uml建模的要点总结

uml建模的要点总结（精选8篇）

uml建模的要点总结 篇1

UML建模的要点总结

预备知识：

一、UML的特性与发展现状

UML是一种Language(语言)

UML是一种Modeling(建模)Language UML是Unified(统一)Modeling Language

1、已进入全面应用阶段的事实标准

2、应用领域正在逐渐扩展，包括嵌入式系统建模、业务建模、流程建模等多个领域

3、成为“产生式编程”的重要支持技术：MDA、可执行UML等

二、建模的目的与原则

1、帮助我们按照实际情况或按我们需要的样式对系统进行可视化;提供一种详细说明系统的结构或行为的方法;给出一个指导系统构造的模板;对我们所做出的决策进行文档化。

2、仅当需要模型时，才构建它。

3、选择要创建什么模型对如何动手解决问题和如何形成解决方案有着意义深远的影响;每一种模型可以在不同的精度级别上表示;最好的模型是与现实相联系的;单个模型是不充分的。对每个重要的系统最好用一组几乎独立的模型去处理。

三、谁应该建模

1、业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与

2、需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与

3、设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导。

4、实现模型：以资深开发人员(设计人员)为主，架构师提供总体指导。

5、数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员(设计人员)予以配合。

正式开始

UML组成，三部分(构造块、规则、公共机制)，关系如下图所示：

一、构造块

1、构造块是对模型中最具有代表性的成分的抽象

建模元素：UML中的名词，它是模型基本物理元素。

行为元素：UML中的动词，它是模型中的动态部分，是一种跨越时间、空间的行为。

分组元素：UML中的容器，用来组织模型，使模型更加的结构化。

注释元素：UML中的解释部分，和代码中的注释语句一样，是用来描述模型的。

1.1、建模元素

类(class)和对象(object)

接口(interface)

主动类(active class)

用例(use case)

协作(collaboration)

构件(component)

节点(node)

类(class)和对象(object)

类是对一组具有相同属性、相同操作、相同关系和相同语义的对象的抽象

UML中类是用一个矩形表示的，它包含三个区域，最上面是类名、中间是类的属性、最下面是类的方法

对象则是类的一个实例(object is a Instance of Class)

接口(interface)

接口是描述某个类或构件的一个服务操作集

主动类(active class)

主动类实际上是一种特殊的类。引用它的原因，实际上是在开发中需要有一些类能够起到 启动控制活动的作用

主动类是指其对象至少拥有一个进 程或线程，能够启动控制活动的类

用例(use case)

用例是著名的大师Ivar Jacobson首先提出的，现已经成为了面向对象软件开发中一个需求分析的最常用工具

用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个 用例定义一组用例实例。

协作(collaboration)

协作定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构 成的一个群体。

对于某个用例的实现就可 以表示为一个协作

构件(component)

在实际的软件系统中，有许多要比“类”更大的实体，例如一个COM组件、一个DLL文件、一个JavaBeans、一个执行文件等等。为了更好地对在UML模型中对它们进行表示，就引入了构件(也译为组件)

构件是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组外部接口。在系统中满足相同接口的组件可以自由地替换

节点(node)

为了能够有效地对部署的结构进行建模，UML引入了节点这一概念，它可以用来描述实际的PC机、打印机、服务器等软件运行的基础硬件

节点是运行时存在的物理元素，它表示了一种可计算的资源，通常至少有存储空间和处理能力

1.2、行为元素

交互(interaction)： 是在特定语境中，共同完成某个任务的一组对象之间交换的信息集合

交互的表示法很简单，就是一条有向直线，并在上面标有操作名

状态机(state machine)：是一个对象或交互在生命周期内响应事件所经历的状态序列

在UML模型中将状态画为一个圆 角矩形，并在矩形内写出状态名称及其子状态

1.3、分组元素

对于一个中大型的软件系统而言，通常会包含大量的类，因此也就会存在大量的结构事物、行为事物，为了能够更加有效地对其进行整合，生成或简或繁、或宏观或微观的模型，就需要对其进行分组。在UML中，提供了“包(Package)”来完成这一目标

1.4、注释元素

结构事物是模型的主要构造块，行为事物则是补充了模型中的动态部分，分组事物而是用来更好地组织模型，似乎已经很完整了。而注释事物则是用来锦上添花的，它是用来在UML模型上添加适当的解释部分

2、关系

UML模型的关系比较多,下图

2.1 关联关系

关联(Association)表示两个类之间存在某种语义上的联系。关联关系提供了通信的路径，它是所有关系中最通用、语义最弱的。

在UML中，使用一条实线来表示关联关系

在关联关系中，有两种比较特殊的关系：聚合和组合

聚合关系：聚合(Aggregation)是一种特殊形式的关联。聚合表示类之间的关系是整体与部分的关系

如果发现“部分”类的存在，是完全依赖于“整体”类的，那么就应该使用“组合”关系来描述

组合是聚合的变种，加入了一些重要的语义。也就是说，在一个组合关系中一个对象一次就只是一个组合的一部分，“整体”负责“部分”的创建和破坏，当“整体”被破坏时，“部分”也随之消失

聚合就像汽车和车胎，汽车坏了胎还可以用。组合就像公司和下属部门，公司倒闭了部门也就不存在了!

2.2 泛化、实现与依赖

泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。

实现关系是用来规定接口和实现接口的类或组件之间的关系。接口是操作的集合，这些操作用于规定类或组件的服务。

有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖(Dependency)于元素X。

二、规则

命名：也就是为事物、关系和图起名字。和任何语言一样，名字都是一个标识符

范围：与类的作用域相似.可见性：Public，Protected，Private，Package

三、UML公共机制

1、规格描述

在图形表示法的每个部分后面都有一个规格描述(也称为详述)，它用来对构造块的语法和语义进行文字叙述。这种构思，也就使可视化视图和文字视图的分离 ：

2、UML修饰与通用划分

在为了更好的表示这些细节，UML中还提供了一些修饰符号，例如不同可视性的符号、用斜体字表示抽象类

UML通用划分：

1)类与对象的划分：类是一种抽象，对象是一个具体的实例

2)接口与实现的分离：接口是一种声明、是一个契约，也是服务的入口;实现则是负责实施接口提供的契约

3、UML扩展机制

这部分不容易描述，待改

构造型：在实际的建模过程中，可能会需要定义一些特定于某个领域或某个系统的构造块

标记值则是用来为事物添加新特性的。标记值的表示方法是用形如“{标记信息}”的字符串

约束是用来增加新的语义或改变已存在规则的一种机制(自由文本和OCL两种表示法)。约束的表示法和标记值法类似，都是使用花括号括起来的串来表示，不过它是不能够放在元素中的，而是放在相关的元素附近。

4、UML视图和图

图名

功能

备注

类图

描述类、类的特性以及类之间的关系

对象图

描述一个时间点上系统中各个对象的一个快照

复合结构图

描述类的运行时刻的分解

构件图

描述构件的结构与连接

部署图

描述在各个节点上的部署

包图

描述编译时的层次结构

用例图

描述用户与系统如何交互

活动图

描述过程行为与并行行为

状态机图

描述事件如何改变对象生命周期

顺序图

描述对象之间的交互，重点在强调顺序

通信图

描述对象之间的交互，重点在于连接

定时图

描述对象之间的交互，重点在于定时

交互概观图

是一种顺序图与活动图的混合附：开发过程与图的对应关系

本文来自CSDN

博

客，转

载

请

标http://blog.csdn.net/Mac_cm/archive/2009/07/27/4384704.aspx

UML 1原有 UML 1非正式图

UML 2.0新增

UML 1原有

UML 1原有

UML中非正式图 UML 1原有 UML 1原有 UML 1原有 UML 1原有 UML 1中的协作图 UML 2.0 新增 UML 2.0新增 明

出

处

：

uml建模的要点总结 篇2

统一建模语言(Unified Modeling Language,UML)是一种可以应用于任何软件开发过程的标记法和语义语言。它不是一种系统设计方法,而是一种系统建模方法。为了使用UML,需要有一种方法应用于它。目前这样的方法已有了若干种,但是最流行的,或许也是第一个用于处理UML的方法是Rational Unified Process,也称为Unified Process(统一过程)。

2 用例图建模及实例

用例图是使用统一建模语言设计新系统的起始点,是有关系统细节的最高形式。用例图说明的是谁要使用系统以及他们使用该系统可以做些什么。

