UML活动图

UML活动图（共9篇）

UML活动图 篇1

具有时间约束的嵌入式系统称作嵌入式实时系统(Embedded Real-Time Systems)[1]。嵌入式实时系统最大的特点就是需要实时性,这就要求实时软件对外部事件作出反应的时间必须要短,并且在某些情况下还需要是确定且可重复实现的,无论当时系统内部状态如何,都是可预测的。另外,随着嵌入式实时系统的复杂性的增长,开发嵌入式实时系统变成了一个系统庞大的工程。UML(Unified Modeling Language)[2]是一种软件建模语言,它强调建模的灵活性和实用性,支持对系统静态和动态的多个侧面进行建模。但是它在实时系统建模过程中存在一定的局限,缺乏对系统非功能属性如时间、资源等方面的描述。因此,文中结合UML和MARTE(Modeling and Analysis of Real-Time and Embedded systems)[3]优点,利用MARTE对UML活动图进行补充,使UML活动图具有时间约束的特性。因为MARTE可以定量的以时间为约束对系统的软件和硬件特性进行规约。

文中提出将UML的活动图用MARTE进行时间消耗的标注,然后将UML活动图映射到时间Petri网模型,模型建立后,便可以计算系统执行所消耗时间最大和最小的路径,从而确定整个系统执行的时间消耗。这样做的好处在于:在系统设计阶段,能够根据设计需求计算出系统执行所消耗的时间,从而提高系统开发效率,因为当系统开发完成之后在来修复错误比开发中修复多耗费10～100倍的时间和精力。

1 UML活动图和时间Petri网

1.1 UML活动图和MARTE

UML包括3大类9种基本的图形,采用活动图为研究对象是因为活动图能够更好地描述实时系统的动态行为。

MARTE作为UML的profile,是对嵌入式实时系统的建模与分析规范,它弥补了UML在非功能属性上建模的不足。MARTE中的概念主要分为基础、建模和分析3个部分,其中基础模型包括实时和嵌入式系统中的一些基本概念,如时间、资源等和一系列核心元素,它是MARTE规范的核心。设计模型提供较高抽象层的建模元素,用于对并发和实时的活动主体和行为建模,如响应并发和实时调用的服务和动作等。分析模型封装了对系统性能质量以及调度的建模元素,主要针对非功能属性的具体建模,如时间、能耗等。文中使用MARTE的元素来表示带有时间约束的UML活动图。

图1 显示了用MARTE标示带有时间约束的UML活动图,该图表示活动A的执行时延为10 s,也就是执行活动A需要耗费10 s钟的时间。

1.2 时间Petri网

一个时间 Petri网[4]是一个七元组 TPN=(P,T,B,F,α,β,M0),其中:① P={ p1,p2,…,pn }是有限、非空的置集;T={ t1,t2,…,tn }是有穷、非空的变迁集,且 P∩T=ϕ;B:T×P→N是向后关联函数;F:T×P→N是向前关联函数。②α:T→Q+是最早实施时间函数;β:T→(Q+∪{∞})是最迟实施时间函数。③ M0:P→N是初始标识。

2 UML活动图到时间Petri网的映射

对UML 活动图的映射,主要包括以下几种元素的映射:活动,迁移,初始、终止状态,分叉与汇合,分支与合并。

2.1 活动的映射

活动是UML 中最基本的元素之一,如图2(a)上半部分中所示,该图表示执行动作A需要消耗最长45 μs,最短5 μs的时间。图2(a)的下半部分为由该活动映射而来的时间Petri 网模型,该模型有两条路径,上条表示动作执行时间最长的路径,下侧表示动作执行时间最短的路径。t_in_W_A与t_in_B_A表示进入动作A使能时间为0的变迁;t_ex_W_A与t_ex_B_A分别表示完成动作A使能时间为45 μs和5 μs的变迁。由于文中只考虑活动执行时间最长和最短的两种情况,故而用两条Petri网路径来表示这两种边界情况,而不是用时间间隔[45,5]来表示变迁,这样做的优点在于:在将来的可达路径搜索中会比后者获得快的多的速度[4]。库所in_A表示执行动作A之前的状态,库所W_A与B_A分别表示执行时间最长和最短的动作状态,库所out_A表示动作A执行完成的状态。图2(b)表示活动A的执行时间为零的映射关系图,因为活动所消耗的时间为零,所以映射后的Petri网只有一条路径,并且迁移执行的时间为零。

2.2 动作流的映射

在UML 活动图中,动作流代表活动之间的相互关系。图3表示了UML 中的动作流到时间Petri网的映射,图3(a)中活动A到活动B的动作流cf1被映射成两条时间Petri网路径t_ex_W_cf1和t_ex_B_cf1,它们分别代表执行的时间最长25 μs和最短15 μs的路径,这两条生成的路径分别连接了库所out_A和库所in_B,库所out_A表示活动A执行结束时的状态,而库所out_B表示进入活动B之前的状态。

若动作流的执行没有时间消耗,则动作流将被映射成如图3(b)所示的时间Petri网模型,该时间Petri网模型也只有一条路径,并且迁移t_ex_cf1的执行时间区间为[0,0]。

2.3 初始、终止状态的映射

初始状态是UML活动图的起点,这个初始状态被映射成时间Petri网的一个带有令牌的库所(initState_A),该模型中的令牌可以有效地模拟系统的动态行为。另外,从初始状态到活动A的控制流映射为迁移t_in_A。图4(a)表示了初始状态到时间Petri网的映射。

终止状态是UML活动图的终点,这个终止状态被映射成时间Petri网的一个带有令牌的库所(endState_B),该库所带有一个令牌,表示UML活动图的终止状态。另外,从活动B到终止状态的控制流映射为迁移t_end_B,图4(b)表示终止状态到时间Petri网的映射。

2.4 分叉与汇合的映射

分叉与汇合是UML活动图中最常用的并行结构。图5(a)所示的是分叉到时间Petri网的映射,图中活动A分解成两个并行的活动B与C,在映射到时间Petri网的过程中,用迁移t_fork_B_C表示并行结构的分叉点,用库所fork_B与fork_C表示并行结构分支的起始点。图5(b)所示为汇合到时间Petri网,图中活动A与B汇合成活动C,在映射到时间Petri网的过程中,用迁移t_join_A_B表示并行结构的汇合点,用库所join_A_B表示进入汇合后的状态。在此例中,库所out_A与out_B中必须同时拥有令牌,才能使迁移t_join_A_B点火,这个特性完全符合UML活动图并行结构的行为特征。

2.5 分支的映射

UML活动图中的分支表示在满足不同条件时动作流的走向。如图6所示,在映射过程中,用迁移t_in_brc表示进入决策判断的入口,库所brc_B_C表示决策判断点。

3 案例研究

以一种实时嵌入式系统的脉冲血氧测量仪的基本UML活动图为例,说明该映射方法的可用性。图7所示的是血氧仪的脉冲频率激发过程,这个过程每一个活动对时间的消耗有着严格的要求,并且整个过程的执行时间限制在[3 500 μs,4 000 μs]。

图8所示的是血氧仪脉冲激发过程的UML活动图映射成时间Petri网示意图。从图8可以看到,图7中UML活动图中的每一个活动都被映射成两个基本的库所和两条迁移路径,其中两个基本的库所分别用来表示活动的起始点和终点;两条迁移路径分别表示时间消耗最短的和最长的情况。在本例中,使用工具INA Tool[6]来为生成的时间Petri网模型计算系统执行时间最长和最短的路径。通过工具模拟计算,整个系统最长的执行时间为3 907 μs,最短的执行时间为3 746 μs,完全符合血氧检测仪脉冲激发过程的UML活动图规定的执行时间范围。

4 结束语

介绍了一种在嵌入式实时软件设计初期,将带有时间约束的UML活动图的各元素映射成时间Petri网模型,然后计算系统执行时间消耗的方法,利用该方法可以有效地根据设计需求预测系统执行时间的消耗,从而提高嵌入式实时系统开发效率。然而,该方法还是基于人工的规则映射,不能用计算机自动实现。

摘要：UML被广泛应用于嵌入式实时系统等领域的建模,而嵌入式实时系统对时间响应的要求非常严格,UML缺乏对系统时间约束的描述和形式化语义。因此,提出了一种结合MARTE与UML带有时间约束的UML活动图模型,并定义相应的映射规则,将该活动图模型映射到时间Petri网模型,最后通过实例验证了该映射方法的正确性和实用性。

关键词：UML活动图,MARTE,时间Petri网

参考文献

[1]张宏海,李成忠,陈祝亚.嵌入式实时系统[J].安徽工业大学学报,2003,20(1):29-31.

[2]OMG.Unified modeling language:Superstructure v2.0[EB/OL].(2005-07-04)[2011-06-12]http://www.omg.org/docs/formal.

[3]OMG.UML Profile for MARTE[EB/OL].(2008-06-08)[2011-07-02]http://www.omg.org/cgi-bin/doc?ptc/2008-06-08.

[4]周航,黄志球,胡军,等.基于Time Petri Nets的实时系统资源冲突检测[J].计算机研究与发展,2009(9):1578-1585.

