快速应用工程指导原则

本打算在网络上寻找GRAPPLE的资料来打印出来，搜了半天没有找到详细的资料，于是自己把<<UML基础、案例与应用>>上的段落誊抄了下来，放在网络上共享之。

快速应用工程指导原则 (Guidelines for Rapid APPLication Engineering)

        GRAPPLE 的第一个字 Guideline( 指导原则 ) 是非常重要的：这说明 GRAPPLE 并不是写在教科书中的一个开发方法学。相反，它是一组可适应的、灵活的开发思想。可以把它看成是开发过程的简要骨架。我将它作为开发背景，以说明在这个背景中如何使用 UML 。经过适当的完善和补充， GRAPPLE 可以使用与许多种的不同组织（但也不是全部组织）的软件开发过程。它为项目经理留有余地，以便让他们发挥自己的创造力和好的思想来适应自己的组织，减少不必要的一些开发步骤。

       GRAPPLE 有 5 个段 (segment) 组成，我使用 ” 段 ” 而不是阶段为的是说明不是通常意义上的那种一个阶段完成后下一个阶段才能开始。每个段又由许多动作组成。每个动作能够产生一个工作产品，并且每个动作都是一个特定的执行者的职责。

在许多情况下 , 项目经理都可以根据工作产品生成一个要提交给客户的报告。工作产品实际上就是项目开发过程中的各种纸件。项目经理可以在每个段中增加动作来改变 GRAPPLE 。另一种改变方式是深入到一个更深的层次，把每个动作进一步划分为多个子动作。还可以对每个段中的动作重新排序。组织的需求将决定具体的开发过程如何改变具体的开发过程。

GRAPPLE 主要适用于面向对象系统。因此，每个段中的动作主要是生成面向对象的工作产品。 GRAPPLE 中有下列段：

1．          需求收集（ Requirements gathering ）

2．          分析（ analysis ）

3．          设计（ design ）

4．          开发（ development ）

5．          部署（ deployment ）

这五个段组成的过程简称为 RADDD( 或 RAD ³ ) 。在第三段以后，项目经理将所有工作产品转化为一个设计文档，将该设计文档交给客户和开发人员。当所有的 RAD ³ 段都完成后，要结合所有的工作产品来生成系统的定义文档。

在所有的这些段开始之前，客户必须已经为该系统制作了一个业务案例。还要求开发组的成员特别是分析员尽可能多地阅读相关的文档资料。

让我们先仔细地考察每个段，并着眼于在每个段中如何应用 UML.

一、需求收集

如果给每个段指派一个重要性的级别的话，那么这一段是第一重要的。如果不理解客户需要什么，那么你就无法构造出正确的系统。如果你不理解客户的领域和他想让你解决的问题，那么所有的用例分析都无济于事。

1．         发现领域过程

开发过程的起点是获得对客户业务过程的理解，特别是获得要使用目标系统的客户的理解，这是一个好的思想，要获得这种理解，分析员通常应与客户或者客户指定的具有业务知识的人面谈，与他们一起一步一步的讨论相关过程。

分析员获得了一套客户业务领域的词汇，这套客户所使用的词汇是初期的重要成果。在下一个动作中，分析员要用这些词汇与客户进一步的面谈。

这项活动的工作产品是一个或者一组能够捕捉业务过程中的步骤和判定点的活动图。

2．          领域分析

这个动作可以和前一个动作同时进行。目标是尽可能深刻地理解客户的领域。注意，这个动作和前一个动作是针对领域中的概念，不是分析要最终建立的系统。分析员必须能够在客户的世界里游刃有余，因为分析员在开发组中最终要担当客户和开发组之间的使者。

分析员与客户会谈的主要目标是理解客户领域中的主要实体。在分析员与客户交谈的过程中，另一个小组的成员做记录（最好是在一个装有字处理软件抱膝上型电脑上做记录），对象建模人员构造高层类图。如果有多于一个的组员做记录，那就更好了。

对象建模人员听取名词，然后开始为每个名字建立一个类。最终，一些名词可能成为类中的属性。对象建模人员还要听取动词，它们可能成为类中的操作。此时，基于计算机的自动建模工具可能会派上大用场。

工作产品是一个高层的类图和会谈的记录。

