Applying UML and Patterns Reading note

dalang 2010-01-20

Part3:

细化迭代1--基础

第8章:迭代1-基础

定义细化阶段的第一个迭代

为本部分的后继章节做铺垫

描述初始细化阶段的关键内容

8.1迭代1的需求和重点:OOA/D技术的核心

在这些案例研究中,细化阶段的迭代1强调的是基础。

在up项目中,我们应该首先处理困难和具有风险的事项。

在迭代开发中,我们并非一次就实现所有需求

在多个迭代对同一用例进行增量式开发

8.2初始和细化

在初始阶段发生了什么

初始阶段是迈向细化阶段的一小步。

初始阶段中可能的活动和制品包括

简短的需求讨论会

大多数参与者,目标和用例的名称

大多数以摘要形式编写的用例。

确定大多数具有影响和风险的质量需求

编写设想和补充性规格说明的第一个版本

风险列表

技术上的概念验证原型和其他调查,用以揭示特殊需求的技术可行性。

面向用户界面的原型

对购买/构建/复用构件的建议,在细化阶段进行精化

对候选的高层架构和构件给出建议。

细化之所在

细化(elaboration)

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

细化阶段通常由两个或多个迭代组成,建议每次迭代的时间是2~6周。

细化不是设计阶段,在该阶段也不要完成所有模型的开发

在细化阶段不是创建可以丢弃的原型。

用一句话来概括细化:构建核心架构,解决高风险元素,定义大部分需求,以及预计总体进度和资源

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

实现短时间定量,风险驱动的迭代。

及早开始编程。

对架构的核心和风险部分进行适应性的设计,实现和测试。

尽早,频繁,实际地测试

基于来自测试,用户,开发者的反馈进行调整。

通过一系列讨论会,详细编写大部分用例和其他需求,每个细化迭代举行一次。

在细化阶段会开始构建哪些制品

制品说明

领域模型领域概念的可视化,类似于领域实体的静态信息模型

设计模型描述逻辑设计的一组图,包括软件类图,对象交互图,包图

软件架构文档学习辅助工具,概念关键架构问题及其在设计中的解决方案。该文档是对重要设计思想及其在系统中的动机的概要

数据模型包括数据库方案,以及在对象和非对象表示之间映射的策略

用例示意板,用户界面原型描述用户界面,导航路径,可用性模型等

8.3过程:计划下一个迭代

几乎和项目管理是重要且涉及广泛的主题。

风险既包括技术复杂性,也包括其他因素。

覆盖范围

关键程度

第九章:领域模型

目标:

确定与当前迭代相关的概念类

创建初始的领域模型

为模型建立适当的属性和关联

简介

领域模型是OO分析中最重要的和经典的模型。它阐述了领域中的重要概念。领域模型可以作为设计某些软件对象的灵感来源,也可以作为在案例研究中

所探讨的几个制品的输入。

领域模型也是可选制品。领域模型的范围现定于当前迭代所开发的用例场景,领域模型能够被不断地演进用以展示相关的重要概念。

9.2什么是领域模型

这一精髓的面向对象分析步骤是从领域到重要概念或对象的分解。

领域模型是对领域内的概念类或实现世界中对象的可视化表示,领域模型也称为概念模型,领域对象模型和分析对象模型

UP对领域模型的定义是,可以在业务建模科目中创建的制品之一。UP领域模型是UP业务对象模型(BOM)

应用UML表示法,领域模型被描述为一组没有定义操作的类图。它提供了概念透视图。它可以展示:

领域对象或概念类

概念类之间的关联

概念类的属性

定义:为什么把领域模型称为“可视化字典”

领域模型是可视化字典,表示领域的重要概念,领域词汇和领域的内容信息。

定义:领域模型是软件业务对象吗?

不是。

以下元素不适用与领域模型

软件制品,例如窗口或数据库

职责或方法

定义:“领域模型”的两个传统含义

1.“领域模型”是现实世界中对象的概念透视图

2.在表示层或UI层之下的软件对象层是由领域对象组成的

定义:什么概念类

概念类是思想,事物或对象

