UML逻辑建模过程分析

UML逻辑建模过程分析

董帅

辽宁工程技术大学工商管理学院，辽宁葫芦岛 (125105)

E-mail：ziyun-1986@

摘要：本文介绍面向对象的系统开发过程中逻辑的建模的过程，对逻辑建模的每个步骤进行分析，指出所涉及UML的图例，并指出他们之间的关系。

关键词：UML，逻辑建模，结构建模机制，行为建模机制

1. 引言

面向对象软件开发方法已经成为现代软件工程的重要手段。这种机制将传统的以数据为中心的软件开发方法，改变为同时关注数据的信息与功能，从而可以开发出适应信息与功能变化的系统。UML语言是目前应用最为广泛的面向对象软件建模语言，其完整丰富的图形和符号为表达面向对象系统模型提供了有力的支持。但是UML作为一种描述工具，而不是作为一种开发方法，应用UML快速设计和表达系统模型，必须有有效的设计方法支持。

UML面向对象的开发理念用UML来表示，其逻辑建模过程大致可分为三个阶段：用来描述需求用例建模、描述需求所建立的系统的静态建模、描述系统行为的动态建模。它从不同的视角为系统的架构建模，形成不同的系统视图，一类为静态图，包括用例图、类图、对象图、组件图、配置图。另一类为动态图，包括状态图、顺序图、活动图、协作图。[1][2]

2. 逻辑建模过程

按照传统的逻辑建模过程分为三步：第一步描述需求，用UML 就是使用用例图来描述人们所要就系统的如何使用第二步描述需求所建立的系统的静态建模，第三步是描述系统行为的动态建模。下面针对这三步作具体介绍。

2.1 需求建模

作为逻辑建模的第一步，需求建模是建立好系统的基础，他将决定系统设计和实现。所以对需求的描述一定要清楚、细致、准确。他是对系统进行需求调研，分析系统的业务流程图和数据流程图，以及系统中涉及的各级操作人员，识别出系统中的所有用例和角色；接着分析系统中各角色和用例间的联系。

需求建模是指人们对于系统功能的要求的初步描述，而非具体的细节的详细描述，是从整体的功能方面考虑。主要把系统所涉及的用户、系统实现的功能等方面的表述，属于统一建模语言UML的结构建模机制。[5]

在这个阶段需要用UML建模工具画出系统的用例图。

用例图是描述人们描述他们期望一个系统将被怎样使用。用例图显示的是有关系的用户，用户期望系统提供的功能，以及用户自己需要为系统作出的贡献，以便使系统的用户更容易地理解这些元素的用处，也便于软件开发人员最终实现这些元素。

用例图表示如图1

2.2 系统静态建模

根据需求分析结果，识别用例，标识完成事件流的类，标识类的责任、属性和关联，发现类的实例对象，建立对象图。为了利于理解和增加模型的可重用性，大型复杂系统则需要构建管理较小组织单元的包图，如子系统模型的设计。建立系统的初始静态结构模型，在系统迭代开发中再对初始静态模型进行细化，构造完整的系统静态结构模型描述了系统中类的静态结构、定义系统中的类、表示类之间的联系，同时也可以包括类的内部结构。[3] 在此步骤当中需要用到类图和对象图。

类图（class diagram）用来表示系统中的类和类与类之间的关系，它是对系统静态结构的描述。类用来表示系统中需要处理的事物。类与类之间有多种连接方式（关系）。比如：关联（彼此间的连接）、依赖（一个类使用另一个类）、特殊化（一个类是另一个类的特殊化）或打包（packaged ）（多个类聚合成一个基本元素），类与类之间的这些关系都体现在类图的内部结构之中，通过类的属性（attribute ）和操作（operation ）这些术语反映出来。在系统的生命周期中，类图所描述的静态结构在任何情况下都是有效的。

对象图是类图的变体。两者之间的差别在于对象图表示的是类的对象实例，而不是真实的类。对象图是类图的一个范例（example ），它及时具体地反映了系统执行到某处时系统的工作状况。

对象图没有类图重要，对象图通常用来示例一个复杂的类图，通过对象图反映真正的实例是什么，它们之间可能具有什么样的关系，帮助对类图的理解。对象图也可以用在协作图中，作为其一个组成部分，用来反映一组对象之间的动态协作关系。

2.3 系统动态建模

