面向对象测试模型论文

面向对象测试模型论文（共9篇）

面向对象测试模型论文 篇1

0 引言

“程序测试是为了发现错误而执行程序的过程”[1]。软件测试是使用人工或自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别[2]。随着开发技术的进步,相对于传统的面向过程的软件开发技术,面向对象技术使得软件产品具有高质量、稳定性好、可重用行好和可维护性好等优点。然而,由于面向对象技术的多态、继承、封装等特性,不再是传统的功能模块结构,原有集成测试方法已成为不可能,使得传统的软件测试方法不能适应具有新特性的面向对象软件的测试。同时,面向对象技术开发的软件的代码重用率高,需要更加严格的软件测试来避免错误的繁衍。由此看来,面向对象的程序设计并没有降低软件测试的难度,相反使软件的测试变得更加复杂。面向对象开发使用的不是传统的开发模式,每个开发阶段有不同的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和设计的结果。因此,传统的测试模型对面向对象软件已经不再适用,应对面向对象的开发技术,需要提出新的测试策略和方法来支持面向对象的软件测试。

1 面向对象测试

面向对象测试的整体目标和传统软件测试的目标是一致的——以最小的工作量发现最多的错误。但是面向对象测试的策略和战术有很大不同,由于面向对象的特点是封装、继承和多态,测试的视角扩大到包括复审分析和设计模型,测试的焦点从过程构件转向了类。

1.1 面向对象测试模型

面向对象的开发模型突破了传统的瀑布模型,将开发分为面向对象分析(OOA),面向对象设计(OOD)和面向对象编程(OOP)三个阶段。针对这种开发模型,面向对象的软件测试可分为:面向对象分析的测试,面向对象设计的测试,面向对象编程的测试,面向对象单元测试,面向对象集成测试,面向对象系统测试[3]。

1.2 面向对象分析的测试

面向对象分析(OOA)是“把E-R图和语义网络模型,即信息造型中的概念,与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法”,最后通常是得到问题空间的图表的形式描述。

OOA直接映射问题空间,全面地将问题空间中实现功能的现实抽象化,测试重点在其完整性和冗余性,OOA的结果是为后面阶段类的选定和实现,类层次结构的组织和实现提供平台。因此,对OOA的测试,应从以下方面考虑:

(1)对认定的对象的测试

(2)对认定的结构的测试

(3)对认定的主题的测试

(4)对定义的属性和实例关联的测试

(5)对定义的服务和消息关联的测试

1.3 面向对象设计的测试

面向对象设计(OOD)采用“造型的观点”,以OOA为基础归纳出类,并建立类结构或进一步构造成类库,实现分析结果对问题空间的抽象。OOD是OOA的进一步细化和更高层的抽象。OOD确定类和类结构不仅是满足当前需求分析的要求,更重要的是通过重新组合或加以适当的补充,能方便实现功能的重用和扩增,以不断适应用户的要求。因此,对OOD的测试,应从如下三方面考虑:

(1)对认定的类的测试

(2)对构造的类层次结构的测试

(3)对类库的支持的测试

1.4 面向对象编程的测试

面向对象程序具有继承、封装和多态的新特性,这使得传统的测试策略必须改变。封装是对数据的隐藏,外界只能通过被提供的操作来访问或修改数据,这样降低了数据被任意修改和读写的可能性,降低了传统程序中对数据非法操作的测试。继承是面向对象程序的重要特点,继承使得代码的重用率提高,同时也使错误传播的概率提高。多态使得面向对象程序对外呈现出强大的处理能力,但同时却使得程序内“同一”函数的行为复杂化,测试时不得不考虑不同类型具体执行的代码和产生的行为。

2 面向对象测试实现

面向对象软件的最小的可测试单位是封装的类或对象,类包含一组不同的操作,并且某特殊操作可能作为一组不同类的一部分存在。面向对象的软件测试分为包括方法级测试、类级测试、类簇级测试和系统级测试。其中,类级测试是测试面向对象软件的关键。

2.1 示例

如图2所示类的层次结构中,基类是一个抽象类Shape,Line和Quadrangle是从Shape派生而来,并使用Point来定义其定点。其中,Quadrangle还派生了三个类:Square、Rectangle和Other。类的设计如图2所示。

Point:表示二维平面上的一个点(x,y坐标)。

Shape:表示二维平面上的基本形状,是一个抽象类,作为其余各类的基类,Point除外,并提供平面上计算长度和面积的抽象方法,提供实现不同形状的对象之间转换的方法ChangeTo()和RollBack()。

Line:表示线段,从Shape类派生而来,通过两个Point对象来定义,表示线段的两个顶点,并具体实现了所有抽象方法。

Quadrangle:表示四边形,从Shape派生而来,通过四个Point对象来定义其四个顶点,并实现了所有抽象方法。

Square:表示正方形,从Quadrangle派生而来。

Rectangle:表示长方形,从Quadrangle派生而来。

2.2 测试用例的设计

给定平面上的四个点p1(1,1), p2(3,0), p3(4,4), p4(4,1),通过Line(p1,p2), Line(p2,p3), Line(p3,p4), Line(p1,p4),由输入的四个点可以输出一个四边形:

(1)由RollBack(p2,p3)将去掉点p2,p3,四边形转换为由点p1和p4组成的线段。

(2)重置p2,p3的坐标为p2(8,1),p3(8,4),由ChangeTo(p2,p3)将p2,p3加入,正确输出是由p1,p2,p3,p4组成的长方形;若p2(4,1),p3(4,4),则由ChangeTo(p2,p3)将输出由p1,p2,p3,p4组成的正方形。

(3)置p2.x=2,p2.y=2,p1,p2,p3三点将变为特殊的共线关系,p2位于线段p1p3的线段上,四点无法组成四边形。

(4)置p2.x=1.5,四点无法组成凸四边形。

全面的测试用例设计可以采用以下策略[4]:

第一,根据方法特性将被测类的方法划分为构造函数、功能函数和接口函数。

第二,对于构造函数,列出所有前置条件和后置条件的组合,根据不同的组合设计测试用例。

第三,对于功能函数而言,对所有公有方法列出前置条件和后置条件,根据各种有意义的组合设计测试用例;对所有受保护的方法,严格区分有访问权限和无访问权限的前置条件和后置条件设计测试用例;对所有私有方法,根据实际情况选用合适的策略进行测试。

第四,对于接口函数,应绘制类的状态转换图,根据该图设计测试用例,覆盖到每种类的状态和状态的转换。

实际测试中,以上的情况都应结合多种基本的测试方法来选择测试数据。

3 结束语

面对面向对象技术开发出来的程序具有更好的结构更规范的编程风格,极大地优化了数据使用的安全性,提高了代码的重用率。同时,也影响了软件测试的方法和内容,增加了传统软件设计技术所不存在的错误,增加了软件测试的难度。面向对象测试技术能解决传统测试方法的不足,同时,更高效、快速、全面的测试技术以及自动化测试是面向对象测试技术所需解决的,以适应要求更高、功能更强大的软件系统。

参考文献

[1]Myers Glenford J,Badgett Tom,Thomas Todd M,et al.The Art ofSoftware Testing[Z].John Wiley&Sons Inc.2005.

[2]路晓丽,葛玮,龚晓庆,等.软件测试技术[M].北京:机械工业出版社,2007.

[3]柳纯录.软件评测师教程[M].北京:清华大学出版社,2005.

[4]武剑洁,陈传波,肖来元.软件测试技术基础[M].武汉:华中科技大学出版社,2008.

面向对象测试模型论文 篇2

面向对象测试方法在观测控制系统中的应用

介绍了面向对象测试方法在观测控制系统(OCS)中的应用.与OCS开发过程和模型相对应,介绍了迭代的面向对象的测试过程,在过程中相应于面向对象的基于组件的开发方法,应用面向对象的.测试方法,提出适合OCS的方法和内容以及OCS的测试重点,包括各开发模型的测试,与子系统的接口测试,应用组件的测试,体系结构的测试.

