西工大软件学院软件架构设计复习

软件架构设计复习

前言

本复习文档，是对于《软件建模与设计：UML、用例、模式和软件体系结构》一书的总结归纳。

面向软件架构(体系结构)设计，以UML语言为基础，从基于用例的需求建模、基于类图的静态建模、基于对象交互分析的动态建模、状态机建模等基本的需求和分析建模手段开始，逐步介绍多种软件架构模式以及基于模式的软件架构设计方法。

第一章

1. 软件体系结构: 将系统的总体结构（包括构件及其连接关系）与各个构件的内部细节相分离。

2. 建模就是在编码之前对软件应用的设计。在系统实现之前，对模型进行构造和分析，并用于指导后继的实现过程

3. 封装：把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信或必要的类或者对象操作，对不可信的或不必要的类或对象进行信息隐藏。

4. 继承：让某个类型的对象获得另一个类型的对象的属性和方法。它可以使用现有类的所有功能，并在无需重新编写原来的类的情况下对这些功能进行扩展。

5. 多态：类实例的相同方法在不同情形有不同表现形式。多态机制使具有不同内部结构的对象可以共享相同的外部接口。

6. 统一建模语言（UML）：为面向对象模型的描述提供了一种标准化的图形语言和表示法。

7. 软件体系结构可以在不同的细节层次上进行描述。

   在较高的细节层次上，体系结构可以描述软件系统是如何分解为子系统的。

   在较低的细节层次上，体系结构可以描述子系统是如何分解为模块或构件的。

   这些不同层次上的体系结构强调的都是子系统/构件的外部视图，即子系统/构件所提供和需要的接口以及与其他子系统/构件的连接关系。

   也称为高层设计，满足功能性的同时重点考虑系统的质量属性（性能、安全性、可维护性等）。

8. CIM: Computation Independent Model（系统的与计算无关的视图）详细描述需求,但是隐藏实现细节和系统实现

9. PIM: Platform Independent Model（平台无关模型）

   PIM是一种在采用特定平台的决策做出之前描述软件体系结构的精确模型。

10. PSM: Platform Specific Model（平台相关模型）

    PSM是映射到特定平台上的一种精确的软件体系结构模型。

    11. 软件设计表示法是一种使用图形或文本方式或同时使用图形和文本描述软件设计的方法。例如，类图是一种图形化的设计表示法，而伪代码是一种文本化的设计表示法。
    12. 软件设计思想是一种可以用于设计系统的根本性的思想。例如，信息隐藏是一种软件设计思想。
    13. 软件设计策略是一种对设计的整体性规划和方向性指导。例如，面向对象的分解是一种软件设计策略。
    14. 软件结构组织准则是用于帮助设计者将软件系统组织为构件的启发式规则或指导方针。例如,对象结构设计准则为如何将系统分解为对象提供了指导方针。
    15. 软件设计方法是一种描述了用于在给定的应用系统软件需求基础上创建一个设计方案的步骤序列的系统化方法。

第二章

