系统架构设计师备考系列之系统架构设计

一、基础概念

1.1 定义

• 架构设计就是需求分配，将满足需求的职责分配到组件上。
• 软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。
• 解决软件的复用、质量和维护问题，是研究软件架构的根本目的。
• 软件架构设计是在需求捕获并进行分析之后开展的工作，软件架构设计不能捕获需求。

1.2 作用

• 软件架构是项目干系人进行交流的手段。
• 软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
• 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

1.3 架构描述语言(ADL)

• ADL的三个基本元素
  • 构件：计算或数据存储单元。
  • 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
  • 架构配置：描述体系结构的构件与连接件的连接图。

1.4 架构的"4+1"视图

二、基于架构的软件开发方法(ABSD) [重点]

2.1 定义

• ABSD方法是由 体系结构驱动的，即指由构成体系结构的 商业、质量和功能需求的组合驱动的。
• ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用。
• 视角与视图：从不同的视角来检查，所以会有不同的视图；采用视角与视图描述软件架构。
• 用例和质量场景：用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求。
• ABSD方法中使用的设计元素如图7-1所示。在最顶层，系统被分解为若干概念子系统和一个或若干个软件模板。在第2层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。
  

2.2 开发模型

• ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程。
  
• ABSD能很好的【支持软件重用】；
• ABSD方法是一个自顶向下，递归细化的方法；
• 软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

2.2.1 架构需求过程

• 需求获取
  架构需求一般来自3个方面，分别是系统的质量目标、系统的商业目标和系统开发人员的商业目标。
• 识别构件
  标识构件过程为系统生成初始逻辑结构，包含大致的构件。
  
• 架构需求评审

2.2.2 架构设计

• 架构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程。架构设计过程如下图：
  
• 1.提出架构模型
  在建立体系结构的初期，选择一个合适的架构风格是首要的。在这个风格的基础上，开发人员通过架构模型，可以获得关于体系结构属性的理解。此时，虽然这个模型是理想化的(其中的某些部分可能错误地表示了应用的特征),但是，该模型为将来的实现和演化过程建立了目标。
• 2.把已标识的构件映射到架构中
  把在架构需求阶段已标识的构件映射到架构中，将产生一个中间结构，这个中间结构只包含那些能明确适合架构模型的构件。
• 3.分析构件之间的相互作用
  为了把所有已标识的构件集成到架构中，必须认真分析这些构件的相互作用和关系。
• 4.产生架构
  一旦决定了关键构件之间的关系和相互作用，就可以在第2阶段得到的中间结构的基础上进行精化。
• 5.设计评审
  一旦设计了架构，必须邀请独立于系统开发的外部人员对体系结构进行评审。

2.2.3 架构文档化

• 体系结构文档化过程的主要输出结果是两个文档： 体系结构规格说明和测试体系结构需求的质量设计说明书。
• 文档的完整性和质量是软件体系结构成功的关键因素。
• 关于文档的三大注意事项：
  • 文档要从使用者的角度进行编写，
  • 必须分发给所有与系统有关的开发人员，
  • 必须保证开发者手上的文档是最新的。

2.2.4 架构复审

• 架构复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误。

2.2.5 架构实现

• 架构的实现过程，如下图：
  

2.2.6 架构演化

• 架构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括图中6个步骤。
  

三、软件架构风格 [重点]

3.1 定义

• 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些连接件和构件组合起来的。
• 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织程一个完整的系统。

  结构特性：指系统的​​静态组织方式​​，即组件（Component）、连接件（Connector）和它们之间的拓扑关系。具体表现包括​​：
  1) 组件类型​​：例如管道-过滤器风格中的“过滤器”、分层架构中的“层”、微服务中的“服务”。
  2) ​​连接机制​​：如函数调用、消息队列、RPC、共享内存等。
  3) 拓扑约束​​：组件如何连接（如分层架构禁止跨层调用、事件总线中的发布/订阅模式）。
  语义特性：指系统的​​动态行为规则​​，即组件如何通过交互完成功能，包括数据流、控制流、异常处理等。具体表现包括​​：
  ​​ 1) 交互协议​​：如REST风格的HTTP动词语义（GET/POST/PUT/DELETE）、事件驱动中的消息顺序。
  2) ​​数据流模式​​：批处理（数据积累后处理） vs. 流处理（实时处理）。
  3) ​​一致性约束​​：如微服务中最终一致性（Eventual Consistency）的语义保证。

