13在开发过程中运用UML1

《13在开发过程中运用UML1》由会员分享，可在线阅读，更多相关《13在开发过程中运用UML1（43页珍藏版）》请在金锄头文库上搜索。

1、第十三章 在开发过程中运用UML 已经学习过UML的各种图，下面是该学习开发过程的时候了。UML是一个有力的工具，但是却不能孤立地使用它。它必须被用于软件开发过程。本章将介绍开发过程方法学，它是用于理解UML使用环境的工具。具体将学习： 开发过程的重要性。 为什么传统的开发方法学不适用于当今的系统开发。1 GRAPPLE开发过程。 如何在开发过程中使用UML。 如果一个组织为了在竞争中取得优势，需要新增一个计算机系统，那么必须补充新的硬件和软件。还必须进行系统开发，而且开发的越快越好。 假如你是系统开发工作的决策者。那么就要建立一个项目开发小组并使小组成员就位，这个项目开发小组包括项目经理、建

2、模设计师、系统分析员、程序员和系统工程师。 换一个角度，如果你是该系统的一个客户。那么从你的角度希望开发小组能为你提供什么工作2产品呢?项目经理如何向你做报告呢?当然，最后你还要看到正在运行的系统。但在这之前，你需要明确开发组确实已经理解你要解决的问题和你所要求的对问题的解决方案。这时你就需要能看到一个正在进展的系统，并且想知道在某一时刻的开发进度。这些是客户共同关心的，并且所有系统开发项目都应该包含对时间、金钱及前景的评估。13.1 开发过程方法学：传统的和现代的 当然客户希望开发组立刻就匆匆投入编码。但是，他们到底要对什么编码还没完全搞清楚。3开发组必须要经历一个结构化的系统的开发过程。在

3、开发过程中所经历的步骤的结构和性质就是开发过程方法学(methodology)。在进行程序设计前开发人员必须要充分理解所要解决的问题。这就需要专门有人负责需求的分析。进行了需求的分析之后，编码就可以开始了吗?不，还必须有人将分析产品转化为设计产品。然后程序员再根据设计产品编制代码，这些代码在经过测试和部署后，最终成为目标系统。13.1.1 传统的开发过程方法学 上面对开发过程中各个阶段的简单描述可能会使你觉得开发过程中的各个活动是按照时间顺序一个4接着一个顺序展开的。事实上，早期的开发方法就是采取这种方式。下图说明了一种曾经造成广泛影响的开发方法模型。它被称为“瀑布(waterfall)”模型

4、，在瀑布方法中，分析、设计、编码和部署阶段是一个接着一个按照顺序进行的。前一个阶段完成后，下一个阶段才能开始。 这种开发方式具有一些明显的缺点。首先，这种方式下的开发过程被分割开来。分析员将分析结果转交给设计人员，设计人员再把设计结果交给开发人员。采用这种工作方式的话，那么这三个组的成员在一起工作和共享重要信息的机会就很少。56 这种方法的另一个问题是它不利于在项目开发过程中对问题的逐步理解(通常，对问题的理解是随着开发过程的深入而增强的，甚至是在分析之后)。如果，过程不能回溯到早期阶段，那么在后期萌发的好的思想将不能被利用。在开发过程中塞进新的见解是非常困难的。重新进行分析和设计(同时引入对

5、问题的更进一步理解)会大大增加项目获得成功的机会。13.1.2 新的开发过程方法学 与传统的瀑布方法明显不同，当代软件工程强调开发阶段的无缝集成。例如，系统分析员和设计7人员，通常要往返进行分析和设计，为程序设计人员提供坚实的基础。程序设计人员反过来也要与分析人员和设计人员交互，共享重要的见解，修改设计，充实代码。 这种方法的优点是，随着对问题理解的深入，项目小组能够引进新的思想，建立起更完善的系统。这种方法的阻力是一些故步自封的人想要看到中间阶段达到一个清晰的结尾。有时，项目经理可能对客户说出这样的话来：“分析已经完成，我们将要进行设计，两二天后就开始编码”。 这种做法充满了危险。在开发过程