1. 用例图，一个参与者( actor）发起一个用例(use case )。用例定义了参与者与系统之间的一组交互序列。

   在用例图中，参与者用一个人形图标表示，系统则用一个方框来表示，一个用例表示为方框中的一个椭圆。通信关联( communication association)将参与者与他们参与的用例进行连接。用例之间的关系通过包含( include）关系和扩展( extend)关系进行定义。

2. 类和对象，类( class)和对象( object)在UML表示法中被描绘成方框。表示类的方框总是包含类名，并且可选择性地列出类的属性( attribute）和操作( operation )。当同时描述以上三者时，方框的顶部区域放置类名，中部区域放置属性，底部区域放置操作。

   为了区分类（类型）和对象（该类型的一个实例)，对象名称需要带有下划线。

3. 类图，在类图中，类用方框描绘，类之间的静态（永久）关系被描绘成连接方框之间的连线。

   UML表示法支持以下三种类之间的主要关系类型:关联( association)、整体/部分关系( whole/part relationship)和泛化/特化

   第四种关系，即依赖关系( dependency relationship )，经常被用来表示包之间是如何进行关联的。

4. 关联( association)：两个或多个类之间的一个静态的、结构化的关系。它用两个类框之间的连线表示，一个关联具有一个名字，并且可选择性地具有一个黑色小箭头来表示关联名称的阅读方向，每个连接类的关联线的末端标明关联的多重性。此外，可以用棍状箭头描绘导航的方向。

5. 聚合和组合层次是整体/部分的关系。组合关系( 用黑色菱形表示)是一个比聚合关系(用空心菱形表示)更强的整体/部分关系的形式。

6. 泛化/特化层次是一种继承关系。泛化被描绘为一个连接子类( subclass）到父类( superclass)的具有箭头的连线，箭头与表示父类的方框连接。

7. 可见性指类中的一个元素是否在类外可见。

   公有可见性( public visibility)使用 + 号，表示一个元素在类的外部是可见的。

   私有可见性( private visibility)使用 - 号，表示一个元素只在定义它的类的内部是可见的，对于其他类是隐藏的。

   受保护可见性( protected visibility)使用 # 号，表示一个元素在定义它的类及其所有子类中是可见的。

8. 交互图，通信图和顺序图是UML的两种主要类型的交互图，它们用来描绘对象间是如何进行交互的。对象用长方形方框表示，对象的名字不需要使用下划线标绘。

9. 通信图描绘了交互对象的组织结构。其中,对象用方框表示，连接方框的线代表了对象间的交互。与这些线相邻的带有标签的箭头表示了对象间消息传递的名字和方向。同时，对象间传递消息的顺序被进行了编号。其中，星号(*）表示一个可选的迭代,即一条消息被发送了多于一次。一个可选的条件( condition)，[conditon]表示一条消息在满足特定条件的情况下才会被发送。

10. 顺序图是另一种说明对象间交互方式的图，顺序图将对象交互通过时间序列的方式进行描绘。顺序图具有两个维度，其中参与交互的对象被描绘在水平方向，而垂直方向代表时间维度。从每一个对象框出发都有一条被称为生命线( lifeline ）的垂直虚线。

11. 状态转换图被称为状态机图。本书使用状态图这一更为通用的术语。在UML表示法中，圆角框表示状态，连接圆角框的弧线表示转换。状态图的初始状态（ initial state )用一个始于小黑圆圈的弧线表示。终结状态（ finalstate)是可选的，它被描绘为嵌套在大白圈中的小黑圆圈，有时也被称为靶心( bull’s-eye )。

12. 弧线上，使用事件[条件]/动作(Event[Condition]/Action )进行标记。事件（ event )引起了状态的转换，当事件发生时，为了发生转换，可选的布尔条件( condition)必须为真。可选的动作( action)作为转换的结果被执行。一个状态可具有以下任意的动作:

    ●进入动作( entry action )，它在进人状态的时候执行；

    ●退出动作（ exit action )，它在退出状态的时候执行。

13. 包是一组建模元素的组合，例如代表一个系统或一个子系统。用一个文件夹图标表示包，即在一个大长方形的角上依附一个小长方形。包也可能被嵌套在其他包里面。依赖和泛化/特化是包之间可能具有的关系。包可用于容纳类、对象或者用例。

14. 主动对象可用于描绘一个并发对象( concurrent object)、进程( process )、线程（( thread)或任务( task )。可以用一个左右两边带有两根垂直线的方框表示一个主动对象。

15. 主动对象拥有自己的控制线程，并且能与其他对象并发执行。

    与此相反，被动对象不具有控制线程。被动对象只在其他对象（主动或被动)调用其方法时才会执行。

16. 部署图以物理结点和结点间物理连接的方式（例如网络连接）展示了一个系统的物理配置。一个结点使用一个立方体表示，连接则用这些立方体之间的连接线表示。本质上，部署图是以系统结点为关注点的一种类图。

17. UML扩展机制
    构造型: <>
    标记值 : {标记=值}

    约束 : {expression}

第三章

1. 瀑布模型的局限性

• 软件需求作为软件开发项目中的一个关键因素，无法进行合适的测试，直至一个工作系统被开发出来并能演示给最终用户。事实上，好几个研究工作已经指出软件需求规约的错误通常在最后才被检测到（直至执行系统测试或验收测试才能被检测到)，并且需要花费最大的代价对其进行纠正。
• 只有在生存周期的后期才能得到一个工作的系统。因此，直到系统几乎可以运行时，一个重要的设计或性能问题才有可能被发现，到那时通常已经太晚了，以至于无法采取有效的措施。

2. 抛弃型原型有助于解决瀑布模型的第一个问题，演化式原型则有助于解决第二个问题。

3. 一个抛弃型原型能够在一个初步的需求规约被制定之后就被开发出来。

4. 演化式原型方法是增量开发的一种形式，在增量开发中，原型从几个中间步骤的可运行系统逐步演化为可交付系统。

