应用Rational 工具简化基于J2EE的项目

应用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的项目 （二）启动项目 ========================================================== 第二部分:启动项目 Steven Franklin 软件设计师和过程专家 2004 年 3 月 这个有多篇文章组成的系列讲述了如何逐渐的应用 Rational 统一过程（RUP）和其他的 Rational 工具，本文中样例项目的详细计划被围绕着管理需求和风险而讨论。 第二部分快照 第 2 部分展示的工具和技术： Rational 统一过程 (RUP) — 支持项目计划的制定 RUP Microsoft Word 模板 — 草拟项目远景文档 Rational RequisitePro v2001A — 用于需求数据库 Rational ClearQuest v2001A — 用于风险管理 将被创建或者更新的产物： RequisitePro 数据库 — 被创建用来存储来自于客户的工作描述（SOW）的需求；之后需求会转化成直接面向分析工作的更为详细的系统需求规格说明书。 ClearQuest 风险数据库 — （通过修改 ClearQuest 计划）被创建以跟踪项目风险 从开始进行计划或者计划失败 在一个软件项目中，获得一个良好的开始是十分关键的。你不仅会希望你的早期劳动确定整个项目的基调，而且你也希望快速的识别出系统中的高风险和挑战的部分。大概一半以上的项目的命运在项目的第一个月就已经注定了，决定的因素包括： 不够良好的客户关系 不充足的预算 糟糕的管理（包括不够好的管理能力、风险的优先级划分和糟糕的项目范围管理） 过于依赖银弹 工程技能和经验的缺乏 不切实际的时间进度 Rational 统一过程（RUP）通过改进团队的效率和指导提升团队的成熟性可以尽量的减少导致项目失败的因素。良好的数据可以影响项目的管理者对项目的管理，更好的工具可以支持工程团队，更好的过程能够帮助软件产品以一种可预见的方式发展。本系列的第2部分将把重点放在我们能应用的一些早期策略上以获得一些在我们的样例项目中摇摆不定的事情。 Note that project management involves some activities that aren't currently addressed in the RUP. I highly recommend the book 请注意项目管理包括一些目前在 RUP 中没有包含的活动。我强烈推荐这本书 快速开发: 驯服疯狂的软件进度 它可以作为在开发项目中减少风险因素的进一步的参考资料。 细化第1阶段时间进度 我们希望尽快启动软件工程，但是首先我们必须在一系列的日程安排问题上得到来自于客户的同意。我们拿来了 我们已经创建的第1阶段的时间进度 （在4个月的时间点以一个演示结束）并和客户更加紧密的审查时间进度。客户提出了以下的问题，所有的问题都是正当的并且一些讨论： “使用迭代开发，工程团队将如何知道需要多少次的迭代才能实现我们目标呢？” ”在分析和架构的必要条件被达到前开始设计架构和设计对我们来说是不舒服的。“ “在4个月的时候我们将得到具有什么功能的系统演示呢？” “你们将使用什么工具来创建系统呢？我们希望开始采购和培训过程。” 这就是我们看到的客户的主要的关心点，并且我们对每一项作出了回答： 担心项目螺旋式的不断进展却没有清晰的交付产品 因为 ASDI 是一家十分遵循有循序的 ISO 标准的公司，因此他们倾向于在早期制定按照从一个到另一个的顺序的具体的时间底线。我们指出迭代可以减少风险并避免一次产生所有产物的与生俱来的问题。虽然迭代的次数可能会在项目过程中有所变化，但客户可以比仅仅一个单一的迭代更好的观测项目的进展。虽然一个单一的迭代看起来是更加简单的，但我们需要多个迭代以更加成本有效的创建系统。在早期的迭代中有 ASDI 的参与将使他们获得更多的好处，这使客户有机会对开发系统的输入提供他们自己的看法。 担心遗漏的需求和不充分的分析。 这里再一次提到，ASDI ISO 背景使他们更愿意相信分析应该在任何的设计开始之前被执行和文档化。我们向他们强调了 RUP 具有允许任务交迭执行的好处；也就是说，不同阶段的任务可以并行的被执行。比如，详细设计可以包括原型的创建和其他一些代码开发以验证设计的假设，减少性能风险等等。瀑布式的开发过程有很少的灵活性，并且不会为你提供高风险的很多早期警告。 担心项目进展的跟踪。 ASDI 中已经开始有对使用迭代开发方法的担心的声音了，并且他们需要看到能够在项目中产成系统演示的具体进展的保证。在这一点上我们不能告诉他们演示被限定成什么样子。这需要经过一个或两个月当我们对更多的理解了系统的关键的和高风险的领域时才能被确定。我们向他们解释说至少系统演示应该展示一些已经降低了我们已识别的主要风险的体系架构的深层次的部分。我们也预期系统演示可以显示整个系统的工作流、可用性问题和组件之间的交互性的问题。 担心我们选择的工具他们将来无法提供或支持。 这对于 ASDI 来说是十分重要的，因为他们计划在项目结束后自己承担维护系统的责任。他们不想看到过早的使用令人兴奋的但有风险的技术。在工具选择方面我们需要针对客户的技术需求、维护计划和其他的需要作一些早期的探索工作。 OTS 评估（包括我们所推荐的）将给 ASDI 一个时机来审查我们对工具和技术选择的标准和理由。在这一点上，ASDI 仍然对自己的执行条件没有信心，他们目前有很少的 IT 基础设施推动我们作快速的决定。 综上所述，我们并不觉得我们时间进度计划是过分自信的，并且我们有信心在客户的成本期望之内完成任务。关于我们能够满足时间进度的能力来自于我们的团队结构，在项目团队中我们与 ASDI 一起对项目进行审查。如表1所示，我们计划了包括一些兼职角色的人员。例如，我们有单独的一个 QA 人员在我们的项目中，这个人同时也在其她项目中扮演角色；在我们的项目中显示她作为一个20％的角色，这就以为着在我们的项目中她一周工作一天： 　 角色 时间承诺 项目管理 项目经理 50% 财务支持 15% 质量保证 10% 项目工程 项目工程师 50% 工程支持 (包括配置管理、系统管理等) 兼职 支持和审查团队(定期的审查和咨询) 兼职 (从项目内和项目外雇用的人员) 组长/高级分析师 全职 高级开发人员 全职 普通开发人员 全职 数据库架构师 25% Table 1:团队结构 总的来看，我们计划需要450个人天的工作量来创建这四个月之久的系统演示。在项目的进展过程中，我们将知道是否我们需要增加时间或者提前完成，我们也将通知 ASDI 项目的情况。在展示系统演示的时候，我们也要对深入的设计审查做好充分的准备，并且能过向客户展示对项目第2阶段的估计。如果 ASDI 对我们在第1阶段的概念检验(POC)的工作表示满意，他们将与我们启动项目的第2阶段的工作来开发产品化的系统。 虽然我们还在创建了ASDI 的第1阶段的演示，但 ASDI 非常高兴的看到了我们所作的工作将是进一步开发产品化系统的良好输入。至少他们已经接近可需求的审查、屏幕的模式、OTS 评估、架构审查、两个实际的版本和一个系统演示。 管理风险 从一开始就跟踪风险是极其重要的。在之前的项目中，我们使用 Microsoft Excel 来管理风险，这次我们决定使用 Rational ClearQuest 以简化风险的输入、管理和报告。 ClearQuest 不是一个便宜的工具，而且它对风险管理不是独一无二的成本有效的工具。然而，它同时还可以集中的管理我们的集成和测试方面的问题。此外，我们计划在 Lookoff 的其他项目中共同承担这个成本。 使用 ClearQuest Designer 可以非常方便的设计新的数据结构和表单。比如，创建一个风险录入表单就类似与已经在 ClearQuest Designer 中显示的缺陷表单，我们可以根据缺陷跟踪计划（DefectTracking schema）来新的计划（schema），也可以删除一些不必要的条目和重命名其他的条目，类似的更新相应的表单，删除或者重命名必要的提示和域。 这里是你如何能够自己进行试验：假设你已经安装了 ClearQuest 并具有管理员的权限，你应该可以很容易的找到 ClearQuest Designer 应用程序。从文件菜单中，选择 创建计划（New Schema ），并且选择一个已存在的你想修改的计划（Schema）。我们选择修改缺陷跟踪计划（DefectTracking schema）。一旦你给你的新计划（schema）一个名字，你将被提示创建一个与这个计划（schema）相关联的数据库。除非你制定一个特殊的方法，否则你将以 Microsoft Access 数据库的形式创建这个数据库。当被要求将这个新建的数据库与一个计划（Schema）关联时，选择你刚刚创建并命名的计划（Schema）。然后你可以检查编辑和修改的表单和数据类型以符合你的要求。比如，你可以展开记录类型和目录树的表单节点来查看存在的 Defect_Base_Submit 表单。这些表单可以被重命名，一些域可以被删除、添加等等。更多创建和修改 ClearQuest 表单的信息，请参考 ClearQuest 文档。 我可以很快的在我们的桌面将我们项目的风险输入到 ClearQuest 中。整个团队的所有成员都可以访问风险数据库，并且可以输入他们观察到的风险。虽然只有项目经理(PM)和项目工程师(PE)应该具有权限关闭风险，但是给团队的每一个成员提出风险的权限是没什么不对的。项目经理首先会希望查看对于客户可见的风险，因为其中的某些风险也许不是相关联的或者是可以很快被解决的。例如，图1显示了一个被用来输入我们讨论过的项目早期遇到的风险的表单。 图 1: ClearQuest 风险输入表单 对于项目的开始我发现并输入和一共17个风险。这并不是一个非常大的数字，其中的一些风险（比如有挑战的时间进度计划）直到项目的最后时期都会存在。 图2显示了我们所查询的项目风险的一个部分的列表的 ClearQuest 界面。风险被列在最上方，并且严格的按照顺序排列。通过点击列表中的风险项可以得到更加详细的单个风险的信息。 Figure 2: ClearQuest 风险报告 跟踪进展 管理需要工具来跟踪项目的进展。在项目的早期阶段，我们不能依赖任何象缺陷、变更请求和测试结果来衡量项目的成功。相反，我们必须根据工作分解结构(WBS)项和我们的进展来估计实际完成的比例。 好的工作分解结构(WBS) 对于跟踪项目进展是十分重要的。第1部分中的干特图 描述了我们第1阶段的工作任务包 。为了使我们可以精练出有用的矩阵，这些工作任务包必须被清晰的定义并也适当的规划每个工作任务包的大小。我们典型的为这些工作任务包分配10到40天的工作工作量。 此外，ClearQuest 也可以帮助我们跟踪那些系统中可变的部分—在这些可变的部分中，变更请求却是极其的偏高。在一些之前的项目中，我们发现在细化阶段出现的过多的变更请求通常是下列方面中的一项或者多项的征兆：不够充分的分析、难相处的客户、脆弱的工程团队、不良的过程执行或者复杂的再工程。如果在系统的某些方面出现了一点这些症状，就需要管理人员和组长对这些部分有额外的注意。 管理客户期望 有时减少与客户开会和接触开起来是很容易的；然而，实际上是你的项目团队成员中最重要的成员之一，并且客户应该被从始至终的包括在整个项目中。这不仅仅可以产生更好的分析和改进每个迭代所获得的结果，而且可以通过让客户看到进化中的产品和理解面临的挑战更好的管理客户的期望。尤其是当客户对技术不是非常精通时，他们对最终产品的期望肯能会很大程度的超出现实的成本、时间进度和可行性。 我们怀疑真正的项目优先级和动机并没有反映客户的工作现状，我们还需要理解客户关心的主要优先级和期望。为了实现之一点，我们起草了一份概要的远景文档来帮助谅解更多的客户期望。（由于时间的限制，我们将业务远景和项目远景合并成了一个文档。）不论是工作现状（SOW）还是远景文档都要与客户一起进行多次的修订。 远景文档是基于在几个由 RUP 安装包提供的 Microsoft Word 模板其中的一个创建的。我们将这些模板安装在 Word 指定的地方（通过 工具 > 选项 > 文件位置）。如图3所示，我们为每个模板生成了预览（通过打开每个 .dot 模板文件，选择文件 > 属性 > 总结，检查 “保存预览画面” ，保存文件）并对模板的标题重命名 *.dot 文件以使他们更容易浏览。 图 3: 浏览 RUP Microsoft Word 模板 管理需求 需求对于系统来说不是微不足道的。同样，因为 ASDI 有很少的 IT 基础设施，因此系统需求向详细的软件需求的转换就需要充足的时间和劳动的付出。Rational RequisitePro 可以非常好的帮助我们完成这个任务，它允许我们在整个项目中管理我们的需求和跟踪项目范围的变化。 客户已经开始的工作现状（SOW）可以作为我们的系统需求基线。在许多的情况下，我们按照 RUP 中描述的从业务建模和需求分析开始。这应该包括业务用例的集合、补充的系统规范和业务对象模型。但是对于我们来说从客户的工作现状开始来满足他们的期望并建立在他们的工作之上是十分重要的。我们将按照的工作现状生成了一个叫作软件需求说明书 (SRS) 的 RUP 产物，并且把它作为需求的基础集合，根据它我们可以跟踪我们后来的分析和建模产物。 RequisitePro 的能力可以非常容易的帮助我们从客户的工作状态（SOW）插入需求。我们创建需求的规则要与我们“子弹”的样式相配，或者与任何或所有的关键字 "must"、 "will" 和 "should" 相配。其他可以帮助我们建立需求层次的诀窍包括在相同的级别上获取需求块，在需求块创建标签下对适当的父需求设置缺省值，然后让创建工具完成接下来的工作。（起先我们使用需求块创建时没有设置父需求，所以我们必须返回到每一个需求并对每一个需求设置父需求 — 对于成百上千的需求来说这是单调乏味的工作。） 图4显示了来自于客户服务子系统需求的一页（一共大约40页）。就象你看到的一样，RequisitePro 的界面被紧密的集成到了 Word 应用程序中，因此你可以同时使用 Microsoft Word 和 RequisitePro 的特性。 图 4: Rational RequisitePro 界面 我们与客户紧密的沟通什么样的信息是被需要的，但是我们让他们在需求文档上作了大量的工作。这被证明是一个非常有效的方式；我们能够向他们的团队传授过程的技能，而他们能够给我们的团队他们学科的专家意见。我们趋向于非常细节的投入到一些领域中，而在其他的一些领域只是在非常高的层面上。在一些情况下这是非常合理的，但是在另一些情况下他们却对系统的一个特定的领域过分的狂热。通过对文档的审查，我们可以指导 ASDI 写出适当并足够详细的需求集合。因为我们正在处理的是 Word 文档，因此规格上的互操作是容易的，当我们对这个文档感到满意时，我们就可以在文档上运行 RequisitePro 。 同样在这个时候我们关注系统的 非功能 需求，这就意味着这些需求不会被系统的功能规格说明描述。这些非功能需求包括关注人的因素的可用性需求（比如学习和使用的舒适性）和可靠性需求等等。 总结 在项目的这个点上，我们运作着一个很小的团队。制定计划和获得资源是我们首要的任务。直到我们知道了我们应该朝什么方向努力并知道如何可以实现目标，我们的团队才会越来越有斗志。对于我们来说首先最重要的是我们必须完成客户的工作状态（SRS），它规定了项目的基本系统和软件需求。 计划未来 我们希望尽快的组成工程团队，但是我们接下来的任务需要一个高级的分析师以使 RUP 的初始阶段更有进展。首先，被显示在我们的工作状态（SOW）中的需求本质上是一系列被分解的规格说明，这些规格说明不能引导清晰的工作分解，或者甚至不能会产生许多架构的线索。我们一直认为以平白的文字表示的需求不会带来以统一建模语言（UML）表达的需求带来同样的好处，因此我们计划将我们的需求转化成用例（在 Rational Rose 中使用 UML）。 同样，我们需要一种正式的方式来管理客户的变更请求、客户所关心的地方和客户的反馈。虽然之前我们没有使用 ClearQuest 的 Web 界面，但是它看起来像是一个完美的工具使开发团队和客户保持同步。建立 ClearQuest Web 对我们来说是下一周或第二周最高优先级的事情。 主要风险 我们的风险没有明显的变化：我们必须继续把精力放在建立有效的客户关系和快速的使项目沿着正确的方向前进。我么们现在有一个问题数据库，因此我们可以关闭这个风险了；然而，直到我们建立了 ClearQuest 的 Web 界面，客户才可以对项目的风险和他们可以支持我们的领域看得更加清楚。（后来当我们关闭这个风险时，我们不能提供时间或者基础设施来建立 ClearQuest，但是一个大的项目将很明确的会从 ClearQuest 中受益。） 客户很高兴我们的进展如期完成，一部分是因为我们的工作产物对他们来说不是感觉不相关的。当我们继续的移到 RUP 的产物时我们必须通过大量的指导来维护客户的舒适感觉并温和的进入新的概念：用例、业务对象等等。 我们觉得我们的时间进度是切合实际的并且设计是良好的除了有非常小的意外。这就意味着资源必须尽快的到位，并且审查返回必须是及时的。我们也必须从一开始就关注高级别的风险，因为我们不能让他们在晚些时候遛进项目的第1阶段。

