UML状态图

UML状态图（共8篇）

UML状态图 篇1

0 引言

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

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

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.

[4]中华人民共和国国家质量监督检验检疫总局, 中国国家标准化管理委员会[EB/OL].GB/T20030-2005HFC网络设备管理系统规范[S].2005.

UML状态图 篇2

软件

学院

标 准 实 验 报

（实验）课程名称

UML

电子科技大学教务处制表

告

电 子 科 技 大 学

实

验

报

告

学生姓名：

黄斌

学 号：

2823102006

学生姓名：

马少龙

学 号：

2823102008

学生姓名：

袁孝涛

学 号：

2823102007

学生姓名：

文志伟

学 号：

2823102009

学生姓名：

杨超

学 号：

2823102010

指导老师：訾德义

实验地点：

教学楼A105

实验时间：10,12,05

一、实验室名称：

软件实验室

二、实验项目名称：可存取款ATM系统

三、实验学时：16

五、实验目的：

随着经济建设的发展，人民生活水平得到了质的飞跃，手头的多余资金越来越多，在倡导消费理念的同时，人们也热衷于理财，银行管理系统为广大用户提供了方便，快捷的资金管理通道。

银行系统分为ATM机，用户，后台服务器。用户向ATM提交数据，ATM机向服务器提出申请，服务器向ATM发送数据，ATM机将数据反馈给用户。

银行系统主要功能用：取款，存款，账户设置，转账汇款，查询账户。

六、实验内容：

一个功能完善的银行管理系统，必须包括以下的几个模块。 用户登陆

由用户登陆、用户注销、退出系统3个部分组成。 取款

客户从银行合法账户取出一定资金。

 查询账户

客户接受银行合法账户余额。

 转账

用户把一个合法账户的款项存到另一个合法账户。

 账户设置

主要对用户的账户相关信息的设置与修改。

七、实验器材（设备、元器件）：

a.试验环境 Rose 2003 b.操作系统 window XP

八、实验步骤： 步骤1：需求分析 步骤1.1：用户登陆

用户登陆所包括的功能模块如下图：

用户进入本银行管理系统的入口，没有得到身份验证的用户只能拥有最低的使用权限，即只能选择退出系统或是用户登陆。这是一个稳定、安全的系统所必须具备的。

步骤1.2：账户管理

账户管理系统是整个银行系统的核心，用户在此选项可以对合法账户的资金进行一定的操作，满足客户日常需要。并且对自己账户的密码，个人信息等进行安全方面的设置。

 取款

 转账汇款

 密码修改

步骤1.3：账户查询

用户在使用系统对账户进行合法操作的同时，也需要对自己账户的动态信息有一个了解，以确定本账户是否正常。使用户对自己的资金规划有一个更清晰的认识

 余额查询

 账户明显

 账户信息

步骤2：系统模型的创建 步骤2.1：系统用例模型

 角色的创建 ATM Customer： Operator：

 可存取款系统根据业务流程可以分为以下几个用例 Add cash Deposit Funds Query Account Remove Cash Shutdown StartUp Validate PIN WithDraw Funds

Customer用例关系图

Operator用例关系图

整个系统的Use Cases关系

步骤2.2：系统动态模型

动态模型包括以下其中几个：  状态图

Closed Downentry/ Display system downClosedownAfter(Elapsed Time)StartupIdleProcessing Customer Inputentry/ Display Welcome...After(Elapsed Time)Wating for PINInvalid PINCard ConfiscatedTerminatingInsufficient CaseValidating PINPIN EnteredValid PINThird Invailid,StolenConfiscatingCard EjectedCancel/EjectWating for Customer ChoiceRejected / EjectEjectingReceipt PrintedProcessing TransactionQuery SelectedPrintingProcessing QueryProcessing DepositQuery OKDeposit SelectedWrong DepositDeposit OKDeposit CheckingCash Deposited / Print ReceiptCash Dispensed/Print ReceiptDispensingWithdrawal SelectedProcessing WithdrawalWithdrawal OK

 时序图

ATM客户端子系统时序图

ATM Server System子系统时序图

 协作图

ATM客户端子系统协作图