5. 螺旋模型是一个风险驱动的过程模型，最初由Boehm ( 1988）开发用来解决软件生存周期早期过程模型中存在的已知问题，涵盖其他生存周期模型，例如瀑布模型、增量开发模型以及抛弃型原型模型。

6. 软件确认的目标是要确保软件开发团队“构建了正确的系统”，也就是说，确保系统符合用户的需求。

7. 软件验证的目标是要确保软件开发团队“正确地构建系统”，也就是说，确保软件系统在每一个阶段中的构造与前一个阶段所定义的规约相符合。

8. 软件质量保证是指一系列确保软件产品质量的活动。软件验证和确认是软件质量保证的重要目标。

9. 软件生存周期的活动

   1. 需求分析和规约

   2. 体系结构设计

   3. 详细设计

   4. 编码

      软件测试

   5. 单元测试

   6. 集成测试

   7. 系统测试

   8. 验收测试

第四章

1. 对象：

   ①现实世界中物理的或概念的实体,它提供了对现实世界的理解。

   ②面向对象的应用由对象组成。

   ③对象包含数据及作用于数据之上的过程（操作、方法）

   ④对象有唯一的标识。

   ⑤一个对象是一个类的实例。

2. 类：具有相同特征的对象的集合

3. 属性：

   1. 类中的对象所持有的一个数据值，每一个对象的属性都有一个特定的取值。
   2. 在一个类中，属性名是唯一的,尽管不同的类可能拥有相同的属性名。

4. 操作：

   1. 由一个对象所执行的一项功能的规约。
   2. 一个对象可拥有一个或多个操作。操作对对象所包含的属性值进行操控。
   3. 操作可具有输入和输出参数。在同一个类中的所有对象拥有相同的操作。
   4. 操作和方法经常混用。
   5. 一个操作的签名包括该操作的名字、参数以及返回值。

5. 接口：

   1. 对象的接口是它提供的操作的集合，操作通过签名定义。
   2. 对象的类型用接口定义。
   3. 对象的实现用类来定义。
   4. 类是一种抽象数据类型。

6. 操作的规约(即操作的名字和参数)

7. 继承

   1.一种抽象机制
   2.对那些在某些方面相似但不完全相同的对象建模
   共同特征 唯一特性
   3.在不同类中分享和复用代码的机制
   超类/基类/父类
   派生类/子类
   4.将父类进行修改从而形成子类的过程称为特化
   5.子类还可以被进一步特化，形成泛化/特化层次结构
   6.类继承实现了一种扩展机制

8. 主动对象（第二次）

   1.又称为：并发对象/并发过程/并发任务/线程
   2.拥有自己的控制线程并能独立于其他对象而执行
   3.每个主动对象处理一个顺序执行的线程
   4.主动对象中不允许并发操作，整个系统的并发是通过多个主动对象的并行执行来实现
   5.主动对象可以异步执行，通常独立但也可相互通信同步

9. 被动对象
   1.没有控制线程
   2.被主动对象调用其操作
   3.可以调用其它被动对象的操作
   4.其操作一旦被主动对象调用，就会在主动对象所控制的线程中执行

10. 顺序应用是一个顺序的程序，它由一组被动对象组成并且仅有一个控制线程。

11. 并发应用中，通常有几个并发对象，每一个对象都拥有属于它自己的控制线程（多个）。

12. 软件体系结构：核心：定义构件及其连接的方式，将系统的整体结构与单个构件的内部实现细节进行分离。

13. 构件接口既要描述它所提供的操作，又要描述它所需要的操作

14. 对象接口一般仅需描述对象所提供的操作

15. 软件质量属性，（20章详解）：

    维护、修改、测试、追踪、扩展、复用、性能、可用、安全。

第五章

1. 增量软件构建包含了该子集中类的详细设计、编码和单元测试。

2. 在增量软件集成期间，要执行每个软件增量的集成测试。

3. 需求建模

   1.用例建模（陈述功能需求）
   系统的功能需求采用用例和参与者来描述
   用例定义了一个或多个参与者与系统之间的交互序列
   用例描述是一个行为视图；用例间的关系给出了一个结构视图
   2.陈述非功能性需求

4. 分析建模

   1.静态建模

   ​ 上下文类图

   ​ 类图E-R图

   2.对象的组织

   • 决定参加每个用例的对象。（哪些对象参加用例）
   • 给出对象的组织准则，以帮助确定系统中的软件对象:哪些是实体对象、边界对象、控制对象以及应用逻辑对象。

   3.动态交互建模

   • 实现用例来显示参与每个用例的对象之间的交互。
   • 开发通信图或序列图来显示对象如何相互通信来执行用例。

   4.动态状态机建模

   • 对状态相关的对象进行建模——状态图。

5. 设计建模（主要考虑问题的解决方案）

   将分析模型映射为并发设计模型

• 集成对象通信模型，开发集成的通信图。
• 做关于子系统结构和接口的决策。开发总体的软件体系结构。将应用组织为子系统。
• 做关于在软件体系结构中使用什么软件体系结构模式和设计模式的决策。
• 做关于类接口的决策，特别是对于顺序软件体系结构。对每个子系统，设计信息隐藏类（被动类)。设计每个类的操作和每个操作的参数。
• 做关于如何将分布式应用组织为分布式子系统的决策，其中子系统被设计成为可配置的构件，并且定义构件之间的消息通信接口。
• 做关于对象特性的决策，特别是它们是主动的还是被动的。对于每个子系统，将系统组织为并发的任务（主动对象)。在任务的组织过程中，使用任务组织准则来组织任务，并定义任务的接口。
• 做关于消息特性的决策，特别是它们是同步的还是异步的(要回复还是不要回复)。

第六章

1. 需求建模包括需求分析和需求规约。

2. 需求分析：分析需求和分析现存系统

3. 软件需求描述了系统必须为用户提供的功能。

4. 需求规约：需求分析师和用户达成共识的文档。

5. 功能性需求描述了为了达到系统的目的系统必须能够提供的功能。

6. 非功能性需求有时也被称作质量属性，是指系统必须满足的服务质量目标。

7. 用例定义了一个或多个参与者和系统之间的交互序列。

8. 用例建模是一种描述系统的功能性需求的方法。

