第七章 系统架构设计基础知识

7.1 软件架构概念

7.1.1软件架构的定义

• 1.一个程序和计算机系统软件体系结构是指系统的一个或多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系，SA：体系结构or架构
• 2.体系结构并非科运行软件，准确来说是一种表达
  • （1）分析设计在满足所规定的需求方面的有效性
  • （2）在设计变更相对容易的阶段，考虑体系结构可能的选择方案
  • （3）降低与软件构造相关联的风险
• 3.在体系结构设计的环境中，软件构件简单到可以是程序模块或者面向对象的类，也可以扩充到包含数据库和能够完成客户与服务器网络配置的中间件
• 4.软件体系结构的设计需要考虑数据设计和体系结构设计
  • 数据设计体现传统系统中体系结构的数据构件和面向对象系统中类的定义（封装了属性和操作）
  • 体系结构设计则主要关注软件构件的结构、属性和交互作用

7.1.2 软件架构设计与生命周期

• 1.需求分析阶段
  • 需求分析阶段的SA研究还处于起步阶段。在本质上，需求分析和SA设计面临的是不同的对象，一个是空间问题；另一个是解空间。保持二者的可追踪性和可转换性，一直是软件工程领域追求的目标。从软件需求模型向SA模型转换主要关注两个问题
    • （1）如何更具需求模型构件SA模型
    • （2）如何保证模型转换的可追踪性
  • 解决方案
    • 在采用Use Case图描述需求的方法中，从用例图向SA模型（包括类图等）的转换一般经过词法分析和一些经验规则来完成，而可追踪性则可通过表格或者Use Case Map等来维护
  • 从软件复用的角度看，SA影响需求工程也有其自然性和必然性，已有系统的SA模型对新系统的需求工程能够起到很好的借鉴作用。在需求分析阶段研究SA，有助于将SA的概念贯穿整个软件生命周期，从而保证了软件开发过程的概念完整性，有利于各阶段参与者的交流，也易于维护各近阶段的可追踪性
• 2.设计阶段
  • 设计阶段是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：
    • SA模型的描述
    • SA模型的设计与分析方法
    • SA设计经验的总结与复用等
  • 有关SA模型描述的研究分为3个层次
    • （1）SA的基本概念，即SA模型由哪些元素组成，这些组成元素之间按照何种原则组织。传统的涉及概念只包括构件以及一些基本的模块互联机制。互联的机制成为与构件同等级别的实体，称为连接子。现阶段的SA描述方法是构件和连接子的建模。
    • （2）体系结构描述语言ADL，支持构件、连接子及其配置的描述语言就是体系结构描述语言。ADL对连接子的重视成为区分ADL和其他建模语言的重要特征之一。
      • 典型的ADL包括UniCon、Rapide、Drwain、Wright、C2 SADL、Acme、xADL、XYX/ADL 和ABC/ADL
    • （3）SA模型的多视图表示，从不同的视角描述特定系统的体系结构，从而得到多个视图，并将浙西而视图组织起来以描述整体的SA模型。系统的每一个不同侧面的视图反映了一组系统相关人员所关注的系统的某一特定方面，多视图提下了关注点分离的思想
      • 把体系结构描述语言和多视图结合起来描述系统的体系结构， 使系统更易于理解，方便系统相关人员之间进行交流，并且有利于系统的的一致性检测以及系统质量属性的评估
      • 典型的4+1视图：逻辑视图，进程视图，开发视图，物理视图，统一的场景
        • PS：区别UML视图：逻辑视图，进程视图，实现视图，部署视图，用例视图
      • Hofmesister的4视图：概念视图，模块视图，执行视图，代码视图
      • Views and Beyond模型：模块视图、构件和连接子视图、分配视图
