第十一章 软件架构设计

非常重要！选择会考20-24分！！案例必考第一题！！

• 选择主要考：架构风格、架构设计过程、质量属性
• 案例主要考：质量属性、架构评估、架构风格

1.软件架构的概念

1.1.架构设计概述

        从‘需求分析’到‘软件设计’之间的过渡称之为软件架构。

        SA----软件架构设计

1.2.软件架构设计与生命周期（过程）

2.构件

2.1.构件的概念

• 构件是一个独立可交付的功能单元，外界通过接口访问其提供的服务
• 构件通常由需要同时部署的原子构件组成
• 一个原子构件是一个模块和一组资源
• 原子构件是部署、版本控制和替换的基本单位
• 原子构件通常被成组部署，但是也可以单独部署
• 原子构件与构件的区别
  • 大多数原子构件永远不会被单独部署
  • 大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族
• 一个模块是不带单独资源的原子构件

2.2.构件和对象的特征

2.3.面向构件的编程（COP）

COP需要支持以下基本支持：

1. 多态性（可替代性）
2. 模块封装性（高层次信息的隐藏）
3. 后期的绑定和装载（部署独立性）
4. 安全性（类型和模块的安全性）

2.4.构件技术

3.软件架构风格

        软件体系架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组丝束指出系统是如何将这些构件和连接件组合起来的。

        架构风格反映了领域中众多系统所共有的结和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的矿究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。架设计的一个核心问题是能否达到架构级的软件复用。架构风格定义了用于描述系统的术语表和一指导构建系统的规则。

3.1.基本架构风格

3.2.层次结构风格

3.2.1.两层C/S

客户端和服务器都有处理功能，因为不太好，所以现在一般不用了。

3.2.2.三层C/S

在两层C/S的基础上，把服务器分为了应用服务器和数据库服务器。

优点：

1. 各层在逻辑上保持相对独立
2. 允许灵活有效的选用相应平台和硬件系统
3. 各层可以并行开发

3.3.3.三层B/S

将客户端变成客户端的浏览器，将应用服务器变成网络上的Web服务器，又称之为0客户端架构。

缺点：

1. 缺乏对动态页面的支持能力
2. 安全性难以控制
3. 在数据查询等响应速度上，要远远低于C/S架构
4. 数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP

3.3.4.混合架构风格

内外有别模型：企业内部人员使用C/S;企业外部人员使用B/S

查改有别模型：采用B/S查询；C/S修改

3.3.富互联网应用（小程序-RIA）

• RIA结合了C/S和B/S的优点
• RIA简化并改进了B/S加油的用户交互
• 数据可以被缓存在客户端
• 本质上还是0客户端

4.面向服务的架构（SOA）

SOA是一种粗粒度、松耦合、标准化接口的服务架构。在SOA中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。

4.1.实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征：

1. 可以从企业外部访问
2. 随时可用（服务请求能被及时响应）
3. 粗粒度接口
4. 服务分级
5. 松散耦合
6. 可重用的服务以及服务接口设计管理
7. 标准化接口
8. 支持各种消息模式
9. 精准定义的接口服务

4.2.基于服务的构件和传统构件的区别有四：

1. 服务构件粒度粗，传统构件粒度细
2. 服务构件的接口是标准的，主要是WSDL接口，传统构件主要以API形式出现
3. 服务构件的实现与语言是无关的，而传统构件常常绑定某种特定语言
4. 服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制

4.3.SOA关键功能和协议

1. UDDI（统一描述、发现和集成）：用于Web注册和服务查找。
2. DISCO：发现公开服务的功能和交互协议

3. WSDL（Web服务描述语言）：用于传递信息

4. SOAP：建立Web服务和服务请求之间的通信提供支持

5. REST：一种只是使用HTTP和XML进行基于Web的通信技术

4.4.SOA的实现方式

Web Service = 服务注册中心+服务请求者+服务提供者

PS：这里爱考ESB

1. 服务注册表(Service registry)提供一个策略执行点，在这个点上，服务可以在SOA中注册，从而可以被发现和使用。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。
2. ESB（传统中间件技术与XML、Web服务等技术结合的产物）将企业中各个不同的服务连接在一起。因为各个服务是异构的，没有统一的标准，各个异构系统对外提供的接口是各式各样的，SOA使用ESB来屏蔽异构系统对外提供的不同接口，以此来达到服务间高效的互联互通。
   1. 起到总线作用
   2. 描述服务的元数据和服务注册管理
   3. 在服务请求者和提供者之间传递数据，以及对这些数据进行转化的能力
   4. 用于路由、匹配、发现和选择的能力

