脚踏实地

软件架构概念

软件架构 = 软件体系结构

架构的本质：

1. 软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
2. 软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。

架构的作用

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

软件架构设计是【降低成本】、【改进质量】、【按时和按需交付产品】的关键因素。 架构设计就是需求分配，即将满足需求的职责分配到组件上。分析需求，将需求转换多个功能，设计各个功能之间的联系及功能与需求之间的联系。

软件架构设计生命周期

1. 需求分析阶段。模型转换关注两个问题：如何根据需求模型构建架构（SA）模型+模型转换可溯源。
2. 设计阶段。SA研究关注得最早和最多的阶段。ADL、4+1视图。
3. 实现阶段。
4. 构建组装阶段。在较高层次上实现系统，高效。
5. 部署阶段。SA为部署提供高层视图指导。
6. 后开发阶段。动态软件体系结构（内部执行和外部请求导致变化）、体系结构恢复与重建。

ADL

ADL是这样一种形式化语言（类似伪代码），它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。

• C2SADL【基于组件和消息的软件架构描述语言】
• Wright【分布、并发类型的架构描述语言】
• ACME【架构互换语言】
• UniCon【基于组件和连接的架构描述语言】
• Rapide【基于事件的架构描述语言】
• 其他【Darwin、MetaH、Aesop、Weaves、SADL、xADL】

ADL的三个基本元素：

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

4+1视图

从不同视角来检查，所以会有不同的视图。

1. 逻辑视图：类与对象
2. 实现/开发视图：配置、装配、源代码结构
3. 进程/过程视图：性能、可伸缩、吞吐率、并发
4. 部署/物理视图：发布安装、拓扑结构
5. 用例/场景视图

基于架构的软件开发方法

基于架构的软件开发方法（ABSD）

• ABSD方法是架构驱动，即强调由业务【商业】、质量和功能需求的组合驱动架构设计。
• ABSD方法有三个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用。
• 视角与视图：从不同的视角来检查，所以会有不同的视图。用来描述功能需求。
• 用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求。

开发过程

ABSD能很好的【支持软件重用】。 ABSD方法是一个自顶向下，递归细化的方法。软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

架构需求

架构设计

架构文档化

架构文档化过程的主要输出结果是架构规格说明和测试架构需求的质量设计说明书这两个文档。文档的完整性和质量是软件架构成功的关键因素。

关于文档的三大注意事项：

1. 文档要从使用者的角度进行编写
2. 必须分发给所有与系统有关的开发人员
3. 且必须保证开发者手上的文档是最新的

架构复审

架构复审【架构评估】的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误。

架构实现

架构演化

软件架构风格

数据流风格

数据流风格的基本思想是将数据处理分步骤进行，前一步骤的处理结果是后一步的输入内容，以数据为驱动。 典型的示例有传统编译器、网络报文处理。

优点：

1. 松耦合【高内聚-低耦合】；
2. 良好的重用性/可维护性；
3. 可扩展性【标准接口适配】；
4. 良好的隐蔽性；
5. 支持并行；

缺点：

1. 交互性较差；
2. 复杂性较高；
3. 性能较差（每个过滤器都需要解析与合成数据）；

数据流子风格：

• 批处理子风格特点：大量整体数据、无需用户交互
• 管道过滤器子风格特点：流式数据、若用户交互

调用/返回风格

开发中用到最多、最重要的风格。调用/返回即，主函数调用子函数，子函数被调用之后，会计算得到执行的结果，最终返回给主函数。

调用/返回风格出现的背景是一个完整的系统过于复杂，将其分成不同的层次，各层之间各司其职，层与层之间进行调用，从而实现解耦合。 各个层次的组件形成不同功能级别的虚拟机；多层相互协同工作，而且实现透明。

优点：

1. 良好的重用性，只要接口不变可用在其它处；
2. 可维护性好；
3. 可扩展性好，支持递增设计；

缺点：

