04《软件构架实践第二版》阅读笔记之四

在前一部分,学习了很多系统质量属性,这些刻画都是通过场景的集合进行的,所以了解到了质量属性能够使我们获取质量需求,但是无法学习到如何实现它们。所以,接下来,我就学习了如何实现每个质量属性的构架,质量属性需求和构架决策之间的关系。

使一个设计具有可移植性,一个设计具有高性能,一个设计具备可集成性,实现这些质量属性的关键都在于基本的设计决策。我们将这些设计决策称为“战术”,即影响质量属性响应控制的设计决策。我们又把战术的集合称为“构架策略”。而系统设计由决策集合组成,在这些决策中,一些可以帮助控制质量属性响应,而另外一些可以确保系统功能的实现。对于设计师来说,每个战术都是一个设计的选择,所以设计师在实践中所使用的的战术,对于我们来说是需要去学习和借鉴的重要内容。比如,在提高可用性方面有两个最近的分支。(1)战术可以求精其他战术,我们可以将冗余确定为一个战术,但是同样,也可以把它求精为数据冗余(在数据库系统中)或计算冗余(在嵌入式系统中)。这两种类型也都是战术,而设计人员需要做的就是进一步求精以使每种类型的冗余更急具体,对于每一个质量属性,可以将战术组织为层级形式。(2)模式可以把战术打包。支持可用性的模式很可能会使用冗余战术和同步战术,也有可能会使用这些战术的更具体的形式。接下来学习了实现质量属性的战术方法,并将每个系统质量属性的战术组织为层次形式。

1.可用性战术:维持可用性的所有方法包括某种类型的冗余,用来检测故障的某种类型的健康监视,以及当检测到故障时某种类型的恢复,并且某些情况下,监视或恢复是自动进行的,还有些情况是手动进行的。对于错误检测部分,广泛应用于识别错误的3个战术是命令/响应、心跳和异常。错误恢复部分由准备恢复和修复系统两部分组成。主要使用的一些准备和修复战术有表决、主动冗余(热重启)、被动冗余(暖重启/双冗余/三冗余)、备件、shadow操作、状态再同步、检查点/回滚。错误预防战术主要有从服务中删除、事务、进程监视器。

为控制实现、测试和部署变更的时间和成本给出的可修改性战术。对在一定的时间限制内到达系统的事件生成一个响应的性能战术。与抵抗攻击有关、与检测攻击有关以及与从攻击中恢复的安全性战术。允许在完成软件开发的一个增量后,较轻松地对软件进行测试的可测试性战术。还有易用性战术,都是我们在设计师实践中学习到的经验。

在学习了设计师用于实现特定质量属性的战术集合后,可以明白的任何模式都会实现几个战术,这与不同的质量属性有关,但是该模式的任何实现都对战术做出了选择。

时间: 2024-11-10 08:27:22

04《软件构架实践第二版》阅读笔记之四的相关文章

UML大战需求分析——阅读笔记04

读<UML大战需求分析>有感04 开发某系统的重要前提是: 这个系统有谁在用? 这些人通过这个系统能做什么事? 一般搞清楚这件事,再画个业务流程图,就能条例清楚的表达系统的需求了.作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙. 用例图是用处非常广泛,使用频率最高的UML图,它用来描述什么角色通过某某系统能做什么事情,关注的是系统的外在表现.系统与人之间的交互.

UML大战需求分析——阅读笔记03

读<UML大战需求分析>有感03 状态机图和活动图在样子比较相似,但状态机图是用来为对象的状态及造成状态改变的事件建模.我们大二学习UML统一建模语言状态机图模块时了解到,UML的状态机图主要用于建立对象类或对象的动态行为模型,描述系统中某一个对象所经历的各个状态.引起状态或活动转移的事件,以及因状态或活动转移而伴随的动作.但在以前的学习过程中,我们并没有学到过"伪状态",后经查阅知:伪状态是指在一个状态机中具有状态的形式,同时具有特殊行为的顶点.它是一个瞬时状态,用于构造

UML大战需求分析--阅读笔记3

这次阅读的是第四章,流程分析利器之 – 活动图.对需求有两种分析的方式:结构建模与行为建模.活动图是行为建模中经常使用的一种图.由流程图发展而来. 活动图中有一些名词:开始状态.结束状态.活动.判断.监护.合并.泳道/分区.分叉.汇合.对象.对象流.控制流.连接件.动作等.开始状态与结束状态表示一个活动的开始和结束,开始状态用实心圆圈表示,结束状态用空心圆圈加上圆心点组合表示.活动和动作都是用圆角矩形表示,并且活动和动作都表示流程中的一个步骤,但是,活动表示的步骤可大可小,而动作表示的步骤不可分