• 3.实现阶段
  • 最初的SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现从SA设计项实现的转换，实现阶段的体系结构研究表现在以下几个方面
    • （1）研究基于SA的开发过程支持，如项目组织结构，配置管理等
    • （2）寻求从SA项实现过渡的途径，如将程序设计语言元素引入SA阶段、模型映射、构件组装、复用中间件平台等
    • （3）研究基于SA的测试技术
  • SA提供了待生成系统的蓝图，根据该蓝图较好地实现系统需要的开发组织结构和过程管理技术。 以体系结构为中心的软件项目管理方法，开发团队的组织结构应该和体系结构模型有一定的对应关系，从而提高软件开发的效率和质量
  • 在大型软件系统中，参与实现人员较多，需要提供适当的配置管理手段。SA引入能够有效扩充现有配置管理的能力，通过在SA描述中引入版本、可选择项等信息，可以分析和记录不同版本构件和连接子之间的演化，从而可用来组织配置管理的相关活动
  • 为了填补高层SA模型和底层实现之间的鸿沟，可通过封装底层的实现细节、模型转换、精化等手段缩小概念之间的额差距
    • （1）在SA模型中引入实现阶段的概念，如引入程序设计语言元素等
    • （2）通过模型转换技术，将高层的SA模型逐步精化成能够支持实现的模型
    • （3）封装底层的实现细节，是指成为较大粒度构件，在SA指导下通过构件组装的方式实现系统，往往需要底层中间件平台的支持
• 4.构件组装阶段
  • 在SA式设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用，研究内容包括以下两个方面
    • （1）如何支持复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持
    • （2）在组装过程中们如何检测和并消除体系结构失配问题。
  • 对设计阶段连接子的支持：支持在实现阶段将连接子转换为具体的程序代码或系统实现。
  • 中间件遵循特定的构件标准，为构件互联提供支持，并提供相应的公共服务，如安全服务，命名服务等。中间件支持的连接子实现有以下优势
    • （1）中间件提供了构件之间跨平台交互的能力，且遵循特定的工业标准。如J2EE、COM、CORBA等，可以有效地保证构件之间得到通信完整性
    • （2）产品化的中间件可以提供强大的公共服务能力，这样能够更好地保证最终系统的质量属性。设计阶段连接子的规约可以用于中间件的选择，如消息通信连接子最好选择提供消息通信机制的中间件平台（导致新的SA风格出现，即中间件导向的体系结构风格）
  • 检测并消除体系结构的失配问题：失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设于实际状况不同而导致的冲突。构件组装阶段失配问题主要包括3方面
    • （1）由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配
    • （2）由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配
    • （3）由于系统成分对全局体系结构假设存在冲突引起的失配等。要解决失配问题，首先需要能够检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。
• 5.部署阶段
  • 由于网络于分布式软件的发展，软件部署逐渐从软件开发过程中独立出来，成为软件生命周期的一个独立阶段。为了使分布式软件满足一定的质量属性要求、如性能、可靠性等，部署要考虑多方面的信息，如待部署软件构件的互联性，硬件的拓扑结构、硬件资源（CPU、内存）占用等。SA对软件部署的作用如下
    • （1）提供高层的体系结构视图来描述部署阶段的软硬件模型
    • （2）基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案
  • 部署阶段，基于SA的见软部署研究更多地集中在组织和展示部署阶段的SA、评估分析部署方案等方面，部署方案的分析往往停留在定性的层面，并需要部署人员的参与。
• 6.后开发阶段
  • 后开发阶段是指软件部署安装之后的阶段。这一阶段的SA研究主要为围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复和重建等
    • 1）动态软件体系结构
      • 传统的SA研究设想体系结构总是静态的。即软的体系结构一旦建立，就不会在运行时刻发生变动，但现实中的软件往往具有动态性，即他们的体系结构会在运行时发生改变。
      • SA在运行时发生的变化包括两类
        • （1）一类时软件内部执行所导致的体系结构改变
          • 如很多服务器端软件会在客户请求达到时创建新的构件来响应用户的请求
          • 某个自适应的软件系统可能根据不同的配置状况采用不同的连接子来响应用户的请求
        • （2）另一类变化时软件系统外部的请求对软件进行的重配置
          • 系统在升级或进行其他修改时不能停机
      • 动态软件体系结构研究分为两个部分
        - （1）体系结构设计阶段的支持：主要包括变化的描述、如何根据变化生成修改策略、描述修改过程、在高抽象层次保证修改的可行性以及分析、推理修改所带来的影响。
        - （2 ）运行时刻基础设施的支持：主要包括系统体系结构的维护、保证体系结构修改在约束范围内、提供系统的运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射体系结构构造元素的变化到实体模块、保整系统的重要子系统的连续执行并保持状态、分析和测试运行系统等
    • 2）体系结构恢复与重建
      • 很少系统时从头开发的，大量的软件开任务是基于已有的遗产系统进行升级、增强或移植。但这些系统没有考虑SA，需要构件化包装，复用的时候需要得到体系结构的支持，所以这些系统的恢复和重构是有意义和必须的
      • SA重建 是指从已经实现的系统中获取体系结构的过程。SA重建的输出是一组体系结构视图。现有的体系结构重建方法分为四类
        • （1）手动体系结构重建
        • （2）工具支持的手动重建
          • 通过工具对手工重建提供辅助支持，包括获得基本体系结构单元、提供图形界面允许用户操作SA模型、支持分析SA模型等
        • （3）通过查询语言来自动建立聚集。适合较大规模的系统，基本思路是：在逆向工程工具的支持下分析程序源代码，然后将得到的体系结构信息存入数据库，并通过适当的查询语言得到有效的体系结构显示
        • （4）使用其他技术，如数据挖掘等