1. 并不是每个系统都方便分层；
2. 层次多了影响效率，很难找到一个合适的、正确的层次抽象方法；
3. 不同层次之间耦合度高的系统很难实现；

调用/返回子风格：

• 主程序子程序：面向过程
• 面相对象：对象的方法调用
• 分层：层与层之间的方法调用

独立构件风格

构件之间不直接交互，而是通过事件管理机制来通知目标函数执行。

优点：

1. 松耦合。
2. 良好的重用性/可修改性/可扩展性。

缺点：

1. 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。 而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
2. 数据交换的问题。
3. 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。

特点：

1. 系统由若干子系统构成且成为一个整体；
2. 系统有统一的目标；
3. 子系统有主从之分；
4. 每一子系统有自己的事件收集和处理机制；

虚拟机风格

最常见的虚拟机就是JVM，使用虚拟机有一个特性，就是能够使得跨平台。 C语言代码是直接编译为机器语言，针对不同的操作系统，编译生成的代码会有一些差别，所以它不支持跨平台。 Java语言是将代码编译为字节码文件，只能使用Java虚拟机运行。Java虚拟机的作用是解释和执行字节码文件，分为windows的JVM、Linux的JVM、Mac的JVM，能够对相同的字节码文件运行，所以它能够跨平台。

解释器风格

可以灵活应对自定义场景，但复杂度较高，适用于需要自定义规则的场景。

• 存储器：存储被解释执行的程序；
• 解释器引擎：解释程序，解释程序会调用解释器引擎；
• 状态器：记录程序执行的当前状态、记录解释器引擎的内容状态；

规则系统风格

基于规则的系统构成：规则集、规则解释器、规则/数据选择及工作内存，一般用在人工智能领域和DSS（决策支持系统）中。

可以灵活应对自定义场景，但复杂度较高。在解释器的基础上增加经验规则、知识库等信息，适用于专家系统，可理解为加强版的解释器。

以数据为中心

以数据为中心的风格又叫仓库风格。仓库风格顾名思义有一个仓库，仓库是用来存储数据，可理解为数据库。

子风格有3个：

• 数据库系统；（了解）
• 黑板系统；（重点）
• 超文本系统；（了解）

黑板系统

黑板用来记录数据，是一个中央数据源，是一个交换信息，更新信息的一个系统。 黑板系统风格就是在仓库风格基础上，增加了一个与知识源之间的触发机制。

黑板系统特点：

1. 有不错的可更改性和可维护性；可重用的知识源；容错性和健壮性。
2. 测试困难；不能保证有好的解决方案；难以建立好的控制策略；低效；开发困难；缺少并行机制。
3. 在以数据为中心的基础上，使用中心数据触发业务逻辑部件。

黑板系统典型实例：语音识别、模式识别、图像处理、知识推理等。

闭环风格

又叫过程控制风格，常见于嵌入式系统，用于解决简单闭环控制问题，经典应用：空调温控、定速巡航。

假设你看电视，要调到10频道，给定值发给控制器（遥控器），遥控器执行命令，控制换台。数据发出去之后，不会持续跟进，也不会持续比较，它不会达到预期结果。 而闭环系统，会有一个比较环节，通过比较器来判断是否达到预期结果，如果不达到预期结果，则会继续调整。

C2风格

【了解】由构件和连接件组成，通过连接件来连接构件。

C2架构的基本规则：

1. 构件和连接件都有一个顶部和一个底部。
2. 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
3. 一个连接件可以和任意数目的其他构件和连接件连接。
4. 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

模型驱动架构

模型驱动架构（MDA：Model DrivenArchitecture）全称模型驱动架构，形式化方法下的一种实现分支。 使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。

MDA的主要目标：

1. Portability（可移植性）
2. interoperability（互通性）
3. Reusability（可重用性）

MDA核心模型（有歧义）：