9. 参与者描绘了一个与系统交互的外部用户(即在系统之外)。在用例模型中，参与者是与系统交互的唯一外部实体；换句话说，参与者是在系统之外的，不是系统的一部分。

10. 参与者一般由人类用户扮演

    有些系统中，有可能有其他类型的参与者作为人类参与者的补充或替代，如，与本系统通过接口连接的外部系统、设备或计时器。

11. 主要参与者-启动用例。因此，用例始于来自主要参与者的输人，系统必须响应主要参与者。

12. 其他参与者称为次要参与者，可以参与到用例中。一个用例中的主要参与者可以是另一个用例中的次要参与者。

13. 至少有一个参与者必须从用例中获得价值;通常，这就是主要参与者。

14. 人类参与者通常使用多种（标准/非标准）IO设备与系统进行物理交互。所有这些情况中，人是参与者，IO设备不是参与者。因此，参与者是终端用户。

15. 用例的主序列描述了参与者和系统之间最常见的交互序列。

    用例中的每个序列称作场景。一个用例通常描述了多个场景:一个主序列（主场景）和多个可替换序列（替代场景）。

16. 包含关系
    1.用来标识多个用例中共同的交互序列
    2.反映了多个用例之间共同的功能
    3.抽取出的共同交互序列形成一个新用例，称为包含用例，原来的用例称为基用例
    4.包含用例通常是抽象的，不能独立执行
    5.基用例包含并执行包含用例

17. 扩展关系
    1.有些用例的交互序列中有太多可替换的、备选或异常的分支
    2.可以将这些分支序列分离成单独的用例
    3.这些新用例扩展了原来的用例，称为扩展用例，原来的用例称为基用例
    4.可以根据条件，确定基用例以不同方式进行扩展
    5.基用例不依赖于扩展用例
    6.扩展用例依赖于基用例并在基用例中引起它执行的条件为真时才执行。

18. 扩展点

    1.用来规定基用例中能被增加扩展的位置
    ​2.扩展用例在扩展点上扩展基用例
    ​3.可以在扩展点上定义多个扩展用例，根据条件调用其中一个用例
    ​4.扩展条件是在基用例运行时设定和更改的

19. 扩展关系通过扩展点名称和选择条件来标识。

20. 活动图是一种描述控制流和活动中序列的UML图。

21. 活动图可用来表示用例的顺序步骤,包括主序列和所有的可替换序列

第七章

1. 静态模型展示的是问题的静态结构视图，它不随时间的变化而变化。

2. 静态模型涉及：
   1.类

   ​ 2.类的属性

   ​ 3.类之间的关系以及约束（操作）
   ​ 4.识别软件外部类及上下文类图
   ​ 5.对象和类的组织

3. 关联定义了两个或多个类之间的关系，指明了类之间的一种静态的、结构化的关系

4. 关联的多重性规定了一个类的多少个实例能与另一个类的单个实例建立关联

5. 组合也是实例之间的关系。因此，部分对象的创建、存在和消亡都是和整体一起的。部分对象只能属于一个整体。

6. 组合类经常涉及整体和部分之间的物理关系。（硬件，ATM机）

7. 聚合一般用于对概念类（非物理类）建模。（学院的组成）

8. 在组合和聚合里**,属性都从整体向部分传播**。

9. 约束规定了必须为真的条件或限制

10. 上下文建模显式地标识了什么是在系统内的，什么是在系统外的。

11. 上下文建模可以在整个系统（硬件和软件）的级别上完成，或者在软件系统（仅软件）的级别上完成。

12. 系统（硬件和软件）上下文类图

    1.在考虑软件系统上下文类图之前建模
    2.只有人类参与者和外部系统在系统边界之外
    3**.I/O设备是系统硬件的一部分，属于系统内部**类

13. 软件系统（软件）上下文类图

    1.I/O设备属于系统外部类

14. 外部类分类

    15. 通过标准输入/输出设备（键盘、显示器和鼠标）和软件系统交互的外部用户描述为外部用户<>

    16. 将非标准输入/输出设备建模为外部设备类

    17. 软件系统上下文类图中标准的关联名称是:输入到，输出到，和…通信，和…交互，向…发信号

    18. 参与者是一个比外部类更抽象的概念
        1.非标输入/输出设备参与者->外部输入/输出设备类
        2.外部系统参与者->外部系统类
        3.计时器参与者->外部计时器类
        4.人类参与者
        a.通过标准输入/输出设备与系统交互，建模为人类参与者的名称的类（人类建立成人类参与者，标准建立成外部用户类）
        b.通过非标准输入/输出设备与系统交互，建模为人类参与者通过外部输入/输出设备类与系统交互

        ​ (人类建立成人类参与者，设备建立成外部输入/输出设备类)

15. 实体类是概念性的数据密集型类——它们的主要目的是存储数据并提供对这些数据的访问。

16. 问题域静态建模阶段，重点仍是定义实体类、它们的属性和它们间的关系，操作的定义推迟到在设计建模。

第八章

1. 核心：确定软件系统内部的软件对象

2. 注意，更重要的是要确定系统中的所有对象，而不是过分关心如何分类少量模棱两可的情况。

