应用Rational 工具简化基于J2EE的项目(一) |
第一部分 介绍 Steven Franklin 软件设计师和过程专家 2004 年 3 月 这个由多篇文章组成的系列文章讲述了如何在很紧的时间和预算的情况下通过应用 Rational 统一过程(RUP)以及 Rational 的其他工具来开发一个软件项目的。 文章的第一部分包含了高层次的计划和需求的引出。 Raional 的开发工具套件支持双向工程(RTE)、分布式的和协作的开发、高度迭代的开发周期和更多的一些特性。 这个由多篇文章组成的系列的第一部分将向大家展示 Rational 工具的作用,并显示你能够通过使用 Rational 的工具来简化分布式的 J2EE(Java 2 Platform, Enterprise Edition) 项目。我们将看一个将单的虚构的项目,并以高层次的计划和需求的引出作为开发,并将过渡到 Rational 统一过程(RUP)的各个阶段。 本文假设你已经对 RUP 有一定的了解;如果你并不了解 RUP 你可以查看文章最后列出的 相关资源. 为了简单起见,我们不想完成 RUP 中所有必要的迭代,而是只显示在项目各个阶段被用到的工具的特性。我们将跟随着我们的小的样例项目,完成它的第一个主要的构建,如下: 了解 RUP 的概念 和 Rational 工具的使用,应用它们来应对远程开发、很紧的时间计划和受限的预算的挑战 使用Rational 技术实现端对端的可以跟踪性和需求的管理 在 J2EE 项目中集成 Rational 工具,完成自动化测试、双向工程、地理分布的代码检查和质量保证(QA) Rational 技术与 J2EE 工具的集成,对于最终的解决方案尤其是应用 J2EE、象 DB2 或者 Oracle 这样的关系数据库和 Java 集成开发环境 这个系列文章的每一篇都有相似的组织形式 ,每篇文章都以一个路标开始,就像下面的一样,每一个链接会连到相应的文章部分。 第 1 部分: 项目介绍;高层次计划 第 2 部分: 风险管理;需求管理 第 3 部分: 模型创建和访问控制;需求分析 第 4 部分: 用例细化;产成报告;工具和技术选择 第 5 部分: 体系架构和设计 第 6 部分: 详细设计;早期开发;双向工程;早期单元测试 第 7 部分: 继续开发;早期的构建;演示 第 8 部分: 单元测试策略;功能测试;GUI 测试脚本 第 9 部分: 系统构建和测试;缺陷跟踪;产品交付 第 10 部分: 项目完成;结论;未来的工作 第一部分快照 第一部分中的工具和技术: Rational 统一过程 (RUP) — 用于项目高层次计划 被产生或者被更新的工作产物: 干特图 — 被创建以用于项目管理的目的,作为时间进度和项目预算执行的基线被衡量。 样例项目介绍 这篇文章中的虚拟假设是我们是一家软件公司,名字为 Lookoff Technologies Incorporated,我们的公司主要的业务是在 IT 系统,包括集成、支持和开发。我们的总部在多伦多,并且在遍布加拿大有一些小的办事处。因为我们的分析和开发团队距离我们大量的跨国客户非常近,这个公司的结构就允许我们以一种非常好的方式集中我们的专家(典型的后端开发和项目管理)。 我们假设另外一个虚拟的公司,Audiophile Speaker Design, Inc. (ASDI),这个公司位于 New Brunswick 的附近。 ASDI 开始只是一家从事扬声器制造和设计的小公司,主要开发针对个人用户的一些定制的扬声器方案。随着 ASDI 公司的声望的增加,他们开发出更多主流的扬声器产品线,并向加拿大和北美国家的用户和电子商店供应产品。 ASDI 的技术设施不能满足他们的成长需要。他们已经难以管理定单,计划生产材料,跟踪部分需求和管理运输。更主要的是,ASDI 的客户抱怨他们缺乏浏览可用性和交付过程的能力。 ASDI 公司意识到了从纸张和电子表格到自动化的资产管理系统的转变是伴随风险的,ASDI 决定将他们的所有 IT 需求交给 Lookoff 一家来作。他们选择我们的主要原因是我们的良好声誉和距离他们的公司很近(便于支持)。 Note that although the sample project is fictional, it's based on my personal experiences, observation of other projects, and knowledge I've acquired through excellent books such as those listed under 注意:虽然样例项目是虚构的,但是它是基于我的个人经验、对其他项目的观察和我通过一些优秀的书籍(例如被列在文章结尾的相关资源)获取的知识。 引出高层次需求 象许多小的非 IT 公司一样,ASDI 意识到了他们的问题,但是他们并不十分清楚他们的需求究竟是什么样子。他们的原有工作状态仅仅有两页纸长,并且是契约的、功能的和编程的需求的混合。我们和他们坐下来讨论他们的每个需求点;这里最大兴趣的是契约的和编程的问题,讨论如下: 契约问题 客户(ASDI) 希望我们签署一份公司固定价格(FFP)合同,合同价值一百一十万加元(CDN),按照合同规定软件系统应在10个月之内交付。对于我们来说没有一个清楚的需求远景,签署这个合同是不可能的。这将给我们带来过多的风险,并且也许对客户来说是不公平的,并且我们能够确定他们的技术需求将被满足吗。我们开始了第一个会议,目的是讨论迭代和和增量的软件开发优于顺序(“瀑布”)开发的力量。 我们对客户强调的 RUP 的关键特性包括: 迭代工程,减少风险和聚合正确的方案 尽最大可能使用已有的工具、技术和已开发好的产品,以减少成本增强质量。 管理和控制变更 给客户对将产成产品的了解 创建高质量的产品 客户还是很关心软件交付的期限的缺乏。通过一些讨论,我们成功的显示了客户从项目的开始到结束都应该对项目的进展有足够的了解。他们也想项目的预算可以分阶段支付,并且要求我们在执行项目时履行一些义务。因此项目计划被划分为两给阶段: 阶段 1 — 创建系统的“概念校对”版本。客户将按照工时支付我们的费用,但是在第一阶段的预选之内。 阶段 2 — 创建系统的产品版本,按照 FFP 支付费用。 对于阶段1,客户要求250K CDN 的上限,我们觉得这个预算对于我们创建第一个原型系统的演示版本是很充裕的。我们创建了如图 1 的干特图,我们在四个月是标记这个点应该产生演示版本,并且与客户一起审阅以确保至少与第一阶段的时间表粗略的保持同步。(之后我们与他们更加紧密的一起检查了这个时间进度表) 图 1: 阶段 1 干特图 图一中的图是用 Microsoft Visio 创建的,但是你可以很容易的使用 Microsoft Project 或者 一些类似的软件工具来计划你的项目。这个图表对我们的主要目的是对时间进对和里程碑达成一致,并且建立工作分解结构(WBS)的层次图,工作分解结构中的每一项我们都可以跟踪、估计和执行。 编程问题 ASDI 是一家通过了 ISO 认证的公司,并且他们非常信仰厚重的文档、连续的里程碑和广泛的质量控制。他们不是一家非常技术型的公司,他们在过程上有自己的想法。我们在与他们合作的作大挑战之一就是找到一个过程和可是使他们满意的可交付工作产物的集合,同时又不会使我们的团队感到多工作有防碍。他们进行了几次会议,并很强调要有大量的彻底详尽的文档。而且,他们的里程碑是有顺序性的,而且他们的思想是每一个任务必须在下一个任务开始前结束。 他们对过程的理解使我们在最可能的方法中应用 RUP 制造了更大的挑战。 虽然 ASDI 同意了我们使用迭代和增量的开发(基于 RUP)方法,但是他们对这种方法似乎不感兴趣。他们希望得到下面的东西: 固定的里程碑: 系统需求检查(SRR),初步设计检查(PDR),和关键设计检查(CDR) 两个软件的演示版本 工厂接受测试(FATs) 和 客户接受测试(CATs) 我们简单的将这些里程碑插到了我们的过程当中(如图 1 所示). 一个正式的需求文档、一个设计说明书和接受测试文档。这些对于基于 RUP 方法的面向对象的符号是全新的,ASDI 在工作中并不是十分的关心他们中的所有,但是 ASDI 还是同意将他们的交付工作产物的描述保持足够的高级别,以便我们可以使 RUP 的工作产物满足 ASDI 所期望的工作产物。我们觉得可以使用 Rational 的工具来生成如何需要的文档,不会对我们的过程造成很大的阻碍,并且可以成功的将信息传达给客户。具体的说是 Rational SoDA能够使我们更加容易的从模型中生成文档。 ASDI 也计划雇用一个 IT 经理与我们联络,同时也负责维护和管理完成的项目。我们需要 ASDI 的这样一个角色的人加入到项目中,这个人对于项目来说应该是一个技术上的权威。不幸的是, 这个 IT 经理(对公司来说是新兴的事物)缺乏客户运作的知识,就像我们的团队中的一样。 总结 在最开始与客户的一系列的会议中,我们取得了一些非常好的进展。ASDI 的对于交付产物和时间进对期望是有些灵活性的,并且允许我们使用基于 RUP 的方法进行开发。我们对项目达成了一个大致的时间进度结构,并且与客户建立了良好的关系。通过与客户的讨论,我们识别除了一些风险,之后这些风险被我们用来划分任务的优先级和项目管理。 计划未来 我们应该进行的最高优先级的事情之一的是与客户一起从客户的工作现状(SOW)开始建立项目的远景。我们已经获得了客户需求的大概的理解,但是我们还需要分析出需要我们作的具体的工作。 我们也必须细化我们的时间进度表,并尽快的开始我们探测好的起步阶段。在阶段1期间,要确保一个方案是有成本效益的和满足客户需求的,我们就必须找出如何能够满足客户需求。客户已经提到过,在决定是否将项目进行到第2阶段的主要因素是最终系统的维护和系统架构软件/硬件的成本。 总而言之,我们在前几周应该做的事情包括: 为项目详细描述的客户工作现状(SOW),并且在 Rational RequisitePro 中输入项目需求。 为阶段1细化时间进度表 在成功的进行了设计的检查后,创建项目计划以显示如何计划过渡到第2阶段。 制定详细的执行计划以减轻被识别出的风险 主要风险 项目进行的开始几周对于建立有效的客户关系和使项目保持在正确适当的技术方向上是非常关键的。我们没有太多的时间来寻找需要的技术并将这些技术集成到我们的团队中,因为客户期望的项目进度是非常快的。 我们认为我们必须建立一个问题的数据库,我们能够以一种集中查找数据库的方式提出行动条目、问题和风险。通过将这些信息发布到网上,这样就可以使不论是集中办公还是远程的开发团队都可以监视项目信息。如果有必要的话甚至远距离的工作者都可以跟踪和更新项目的风险。
|
应用Rational 工具简化基于J2EE的项目 (三)转换到系统模型 |
============================================================================= |
第 3 部分 :转换到系统模型 Steven Franklin 软件设计师和过程专家 2004 年 3 月 本文将继续通过这个全面的应用 RUP 和 其他 Rational 工具的样例项目来介绍创建项目的 Rational Rose 模型,本文中我们将开始创建代表“目前”业务情况的系统模型,并将此业务模型转换成为“将来”的系统模型。 这个第 3 部分文章重点的介绍了在 Rational Rose 中完成的早期建模活动。首先我们来对 ASDI 现有的(“as is”)系统进行建模,通过业务用例和业务对象可以显示当前事情是如何工作的。我们将从这个反映现有系统的模型创建出符合 ASDI 新的需求的系统模型,并且将这个系统模型作为建立软件的基础。 伴随着这本文有 2 个演讲稿 (来自于 Rational 用户大会 2000) 这里讨论了以下主题: Yves Holvoet 的 “维护分析模型与多个设计模型的同步” 和 Robert Bretall 的 “结构化你的 Rational Rose 模型”。后一个演讲稿附带一个 Rose 模型。 第 3 部分快照 第 3 部分所使用的工具和技术: Rational 统一过程 (RUP) — 指导软件开发过程,对项目的每个阶段提供建议的过程和工作产物 Rational Rose 企业版 — 为了创建“目前的”业务模型(使用统一建模语言(UML))并在分析线索的基础上开始创建“将来的”系统模型 被创建的或者被更新的工作产物: 业务用例模型(Rational Rose) — 被创建用来代表系统“目前的”业务功能 业务对象模型 (Rational Rose) — 被创建用来捕获系统“目前的”业务功能是如何被执行的:实体之间的协作、实体之间的交互和相关的过程和产物 用例模型(Rational Rose) — 不能完全的表示业务用例模型;被创建用来获取详细的系统“将来的”执行功能(它作为构建软件的基础) 捕获“目前的”系统 有太多新的和被改进了的 IT 系统在已有系统被了解之前被启动。甚至是当已有系统还缺乏 IT 组件的时候,有必要在可选的和改进的方案被建议之前对当前的业务活动情况进行分析。然而人们总是跳过或者草草的完成这一步,但是这做会导致以下的问题: 对客户的需求的理解不够充分,减慢接下来的分析 对需求的不正确的解释 不能准确的估计新方案所带来的影响,导致当软件被交付给客户使用时对客户的工作产生巨大的震动和要求客户完全改变现有的工作流程 不一致的术语和概念,导致与客户之间产生交流上的误解和混乱 创建一个业务模型以捕获“目前的”系统的情况可以是非常快速的任务并能够产生有用的分析线索,这些线索将简化对“将来的”系统的定义。在创建这个模型中能够对我们有帮助的一件事情是工作状态(SOW)。虽然 SOW 主要用来描述“将来的”系统的需求,但是它也提供了ASDI 的当前业务流程的有用的背景信息。 在 Rational 统一过程(RUP)初始阶段部分存在一系列的用于业务建模的方法(也是就在我们项目的第 1 阶段)。与 ASDI 一起创建一个 IT 系统,我们需要一个“目前的”模型以捕获文件的流转和他们的当前系统的交互活动。我们在 Rational Rose 中创建了下列 RUP 工作产物作为业务建模工作的部分: 业务用例模型, 建模“目前的”业务功能。 业务对象模型 (有时也称作 领域模型), 对执行业务功能的对象和这些对象之间的关系进行建模。一个业务对象模型可能会显示一个发票是如何被生成并如何在系统中进行流转,或者显示了一个购买请求的开始到结束的过程。 注意在以前的一些项目中,我们跳过了业务建模的步骤,因为我们是建立一个全新的系统,或者是因为我们已经非常好的了解了已有的业务模型。但是因为我们对 ASDI 的业务是陌生的,因此我们觉得这一步是十分重要的。 我们也考虑到开发一个业务术语表(使用 RUP 提供的工作产物模板),但是我们发现我们的术语中的大多数是相当标准和明确的,而且这些术语在我们的业务对象模型中被充分的捕获了。更加复杂或者严格的项目将会从创建业务术语表中获益以确保在所有产物中的一致性。 当我们使用 Rational Rose 创建我们的模型时,我们感到仅仅简单的创建图是不够的。我们发现仅仅通过图的方式表达模型对图的创建者是容易理解的,但对图的阅读者来说却是很难读懂的,因此我们为每一个图附加了文档(通过在图上点击并在文档窗口输入文本)。我们也为图中的每一项提供了文档 — 用例、业务对象、用户或者其他项 — 用一到两行的文字来描述每一项的目的。 创建模型 我们从一个开始点来创建我们的新模型文件(ASDI.mdl),我们使用符合 RUP 中定义的结构的 Rose 模板(见图 1)。因为我们在 RUP 中完成大量的工作,这将使我们工作的很好。RUP 的模型模板是可以在启动 Rose 时看到的,我们可以通过向导来访问的几个模板之一,或者你也可以在 Rose 应用程序的 Frameworks 目录中找到他们。 图 1: RUP 模型模板 我们对模板的结构做了一些改动以符合我们的需要和选择。例如,我们直接做了一下的修改: 代替跟踪被包括的与其他用例分离的用例,我们将这些用例组织到逻辑上包含他们的功能的包中。我们觉得可以将 <> 原型和 Rational SODA 的报告能力结合起来,这样当有必要时可以允许我们容易的识别被包含的用例。 我们删除了在逻辑视图(Logical View)下的分析模型。你可以阅读 Yves Holvoet 的演讲稿来了解分析框架重用和分析/设计用例的正反观点的讨论。我们决定一个分层的分析模型是没有必要的,因为我们并不期望 ADSI 系统中的多数业务模型可以在将来的项目中被重用。相反,我们允许用例在整个项目的过程中得到进化。 我们首先通过业务组件对设计模型进行了划分,然后再对他们进行层次的划分(这两个任务通常是不同的),而不是一开始就对模型进行层次划分。 接下来我们必须添加一个计划(schema)区域到模型中以使数据库架构师可以跟踪数据建模的工作。 管理模型 将 Rose 模型按照不同团队成员的责任分摊到包中通常是需要花费一定的功夫的。包的结构应该被创建的使在团队成员之间共享职责相对的简单一些,这可以通过划分系统成为不同的部分来实现:分析(比如,贯穿用例和业务对象),体系架构和设计。 我们的团队虽然不是很大,但我们还是要考虑到在模型之上的协作问题。我有几个 Rational Rose 的浮动的许可证,这足够我们所有的人同时访问模型,但是我们也需要使我们能够并发的访问模型的某一部分。因此我们使用 Rose 的 “单元控制” 的特性以对模型进行适当的分解。 在我们的团队的组织结构中的角色(如在第 2 部分被描述的)这些角色所拥有的对模型各部分的输入和更新的指责被显示在表 1 中。因此,团队中的其他成员,比如初级的开发人员和项目工程师将只拥有对模型进行访问的权限以完成他们的开发工作。 角色 输入/更新职责 组长/高级分析人员 打包管理 用例模型(业务和系统) 业务对象模型 体系架构 设计 高级开发人员 体系架构 设计 数据库架构师 体系架构 计划(Schema)设计 表 1: 模型输入/更新职责 我们对模型进行了分解,如图 2 中显示的 Rose 图。此时这个模型的结构服务于我们需要,因为我们有 3 个人直接的维护这个模型。将来,当团队和项目逐渐扩大时,这个模型结构可以被容易的分解为更多的 *.cat 文件。 图 2: 模型分解 关于分解 Rose 模型的额外信息可以在 Robert Bretall 的演讲稿中找到。这里只指出来自于它的模型结构讨论中的几个有价值的事情: 最好不要将内容放在模型的顶层。(在我们的案例中,所有的信息都被放到了被控制的 *.cat 文件中。) 如果你计划在将来的项目中重用你的系统模型的某些部分,考虑对分析模型进行分层。(你也可以在 Yves Holvoet 演讲稿中找到更多相关的信息。 ) 如果模型的结构是根据 RUP 的指导创建的,Rational 的工具(SoDA ,REI 脚本等)将更加有效的与模型进行交互。 使用 Rational Rose 分解模型成为分离的 *.cat 文件是很容易的。如图 3 所示,我们简单的右键点击我们想在单独的文件中控制的包;然后在上下文菜单中选择 Units > Control Use-Case Model ,这使我们可以控制这个包和这个包中的所有子子项。稍后在项目中,我们将重组一些 *.cat 文件成为几个更小的被控制的包以进一步的发布建模的工作产物。 图 3: 在 Rose 中创建分离的 *.cat 文件 建模用户和接口 一个角色(actor)是与系统交互的外界的人或者事物;这既可以是使用系统的人,也可以是其他的接口类型。建模系统的用户和接口以及他们之间的依赖是非常有用的;它不仅仅可以给你一个系统的完整实体,而且也可以提供给你对于将来的安全性和角色建模工作的良好信息。 图 4 显示了我们如何在 Rose 中将角色容入我们的业务模型当中 — 尤其是,在一个与客户服务相关的用例图中,这个用例图摘自我们的业务用例模型。两个特殊的原型类被使用:业务角色和业务用例。 Rose 可以基于原型分配自定义的图标,并且我们选择这个方法为用例和角色分配外表略有不同的图标 — 加了一条斜线 — 因为我们觉得区别用于构建软件的系统模型与业务模型是重要的。 图 4: 客户服务的用例模型摘录 当我们将业务用例模型充实起来时,对于业务对象模型来说将会出现一系列好的候选对象。虽然创建一个“目前的”系统的业务模型看起来要花费大量的工作(主要的工作量是生成图),但是我们觉得它是值得的。在我们过去的“目前的”模型中,已经包含了大量的在实验室工作簿中的注释和正式的技术注释。为了得到已有业务流程的更加清晰和完整的视图,应该在花费一些时间在 Rose 中捕获这个信息。 理解系统交互 有时人们会将重点都放到了系统的某个单独的部分上,但实际上系统各部分之间的交互也是非常重要的。充分的考虑整个系统部分的交互将使系统各部分之间集成的共性和可能性更加明显。这是为什么我们后来使用交互图的原因之一(显示系统各部分间的交互)以验证我们的设计;这对在分析和设计中识别流程和固有的缺口是非常关键的。 在项目的早期我们关注的交互: 业务用例对角色(什么样的个体和接口访问到我们识别出来的各种业务任务) 业务对象对业务对象(各个业务对象之间是如何彼此交互的,和他们共享信息的种类) 用例对用例(任务彼此之间的依赖,和被一定的过程共享的公用任务) 我们花费了一些时间在 Rose 中捕获我们对当前业务组织和过程的理解,结果是生成了对于我们理解现有系统非常有用的业务对象模型。在对象模型中的图(在图 5 中显示的是其中的一个)类似于标准的类图、除了他们使用了特殊的原型类:业务实体、业务控制和业务角色。业务实体表示被动的领域对象比如发票或者报告,而业务控制是执行功能的对象,可以表示报警或者机械的作用。(业务角色在之前已经被讨论了。) 图 5: 业务对象模型摘录 我们在业务用例建模之后很快开始业务对象建模。业务用例的说明文字确定了一系列合适的业务对象。如果是跨越多个用例的对象,比如“购买请求”和“产品”、“产品队列”和“运输队列”是被识别的业务领域的关键对象。有时如果我们意识到它是不合适的或者已经被其他对象覆盖到了,我们将删除这个业务对象。通过这种方法,可以快速的在任务(用例)和 事物(业务对象)中筛选与 ASDI 业务相关的业务对象。 在某些情况下,业务对象模型将演化成系统类。这对于实体对象来说基本上是正确的,实体对象通常被映射为容器类或者是数据库表。在其他一些情况下,业务对象模型简单的作为一个为理解客户领域的引用的结合点来使用。我们确认客户已经完全理解了图形化的符号和每个图的内容,因为他们的检查和批准是关键的。 总而言之,我们花费了大量的时间在业务建模的工作上。这并不一定是一流的或者是完全的,但是对于我们来说应该是能够对当前的业务流程有一个足够的认识。在项目的第一个或者两个月后,我们将很少的提及业务模型,但是我们觉得它是值得花费时间的,因为它是形成“未来的”系统的系统模型的一个必要的步骤。当一个新成员加入到我们的团队时,我们可以通过浏览业务模型来帮助他们来理解新的领域;然而,一旦对它熟悉了,业务模型将很少再被查看,除非是阐明术语。 将 SOW 转换成用例 计划“将来的”系统,我们需要将已经用文字形式表示的 SOW 需求(在 第 2 部分中被讨论的)转换成为经过深思熟虑的用例。换句话说,通过对“目前的”系统的业务用例的创建(就像早些时候所讨论的),我们准备为“将来的”系统细化这些用例。这将不是一个快速的步骤,但是它经历超过两周的时间。(在 RUP 的术语中,这个转换反映了一个从初始阶段到细化阶段的逐步转化过程。)我们在业务建模上所作的工作,获得了当前系统的经验并将它的功能划分进了业务用例,这对我非常有帮助。( RUP 的文档显示了从业务用例模型到业务对象模型和系统用例模型的演进;我们发现这是非常正确和有帮助的。) 我们并不担心映射 SOW 需求到“目前的”系统业务用例的原因是 SOW 需求中的许多在当前的系统中是不存在的。我们早期所创建的业务模型只不过是一个临时的产物,它用于我们确保我们的团队理解 ASDI 的当前系统。 用例对文字说明 一系列的工作簿和工作产物(包括那些后面被列的“引用和其他资源”)解释了用例建模和理解需求的好处。我们发现许多被提及的好处是真实的,虽然定义用例的内容不是琐碎的任务。与良好的文字说明相比,如果用例没有被良好的设计,对于你来说他们当然没有用的。 这里是一些开始创建用例时的误解: 用例被创建的太大或者太小 用例在跨越团队的情况下不一致 没有对用例分组的包进行良好的计划 不合理的对模型的访问进行控制,导致在团队分析协作的过程中发生冲突 过于细致的定义用例,在用例进入原型、设计和开发任务之前就定义每一件事情 定义用例时过于简单,使需求被工程团队可以有众多的解释 结果,我们决定用例建模标准和指南需要被组长定义。这些包括下面的指南: 用例典型的获取 10 到 20 天的开发和单元测试。这不是 RUP 的规则,但是对于我们来说这是一个好的规则。如果我们发现用例比这个标准过大或者过小,我们将花费额外的时间检查他们以保证他们有合适的范围。 工程团队必须在早期对包的结构达成一致。这个结构可能会变化,但是变化应该首先与团队进行讨论。 当决定什么应该包括在我们的用例中时,我们应该遵从在文章中指出的指南Fine Tuning Rose to Complement Your Process: 标识 — 名称、唯一的 ID、 原型、可跟踪需求和简介 描述 — 开始状态、结束状态主流程描述和变更 注释 — 临时的“便签簿”注释 从“目前的”到“将来的”演进 当我们从“目前的”转移到“将来的”时,我们的许多业务角色被演化成了系统中真实的用户和接口,虽然有意义的重构是必要的。这是自然的,因为当重新定义其他角色时新的 IT 方案统一了原有的一些角色。一些业务实体作为抽象的概念消失了,而其他的一些通过计划(schema)或者详细的设计被映射成了类。 在图 6 到 图 9 中显示了我们早期工作产生的对于“将来的”系统的用例模型的一部分。通过图形、协作图和时序图以及进一步的详细分析的帮助,它将随着时间推移而成熟。 图 6: 早期的角色模型 图 7: 核心的客户服务用例 图 8: 客户定单用例 图 9: 系统管理用例 像 RUP 的描述,“用例建模的最重要的目的是与客户或者最终用户沟通系统的行为。”然而,增加复杂性可以导致我们的客户也许感觉不舒服的风险,我们发现当我们充实用例时,在用例中引入更高级的包含和扩展关系是很有价值的。在详细的检查我们的用例模型时,被包含和扩展的用例频繁的出现。我们发现甚至在我们理解了系统的(包括用户)外界接口视图,通过包含和扩展用例来分组功能产生在重要的计划、架构和测试中的好处。然而,在我们看到客户对检查这些高级的关系没有信心时,我们有时会将被包括和扩展的用例从检查的包中拿掉。 总结 我们现在已经有了一个描述了 ASDI 业务中已有过程和实体的画面,并且在对将被构建系统的任务和角色的系统建模上有一个良好的开始。虽然还有一些在团队内的关于跳过业务建模工作的讨论,但是我们觉得我们的工作将收到回报。其他的好处是,它使客户容易的以一种舒服的和相对非技术的级别进入用例。 不同项目之间的用例建模有着显著的不同;用例的定义、用例的关系、详细的程度等等都是经常被争论的。最后我们发现当我们向客户展示我们的用例模型时,一致的并频繁的检查是成功的关键。 计划未来 我们需要得到技术上的强劲进展。客户正向我们索取比我们现在可以提供的更多的有关用户界面、代码原型和工具选择的信息。我们必须开始提供屏幕的模拟并开始考虑适当技术的选择;现在重要的是开始使用更加实际的、技术的产物和购买工具(尤其是如果我们需要更多的培训)。 虽然我们还没有开始进入体系架构阶段,但是我们知道系统必须是基于 Web 的并且是跨平台的,同时从原型到企业级方案都要是可扩展的。我们已经学习了 J2EE ,并且 ASDI 雇用的 IT 经理也首选这个技术平台。因此,我们觉得开始探索 J2EE 的成本和能力是明智的。我们的团队在这个领域不需要太多的培训,这是另外一个因素。数据的存储应该被更多的考虑,然而,因为 IT 经理极力的推崇面向对象的数据库(OODB)方案。因为我们对关系型数据库更加在行,这对我们来说是一个艰难的路程,但是我们还是同意了考察 OODB 的方案。 我们非正式的与我们的客户审查了我们的所有工作产物,但是是时候进行正式的检查了。在接下来的几周中,我们将建立我们的 Rational SoDA 模板以便我们提供我们的第一个正式的交付:详细的软件需求。我们同意这个文档应该包括用例和非功能需求(可靠性、可用性等等)。 我们的用例开始稳定了,开始指明在对 SOW 合适的可跟踪的地点。我们需要用 Rational RequisitePro 来确保维护 SOW 与我们的用例之间的映射。 我们接下来的方向,应该是: 技术上的进展,尤其是工具和技术的选择 建立必要的 Rational SoDA 模板以生成我们的第一个正式的文档 精练我们的用例以添加可跟踪性到 SOW 主要风险 我们仍然觉得时间是非常紧的,并且存在着时间进度或者预算的一些出入 — 并且我们的风险列表还在增长,甚至我们还没有开始任何的认真的技术探索。其中有以下新的风险: 过多的涉众竞争,有时在系统的功能上会有矛度的意见。我们需要与客户澄清觉得的过程。 假如我们选择 OODB 方案,我们必须扩展我们的深度,因此这会产生强迫的培训和对工程团队的时间进度产生不确定性。 客户心急的要求第一阶段的重要的正式的和详细的工作产物,而我们设想的是这只是个概念性的证实。我们仍然与客户针对 RUP 进行沟通,并尽力在 RUP 中的工作产物和符号中增加他们舒服感受。 |
应用Rational工具简化基于J2EE项目(四)分析和工具的进展 |
=============================================================================== |
第 4 部分 :分析和工具的进展 Steven Franklin 软件设计师和过程专家 2004 年 4 月 在这个展示了 RUP 和其他 Rational 工具使用的样例项目的接下来的阶段,用例通过添加文档和可跟踪性到需求被细化,并且使用的工具和技术被评估和选择。 这个第 4 部分文章的重点在于 ASDI 项目的细化阶段,尤其是在用例分析方面(细化我们的用例以对工作状态(SOW)添加可跟踪性,并且标准化和生成用例文档)并选择合适的工具和技术。 第 4 部分快照 在第 4 部分演示的工具和技术: Rational Rose 企业版 — 用于用例细化 Rational SoDA — 为客户检查的低成本的产生用例文档的工具 Rational RequisitePro — 用于管理 SOW 需求和用例之间的可跟踪性 产生或者被更新的产物: Rational Rose 模型 — 被修改并在用例的各个方面添加了更加详细的内容 用例报告 — 用 Rational SoDA 从 Rose 用例中生成 RequisitePro 数据库 — 被更新以包括SOW 需求和用例之间的可跟踪性 细化并文档化用例 图 1 显示了在 ASDI 项目的第 1 阶段(RUP 的初始和细化阶段)中的用例的演化。就像我们在第 3 部分讨论的,我们在初始阶段创建了业务用例,然后在细化阶段的初期将业务用例转换成体现了“目前的”系统的用例。现在我们是在细化阶段的最激烈的时刻,我们正准备细化我们的用例,为系统完成向详细需求的转换。这个演进是自然形成的,因为直到断定了是否我们开始定义的用例是正确的,我们才可以为用例进行更为详细的信息添加。一旦详细的系统需求被完成,我们将它作为一个正式的交付物被 ASDI 审查通过。 图 1: 第 1 阶段用例的演进 标准化用例文档 在我们与 ASDI 对用例进行非正式的检查的会议中我们对用例进行了注释。用例图和包也被我们的高级团队成员定期的检查了,一个“健全的” 检查将带来以下的结果: 将不稳定的或者遗漏的方面反馈给组长 有用的分析建议、模式和功能分解方面的考虑 一致的系统视图 工程团队对详细需求的交流 我们现在的重点是记录我们已经了解到的东西。我们与 ASDI 在用例文档的形式上达成了一致,并且我们非常高兴他们愿意接受在 Rose 模型 中对每一个用例直接添加文档的方式。这对于我们来说,事情变得更加简单了,因为这意味着更低的对文档美观的期望。 在多个团队成员共同工作的情况下,我们发现我们需要标准化与每个用例相关联的文档。因此,我们起草一份用例的文档模板,并应用于 Rose 模型的每个用例中。在图 2 中显示的内容是被粘贴到每个用例作为模板的文档窗口。注意我们在这个模板中使用术语 “variation” 作为对 RUP 可选流概念的速记标记。 图 2: 用例文档模板 在项目的后来,我们意识到在模型(*.mdl 和 *.cat)文件中有大量 ASCII 形式的文档,使模型的加载慢了下来。感谢我们的快速的电脑,这个副作用还可以被容忍,但是在后来的项目中我们使用了更加正式的方法来维护用例的内容,通过一个自定义接口的方式(就像在文章 Fine Tuning Rose to Complement Your Process 所讨论的那样)。另一个可选的方法是使用 Rose 附带单独的 Microsoft Word 文档到用例的特性(通过右键点击用例并从上下文菜单中选择 New > File )。 用例的可跟踪性 ASDI 原来的期望是 SOW 将最终成为一个大的文字形式的文档。我们通过与他们的不断的讨论,最终他们意识到这种方法的缺点,并作出了让步的姿态。他们现在明白了使用用例的好处并很快的掌握了相关的概念,并理解了使用用例将给他们一种不需要对模型进行预排的非常强大并适当的反馈的方式。无论如何,一个好的时间和精力的分配已经进入了 SOW ,可以理解 ASDI 希望我们能够确保不会遗漏任何在 SOW 中被捕获的东西。 为了提供这个保证,我们使用了 Rational 的工具来建立在 SOW 需求和我们的相当稳定的用例之间的可跟踪性。首先我们通过 RequisitePro 将 Rose 模型与被管理的需求文档关联起来,通过选择 Tools > Rational RequisitePro > Associate Model to Project 并选择 SOW 。然后我们相应的映射每一个用例到主 SOW 需求,通过右键点击用例并在上下文菜单中选择 Requirement Properties > New 。如图 3 所示,我们展示了一个 SOW 需求列表,并从中选择适当的需求。 图 3: 关联需求与用例 我们已经在模型中建立起了这些关联,我们可以跟踪需求到用例,相反也可以。双向的可跟踪性是十分重要的,因此我们既可以发现遗漏的需求也可以发现新添加的需求。遗漏某一需求是不可接受的,跟踪需求到用例可以使我们很容易的发现我们的任何遗漏。添加需求而没有清晰的调整将导致项目范围的蔓延并对项目的时间计划和预算有着负面的影响。为了防止这一切,我们应该跟踪所有的用例到每一个存在的 SOW 需求或者变更请求。 不像跟踪需求到用例,反方向的跟踪经常被忽略,但是我们可以很容易的在 Rose 中完成这一点。为了浏览与一个用例相关联的 SOW 需求,我们简单的在 Rose 模型中右键点击用例,并选择从上下文菜单中选择 View RequisitePro Association 。这会弹出一个窗口指示哪一个 SOW 需求是被选择的用例跟踪的,如图 4 所示。如果用例没有被映射到一个 SOW 需求,底部的两个域将显示 “NONE” 。我们也可以通过 Rational SoDA 产生更加复杂的跟踪报告。 图 4: 被 Rose 报告的对于一个用例的 SOW 需求 注意在这个方法中使用一个捷径是重要的。通过我们使用的方法,我们可以仅仅可以每次关联一个用例到一个需求,反之亦然;然而,一个用例实际上是可以跟踪回到几个需求的,同样一个需求可能分布到多个用例中。我们不必苦恼映射多对多的关系。我们直接将用例关联到 SOW 中的需求,但是更好的方法是引入一个被 RequisitePro 管理的用例规格文档,它包含很多用例需求的文字描述并可以实现多对多的映射。(详细的描述可以在 Rational 白皮书 Use Case Management with Rational Rose and Rational RequisitePro 中被找到。)我们现在觉得用例规格文档是我们不应该跳过的重要步骤。 用例文档的检查周期 我们与 ASDI 都明白文档频繁的检查周期会导致无止境的循环下去。结束任何文档都是困难的,因为每一次阅读文档时检查人员经常会产生一些新的想法。在迭代的方法中,相同的 “何时结束的” 的挑战也会出现在软件的文档和其他任务中。为了满足 ASDI 对关于结束的关心,我们描述了我们对用例文档的检查周期将是什么样的,我们努力的借用了 RUP 中所描述的概念(见图 5)。 图 5: 文档检查周期图 就像你所看到的,我们的每一个文档都经过了一系列的迭代。对于我们来说找到一个工具来支持它是重要的,我们在 Rational SoDA 中发现这样一个工具,它允许我们生成 Rose 模型以外的文档。虽然对文档直接做修改是诱人的,但是这将带来文档与模型不同步的风险。如果你将在一个或其他的文档中投入精力,更好的方法是在模型中投入精力。除了你开发的软件用户手册以外,模型几乎是可以在软件被交付后还可以继续被引用和维护的产物。 通过使用 SoDA ,产生报告是简单的。为客户的检查生成用例文档,我们从 Rose 的 报告菜单中选择 SoDA Report ,这将出现一个报告模板的列表,如图 6 所示。从中我们选择 a RUP use-case model survey 模板。 图 6: SoDA 报告选择 每一个模板提供了一个缺省的报告(作为 Microsoft Word 文档)伴随一个空的部分和相应的内容表格(TOC)。图 7 显示了我们选择报告的 TOC 。我们通过与 ASDI 检查 TOC 开始,并且我们查看了我们的用例以决定是否需要在报告中根据我们的需要进行合适的裁剪。 图 7: SoDA use-case survey 报告(TOC) 你可能想知道在写任何实际的内容之前,为什么我们担心与 ASDI 一起检查 TOC 。我们发现这是一个重要的步骤。有时 ASDI 给我们一个 DID (数据项描述),它对正式的交付物提供一个 TOC ,但是我们发现在开始充实内容之前根据 TOC 从 ASDI (或者内部的团队检查人员)得到信息是有用的。有时我们在每一个部分填写显示我们将如何细化的标题,但是在首次的 TOC 检查时几乎没有任何的段落内容。 后续的文章部分将讨论 Rational SoDA 和 模板定制的更加详细的信息。 细化:不只是用例 为了使生活更加有难度, ASDI 期望我们在继续随后的任务之前创建用例文档。我们必须提醒他们用例文档直到软件被交付才会被 “完成” ,除非他们不想让我们在需求变化或者新需求出现时更新用例。我们说服了他们,他们不会对完成的 里程碑甚至是 自信的里程碑感兴趣。然而,他们希望放一个检查标记到下一个要做的 “详细的用例文档”项,因为它是十分成熟的,我们同意这个观点。 真正的挑战是说服 ASDI 所有需要的活动应该是并行的发生,而不是所有的里程碑都是按照顺序被交付的。我们把它作为在项目早期的一个常规的关注点,它仍然没有被完全的解决。为了让他符合用例分析的一些活动,我们提出了这两个观点: 屏幕的模拟将简化需求的检查,并可以比用例讲述一个广泛的经过。 没有一些前瞻性的原型,工具获得、安装和培训不应该发生。 我们非常高兴 ASDI 同意模拟和原型作为分析阶段的有用的部分。这使我们可以在用例分析被完成前进入到架构的和工具的选择问题中。 选择工具和技术 工具和技术选择从来就不是微不足道的任务,虽然它常常被忽略。团队经常根据启动成本、“小工具因素”、好奇心或者对工具和技术的忠心来作出选择,相反,他们应该考虑生产成本、可靠性、可得到的培训、团队技能和特性标准。在评估过程中添加一些正式手续可以确保工具的选择使基于项目需要的而不是个人主观的意见。 正式的工具评估 一个在 RUP 中很少关注的地方是团队挑选现货(off-the-shelf)— 也称作商业现货供应 (COTS) — 工具的过程。可以了解这个过程领域知识的一个地方是卡内基-梅隆软件工程学院(SEI),那里有 COTS-Based Systems Initiative 关注于 COTS 产品的选择和采纳的策略。特别有趣的是 SEI 的 product feature checklist ;虽然它更关注于选择软件系统的组件和框架,但是其中的很多策略也可以被用于选择软件开发工具、Web 服务、数据库等等。 工具选择标准 ASDI 向我们展示了这些他们觉得将影响我们的工具选择的标准: 他们最终承担系统的核心开发和维护团队包含 3 到 5 个人。 系统能够被 4 到 7 个内部用户和 1 到 5 个来自于 20 到 30 个公司的外部用户访问(虽然系统的将来版本将支持数千人在线用户)。 跨平台技术是重要的, 因为 ASDI 期望在数年中这个系统仍然是可用的。 对所有技术的培训必须是容易得到的。 他们强烈首选基于 Java 的解决方案。 他们首选 OODB (面向对象的数据库)作为数据的存储。 系统的早期版本将运行在 Linux 系统上,虽然之后将运行在 Solaris 系统之上。 开发人员需要能够在 Windows 2000 的机器上有效的使用软件。 性能不会是重要的挑战,因为在同一时刻仅有少数的用户与系统进行交互。 应用服务器的选择 我们拥有 J2EE 应用服务器的经验,因此我们非常幸运 ASDI 选择基于 Java 方案。不过在我们还是快速的评估了象 Perl/CGI 和 PHP 这样的入门级的 Web 方案之后的计算技术(主要是 Microsoft .NET/DNA)。 我们一致发现 Orion Application Server 是友好的并是最成本有效的开发环境。在那里 Orion 唯一评分低的方面是 供应商的稳定性和支持。提供 Orion 产品的公司是非常小的并且不具备象 BEA 的 WebLogic 或者 IBM 的 WebSphere 的能力和信誉。然而在与 ASDI 的检查人员讨论后,我们互相同意 Orion 的 J2EE 标准遵从的好处足以抵消这些风险。如果第二阶段开发需要,仔细的开发将可以确保我们拥有轻便的可以移植到其他应用服务器方案的代码。因此我们选择了 Orion — 这意味这启动成本为零,因为 Orion 是免费的。 Web 服务器选择 Orion 带有高速的内建的 Web 服务器,因此当 Orion 被选定后 Web 服务器的选择过程也就有了结论。它主要的竞争对手是 Apache 。然而,在 Orion 网站上显示 Orion 已经在某些测试方面达到并超过了 Apache 。 数据库选择 使用哪一个数据库的选择不是显而易见的。数据库通常不会执行高负载,但是它需要有丰富的特性支持。比如,复杂的数据关系要求有完全的引用完整性限制。同时,系统必须可以 24 小时不间断运行,因此我们希望它具有热备功能、复制、其他的可用性和容错特性。我们是否会用到所有的特性将在以后被决定。 我们觉得 PostgreSQL 仅仅是一个有资格的开放源码的候选者。它有很好的 ANSI SQL 支持和引用完整性,并且只要并发用户的增长不太大它可以保持良好的性能。然而,数据存储需要更多的来自于一个供应商的 committed 支持。此外,我们觉得 PostgreSQL 在线支持(比如用户社区讨论)对我们来说是不够的。MySQL 实际上是更加流行的开放源码的数据库,但是它缺少太多的特性(比如,外键支持)。 然后我们转到主流的数据库:DB2, Oracle, and Microsoft SQL。我们在 Oracle 上有着丰富的经验,但是新的处理器单元价格模式对于我们的这个应用来说是过于昂贵了。Oracle 的每 MHz 每 CPU 的基本负荷,意味着 ASDI 将为系统忍受高的生产环境成本,除非他们愿意将 Oracle 安装在一台 P-133 的机器上。Microsoft SQL 被淘汰了,因为它是基于私有平台的。如果创建一个基于 DNA 的方案,Microsoft SQL 自然是首选的,但是对于 J2EE 来说很少被选择的。 最后,我们选择了 DB2 ,我们的调查表明 DB2 对 SQL 有着非常优秀的支持、强大的容错特性、公道的价格模式和正在增长的和被培训的在线用户集合。 IBM 的 JDBC 驱动是高性能的,而且他们的个人版可以被免费的用于开发团队中。不幸的是,我们缺乏 DB2 的技能,这就意味着一些培训在原型活动期间被需要。 你也许正想知道对于 ASDI 首选的 OODB 的选择发生了什么。在通过原型和探索产品后,我们很快个到了结论,使用 OODB 得到的好处不足以抵消它带来的风险。关于这个的更多思想,看下面的文章 引用和其他资源 。 集成开发环境(IDE)选择 在这一点上,我们不想使用任何高端的 IDE 产品,有几个原因: 我们并不明确第 1 阶段概念的证明需要使用 Enterprise JavaBeans 。 IDE 的投入是昂贵的。 团队的成员已经有了他们自己的选择。 因为第 1 阶段的时间是很紧的,使用如 IBM 的 VisualAge 所带来的学习曲线是我们无法承受的。 相反,我们混合使用了以下工具: JCreator — 免费的基于 Java 的 IDE CodeGuide — 低成本的 IDE log4j — 简化服务器端 调试的日志工具 Jikes — 快速严格的 Java 编译器 很自然,这些工具可通过使用 Rational 工具来弥补在测试、调优和代码覆盖上的缺乏。 总结 在这个阶段我们看到了用例的演进(通过可跟踪性和文档化)并且通过 ASDI 参与的用例的检查,我们快速的发现我们是自由主题方式的专家。这通常是软件开发项目中的最大挑战之一,因此早期的并有效地建立这种关系才是真正的胜利。我们与 ASDI 的关心通常是很好的。他们很快的理解并同意了基于 RUP 的开发过程而没有花费我们太多的精力。这是令人惊讶的,被他们给的首选的瀑布型的开发最终取得了这个和约。很多被 RUP 鼓励的迭代和增量开发的方法被良好的进行了调整,并且 ASDI 也看到可好处。 我们幸运的是工具的选择相当的简单,并在项目的早期被完成。Rational 的一些工具被用来节省我们的时间。在之前的项目中我们使用 Excel 来管理需求,但是我们发现 Rational RequisitePro 是一流的并是完整的方案。此外, Rational SoDA 报告可以大大的降低我们的文档生成的成本。因为这个项目是我们第一次使用 SoDA,我们非常高兴 ASDI 对标准的 SoDA 模板表示满意。 计划未来 到现在为止,我们把焦点放到了需求相关的产物上,并且花费了相对来说不多的时间来评估技术并创建原型以支持工具的选择。现在对我们来说重要的是通过创建更有挑战的原型来揭示系统更加复杂的领域,并开始在实际的开发中使用工具。我们是否会用到 XML ?如果会用到,我们应该使用什么样的解释器?我们需要什么样的安全机制?我们应该使用 Enterprise JavaBeans 吗?象这些问题我们将很快有答案。 换句话说,是时候从分析转移到架构和设计了 — 尽可能快而不是晚,因为大多数的技术风险将在接下来的几周显现出来。我们有一个很好的功能基线包含一系列定义良好的用例。对于我们来说避免分析麻痹大意和维护前进的动力是重要的。 主要风险 没有新的风险被识别出来;实际上我们的风险列表比以前更短了。因为 ASDI 同意对于这个项目 OODB 是不合适的,我们因此不再有技术上的风险要管理。他们也放松了对我们的交付产物的正规形式和他们预想的结构,并且他们毫无保留的批准了我们的基于 RUP 框架的文档。 在我们关心的剩余时间和工作量的问题上,当我们增加了对所需能够的理解和对技术熟悉后,我们觉得预算更加符合项目情况了。更进一步的技术探索勿庸置疑的将揭开新的挑战。
|