1. 计算无关模型（CIM）：偏向于领域，对某具体行业内一个项目的业务需求及其系统功能需求进行分析。
2. 平台独立模型（PIM）：(UML)平台无关模型，具有高抽象层次、独立于任何实现技术的模型。
3. 平台相关模型（PSM）：偏向于某一个方向、平台。为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
4. 代码Code：用源代码对系统的描述（规约）。每个PSM都将被变换成代码。

软件架构复用

【软件复用】是一种系统化的软件开发过程，通过识别、分析、分类、获取和修改软件实体，以便在不同软件开发过程中重复使用它们。

软件开发过程中重复使用相同或相似【软件元素】的过程。

复用维度：

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

软件架构类型复用：

• 机会复用：开发过程中，只要发现有可用的资产，就对其复用，一有机会就复用；
• 系统复用：开发之前，进行规划，决定那些需要复用；

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

复用流程：

1. 【获取】构造可复用资产；获取可复用软件资产；
2. 【存储】对资产进行入库；对资产进行分类，构建检索；
3. 【应用】从库里提取，复用资产；修改、配置、扩展、组装、集成，最终形成系统；

特定领域软件架构

特定领域软件架构（DSSA：Domain Specific Software Architecture）以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。 简而言之，就是将共性的内容提取出来，形成特定领域架构，从而生成系统。

DSSA类型：

• 垂直型：相同领域，深入；
• 水平型：不同领域，共性通用，平移；

DSSA参与人员：

1. 领域专家：有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
2. 领域分析人员：领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。
3. 领域设计人员：领域设计人员应由有经验的软件设计人员来担任。
4. 领域实现人员：领域实现人员应由有经验的程序设计人员来担任。

DSSA建立过程：

1. 定义领域范围
2. 定义领域特定元素
3. 定义领域特定的设计和实现需求的约束
4. 定于领域模型和架构
5. 完成相应的产品单元

DSSA三层次模型：

1. 领域开发环境
2. 特定领域应用开发环境
3. 应用执行环境

软件产品线

软件产品线包括软件架构技术、领域工程、DSSA也包括自己特有的一些技术。 它的思想是源于工厂的流水线，软件开发若干年之前需要定制开发，实际上相同领域的软件没必要定制，里面存在大部分相同的代码，所以关键是建立核心资源库。 核心资源库是建立公版软件，然后通过定制化来开发软件。适合某个企业专门研发某类软件。

软件架构评估

软件架构评估是【考试重点】。

为什么要进行架构评估？
架构评估的核心是提前暴露设计风险，降低因架构缺陷导致的后期修改成本。例如，未评估扩展性的系统可能在用户量激增时无法扩容，引发服务崩溃。通过评估，可以识别性能瓶颈、安全漏洞或技术选型不合理等问题，帮助团队在开发前期优化设计方向，减少返工风险。

架构评估到底评什么？
核心是评估架构是否满足两类需求（着重于非功能性需求）：

• 功能性需求：系统能否正确实现业务功能（如支付流程是否完整）；
• 非功能性需求：重点关注质量属性，例如性能（响应速度）、可靠性（故障恢复能力）、扩展性（能否快速扩容）、安全性（防攻击能力）等。

架构评估怎么评估？
使用架构评估方法评估，常见的有：

• 专家评审：组织架构师、开发人员等讨论设计合理性；
• 场景分析法：模拟实际使用场景（如“万人秒杀”），验证架构能否支撑；
• 原型测试：搭建简化版系统，通过压测工具（如JMeter）检查性能瓶颈；
• 工具辅助：用代码分析工具检测耦合度，或用监控工具追踪运行时指标。

软件质量属性（重要）

质量属性分类：

1. 【开发期】质量属性

• 易理解性：指设计被开发人员理解的难易程度。
• 可扩展性：软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性。
• 可重用性：指重用软件系统或某一部分的难易程度。
• 可测试性：对软件测试以证明其满足需求规范的难易程度。
• 可维护性：修改缺陷、增加功能、提高质量属性时，识别修改点并修改的难易程度。
• 可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度

