软件架构设计

1 软件架构概述

1.1 软件架构的定义

架构是对系统的抽象，由多个架构组成，任何软件都存在架构，元素与其行为的集合构成架构内容，架构具有“基础性”，架构隐含有“决策”。

1.2 软件架构重要性

项目关系人之间交流平台；
早期设计决策；
在较高层面上实现软件复用；
架构对开发的指导与规范意义不容忽略。

1.3 架构的模型

结构模型；框架模型；动态模型；过程模型；功能模型；
逻辑视图，开发视图，进程视图，物理视图，场景。

2 架构需求与软件质量属性

2.1 软件质量属性

功能性；可靠性；易用性；效率；可维护性；可移植性；

• 1 运行期质量属性
  性能；安全性；易用性；可伸缩性；互操作性；可靠性；持续可用性；鲁棒性；

• 2 开发期质量属性
  易理解性；可扩展性；可重用性；可测试性；可维护性；

2.2 六个质量属性与实现

质量属性：可用性；可修改性；性能；安全性；可测试性；易用性；

质量属性场景组件：刺激源；刺激；环境；制品；响应；响应度量；

• 1 可用性与其实现战术
  可用性描述
  可用性战术
  错误检测：命令/响应；心跳；异常；
  错误恢复
  表决；主动冗余；被动冗余；备件；状态再同步；检查点/回滚；
  错误预防
  从服务中删除；事务；进程监视器；
• 2 可修改性与其实现战术
  可修改性描述
  可修改性战术
  局部化修改；(维持语义的一致性；预期期望的变更；泛化该模块；限制可能的选择)
  防止连锁反应；（信息隐藏；维持现有的接口；限制通信路径；仲裁者的使用）
  推迟绑定时间；（运行时注册；配置文件；多态；构件更换；）
• 3 性能与其实现技术
  性能描述
  性能战术
  资源消耗：闭锁时间；
  资源需求：减少处理事件流所需的资源；减少所处理事件的数量；控制资源的使用；
  资源管理：引入并发；维持数据或计算的多个副本；增加可用资源；
  资源仲裁：先进先出；固定优先级调度；动态优先级调度；静态调度；
• 4 安全性与其实现技术
  安全性描述
  安全性战术
  抵抗攻击：对用户进行身份验证；对用户进行授权；维护数据的机密性；维护完整性；限制暴露的信息；限制访问；
  检测攻击
  从攻击中恢复：恢复；识别攻击者；
• 5 可测试性与其实现战术
  可测试性描述
  可测试性战术
  输入/输出：记录回放；将接口与现实分离；优化访问线路
  内部监控
• 6 易用性与实现战术
  易用性描述
  易用性战术
  运行时战术：任务的模型；用户的模型；系统的模型；
  设计时战术
  支持用户主动操作

常见的六个质量属性:可用性、可修改性、性能、安全性、可测试性、易用性。

质量属性场景是一种面向特定的质量属性的需求，由6部分组成：刺激源、刺激、环境、制品、响应、响应度量。

以《淘宝网》为例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

