UML模型的基本概念.docx
- 文档编号:17581020
- 上传时间:2023-07-26
- 格式:DOCX
- 页数:39
- 大小:285.03KB
UML模型的基本概念.docx
《UML模型的基本概念.docx》由会员分享,可在线阅读,更多相关《UML模型的基本概念.docx(39页珍藏版)》请在冰点文库上搜索。
UML模型的基本概念
UML 模型的基本概念
1 UML 的建筑块
组成 UML 有三种基本的建筑块:
1、事物(Things)
2、关系(Relationships)
3、图(Diagrams)
事物是 UML 中重要的组成部分。
关系把事物紧密联系在一起。
图是很多有相互相关
的事物的组。
1.1 UML 的事物
UML 中有始终类型的事物:
1、结构事物(Structural things)
2、动作事物(Behavioral things)
3、分组事物(Grouping things)
4、注释事物(Annotational things)
这些事物是 UML 模型中最基本的面向对象的建筑块。
它们在模型中属于最静态的部
分,代表概念上等或物理上的元素。
1.1.1 结构事物。
总共有七种结构化事物。
首先是类(class),类是描述具有相同属性、方法、关系和语
义的对象的集合。
一个类实现一个或多个接口。
在 UML 中类被画为一个矩型,通常
包括它的名字、属性和方法。
Window
Origin
Size
Open()
Close()
Move()
Display()
图 1-1 类
第二种是接口(interface),接口是指类或组件提供特定服务的一组操作的集合。
因此,
一个接口描述了类或组件的对外的可见的动作。
一个接口可以实现类或组件的全部动
作,也可以只实现一部分。
接口在 UML 中被画成一个圆和它的名字。
ISpelling
图 1-2 接口
第三种是协作(collaboration),协作定义了交互的操作,是一些角色和其它元素一起
工作,提供一些合作的动作,这些动作比元素的总和要大。
因此,协作具有结构化、
动作化、维的特性。
一个给定的类可能是几个协作的组成部分。
这些协作代表构成系
统的模式的实现。
协作在 UML 中用一个虚线画的椭圆和它的名字来表示。
响应链
图 1-3 协作
第四种是 use case,use case 是描述一系列的动作,这些动作是系统对一个特定角色执
行,产生值得注意的结果的值。
在模型中 use case 通常用来组织动作事物。
Use case
是通过协作来实现的。
在 UML 中,use case 画为一个实线椭圆,通常还有它的名字。
Place order
图 1-4 use case
第五种是活动类(active class),活动类是这种类,它的对象有一个或多个进程或线程。
活动类和类很相象,只是它的对象代表的元素的行为和其他的元素是同时存在的。
在
UML 中活动类的画法和类相同,只是边框用粗线条。
EventManager
Suspend()
Flush()
图 1-5 活动类
第六种是组件(component),组件是物理上或可替换的系统部分,它实现了一个接口
集合。
在一个系统中,你可能会遇到不同种类的组件,例如 COM+或 JAVA BEANS。
组件在 UML 中用如下的图表示:
Orderform.java
图 1-6 组件
第七种是结点(node),结点是一个物理元素,它在运行时存在,代表一个可计算的资
源,通常占用一些内存和具有处理能力。
一个组件集合一般来说位于一个结点,但有
可能从一个结点转到另一个结点。
结点通常用如下的图形表示:
Server
图 1-7 结点
类、接口、协作、use case、活动类、组件和结点这七个元素是在 UML 模型中使用的
最基本的结构化事物。
系统中还有这七种基本元素的变化体,如角色、信号(某种类),
进程和线程(某种活动类),应用程序、文档、文件、库、表(组件的一种)。
1.1.2 动作事物
动态事物是 UML 模型中的动态部分。
它们是模型的动词,代表时间和空间上的动作。
总共有两种主要的动作事物。
第一种是 ineraction,interaction 是由一组对象之间在特定上下文中,为达到特定的目
的而进行的一系列消息交换而组成的动作。
在 interaction 中组成动作的对象的每个操作都
要详细列出,包括消息、动作次序(消息产生的动作),连接(对象之间的连接)。
在 UML
中消息画成带箭头的直线,通常加上操作的名字。
display
图 1-8 消息
第二种是状态机(statemachine),状态机由一系列对象的状态组成。
在 UML 中状态
表示为下图:
waiting
图案 1-9 状态
interaction 和状态机是 UML 模型中最基本的两个动态事物元素,它们通常和其他的结构元
素、主要的类、对象连接在一起。
1.1.3 分组事物
分组事物是 UML 模型中组织的部分,可以把它们看成是个盒子,模型可以在其中被
分解。
总共只有一种分组事物,称为包(package)。
包是一种将有组织的元素分组的机制。
结构事物、动作事物甚至其他的分组事物都有
可能放在一个包中。
与组件(存在于运行时)不同的是包纯粹是一种概念上的东西,只存
在于开发阶段。
在 UML 中用如下图表示包:
Business rules
图 1-10 包
1.1.4 注释事物
注释事物是 UML 模型的解释部分。
UML 中用如下图表示:
Return copy of self
图 1-11 注释
1.1.5 UML 中的关系
UML 中有四种关系:
1.依赖(Dependencies)
图 1-12 依赖
2.关联(Association)
0..1*
图 1-13 关联
3.一般化(generalization)
图 1-14 一般化
4.实现(realuzation)
图 1-15 实现
1.1.6 UML 中的图
1、类图(class diagram)
2、对象图(class diagram)
3、Use case diagram
4、Sequence diagram
5、Collaboration diagram
6、Statechart diagram
7、Activity diagram
8、Compomnent diagram
9、Deployment diagram
第二章 Hello World
记得在学习 C 语言的时候,教科书上的第一个程序就是叫 Hello world,一个在屏幕上简单
地打印出“Helloworld!
”语句的例子。
在系统的学习 UML 语言之前我们来看一个简单的
例子,让大家有一个系统的认识。
在 java 中一个在浏览器中显示“Hello World!
”的 Applet 代码如下:
import java.awt.Graphics;
class HelloWorld extends java.applet.Applet{
public void paint( Graphics g ){
g.drawString("Hello World!
", 10,10 );
}
}
代码的第一行:
import java.awt.Graphics;
使得程序可以使用 Graphics 类。
前缀 java.awt 指出了类 Graphics 所在的包。
第二行代码:
class HelloWorld extends java.applet.Applet{
从 Applet 类派生出新的类 HelloWorld,Applet 类在 java.applet 包中。
接下来的三行代码:
public void paint( Graphics g ){
g.drawString("Hello World!
", 10,10 );
}
声明了类 HelloWorld 的方法 paint,在他的实现中调用了另一个方法 drawString 来输出
“Hello World!
”。
我们可以很直接地为这个程序用 UML 建立模型。
如图 2-1。
HelloWorld
Paint()g.drawString("Hello
World!
",10,10)
图 2-1 HelloWorld
图 2-1 表达了最基本的 HelloWorld 模型,但它还有很多东西没有表示出来。
在我们的程序
中 Applet 类和 Graphics 类的使用是不相同的。
Applet 用作 HelloWorld 类的父类,而
Graphics 类用在方法 paint 的实现中。
在 UML 模型中可以将这些关系表示为图 2-2:
Applet
HelloWorld
图 2-2 HelloWorld 的类图
在图 2-2 的类关系图中,我们用简单的矩行图标表示类 Applet 和 Graphics 类,没有将它们
的属性和方法显露出来是为了简化。
图中的空心箭头表示 HelloWorld 类是 Applet 类的子类,
代表一般化。
HelloWorld 和 Graphics 之间的虚线箭头表示依赖关系,表示 HelloWorld 类使
用了 Graphics 类。
到这里或许你认为已结束了,其实不然,如果认真研究 java 库中的 Applet 类和 Graphics 类
会发现他们都是一个庞大的继承关系中的一部分。
追踪 Applet 的实现可以得到另外一个类
图,如图 2-3 所示:
Object
Component
ImageObserver
Continer
Panel
Applet
HelloWorld
图 2-3 HelloWorld 继承图
䌺䌺䌺d䌺䌺䌺䌺䌺䌺䌺䌺 䌺䌺䌺䌺䌺䌺䌺䌺䌺䌺䌺d
䌺
䌺䌺䌺䌺䌺䌺
䌺䌺䌺䌺䌺䌺
䌺䌺
图 2-4 绘图机制
第四章 关系
依赖关系(Dependency)
依赖关系是一种使用关系,特定事物的改变有可能会影响到使用该事物的事物,反之
不成立。
在你想显示一个事物使用另一个事物时使用依赖关系。
通常情况下,依赖关系体现在某个类的方法使用另一个类作为参数。
在 UML 中你可
以在其它的事物之间使用依赖关系,特别是包和节点之间。
FilmChip
name :
string
dependency
PlayIOn(c :
Channel)
start()
stop()
Channel
图 4-1 依赖关系
一般化(Generalization)
一般化是继承关系,是叫做“is-a-kind-of”的关系。
在 UML 中你可以在包之间建立一
般化关系。
图 4-2 一般化
关联(Association)
关联是一种结构化的关系,指一种对象和另一种对象有联系。
给定有关联的两个类,
可以从一个类的对象得到另一个类的对象。
关联有两元关系和多元关系。
两元关系是指一
种一对一的关系,多元关系是一对多或多对一的关系。
一般用实线连接有关联的同一个类
或不同的两个类。
当你想要表示结构化关系时使用关联。
有一些修饰可以应用于关联。
1.名字:
可以给关系取名字
Person
Works for
Company
2.角色:
关系的两端代表不同的两种角色
PersonCompany
employeeemployer
3.重数:
表示有多少对象通过一个关系的实例相连接
Person
+1..* +*
Company
第五章 通用机制
UML 中的四种机制使地它简单和更易于使用,你可以在 UML 语言的任何时候用同样的方
法来使用,这四种机制是:
●specifications
●adornments
●common divisions
●extensibility
本章讨论 adornments 和 extensibility 这两种机制。
注释是最重要的一种修饰。
一个注释在 UML 中是一个图形符号,描述了和它相关联的元
素或一组元素的限制或注释语。
CPen只能动态创
建该对象
上图就是一个使用注释的例子,图中右边的为注释符号。
UML 的扩充性机制允许你在控制的方式下扩充 UML 语言。
这一类的机制包括:
stereotype,标记值、约束。
Stereotype 扩充了 UML 的词汇表,允许你创建新的建筑块,这
些建筑块从已有的继承而来,但特别针对你的问题。
标记值扩充了 UML 的建筑块的属性,
允许你在元素的规格中创建新的信息。
约束扩充了 UML 建筑块的语义,允许你添加新的
规则或修改已有的。
你将使用这些机制来让 UML 满足你的领域和开发的特别需要。
<
Billing
{version = 3.2}
上面是一个使用扩充机制的例子。
<
术语和概念
注释是一种图形符号用来限制或给一个元素或一组元素加上注解。
注释画成一个带折
角的矩形,在矩形中加上文字或图形的注解,
stereotype 是 UML 词汇的扩充,允许你创建新的 UML 建筑块,这些新的建筑块和原
有的类似,但特别针对你自己的问题。
通常 stereotype 画成用<<和>>包围起来的一个名字,
通常放在另一个元素的名字之上。
作为可选,stereotype 可以画成加一个图标。
标记值是 UML 元素特性的扩充,允许你创建元素规格的新的信息。
在 UML 中标记值
画成{}内的字符串,跟在元素名后面。
限制是 UML 元素语义的扩充,允许你对一个 UML 元素添加新规则或修改存在的规则。
限制通常画成{}内的字符串,放在关系附近。
当然,你也可以把限制用注释来表示。
通用建模技术
1.建模注解
使用注释的目的是为了让模型更清晰,下面是使用注释的一些技巧:
●将注释放在你要注解的元素边上,写下注解的文字。
用依赖关系的线将注释和被
注释的元素连起来会让人更明白。
●记住,你可以隐藏元素或使隐藏的元素可见。
这就意味着你可以将注释不隐藏起
来,而她注释的元素是可见的,这样会使你的模型图简洁,在必要的地方让注释
可见。
●如果你的注释很长或不仅仅是普通文本,你可以将你的注解放到一个独立的外部
文件中(如 WORD 文档)然后链接或嵌入到你的模型中。
下面是一个使用注解的例子:
建立新的建筑块
UML 的建筑块如:
类、接口、合作、组件、注释、关系等等,都在为具体问题建模的
时候基本上是够用了。
然而,如果你想扩展你的模型的词汇,如用来表示你的特定的问题
领域,你需要 stereotypes。
建立新的建筑块有如下的技巧:
●确定没有现成的基本的 UML 方法可以表达你的需要。
如果你碰到一个普通的建
模问题,很有可能已经有某种标准的 stereotype 是你想要的。
●如果你确信没有现成的东西可以表达这些语义,首先找到一个 UML 中的最接近
你要建立的模型的元素(例如:
类、接口、组件、注释、关系等等)然后为她定
义一个 stereotype。
值得一提的是你可以定义 stereotypes 的层次从而得到一般的
stereotypes 和为它定义的特别的特性。
这种方法尽量少用。
●通过对普通的 stereotype 定义一组标记值和对 stereotype 进行限制可以实现普通
stereotype 不能实现的功能。
●如果你希望这些 stereotype 具有不同的视觉效果,为他们定义一个特别的图标。
Competition
Registration
:
Coach
Practice
Register
team
Pay fee
Get event
materials
Return event
materials
:
Team
Unregistered]
:
Team
registered]
:
Team
Complete
Get event
results
New State2
[finished]
上面是一个例子。
假如你用活动图来为一个涉及到教练工作流和队员工作流的体育活
动建模。
在这里,区别教练和运动员以及与其他的本领域的对象是有意义的。
上面的
图中有两个事物是很突出的,教练对象和队员对象。
这里不仅仅是普通的类,更确切
地说,他们现在是两个新的建筑块。
因为定义了教练和队员 stereotype,并且运用到了
UML 的类上。
在这个图上,被标记为:
Coach 和:
Team 的匿名实例,后者显示了不同的
状态。
建模新属性
UML 建筑块的基本属性如:
类的属性和操作,包的内容等等,都足够描述清楚你要建
立的模型。
然而,如果你想扩展这些基本建筑块(或者用 stereotype 建立的新的建筑
块)的属性,你就需要使用标记值。
下面是一些技巧:
●首先要确定的是你的需要无法用基本的 UML 表达。
如果你碰到一个普通的建模
问题,很有可能已经有某种标准的标记值是你想要的
●如果你确定没有其他的方法可以表达你需要的语义,添加新的属性到一个单独的
元素或一个 stereotype。
继承的规则是适用的,也就是说对父亲定义的标记值对儿
子也具有。
<
FieldAccess
{version = 2.5 status = checked in}
<
Billing
{version = 2.5 status = checkedOut by=egb
建立新的语义
当你用 UML 建立模型的时候,你总是使用 UML 定义的规则,这实在是件好事,因为
别的懂得如何读 UML 的人可以毫无偏差地读懂你想要表达的东西。
然而,如果你发现你
需要表达的语义是 UML 无法表达的或你想要修改 UML 的规则,这时你就需要使用限制了。
下面是使用限制的一些技巧:
●首先要确定的是你的需要无法用基本的 UML 表达。
如果你碰到一个普通的建模
问题,很有可能已经有某种标准的限制是你想要的。
●如果你确定没有其他的方法可以表达你需要的语义,用文本的形式在限制中写下
你的新语义,并且将他放在他涉及的元素附近。
你可以使用依赖关系来明确地表
示限制和他涉及的元素之间的关联。
●如果你需要详细说明你的语义,你可以用使用 OCL 把它写下来。
下面的图是一个公司人力资源系统的一小部分:
Department
**
{subset}
member
1..* 1
manager
Person
这副图显示了每个 Person 可能是 0 个或多个 Department 的成员。
每个 Department 至
少要有一个 Person 成员。
这副图进一步说明每个 Department 严格地有一个 Person 作
为管理者,每个 Person 可以是 0 个或多个 Department 的被管理人员。
所有的这些语义
可以被简单的 UML 表达。
然而,为了指出一个管理者必须也是 Department 的成员是
多员关系所忽略的,也是简单的 UML 无法表达的。
为了表达这种关系,你必须写下
一个限制指出管理者是 Department 成员的一个子集。
从子集到超集用依赖关系将两个
关系联系起来。
第六章 图
前言
建模实际上是对真实世界进行简化,从而可以更好地理解你要开发的系统。
使用 UML
中基本的建筑块如:
类、接口、关系、协作、组件、依赖、继承等,可以建立你想要的模
型。
还可以利用第五章介绍的机制扩充 UML 来表达问题领域独特的东西。
图是你组织这些建筑块的方式。
图代表着一系列的元素,这些元素常常被画成用点
(事物)和弧(关系)相连的图。
利用图来从不同的视角来观察系统。
由于没有一个复杂
的系统可以从一个透视图弄明白,UML 定义了一些图使得我们可以独立地从几个不同的视
角来了解系统。
好的图使得你要开发的系统是易于理解和可以接近的。
选择好的图对系统建模让你找
到系统中真正要问的问题,帮助你阐述清楚你的系统。
术语和概念
系统是组织起来完成特定目标的一组子系统。
系统可以用一组模型,可能来自不同的
视角,进行描述。
子系统是一组元素,其中一些通过包含的另外的元素组成特定的行为。
模型是对系统进行语义上的抽象,它是整个真实系统的简化,为了更好地理解系统而创建
的。
图是一系列的元素,这些元素常常被画成用点(事物)和弧(关系)相连的图。
利用
图来从不同的视角来观察系统。
系统代表着你要开发的事物,通过不同的模型从不同的透视图来观察系统,这些透视
图以图的形式表达。
在对真实世界进行建模的时候,你可以发现不管你的问题处于什么样的领域,你都会
创建相同的图,因为他们代表着通用的模型的通用的视。
通常,你利用下面的图来观察系
统的静态部分:
1.类图(Class Diagram)
2.对象图(Object Diagram)
3.组件图(Compoment Diagram)
4.分布图(Deployment Diagram)
使用下面的五种额外的图来观察系统动态的方面:
1.Usecase 图
2.序列图(Sequence Diagram)
3.协作图(Collaboration Diagram)
4.状态图(Statechart Diagram)
5.活动图(Activity Diagram)
UML 定义了这五种图。
结构化图(Structural Diagrams)
1.类图(Class Diagram)类、接口和协作
2.对象图(Object Diagram)对象
3.组件图(Compoment Diagram)组件
4.分布图(Deployment Diagram)节点(Notes)
类图类图显示了一组类、接口和协作以及它们之间的关系。
类图在面向对象的建模
设计中是很常用的。
利用类图阐明系统的静态的设计。
包含活动类(active classes)的类图
通常用来说明看到的系统静态过程。
对象图对象图显示了一组对象和他们之间的关系。
使用对象图来说明数据结构,类
图中的类或组件等的实例的静态快照。
对象图和类图一样反映系统的静态过程,但它是从
实际的或原型化的情景来表达的。
组件图组件图显示了一些组件和它们之间的关系。
使用组件图来说明系统的静态实
现。
组件图和类图是有联系的,通常一个组件可以映射成一个或多个类,接口或协作。
分布图分布图显示了一些节点和它们之间的关系。
使用分布图来说明系统的静态结
构。
分布图和组件图是有联系的,通常一个节点封装了一个或多个组件。
动作图(Behavioral Diagrams)
UML 中定义的动作图包括:
1.Usecase 图
2.序列图(Sequence Diagram)
3.协作图(Collaboration Diagram)
4.状态图(Statechart Diagram)
5.活动图(Activity Diagram)
Usecase 图 Usecase 图显示了一些 Usecase 和角色(特殊的类)和他们的关系。
使用
us
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 模型 基本概念