13在开发过程中运用UML.ppt

上述对象图和活动图。 13.7.2 开发构件图 在本动作中，程序员是重要角色。这个段的任务是可视化的描绘出构件和构件之间的关系。构件图是本动作的工作产品。 13.7.3制定部署计划 当构件图完成后，系统工程师就开始编制系统的部署以及系统与其他协作系统集成的计划。系统工程师要绘制系统的部署图，图中要表明每个节点中驻留了哪些构件。这个动作的工作产品是部署图。 * * 第十三章 在开发过程中运用UML 已经学习过UML的各种图，下面是该学习开发过程的时候了。UML是一个有力的工具，但是却不能孤立地使用它。它必须被用于软件开发过程。本章将介绍开发过程方法学，它是用于理解UML使用环境的工具。具体将学习： ● 开发过程的重要性。 ● 为什么传统的开发方法学不适用于当今的系统开发。 ● GRAPPLE开发过程。 ● 如何在开发过程中使用UML。 如果一个组织为了在竞争中取得优势，需要新增一个计算机系统，那么必须补充新的硬件和软件。还必须进行系统开发，而且开发的越快越好。 假如你是系统开发工作的决策者。那么就要建立一个项目开发小组并使小组成员就位，这个项目开发小组包括项目经理、建模设计师、系统分析员、程序员和系统工程师。 换一个角度，如果你是该系统的一个客户。那么从你的角度希望开发小组能为你提供什么工作 产品呢?项目经理如何向你做报告呢?当然，最后你还要看到正在运行的系统。但在这之前，你需要明确开发组确实已经理解你要解决的问题和你所要求的对问题的解决方案。这时你就需要能看到一个正在进展的系统，并且想知道在某一时刻的开发进度。这些是客户共同关心的，并且所有系统开发项目都应该包含对时间、金钱及前景的评估。 13.1 开发过程方法学：传统的和现代的 当然客户希望开发组立刻就匆匆投入编码。但是，他们到底要对什么编码还没完全搞清楚。 开发组必须要经历一个结构化的系统的开发过程。在开发过程中所经历的步骤的结构和性质就是开发过程方法学(methodology)。在进行程序设计前开发人员必须要充分理解所要解决的问题。这就需要专门有人负责需求的分析。进行了需求的分析之后，编码就可以开始了吗?不，还必须有人将分析产品转化为设计产品。然后程序员再根据设计产品编制代码，这些代码在经过测试和部署后，最终成为目标系统。 13.1.1 传统的开发过程方法学 上面对开发过程中各个阶段的简单描述可能会使你觉得开发过程中的各个活动是按照时间顺序一个 接着一个顺序展开的。事实上，早期的开发方法就是采取这种方式。下图说明了一种曾经造成广泛影响的开发方法模型。它被称为“瀑布(waterfall)”模型，在瀑布方法中，分析、设计、编码和部署阶段是一个接着一个按照顺序进行的。前一个阶段完成后，下一个阶段才能开始。 这种开发方式具有一些明显的缺点。首先，这种方式下的开发过程被分割开来。分析员将分析结果转交给设计人员，设计人员再把设计结果交给开发人员。采用这种工作方式的话，那么这三个组的成员在一起工作和共享重要信息的机会就很少。 这种方法的另一个问题是它不利于在项目开发过程中对问题的逐步理解(通常，对问题的理解是随着开发过程的深入而增强的，甚至是在分析之后)。如果，过程不能回溯到早期阶段，那么在后期萌发的好的思想将不能被利用。在开发过程中塞进新的见解是非常困难的。重新进行分析和设计(同时引入对问题的更进一步理解)会大大增加项目获得成功的机会。 13.1.2 新的开发过程方法学 与传统的瀑布方法明显不同，当代软件工程强调开发阶段的无缝集成。例如，系统分析员和设计 人员，通常要往返进行分析和设计，为程序设计人员提供坚实的基础。程序设计人员反过来也要与分析人员和设计人员交互，共享重要的见解，修改设计，充实代码。 这种方法的优点是，随着对问题理解的深入，项目小组能够引进新的思想，建立起更完善的系统。这种方法的阻力是一些故步自封的人想要看到中间阶段达到一个清晰的结尾。有时，项目经理可能对客户说出这样的话来：“分析已经完成，我们将要进行设计，两二天后就开始编码”。 这种做法充满了危险。在开发过程的各个阶段 之间设置人为的障碍会最终导致所开发的系统不是客户想要的。 传统方法还有另外一个问题：瀑布方法的追随者通常将过多的项目开发时间用于编码。其直接结果是宝贵的系统分析和设计时间被编码所侵吞。 13.2 开发过程中必须做什么 在计算机程序设计的早期，分析问题，设计解决方案，编制程序代码都是