用例图和顺序图构造操作剖面方法的有效软件工程论文

摘 要:探讨了由面向对象用例模型构造操作剖面的可行性,结合一个实例,详细介绍基于统一建模语言UML(Unified Modeling Language)的用例图和顺序图构造操作剖面的具体方法,代写硕士论文并对基于UML用例图和顺序图构造操作剖面方法的有效性进行了分析.结果表明,将操作剖面构造与软件系统建模相结合,可大大简化构造过程,降低开发费用.

关键词: 软件;软件工程;可靠性工程;操作剖面;用例模型;统一建模语言;用例图;顺序图

操作剖面是描述用户如何使用软件的一种技术.因此通过构造软件系统的操作剖面,可以有效的指导软件可靠性测试工作,获得理想的测试结果,大大提高软件系统的可靠性.一方面,软件运行条件和用户的使用情况可以用剖面概念进行描述;另一方面,建立完整的系统表示模型,可以使人们从全局上把握软件系统的全貌.因此,如何准确高效的构造出切合实际的软件系统操作剖面已成为软件可靠性测试工作的一个关键环节.操作剖面的基于非面向对象技术的构造已经有了较为系统化的、成熟的理论和方法[1],而基于面向对象技术,尤其是基于统一建模语言UML(Unified Modeling Language)的系统操作剖面构造的系统化和成熟的理论、技术、方法以及相关工具目前尚未见到.

随着面向对象技术应用的日益广泛,如何将面向对象技术用于软件系统操作剖面的构造已逐渐成为人们关注的焦点[2~4].本文探讨在成熟的面向对象统一建模语言UML基础上进行软件系统操作剖面的构造,并对其有效性进行了分析.

1基本概念及操作剖面传统构造方法

1.1 基本概念

统一建模语言UML是面向对象技术发展的重大里程碑.它不仅支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程.UML用例视图,作为描述系统功能需求的手段和方法,用于辅助需求分析,描述项目的功能性需求.用例模型中,每个用例的执行独立于其他用例,在功能上具有完整性.用例是一个类,它完整地描述系统功能,包括用例执行过程中可能产生的诸多变化情况,错误情况和异常情况等.用例实例化的结果通常称为场景(Scenario),场景描述系统执行的一个特定情况.但用例视图是静态的,用例的动态执行过程不能表述,需要用UML的交互模型和活动模型进行描述.而顺序图模型可以用来进行一个场景说明———即一个事务的历史过程[6],即完成用例动态执行的模拟.因此认为,对于任何一个复杂的软件系统,上述2个视图对系统功能性需求进行建模已经足够.这为基于用例视图和顺序视图构造操作剖面提供了重要依据.

1.2 操作剖面传统构造方法

操作剖面的基于非面向对象技术的构造理论和方法在文献[1],文献[7]已经有详细的阐述.Musa详细描述了操作剖面的特征,代写硕士论文并给出了获得操作剖面的方法.操作剖面是通过自顶向下不断细化软件输入空间并确定概率的方法获得的,如图1所示.由于篇幅所限,在此不作详细解释.但需要指出的是,在Musa的操作剖面构造方法中,操作剖面是在软件实现和软件测试阶段建立的,而其它剖面是在需求分析阶段之前建立的.随着面向对象技术等先进软件工程方法的日益成熟,一方面,面向对象和快速原型法等新兴开发技术的应用使得操作剖面的构造时机有了提前的可能;另一方面,在面向对象开发模式下,客户要求根据用例模型安排人员现场模拟系统运行时,系统操作剖面的构造时机的提前便成了必要的需求.

2基于UML的操作剖面构造

本节中使用PBX(Private Branch eXchange)电话交换系统进行操作剖面构造方法的介绍.该系统是由AT&T公司开发的国际Definity项目.AT&T公司在此项工程的开发过程中使用了操作剖面和其他提高质量方法,大大提高了系统的可靠性和软件质量.PBX系统是一个命令驱动系统.图2是系统示意图,其中,PBX交换机由UNIX工作站进行控制,同时与提供给用户使用的数台电话相连.该系统按运行模式分为单位使用、个人使用、服务人员使用、系统管理和系统维护5类.为简化操作剖面的构建过程,本文仅以系统管理模式为例进行操作剖面的构造。构造操作剖面是一种逐步细化软件运行条件和使用范围的过程.本文将基于UML用例图和顺序图操作剖面构造的整个过程分为3个主要阶段,即建立用例剖面、确定场景剖面和构造操作剖面.

21 构造用例剖面

UML用例图捕获系统用户需求及其描述的完整性给系统功能的细化提供了便利.下面首先给出用例剖面的定义,然后列出进行用例剖面构造的步骤.从软件需求规格说明到用例剖面的构造需要完成的步骤:①细化系统功能,生成用例模型,即根据软件需求规格说明建立UML用例视图;②识别对用例产生影响的主要环境变量,并估测其出现概率;③分析用例和环境变量关系,并估计在环境变量影响下用例出现的概率.例如,在PBX交换系统中,系统管理工作方式主要包括移动电话或修改所提供服务、增加电话、代写硕士论文摘除电话和更新电话簿4个功能,对这些功能产生主要影响的是电话类型,在此只考虑模拟电话和数字电话.根据上述步骤,在UML用例视图的基础上进行扩充得到如图4所示的PBX系统中系统管理用例剖面视图.在表示参与者与其参与执行的用例之间的通信路径的关联上标注用例发生概率,如在管理用户和增加用例之间的关联上标注8%,表示此用例发生概率为8%;用注释标注对每个用例产生主要影响的环境变量及其发生概率,如对移动电话或修改所提供服务、增加电话、摘除电话用例都产生影响的环境变量用注释标注A(80%),B(20%),表示对上述3个用例有影响的主要环境为A,B,它们在各个用例下发生的概率均为80%与20%.

