硕士学位论文-用例驱动的交互式需求获取技术及支持工具.pdf

西北大学 硕士学位论文 用例驱动的交互式需求获取技术及支持工具 姓名：刘旭勇 申请学位级别：硕士 专业：计算机软件与理论 指导教师：鱼滨 20080608 西北大学学位论文知识产权声明书 本人完全了解西北大学关于收集、保存、使用学位论文的规定。 学校有权保留并向国家有关部门或机构送交论文的复印件和电子版。 本人允许论文被查阅和借阅。本人授权西北大学可以将本学位论文的 全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫 描等复制手段保存和汇编本学位论文。同时授权中国科学技术信息研 究所等机构将本学位论文收录到中国学位论文全文数据库或其它 相关数据库。 保密论文待解密后适 学位论文作者签名： d 。d 筘厶月j 日 孑咖召年6 月彦e l 西北大学学位论文独创性声明 本人声明；所里交的学位论文是本人在导师指导下进行的研究工作及取得的研究 成果据我所知，除了文中特别加以标注和致谢的地方外，本论文不包含其他人已经 发表或撰写过的研究成果，也不包含为获得西北大学或其它教育机构的学位或证书而 使用过的材料与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确 的说明并表示谢意。 学位论文作者签名： d d dg 年辨孑 摘要 需求获取是系统开发过程至关重要的一步，它是用户到软件工程人员之间的 一道桥梁，软件工程人员通过需求获取得到用户的意图，形成软件编制的依据。 需求获取的好坏直接关系到软件的成功与否，是软件生命周期中的关键步骤。 本文主要论述在u m l 中没有提供需求获取过程情况下，如何使用用例驱动方 法来获取需求，并主要从以下几方面展开研究：第一，详细论述了需求工程、模 型驱动开发( m d a ) 及用例( u s ec a s e ) 驱动技术，为研究奠定理论基础；第二，给 出了需求获取的方法。该方法以用户填表的方式，交互式引导用户表达需求，依 据需求描述信息获取参与者、用例等信息，并进一步获得用例模型；第三，给出 了类图的导出方法。该方法使用c r c ( c l a s sr e s p o n s i b i l i t yc o l l a b o r a t o r ) 技术 获取类，并改进了c r c 结构，为类图导出打下良好的基础；第四，设计并实现了 需求获取支持工具；第五，应用需求获取工具详细地给出了教学管理系统的需求 获取过程，导出了用例图和类图。 关键词：需求获取；用例；参与者；类图； u s ec a s edriv e nr e q uir e m e n teiicit a tio nt e c h n oio g ya n d s u p p o r tt o o if o r in t e r a c tiv ea c c e s s a b s t r a c t t h e r e q u i r e m e n t e l i c i t a t i o ni sv e r yi m p o r t a n to n es t e pi n t h es y s t e m p e r f o r m a n c eh i s t o r y ，i ti s ab r i d g eu s e r sb e t w e e ns o f t w a r ee n g i n e e r i n g p e r s o n n e l ，t h es o f t w a r ee n g i n e e r i n gp e r s o n n e lo b t a i n su s e r si n t e n t i o nt h r o u g ht h e r e q u i r e m e n t e li c i t a t i o n ，f o r m st h eb a s i sf o r t h es o f t w a r ee s t a b li s h m e n t t h e r e q u i r e m e n te l i c i t a t i o n sq u a l i t yd i r e c tr e l a t i o ns o f t w a r e ss u c c e s so rn o t ，i s c o m m i t t e ds t e pi nt h es o f t w a r el i f ec y c l e t h i sa r t i c l em a i ne l a b o r a t i o nh a sn o tp r o v i d e d r e q u i r e m e n t e li c i t a t i o n p r o c e s ss i t u a t i o ni nu m l ，h o wt ou s e t h eu s ec a s ed r i v e nm e t h o dg a i n st h e r e q u i r e m e n t ，a n dm a i n l yl a u n c h e st h er e s e a r c hf r o mt h ef o ll o w i n gs e v e r a la s p e c t s ： f i r s t ，e l a b o r a t e dt h er e q u i r e m e n t se n g i n e e r i n g ，m d aa n du s ec a s ed r i v e nt e c h n o l o g y i nd e t a i l ，l a y st h er a t i o n a l ef o rt h er e s e a r c h ：s e c o n d ，g i v e nt h er e q u i r e m e n t e l i c i t a t i o nm e t h o d t h i sm e t h o dw h i c hf i l i so u taf o r mb yt h eu s e r ，t h ei n t e r a c t i v e g u i d a n c eu s e re x p r e s s i o nr e q u i r e m e n t ，b a s i sr e q u i r e m e n td e s c r i p t i o ni n f o r m a t i o n a c q u i s i t i o na c t o r ，u s ec a s ea n df u r t h e ro b t a i n s t h eu s ec a s em o d e l ：t h i r d ，g a v e t h e m e t h o dt od e r i v ec o l l a b o r a t i o nd i a g r a m t h i sm e t h o du s e dc r c ( c l a s s r e s p o n s i b i l i t yc 0 1 1 a b o r a t o r ) t og a i nc l a s s ，a n di m p r o v e dt h ec r cs t r u c t u r e ，d e r i v e s f o rc o l l a b o r a t i o nd i a g r a mt ob u i l dt h eg o o df o u n d a t i o n ：f o u r t h ，d e s i g n e da n d r e a l i z e dt h er e q u i r e m e n te l i c i t a t i o ns u p p o r tt o o l ：f i f t h ，t h ea p p l i c a t i o n r e q u i r e m e n t e l i c i t a t i o nt o o h a sg i v e nt h et e a c h i n gm a n a g e m e n ts y s t e m s r e q u i r e m e n t e l i c i t a t i o n p r o c e s s ，d e r i v e du s e c a s ed i a g r a ma n dc o l l a b o r a t i o n d i a g r a m k e yw o r d s ：r e q u i r e m e n te l i c i t a t i o n ；u s ec a s e ； a c t o r ； c o l l a b o r a t i o nd i a g r a m 2 第一章绪论 1 1 课题研究背景及意义 需求工程是随着软件工程的发展而产生的。在软件开发的初级时期，软件规 模不大，软件开发所关注的是代码编写，软件需求很少受到重视。在引入软件生 命周期的概念后，需求工程成了软件生命周期的第一阶段。随着软件系统规模的 扩大，以及为了解决“软件危机而引起的软件工程技术与方法的发展，需求工 程在整个软件开发与维护过程中就显得越来越重要了。人们普遍认识到，充分研 究软件需求可以避免开发系统时的盲目性，能够直接关系到软件的成功与否。随 着软件工程的研究和应用的逐渐深入，人们同时认识到软件需求不再仅限于软件 开发的最初阶段，它贯穿于系统开发的整个生命周期n3 。虽然与“软件危机”一 起诞生的软件工程方法和建模理论己经发展了几十年，取得了长足的发展与进 步，但实践证明，软件项目开发过程中存在的问题仍然相当严重，人们经常会看 到有头无尾的工程、用户不满意的工程、难以投入使用的工程或者严重超支和拖 延进度的工程乜3 。这些现象的产生往往是因需求问题而造成的。美国知名的市场 研究公司s t a n d i s hg r o u p 的c h a o sr e p o r t s 垮艮导了该公司的一项研究，该公司 对3 5 2 个公司的8 0 0 0 多个软件项目进行调查后发现，7 4 的项目是失败的，即这 些项目不能按时或按预算完成。为了更深入地了解问题的所在，s t a n d i s hg r o u p 也对引起这些失败的原因进行了调查。调查结果表明，其中导致项目失败的大多 数原因都与需求有关。c h a o sr e p o r t s 的工作人员指出：“如果没有弄清楚软件 项目需求，则该项目一定会失败：如果弄清楚了需求，则项目一定会交付”h 。 虽然人们提出了解决需求获取问题的很多技术与方法，但仍然难以从根本上 解决需求问题。美国咨询公司l e f f i n g w e l l 的报告晴1 指出，软件项目中4 0 - - - - - 6 0 的问题根源都是在需求阶段埋下的，而这些问题放到产品发布后再改正，比起在 需求阶段就立即改正，需要多付出6 8 - 2 0 0 倍的成本阳1 。传统的结构化软件开发方 法在需求阶段侧重的是业务数据或者是业务流程，却没有把二者结合起来考虑， 开发出来的产品结构复杂难以维护、可重用性差。面向对象技术把数据及其处理 过程集成到类中，克服了结构化方法的缺点，但是忽视了用户的需求。以前说软 件开发技术，往往忽视了用户j j 。是软件产品的最终使用者，大多数公司主要注意 的是实现阶段的技术，需求阶段草草了事的居多，他们大多以功能为中心而忽视 了用户的参与，通常会导致最终产品与客户间的期望差异。但是随着软件业的发 展，现在很多公司也己经注意到了需求技术的重要性。解决需求问题的技术和方 法在很多传统的大型软件开发项目中得到了较好的使用，但同时也遇到了很多问 题，如何快速地获取和准确地理解、表达用户需求，是长期困扰软件开发者的难 题。一方面，软件开发者由于不了解应用领域，只能被动地等待领域用户提供信 息，他们常常抱怨用户需求不全，经常变化，使他们无所适从；他们还难免对领 域用户的描述产生错误的理解，因而得出不适当的需求模型，导致软件开发半途 而废。另一方面，领域用户通常不知道如何按软件开发的要求去描述他们的需求， 而且，他们一开始常常对自己的需求仅有一个模糊的认识，如果没有任何提示和 引导，就不可能立刻给出正确而且完整的需求描述。确定系统的需求是一个连续 的过程，丌发人员在开发系统之前不可能完全详细地说明一个系统的真正需求。 一个不完整的需求获取和管理过程，会对项目的生命周期产生多米诺骨牌的效应 口1 。用户需求的缺失会导致系统需求的缺失，从而导致设计单元及功能的缺失， 并最终导致系统不能实现预期的功能，或者需要在后期花费较大的代价来修正或 补充这些功能，导致项目延期、产生严重的质量问题或超出项目预算。因此，及 时、准确地获取用户需求，是决定软件项目能否取得成功的关键步骤之一。 用例分析法是一种常用的需求获取技术，它被吸收到统一建模语言u m l 中， 使得获取有用的用例模型成为基于u m l 面向对象建模的需求分析中的首要任务。 u m l 中用例模型是凭借简单的图形符号和接近自然语言的规格描述来获取系统与 不同用户进行交互的状况，它的出现缩小了用户与开发人员的距离，并且驱动着 软件开发的其它过程。 1 2 国内外研究现状 自从在1 9 9 2 年j a c o b s o n 首次提出用例的概念，用例导出方法就一直是一个 热点和难点问题，到目前为止国内外主要有以下几个代表性的用例导出方法： 1 国外的代表是a 1 i s t a i rc o c k b u r n 在2 0 0 1 年提出了需求分析中的利益模 型以及项目相关人员( s t a k e h o l d e r ) 模型和通信模型扭1 ，c o c k b u r n 的模型如下： 用例：代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描 述了在不同的条件下，系统对某一项目相关人员的请求所做出的响应。 ( 1 ) 项目相关人员：指契约的参与者，是对用例的行为具有特定利益的人或物。 但是c o c k b u r n 并没有给出发现项目相关人员的方法。 ( 2 ) 通信模型：责任目标一动作一模型。c o c k b u r n 的通信模型的问题是可验 证性不够，即当追究某一件事情是谁的责任的时候有很多的情况追究不清楚。 2 国内的代表是u m l c h i n a 提出的用例导出方法阳1 ，认为导出用例的思路是系 统参与者一系统事件一系统用例。这种方法最大问题是关于系统事件的确定很困 难，无章可循。 虽然这两种方法都可以导出用例，但是存在的问题是： ( 1 ) 操作性不够。u m l c h i n a 中的最大问题是关于系统事件的确定很困难，无 章可循。而c o c k b u r n 的通信模型的问题是可验证性不够，即当追究某一件事情 是谁的责任的时候有很多的情况追究不清楚。 ( 2 ) 不方便发现有没有遗漏的用例。 除以上方法外，很多学者也尝试做过研究，比如： ( 1 ) 中国海洋大学提出的s i r g a v 用例导出模型n0 | ，即( 项目相关人员 ( s t a k e h o l d e r ) 一利益( i n t e r e s t ) 一责任( r e s p o n s i b i l i t y ) 一目标令( g o a l ) 一动作令( a c t i o n ) 一利益流程图验证( v a l i d a t i o n ) 。因为牵扯到利益分析问题， 因而这种方法对客户的组织结构要求比较高，难于应用于组织结构不是十分规范 的客户。 ( 2 ) 西北大学提出了一种适合于信息流系统的用例构造方法r g f f 用例构造 框架口。本方法以参与者为中心，首先分析出参与者的责任( r e s p o n s i b i l i t y ) ， 然后根据责任得到参与者的目标( g o a l ) ，接着根据目标得到输入信息( f e e d i n ) ， 由输入信息分析出输出信息( f e e d b a c k ) ，最终导出系统的用例。但该方法的用例 的粒度难以控制，而且采用自然语言描述，不能克服自然语言带来的二义性。 1 3 本文所做的主要工作 需求捕获过程是一个复杂问题，对于不同种类的软件很难用一个标准的过程 来完成需求捕获工作，因此应该针对不同种类软件应有不同的需求捕获方法。本 文就是采用用例驱动技术，并以交互式表格界面，以用户填表的方式，引导用户 表达出需求。获取的结果是建立用例模型和导出类图。 1 给出需求获取的方法 需求获取是后期分析和建模的基础。软件需求获取的主要任务是弄清楚用户 企图通过软件所达到的目的，归纳并整理用户提出的各种问题和要求，从非形式 要求陈述中提炼出用户真正的需求。需求获取过程常常涉及各方面的系统利益相 关者( s t a k e h o l d e r ) ，因此在实践中非常困难。软件规模的不断扩大、软件系统 环境的频繁变化更增加了这种困难。基于这种情况本文以用户填表的方式，交互 式引导用户表达需求，依据需求描述信息获取用例等信息，并进一步获得用例模 型。 2 给出了类图导出方法 类图技术是面向对象方法的核心技术。类图描述了系统中的类及其相互之间 的各种关系，其本质反映了系统中包含的各种对象的类型以及对象间的各种静态 关系。本文采用的是c r c ( c l a s sr e s p o n s i b i l i t yc o l l a b o r a t o r ) 技术，并改进了 c r c 结构，这项技术让对象的设计者更加抽象地从职责分配和协作角度思考问题， 为类图导出打下良好的基础。 3 设计并实现了需求获取的支持工具 结合本文提出的用例和类的导出方法，以用例( u s e c a s e ) 驱动技术为基础设计 交互式需求获取支持工具，该工具以表格为界面来填入需求相关信息，生成x m l 格 式文档，为进一步转换用例图，类图等提供支持。 2 1 需求工程 第二章需求工程及相关技术 2 1 1 软件需求和需求工程 随着信息技术的发展，软件需求( 以下简称需求) 愈来愈复杂，规模愈来愈大。 软件需求工程作为软件生命周期的第一个阶段，并贯穿于整个软件生命周期，人 们对需求工程的认知也愈来愈深刻。但是，即使如此，到目前为止学术界尚未对 软件需求的相关概念或术语给出统一的定义。人们只是通过对这些概念或术语的 描述，来理解这些概念。 在早期的软件系统开发过程中，需求往往被定义成一个要求软件系统应该实 现某些业务功能的规格说明n2 j 。这些规格说明是关于系统行为或系统特性和属性 的描述，也可以是对系统开发过程的约束。但是，这种定义过于笼统，软件项目 开发人很难从中去理解需求的真实含义，而且由于存在着认知上的差异，人们对 规格说明的理解也很难形成统一的认识。随着问题规模的复杂化以及信息技术的 进步，有人认为需求应是问题信息和系统行为、特性、设计及制造约束的描述的 集合。r a t i o n a l 把需求定义为“系统必须符合的条件或具备的功能”n3 | 。i e e e 软件工程标准词汇表( 1 9 9 7 年) 中定义需求为包括如下内容的一组描述。 ( 1 ) 用户解决问题或达到目标所需的条件或能力。 ( 2 ) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的 条件或能力。 ( 3 ) 一种反映上面( 1 ) 或( 2 ) 所描述的条件或能力的文档说明。 著名的需求工程设计师m e r l i nd o r f i n a n 和r i c h a r dh t h a y e r 提出了一个包 容且更为精练的定义。该定义特指软件方面，但不仅仅限于软件。软件需求可定 义为： ( 1 )用户解决某一问题或达到某一目标所需的软件功能。 ( 2 )系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而 必须满足或具备的软件功能。 这个定义从用户和丌发者两个不同的角度阐述了对需求的理解，需求定义了 系统必须具有的能力，一个项目的成功与否往往取决于它是否符合一系列的需 求。 一般而言，人们把所有与需求相关的活动称为需求工程。需求工程是指应用 己证实是有效的技术和方法进行需求分析，确定客户需求，帮助分析人员理解问 题并定义目标系统的所有外部特征的一门学科n4 | ；它通过合适的工具和记号，系 统地描述待开发系统及其行为特征与相关约束，形成需求文档，并对用户不断变 化的需求演进提供支持n5 1 。需求工程是一个包括创建和维持系统需求文档所必需 的一切活动的过程n 引。 2 1 2 需求工程方法 需求工程的方法学发展很快，对需求工程方法学的不同侧面的研究和一些经 典论述，为需求工程的发展奠定了理论基础。需求工程方法大致可分为七类，如 图2 i 所示。 图2 1 需求工程方法的分类 图2 1 所示的每一种方法，都是从不同的侧面来分析需求，每种方法也有各 自的优点和缺点。 面向过程的分析方法主要研究系统输入输出的转化方式n7 。，对数据本身及控 制方面并不很重视。 面向数据的方法强调以数据结构的方式描述和分析系统状态。典型的方法有 j s d ( j a c k s o ns y s t e md e v e l o p m e n t ，j s d ) 方法和关系实体模型法。 面向控制的方法强调同步、死锁、互斥、并发以及进程激活和挂起，数据流 图就是典型的面向控制的方法，结构分析设计技术( ( s t r u c t u r ea n a l y s i sa n d d e s i g nt e c h n i q u e ，s a d t ) 是以面向控制的方法为辅的。 面向知识的方法是在特定需求领域的知识库基础上，帮助分析人员建立和修 订需求规格。其核心是缩小非形式化和形式化需求规格的距离，实现前者到后者 的转化，从人工智能的角度来看，面向知识的方法所面临的主要问题是知识获取。 面向视点的方法认为，需求之间的冲突往往是由于涉众视点不同所导致，因 此，完整而一致地发现和集成视点是获得高质量需求的关键。 面向方面的方法n 8 1 通常将功能性需求作为一组基础，而将非功能性需求作为 方面级( a s p e c t u a l ) 的需求。面向方面的方法从面向方面的编程 ( a s p e c t o r i e n t e dp r o g r a m m i n g ，a o p ) 方法发展而来，目前较为成功的应用主 要集中在需求的实现，如构件技术中。 面向对象( ( 0 b j e c t 一0 r i e n t e d ，o o ) n 盯的方法把分析建立在系统对象以及对象 间交互的基础上，通过对象的属性、分类结构和集合结构，定义和沟通需求，从 对象模型、动态模型和功能模型三个方面对问题进行描述。 从需求工程的研究来看，把客观世界看成对象的集合更接近人类的自然思维 方式。面向对象思想曾经遭受一些人的批评，理由是用户关心和理解的只是系统 的功能，而不可能去学习面向对象模型，所以虽然面向对象的建模缩小了分析设 计和编码的鸿沟，但却拉大了与用户的距离。幸运的是，用例技术的出现，使这 一情况得到了极大的改观。在统一建模语言( u n i f i e dm o d e l i n gl a n g u a g e ，u m l ) 中，面向对象建模的第一步是用例的分析，用例体现了系统的功能单元。系统的 外部人员或其它系统通过与用例交换消息来把握系统的功能，弥补了面向对象建 模和用户之问的距离。面向对象建模正在成为需求工程中的一个研究热点，并展 现出良好的应用前景。 2 1 3 需求工程的内容 需求工程的目的是通过与用户广泛地交流，以确定应用系统的目标，需求活 动以“工程化”的方法被提出、分析和组织。需求工程主要包括4 个阶段，如图 2 2 所示。 图2 2 需求工程的内容构成 1 需求获取 需求获取是在问题及其最终解决方案之问架设桥梁的第一步，这一阶段的工 作一旦做错，将最终会给系统带来极大损害。由于需求获取失误造成的对需求定 义的任何改动，都将导致没计、实现和测试上的大量返工，而这时花费的时间和 资源，将会大大超过仔细、精确地获取需求时所花费的时间和资源n 。 要想开发正确的系统，就需要尽可能详细地描述需求，即系统必须达到的条 件或能力，使用户和开发人员在“系统应该做什么，不应该做什么”方面达成共 识。当然，需求的获取并不仅仅是指用户知道需求是什么，系统开发人员就通过 与他们进行交流就能够用户那罩得到需求，除此之外，开发人员只要向用户询问 系统的目标特征，什么是要完成的，什么样的系统能适合业务需要就可以了。事 实上，在与用户沟通的路上布满了荆棘。 2 需求分析 需求分析是指在需求丌发过程中，对所获取的需求信息进行分析，消除错误， 弥补不足，刻画细节，以确保需求文档能够币确地反映用户的真实意图。需求分 析的目标是能够更加深入地描述软件的功能和性能心，确定软件设计的约束和软 件同其它系统元素的接口细节，定义软件的其它有效性需求等。需求分析的任务 就足借助于当前系统的逻辑模型导出目标系统的逻辑模型，确定为了满足用户的 需求系统必须做什么的问题。需求分析中的主要活动是需求建模，即采用一种符 号体系来描述与刻画需求，为最终用户所看到的系统建立一个概念模型。作为对 需求的抽象描述，应尽可能多地去捕获现实世界的语义。 3 需求描述 需求描述的目的是根据需求获取和需求分析的结果，进一步定义准确无误的 软件需求，产生需求规格说明书。需求规格说明书的重点是阐述“做什么“ ，而 不是阐述“怎么做“ 。“怎么做”乜2 1 的问题是系统设计和实现阶段的主要工作。需 求规格说明是需求工程的主要结果，它阐述了一个软件系统必须提供的功能和性 能以及所要考虑的限制条件。需求规格说明不仅是系统测试和用户文档的基础， 也是所有子系列项目规划、设计和编码的基础，同时也是开发商和用户之间制订 合约的重要依据。需求规格说明应该尽可能完整地描述系统预期的外部行为和用 户可视化行为，其基本内容应包括功能性需求和非功能性需求。功能性需求主要 说明了系统各功能部件与环境之问的相互作用的本质，即拟开发软件在职能上实 际应该做什么。一般来说，它是用户主要需求，通常包括系统的输入、系统能完 成的功能、系统的输出以及其它反应等。非功能性需求也称为系统的“约束“ ， 它主要从各个不同的角度对所考虑的可能的解决方案进行约束和限制，包括可移 植性、可靠性、效率、可用性、安全性、可重用性等性能指标，都是非功能性需 求的典型内容。除了设计和实现上的限制外，软件需求规格说明不应该包括设计、 构造、测试或工程管理上的细节。 4 需求管理 需求管理是c m m 可重复级( 第二级) 的第一个关键过程域瞳引，其主要目标是在 用户与开发人员之间建立对需求的共同理解，以维护需求与其它工作成果的一致 性并控制需求的变更，保持开发项目的计划、活动与软件需求的一致性。需求管 理过程和软件开发过程是并行的，且贯穿在整个软件开发的生命周期之中。需求 管理的主要内容包括：需求确认、需求跟踪和需求变更控制。 ( 1 ) 需求确认：需求确认是指开发人员和客户共同对需求规格说明书进行评 审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同的效果。需 求确认包含两个重要工作：“需求评审”和“需求承诺”。其中，需求承诺是指开 发方和用户方的责任人对通过了f 式技术评审的需求舰格说明书作出的承诺，该 承诺具有商业合同的效果。这样做也可为需求获取阶段的双方良好沟通提供保 证。但是，由于不可能在项目的早期阶段就了解项目的所有需求，而且需求将会 1 3 毫无疑问的出现变更，所以，对需求确认的理解应该是这样的，即用户方同意了 这份需求文档，则表示开发人员己经对项目软件需求有所了解，进一步的变更可 以在此基础上通过项目定义的变更过程来进行。用户方知道变更可能会使开发人 员重新协商成本、资源和项目阶段任务等事宜，对需求达成一定的共识会使双方 易于忍受将来的摩擦。需求确认显现出需求的真面目，给初步的需求开发工作画 上了双方都明确的句号，有助于形成一个持续良好的客户与开发人员的关系，为 项目的成功奠定了坚实的基础。 ( 2 ) 需求跟踪：需求跟踪是指通过比较需求文档与后续工作成果之间的对应 关系乜4 。，确保软件项目是依据需求文档进行开发的。需求跟踪是需求管理的基础， 同时也是需求变更控制的基础。可跟踪性是指两个或多个实体之间具有定义好的 链接或关系乜5 1 ，可以从一个实体跟踪或回溯到另一个实体。实现对需求的跟踪， 即跟踪一个需求使用的全过程，也就是从最初的用户需求到设计实现的整个生存 期。需求跟踪的目的是建立与维护“需求一设计一编程一测试”之间的一致性， 确保所有的工作成果符合用户需求。要实现在软件生命周期各个阶段对需求的跟 踪，其前提条件是在各个阶段都必须有比较完善的文档堙6 | 。例如，需求工程阶段 的需求规格说明书，设计阶段的设计文档，以及需求实现阶段的源代码等。这些 文档之间的层次关联关系是实现需求跟踪的基础。在这些元素间建立了跟踪关系 后，就可以将每项需求从最初的业务需求一直跟踪到测试这项需求的测试用例。 同样，也可以根据这条跟踪关系链回溯到项目的业务需求。 需求跟踪的一种通用方法是采用需求能力跟踪矩阵乜7 i 。建立需求能力跟踪矩 阵的前提条件是将在需求链中各个过程的元素加以编号，以便使用数据库进行管 理，使需求的变化能够立刻反映为整条需求链的变化。需求跟踪矩阵并没有固定 的实现办法，每个团体注重的方面不同，所创建的需求跟踪矩阵也不同，只要能 够保证需求链的一致性和对状态的跟踪，就可达到所要求的目的。对需求进行跟 踪在一定程度上也可以保证对开发项目的进度控制。 ( 3 ) 需求变更控制：在软件丌发过程中，需求变更不可避免，甚至是必须的， 变更有助于最大限度地满足用户需求。但是，在软件开发过程中需求的变更会给 项目开发带来不确定性。变化并不是可怕的，可怕的是不能迅速地作出反应。所 以正确地认识需求变化并作出相应的管理变更计划，有效地管理需求变更使项目 始终处于控制之下，这样，软件开发的进度、成本和质量，也就有了“安全“ 的 基础。 变更控制是指对变更申请、变更评估和变更实施等进行控制的过程。需求变 更是指在软件需求确定后所增添的新需求或对已经存在的需求所进行的修改1 。 问题不仅仅是需求变更本身，而是迟到的需求变更会对己进行的工作有较大的影 响，若不加以控制，就会导致项目开发人员不断采纳新的需求，不断地调整项目 计划进度、成本以及质量目标，最终导致项目的失控。因此，需求变更控制是需 求管理的关键。值得注意的是变更控制过程并不是给变更设置障碍，相反，它是 一个渠道和过滤器，通过它可以确保采纳最合适的变更，使变更产生的负面影响 减少到最小。变更控制过程应该尽量文档化，尽可能地简单、有效。如果变更控 制过程效率低下且拖沓冗长，又很复杂，那么该控制过程将没有任何意义。结合 以往的开发经验，需求变更控制步骤可归结为如下几点： 变更申请。变更申请人向变更控制委员会( ( c h a n g ec o n t r o lb o a r d ，c c b ) 提交变更正式申请，重点说明“变更内容“ 和“变更原因”，可以要求预评审， 也可以越过预评审。 受理与分析变更申请。变更控制部门或c c b 成员小组分析这个变更请求， 确定它是新的要求，还是修改请求，或者是误解：变更请求所针对的真实需要是 什么：完成该请求的成本如何。根据需求的链式结构，确定受其影响的其它部分 需求。 审批变更申请。c c b 成员通过对变更的分析与讨论，对变更请求进行投票， 由e g g 负责人审批并发布结果。如果同意变更的话，则转向第四步，否则终止。 安排变更任务。c c b 指定变更执行人，安排他们的任务。 执行变更任务。变更执行人根据c c b 安排的任务，修改需求项。 对更改后的需求项重新进行技术评审( 或审批) 。 结束变更。当所有变更后的需求项都通过了技术评审或领导审批，这些 需求项的状态就从“正在修改“ 变迁为“正式发布”，本次变更即告结束。 2 1 4 需求工程存在的问题 需求工程是软件工程中最复杂的过程之一，其复杂性来自于客观和主观两个 方面。从客观意义上说，需求工程面对的问题几乎是没有范围的心9 | 。由于应用领 域的广泛性，它的实施无疑与各个应用行业的特征密切相关，这为获取需求增加 了困难，主要原因有如下几点： ( 1 ) 缺乏领域知识、应用领域的问题常常是模糊的、不精确的： ( 2 ) 存在默认的知识，即难以描述的日常知识( 常识问题) ： ( 3 )存在多个知识源，而且多知识源之间可能有冲突。 从主观意义上说，需求工程中最重要的一个因素就是人的因素。需求工程需 要方方面面人员的参与，如软件系统用户、问题领域专家、需求工程师和项目管 理员等，这些人员往往具有不同的背景知识，且处在不同角度，扮演着不同角色， 从而不可避免地造成了他们之问相互交流的困难圳。而且，在项目开发中最难办 的事情是莫过于拒绝客户提出的需求变更请求。通常情况下丌发人员是不敢得罪 客户的，但是无原则地退让将使丌发小组陷入困境。解决这个问题最好的办法是 事先建立游戏规则：开发人员可以与客户方达成事不过三的约定( 符合中国人的 习惯) ，即允许客户变更三次需求：如果客户第四此变更需求，开发人员有权拒绝， 除非客户愿意补偿开发人员的损失。下面这幅漫画虽然不乏夸张，但的确反映了 需求工程的真实问题，如图2 3 。 图2 3 软件需求曾让我们如此狼狈 造成这一现象的根本原因在于客户与丌发人员之间的沟通存在障碍，双方都 以自己的角度、自己的专业术语进行沟通，这使得大家并不能够很好地就软件需 求达成共识。事实上，许多开发团队经常抱怨：他们的客户连需求都说不清楚， 他们的客户对计算机了解太少了等。多年以来，大家都习惯从自己的角度来定义 问题、分析问题，这也就造成了软件行业成为了一个最缺乏信任的行业，而实际 上帮助客户更好地利用信息化工具以提高工作效率，是软件开发团队的责任，因 此没有权利让用户理解开发人员所用的语言，而是反过来，软件开发团队有义务 去理解用户的语言，站在用户的角度看问题。 2 2 模型驱动开发 2 21m d a 概述 对象管理组织( o m g ) 成立于1 9 8 9 年，该组织的工作重点是为应用开发提供一 个公共的框架，制定工业指南和对象管理规范，加快对象技术的发展。其主要技 术目标是：使得基于对象的软件在分布异构环境下具有良好的可重用性、可移植 性和互操作性，从而能够在由多种主流平台上运行多种操作系统构成的异构分布 环境中方便地建立异构分布式应用系统。它以提供开放的、与开发者无关的互操 作规范为使命，从而帮助计算机使用者解决跨平台问题。 从1 9 9 0 年开始，o m g 就开始致力于解决企业应用集成的问题，并制定了跨平 台的应用集成和互操作的标准- - - c o r b a 。c o r b a 允许对象在异构的平台上进行交 互。然而c o r b a 并不是唯一的中间件平台，像n e t 、j 2 e e 都提供了类似的服务， 所以目前的中间件技术并不足以解决企业问跨平台计算的要求。为此，o m g 提出 了模型驱动框架( m d a ) 的概念，但是不同的是m d a 致力于解决的是现在已经部署 的复杂企业系统上的集成问题 模型驱动框架是一种i t 系统规范的方法，它分离了系统功能规范和其在特 定技术平台上的实现。m d a 方法和支持它的标准，使得规范系统功能的同一个模 型可以通过辅助变换标准，或通过点变换到特定平台，从而在多平台上实现。同 时，它可以使得不同的应用程序通过清晰的模型联系而集成在一起。这样就促进 了集成性和互操作性，并支持随着平台技术变迁的系统演化。 正如d a v i df r a n k e l 所说的：”m d a 是将建模语言作为一种编程语言来使用， 而不是仅仅作为一种设计语言来使用”m d a 的基本原理就是通过提高抽象的层 次，使模型在软件开发过程中扮演了非常重要的角色。它是一种用于构建企业应 用的新方法。其目标就是以模型驱动的方式在一个比技术的实现更抽象的层面来 设计应用。m d a 认为系统开发的最好方式就是隔离系统设计与系统实现，独立建 模业务行为和领域元素，关注系统应用本身，而不是将中间件平台作为系统开发 的中心。 在m d a 中有如下的一些核心概念，在此需要做一简要说明： 1 模型 模型是对系统的一部分结构、功能或行为正式规约。首先，模型是一种系统 规约，这种规约可以是对结构的规约也可以是对系统功能或系统行为的规约：其 次，这种规约必须是正式的，即必须使用一种严格定义没有歧义的语言。所以一 个模型必须和一种严格定义了语法和语义的建模语言绑定在一起。根据模型的这 种定义，程序代码也是模型。 2 抽象、视角、求精 一个客观系统的规约可以处于不同层面上。例如，对于一台笔记本电脑，可 以有3 个规约：“一台电脑”、“一台笔记本电脑”、“某某牌某某型号的笔记本电 脑”。如果还要细化下去，还会有无穷的规约来表达这个系统。从这个例子中可 以看出，在一个客观系统中可以挖掘出无穷多的细节，一个系统的任何规约都只 是从一个特定的角度描述了这个系统的某个层面，都是对这个客观系统的某种程 度上的抽象。这种特定的角度或者说抽象的程度就是视角。上述例子中的3 个规 约是一个不断逼近客观现实的关系，这种关系就是抽象和求精。简单地说，抽象 就是略去无关的细节，求精就是现实化口1 | 。 3 缩放 对于系统中的对象和对象之i 、日j 的关系，会有不同抽象程度的模型。抽象模型 中的一个对象，在求精模型中可能由多个对象组成，抽象模型中的个关系，在 求精模型中可能表现为多个关系。从抽象模型中的一个对象( 关系) 到求精模型中 的多个对象( 关系) 的过程称为放，反之则称为缩n 1 | 。 4 平台 “平台”的概念是相当复杂和依赖环境的。一个平台( p l a t f o r m ) 是多种技术 的集合，提供了各种功能接口，它是通用的、和具体技术相关的( 如j a v a ) 或特定 于软件供应商的( 如：微软的n e t 平台) 。在m d a 中，平台的概念包含以下这些技 术： ( 1 )信息格式化技术，如x m ld t d 和x m ls c h e m a o ( 2 )3 g l 和4 g l ，如j a v a 和c + + 等。 ( 3 )分布式组件中间件，如j 2 e e ，d o t n e t ，c o r e 3 a o ( 4 ) 消息处理中间件，如w e b s p h e r em qi n t e g r a t o r ( m q s e r i e s ) 和m s m q 。 5 计算无关模型 计算无关模型( c i m ) 是从用户的角度来描述特定领域所面临的问题及系统需 求的模型。c i m 包含了系统的数据信息等，它代表了生命周期中的需求模型b 2 】 6 平台无关模型 平台无关模型( p i m ) 由系统的数据、处理进程等平台无关的信息组成。一个不 带有任何特定技术细节的系统模型，就是平台无关模型。这种模型描述了系统独 立于任何实现平台的结构和功能特征。p i m 代表了生命周期中的分析模型，只定 义了系统的结构和功能，而不考虑系统的实现细节鹞2 j 7 平台相关模型 平台相关模型( p s m ) 由系统的数据、处理进程等平台相关的信息组成。它包 括了特定技术细节。这种模型描述了建立在特定技术基础上的系统结构和功能特 征。p s m 代表了生命周期中的详细设计模型，定义了系统的功能在特定平台上的 实现方式2 1 。 8 模型变换 m d a 中各种模型扮演着不同的角色，我们希望从一种源模型自动得到另一种 目标模型，这就是模型变换。模型变换由一系列的变换规则组成，形式上可以看 作一个函数。这些变化规则是无歧义的规约，规定了如何从源语言描述的源模型 转换到目标语言描述的目标模型，目标模型的含义必须和源模型的含义一致。由 于m d a 中的p i m 和p s m 都是使用特定的u m l 来描述，所以m d a 中的模型变换主要 是u m l 模型的变换2 】。 2 2 2m d a 模型结构 在m d a 中，模型不冉仅仅是描绘系统，辅助沟通的工具，而是软件开发的核 心和主干。图2 4 描绘了m d a 的模型架构。从中我们可以看到，一个系统从不同 的视角可以为不同模型所描述。这些模型分为3 个层次：计算无关、平台无关、 平台相关，它们之间有着抽象和求精的关系。模型之间通过模型映射机制相互映 射，从而保证了模型的可追溯性船3 。 m d a 模 型 中间件平台 图2 4m d a 模型结构 软件的开发和更新过程就是模型自顶而下，逐步求精的过程。首先由领域专 家构建商务建模( c i m ) ：然后由模型映射专家将商务模型映射到平台无关的计算 模型：最后由平台技术专家将平台无关模型映射到平台相关模型( p s m ) 。将平台无 关模型和平台相关模型显式地分开有下述几个优点： 1 平台无关模型可以被多种实现技术复用，当技术平台发生迁变的时候平 台无关模型不必做改动。 2 由于和具体实现技术无关，平台无关模型可以更加精确地体现系统的本 质特征，因此可以跨越具体的技术圈子进行交流和共享。 3 由于使用了简单的、通用的模型，可以更加容易地对平台无关模型进行 验证。 4 在平台无关模型这个层次上对跨平台互操作问题进行建模非常容易，因 为使用与平台无关的通用术语，所以语义表达会更加清晰。 m d a 的基本思想就是：一切都是模型。软件的生命周期就是以模型为载体并由 模型映射所驱动的过程。 2 2 3m d a 核心技术 建模和模型映射技术是m d a 的核心。元数据的管理和集成可以使用o m g 提出 的一系列标准来完成，它们分别是元对象设施( m e t ao b j e c tf a c i l i t y ，m o f ) ， 统一建模语言( u n i f i e dm o d e l i n gl a n g u a g e ，u m l ) ，x m l 元数据交换( x m l m e t a d a t a i n t e r c h a n g e ，x m i ) ，公共仓库元模型( c o m m o nw a r e h o u s e m e t a m o d e l ，c w m ) 。在o m g 的蓝图中，u m l 、m o f 、x m i 、c w m 等一系列标准分 别解决了m d a 的模型建立、模型扩展、模型交换、模型变换这几个