作 者：王坚 黄鲲 任间 朱利平姚仰光 刘光曹 袁海龙 金革 WANG Jian HUANG Kun REN Jian ZHU Li-ping Yao Yang-guang LIU Guang-cao YUAN Hai-long JIN Ge 作者单位：安徽省物理电子学重点实验室,中国科学技术大学,合肥,230026刊 名：核电子学与探测技术 ISTIC PKU英文刊名：NUCLEAR ELECTRONICS & DETECTION TECHNOLOGY年，卷(期)：27(2)分类号：P111.2关键词：观测控制系统 面向对象的测试 测试过程 测试方法 模型 接口

面向对象测试模型论文 篇3

关键词:面向对象;白盒测试;用例

1 引言

如何提高软件质量是软件工程致力解决的关键问题之一。软件测试和验证是保证软件正确性和提高软件可靠性的最基本和最重要的手段。自20世纪80年代以来,面向对象方法和技术的研究已遍及计算机软件、硬件和应用各领域,在软件工程领域更是得到了广泛的重视,但研究的重点和成果主要集中于面向对象分析与技术方法学领域(即软件开发的前期),而面向对象软件测试技术的研究还比较薄弱。近年来,国内外对面向对象软件测试进行了大量的研究,但目前该领域还处于百家争鸣的阶段,还未形成一套较为成熟与完善的软件测试理论与方法。本文从软件测试的层次划分出发,对面向对象的测试方法和解决方案做一探讨,并结合具体项目给出了实例设计。

2 面向对象理论

运用面向对象的方法和技术,首先必须明确什么是“面向对象”。曾经有很多年,“面向对象”被认为是使用一系列面向对象程序设计语言(如Ada95,C++,Smalltalk等)的软件开发方法。现在“面向对象”己包含完整的软件工程观点,Peter Coad和Edward Yourdon给出了“面向对象”的如下定义:面向对象(Object-Oriented)=对象(Objects)+分类(Classification)+继承(Inheritance)+通信(Communication)。

面向对象软件的封装性、继承性、多态性和动态绑定等特性提高了软件的可重用性,使软件开发更快、质量更高,而且软件易于维护、易于修改。通过组装可利用子系统而产生更大的系统,然而另一方面,它却给软件测试带来了更多的困难。与之相对应的软件测试技术还相对滞后,如何探索出一套行之有效的方法,尤其是如何采用自动化的方法来测试这些软件,己成为软件测试者们所面临的挑战。

3 白盒测试的传统方法

白盒测试方法主要依据逻辑段盖准则,如语句覆盖和判定覆盖等。这些覆盖准则是白盒测试方法的重要理论基础,能够指导测试人员设计出有效的测试用例。

SQA Team Test是测试Power Builder软件的有用测试工具,它能够与Power Builder对象紧密地结合在一起,根据使用SQA Team Test测试软件的经验和对该软件的理解,认为设计出有效的测试用例仍是使用SQA Team Test测试软件的关健性工作。能否设计出一系列有效的测试用例,将直接影响到软件的测试效果,因为SQA Team Test测试软件的测试思想是回归测试,所以能否发现软件中存在的问题,仍依赖于测试用例的设计。

从前面的分析中可以看出,无论是使用白盒测试方法还是使用SQA Team Test测试软件,设计有效的测试用例是测试工作的重要环节。传统的白盒测试方法是按照软件模块内的逻辑控制结构、运行过程和模块间的组织结构与接口,逐个设计出针对每个模块、每个子系统和系统的测试用例,因此每个模块都会被测试到,或者说能够保证测试的模块被覆盖。因为白盒测试的基础是依据对程序结构的清楚描述,而模块内部的逻辑履盖由逻辑覆盖准则提供保证。但是在事件驱动面向对象的软件中,软件的设计思路和软件的结构与传统的面向过程的软件相比已经发生了相当大的改变,对象和事件概念在软件开发中占有非常重要的地位,而传统的白盒测试方法并不能适应这种变化。

4 面向对象白盒测试框架分析

测试设计是整个测试过程的关键部分,面向对象软件开发中的白盒测试设计优劣更是整个测试工作的成败所在。为此在本文中我们可以具体的实例来设计一个白盒测试的框架和方法。

面向对象的白盒测试通常不能独立地测试一个方法(操作),这个方法相当于传统的测试单元,而是将这个方法作为一个测试类的一部分。

如果一个基类中有一个方法,继承类也继承了这个方法,但是这个方法可能在继承类中被私有数据和方法使用,所以尽管基类中已经测试了这个方法,但是每个继承类也需要考虑对这个方法进行测试。一般从下面两个方面进行考虑。

(1)继承的成员函数是否都不需要测试。一般来说,对父类中已经测试过的成员函数,两种情况需要在子类中重新测试,即继承的成员函数在子类中作了改动,或成员函数调用了改动过的成员函数的部分。

(2)对父类的测试是否能照搬到子类。多态有几种不同的形势,如参数多态,包含多态,过载多态。包含多态和过载多态在面向对象语言中通常体现在子类与父类的继承关系上。对具有包含多态的成员函数测试时,只需要在原有的测试分析的基础上扩大测试用例中输入数据的类型。

从上面的分析可以看出,面向对象的软件的白盒测试主要是针对软件设计中的类和对象来进行测试的。因此链接被测试的软件的类结构,是进行白盒测试的关键。由于封装的原则,在面向对象软件的类一般设计为私有或受保护类型,即类的属性和方法是无法从外部直接访问的,必须通过类中的公有方法来实现。因此设计测试用例时必须要注意对这些公有成员的才做。白盒测试逻辑覆盖的方法主要包括语句覆盖、分支覆盖、条件覆盖、条件组合覆盖等。穷举测试要求对所有可能的输入和状态执行所有的路径,除非对一些小实例,穷举测试是不现实的,通常是通过从所有可能的测试用例中确定最有可能检测出最多错误的子集,进行有限的测试来发现尽可能多的错误。但是为了实现对类中所有方法的有效测试,必须设计足够多的测试用例。

下面我们就以一个自动售货机为例设计一个软件系统的白盒测试用例。一个软件系统是有很多的服务组成的,而每个服务时由很多的用例组成的,下面我们给出自动售货机的用例和服务,如表1所示,描述用例的用例图如图1所示。

对用例的用户描述往往采用系统序列图,它将系统看做一个整体,并从用户的角度描述用例的处理过程,以购买商品用例为例,给出其处理过程序列表如表2所示。

借助购买商品的流程可以对服务进行白盒测试。白盒测试主要进行基本路径测试,我们在这里主要设计语句覆盖测试和分支覆盖测试,来设计面向对象软件的白盒测试的测试用例,测试用例的设计原则是保证在测试中程序的每一个可执行语句至少执行一次,针对购买商品的流程得出的具体路径有两条,路径1:1-2-3-4-5;路径2:1-3a-2-3-5a-4-4a-5。

根据路径生成测试用例:根据判断节点给出的条件,选择适当的数据以保证每一条路径可以被测试到。只要设计出的测试用例能够保证控制流程图中的所有路径都能被执行到,就可以使得程序中的每一个可执行语句至少执行一次,则服务中每个条件的真假两种取值都可以得到测试,从而实现可以检查程序的主要执行路径,又可以覆盖程序的所有分支,而且可以满足语句覆盖的要求。

5 小结

由于面向对象软件自身的特点,使得面向对象的白盒测试有别于传统的白盒测试思想。到目前为止,现有的面向对象软件测试方法还存在许多问题,对面向对象软件的白盒测试技术还有待进一步的深入研究,以便做出对软件测试的理论和实践有指导意义、有影响的成果。

参考文献

[1]LARMAN C.UML和模式应用:面向对象分析与设计导论[M].姚淑珍,李虎,译.北京:机械工业出版社,2001.

[2]JACOBSON I, BOOCH G, RUMBAUGH J.统一软件开发过程[M].周伯生,冯学民,樊东平,译.北京:机械工业出版社,2001.

面向对象的软件测试 篇4

1 面向对象测试与传统测试技术的异同