[5]DAVID R,ALLA H.Discrete,continuous,and hybrid petri nets[M].German:Springer,Heidelberg Allemagne,2005.

[6]MANSOURI R,KERKOUCHE E,CHAOUI A.A graphical environment for petri nets INA tool based on meta-model-ling and graph[C].World Academy of Science,Engineering and Technology,2008.

UML活动图 篇2

用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

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

包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

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

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

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

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。

*****************************************************************

(1)系统整体用例图

(商品用例图)

（购买信息用例）

(用户资料用例)

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别

泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

●泛化侧重表示子用例间的互斥性；

●包含侧重表示被包含用例对Actor提供服务的间接性；

●扩展侧重表示扩展用例的触发不定性；详述如下：

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

⒈无条件发生：肯定发生的；

⒉有条件发生：未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

UML活动图 篇3

弗拉曼克的《夏图近郊的风景》是一幅色彩浓烈的风景油画，整幅画虽然看上去很丰满艳丽，但结构却很简单，画中的小河、小路、树、房子等都是孩子很熟悉也有能力表现的内容。如何让孩子们在欣赏了大师的作品后创作出自己心中的风景呢？我尝试开展了此次活动。

活动设计：

一、活动目标

1.通过欣赏，感受作品画面浓烈的色彩美。

2.根据自己的观察和感受，描摹出自己对作品的感悟。

3.乐意参加活动，体验互相帮助和艺术创作的快乐。

二、活动准备

材料准备：

1.每人一张弗拉曼克的《夏图近郊的风景》，调好的蓝、黄、绿、红等系列颜料若干，铅画纸每人一张，毛笔或油画笔每种颜色放两支（具体要根据幼儿人数的多少来确定，但不宜太多，以保证每人有一支笔，略有盈余作为机动）。

2.每人1张旧报纸。

3.背景音乐《故乡的原风景》。

经验准备：参观公园风景，为感受作品做铺垫。

三、活动过程及实录评析

1.引导幼儿欣赏《夏图郊外的风景》。

（1）鼓励幼儿说出自己对作品的感觉。

教师：今天老师给小朋友带来了一法国画家弗拉曼克的一幅画，看了这幅画后，你有什么感觉？

（评析：幼儿在初步欣赏后说出来自己的各种感受，有的说感觉很温暖；有的说很舒服；还有的说看了这幅画想喝冰红茶……可见，孩子虽小，但是对作品都有自己的感受。）

（2）引导幼儿观察并说出画面内容。

教师：这幅画里画了些什么？

教师：树的旁边是什么？

（评析：幼儿边看边说边指出各自的位置，加深了幼儿对画面结构的了解。）

（3）引导幼儿观察、分析作品的季节背景。

教师：这幅画画的是什么季节？你从哪儿看出来的？

教师：你们知道这幅画的名字叫什么吗？

（评析：通过提问、对话，可以了解幼儿对季节判断的标准，不少孩子根据画面的色彩进行判断，帮助幼儿了解作品的色调。）

2.幼儿通过用手指在画上描画，进一步感受画的画法。

（评析：通过用手指在原作品上描画，可以让幼儿近距离接触大师的作品，进一步感受作品结构及画法。）

3.引导幼儿探索作画方法，感受作品由近及远的层次。

教师：你们觉得这幅画里离我们最近的是什么？

第二近呢？

离我们最远的是什么呢？

大树的后面有什么？

教师：你们真厉害，能看到被大树遮住的小河、房子、天空。

教师：大树后面的小河、房子、天空要画出来吗？

教师：如果把大树后边的小河、房子、天空画出来会怎样呢？

教师：现在老师给你们准备了一张旧报纸，你们就在旧报纸上试试看吧。试验成功的小朋友就到老师这儿来领白纸画。

幼儿在报纸上试验，探索画景物的先后顺序和怎样保持大树完整性的画法。

（评析：树是这幅画的主角，如何让树成为一个整体而不被肢解是活动的重难点。因为幼儿的年龄特点决定了他们的绘画是透明的，不知道被遮住的地方不要画，因此，我让他们先在报纸上进行试验，结果发现对于大班的孩子来说已经有了一定的经验，通过自己观察、探索，他们很快就找到解决问题的方法。）

4.幼儿自己作画，教师巡回了解幼儿作画情况。

教师必要时给予适当指导，提醒幼儿注意不要相互碰撞，笔用完后还要放回原处，以免把颜色搞混。

绘画过程中播放《故乡的原风景》音乐，营造良好的绘画气氛。

（评析：面对相同的主题，不同的孩子会有不同的理解和不同的做法，我们应该充分地尊重他们，给他们进行自我探索和自我发现的机会，不要轻易地介入。）

5.相互欣赏作品，交流创作感受。

展示幼儿作品，教师和幼儿一起欣赏所有作品，交流创作体会。

（评析：交流创作感受，不仅可以帮助我们了解幼儿的创作意图及画面内容，而且可以提高其语言表达能力，还可以帮助我们更好地了解幼儿。）

活动反思：

在欣赏、分析、理解作品意境的基础上，让孩子通过用手指在原作品（印刷品）上边看边描画的方法，感受、探索画家的精妙技法，然后根据自己的感悟画出自己心中的风景。这虽然是个临摹大师的活动，但并没有束缚于用像与不像的标准来评价，而是充分体现了孩子对作品的理解和个性。

作品的选择贴近了幼儿的生活：虽然作品描绘的是西方的风景，但观看风景的方法是相通的，幼儿每天学习、生活的地方就是一幅天然的风景画，而且我们多次组织孩子去公园看过风景。因此，对于作品中描绘的由近及远的场景，幼儿是有亲身体验，也是能感受，能表现的。

活动过程彰显了幼儿的主体性：活动的主题虽然是临摹大师的作品，但我并没有动一笔，而是通过对话的方式，引导幼儿借助已有经验学会自己观察，自己体会。通过在原作品上用手指描画，探索、感悟大师精妙的绘画技巧。对于作品的重难点遮挡的层次性，我则通过给孩子提供旧报纸进行探索试验的方法，既培养了孩子的自主解决问题能力，又激发了克服困难的勇气。

UML活动图 篇4

关键词：系统测试,UML活动图,测试场景,场景数量爆炸

0 引 言

UML是一种用于对软件密集型系统进行可视化详述、设计、构造和文档化的建模语言,主要用于分析和设计阶段的系统建模[1]。由于UML易于表达、功能强大,融入了软件工程领域的新思想、新方法和新技术,适合用于支持面向对象语言实现的项目,应用范围不仅限于支持面向对象的分析与设计,还包括从需求分析开始的软件开发全过程,已被广泛应用到描述系统的静态结构和动态行为,所以UML模型成为了测试用例生成的有效来源[2]。

UML活动图是一种特殊形式的状态机,它用于对计算流程和工作流程建模[1]。活动图展现了活动可能发生的序列,专注于系统(操作、对象)的动态视图。运用可视化面向对象建模技术UML中的活动图生成测试场景方法和依据场景进行测试用例自动生成的方法不仅适合于软件系统的测试,同时也适用于软件设计阶段中对软件需求和设计模型的测试和验证。

1 活动图的形式化定义

UML活动图主要由活动状态、转移、约束条件、并发活动和分支汇聚节点等基本元素组成[3]。

定义1 一个活动图的边(动作)、方向(逻辑)和节点(状态)等在形式上可以通过一个六元组集合D={<ai, ti, fi, ci, JFi, BMi>|∀ai∈A, ti∈T, fi∈F, ci∈C, JFi∈JF, BMi∈BM}表示,其中A、T、F、C、JF和BM系集合,定义如下:

1) A是非空有限活动状态集,A= {a0,a1,…,am}。a0是初始状态,am是结束状态。

2) T是非空有限转移集,T= {t0,t1,…,tn}。

3) C是有限条件转移表达式,C= {c0,c1,…,cn},ci对应ti。

4) F⊆ {A ×T} ∪ { T× A}表示活动与转移之间的流关系。

5) 只存在一个t∈T,使得(a0,t) ∈F;对任意t′∈T , (t′, a0)∉F, (am, t′)∉F。

6) JF是并发分支与汇聚节点集,{JF0, JF1, … ,JFn}。

7) BM是条件分支与汇聚节点集,BM= {BM0, BM1, …, BMn}。

定义2 设D是一个符合定义1的活动图,CA是当前活动状态,对于∀t∈T:

1) *t= {a| a∈A, (a, t)∈F}和t*={a| a∈A, (t, a)∈F}分别表示t的前集和后集。

2) Enabled(CA)表示可以从CA触发的转移集,enabled(CA)= {t | *t ∈满足c(t)条件的CA}。

3) fired(CA)= {t | (t ∈ enabled(CA))∧((CA-*t)∩ t*= ∅) },当t被触发,新的活动状态CA′=(CA-*t)∪ t*,如果满足条件的转移不唯一,可以选择其中任何一个未触发的转移。

4) EP表示D运行时的执行路径,ep∈EP,它是活动和转移的序列,ep=CA0[c0]t0CA1[c1]t1…[cn-1]tn-1CAn,CA0={a0},CAn={am},CAi为当前活动,ti∈ fired(CAi),i ≥0,CAi=(CAi-1-*ti-1)∪ t*,i ≥1。