2. 【运行期】质量属性

• 性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
• 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
• 可伸缩性：用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
• 互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
• 可靠性：软件系统一定时间内持续无故障运行的能力。分为容错性和健壮性，容错性指包容错误，出错后系统继续运行；健壮性指系统在出现错误后系统不能继续运行，但能按已定义好的方式终止执行。
• 可用性：系统在一定时间内正常工作时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。
• 鲁棒性：软件系统在非正常情况（非法操作、软硬件故障等）下仍能够正常运行的能力，也称健壮性或容错性。

性能

性能指系统的响应能力，即要经过多长时间才能对某个时间做出相应，或单位时间之内能够处理事件的个数。 例如：

1. 同时支持1000并发；
2. 响应时间小于1s；
3. 显示分辨率达到4K；

性能提升方法：

1. 资源需求：提高计算效率，减少计算开销，管理事件率，控制采样频率；
2. 资源管理：引入并发，维持多个副本，增加可用资源；
3. 资源仲裁（资源调度策略）：先进先出，固定优先级，动态优先级，静态调试；

可用性

注意与可靠性区分。可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

例如：

1. 主服务器故障，1分钟内切换至备用服务器
2. 系统故障，1小时内修复；
3. 系统支持7×24小时工作。

可用性提高方法：

1. 错误检测：命令/响应，心跳检测，异常检测；
2. 错误恢复：表决器，冗余【主动、被动】，备件；
3. 错误预防：进程监视器，事务，从服务器删除；

安全性

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。 安全性又可划分为机密性【信息不泄露给未授权的用户】、完整性【防止信息被篡改】、不可否认性【不可抵赖】及可控性【对信息的传播及内容具有控制的能力】等特性。

例如：

1. 可抵御SQL注入攻击；
2. 对计算机的操作都有完整记录；
3. 用户信息数据库授权必须保证99.9%可用；

安全性提高方法：

1. 抵抗攻击：身份验证，用户授权，数据加密，数据完整性，限制暴露，限制访问；
2. 检测攻击：入侵检测；
3. 从攻击中恢复：审计追踪，冗余（与可用性重叠，优先可用性）；

可修改性

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。 通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。 可修改性包含4个方面：可维护性、可扩展性、结构重组、可移植性。

例如：

1. 更改系统报表模块，必须在2人周内完成；
2. 对Web界面风格进行修改，修改必须在4人月内完成；

可修改性提高方法：

1. 局部化修改：维持语义一致性，预期期望的变更，泛化模块，限制可能的选择，抽象通用服务；
2. 防止连锁反应：隐藏信息（代码中属性不能直接访问，只能通过接口），维持现有接口，限制通信路径，使用仲裁者；
3. 推迟绑定时间：不直接绑死，使用事件间接绑定。运行时注册，配置文件，多态，组件更换，遵守已定义的协议；

易用性与可测试性

注意与可修改性区分。

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

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

软件可测试性是指通过测试揭示软件缺陷的容易程度。 例如：提供远程调试接口，支持远程调试。

敏感点、权衡点、风险点与非风险点

• 敏感点：是对系统有所影响，是一个或多个构件（和构件之间的关系）的特性。如：对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计；
• 权衡点：是影响多个质量属性的特征，是多个质量属性的敏感点。如：更改加密的级别将对安全性和性能产生影响。
• 风险点：是指架构设计中潜在的、存在问题的架构决策所带来的隐患。如：目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性；
• 非风险点是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。如：假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的；

质量属性场景（重要）

质量属性场景是许多架构评估方法（如ATAM、SAAM等）中的核心工具或输入，用于描述系统在特定条件下如何响应刺激，以验证其非功能性需求（质量属性）。

【质量属性场景】是从风险承担者的角度与系统交互的简短描述，它通常作为描述质量属性的手段。

