UML建模范文

UML建模范文（精选10篇）

UML建模 第1篇

UML主要是由Rational software公司和它的三位巨匠Grady Booch、Jim Rumbaugh和Ivar Jacohson开发的。这一标记法凝聚了三位设计者的精华,并因此促成了一个国际公认的标准的产生[1]。

1 UML的基本概念

UML(统一建模语言,Unified Modeling Language)是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。作为一种建模语言,UML的定义包括语义和语法两部分。UML的语义描述基于UML提供的精确元模型的定义(元模型为UML的所有元素在语法和语义上提供了简单、一致和通用的定义性说明,并且UML还支持对元模型的扩展定义),UML的语义用自然语言描述,同时在语义上,模型是元模型的实例;UML的语法定义了UML的概念、元素、符号表示法及用法,为开发者或开发工具使用这些图形符号和文本语法提供了系统建模标准。

UML是一种可视化的建模语言,对其各种建模元素可进行详细说明,并能生成所建模型的文档[2]。使用UML时,要从不同的角色观察系统,为此定义了一个概念“视图”。视图是对系统模型在某方面的投影,它注重于系统的某个方面,每个视图是图的协作,由视图可以定义模型,模型在语义上是闭合的,它从特定的角度、在一定抽象层次上描述目标系统。可以把视图组织成模型,开发人员可从各视角观察并使用模型。

UML定义了5大类共9种视图:1)用例图;2)静态图,包括类图、对象图和包图;3)行为图;4)交互图,它描述对象间的交互关系;5)实现图,包括构件图和配置图。

2 UML建模过程及建模支持工具

Rational统一过程是由UML的创始者Booch等人提出的一种面向对象软件开发过程。这种开发过程的特点:以用例驱动,以体系结构为中心,迭代和递增的开发过程。[5]Rational统一过程把软件项目的开发过程划分为4个阶段:开始、详细描述、构建、移交。在每个阶段内都有一些迭代。一个迭代代表一个完整的开发周期,从需求分析到实现和测试,结果是一个可执行项目的发布。每一次迭代都包含编码、测试和集成,所得产品应满足项目需求的某一子集,或提交给用户,或纯粹是内部提交。每次迭代都包含了软件生命周期的所有阶段。在开始阶段,焦点是需求的获得;在详细描述阶段,重点是转向分析和设计;在构建阶段,实现是中心任务;移交阶段的中心则在于配置。

当然好方法一定要有好的工具支持才能取得好的效果,由于UML本身是一个以图形化图符为主的建模方法,因此在图形绘制及模型管理上会随着软件规模的扩大而变得困难[3]。这时UML支持工具就显得更为重要,目前最常用的两种工具是Rational软件公司的Rational Rose和Microsoft公司的Visio,尽管在大多数情况下Rational Rose显得有些昂贵,但它确是集多种功能于一身的软件包,它可使代码反向转化为模型、改变模型以及可以对代码进行更新来反应模型的变化。与Rational Rose相比,Microsoft公司的Visio却相当便宜,并且允许你用图表示任何事情,从架构布局到办公计划、指向路标和工程计划。Microsoft公司的Visio的最大卖点就是它是Microsoft Office的一个组件,这意味着它的界面、控件和功能与Word和Excel的标准一样。

3 UML的应用

现以图书管理系统为例说明UML建模的基本过程[4]。该过程主要包括:需求分析、设计阶段、构造阶段和测试阶段。首先我们进行需求分析,需求分析主要是定义用例,对该系统的主要功能进行描述,在这部分主要是应用用例图。在图书管理系统中,当图书馆新进一批图书,图书管理员需要在电脑中新增书籍信息,对已有的书籍信息要能够修改,查询书籍信息,所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行,当有读者借阅书籍时,图书管理系统还要能登记外借信息,并能对外借书籍信息进行查询,期间图书管理员可以按特定时间段统计购买新书的金额、册数,图书管理系统用例图如图1所示。

其次是设计阶段,在设计阶段,对需求阶段的成果提出技术上的解决方案。对类进行细化建模,并提出技术框架,例如,用户界面、面向对象数据库的永久性对象和系统接口等。该阶段最后为系统实施阶段产生详细说明文档。

再次,在构造阶段把设计阶段的类转换成某种面向对象程序设计语言的代码。

最后是测试阶段。这一阶段通常包括单元测试、集成测试、系统测试和验收测试。单元测试使用类图和类的定义文档。集成测试使用协作图,而系统测试使用用例图,用例图可以用于证实客户所期望的系统行为。

可以看出,UML提供的五类视图从不同应用层次出发,贯穿于整个系统设计的全过程,减少了设计的盲目性,提高了设计的效率。

4 结束语

在很短的时间内,UML已经成为软件工业中占支配地位的建模语言。目前它不仅是事实上的建模语言标准,也正在快速地成为法律上的标准。

参考文献

[1]Jason T.UML基础教程[M].张瑜,杨继萍,译.北京:清华大学出版社,2003.

[2]华冠萍.浅述UML及其应用[J].电脑知识与技术,2006(3).

[3]郑燕,王杨.浅谈UML[J].科技视野,2008(7).

[4]江进.浅谈面向对象建模语言UML[J].福建电脑,2008(8).

UML建模的要点总结 第2篇

预备知识：

一、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建模技术研究 第3篇

UML是模型驱动架构的一种关键技术, 每一个由模型驱动架构构建的模型都是基于一个平台无关的UML模型。但是, UML的语义不是十分精确;UML在软件分析设计阶段是不可以执行, 不能验证的, 增加了后期开发的风险;UML无法直接表示数据处理过程, 如对象与对象是如何产生实际的连接等。为了解决建模的这些问题OMG对UML进行了扩充, 在UML中加入了动作语义使得模型可以是可执行的。

2 可执行UML概述

可执行UML规定了一个简单, 一致的UML符号的子集。这些符号的选择是基于现实世界中的结构, 而不是基于在某个软件系统的构造中用到的个别结构。不仅仅这些符号本身是简单的, 而且组织和集成它们的方式也必须遵循严格的规则, 而这些规则能够保持整个系统规约的清晰性。

核心UML加上动作语义就成为可执行UML[1] (Executable UML) 。可执行UML用动作规约语言对UML进行扩充, 使得模型可以被更精确地描述, 得到可执行的平台无关模型PIM, 同时可执行UML去掉了庞大的UML体系中语义较弱的部分, 解决了UML歧义问题, 使得建模过程更加简洁明了。

可执行UML就是UML的一个可执行版本[2], 它还包括了:

一个被清洗定义的简单模型结构;

精确地动作语义, 这些语义已经成为UML标准的一部分;

一个适应性很强的动作规约语言;

一个配套的关键过程:MDA, 该过程面向:可执行建模, 大规模复用, 基于模式的设计。

3 可执行UML建模过程

(1) 系统用例建模

用例仅从用户使用系统的角度描述系统中的信息, 并不描述系统内部对该功能的具体操作方式, 确定系统能够做什么?谁来使用这个系统?用例它描述了待开发系统的功能需求, 它将系统看做黑盒, 从参与者的角度来理解系统, 它驱动了需求分析之后各阶段的开发工作, 不仅在开发过程中保证了系统所有功能的实现, 而且用于验证和检测所开发的系统。建立用例的过程是一个不断细化的过程, 刚开始建立的用例可能比较粗糙, 随着对需求的不断挖掘和理解, 逐步细化用例。

(2) 域的划分

系统分解的基本单元是域。域表示一个大的可复用组件, 采用由UML包图和依赖关系构成的域图来描述。建立一个系统涉及许多不同的主题并把它们连贯起来形成一个整体。每个主题都是一个域, 是能够被理解和使用可执行UML建模的。我们可以为每个域建立一个或多个可执行UML模型。

域的类型有可以分为以下四种它们分别是:应用域、服务域、体系结构域、实现域。

(3) 使用域进行平台无关建模

建立一个域的平台无关模型将在3个层次中构建:

第一层次是对域中的类建模。

平台无关模型的主要组成部分是类图, 每个域都有一个类图。类图是系统的静态视点。它描述了类和关系。类图描述了被分析的系统的抽象表示, 以及这些抽象表示之间的关联关系。类图不描述什么时候创建或删除一个类或关系的实例, 也不描述如何使用对象或如何查询关系。换句话说, 类图是声明性规约。对于域的类图的正确答案不是唯一的, 对于任何域, 都有多个可能的类图能够满足相关要求。

第二层次是定义域的动态行为。

模型需要定义类之间如何互相实现域中要求的行为。在可执行UML中提供了两种状态机的表现形式, 一种是状态图, 状态图显示了状态, 事件, 和转换, 提供了状态机的图形表示, 但图不能涵盖所有可能的组合;一种是状态转换表 (state transition table简称SST) , 使用状态转换表确保底层模型的完整性。一个是代表性的图形, 但不完整, 另一种是表格, 显示状态和事件的所有组合。在状态转移表, 每行代表一个状态, 每列表示一个事件。这些单元格指定什么时候会发生在一个给定的状态 (行) 检测到一个特定的事件 (列) 的对象, 这些单元格被称为效果。

第三层次是详细定义动作, 即用动作语言来表示。

动作语言是平台无关的语言, 用来在可执行UML模型的上下文中详述处理行为。该语言的目的就是为将要被系统执行的处理行为提供无歧义的、精确的且易读的定义。UML并没有定义动作语言, 而是在UML标准中加入了动作语义。而动作语言符合UML的动作语义

(4) 验证PIM

我们可以用模拟器来验证每个域的PIM是否表现出我们所要求的行为, 最后, 我们通过集成一系列相互兼容的域来完成系统的集成。

4 可执行UML的动作语言

可执行UML中关键的一环就是动作语言[3], 动作语言能够精确描述对象行为, 能够使建立的模型是可执行, 动作语言是抽象的、独立于各种程序编程语言 (如C++, Java等) 。在国外, 目前已经有几个工具厂商推出了可执行UML的动作语言和用于系统开发的CASE工具, 通过这些工具可以对模型进行执行和验证。下面介绍几种运用比较广泛的动作语言:

(1) Object Action Language (OAL)