首先, 这两种技术的测试过程是相同的。都要对整个测试进行计划, 设计出测试用例, 运行测试用例, 根据结果进行测试分析, 最后是用户验收。其次, 这两种技术的测试目标也是相同的。测试的目的都是为了使得设计出来的软件能够达到期望的功能。再次, 测试也是为了用尽可能少的工作量测试出软件尽可能多的错误, 虽然在这三个方面这两种技术都是相同的, 但是在测试计划和设计测试用例的时候是有很大的区别的, 这主要是归结于面向对象软件和传统的软件的设计思路不同。传统的软件是由各个功能模块组成的, 那么在测试计划和设计测试用例的时候就要注意的就是这些功能模块之间的关系。他们之间的关系, 它们之间是调用的关系。而面向对象的软件, 它更加注重的是对象之间的相互交流。它们是通过对象来传递它们之间的消息。这也是在测试计划和设计测试用例的时候需要考虑的, 怎样的测试用例才能够更好使得软件的功能的优缺点体现出来。

2 面向对象测试的意义与现状

类是面向对象软件中最重要的概念, 也是面向对象程序的最基本的组成要素。传统的软件是面向过程的, 软件的推进必须是一个过程完结的输出作为下一个过程的输入, 必须这样按部就班的进行下去。计算机的功能就是模拟人的行为的。这样的一种软件的方法是不能达到前面讲的效果的。人是一种群体动物, 必须是在一个团体下才能够使得事情向更好的方向发展。也就是在团体的作用之下才能使资源更优, 而面向对象方法的出现就是应了这样的需求。类就是实现这种需求的最好方法, 它既可以是对象又可以是事件, 通过类之间的相互作用也达到了这种消息之间的传递。这是因为这种软件方法的改变也就造就了软件测试的改变, 传统的软件测试方法完全不能达到用小的工作量来测试软件的错误。针对软件方法面向对象的软件测试也就应运而生了。而面向对象测试是势在必然的。

3 面向对象测试

3.1 面向对象的测试模型

大家比较熟悉的软件开发模型就是瀑布模型, 它包括了需求分析, 设计, 实现和测试。面向对象的开发模型变为了面向对象分析 (OOA) 、面向对象设计 (OOD) 和面向对象编程 (OOP) 3个阶段。面向对象分析阶段需要做的就是将整个问题总结出来, 转换成计算机能够识别的语言, 那么在这个阶段就需要选择使用什么样的编程语言。在面向对象设计阶段则需要的是选择什么样的类结构, 也就是需要些什么类, 这些类能够完成些什么工作。最后的面向对象编程阶段, 用选定的编程语言来实现设计出来的类结构。这种方法有个很大的优点就是在用户需求发生变化的时候, 能够不改变原有程序。测试模型如图1所示:

从上面的图中可以看出, 对面向对象开发模型的各个阶段都进行了测试的, 对面向对象分析的测试和面向对象设计的测试是非常必要的。如果把软件的前期工作做好了, 那么后续的工作进行的才有意义, 进行完了面向对象编程测试以后, 还有三个非常重要的测试, 就是面向对象单元测试, 面向对象集成测试和面向对象系统测试。其中面向对象单元测试和面向对象集成测试是两个工作量比较大的地方。而最后的面向对象系统测试就是要参考前面两个阶段测试结果了, 主要是以用户的需求为主的。六个阶段的测试是相辅相成的, 但是在每个阶段又有不同, 它们采用的方法也会不尽相同。下面就分别介绍单元测试, 集成测试和系统测试。

3.2 面向对象的单元测试

3.2.1 基础类测试

什么是基础类, 就是我们在面向对象设计时, 设计的类, 这些类可能是些对象, 也可能是些事件, 这里并不包括那些需要继承的类, 就是一些独立的类, 没有任何的消息传递。软件的测试就是要构造测试用例, 构造的这些测试用例必须满足两个条件:前置条件和后置条件。所谓前置条件就是发生这些测试用例要满足什么样的条件, 后置条件就是使用了这些测试用例会产生什么样的后果。测试用例既要满足前置条件又要满足后置条件。在设计测试用例的时候需要根据状态转换图, 因为状态转换图中的节点代表的是状态, 而节点与节点之间的连线则表示的是一个动作, 而测试用例就是需要了解如何促使这些动作发生。满足这些动作的发生应该是在一定的范围进行的, 那么对于临界值的设计是至关重要的, 在选择测试用例的时候临界值是非常好的一个标志。设计好了测试用例需要的是怎样来使它运行, 那么就还需要一个测试用例驱动程序。测试用例驱动程序主要的工作就是运行测试用例和得到运行结果。目前用的最多的测试驱动程序是Tester类。Tester类是抽象的概念, 使用这个类的最大好处就是能够为所有的测试人员提供默认的实现。测试人员可能会有如下的操作:运行其他所有类的测试驱动程序的公共函数, 记录下这些测试用例的结果, 必须运行所有要测试的类的测试用例, 检查所有类的所有常量。具体的Tester类主要负责实现测试用例的方法, 并将它们作为测试系列不可缺少的一部分来运行。

3.2.2 交互对象测试

面向对象的程序顾名思义就是由很多的对象构成的, 这些对象相互作用来解决某类问题的。程序中的这些对象有条不紊的相互工作这是这个程序成功的关键。完成了上面提到的单元类的测试, 那么交互对象测试则是为了这些单元类之间的消息传递能够正常的进行。交互测试有两种方法:一种是把设计的测试用例嵌入到程序的交互对象中去, 另一种方法则是用上面提到的Tester类提供的测试环境, 在这个环境下使得对象之间相互作用。这种测试的前提条件就是发送对象能不能够满足接受对象的要求。单位类测试的时候采用了临界值的方法, 这里是一些动作的发发生, 临界值的方法不并不适用。如果采用穷举的方法, 那么工作量将会变得很大, 也有可能出现无穷的情况, 交互对象的测试采用的是正交阵列的方法, 这种方法就是从影响交互对象的所有因素中选出那些对所有交互对象都有影响的子集中来确定测试用例。

如何选出这个子集是正交阵列提供的一种特殊方法, 该方法首先要设计出交互对象配对的方法, 选择的组合方式必须要限制组合数量的急剧递增。正交阵列就如下表1所示是一个数值矩阵。表中的每一行都是一个变量, 这个变量在测试的软件中就是表示的那些具有相同特性的类群。变量则会有一定的取值, 每一个取值则代表了某一个特定的类。把每个变量的所有取值都列举出来就成为了一个矩阵, 也列举出了所有可能的情况。

3.2.3 层次结构类测试

面向对象程序有一个很重要的特征就是继承, 继承的好处可以减少工作量, 不会使得工作变得冗余, 大大的提高程序的性能, 这是因为这些特点也使得继承具有一定的缺点, 那就是错误的传播率提高。继承是面向对象软件新出的概念, 那么在测试的时候对这一部分怎样设计测试用例是新的问题。如果对某个类的父类已经做了完整的测试, 那么对它的子类如何进行测试呢, 为了达到测试的目标就是用尽可能少的工作量来完成测试, 那么就需要复制对父类的某些测试部分, 又因为子类不仅仅继承了父类还有自己一些新的动作或者规范, 因此除去复制的部分再添加一些对新的动作或规范起作用的测试部分即可。这样就会大大的提供工作效率。

3.3 面向对象的集成测试

面向对象的集成测试即涉及到面向对象的结构集成又涉及到面向对象的功能集成。要实现结构和功能的集成则会有类之间的关联、聚合、多态、继承。那么在测试的时候可以分成以下几种情况:

1) 关联和聚合关系的测试:将所有具有关联和聚合关系的类放到一起, 这里不需要涉及新的测试用例, 只需要找到这些类中哪个类是最开始发出动作的, 最先发出动作类的测试用例作为这种关系的测试用例, 应用驱动程序来运行这个测试用例, 观察类之间的消息传递情况。

2) 继承关系的测试:在前面的层次结构类中提到了继承关系的测试, 参照前面的方法即可。

3) 多态/动态绑定的测试:面向对象中的多态增加了程序的运行路径的多样性, 那么在设计测试用例的时候就要考虑到这个因素, 由于运行的轨迹不同那么测试用例的设计可能就会出现变化。那么测试用例的数量就会发生变化, 应该包括所有的执行路径。

3.4 面向对象的系统测试

面向对象的系统测试和传统的系统测试是一样的, 都是为了验证设计出来的软件有没有达到用户的需求, 在满足了用户需求的前提下再考虑软件的性能是不是满足了最开始面向对象分析时提出的要求。系统测试的时候可以采用传统的系统测试的方法, 但是在设计测试用例的时候还是会有不同的, 测试用例的设计还是需要考虑从对象入手。

