（计算机软件与理论专业论文）现代软件工程理论rup及其在翻译辅助系统中的应用.pdf

摘要 摘要 八十年代末以来，而向对象技术逐渐成为研究的热点，一度出现 了几十种支持软件玎发的面向对象方法。其中，b 0 0 c h ，c o a d y o u r d o n ， o m t ，和j a c o b s o n 的方法在面向对象软件开发界得到了广泛的认可。 任何一种思想方法都需要语言来具体描述，于是统一的建模语言 u m l ( u n i f i e dm o d e l i n gl a n g u a g e ) 成为了一种必须，该语言结合 了b o o c h ，o m t ，和j a c o b s o n 方法的优点，统一了符号体系，并从其 它方法和工程实践中吸收了许多经过实际检验的概念和技术，现已成 为软件业事实上的标准。 在u m l 的支持下，r u p 开发方法乘势而出。r u p 是最佳软件开发 经验的总结，它包括多年来在软件开发中总结出的五大经验，即：迭 代式开发；管理需求；使用基于组件的软件体系结构：可视化建模； 验证软件质量。值得注意的是，r u p 是一个通用的过程模板，包含了 很多开发指南、制品及开发过程所涉及到的角色说明，由于它异常庞 大，所以具体的开发机构和项目小组在使用r u p 时还要做裁剪，即对 r u p 进行配置。r u p 就像一个元过程，通过对r u p 进行裁剪可以得到 很多不同的丌发过程，这些软件开发过程可以看作r u p 的具体实例。 本文论述了作者在软件项目的开发中，借鉴r u p 的开发规范，利 用面向对象的开发理念，在u m l 的帮助下，从业务建模、需求分析、 面向对象的分析、面向对象的设计乃至最后的代码生成与测试的全过 程。 关键词：业务建模，需求分析，面向对象分析，面向对象设计，测试 驱动的开发，统一建模语言 a b s i r a c t a b s t r a c t f r o m1 9 8 0 s ，2 0 hc e n t u r y ，o ot e c h 玎o l o g yc a m el ob eah o t s p o t d o z e n so fn e w m e t h o d o 】o 百e se m e r g e da m o n g w h i c h b o o c h ， c o a d ，y o u r d o n ，o m ta n dj a c k b s o n sw e r et h em o s to u t s t a n d i n g a n yi d e am u s tb ee x p r e s s e db ys o m el a n g u a g e t h a t sw h yu m l ( u n i f i e dm o d e l i n gl a n g u a g e ) w e r e f a t e dt ob ei n v e n t e d u m la b s o r b sa l l t h ea d v a n t a g ef r o mb o o c h ，o m ta n dj a b s o n ，u n i f ! i e ss y m b o ls y s t e m a n de m p l o y sm a n yo t h e rp r o v e nc o n c e p t sa n dt e c h n o l o g i e sw h i c hm a k e s u m la ni n d u s t r ys t a n d a r d r u pc o m e sf o n hu n d e rs u p p o r to fu m l r u p 毋0 u p sa l lt h e e x p e r i e n c em a n k i n dd r a w sf m mp r e v i o u ss o 行a r ed e v e l o p m e n ta c t i v i t y w h i c hi n c l u d e si t e f a t i v ed e v e l o pm e t h o d ；m a n a g e m e n to fr e q u i r e m e n t ； c o m p o n e n t _ b a s e ds o f t w a r ea r c h i t e c t u r c ；v j s u a li n o d e l i n g ；s o f t w a r eq u a l i t y v a l i d a t i o n r u pi sau n i v e r s a lt e 珈p l a t ew h i c hj n d u d e sm a n yg u j d e l i n e s ， w o r kp m d u c t s & r m e s b e c a u s er u pi ss oc o m p l e x ，m a n yd e v e l 叩t e 锄s c u s t o m i z ei tt 0m a k et h e i ro w nv e r s i o no f r u p r u pi sl j k ea m e t a - m e t h o d o l o g yb a s e do nw h j c hm a n yi n s t a n c e sa r ec r e a t e d n i st h e s i sd e s c 曲e st h e e x p e r j e n c e a u t h o rd r a w sf r o ms o f t w a r e d c v e l o p m e n tp r a c t j c cw i t ht h eh c l po fr u p ，0 0 u m lf f o mb u s i n e s s m o d e l i n g a n a l y s i so fr e q u j r e m e n t ，o o a ，o o dt oc o d i n g t e s t j n 舀i e x p l o r ea l lt h em a i na s p e c t sm o d e r ns o f t w a r ee n 舀n e e i i n gi n c l u d e s k e y w o r d s ：b u s i n e s sm o d e l i n g ，r e q u i r e m e ma n a l y s j s ，o o a ，o o d ， t e s td r j v e nd e v e l o p m e n t ，u m l 独创性声明 本人声明，所呈交的学位论文是我个人在导师指导下进行的研究 工作及取得的研究成果。尽本人所知，除了文中特别加以标注和致谢 的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不 包含为获得北京交通大学或其他教学机构的学位或证书而使用过的 材料。与我一起工作的同志对本研究所做的任何贡献已在论文中作了 明确的说明并表示了谢意。 本人签名：芬。 日期：丛年上月二日 关于论文使用授权的说明 本人完全了解北京交通大学有关保留、使用学位论文的规定， 即：学校有权保留送交论文的复印件，允许论文被查阅和借阅：学校 可以公布论文的全部或部分内容，可以采用影印、缩印或其他复制手 段保存论文。论文中所有创新和成果归北京交通大学计算机与信息技 术学院所有。未经许可，任何单位和个人不得拷贝。版权所有，违者 必究。 本人签名：壅塑 舻 日期：盟年上月日 第1 章绪论 1 1方法论 在理性思维的指导下，人们逐渐发觉软件开发的确需要方法论的 指导。 方法论的英文为m e t h o d o l o g y ，词典中的解释为”as e r i e so f r e l a t e dm e t h o d so rt e c h n i q u e s ”。我们可以把它定义为软件开发过 程中的一整套方法、过程、规则、实践和技术。 关于方法论的起源，有人说，”方法论源于恐惧”。在软件开发中， 出于对项目的超期、成本失控等等因素的恐惧，项目经理们从以前的 经验出发，制定出了一些控制、监测项目的方法、技巧。这就是方法 论产生的原因。川 通常，大型软件的开发有多个层次，需要分工合作：在开发项目 的各个部分以及各开发阶段之间存在着千丝万缕的联系和衔接问题。 将这些错综复杂的关系协调好，需要统一的约束和规定；在软件开发 项目取得阶段性成果或最终交付时，需进行阶段评审或验收测试。以 上种种可以看出，系统化的管理是软件产品成功的保障。 对于任何一个软件研发团队，软件工程的作用就是将软件设计和 开发作为一项工程对待，采用严格的设计开发规范，将软件开发产业 化，避免以前作坊式的、无序的、杂乱无章的研发。 1 2 使用r u p 开发的必要性 r u p 是方法论的一种。 北京交通人学硕士学位论文 在软件项目中，我们可以分析得出十三个要素，它们基本可以涵 盖软件开发方法论的各个方面，它们是： 角色( r o l e s ) 个性( p e r s o n a l i t y ) 技能( s k i l l s ) 团队( t e a m s ) 技术( t e c h n i q u e s ) 活动( a c t i v i t i e s ) 过程( p r o c e s s ) 工件( w o r kp r o d u c t s ) 罩程碑( m i l e s t o n e s ) 标准( s t a n d a r d s ) 质量( q u a l i t y ) 工具( t 0 0 1 s ) 团队价值( t e a l l lv a l u e s ) 它们之间的关系可以用图1 1 来表示： 有的方法论规定了大量的中间文档和复杂的过程管理，这些中间 文档被称为工件。需要大量工件的软件开发方法被称作重型( h e a v y w e i 曲t ) 方法。在大型项目中，项目经理往往不再担任编码工作， 所以他们无法切身而直接地了解当前工程的进度、质量、成本等因素。 为了更好的控制整个项目，经理们采用了大量的中间管理方法，最典 型的莫过于要求开发人员频繁地递交各种报告。重型方法中的基本假 设是过程及工件是客观的，便于管理和考核的；而个体的程序开发人 员则是相对不可靠的因素。 重型方法难免繁杂，不适用于中小型的软件项目。为了解决重型 方法存在的问题，业界出现了很多轻型( l i 曲tw e i g h t ) 方法。这类 软件工程方法的特点是：尊重个人，强调沟通和反馈，与客户紧密合 作，保持设计的简单性等等。它们努力追求的是希望用低成本的管理 活动带来最大的产出。例如x p 开发方法。 本文研究的主要对象r u p 是一种重型的软件开发方法。 1 3 r u p 结合u m l 的强大能力 历史上来看，曾经出现过数十种面向对象的建模语言，他们相互 独立，彼此无法兼容，业界在经历了无数痛苦的挣扎后，终于意识至u 了统一描述语言的重要性。u m l 的最终出现，主要目的就是消除建模 语言潜在的、不必要的差异，以免用户混淆：其次，通过统一语义和符 号表示，使项目根植于一个成熟的标准建模语言，可大大拓宽所研制 与开发软件系统的适用范围，并大大提高其灵活度。【1 2 1 标准建模语言u m l 的主要特点可以归结为以下三点： ( 1 )u m l 统一了b o o c h 、o m t 和0 0 s e 等方法中的基本概念； ( 2 )u m l 还吸取o o 领域中其它流派的长处，其中也包括非o o 方法的影响。u m l 标准符号考虑了各种方法的图形表示，删掉了大量易 引起混乱的、多余的和极少使用的符号，添加了一些新符号。因此，在 u m l 中汇入了很多面向对象领域的思想，它们都是依据最优秀的o o 方 法和丰富的计算机科学实践经验综合提炼而成的。 ( 3 )u h l l 在演变过程中还提出了一些新的概念。在u m l 标准中 新加了模板( s t e r e o t y p e s ) 、职责( r e s p o n s i b i l i t i e s ) 、扩展机制 ( e x t e n s i b i l i t ym e c h a n i s m s ) 、线程( t h r e a d s ) 、过乖呈( p r o c e s s e s ) 、 北京交通大学硕士学位论文 分布式( d i s t r i b u t i o n ) 、并发( c o n c u r r e n c y ) 、模式( p a t t e r n s ) 、合 作( c o l l a b o r a t i o n s ) 、活动图( a c t i v i t yd i a g r a m ) 等新概念，并清晰 地区分类型( t y p e ) 、类( c 1 a s s ) 和实例( i n s t a n c e ) 、细化 ( r e f i n e m e n t ) 、接口( i n t e r f a c e s ) 和组件( c o m p o n e n t s ) 等概念，大大 提高了语言本身的建模能力。 需要特别指出的是，统一建模语言只是标准的建模语言，而不是 一个标准的开发流程。就像我们利用“英文”既可以描述人物，也可 以描述建筑一样。利用u m l 我们可以描述r u p 开发流程各个阶段所需 的各类物件，使各类物件的含义明确而简洁，便于大家理解。 实践证明，不同的开发机构和不同的问题域，其建模过程不完全 相同。因此，u m l 首先把重点放在通用的元模型( 用带有文字说明的 u m l 符号表示) ，用来统一语义：然后才是通用的符号表示，用以表示 语义提供的表示方法。元模型是用于定义对象模型的语言。元模型 为u m l 的所有元素在语法上和语义上提供了单一的、通用的和确定的 描述。使开发者在语义上取得的一致，不仅消除了人为因素对语义表 示所造成的影响，而且可使工具间的信息交换和复杂系统的设计在含 义上保持高度统一，是基础性的标准化过程。 4 业务建模 第2 章业务建模 2 1 业务建模的定义 业务建模( b u s i n e s sm o d e l i n g ) ，顾名思义，就是分析企业包括 组织模型、流程模型在内的业务模型，以期改进之。在r u p 中将其解 释为：包含用来对业务进行可视化建模的所有建模方法，是可用于执 行业务工程的方法的子集。 2 2 业务建模的必要性 企业级软件需要实现的功能往往注重技术无关性，即同样的业务 模式，可以用不同的开发语言乃至软件架构实现，这可以在最大程度 上保护企业对其业务软件架构的投资，使其不至于在技术进步的浪潮 中遭受颠簸乃至倾覆：这是业务建模的首要驱动力。 从技术发展的角度看，软件开发的层次在逐渐升高，从早期使用 机器语言，汇编语言开发，到使用中级语言c 进行开发，直至c + + 乃 至跨时代的j a v a 语言的流行，明显的趋势是：普通软件开发人员进 行逻辑抽象的层次在逐渐升高，距离机器的底层架构越发遥远。 图2 一l 软件开发层次的提升趋势 北京交通大学硕士学位论文 有理由认为，在不久的将来，程序员只需对业务进行合理建模， 将问题域中需要解决的问题用统一建模语言描述清楚；i d e 及代码生 成器将自动生成所需代码，构造全套的解决方案。可以预见，手动 编写代码的时代终将结束。从这个意义上来看，业务建模是未来软件 开发的主要方向，值得重视。 2 3 业务建模的主要任务 召开广泛参与的业务建模会议 业务建模一般以会议的形式进行，这个会议需要所有的项目干系 人( s t a k e h 0 1 d e r ) 充分参与，以广泛获取其意见。会议中，与会人 员可利用白板，投影仪，绘图仪，数码相机等辅助工具充分表达自己 的思想，在详细记录与会人员的意见后，开发人员再进行全面的整理 概括，借此可大大提高业务建模的质量。 抽象的业务需求概括 概括业务需求应该避免讨论过多的细节，需要时刻记住的是，业 务建模的中心议题是保证快速的讨论出系统的概貌，以建立需求模 型，并得到项目干系人的一致通过。过早深入业务细节会使大家只见 树木，不见森林，无法把握业务模型的本质。其中的分寸拿捏需要有 经验的业务建模专家进行指导和监督。【1 5 】 确定项目边界 项目该做什么，不该做什么，在一开始就须有明确的定义。对于 项目范围内的需求，一个也不要放过；而项目之外的，一个也不要去 关心。虽然有的时候，范围的变化会有利于项目本身，例如客户的合 理要求或是市场目标客户的变化，但是这种变化必须要在”资源充分” 业务建模 和”审批通过”的前提下进行。项目范围的描述可以通过详细的文字陈 述配合图示( 如用例图) 来进行。 确认各项目干系人的利益所在 要想项目成功，绝对离不开项目干系人的有力支持。在项目一开 始，不论是项目干系人还是开发人员，对项目的任务、范围都是模糊 不清的。但随着项目的深入，原来模糊的景象会慢慢清晰、立体起来。 但是为了不浪费时间，我们有必要在项目启动之前，先在项目涉众中 树立一个共同的愿景。共同愿景的树立并非易事，因为每位于系入都 关心自己的利益，具有自己的评判标准。我们把大家的意见都列在白 板上，然后逐项集中讨论，做出修正，直到大家的意见一致为止。在 共同远景的竖立过程中，我们自然而然的确定了项目范围和高层需求 模型。 2 4 模型驱动的开发 以代码为核心的软件开发方法从计算机技术刚刚出现就统治了整 个计算机界，在人类不断追求方法进步的今天，模型驱动的软件开发 ( 1 i l o d e 卜d r i v e nd e v e l o p m e n t ，m d d ) 理念出现了。它是以建模活动 为核心来驱动整个软件系统的开发过程，注重建模活动的在业务分析 阶段的承上启下作用，历史上，它第一次提出了模型不仅是文档，更 是代码的观点。 纵览业界现状，业务模型虽然很早就出现在软件开发过程中，但 事实上，大多数开发人员经常脱离模型进行工作，模型作为指导蓝图， 往往在设计初期被分析、绘制后就柬之高阁，开发者仍然需要手工编 写所有的实现代码。随着项目不断进展，开发者经常发现坚持使用模 7 北京交通大学硕十学位论文 型所带来的约束远大于其好处；甚至维护模型本身就十分耗时耗力， 且对项目成功实现所做贡献低下。久而久之，许多程序员往往认为模 型的象征意义大于其实用价值，最终对其产生抵触情绪。 模型驱动的开发试图充分利用已设计良好的模型，尽力使得模型 与代码最终实现能够更紧密地关联。在m d d 理念的驱动下，模型不仅 是用来展示架构师设计思想的载体，还可用以生成实现代码，从而大 大降低模型与代码双向转换的代价。 m 叻通常由以下5 个步骤组成： l 、创建平台无关的业务模型 这其中包括定义数据项和业务操作。平台无关业务模型是一个抽 象层次较高、独立于任何具体实现技术的系统模型，它着眼于操作环 境中的系统以及系统需求的描述，而不关心系统本身的结构和功能实 现细节。事实上，我们能够使用同一个平台无关业务模型生成多个平 台相关模型，以期大大节省跨平台项目的开发成本。 2 、创建平台相关模型 它与通常意义上的设计模型类似，将平台无关业务模型与实际使 用平台的细节相结合，包含了具体平台的特定实现技术。 3 、由平台相关模型生成特定平台下的实现代码。 4 、为定义的特殊操作手动撰写代码。m 叻工具能够完成通用的 c r u d 操作，但是诸如i n i t o r d e r ( ) 或c h e c k p a s s w o r d ( ) 这样的自定 义操作，目前阶段仍然需要开发人员自行编写代码。 5 、将应用程序进行打包并部署到特定的运行平台上。 需求分析 第3 章需求分析 3 1需求分析的重要性 软件项目开发中会遇到各类棘手的问题，有统计表明，其中百分 之四十至百分之六十是由软件需求分析阶段遗留的缺陷引起的；在产 品投入应用后才改正需求方面的错误比在需求阶段就改正这个错误 要多付出平均6 8 倍的成本。即使研究结果已经揭示了需求分析的重要 性，可实际开发中，至今仍有许多软件项目开发组和软件公司轻视需 求分析阶段的工作，采用极不规范的做法，最终结果是开发出的软件 产品与用户的初始期望相差巨大，浪费人力物力。【】” 需求本质上基于“项目干系人”( s t a k e h o l d e r ) 的利益。 项目干系人，即所有可能受项目结果影响的人。他们既可能受益 者于项目，也可能承担项目实旌后带来的风险。各干系人的利益不可 能完全一致，有时甚至是冲突的，故平衡各方利益是需求分析阶段的 重要使命。 例如开发一个人口普查系统，各项目干系人可能关心的分别是： 高层管理者：希望普查尽可能多的信息，以了解人口宏观状 况：还希望系统使用方法简单，易于学习。 基层普查工作者：希望录入速度快，工作量小，自动化程度 高。 被普查的群众：不涉及自己的隐私，且不需要占用自己太多 的时间填写普查信息。 若对各项目干系人的不同年u 益分析不够彻底，则往往会因各方利 益的冲突而造成工期的延长，成本的增加，甚至项目的完全失败。 益的冲突而造成工期的延长，成本的增加，甚至项目的完全失败。 9 北京交通大学硕士学位论文 所以，从项目的初始阶段开始，就要着重分析项目干系人包含的 人和组织，通过沟通、协调对他们施加影响，驱动他们对项目的支持， 调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获 得成功。 全面识别出项目干系人可采用如下方法： 1 、列表排列出项目中最明显、最重要的项目干系组。 2 、寻找并确定每个项目干系组中的最佳沟通者，当然，适当标 注其在企业中担任的职务有助于更好的理解其权限和权力。 3 、与以上已寻找出的项目干系人沟通，找出他们经常与之沟通 的人员类型，继而分析并确定这类人员是否也是本项目的重 要干系人。 对于除软件开发人员外的项目干系人，他们最感兴趣的往往只是 需求分析阶段。这是他们可以自由表达对软件系统期望的关键时期， 鼓励各干系人畅所欲言，并且用科学的方式将其意见综合整理，是项 目需求管理者的职责。 在我们研发的系统中，每个用例分析出的“项目干系人”可参详 见8 2 节中“t a s 一0 2 c 一0 3 一u c 0 4 ：添加技术术语同义词”用例中的 “s t a k e h o l d e ra n di n t e r e s t s ”部分。 3 2 需求的定义 i e e e 软件工程标准词汇表( 1 9 9 7 年) 中定义“需求”为： ( 1 ) 用户解决问题或达到目标所需的条件或权能 ( 2 ) 系统或系统部件要满足合同、标准、规范或其它正式规定文档 所需具有的条件或权能。 1 0 需求分析 ( 3 ) 一种反映上面( 1 ) 或( 2 ) 所描述的条件或权能的文档说明。 3 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 m l 中的用例( u s e c a s e ) 文档加以说明。尤 其需要注意的是：在用户需求中，必须将各项目干系人的利益都 全盘考虑进去，争取所有项目于系人对软件产品满意。这是一个 软件产品成功的关键。 在我们开发的系统中，一个用例的示例请详见8 2 节 功能需求( f u n c t i o n a lr e q u i r e m e n t ) 定义了开发人员必须实现 的软件功能，这些功能互相配合，使用户能完成他们的工作任务， 从而满足业务需求。所谓特性( f e a t u r e ) 是指逻辑上相关的功能 需求的集合，这些特性给用户提供处理日常商务活动的能力并满 足其业务需求。 三类需求及相关约束元素间的关系如下图所示： 儿 北京交通大学硕士学位论文 图3 1 业务需求、用户需求和功能需求之间的关系 3 4 需求的来源 访问最终用户并与之深入探讨 为找出新软件产品的用户需求，最直截了当的方法是询问最终使 用者真正需要什么，这往往成为软件产品需求分析的入手点。 分析当前市场上同类竞争产品的功能 从竞争对手的畅销产品那里掌握市场的当前需求，分析对手产品 的优势和劣势，结合自身团队的特点规划产品功能乃至产品线搭 配。 收集当前系统的问题报告和增强要求 通过与用户和售后工作人员接触，获得用户在使用现有系统过程 中所遇问题的信息，甚至可得到热心用户关于系统改进的想法。 市场调查和用户问卷调查 需求分析 雇用专门的市场调研公司，从广大有潜力的用户那里获得大量的 珍贵数据，此类调查的目标人群针对性极强，往往能为软件产品 的大获成功打下坚实基础。 观察目前用户的工作流程 对当前系统的用户和将来系统的有潜力的用户，我们可以通过观 察他们的“日常工作”以获得经验，这些经验能提供很有价值的 信息。分析人员可通过观察用户在所关联任务环境中的工作流程 来预见用户在使用当前系统时所遇到的闯题，并能分析新韵系统 可能在哪些方面更加有效的支持工作流程。比起仅仅简单地询问 用户，并记下用户在处理任务时的步骤来说，直接观察用户的工 作流程可使系统架构设计师对用户的活动有更深入的理解。分析 员必须抽象和总结用户的直接活动，以确保所获得的需求具有普 遍性，而不仅仅代表单个用户。 当然，需求分析也很可能与企业的b p r ( b u s i n e s sp r o c e d u r e r e e n g i n e e r i n g ) 结合起来，这是很多全球化的大中型企业采用e r p 系统时必经的流程。当技术与企业的流程再造结合起来时，其焕 发出的强大效率是单单技术因素带来的效率提升所无法比拟的。 3 5 结合需求撰写用例 为使得需求能够满足以下条件： 软件需求的规格说明正确描述了预期的系统行为和特征。 - 从系统需求或其它来源中得到软件需求。 一需求是完整的和高质量的。 所有对需求的看法是一致的。 北京交通大学硕士学位论文 - 需求为继续进行产品设计、构造和测试提供了足够的基础。 3 6 需求验收评审 需求评审是为了明确需求，确定需求。 通常，为了避免软件开发人员视野的局限性，总是由一些非软件 开发人员进行产品的需求评审，以发现需求所存在的问题。需求文档 的评审是一项非常重要的基础性工作，它的主要目标有：发现那些二 义性或不确定的需求，找出那些由于定义不清而不能作为设计基础的 需求，以及揪出那些实际上是“设计规格说明”的“伪需求” 一般来说，需求评审涉及的人员可以包括： 需方：高层管理人员、中层管理人员、最终操作人员、 i t 主管、采购主管； 供方：市场人员、需求分析人员、设计人员、测试人 员、质量控制人员、项目经理； 第三方：本领域的专家。 上述人员由于各自所处立场不同，对同一个问题的看法很可能不 同，各种不同观点形成互补的关系，恰恰保证了评审的质量和效率。 故，要鼓励不同类型的人员真正参与进需求的评审中，否则很可能会 漏掉许多很重要的需求。其次，为了保证评审的高效率，要让那些真 正对系统及业务流程有足够了解的人员( 如一线使用系统的员工) 拥 有更大的发言权。 所以在实际项目操作中，我们通常实行分层次评审。 用户的需求是可以分层次的，一般而言可以分成如下的层次： 目标性需求：定义了整个系统需要达到的目标； 1 4 需求分析 功能性需求：定义了整个系统必须完成的任务； 操作性需求：定义了完成每个任务的具体人机交互步骤； 目标性需求是企业的高层管理人员所关注的；功能性需求是企业 的中层管理人员所关注的；操作性需求则是企业的一线具体操作人员 所关注的。对不同层次的需求，其描述形式是有区别的，更重要的是， 参与评审的人员也应该是不同的。如果让具体的操作人员去评审目标 性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象；如果 让高层的管理人员也去评审那些操作性需求，则往往根本无法找出合 理的操作细节，因为这些细节步骤只有经常操作系统的人员最为熟 悉。 让合适的人担任合适的评审角色是进行高效评审的关键，在这一 点上，有经验的开发团队需要十分注意。 北京交通大学硕士学位论文 第4 章面向对象的分析( o o a ) 4 1 系统顺序图( s s d ) 4 1 1 什么是系统顺序图 系统顺序图是用来表示在用例中描述的特定场景下，外部参与者 如何与系统进行互动及动作问时序的图示。 4 1 2 分析系统顺序图的意义 在进行进一步的系统逻辑设计之前，把系统看成一个黑箱，分析 其行为是十分必要的。在这个阶段，我们仅仅关心系统需要做什么， 而不必关心系统内部的具体实现方法。这样的思维次序有助于我们在 开发的不同阶段将注意力的重点放在合适的地方。待系统作为一个整 体与外界的交互确定后，再进一步分析系统内部如何设计更加简洁、 高效。【1 3 l 这是一种先解决主要矛盾，后解决次要矛盾的方法。 4 1 3什么样的事件需进行系统顺序图分析 系统内部和外部发生的事件很多，但是系统顺序图p 】上需要且只要 表现由参与者跨越系统边界与系统发生的交互事件。外部参与者之间 和系统内部各实体之间的交互事件都不是本图需要表现和分析的目 标。 需要特别注意的是，用例中并非所有场景都需要相应的s s d 图配合 进行描述。事实上，复杂而重要的场景才需要绘制s s d 图。这样的场 1 6 面向对象的分析( o o a ) 景包括 用例中的主流程 用例中的多分支场景 用例中的复杂场景 4 1 4 系统顺序图上动作的命名原则及文字说明 系统顺序图上动作的命名以形象、简洁、统一为好。形象，即看 到命名，就知道这个动作的具体内涵，这样利于小组成员共享文档时 的易读性。统一，就是统一以“动词+ 名词”的方式命名；动词全部 小写，每个名词的首字母大写，这样统一明了，利于沟通。在使用动 词时，要表现出a c t o r 的意图，而不仅仅是手段。例如：在我们开 发的统中，使用e n t e r s y n t e c h w o r d ( 输入技术术语同义词) 就比 t y p e s y n t e c h w o r d 好，因为用户可以将技术术语同义词拷贝并粘贴过 来作为输入，而这各种各样的手段都可被e n t e r 概括。e n t e r 在这里 就是意图，而不是具体的手段。 系统顺序图上往往配以简要的文字说明，以描述当前系统顺序图 对应的用例上下文。此时文字与图示分工如下：文字提供交互细节的 信息，图示则形象地表现出外部用户与系统交互的过程。h 4 2 分析系统中的概念类( c o n c e p t u a ic l a s s ) 识别概念类是问题域调查的一部分。 4 2 1概念类的通俗定义 通俗来说，概念类就是世界上的各类思想、事物或对象。 1 7 北京交通火学硕士学位论文 例如，在现实世界的商店销售领域中，存在如s a l e ，c a s h i e r ， r e g i s t e r ，c r e d i t c a r d 等概念类。而在t a s 系统的“添加技术术语同 义词”操作域中，我们分析出了d b a ，i n s e r t o p e r a t i o n ， s y n s t d t e c h n 柚e ，s t d t e c h n 锄e i d ，d i c t i o n a r y 等概念类。 值得特别指出的是，概念类一般使用名词进行描述，因为世界上 的各种思想、事物或对象本身都是名词短语。 4 2 2 概念类的正式定义 依据概念类的符号、内涵和外延，我们可以从以下几方面来理解 概念类： 符号：代表一个概念类的单词或图片 内涵：概念类的定义 外延：概念类应用的实例 例如，在我们开发的t a s 系统中，一次添加技术术语同义词的操 作，其符号，内涵和外延分别分析如下： 1 8 面向对象的分析( 0 0 a ) 1 n s e r t o p 吖t t i o n i n t r t t i - s y i i s t 盯t c 锄e s t 盯e c 蚶工d 图4 1 概念类的符号、内涵和外延 4 2 3 分析寻找概念类的原则 细粒度原则 我们在分析问题域中的各种对象时，不要怕分析的粒度太细，甚 至可以认为，分析的越细致越好，考虑的越周到越好! 因为想的 越多，越能激发我们去深入思考! 我们把问题想的更透彻一些， 也就达到了分析的终极目的。不要因为某个想到的概念类现在暂 时没有用，就不把他包含到分析模型中去。不知什么时候，我们 就可能用到这个实体，事先尽量保留可以避免以后的重复劳动。 北京交通大学硕士学位论文 及时添加原则 开始分析问题域时，难免遗漏一些概念类；在后面阶段分析属性、 关联甚至进行设计时，发现遗漏，可随时补充。 无属性概念类问题 有些概念类在问题域中仅仅具有行为，而不包括任何属性，这样 的类往往十分重要，需尤其注意。 4 2 4 分析寻找概念类的方法 分类列表法 通过已总结得出的一个在通常情况下值得认真考虑的公共分类， 来分析现有问题在公共分类中的对应情况。 例如，在商店销售领域中，概念类的通用分类及其分析结果如下： 表4 1 概念类的分类分析结果 概念类分类概念类分析结果 人的角色c a s h i e r 交易s a l e ，p a y 珂e n t 交易项目s a l e s l i n e i t 鲫 物理或具体对象r e g is t e r 位置s t o r e 名词短语分析法 就是通过对用铡文字中名词的分析、识别寻找所需概念类的方法。 面向对象的分析( 0 0 a ) 使用分析模式 就是由本领域的专家创建并公开的部分领域模型，专家们认为在 一般情况下，总结出来的概念类很可能在建模时用到。例如，在现实 世界的商店销售领域中，专家们提取出的常用概念类如下： 表4 2 销售领域的常用概念类 s t o r e商店 s a l e一笔交易 c a s h i e r收银员 c u s t e r顾客 m a n a g e r 经理 s a l e s l i n e i t e m购买物品条目 p r o d u c t s d e c i f i c a t i o n购买物品规格明细 p a y m e n t支付金额 4 3 分析域模型( d o i nm o d e i ) 4 3 10 0 a 阶段的主要任务 在使用o o 的方法分析软件问题前，典型的应用程序被看作一个逻 辑流程，接受输入，处理数据，最后得出结果。对程序架构师最大的 挑战是如何将程序的逻辑结构设计的清晰有致。 在现代的0 0 方法中，尽管程序逻辑仍然重要，但是分析和设计的 重点已经转移到了如何合理提取对象和处理对象间关系上。这是程序 架构设计思想的一次朴实回归。因为人类观察周围环境最原始的方式 北京交通大学硕士学位论文 就是以对象为单位，程序设计以此为模式，更加贴近人类思维的本原 模式，从而简单易行。 由此可见，从已经撰写好的需求用例入手，分析需要解决的实际 问题，识别和总结出相关的概念类，是o o a 分析阶段的主要任务。分 析妥当，可为后面的设计和实现打下良好的基础；而一旦分析欠妥， 后面要对之进行改进、完善，则需花费很大的力气。可见，系统架构 设计师在0 0 a 阶段，就像传统意义上建筑行业中的工程师在设计房子 的图纸；在后面的开发阶段好比让工人师傅使用砖头水泥去盖房子。 4 3 2域模型的定义 域模型就是概念类或者问题域中现实对象的可视化表示。我们通 常用u m l 表示法中不定义操作的一组类图来表示域模型，它主要显示 的是： 概念类 概念类问的关系 概念类的属性 域模型最大的优点就是形象化，人们可以借由观察和分析域模 型，方便的考虑现实问题域中需要解决的需求。由域模型中各式各样 “概念类”的引入，激发软件开发人员的思考，引导其得出“软件类” 的设计方案，最终跨越由现实世界到软件世界的巨大鸿沟，开发出架 构合理，扩充性强的软件产品。 这里要特别注意的是，域模型反映的是现实世界中的概念类，而 不是软件产品中的代码类。在o o a 阶段，架构设计的重点在于分析现 实世界，对其适当抽象，而将其最终具体化到软件类这个级别，则是 而向对象的分析( o o a ) o o d 阶段的任务了。 4 3 3 创建域模型的步骤 创建域模型的步骤如下： 列出候选概念类 在域模型中画出候选概念类 添加各概念类自身的属性 添加各概念类之间的关系 4 3 4 域模型中概念类问的关联 概念类问的关联就是两个概念类间的语义联系。 例如，在t a s 系统中，t a sd b a 进行一个插入技术术语同义词的 操作，就可以归纳为如下两个概念类之间的关系： 图4 2 两个概念类之间的关联 一般来说，我们使用一个动词为概念类间的关联进行命名，这样 与前后的名词性概念类形成“名词一动词一名词”的结构，便于阅读 和理解。动词的选择要使得这个结构可读、语义连贯。通常情况下， 横线上动词所表示的( c r e a t e ) 关系应该从左往右或从上往下读取并 理解含义。当然，我们还可以在横线上加一个单向的箭头特别指出读 取此关联关系的方向。 概念类间的关系很多时候是显而易见的，比如，t a sd b a 会发起 一个插入新词条的操作，所以两者之间的关系是c r e a t e 。又如：一个 北京交通人学硕士学位论文 超级市场会有很多的存货，所以s u p e r m a r k e t 和m e r c h a n d i s e 之间是 s t o r e 的关系。在软件工程o o a 的域模型分析中，我们把这样的常用 关系组织成表，供建模者参考、拟定概念类间的各种关系，其例子参 见表4 3 值得特别注意的是，在寻找概念类时“越多越好”的原则并不适 用于探询概念类问的关联；相反的，关联是宁缺毋滥。在一个有n 个 概念类的域模型中，每个概念类可能与其它的n 1 个概念类都发生 关联。在最极端的情况下，此域模型中会有个( n 一1 ) ! 个关联。显然， 域模型中可能的关联数目是非常巨大的，而它们是否真的对我们都有 用呢? 简单分析一下即可看出，概念类问的关联过多，首先会耗费 我们大量的时间去寻找和定义；其次会混淆我们对域模型整体架构的 理解，不利于我们抓住现实世界中问题的本质，不利于将问题简洁、 清晰的表述出来。故每添加一个关联都需要慎重考虑，以期尽量减少 概念类之间关联的数目。 总之，我们分析域模型的重点还是分析辨别概念类，概念类都找 出来了，其间的关联迟早都会浮出水面；相反，如果概念类都没有找 完全，何谈其间的关联。实际设计和开发过程中，我们的经验是，识 别概念类的时间和分析其间关联的时间比可控制在3 ：1 左右。 在刚学会运用o o 理念分析问题时，往往不很熟练，对概念类之间 关联的把握能力较弱，此时，我们可以借助表4 3 中的通用关联类 日表来寻找问题域中的关联关系，以免遗漏。4 3 面向对象的分析( o o a ) 表4 3 通用关联类目表 c a t e g o r ye m m p l e s a ba 曲笋i c a l p 矾o f b d m 1 一蜀目辱，蛔f 日i o 荦呼 衲魄口鲫， 聊哼一m 础 a i sal o g c a l p a | t o f b 翻坛虹庇啦f 酝m 一6 h 如 f 靴壤f z 耐峨斑如 a i s 砷y 葫c a n y c o 曲妇e d 甜o n b威g 嘲f 一盛鸭j h m 一删 凡嬲碰r 学旷一一生雄璃册e a i s l o 出a n y c 伽t a i n e d i n b册吡b 呻蜘一。栅喀 黝b 黝盘蝴船 a i s a d e s c 啕) t i 锄胁b砌此惦咖廊h 一撕 同劝出r 脚，一而g 拊 a i sa 壮n e i t 咖o f a 啦啦翰c t 溉o r 掣n b& 硝帮l 曲捌女晰l 一鼬 蛐艟 口糅j 硒a 鳓陀n d i 厶喀 a i s k w 醚。辫，e 讲d e 出f e p w f e 础c a p 劢如一忍啦睁 删诅b 忍m 蛳m 一用拉h 细i 驷 a i sa m 锄口b 盯o f b o ，6 f 一& b m 芦1 5 吖一唐自口聍 舳o r g a n i z a n l 心m i t o f b z k 自田由”e ，耐一5 物r p 丑d 矗女w 扫m 髓扣妨孵 a l s o r m b g bq 8 黼f 一忍蚋橱。 砌f 一撕咖 ac 伪蚴m i c a l e sw i m 丑 ( h 鲥翻，孵r c h 眩盯 蜀鳓旷岫棚4 静甜一f 鼬削咿 a i sr e 主a 担d | oa 盯a 嘲吐o l l bc 轧蝣朔r b 句柏时 只鄹日觜盯一豫南盯 ai sa 吐a n s a 甜o bf e i a l e dt oa n o t l l 臼仃a n s _ 月耳 时一跳 a ：f i o n b置毋日n l 蓦d n ( 轴崔鲤d d o n a i s n e x t t o b & 硝躲d 瓣翻l 研i 一& 础嚣【加圳豫晰 妒嘶， 概念类之间可能存在多重性关系。多重性关系就是a 类的一个实 例和b 类的若干个实例同时发生关联。例如：在我们的t a s 系统中， 一个技术术语权威档可以同时对应若干个技术术语同义词，可用以下 图示表示： 北京交通火学硕士学位论文 图4 3 一对多关系 需要特别指出的是，多重性的对应关系强调的是一个概念类的实 例在某个特定的时刻而非一段时间内，可以与多少个实例发生关系。 时刻是一个点，时段是一个区间，两者差别巨大，示例如下： 图4 4 一对一关系 t a s 系统中，在某个时段里数据库管理员可以向系统中插入多条 技术术语同义词的记录；但是在某一时刻，数据库管理员只能发起并 执行一个插入操作，所以