系统架构设计师-案例分析-软件架构设计
质量属性
-
质量属性效用树、质量属性判断
(1)性能:指系统的响应能力 ,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量 。设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度 等。
(2)可靠性:是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统的功能特性的基本能力 。可靠性通常用平均失效等待时间(Mean Time To Failure,MTTF )和平均失效间隔时间(Mean Time Between Failure,MTBF )来衡量。在失效率为常数和修复时间很短的情况下,MTTF和MTBF几乎相等。可分为容错和健壮性。容错 是指在错误发生时确保系统正确的行为,并进行内部"修复"。健壮性是系统不受错误使用和错误输入的影响,按既定程序忽略错误。设计策略:冗余、心跳、选举、Ping/Echo 。
(3)可用性:是系统能够正常运行的时间比例 ,经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间 。设计策略:冗余、心跳、选举、Ping/Echo。
(4)安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力 。可分为机密性、完整性、不可否认性、可控性 。机密性保证信息不泄露给未授权的用户、实体或过程;完整性保证信息的完整和准确,防止信息被非法修改;不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为;可控性保证对信息的传播及内容具有控制的能力,防止为非法者所用。设计策略:入侵检测、用户认证、用户授权、追踪审计。
(5)可修改性:是指能够快速的以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准,通过考查这些变更的代价来衡量可修改性。可分为可维护性、可扩展性、结构重组和可移植性。
- 可维护性:在错误发生后"修复"软件系统的难易程序。 - 可扩展性:软件因适应新需求或需求变化而增加新功能的能力。 - 结构重组:重新组织软件系统的构件及构件之间的关系。 - 可移植性:将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。设计策略:接口-实现分类、抽象、信息隐藏。
(6)功能性:是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
(7)可变性:指架构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则,在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品的基础时,可变性是很重要的。
(8)互操作性:作为系统组成部分的软件不说独立存在的,通常与其他系统或自身环境相互作用。为了支持互操作性,软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,这种互操作性也影响应用的软件架构。
质量属性效用树
ATAM方法采用效用树这一工具来对质量属性进行分类和优先级排序。效用树的结构包括:树根------质量属性------属性分类------质量属性场景 。
ATAM主要关注4类质量属性:性能、安全性、可修改性和可用性。

软件架构风格
重要:
- 软件结构风格是描述某一特定应用领域中系统组织方式的惯用模式。结构风格定义一个系统家族,即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。
- 敏感点和权衡点:敏感点是指为了实现某种特定的质量属性,一个或多个构件所具有的特性。权衡点是影响多个质量属性的特性,是多个质量属性的敏感点。
- 架构风险:是指架构设计中潜在的、存在问题的结构决策所带来的隐患。
- 风险点和非风险点:即可能引起风险的因素,称为风险点。而如果是某件事是可行的可接受的,则为非风险点。
架构风格对比
架构风格含义
| 架构风格名 | 子风格 | 常考关键字及实例 | 简介 |
|---|---|---|---|
| 数据流 | 批处理 | 一个接一个,数据以整体的方式传递 | |
| 管道-过滤器 | 传统编译器、网络报文处理 | 一个接一个,前一个输出是后一个输入 | |
| 调用/返回 | 主程序/子程序 | 显示调用,主程序直接调用子程序 | |
| 面向对象 | 构件是对象,通过对象调用封装的方法和属性 | ||
| 层次型 | 分层,每层最多影响其上下两层,有调用关系 | ||
| C/S | 瘦客户机 | 三层C/S结构为客户端、应服务器和数据库服务器 | |
| B/S | 零客户端 | 三层B/S结构为浏览器、Web服务器和数据库服务器 | |
| 以数据为中心 | 仓库 | 现代编译器的集成开发环境IDE,以数据为中心。又称为数据共享风格 | 中央共享数据源,独立处理单元 |
| 黑板 | 包括知识源、黑板和控制三部分。适用于解决复杂的非结构化问题,如信号处理、问题规划和编译器优化等 | ||
| 虚拟机 | 解释器 | 自定义一套规则,开发构件,增加灵活性,能够跨平台适配 | 解释自定义的规则,解释引擎、存储区、数据结构 |
| 规则系统 | 包括规则集、规则解释器、选择器及工作内存,用于人工智能和DSS中 | ||
| 独立构件 | 进程通信 | 进程之间消息传递,点对点独立传递,同步或异步方式 | |
| 事件系统 | 事件触发调用,如程序语言的语法高亮、语法错误提示 | 基于事件的隐式调用,通过事件驱动 | |
| C2风格 | 构件和连接件、顶部和底部 | 通过连接件绑定在一起按照一组规则运作的并行构件网络 | |
| 闭环-过程控制 | 汽车巡航定速、空调温度调节,设定参数,并不断调整 | 发出控制指令并接受反馈,循环往复达到平衡。 |
常考架构风格对比
| 架构风格 | 主要特点 | 主要优点 | 主要缺点 | 适合领域 |
|---|---|---|---|---|
| 管道-过滤器 | 过滤器相对独立 | 高内聚、低耦合;支持软件复用;可维护性、可扩展性较强;具有并发性、灵活性 | 不适用于交互性强的应用,对于存在关系的数据流必须进行协调 | 系统可划分清晰的模块:模块相对独立:有清晰的模块接口 |
| 解释器风格 | 系统核心是虚拟机 | 自定义一套规则,开发构件,增加灵活性,能够跨平台适配,可扩展性强 | 执行效率低,如果语法规则数量太多,会增加系统复杂度,性能较差 | 适合于模式匹配系统与语言编译器 |
| 面向对象 | 构件是对象,对象是通过函数和过程的调用来交互的 | 高度模块化:实现封装:代码共享灵活;易维护;性能好 | 增加了对象之间的依赖关系 | 多种领域 |
| 事件系统 | 构件不直接调用一个过程,而是触发或广播一个或多个事件 | 支持软件复用;容易实现并发处理和多任务;可扩展性好;具有类层次结构;简化代码 | 对系统计算的控制能力弱;各个对象的逻辑关系复杂 | 一个系统对外部的表现可以从它对事件的处理表征出来 |
| 层次型 | 构件组成一个层级结构;多层相互协同工作,每一层为上层提供服务,并作为下层的客户,只对与自己相邻的层可见 | 支持系统设计过程中的逐级抽象;可扩展性好;支持软件复用 | 不同层次之间耦合度高的系统很难实现,即难以划分层次 | 适合功能层次的抽象和相互之间低耦合的系统 |
| 仓库 | 由中央数据结构和一组独立构件组成 | 中央数据结构实现了数据的集中,以数据为中心 | 适合于特定领域 | 以数据为中心 |
MVC架构

面向服务的架构SOA
SOA是一种设计理念,其中包含多个服务,服务之间通过相互依赖最终提供一系列完整的功能。
企业服务总线ESB
用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务,ESB做了消息的转化、解释以及路由的工作,以此来让不同的服务互联互通。
ESB的特点:
- SOA的一种实现方式,ESB在面向服务的架构中起到的是总线作用,将各个服务进行连接与整合
- 描述服务的元数据和服务注册管理
- 在服务请求者和提供者之间传递数据,以及对这些数据进行转换的能力,并支持由实践中总结出来的一些模式如同步模式、异步模式等;
- 发现、路由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高级一些的能力,包括对安全的支持、服务质量保证、可管理性和负载平衡等。
ESB的主要功能:
- 服务位置透明性
- 传输协议转换
- 消息格式转换
- 消息路由
- 消息增强
- 安全性
- 监控与管理