动态建模阶段是实现用例，识别参加交互的对象，描绘系统的动态行为，反映系统对象之间的动态关系，构建系统的动态模型。采用逐步递增的方法，分析用例的场景描述，并从用例与活动者的边界、用例的控制逻辑和用例与活动者的边界等3个方面寻找对象。通常，使用一个顺序图描述用例的主要事件流，用其它的顺序图描述独立的分支事件流。同时用状态图描述状态的转换。[6][7]

在此阶段使用的图主要有状态图、时序图、协作图、活动图。

状态图是对类所描述事物的补充说明，它显示了类的所有对象可能具有的状态以及引起状态变化的事件。事件可以是给它发送消息的另一个对象或者某个任务执行完毕（比如：指定时间到）。状态的变化称作转移（transition），一个转移可以有一个与之相连的动作（action ），这个动作指明了状态转移时应该做些什么。[4]

时序图用来反映若干个对象之间的动态协作关系，也就是随着时间的流逝对象之间是如

何交互的。时序图主要反映对象之间已发送消息的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一具体位置将会有什么事件发生。[4]

时序图由若干个对象组成，每个对象用一个垂直的虚线表示（线上方是对象名）每个对象的正下方有一个矩形条，它与垂直的虚线相叠，矩形条表示该对象随时间流逝的过程（从上至下），对象之间传递的消息用消息箭头表示，它们位于表示对象的垂直线条之间。时间说明和其他的注释作为脚本放在图的边缘。

协作图和时序图的作用一样，反映的也是动态协作。除了显示消息变化（称为交互）外，协作图还显示了对象和它们之间的关系（称为上下文有关）。由于协作图或序列图都反映对象之间的交互，所以建模者可以任意选择一种反映对象间的协作，如果需要强调时间和序列最好选择序列图，如果需要强调上下文相关最好选择协作图。

活动图(activity diagram) 反映一个连续的活动流,如图所示,相对于描述活动流(比如用例或交互)来说,活动图更常用于描述某个操作执行时的活动状况.

活动图由各种动作状态(action state )构成,每个动作状态包含可执行动作的规范说明.当某个动作执行完毕,该动作的状态就会随着改变,这样动作状态的控制就从一个状态流向另一个与之相连的状态.

活动图中还可以显示决策、条件、动作状态的并行执行、消息（被动作发送或接收）的规范说明等内容。

要根据类图和对象图抽象出实体的活动，然后根据实体的活动画出活动图，在对活动图采用自顶向下的分析，画出相应的状态图。活动的发生关系是又时序性的，根据此性质画出时序图。不同的活动之间可能存在相互协作的关系，这种关系的描述就是用协作图来表示。

[4]

3. 实例分析

下面以咖啡机系统设计为例进行分析。假设经过需求分析得到系统的相关概念:如果顾客塞入需要的钱币金额，咖啡机提供给顾客一杯咖啡或一杯热水(泡茶)。咖啡机可以处理币值为5或10的硬币。一杯茶的价格是5元，而一杯咖啡的价格是10元。可能的情况如下:如果塞入了一枚币值为10的硬币，然后按了咖啡的按钮，则顾客会得到一杯咖啡，而如果按了茶的按钮，则顾客会得到一杯热水，外加找零。如果塞入了一枚币值为5的硬币，然后按了咖啡的按钮，则钱被退回来，如果按了茶的按钮，则顾客会得到一杯热水。本例旨在说明系统逻辑建模过程。主要涉及用例图、类图、时序图。

第一步建立系统的用例模型。此步用途是列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。根据咖啡机行为关系，得到咖啡机的顶层用例模型，如图2所示。如系统较复杂，则采用分层设计，也可归并为用例包图。

第二步根据需求分析的用例图，进行系统功能设计，系统静态模型的建模。将每个用例分别作为实体，抽象出实现系统所需要的类，以及与用户的接口，得到类图和对象图。如果系统较为复杂，采用自顶向下的方式分析设计，可以采用包图分类封装，达到结构清晰，易于实现的目的。如图3所示类和接口的设计。

第三步根据用例模型和静态模型进行系统的动态模型的建模，即建立系统的交互模型。针对每个用例图，创建用例实现，建立其相应的交互模型。从用例模型中，概括出事件的活动，建立活动图。对照活动图画出其状态图、活动图和时序图。状态图和活动图是紧密相关的。状态图是以状态为中心，活动图是以活动为中心。时序图反映事件发生的先后关系，如