软件体系结构

转载自同学幕布https://mubu.com/doc/explore/26560，幕布查看更佳
软件体系结构概论
- 软件体系结构的定义
  - 软件体系结构尚处在发展期，对于其定义，目前学术界尚未形成统一意见，不同学者有不同的看法。以下介绍并分析几个具有代表性的定义。
  - 定义1
    IEEE610. 12—1990软件工程标准词汇中的定义
    - 体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即
    - 软件体系结构 = { 构件，连接件，环境，原理 }
  - 定义2
    Booch&Rumbaugh&Jacobson的定义
    - 体系结构是一系列重要决策的集合，这些决策与以下内容相关：软件的组织、构成系统的结构元素及其接口的选择，这些元素在相互协作中明确表现出的行为、这些结构元素和行为元素进一步组合构成的更大规模的子系统，和引导这一组织(包括这些元素及其接口、它们的协作、它们的组合)的体系结构风格，即
    - 软件体系结构 = { 组织，元素，子系统，风格 }
  - 定义3
    Bass的定义
    - 程序或计算系统的软件体系结构是系统的一个或多个结构，包括软件构件、构件的外部可视属性和构件之间的关系。
    - 这个定义有以下含义：首先，体系结构定义了构件，描述了构件间如何交互，这意味着体系结构略去了那些仅与某构件自身有关的信息。
    - 同时，这个定义明确指出系统可以包含多个结构，但没有其中的哪一个可以被称为是体系结构。
    - 这个定义还意味着每一个软件系统都有一个体系结构，因为每个软件系统都是由若干构件及其之间的关系构成的。
    - 此外，只要一个构件的行为可以被其他构件观察或辨明，这个构件就是体系结构的一部分。
    - 这里的外部可视属性，是指其他构件认为该构件所具备的特征，如所提供的服务、具有的性能特点、错误处理机制、共享资源的用法等。需要注意的是，此定义中，特意未指明什么是构件，什么是关系。构件既可以是对象，也可以是进程，还可以是函数库或是数据库。
  - 定义4
    Shaw的定义
    - 在第一届软件系统体系结构国际研讨会上，Mary Shaw对于当时术语使用的混乱情况予以了澄清：不同学者的软件体系结构定义之间并不相互抵触，在回答什么是软件体系结构这样的问题时，也并没有根本的冲突。
    - 实际上，它们代表了软件体系结构研究者对于体系结构研究重点的一系列不同看法。在会上，Shaw对当时的各种观点做了如下的分类。
      - 结构模型
        结构模型认为，软件体系结构由构件、构件之间的连接和一些其他方面组成这些方面包括如下几类：
        
        配置，风格
        
        约束，语义
        
        分析，属性
        
        原理，需求。
      - 框架模型
        
        框架模型的观点与结构模型相似，但其重点在于整个系统的连贯结构(这种结构通常是唯一的)，这与重视其组成恰好相反。
        
        框架模型常以某种特定领域或某类问题为目标。
      - 动态模型
        
        动态模型强调系统的行为质量
        
        “动态”可以有多种含义。它可以是指整个系统配置的变化，也可以是指禁止预先激活了的通信或交互，还可以是指计算中表现出的动态特性，如改变数据的值。
      - 过程模型
        
        过程模型关注系统结构的构建及其步骤和过程
        
        在这一观点下，体系结构是所进行的一系列过程的结果。
  - 定义5
    Garlan&Shaw的模型
    - 软件体系结构 = { 构件，连接件，约束 }
      - 构件
        
        构件(Component)可以是一组代码，如程序的模块，也可以是一个独立的程序，如数据库服务器。
        
        构件是相关对象的集合，运行后实现某计算逻辑。
        
        它们或是结构相关或是逻辑相关。
        
        构件相对独立，仅通过接口与外部相互作用，可作为独立单元嵌入到不同应用系统中。
        
        构件的定制和规范化对于实现构件的重用有重要意义。
      - 连接件
        
        连接件(Connector)可以是过程调用、管道、远程过程调用等，用于表示构件之间的相互作用，它把不同的构件连接起来构成体系结构的一部分。
        
        连接件也是一组对象。
        
        它一般表现为框架式对象或转换式对象(调用远程构件资源)，例如“桩”、“代理”对象等。
      - 约束
        
        约束(Constrain)一般为对象连接时的规则，或指明构件连接的姿态和条件。
        
        例如，上层构件可要求下层构件的服务，反之不行；两个对象不得以递归方式发送消息；代码复制迁移的一致性约束；在什么条件下此种连接无效等。
  - 定义6
    Perry&Wolf的模型
    - 软件体系结构是一组具有特定形式的体系结构元素(Elements)。
    - 这组元素分为3类
      - 负责完成数据加工的处理元素(Processing Elements)
      - 被加工的数据元素(Data Elements)
      - 连接元素(Connecting Elements)
        
        用于把体系结构的不同部分组合连接到一起的
    - 软件体系结构形式由专有特性和关系组成。
      - 专有特性用于限制软件体系结构元素的选择
      - 关系用于限制软件体系结构元素组合的拓扑结构。
    - 在多个体系结构方案中选择合适的体系结构方案往往基于一组准则，即
    - 软件体系结构={元素，形式，准则}
  - 定义7
    Garlan&Perry的定义
    - 1995年，David Garlan和Dewne Perry在IEEE软件工程学报上所做的特约评论中提出：软件体系结构是一个程序或系统各构件的结构、它们的相互关系以及进行设计的原则和指导方针，这些原则和方针随时间变化而变化。
  - 定义8
    Boehm的模型
    - 软件体系结构包括系统构件、连接件、约束的集合，反映不同人员需求的集合，以及准则的集合。
    - 其中，这些准则能够说明由构件、连接件和约束所定义的系统在实现时是如何满足系统不同人员需求的，即
    - 软件体系结构 = { 构件，连接件，约束，不同人员的需求，准则 }
    - 比较上述体系结构定义，可以发现：尽管各种定义都从不同的角度关注软件体系结构，研究对象各有侧重，但其核心内容都是软件的系统结构，并且都蕴含构件、构件之间的关系、构件和连接件之间的关系等实体。
  - 定义9
    国内普遍认可的看法
    - 体系结构 = 构件 + 连接件 + 约束
      - 软件体系结构
        
        软件体系结构指可预制和可重构的软件框架结构。
      - 构件
        
        构件是可预制和可重用的软件部件
        
        是组成体系结构的基本计算单元或数据存储单元
      - 连接件
        
        连接件也是可预制和可重用的构件部件，是构件之间的连接单元
      - 约束
        
        构件和连接件之间的关系用约束来描述
    - 除了构件、连接件和约束这3个最基本的组成元素，软件体系结构还包括端口(Port)和角色(Role)两种元素
    - 图示
      - 软件体系结构的基本概念
        
        软件体系结构∷= 软件体系模型 | 体系结构风格
        
        软件体系模型∷= { 构件，连接件，约束 }
        
        构件∷= { 端口1，端口2，…，端口ｎ }
        
        连接件∷= { 角色１，角色２，…，角色m }
        
        约束∷= { (端口i，角色j)，… }
        
        体系结构风格∷= { 管道-过滤器，层次系统，客户/服务器，…，解释器 }
    - 构件
      - 一般认为，构件是指具有一定功能、可明确辨识的软件单位
      - 构件的特点
        
        语义完整
        
        语法正确
        
        有可重用价值
      - 在结构上来看
        
        构件是语义描述、通信接口和实现代码的复合体
        
        更具体地说，可以把构件视为用于实现某种计算逻辑的相关对象的集合，这些对象或是结构相关或是逻辑相关。
        
        在体系结构中，构件可以有不同的粒度
        
        一个构件可以小到只有一个过程，也可以大到包含一个应用程序。
        
        它可以包括函数、例程、对象、二进制对象、类库、数据包等。
        
        构件内部包含了多种属性
        
        端口
        
        端口是构件与外部世界交互的一组接口
        
        构件端口说明了构件提供哪些服务(消息、操作、变量)。它定义了构件能够提交的计算委托及其用途上的约束
        
        类型
        
        构件类型是实现构件重用的手段。
        
        构件类型保证了构件自身能够在体系结构的描述中多次实例化。
        
        语义
        
        约束
        
        演化
        
        非功能属性
      - 从抽象程度来看
        
        构件是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口
        
        构件之间是相对独立的
        
        构件隐藏其具体实现，只通过接口提供服务
        
        如果不用指定的接口与之通信，则外界不会对它的运行造成任何影响
        
        因此，构件可以作为独立单元被应用于不同的体系结构和软件系统中，实现构件的重用。构件的使用与它的开发也是独立的。
    - 连接件
      - 连接件是用来建立构件间的交互以及支配这些交互规则的体系结构构造模块
        
        构件之间的交互
        
        消息
        
        信号量的传递
        
        功能或方法调用
        
        数据的传送和转换
        
        构件之间的同步关系
        
        依赖关系等
      - 在最简单的情况下，构件之间可以直接完成交互，这时体系结构中的连接件就退化为直接连接
      - 在比较复杂的情况下，构件间交互的处理和维持都需要连接件来实现
      - 常见的连接件
        
        管道(在管道-过滤器结构中)
        
        通信协议或通信机制(在客户/服务器结构中)等
      - 角色
        
        连接件的接口由它与所连接构件之间的一组交互点构成，这些交互点称做角色。
        
        角色代表了所连接构件的作用和地位，并体现了连接所具有的方向性
        
        因此，角色存在主动和被动、请求和响应之分
      - 体系结构级的通信需要有复杂协议来表达，为了抽象这些协议并使之能够重用，可以将连接件构造为类型。
      - 连接件的主要特性
        
        可扩展性
        
        连接件的可扩展性是连接件允许动态改变被关联构件的集合和交互关系的性质。
        
        互操作性
        
        互操作性指的是被连接的构件通过连接件对其他构件进行直接或间接操作的能力。
        
        动态连接性
        
        动态连接性是对连接的动态约束，即连接件对于不同的所连接构件实施不同的动态处理方法的能力。
        
        请求响应特性
        
        请求响应特性包括响应的并发性和时序性。
      - 在并行和并发系统中，多个构件有可能并行或并发地提出交互请求，这就要求连接件能够正确协调这些交互请求之间的逻辑关系和时序关系。
      - 对于构件而言，连接件是构件的黏合剂，是构件交互的实现。
      - 连接件和构件的区别
        
        主要在于它们在体系结构中承担着不同的作用。
      - 连接件也是一组对象
        
        它把不同的构件连接起来，形成体系结构的一部分，一般表现为框架式对象或转换式对象(调用远程构件资源)。
    - 约束
      - 体系结构的约束描述了体系结构配置和拓扑的要求，确定了体系结构的构件与连接件的连接关系
      - 它是基于规则和参数配置的
      - 体系结构约束提供限制以确定构件是否正确连接、接口是否匹配、连接件构成的通信是否正确，并说明实现所要求行为的组合语义
      - 体系结构往往用于大型的、生存期长的软件系统的描述。
      - 为了更好地在一个较高的抽象层上理解系统的分析和设计，同时为了方便系统开发者、使用者等多种有关人员之间的交流，需要简单的、可理解的语法来配置结构化(拓扑的)信息。
      - 理想的情况是从约束说明中澄清系统结构
        
        即不需研究构件与连接件就能使构件系统的各种参与者理解系统。
- 软件体系结构的研究意义
  - 软件体系结构是软件系统的高级抽象，往往体现了系统开发中最早做出的决策
  - 它体现了根本性的系统设计思路，对系统起着最为深远的影响
  - 体系结构在明确了系统的各个组成部分的同时，也限定了各部分间的交互方式
    - 这将进一步影响到开发资源的配置和开发团队的组织等其他方方面面的开发活动，并影响着最终的软件产品质量。
    - 在大型软件系统中，软件体系结构是决定系统能否顺利实现的关键因素之一，不当的体系结构会给整个系统带来灾难性的后果。
    - 良好的体系结构对于软件系统的重要意义在软件生命周期中的各个阶段都有体现
      - 对系统分析的意义
        
        在系统分析阶段，软件体系结构发挥着巨大作用。
        
        一方面
        
        借助于软件体系结构进行描述，可以使问题得以进一步抽象，使整个系统更易于被系统分析设计人员把握，更清晰地认识系统，完善对系统的理解。
        
        除此之外，体系结构对于系统分析带来的优势还体现在，它为系统分析设计人员提供了新的思路。
        
        比如，在更高层次上进行系统一致性检查、使用成熟的软件体系结构风格等。
        
        另一方面
        
        它能够帮助软件系统的各有关权益方(客户、用户、项目管理人员、设计开发人员以及测试人员等)形成统一认识，互相交流。
        
        交流是软件开发的重要组成部分。
        
        在软件开发活动中，各有关权益方承担着不同角色，关注同一软件系统不同的侧面，这要求他们要从不同的角度交流对共同面对的软件系统的认识。
        
        例如
        
        用户关心系统是否满足可用性及可靠性需求
        
        客户关心此结构能否按期按预算实现
        
        管理人员担心在经费支出和进度条件下，按此体系结构能否使开发组成员在一定程度上独立开发，并有条不紊地有序地交互
        
        开发人员关心达到全部目的的策略。
      - 对软件开发的意义
        
        软件体系结构代表了系统早期的设计决策
        
        与开发、设计、编码或运行服务及维护阶段相比，早期设计决策的处理难度最大，对系统的生命期的影响也最大
        
        同时，软件体系结构也难于改变，会对整个系统开发活动造成深远影响。
        
        软件体系结构是系统实现的基本约束
        
        即系统的后继开发工作要遵循体系结构所描述的设计决策。
        
        每个构件或连接件必须满足体系结构规格说明中指定的功能、语义和接口，并且按体系结构配置中所规定的方式完成交互。
        
        这样，构件或连接件的开发人员在体系结构给定的约束下进行工作，他们既不关心其他构件或连接件的开发，也不会对其产生影响。
        
        而体系结构设计者也不必设计算法或精通编程语言。
        
        软件体系结构决定了开发和维护项目的组织活动
        
        软件体系结构也会反映到开发工作的分解，以及项目的人员组织。
        
        项目组成员还要使用构件的接口规格说明相互交流。
        
        即使到了维护期，项目维护人员的组织形式也常常要依据特定的软件体系结构成分来安排。
        
        此外，对于项目组新成员，可以用软件体系结构作为培训基础或高层次的系统概述，使他们迅速、准确地认识系统和自己的任务，快速进入开发角色。
        
        软件体系结构对于软件质量控制有重要意义
        
        软件质量特性可分为两类
        
        第一类是可以通过运行软件并观察其效果来度量的特性
        
        如功能、性能、安全性及可靠性等
        
        第二类是指那些无法通过观察系统来度量，只能通过观察开发活动或维护活动来考察的特性
        
        包括各种可维护性问题
        
        如可适应性、可移植性、可重用性等
        
        (例如，可重用性依赖于系统中的构件与其他构件的联系情况)。
        
        软件体系结构在很大程度上确定了系统是否能达到其需求的质量特性
      - 对软件重用的意义
        
        重用是提高软件开发效率、保证软件质量的重要手段
        
        软件开发经历了从机器语言、汇编语言、结构化程序设计语言、面向对象程序设计语言、形式化(非形式化)规格说明语言(如体系结构描述语言)的发展过程，越来越适合开发人员的思维活动模型，代码重用的级别也在不断地提升
        
        体系结构技术的研究，使软件重用从代码重用发展到设计重用和过程重用，实现多层次的软件重用。
        
        构件的重用是体系结构良好的软件系统最基本的一点
        
        面向体系结构的开发方法常常注意构件的组合与装配，而不一定把编程作为主要活动。
        
        有效地利用标准构件，或是识别并重用系统内部的构件，或是购买第三方构件，只要这些构件与当前体系结构相容，都能减少开发中的重复劳动和系统中的重复代码。
        
        体系结构起了组织产品的构件、接口及运行的作用。这里要着重指出的是标准构件的应用。应用标准构件库的关键在于要能够从整体上对库中构件进行把握。
        
        一旦做到了这点，就可以快速、灵活地在构件库中选择出合适的构件应用到系统中去；反之，构件的选取就只能通过反复地浏览来寻找，这实际上影响到了体系结构所带来的优势，造成了不必要的资源浪费。
        
        不仅构件库能够重用，还可以在更高层次上实现软件子系统乃至软件系统框架的重用
        
        软件体系结构级的重用意味着体系结构的决策能在具有相似需求的多个系统中发生影响，这比代码级的重用要有更大的好处。
        
        通过对体系结构的抽象可以使设计者能够对一些实践证明有效的体系结构构件进行重用，从而提高设计效率和可靠性。
        
        在设计过程中我们常常会发现，对一个体系结构构件稍加抽象，就可以将它应用到其他设计中去，这样会大大降低设计的复杂度。
        
        例如
        
        我们在某个设计中采用了管道-过滤器风格，当我们将系统映射到Unix系统中时，我们就会发现Unix系统已经为我们提供了功能丰富的管道-过滤器功能，这样我们就可以充分利用Unix系统提供的这些构件来简化我们的设计和开发。
        
        当前，针对特定领域的体系结构，人们开展了许多研究和实践工作。这在某种意义上也是一种重用。
        
        软件重用的层次越高，所带来的收益也就越大
        
        某些情况下，重用的设计方案本身也许不是最适合该系统的，但是从整体上权衡，通过重用带来的成本节约和质量提供能够让重用变得非常值得
      - 对系统演化的意义
        
        对软件系统的演化过程中，维护人员需要不断地进行调整、修改、增加新的功能或构件等工作
        
        通常情况下，软件系统的开发成本中，有80%是在初次投入使用之后产生的
        
        因此，解决好系统演化阶段的开发问题具有重要意义
        
        软件体系结构决定着系统构件的划分和交互方式
        
        一方面
        
        在设计系统的体系结构之初，就应当充分考虑到将来可能的系统演化
        
        另一方面
        
        在进行系统演化阶段的开发时，由于体系结构充分地刻画了当前系统，清晰地描述了构件及其相互关系和整个系统的框架，所以应当充分利用。
        
        以现有体系结构为基础，把握需要进行的系统变动，在系统范围内综合考虑，有助于确定系统维护的最优方案，更好地控制软件质量和维护成本
        
        软件为主的系统总是存在着“利用软件作为增加或修改系统总体功能的工具”的倾向。
        
        重要的是要决定何时进行改动，确定哪种改动风险最小，评估改动的后果，仲裁改动的顺序及优先级。
        
        所有这些都需要深入地洞察系统各部分的关系、相互依存关系、性能及行为特性。
        
        而在软件体系结构这一级进行讨论，就能提供这种观察力，更重要的是软件体系结构可以把可能发生的变动分为3类
        
        局部的
        
        局部的是指只要修改单个构件本身
        
        非局部的
        
        非局部的是指要修改几个构件，但不影响基础体系结构的变动
        
        体系结构级的
        
        而体系结构级是指会影响各部分的相互关系，甚至要改动整个系统
        
        显然，局部改动应是最经常发生的，也是最容易进行的。
        
        软件体系结构承担了“保证最经常发生的变动是最容易进行的”这一重任。
- 软件体系结构的发展历程
  - 软件工程作为一门独立的学科，其发展已逾30年。
  - 无论从应用规模还是从技术水平看，计算机软件产业所经历的发展都是迅猛的。
  - 这体现在诸多方面。
    - 首先，软件系统的应用领域从实验室渗透到了人类社会的各个角落。
      - 最初的软件是以穿孔纸带或卡片的形式出现在实验室和机房中用于科学计算的；
      - 而在今天的人类社会中，各种软件系统运行在从手持设备(如手机)到大型机(如进行天气预报的服务器)的各种规模和用途的信息处理设备上。
    - 其次，软件系统的规模也迅速增长
      - 从微机不断跃增的内存配置就可以明显看出这一点
        
        1981年，IBM公司推出的第一台PC机的配置是16 KB的内存
        
        2003年，主流PC机的内存配置是256 MB
        
        2008年，主流PC机的内存配置是2 GB
    - 此外，随着计算机产业的发展，软件成本也在增长
      - 20世纪50年代，软件成本在整个计算机系统成本中所占的比例为10%～20%
      - 到20世纪60年代中期，软件成本在计算机系统中所占的比例已经增长到50%左右
      - 相反，计算机硬件价格随着技术进步和生产规模扩大却在不断下降
      - 软件成本在计算机系统中所占的比例越来越大。
        
        下面是一组来自美国空军计算机系统的数据
        
        1955年，软件费用约占总费用的18%
        
        1970年达到60%
        
        1975年达到72%
        
        1980年达到80%
        
        1985年达到85%左右
    - 在软件应用规模和应用领域迅速扩大的同时，软件开发技术也在发生着根本性的变革。
      - 软件规模的迅速增长使得软件开发成为了一项过去难以想象的系统工程
        
        根据微软公司公布的数据
        
        Windows 2000开发过程中测试用代码行数超过1000万行
        
        测试兼容性的应用软件数量约1000种
        
        应用软件测试中所使用的脚本程序约6500种
        
        每月备份的数据约 88 TB
        
        每晚模拟打印数量约25万页
        
        每周刻录CD约12 000盘。
    - 在此过程中，软件体系结构也经历了与之相对应的一系列变革，由最初的模糊概念发展成为一门日益成熟的技术。下面我们分阶段进行讨论。
      - “无体系结构”设计阶段
        
        1946年，随着具有里程碑意义的ENIAC机的问世，软件行业开始在美国和欧洲的实验室出现。
        
        1955～1965年间，运算速度越来越快、价格越来越低的新计算机不断涌现。
        
        这期间的软件多数应用于学术界，或者是政府、军队及私人公司。
        
        但是，由于当时的计算机硬件向着专用方向发展，科学与商业领域使用完全不同的机器硬件。
        
        不断地针对不同计算机编写软件让软件工作人员应接不暇，反复地开发相同或类似的软件使得软件研究者开始着手处理软件的移植问题，即设法使一种机器的汇编语言程序能够自动移植到另一台机器上去。
        
        但研究人员很快发现这难以实现，大量复杂代码仍必须由程序员进行改写。
        
        在这样的背景下，高级语言应运而生。
        
        FORTRAN语言诞生于20世纪50年代中期，是最早发布的高级语言
        
        50年代后期，COBOL语言出现
        
        60年代早期，ALGOL语言出现
        
        而在当时，高级语言不能被程序编制人员所接受，他们认为真正的程序员应使用汇编语言。
        
        总的说来
        
        20世纪70年代以前，尤其是在以ALGOL 68为代表的高级语言出现以前，软件开发基本上都是用汇编程序设计。
        
        尽管此阶段软件工作者开始逐渐形成模块编程的方法，但软件投入的资金和人力无法预测，软件完工的时间无法确定，软件的可靠性无法控制等问题开始表露出来，软件危机从此阶段开始出现。
        
        一个著名的例子是1962年7月美国飞往金星的火箭控制系统中的指令，“DO 5 I=1, 3”误写成“DO 5 I=1.3”，导致火箭偏离轨道，被迫炸毁。
        
        因为此阶段系统规模较小，很少明确考虑软件体系结构，所以一般不存在软件系统的建模工作。
      - 萌芽阶段
        
        在1968年NATO会议上，“软件工程”的概念首次被提出。
        
        自此，围绕软件项目，开展了有关开发模型、方法以及支持工具的研究。
        
        其主要成果有：提出了瀑布模型，开发了一些结构化程序设计语言(例如PASCAL语言、Ada语言)，结构化软件开发技术，并且围绕项目管理提出了费用估算、文档复审等方法和工具。
        
        结构化软件开发技术在20世纪70年代中后期出现
        
        以PASCAL、COBOL等程序设计语言和关系数据库管理系统为标志，以强调数据结构、程序模块化结构为特征，采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。
        
        随着结构化开发技术的出现与广泛应用，软件开发中出现了以数据流设计和控制流设计为主要任务的概要设计和详细设计
        
        伴随着结构化软件技术而出现的软件工程方法(包括CASE工具)，使软件工作的范围从只考虑程序的编写扩展到从定义、编码、测试到使用、维护等活动的整个软件生命周期。
        
        总的说来，在此阶段，软件体系结构已经是系统开发中的一个明确概念。
        
        结构化程序中，由语句构成模块，模块的聚集和嵌套又构成层层调用的高层结构。
        
        这种程序(表达)结构和(计算的)逻辑结构的一致性形成了结构化程序的体系结构。
        
        结构化程序设计时代程序规模不算大，同时，采用结构化程序设计方法进行自顶向下逐步求精的设计，并注意模块的耦合性，就可以得到相对良好的结构。
        
        因此，体系结构问题并不是当时软件开发中的主要问题，也就没有开展深入的研究工作。
      - 初级阶段
        
        20世纪80年代初，面向对象开发技术逐渐兴起。
        
        随着面向对象技术成为研究的热点，出现了几十种支持软件开发的面向对象方法。
        
        其中，Booch、Coad/Yourdon、OMT和Jacobson的方法在面向对象软件开发界得到了广泛的认可。
        
        面向对象开发技术以对象作为最基本的元素，将软件系统看成是离散的对象的集合。一个对象既包括数据，也包括行为。
        
        面向对象方法都支持3种基本的活动
        
        识别对象和类
        
        描述对象和类之间的关系
        
        通过描述每个类的功能定义对象的行为
        
        对象技术的优点
        
        它能让分析者、设计者及用户更清楚地表达概念，相互交流
        
        同时，它作为描述、分析和建立软件文档的一种手段，大大提高了软件的易读性、可维护性、可重用性
        
        使得从软件分析到软件设计的过渡非常自然，因此可显著降低软件开发成本。
        
        另外，面向对象技术中的继承、封装、多态性等机制，直接为软件重用提供了进一步的支持。
        
        在面向对象开发方法阶段，由于对象是对数据及其操作的封装，因而数据流设计与控制流设计统一为对象建模。
        
        面向对象方法还提出了一些其他的结构视图
        
        OMT方法提出了功能视图、对象视图和动态视图
        
        Booch方法提出了类视图、对象视图、状态迁移图、交互作用图、模块图、进程图，UML则从功能模型、静态模型、动态模型、配置模型等方面描述应用系统的结构。
        
        从1994年开始，Booch、Rumbaugh和Jacobson三人经过共同努力，推出了统一建模语言UML(Unified Modeling Language)。
        
        它结合了Booch、OMT和Jacobson方法的优点，统一了符号体系，并从其他的方法和工程实践中吸收了许多经过实际检验的经验和技术。
        
        对象管理组织OMG于1997年11月正式采纳UML1.1作为建模语言规范，然后成立任务组不断修订。
        
        尽管UML取得了巨大成功，但仍然有一些批评意见。工业界的批评主要是，它的庞大和复杂使得多数用户难以实际应用或只能应用少许概念。
        
        学术界的批评则主要针对它在理论上的缺陷和错误，包括语言体系结构、语法、语义等方面的问题。
        
        随着抽象数据类型和面向对象技术的出现，体系结构研究逐渐得到重视。
        
        这是由以下因素决定的
        
        对象的封装减低了模块间的耦合，为构件层次上的软件重用提供了可能
        
        此外，类库的构造、分布式应用系统的设计等规模大、复杂性高的系统，也需要对体系结构进行研究
      - 高级阶段
        
        20世纪90年代后，软件开发技术进入了基于构件的软件开发阶段
        
        软件开发的目标是软件具备很强的自适应性、互操作性、可扩展性和可重用性，软件开发强调采用构件化技术和体系结构技术。
        
        软件构件技术与面向对象技术有着重要的不同。
        
        面向对象技术中的软件重用主要是源代码形式的重用，这要求设计者在重用软件时必须理解其设计思路和编程风格。
        
        软件构件技术则实现了对软件的最终形式——可执行二进制码的重用。
        
        这样，构件的实现是完全与实现语言无关的。
        
        任何一种过程化语言，从Ada到C到Java到C#，均可用来开发构件，并且任何一种程序设计语言都可以直接或稍作修改后使用构件技术。
        
        一个软件可被切分成一些构件，这些构件可以单独开发、单独编译，甚至单独调试与测试。
        
        当完成了所有构件的开发，再对它们加以组合，就得到了完整的软件系统。在投入使用后，不同的构件还可以在不影响系统的其他部分的情况下，分别进行维护和升级。
        
        此阶段中，软件体系结构逐渐成为软件工程的重要研究领域，并最终作为一门学科得到了业界的普遍认同。
        
        在基于构件和体系结构的软件开发方法下，程序开发模式也相应地发生了根本变化。
        
        软件开发不再是“算法+数据结构”，而是“构件开发+基于体系结构的构件组装”。
        
        软件体系结构作为开发文档和中间产品，开始出现在软件过程中。
        
        有研究人员认为，“未来的年代将是研究软件体系结构的时代”。
      - 综合
        
        从软件技术的发展过程可以看出，在各个时期，软件体系结构的问题实际上总是存在的，但是它是随着软件系统的规模和复杂性的日益膨胀才逐渐表露、被人们发现和研究的。
        
        软件体系结构技术大致经历了以下4个阶段
        
        “无体系结构”设计阶段
        
        开发主要采用汇编语言，规模一般较小
        
        萌芽阶段
        
        主要采用结构化的开发技术
        
        初级阶段
        
        主要采用面向对象的开发技术，从多种角度对系统建模(如UML)
        
        高级阶段
        
        该阶段以Kruchten提出的“4+1”模型为标志
        
        软件开发的中心是描述系统的高层抽象结构模型
        
        相比之下，传统的软件结构更关心具体的建模细节
        
        软件体系结构技术仍存在诸多问题，如概念定义尚不统一、描述规范不能一致等。
        
        有研究人员认为在软件开发实践中软件体系结构尚不能发挥重要作用，软件体系结构技术仍有待研究、发展和完善。
