【新版】系统架构设计师 - 软件架构设计＜新版＞

个人总结，仅供参考，欢迎加好友一起讨论

架构 - 软件架构设计＜新版＞

考点摘要

• 软件架构的概念（★★★）
• 基于架构的软件开发（★★★★）
• 软件架构风格（★★★★★）
• 特定领域软件架构（★★★）
• 软件质量属性（★★★★★）
• 软件架构评估（★★★★★）
• 软件产品线（★★★）
• 构件与中间件技术（★★★★）
• MDA数据驱动模型（★★★）
• 架构描述语言ADL（★★★）
• Web架构设计（★★★★）

第二版教材对应第7，8两章，是整个架构考试里最重要的章节，其内容不仅在选择题占大头，案例论文也是每年都考。本章节选择题，除了教材上有的架构基本概念、架构风格、DSSA、ABSD、质量属性和架构评估外，还涉及到了很多教材上没有的内容，如构件和连接件、中间件、构件开发等，这些内容在老版教材是有单独的章节，但是第二版教材已经都删除了，个人认为出题的概率还是很大的。

概念

• 架构设计就是需求分配，即将满足需求的职责分配到构件/组件上。
• 软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成。
• 软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构件之间的对应关系，提供了一些设计决策的基本原理。
• 解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

架构的本质

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

架构的作用

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

架构的 4 + 1 视图

Kruchten在1995年提出了一个“4+1”的视图模型。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件架构的全部内容。

• 逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统，且描述对象模型和对象之间的关系。
• 开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。
• 进程视图：也称为过程视图。侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
• 物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
• 场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。

逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。

架构描述语言ADL

ADL（Architecture Description Language）是一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体化语法和概念框架。如： Aesop、MetaH、C2、Rapide、SADL、Unicon等。

ADL三个基本元素：

• 构件：也称为组件，包括组件和组件接口。计算或数据存储单元，包括构件和相应的构件接口
• 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
• 架构配置：描述体系结构的构件和连接件的连接图

ADL是建模用的，是一些伪代码

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

基于架构的软件设计（ABSD，Architecture-Based Software Design）是一种架构驱动方法，架构驱动也就是说架构先行，需求获取和分析还没有完成就开始架构设计，需求获取和分析与架构设计并行，例如产品线系统和长期运行的系统，我们不可能开始就能决定所有的需求。

ABSD强调由业务【商业】、质量和功能需求的组合驱动架构设计，强调采用视角和视图来描述软件架构，采用用例（描述功能需求）和质量场景（描述质量需求）来描述需求。

ABSD方法有三个基础：

• 第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
• 第二个基础是通过选择架构风格来实现质量和业务需求。
• 第三个基础是软件模板的使用。

再次强调：

• 视角与视图：从不同的视角来检查，所以会有不同的视图。
• 用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求。

另外：

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

ABSD的开发模型ABSDM

传统的软件开发过程包括问题定义，需求分析，软件设计，实现，测试。

ABSD把整个软件过程分成六个部分，架构需求，设计，文档化，复审，实现，演化六个步骤。

ABSD（ABSDM模型）的开发过程

软件架构风格

• 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。
• 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

经典五大架构风格

五大架构风格常考关键字汇总

数据流风格

调用/返回风格

独立构件风格

虚拟机风格

仓库风格

闭环控制架构（过程控制）

C2架构风格

软件架构风格 - 风格判断题目

题目，给大类选大类，给小类选小类

问：Java程序可以做到“一次编写，到处运行”，从架构风格上看符合（ ）风格的特点。

答：虚拟机风格

问：在网络通信中，进行包的解析，一般先进行包头的分离，然后进行报文解析及后续处理，根据这一特点选用（ ）风格最合适。

答：解析数据，分层逐次操作，数据流风格

问：某公司欲开发一个基于图形用户界面的集成调试器。该调试器的编辑器和变量监视器可以设置调试断点。当调试器在断点处暂停运行时，编辑程序可以自动卷屏到断点，变量监视器刷新变量数值。针对这样的功能描述，采用（ ）的架构风格最为合适。

答：集成调试器，调试器中有多个部件，强调可设置断点，断点处都触发操作，独立构件风格中的事件驱动。