6、的各个阶段8之间设置人为的障碍会最终导致所开发的系统不是客户想要的。 传统方法还有另外一个问题：瀑布方法的追随者通常将过多的项目开发时间用于编码。其直接结果是宝贵的系统分析和设计时间被编码所侵吞。13.2 开发过程中必须做什么 在计算机程序设计的早期，分析问题，设计解决方案，编制程序代码都是由一个人完成的。现在却完全同了。为了开发各种复杂的系统，今天的企业需要群组工作方式。为什么呢?由于知识越来越9专业化，一个人不可能知道一个企业的全部方面，理解问题，设计解决方案，将解决方案转化成程序代码，在硬件上部署这些程序代码，并能确保所有的软硬件构件都能很好地协同工作。 项目小组中必须包括的成员有：系统

7、分析员，他们与客户交流，理解客户的问题；设计人员，他们设计问题的解决方案；程序设计人员，将解决方案编制成代码以及将代码部署到硬件上运行的系统工程师。一个开发过程必须要考虑到所有这些角色，合理地利用他们，为开发过程的每个阶段分配时间。开发过程还必须产生一指明过程进度以及形成职责跟踪的工作产品。10 最后，开发过程必须确保每个阶段的工作不是分离的。相反，必须在开发过程中得到反馈信息以增加在开发过程中采纳新思想的容易程度。基线：能容易地修改系统的蓝图，然后再修改系统，而不是在修改了系统再去改变系统蓝图。 一些公司认为，在开发过程中，一定要构造出一组开发阶段，每个阶段都产生大量的书面制品。因为一些商业

8、可用的开发方法学的做法就是这样的，让项目经理填写大量的表格。 产生这种情况的一个原因是源于一种方法能够适用于所有开发过程的错误思想。每个组织都是11独一无二的。一个组织有他自己的文化、标准、历史和人员。适用于跨国大公司的软件开发方法用在一个小公司时，很可能失败，反过来也一样。在开发过程中制定大量的书面制品就有助于将一个开发方法学运用于某个组织，这种观念是错误的。 因此，一个开发方法学必须要能够做到： 保证开发小组对所要解决的问题有个坚实的理解。 要考虑到开发小组是由不同角色组成。 能够在小组的不同角色成员之间培育良好的通信关系。12 考虑到跨越阶段的开发过程的反馈信息。 开发出能够向客户反映出

9、开发进度的工作产品，但是要避免产生过多的纸面制品。 应该注意的是，如果采用某种开发过程能够在一个短的时间周期内开发出一个完善的产，那么它就是一个好的开发过程。13.3 GRAPPLE 我们将介绍和使用能够适应对开发过程多方面的挑战的快速应用工程指导原则(Guidelines for Rapid APPLication Engineering，GRAPPLE)。GRAPPLE内13的思想并不是什么新颖思想。它只是吸取了许多其他方法的精髓。发明UML的三位科学家还建立了Rational统一开发过程(RUP)，在这之前，他们每个人还有自己的开发过程方法学。这些开发过程方法学的思想与GRAPPLE类似

10、。Steve McConnell的Rapid Development(Microsoft出版杜，1996)这本书，介绍了适于快速开发的很多好的做法。 GRAPPLE名字的第一个字Guidline(指导原则)是非常重要的：这说明GRAPPLE并不是写在教科书中的一个开发方法学。相反，它是一组可自适应的，灵活的开发思想。可以把它看成是开发过程的简要骨架。14我们将它作为开发背景，以说明在这个背景中如何使用UML。 经过适当的完善和补充，GRAPPLE可以适用于许多种不同组织(但也许不是全部组织)的软件开发过程。它为项目经理留有余地，以使让他们发挥自己的创造力和好的思想来适应自己的组织，减少不必要的

11、一些开发步骤。13.4 RAD3 ：GRAPPLE的结构 GRAPPLE由5个段(segment)组成，使用“段”而不是“阶段”(stage)为的是说明不是通常意义上的那种15一个阶段完成后，下一个阶段才能开始。每个段又由许多动作(action)组成。每个动作能够产生一个工作产品，并且每个动作都是一个特定的执行者(player)的职责。 在许多情况下，项目经理都可以根据工作产品生成一个要提交给客户的报告。工作产品实际上就是项目开发过程中的各种纸件。 项目经理可以在每个段中增加动作来改编GRAPPLE。另一种改编方式是深入到一个更深的层次，把每个动作进一步划分为多个子动作。还可以记录在每个段中的

