最常用的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:显示类通过某个功能系统的各种状态的状态图

图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图,仍然会 获益匪浅。

时间: 2024-12-15 01:40:02

最常用的UML图包括:用例图、类图、序列图、状态图、活动图、组件图和部署图的相关文章

你的UML第一张图是用例图么?(1)——活动图为开端

前言: 如果你的UML图第一章还是用例图请你继续看下去:如果你不知道业务分析图和活动图的关系,请你继续看下去:如果你的机房无论是重构还是合作出现遗漏功能(我重构的时候就把操作员工作记录查询给漏了)请你继续看下去. 一.需求分析的误区 事实上,我机房合作是做了很久很久,事实上代码我们早就敲完了,但是我还是坚持不去结束项目,原因很简单,我想通过机房真正的对于软工有所了解和体会.机房合作的时候我犯了一个致命的错误,我是按照功能分析需求的.举个例子: 机房有一个操作员工作查询记录的功能,我当时只是草草幻

设计模式1 UML基本使用 用例图,类图(关联依赖聚合组合),时序图,活动图,包图,组件图,

StartUML下载 http://staruml.io/ 1,基本使用 用例图: 保存为图片: 泛化关系图: 包含于扩展图: 人事管理系统图:

Python设计模式 - UML - 组件图(Component Diagram)

简介 组件图又称构建图,用于显示系统各组件及各组件关系的物理视图. 组件图通常包括组件.接口.关系.端口和连接器,用来显示程序代码中相应的模块.源文件或源文件集合之间的依赖和泛化关系. 组件图中的组件通常由类图中的一个或多个类(对象)实现为系统中的模块.源文件.过程文件或可执行文件,最终构成系统的绝大部分功能单元. 组件图建模步骤 - 确定系统有哪些对外接口或端口 - 确定系统要用到哪些组件,识别出系统中的重要模块.库文件.源代码文件.数据表或文件.可执行文件或文档等,将其建模为一个个组件 -

UML九种图 之 用例图

前言     最近写UML文档,看视频的时候感觉掌握的还可以,当真正写文档的时候才发现不是一件容易的事.写文档自己又翻开自己的笔记看了一遍又一遍. 下面就给大家介绍一下我画的几张图: 用例图     1. 用例图的构成         (用例,角色,关系)         用例:指功能的描述         角色:触发起某种事件         关系:用例图的关系(依赖,泛化,关联)     2. 用例图的作用         (1)用例视图是整个UML设计的关键,影响到整个UML设计的过程  

UML九种图 之 用例图和类图

前言     近期写UML文档,看视频的时候感觉掌握的还能够,当真正写文档的时候才发现不是一件easy的事.写文档自己又翻开自己的笔记看了一遍又一遍. 以下就给大家介绍一下我画的几张图: 用例图     1. 用例图的构成         (用例,角色,关系)         用例:指功能的描写叙述         角色:触发起某种事件         关系:用例图的关系(依赖,泛化,关联)     2. 用例图的作用         (1)用例视图是整个UML设计的关键,影响到整个UML设计的

UML学习之用例图

在UML的整个学习过程中,9种图(用例图.活动图.状态图.顺序图.类图.对象图.协作图.组件图.部署图)的学习以及常用开发.建模工具的使用是最为重要的一个阶段,它是进行UML建模的基础.在本篇文章中首先介绍下用例图(Use Case Diagram). 用例图概念 1.概念及作用:用例图描述的是开发人员与用户交流后完成的图,用来表达待系统的功能性需求和行为,它由参与者(Actor).用例(Use Case).子系统(Subsystem)以及构成它们之间的关系组成,主要用于对系统.子系统或类的功能

UML--用例图

一.UML概述 1.UML的作用:a 把复杂的问题分解   b 实现了可视化 UML是由Rational公司创建的 2.UML是什么:是一种语言,有属于自己的标准表达规则,是一种分析设计语言,也是一种建模语言 3.UML包括五大视图,13种图 五大视图: 用户视图: 用例图 行为视图:顺序图,状态图,活动图,通信图,定时图,交互概览图 结构视图:类图,包图,对象图,组合结构图 环境视图:部署图 实现视图:组件图 使用频率最高的是用例图和类图 二.UML构造需求模型 绘制用例图-->编写用例文档-

UML之轻松入门(1)-类图

曾经看到过一篇blog,上面探讨了学习UML和学习设计模式的区别,同时提出了学习UML还不如学习设计模式的观点.自我感受是,UML和设计模式在本质上属于完全不同的两个方向.设计模式是一种被反复使用.多数人知晓的.代码设计经验的总结.它可以更容易让人理解而且保证了代码的可靠性,而UML则是一种模型化和可视化的一种语言.可以这么说,设计模式是一种方法,它让我们的代码更有层次感 .而UML则是一种表达,它让我们的代码更加形象化.通过UML我们不必太过关注代码,不必担心客户是否了解相关的语言知识,整体的

转载:UML学习(二)-----类图(silent)

原文:http://www.cnblogs.com/huiy/p/8552607.html 1.什么是类图 类图(Class diagram)主要用于描述系统的结构化设计.类图也是最常用的UML图,用类图可以显示出类.接口以及它们之间的静态结构和关系. 2.类图的元素 在类图中一共包含了以下几种模型元素,分别是:类(Class).接口(Interface).依赖(Dependency)关系.泛化(Generalization)关系.关联(Association)关系.聚合关系(Aggregati