- 软件体系结构的研究现状及发展方向
  - 软件体系结构的研究现状
    - 软件体系结构作为软件工程研究领域的一部分，已经取得了长足的发展，受到大多数软件系统设计和研究人员的重视。
    - 但当前，体系结构仍是一个处在不断发展中的新研究领域，许多定义还不够统一，归纳现有体系结构的研究活动，主要的讨论和研究大致集中在以下几个方面。
      - 软件体系结构描述研究
        
        构建软件体系结构的目的之一就是建立一个可供各种人员交流的平台，并且要具备系统架构级的可重用性。
        
        因此如何恰当、准确地对软件体系结构进行描述是至关重要的。
        
        这种描述应当能够为各种人员提供不同的视图以满足其不同的要求
        
        同时，当要构建新的应用或对应用进行系统级更改时，这种描述应该能够快速提供可重用的系统架构视图或系统模块视图。
        
        这方面的研究包括软件体系结构描述语言、使用“4+1” 模型描述软件体系结构、使用UML描述软件体系结构等方面的研究。
        
        软件体系结构描述语言
        
        现有的一些软件体系结构描述方法采用非形式化的方法，体系结构设计经常难以理解，难以对体系结构进行形式化分析和模拟，缺乏相应的支持工具帮助设计师完成设计工作。为了解决这个问题，用于描述和推理的形式化语言得以发展，这些语言就叫做体系结构描述语言(Architecture Description Language，ADL)，ADL寻求增加软件体系结构设计的可理解性和重用性。
        
        ADL是这样一种语言，系统设计师可以利用它所提供的特性进行软件系统概念体系结构建模
        
        ADL提供了具体的语法与刻画体系结构的概念框架
        
        它使得系统开发者能够很好地描述他们设计的体系结构，以便与他人交流，能够用提供的工具对许多实例进行分析
        
        使用“4+1” 模型描述软件体系结构
        
        按照一定的描述方法，用体系结构描述语言对体系结构进行说明的结果称为体系结构的表示，而将描述体系结构的过程称为体系结构构造。
        
        在体系结构描述方面，Kruchten提出的“4+1”模型是当前软件体系结构描述的一个经典范例，该模型由逻辑视图、开发视图、过程视图和物理视图组成，并通过场景将这4个视图有机地结合起来，比较细致地描述了需求和体系结构之间的关系。
        
        “4+1”模型实际上使得有不同需求的人员能够得到他们对于软件体系结构想要了解的东西。
        
        系统工程师先从物理视图，然后从过程视图靠近体系结构。
        
        最终使用者、客户、数据专家从逻辑视图看体系结构；项目经理、软件配置人员从开发视图看体系结构。
        
        使用UML描述软件体系结构
        
        Booch从UML的角度给出了一种由设计视图、过程视图、实现视图和部署视图，再加上一个用例视图构成的体系结构描述模型。
        
        Medividovic则总结了用UML描述体系结构的三种途径：不改变UML用法而直接对体系结构建模；利用UML支持的扩充机制扩展UML的元模型对体系结构建模概念的支持；对UML进行扩充，增加体系结构建模元素
        
        UML的静态建模机制包括用例图、类图、对象图、包、构件图和部署图。
        
        UML的动态建模机制包括顺序图、协作图、状态图和活动图。
        
        可以使用UML对构件交互模式进行静态建模和动态建模。
      - 软件体系结构设计研究
        
        体系结构风格研究
        
        体系结构设计研究的重点内容之一就是体系结构风格的研究。
        
        人们在开发不同系统时，会逐渐发现一类系统的体系结构上有许多共性，于是抽取出这些共性构成一些富有代表性和被广泛接受的体系结构风格。
        
        所以说体系结构风格是用来刻画具有相似结构和语义性质的一类系统族的。
        
        它定义一组构件、连接件的类型以及它们之间应该如何连接的约束。
        
        一般来说，一个系统不一定只具有一种风格，在不同层次或抽象级别上，可具有多种风格。
        
        虽然系统组织方式可以是无穷的，但如果能用少量的风格类型表达出较多的系统组织方式，不仅可以缩短系统分析设计的时间，还能大大提高大规模软件重用的机会。
        
        Garlan和Shaw给出了对通用体系结构风格的分类：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
        
        体系结构设计原理
        
        参照软件工程、结构化程序设计和面向对象程序设计原理，结合软件体系结构设计本身的特点
        
        可以总结出软件体系结构设计过程中用到的原理主要有以下几个：抽象、封装、信息隐藏、模块化、注意点分离、耦合和内聚、接口和实现分离、分而治之、层次化等。
        
        设计模式
        
        设计模式的概念最早是由美国的一位叫做Christopher Alexander的建筑理论家提出来的，他试图找到一种结构化、可重用的方法，以在图纸上捕捉到建筑物的基本要素。
        
        后来被作为总结软件设计，特别是面向对象设计的实践和经验而提出。
        
        在几十年的软件设计研究和实践中，设计人员和程序员积累了大量的实际经验，发现并提出了大量在众多应用中普遍存在的软件结构和结构关系，模式被用于软件体系结构设计中。
        
        利用设计模式可以方便地重用成功的设计和结构。
        
        把已经证实的技术表示为设计模式，使它们更加容易被新系统的开发者所接受。
        
        设计模式帮助设计师选择可使系统重用的设计方案，避免选择危害到可重用性的方案。
        
        设计方法研究
        
        生成一个满足软件需求的体系结构的过程即为体系结构设计。
        
        体系结构设计过程的本质在于：将系统分解成相应的组成成分(如构件、连接件)，并将这些成分重新组装成一个系统。
        
        常用的体系结构设计方法有4类，分别为制品驱动(artifact-driven)的方法，用例驱动(use-case-driven)的方法，模式驱动(pattern-driven)的方法和领域驱动(domain-driven)的方法。
        
        每种方法在过程的顺序上、在概念的特定内容上有所不同，但最后都生成对体系结构的描述。
      - 基于体系结构的软件开发方法
        
        本质上，软件体系结构是对软件需求的一种抽象解决方案。
        
        在引入了体系结构的软件开发中，应用系统的构造过程变为“问题定义→软件需求→软件体系结构→软件设计→软件实现”，可以认为软件体系结构架起了软件需求与软件设计之间的一座桥梁。
        
        而在由软件体系结构到实现的过程中，借助一定的中间件技术与软件总线技术，软件体系结构易于映射成相应的实现。
        
        Bass等人提出了一种基于体系结构的软件开发过程，该过程包括6个步骤：导出体系结构需求；设计体系结构；文档化体系结构；分析体系结构；实现体系结构；维护体系结构。
        
        软件开发模型是跨越整个软件生存周期的系统开发、运行、维护所实施的全部工作和任务的结构框架，给出了软件开发活动各阶段之间的关系。
        
        目前，常见的软件开发模型大致可分为3种类型
        
        以软件需求完全确定为前提的瀑布模型。
        
        在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型等。
        
        以形式化开发方法为基础的变换模型。
      - 软件体系结构评估
        
        软件体系结构的设计是整个软件开发过程中关键的一步。
        
        对于当今世界上庞大而复杂的系统来说，没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。
        
        不同类型的系统需要不同的体系结构，甚至一个系统的不同子系统也需要不同的体系结构。
        
        体系结构的选择是一个软件系统设计成败的关键。
        
        常用的软件体系结构评估方法有软件体系结构分析方法(Software Architecture Analysis Method，SAAM)和体系结构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)。
        
        它们都是基于场景的软件体系结构评估方法，这类评估方法分析软件体系结构对场景也就是对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。
        
        例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。
        
        SAAM本质上是一个寻找受场景影响的体系结构元素的方法，而ATAM建立在SAAM基础上，关注对风险、非风险、敏感点和权衡点的识别。
      - 特定领域的体系结构框架
        
        特定领域的应用通常具有相似的特征，如果能够充分挖掘系统所在领域的共同特征，提炼出领域的一般需求，抽象出领域模型，归纳总结出这类系统的软件开发方法，就能够指导领域内其他系统的开发，提高软件质量和开发效率、节省软件开发成本。
        
        正是基于这种考虑，人们在软件的理论研究和工程实践中，逐渐形成一种称之为特定领域的软件体系结构(Domain Specific Software Architecture，DSSA)的理论与工程方法，它对软件设计与开发过程具有一定参考和指导意义，已经成为软件体系结构研究的一个重要方向。
        
        Rick Hayers-Roth和Will Tracz分别对DSSA给出了不同的定义
        
        前者侧重于DSSA的特征，强调系统由构件组成，适用于特定领域，有利于开发成功应用程序的标准结构
        
        后者侧重于DSSA的组成要素，指出DSSA应该包括领域模型、参考需求、参考体系结构、相应的支持环境或设施、实例化、细化或评估的方法与过程
        
        两种DSSA定义都强调了参考体系结构的重要性。
        
        特定领域的体系结构是将体系结构理论应用到具体领域的过程
        
        用户界面工具和框架
        
        可以为开发者提供可重用框架以及像菜单、对话框等可重用构件的集合
        
        编译器的标准分解
        
        体系结构的重用能使语言编译系统的开发变得非常简单
        
        标准化的通信协议
        
        通过在不同层次的抽象上提供服务，可实现跨平台的交互
      - 软件体系结构支持工具
        
        几乎每种体系结构都有相应的支持工具，
        
        如UniCon、Aesop等体系结构支持环境
        
        C2的支持环境ArchStudio
        
        Acme的支持环境AcmeStudio
        
        支持主动连接件的Tracer工具等
        
        另外，还出现了很多支持体系结构的分析工具
        
        如支持静态分析的工具
        
        支持类型检查的工具
        
        支持体系结构层次依赖分析的工具
        
        支持体系结构动态特性仿真工具
        
        体系结构性能仿真工具
        
        但与其他成熟的软件工程环境相比，体系结构设计的支持工具还很不成熟，难以实用化。
        
        本书通过两个较为著名的软件体系结构集成开发环境ArchStudio4和AcmeStudio，介绍软件体系结构集成开发环境的具体功能。
  - 软件体系结构的发展方向
    - 各种软件体系结构语言之间的信息互换
      - 现有的各种软件体系结构描述语言大多是与领域相关的，所以不利于对不同领域体系结构的说明。但这些针对不同领域的软件体系结构描述语言在某些方面又大同小异，造成资源的冗余。
      - 其实，大多数软件体系结构描述语言具有一系列共同概念。
      - 如何用一种公共形式把各种语言综合起来，使得能够交换各种体系结构描述信息，将是今后软件体系结构研究和实践的重点之一。
    - 设计工具和环境
      - 软件体系结构设计作为软件工程的一部分，它的计算机辅助实现手段是相当重要的。
      - 应当开发出一些软件工具来实现体系结构的描述和分析，开发阶段转换工具可以实现阶段成果的自动转换，例如，把需求规格说明自动转换为构件等。
      - 目前关于这方面的研究成果很少，特别是可以应用到实际项目开发中的工具和环境就更少。
    - 体系结构再工程问题
      - 现在软件系统的规模变得越来越大，结构也越来越复杂，同时从头开始构建的大系统数量在急剧地减少，因而很多遗留系统正在被逐步地利用。
      - 从遗留系统软件代码和系统中抽取结构信息，经过描述、统一、抽象、一般化与实例化等处理，可总结出系统的体系结构。
软件体系结构的风格与模式
- 软件体系结构风格和模式的概念
  - 软件体系结构风格
    Architectural Style
    - 一种体系结构风格以结构组织模式定义了一个系统家族
    - 关于构件和连接件类型的术语；一组约束对它们组合方式的规定；一个或多个语义模型，规定了如何从各成分的特性决定系统整体特性
    - 概括地说，一种软件体系结构风格刻划一个具有共享结构和语义的系统家族
  - 软件体系结构模式
    Architectural Pattern
    - 一种软件体系结构模式是对某个具体环境下问题的结构性解决方法
- 软件体系结构的构建风格
  体系结构风格不是对软件进行分类的标准它仅仅是表示描述软件的不同角度而已例如，一个系统采用了分层风格，但这并不妨碍它用面向对象的方法来实现。同一个系统采用多种风格造成了所谓体系结构风格的异构组合。
  - 管道-过滤器风格
    - 概述
      - 在管道-过滤器风格下，每个功能模块都有一组输入和输出
        
        功能模块称作过滤器（filters）
        
        功能模块间的连接可以看作输入、输出数据流之间的通路，所以称作管道（pipes）。
      - 管道-过滤器风格的特性之一在于过滤器的相对独立性，即过滤器独立完成自身功能，相互之间无需进行状态交互。
    - 过滤器是独立运行的构件
      - 非临近的过滤器之间不共享状态
    - 过滤器自身无状态
      - 过滤器对其处理上下连接的过滤器“无知”
    - 对相邻的过滤器不施加任何限制
      - 结果的正确性不依赖于各个过滤器运行的先后次序
      - 各过滤器在输入具备后完成自己的计算。
      - 完整的计算过程包含在过滤器之间的拓扑结构中。
    - 一个管道-过滤器风格的图示
    - 一个采用了嵌套的管道过滤器的系统示例
    - 实例
      - Unix系统中的管道过滤器结构
        
        ls –al | grep my
      - DOS 中的管道命令
        
        DOS允许在命令中出现用竖线字符“|”分开的多个命令，将符号“|”之前的命令的输出，作为“|”之后命令的输入，这就是“管道功能”，竖线字符“|”是管道操作符。
        
        例如
        
        命令dir | more使得当前目录列表在屏幕上逐屏显示。dir的输出是整个目录列表，它不出现在屏幕上而是由于符号“|”的规定，成为下一个命令more的输入，more命令则将其输入，more命令则将其输入一屏一屏地显示，成为命令行的输出。
    - 优点
      - 设计者可以将整个系统的输入、输出特性简单的理解为各个过滤器功能的合成
        
        设计人员将整个系统的输入输出行为理解为单个过滤器行为的叠加与组合。
        
        这样可以将问题分解，化繁为简。
        
        将系统抽象成一个“黑箱”，其输入是系统中第一个过滤器的输入管道，输出是系统中最后一个过滤器的输出管道，而其内部各功能模块的具体实现对用户完全透明。
      - 支持功能模块的复用
        
        任何两个过滤器，只要它们之间传送的数据遵守共同的规约，就可以相连接。
        
        每个过滤器都有自己独立的输入输出接口，如果过滤器间传输的数据遵守其规约，只要用管道将它们连接就可以正常工作。
      - 系统具有较强的可维护性和可扩展性
        
        旧的过滤器可以被替代，新的过滤器可以添加到已有的系统上。
        
        软件的易于维护和升级是衡量软件系统质量的重要指标之一，在管道-过滤器模型中，只要遵守输入输出数据规约，任何一个过滤器都可以被另一个新的过滤器代替，同时为增强程序功能，可以添加新的过滤器。
        
        这样，系统的可维护性和可升级性得到了保证。
      - 支持一些特定的分析
        
        如吞吐量计算和死锁检测等
        
        利用管道-过滤器风格的视图，可以很容易的得到系统的资源使用和请求的状态图。
        
        然后，根据操作系统原理等相关理论中的死锁检测方法就可以分析出系统目前所处的状态，是否存在死锁可能及如何消除死锁等问题。
      - 具有并发性
        
        每个过滤器作为一个单独的执行任务，可以与其它过滤器并发执行。
        
        过滤器的执行是独立的，不依赖于其它过滤器的。在实际运行时，可以将存在并发可能的多个过滤器看作多个并发的任务并行执行，从而大大提高系统的整体效率，加快处理速度。
    - 缺点
      - 交互式处理能力弱
        
        管道-过滤器模型适于数据流的处理和变换，不适合为与用户交互频繁的系统建模。
        
        在这种模型中，每个过滤器都有自己的数据，这些数据或者是从磁盘存储器中读取来，或者是由另一个过滤器的输出导入进来，整个系统没有一个共享的数据区。
        
        这样，当用户要操作某一项数据时，要涉及到多个过滤器对相应数据的操作，其实现较为复杂。由以上的缺点，可以对每个过滤器增加相应的用户控制接口，使得外部可以对过滤器的执行进行控制。
      - 导致系统处理过程的成批操作。
        
        设计者也许不得不花费精力协调两个相对独立但又存在某种关系的数据流之间的关系
        
        例如多过滤器并发执行时数据流之间的同步问题等。
        
        根据实际设计的需要，设计者也需要对数据传输进行特定的处理（如为了防止数据泄漏而采取加密等手段），导致过滤器必须对输入、输出管道中的数据流进行解析或反解析，增加了过滤器具体实现的复杂性。
    - 实例——数字通信系统
  - 面向对象风格
    - 概述
      - 面相对象模式集数据抽象、抽象数据类型、类继承为一体，使软件工程公认的模块化、信息隐藏、抽象、重用性等原则在面向对象风格下得以充分实现。
    - 应用场合
      - 面向对象的体系结构模式适用于数据和功能分离的系统中，同样也适合于问题域模型比较明显，或需要人机交互界面的系统。大多数应用事件驱动风格的系统也常常应用了面向对象风格
      - 图示
    - 基本原则
      - 将逻辑上的实体映射为对象，实体之间的关系映射为对象之间的应用关系。
      - 对象利用应用关系来访问对方公开的接口，完成某个特定任务；一组对象之间相互协作，完成总体目标。
      - 图示
    - 优点
      - 高度模块性
        
        数据与其相关操作被组织为对象，成为模块组织的基本单位
      - 封装功能
        
        一组功能和其实现细节被封装在一个对象中，具有功能的接口被暴露出来
      - 代码共享
        
        对象的相对独立性可被反复重用，通过拼装形成不同的软件系统
      - 灵活性
        
        对象在组织过程中，相互关系可以任意变化，只要接口兼容
      - 易维护性
        
        对象接近于人对问题和解决方案模型的思维方式，易于理解和修改
    - 面向对象风格实例——人事档案管理系统
    - 缺点
      - 面向对象风格最大的不足在于如果一个对象需要调用另一个对象，它就必须知道那个对象的标识（对象名或对象引用），这样就无形之中增强了对象之间的依赖关系。
      - 如果一个对象改变了自己的标识，就必须通知系统中所有和它有调用关系的对象，否则系统就无法正常运行。
      - 图示
    - 特征
      - 事件驱动系统的基本观点是一个系统对外部的表现可以从它对事件的处理表征出来
        
        图示
  - 事件驱动风格
    - 特点
      - 系统是由若干子系统或元素所组成的一个整体
      - 系统有一定的目标，各子系统在某一种消息机制的控制下，为了这个目标而协调行动
      - 在某一种消息机制的控制下，系统作为一个整体与环境相适应和协调
      - 在一个系统的若干子系统中，必定有一个子系统起着主导作用，而其他子系统则处于从属地位；
      - 任一系统和系统内的任一元素，都有1个事件收集机制和1个事件处理机制，通过这种机制与周围环境发生作用和联系；
    - 基于事件驱动的软件系统的示意图
    - 事件驱动风格系统设计时有下述几条基本原则
      - 从系统论的角度来看待描述的对象，合理分解子系统，保证各个子系统的独立性和社会性；
      - 无论系统多么复杂，子系统性质的差异多么大，任何子系统都可以按照有无子系统这一性质分为2类：管理系统和执行系统。
      - 为了达到系统的目标，系统内的各个子系统通过传递消息和执行消息来协同操作。
      - 为了达到系统的目标，系统内的各个子系统通过传递消息和执行消息来协同操作。
      - 在一个完整系统中，必须有这样一个子系统，它没有上级，必须收集系统外的事件及下级发出的事件。
      - 管理类型的子系统一般不执行具体操作，它的主要功能是按照自己的职能指挥下级完成任务，功能性操作一般由执行类型的子系统完成。
      - 在一般情况下，除最高级管理子系统外，子系统一般是“有问才答”，即使在必要的情况下需要积极寻找事件时，也必须征得上级系统得许可，保证了系统的控制流不会分散。
    - 事件驱动风格基本结构
      - 事件驱动系统具有某种意义上的递归性，形成了“部分－整体”的层次结构，可以用属性结构加以表示。
      - 一个简单的表示方法是为执行系统定义一些类，另外定义一些类作为这些执行系统的容器类，也就是管理系统。
      - 图示
    - 事件驱动风格实例
      - Java中的button实现
    - 优点
      - 事件驱动风格非常适合于描述系统族，在属于同一族的任何系统中，系统的高级管理子系统的描述是完全类似的，便于重用；
      - 由于最高管理子系统牢牢的掌握着控制权，又因为各同级子系统一般不直接发生关系，因此容易实现并发处理和多任务操作；
      - 基于事件驱动风格的系统具有良好的可扩展性，设计者只需为某个对象注册一个事件处理接口就可以将该对象引入整个系统，同时并不影响其它的系统对象。
      - 定义了包含执行子系统和管理子系统的类层次结构；
      - 简化客户代码；
      - 使整个系统的设计更具有一般化。
    - 缺点
      - 事件驱动风格最大的不足在于构件削弱了自身对系统计算的控制能力
      - 事件驱动风格中存在的另一个问题在于数据共享
      - 系统中各个对象的逻辑关系变得更加复杂
    - 事件驱动风格和面向对象风格的关系
      - 基于面向对象风格的系统由多个封装起来的对象构成，对象之间通过消息传递实现通信，而事件驱动正是对消息传递机制的一种实现。
      - 所以基于事件驱动风格的系统往往都是面向对象的。
  - 分层风格
    - 特征
      - 一个分层系统采用层次化的组织方式构建，系统中的每一层都要承担两个角色。
        
        首先，它要为结构中的上层提供服务；
        
        其次，它要作为结构中下面层次的客户，调用下层提供的功能函数。
      - 图示
    - 优点
      - 分层风格支持系统设计过程中的逐级抽象
      - 基于分层风格的系统具有较好的可扩展性
      - 分层风格支持软件复用
    - 缺点
      - 并不是所有的系统都适合用分层风格来描述的
      - 对于抽象出来的功能具体应该放在哪个层次上也是设计者头疼的一个问题
    - 分层风格实例：计算机网络的设计
      - 概述
        
        网络协议设计者将计算机网络中的各个部分按其功能划分为若干个层次（Layer），其中的每一个层次都可以看成是一个相对独立的黑箱、一个封闭的系统。用户只关心每一层的外部特性，只需要定义每一层的输入、数据处理和输出等外部特性。
      - ISO/OSI网络体系结构
        
        ISO/OSI采用了7层体系结构，从高到低分别是
        
        应用层
        
        它的主要功能是为数据提供各种可行的收发方式。
        
        它应该为网络用户或应用程序提供各种应用服务，如文件传输、电子邮件（E-mail）、分布式数据库、网络管理等。
        
        这类似于用户公司内部的部门或个人在收发货物时，都必须遵循用户公司内部的有关规定，只能使用用户公司所允许的方式来收发货物。
        
        从另一方面来说，用户公司也要为公司内部的部门或个人收发货物提供各种可行的收发方式，让用户公司内部的部门或个人知道他们能够使用哪些方式来收发货物。
        
        表示层
        
        它的主要功能是为数据提供收发、存放的具体格式和规范。
        
        它应该为应用层提供信息表示方式的服务，如数据格式的变换、文本压缩、加密技术等。
        
        这类似于用户公司的货物收发员，它负责与用户公司内部要收发货物的部门或个人打交道，在收集要发送的货物时告诉用户应该怎样填写发货资料，在向用户发放货物时告诉用户应该完清哪些具体手续，等等。
        
        会话层
        
        它的主要功能是负责收发数据的交接工作、并组织和管理数据。
        
        它应该为表示层提供建立、维护和结束会话连接的功能，并提供会话管理服务。
        
        这类似于用户公司的货物收发室，它负责与运输公司打交道，完成用户公司货物的收发的交接工作、并组织管理公司内部要收发的货物。
        
        传输层
        
        它的主要功能是在上层和下层之间起到一种接口的功能。
        
        它应该为上层提供端到端（最终用户到最终用户）、的透明的、可靠的数据传输服务。
        
        所谓透明的传输是指在通信过程中上层可以将下面各层看作是一个封闭的黑箱系统，传输层对上层屏蔽了传输系统的具体细节。
        
        这类似于运输公司在各个地方设置的业务接洽处，它负责在用户和公司之间建立起一个货物交接的桥梁，使得用户不用去管运输公司将以什么样的方式将货物运送到目的地，也就是说业务接洽处对用户屏蔽了货物运输中的具体细节。
        
        网络层
        
        它的主要功能是路由控制（找路）、拥塞控制和数据打包。
        
        它应该为其上一层传输层的数据传输提供建立、维护和终止网络连接的手段，把上层传来的数据分割成一个一个的数据包（Packet，也叫报文分组）在结点之间进行交换传送，并且负责路由控制和拥塞控制。
        
        这类似于运输公司需要将用户发送的货物进行分割打包，并在现有的交通网络之中负责找出一条从源地址到目的地址的线路（即找路），在找路时需要考虑到能否到达、拥塞状况、安全可靠性、甚至交通费用等诸多方面的因素。
        
        数据链路层
        
        它的主要功能是纠错和流量控制，负责在可能出现差错的物理线路中实现无差错的数据传送。它应该在物理层的基础上，建立相邻结点之间的数据链路，通过差错控制提供数据帧（Frame）的无差错传输，并进行数据流量控制。
        
        这类似于运输公司的运输管理和质量监督部门，需要负责在可能出现问题的运输线路之中保质保量地完成运输任务。
        
        物理层
        
        它负责在物理信道上传输原始的数据bit流。它应该提供为建立、维护和拆除物理链路连接所需的机械的、电气的、功能和规程的特性，这类似于运输车辆只需要负责将装在车辆内的货物（类似于bits）运送到某地就行了。
        
        层与层之间的联系是通过各层之间的接口来实现的，上层通过接口向下层提出服务请求，而下层通过接口向上层提供服务。两台计算机通过网络进行通信时，只有两物理层之间能够通过媒体进行真正的数据通信，其余各对等层之间均不存在直接的通信关系，各对等层之间只能通过各对等层的协议来进行虚拟通信。
        
        图示
      - ISO/OSI层次分组关系 :有两种分组方法
      - 从数据处理分工的角度
        
        将ISO/OSI七个层次分为三组
        
        第1、2层解决有关网络信道问题
        
        第3、4层解决传输服务问题
        
        第5、6、7层则处理对应用进程的访问
      - 从数据传输控制的角度
        
        将ISO/OSI七个层次分为三组
        
        下三层（1、2、3层）可以看作是传输控制组，负责通信子网的工作，解决网络中的通信问题
        
        上三层（5、6、7层）为应用控制组，负责有关资源子网的工作，解决应用进程之间的信息转换问题
        
        中间层（4层）则为通信子网和资源子网的接口，起到连接传输和应用的作用
    - 分层风格实例：.Net平台
  - 数据共享风格
    - 特征
      - 采用数据共享风格构建的系统中通常有两个截然不同的功能构件
      - 中央数据单元构件
      - 一些相对独立的构件的集合
      - 图示
    - 控制策略
      - 信息交互方式的差异导致了控制策略的不同
      - 主要的控制策略有两种，正是依据这两种不同的控制策略，基于数据共享风格的系统被分成两个子类：
        
        基于传统数据库型数据共享风格的应用系统
        
        基于黑板型数据共享风格的应用系统
        
        知识源
        
        知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
        
        黑板数据结构
        
        黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
        
        控制
        
        控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
        
        黑板模式对于无确定性求解策略的问题比较有用，在专家系统中，这种模式应用的比较广泛。
    - 优点
      - 解决问题的多方法性
        
        对于一个专家系统，针对于要解决的问题，如果在其领域中没有独立的方法存在，而且对解空间的完全搜索也是不可行的，在黑板模式中可以用多种不同的算法来进行试验，并且也允许用不同的控制方法。
      - 具有可更改性和可维护性
        
        因为在黑板模式中每个知识源是独立的，彼此之间的通信通过黑板来完成，所以这使整个系统更具有可更改性和可维护性。
    - 缺点
      - 测试困难
        
        由于黑板模式的系统有中央数据构件来描述系统的体现系统的状态，所以系统的执行没有确定的顺序，其结果的可再现性比较差，难于测试。
      - 不能保证有好的求解方案
        
        一个黑板模式的系统所提供给我们的往往是所解决问题的一个百分比，而不是最佳的解决方案。
      - 效率低
        
        黑板模式的系统在拒绝错误假设的时候要承受多余的计算开销，所以导致效率比较低。
      - 开发成本高
        
        绝大部分黑板模式的系统需要用几年的时间来进化，所以开发成本较高。
      - 缺少对并行机的支持
        
        黑板模式要求黑板上的中心数据同步并发访问，所以缺少对不并行机的支持。
    - 数据共享风格实例：专家系统
      - 概述
        
        专家系统实质就是一组程序
        
        从功能上讲
        
        可定义为“一个在某领域具有专家水平解题能力的程序系统”，能像领域专家一样工作，运用专家积累的工作经验与专门知识，在很短时间内对问题得出高水平的解答。
        
        从结构上讲
        
        可定义为“由一个专门领域的知识库，以及一个能获取和运用知识的机构构成的解题程序系统”。
      - 图示
  - 解释器风格
    - 特征
      - 基于解释器风格的系统核心在于虚拟机。
      - 一个基于解释器风格的系统通常包括：正在被解释执行的伪码和解释引擎
      - 伪码：由需要被解释执行的源代码和解释引擎分析所得的中间代码组成
      - 解释引擎包括：语法解释器和解释器当前的运行状态
    - 图示
    - 优点
      - 在文法规则比较简单的情况下，解释器风格工作的很好
      - 易于改变和扩展文法
        
        因为解释器风格使用类来表示文法规则，用户可以使用继承来改变和扩展文法。已有的表达式可以采用增量的方式逐渐扩充，而新的表达式可以定义为旧表达式的变体
      - 易于实现文法。
      - 可以用多种操作来“解释”一个句子。
    - 缺点
      - 无法解释复杂的文法规则
        
        对于比较简单的文法规则，解释器风格工作的很好，而对于复杂的文法规则，则由于文法层次的庞大而难于管理
      - 应用范围比较狭窄
      - 在文法规则比较复杂，则文法的层次变得无法管理，系统中需要包含许多表示文法规则的类
    - 解释器风格实例：一个布尔表达式解释器
      - 图示
      - 优缺点
        
        在文法规则比较简单的情况下，解释器风格工作的很好，但如果文法规则复杂，则文法的层次变得庞大而无法管理，系统中需要包含许多表示文法规则的类。
        
        最高效的解释器通常不是通过直接解释语法分析数实现的，而是首先将它们转换成另一种形式。
        
        易于改变和扩展文法。
        
        易于实现文法。
      - 角色
        
        BooleanExpression（抽象布尔表达式）
        
        TerminalExpression（终结符表达式，如VariableExpresssion和Constant）
        
        NonterminalExpression（非终结符表达式，如AndExpression、OrExpression和NotExpression）
        
        Context（上下文，也就是“解释引擎内部状态”）
        
        Client（客户）
      - 实现
        
        在具体实现布尔表达式求值系统时还有许多细节的问题要处理，这些细节问题处理的好坏甚至会直接影响整个系统的性能。这些问题主要表现在以下几个方面
        
        创建抽象语法树
        
        定义求值操作
        
        共享终结符
  - 反馈控制环风格
    - 概述
      - 所谓对一个对象（或过程）进行控制，意味着设法使这个被控对象（或被控过程）的功能或特性有效的达到所期望的目标。
      - 为了成功设计一个控制系统，必须事先知道被控对象所具有的性质和特征，同时还须了解和掌握这些性质和特征随环境等因素变化的情况。
    - 控制工程是一个十分强调方法论的专业领域，因此控制工程方法完全是独立于各种应用领域的。
    - 为了将过程控制方法从单纯的控制领域中抽象出来，我们引入了动态系统的概念。
      - 动态系统表示信号处理和传输的一个功能单元（例如：信号可以是能量、材料、信息、资金及其他形式），其中系统的起因和由此引起的时间上的效果分别作为系统的输入量和输出量来考虑。
      - 如此定义的系统具有共同的特征，即在其中一定存在有目标的作用、信息处理、闭环和开环控制过程，正如N.Wiener所提出的，以上概念可以用控制论这个更高级的概念来总结。
      - 控制论也可以应用于软件体系结构的创建。
    - 描述手段
      - 根据上述的动态系统的定义，在系统中必然存在信号的处理和传输。这时系统也可描述为传输环节或传输系统。传输环节具有唯一的作用方向，这由输入、输出信号的箭头方向给出。
      - 图示
    - 开环与闭环控制
      - 一般的动态系统描述框图可以分为开环控制和闭环控制系统，但在实际应用中这两种不同的动态系统往往很容易混淆在一起，对它们之间的区别强调的不够。
      - 现在通过一个市内暖气系统来指出这两者之间的不同和相同之处。
        
        开环控制图
        
        闭环控制图
        
        开环控制和闭环控制的差别
        
        闭环控制
        
        表示一个闭合的作用过程，（控制回环）
        
        根据闭环作用原理可增加抗干扰性（负反馈）
        
        可能不稳定，也即被控量不再衰减，而是增长到无穷大（理论上）
        
        开环控制
        
        表示一个开放的作用过程（控制序列）
        
        只能对抗指定由其处理的干扰，对于其他一些干扰因素无法消除
        
        只要被控制对象自己保持稳定，整个开环控制系统也就保持稳定
    - 基本结构
      - 一个自动控制系统包括如下4个主要组成部分：被控对象、测量环节、调节器和执行环节
      - 图示
      - 自适应反馈控制环需要包括以下3方面的工作
        
        辨识被控对象的特征
        
        在辨识的基础上作出控制决策
        
        在决策的基础上实施修正动作
      - 按照构成自适应控制环的目的的不同可将其分为两种类型：
        
        参数自适应控制环
        
        性能自适应控制环
  - 七种构建模式的比较
    - 软件体系结构的七种构建模式各有自己的特点、局限、应用范围和优缺点，比较各种构建模式的不同将有助于在实际的项目开发过程中选择适合项目的构建模式。七种构建模式的比较见下表所示：
  - 异构风格的集成
    - 概述
      - 各种系统构建模式之间不仅有联系，而且在很多情况下它们往往是配合使用的。
      - 即面对一个实际系统，很难判断它究竟是A型，还是B型，亦或者是C型，单纯的把它归到任何一型都是很勉强的。
      - 这样的系统可以称为复合型系统，这样的系统构建模式就称为异构风格的集成。