7.1.3 软件架构的重要性

• 软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素
• 1.架构设计能够满足系统的品质
  • 系统的功能性是软件架构设计师通过组成体系结构的多种元素之间的交互作用来支持的。架构设计用于实现系统的品质，如性能，安全性和可维护性等。通过架构设计文档化，可以尽早地评估项目的这些品质
• 2.架构设计使受益人达成一致的目标
  • 架构设计使不同的受益人达成一致的目标，，体系架构的设计过程需要确保架构设计被清楚地传达与理解，一个被有效传达的体系架构使得涉众们可以辩论、决议和权衡，反复讨论最终达成共识。文档化体系架构师非常重要的，这是软件架构设计师的主要职责
• 3.架构设计能够支持计划编制过程
  • 架构设计将确定组件之间的依赖关系，直接支持项目计划和项目管理的活动，例如， 细节划分、日程安排、工作分配、成本分析、风险管理和技能开发等
  • 架构设计师还能协助估算项目成本，例如体系架构决定使用第三方组件的成本，以及支持开发的所有工具的成本；
  • 架构设计师支持技术风险的管理，包括指定每一个风险的优先次序，以及确定一个恰当的风险缓解策略
• 4.架构设计对系统开发的指导性
  • 架构设计的主要目标就是确保体系架构能够为设计人员与实现人员所承担的工作提供可靠的框架。
  • 确保最终体系架构的完整性，架构设计师必须要明确定义体系架构，能确定体系架构的重要元素，如系统的组件，组件之间的接口以及组件之间的通信
  • 架构设计师需要定义恰当的标准和指导方针，它们将会引导设计人员和是现人员的工作。对开发过程活动采取恰当的架构回顾和怕评估，能偶确保体系架构的完整性。这些QA（质量保证）活动的任务是确定体系架构的标准和指导方针的有效性
• 5.架构设计能够有效地管理复杂性
  • 体系架构通过构件与构件之间的关系，描述了一个抽象的系统，因而提高了高层次的复杂的管理的方法。同理架构设计过程考虑组件的递归分解，能够将大问题分解成很多小问题，再逐个解决。
• 6.架构设计能为复用奠定了基础
  • 架构设计过程可以同时支持使用和建立复用资源。复用资源可以降低一个系统的成本，并且可以改进系统的质量。一个体系架构的建立，能够支持大粒度的资源复用。如体系架构的重要组件和它们之间的接口和质量，能够支持货品供应的组件，存在的系统和封装的应用程序等的选择，从而可以用来实现这些组件
• 7.架构设计能够降低维护费用
  • 架构设计过程要确保系统的维护人员是一个主要的涉众，并且他们的需求被作为首要的任务满足。
  • 一个被恰当文档化的体系架构不应该仅仅为了减轻系统的可维护性，架构设计师还应该确保结合恰当的系统维护机制，并且再建立体系架构的时候还要考虑系统的适应性和可扩充性
• 8.架构设计能够支持冲突分析
  • 架构设计的重要好处是，它允许人们在采取改变之间推断它所产生的影响。一个软件架构确定了主要的组件和它们之间的交互作用，两个组件之间的依赖性以及这些组件对与需求的可追溯性。有了这些信息，需求的改变等可以通过组件的影响来分析。同样的，改变一个组件的影响可以在依靠它的其他组件上分析出来

7.2 基于架构的软件开发方法

7.2.1 体系结构的设计方法概述

