内容提纲:
1.UML概述
1.1 UML的定义
2. UML的组成
2.1 UML的三个基本构造块
2.1.1 事物
2.1.2 图
2.1.3 关系
3.UML中建模的机制
4.UML中图的使用
4.1 用例图
4.1.1 组成
4.1.2 用例间的关系
4.1.3 如何发现用例
4.2.类图
4.2.1 类和对象
4.2.2 类的组成
4.2.3 类之间的关系
4.2.4 类图
4.2.5 如何发现类
4.3 序列图(Sequence图)
4.3.1 定义
4.3.2 组成
4.4 活动图
4.4.1 定义
4.4.2 组成
4.5 状态图
1.UML概述
![]() | |
| ![]() |
UML是随着面向对象的分析和设计方法(OOA&D)的出现而出现的。最早的面向对象建模语言出现在70年代中期,随后数量越来越多,其中最著名的是Booch 1993(Booch)、OOSE(Jacobson)和OMT-2(Rumbaugh)。为了将各种各样的建模语言统一起来,建立一个统一的建模语言,这三位建模语言大师聚到一起工作,将各自的理论和方法结合在一起,从而形成了“统一建模语言(Unified Model Language)”,简称UML。下面这张图形象的说明了UML的发展历程。
UML是一种通用的可视化建模语言,是一种标准化的用图形方式来建模(建立模型)的语言,是面向对象分析和设计的一种表示。它用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。UML能够描述系统的静态结构和动态行为:静态结构定义了系统中重要对象的属性和操作,以及这些对象之间的相互关系;动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML不是一种程序设计语言,但我们可以用代码生成器将UML模型转换为多种程序设计语言代码,或使用反向生成器工具将程序源代码转换为UML模型。
它包括两个方面的概念:语义和表示法。
(1)语义 是用自然语言描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
(2)表示法 定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,这决定了UML是一种可视化(图形化)的建模语言。
![]() | |
| ![]() |
2. UML的组成
![]() | |
| ![]() |
2.1 UML的三个基本构造块
组成UML有三个基本的构造块,它们是:事物,图和关系。事物是UML中重要的组成部分,代表概念上或物理上的元素。关系把事物紧密联系在一起。图是很多有相互相关的事物的组。
![]() | |
| ![]() |
1、结构事物(Structural things):
a.类
b.接口
c.协作(collaboration)
d.用例(USE Case)
e.活动类(active class)
f.组件(component)
g. 结点(node)
2、动作事物(Behavioral things)
是UML模型中的动态部分。它们是模型的动词,代表时间和空间上的动作。总共有两种主要的动作事物:
第一种是交互(interaction),它是由一组对象之间在特定上下文中,为达到特定的目的而进行的一系列消息交换而组成的动作。
第二种是状态机(state machine),状态机由一系列对象的状态组成。
3、分组事物(Grouping things)
分组事物是UML模型中组织的部分,可以把它们看成是个盒子,模型可以在其中被分解。总共只有一种分组事物,称为包(package)。
4、注释事物(Annotational things)
注释事物是UML模型的解释部分。UML中用如下图表示:
![]() | |
| ![]() |
UML中的图有五种类别的图(9种图形)。它们是
1. 用例图:用例图
2. 静态图:类图、对象图
3. 行为图:状态图和活动图
4. 交互图:合作图和序列(顺序)图
5. 实现图:部署图和组件图(构件图)
![]() | |
| ![]() |
关系是建模元素之间的语义(有意义)联系,是UML把事物联系到一起的方法。
UML中的关系类型有:
1.依赖:是两个元素之间的关系,对一个元素(提供者)的改变可能影响或提供信息给其他元素(客户)
依赖不仅发生在类间,它们通常发生在:
l 包和包之间
l 对象和类之间
UML中表示依赖的图形是:
在UML中有四种基本的依赖类型:
a.Usage(使用):客户使用由提供者所提供的服务以实现它的行为,这是最普遍使用的依赖类型。
b.Abstraction(抽象):表示客户和提供者之间的关系,提供者比客户更加抽象
c.Permission(授权):提供者为客户提供某种权限以访问提供者的内容,这是一种提供者控制和限制对其内容访问的方法
d.Binding(绑定):一般用于提供参数化类型(模板)的语言中(如C++)
2.关联:是类间的语义联系,是类实例间连接的描述。在UML中表示关联的图是:
关联可以具有以下各项:
a.关联名称
关联名称是动词短语,表明源对象正在目标对象上执行的动作
b.角色名称
表明关联中类的对象所扮演的角色。
c. 多重性
多重性表明在任意时刻关系所能够涉及的对象数目,用来约束任意时刻对象的数目
d.导航性
用关系端部的箭头显示,表明可以从源类的任何对象到目标类的一个或多个对象(根据多重性确定的)遍历
3.泛化:一个元素是另一个元素的特例,而且它可以取代更一般的元素
泛化是一般元素和特殊元素之间的关系,是更概括的描述和更具体的种类间的关系,适用于继承。在UML的表示泛化的图形是:
4.实现:说明和实现间的关系。在UML中表示实现的图形是:
注意:关系的具体说明请见参考资料 (1) |
![]() | |
| ![]() |
在UML中存在两种建模机制:静态建模机制和动态建模机制。
当我们在实际的应用中使用面向对象的设计和分析方法时,一般遵循的步骤是:
第一步,描述需求;
这个步骤一般产生用例图。
第二步,根据需求建立系统的静态模型,构造系统的结构;
这个步骤产生:类图,对象图,组件图和部署图。
第三步,描述系统的行为。这里建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。
这个步骤产生:状态图,活动图,顺序图和合作图。
第一和第二步建立的模型都是静态的,我们称之为静态建模,第三步我们称之为活动建模。
![]() | |
| ![]() |
假设(1),一个仓库管理系统:仓库管理员需要进行物品进仓和物品出仓的操作,物品出仓的前提是相关物品的库存必须大于一定额度。
![]() | |
| ![]() |
4.1 用例图
![]() | |
| ![]() |
4.1.1 组成
用例图表示处于同一个系统中参与者和用例之间的关系。是一组动作序列(包括它的变衍生物)的描述,系统执行该动作序列来为参与者产生一个可观测的结果值。
它用来描述需求的,描述待开发系统的功能需求,本质上是用来描述用户和系统间一次交互。它是需求分析阶段(MSF中的构想阶段)的主要任务之一。
用例图分为两个部分:用例(Use Case)和执行者(Actor)
用例(Use Case ):UML中表示为一个椭圆。它有以下特点:
1.用例捕获某些用户可见的需求,实现一个具体的用户目标。
2.用例由执行者激活,并提供确切的值给执行者。
3.用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。
执行者(Actor):指用户在系统中所扮演的角色。用个小人表示。这里的执行者可以是实际的用户也可以是另外的计算机系统。
![]() | |
| ![]() |
用例间的关系分为两种:使用(Include)和扩展(Extend)
使用:指的是用例A要用到用例B。
例如出仓,我们需要检查库存情况,那用例“物品出仓”就要用到用例“显示物品的库存”。
扩展:表示某个用例是从另外一个用例扩展而来的。
例如仓库管理员在物品进仓的时候,可以查看相关物品的库存情况。那么用例“查看物品的库存情况”就是扩展自用例“物品进仓”。
两者的图形都是一个带箭头的实线:
![]() | |
| ![]() |
我们一般可以采用“主谓”结构的方式来发现用例,也就是“谁做什么”。“谁”就是ACTOR,“做什么”就是用例。对于已识别的角色,通过询问以下问题就可以发现用例:
1.角色需要从系统中获得哪种功能?角色需要做什么?
2.角色需要读取,产生,删除,修改或存储系统中的某种信息吗?
3.系统中发生的事件需要通知角色吗?或者角色需要通知系统某件事件吗?这些事件(功能)能干些什么?
4.如果采用系统的新功能处理角色的日常工作是简单化了,还是提高了工作效率?
5.还有一些与当前角色可能无关的问题,也能帮助建模者发现用例。例如:
a.系统需要的输入/输出是什么信息?这些输入/输出信息是从哪里来到哪里去?
b.系统当前的这种实现方法要解决的问题是什么?(也许是用自动系统代替手工操作?)
对于假设(1),仓库管理员就是ACTOR,要进行的动作有“物品进仓”,“物品出仓”和“获得物品的库存情况”,相应的用例就是这三个。
![]() | |
| ![]() |
4.2.类图
![]() | |
| ![]() |
4.2.1 类和对象
类是具有相同特征的对象的集合。对象是类的一个实例,是类的一个具体表现。打个比方:人是类,而张三就是对象。一个类可以有很多个实例(对象)。
![]() | |
| ![]() |
类包括这三部分:
1.名称:类的名称
2.属性:描述类的对象包含的数据。例如类“人”。它的属性有:姓名,性别,年龄等等。
在UML 中表示属性的语法是:可见性 属性名 :类型 = 缺省值 {约束特性}。其中常用的可见性有Public、Private和Protected三种,在UML中分别表示为“+”、“-”和“#”。对于类人的姓名属性可以写成:+ 姓名:字符串型=“”。表示姓名属性是Public的,类型是字符串型的,缺省值为空串。
3.方法(操作):是类的功能,只能作用到该类的对象上,定义了对象之间可能的交互。
在UML中表示方法的语法为:可见性 操作名 (参数表) :返回类型 {约束特性}。对于类人的吸气方法,我们可以写成:+ 吸气(氧气):二氧化碳。表示吸气方法是公共的,需要氧气做参数,返回的类型是二氧化碳。
![]() | |
| ![]() |
类间的关系有这几种:
1.关联
关联用于描述类与类之间的连接。由于对象是类的实例,因此,类和类之间的关联也就是对象和对象之间的关联,类和类之间有多种连接方式每种连接方式各不相同(语义的连接),但外部表现形式相类似,故我们称之为关联。关联关系之间一般都是双向的,关联的双方都能够互相通信;反过来说,如果某两个类能够互相通信或者y一方能感知另一方,那么这两个类之间就存在关联关系。描述这种关系常用的子句是“彼此知道,互相连接”。
关联有0或1对多,多对多等几种。例如班级(Class)类和学生(Student)类,他们之间就是1对多的关系。
关联类是起关联作用的类。是通过一根虚线与关联连接。例如公司和个人之间的雇佣关系是通过合同建立的。那么合同就是个关联类。
聚合:一种特殊形式的关联。聚合表示类之间的关系是整体与部分的关系。比如计算跟打印机的关系,一台完整的计算机可以包括打印机,但是没有打印机,计算机也可以运行。
组合:另一种特殊形式的关联。组合也表示类之间的关系是整体与部分的关系,但整体拥有各部分,部分与整体共存,如部分不存在了,整体也就不完整。例如计算机根CPU的关系,如果没有了CPU,那么计算机就没有办法运行。
在UML中,聚合表示为空心菱形,组合表示为实心菱形。
2.继承
定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一端是空心三角形的实线。例如人,人是共性(一般)的元素,而男人和女人就是特殊的元素。我们可以说:男人继承自人,女人也继承自人,而漂亮女人继承自女人。
3.依赖
有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类发送消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。UML中依赖表示为:虚线加箭头。
![]() | |
| ![]() |
它是描述类和类之间的静态关系,是用来记录系统的静态结构。也就是指出系统包括哪些类,它们是如何关联的,但不包括为实现特定的行为而进行的交互。
它是定义其它图的基础。
在UML中通常是用个矩形方框表示:
矩形顶部:名称,类名称首字母大写;
矩形中部:属性,一般用小写字母;
矩形底部:方法,一般用小写字母;
它通常包含:
1.类
2.接口
3.协作
4.类间的关系
![]() | |
| ![]() |
标识正确的类是设计面向对象系统的主要工作,找出系统中的类的方法有:
1.名词/动词分析
是一种非常简单的方法。
它首先对系统需求进行简明一致的陈述,然后将名词和名词短语用下划线表示出来,即标识出代表事物的词和短语。这样就产生一个候选类列表,从中筛选整理后获得系统的初始类列表。过程是:
a.找出名词或名词短语,这些是候选类或属性
b.找出动词或动词短语,这些是候选职责或操作
c.分析收集到的信息,得到初始类列表
对于假设(1)中的物品出仓,物品和仓库就是类。
2.CRC卡
是一种有力的和有趣的脑力风暴技术。它的方法是:
a.把问题域中重要事物书写在便笺上
b.每个便笺具有三个分栏的:
l 类名(在顶端)
l 类的职责(在左边)
l 类的协同者,帮助实现每个功能(在卡片的右边)
它经历的过程是一种脑力风暴的过程:
a.要求团队成员命名运转在业务领域的“事物”,把它们书写在便笺上
b.要求团队陈述该事物的职责,把他们记录在便笺的职责分栏上
c.要求团队识别可能一起工作的类,并且在他们之间连线或者把这些记录在每个便笺的协同者分栏中
对于假设(1),我们建立的类图是:
该图意在表示类和关系的用法,并不完整(不包括产品和订单细目部分,也没有体现库存检查部分).另外,GO是出仓单的简写.
![]() | |
| ![]() |
4.3 序列图(Sequence图)
![]() | |
| ![]() |
4.3.1 定义
是一种动态建模方法,用来描述对象之间动态的交互关系,着重体现对象间消息传递的时间顺序。
![]() | |
| ![]() |
UML中序列图中存在两根轴,分别是时间轴(垂直方向)和对象轴(水平方向);
顺序图中的对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名。垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息来表示。消息的箭头指明消息的类型。
顺序图中的消息可以是信号(Signal)、操作调用。当收到消息时,接收对象立即开始执行活动,即对象被激活了。
通过在对象生命线上显示一个细长矩形框来表示激活。消息可以用消息名及参数来标识。
上图表示aManager(仓库管理员)建立出货单,然后再进行库存检查的过程.当然,库存检查是在增加产品之后由产品对象调用库存检查,但是此处设计不包括产品部分,为了体现效果,改用订单对象直接调用库存检查.
![]() | |
| ![]() |
4.4 活动图
![]() | |
| ![]() |
4.4.1 定义
UML活动图是一种特殊的状态图,记录了单个操作或方法的逻辑,单个用户案例,或者单个业务流程的逻辑。表示一个程序或工作流。工作流是被活动图所建模的过程的例子。活动图通常出现在设计的前期,即在所有实现决定前出现,特别是在对象被指定执行所有的活动前,其状态代表活动的执行,就像一个计算机或真实世界不间断的操作,而转换由状态内活动的完成来触发(若有约束条件,可能有几个可能不同的出口)。
活动图是强调计算过程中顺序的和并发步骤的状态机。
![]() | |
| ![]() |
- 状态:来表示某个活动或动作,分为“动作状态”,“状态”,“初始状态”,“最终状态”;
- 泳道:用来表示活动图中的责任,是个矩形
。是活动图中活动的分组,每个组代表活动职责的一些有意义的部分;
- 控制流:表示从一个状态到另一个状态的变化。
![]() | |
| ![]() |
用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。一个状态图包括一系列的状态以及状态之间的转移。
注意:要了解其他UML图的详细情况,请访问UML站点:www.uml.org或www.umlchina.com。
(1)《UML参考手册》
(2)《UML和统一过程-实用面向对象的分析和设计》
(3)《使用UML-关于对象和组件软件工程》