在画用例图的时候，理清用例之间的关系是重点。用例的关系有泛化(generalization)、扩展(extend)和包含(include)。其中include和extend最易混淆。下面我们结合实例彻底理清三者的关系。
用例图（Use Case Diagram）:用例图显示谁是相关的用户，用户希望系统提供什么服务（用例），以及用例之间的关系图。用例图主要的作用是获取需求、指导测试。
用例图的4个基本组件：参与者(Actor)、用例(Use Case)、关系(Relationship)和系统。
泛化(generalization)：泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。
扩展(extend)： extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示(在线上标注&&extend&&)，箭头从子用例指向基用例。
包含(include)： include为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注&&include&&)，箭头从基用例指向子用例。
实例需求场景
联通客户响应OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。
需求1：客户响应用户和国际客服可以进行割接通知查询，在页面上有骨干割接查询、省间割接查询、省级割接查询的Tab。
分析：可以很容易看出割接查询和不同的割接子查询Tab之间是继承的关系，所以此处用泛化。用户和客户响应、国际客服也是继承的Actor关系。
需求2：客户响应用户和国际客服可以查看某条割接通知信息，可以在页面上导出割接信息Excel格式，可以查询和该条割接相关联的故障单信息。
分析：因为导出割接和查看相关联的故障单信息都是可选的，就是说我查看割接的时候，也可以不进行这些操作，所以这里用extend关系。也就是导出割接和查看故障单信息扩展了查看割接信息。
需求3：客户响应用户可以以网管系统为来源创建割接通知，在创建割接通知时可以保存为草稿，也可以直接发布割接通知。
分析：由于创建割接通知时，发布割接通知可以同时进行，也可以先存为草稿，所以发布割接是可选的，用extend就比较合适。也就是发布割接扩展了创建割接通知。
需求4：用户在进行业务开通、发布割接通知、发布重保通知及相关跨省的业务时需要进行数据分发。
分析：由于业务开通、重保、割接及其它跨省的业务都需要用到数据分发用例，我们可以将数据分发用例单独抽出来，供各业务使用，这里用include就比较合适。实际的系统中数据分发也是单独抽出来用jms和webservice实现的接口服务。
其它需求：可以看到删除割接通知和查看割接明细也可以做为割接通知查询用例的扩展，因查询列表时，一般可以选择继续查看明细或者删除操作。但在实际化图中，这两个extend可以不画，这里只是为了让大家理解概念。
用例图：大家可以参照着图，好好理解。
我们再用另外一个场景的用例说明一下include和extend,因为就这两个玩意比较容易搞混。
销户：因为销户必需先进行账户结算，所以这里用include
停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend.
阅读(...) 评论()[转载]UML--建模
已有 2796 次阅读
|个人分类:|系统分类:|关键词:建模 VISIO UML|文章来源:转载
使用Visio进行UML建模
内容提纲：
、VISIO中的UML建模环境
& &Microsoft Visio“UML 模型图”解决方案为创建复杂软件系统的面向对象的模型提供全面的支持。包括下列工具、形状和功能：
&& n&“UML 模型资源管理器”，它提供模型的树视图和在视图间进行浏览的手段。&& n& 预定义的智能形状，表示 UML 标注中的元素并支持 UML 图表类型的创建。在程序控制下，这些形状的运行方式同 UML 语义学相符。&& n& 易于访问“UML 属性”对话框，可通过这些对话框将名称、特性、操作和其他属性添加到 UML 元素。&& n& 标识和诊断错误（例如丢失数据或不正确地使用 UML 表示法）的动态语义错误检查。&& n& 对用 Microsoft Visual C++ 6.0 或 Microsoft Visual Basic 6.0 创建的项目进行反向工程，以生成 UML 静态结构模型的能力。&& n& 使用 C++、Visual C# 或 Microsoft Visual Basic 根据 UML 模型中的类定义生成代码框架。&& n& 标识特定于语言的错误的代码检查实用程序，这些错误可使代码无法用您为生成代码指定的目标语言编译出来。&& n &为 UML 静态结构、活动、状态图、组件和部署图创建报告
& 模型资源管理器的使用
& 当您打开“UML 模型图”解决方案时，您就打开了一个建模环境，并且从开始时模型便已经就位。
& 如果没有显示出“模型资源管理器”,可以单击“UML”菜单—&“视图”—&“模型资源管理器”
& “UML 模型资源管理器”中的树状视图表示您的总体系统模型。您创建的图表都是该模型的视图。
表示您当前正在建模的系统中。若要添加模型，请在“UML”菜单上单击“模型”。
在这种情况下，将您系统的一个模型或抽象内容表示为静态结构模型。要重命名树状视图中的任何图标，请对图标的文本单击一次，然后再单击一次该文本。键入新的名称。
表示静态结构模型中最上层的包。包是一种容器。此软件包含有所有静态结构模型元素。
默认情况下，新模型所包括的包会含有常见的数据类型。您可以创建含有您自己的数据类型的包。
单击加号 (+) 显示包的内容。单击减号隐藏包的内容。
&&& 得到图（1）的步骤如下：
&&&&& A．& 将最顶层包的默认名称改为“PetShop”：单击右键，选择“重命名”
&&&&& B．& 将包“静态模型“改名为“Design Model”：单击右键，选择“重命名”
&&&&& C．其他包命名依次类推
、用例图(USE CASE Diagram)的使用
用例图的组成
& 用例图表示处于同一个系统中参与者和用例之间的关系。是一组动作序列（包括它的变衍生物）的描述，系统执行该动作序列来为参与者产生一个可观测的结果值。在VISIO中包括三部分：
角色(ACTOR)
&&& 表示活动的发起者，VISIO中用表示。
用例(USE Case)
&&& 实际的场景，如登陆系统,物品进仓，VISIO中用表示表示。
系统边界 指示系统用例的边界，用来确定系统内部和外部之间的界限。用矩形框表示。
创建用例图
& 假设(1)，我们有个仓库系统，有三个活动(用例)：物品进仓，物品出仓和显示物品的库存.当出仓的时候要检查物品的库存情况，如果库存小于5就不能出仓。活动的执行者是仓库管理员(这些都是来自需求文档)，出入仓时管理员需要开据出入仓单.本示例我们主要考虑出仓情况。
建立角色(Actor)
& 在“图 1”中选择“Actors package”，单击右键，选择“主角”,输入“名称”，如图2、图3所示：
& 在图1中选择“Usercases”,单击右键,选择“用例”,输入“名称”，如图4，图5所示：
.2.3 建立角色和用例的通信
& 在VISIO中表示为：
建立用例间的关系
A.使用关系
在用例图中，将“使用”关系形状拖到绘图页上；
将“使用”端点（不带箭头）粘附到使用其他用例方式的“用例”形状的连接点*上；
将“使用”端点（带有箭头）粘附到正使用的用例的连接点上；
双击“使用”形状，打开“UML 归纳属性”对话框。添加属性值，然后单击“确定”。
B.扩展关系
在用例图中，将“扩展”形状拖到绘图页上；
将不带箭头的“扩展”端点+粘附到提供扩展的用例的连接点+上；
将带有箭头的“扩展”端点粘附到基础用例的连接点上；
双击“扩展”形状，打开“UML 归纳属性”对话框。添加属性值，然后单击“确定”。
建立用例图
& 在图 1中选择“Usecase Model”，单击右键,选择“用例图”，这里保留默认的名称。然后就可以将我们已经建立的角色和用例从左边的树拖动到右边的空白区了，同时还需要建立系统边界，从假设(1)我们得知出仓要检查物品的库存，因此用例“货物出仓”要使用用例“显示物品的库存”（没有“显示库存”用例“货物出仓”用例就不完整）。而对于用例“物品进仓”，仓库管理员也可以在进仓的同时来检查物品的库存情况，因此两者之间是扩展关系（“货物出仓”用例本身功能完整，但管理员也可以在某些时候查看库存），另外仓库管理员还可以直接查看库存信息，完成后的用例图如下：
注意：如要了解创建用例图的更多知识，请参看 Visio 联机帮助。
、活动图的建立
活动图的组成
泳道：用来表示活动图中的责任，是个矩形；
状态：用来表示某个活动或动作，分为“动作状态”，“状态”，“初始状态”，“最终状态”；
控制流：表示从一个状态到另一个状态的变化。
创建活动图
& 根据假设(1)我们创建物品出仓的活动图,步骤如下:
在图1中选择包“Usecases”，单击右键选择“活动图”；
将泳道拖到右边，双击泳道重命名为“物品出仓”。将“初始状态”从左边拖动到右边空白区
将三个“动作状态”拖到右边，分别命名为“申请出仓”，“选择仓库”和“判断库存”，然后在三者之间增加控制流；
将“判定”流程拖到右边，增加两个控制流，双击控制流分别输入临界表达式：成功和失败；
将“最终状态”拖到右边.连接步骤4中的两个控制流。
&&& 最后的结果如下：
注意：1：该图的“合并”（由顶至下第三个菱形）是UML工业标准，Visio暂时不支持该图标。2：如要了解创建活动图的更多知识，请参看 Visio 联机帮助。
、静态结构图(Static Structure Diagram)的使用
& 在VISIO中有两种静态结构图:概念静态结构图和类静态结构图。概念静态结构图是表示现实世界中的概念以及它们之间的关系。它侧重于关系和属性而不是方法，并有助于您了解开发的系统所针对的领域内的术语。
& 类静态结构图是将软件系统分解为各个部分。不过在类图中，各部分指的是类，代表已经完整定义的软件实体，而并不是代表现实世界概念的对象。除属性和关联之外，类图还可指定操作、方法、界面和依赖关系。
& 我们重点介绍类静态结构图。
类静态结构图的组成
& 类静态结构图是由类或对象组成的，在VISIO中用来表示，类之间的关系主要有关联，依赖和归纳三种：
& 关联是用、、表示
& 依赖是用表示
& 继承(归纳)是用表示的
创建类静态结构图
& 在图1中选择“staticview”，单击右键选择“静态结构图”，然后从右边选择Class图标拖动至右边的空白区中：
& 将类的图标从左边拖动至于右边。输入类的名称、属性和方法：
& 根据假设(1)，仓库系统里有如下类：
& GoodsOutput(出仓单),GoodsOutputItem(出仓项目),StoreHouse(仓库类)、Product(物品类)、Manager(仓库管理员类)、StoreHouseControl(仓库控制类)、People(人员类)，依次建立。
类间关系的建立
& 通过分析我们得知一个仓库里可以包含有很多的物品，即两者是关联关系(一对多)。而Manager是从People继承而来。因此可以使用“继承”图形。
& 关联关系：
将一个“二元关联”形状从“UML 静态结构”模具拖到要关联的类旁边的绘图页上；
将关联形状的端点粘附到该类形状的连接点*上；
双击该“关联”形状，打开其“UML 属性”对话框，然后输入或选择要设定的属性值；
单击“确定”。
& 继承关系：
将“继承”形状从“UML 静态结构”模具拖到要关联的类或包旁边的绘图页上。
将箭头旁边的端点粘附到更普通元素的连接点*上。将没有箭头的端点粘附到更具体元素的连接点上。
双击该“归纳”形状。在“UML 归纳属性”对话框中，添加名称、构造型、鉴别器和其他属性值，然后单击“确定”。
&&& 静态图如下：
注意：如要了解创建静态结构图的更多知识，请参看 Visio 联机帮助。
、序列图(Sequence Diagram)的建立
& 序列图显示参与交互作用的角色或对象，以及它们生成的按时间排序的事件。通常，序列图显示特定用例实例产生的事件。
& 序列图中的纵向维代表时间，按时间先后依次向下排序。横向维代表不同的角色或对象。
& 下面就根据假设(1)来画一个用例“物品出仓”的序列图
&&&&1．在图1中选择“Usecase Realization”，单击右键选择“序列图”；
&&& 2.将“对象生命线”拖入右边空白区，双击“对象生命线”，输入名称“aManger”，将“分类器”设为“仓库管理员”，单击确定。这样一个对象就建立好了。类静态结构图中其它的Class依样照搬：
&&&&3.将“激活”拖到“GoodsOutput对象生命线”上，对于其余的对象处理方式类似；
&&&&4.添加“消息(调用)”到两个“激活”之间。例如对于GoodsOutput生命线和StoreHouse生命线，当添加了“消息(调用)”以后，表示类GoodsOutput会创建类StoreHouse的一个实例，对于物品出仓用例，我们首先需要确定出仓的货物，所以在此我们调用相应的方法，我们首先从左边的工具栏拖动“消息”，并连接相应的激活，结果如下图所示。
&&& &5.双击“消息1”，如果GoodsOutput类没有这个方法会自动弹出一个添加方法的对话框，由于我们已经添加了这个方法，所以此处我们可以直接选择相应的操作，若果存在参数，我们可以通过实参来调整参数名称，如图：
&&&&6.根据假设(1)，出仓的时候需要检查物品的库存(小于5就不能出仓)，因此StoreHouse需要一个GetProductStorage方法来得到物品的库存；
&&& 7.库存返回后，根据库存执行不同的调用，如果库存不小于5，创建新的GoodOutputItem实例；
&&& 8.如果返回的库存小于5，使用来添加返回“Nothing Added”。最后得到的序列图如下：
注意：如要了解创建序列图及UML其他图的更多知识，请参看 Visio 联机帮助。
、VISIO与MS .NET
生成.NET代码
& 从UML图生成相应的代码我们称为正向工程,在Visio中可以很方便生成.Net的代码。
&&& 1.单击“UML”选项—&“代码”—&“生成”，此时会弹出一个对话框.在里面选择要生成代码的包；
&&& 2.选择“目标语言”和“位置”，单击确定。
从.NET生成VISIO中的UML图
& 由代码生成UML图我们称为反向工程，在.Net里可以很方便的生成UML图。
打开.Net项目，选择“项目”—&“UML”—&“反向工程：
输入要生成的VISIO文件命.单击保存。
(1) Microsoft Visio 帮助文档
2、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 中类被画为一个矩型，通常包括它的名字、属性和方法。　
Origin Size
Open()Close()Move()Display()
第二种是接口（interface），接口是指类或组件提供特定服务的一组操作的集合。因此，一个接口描述了类或组件的对外的可见的动作。一个接口可以实现类或组件的全部动作，也可以只实现一部分。接口在UML 中被画成一个圆和它的名字。
图1-2 接口
第三种是协作（collaboration），协作定义了交互的操作，是一些角色和其它元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。因此，协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成部分。这些协作代表构成系统的模式的实现。协作在UML 中用一个虚线画的椭圆和它的名字来表示。
图1-3 协作
第四种是use case，use case是描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的值。在模型中use case通常用来组织动作事物。Use case是通过协作来实现的。在UML 中，use case画为一个实线椭圆，通常还有它的名字。& & 图1-4 use case & 第五种是活动类（active class），活动类是这种类，它的对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的。在UML 中活动类的画法和类相同，只是边框用粗线条。& &
EventManager
Suspend()Flush()
图1-5 活动类& 第六种是组件（component），组件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，你可能会遇到不同种类的组件，例如COM+ 或JAVA BEANS。组件在UML中用如下的图表示：图1-6 组件 第七种是结点（node），结点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个结点，但有可能从一个结点转到另一个结点。结点通常用如下的图形表示：& & 图1-7结点& 类、接口、协作、use case、活动类、组件和结点这七个元素是在UML 模型中使用的最基本的结构化事物。系统中还有这七种基本元素的变化体，如角色、信号（某种类），进程和线程（某种活动类），应用程序、文档、文件、库、表（组件的一种）。&
1.1.2 动作事物
动态事物是UML 模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。总共有两种主要的动作事物。第一种是ineraction，interaction是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作。 interaction中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作），连接（对象之间的连接）。在UML 中消息画成带箭头的直线，通常加上操作的名字。& 图1-8 消息&&&&&& 第二种是状态机（state machine），状态机由一系列对象的状态组成。在UML 中状态表示为下图：& 图案1-9 状态& interaction和状态机是UML 模型中最基本的两个动态事物元素，它们通常和其他的结构元素、主要的类、对象连接在一起。&
1.1.3 分组事物
分组事物是UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中被分解。总共只有一种分组事物，称为包（package）。包是一种将有组织的元素分组的机制。结构事物、动作事物甚至其他的分组事物都有可能放在一个包中。与组件（存在于运行时）不同的是包纯粹是一种概念上的东西，只存在于开发阶段。在UML 中用如下图表示包：& & & 图 1-10 包&
1.1.4 注释事物
注释事物是UML模型的解释部分。UML中用如下图表示：& 图　1-11 注释&
1.1.5 UML中的关系
UML中有四种关系：1.&&&& 依赖（Dependencies）& （图1-12 依赖）&2.&&& 关联（Association） （图　1-13 关联）　 & 3.&&&&&&&& 一般化（generalization） （图1-14 一般化） & 4.&&&&&& 实现(realuzation)& （图　1-15 实现）&
1.1.6 UML中的图
1、类图（class diagram）2、对象图（class diagram）3、Use case diagram4、Sequence diagram5、Collaboration diagram6、Statechart diagram7、Activity diagram8、Compomnent diagram9、Deployment diagram关于这些图的详细介绍将在今后的章节中讲解。
联系本文作者：如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。
第二章 Hello World
记得在学习C语言的时候，教科书上的第一个程序就是叫Hello world，一个在屏幕上简单地打印出“Hello world!”语句的例子。在系统的学习UML语言之前我们来看一个简单的例子，让大家有一个系统的认识。在java中一个在浏览器中显示“Hello World!”的Applet代码如下：import java.awt.Gclass HelloWorld extends java.applet.Applet{public void paint( Graphics g ){g.drawString("Hello World!", 10,10 );}}代码的第一行：import java.awt.G使得程序可以使用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。&
图 2-1 HelloWorld图2-1表达了最基本的HelloWorld模型，但它还有很多东西没有表示出来。在我们的程序中Applet类和Graphics类的使用是不相同的。Applet用作HelloWorld类的父类，而Graphics类用在方法paint的实现中。在UML模型中可以将这些关系表示为图2-2:
图2-2 HelloWorld的类图在图2-2的类关系图中，我们用简单的矩行图标表示类Applet和Graphics类，没有将它们的属性和方法显露出来是为了简化。图中的空心箭头表示HelloWorld类是Applet类的子类，代表一般化。HelloWorld和Graphics之间的虚线箭头表示依赖关系，表示HelloWorld类使用了Graphics类。到这里或许你认为已结束了，其实不然，如果认真研究java库中的Applet类和Graphics类会发现他们都是一个庞大的继承关系中的一部分。追踪Applet的实现可以得到另外一个类图，如图2-3所示：
图2-3 HelloWorld继承图
联系本文作者： 如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。
类是具有相同属性、操作、关系的对象集合的总称。通常在UML中类被画成矩形。
每个类都必须有一个名字，用来区分其它的类。类名是一个字符串，称为简单名字。路径名字是在类名前加包含类的包名为前缀。例如Wall、java::awt::Wall都是合法的类名。
属性是指类的命名的特性，常常代表一类取值。类可以有任意多个属性，也可以没有属性。在类图中属性只要写上名字就可以了。如下图
也可以在属性名后跟上类型甚至缺省取值，如下图：
操作是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。操作在类图中如下图描述：
组织属性和方法
在画类图的时候没有必要将全部的属性和操作都画出来。实际上，在大部分情况下你也不可能在一个图中将类的属性和操作都画出来。在画类图时可以只将感兴趣的属性和操作画出来就可以了。可以用”...”表示还有属性或方法没有画出来。为了更好地组织属性或方法，可以在一组功能相同的属性或方法前加上一个描述的前缀（&&&&中的文字），如下图：
职责指的是类所担任的任务，类的设计要完成什么样的功能，要存担的义务。一个类可以有多种职责，设计得好的类一般至少有一种职责，在定义类的时候，将类的职责分解成为类的属性和方法。
通常在UML中在类图的最下方用单独的部分列出类的职责。
类的职责其实只是一段或多段文本描述。
通用建模技术
1.&&&&&&&& 为系统的词汇建立模型
l&&&&&&&&& 标识出用户或解决问题时用来描述问题的东西，使用CRC卡片和基于USE－CASE的分析来找出这些抽象。
l&&&&&&&&& 对每一个抽象，标识出它的职责集合。确定明确地定义了每一个类，在为所有类确定的职责中取得了很好的平衡。
l&&&&&&&&& 为类提供实现类的职责所需要的属性和方法。
2.&&&&&&&& 为系统的职责分配建立模型
l&&&&&&&&& 标识出行为相类似的对类
l&&&&&&&&& 找出这些类的职责
l&&&&&&&&& 把这些类作为整体看待，把职责多的类分为几个小类
l&&&&&&&&& 考虑这些类如何协作，重新进行类的职责分配已满足协作中没有类太多职责或太少职责
3.&&&&&&&& 为非软件的事务建立模型
l&&&&&&&&& 为抽象成类的事务建立模型
l&&&&&&&&& 如果你建模的是硬件本身包含有软件，建模时考虑为一种NODE，这样可以对它进一步的分解。
4.&&&&&&&& 为原始类型建模
l&&&&&&&&& 为类型或枚举建立模型
l&&&&&&&&& 如果要对这种类型取值范围进行说明，使用约束。
联系本文作者： 如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。
第四章 关系
依赖关系（Dependency）
依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用依赖关系。
通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。在UML中你可以在其它的事物之间使用依赖关系，特别是包和节点之间。
图 4-1 依赖关系
一般化（Generalization）
一般化是继承关系，是叫做“is-a-kind-of”的关系。在UML中你可以在包之间建立一般化关系。
图 4-2 一般化
关联（Association）
关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象。关联有两元关系和多元关系。两元关系是指一种一对一的关系，多元关系是一对多或多对一的关系。一般用实线连接有关联的同一个类或不同的两个类。当你想要表示结构化关系时使用关联。
有一些修饰可以应用于关联。
1.&&&&&&&& 名字：可以给关系取名字
2.&&&&&&&& 角色：关系的两端代表不同的两种角色
3.&&&&&&&& 重数：表示有多少对象通过一个关系的实例相连接
联系本文作者： 如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。
第五章 通用机制
UML中的四种机制使地它简单和更易于使用，你可以在UML语言的任何时候用同样的方法来使用，这四种机制是：
l&&&&&&&& specifications
l&&&&&&&& adornments
l&&&&&&&& common divisions
l&&&&&&&& 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元素添加新规则或修改存在的规则。限制通常画成{}内的字符串，放在关系附近。当然，你也可以把限制用注释来表示。
通用建模技术
1.&&&&&&&& 建模注解
使用注释的目的是为了让模型更清晰，下面是使用注释的一些技巧：
l&&&&&&&& 将注释放在你要注解的元素边上，写下注解的文字。用依赖关系的线将注释和被注释的元素连起来会让人更明白。
l&&&&&&&& 记住，你可以隐藏元素或使隐藏的元素可见。这就意味着你可以将注释不隐藏起来，而她注释的元素是可见的，这样会使你的模型图简洁，在必要的地方让注释可见。
l&&&&&&&& 如果你的注释很长或不仅仅是普通文本，你可以将你的注解放到一个独立的外部文件中（如WORD文档）然后链接或嵌入到你的模型中。
下面是一个使用注解的例子：
建立新的建筑块
UML的建筑块如：类、接口、合作、组件、注释、关系等等，都在为具体问题建模的时候基本上是够用了。然而，如果你想扩展你的模型的词汇，如用来表示你的特定的问题领域，你需要stereotypes。
建立新的建筑块有如下的技巧：
l&&&&&&&& 确定没有现成的基本的UML方法可以表达你的需要。如果你碰到一个普通的建模问题，很有可能已经有某种标准的stereotype是你想要的。
l&&&&&&&& 如果你确信没有现成的东西可以表达这些语义，首先找到一个UML中的最接近你要建立的模型的元素（例如：类、接口、组件、注释、关系等等）然后为她定义一个stereotype。值得一提的是你可以定义stereotypes的层次从而得到一般的stereotypes和为它定义的特别的特性。这种方法尽量少用。
l&&&&&&&& 通过对普通的stereotype定义一组标记值和对stereotype进行限制可以实现普通stereotype不能实现的功能。
l&&&&&&&& 如果你希望这些stereotype具有不同的视觉效果，为他们定义一个特别的图标。
上面是一个例子。假如你用活动图来为一个涉及到教练工作流和队员工作流的体育活动建模。在这里，区别教练和运动员以及与其他的本领域的对象是有意义的。上面的图中有两个事物是很突出的，教练对象和队员对象。这里不仅仅是普通的类，更确切地说，他们现在是两个新的建筑块。因为定义了教练和队员stereotype，并且运用到了UML的类上。在这个图上，被标记为:Coach和:Team的匿名实例，后者显示了不同的状态。
建模新属性
UML建筑块的基本属性如：类的属性和操作，包的内容等等，都足够描述清楚你要建立的模型。然而，如果你想扩展这些基本建筑块（或者用stereotype建立的新的建筑块）的属性，你就需要使用标记值。
下面是一些技巧：
l&&&&&&&& 首先要确定的是你的需要无法用基本的UML表达。如果你碰到一个普通的建模问题，很有可能已经有某种标准的标记值是你想要的
l&&&&&&&& 如果你确定没有其他的方法可以表达你需要的语义，添加新的属性到一个单独的元素或一个stereotype。继承的规则是适用的，也就是说对父亲定义的标记值对儿子也具有。
建立新的语义
当你用UML建立模型的时候，你总是使用UML定义的规则，这实在是件好事，因为别的懂得如何读UML的人可以毫无偏差地读懂你想要表达的东西。然而，如果你发现你需要表达的语义是UML无法表达的或你想要修改UML的规则，这时你就需要使用限制了。下面是使用限制的一些技巧：
l&&&&&&&& 首先要确定的是你的需要无法用基本的UML表达。如果你碰到一个普通的建模问题，很有可能已经有某种标准的限制是你想要的。
l&&&&&&&& 如果你确定没有其他的方法可以表达你需要的语义，用文本的形式在限制中写下你的新语义，并且将他放在他涉及的元素附近。你可以使用依赖关系来明确地表示限制和他涉及的元素之间的关联。
l&&&&&&&& 如果你需要详细说明你的语义，你可以用使用OCL把它写下来。
下面的图是一个公司人力资源系统的一小部分：
这副图显示了每个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和角色（特殊的类）和他们的关系。使用usecase图来描述系统静态的功能场景。Usecase图对于组织和模型化系统的动作是很重要的。
序列图 序列图是一种交互图（interaction diagram），强调的是时间和消息的次序。一个序列图显示了一系列的对象和在这些对象之间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用序列图来说明系统的动态情况。
协作图 协作图是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。
注意：序列图和协作图是同构的，它们相互之间可以转化而不损失信息。
状态图 状态图显示了一个状态机，由状态、转换、事件和活动组成。使用状态图说明系统动态情况。状态图对于建模接口的动作、类的动作或协作的动作是重要的。状态图强调的是事件驱动的对象的动作，这在对反应式系统的建模是相当重要的。
活动图：活动图显示了系统中从一个活动到另一个活动的流程。活动图显示了一些活动，他们很象传统的流程图有序列或分支。活动图对于给系统的功能建模是很重要的。活动图强调的是对象之间的流程控制。通用建模技巧
1.对系统的不同视进行建模
l决定采用哪个视才能最好地表达系统的结构，以及暴露出项目的技术风险。前面讨论的五种图是很好的开始点。
l对每一种视图决定要画那些图，通常一个视图会对应多个图
l作为你的过程计划的一部分，决定那些图是要作为项目文档保存。
l不要认为一次能够将图画好，最好准备一个装废纸的房间。
例如，如果你为一个简单的应用建模。你可能只需要其中一部分视图。
Usecase 视图
处理（Process）视图
如果你是一个反应式的系统或系统的重点在处理流程上，你可能想包括状态图和活动图来建立系统的动作模型。
同样的，如果你是一个Client/Server系统，你可能想用组件图和分布图来为你的系统的物理细节进行建模。
最后，如果你是要对一个复杂的、分布式的系统建模，你需要使用所有的UML的图来表达系统的结构和项目的技术风险，如下所示：
2.不同抽象层次建模
你不仅要从不同的视角观察系统，还要系统进行不同层次的抽象，因为参加项目开发的人可能对同一个系统的视图需要不同的抽象层次。对于程序员来说，他希望看到的是类的属性、方法，而对于一个系统分析员使用usecase场景来说只要看到存在这么个类就可以了，这里程序员要求的抽象层次较底层。可以通过隐藏或显示不同层次的细节来实现不同抽象层次的模型，或者创建不同层次抽象的图。
l考虑你的读者的需要，从一个给定的模型开始
l如果你的读者使用模型是构造一个实现，他需要的是较低层的抽象，也就是说他需要更多的细节。如果他利用概念模型只是为了和最终用户交流，他需要的是高层次的抽象，不需要细节的东西。
3.复杂视图建模
l首先确信没有更好的方法可以利用高层次的抽象表达要表达的信息，即便是删除一部分图或保留细节到另外一部分。
l如果你隐藏了你所能隐藏的细节而你的图还是很复杂，考虑将一部分元素分组放到包里或放到较高层次的协作中，然后在你的图中只画这些包和协作。
l如果你的图还是很复杂，使用注释或颜色来钩出你的重点好引起读者的注意
l如果你的图依然很复杂，哈哈，打印出来，贴到墙上，将读者叫来亲自讲解给他听吧。希望他能明白……其实你可以自己慢慢研究，最后发现简化还是可以的。
第七章 类图
类图是在面向对象的系统模型中使用得最普遍的图。类图包含了一组类、接口和协作以及他们之间的关系。
你使用类图来为系统的静态视图建模。通常这包括模型化系统的词汇（从系统的词汇表中发现类），模型化协作，或则模型化模式。类图还是一些相关的图的基础，包括组件图、分布图。
类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型，同样重要的是构建通过正向和反向工程建立执行系统。
术语和概念
类图：类图是一组类、接口和协作以及他们之间的关系构成的。
类图通常包含如下的内容：
l&&&&&&&& 类
l&&&&&&&& 接口
l&&&&&&&& 协作
l&&&&&&&& 依赖关系、继承关系、关联关系
同其他的图一样，类图也可以包含注解和限制。
类图中也可以包含包和子系统，这两者用来将元素分组。有时后你也可以将类的实例放到类图中。
&注：组件图和分布图和类图类似，虽然他们不包含类而是分别包含组件和节点。
你通常通过下面三种方式使用类图：
1，为系统词汇建模型
为系统的词汇建模实际上是从词汇表中发现类，发现它的责任。
2，模型化简单的协作
协作是指一些类、接口和其他的元素一起工作提供一些合作的行为，这些行为不是简单地将元素加能得到的。例如：当你为一个分布式的系统中的事务处理过程建模型时，你不可能只通过一个类来明白事务是怎样进行的，事实上这个过程的执行涉及到一系列的类的协同工作。使用类图来可视化这些类和他们的关系。
3，模型化一个逻辑数据库模式
想象模式是概念上设计数据库的蓝图。在很多领域，你将想保存持久性数据到关系数据库活面向对象的数据库。你可以用类图为这些数据库模式建立模型。
通用建模技术
没有类是单独存在的，他们通常和别的类协作，创造比单独工作更大的语义。因此，除了捕获系统的词汇以外，还要将注意力集中到这些类是如何在一起工作的。使用类图来表达这种协作。
l&&&&&&&& 确定你建模的机制。机制代表了部分你建模的系统的一些功能和行为，这些功能和行为是一组类、接口和其他事物相互作用的结果。
l&&&&&&&& 对于每个机制，确定类、接口和其他的参与这个协作的协作。同时确定这些事物之间的关系。
l&&&&&&&& 用场景来预排这些事物，沿着这条路你将发现模型中忽略的部分和定义错误的部分。
l&&&&&&&& 确定用这些事物的内容来填充它们。对于类，开始于获得一个责任（类的职责），然后，将它转化为具体的属性和方法。
图 7-1 模型化简单的协作
图7-1是一个自治机器人的类图。这张的图焦点聚集那些让机器人在路上行走的机制对应的类上。你可以发现一个虚类Motor和两个从它派生出来的类：SteeringMotor和MainMotor。这两个类都从它的父亲Motor继承了五个方法。这两个类又是另一个类Driver的一部分。类PathAgent和Driver有一个1对1的关系，和CollisionSensor有1对n的关系。
在这个系统中其实还有很多其他的类，但这张图的重点是放在那些将机器人移动的类上的。在其他的图中你可能也会看到这些类。通过将焦点放在不通的功能上，可以获得从不通的角度对整个系统的认识，最终达到认识整个系统。
很多系统都是有持久性数据的，也就是说要将这些数据保存到数据库中以便下一次使用。通常你会使用关系型数据库或面向对象的数据库，或其它类型的数据库来保存数据。UML很适合为逻辑数据库模式建模。
UML的类图是E-R图（为逻辑数据库建模的通用工具）的超集，尽管E-R图的重点是数据，类图的扩展允许模型化行为。在物理数据库中这些逻辑操作一半转化为触发器或存储过程。
l&&&&&&&& 确定那些状态比其生命周期要长的类。
l&&&&&&&& 创建一张包含这些类的图，标记它们为持久性的。
l&&&&&&&& 详细定义它们的属性。
l&&&&&&&& 对于使得物理数据库设计复杂的模式如：循环关系、1对1关系、N元关系，考虑创建中间抽象来使得逻辑结构复杂。
l&&&&&&&& 详细定义这些类的操作，特别是那些访问数据和涉及数据完整性的方法。
l&&&&&&&& 如果可能的话使用工具来将你的逻辑设计转化为物理设计。
图7-2 模式建模
建模是重要的，但要记住的是对于开发组来说软件才是主要的产品，而不是图。当然，画图的主要目的是为了更好地理解系统，预测什么时候可以提供什么样的软件来满足用户的需要。基于这个理由，让你画的图对开发有指导意义是很重要的。
某些时候，使用UML。你的模型并不能直接映射成为代码。例如，如果你在使用活动图为一个商业过程建模，很多活动实际上涉及人而不是计算机。
很多时候，你创建的图形可以被映射成为代码。UML并不是专门为面向对象的语言设计的，它支持多种语言，但使用面向对象的语言会更直观些，特别是类图的映射，它的内容可以直接映射成为面向对象语言的内容。如：C＋＋，SMALLTALK、ADA、ObjectPascal、Eiffel和Forte。UML还支持如Visual Basic这样的面向对象的语言。
正向工程：是从图到代码的过程。通过对某中特定语言的映射可以从UML的图得到该语言的代码。正向工程会丢失信息，这是因为UML比任何一种程序语言的语义都丰富。这也正是为什么你需要UML模型的原因。结构特性、协作、交互等可以通过UML直观地表达出来，使用代码就不是那么明显了。
对类图的正向工程：
l&&&&&&&& 选择将图形映射到哪一种程序语言。
l&&&&&&&& 根据你选择的语言的语义，你可能要对使用某写UML的特性加以限制。例如：UML允许你使用多重继承，而SmallTalk只允许一重继承。
l&&&&&&&& 使用标记值来指定比的目的语言。你可以在类级进行也可以在协作或包的层次上进行。
l&&&&&&&& 使用工具来对你的模型进行正向工程。
反向工程：反向工程是从代码到模型的过程。
进行反向工程：
l&&&&&&&& 确定将你的程序语言的代码反向成模型的规则。
l&&&&&&&& 使用工具（Rose C++ Analyzer）进行反向工程。
提示和技巧
一个结构化好的类图：
l&&&&&&&& 焦点放在系统静态设计视图的一个方面
l&&&&&&&& 只包含为了理解该方面而应该存在的元素
l&&&&&&&& 提供足够的信息来理解该图
l&&&&&&&& 不让读者产生错误的信息
当你画类图的时候：
l&&&&&&&& 给它起一个名字，这个名字能表达类图的用途
用最少的交叉线来组织它的元素。
联系本文作者： 如果本文某些术语翻译得不正确，敬请大家指教。关于ＵＭＬ的东西我也是最近才接触，本文如有错误还请原谅。
3、四步轻松实现用Visio画UML类图
转载本文请联系原作者获取授权，同时请注明本文来自科学网博客，链接地址：
上一篇：下一篇：
当前推荐数：0
评论 ( 个评论)
作者的精选博文
作者的其他最新博文
热门博文导读
Powered by
Copyright &}