图1是一个简单报表系统的活动图模型,它包含了基本的活动图元素。

根据定义1,活动图模型D为符合定义1的活动图,其中活动集合A= {a0,a1,…,a16},a0是初始活动,a16是结束活动;转移集合T= {t0,t1,…,t22};并发分支与汇聚节点集合JF= {JF0,JF1 };条件分支与汇聚节点集合BM= {BM0,BM1 };约束条件集合C= {c0,c1,c2,c3},其中c0表示[invalid],c1表示[valid],c2表示[Yes],c3表示[No]。

2 基于UML建模活动图的测试方法

2.1 基路径方法

向量空间的基是一组相互独立的向量,基的线性组合覆盖整个向量空间,使得该空间中的任何其它向量都可以用基向量线性表示。基对测试的潜在意义是:如果可以把程序看作是一个向量空间,则这种空间的基就是需要测试的关键元素集合[4]。

McCabe提出应根据程序控制流的复杂程度,定量度量程序复杂程度,即程序的环行复杂度等于强连通的程序图中线性无关的有向环的个数。根据图论,在一个强连通图的有向图中,线性无关环的个数为:

V(G)=m-n+1 (1)

其中V(G)是强连通的有向图G中的环数,m是弧数,n是节点数[4]。本文将McCabe方法应用于UML活动图测试分析。如果从UML活动图的终止节点到初始节点画一条虚弧,则UML活动图成为一个强连通图,此时的圈数就是图中线性独立环路的数量。对于图中的每一条独立环路,若删除从终止节点引向初始节点的有向边,则线性独立环路成为从活动图中初始节点开始到终止节点结束的线性独立路径,即基路径,这时每一条基路径表示的就是一个测试场景。

2.2 生成测试场景

测试场景是与待测软件的执行过程相对应的一个活动背景,它描述了系统的典型活动过程。采用基路径方法生成测试场景的基本思想是:首先选择一条尽可能多的经过活动图条件分支节点的基路径ep0,ep0起始于初始活动a0,终止于结束活动am;回溯该路径,依次在每个分支节点处作一次翻转,即取另一条转移边,按照深度优先遍历活动图到终止节点,产生一条新的路径ep1,重复上述步骤,直到所有分支节点都翻转一次,算法结束[5]。

具体算法描述如下:

1) 选择基路径ep0,放入基路径集set_Paths。

2) 将ep0中的每一个条件分支节点bm依次入节点队列node_queue。

3) 将基路径ep0加入路径队列path_queue。

4) 取出节点队列node_queue的队头元素nq。

5) 取出路径队列path_queue的队头元素pq。

6) 当队列nq和pq都不为空时,执行7)。否则执行11)。

7) 如果转移t∈pq并且t∈fired(nq),则从{fired(nq)-t}中取t′。

8) 从分支节点nq,以转移边t′,按照深度优先遍历活动图D′,得到新基路径ep′,并将ep′放入基路径集set_Paths。

9) 如果存在bm′∈ ep′,bm′不在node_queue中,并且bm′!= bm,则将bm′依次入节点队列node_queue,将ep′放入路径队列path_queue。

10) 本次翻转结束,执行4)。

11) 得到基路径集set_Paths,算法结束。

2.3 系统测试的步骤

要达到对相应程序的充分测试,路径覆盖是最充分的测试,但要对活动图上所有可能的路径进行穷尽测试,在实际的情况下是无法达到的,因为循环和并发会导致路径的组合爆炸。为了解决爆炸问题,可以在活动图中进行深度遍历寻找路径的过程中,限定循环至多发生一次,同时覆盖活动图上所有的动作状态和转换。

由于UML活动图中的各种并发总是从并发分支节点开始,结束于并发汇聚节点,满足单入单出的性质,因此可以将包括这些并发活动的部分压缩为一个节点。在生成测试场景时,先分析压缩后的活动图基路径以生成初步的测试场景,然后将被压缩的并发活动实例化,还原到测试场景中,这样就得到完整的测试场景。

根据上述讨论,基于UML活动图进行系统测试的步骤如下:

1) 根据规格说明书设计绘制UML活动图,并检测其正确性、完整性。

2) 将活动图中并发活动压缩为一个活动节点。

3) 计算压缩后的活动图的环形复杂度,确定线性独立的基路径集合。

4) 将2)中被压缩的并发活动实例化,还原到3)中生成的基路径,形成完整的路径,即测试场景。

5) 根据测试场景生成测试用例,设计用例输入数据和预期结果。

6) 执行每个测试用例,并把实际输出结果与预期结果相比较。

设计的测试用例要保证在测试过程中程序的每条可执行语句至少执行一次。

在测试完全部路径后,保留所有的测试用例和测试结果,即可完成对程序中的每一种逻辑处理方式的测试。同理,也可以反过来对已存在的测试用例进行验证。如果经过控制流图分析环行复杂度,得出当前测试有不足或重复的情况,则可以及时发现问题。

3 基于UML活动图进行系统测试

3.1 生成活动图的基路径

将图1中并发活动a5,a6,a7,a8,a9,a10压缩为一个节点N1,则压缩后的活动图为D′= {<ai, ti, fi, ci, JFi, BMi > |∀ ai ∈A′, ti ∈T′, fi ∈F′, ci ∈C′, JFi ∈JF′, BMi ∈BM′},A′= {a0,…,a4,N1,a11,…,a16};T′= {t0,…,t6,t15,…,t22};JF′= ∅;BM′= {BM0,BM1 };C′= {c0,c1,c2,c3}。若从a16到a0画出一条虚弧,则活动图D′成为强连通图。此时活动图D′的弧数m = 16,节点数n = 14,环数V(D′) = 3,即活动图D′的基路径有3条。

选择活动图D′中一条尽可能多的经过条件分支节点的基路径ep0:a0t0a1t1a2t2BM0t4a3t5a4t6N1t15a11t16a12t17a13t18a14t19BM1t21a15t22a16,根据2.2节中生成测试场景算法,得到基路径集set_Paths ={ ep0, ep1, ep2},如表1所示。

3.2 并发活动处理

得到所有基路径后随之而来的问题是,在并发线程较多的情况下,如果按照任意的顺序排列,会导致场景数量爆炸。假设有n个进程并发,每个进程包含mmn个活动数目,则生成的基路径数为[6]:

$\frac{(n\times m)!}{(m!){}^n}(2)$

例如三个进程并发,每个进程包含5个活动数目,则生成的基路径数为15! /(5! ×5!×5!) =756756。这在测试中难以完全覆盖,具体情况下也是不必要的。

测试人员需根据已具备的应用领域知识,以及对系统功能特征和结构特性的了解,对并发活动加以约束[7]:

1) 输入约束条件。例如活动a1必须在活动an之前发生,表示为a1>an。

2) 对活动图进行分类处理,使用标记的方法记下不同种类的活动。测试人员在并发线程的活动中选择重要活动进行组合排列。

3) 指定活动的权值。在生成场景时,权值大,场景比例较大。

4) 指定生成场景的数目。

如果没有测试人员的约束,对N1节点中的并发部分生成基路径数为20个,如果加以约束a9>a10,则生成的基路径数为8个,如(a5,a6,a7,a9,a8,a10),(a6,a8,a5,a7,a9,a10)等。这种约束在并发活动较多时更为有效。

将N1的基路径替换上表中N1,可以得到24个测试场景,如将(a5,a6,a7,a9,a8,a10)替换N1,并加入各条件分支活动的约束条件,生成的测试场景如表2所示。

3.3 由测试场景生成测试用例

通过测试场景最终生成测试用例,还必须确定以下几个要素:

1) 用例中输入序列及限制条件C,从测试场景中得到。

2) 活动状态的访问序列,从测试场景中得到。

3) 活动状态对应的对象方法序列:从活动图中得到。

4) 方法对应的对象,从活动图的泳道中得到。

每个测试场景至少生成一个测试用例,设计用例输入数据和预期结果。例如测试场景ts1的一个测试用例tc1为:

tc1:User.Login(User,123);ReportSystem.Check(User,123);[valid];ReportSystem.ReportSearchPage;User.InputParameters(2009-5-10);ReportSystem.CheckParemeters;ReportSystem.GetDataFromDB;ReportSystem.DisplayResult;ReportSystem.CheckOSTime;ReportSystem.GetCurrentDateTime;ReportSystem.DisplayRefreshTime;ReportSystem.DisplayReport;User.SelectReportFormat(PDF);ReportSystem.ExportReport;NeedOtherFormat;[No]; ReportSystem.Exit.

用户名为User,密码为123的用户登录报表系统后,输入日期参数2009-5-10,系统生成相应的报表,用户选择导出报表格式为PDF,系统导出PDF格式的报表文件。执行测试用例,并把实际输出结果与预期结果相比较。

4 结 论

本文对UML活动图的语法和语义进行了形式化定义和描述,分析了并发活动的处理方法,详细介绍了采用基路径方法从UML活动图中提取测试场景的方法,该方法产生的基路径相对独立,又能较全面地覆盖测试用例。

参考文献

[1]梁义芝,王延章,缪旭东,等.UML活动图的形式语义及分析[J].计算机工程与应用,2003,39(18):28-30.

