《软件构架实践》阅读笔记02

第三章讲述了一个构架案例分析,介绍了构架层次上的各种不同结构,即模块分解结构、使用结构和进程结构。这个案例说明了为实现构架的特定目标必须重视构架层次上的各种结构。该案例给我们两条经验:第一,信息隐藏式软件开发中可行的和明智的设计准则,第二,从实现系统质量指标的角度看,认真设计构架层次上的各种结构可以达到事半功倍的效果。

第四章《理解质量属性》,软件需求分析的其中一个任务就是定义软件的质量属性。对用户来说,重要的质量属性包括有效性、高效性、灵活性、安全性、互操作性、可靠性、健壮性和易用性等,对开发者来说重要的质量属性包括可维护性、可移植性、可复用性、可测试性和可理解性等。任何一个质量属性的实现都会对其他质量属性的实现带来积极或者消极的影响。在实际项目中,定量地描述用户期望的质量属性是很重要的。质量属性是很难定义的,并且他们经常造成开发者设计的产品和客户满意的产品之间的差异。

质量属性分为3类:

(1)系统的质量属性。可用性,可修改性,性能,安全性,可测试性和易用性。

(2)受构架影响的商业属性(上市时间)。

(3)与构架本身相关的一些质量属性(如概念完整性),它们会间接影响其他质量属性,如可修改性。

那么如何描述质量属性需求呢?一般采用质量属性场景作为一种规范。 质量属性场景是一种面向特定的质量属性的需求。它由6部分组成:刺激源、刺激、环境、制品、响应、响应度量。

实践中的质量属性场景了解了可用性、可修改性、安全性、可测试性、易用性、性能的一般场景。

时间: 2024-10-31 09:46:26

《软件构架实践》阅读笔记02的相关文章

《构建之法》阅读笔记02

<架构之美>阅读笔记02 今天,我读了<架构之美>第三.四章,第三章主要讲伸缩性架构设计,书中说设计系统架构时,要确保系统在伸缩时的弹性,根据书中的介绍我对系统伸缩性的理解是每个网站在不同时期都会有不同的访问量,有时会很多,有时会较少,当较多的人访问你的系统时,你可能需要数量较多的设备来满足用户与系统的交互,但当访问的用户越来越少时,系统伸缩性如果不够好,很多设备就会被浪费,不能够与系统分离,这对于软件开发者是不可取的.Darkstar项目就是由Sun公司实验室承担的一个将在架构的

《用户故事与敏捷开发》阅读笔记02

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

ijkplayer阅读笔记02

ijkplayer阅读笔记02 1.在这一章主要介绍音视频解码和显示线程的创建和启动,直接贴代码如下: IjkMediaPlayer_prepareAsync{ ijkmp_prepare_async_l{ ijkmp_change_state_l(mp, MP_STATE_ASYNC_PREPARING); msg_queue_start(&mp->ffplayer->msg_queue); SDL_CreateThreadEx(&mp->_msg_thread, mp

《需求分析与系统设计》阅读笔记02

在对于<需求分析与系统设计>第一章的阅读中我知道一个项目的成型的大致流程,一个软件的生命周期以及在不同的阶段我们应该采用什么样的方法.在不同的生命周期阶段当中我们应该做些什么,应该注意什么.对于一个软件的开发的方法. 对于第二.三章的精读之后了解到学习对象技术的主要困难在于缺乏明确的出发点和清晰的研究途径.没有像我们曾经了解的自顶向下或自底向上的一种学习方法.学习面向对象技术是一种“从中间出发”的方法.对于一个对象,我们首先要先确认实例对象,并且区分实例对象和类对象.那么关于对象呢,我们需要掌

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之一

<<需求分析与系统设计>>这本书论述了软件分析和设计的迭代增量式过程,讨论软件分析与设计的原理,方法和技术,并特别关注了设计阶段,对软件体系结构的内容进行了很大的扩充.本书强调对象技术与统一建模语言UML在企业信息系统开发中的应用,并讨论了使用web技术和数据库技术进行开发的方法.这本书集中在面向对象软件开发上,统一建模语言用于捕捉建模的人工制品,主要论述用逐步细化的方式进行开发,并且在整个开发生命周期中都是用UML这种建模语言.系统分析师,设计师和程序员使用同一种语言和工具,但有

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之三

终于把<需求分析与系统设计>读完了,感受很多,虽然理解还不是透彻,但还是学到了不少知识.在软件需求规格说明中,需要用图形和其他形式化模型来说明需求,为了完整地说明一个系统,有必要采取多种模型.UML提供了许多集成化的建模技术来辅助系统分析师来完成这项工作.规格说明的过程是迭代增量式的.对成功的建模来说,使用case工具是必须的.需求规格说明产生三种模型:状态模型,行为模型,状态变化模型.需求规格说明涉及需求确定期定义的客户需求进行严格的建模,重点放在那些系统将要提供的所期望的服务上.在规格说明

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

软件应能真正的对客户的工作提供帮助,只有客户使用并真正对其有用才能说我们做的软件成功了.客户从开始提出需求时到后期的工作过程中,需求总是不停变化的,所以这就需要需求人员对需求领先于客户.所以活用UML进行结构和行为建模,帮助我们更好的认识客户业务和做好业务流程再造工作.UML进行需求分析的过程: 搞清楚系统的目标和范围 找出该系统的所有关键涉众列出他们要解决的问题 分析业务,确认问题,发掘真正问题 针对问题,提出系统的特性 针对特性,提出系统的用例细化功能需求非功能需求 类图是用的最多的UML图

代码大全阅读笔记02

继续阅读代码大全这本书,感觉是好厚好难啃啊.刚刚开始读不久到了作者说把主要精力集中于构建活动,可以大大提高程序员的生产率.我想就一个项目来说,思路和设计是站着主导的地位的,你如果不能把思路理清,可能随时都有可能卡在那里,而一旦灵感来了,你就会想泉涌一样的来思路,我们也算是做了一个小的项目的了,虽然很low吧,但是好歹也算有点体会.我们总是在设计的时候会走投无路,不知所措,以至于每一次开始时都是没有思路起手都只能积压在那里,实在是不知道该怎么做.我觉得 P28 的那个食物链的例子更有说服力,健康的

人月神话阅读笔记02

贵族专制.民主政治和系统设计 本章主要是围绕着: 1.如何得到概念的完整性. 2.这样的观点是否要有一位杰出的精英,或者说是结构设计师的贵族专制,和一群创造性天分和构思被压制的平民编实现人员? 3.如何避免结构设计师产出无法实现.或者是代价高昂的技术规格说明,使大家陷入困境? 4.如何才能实现与实现人员就技术说明的琐碎细节充分沟通,以确保设计整备正确的理解并精确的整合到产品中? 就第一个问题文章是介绍的编程系统的目的是使计算机更加容易使用.对于功能,能够用最简洁的方式来指明事情的系统是最好的,对