ATM Server System系统协作图 1: ATM Transaction《Subsystem》 : ATMClient2: BankResponse3: Transfer5: Withdraw6: Confirm7: Abort《Business logic》 : Withdrawal TransactionManger23: Log17: Log24: log36: log21: ReadBalance22: ReadCumlative Interest12: read Balance13: readLast Deposit Amount18: debit19: credit20: ReadBalance25: debit26: credit27: ReadBalance28: check Daily Limit29: updateDaily Total《Coordinator》 : BankTransactionServer32: Deposit33: Confirm34: Abort4: Query8: ValidatePin《Business logic》 : Transfer TransactionManager9: debit10: credit11: readbalance《Business login》 : Query TransactionManagerBussiness logic : Deposit TransactionManger35: log37: debit38: credit39: ReadBalance40: check Daily Limit41: updateDaily Total《Business logic》 : PIN Validat...14: debit15: Credit16: ReadBalance31: read30: validate《databasewrapper》 : CheckingAccount《databasewrapper》 : Transaction Log《databasewrapper》 : Saving Account《databasewrapper《databasewrapper》 : CardAccount》 : DebitCard

步骤2.3：创建系统包图与系统类模型

创建系统包图：从宏观的角度上将系统分割为两个独立的包。

ATMSystemcustomerSystemoperaterSystem

 客户端信息包内的类组织 验证PIN码 取款 存款 查询

withdraw_funds0..*存款1..*desposit_funds0..*Validate_PIN1..*1..*取款query_accont0..*查询金额 服务器包内的类组织 增加资金 移动资金 开启服务 关闭服务

startup110..*Add_cash1..*0..*0..*11remove_cashshutdown

步骤2.5：系统部署

仓库管理系统的Component视图的创建 配置图的创建

ATMClient<>BankServer

九、实验结论：

系统主要的实现目标是实现对可存款&取款ATM机的前台和后台服务器端系统的设计，;提供完善的存款&取款功能，分布有人和ATM交互，ATM和后台服务器端交互，完成对ATM存取款功能设计。

十、总结及心得体会：

UML工具很好的帮助我们实现了对可存取&取款ATM机系统设计，通过ML建模，把事物从抽象到实例化的过程，对每个对象进行细化分析，从而得到简单而方便，容易理解的模型结构。通过UML模型可以高效完成软件设计，通过此次试验收获很大。

十一、对本实验过程及方法、手段的改进建议：

？？？？？

报告评分：

UML状态图 篇3