12、动作。组织的需求将决定如何改编16具体的开发过程。 GRAPPLE主要适用于面向对象系统。因此每个段中的动作主要是生成面向对象的工作产品。GRAPPLE中有下列段： 1需求收集。 2分析。 3 设计。 4开发。 5部署。 这5个段组成的过程简称为RADDD或RAD3 。17在第3段以后，项目经理将所有工作产品转化为一个设计文档，将该设计文档交给客户和开发人员。当所有的RAD3段都完成后，要结合所有的工作产品来生成系统的定义文档。 在所有这些段开始之前，客户必须已经为该系统制作了一个业务案例。还要求开发组的成员特别是分析员尽可能多的阅读相关文档资料。 让我们先更仔细地考察每个段，并着眼于在每个段

13、中如何应用UML。1813.5 需求收集 如果给每个段指派一个重要性的级别的话。那么这一段是第一重要的。如果不理解客户需要什么，那么你就无法构造出正确的系统。如果你不理解客户的领域和他想让你解决的问题，那么所有的用例分析都无济于事。13.5.1 发现业务过程 开发过程的起点是获得对客户业务过程的理解，特别是获得要使用目标系统的客户的理解，这是一个好的思想。要获得这种理解，分析员应与客户19或者客户指定的具有业务知识的人面谈，与他们一起一步一步地讨论相关过程。 分析员获得了一套客户业务领域的词汇，这套客户所使用的词汇是初期的重要成果。在下一个动作中，分析员要用这些词汇与客户进一步面谈。 工作产品

14、是一个或者一组能够捕获业务过程中的步骤和判定点的活动图。13.5.2 领域分析 这个动作类似于与篮球教练交谈的那个例子。它可以与前一个动作同时进行。目标是获得尽可能深刻地理解客户的领域。注意，这个动作和前一个动作是20针对领域中的概念，不是分析要最终建立的系统。分析员必须能够在客户的世界里游刃有余，因为分析员在开发组中最终要担当客户的使者。 分析员与客户会谈的主要目标是理解客户领域中的主要实体。在分析员与客户交谈的过程中，另一个小组的成员做记录(最好是在一个装有字处理软件包的膝上型电脑上做记录)，对象建模人员构造高层类图。如果有多于一个的组员做记录，那就更好。 对象建模人员听取名词，然后开始为

15、每个名词建立一个类。最终，一些名词可能成为类中的属性。对象建模人员还要听取动词，它们可能成为类中的操作。21此时，基于计算机的自动建模工具可能会派上大用场。 工作产品是一个高层的类图和会谈记录。13.5.3 识别协作系统 当今企业中的计算机系统中不是孤立地存在于真空中。它们必须与其他系统协作。在开发过程的早期，开发组要找出新建的系统要依赖哪些老系统，哪些老系统要依赖新建的系统。这个动作备受系统工程师关注，因为他要为准备新建的系统建立部署图。图中每个节点是一个系统，节点之间的连线是系统之间的通信关系，节点中还要表示出驻留在节点中的软件构件和构件间的依赖关系。2213.5.4 发现系统需求 因为这

16、个动作名字中有“需求”两个字，因此这个动作极其重要。在这个动作中，开发组要经历第一次联合应用开发会议(Joint Application Development session，JAD session)，在整个GRAPPLE中还有好几个这种JAD session。 JAD session的参加者是来自客户所在组织的决策者、可能的用户，以及开发组的成员。还要有个协调者来缓和会议气氛。协调者的任务是引出组织决策者和用户对系统的需求。至少要有两个人做会议记录，对象建模人员应该在会议中细化他以前所建立的类图。23 会议得到的工作产品是一个包图。每个包代表了一个系统功能的高层领域(例如，“协助顾客”)。

17、每个包中包括了一组用例(例如，“获取顾客历史信息”和“与顾客交互”)。 系统的复杂性决定了会议的时间长度。一般很少短于半个工作日，有时长达一个工作周的时间。客户的组织必须要舍得在会议的时间上投资。 为什么要使用JAD session来开发系统需求呢?为什么不与每个人单独会谈呢?我们说过，当今系统开发的一个挑战是短的开发周期。单独会谈可能耗时数周或者更长的时间。因为被找的人不一定总有时间。24如果等他们有时间了再会谈，那么就白白浪费了宝贵的系统开发时间。单独会谈时可能会产生意见上的分歧，解决这些分歧又要浪费更多的时间。将所有的人召集起来开会的作用显然要超过和每个单独的人开会的作用，这样对每会议参

18、加者都有好处。13.5.5 将结果提交给客户 当开发组完成了所有需求动作，项目经理就要将这些动作的结果提交给客户。有一些组织在这个时候可能需要客户对这些结果认可，然后才能继续开发过程。其他一些组织可能要根据这些结果做成本估算。这个动作的工作产品视不同的组织而不同。2513.6 分析 在这一段里，开发组深入分析需求段获得的结果并增进对问题的理解。事实上，分析段的部分工作在需求段就已经开始，例如对象建模者在需求段JAD session时就应该开始细化类图了。13.6.1 理解系统的用法 这个动作是一个高层用例分析，在一个与可能的用户的JAD session中，开发组与用户一同工作找出发起每个用例的

19、参与者以及从这些用例中获益的参与者，这些用例是在需求段JAD session中发现的。协调者协调会议气氛，并且要有两个小组成员做26记录。在有过几个项目的经验后，协调者有可能发展成为用例分析员。 开发小组还要尝试开发出新用例。产生的工作产品是一组用例图，图中说明了用例和用例的参与者，以及带着构造型(extends和include)的用例之间的依赖关系。13.6.2 充实用例 在这个动作中，开发组继续和用户一同工作。目标是分析出每个用例中的步骤序列。这个动作的JAD session可以是前一个动作的JAD session的继续。注意：对用户来说，这个通常是最困难的27JAD session。他们

20、往往不习惯将一个操作分解成各个组成步骤并列举出所有可能的这种步骤。工作产品是对每个用例步骤的文本描述。13.6.3 细化类图 在JAD session期间，对象建模者听取所有讨论并继续细化类图。在这时，对象建模者应当在类图中加入关联名、抽象类、多重性、泛化和聚集等。工作产品是一个细化了的类图。13.6.4 分析对象状恋变化 对象建模者进一步细化模型，要展示出对象状态的变化。工作产品是一个状态图。2813.6.5 定义对象之间的交互 开发组有了一组用例图和细化了的类图后，就该定义对象之间如何交互了。对象建模者开发一组顺序图和协作图来描绘对象之间的交互。状态变化应当被包括在内。这些图形成了该动作的

21、工作产品。13.6.6 分析与协作系统的集成 系统工程师要找出与协作系统集成的具体细节，这个过程是与前面的过程同步进行的。比如何种类型的通信?何种网络体系结构?如果系统要访问数据库，那么一个数据库分析员要决定这些数据库(物理的和逻辑的)的体系结构。这个动作的工作产品是29详细的系统部署图和(如果有必要的话)数据模型。13.7 设计 在本段中，开发组使用分析段的结果来设计系统的解决方案。设计和分析都可以往返进行直到设计完成。事实上，在一些方法学中，分析和设计被做为一个阶段。13.7.1 开发和细化对象图 程序员根据类图产生一些必要的对象图。他们检查每个操作并开发对应操作的活动图去充实对象图。活动

22、图将是开发段中编码的基础。工作产品是30上述对象图和活动图。13.7.2 开发构件图 在本动作中，程序员是重要角色。这个段的任务是可视化的描绘出构件和构件之间的关系。构件图是本动作的工作产品。13.7.3制定部署计划 当构件图完成后，系统工程师就开始编制系统的部署以及系统与其他协作系统集成的计划。系统工程师要绘制系统的部署图，图中要表明每个节点中驻留了哪些构件。这个动作的工作产品是部署图。3113.7.4 设计和开发用户界面原型 这个动作要包括另一个与用户的JAD session。尽管属于设计段的一部分，这个会议也可以是早期与用户进行的JAD session的继续说明了分析和设计之间的相互作用

23、。 用户界面应当考虑到所有用例的完成。为了执行这个动作，一个GUI分析员与用户一起开发纸面上的用户界面原构件原型(按钮，检查框、下拉列表、菜单等等)，当用户对界面构件满意后，开发人员就开发显示器上的用户界面原型，拿给用户让他们认可。工作产品是屏幕界面原型的快照。3213.7.5 测试设计 用例是进行测试设计的依据。目标是评价所开发出的软件是否能够做所期望的事也就是说，它能够实现用例所描述的事情。更好的做法是再请一位开发组之外的测试专家为自动测试工具开发测试脚本。这些测试脚本构成本动作的工作产品。13.7.6 开始编制文档 系统最终用户和系统管理员使用的文档不要太早就开始编制。编制文档的专业人员