3．         识别协作系统

17 世纪的诗人 John Donne 写到：“没有人是孤岛，只包括他自己”。如果这句话放到今天来说，可以说是“没有不和其他人交往的人”。还可以说成是“没有哪个系统实孤岛 …. ”，等等。无论从哪个角度考虑， Donne 写的都是对的。当今企业中的计算机系统中不是孤立地存在于真空中。它们必须与其他系统写作。在开发过程的早期，开发组要找出新建的系统要依赖那些老系统，那些老系统要依赖新建的系统。这个动作备受系统工程师关注，因为他要为准备新建的系统建立部署图。图中每个节点是一个系统，节点之间的连线是系统之间的通信关系，节点中还要表示出驻留在节点中的软件构件和构件间的依赖关系。

4．         发现系统需求

你可能已经猜到，因为这个动作名字中有“需求”两个字，因此这个动作极其重要。在这个动作中，开发组要经历第一次联合应用开发会议（ Joint Application Development session,JAD session ） , 在整个 GRAPPLE 中还有好几个这种 JAD session.

JAD session 的参加者是来自客户所在组织的决策者、可能的用户、以及开发组的成员。还要有个协调者来缓和会议气氛。协调者的任务是引出组织决策者和用户对系统的需求。至少要有两个人做会议记录，对象建模人员应该在会议中细化他以前所建立的类图。

会议得到的工作产品是一个包图。每个包代表了一个系统功能的高层领域。每个包中包括了一组用例。系统的复杂性决定了会议的时间长度。一般很少短于半个工作日，有时长达一个工作周的时间。客户的组织必须要舍得在会议的时间上投资。

为什么要使用 JAD session 来开发系统需求呢？为什么不直接找每个要找的人会谈呢？也许你还记得，当今系统开发的一个挑战是短的开发周期。单独会面可能耗时数周或者更长的时间，因为被找的人不一定总有时间。如果等他们有时间了在会谈，那么就白白浪费了宝贵的系统开发时间。单独会谈时可能会产生意见上的分歧，解决这些分歧又要浪费更多的时间。将所有的人召集起来开会的作用显然要超过和每个人单独开会的作用，这样对每位会议参与者都有好处。

5．         将结果提交给客户

当开发组完成了所有需求动作，项目经理就要将这些动作的结果提交给客户。有一些组织在这个时候可能需要客户对这些结果认可，然后才能继续开发过程。其他一些组织可能要根据这些结果做成本估算。这个动作工作产品视不同的组织而不同。

二、分析

在这一段里，工作组深入研究需求段获得结果并增进对问题的理解。事实上，分析段的部分工作在需求段就已经开始，例如，对象建模人员在需求段 JAD session 时就应该开始细化类图了。

1 ．理解系统的用法

这个动作是一个高层用例分析。在一个与可能的用户的 JAD session 中，开发组与用户一同工作找出发起每个用例的参与者以及用例中获益的参与者，这些用例是在需求段 JAD session 中发现的。协调者协调会议气氛，并且要有两个小组成员做记录。在有过几个项目的经验后，协调者有可能发展成为用例分析员。

开发小组还要尝试开发出新用例。产生的工作产品是一组用例图，图中说明了用例和用例的参与者，以及带着构造型（ «extends»«includes» ）的用例之间的依赖关系。

2 ．充实用例

在这个动作中，开发组继续和用户一同工作。目标是分析出每个用例中的步骤序列。这个动作的 JAD session 可以是前一个动作的 JAD session 的继续。注意：对用户来说，这个通常是最困难的 JAD session 。他们往往不习惯将一个操作分解成各个组成步骤并举列出所有可能的这种步骤。工作产品是对每个用例步骤序列的文本描述。

3 ．细化类图

在 JAD session 期间，对象建模者听取所有讨论并继续细化类图。在这时，对象建模者应当在类图中加入关联名、抽象类、多重性、泛化和聚集。工作产品是一个细化了的类图。

4 ．分析对象状态变化

对象建模者进一步细化模型，要展示出对象状态的变化。工作产品是一个状态图。

5 ．定义对象之间的交互

