UML学习笔记

 

UML

统一建模语言　Unified Modeling Language

内容目录

1 面向对象分析和设计（OOA/D） 1

2 UP过程与“瀑布”模型 3

3 UML概览 4

4 需求分析与用例（用例图） 6

5 类图 8

6 领域模型（分析模型） 12

7 交互图（顺序图和协作图） 13

8 UML活动图 15

9 UML状态图 17

10 构件图 19

11 部署图 19

12 GRASP与GOF（设计模型） 20

12.1 附寻1－GRASP：基于职责设计对象 20

12.2 附录2　应用GOF设计模式 21

面向对象分析和设计（OOA/D）

课程目标

介绍如何将UML应用于UP过程

介绍如何应用UML进行OOA/D

UML不是OOA/D，也不是方法，它仅仅只是一种图形表示法

如果不掌握对象思想，那么UML或任何case工具（如ROSE）将毫无意义

我们需要一种用于OOA/D的语言，这既是一种思考的工具，也是一种沟通的形式，因此我们将在OOA/D中应用UML

分析（analysis) 对问题或需求的调查研究

设计（design)满足需求的概念上的解决方案

面向对象分析（object-oriented analysis) 在问题域内发现和描述对象

面向对像设计（object-oriented deign) 如何定义软件对象以及它们之间如何协作以及实现需求。

快速开始的示例

骰子游戏：软件模拟游戏者投掷两个骰子，如果总点数是７则赢得游戏，否则为输。

过程：定义用例－>定义领域模型－>定义交互图－>定义设计类图

定义用例(用例是需求分析的一种工具，它是一些情节的描述)

骰子游戏：

１.游戏者请求骰子

２.系统展示结果：如果骰子的总点数是７,则游戏者羸，否则游戏者输

定义领域模型（OOA）－识别问题中的概念，它是对真实世界领域中的概念和想像可视化，与具体实现的软件技术无关（比如ＪＡＶＡ或C#）

游戏者

骰子

骰子游戏

分配对象职责并绘制交互图（动态建模）

OOD关注的是：软件对象的定义－职责与协作　

定义设计类图（静态建模）

从领域模型以及交互图中获得启示，定义软件类，包括属性、方法等等

骰子游戏的局部设计类图示例如下：

什么是UML？

标准定义：统一建模语言（Unified Modeling Language,UML)是描述、构造和文档化系统制品的可视化语言。

UML是一个庞大的图形化表示法体系

应用UML三种方式

草图

蓝图

编程语言

学习UML要素

表示法－图形

过程－（UML与过程无关，但最好用于RUP）

工具－（比如：Rational Rose)

UP过程与“瀑布”模型

什么是UP？

软件开发过程(software development process)描述了构造、部署以及维护软件的方式。统一过程(the unified software development process)是一种流行的构造面向对象系统的迭代软件开发过程。特别是，Rational统一过程(rational unified process,RUP)是对统一过程的详细精化，并且己经被广泛采纳。

UP也可以引进其它方法中的有用的实践，比如极限编程(extreme programming,XP)、重构(refactoring)和持续集成(continuous integration)等。

什么是瀑布生命周期

试图在编程之前（详细）定义所有或大部分需求

而且通常于编程之前创建出完整的设计

试图在开始前定义“可靠的”计划或时间表

UML概览

UML包括：

事物

关系

图

扩展机制

事物

结构:类、接口、构件、节点等

行为：交互（消息）、状态等

分组：包、子系统等

注释：注释

关系：

依赖、关联（聚合、组合）、泛化、实现

图

用例图、交互图（顺序图、协作图）、类图、活动图、状态图等

扩展机制　stereotype、tagged value 、constraint

重要的概念及图形表示法初步接触1

重要的概念及图形表示法初步接触2

Rational Rose

Rational Rose是一种建模工具

用例视图

需求分析阶段的利器

逻辑视图

设计阶段，用例的实现

组件（构件）视图

构件表示了封装了其内容的系统模块：构件是相对独立的模块

部署视图

表示软件元素在物理架构上的部署，以及物理元素之间的通信

需求分析与用例（用例图）