24、与开发人员一起共同编制文档，制定出每个文档的高层结构。文档的结构就是工作产品。3313.8 开发 该段是由程序员负责的。有了充分的分析和设计结果，这个段的工作就能快速平稳地进行。13.8.1 编制代码 根据掌握的类图、对象图、活动图和构件图，程序员编制实现系统的代码。这一动作的工作产品是编制出的代码。13.8.2 测试代码 测试专家(不是开发人员)运行测试脚本，评价代码是否做了预期的工作。测试结果是这个动作的34工作产品。这个动作中产生的信息要反馈到前面的动作中，反过来也是如此，直到代码通过了所有层次的测试。 13.8.3 构建用户界面和用户界面到代码的连接及测试 这个动作向着用户认可的用户界

25、面原型靠近。GUI专家构建用户界面并将界面连接到代码。要进一步的测试，确保用户界面工作正确。工作产品是带有用户界面的功能系统。13.8.4 完成文档 在开发段中，文档专家与程序员并行工作，确保35文档及时完成和交付。该动作的工作产品是文档。13.9 部署 当开发完成后，系统就要被部署到适当的硬件上运行并要与协同系统集成起来。尽管如此，这一段中的第一个动作在开发段开始以前就可以开始。13.9.1 编制备份和恢复计划 由系统工程师编制计划，以防系统崩溃。这个动作的工作产品是备份和恢复计划。计划中要详细说明如何备份系统以及系统崩溃后如何恢复。13.9.2 在硬件上安装最终系统 系统工程师在必要的开发

26、人员协助下，将最终36开发好的系统部署到合适的计算机上运行。工作产品是完全部署好的计算机系统。13.9.3 测试安装后的系统 最后，开发组还要对安装好的系统测试。它是否能执行预期的事?备份和恢复机制起作用了吗?测试的结果将决定系统是否需要进一步精化，并且测试结果组成了工作产品。13.9.4 庆祝 开发组庆祝一个新系统的诞生，这个动作的工作产品就是这个新系统。3713.10 GRAPPLE总结 如果我们回过头来看GRAPPLE中的段和动作，将会看到GRAPPLE的运动方式是从一般到具体从不精确到精确。它开始于一个对领域的概念理解，然后是系统的高层功能，接着继续深入每个用例、细化模型，最后设计、开

27、发和部署系统。 你还将注意到在分析和设计段中的动作比开发段中的动作多。也就是说，强调对系统的设计。基本思想是尽可能多地花时间在前端的分析和设计上下工夫，为的是能使编码平稳地进行。这看上去好象有点背离系统这个主题。但在实际开发中，编码38只是系统开发过程的小部分。分析的越充分，就越能接近目标。 正如前而所述，GRAPPLE只是一个开发过程的简单骨架。我们并没有涉及一些重要问题的细节，例如测试的层次。我们还省略了一些重要的细节：中间工作产品存放在哪里，如何存放?如何处理在任何时候都非常重要的配置管理问题? 我们没有讨论这些问题是因为它们与我们正在学习的UML不直接相关。下面对这些细节问题做个简单的

28、回答。工作产品(已经完成的或者正在进行中的)可以被存储在位于组织局域网中的一个数据仓库39中。一种可选择的方案是安装一个集中控制的数据仓库软件包来控制各个用户对每个工作产品项的读出和写入。这也是配置管理问题的基本解决方案。数据仓库技术至尽仍然在不断发展，当然还有别的可供选择的方案。 以后，我们将进入案例学习部分，一个应用了UML和GRAPPLE的例子。13.11 小结 开发过程方法学将一个系统开发项目的开发过程分为阶段和动作。没有开发过程方法学的指导，40开发过程就会产生混乱，开发者无法理解到底他要解决的是什么问题，因而系统也不可能满足用户的需求。早期的开发过程方法学采用严格的“瀑布”顺序，即

29、分析、设计、编码和测试。 这种顺序的开发过程方法学机械地分割了开发过程，因此一个开发组不能对项目的生命周期产生的问题增加理解。它还将主要的开发工作量分配给了编码，浪费了分析和设计阶段的宝贵时间。 这一章介绍了GRAPPLE(快速应用工程指导原则)，它是一个开发过程的骨架。GRAPPLE由5个段组成：需求收集、分析、设计、开发、部署。每个41段由又由些动作组成，每个动作都产生各自的工作产品。UML图是许多这些动作的工作产品。 传统的“瀑布”方法仍然在某些领域中可以适用。但对于现代面向对象系统开发来说，过程方法学仍然鼓励开发段之间的各个活动持续进行、相互作用，这样能产生较好的结果。42作业：1.GRAPPLE是什么意思？其中包含哪些段？2.什么是JAD session？43