作者：何云
摘要：UML的目标是以面向对象图的方式来描述任何类型的系统，其中最常用的是建立软件系统的模型。本文运用UML，对软件开发过程中的概念模型进行了分析，研究了开发模型的整个过程以及其间涉及到的相关知识，对软件开发建模具有较大的指导意义。
关键词：UML 建模技术 概念模型
一.UML简介
UML是一种面向对象的建模语言，而不是一种面向对象的建模方法，它只是给出一套用于建模的元素及表示符号并定义了它们的语义，而不涉及如何进行系统建模，它本身没有提供过程的概念，这意味着用户在使用UML进行建模时，可以选用任何适合的方法和过程。过程的选用与模型/软件开发过程的不同因素有关，诸如所开发软件的种类(如实时系统、信息系统和桌面产品)和开发的目的等。用户将根据不同的需要选用不同的过程。然而，使用UML建模仍然有着大致统一的过程框架。该框架包含了UML建模过程中的共同要素，同时又为用户选用与其所开发的工程相适合的建模技术提供了很大的自由度。
鉴于此，Rational公司在Objectory过程框架的基础上，提出了统一过程（Unified Process）的概念，力争使其象UML成为标准的建模语言那样，成为进行信息系统开发的标准过程。使用UML进行建模的过程应包含以下三个基本特性：Use Case驱动、以体系结构为中心、迭代式的增量开发。
1.Use Case驱动
在UML中，Use Case捕获系统的功能需求，驱动软件的整个开发过程，确保分析中罗列的所有功能均被实现。由于Use Case中包含了系统中的所用功能描述，因此将影响到所有的开发阶段。
2.以体系结构为中心
使用UML进行建模的过程应该以体系结构为中心。这意味着应该在开发的早期尽量建立一个良好的系统体系结构，然后建立原型和进行评估，并在开发过程中不断的细化。体系结构把系统划分为几个部分，描述各部分间的关系、相互作用、通信机制以及添加和修改某一部分的原则。定义一个良好的体系结构对于实现一个易于修改、易于理解和可重用的系统至关重要。
3.迭代式的增量开发
使用UML建立模型时，不应试图一次定义出模型的所有细节，而应分成一系列较小的迭代过程，在每个迭代过程中逐步增加信息，逐步进行细化。一次迭代或一系列迭代可认为是对系统进行功能完善的过程，即完成系统的一次增量。迭代和增量式开发就是定义一系列的开发阶段。
UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常用的是建立软件系统的模型，当然它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。
二.概念模型的UML描述规范
从表达能力来看，UML无疑是很强的，它从参加联合的各种面向对象方法中吸取了许多扩充的概念和图性。但恰恰因为这一点，UML的复杂性也远远超出了以往各种面向对象方法，以至它所使用的建模元素达到一百多个，开发一个系统要画的图达9种之多。UML没有指明它要求建立的9种图有哪些是可以缺省的，以及在什么情况下，对哪类系统可以缺省。实际上UML的各种图对建模问题的表达能力有很大的冗余性。例如，协作图中表达的静态信息（关联、关联端点、可导航性等）都可以在静态结构图中表达，而它对消息的表示也没有提供比顺序图更多的信息。建模元素的繁多是UML的另一特点。尽管在UML的设计中考虑到“必须在表达能力和简单性之间作出折衷”，但是从实际结果来看似乎还是倾向于复杂。
由于以上原因，在使用UML对使命空间概念模型进行描述时，应当避免随意性、遵从一定的描述规范，即用什么UML建模元素表示概念模型的描述要素，对UML表示有哪些限制、约定，遵从什么表示习惯等，这样才有利于模型开发人员之间的交流，并促进概念模型的重用性。
1.描述概念模型所需的UML建模元素
在UML的五大类图中，在描述概念模型时只有实现图是不需要的，因为我们所描述的毕竟是概念模型，与具体实现无关。其他四大类图中也并不是全部用到，一般只用到下面几种图：
1) Use Case图
Use Case图主要用于顶层的功能性描述。Use Case图中主要用到Use Case、作用者和联系这三类UML建模元素，除此之外，依据实际情况还要用到类图中的一些UML建模元素。
2) 类图
类图主要用于表示实体等这一类实在的现实对象及其相互关系，具体而言，类图中一般要用到这些UML建模元素：类、联系、聚合、泛化、联系类、接口、依赖等。
3) 状态图
状态图中一般要用到这些UML建模元素：状态、状态转移、子转移、起始状态、终止状态、判断、同步等。
4) 活动图
活动图实际上是状态图的超集，活动图中除了要用到状态图中所使用的建模元素外，还要用到这些UML建模元素：活动和泳道。
5) 顺序图
为了全面地说明各实体间的信息交互的流程，即每个实体的整个生命期内以及各实体间的交互时序关系。可以通过顺序图，用对象间的消息交互，表示实体间的信息交互的流程。顺序图中一般要用到这些UML建模元素：对象、对象消息。
2.UML描述风格
2.1 EATI的UML描述风格
EATI（实体、动作、任务、交互等）用UML建模元素表示时，可用版式（stereotype）加以标识。
a.Use Case的表示
Use Case的命名方式：以简洁的文字说明Use Case所代表的功能。对Use Case的附加说明则放在Use Case规范的文档中。作用者对于Use Case的作用可用联系名具体说明。
b.实体和关系的表示
实体是可以用UML的类来表示的，实体的相关内容可以放在类的属性里表示；与此相应，实体间的关系则是用类间的联系来表示的，可以使用版式或命名来区分不同的关系。现实世界中实体间的组合关系可以方便的用UML中类之间的聚合（Aggregation）联系来表示。
c.动作、任务和交互的表示
任务是由UML的活动图中的活动元素来表示的，动作是由活动图中的动作来表示的。而任务间的交互则是用活动间的状态转移来表示的，交互中所传递的消息、事件等则放入转移规范中的事件里。
在活动图中任务间的时序关系是这样表示的：①若两个任务间有表示状态转移（state transition）的线，则表明该两任务是顺序关系。②放在两个同步符号中间的任务表示并发。③嵌套任务同样用放在两个同步符号间的任务表示，只不过在生命期短的任务的前后各加上一个空任务，从而表示生命周期的嵌套。如图1所示，表示任务A嵌套任务B。④嵌套任务同样用放在两个同步符号间的任务表示，只不过在开始时间晚的任务的前加上一个空任务，而在结束时间早的任务的后面加上一个空任务。⑤任务的重复是用自身转移表示的。如图1所示，表示任务A的重复执行。
图1 任务时序关系图
状态转移上的文字一般是指当某事件发生时，从一个任务转移到另一个任务，这也包含了一种时序关系。这些事件同样指出了任务的进入和退出的条件。至于任务中的条件及条件从句，在活动图中归结为事件和对事件的反应。
任务中的其他描述成分，如初始状态、输入（实体）、动作限制、输出（实体）、最终状态、任务描述等，均放在活动图的文档（document）中。对输入的响应，如对事件的响应；而发送输出实体相当于发送事件。在活动图中任务间的执行者（即动作的主语）是这样表示的：以泳道（swimlane）来表示执行动作的实体，放在某个泳道中的任务或步骤表示其动作的主语是该泳道表示的实体。
在活动图中一般都有起始状态和终止状态，在表示任务时，用这两个状态来充当类似“模块接口”的作用。具体来说，就是对某个具有若干输入和输出的任务进行分解时，分解后的活动图中的从初始状态引出的状态转移与上一级的输入相同，而引向终止状态的状态转移与上一级的输出相同。这样做的原因是模型的一致性所要求的。
d.顺序图的表示
顺序图的表示遵从一般的UML语法即可，只是对于对象消息的命名应当符合表达习惯。
2.2 体系结构产品的UML描述风格
并不是所有的体系结构产品都适宜于用UML进行描述，有些产品用表格式的方法来表示这些产品更直观和易于理解，尽管这些产品中的大多数实际上仍可以从相应的UML图中推导出。
三.开发概念模型的指南
两条主要的指南形成了开发概念模型的面向对象过程的基础。第一条是“自顶向下、广度优先”，第二条主要依赖于基于事件的交互作为描述和分析的技术。下面，我们对这两条指南进行一下阐述：
1.自顶向下、广度优先
第一条指南是体系结构的规范说明过程应当遵循自顶向下、广度优先方案。“自顶向下”意味着该过程开始时将软件系统看作一个黑箱，与外部的（范围外的）实体相连或相关。在最初的上下文中，系统被分解成一些主要的部件，然后那些部件被近一步分解，如此下去。分解过程通过每个附加的层次从几何上扩展，最终对任何项目可以实际处理的分解深度施加实际限制。“广度优先”意味着随着深度增加分解应当在整个体系结构范围内被统一执行——不应当在体系结构的某一特定范围进行特别深入的分解而造成“烟囱”似的结构。这条指南的理论基础在于统一的自顶向下、广度优先是保证正确的体系结构实现和系统需求、减少修复前期烟囱式设计所必不可少的返工、避免体系结构的一部分“驱动”其它部分不必要的需求、接口和行为所必需的。
2.基于事件的交互
第二条指南是我们强烈的依赖于对象间基于事件的交互作为定义机制。无论对象代表一个复杂系统或一个软件，其输入输出事件都是说明对象行为的关键信息。这些行为可通过形式化的状态图来捕捉，在此应当注意到系统仅对其输出有控制权，而其输入由系统环境决定不受系统的控制（即在视野范围内的系统外部）。
四.开发概念模型的面向对象过程
图2表示了整个开发概念模型的面向对象过程主要的迭代特性。迭代循环主要的输入和输出是系统的行为，其中“预期的”（as desired）行为作为输入、“建模的”（as modeled）行为作为输出。这两种情形下，系统行为都通过使用UML顺序图来表达。应注意其它一些技术和方法学是以别的名字称呼这一基本图形的，如事件跟踪图、消息顺序表等。迭代循环的要素如下：
①以顺序图的形式定义一些行为，这些就是“预期的”行为，这里涉及的是对象实例，而不是类；
②构造新的对象类（从前一步中的对象实例导出）及其相关的状态图，或修改现存的一些；
③为所有的Use Case产生行为（还是以顺序图的形式），这些就是“建模的”行为；
④比较“预期的”和“建模的”行为，如果两者匹配，则继续为新的行为建立模型或继续为对象分解的下一级建立模型，如果匹配不充分，对象类及其状态图则需要进行再工程，通常会出现下列两种情况之一：“建模的”行为规定得不够或需要重新设计。
图2 整体开发过程的迭代特性
下面，我们对完整的开发概念模型的面向对象过程按照实施的步骤进行说明：
1.对于最初的Use Case，第一步是将Use Case图翻译成高层的顺序图，它主要涉及在外部作用者和系统（视为单一实体）之间信息交换的顺序。初始的对象类图和状态图可以从此导出，这将产生“建模的”行为（嵌入在顺序图中）。这些最初的图代表第一次迭带。接下来的迭代从在顺序图和对象图中分解一个或多个对象开始，定义顺序图中更精确（详细）的行为并通过修改或附加的状态图来实现哪些行为。这样的迭代将进行下去，阐述额外层次的细节，直到Use Case的需求得到满足。当阐述后续的Use Case时，或许有必要将行为定义到附加的层次细节。必须认识到导出的类和状态图代表通过所有的Use Case和顺序图捕捉到的行为的结合。将附加的行为集成到现有状态图集合中的过程有时候会是一个挑战，还会是理解一个多任务系统需要如何装配的关键。
许多开发人员曾批评过UML的Use Case图根本不像面向对象风格的（除了外部作用者外，它看上去更像面向功能的而非面向对象的）。但是它的价值在于为后继的分析正确设定上下文并提供外部消息接口的方便视图。我们建议用基本的系统功能来标识此Use Case。（其他主要的系统使用或功能应当表示成单独的Use Case。）作用者和Use Case之间的单向箭头代表作用者和系统之间的基本交互。初始、顶层的Use Case阐述了外部作用者和作为一个单一实体“系统”间的关系。Use Case图的重要价值之一就是对图形附之以文字描述。
2.在给出了一个或多个Use Case后，下一步就是将这些Use Case转化为高层的顺序图。顺序图是UML中两种交互图之一（另一种是合作图）。这两种交互图可以互换，而没有信息损失。因此选用哪一个主要是风格问题而不是技术问题。
顺序图表示实体间事件或消息交换的事件顺序，在这个特定的步骤中，实体集合应当限定为对应于Use Case的外部作用者和一个代表整个“系统”的实体。第一个顺序图应当只含一个“系统”实例外加必需的外部作用者，以便集中注意力于系统与外部世界的顶层界面。通过按时间排序实体间的交互可以将顶层的Use Case图直接转换成顺序图。应当为每一个Use Case构造一个顶层顺序图，并且在这个图中用单独的实体表示整个系统。
3.接下来是从刚刚创建的顺序图中提取初始的系统视图的信息对象。顺序图中的事件代表可用于直接创建初始的（信息）对象类的事件和信息。这些将会放在对象类等级图中。在顺序图中若将事件视为刺激—响应对偶，那么通过在每个刺激和对应的响应之间加入联系就可以构造最初的联系集。应当注意，在很多情况下，对于第一个刺激的响应或许会成为第二个刺激，导致遵循对象类图的因果链（尽管在对象类图中，联系是无方向的）。随着其它顺序图被开发出来，类图将作相应修订和扩展。当类图完成、不需进一步改动时，就是完整的逻辑数据模型。
4.再次要对现已存在的顺序图进行处理，这是功能分解的推导源头。代表最初的Use Case的椭圆是以功能-类型名（动词/动作短语）来标识的。现在让我们回到顺序图看一下系统生命线。从系统收到第一个事件到产生第一个输出事件之间，系统必定执行了某种动作或功能。我们建议在系统生命线的输入和输出事件之间加入功能名。通过观察对象、刺激和响应，设想完成所希望的基于输入的输出的功能是相当直接的。通过沿着系统对象的生命线加入功能（注意，沿作用者的生命线定义功能并不重要，因为他们处于系统外部，不在关心范围之内），可以粗略的定义一起完成较高层功能（即Use Case的名字）的多个子任务，顶层功能已借助基于顺序图的技术分解过了。既然在顶层Use Case图中的活动（椭圆）以功能名来标识，从而用来扩充顺序图的功能实际上是Use Case活动的子功能。
从系统对象顺序图中构造的功能层次图可以推导出UML活动图。功能层次图在每一次对象分解迭代中会增加额外的叶结点，因此只有对象分解过程中止时它才能称得上“完整”。需要着重指出的一点是功能层次图是从顺序图中导出的，而不是单单检查系统本身。
5.将已分解出来的“系统”的部件对象代替顶层顺序图中的系统对象。原来已存在的作用者与系统之间传递的事件，现在这些事件将从作用者传递到某个或某些个系统的部件对象。在这些部件对象之间也要添加新的事件（这些事件在顶层的顺序图中是不可见的，因为他们完全是内部事件）。当修改现存的事件并加入新事件时，又会观察到因果关系。在新对象生命线上再加上功能名，从而得到一个新的扩充顺序图。通过比较新旧扩充顺序图，可以看出上一层的功能已被下一层中的功能分解所代替。在此，当对象分解过程如果已经达到了足够详细的程度，就可以开始为对象类构造状态图了。否则，还需要进一步分解。
6.对于所有在一个或多个顺序图有实例的系统对象类，都需要开发其状态图。对于一个给定的类开发其状态图的过程开始于扩充状态图。从顺序图中将该类的对象生命线和与之相连的输入输出事件抽取出来，这是开发该类的状态图的起点。抽取出来的生命线有许多输入和输出事件与之相连，将这一系列事件转换成状态图的一般规则如下：
输入事件是与导出某个状态的转移相关的，输入事件应当是导致转移点火的触发事件。因此在生命线上可通过在触发事件之前加入对象的状态来进一步标识。这种技术UML并不支持，但在其他一些方法和工具中已被实现。
输出事件是由对象采取的某些动作产生的（即方法、操作、函数等）。如状态图规则所约定那样，动作可以与一个转移、或状态的进入和退出相联系（经由某个转移）。入口和出口代码，就像他们的名字所显示的那样，在某些复杂行为情况下很有用，但在本文中并未阐述这一点。不失一般性，这里的讨论仅限于一有限子集：动作假定仅与转移相关。即使在软件开发中，在这种限制下，也能够实现系统而只是会产生一些冗余代码。
7.应当检查生命线的循环模式。并不是所有的对象都有循环模式。通常一些数据类型对象（信息对象）生存期是短暂的，其活动状态图不是循环的。另一方面，许多对象预期执行多次同一任务，他们的状态图将是循环式的。可以构造系统对象图的另一版本以达到使用UML联系构造来指示物理接口的意图。这里用到的另一个有用的UML构造是“连接属性”（称为“联系类”），这种构造用于表明系统对象之间的联系是实际的（接口）类。
8.在给出类结构以及完整的顺序图后，就得到了将事件和消息与系统接口相关联的全部信息。通过在表示物理接口的联系类中加入由该物理接口传输的消息、事件等的文字说明，就得到了消息-接口映射图或消息-接口图。为了支持包含通信带宽需求或用户界面/人为因素等问题的系统分析，这种相关性是至关重要的。
五. 一个可行技术的探讨
构造体系结构的主要动机之一是处理演化系统自有的问题。在这里，我们将阐述使用UML图来处理划分时间阶段系统的一个可行技术。本技术基于对类图的使用和子类（特化/泛化）的正确构造，还依赖于对象类是否是可实例化的。在定义上，高层类（父类或超类）比其子类更具抽象性，定义了其子类的共同特征。这样的话，我们不能实例化高层的抽象类。应注意在有些情况下父类是可实例化的。这些类，不管父类还是子类，都可以进行实例化。另一方面，对于“人”这样的类（有子类“女人”和“男人”）是不能实例化的——只有它的子类可以有自己的实例，因为任何人必须要么是男人要么是女人（子类是互斥的并构成了完整的“人”集）。
使用可实例化子类的策略是标识/创建一个子类集合（或在不同父类下的几个可能的集合）使得对应于系统的每一阶段都有一个子类集。我们可以创建类族，对于每一个系统阶段每一个类族都有一个单独的父类和子类。当以下的条件一个或多个满足时，决定了一个对象类需要重新改进为特定阶段子类：
①接口被从对象（类）中加入/删除；
②消息被从对象（类）接口中加入/删除；
③对象对给定刺激的反应发生变化；
④对象类属性的取值范围发生变化。
六.过程概述
在进行实际的想定描述之前，先要进行需求分析，目的是在用户和系统开发者间达成共识。概念模型的用户主要是软件开发人员和建模仿真人员，为此在这一阶段作为概念模型的开发者应当通过与用户的交流，清楚的了解用户期望的概念模型是什么样子的，表述习惯是怎样的，应当详细到何种程度。例如对如建模仿真人员来说，他们更注重任务等对于事件的响应，而软件开发人员在制定作业想定时，往往采用时间序列，因此在建立概念模型时应当弱化时间序列、强化事件序列。又如软件开发人员对使命空间的描述往往具有概括性、确定性的特点，即对软件细节、开发的变化情况缺乏详细的阐述；而仿真建模人员要建立起仿真模型的话，必须得到非常详细信息，包括许多软件开发人员认为理所当然的叙述，为了进行仿真建模必须提供更低级的细节。所以概念模型应当尽可能的从软件领域将这些细节“挖掘”出来，建立起现实世界到仿真建模领域的一座桥梁。这实际上是一个知识获取的过程。
1.定义和分析Use Case
在充分了解特定使命空间并和领域知识专家充分交流的基础上，使用Use Case技术进行想定的功能定义，附带定义Use Case的Use Case实例、性能度量等。这一阶段不一定要将所有的Use Case都列出来，只要列出比较重要的即可，其它的留待以后完善。
Use Case最初起源于软件工程领域，在软件开发中的Use Case图中，明显的分为两部分：作用者和Use Case。相对于作用者（大多数情况下系统的用户）而言，Use Case近似于“黑箱”，作用者只关心Use Case的外在表现，也就是它可以提供什么功能。然而在建立软件领域的使命空间概念模型时，模型的用户主要是软件开发人员和仿真建模人员，尤其是仿真建模人员它们更关心模型的内部细节，这时Use Case近似于“白箱”。既然是“白箱”，软件开发人员和仿真建模人员都可以深入其中，获取自己想要的信息。所以“白箱”里边的描述应当符合一定的软件规则、习惯、术语等，同时也应当遵从UML的语义，不至于给仿真开发人员造成误解。
在建立使命空间的概念模型时，Use Case模型的获取同软件开发过程中Use Case模型的获取有很大不同。在软件开发过程中，开发人员所建立的Use Case图、静态图、行为图和交互图等，并不提交给软件系统的用户，而这些图模型的用户恰恰是开发人员自己。开发人员最后提交给用户的是最终的软件系统。然而在使命空间中，概念模型的用户是软件开发人员和仿真人员，概念模型的开发人员提交给用户的却正是这些图模型（概念模型）。软件开发人员和仿真人员虽对概念模型表示的习惯、风格等有影响，但对于概念模型的内容并无直接作用，即他们影响概念模型的“形式”甚于“内容”。概念模型中的Use Case的作用者不再是系统外的用户等，而是系统内对它实施作用者。因此，在建立使命空间的概念模型时，Use Case模型的获取不同于软件开发过程中Use Case模型的获取。
我们知道，Use Case是对一个实体（响应实体）由于另一个实体的激励（激励实体）导致的行为的描述。基于此，我们认为在使命空间中，获取Use Case模型应当按如下步骤：
第一步，找出使命空间的激励实体和响应实体；
第二步，根据激励实体和响应实体找出对应的Use Case。
以上两步，往往不是一次性的完成，而是随着工作的深入，不断执行上述两步，完善系统的Use Case模型。
有时候需要对Use Case进行分解，将较高一级Use Case分解为低一级的Use Case，可以遵循如下原则：
①将某个Use Case的响应实体作为激励实体，找出该激励实体的下一级响应实体，进而导出下一级Use Case。
②如果某个Use Case所描述的功能可以分成相对独立的几块，则可据此分解Use Case。
但Use Case毕竟是用来表示高层的软件开发活动，故不应分得过细，应当适可而止。至于分解到何种程度合适，应当具体问题具体分析，不宜给出统一标准。
除了Use Case外，Use Case实例及其性能度量、条件、实体等都是用UML中的类图来表示的，他们的相关内容可以放在类图里的属性来表示。现实世界中实体间的组合关系可以方便的用UML中类之间的聚合（Aggregation）联系来表示。
2.任务分解与交互
一个任务可以分解为子任务或任务步骤。任务步骤是任务的原子成分。它不能进一步得分结尾子任务或任务步骤。一个任务步骤必须和对应任务必须共享同一Use Case。
进行任务分解应遵循某种原则。既然动作是任务表示的模板，任务的分解可以归结为动作的分解。动作的分解就是对谓语动词（Verb）、主语（Subject）和直接宾语（Direct object）的分解。所谓步骤，可以认为它是由“最小”的主语、谓语动词和直接宾语组成的。既然步骤是“最小”的，当然是不可分解的。对任务进行分解，一直分解到步骤而止。
任务间不是互不相关的，而是相互影响和相互制约的。使命空间的本质就是为了达成某种目的的若干任务的互相影响的执行，所以只有将任务间的交互描述清楚，才可以完整的建立其概念模型。
3.实体与关系
在第二步任务分解和交互的基础上，会得到许多实体，主要视任务的执行者、交互事件消息等。这一节主要是找出使命空间中的相关实体，并定义实体的能力、技术指标等，以及实体间的静态联系（包括关系联系、聚合联系、依赖联系等）。列出的所有实体都不是一成不变的，在整个开发过程中，由于经验的不断积累，可能会增删一些类的属性和操作，或者增加一些新实体，删除一些不再使用的实体。
4.顺序图的描述
为了全面地说明各实体间的信息交互的流程，即每个实体的整个生命期内以及各实体间的交互时序关系。可以通过顺序图，用对象间的消息交互，表示实体间的信息交互的流程。在描述完任务间的交互之后，顺序图可以自然推导而出，它可以给出使命空间信息流的全局概貌。
5.过程总结
该过程是以EATI为基础的，我们所做的只不过是用UML语言将EATI表现出来而已。EATI是表示的内容，本身没有过程的概念，而UML则是表示的形式。
[下一页]
摘要：在软件开发过程中，概念模型的正确性是软件产品质量的基本保障。为保证概念模型的正确性，需要对概念模型进行验证。本文从概念模型的开发过程出发，首先介绍了概念模型的一致性检查，而后重点讨论了概念模型的可执行验证，最后介绍了一种基于Petri网描述模型的方法。
关键词：概念模型 UML 模型验证
引论
在软件开发过程中，概念模型的正确性是软件产品质量的基本保障，唯有正确的概念模型才能真实的反映客观世界、才能实现可信度高的仿真。概念模型的正确性有三方面的含义：语法的、语义的和语用的。为保证概念模型的正确性，需要对概念模型进行验证。
从概念模型的开发可知模型是由静态与动态两部分组成的。静态部分的内容比较容易理解和检查，而动态部分的内容则由于其复杂性难于通过阅读式地审查发现其中的瑕疵。而利用可执行模型在人机交互条件下验证概念模型的动态部分是值得探讨的。通过高效的工具方便地描述概念模型中的动态行为信息，并快速、直观地建立可执行、可验证的模型是当前建模技术和工程的一大趋势。
下面，我们首先介绍了概念模型的一致性检查，而后重点讨论了概念模型的可执行验证，最后介绍了一种基于Petri网描述模型的方法。
一.概念模型的一致性检查
1.概念模型一致性概要
为任何系统建立概念模型都有同样的目标，即完整、准确、一致地刻画系统的主要方面。我们在《UML在概念模型中的运用分析》一文中已经介绍了UML的功能模型（Use Case图）、结构模型（类图）、行为模型（状态图、活动图、顺序图），从不同的角度完整地刻画了软件开发系统的全貌。但是这些模型不是孤立的，而是相互依赖、相互约束的，在大型复杂系统中尤其如此。只有分析清楚各个模型间的约束和协作关系，才能对系统有准确、一致的描述。
模型一致性检查是在语法正确的基础上实施的，它与语法正确性检查机制和模型完备性检查机制共同为模型的正确性提供保证，为概念模型的模拟和可执行验证奠定基础。UML支持用户从不同角度来描述系统，因此，描述系统的各个模型间存在着约束和协作关系，模型中必定存在一致性问题。况且，在大型系统的开发过程中，各个模型间的协作和约束关系错综复杂，单靠建模者自行保证模型间的一致性，不仅非常烦琐而且很难避免有所遗漏。所以，必须为UML可视化建模系统提供模型一致性检查，以防止对同一系统从不同角度描述的模型间存在相互冲突的信息。模型一致性存在于模型内部和模型之间两个方面。模型内部的一致性是指模型各个组成部分之间的一致性。例如在行为模型中，顺序图、合作图、状态图和活动图之间存在某种约束关系，这些约束关系即行为模型内部的关系。在模型之间，一致性约束关系更为明显，功能模型与结构模型之间、结构模型与行为模型之间以及结构模型、行为模型与实现模型之间都存在很强的约束关系。
本文定义的一致性是指在使用系统模型（包括功能模型、结构模型和行为模型）从不同的角度来描述系统的不同方面，即系统的各个视图（包括功能视图、结构视图、行为视图）时，由于侧重点各不相同，必然存在重叠，必须保证由不同的模型组合在一起所得到的系统模型中不存在冲突。因此，分为以下5方面的一致性：
a.结构一致性：行为模型在描述系统行为的同时也明确地或隐含地体现了系统的结构，行为必须建立在一定的系统结构之上。因此，结构一致性既包括结构模型内部结构上的一致，还包括了行为模型与结构模型结构的一致；
b.功能一致性：将需求模型描述的功能分配给结构模型中的类和类之间的关系，并且通过定义“合作”来实现功能的职责分配。因此，在功能模型、结构模型和行为模型之间存在功能一致的约束关系；
c.接口一致性：一般对于大型复杂系统，用UML对其进行描述，通常采用分层、分块结构。因此在各层和各个模块间必须保证信息流、事件流等的一致性，即接口一致性；
d.标识一致性：标识是联系各个模型的桥梁，是识别模型间关系的纽带。因此，在建模过程中应遵循对不同含义的模型元素采取相互可以区别的标识这一原则来标识每个模型元素；
e.行为一致性：行为模型在结构模型的基础上描述系统的行为，因此它依赖于结构模型中有关行为的定义。此外，行为模型的各个组成部分之间对同一行为的描述也要保持一致。
2.概念模型的一致性检查机制
一致性检查机制实现的关键在于：如何将一致性检查机制有机地加入到UML可视化建模系统中。所以首先要分析：
a.建模者在建立系统模型的过程中，实施何种编辑操作可能产生模型的哪些不一致；
b.建模系统如何避免不一致的出现；
c.建模系统采取什么措施可以有助于消除已出现的不一致。
最后根据分析结果相应地制定一致性检查的实现策略，给出实现方案并对每一条检查规则进行具体实现。由于在建模过程中随时都有可能出现不一致。无法完全由建模者自己去维护模型的一致。建模系统应该对模型具备以下能力：
a.检测能力： 检测可能导致模型不一致的编辑操作和当前已经存在的模型不一致；
b.一定程度的自动修正能力： 当检测到导致模型不一致的编辑操作后，搜索它所波及到的所有地方，依据编辑结果相应地进行一致性修正。例如，当检测到类中的操作被修改时，开始搜索所有引用该操作的地方，一旦找到立即相应地修改对该操作的引用；
c.对错误进行定位并提供指导性修正建议的能力： 对于有些导致模型不一致的编辑操作，通过自动修正后仍不能满足一致性要求，此时需要建模者进一步进行手动修正。
建模系统除了应具备上述3种能力外，还应提供基本的一致性保证机制。当建模者进行图形元素的规格说明编辑时系统提供正确、一致的信息以供选择，从而避免了编辑的随意性，在一定程度上保障了模型的一致。
通过上面的分析，可为一致性检查机制制定以下的实现策略：
a.强制约束：对用户实施的编辑操作在某种程度上进行限制，使建模者只能在系统规定的范围内有选择的进行编辑，从而避免了不一致编辑操作的出现。
b.自动维护：当用户实施了可能引起模型不一致的编辑操作后，系统自动修正，从而维护了模型的一致性。
c.动态检查：实时地捕获引起模型不一致的编辑操作，给出错误原因和修改建议。
值得一提的是，动态检查与自动维护都实时地对引起不一致的编辑操作进行检测，但两者之间是有区别的。动态检查对检测到的不一致编辑操作无法进行自动维护，只能通知建模者进行手工修改，而自动维护可对不一致的地方进行自动修改，但有时自动维护并不能完全消除模型的不一致，此时，需要静态检查进行进一步的检测。
d.静态检查：系统对模型中有些不一致无法进行实时检测，也无法对引起不一致的编辑操作进行限制，只能在建模过程中静态地进行检测。系统为检测这类错误提供了一个功能选单，由建模者在他认为合适的时刻进行一致性检查。只有当建模者选择该选单时，系统才对模型进行检查，对错误进行精确定位并给出修改建议。例如，结构一致性要求链接一端的实例数目与它所属的关联一端的多重性标记相符，即必须在多重性标记规定的数值范围内。对这一规则的检查只能在建模过程中的某一时刻进行，判定在该时刻是否满足规则的要求。
二.概念模型的可执行验证
我们知道，完成了一次概念模型开发迭代之后，验证已完成的工作是有益甚至至关重要的。许多概念（体系结构）模型拥有大量的对象类，而且底层的类（叶结点）还有自己的状态图。如果没有某种形式的计算机辅助过程支持，评价如此大的一个模型的正确性将是非常费力的。幸运的是，因为OO技术主要用于软件工程领域，有许多工具能够从一个完整的模型直接构造一个可执行模型（用计算机术语来说就是可执行文件）。对于任何复杂的模型，自动化执行对于保证模型不同部分的一致性具有重要价值。
应当指出，可执行模型并不是概念模型所必需的一部分，也不是软件开发体系结构框架文档所需要的。但是我们确信无论使用结构化分析还是面向对象技术都应当从概念模型来构造可执行模型，当然最好是采用自动化的方式。若没有模型可执行版本的构造和执行，要可靠的验证整个模型的完整性和内部的一致性是非常困难的。
CASE工具通常包括一组用于检查各种图的语法正确性的一致性规则——一个称作一致性的属性。但是这些规则的应用范围通常有实际限制，也就是将想要的行为序列嵌入到静态规则中不太切合实际。另外，当存在数以百计的对象类，每个类都有自己的状态图、活动图，某些类还有多个实例时，借助静态规则或手工方式，通过状态图、活动图等跟踪行为的任务很快就变得难以承受。并且，假设许多对象实例状态图有着复杂的交互，要想只借助单纯的静态规则检查来检测竞争和/或死锁条件是非常困难甚至是不可能的。
模型的可执行版本以严格的、精确的和自动的方式演示对象交互及其状态图来解决这个问题。如同语法规则可以捕捉语义错误，可执行模型将捕捉设计错误——涉及全部个体对象类的总体行为式的错误。某些对象集合的总体行为在语法上尽管是正确的，但却没有正确反映原有组织的需要与目的。
总而言之，为了决定概念模型是否反映了合适的和预期的行为，构造模型的可执行版本是合适的。
三.一种描述模型的方法
可执行验证是一种人机交互的验证，概念模型按照过程逻辑进行“执行”，其结果正确性依赖与领域专家的判断。概念执行要解决相关领域专家的理解问题，即不能直接将概念模型的“执行”过程直接展现给软件开发人员，而应提供更加直观的、为他们所熟悉的概念与形式来表现概念模型的“执行”。由于Petri网本身的可视化特点与可执行能力以及我们在这方面的理论与技术积累，这里我们可以选择Petri网作为描述执行模型的语言和工具，
在许多文献中，都提到用Petri网构造可执行模型。Petri网是描述和分析离散事件动态系统的一种模型工具。它综合了数据流、控制流和状态转移，能很自然地描述并发、同步、资源争用等特性，而且本身自含执行控制机制，集规范表示与执行于同一模型。如果在Petri网的执行过程中增加数据跟踪与收集等活动，则可实现实际系统的仿真。另外，Petri网以图形的形式描述系统，简单直观。Petri网在逻辑上将系统抽象为“情况─处置”、“信息─处理”、“队列─服务”等等类似的关系构成的网络。在数学上Petri网可用有向的二部图表示，有严格的数学理论支持。
但是，基本Petri网存在着的一个主要弱点是规模难以控制。如果系统比较复杂，其Petri网模型的规模将变得很大。特别是当系统的可达状态增加时，模型的复杂性将呈指数增长，使Petri网模型的分析和理解变得十分困难。另外，Petri网中的位置、转移和Token所携带的系统信息量不够丰富，缺乏语义描述功能，且Petri网不涉及时间因素，仅能反映出事件间的因果关系。
参考文献：
[1].邵维忠，梅宏. 统一建模语言UML评述. 计算机研究与发展，1999
[2].王云等. UML可视化建模系统的模型一致性检查机制. 计算机研究与发展，2000
[3].邵维忠，杨芙清. 面向对象的系统分析. 北京：清华大学出版社，1998
[4].周之英. 现代软件工程. 北京：科学出版社，2000
[5].黄健等．任务空间概念模型研究．系统仿真学报，2000