问：某游戏公司欲开发一个大型多人即时战略游戏，游戏设计的目标之一是能够支持玩家自行创建战役地图，定义游戏对象的行为和之间的关系。针对该目标，公司应该采用（ ）架构风格最为合适。（四选一：管道-过滤器、隐式调用、主程序-子程序、解释器）

答：支持自行创建，自定义规则，虚拟机风格的解释器

问：某公司承接了一个开发家用空调自动调温器的任务，调温器测量外部空气温度，根据设定的期望温度控制空调的开关。根据该需求，公司应采用（ ）架构风格最为合适。（四选一：解释器、过程控制、分层、管道-过滤器）

答：过程控制/闭环控制架构风格

问：某公司欲开发一个语音识别系统，语音识别的主要过程包括分割原始语音信号、识别音素、产生候选词、判定语法片断、提供语义解释等。每个过程都需要进行基于先验知识的条件判断并进行相应的识别动作。针对该系统的特点，采用（ ）架构风格最为合适。（四选一：解释器、面向对象、黑板、隐式调用）

答：语音识别，仓库风格中的黑板系统

问：某公司欲开发一个漫步者机器人，用来完成火星探测任务。机器人的控制者首先定义探测任务和任务之间的时序依赖性，机器人接受任务后，需要根据自身状态和外界环境进行动态调整，最终自动完成任务。针对这些需求，该机器人应该采用（ ）架构风格最为合适。（四选一：解释器、主程序-子程序、隐式调用、管道-过滤器）

答：有自定义的情况，虚拟机风格的解释器。另外其中隐式调用其实就是事件驱动，对应的显示调用（调用/返回风格）

问：某公司拟开发一个扫地机器人。机器人的控制者首先定义清洁流程和流程中任务之间的关系，机器人接受任务后，需要响应外界环境中触发的一些突发事件，根据自身状态进行动态调整，最终自动完成任务。针对上述需求，该机器人应该采用（ ）架构风格最为合适。（四选一：面向对象、主程序-子程序、规则系统、管道-过滤器）

答：有自定义的情况，虚拟机风格的解释器。如果没有解释器风格，就选择大类虚拟机风格，或者是虚拟机风格下的规则系统

问：Windows操作系统在图形用户界面处理方面采用的核心架构风格是（ ）风格。

答：图形用户界面，独立构件风格中的事件驱动

例题：

解析：

第一空，字眼“程序源代码作为整体，依次在不同模块中进行传递”，符合“顺序批处理”的特点。

第二空，字眼“支持代码的增量修改与处理”，又有“IDE”集成开发环境，符合仓库风格，仓库风格是以数据为中心的，所以这里选择“数据共享”。

第三空，字眼“触发”，符合独立构件风格中的事件驱动，也就是“隐式调用”。

第四空，设计模式的考察，设计模式和架构设计是相辅相成的，字眼“适应性改造”，选择“适配”。

第五空，字眼“模拟新操作系统”，符合“虚拟机”特点。

层次架构风格

二层C/S架构

客户机/服务器（Client/Server，C/S）架构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S架构定义了工作站（客户应用程序）如何与服务器相连，以实现数据和应用分布到多台计算机上。服务器负责有效地管理系统的资源，其主要任务集中于对DBMS的管理和控制，以及数据的备份与恢复；客户应用程序的主要任务是提供用户与数据库交互的界面，向服务器提交用户请求并接收来自服务器的信息，对存在于客户端的数据执行应用逻辑要求。这是一种“胖客户机（fat client）、瘦服务器（thin server）”的架构，其处理流程如下图：

其主要特点：

• 开发成本较高
• 客户端程序设计复杂
• 信息内容和形式单一
• 用户界面风格不一
• 软件移植困难
• 软件维护和升级困难
• 新技术不能轻易应用

其缺点：

• 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏。
• 数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。

三层C/S架构

与二层C/S架构相比，在三层C/S架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种客户机称为瘦客户机（thin client）。三层C/S架构将应用系统分成表示层、功能层和数据层三个部分，如下图：

• 表示层

  表示层是系统的用户接口部分，担负着用户与系统之间的对话功能。它用于检查用户从键盘等输入的数据，显示输出的数据。

• 功能层

  功能层也称为业务逻辑层，是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额、按照预定的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。