3. 外部计时器类向软件计时器类发信号。（与控制类的计时器不同）

4. 协调者对象，是做出总体决策的对象，它确定相关对象的协作顺序，从而为用例的执行提供总体顺序安排

5. 由协调者对象发起的动作只取决于包含在传入消息中的信息，而不依赖于系统中之前发生的事情（只与输入有关，与状态无关）

6. 状态相关的控制对象,用有限状态机对它进行定义，用状态图来描述,不仅依赖该对象的输入，还依赖对象的当前状态

7. 计时器对象,要么自己执行某个动作，要么激活另一个对象来执行期望的动作,计时器对象是一个由外部计时器（如实时时钟或操作系统时钟）激活的控制对象

8. 业务逻辑对象,定义了用于处理一个客户端请求的特定业务的应用逻辑,将可能相互独立变化的业务规则封装到分离的业务逻辑对象中.

9. 设计决策：
   • 如果业务规则只有通过访问两个或更多的实体对象才能执行，就应该有一个分离的业务逻辑对象
   • 如果访问一个实体对象就足以执行业务规则，则可将它作为该对象的一个操作

10. 算法对象,封装了问题域中使用的算法,必须频繁与其他对象交互，以便执行算法

11. 服务对象,对其他对象提供服务，常用于面向服务的架构中。可能封装了它需要用来服务客户端请求的数据，或访问其他封装了该数据的实体对象

第九章

1. 动态交互建模，描述了被建模系统的控制行为以及系统构件交互的顺序安排

2. 通信图是一种UML交互图，描述了一组对象是如何通过对象间消息传递来实现交互

3. 顺序图(序列图)，序列图按时间的顺序展现了对象间的交互

4. 对系统进行动态描述时，通信图和序列图二选其一

5. 动态交互建模用来帮助分析对象之间是如何交互来实现用例的

6. 动态交互建模分为：
   无状态动态交互建模
   有状态动态交互建模

   状态相关的动态交互建模包括了一个由状态图控制的状态相关的通信，而无状态的动态交互建模则没有这一特点。

   实例形式用来详细地描述一个特定的场景，把一个可能的对象实例间的交互序列描绘出来。

   通用形式则是用来描述参与交互的对象之间所有可能的交互关系，因此会包含循环、分支和条件。

第十章

1. 有限状态机的概念
   1.是包含有限个状态的概念化机器
   2.对系统或对象的控制、顺序视图进行建模
   3.有限状态机行为既与当前输入相关，也与其之前发生的事件相关（输入+当前状态）
   4.输入事件引起状态转变，下一个状态依赖于当前状态和输入事件
   5.有时，状态转变会导致输出动作
   6.事件具有原子性且在概念上无持续
   7.状态是一种可识别的、存在于一段时间间隔内的情况，状态转变时间常被忽略

   有限状态机的表示法有状态转换图、状态图和状态转换表。

2. 事件是在某一个时间点发生的事情，事件也被称为离散事件、离散信号或激励。

3. 有限状态机可以对一个完整的系统建模，因此状态图可以描述系统

4. 通过使用警戒条件，使状态转变具有条件性，事件[条件]

5. 状态转变的结果是动作的执行

6. 三类动作定义方式
   状态转换中的动作
   进入动作
   退出动作

7. 层次化状态图，层次化状态分解
   引入复合状态，它可以被分解为多个子状态
   子状态相互关联且有先后顺序，称为顺序化状态分解

   ​ 当复合状态被分解为多个子状态时，必须保留进入和离开该复合状态的状态转换

8. 正交状态图
   1.是另一种层次化分解方式
   2.用来从不同的视角对同一对象状态进行建模
   3.高层次的状态可分解为两个或多个正交状态图
   4.当进入复合状态时，则同时进入正交的多个状态图的某个子状态
   5.可以用于表示并发，但不推荐，最好表示同一对象的不同部分（不是并发的）

第十一章

1. 状态相关的动态交互建模能够处理对象间的交互是与状态相关的情况。

2. 状态相关的动态交互建模中的步骤

   1.确定边界对象
   2.确定状态相关的控制对象
   3.确定其他软件对象
   4.确定主序列场景中的对象交互
   5.确定状态图的执行
   6.考虑备选序列场景

3. 交互图上的消息包含一个事件以及伴随事件的数据

4. 通信图覆盖了主序列也覆盖了所有可替换序列。

第十二章

1. 软件架构，一个程序或计算机系统的软件架构是包含了该系统的软件元素、这些元素的外部可见的属性以及这些元素之间关系的结构或一组系统结构

2. 软件体系结构模式

   1.软件高层设计的框架和模板
   2.又称体系结构风格，是不同软件应用中重复出现的软件结构设计方案

3. 基于构件的软件体系结构

   1.软件由构件组成，每个构件相对独立且封装了某些信息
   2.构件可以是简单对象或由其他对象组成的复合对象
   3.构件通过接口与其他构件通信
   ·接口描述了通信所需的所有信息
   ·接口与实现分离
   ·接口约定了通信模式

   顺序式设计（构件是类）
   • 构件是没有控制线程的被动类
   • 可以把构件单独编译并存储在构件库中
   • 采用唯一的通信模式：调用/返回

   并发或分布式设计
   • 构件是主动的（并发的），含有控制线程。
   • 可以被部属到一个分布式环境中的不同结点上
   • 并发构件可以通过几种不同的通信模式通信（通过底层中间件框架实现通信）
    同步模式
    异步模式
    代理模式
    群组通信模式