2.1 基本组件

用例图包含4个基本组件:系统、参与者、用例、关系。在用例图建模时还会用到泛化技术,泛化是一种用于表示UML中项目的继承的技术。泛化可以应用于参与者和用例来表示其子项从父项继承功能,而且泛化还表示父亲的每个孩子都有着略微不同的功能或目的以确保自己的惟一性。

2.2 建模实例

教师记录成绩时,会得到下列需要进行的活动:

(1)教师确定出要记录成绩的学生。

(2)系统要确保学生在数据库中。

(3)教师说明要记录哪项作业的成绩。

(4)系统开始执行数据库事务处理。(5)系统将布置给学生的作业添加到数据库中。(6)教师输入学生作业的成绩。

(7)系统确认输入成绩以确保成绩处于有效范围之内。(8)系统记录作业成绩。

(9)系统结束事务处理。

(10)系统提示教师成绩已经被记录。

创建用例图的第一项任务是找出要建立的系统模型中的参与者和用例。通过与客户的访谈和提问得出以下的系统需求列表:

(1)系统可以供教师使用来为学生记录并更新成绩。

(2)系统根据需要由管理人员创建报告卡,管理人员要检查报告卡的准确性。

(3)教师需要通过计算机分发报告卡。

(4)系统需要允许教师和学生浏览记录的成绩。

从系统需求表可以确定出参与者为教师、学生和管理员。并且提出了下列用例,记录成绩、更新成绩、生成报告卡、检查报告卡的准确性、分发报告卡、浏览成绩。

接着,需要确定出用例的优先次序,利用需求列表,可以轻松提出以下优先次序:

(1)记录成绩。(2)浏览成绩。(3)更新成绩。(4)生成报告卡。

(5)检查报告卡的准确性。(6)分发报告卡。

然后,可以细化每个用例。下面就是为已创建的Record Grades用例的细节描述列表:

(1)系统要确保学生在数据库中。

(2)教师说明要记录哪项作业的成绩。

(3)系统开始数据库的一项事务处理。

(4)系统为学生把作业加入数据库。

(5)教师输入学生作业的成绩。

(6)系统核对输入的成绩以确保其属于正确的范围。

(7)系统记录作业的成绩。

(8)系统结束事务处理。

(9)系统提示教师成绩已经记录。

对于View Grades用例,发现需要一个使某些人登录的方法,并且这个用例会成为一个被其他每个用例包含的共有用例,因此添加Logon用例。对于Update Grades用例,因为Load Grades和Save Grades与Record Grades和View Grades一同共享,所以他们两个都会被添加到列表中。而当处理Check Report Cards for Accuracy用例时,意识到这是一个手工处理过程,而不是一项可以编程的工作,于是将它从用例列表中删除。

3 活动图建模及实例

活动图在用例图之后提供了下一步系统分析中对系统充分的描述。活动图允许读者了解系统的执行,以及如何根据不同的条件和刺激改变执行方向。因此,活动图可以用来为用例建模工作流。

活动图对用例尤其有用,因为它可以为读者提供明显的开始和结束状态,可以向读者说明需要满足什么条件用例才会有效,以及用例完成之后系统保留的条件或者状态。

3.1 标记符

活动图有3种主要的活动图标记符组件:活动、状态和转移。活动也称为动作状态,它是活动图中指示要完成某项工作的指示符。在前面的示例中,Choose Career是第一个显示的活动。状态指示内部的值,它可以指示每个域是否为真,也可以指示成功或者失败。转移用来显示从一种状态到另一种状态的控制流,它显示出活动图的迁移路径。

除以上的3种主要标记符外,还有控制点和决策点可以建模修改活动图流程的条件。控制点(guard)用来允许控制流仅沿着满足预置条件的方向,而决策点需要对控制流继续的方向做出决策。另外还有事件和触发器,事件非常类似于操作和方法,它是动作发生的指示符,用来包含在转移中来强制控制流采取某个方向,事件中可以包含一个或者多个参数。游泳道(swim lane)用来根据活动绘制对象的域来隔离它们,在很大程度上增强了活动图的可读性。分岔和联结也是活动图中使用的标记域,分岔用来开始并行处理,它的每一个分支基本上都是独立的活动图,与其他分支没有任何关系,联结用来把并行处理流转换为单向处理流。分岔具有一个转移入口,两个或者多个转移出口,描述了单向处理控制流分成了多个控制流。联结描述了不同的处理控制流合并到一起形成一个单向处理。特别的是,如果一个处理在其他处理之前到达了联结,它将会等待,直到所有的处理都准备好之后才会向联结传递控制权。

3.2 创建活动图实例

首先对教师更新分数这个工作流进行扩展。最容易的扩展方式就是登录,选择学生,加载他们的分数,修改分数,保存修改结果。因此得到的活动图如图1。

接着建模从路径,向活动图以单个活动Display Error的形式添加出错处理功能。它只在错误发生时发生,并且一旦发生将会使得工作流停止,同时,添加一些并行处理。加载了每个学生的班级和分数,并且使得加载工作同时发生。因此,在Choose Student后添加一个分叉,同时进行Load Class和Load Grades。这时候,若loading有错误,工作流便转向错误处理;假若没有,接着将是显示Student Information,然后修改信息,保存。由于游泳道可提高活动图的可读性,因此把以上的活动图分成了两个游泳道。第一个游泳道是Teacher,第二个是Website。Teacher是用例的参与者,而Website是提供后端功能的泛化组件。添加游泳道以后,给出图2。

4 结语

UML使系统开发者能够以一种支持可伸缩性、安全性和健壮性的方式描述、记录模型并使之可视化。因为UML提高了分析和设计阶段的抽象程度,所以它很容易识别行为的模式,从而大大增加了重用的可能性。UML建模推动了模块化设计,导致了组件和组件库的形成,从而加快了开发速度,并保证系统设计和实现之间的一致性。

参考文献

[1]Jason T.Roff著.UML基础教程.清华大学出版社,2003.

[2]Tom Pender著,UML Bible,耿国桐,史立奇,等译.电子工业出版社,2004.

[3]姚淑珍,唐发根译.UML参考手册.机械工业出版社,2001.

[4]Craig Larman著.UML和模式应用:面向对象分析与设计导论.机械工业出版社,2002.

[5]王少锋著.面向对象技术UML教程.清华大学出版社,2004.

[6]方贵宾,李侃,等译.UML和统一过程实用面向对象的分析和设计.机械工业出版社,2003.

对两款UML建模工具的功能评价 篇3

关键词：功能评价；CASE工具；model maker；rational rose

中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)12-21604-02

Evaluation of the Functions of the two UML Case Tools

WANG Lei, ZHOU Bing

(Anhui University of Technology Institution of Computer Science and Application,Maanshan 243002,China)

Abstract:The article puts forward a kind of method of evaluation of the functions which is on behalf of the users. This method includes seven parts of the evaluation of the functions and in this article, it evaluates the most popular two kinds of case tools (Rational Rose and Model Maker) by this method. Then, it gets the result of the advantages and disadvantages of each tool and their using conditions.

Key words:evaluation of the functions;case tools;model maker;rational rose

1 概述

随着UML的提出与发展，UML建模工具也越来越多，每一个软件开发者都希望找到适合自己的，拥有自己所需要的功能并且尽可能简单的建模工具。为此本文提出了一种基于用户的对UML建模工具的功能评价的方法，并且对两款CASE工具做了简单的评价与比较。开发者也可以通过对下面几个方面的评价与测试来选择一款合适的工具。

2 基于用户的功能评价

2.1 绘图支持

绘图支持功能的评价主要从三个方面入手，具体如下：

(1)工具应使绘图工作简单而有趣，不仅必须提供优秀的选择、放置、连接和定义图中元素的机制，而且要帮助建模者着色，形成一张正确的图。

RR的绘图区中提供了很好的选择功能，可以方便地选择某个，某些或全部元素，另外在绘图窗口中的右键菜单中还提供了“select in browser”在浏览器中选择的功能。MM同样提供了方便的选择功能，

(2)工具还应该有理解元素语义的能力。这种能力能够提示一个具体的操作与其他操作之间存在不一致问题。比如，在一个模型中，若修改某个图后，将会引起该图与其他图的冲突，这时系统就会自动警告，提示建模者的修改可能出现错误。

在测试不一致问题时，将从以下两个方面进行。