• 数据层

  数据层相当于二层C/S架构中的服务器，负责对DBMS的管理和控制。

与传统的二层架构相比，三层C/S架构具有以下优点：

• 允许合理地划分三层的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
• 允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
• 系统的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行且高效地进行开发，达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。
• 利用功能层可以有效地隔离表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础。

B/S架构

在B/S架构中，除了数据库服务器外，应用程序以网页形式存放于Web服务器上，用户运行某个应用程序时，只须在客户端的浏览器中键入相应的网址，调用Web服务器上的应用程序，并对数据库进行操作，完成相应的数据处理工作，最后将结果通过浏览器显示给用户。基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。

另外，B/S架构也有一些缺点存在：

• B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能
• B/S架构的安全性难以控制
• 采用B/S架构的应用系统，在数据查询等响应速度上，要远远低于C/S架构
• B/S架构的数据提交一般以页面为单位，数据的动态交互性不强,不利于OLTP应用

混合架构风格

实现困难，成本较高。

其它架构风格

富互联网RIA架构

为了弥补B/S架构存在的一些不足，提高用户体验，富互联网应用（Rich Internet Application，RIA）技术应运而生。

富互联网架构的特点：

• RIA结合了C/S架构反应速度快、交互性强的优点，以及B/S架构传播范围广及容易传播的特性
• RIA简化并改进了B/S架构的用户交互
• 数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面
• 本质上还是零客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，如小程序等

MVC架构风格

MVC架构，既是架构模式也是设计模式。

MVC分为主动和被动两种MVC模型。主动MVC有对模型的观察机制，会把数据主动返回到View。主动MVC能推送数据给视图，但被动模型是没有的。主动MVC就是引入了观察者模式来实现了向视图的推送信息。如下：

