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级: