（计算机软件与理论专业论文）用例驱动需求工程的研究与应用.pdf

摘要 摘要 9 0 年代以来，需求工程己成为研究热点之一用例技术的出现，为面向对 象的软件开发过程中，用户真正地参与到系统中来带来了福音。在o o s p 领域， r u p 以其用例驱动、以体系结构为中心、迭代和增量的开发特点带来了强大的 市场竞争力，颇受用户青睐。 r u p 是一个通用的过程模版，非常庞大，没有一个项目会使用r u p 的全 部东西，在具体的实施过程中还要根据项目的实际情况进行“量体裁衣”针对 信息系统的特点，本文对r u p 进行了适量裁减，提出了用例驱动且具有良好扩 展性的r r u p 需求开发及管理方法。基于此方法本文设计实现了一个需求管理 工具r m b r s 软件开发过程中需求的获取和表示一直是研究的热点和难点，在r r u p 中 采用用例来表示需求。本文提出需求层级表示的观点帮助用户对需求进行“大 局”和“小节”的把握。 用例的导出问题是需求获取时最困难的问题，至今在理论上还没有一致认 可可行的办法。在需求层级表示的基础上，本文提出r g i p o 用例导出方法导出 信息系统的用例为规范用例的描述，本文提供了一个普遍适用的用例模版 针对导出过程中责任归属不清的问题，本文对r g i p o 进行了扩展，采用角色定 岗，分级授权的思想来实现权责分明 在n t o p s s 系统中对本文所提方法进行了实践验证。 关键词：用例，需求获取，用例导出，需求开发，需求管理，层级表示 摘要 t h er e s e a r c ha n d a p p l i c a t i o no f u s ec a s e d r i v e n r e q u i e m e n t se n g i n e e r i n g a b s t r a c t s i n c et h e1 9 9 0 s ，r e q u i r e m e n t se n g i n e e r i n gh a sb g c o m eo n eo ft h es t u d y i n g h o t s p o t s t h ea d v e n to fu s ec a s et e c h n i q u eb r i n g sg o s p e lf o rt h ei l s e l s w h oc a n p a r t i c i p a n tt h eo b j e e t - o r i e n t e ds o f t w a r ed e v e l o p m e n tp r o c e s sr e a l l y i nt h ed o m a i no f o o s p , r u pw i n su s e r sw e l lb yi t ss t r o n gm a r k e tc o m p e t i t i o n , b r o u g h tb yi t s c h a r a c t e r i z e s u s ec a s e - d r i v e n ，c e n t e ro na r c h i t e c t u r e 。a n d d e v e l o pi t e r a t i v e l y a n di n c r e m e n t a l l y r u pi sau n i v e r s a lp r o c e s st e m p l a t ea n di ti sv e r yh u g e t h e r ei s n ta n y p r o j e c t w i l l 峨i tw h o l l y , w en e e d q u a n t i t yf o r md r e s s a c c o r d i n gt ot h ep r o j e c ti nt h e o p e r a t i n gp r o c e s s a i ma tt h ei n f o r m a t i o ns y s t e m sc h a r a c t e r i s t i c s ，t h i st h e s i sb r i n g s f o r w a r dr r u p , w h i c hc a nb ee x t e n s i b l ew e l l ，f o rr e q u i r e m e n t sd e v e l o p m e n ta n d r e q u i r e m e n t sm a n a g e m e n tb yr e d u c i n gr u p t h i st h e s i sd e s i g n sa n di m p l e m e n t sa r e q u i r e m e n t sm a n a g e m e n tt o o l - r m b r sb a s i n go nr r u p r e q u i r e m e n t s c a p t u r ea n de x p r e s s i o ni sa l w a y so n eo ft h es t u d y i n gh o t s p o t s a n dd i f f i c u l t i e s ，r e q u i r e m e n t sa r ee x p r e s s e db yu s ec a s ed u r i n gr r u p t h i st h e s i s p r o p o s e dt h ev i e wu s ec a s e sl a y e r & r a n ke x p r e s s i o nt oh e l pu 潞g r a s pt h e g e n e r a ls i t u a t i o n a n d s m a l ld e t a i l s t h ei n d u c e m e n to fu s ec a s ei st h em o s td i f f i c u l tp r o b l e mw h e nw ec a p t u r e r e q u i r e m e n t s t h e r ei s n tam e t h o da c e e p t e c lg e n e r a l l y 咖s o l v et h ep r o b l e mi n t h e o r yb yn o w t h i st h e s i sa d o p t sr g i p oi n d u c e m e n tm e t h o db a s e do nt h el a y e r & r a n ke x p r e s s i o no fu s ec a s et oe d u c et h eu s ec a s e so fi n f o r m a t i o ns y s t e m t k s t h e s i sg i v e sau n i v e r s a lu s ec a s em o d e lf o rt h er e g u l a t i o no fe x p r e s s i o n t os o l v e t h ep r o b l e mw h o s er e s p o n s i b i l i t yi so b s c u r e ，t h i st h e s i se x t e n d sr g i p om e t h o d ， a d o p t i n gt h et h o u g h ta s s i g n i n ga c t o rt ot h ep o s ta n dd e c e n t r a l i z e da u t h o r i z a t i o nt o r e a l i z et h er i g h tm a t c h e st h er e s p o n s i b i l i t y n 摘要 a p p r o a c h e st h i st h e s i sp u t f o r w a r da r ev e r i f i e di nn t o p s s k e yw o r d s ：u s ec a s e ，r e q u i r e m e n t sc a p t u r e ，i n d u c e m e n to fu s ec a s e ， r e q u i r e m e n t sd e v e l o p m e n t , r e q u i r e m e n t sm a n a g e m e n t , l a y e r & r a n ke x p r e s s i o n i i i 西北大学学位论文知识产权声明书 本人完全了解学校有关保护知识产权的规定，即：研究生在校 攻读学位期间论文工作的知识产权单位属于西北大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和电子版。本人允许 论文被查阅和借阅。学校可以将本学位论文的全部或部分内容编入 有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存 和汇编本学位论文。同时，本人保证，毕业后结合学位论文研究课 题再撰写的文章一律注明作者单位为西北大学。 保密论文待解密后适用本声明。 学位论文作者签名： j 燕峻 指导教师签名：聋亥一 柳年主月3 7 日 年月 日 西北大学学位论文独创性声明 本人声明：所呈交的学位论文是本人在导师指导下进行的研究 工作及取得的研究成果。据我所知，除了文中特别加以标注和致谢 的地方外，本论文不包含其他人已经发表或撰写过的研究成果，也 不包含为获得西北大学或其它教育机构的学位或证书而使用过的材 料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作 了明确的说明并表示谢意。 学位论文作者签名：；巍峻 。o t 年多月引e t 第1 章绪论 i i 研究背景及意义 第1 章绪论 对于计算机软件而言，软件开发方与软件客户方是贯穿软件整个生命周期的 两个最基本的要素。无论软件的规划、开发、测试，还是软件的使用、维护、废 弃，都需要二者不同程度的参与。正是由于二者自始至终的相互制约、相互合作， 才推动着整个计算机软件产业不断地向前发展。而需求分析是二者合作的基石和 关键所在。如果说软件工程概念的形成是解决软件危机的必然结果，那么其子工 程一需求工程的出现才真正体现出软件产品不同于其它产品的一个特性一用户 参与整个产品过程的重要性。 需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求， 帮助分析人员理解问题并定义目标系统的所有外部特征的- - f 学科；它通过合适 的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档， 并对用户不断变化的需求演进给予支持【需求工程可分为系统需求工程和软件 需求工程i ”本文的需求工程指的是软件需求工程。 用例驱动方法自从被提出而又被吸收到u m l 中以来，凭借用例模型简单的 图形符号和接近自然语言的规格描述来获取系统与不同用户进行交互的情况，缩 小了用户、需求分析人员、开发人员之间的差距，并驱动着软件开发的其它过程， 得到了业晃广泛的接受和大规模的应用 用例技术的使用，使得软件的生产效率得到了大幅度的提高，但是用例技术 中仍然存在着很多的问题：如角色和用例的关系不清晰，发现涉众的方法导致用 例的边界定义模糊不清、用例的税度控制问题、用例的组织问题等。 本文在已有的用例驱动需求工程研究的基础上，结合实践经验，提出了适合 于信息系统的r r u f 需求开发和需求管理方法该方法在n t o p s s 的需求开发和 管理中得到了应用，该系统对包括河北、河南、天津、内蒙等在内的九个省市的 电信业务提供了支撑，创造了可观的效益：根据该方法，本文设计实现了r r u f 需求管理工具来辅助需求的管理在需求获取中，用例的导出一直是一个研究热 点和难点，本文基于c o c k b u r n 的通信模型，给出了适用于信息系统的r g i p o 用例 第1 章绪论 导出方法，并针对通信模型归责不清的问题对r g i p o 方法进行了扩展解决责任归 属问题。为了表达方便，本文采用了缩略语，如附录1 所示。 1 2 国内外研究现状 需求关乎系统成败，进入9 0 年代以来，需求工程成为研究的热点之一：从1 9 9 3 年起，每两年举办一次需求工程国际研讨会o s r e ) ，1 9 9 4 年起，每两年举办一次 需求工程国际会议( i c r e ) 。一些关于需求工程的工作小组相继成，例如i f i p 专门 成立的需求工程小组 需求工程的发展趋势是对象化、形式化和自动化，并将向着纵深发展和综合 发展无论是在需求工程的理论研究，还是需求工程的技术实践上，国内外的软 件行业在理论研究领域已提出了很多需求工程方法，如用户主导的需求分析方 法、面向问题、面向对象、面向方面以及数据、面向控制以及传统的面向过程的 方法面向对象是目前最流行最常用的方法。现将与本文相关的面向对象的研究 状况介绍如下： 面向对象的方法把分析建立在系统对象以及对象间交互的基础之上【2 】，使得 我们能以三个最基本的方法框架一对象及其属性、分类结构和集合结构来定义和 沟通需求面向对象的问题分析模型从三个侧面进行描述，即对象模型、动态模 型和功能模型需求工程的抽象原则、层次原则和分割原则同样适用于面向对象 方法，即对象抽象与功能抽象原则是一样的，也是从高级到低级、从逻辑到物 理，逐级细分每一级抽象都重复对象建模( 对象识别p 动态建模( 事件识别) 功能建模( 操作识别) 的过程，直到每一个对象实例在物理( 程序编码) 上全部实现 面向对象的方法正在成为需求分析中的一个热点，并展现出良好的应用前 景y b m d 粕和c o a d 的o o a 方法嘲、b 0 0 c h 【习的方法、j a c o b s o n l 拘o o s e t 4 1 、r u m b a u g h 的o o m 聆l 方法等都是这一方法的典型流派 a o s d ，是对面向对象方法的一种改进，i v a r j a e b o s o n ：e 2 0 0 4 年提了出来嘲， 该方法意在实现关注点的分离a o s d 中也发现一些内容如基础结构，即领域模 型等是无法在多个用例之间切开的，所以又提出了“公共用例”、“基础用例”来弥 补一些其原型的漏洞。到现在为止，a o s d 中用例切片、用例模块还存在许多不 成熟的地方，较少在实际的软件开发中应用 2 第l 章绪论 用例驱动的需求工程是面向对象的需求工程。国外以n a tj a c o b s o n 和a l i s t r a i r c o c k b u m 为代表对用例技术进行了深入的研究，得到了一系列的成梨7 】；在1 9 9 2 年i v a r j a c o b s o n 提出一种用例驱动的软件开发方法：o o s e 4 1 ，其最大特点是面向 用例，并在用例的描述中引入了外部角色的概念用例成为分析模型的基础，用 交互图对用例进一步描述后形成设计的模型。用例是精确描述需求的关键，它贯 穿于整个开发过程，包括对系统的测试和验证。o o s e 比较适合于支持商业工程 的需求分析，用例同时也很好地驱动了测试工作 在面向对象的软件过程领域，主要有三种方法：r u p ，o p e n 过程和o o s p s 1 按照评估软件能力与成熟度的标准一c m m ，o p e n 、o o s p 与r u p 均能支持c m m 关键过程域的2 级到3 级标准。r u p 与o p e n 和o o s p 相比，优势在于与u m l 的良 好集成、有多种c a s e 工具的支持，不断的升级与维护。强大的市场竞争力是目 前r u p 被广泛用作软件开发指导的最重要原因。当然，r u p 虽然是一个完善的过 程，却并不是一个完美的过程，也需要借鉴和吸取其它过程的长处，才能更好地 面对挑战 1 3 主要研究内容 需求具有易变性和难以表述性软件项目中4 0 到6 0 的问题都是由需求阶 段引起的，因此如何做好需求分析验证，有效管理需求变更，对变更需求进行跟 踪维护至关重要。针对需求工程的问题，本文主要工作如下； 1 需求的层级表示 为了保证各类人员在软件需求上达成共识，避免期望差异，在把握需求时兼 顾大局和小节，在业务上根据用户的不同目标完成不同级别的需求，合理安j 非开 发进度，灵活地跟踪需求，本文在对需求分层的基础上，提出了功能需求分级的 观点，本文将功能需求分为三级：组织级、系统级、子系统级，三级之间是逐级 细化的关系；这和c o c k b u m 需求用例表示分为三级是一致的，他将用例分为：概 要级、用户目标级和子功能级本文重点说明了需求层级用例化的相应关系并以 一个模型图予以表示 2 r r u p 需求开发方法 传统的r u p 方法非常庞大，没有一个项目会使用r u p 的所有东西，本文结合 第1 章绪论 信息系统多学科、需求易变、风险大、时间性强等特点，对r u p 进行了裁剪，对 裁减后的r u p ，本文命名为r r u p 本文对r u p 需求相关的业务建模、需求分析、配置与变更三个核心工作流程 进行了裁减。在实现三个工作流程目标，任务的前提下，本文作者认为整个需求 的开发过程是连续进行的一系列工作，由于信息系统时间性非常强，需求又非常 容易变化，为了提高开发的效率和速度，就没有将它们一一划分，只是按照工作 的目标以及里程碑事件将工作归入到需求开发的四个阶段中。因此，本文给出的 每次迭代过程都包含需求调研、分析、验证与维护四个阶段的工作流r r u p 合 并了原来r u p 四个阶段的定义，在改进后的过程中重点应用工作流的迭代，不 再按照阶段来划分迭代过程。 3 r g m o 用例导出方法 在对国内外的理论方法进行深入研究的基础上，结合信息系统的特点，本文 提出了r g i p o 用例导出方法：即责任目标- 输入处理输出并且针对归责 不清的问题，对所提的r g i p o 方法进行了扩展，利用对关键角色定岗即采用角色 的间接授权机制使某个处于某岗位一个特定用户组中 的用户间接获得已定义到该组上的“角色权限”所包含的一系列操作权利，提高 授权效率和灵活性，根据工作安排，可以归责到个人，做到权责分明，解决责任 归属不清的问题。 本文给出了基于r g i p o ，利用需求的层级表示，逐步获取需求、表示需求的 方法，提供了信息系统可通用的用例模型以及基于用例的s r s 模版功能需求的表 示方法来规范需求表示，作者提倡使用流程图、用例描述和界面原型来辅助客户 方的理解。 4 r r i p 需求管理过程 在r u p 需求开发方法的基础上，本文提出了r r u p 需求管理过程，和一般需 求管理的划分方法不同，r r u p 需求管理贯穿于项目开发始终，本文给出了r r i i p 需求开发四个阶段进行需求管理的主要工作、目标和里程碑事件 r r u p 需求管理给出了需求变更实施的一般流程，对需求的状态重新进行了 定义，对本文利用用例表示需求来说即用例的状态，根据层级表示思想，我们总 是把某一个用例归属到某一功能模块下，根据用例的状态，本文提出了定义用例 4 第l 章绪论 所属功能模块的状态，这样便于我们实时掌握需求的完成情况，进行“大局”和 “小节”韵管理。 5 对所提方法进行实践验证 结合n t o p s s 的一个业务需求，对本文提出的r r u p 需求开发和管理方法、 r g i p o 用例导出及其扩展方法进行验证，通过实例证明本文所提方法的可行性 6 根据r r u p 需求管理思想设计需求管理工具 根据r r u p 需求管理思想，设计并实现了基于r r u p 的需求管理系统，辅助 需求管理：r m b r s 嵌入了工作流引擎，有利于支持需求管理过程的自定义：通 过e m a i l 通知需求变更；支持多附件的上传下载：强力支持需求变更和版本管理； 可使用查询统计功能把握系统的进展情况。系统采用基于j 2 e e 软件架构的m v c 模式进行开发，具有良好的较强的扩展性 1 4 论文组织结构 本文首先在第一章介绍了研究背景，国内外研究现状，以及本文所作的主要 研究工作：接着本文在第二章提出了需求层级表示的观点，在第三章给出了p r o p 需求开发方法，提出采用用例表示需求；然后利用需求的层级表示的观点给出了 r r u p 开发过程中r g 口o 用例的导出方法以及解决归责问题的扩展方法，本章最 后给出了用例模型和基于用例的s r s 模版中的功能需求的表示方法在第四章本 文给出了和r r i 限开发并发进行的r r u p 管理过程，对需求的变更给出了一个比 较简洁实用的流程，对需求的状态重新进行了定义，然后说明了r r u p 管理的适 用性在第五章本文在m r o p s s 系统中对所提方法进行了验证第六章介绍了基 于r r u p 思想的需求管理工具的设计和实现。最后，在第七章对本文的工作进行 总结，对进一步要开展的工作进行展望 第2 章需求用例化层级表示 第2 章需求用例化层级表示 2 1 需求工程简介 2 1 1 需求工程研究内容 需求工程的目的是通过与用户交流为待开发系统提供一个清晰、一致、精确 且无二义性的模型，通常以s i 峪的形式来定义待开发系统的所有外部特征。需求 活动以“工程化”的方法被提出、分析和组织，是一个反复定义、记录、演进的 过程，在最终达到需求的冻结。 田2 1 ：量隶工程活动 关于需求工程的活动阶段和内容有很多种定义8 0 年代，h e r bk a s n c r 定义 了需求工程的五阶段生命周期阴：需求定义和分析、需求决策、形成需求规格、 需求实现与验证、需求演进管理。近来，m a t t h i a sj a r k e 和a 璐p o h l 提出了三阶 段周期的说法f i 川：获取、表示和验证从侧重点不同来看，需求工程可分为需求 开发和需求管理，前者侧重需求的生成，后者侧重于需求变更的控制。综合上述 观点，比较公认的方法是把需求工程的活动划分为两个阶段：需求开发和需求管 理。每个阶段都包括具体的活动内容，如图2 1 所示 在以后的章节会将每个需求活动一一详述，这里不再加以说明 6 第2 章需求用例化层级表示 2 1 2 需求工程研究途径 需求工程的研究有三条途径； 1 形式化途径 包括完全形式化方法的研究及基于知识表示的各种综合技术的研究。 2 非形式化途径 这方面的工作主要是解决需求工程的指导原则、方法框架和操作启示。其中 比较有代表性的是：结构化分析方法和面向对象分析方法。 3 半形式化途径 方法介于上述两者之间，在宏观上对语言和语义有较精确的描述，而在某些 局部方面则允使用非形式化的自然语言 本文采用的是基于u m l 面向对象的非形式化途径，采用自然语言和图形化 的表示方式。 2 1 3 需求工程研究难点 需求工程的研究到今天己相对成熟了，能作为一个独立的领域出现，有大量 优秀的方法和工具对它提供支持但需求工程的发展不仅受技术因素的影响，还 受一些重要的社会因素的影响，因而不可避免的存在着一些问题。归结起来，主 要体现在以下四个方面【1 1 1 ：问题的复杂性：交流障碍；不完备性和不一致性；需 求易变性。 下面将介绍通过需求层级表示用例化来进行需求分析，结合后面的需求开发 管理方法来解决信息系统中现存的需求困难。 2 2 需求的层级表示 2 2 1 需求的分层表示 在软件系统开发过程中，不同角色的人员对需求有着不同的理解。客户所理 解的需求是使用软件系统所要达到的经济效益和工作效率方面的目标，这是一个 高层次的、抽象的概念系统分析员所考虑的则是由客户的高层次的需求导出的 7 第2 章需求用例化层级表示 软件系统在范围、功能以及系统架构方面的需求而对于具体的开发人员来说， 软件需求则变成了由系统分析员指定的软件模块的详细设计要求，如输入，输出 的数据格式、处理过程以及模块的接口要求等【1 2 3 。 为了保证各类人员在软件需求上达成共识，避免期望差异，必须对软件需求 按不同的角色进行划分。软件需求一书中有对需求层次的详细定义【1 3 l ： 业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在 项目视图与范围文档中予以说明。 用户需求：描述系统的直接使用者使用产品所必须要完成的任务，这在使用 用例文档或方案场景( s c e n a r i o ) 说明中予以说明。 功能需求：定义开发人员必须实现的软件功能，使得用户能完成他们的任务， 从而满足用户需求和业务需求；它是用户对系统要做什么的要求；是功能和特性， 是通常要在描述系统时考虑的需求特性是指逻辑上相关的功能需求的集合，给 用户提供处理能力并满足业务需求。 非功能需求：非功能需求描述了系统展现给用户的行为和执行的操作等，包 括要遵从的业务规则、人机接口、安全性和可靠性等要求；它描述对用户很重要 的系统隐藏部分，尽管他们可能没有意识到这些部分的重要性 业务需求决定了用户需求，而每个用户需求又对系统提出了一个或多个功能 需求和非功能需求，本文将功能需求和非功能需求统称为系统需求。有时，不同 的用户需求会对系统提出相同的功能需求，这就需要对这些用户需求进行抽象， 形成最终的功能需求。需求分层有助于跟踪需求的来源，控制系统范围，有效避 免期望差异 2 2 2 功能需求的分级表示 基于信息系统本身固有的特点( 参看3 1 1 节) ，在进行功能需求的分析时， 需要对系统实现的功能进行分级，这样便于我们在把握需求时兼顾大局和小节， 在业务上根据用户的不同目标完成不同级别的需求，合理安排开发进度，灵活地 对我们的需求进行跟踪。我们把功能需求分为三个等级：组织级、系统级、子系 统级。 组织级( o r g a n i z a t i o nl e v e l ) ：是要实现的功能的最高层次功能概括，规定 8 第2 章需求用例化层级表示 了功能需求的总体目标，包含多个功能目标我们需要经过多个来回能达到的功 能需求。 系统级( s y s t e ml e v e l ) ：系统级指定功能需求的环境以及与它的角色、活 动之间的关系，是经一个来回就能达到的功能需求。 子系统级( s u b s y s t e ml e v e l ) ：子系统级定义了子系统组件、子系统的职责、 接口、关系和交互，描述系统级需求的一部分 三个级别是从高到低逐级细化的关系，和c o c k b u m 先生在其所著的 w r i t i n g e f f e c t i v eu s ec a s e s ) 一书中将用例分为三个级别是一致的。我们以病人就诊系统 为例来说明三个级别的关系，如图2 2 所示 田2 2 s 组织需采的分级表示实倒说明 病人就诊系统就是我们的组织级的功能需求，它可以细化成多个系统级的功 能需求，如挂号系统，收费系统等，挂号系统可单独作为一个系统来实现，序列 号产生系统、挂号收费系统和发放病例卡系统都是它的子系统级功能需求。假如 现在新的业务出现，某个组织级的需求即就诊系统要废弃，我们就不用考虑其他 级别的需求进度和状态了。而系统级的需求如医药系统变更的话，我们也只需要 对该系统级的需求进行变更，而不需要进行整个组织需求的重新考虑，分级的好 处显而易见 当然，需求分析是一个复杂的过程，在工业界它的分析是为了创造更多的价 值，在实际的分析过程中，我们除了依靠分级对需求分析过程进行改进外，还得 考虑其他各方面的要求。如开发风险，客户各种业务发展的相对稳定性，开发人 员的素质等等因素 9 第2 章需求用例化层级表示 2 3 用例简介 2 3 1 用例定义 用例概念1 扫j a c o b s o n 1 4 1 在1 9 9 2 年首次提出。发展到现在主要形成了两个学 派： u s ec a s e 之父j a c o b s o n 为代表的r a t i o n a l 学派认为用例的概念是“与系统进行 对话时行为相关的事务系列的描述”r u p 中关于用铡的定义是“一系列带交量 的动作描述，系统由此对特定用户产生有价值的可见结果”一个用例要求有一 个量化的结果，从单个线索的需要提交。作为量化结果的组成，目标要么成功要 么失败，没有其它的情况。用例具有前置条件和后置条件【旧 另一个学派是以a l i s t a i rc o c k b u m 为代表，该学派认为用例的概念是“代表 系统中各个项目相关人员之间就系统的行为所达成的契约”提出请求的项目相 关人员被称为主执行者( p r i m a r ya c t o r ) 。系统对任一执行者所做出的响应，要保证 所有项目相关人员的利益不受侵犯根据执行者做出的请求和请求涉及的条件， 系统将执行不同的行为序列，每一行为序列称之为一个场景。一个用例是多个不 同场景的集合。这种模型被认为是应用最成功的模型【垌本文倾向使用后者，同 时在使用过程中加入了前者的不少鲜明特点 用例可以作为项目计划、进度控制、测试等环节的基础，是一些外部参与者 和计算机系统之问交互的文本描述用倒图是参与者和用例之间关系、用例之间 关系的图形表示不少人是在学习u m l 的时候接触到u s ec a 辩，所以很多人 都误解其为一种图表，把用例图当作用例分析的全部，这是不正确的，用例描述 才是用例驱动分析技术的核心关于用例图和用例描述的区别，我们将在第五章 n t o p s s 故障流程的分析过程中予以说明。本文的用例指的是用例描述。 2 3 2 用例之间的关系 用例使开发团队与客户之间的交流更加顺畅，使得开发人员和客户可以共同 讨论业务流程【m 。从原贝q 上讲，用例之闻是并列的，但从用例粒度的控制以及可 维护性来说，我们可以把用例抽象出以下三种关系【1 明： i o 第2 章需求用例化层级表示 1 泛化关系：用例之间的一般和特殊关系，其中特殊用例继承一般用例的 特性并可增加新的特性或覆盖父用例的特性( 行为和含义) 2 扩展关系：在基用例上插入基用例不能说明的扩展部分。它的基本含义 和泛化关系类似，但在扩展用例中更多的规则限制，即基用例到扩展用例是有条 件的，也就是说，扩展用例发生有其触发事件。 3 包含关系：一个用例使用另一个用例，或者说一个用例( 称为基本用 例) 的行为包含了另一个用例的行为( 称作包含用例) 2 3 3 用例驱动分析技术简介 i v a rj a c o b s o n 于1 9 6 7 年开始研究用例驱动分析技术，并于1 9 8 6 年总结、发布 了一项源于实践的需求分析技术i v a r 先生在加盟r a t i o n a l 之后，与g r a d yb o o t h 、 j i mr a m b a u g h 共同创建了一种可视化地说明、建造软件系统的工业标准语言一 u m l t l 9 l ，完善了r u p ，用例驱动分析技术也因此被人广泛了孵和关注。 用例驱动分析技术为软件需求规格化提供了一个基本的元素，而且该元素是 可验证，可度量的用例应该以“用户语言”编写，避免掺杂“对象语言”和实 现细节，所产生的用例和用例图文档应该使用户能够很容易理解。每个用例内部 是一个有效驱动系统开发过程的精巧的需求包 本文研究的是与需求相关的用例驱动技术，即用例驱动的需求工程，整个需 求开发和需求管理的基础和出发点是用例，开发和管理过程围绕用例展开 2 3 4u m l 对用例驱动技术的支持 面向对象思想曾经遭受一些人的批评o o m 设计思想是一种关于计算和信 息结构化的新思维，它的出现缩小了分析设计和编码的鸿沟，却拉大了和用户的 距离，因为用户关心和理解的只是系统的功能，他不可能去学习面向对象模型。 但用例的出现使这一情况得到了极大的改观。在u m l 中，o o m 的第一步是用例 的分析，用例体现了系统的功能单元系统的外部人员或其它系统通过和用例交 换消息来了解和使用系统的功能，弥补了0 0 m 和用户之间的距离。 u m l 以对象图描述任意类型的系统，具有很宽的应用领域，可以对任何具 有静态结构和动态行为的领域建模u m l 适用于从需求规格说明到系统测试的 第2 章需求用例化层级表示 不同阶段。在需求分析阶段，使用用例捕捉用户需求并建模，描述与系统有关的 外部角色及其对系统的功能要求。分析阶段主要关心问题域中的主要概念和机 制，并用u m l 类图来描述对象和类，用u m l 动态模型描述类之间的协作关系。 u m l 模型同时还是测试阶段的依据不同的测试小组使用不同的u m l 图作为测 试依据：单元测试使用类图和类规格说明：集成测试使用构件图和协作图；系统 测试使用用例图 2 0 l 。 2 4 用例层级表示 2 4 1 用例的分层 相对于对需求的层次划分，我们需要对各层需求进行用例表示，由于用例只 能是实现某种要求的功能性需求的表示，因此业务需求和非功能需求不需要用例 化。业务需求为我们分析用户需求提供范围，业务前景，非功能需求就转化为对 系统的总体要求和对用例的限制；因此只需得到用户需求、功能需求相对应的用 例表示即可 本文把需求的用例表示分为用户用例、功能用例两层。那么对于一个系统来 说，开发过程中写多少用例才是恰当的? 这就是用例的粒度问题。 2 4 2 用例的粒度 用例在表达上具有简洁性，同时可以在需求可跟踪性问题的解决过程中驱动 整个方法论但任何使用用例的人都避免不了为一件事情烦恼：用例的粒度，任 何使用者都不可能回避这个问题。因为用例的定义本身就是从参与者的角度出发 的，用例考察的场景是由参与者发起的一系列完整活动，对于普通的应用系统而 言，我们都会遇到几十个或几百个用例在使用用例分析技术时，很多人都觉得 如何确定用例的粒度是一个难点，而且感觉到用例没有什么规则遵从，甚至有无 所适从的感觉。c o c k b u m 先生提出学习用例分析技术应分为三个阶段： 1 练习基本功，遵循规则，照章办事： 2 突破传统方法，因地制宜地灵活应用； 3 超脱任何限制和规则，随心所欲地使用。 第2 章需求用例化层级表示 但是用例驱动分析技术让第一阶段的初学者感到无法很快地掌握。 c o c k b u m 先生在其所著的( w r i t i n ge f f e c t i v eu s ec a s e s 一书中对i v a r j a c o b s o n 的用例驱动分析技术做了一些补充口1 】： l 。用例是契约，是系统与涉众之间达成的契约。也就是将用例朝着形式化 的方向发展。 2 将系统用例分为三个目标层次； 概要级：包括多个用户目标( 显示用户目标运行的语境：显示相关目标的生 命周期；为低层用例提供一个目录表等) 用户目标级：它是主执行者努力使工作得以完成的目标，或是用户使用系统 的目标。它相当于业务过程工程中的“基本业务过程” 子功能级：指那些在实现用户目标用例时可能会被用到的用例。 c o c k b u m 的思路与理念对于初学用例分析技术的人来说非常有价值，使得用 例驱动分析技术更具操作性，但这同时也或多或少地局限了使用者的思维。因此， 第三阶段就是超脱任何限制和规则，按需灵活使用 现结合2 2 2 节病人看病的实例来辅助说明用例需求的划分： 1 概要级用例：病人看病 2 用户目标级用例：一般包含挂号、到诊断室就诊，交费，取药等 3 ，子功能级用例：以挂号为例，我们需要抽取序列号，等待，缴纳挂号费， 取病例卡。 关于三个级别的用例有以下三个重要的注意事项【2 1 】： 1 把较多的精力投入到对用户目标级用例的考查上，它们是重要的用例 2 编写一些最外层用例来为其他用例提供语境 3 不要在“是否把系统需求规格说明语句中你最喜欢的那个措辞用作用例 的标题”上面小题大做 如何找出正确级别的用例，可对用户用例问两个问题1 2 1 1 ：主执行者想要怎么 做? 为什么做这件事? 思考“执行者为什么做这件事”可提升用例层次，以前 文所用的就诊为例说明：在写病人挂号的用例时，回答这个问题，答案就是“病 人为了来看病”，显然，病人看病是一个高层次用例。思考想要怎么做的问题 则会降低目标层次 第2 章需求用例化层级表示 将用例分级，发现高层次需求有利于把握全局，而要细化需求时，又不得不 去寻找低层次的用例，用户目标级用例是两者的中间点，起到呈上启下的作用。 往往用户目标级用例的描述步骤就是未来软件系统界面和流程的雏形 2 5 需求用例化层级表示 或许你已经发现功能需求分级与用例分级的一致性，在用例驱动的需求分析 中，各个级别的用例就是需求的规范表示。下面我们将用一个需求用例化层级表 示模型来说明其中的关联，如图2 3 所示 圈2 a露求用倒化层缀农示 那么如何将需求用例化，什么样的用例才是最适合我们的用例? c o e k b u m 在( w r i t i n ge f f e c t i v eu s ec a s e s 一书中告诉我们。我们需要的是一个有用的用 例，而不必是一个完美的用例。基于这种观点，本文探讨了适合于信息流系统的 需求用例化方法：r g i p o 用例导出方法 1 4 第3 章用例驱动需求开发方法 第3 章用例驱动需求开发方法 3 1r r u p 需求开发方法 3 1 1 信息系统简介 信息系统的概念是一个历史范畴，它的内涵随着时间的推移而不断变化。 m i s 的出现是在1 9 7 0 年， w a l t e r t k e n n e v a n 定义m i s 为：以书面或口头的形式， 在合适的时间，向经理、职员以及外晃人员提供过去的、现在的并预测未来的有 关企业内部及环境的信息，以帮助它们进行决策。随着信息技术的发展和广泛应 用，m i s 已经不能独自涵盖计算机在组织管理中的所有应用领域，出现了含义更 为广泛的信息系统的概念1 2 2 1 。信息系统的发展已经历t e d p s 、m i s 和d s s = 个 阶段。d s s 可以认为是m i s 发展的新阶段，e d p s 、m i s 、d s s 各自代表了信息系 统发展过程中的某一阶段，至今它们仍各自不断地发展着，而且具有相互交叉的 关系瞄】。 信息系统可以看作是管理信息系统概念的发展，或者说信息技术的发展促使 信息系统概念的形成并普遍被接受和认同如s t a i r 把信息系统定义为：一系列相 互关联的，可以收集( 输入) 、操作和存储( 处理) 、传播( 输出) 数据和信息，并提供 反馈机制以实现其目标的元素或组成部分的集合信息系统项目具有多学科性， 风险大，时间性强，强调团队协作等特点。在企业组织中最常见的信息系统有事 务处理系统、管理信息系统、决策支持系统、综合服务系统等 信息系统的特点决定了它的开发不仅需要用工程的思想来指导，更需要一种 受控的工作方式，需要一个过程来集成软件开发的方方面面跚：需要一种通用的 方法或过程来指导团队活动的顺序；明确每个成员的任务；确定开发何种制品等 工作。本文结合r u p 的最佳实践经验和特点提出运用r r u p 需求过程来指导需求 开发和管理 3 1 2 r u p 简介 r u p 是r a t i o n a l 软件公司的软件工程过程框架，其目标是确保软件产品达到 第3 章，用例驱动需求开发方法 高质量，能够满足最终用户需求跚，软件开发过程是一个将用户需求转化为软件 系统所需要的活动的集合。r u p 汲取了面向对象的软件工程领域多年来的优秀研 究成果，利用了新的可视化建模标准u m l ，是软件工程发展的新成果。 r u p 是一种具有明确定义和结构的软件工程过程，它采用用例驱动的、以架 构为中心、迭代增量的软件开发方法，它明确规定了人员的职责、如何完成各项 工作以及何时完成各项工作，并提供了软件开发生命周期的结构【2 6 】。 r u p 是一种二维的软件工程过程，其中一维( 横轴) 是时间，另维( 纵 轴) 是过程成分，可参照r u p - - 维模型。二维坐标的横坐标体现了过程的动态结 构，以术语周期( c y c l e ) 、阶段( p h a s e ) 、迭代( i t e r a t i o n ) 和里程碑( m i l e s t o n e ) 来表达； 纵坐标表现了过程的静态结构，以术语活动( a c t i v i t y ) 、制品( a r t i f a e 0 ，角色( r o l e ) 和工作流( w o r l m o w ) 来描述1 2 7 l 。 r u p 提供了如何在开发组织中严格分配任务和职责的方法，被称为软件开 发队伍的最佳实践，而且被许多机构普遍运用。为使整个团队有效利用最佳实践， r u p 为每个团队成员提供了必要的准则模板和工具指导，主要包括以下六个部分 脚】：迭代的开发产品；需求管理；基于构件的体系结构；可视化软件建模：验证 软件质量；控制软件的变更。 3 1 3r u p 裁剪研究 r u p 是个过程的框架，它包容许多不同类型的过程，我们可以采用不同的方 式来使用它，如瀑布式和敏捷式；可以把它用得繁文缛节，也可把它用得轻捷灵 便，这取决于如何在环境中对它裁剪运用。r u p 并非只对大型项目的开发有指导 意义，通过裁剪，它几乎可适用于所有的软件项目。k f i c k a e lh i 巧c h 在 m a k i n gr u p a g i l e 一文中在许多小项目上成功应用了r u p ，指出r i j p 完全可以适应小项目的 需要，在小项目中r t a 的关键是仔细选择合适的制品子集并保持这些制品非常简 明、剔除不需要的形式主义制品 2 9 1 。针对具体的项目，对r u p 的裁剪，可以遵循 由浅入深的5 步法，在保留r u p 核心概念的基础上，降低r u p 应用的复杂性： 1 确定项目的软件过程需要哪些工作流 2 ，确定每个工作流产出哪些制品 3 确定阶段间演进 1 6 第3 章用例驱动需求开发方法 4 确定阶段内的迭代计划 5 规划工作流内部的结构 总之，r