4 总结

通过对面向对象测试过程方法的分析, 根据本文中的图1就可以了解到测试并不是和开发过程分开的, 它们之间是密不可分的。在整个开发过程要随时都做到随时测试, 这样做的好处就是能够尽早的发现问题, 这样就会及时作出修改。该文中提到了很多解决不同阶段的测试方法, 但是这些都是在理论层次的探讨, 在实施的过程中仍然会遇到这样或那样的问题, 因此后面的研究就着重在如何使理论和实际达到高度的统一。

摘要：软件的测试时软件开发的重要部分, 是保证软件质量提高软件性能的关键。面向对象的软件测试具有它自己的特点, 需要与传统的软件测试相区别, 因此面向对象的软件测试则被分成不同的阶段, 本文将面向对象软件测试层次划分为六个个层次, 主要介绍了面向对象软件测试的以下三个层次:类测试、集成测试和系统测试。

关键词：面向对象,单元测试,集成测试,系统测试

参考文献

[1]武海丽.面向对象的软件测试[J].中国高新技术企业, 2008 (12) .

[2]李伟龙.面向对象的软件测试[J].科技资讯, 2008 (26) .

[3]刘维光.面向对象软件测试的方法研究[J].电脑知识与技术, 2006 (29) .

面向对象测试模型论文 篇5

关键词：UML,测试用例,类测试,面向对象,状态图

1 引言

面向对象软件测试的主要目标与传统软件测试目标相同,既是用最小的工作量发现最多的错误。由于面向对象所独有的多态、继承、封装等新的特点,使面向对象测试的策略和技术与传统测试有所不同,测试的视角扩大到包括复审分析和设计模型,测试焦点从模块转向类。类是构成面向对象程序的基本成分,类的测试无疑成为面向对象测试的重要环节。基于对象状态的测试是根据被测试的类的对象所处的状态以及状态之间的转移来构造测试用例,它侧重于对象的动态行为,这种动态行为依赖于对象状态。测试对象动态行为能检测出对象成员函数之间通过对象状态进行交互式产生的错误。

2 基于对象状态的测试方法的发展

现在面向对象测试中基于对象状态的测试方法一般是采用扁平状态机和状态迁移图。扁平状态机能很好的提示出一些类中的错误,但是随着类的状态属性的增加,对象状态的数目会迅速膨胀,大大增加测试的复杂度。状态转移图用于刻画对象响应各种事件时状态发生转移的情况,容易借助于自动机理论来选择测试时所用的时间序列和预测对象的状态变化结果序列,但是,它难于描述继承的对象动态行为、并发的动态行为以及由数据成员和成员函数构成的对象状态和对象状态转移。基于UML的状态图可以很好的描述对象动态行为、并发的动态行为,可以把状态的复杂度控制在和状态属性相关的线性级别,下面我们主要介绍利用UML状态图如何描述对象动态行为、并发的动态行为,以及如何产生测试用例。

3 UML状态图

UML状态图(State Diagram)是UML中对系统的动态行为进行建模的表示方法,它包括对反应型对象的行为建模。它展现了对象生命周期内可能处于的状态以及在这些状态间转换的激发条件。UML状态图中引起状态迁移的原因通常有两种,一种是在状态图中相应的迁移上未指明事件,这表示当位于迁移箭头源头的状态中的内部动作全部执行完后,该状态迁移被自动触发;另一种是,当出现某一事件时会引起状态的迁移,在状态图中把这种一起状态迁移的事件标在改前一的箭头上,如图1。

状态迁移的形式化语法为:

event_signsture[guard_condition]/action_expression^send_clause

其中事件特征event_signsture是由事件名后括号括起来的参数表组成,它指出触发迁移的事件以及与该事件相连接的附加数据。guard_condition警戒条件是一个布尔表达式,如果状态迁移中既有事件又有警戒条件,则表示仅当这个事件发生并且警戒条件为真时,触发状态迁移。动作表达式action_expression是一个触发状态迁移时可执行的过程表达式,表达式中可引用该状态所拥有的对象中的属性、操作或事件特征中的参数。发送子句send_clause是动作的一种特殊情况,用来说明在两个状态的迁移期间发送的消息。

UML状态图的优点在于它支持嵌套和并发。UML状态图中包含基本状态(basic state)和复合状态(composite state),复合状态分为或状态(or-state)和与状态(and-state)。或状态的子状态之间是相互排斥的或关系,表示在任一时刻这些子状态中只有一个子状态为真;与状态的子状态之间是并发的非相互排斥关系,与状态表示一个状态可以有多个并发的子状态,并发子状态之间用虚线分隔,用虚线分隔的每个区域表示一个并发的子状态。把状态属性看成并发的子状态,从而可以把状态图的复杂度控制在线性级别上。并发状态图中一个事件可能引起多个子状态的状态迁移。如图2中的CVM就是一个或状态,它的子状态OFF和ON之间是相互排斥的关系,ON状态就是一个与状态,当处于ON状态时,就意味着同时处于COFFEE和MONEY两个子状态。

由于UML状态图支持嵌套和并发,这就使得它比以往的状态转移图能更好的描述继承的对象动态行为、并发的动态行为以及由数据成员和成员函数构成的对象状态和对象状态转移。UML状态图中可以包含复合状态这就使得它可以把状态的复杂度控制在和状态属性相关的线性级别。下面我们讨论如何从UML状态图构造一棵复合状态测试树。

4 构造复合状态测试树

与以往的测试树不同的是复合状态测试树的每个节点代表对象的复合状态既对象的各个属性的集合,边表示状态间的迁移,根节点代表对象的初始属性集合。

构造一个队列queue来存放复合状态测试树的各个节点。

1)把UML状态图的起点读入队列queue。

2)以UML状态图的起点定义根节点Test Tree root,同时把节点标识tree Node置为对象的初始状态,nodelevel置为0,t和child Tree置为NULL,把root放入队列中。

3)取队列头部的节点设为head,搜索从head节点所对应的状态(head.tree Node)发出的状态前移以及前移置的目标状态,分别填充head.t和head.child Tree,即把迁移至的状态作为head的子节点;同时置好各个子节点的属性值,node Level=head.node Level+1,从root节点开始层次遍历测试树(从第0层至head.node Level层),如果在head的子节点中存在某个节点n,其所对应的状态已经在第0层至head.node Level层中出现过,则该节点n不再扩展,即为叶子节点。把其他没有出现过的子节点加入到队列的尾部。

4)head指向队列中的下一个节点,重复第二步,直至队列为空。

在3)中,如果某个迁移对应的目标状态已经在测试树中出现过,就不再考虑这个状态,不加入到队列尾部。这样有效地避免了重复构造节点,同时又不降低测试的覆盖率。通过上述步骤就可以构造出UML状态图对应的测试树。

复合状态树构造算法能很好的支持多个并发的子状态的情况,只是节点表示为并发子状态的合集;如果某个事件触发其他事件从而引起一系列的状态迁移时,只要把最终的状态作为节点加入到测试树中。比以往的插入桩模块更容易实现。

通过测试树可以很容易的构造出测试用例。从根节点开始沿着各个分支往下知道叶子节点,每条这样从根节点开始到某个叶子节点结束的路径上的事件按顺序组合在一起,就成为基于对象状态测试的一个测试用例。如果增加对象属性可以很容易的在复合状态测试树中增加,增加属性后可以把状态的复杂度控制在和状态属性相关的线性级别,测试时不仅可以单独的对对象的每一个属性和所有属行进行测试,也可以对对象的所有属性任意选择组合进行测试。大大增加了测试的灵活性。

5 结束语

UML的状态图支持潜逃和并发,把状态的复杂度控制在和状态属性相关的线性级别;其次UML状态参数图是在面向对象软件开发的生命周期中的早期设计阶段确定的,是对对象状态的完整的描述,并不依赖于源代码,既保证了状态描述的完整性,又可以在开发早期进行测试,尽早发现与状态相关的错误,避免将错误带入到后面的开发阶段。因此可以用UML的状态图来产生有效的测试用例,这大大提高了测试的灵活性和有效性。

参考文献

