转UML的9种图例解析
Posted James wang
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了转UML的9种图例解析相关的知识,希望对你有一定的参考价值。
UML图中类之间的关系:依赖,泛化,关联,聚合,组合,实现
依赖关系(Dependence):假设A类的变化引起了B类的变化,则说名B类依赖于A类。
- public class Driver
- {
- public void drive(Car car)
- {
- car.move();
- }
- ……
- }
- public class Car
- {
- public void move()
- {
- ......
- }
- ……
- }
依赖关系有如下三种情况:
1、A类是B类中的(某中方法的)局部变量;
2、A类是B类方法当中的一个参数;
3、A类向B类发送消息,从而影响B类发生变化;
泛化关系(Generalization):A是B和C的父类,B,C具有公共类(父类)A,说明A是B,C的一般化(概括,也称泛化)
- public class Person
- {
- protected String name;
- protected int age;
- public void move()
- {
- ……
- }
- public void say()
- {
- ……
- }
- }
- public class Student extends Person
- {
- private String studentNo;
- public void study()
- {
- ……
- }
- }
在UML当中,对泛化关系有三个要求:
1、子类与父类应该完全一致,父类所具有的属性、操作,子类应该都有;
2、子类中除了与父类一致的信息以外,还包括额外的信息;
3、可以使用父类的实例的地方,也可以使用子类的实例;
关联关系(Association):类之间的联系,如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单,再如篮球队员与球队之间的关联(下图所示)。
- public class Customer
- {
- private Product[] products;
- ……
- }
- public class Product
- {
- private Customer customer;
- ……
- }
- public class Customer
- {
- private Address address;
- ……
- }
- public class Address
- {
- ……
- }
- public class Node
- {
- private Node subNode;
- ……
- }
表示方式 |
多重性说明 |
1..1 |
表示另一个类的一个对象只与一个该类对象有关系 |
0..* |
表示另一个类的一个对象与零个或多个该类对象有关系 |
1..* |
表示另一个类的一个对象与一个或多个该类对象有关系 |
0..1 |
表示另一个类的一个对象没有或只与一个该类对象有关系 |
m..n |
表示另一个类的一个对象与最少m、最多n个该类对象有关系 (m<=n) |
- public class Form
- {
- private Button buttons[];
- ……
- }
- public class Button
- {
- …
- }
聚合关系(Aggregation):表示的是整体和部分的关系,整体与部分 可以分开.
- public class Car
- {
- private Engine engine;
- public Car(Engine engine)
- {
- this.engine = engine;
- }
- public void setEngine(Engine engine)
- {
- this.engine = engine;
- }
- ……
- }
- public class Engine
- {
- ……
- }
如:电话机包括一个话筒
电脑包括键盘、显示器,一台电脑可以和多个键盘、多个显示器搭配,确定键盘和显示器是可以和主机分开的,主机可以选择其他的键盘、显示器组成电脑;
组合关系(Composition):也是整体与部分的关系,但是整体与部分不可以分开.
- public class Head
- {
- private Mouth mouth;
- public Head()
- {
- mouth = new Mouth();
- }
- ……
- }
- public class Mouth
- {
- ……
- }
如:公司和部门,部门是部分,公司是整体,公司A的财务部不可能和公司B的财务部对换,就是说,公司A不能和自己的财务部分开; 人与人的心脏.
实现关系(Implementation):是用来规定接口和实线接口的类或者构建结构的关系,接口是操作的集合,而这些操作就用于规定类或者构建的一种服务。
- public interface Vehicle
- {
- public void move();
- }
- public class Ship implements Vehicle
- {
- public void move()
- {
- ……
- }
- }
- public class Car implements Vehicle
- {
- public void move()
- {
- ……
- }
- }
UML的9中图例概述
作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。
l UML语义:描述基于UML的精确元模型定义。
l UML表示法:定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。
标准建模语言UML可以由下列5类图来定义。
l 用例图:从用户角度描述系统功能,并指出各功能的操作者。
l 静态图:包括类图和对象图。类图描述系统中类的静态结构,不仅定义系统中的类,表示类之间的联系,如关联、依赖、聚合等,也包括类的属性和操作,类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
l 行为图:描述系统的动态模型和组成对象间的交互关系,包括状态图和活动图。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件,状态图是对类图的补充,活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并进行活动。
l 交互图:描述对象间的交互关系,包括时序图和协作图。时序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;协作图描述对象间的协作关系,协作图跟时序图相似,显示对象间的动态合作关系。除显示信息交换外,协作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用时序图;如果强调上下级关系,则选择协作图。
l 实现图:包括组件图和部署图。组件图描述代码部件的物理结构及各部件之间的依赖关系,组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。
采用UML来设计系统时,第一步是描述需求;第二步根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图、对象图、组件图和部署图等5种图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、时序图和协作图等4种图形,是标准建模语言UML的动态建模机制。
首先对UML中的各个图的功用做一个简单介绍:
和序列图相似,显示对象间的动态合作关系。可以看成是类图和顺序图的交集,协作图建模对象或者角色,以及它们彼此之间是如何通信的。如果强调时间和顺序,则使用序列图;如果强调上下级关系,则选择协作图;这两种图合称为交互图。
一:这九种模型图各有侧重,
1:用例图侧重描述用户需求,
2:类图侧重描述系统具体实现;
二:描述的方面都不相同,
1:类图描述的是系统的结构,
2:序列图描述的是系统的行为;
三:抽象的层次也不同,
1:构件图描述系统的模块结构,抽象层次较高,
2:类图是描述具体模块的结构,抽象层次一般,
3:对象图描述了具体的模块实现,抽象层次较低。
在有的文献书籍中,将这九种模型图分为三大类:
结构分类、动态行为和模型管理:
1:结构分类包括用例图、类图、对象图、构件图和部署图,
2:动态行为包括状态图、活动图、顺序图和协作图,
3:模型管理则包含类图。
画图说明
UML中有3种构造块:事物、关系和图,事物是对模型中最具有代表性的成分的抽象;关系是把事物结合在一起;图聚集了相关的的事物。具体关系图标如下:
说明:
构件事物是名词,是模型的静态部分。
行为事物是动态部分,表示行为。
分组事物是组织部分。
注释事物是解释部分。
聚集:特殊的关联,描述整体与部分的组合关系。
泛化:是一种特殊与一般的关系,如子元素(特殊)与父元素(一般),箭头指向父元素。
实现:类元之间的关系,其中一个类元指定了由另一个类元保证执行的契约。一般用在接口和实现他们的类之间或用例和实现它们的协作之间。
在UML系统开发中有三个主要的模型:
对象模型: 采用对象,属性,操作,关联等概念展示系统的结构和基础,包括类图。
动态模型: 展现系统的内部行为。 包括序列图,活动图,状态图。
下面具体说明:
1.类图:描述一组对象、接口、协作等事物之间的关系。如下图(摘自网络):
3.用例图:描述一组用例、参与者以及它们之间的关系,其展示的是该系统在它的外面环境中所提供的外部可见服务。如下图(摘自网络):
4.交互图:包括序列图(顺序图)和协作图,两者对应,顺序图是强调消息时间顺序,有对象生命线和控制焦点。协作图是强调接收和发送消息的对象的结构组织,有路径和顺序号。如下图(摘自网络):
5.状态图:展示了一个状态机,由状态、转换、事件和活动组成。强调事件行为的顺序。如下图(摘自网络):
UML中的几种关系详细解析
在UML类图中,常见的有以下几种关系: 泛化(Generalization), 实现(Realization),关联(Association),聚合(Aggregation),组合(Composition),依赖(Dependency)
1. 泛化(Generalization)
【泛化关系】:是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。例如:老虎是动物的一种,即有老虎的特性也有动物的共性。
【箭头指向】:带三角箭头的实线,箭头指向父类
2. 实现(Realization)
【实现关系】:是一种类与接口的关系,表示类是接口所有特征和行为的实现.
【箭头指向】:带三角箭头的虚线,箭头指向接口
3. 关联(Association)
【关联关系】:是一种拥有的关系,它使一个类知道另一个类的属性和方法;如:老师与学生,丈夫与妻子关联可以是双向的,也可以是单向的。双向的关联可以有两个箭头或者没有箭头,单向的关联有一个箭头。
【代码体现】:成员变量
【箭头及指向】:带普通箭头的实心线,指向被拥有者
上图中,老师与学生是双向关联,老师有多名学生,学生也可能有多名老师。但学生与某课程间的关系为单向关联,一名学生可能要上多门课程,课程是个抽象的东西他不拥有学生。
下图为自身关联:
4. 聚合(Aggregation)
【聚合关系】:是整体与部分的关系,且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。
聚合关系是关联关系的一种,是强的关联关系;关联和聚合在语法上无法区分,必须考察具体的逻辑关系。
【代码体现】:成员变量
【箭头及指向】:带空心菱形的实心线,菱形指向整体
5. 组合(Composition)
【组合关系】:是整体与部分的关系,但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系,没有公司就不存在部门。
组合关系是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
【代码体现】:成员变量
【箭头及指向】:带实心菱形的实线,菱形指向整体
6. 依赖(Dependency)
【依赖关系】:是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖.
【代码表现】:局部变量、方法的参数或者对静态方法的调用
【箭头及指向】:带箭头的虚线,指向被使用者
各种关系的强弱顺序:
泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
下面这张UML图,比较形象地展示了各种类图关系:
UML几种图介绍
用例图
用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求,包括基于基本流程的"角色"(actors,也就是与系统交互的其他实体)关系,以及系统内用例之间的关系。用例图一般表示出用例的组织关系 —— 要么是整个系统的全部用例,要么是完成具有功能(例如,所有安全管理相关的用例)的一组用例。要在用例图上显示某个用例,可绘制一个椭圆,然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个角色(表示一个系统用户),可绘制一个人形符号。角色和用例之间的关系使用简单的线段来描述,如图1所示。
图1:示例用例图
图字(从上到下):CD销售系统;查看乐队CD的销售统计;乐队经理;查看Billboard 200排行榜报告;唱片经理;查看特定CD的销售统计;检索最新的Billboard 200排行榜报告;排行榜报告服务
用例图通常用于表达系统或者系统范畴的高级功能。如图1所示,可以很容易看出该系统所提供的功能。这个系统允许乐队经理查看乐队CD的销售统计报告以及Billboard 200排行榜报告。它也允许唱片经理查看特定CD的销售统计报告和这些CD在Billboard 200排行榜的报告。这个图还告诉我们,系统将通过一个名为"排行榜报告服务"的外部系统提供Billboard排行榜报告。
此外,在用例图中,没有列出的用例表明了该系统不能完成的功能。例如,它不能提供给乐队经理收听Billboard 200上不同专辑中的歌曲的途径 —— 也就是说,系统没有引用一个叫做"收听Billboard 200上的歌曲"的用例。这种缺少不是一件小事。在用例图中提供清楚的、简要的用例描述,项目赞助商就很容易看出系统是否提供了必须的功能。
类图表示不同的实体(人、事物和数据)如何彼此相关;换句话说,它显示了系统的静态结构。类图可用于表示逻辑类,逻辑类通常就是业务人员所谈及的事物种类 —— 摇滚乐队、CD、广播剧;或者贷款、住房抵押、汽车信贷以及利率。类图还可用于表示实现类,实现类就是程序员处理的实体。实现类图或许会与逻辑类图显示一些相同的类。然而,实现类图不会使用相同的属性来描述,因为它很可能具有对诸如Vector和HashMap这种事物的引用。
类在类图上使用包含三个部分的矩形来描述,如图2所示。最上面的部分显示类的名称,中间部分包含类的属性,最下面的部分包含类的操作(或者说"方法")。
图2:类图中的示例类对象
根据我的经验,几乎每个开发人员都知道这个类图是什么,但是我发现大多数程序员都不能正确地描述类的关系。对于像图3这样的类图,您应该使用带有顶点指向父类的箭头的线段来绘制继承关系1,并且箭头应该是一个完全的三角形。如果两个类都彼此知道对方,则应该使用实线来表示关联关系;如果只有其中一个类知道该关联关系,则使用开箭头表示。
图3:一个完整的类图,包括了图2所示的类对象
在图3中,我们同时看到了继承关系和两个关联关系。CDSalesReport类继承自Report类。一个CDSalesReport类与一个CD类关联,但是CD类并不知道关于CDSalesReport类的任何信息。CD类和Band类都彼此知道对方,两个类彼此都可以与一个或者多个对方类相关联。
一个类图可以整合其他许多概念,这将在本系列文章的后续文章中介绍。
序列图显示具体用例(或者是用例的一部分)的详细流程。它几乎是自描述的,并且显示了流程中不同对象之间的调用关系,同时还可以很详细地显示对不同对象的不同调用。
序列图有两个维度:垂直维度以发生的时间顺序显示消息/调用的序列;水平维度显示消息被发送到的对象实例。
序列图的绘制非常简单。横跨图的顶部,每个框(参见图4)表示每个类的实例(对象)。在框中,类实例名称和类名称之间用空格/冒号/空格来分隔,例如,myReportGenerator : ReportGenerator。如果某个类实例向另一个类实例发送一条消息,则绘制一条具有指向接收类实例的开箭头的连线,并把消息/方法的名称放在连线上面。对于某些特别重要的消息,您可以绘制一条具有指向发起类实例的开箭头的虚线,将返回值标注在虚线上。就我而言,我总喜欢绘制出包括返回值的虚线,这些额外的信息可以使得序列图更易于阅读。
阅读序列图也非常简单。从左上角启动序列的"驱动"类实例开始,然后顺着每条消息往下阅读。记住:虽然图4所示的例子序列图显示了每条被发送消息的返回消息,但这只是可选的。
图4:一个示例序列图
通过阅读图4中的示例序列图,您可以明白如何创建一个CD销售报告(CD Sales Report)。其中的aServlet对象表示驱动类实例。aServlet向名为gen的ReportGenerator类实例发送一条消息。该消息被标为generateCDSalesReport,表示ReportGenerator对象实现了这个消息处理程序。进一步理解可发现,generateCDSalesReport消息标签在括号中包括了一个cdId,表明aServlet随该消息传递一个名为cdId的参数。当gen实例接收到一条generateCDSalesReport消息时,它会接着调用CDSalesReport类,并返回一个aCDReport的实例。然后gen实例对返回的aCDReport实例进行调用,在每次消息调用时向它传递参数。在该序列的结尾,gen实例向它的调用者aServlet返回一个aCDReport。
请注意:图4中的序列图相对于典型的序列图来说太详细了。然而,我认为它才是足够易于理解的,并且它显示了如何表示嵌套的调用。对于初级开发人员来说,有时把一个序列分解到这种详细程度是很有必要的,这有助于他们理解相关的内容。
状态图表示某个类所处的不同状态和该类的状态转换信息。有人可能会争论说每个类都有状态,但不是每个类都应该有一个状态图。只对"感兴趣的"状态的类(也就是说,在系统活动期间具有三个或更多潜在状态的类)才进行状态图描述。
如图5所示,状态图的符号集包括5个基本元素:初始起点,它使用实心圆来绘制;状态之间的转换,它使用具有开箭头的线段来绘制;状态,它使用圆角矩形来绘制;判断点,它使用空心圆来绘制;以及一个或者多个终止点,它们使用内部包含实心圆的圆来绘制。要绘制状态图,首先绘制起点和一条指向该类的初始状态的转换线段。状态本身可以在图上的任意位置绘制,然后只需使用状态转换线条将它们连接起来。
图5中的状态图显示了它们可以表达的一些潜在信息。例如,从中可以看出贷款处理系统最初处于Loan Application状态。当批准前(pre-approval)过程完成时,根据该过程的结果,或者转到Loan Pre-approved状态,或者转到Loan Rejected状态。这个判断(它是在转换过程期间做出的)使用一个判断点来表示 —— 即转换线条间的空心圆。通过该状态图可知,如果没有经过Loan Closing状态,贷款不可能从Loan Pre-Approved状态进入Loan in Maintenance状态。而且,所有贷款都将结束于Loan Rejected或者Loan in Maintenance状态。
活动图表示在处理某个活动时,两个或者更多类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模,或者对低级别的内部类操作进行建模。根据我的经验,活动图最适合用于对较高级别的过程建模,比如公司当前在如何运作业务,或者业务如何运作等。这是因为与序列图相比,活动图在表示上"不够技术性的",但有业务头脑的人们往往能够更快速地理解它们。
活动图的符号集与状态图中使用的符号集类似。像状态图一样,活动图也从一个连接到初始活动的实心圆开始。活动是通过一个圆角矩形(活动的名称包含在其内)来表示的。活动可以通过转换线段连接到其他活动,或者连接到判断点,这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一个终止点(就像在状态图中一样)。作为一种选择,活动可以分组为泳道(swimlane),泳道用于表示实际执行活动的对象,如图6所示。
图6:活动图,具有两个泳道,表示两个对象的活动控制:乐队经理,以及报告工具
图字(沿箭头方向):乐队经理;报告工具;选择"查看乐队的销售报告";检索该乐队经理所管理的乐队;显示报告条件选择屏幕;选择要查看其销售报告的乐队;从销售数据库检索销售数据;显示销售报告。
该活动图中有两个泳道,因为有两个对象控制着各自的活动:乐队经理和报告工具。整个过程首先从乐队经理选择查看他的乐队销售报告开始。然后报告工具检索并显示他管理的所有乐队,并要求他从中选择一个乐队。在乐队经理选择一个乐队之后,报告工具就检索销售信息并显示销售报告。该活动图表明,显示报告是整个过程中的最后一步。
组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件组件(例如,库函数)的依赖关系。组件图可以在一个非常高的层次上显示,从而仅显示粗粒度的组件,也可以在组件包层次2上显示。
组件图的建模最适合通过例子来描述。图7显示了4个组件:Reporting Tool、Billboard Service、Servlet 2.2 API和JDBC API。从Reporting Tool组件指向Billboard Service、Servlet 2.2 API和JDBC API组件的带箭头的线段,表示Reporting Tool依赖于那三个组件。
图7:组件图显示了系统中各种软件组件的依赖关系
部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行,以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模,系统的生产人员就可以很好地利用这种图。
部署图中的符号包括组件图中所使用的符号元素,另外还增加了几个符号,包括节点的概念。一个节点可以代表一台物理机器,或代表一个虚拟机器节点(例如,一个大型机节点)。要对节点进行建模,只需绘制一个三维立方体,节点的名称位于立方体的顶部。所使用的命名约定与序列图中相同:[实例名称] : [实例类型](例如,"w3reporting.myco.com : Application Server")。
图8:部署图
图字:由于Reporting Tool组件绘制在IBM WebSphere内部,后者又绘制在节点w3.reporting.myco.com内部,因而我们知道,用户将通过运行在本地机器上的浏览器来访问Reporting Tool,浏览器通过公司intranet上的HTTP协议与Reporting Tool建立连接。
图8中的部署图表明,用户使用运行在本地机器上的浏览器访问Reporting Tool,并通过公司intranet上的HTTP协议连接到Reporting Tool组件。这个工具实际运行在名为w3reporting.myco.com的Application Server上。这个图还表明Reporting Tool组件绘制在IBM WebSphere内部,后者又绘制在w3.reporting.myco.com节点内部。Reporting Tool使用Java语言通过IBM DB2数据库的JDBC接口连接到它的报告数据库上,然后该接口又使用本地DB2通信方式,与运行在名为db1.myco.com的服务器上实际的DB2数据库通信。除了与报告数据库通信外,Report Tool组件还通过HTTPS上的SOAP与Billboard Service进行通信。
尽管本文仅提供了对统一建模语言UML的简要介绍,但还是鼓励大家把从这里学到的基本信息应用到自己的项目中,同时更深入地钻研UML。已经有多种软件工具可以帮助您把UML图集成到软件开发过程中,不过即使没有自动化的工具,您也可以使用白板上的标记或者纸和笔来手工绘制UML图,仍然会获益匪浅。
UML之用例图解析
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
【用途】:帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图所包含的元素如下:
1. 参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
2. 用例(Use Case)
用例就是外部可见的系统功能,对系统提供的服务进行描述。用椭圆表示。
3. 子系统(Subsystem)
用来展示系统的一部分功能,这部分功能联系紧密。
4. 关系
用例图中涉及的关系有:关联、泛化、包含、扩展。
如下表所示:
a. 关联(Association)
表示参与者与用例之间的通信,任何一方都可发送或接受消息。
【箭头指向】:指向消息接收方
b. 泛化(Inheritance)
就是通常理解的继承关系,子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。
【箭头指向】:指向父用例
c. 包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
【箭头指向】:指向分解出来的功能用例z
d. 扩展(Extend)
扩展关系是指用例功能的延伸,相当于为基础用例提供一个附加功能。
【箭头指向】:指向基础用例
e. 依赖(Dependency)
以上4种关系,是UML定义的标准关系。但VS2010的用例模型图中,添加了依赖关系,用带箭头的虚线表示,表示源用例依赖于目标用例。
【箭头指向】:指向被依赖项
5. 项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求,但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强,VS2010中引入了“项目”这样一个元素,以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上:
然后把项目-》属性 的Hyperlink设置到你的文档上;
这样当你在用例图上双击项目时,就会打开相关联的文档。
6. 注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance) 的区别:
条件性:泛化中的子用例和include中的被包含的用例会无条件发生,而extend中的延伸用例的发生是有条件的;
直接性:泛化中的子用例和extend中的延伸用例为参与者提供直接服务,而include中被包含的用例为参与者提供间接服务。
对extend而言,延伸用例并不包含基础用例的内容,基础用例也不包含延伸用例的内容。
对Inheritance而言,子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系;
一个用例图示例:
牢骚:
感觉用例图还不成熟,并不能很好地表达系统的需求, 没有UML背景的用户几乎不知道画的是些什么。
其次,包含关系、扩展关系的箭头符号竟然是同样的箭头,仅靠上方写个文字来加以区别,翻译成其他语言的话,几乎就不知道代表什么意思。扩展关系的箭头朝向也很难理解,为何要指向基用例,而不指向扩展用例。
VS2010添加的“项目”元素,是个很好的创新,能够在用例图中关联word, excel这些文档。但为什么不把这些功能直接集成到用例里面,双击用例就弹出一份文档岂不更容易理解,非要画蛇添足地加一个元件,仅仅为了提供个链接功能。
用例描述表:
鉴于用列图并不能清楚地表达功能需求,开发中大家通常用描述表来补充某些不易表达的用例,下图的表给大家提供一个参考:
UML之序列图解析
序列图主要用于展示对象之间交互的顺序。
序列图将交互关系表示为一个二维图。纵向是时间轴,时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时,角色用一条虚线表示,当对象的过程处于激活状态时,生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。
序列图中涉及的元素:
1. 生命线:
生命线名称可带下划线。当使用下划线时,意味着序列图中的生命线代表一个类的特定实例。
2. 同步消息
发送人在它继续之前,将等待同步消息响应。
3. 异步消息
在发送方继续之前,无需等待响应的消息。
4. 注释
5. 约束
约束的符号很简单;格式是: [Boolean Test]
6. 组合片段
组合片段用来解决交互执行的条件及方式。它允许在序列图中直接表示逻辑组件,用于通过指定条件或子进程的应用区域,为任何生命线的任何部分定义特殊条件和子进程。
常用的组合片段有:
抉择(Alt)
抉择用来指明在两个或更多的消息序列之间的互斥的选择,相当于经典的if..else..。
抉择在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。else 的临界指示其他任何临界都不为 True 时应运行的片段。如果所有临界都为 False 并且没有 else,则不执行任何片段。
选项(Opt)
包含一个可能发生或不发生的序列
循环(Loop)
片段重复一定次数。 可以在临界中指示片段重复的条件。
并行(Par)
下表列出了常用的组合片段:
片段类型 |
名称 |
说明 |
Opt |
选项 |
包含一个可能发生或可能不发生的序列。 可以在临界中指定序列发生的条件。 |
Alt |
抉择 |
包含一个片段列表,这些片段包含备选消息序列。 在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。 else 的临界指示其他任何临界都不为 True 时应运行的片段。 如果所有临界都为 False 并且没有 else,则不执行任何片段。 |
Loop |
循环 |
片段重复一定次数。 可以在临界中指示片段重复的条件。 Loop 组合片段具有“Min”和“Max”属性,它们指示片段可以重复的最小和最大次数。 默认值是无限制。 |
Break |
中断 |
如果执行此片段,则放弃序列的其余部分。 可以使用临界来指示发生中断的条件。 |
Par |
并行 |
并行处理。 片段中的事件可以交错。 |
Critical |
关键 |
用在 Par 或 Seq 片段中。 指示此片段中的消息不得与其他消息交错。 |
Seq |
弱顺序 |
有两个或更多操作数片段。 涉及同一生命线的消息必须以片段的顺序发生。 如果消息涉及的生命线不同,来自不同片段的消息可能会并行交错。 |
Strict |
强顺序 |
有两个或更多操作数片段。 这些片段必须按给定顺序发生。 |
有关如何解释序列的片段
默认情况下,序列图表明可能发生的一系列消息。 在运行的系统中,可能会出现您未选择显示在关系图上的其他消息。
以下片
以上是关于转UML的9种图例解析的主要内容,如果未能解决你的问题,请参考以下文章