4. 结构视图

   1.是一种静态视图，不会随时间发生改变。
   2.子系统使用类图来描述

5. 动态视图

   1.是一种行为视图，子系统间消息通信
   2.使用子系统通信图来描述

   3.是一种泛化的通信图，描述了子系统间所有可能的交互场景 ，所以没有消息顺序编号

6. 部署视图

   1.描述了软件架构的物理配置
   2.表示子系统如何在一个分布式配置中分配到不同的结点上
   3.可以指明子系统的多个实例都可以部署到一个单独的接点上，但不指定实例的确切数量

7. 软件体系结构模式

   1.集中式控制模式

   ①仅包含单个控制构件
   ②控制构件执行一个状态图以总控全局并管理整个系统的行为顺序
   ③控制构件从与其交互的构件那里接收事件，并引发一个或多个状态相关动作
   ④控制构件通过动作控制系统中的其他构件

   2.分布式控制模式

   ①包含多个控制构件
   ②每个控制构件执行一个状态图以控制系统的特定部分
   ③控制分布于各个控制构件中
   ④控制构件通过点对点的通信实现重要事件的通知

   3.层次化控制模式

   ①包含多个控制构件
   ②每个控制构件执行一个状态图以控制系统的特定部分
   ③存在一个协调者构件，它协调所有控制构件来完成整个系统的控制
   ④协调者构件提供高层控制：
   ①直接与各个控制构件通信并决定各个控制构件的动作
   ②从控制构件接收状态信息

   4.抽象分层模式

   ①分层可以提高软件的伸缩性
   ·在提供服务的较低层次的基础上添加上层来扩展软件

   ​ ·移除上层即可收缩软件
   ②分层原则
   从软件构件的功能和角色角度分层
   从部署方法考虑

   5.多客户端/多服务模式

   ①多对多通信
   ②服务之间也可能相互通信
   ③既可以采取顺序性通信，也可以采用并发通信

   6.多客户端/单服务模式

   ①是客户端/服务器（C/S）架构的最常见模式，因此常直接称它为C/S模式
   ②一般采用顺序性通信方式

   7.多层客户端/服务架构模式
   ①拥有同时扮演着客户端和服务角色的中间层
   ②中间层可能有多个
   ③具有服务功能的层可部署在同一个服务器结点上

8. 软件体系结构通信模式

   1.异步消息通信模式（松耦合）

   ①生产者构件发送一条消息给消费者构件
   ②返回消息有两种情况
   a.不等待其回复，生产者继续执行
   b.有回复，但收到回复之前还要执行一些其它功能
   ③消息到达消费者后：
   a.消费者直接接收消息
   b.若消费者正在处理其他事情，消息会进入等待队列
   ④通过先进先出的消息队列进行异步通信
   在分布式环境中，异步消息通信模式可以大大提供系统的灵活性

   2.带回调的异步消息通信模式

   ①客户端向服务发送了一条请求后可以继续工作而不必等待应答
   ②服务需要在稍后向客户端发送答复信息（异步应答）
   ③一个客户端在同一时间只会向服务发送一条请求消息并收到服务的应答

   3.双向异步消息通信模式

   两个构件之间也可以使用点对点的异步消息通信。

   4.广播消息通信模式
   一个主动消息被发送给所有的接收者

   5.代理者转发模式

   ​ 1.提供了客户端和服务间消息转发的中介
   ​ 2.每条消息都可以被代理者审查，安全性高
   ​ 3.消息通信量加倍，效率低
   ​ 4.流程：
   ​ ①客户端向代理者发送一个服务请求
   ​ ②代理者查询服务的位置并将请求转发给合适的服务
   ​ ③服务执行请求并将回复发送给代理者
   ​ ④代理者将回复转发给客户

   6.代理者句柄模式

   ​ 1.减小了消息通信量
   ​ 2.当客户端和服务间可能存在会话并需要交换多条消息时特别适用
   ​ 3.流程：
   ​ ①客户端向代理者发送一个服务请求
   ​ ②代理者查询服务的位置并向客户端返回一个服务句柄
   ​ ③客户端使用服务句柄来请求合适的服务
   ​ ④服务执行请求并直接发送回复给客户端

   7.调用/返回模式

   ​ 1.是对象间最简单的通信形式
   ​ 2.是顺序设计的唯一通信形式
   ​ 被动对象类上的操作/方法调用

   ​ 操作被调用时，控制从调用操作传递到被调用操作
   ​ 被调用操作执行完后将控制返回调用操作
   ​ 伴随参数的传递

   8.协商模式

   ​ 1.软件主体（agent）之间协商，共同做出决策
   ​ 2.分为客户主体和服务主体

   9.服务发现模式

   ​ 1.之前的模式中，客户端知道请求的服务而不是位置，称为白页代理
   ​ 2.本模式中，客户端知道请求的服务类型而不是特定的服务——黄页代理
   ​ 3.先使用黄页代理，返回给客户端一个满足请求要求的所有服务的列表，客户端从中作出选择，再使用白页代理执行服务调用

   10.服务注册模式

   ​ 1.服务向代理者注册服务信息
   ​ 2.服务名称、服务描述和提供服务的位置
   ​ 3.服务在第一次加入“代理交易所”时需要注册
   ​ 4.服务每次位置变化，需重新注册
   ​ 5.流程：
   ​ ①服务向代理者发送“注册服务”请求
   ​ ②代理者在服务库中注册服务，并向服务发送“注册确认”

   11.订阅/通知消息通信模式
   ①使用组播通信方式
   ②订阅了某个主题的构件会接收该主题发送给订阅者的所有消息
   ③一个构件可以订阅和取消订阅一个主题
   ④发送者不需要知道订阅者

   12.带回复的同步消息通信模式

   ​ 1.客户端构件向服务构件发送一条消息并等待服务构件的回复
   ​ 2.消息到达服务构件后：
   ​ a.服务构件接收消息并处理
   ​ b.生成一个回复并将回复发送回客户端
   ​ 3.当服务构件未收到任何消息,服务构件挂起 (?)
   ​ 4.一般包含多个客户端和一个服务

   13.不带回复的同步消息通信（紧耦合），

   消息生产者给消费者发送完一个消息后会等待消息被消费者接收，一旦消费者接收消息则释放生产者

