软件需求分析阶段基于UML的SFMEA方法研究*
2013-08-29王雁涛
王雁涛 王 毅 杨 钿
(1.海军装备部驻重庆地区军事代表局 重庆 400042)(2.总装备部重庆军事代表局 重庆 400060)
1 引言
近年来,随着计算机软件在军用与民用领域的广泛应用,软件可靠性的重要性也日益突出。作为主要的软件可靠性分析方法之一,软件失效模式与影响分析(SFMEA)得到了越来越多的实际应用,对提高软件的可靠性和安全性起到了重要作用。当前,面向对象方法已成为国内外软件设计的主流,UML亦已成为软件界统一的建模语言。建模语言是构建软件的蓝图,从软件开发的建模语言入手进行SFMEA 分析,无疑抓住了面向对象软件可靠性分析的核心。因此,基于UML的SFMEA 方法对面向对象软件的可靠性分析具有重要意义。
当前,国内外针对该领域的研究成果非常少。从检索到的仅有的几篇文献来看,Nathaniel Ozarin 教授在2004年发表的文献[1]中总结了软件开发阶段、UML 图和软件单元(方法、类、模块和包)三者之间的关系,着重描述了SFMEA 四个级别(方法级、类级、模块级和包级)的分析特点和过程。作者虽然将UML图与SFMEA 关联起来,却未阐述如何将UML图以及关系元素具体应用在SFMEA 各级别分析中。同一年,Herbert Hecht教授发表的一篇基于UML的计算机辅助软件FMEA 文献[2]中,分别从软件开发过程中的概念阶段(即需求阶段)和执行阶段(即编码阶段)以实例阐述了UML 图在SFMEA 中的应用方法。不过,作者仅仅对用例图和类图的特点做了研究,缺乏对UML元素全面的阐述。针对当前研究现状,本人致力于研究基于UML的、应用于软件开发各阶段的、全面深入的SFMEA 分析方法,提高面向对象软件的可靠性和安全性。
2 需求分析阶段的UML建模特点
需求分析阶段是软件开发过程中第一个重要阶段,用来描述用户需求和系统结构。因此在这个阶段需要采用好的需求分析方法和技术,以保证得到高质量的用户需求[3]。需求分析阶段建模常用的UML 图形有:用例图、类图和活动图。
用例图:用例图通常是软件需求分析阶段基于UML开发的首要工具,用来描述用户需求。用例图包括用例、参与者和它们之间的关系,如图1所示。用例与参与者之间存在关联关系,用例与用例之间主要存在两种关系:包含(用《uses》表示)和扩展(用《extends》表示)。包含是指一个用例作为另一个用例必需的部分被使用;扩展则是指一个用例扩充了另一个用例的功能,但这个扩充功能不是必需的[3]。
图1 用例图
图2 类图
·类图:如图2所示,类图由类和类间关系组成,描述了系统的静态结构。在程序设计的不同阶段,类图的作用也不相同。在需求分析阶段,类图是针对研究领域的概念描述。绘制类图时,一般只给出主要的类名、属性和方法及主要的类间关系(关联、依赖和泛化)[3]。
图3 活动图
·活动图:活动图用来描述一个过程或操作的执行步骤。一个活动顺序地跟在另一个活动后执行,表示系统按照先后次序依次进行,如图3所示。在需求分析阶段,活动图常用来描述系统的宏观活动[4]。
3 基于UML的SFMEA 方法研究
按分析的层次,SFMEA 分为系统级SFMEA 和详细级SFMEA[5]。系统级SFMEA 用以分析评价软件的需求描述和体系结构,确保软件结构能够抵御软硬件失效所带来的影响,降低软件风险。因此需要在开发过程的早期开始实施系统级SFMEA,如需求分析阶段和概要设计阶段。系统级SFMEA的一般分析步骤[6]为:系统定义—功能分解—对所选层次的定义—对所选层次的基本单元进行失效模式分析—填写SFMEA 分析表格—提出改进、纠正措施。我们认为,在软件需求分析阶段,基于UML的SFMEA 也遵循同样的分析步骤。
3.1 系统定义并功能分解
作为一种自底向上的分析方法,SFMEA 首先需要将被分析系统按层次分解成各个功能模块。这种分解遵循的方式是能够识别底层模块的失效模式。底层模块的失效影响构成了上一层次模块的失效模式。影响选择合适的系统层次的基本因素在于分析的目的和可参考文档的详尽程度[7]。
从用例图的特点可知,用例表示系统执行的功能模块。在实际开发过程中,随着对需求进一步的分析和明确,用例可以进一步分解,得到子用例。这些用例和子用例在SFMEA 中作为失效模式的分析对象,即分析项(如图4所示)。
需要说明的是,用例之间的包含(用《uses》表示)和扩展(用《extends》表示)关系在用例分解中得以如下体现:被包含用例是包含用例(或基础用例)执行的一部分,因此是其子用例之一;扩展用例是对基础用例的功能扩充,通常也作为基础用例的子用例之一。用例之间的这些相互关系有助于我们对系统功能层次的了解和划分。
3.2 确定分析的约定层次
系统功能层次划分完成以后,确定分析的约定层次是一步很重要的工作,它决定了我们在哪个层次上进行分析。确定约定层次是一个主观行为,一般来说,分析人员可以约定在任意层次上开始分析。约定层次越低,功能模块就越多,分析结果更全面,但花费的人力、时间成本也就越高。实施SFMEA的目的之一是在软件开发过程的早期尽可能多地发现软件存在的缺陷并加以改进,因此,在需求分析阶段应该从较低层次开始SFMEA 分析(如图4所示)。
图4 用例图、分析项和约定层次
3.3 确定失效影响的传递路径
失效影响是指软件(或软件单元)失效对系统造成的后果。失效影响具有传递性,一般分为本层次影响、上一层次影响、最终影响。为了得到失效影响的传递路径,我们需要确定软件模块(或软件单元)之间的顺序依赖关系。
UML中的活动图适合于描述跨一个或多个用例的行为,而且它的特点很适合描述用例行为的顺序关系。因此在需求分析阶段的SFMEA 过程中,我们利用已有的活动图,在用例级(或子用例级)分析层次上确定用例(或子用例)的执行顺序,建立失效影响的传递路径。这种用活动图元素表示用例与用例、子用例与子用例之间的顺序依赖关系的图形称作“用例依赖关系图”[8],如图5所示。该图反映了图4中在约定层次上三个用例的依赖关系。该三个用例顺序执行,用例1.1失效的本层次影响是对用例1.2实施,用例1.2失效的本层次影响是对用例2.1 实施,等等,以此类推。另外,分析用例的上一层次失效影响以及最终影响则根据用例图的层次关系来确定。如参考图4用例图,用例1.1的上一层次影响是对用例1实施,最终影响是对整个系统实施。
图5 用例依赖关系图
3.4 确定失效模式并进行影响分析,完成分析表
SFMEA的最终成果是生成分析表,表格内容主要包括分析项、失效模式、失效原因、失效影响、严酷度以及改进措施和建议。由前面的分析得知,将约定层次上的用例(或子用例)作为分析项。失效模式是指软件(或软件单元)失效的表现形式,是SFMEA 最重要的分析元素。分析人员需要根据分析项的功能特点并结合需求规格文档,例举出该分析项所有潜在的失效模式。然后,从约定层次向上追溯失效影响的传递路径,确定该失效模式的本层次影响、上一层次影响和最终影响。再协同开发人员、领域专家以及结合相关文档找出失效原因并评估失效严酷度。最后,提出改进措施和建议,完成SFMEA 分析表。
综上论述,在软件需求分析阶段基于UML的SFMEA方法总结如下:
1)分析对象:用例图、活动图。
2)分析方法:利用用例图确定分析层次和分析项,结合用例图和活动图建立“用例依赖关系图”,用于分析失效影响。
需要说明的是,类图在软件需求分析阶段主要用于概念类的描述,不需要也无法获知类的完整属性和方法。因此,类图不作为在此阶段SFMEA的分析对象。但是,在后续的软件设计和实现阶段的SFMEA 过程中,类图将扮演着重要角色。
4 实例验证
以常见的ATM 软件系统为例,根据其需求规格说明文档绘制的系统用例图如图6所示,包括“存款”、“取款”、“查询余额”三个主要用例,其中“登录”为该三个用例的被包含用例,“打印收据”为“存款”、“取款”用例的扩展用例。对ATM 软件系统的SFMEA 分析过程如下
图6 用例图
1)系统定义和功能分解。由图6可知,系统包括“取款”、“存款”和“查询余额”三大功能模块,它们作为系统第一层次。“登录”用例是被包含用例,因此属于第二层次;“打印数据”用例是扩展用例,根据其功能特点,属于上层用例的子用例,也划为第二层次。并且,“打印数据”与“登录”两个子用例相互独立。分析人员参考子用例图进一步了解系统层次。以“取款”用例为例,图7反映了“取款”的子用例层次图。分析人员可结合用例图与子用例图来约定分析层次。
图7 “取款”子用例图
2)约定整个软件系统为分析的初始层次,子用例图的最底层为最低层次。如图7 所示,子用例“验证银行卡”、“验证密码”、“验证账户余额”、“结算”所在层次为最低层次;“打印数据”没有子用例,也将其作为最低层次。上述5个子用例均作为分析项,展开自底向上的分析。
3)确定失效影响的传递路径。根据“取款”用例的活动图(见图8)我们看到,一个或一组活动构成了个子用例。由这些活动的顺序关系,我们绘制出如图9所示的子用例依赖关系图,建立了子用例失效影响的传递路径。
图8 “取款”活动图
图9 “取款”子用例依赖关系图
4)研究分析失效模式。以“验证银行卡”子用例为例,根据其功能特点,有“无效银行卡验证成功”、“有效的银行卡验证失败”以及“验证银行卡超时”等三种失效模式。分析失效原因需要结合需求说明文档以及项目经验来阐述。分析失效的本层次影响、上一层影响以及最终影响时,分别根据图9、图7和图6进行跟踪,即分析对“验证密码”子用例、“登录”子用例和整个系统的影响。最后,评估失效影响的严重等级。对其他子用例的分析过程如法炮制。
通过以上分析,最后完成SFMEA分析表,如表1所示。
表1 SFMEA 表
续表1
5 结语
通过以上分析,我们更加明确利用UML 元素在软件需求分析阶段进行SFMEA 分析的特点:
1)使用用例图定义分析项,分析者不需要将系统进行功能分解[1];结合活动图来建立用例依赖关系图,确定失效影响的传递路径;
2)用例图覆盖了系统功能,将用例作为分析项,确保分析完整;
3)找出需求描述在准确性、一致性和完备性方面的缺陷;识别软件潜在的危险状态,在后续设计和实现中避免危险状态的发生。
与其他开发阶段相比,在需求分析阶段进行SFMEA分析只需要相对较少的努力,虽然分析结果不如在后续阶段的分析准确和完善,但具有重要意义。
[1]Nathaniel Ozarin.Failure Modes and Effects Analysis during Design of Computer Software[J].IEEE,2004:201-206.
[2]Herbert Hecht,Xuegao An,Myron Hecht.Computer Aided Software FMEA for Unified Modeling Language Based Software[J].IEEE,2004:243-248.
[3]王养廷,李磊,等.UML 基础与应用[M].北京:清华大学出版社,2006,6.
[4]吴建,郑潮,等.UML基础与Rose建模案例[M].北京:人民邮电出版社,2004,(10):91.
[5]Bowles,J.B..The new SAE FMECA standard[C]//Proceedings Annual Reliability and Maintainability Symposium,1998:48-53.
[6]栗芳,黄锡滋.软件失效模式效应分析方法[D].电子科技大学,1998.
[7]Haapanen Pentti,Helminen Atte.Failure modes and effects analysis of software based automation systems[J].STUKYTO-TR 190,2002,(8).
[8]徐宏喆,陈建明,等.UML 自动化测试技术[M].西安:西安交通大学出版社,2006:143-173.