返回

UML和模式应用技巧分享 UML和模式应用读书笔记大全

时间:2016年12月21日 04:49评论:0

第一部分 绪论

1、在OO开发中,至关重要的能力是熟练地为软件对象分配职责;个人认为将对象进行抽象的能力也相当重要。

2、分析(analysis)强调的是对问题和需求的调查研究,而不是解决方案;设计(design)强调的是满足需求的概念上的解决方案(在软件方面和硬件方面),而不是其实现。

有益的分析和设计可以概括为:做正确的事(分析)和正确地做事(设计)。

xl

3、需求分析可能包括人们如何使用应用的情节或场景,这些情节或场景可以被编写成用例(use case)。

4、面向对象分析关注从对象的角度创建领域描述,面向对象分析需要鉴别重要的概念、属性和关联。面向对象分析的结果可以表示为领域模型,在领域模型中展示重要的领域概念或对象。

5、面向对象设计关注软件对象的定义-它们的职责和协作。

6、与领域模型表示的是真实世界的类,设计类图表示的是软件类。

7、敏捷建模(agile modeling)强调了UML作为草图的方式,这也是适用UML的普通方式,而且通常对时间投入具有高回报(一般费时较短)。

8、迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中,开发被组织成一系列固定的短期(如三个星期)小项目,称为迭代(iteration),每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。

9、迭代开发的优点包括:

10、在复杂、变更系统中(如大多数软件项目),反馈和调整是成功的关键要素。

11、如何进行迭代和进化式分析和设计:

1)在第1次迭代之前,召开第一个时间定量的需求工作会议,例如确切地定义为两天时间,业务和开发人员(包括首席架构师)需要出席。

2)在第1次迭代之前,召开迭代计划会议,选择上述三个用例的子集,在特定时间内(例如,四周的时间定量迭代)进行设计、构造和测试。

3)在三到四周内完成第1次迭代(选择时间定量,并严格遵守时间):

4)在第1次迭代即将结束时(如最后一周的星期三和星期四),召开第二次需求工作会,对上一次会议的所有材料进行复查和精化,然后选择具有重要架构意义和高业务价值的另外10%到15%的用例,用一到两天对其进行详细分析。

5)于周五上午,举行下一迭代的迭代计划会议。

6)以相同步骤进行第2次迭代。

7)反复进行四次迭代和五次需求工作会,这样在第4次迭代结束时,可能已经详细记录了大约80%-90%的需求。

8)我们大概推进了整个项目过程的20%。此时,可以估计这些精化的、高质量的需求所需工作量和时间。因为具有依据现实得出的调查、反馈结论并进行了早期编程和测试,因此估计能够做什么和需要多长时间的结果会更为可靠。

9)此后,一般不需要再召开需求工作会;需求已经稳定了(尽管需求永远不会被冻结)。接下来是一系列为期三周的迭代,在最后一个周五召开的迭代计划会上选择适宜的下一步工作,每次迭代都要反复询问:“就我们现在所知,下一个三周应该完成的、最关键的技术和业务特性是什么?”

利用这种方式,经过早期探索式开发的几次迭代之后,团队将能够更准确地回答“什么、多少、何时”。

12、建模(构建UML草图……)的目的主要是为理解,而非文档。

第二部分 初始阶段

1、用一句话来概括初始阶段:预见项目的范围、设想和业务案例。用一句话来概括初始阶段要解决的主要问题:涉众是否就项目设想基本达成一致,项目是否值得继续进行认真研究。

2、需求分析的最大挑战是寻找、沟通和记住(通常是指记录)什么是真正需要的,并能够清楚地讲解给客户和开发团队的成员。

3、在统一过程中,需求按照“FURPS+”模型进行分类,这是一中有效的记忆方法,其含义如下:

”FURPS+“中的”+“是指一些辅助性的和次要的因素,比如:

若想从生活中得到什么,必不可少的第一步就是:决定想要什么。 -本。斯坦(Ben Stein)

4、用例是文本形式的情节描述,广泛应用于需求的发现和记录工作中。

5、用例是一种优秀的方法,使领域专家或需求提供者自己编写(或参与编写)用例成为可能,并使这项工作难度降低。

第三部分 细化迭代1 基础

1、细化(elaboration)是一般项目中最初的一系列迭代,其中包括:

细化阶段是最初的一系列迭代,在这一阶段,小组进行细致的调查、实现(编程和测试)核心架构、澄清大多数需求和应对高风险问题。

2、在细化阶段可能出现的一些关键思想和最佳实践包括:

3、通过关联而不是属性来表示概念类之间的关系。

4、没有所谓唯一正确的领域模型。所有模型都是对我们试图要理解的领域的近似。领域模型主要是在特定群体中用于理解和沟通的工具。

5、在同一层内的对象在职责上应该具有紧密关联,不同层中对象的职责则不应该混淆。

6、需要哪些对象,它们如何通过消息和方法进行协作,通过动态对象建模(例如绘制顺序图)才能真正落实这些准确和详细的结论。

7、应该把时间花费在交互图(顺序图或通信图),而不仅是类图上。

8、任何顺序图都可以使用sd图框围绕起来,并对其命名。当你想要引用相应名字的sd图框时,可以使用ref图框。

9、在类图中,使用依赖线描述对象之间的全局变量、参数变量、局部变量和静态方法(对其他类的静态方法加以调用)的依赖。

10、GRASP是通用职责分配软件模式(General Responsibility Assignment Software Patterns)的缩写。GRASP的9个模式如下所示:

创建者(Creator)

如果以下的条件之一(越多越好)为真时,将创建类A实例的职责分配给类B:

注意:对象的创建常常具有相当的复杂性,这时最好的方法是把创建职责委派给称为具体工厂(Concrete Factory)或抽象工厂(Abstract Factory)的辅助类,而不是使用创建者模式所建议的类。

信息专家(Information Expert)

把职责分配给信息专家,它具有实现这个职责所必需的信息。分配职责应当从清晰地描述职责开始。

注意:由于耦合与内聚问题导致某些情况下,专家模式建议的方案并不合适。

低耦合(Low Coupling)

分配职责,使耦合性尽可能低。利用这一原则来评估可选方案。

控制器(Controller)

控制器是UI层之上的第一个对象,它负责接收和处理系统操作消息。 

高内聚(High Cohesion)

内聚(或更为专业地说,是功能内聚)是对元素职责的相关性和集中度的度量。

多态性(Polymorphism)

纯虚构(Pure Fabrication)

间接性(Indirection)

防止变异(Protected Variations)

相关文章
猜你喜欢
用户评论