定义:领域模型和数据模型是一回事吗

不是一回事

9.3动机:为什么要创建领域模型

降低与OO建模之间的表示差异

9.4准则:如何创建领域模型

以当前迭代中所要设计的需求为界

1)寻找概念类

2)将其绘制为UML类图中的类

3)添加关联和属性

9.5准则:如何找到概念类

找到概念类的三条策略

1)重用和修改现有的模型

2)使用分类列表

3)确定名词短语

重用现有的模型是最好的做法,使用分类列表也很有效

重用现有模型:在许多常见领域中都存在已发布的,绘制精细的领域模型和数据模型(可以修改为领域模型),这些领域包括库存,金融,卫生等等。

使用分类列表:

概念类分类列表

概念类的类别

业务交易

交易项目

与交易或交易项目相关的产品或服务

交易记录于何处

于交易相关的人或组织的角色;用例的参与者

交易的地点:服务地点

重要事件:通常包括我们需要记录的时间或地点

物理对象

事物的描述

类别

事物的容器

容器中的事物

其他协作的系统

金融工作合约法律材料的记录

金融手段

执行工作所需的进度表,手册,文档等

通过识别名词短语寻找概念类

另一种有效的技术是语言分析,即在对领域的文本性描述中识别名词和名词短语,将其作为候选的概念类或属性。

9.6示例:寻找和描绘概念类

9.7准则:敏捷建模—绘制类图的草图

让类框的底部和右侧呈开放状态

9.8准则:敏捷建模—是否要使用工具维护模型

问问自己:谁要使用这些更新的模型?为什么?如果不存在实际的理由,则无需多此一举

9.9准则:报表对象—模型中是否要包括“票据”

以下是一些需要考虑的因素

一般来说,在领域模型中显示其他信息的报表并没有意义,因为其所有信息都是源于或复制于其他信息源的。

另一方面,就业务规则而言,它有特殊的作用:通常持有票据的人有退货的权利,这是模型中要表示它的理由

9.10准则:想地图绘制者一样思考;使用领域术语

9.11准则:如何对非现实世界建模

9.12准则:属性和类的常见错误

准则:如果我们认为某概念类X不是现实世界中的数字或文本,那么X可能是概念类而不是属性。

9.13准则:何时使用“描述”类建模

描述类包含描述其他事物的信息

动机:为什么使用描述类

准则:何时需要描述类

9.14关联

第十章:

系统顺序图

确定系统事件

为系统场景创建系统顺序图

系统顺序图是为阐述与所讨论系统相关的输入和输出事件而快速,简单地创建的制品

它们是操作契约和对象设计的输入。

UML包含以顺序图为形式的表示法,用以阐述外部参与者到系统的事件。

用例文本及其所示的系统事件是创建SSD的输入。SSD中的操作可以在操作契约中进行分析,在词汇表中被详述。

10.2

什么是系统顺序图

第13章逻辑架构和UML包图

目标:

介绍使用层的逻辑架构

阐述使用UML包图的逻辑架构

13.2什么是逻辑架构和层

逻辑架构是软件类的宏观组织结构

它将软件类组织成包,子系统和层

层是对类,包,子系统的甚为粗粒度的分组,具有对系统主要方面加以内聚的职责。

OO中通常包括的层有:

用户界面层

应用逻辑和领域对象

表示领域概念的软件对象,这些对象实现了应用需求。

技术服务

提供支持性技术服务的常用对象和子系统,例如数据库接口或错误日志。这些服务通常

独立于应用。

在严格的分层架构中,层只能调用与其相邻的下层服务。在信息系统中通常使用宽松的分层架构

13.4什么是软件架构

架构是一组重要决策,其中涉及软件系统的组织,对结构元素及组成系统所籍接口的选择,这些元素特定于其相互协作的行为,

这些结构和行为元素到规模更大的子系统的组成,以及指导该组织结构。

13.5UML应用:包图

UML包图通常用于描述系统的逻辑架构--层,子系统,包等。

13.6准则:使用层进行设计

使用层的本质思想很简单:

将系统的大型逻辑结构组织为独立的,职责相关的离散层,具有清晰,内聚的关注分离。

协作和耦合是从较高层到较低层进行的,要避免从较低层到较高层的耦合。

使用层有助于解决如下问题:

源码的变更波及整个系统--大部分系统是高度耦合的。

应用逻辑与用户界面交织在一起,因此无法复用于其他不同界面或分布到其他处理节点之上。

潜在的一般技术服务和业务逻辑与特定于应用的逻辑交织在一起,因此无法被复用,分布到其他节点或

方便地使用不同实现替换。

不同的关注领域之间高度耦合

定义:层,层和分区

层在架构中最初表示的是逻辑层,而不是物理节点。

架构中的层表示对系统在垂直方向的划分,而分区(patition)则是表示对层在水平方向进行划分,形成相对平行的子系统。

准则:不要将外部资源表示为最底层

将外部资源表示为“低于”基层层的层,是对逻辑视图和架构部署视图的混淆

就逻辑架构及其层而言,对某个持久数据集合的访问可以视为领域层中的子领域。而提供数据库访问

的一般性服务可以视为服务分区--持久性服务。

13.7准则:模型-视图分离原则

其他包应该对UI层具有何种可见性?非窗口类应该如何与窗口通信?

第十四章:迈向对象设计

目标

理解动态和静态对象设计建模

尝试敏捷建模,或用于绘图的UMLCASE工具

绘图,然后建模

14.1敏捷建模和轻量级UML图形

一些敏捷建模的目标是减少常用图形,建模的目的是为理解和沟通而不是构建文档。可以尝试简单的敏捷建模方法,

这些实践包括使用大量白板或特制的白色塑胶静电贴片,使用白板笔,数码相机和打印机捕获“UML草图”。

敏捷建模还包括:

与其他人一同建模。

并行创建若干模型。

其他技巧如下:

可以轻松地将数码相机捕获到的草图上传到内部的wiki上,这样可以记录项目信息。

14.2UMLCASE工具

准则:

选择能够与流行的文本增强型IDE集成的UMLCASE。

选择不仅能够对类图(比较常见)还能对交互图进行逆向工程的UML工具。

14.3编码前绘制UML需要花费多少时间

14.4设计对象:什么是静态和动态建模

对象模型有两种类型:动态和静态。动态模型有助于设计逻辑,代码行为或方法体,(顺序图或通讯图)

动态模型倾向于创建更为有益,困难和重要的图形。静态模型有助于设计包,类名,属性和方法的特征标记的定义。

静态和动态建模之间具有关系,敏捷建模对此的实践是并行创建模型:花费较短的时间创建交互图,然后转到对应的类图,交替进行。

动态对象建模

准则:

应该把时间花费在交互图,而不是类图上。

忽视这一准则是十分常见的UML错误实践。

在应用职责驱动设计和GRASP原则的动态建模过程中,这一准则尤为重要。

UML工具集中还有其他动态工具,包括状态机图和活动图

静态对象建模

最常见的静态对象建模是使用UML类图。

如果开发者应用了并行创建若干模型的敏捷建模实践,则他们应该同时绘制交互图和类图。

UML中支持静态建模的其他制品包括包图和部署图。

14.5对象设计技能比UML表示法技能更重要

对象设计技能与UML表示法技能

绘制UML反映了对设计作出的决策。

对象设计技术并不一定要了解如何绘制UML

基本的对象设计需要了解的是:

职责分配原则

设计模式

14.6其他对象设计技术:CRC卡

类职责协作(CRC)卡是流行的面向文本建模技术

CRC卡是纸质的索引卡片,其中记录了类的职责和协作。在CRC建模活动中,一组人围坐桌旁讨论编写卡片,他们通过

“如果。。。怎样”的对象场景,考虑对象必须做什么,以及必须与那些其他对象协作。

第15章:UML交互图

目标:

为快速使用UML交互图表示法提供参考。

UML使用交互图来描述对象间通过消息的交互。交互图可以用于动态对象建模。交互图有两种类型:顺序图和通信图。

第16章:UML类图

迭代的是人,递归的是神