软件体系结构描述
- 传统的软件体系结构描述方法
  - 传统描述方法的种类
    - 图形表达工具
      - 采用由矩形框和有向线段组合而成的图形表达工具。
      - 矩形表示抽象构件
      - 框内文字为抽象构件的名称
      - 有向线段代表辅助各构件进行通信、控制或关联的连接件。
      - 图示
    - 模块内连接语言
      - 采用将一种或几种传统程序设计语言的模块连接起来的模块内连接语言（Module Interconnection Language, MIL）
        
        由于程序设计语言和模块内连接语言具有严格的语义基础，因此它们能支持对较大的软件单元进行描述，诸如定义/使用和扇入/扇出等操作。例如，Ada语言采用use实现包的重用，Pascal语言采用过程（函数）模块的交互等。
      - MIL方式对模块化的程序设计和分段编译等程序设计与开发技术确实发挥了很大的作用。
        
        但是由于这些语言处理和描述的软件设计开发层次过于依赖程序设计语言，因此限制了它们处理和描述比程序设计语言元素更为抽象的高层次软件体系结构元素的能力。
    - 基于软构件的系统描述语言
      - 基于软构件的系统描述语言将软件系统描述成一种是由许多以特定形式相互作用的特殊软件实体构造组成的组织或系统。
      - 例如，一种多变配置语言(Proteus Configuration Language, PCL)就可以用来在一个较高的抽象层次上对系统的体系结构建模，Darwin最初用作设计和构造复杂分布式系统的配置说明语言，因具有动态特性，也可用来描述动态体系结构。
      - 这种表达和描述方式虽然也是较好的一种以构件为单位的软件系统描述方法，但是他们所面向和针对的系统元素仍然是一些层次较低的以程序设计为基础的通信协作软件实体单元，而且这些语言所描述和表达的系统一般而言都是面向特定应用的特殊系统，这些特性使得基于软构件的系统描述仍然不是十分适合软件体系结构的描述和表达。
  - 存在的问题
    - 体系结构设计不容易理解。
    - 系统架构师很难在各种方案中做出原则性的选择。
    - 初始设计中假定的体系结构约束可能随着系统演化而丧失。
    - 几乎没有什么工具能帮助系统架构师进行体系结构设计。
  - 目前对体系结构的描述主要有两类：
    - 使用精确的无歧义的体系结构描述语言，并提供对体系结构和特征的分析工具和设计环境。
    - 采用形式化的方法，提供精确的、抽象的模型，并提供基于这个模型的分析工具。
- 软件体系结构描述框架标准
  - 体系结构描述的概念与实践存在不统一的现象
  - 基于此，关于体系结构，IEEE于1995年8月成立了相关工作组，综合研究成果，参考业界的体系结构描述实践，负责起草了体系结构框架标准
  - IEEE　P1471
    - IEEE P1471于2000年9月21日通过IEEE-SA标准委员会评审。（软件密集系统的体系结构描述推荐标准）
    - IEEE P1471适用于软件密集的系统，其目标在于：便于体系结构的表达与交流，并通过体系结构要素及其实践标准化，奠定质量与成本的基础。
  - IEEE P1471 最主要的组成部分
    - 对关键术语的定义。
    - 对体系结构与体系结构描述在概念上的分力促进了描述体系结构标准和构筑系统标准的建立。
    - 用于描述一个系统体系结构的内容要求。
  - IEEE P1471 的体系结构描述要求
    - 一个体系结构描述必须规定系统的用户，确定体系结构的要点。
    - 一个体系结构描述必须被编入一个或多个系统的体系结构视图中。
    - 一个体系结构描述必须为制定关键的结构性决策提供基本原则。
  - IEEE P1471 软件体系结构描述的标准
    - 体系结构设计的标识、版本、总体信息。
    - 系统参与者的标识、以及在体系结构中他们所关注方面的标识。
    - 组织体系结构表示所选择的视点的规格说明，以及这种选择的基本原理。
    - 一个或多个体系结构视图。
    - 体系结构描述所需的成分之间不一致的记录。
    - 体系结构选择的基本原理。
  - Rational
    - 基于IEEE　P1471推荐的体系结构描述的概念框架
    - Rational起草了可重用的软件资产规格说明，提出了一套易于重用的体系结构描述规范。
- 软件体系结构与UML
  - UML简介
    - UML(Unified Modeling Language)是下面这些最好的建模方法中最好部分的集成:
      - 商务流程模型(Work Flow)
      - 对象建模方法
      - 软构件建模思想
    - UML是一种用可视化方法对软件系统进行描述、实施和说明的标准语言。
    - 支持用不同实现技术进行的软件开发全过程。
    - 图示
- 使用“4+1”模型描述软件体系结构
  - 从1990年开始，Rational公司的Philippe Kruchten对软件体系结构的不同视角进行了专门的研究，并于1995年在IEEE提出了用于体系结构描述的“4+1”视图模型(The 4+1 View Model of Architecture)。
    - 逻辑视图(Logical View)
      - 当采用面向对象的设计方法时，逻辑视图即是对象模型。
      - 逻辑视图主要支持功能需求——系统应当向用户提供什么样的服务。
      - 从问题域出发，采用面向对象的方法，按照抽象、封装、继承的原则进行分解，得到代表着系统的关键抽象表示的集合。
      - 这些抽象表示的具体形式就是对象和对象的类。
      - 这种分级不仅是为了功能分析，而且还担负着在系统的各部分中确定公共机制和设计元素的作用。
      - 除了面向对象的方法，还可以使用其他形式的逻辑体系结构。
        
        例如，当所面对的应用具有很明显的数据驱动的特征时，可以使用E-R图。
      - 逻辑视图的符号表示法
        
        逻辑体系结构的符号表示法(见图4-18)是从Booch方法派生而来的。
        
        它被极大地简化了，尤其大量简化了在这个设计阶段作用不大的各种修饰，只考虑对于体系结构有重要意义的元素。
        
        在设计工具上，可以使用Rational Rose等UML建模工具。公共的机制和服务在类设施(Class Utilities)中定义。
        
        图示
      - 逻辑视图的风格
        
        逻辑视图也可以采用面向对象的风格。
        
        逻辑视图设计的主要准则是，要设法在整个系统中保持一个单一的、连贯的对象模型，避免类和相关机制按照场地或处理器过早地分化。
    - 过程视图(Process View)
      - 描述系统的并发和同步方面的设计。
      - 过程体系结构考虑的是一些非功能性的需求，诸如性能、可用性等。
      - 它所要面对的问题有并发、分布、系统的完整性、容错能力等。
      - 它还要考虑怎样把过程体系结构与逻辑视图体系结构的要点相适应——对某个对象的某个操作实际上是在哪个控制线程上发生的。
      - 过程视图的符号表示法
        
        这里介绍的过程体系结构符号表示法是从Booch为Ada任务分配提出的符号表示法扩展而来的。
        
        与逻辑视图的符号表示法类似，它也被极大地简化了，只考虑对于体系结构有重要意义的元素，如图4-20所示。
        
        图示
      - 过程视图的风格
        
        有多种风格适合过程体系结构。例如管道-过滤器、客户/服务器及其变体(多客户/单服务器、多客户/多服务器等)
    - 物理视图(Physical View)
      - 描述软件到硬件之间的映射关系，反映系统在分布方面的设计。
      - 物理视图的体系结构：从软件到硬件的映射
        
        物理体系结构主要考虑的是非功能性的系统需求，如系统的可用性、可靠性(容错性)、性能(信息吞吐量)和可扩展性。
        
        软件系统在计算机网络的各个处理节点上运行。
        
        各种被确定出的元素——网络、过程、任务和对象——需要映射到各种节点上去，将用到不同的物理配置，有些用于开发和测试，有些用于不同场所或不同用户。
        
        因此从软件到处理节点的映射需要高度灵活，并且最小限度地影响其本身的源代码。
      - 物理视图的符号表示法
        
        图示
        
        大型系统中的物理视图可能非常凌乱
        
        TRW公司的UNAS允许使用者采用数据驱动的方式将过程体系结构映射到物理体系结构，并允许在不修改源代码的情况下对这种映射做出多种改动。
    - 开发视图(Development View)
      - 描述软件在开发环境下的静态组织结构。
      - 开发视图的符号表示法
        
        与前面类似，开发视图的符号表示法采用Booch表示法的变体，并且只考虑对于体系结构有重要意义的元素
        
        图示
        
        Rational公司的Apex Development Environment 支持对开发视图的定义和实现，也支持上面描述的分层策略和对设计规则的执行。在Rational Rose中，可以绘制模块层和子系统层的开发体系结构图，还可以在逆向工程中从已经开发的源代码(Ada或C++)中得出系统的开发体系结构图。
      - 开发视图的风格
        
        对于开发视图，我们建议采用分层风格，定义4～6层的子系统。
        
        每一层都有明确定义的责任。
        
        设计规则是，某一层的子系统只能依赖于本层或其下层的子系统。
        
        这样做的目的是使模块间相互依赖而构成的复杂网络最小化，并使得系统可以采用逐层的策略完成释放。
    - 另外加上场景(Scenarios)
      - 场景视图的体系结构：汇总
        
        通过使用一些重要场景，4个视图中的元素可以协调地共同工作。
        
        尽管这些场景是一个小集合，但是它们很重要。
        
        场景是更通用的概念——用例的实例。
        
        从某种意义上讲，场景是最重要的需求的抽象。
        
        场景的设计使用对象场景图(Object Scenario Diagram)和对象交互图来表示。
      - 相对于其他的4个视图，场景视图是多余出来的(所以称为“4+1”)，但是它承担着两个任务
        
        在下面要讲到的体系结构设计中，将以此视图为驱动来发现体系结构元素。
        
        在体系结构设计结束后，此视图承担验证和描述的角色。它不仅用于书面记录，并且是体系结构原型测试的起始点。
      - 场景视图的符号表示法
        
        场景视图的符号表示法中，构件的表示与逻辑视图非常相似，但是连接件的表示使用过程视图中的方法。
        
        注意，对象的实例用细实线表示。
        
        在工具的使用方面，和逻辑体系结构类似，可以使用Rational Rose绘制和管理对象场景图。
    - 图示
    - “4+1”视图模型为理解复杂系统的软件体系结构提供了一个简单和易于理解的方式。它从 5个不同的角度来描述软件，每个角度都显示了模型系统的一个具体方面。