这个语言由Project Technology, Inc.公司发布, OAL被用于定义模型中过程的语义。在由Project Technology, Inc.公司发布的BridgePoint CASE中, OAL可被用于以下几个模型元素中:对象状态、定义两个域模块之间的桥程序、对象的函数、基于类和对象的操作和基于对象属性的操作。

(2) Action Specification Language (ASL)

动作规约语言ASL是一个与实现语言无关的动作语言, 通过它可以使模型成为可执行和可验证。这个语言由Kennedy Carter公司发布。ASL是满足"Precise Action Semantics"的, 它是UML标准的一个扩展。当ASL被执行时, 模型变得更加容易理解。

(3) SMALL

SMALL是Shlaer-Mellor Action Language的缩写, 最后一个L是没有意义的, 这个语言是由Stephen J.Mellor创造的。Gregory Rochford和Cortland D.Starrett建立了一个解析器来验证SMALL语法。

(4) TALL

TALL是That Action Language的缩写, 最后一个L没有意义。这个语言是由Marc J.Balcer, Conrad Bock和Dirk Epperson共同创造的。

结束语。可执行UML解决了UML在应用过程中暴露出的各种弊端如UML在软件分析设计阶段是不可以执行, 不能验证的, 增加了后期开发的风险;信息表达度问题, UML无法直接表示数据处理过程, 如对象与对象是如何产生实际的连接等。近几年来, 基于可执行UML的软件开发方法已成为软件开发方法的一个研究方向

摘要：能够降低软件开发成本、提高软件生产效率、可移植性、增加软件的可重用性的技术越来越受到人们的关注, 通过可执行UML技术, 使得软件开发在前期可以得到执行和验证, 通过可执行UML的动作语言可以解释对象之间的行为等。

关键词：可执行UML,UML,平台无关

参考文献

[1]刘建宾, 李建忠, 余楚迎.模型驱动体系架构MDA及xUML规范在其语境中的探讨[J]汕头大学学报 (自然科学版) , 2004年11月58-65.

[2]Chris R aistrick, Psul Francis, John Wright, Colin Carter, Lan Wilkiie著.赵建华, 张天等译.MDA与可执行UML[M]机械工业出版社, 2006.4.

UML建模实验指导书总结 第4篇

实验一 熟悉UML开发工具Microsoft Visio 2007 【实验目的】

熟悉UML开发工具Microsoft Visio 2007。【实验要求】

1． 熟悉Visio的UML建模绘图界面。2． 通过绘制类图学习Visio的使用方法。3． 通过绘制对象图学习Visio的使用方法。4． 通过绘制顺序图学习Visio的使用方法。【实验步骤】

一．熟悉Visio的UML建模绘图界面 1．进入Visio的UML建模绘图界面 通过“开始”|“程序”，运行Microsoft Office Visio 2007，出现Microsoft Visio界面。在左侧的“类别”区域中单击“软件”，然后在右侧的“模板”中单击“UML模型图”，则进入Visio的UML建模绘图界面。

2．熟悉UML建模绘图界面

在Visio的UML建模绘图界面中，最大的白色区域就是绘图区。左上方的“形状”窗口就是Visio的UML元素调板，它由很多的标签页组成。每个标签页提供了一个特定的UML图标。左下方的“模型资源管理器”就是Visio的字典，字典就是所创建的所有元素及其属性的记录的集合。当Visio打开并准备开始UML绘图的时候，“UML静态结构”标签页就会激活，我们就可以创建类图和对象图了。

二．绘制类图

下面我们使用Visio来绘制一个如图1所示的行星系统的类模型。

图1 一个行星系统的类图

1．从“UML静态结构”标签页中选择“类”图标并把它拖放到绘图区中。双击绘图区

中的类图标，出现“UML类属性”窗口。在“名称”字段中输入“PlanetarySystem”来重新命名这个类。单击“确定”按钮回到绘图界面。我们可以通过控制工具栏中“缩放”按钮的显示比例，使界面中的类图标显示合适的大小。采用同样的方法添加Planet类。在“模型资源管理器”中反映出了增加的新类。

2．下面我们为Planet类添加两个属性和一个操作，并把它设置为一个抽象类。

在Planet类上双击打开“UML 类属性”对话框。选中“IsAbstract”复选框，然后，从左边的“类别”区域选择“特性”，在右边的对话框中打开“特性”表。单击“新建”按钮，则在 “特性”表中添加了一行，在“特性”表项中输入diameter。采用同样的方式加入 distanceFromStar属性。

然后从“类别”区域选择“操作”，打开“操作”表，单击“新建”按钮，则在 “操作”表中添加了一行，在“操作”表项中输入“receiveLight”。单击“确定”按钮，赋予抽象类Planet相应的属性和操作。

3．注意每个属性左边的减号和每个操作左边的加号，它们表示可见性。为了使图显得比较简单，我们可以在图中去掉它们。只需要在Planet类上右击，打开弹出式菜单，选择“形状显示选项”，打开“UML 形状显示选项”对话框。去掉“可见性”复选框，单击“确定”按钮，则Planet类的属性和操作前面不再显示可见性。

4．我们把其他的类拖拽到大图中，然后添加组成关系。

首先是组成关系。从“UML静态结构”标签页中把“聚合”图标拖拽到绘图区，实心菱形一端连接到PlanetarySystem，另一端（尾端）连接到Star。

在图中，我们可以看到组成关系的每一段都有多重关系、可见性和缺省名。为了在图中去掉缺省名和可见性，在组成关系上右击，在弹出菜单中选择“形状显示选项”。这次，在“UML 形状显示选项”对话框中，去掉“第一个端名”、“第二个端名”和“端的可见性”选项，单击“确定”按钮。

现在我们来关注一下Star类的多重关系。双击组成关系图标，打开“UML关联属性”对话框。在“关联端”表格中，选择“结束2”一行“多重性”列的单元格。单击这个单元格中的下拉列表框，显示出“结束2”的可能多重性关系的一个列表。选择“1”并单击“确定”按钮，我们将在图中得到所选多重性的表示。

采用同样的方式拖拽“聚合”图标，先把菱形箭头的一端连在“PlanetarySystem”，然后再把尾端连接到Planet类，并进行多重性等相关设置。

5．向图中添加继承关系。

从“UML静态结构”标签页中将“泛化”符号拖拽到绘图区，把三角形的一端连接到Planet，尾端连接到HabitablePlanet。重复拖拽一个“泛化”符号，把三角形的一端连接到Planet，尾段连接到NonHabitablePlanet。完成这些操作后，绘图区中就是完整的类图。

三．绘制对象图

下面我们使用Visio绘制一个如图2所示的Earth和Sun的对象模型。

图2 Earth和Sun的对象图

1．在“模型资源管理器”中“顶层包”的文件夹上右击，从弹出菜单中选择“新建”|“静态结构图”，则创建并打开了一个新的静态结构图。从“形状”的“UML 静态结构”标签页中选择“对象”图标，拖拽到绘图区。

2．在对象图标上双击打开“UML对象属性”对话框。在“名称”字段中输入“theSun”替代缺省名字。我们还需要表明theSum是Star类的一个实例，为此，选择“类”字段并单击下拉列表。从类列表中选择“顶层包：：Star”，然后单击“确定”按钮。

3．用相同的一系列步骤创建HabitablePlanet类的一个earth对象。双击打开“UML对象属性”对话框。从“类别”区域选择“特性值”打开“Attribute Values”表。在这张表中，我们可以填入diameter和distanceFromTheStar属性的值，这两个属性是HabitablePlanet继承自Planet的。在“值”列赋值，单击“确定”按钮。

4．在对象之间添加连接。

从“UML 静态结构”标签页中拖动“链接”符号到绘图区，将其两端分别和对象连接起来。完成这个步骤后，“结束1”和“结束2”的名字就出现了，在连接上右击，并通过“形状显示选项”可以从图中移除它们。

四．绘制顺序图

下面我们使用Visio绘制一个如图3所示的示意theSun和Earth之间的一个交互的顺序图（简化的图形，只有一条消息）。

图3 示意theSun和earth之间的一个交互的顺序图

1．在“模型资源管理器”的“顶层包”图标上右击，从弹出菜单上选择“新建”|“序列图”，则打开一个新的绘图区。

2．从“UML序列”标签中，拖拽一个“对象生命线”图标并把它放入到绘图区。双击图标打开“UML 分类器角色属性”对话框，在“名称”区域命名对象以后，在“分类器”区域从你创建的类列表中选定对象所属的类，单击“确定”按钮。

3．右击新添加的对象生命线，单击“UML形状显示选项”，通过选择“分类器名称”复选框可以显示类名。

4．通过一系列类似的步骤，创建另一个表示Earth的对象生命线图标。5．创建从sun对象到earth对象的消息。

从“UML 序列图”中选择 “消息”图标，并把它拖拽到绘图区，把它的尾部连接到sun对象的生命线，把它的头部连接到earth对象的生命线。

要改变消息的缺省标记，双击消息图标打开“UML 消息属性”对话框。由于只有一个可能的操作，名字和来自earth对象的消息所请求的操作都已经被选好了。单击“确定”按钮，则把操作放到消息之上。

6．从“UML序列”标签中，拖拽一个“激活条”图标完成顺序图。【思考问题】

1．对于本实验中创建的类图和对象图能在两个不同的绘图文件中分别创建吗？类图和顺序图呢？为什么？

2．本实验中创建的顺序图是在“顶层包”下新建的序列图中创建的，请问顺序图能在静态结构图中创建吗？为什么？

实验二 用例图设计

【实验目的】

掌握在Visio下用例图的设计。【实验要求】

1． 针对网上选课系统掌握识别参与者和用例的方法。2． 学习通过Visio绘制用例图的方法。3． 掌握如何对每个用例进行用例描述。【实验步骤】

一．网上选课系统需求分析

某学校的网上选课系统主要包括如下功能：

1． 管理员通过系统管理界面进入，建立本学期要开的各种课程，将课程信息保存在数据库中并可以对课程进行改动和删除。

2． 学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程、选课以及付费。同样，通过业务层，这些操作结果存入数据库中。二．在Visio中设置全局属性 1． 添加四个模型