• 架构设计的一个核心问题是能否达到架构级的软件复用。

3.2 数据流风格（Data Flow）

• 说明：面向数据流，按照一定的顺序从前向后执行程序
• 代表性风格
  • 批处理序列：构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始。适用场景：大量整体数据、无需用户交互
  • 管道-过滤器：前一个构件的输出作为后一个构件的数据，前后数据流关联。如：编译器。流式数据，弱用户交互。
  • 区别：批处理前后构件不一定有关联，并且是作为整体传递；管道过滤器是前一个输出作为后一个输入，前面执行到部分就可以开始下一个的执行。
• 优缺点比较

优点	缺点	典型实例
1. 松耦合【高内聚-低耦合】 2. 良好的重用性/可维护性 3. 可扩展性【标准接口适配】 4. 良好的隐蔽性 5. 支持并行	1. 交互性较差 2. 复杂性较高 3. 性能较差（每个过滤器都需要解析与合成数据）	传统编译器 网络报文处理

3.3 调用/返回风格 (Call/Return)

• 说明：构件之间存在互相调用的关系，一般是显式的调用。
• 代表性风格
  • 主程序/子程序
  • 面向对象
  • 层次结构
• 分层架构风格优缺点比较

优点	缺点	特点
1. 良好的重用性，只要接口不变可用在其它处； 2. 可维护性好； 3. 可扩展性好，支持递增设计。	1. 并不是每个系统都方便分层； 2. 很难找到一个合适的、正确的层次抽象方法； 3. 不同层次之间耦合度高的系统很难实现。	各个层次的组件形成不同功能级别的虚拟机； 多层相互协同工作，而且实现透明。

3.4 独立构件风格 (Independent Components)

• 说明：构件之间是相互独立的，不存在显式的调用关系，而是通过某个事件触发，异步的方式来执行。
• 代表性风格
  • 进程通信
  • 事件驱动系统
• 优缺点比较

优点	缺点	特点
1. 松耦合。 2. 良好的重用性/可修改性/可扩展性。	1. 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。 2. 数据交换的问题。 3. 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。	系统由若干子系统构成且成为一个整体； 系统有统一的目标； 子系统有主从之分； 每一子系统有自己的事件收集和处理机制。

3.5 虚拟机风格 (Virtual Machine)

• 说明：自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配。

• 代表性风格

  • 解释器
  • 基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中

• 优缺点比较

子分类	优点	缺点	特点	适合领域
解释器	可以灵活应对自定义场景	复杂度较高		适用于需要“自定义规则”的场合
规则为中心	(同上)	(同上)	在解释器的基础上增加经验规则	适用于专家系统

3.5.1 解释器风格

3.5.2 规则系统风格

基于规则的系统(见图7-16)包括规则集、规则解释器、规则/数据选择器及工作内存。

3.6 仓库风格（以数据为中心 Data-Centered)

• 说明：以数据伟中心，所有的操作都是围绕建立的数据中心进行的。
• 仓库风格中，有两种不同的构件
  • 记录当前数据的状态中央数据结构
  • 一组对中央数据进行操作的独立构件
• 代表性风格
  • 数据库系统
  • 超文本系统
  • 黑板系统：包括知识源、黑板和控制三部分。通常应用于对于解决问题没有确定性算法的软件中，如信号处理、问题规划、编译器优化、语音识别、知识推理等。
• 现代编译器的集成开发环境一般采用数据仓库风格进行开发，其中心数据就是程序的语法树。
• 优缺点比较

子分类	优点	缺点	特点	典型实例
数据库系统			以数据为中心
黑板系统	可更改性和可维护性； 可重用的知识源； 容错性和健壮性	测试困难； 不能保证有好的解决方案； 难以建立好的控制策略； 低效； 开发困难； 缺少并行机制	在以数据为中心的基础上，使用中心数据触发业务逻辑部件	语音识别 模式识别 图像处理 知识推理

3.6.1 黑板架构风格

• 黑板
  用于支持多种知识源的协作，但更注重动态推理和解决问题的过程，而不是单纯的记录数据状态。
• 知识源
  知识源是执行特定功能的独立模块，但它不直接负责记录数据状态
• 控制
• 中央数据结构
  中央数据结构是仓库系统中的核心，起到了数据处理单元的作用。它是所有组件共享的数据存储区域，所有的知识源都会访问和更新这个中央数据结构，它准确描述了当前数据的状态。
  

