UML 学习

本文是赖信仁的《UML团队开发流程与管理》的学习笔记

第一部分UML介绍

本部分以一个医院的住出院登记系统为例，介绍UML中的各种图的概念。

角色:

系统分析师ra(resources analysis),架构师sa(software architecture),项目管理师pm,领域代表de(domain expert),操作人员op(operator),程序员se(software engineer)

1 需求获取:

• 活动描述

参与者:ra,de;
任务:获取整体的业务流程;
活动:ra与de进行前期沟通,通过用例捕捉需求
结果:通过uml中的活动图绘制主业务流程,绘制用例图;

• 要点:

1) 前期访谈不要陷入细节,注重流程的完整性,细节在用例中捕捉.
2) 了解现有系统;
3) 适用的技术条件;
4) 项目成功的关键因素.

• 关于活动图

1)活动图使用的时机:需求阶段与de的沟通桥梁;系统集成测试阶段作为参考依据;使用维护阶段作为维护业务过程.
2)活动图是表达活动与活动之间流程控制的转移.活动图捕获主要流程,注重流程的完整性,不要在开始陷入细节,细节在用例中捕捉..
3)活动图中元素:开始,结束,分支(条件),迁移(顺序),分叉(并行),汇合(并行),分区(角色或对象,又称泳道).
4)活动图中不要复用活动.
5)活动图中尽量不要出现文件.

• 关于用例

1)用例是由一系列处置构成,能够使系统外用户(人员或系统)使用系统而完成一个完整期望.用例的本质是满足客户的需求.
2)用例的形成可以通过与用户的沟通去发掘,然后绘制流程图,序列图等,这是UML发明者推荐的方法.或者,由于用例同时要满足管理的需求(业务流程),所以也可以通过主业务流程去发掘用例(这是一个过程),本书采用后者方式.
3)用例是描述目的而不是设计.
4)用例模型包括用例图和用例描述;用例描述包括正常流和异常流,在前期可描述正常流.用例描述采用主语+动词+名词结构.
5)用例图中的元素:角色(人或系统),边界,用例;用例图中元素的关系包括:关联,泛化.需要指出的是如果从用例指向边界外对象,则该对象必须和系统处于同一级别.

2 系统设计:

• 活动描述

参与者:ra,de,sa,se,pm
任务:表达系统内部结构
活动:sa与de沟通建立领域模型,内部沟通决定实现用例的优先级.
结果:通过类图表达领域模型(静态模型),通过序列图表达系统动态模型

• 关于领域模型:

1)所谓模型就是对事物本质的描述,本质是指解决问题的核心.领域模型是领域问题域的抽象表达方式.
建立领域模型,首先要定义清楚领域问题域:人,物,时,地,事.数据是问题域模型的一方面而不是全部.在结构化程序设计中通过数据字典,数据流图建立模型.
在数据库系统中,通过ER图建立模型.面向对象设计通过类,序列图等建立模型.
2)通过类图建立领域模型的静态结构.类图是表达领域模型的重要元素.
3)对于信息系统,通常以事件为中心,找出相关的人,物,地形成领域模型(交易模型).
在与de沟通的过程中要围绕这个展开讨论”中心事件->关联的人,物,地”

• 关于类图:

1)类图中元素:类(类包括名称,属性,操作),.类之间关系(包括:关联,整体与部分(聚集,组合),泛化,依赖,多重性).
2)绘制类图,首先建立一个核心类,然后围绕其建立其他类.

• 关于序列图:

1)序列图表达的是如何利用领域模型中的对象来实现用例中的需求;是系统的动态模型.
2)序列图的作用:表达设计人员心目中对象的协作,验证领域模型的正确性,为程序员建立程序蓝图.
3)序列图元素:对象,消息,时间线.
4)通信图(协作图)是表述对象之间关系的另外一种方式,通常可以与序列图转换.但是通讯图可以更直观的表达对象之间的关系,让设计人员聚焦领域模型.

3 细节设计:

对于设计的细节表述,包括对象图,状态图,时间图.是系统在特定条件下的表述(时间,条件)

• 关于对象图:

1)对象图中元素:对象,对象之间的关系(关联)

• 关于状态图:

1)状态图中元素:对象,迁移

• 关于时间图:

1)时间图中元素:状态,时间线,转换条件

4 宏观设计:

• 关于总则图:

凝聚共识

• 关于包图:

命名空间,封装.包内高内聚,包外松耦合.

• 关于交互概述图:

正常流,替代流,异常流之间的关系.

• 关于组合结构图:

1)用于描述系统之间的关系;
2)元素:系统,端口,接口,关系

5 部署与实现:

• 关于组件图:

1)用于描述组件之间的关系;
2)元素:组件,接口,依赖关系

• 关于部署图:

1)描述软件与计算机之间的关系;
2)元素:组件,节点,依赖关系.

第二部分电子信息化采购系统实例

6 需求收集阶段-发现用例和建立业务流程

• 业务描述

• 过程:

UML创立者认为用例具有目标导向作用,所以通过用例来完善业务流程(领域代表不太接受用例表述).另外一种发现需求的方法是通过业务流程来发掘用例,但是往往忽略目的性.扩展流程方法发现企业主业务过程(不讨论细节),
然后通过活动图细化主业务流程,发现用例.
扩展模型元素:处理、事件（触发）、参与人、消息、对象、参与者、目标、依赖关系、参与关系、实现关系；

传统的设计方法认为需求必须是完整的，现代的方法认为需求是对系统的验证，系统必须尽可能满足变化的需求。
用例可以从两个角度来看：从外部角度看是满足用户的一个完整期望，从内部角度看是系统能够提供的服务。

通过扩展模型找出主要处理，通过每个处理细化（活动图）找出业务流程，通过对业务流程中每个活动询问以下问题找出系统用例：
1).谁使用这个活动(主要参与者)?
2).需要系统提供服务吗?
3).需要这个活动提供何种服务?
4).需要其他系统服务吗?
对于找出的用例进行用例描述(场景),用例描述包括正常流,替代流,异常流.正常流是业务的主要部分,尽可能使替代流,异常流简单,可以通过迭代实现其他流.
建立正常流后可以设计测试案例.

• 要点:

绘制活动图尽量不要描述文件(在扩展模型中体现);
用例描述采用主语+动词+名词结构;
举例:
主参与者提供某些信息给系统;
系统做第一件事
系统做第二件事
主参与者提供另外一些信息给系统;
系统做第一件事
系统做第二件事
…

7 实现用例-建立模型:

软件设计的重要原则:不是要单个复用,而是整体复用,使得单个组件容易被替换,从而使得整个系统实现复用.弹性与稳定架构是软件设计追求的目标.

7.1 建立领域模型：

每个用例代表系统提供给使用者功能接口.在UML中,区分不同的对象,对于实现模型中的不同工作是重要的,为此我们可以分辨出控制对象,实体对象和接口对象.

控制对象包括一个或多个用例的功能;实体对象包括对信息的存取;接口对象包括系统的接口的相关功能.

• 关于控制对象:

通过正常流的描述,我们可以建立控制对象.对于每一个由主参与者分隔开来的描述我们可以将它作为系统提供的一个服务(单一服务,作为设计的原则单一职责每个服务尽可能单一).
服务的命名:取自每个服务的最后描述;
输入参数取自主参与者提供的信息,输出参数取自服务的最后描述;
中间的以系统为主语的描述是系统内部的功能;在内部功能中可以描述过程的伪代码,作为下一阶段编码的蓝图.

• 关于实体对象:

实体对象是业务中稳定部分，也是核心部分。
通过交易模式可以有助于我们找出实体对象.交易模式是以事件为中心,发现围绕其的人、物、地。根据Peter Coad著述，人可以分成具体角色和参与者，事可分为交易细项，后续交易
后续交易细项，物可分为物和具体物。并可分成角色-参与者等9种模式。实际运用中，并非这些元素都要用到。

7.2 建立交互图：

交互图是利用对象实现用例的表述；

总结：实现用例过程可以包括以下几步：

1）通过对用例和用例描述分析找出控制对象，操作；
2）通过交易模式找出实体对象；
3）通过交互图验证控制对象分析；

8 物理设计-PIM->PSM->SouceCode

建立好模型之后,如何转换成实际代码.现代软件有各种平台比如Java,C,C++,.Net,我们不太可能熟悉所有平台.MDA(Model Driven Architecture)是一种基于模型的架构模式.
下图是OMG组织定义的MDA架构.从该图我们可以看到最内层是基于UML等的模型,中间是各种平台工具,最外层是各种应用.OMG希望通过定义的MDA规则,可以使得model**自动的**转换成各种平台语言.为了达到这一目标,OMG定义了标准的转换过程:

PIM-platform Independent Model:平台无关模型;

PSM-platform Specific Model:平台相关模型;

Source Code :平台相关代码,由PSM转换而来.

现代的各种UML设计工具支持以上的MDA过程(比如EA,RationalRose,StarUML等).

就软件框架来说现代比较流行的是三层模型:表示层,领域层,数据层.

就开发平台来说.Net和Java是两大主要开发平台,分别有不同的组件支持以上的软件框架;

.Net平台框架:

spring平台框架:

9 代码重构

• 重构的时机

在项目的开始阶段,如果迫于时间的压力可以留下todo.

• 重构的方法

一般原则:单个函数不要超过20行,尽量不要用if then else;

结构的重构:与设计模式相关.