目录
1.可修改性Modifiability定义:可修改性与变化有关,其核心是进行修改的成本和风险
0.前言
本系列文章旨在软件设计与体系结构的知识点,资料来源四川大学授课内容,可用于期末复习,笔者理解尚浅,文中不正之处静待批正。加粗部分为重点。
可修改性Modifiability(与变化有关)
1.可修改性Modifiability定义:可修改性与变化有关,其核心是进行修改的成本和风险
规划可修改性时要考虑四个问题:What can be changed?What is the likelihood of the change?When is the change made and who makes it?What is the cost of the change
两种成本:引入机制使系统更具可修改性的成本;使用该机制进行修改的成本
对于 N 项类似的修改,比较修改成本的公式如下:N ×Cost1<= Cost2 + ( N ×Cost3 )
cost1:在没有机制的情况下进行变革的成本
cost2:建立机制的成本
cost3:使用机制进行变革的成本
2.可修改性的通用质量属性:
A change can be:Function ( add/modify/delete )/Qualities ( availability, usability )/ Capacity ( users number was supported)/Technology
例子:
开发人员希望通过在设计时修改代码来更改用户界面,在三小时内完成修改且无副作用。
4.可修改性的战术
控制可修改性的策略以控制修改的复杂性以及修改的时间和成本为目标
4.1 与可修改性有关的因素Factors relate to modifiability
可修改性与两个因素有关:
- 内聚性Cohesion:衡量模块职责之间的关联程度(内聚性越高越好)。
- 耦合度Coupling:衡量一个模块的修改会传播到另一个模块的概率(耦合度越低越好)。
4.2 激励可修改性策略的参数
Size of module模块大小;Coupling耦合;Cohesion内聚力;Binding time of modification修改的绑定时间
4.3 可修改性战术的类别
4类:Reduce size of a module/Increase cohesion/Reduce coupling/Defer binding time
Split module:原因:如果要修改的模块包含大量功能,修改成本可能会很高 解决办法:将模块细化为几个较小的模块,应能降低未来修改的平均成本
Encapsulate:使用中介打破依赖关系。例如,发布-订阅架构publish-subscribe中介将消除数据生产者对其消费者的了解。在面向服务的体系结构service-oriented architecture中,服务通过动态查找来相互发现,而中介机构中的目录服务则通过动态查找来相互发现。
Restrict dependencies:在实践中,这种策略是通过限制模块的可见性和授权来实现的。例如,分层架构layered architecture中,一层只允许使用下层的模块。
Refactor:当两个模块因彼此重复而受到同一变更的影响时,就会采取重构的策略;将共同的职责放在一起,使它们成为同一父模块的子模块。
Abstract Common Services:如果有两个模块提供类似的服务,则只需以更通用的形式实现一次服务即可,这样做可能更符合成本效益。引入抽象的常见方法是将模块活动的描述参数化。
Defer binding:①编译时绑定值:组件替换;编译时参数化;Aspect②部署时绑定值:配置时绑定值③启动或初始化时绑定值:资源文件④运行时绑定值:运行时注册;动态查找;解释参数;名称服务器;插件;发布-订阅;共享存储库;多态性
性能Performance(与时间相关)
定义:性能与时间和软件系统满足时间要求的能力有关
所有系统都有性能要求。它仍然是一项基本的质量属性
3.性能的通用质量属性
- Latency延迟:从刺激到达到系统做出反应之间的时间
- Deadline in process处理中的截止时间: 必须处理事件的阈值时间
- Throughput吞吐量:系统在单位时间内可处理的事务数量
- The jitter抖动:延迟的允许变化范围
- Miss rate未处理率:因系统太忙而无法响应而未处理的事件数
例子:
用户在正常操作情况下启动交易,系统处理事务的平均延迟时间为两秒。
4.性能的战术
性能战术的目标是在一定的时间限制内对系统中出现的事件做出响应
4.1 影响性能的因素
影响响应时间的两个基本因素:
①处理时间Processing time:系统正在努力作出响应
处理需要消耗资源:硬件资源、软件资源
②阻塞时间Blocked time:系统无法响应
计算受阻的原因可能是对某些所需资源的争夺
阻塞时间的类型:
争夺资源Contention for resources:多个数据流竞争同一资源(关键资源访问)
资源可用性Availability of resources:资源不可用(资源离线、组件故障)
依赖其他计算Dependency on other computation:一项计算可能需要等待,因为它必须与另一项计算的结果同步
4.2 两类性能战术
①控制资源需求Control resource demand:这种策略从需求方面入手,减少需求量
两类控制资源需求:减少处理事件的数量Reduce the number of events processed;限制系统响应事件的速度Limit the rate at which the system responds to events
1)管理采样率:可以降低采样频率,从而减少需求。这种方法通常会带来一些保真度损失(副作用)。
2)限制事件响应:当离散事件到达系统的速度太快而无法处理时,这些事件必须排队等待处理。这种策略不允许丢失任何事件,系统只能以设定的最大速度处理事件。
3)确定事件的优先级:如果并非所有事件都同等重要,则可采用优先级方案对事件进行排序;如果可用资源不足,低优先级事件可能会被忽略;忽略事件会消耗最少的资源,从而提高整体性能。
4)减少开销:使用中介会增加资源消耗,移除中介则会改善延迟 这就是可修改性/性能的权衡。减少计算开销的一种策略是将资源集中在同一地点。
5)限制执行时间:限制用于响应事件的执行时间 对于迭代式,限制迭代次数是限制执行时间的一种方法 限制执行时间通常是一种不太精确的计算方法。
6)提高资源效率:改进关键领域使用的算法,减少延迟。
②管理资源Mange resources:该策略在响应方面发挥作用,使现有资源更有效地处理需求。
管理资源策略通常适用于处理器,但也可有效应用于磁盘等其他资源。例如,中间数据可以保留在缓存中,也可以根据时间和空间资源的可用性重新生成
1)增加资源:更快的处理器、额外的处理器、额外的内存和更快的网络都有可能减少延迟。不过,在许多情况下,这是立即改善的最廉价方法。
2)引入并发性:如果可以并行处理请求,则可以减少阻塞时间;并发性可以通过在不同的线程上处理不同的事件流或创建额外的线程来处理不同的活动来实现。并发指的是并行操作;在系统创建新线程的任何时候都会出现并发现象;独立线程支持系统上的多任务处理。
由于交错现象被称为 "竞赛条件"Race condition,并发性必须由架构师进行管理。当有两个控制线程且共享状态时,就会出现竞赛条件。竞赛条件是最难发现的错误类型之一。该错误的出现具有偶发性,取决于时间上的差异。
有两种技术可以防止竞态:①使用锁来强制顺序访问状态②根据执行部分代码的线程来划分状态。 也就是说,有两个 x 实例,x 不被两个线程共享。