- 使用UML描述软件体系结构
  - UML简介
    - UML的概念
      - UML(Unified Modeling Language)是一种统一建模语言，下面对它进行解释。
      - 统一
        Unified
        
        表示是一种通用的标准，它被OMG(Object Management Group)认可，成为软件工业界的一种标准。
        
        UML表述的内容能被各类人员所理解，包括客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。
        
        他们可以通过UML充分理解和表达自己所关注的那部分内容。
      - 建模
        Modeling
        
        即建立软件系统的模型。
        
        为说明建模的价值，Booch给出一个类比：盖一个宠物窝棚、修一个乡间别墅和建一座摩天大楼。
        
        建立一个简单的系统，例如盖一个宠物窝棚，模型可有可无；建立一个比较复杂的系统，例如修一个乡间别墅，模型的必要性增大；建立一个高度复杂的系统，例如建一座摩天大楼，模型必不可少。
      - 语言
        Language
        
        表明它是一套按照特定规则和模式组成的符号系统，它用半形式化方法定义，即用图形符号、自然语言和形式语言相结合的方法来描述定义的。
    - UML的发展历史
      - 公认的面向对象建模语言出现于20世纪70年代中期，到了80年代末发展极为迅速。
      - 据统计，1989年到1994年，面向对象建模语言的数量从不到10种增加到50多种。
      - 各位语言的创造者极力推崇自己的语言，并不断地发展完善它。
      - 但由于各种建模语言所固有的差异和优缺点，使得使用者不知道该选用哪种语言。
      - 其中比较流行的有Booch、Rumbaugh(OMT)、Jacobsom(OOSE)、Coad-Yourdon等方法。OMT擅长分析，Booch擅长设计，OOSE擅长业务建模。
      - Rumbaugh于1994年离开GE加入Booch所在的Rational公司，他们一起研究一种统一的方法，一年后，Unified Method 0.8诞生，同年，Rational收购了Jacobson所在的Objectory AB公司。经过三年的共同努力，UML0.9和UML0.91于1996年相继面世。
      - 此后，UML的创始人Booch等邀请计算机软件工程界的著名人士和著名的企业如IBM、HP、DEC、Microsoft、Oracle等对UML进行评论，提出修改意见。1997年1月，Rational公司向OMG递交了UML1.0标准文本。1997年11月，OMG宣布接受UML，认定为标准的建模语言。UML目前还在不断发展和完善。
  - UML基本图符
    - UML包含了一些图形元素，在进行系统分析和设计时需要这些图。
    - UML通过提供这些图，使得可以通过多个视图从不同角度来描述一个系统。
    - 用例图
      Use Case Diagram
      - 用例(Use Case)是从用户的观点对系统行为的一个描述。
      - 它从用户角度搜集系统需求，这样既可靠又不易遗漏需求。这里先举一个简单的例子，假设一个人使用洗衣机来洗衣服，用UML用例图来描述洗衣过程
      - 图示
        
        其中，小人表示参与者(Actor)，它代表拟建系统外部和系统进行交互的某类人或系统；椭圆代表用例。用例定义一组相关的由系统执行的动作序列。
    - 类图
      Class Diagram
      - 一个类是一组具有类似属性和共同行为的事物。
      - 例如，属于洗衣机类的事物都有诸如品牌(Brand Name)、型号(Model Name)、序列号(Serial Number)和容量(Capacity)等属性，它们的行为包括加衣物(Add Clothes)、加洗涤剂(Add Detergent)、取出衣物(Remove Clothes)等操作。
      - 图4-28是一个用UML表示法表示的洗衣机属性和行为的例子。
      - 矩形方框是UML中表示类的图标，它被分为3个区域：最上面是类名，中间是属性，最下面是操作。类图由这些类框和表明类之间关联的连线所组成。
    - 对象图
      Object Diagram
      - 对象是一个类的实例，是具有具体属性和行为的一个具体事物。
      - 如洗衣机品牌为海尔或小天鹅，一次最多洗涤重量为5 kg。
      - 图4-29说明了如何用UML来表示对象。
      - 使用UML描述对象时和类图类似，但在对象名下要加下划线，对象名后加冒号加类名。
    - 顺序图
      Sequence Diagram
      - 类图和对象图表达的是系统的静态结构。
      - 在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。UML顺序图所表达的正是这种基于时间的动态交互。
      - 仍以洗衣机为例，洗衣机的构件包括一个注水的进水管(Water Pipe)、一个用来装衣物的洗涤缸(Drum)和一个排水管(Drain)。这些构件也是对象
      - 当“洗衣服”这个用例被执行时，假设已完成了“加衣物”、“加洗涤剂”和“开机”操作，那么应执行以下步骤：
        
        (1) 通过进水管向洗涤缸中注水。
        
        (2) 洗涤缸保持静止状态。
        
        (3) 水注满，停止注水。
        
        (4) 洗涤缸往返旋转15分钟。
        
        (5) 通过排水管排掉洗涤后的脏水。
        
        (6) 重新开始注水。
        
        (7) 洗涤缸继续往返旋转洗涤。
        
        (8) 停止向洗衣机中注水。
        
        (9) 通过排水管排掉漂洗衣物的水。
        
        (10) 洗涤缸加快速度单方向旋转5分钟。
        
        (11) 洗涤缸停止旋转，洗衣过程结束。
      - 图4-30用一个顺序图说明了进水管、洗涤缸和排水管(由顺序图顶端的矩形图标代表)之间随时间变化所经历的交互过程。
      - 对象符号下方垂直的虚线，称为对象生存线。沿对象生存线上展开的细长矩形称为激活，表示该对象正在执行某个操作，矩形的长度表示执行操作的持续时间。
      - 带箭头的水平实线表示发送消息，消息可以发往其他对象或自身对象。图中对象之间发送的消息有6个，发往自身的消息有5个。消息可以是简单的(Simple)、同步的(Synchronous)或异步的(Asynchronous)。消息的图符可以用图4-31来表示。
    - 协作图
      Collaboration Diagram
      - 系统的工作目标是由系统中各组成元素相互协作完成的，建模语言必须具备这种协作关系的表达方式。UML协作图就是为此目的设计的。
      - 图4-32是协作图的一个例子。
      - 该图仍以洗衣机为例，在洗衣机构件的类集中又增加了一个内部计时器(Internal Timer)。在经过一段时间后，内部计时器控制进水管停止注水，然后启动洗涤缸往返旋转。图中的序号代表命令消息的发送顺序，内部计时器先向进水管对象发送停止注水消息，后向洗涤缸对象发送往返旋转消息。
    - 状态图
      Statechart Diagram
      - 在任一给定的时刻，一个对象总是处于某一特定的状态。
      - 一个人可以是新生儿、婴儿、儿童、少年、青年、中年或老年。
      - 一个电梯可以处于上升、下降或停止状态。一台洗衣机可处于浸泡(Soak)、洗涤(Wash)、漂洗(Rinse)、脱水(Spin)或关机(Off)状态。
      - UML状态图如图4-33所示，说明洗衣机可以从一个状态转移到另一个状态。
      - 状态在图中表述为圆角矩形，有两种比较特殊的状态：初始状态(实心圆点)和结束状态(实心圆点外加一个圆圈)。只能有一个初始状态，可能有多种结束状态。
    - 活动图
      Activity Diagram
      - 活动图类似于流程图，用于描述用例中的事件流结构。
      - 图4-34显示了顺序图中步骤4到步骤6之间按顺序的UML活动图。
    - 构件图
      Component Diagram
      - 构件图和下一个要介绍的部署图将不再使用洗衣机作为例子来做说明，因为它们和整个计算机系统密切相关。
      - 用图4-35来说明如何用UML表示软件构件。
      - 构件是软件系统的一个物理单元，例如数据表、可执行文件、动态链接库、文档等。
    - 部署图
      Deployment Diagram
      - 部署图显示了基于计算机系统的物理体系结构。
      - 它可以描述计算机和设备，展示它们之间的连接，以及驻留在每台机器中的软件。
      - 每台计算机用一个立方体来表示，立方体之间的连线表示这些计算机之间的通信关系。
      - 图4-36是部署图的一个例子。
    - 其他特征图
      - 包
        Package
        
        当需要将图中的组织元素分组，或者在图中说明一些类或构件是某个特定子系统的一部分时，可以将这些元素组织成包。
        
        包的表示法如图4-37所示。
      - 注释
        Note
        
        注释可以作为图中某部分的解释，其图标是一个带折角的矩形，矩形框中是解释性文字
        
        如图4-38所示
      - 构造型
        Stereotype
        
        构造型可以让用户能使用现有的UML元素来定制新的元素。
        
        构造型用双尖括号(Guillemets)括起来的一个名称来表示，如图4-39所示。
      - 以上3种图都可以用来组织和扩展模型图的特征。
  - UML的静态建模机制
    - UML的静态建模机制包括用例图、类图、对象图、包、构件图和部署图。
    - 用例图
      - 用例模型
        Use Case Model
        
        用例模型描述的是外部角色(Actor)所理解的系统功能。
        
        用例模型适用于需求分析阶段，它是经过系统开发者和用户反复讨论后而建立的，说明了开发者和用户对系统功能和需求规格达成的共识。
        
        用例模型描述了待开发系统的功能需求，它将系统看作黑盒，从系统的外部用户角度出发，对系统进行抽象表示。
        
        用例模型驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于测试系统是否满足用户的需求和验证系统的有效性，从而影响到开发工作的各个阶段和UML的各个模型。
        
        用例视图是其他视图的核心和基础，其他视图依靠用例视图中所描述的内容来构造。
        
        用例模型基本组成包括：用例、角色和系统。
        
        用例用于描述系统的功能，即从外部用户的角度观察系统应该支持的功能。
        
        用例宏观描述了系统功能，帮助分析人员理解系统的行为。
        
        每个系统中的用例都具体说明系统所具有的基本功能。
        
        角色是与系统进行交互的外部实体，可以是系统用户，也可以是与系统交互的任何其他系统或硬件设备。
        
        系统边界线以内的区域(即用例的活动区域)抽象表示系统能够实现的基本功能。
      - 用例
        Use Case
        
        从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。
        
        在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。　　
        
        用例的特点
        
        用例捕获某些用户可见的需求，实现一个具体的用户目标。
        
        用例由角色激活，并提供确切的值给角色。
        
        用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。
      - 角色
        Actor
        
        角色是与系统交互的人或事。
        
        所谓与系统交互，指的是角色向系统发送消息，从系统中接收消息，或是在系统中交换信息。只要使用用例，与系统互相交流的任何人或事都是角色。
        
        角色是一个群体概念，表示一类能使用某个功能的人或事，并不是指某个个体。一个具体的个体在系统中可以具有多种不同的角色。
        
        角色都有名字，它的名字反映了该角色的身份和行为，但是不能将角色的名字表示成角色的某个实例，或表示成角色所需完成的功能。
        
        角色与系统进行通信的收、发消息机制，类似于面向对象编程中的消息机制。
        
        角色是启动用例的前提条件。首先，角色发送消息给用例，当初始化用例后，用例再开始执行，在执行过程中该用例也可能向一个或多个角色发送消息。
      - 用例之间的关系
        
        扩展关系
        
        如果一个用例中加入一些新的动作后构成另一个用例，那么这两个用例之间的关系就是扩展关系
        
        后者通过集成前者的一些行为得来
        
        前者通常称为通用化用例，后者常称为扩展用例
        
        扩展用例可以根据需要有选择地集成通用化用例的部分行为
        
        使用关系
        
        一个用例使用另一个用例时，这两个用例之间就构成了使用关系
        
        通常，可以把用例中相同的行为提取出来单独做成一个用例，这个用例称为抽象用例
        
        当某个用例使用该抽象用例时，就像这个用例包含了抽象用例的所有行为
    - 类图、对象图和包
      - 类图
        
        在面向对象建模技术中，将客观世界的实体映射为对象，并归纳成类。
        
        类、对象和它们之间的关联是面向对象技术中最基本的元素。系统的类模型和对象模型描述了系统的结构。
        
        在UML中，类和对象模型分别由类图和对象图表示。
        
        类图表示类和类之间的静态关系。
        
        不同于数据模型，它不仅显示了信息的结构，同时还描述了系统的行为。
        
        类图是定义其他图的基础，状态图、协作图等在这个基础上进一步描述了系统其他方面的特性。
        
        类图是一种用类和它们之间的关系描述系统的图示。
      - 关系
        
        关联关系
        
        关联用于描述类与类之间的连接。
        
        因为对象是类的实例，所以类与类之间的关联也就是其对象之间的关联。
        
        虽然类与类之间有含义各不相同的多种连接方式，但外部表示形式相似，统称为关联。
        
        关联关系通常都是双向的，即关联的对象双方彼此都能与对方通信。
        
        也就是，当某两个类的对象之间存在要互相通信的关系时，这两个类之间就存在关联关系。
        
        泛化关系
        
        又称继承关系，是指一个类(称为一般元素、基类元素或父元素)的所有信息(属性和操作)能被另一个类(称为特殊元素或子元素)继承。
        
        继承某个类的类中不仅可以有属于自己的信息，而且还拥有被继承类中的信息。
        
        泛化的优点是通过把一般的公共信息放在基类元素中，使得在处理具体情况时只需定义该情况的特殊信息即可，公共信息则从通用元素中继承得来，从而增强了系统的灵活性、易维护性和可扩充性，大大缩短了系统的维护时间。
        
        具有泛化关系的两个类之间，继承通用类所有信息的具体类称为子类，被继承类称为父类。
        
        可以从父类中继承的信息有属性、操作和所有的关联关系。
      - 对象图
        
        类图表示类以及类和类之间的关系，对象图则表示在某一时刻这些类的实例之间的具体关系。
        
        由于对象是类的实例，因此，UML对象图中的概念与类图中的概念完全一致，对象图可以帮助理解一个比较复杂的类图，也可以用于显示类图中的对象在某一点的连接关系。
        
        对象的图示方法与类的图示方法几乎一样，主要差别在于对象的名字下面要加下划线
      - 包
        
        包是一种组合机制，把各种模型元素通过内在的语义连在一起成为一个整体，形成一个高内聚、低耦合的集合，UML中将这种分组机制称为包。
        
        构成包的模型元素称为包的内容。
        
        包通常用于对模型的组织管理，因此有时又将包称为子系统。
        
        模型元素的分组方法可以是任意的。
        
        在UML中，最有用和强调最多的分组原则是依赖。
        
        包图主要显示模型元素的包以及这些包之间的依赖关系，有时还显示包和包之间的继承关系和组成关系。
    - 构件图和部署图
      - 构件图和部署图显示系统实现的一些特性，包括源代码的静态结构和运行时刻的实现结构。构件图显示代码本身的结构，部署图显示系统运行时刻的结构。
      - 构件图
        
        构件图的表示法如图4-35所示。
        
        构件图显示系统构件之间的依赖关系，如图4-40所示。
        
        一般来说，系统构件就是一个实际文件，可以是源代码文件、二进制代码和可执行文件等，可以用来显示编译、链接或执行时构件之间的依赖关系。
      - 部署图
        
        部署图描述系统硬件的物理拓扑结构以及在此结构上执行的系统。
        
        部署图可以显示计算节点的拓扑结构和通信路径、节点上运行的系统构件、系统构件包含的逻辑单元(对象、类)等。部署图常常用于帮助理解分布式系统。
        
        节点和连接
        
        节点代表一个物理设备以及其上运行的系统。
        
        节点表示为一个立方体，节点名放在左上角。
        
        与类和对象一样，节点可以用于表示类型和实例。
        
        当用该符号表示实例时，需要名字下面有一条下划线。节点之间的连线表示系统之间进行交互的通信路径，称为连接。
        
        通信类型放在连接旁边的<< >>之间，表示所用的通信协议或网络类型。
        
        构件和界面
        
        在部署图中，构件代表可执行的物理代码模块，它在逻辑上与类图中的包或类对应。
        
        因此，部署图中显示运行时各个包或类在节点中的分布情况。
        
        在面向对象方法中，类和构件等元素并不是所有的属性和操作都对外可见。
        
        它们对外提供了可见操作和属性，称为类和构件的界面。
        
        界面表示为一头是小圆圈的直线。
        
        对象
        
        一个面向对象系统中可以运行很多对象。
        
        因为构件可以看做与包或类对应的物理代码模块，所以构件中应包含一些运行的对象。
        
        如图4-36所示的部署图中的对象与对象图中的对象表示法一致。
  - UML的动态建模机制
    - 在面向对象技术中，对象间的交互是通过在对象间传递消息完成的。
    - 在UML的所有动态图(顺序图、协作图、状态图、活动图)中，消息被当作对象间的一种通信表示方式。
    - 一般情况下，当一个对象调用另一个对象中的操作时，即完成了一次消息传递。
    - 当操作执行后，控制便返回到调用者。
    - 对象通过相互间的通信(消息传递)进行合作，并在其生命周期中根据通信的结果不断改变自身的状态。
      - 简单消息
        Simple Message
        
        表示普通的控制流。它描述控制是如何在对象间进行传递的，不考虑通信的具体细节。
        
        这种消息类型主要用于通信细节未知或不需要考虑通信细节的场合。
      - 同步消息
        Synchronous Message
        
        表示嵌套的控制流。操作的调用便是一种典型的同步消息。
        
        调用者发出消息后必须等待消息返回，只有当处理消息的操作执行完毕后，调用者才可继续执行自己的操作。
      - 异步消息
        Asynchronous Message
        
        表示异步控制流。调用者发出消息后不用等待消息的返回即可继续执行自己的操作。异步消息在实时系统中常用来描述其中的并发行为。
    - 顺序图
      - 顺序图用来描述对象间的动态交互关系，侧重体现对象间消息传递的时间顺序
      - 顺序图用横坐标轴表示对象，用纵坐标轴表示时间
      - 顺序图横坐标轴上的对象用一个带有垂直虚线的矩形框表示，矩形框中写有对象名和/或类名
      - 垂直虚线是对象的生命线，用于表示在某段时间内对象是否存在
      - 对象间的通信用对象的生命线之间的水平消息线来表示
      - 消息的箭头表示消息的类型，如同步消息、异步消息或简单消息
    - 协作图
      - 协作图用于描述相互合作的对象间的交互和链接关系(链接是关联的实例化)。
      - 尽管顺序图和协作图都用来描述对象间的交互关系，但侧重点并不一样。顺序图强调交互的时间顺序，而协作图则强调交互对象间的静态链接关系。
      - 协作图表示对象与对象间的链接以及链接间如何发送消息。
      - 协作图中对象的外观与顺序图中的一样。
      - 对象间链接的表示方法类似于类图中的关联。
      - 通过链接上标以用消息串表示的消息(简单、异步或同步消息)来表达对象间的消息传递。
      - 链接
      - 消息流
        
        在协作图的链接线上，可通过用消息串表示的消息来描述对象间的交互
        
        消息串中包含了发送的消息、消息的参数、消息的返回值以及消息的序列号等信息。
      - 对象的生命周期
        
        如果一个对象在消息的交互中被创建，则可在对象名称之后标以{new}。
        
        类似地，如果一个对象在交互期间被删除，则可在对象名称之后标以{destroy}。
    - 状态图
      - 状态图描述一个特定对象的所有可能状态以及引起状态转移的事件。
      - 状态图由一系列状态和状态之间的转移构成，通过状态图可以表示单个对象在其生命周期中的行为。
      - 状态
        
        每个对象都具有状态，状态是对象执行某个活动的结果。
        
        当发生某些事情后，结果将引起对象的状态的变化。
        
        通常将这些引起对象状态变化的事情称为“事件”。
        
        状态图可以有一个起点(初态)和多个终点(终态)。
        
        状态图的起点用一个黑圆点来表示，终点用黑圆点外加一个圆表示，状态用一个圆角矩形表示。
      - 转移
        
        状态图中用状态间带箭头的连线来表示状态的转移
        
        状态的变化通常由事件触发，此时应在状态转移线上标出触发转移的事件表达式
        
        如果状态转移线上未标明事件，则表示在源状态的内部活动执行完毕后自动触发转移
        
        一般情况，状态图是对类图的补充
        
        实际上，并不需要为所有的类画状态图，仅需要为那些有多个状态且其行为受外界环境的影响而发生改变的类画状态图
    - 活动图
      - 活动图可以描述操作(类的方法)中完成的工作，也可以描述用例和对象内部的工作过程。
      - 活动图由状态图变化而来，但它们的目的有所不同。
      - 活动图的主要目的是描述动作(将要执行的工作或活动)以及对象状态变化的结果。
      - 在活动图中，当一个活动结束后将立即进入下一个活动。
      - 但在状态图中，状态的变迁可能需要由事件触发。
      - 活动和转移
        
        一项操作可以用一系列相关的活动来描述。
        
        活动只有一个起始点，但结束点可以有多个。
        
        一个活动可以顺序地跟在另一个活动之后，这是简单的顺序关系。
        
        如果在活动图中使用一个菱形的判断标志，则表达条件关系，判断标志可以有多个输入和输出转移，但在活动的运作中只触发其中的一个输出转移。
        
        活动图也可以表示并发行为。
        
        在活动图中，使用一个称为同步条的水平粗线可以将一条转移分为多个并发执行的分支，或将多个转移合为一条转移。
        
        此时，只有当输入的转移全部有效，同步条才会触发转移，进而执行后面的活动。
      - 泳道
        
        泳道用纵向矩形框表示，放在该矩形框内均属于某个泳道的所有活动；将对象和名称放在矩形框的顶部，表示该对象对泳道中的活动负责
        
        所以，通过泳道可以将活动图的逻辑描述与顺序图、协作图的责任描述结合起来。
      - 对象
        
        在活动图中可以出现对象。
        
        对象可以作为活动的输入或输出，也可以仅表示某一活动对对象的影响。
        
        如果对象是一个活动的输入，那么用一个从对象指向活动的虚线箭头表示；如果对象是一个活动的输出，那么用一个从活动指向对象的虚线箭头表示；如果仅表示对象受到某一活动的影响，则可用不带箭头的虚线来连接对象与活动。
      - 信号
        
        在活动图中可以表示信号的发送与接收，分别用发送符号和接收符号表示。
        
        发送符号和接收符号也可与消息的发送对象和消息的接收对象相连。
  - UML在软件体系结构建模中的应用实例
    - 下面以浏览器/服务器的软件体系结构为例子，用UML的建模机制对简单的B/S体系结构进行建模，并说明该结构的构件交互及其交互模式的重用技术。
      - 用UML对构件交互模式进行静态建模
        
        前面已经介绍UML的静态建模机制包括用例图、类图、对象图、包、构件图和部署图。在本节主要通过用例图和部署图两种图来对B/S体系结构进行静态建模
        
        经过对B/S风格的软件体系结构的分析可知，用户通过浏览器与服务器端的交互用UML的部署图来表示，如图4-41所示
        
        浏览器是运行在客户端的应用程序，与网络上的服务器连接并请求获取信息页。
        
        当请求被满足，即浏览器得到所请求的信息页，连接就终止。
        
        浏览器指导怎样通过HTTP与Web服务器通信，以及怎样显示由Web服务器返回的格式化的信息(即以网页的形式返回)。
        
        服务器端的Web服务器接收网页(静态的HTML或服务器页)的请求，根据请求，Web服务器可能启动某个服务器端的处理(例如向数据库服务器发出SQL查询，然后将查询结果返回)，再将得到的信息以网页(如HTML格式的网页)的形式返回，在客户端的浏览器中显示出来。
        
        在B/S体系结构中，有各种构件和连接件。构件分为形成客户浏览器和服务器端的构件，服务器端构件包括Web服务器端和数据库服务器构件。
        
        构件在这里可以看做是进行一定运算或其他操作的体系结构的实体，而连接件是用于提供构件间交互的体系结构实体。通过构件和连接件加上由构件之间形成的交互，就形成了一个完整的体系结构。其中，构件间的信息交互有同步和异步两种；而内部构件的通信分为同步、异步、代理和组通信等。连接件不但表示一个简单的交互操作(例如过程调用、共享变量的使用)，而且还表示复杂的交互(例如TCP/IP协议、数据库使用协议、异步事件列表、网络安全协议等)。
        
        用UML的静态建模机制与扩展机制的构造型对构件间交互进行静态建模，如图4-42所示，其中<<构件>>、<<资源>>和<<连接件>>是构造型的。
        
        浏览器连接件也就是客户连接件，可以分为同步客户连接件和异步客户连接件。异步客户连接件是一个组合类，它由客户消息输入缓存类、客户请求端类和客户返回端类构成。用UML的类图表示如图4-43所示。
        
        服务器连接件可以分为单线程和多线程服务器连接件。用UML类图表示如图4-44所示。
      - 用UML对构件交互模式进行动态建模
        
        如前面所讲，UML中动态图有顺序图、协作图、状态图、活动图。在本节中，主要利用协作图对B/S体系结构的构件之间的交互进行建模。
        
        图4-45中显示了客户端浏览器与服务器端的构件的动态交互的协作图。
        
        首先，用户通过浏览器向浏览器连接件发出消息请求，浏览器连接件将请求进行打包形成消息包(消息包中包含相应的服务参数)，再通过网络资源(例如传输协议软件)将消息包发给服务器连接件，服务器连接件接收器将消息包进行检查，如果无错，就将它提交给服务器，服务器根据请求包中的请求完成相应的处理或服务，并将服务结果装配成一个响应包，再沿原路返回到浏览器端(中间服务器连接与浏览器连接件都将消息包进行处理)，最后提交给用户。
        
        前面已经提出，浏览器连接件有同步与异步之分，那么它们如何请求与接收信息的程序？请参见图4-46与图4-47。
软件体系结构集成开发环境
- 软件体系结构集成开发环境的作用
  - 软件体系结构集成开发环境基于体系结构形式化描述从系统框架的角度关注软件开发。
  - 体系结构开发工具是体系结构研究和分析的工具，给软件系统提供了形式化和可视化的描述。
  - 它不但提供了图形用户界面、文本编辑器、图形编辑器等可视化工具，还集成了编译器、解析器、校验器、仿真器等工具；不但可以针对每个系统元素，还支持从较高的构件层次分析和设计系统，这样可以有效地支持构件重用。
  - 具体来说，软件体系结构集成开发环境的功能可以分为以下5类。
    - 辅助体系结构建模
      - 建立体系结构模型是体系结构集成开发环境最重要的功能之一。
      - 集成开发环境的出现增加了软件体系结构描述方法的多样性，摒弃了描述能力低的非形式化方法，摆脱了拥有繁杂语法和语义规则的形式化方法。
      - 开发者只需要经过简单的操作就可以完成以前需耗费大量时间和精力的工作。
      - 形式化时期建模是将软件系统分解为相应的组成成分，如构件、连接件等，用形式化方法严格地描述这些组成成分及它们之间的关系，然后通过推理验证结果是否符合需求，最后提供量化的分析结果。
      - 而集成开发环境提供了一套支持自动建模的机制完成体系结构模型分析、设计、建立、验证等过程。
      - 用户根据不同的实际需求、应用领域和体系结构风格等因素选择不同的开发工具。
    - 支持层次结构的描述
      - 随着软件系统规模越来越大、越来越复杂，只使用简单结构无法表达，这时就需要层次结构的支持，因此开发工具也需要提供层次机制。
      - 图10-1描述了一个简单的具有层次结构的客户端/服务器系统。
      - 系统由客户端和服务器两个构件组成，客户端可以向服务器传输信息。
      - 服务器是一个包含了3个构件的复杂元素，内部构件之间相互关联形成了一个具有独立功能的子系统，子系统通过接口与外界交互。
      - 体系结构集成开发环境提供了子类型和子体系结构等机制来实现层次结构。
      - 用户还可以根据需要自定义类型，只需将这种类型实例化为具体的子系统即可。
      - 类似构件、连接件也可以通过定义新类型表达更复杂的信息。
    - 提供自动验证机制
      - 几乎所有的体系结构集成开发环境都提供了体系结构验证的功能。
      - 体系结构描述语言解析器和编译器是集成开发环境中必不可少的模块。
      - 除此之外，不同的集成开发环境根据不同的要求会支持特定的检验机制。
        
        Wright提供模型检测器来测试构件和连接件死锁等属性，它通过一组静态检查来判断系统结构规格说明的一致性和完整性，同时还支持针对某一特定体系结构风格的检查；
        
        C2通过约束构件和连接件的结构和组织方式来检查一致性和完整性；
        
        SADL利用体系结构求精模式概念保证使用求精模式的实例的每一步求精过程都正确，采用这种方式能够有效地减少体系结构设计的错误
        
        ArchStudio中的Archlight不但支持系统的一致性和完整性检查，还支持软件产品线的检测。
      - 集成开发环境的校验方式可分为主动型和被动型两种。
        
        主动型
        
        主动型是指在错误出现之前采取预防措施，是保证系统不出现错误状态的动态策略。
        
        它根据系统当前的状态选择恰当的设计决策保证系统正常运行。
        
        例如，在开发过程中阻止开发者选择接口不匹配的构件；集成开发环境不允许不完整的体系结构调用分析工具。
        
        被动型
        
        被动型是指允许错误暂时存在，但最终要保证系统的正确性。
        
        被动型有两种执行方式，一种允许预先保留提示错误稍后再作修改，另一种必须强制改正错误后系统才能继续运行。
        
        例如，在MetaH的图形编辑器中，启动“应用”按钮之前必须保证系统是正确的。
    - 提供图形和文本操作环境
      - 体系结构集成开发环境是开发者研究体系结构的可视化工具和展示平台，它具有友好的图形用户界面和便捷的操作环境。
      - 体现在以下4个方面：
        
        集成开发环境提供了包含多种界面元素的图形用户界面
        
        例如工具栏、菜单栏、导航器视图、大纲视图等。工具栏显示了常用命令和操作；视图以列表或者树状结构的形式对信息进行显示和管理。
        
        集成开发环境提供了图形化的编辑器
        
        它用形象的图形符号代表含义丰富的系统元素，用户只需选择需要的图形符号，设置元素的属性和行为并建立元素之间的关联就可以描绘系统了。
        
        例如，Darwin系统提供基本图元代表体系结构的基本元素，用空心矩形表示构件，直线表示关联，圆圈表示接口；
        
        每个图元都有自己的属性页，通过编辑构件、关联和接口的属性页来设置体系结构的属性值。
        
        集成开发环境利用文本编辑器帮助开发者记录和更新体系结构配置和规格说明
        
        通常，集成开发环境会根据模型描述的系统结构自动生成配置文档。
        
        当模型被修改时，它的文本描述也会发生相应的变化，这种同步机制保证了系统的一致性和完整性。
        
        集成开发环境还支持系统运行状态和系统检测信息的实时记录
        
        这些信息对分析、改进和维护系统都很有价值
    - 支持多视图
      - 多视图作为一种描述软件体系结构的重要途径，是近年来软件体系结构研究领域的重要方向之一。
      - 随着软件系统规模不断增大，多视图变得更为重要。
      - 每个视图都反映了系统内相关人员关注的特定方面。
      - 多视图体现了关注点分离的思想，把体系结构描述语言和多视图结合起来描述系统的体系结构，能使系统更易于理解，方便系统相关人员之间相互交流，还有利于系统的一致性检测以及系统质量属性的评估。
      - 图形视图和文本视图是两种常见的视图。
        
        图形视图
        
        图形视图是指用图形图像的形式将系统的某个侧面表达出来。
        
        它是一个抽象概念，不是指具体的哪一种视图。逻辑视图、物理视图、开发视图等都属于图形视图。
        
        文本视图
        
        文本视图是指用文字形式记录系统信息的视图。
        
        此外，还存在很多特殊的体系结构集成开发环境特有的视图
        
        例如Darwin系统中的分层系统视图、ArchStudio的文件管理视图、Aesop支持特定风格形象化的视图等。