开发组有了用例图和细化了的类图后，就该定义对象之间如何交互了。对象建模者开发一组顺序图和协作图来描绘对象之间的交互。状态变化应当包括在内。这些图形成了该动作的工作产品。

6 ．分析与协作系统的集成

系统工程师要找出与协作系统集成的具体细节，这个过程是与前面的过程同步进行的。何种类型的通信？何种网络体系结构？如果系统要访问数据库，那么一个数据库分析员要决定这个数据库的体系结构。这个动作的工作产品是详细的系统部署图和数据模型。

三、设计

在本段中，工作组使用分析段的结果来设计系统的解决方案。设计段和分析段都可以往返进行直到设计完成。事实上，在一些方法学中，分析和设计被当做一个阶段。

1 ．开发和细化对象图

程序员根据类图产生一些必要的对象图。他们检查每个操作并开发对应操作的活动图去充实对象图。活动图将是开发段中编码的基础。工作产品是上述对象图和活动图。

2 ．开发构件图

  在本动作中，程序员是重要角色。这个段的任务是可视化地描述出构件和构件之间的关系。构件图示本动作的工作产品。

3 ．制定部署计划

当构件图完成后，系统工程师就开始编制系统的部署以及系统与其他协作系统集成的计划。系统工程师要绘制系统的部署图，图中要表明每个节点中驻留了那些构件。这个动作的工作产品是部署图。

4 ．设计和开发用户界面原型

这个动作要包括另一个与用户的 JAD session 。尽管属于设计段的一部分，这个会议也可以是早期与用户进行的 JAD session 的继续 ---- 说明了分析和设计之间的相互作用。

用户界面应当考虑到说有用例的完成。为了执行这个动作，一个ＧＵＩ分析员与用户一起开发纸面上的用户界面原构件原型。当用户对界面构件满意后，开发人员就开发显示器上的用户界面原型，拿给用户让他们认可。工作产品是屏幕界面原型的快照。

5 ．测试设计

用例是进行测试设计的依据。目标是评价所开发出的软件是否能够做所期望的事――也就是说，它能够实现用例所描述的事情。更好的做法是再请一位开发组之外的测试专家为自动测试工具开发测试脚本。这些测试脚本构成本动作的工作产品。

6 ．开发编制文档

系统最终用户和系统管理员使用的文档不要太早开始编制。编制文档的专业人员与开发人员共同编制文档，编制出每个文档的高层结构。文档的结构就是工作产品。

四、开发

该段是由程序员负责的。有了充分的分析和设计结果，这个段的工作就能快速平稳地进行。

1 ．编制代码

根据掌握的类图，对象图，活动图和构件图，程序员编制实现系统的代码。这一动作的工作产品是编制出来的代码。

2 ．测试代码

测试专家（不是开发人员）运行测试脚本，评价代码是否做了预期的工作。测试结果是这个动作的工作产品。这个动作中产生的信息要反馈到前面的动作中，反过来也是如此，直到代码通过了所有层次的测试。

3 ．构建用户界面和用户界面到代码的连结及测试

这个动作向着用户认可的用户界面原型靠近。ＧＵＩ专家构建用户界面并将界面连接到代码。要进一步地测试，确保用户界面工作正确。工作产品是带有用户界面的功能系统。

4 ．完成文档

在开发段中，文档专家与程序员并行工作，确保文档及时完成和交付。工作产品是文档。

五、部署

当开发完成后，系统就要被部署到适当的硬件上运行并要与协同系统集成起来。尽管如此，这一段中的第一个动作在开发段开始以前就可以开始。

1 ．编制备份和恢复计划

由系统工程师编制计划，以防系统崩溃。这个动作的工作产品是备份和恢复计划，计划中要详细说明如何备份系统以及系统崩溃后如何恢复。

2 ．在硬件上安装最终系统

系统工程师在必要的开发人员协助下，将最终开发好的系统部署到合适的计算机上运行。工作产品是完全部署好的计算机系统。

3 ．测试安装后的系统

最后，开发组还要对安装好的系统测试。它是否能做预期的事？备份和恢复机制起作用了吗？测试的结果将决定系统是否需要进一步精化，并且测试结果组成了工作产品。

4 ．庆祝

开发组庆祝一个新系统的诞生，这个动作的工作产品就是这个新系统。