场景可从六个方面进行描述：刺激源、刺激、制品、环境、响应、响应度量。

质量属性场景构成：

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

可用性质量属性场景

例：系统能够连续运行的时间不小于1000小时，闪退后能够在15s之内自动重启。

• 刺激源：系统内部、系统外部；
• 刺激：疏忽、错误、崩溃、时间；
• 环境：正常操作、降级模式；
• 制品：系统处理器、通信信道、持久存储器、进程；
• 响应：系统应该检测事件、并进行如下一个或多个活动；将其记录下来通知适当的各方，包括用户和其他系统； 根据已定义的规则禁止导致错误或故障的事件源在一段预先指定的时间间隔内不可用，其中时间间隔取决于系统的关键程度在正常或降级模式下运行；
• 响应度量：系统必须可用的时间间隔可用时间系统可以在降级模式下运行的时间间隔故障修复时间；

可修改性质量属性场景

例：更改Web界面接口必须在2人周内完成。

• 刺激源：最终用户、开发人员、系统管理员；
• 刺激：希望增加、删除、修改、改变功能、质量属性、容量等；
• 环境：系统设计时、编译时、构建时、运行时；
• 制品：系统用户界面、平台、环境或与目标系统交互的系统；
• 响应：查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试部署所做的修改；
• 响应度量：根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成影响的程度；

性能质量属性场景

例：正常负载情况下，系统必须在0.5秒内对用户的交易请求进行响应。

• 刺激源：用户请求，其他系统触发等；
• 刺激：定期事件到达、随机事件到达、偶然事件到达；
• 环境：正常模式、超载（Overload）模式；
• 制品：系统；
• 响应：处理刺激、改变服务级别；
• 响应度量：等待时间、期限、吞吐量、抖动、缺失率、数据丢失率；

可测试性质量属性场景

例：测试人员在开发期间针对一个代码单元，执行一个测试序列，获取结果，并在20分钟内完成测试。

• 刺激源：开发人员、增量开发人员、系统验证人员、客户验收测试人员、系统用户；
• 刺激：已完成的分析、架构、设计、类和子系统集成；所交付的系统；
• 环境：设计时、开发时、编译时、部署时；
• 制品：设计、代码段、完整的应用；
• 响应：提供对状态值的访问，提供所计算的值，准备测试环境；
• 响应度量：已执行的可执行语句的百分比，如果存在缺陷出现故障的概率，执行测试的时间，测试中最长依赖的长度准备测试环境的时间；

易用性质量属性场景

例：新用户学习使用系统时间不超过2小时。

• 刺激源：最终用户；
• 刺激：想要学习系统特性、有效使用系统、使错误的影响最低、适配系统、对系统满意；
• 环境：系统运行时或配置时；
• 制品：系统；
• 响应：
  1. 系统提供以下一个或多个响应来支持“学习系统特性”：帮助系统与环境联系紧密界面为用户所熟悉；在不熟悉的环境中，界面是可以使用的；
  2. 系统提供以下一个或多个响应来支持“有效使用系统”：数据和（或）命令的聚合；已输入的数据和（或）命令的重用；支持在界面中的有效导航；具有一致操作的不同视图；全面搜索；多个同时进行的活动；
  3. 系统提供以下一个或多个响应来“使错误的影响最低”：撤销；取消从系统故障中恢复；识别并纠正用户错误；检索忘记的密码；验证系统资源；
  4. 系统提供以下一个或多个响应来“适配系统”：定制能力；国际化；
  5. 系统提供以下一个或多个响应来使客户“对系统的满意”：显示系统状态；与客户的节奏合拍；
• 响应度量：任务时间、错误数量、解决问题的数量、用户满意度、用户知识的获得、成功操作在总操作中所占的比例、损失的时间/丢失的数据量；

安全性质量属性场景

例：信用卡支付必须保证99.999%的安全性。