9. 软件体系结构事务模式

   1.事务是客户端对由两个或更多操作组成的服务的请求，这些操作属于同一个逻辑功能并必须全部完成或全部不做
   2.事务在客户端生成并发送给服务处理
   3.事务的ACID特性
   A：原子性，事务不可分割
   C：一致性，事务执行完，系统处于一致状态
   I：隔离性，两个事务间不相互影响
   D：持续性，事务结果的持久性

两阶段提交协议模式

​ 1.用于在分布式系统中处理事务的原子性问题
​ 2.例如，跨行转账
​ 转账事务由借和贷两个原子操作组成
​ 转账事务要么被提交，要么被终止
​ 3.第一阶段通信图

复合事务模式

​ 1.需要部分回滚
​ 2.当客户端的事务需求能够被分解成更小的原子性事务，且每个原子性事务能够被单独执行或回滚时， 可以使用此模式
​ 3.例如，旅行社
​ 预定机票
​ 预定宾馆
​ 租车

长事务模式

​ 1.是有人参与、需要很长甚至无限长的时间来执行的事务
​ 2.基于人行为的不可预知性
​ 3.将长事务分解成两个或更多的单独的事务（通常是两个）
​ 4.人的决策发生在连续的事务对儿之间

9. 从三个方面编写软件架构模式说明文档
   1.上下文,指产生问题的环境
   2.问题,指上下文中可能重复出现的问题
   3.解决方案,指一种解决问题的可行方法

   10. 接口明确了一个类、构件或服务的外部可见操作，而不需要提供其内部关于该操作的实现

第十三章

客户端子系统：包含用户交互子系统，控制子系统，IO子系统；

用户交互子系统：包含用户接口子系统，实体对象，控制对象；

服务子系统：包含实体对象，协调者对象，业务逻辑对象；

IO子系统：包含控制对象，实体对象。

第十四章

1. 信息隐藏，设计者需要确定哪些信息应该隐藏在类中，哪些信息应该放在类的接口中

2. 数据抽象类：封装数据结构

3. 包装器类：隐藏了访问存储在现有系统或遗留系统中的数据的访问接口，包装器可以封装对数据库的访问

4. 可复用的状态机类提供了两个通用的可复用的操作

   processEvent(in event, out action) //当有新事件需要处理时被调用，它查找状态转换表来确定此事件的影响，考虑状态机的当前状态和必须满足的条件，新状态是什么及需执行的动作；接着改变当前状态，返回需要执行的动作作为输出参数
   currentState(): State //返回状态机当前状态

第十五章

1. 顺序性服务的设计
   ①服务必须先完成上一个服务请求，才能开始处理下一个请求
   ②顺序性服务设计为一个并发对象（控制线程）来响应客户端的服务请求
   ③服务通常会有一个消息队列来存放收到的服务请求

   ​ ④服务协调者收到客户端消息后，按照消息类型调用相应服务对象所提供的操作
   ​ ⑤消息的参数作为操作的参数
   ​ ⑥服务对象的处理结果经由服务协调者发回客户端

2. 并发服务设计
   ①服务功能由多个并发的对象共同完成
   ②适用于客户端对于服务的要求很高，使用多个并发对象提供的服务可以提高系统的吞吐量

3. C/S模式中，数据抽象类更常位于客户端，数据库包装器类一般位于服务器端

4. 关系数据库表必须有一个主键，一般能够唯一确定表中某一行的属性选做主键，可以是复合主键

5. 外键是包含在一张表中的另一张表的主键，可以帮助从一张表导航到另一张表

