5.1 设计过程
5.1.1 设计
- 思考如何实现客户所有需求的过程、产品的计划，就是设计
- 设计早期 体系结构 设计后期 如何实现具体的细节 模块/代码设计
5.1.2 体系结构：
1-1. 什么是软件体系结构设计
软件体系结构定义：
- 【IEEE610. 12—1990】体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即软件体系结构={构件，连接件，环境，原理}
- 【Bass的定义】系统的一个或多个结构，包括软件构件、构件的外部可视属性和构件之间的关系
- 【国内】可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)
设计相关的概念
1-2. 设计模式 设计公约…
设计模式 design pattern：一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策。它是一个共同的设计结构的关键方面，包括对象和实例，角色和协作，责任分配，第六章详细讨论
设计公约 Design Convention：一系列设计决策和建议的集合，采取这些建议可以提高系统某方面的设计质量。当一种设计公约发展成熟时，将会被封装成设计模式或体系结构风格，最后可能被内嵌为一种程序语言结构
创新设计 innovation design：由脑海中闪现的灵感驱动，这种无规律的突发式进展正是创新性设计的特征
设计原则 design principle：是把系统功能和行为分解成模块的指导方针，描述一些
良好设计的特征（优秀设计的可描述的特点）【好的设计所具有的可以描述的特征】
2. 软件体系设计过程
建模 分析 文档化 预审 SAD
软件设计过程模型的五个阶段：
- 初始建模：尝试对系统进行分解，根据需求描述的系统关键特性确定软件体系结构风格。
- 分析：分析软件系统的功能和质量属性、各种约束等。
- 文档化：确定各个不同的模型视图，进行文档化。
- 复审：检查文档是否满足所有功能及质量需求。
- 最终输出：软件体系结构图SAD。
3. 设计用户界面需要考虑的问题：
① prototype
② 文化差异的问题/用户爱好的问题
5.3 Decomposition和view
分解是把大的系统分解成为更小的部分使问题变得更易于处理，是一种自顶向下的方法；另一种自底向上的方法是将小的模块以及小的构件打包成一个更大的整体，被认为其设计出来的系统更加易于维护。
六种设计方法
(1) 功能性分解 Functional decomposition:按照功能和需求进行分解
(2) 面向特征的分解 Feature-oriented design:功能性分解的一种，为各个模块指
定了各自的特征
(3) 面向数据的分解 Data-oriented decomposition :关注如何将数据分解成模块
(4) 面向进程的分解 Process-oriented decomposition:将系统分解成为并发进程
(5) 面向事件的分解 Event-oriented decomposition:将事件分给不同的模块
(6) 面向对象的设计 Object-oriented design:将对象分配给模块
模块化 Modular：只有当系统的每个活动都仅由对应的软件单元实现，并且每个软件单元的输入和输出都已经明确的被定义时，这个设计才是模块化的。
明确定义 well-defined：一个定义明确的软件单元的接口必须能够准确无误地指定该单元的外部可见行为（其他构件认为该构件所具备的特征，提供的服务，具有的特点，错误处理机制）：每个指定的输入对于单元功能来说都很重要，且一个指定的输出很可能就是这个单元动作的结果
5.4 软件体系结构风格和策略 Architectural Styles and Strategies
软件体系结构风格（Architectural Styles）
软件体系结构风格（Architectural Styles）是描述特定系统组织方式的惯用范例，强调了软件系统中通用的组织结构。
1. Pipes-and-Filter（管道和过滤器）
一种组件式设计,常用于语义分析、字典分析等设计。
- 管道 pipe：将数据从一个过滤器传输到下一个过滤器的连接器，不对数据做任何改变
- 过滤器 filter：数据转换构件，对输入数据进行转换
2.Client-Server（客户端-服务器）C/S
服务器提供服务
客户通过请求/应答协议访问服务
3.Peer-to-Peer（对等网络）
体系结构中，每个构件都只执行它自己的进程并且对于其他同级构建，每个构件本身既是客户端又是服务器。如文件共享网络
4.Publish-Subscribe（发布-订阅）
用于分组交换网络软件设计等等。事件驱动，基于构件之间对时间广播和反应实现交互。一个构件订阅感兴趣的事件，一旦该事件发生，另一个构件进行发布来通知订阅者。隐含调用 implicit invocation 就是一种常见的发布订阅体系结构。
5.Repositories（信息库）
常用于信号处理、知识发现、模式识别系统等设计
由中心数据存储以及其与其相关联的访问构件组成。其重要特性就是对于系统关键数据的中心式管理，如黑板类型信息库系统：包括黑板（blackboard）本身，知识源（knowledge sources）和控制。当黑板的状态发生变化时，知识源将作出响应。也就是访问数据的构件是被动的。
在基于规则的系统中，黑板上存储了问题的当前解决状态，知识源使用重写规则迭代地修改优化解决方案。这种风格类似于在真实世界中在黑板上进行计算或证明过程，人们（知识源）一遍一遍地走到黑板前去优化解答。黑板模式对于无确定性求解策略的问题比较有用，在专家系统中，这种模式应用的比较广泛。
主要的优点：openness开放性
缺点：必须统一格式
6.Layering（分层）
分层系统就是将系统的软件单元按层次划分，每一层为它的上层提供服务，同时作为下层的客户。
例如计网中的开放式系统互联 OSI。
优点是高度的抽象以及相对容易增加和修改层，
缺点是结构化系统的层次的难度以及系统性能会受到层之间的额外协调影响。
5.5 Achieving Quality Attributes
软件需求包含功能性需求和质量需求，在设计系统时，选择能够提高必要的质量属性的体系结构风格
可修改性 Modifiability
可修改性是大部分体系结构风格的基础，设计必须易于修改
对于某个特定改变，为了减少受直接影响的单元，要预测预期改变然后封装在各自的软件单元内、增加内聚性、增加软件单元的通用性；为了减少受间接影响的单元，要降低耦合性增加接口设计的多重性。
通过修改单元的输入来适应变化，而不是修改单元本身
Self-managing Software 自管理软件
基本思想：软件系统监控其环境或自身性能，并根据检测到的变化改变其行为
性能 performance
描述了系统速度和容量上的特点，主要包括响应时间（请求反应时间）、吞吐量（处理请求速度）和负载（并发用户数）
几项内容提高性能的策略：
①提高资源利用率，如增加软件并行程度；复制数据以及分布式共享数据
②有效的管理资源分配，使用一些调度策略以达到响应时间最小化，吞吐量、资源利用率、公平最大化，高级或紧急事件优先处理等，如 FIFO
③降低对资源的需求，如设计适应性能要求的拓扑结构或允许有限变更等
1. 管理资源的利用 ①先到先服务 ②指定优先级 2. 编写有效的代码
安全性 security
安全性 security 是实现软件各种安全保密措施的有效性度量。
Immunity（免疫力）：系统阻挡攻击企图的能力，可通过更改体系结构保证系统安全特征、最小化系统安全漏洞提高免疫力
Resilience（弹性）：系统快速容易地从成功的攻击中恢复的能力。可通过功能分段使攻击影响最小化、增加快速恢复能力来提升。
提高免疫力（检测到、融合策略） 弹性（从异常快速回复）
可靠性 reliability
可靠性 reliability 是软件产品在假设的环境下，按照规定的条件和规定的时间区间完成规定功能的能力。
主动故障检测：可以使用周期性检查或预测系统故障，如无法提供服务，提供错误服务，数据损坏，死锁等等；可以使用某种形式的冗余如 n 版本编程（N-version programming）
故障恢复 Fault recovery：撤销事务 Undoing transactions，回退 Checkpoint/rollback，备份 Backup，服务降级Degraded service，实时修正 Correct and continue，实时报告 Report……
（偏内部）
健壮性robust
健壮性robust 是系统在不正确的输入或意外的环境条件下依然保持正确工作的能力。
可靠性与软件本身内容是否有错误有关，而健壮性与软件容忍错误或外部环境异常时的表现有关。要防御的设计系统，必须遵循互相怀疑策略，每个软件单元都假设其他软件单元含有故障；在检测故障时，与可靠性策略中的故障恢复基本类似。
（偏外部）
易使用性 usability
易使用性 usability 是用户能够操作软件系统的容易程度。
将用户界面放置于自己的软件单元方便于为不同类型用户定制；系统需要一个进程来监听一些用户发起的命令；系统需要维护一个环境模型来支持系统发起的活动要求。
商业目标
5.6 Collaborative Design
outsourcing 外包（了解即可）
5.7 架构评估和改进 Architecture Evaluation and Refinement
不做具体要求，知道即可
5.8 Documenting Software Architectures
Document rationale: outlining critical issues and trade-offs 为设计合理性建立文档，概述在构建设计的过程中所考虑的关键问题以及做出的权衡
System overview 系统概述
Views 视图
Software units 软件单元
Analysis data and results 分析数据和结果
Design rationale 设计合理性
Definitions, glossary, acronyms 定义、术语表、缩写词
5.9 Architecture Design Review
评审 确认 验证
4. 复审的概念 重要性
设计复审：检查我们的软件设计、软件体系结构图是否满足了所有功能与质量需求。其重要性在于复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。复审可以分为两类：
- 概念设计复审：与客户和用户一起检查概念设计。
- 技术/程序设计复审：让程序员可以参与复审，在程序实现之前获得本阶段的反馈。