• 刺激源：正确识别、非正确识别身份未知的来自内部/外部的个人或系统；经过了授权/未授权它，访问了有限的资源/大量资源
• 刺激：试图显示数据，改变/删除数据，访问系统服务，降低系统服务的可用性
• 环境：在线或离线、联网或断网、连接有防火墙或者直接连到了网络
• 制品：系统服务、系统中的数据
• 响应：对用户身份进行认证；隐藏用户的身份；阻止对数据或服务的访问；允许访问数据或服务； 授予或收回对访问数据或服务的许可；根据身份记录访问、修改或试图访问修改数据、服务； 以一种不可读的格式存储数据；识别无法解释的对服务的高需求通知用户或另外一个系统，并限制服务的可用性；
• 响应度量：用成功的概率表示，避开安全防范措施所需要的时间、努力、资源；检测到攻击的可能性； 确定攻击或访问、修改数据或服务的个人的可能性；在拒绝服务攻击的情况下仍然获得服务的百分比； 恢复数据、服务；被破坏的数据、服务和（或）被拒绝的合法访问的范围；

基于场景的架构评估方法

• 【软件架构分析法（SAAM）】：最初关注可修改性，后扩充到可移植性、可扩充性等。最早形成文档并得到广泛使用的软件架构分析方法。
• 【架构权衡分析法（ATAM）】：由SAAM发展而来，主要针对：性能、实用性、安全性、可修改性。
• 【成本效益分析法（CBAM）】：在ATAM基础上建立的，软件的“经济”模型。（了解）

SAAM

软件架构分析方法SAAM最初用于分析架构可修改性，后扩展到其他质量属性。

核心目标： 验证架构是否满足功能需求和非功能性需求（如可维护性、可扩展性）。 评估修改系统的成本（例如添加新功能或适应环境变化）。

主要输入：问题描述、需求说明、架构描述（体系结构描述）。

评估步骤：

1. 场景开发
2. 架构描述
3. 单场景评估
4. 场景交互评估，但架构评估
5. 总体评估，比较多个架构

ATAM

ATAM是一种系统化的架构评估方法，聚焦于识别架构中的风险、敏感点和质量属性之间的权衡，尤其适合复杂系统。 架构权衡分析方法ATAM，在SAAM的基础上发展起来的，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

核心目标：

• 发现架构设计中可能无法满足质量需求的潜在风险。
• 分析不同质量属性之间的冲突（如安全性与性能的平衡）。

评估步骤：

1. 场景和需求收集：收集利益相关者的质量属性场景（如性能、可用性、安全性）。
2. 架构视图和场景实现：描述架构视图，并实现场景。
3. 属性模型构造和分析：特定属性分析（优秀的单一理论）。
4. 折中：标志敏感度，标志折中。

质量效用树

质量效用树是架构评估方法（如ATAM）中的核心工具，用于系统化识别、分解和优先级排序关键质量属性（非功能性需求）。 它通过树状结构将抽象的质量目标转化为可操作的具体场景，帮助团队聚焦核心需求并发现潜在风险。

构件

构件的定义：

1. 定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
2. 定义2：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。
3. 定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。

模块、对象、构件特性区分：

1. 模块特性：结构化开发的产物
2. 对象的特性：
   • 一个实例单元，具有唯一性的标志
   • 可能具有状态，此状态外部可见
   • 封装了自己的状态和行为
3. 构件特性：

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

构件系统架构特性：

1. 构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。
2. 构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时，也是一组固定地作用于构件层次机制的策略。
3. 概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。
4. 构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。
5. 一个原子构件是一个模块和一组资源。
6. 模块是一组类和可能的非面向对象的结构体，比如过程或者函数。
7. 资源是一个类型化的项的固定集合。
8. 资源这个概念可以包含代码资源，进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在“纯对象”的方法中，资源是外部化的不可改变的对象一一不可改变是因为构件没有持久化的标志，而且复制不能被区分。

构件的复用（重要）

可能考论文。

复用步骤：