[2]Wang Linzhang,Yuan Jiesong,Yu Xiaofeng,et al.Generating test cases from UML activity diagram based on gray-box method[C]//Proc of the11th Asia-Pacific Software Engineering Conference.Washington D.C:IEEE Press,2004:284-291.

[3]徐宏喆，陈建明．UML自动化测试技术[M].西安:西安交通大学出版社,2006.

[4]陆惠恩.实用软件工程[M].北京:清华大学出版社,2006.

[5]樊鑫,舒坚,刘琳岚,等.基于UML活动图的测试场景生成方法研究[J].计算机系统应用,2008,17(8):83-86.

[6]曾一,张利武,张元平,等.一种基于活动图的并发软件测试线索生成方法[J].计算机科学,2007,34(12):286-290.

UML活动图 篇5

工作流是针对日常工作中具有固定程序的常规活动提出的一个概念,是一类能够完全或部分自动化执行的过程,在办公自动化、集成制造、电子商务等领域发挥了重大作用。目前工作流过程建模的研究还处于发展阶段,现有的过程建模方法仍存在很多不足。过程模型理论上的不足导致过程建模能力以及过程模型的应用非常有限,不能满足复杂的政府应用需要。主要的建模方法有流程图方法、Petri网模型、EPC方法、UML活动图方法等。

在电子政务系统中,用户的行为普遍具有随机性、交互性、动态性和并发性等特点,非常适合采用 Petri网和UML活动图这样的工具来进行建模。本文以投诉管理的流程为例,研究如何将Petri网和UML活动图结合,提取它们的优点,建立高质量的工作流模型,从而优化业务流程。

1 工作流建模理论

1.1 Petri网工作流建模

传统的Petri网,由库所、变迁、有向弧和托肯等元素组成的。有向弧连接库所和变迁。一般用圆圈表示库所,用矩形示变迁,有向弧用带箭头的直线或者弧线表示。在Petri网的基础上,Aalst提出了工作流网(WF-net)的概念。

一个Petri网PN=(P,T,F)是工作流网,当且仅当它满足下面的三个条件:①PN有唯一的起始库所i,即i没有前驱;②PN有唯一的终止库所o,即o没有后继;③每一个节点x都位于从i到o的一条路径上。

条件①和②是使工作流网必须具有一个起始点和一个终止点,进入起始库所的托肯代表着一个过程实例的开始,而进入终止库所的托肯则意味着一个过程实例的结束;条件③使得工作流网中不存在处于孤立状态的活动与条件,所有的活动与条件都位于由起始点到终止点的通路上。

Petri网作为一种建模工具,既有直观的图形表示,又有严谨的数学分析方法,不仅能描述系统的静态特性,也能描述系统的动态特性,尤其适合于描述含有并发、异步和分布特征的复杂系统。而它的不足是,随着业务过程复杂性的加大,Petri网中变迁与库所的数目增多,其模型复杂程度急剧上升,不易于用户的理解。

1.2 UML活动图工作流建模

统一建模语言UML是一种可视化、规范定义、构造和文档化的建模语言,已经成为目前面向对象软件系统分析与设计的标准。UML 为过程建模提供了四种图,即:时序图、协作图、状态图和活动图。其中,活动图主要是一个流图,描述了从活动到活动的流。它描述活动序列,并且支持对并发行为和活动选择行为的表述,还支持对象流的描述。它综合了以往许多系统建模的思想,如Jim Odell 的事件图、SDL 状态建模技术和 Petri 网等,特别适合于工作流和并发的处理行为。

UML对待用户友好,能够有效地描述系统,模型与程序实现联系紧密,然而其形式化程度相对较低,不能对工作流进行分析验证。

通过以上所述可知,UML活动图与Petri网都适合于工作流建模。两者各有优缺点,若两者相互补充,能够设计出具有良好适应性的工作流模型。

2 基于Petri网与UML活动图的工作流建模

2.1 UML活动图向Petri网的转化

由UML活动图转换到Petri网方法的主要思想是用库所表示活动,用变迁表示活动的跃迁。UML活动图的顺序结构对应Petri网的顺序结构;UML活动图中表示分支的菱形,对应Petri网中的OR-Split、OR-Join; UML活动图中表示并发的分叉同步棒对应Petri网中的AND-Split, 表示并发的合并同步棒对应Petri网中的AND-Join。

2.2 建模方法

Petri网与UML活动图相结合的工作流建模方法如图1所示。

(1) 根据实际业务流程确定工作流。

业务流程的描述必须准确,流程的准确与否影响到所建的工作流模型的合理性。

(2) 用UML活动图对工作流建模。

UML活动图易于用户理解,便于建模人员与用户交流,随时修正业务流程。

(3) 实现UML活动图与Petri网的转换。

运用转换规则将UML活动图建立的工作流模型转换为Petri网工作流模型。

(4) 用Petri网的相关理论进行验证、分析。

若模型不满足合理性(即模型的可达性、合理性、自由选择性、良构性、S可覆盖性等),则重新对业务过程建模;若模型是合理的,则编程实现UML活动图模型。

3 电子政务工作流模型

下面我们以某市电子政务系统中的投诉管理子系统为例,说明集成的工作流建模方法在电子政务中的应用。

3.1 根据投诉管理流程确定工作流

电子政务系统中投诉管理的流程为:(1) 投诉人提交投诉材料进行投诉;(2) 相关部门对该投诉进行记录;(3) 根据登记的投诉信信息联系投诉人和被投诉人;(4) 相关部门收集投诉相关的信息;(5) 根据收集的信息进行评估;(6) 若情况属实则处理该投诉,否则撤消投诉;(7) 将该投诉处理情况归档,以备查询。

3.2 建立UML活动图模型

通过对投诉管理流程的分析,结合实际情况,用UML活动图表示的该工作流模型如图2所示。

3.3 实现UML活动图模型向Petri网的转换

投诉管理子系统的Petri网模型如图3所示。

3.4 基于Petri网模型的正确性分析

导入或修改一个业务过程会产生深远的影响,所以必须保证其正确性。一般地,如果Petri网符合合理性要求,则可以认为该模型是正确的工作流模型。通常验证合理性所采取的办法是根据过程模型的特点,选取便于验证的几种特性(如:可达性、合理性、自由选择性、良构性、S可覆盖性等),然后根据性质间的因果关系进行正确性分析。

3.4.1 可达性分析

Petri网的初始状态决定了哪些状态可达,以及它们的到达次序。因此Petri网一旦确定,被建模过程的可能行为就是确定的,通常利用可达图作为描述工作流行为的方法。图4为本模型的可达图。

图4中可以看到有16种可达状态,但并不是每种状态都发生。如只有在状态(0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0)下,状态(0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0)才会发生。通过建立可达图,可知该模型满足可达性。

3.4.2 合理性分析

工作流网是否合理必须满足以下三个条件:(1) 对应于库所start中的每一个标记,最终会有且只有一个标记出现在库所end中;(2) 当库所end出现标记时,其它库所都是空的。(3) 对每个变迁,从初始状态都能够到达该变迁就绪的状态。在分析技术上判定工作流网合理的方法是将合理性转化成等价的两种特性——活性和有界性。

在图3工作流网中,对任意变迁T,从初始状态可达的任何状态都能到达该变迁的就绪状态,即该petri网是活的;而且,从start到end的所有库所,当任务被实施时它们中的托肯的数量最多是一个,即满足有界性。从而可得知,图3的工作流网是活的且有界的,即所建的工作流网模型是合理的。

3.4.3 自由选择性分析

Petri网是自由选择的,当且仅当对于任何两个变迁T1和T2,·T1∩·T2≠隐含了·T1=·T2。

对于图3的工作流网,变迁T9和T10共享一个输入库P7,显然它们的输入集合相等,因此,所构建的工作流网是有选择的。

3.4.4 良构性和S可覆盖性分析

工作流网的良构性要求具有平衡AND/OR-split和ANOR-join。也就是说,一个AND-split初始化的两个并行流不该由一个OR-join进行汇合。同样,通过一个OR-join创建两个选择流也不应该由一个AND-join进行同步。对于图3的工作流网,T10(OR-split)到T13(OR-join)符合平衡的选择路由。T3(AND-split)到T6(AND-join)符合平衡的并行路由。可见,所建的工作流网符合良构性。根据定理,一个合理的自由选择的WF-net是S可覆盖的。

通过上面的分析可知,如图3所示的工作流网既是合理的又是自由选择的,故此工作流网符合S可覆盖性。通过上证明,所建工作流模型具有可达性、合理性、自由选择性、良构性、S可覆盖性,这些结构化特性在工作流过程定义的分方面都非常重要,因此,有足够的理由证明工作流模型符合确性验证。

4 结 语

本文以电子政务系统中的投诉管理流程为例,研究了一种Petri网与UML活动图相结合的工作流建模方法。该方法集成了UML的用户友好性和Petri网的分析验证能力。

参考文献

[1]袁崇义.Petri网原理[M].北京:电子工业出版社,2005.

[2]汪文元,沙基昌.基于Petri网和UML活动图的工作流建模比较[J].系统仿真学报,2006,18(02):504-510.

[3]张彦歆.结合UML和Petri Net技术的工作流建模的研究[J].微型电脑应用,2008,24(2):47-64.

