（计算机软件与理论专业论文）基于mda的需求工具的研究和设计.pdf

捅要随着军事信息化系统的不断发展及规模的不断扩大，军用软件面临着越来越大的压力。军事信息化系统开发的重点除了信息技术支持以外，前期的需求获取与建模也变得非常重要。本文通过建立一套规范的需求建模方法，力求解决军用软件的高效性和完备性等问题，主要研究用例驱动的需求技术和模型驱动体系结构( m d a ) ，提出需求过程和m d a 开发过程相结合的软件开发方法。本文重点分析和设计了一种基于m d a 的需求工具，可实现需求获取、需求分析、模型转换、文档生成和需求确认等功能。该工具主要采用用例驱动技术，通过表格和模板的方式引导用户捕获自己的实际业务需求；同时开发了一种描述系统功能性需求的语言一一用例描述规范语言( u c d s l ) ，该语言支持需求分析和模型转换的自动化；并且制定了需求到用例模型、用例模型到活动图、用例模型到时序图以及扩展的c r c 卡到类图的转换规则。关键词：模型驱动体系架构用例驱动需求获取模型转换a b s t r a c tw i t ht h ed e v e l o p m e n to ft h em i l i t a r yi n f o r m a t i o ns y s t e ma n dt h ee n l a r g e m e n to ft h es c a l e ，m i l i t a r ys o f t w a r ef a c e st h ei n c r e a s i n gp r e s s u r e i na d d i t i o nt oi n f o r m a t i o nt e c h n i c a ls u p p o r t ，t h em i l i t a r yi n f o r m a t i o ns y s t e md e v e l o p m e n tf o c u s e so nt h ee a r l yr e q u i r e m e n te l i c i t a t i o na n dm o d e l i n g b ye s t a b l i s h i n gan o r m a lr e q u i r e m e n tm o d e l i n gm e t h o d s ，t h et h e s i st r i e st or e s o l v et h ei s s u e so ft h em i l i t a r ys o f t w a r ee f f i c i e n c ya n di n t e g r a l i t y t h et e c h n o l o g yo fu s e - c a s ed r i v e nr e q u i r e m e n te l i c i t a t i o na n dt h em e t h o d o l o g yo fm o d e ld r i v e na r c h i t e c t u r e( m d a ) a r em a i n l ys t u d i e d ，a n dan e ws o f t w a r ed e v e l o p m e n tm e t h o di sp r o p o s e dw h i c hi n c o r p o r a t e sr e q u i r e m e n tp r o c e s sa n dm d ad e v e l o p m e n tp r o c e s s t h et h e s i se m p h a s i z e so nt h ea n a l y s i sa n dd e s i g no fan e wr e q u i r e m e n tt o o lb a s e do nm d a t h ef u n c t i o n sw h i c ht h et o o lc a ni m p l e m e n ti n c l u d er e q u i r e m e n te l i c i t a t i o n ，r e q u i r e m e n ta n a l y s i s ，m o d e lt r a n s f o r m a t i o n ，d o c u m e n tg e n e r a t i o na n dr e q u i r e m e n tv a l i d a t i o n t h eu s e c a s ed r i v e nt e c h n o l o g yi sa d o p t e dt og u i d eu s e r st oc a p t u r et h e i rr e q u i r e m e n t sb yt h ef o r mo ft a b l e sa n dt e m p l a t e s al a n g u a g e ，n a m e da su s e c a s ed e s c r i p t i o ns p e c i f i c a t i o nl a n g u a g e ( u c d s l ) ，i sd e v e l o p e dt od e s c r i b es y s t e mf u n c t i o n a lr e q u i r e m e n t s ，w h i c hf a c i l i t a t e st h ea u t o m a t i z a t i o no fr e q u i r e m e n ta n a l y s i sa n dm o d e lt r a n s f o r m a t i o n f u r t h e r m o r e ，t h em o d e lt r a n s f o r m a t i o nr u l e sa r ee s t a b l i s h e d ，w h i c hi n c l u d et h et r a n s f o r m a t i o no fr e q u i r e m e n t st ou s e c a s em o d e l s ，u s e - c a s em o d e l st oa c t i v i t yd i a g r a m s ，u s e c a s em o d e l st os e q u e n c ed i a g r a m sa n de x t e n d e dc r cc a r d st oc l a s sd i a g r a m s k e y w o r d s ：m d a ( m o d e ld r i v e na r c h i t e c t u r e )r e q u i r e m e n te l i c i t a t i o nu s e c a s ed r i v e nm o d e l ，1 1 阻n s f o r m a t i o n创新性声明本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其它人已经发表或撰写过的研究成果；也不包含为获得西安电子科技大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中做了明确的说明并表示了谢意。申请学位论文与资料若有不实之处，本人承担一切相关责任。本人签名：l 她关于论文使用授权的说明本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。本人保证毕业离校后，发表论文或使用论文工作成果时署名单位仍然为西安电子科技大学。学校有权保留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全部或部分内容，可以允许采用影印、缩印或其它复制手段保存论文。( 保密的论文在解密后遵守此规定)本学位论文属于保密，在一年解密后适用本授权书。本人签名：瘗照玉墨导师签名：文二： 。，j i “麓蔓：一_ ，第章绪论第一章绪论1 1 课题研究背景随着社会信息化的快速发展，软件界需要创薪出一种新的软件开发方法。尤其对于复杂的军事信息化系统来说，一种行之有效的软件开发方法是至关重要的。军搴信息化的核心在于建立军事信息优势，有效地管理与运用所获得的一切军事信患，恰当地为军事决策人员提供信息服务，以达到取得军事决策优势和战场控制优势之目的【1 1 。现在，各国军事领域信息化的战争方式越来越明显，打赢军事战争的关键就是加强信怠化系统的建设。军事信息化系统建设的主要特性包括：高效性和完备性。高效性指的是军事信息化系统的开发效率，也就是说快速、高效地开发出满足作战需求的系统软件。当今的战争就是信息战、速度战。当出现新的军事需求时，如何在短时间内准确获取需求、快速创建稳定的信息系统是取得军事胜利的关键。完备性指的是开发出来的军事信息化系统要满足军事上提出的各种需求。如果系统未能实现全部的功能，那势必在战争中会影响各种作战力量之间及各种作战行动、手段之间的密切协同和有机配合。因此，努力增强军事信息化系统的建设，提高系统的开发速度，完善系统的各种功能，是军事信息化系统建设面临的且必须解决的重要课题。麸各种擐导我们得知，我国军队歪在进行着军事信息纯建设。但是成效如何，从军队体制编制调整、信息化建设相关的报导中不难见其端倪。首先，没有合理、有效的需求获取方法来准确、全面地获取军事的需求；其次，没有一套完备的理论和方法支持军事信息化系统的开发。这些暴露出来的问题严重阻碍着中国军队信息化建设、制约着现代信息技术的优势，同时大大降低了我军作战的能力。因此，对予我国军事的发展来讲，创建一种适合我国军事信息化建设的软件需求工具是迫在眉睫的。在军事信息化系统的需求分橇、开发设计和建设维护麴各个阶段孛，需求获取和分析处于系统建设的初始部分，它提供了构建整个系统的根基。需求分析差之毫厘，系统实现则谬以予墨。据统计，在系统项目的研制中酉分之四十至六十的不成功都是由于需求分析不科学、不全面造成的。长期以来，我们对军事信息化系统的需求一直处在用自然语言定性描述的阶段，主观因素较多，丽较少把之作为一项“工程来看待。事实上，需求工程是系统工程的重要分支，在软件工程学科中已得到广泛运用。军事信息化系统建设作为一项复杂的系统工程，亦应采用需求工程的方法，合理运用需求获取和分析技术，使构建麓信息系统切实符2基t - m d a 的需求工具的研究和设计合未来战场的需要【2 1 。1 2 研究现状及存在问题由于信息技术的迅猛发展，现今已是信息的时代。不言而喻，信息时代的战争必将是信息化的战争。军事信息化系统是作战中所使用的信息系统。目前，国内外军事信息化建设面临着以下问题：军事软件复杂度不断提高，开发规模不断变大，开发周期不断延长。究其原因是军队对信息化系统要求的不断增加。面对纷繁复杂的军事用户要求，如何能够快捷、准确的获取系统的需求并建立起无歧义的、完整的模型已成为军事信息化软件丌发中的核心问题。在军事信息化发展的初期，军用软件规模较小，软件开发直接从代码开始，需求阶段不受到重视。后来军事信息化规模的不断增大，出现了软件危机，军用软件缺陷的增加导致军事信息化系统无法运行。随着软件生命周期概念的出现，需求成为软件开发的第一个阶段【3 1 。但是，目前的军事应用软件需求研究常常流于形式。由于缺乏用户参与的合理机制，缺乏对需求文档资料的有效管理，缺乏用户与开发人员之间有效的交流方法，使需求研究效率低、效果差1 4 j 。同时，军事系统的建设与发展周期长，系统结构复杂，涉及因素多，耗资巨大。军事人员常常难以根据目前的实际情况提出“完整 的需求，软件开发人员又对军事领域缺少深刻的了解，致使开发的军用软件不能完全满足作战需求。对国外众多案例的分析结果表明：软件需求直接影响到系统的成功与否，需求活动是软件开发的第一阶段，也是非常重要的阶段。因不重视或忽视需求而直接导致项目失败甚至造成重大损失的例子不胜枚举。2 0 世纪9 0 年代爆发的海湾战争暴露了以美军为主的多国部队的军事信息化系统的缺点：由于美军各军种的系统建设没有依据联合作战的需求，在战争过程中不能互通，因此不得不派军用飞机携带磁盘下达战斗命令，致使茭军战斗能力大大减弱。海湾战争之后，美军提出了一系列基于现代条件下战争的思想，大力加强军事信息系统建设中军事需求工程的研究和分析【5 1 。另个著名的案例是“伦敦野战救护系统( l a s ) ”1 6 j ，这个系统在部署不久即陷入瘫痪，其中一个主要原因就是开发的软件系统未能满足实际业务需求。在我国，军事信息化建设正处在由各个系统独立建设向整体建设全面发展的过渡时期。短短十余年我军信息化建设就达到了发达国家的水平。这种后发优势表现出的效益，缩短了建设周期，跨越了常规阶段，使我们少走了许多弯路，但是也存在很多问题。由于当初起点低，较高的发展速度使一些成果来不及消化，尤其是在军事需求分析等方面表现出了极大的弊端，如：需求获取和需求分析不完善，软件需求阶段与产品开发结合不够紧密。解决这些问题需要对信息化建设第一章绪论3的深层次规律有科学的认识和把握，有效地解决军事应用软件需求遇到的难题。军事需求的精确性和完整性在很大程度上决定着软件产品质量的优劣。军事需求研究上的缺陷与失误，往往会使系统建设受到严重影响，甚至导致整个系统建设的失败。充分、明确、合理的作战需求分析，对系统建设起着重要的导向、推动、检验和增益 乍用1 7 1 1 羽。军事需求牵弓| 军事信息化系统发展建设的方向，需求开发的工作成效直接影响系统发展建设的效益、决定系统建设的成败。因此，需要深入开展军事信患化系统的软件需求麴研究。军事信息化系统的强大功能和威力已经为人们目睹，引起了世界各国军事界的注意共投入大量的人力物力予以研究和发展。军事需求开发要做到：一、解决问题的突破口和焦点应该在于解决问题的多视角化，即不同领域、同一领域不同视角人员共同有效参与；二、应该将重点放在领域分析上，只有深入准确地分析所要研究的领域，才能保证需求客观有效；三、高度重视最终用户参与的必要性和重要性。因此，军事需求获取必须以有效合适的军事需求开发技术为基础，吸收最终用户有效参与需求开发全过程，并采取有效的方法策略，实现领域知识酶无缝交互，协调统一不同“视角 的理解，吸收军事需求工程各阶段人员的不同观点，最终获得完备、科学、可行的需求。在软件需求工程领域中已经存在一些成熟的、有代表性的、广泛应用的方法。比如：s 删w ( s t r u c t u r e da n a l y s i sa n dd e s i g nt e c h n i q u e ) 、s r e m l l u j ( s o f t w a r er e q u i r e m e n te n g i n e e r i n gm e t h o d o l o g y ) 、j a d 方法( j o i n ta p p l i c a t i o nd e v e l o p m e n t ) 以及s c e n a r i o 方法【1 2 】【1 3 】。上述几种方法各有侧重点，都在某个方面发挥了各融的优势。s 越注重予需求的建模及表示；s r e m 严格的需求分析步骤能实现一定程度上的自动化支持；j a d 方法是群体讨论方法的代表；s c e n a r i o 强调从用户的焦度用事件及状态变化来描述需求。但是我们可以看到，由予军事信息系统的特殊性质，没有任何一种需求工程方法能够独自担当大任。为改变这种状况，在开发军事信息系统的军事需求阶段，我们需要在借鉴已有需求工程方法的基础上，尝试引入新的方法，发挥军队用户在需求获取和分析中的主导作用。同时，还须对需求过程进行必要的管理，这也是非常重要的一点。1 3 研究目标和内容基于上述研究背景和研究现状，本文借鉴已有需求工程方法，结合军事信息化建设的特性，主要采用用例驱动技术，同时融入耳前一种非常热门的思想一一模型驱动体系架构( m o d e l d r i v e na r c h i t e c t u r e ，m d a ) ，构建了一种符合军事信息化系统建设要求的需求工具。本文研究的内容主要包括以下两点：4基于m d a 的需求t 具的研究和设计1 ) 在已有需求获取和分析技术的基础上，结合实践经验，改进了原有的u m l用例驱动技术，提出了一种全面的用例驱动方法。此方法能够快速、准确地获取用户需求。用例驱动方法是一种常用的需求技术，它被吸收到统一建模语言u m l 中，使得获取有用的用例模型成为基于u m l 面向对象建模的需求分析阶段的首要任务。然而己有u m l并没有支持需求获取过程，仅仅提供绘制、说明和管理用例模型的平台，致使建立的用例经常存在一些缺陷。因此，本文改进了现有的用例驱动技术，提出了完整获取需求的方法。2 ) 在需求工具的开发中，融合了m d a 的思想。这里所提到的m d a 思想与目前业界理解的m d a 有些许的差别。m d a是由对象管理组织( o b j e c tm a n a g e m e n tg r o u p ，o m g ) 提出的，其思想是通过以更高抽象层次的模型为核心而不是以原来的代码为核心来进行软件开发，解决传统软件开发模式的需求分析和设计中所作的模型和文档与编码实现中的代码之间存在的严重不一致问题，使软件开发过程自始至终都保持高度一致，大幅度提高软件开发效率，增强软件的可移植性、协同工作能力和可维护性，同时也为文档编制的便利性指明道路【1 引。目前软件界认同的m d a 软件开发过程只包括建模、开发、发布等阶段，但不包括需求、测试等阶段。这并不代表需求和测试在m d a 框架下不需要存在，事实上它们都是非常重要的，只是目前m d a 开发过程没有涉及，也没有工具进行支持而已【1 5 i 。因此，为了填补需求在m d a 框架中的空白，本文提出了一种新的理论：需求工具和现有m d a 开发过程相结合，使需求过程与m d a 模型的创建和转换过程衔接起来，真正做到模型驱动技术从业务模型开始。这样做的好处是：一广大用户可以容易地参与系统软件的开发，甚至可以亲自定制软件的矿强等，有效预防了软件产品与用户要求相差甚远的难题；二、模型驱动酐砍| 牛开发过程从需求开始，把业务需求作为起始点，大大提高了软件的开发效率，满足了军事信息化系统开发的要求。同时，避免了需求变更带来的一些复杂问题，比如：软件开发永远无法适应需求变更的现实。为了满足军事信息软件的快速发展，以及军事信息软件高效性和完备性的要求，本项目组研究了采用用例驱动技术、融合m d a 开发理念的需求工具。该工具将实现以下目标：1 ) 方便、准确、全面地获取用户需求；2 ) 提供友好、快捷的操作界面引导业务领域的专家和最终用户描述需求；3 ) 将系统对用户需求的理解以直观、方便的形式反馈用户；4 ) 结合m d a 的思想，将获得的用户需求转化成模型，加快软件产品的开发。第一章绪论51 4 论文的创新性在军事信息化系统建设的大背景下，本文就系统开发中的需求阶段以及需求与建模的联系傲了重点的研究。课题研究的创新点在于：1 ) 采用用例驱动的需求技术，建立面向最终用户和领域专家的需求工具。已开发的需求管理工具的使用者都是软件开发人员，比如：r e q u i s i t e p r o 、d o o r s 等。由于软件产品需求主要来源于软件产品的最终用户以及领域专家，因此建立直接面向产品用户的需求工具可以有效地保证需求的完整性和正确性。2 ) 本文设计的需求工具与传统的需求管理工具相比，功能更全面、更完善，并且需求过程中各个阶段的衔接更紧密。传统的需求管理工具侧重于软件需求的管理，对软件开发过程中需求阶段的工作未能提供全面的支持。本文在设计需求工具时，考虑了需求过程中应实现的所有功能，包括：需求获取、需求分析、需求文档生成、需求确认等。此外，还提高了需求过程中餐个阶段衔接的紧密性和露动性。3 ) 统一需求过程和m d a 开发过程，这是本文的主要创新点之一。从m d a 的研究现状来看，整合需求过程与m d 硝过程的研究尚处予初级阶段。本文在军事信息化系统建设的高效性要求下，针对需求与m d a z 间的不衔接性，将需求过程和m d a 开发过程统一起来，完善软件开发过程。同时制定了用例描述规范语言和模型转换规则来完成需求到m d a 模型自动化或半自动化的转换。1 5 论文的组织结构本文由六个主要章节组成，各章主要内容如下：第一章：绪论。本章主要介绍课题的研究背景、国内外研究现状和存在的问题、研究西标、研究内容等。第二章：用例驱动的需求分析技术。本章首先介绍了软件需求的相关知识，包括需求工程以及需求工程的复杂性、重要性。然后描述了焉例驱动技术，介绍了用例驱动的基本概念：参与者和用例，同时重点介绍了在工具设计中所采用的另一个概念：用铡描述。第三章：m d a 体系结构。本章介绍了目前在软件界非常流行的技术一m d a ，包括：m d a 产生的背景、m d a 的体系架构。同时，本章比较了m d a 开发方法与6基丁：m d a 的需求工具的研究和设计传统软件开发方法的不同之处，总结了m d a 开发方法的优势。第四章：基于m d a 的需求工具。本章提出并阐述了需求工具的整体框架以及实现的功能。首先概要地描述了需求工具的大体框架以及所要实现的目标，接着具体阐明了需求工具提供的各项功能。第五章：基于m d a 的需求工具的详细设计。本章详细地描述了需求工具的设计，包括：需求获取模块的设计、用例描述规范语言的制定、需求到模型的分析和转换以及文档的生成。第六章：总结与展望。作为本文的结尾，本章主要包含两个方面：其一总结了本人在研究实践中所做的工作以及工具实现的功能；其二列举出了基于m d a 的需求工具还有待完善的一些方面。第二章用例驱动的需求分析技术7第二章用例驱动的需求分析技术2 1 软件需求随着信息时代的发展，计算机软件的需求愈来愈复杂，规模愈来愈大，而且随着企业的发展及工作过程重组，需求变更已愈来愈成为必然。但是，传统的软件工程( s o f t w a r ee n g i n e e r i n g ，s e ) 开发模式显然不能充分满足用户的需求。进入9 0 年代以来，一种新的被称为“用户主导，面向领域的需求分析方法 被提了出来，即如何从各种各样的应用专业领域中特别是直接从最终用户处捕获需求，并完整、准确地予以描述与分析，需求工程成为研究的热点之一。对于本文所涉及到的军事专业领域来讲，如何和最终的军队用户进行沟通、如何获取全面的、准确的需求，解决好这些问题是成功开发军事信息化系统的关键点，需求工程在军事信息化建设过程中起着举足轻重的作用。下面就需求工程概念、复杂性和重要性做出介绍。2 1 1 需求工程需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求工程很少受到重视。后来软件开发引入了生命周期的概念，需求成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。8 0 年代中期，形成了软件工程的子领域一需求工程。进入9 0 年代以来，需求工程成为研究的热点之一。从1 9 9 3 年起每两年举办一次需求工程国际研讨会，自1 9 9 4 年起每两年举办一次需求工程国际会议，s p r i n g e r v e f l a g 发行了一个刊物一r e q u i r e m e n t se n g i n e e r i n g 。一些关于需求工程的工作小组也相继成立，如欧洲的r e n o i r ，并开始开展工作。目前“需求工程 还没有标准的定义，一般认为需求工程是指应用已证实有效的原理、技术和方法，描述目标系统的外部特征和相关约束，从而确定客户需求，帮助分析人员理解目标系统的一门学科。它通过合适的工具和记号系统描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持1 1 6 儿1 。丌。需求工程是软件工程的一个子集，但它并不是软件工程产生时就有的。随着软件工程的发展，即软件危机的出现及其解决思路的改进，对软8基于m d a 的需求丁具的研究和设计件需求的要求越来越高，逐渐形成了一套工程化的理念和做法。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。8 0 年代，h e r bk r a s n e r 定义了需求工程的五阶段生命周期【1 8 】【1 9 l ：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。m a t t h i a sj a r k e 和k l a u sp o h l 提出了三阶段周期的说法：获取、表示和验证【捌。近来，w i e g e r s 将整个需求工程领域划分为需求开发和需求管理。需求开发可进一步分为：需求获取、需求分析、编写软件规格说明书s r s 和需求验证四个阶段，如图2 1 2 1 1 。图2 1 需求工以的层次分解不恿图1 ) 需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。需求获取的方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等。此外，还有知识工程方法，如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。分析人员借助于这些工具和方法，获取对用户需求的基本理解，然后在需求获取方法驱动和指导下，从非形式化需求陈述中提取出用户的实际需求，并由此确定软件的功能、性能、接口关系及有关属性、软件条件、限制和边界等，标定软件的作用范围，确认支持性的软、硬件环境及辅助工具与条件。2 ) 需求分析：在需求获取的基础上，对己收集到的需求进行提炼、分析和仔细审查，与用户进一步交流以澄清某些易混淆的问题，以便所有风险承担第二章用例驱动的需求分析技术9者都明白需求的含义，并找出其中的错误、遗漏或其他不足的地方。通常采用的需求分析方法有面向数据流的结构化分析方法、面向数据结构方法、面向对象的分析方法等。这些方法都采用图文结合的方式，可直观地描述软件的逻辑模型，为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。3 ) 形成需求规格说明书：s r s 用来阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，s r s 不应该包括设计、构造、测试或工程管理的细节。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。4 ) 需求验证：也称需求评审。作为需求开发阶段的最后一步，应该对功能的正确性、完整性和清晰性以及其他需求给予评价。以用户为中心，成立一个由不同代表( 如用户、分析人员、设计人员、测试人员) 组成的需求评审小组。以需求规格说明为输入，通过符号执行、模拟或快速原型等途径分析需求规格的正确性和可行性。5 ) 需求管理：支持系统的需求演进。如：需求变化和可跟踪性问题。需求管理不涉及收集和分析软件项目需求【勿。其主要目标是对分配需求进行管理，即要在客户和实现客户需求的软件项目之间达成共识；控制软件系统的需求变更，为软件工程和管理建立基准线；保持软件计划、产品活动与软件需求的一致性。简单地说，需求管理就是要确定便于所有人理解的需求，稳定软件需求并说明需求的更改对项目成本和进度的影响。需求管理过程和软件开发过程是并行的，并贯穿在整个软件开发的生命周期之中。2 1 2 需求工程的复杂性在整个软件项目，软件需求是最关键的一个输入。和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性等特点，它不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，它的复杂性体现在以下方面：1 ) 需求的描述问题缺少正式的、完整的需求文档，同时浪费大量的人力物力。但是一旦有了需求文档，则又出现了新的问题。在用户方进行的需求评审通常完全是走形式，因为用户根本不去听或读那上百页的需求文档。不同层次的客户( 用户) 所关心的问题是不一样的，因此想要每个客户都成为需求专家是不现实1 0基丁：m d a 的需求工具的研究和设计的。2 ) 需求的完备程度问题需求如何做到没有遗漏? 如何划定系统的范围? 这确实是个两难的问题。稍微大一点的系统要想穷举需求几乎是不可能的。每次在开需求评审会议时，总会冒出新的需求，以至于系统没有一个准确的需求范围界定。即使是这样，系统还是要丌发，系统的范围还要硬性的划定一个，从而建立一个基线。3 ) 需求开发的工期问题在需求上花费大量时间，客户、软件公司是否能够忍受? 为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已!他们往往会逼迫项目组尽快往前推进项目，而项目组的成员往往也会为系统复杂的、善变的需求折腾得筋疲力尽，他们都希望尽快结束此阶段的工作。4 ) 需求的细致程度问题需求到底需要描述到多细，细到什么程度才可以结束? 仁者见仁，智者见智，并没有定论。如果时间允许，要想细总可以细化的。但是，需求定义的周期越长，可能产生的变化越多，对设计的限制越严格，对需求共性的提取的要求就越高。5 ) 需求的变化问题在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上就是在同变化做斗争的过程，需求的变更不一定是坏事，有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。需求变化的原因很多，比如：矸始没有识别全部的需求，需要增加需求；业务发生了变化，需求必须变化需求错误；需求不清楚等。需求的变化问题是每个开发人员：每个项目经望都遇到的问题，也是最头痛的问题。一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等。需求的变化有时好比是万恶之源，为项目的正常进展带来不尽的麻烦。如何减少这些麻烦呢? 只有管理它，使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。因此，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用【2 3 1 。第二章用例驱动的需求分析技术2 1 3 需求工程的重要性需求工程的重要性是不容质疑的，然而并非所有软件开发者都能清楚地意识到需求工程中的缺陷会给软件项目带来怎样的风险。目前，尽管软件项目开发的相关知识不断扩充、技术不断进步、经验不断丰富、可利用的工具也在不断增多，但仍然有相当比例的软件项目失败。据调查显示在众多失败的软件项目中，由于需求原因导致的约占到4 5 。究其原因，常常是因为在项目开始阶段没有正确地定义需求，或是随着项目的展开没有正确的管理需求。因此，需求工作将对软件项目能否最终实现有着至关重要的影响。目前，需求活动逐渐被重视以及工程化。但是在许多软件项目中，由于需求活动引发的潜在问题未被理解和重视，很多人对需求的认识仍然远远不够。很多项目都把大量精力放在开发上，减少需求活动的时间。不管是小到几十万元，还是大到上亿元的软件项目，需求都或多或少的存在问题，有的是开发者本身不重视原因，有的是技术原因，有的是人员组织原因，有的是沟通原因，有的是机制原因。在需求阶段一个小小的错误很有可能造成后期付出几百倍的代价。上述现象表明需求工程在整个软件生命周期中是非常重要的，也是非常基础的。做好软件需求开发是一项系统工作，而不是简单的技术工作。只有系统的了解和掌握需求工程的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求工程的工作，从而减少软件开发中的错误，减少修复错误的费用，降低软件开发成本，缩短软件开发时间。2 2 1 用例驱动技术2 2 用例驱动技术多年来，软件分析师总是利用情节或经历采用用户和软件系统的交互方式来获取需求。用例驱动技术是i v a rj a c o b s o n 先生于1 9 6 7 年在爱立信公司开发a x e 交换机时开始研究的，并于1 9 8 6 年发布的一项源于实践的需求分析技术。i v a r 先生在加盟r a t i o n a l 之后，与g r a d yl o o c h 和j i mr a m b a u g h 共同创建了一种可视化地说明、建造软件系统的工业标准语言一统一建模语言u m l 、完善了r a t i o n a l 统一过程r u p ，用例驱动分析技术也因此被人广泛了解和关注。用例被面向对象领域所接纳，成为一种广泛使用的需求技术。u m i a 示准中引入了用例作为软件开发的基本元素。与传统的功能分解方式相比，用例驱动方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用1 2基丁m d a 的需求工具的研究和设计于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的s r s 更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。用例驱动技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。用例是一些外部参与者和系统之间交互的文本描述。用例图是参与者和用例之间、一个用例和另一个用例之间的图形表示。所产生的用例和用例图文档应该使用户能够很容易理解。用例应该以“用户语言”编写，避免掺杂“对象语言和实现细节。每个用例内部是一个有效驱动系统开发过程其余部分的精巧的需求包。用例不仅驱动需求过程，而且还驱动整个软件开发周期。有些方法论，比如r u p ，都是用例驱动的。用例具有表达计算机系统本质的简洁性，同时又可以在需求可跟踪性问题的解决过程中驱动整个方法论。但是，在第一章中我们已经提到了用前期版本的u m l 包含的用例来获取需求会存在一些缺陷，原因包括：1 ) 执行者和用例的关系复杂不清晰；2 ) 用例中的系统边界模糊且变化无常；3 ) 用例的规格说明形式各异；4 ) 用例的描写来自于系统的观察点，而非实际用户的角度。2 2 2 用例驱动的基本概念用例驱动的基本概念包括参与者和用例，在本文的研究中还包括另一个概忿：用例描述。通过识别并独立分析每一个参与者的不同用例，可以了解系统的每一类用户的要求和愿望，而不会沉溺于实现细节，而用户的要求和愿望正是系统蚊重要的部分。所有用例的集合描述了系统的功能，客户可以预先确定项目的范围，从而避免了最终产品与客户间的期望差异。下面介绍用例驱动涉及到的几个基本概念：1 ) 参与者参与者是与系统交互的外部实体，它是直接与系统相互作用的系统、子系统或类的外部实体的抽象概念。参与者定义了用户在系统交互过程中扮演的角色，其可以是一个人，也可以是另一个相关的计算机系统或更抽象的东西，例如特定的日期和时间。显示在用例图上的参与者应该与系统直接交互，或直接受系统影响。第- 二章用例驱动的需求分析技术1 32 ) 用例用例是参与者与系统之间一系列可能的交互行为序列的集合，以实现用户使用系统所要达到的特定目标。用例描述了参与者使用系统所要实现的行为。但是它不涉及具体的实现细节，强调的是能做什么，而不是怎么去做。用例用于表示系统所提供的服务，定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的对话。用例实例是在系统中执行的一系列动作。这些动作将生成特定参与者可见的价值结果，一个用例定义一组用例实例。一个用例应为参与者提供一个价值。在具体的需求过程中，有大的用例，也有小的用例，主要是由用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是其内部的一些信息。用例可以很容易被用户( 也包括开发者) 所理解。如果用例不足以表达足够的信息来支持系统的开发，那就有必要把用例这个黑盒打开，审视其内部的结构，找出其内部包含的参与者和用例。这样通过不断地打开黑盒，分析黑盒，再打开新的黑盒，直到整个系统可以被清晰地了解为止。3 ) 用例描述【冽，很多人都误解u s ec a s e 为一种图表，把用例图当作用例分析的全部，其实这是错误的，用例描述才是用例驱动技术的核心。用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，还需要描述每一个用例的详细信息的用例描述。用例模型是由用例图和每一个用例的详细描述所组成的。u m l 2 0 提供了用例描述的基本内容：简要描述、前置条件、基本事件流、备选事件流、后置条件、主要参与者( a c t o r ) 、相关用例等等。( 1 ) 简要描述：对用例的角色、目的的简要描述；( 2 ) 前置条件：执行用例之前系统必须要处于的状态或者要满足条件；( 3 ) 基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流：( 4 ) 备选事件流：负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景；( 5 ) 后置条件：用例一旦执行后系统所处的状态；( 6 ) 主要参与者：参与用例的主要参与者；( 7 ) 相关用例：与用例相关的其他用例。第三章m d a 体系结构1 5第三章m d a 体系结构模型驱动体系架构m d a 是由o m g 组织全新提出的应用模型技术进行软件系统开发的方法论和标准体系，它正成为软件工程界的研究焦点，同时正在引起各个相关产业领域高度的关注【2 5 1 。m d a 作为一种新的软件开发的思想和理念，受到了业界的热烈响应和广泛的支持。m d a 被软件工程方面特别是面向对象技术的专家预言为未来几年中最重要的方法学【1 4 】。3 1m d a 产生的背景早在1 9 8 9 年，为了解决跨平台的软件互操作问题，由软件技术供应商、发布者和最终用户共同发起成立了对象管理组织o m g 。它的工作重点是为应用开发提供一个公共的框架，制定工业指南和对象管理规范，加快对象技术的发展。这个组织所提出的c o r b a 互操作标准己经成为事实上的工业标准。然而，仅仅依靠孤立的接口标准所能达到的跨平台互操作能力并不能满足需求。同时j 2 e e 、c o m d c o m 等平台技术的出现使得支持不同技术标准的中间件并存。这种中间件分化现象所带来的中间件平台之间的互操作障碍，直接导致了企业必须为不同中间件的应用系统集成付出代价。因此在这种情况下，如何解决信息化系统建设的互操作性、可移植性、可重用性等问题，成为了软件领域的重要课题【2 5 1 。从1 9 9 7 年起，o m g 在继续推动c o r b a 平台技术及标准的同时，将其工作范围进行了重大的拓展，陆续颁布了几个重要的技术无关建模标准，包括统一建模语言u m l ( u n i f i e dm o d e l i n gl a n g u a g e ) 、元对象设施m o f ( m e t ao b j e c tf a c i l i t y ) 、x m l元数据交换x m i ( x m lm e t a m o d e li n t e r c h a n g e ) 和公共仓库元模型c w m ( c o m m o nw a r e h o u s em e t a m o d e l ) 等。这四个建模标准面向各种软件平台技术提供通用的模型设计规范，实现系统设计过程中企业商业逻辑与实现技术相分离，保证企业的商业应用在不同实现平台上的互操作性、可移植性、可重用性。为了更好地挖掘众多建模标准的潜力，促进和规范建模技术的进一步发展，制定一个清晰的体系结构势在必行。作为在软件互操作领域最有影响力的组织o m g 于2 0 0 1 年7 月发布了模型驱动体系结构m d a 。m d a 的核心思想是用更高抽象层次的模型代替原来的代码作为核心来开发软件，解决传统软件开发模式中软件设计中所做的模型和文档与编码实现中的代码存在的严重不致的问题，使软件开发过程自始至终都保持高度一致，从而大革1m d a 的需求i 的研究f i 垃计幅度提曲软f l ”发效辛：，增强软件的j 移植件、制l 。作能，j 和可维护陀，为文档编制的便利肚指明道路【“i 。32 1m d a 结构框架3 2 m d a 体系架构模j 叫二j | _ i 动垫构j 耍足分孙l p 务功能设- j 实现技术之削的紧耦合关系，将关注点放在系统应用本身丽非- ；j 什、r 台，从而减小技术变化刈系统所造成的影响。m d a 的核心足址模和模型映身j 技术，包含丁o m g 的系列标准：元埘缘设施m o f 、统一缱横语南u m l 、公共数据仓阼，l 模型c w m 和i 模刑交换机：+ j u x m i 。其结构示意图f 【 i 图31 1 ：6 惭示。m 晰幽31m d a 结构孙意阁1 ) m o f ：它是m d a 的核心部分。m d a 允许不同格式的数据同时? 在。片日使用m o f , 其进行统的定义，突破r 以往数掘格式统昔理的模式，使得各种元模型u r 以丰h 瞳映射，相互交换元数据。2 ) u m l ：它是标准的图形化建模语言，是m d a 的基础部分。它既町以用静志模划( 类对象图) 对类进行定义，对类之间的关系进行描述，还可以使用协作斛、序列幽、状态图等动态行为模型进行动作行为的建模，它以，格而 一右的语义表达能力减少了建模过程中的信息失真。3 ) c w m ：它足一种数槲模型的模型几模型，它在数摒仓库工具、数据仓怍、r 台和数据仓库存储z 删建立一个商务智能元数据的交换映射机制，例曲i 将数_ 【| i 实伴从关系数据库映射为x m l 格1 = l = 。4 ) x m i ：是璀j x m l 的儿数据交换，它通过柄、准化的x m l 文档格式和艾档第三章m d a 体系结构1 7类型定义d t d ( d o c u m e n tt y p ed e f i n i t i o n s ) ，为各种模型定义了一种基于x m l 的数据交换格式，正是因为有了x m i ，才使得m d a 的平台无关模型灵活地转换成各种平台相关模型。o m g 组织对于m d a 技术提出的四个原则【2 7 】【2 8 1 ：1 ) 一种良好的符号表示的模型是理