-
质量属性判断与质量属性效用树
- 性能:指系统的响应能力,即要经过多长时间才能对某个事件作出响应,或者在某段时间内系统所能处理的事件个数。
- 如响应时间、吞吐量。
- 设计策略:优先级队列、增加计算资源、减少计算开销、引入并发机制、采用资源调度等。
- 可靠性:是软件系统在应用或系统错误面前,在意外或错误使用的情况下维持软件系统功能特性的基本能力。
- 如MTTF、MTBF。
- 设计策略:心跳、Ping/Echo、冗余、选举。
- 可用性:是系统能够正常运行的时间比例,经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
- 如故障间隔时间。
- 设计策略:心跳、Ping/Echo、冗余、选举。
- 安全性:是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
- 如保密性、完整性、不可抵赖性、可控性。
- 设计策略:入侵检测、用户认证、用户授权、追踪审计。
- 可修改性:指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变化为基准,通过考查这些变更的代价衡量。
- 设计策略:接口-实现分类、抽象、信息隐藏。
- 功能性:是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
- 可变性:指体系结构经扩充或变更成为新体系结构的能力。
- 这种新体系结构应该符合预先定义的规则,在某些具体方面不同于原有的体系结构。
- 当要将某个体系结构作为一系列相关产品的基础时,可变性很重要的。
- 互操作性:作为系统组成部分的软件不是独立存在的,经常与其他系统或自身环境相互作用。
- 为了支持互操作性,软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。
- 程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题,也影响应用的软件体系结构。
- 性能:指系统的响应能力,即要经过多长时间才能对某个事件作出响应,或者在某段时间内系统所能处理的事件个数。
-
必背概念
- 软件架构风格:指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式,惯用模式则反映众多系统共有的结构和语义。
- 架构风险:指架构设计中潜在的、存在问题的架构决策所带来的隐患。
- 风险点与非风险点:不是以标准专业术语形式出现的,只是一个常规概念,即可能引起风险的因素,可称为风险点。某个做法如果有隐患,有可能导致一些问题,则为风险点;而如果某件事是可行的、可接受的,则为非风险点。
- 敏感点:指为了实现某种特定的质量属性,一个或多个构件所具有的特性。
- 权衡点:是影响多个质量属性的特性,是多个质量属性的敏感点。
-
架构风格对比
架构风格 | 主要特点 | 主要优点 | 主要缺点 | 适合领域 |
---|---|---|---|---|
管道-过滤器 | 过滤器相对独立 | 功能模块复用;可维护性和可扩展性较强;具有并发性;模块独立性高 | 不适用于交互强的应用,对于存在关系的数据流必须进行协调 | 系统可划分清晰的模块;模块相对独立;有清晰的模块接口 |
面向对象 | 力争实现问题空间和软件系统空间结构的一致性 | 高度模块性;实现封装;代码共享灵活;易维护;可扩充性好 | 增加了对象之间的依赖关系 | 多种领域 |
事件驱动 | 系统由若干子系统构成且称为一个整体;系统有统一的目标;子系统有主从之分;每一个子系统有自己的事件收集和处理机制 | 适合描写系统组;容易实现并发处理和多任务;可扩展性好;具有类层次结构;简化代码 | 因为树形结构所以削弱了对系统计算的控制能力;各个对象的逻辑关系复杂 | 一个系统对外部的表现可以从它对事件的处理表征出来 |
分层风格 | 每个层次的组件形成不同功能级别的虚拟机;多层互相协同工作,而且实现透明 | 支持系统设计过程中的逐级抽象;可扩展性好;支持软件复用 | 不同层次之间耦合度高的系统很难实现 | 适合功能层次的抽象和相互之间低耦合的系统 |
数据共享风格 | 采用两个常用构件中央数据单元和一些相对独立的组件集合 | 中央数据单元实现了数据的集中,以数据为中心 | 适合于特定领域 | 适合于专家系统等人工智能领域问题的求解 |
解释器风格 | 系统核心是虚拟机 | 可以用多种操作来解释一个句子,灵活应对自定义场景 | 适合于特定领域 | 适合于模式匹配系统与语言编译器 |
闭环控制风格 | 通过不断地测量被控对象,认识和掌握被控对象;将控制理论引入体系结构构建 | 将控制理论引入到计算机软件体系结构中 | 适合于特定领域 | 该系统中一定存在有目标的作用、信息处理闭环控制过程 |