需求：就是系统或者说是项目必须提供的能力和必须遵从的条件

需求分析的一种重要手段是：确定和编写用例

用例定义：

用例是文本形式的情节描述，用于需求的发现和记录。用例会影响后续OOA/D的工作

简单示例：

登录系统：管理员向系统提交用名户和密码。系统进行认证。系统向管理员显示成功登陆的消息。

参与者（actor）

某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如收银员

场景（scenario）是参与者和系统之间的一系列特定的活动和交互

主成功场景和交替场景（或主路径和扩展路径）

用例（use case）就是一组相关的成功和失败场景集合

系统边界

用例的目的与形式

谁使用系统？它们使用的典型场景是什么？它们的目的是什么？

用例编写的形式：

摘要－需求分析早期使用，通常用于主成功场景

非正式－需求分析早期使用，可覆盖不同的场景

详述－详细编写所有步骤及各各变化　

用例的名称应使用动词开头

编写用例的时候应尽量使用行业的专有名称，而不是计算机专业术语

用例的编写：

用例编号

用例名

用例描述

参与者

前置条件

后置条件

基本路径

1...

2...

3...

扩展点

2_1...

2_1_1...

补充说明

请参考文档示例的编写方法（大量用例）

如何发现用例？

１.选择系统边界

２.确定主要参与者

３.确定每个参与者的目标

４.定义满足用户目标的用例，根据其目标对用例命名

真实项目中如何发现用例？

请遵循如下思维习惯：

调研需求时最先弄清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，请他们类似的问题：你平时都做什么？（参与者目标）这件事是谁交办的？做完了你需要通知给谁或传达给谁吗？做这件事情你都需要填写些什么表格吗？（用例）

用例关联及一些术语

用例彼此之间可能具有联系，如何处理信用卡支付用例可作为处理销售、处理租金等常见用例的一部分。

注意：避免陷入用例关系的陷阱

别花过多时间争论用例中如何关联用例，而不关注更重要的工作，编写用例文件。

包含关系－主要目的是避免用例文本的重复编写

比如上面所说的，处理销售，处理租金等用例可包含处理信用卡支付用例

扩展关系－可以将可选路径中的场景抽象为扩展关系（但通常都是不必要的）

泛化关系－两个或更多用例在行为、结构、目的等方面存在共性时，可使用泛化关系

类图

UML类图

类图允许我们标记静态类及类之间的关系

类的基本表示法

名称

属性（类型，可见性）

方法（参数，返回值）

接口的基本表示法

圆形表示法

构造表示法

包

关系

依赖（一个事物的变化影响另外一个事物）

关联（关联名、导航、角色、多重性、聚合、组合）

泛化（extends）

实现（implements）

接口名称不换行－>options－>automatic resize

包

包可以用来表示层次结构（子系统）

包可以用来组织各种内容

依赖关系－从代码看起

依赖关系－真的有必要画出来吗？

要记住必要性是画图的重要原则，虽然有这种关系，但不一定要画出来，如果非要画出来，则应考虑不要影响图形的美观。

关联关系

ctr+D删除

可以customize加上双向关联的工具create an association class

聚合与组合　如果不清楚一般用聚合

飞机场与飞机是聚合关联

按钮与窗口是组合关联

泛化

实现

正向工程、逆向工程与MDA

正向工程：从UML图形生成JAVA

逆向工程：从JAVA代码生成UML

不要依赖于正向或逆向工程，仅是一种辅助手段

画图的目的不是为了生成代码

写代码的目的也不是为了生成图形

MDA？

模型驱动架构

Platform Independent Models(PIMs) 和Platform Specific Models(PSMs)

MOF－（UML－>元模型－>元-元模型）

什么时候使用类图？

任何时候

类图是UML中最重要的图形

不要尝试使用类图描述所有的细节

保持类图的简单

对概念建模（领域模型）

分析（分析类图）

实体类（领域模型）

控制类

边界类

领域模型（分析模型）

领域模型是OO分析中最重要的和经典的模型

领域模型（Domain model）也称概念模型、领域对象模型、分析对象模型，我们在对项目进行分析的时候，往往会创建相应的领域模型。