浏览窗口中显示的不一致：

RR中在左边的浏览器中的用例视图和组件视图中都可以创建类，如果在同一个视图中创建两个同名的类会发出警告，并且最终不允许类名相同。如果在不同的视图中创建两个相同的类，则也会出现警告，但最终将允许类名相同。

RR中浏览器中的用例视图和组件视图中都可以创建类图，无论在相同或者不同的视图中创建一个同名的类图，系统都不会发出警告，并且默认它们为不同的类图。在两个视图中还分別可以创建用例图和序列图，协作图，活动图等，创建同名图的时候都属于上述情况。

MM的界面设置相对合理，因此极少出现次类情况。

图与浏览器显示的不一致：

RR中在右边绘图窗口中的图与浏览器中所表示的图于元素是对应的，如绘图区的类图中加入一个新类，那么，左边的浏览器中，类图名子下就会多出这个类。但是，如果在绘图区中用DELETE键将该类删除时，浏览器下仍然保持显示这个类，并且没有任何警告。而反过来在浏览器中删除元素则会正常地对应到图中。

MM中在绘图区删除某一元素，也不会直接反映到浏览器中，这一点与RR很象。

(3)工具也应该提供图的版面设计功能。比如，允许建模者重新排列模型元素，而代表消息的线条由工具自动地重新排列，使它们彼此不会交叉。

RR中在绘图区点鼠标右键出先的菜单中有一项“fit in window”功能，这一功能的主要作用是调整整个图在窗口中的位置，采取缩小的方式尽量将图一次全部显示出来。

RR中没有自动调整图内各元素位置的功能。例如，当图中线条有交叉时，只能通过手动调整。

MM具有全屏显示图形的功能。

MM具有较强的自动排列功能。可以在绘图区的右键菜单中找到该功能，使用这一功能不仅可以让图中的各元素的位置变的更合理，还可以重新排列各元素位置，以消除线条的交叉现象。

MM中的类图还可以自动按继承关系排列。该功能同样在绘图区的右边键菜单中。使用该功能可以使类图中的类按照继承关系自上而下排列，最上层的将是祖先。

2.2 导航

把几个视图和图合起来共同描述一个系统的时候，能够方便地在视图和图之间导航是很重要的。CASE工具一定要支持导航功能，达到方便地浏览不同的图和搜索模型元素的目的。

(1)在CASE工具中表示的模型元素本身应该具有超链功能。右击元素应能弹出一个快捷菜单，上面显示普通的操作并给出可能的导航。

RR没有超链功能。

MM具有超链功能。用法为点击超链按钮，再点击图中想要加超链的图形元素，选择链接目标，便可以在添加超链元素的右键菜单中的“Navigation”子菜单下找到链接目标。比如说，给A类添加超链目标为B类，那么便可以在编辑A类的同时方便地找到B类，给设计者带来了很大的方便。

(2)另一种控制复杂图的方式是定义过滤器，用过滤器把图中一些开发者感兴趣的方面独立表示出来或高亮显示。有了过滤器，建模者就可以在某一时段只研究那些重要的高亮显示部分。

RR中没有过滤器功能。

MM具有过滤器功能。主界面中的左下角的窗体用来显示图中与某个元素直接相关的子元素。比如说，一个类的所有属性、方法、事件、域等信息都显示在这个窗体中，该窗体上方有过滤按钮，可以分别过滤属性、方法、事件、域等信息，按下相应的按钮则该信息被过滤，不会显示在该窗体中，直到再按下该按钮取消过滤。

MM中的绘图区域还可以选择是否显示类的关系，类的细节，单元的关系等等。这一点也属于过滤器功能。

综合上述可以看出，在导航方面RR的功能明显不足于MM。

2.3 输出图表

一个经常被忽略的关键特性是用某种格式输出图表，以便引入到文字处理文档或Web页面中。用于输出的最流行图像格式是GIF、PNG和JPEG。这一功能将大大方便开发文档的制作。

MM中绘制的图不仅可以直接打印（“print”功能），还可以通过“export as image”功能将绘制的图做为图片文件输出，它支持的格式有WMF、PNG、BMP、JPG。用哪种格式来保存可以随意选择。

RR也支持“print”功能，但是如果想将图作为图片文件输出的时候就必须通过工具栏中的拷贝按钮将图中元素拷贝，再粘贴到其他的文件中。比如说可以粘贴到Windows XP自带的画图软件中,或者干脆直接粘贴到WORD文档中。

2.4 双向工程

一款优秀的UML工具都支持由模型自动生成代码，而今天这一技术非常有限，一般只能对类产生代码。

逆向工程与代码生成几乎是对立的二个功能。CASE工具阅读和分析代码为的是用图显示代码的结构。通常只有静态（比如类图）能用代码构建，动态信息是不能从代码中提取的。

产生代码和逆向工程合在一起称为双向工程（ROUND-TRIP ENGINEERING）。

RR只能产生类代码，产生代码时将自动转入开发环境的创建工程步骤，并将其引入该工程，如果系統没有安装所需要的开发环境的话，那么将用一个WINDOWS文本文档来保存代码。

RR生成代码后如果对模型有所修改，那么它并不能够自动地反映带模型中去，必须通过手动来升级代码，通常会使用生成代码菜单中的“UPDATA CODE”功能。同时修改代码要想获得新的模型也需要手动完成。

MM采用了强大的实时同步引擎，使得开发者的设计可以直接映射成代码，在代码上的修改可以自动逆向反映到设计模型。也就是说修改模型或者代码时候，它会自动地映射到代码或模型中去，而无需要手动升级。这一点RR很难做到。

2.5多用户支持

CASE工具应能让多个用户在同一个模型上协同工作。也就是说，彼此之间没有干扰。一般地，如果一个用户正在某个图上工作，那么该用户应该锁定这个图，不让其他用户同时改变这个图。更进一步地说，CASE工具要具有识别对积累中共享元素的任何改变的能力，但是这种改变是否适当是否有效还要靠用户决定。

RR通过使用控制单元支持多用户的并行开发。控制单元可以是用例视图、逻辑视图、组件视图中的任何包。也可以是配置视图和模型道具单元。在控制一个单元时，这个单元中所有模型元素存放在独立于模型的文件中。这样独立文件可以利用支持SCC的版本控制工具进行控制。在使用控制单元的过程中，如果希望在任何时候都可以浏览但不能修改项目，可以对控制单元写保护。

RR中的Model Integrator(模型集成器)可以比较和合并多个Rose模型，这项功能在多个设计人员共同开发时也非常有用，每个人可以独立工作，最后再将所有的模型集成到一起。

在MM中，模型分界线是一对相关的问题，因为他们处理同样的问题：什么应该在一个模型中而什么不应该在一个模型中。 使用模型分界线功能可以完成多用户的共同开发。

2.6 集成

建模工具与系统开发时需要使用的其他工具形成一个整体，就是集成。其他工具主要包括开发环境（比如，编辑器、编译器和调试器）和企业工具（比如，配置管理和版本控制系统）等。

CASE工具一定要能与其他工具集成，这样才能给开发者带来最大的方便，也是使用UML工具进行系统设计的先决条件。

一款UML建模工具可以集成的工具有开发环境、配置和版本控制、文档工具、测试工具、GUI构造器、需求说明工具、工程管理和过程支持工具等七种。

(1)开发环境：

Rational rose：add-in manager：很多外部的产品都对rose发布了add-in支持，以对rose的功能做进一步的扩展，如java、oracle、delphi，有了这些add-in，rose就可以做更多的深层次的工作了。例如装了delphi link之后，rose就可以直接可以生成delphi的框架代码，也可以从delphi代码转化成rose模型，并进行两者的同步。

Model maker：为delphi的建模而开发，因此与delphi可以说是无缝隙连接。

(2)文档工具

Rational rose：提供了文档窗口，它包含与模型元素规范窗口中完全相同的信息，描述模型元素或者关系，描述角色、约束、目的以及模型元素基本行为等信息。文档窗口中输入的一切都将显示为生成的代码中的说明语句，以后不必输入系统代码的说明语句。

Model maker：图中的每一个单元，类，类的所有成员，事件类型和符号都可以用一个简短的描述（成为“One Liner”）和更长的文本（称为文档）来进行文档化。为编辑“One Liner”和文档，我们将使用文档视图。我们也可以使用浮动的文档窗口来进行编辑。

3 结论