单击Visio界面上菜单栏中的“UML”菜单，选择其下拉菜单中的“模型”，则打开了“UML模型”窗口。单击“新建”按钮，在“模型”表项中输入模型的名字。依次添加4个模型：用例模型、分析模型、设计模型和实现模型。

下面简要介绍一下四个模型的功能。

（1）用例模型：用例贯穿于建模的整个过程，因为软件和顶层包的价值就在于实现用例，从而为用户提供期望的功能。用例细化可使用活动图、顺序图等。

（2）分析模型：识别分析类，利用分析类实现用例，是用例模型中用例细化活动的延伸。主要使用顺序图和协作图实现用例。

（3）设计模型：将分析模型转化为解决方案。分析类转化为一个或多个设计类、接口、类（和接口）的操作、类的特性都被完整的定义。根据解决问题的需要，可能会引入一些包，这些包提供了诸如数据库访问、异常处理、分布式通信等基础服务。

通常有两种途径获得设计类：

1）将分析类转化一个或多个设计类；

2）通过引入基础服务获得设计类。

用设计类实现用例：使用顺序图和协作图。

设计系统原型：通过它验证解决方案的正确性，并为实现者提供指南。

（4）实现模型：将设计模型转化可执行代码的过程。关键的活动有：代码编写、测试、部署。使用构件图来描述系统的静态实现视图，使用部署图来描述系统的动态实现视图。

2． 将UML系统改名为SelectCourseSystem 在“模型资源管理器”窗口下，右击顶层节点，选择“属性”命令。在“UML子系统属性”对话框的“名称”文本框中输入新的名称“SelectCourseSystem”。在“文档”文本框中可以输入一些说明消息。

3． 设置模型的数据类型 在默认情况下，UML中可以使用的数据类型有4个包。本例中将目标语言绑定为C++，所以仅保留C++数据类型包。

单击Visio界面上菜单栏中的“UML”菜单，选择其下拉菜单中的“选项”，则打开了“UML选项”窗口。在 “UML文档”选项卡中选择C++数据类型。

三．实现用例模型 1． 识别参与者

本系统涉及的用户包括管理员Registrar和学生Student，他们是用例图的参与者，他们的主要特征相似，都具有姓名和学号等信息，所以可以抽象出“基”参与者人People，而Registrar和Student则从People统一派生。数据库管理系统Database是另外一个参与者。

2． 识别用例

识别、详述用例是用例建模过程中最重要的活动。顺着参与者出发，通过考虑参与者和系统的交互，可以识别出主要用例。

（1）与Students参与者相关的用例有哪些？（2）与Registrar参与者相关的用例有哪些？（3）哪些用例与Database参与者相关？

3． 绘制参与者以及参与者之间的关系

（1）在“模型资源管理器”中，右击“用例模型”下的“顶层包”，选择“新建”|“主角”命令，出现“UML主角属性”对话框。将主角命名为“Registrar”，然后在“文档”栏中输入一些描述管理员主角职责的文字。其中的完整路径显示了主角在UML模型中所处的位置。单击“确定”按钮，则在“用例模型”的“顶层包”下新增了一个名为“Registrar”的主角。

重复上面操作，在用例模型的顶层包中添加上所有主角。

（2）下面绘图角色之间的关系。

双击“用例模型”“顶层包”下的“静态结构图”，这时会在绘图画板中打开。分别将Registrar角色、Student角色、People角色拖放到绘图画板，然后将“UML静态结构”标签页中的“泛化”图标拖放到绘图画板，并用它来连接两个角色。4． 绘制用例以及用例之间的泛化关系

（1）在“模型资源管理器”中，右击“用例模型”下的“顶层包”，选择“新建”|“用例”命令，出现“UML用例属性”对话框。在“名称”框中输入一个你所找到用例名，单击“确定”按钮。

重复上面操作，在用例模型的顶层包中添加上所有用例。

（2）用例之间如果存在泛化关系，则拖拽“UML静态结构”标签页中的“泛化”图标到静态结构图中，来连接两个用例。5． 绘制用例图

（1）在“模型资源管理器”中，右击“用例模型”下的“顶层包”，选择“新建”|“用例图”，这时会新建一个名为“用例-1”的空白用例图，右击新建的空白用例图节点，选择“重命名”，可对用例图重新命名。

（2）在“形状”中的“UML用例”标签页中，将“系统边界”形状拖放到用例图中，双击系统边界形状，可进行重新命名。

（3）在“模型资源管理器”中“用例模型”下，选中“Registrar”、“Student”和“Database”主角，拖放到用例图的系统边界之外。将“用例模型”下创建的用例拖放到用例图的“系统边界”内。

（4）绘制参与者与用例之间的关联。

如果主角和系统的交互包含某个用例，那么主角和该用例之间存在通信关系。将“UML用例”标签页中的“通信”图标拖放到用例图中，用它来连接参与者和用例。

端点名表示通信连接两端在通信中扮演的角色。端点的多重性表示通信另一端连接的一个对象对应着本端点连接的对象的数量。右击通信连线，选择“属性”，出现“UML关联属性”对话框，可以设置连接线的两个端点的多重性，还可以设置连接线的导航方向。为了降低图表的复杂性，通常只有在例外的情况下才显示导向性。

如果不关心端点名等信息，为了在视觉效果上隐藏这些信息，右击通信连线，选择“形状显示选项”命令，进行设置即可。（5）绘制用例之间的包含和扩展关系。

用例之间如果存在包含关系，则通过拖拽“UML用例”标签页中的“用”图标来连接两个用例；用例之间如果存在扩展关系，则通过拖拽“UML用例”标签页中的“扩展”图标来连接两个用例。

用例图作为一种UML模型元素，也必须用包来组织。本例中将两个用例图都放到了用例模型顶层包中，还可以用注释元素对用例图作简单说明。

6．对每个用例进行用例描述。为了便于以后对用例进行细化，每个用例都要提供用例描述。一个用例是多个场景组成的，对每个用例的场景进行场景描述，写入Word文档中。

【思考问题】

1．绘制用例图的步骤是什么？

2．结合网上选课系统的用例图设计实例，总结一下用例图在系统分析过程中所起的作用。

实验三 类图设计

【实验目的】

掌握在Visio下类图的设计。【实验要求】

1． 通过网上选课系统学习识别类的方法。

2． 通过网上选课系统学习识别类之间关系的方法。3． 学习使用Visio绘制类图。【实验步骤】 一．识别类 1．通过实验二中用例图的设计，我们找到了四个参与者：管理员Registrar，学生Student，学生和管理员的父类People，数据库Database。这些参与者都可以作为类图中的类。

2．识别选课系统中其他的类。

在选课系统中，还能找出哪些类？这些类有哪些属性和操作？ 二．绘制类图 1．绘制类

在“模型资源管理器”中，双击“分析模型”中“顶层包”下的静态结构图，此时在绘图区中显示的则是此静态结构图。按照实验一中给出的方法绘制这四个类，包括这些类的属性和操作。

2．绘制类之间的关系

确定类之间是否有关系以及有什么关系。

如果存在“关联”关系，则将“形状”窗口中“UML静态结构”标签页中的“二元关

联”图标拖到绘图区，来连接两个类；如果存在“泛化”关系，则将“UML静态结构”标签页中的“泛化”图标拖到绘图区，来连接类；如果存在“聚集”或“组成”关系，则将“UML静态结构”标签页中的“复合”图标拖到绘图区，来连接类；如果存在“依赖”关系，则将“UML静态结构”标签页中的“依赖关系”图标拖到绘图区，来连接类。

在绘图区中双击这些关系图标，可以打开它们的属性对话框来修改属性。具体操作可参考实验一。

【思考问题】

1．绘制类图的步骤是什么？ 2．结合网上选课系统的用例图设计实例，总结一下类图在系统分析过程中所起的作用。

实验四 状态图设计

【实验目的】

掌握在Visio下状态图的设计。【实验要求】

1． 通过网上选课系统学习识别对象状态的方法。2． 通过网上选课系统理解对象状态的转换。3． 学习使用Visio绘制状态图。【实验步骤】

一．识别课程类（对象）的状态 我们考察一个课程类（对象）（Course）的状态变化过程。

课程对象被创建、添加到数据库中。管理员可以删除、修改课程信息，在某个学期，开设该课程，如果选修人数超过指定人数，就不再允许学生选这门课程。学期结束，课程的状态终止。

通过上述需求描述，我们能够识别出课程类（对象）的哪些状态？ 二．绘制状态图

1．在“模型资源管理器”的“分析模型”中，右击“课程”类，选择“新建”|“状态图”，这时会新建一个名为“状态图-1”的空白状态图，右击新建的空白状态图节点，选择“重命名”，可对状态图重新命名。

2．在“形状”窗口的“UML状态图”标签页中，选中“初始状态”图标并拖拽到绘图区，选中“最终状态”图标并拖拽到绘图区。

3．在“UML状态图”标签页中，选中“状态”图标并拖拽到绘图区，来添加一个状态。双击此状态，打开“UML状态属性”对话框，进行相应的设置。

4．在“UML状态图”标签页中，选中“复合状态”图标并拖拽到绘图区，来添加一个复合状态。双击此状态，打开“UML复合状态属性”对话框，进行相应的设置。

在“模型资源管理器”中，单击此复合状态前的“+”号，可以看到此复合状态下有一个新的状态图，可以通过双击此状态图，在绘图区中进行此状态图的绘制。

5．在“UML状态图”标签页中，选中“转换”图标并拖拽到绘图区，来添加状态到状态间的转换。双击转换图标，进入“UML转换属性”对话框，进行相应设置。

【思考问题】

1．总结绘制状态图的步骤。

2．结合网上选课系统的状态图设计实例，总结一下状态图在系统分析设计过程中所起的作用。

实验五 顺序图设计

【实验目的】

掌握在Visio下顺序图的设计。【实验要求】

1． 学习根据用例描述绘制顺序图的方法。2．学习使用Visio绘制顺序图。【实验步骤】

下面我们以Select Course（选课）用例为例来设计和制作顺序图。

一．识别对象