目标:

为快速使用UML类图表示法提供参考

第17章:GRASP:基于职责设计对象

理解职责是顺利进行面向对象设计的关键

目标:

学习使用面向对象设计的5个GRASP原则或模式

17.1:UML与设计原则

最关键的软件开发工具是受过良好设计原则训练的思维,而不是UML或任何其他技术。

17.2:对象设计:输入,活动和输出的示例

已经完成了哪些活动?

事物之间具有什么样的关系

需要完成多少设计建模工作

有哪些输出

对象设计的输入是什么?它们与对象设计有什么样的关系?

用例文本

补充规格说明

系统顺序图

词汇表

操作契约

领域模型

这些制品不一定都是必要的。在UP中所有元素都是可选的,也许是为了降低某种风险而创造的。

对象设计中的活动

既要画出交互图,又要画出补充性的类图,在绘图过程中我们要应用各种OO设计原则,如GRASP和GoF设计模式

有哪些输出?

针对设计中的难点创建UML交互图,类图和包图。

UI的草图和原型

数据库模型

报表的草图和原型

17.3职责和职责驱动设计

思考软件对象设计以及大型构建的流行方式是,考虑其职责,角色和协作。这是职责驱动设计的大型方法的一部分。

UML把职责定义为:类元的契约或义务。职责分为以下两种类型:行为和认知

对象的行为职责包括:

自身执行一些行为:如创建对象或计算

初始化其他对象中的动作

控制和协调其他对象中的活动

对象的认知包括:

对私有封装数据的认知

对相关对象的认知

对其能够导出或计算的事物的认知

在对象设计中,职责被分配给对象类。

准则:对于软件领域对象来说,由于领域模型描述了领域对象的属性和关联,因此其通常产生与认知相关的职责。

职责的粒度会影响职责到类和方法的转换。

职责与方法并非同一事物,职责是一种抽象,而方法实现了职责。

17.4GRASP:基本OO设计的系统方法

GRASP:使用职责进行OO设计的学习工具

17.5职责,GRASP和UML图之间的联系

17.6什么是模式

如果以结构化形式对这些问题,解决方案和命名进行描述使其系统化,那么这些原则和习惯用法就可以称为模式。

新模式是一种矛盾修饰法

GOF关于设计模式的著作

GRASP是一组模式或原则吗

GRASP定义了9个基本OO设计原则或基本设计构件。

17.8

创建者(Creator)

信息专家(InformationExpert)

低耦合(LowCoupling)

控制器(Controller)

高内聚(HighCohesion)

创建者(Creator)

名称;创建者(Creator)

问题:谁创建了A?

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

1)B“包含”或组成聚集了A

2)B记录A

3)B紧密地使用A

4)B具有A的初始化数据

信息专家

问题:如果给定键值,谁知道square对象的相关信息?

在对象设计中,信息专家模式是最基本的职责分配原则之一

名称:信息专家(InformationExpert)

问题:给对象分配职责的基本原则是什么

解决方案(建议):把职责分配给具有完成该职责所需信息的那个类

低耦合

问题:为什么是board而不是Dog?

名称:低耦合

问题:如何减少变化产生的影响

解决方案:分配职责以使耦合保持在较低的水平。用该原则对可选方案进行评估。

控制器:

名称:控制器

问题:在UI层之上首先接收和协调系统操作的对象是什么?

解决方案:

把职责分配给能代表下列选择之一的对象:

代表全部“系统”,“根对象”,运行软件的设备或主要的子系统

代表发生系统操作的用例场景

高内聚:

名称:高内聚

问题:怎样使对象保持内聚,可理解和可管理,同时具有支持低耦合的附加作用

解决方案:职责分配应保持高内聚,以此来评估备选方案。

GRASP的9种模式如下所示:

创建者(Creator)控制器(Controller)纯虚构(PureFabrication)

信息专家(InformationExpert)高内聚(HighCohesion)间接性(Indirection)

低耦合(LowCoupling)多态性(Polymorphisn)防止变异(ProtectedVariations)

bestregards

eagle.guo

相关推荐