《UML大战需求分析阅读笔记》05

我阅读了一个例子,一个软件公司采用.NET技术体系研发了一套电力系统,该系统使用的是SQL SERVER数据库.但安装系统时,客户发现该系统使用的数据库是SQL SERVER时,要求必须使用Oracle,如此一来,软件公司只能修改系统,这样的软件改动工作量是很大的.所以一定会需要软件技术框架,如果忽视了在软件技术框架.软件架构上的要求的话,会给软件后期工作带来想不到的麻烦.很多项目往往在初期就会对技术框架有一定的限制,常见的情况有:1.新项目需要在原系统的基础上开发:2.新项目需要与某些存在的系

04《火星——UML大战需求分析》阅读笔记之四

在上一章我看了UML大战需求分析分析中的类图,在上课中老师也提到了类图对于需求分析的重要性.其中在软件需求分析中重要的有:类图(结构建模是最常用的UML图).时序图.用例图.现在看着这一章虽然没有那么的重要,但是在软件需求分析中也有很重要的地位: 在书中提到活动图可能用来表达流程的最常用的一种UML图,是行为建模的重要工具之一.在这就会出现一个问题:如果我们想要做一个项目,我们就要问自己几个问题:1.没有应用系统的时候,系统是怎样运行的(事物内容和事物之间的关系/流程相关的问题)2.应用了系统后

05《火星——UML大战需求分析》阅读笔记之五

在从这,我们已经学习了两种 的图:类图.活动图.现在的状态机图我感觉和状态图很相.都会有起始的状态,结束的状态,状态. 就是因为状态机图以及活动图的相似,所以我们在写状态机图的时候,总是会和活动图相似: 怎样克服他们就是一回事: 1.  流程所围绕的事物是什么 2.  这个事物所处的状态是什么: 3.  当一个状态可以装换为两个或者两个以上状态的时候,可以表示为分支.比如:请假可以分为通过.不通过两种情况. 活动图中有很好的条件,状态机图中也有很好的图形,两者可以混用吗: 活动图的泳道,表示当中

02《火球——UML大战需求分析》阅读笔记之二

02<火球----UML大战需求分析>阅读笔记 在上一次的阅读笔记中,:我阅读的是开始部分和第一章,总结了其实UML不仅对于软件设计有很大的用处,对于软件的需求的分析也处于很高的地位.现在,读了第二章,真正的明白了UML对于需求分析的真正用处. 其实客户与我们所处的关系和医生与病人之间的关系,认识永远存在着偏差,就像对于用户和软件公司,对于需求的分析永远的存在着偏差.因为对于客户而言,每天的需求总是多变的,并且词不达意--à分析员的错误理解--à程序员的错误编码----à返回客户,客户的不满意

《uml大战需求分析》阅读笔记一

首次接触UML是去年的时候,当时是刘立嘉老师为我们讲授的,因为之前并没有接触到具体的项目,所以对UML这门课不是很重视,我想大多数人应该和我一样对UML没有给予足够的重视,这学期我们开设了软件需求分析这门课,又使我重新接触了UML,我选择阅读<UML大战需求分析>这本书来增强我对UML的理解. 根据作者所说他开始和我一样认为UML图并不能简化项目,反而成为了一个负担,但是在作者开始工作了以后渐渐了解UML对于项目的重要性,他可以明确的表达一个软件的功能,边界,交互过程.虽然没有学过UML的人并

《UML大战需求分析》阅读笔记01

在刚学习软件开发的课程时,首先学习了UML设计,但只是学习了基本的语法,虽然在学期通过课堂练习进行了实践,但并没有真正理解其中作用.为了进一步的理解UML的用法,我阅读了<UML大战需求分析>这本书,希望可以详尽的掌握UML语言. 首先我阅读了第一章,学习了什么时候使用什么图,并从整体的角度对各类图进行了认识.UML是一种语言,UML语言用于软件需求中更能直观的进行交流,易于理解.UML大体可以分为两类图:结构型的和行为型的.结构型的图描述的是某种结构在某段时间内具有固有的结构,是静态的:而行

2016年秋季-《UML大战需求分析》-阅读笔记2

<火球--UML大战需求分析>的第二章的语言很有趣,而且在开始介绍的地方有一个我们非常熟悉的一个关于"软件需求与分析"的案例,在从上大学的第一门课"信息科学技术导论"上,王老师给我们看过一张非常有趣的组图,讲的就是:客户需要的是一把梯子,系统分析员了解到的是一张凳子,开发人员做出来的是一张桌子,测试人员以为是一张椅子!需求分析是高难度和折腾人的工作,以一个示例全过程的了解需要的挑战.在通过这几天的阅读后我认为:软件需求分析存在的主要困难是由于角色的不同引