首先，查找Select Course用例的用例描述，从事件流中发现涉及以下对象： 1．界面 2．课程

3．对于业务层的操作，也应该有对象进行处理。4．事件流中涉及的参与者有：学生、数据库。二．识别对象之间的交互

分析对象、参与者之间交互的消息。本用例主要有以下交互： 1．学生通过界面发送选课命令。2．界面向控制对象请求课程信息。

3．控制对象向数据库发送查询数据信息。4．控制对象暂存数据库的查询结果。

5．界面对象从控制对象中取得所有的课程信息。6．在界面上显示所有的课程信息。

7．界面对象发送命令要求控制对象删除课程信息。8．学生选择课程。

9．界面对象要求学生输入学号。

10．界面对象向控制对象发送信息，查询该生是否可以选择选定的课程。11．控制对象从数据库中查询关联信息。12．控制对象判断是否可以选课。

13．如果可以选课，则向数据库中添加关联信息。14．向界面对象返回信息。三．绘制Select Course顺序图

1．在“模型资源管理器”的“分析模型”中，右击“顶层包”，选择“新建”|“序列图”，这时会新建一个名为“序列-1”的空白序列图，右击新建的空白序列图节点，选择“重命名”，可对序列图重新命名。

2．在“形状”窗口的“UML序列”标签页中，拖拽“对象生命线”到绘图区，在绘图区中双击此对象生命线，出现“UML分类器角色属性”对话框，在“名称”栏输入名字，在“分类器”栏中选择所属的类。单击“确定”按钮。

要想显示出分类器名字，可以右击此对象生命线，选择“形状显示选项”，打开“UML形状显示选项”对话框，选中“分类器名称”项，单击“确认”即可。

3．绘制对象间的通信。

在 “UML序列”标签页中，拖拽“消息”图标到绘图区，连接对象的生命线。双击“消

息”，打开“UML消息属性”对话框，进行消息的属性设置。通过拖拽“激活”图标到绘图区的生命线上，来表示该对象正在执行某个操作。

四．绘制其他用例的顺序图

按照上述例子的方法，画出网上选课系统中其他用例的顺序图。【思考问题】

1．总结绘制顺序图的步骤。

2．结合网上选课系统的顺序图设计实例，总结一下顺序图在系统分析设计过程中所起的作用。

实验六 协作图设计

【实验目的】

掌握在Visio下协作图的设计。【实验要求】

1． 学习根据用例描述绘制协作图的方法。2．学习使用Visio绘制协作图。【实验步骤】

下面我们以Select Course（选课）用例为例来设计和制作协作图。

一．识别对象

首先，查找Select Course用例的用例描述，从事件流中发现涉及以下对象： 1．界面 2．课程

3．对于业务层的操作，也应该有对象进行处理。4．事件流中涉及的参与者有：学生、数据库。二．识别对象之间的交互

分析对象、参与者之间交互的消息。本用例主要有以下交互： 1．学生通过界面发送选课命令。2．界面向控制对象请求课程信息。

3．控制对象向数据库发送查询数据信息。4．控制对象暂存数据库的查询结果。

5．界面对象从控制对象中取得所有的课程信息。6．在界面上显示所有的课程信息。

7．界面对象发送命令要求控制对象删除课程信息。8．学生选择课程。

9．界面对象要求学生输入学号。

10．界面对象向控制对象发送信息，查询该生是否可以选择选定的课程。11．控制对象从数据库中查询关联信息。12．控制对象判断是否可以选课。

13．如果可以选课，则向数据库中添加关联信息。14．向界面对象返回信息。三．绘制Select Course协作图

1．在“模型资源管理器”的“分析模型”中，右击“顶层包”，选择“新建”|“协作图”，这时会新建一个名为“协作-1”的空白序列图，右击新建的空白序列图节点，选择“重

命名”，可对协作图重新命名。

2．在“形状”窗口的“UML协作”标签页中，拖拽“分类器角色”到绘图区，在绘图区中双击此分类器角色，出现“UML分类器角色属性”对话框，在“名称”栏输入名字，在“分类器”栏中选择所属的类。单击“确定”按钮。

要想显示出分类器名字，可以右击此分类器角色，选择“形状显示选项”，打开“UML形状显示选项”对话框，选中“分类器名称”项，单击“确认”即可。

3．绘制对象间的通信。

在 “UML序列”标签页中，拖拽“关联角色”图标到绘图区，连接对象。双击此关联角色，打开“UML关联角色属性”对话框，进行属性设置。

四．绘制其他用例的协作图

按照上述例子的方法，画出网上选课系统中其他用例的协作图。【思考问题】

1．总结绘制协作图的步骤。

2．结合网上选课系统的协作图设计实例，总结一下协作图在系统分析设计过程中所起的作用。

实验七 活动图设计

【实验目的】

掌握在Visio下活动图的设计。【实验要求】

1． 学习根据用例描述绘制活动图的方法。2．学习使用Visio绘制活动图。【实验步骤】

下面我们以Add Course（添加课程）用例为例来设计和制作活动图。

一．识别活动

针对Add Course用例的用例描述，因为管理员密码验证过程可以抽取出来，作为通用的流程，所以将管理员输入课程信息作为起始的活动。内容如下：（1）管理员输入信息。

（2）系统验证是否和已有课程冲突。A：有冲突。

（3）系统添加新课程，提示课程添加成功。（4）系统重新进入管理主界面，显示所有课程。（5）用例结束。其他事件流： A：有冲突

（1）系统提示冲突，显示冲突课程信息。（2）用户重新输入。

（3）继续验证直到无冲突。

（4）进入添加课程事件流第（3）步。

根据以上描述并进一步细化，能识别出哪些活动？ 二．识别负责活动的角色

在绘制活动图的时候，要对角色可视化，需要画出泳道。所以我们要识别出负责每个活动的角色。

三．绘制活动图

1．在“模型资源管理器”的“用例模型”中，右击“顶层包”，选择“新建”|“活动图”进行创建。这时会新建一个名为“活动-1”的空白活动图，右击新建的空白活动图节点，选择“重命名”，可对活动图重新命名。

2．在“形状”窗口的“UML活动”标签页中，分别拖动“初始状态”图标和“最终状态”图标到绘图区。

3．添加泳道。

在“UML活动”标签中，将“泳道”图标拖到绘图区来添加泳道。双击泳道，可以打开“UML分区属性”对话框，进行分区属性的设置。

4．添加状态。

在“UML活动”标签中，将“动态状态”或“状态”图标拖到绘图区来添加活动。双击图标可以打开属性对话框，进行属性的设置。

动作状态表示对象正在执行一个不可中断的原子操作。状态可以被分解成其他动作状态或状态，因此如有必要，可用一个单独的活动图描述状态。

5．添加转换。

在“UML活动”标签中，“判定”图标来表示在某一点做出判定。“转换（分叉）”和“转换（连接）”图标来描述并发的活动，此时包含多个控制流。“控制流”描述单个控制的简单转换。双击图标可以在相应的属性对话框中进行属性设置。

四．绘制其他用例的活动图

按照上述例子的方法，画出网上选课系统中其他用例的活动图。【思考问题】

1．总结绘制活动图的步骤。

基于UML的产品建模方法研究 第5篇

制造业是经济建设和国防建设的基础, 也是社会发展的原动力。产品信息建模是21世纪制造业的一项关键支撑技术, 合理的产品模型对产品开发和企业生存具有重要的意义。产品模型是产品全生命周期管理的底层支撑, 国内外对企业产品信息建模方面的研究已经开展多年, 取得相当多的研究成果。比较著名的研究成果有CIM-OSA方法、ARIS体系结构、IDEF方法、GRAI/GIM方法与PERA方法等, 另外工作流建模技术、面向对象建模方法也取得了不少研究成果[1]。

UML是一种通用的可视化建模语言。它是在Booch, OMT和OOSE三大面向对象方法学基础上, 吸取了其他面向对象开发方法和近30年软件工程的经验和成果, 抽象出的模型语言[2]。UML的目标是以面向对象图的方式来描述任何类型的系统, 具有很广的应用领域。其中, 最常用的是建立软件系统的模型, 但它同样可以用于描述非软件领域的系统[3]。目前, UML已在企事业、金融、交通、电讯、国防、医学、科研、网络等领域得到实际应用。

传统的建模方法, 描述系统和语义约束能力差, 基于UML的产品模型可以解决全生命周期产品定义、过程和资源的一致性问题, 同时提供了多种视图来满足不同角度创建系统的需要。现以UML建模语言为基础, 依据UML四层元元模型结构结合元模型理论、面向对象的建模方法和广义产品建模方法寻求一种能为企业建立支持产品全生命周期, 具有多角度, 多视图, 界面友好, 便于理解、并且有严格语义约束, 数据完整一致, 少冗余的产品信息模型的建模方法。

1 基于UML的产品三层结构模型

元模型就是关于模型的模型, 是关于如何建立模型、模型的语义或模型之间如何集成和互操作等信息的描述。元模型由于比模型的抽象程度高, 因此能够较好地解决模型集成中地问题。元模型是用来解决模型层难以解决的问题, 同样在元模型层难以解决的问题可以通过元元模型来解决[4]。

软件工程中, 为统一定义各种建模语言及模型间的转换关系, OMG试图提出各建模语言 (元模型) 的公共抽象 (元元模型) 来统一建模语言的表达, 继而可以统一各模型之间转换规则的表达, 于是在1999年提出了MOF规范, 此规范借用UML的图示方法, 基于面向对象思想的概念定义元建模元素。现在OMG给出的各项规范中, UML, CMW和CORBA IDL等均已采用基于MOF的定义[5]。

根据软件行业中UML和MOF定义的四层元元模型结构和相互关系如图1所示[6], 定义产品模型中三层元元模型结构和相互关系如图2所示。

基于对UML四层元模型结构中MOF层和UML层的分析, 结合机械类产品所要表达的内容, 给出以下定义:

1) 产品元元类:位于产品元元模型层中不再细分, 具有自我解释定义的类。

2) 产品元类:位于产品元模型层中类, 是产品元元类的实例。

3) 产品元元模型:模型中除了被解释的元素以外, 必须全部由产品元元类构成。