- 体系结构IDE原型
  - 现在出现了越来越多的体系结构集成开发环境来满足种类繁多的体系结构和灵活多变的需求。
  - 尽管这些集成开发环境针对不同的应用领域，适用不同体系结构，但是它们都依赖相似的核心框架和实现机制。
  - 把这些本质的东西抽象出来可以总结出一个体系结构集成开发环境原型。
  - 该原型只是一个通用的框架，并不能执行任何实际的操作，但它可以帮助开发人员深入理解开发工具的结构和工作原理。
  - 下面结合XArch(eXtensible Architecture Research System)系统来介绍原型。
    - 从集成开发环境的工作机制看，原型是三层结构的系统。
      - 用户界面层
        最上层是用户界面层，它是系统和外界交互的接口
        
        用户界面层是用户和系统交互的唯一渠道，用户需要的操作都被集成到这一层。
        
        这些操作可以通过编辑器和视图来实现。
        
        编辑器是开发环境中的可视构件，它通常用于编辑或浏览资源，允许用户打开、编辑、保存处理对象，类似其他的文件系统应用工具，如Microsoft Word，执行的操作遵循“打开—保存—关闭”这一生命周期模型。
        
        同一时刻工作台窗口允许一个编辑器类型的多个实例存在。
        
        视图也是开发环境中的可视构件，它通常用来浏览分层信息、打开编辑器或显示当前活动编辑器的属性。
        
        与编辑器不同的是，同一时刻只允许特定视图类型的一个实例在工作台存在。
        
        编辑器和视图可以是活动的或者不活动的，但任何时刻只允许一个视图或编辑器是活动的。
        
        XArch系统的工作台是一个独立的应用窗口，包含了一系列视图和编辑器。
        
        工作台基于富客户端平台(Rich Client Platform)，它最大的特点是支持用户建立和扩展自己的客户应用程序。
        
        如果现有的编辑器不能满足需求，用户可以灵活地在接口上扩展新的功能。
        
        图10-3显示了XArch系统的部分编辑器和视图。
        
        图10-3
        
        左侧的资源管理器视图将系统所有的信息以树状结构显示出来；
        
        右边的属性视图显示了考察对象的属性和属性值；
        
        下面是记录系统重要状态的日志视图。
        
        占据工作台最大区域的是中间的编辑器，是主要的操作场所。
        
        为了满足相关人员不同的需求，系统支持多视图。
        
        系统用标签对多个视图进行区分和管理，用户可通过选择标签在不同视图间转换。
      - 模型层
        中间层是模型层，它是系统的核心部分，系统重要的功能都被封装在该层。这层通过接口向用户界面层传输数据，用户界面层要依赖这一层提供的服务才能正常运行。
        
        模型层是系统的核心层，系统的大部分功能都在这一层定义和实现
        
        主要任务
        
        主要任务是辅助体系结构集成开发环境建立体系结构模型。
        
        体系结构描述语言文档是系统的输入源
        
        有的体系结构集成开发环境对描述语言的语法有限制或约束，这就需要修改语言的语法与其兼容。
        
        输入的体系结构文档是否合法有效，是由专门的工具来检验的。
        
        此处的编译器不同于往常的把高级程序设计语言转化为低级语言(汇编语言或机器语言)的编译器，它是一个将体系结构描述转化为体系结构模型的工具。
        
        为实现此功能，编译器一般要完成下列操作：词法分析、解析、语义分析、映射、模型构造。
        
        词法分析
        
        词法分析是遵循语言的词法规则，扫描源文件的字符串，识别每一个单词，并将其表示成所谓的机内token形式，即构成一个token序列；
        
        解析
        
        解析过程也叫语法分析，是指根据语法规则，将token序列分解成各类语法短语，确定整个输入串是否构成一个语法上正确的程序，它是一个检查源文件是否符合语法规范的过程；
        
        语义分析
        
        语义分析过程将语义信息附加给语法分析的结果，并根据规则执行语义检查；映射是根据特定的规则，
        
        如映射文档，将体系结构描述语言符号转换成对应的模型元素的过程；模型构造紧跟着映射过程，它把映射得到的构件、连接件、接口等模型元素按语义和配置说明构造成一个有机整体。
        
        在编译器工作的过程中会有一些隐式约束的限制，例如类型信息、构件属性、模块间的关系等。
        
        校验器是系统最主要的检查测试工具，采用显示检验机制检查语法语义、类型不一致性、系统描述二义性、死锁等错误，以保证程序正常运行
        
        模式是一组约束文档结构和数据结构的规则，它是判断文档、数据是否有效的标准
        
        映射模块是抽象了体系结构描述语言元素和属性的一组规则，这组规则在模型层和用户界面层担任了不同的角色
        
        在模型层，它根据映射规则和辅助信息，将开发环境无法识别的体系结构描述语言符号映射成可以被工具识别的另一种形式的抽象元素。
        
        在用户界面层支持模型显示，它详细定义了描述语言符号如何在模型中表示，如何描绘模型元素以及它们之间的关系。
        
        建立体系结构模型是这层的最终目标，模型层用树或图结构抽象出系统，形象地描述了系统的各构件及它们之间的关系。
        
        通常，一个系统用一个体系结构模型表示。
        
        对于一个规模庞大、关系复杂的模型，不同的系统相关人员只需侧重了解他们关注的局部信息，而这些信息之间具有很强的内聚性，可以相对独立地存在。
        
        针对某一观察角度和分析目的，提取一系列相互关联且与其他内容相对独立的信息，就可以构成软件体系结构视图。
        
        一个模型可以构造成多种视图，通过不同的视角细致全面地研究系统。
        
        XArch系统只处理基于XML的可扩展的体系结构描述语言，即FEAL兼容的体系结构描述语言，如果不符合这一要求，则可以适当调整语法结构来满足FEAL的规范。
        
        软件体系结构描述不仅是XML结构良好的，还必须是符合模式规定的有效的文档。该系统不但支持对系统的分析、验证和序列化等操作，还支持视图和模型之间的相互转化。
        
        XArch系统不仅仅是一个体系结构开发环境，还是一个扩展工具的平台。它的扩展性主要体现在两个方面：
        
        可以灵活地创建和增加一种新的软件体系结构描述语言或语言的新特性，以满足新功能和新需求。
        
        如图10-4所示，系统通过引入一个中间介质FEAL，使模型脱离与体系结构描述语言的直接联系，从而拓展了体系结构描述语言符号到模型元素固定的对应关系。
        
        图10-4
        
        体系结构描述语言的元素首先根据映射规则被映射为FEAL元素(FEC)的形式，FEC再对应到相应的模型的构件。
        
        因此，只要体系结构描述语言符号到FEC的映射是有效的，那么无论哪种体系结构描述语言都可以构造对应的体系结构模型。
        
        当新的体系结构描述语言或新的语言特性出现时，只需修改映射规则就能有效地支持。
        
        XArch系统提供了一系列可扩展的可视化编辑接口，支持定义新界面元素。
      - 基础层
        
        底层是基础层，它覆盖了系统运行所必需的基本条件和环境，是系统正常运行的基础保障。
        
        此外，模型层和用户界面层的正常运行还需要映射模块的有效支持，映射文件将指导和约束这两层的行为(如图10-2所示)。
        
        基础层是系统的基本保障，涵盖了系统运行所需的软/硬件支撑环境，它还对系统运行时所用的资源进行管理和调度。
        
        通常，普通的简单配置就可以满足系统运行需求，但是有的体系结构集成开发环境需要更多的支持环境。
        
        例如，ArchStudio 4 作为Eclipse的插件，必须在Java和Eclipse环境下运行。
  - 体系结构集成开发环境设计策略
    - 目前，集成开发环境都很注重体系结构的可视化和分析，有的也在体系结构求精、实现和动态性上具有强大的功能。
    - 体系结构开发环境原型提供了一个可供参考的概念框架，它的设计和实现需要开发人员的集体努力。
    - 下面是体系结构集成开发环境设计的3条策略
      - 体系结构集成开发环境的设计必须以目标为向导
        
        集成开发环境的开发遵循软件开发的生命周期，需求分析是必需且非常重要的阶段。开发者只有明确了实际需求，才能准确无误地设计。
        
        无论是软件本身还是最终用户都有很多因素需要确认。
        
        例如，集成开发环境可以执行什么操作？怎么执行？它的结构怎样？哪一种体系结构描述语言和体系结构风格最适合它？哪些用户适合使用该系统？怎样解决系统的改进和升级？这些问题给设计者提供了指导和方向。
      - 为了设计一个支持高度扩展的体系结构集成开发环境，必须区分通用和专用的系统模块
        
        通用模块部分是所有集成开发环境都必备的基础设施，例如支撑环境、用户界面等。
        
        但是不同的体系结构集成开发环境针对不同的领域需要解决千差万别的问题，因此每种体系结构集成开发环境都有自己的特点。
        
        例如，Rapide的开发环境建立一个可执行的仿真系统并提供检查和过滤事件的功能，以此来允许体系结构执行行为的可视化；SADL的支持工具支持多层次抽象和具有可组合性的体系结构的求精。
        
        它要求在抽象和具体的体系结构之间建立名字映射和风格映射，两种映射通过严格的验证后，才能保证两个体系结构在求精意义上的正确性。
        
        这样可以有效地减少体系结构设计的错误，并且能够广泛、系统地实现对设计和正确性证明的重用。
      - 合理使用体系结构集成开发环境原型
        
        原型框架为可扩展性开发工具的设计提供了良好的接口。
        
        例如XArch系统可以通过添加语言符号或定义FEAL兼容的体系结构描述语言来扩展现有的功能。
        
        这样，体系结构专用的功能就可以作为动态插件应用到集成开发环境中，增强开发工具的功能，扩大它的使用范围。
- 基于软件体系结构的开发环境ArchStudio 4
  - ArchStudio 4的作用
    - ArchStudio 4 是美国加州大学欧文分校的软件研究院开发的面向体系结构的基于xADL2.0的开源集成开发环境。
    - 它除了具备普通体系结构建模功能外，还提供了对系统运行时刻和设计时刻的元素的建模支持，类似版本、选项和变量等更高级的配置管理观念，以及对软件产品线体系结构的建模支持。
    - ArchStudio 4在前一版的基础上添加了新的特性和功能，在可扩展性、系统实施和工程性上有新的发展。
    - ArchStudio 4的作用主要体现在基本功能和扩展功能两方面。它不但实现了建模、可视化、检测和系统实施等基本功能，还良好地支持这些功能的扩展。
      - 建模
        
        作为软件体系结构开发辅助工具，ArchStudio 4最主要的功能就是帮助用户用文档或者图形方式表达设计思想。
        
        模型像建筑蓝图一样从较高的角度把系统抽象成一个框架，抽象的结果将以XML的形式存储和操作。
        
        用户可以利用系统多个视角对该模型进行考察和研究。
        
        此外，ArchStudio 4还支持体系结构分层建模、软件产品线建模，而且可以时刻监视变化的体系结构。
      - 可视化
        
        ArchStudio 4提供了多种可视化的构件，例如视图和编辑器。
        
        视图和编辑器用文本或图形方式形象化体系结构描述
        
        例如Archipelago、ArchEdit、Type Wright等工具，同时也给系统涉众提供了交互和理解的平台。
      - 检测
        
        ArchStudio 4集成了功能强大的体系结构分析和测试工具Schematron
        
        它通过运行一系列预定的或用户定义的测试来检查系统
        
        Archlight根据标准来自动测试体系结构描述的正确性、一致性和完整性等
        
        检查出来的错误会显示出来，同时帮助用户定位出错的地方并提供修改途径和方法。
      - 实施
        
        它帮助将体系结构运用到实施的系统中。
        
        ArchStudio使用自己的体系结构设计思想和方法来实现自身。
        
        ArchStudio本身的体系结构是用xADL2.0详细描述的，这些文件都是实施的一部分。
        
        一旦ArchStudio在机器上运行，它的体系结构描述将被解析，这些信息将被实例化并连接到预定的构件和连接件上。
      - 除此以外，ArchStudio 4对上述的功能提供了良好的扩展机制
        
        它基于xADL2.0，而xADL2.0是模块化的，不是一个独立的整体。
        
        它没有将所有词法和语法一起定义，而是采用根据XML模式分解模块的方式。
        
        如图10-5所示，每个模块相互分裂，侧重实现系统的某一功能，4个模块都与中间的模块交互，5个模块共同组成了一个有机的系统。
        
        图10-5
        
        例如，可将构件和连接件分解为多个相互关联的模块。
        
        目前，模块技术已经能处理构件和连接件等低层次的构件，还能处理软件产品线、实施映射、体系结构状态。
        
        ArchStudio 4根据模式自动生成一个数据绑定库以便为别的工具提供共享功能。
        
        这样，用户就可以扩展xADL语言的新特性并自动生成支持新特性交互的库。
        
        总之，ArchStudio在xADL2.0的支持下允许开发者定义新的语义和规则去获取更多的数据信息来满足新的需求(如图10-6所示)。
        
        图10-6
      - 可扩展的建模
        
        开发ArchStudio 4的目标就是要实现体系结构建模的可扩展性。
        
        它基于可扩展的体系结构描述语言xADL2.0，利用添加新的XML模式来支持模型扩展。
      - 可扩展的可视化
        
        可视化编辑器利用可扩展的插件机制添加对新体系结构描述语言元素编辑的功能。
      - 可扩展的检测
        
        用户可以在Schematron中设计新的测试，也可以集成新的分析引擎来满足高要求的检验。
        
        在ArchStudio 4中，所有的检测工具都作为Archlight插件使用，因此用户可以通过添加插件完成新的测试。
        
        Archlight集成了功能强大的Schematron XML分析引擎，别的测试引擎也可以无缝地集成到Archlight中(如图10-7所示)。
        
        图10-7
      - 可扩展的实施
        
        用户可以灵活地把体系结构与Myx框架绑定起来。
        
        Myx是在ArchStudio 4建立的体系结构风格。
        
        此风格适合开发高性能的、灵活的集成开发环境。
        
        Myx-whitepaper定义了一套构件和连接件的构建规则，提供了定义构件同步和异步交互的模式，同时还规定了哪些构件可以相互约束，确定了构件间直接的或者分层的关系。
        
        在Myx风格的约束下，构件之间的相对独立有利于构件重用，构件只能通过显示接口与外界传递消息，因此不需对构件重新编码就可以在不同配置的构件间建立联系。
        
        此外，动态代理和事件处理机制支持在运行时刻控制连接状态。
  - 安装ArchStudio 4
    - 硬件配置需求
      - 硬件配置取决于具体的实际应用需求，例如程序规模、程序预期的运行时间等。
      - 对于ArchStudio 4来说，使用x86体系结构兼容的计算机，Pentiun Ⅲ处理器，128 MB内存以上的配置即可。
    - 软件配置需求
      - ArchStudio 4是开源开发工具Eclipse的插件。
      - 它可以在任何支持Eclipse的系统上运行。
      - 不过，必须有JRE1.5或者更高版本和Eclipse3.2.1或者更高版本的支持。
    - 安装ArchStudio 4
      - 安装过程只需按照安装向导进行即可，具体的步骤如下：
        
        (1) 在“Eclipse”菜单栏上单击“Help”按钮，在菜单列表中选择“Software Updates”→“Find and Install”命令。
        
        (2) 在弹出的“Install/Updates”窗口中选择“Search for new features to install”选项，单击“Next”按钮。
        
        (3) 在弹出的“Install”对话框中单击“New Remote Site”按钮；分别在“Name”文本框中输入一个名字标识，在URL文本框中填写“http://www.isr.uci.edu/projects/archstudioupdate”，确认这些信息后单击“Finish”按钮。
        
        (4) 在弹出的“Updates”窗口中，选择需要安装的属性，这里把所有的属性都选中。然后在许可确认对话框中，单击“同意”按钮继续后面的安装。
        
        等待Eclipse下载ArchStudio 4和相关工具，下载完成后在弹出的确认下载对话框中确认信息完成安装。
        
        重新启动Eclipse后，在Eclipse的菜单栏上单击“Windows”按钮，选择 “Open perspective”→“other”→“ArchStudio”命令，确认后就可以开始使用ArchStudio 4了。
        
        ArchStudio 4的界面如图10-8所示。
  - ArchStudio 4概述
    - 根据分工不同，把ArchStudio 4分为两部分：项目、文件夹、文件等资源管理器和完成绝大部分操作的工作台。
      - 资源管理器
        
        工作台的资源有3种基本类型：项目、文件夹和文件。
        
        文件与文件系统中的文件类似。
        
        文件夹与文件系统中的目录类似，文件夹包含在项目或其他文件夹中，文件夹也可包含文件和其他文件夹；项目包含文件夹和文件。与文件夹相似，项目映射为文件系统中的目录。
        
        创建项目时，系统会为项目在文件系统中指定一个存放位置。
        
        安装了Eclipse之后，在安装目录下会创建一个workspace文件夹，每当Eclipse新生成一个项目时，默认情况下会在workspace中产生和项目同名的文件夹，该文件夹将存放该项目所用到的全部文件。
        
        可以使用Windows资源管理器直接访问或维护这些文件。
      - ArchStudio 4的工作台
        
        ArchStudio 4的工作台通过创建、管理和导航资源来支持无缝的工具集成，它可以被划分为3个模块：视图、编辑器、菜单和工具条。
        
        视图
        
        打开ArchStudio 4的工作窗口发现有4个主要窗格，它们拥有特定的属性，代表了不同的视图。
        
        主要的视图有：导航器视图、大纲视图和ArchStudio 4视图。
        
        导航器视图
        
        图10-9
        
        导航器视图是系统资源的导航，以层次结构形象地显示了工程、文件夹、文件以及它们之间的关系。
        
        用户可以选择某个文档对其进行查看、编辑或管理等操作，同时也可以选择多个对象进行集合操作。
        
        大纲视图
        
        图10-10
        
        大纲视图以树状结构显示了在导航器视图中被选择的系统的内容。
        
        该视图按体系结构实例、类型、架构、测试等内容对系统信息进行分类和管理。
        
        ArchStudio 4视图
        
        图10-11
        
        深色背景的窗格显示的是ArchStudio 4视图。
        
        标签栏和显示区域将窗格分为两部分。
        
        标签栏将6种ArchStudio 4视图有效地集合在一起：ArchStudio 4 Laucher、File Tracker View、Archlight Issues、Archlight Notices、Tasks和File Manager View。显示区域将活动视图的具体内容和信息展示出来。
        
        ArchStudio 4 Launcher
        
        此视图的主要任务是提供打开文档并激活相应的工具。
        
        它不执行任何编辑、运行或者检查工作，只是帮助文件导航到需要的操作环境中。任何对文档的操作都委托给编辑器。
        
        在窗口的右上角有3个快捷按钮，给用户操作提供了便利。
        
        第一个按钮上面有文档图标，用于创建一个新的体系结构描述文档；
        
        第二个按钮是链接ISR网站的快捷方式；第三个按钮是访问ArchStudio 4网站的快捷方式。
        
        左边ArchStudio 4图标下面排列了一组编辑器：ArchEdit、Archipelago、Archlight、Selector和Type Wrangler。
        
        有两种方式选用编辑器处理文档：用户可以将被处理的文档从导航器视图拖到相应的编辑器上，也可以先单击编辑器再选择要处理的文档。
        
        Archlight Issuses
        
        ArchStudio 4使用Schematron作为体系结构分析测试工具，测试的结果和相关信息将在Archlight Issuses视图中显示。
        
        如图10-12所示，该视图的第一列是错误图标。
        
        第二列简要叙述了检测出的语法错误、语义错误、不一致等错误信息。
        
        若用户希望更详细地了解和追踪错误可以右击提示信息，在弹出的信息窗口中有更详细的描述。
        
        ArchStudio 4提供了4种处理错误的方式：selector dialog box、type wrangler dialog box、ArchEdit view和Archipelago view。第三列显示了检查工具的名称。
        
        Schematron支持定义XML格式的xADL文档的约束管理，运行时它将按其列筛选出错误。
        
        Archlight Notices
        
        该视图(如图10-13所示)记录了Schematron启动后的活动情况。
        
        每次启动系统时，Schematron都会初始化，每执行一次校验也会有相应的信息被记录。
        
        Tasks
        
        任务视图(如图10-14所示)标记了系统生成的错误、警告和问题，当ArchStudio 4发生错误时会自动添加到任务视图中。
        
        通过任务视图，可以查看与特定文件及特定文件中的相关联的任务。
        
        用户可以新增任务并设置它们的优先级。
        
        视图将要执行的任务、所用的资源、路径和位置等信息简要地描述出来，它是管理系统任务简捷的方式。
        
        编辑器
        
        ArchEdit
        
        ArchEdit是语法驱动的编辑器，将体系结构用树状结构非代码的方式描述出来。
        
        系统遵循xADL模式并提供了建模框架。
        
        这些现成的建模元素被封装在模块中，对开发人员隐藏了具体的实现细节。
        
        虽然有固定的框架，但同时它也能灵活地支持新元素。
        
        ArchEdit不关心元素的语义，只是按照XML模式建立行为和接口。
        
        因此当新模式加入或原有模式改变时它不须改变，即自动支持新模式。
        
        Archipelago
        
        Archipelago是语义驱动的编辑器，像Rational Rose一样可以用方框和箭头将信息描绘出来。
        
        与之不同的是，Archipelago中的每一个图形元素都赋予了丰富的含义，元素和元素间的关系必须满足一些规范和约束，所有元素有机地组合形成一个整体。
        
        Archipelago编辑器提供了即点即到的操作方式，双击大纲视图中树状结构的节点，在右边的编辑器中就会以图形方式显示该元素。右击编辑器的空白处可以创建新的图形元素，也可以对选中的元素进行属性编辑和修改。
        
        窗格中的图形可以通过滚动条进行缩放。Archipelago还可以与ArchEdit或其他编辑器结合使用。
        
        例如，用Archipelago描绘的体系结构可以用ArchEdit对其求精；ArchEdit可以对某些Archipelago不能直接支持的模式元素进行操作；
        
        在ArchEdit中创建的元素都会在Archipelago编辑器中用图形形象地表示出来，其中的每个细微的修改都能马上在ArchEdit中反映出来。
        
        Archlight
        
        Archlight是ArchStudio 4的分析工具框架，提供了一个统一的用户界面，使用户可以选择测试体系结构的各种属性。
        
        所有的测试将以树状结构在大纲视图中显示出来，树的每个节点都代表了一个测试。
        
        由于体系结构和体系结构风格的多样性以及开发阶段的不同，有时并不需要对整个系统的所有细节进行检测。Archlight提供了一种可供选择的局部测试机制，用户可以根据具体需要定制测试方案并限制范围。
        
        为支持这种机制的运行，系统提供了3种测试状态，用户只需选择不同的状态就可以方便地更改测试方案，如图10-15所示。
        
        Selector
        
        选择器的全称是软件产品线选择器，首先介绍一下软件产品线的概念。
        
        软件产品线是一族相关的软件产品，它们的体系结构中有很多的部分是共享的，但各自又有特定的变异点。
        
        一个产品线中的各个产品可能是为不同地区定制化的，或者是因市场原因实现不同的特征集。
        
        而利用Sclector可以在需要时把某个产品线体系结构简化成另一个小型产品线，或者从整个体系结构中抽取出一部分形成某具体产品的体系结构。
        
        选择器提供了3种选择方式：Select、Prune和Version Prune，如图10-16所示。用户根据实际需求选择其中一种或多种方式执行。
        
        Type Wrangler
        
        Type Wrangler如图10-17所示。
        
        Type Wrangler为考察体系结构类型提供了帮助和支持，方便用户分析体系结构中的所有类型。
        
        可利用它添加或移除接口和签名，并判断构件和连接件是否符合类型一致性要求。
        
        菜单栏和工具栏
        
        除了视图和编辑器外，菜单栏、工具栏和其他快捷工具也给用户提供了操作便利。
        
        类似视图和编辑器，工作台的菜单栏和工具栏也会根据当前窗口的属性和任务发生变化。
        
        菜单栏包含了集成开发环境中几乎所有的命令，它为用户提供了文档操作、安装脚本程序的编译、调试、窗口操作等一系列的功能。
        
        菜单栏位于工作台的顶部、标题的下面。用户可以单击菜单或子菜单完成大部分操作。
        
        在菜单下是工具栏，由于工具栏比菜单操作更为便捷，故常常将一些常用菜单命令也同时安排在工具栏上。
        
        除了工作台的菜单栏和工具栏，某些视图和编辑器也有它们专用的菜单。菜单栏和工具栏为用户提供了一个方便且迅速的操作方法。　
        
        ArchStudio 4的使用
        
        略