　　　(1)可用性:
　　　　场景：天猫双十一购物狂欢节
　　　　刺激源：海量用户
　　　　刺激：过多用户涌入抢购，系统出现崩溃的状态
　　　　制品：处理系统崩溃的处理器
　　　　环境：正常操作
　　　　响应：淘宝网监控系统记录，处理人员进行紧急处理
　　　　响应度量：短时间内恢复系统正常运行
　　（2）可修改性：
　　 　　场景：系统进行升级
　　　 　刺激源：开发人员
　　　　 刺激：改变页面的形态，增加少许功能、
　　　　 制品：升级完后的系统
　　　　 环境：设计时
　　　　 响应：修改了用户的操作页面，未产生副作用
　　　　响应度量：在15分钟左右完成升级更改
　　（3）性能：
　　　　场景：天猫双十一购物狂欢节
　　　　刺激源：用户
　　　　刺激：进行疯狂购物交易
　　　　制品：系统
　　　　环境：在正常操作下
　　　　响应：大量的交易同时被处理
　　　　响应度量：每个交易平均等待时间为3s
　　　(4)安全性:
　　　　场景：黑客想要盗窃用户信息
　　　　刺激源：黑客
　　　　刺激：试图通过某些手段窃取用户的信息
　　　　制品：淘宝用户信息
　　　　环境：用户不在线时
　　　　响应：对访问者进行身份上的验证
　　　　响应度量：淘宝安全系统阻止黑客访问用户信息
　　　（5）可测试性：
　　　　场景：一个马上要执行的系统功能
　　　　刺激源：系统测试人员
　　　　刺激：对系统功能执行测试
　　　　制品：系统的某个功能
　　　　环境：功能要部署时
　　　　响应：提供对状态值的访问、提供所要计算的值，准备测试环境
　　　　响应度量：3个小时测试了85%
　　（6）易用性：
　　　　场景：用户误将某物品移入到购物车
　　　　刺激源：用户
　　　　刺激：用户想要将物品移出
　　　　制品：系统
　　　　环境；系统运行时
　　　　响应：希望快速完成操作
　　　　响应度量：在1s内完成撤销操作

3 软件架构风格

3.1 软件架构风格分类

数据流风格：批处理序列；管道\过滤器；
调用/返回风格：主程序、子程序；面型对象风格；层次结构；
独立构件风格：进程通信；事件系统；
虚拟机风格：解释器；基于规则的系统；
仓库风格：数据库系统；超文本系统；黑板系统；

3.2 数据流风格

• 批处理序列：批处理风格的每一步处理都是独立的，并且每一步都是顺序的。

• 管道和过滤器：每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。

• 好处：良好的隐蔽性；高内聚低耦合；简单合成；支持重用；性能简单；允许死锁分析；支持并行执行；

• 弊端：导致进程成为批处理；不适合处理交互式应用；

3.3 调用/返回风格

• 主程序/子程序
• 面向对象风格：对负责维护其表示的完整性；对象的表示对其他对象而言是隐蔽的；
• 层次结构风格：支持基于抽象程度递增的系统设计；支持功能增强；支持重用；

3.4 独立构件风格

• 进程通信架构风格：构件是独立的过程，连接件是消息传递
• 事件系统风格：为软件重用提供了强大的支持；为还进系统带来了方便

3.5 虚拟机风格

• 解释器：包括完成解释工作的解释引擎，一个包含将被解释的代码储存区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的
• 规划为中心：基于规则的系统包括规则集、规则解释器，规则/数据选择器及工作内存

3.6 仓库风格

数据库系统、超文本系统、黑板风格

4 层次系统架构风格

4.1 二层及三层C/S架构风格

4.2 B/S架构风格

4.3 MVC架构风格

4.4 MVP架构风格

5 面向服务的架构

5.1 SOA概述

5.1.1 服务基本结构

5.1.2 SOA设计原则

明确定义的接口、自包含和模块化、粗粒度、松耦合、互操作性。

5.1.3 服务构件和传统构件

5.2 SOA关键技术

• UUDI（统一描述、发现集成）
  数据模型、API、注册服务
• WSDL（web服务描述语言）
  服务实现定义：服务、端口
  服务接口定义：绑定、端口类型、消息、类型
• SOAP（简单对象访问协议）
  封装；编码规则；RPC表示；绑定；
  SOAP消息：封装；SOAP头；SOAP体；
• REST（表述性状态转移）
  网络上的所有事物都被抽象为资源
  每个资源对应一个唯一资源标识
  通过通用链接件接口对资源进行操作
  对资源各种操作不会改变资源标识
  所有操作都是无状态的

5.3 SOA的实现方法

• Web Service
  架构：服务提供者，服务请求者，服务注册者。
  操作：发布，查找，绑定。
  层次：底层传输层，服务通信协议层，服务描述层，服务层，业务流程层，服务注册层