• 基于体系结构的软件设计方法（ABSD）。
• ABSD方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的。
• 使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味这需求抽取和分析还没有完成，就开始了软件设计。设计活动的开始并不意味着需求抽取和分析活动就可以终止，而是应该与设计活动并行。特别是不可能预先决定所有需求时，快速开始设计是至关重要的
• ABSD 方法的三个基础
  • 1.功能的分解：分解过程中使用已有的基于模块的内聚和耦合技术
  • 2.通过选择体系结构风格来实现质量和商业需求
  • 3.软件模板的使用，软件模板来利用了一些软件系统的结构
• ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的，能够有效降低体系结构设计的随意性

7.2.2 ABSD的概念和术语

• 1.设计元素
  • 1）ABSD方法是一个自顶向下，递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类
  • 2）ABSD方法中使用的设计元素如图所示，
    • 在最顶层：系统被分解为若干概念子系统和一个或若干个软件模板
    • 在第二层：概念子系统分解为概念构件和一个或若干个软件模板
    • 第三层为：概念构件转为实际构件
    • 
• 2.视角于视图
  • 在考虑体系结构时，要从不同的视角来观察对架构的描述，这需要考虑体系结构的不同属性。
    • 展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。如选择的特定视角或视图（逻辑视图、进程视图、实现视图和配置视图）可以全方位的体系考虑结构设计。
• 3.用例和质量场景
  • 用例已经成为推测系统在一个具体设置重点额行为的重要技术，用例被用在很多不同的场合，用例时系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求
  • 使用质量场景捕获变更，性能、可靠性和交互性，分别称为变更场景，性能场景、可靠性场景和交互性场景。质量场景必须包括预期的和非预期的场景

7.2.3 基于体系结构的开发模型

• 1.传统的软件开发过程可以划分从概念直到实现的若干阶段，包括问题定义、需求分析、软件设计、软件实现及软件测试等
• 2.ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程
  • 

7.2.4 体系结构需求

• 体系结构需求是指用户对目标软件系统在功能更、行为、性能、设计约束等方面的期望。
  体系结构需求受技术环境和体系结构设计师的经验影响。
  需求过程主要是获取用户需求，标识系统中所要用的构件
  • 体系结构需求过程
    • 1.需求获取
      • 体系结构需求一般来自3个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标
      • 软件体系结构需求过程主要是定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务上的需求。与此同时，还要获得软件质量属性，满足一些非功能性需求
    • 2.标识构件
      • 该过程为系统生成初始逻辑结构，包含大致的构件
        • 1）生成类图
        • 2）对类进行分组
          • 在生成类图的基础上，使用一些标准对类进行分组可以大大简化类图结构，使之更清晰，一般地，于其他类隔离的类形成一个组，由概况关联的类组成一个附加组，由聚合或合成关联的类也形成一个附加组。
        • 3）把类打包成构件
    • 3.需求评审
      • 组织成一个由不同代表（分析人员、客户、设计人员和测试人员）组成的小组，对体系结构需求及相关构件进行仔细地审查。
        • 审查的主要内容包括：获取的需求是否真实反映了用户的要求；类的分组是否合理，构件合并是否合理。必要是可以在需求获取-标识构件-需求评审之间进行迭代
    • 

7.2.5 体系结构设计

• 体系结构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的系信息。体系结构设计是一个迭代的过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有的系统设计过程
• 软件体系设计过程如下
  • 1.提出体系结构模型
    • 建立体系结构的初期，需要选择合适的体系结构风格是首要的
  • 2.把已标识的构件映射到软件体系结构中
    • 把在体系结构需求阶段已标识的构件映射到体系结构中，将产生一个中间构件，这个中间构件指包含那些能明确适合体系结构模型的构件。
  • 3.分析构件之间的相互作用
    • 把所有已标识的构件集成到体系结构中，认真分析这些构件的相互作用和关系
  • 4.产生构件体系结构
    • 一旦决定了关键构件之间的关系和相互作用，就可以在第二阶段得到中间结构的基础上进行精华
  • 5.设计评审
    • 一旦设计了软件结构体系，必要邀请独立于系统的外部人员对体系结构进行评审
  • 

7.2.6 体系结构文档化

• 1.大多数体系结构都是抽象的，由一些概念上的构件组成，如层的概念在任何程序设计语言中都不存在。所以要实现体系结构，需要体系结构文档化
• 2.文档是在系统演化的每一个阶段，系统设计和开发人员的额通信媒介，是为验证体系结构设计和提炼或修改这些设计所执行预先分析的基础
• 3.体系结构文档化过程的主要输出结果是两个文档
  • 体系结构规格说明书
  • 测试体系结构需求的质量说明书
