UML基本概念教程Word下载.docx

上传人:b****4 文档编号:16906231 上传时间:2022-11-27 格式:DOCX 页数:25 大小:147.89KB
下载 相关 举报
UML基本概念教程Word下载.docx_第1页
第1页 / 共25页
UML基本概念教程Word下载.docx_第2页
第2页 / 共25页
UML基本概念教程Word下载.docx_第3页
第3页 / 共25页
UML基本概念教程Word下载.docx_第4页
第4页 / 共25页
UML基本概念教程Word下载.docx_第5页
第5页 / 共25页
点击查看更多>>
下载资源
资源描述

UML基本概念教程Word下载.docx

《UML基本概念教程Word下载.docx》由会员分享,可在线阅读,更多相关《UML基本概念教程Word下载.docx(25页珍藏版)》请在冰豆网上搜索。

UML基本概念教程Word下载.docx

第四种是usecase,usecase是描述一系列的动作,这些动作是系统对一个特定角色执行,产生值得注意的结果的值。

在模型中usecase通常用来组织动作事物。

Usecase是通过协作来实现的。

在UML中,usecase画为一个实线椭圆,通常还有它的名字。

第五种是活动类(activeclass),活动类是这种类,它的对象有一个或多个进程或线程。

活动类和类很相象,只是它的对象代表的元素的行为和其他的元素是同时存在的。

在UML中活动类的画法和类相同,只是边框用粗线条。

第六种是组件(component),组件是物理上或可替换的系统部分,它实现了一个接口集合。

在一个系统中,你可能会遇到不同种类的组件,例如COM+或JAVABEANS。

组件在UML中用如下的图表示:

图1-6组件第七种是结点(node),结点是一个物理元素,它在运行时存在,代表一个可计算的资源,通常占用一些内存和具有处理能力。

一个组件集合一般来说位于一个结点,但有可能从一个结点转到另一个结点。

结点通常用如下的图形表示:

类、接口、协作、usecase、活动类、组件和结点这七个元素是在UML模型中使用的最基本的结构化事物。

系统中还有这七种基本元素的变化体,如角色、信号(某种类),进程和线程(某种活动类),应用程序、文档、文件、库、表(组件的一种)。

1.1.2动作事物

动态事物是UML模型中的动态部分。

它们是模型的动词,代表时间和空间上的动作。

总共有两种主要的动作事物。

第一种是ineraction,interaction是由一组对象之间在特定上下文中,为达到特定的目的而进行的一系列消息交换而组成的动作。

interaction中组成动作的对象的每个操作都要详细列出,包括消息、动作次序(消息产生的动作),连接(对象之间的连接)。

在UML中消息画成带箭头的直线,通常加上操作的名字。

图1-8消息

第二种是状态机(statemachine),状态机由一系列对象的状态组成。

在UML中状态表示为下图:

interaction和状态机是UML模型中最基本的两个动态事物元素,它们通常和其他的结构元素、主要的类、对象连接在一起。

1.1.3分组事物

分组事物是UML模型中组织的部分,可以把它们看成是个盒子,模型可以在其中被分解。

总共只有一种分组事物,称为包(package)。

包是一种将有组织的元素分组的机制。

结构事物、动作事物甚至其他的分组事物都有可能放在一个包中。

与组件(存在于运行时)不同的是包纯粹是一种概念上的东西,只存在于开发阶段。

在UML中用如下图表示包:

1.1.4注释事物

注释事物是UML模型的解释部分。

UML中用如下图表示:

1.1.5UML中的关系

UML中有四种关系:

1.依赖(Dependencies) 

(图1-12依赖)

2.关联(Association)

(图 1-13关联)

3.一般化(generalization)

(图1-14一般化) 

4.实现(realuzation) 

(图 1-15实现)

1.1.6UML中的图

1、类图(classdiagram)

2、对象图(classdiagram)

3、Usecasediagram