[4]赵阳,易先清,罗雪山.MD_WFN:一种基于Petri网的工作流模型研究[J].计算机应用研究,2008,25(11):3336-3339.

[5]王哥,杨青,胡金柱.基于Petri网的OA工作流模型研究[J].计算机工程与设计,2007,28(5):1144-1146.

选择序列图创建UML动态模型 篇6

序列图是描述对象如何交互的, 其中最重要的是对象交互的时间。由于序列图与用例路径有关, 在大多数动态建模中都要用到它。

协作图也是描述对象交互的, 但侧重于对象空间的协作。协作图是序列图的“孪生兄弟”, 在序列图与协作图二者中, 可以选择一个。

状态图只有在一个类具有复杂的动态特性时才有用, 多用于实时应用程序, 而大多数应用程序不需要状态图。

活动图描述活动序列, 适合表达工作流和并发处理。

1 选择序列图

序列图可以清楚地描述一个用例路径的实现步骤, 在系统设计中使用最多。其他3个图只有在需要的时候才使用。在项目实例中, 只用序列图就可以满足设计动态模型的需要。

一个用例路径用一个序列图来描述。序列图中的消息序列来自用例路径, 选用的对象序列来自类图。生成序列图的流程如图1所示。

在设计序列图时, 前面已经识别出来的类或类的操作都要受到检验, 有的可能要修改, 有的可能要摈弃, 需要而又没有的要增加。

2 设计序列图

本节将对第一讲定义的14个用例, 选择其中用户登录、录入票据和检索票据3个用例, 分别画出它们的主路径序列图。

2.1 登录

前文已知, 登录的活动者是User, 主路径是:用户提供正确的用户帐户名和密码, 登录到系统中。

主路径细化为:

(1) 用户打开登录页。

(2) 系统显示登录页。

(3) 用户输入帐户名和密码。

(4) 系统检查帐户名在系统中是否注册, 以及键入的密码与用户帐户名是否符合。

(5) 结束登录。

登录的序列图如图2所示。

发送消息的过程如下:

(1) 用户和登录页交互, 使登录页执行事件Page_Load () 。

(2) 用户输入账户和密码, 按按钮Button1, 请求登录页执行Button1_Clickt () 事件。

(3) 在Button1_Clickt () 事件中, 请求UserCls对象执行GetCustomerAccount () 操作, 查找已注册用户中账户和密码都符合的用户账户。

(4) 在GetCustomerAccount () 操作中, 请求SqlHelper对象执行ExecuteScalar () 操作。

(5) 在Button1_Clickt () 事件中, 请求UserCls对象执行GetAuthority () 操作, 返回用户的权限。

(6) 在GetAuthority () 操作中, 请求SqlHelper对象执行ExecuteScalar () 操作。

2.2 录入票据

录入票据的活动者是Undertaker, 主路径是:报销人输入票据信息, 系统保存下来。

主路径细化为:

(1) 报销人打开录入票据页。

(2) 系统显示录入票据页。

(3) 报销人选择要录入票据的项目。

(4) 系统显示报销人所选择的项目的信息。

(5) 报销人录入票据。

(6) 保存票据信息。

录入票据的序列图如图3所示。

发送消息的过程如下:

(1) 报销人和录入票据页交互, 使录入票据页执行事件

Page_Load () 。

(2) 在事件Page_Load () 中, 请求ProjectCls对象执行GetProjectList () 操作。

(3) 在GetProjectList () 操作中, 请求SqlHelper对象执行ExecuteDataset () 操作, 返回报销人所选择的项目的信息并显示在页面上。

(4) 在事件Page_Load () 中, 录入票据页自身要求调用ShowProject () 操作。

(5) 在ShowProject () 操作中, 录入票据页自身要求调用SumInvoice () 操作, 对所选择项目已录入的票据的报销金额进行汇总, 并将汇总金额显示在页面上。

(6) 在SumInvoice () 操作中, 请求InvoiceCls对象执行GetInvoice () 操作。

(7) 在GetInvoice () 操作中, 请求SqlHelper对象执行ExecuteDataset () 操作。

(8) 报销人选择要录入票据的项目, 并输入票据信息, 按按钮butnSave, 请求录入票据页执行butnSave_Click () 事件。

(9) 在butnSave_Click () 事件中, 录入票据页自身要求调用GetCrtlValue () 操作。

(10) 在butnSave_Click () 事件中, 请求InvoiceCls对象执行AddNewInvoice () 操作。

(11) 在AddNewInvoice () 操作中, 请求SqlHelper对象执行ExecuteNonQuery () 操作, 将所录入的票据信息保存到系统中。

2.3 检索票据

检索票据的活动者是User, 主路径是:用户提供票据的检索条件, 系统以报表显示符合条件的票据。

主路径细化为:

(1) 用户提供票据的检索条件。

(2) 系统用报表显示检索结果。

(3) 结束检索票据。

检索票据的序列图如图4所示。

发送消息的过程如下:

(1) 用户和票据检索页交互, 使票据检索页执行事件Page_Load () 。

(2) 用户提供票据的检索条件, 按按钮btnQuery, 请求票据检索页执行btnQuery_Click () 事件。

(3) 在btnQuery_Click () 事件中, 重定向到票据检索结果页, 使票据检索结果页执行事件Page_Init () 。

(4) 在事件Page_Init () 中, 票据检索结果页自身要求调用ConfigureCrystalReports () 操作, 以实例化一个ReportDocument对象来封装报表。

(5) 在ConfigureCrystalReports () 操作中, 票据检索结果页自身要求调用PopulateInvoiceValuesArrayList () 操作。

(6) 在PopulateInvoiceValuesArrayList () 操作中, 请求InvoiceCls对象执行GetInvoiceTotal () 操作, 返回满足检索条件的票据。

(7) 在GetInvoiceTotal () 操作中, 请求SqlHelper对象执行ExecuteDataset () 操作。

(8) 最后, 票据检索结果页自身要求执行事件Page_Load () 。

3 结语

项目实例建立的动态模型是用序列图来描述的。一个序列图描述一个用例路径是怎样实现的。序列图中的消息序列来自用例路径, 选用的对象序列来自类图。

动态模型是依据系统用例模型和类模型对系统做出的详细设计, 是后续系统实现的依据。

参考文献

[1]范晓平.ASP.NET 2.0项目开发第一步UML+VB+C#+Crystal Reports.清华大学出版社, 2008.

基于OWL本体的UML类图推理 篇7

统一建模语言UML是OMG提出的标准对象建模语言,其从不同的测面对信息系统的静态结构和动态行为进行建模。但UML不是一种半形式化语言,其缺乏精确的语义,导致了UML模型一致性问题的产生,而目前多数的UML建模工具并没有提供完善的一致性管理框架。因此,研究UML模型一致性检测具有很大的现实意义。

UML类图是UML模型的核心视图之一,UML类图推理自然也成为了UML模型一致性检测的研究重点。文献[1]中基于描述逻辑研究了UML类图推理问题,给出了UML类图的DL DLCQI的形式化编码。文献[2]中研究了基于描述逻辑DLR的UML类图形式化方法。这些检测方法偏向于形式化方法及推理理论方面的研究,具体应用方面受相关技术的制约,研究成果最终没有转换为彻底的解决方案。文献[3]中研究了基于描述逻辑SHOIN(D)的UML类图形式化方法,证明了其转化为描述逻辑知识库的正确性。其优点在于其针对UML缺乏精确语义的不足,提出了基于描述逻辑的UML类图形式化方法,为进一步研究UML类图推理提供了理论依据。但文献[3]只研究了基于描述逻辑SHOIN(D)的UML类图形式化方法,没有转换为以描述逻辑为基础的OWL本体的表示形式。文献[4]研究了UML类图到OWL本体自动映射方法,但文献[4]只对本体与UML类图进行比较,给出了UML类图到本体模型的映射规则,没有给出UML类图模型元素的OWL本体表示形式,也没有研究UML类图的推理问题。针对文献[3,4]的不足,文章提出了一种基于OWL本体的UML类图推理方案,给出了UML类图的OWL本体表示形式,研究了UML类图包含关系、可满足性、等价关系、相离关系的推理问题。

1 UML类图推理框架

1.1 Jena推理机制

Jena是由惠普语义网络实验室开发的一种用来构造语义Web应用的Java框架,支持基于规则的推理机制,支持RDQL查询语言,以及操作RDF、RDFS和OWL的推理引擎,Jena本体推理机制如图1所示[5],其中Reasoner Registry(推理注册机)负责创建Reasoner(推理机),Reasoner负责生成包含推理机制的模型对象,Ontology/Model API提供了对模型的操作和处理。

1.2 基于OWL本体的UML类图推理框架

Jena提供了的基于规则的推理机,Jena API本质上是Java程序,需要Java运行环境,本文采用jdk1.6.0_04和eclipse3.3,推理框架如图2所示。

2 UML类图的OWL本体映射

UML类图由类加上类间关系构成,类间关系有关联、泛化、聚合、组合、依赖等。为了便于介绍UML类图推理问题,特在图3所示的UML类图中设置Company类为Corporation类的等价类(equivallentClass)。