• 4.生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约
• 5.文档的完整性和质量是软件体系结构成功的关键因素。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须要保证开发者手上的文档是最新的。

7.2.7 体系结构复审

• 体系结构设计、文档化和复审是一个迭代过程。即一个主版本的软件体系结构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。
• 通常搭建一个可运行的最小化系统用于评估和测试体系架构是否满足需要。是否存在可以识别的技术和协作风险
• 复审的目的是：标识潜在的风险、及早发现体系结构设计中的缺陷和错误，包括体系机构能否满足需求，质量需求是否在设计中的得到体现、层次是否清晰、构建的划分是否合理、文档表达是否明确、构建的设计是否满足功能和性能的要求等

7.2.8 体系结构实现

• 实现就是要用实体来显示出一个软件体系结构，即要符合体系结构所描述的结构性设计决策，分割成规定的构件，按规定方式互联交互
• 主要由分析与设计，构件实现，构件组装，系统测试组成，前三部分组成构件库
• 

7.2.9 体系结构的演化

• 在构件开发过程中，用户的需求可能还有变动，在软件开发完毕正常运行后，由一个单位移植到另一个单位，需求也会发生变化，
• 体系结构演化是使用系统演化步骤去修改应用，以满足新的需求，分为6个步骤
  • 1.需求变化归类
  • 2.制定体系结构演化计划
  • 3.修改、增加或删除构件
  • 4.更新构件的相互作用
  • 5.构件组装和测试
  • 6.技术评审
    • 评审组装后的体系结构是否反映需求变动、符合用户，如果不符合，则需要不断迭代
    • 在原系统上所做的所有修改必要集成到原来的体系结构中，完成一次演化过程。

7.3 软件架构风格

• 软件体系结构设计的一个核心目标是重复的的体系结构模式，即达到体系架构的软件中重用。
• 在不同的软件系统中，使用同一体系结构
• 主要任务是研究和实践软件体系结构的风险和类型问题

7.3.1 软件架构风格概述

• 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模型。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。
  • 词汇表中包含一些构件和连接件类型，而这组约束时指出系统时如何件这些构件和连接件组合起来的
• 体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统
• 对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。如“客户/服务器”模式。

7.3.2 数据流体系结构风格

• 数据流体系结构是一种计算机体系结构，直接与传统的冯·诺依曼提携结构或控制流体系结构进行了对比：数据流体系结构没有概念上的程序计数器，指令的可执行性和执行仅基于指令输入参数的可用性来确定，因此，指令执行的顺序是不可预测的，即行为是不确定的。
  • 1.批处理体系结构风格
    • 批处理体系结构风格中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，且数据必须是完整的，以整体的方式传递。它的基本构件是独立的应用程序，连接件是某种类型的媒介。连接件定义了相应的数据流图，表达拓扑结构
  • 2.管道-过滤器体系结构风格
    • 当数据源源不断产生时，系统就需要对这些数据进行若干处理（分析、计算、转换等）。现有的解决方案是
      • 把系统分解成几个序贯的处理步骤， 步骤之间通过数据流连接，一个步骤的输出是另一个步骤的输入。
      • 每个处理步骤由一个过滤器实现，处理步骤之间的传输由管道负责。
    • 管道-过滤器风格的基本构件是过滤器，连接件是数据流传输管道。

7.3.3 调用/返回体系结构风格

• 调用/返回风格是指在系统中采用了调用与返回机制。利用调用返回实际上是一种分而治之的策略，主要思想是将一个复杂的大系统分解为若干子系统，以便降低复杂度，并且增加可修改性。
• 调用返回体系结构风格由4种具体风格
  • 1.主程序/子程序风格
    • 主程序/子程序风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成模块，过程调用作为交互机制，充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性
  • 2.面向对象体系结构风格
    • 建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。构件是对象，或者是抽象数据类型的实例。
  • 3.层次型体系结构风格
    • 层级系统组成一个层次结构，每一层为上一层提供服务，并作为下层的客户。
      • 在一些层次系统中，内部的层接口只对相邻的层可见，这样的系统中构件在层上实现了虚拟机。连接件由通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束，每一层最多影响两层，同时只要给相邻层提供相同的结构，允许每层用不同的方法实现，为软件重用提供了强大的支持
  • 4.客服端/服务器体系结构风格
    • 基于资源不对等，且为实现共享而提出的，
    • 两层 C/S体系结构有3个组成部分：数据库服务器，客户应用程序、网络。服务器负责数据管理，客户机完成于用户的交互任务
    • 三层C/S体系结构增加了 应用服务器，使整个应用逻辑组留在应用服务器上，只有表示层在客户机上。
      • 应用层分为：表示层，功能层和数据层
        • 表示层使应用的用户接口部分，通常使用图形用户界面
        • 功能层使应用的主体，实现具体的业务处理逻辑
        • 数据层是数据库管理系统