- Acme工具和AcmeStudio环境
  - Acme工具是由卡耐基梅隆大学计算机科学学院(School of Computer Science，Carnegie Mellon University)的ABLE (Architecture Based Languages and Environments)项目组开发的。
    - 该项目的主要内容包括开发描述和利用体系结构风格的方法，为软件体系结构实践提供工具，为软件体系结构和体系结构风格的定义与分析创建形式化的基础。
  - Acme工具开发人员库(Acme Tool Developer’s Library)
    - Acme工具开发人员库(简称为AcmeLib)是一个可重用的类库，用于表示和操作Acme的设计。AcmeLib包括Java AcmeLib和C++ AcmeLib两种具体实现。
    - AcmeLib概述
      - 首先介绍AcmeLib提供的基本功能以及它所面向的应用。 AcmeLib可以读、写、操作用Acme体系结构描述语言定义的软件体系结构设计。AcmeLib框架是为支持两类应用程序的快速开发而设计的。
      - (1) 在ADL之间进行转换的工具(比如Rapide、Wright、UniCon和Aesop)。
        
        Acme体系结构描述语言的最初目的是把用一种ADL(如Aesop)描述的体系结构转换成用另一种不同的ADL(如UniCon)描述的体系结构。AcmeLib框架可被用作开发这类在Acme和其他静态体系结构描述语言之间进行转换的工具的基础。
      - (2) 以Acme为基础的体系结构设计和分析工具。
        
        除了开发转换工具，使用Acme框架还可以快速创建具有体系结构分析、操作和可视化等功能的应用程序。
        
        这些工具直接以Acme体系结构描述语言为目标，并能针对特定的应用或特定的体系结构风格进行定制。
        
        AcmeLib工具包中提供一套可重用的构件，它能够帮助软件体系结构工具开发人员降低开发难度，在付出尽可能少的代价的情况下开发定制基于Acme的工具。AcmeLib工具包具有如下基本功能和特点：
        
        为Acme体系结构描述提供了一个通用的、可扩展的、面向对象的二进制表示框架。这一框架包括一个编程接口工具，可以通过它来完成对Acme设计的操作。
        
        提供了一个Acme语法分析器。该分析器把文本化的Acme描述转换成AcmeLib的二进制对象表示。可以方便地扩展该分析器，使它能够支持对目标ADL定义的语义丰富的Acme属性类型的分析。
        
        提供了一个反语法分析器(导出器)，用于把AcmeLib的二进制对象表示转换成文本化的Acme描述。
        
        提供了一个转换辅助程序。
    - 开发定制的基于Acme的应用
      - 典型的基于AcmeLib的应用程序是这样的：对一个基于AcmeLib的应用程序来说，所设想的标准操作模式是调用语法分析器处理文本形式的Acme描述，对分析器返回的体系结构设计的二进制对象表示进行一系列的操作。
      - 操作结果的输出有两种方式，即向调用工具返回结果，或使用AcmeLib的反语法分析器输出修改后的文本形式的Acme描述。
      - 工具开发人员创建自己定制的基于AcmeLib的应用时可以选择使用两种方法：使用AcmeLib提供的通用API，或使用自定义的接口类集合。
      - 如果只是使用AcmeLib的通用API，开发人员在创建新的体系结构工具(或与现有工具相链接)时需要按照以下步骤进行：
        
        (1) 决定该工具将要操作的特定应用程序的Acme类型集合，为这些类型编写Acme规格说明。
        
        (2) 使用通用的AcmeLib API构造对Acme表述进行操作的体系结构设计工具。
        
        (3) 把任何所需的用户语法分析器链接起来，用来解析属性或外部体系结构描述语言。
        
        (4) 把开发人员的新工具和AcmeLib相链接。
      - 如果要使用自定义的接口类集合创建基于AcmeLib的应用程序，需要完成以下步骤：
        
        (1) 决定所要开发的工具要操作的特定应用程序的类型集合，为这些类型编写Acme规格说明。
        
        (2) 通过子类化AcmeLib的体系结构元素类型(构件、连接件等)为特定应用程序的Acme类型创建接口，这些接口类将为直接在特定应用程序Acme类型提供的属性和结构上进行操作提供方法。
        
        (3) 使用这些接口类和其余的AcmeLib提供的通用API创建所要的体系结构设计工具。
        
        (4) 把任何所需的用户语法分析器链接起来，用来解析属性或外部体系结构描述语言。
        
        (5) 把开发人员的新工具和AcmeLib相链接。　　
    - Acme设计结构
      - 这里我们概要介绍用于描述体系结构设计的Acme类，这些类为基于Acme模型操作体系结构设计定义了通用的API，并对表示体系结构设计的结构进行了总结，概述了重要的设计对象类及其关联。
      - 一个Acme设计的对象模型和用文本化的Acme语言描述的设计结构很相近。一个AcmeDesign包括一个全局体系结构元素类型集合、存储在全局类型空间AcmeTypeSpace中的属性类型定义(AcmeElementType和AcmePropertyType类的实例)。
      - 它还包括一个AcmeFamily类的实例的集合，其中的每一个与一个Family定义相关。Family定义是一组类型定义，是最终的模板定义。
      - 最后，一个AcmeDesign还包括一组AcmeSystem对象，它们描述了最高层的设计拓扑结构。
      - 一个AcmeDesign还含有一个AcmeTypeManager。
      - 类型管理器实例以元素类型和属性类型为基础，提供一个用来进行查找、实例化和检查元素实例及属性的类型的接口。
      - 一个AcmeTypeManager对象并不是设计的一部分，而是为对体系结构设计进行操作提供了一个接口。
  - AcmeStudio环境
    - AcmeStudio是一个图形化用户界面的软件体系结构开发环境。
    - 它既提供了Linux平台下的版本，也提供了Windows平台下的版本。
    - 尽管使用AcmeStudio开发环境和编辑器相当简单，但在设计具体应用时，使用者应当熟悉软件体系结构的建模方法，并熟悉Acme体系结构描述语言。
    - AcmeStudio以Acme通用体系结构描述语言为基础。
    - 它可以打开任何用Acme描述的体系结构设计。
    - 通常，这些Acme描述被存储在扩展名为 .acme的文件中。
    - 用户界面概述
      - 下面我们简单介绍AcmeStudio用户界面的组织。
      - AcmeStudio的图形用户界面采用的是Windows风格的多文档界面(MDI)模型，如图10-22所示。
        
        图10-22
        
        设计浏览器窗口
        
        使用AcmeStudio的第一步是打开一个现存的设计或创建一个新的设计。
        
        在AcmeStudio中打开的每个设计都会显示在单独的浏览器窗口中。
        
        浏览器窗口由多个不同的编辑视图组成，它们中的每个都显示在单独的、可调整大小的面板上。
        
        这些视图是同步的，即在一个视图上所做的更改会马上在其他相关视图中显示出来。
        
        Design Navigator
        
        Design Navigator窗口用树形结构显示了整个设计的层次体系。
        
        它包括体系结构描述中定义的所有类型和族，以及设计及其子结构中表示的所有系统。
        
        这个窗口的内容直接与文本形式的Acme描述的结构相关。
        
        通过选择此窗口中的树的不同条目，使用者可以访问设计中的不同元素。
        
        一旦选择了某个或某些元素，它们就会在Diagram View窗口或Element Workshop窗口显示出来。
        
        Diagram View
        
        Diagram View显示一个简单的图形编辑器，可以用通常的方式对构件、连接件、端口和角色进行选中、调整大小、移动等操作。
        
        但是，不同于大多数图形工具，Diagram View在显示系统图形时，使用的显示规范是在当前选择的图形风格(Diagram Style)中定义的，通过在图形风格列表中进行选择就可以用新的风格查看系统。
        
        每个元素的显示方式是以该元素的类型和属性为基础的。
        
        通过视觉外观我们就可以知道所选择元素的一些信息。
        
        Type Platte
        
        Type Platte显示体系结构元素类型的集合。
        
        这些类型构成的词汇表能用于编辑在Diagram View窗口中所选择的系统的设计。
        
        它不仅包括系统具有的各种族的类型，而且包括所有的全局类型的定义。
        
        在编辑一个系统时，Platte窗口显示4个列表：构件类型列表、连接件类型列表、端口类型列表和角色类型列表。
        
        在编辑一个构件类型时，Platte只显示端口类型。
        
        类似地，在编辑一个连接件类型时，只显示角色类型。
        
        通过选择一个类型并把它拖入Diagram View窗口，可以向系统中加入新的构件和连接件。
        
        同时，要向构件或连接件中拖入端口类型或角色类型来添加新的端口或角色。
        
        要注意的是，通过选择适当的菜单项，也可以向系统添加新的结构。
        
        Element Workshop
        
        Element Workshop显示当前选中对象的细节信息，包括对象的子结构以及元素的各种属性和表述。
        
        对于系统，子结构包括系统中的构件和连接件；对于构件，列出与此构件相关联的端口；对于连接件，列出与此连接件相关联的角色。
        
        双击一个元素或表述将导航到该条目上，并在Diagram View窗口中显示它。
        
        双击一个属性将显示属性编辑器，使用者可以用它来编辑属性值。
    - 执行基本任务
      - 下面我们介绍怎样在AcmeStudio中执行一些基本任务。
      - 与大多数应用程序类似，往往可以使用多种操作完成同一个任务。
      - 例如，可以使用右键弹出菜单执行一个命令，也可以通过应用程序的主菜单完成相应的任务，或通过拖拽操作完成该任务。
      - 与设计有关的任务
        
        类似于大多数Windows应用程序，可以通过“File”菜单完成打开和保存操作。、
        
        如果要创建新的设计，则按以下步骤进行：
        
        (1) 从菜单中选取“File”→“New Design…”。
        
        (2) 选择族，新的设计中的顶层系统将在所选的族中创建。在对话框中将显示AcmeStudio\Families目录下所有的族。通过把新的包含族描述的*.acme文件拷贝到该目录中，就可以向库中加入新的族。
        
        如果要添加新的构件或连接件，则按以下步骤进行：
        
        (1) 通过单击构件/连接件类型并把它拖拽到图形中，在Type Palette中选择类型。
        
        (2) 在设计上释放鼠标。这样，就在该系统中创建了一个该类型的构件或连接件的新的实例。缺省情况下，系统会根据类型名自动为该实例分配一个名称。
        
        或者，也可以按以下步骤进行：
        
        (1) 从应用程序菜单中选择“Insert”→“New Component…”或者“Insert”→“New Connector…”，然后，系统会提示对新元素的其他信息进行选择。
        
        (2) 为新元素提供一个名称，并为其选择一个类型。
      - 与表述有关的任务
        
        在Acme中，系统、构件、连接件、端口或角色都可以有一个表述(Acme Representation)。
        
        在当前版本中，可以查看并编辑系统、构件和连接件的表述，也可以打开包含端口表述和角色表述的系统设计，但不能通过编辑环境访问它们。
        
        如果要为构件或连接件添加一个新的表述，则按以下步骤进行：
        
        (1) 在系统视图中选择一个构件或连接件。
        
        (2) 在主菜单中选择“Insert”→“New Representation…”。
        
        如果要导航到一个现有的表述并在系统视图中把它显示出来，则按以下步骤进行：
        
        (1) 在系统视图中选择一个构件或连接件。
        
        (2) 从主菜单中选择“View”→“Open Representation”，或从元素的右键弹出菜单中选择“Open Representation”。
      - 使用剪贴板进行复制、剪切和粘贴操作
        
        可以对系统结构(即一些构件和连接件及其关联构成的集合)进行各种剪贴板操作。
        
        在当前版本中，能够在Diagram View窗口中对构件和连接件的图形表示(以及它们所包含的端口和角色)进行剪切和粘贴操作。
        
        预计在将来的版本中会提供更为丰富的功能。
        
        如果要剪切/复制构件或连接件的集合，则按以下步骤进行：
        
        (1) 在图中选择想要剪切或复制的构件和连接件组成的子图。
        
        (2) 选择“Edit”→“Copy”或“Edit”→“Cut”菜单项。
        
        如果要粘贴元素集合，则按以下步骤进行：
        
        (1) 导航到要把子图粘贴到的那个系统。
        
        (2) 选择“Edit”→“Paste”菜单项。
        
        这非常简单，与一般的编辑器中的操作基本是相同的。但需要注意，也可以用文本的形式把元素粘贴到设计中去。
        
        这里要使用“Edit”→“Paste Acme Text”菜单项。这些文本应当包括对构件、连接件或系统的Acme描述。
        
        例如，可以在其他文本编辑器中输入如下文本：
      - 与族和类型有关的任务
        
        通过在主菜单中选择“Type”→“Families…”或通过Design Browse窗口访问族和类型的目录，可以执行与族和类型有关的操作。
        
        在Acme中，一个体系结构设计描述包括一组族，可在设计中使用它们。
        
        在设计中为了定义一个属于某个特定族的系统，必须先要把这个族添加到设计中。
        
        可以采用两种操作方式：从头开始创建一个新的族，或者导入一个现有的族。
        
        如果要向设计中加入新的族，则按以下步骤进行：
        
        (1) 在“Type”菜单中选择“Families…”。这将打开一个对话框，其中列出了与当前设计有关的所有的族，而不是只有当前被编辑的系统所指定的族。　　
        
        (2) 单击“New…”按钮，打开另一个对话框，在这里为新建的族命名。如果要向设计中导入一个族，则单击“Import…”按钮，然后选择一个Acme描述文件。
        
        如果要指定一个系统的族，则可以从“Families”对话框中选择当前系统的族。这样做就把当前系统和这个族关联了起来。
        
        另一种办法是，在Design Browser窗口中或在Diagram View窗口中使用右键菜单，选择“Assign Families…”菜单项。
        
        如果要为族添加一个新的类型，则在AcmeStudio中可以这样创建一个新的元素类型：首先在设计中创建一个构件、连接件、端口或角色，然后使用“Type…”→“Create type from prototype…”把它转换成一个类型。使用“Create type in current family”选项，可以在与当前编辑的系统相关的族中创建一个新的类型；使用“Create type in global type space”选项，可以在一个设计的全局类型那个空间中创建一个新的类型。
      - 与图形风格(Diagram Style)有关的任务
        
        通过选择主菜单中的“View”→“Diagram”→“Diagram Styles…”，可以对图形风格进行编辑，并添加新的风格。
        
        一般情况下，可以为所要使用的每个族定义一种图形风格。在每种图形风格中，定义了该族中各类型的视觉效果。
        
        如果要为当前系统选择一种图形风格，则通过在图形风格工具条的下拉框中进行选择。另一种方法是使用主菜单的“View”→“Diagram Styles…”选项，然后单击“Assign Style to Current System”按钮。
        
        如果要创建新的图形风格，则在“View”→“Diagram Styles…”所打开的对话框中单击“New…”按钮即可。
        
        如果要为一个图形风格添加新的视觉效果，则按以下步骤进行：
        
        (1) 从主菜单中选择“View”→“Diagram”→“Diagram Styles…”菜单项，并使用图形风格对话框选择所要编辑的图形风格；或者选择“View”→“Diagram”→“Edit Current Diagram Style…”菜单项，编辑当前系统所使用的图形风格。
        
        (2) 单击“New…”按钮，选择是否创建新的构件、连接件、端口或角色的视觉效果。
软件体系结构评估
- 软件体系结构评估概述
  - 评估关注的质量属性
    - 软件体系结构的设计是整个软件开发过程中关键的一步。
    - 对于当今世界上庞大而复杂的系统来说，如果没有一个合适的体系结构而要有一个成功的软件设计几乎是不可想象的。
    - 不同类型的系统需要不同的体系结构，甚至一个系统的不同子系统也需要不同的体系结构。体系结构的选择是一个软件系统设计成败的关键。
      - 但是，怎样才能知道为软件系统所选用的体系结构是否恰当？
      - 如何确保按照所选用的体系结构能顺利地开发出成功的软件产品呢？
    - 体系结构评估可以只针对一个体系结构，也可以针对一组体系结构。
    - 在体系结构评估过程中，评估人员所关注的是系统的质量属性，所有评估方法所普遍关注的质量属性有以下几个。
      - 性能
        
        性能是指系统的响应能力，即要经过多长时间才能对某个事件作出响应，或者在某段时间内系统所能处理的事件的个数。
        
        经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的表示。
        
        性能测试经常要使用基准测试程序(用以测量性能指标的特定事务集或工作量环境)。
      - 可靠性
        
        可靠性是软件系统在应用或系统错误面前、在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
        
        可靠性是最重要的软件特性，通常用它衡量在规定的条件和时间内，软件完成规定功能的能力。
        
        可靠性通常用平均失效等待时间(Mean Time To Failure，MTTF)(指软件在失效前正常工作的平均统计时间 )和平均失效间隔时间(Mean Time Between Failure，MTBF)来衡量。
        
        在失效率为常数和修复时间很短的情况下，MTTF和MTBF几乎相等。MTBF可用下式表示：
        
        MTBF = MTTF + MTTR(平均修复时间)
        
        可靠性可以分为两个方面
        
        容错
        
        其目的是在错误发生时确保系统正确的行为，并进行内部“修复”。
        
        例如在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。
        
        在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作直到错误再次发生。
        
        健壮性
        
        其能保护应用程序不受错误使用和错误输入的影响，在遇到意外错误事件时确保应用系统处于已经定义好的状态。
        
        和容错相比，健壮性并不是在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。
        
        软件体系结构对软件系统的可靠性有巨大的影响。
        
        例如，软件体系结构通过在应用程序内部包含冗余、集成监控控件和异常处理来支持可靠性。
      - 可用性
        
        可用性是系统能够正常运行的时间比例。
        
        经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
      - 安全性
        
        安全性是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
        
        安全性是根据系统可能受到的安全威胁的类型来分类的。
        
        安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
        
        机密性保证信息不泄露给未授权的用户、实体或过程
        
        完整性保证信息的完整和准确，防止信息被非法修改
        
        不可否认性是指正确认定发送者，使之不能否认已发送过的数据的过程
        
        可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
      - 可修改性
        
        可修改性是指能够快速地以较高的性能代价比对系统进行变更的能力。
        
        通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
        
        可修改性包含四个方面：
        
        (1) 可维护性
        
        这主要体现在问题的修复上；在错误发生后“修复”软件系统。
        
        做好为可维护性准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
        
        (2) 可扩展性
        
        这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。
        
        为了实现可扩展性，软件系统需要松散耦合的构件。
        
        其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。
        
        支持把新构件集成到现有的体系结构中也是必要的。
        
        (3) 结构重组
        
        这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。
        
        为了支持结构重组，软件系统需要精心设计构件之间的关系。
        
        理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
        
        (4) 可移植性
        
        可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。
        
        为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。
        
        可移植性是系统能够在不同计算环境下运行的能力。
        
        这些环境可能是硬件、软件，也可能是两者的结合。
        
        在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。
        
        如果移植到新的系统需要作些更改，则可移植性就是一种特殊的可修改性。
      - 功能性
        
        功能性是系统能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
      - 可变性
        
        可变性是指体系结构经扩充或变更而成为新体系结构的能力。
        
        这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。
        
        当要将某个体系结构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。
      - 可集成性
        
        可集成性是指系统能与其他系统协作的程度。
      - 互操作性
        
        作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。
        
        为了支持互操作性，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。
        
        程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。
  - 评估的必要性
    - Barry Boehm说过，“匆忙之中选择某个体系结构，闲暇之时就会深深懊悔”。糟糕的体系结构实际上宣判了项目的死刑。
    - 关于评估的必要性有以下三点：
      - (1) 软件体系结构反映了系统最初始的设计决策
        
        对同样一个问题，在初始阶段纠正所带来的花费和在测试或部署阶段纠正导致的开销不在一个数量级。
        
        毕竟在体系结构视图上一个符号改动比后期大规模的代码改动工作量要少得多，这样，巨大的额外开销就避免了。
        
        有了对体系结构的完整描述，退一步讲即使是部分描述，也能模拟系统运行时的行为，对一些设计思想进行探讨，并推断体系结构应用于系统时的潜在影响。
        
        而所有这些工作只不过需要整个项目周期中的几天时间。
      - (2) 评估是挖掘隐性需求并将其补充到设计中的最后机会
        
        由于缺乏充分的交流和不能对软件项目透彻理解，许多涉众并不知道自己到底想要什么。
        
        在需求获取阶段，他们会列出自认为最重要的几项要求。但是评估之后，这些观点可能会变动很大。
        
        有些起初重视的方面可能并不是那么重要，而另一些本来看上去无关紧要的东西却被发现需要花更多精力来处理。
        
        在评估过程中，涉众会感受到群体力量的强大，同时对自己的参与带来的正面影响也很振奋。
        
        而架构师会在此阶段的活动中了解涉众的各种想法，调整初始设计以做出权衡(也可能是对候选体系结构的对比和选择)。
        
        对架构师来讲，这也是加深对待建系统理解的好机会。
        
        总之，体系结构评估清除了涉众的沟通障碍。其最直接的结果就是得到各方满意的系统蓝图，而这至少意味着项目成功了一半。
      - (3) 体系结构是开发过程的中心，它决定了团队组织、任务分配、配置管理、文档组织、管理策略，当然还有开发进程安排。
        
        不良体系结构往往带来一塌糊涂的效果，因为它在被使用过程中必须被修改以适应新的考量，或者去弥补那些在开发早期阶段没有考虑到的缺陷，在这些方面进行修改需要花费大量成本。
        
        更糟糕的是，团队会面临着项目失控的可怕境遇：改了旧错误带来了更多的新错误；过时的体系结构会破坏现有的开发团队结构，而这又进一步干扰了开发工作；客户、管理层和开发者都急切地盼望者噩梦结束，但谁都不知道这样的日子何时到来。
        
        如果在这些发生之前充分分析一下体系结构就可以部分避免这些问题的发生。
        
        因此，体系结构想要付诸实践的话，就必须被评估。
- 软件体系结构评估的主要方式
  - 主要评估方式简介和比较
    - 从目前已有的软件体系结构评估技术来看，某些技术通过与经验丰富的设计人员交流获取他们对待评估软件体系结构的意见；某些技术对针对代码质量度量进行扩展以自底向上地推测软件体系结构的质量；某些技术分析把对系统的质量的需求转换为一系列与系统的交互活动，分析软件体系结构对这一系列活动的支持程度等。
    - 尽管看起来它们采用的评估方式都各不相同，但基本可以归纳为三类主要的评估方式：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。
      - 基于调查问卷或检查表的评估方式
        
        卡耐基梅隆大学的软件工程研究所(CMU/SEI)的软件风险评估过程采用了这一方法。
        
        调查问卷是一系列可以应用到各种体系结构评估的相关问题，其中有些问题可能涉及到体系结构的设计决策；有些问题涉及到体系结构的文档，例如体系结构的表示用的是何种ADL；有的问题针对体系结构描述本身的细节问题，如系统的核心功能是否与界面分开。
        
        检查表中也包含一系列比调查问卷更细节和具体的问题，它们更趋向于考察某些关心的质量属性。
        
        例如，对实时信息系统的性能进行考察时，很可能问到系统是否反复多次地将同样的数据写入磁盘等。
        
        这一评估方式比较自由灵活，可评估多种质量属性，也可以在软件体系结构设计的多个阶段进行。
        
        但是由于评估的结果很大程度上来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。
        
        尽管基于调查问卷与检查表的评估方式相对比较主观，但由于系统相关人员的经验和知识是评估软件体系结构的重要信息来源，因而它仍然是进行软件体系结构评估的重要途径之一。
      - 基于场景的评估方式
        
        场景是一系列有序的使用或修改系统的步骤。
        
        基于场景的方式由SEI首先提出并应用在体系结构权衡分析方法(Architecture Tradeoff Analysis Method，ATAM)和软件体系结构分析方法(Software Architecture Analysis Method，SAAM)中。
        
        这种软件体系结构评估方式分析软件体系结构对场景，也就是对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。
        
        例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。
        
        这一评估方式考虑到了包括系统的开发人员、维护人员、最终用户、管理人员、测试人员等在内的所有与系统相关的人员对质量的要求。
        
        基于场景的评估方式涉及到的基本活动包括确定应用领域的功能和软件体系结构的结构之间的映射，设计用于体现待评估质量属性的场景以及分析软件体系结构对场景的支持程度。
        
        不同的应用系统对同一质量属性的理解可能不同，例如，对操作系统来说，可移植性被理解为系统可在不同的硬件平台上运行，而对于普通的应用系统而言，可移植性往往是指该系统可在不同的操作系统上运行。
        
        由于存在这种不一致性，对一个领域适合的场景设计在另一个领域内未必合适，因此基于场景的评估方式是特定于领域的。
        
        这一评估方式的实施者一方面需要有丰富的领域知识以对某一质量需求设计出合理的场景，另一方面，必须对待评估的软件体系结构有一定的了解以准确判断它是否支持场景描述的一系列活动。
      - 基于度量的评估方式
        
        度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数、构件个数等。
        
        传统的度量研究主要针对代码，但近年来也出现了一些针对高层设计的度量，软件体系结构度量即是其中之一。
        
        代码度量和代码质量之间存在着重要的联系，类似地，软件体系结构度量应该也能够作为评判质量的重要的依据。
        
        赫尔辛基大学提出的基于模式挖掘的面向对象软件体系结构度量技术、 Karlskrona和Ronneby提出的基于面向对象度量的软件体系结构可维护性评估、西弗吉尼亚大学提出的软件体系结构度量方法等都在这方面进行了探索，提出了一些可操作的具体方案。
        
        我们把这类评估方式称做基于度量的评估方式。
        
        基于度量的评估技术都涉及三个基本活动：
        
        首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；
        
        然后从软件体系结构文档中获取度量信息；
        
        最后根据映射原则分析推导出系统的某些质量属性。
        
        因此，这些评估技术被认为都采用了基于度量的评估方式。
        
        基于度量的评估方式提供更为客观和量化的质量评估。
        
        这一评估方式需要在软件体系结构的设计基本完成以后才能进行，而且需要评估人员对待评估的体系结构十分了解，否则不能获取准确的度量。
        
        自动的软件体系结构度量获取工具能在一定程度上简化评估的难度，例如MAISA可从文本格式的UML图中抽取面向对象体系结构的度量。
      - 三种评估方式比较
        
        经过对三类主要的软件体系结构质量评估方式的分析，表7-1从通用性、评估者对体系结构的了解程度、评估实施阶段、评估方式的客观程度等方面对这三种方式进行简单的比较。
        
        表7-1
  - 基于场景的评估方法概念介绍
    - 最著名的体系结构评估方法均是基于场景的。
    - 场景是系统使用或改动的假定情况集合。各种场景可以抽象成包含6个部分的一般形式，以方便后期的评估。
      - (1) 刺激源
        
        这是某个生成该刺激的实体(人、计算机系统或任何其他可以起到刺激作用的实体)。
      - (2) 刺激
        
        刺激源对系统的影响。
      - (3) 环境
        
        与刺激相关的上下文条件。当刺激发生时，系统可能处于过载，或者正在运行，也可能是其他情况。
      - (4) 制品
        
        接收刺激的实体。
        
        可能是整个系统，也可能是系统的一部分。
      - (5) 响应
        
        是在刺激到达后所采取的行动。
      - (6) 响应度量
        
        当响应发生时，应该能够以某种方式对其进行度量，以对需求进行测试来确定其是否能被满足。
    - 场景的一个优点就在于它是针对特定系统的，也就是说它不会被领域所限。
    - 场景可以充分自由地表达刺激源导致的系统响应。
    - 更重要的是场景可以将多个涉众的建议统一起来。
    - 不同的涉众可以对相似的情况从各自的角度作出解释，然后这些解释就可以在删除冗余信息后整合到一个场景里。
    - 若干知名的评估方法均使用场景，例如SAAM、ATAM、SAEM等。下面对其中的SAAM和ATAM方法进行较详细的介绍。