UML类图是一个四元组S=(CS,PS,OS,RS),其中CS为概念集合,PS为属性集合,OS为行为集合,RS为关系集合。UML类图与OWL本体之间存在很多相似或等价的概念[4,6],特别是在OWL中关联被称为属性,UML类图中的关联可以通过属性表示。经研究,可制定如下UML类图向OWL本体映射规则:

规则1 (标识符规则) 标识符映射为<OWL:Class rdf:ID=″类标识符″/>。

规则2 (属性规则) 类与属性之间的关系映射为OWL:DatatypeProperty,并分别用domain和range说明值域和定义域。

规则3 (取值范围规则) 重数约束映射为maxCardinality、minCardinality来声明类的某个特定属性(对象属性或数据类型属性)的取量范围。

规则4 (行为规则) 是一个函数属性,映射为FunctionalProperty函数属性。

规则5 (关联规则) 在OWL中,关联也被称为属性,在表示类与类之间的关联时,用OWL:ObjectProperty表示;在表示类与属性之间的关系时,用OWL:DatatypeProperty表示。

规则6 (泛化规则) 泛化关系映射为SubClassOf关系。

规则7 (聚合规则) 聚合关系为单向关联关系,匹配为PartOf,并用domain和range声明这两个类。

规则8 (组合规则) 组合关系为单向关联关系,匹配为UnionOf,并用domain和range声明这两个类。

根据以上映射规则,图3所示UML类图,它可映射为如下OWL本体片段:

<owl:Ontology rdf:about=″″/>

<owl:Class rdf:ID=″Company″>

<owl:equivalentClass rdf:resource=″Corporation″/> //等价类

</owl:Class>

<owl:Class rdf:ID=″Staff″/>

<owl:Class rdf:ID=″Administrator″>

<rdfs:subClassOf rdf:resource=″#Staff″/> //泛化关系

<owl:disjointWith>

<owl:Class rdf:ID=″Worker″/>

</owl:disjointWith> //相离关系

</owl:Class>

<owl:Class rdf:ID=″Worker″>

<rdfs:subClassOf rdf:resource=″#Staff″/>

</owl:Class>

<owl:Class rdf:ID=″Director″>

<rdfs:subClassOf>

<owl:Class rdf:about=″#Administrator″/>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class rdf:about=″#Worker″/>

</rdfs:subClassOf>

</owl:Class>

<owl:ObjectProperty rdf:ID=″Work″>

<rdfs:domain rdf:resource=″# Company″/>

<rdfs:range rdf:resource=″# Staff″/>

<owl:Restriction>

<owl:minCardinality rdf:datatype=〃&xsd;nonNegativeInteger〃>1</OWL:minCardinality>

</owl:Restriction>

</ owl:ObjectProperty> //关联关系,关联的逆方向同理

<owl:ObjectProperty rdf:ID=″PartOf″>

<rdfs:domain rdf:resource=″# Company″/>

<rdfs:range rdf:resource=″# Companygroup″/>

<owl:Restriction>

<owl:maxCardinality rdf:datatype=″&xsd;nonNegativeInteger″>1</OWL:maxCardinality>

<owl:minCardinality rdf:datatype=″&xsd;nonNegativeInteger″>1</OWL:minCardinality>

</ owl:Restriction>

</ owl:ObjectProperty> //聚合关系

<owl:ObjectProperty rdf:ID=″UnionOf″>

<rdfs:domain rdf:resource=″# Corporation″/>

<rdfs:range rdf:resource=″# Companygroup″/>

<owl:Restriction>

<owl:maxCardinality rdf:datatype=″&xsd;nonNegativeInteger″>1</OWL:maxCardinality>

<owl:minCardinality rdf:datatype=″&xsd;nonNegativeInteger″>1</OWL:minCardinality>

</ owl:Restriction>

</ owl:ObjectProperty> //组合关系,Product与Company之间的组合同理

3 推理实现

3.1 推理基础

OWL本体知识库KB=<TB,AB>由TBox TB和ABox AB组成,其中TBox(Terminology Box)是术语公理集合,Abox(Assertional Box)是实例断言集合。OWL本体知识库KB推理问题主要包括包含关系、概念可满足性、等价关系和实例检测等等,KB推理问题实质就是可满足性推理问题。如果解释I=(ΔI,·I)满足知识库KB中的所有断言,则称I是KB的一个模型,如果知识库KB存在一个模型,则称KB是可满足的。

3.1.1 TBox的推理任务

对于术语断言TBox T,如果能够找到满足T的解释,即概念在T中的解释为非空集合(或称存在T的模型),则称TBox T是可满足的,否则称TBox T是不可满足的。TBox的推理任务主要有以下几方面:

包含关系 如果对于TBox T的模型I,都有CI⊆DI,那么C⊆D,记作C⊆TD。

概念可满足性 对于TBox T中的概念C,若存在KB的模型I,有CI≠φ,则称C在KB中是可满足的。

等价关系 如果对于TBox T的模型I,都有CI=DI,那么C=D,记作C≡TD。

相离关系 如果对于TBox T的模型I,都有CI∩DI=∅,那么C和D相离。

3.1.2 ABox的推理任务

ABox中有四种断言组成形式:C(a),R(a,b),a=b和a≠b。其中C是概念,R是角色,a、b为个体。

ABox可满足性:称一个ABox相对于一个TBox是可满足的,是指存在一个满足TBox的模型I=(ΔI,·I ),并且对于ABox中的断言有:(ⅰ)如果C(a)∈ABox,a I∈C I;(ⅱ)如果R(a,b) ∈ABox,那么(a I,b I) ∈R I;(ⅲ) 如果a=b∈ABox,那么a I=b I;(ⅳ) 如果a≠b∈ABox,那么aI≠bI。

对知识库KB=<TB,AB>而言,可满足性检测实际上就是检测是否存在TBox和ABox的模型[7]。由于UML类图一般比较少涉及到ABox,故文章主要针对TBox讨论UML类图推理问题。

3.2 推理规则

3.2.1 包含关系推理

Jena支持基于规则的推理引擎,规则构造形式如下:(P:Property),(A P B ),(B P C)->(A P C)。不失一般性,概念包含关系比较容易判断,如果A⊆B,B⊆C,由传递性得A⊆C,于是有:

公理1 subClassOf(C1,C2)∧subClassOf(C2,C3)->subClassOf(C1,C3)。

3.2.2 可满足性推理

本体不可满足性主要是由于不相交关系(disjointwith)引起,所以判断本体的可满足性主要也是围绕不相交关系进行考虑,具体公理如下:

公理2 disjointWith(C1,C2)∧subClassOf(C3,C1)∧subClassOf(C3,C2)->NotSatisfiabilityOf(C3,C1),NotSatisfiabilityOf(C3,C2)。

3.2.3 等价关系推理

等价关系包括等价类和等价个体,等价关系比较容易判断,具体公理如下:

公理3 equivalentClass(C1,C2)->equivalWith(C1,C2)∨sameAs(C3,C2)->equivalWith(C3,C4)。

3.2.4 相离关系推理

相离关系实际上就是判断类不相交和个体不相同,相离关系也比较容易判断,具体公理如下:

公理4 disjoinWith(C1,C2)->SeparatelyOf(C1,C2)∨differentFrom(C3,C4)->SeparatelyOf(C3,C4)。

3.2.5 推理规则设计

Jena规则构造语法如下[5]:

Rule:=Bare-rule or[ruleName:Bare-rule]

Bare-rule:=term,…,term->hterm,…,hterm or hterm,…,hterm<- term,…,term

Term:=(node,node,node) or (node,node,functor) or builtin(node,node,functor)

hterm:=term or[Bare-rule]

functor:=functorName(node,node,node)

node:=uri-ref or prefix:localname or vername or ′a literal′ or number

根据上述规则构造语法,结合公理1～4,设计如下推理规则:

规则1 (包含关系推理规则)

rule1:(?a rdfs:subClassOf b),(?b rdfs:subClassOf c)->(?a rdfs:subClassOf c);

规则2 (不可满足性推理规则)

rule2:(?x rdfs:subClassOf y),(?x rdfs:subClassOf j),(?y owl:disjointWith j)->(?x rdfs:NotSatisfiabilityOf y),(?x rdfs:NotSatisfiabilityOf j);

规则3 (等价关系推理规则)

rule3:(?a owl:equivalentClass b)->(?a owl:equivalWith b),(?c owl:sameAs d)->(?c owl:equivalWith d);

规则4 (相离关系推理规则)

Rule4:(?a owl:disjointWith b)->(?a owl:SeparatelyOf b),(?c owl:differentFrom d)->(?c owl:SeparatelyOf d);

3.3 实验与结果分析

根据上述UML类图的OWL本体映射方法,首先把图3所示的UML类图对应的OWL本体保存为company.owl,然后结合3.2节的推理规则,笔者利用图2所示的推理框架开发了UML类图推理系统原型,包含关系、可满足性、等价关系和相离关系检测结果分别如图4～图7所示。

图4表示Director⊆Staff、Director⊆Worker、Director⊆Administrator、Worker⊆Staff、Administrator⊆Staff;图5表示Director⊆Worker、Director⊆Administrator,Worker与Administrator不相交,所以Director是不可满足的;图6表示Company类与Corporation类等价;图7表示Administrator与Worker相离。推理结果说明了推理系统能够推出预期结果,也证明了推理规则的正确性,验证了本文所提推理方案的可行性。