22 构造场景剖面

场景,作为系统执行特定情况的描述,是用例实例化的结果.根据UML用例图定义可知,用例的定义包含用例所必需的所有行为,包括所有正常行为、异常情况及其预期反应[6].因此,场景有必要对用例的所有情况进行描述.下面给出了场景剖面的定义及其

构造方法.定义场景剖面:场景剖面是指软件系统由用例定义的场景及其发生的概率组成的集合.同样可以给出集合的定义方式,在此省略.需要指出的是,此处场景发生的概率是在用例事件发生前提下的概率,是条件概率.场景剖面的构造在操作剖面的构造过程中起到了承上启下的作用,它完成了操作剖面构造方法中的①用顺序图对用例场景进行描述;②估计场景出现概率2个步骤.PBX系统中添加用户用例根据添加用户类型不同可以划分为3个场景:添加一般人员用户、添加秘书用户和添加经理用户,按照PBX命令形式分别表示为: http://www.51lunwen.org/master_degree.html add-s staff,add-s secre-tary和add-s manager.根据上述步骤,可以得到如图5所示的PBX系统中增加电话用例的场景剖面视图.在视图中,用注释描述用例的每一场景发生的概率,如在增加电话用例中添加一般人员用户场景发生的概率为70%,它表明在增加电话用例事件发生的前提下添加一般用户电话的场景发生的概率是70%.

2.3 构造操作剖面

场景是用例实例化的描述,因此,场景剖面所描述的仍然是面向用户的细化功能,而不是实际实现的操作,需要进一步细化.同时,操作剖面的构造有时还需要考虑系统的负载率[5](本文不作介绍).下面给出由场景剖面构造操作剖面的一般步骤:①识别场景剖面中的所有操作可能,建立操作和场景之间的联系;②识别操作输入变量和输入状态的作用;③根据用例剖面、场景剖面、环境变量情况等因素估算操作出现概率.上例中,每一场景用PBX系统的一条命令表示,不能再分,认为每一场景均包含一个操作.在考虑操作输入变量时,认为地址(location)对操作性质没有影响,因此,在本文中不予考虑,当然如果认为某一地区发生此类操作较多的话,则另当别论.最后,可以根据条件概率公式,估算得到任一操作发生的概率,如管理人员执行add-s staff命令(针对模拟电话用户)的操作概率为2%×8%×80%×70%=0.000896。

建立了操作剖面,就可以此为依据安排软件可靠性测试工作的进行,大大提高软件可靠性.由于篇幅所限,此例中提及的PBX系统操作剖面的Musa构造过程在此不作详细介绍.读者如有兴趣,可参见文献[5]和文献[7].可以看出,基于UML用例图和顺序图的操作剖面构造方法将操作剖面的构造过程融入了软件系统建模过程中,大大减少了构造步骤,避免了传统构造方法繁琐的过程,降低了软件开发的费用.

3有效性分析

首先,分析用例剖面的构造.通过用例剖面的定义可以看出,一方面,用例剖面通过UML用例视图定义的用例描述了系统的功能性需求,传统构造方法所强调的客户、用户和系统模型等信息已经在建立用例模型时用UML用例视图进行了描述;另一方面,它又通过定义这些用例发生的概率确定了系统的定量使用情况,满足剖面的完备性.从此意义上讲,用例剖面与传统意义上的功能剖面是等价的.其次,从用例剖面到场景剖面的构造,以及从场景剖面到操作剖面的构造过程完成了操作剖面构造传统方法中的①细化功能;②识别出所有可能的运行;③建立运行与功能之间的联系;④识别运行的输入变量和输入状态;⑤)计算每个运行子类的出现概率等步骤,最终生成系统完整的操作剖面.可以看出,传统构造方法中所考虑到的问题在基于UML用例图和顺序图的操作剖面构造方法中均有所考虑,因此,认为本文提出的操作剖面构造方法是有效的.表2列出了2种方法中相关关键术语的对比.

4结束语

基于用例图和顺序图的操作剖面的构造,可大大简化操作剖面的传统构造过程,避免由软件系统需求规格说明到功能剖面的繁琐构造过程.同时,由于用例图和顺序图对系统功能性需求描述能力的完备性,也决定了这种操作剖面构造的方法与传统方法的等价性.

参考文献：

[1] Musa J D. Operational profiles in software-reliability engineering [J]. IEEE Software, 1993,10(2):14~32

[2] Lakey P, Neufelder A. System and software reliability assurance notebook[M]. NewYork: Rome Laboratory,1997. 9-16~9-20

[3] Regnell B, Runeson P, Wohlin C. Towards integration of use case modelling and usage-based testing[J]. Journal of Systems and Software, 2000, 50(2):117~130

[4] Butler G, Cretu A, Khendek F. Reconciling use cases and operational profiles[DB/OL]. http://www.51lunwen.org/master_degree.html http://citeseer.nj.nec.com/148512.html, 2000-04

[5] Lyu M R. Handbook of software reliability engineering [M]. McGraw-Hill publishing, 1995

[6]兰博.UML参考手册[M].姚淑珍,唐发根译.北京:机械工业出版社,2001Rumbaugh J. The unified modeling language reference manual[M]. Translated by Yao Shuzhen, Tang Fagen. Beijing:China Machine Press, 2001(in Chinese)

[7]党齐民,杨新发.软件可靠性工程中的操作剖面开发[J].软件学报,1996,7(增刊):323~328DangQimin,YangXinfa. Operational profile development in software reiliability engineering[J]. Journal of Software,1996, 7 (supplement):323~328(in Chinese)

 ()   () 

本文标签：