4) 产品元模型:产品元元模型的实例, 由产品元类或产品元类和产品元元类构成。

建立产品元元模型层目的是为了解决产品模型层无法解决的问题如产品元模型层语义含糊、模型集成和信息共享等。产品元元模型层的类型系统比产品模型层的类型系统更细致地划分了模型的类型系统中的各种概念、关系、约束等, 并且还包含关于产品元模型的控制和指导等信息的概括和抽象, 将产品元元模型的这些概念实例化就可以对某个具体元模型的建模进行监控。

产品元模型层中的产品元类是产品元元类的综合实例, 是在产品全生命周期建模中的主要元素, 产品元类在UML建模环境语义约束下按照相互间的关系进行一定形式的交换构成了产品的元模型。产品元模型加直观体现出面向对象的思想, 同时语法规则和语义约束在UML建模工具环境下得到了严格的约束。用于元模型层建模的产品元类的定义是在产品元元层来完成的。通过这种层级约束, 确保了产品建模中模型逻辑一致性和数据完整性。

2 产品元元层和产品元层

利用UML的扩展机制结合广义建模理论建立如图3所示的产品元元模型基本组成结构[7]。给出以下几种类的定义:

1) 信息类:基于广义产品模型下的不同层次, 不同类型信息的抽象定义。

2) 过程信息类:信息类中关于对产品生命过程方面描述类的抽象定义。

3) 结构信息类:信息类中关于对产品结构方面描述类的抽象定义。

4) 关系类:用于定义广义产品模型环境中“点”与“点”之间的关联信息, 即产品生命周期过程中各类关联属性的抽象定义。

5) 结构关系类:关系类中关于对产品结构关系方面描述类的抽象定义。

6) 过程关系类:关系类中关于对产品过程关系方面描述类的抽象定义。

产品元元类由信息类和关系类构成;信息类由结构信息类和过程信息类构成;关系类由结构关系类和过程关系类构成。产品元类依赖产品元元类来描述。

结构信息要满足表达、评价和管理的需要。因此结构信息包括表达性结构信息、评价性结构信息和管理性结构信息。

过程是不同状态之间活动的集合, 活动则以一系列的步骤或行为以及行为所引起的对象状态的改变为特征。可以认为活动以前面的活动所产生的产品数据 (或状态信息) 为输入, 经过决策, 并采用一定的行为或步骤, 对输入的产品相关信息进行操作, 形成新的产品状态或产品数据。过程作为活动的记录, 其内容应该能够体现活动的特征。

关系信息体现了在装配层次上对产品结构的描述, 是产品功能特征的体现, 因为机械产品的功能主要通过构成产品的零、部件之间静态或动态的配合关系来实现, 这类信息的获得主要在产品的概念设计和结构设计阶段。按照广义产品建模方法结构关系根据性质不同分为三类, 分别是功能关系、定位关系和运动关系。

过程是由一个和若干个活动 (过程单元) 构成的。这些活动之间存在关系, 或表现为一种时间性的关系, 或表现为一种逻辑性的关系。

产品元元类库是产品元元类的集合, 按照所述方法, 建立产品元元类库如图4所示。

以其中结构关系元元类包为例展开抽象产品结构关系元元类如图5所示。

根据产品全生命周期建模需要, 定义产品元类由产品基本元类、产品需求元类、产品设计元类、产品制造元类、产品销售元类和产品服务元类构成, 如图6所示。

建立产品元类库如图7所示。

以其中产品服务元类包为例展开抽象产品结构关系元元类如图8所示。

3 产品生命周期建模

参照PTC公司对产品全生命周期阶段的划分, 将产品生命周期划分为需求分析、设计、制造、销售和服务五个阶段[8,9]。

1) 产品需求分析阶段:在这一阶段企业通过调查和分析市场和客户需求, 确定产品的基本功能, 性能, 使用环境和其他约束, 实现产品信息从客户角度向设计者角度的转换。

2) 产品设计阶段:产品设计阶段一般要分为三个阶段, 概念设计, 详细设计和工艺设计。在这三个阶段中, 产品设计所需的信息是不同的。随着设计的深入进行, 产品所包含的信息越来越丰富。概念设计阶段完成产品的功能定义和原理设计, 提供原理设计方案;详细设计阶段细化原理方案, 提供原理的具体实现结构, 得到产品的技术方案;工艺设计阶段则是对产品制造工艺流程的设计, 是产品设计阶段向制造阶段的过渡。

3) 产品制造阶段:产品制造阶段包括生产准备、供应、加工、外协, 装配等过程, 是产品在物理上形成的阶段。在该阶段, 相关人员对各种计划进行分解, 优化调度配制所需的制造资源, 进行加工装配等活动。

4) 产品销售阶段:产品销售阶段的主要活动包括, 市场推广、产品发布、销售战略制定以及客户管理、定单管理等。PLM系统负责企业与分销商、客户以及供应商之间的信息协调和管理, 保证定单、生产、库存和销售等环节的畅通和一致性。

5) 产品服务阶段:产品服务阶段是从物理产品形成到产品报废为止的时间跨度。在这个阶段企业服务人员对产品进行测试, 交付用户使用。典型的服务包括产品安装、使用培训、故障诊断和维护等。

对应产品生命周期的划分, 产品生命周期各阶段模型对应企业人员职责的活动图泳道模型如图9所示。

产品全生命周期建模目的是建立面向产品全生命周期的统一的、具有可扩充性的能表达完整信息的产品模型, 该产品模型能随着产品开发进程自动扩张, 并从设计模型自动映射为不同目的的模型, 如可制造性评价模型、成本估算模型、可装配性模型、可维护性模型等, 同时产品模型应能全面表达和评价与产品全生命周期相关的性能指标[10]。

产品全生命周期模型用例模型如图10所示。产品整个周期包含了客户和外部企业在内的多范围用例。随着先进制造技术的发展, 企业间信息交流的日益频繁, 产品生产已走出单一企业, 向着联盟方向发展。

以产品制造阶段为例, 建立产品制造阶段元模型如图11所示。产品制造活动在产品设计模型的基础上, 根据产品的加工和装配关系, 改变产品的设计BOM, 参照工艺BOM, 经过演化映射形成制造BOM。零件可以划分为由其他企业加工的外协件和本企业加工的自制件。对于外协件, 制造企业需要到市场中进行采购。零件的加工需要按照工艺路线和规则进行, 所以零件类依赖于工艺类。部件类是一组相互聚合的零件组合。机械产品的功能和设计者的意图体现于零件的具体几何结构, 特别是零件间的相互连接和装配关系, 这就要求制造企业重视产品的装配工艺。各种制造和装配工艺不仅规定了工艺操作方法, 也提出了产品制造过程中的资源要求。部件需要按照装配工艺进行装配操作, 在部件类与工艺之间存在依赖关系。同时, 加工工艺、装配工艺和生产计划依赖于企业资源。

4 采用UML对模型映射关系建模

以产品BOM为例说明采用UML对模型关系建模的方法。

BOM的含义是物料项清单 (bill of material) 即构成一个物料项的所有子物料项的列表。在产品的全生命周期中, 存在着各种面向企业不同部门、具有不同用途的BOM文件, 不同的部门为了各自的目的设计、生成、管理和使用BOM。在产品的全生命周期中, BOM视图种类和相互间关系如图12所示[11]。

下面, 以设计BOM到工艺BOM的演化映射为例来说明采用UML对模型映射关系建模的方法。一般来说, 由于工艺的变动而导致其映射信息不同的原因主要可以归结为[11]:

1) 继承部件映射规则Fi ( ) 。

在产品P中, 如果设计BOM中某一部件为继承部件, 则在工艺BOM中该部件完全继承其在设计BOM中定义的装配关系。图13中的e部件。

2) 虚设部件映射规则Fv ( ) 。

如果在工艺中将设计BOM中某部件定义为虚设部件, 则在工艺BOM中应该将该部件在设计BOM中的下属所有零部件按设计BOM中表述的数量关系移动到虚设部件的父件中去。如图13中的c部件。

3) 中间部件映射规则Fm ( ) 。

如果某部件是中间部件, 则应该根据工艺BOM中的中间部件相关信息和设计BOM的中间部件的父子件的相关信息, 在制造BOM中添加中间部件的装配关系信息。如图13中的f部件。

4) 外协部件映射规则Fc ( ) 。

在制造BOM中只描述外协部件本身, 而不描述外协部件的下级零部件物料信息。因此, 所有的外协部件处于BOM树的叶节点上, 外协部件在制造BOM中可以视为一个零件来处理, 正如在设计BOM/制造BOM的形式化描述中不描述处于叶结点的零件一样, 外协部件应设成空元素。如图13中的d部件。

自然属性映射符合继承部件映射规则, 所以从EBOM到PPBOM的演化映射模型如图14所示。

5 产品层建模

产品层的建模即是对产品元层模型的实例化, 现以平口钳为例, 对元模型的应用进行详细讨论, 验证基于UML的产品建模方法的准确性和有效性。

平口钳, 作为一种夹具, 在生产工作中得到广泛使用。Pro/E中产品的3D模型如图15所示。

平口钳的产品层结构模型如图16所示。平口钳产品由平口钳固定部件和平口钳活动部件两个部件以及1个到多个平口钳文档组成。其中平口钳固定部件由下列零件组成:1个固定钳身、1个平口钳垫圈、1根丝杠、1个垫圈、2个螺母、1块钳口板和2个螺钉。平口钳活动部件包括下列零件:1个平口钳螺钉、1个平口钳螺母、1块活动钳口、2个螺钉和1块钳口板。

平口钳的产品层关系模型如图17所示。平口钳固定部件和平口钳活动部件是靠丝杠和平口钳螺母之间的丝杠螺母连接关系装配的, 固定钳身和丝杠关系是轴孔连接, 钳口板和固定钳身以及钳口板和活动钳口的关系是螺钉连接, 活动钳口和平口钳螺钉为轴孔连接, 活动钳口和平口钳螺母是平面配合, 平口钳螺钉和平口钳螺母是螺栓连接, 平口钳螺钉和活动钳口是轴孔连接关系。产品层模型是这两种模型的叠加。

