5 软件体系结构的设计原理

在SE中，可根据建模要求和抽象内容，将模型如下分类：

开发过程模型	瀑布、增量、螺旋
信息流模型	DFD，SADT
设计模型	类图、功能层次图
交互作用模型	实例图、时序图
状态迁移模型	状态图、Petri网
用于构造细节的原理模型	设计模式、ER图
过程成熟度模型	CMM
其他模型	可靠性模型，成本估算模型

体系结构的设计原理

抽象

数据抽象、实体抽象、行为抽象、过程抽象、对象抽象、虚拟机抽象
模型是抽象的，但算法是具体的。

封装

将抽象的属性和行为结合在一起
为不同的抽象提供了明确的界限
有利于非功能特性的实现
- 可变性
- 可复用性

信息隐藏

对用户隐藏部件的实现细节：接口与实现相分离
信息的隐藏
- 如何隐藏取决于技术
- 隐藏那些取决于具体的应用
用来更好地处理系统的复杂性和减少各部件之间的耦合

模块化

良好定义的分界将构成应用的逻辑结构物理地分割成代码实体
模块是一个应用的功能和责任的物理容器
- 优点：可复用
- 缺点：额外复杂的系统资源管理

注意点分离（Separation of Concerns）

不同和无关联的责任应该在软件系统中分离开来，让他们出现在不同的部件中
相互协作完成某一个特定任务的部件应该和在其他任务中执行计算的部件分离开来
避免过多暴露所造成的对应用设计的负担和混乱，保证了组件运行的可靠和安全

耦合和内聚

高内聚
弱耦合：模块间联系的紧密程度（理解、维护、调试）

原始性

原始性是指部件应该完成的操作都可以容易地得到实现（人的价值是最大的）

策略和实现的分离（决策机构与实现部门）

策略部件负责处理上下文相关的决策、信息的语义和解释的知识、把不相交计算组合形成结果、对参数值进行选择等问题
实现部件负责全面规范算法的执行，执行中不需要上下文相关信息进行决策
实现部件因为独立于上下文环境，因而更容易重用和维护
策略部件因为与特定的应用相关，通常随时间的变化而改变

接口和实现的分离

接口定义了部件所提供的功能并规范了功能的使用方法
实现部分包括了部件所提供功能的实际代码
强调一个客户只应该知道他需要知道的东西
是一种信息隐藏技术
接口和实现的分离可以很好地支持可变性

分而治之（divide and conquer）

自上而下的分析，自下而上的实现
横向的分解
纵向的分解

层次化

软件的非功能特性

功能特性主要是直接针对客户的功能需求，多数是容易感知和判断的。
不成熟的客户、投资决策者、设计者往往片面追求表明功能的要求而忽略内在的结构和非功能特性。
软件系统越大越复杂、生命周期越长，非功能特性就越重要。

可变性/可维护性

软件老化的几个原因

不能适应变化
盲目和无知的更改
软件建立初期就设计得不灵活，无法或难以维护和升级
文档不充分

可变性/可维护性的四个方面

可维护性
可扩充性
可重构性（设计人员；用户）
可移植性

为应对改变而设计的系统更容易适应用户，适应性要好得多，生命周期要长得多

设计可维护
- 业务设计的可维护性
- 实现设计的可维护性
代码可维护
运行可维护

互操作性

互操作性是指不同的计算机系统、网络、操作系统和应用程序一起工作并共享信息的能力。
将系统设计成具有互操作性的部件集合本身就自然地对系统的功能构成进行了分割。
使各种不同的系统能够更好地通讯和交换数据，提高软件的互操作性需要由不同的厂商共同努力来完成。直到目前为止它仍然是软件领域中最大的挑战之一。

效率

软件运行过程中对资源的使用情况、以及对系统的响应时间、存储消耗和I/O吞吐量的影响
效率问题不仅仅是设计精良算法的问题，而且是部件操作责任合理的分配、部件之间的耦合关系等体系结构的问题
良好结构、丰富功能和高效率等方面需要权衡利弊

性能

我们往往关注的是系统的运行速度，宏观上，还需关注设计、编码等整个软件系统交付过程的速度。

设计速度：兼顾速度与质量
编码速度
运行速度

可靠性

是软件系统在各种情况下维持其功能的能力，区分为2个方面的内容：

容错性：当错误事件发生时确保正确的系统响应，必要时采取内部补救措施
健壮性：健壮性不要求软件在发生错误之后还能继续执行，他只需要保证软件能以明确和可接收的方式终止

可测试性

支持可测试性的软件体系结构可以为错误探测和改正、以及代码调试和部件的临时集成给予支持

可重用性

“通过已经存在的来获得想要的”的软件设计和实现方法（有利于Cost、Time、Quality）

非功能性可能产生冲突。
虽然非功能性在软件体系结构中非常重要，但很难对他们的效果和作用进行衡量。
对软件体系结构满足非功能性程度的评价，主要还是基于工程师的经验。