1. 检索与提取构件
   • 基于关键字的检索：树形或有向无回路图结构
   • 刻面检索法：利用Facet描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征
   • 超文本检索法：按照人类的联想思维方式任意跳转到包含相关概念或构件的文档
2. 理解与评价构件
   • 要复用构件，准确地理解构件至关重要。特别是对构件修改使用时。
   • 为达到目的，必须要求构件的开发过程遵循公共标准。
   • 一般构件库的文档中全面而准确地说明以下内容：构件的功能与行为、相关的领域知识、可适应性约束条件与例外情形、可以预见的修改部分及修改方法。
3. 修改构件
   • 理想状态是直接复用构件库中现成的构件，但大多数情况下，必须对构件进行或多或少的修改，以应对新需求。
   • 为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。 这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。
   • 构件库中若无可修改使用的构件，则按新需求开发构件，并存入构件库。
4. 组装构件
   • 组装的三种方式
     1. 基于功能的组装：采用子程序调用和参数传递的方式将构件组装起来。
     2. 基于数据的组装：仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson系统开发方法。
     3. 面向对象的组装：如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。
   • 构件组装失配问题
     1. 由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配；
     2. 由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配；
     3. 由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。

构件的分类

从构件的外部形态来看，构件可分为5类：

1. 独立而成熟的构件。已在实际运行环境多次检验，该类构件隐藏了所有接口，用户只需用规定好的命令进行使用。例如，数据库管理系统和操作系统等。
2. 有限制的构件。有限制的构件提供了接口，指出了使用的条件和前提，这种构件在装配时，会产生资源冲突、覆盖等影响，在使用时需要加以测试。例如，各种面向对象程序设计语言中的基础类库等。
3. 适应性构件。适应性构件进行了包装或使用了接口技术，把不兼容性、资源冲突等进行了处理，可以直接使用。这种构件可以不加修改地使用在各种环境中。例如ActiveX等。
4. 装配的构件。装配（assemble）的构件在安装时，已经装配在操作系统、数据库管理系统或信息系统不同层次上，使用胶水代码（gluecode）就可以进行连接使用。目前一些软件商提供的大多数软件产品都属这一类。
5. 可修改的构件。对原构件修改错误、增加新功能，可以利用重新“包装”或写接口来实现构件的版本替换。这种构件在应用系统开发中使用得比较多。

构件标准

1. CORBA：CORBA（Common Object Request Broker Architecture，公共对象请求代理架构） 是由国际标准化组织 OMG（Object Management Group） 在1990年代提出的 分布式系统中间件标准。它的核心目标是解决异构环境（不同编程语言、操作系统、硬件平台）下的 分布式对象通信与互操作性问题，简化复杂系统的开发。
   • 伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
   • 对象适配器（ObjectAdapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
   • 对象请求代理（ObjectRequestBroker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
2. J2EE【EJB】
   • 会话Bean：实现业务逻辑，负责完成服务端与客户端的交互
   • 实体Bean：实现O/R映射，简化数据库开发工作
   • 消息驱动Bean：处理并发与异步访问
3. DNA2000

中间件

中间件是一类构件，中间件是一类系统软件。它简化结构、屏蔽差异、利于复用。

采用中间件技术的优点

1. 面向需求。即设计师集中精力于业务逻辑本身。
2. 业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式。
3. 设计与实现隔离。构件对外发生作用或构件间的交互，都是通过接口进行的，构件使用者只需要知道构件的接口，而不必关心其内部实现，这是设计与实现分离的关键。
4. 隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构件隔离，这是保证构件可复用甚至“即插即用”的基础，与中间件的意图也是一致的。
5. 符合标准的交互模型。中间件则实现了架构的模型，实现了标准的协议。
6. 软件复用。中间件提供了构件封装、交互规则、与环境的隔离等机制，这些都为软件复用提供了方便的解决方案。
7. 提供对应用构件的管理。基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。

中间件分类