7.3.4 以数据为中心的体系结构风格

• 1.仓库体系结构风格
  • 仓库是存储和维护数据的中心场所。
  • 在仓库风格中，有两种不同的构件：中央数据结构说明当前的数据的状态以及一堆对中央数据进行操作的独立构件，仓库与独立构件间的相互作用在系统中会有很大的变化。
  • 这种风格的连接件即为仓库与独立构件之间的交互
• 2.黑板体系结构风格
  • 黑板体系结构风格适用于解决复杂的非结构化的问题，能在求解过程种综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易
  • 黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。
    • 它将问题的解空间组织成一个或多个应用相关的分级结构。分级结构的每一层信息有一个唯一的词汇来描述，它代表了问题的部分解。
    • 领域相关的知识被分成独立的知识模块，
    • 它将某一层次中的 信息转换成同层或相邻层的信息。各种应用通过不同知识表达方式、推理框架和控制机制的组合来实现的
  • 影响黑板系统设计的最大因素是应用问题本身的特性，但是支撑应用程序的黑板体系结构有多相似的特征和构件
  • 对于特定的应用问题，黑板系统可以通过各种黑板、知识源、控制模块的构件来设计，也可以利用预先定制的黑板体系结构的编程环境。
  • 黑板系统的传统应用是信号处理领域，如语言识别和模式识别，另一应用是松耦合代理数据共享存取
  • 

7.3.5虚拟机体系风格

• 虚拟机体系结构风格的基本思想是人为构件一个运行环境，在这个环境之上，还可以解析与运行自定义的一些语言，这样可以增加架构的灵活性。虚拟机体系结构风格主要包括解释器风格和规则系统风格

  • 1.解释器体系结构风格

    • 一个解释器通常包括完成解释工作的解析引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解析执行进度的数据结构
    • 解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。
    • 解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异，其缺点是执行效率较低，如专家系统
    • 

  • 2.规则系统体系结构风格

    • 基于规则的系统，包括规则集、规则解释器、规则/数据选择器以及工作内存
    • 

7.3.6 独立构件体系结构风格

• 独立构件风格主要强调系统中的额每个构件都是想对独立的个体，它们之间不要直接通信，以降低耦合度，提升灵活性。独立构件风格主要包括进程通信和事件系统风格
  • 1.进程通信体系结构风格
    • 在进程通信体系结构风格中，构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方法是可以是点到点、异步或同步方式以及远程过程调用等。
  • 2.事件系统体系结构风格
    • 事件系统风格基于事件的隐式调用风格的思想式构件不直接调用一个过程，而是触发或广播一个或的多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有的过程，这样，一个事件的触发就导致了另一个模块中的过程的调用
    • 从架构上说，这种风格的构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。
    • 基于事件的隐式调用的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。许多隐式调用的系统也包含显式调用作为构件交互的补充方式。
    • 事件系统应用与，编程环境中用于集成各种工具，在数据库管理系统中确保数据的一致性约束，在用户界面系统中管理数据，以及在编辑器中支持语法检查，如相应的debugger的断点事件。
    • 

7.4 软件架构复用

7.4.1 软件架构复用的定义及分类

• 软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。
  • 核心资产库包括软件架构及其可剪裁的元素，更广泛地，它还包括设计方案及其文档、用户手册、项目管理的历史记录（如预算和进度）、软件测试计划和测试用例。
  • 复用核心资产（特别是软件架构），更进一步采用产品线将会惊人地提高生产效率、减低生产成本和缩短上市时间。