• Model(模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
• View(视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
• Controller(控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

MVP架构风格

MVP的所有的操作都要经过Presenter。MVC中的C主要做事件的分发，并不做事件业务的处理。而P层可以处理业务逻辑。MVP比MVC更加容易进行工程化测试。

MVC和MVP的一个最大的区别就是View和Model是否有交互。所以MVP在耦合程度上是更加有优势的。

MVP是MVC的变种，模型与视图完全分离，可以修改视图而不影响模型。

MVP实现了V与M之间的解耦，（V不直接使用M，修改V不会影响M）。

MVP更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑，可以将一个P用于多个V，而不需要改变P的逻辑）。

MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理。

MVVM架构风格

模型驱动MDA

概念

MDA是Model Driven Architecture 的缩写，也叫模型驱动架构。起源于分离系统规约和平台实现的思想，MDA的主要目标是：Portability（可移植性），Interoperability（互通性），Reusability（可重用性）。

其中，M为Model，客观事物的抽象表示；Model-Driven，使用模型完成软件的分析、设计、构建、部署、维护等各开发活动；A是Architecture ，构成系统的部件、连接件及其约束的规约。

三种核心模型

MDA的3种核心模型：

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

MDA是模型驱动架构，由OMG定义的一个软件开发框架，基于UML及其他工业标准。MDA把建模语言用作一种编程语言而不仅仅是设计语言，模型在软件开发中扮演了非常重要的角色。

示例

解：（1）平台无关模型（PIM）（2）UML建模（3）模型变换（映射）（4）模型生成源码

特定领域软件架构DSSA

DSSA（Domain Specific Software Architecture）特定领域软件架构，可以看做开发产品线的一个方法或理论，目标就是支持一个特定领域中多应用的生成。

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

基本活动

1. 建立领域模型，一个严格定义的问题域或解决域。其中，垂直域是在相同领域中深入；水平域是在不同领域中平移。
2. 具有普遍性，使其可以用于领域中某个特定应用的开发。
3. 对整个领域的合适程序的抽象。
4. 具备该领域固定的、典型的在开发过程中的。可复用元素。

领域分析机制

建立过程

三层次模型

软件架构评估

架构评估的基准是架构质量属性

软件架构质量属性

性能

性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

例如：

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

可用性

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

例如：

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

安全性

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

例如：

• 可抵御SQL注入攻击
• 对计算机的操作都有完整记录（日志，审计追踪）
• 用户信息数据库授权必须保证99.9%可用

可修改性

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

例如：

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

易用性

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

例如：

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

可测试性

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

例如：

• 提供远程调试接口，支持远程调试

敏感点与权衡点

敏感点是一个或多个构件（和/或构件之间的关系）的特性。

权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

非风险点是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。

例如：

• 对交易请求处理时间的要求将影响系统的数据传输协议和处理过程的设计（敏感点）
• 假设每秒中用户交易请求的数量是10个，处理请求的时间为30毫秒，则“在1秒内完成用户的交易请求”这一要求是可以实现的（非风险点）
• 目前对系统信用卡支付业务逻辑的描述尚未达成共识，这可能导致部分业务功能模块的重复，影响系统的可修改性（风险点）
• 更改加密的级别将对安全性和性能产生影响（权衡点）

评估方法

软件架构评估有三种方式：基于调查问卷（检查表），基于度量，基于场景。

基于调查问卷（检查表）：是指组织相关人员进行评估，这种方式最简单易行，但是主观性强。

基于度量：强调量化指标，最客观，但是这种方式实施难度大，因为需要评估者对系统非常熟悉，不然很难量化清楚各项指标。

基于场景：筛选出系统的关键场景，根据系统在不同场景中的表现进行评估，这种方式客观程度介于2者之间，这也是目前较为流行的结构评估方法。

基于场景的架构评估方法

场景是从风险承担者的角度与系统交互的简短描述。

质量场景的6个组成部分：

• 刺激源，谁造成的刺激
• 刺激，一个响应系统的情况
• 制品，系统被刺激的部分
• 环境，刺激发生时，系统所处的状态
• 响应，刺激所产生的结果
• 响应度量指标，如何评估响应

基于场景的方法主要有三种（前2种方式用得比较多）：

• 软件架构分析法（SAAM，Software Architecture Analysis Method）
• 架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）
• 成本效益分析法（CBAM，Cost Benefit Analysis Method）

软件架构分析法SAAM

SAAM，最初用于分析架构可修改性，后扩展到其它质量属性（例如：可移植性、可扩充性）。

SAAM的主要输入是问题描述、需求说明和架构描述，其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。

软件架构分析法分为6个步骤：

1. 形成场景
2. 描述架构
3. 对场景进行分类和确定优先级
4. 对场景进行单个评估
5. 评估场景的相互作用
6. 形成总体评价

架构权衡分析法ATAM

架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method）是在SAAM上发展而来。核心是结合质量属性效用树对系统进行评价，确定风险点、敏感点、权衡点，并对系统架构做出决策和折中。整个评估过程强调以质量属性作为评估核心，主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

ATAM分成4个阶段，如下图：

1. 场景和需求收集
2. 架构视图和场景实现
3. 质量模型构造和分析
4. 质量模型折中

评估参与者

• 评估小组：组织内部或外部的、扮演特定的角色
• 项目决策者：项目管理人员、重要客户代表、架构师
• 项目干系人：模块开发人员、测试人员、用户

评估步骤

1. 描述ATAM方法：评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。
2. 描述业务动机/商业目标：项目决策者从业务的角度介绍系统的概况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要的项目干系人，以及架构的驱动因素等。
3. 描述架构/体系结构：包括技术约束（例如：操作系统、硬件和中间件等）、将与本系统进行交互的其他系统、用以满足质量属性要求的架构方法等。
4. 确定架构方法/标识体系结构：通过理解架构方法来分析架构，在这一步，由架构设计师确定架构方法。
5. 生成质量属性效用树：评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。
6. 分析架构方法/分析体系结构：这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
7. 讨论场景和对场景分级/评论质量需求的次序：项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，使用系统执行的一些功能。一旦收集了若干个场景后，必须设置优先级。评估人员通过投票表决的方式来完成。
8. 分析架构方法/分析体系结构：在收集并分析了场景之后，设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。在这一步中，评估小组要重复第6步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则在第8步就是测试步骤。
9. 描述评估结果：最后，要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人。ATAM的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。

图例参考：

质量属性效用树

质量属性效用树：识别质量属性并排序，主要包含性能、可用性、可修改性、安全性四个方面。

性能：性能延时（将用户数据库存储延迟到了最小值300ms，提供了实时的视频图像），交易吞吐量（使认证服务器的平均吞吐量最大化）。

可修改性：新增产品目录，商业产品修改（已小于20人月的工作量添加CORBA中间件，以小于4人周的工作量更改web界面）。

可用性：硬件故障（若站点A断电，要求在3秒内将任务重定向到站点B，若磁盘出现故障，要求在5分钟内重新启动，要在1-5分钟之内检测并恢复网络故障），商业软件故障。

安全性：数据机密性（信用卡交易在99.999%的时间内是安全的，客户数据库z认证在99.999%的时间内能正常工作），数据完整性。

质量属性效用树示例图如下：

成本效益分析法CBAM

CBAM用来对架构设计决策的成本和收益进行建模，它的基本思想是架构策略影响系统的质量属性，反过来这些质量属性又会为系统的项目干系人带来一些收益（称为“效用”），CBAM协助项目干系人根据其投资收益率选择架构策略。CBAM可以看作是ATAM的补充，在ATAM评估结果的基础上对架构的经济性进行评估。

其它评估方法

SAEM方法，SAABNet方法、SACMM方法、SASAM方法、ALRRA方法、AHP方法、COSMIC+UML方法等。

软件产品线

软件产品线主要由两部分组成，分别是核心资源和产品集合。核心资源是领域工程的所有结果的集合，是产品线中产品构造的基础。

软件产品线开发有4个基本技术特点，即过程驱动、特定领域、技术支持和架构为中心。与其它软件开发方法相比，组织选择软件产品线的宏观上的原因有：对产品线及其实现所需的专家知识领域的清楚界定；对产品线的长期远景进行了战略性规划。

组织选择软件产品线的原因：

1. 对产品线及其实现所需要的知识领域的清楚界定。
2. 对产品线的长期远景进行了战略性规划。

过程模型 - 双生命周期模型

双生命周期模型分成两个重叠的生命周期：领域工程和应用工程。

领域工程使用DSSA，主要任务有领域分析，领域设计，领域实现。

领域工程主要任务：

• 领域分析，利用现有系统的设计、架构和需求建立领域模型。
• 领域设计，用领域模型确定领域/产品线的共性和可变性，为产品线设计架构。
• 领域实现，基于领域架构开发领域可重用资源（构件、文档、代码生成器）。

应用工程领域：需求分析，系统设计，系统实现。

应用工程在领域工程结果基础上构造新产品：

• 需求分析，划分领域公共需求和独特需求，得出系统说明书。
• 系统设计，在领域架构基础上，结合系统独特需求设计应用的软件架构。
• 系统实现，按应用架构，用领域可重用资源实现领域公共需求，用定制开发的构件满足系统独特需求，构件新的系统。

过程模型 - 三生命周期模型

三生命周期模型为有多个产品线的大型企业增加企业工程流程，以便在企业范围内对所有资源的创建、设计和重用提供合理规划。

过程模型 - SEI模型

SEI模型基本活动分为三部分，分别是核心资源开发（即领域工程）、产品开发（即应用工程）和管理。

SEI模型的主要特点：

• 循环重复是产品开发过程的特征，也是核心资源开发、产品线开发以及核心资源和产品之间协作的特征。
• 核心资源开发和产品开发没有先后之分。
• 管理活动协调整个产品线开发过程的各个活动、对产品线的成败负责。
• 核心资源开发和产品开发是两个互动的过程，三个活动和整个产品线开发之间也是双向互动的。

核心资源开发活动的目标是建立产品线的生产能力。根据输入端的产品约束、框架、生产约束、生产策略和遗留资产清单，核心资产开发活动产出三项输出：

• 产品线范围。产品线范围是关于构成产品线的产品或产品线所能包括的产品的描述，该描述列举了所有产品的共性和他们之间彼此的差异，包括产品所提供的特征或操作、产品所表现出的性能和其他产品属性等。
• 核心资产：是产品线中产品生产的基础。这些资产包括产品共享的架构，以及为贯穿产品线进行系统化重用所开发的产品组件。提供了将纳入资产库的组件接口规范。
• 生产计划：描述了如何从核心资产中生产产品。

建立方式

划分依据：用演化方式和革命方式引入产品线开发过程，基于现有产品还是开发全新的产品线。

四种方式的基本特征如下：

• 将现有产品演化为产品线
• 用软件产品线替代现有产品集
• 全新软件产品线的演化
• 全新软件产品线的开发

组织结构

软件产品线开发过程分为领域工程和应用工程，相应的软件开发组织结构也应该有两个基本组成部分，即负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。

组织模型：开发部门、商务部门、领域工程部门和层次领域工程部门。

动态的组织结构，根据产品线的建立方式和发展阶段、成熟程度的变化，有一种组织结构向另一种组织结构演变。

组织结构类型：

• 设立独立的核心资源小组
• 不设立独立的核心资源小组
• 动态的组织结构

要成功实施产品线，主要取决于以下因素：

• 对该领域具备长期和深厚的经验
• 一个用于构建产品的好的核心资源库
• 好的产品线架构
• 好的管理（软件资源、人员组织、过程）支持

构件

定义

定义1：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。

定义2：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。

定义3：构件是一个独立发布的功能部分，可以通过其接口访问它的服务。

构件系统架构特性：

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

构件的复用

软件复用（软件重用）是使用已有的软件产品（如设计、代码和文档等）来开发新的软件系统的过程。

复用的发展过程：

复用的维度：

• 水平复用，复用不同应用领域中的软件元素，如标准函数库
• 垂直复用，是在一类具有较多公共性的应用领域之间重用软件构件

构件的组装

第一步，检索与提取构件

1. 基于关键字的检索，特点：树形或有向无回路图结构。

2. 刻面检索法，特点：利用Facet描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征。

   例如，分多个刻面：1 应用领域、2 使用环境、3 功能

3. 超文本检索法，特点：按照人类的联想思维方式任意跳转到包含相关概念或构件的文档。

第二步，理解与评价构件

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

第三步，修改构件

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

第四步，组装构件

组装的三种方式：

1. 基于功能的组装，采用子程序调用和参数传递的方式将构件组装起来。
2. 基于数据的组装，仍然是传统的子程序调用与参数传递。但它所依赖的软件设计方法不再是功能分解,而是面向数据的设计方法，例如，Jackson系统开发方法。
3. 面向对象的组装，如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则,必须以基类为父类,生成相应的子类，以满足新系统的需求。

构件组装失配问题：

1. 由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。
2. 由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。
3. 由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。

构件的标准

构件标准规范包括OMG的CORBA、Sun的EJB/J2EE和微软的COM/DCOM/COM+。

COBRA

CORBA体系的主要内容包括以下几部分：

1. 对象请求代理(Object Request Broker，ORB)。负责对象在分布环境中透明地收发请求和响应，它是构建分布对象应用、在异构或同构环境下实现应用间互操作的基础。
2. 对象服务(Object Services)。为使用和实现对象而提供的基本对象集合，这些服务应独立于应用领域。
3. 公共设施(Common Facilitites)。向终端用户提供一组共享服务接口，例如系统管理、组合文档和电子邮件等。
4. 应用接口 (Application Interfaces)。由销售商提供的可控制其接口的产品，相应于传统的应用层表示,处于参考模型的最高层。
5. 领域接口(Domain Interfaces)。为应用领域服务而提供的接口，如OMG组织为PDM系统制定的规范。

四种构件：

1. 实体（Entity） 构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
2. 加工（Process） 构件同样需要容器管理其持久化，但没有客户端可访问的主键。
3. 会话（Session） 构件不需要容器管理其持久化，其状态信息必须由构件自己管理。负责完成服务端和客户端的交互。
4. 服务（Service） 构件是无状态的。

构件模型：

1. 伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
2. 对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
3. 对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

EJB/J2EE

EJB是Sun的JavaEE服务器端组件模型，设计目标与核心应用是部署分布式应用程序。EJB (Enterprise JavaBean)是J2EE(javaEE)的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。EJB 构件用于封装业务逻辑，使开发人员无须再担心数据访问、事务处理支持、安全性、高速缓存和迸发等琐碎任务的编程。

支持的5种构件模型：Applet、Servlet、JSP、EJB、Application Client。

其中，EJB中的BEAN分三种：

1. 会话bean，实现业务逻辑，负责完成服务端与客户端的交互，负责维护一个短暂的会话。
2. 实体bean，实现O/M映射，简化数据库开发工作，负责维护一行稳固持久的数据。
3. 消息驱动，处理并发与异常访问，异步接受消息。

COM/DCOM/COM+

COM+ ⊇ DCOM ⊇ COM

参考https://blog.csdn.net/lili40342/article/details/128586533

中间件

中间件是一类构件，中间件是一类系统软件。

中间件，简化结构、屏蔽差异、利于复用。

采用中间件技术的优点：

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

中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于操作系统之上，管理计算资源和网络通信，实现应用之间的互操作。

6个基本功能

1. 负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
2. 提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
3. 提供一个多层架构的应用开发和运行的平台，以及一个应用开发框架，支持模块化的应用开发。
4. 屏蔽硬件、操作系统、网络和数据库的差异。
5. 提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。
6. 提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。

类型和分类

1. 通信处理（消息）中间件。在分布式系统中，人们要建网和制定出通信协议，以保证系统能在不同平台之间通信，实现分布式系统中可靠的、高效的、实时的跨平台数据传输，这类中间件称为消息中间件，也是市面上销售额最大的中间件产品。目前主要产品有BEA的eLink、IBM的MQSeries、TongLINK等。实际上，一般的网络操作系统如Windows已包含了其部分功能。
2. 事务处理（交易）中间件。在分布式事务处理系统中，经常要处理大量事务，特别是OLTP中，每项事务常常要多台服务器上的程序按顺序协调完成，一旦中间发生某种故障，不但要完成恢复工作，而且要自动切换系统，达到系统永不停机，实现高可靠性运行。要使大量事务在多台应用服务器上能实时并发运行，并进行负载平衡的调度，实现与昂贵的可靠性机和大型计算机系统同等的功能，为了实现这个目标，要求中间件系统具有监视和调度整个系统的功能。BEA的Tuxedo由此而著名，它成为增长率最高的厂商。
3. 数据存取管理中间件。在分布式系统中，重要的数据都集中存放在数据服务器中，它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型，或者是经过加密或压缩存放的，该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。
4. Web服务器中间件。浏览器图形用户界面已成为公认规范，然而它的会话能力差、不擅长做数据写入、受HTTP协议的限制等，就必须进行修改和扩充，形成了Web服务器中间件，如SilverStream公司的产品。
5. 安全中间件。一些军事、政府和商务部门上网的最大障碍是安全保密问题，而且不能使用国外提供的安全措施（如防火墙、加密、认证等），必须用国产产品。产生不安全因素是由操作系统引起的，但必须要用中间件去解决，以适应灵活多变的要求。
6. 跨平台和架构的中间件。当前开发大型应用软件通常采用基于架构和构件技术，在分布式系统中，还需要集成各节点上的不同系统平台上的构件或新老版本的构件，由此产生了架构中间件。功能最强的是CORBA，可以跨任意平台，但是过于庞大；JavaBeans较灵活简单，很适合于做浏览器，但运行效率有待改善；COM+模型主要适合Windows平台，在桌面系统已广泛使用。由于国内新建系统多基于UNIX（包括Linux）和Windows，因此，针对这两个平台建立相应的中间件市场相对要大得多。
7. 专用平台中间件。为特定应用领域设计领域参考模式，建立相应架构，配置相应的构件库和中间件，为应用服务器开发和运行特定领域的关键任务（如电子商务、网站等）。
8. 网络中间件。它包括网管、接入、网络测试、虚拟社区、虚拟缓冲等。

应用服务器

目前，应用服务器已经成为电子商务应用中一种非常关键的中间件技术。通过它能将一个企业的商务活动安全有效地实施到Internet上，实现电子商务。它并非一种传统意义上的软件，而是一个可以提供通过Internet来实施电子商务的平台。在分布式、多层结构及基于构件和服务器端程序设计的企业级应用开发中，它提供的是一个开发、部署、运行和管理、维护的平台。它可以提供软件“集群” 的功能，因而可以让多个不同的、异构服务器协同工作、相互备份，以满足企业级应用所需要的可用性、高性能、可靠性和可伸缩性等。

故而，从某种意义上说，应用服务器提供了一个“企业级应用的操作系统”。实现 J2EE规范的应用服务器称为 J2EE 应用服务器。文章来源地址https://www.toymoban.com/news/detail-706845.html

到了这里，关于【新版】系统架构设计师 - 软件架构设计＜新版＞的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！