[课业] 19 | 软工 | 软件体系结构设计与构建

体系结构设计

体系结构设计过程

过程为：

1. 分析关键需求和项目约束
   搞清楚体系结构的输入是什么
2. 选择体系结构风格
3. 进行软件体系结构逻辑设计
4. 依赖逻辑设计进行软件体系结构设计
5. 完善体系结构设计
6. 添加构建接口
7. 迭代过程3-7

说明：

1. 整个过程可以分为两步骤：逻辑设计（1-3）和物理设计（4-6），其中3-4是从逻辑设计到物理设计的转化
2. 迭代过程是为了不断完善软件体系结构设计

分析关键需求和项目约束

1. 图示
   
2. 体系结构的输入：功能需求，非功能需求（质量、性能、约束、接口，项目约束等
3. 不同程度的系统考虑输入（需求）范围不同：
   简单系统可能只考虑功能需求——功能齐全就好
   商业产品——加入项目约束的考虑（钱、人、物、时间等）
   复杂产品——加入非功能性需求的考虑
4. 实践案例
   
   需求：
   概要功能需求：10个功能
   非功能性需求：安全需求（Security1～3）；约束IC2
   项目约束：
   开发技术：Java
   时间较为紧张
   开发人员：不熟悉Web技术

选择体系结构风格

1. 实践案例
   
   本例中，协议较为清晰，采用分层风格
   分层风格：协议不变情况下易于修改；能够促进并行开发
   实际的并行开发（以逻辑、数据、展示分层为例）：分三拨人员分别开发

进行软件体系结构逻辑设计（抽象）

依据概要功能需求与体系结构风格建立初始设计

概述

1. 此步骤目标：将需求分配到子系统和模块
2. 什么样的需求分到同一模块或子系统？
   考虑功能的相同性：不同任务但是相同功能
   考虑可复用性：结构、数据、行为的可复用性（如对同一数据进行操作的行为可能被放在一起）

实践案例

1. 精简示例
   销售与退货：互为逆向过程，属于同一功能
   产品调整、入库、出库与库存分析：都是对库存数据的增删改查——行为复用
   会员发展与礼品赠送：会员数据的操作
   销售策略
2. 精简结果
   基本功能：销售、库存、会员、销售策略、用户
3. 确定功能对应的逻辑包
   注意起名字最好统一格式
   每个功能都有三层，各有一包
   
4. 确定好功能对应的逻辑包后，考虑每个功能依赖的数据（需要依赖这些包中的哪些）
   
5. 根据每个功能设计的包的信息产生初步设计方案（包图）
   
   这个方案中
   存在很多复杂的依赖关系
   如SaleUI要用到逻辑层4个包的数据——这在开发时，就意味着做展示层的某人要与做逻辑层的好多人都要打交道，代价过大
   又如数据层就集中在一个数据库包上，数据库压力大
6. 改进包的结构后的初步设计方案
   
   这个方案中
   每一个展示层包只和一个业务逻辑包相连；每一个业务逻辑包只与他对应的数据包进行交互；数据分不同包——实现层间包交互是一对一的
   数据层分包的好处：如果某个数据层包发生改变，那么对上层的影响也只是一个包
   此时的SaleUI包还是需要获得好多逻辑层包的数据，他们不直接相连，而是SalesUI对应的逻辑层包负责与逻辑层其他的有数据需求的包相连进行联系，这就实现了开发中的跨足沟通（代价大）转化为组内沟通（代价相对小）

使用非功能性需求与项目约束评价和改进初始设计

对上述案例的初步设计的分析

1. 能够满足项目约束（项目约束）
   分层风格能够促进并行开发，从而缩短开发时间
   分层风格可以使用Java技术，而不使用Web技术
2. 无法满足安全需求和网络分布约束，所以需要改进（非功能需求）
   为使其满足安全需求，可以增加用户登录与验证功能，可以建立专门的三个模块(Presentation, Logic, Data)，也可以将该功能并入用户管理功能，即为userUI，user，userData三个模块增加新的职责

连锁超市管理系统最终的软件体系结构逻辑设计方案

增加了用户登录包（逻辑层里）
做出决策：展示层与逻辑层放在客户端，数据层放在服务器端
逻辑层与数据层（客户短语服务器端）通过RMI相交流
这就体现了项目约束、非功能需求对架构的更改

物理包设计原则

概述

两类原则

1. 内聚性原则：关注点在于包的内聚性，如何重用、变更；如何让包的内部具有更强大的联系，变得高内聚
   共同封闭原则(CCP)
   共同重用原则(CRP)
   重用发布等价原则(REP)
2. 耦合性原则：关注点在于包的耦合性，如何使包与包之间关联变得弱，实现低耦合
   无循环依赖原则(ADP)
   稳定依赖原则(SDP)
   稳定抽象原则(SAP)

共同封闭原则

1. 一起被修改的类应该放在一个包里
2. 如果一起改的东西都放在一个包里，那么要修改时就修改一个包就好了，这样利于维护，最小化修改的影响
3. 一次修改的影响尽量波及到少的模块，这样编译、连接、重验证的时间和成本都减小
4. 项目中
   
   两个接口处的数据对像会一起被修改，放在一起
   持久化数据连接们放在一起
5. 总结
   有相同修改需求的放在一起，注意这里说的一起修改需求都是可预测到的修改
   不可预测的东西：要么出现了系统可以忍受，要么就是不可忍受的重大改动（代价大）
   没有预测到的改变破坏力很大
   再好的设计也是基于能预测到的影响和修改，不可能有高超的设