应用前面所建立的BOM映射元模型来建立平口钳产品的设计BOM向工艺BOM的映射模型如图18所示。

6 结论

文中所做研究工作目的是为了寻求更加有效建立支持产品全生命周期模型的方法。通过以上工作, 建立了基于UML的产品信息模型。UML严格的语法规则和语义约束为产品定义、制造、服务等过程和资源提供了一个联结, 解决了全生命周期产品定义、过程和资源的一致性和数据冗余问题。同时产品全生命周期建模是一项多角色参于多角度需求的复杂工程, 基于UML的产品建模方法提供了多种视图来满足不同角色和角度创建系统的需要, 支持产品静态、动态和工作流建模。该工作扩展了以往对产品建模方法的研究, 为进一步对产品信息的管理奠定了基础。

摘要：为有效保证产品全生命周期产品定义、过程和资源的一致性, 同时满足系统多角度创建系统的需要, 提出基于UML的产品建模方法。通过定义“产品元元模型层”、“产品元模型层”和“产品模型层”三层产品模型结构及其内容和相互关系, 实现了产品建模定义、约束统一性, 实际应用表明基于UML的产品建模方法的有效性和可行性。

关键词：产品元元模型,产品元模型,产品模型

参考文献

[1]杨云涛, 王润孝, 等.企业建模方法及ARIS建模过程应用研究[J].组合机床与自动化加工技术, 2007 (3) :86-88.

[2]Joseph Schmuller.李虎, 赵龙刚译.UML基础、案例与应用[M].3版.北京:人民邮电出版社, 2006:4-5.

[3]徐宝文, 周毓明, 卢红敏.UML与软件建模[M].北京:清华大学出版社, 2006:6-7.

[4]肖田元.虚拟制造[M].北京:清华大学出版社, 2004.65.

[5]Object Management Group (OMG) .Meta Object Facility (MOF) Core Specifica-tion.Version2.0:5P (http://www.omg.org/docs/formal/06-01-01.pdf, accessed in October 2007) .

[6]Joseph Schmuller.UML基础、案例与应用[M].3版.李虎, 赵龙刚, 译.北京:人民邮电出版社, 2006.156.

[7]王涛.广义产品建模方法的研究[D].北京:清华大学博士学位论文.2004:23-88.

[8]黄双喜, 范玉顺.产品生命周期管理研究综述[J].计算机集成制造系统CIMS.2004, 10 (1) :1-9.

[9]舒启林, 王成恩.产品全生命周期中面向客户服务的产品模型[J].中国机械工程.2005, 16 (15) :1358-1362.

[10]沈建新, 周儒荣.产品全生命周期管理系统框架及关键技术研究[J].南京航空航天大学学报.2003, 35 (5) :565-571.

UML用例建模的分析及使用 第6篇

UML(Unified Modeling Language)是一种编制系统蓝图的标准化语言,它可以实现大型复杂系统各种成分描述的可视化、说明并构造系统模型,以及建立各种所需的文档,是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。在系统分析阶段,一般用UML设计各种模型图,主要包括用例图、交互图、静态图、行为图、实现图等5大类10种模型图,根据系统具体情况来确定使用哪些图。总之,UML的作用就是从静态和动态方面用很多模型图来全面描述要开发的系统。

2 用例建模

用例建模是UML建模的一部分,也是UML中最基础的部分。其主要功能是用来表达系统的功能性需求或行为。用例建模可分为用例图和用例描述:用例图包含六个元素,分别是:参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。用例图示由参与者、用例、系统边界、箭头组成,用画图的方法来完成;用例描述用来详细描述用例图中每个用例,用文本文档来完成。

2.1 用例图

用例图主要用于对系统、子系统或类的行为进行建模。它只说明系统实现什么功能,而不必说明如何实现,表示了从系统的外部用户的观点看系统应具有的功能的高级视图[1]。

2.1.1 参与者(Actor)

参与者是直接与系统相互作用的系统、子系统或类的外部实体的抽象。是指系统以外的,在使用系统或在与系统交互中所扮演的角色。因此参与者可以是人,可以是事物,也可以是时间或其他系统等。并且,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。比如小明是网站系统管理员,参与网站管理系统的交互,他既可以作为管理员参与管理,也可以作为用户访问并使用该网站,这时小明是两个不同的参与者。参与者在模型图中用简笔人物画来表示,人物下面标明参与者的名称。

2.1.2 用例(Use Case)

用例是系统提供的功能块,说明参与者如何使用系统;是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果,用例是参与者需要系统做的事情。用例命名时,可以使用一个简单、描述性的名称,一般为带有动作性的词。用例在模型图中用椭圆来表示,椭圆下面标明用例的名称。用例的名字非正式描述了参与者与对象之间的事件序列,应该能直接表示它所包含的业务工作。

2.1.3 系统边界

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分,边界外表示系统外部。系统边界在模型图中用方框来表示,同时标明系统的名称,参与者画在边界的外面,用例画在边界里面。由于系统边界的作用不是很明显,在制作模型图时可省略。

2.1.4 箭头

关系反应了参与者和用例之间、用例与用例之间以及参与者和参与者之间的相互作用。在一个用例图中,可能会出现关联关系、包含关系、扩展关系以及泛化关系。画图时,用箭头表示参与者和系统通过相互发送信号或消息进行交互的关系。箭头尾部用来表示启动交互的一方,箭头头部用来表示被启动的一方,其中用例总是要由参与者来启动。

2.2 用例描述

用例图只是简单地用图描述系统,但为了使用户对该系统有更加详细的了解,对于每个用例,都需要有详细的说明,这时需要写出用例描述。

用例描述的内容,没有固定的格式,但系统中重要的部分需要写进用例描述中。一般包括:简要描述(说明)、前置(前提)条件、基本事件流、其他事件流、异常事件流、后置(事后)条件等[2]。其中:

简要描述:对用例的角色、目的的简要描述;

前置条件:执行用例之前系统必须要处于的状态,或者要满足的条件;

基本事件流:描述该用例的基本流程,指每个流程都“正常”运作时所发生的事情,没有任何备选流和异常流,而只有最有可能发生的事件流;

其他事件流:表示这个行为或流程是可选的或备选的,并不是总要执行它们;

异常事件流:表示发生了某些非正常的事情所要执行的流程;

后置条件:用例一旦执行后系统所处的状态。

3 用例图和用例描述设计实例

下面通过一个教务网络管理系统来简单的分析用例图的画法和用例描述的写法。该系统分为前台客户系统和后台管理系统。

前台客户系统的用例图如图1所示。

后台管理系统用例图如2所示。

篇幅所限,对于用例描述,只列出后台管理系统中的网站公告发布用例的描述。如下:

用例名称:网站公告发布。

用例标识号:202。

参与者:管理员。

简要描述:管理员用来填写和修改教务网站首页的公告,公告最终显示在教务网站的首页上。

前置条件:管理员已经登陆教务网络管理系统。

基本事件流:

1)管理员鼠标点击“修改公告”按钮。

2)系统出现一个文本框,显示着原来的公告内容。

3)管理员可以在文本框上修改公告,也可以完全删除,重新写新的公告。

4)管理员编辑完文本框,按“提交”按钮,首页公告修改。

5)用例终止。

其他事件流:在按“提交”按钮之前,管理员随时可以按“返回”按钮,此时文本框的任何修改内容都不会影响网站首页的公告。

异常事件流:

1)提示错误信息,管理员确认。

2)返回到管理系统主页面。

后置条件:网站首页的公告信息被修改。

注释:无。

4 总结

用例图主要在系统需求分析阶段和系统设计阶段使用,在系统的需求分析阶段,用例图用来获取系统的需求,理解系统应当如何工作;在系统设计阶段,用例图可以用来规定系统要实现的行为。在用例建模过程中可以依照以下角度来帮助用户顺利完成建模。

4.1 对语境建模

对于一个系统,会有一些事物存在于其内部,而一些事物存在于其外部。存在于系统内部的事物的任务是完成系统外部事物所期望的系统行为,存在于系统外部并与其进行交互的事物构成了系统的语境,即系统存在的环境。在UML建模中,用例图对系统的语境进行建模,强调的是系统的外部参与者[3]。对系统语境建模应当遵循以下的方法:

1)用以下几组事物来识别系统外部的参与者:需要从系统中得到帮助以完成其任务的组;执行系统功能时所必须的组;与外部硬件或其它软件系统进行交互的组;为了管理和维护而执行某些辅助功能的组。

2)将类似的参与者组织成泛化/特殊化的结构层次。

3)在需要加深理解的地方,为每个参与者提供一个构造型。

4)将参与者放入到用例图中,并说明参与者与用例之间的通信路径。

4.2 对需求建模

需求就是根据用户对产品功能的期望,提出产品外部功能的描述。需要分析所要做的工作是获取系统的需求,归纳系统所要实现的功能,使最终的软件产品最大限度的贴近用户的要求。对系统需求建模可以参考以下的方法:

1)识别系统外部的参与者来建立系统的语境。

2)考虑每一个参与者期望的行为或需要系统提供的行为。

3)把公共的行为命名为用例。

4)分解公共行为,放入到新的用例中以供其它的用例使用:分解异常行为,放入新用例中以延伸为主要的控制流。简而言之,就是确定提供者用例和扩展用例。

5)在用例视图中对用例、参与者和它们之间的关系进行建模。

摘要：用例建模是UML建模的基础部分,其主要功能是用来表达系统的功能性需求或行为。该文以实例说明用例建模中用例图、用例描述部分的设计过程。

关键词：UML,用例图,用例建模

参考文献

[1]刘敏莺,杨丽,文学义.Rational Rose2003基础教程[M].北京:冶金工业出版社,2005.

[2]曲维娟.UML中各种图形工具的科学选择与灵活应用[J].河北:河北能源职业技术学院学报,2008(28):77-79.

UML数据库建模关键技术分析 第7篇

1 关于UML数据库建模方法的分析