• 软件复用是指系统化的软件开发过程：开发一组基本的软件构造模块，以覆盖不同的需求/体系结构之间的相似性，从而提高系统开发的效率、质量和性能。软件复用是一种系统化的软件开发过程，通过识别、开发、分类、获取和修改软件实体，以便在不同的软件开发过程中重复的使用它们
• 软件架构复用的类型包括机会复用和系统复用
  • 机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用
  • 系统复用是指开发之间，就要进行规划，以决定哪些需要复用。

7.4.2 软件架构复用的原因

• 软件架构复用可以减少开发工作，减少开发时间以及降低开发成本，提供生产力。不仅如此，还可以提供产品质量使其具有更好的互操作性。同时，软件架构复用会使产品维护变得更加简单。

7.4.3软件架构复用的对象及形式

• 基于产品件共性的软件产品线代表了软件工程中的一个创新的、不断发展的概念。软件产品线的本质使生产产品家族时，以一种规范的、策略性地方法复用资产。可复用的资产包括
  • （1）需求
    • 许多需求与早期开发的系统相同或部分相同，如网上银行交易和银行柜面交易
  • （2）架构设计
    • 原系统在架构设计方面花费了大量的时间和精力，系统已成功验证了架构的合理性，如过新产品能复用已有的结构，将会取得很好的效益
  • （3）元素
    • 元素复用不只是简单的代码复用，它旨在捕获并复用设计中的可取之处，避免设计失败的地方
  • （4）建模与分析
    • 各类分析方法（如性能分析）及各类方案模型（如容错方案、负载均衡方案）都可以在产品中得到复用
  • （5）测试
    • 采用产品线可积累大量的测试资源，即在考虑测试时不是以项目为单位，而是以产品线为单位。这样整个测试环境都可以得到复用，如测试用例、测试数据、测试工具，甚至测试计划、过程、沟通渠道都可以得到复用。
  • （6）项目规划
    • 利用经验对项目的成本、预算、进度即开发小组的安排等进行预测，即不必每次都建立工作分解结构
  • （7）过程、方法和工具
    • 有了产品线，企业就可以建立产品线级的工作流程、规范、标准、方法和工具环境，供产品线中所有产品复用。如编码标准就是个例子
  • （8）人员
    • 以产品线来培训人员，适应于整个系列的各个产品的开发
  • （9）样本系统
    • 将已部署的产品作为高质量的演示原型和工程设计原型
  • （10）缺陷消除
    • 产品线开发中积累的缺陷消除活动，可使新系统受益，特别是整个产品家族中的性能、可靠新等问题的一次性解决，能取得很高的会报。
• 一般形式的复用主要包括函数的复用，库的复用，以及再面向对象开发中的类、接口和包的复用。当前的趋势下，复用体由小粒度向大粒度的方向发展

7.4.4 软件架构复用的基本过程

• 复用的基本过程主要包括3个阶段：首先构造/获取可复用的软件资产，其次管理这些资产，最后根据特定的需求，选择可复用的资产，以开发满足需求的应用系
  • 1.获取可复用的软件资产
  • 2.管理可复用的资产
    • 该阶段最重要的是：构件库，由于对可复用的构件进行存储和管理，它是支持软件复用的必要设施。构件库中必须由足量的可复用构件才有意义。构件库应提供的主要功能包括构件的存储，管理、检索以及库的浏览和维护等，以及支持使用者有效地准确地发现所需的可复用构件
      • 关键问题
        • 构件分类，指将数据量众多的构件按照某种特定方式组织起来
        • 构件检索，是指给定几个查询需求，能够快速准确地找到相关构件
  • 3. 使用可复用的资产
    • 在最后的阶段，通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用资产；修改、扩展、配置等，最后件它们组装与集成，形成最终系统。

7.5特定领域软件体系结构

• 特定领域软件体系结构的主要目的是在一组相关的应用中共享软件体系结构

7.5.1 DSSA的定义

• DSSA 就是一个在特定应用领域中为了一组应用提供组织结构参考的标准软件体系结构。
• DSSA的必备特征如下
  • （1）一个严格定义的问题域或问题解域
  • （2）具有普遍性，使其可以用于领域中某个特定应用的开发
  • （3）对整个领域的构件组织模型的恰当抽象
  • （4）具有该领域固定的、典型的开发过程中可重用元素
• 从功能覆盖范围角度理解DSSA
  • （1）垂直域
    • 定义一个特定的系统族，包括整个整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构
  • （2）水平域
    • 定义了多个系统或多个系统族中功能区域的共有部分。在子系统即上涵盖多个系统族的特定部分功能。