4 结 语

本文研究了Jena的推理机制,提出了一种基于OWL本体的UML类图推理方案,制定了UML类图向OWL本体转换的映射规则,并给出了具体实例的OWL本体片段。给出了UML类图包含关系、可满足性、等价关系、相离关系的判断方法及其推理规则,编程实现了UML类图包含关系、可满足性、等价关系、相离关系推理。实验结果说明了该推理方案的可行性。

摘要：分析UML模型一致性检测的研究意义,以及UML类图推理的研究现状,提出一种基于OWL本体的UML类图推理方案。研究UML类图向OWL本体转换的映射规则,给出UML类图包含关系、可满足性、等价关系和相离关系的判断方法及其推理规则。利用Jena推理机制实现了UML类图包含关系、可满足性、等价关系和相离关系的推理。

关键词：OWL本体,UML类图,映射规则,推理规则,推理

参考文献

[1]Daniela Berardi,Diego Calvanese,Giuseppe De Giacomo.Reasoning onUML class diagrams[J].Artificial Intelligence,2005,168:70-118.

[2]Cali A,Calvanese D,De Giacomo G,et al.A formal framework for rea-soning on UML class diagrams[C]//Proceedings of the Thirteenth In-ternational Symposium on Methodologies for Intelligent Systems(ISMIS2002),volume 2366 of Lecture Notes in Computer Science,Springer,2002:503-513.

[3]陈振庆.基于SHOIN(D)的UML类图形式化方法[J].计算机工程,2009,35(19):43-45.

[4]严璐,李利.从UML类图到本体的自动映射[J].科学技术与工程,2008,8(13):3645-3648.

[5]吴振生,孙秀迪,李新云,等.基于本体的推理在行业信息化知识库中的应用[J].计算机工程,2008,34(18):60-61.

[6]陈振庆.基于XMI的UML模型向OWL本体转换方案[J].贺州学院学报,2009,25(3):139-144

UML活动图 篇8

近年来, 随着计算机网络、电信网络和有线电视网络技术的发展, 在“三网融合”的背景下, 网络的规模越来越大, 结构越来越复杂, 异构性越来越高, 用户数量越来越多, 网络管理的难度也随之增加。在某种意义上, 管理好一个网络甚至比建设好一个网络更紧要。因此, 如何保证网络的可靠运行和服务质量, 如何提供一个经济有效的网络管理系统, 已经成为广电运营商、设备提供商以及学术界共同关心的重要问题。

基于模型的嵌入式系统设计方法是目前的一个研究热点, 因此, 本文结合实际需要, 把这种方法用于嵌入式管理代理的设计开发中, 从而设计出可维护性更高、扩展性更强的系统, 因而具有较高实用价值和参考意义。

1 管理代理对象结构分析及建模

1.1 识别对象及对象关联

建立类图的第一步是识别领域中的相关对象。识别对象有多种策略, 本文所用策略及识别的对象如表1所示。

1.2 建立系统整体类图

上面识别的一些对象在结构上可能是相同的, 例如前面板的上翻、下翻和确定按钮具有相同结构。显然按钮可抽象为一个类。按照这种方法, 可将对象图抽象为类图。如图1所示为嵌入式管理代理系统整体的主要类图。

1.3 建立各子系统

(1) Agent子系统。每一个管理信息库MIB由一组对象标识符 (Object ID) 组成, 而每个Object ID又包含了一组状态信息样本。Agent子系统能够通过I2C、RS485、温度传感器Temp和电源电平传感器Battery进行数据采集, 并根据来自网络或串口的请求输出信息。类MsgQ是用于串口收发的消息队列。类Timer是定时器封装类, 它为MIBSample类提供了精确定时。

(2) MIB Memory子系统。类MIBMemory管理着嵌入式管理代理的存储空间, 它保存了系统采集的被管设备的MIB, 可以分配空间给新的MIB, 也可以删除某个MIB。MIBMemory是类AgentController的一部分, 即它们之间存在着聚合关系, 每个AgentController对象有1个MIBMemory对象。类ObjectID与类MIBMemory之间也存在着聚合关系, 每个MIBMemory可以存储0到多个ObjectID。类MIB与MIBMemory之间也同样是聚合关系, 每个MIBMemory最多可以存储30个MIB。

(3) Clock子系统。Clock类保存管理代理系统当前累计运行时间。Clock通过一个定时器来测量时间, 每秒钟都调用nextSecond () 方法更新内部时钟。当时间增加到24小时, 调用nextDay () 方法更新日期。

(4) UI子系统。类UI管理着系统与用户之间的交互行为。它接收用户的键盘输入, 然后通过LCD液晶显示屏、LED或蜂鸣器将结果反馈给用户。

2 转换与测试

我们使用visualSTATE建模环境中的有效性测试工具 (Validator) 对嵌入式管理代理的状态图模型进行测试。

Validator用于对VS状态图模型进行交互式模拟、分析和调试。如果借助RealLink硬件调试工具, 还可以连接目标板对状态机的运行时行为进行监控 (暂不讨论这种测试方案) 。有效性测试结果如图2所示。

图2是利用混合图识别出来的状态图模型的一个交互式模拟的示例。通过交互式地输入一些事件, 在计算机中观察可执行模型模拟运算输出的结果及内部变化, 可以测试一个状态机模型。

通过这种方式还可以进行对比分析或回归测试, 例如检查系统的修改有没有导致意外的结果。利用Validator工具还可以将一组测试步骤记录下来, 以备日后重用并进行回归测试, 从而保证了所有的修改都不会偏离设计的初衷。在交互式模拟测试或对比测试前提下, 还可以进行动态分析, 从而获得系统优化和系统瓶颈, 甚至发现模型的哪个部分运行得最活跃、哪个部分从未被激活。

3 结束语

本文以光放大器EDFA设备网管为实例, 在对其进行总体描述之后, 基于UML对嵌入式管理代理进行面向对象系统分析与建模, 构建了一系列用例图、类图和子系统状态图, 然后用层级树辅助建立整体状态图, 并在VisualSTATE状态图建模环境下实现了各层次模型的绘制、模型的交互式模拟测试和完整性测试。

摘要：结合当前HFC网络设备管理代理的需求, 把UML状态图应用于管理代理的软件分析与设计, 以EDFA设备为例, 详细探讨了软件建模过程, 运用面向对象的方法, 构建了软件的用例模型、对象结构模型和行为模型。通过可视化状态图建模工具实现系统的模型仿真、有效性验证和动态规范性验证, 给出了测试结果。

关键词：UML,状态图,EDFA,软件建模

参考文献

[1]Bruce Powel Douglass.实时UML开发嵌入式系统高效对象 (第2版) [M].尹浩琼, 欧阳宇, 译.北京:中国电力出版社, 2003.

[2]Samek M.Practical Statecharts in C/C++:Quantum Programming for Embedded Systems[M].CMP BOOKS, 2002.

[3]IEC60728-7-1.Cable networks for television signals, sound signals and interactive services-Part7-1:Hybrid fiber coax outside plant status monitoring-Physical (PHY) layer specification[S].2003.

UML活动图 篇9

当今，工作流技术的应用越来越广泛，它也逐渐成为计算机领域的研究热点。而工作流设计的正确与否直接影响工作流执行期间的正确性，基于此人们也越来越认识到在过程定义阶段保证工作流模型正确的重要性。目前，工作流的模型验证已经成为工作流技术的研究领域之一，但大多数研究都只是针对单个工作流实例的研究，其中有一部分研究涉及单个工作流实例中多个任务的并发。文献[1,2]基于数据资源语义及其约束的分析为基础，扩展Aalst的工作流网为资源语义约束工作流网，给出了基于并发矩阵的并发冲突检测算法，并给出了基于锁的并发保证机制。文献[3]提出了基于集合的冲突分析方法，该方法分为两个阶段，在第一阶段从工作流定义中产生集合约束，在第二阶段解决第一阶段获得的集合约束。

但当工作流的多个实例并发执行时，这种情况的并发冲突分析比分析单个工作流实例中任务之间的并发要复杂的多，而且分析方法也有所不同。当存在几个工作流实例中的任务同时对环境中的共享数据进行访问时，我们需要考虑如下并发冲突问题：即读写冲突和写写冲突。

本文对UML状态图进行了扩展;然后把扩展的UML建立的工作流模型转化为Büchi自动机[4]，用Büchi自动机之间的积表示多个工作流实例的并发模型;接着给出了根据并发模型中标记的命题公式判断并发冲突的定理，并进行了证明;最后，给出了一个并发冲突检测算法。

2 扩展的UML状态图到Büchi自动机的转化

2.1 扩展UML状态图

我们可以通过UML状态图[5,6]对工作流建模，并通过几个UML状态图之间的同步表示多个工作流实例的并发，但由于UML状态图自身就存在并发的特性，所以会使得证明很复杂。为了消除UML状态图自身的并发性，降低证明的难度，本文把UML状态图转化为Büchi自动机，在实现这一转化之前，我们需要扩展UML状态图。