第十六章

1. 面向服务架构(Service oriented Architecture, SOA)是一个由多个自治的服务组成的分布式软件体系结构

2. 各个服务可以用不同的语言实现，运行在不同的平台上

3. 服务间的通信和信息交换采用标准协议

4. 对每个服务都有服务描述

5. 服务消费者通过服务代理发现和调用服务（松耦合）

6. 事务是客户端对由两个或更多操作组成的服务的请求，这些操作属于同一个逻辑功能并必须全部完成或全部不做

7. 编制（编舞）(orchestration)：协调多个服务的采用集中式控制的工作流协调逻辑组成。

8. 编排（编曲）(choreography)：分布式协调，用于不同业务组织间的协调

9. 服务一般只有供给接口，而没有请求接口（除了使用带回调的异步通信），这样使服务更独立，便于复用

第十七章

1. 供给接口定义了构件必须实现的操作，代表其他构件使用本构件时的要求

2. 请求接口定义了在特定环境下其他构件需为本构件提供的操作，代表了本构件使用其他构件时的要求

3. 一个构件通过一个或多个端口与其他构件交互

4. 端口用供给和请求接口来定义
   ①一个供给端口支持一个供给接口
   ②一个请求端口支持一个请求接口
   ③一个复杂端口同时支持一个供给接口和一个请求接口

5. 构件的供给端口的名称以字母“P”开头

6. 构件的请求端口的名称以字母“R”开头

7. 连接器将一个构件的请求端口和另一个构件的供给端口连接起来

8. 被连接的两个端口必须相互兼容

9. 复合构件的端口可以连接到内部构件的端口上，称为委托连接器，此时两个端口名相同

第十八章

1. 实时软件架构是指必须同时处理多个输入事件流的并发式架构

2. 通常与状态相关，具有集中或非集中的控制方式

3. 设计并发对象（并发任务）是设计实时软件架构的重要工作

4. 设计并发软件时，将系统分解成一系列并发任务（对象），并定义了任务间的接口及交互

5. 客户端和服务各自都可以设计成并发软件架构

6. 实时系统通常被分为硬实时系统和软实时系统两类。硬实时系统具有必须满足的关键性时限以防止灾难性的系统失效。在软实时系统中也具有不希望被违反的时限要求，但是的超出时限并不会造成灾难性的后果，因而是可以容忍的。

7. 在分析模型中确定对象应该并发执行或者顺序执行，从而被设计为主动或被动对象

8. 两类重要的并发任务，I/O任务 & 内部任务

9. .I/O任务包括：
   ①事件驱动
   ②周期性
   ③按需驱动

10. 事件驱动I/O任务接收输入事件（中断），将它传给其他对象处理，随即转而对之后到来的中断做出迅速响应，构造型：<>

11. 周期性I/O任务，外部计时器周期性地发送计时器事件，从而触发周期性I/O任务，构造型：<>，用于需要周期性采样的被动传感器（输入）设备

12. 按需驱动I/O任务，处理不需周期性轮询的被动I/O设备，按需驱动I/O任务更常用于处理输出设备，构造型：<>

13. 周期性任务（内部），用来处理周期性执行的活动的任务。构造型：<>，该任务被计时器事件触发并执行周期性活动，随后等待下一个计时器事件。

14. 按需驱动任务，它被到达的外部消息或事件所触发，触发后任务开始处理所需请求，随后等待下一个消息或事件，<>、<>。

15. 控制任务，是分析模型中的状态相关的控制对象在设计模型中的实现，分析模型中的协调者对象也被设计成协调者任务，它也是一种控制任务，构造型：<>。

16. 用户交互任务，一个用户交互任务通常与多个标准I/O设备相连，由于操作系统为这些设备提供了标准接口，所以无需开发专用的I/O任务去处理它们，构造型<>,

    <>

17. 然后按以下顺序应用以上任务组织准则
    ①I/O任务，从外部的设备I/O对象来分析
    ②控制任务，分析每个状态相关控制对象和协调者对象
    ③周期性任务，分析内部周期性活动
    ④其他内部任务，由内部事件触发内部任务，构造为按需驱动任务

18. 事件同步机制，包括：外部事件同步，计时器事件同步，内部事件同步。

19. 任务接口规约（TIS）是类接口规约的扩展

20. 任务行为规约（TBS）描述任务事件的顺序逻辑，即任务如何对接收到的消息或输入事件做出响应

第十九章

第二十章

第二十一章

1. 微服务是一种分布式系统解决方案，通过使用细粒度服务，使其协同工作，每个服务有其生命周期

2. 微服务的定义：协同工作的小而自治的服务

3. 微服务的益处

   1 技术异构性，可以在不同服务中使用最适合的技术

   2 弹性，一个服务失效不会导致级联故障

   3 扩展性，若系统中只有一小部分存在性能问题，只要对需要扩展的服务进行扩展即可

   4 简化部署，各服务独立部署

   5 与组织结构匹配，小型代码库使得团队工作更高效

   6 可组合性，根据不同目的，以不同方式重用服务

   7 对可替换性的优化，采用微服务可以轻易重写服务