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

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

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

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

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

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

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

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

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

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

软件老化的几个原因

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

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

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

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

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

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

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

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

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