应用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 框架的文档。 在我们关心的剩余时间和工作量的问题上，当我们增加了对所需能够的理解和对技术熟悉后，我们觉得预算更加符合项目情况了。更进一步的技术探索勿庸置疑的将揭开新的挑战。 应用Rational工具简化基于J2EE项目（五）架构与设计 =============================================================== 第 5 部分 ：架构与设计 Steven Franklin 软件设计师和过程专家 2004 年 4 月 当这个正在进行的应用 RUP 和其他的 Rational 工具的 J2EE 样例项目从用例转换成架构和设计时（包括数据建模和构建测试设计假想的原型），这个项目已经进入了更加技术的阶段了。 这个系列的第 5 部分首先检查了一下项目的时间进度，然后当我们进入了架构、设计、数据建模和创建原型时，我们已经在下一个阶段进行细化阶段中了。 第 5 部分快照 在第 5 部分演示的工具和技术： Rational Rose 企业版 用于创建设计模型（包括使用 Rose 的 data modeler 进行数据建模） Rational RequisitePro — 用于添加或者细化需求 产生或者被更新的产物： 设计模型 （Rational Rose） — 被创建来添加架构和设计信息（包括数据库计划（schema）） RequisitePro database — 被更新以添加或者细化基于架构和设计探索的需求 项目的时间进度 在开始进行详细的架构和设计工作之前，让我们来检查一下 ASDI 项目的整体进度。就像你可以第 1 部分回想起来的，这个由多个部分组成的系列文章覆盖了项目的第 1 个阶段：以一系列需求、一个参考架构和代码（理想的可重用的）为结果的概念的验证。到目前为止，我们大概使用了整个第 1 阶段预算的三分之一，但我们已经接近了项目时间进度的一半了。这是在我们的预料之中的，因为我们有意的让进度稍微慢一点。分析和计划活动总是以较慢的步伐移动，团队应该在项目开始时逐步的将他们建立起来。 因为第 1 阶段要求一个相关的结构化的和正式的概念的证据，我们将它作为一个小的项目处理，通过在演进的产品上进行测试和 QA（同级审查）来完成它。RUP 有一些用于开发概念证据的机制，基本在分析和设计工作流的执行架构的合成的活动中。我们正在进一步的将概念的证据转化成可用的 beta 版产品。我们能够将更多的功能、风险的降低和产品的成熟放到这个阶段中，我们越多的将技能和知识用到系统的产品版本中，我们的客户就越高兴。 这个接下来的一系列的任务将比之前的活动更加具有技术性。我们正很好的向架构。设计、数据建模和原型前进。在第 4 部分中我们讨论了一些原型和评估如何进行我们的工具选择；现在我们的原型的关注点在测试我们设想的需求、系统说明和设计上。 过渡到架构和设计 架构和设计活动是在 ASDI 项目中最令人愉快和具有创造力的任务。我们为我们将系统计划的高效、安全和简单优雅而自豪。技术方案的远景在多次令人兴奋的会面、自由讨论和技术探索中最终形产生了。 简单的讲，架构意在捕获技术上灵活的方案，这个方案可以覆盖上个月我们定义出来的系统需求。不论是向前看（对于设计）还是向后看（对于需求），架构团队都将承受巨大的压力。 Rational Rose 的集成开发环境通过让我们能够做以下的事情简化了这个挑战： 使用 SoDA 产生文档以允许架构和设计元素的分发，简化了检查并保持每个人都有一致的当前远景。 从场景直接更新类的签名（方法和属性），以使我们不必回到类的说明中添加缺少的方法。 为自动化的任务比如产生类的骨架、检查模型的命名习惯和测试模型的完整性和有效性生成 RoseScripts （可以通过访问 Tools 菜单得到）。 使用 Rose 的 RUP 模板，提供一个附带 RUP 指南的模型框架。 在 Rose 中从提供的 J2EE 类框架中拖出类。 用 Rose 的”单元控制“特性将模型分解成为能够被团队进行版本控制和并行工作的片断。 注意，因为我们在过去的项目中创建的系统与目前这个系统类似，因此如果我们引用一些参考架构，我们的架构将会从中受益。然而，我们不能在已存在的包或者设计模式中找到任何可重用的机会，因此我们只是引用了已存在系统中可能会在将来用到的思想和类。 从用例到设计类的转化 从用例到设计类的转化过程是缓慢的，需要进行多次的迭代。这牵扯到分析人员和设计人员，因为我们有很少的既可以舒服的与客户讨论业务领域又可以使用特定的工具进行分析、细化设计产物的人员。 这个活动的目标 有时将需求直接的转换成代码是诱人的。实际上，我们在以前的项目中就是这样做的（因为我们有非常详细的需求说明），我们在我们对项目的理解上非常自信。这样就产生了一个错误。需求被遗漏，范围很难被跟踪，并且大量的工作和返工是无用的。使用设计模型来连接在需求和代码之间的鸿沟是重要的；设计模型可以在开发和测试之前很久捕获错误和有问题的假设。 在从用例向设计类转化的过程中，我们希望能够实现： 将分析小组的知识传授给工程团队。 识别能够满足所有需求的技术方案 — 或者，什么地方不是可能的，识别与技术方案冲突的需求，并确定是否他们是重要的或者被改变或者被删除。 识别能够帮助确定团队结构、架构层次和对于购买软件的候选的接口。 指定技术方案的细节并开始计划如何在团队之中分配工作。 基于设计模型的细化时间进行计划和预算的预估。 分配类到平台、产品和私有代码。 为了反馈和同步的目的，生成软件架构文档，软件架构文档能够被分发到内部和外部的团队成员。 实现稳定的设计 从用例和分析类到设计和设计类的转化是不可避免的模糊的。在我们能够拥有我们感到满意的设计之前，我们需要做大量的工作。图 1 显示了我们以我们的方法定义一个稳定的设计的主要活动。 图 1: 从用例模型到设计模型的转化 前面的文章部分讨论了多数的在图 1 中作为”架构“准备的活动和产物（特别是 SOW 需求、用例、业务对象模型和分析类）。此外，这些其他的活动对设计工作也是重要的： 确定包的结构 建模数据（创建数据库计划） 创建原型和屏幕模拟 这些将在接下来的部分连同如何处理新的和改变的需求一起被讨论。 打包和子系统结构 在开始考虑设计类之前，整个团队要对一个良好的包结构达成一致同意。不管我们最后的决定是什么，它都应该成为设计过程中的指导方针，所有团队成员都要遵守这个指导方针。 包结构的选择 我们一直在争论是按照子系统（图 2）来划分包还是按照架构的层次来划分（图 3）。表 1 列出了每种方法的有点和缺点。 图 2: 按照子系统定义包 图 3 : 按照架构的层次进行包的划分 方法 优点 缺点 按照子系统定义包 它简化了模型的管理。复杂的子系统能够以单一的 *.cat 文件或者 *.cat 文件的层次被分配给大的团队。 对于在子系统之间不合规定的依赖可以容易的测试出来。 它简化了对项目增量的计划。 它鼓励减少子系统，使架构更容易被看懂。 它增加了子系统重用的可能性。 子系统之间的一致性和被共享的关系将更难的被协调。例如，DBA 也许要更加努力的理解数据层的蓝图，或者数据抽象类和计划实体之间的依赖。 它能够促进来自于通用服务包的令人泄气的重用哲学。 按照架构层次划分包 层次之间的一致性要被维护。 它隔离了不同的技术领域：在用户界面层的 JavaServer Pages (JSP)；在业务逻辑层的 Enterprise JavaBeans (EJB) 和 servlets ；实体 bean 、类和数据层的表。 它增加了重用系统架构的可能性。 不是所有的代码都是恰好的符合三层架构中的一层。 对于一个子系统，团队领导或者远程团队必须检出（check out）几个 *.cat 文件来更新或者获得子系统模型的所有权限。 如果不将所有的模型都检出（check out），通常很难报告或者呈现一个具体的子系统。 表 1: 打包方法的比较 最终我们使用了第一种方法，按照子系统来划分设计模型。我们觉得系统是足够小的，我们可以保持好子系统之间的一致性。 子系统结构设计 我们的顶层的包结构的一个最初草稿就象图 4 。你可以从顶层的包中看到被识别的子系统（因此，原型 <> 被分配给了每一个子系统）。 图 4: 顶层包的结构 在我们将这个早期的草稿变成最终稳定的包结构之前，我们进行了大量的讨论。下面是我们关注的一些问题： 我们如何组织通用的服务？ 回答：公用服务被单独的放在一个子包中（日志服务；数据同步和备份服务；访问控制服务和登陆服务）。 我们应该在 shipping 和 part management 之间画线吗？ 回答: 我们不需要连接他们两个。 我们根据领域还是架构来定义子系统？ 回答：架构在大多数地方都能与领域结合。 我们允许包之间的双向依赖吗？ 回答：不。这是违背我们内部设计指导方针的不好的设计实践。 作为一个例子，我们将着重关注在 command gateway 子系统上。虽然系统的很多地方都是以一个内部的和外部的 Web 接口为中心的，我们还是计划提供一个安全的、基于 XML 的命令网关（command gateway），这个命令网关允许 ASDI 的系统与它的大客户之间的形成一个 B2B（business-to-business）的接口。这个特性允许这些客户能够从他们已有的系统对 ASDI 查询、提交和更新信息。这是非常重要的，因为一些公司的需求是不能通过 Web 接口访问，相反他们需要的来自与公司的代号的批量的或者是幕后的提交。 在每一个包中，我们最初的类图都来自于我们的用例、业务对象模型、注释和访谈。图5 显示了 command gateway 子系统从早期的思想到详细的设计的演进过程。 图 5: command gateway 的初始设计 在这个第一轮的设计中，我们简单的识别出 command gateway 子系统的主要部分，在这个层次上存在着必须被关注的问题： 我们使用 XML 吗？（问题包括宽带消费、稳定性和解释器的成熟性）。 我们要向客户发送和接收数据吗？ 我们要提供命令的客户端软件或者仅仅为此发布命令的规范？ 我们要通过 SSL（Secure Sockets Layer）、HTTP 或者私有的套接字通讯传输 XML 吗？ 在后续的设计中（图 6 ），我们识别出了在系统中的更多依赖关系，并开始识别看起来象实现类的东西。我们仍然在争论高级别的概念，因此我们对文档和类的签名并不感兴趣（方法和属性）。文档和类的签名应该在我们觉得设计开始稳定时被填充进去。 图 6: command gateway 的中期设计 就像图 7 显示的那样，我们后来细化了一些我们识别出的依赖关系、适当的方法和属性（被隐藏在图中以节省空间），并且添加了一些技术的细节。例如，通过建立原型我们识别出将 JSSE (Java Secure Socket Extension) 作为在客户和服务器之间的 SSL 连接的方案。JSSE 被直接集成到了 JDK 1.4 中，当对 JDK 1.4 以前的版本它只是一个附加的部分。 图 7: 成熟的 command gateway 设计 这个设计还不是最终的。虽然设计已经通过众多的场景图被测试过了，但是在接下来的数周和数月的编码中将发现设计中不正确的地方或者或者遗漏的细节。 管理需求的变更 当我们进行架构和设计时，我们识别出了添加新的需求或者对已有系统需求进行细化的需要。忽略一些小的变更是诱人的，但是我们看到需要相当多的预算来完成变更。在预算上的小的缺口将增加需要的时间，并给客户一个不好的先例。我们发现跟踪所有的添加和变更将有助于我们用检查保持期望，并迫使我们问，“在将来我们真的需要这个吗？” 这是一个我们通常忽略的关键点：如果一个需求不是足够重要进入系统，那么这个需求就不值得去实现。 有时，需求的引入会对已有的进化和预算带来负面的影响。这就要求我们坐下来和客户讨论选择 — 但是首先，我们应该在我们内部进行讨论，以便我们能可信的向客户提出备选方案，而不是简单的“即兴表演”。选择通常包括以下的方面： 推迟需求。 这通常发生在需求不是都重要的时候，或者是其他的需求没有目前正在构建的需求那么重要。 去掉需求。 这发生在需求更本不重要的时候。 用一个新的需求代替一个已有的需求。 如果已存在的需求不是重要的或者这至少不是特别紧急的，我们可以推迟或者去除这个需求来为新的需求在时间进度和预算上腾出空间。 添加需求到目前的工作中。 这种选择仅仅在不会引入不可接受的风险到已存在的需求和整个系统计划时才被考虑。添加任何重要的需求自然会要求额外的时间和预算。 对用例进行变更不是问题，因为我们对用例进行了严格的版本控制，并可以直接的在模型中更新他们。此外，Rational RequisitePro 的使用将编程集成回到 SOW 中也是容易的。然而，追溯我们所希望的，我们已经花费时间建立了 Rational ClearQuest 来管理需求的变更。有时变更是被内部识别出来的，但是更多的情况是有外部的请求产生的。我们的变更管理过程是非常笨拙的，包括每月的会议、硬拷贝的文件等等。更加无缝的变更请求过程几乎会为控制范围的增长、产生更好的系统和更高的和约价值带来的更多的机会。 数据建模 当我们开始进行上面所描述的设计工作的同时，我们也开始建模数据了。在以前的项目中，我们使用 Rational Rose 进行设计，并发现在持久类和暂时类之间的分割有点笨拙：一旦我们识别出了一个用于持久存储的类，我们便设置它的持久属性并开始用其他的工具对他建模。在 ASDI 项目中，我们使用了集成在 Rational Rose Enterprise 中的 data modeler 进行数据建模，并且发现过度更加的成熟。 实际上，我们最初在使用老方法上范了一个错误 — 将持久对象放到他们自己的文件夹中，并遗忘了他们 — 但是，我们自己发觉了他们并使用 Rose 将这些对象转换成了数据模型。将所有收集到的持久类放入一个包中，我们可以通过鼠标右键点击包，并转换他们成为数据模型（通过从上下文菜单选择 Data Modeler > Transform to Data Model ）。 数据建模器在 Rose 模型中创建了一个数据库计划。我们后来将这些计划从它的逻辑表示转化成了一个物理的 DB2 安装，并给工程团队访问表和测试数据。 原型 作为架构和设计的基础，良好的分析是重要的，但是原型也是非常有价值的。很多的主意在纸上看起来很好，但我们的假设只有原型才能提供的证据。 工程团队非常喜欢原型活动。典型的对这些活动的时间计划是非常自信的，目标是模糊的，技术是新的，并且 QA 轻松的，因此原型通常是很有趣的 — 金钱的大量浪费。我们发现如果原型没有清晰的、可测量的目标，它很快就会沦落到“我能做什么...”的境地，而不是降低风险的任务。 我们通常尽力与 RUP 的演进产品理论保持一致，RUP 可以指导我们将我们所有的原型演化成最终的产品。事实上，我们对快速的探索保留了术语“原型”。为了从原型中释放出最大的价值，我们经常忽略代码的标准、同级检查和类似的过程。原型的一些方面（类的说明、设计模式或者编码习惯）也许可以被重用，但是我们在重用这一点上给团队非常小的压力。相反，我们的原型的结果通常被总结成为技术注释或者成为可以被活来项目参考的样例应用。 马上，一个工作包必须被起草。对它的开发人员来说这个包能够概括特定原型的目标。我们为每个原型分配了预算和时间计划，这里包括了任务完成之前的中期检查。 我们不总是通过直接的编码来创建原型的。有时我们通过在写任何代码之前进行学习来执行工具的评估。当评估数据库时，比如，我们基于我们的经验、供应商提供的信息和第三方的检查从类表中去掉一些候选工具。 我们发现几种很好的构建原型和工具选择的方法： 审查 （读、反复查看、面谈） 编码 （深入的代码片断可以探察特定的接口、需求或者性能问题，并且明朗的、简洁的代码片断可以显示连接性、工作流和可用性） 原型的安装和演示 工具提供商的演示 良好运用原型的关键在于决定原型的实现的程度。很少有原型能够在推荐中被设计成为给人 100% 的信心。相反，原型必须演示足够的结果以减少风险到可以忍受的级别。 表 2 列出了一些我们在这个项目中采用的特定原型活动。 原型活动 结果 研究（覆盖特性、成本和性能） Orion Application Server 的选择（更多信息，看 第 4 部分 ） OOBD 的评估（覆盖特性和市场份额），以满足客户的偏爱 决定放弃使用 OODB（更多信息，看 第 4 部分 ） 研究关系型数据库（覆盖特性、成本和性能） 选择 DB2 （更多信息，看 第 4 部分 ） JSSE 评估 （覆盖复杂性、稳定性和安全性） 在 B2B 方案中包括 JSSE 用户界面模拟（测试可用性、工作流和“外表感观”） 对于“外表感观，用户界面指南和标准的开发” 在 Rational Rose Enterprise 进行数据建模（使用 Rose 的 data modeler） 熟悉使用 Rose data modeler；生成创建表、触发器等等用于早期原型的数据库教本 XML 探索 （看 相关资源） 并且创建 B2B 接口原型 一致同意良好格式的 XML 比信任第三方的解释器带来的利益或者对丰富标记的 XML 更重要 EJB 与 JSP 和 servlets 的对比 决定在 第 1 阶段使用 JSP 和 servlet 表 2: 原型活动 总结 我们对系统的架构和设计已经相当的成熟；我们的原型取得了巨大的成功，并且我们将很快开始实现的工作。这意味着跟踪项目的过程要比保持项目远景在规定的方向上和仔细的计划每一个迭代和增量更加的重要。 到现在为止，我们已经试验并选出了所有主要的技术和第三方的工具，并且我们非常满意工具提供商能够做他们的工作。我们通过被计划的原型做了这个决定，并且不只是希望或者相信银弹。原型也帮助我们的工程团队，给我们我们具有完成工作的知识和需要的技能。 计划未来 在不久的将来，我们将进入系统的实现中。我们计划实现以下目标: command gateway ，它造成了一些最大的技术风险 图形用户界面，它将为客户提供有用的检查产物 被众多子系统功能需要的一些通用服务 在做任何实现之前，我们必须在多个方面对项目的阶段做准备，包括更新我们团队的结构以满足我们的新需要，文档化代码和设计协定和交流有效的开发方法（包括单元测试和同级检查）。工程团队将需要完全的理解双向工程、调试、分析和其他更多的东西。 主要风险 JSSE 原型指出 JSSE 是一个比我们最初预期的更加复杂的 API 。尤其是，安全方面对项目范围的蔓延产生了巨大的机会，因此我们必须与 ASDI 密切的工作以准确的理解他们需要什么样的安全。来自于需求的工作不会涉及到密钥长度、加密机制和其他底层的细节。 最后，我们在 EJB 之上选择和 JSP 和 servlet ，我们知道我们架构可能需要在第 2 阶段进行一些返工。我们愿意将它作为那个阶段的风险保留，因为我们完全的提交了这个技术选择