• 服务注册表
  服务注册，服务位置，服务绑定。
• 企业服务总线
  • 功能：
    • 支持异构环境中的服务，消息和基于事件的交互，并且具有适当的服务级别和可管理级别。
    • 可以在几乎不更改代码的情况下，以一种无缝的非入侵方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准
    • 充当缓冲器的ESB于服务逻辑和分离，从而使不同的系统可以同时使用同一服务，不用在系统或数据变化时改动服务代码
    • ESB还提供服务代码和协议转换等功能，多种传输方式，发现和使用企业服务或界面提供基础设施。
    • 提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地
    • 提供安全和拥有者机制，保证消息和服务使用的认证，授权和完整性。
  • 优势:
    • 扩展的、基于标准的连接。
    • 灵活的、服务导向的应用组合。
    • 提高复用率。
    • 减少市场的反应时间。

5.4 微服务

优势：
技术异构性，弹性，扩展，简单部署，与组织结构相匹配，可组合性，对可替代的优化。

挑战：
分布式系统的复杂度，运维成本，部署自动化，DEVOPS与组织结构，服务间的依赖测试，服务间的依赖管理

6 架构设计

1. 演变交付生命周期
2. 属性驱动设计法ADD
3. 按架构组织开发团队
4. 开发骨架系统
5. 利用商业构件进行开发

7 软件架构文档化

1. 架构文档的使用者
2. 合理的编写规则
   从读者角度编写文档，避免出现不必要的重复，避免歧义，使用标准结构，记录基本原理，文档保持更新但注意频率，针对目标的适宜性对文档进行评审
3. 视图编档
   视图概述，元素目录，上下文图，可变性指南，架构背景，术语表，其他信息。
4. 跨视图文档
5. UML
6. 软件架构重构

8 软件架构评估

8.1 软件架构评估方法

1. 基于调查问卷
2. 基于场景
3. 基于度量

8.2 架构的权衡分析法ATAM

1. 一个简洁的架构表述
2. 表达清楚的业务目标
3. 用场景集合捕获质量需求
4. 架构决策到质量需求的映射
5. 所确定的敏感点与权衡点的集合
6. 有风险决策和无风险决策
7. 风险主题集合
8. 产生一些附属结果
9. 产生一些无形的结果

步骤：

1. ATAM方法表述
2. 商业动机表述
3. 架构表述
4. 对架构方法进行分类
5. 生成质量属性效用树
6. 分析架构方法
7. 集体讨论并确定场景优先级
8. 分析架构方法
9. 结果的表述

8.3 成本效益分析法CBAM

步骤：
整理场景，对场景进行求精，确定场景优先级，分配效用，策略-场景-响应，质量属性响应级别效用，各架构策略的总收益，

9 构件及其复用

9.1 商用构件标准规范

CORBA，J2EE，DNA 2000

9.2 应用系统簇与构件系统

9.3 基于服用开发的组织结构

10 产品线及系统演化

10.1 复用与产品线

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

10.2 基于产品线的架构

三个方面：确定变化点，支持变化点，对产品线架构的适宜性进行评估

10.3 产品线的开发模型

前瞻性产品线，反应性模型

10.4 特定领域软件架构

• 领域模型为需求定义率领域知识和领域词汇
• 软件界面的设计往往和领域模型关系密切
• 领域模型的合理性将严重影响软件系统的可扩展性
• 在分层架构指导下，领域模型精华后即成为业务层骨架
• 领域模型也是其数据模型的基础
• 领域模型是团队交流的基础

10.4 架构及系统演化

需求变动归类，制订架构演化计划，修改增加删除构件，更新构件的互相作用，构架组装和测试，技术评审，产生演化后的架构

11 软件架构视图

11.1 软件视图分类

11.2 模块视图类型及其风格

11.3 C&C视图类型及其风格

11.4 分配视图类型及其风格

11.5 各视图类型间的映射关系

「 感谢支持 」

赞赏

微信赞赏

支付宝赞赏