在实际操作中, 为了确保UML数据库建模系统的建立健全, 我们需要实现数据库与UML模型图相关环节的一一对应, 通常来讲, 我们可以利用UML中的表达方法对数据库相关环节进行映射, 或者实现物理概念与数据库逻辑与UML表达方法的具体对应, 实现两者的具体映射。

在具体运行中, 我们可以将数据库中的相关逻辑环节与物理概念, 利用UML的语言表达相关设计思路。这个环节的关键部分是对数据库中物理概念的具体应用, 比如用UML中的部署图来表达实际操作中的数据库服务器及其通信协议等。UML的包、角色代替数据库中的表空间等, 利用UML中的类图和对象图和属性来表现具体数据库中的表、列、行等, 一般来说, UML类图的关系能够有效实现数据库的设计方案, 有利于数据库设计的完美展示。这种程序的进行离不开数据库设计方案, 在进行具体的设计方案设计后, 可以确定该系统数据库设计方案的信息系统, 以有利于内部相关环节的协作共同, 有利于数据库设计的信息系统的建立健全。

在日常数据库模式分析中, 我们需要UML中的表达方法对数据库进行相关环节的模型映射。这个环节的关键点在于UML中的类图为关键点, 向数据库相关程序进行映射, 相关人员要利用UML, 进行概念建模的具体实现。将UML数据建模中的相关设计成果, 利用一系列的映射方法促进后端的ORDBMS的实现。利用这种设计方法有利于有效分解UML图, 实现静态结构与动态结构的分离, 有利于数据库建模系统的建立健全, 在此过程中, 我们把类图的操作当作是动态结构, 以确保数据库逻辑模型的建立, 将数据库表中信息存放系统看做是静态结构系统, 在实际操作中, 动态结构能够有效实现数据库逻辑规则以及界面代码的相关环节, 这种设计方法有利于促进系统分析设计到数据库设计的转化, 有利于减少数据与相关操作信息的流失。

根据上文所讲述的, 该文对第一种方案进行具体分析, 促进其解决方案的升级。在数据建模系统环节中, 利用UML类图环节, 实现对数据库相关程序的映射, 这是目前来说最有效的方案了, 它有利于促进系统特征与结构的具体分析, 有利于进行具体的相关对象的分析与设计。

2 关于UML数据库静态建模的分析

在实际操作中, 针对对类的属性进行范围确定。以研究文献的视角进行具体划分, 可以将其分为接口类、短暂类以及永续类这三个部分。这几个不同的类分别拥有不同的作用, 一般来说永续类, 应用于需要持久性的存储对象, 以促进建模方案中的数据设计。在实际操作中, 利用一对一方法进行永续类的具体对映, 以实现数据表的实体化, 在这一过程中, 该信息系统是教务系统, 其主要通过静态信息进行处理, 一般来说此系统中出现的类都是需要进行保存的永续类, 而其对映的短暂类则出现在状态转化图中, 系统与程序设计的接口我们可以视作系统接口类。

在具体建模中, 要针对UML的对象特点, 在类图中, 进行一系列的一对多的方式的继承结构的对映, 以有效界定超类和子类的具体概念。在具体建模过程中, 利用UML数据库建模中的UML的泛化关系, 进行继承关系的数据表对映, 积极利用相关方式, 进行数据表表达。在具体操作中将所有的子类与父类结合成为单一的数据表格;将父类的属性、操作复制到各个子类之中, 成为若干个子类别数据表;将父类与各个子类分别对映成数据表, 父类的主键将成为子类数据表的主/外键。

3 关于UML数据库动态建模的分析

在实际操作中, 为了弥补UML数据库动态建模中的不足, 需要进行积极的描述补充工作, 实现状态图、交互图、存储过程、方法环节的具体实现。在此过程中, 类图不包括交互图、活动图与状态图, 但是在实际操作中, 都能借以补充说明操作的行为或处理程序。因此, 可从这些图形的内容去探讨它们与程序代码的对映关系, 以找出实现类操作的步骤与原则。

3.1 关于类图中操作映射的分析, 一般来说, 操作是一种广泛的代表

概念, 它有利于实现某一类对象的相关服务环节的实现, 它包含了类里面的相关行为。在具体的操作逻辑以及程序处理过程中, 我们可以利用活动图、结构化英文以及虚拟程序来进行表示, 一般来说, 类的操作与传统结构化系统中的子程序有一定类似之处。如果操作逻辑及处理程序已使用结构化英文或虚拟程序代码清楚的描述, 则可以将操作描述映射为程序代码。另外在操作映射过程中, 需要特别注意的是传入和传出的参数。

3.2 对于交互图映射的具体分析, 一般情况下, 我们对交互图的概念

理解分为顺序图和合作图, 它有利于对许多对象在单一用例中的互动行为合作的分析, 有利于相关收发信息对象结构组织的建立健全。有利于实现合作图各个环节的有效协作。由于可使用如Rational Rose或System Architect 2001等CASE Tool直接将顺序图映射为合作图, 表示两种图形在语意映射上不会有流失的情形。所以在探讨交互图映射程序代码的议题上, 只要针对顺序图即可。

3.3 对于活动图映射系统分析, 日常建模中的活动图可以理解为系

统内部相关活动之间的传递流程。活动图里面包括一组活动以及活动与活动之间的顺序流程、分支流程以及发出动作和接受动作的对象。活动图可以用来表现系统的动态视图, 进行工作流程建模与操作建模。

3.4 在日常的状态图映射过程中, 此环节是数据库库管理系统中的

一种特殊程序, 它存在于关系型数据库管理系统内部, 它是一种程序利用逻辑与客户端应用程序的具体结合, 有利于实现数据库管理系统的相关环节的有效运行, 通过一系列具体指令, 实现计算机资源的有效优化, 有利于节约网络流量, 促进相关系统的执行效能。触发器是一种特殊的存储过程, 两者不同之处在于存储过程是被动的程序, 必须要有入调用它才会执行;触发器是主动的程序, 它由设计人员事先定义在某个数据表上, 当使用INSERT、UPDATE或DELETE指令柬修正数据时, 数据库管理系统会检查是否有符合某种条件的状况发生, 一旦该条件符合时, 会自动激活触发器, 执行一连串的SQL指令。

结束语

根据上文所说, 由于UML自身具备的局限性, 它不能解决数据库建模中的所有问题, 这需要对UML系统展开系统剖析, 以满足实际问题的需要。与ER模式不同的是, UML模式更加具备一定兼容性, 有利于实际工作的优化。

摘要：该文就UML数据库建模关键技术展开分析, 以找到其中存在的不足, 采取措施, 解决问题, 促进UML数据库建模系统的建立健全, 以满足现实生活的需要。

关键词：UML数据库,动态建模,静态建模,方案设计,具体措施

参考文献

[1]刘志成, 应时, 黄格飞.UML在关系数据库设计中的应用[J].计算机时代, 2006, 12.[1]刘志成, 应时, 黄格飞.UML在关系数据库设计中的应用[J].计算机时代, 2006, 12.

教学管理系统UML用例建模方法 第8篇

一、用例 (Use Case) 概念

用例 (Use Case) 的概念是Jacobson在1992年首先提出的。此后在Firesmith和Booch等几种软件开发方法中对于确切地描述用户需求中的功能需求;帮助发现系统中应设立哪些对象;核实每种功能需求是否有相应的对象予以满足等, 都起到了很好的促进作用, 因此受到人们的重视和好评。

二、系统需求分析

需求分析是系统开发中的一个重要步骤, 是整个系统开发的基础。需求分析的结果将直接影响到整个软件工程的成功与失败。如果需求定义错误 (如需求不完全、不合乎逻辑、不贴切或使人易于发生误解) , 那么不论以后的工作质量如何, 都必然导致系统开发的失败。大量实践证明, 信息系统产生的许多错误都是由于需求定义不准确或错误导致的。而且, 如果在需求定义阶段发生错误, 修改这些错误的代价是非常高的。因此, 信息系统开发中需求分析是系统成功的关键一步, 必须引起足够的重视。只有在正确的需求分析基础之上, 才能顺利完成系统的设计与实现工作。

三、用例 (Use Case) 建模

教学管理系统功能设计利用UML方法完成, 通过用例图描述了系统的主要功能及其使用的对象。

创建用例模型的工作包括:确定活动者和用例、描述用例、定义用例间的关系、最后确认模型。用例模型由用例图组成, 用例图展示了活动者、用例以及它们之间的关系。在创建用例模型时, 用户与开发者之间的积极合作和交流是十分重要的, 用户的参与使模型能够反映出用户所希望的细节, 并以用户的语言和术语来描述用例等。

USE CASE图可以按下列步骤建立:

1. 定义活动者。

活动者 (Actor) 是用户作用于系统的一个角色 (Role) 。活动者有自己的目标, 并且通过与系统的交互达到目标。

2. 定义USE CASE。

USE CASE本身是用户或其他系统与正在设计的系统的一个交互, 每一个USE CASE都是一个活动者与系统在交互中执行的有关事物序列。应当根据系统的需求找出全部的USE CASE, 并从活动者的角度给出事件流。当USE CASE执行时, 系统应提供给活动者服务。

3. 绘制USE CASE图。

USE CASE图是系统的外部行为视图。在确定了活动者和USE CASE的基础上绘制USE CASE图, 可以更清楚地了解系统的行为。绘制USE CASE图应先从顶层抽象开始, 然后逐步分解、精细化USE CASE图, 直到能清晰地表达问题、满足系统分析与建立模型的需要为止。基于前面的分析过程, 在此绘制了系统顶层用例图, 如图1所示。

四、结束语

UML建模 第9篇

关键词：UML；SystemC；建模；描述

中图分类号：TP311.1 文献标识码：A文章编号：1007-9599 (2011) 08-0000-02

The Method Using UML and SystemC for System-level Modeling of Embedded System

Chen Ke,Deng Fuyu

(Sichuan Vocational and Technical College,Suining629000,China)

Abstract:This paper designs an UML model of an embedded system fruitcleaner with UML modeling tool Rational Rose,then makes a system-level description targeting this system with executable SystemC language on the basis of UML model prototype.This paper also obtains the final description result of the fruitcleaner system,and emulation result by running.

Keywords:UML;SystemC;Modeling;Description

一、引言

