第 7 章 设计体系结构软件构架实践 Len Bass 著 车立红译清华大学出版社 7.1 生命期中的体系结构 7.2 良好体系结构的评判原则 7.3 体系结构设计的质量驱动方法 7.4 创建骨架系统 7.5 团队结构的形成 7.6 设计师的职责 7.7 小结1. 瀑布模型(waterfall model)Winston Royce在1970年提出了著名的“瀑布模型”。瀑布模型将软件生命周期划分成了：制定计划、需求分析和 定义、软件设计、程序编写、软件测试、运行和维护这六 个阶段。规定了它们自上而下、相互衔接的固定次序，如同瀑布流水 ，逐级下落。优点：各个阶段的划分非常明确，每一个阶段有明确分工， 从对软件生命周期各阶段有明确的界定，可以良好的把握 。n常见的软件生命周期模型1. 瀑布模型(waterfall model)n常见的软件生命周期模型7.1 生命期中的体系结构1. 瀑布模型(waterfall model)如需求分析后，紧接着是系统设计。在系统设计过程中， 往往会发现更多的需求。或者在系统设计过程中，由于跟 用户交流增多，用户又意识到了更多的需求。所以在系统 设计当中，往往会引发新的需求。从而引起需求分析的改 变，进一步的引发系统设计的更改。又或，在系统实现的过程当中，发现系统分析的不足，从 而影响到对系统设计的更改。n常见的软件生命周期模型1. 瀑布模型(waterfall model)在实际的软件开发过程中，会存在很多循环反复的行为。软 件生命周期后面阶段的行为，会影响到软件生命周期前面阶 段的行为。而瀑布模型认为每一阶段是相互分离的，而每一 阶段不可能回到前面一阶段，这也是为什么称为瀑布模型， 瀑布从高往下流，从前面阶段往后面阶段流，不可能倒流回 来。缺点：没有考虑到软件开发过程中常见的循环往复的行为。 从而很难适应实际开发的需要。n常见的软件生命周期模型2. 演化模型n常见的软件生命周期模型2. 演化模型用户可以给出待开发系统的核心需求，并且当看到核心需求 实现后，能够有效地提出反馈，以支持系统地最终设计和实 现。演化模型对软件开发过程中的循环往复的行为，尤其是对需 求的不断变更提供了良好的支持。演化模型中可以在核心需 求实现之后，把对核心需求进一步的新的反馈信息溶入到系 统当中，从而更好的支持系统的设计和实现。演化模型中各个阶段都可以有循环往复的行为，可以更好的 适应实际开发的需要n常见的软件生命周期模型3. 螺旋模型是瀑布模型与演化模型的结合，并加入了两者所忽略的风险 分析因素，所建立的一种软件开发模型。n常见的软件生命周期模型体系结构设计在软件生命周期中处于什么位置？下图的演变交付生命期模型（演化模型）表明了体系结构所应 处的位置。7.1 生命期中的体系结构软件过程对软件开发活动的组织、规范和管理基于体系结构的开发步骤：（即以体系结构为核心来进行软件开发）1. 为软件系统构建一个商业案例需要设计师来参与，不仅要看到商业前景，还要看到现有的 技术水平能否实现系统。2. 弄清系统需求在需求阶段是无法弄清楚需求的，要在需求与设计的迭代过 程中才能真正理解需求，也可以设计出满足需求的体系结构 。这也需要设计师参与。3. 构建或选用体系结构通常是选用体系结构，很少是新建体系结构。4. 正确表述此体系结构（写出文档），并与有关各方进 行交流（例如与需求的各方交流）5. 对此体系结构进行分析和评价请专家评审，用需求与设计的迭代来实现用户的真正 的需求，也可以得到满足这些需求的体系结构。6. 实现基于体系结构的系统并保证与体系结构相一致在实现的过程中，体系结构并不是不可以修改。在实 现过程中可能体系结构出现一些问题，可以作修改， 要保证实现的内容与体系结构一致。7. 系统维护时，体系结构文档应同步维护u何时可以开始设计体系结构?对需求有了初步了解就可以开始设计，但是并不需要太多的 需求。关注哪些重要的需求，而忽略不重要的需求，以免设计师 在设计时有太多相互制约的约束。u体系结构驱动因素（即设计的依据）的组成：p重要的功能（或功能需求）p重要的质量属性（或质量需求）p重要的限制条件（或商业需求等）以上三个因素构成的某个子集。u功能需求和质量需求是无关，体系结构的设计是由质量需 求决定的，这是否意味着体系结构的设计是否跟功能需求无 关呢？实事上一个系统的体系结构设计是不能不考虑系统的功能需 求的。体系结构设计是将系统的功能需求划分到系统的各个 不同的模块当中，即体系结构设计是功能划分的过程。各种 不同的功能划分，形成了系统的不同结构，从而形成了系统 的不同体系结构，也就表现出不同的质量属性。所以体系结 构设计是功能划分的过程，体系结构设计离不开功能需求的 。u如何确定体系结构驱动因素?业务目标优先级较高的要求7.2 良好体系结构的评判原则设计体系结构过程的建议：1. 体系结构的设计应该由一位设计师来完成2. 设计师应全面掌握对系统的技术需求，以及对各项定性指标 优先级的清单3. 体系结构的文档完备，并采用所有人员认可的文档形式4. 体系结构设计方案应让各风险承担者积极参与评估5. 通过专家对体系结构分析，得出明确的定性与定量指标6. 体系结构设计应有助于具体实现7. 允许体系结构带来一定的资源争用，并给出可行的解决方案关于体系结构的建议：1. 体系结构由定义良好的模块组成，各模块的功能划分应基于信息隐藏2. 模块的划分应体现出相互独立的原则3. 把计算机基础结构的特性封装在一定的模块中（便于系统的移植）4. 体系结构尽量不依赖于某个特定版本的商用产品或工具（如果依赖于某个特定版本的商用产品或工具，系统以后升级会受到制约，会产生更高昂的代价。所以要采用更加通用的、可以替代的工具和产品。）关于体系结构的结构的建议：5. 产生数据的功能和使用数据的功能应分属于不同的模块（一般采用数据库来管理数据，会把写入数据模块和读入数据的模块进行分离）6. 对并发系统，体系结构应充分考虑进程与模块结构的不对应7. 进程编写要考虑到与特定处理器的关系，并容易改变关系7. 体系结构应尽量采用一些已知的设计模式（如工厂模式、门面模式、模板模式等等）。7.3 体系结构设计的质量驱动方法你作为设计师对体系结构的设计和评价就如同一个足球 教练对一场比赛的球队组织。你首先要了解自身和对手的情况，明确你这场比赛想打 输、打赢或打平（质量目标）；然后根据该目标设计比赛阵型，如攻击或防守阵型；再确定相关战术和人员组织（体系结构设计、战术选用 ）；最后将你的设计和队员沟通，取得全体队员的共识（体 系结构评价）。属性驱动的设计(Attribute Driven Design, ADD)把一组质量属性场景作为输入，利用对质量属性实现与体系结构设计之间的关系的了解（如体系结构风格、质量战术等），对体系结构进行设计。ADD是一种定义软件体系结构的方法，该方法将模块分解过程建立在软件必须满足的质量属性之上。它是一个递归的分解过程，其中在每个阶段都选择体系结构模式和战术来满足一组质量属性场景，然后对功能进行分配，以实例化有该模式所提供的模块类型。ADD与普通体系结构设计方法的区别：普通体系结构设计方法是先按功能划分模块，后看系统满足相应质量，即以功能为主要矛盾，质量为次要矛盾来设计软件；ADD是将模块分解过程建立在软件必须满足的质量属性之上，再把功能作为模块的实例化来把功能附加在模块上。即先满足质量，在对功能进行分配。即以质量为主要矛盾， 功能为次要矛盾来进行体系结构设计。ADD的结果是粗粒度的， ADD的结果是体系结构的模块分解和其他视图的最初的几个层次，不是所有视图的所有细节都是通过ADD得到，它不能取代传统的面向对象的设计。由ADD得到的体系结构和已经为实现做好准备的体系结构之间的区别是，需要做出更详细的设计决策。如先由ADD方法得到系统的整体框架初步确定，再由面向对象的的方法得到更加详细的设计。ADD体系结构设计的步骤如下（共4步）：1. 样本输入。系统要满足的功能、质量及受到的限制。2. 选择要分解的模块。首先要分解的就是系统本身最大的等待 分解的模块。3. 根据下列步骤对模块进行求精：a. 从具体的质量场景和功能需求集合中选择体系结构驱动因 素。先找到比较重要的功能、重要的质量场景及重要的限制条 件，但是个数不能太多。b. 选择满足体系结构驱动因素的体系结构风格。根据体系结构风格、质量战术来选择满足体系结构驱动 因素的体系结构风格c. 实例化模块并根据用例分配功能，使用多个视图进行 表示。d. 定义子模块的接口。e. 验证用例和质量场景（是否得到满足）并对其进行求 精，使它们成为子模块的限制（这样可以使子模块得到 进一步划分）。4. 对需要进一步分解的每个模块重复上述步骤。这样递归 的过程一般不超过23步。7.4 创建骨架系统用ADD方法将体系结构设计出来，是否可以直接用来实现系 统呢？中小规模的软件系统可以中大规模的交复杂的软件系统，能否得到实现还不确定，这样 可以求助与骨架系统。骨架系统类似于楼盘模型7.4 创建骨架系统1. 提高开发效率，鼓舞士气。2. 能更早发现复杂的依赖关系。3. 使开发人员更多关注在设想中最难以实现的部分。4. 能够缩短系统集成时间，降低其成本，并使集成成本更明确。5. 便于评审和测试。创建骨架系统的思想是提供一种基本能力，以一种对项目有力的 顺序实现系统的功能。在系统开发的最初阶段创建整个系统的骨架系统是非常重要的， 主要原因包括：创建骨架系统的步骤：1. 实现处理体系结构组件交互的软件部分。（ 先实现关节点）2. 选择组件逐步添加到系统中。3. 逐步进行测试。7.5 设计师的职责设计师要和多个部门和多种人沟通u如要指导以体系结构为核心形成开发团队，协调团队 之间的合作，解决他们之间的冲突；u设计师要支持项目经理的工作，要知道开发团队的技 术水平；u为明确组织的业务目标，设计师需要和售前、售后部 门交流，拜访客户。因此，设计师必须纵观软件过程的全局，并对不同角色相 互合作的接口和时机有清晰的把握。设计师的职责包括：1 了解所在组织的业务目标，使体系结构更好地支持业务目标2 规划产品的开发与演进3 规划和建设体系结构级的重用，如产品线等4 领导并负责体系结构设计，定义系统的高层结构和接口5 为项目管理提供支持，如技术可行性、任务划分、人员招聘6 领导和协调项目组的主要技术活动，对主要技术产品负责实 际参与体系结构原型的开发实现7 讲解体系结构、指导详细设计和开发、协调冲突以实现既定 的体系结构目标8 规划和协助软件体系结构的评审9 评估新技术并提出采用建议7.6 团队结构的形成u开发小组的结构反映了体系结构的模块结构。可以把模块看作一个小领域，再根据开发人员的专长进行安排。u开发小组要做到松耦合，高内聚，即小组内需要有非常便于沟通的机制，小组间的沟通尽可能少（可以并行的开发，减少小组间的相互等待，和产生相互摩擦）。u开发组织对体系结构也会有影响。7.7常见的软件生命周期模型体系结构设计的ADD方法，以质量属性为主 要矛盾来进行体系结构设计。