从绘图支持、打印、导航、双向工程等九项功能指标当前最流行的两款Case工具进行测评。通过评测试，对结果进行比对，不难看出：

(1)MM的界面虽然较RR复杂，但是使用起来更加方便。

(2)在绘图支持这项功能的评测过程中，可以发现MM在不一致检查，自动排版等方面都强于RR。

(3)导航方面MM又具有了RR所不具备的超链接和过滤器功能，为开发者提供了更大的方便。

(4)MM采用了强大的实时同步引擎，使得开发者的设计可以直接映射成代码，在代码上的修改可以自动逆向反映到设计模型。而RR不能做到这一点。

综上所述，Model maker的优势在于它的绘图操作更加的方便，而Rational rose的优势主要在于它支持更多的开发环境。

参考文献：

[1]Martin Fowler.UML Distilled[M].Addison Wesley,2003.

[2]蔡敏,徐慧慧,黄炳强.UML基础与Rose建模教程[M].人民邮电出版社,2006年.

UML系统建模与分析大作业 篇4

题

目：

《图书馆管理系统》 专业班级：

学

号:

姓

名：

一、系统功能需求

1、基本功能

① 借阅者能够借阅书籍和还书。

② 图书管理员能够处理借阅者的借阅和还书请求。

③ 系统管理员可以对系统的数据进行维护，如增加、删除和更新书目，增加、删除和更新借阅者帐户，增加和删除书籍。

2、系统主要包括以下几个模块：

2.1、基本数据维护模块

① 添加借阅者帐户

② 修改更新借阅者帐户信息 ③ 添加书目

④ 修改和更新书目信息 ⑤ 添加书籍 ⑥ 删除书籍

2.2、基本业务模块

① 借书 ② 还书 ③ 书籍预留

④ 取消书籍预定

2.3、数据库模块

① 借阅信息管理 ② 书籍信息管理 ③ 帐户信息管理 ④ 书籍预留信息管理

2.4、信息查询模块

① 查询书籍信息 ② 查询借阅者信息

3、系统中的类

① 读者类Reader ② 图书馆人员类 LibraryStaff 图书馆管理员类LibraryManager 系统管理员类SystemManager 图书馆馆长类LibraryBoos ③ 图书馆数据库类LibraryDatabase 图书馆资源数据库ResourcesDatabase 图书馆读者数据库ReaderDatabase 图书馆工作人员数据库LibraryStaffbase ④ 图书馆资源类LibraryResources 实物书籍类BooksResources 电子书籍类ElectronicResources 书类Book

Magazine杂志类

4、系统的用例图

 借阅者请求服务的用例图

1借书还书resourcesDatabase下载（阅读）电子书长籍11读者身份验证1reader查询书籍资料阅读杂志readerDatabase11libraryDatabaselibraryStaffese

 图书馆工作人员用例图

图书馆管理员验证处理读者借书处理读书还书1systemManager添加书目resourcesDatabase1系统管理员验证删除书目1添加书籍1libraryDatabaselibraryStaff删除书籍readerDatabase删除读者用户libraryManager添加读者用户

二、软件系统体系结构建模 2.1、系统的时序图

 系统管理员添加书籍的时序图

 系统管理员添加借阅者帐户的时序图

 系统管理员删除书目的时序图

 图书管理员处理书籍借阅的时序图

 图书管理员处理书籍归还的时序图

 借阅者查询书籍信息的时序图

 借阅者预留书籍的时序图

ReaderReaderDatabase1:验证身份()ResourcesDatabase2:返回验证信息3:使用终端机器预留书籍()4:预留书籍信息5:返回书籍信息和馆藏地点

2.2、系统的协作图

 系统管理员添加书籍的协作图

SystemManager2:返回验证消息LibraryResources3:向数据添加新书()4:向书库添加新书()7:返回添加新书成功1:验证身份()5:返回添加成功信息LibraryStaffbaseResourcesDatabase  系统管理员删除书籍的协作图

SystemManager3:删除数据库书目()7:删除成功2:返回信息1:验证身份()LibraryResources5:返回删除消息4:删除馆藏的书()LibraryStaffbaseResourcesDatabase6:更新数据库

 图书管理员处理借书的协作图

对象13：发出借书请求4:输入ReaderID()5:返回读者信息11：将书给读者对象42:返回信息7:输入书籍ID()10:借阅成功1:验证身份()对象38:该书信息对象5对象29:标记该书借出

 图书管理员处理还书的协作图

 借阅者预留书籍的协作图2.3、系统的活动图

 借阅者的活动图

进入图书馆

Reader进入刷卡终端键盘输入ReaderId刷卡输入ReaderID验证成功享受Reader各项服务借书还书将书给图书馆管理人员将书还给图书馆管理员查询书籍资料登录查询终端机下载电子资料登录账户图书管理人员处理借书请图书馆管理人员处理还书请求输入查询资料信息进入电子资料数据库借书成功还书成功得到相关资料信息下载或阅览电子资愿该项服务结束结束离开图书馆  图书管理员的活动图

验证图书馆管理人员账户登录到管理员账户等待读者的还书请求等待读者的借书请书处理读者的还书请处理读者借书请求重新等待读者服务请求处理还书结束处理借书 借书将书给读者重新等待读者服务请求系统管理员的活动图

 系统管理员维护借阅者帐户的活动图

系统管理员 维护借阅者账户的活动图登录到系统管理员账户登录到维护读者账户模块添加读者账户删除读者账户修改更新读者账户输入新账户信息检查该账户信息修改更新读者数据库信息有欠款欠书开设新读者账户没有欠款欠书将账户给读者删除该账户信息督促该用户归还欠款书  系统管理员进行书目信息维护的活动图

系统管理员进行书目信息维护的活动图登录到系统管理员账户登录到书目信息维护模块添加书目删除书目修改更新书目向数据库中添加书目删除数据库中的书目修改更新数据库书目向书库添加新书目删除书库中书目 系统管理员维护书籍信息的活动图

系统管理员维护书籍活动图登录到系统管理员账登录到维护书籍模添加书籍删除书籍向书库添加书籍删除书库中书籍更新数据库书籍信

三、硬件系统体系结构建模

3.1、业务对象组件图 <><>Item.javaLoan.javaTitle.javaReservation.java3.2、用户界面的组件图

UpdateBorrowerFBorrowerFrame.jrame.javaavaCancelResevationFBorrowerWirame.javandow.javaFindBorroweReturnItemrDialog.javaFrame.javaLendItemFFindTitleDrame.javaialog.javaUpdateTitleTitleFramFrame.javae.java

3.3、系统的部署图

DatabaseApplication ServiceWeb Bussiness ApplicationOperation<>BorrowerInformation.java

MainWindow.javaReservationFrame.javaTitleInfoWindow.javaBorrowerInfoWindow.java

uml建模的要点总结 篇5

需求分析阶段的任务是确定软件系统功能，用例建模是面向对象软件开发技术中的一个重要部分，它从用户角度描述软件系统功能。以医学院临床管理信息系统为例，利用统一建模语言UML对系统进行抽象，建立用例模型;根据用例建模，采用结构化设计的方法设计出临床毕业实习管理系统功能模块，完成系统初步设计。

0引言

在系统工程及软件工程中，需求分析指在创建一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作。需求分析是软件工程中的一个关键过程[1]，是整个系统开发的基础。需求分析的结果将直接影响到整个软件工程的成功与失败[2]，需求分析阶段的任务是确定软件系统功能。

在UML中，需求模型又称为用例模型，主要用于描述系统的功能性需求，即软件可以实现的功能。将UML的用例模型应用到医学院校临床毕业实习管理系统的需求分析中可以更有效地获取系统功能需求，并清晰描绘出系统功能。

1医学院校临床毕业实习管理系统需求分析

医学院校临床毕业实习根据专业性质不同一般为36～52周，通常安排在第五学年进行。临床医学毕业实习工作主要包括：实习计划制订、实习医院落实、实习生分配、各实习医院学生名单公布，实习日期确定;学生分赴实习医院、确定实习科室轮转日程、确定实习指导教师、分配实习分管床位、按计划进入各实习科室、出科考试。参与这些工作的用户有管理员、教师、学生、系统管理员，不同的用户对系统有不同的功能需求。