[1]张克东,庄燕滨.软件工程与软件测试自动化教程[M].北京:电子工业出版社,2002.

[2]刘金艳,蔺娟茹,尹治本.面向对象软件测试的探讨[C]//2002年全国软件与应用学术会议(NASAC)论文集.北京:机械工业出版社,2002:262-266.

[3]杨小平.面向对象软件测试探讨[J].计算机工程与应用,2000,36(1):44-46.

[4]姬莹,罗钧昊,钟联炯.面向对象软件测试主要问题的探讨[J].西安工业学院学报,2001(1).

[5]Fewster M,Graham D.软件测试自动化技术与实例详解[M].舒智勇,译.北京:电子工业出版社,2000.

[6]叶仁召,郑玉墙,鲁汉榕.面向对象软件测试及度量的研究[J].计算机工程与设计.2001,22(4):21-24.

面向对象数据库模型研究 篇6

面向对象的数据库经过十几年的发展, 已经日趋成熟, 有关的国际标准相继出台。ODMG (OMG所属的对象数据库管理组) 分别于1993, 1997, 2000年提出了对象数据库标准O D M G 1.0, O D M G 2.0, O D M G 3.0, 制定ODMG标准的目的是为了让ODBMS的用户编写的可移植的应用, 能运行在多个OODBMS的产品上。本课题的接口实现部分就是参照ODMG标准来实现。

ODMG对象模型主要包括以下基本概念。

(1) 数据建模的基本原语是对象 (Object) 和文字 (Literal) , 每个对象有一个唯一的标识符, 文字没有标识符。

(2) 对象和文字都可以划分为类型 (Type) , 同一类型的对象或文字具有相同的行为和状态, 对象可以称为类型的实例。

(3) 通过一组性质 (Property) 来定义对象的状态, 性质可以分为两种:对象的属性 (Attribute) 和对象之间的关系 (Relationship) 。

1 对象与对象标识

1.1 对象结构

对象是由一组数据结构和在这组数据结构上的操作的程序代码封装起来的基本单位。对象之间的界面由一组消息定义。一个对象包括以下几个部分。

(1) 属性集合:所有属性合起来构成了对象数据的数据结构。属性描述对象的状态、组成合特性。对象的某一属性可以是单值的或值的集合, 进一步地, 一个对象的属性也可以是一个对象, 即对象可以嵌套, 从而组成各种复杂对象。

(2) 方法集合:方法描述了对象的行为特征。方法的定义包括两部分, 一是方法的接口, 二是方法的实现。方法的接口用以说明方法的名称、参数和结果返回值的类型, 也称之为调用说明。方法的实现是一段程序代码, 用以实现方法的功能。

(3) 消息集合:消息是对象向外提供的界面, 消息由对象接收和响应。面向对象数据模型中的“消息”与计算机网络中传输的消息含义不同。它是指对象之间操作请求的传递, 而不考虑操作实现细节。

1.2 对象标识

面向对象数据库中的每个对象都有一个唯一的不变的标识称为对象标识 (OID) 。对象通常与实际领域的实体对应。现实世界中, 实体的属性值可能随着时间的推移会发生改变, 但是每个实体的标识始终保持不变。相应的, 对象的部分 (或全部) 属性、对象的方法会随着时间的推移发生变化, 但对象标识不会改变。

1.3 封装

OO模型的一个关键概念就是封装。每一个对象是其状态与行为的封装。

封装的意义在于将对象的实现与对象的应用互相隔离, 从而允许对操作的实现算法和数据结构进行修改, 而不影响接口, 不必修改使用它们的应用, 这有利于提高数据独立性。

2 类和类层次

在OO数据库中相似对象的集合称为类。每个对象称为它所在类的一个实例。一个类中所有对象共享一个定义, 它们的区别仅在于属性取值不同。可以看到, 类的概念类似关系模式, 类的属性类似关系模式中的属性:对象类似元组的概念, 类的一个实例对象类似关系中的一个元组。可以把类本身也看作一个对象, 称为类对象 (Class Object) 。

3 面向对象数据库的模式演进

面向对象数据库模式是类的集合。模式为适应需求的变化而随时间变化称为模式演进。模式演进包括创建新的类、删除旧的类、修改类的属性和操作等。在关系数据库系统中, 模式的修改比较简单, 主要有如下的模式修改操作。

(1) 创建或删除一个关系。

(2) 在关系模式中增加或删除一个属性。

(3) 在关系模式中修改完整性约束条件。

OODB应用环境对OODB模式演进提出了许多新的要求, 使得面向对象数据库模式的修改要比关系模式的修改复杂得多, 其主要原因有以下几点。

(1) 模式改变频繁。

使用O O D B系统的应用通常需要频繁地改变O O D B数据库模式。例如O O D B经常运用于工程设计环境中, 设计环境特征之一就是不断变化.设计自身在不断变化, 以纠正错误或修改设计使之更完美、更适合于实际:而当设计者对问题及其解决有更深刻理解时也会修改模式。

(2) 模式修改复杂。

从上面讲解的OO模型特征可以看到OO模型具有很强的建模能力和丰富的语义, 包括类本身的语义、类属性之间和类之间丰富的语义联系, 这使得模式修改操作的类型复杂多样。此外, OODB中模式演进往往是动态的, 动态模式演进的实现技术更加复杂。

3.1 模式的一致性

模式的演进必须要保持模式的一致性。模式的一致性是指模式自身内部不能出现矛盾和错误, 它由模式一致性约束来刻画。模式一致性约束可分为唯一性约束、存在性约束和子类型约束等, 满足所有这些一致性约束的模式则称为是一致的。

(1) 唯一性约束, 这一类约束条件要求名字的唯一性。

(2) 存在性约束, 存在性约束是指显式引用的某些成分必须存在。

(3) 子类型约束。

3.2 模式演进操作

下面给出一些主要的模式演进操作, OODBMS应该支持这些模式演进。

(1) 类集的改变; (2) 己有类的成分的改变; (3) 子势超类联系的改变。

3.3 模式演进的实现

模式演进主要的困难是模式演进操作可能影响模式一致性。面向对象数据库中类集的改变比关系数据库中关系模式的改变要复杂得多。因为类的修改操作可能会影响到其它类的定义。例如, 改变了一个类的属性名, 这需要所有使用该属性的地方都要改名。

因此, 在OODB模式演进的实现中必须具有模式一致性验证功能, 这部分的功能类似编译器的语义分析。进一步, 任何面向对象数据库模式修改操作不仅要改变有关类的定义, 而且要修改相关类的所有对象, 使之与修改后的类定义一致。所谓转换的方法是指在OODB中, 己有的对象将根据新的模式结构进行转换以适应新的模式。例如, 在某类中增加一属性时, 所有的实例都将增加该属性。这时还要处理新属性的初值, 例如给定一缺省初值, 或提供一算法来自动计算新属性初值, 还可以让用户设定初值。删除某类中一属性时只需要从该类的所有实例中删除相应属性值即可。

参考文献

[1]数据库系统基础Ramez Elmasri[M].人民邮电出版社.

面向对象的软件类测试技术的研究 篇7

随着面向对象技术的广泛应用和发展,软件测试技术也在逐步成熟。在传统软件测试中,软件测试工作仅是对简单计算机代码进行“调试”工作。而随着面向对象技术的提出和应用,传统的软件测试技术已经无法满足面向对象技术中关于多态、继承、封装等特点的要求,从而提出了面向对象软件测试技术。

在面向对象技术中,最重要的概念就是类。我们以往所使用的传统测试方法,是一种面向过程的测试方法,只完成对方法的测试,并不适用于面向对象技术中类的整体测试。因此,在面向软件测试技术中,提出了类测试的概念。本文将从类的特点出发,对面向对象的类测试技术作进一步的研究。

2 类测试技术

类测试是针对面向对象技术中类的概念而提出的,其目的是为了保证一个定义的类能够完成其定义以内的功能,确保类中方法的实现,将类的使用风险降到最低。

类测试按测试的顺序可分为以下三个部分:

1)基于服务的测试:测试类中的每一个服务;

2)基于状态的测试:考察类的实例在其生命周期各个状态下的情况;

3)基于响应状态的测试:从类和对象的责任出发,以外界向对象发送特定的消息序列的方法来测试对象的各个响应状态。如图1所示。