3.7 模型驱动架构 (MDA)

MDA（模型驱动架构）是一种以模型为核心的软件开发方法，通过抽象模型与自动化转换实现跨平台开发。其核心思想是将业务逻辑与平台技术分离，通过模型映射实现从概念设计到具体实现的过渡。

• 主要目标
  • 可移植性
  • 互通性
  • 可重用性
• 3种核心模型
  • 平台独立模型(PIM）：具有高抽象层次、独立于任何实现技术的模型。
  • 平台相关模型(PSM）：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
  • 代码Code：用源代码对系统的描述（规约)。每个PSM都将被变换成代码。

四、软件架构复用

软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

4.1 可复用的资产

• 需求
• 架构设计
• 元素
• 建模与分析
• 测试
• 项目规划
• 过程、方法和工具
• 人员
• 样本系统
• 缺陷消除

4.2 复用的过程

• 构造可复用资产
• 管理可复用资产
  • 该阶段最重要的是：构件库 (Component Library), 由于对可复用构件进行存储和管理，它是支持软件复用的必要设施。
  • 在这个过程中，存在两个关键问题：一是构件分类，构件分类是指将数量众多的构件按照某种特定方式组织起来；二是构件检索，构件检索是指给定几个查询需求，能够快速准确地找到相关构件。
• 使用可复用资产

4.3 复用的维度

• 水平复用
  不分行业领域，通用
• 垂直复用
  区分行业领域，专用

4.4 构件的复用

五、特定领域软件架构 (DSSA)

5.1 定义

特定领域软件架构以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。

• DSSA 分类
  • (1) 垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。
  • (2) 水平域：定义了在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。

5.2 基本活动及产出物

5.2.1 领域分析

这个阶段的主要目标是获得领域模型

5.2.2 领域设计

这个阶段的主要目标是获得DSSA

5.2.3 领域实现

这个阶段的主要目标是依据领域模型和DSSA 开发和组织可重用信息

5.3 参与人员

5.3.1 领域专家

领域专家可能包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、 DSSA等领域工程产品等。

5.3.2 领域分析人员

领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。领域分析人员的主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。

5.3.3 领域设计人员

领域设计人员应由有经验的软件设计人员来担任。领域设计人员的主要任务包括控制整个软件设计过程，根据领域模型和现有的系统开发出 DSSA, 对 DSSA 的准确性和一致性进行验证，建立领域模型和 DSSA 之间的联系。

5.3.4 领域实现人员

领域实现人员应由有经验的程序设计人员来担任。领域实现人员的主要任务包括根据领域模型和 DSSA, 或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立 DSSA与可重用构件间的联系。

5.4 建立过程

• DSSA的建立过程分为五个阶段，每个阶段可以进一步划分为一些步骤或子阶段；
• 每个阶段包括一组需要回答的问题，一组需要的输入，一组将产生的输出和验证标准；
• 本过程是并发的 (Concurrent)、 递归的 (Recursive)、 反复的 (Iterative)。 或者可以说，它是螺旋模型(Spiral)。
• 完成本过程可能需要对每个阶段经历几遍，每次增加更多的细节。
  
  

六、软件质量属性 [重点]

6.1 基于软件系统的生命周期

• 将软件系统的质量属性分为开发期质量属性和运行期质量属性2个部分。
  

6.2 面向架构评估的质量属性

6.2.1 性能

• 定义：性能 (Performance) 是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段事件内系统所能处理的事件的个数。
• 度量：响应时间、吞吐量
• 设计策略：
  • 资源需求 （提高计算效率、减少计算开销、管理事件率、控制采样率）
  • 资源管理（引入并发机制、增加计算资源）
  • 资源仲裁 （优先级队列、采用资源调度）

6.2.2 可用性

• 定义：系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
• 度量：故障间隔时间
• 设计策略
  • 错误检测（命令/响应、Ping/Echo、心跳、异常）
  • 错误恢复（表决、冗余、备件）
  • 错误预防（进程监视器、事务、从服务器删除）

6.2.3 安全性

• 定义
  安全性 (Security) 是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
  • 机密性保证信息不泄露给未授权的用户、实体或过程；
  • 完整性保证信息的完整和准确，防止信息被非法修改；
  • 不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为；
  • 可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
• 度量：机密性、完整性、不可否认性及可控性
• 设计策略
  • 抵抗攻击（身份验证、用户授权、数据加密、数据完整性、限制暴露、限制访问）
  • 检测攻击（入侵检测）
  • 从攻击中恢复（识别：审计追踪、恢复：冗余）

6.2.4 可修改性

• 定义
  可修改性 (Modifability) 是指能够加粗样式olor=red>快速地以较高的性价比对系统进行变更的能力。
• 度量：人日、人月
• 设计策略
  • 局部修改（维持语义的一致性、预期期望的变更、泛化模块、限制可能的选择、抽象通用服务）
  • 防止连锁反应（隐蔽信息、维持现有的接口、限制通信路径、使用仲裁者）
  • 推迟绑定时间（运行时注册、配置文件、多态、组件更换、遵守已定义的协议）

6.2.5 易用性

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。例如:

• 界面友好;
• 新用户学习使用系统时间不超过2小时。

6.2.6 可测试性

软件可测试性是指通过测试揭示软件缺陷的容易程度。例如:

• (1)提供远程调试接口，支持远程调试。

6.2.7 功能性

功能性 (Functionality) 是系统能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

6.2.8 互操作性

作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件架构。

6.2.9 可变性

可变性 (Changeability) 是指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些具体方面不同于原有的架构。当要将某个架构作为一系列相关产品(例如，软件产品线)的基础时，可变性是很重要的。

6.3 质量属性场景描述

6.3.1 定义

• 为了精确描述软件系统的质量属性，通常采用质量属性场景(Quality Attribute Scenario) 作为描述质量属性的手段。质量属性场景是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。
• 场景是从风险承担者的角度与系统交互的简短描述

6.3.2 场景的六个组成部分

• 刺激源
  这是某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
• 刺激
  该刺激是当刺激到达系统时需要考虑的条件。
• 环境
  该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
• 制品
  某个制品被激励。这可能是整个系统，也可能是系统的一部分。
• 响应
  该响应是在激励到达后所采取的行动。
• 响应度量
  当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。
  

七、软件架构评估方法 [重点]

7.1 相关概念

• 敏感点：敏感点是一个或多个构件(和/或构件之间的关系)的特性，它能影响系统的某个质量属性。
• 权衡点：权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
• 风险点：是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
• 非风险点：是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。

7.2 架构评估分类

• 基于调查问卷的方式
  类似于需求获取中的问卷调查方式，只不过是架构方面的问卷，要求评估人员对领域熟悉。
• 基于度量的方式
  制定一些定量指标来度量架构，如代码行数等。要制定质量属性和度量结构之间的映射，要求评估人员对架构熟悉。
• 基于场景的方式
  • 主要方法。首先要确定应用领域的功能和软件架构的结构之间的映射，然后要设计用于体现待评估质量属性的场景(即4+1视图中的场景)，最后分析软件架构对场景的支持程度。要求评估人员即对领域熟悉，也对架构熟悉。从三个方面对场景进行设计:刺激(事件);环境(事件发生的环境);响应(架构响应刺激的过程)。
  • 基于场景的方式由卡耐基梅隆大学软件工程研究所首先提出并应用在架构权衡分析法 (Architecture Tradeoff Analysis Method,ATAM) 和软件架构分析方法(Software ArchitectureAnalysis Method,SAAM) 中。
  • 它是通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
    

7.2 基于场景的软件结构分析方法 (SAAM)

• SAAM是一种非功能质量属性的架构分析方法，是最早形成文档并得到广泛使用的软件架构分析方法。
• 特定目标： SAAM的目标是对描述应用程序属性的文档，验证基本的架构假设和原则。
• 质量属性：这一方法的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。
• 架构描述：SAAM用于架构的最后版本，但早于详细设计。架构的描述形式应当被所有参与者理解。功能、结构和分配被定义为架构描述的3个主要方面。
• 方法活动：SAAM的主要输入是问题描述、需求声明和架构描述。SAAM分析评估架构的过程包括5个步骤，即场景开发、架构描述、单个场景评估、场景交互和总体评估。图8-1描绘了SAAM分析活动的相关输入及评估过程。
  

7.3 架构权衡分析法 （ATAM）

• 架构权衡分析方法 (Architecture Tradeoff Analysis Method,ATAM) 是在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
• ATAM让架构师明确如何权衡多个质量目标，参与者有评估小组、项目决策者和其他项目相关人。
• ATAM被分为4个主要的活动领域(或阶段), 分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中。图8-2描述了与每个阶段相关的步骤，还描述了架构设计和分析改进中可能存在的迭代。
  
• ATAM 方法采用效用树 (Utility tree) 这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根—质量属性—属性分类—质量属性场景(叶子节点)。需要注意的是，ATAM主要关注4类质量属性：性能、安全性、可修改性和可用性。
• 在架构权衡分析方法(ATAM)中，头脑风暴的三种场景类型为
  • 用例场景:表示系统在典型工作负载或使用情况下的行为。
  • 增长场景:描述系统随着需求变化或规模扩展的能力。
  • 探索性场景:表示非典型或异常使用情况下的表现，强调性和边界条件。

7.4 其他评估方法

• 成本效益分析法 CBAM：在ATAM基础上建立的，软件的"经济"模型。
• SACMM方法：是一种软件架构修改的度量方法
• SASAM方法：通过对预期架构（架构设计阶段的相关描述材料）和实际架构（源代码中执行的架构）进行映射和比较来静态地评估软件架构。
• ALRAA方法：一种软件架构可靠性风险评估方法。
• AHP（层次分析）方法：对定性问题进行定量分析。
• SAABNet方法：一种用来表达和使用定性知识以辅助架构的定性评估。来源于人工智能。
• COMSMIC+UML方法：基于度量模型来评估软件架构可维护性的方法。

八、构件与中间件技术

8.1 构件

8.1.1 构件的特性

• 独立部署单元
• 作为第三方的组装单元
• 没有外部的可见状态

一个构件可以包含多个类元素，但是一个类元素只能属于一个构件

8.1.2 对象的特性

• 一个实例单元，具有唯一的标志
• 可能具有状态，此状态外部可见
• 封装了自己的状态和行为
  

8.1.3 构件接口

接口标准化是对接口中消息的格式、模式和协议的标准化。它不是要将接口格式化为参数化操作的集合，而是关注输入输出的消息的标准化，它强调当机器在网络中互连时，标准的消息模式、格式、协议的重要性。

8.1.4 构件标准三大流派

• EJB
  • 会话Bean
  • 实体Bean
  • 消息驱动Bean
• COM、DCOM、COM+
• COBRA标准
  • 对象请求代理
  • 公告服务对象
  • 公告设施

8.1.5 构件的复用

8.1.5.1 检索与提取构件

• 基于关键字的检索
• 刻面检索法
• 超文本检索法

8.1.5.2 理解与评价构件

• 1、要复用构件，准确地理解构件至关重裂。特别是对构件修改使用时。
• 2、为达到目的，必须要求构件的开发过程遵备公共标准。
• 3、一般构件库的文档中全面而准确地说明以下内容:
  构件的功能与行为、相关的领域知识、可透应性约束条件与例外情形、可以预见的修改部分及修改方法。

8.1.5.3 修改构件

• 1、理想状态是直接复用构件库中现成的构件，但大多致情况下，必须对构件进行或多或少的修改，以应对新需求。
• 2、为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。
• 3、构件库中若无可修改使用的构件，则按新需求开发构件，并存入构件库。

8.1.5.4 组装构件

• 组装的三种方式
  • 1、基于功能的组装：采用子程序调用和参数传递的方式将构件组起来。
  • 2、基于数据的组装：仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson系统开发方法。
  • 3、面向对象的组装:如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。
• 构件组装失配问甄
  • 1、由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配;
  • 2、由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配;
  • 3、由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的于段消除检测出的失配问题。

8.2 中间件

8.2.1 定义

• 中间件: 在一个分布式系统环境中处于操作系统和应用程序之间的软件，可以在不同的技术之间共享资源，将不同的操作系统、数据库、异构的网络环境以及若干应用结合成一个有机的协同工作整体。
• 中间件是一类构件
• 中间件是一类系统软件
  

8.2.2 中间件技术的优点

8.2.3 中间件分类

九、其他架构知识

9.1 领域驱动设计（Domain-Driven Design, DDD）

• 领域驱动设计的分层结构是解耦业务逻辑与技术实现的核心框架，其标准分层如下（自顶向下依赖，禁止反向调用）：
  • 用户接口层（User Interface Layer）作用：处理外部输入（HTTP请求、消息、CLI命令等），封装输出（JSON/XML/视图）。
  • 应用层（Application Layer）作用：编排领域对象完成业务用例，不包含业务规则。
  • 领域层（Domain Layer）业务核心作用：承载业务规则和状态，与技术实现无关。
  • 基础设施层（Infrastructure Layer）作用：实现技术细节，为上层提供支撑。