4、Sequencediagram

5、Collaborationdiagram

6、Statechartdiagram

7、Activitydiagram

8、Compomnentdiagram

9、Deploymentdiagram

关于这些图的详细介绍将在今后的章节中讲解。

第二章HelloWorld

记得在学习C语言的时候,教科书上的第一个程序就是叫Helloworld,一个在屏幕上简单地打印出“Helloworld!

”语句的例子。

在系统的学习UML语言之前我们来看一个简单的例子,让大家有一个系统的认识。

在java中一个在浏览器中显示“HelloWorld!

”的Applet代码如下:

importjava.awt.Graphics;

classHelloWorldextendsjava.applet.Applet{

publicvoidpaint(Graphicsg){

g.drawString("

HelloWorld!

"

10,10);

}

代码的第一行:

使得程序可以使用Graphics类。

前缀java.awt指出了类Graphics所在的包。

第二行代码:

从Applet类派生出新的类HelloWorld,Applet类在java.applet包中。

接下来的三行代码:

声明了类HelloWorld的方法paint,在他的实现中调用了另一个方法drawString来输出“HelloWorld!

”。

我们可以很直接地为这个程序用UML建立模型。

如图2-1。

图2-1表达了最基本的HelloWorld模型,但它还有很多东西没有表示出来。

在我们的程序中Applet类和Graphics类的使用是不相同的。

Applet用作HelloWorld类的父类,而Graphics类用在方法paint的实现中。

在UML模型中可以将这些关系表示为图2-2:

在图2-2的类关系图中,我们用简单的矩行图标表示类Applet和Graphics类,没有将它们的属性和方法显露出来是为了简化。

图中的空心箭头表示HelloWorld类是Applet类的子类,代表一般化。

HelloWorld和Graphics之间的虚线箭头表示依赖关系,表示HelloWorld类使用了Graphics类。

到这里或许你认为已结束了,其实不然,如果认真研究java库中的Applet类和Graphics类会发现他们都是一个庞大的继承关系中的一部分。

追踪Applet的实现可以得到另外一个类图,如图2-3所示:

第三章类

类是具有相同属性、操作、关系的对象集合的总称。

通常在UML中类被画成矩形。

名称

每个类都必须有一个名字,用来区分其它的类。

类名是一个字符串,称为简单名字。

路径名字是在类名前加包含类的包名为前缀。

例如Wall、java:

:

awt:

Wall都是合法的类名。

属性

属性是指类的命名的特性,常常代表一类取值。

类可以有任意多个属性,也可以没有属性。

在类图中属性只要写上名字就可以了。

如下图

也可以在属性名后跟上类型甚至缺省取值,如下图

操作

操作是类的任意一个实例对象都可以调用的,并可能影响该对象行为的实现。

操作在类图中如下图描述:

组织属性和方法

在画类图的时候没有必要将全部的属性和操作都画出来。

实际上,在大部分情况下你也不可能在一个图中将类的属性和操作都画出来。

在画类图时可以只将感兴趣的属性和操作画出来就可以了。

可以用”...”表示还有属性或方法没有画出来。

为了更好地组织属性或方法,可以在一组功能相同的属性或方法前加上一个描述的前缀(<

<

>

中的文字),如下图:

职责:

职责指的是类所担任的任务,类的设计要完成什么样的功能,要存担的义务。

一个类可以有多种职责,设计得好的类一般至少有一种职责,在定义类的时候,将类的职责分解成为类的属性和方法。

通常在UML中在类图的最下方用单独的部分列出类的职责。

类的职责其实只是一段或多段文本描述。

通用建模技术

1. 

为系统的词汇建立模型

● 

标识出用户或解决问题时用来描述问题的东西,使用CRC卡片和基于USE-CASE的分析来找出这些抽象。

对每一个抽象,标识出它的职责集合。

确定明确地定义了每一个类,在为所有类确定的职责中取得了很好的平衡。

为类提供实现类的职责所需要的属性和方法。

2. 

为系统的职责分配建立模型

标识出行为相类似的对类

找出这些类的职责

把这些类作为整体看待,把职责多的类分为几个小类

考虑这些类如何协作,重新进行类的职责分配已满足协作中没有类太多职责或太少职责

3. 

为非软件的事务建立模型

为抽象成类的事务建立模型

如果你建模的是硬件本身包含有软件,建模时考虑为一种NODE,这样可以对它进一步的分解。

4. 

为原始类型建模

为类型或枚举建立模型

如果要对这种类型取值范围进行说明,使用约束。

第四章关系

依赖关系(Dependency)

依赖关系是一种使用关系,特定事物的改变有可能会影响到使用该事物的事物,反之不成立。

在你想显示一个事物使用另一个事物时使用依赖关系。

通常情况下,依赖关系体现在某个类的方法使用另一个类作为参数。

在UML中你可以在其它的事物之间使用依赖关系,特别是包和节点之间。

图4-1依赖关系

一般化(Generalization)

一般化是继承关系,是叫做“is-a-kind-of”的关系。

在UML中你可以在包之间建立一般化关系。

图4-2一般化

关联(Association)

关联是一种结构化的关系,指一种对象和另一种对象有联系。

给定有关联的两个类,可以从一个类的对象得到另一个类的对象。

关联有两元关系和多元关系。

两元关系是指一种一对一的关系,多元关系是一对多或多对一的关系。

一般用实线连接有关联的同一个类或不同的两个类。

当你想要表示结构化关系时使用关联。

有一些修饰可以应用于关联。

名字:

可以给关系取名字

角色:

关系的两端代表不同的两种角色

3.重数:

表示有多少对象通过一个关系的实例相连接

第五章通用机制

UML中的四种机制使地它简单和更易于使用,你可以在UML语言的任何时候用同样的方法来使用,这四种机制是:

specifications

adornments

commondivisions

extensibility

本章讨论adornments和extensibility这两种机制。

注释是最重要的一种修饰。

一个注释在UML中是一个图形符号,描述了和它相关联的元素或一组元素的限制或注释语。

上图就是一个使用注释的例子,图中右边的为注释符号。

UML的扩充性机制允许你在控制的方式下扩充UML语言。

这一类的机制包括:

stereotype,标记值、约束。

Stereotype扩充了UML的词汇表,允许你创建新的建筑块,这些建筑块从已有的继承而来,但特别针对你的问题。

标记值扩充了UML的建筑块的属性,允许你在元素的规格中创建新的信息。

约束扩充了UML建筑块的语义,允许你添加新的规则或修改已有的。

你将使用这些机制来让UML满足你的领域和开发的特别需要。

上面是一个使用扩充机制的例子。

subsystem>

是stereotype,{version=3.2}是标记值

术语和概念

注释是一种图形符号用来限制或给一个元素或一组元素加上注解。

注释画成一个带折角的矩形,在矩形中加上文字或图形的注解,

stereotype是UML词汇的扩充,允许你创建新的UML建筑块,这些新的建筑块和原有的类似,但特别针对你自己的问题。

通常stereotype画成用<

和>

包围起来的一个名字,通常放在另一个元素的名字之上。

作为可选,stereotype可以画成加一个图标。

标记值是UML元素特性的扩充,允许你创建元素规格的新的信息。

在UML中标记值画成{}内的字符串,跟在元素名后面。

限制是UML元素语义的扩充,允许你对一个UML元素添加新规则或修改存在的规则。

限制通常画成{}内的字符串,放在关系附近。

当然,你也可以把限制用注释来表示。

建模注解

使用注释的目的是为了让模型更清晰,下面是使用注释的一些技巧:

将注释放在你要注解的元素边上,写下注解的文字。

用依赖关系的线将注释和被注释的元素连起来会让人更明白。

记住,你可以隐藏元素或使隐藏的元素可见。

这就意味着你可以将注释不隐藏起来,而她注释的元素是可见的,这样会使你的模型图简洁,在必要的地方让注释可见。

如果你的注释很长或不仅仅是普通文本,你可以将你的注解放到一个独立的外部文件中(如WORD文档)然后链接或嵌入到你的模型中。

下面是一个使用注解的例子:

建立新的建筑块

UML的建筑块如:

类、接口、合作、组件、注释、关系等等,都在为具体问题建模的时候基本上是够用了。

然而,如果你想扩展你的模型的词汇,如用来表示你的特定的问题领域,你需要stereotypes。

建立新的建筑块有如下的技巧:

确定没有现成的基本的UML方法可以表达你的需要。

如果你碰到一个普通的建模问题,很有可能已经有某种标准的stereotype是你想要的。

如果你确信没有现成的东西可以表达这些语义,首先找到一个UML中的最接近你要建立的模型的元素(例如:

类、接口、组件、注释、关系等等)然后为她定义一个stereotype。

值得一提的是你可以定义stereotypes的层次从而得到一般的stereotypes和为它定义的特别的特性。

这种方法尽量少用。

通过对普通的stereotype定义一组标记值和对stereotype进行限制可以实现普通stereotype不能实现的功能。

如果你希望这些stereotype具有不同的视觉效果,为他们定义一个特别的图标。

上面是一个例子。

假如你用活动图来为一个涉及到教练工作流和队员工作流的体育活动建模。

在这里,区别教练和运动员以及与其他的本领域的对象是有意义的。

上面的图中有两个事物是很突出的,教练对象和队员对象。

这里不仅仅是普通的类,更确切地说,他们现在是两个新的建筑块。

因为定义了教练和队员stereotype,并且运用到了UML的类上。

在这个图上,被标记为:

Coach和:

Team的匿名实例,后者显示了不同的状态。

建模新属性

UML建筑块的基本属性如:

类的属性和操作,包的内容等等,都足够描述清楚你要建立的模型。

然而,如果你想扩展这些基本建筑块(或者用stereotype建立的新的建筑块)的属性,你就需要使用标记值。

下面是一些技巧:

首先要确定的是你的需要无法用基本的UML表达。

如果你碰到一个普通的建模问题,很有可能已经有某种标准的标记值是你想要的

如果你确定没有其他的方法可以表达你需要的语义,添加新的属性到一个单独的元素或一个stereotype。

继承的规则是适用的,也就是说对父亲定义的标记值对儿子也具有。

建立新的语义

当你用UML建立模型的时候,你总是使用UML定义的规则,这实在是件好事,因为别的懂得如何读UML的人可以毫无偏差地读懂你想要表达的东西。

然而,如果你发现你需要表达的语义是UML无法表达的或你想要修改UML的规则,这时你就需要使用限制了。

下面是使用限制的一些技巧:

如果你碰到一个普通的建模问题,很有可能已经有某种标准的限制是你想要的。

如果你确定没有其他的方法可以表达你需要的语义,用文本的形式在限制中写下你的新语义,并且将他放在他涉及的元素附近。

你可以使用依赖关系来明确地表示限制和他涉及的元素之间的关联。

如果你需要详细说明你的语义,你可以用使用OCL把它写下来。

下面的图是一个公司人力资源系统的一小部分:

这副图显示了每个Person可能是0个或多个Department的成员。

每个Department至少要有一个Person成员。

这副图进一步说明每个Department严格地有一个Person作为管理者,每个Person可以是0个或多个Department的被管理人员。

所有的这些语义可以被简单的UML表达。

然而,为了指出一个管理者必须也是Department的成员是多员关系所忽略的,也是简单的UML无法表达的。

为了表达这种关系,你必须写下一个限制指出管理者是Department成员的一个子集。

从子集到超集用依赖关系将两个关系联系起来。

第六章图

前言

建模实际上是对真实世界进行简化,从而可以更好地理解你要开发的系统。

使用UML中基本的建筑块如:

类、接口、关系、协作、组件、依赖、继承等,可以建立你想要的模型。

还可以利用第五章介绍的机制扩充UML来表达问题领域独特的东西。

图是你组织这些建筑块的方式。

图代表着一系列的元素,这些元素常常被画成用点(事物)和弧(关系)相连的图。

利用图来从不同的视角来观察系统。

由于没有一个复杂的系统可以从一个透视图弄明白,UML定义了一些图使得我们可以独立地从几个不同的视角来了解系统。

好的图使得你要开发的系统是易于理解和可以接近的。

选择好的图对系统建模让你找到系统中真正要问的问题,帮助你阐述清楚你的系统。

系统是组织起来完成特定目标的一组子系统。

系统可以用一组模型,可能来自不同的视角,进行描述。

子系统是一组元素,其中一些通过包含的另外的元素组成特定的行为。

模型是对系统进行语义上的抽象,它是整个真实系统的简化,为了更好地理解系统而创建的。

图是一系列的元素,这些元素常常被画成用点(事物)和弧(关系)相连的图。

系统代表着你要开发的事物,通过不同的模型从不同的透视图来观察系统,这些透视图以图的形式表达。

在对真实世界进行建模的时候,你可以发现不管你的问题处于什么样的领域,你都会创建相同的图,因为他们代表着通用的模型的通用的视。

通常,你利用下面的图来观察系统的静态部分:

类图(ClassDiagram)

对象图(ObjectDiagram)

组件图(CompomentDiagram)

分布图(DeploymentDiagram)

使用下面的五种额外的图来观察系统动态的方面:

Usecase图

序列图(SequenceDiagram)

协作图(CollaborationDiagram)

状态图(StatechartDiagram)

5. 

活动图(ActivityDiagram)

UML定义了这五种图。

结构化图(StructuralDiagrams)

类图(ClassDiagram) 

类、接口和协作

对象图(ObjectDiagram) 

对象

组件图(CompomentDiagram) 

组件

分布图(DeploymentDiagram) 

节点(Notes)

类图类图显示了一组类、接口和协作以及它们之间的关系。

类图在面向对象的建模设计中是很常用的。

利用类图阐明系统的静态的设计。

包含活动类(activeclasses)的类图通常用来说明看到的系统静态过程。

对象图对象图显示了一组对象和他们之间的关系。

使用对象图来说明数据结构,类图中的类或组件等的实例的静态快照。

对象图和类图一样反映系统的静态过程,但它是从实际的或原型化的情景来表达的。

组件图组件图显示了一些组件和它们之间的关系。

使用组件图来说明系统的静态实现。

组件图和类图是有联系的,通常一个组件可以映射成一个或多个类,接口或协作。

分布图分布图显示了一些节点和它们之间的关系。

使用分布图来说明系统的静态结构。

分布图和组件图是有联系的,通常一个节点封装了一个或多个组件。

动作图(BehavioralDiagrams)

UML中定义的动作图包括:

Usecase图Usecase图显示了一些Usecase和角色(特殊的类)和他们的关系。

使用usecase图来描述系统静态的功能场景。

Usecase图对于组织和模型化系统的动作是很重要的。

序列图序列图是一种交互图(interactiondiagram),强调的是时间和消息的次序。

一个序列图显示了一系列的对象和在这些对象之间发送和接收的消息。

对象通常是命名或匿名的类的实例,也可以代表其他事物的实例,例如协作、组件和节点。

使用序列图来说明系统的动态情况。

协作图协作图是一种交互图(interactiondiagram),强调的是发送和接收消息的对象之间的组织结构。

一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。

对象通常是命名或匿名的类的实例,也

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 农林牧渔 > 林学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1