学生用户的功能需求为：查询和修改个人信息，填报实习医院，查询实习医院，查看、下载、上传作业，查看各种公共信息，查询学生成绩等;教师用户的功能需求为：查询及维护个人信息，添加、修改、删除实习科目，查看、添加、删除、修改公告，查看、添加、修改、删除作业，查询学生记录、录入学生成绩;管理员用户的功能需求为：查询、添加、删除、修改、审核或导入医院信息、专业信息、实习科目信息和教师信息，发布、查看、修改公告审核和调整学生实习医院等;系统管理员用户的功能需求为：管理整个临床毕业实习管理系统，负责不同用户组的权限定义，进行整个系统的信息初始化及数据维护备份，注册系统用户，负责系统安全管理，硬件环境及网络的管理与维护。

根据上述各种用户的功能需求描述，可以将临床毕业实习管理业务功能归纳为：用户管理、公用信息管理、作业管理、实习成绩管理、公告管理、实习医院管理，如图1所示。

2基于UML用例建模的系统用户功能需求描述

用例(Use Case)是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早由Iva Jackboson博士[3]提出，后来被综合到UML规范之中，成为一种标准化的需求表述体系。UML 是目前最常用的一种面向对象建模语言， 主要包括7种常见类型，即用例图、类图、序列图、状态图、活动图、组件图和部署图，分别用于不同的建模用途。 用例图主要用于对系统、子系统或类的行为进行建模。它只说明系统实现什么功能，而不必说明如何实现。用例图包括系统的执行者和若干个执行用例[4]，以图形化的方式表示系统内部用例、系统外部参考者以及它们之间的交互[5]，从系统外部用户的观点看系统所具功能的高级视图[6]。

医学院校临床毕业实习管理系统中的主要执行者有系统管理员、普通管理员、带教教师及实习学生等，常见的执行用例为数据备份与恢复、用户管理、公用信息管理、公告管理、作业管理、实习成绩管理、实习医院申报和审核管理，由此可以得到系统顶层用例如图2所示。

2.1用户管理用例建模

在医学院校临床实习毕业系统中，为了保证系统数据的安全，建立用户管理。用户管理实现系统中所有用户使用系统资源的权限管理。用户管理的执行者是系统管理员，执行用例为添加用户、修改和查询用户、删除用户、权限定义。具体用例如图3所示。

2.2公用信息管理用例建模

公用信息是维护整个系统正常运行所需的基础数据集，公用信息管理的执行者是各院系管理员，执行用例包括专业信息管理、班级信息管理、学生信息管理、管理员信息管理、部门信息管理、公告类型信息管理、实习科目信息管理、成绩系数管理，具体用例如图4所示。

2.3作业管理用例建模

为巩固学生实习所学知识，检测学生实习效果，并使所学知识转化为技能技巧，在实习过程中，带教教师常常布置相应的作业，教师通过批改学生作业，检查实习效果，因此在医学院校临床毕业实习管理系统中设置作业管理用例图。作业管理的执行者是带教教师和实习生，执行用例包括添加作业、管理作业、批改作业、做作业。具体用例如图5所示。

2.4成绩管理用例建模