定义2.1(扩展的UML状态图)扩展的UML状态图是ES=(S,init,Labs,￡,T,ρ)，其中：

1)S是有穷状态集合;

2)init是初始状态;

3)Labs是迁移标记集合，它是元组(source,event,guard,action,target)，其中source是迁移的源状态，event是触发迁移的事件，guard是迁移的监视条件，action是迁移触发时发生的动作，target是迁移的目标状态;

4)￡是状态标记集合，它是命题集合{TR(Di),TW(Dj),True}，其中Di,Dj表示工作流环境中的共享数据，没有读写操作时状态标记为True;

5)T哿2S×Labs×2S是迁移集合;

6)ρ：S→2S是状态精化函数，刻画状态间的层次(父/子)关系.

下面用扩展的UML状态图表示一个实例，图1表示的是某人用银行卡的母卡在账户里存入一定数额的人民币，图2表示的是与此同时另一个人正在用该银行卡的子卡刷卡消费。

这里不再详述UML状态图的操作语义，请参考文献[6,7,8,9,10]。扩展后的UML状态图的操作语义与UML状态图的操作语义只是稍有不同，但在状态标记为True时，语义与原来的相同，而当状态标记为TR()或TW()时，首先要完成对环境中数据的读写操作，然后再执行与原来语义中相同的一系列动作。

2.2 扩展的UML状态图到Büchi自动机的转化

在进行扩展的UML状态图到Büchi自动机前，下面先介绍一下Büchi自动机的定义。

定义2.2(Büchi自动机)Büchi自动机A=(AP,S,Δ,I,L,F)，其中：

1)AP是有穷命题集合;

2)S是有穷状态集合;

3)Δ哿S×S是状态间的迁移关系;

4)I哿S是初始状态集合;

5)L:S→2AP是用命题集合中的命题标记状态的标记函数;

6)F哿S是接受状态集合.

我们假设每个单独的工作流实例都是正确的，下面给出转化过程：

1)Conf0=(init)，把init的所有活跃子状态的初始状态加入Conf0中

2)从事件队列中删除当前触发事件，得到可以被当前事件使能的所有迁移集合

3)检查迁移集合中是否存在冲突的迁移，如果存在则根据迁移间的优先关系进行触发

4)在触发之前，检查迁移所在源状态的状态标记集合，如果标记为True，则直接触发;如果存在读、写标记，则从环境中完成读写操作后才能触发，如果要进行操作的资源暂时不可用，而其它使能迁移的标记为true或其操作的资源可用时，则先进行触发，如果没有这样的使能迁移，则待触发的迁移等待资源可用时进行触发

5)根据迁移关系到达所有可达状态，如果当前触发状态没有其它迁移则从当前格局中删除，否则保留;把所有可达状态中与当前格局中不同的状态加入当前格局，生成新的格局;如果生成的新格局中没有新状态，则算法终止，生成错误信息

6)新格局的状态标记为前继格局中未触发状态的与触发后可达状态的状态标记两者状态标记的合取

7)如果格局中的状态都为终止状态，则算法结束，否则跳到2)。

我们没有在图1和图2中的模型引入层次结构，所以它们通过上述转化过程，得到的Büchi自动机模型与原来的模型相同。

3 建立并发工作流的模型

3.1 Büchi自动机的积

为了建立多个工作流实例并发执行的模型，前面我们已经给出了扩展的UML状态图到Büchi自动机的转化过程，下面我们应用Büchi自动机的积[11]建立并发工作流的模型。

定义3.1(Büchi自动机的积)给定两个Büchi自动机A=(AP1,S1,Δ1,I1,L1,F1)和B=(AP2,S2,Δ2,I2,L2,F2)，它们做积生成的Büch自动机为C=(AP,S,Δ,I,L,F)，其中：

1)AP=AP1∪AP2;

2)S=S1∩S2;

3)(,)∈Δ如果(s1,s2)∈Δ1且t1∈S2或(,)∈Δ如果(t1,t2)∈Δ2且s1∈S1;

4)(s0,t0)∈I当且仅当s0∈I1且t0∈I2;

5)L(s1,t1)=L1(s1)∧L2(t1)s1∈S1,t1∈S2;

6)(s,t)∈F当且仅当s∈F1且t∈F2.

3.2 实例的并发模型

根据Büchi自动机的积的定义，我们建立图1和图2的并发模型。

4 并发工作流的验证

4.1 并发冲突的判定

通常，判定模型时候正确都是通过判定模型是否满足某些性质，这里，并发工作流模型是正确的当且仅当模型中不存在并发冲突即存在读写或写写冲突。下面给出判定工作流模型中是否存在并发冲突的定理。

定理4.1(工作流并发冲突)并发工作流实例间存在并发冲突当且仅当存在TR(Di)∧TW(Di)或TW(Di)∧TW(Di)是Büchi自动机建立的并发模型中某个状态的状态标记的子公式，其中Di是工作流环境中的共享数据。

证明：先证必要性，在扩展的UML状态图模型转化为Büchi自动机模型和Büchi自动机间作积的过程中状态标记都是合取形式，而我们前面又假设每个单独实例都是正确的，所以它们的状态标记不可能存在有TR(Di)∧TW(Di)或TW(Di)∧TW(Di)的形式或是某个状态标记的子公式，现在我们已知并发工作流实例间存在并发冲突，即存在读写或写写冲突，由前面分析知并发冲突只可能发生在用Büchi自动机建立并发模型的过程中，并且存在并发工作实例中的任务同时读写或写写工作流环境中的共享数据，即TR(Di)∧TW(Di)或TW(Di)∧TW(Di)某个状态标记的子公式;

再证明充分性，由于存在TR(Di)∧TW(Di)或TW(Di)∧TW(Di)是Büchi自动机建立的并发模型中某个状态标记的子公式，即并发模型中存在并发冲突，前面我们已经假设每个单独实例都是正确的，所以每个单个实例中的任务间都不存在并发冲突，并发冲突只可能在多个工作流实例的并发过程中产生的。

4.2 验证算法

由于多个工作流实例并发会使得生成的状态空间会很庞大，我们这里使用on-the-fly技术[12]，它是一种根据需要生成状态空间而不用生成整个状态空间的技术。假设sub(F)表示状态标记F的所有子公式，下面给出根据上述定理验证Büchi自动机建立的并发模型正确性的算法：

算法的复杂度为O(m×n)，其中m为工作流环境中共享数据的数目，n为并发模型中的状态数。最好情况只检测1次，即在初始状态检测出对于第一个共享数据就存在并发冲突，最坏情况是检测m×n次，即生成最后一个状态并检测出它对于最后一个共享数据存在并发冲突。

根据验证算法，检测到图3中(s4,t3)存在读写冲突，检测到冲突后算法终止。

6 结束语

本文扩展了UML状态图，在其中加入了状态标记;给出了扩展的UML状态图到Büchi自动机的转化过程，通过Büchi自动机间的积建立并发工作流模型;提出了判定是否存在并发冲突的判定定理，并给予了证明;给出了验证并发模型正确性的算法。本文的侧重点是并发工作流模型的验证，但还存在着许多工作要进一步研究：本文只给出了检测是否存在并发冲突，而没有给出检测到并发冲突后使用何种策略解决冲突，这是我们下一步研究的方向;如何直接通过UML状态图之间的同步表示并发工作流模型，并使用相关的方法降低验证的复杂性，这也是我们下一步研究的方向。

参考文献

[1]胡乃静,顾宁,施伯乐.基于语义约束的资源工作流并发正确性验证[J].计算机研究与发展,2003,40(5):712-719.

[2]胡乃静,赵亮,罗永强.基于资源限制流图的工作流并发结构的正确性验证[J].小型微型计算机系统,2003,24(7):1289-1292.

[3]LEE M,HAN D,SHIM J.Set-based access conflict analysis of concurrent of workflow definition[J].Information Processing Letters,2001,80:189-194.

[4]Giannakpoulou D,Lerda F.From States to Translation:Improving Translation LTL Formulae to Büchi Automata[C].Formal Techniques for Networked and Distributed Sytems-FORTE2002:22nd IFIP WG6.1.International Conference,Houston,Texas,USA,Berlin:Springer-Ver-lag,2002,2529:308-326.

[5]HAREL D.STATECHARTS:A VISUAL FORMALISM FOR COMPLEX SYSTEMS[J].Science of Computer Programming,1987,8:231-274.

[6]董威,王戟,齐治昌.UML Statecharts的模型检验方法[J].软件学报,2003,14(4):750-756.

[7]李留英,王戟,齐治昌.UML Statechart图的操作语义[J].软件学报,2001,12(12):1864-1873.

[8]周颖,郑国梁,李宣东.面向模型检验的UML状态机语义[J].电子学报,2003,31(12A):2091-2095.

[9]蒋慧,林东,谢希仁.UML状态机的形式语义[J].软件学报,2002,13(12):2241-2250.

[10]Harel D,Naamad A.The STATEMENT Semantics of Statecharts[J].ACM Transactions on Software Engineering and Methodology,1996,5(4):293-333.

[11]Berard B,Bidoit M,Finkel A,et al.Systems and Software Verification-Model checking Techniques and Tools[M].Berlin:Springer-Verlag,2001.