（系统分析与集成专业论文）敏捷建模在mis系统中的应用.pdf

摘要 敏捷建模是针对基于软件系统的有效建模和编写文档的一个混乱而有序的、基于实 践的方法。简言之，它就是一组能够以有效和轻量级的方式应用于软件开发项目的价值 观、原则和实践的集合。敏捷建模并非一个完整的软件过程，需要把它与另一个完整的 过程一起使用，并被用来增强这些过程。采用敏捷建模，建模人员能够找到建模的最佳 点，在这一点上既进行了足够的建模，以保证有效地研究和记录系统，但又没有过多地 建模以致变成减慢项目进度的负担。 本文首先论述t r a t i o n a l 统一过程及统一建模语言u m l ，并深入剖析了当前运用r u p 进行软件开发实践时出现的典型问题。针对这些问题，引入了敏捷建模思想。并对敏捷 建模的核心实践进行了分析研究，同时与当前r u p 实践进行比较。在对r u p 和a m 进行充分 研究的基础上，依据a m 的实践和原则对r u p 进行相应的改造，并总结出敏捷化统一过程 的特点。根据敏捷化统一过程的特点，提出了一个敏捷化统一过程需求建模过程一“总 体概要需求获取，按需求优先级进行计划，小增量迭代式简单需求建模”，同时分析研 究了敏捷化统一过程的部分需求建模制品，并引入了结合场景和目标的需求分析技术。 关键词：统一过程敏捷建模需求建模建模过程 a b s t r a c t a g i l em o d e l i n g ( a m ) i sad e c o m p o s e da n dp r a c t i c e - b a s e dm e t h o d o l o g yf o re f f e c t i v e m o d e l i n ga n dd o c u m e n t a t i o no f s o r w a r e - b a s e ds y s t e m s s i m p l yp u t ，a mi sac o l l e c t i o no f v a l u e s ，p r i n c i p l e s ，a n dp r a c t i c e sf o rm o d e l i n gs o f t w a r et h a tc a l lb ea p p l i e dt oas o r w a r e d e v e l o p m e n tp r o j e c ti na ne f f e c t i v ea n dl i g h t - w e i g h tm a n n e r a mi sn o tac o m p l e t e ds o r w a r e d e v e l o p m e n tp r o c e s s ，i ts h o u l db eu s e dw i t ho t h e rp r o c e s s e st oa c h i e v eab e t t e rr e s u l t s y s t e m m o d e l e rc a nf i n dt h eb e s tp o i n to f m o d e l i n gw h e n u s i n ga m i nt h a ts e n s e ，s y s t e mm o d e l e rc a ne s t a b l i s ht h es y s t e mm o d e lw i t hm i n i m i z e d t i m ew h i l em a i n t a i n i n gt h eq u a l i t yo f d o c u m e n t sa n dp r o c e s sc o n t r 0 1 i no t h e rw o r d s ，t he p r o j e c tc o u l db es p e e d u p t h i sd i s s e r t a t i o nf i r s td i s c u s s e st h er a t i o n a lu n i f i e dp r o c e s sa n dt h eu n i f i e dm o d e l i n g l a n g u a g e ( u m l ) ，a n dt h e ne x p l o d e sa ni n d e p t hs t u d yt ot h er e p r e s e n t a t i v ep r o b l e m st h a t e x i s ti nt h ep r a c t i c eo fd e v e l o p i n gs o f t w a r eu s i n gr u bt h i sd i s s e r t a t i o ni n t r o d u c e st h ea g i l e m o d e l i n gi d e aa g a i n s tt h e s ep r o b l e m s ，t h e ns t u d i e sa n da n a l y s e st h ec o r ep r a c t i c e so ft h e a m ，s i m u l t a n e o u s l yc o m p a r e st h ea mp r a c t i c ew i t ht h ep u r er u pp r a c t i c e b a s e do nt h e s e s t u d y , t h i sd i s s e r t a t i o nd e s c r i b e sh o wt om o d i f yt h er u pa c c o r d i n gt ot h ea mp r a c t i c e sa n d p r i n c i p l e s ，t h e nc o n c l u d e st h ef e a t u r e so fa 西l er a t i o n a lu m f i e dp r o c e s s ( a m - r u p ) b a s e d o nt h e s ef e a t u r e s ，t h i sd i s s e r t a t i o nb r i n g sf o r w a r dt h ea m - r u pr e q u i r e m e n tm o d e l i n g p r o c e s s 一”g e t t i n gg e n e r a lr e q u i r e m e n t s ，p l a n n i n gb yr e q u i r e m e n tp r i o r i t i e s ，s i m p l e r e q u i r e m e n tm o d e l i n ga tt h es m a l li n c r e m e n ta n di t e m t i v em o d e ”，a n ds t u d i e sa n da n a l y s e s s o m ea m r u pr e q u i r e m e n tm o d e l i n gw a r e sa n di n t r o d u c e st h es c e n a r i oa n dg o a l r e q u i r e m e n ta n a l y s i st e c h n o l o g y k e y w o r d s ：r a t i o n a lu n i t e dp r o c e s s a g i l em o d e l i n gr e q u i r e m e n tm o d e l i n g m o d e l i n g p r o c e s s l l 湖北大学学位论文原创性声明和使用授权说明 原创性声明 本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所 取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任 何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡 献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的 法律后果由本人承担。 论文作者签名：耘佐 日期：z - q 年月7e l 学位论文使用授权说明 本学位论文作者完全了解学校有关保留、使用学位论文的规定，即： 按照学校要求提交学位论文的印刷本和电子版本；学校有权保存学位 论文的印刷本和电子版，并提供目录检索与阅览服务；学校可以允许采用 影印、缩印、数字化或其它复制手段保存学位论文；在不以赢利为目的的 前提下，学校可以公开学位论文的部分或全部内容。( 保密论文在解密后遵 守此规定) 作者签名：张经 船教师躲掷 日期：工- 口7 多，岁 日期：洳辟6 j ；i7 日 第一章绪论 1 1 研究背景及意义 第一章绪论 随着社会信息化水平的不断提高，世界上数以力计的软件开发团队讵在为各种行业 开发各种软件应用程序，开发团队的共同目标是：在预算内按时开发符合用户真正需要 的高品质软件。然而现实并非如此，当前软件开发的主要难点在于： 1 实际问题的复杂性。由于用户需求所涉及的因素多，而导致问题的复杂化。 2 交流困难。需求分析涉及人员多，这些人员往往具有不同的背景知识，且处在不 同的角度，扮演不同的角色，从而不可避免地会带来交流上的问题。 3 不完备性和不一致性。由于种种原因，用户对问题的陈述往往是不完备的，其各 方面的需求不可避免地会存在矛盾。如何消除其矛盾，最终形成完备且一致的需求定义， 这也是一个难点。 4 易变性。用户需求的变动是一个极为普遍的问题，特别是在有关国家机关和企业 信息系统的开发工作中，由于相关的政策和市场的不断变化，随之需求也在不断的变化。 如果不能很好的应对，会导致整个项目的进度和质量都难以控制，最终使整个系统失败。 在我国，用户对于如何应用计算机软件并没有一个成熟的经验，在项目进行中用户 会频繁的改变和增加各种要求。当最终完成系统的建设时，却发现企业的业务需求已经 发生了很大的改变，一方面是系统的设计已经无法很好地满足新的需求，另一方面是项 目周期大大超过预期，项目发生亏损 据美国软件工程实施现状的调查，软件研发的情况也是很难预测，大约只有1 0 的 项目能够在预定的费用和进度下交付。由于这些问题的出现，软件工程领域的专家就提 出了应用敏捷方法的思想来应对软件开发过程中需求变化的问题。“敏捷”( a g i l i t y ) 是为了适应日趋激烈的竞争和生存环境而提出的一种新概念，它要求企业通过提高敏捷 性，从变化的调整中掌握主动并赢得市场这一概念在制造业中己被广泛讨论和实践， 以敏捷制造( a g i l em a n u f a c t u r i n g ) 为核心的先进制造为全世界广为接受。近年来，软 件开发全球化、个性化、快速化、高质量、新格局向软件工程提出了极大的挑战。“敏 捷”概念因此被引入软件领域，逐渐形成一种新的软件建模方式一敏捷建模( a g i l e 湖j 人学硕十学位论文 m o d e l i n g ) 敏捷建模是对已有方法的补充，而不是一个完整的方法论：而统一过程是己为广泛 使用的成熟的软件过程。将敏捷建模新思想融入统一的软件过程中，将顺应当前的软件 需求的要求，大大提高软件开发效率。本文在考虑需求建模时，将采用敏捷化统一建模 方法，并结合环保m i s 系统需求建模实例来具体说明如何选择建模技术制品进行需求建 模。 国内外对敏捷化统一软件过程的需求建模研究还没有形成很成熟的理论，敏捷化统 一软件过程中需求建模技术的研究还处于初级阶段。当前统一软件过程下的需求建模主 要还是运用u m l 。因此，本课题的研究无论在软件过程的理论探讨方面，还是在需求建 模应用实践指导方面都有极其重大的意义。 1 2 研究的内容和目标 1 ) 主要研究内容 r a t i o n a l 统一软件过程。 u m l 技术理论。 敏捷建模思想及建模相关工具。 敏捷建模与统一过程的结合。 敏捷化的统一需求建模过程及技术。 2 ) 研究目标 将敏捷建模技术和统一需求工程方法相结合，使用u m l ，敏捷建模技术及相关的工 具构建企事业信息系统的需求模型及需求变更演进直至需求确认的循环迭代式敏捷需 求建模过程。 1 3 论文的结构 1 ) 第一章为绪论。主要介绍了本文研究的背景及意义、研究的内容和目标及全 文的总体结构。 2 ) 第二章为r a t i o n a l 统一过程和u m l 。主要讨论统一过程的特点、生命周期及主 要的建模技术u m l ，最后讨论了敏捷方法、敏捷建模过程的价值观、核一t l , 实践及原则。 3 ) 第三章为r a t i o n a l 统一过程敏捷化。通过总结当前r u p 实践存在的不足之处， 2 第一章绪论 同时与当前r u p 实践进行比较，说明了本文研究的“敏捷建模在m i s 系统中的应用”这一 问题的必要性，并提供了敏捷建模方面的方法及实践支持。最后，将敏捷建模实践及原 则融入r u p 中，建立敏捷化统一过程。 4 ) 第四章为敏捷化统一过程软件需求建模。本章作为全文的主要部分，详细分 析研究了强化统一过程的敏捷建模技术方法，提高软件开发的效率，并依据敏捷化统一 过程理论实践特点提出一个敏捷化统一过程软件需求建模过程。 5 ) 第五章为环保m i s 系统需求建模。本章主要结合环保m i s 系统的需求建模实 例来具体说明如何利用各种建模技术方法在敏捷化统一过程中进行需求建模。 6 ) 论文的末尾是对课题的总结和展望。总结了课题研究的主要贡献及将来有待进 一步研究的问题。 7 ) 参考文献列出了本文所引用的全部文献。 湖北人学硕十学位论文 第二章研究涉及的关键技术基础分析 上章介绍了课题的研究背景和意义，本章将介绍研究所涉及的关键技术基础分析。 2 1r a t i o n a i 统一过程 本节将引入本论文的理论基石之- - r u p 。统一过程，它是本文所要研究的敏捷化统 一过程需求建模的基础。所谓基于敏捷化统一过程需求建模，就是以r u p 为组织的标准 过程，结合敏捷建模思想和r u p 的特点构造一个需求建模过程。 r u p 是r a t i o n a l 公司提出的一个通用的软件开发过程框架。“它是一种软件工程过 程( s o f t w a r ee n g i n e e r i n gp r o c e s s ，软件工程过程并不是以工程数学的角度来探讨软 件过程，而是应用工程式的纪律来管理和组织软件开发或维护的过程) ，为在丌发组织 中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内， “1 丌发出满足用户需求的高品质的软件”其实，r u p 是涵盖以下两个方面的综合过程： 1 ) 从软件工程过程的方面来看，统一过程是一个软件开发过程，即是指为了达到 目标而实施的一组有序的步骤。在软件生命周期中，统一过程就是为了实现满足用户需 求的软件系统所需的一系列步骤的汇总( 如图2 1 所示) ，它对软件丌发的周期、阶段、 工作流步骤提供了详细的指导。 输入 - - - 用户需求 图2 1r u p 是一个软件开发过程 2 ) 从项目组织管理方面来看，统一过程不仅是一个简单的开发过程，它还是一个通 用的、可裁剪的项目管理框架。统一过程从广泛的软件项目中吸取了不少最佳的软件开 发实践。这些实践经验对软件项目组织中的四要素( 人员、项目、产品和过程) 之间关系 的协调管理提供了有效的指导，从而达到项目风险缓解、质量控制、优化项目管理和配 置管理的目标。统一过程框架可依据软件项目的实际情况进行合适的裁剪，使之在各种 4 第一二章研究涉及的关健技术基础分析 不同的项目规模、各种不同的应用领域、各种不同类型的软件系统、各种不同类型 的组织及各种不同的性能水平上成功的发挥作用 2 1 1r u p 的生命周期 与传统的软件开发模型相比，传统的软件开发模型( 如瀑布模型) 通常是一个一 维的模型，而统一过程的生命周期可用二维结构来描述，如图2 2 ，该图的一次循环代 表了统一过程的一次生命周期。统一过程是一个将用户需求转化软件系统所需的活动集 合，该活动集合是在过程的生命周期中完成的 图2 2r u p 生命周期 统一过程是在重复一系列的生命周期，这些生命期构成了一个软件系统的寿命。 每个生命期都以向用户推出一个产品版本作为终结。每个周期包括初始、细化、构造、 交付四个阶段。正如上图所示，每个阶段可以迸一步划分为多次迭代。软件开发组织正 是在该过程的指导下，不断重复过程的生命周期，从而不断向用户提供越来越符合用户 需求的软件产品版本，推进着系统不断升级 2 1 2r u p 的动态结构 在统一过程生命周期的二维结构图的横轴上包含阶段和迭代两项内容，这两项即 是开发过程沿时间的动态组织结构。在此时间维上，为了能够方便地管理软件开发过程， 5 湖北人学硕士学位论文 监控软件开发状态，r u p 把软件生命周期划分为若干次迭代，每次迭代生成一个产品的 新版本并依次由四个连续的阶段组成，每次迭代都应完成确定的任务，正是这些迭代过 程不断产生系统新的增量，使产品不断成熟，从低版本软件不断过渡到高版本软件 1 ) 四大阶段 软件生命周期被分解为周期，每一个周期工作在产品新的一代上，r u p 将周期又划分 为初始、细化、构造、交付四个连续的阶段。每个阶段都终结于一个良好定义的罩程碑。 其实，每个阶段就是两个主要里程碑之间的时间跨度。在每个阶段结束时要依据罩程碑 目标进行工作评估，以确定是否实现了该阶段的目标以及是否可以进入下一个阶段。 ( 1 ) 初始阶段 初始阶段的目标是为系统建立业务案例和确定项目的范围及边界条件，为了达到 该目的必须识别所有与系统交互的外部实体、在较高层次上定义交互的特性。它包括识 别所有用例和描述一些重要的用例。业务案例包括验收规范、风险评估、所需资源的估 计及体现主要罩程碑同期的阶段计划。在初始阶段，通常要建立一个或多个用于验证的 概念原型。 本阶段具有非常重要的意义，在这个阶段中关注的是整个项目进行工程中的业务和 需求方面的主要风险。 ( 2 ) 细化阶段 细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划和淘汰 项目中最高风险的元素。在本阶段，需在理解整个系统的基础上，确定它的范围、主要 功能和如性能等非功能性需求，建立一个合理的体系结构基础。在细化阶段，需建造一 个包含高质量组件的可演化的产品原型。 细化阶段是四个阶段中最关键的阶段。细化阶段活动确保了结构、需求和计划的稳 定性并充分减轻了风险性，最后决定项目是否提交于构造和交付阶段。 ( 3 ) 构造阶段 在构造阶段，迭代地、增量地开发软件系统。通过不断测试、不断改进软件、体系 结构和方案，直至开发出完整的产品。 ( 4 ) 交付阶段 交付阶段的目标是将软件产品交付给用户使用。在交付阶段的终点是第四个重要的 项目里程碑一产品发布里程碑。此时决定是否目标己达到或开始另一个周期。 2 ) 迭代过程 6 第一二章研究涉及的关健技术基础分析 r u p 的每个阶段都由一个或多个连续的迭代组成。迭代过程是导致可执行产品版本的 完整开发循环( 即从捕获需求到代码实现) ，是最终产品的一个予集，从一个迭代过程到 另一个迭代过程递增式增长，形成最终的系统产品。在各阶段中，每个过程工作流各有 不同的重点。通常，在初始阶段，迭代工作重点在于需求捕获：在细化阶段，重点转移 到分析和设计：在构造阶段，实现是中心活动：而交付阶段的，中心任务在于实施 2 1 3r u p 的静态结构 在统一过程生命周期的二维结构图的纵轴上表现了过程的静态结构。 1 ) r u p 的模型元素 r u p 的静态结构包括角色、工作流程、活动、工件四个基本模型元素。它们分别描述 了软件开发过程“谁”“什么时候”“如何”“做”某事以及怎样实现某一特定的目 标。模型元素之间的关系如图2 3 所示。 ( 1 ) 角色，定义了个人或由若干人所组成小组的行为和责任。角色通过执行某些活 动完成特定工件。 ( 2 ) 活动，是具有明确的目的的工作单元，通常表现为一些产物如模型、类、计划 等。 ( 3 ) 工件，是项目期问由活动生成并使用的中问或最终产物。工件有多种存在形式， 包括模型、模型元素、文档、源代码、可执行文件等。 ( 4 ) 工作流程，是产生具有可观察结果的活动序列。每个工作流产生一些有价值的 工件。r u p 主要提供两种组织工作流的方式：核心工作流和核心支持工作流。工作流的具 体内容将在下- - 4 , 节详细介绍。除以上四个基本模型元素，r u p 还包括一些辅助活动 及工件的其他一些模型元素。其中工作指南和工具向导，提供了角色执行二活动的方法 和应用工具的步骤：概念则是包含了工作流中的重要概念：报告则存放着模型与模型元 素之间相关联的信息：工件相关的指南和检查点，提供有关开发工件、评估工件和使用 工件等信息。 7 湖北人学硕+ 学位论文 马 角色 豳 糍念 d 一黧 活动 - t - c ej 餐p l l 主耋 案 静 z 嘉导 。 工件 。 。7l 4 。毒嚏 囵 鹪黧 檎囊虑 王伴插黼 搬侮 瀚 棱缀 图2 3r u p 静态结构图 2 ) 工作流程 r u p 共有九个工作流程( 如图2 2 所示) ，其中分为六个个核心工程工作流程：业务建 模、需求、分析和设计、实现、测试、部署工作流：三个核心支持工作流程：项目管理、 配置和变更控制、环境工作流。这九个工作流程并不是顺序执行的，而是在整个生命周 期中的每个阶段迭代并行执行的。 ( 1 ) 业务建模工作流，说明如何拟定新目标组织的前景，并基于前景来确定该组织 在业务用例模型和业务对象模型中的流程、角色以及职责。 ( 2 ) 需求工作流，主要目标是描述用户的需求，并做到与用户和其他涉众在系统的 工作内容方面达成且保持一致，使系统开发人员能够更清楚地了解系统需求，定义系统 边界，定义系统的用户界面。 ( 3 ) 分析和设计工作流，将需求转换为未来系统的设计，逐步开发强壮的系统构架。 使设计适合于实现环境，最后得到一个为软件特定环境支持详细的系统结构描述。 ( 4 ) 实现工作流，目标是用源代码、可执行程序等构件实现设计模型中的元素( 如设 计类和接口等) ： 8 第_ 二章研究涉及的关健技术基础分析 ( 5 ) 测试工作流，分单元测试、阶段测试和系统测试。主要目标是核实对象之间的 交互及所有构件是否正确集成，确定缺陷并确保在部署软件之前将缺陷解决。 ( 6 ) 部署工作流，为确保最终用户可以正常使用软件产品而进行的活动( 如软 件打包、系统配置等) 。 ( 7 ) 项目管理工作流，描述如何控制软件项目组内部的各个成员的相互关联的工 作。目标是为计划、执行和监控软件开发项目提供可行性指导：为风险管理提供框架和 环境：为组织提供过程管理和工具的支持。 ( 8 ) 配置和变更控制工作流，控制对项目产品的变更，并且维护项目产品的完整性。 ( 9 ) 环境工作流，描述为支持项目而开发指南及在配置流程时所需的活动。主要目 的是为软件开发组织提供软件开发环境( 流程和工具) 。 2 1 4r u p 的特点 r u p 所具有的特点是：用例驱动、体系架构为核心、迭代增量，可剪裁性。下面详细 介绍。 1 ) 用例驱动 将u s ec a s e 作为划分问题的组织单元，分析和设计活动的局部粒度都遵循这一划分 原则。u s ec a s e 的定义反映了系统外部要素根据特定目标使用拟建系统的情况，能保证 问题的局部划分不过于粗略，也不过于琐碎，进而维持了全局重心和局部重心的平衡。 用例并不仅是定义一个系统的需求的工具，它们还驱动整个开发过程。其实， “用例驱 动”即指开发过程将遵循一个流程：它将按照一系列由用例驱动的工作流程一首先是定 义用例，然后是设计用例，最后用例是测试人员构建测试案例的来源来进行。 用例确实在驱动整个开发过程，但是不能仅选择用例。它们必须与系统架构协 同开发。两者互相影响，最终均会随着生命周期的延续而逐渐完善。 2 ) 体系构架为核心 构架是系统最高层概念。在系统建模中，构架主要是指拟建系统重要设计内容的逻 辑组织及结构。统一过程是以多种构架视图来表示软件构架，每种构架视图针对于开发 流程中的涉众所关注的特定方面，它包括用例图、逻辑视图、配置图和构件图等。体系 构架重要有以下四个作用： 湖北人学硕十学位论文 ( 1 ) 理解系统。r u p 使用u m l 可视化建模系统的构架，并以构架为中心进行丌发，这 使得开发人员、管理人员及其他相关人员能够详细理解所需要做的工作，以利于他们参 与系统的开发。 ( 2 ) 组织开发。构架设计师通过将系统划分为带有明确定义接口的子系统，并让开 发小组负责每个子系统，可以显著减少开发组之间交流的工作量，而且接口双方的软件 可独立地进化。 ( 3 ) 鼓励重用。好的构架为开发人员提供了可以在其上开展工作的稳定的骨架，它 有助于开发人员知道在哪罩能有效地找到可重用的元素以及发现合适的可重用的组件。 ( 4 ) 进化系统。一个具有稳定的构架的系统在分析和设计时就考虑到系统进化的需 求，从而具有一定的容变能力，系统可以适度地进化。 3 ) 迭代和增量开发过程 在统一过程中，软件的生命周期是由一系列迭代组成的，这些迭代都是由软件项目 分解成的许多袖珍项目。每个迭代都产生一个内部版本，其中每个内部版本会增加一个 增量并表明存在的风险得以降低。这些版本通过展现给用户，获得有价值的反馈以确认 工作成效早期阶段的迭代主要是确定项目范围、消除关键风险及建立系统构架基准。 后期迭代则不断增加增量结果，直至获得可对外发布的产品。 4 ) 可裁减性 r u p 提供了在软件开发中涉及到的几乎所有方面的内容，r u p 有九个工作流程，共有 5 8 个工作流程明细和1 3 4 个活动，大约8 9 个产品。r u p 所包含的活动、工作流程、产品、 角色等元素可以是各种元素的全集。其实，并不是过程的所有细节都要执行或者所有详 细的产品都要生产，各项目团队可以根据各自的情况及项目的需要剪裁r u p 以适合特定 的应用，即进行组织级的流程配置和项目级的流程配置。 2 2 统一建模语言 统一建模语言( 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 o s e 方法、o 婀方法以及其他方法大师优秀观点的统一 2 1u m l 统一了面向对象方 法中使用的符号，在广大用户使用经验的基础上，为面向对象分析与设计领域的标准化 打下了基础。统一过程使用的是u m l 。事实上，u m l 是统一过程的有机组成部分一它们 第二章研究涉及的关健技术基础分析 是被同步开发的。 2 2 1u m l 的内容 作为一种建模语言，u m l 的定义包括u m l 语义和u m l 表示法两个基本部分。它们分别 是由元模型和图组成和表示的。图是u m l 语义的表示法，而元模型则给出图的语义。u m l 语义用于对现实世界进行抽象和描述，而u m l 表示法则通过可视化的图形符号表达u m l 语 义。以下将分别介绍。 u m l 表示法：定义u m l 符号的表示法，为开发者或开发工具使用这些图形符号和文本 语法提供了系统建模标准”1 。这些图形符号和文字所表达的是应用级的模型，在语义上 它是u m l 元模型的实例。 1 ) u l l l 语义 u m l 语义描述基于堋l 的精确元模型定义。元模型为u m l 的所有元素在语法和语义上 提供了简单、一致、通用的定义性说明，使开发者能在语义上取得一致，消除了因人而 异的表达方法所造成的影响。u m l 还支持对元模型的扩展定义。 u m l 语义主要部分即是u m l 模型元素，它是用来抽象、描述现实世界的u m l 语义成 分，在u m l 中它具体实现为u m l 中的四种事物。事物是对模型中最具有代表性的成分的抽 象：关系把事物结合在一起。最后它们通过u m l 的图形符号表示出来【4 】【5 1 。 u m l 中描述语义的四种事物：结构事物、行为事物、分组事物、注释事物。以上事 物是u m l 中基本的面向对象的构造块，用它们可以建造出结构良好的模型。 ( 1 ) 结构事物 结构事物通常是模型的静态部分，描述概念或物理元素。共有七种结构事物：类、 接i ：1 、协作、用例、主动类、构件、结点。其中类是一组类似对象的抽象。接口是描述 一个类或构件的一个服务的操作集。协作定义了一组元素的交互，并且这些协作行为大 于各个元素独立行为的总和。用例是对一组动作序列的描述，为系统提供功能的描述。 主动类是拥有一个线程或进程，能启动控制活动的类。构件是系统物理的、可替代的部 件。结点是运行时存在的物理元素。 ( 2 ) 行为事物 行为事物是u m l 模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的 行为。共有两类行为事物：交互和状态机。交互是由在特定的语境中共同完成一定任务 湖北人学硕十学位论文 的一组对象之间交换的消息组成。而状态机是这样一种行为，它描述了一个对象或一个 交互在生命期内响应事件所经历的状态序列。交互和状态机者两种元素是可以包含在 u m l 模型中的基本行为事物。在语义上，这些元素通常与各种结构元素( 主要是类、协作 和对象) 相关。 ( 3 ) 分组事物 分组事物是u m l 模型的组织部分。它们是一些由模型分解成的“盒子”。在所有的 分组事物中，最主要的是包。包是把元素组织成组的机制。它是用来组织u m l 模型的基 本分组事物。它有诸如框架、模型和子系统等变体。 ( 4 ) 注释事物 注释事物是u m l 模型的解释部分。这些注释事物用来描述、说明和标注模型的任何 事物。 u m l 中的各种事物是通过依赖、关联、泛化、实现四种关系结合在一起。依赖描述 两个事物f h j 的语义关系，其中一个事物变化是会影响另一依赖的事物。关联描述对象之 问的连接。泛化表示一种特殊和一般的关系。实现指定了一个类元对另一个类元保证执 行的契约，常用于接口和类或构件之间。 2 ) u m l ：表示法 u m l 描述的模型是由一系列要素、关系和图的排列组合而成的。要素是模型的核心： 关系是在逻辑上将要素联系在一起的纽带：图则是展现一组要素和关系的载体。u m l 正是 通过各种不同的图和这些图之间的联系来更好的描述软件系统从需求分析到软件测试 开发的全过程。 运用u m l 建模的方式可以归纳为静态建模和动态建模两大类。可以由下列五类图来 完成： 第一类：用例图。包括用例( u s ec a s e ) 和角色( a c t o r ) 用来从用户角度描述系统功 能，并指出各功能的操作者。u s ec a s e 是u m l 的核心。u s ec a s e 在软件开发的需求、分 析与设计、实现和测试四个核心流程中扮演着重要的角色。 第二类：静态图。包括类图、对象图和包图。其中，类图描述系统中类的静态结构， 不仅定义系统中的类，还表示类之间的联系，如关联、依赖、聚合等，也包括类的内部 结构( 类的属性和操作) 。对象图是类图的实例，几乎使用与类图完全相同的标识，不同 点在于对象图显示类的多个对象实例，而不是实际的类。包由包或类组成，表示包与包 之间的关系。包图用于描述系统的分层结构，是将大系统拆分为小系统的工具，可以帮 1 2 第二章研究涉及的关健技术基础分析 助理解与维护系统。 第三类：行为图包括状态图、活动图，用来描述系统的动态模型和组成对象间的 交互关系，其中状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件， 它是对类图的补充。在实用上并不需要为所有的类画状态图，仅为那些有多个状态，其 行为受到外界环境的影响而发生改变的类画状态图。而活动图描述满足用例所要进行的 活动以及活动间的约束关系，有利于识别和表达并行活动。 第四类：交互图。包括时序图、合作图，用来描述对象间的交互关系。其中时序图 显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之问的 交互。合作图描述对象间的协作关系，合作图和时序图相似，显示对象问的动态合作关 系。除显示信息交换外，合作图还显示对象以及它们之自j 的关系。 第五类：实现图。包括构件图，配置图，其中构件图描述代码部件的结构及各部件 之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部 件。配置图定义系统中软硬件的物理体系结构，它可以显示实际的计算机和设备( 用节 点表t ) 以及它们之间的连接关系，也可显示连接的类型及部件之问的依赖性。 从实际应用的角度看，在采用面向对象技术设计信息系统时，描述需求是第一步： 然后根据需求建立系统的静态模型，以构造系统的结构：第三步是描述系统的行为，即 根据用例及静态模型进行动态建模。在前两步中所建立的模型都是静态的，包括用例图、 类图( 包含包) 、对象图、构件图和配置图等五种图。是标准建模语言u m l 的静态建模机 制。而第三步中所建立的模型或者表示执行流程，或者表示执行时的时序状态或交互关 系。它涵盖了状态图、活动图、时序图和协作图等四种图组成，是标准建模语言u m l 的 动态建模机制。 3 ) u m l 的主要特点 标准建模语言u m l 的主要特点可以归结为以下三点： ( 1 ) u m l 统一了b o o c h ，o m t 和o o s e 等方法中的基本概念。 ( 2 ) u m l 还吸取了面向对象技术领域中其他流派的长处，其中也包括非0 0 方法的影 响。u m l 符号表示考虑了各种方法的图形表示，删掉了大量易引起混乱的、多余的和极 少使用的符号，也添加了一些新符号。因此，在u m l 中汇入了面向对象领域中很多人的 思想。这些思想并不是u m l 的开发者们发明的，而是开发者们依据最优秀的0 0 方法和丰 富的计算机科学实践经验综合提炼而成的。 ( 3 ) u m l 在演变过程中还提出了一些新的概念。在u m l 标准中新加了模板、职责、扩 湖北人学硕十学位论文 展机制、线程、过程、分布式、并发、模式、合作、活动图等新概念，并清晰地区分类 型、类和实例、细化、接口和组件等概念。 2 2 2u m l 的应用领域 u m l 的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。 在此，从横向和纵向来进行应用领域的描述： 1 ) u m l 横向应用领域 u m l 最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统， 如机械系统、企业组织或业务过程，以及处理复杂数据的信息系统、具有实时要求的工 业系统或工业过程等。 2 ) u m l 纵向应用领域 u m l 适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。在需求 分析阶段，可以利用用例来捕获用户需求。分析设计阶段，用u m l 类图来描述系统静态 结构，用协作图、活动图和状态图来描述系统的动态特征，并将其设计成详细解决的方 案。u m l 模型还可作为测试阶段的依据。依据需求用例构造测试用例。经过单元测试、 集成测试、系统测试和验收测试。以验证系统测试的结果是否满足系统应用需求。 2 2 3c a s e 工具的优缺点 由于u m l 的模型主要是通过图来表达的，一个系统往往需要很多的图来从不同侧面 进行建模。如果仅靠手工，要正确和一致的处理好它们并不是简单的事。因此，出现了 一些c a s e i 具可以帮助创建和管理u m i 模型。其中，主流是r a t i o n a lr o s e ，它是一种用 来分析和设计面向对象软件系统的强大的工具。r o s e 支持u m l 的所有建模元素。同时也 支持b o o c h 和o m t 标记。使用r o s e 不但可以进行面向对象的分析、设计的正向开发过程， 还能通过源代码提取接口、类声明信息来获取源码中的模型信息，即对软件进行逆向工 程。 通过使用r o s e 建模，可以使整个开发团队达成一致。r o s e 本身可以检查模型的一致 性，而且r o s e 模型也是一种良好的文档组织方式。 然而，c a s e 工具也存在一些缺点： c a s e i 具功能虽多，但使用起来比较复杂：由于新的方法的出现而必需再训练：而且 1 4 第一二章研究涉及的关健技术基础分析 取代了系统分析者的观点、价格昂贵。因此在软件开发过程中选择何种工具必须根据具 体的项目情况而定。 2 3 敏捷建模概述 自软件工程诞生以来，一直试图通过技术和管理的手段来降低软件项目需求的不确 定性。在这个目标的指导下，专家们研究出结构化、面向对象、c 等一些新的技术和方 法，这些技术方法的确有助于“软件危机”的解决，促进了软件行业的发展：然而，由 于软件开发过程中需求不断变动，致使开发周期不断拖延，经费预算一再上扬，在规定 的时间内开发出令用户满意的合格软件越来越难。传统的软件工程方法认为只要开发人 r 1 员努力工作，就可以在早期确定所有的需求，从而减少后期需求变动引发的成本增加。， 而且传统的软件工程方法认为变动是前期工作失误造成的，因此总是尽量将需求的变动 排除在开发进程之外。 针对软件业中这种超支、超时、低质量的现状，敏捷建模( a g i l em o d e l i n g ) 的思想 日趋显现。2 0 0 1 年2 月的在美国犹他州敏捷软件开发联盟( a g il es o f t w a r ed e v e l o p m e n t a l l l a n c e ) 成立。在此之前，联盟的成员们在轻型方法的探索与实践方面做了不少有效 的工作，知名的x p ( e x t r e m ep r o g r a m m i n g ，极端编程) 方法就是众多敏捷( a g i l e ) 方法论 中的一种。其实，敏捷方法是在无过程和过于复杂的过程中达到了一种平衡，既能保持 小型软件项目开发有序不混乱又能简化中大型软件项目开发 过程，最终在规定期限内、规定费用内获取较高质量的软件产品。敏捷建模的思想 是从众多敏捷方法中提炼、总结出来的。 2 3 1 敏捷方法 通常将软件开发过程中产生大量中间制品( 如需求规约、设计模型等) 和复杂控制的 软件开发方法称为重型方法：相反，我们称中间制品较少的方法为轻型方法。 当前，统一过程可称为一种重型方法，以下将通过对轻型方法与重型方法的特点比 较和几种敏捷方法的介绍，来说明“统一过程敏捷化”的必要性并提供方法支持。 1 ) 轻型方法与重型方法的比较 湖北人学硕十学位论文 敏捷方法( a g i l em e t h o d o l o g i e s ) 汲取了多种轻型方法的“精髓”。从表层来看， 重型方法注重开发文档的完备性和一致性：而敏捷型方法则侧重于软件实现的源码，并 不是繁琐的文档。从深层中挖掘，发现有以下两方面的本质区别： ( 1 ) 敏捷方法的思想是“自适应”的而并非“预先详细计划”的。重型方法试图 预先确定需求并拟定详细开发计划来指导长期的工作，而一旦情况变化，计划就要完全 r n 更新。因此重型方法是经不起频繁的变化，甚至有时是抵制变化的，而敏捷方法则强 调包容需求的变化，由于敏捷方法采用较短的迭代周期( 一般在2 6 星期间) ，每个迭代 周期的丌发工作都会根据上一个周期用户反被做出调整，而且在迭代周期中经常进行权 衡和调整以适应新的情况。因此，敏捷方法可以被称为针对需求变动的软件开发方法。 ( 2 ) 敏捷方法侧重以“人”为中心，而并非以“过程”为中心。在实践原则中， 重型方法通常将开发者看作是一个泛化的生产要素，而忽视了作为决定性因素的人的灵 活性：相反，相对于以技术术语描述的重型方法，敏捷方法则更重视以用户语言描述的 功能，因为这样有利于同用户交流，产生更切合用户需求的软件。总之，以人为本是贯 穿敏捷实践始终的原则。 由上可知敏捷方法其实是软件工程方法论从无到重型再进一步发展的成果。下一小 节将重点介绍其中最为流行的几种方法。 2 ) 典型敏捷方法 由于敏捷方法适应需求变动的特点，在软件界，敏捷丌发方法种类也日益增多，它 们有许多的共同特征，但也存在重要的不同之处。以下介绍的是几种知名的敏捷方法。 ( 1 ) x p x p 是一种轻型方法它规定了一组核心价值和方法，裁减了大多数重量型过程的不 必要产物。建立了一个渐进型的开发过程，它依赖于每次迭代时对源码的重组。所有的 设计都是围绕着当前这次迭代，并不考虑将来的需求。这种设计过程的结果是“纪律 性”与“适配性”的高度统一，使得x p 在适配性方法中成为发展的最好的一种方法。 ( 2 ) 特征驱动开发方法( f e a t u r ed r i v e nd e v e l o p m e n t ，简称f d d ) f d d 关注的是短时的迭代阶段及特征( 即功能) 。f d d 包含五个过程：建立总体模型， 提出特征清单，针对特征逐项制订计划、设计、实现。编程开发人员分成两类：首席程 序员和“类”程序员。首席程序员负责开发实现系统的各项功能。对每一项功能，首席 程序员要定出需要哪些类来实现这项功能，并召集“类”程序员们组成一个针对这项功 能的开发组。首席程序员作为协调者，设计者和指导者，而“类”程序员则主要编写源 第一= 章研究涉及的关健技术基础分析 码。 ( 3 ) 适配性软件开发方法( a d a p t i v es o f t w a r ed e v e l o p m e n t ，简称a s d ) 该方法把一些起源于复杂适配性系统( 通常称之为混沌理论一c h a o st h e o r y ) 的思 想在软件开发中加以应用嘲a s d 的核心是3 个非线性的、重迭的开发阶段即猜测，合作 与学习。在一个适配性环境中，因为结果是不可预测的，偏离计划则是在引导开发人员 向正确的目标迈进。在管理上，其重点不在于分配团队成员的任务，而是鼓励团队成员 们交流沟通，从而使他们能自己创造性的提出解决方案。计划和设计都得随开发的推进 而改变。 ( 4 ) 水晶系列方法 水晶系列与x p 一样，都有以人为中心的理念，但在实践上有所不同。c o c k b u r n 考虑 到人们一般很难严格遵循一个纪律约束很强的过程，因此，与x p 的高度纪律性不同， c o c k b