（计算机软件与理论专业论文）利用uml对货物受理信息系统进行需求收集的研究.pdf

山东大学硕士学位论文 摘要 本文的主要工作是对货运管理信息系统的业务进行收集和分析，一方面 利用u m l 的表达方法对所收集的信息进行可视化处理，满足了系统进一步开 发的需要，在此基础上，论述了该方法在实现需求收集过程规范化方面的优 势，期望借此找到货运管理信息系统开发所能共同遵守的需求收集工作框架， 软件开发工作者可以通过很少的变动来适应此类软件需求收集工作。 公路快速货运信息系统需求收集的内容包含大量复杂多变的业务规则， 尤其是在计算机的使用改变了传统的作业模式的情况下，很多业务可能需要 重新设计，采用传统的面向过程的开发方式，难于进行业务分解，一方面可 能会因为功能难以明确分离，导致过分关注细节而陷入需求收集的泥沼之中； 另一方面可能会导致开发人员在需求阶段进行一个过于粗略的需求收集过 程，而草率进入设计阶段。因此，本文利用u m l 建模方法对货物受理信息系 统进行需求收集的工作，采用图形表达方式，为开发者和客户之间、开发者 和开发者之间提供高效的沟通工具，以增强各方人员对系统的理解，为后续 的再创造工作提供条件。 本文研究的重点在于如何根据客户已有业务流程和流程的再造，对货运 管理信息系统进行基于u m l 的需求收集，论述该收集方法在坚持需求收集过 程中的四个准则方面的优势所在。为了更好地体现利用u m l 的优势，文中还 利用c a s e 工具生成的代码，对需求中的部分用例进行了修订，以维护需求的 正确性，保持代码、设计及需求文档的一致。 本文所采用的系统收集的方法是在明确系统边界的条件下，按照u m l 中 关于参与者的定义寻找系统的参与者， 例，以主用例为核心开发其支撑用例， 根据决定系统特性的业务来确定主用 然后利用用例图和活动图对系统的功 能进行可视化处理，并对系统进行细节描述。在寻找用例的过程中，运用分 步骤的方法，包括用例的初始化、用例的扩展、用例的细化。 工程的实践表明，通过使用u m l 对系统进行需求收集和表达，很好地适 山东大学硕士学位论文 应了软件开发的需要，能够满足业务模式的转变，在收集过程中也能够很好 地坚持需求收集的准则，不断发现问题，解决问题，形成一个良性的工程迭 代。 关键字：统一建模语言；需求收集；货运；用例 山东大学硕士学位论文 a b s t r ac t t h em a i nw o r ko ft h e s i si st oc o l l e c ta n da n a l y z et h eb u s i n e s sr u l e s o f f r e i g h tm a n a g e m e n ti n f o r m a t i o ns y s t e m o nt h eo n eh a n dt h e i n f o r m a t i o nc o l l e c t e di sv i s u a l i z e du s i n gt h er e p r e s e n t a t i o no fu m l c o r r e s p o n d i n gt or e q u i r e m e n tc a p t u r i n g 。w h i c hi ss a t i s f i e dw i t h t h e n e x ts o f t w a r ed e v e l o p i n g ，o nt h eo t h e rh a n di ti se x p e c t e dt h a ta c o m m o n f r a m e w o r k ，w h i c hi sa b i d e db yt h es o f t w a r ed e v e l o p i n gt e a mo rr e b o u n d e d t oa d a p tt ot h ep r o j e c tw i t hs m a l lc h a n g e s ，c a nb ef o u n dt h o u g ht h e a r g u m e n to fa d v a n t a g et ot h ep r o c e s ss t a n d a r d i z i n go fr e q u i r e m e n t c a p t u r i n g i tm e a n sag r e a td e a lo fc o m p r e h e n s i v e a n dr a p i d l yc h a n g i n g b u s i n e s sr u l e st od e v e l o pt h er o a dr a p i df r e i g h ti n f o r m a t i o ns y s t e m ， e s p e c i a l l yi nt h ec a s eo fc o n v e n t i o n a lb u s i n e s s e sc h a n g e dd u et ou s i n g c o m p u t e r s t h e r ee x i s t ss o m ew e a k n e s si fw eu s et r a d i t i o n a lw a y so f p a r t i t i o n i n gf u n c t i o nm o d e l s f i r s t ，i tc o u l ds l o u g hi nt h ed e t a i lo f r e q u i r e m e n tc o l l e c t i o n ，o rb eh a r dt o p a r t i t i o nt h ef u n c t i o n s s e c o n d l y ，i tc o u l dp r o c e s saf u s sp h r a s eo fr e q u i r e m e n tc o l l e c t i o na n d e n t e rt h ed e s i g np h r a s ed i r e c t l y a c c o r d i n g l y ，t h em e t h o do fu m lm o d e l i su s e dt op r o c e s st h ew o r ko fr e q u i r e m e n tc o l l e c t i o ni nt h et e x t u m l o w n sas u i to fs t a n d a r dr e p r e s e n t a t i o n s ，w h i c hp r o v i d e sar e c o r dt o o l f o rb e t w e e n d e v e l o p e r sa n dc u s t o m e r s ，b e t w e e n d e v e l o p e r s a n d d e v e l o p e r s ，a n do nw h i c hb a s e dt h es y s t e mi su n d e r s t o o db e t t e ra n di s r e c r e a t e d t h ep o i n to fr e s e a r c h i n gi sf o c u so n a c h i e v i n gr e q u i r e m e n t c a p t u r i n gf o rf r e i g h tm a n a g e m e n ti n f o r m a t i o ns y s t e mb a s e do nu m l a c c o r d i n gt ob u s i n e s s e sa n db u s i n e s sr e e n g i n e e r i n ga n da n a l y s i so nt h e a d v a n t a g et oi n s i s t i n go nf o u rr u l e so fr e q u i r e m e n tc a p t u r i n gp r o c e s s i i i 山东大学硕士学位论文 t h ef o u rr u l e sa r ec o n f i r m i n go b j e c t i v eo fr e q u i r e m e n tc a p t u r i n g ， k e e p i n gt h et r a c ea n dc h a n g e a b i l i t yo fr e q u i r e m e n t ，e n s u r i n g t h e n e c e s s i t yo fr e q u i r e m e n tc a p t u r i n g t h ea r g u m e n tc o n s i s t so ft h r e e a s p e c t so nf i n d i n ga c t o r s ，d o m a i na n a l y s i s ，a n dm a k i n g au s ec a s e m o d e li n gf r a m e w o r k t h ea p p r o a c hf o rr e q u i r e m e n tc a p t u r i n gi sf i n d i n gt h ea c t o r s ， w h i c ha r ea c c o r d i n gt ou m ld e f i n i t i o ni nt h ee x p l i c i ts y s t e mb o u n d a r y ， a n dc h o o s i n gt h ek e yu s ec a s e s ，w h i c hd i c t a t e ss y s t e mc h a r a c t e r i s t i c t h es u p p o r tu s ec a s e sa r ed e v e l o p e df o r t h ei m p l i c a t i o n so fk e yu s e c a s e s t h es y s t e mf u n c t i o ni sv i s u a l i z e du s i n gu s ec a s e sa n da c t i v i t y d i a g r a m s i nt h es e a r c ho fu s ec a s e st h ep r o c e s sc o n s i s t so fi n i t i a l u s ec a s em o d e l i n g ，e x p a n do nt h eu s ec a s em o d e l ，a n de l a b o r a t e du s e c a s e t h ep r a c t i c ep r o v e dt h a tu m lc a nf u l l ye x p r e s ss y s t e mr e q u i r e m e n t c a p t u r i n ga n da d a p tt ot h en e e do fs o f t w a r ed e v e l o p i n ga n dt h ec h a n g e s o fb u s i n e s sm o d e l d u r i n gt h ep r o c e s so fc a p t u r i n gp r o b l e m sc a nb e f o u n da n ds o l v e dt oc o n f o r mab e n i g np r o j e c tr e c u rw i t hi n s i s t i n go n t h er u l e so fr e q u i r e m e n tc a p t u r i n g k e y w o r d s ：u m l ：r e q u i r e m e n tc a p t u r i n g ：f r e i g h t ：u s ec a s e i v 原创性声明和关于论文使用授权的说明 原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独 立进行研究所取得的成果。除文中已经注明引用的内容外，本论文不 包含任何其他个人或集体已经发表或撰写过的科研成果。对本文的研 究作出重要贡献的个人和集体，均已在文中以明确方式标明。本声明 的法律责任由本人承担。 论文作者签名日期：d 。，77 、 关于学位论文使用授权的声明 本人完全了解山东大学有黄保留、使用学位论文的规定，同意学校保留或向国家 有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅；本人授权山东大 学可以将本学位论文的全部或部分内荦潮入有关数据库进行检索，可以采用影印、缩印 或其他复制手段保存论文和汇编本学位论文。 ( 保密论文在解密后应遵守此规定) 论文作者签名：基兰叠导师签名：日期： l 山东大学硕士学位论文 第一章引言 1 1 背景介绍 1 1 1 工程背景： 本研究课题是以山东省公路快速货运信息系统的实践为背景。公路快速 货运系统项目是由山东省联运中心和交通部公路科学研究所共同承担的国家 重点工业性试验项目，项目主持单位为交通部。该项目于2 0 0 0 年3 月正式立 项。山东省快速货运有限公司作为该项目的建设载体，具体承担了组织系统、 信息系统、车辆装备系统、场站建设系统四个系统建设的主要任务，该项目 建设的根本目的和任务是根据国家技术创新项目的建设要求和宗旨，通过技 术创新和营运实践，逐步探索建立符合现代经济和科技发展需要的全国统一、 规范的快速货运网络系统和运营体系，进而形成国内一体并与国际相衔接的 市场化、集约化、品牌化发展的战略目标。 ， 山东省公路快速货运信息系统包括8 个子系统：货物受理信息子系统； 票据单证制作、处理、传输子系统；仓库货物管理子系统；分拣子系统；i c 卡人员身份认证子系统；运输调度子系统；财务结算子系统；企业内部管理 子系统。面对激烈的市场竞争以及信息时代对全公司各项工作提出的新的挑 战与机遇，公司决定实施信息化工程，目标是用信息技术和现代管理技术相 结合的方式改造企业，提高企业的管理水平，提高企业的经济效益和增强企 业的市场竞争能力。 1 1 2u m l 发展和应用现状 随着计算机硬件性能的迅速提高和价格的持续下降，其应用范围也在不 断扩大。交给计算机解决的问题也越来越难，越来越复杂。这就使得计算机 软件变得越来越复杂和庞大。2 0 世纪6 0 年代的软件危机使人们清醒地认识 到按照工程化的方法组织软件开发的必要性。于是软件开发方法从6 0 年代毫 无工程性可言的手工作坊式开发，过渡到7 0 年代结构化的分析设计方法、8 0 年代初的实体关系开发方法，直到面向对象的开发方法。 山东大学硕士学位论文 面向对象的软件开发方法是在结构化开发范型和实体关系开发范型的基 础上发展而来的，它运用分类、封装、继承、消息等人类自然的思维机制， 允许软件开发者处理更为复杂的问题域和其支持技术，在很大程度上缓解了 软件危机。面向对象技术发端于程序设计语言，以后又向软件开发的早期阶 段延伸，形成了面向对象的分析和设计。 2 0 世纪8 0 年代末9 0 年代初，先后出现了几十种面向对象的分析设计方 法。其中，b o o t h ，c o a d y o u r d o n 、o m t 和j a c o b s o n 等方法得到了面向对象 软件开发界的广泛认可。各种方法对许多面向对象的概念的理解不尽相同， 即便概念相同，各自技术上的表示法也不同。通过9 0 年代不同方法流派之间 的争论，人们逐渐认识到不同的方法既有其容易解决的问题，又有其不容易 解决的问题，彼此之间需要进行融合和借鉴；并且各种方法的表示也有很大 的差异，不利于进一步的交流与协作。在这种情况下，统一建模语言( u m l ) 于9 0 年代中期应运而生。 u m l 的产生离不开三位面向对象的方法论专家g b o o c h 、j r u m b a u g h 和i j a c o b s o n 的通力合作。他们从多种方法中吸收了大量有用的建模概念， 使u m l 的概念和表示法在规模上超过了以往任何一种方法，并且提供了允许 用户对语言做进一步扩展的机制。u m l 使不同厂商开发的系统模型能够基于 共同的概念，使用相同的表示法，呈现彼此一致的模型风格。1 9 9 7 年1 1 月 u m l 被o m g 组织正式采纳为标准的建模语言，并在随后的几年中迅速地发展 为事实上的建模语言国际标准。 u m l 在语法和语义的定义方面也做了大量的工作。以往各种关于面向对 象方法的著作通常是以比较简单的方式定义其建模概念，而以主要篇幅给出 过程指导，论述如何运用这些概念来进行开发u m l 则以一种建模语言的姿 态出现，使用语言学中的一些技术来定义。尽管真正从语言学的角度看它还 有许多缺陷，但它在这方面所做的努力却是以往的各种建模方法无法比拟的。 从u m l 的早期版本开始，便受到了计算机产业界的重视，o m g 的采纳和 大公司的支持把它推上了实际上的工业标准的地位，使它拥有越来越多的用 户。它被广泛地用于应用领域和多种类型的系统建模，如管理信息系统、通 信与控制系统、嵌入式实时系统、分布式系统、系统软件等。近几年还被运 用于软件再工程、质量管理、过程管理、配置管理等方面。而且它的应用不 2 山东大学硕士学位论文 仅仅限于计算机软件，还可用于非软件系统，例如硬件设计、业务处理流程、 企业或事业单位的结构与行为建模，等等。 在u m l 陆续发布的几个版本中，逐步修正了前一个版本中的缺陷和错误 即将发布的u m l 2 0 版本将是对u m l 的又一次重大的改进。将来的u m l 将向着 语言家族化、可执行化、精确化等理念迈进，为软件产业的工程化提供更有 力的支撑。 1 2 本文的工作 作为山东省公路快速货运信息系统的核心子系统一一货物受理信息子系 统是为了满足企业开展物流经营活动的迫切需要，依据运输企业的业务流程， 为其所提供的一套先进适用的物流管理信息系统软件和应用平台。其用途是 为创建物流运输管理系统平台服务，切实提高货物运输的组织化水平和效率， 加速企业的信息化进程。 本文的工作在于利用u m l 对货物受理信息子系统进行需求收集，目标是 围绕软件工程中软件需求收集准则，更加有效地获得用户需求，从客户的角 度来描述系统，以期软件能够快速、高质量的被开发。工作大致可以分为五 个方面： 1 2 1 问题域的识别 重点在于研究系统的说明书和软件工程计划书。问题域的识别目标是识 别使用者或用户对基本问题元素的假想；问题域的识别的结果是确定系统的 边界和系统的参与者。 1 2 2 对问题的分解和分析 通过对货物受理信息子系统的分解，定义所有的数据对象、定义和细化 所有的软件功能、理解软件的每一个动作对系统的影响、建立系统界面的特 性、发现附加的设计限制；分解和分析的结果是确定系统的主用例和相应的 支撑用例，这一部分是本文的核心部分，就u m l 而言，它本身没有提供如何 去寻找用例，只是规定了对用例如何表达，因为对于无限变化的需求，很难 给出一个或几个标准的或通用的用例寻求方法，所以本文意图利用u m l 的统 山东大学硕士学位论文 一、易懂、全面等优点对货物受理信息子系统进行需求的收集和分析研究， 研究既具有特殊性，也具有一般性，特殊性在于为货物受理子系统提供了一 个具体的需求收集和分析方法，一般性在于物流领域的软件需求收集和分析 都可以采用相似的方法。 1 2 3 利用u m l 进行建模 这一部分充分利用u m l 可视化的优点，使用u m l 中已经定义好的各种图 框来表达系统各个用例和参与者的相互关系，系统用例的执行过程。利用u m l 进行建模的目标是更好的理解数据流和控制流，功能的执行过程和行为的操 作方式，以及信息的内容。利用u m l 进行建模的结果是产生用例图和活动图， 它们会被用来作为建立软件需求规格说明书的基础。 1 ，2 4 建立需求规格说明书 在“u m ld i s t i l l e d ”中提到“w h a tt h eu m ld e s c r i b e si sau s ec a s e d i a g r a m ，w h i c hs h o w sh o wu s ec a s e sr e l a t et oe a c ho t h e r b u ta l m o s t a l lt h ev a l u eo fu s ec a s e sl i e si nt h ec o n t e n t ，a n dt h ed i a g r a mi so f r a t h e rl i m i t e dv a l u e ” 1 】这部分将要把模型所表达的内容准确系统的表 达出来，由于在这个阶段尚处于原型时期，因此这部分的说明不会涉及到软 件开发的细节，尤其是用户还没有最终确定的部分。建立需求规格说明书的 结果是产生一个采用一定的标准模板对模型的准确说明。 1 2 5 用例评述 用例的建立要遵守价值独立、功能集中的准则 2 ，在分解过程中可能会 因为从局部角度考虑建立的部分用例，在后来分析的结果中出现与准则不相 符格的用例，在用例评述部分中，要对每一个用例按照准则进行分解用例、 合并用例或者删除用例。用例评述的结果产生符合准则的系统用例。 1 3 本文的组织 本文围绕工作的五个方面来进行组织。第一部分要对本文u m l 中所涉及 的一些术语做一个限定性的解释。由于不同的人在不同的环境对于这些属于 4 山东大学硕士学位论文 会有不同的理解和解释，所以这一部分很有必要。第二部分会介绍对需求收 集和分析过程中用例建立的准则，需求收集过程的常见问题以及解决方案 第三部分针对货物受理信息系统的业务定义，业务逻辑进行详细描述，从系 统工程角度出发，概括整个受理业务流程。第四部分研究分析业务流程，从 中发现用例，评述用例，建立模型，按照模型完成系统的设计规格说明书。 第五部分对规格说明书的实现过程进行总结，并简要阐述需求收集和分析的 下一步工作，除此之外，还提出c a s e 工具在软件做需求收集和分析工作中的 应用。 山东大学硕士学位论文 第二章u m l 概述 在2 0 世纪9 0 年代中期和后期，为了结束相互竞争的符号带来的混乱， 出现了统一建模语言。虽然统一建模语言发明的本意并不是为面向对象的软 件系统进行建模提供符号语言，但是它是由面向对象软件开发领域的许多最 好的、最聪明的学者和从业者联合起来创造的，或者说是在面向对象方法的 需求中产生的，现在它已经成为面向对象系统建模的国际标准。统一建模语 言目前是由o m g ( o b j e c tm a n a g e m e n tg r o u p ，对象管理组织) 控制的一个开放 的标准，而不属于任何公司或个人。统一建模语言为软件系统建模提供了精 确的符号，更重要的一点是，统一建模语言不仅可以记录已有想法，它还帮 助软件开发人员创造并交流想法。 2 1 u m l 简介 统一建模语言( u m l ) 是一个通用的可视化建模语言，用于对软件进行描 述、可视化处理、构造和建立软件系统制品的文档。它记录了对必须构造的 系统的决定和理解，可用于对系统的理解、设计、浏览、配置、维护和信息 控制 3 。u m l 适用于各种软件开发方法、软件生命周期的各个阶段、各种应 用领域以及各种开发工具，u m l 是一种总结了以往建模技术的经验并吸收当 今优秀成果的标准建模方法。u m l 包括概念的语义，表示法和说明，提供了 静态、动态、系统环境及组织结构的模型。它可被交互的可视化建模工具所 支持，这些工具提供了代码生成嚣和报表生成器。u m l 标准并没有定义一种 标准的开发过程，但它适用于迭代式的开发过程。它是为支持大部分现存的 面向对象开发过程而设计的。 u m l 描述了一个系统的静态结构和动态行为。u m l 将系统描述为一些离散 的相互作用的对象并最终为外部用户提供一定的功能的模型结构。静态结构 定义了系统中的重要对象的属性和操作以及这些对象之间的相互关系。动态 行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。从不 6 山东大学硕士学位论文 同但相互联系的角度对系统建立的模型可用于不同的目的。 u m l 还包括可将模型分解成包的结构组件，以便于软件小组将大的系统 分解成易于处理的块结构，并理解和控制各个包之间的依赖关系，在复杂的 开发环境中管理模型单元。它还包括用于显示系统实现和组织运行的组件。 u m l 不是一门程序设计语言。但可以使用代码生成器工具将u m l 模型转 换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为 u m l 。u m l 不是一种可用于定理证明的高度形式化的语言，这样的语言有很多 种，但它们通用性较差，不易理解和使用。u m l 是一种通用建模语言。对于 一些专门领域，例如用户图形界面( g u i ) 设计、超大规模集成电路( v l s i ) 设计、基于规则的人工智能领域，使用专门的语言和工具可能会更适合些。 u m l 是一种离散的建模语言，不适合对诸如工程和物理学领域中的连续系统 建模。它是一个综合的通用建模语言，适合对诸如由计算机软件、固件或数 字逻辑构成的离散系统建模。 2 2u m l 中需求收集的相关术语 在u m l 的用例模型中，有一种高层次的图为实现这个目标提供一个很好 的机制。用例图( u s ec a s ed i a g r a m ) 描绘不同系统用户群是如何同这个系统 交互。创建一个用例模型需要三个步骤： 确定使用这个系统的人群。 确定这些人群是如何从这个系统中获取价值。 用一个简单易懂的视图来描述这些用户以及它们如何使用系统。 下面是关于这三个步骤的几个术语及表达方式。 2 2 1 参与者 参与者的基本概念是指与系统交互的实体，它的目的在于完成某一个事 件 4 。 在u m l 中，一种人群称为参与者( a c t o r ) ，使用这个系统或被这个系统使 用的其他系统也是参与者。所以，参与者是指在这个系统的外部并和这个系 统交互的一群人或一个系统。一个参与者必须以独有的方式来使用这个系统 从这一点上看，现实世界中划分的人群与这里所说的参与者是完全不同的。 山东大学硕士学位论文 对于参与者这个概念，也有人争论说应该为角色 1 ( r o l e ) ，主要就是说明 这个问题。本文仍沿用参与者( a c t o r ) 。 2 2 2 用例 用例的基本概念是指对一套序列化的动作的描述，它包括很多变化，它 是由系统完成的并能够给参与者带来可观察的结果 4 。 在u m l 中，系统为参与者提供一个独立的价值所采取的方式称之为用例 ( u s ec a s e ) 。用例必须是集中的( w e l lf o c u s e d ) ，并有一个明确的目标。用 例将需求分成不同的部分，所以集中的用例将使文档更容易导航和理解。用 例也可以用来安排进度和做估算，所以十分集中的用例有利于精确地估算和 准确地跟踪。每一个用例也将被用来作为测试用例的基础，而集中的用例将 对建立一个可用的测试计划十分有帮助，并为跟踪目标进度提供基础。大型 的用例意味着对需求文档的较少的划分，以及较少的里程碑。单纯描述用例 的概念是难于理解的，用例的定义可以转化为 2 ： 用例是集中的： 它可以为系统带来一个独立的好处。 它可以用一个简短的独立的句子来表述。 参与者可以通过一次对话来完成它。 可以作为测试计划的一个部分 用例是具有独立价值的： 参与者利用这个用例得到明确信息或者以一定方式改变系统 在执行它以后，参与者可以在确定时间停止使用系统。 2 2 3 参与者、用例和依赖关系的表达 在u m l 中，参与者用一个棒形人来表示，用例用一个带标记的椭圆来表 示 3 。从参与者指向用例的带箭头的实线表示这个参与者触发这个用例。如 图2 1 所示： 山东大学硕士学位论文 黼( a c t o r ) 用例( u s ec a 8 e ) 图2 1 参与者、用例和依赖关系的表达 2 4u m l 中需求描述的相关术语 描述需求有两种方式：采用文本文档来详细地描述用例以及参与者和用 例之间的交互关系，或者采用u m l 的活动图来描述。与文本文档一样，活动 图也可以描述交互行为，但是它采用的是可视化的形式。这两种文档的目标 是一样的，并且包含相同的信息，它们有很好的互补性。当然，不同的人认 识事物的方式也不一样，所以，将一个可读的文本描述和一个非常精确的可 视化描述结合起来会带来很多的好处。每一个用例都包含三个要素：用例描 述、一个或者多个事件流、活动图。 2 4 1 用例描述 用例描述说明一个用例的概况和特征，例如，前置条件，后置条件、性 能需求、安全要求以及部署约束。前置条件包括参与者启动这个用例之前必 须完成的所有用例。后置条件包括这个用例对系统所作的所有改变。最后， 部署约束描述访问这个用例的所有约束。这些约束让解决方案在尽可能开放 的同时规定了一些要求。 2 4 2 事件流 事件流描述参与者在完成用例的过程中发生的一系列的交互行为。一个 事件流仅描述用例中的一条路径，不包括其他的分支。用例中的其他分支是 由其他的事件流来描述。事件流中的交互是对参与者的输入和系统的响应的 文本描述。 在用例中有三种事件流： 正常的，或基线事件流。通过描述一切都按部就班时的情况来捕捉用例 的目标。 山东大学硕士学位论文 可选事件流。描述由参与者引起的变更。一个用例可能有几个不同的可 选事件流。 异常事件流。描述由系统引起的变更。例如，由于网络的故障、磁盘错 误或者资源限制，系统被迫停止它们的正常响应。多数的用例都或多或少的 有一些异常事件流。 2 4 3 活动图。 活动图是一张集中显示一个用例所有事件流的u m l 图。为了达到这个目 的，活动图显示系统执行的不同活动以及不同的执行结果引起的不同执行路 径。活动图描述一个开始状态、系统执行的活动、执行下一个活动时需做的 判断以及一个或多个结束点。活动图中也有描述并行执行的活动的符号。 2 5u m l 中用例重构 在充实每一个用例之后，需求收集人员必须不断地从整体上浏览和修改 这些用例模型。根据独立和集中的准则，用例可能需要分解、合并或者澄清。 必须找出并纠正过于复杂的用例。 有几种机制可以用来控制这种复杂性。第一种是将这个用例分解，并采 用前置条件来描述工作流。另一种机制是采用u m l 中的包含和扩展关系。还 有一种方法是泛化参与者和用例。 2 5 1 分解用例 首先，我们可以删除一个包含过多步骤的的用例，将它的功能分散到几 个用例中。这些用例通过前置条件和后置条件联系在一起。 2 5 2 使用包含和扩展关系 u m l 提供了两个有力的，但有时又容易混淆的概念来描述用例间的关系。 扩展( e x t e n d ) 关系允许一个用例可选地包含或者基于另一个用例。而另一种 关系，包含( i n c l u d e ) 则指一个用例永远的包含在另一个用例中。 2 5 2 1 包含 在包含关系中，基本用例吸收了被包含的用例的行为，形成对后者的依 l o 山东大学硕士学位论文 赖。包含关系是用一个从基本用例指向被包含用例的带箭头的虚线来表示。 这个关系的构造型是由两个双尖括号包围i n c l u d e 来表示。事件流沿着基本 用例到达被包含用例的包含点。在这一点上，事件流通过被包含的用例，直 到这个用例结束，然后重新回到基本用例的剩余部分。这个包含是必选的， 也就是说，当基本用例到达包含点，被包含的用例就接过流程。而且，这个 被包含的用例可以是抽象的，这样，我们可以用不同形式的用例来实现这个 抽象用例，将它包含到基本用例中而不需要改变基本用例。 2 5 2 2 扩展 在扩展关系中，基本用例并不包含从属用例。相反，扩展用例依靠基本 用例，它的事件流对基本用例的事件流来说是可选的。扩展关系是由一个从 扩展用例指向基本用例的带箭头的虚线来表示，它的构造型是由两个双尖括 号包围e x t e n d 来表示。基本用例中定义一个或者多个事件流的扩展点，每一 个扩展用例都指明它在哪一个扩展点被插入，以及插入这个用例的条件。当 基本用例的事件流到达这个扩展点时，它检查扩展用例发生的条件。如果这 个条件得到满足，那么这个扩展用例的事件流就开始执行，直到结束。然后， 基本用例的事件流从扩展点继续运行。 在扩展关系中，依赖关系是从扩展用例到基本用例，这一点和包含关系 相反，在包含关系中，依赖关系是从基本用例到扩展用例。扩展用例是可选 的，而被包含用例在基本用例到达包含点时，它必须接过事件流。 2 5 3 用例泛化 在某些情况下，一个用例可能有几种不同的分支。用例被转换成抽象用 例，这意味着它只定义用户可以获得的价值，但不说明用户是如何通过交互 来达到这个目的。下一步，就是编写几个具体的用例，用以描述达到抽象用 例定义的目标所需要的交互 5 。 2 5 4 参与者泛化 在很多用例模型中，一个参与者和其他的参与者往往很相似，虽然它可 能还有其他的职责和义务。在u m l 中，如果一个参与者是另一个参与者的特 殊类型，那么就在这个参与者和那个更一般的参与者之间画一个泛化箭头。 山东大学硕士学位论文 这种泛化关系是用来记录现实世界中相似用户群之间的差异 7 。更特殊的参 与者必须触发所有那些更一般的参与者触发的用例。所以，这个特殊的参与 者是一般的参与者的一种类型。 2 6 小结 本章着重阐述关于u m l 的基本概念和基本建模过程，以及它在需求收集 中所涉及到的术语，包括了参与者，用例等基本概念，也包括了关于用例分 解的解释，包含和扩展的关系，还有参与者和用例的泛化等等。 山东大学硕士学位论文 第三章需求收集概述 在进行需求分析时，常常会面临很多选择 8 ，是否要把业务描述得更加 详细，是否要确定的描述某个业务规则，尤其是在时间紧迫，任务复杂的时 候这些问题就会更加突出，处理得不正确或者不及时就会导致需求收集的失 败，要么软件的工期被延误，要么收集了错误的信息，在这个章节针对以上 问题提出了用户需求收集的几个准则，也就是如何处理在需求收集中出现的 几个比较突出的问题。 3 1 需求的定义 需求的定义包括从用户角度( 系统的外部行为) ，以及从开发者角度( 一 些内部特性) 来阐述需求。需求是用户所需要的并能触发一个程序或系统开 发工作的说明 9 ，1 0 。需求的拓展概念：从系统外部能发现系统所具有的满 足于用户的特点、功能及属性等。这些定义强调的是产品是什么样的，而并 非产品是怎样设计、构造的。 从用户需要转移到了系统特性，那么需求是指明必须实现什么的规格说 明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。从 上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的。需求 术语存在 1 2 ，真正的”需求”实际上在人们的脑海中，这个人们主要是指客 户，但一般情况下，用户并不能描述自己的需要，这就需要系统分析人员根 据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析 员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必 达成共识。 3 2 需求的类型 软件需求包括三个不同的层次 2 7 3 ：业务需求、用户需求和功能需求( 也 包括非功能需求) 。 山东大学硕士学位论文 业务需求( b u s i n e s sr e q u i r e m e n t ) 反映了组织机构或客户对系统、产 品高层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求( u s e rr e q u i r e m e n t ) 文档描述了用户使用产品必须要完成的 任务，这在使用实例( u s ec a s e ) 文档或方案脚本说明中予以说明。 功能需求( f u n c t i o n a lr e q u i r e m e n t ) 定义了开发人员必须实现的软件功 能，使得用户能完成他们的任务，从而满足了业务需求。 作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述 了系统展现给用户的行为和执行的操作等它包括产品必须遵从的标准、规 范和合约；外部界面的具体细节：性能要求；设计或实现的约束条件及质量 属性。 3 3 需求收集的任务和过程 3 3 1 问题识别 首先系统分析人员要确定对目标系统的综合要求，即软件的需求。并提 出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性 能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用 需求、软件成本消耗与开发进度需求，并预先估计以后系统可能达到的目标。 此外，还需要注意其它非功能性的需求 3 4 ，如针对采用某种开发模式，确 定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以 及可维护性方面的需求。 3 3 2 分析与综合 问题分析和方案的综合是需求分析的第二方面的工作。分析员必须从信 息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联 系、接口特性和设计上的限制，判断是否存在因片面性或短期行为而导致的 不合理的用户要求，是否有用户尚未提出的真正有价值的潜在要求。剔除其 不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系 统的详细逻辑模型。 1 4 山东大学硕士学位论文 3 3 3 编制需求分析阶段的文档 已经确定下来的需求应当得到清晰准确的描述。通常我们把描述需求的 文档叫做软件需求说明书。同时，为了确切表达用户对软件的输入输出要求， 还需要制定数据要求说明书及编写初步的用户手册。 3 3 4 需求分析评审 作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致 性、完备性、准确性和清晰性，以及其它需求给予评价。为保证软件需求定 义的质量，评审应以专门指定的人员负责，并按规程严格进行。评审结束应 有评审负责人的结论意见及签字 3 6 除分析员之外，用户需求者，开发 部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。 3 。4 需求收集的准则 保持需求在全面性和详细程度上一致性是很重要的。这也就是说，我们 必须确认需求收集过程并不就此终止在需求收集上。在过多和过少之间做一 个恰当的平衡将为整个开发周期打下坚实的基础。如下的一些准则在总体上 为收集需求提出一些通用的建议。 3 4 1 明确目的 进行需求收集的注意力应该集中在问题上，而不是技术细节。在用户需 求收集的过程中，要始终坚持这个准则，把注意力集中在系统“做什么”上， 而忽略“怎么做”的问题。当项目的注意力转移到技术选择和构架上的时候， 需求文档的功能关键在于为各种重要而又难以决定的问题提供有价值的信 息，而不是要从需求文档中直接找到答案。在收集需求的时候，由于信息还 不完整，这时候做出一些决定就会产生仓促的结论，因此这并不是考虑“怎 么做”的好的时机。 3 4 2 保持需求可跟踪性 分步骤进行分析，不断地对用例进行评审和对变化跟踪。在用例建模中， 一个大型的系统中会有大量的用例，每个用例有几个事件流，每个用例都有 山东大学硕士学位论文 活动图，要完成这些图，而且还要维持一致的质量水平和详细程度，此外， 随着时间的推移对系统的共同理解的不断变化，这就需要花大量的时间来评 审那些会议记录，并更新用例模型。 3 4 3 保持需求可变化性 对用户的需求收集做到适可而止，给用户留有变化的余地。需求收集可 能会被过分强调，以至超出它所能提供的价值。需求收集并不就此终止的一 个过程。它是下一阶段开发过程的基础。基础必须牢固扎实，但不意味着要 把它做成一个艺术精品。 如果坚持要得到一个完美的需求，需求过程就会不断的拖着。如果客户 也没有明确的目标，或者对下一步活动不确定，那么这个趋势就更加恶化了 在开发人员采用新技术或新方法开发他的第一个项目时更容易犯这种错误。 有一些项目，在需求收集完成它的使命之后，仍然还陷在需求中。因为同面 对一个不确定的未来相比，新一轮的需求收集更容易打动相关人员。而这时 候，更有可能消除那些不确定因数的工作，比如建立原型或进行技术培训， 都被花在需求收集的细枝末节上了。 3 4 4 确信需求收集的必要性 确信用户需求收集过程的必要性，合理安排软件开发进度。 可靠的需求对项目的成功十分重要。没有它们，注定要解决错误的问题， 做很多重复性的工作，并激怒客户。企图通过忽略需求收集来节约时间只会 适得其反，这将不可避免地导致工期的延长和开销的增加。就像古语所说的 “欲速则不达”。在系统测试的时候才找到需求遗漏或误解将是灾难性的。修 正一个疏忽或者误解将花费数周甚至数月的开发时间。 不良的需求在这些方面导致系统的失败： 客户对开发进程和开发人员的信心随着每一次的误解而逐渐丧失。每一 次的失败都为下一次的努力增加了压力。这样，开发人员和相关人员之间的 交流情况很快就恶化了。一旦这种交流停止，误解随之加深，这个过程一旦 开始就很难逆转。 软件基础将随着对系统的视图的不断改变而不断膨胀。新的需求和对需 求的新认识，都在不断地增加新的系统功能层次日积月累，这个项目就难 1 6 山东大学硕士学位论文 以实现。 当开发人员意识到他们的工作越来越重而收获却越来越少的时候，开发 者如果每一次都要花费大量的时间来解决错误的问题，那对开发过程的信心 和对成功的希望都将逐渐丧失。而另一方面，一个好的用例模型为项目的后 续阶段打下坚实的基础：开发人员充满信心地开始分析、构架和设计在项 目开发时，有着明确的信息来源。当然，在这过程中也会提出一些问题，提 炼需求，但是，需求的核心价值却是完整的，这可以将精力集中在解决问题 上。技术的选择和构架的确定都是在完整的信息基础上进行