- SAAM软件体系结构分析方法
  　　SAAM是最早精心设计并形成文档的分析方法。它出现于1993年，发表于1994年(Kazman，1994)。后来Kazman对其进行改进，在参考文献[72]中对其提供了几个深入的案例研究。　　SAAM是一种直观的方法，它试图通过场景来测量软件的质量，而不是泛泛的不精确的质量属性描述。SAAM也比较简单，仅仅考虑场景和体系结构的关系，也不涉及太多的步骤和独特的技术。　　于是，它成为体系结构评估初学者的理想入门方法。SAAM最初是为了评估体系结构的可修改性而设计，不过经过演化和实际应用，在许多其他常见的质量属性评估方面也展现了威力，并成为其他一些评估方法的基础，比如ATAM。利用预先定义的场景，SAAM可以检查出被评估体系结构的潜在风险，并对几个候选体系结构进行比较。　　另外，SAAM可以为很多涉众进行(可能是项目启动后的第一次)讨论提供平台。这样大家就有机会用人人都懂的语言来说出各自关心的问题，了解别人所关心的，并看到这些问题又是如何在蓝图中处理的。在此过程中，理解上的偏差和不正确的设计都将被发现。
  - SAAM的一般步骤
    - SAAM的一般步骤看上去非常简单直观，图7-1揭示了评估的一般步骤，每个阶段能得到什么，各个阶段的关系如何。
    - 图7-1
    - 从图7-1可以清楚地看到SAAM的输入、输出。
    - 为了开始评估，必须提供一个体系结构描述，该描述可以是所有参与者能接受并理解的任何形式。
    - 根据特定评估的对象和关注点，描述的详细程度和范围可能不同，有时也需要进行更新或补充。
    - 多种不同的候选体系结构的描述都可以拿来评估以便对比和选择。
    - 场景是体系结构描述之外的另一个关键输入。
      - 基于场景的评估方法的基本要点就是检查当前的体系结构能否直接满足期望的质量需求，并在不能满足时看看可以怎样改动。
      - 我们几乎不可能对质量属性进行精确测量，
      - 可又希望质量属性对评估有意义，所以必须以一种更实在的形式来表述它。这就是场景为什么这么重要的原因。
      - 有些场景可能可以在功能性需求中提取出来，不过大多数都是源自涉众的讨论和头脑风暴。
      - 当然，待评估的体系结构起码得支持需求说明中的所有功能。
      - 而评估过程的关键是搞清楚体系结构是否能在满足需求的情况下拥有良好的质量属性。
    - SAAM主要是以评估报告的形式输出。
    - 如果是评估单个体系结构，那么报告的内容将包括该体系结构设计不能满足质量需求的缺陷；多个体系结构情况下将报告哪个候选体系结构能最好地满足场景。
    - 由不适当分解或过分复杂导致的不良设计也会在报告中被指出。
    - 最后，SAAM可以估计修改导致的费用和范围，以避免盲目的修改。
    - 除此之外，SAAM还有一些优点。
      - 它增强了涉众对体系结构的理解，强制对体系结构更好的编档，澄清系统将来演化最可能的方向。
      - 通过涉众广泛的讨论，业务目标的优先级和潜在的场景也得以澄清。
  - 场景生成
    - 场景生成是各种涉众参与讨论和头脑风暴的过程。
    - 每个参与者都有自己的视角，并提供基于此的场景。
    - 对于某个修改，项目投资方关注其导致的费用，程序员在意哪些模块将受到影响，买主关心价格，最终用户关心由修改带来的好处。有关联的，甚至是相互矛盾的场景可能在这个过程中出现并被编档。
    - 评估过程中最重要的是保证一个可以自由进行评论的氛围。
    - 生成的所有场景都应该认真记录到列表中以便涉众之后审查。
    - 对那些缺乏评估经验的人，可能需要一个指导教程，这样才能保证“好”的场景生成。
    - 所谓“好”场景，是指这些场景反映了系统主要用例、潜在修改或更新，或系统行为必须符合的其他质量指标。
    - 此阶段可能会迭代进行几次。
    - 收集场景的时候，参与者可能会在当时的文档中找不到需要的体系结构信息。
    - 而补充的体系结构描述反过来又会触发更多的场景。
    - 场景开发和体系结构描述是互相关联、互相驱动的。
  - 体系结构描述
    - 体系结构文档包括了需要评估的信息，当然大多数信息都是在评估前就必须准备好的。
    - 为了更好地进行评估，体系结构描述应该以一种参与者都能接受的形式表达，对构件、连接件、模块、配置、依赖、部署等概念要区分清楚。
    - 只要能清晰无歧义，自然语言、框图、数据表或者形式化模型等任何形式都可以用来表达体系结构。
    - 如上节所述，场景生成和体系结构描述阶段可能会迭代进行几次，它们互相关联、互相驱动。
  - 场景的分类和优先级确定
    - SAAM中的场景分为两类：直接场景和间接场景
      - 直接场景
        
        直接场景指当前体系结构不经修改即可支持的场景。
        
        如果一个场景能在原始需求(该需求在设计当前体系结构时已经被考虑)找到类似的内容，那么显然该场景很容易被满足。
        
        架构师可以引入一系列的响应行为来证明这些场景确实得到满足。
        
        通常，直接场景虽然对揭示体系结构缺陷没有帮助，却可以提高涉众对体系结构的理解程度，有助于对其他场景的评估。
      - 间接场景
        
        间接场景不能直接被当前体系结构支持。
        
        为了满足间接场景，就需要对体系结构进行某种修改，比如添加一个或多个构件、取出间接层、用更合适的模块替代、改变或增强接口、重定义元素间关系或者上述情况组合。
        
        间接场景是SAAM后续活动最关键的驱动器。
        
        通过充分考虑各种间接场景，可以在很大程度上预测系统将来的演化，尽管这种预测可能很模糊。
    - 有了架构师的帮助，对场景分类就很容易了。纵然如此，场景还是可能会多到无法一一仔细评估。
      - 由于时间和资源有限，就需要通过设置优先级的方法来选择最关键的场景。
      - CMU SEI建议以涉众范围内投票的方式决定哪些是“关键”的。
      - 每个人都拿到固定数量的选票，大概是场景总数的30%。
      - 投票策略是只要每个人投票总数不超过手中的选票总数，他可以为任何场景投任何数目的票。
      - 然后按照得到选票数目的顺序对所有场景进行排序，并根据具体情况选择一定数目的排序靠前的场景。
      - 有时候，排序后的列表可能会有一个泾渭分明的分界，一边是得票数很多的场景，另一边得票数很少(如图7-2所示)的场景，那么直接选择得票多的场景即可。
      - 图7-2
      - 其他时候，可以计算一下评估多少场景比较适合，或者估计一下评估时间内能完成多少。
      - 典型的比如说，一整天可以评估完8个场景而计划两天的时间进行场景的单个评估，那么选择15或16个比较合适。
      - 要注意的是即使根据预先定好的规则某些场景是应该放弃的，但如果它们的提出者仍然坚持而其他人又不反对的话，那么也可以添加到“关键”列表中。
  - 间接场景的单独评估
    - 涉众最关心的信息莫过于间接场景会怎么影响当前的候选体系结构。
    - 需要做什么修改？修改是否在项目预期的费用、时限和范围内？如果是，那么到底需要多少额外的工作？如果不是，有没有替代方案？
    - 这些问题在评估的这个阶段都需要回答。
    - 对于每个候选体系结构，都要评估一下在每个间接场景下的表现。在此，体系结构的元素被映射到具体的质量属性。
    - 间接场景都要求改动当前体系结构。
    - 大多数时候，架构师负责解释需要的变更。
    - 如果连他们都没法说清楚该如何处理这些变更，评估前体系结构描述的完整性就值得怀疑了。
    - 具体来说，这种解释包括改动涉及的范围、该范围内具体的元素和估计的工作量。
    - 一般这些信息都要以表7-2的形式进行总结。
    - 表7-2给出了后续变更工作的启动基础。
    - 涉众根据此表就可以决定哪些工作是最紧急并需要尽快进行，哪些工作应该延迟一段时间，还有哪些工作因其完成的可能性不高不应该在当前项目中实施。
    - 如果一个场景需要过多修改，可以认为有设计缺陷，可能需要在修改发生处做重新设计。
  - 对场景关联的评估
    - 如果不同的场景都要求对同一个体系结构元素进行修改，则称这些场景关联于此元素。
    - 场景关联意味着原始设计的潜在风险。
    - 这里需要强调的一点是，所谓场景“不同”是指场景的语义有差异，该语义由涉众决定。
    - 在分类和设置优先级处理之前，有共同点的场景可以被归为一组或合并以避免评估冗余，最终保留那些反映典型用例、典型修改或其他质量属性而又很少重叠的场景。
    - 语义不同的场景影响同一体系结构元素(比如，同一个构件)的情况表明设计不良。
    - 场景关联的程度高意味着功能分解不良，当然如果某些经典体系结构模式的工作方式就是如此，就可以当例外来处理。
    - 一般说来，场景关联可能是灾难的种子，因为将来系统演化的时候该关联会导致混乱的修改。虽然无需认定所有的场景都是灾难之源，但它们必须得到足够的重视。
    - 不过在识别场景关联时要小心一些伪关联。
    - 有时体系结构文档表明某个构件参与了某个关联，但是实际上是该构件内部分解良好的子构件独立处理了不同的“关联”场景。
    - 这时可以返回到步骤2——体系结构描述，检查一下文档的详细程度是否满足关联识别所需。
  - 形成总体评估
    - SAAM的最后一步是形成总结报告。
    - 如果候选体系结构只有一个，那么总体评估要做的就是审查前面步骤的结果并总结成报告。修改计划将基于此报告。
    - 如果有多个候选体系结构，就需要进行一番比较。
    - 为此需要根据各个关键场景和商务目标的关系来决定每个关键场景的权重。
    - 比较体系结构时会发现，某个体系结构在某些场景下表现突出，而另一个体系结构在另一些场景下最好。
    - 有时简单的根据候选体系结构在哪些场景下具有优势很难做出最好的选择。
    - 而事实上，即使同样叫做关键场景，场景的重要性也是不同的。这可以通过设置权重来体现。
    - 多年来，出现了几种决定权重的策略。
    - 其中一种方式是利用涉众的讨论，有时是争论来得到相对权重。或者，如果有历史记录，则是很好的参考资料。
    - 直接场景也影响总体评估结果。
    - 不同的候选体系结构几乎总是有各自不同的直接场景。
    - 回忆一下，直接场景是不经修改就被体系结构支持的那些场景。
    - 所以支持更多直接场景的体系结构也暗示着这是一个更好的候选。
    - 有时，也会把直接场景的重要性放到总体评估这里一起考虑。
    - 最后，架构师对每个关键场景下各个候选体系结构打分。
    - 一般来说，打分采用相对值的方法，比如“1，0，-1”(或“2，1，0”、“+，0，-”等)。1表示体系结构在该场景下表现很好；-1相反；0则表示体系结构对该场景无关紧要。根据需要把范围定到5或者10也没问题。有了场景权重和体系结构的得分，就可以画一个类似表7-3的表格。
    - 表7-3
    - 然后把该表格和独立场景评估、场景关联评估和直接场景分析的结果结合起来，选择一个最好的体系结构作为下一步开发的基础。
- ATAM体系结构权衡分析方法
  ATAM方法可看做SAAM方法的增强版。从名字可以看出，ATAM方法除了能暴露被评估体系结构的潜在缺陷和风险外，还能使我们更好地理解和权衡多个相关的，甚至是不一致的质量需求或目标。ATAM的基础来自3个领域：体系结构风格、质量属性分析组(包含丰富的质量属性和体系结构对应关系的库)和SAAM。
  - ATAM在各个发展阶段的大概步骤
    - 最初的ATAM
      大多数设计都是对目标进行权衡。如果不需要权衡，那么实际上也没必要做设计，因为只要根据需求做些固定的计算就行了。大多数的权衡源自非技术的原因。比如说，为了保证系统的可伸缩性，可能需要更多的间接层，从而导致更多的编程和测试工作，也意味着整个项目需要更多的花费，可能也需要更多的时间。再比如，两个涉众持有截然相反的需求，结果开发进程受阻。
      - 架构师的职责是进行设计，方式是采集需求并把需求映射到软件的结构和行为描述中去。
      - 不过除此之外，他们更重要的责任是从技术和社会学的视角做权衡。
      - ATAM就是做此类权衡的合适工具。
      - ATAM和其他评估方法或技术有着根本的不同，它明确考虑多个质量属性之间的关联，并可以对这些关联必然导致的权衡进行原则上的推理。
      - 为了达到这个目标，最初的ATAM分成4个阶段内的6个步骤，如图7-3所示。
      - 图7-3
      - 螺旋模型源自Boehm(1986)，该文引入了一个描述软件开发的类似的螺旋模型。图7-3把评估集成到了整个设计过程中。
      - 6个步骤，即收集场景，收集需求、限制和环境，描述体系结构视图，属性特定分析，识别敏感度和识别权衡，构成了一轮迭代。
      - 完成上述步骤后如果评估结果表明当前体系结构能满足期望的质量需求，就可以进行详细设计或实现了。
      - 否则，可以制定修改计划更新已有设计，新的设计将进入第二轮ATAM的迭代。
      - 值得注意的是，这些步骤并不需要按照线性顺序操作。
      - 每个步骤都可能会触发任何其他步骤的改进，正如图7-3所示。又如，属性特定分析可能需要收集更多的场景来保持各个属性的均衡。
      - 在进行一次迭代时，第一阶段关注场景输入。第一步仅仅关注“使用场景”，尽量增进参与者对体系结构的理解。这样沟通的基础就建立了。第二步是收集质量相关信息，也是以场景的形式表达。这些场景可以被看做是质量需求假设，是后续步骤的基础。得到需求之后，就可以利用需求的限制开始第一阶段的设计。设计出来的体系结构被编档以备评估。
      - 接下来评估就开始了。首先独立分析每个质量属性，这时候不必考虑场景关联。单独评估可以使得各个质量属性方面的专家最大程度地利用属性特定的技术或模型进行分析。比如，马尔科夫模型擅长可用性分析，而SPE(即软件性能工程)分析性能特别方便。属性特定分析的结果以特定模型中数据的测量值来表述，例如“最坏情况下请求必须在500 ms内得到响应”，或者“在理想环境下系统的可用性为99.99%”。
      - 最后要做的是识别敏感度和权衡。在解释这两个步骤之前，先定义一下“体系结构元素”。体系结构元素是指任何构件、构件属性或构件关系的属性，只要它们对质量属性有影响。敏感点是指会由于体系结构元素的修改而发生显著变化的系统模型参数。例如，基于C/S的系统，服务器的冗余度影响整个系统的可用性。增加一个后备服务器会把平均每年的系统崩溃时间降低一个数量级。这里系统平均崩溃时间就是一个敏感点。一个权衡点是指与多个敏感点有关的体系结构元素。
      - 就是说，如果一个构件、构件属性或关系属性变化了，若干质量属性会大幅度地变得更好或更坏。例如，C/S系统中服务器冗余度就是一个权衡点，因为它的改动将导致可用性、费用、安全性等属性的显著变化，这些特性有些是互相冲突的。权衡点揭示了架构师需要密切关注的问题。
    - 改进版ATAM
      1999年，ATAM在几个实际项目中应用后，有了升级和增强。ATAM的原有步骤有的进行了合并，另外又补充了几个其他的步骤(如图7-4所示)。比如，增加了“场景分组和设置优先级”，这个步骤和SAAM中类似。有几个步骤被浓缩成一个，如“体系结构介绍”。
      - 图7-4
      - 对改进版ATAM主要有两点值得注意。第一点是怎样才知道什么时候停止场景生成比较合适。从图7-4可以看到第3步进行场景覆盖检查。CMU SEI专门为此步骤定义了一套针对特定质量属性的问题，回答这些问题可以帮助评估者找到遗漏的有用场景并补充进来。
      - 另外一点就是引入了很多ABAS(基于属性的体系结构风格)。ABAS是一种分析辅助工具，可以帮助涉众识别体系结构风格的质量属性，比如性能、可用性、安全性、可测试性、可修改性等。
        
        简言之，ABAS就是带有属性值以反映质量信息的体系结构风格。
        
        ABAS的著名例子是用于多个并发进程的性能分析。
        
        如果软件系统使用多个进程，每个进程都竞争有限的计算资源，该系统就可以称做性能ABAS。
        
        对此ABAS应当进行以下相关参数信息的质询，比如进程优先级、同步位置、排队策略和估计执行时间。
        
        但是，仅仅知道性能相关的信息并不足够，还需要把这些信息输入到分析框架以便分析。
        
        例如，单调速率分析是实时系统的一个有效分析框架。
      - 对比两个版本的ATAM，可以看到一个趋势，就是更多实际的技术和关注点被加入进来。
        
        第一版建立在螺旋开发模型之上，理论的味道很浓。在第二版，步骤进行了重新调整以更好地符合实际需要。
        
        除此之外，也引入了一些需要的辅助技术，尽管其中有些从评估的角度看并不能算是核心技术。
      - 简单地说，这些变化试图为如下问题提供答案
        
        怎样帮助涉众知道做什么和怎么做从而为评估过程做贡献？
        
        怎样引导涉众精确清晰地理解待评估的体系结构？
        
        怎样生成对评估有益的场景，同时避免忽略某些必需的场景，并从所有场景中选出最重要的？
        
        怎么把场景映射到体系结构，以便识别敏感点和权衡点？
        
        最后，怎样对特定的质量属性进行具体的评估并生成负责规划后续活动的评估报告？
        
        这些问题是大多数评估方法的共同问题。
        
        尽管经历了众多项目的实际应用和数以千计的架构师、设计人员和软件工程师的改进，ATAM仍在不断调整以追求更好的评估效果
    - ATAM的一般过程
      - 当前ATAM的完整过程包括4个阶段，共9个主要步骤。
        
        在此，步骤仍然不必是线性执行的。实践上，评估负责人可以决定应该执行哪些步骤，或者直接跳到本应在若干步之后才实施的步骤。这些都视情况而定。步骤仅仅表明评估中间制品的生成顺序。顺序靠后的步骤总需要靠前步骤的制品作为输入。因此，如果评估团队已经有了某一步骤生成的信息，或者这些信息对此次评估没有用处，就可以跳过这一步。
      - ATAM的一般过程如图7-5所示。阶段Ⅰ和Ⅱ是评估的核心。
      - 图7-5
      - 阶段0是准备阶段
        
        考虑到ATAM评估的范围、时间和费用，有必要就评估时间表、费用计划、参与者组织等问题进行讨论甚至签署严格的合同协定。
        
        评估前首先应该搞清楚进行评估是否可行、谁参与评估、评估的对象是什么、评估结果提交给谁、评估后又该做什么。
        
        为了避免核心评估阶段中断，上面提到的每个问题都需要仔细考虑和计划。
        
        然后，需要建立一个评估团队(如果准备评估的组织没有专职评估团队的话)，负责接下来的工作。
        
        该团队中需要定义几个角色，包括团队领导、评估领导、书记员、计时者、提问者、监督员等。
        
        同一个人可以扮演多个角色。通常，在阶段0会开一个评估团队会议以明确责任并为下一阶段做好准备。
      - 阶段Ⅲ是评估收尾阶段。
        
        这时有两项任务必须要做。
        
        首先是要产生最终报告，记录核心评估阶段的过程、信息和基于此的结论。另一项任务是进行总结以便改进今后的评估。
        
        一方面，可以询问评估成员或者其他参与者感觉哪些活动好，哪些不好，为什么。可以收集关于本次评估的花费和收益的信息。这种数据挖掘可能会有利于找到各种活动的可改进之处。
        
        另一方面，可以整理本次的场景和相关的问题，以备下次评估类似项目。在领域特定的开发中，这项活动因其强大的可重用性而非常有效。
      - 阶段Ⅰ和阶段Ⅱ是核心评估阶段
        
        共有9个步骤，和前面小节曾讲的步骤类似。
        
        这些步骤又进一步分为如下4个子阶段
        
        介绍
        
        (1) 介绍ATAM：介绍ATAM的步骤、活动和技术
        
        (2) 介绍商业动机：介绍商业目标以识别主要质量需求。
        
        (3) 介绍体系结构：解释当前体系结构如何满足商业动机。
        
        研究和分析
        
        (4) 识别体系结构方法：找到建立体系结构所用的方法。
        
        (5) 生成质量属性效用树：以树的形式产生反映系统效用的带有优先级的场景。
        
        (6) 分析体系结构方法：对支持关键场景的体系结构方法进行分析，并识别风险、非风险、敏感点和权衡点。
        
        测试
        
        (7) 头脑风暴和给场景指定优先级：由更多的涉众生成更多的场景。
        
        (8) 分析体系结构方法：同步骤(6)，不过采用的场景来自步骤(7)。
        
        报告
        
        (9) 报告结果：产生评估报告。
        
        实际上，主要阶段Ⅰ和Ⅱ分别是上述步骤的一次迭代，当然包括的具体步骤和参与者范围有所不同，如表7-4所示。
        
        表7-4
        
        主要阶段Ⅱ需要更多类型的涉众参与场景生成和分析讨论。
        
        主要阶段Ⅰ则试图利用几个原则识别主要的质量属性，为后续评估打好基础。
        
        主要阶段Ⅰ只包含步骤(1)～(6)。
        
        当然，不必机械式地执行这两次迭代。
        
        实际应用时评估团队可以调整迭代这些步骤的时间计划，并可以自行决定每次迭代的参与者。
        
        读者可能会看到一些不熟悉的概念，如“效用树”、“风险”或者“非风险”，也可能会问为什么步骤(6)看上去和步骤(8)一样。这些问题在后面的小节中将有详细介绍。
    - 介绍
      - 这个子阶段的目标是界定哪些行动是有益的，而哪些不是。该阶段引导参与者致力于系统设计并能做出贡献。同时，后续步骤所需的输入也由此阶段提供。
      - 步骤(1)——介绍ATAM
        
        这一步回答了“什么是ATAM？”和“ATAM参与者都做些什么？”的问题。
        
        这是因为除了专业的评估团队，其他涉众可能是第一次参与评估。
        
        评估负责人需要向参与者介绍ATAM，回答他们的相关问题。
        
        在此过程中，评估负责人的工作集中在场景确定优先级、效用树构建等操作的步骤、概念和技术，评估的输入输出及其他有关信息。
      - 步骤(2)——介绍商业动机
        
        项目领导人(项目主要管理者或类似人员)需要向所有参与者解释主要的商业动机。
        
        毕竟，场景开发和特定的评估需要此类信息。
        
        这项介绍的主题应该包括：主要商业目标，需求说明中已文档化的主要功能，来自技术、管理、经济、政策方面的有关限制，还有涉众的重要质量需求。
        
        注意“涉众”这个概念，在不同主要阶段，涉众的范围不同，这就使得关注点会有所偏重。这种差异也能作为一个参照，以便暴露那些没被考虑的问题。
      - 步骤(3)——介绍体系结构
        
        首席架构师介绍已有的体系结构，通常采用多视图的形式。
        
        大多数项目需要展示静态逻辑结构的分解视图、运行时结构的构件-连接件视图、逻辑结构和物理实体之间映射的分布视图和描述期望行为的行为视图。
        
        不过特定情况下，架构师有权决定使用其他视图展示系统某个特定区域，以此提供与关键质量属性对应的体系结构信息。
        
        体系结构介绍的详细程度直接影响后续的分析。
        
        根据在准备阶段设定的评估的期望效果，架构师有义务选择一个对评估比较合适的详细程度。
        
        当然在评估时，如果需要的体系结构信息未被提供，涉众可以向架构师询问。
        
        最后，一个重要任务就是列出明确使用的体系结构方法，为下一步做准备。
    - 研究和分析
      - 在这个子阶段，涉众开始将体系结构与质量属性对应起来。
      - 不过和前述ATAM的其他版本相比，在此使用的具体方法更加出色。
      - 这里捕获分析的不是体系结构元素，而是体系结构方法；用于场景生成的不是头脑风暴一类的办法，而是采用效用树。
      - 在效用树中，每个场景的优先级由二维估计值来测量。
      - 评估中，要识别风险、非风险、敏感点和权衡点，不过这些识别是分析的开始而非结束。
      - 步骤(4)——识别体系结构方法
        
        识别体系结构方法的原因是这些信息提供了体系结构构建背后的基本原则。
        
        简言之，一个体系结构方法是指根据功能或质量需求而做的设计决定。
        
        众所周知，软件体系结构风格和模式包含了大量的有用信息，这些信息与进行特定设计的原理紧密相关。
        
        体系结构模式描述了必要的抽象元素、这些元素的结构和相关的一些约束。
        
        每个体系结构模式的优缺点和基本原理都有成千上万次的使用作基础。
        
        ATAM第二版中提到的ABAS尤其有用。
        
        和ABAS相联系的属性值暴露了主要的质量属性目标，也能用来分析能否满足这些目标。
        
        但是并不是所有的体系结构方法都可以用体系结构风格或模式的形式表达。
        
        如果是这样，架构师就需要用自然语言解释为什么做出这样的设计，或为什么设计会以期望的方式运行。
        
        架构师应该能讲清楚使用的每个体系结构方法。
        
        这样，对于那些架构师觉得很基础，但是对评估非常重要的体系结构方法(于是如果不是被明确的问到，架构师不会做特别说明)，其他评估参与者也有机会理解。
        
        尽管这一步骤需要清晰的解释，但是不需要对方法的分析，那是步骤(6)中的任务。
      - 步骤(5)——生成质量属性效用树
        
        本步骤将识别关键质量属性目标，参与者是评估团队和核心项目成员，如管理者、客户代表和首席架构师。
        
        这里主要的目标是避免在评估上时间和费用的浪费。
        
        如果参与者不能决定出关键的质量属性目标或就此达成一致，评估就无法得到应有的效果。
        
        质量属性效用树是达到此目标的强大工具。
        
        质量属性效用树(Quality Attribute Utility Tree，QAUT)以树的形式表现质量属性的细化。
        
        QAUT的根是效用，接下来是质量属性层，典型的有可用性、可修改型和安全性等。
        
        再接着下一层是质量属性具体描述分类，也就是把某个质量属性分成几个主题。
        
        第四层也是最后一层，是具体的场景，精确定义了质量需求以允许后续分析。
        
        一般来说，QAUT把系统的期望效用翻译成了场景。
        
        每个场景有两维度量
        
        (1) 此场景对系统成功的重要程度
        
        (2) 架构师所估计的支持此场景的开发难度。
        
        测量所用的标度可以定为类似高、中、低这样范围为3的序数尺度，范围为5或者10等也可以。
        
        标记好度量后，场景就可以排出优先级了，最上面的是参与者希望得到的最关键的质量属性目标。
        
        图7-6
        
        图7-6是QAUT的一个例子。
        
        实际上，真实项目中生成的场景比此例复杂得多。最终QUAT生成了带有优先级的场景列表，顺序应该是(H，H)、(H，M)、(M，H)……(L，L)。这个优先级清楚地揭示了各种涉众的全面关注。
        
        也许有人认为性能是关键需求，而另一些人坚持可用性需要更多的关注。
        
        但是在建立QAUT之前，每个人的想法可能都是凌乱的。
        
        QAUT引导并澄清系统的质量需求及其相对重要性。
        
        于是，评估的时间和成本不够时就可以省略优先级低的场景。
        
        因为分析不重要或者很简单的场景没什么意义。
      - 步骤(6)——分析体系结构方法
        
        QAUT指明了评估的方向，之后就该分析体系结构方法处理高优先级场景的机制了。
        
        在这一步骤，评估团队和架构师一道识别在那些和重要场景相关的方法中存在的风险、非风险、敏感点和权衡点。
        
        风险是已经做出的但是在特定的可能情况下出现潜在问题的决策。
        
        而非风险正好相反。可能有人会说风险应该受到更多关注，因为它们是将来的问题之源。
        
        不过，非风险也一样重要，因为它们暗示了哪些体系结构方法值得保留和坚持。
        
        更重要的是，当上下文变化的时候，非风险可能会转变成风险。因此，显式地列出非风险是有用的。
        
        敏感点是指会被某些体系结构元素显著影响的系统模型的属性值。
        
        权衡点是系统内与几个敏感点都相关的地方。
        
        在步骤(4)和步骤(5)中这些需要的信息应该就准备好了。
        
        不过若评估团队感到有什么信息缺失，可以询问架构师。
        
        为了识别风险、非风险、敏感点和权衡点，全体参与者都要完成下述工作：
        
        这一步骤结束，主要阶段Ⅰ就完成了。如果一切顺利，评估团队应该对体系结构有了大致的了解，也清楚了其优缺点。
        
        (1) 识别出试图支持重要场景的体系结构方法并弄清楚这些方法在当前体系结构中是怎么实例化的。
        
        (2) 分析每个方法，考虑其明显的优点和缺点，判断其是否对质量属性带来负面影响。这项工作可以利用询问一系列附属于这种体系结构方法的特定问题来完成。
        
        (3) 在回答这些问题的基础上，识别风险、非风险、敏感点和权衡点并分别记录在文档中。
    - 测试
      - 这一阶段的目的是对到目前为止所作的分析进行测试。
      - 会有更多种类的涉众就系统质量需求给出建议。
      - 讨论的范围被扩大了，因而会有额外的问题和关注点出现来对系统需求进行补充。
      - 步骤(7)——头脑风暴和设定场景优先级
        
        在步骤(5)中，场景表示为QAUT，表明项目决策者心目中的体系结构该是什么样子。不过在这一步，评估团队的范围更大了。
        
        这里得到更多场景的有效方法是头脑风暴，就像SAAM的场景生成采用的方式。这种环境容易激发创造性的想法和新颖的建议。
        
        按性质场景可以分为以下3类：
        
        (1) 用例场景
        
        描述被评估体系结构所在的系统在最终用户的特定操作下如何动作和响应。
        
        (2) 增长式场景
        
        描述被评估体系结构所在的系统怎样支持快速修改和演化的，比如添加构件、平台移植或者与其他系统集成。
        
        (3) 探索式场景
        
        探索被评估体系结构所在系统的极端增长情况。
        
        如果说增长式场景试图揭示期望中的和可能的修改，那么探索式场景使评估参与者有机会知道重大变更后系统会发生什么。
        
        比如说，性能必须提高5倍，或可用性需要提高一个数量级。
        
        根据这类场景，额外的敏感点和权衡点将会暴露，评估测试可基于此。
        
        头脑风暴后，利用投票为场景设置优先级，这和SAAM类似。
        
        显然步骤(5)和本步骤生成的场景有显著差异。利用QAUT生成场景是细化的过程，看起来是自顶向下的风格。
        
        评估团队和核心项目决策人通过QAUT找到当前体系结构的主要质量驱动。
        
        而头脑风暴生成的场景需要几乎所有涉众的合作。测试时，本步骤生成的场景将和QAUT的结果比对。
        
        新的场景成为QAUT已有分支的叶子节点，也可能原来就完全没有相应的质量属性分支。
        
        评估测试的目的也正是如此，即暴露二者之间的差异，补充未考虑到的场景。
      - 步骤(8)——分析体系结构方法
        
        这一步使用的方法和技术同步骤(6)，主要差别在于，在此涉众分析的是步骤(7)产生的体系结构方法。
        
        如果一切顺利，那么架构师只需要解释是如何用那些被捕获的方法来实现场景的。
        
        但是如果存在某些场景不能被直接支持，那么评估团队应该记录在档以便制定修改计划。
    - 报告
      - 步骤(9)——提供评估结果
        
        这是ATAM一轮迭代的最后一步，包括已收集在原始体系结构文档内的、涉众生成的和分析得到的所有信息都要体现在评估报告中。
        
        最重要的内容或者说ATAM的输出，包括文档化的体系结构方法(包括这些方法附属的问题)、带优先级的场景、QAUT、关键质量需求、风险、非风险、敏感点和权衡点。
        
        所有涉众一起讨论来解决当前体系结构的问题，尤其是风险和权衡点。