• 在垂直域上定义的DSSA只能应用于一个成熟的、稳定的领域，但这个条件比较难于满足，若件领域分割成较小的范围，则相对容易

7.5.2 DSSA的基本活动

• 1.领域分析
  • 这个阶段的主要目标是获取领域模型。
  • 领域模型描述领域系统之间的共同需求，即领域模型所描述的需求为领域需求。
    • 包括定义领域的边界，从而明确分析的对象
    • 识别信息源，即整个领域工程过程中信息的来源。可能信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等。
• 2.领域设计
  • 这个阶段的主要目标是获得DSSA
  • DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，是能够适应领域中多个系统的需求的一个高层次的设计。
  • 由于领域模型的领域需求具有一定的变化性，DSSA也要具有相应的变化性，通过多选一的，可选的解决方案来实现，同时形成了重用基础设施的规约
• 3.领域实现
  • 这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息
  • 这些可重用信息可能是从现有系统中提取到的，也可能需要从新的开发得到。
  • 是领域模型和DSSA定义了这些可重用信息的重用时间，从而支持系统化的软件重用。也是重用基础设施的实现阶段。
• 以上3个过程是反复的，精益求精的过程。在实施领域工程的每个阶段中，都可能返回到以前的步骤，对以前的步骤得到的结果进行修改和完善，再回到当前步骤，在新的基础上进行本阶段的活动。

7.5.3 参与DSSA的人员

• 1.领域专家
  • 领域专家可能包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的工程师等
  • 主要任务：包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、已知的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型，DSSA等领域工程产品等。
  • 领域专家应该熟悉该领域中系统的软件设计和实现、硬件限制、未来的用户需求及技术走向等。
• 2.领域分析人员
  • 领域分析人员由具有知识工程背景的有经验的系统分析员来担任
  • 主要任务：包括控制整个领域分析过程，进行知识获取，将获取到的知识组织到领域模型中，依据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型
  • 领域分析人员应熟悉软件重用和领域分析方法，熟悉进行知识获取和知识表示所需的技术、语言和工具，具有一定的该领域的经验，以便于分析领域中的问题及领域专家进行交互；具有较高的进行抽象、关联和类比的能力，具有较高的与他人交互和合作的能力
• 3.领域设计人员
  • 领域设计人员由有经验的软件设计人员来担任
  • 主要任务：包括控制整个软件设计过程，根据领域模型和现有的系统开发出DSSA
  • 领域设计人员应属性软件重用和领域设计方法，熟悉如按难见设计方法，有一定的该领域的经验，以便分析领域中的问题及与领域专家进行交互
• 4.领域实现人员
  • 领域实现人员应由有经验的程序设计人员来担任
  • 主要任务：包括根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件间的联系
  • 领域实现人员应熟悉软件重用、领域实现及软件再工程技术；熟悉程序设计；具有一定的该领域的经验

7.5.4 DSSA建立的过程

• DSSA建立的过程分为5个阶段，每个阶段可以进一步划分为一些步骤或子阶段。每个阶段包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证的标准。本过程是并发的、递归的、反复的。或者可以说它是螺旋模型。
  • （1）定义领域范围
    • 本阶段的重点是去顶什么在感兴趣的领域中以及本过程到何时结束。
    • 主要输出是领域中的应用需要满足一系列用户的需求
  • （2）定义领域特定的元素
    • 本阶段的目标是编译领域字典和领域属于的同义词词典
    • 增加更多的细节，特别是识别领域中应用间的共同性和差异性
  • （3）定义领域特定的设计和实现需求的约束
    • 目标是描述解空间中差别的特性。
    • 不仅要识别约束，并且要记录约束对设计和实现决定造成的后果，还要记录对处理这些问题时产生的所有问题的讨论
  • （4）定义领域模型和体系结构
    • 目标是产生一般的体系结构，并说明构成它们的模块或构件的语法和语义
  • （5）产生、收集可重用的产品单元
    • 目标是为DSSA增加构件，使它可以被用来产生问题域中新应用
• DSSA的建立过程是并发的、递归的、反复进行的，该过程的目的是将用户的需求映射为基于现实限制集合的软件需求，这些需求定义了DSSA
  • 

本文参考文档：《系统架构设计师 第二版》