领域模型包括：概念、关联、属性

为什么要领域模型?

理解关键概念和词汇

逐步进入设计阶段（为进入设计阶段得到一些启示）

现实世界与软件实现之间的过度

如何创建领域模型？

寻找概念类（名词短语、分析模式）

绘制类图添加关联和属性

普通数据类型表示为属性

不要把复杂的领域概念建模为属性

请根据以下描述，画出相应的UML图

神州六号飞船是神州飞船系列的一种，它由轨道舱、返回舱、推进舱和逃逸救生塔等组成航天员可以在返回舱内驾驶飞船，轨道仓则是航天员工作和休息的场所。在紧急的情况下，可以得用逃生救生塔逃生。在飞船两侧有多个太阳能电池翼，可以为飞船提供电能

交互图（顺序图和协作图）

顺序图是交互图的一种

交互图还包括协作图

顺序图是强调消息时间顺序的交互图

协作图则是强调接收和发送消息的对象的结构组织的交互图

如何对动态方面建模？

所谓动态方面，即随着时间的推移，一些对象被创建，属性值的改变，以及其中一些对象的销毁，对象之间的互相调用！

对象

对象生命线

消息（实际上就是方法调用）

对象的创建与销毁

用例－－实现功能

基于Web的消息管理系统实例：用户登陆之后，可以给其它用户发送消息，也可以查询到其它用户发过来的消息！

如何创建概念模型？

如何确立多层架构？

如何给对象分配职责？

原则模式（经验）

顺序图实现

UML活动图

活动图（activity diagram）是UML的动态视图之一，用来描述事物或对象的活动变化流程

活动（Action）：是活动图主要结点，用两边为弧的条形框表示，中间填活动名。

活动分为简单活动和复合活动。

简单活动：不能再分解的活动。

复合活动：可以再分解的复杂活动。

活动流（Action Flow）：描述活动之间的有向关系，反映一个活动向另外一个活动之间转移。用带箭头的实线表示。

分支：表示活动流的分叉和合并。表示从一个活动按照某种条件转移到几个不同的活动。

分劈和汇合：表示并发的同步行为，用同步杆表示

泳道（swimlane）：是活动图中的区域划分，每一个泳道代表一个责任区域。一个泳道中包括一组相关活动。

对象流：反映活动与对象之间的依赖关系，表示对象对活动的作用或活动对对象的影响，用依赖关系表示。

UML状态图

状态图的概念

状态图（statechart diagram）用来描述一个特定的对象所有可能的状态，以及由于各种事件的发生而引起的状态之间的转移和变化

一个机器的状态图

一个发货单的状态图

构件图

构件的概念

构件（component）：是一个相对独立的可装配的物理块，一般作为一个独立的文件存在。

构件具有确定的接口，相互之间可以调用，构件之间存在依赖关系。

部署图

部署图(deployment diagram):用来描述系统中计算结点的拓扑结构和通信路径与结点上运行的软件构件等。

GRASP与GOF（设计模型）

附寻1－GRASP：基于职责设计对象

GRASP（General Responsibility Assignment Software Patterns）通用职责分配软件模式

创建者　谁应该负责创建某类的新实例？

信息专家　给对象分配职责的基本原则是什么？

低耦合　怎样降低依赖性，减少变化带来的影响，提高重用性？

控制器　在UI层上首先接收和协调（控制）系统操作的第一个对象是什么？

高内聚：怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？

多态：如何处理基于类型的选择?如何创建可插拔的软件构件？

纯虚构　当你并不想违背高内聚高耦合，但是基于专家模式所提供的方案又不合适时，哪　些对象应该承担这一职责？

间接性　为了避免两个或多个事物之间直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提高复用性潜力？

防止变异　如何设计对象、子系统和系统，使其内部的变化和不稳定性不会对其它元素不会产生不良的影响？

附录2　应用GOF设计模式

创建型模式

Abstract Factory

Builder

Factory Method

Prototype

Singleton

结构型模式

Adapter

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

行为模式

Chain of responsibility

Command

Interpreter