Applying UML and Patterns Reading note

Part 3:

细化迭代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.5 UML应用：包图
UML包图通常用于描述系统的逻辑架构--层，子系统，包等。

13.6 准则：使用层进行设计
使用层的本质思想很简单：
将系统的大型逻辑结构组织为独立的，职责相关的离散层，具有清晰，内聚的关注分离。
协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合。

使用层有助于解决如下问题：
    源码的变更波及整个系统--大部分系统是高度耦合的。
    应用逻辑与用户界面交织在一起，因此无法复用于其他不同界面或分布到其他处理节点之上。
    潜在的一般技术服务和业务逻辑与特定于应用的逻辑交织在一起，因此无法被复用，分布到其他节点或
方便地使用不同实现替换。

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

定义：层，层和分区
    层在架构中最初表示的是逻辑层，而不是物理节点。  
    架构中的层表示对系统在垂直方向的划分，而分区（patition）则是表示对层在水平方向进行划分，形成相对平行的子系统。

  准则：不要将外部资源表示为最底层
    将外部资源表示为“低于”基层层的层，是对逻辑视图和架构部署视图的混淆

  就逻辑架构及其层而言，对某个持久数据集合的访问可以视为领域层中的子领域。而提供数据库访问
的一般性服务可以视为服务分区--持久性服务。

13.7 准则：模型-视图分离原则
其他包应该对UI层具有何种可见性？非窗口类应该如何与窗口通信？



第十四章：迈向对象设计

目标
       理解动态和静态对象设计建模
       尝试敏捷建模，或用于绘图的UML CASE工具

   绘图，然后建模


14.1 敏捷建模和轻量级UML图形
       一些敏捷建模的目标是减少常用图形，建模的目的是为理解和沟通而不是构建文档。可以尝试简单的敏捷建模方法，
这些实践包括使用大量白板或特制的白色塑胶静电贴片，使用白板笔，数码相机和打印机捕获“UML草图”。
       敏捷建模还包括：
       与其他人一同建模。
       并行创建若干模型。

       其他技巧如下：
       可以轻松地将数码相机捕获到的草图上传到内部的wiki上，这样可以记录项目信息。

14.2 UML CASE工具
       准则：
       选择能够与流行的文本增强型IDE集成的UML CASE。
       选择不仅能够对类图（比较常见）还能对交互图进行逆向工程的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.4 GRASP：基本OO设计的系统方法

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



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

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

新模式是一种矛盾修饰法

GOF关于设计模式的著作

GRASP 是一组模式或原则吗
       GRASP定义了9个基本OO设计原则或基本设计构件。



17.8
       创建者（Creator）
       信息专家（Information Expert）
       低耦合（Low Coupling）
       控制器（Controller）
       高内聚（High Cohesion）

创建者（Creator）
名称;创建者（Creator）
问题：谁创建了A？
解决方案：如果以下条件之一为真时（越多越好），将创建类A实例的职责分配给类B：
1） B“包含”或组成聚集了A
2） B记录A
3） B紧密地使用A
4） B具有A的初始化数据



信息专家
       问题：如果给定键值，谁知道square对象的相关信息？
       在对象设计中，信息专家模式是最基本的职责分配原则之一

       名称：信息专家（Information Expert）
       问题：给对象分配职责的基本原则是什么
       解决方案（建议）：把职责分配给具有完成该职责所需信息的那个类

低耦合
       问题：为什么是board而不是Dog？
      
       名称： 低耦合
       问题： 如何减少变化产生的影响
       解决方案：分配职责以使耦合保持在较低的水平。用该原则对可选方案进行评估。

      
控制器：
       名称：控制器
       问题：在UI层之上首先接收和协调系统操作的对象是什么？
       解决方案：
              把职责分配给能代表下列选择之一的对象：
              代表全部“系统”，“根对象”，运行软件的设备或主要的子系统
              代表发生系统操作的用例场景

      
高内聚:
       名称：高内聚
       问题：怎样使对象保持内聚，可理解和可管理，同时具有支持低耦合的附加作用
       解决方案：职责分配应保持高内聚，以此来评估备选方案。


GRASP的9种模式如下所示：
       创建者（Creator）       控制器（Controller）    纯虚构（Pure Fabrication）
       信息专家（Information Expert） 高内聚（High Cohesion） 间接性（Indirection）
       低耦合（Low Coupling）多态性（Polymorphisn）防止变异（Protected Variations）



best regards
eagle.guo