《架构师培训4-高层软件架构的设计》由会员分享，可在线阅读，更多相关《架构师培训4-高层软件架构的设计（30页珍藏版）》请在金锄头文库上搜索。
1、第四章 高层软件架构的设计在高层设计阶段，主要工作是分析与设计软件的体系结构。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，产生体系结构设计报告。这个阶段是系统架构师发挥作用的主要位置，高层架构设计过程设计流程如下。确定设计策略确定 约束 因素设计 准备系统分解设计设计评审撰写 文档在分析阶段，我们建立模型表示真实的世界，以便理解业务过程以及这个过程中所要用到的信息。基本上说，分析首先是分解，把复杂信息需求的综合问题，分解成易于理解的多个小问题。然后通过建立需求模型来对问题领域进行组织、构造并且编制文档。分析建模过程必须要用户参与，并且需要用户解释需求，并且
2、验证建立的模型是否正确。设计也称之为架构设计，实际上也是个建模过程，它把分析阶段得出的信息也就是需求模型，转换为称之为解决方案的模型。一般来说架构设计是一个高度技术的工作，一般不需要涉及太多的用户，但需要系统分析人员和部分开发人员参与。因为系统设计的输出就是开发的蓝图。下面讨论在这一阶段一系列的原则和思想。第一节 高层软件架构的规划一、客户服务结构（C/S architecture）这个结构可以用部署图来表示。二、多级体系结构（four-tier architecture）这里使用了组件图和部署图。三、多级体系结构（串行法和团聚法）四、流处理体系结构（procedural prcessing
3、architecture）五、代理体系结构（agent architecture）六、聚合体系结构（aggregate architecture）七、联邦体系结构（federation architecture）第二节 面向过程的架构设计面向过程的架构设计，又称之为结构化设计。它使用“输入 处理 输出”这样一个基本模型，这些模式比较适用于描述商业软件，它们中大多数依靠数据库或者文件，并且不太需要复杂的实时处理。我们可以使用流程图来记录各个子系统的结构，系统流程图标识了每个程序，以及他们存取的数据。一、系统流程图系统流程图是用图形的方式描述哪些子系统是系统自动完成的，哪些是需要人工参与的，并且显
4、示了数据流和控制流。系统流程图主要描述大的信息系统，这种大的信息系统由单个的子系统和大量的程序块组成。绘制流程图使用的主要符号如下，也可以有其它的变体。下面是一个销售系统的流程。二、结构图及其应用结构化设计的基本任务，是自顶向下的分解任务，结构图是用来展示计算机程序模块之间的层次关系。结构图的主要符号如下：下面是一个工资系统的部分结构图。三、模块算法设计（伪码）结构化设计的另一个需求，是描述每个模块的内部逻辑，我们可以用自己熟悉的语言来定义伪码（比如C），使用伪码并不是写出程序，而是为了更清楚地描述模块级的逻辑。这样也可以避免各种图泛滥成灾。第三节 面向对象的架构设计在面向对象的设计中，关注点
5、变成了消息和响应机制。而我们由面向对象的分析转向面向对象的设计是一个自然的结果，在OOA中已经提供了足够多的信息，在高层设计阶段，我们可以用包图来建立体系架构。在详细设计阶段，可以利用类图建立相应的体系结构。下图是以类表达的典型的Nhibernate体系结构。在设计的各个阶段，在必要的重点位置，我们还可以用顺序图或者协作图来描述一些最重要的消息机制。面向对象的设计不仅仅是根据功能性和非功能性需求建立一些相应的结构，更重要的是要分析一些潜在问题，通过种种设计技巧，提升系统的整体性能。下面我们来讨论有关问题。第四节 高层设计中的架构分析面向对象的设计并不是简单的把需求分析中的领域模型转换成设计模型
6、就可以了，架构师必须在由需求分析获取架构因素，因此我们首先必须研究架构分析的问题。另外，由于面向对象设计的成熟和发展，已经形成了一系列的重要设计原则和方法，这些原则和方法可以大大的提高我们的设计质量，这是使用OOD必须关注的问题。面向对象的架构设计与结构化设计根本的不同，是非常注意实时信息，也就是消息和响应机制。另一方面，也非常注意代码重用，设计的目标往往是大型的、分布式的、可升级、可维护而且是安全的体系，这也对设计者提出了更高的要求。架构分析的本质，是识别可能影响架构的因素，了解它的易变性和优先级，并解决这些问题。其难点是，应该了解提出了什么问题，权衡这些问题，并掌握解决影响架构重要因素的众
7、多方法。架构分析是高优先级和大影响力的活动。架构分析对如下的工作而言是有价值的：l 降低遗漏系统设计核心部分的风险l 避免对低优先级的问题花费过多的精力l 为业务目标定位产品一、架构分析 架构分析是在功能性需求过程中，有关识别非功能性需求的活动。1）架构分析需要解决的问题下面说明在架构级别上，需要解决的诸多问题的一些示例：l 可靠性和容错性需求是如何影响设计的？l 购买的子组件的许可成本将如何影响收益？l 分布式服务如何影响有关软件质量需求和功能需求的？l 适应性和可配置性是如何影响设计的？2）架构分析的一般步骤架构分析有多种方法，大多数方法都是以下步骤的变体。1辨识和分析影响架构的非功能性需
8、求。2对于那些具有重要影响的需求而言，分析可选方案，并做出处理这些影响的决定，这就是架构决策二、识别和分析架构因素 1）架构因素任何需求对一个系统架构都有重要影响。这些影响包括可靠性、时间表、技能和成本的约束。比如，在时间紧迫、技能有限同时资金充足的情况下，更好的办法是购买和外包，而不是内部开发所有的组件。然而，对架构最具影响的的因素，包含功能、可靠性、性能、支持性、实现和接口。通常是非功能性属性（如可靠性和性能）决定了某个架构的独到之处，而不是功能性需求。2）质量场景在架构因素分析期间定义质量需求的时候，推荐应用质量场景。它定义了可量化（至少是可观测）的响应，并且因此可以验证。质量场景很少使
9、用模糊的不具度量意义的描述，比如“系统要易于修改”。质量场景用的形式作简短的描述，如：l 当销售额发送到远程计税服务器计算税金的时候，“大多数”时候必须2秒之内返回。这一结果是在“平均”负载条件下测量的。l 当系统测试志愿者提交一个错误报告的时候，要在一个工作日内通过电话回复。这里，“大多数”和“平均”需要软件架构师作进一步的调查和定义。质量场景直到做到真的可测试的时候，才是真正有效的。这就意味着需要有一个详细的说明。3）架构因素的描述架构分析的一个重要目标，是了解架构因素的影响、优先级和可变性（灵活性以及未来演变的直接需要）。因此，大多数架构方法，都提倡对以下信息建立一个架构因素表。因素测量
10、和质量场景可变性（当前灵活性和未来演化）因素（和其变化）对客户的影响，架构和其它因素获取成功的优先级困难或风险可靠性 - 可恢复性从远程服务失败中恢复。当远程服务失败的时候，侦听到远程服务重新在线的一分钟内，重新与之建立联系，在产品环境下实现正常的存储装载。当前灵活性我们的SME认为直到重新建立连接前，本地客户简化的服务是可以接受的（也是可取的）。演化在2年之内，一些零售商可能选择支付本地完全复制远程服务的功能（如税金计算器）。可能性？高。对大规模设计影响大。零售商确实不愿意远程服务失败，因为这将限制或阻止它们使用POS进行销售。高低注：SME表示主题专家。请注意上面的分类方法：可靠性可恢复性
11、。在这里这么说明不等于它是唯一的或者最好的，但它对架构因素的分类很有效。3）架构因素和UP工件在架构设计中，中心功能需求库就是用例，它的构想和补充规范，都是创建因素表的重要源泉。在用例中，特殊需求、技术变化、未决问题应该被反复审核。其隐含或者清晰的架构因素要被统一整理到补充规范里面去。例如：用例1：Process Sale主要成功场景1特殊需求l 90%的信用授权应该在30秒内响应l 无论如何，当远程服务如库存系统失败的时候，我们需要强健的恢复措施。l 技术和数据变化表2a. 商品的表识可以通过条形码扫描器或者是键盘输入。未决问题l 税法的变化是什么？l 研究远程服务的恢复问题。三、架构因素的
12、解析架构设计的技巧就是根据权衡、相互依赖关系和优先级对架构因素的解决作出合适的选择。但这还不全面，老练的架构师具有多种领域的知识（例如：架构样式和模式、技术、产品、缺陷和趋势），并且能把这些知识应用在它们的决定中。1）记录架构的可选方案、决定和动机不管目前架构决策的原则有多少，事实上所有的架构方法都推荐记录：可选的架构方案；决定；影响因素；显著问题；决定动机。这些记录按不同的的形式或者完善程度，被称之为：技术备忘录；问题卡；架构途径文档。技术备忘录的一个重要的的方面就是动机或者原理，当开发者或者架构师以后需要修改系统的时候，架构师可能已经忘了他当初的设计依据（一个资深架构师同时带多个项目的情况
13、非常多见），备忘录对理解当时的设计背后的动机极为有用。解释放弃被选方案的理由十分重要，在将来产品进化的过程中，架构师也许需要重新考虑这些备选方案，至少知道当初有些什么备选方案，为什么选中了其中之一。技术备忘录的格式并不重要，关键是简单、清楚、表达信息完整。技术备忘录问题：可靠性-从远程服务故障中恢复解决方案概要：通过使用查询服务实现位置透明，实现从远程到本地的故障恢复和本地服务的部分复制架构因素l 从远程服务中可靠恢复l 从远程产品数据库的故障中可靠恢复解决方案在服务工厂创建一个适配器动机零售商不想停止零售活动遗留问题无考虑过的备选方案与远程服务厂商签订“黄金级”服务协议2）优先级下面是指导做
14、出架构决定目标：1不可改变的约束，包括安全和法律方面的事务2业务目标3其它全部目标早期要决定是否应该避免保证未来的设计，应该实事求是的考虑，那些将要推迟到未来的场景，有多少代码需要改变？工作量将是多少？仔细考虑潜在的变更将有助于揭示什么是首要考虑的重要问题。一个低耦合高内聚的产品，往往比较容易适应将来的变化，但也要仔细分析这样付出的代价，在这个问题上，架构师的掂量往往是决定这个项目的生命线。3）系统不同方面的分离和影响的局部化架构分析的另外一个基本原则，就是实现分离系统的不同方向。系统不同方向的分离，是在架构级别上关于低耦合和高内聚的一种大尺度思考方法。虽然它们也应用在小尺度对象上，但这样的分离对于架构问题尤其突出。因为系统的不同方面很广泛，而且架构的解决方案涉及重要的设计选择。至少有三个实现系统不同方面分离的大尺度技术：1把系统的一个方面模块化到一个独立的组件（如子系统）中并且调用它的服务。2使用装饰器模式3采用后编译器技术和面向方面的技术有了架构分析的结果，我们就可以讨论高层架构设计本身的一系列原则了。第五节 高层架构设计中的层模式一、面向对象软件架构的优点 1）面向对象软件架构的维和视图