医学院校临床毕业考试成绩通常由毕业实习成绩、毕业实践技能考核成绩、毕业理论考核成绩按一定比例构成。专业不同，实习科目不同，毕业实习成绩计算方法也不同。例如临床医学专业实习科目为内科、外科、妇产科、儿科，每个科目的出科考试成绩通常由医德医风考核、病历书写考核、临床实践技能考核、理论考试按一定比例构成，内科、外科、妇产科、儿科的出科考试的平均分构成毕业实习成绩。录入成绩后，学生可查询成绩，各院系(或者医院)的管理员将学生每门实习科目的`出科考试成绩按一定系数比例汇总成毕业实习成绩，各院系管理员将毕业实习成绩、毕业实践技能考核成绩、毕业理论考核成绩按一定比例汇总成毕业考试成绩上交给教务处。成绩管理的执行者有教师、院系管理员和实习生，执行用例包括录入成绩系数、录入成绩、查询成绩、汇总成绩。具体用例如图6所示。2.5公告管理用例建模

公告管理的执行者为系统管理员、管理员和实习生，管理员又可分为教师、教务处管理员、院系管理员、医院管理员，执行用例包括添加公告、上传公告、查看公告、修改公告、删除公告。公告管理用例如图7所示。

公告管理系统内的任何用户都可以查看系统内所有已发布的公告。系统管理员、各院系临床实习教学管理员、医院临床实习管理员、教师都可以添加公告，在公告没有发布前可以修改自己添加的公告，各用户可以删除自己已发布的和未发布的公告。

2.6实习医院申报和审核管理用例建模

实习生在实习前首先要进行实习医院的申报，各院系管理员根据实习生的申报情况进行实习医院的调整，调整完后，学生可以查询具体实习医院信息。各医院管理员根据实习生分配情况，对每一实习科目指派带教教师。实习医院申报和审核管理的执行者为实习生和院系管理员，执行用例包括填报实习医院、查询实习医院(扩展用例包括查询实习科目、查看带教教师)、调整实习医院、管理带教教师。具体用例如图8所示。

3系统模块设计

综合上述需求分析和用例模型分析，采用结构化设计的方法设计出临床毕业实习管理系统功能模块，包括用户管理、公用信息管理、作业管理、实习成绩管理、公告管理、实习医院管理共6个子系统，这些子系统又包含了若干子模块，如图9所示。

4结语

UML九种视图总结 篇6

UML类图中的关系分为四种：泛化关系、依赖关系、关联关系、实现关系；关联关系又可以细化为聚合和组合。

1.1 泛化（Generalization)泛化是父类和子类之间的关系，子类继承父类的所有结构和行为。在子类中可以增加新的结构和行为，也可以覆写父类的行为。

1.2.依赖（Dependencies）

依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的事物，反之不成立。在你想显示一个事物使用另一个事物时使用，两个元素之间的一种关系，其中一个元素（服务者）的变化将影响另一个元素（客户），或向它（客户）提供所需信息。它是一种组成不同模型关系的简便方法。依赖表示两个或多个模型元素之间语义上的关系。它只将模型元素本身连接起来而不需要用一组实例来表达它的意思。它表示了这样一种情形，提供者的某些变化会要求或指示依赖关系中客户的变化。

根据这个定义，关联和泛化都是依赖关系，但是它们有更特别的语义，故它们有自己的名字和详细的语义。我们通常用依赖这个词来指其他的关系。依赖用一个从客户指向提供者的虚箭头表示，用一个构造型的关键字来区分它的种类，通常情况下，依赖关系体现在某个类的方法使用另一个类作为参数。

1.3.关联（Association）

关联是一种结构化的关系，指一种对象和另一种对象有联系。给定有关联的两个类，可以从一个类的对象得到另一个类的对象。

类与类之间由弱到强关系是: 没关系 > 依赖 > 关联 > 聚合 > 组合。

类和类之间八竿子打不着那就是没关系，这个没啥歧义。依赖(dependency)

可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用。用带虚线的箭头。

关联(association)

他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；

依赖和关联区别：我用锤子修了一下桌子，我和锤子之间就是一种依赖，我和我的同事就是一种关联。依赖是一种弱关联，只要一个类 用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系。关联是类之间的一种关系，例如老师教学生，老公和老婆这种关系是非常明显的。依赖是比较陌生，关联是我们已经认识熟悉了。

1.3.1 聚合（Aggregation）

聚合是一种特殊的关联。它描述了“has a”关系，表示整体对象拥有部分对象。

关联关系和聚合关系来语法上是没办法区分的，从语义 上才能更好的区分两者的区别。聚合是较强的关联关系，强调的是整体与部分 之间的关系。

与关联关系一样，聚合关系也是通过类的成员变量 来实现的。

1.3.2 组合（Composition）

组合是聚合的一种形式，它具有更强的拥有关系，强调整体与部分的生命周期 是一致的。整体负责部分的生命周期的管理。如果整体被销毁，部分也必须跟着一起被销毁，如果所有者被复制，部分也必须一起被复制。

与关联关系一样，组合关系也是通过类的成员变量 来实现的。

1.4.实现（Realization）

实现关系指定两个实体之间的一个合约。换言之，一个实体定义一个 合约，而另一个实体保证履行该 合约。

1.5 扩展关系(extends)1.6 包含(include)

1.7 精化关系（refine）UML视图

说明：

构件事物是名词，是模型的静态部分。行为事物是动态部分，表示行为。分组事物是组织部分。注释事物是解释部分。

依赖：一个事物变化会引起另一个事物变化。聚集：特殊的关联，描述整体与部分的组合关系。

泛化：是一种特殊与一般的关系，如子元素（特殊）与父元素（一般），箭头指向父元素。实现：类元之间的关系，其中一个类元指定了由另一个类元保证执行的契约。一般用在接口和实现他们的类之间或用例和实现它们的协作之间。

2.1 类图

用于展现系统中的类以及其之间的关系

对象图：显示了单独的对象及其关系。对象图有助于记录测试用例以及讨论用例。

•静态图：包括类图和对象图。

类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是一种静态关系，在系统的整个生命周期都是有效的。

对象图是类图的实例，几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由 于对象存在生命周期，因此对象图只能在系统某一时间段存在。2.1.1 包

包可直接理解为命名空间，文件夹，是用来组织图形的封装，包图可以用来表述功能组命名空间的组织层次。

•在面向对象软件开发的视角中，类显然是构建整个系统的基本构造块。但是对于庞大的应用系统而言，其包含的类将是成百上千，再加上其间“阡陌交纵”的关联关系、多重性等，必然是大大超出了人们可以处理的复杂度。这也就是引入了“包”这种分组事物构造块。•包的作用是：

1）对语义上相关的元素进行分组； 2）定义模型中的“语义边界”； 3）提供配置管理单元；

4）在设计时，提供并行工作的单元；

5）提供封装的命名空间，其中所有名称必须惟一

上图解释

•首先根据《use》关系，可以发现Client包使用Server包，Server包使用System.Data.SqlClient包，结合其元素，不难得知Client负责Order（订单）的输入，并通过Server来管理用户的登录（LoggingService）和数据库存储（DataBase），而Server包还将通过.NET的SQL Server访问工具包来实现与数据库的实际交互。•接着再看两个《import》，从包的命名和其所属的元素不难发现Rule负责处理一些规则，并引用一个具体的窗体（Window），而Client包则通过引用Rule来实现整个窗体和表单的显示、输入等。并且还将暂存Order（订单）信息。•最后来看包的泛化关系，GUI有两个具体实现，一个是针对C/S的WindowsGUI，一个是实现B/S的WebGUI。依赖关系

•《use》使用关系：是一种默认的依赖关系，说明客户包（发出者）中的元素以某种方式使用提供者包（箭头指向的包）的公共元素，也就是说客户包依赖于提供者包

•《import》引用关系：最普遍的包依赖类型，说明提供者包(箭头指向的包)的命名空间（包本身代表命名空间）将被添加到客户包（发出者）的命名空间中，客户包中的元素也能够访问提供者包的所有公共元素

•《access》访问关系：只想使用提供者包中的元素，而不想将其命名空间合并则应使用该关系

•《trace》追溯关系：想表示一个包到另一个包的历史发展，则需要使用《trace》关系来表示

例子描述

•分析系统工作流程：

1）通过Internet连接到股票信息服务器，获取实时的股票信息，并存入数据库中。2）根据用户的输入和选择，从数据库中获取相应的信息，展现在屏幕中。3）在数据的展现过程中，将需要绘制大量的图表 •根据功能模块组织包：

包之间的依赖关系

2.2 状态图

展示了一个状态机，由状态、转换、事件和活动组成。强调事件行为的顺序。如下图(摘自网络)：

2.2.1 事件

事件是指某个时刻发生的事情。

信号是指从一个对象到另一个对象的明确的单向信号流动。

信号事件：是指发送或者接受信号的事件。

区别：信号是对象间的消息，而信号事件是指某个时刻发生的事情。

变更事件：是指满足布尔表达式而引起的事件。

时间事件：是指在绝对时间上或者在某个时间间隔内发生的事情而引起的事件。

2.2.2 状态

是对象取值和链接的抽象。根据对象的总体行为，将取值和链接的集合组成一个状态。

事件表示时间点，状态表示时间段。

2.2.3 迁移

是指从一种状态到另一种状态的瞬时变化。

2.2.4 电话状态图

2.2.5 活动 2.2.6 增加了活动的电话状态图 2.2.7 嵌套状态图

嵌套状态

2.3 用例图

描述一组用例、参与者以及它们之间的关系，其展示的是该系统在它 的外面环境中所提供的外部可见服务

2.3.1 用例中的包含

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。2.3.2 扩展

将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

2.3.3 泛化

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。2.3.4 实例

2.4 交互图

场景是指系统在某个特定的执行期内发生的一系列事件。

包括序列图（顺序图）和协作图，两者对应，顺序图是强调消息时间顺序，有对象生命线和控制焦点。

协作图是强调接收和发送消息的对象的结构组织，有路径和顺序号

交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流

•活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模

2.4.1 顺序图

显示了交互的参与者以及参与者之间的消息顺序。也显示了系统为了执行全部或部分用例而与参与者的交互。

2.4.2 活动图

显示了组成复杂过程的步骤序列。

活动图的主要元素

•初始节点和活动终点：用一个实心圆表示初始节点，用一个圆圈内加一个实心圆来表示活动终点

•活动节点：是活动图中最主要的元素之一，它用来表示一个活动

•转换：当一个活动结束时，控制流就会马上传递给下一个活动节点，在活动图中称之为“转换”，用一条带箭头的直线来表示 活动图的主要元素

•分支与监护条件：分支是用菱形表示的，它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。

•分岔与汇合：

修改后的简单活动图

带泳道的活动图

带对象流的活动图 复杂活动图 •辅助活动图：

•汇合描述：当汇合的所有入流均到点汇合点时，就将执行汇合点指向的活动节点。但是有些时候，你希望对其做一些约束，这时就可以借助汇合描述来完成。汇合描述实际上是一个约束，其格式就是“{约束条件}”。•发送信号与接收信号：

•如何绘制活动图 绘制活动图

•“活动图” 比较直观易懂；与传统的流程图十分的相近，只要能够读懂活动图，就不难画出活动图

•绘制时首先决定是否采用泳道：主要根据活动图中是否要体现出活动的不同实施者 •然后尽量使用分支、分岔和汇合等基本的建模元素来描述活动控制流程

•如果需要，加入对象流以及对象的状态变化，利用一些高级的建模元素（如辅助活动图、汇合描述、发送信号与接收信号、引脚、扩展区）来表示更多的信息

•活动图的建模关键是表示出控制流，其它的建模元素都是围绕这一宗旨所进行的补充 工作流程，控制流程，业务流程中使用。

• •活动图应用说明

活动图应用说明

•对工作流建模：用于业务建模的时候，每一条泳道表示一个职责单位，该图能够有效地体现出所有职责单位之间的工作职责，业务范围及之间的交互关系、信息流程 建模时应遵循以下策略： •为工作流建立一个焦点，除非你所涉及的系统很小，否则不可能在一张图中显示出系统中所有的控制流

•选择对全部工作流中的一部分有高层职责的业务对象，并为每个重要的业务对象创建一条泳道

•识别工作流初始节点的前置条件和活动终点的后置条件，这可有效地实现对工作流的边界进行建模。

•从该工作流的初始节点开始，说明随时间发生的动作和活动，并在活动图中把它们表示成活动节点

•将复杂的活动或多次出现的活动集合归到一个活动节点，并通过辅助活动图或子活动图来表示它们

•找出连接这些活动节点的转换，首先从工作流的顺序开始，然后考虑分支，接着再考虑分岔和汇合

•如果工作流中涉及重要的对象，则也可以将它们加入到活动图中 •若工作流中有多次启用的，则可采用展开区表示

•对操作建模：每一个对象占据一个泳道，而活动则是该对象的成员方法 •建模时应遵循以下策略：

--收集操作所涉及的抽象概念，包括操作的参数、返回类型、所属类的属性以及某些邻近的类

--识别该操作的初始节点的前置条件和活动终点的后置条件。也要识别在操作执行过程中必须保持的信息

--从该操作的初始节点开始，说明随着时间发生的活动，并在活动图中将它们表示为活动节点

--如果需要，使用分支来说明条件语句及循环语句

--仅当这个操作属于一个主动类时，才在必要时用分岔和汇合来说明并行的控制流程 构件图

2.5 构件图

类是最基础的“模块化”元素，它封装了属性和成员的方法，就像是物理世界中的“分子”。但是，对于复杂的软件系统而言，往往拥有成百上千的各种类。因此，类的粒度太小了，引入更粗的粒度的概念—“构件”

构件是系统中可替换的物理部分，它包装了实现而且遵从并提供一组接口的实现。通俗的说，构件是系统设计的一个模块化元素，它隐藏了内部的实现，对外提供一组外部接口。在系统中，满足相同接口的组件可以自由地替换。

1、构件的表示方法

和类的名称相近，构件的名称也是一个正文字符串，它可以是简单名，也可以是带路径的全名。

2、构件图实例：

2.6 部署图

1、部署图描述了一个系统运行时的硬件节点，在这些节点上运行的软件构件将在何处物理运行以及它们将如何彼此通信的静态视图。

部署图包括两种基本模型元素：节点和节点间的连接。每个模型中，仅包含一个部署图。节点包括两种类型：处理器和设备。

处理器指本身具有计算能力且能执行各各软件的节点，如服务器。

处理器具有处理能力，所以在描述处理器方面应当包含了处理器的调度和进程。

调度指在处理器处理其进程中为实现一定的目的而对共同使用的资源进行时间分配。调度方式包含：抢占，无优先级，循环，算法控制，手动执行。进程表示一个单独的控制纯种，是系统中一个重量级的并发和执行单元。

设备指本身不具备处理能力的节点，如打印机。

连接用来表示两个节点之间的硬件连接。节点之间的连接可以通过光缆直接进行，或通过卫星等方式非直接连接，通常连接都是双向的。连接用实线表示，实线上可加连接名和构造型。

系统开发人员和部署人员可以利用部署图去了解系统的物理运行情况。如果，开发的软件系统只需在一台计算机上运行，且使用的标准设备，则不需要为它画出系统部署图。部署图只需要给那些复杂的物理运行情况进行建模。

部署图显示了系统的硬件，安装在硬件上的软件，用于连接硬件的各种协议和中间件等。

2、部署模型的目的：

描述一个具体应用的主要部署结构，通过对各种硬件，在硬件中的软件以及各种连接协议的显示，可以很好的描述系统是如何部署的；平衡系统运行时的计算资源分布；可以通过连接描述组织的硬件网络结构或者是嵌入式系统等具有多种硬件和软件相关的系统运行模型。

基于UML的建模分析与应用 篇7

1 UML建模概要

UML建模可概要可归纳为静态的建模方法和动态的建模方法这两大类。

用UML进行面向对象的系统分析时,首先是要描述系统的需求，以此确定系统的功能；其次是要依据系统的需求为系统去建立静态模型,进一步去描绘和构建系统的结构；最后是去描绘和阐述系统的行为。在此，应用UML的前两步创建的都是系统的静态的模型,可使用的图形工具包括有用例图、类与对象图、包图、构件图和配置图，这些图形构成了UML建模语言的静态建模机制，通常由用例图和类与对象图来描述和构建系统的功能和结构；进行建模分析的第三步是描述系统可以执行的动作或是执行动作时的时序状态以及存在的交互关系。对这些情形的描述和构建可以使用状态图、活动图、顺序图和合作图等，这些内容则构成了UML建模语言的动态建模机制。

2 UML的建模应用

下面以餐饮企业管理信息系统为例，用UML的建模机制和方法对餐饮企业管理信息系统进行具体的分析建模。

2.1 系统描述

餐饮企业管理信息系统是根据餐饮企业的特点和日常经营活动内容对其业务信息的处理和流程进行规范化的管理。它的使用对象是餐饮管理员和餐饮服务员。

2.2 系统需求分析与建模

2.2.1 系统分析与功能描述

用UML对系统进行需求分析时,是使用用例来获取用户的需求的，一个用例表示系统具有的某一种功能。在此选择用例图描述使用系统和与系统有关的相关联的角色以及这些角色对系统功能的要求，系统中的所有的用例以及这些用例的使用者构成了系统的用例图，以此来描述系统具有的功能和系统的使用者。分析阶段是针对问题域中的类和问题域中的对象展开分析,必须识别出系统中的这些类以及类与类之间的关系,而后由类图去加以描述和说明。而类与类之间是需要协作才能实现用例的，因此这就还要用到动态模型去描述类之间的协作。在系统分析这一阶段和时期,应该仅就问题域的对象去建模,暂不考虑软件系统中涉及的技术细节。

遵循UML的建模思想对餐饮管理信息系统进行具体的分析建模。根据餐饮企业的特点，餐饮企业可见的业务活动和应实现的功能应该包括有菜品业务的管理，该项功能的使用者是餐饮管理员。菜品信息的管理是餐饮管理的核心内容，诸如顾客所点的菜品是否可用、菜品查询、菜品编号、菜品名称、菜品价格等；系统前台的营业管理应该包括营业订单信息的录入、查询、添加、修改和删除等，该项功能的使用者是前台服务员；餐饮企业还应提供餐饮预定服务，应按顾客指定的时间和内容提供餐饮产品，餐饮预订的信息管理应该包括顾客预订信息的录入、查询、添加、修改和删除等，该项功能的使用者是预订服务员；同理，餐饮企业还应提供外卖服务，要实现对外卖信息的录入、查询、添加、修改和删除等，该项功能的使用者是外卖服务员；同时系统还应该具有对员工基本信息的管理功能，这项功能的使用者是餐饮管理员。因此菜品管理、前台业务管理、预定业务管理、外卖业务管理和企业员工管理是餐饮管理信息系统中的五个用例。它们与系统的执行者也就是餐饮管理员、前台服务员、预定服务员和外卖服务员构成了餐饮管理信息系统的用例。

2.2.2 系统结构描述

用类图描述系统的组成结构。类的分析是建立在用例分析的基础上的。类模型是面向对象方法的核心内容，它是对系统中的某一类对象的抽象，它描述了系统中各种对象的类型以及对象之间的各种静态关系，是具有职责的数据模型。每个类都包含其特有的静态属性和动态行为，这些属性和行为标注在类名称的下方，由类可生成具体的数据对象实例。通过分析得知餐饮管理系统中的基本类有：员工类、预定类、前台类、外卖类和菜品类，由此得到概念层上的系统，即餐饮管理信息系统的结构。

2.2.3 系统中类行为的描述

上述系统中的每个类都具有自己的动态行为。接下来给出其动态行为的描述。仅以前台营业为例用UML的状态图和顺序图对前台营业的处理流程进行具体的分析与描述。其他类的动态行为图可以类似的得出。在此，状态图描述了一个具体对象的可能的所有状态和因事件引发的所有的状态的转变。前台营业中，一单业务进入订单生成状态后接下来可能出现的状态有下述几种情况：(1)订单取消、业务结束；(2)订单使用、订单结算、业务结束；(3)订单修改、订单使用、订单结算、业务结束；(4)订单使用、订单修改、再订单使用、订单结算、业务结束。

UML用顺序图描述对象之间随时间推移的动态交互关系。其中每个对象用一条竖线表示其生命线，消息用水平箭头表示由一个对象发送给另一个对象。前台营业时，营业信息由前台营业员添加到系统的营业信息处理界面，产生修改信息时，信息再发送至修改界面，修改完成后再发送到营业信息界面确认，最终再将确认的营业信息发送至营业结算界面。

2.3 系统后期设计目标

下一步系统设计阶段，要进行更进一步的细化分析，对已有的类(包括已经定义的操作和属性)进行细化,适当增加新类，用来处理例如用户接口以及数据库等其他问题。设计阶段还包含总体设计与详细设计，总体设计即高层结构设计，是定义包(即子系统),其中还有包间的依存关系和包间的通信关系；详细设计则是详细描述包中的内容,为下一阶段的编程工作提供一个清晰的类的描述，为后续的编码实现奠定基础。

总体设计中定义的包体现的是一种分组机制。餐饮管理信息系统的包可由如下几个包组成：系统界面、业务对象、数据库和系统应用。这些包中，用户界面包构成将来用户的操作界面；业务对象包包含了分析模型中的所有的类，它们在数据库包的支持下完成任务；数据库包为业务对象包提供服务；应用包向其他包提供服务。

详细设计是将上述包的内容再进行细化，对每个包的内容进行详细的设计。最后根据详细设计的结果进行编码实现。

3 结语

UML是功能强大的可视化建模语言。运用其静态建模机制建立了餐饮管理信息系统的功能模型，运用UML的用例图、UML的类图构建了系统、描述了系统的信息处理功能以及用户与系统之间的关系；应用UML的动态建模方法，使用UML的状态图和顺序图对系统中的业务对象的状态及行为过程进行了描述。为系统的后续设计奠定了基础。

参考文献

[1]张海藩.软件工程[J].北京:人民邮电出版社,2002.

[2]宋国顺.软件工程中UML建模的技术与分析[J].软件导刊,2010(8).

[3]马国勤.基于UML的全程建模研究与应用[J].信息技术,2010(6).

[4]许维.基于UML的嵌入式系统可视化建模研究[J].制造业自动化,2011(1).

uml建模的要点总结 篇8

[关键词] 统一建模语言 企业资源计划系统 建模 分析

一、引言

ERP是企业资源计划 (Enterprise Resources Planning)的缩写，作为企业管理思想，它是一种新型的管理模式;作为一种管理工具，它又是一套先进的计算机管理系统。20世纪80年代以来，国内的经济格局同国外一样发生了重大变化，市场营销观念发展为“市场需要什么就生产和销售什么”，“哪里有消费者的需求，哪里就有机会”。一方面，企业所面临的共同问题是更加激烈的市场竞争，在竞争中技术因素变得越来越重要；另一方面，过去那种仅仅面向“生产经营”的管理方式已不再适应激烈的市场竞争，企业为了适应市场需求，在不断完善其内部生产管理的同时，都在延长自己的产品线，更加注重产品的研究开发、质量控制、市场营销和售后服务等环节，并且发现仅靠自己企业的资源不可能有效地参与市场竞争，而必须把经营过程的有关各方如供应商、客户、制造工厂、分销网络等纳入一个紧密的供应链中。因此，企业的管理技术也必须紧跟不断变化的市场竞争的需求，不断地在其广度和深度上加以完善和更新，不断为企业提供竞争制胜的有力手段。而ERP正是這一背景下的产物，它是对企业的三大流：物流、资金流、信息流进行全面一体化管理的信息系统。

二、UML简介

UML是统一建模语言的缩写，是一种用于描述、可视化和构架软件系统，以及商业建模的语言。它溶入了软件工程领域的新思想、新方法和新技术，支持从需求分析开始的软件开发的全过程，随着人们对软件工程概念的重视，UML在软件开发中的应用也日益广泛。

UML提供了9种简便直观的图形来帮助用户分析、设计和管理系统中各个元素的信息及其之间的关系。根据UML的建模机制，UML可看成为以4+1视角模型来表示的软件系统的图形体系结构。这5部分从不同角度体现了UML建模系统的特性，它们包括用例视角、设计视角、实现视角、进程视角和配置视角，如图1所示。图中可清楚地看出用例视角在整个视角模型整合中的特殊地位，这也体现了用例分析在UML建模过程中的重要性。

三、基于UML的ERP系统分析和设计

在ERP系统中，生产控制是关键的模块之一，主要是了解加工什么、什么时候加工、加工多少、在什么地方加工和怎么加工。它面临生产的第一线，直接影响到一个企业的生产，一旦生产控制系统出现问题，则给企业带来巨大的经济损失。图2给出一个简化的生产控制结构图。

UML易于表达，其功能强大，适用于信息管理系统、实时系统、分布式系统、Web系统等的开发。下面结合生产控制系统的生产调度部分来阐述如何利用UML工具对ERP系统进行分析和设计。

1.用例图

用例图表示一个系统对于系统外部的交互者的功能。强调从用户的角度看到的或需要的系统功能。其用例是系统提供的高级功能模块，根据用例图的描述，可对生产控制系统的调度部分的功能划分为接受订单、任务平衡、下达生产任务等，当然还应有相关的智能功能，比如，任务调整、组合查询、意外处理等功能。而该系统的主要用户就是管理者和生产车间（生产车间是任务的接受者，也作为用户考虑），调度部分的用例图如图3所示。

2.交互图

交互图包括顺序图和协作图，顺序图反映若干个对象之间的动态协作关系，主要分析对象之间已发消息的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一具体位置将会发生什么事件。所以，顺序图是UML分析业务过程中非常重要的一种图，它是对整个系统工作流程的一个过程反映，直接影响其构造的系统将来是否和实际系统相符合。

要画出顺序图，就必须对整个工作流程的细节都要清楚了解，否则就不可能画出系统相应的顺序图来。在生产控制系统中的一个主要的简化的业务流程就是接受MPS的订单，进行任务平衡和分解，向相应工作中心下达生产任务，向库存发物料需求单，各个工作中心相互合作，在产品的生产过程中请求质量检验部门的检验，控制不合格产品的非法流动。

协作图是表示角色之间交互的视图，除了反映角色之间的消息变化（交互）外，还能够反映角色和它们之间的关系（称为上下文相关）。由于协作图和顺序图透视反映角色之间的交互，所以建模时可任意选择一种图来反映对象间的协作关系，并根据其强调的是时间序列还是上下文相关来确定画哪一种图，在ROSE工具中，提供了方便的顺序图和协作图的转化工具。

3.类图、对象图和包图

类图表示系统中需要处理的事务，类与类之间有多种连接方式（关系），比如关联、依赖、通用化、打包等。这些关系体现在类图的内部结构之中，通过类的属性和操作反映出来。一般一个系统有若干个类图，一个类图不一定包含系统中的所有类，一个类可以加到几个类图中。

在生产控制系统中，根据其简化的业务流程可得出这些类：调度员类（完成订单任务的接受、判断和下达）；MPS任务类（对订单任务的处理）；任务平衡类（提供任务平衡计算的方法）；工作中心类（任务加工和内部工作处理）；质量检验类（提供质量检验）；库存类（提供生产产品的仓库管理）；意外处理类（对不合格产品的处理）。

对象图是类图的实例化，不是真正的类，是类图的一个范例，它及时、具体的反映了系统执行到某处时的工作状况。

包图是设计元素分组的通用组织机制，利用包图将系统逐步细化，分成若干子系统，这样便于设计者理解、修改、维护和测试。

4.活动图

活动图反应一个连续的活动流，主要用于描述某个操作执行时的活动状态，对调度部分的接受定单而言，首先获取各个任务定单，定单合法检查、定单分类，更新数据库。其他用例的活动与此相似的进行分析和处理。

5.状态图

状态图是对类所描述的对象的一个补充，显示了类的所有对象可能具有的状态，以及引起的状态变化。在生产系统中，一个产品从MPS订单到加工成型入库，要经历不同的状态：在开始是MPS订单状态，在调度员接受后，进入生产预准备态，在经过平衡计算后，下达到各个工作中心后，进入生产态，在生产加工以后，进入质量检验状态，合格后，提交到库存，进入库存态，如果不合格，则进入意外处理态。这里的不同状态由不同的事件来触发。不难看出，在描述一个跨越多个用例的单个对象的分析时状态图是非常有用和方便的。

6.组件图和展开图

组件图描述软件组件和组件之间的关系，显示代码的结构。其中的组件可以是源组件、二进制、可执行组件，在生产控制系统中可以分为调度界面子程序、MPS任务子程序、生产平衡处理子程序、生产处理子程序、质量检验子程序、库存管理子程序等组件。

展开图描述系统拓扑的最终物理描述。生产控制系统中，考虑到生产场所相对集中，在企业内部网上本应采用C/S结构的物理架构，但考虑到调度管理可能是远程的控制，因此最好采用B/S和C/S结构的方式，管理人员在本地时，直接在本地计算机上调度，在异地时，可通过Web方式来进行生产调度。

四、结束语

在软件工程领域，UML建模语言的提出改善了面向对象的分析与设计，使得以从需求分析开始的软件开发过程变得清晰明了，有据可依，并最终能够形成文档，保证软件产品的高质量。本文通过介绍UML建模在ERP开发应用中的一个方面，充分展示了UML工具在ERP系统开发设计中的重要作用。此外，由于系统的设计不可能完全预计需求，因而它应该是也必须是可以更改的，如果认为UML的模型是完美的，开发者生搬硬套地以此设计代码，将极有可能导致不符合实际需要的产品出现。

参考文献:

[1]冀振燕:UML系统分析设计与应用案例[M].北京:人民邮电出版社,2003

[2]蒋慧吴礼发:UML Programming Guide[M].北京:希望电脑公司，2001

[3]Wendy Boggs,Michael Boggs.UML with Rational Rose 2002从入门到精通[M].北京:电子工业出版社,2002

[4]尤克滨:UML应用建模实践过程[M].北京:机械工业出版社2003