3 面向对象的软件类测试技术

类测试有很多种方法,如:等价划分测试、基于层次增量、基于服务、基于状态、基于流程、基于数据流的类测试。这里详细介绍基于服务的和基于状态的类测试,通过对这两种类测试的介绍,了解类测试的思想和方法。

3.1 基于服务的类测试技术

基于服务的类测试主要考察封装在类中的一个方法对数据进行的操作。类测试若采用传统的白盒测试,很可能会带来测试用例选取的盲目性。测试人员的个人喜好和倾向性,也会使得选取的测试用例存在一定的局限性。块分支图,作为一种基于服务的类测试模型,能够比较好的克服测试中的盲目性和局限性,保证软件测试的质量。

3.1.1 类的服务的测试模型

由Kung等人提出的块分支图(Block Branch Diagram,简称BBD)是一种性能比较好的基于服务的类测试模型,如图2所示。

服务f的BBD是一个5元组。BBD f=(Du,Dd,P,Fe,G)

其中:Du={di|di是f引用全局数据或类数据};Dd={di|di是f修改了的全局数据或类数据};P=X1θ1,X2θ2,…,Xnθn;Xn+1θn+1分别是f的参数表和函数返回值,θi为↓(表示输入)、↑(表示输出)或↓↑(表示输入/输出)。若Xn+1缺省,则无返回值;Fe={fi|fi是被f调用的其它服务}

G是一个有向图,叫做块体。它是按照控制流图的思想,修改f的程序流程图而来,表示了f的控制结构。f中的复合条件判断被分解,每个判断框只有单个的条件。

BBD通常有两种获取途径。一是采用逆向工程的方法,由源程序画出流程图构造出BBD。但这并不是最好的方法,当源程序不正确时构造出来的BBD是错误的。另一种途径是在软件的分析设计阶段构造出相应的BBD,能根本解决问题,正确指导类的服务的测试。

3.1.2 类的服务的测试策略

根据BBD模型,可对服务进行结构测试和功能测试两种测试。

1)结构测试:主要进行基本路径测试,根据软件过程性描述中的控制流程确定复杂性度量,然后用此度量定义基本路径集合,导出一组测试用例。

2)功能测试:等价类划分和边界值分析是两种很有效的功能测试方法。但这两种方法只针对数据集中的孤立数据进行测试,为考虑多组数据组合的情况,我们以判定表或判定树为工具,列出输入数据的各种组合情况和程序相应动作(以及可能的输出结果)之间的对应关系,为判定的每一列至少设计一个测试用例。

3.2 基于状态的类测试

同传统的控制流和数据流测试相比,对象状态测试侧重于对象的动态行为,这是一种依赖于对象的状态。当对象成员函数之间通过对象状态进行交互时可能会产生一些错误,测试对象的动态行为就可以检测出这些错误,基于状态的类测试就是这样一种通过测试对象的动态行为检测错误的测试方法。

下面举例使用状态转移图建立对象的动态行为模型,用以刻画对象响应各种事件时状态发生转移的情况。如图3所示,图中每个结点表示对象的某个可能状态,结点之间的有向边通常用“事件/动作”标出。当对象处于状态A时,若接收到考察事件e则执行相应的操作a同时转移到状态B。如此,对象的状态就随各种外来事件发生了变化,这是对象行为的一个重要方面。

基于状态的测试是检查对象的状态在执行某个方法后是否会达到预期的一种测试技术。对象状态的变化是通过对象的数据成员值体现出来的,实现对象数据成员值的跟踪监视,即完成了对象状态的检测。要检测对象多个数据成员的状态需要对对象的状态空间进行划分,这类似于黑盒测试中划分等价类的方法,并在对象的数据成员的取值域中找到特殊值和一般性区间,分别对其进行测试。进行基于状态的测试时,首先要对受测试的类进行扩充定义,增加一些用于设置和检查对象状态的方法。另一项重要工作是编写主控的测试驱动程序,如被测对象在执行某个方法时还要调用其他对象的方法,则需编写程序代替其他对象的方法。

4 结束语

面向对象软件类测试技术的研究是面向对象开发的重要一环。从目前对面向对象测试的研究现状来看,现有的类测试方法还存在一些问题。深入研究类测试技术,解决现有问题,对面向对象软件测试技术具有十分重大的指导意义。

参考文献

[1]赵荣利,崔志明,陈建民.面向对象软件测试的技术研究[J].苏州大学学报:工科版,2007,21(1):35-38.

[2]Grady Booch.面向对象分析与设计[M].冯博琴,冯岚译.北京:机械工业出版社,2003.

[3]朱少民.软件测试方法和技术[M].北京:清华大学出版社,2005.

[4]钱乐秋,赵文耘.软件工程[M].北京:清华大学出版社,2007.

基于纯面向对象的海战模型库研究 篇8

随着计算机仿真技术的飞速发展,对海军作战仿真模型研究的日益深入,我军广大科研人员研制开发了大量的作战仿真模型,随之而来,模型开发费用、开发效率、开发质量、开发可信性及可靠性的控制等变得越来越困难了。对相同或相似的军事问题,研发人员做着大量重复的工作,多数研制开发都是从零开始,无法或很少重用已有的成果,模型的研制开发始终不能摆脱这种手工作坊的研发方式。为了更加有效地对已有海战模型进行管理和重用,同时也为了加快建模速度,需要建立一个模型库管理系统来对海战模型进行管理,军内外已对此类问题进行了大量的研究工作,但多数研究的可操作性小,问题没有得到很好的解决。考虑到数据库及其管理系统技术中的完美重用结构,我们决定借用数据库的重用思想,来建立海战模型库管理系统,然而对于与现实世界紧密联系的模型,目前在数据库领域占据绝对优势的关系数据库则显得无能为力,本文通过使用纯面向对象数据库及其管理技术建立海战模型库管理系统,以求解决海战模型的表示、存储、使用和运行等问题。

二、纯面向对象数据库技术

2.1面向对象数据库

面向对象是一种认识方法学,也是一种新的程序设计方法学。把面向对象的方法和数据库技术结合起来可以使数据库系统的分析、设计最大程度地与人们对客观世界的认识相一致。20世纪80年代已开始出现一些面向对象数据库的商品和许多正在研究的面向对象数据库。多数这样的面向对象数据库被用于基本设计学科和工程应用领域。与关系数据库不同,面向对象数据库不因数据类型的增加而降低处理效率。

面向对象数据库从面向程序设计语言的扩充着手使之成为基于面向对象程序设计语言的面向对象数据库。例如:ONTOS、ORION等,它们均是C++的扩充,熟悉C++的人均能很方便地掌握并使用这类数据库。

2.2纯面向对象数据库的特点

本文使用的面向对象数据库是美国加州硅谷的开源面向对象数据库公司db4objects研制的db4o,它是纯面向对象的数据库,具有如下良好性能:

(1)支持面向对象数据模型

面向对象数据库系统支持面向对象数据模型,简称OO(Orient Object)模型。也就是说,一个面向对象数据库系统是一个持久的、可共享的对象库存储和管理者;而一个对象库是由一个OO模型所定义的对象的集合体。面向对象数据库模式是类的集合。面向对象的数据模型提供了一种类层次结构。在面向对象数据库模式中,一组类可以形成一个类层次。一个面向对象数据库可能有多个类层次。在一个类层次中,一个类继承其所有超类的全部属性、方法和消息。

面向对象的数据库系统在逻辑上和物理上从面向记录上升为面向对象、面向可具有复杂结构的一个逻辑整体。允许用自然的方法,并结合数据抽象机制在结构和行为上对复杂对象建立模型,从而大幅度提高管理效率,降低用户使用复杂性。

关系数据库是一种很灵活而且使用简便的数据库。但是,它不能表示复杂的对象,也不具备定义复杂操作的能力。面向对象的数据模型由于可以表示复杂的数据类型,它能适用于一些关系模型不能适用的复杂应用领域,如一些要表示抽象的数据类型像海图、水源、建筑物等的领域。而且它对实体的描述比关系模型更加现实、自然,更加直观。因此,面向对象的数据模型更适合描述海战模型。

(2)支持对象嵌套

