《软件工程与计算（卷二）》-Chapter9-10-软件体系结构
A级：
软件体系结构的视角：
逻辑视图：设计的对象模型
视 角：最终用户
关注点：功能性需求，即在为用户提供服务方面系统所应该提供的功能。
表示法：UML（类图、交互图、顺序图、状态图），E-R图。
系统分解为一系列的关键抽象，表现为对象或对象类的形式。它们采用抽象、封装和继承的原理。
分解并不仅仅是为了功能分析，而且用来识别遍布系统各个部分的通用机制和设计元素。
开发视图：描述了在开发环境中软件的静态组织结构
视 角：程序员、软件项目经理
关注点：软件开发环境下实际模块的组织（受开发难度、软件管理、重用性和通用性及由工具集、编程语言所带来的限制）。
表示法：UML（包图）。
软件打包成小的程序块（程序库或子系统），它们可以由一位或几位开发人员来开发。
子系统可以组织成分层结构，每个层为上一层提供良好定义的接口。
过程视图：捕捉设计的并发和同步特征
视 角：系统集成者
关注点：非功能性需求，如并发性、分布性、系统完整性、容错性。
表示法：UML（活动图、交互图、状态图）。
进程架构可以在多层次的抽象上进行描述，每个层次针对不同的问题。在最高的层次上，进程架构可以视为一组独立执行的通信程序的逻辑网络，它们分布在整个一组硬件资源上，这些资源通过LAN或者WAN连接起来。多个逻辑网络可能同时并存，共享相同的物理资源。
软件被划分为一系列单独的任务。任务是独立的控制线程，可以在处理节点上单独地被调度。
区别主要任务、次要任务。
物理视图：描述了软件到硬件的映射
视 角：系统工程师
关注点：依赖于硬件的非功能性需求，如可用性、可靠性、性能吞吐量和可伸缩性等。
表示法：UML（部署图）。
分别用于开发和测试、部署的物理配置。
软件至节点的映射需要高度的灵活性及对源代码产生最小的影响。
模型：软件体系结构={部件，连接件，配置}
定义：一个软件系统的体系结构规定了系统的计算部件和部件之间的交互
体系结构风格：
主程序/子程序
面向对象式
分层
MVC
主程序/子程序：适用于按层次分解为多个顺序执行步骤的系统
优点：
流程清晰，易于理解
更能控制程序的“正确性”
缺点：
难以修改和复用
产生不必要的公共耦合
面向对象式：适用于能够基于数据信息分解和组织的软件系统
优点：
内部实现的可修改性
易开发，易理解，易复用
缺点：
无法消除接口的耦合性
标识的耦合性：一个方法要与其他对象交互，就必须知道其他对象的标识
副作用。引入了面向对象的副作用
分层：
优点：
①机制清晰，易于理解
②支持并行开发
③更好的可复用性与内部修改性
缺点：
①交互协议难以修改
②性能损失
③难以确定层次数量和粒度
适用性：
能在不同抽象层次上进行任务分解
能建立不同层次间的稳定交互协议
没有很高的实时性要求
MVC：适用于网络系统开发
优点：
①易开发性
②视图和控制的可修改性
③适宜于网络系统开发的特征
缺点：
①复杂性
②模型修改困难
包的设计原则（物理设计的主要原则）
REP：（Reuse-Release Equivalency Principle）复用发布等价原则
CCP（Common Closure Principle）：共同封闭原则
CRP（Common Reuse Principle）：共同复用原则
ACP（Acyclic Dependencies Principle）：非循环依赖（单向依赖）
SDP（Stable Dependencies Principle）：稳定依赖原则
SAP（Stable Abstractions Principle）：稳定抽象原则
Cohesion Reuse && Change（把一些东西做在一个包里，包里的东西是相关的）
REP：（Reuse-Release Equivalency Principle）复用发布等价原则
别人打开能用，考虑被别人复用的可能性（相同功能->相同需求->相同目的）
三层结构为什么分三层？就是因为分层符合REP
通常是类成组，不会单独类
CCP（Common Closure Principle）：共同封闭原则
如果要修改，最好涉及一个包而不是多个包。最好只有一个修改原因而不是多个修改原因
比如UI和BL中加VO，BL和DATA中加POJP，DATA分出Procedure
把相似的包放在一起
Confines changes to a few packages
减少包发布频率
减少编程者的工作
CRP（Common Reuse Principle）：共同复用原则
10个库别人只用了一个
侧重组合（减轻关联）
ACP（Acyclic Dependencies Principle）：非循环依赖（单向依赖）
会影响编译和链接的复杂程度
SDP（Stable Dependencies Principle）：稳定依赖原则
被依赖包尽可能不发生修改。包如果不稳定可以进行分解
SAP（Stable Abstractions Principle）：稳定抽象原则
稳定包应该是抽象的，不稳定的包是包含需求的
体系结构构件之间接口的定义：
提供的服务（供接口）：语法、前置条件、后置条件
需要的服务（需接口）：服务名、服务
软件体系结构设计过程：
①需求分析
②选择体系结构风格
③抽象设计
④物理设计
⑤完善
⑥定义构件接口
⑦迭代③~⑥
体系结构开发集成测试用例：（桩Stub、驱动Driver）
桩：自顶向下集成，下层的模块使用伪装的具有相同接口的桩。
驱动：自底向上集成，从底层的模块集成起，测试的时候上层的模块使用伪装的相同接口的驱动。
集成测试用例：模拟实现。
集成：单元测试后，将所有模块组合起来形成整个软件原型系统
集成的目的：逐步让各个模块合成为一个系统来工作，从而验证整个系统的功能、性能、可靠性等需求。进行黑盒测试
集成策略：
①大爆炸式
②增量式
增量式：
①自顶向下
②自底向上
③三明治式
④持续集成
大爆炸式：一次性组合。优点是短时间内迅速完成集成测试。缺点是问题的定位和修改比较困难。适合应用于一个维护型项目或被测试系统较小的情况
自顶向下：
优点：
①按深度优先可首先实现和验证一个完整的功能需求
②只需要最顶端一个驱动
③利于故障定位
缺点：
①桩的开发量大
②底层验证被推迟，底层组件测试不充分
适用于控制结构比较清晰和稳定、高层接口变化比较小、底层接口未定义或经常可能被修改、控制组件具有较大的技术风险的软件系统
自底向上
优点：
①对底层组件行为较早验证
②底层组件开发可以并行
③桩的工作量小
④利于故障定位
缺点：
①驱动的开发量大
②高层验证被推迟，高层的错误不能及时被发现
适用于底层接口比较稳定、高层接口变化频繁、底层组件较早被完成的软件系统
持续集成：
提倡尽早集成和频繁集成
优点：
①防止软件开发中出现无法集成与发布的情况
②有利于检查和发现集成缺陷
必须使用版本控制工具和持续集成工具
B级：