SystemC语言是一种理想的软/硬件协同设计语言，其描述得到的模型具有可执行性。目前为了实现对UML所描述的嵌入式系统进行模拟验证，采用合适的方法将UML模型转换成相应的SystemC描述是比较有效的途径，也是当前嵌入式系统软硬件协同设计领域研究的热点。

二、果蔬清洗机的系统级UML模型设计

从整体上看，一个果蔬清洗机（fruitcleaner）的系统结构主要包含有一个洗涤桶（tub）、一个引擎（engine）和一个臭氧发生器（generator）。

（一）清洗周期的定义

对于果蔬清洗机而言，从关闭清洗机的门进行系统初始化开始到清洗完毕排空洗涤桶的水并打开清洗机的门为止，整个过程被定义为一个完整的清洗周期。因此，该系统一个清洗周期由六个阶段构成。实际上，在对该系统进行初始化动作（Start）阶段时，就由清洗模式cleaning mode指定Fill，Generate，Feed Clean和Discharge这五个阶段持续的时间。

（二）系统级UML模型图

该系统主要包含两个Use Case：清洗果蔬和设置清洗的模式。系统重点针对清洗果蔬

这个用例，分别画出其类图、顺序图、状态图和活动图。该系统包含有四个类：Tub、Engine、Generator和Fruitcleaner，每个类包含有相应的方法和属性。顺序图中有四个对应类的对象参与六个交互进程。图1显示的是fruitcleaner的类图。

图1.fruitcleaner的类图

三、用SystemC描述果蔬清洗机的系统级模型

UML是一种图形化的统一建模语言，用UML描述的嵌入式系统模型虽然有很强的可读性，但是却不可执行，即无法在系统级描述的基础上进行仿真，验证系统功能描述的准确性。在实际的嵌入式系统设计流程中，为了能对UML所描述的嵌入式系统进行功能模拟验证并得出有效结论，因此有必要再用SystemC进行嵌入式系统的系统级描述。鉴于在Rational Rose软件中设计的UML用例图、类图、顺序图、状态图和活动图都能很直观地反映系统的执行功能，因此利用UML图形描述来作为后续SystemC描述所需的模型书面文档是行之有效的途径。这部分采用合适的方法把UML图中的元素与SystemC中的相关模块和进程对应起来，对直观的图形描述进行抽象，得到能执行的程序代码。此外，在系统功能模拟验证完成后，系统的软硬件划分、软硬件综合等设计流程都将通过SystemC完成。这样就把UML和应用于整个后期设计的SystemC紧密地联系起来了，在当前的嵌入式系统软硬件协同设计领域有其独到的作用。

四、描述结果

以Generator对象为例，给出SystemC下的部分描述代码结果：

SC_MODULE（Generator）

{sc_infcGenetratorOn_in；

sc_infcGenetratorOff_in；

void on（）；

void off（）；

SC_CTOR（Generator）

{SC_METHOD（on）；

………………

………………

}

}；

void Generator：：on（）

{printf（“Switch on the generator.n”）；

printf（“Waiting……n”）；

}

void Generator：：off（）

{printf（“Switch off the generator.n”）；

}

五、模拟仿真运行结果

代码编写完成后，最后在SystemC 2.2平台环境下试运行，通过调试、修改，得出模拟验证的仿真结果如图2所示：

图2.SystemC 2.2平台仿真结果

通过以上运行结果可以看出，从系统准备就绪（ready），启动清洗周期（Start a cleaning cycle）开始，到最后清洗周期结束，描述方法对系统模型运行连续性的影响得到了较好的体现。其中，几个Waiting语句的时间延迟也成功地反映了系统运行阶段的时间约束特性，嵌入式系统的实时响应特性与预期效果保持了大体一致，说明以UML图形化模型为蓝本写出的SystemC代码具有简洁、高效的特点。总的来说，该模拟仿真结果基本达到了预期效果，说明了以上的工作取得了初步成效。

参考文献：

[1]吴迪.嵌入式系统原理,设计与应用[M].北京;机械工业出版社,2005:45-66

[2]高焕堂.UML嵌入式设计[M].北京:清华大学出版社,2008:124-140

[3]陈咏恩.SystemC,一种软/硬件协同设计语言[J].电路与系统学报,2001,1

[4]陈燕,杜玄,彭澄廉.基于SystemC描述的嵌入式系统的自动化验证[J].同济大学学报(自然科学版),2004,8

[作者简介]陈科，男，四川职业技术学院电子电气工程系，助教，硕士，研究方向：电气自动化技术；邓馥郁，女，四川职业技术学院电子电气工程系，助教，硕士，研究方向：电气自动化技术。

基于UML的面向对象建模方法研究 第10篇

传统的软件工程方法主要是以结构化方法为代表, 随着计算机应用的深入, 这种方法出现了许多问题, 具体表现在软件的重用程度低、稳定性差、难以维护等。针对这些弊端, 面向对象的软件工程方法随之产生。

面向对象 (Object Oriented) 的方法包含了面向对象的分析 (OOA) 、面向对象的设计 (OOD) 和面向对象的编成 (OOP) , 是一种新的思维方法。面向对象的方法与人类的思维习惯一致, 具有稳定性好、可复用性好、适应变化、易于维护等优点。

统一建模语言UML作为一种标准的图形化建模语言, 成为面向对象分析与设计的一种标准表示方法, 它的作用域不限于支持面向对象的分析与设计, 还支持从需求分析开始的软件开发全过程, 可以被各种可视建模工具支持。UML获得了广泛应用, 并代表了软件开发技术的发展方向。

1 建模方法

1.1 用例图

用例图是从用户的角度描述系统的功能, 并指出各个功能的操作者和执行者。基于UML的建模首先要进行需求分析, 需求是对产品的需要和要求的描述。需求分析阶段的活动包括概念初始化、写调查报告、计划和需求的详细描述等;常用的文档包括:计划、原始调查报告、需求说明、术语表、原型、用例、用例图、概念模型草图等。

用例描述了参与者执行一个任务时产生的事件序列。用例图说明了系统、参与者和用例的关系。用例用椭圆表示, 参与者用简化人形表示, 在用例和参与者之间用箭头、连线表示信息流。

针对一个典型的零件订单系统, 我们先分析该系统的需求, 建立概念模型, 画出用例图。图1是使用目前最广泛应用的UML工具Rational Rose建立的该零件订单系统的用例图。一个简单的订单系统用例图表示一个执行者 (会员) 和被操作系统之间产生的事件序列。订购零件就是该事件的用例, 图中的箭头表示时序。下面类图和顺序图的建立都是基于这个用例图而产生的, 我们将在后面的章节详细说明。

1.2 类图

面向对象分析设计的关键是提取对象。对象是对现实世界中事物的抽象, 它具有状态、行为和标识。状态是当前属性值的组合, 是行为的累积结果;行为是对象根据状态和接收消息作出的反应;标识是和其它对象的区分。

类是共享一个公用结构和公用行为对象的集合。我们通过类图来描述对象的状态和对象间的关系。类图中的关系主要有泛化、关联和聚合。

在零件订单系统中, 我们提取出几个基本的对象, 包括会员、订单和零件。订单类与会员类之间具有操作性, 用直线连接表示它们相关联关系, 两端的数字表示连接关系是一对多, 且会员可以操作多个订单。会员类有其共有的属性, 包括会员编号、用户名、密码、姓名、性别、电话、传真。会员类可以细化为普通会员和高级会员两个子类, 子类继承父类的所有属性, 并具有自身独特的属性, 这种关系就是泛化, 用带三角的箭头表示。订单类的属性包括下单日期、税金、运费、总价等, 另外订单类具有一些可对其执行的操作, 例如计算附加费用、合计总费用。订单类可以包括多个订单项, 这是包含的关系, 即订单项是订单的组成部分, 是整体和部分的关系, 它们的关系叫做聚合, 用菱形的箭头表示。箭头两端的数字表示它们的关系是一对一或是一对多, 一个订单可以有多个订单项, 所以在这里的聚合是一对多的。订单项的属性包括购买数量和单价, 对它的操作包括计算该项订单的价钱。订单项对零件是依赖关系, 这种关系体现在零件类是订单项类的一个成员变量, 零件类的信息变化, 比如零件的价格可以影响订单项类的信息变化。依赖关系用普通箭头表示。

图中几种类的关系的代码表示简单列举如下:

1) 泛化:

2) 依赖:

3) 聚合:

4) 关联:

1.3 顺序图、状态图

类图仅仅从静态角度描述了系统, 而面向对象系统是通过对象之间相互发送消息来实现系统功能的, 所以我们需要为系统建立动态模型才能全面反映系统的情况。

动态模型包括协作图和顺序图, 顺序图属于动态建模交互图的一种。它用来描述对象之间动态的交互关系, 着重体现对象间消息传递的时间顺序。它反映了各个对象之间的动态协作关系, 体现了对象动作的先后时间顺序。顺序图能更好地说明对象间的交互顺序, 有利于理解系统, 所以最好用顺序图来描述每个用例的实现。

图3详细地描述了会员完成零件检索的顺序, 首先根据查询条件检索零件, 系统查找到零件后将零件列表显示在界面上, 会员选择感兴趣的零件并提交可以提取该零件的信息, 系统就会回复该零件的详细信息给会员。可以看出整个检索的程序在顺序图中描述出来十分直观详细。

2 结束语

基于UML进行系统分析与设计, 便于在全局上纵览整个软件的结构;便于把握整个软件的总体结构与各个分系统结构之间的关系。本文通过工程企业管理系统的UML建模, 分析了系统的需求, 分别进行静态建模和动态建模, 给出了整个系统实现的蓝图, 使用UML建模的方法, 可以缩短开发时间, 提高软件开发的质量, 有着良好的应用前景。

参考文献

[1]刘超, 张莉.标准建模语言UML教程 (第2版) [M].北京:航空航天大学出版社, 2002.

[2]谢子松.武友新.基于UML的工作流建模的研究与应用[J].计算机系统应用, 2005 (2) .

[3]张红霞.基于UML和工作流技术的企业管理信息系统开发研究[D].天津大学硕士学位论文, 2003.