在同一个面向对象数据库模式中,对象的某一属性可以是一个对象,这样对象之间就产生一个嵌套的层次结构。例如:设Obj1和Obj2是两个对象,如果Obj2是Obj1的某个属性的值,称Obj2属于Obj1,或Obj1包含Obj2。一般的,如果对象Obj1包含Obj2,则称Obj1为复杂对象或复合对象。

对象嵌套概念是面向对象数据库系统的一个重要概念,它允许不同的用户采用不同的粒度来观察对象。对象嵌套层次结构和类层次结构形成了对象横向和纵向的复杂结构。

(3)真正的原生查询

db4o是真正的原生面向对象数据库,直接使用编程语言来操作数据库。程序员无需进行OR映射来存储对象,大大节省了程序员在存储数据的开发时间,同时带来高效的数据查询,根据官方公布的基准测试数据,db4o比采用Hibernate/MySQL方案在某些测试线路上速度高出44倍之多,并且安装简单,仅仅需要400Kb左右的jar或dll库文件。

db4o能实现真正的原生查询,查询语句用实现语言(Java或C#)完全表达,并完全遵循实现语言的语义,db4o查询语句能运行在自己的实现语言中,允许未经优化执行普通集合而不用自定义预处理。db4o查询还实现了100%的类型安全查询,能完全获取现代IDE的特性,比如语法检测、类型检测、重构等。

三、纯面向对象模型库管理系统设计

3.1模型的原子化处理

海战模型是研究海军军事问题模型。能否充分有效地运用、组织和管理好众多海战模型,也是能否充分提高海战决策高效、科学的关键,也是构造可重用海战模型结构的关键因素。而模型结构是解决这些关键问题的基础,通过对海战的各类模型进行深入研究发现:无论哪类模型都是用某些特定的方法对描述问题的一组特征数据进行处理,给出有价值的处理结果,提供给决策者并辅助其进行有效的决策,从而海战模型可以表述为:描述或解决某个问题所需的一组特征数据与解决这个问题所需的操作或方法的结合。由于此模型概念具有对象的特征,很容易以OOP技术进行实现,称之为模型对象。

为了能够实现对海战模型的高效管理,需要对模型进行原子化处理,原子化包括层次化和组件化。层次化要求对模型进行详细的分类,组件化要求将模型最终划分为不需要进一步分解的原子模型,然后在此基础上组合成用户所需要的组合模型,具体步骤如下:

首先对模型的类型进行层次化的分类,将海战模型根据应用层次进行进一步的分类,然后在类型分类的基础上可以提出具体可应用的模型,接着对应用模型进一步分解,最终得到不能够或不必要进一步分解的模型称为原子模型。这样就将模型分为了三个层次,分别为模型类型层、应用模型层和原子模型层,便于存储管理。对于单个模型,本系统采用面向对象的模型表示。

模型可以表示成一个三元组的形式:{M_id,M_attribute,M_operation}。

其中M_id是模型的标识符,相当于身份确认;

M_attribute用于描述模型的各类属性。对于组合模型还需要增加两类属性(子模型列表和子模型参数信息)。子模型列表包括组成该组合模型的各子模型的顺序信息,子模型参数信息是组成组合模型时子模型的接口信息;

M_operation描述模型的操作,包括模型的集成、调用、运行等操作。之所以采用这个方法是因为很多大型装备有共同之处,可以用少数子模型组合出大量整体模型,减少了库中的储存量。本文是以航空兵的装备为主要研究对象,例如实体可分为武器、飞机等。在飞机中的模型有歼击机、侦察机、轰炸机等。歼击机模型与轰炸机模型可以通用一种动力系统,所以存储时只用存储动力系统和两个武器系统。行为有机动行为、起飞行为、降落、发射导弹等行为。

3.2模型重构的实现

模型重构是指一些简单的子模型组合成所需的复杂模型。这个过程是由模型管理系统通过对模型进行组合分解完成的。接口间的关系是模型进行组合的依据,是模型组合信息的重要内容,通过关系的改变可以完成对模型的组合。组合之后的新模型要进行测试验证。功能属性符合要求、运行正常的模型就可以注册运行。重构技术减少了库中模型的存储量还可以让战场仿真中的指挥员查看装备的某些部分,即子模型的情况。

本文的模型定义将明确地区分属性与方法,例如,某舰艇对空防御模型由描述舰艇的实体模型(描述舰艇的基本属性,如物理属性、动力性能、装备配载等)和一系列动作模型(预警探测、机动行为、对空抗击、电子干扰等)组成。其中既有元模型也有组合模型,如图1所示。

3.3模型库接口设计

模型库管理系统中,模型库与其他系统紧密联系,需要建立接口关系,以便接收到访问请求,调用请求,进行模型传输等。接口类型有:模型库与内部数据库的接口,模型库与外部系统的接口。对于不同的系统接口设计不同。接口关系在模型库系统中起着重要的作用,只有通过这些接口模型库系统才能够与其它模拟系统进行交互,没有这些接口,模型库管理系统将无法提供服务。对于不同的模拟系统,由于服务的要求有所不同,所以接口的设计也会不同。其与外界建立联系的过程大致如下所述:应用系统调用模型库中模型时,向模型库管理系统发出请求命令,在模型库管理系统接收到应用系统的请求后,向内部数据库和实体模型库发送相应命令,实体模型库收到命令后在库中进行相应配置,然后通过接口向应用系统发送模型,向应用系统发送与最终输出模型相关的数据,应用系统在接收到模型和与模型相关的数据后,向模型库管理系统发送一个确认。上述过程是由模型库提供的接口函数实现的。接口函数又可分为与内部数据库接口的数据接口函数和与实体模型库接口的模型接口函数两种,是通过链接动态链接库完成。

例如:实现接口调用的类class CDbModel有一个函数GetComponent功能是得到实体的一部分,函数int GetModelIndex功能得到实体模型号

3.4模型存储设计

模型库是系统的核心部分,在逻辑上模型库是各种模型的集合,在内容上则由许多概念模型和仿真程序模型组成。根据本系统的需要,模型的存储采用“文件+模型字典”的方式,即模型主要以文件形式存储,但把模型的主要信息抽取出来放入模型字典中,通过模型字典对模型库中的模型进行管理。

模型库中存储的文件包括文档和代码文件,代码文件由源码库、目标代码库两部分组成。源码库存储的内容包括模型详细文档、模型程序源码文件;目标代码库存储编译完成的动态链接库、COM组件文件和可执行文件等。

模型字典用来存放有关模型的描述信息(如功能、性能、限制、约束、参数等)和模型的数据抽象。这里所谓模型的数据抽象是模型关于数据存取的说明,这部分是系统管理模块对数据库存取数据的需要。模型字典中有关模型的详细说明可作为用户和系统人员查询模型库内容之用,也是模型查询的数据来源。

此外,模型字典中有关模型的详细说明可作为用户和系统人员查询模型库内容之用,也是模型查询的数据来源。

3.5模型字典设计

模型字典是模型库管理系统的核心,模型库管理系统通过模型字典有效地组织和管理各种模型元数据以及其他相关文件,从而实现对模型资源的有效管理。在本系统中,设计的模型字典主要包括如下信息:

(1)模型名、模型类型、模型原理、适用条件、使用方法、所属模型库、开发信息、使用信息、相关模型;

(2)源程序文件、中间目标文件、可执行文件、实现语言、编译系统;

(3)函数编号、函数名、函数功能、函数类型、实际变量数;

(4)变量序号、变量名、变量含义、变量类型。

模型库有关文献讨论了基于关系数据库的模型库管理系统,提出用关系数据库进行管理模型,考虑到模型字典的内容和形式,模型字典作为模型描述信息的特殊数据库,用面向对象数据库进行管理无疑是非常合适的,事实上模型库管理系统是通过以上形式的模型字典对各种模型元数据和相关文件进行有效的组织和管理的。

四、模型库管理系统实现

我们在Windows xp操作系统环境下,使用Microsoft Visual C#和DB4O作为开发工具,研制开发了海战模型库管理系统,它由模型库服务端程序和客户端程序两部分组成。

模型库服务端程序主要实现模型的维护、调用、查询、运行等的集中控制,由存取管理、运行管理两大模块组成。存取管理模块实现对模型的组织、入库、更新、删除、检索、验证等,而运行管理模块则实现对模型的调用、运行等的功能。模型服务器以科学、合理、切实可行的方式完成对本地或异地的各模型所在的服务器及服务器中所具有的模型的注册、维护、组织、管理、调度、使用与控制,同时在为用户提供服务过程中兼顾模型封闭运行和专家参与两个方面。

模型库客户端程序主要实现用户输入界面和结果信息的输出,是用户和模型库交流的窗口。

海战模型库管理系统的信息流程见图2。

五、结束语

基于用例模型的面向对象需求分析 篇9

软件需求分析工作主要目的就是分析软件用户的需求是什么,它是软件开发中的重要一步。只有通过需求分析,才能把软件功能和性能的总体概念描述为具体的软件需求规格说明书,从而奠定软件开发的基础。研究表明,在需求阶段检查和修复一个错误所需的费用只有编码阶段的l/5到l/10,而在维护阶段做同样的工作所付出的代价却是编码阶段的20倍。这就意味着在需求阶段和维护阶段修复一个错误的比值可高达1:200。由此可以看出,需求分析在整个软件生命周期是非常重要的。做好需求的分析和管理,既可以减少软件开发中的错误,还可以减少修复错误的费用,从而大大降低软件开发成本,缩短软件开发时间。

二、需求分析存在的问题

软件开发常常是一个专业领域的人在为另一个专业领域的人服务,但开发出来的软件往往与用户的需求有偏差,用户往往在看到最终交付的产品时才真正明确自己的需求。软件开发人员经常会遇到这样的问题,客户对自己系统的需求从一开始就是含糊的并且总以为随着时间的推移就能对细节进行澄清改变和补充也就是说客户在软件开发的过程中可能经常改变系统需求,软件开发过程中需求更改可能是最常见的错误但也是修改花费最昂贵的错误。

三、UML的面向对象建模技术

统一建模语言UML是一种通用的可视化的建模语言,用于对软件进行描述、可视化处理,构造和建立软件系统的文挡。适用于各种软件开发、软件生命周期的各个阶段、各种应用领域以及各种开发工具,是一种总结了以往建模技术的经验并吸收了当今优秀成果的标准的建模方法。

面向对象的建模,就是把系统看作是相互协作的对象,这些对象是结构和行为的封装,都属于某个类,那些类具有某种层次化的结构。系统的所有功能通过对象之间相互发送消息来获得。面向对象的建模可以视为是一个包含以下元索的概念框架:抽象、封装、模块化、层次、分类、并行、稳定、可重用和可扩展。面向对象的建模思想的出现是面向过程和严格数据驱动的软件开发方法的渐进演变结果。

在需求分析阶段,UML可以用用例来捕获用户需求。通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。分析阶段主要关心问题域中的主要概念(如抽象、类和对象等)和机制,需要识别这些类以及它们相互间的关系,并用UML类图来描述。为实现用例,类之间需要协作,这可以用UML动态模型来描述。

四、用例模型技术

1、基本思想

针对需开发的软件系统,首先明确系统边界,然后找出系统边界以外的参与者,再按用例模型从这些参与者如何与系统进行交互的角度,描述参与者如何使用系统及系统向参与者提供什么功能。

2、系统边界、参与者

系统边界是指一个系统所包含的所有系统成分与系统以外各种事物的分界线,而参与者是指在系统之外,通过系统边界与系统进行交互的任何事物在面向对象分析(OOA)中,认识系统边界与参与者是为了确定系统范围,弄清系统应该在它的应用领域中发挥什么作用,从而建立一个满足用户需求的OOA模型。

参与者不仅仅是指与系统交互的各类人员,还包括与系统进行交互的任何其他事物。

3、如何确定参与者

从用户的角度考虑这个系统建立后将发挥的作用,主要需考虑系统外部将有哪些事物与它进行交互。凡是与系统进行数据信息或控制信息交换的外部事物都应看作参与者。常见的参与者有:

(1)首先从接受系统服务的人员中发现哪些人员是系统的直接使用者,这些人员是参与者;

(2)从为系统服务的各类人员中发现参与者。那些为系统的正常运行而工作,并且直接与系统交互的人员就是参与者;

(3)与系统相连,向系统提供外界信息或者在系统控制下运行的设备也可以看作参与者。这些设备在与系统交互、要求系统提供某些功能方面,与人员没有本质的区别。但要注意区别设备的两种作用模式一种是对内与计算机系统相连,对外不必经过与人员的交互而直接发挥某种作用的设备,符合图l(a)所示的模式,这类设备应该被看作参与者;另一种情况如图l(b)所示的模式。设备对内与系统相连,对外与人员交互,人员以外是现实世界的其他事物。在这种模式下,有时可以把系统边界定在设备与系统之间,把设备看作参与者;有时也可以把系统边界定在设备与人员之间,把设备看作系统的设施,而把人员看作参与者。

(4)与当前系统相连的外系统是系统边界之外的另一种参与者。

4、用例的确定与描述

用例是外部可见的一个系统功能单元,这些功能由系统单元所提供,并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。从用户角度来看,上述情况很可能是异常情况;从系统角度来看,它们是必须被描述和处理的附加情况。

例如:在图书管理系统中,Borrower(借阅者)需要通过系统Borrow Book(借书)、Return Book(还书)、Reserve Book(预定书刊)、Cancel Reservation(取消预),而借阅者的这些操作都需要通过Librarian(图书管理员)来实现,图书管理员使用系统时首先要Login(登录),在使用系统的过程中要Maintain Book Info(维护借阅者信息),Maintain Book Info(维护书刊信息)及Maintain Subst B Info(维护物理书刊信息)。所以图书管理系统需要以下8个用例:借书、还书、预定、书刊、取消预定、登录、维护借阅者信息、维护书刊信息、维护物理书刊信息。例如图书管理系统中预定书刊用例的描述如下:

5、用例模型

用例模型描述的是外部参与者所理解的系统功能。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部参与者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,保证了系统所有功能的实现。在UML中,一个用例模型由若干个用例图描述,如下图3:

用例模型是获取需求、规划和控制项目迭代过程的基本工具,是对一个参与者使用系统的一项功能时所进行的交互过程的一个文字描述序列。通过分析,把每个参与者对系统的每一项功能的使用情况都用用例模型进行了描述,全部用例模型将构成对系统外部可见行为的穷举式描述。这样,由全部用例模型描述构成了整个软件系统的需求分析。

用例模型帮助客户、用户和开发人员在如何使用系统方面达成共识。大多数系统具有多种类型的用户。每类用户表示为一个参与者(Actor)。参与者在与用例进行交互时使用系统。系统所有的参与者和所有用例组成用例模型。一张用例图描述部分用例模型,显示带有关联关系(表示出一对参与者和用例之间交互)的用例和参与者的集合(如图4所示)。

参与者“银行储户”使用白动取款机系统从帐户中取款,或存款到帐户中,或在不同的帐户间转帐。这可以由图3中的三个用例表示,这三个用例与参与者之间的关联表示了它们之间的交互。

五、结束语

UML改变了传统的软件设计思想,降低了系统设计的盲目性,也更有利于系统的扩展与测试。用例模型的提出对于软件开发具有重要的意义。通过用例模型的建立和对用例的分析,软件开发者可以准确地了解用户需求和系统功能,它是用户和软件开发者一起剖析系统需求的关键一步,推动了需求分析后各阶段的开发工作。

摘要：面向对象方法正在逐渐取代传统的方法,日益成为当今软件工程领域的主流方法。在系统需求设计方法中用例模型已成为获取系统需求的主要技术,通过用例模型的建立和对用例的分析软件开发者可以准确地了解用户需求和系统功能。它是用户和软件开发者一起剖析系统需求的关键一步,可以推动需求分析后各阶段的开发工作。

关键词：面向对象,用例,建模,需求分析

参考文献

[1]冀振燕著.系统分析设计与应用案例[M].人民邮电出版社.

[2]郑跃斌,韩文秀.用户需求分析的一种新方法-面向对象集成分析法[J].计算机工程与应用.2000.05.

[3]何克清,何非,应时.角色Use Case:UML的一个更加完全的分析方法[J].计算机研究与发展.2001.09.