4.5.微服务和SOA

了解以下就行啦~

5.特定领域软件架构（DSSA）

DSSA是专用于一类特定类型的任务的软件构件集合。DSSA的目的是支持在一个特定领域中的多个应用生成。

• 垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构
• 水平域：在多个领域之间相同的部分小工具

5.1.DSSA的三个基本活动

（1）领域分析：主要目标是获得领域模型。即通过分析领域中系统的需求（领域需求），确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。
（2）领域设计：这个阶段的目标是获得DSSA，它是一个能够适应领域多个系统的需求的一个高层次的设计。由于领域模型中的领域需求具有一定的变化性，DSSA 也要相应地具有变化性，它可以通过表示多选一的、可选的解决方案等来做到这一点。
（3）领域实现：主要目标是依据领域模型和DSSA 开发与组织可复用信息。这些复用信息可以是从现有系统中提取得到的，也可能通过新的开发得到。这个阶段可以看作复用基础设施的实现阶段。

5.2.参与DSSA的四种角色

这些角色不是懂技术就是懂业务的

参与DSSA的人员可以划分为4种角色：领域专家、领域分析师、领域设计人员和领域实现人员

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

5.3.建立DSSA的过程

1. 定义领域范围

2. 定义领域特定的元素                                 //领域分析

3. 定义领域特定的设计和实现需求约束

4. 定义领域模型和体系结构                          //领域设计

5. 产生，搜集可重用的产品单元                   //领域实现

DSSA的建立过程是并发的、递归的、反复和螺旋进行的

5.4.三层次模型

6.基于架构的软件开发方法

        ABSD是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例图和质量属性场景来描述需求，用例图描述功能需求；质量属性场景描述的质量需求（侧重于非功能需求）

ABSD方法有3个基础：

• 第1个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；
• 第2个基础是通过选择架构风格来实现质量和商业需求。
• 第3个基础是软件模板的使用，软件模板利用了一些软件系统的结构。

ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。--->结构化

ABSD开发过程：

1. 架构需求阶段：重在掌握标识构件的三步：生成类图、对类进行分组、把类打包成构件。
2. 架构设计阶段：将标识构件映射成为构件进行分析。
3. 架构文档化阶段：将设计结果文档化，便于开发人员理解和实现。主要输出包括架构规格说明文档和测试架构需求的质量设计说明书。
4. 架构复审阶段：请外部人员对设计结果进行复审，确保设计满足需求和质量标准。
5. 架构实现阶段：根据设计文档，实现软件系统。主要活动包括构件分析和设计、构件实现、构件组装、系统测试等。
6. 架构演化阶段：根据用户反馈和系统运行情况，对系统进行持续改进和优化。主要活动包括错误修正、功能迭代和性能优化等。

7.架构评估

7.1.质量属性

7.2.质量属性场景

1）刺激源（Source）：这是某个生成该刺激的实体（人、计算机系统或者任何其他刺激源）。

2）刺激（Stimulus）：该刺激是当刺激到达系统时需要考虑的条件。（希望增加、删除、修改、改变功能等）

3）环境（Environment）：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。（系统运行时、编译时、构建时、运行时）

4）制品（Artifact）：某个制品被激励。这可能是整个系统，也可能是系统的一部分。（系统，或者部分系统）

5）响应（Response）：该响应是在激励到达后所采取的行动。

6）响应度量（Measurement）：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。

7.3.架构评估方式

• 敏感点：影响了一个质量属性
• 权衡点：影响了多个质量属性
• 风险点：可能引起风险
• 非风险点：某件事是可行、可接受的

7.4.常用的评估方法

其中，基于场景的方式是主流，其有三种评估方法：

1. 软件架构分析方法SAAM
2. 架构权衡评估方法ATAM
   1. 四大部分，九个步骤

1. 成本效益分析方法CBAM

参考的博客：
SOA架构概述-CSDN博客

面向服务的架构（SOA）_soa架构-CSDN博客

什么是DSSA?以及DSSA主要包括哪些阶段？-CSDN博客

【软考系统架构设计师】DSSA特定领域软件架构-CSDN博客

论基于架构的软件设计方法及应用（ABSD）-CSDN博客