当今，工作流技术的应用越来越广泛，它也逐渐成为计算机领域的研究热点。而工作流设计的正确与否直接影响工作流执行期间的正确性，基于此人们也越来越认识到在过程定义阶段保证工作流模型正确的重要性。目前，工作流的模型验证已经成为工作流技术的研究领域之一，但大多数研究都只是针对单个工作流实例的研究，其中有一部分研究涉及单个工作流实例中多个任务的并发。文献[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.

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

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

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

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

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

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.

基于本体的UML类图语义推理 篇5

关键词：本体,UML类图,形式化,描述逻辑

0 引言

UML[1,2,3]是一种形式化建模语言, 可以对具有静态结构和动态行为的系统进行建模。作为一种通用的建模语言, UML越来越多地用于大型系统的建模, 但复杂系统的建模往往需要进行严格的形式分析和验证以保证其正确性。UML是半形式化的———其语法结构采用了形式化的规约, 但其语义部分则是用自然语言描述的, 缺乏准确的语义[4], 难以对模型进行语义推理验证和检查。

为了提高UML的语义精确性, 许多组织和学者提出了很多形式化UML的方法。如:英国的p UML组 (precise UML group) [5]试图给出一种相对治本的方法, 其目标是运用浅显的数学知识对UML元模型进行形式化, 从而将UML发展为一种精确的 (形式的) 建模语言。此外, 还有研究人员利用形式化语言:Z语言、Object-Z语言、COOZ语言、B语言、PVS、XYZ/E、RAISE等对UML类图进行形式化, 以提高模型的准确性。

本文在详细分析对比领域本体与UML模型之间相似性的基础上, 提出了一种基于本体的UML类图形式化方法, 通过本体的推理实现对UML类图的语义检查。由于本体与UML类图模型有着极为相似之处, 并且, 本体能在语义和知识层次上描述信息系统, 因此, 把UML类图模型转换为本体, 通过对转换后的模型进行推理, 可以检查出模型中存在的语义问题, 从而提高了建模的效率。

1 UML类图与领域本体的对比分析

类是任何面向对象系统的核心, 因此, 类图成了最常用的UML图[3]。系统的结构由一组通常称为对象的部件构成。类描述系统中不同对象的类型, 而类图则显示出这些类以及彼此之间的关系。

一个类图主要包括三部分:类名、属性和操作 (方法) 。并且, 类与类之间还存在着各种各样的关系, 包括:依赖、关联、聚合、组合以及泛化 (继承) , 这些类之间的关系依照顺序依次增强的。两个类之间的依赖, 说明一个类的对象暂时使用另一个类的对象。关联则意味着一个类的对象在一段时间内使用另一个类的对象。关联关系包括关系的方向性、角色以及基数等三个要素。方向性指关联关系是从源类指向目的类, 在不同的关系中源类和目的类具有不同的角色, 并具有1对1或1对n的数量关系。关联关系的语义为源类对象中包含目的类对象或对象引用, 因此只有当两个对象的类之间存在关联关系时, 这两个对象之间才可能会发消息。聚合是整体—部分关系, 聚合关系可以看作特殊的关联关系。组合是比聚合还强的关系 (尽管它们的工作方式非常相近) 。泛化是一种更一般描述和更具体描述之间的分类关系。

本体最早是一个哲学上的概念, 从哲学范畴上讲, 本体是客观存在的一个系统的解释和说明, 关系的是客观现实的抽象本质。在人工智能界, 本体最流行的定义是Gruber给出的即“本体是概念模型的明确的规范说明[6]”。后来, Borst在此基础上给出了本体的另一个定义即本体是共享概念模型的明确的形式化的规范说明。通过分析上述定义, Studer认为其包括四层含义:概念模型、明确、形式化和共享。Perez等人认为本体可以按分类法来组织, 他归纳出本体包含5个基本的建模元语。这些建模元语分别为:类、关系、函数、公理、实例, 通常也把class写成concept。概念的含义很广泛, 可以指任何事物, 如功能、行为、策略等等, 实例代表元素;从语义上讲, 概念就是对象的集合, 实例就是概念;关系代表了在领域中概念的交互作用, 形式定义为n维笛卡尔乘积的子集:R:C1×C2×…×Cn, 关系主要分为四类, part-of (概念之间整体与部分的关系) 、kind-of (概念之间的集成关系) 、instance-of (概念的实例与概念之间的关系) 、attribute-of (概念是另一个概念的属性) ;函数是一类特殊的关系;公理代表永真断言。

通过比较可以容易看出, UML类图与本体两者具有高度的相似性[7], 如:UML类图中的类名对应本体建模元语中的类或概念, 关系对应建模元语中的关系, 对象对应于建模元语中的实例, 属性和操作 (方法) 对应于建模元语中的函数, 但UML类图中的函数和本体建模元语中的函数有些少许差别, 例如, 为证实一个Student (一个Student必须至少选学一门课程) 的身份, 一个方法/函数get_course () 可能被声明或定义。本体中的函数一类特殊的关系。该关系的前n-1个元素可以唯一决定第n个元素。形式化的定义为F:C1×C2×…×Cn-1→Cn。例如mother-of就是一个函数, mother-of (x, y) 表示x是y的母亲。UML类图与本体最大的不同之处在于:本体有公理, 具备推理能力, 可以进行自身推理;而UML类图是形式化语言, 不能进行自身的推理。由于其语义的非形式化特点, 所以, UML类图所描述的系统模型往往会隐藏一些错误, 而自己不能检查出来。因此引入本体以弥补对象模型的缺陷。类图与本体之间的对应关系如表1所示。

2 UML类图与本体的转换

本体与UML类图有着许多相似的特性。基于两者的相似性, 建立UML类图到本体的转换, 将UML的类图模型转换为形式化的本体模型。本体作为一种模型需要使用具体的语言表示, 本文选择描述逻辑作为其描述语言, 同一阶谓词逻辑相比, 描述逻辑具有可判定性, 描述逻辑也已经成为其它本体表示语言 (如OIL、OWL等) 的逻辑基础, 而且, 描述逻辑也可以对象模型进行形式化[8]。最后通过对转换后的本体进行推理, 以检查出UML中存在的语义问题。

定义1一个UML类图模型是一个四元组C= (Cn, Cp, Cr, Cm) , 其中:Cn表示类名, Cp表示类属性, Cr表示类之间的关系, Cm表示多重性。在此只考虑UML类图的静态特性, 由于类的方法属于动态性的知识, 不予考虑。

定义2一个DL (Description Logic) 本体模型是一个二元组O= (N, A) , 其中, N=Concepts∪Properties∪Relationships表示一个有限的标识符 (identifier) 集, A表示一个有限的公理序列, 每个公理由作用于标识符的若干构造算子 (如, ∪, ∩, , , 等) 而实现。

显然, 很容易进行UML类图到DL本体之间的转换, UML类图中的Cn、Cp和Cr可直接转换为DL本体中的N, UML类图中的Cn、Cp、Cr和Cm通过一些构造算子可以构造成为DL本体中的公理。

下面通过一个具体实例来说明两种模型的转换:

根据上述规则, 图1可以转换为DL本体:

N是类、属性和关系的集合, A是包含公理和等价公理的集合。Employee, Name, supervise () 等直接映射为领域本体中的概念, 属性, 关系的集合;通过构造子、∩、∪构造SupervisorEmployee、TeacherEmployee、Supervisor≡Employee∩supervise.Graduate等领域本体中的公理。

3 UML类图语义推理

本文主要借助描述逻辑中的Tableau算法对转换后的本体模型进行推理, Tableau算法通过构造一棵关于概念C的Tableau树来计算C的可满足性。该算法的基本思想是:首先, 将不是NNF (Negation Normal Form) 范式的概念通过使用“德·摩根规则”转换为NNF范式, 初始化树T (T仅包含一个根节点) , 然后反复使用转换规则扩展树T, 直到各分枝出现矛盾或者无规则可用。有关描述逻辑的Tableau的算法详细介绍可参阅文献[9]。目前, 已经出现了很多的本体推理机系统, 其中最新的、应用最广泛的和最具代表性的有:Racer, Pellet, Fa CT。Racer是德国Franz Inc公司开发的一个采用描述逻辑作为理论基础的本体推理机, 不仅可以当作描述逻辑系统使用, 还可以用作语义知识库系统;Pellet是美国马里兰大学MNDSWAP项目组专门针对OWL-DL开发的一个本体推理机, 基于描述逻辑表实现;Fa CT是英国曼彻斯特大学开发的一个描述逻辑分类器, 提供对模式逻辑的可满足性测试。

下面就利用Tableau算法对图1进行推理, 图1中的概念Employee有两个分类, 分别为概念Supervisor和概念Teacher。如果图1能准确地描述现实世界, 那么概念Supervisor和概念Teacher应该是不相交的, 即SupervisorTeacher是可满足的 (satisfiable) 。如果SupervisorTeacher成立, 则Supervisor∩Teacher≠。也就是说, {Employee∩supervise.Graduate}∩{Employee∩supervise. (Bachelor∪Graduate) }是可满足的, 整个推理过程如下:

到此已经不能对树T再使用任何转化规则 (transformation rules) 了, 算法结束。树T的节点和边分别为:

由于C (x1) 含有冲突 (clash) , 所以概念{Employee∩supervise.Graduate}∩{Employee∩supervise. (Bachelor∪Graduate) }是不可满足的, 即Supervisor∩Teacher=, 原假设SupervisorTeacher不成立, 因此图1需要修改, 修改后的图形如图2所示。

归纳总结基于本体的UML类图语义推理的一般过程如下:

(1) 找出类图中的概念、关系、属性等直接转化为对应领域本体中的概念、关系和属性。

(2) 利用⊆, ∪, ∩, ﹁, ∀, Ǝ等构造算子根据类图的概念层次关系和属性构造对应中的公理。

(3) 借助描述逻辑提供的Tableau算法对转换后的本体模型进行推理。初始化树T, 将不是NNF范式的概念通过使用“德·摩根规则”转换为NNF范式。

(4) 反复利用上述规则扩展树T, 直到各分支出现矛盾或无规则可用为止, 修改类图。

4 结论

UML作为一种图形化建模语言, 其语义描述是非形式化的, 且缺乏推理能力, 不能对其所建模系统进行语义检查, 使得所建立的模型存在不一致等问题, 影响了建模效率。本文提出了一种基于本体的UML类图的形式化方法, 通过本体提供的推理能力, 对UML类图进行推理, 从而检测出隐藏在UML类图中的不一致等问题, 以达到精确建模的目的, 提高了建模效率。

参考文献

[1]Grady BoochJ, ames Rumbaugh, Ivar Jacobson.The Unified Modeling Language User Guide SECOND EDITION[M].Addison Wesley Pro-fessional, May 19, 2005.

[2]Kim Hamilton, Russell Miles.Learning UML 2.0[M].O'Reilly, A-pril, 2006.

[3]邵维忠, 蒋严冰, 麻志毅.UML现存的问题和发展道路[J].计算机研究与发展2, 003, 40 (4) :509-516.

[4]Evans A, Kent S.Core Meta-modeling Semantics of UML:The pUML Approach[DB].http://www.cs.york.ac.uk/papers/pumlun199.pdf, 2005.

[5]Borst P, Akkermans H.An Ontology Approach to Product Disassembly[C]//EKAW 1997, Sant Feliu De Gu5xols, Spain, October:15-19.

[6]Dencho N Batanov, Waralak Vongdoiwang.Using Ontologies to CreateObject Model for Object-Oriented Software Engineering[M].In:Shar-man, Raj, et al.ONTOLOGIES:A Handbook of Principles, Conceptsand Applications in Information System, Chapter 16.New York:Springer, 2007.

[7]Daniela Berardi.Using DLs to reason on UML class diagrams[C]//Proc.Workshop on Applications of Description Logics.2002.

UML状态图 篇6

文中提出将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.

UML状态图 篇7

关键词：系统测试,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状态图 篇8

软件工程作为一种软件从需求分析到概要、详细设计再到产品最终开发使用以及维护的全生命周期过程, UML (Unified Modeling Language, 统一建模语言) 在其中起到了非常重要的作用。它作为一种可视化的面向对象的建模语言, 运用统一标准的标记定义并实现软件系统开发全周期的描述与记录, 在1997年被OMG采纳作为软件开发业界标准以来, 在软件开发的四个主要部分:初始、细化、构造以及应用阶段分别用不同的UML设计图形分开表示, 如图1上面第一行所示。它从项目计划、需求分析道设计、编码与实现再最后进行测试与配置和使用与维护, 使得软件开发工作人员更加专注于构建产品本身的结构和模型, 而较少的关注使用何种程序语言以及何种算法实现。另外, 用UML建立模型以后, 可以利用UML工具直接将软件本身转化为某种指定的程序语言, 这也大大的提高了软件开发的效率[1,2]。

2 活动图的概述

活动图是一种表述过程机理、业务过程以及工作流的技术。作为一种非常常用的UML工具图形, 它主要使用在软件设计过程中的需求分析阶段和设计中的概要设计阶段, 如图1左边所示, 它主要用于描述记录软件活动的先后顺序, 从一个活动 (事件) 转到另外一个活动 (事件) 的控制流情况。因此, 与常用的软件流程图类似, 从本质上说, 活动图是一类流程图[3,4,5]。

活动图作为一类主要刻画软件系统具体活动流程的工具, 它主要用在系统需求分析阶段的用例模型的具体描述, 根据软件活动图的详细刻画, 用户可以大致了解整个系统的执行情况, 如何根据不同条件执行分支改变执行方向。活动图通常作为用例图建模的工作流来使用。下面构建的证券股票交易的活动图即是作为股票交易用例图的详细分析阶段而应用的。

活动图对用例尤其有用, 因为它可以为用户提供明显的开始和结束标志状态。活动图还可以在建立用力具体流程图时显示用例图之间以及用例内部的详细执行路径。它详细给用户说明了何种情况下某种用例有效, 同时告知用户用例完成后软件系统保留原状态的条件是什么。因为Unified Process (统一软件过程) 是一种反复的过程, 在需求分析阶段经常会遇到根据原用例框架图构建详细活动图时又发现新的前面没有想清楚的附加用例, 这时软件开发者只需将新用例的功能附加到自己模块的用例中, 从而大大减少了开发人员的软件开发时间, 提高了开发效率。

3 活动图的建模步骤

如图1所示, 活动图可以在软件周期中的多个建模元素当中存在, 主要包括比如:用例、状态、顺序、协作、类、接口以及方法和操作等。用活动图构建具体软件工作流程模型通常按照以下几个步骤进行:

(1) 首先清楚要对软件系统中的哪些类 (对象) 进行识别, 找到具体负责软件系统工作流程的业务对象的目标是为每一个重要的业务对象建立对应的工作泳道。这些对象用来表示业务领域的实体, 当然也可以表示某种抽象的概念或者事物。

(2) 明确软件工作流程的初始和终结 (止) 状态, 主要目的是清晰具体工作流的各自边界。

(3) 建模具体的动作 (活动) 状态。主要目的是对依时间发生的动作活动事件, 可以将它们表示成对应的动作 (活动) 状态。

(4) 建模具体动作流。一般来说, 建模先处理顺序的动作 (活动) , 然后处理条件行为 (比如:分支与合并) , 最后处理并发等行为 (比如:分叉与汇合) 。

(5) 建模对象流。具体来说就是找到与描述工作流紧密相关的重要对象, 同时连接它到对应的动作 (活动) 状态中。

(6) 细化和精化建立的模型。

以下针对具体的证券交易系统的活动图进行详细的建模分析。

4 建立证券交易系统的活动图

本节对用例框架中的“股民交易股票”用例创建活动图, 目的是详细说明系统活动图的一般绘制方法以及流程。通常创建具体活动图有如下的五大任务:

(1) 找到需要详细描述的用例。

(2) 把找出的用例主路径绘制出来。

(3) 把对应用例的从路径绘制出来。

(4) 活动对象的事务分区用泳道的方式表示出来。

(5) 最后改进高层活动同时加入更多活动图, 完善它。

在下面详细介绍每一步时, 将会逐步创建一个活动图。“Unified Process”是一个反复的过程。不要因为返回到前面的阶段去简化一个模型或者模型的某一个部分而感到难堪。这样做时, 检查一下你所修改的模型之后的其他模型, 就会发现你的修改会影响整个工程。这些提前完成的修改是建模软件的任务, 会让你提前发现错误并且在新方法中受益。

4.1 标识用例图

注:图2 (a) 是整个证券交易系统的用例图, 图2 (b) 只是 (a) 图中一小部分内容, 虽然只有一个用例, 但只要仔细考虑一下, 交易股票如何进行, 就会发现, 还有很多步骤需要细化。

首先明确建模的活动图针对的对象, 以本模型为例, 第一步是找到对应需要活动图详细建模描述的用例。从用例开始, 以下例子“股民交易股票”是证券交易用例系统图中的一小部分。软件系统需要使用许多活动图详细描述系统使用过程, 软件设计过程中它们都被分割成可以统一管理的子模块部分。

4.2 建模主路径

通常情况, 构建某个用例图的详细活动图时, 软件设计人员一般利用某一条明显的主要路径来描述执行的工作流, 然后再进一步从该主要路径进行下一步扩展, 如图3所示, 它是对图2的用例分解图的主路径。

所谓最明显的路径, 即从工作流开始到最终结束, 其中没有任何错误或是判断路径, 它是完成用例功能最容易实现的路径。在上述示例中, 让股民交易股票最容易的方式就是打开证券交易系统, 登录用户账号, 选择股票, 交易股票, 成功结束交易[6,7,8,9,10]。

4.3 建模从路径

针对用例图建立的活动图的主路径, 设计者需要检查其他可能的工作流程情况。通常是通过检查每一步主要路径的活动图, 就会发现该主路径上会出现诸如:处理临时错误、亦或是执行其他重要分支活动等情况, 从而把设计者带到还没有在主路径建模的其他不同方向。

如图4中增加了“打开证券系统”可能出错的情况;登录个人帐户可能失败的情况;打开系统仅仅为了查看股票信息, 然后结束的情况;按照实际情况将交易分为了“买入股票”、“卖出股票”两类, 分别就这两类交易又增加一个时间判断和交易的合法性判断, 给出了不在正常交易时间的买入或者卖出股票的处理;就可能的买入失败或者卖出失败也进行了正确的处理。交易成功以后, 更新帐户信息, 重新回到“显示帐户信息”栏, 又开始一轮新的上述过程。最后, 股民主动地退出帐户结束本次交易活动图。

4.4 泳道添加

泳道是一种UML活动图, 它能够清晰体现出某个动作发生在哪个部门。通常泳道用来区分活动模型中的不同对象它们内部不同的业务流程和它们相互在活动过程中交互的逻辑关系, 方便用户进一步理解系统的业务逻辑。为了方便起见一般用并排的矩形条来分别绘制业务流程, 它能够直观方便的描述不同对象业务的区别与联系, 由于形状像泳道, 故此得名泳道图。它能够极大提高用户对活动图的可读性。以本文活动图为例, 在建模活动图后, 把活动图根据主要对象分为两个不同泳道:“股民泳道”和“证券系统泳道”, 如图5所示。

仔细观察图4和图5, 我们会发现:图5更加清晰地界定了股民和证券系统分别在此次活动中所扮演的角色, 它们都具体做了哪些动作, 出现了哪些情况。然后根据实际情况, 系统增加了一个“查询股票”也即是图中的“显示账户信息”, 因为很多时候, 股民并不一定想要交易, 上证券系统仅仅为了了解股票信息。同时增加了证券系统检查的一系列活动:“合法用户检查”、“合法交易时间检查”和“合法交易检查”。名称的些许改动, 不是问题, 含义一致。至于合法性检查, 在图4的判断“◇”的约束条件中, 已经详细注明, 如果卖出合法:“卖出股票数目<=已有股票数&非今天买入的股票”;买入合法:“可用资金>=买入股票数*股价”。为了简化图型, 故而以“合法交易与否”概括。

4.5 改进高层活动

在最后一步建模活动图中, 需要强调反复建模修改的意识。需要在不断回退活地图中增加更多描述细节。建立完整的开始和结束活动状态, 同时强调选择最复杂的活动图建模。以股票交易活地图为例, 在上图5中, 明显看到:账户信息更新包含了更为复杂需要细化的活动功能, 具体如图6所示。

在图6中, 本活动图建模了3个具体的子活动。当“账户信息更新”活动从主活动图启动以后, 就跳转到图6的详细图中判断, 控制流就会从“查出股民历史信息”进入“更改股票信息”, 再进入“添加股民交易信息”, 最后“账户信息更新成功”, 控制流退出该子活动图。假定在处理这3个活动时没有错误发生, 控制流将会继续从“账户信息更新”活动进入主活动图的“显示账户信息”。

如果“账户信息更新”活动图中有错误, 这在实际过程中股民是不会看到的, 是由证券系统自行处理。

5 结束语

软件工程设计是一项系统工程, 其中包括了用例图、活动图、类图等在内的多种软件设计和开发模型, 为了提高软件开发者的程序开发效率, 通过UML的多种不同工具共同完成了软件开发的系统工程, 其中如用例图、活动图等工具的使用, 为软件设计后续的详细设计以及程序开发明确了前行的具体方向, 提高了效率。

活动图和用例图是面向对象程序开发前期阶段最重要的功能表示方式, 在各类软件系统开发过程中占据了主要的位置, 比如针对病人的医疗系统, 针对医院管理的医院绩效管理系统的开发和设计。用例与活动图的组合使用在可以预见的将来还将一直持续下去[11,12,13,14,15,16]。

摘要：活动图作为uml的一种建模图形广泛应用在面向对象软件系统开发过程中, 本文主要研究了活动图针对具体软件工程设计中的用例, 由粗到细, 逐步分解的设计过程。首先界定了活动图在软件开发周期模型中的应用, 接着以中国证券交易系统中股民股票交易子活动图设计为例详细描述了功能活动子图的绘制过程, 然后对整个软件系统的活动图的绘制过程进行了描述, 并给出了软件开发工程中活动图的最根本原则。