- SAAM方法评估实例
  我们在本节介绍一个使用SAAM方法的实例。我们使用SAAM方法对第3章介绍过的KWIC(在文章中查找和重组关键词)系统中的不同场景进行评估。
  - 定义角色和场景
    - KWIC系统感兴趣的角色有两个，分别是最终用户和开发人员。使用四个场景，其中两个场景经过了不同的最终用户的讨论，即
      - (1) 修改KWIC程序，使之成为一个增量方式而不是批处理的方式。这个程序版本将能一次接受一个句子，产生一个所有置换的字母列表。
      - (2) 修改KWIC程序，使之能删除在句子前端的噪音单词(例如前置词、代名词、连词等)。
    - 使用的另外两个场景是经过开发人员讨论，但最终用户不知道的，即
      - (1) 改变句子的内部表示(例如，压缩和解压缩)。
      - (2) 改变中间数据结构的内部表示(例如，可直接存储置换后的句子，也可存储转换后的词语的地址)。
  - 描述体系结构
    - 第2步就是使用通用的表示对待评估的体系结构进行描述，这种描述是为了使评估过程更容易，使评估人员知道体系结构图中的框或箭头的准确含义。
    - 这里对两种体系结构风格进行评估。
      - 共享内存的解决方案
        
        在第一个待评估的体系结构中，有一个全局存储区域，被称做Sentences，用来存储所有输入的句子。
        
        其执行的顺序是：输入例程读入句子→存储句子→循环转换例程转换句子→字母例程按字母顺序排列句子→输出。
        
        当需要时，主控程序传递控制信息给不同的例程。
        
        图7-7描述了这个过程，不同计算构件上的数字代表场景编号，在这一步中可忽略(将在后面用到)。
      - 抽象数据类型解决方案
        
        待评估的第2个体系结构使用抽象数据类型(Abstract Data Type，ADT)，如图7-8所示。
        
        其中每个功能都隐藏和保护了其内部数据表示，提供专门的存取函数作为唯一的存储、检索和查询数据的方式。
        
        ADT Sentences有两个函数，分别是set和getNext，用来增加和检索句子；ADT Shifted Sentences提供了存取函数setup和getNext，分别用来建立句子的循环置换和检索置换后的句子。
        
        ADT Shifted Sentences使用ADT Sentences的getNext函数来重新存储输入的句子。
        
        ADT Alphabetized Sentences提供了一个setup函数和一个i-th函数，setup函数重复调用Shifted Sentences的getNext函数，以检索已经存储的所有行并进行排序，i-th函数根据参数i，从存储队列中返回第i个句子。
  - 评估体系结构
    - 既然已经把待评估的体系结构用通用的符号标记了出来，接下来就是评估体系结构满足场景的程度。
    - 通过依次考虑每个场景来进行评估。
    - 我们所选择的用来评估的所有场景都是间接场景，也就是说，这些场景不能被待评估的体系结构直接执行，因此评估依赖于体系结构的某些修改。
      - (1) 场景1。第一个场景是从批处理模式转移到增量模式，也就是说，不是把所有句子都输入完后再一次性进行处理，而是一次只处理一个句子。
        
        对共享内存解决方案而言，这需要修改Input例程，使之在读入一个句子后让出控制权，同时，也要修改Master Control主控程序，因为子例程不再是按顺序一次只调用一个，而是一个迭代调用的过程。还要修改Alphabetizer例程，因为使用增量模式后，牵涉到插入排序的问题。我们假设Circular Shift例程一次只处理一个句子，且输出函数只要被调用，就可以输出。
        
        注意，我们所作的假设只是针对共享内存解决方案而言的，一般来说，判断的准确性取决于不同的计算构件的内部工作知识。这也是为什么要期望评估人员中，既有具有计算构件一般知识的人，也有具有特定构件知识的人。
        
        对抽象数据类型解决方案而言，Input函数需要修改，使之在被调用时，一次只输入一行。假设Sentence当存储了输入之后放弃控制权，则无需改变。也假设当Shifted Sentences被调用时，能请求和转换所有可获得的句子，这样，该例程也无须改变。与在共享内存解决方案中一样，Alphabetized Sentences也必须修改。
        
        综上所述，对第一个场景而言，两个待评估的体系结构受到的影响是均等的，因此，我们判定其为中性的。
      - (2) 场景2。第二个场景要求删除句子中的“噪音”单词。
        
        无论在共享内存解决方案还是在抽象数据类型解决方案中，这种需求均可通过修改转换函数很容易地实现(在共享内存体系结构中，修改Circular Shift函数；在抽象数据类型体系结构中，修改Shifted Sentences函数)。
        
        因为在两种体系结构中，转换函数都是局部的，且噪音单词的删除不会影响句子的内部表示，所以，对两种体系结构而言，这种修改是等价的。
      - (3) 场景3。第三个场景要求改变句子的内部表示，例如从一个未压缩的表示转换到压缩的表示。
        
        在共享内存体系结构中，所有函数共享一个公用的表示，因此，除了主控函数Master Control外，所有函数都受该场景的影响。
        
        在抽象数据类型中，输入句子的内部表示由Sentence提供缓冲。因此，就第三个场景而言，抽象数据类型体系结构比共享内存的体系结构要好。
      - (4) 场景4。第四个场景要求改变中间数据结构的内部表示(例如，既可直接存储置换后的句子，也可存储转换后的词语的地址)。
        
        对于共享内存体系结构，需要修改Circular Shift、Alphabetize和Output三个例程。对于抽象数据类型体系结构，需要修改抽象数据类型中的Shifted Sentences和Alphabetized Sentences。
        
        因此，抽象数据类型解决方案所受影响的构件数量要比共享内存体系结构解决方案的少。
      - (5) 比较分析
        
        图7-7和图7-8都标记了反映每个场景的影响。
        
        例如，在图7-7中，Master Control构件中的“1”反映了该构件必须修改以支持场景1。
        
        检查待评估体系结构，看其有多少个构件受场景的影响，每个构件最多受多少个场景的影响。
        
        从这方面来看，抽象数据类型体系结构要比共享内存体系结构好。
        
        在共享内存体系结构和抽象数据类型体系结构中，两者都有4个构件受场景的影响，但是，在共享内存体系结构中，有两个构件(Circular Shift和Alphabetize)受三个场景的影响，而在抽象数据类型体系结构中，所有构件最多只受两个场景的影响。
      - (6) 评估结果。
        
        表7-5概括了评估的结果，其中0表示对该场景而言，两个体系结构不分好坏，在实际的评估中，还需要根据组织的偏好设置场景的优先级。
        
        表7-5
        
        例如，如果功能的增加是风险承担者最关心的问题(就像第2个场景一样)，那么这两个体系结构是不相上下的，因为在这一点上，它们之间没有什么区别。
        
        但是，如果句子内部表示的修改是风险承担者最关心的问题(就像第3个场景一样)，那么抽象数据类型体系结构显然是要首选的体系结构。
        
        使用SAAM方法评估系统的结果通常容易理解，容易解释，而且和不同组织的需求目标联系在一起。开发人员、维护人员、用户和管理人员会找到对他们关心的问题的直接回答，只要这些问题是以场景的方式提出的。
软件体系结构研究展望
- 21世纪软件技术展望
  - 开放源代码
    - 下一世纪的操作系统将继承现在好的操作系统的主要优点，变成开放的和进化的。
    - 在操作系统开放之后，系统软件产业将主要集中在软件环境平台和工具的研究开发上。
    - 可视化编程环境与工具、办公套件、家庭套件、学习套件等将会有很大的空间。
  - 跨平台
    - 使得一次写好的应用软件在各种不同硬件系统上都可以运行、使得已经设计好的程序模块被有效地重复利用。
    - 目前跨平台这一设想还没有完全有效地被实现，相信21世纪第一个10年一定可以完成。当然，如何解决非Java语言软件的跨平台问题仍然是一个难题。
  - 软件工业化
    - 随着软构件的规范化和实用化，计算机软件生产的工业化程度会慢慢提高，软件发展的速度也会慢慢加快。
    - 估计到21世纪的第一个10年结束的时候，软件的工业化程度应该达到20世纪90年代中期计算机硬件的工业化程度。
  - 友好界面
    - 多媒体技术、语音识别与合成技术、手写体文字的识别、自然语言理解与机器翻译技术、图像处理与图形学技术、用户图形界面技术、人工智能技术等等都是解决软件系统友好性的关键技术。
  - 基于网络的应用软件
    - 利用了WEB浏览技术、多媒体技术和网络信息管理系统等综合技术而构成的网络应用软件（例如电子商务）将是今后软件业发展的最大舞台。
- 软件体系结构研究新方向
  - IEEE 1471标准
    - 基本原则
      - 每个系统具有一个体系结构，但一个体系结构不是一个系统；
      - 体系结构与体系结构描述不是同一件事；
      - 体系结构标准、描述、及开发过程可以不同，并且可以单独地进行研究；
      - 体系结构描述本身是多见解的；
      - 把一个对象的总体概念从其详述中分离开是撰写体系结构标准的一个有效方法。
    - 体系结构定义
      - 体现在各组成部分、它们相互关系及与环境的关系、和指导设计和演变的原理之中的一个系统的基本结构。
    - 组成部分
      - 对关键术语的定义，如体系结构描述、结构性视图与体系结构性视点；
      - 对体系结构与体系结构描述在概念上的分离促进了描述体系结构标准（与蓝图标准相类似）和构筑系统标准（与建筑规范或城市规划法规相类似）的建立；
      - 用于描述一个系统体系结构的内容要求。
    - 体系结构描述要求
      - 一个体系结构描述必须规定系统的用户，确定他们体系结构的要点；
      - 一个体系结构描述必须被编入一个或多个系统的体系结构视图中；
      - 一个体系结构描述必须为制定关键的结构性决策提供基本原则。
  - 基于软件体系结构的软件工程
    - 基于体系结构的软件开发方法
      - ACPP
        
        以体系结构为中心的软件项目计划
        
        图示
      - ABDP
        
        基于软件体系结构的开发过程
        
        Perry和Wolf提出在软件设计的早期应该引入构架设计，他们根据软件生命周期各阶段相应的实体、属性、关系、主要产品和评估标准，将软件开发过程分为四个阶段：需求分析、体系结构设计、详细设计、实现
        
        图示
      - ABC
        
        基于体系结构、面向构件的软件开发方法
        
        北京大学梅宏等研究人员将软件体系结构技术与基于构件的软件开发方法接合，提出了ABC方法
        
        图示
    - 基于体系结构的软件组装
      - 图示
    - 基于体系结构的软件测试方法
      - 体系结构形式化验证
      - 多组态软件体系结构测试
        
        图示
        
        参与交互的构件是否能达到系统的目标
        
        系统的完备性和效率
        
        系统扩展的潜能
        
        构件接口的一致性
        
        构件之间连接的机制
        
        构件行为的顺序
        
        临界资源的争夺
      - 基于有穷状态进程的形式化验证
      - 基于时态逻辑的形式化验证
      - 基于进程演算的形式化验证
      - 基于Petri网的形式化验证
  - 面向服务体系结构（Service-Oriented Architecture）
    - 三位一体的职责构成SOA
      - 图示
    - SOA应用示例
    - SOA特性
      - 基于标准的互操作性
        
        在SOA当中，接口、通讯协议、工作流、协作和发布都是由一整套国际标准所定义，包括XML, SOAP, WSDL, UDDI, HTTP,CPP, ebXML, bSOA, BPEL, FERA, OWL-S等，从而保证不同平台的系统能够无阻碍的交流
      - 基于发现的动态组装
        
        在SOA中的系统所需要的服务均通过运行时发现，运行时加载的方式工作
      - 基于策略的动态管理和总控协作
        
        SOA的各个服务的运行都由策略（Policy）进行控制，策略的制定、监测、执行都可在运行时内完成。SOA实行总控式协作，即由一个中心控制节点负责控制和调度分布在网络各处的服务
    - SOA分类标准
      - 结构（Structure）
        
        应用程序的结构是静态(S)还是动态(D)
      - 动态重组能力（Runtime re-composition capability)
        
        可以在运行时进行重组(R) 不可以进行重组(N)
      - 容错能力（Fault Tolerant Capability）
        
        具有容错的骨干通讯机制(FB)，具有容错的控制服务(FC)，不具有容错能力(FN)
      - 软件工程支持（System Engineering Support）
        
        是否具有系统支持的模型监测、数据收集、部署、代码自动生成、策略实施、一致性检查等机制。有用(SY)表示，无用(SN)表示
      - 由此得到一个四元组
        
        {Structure, Re-composition, Fault-tolerance, System-engineering}
        
        对各种SOA进行分类
      - SOA类别及其进化
        
        图示
    - Customer Centric SOA
      - 常规SOA模式
        
        服务提供者向服务代理注册开发出来的服务，由应用程序构建者来寻找需要的服务
      - CCSOA模式
        
        在传统SOA的基础上，应用程序构建者也可以发布应用程序模板，服务提供者可以根据模板的需要开发新的服务
      - 图示
    - 商业SOA平台
  - 柔性软件体系结构
    柔性软件体系结构是指可以根据需求的变化而容易发生形态变化的体系结构
    - 柔性软件体系结构的行为
      - 添加新的构件
      - 升级已存在构件
      - 删除不需要的构件
      - 动态改变构件之间的关系
      - 动态改变构件到执行平台的映射
    - 柔性软件体系结构的应用领域
      - 图示
    - 自适应的柔性软件体系结构
      - 自适应软件体系结构是根据操作环境的变化而变化的体系结构
        
        外界的变化包括用户输入、硬件设备输入、传感器信号、以及程序指令等
      - 自适应软件体系结构需要解决的问题
        
        在什么条件下系统发生改变
        
        自适应软件体系结构应具有开放性质还是封闭性质
        
        需要实现什么样的自适应程度
        
        如何演算从而评估变化后带来的收益是否大于变化本身的成本
        
        变化的频繁程度如何
        
        自适应变化需要的原始信息有哪些
      - 自适应的基本结构
        
        Monitor监控外界的变化
        
        Adapt负责调整系统模型
        
        Control负责将外界变化演算出模型变化，并作出变化决策
        
        图示
      - 移动环境的自适应柔性软件体系结构
        
        为何移动环境需要动态自适应
        
        移动环境下设备往往需要连续工作，对自身进行改变必须在运行时下进行
        
        移动设备经受的操作环境的改变与固定的计算设备相比要频繁的多
        
        使用移动设备的用户的需求也在不断改变
      - 自适应体系结构示例：Rainbow
    - 移动环境下的软件体系结构
      - 移动环境应用实例
      - 为何使用体系结构的方法
        
        基于编程语言的方法
        
        使用条件表达式
        
        使用参数
        
        使用异常
        
        缺点
        
        将软件行为和自行应的过程混杂起来
        
        当引入新的适应机制式时需要修改大量代码，造成扩展性底下
        
        结论
        
        采用移动中间件来具体负责适应行为
      - 移动中间件
        
        移动中间件特点
        
        足够轻量使其可以运行在资源受限的手持设备上
        
        支持异步通讯，使移动设备可以用较短时间周期性访问网络，用以节省能源
        
        可以感知环境的变化、例如自身状态、位置、可以获得的服务等
        
        移动中间件所作出的推理必须简单有效，即推理得到的改变决策必须使系统有较大的收益
        
        移动中间件
        
        中间件可以为解决分布是系统的基本通讯和管理问题，使开发者专注于业务流程
        
        在移动环境下，动态服务和位置发现，从而动态的调整体系结构的形态是移动中间件的核心思想
        
        图示
        
        移动中间件实例MADAM
        
        移动中间件的运行方式——可变属性
        
        绑定属性实例
      - 移动柔性软件体系结构的发展
        
        统一的、通用的体系结构模型和环境模型表示方法
        
        如何更好的描述体系结构模型这个变化的基础
        
        如何更好的描述环境模型这个变化的触发点
        
        变化决策推理算法的设计范式
        
        如何设计才能使推理算法可以在资源受限的设备上流畅运行，并保证其结果的有效性
        
        用户干涉对推理算法的影响
        
        例如调整某些属性的计算权重
    - 自修复系统
      - 自修修复系统的分类
        基于软件体系结构的自修复系统使用软件体系结构模型为基础进行自修复，是外修复系统的一种
        
        内部修复
        
        修复代码和常规代码集成到普通代码当中
        
        外部修复
        
        修复代码单独作为一个构件存在于系统当中，与普通的代码互相隔离
      - 自修复系统设计过程
        
        体系结构设计
        
        将系统分为两部分
        
        体系结构管理器（AMR）和体系结构模型容器（AMC）
        
        运行时环境（RE）和实际运行系统（RS）
        
        图示
        
        修复行为触发
        
        运行时环境负责监控运行时系统的各个参数，并将数据发送给体系结构管理器
        
        延迟信息
        
        内存消耗
        
        CPU占用
        
        负载
        
        系统异常
        
        用户指令
        
        修复行为
        
        体系结构管理器负责分析收集的数据，并执行和校验体系结构的重新配置，并将决策的目标体系结构模型映射成运行时环境可以接受的操作集
        
        运行时环境对运行系统执行实际的修复操作
      - 体系结构管理器结构
    - 支持代码移动的体系结构
      - 代码移动
        
        定义
        
        可以动态改变代码和代码所在位置绑定的能力
        
        优点
        
        在需要传输大量数据的情况下，传输执行代码可能会更为快捷
        
        使得代码具有自我决策的能力，在网络中自行传输
        
        图示
      - 支持代码移动的基本结构
      - 支持代码移动的运行环境结构
  - 动态软件体系结构的描述
    - SA通常是对系统的静态描述,如果需要改变体系结构则必须重新设计新的SA,这已不能适应现在越来越多的需要在运行时刻发生变化的系统的设计需求.则允许系统在执行过程中修改其体系结构,修改过程通常也被称为运行时刻的演化(即在线演化)或动态性。
    - 主要的变化体现在以下几个方面：
      - 结构
        
        软件系统为适应当前的计算环境往往需要调整自身的结构,比如增加或删除构件、连接子,这将导致SA的拓扑结构发生显式的变化
      - 行为
        
        由于用户需求的变化或者系统自身QoS调节的需要,软件系统在运行过程中会改变其行为,比如由于安全级别的提高更换加密算法;将http协议改为https协议,行为的变化往往是由构件或连接子的替换和重配置引起的
      - 属性
        
        已有的ADL大都支持对非功能属性(non functional properties)的规约和分析,比如对服务响应时间和吞吐量的要求等,在系统运行的过程中这些要求可能发生改变,而这些变化又会进一步触发软件系统结构或行为的调整.属性的变化是驱动系统演化的主要原因
      - 风格
        
        系统由一种体系结构风格演化成“衍生”的另外一种风格。
        
        例如两层C/S结构衍生成多层C/S结构，或者衍生成B/S结构
    - 动态体系结构描述的约束
      - 一致性
        
        体系结构规约与系统实现的一致性,运行时刻的修改应及时地反映到规约中,以保证规约不会过时
        
        系统内部状态的一致性,正在修改的部分不应被其他用户或模块更改
        
        系统行为的一致性,若“管道-过滤器”风格的结构中增加一个过滤器,则需要保证该过滤器的输入和输出与相连的管道的要求一致
        
        体系结构风格的一致性,演化前后体系结构或者保持风格不变,或者演化为当前风格的“衍生”风格
      - 完整性
        
        系统的演化不能破坏SA规约中的约束
        
        演化前后系统的状态不会丢失,否则系统将变得不“安全”,甚至不能正确运行.
      - 追溯性
        
        传统的ADL采用逐步精化的方式将一个抽象层次很高的ADL规约逐步精化为具体的可直接实现的ADL规约，在精化的过程中通过形式化的验证保证每一步精化都符合要求,满足可追溯性。
        
        对于动态系统而言，追溯性除了需要满足静态设和净化阶段被满足，还需要被延伸到运行时刻，以保证系统的任何一次修改都会被验证，这样既有利于软件的维护，也为软件的进一步演化提供了可分析的依据。
    - 动态体系结构描述语言D-ADL
      - 将构件行为进行分类
        
        计算行为：计算行为和动态行为.计算行为面向系统的商业逻辑,处理业务功能中的数据信息
        
        动态行为：面向系统的预定义演化逻辑,使系统能够自适应演化,以体系结构元素为处理对象,如增删构件、建立新的连接等.
      - 基于高阶π演算
        
        所有描述行为都可在高阶π演算中找到对应表示
        
        具有强有力的形式化基础，可以对软件体系结构行为作深入的推理和规约
      - 对高阶π演算进行扩充
        
        对于某些不能使用高阶π演算方便表示的概念（间接可以表示）进行了扩充
        
        提供了构件动态行为new、attach和detach的语法概念
      - 图示
      - 动态体系结构描述语言D-ADL（续）
    - 体系结构动态演化系统的设计
      - 反射
        
        反射(reflect)是指计算系统通过与自身状态和行为具有因果互联的系统自述，以描述、推理和操纵自身的能力
        
        可以将体系结构包含在系统当中作为元数据，并对外提供访问接口，以实现对系统的体系结构进行运行时控制
        
        图示
      - 体系结构在线演化的实施
        
        预设演化
        在设计时就定义好的演化，以演化规则库的形式存储
        
        非预设演化
        未预设演化需以基本访问接口为基础在运行时动态生成
      - 体系结构在线演化的校验
        
        使用类型系统检测一致性
        
        将体系结构风格衍生路线设计为继承的类型体系，体系结构演化只能沿着继承路线向子类型前进
        
        将构件接口类型化，在改变构件连接关系时要保证新的连接的类型一致
        
        使用事务处理机制确保演化不被恶性中断
        
        每次演化的一些列操作都在一个事务当中进行
        
        演化发生错误时全部操作回滚
        
        在分布式系统当中，事务可保证在线演化操作的在并行访问的情况下的正确性
    - 连接器
      - 连接器的形式化重用
        
        通过重用旧有的、相对简单的连接器来得到新的、较为复杂的连接器，就可以获得一种增量式的连接器开发方法，从而提高软件开发的质量和效率
        
        具有形式化基础（例如使用CSP）使得新的连接器定义可以进行形式化检测
      - 连接器组合元操作
        
        角色（Role）元操作
        
        Substitute:角色的替代
        
        可以实现用一个角色来充当另一个已经定义的角色
        
        ConcurrencyMerge:角色的并行合一
        
        可以实现用一个角色来同时充当多个已经定义的角色，并且它“扮演”的多个角色之间应并行协调
        
        AlternativeMerge:角色的选择合一
        
        可以实现用一个角色来完成多个已经定义的角色的功能，并且在每一次完整的交互中该角色只能充当其中的某一个角色
        
        Choice:该操作将两个或者多个粘结进程选择地组合起来
        
        这种选择可能是上述的不确定性选择，也可能是确定的选择，即选择权在其所在环境的选择。
        
        如果它所规范的角色在某次完整的交互中想要参与的初始事件仅被某个子粘结进程所允许，那么组合粘结进程就选择该子粘结进程去承担该次交互的协调任务;否则，如果角色想要参与的初始事件为多个子粘结进程所允许，那么它就会任意选择其中的某个子粘结进程去承担此次交互的协调任务。
        
        Interleave:该操作将两个或者多个粘结进程交错地组合起来
        
        如果用这种组合得到的粘结进程去协调和约束某个角色的行为，那么该角色无论何时要想参与某一个事件，只需得到某个子粘结进程的允许即可。
        
        当然，如果此时有多个子粘结进程都允许该事件发生，那么组合粘结进程就会任意选择其中的某个子粘结进程去承担允许该事件发生的责任。
        
        粘连（Glue）元操作
        
        Parallel:该操作将两个或者多个粘结进程并行地组合起来
        
        如果用这种组合得到的粘结进程去规范某个角色行为，那么该角色无论何时要想参与某一个事件，都必须得到各个子粘结进程的共同允许。
        
        Decision:该操作将两个或者多个粘结进程不确定性选择地组合起来
        
        这里的不确定性选择指的是:组合得到的粘结进程究竟选择哪一个子粘结进程去规范角色的某一次完整的交互行为，由其自身来决定。
        
        Follow:该操作将两个或者多个粘结进程顺序地组合起来
        
        用这种组合得到的粘结进程依次用其子粘结进程去协调和约束其所规范的角色的行为，当然，后续的子粘结进程要想承担这种责任，必须满足前行的子粘结进程能够成功终止。
        
        Interrupt:该操作将两个或者多个粘结进程顺序中断地组合起来
        
        用这种组合得到的粘结进程可以随着后续子粘结进程初始事件的发生，用后续的子粘结进程去中断和接替前行的子粘结进程，并获得协调和约束角色的责任。
        
        Lightning:该操作可以看作是Interrupt的一种特殊情形，它将两个粘结进程顺序中断地组合起来
        
        但与Interrupt不同的是，前行子粘结进程被中断并不取决于后续子粘结进程初始事件的发生，而是某个被定义的中断事件。
        
        为了表示这个特殊事件，我们把它作为第3个参数引入到Lightning函数中。
      - 连接器组合示例
      - 连接器组合法性检测
        
        检查1：连接器的每个角色都是无死锁的
        
        这是对连接器角色内部相容性的检测。
        
        由于组合连接器的每个角色是在重用已有连接器的角色基础上得到的，因此，这种检查可以分为两种情形:若组合连接器的某个角色是通过替换或者选择合一得到的，那么对子连接器相应角色的检查结果仍然适用于组合连接器的这一角色；若组合连接器的某个角色是通过并行合一得到的，那么就必须重新检查。
        
        因为对于一个并行合一的角色进程，可能会出现这样的问题:在某个时候，虽然它的子角色都各自能参与某些事件，但它却不能参与任何一个事件。
        
        检查2：连接器是无死锁的
        
        这种相容性的检查是对连接器整体的检查。
        
        因此，检查1如果通不过，也会反映到检查2中。
        
        角色规范了充当其实例的组件预期要发生的行为，而粘结规范的是对这些行为的协调与约束。
        
        角色规范与粘结规范是否会出现矛盾，就需要用检查2来考察。

posted @ 2019-12-13 10:56 Zander_Zhao 阅读(5586) 评论(3) 收藏举报

刷新页面返回顶部

Zander Zhao

To the time to life, rather than to life in time .

软件体系结构

公告