4应用 Rational 工具简化基于 J2EE 的项目Word文档下载推荐.docx

4应用 Rational 工具简化基于 J2EE 的项目Word文档下载推荐.docx

《4应用 Rational 工具简化基于 J2EE 的项目Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《4应用 Rational 工具简化基于 J2EE 的项目Word文档下载推荐.docx（12页珍藏版）》请在冰豆网上搜索。

∙第6部分:

详细设计；

早期开发；

双向工程；

早期单元测试

∙第7部分:

继续开发；

早期的构建；

演示

∙第8部分:

单元测试策略；

功能测试；

GUI测试脚本

∙第9部分:

系统构建和测试；

缺陷跟踪；

产品交付

∙第10部分:

项目完成；

结论；

未来的工作

本文中所虚构我们是一家软件公司LookoffTechnologiesIncorporated，我们的客户AudiophileSpeakerDesign,Inc.（ASDI），它雇用我们实现他们最初的IT需求。

对于更详细的信息，参见第1部分。

这个第4部分文章的重点在于ASDI项目的细化阶段，尤其是在用例分析方面（细化我们的用例以对工作状态（SOW）添加可跟踪性，并且标准化和生成用例文档）并选择合适的工具和技术。

第4部分快照

在第4部分演示的工具和技术：

∙RationalRose企业版—用于用例细化

∙RationalSoDA—为客户检查的低成本的产生用例文档的工具

∙RationalRequisitePro—用于管理SOW需求和用例之间的可跟踪性

产生或者被更新的产物：

∙RationalRose模型—被修改并在用例的各个方面添加了更加详细的内容

∙用例报告—用RationalSoDA从Rose用例中生成

∙RequisitePro数据库—被更新以包括SOW需求和用例之间的可跟踪性

细化并文档化用例

图1显示了在ASDI项目的第1阶段（RUP的初始和细化阶段）中的用例的演化。

就像我们在第3部分讨论的，我们在初始阶段创建了业务用例，然后在细化阶段的初期将业务用例转换成体现了“目前的”系统的用例。

现在我们是在细化阶段的最激烈的时刻，我们正准备细化我们的用例，为系统完成向详细需求的转换。

这个演进是自然形成的，因为直到断定了是否我们开始定义的用例是正确的，我们才可以为用例进行更为详细的信息添加。

一旦详细的系统需求被完成，我们将它作为一个正式的交付物被ASDI审查通过。

图1:

第1阶段用例的演进

标准化用例文档

在我们与ASDI对用例进行非正式的检查的会议中我们对用例进行了注释。

用例图和包也被我们的高级团队成员定期的检查了，一个“健全的”检查将带来以下的结果：

∙将不稳定的或者遗漏的方面反馈给组长

∙有用的分析建议、模式和功能分解方面的考虑

∙一致的系统视图

∙工程团队对详细需求的交流

我们现在的重点是记录我们已经了解到的东西。

我们与ASDI在用例文档的形式上达成了一致，并且我们非常高兴他们愿意接受在Rose模型中对每一个用例直接添加文档的方式。

这对于我们来说，事情变得更加简单了，因为这意味着更低的对文档美观的期望。

在多个团队成员共同工作的情况下，我们发现我们需要标准化与每个用例相关联的文档。

因此，我们起草一份用例的文档模板，并应用于Rose模型的每个用例中。

在图2中显示的内容是被粘贴到每个用例作为模板的文档窗口。

注意我们在这个模板中使用术语“variation”作为对RUP可选流概念的速记标记。

图2:

用例文档模板

在项目的后来，我们意识到在模型（*.mdl和*.cat）文件中有大量ASCII形式的文档，使模型的加载慢了下来。

感谢我们的快速的电脑，这个副作用还可以被容忍，但是在后来的项目中我们使用了更加正式的方法来维护用例的内容，通过一个自定义接口的方式。

（就像在文章"

FineTuningRosetoComplementYourProcess"

所讨论的那样）另一个可选的方法是使用Rose附带单独的MicrosoftWord文档到用例的特性（通过右键点击用例并从上下文菜单中选择New>

File）。

用例的可跟踪性

ASDI原来的期望是SOW将最终成为一个大的文字形式的文档。

我们通过与他们的不断的讨论，最终他们意识到这种方法的缺点，并作出了让步的姿态。

他们现在明白了使用用例的好处并很快的掌握了相关的概念，并理解了使用用例将给他们一种不需要对模型进行预排的非常强大并适当的反馈的方式。

无论如何，一个好的时间和精力的分配已经进入了SOW，可以理解ASDI希望我们能够确保不会遗漏任何在SOW中被捕获的东西。

为了提供这个保证，我们使用了Rational的工具来建立在SOW需求和我们的相当稳定的用例之间的可跟踪性。

首先我们通过RequisitePro将Rose模型与被管理的需求文档关联起来，通过选择Tools>

RationalRequisitePro>

AssociateModeltoProject并选择SOW。

然后我们相应的映射每一个用例到主SOW需求，通过右键点击用例并在上下文菜单中选择RequirementProperties>

New。

如图3所示，我们展示了一个SOW需求列表，并从中选择适当的需求。

图3:

关联需求与用例

我们已经在模型中建立起了这些关联，我们可以跟踪需求到用例，相反也可以。

双向的可跟踪性是十分重要的，因此我们既可以发现遗漏的需求也可以发现新添加的需求。

遗漏某一需求是不可接受的，跟踪需求到用例可以使我们很容易的发现我们的任何遗漏。

添加需求而没有清晰的调整将导致项目范围的蔓延并对项目的时间计划和预算有着负面的影响。

为了防止这一切，我们应该跟踪所有的用例到每一个存在的SOW需求或者变更请求。

不像跟踪需求到用例，反方向的跟踪经常被忽略，但是我们可以很容易的在Rose中完成这一点。

为了浏览与一个用例相关联的SOW需求，我们简单的在Rose模型中右键点击用例，并选择从上下文菜单中选择ViewRequisiteProAssociation。

这会弹出一个窗口指示哪一个SOW需求是被选择的用例跟踪的，如图4所示。

如果用例没有被映射到一个SOW需求，底部的两个域将显示“NONE”。

我们也可以通过RationalSoDA产生更加复杂的跟踪报告。

图4:

被Rose报告的对于一个用例的SOW需求

注意在这个方法中使用一个捷径是重要的。

通过我们使用的方法，我们可以仅仅可以每次关联一个用例到一个需求，反之亦然；

然而，一个用例实际上是可以跟踪回到几个需求的，同样一个需求可能分布到多个用例中。

我们不必苦恼映射多对多的关系。

我们直接将用例关联到SOW中的需求，但是更好的方法是引入一个被RequisitePro管理的用例规格文档，它包含很多用例需求的文字描述并可以实现多对多的映射。

（详细的描述可以在Rational白皮书"

UseCaseManagementwithRationalRoseandRationalRequisitePro"

中被找到。

）我们现在觉得用例规格文档是我们不应该跳过的重要步骤。

用例文档的检查周期

我们与ASDI都明白文档频繁的检查周期会导致无止境的循环下去。

结束任何文档都是困难的，因为每一次阅读文档时检查人员经常会产生一些新的想法。

在迭代的方法中，相同的“何时结束的”的挑战也会出现在软件的文档和其他任务中。

为了满足ASDI对关于结束的关心，我们描述了我们对用例文档的检查周期将是什么样的，我们努力的借用了RUP中所描述的概念（见图5）。

图5:

文档检查周期图

就像你所看到的，我们的每一个文档都经过了一系列的迭代。

对于我们来说找到一个工具来支持它是重要的，我们在RationalSoDA中发现这样一个工具，它允许我们生成Rose模型以外的文档。

虽然对文档直接做修改是诱人的，但是这将带来文档与模型不同步的风险。

如果你将在一个或其他的文档中投入精力，更好的方法是在模型中投入精力。

除了你开发的软件用户手册以外，模型几乎是可以在软件被交付后还可以继续被引用和维护的产物。

通过使用SoDA，产生报告是简单的。

为客户的检查生成用例文档，我们从Rose的报告菜单中选择SoDAReport，这将出现一个报告模板的列表，如图6所示。

从中我们选择aRUPuse-casemodelsurvey模板。

图6:

SoDA报告选择

每一个模板提供了一个缺省的报告（作为MicrosoftWord文档）伴随一个空的部分和相应的内容表格（TOC）。

图7显示了我们选择报告的TOC。

我们通过与ASDI检查TOC开始，并且我们查看了我们的用例以决定是否需要在报告中根据我们的需要进行合适的裁剪。

图7:

SoDAuse-casesurvey报告（TOC）

你可能想知道在写任何实际的内容之前，为什么我们担心与ASDI一起检查TOC。

我们发现这是一个重要的步骤。

有时ASDI给我们一个DID（数据项描述），它对正式的交付物提供一个TOC，但是我们发现在开始充实内容之前根据TOC从ASDI（或者内部的团队检查人员）得到信息是有用的。

有时我们在每一个部分填写显示我们将如何细化的标题，但是在首次的TOC检查时几乎没有任何的段落内容。

后续的文章部分将讨论RationalSoDA和模板定制的更加详细的信息。

细化：

不只是用例

为了使生活更加有难度，ASDI期望我们在继续随后的任务之前创建用例文档。

我们必须提醒他们用例文档直到软件被交付才会被“完成”，除非他们不想让我们在需求变化或者新需求出现时更新用例。

我们说服了他们，他们不会对完成的里程碑甚至是自信的里程碑感兴趣。

然而，他们希望放一个检查标记到下一个要做的“详细的用例文档”项，因为它是十分成熟的，我们同意这个观点。

真正的挑战是说服ASDI所有需要的活动应该是并行的发生，而不是所有的里程碑都是按照顺序被交付的。

我们把它作为在项目早期的一个常规的关注点，它仍然没有被完全的解决。

为了让他符合用例分析的一些活动，我们提出了这两个观点：

∙屏幕的模拟将简化需求的检查，并可以比用例讲述一个广泛的经过。

∙没有一些前瞻性的原型，工具获得、安装和培训不应该发生。

我们非常高兴ASDI同意模拟和原型作为分析阶段的有用的部分。

这使我们可以在用例分析被完成前进入到架构的和工具的选择问题中。

选择工具和技术

工具和技术选择从来就不是微不足道的任务，虽然它常常被忽略。

团队经常根据启动成本、“小工具因素”、好奇心或者对工具和技术的忠心来作出选择，相反，他们应该考虑生产成本、可靠性、可得到的培训、团队技能和特性标准。

在评估过程中添加一些正式手续可以确保工具的选择使基于项目需要的而不是个人主观的意见。

正式的工具评估

一个在RUP中很少关注的地方是团队挑选现货（off-the-shelf）—也称作商业现货供应（COTS）—工具的过程。

可以了解这个过程领域知识的一个地方是卡内基－梅隆软件工程学院（SEI），那里有COTS-BasedSystemsInitiative关注于COTS产品的选择和采纳的策略。

特别有趣的是SEI的productfeaturechecklist；

虽然它更关注于选择软件系统的组件和框架，但是其中的很多策略也可以被用于选择软件开发工具、Web服务、数据库等等。

工具选择标准

ASDI向我们展示了这些他们觉得将影响我们的工具选择的标准：

∙他们最终承担系统的核心开发和维护团队包含3到5个人。

∙系统能够被4到7个内部用户和1到5个来自于20到30个公司的外部用户访问（虽然系统的将来版本将支持数千人在线用户）。

∙跨平台技术是重要的，因为ASDI期望在数年中这个系统仍然是可用的。

∙对所有技术的培训必须是容易得到的。

∙他们强烈首选基于Java的解决方案。

∙他们首选OODB（面向对象的数据库）作为数据的存储。

∙系统的早期版本将运行在Linux系统上，虽然之后将运行在Solaris系统之上。

∙开发人员需要能够在Windows2000的机器上有效的使用软件。

∙性能不会是重要的挑战，因为在同一时刻仅有少数的用户与系统进行交互。

应用服务器的选择

我们拥有J2EE应用服务器的经验，因此我们非常幸运ASDI选择基于Java方案。

不过在我们还是快速的评估了象Perl/CGI和PHP这样的入门级的Web方案之后的计算技术（主要是Microsoft.NET/DNA）。

我们一致发现OrionApplicationServer是友好的并是最成本有效的开发环境。

在那里Orion唯一评分低的方面是供应商的稳定性和支持。

提供Orion产品的公司是非常小的并且不具备象BEA的WebLogic或者IBM的WebSphere的能力和信誉。

然而在与ASDI的检查人员讨论后，我们互相同意Orion的J2EE标准遵从的好处足以抵消这些风险。

如果第二阶段开发需要，仔细的开发将可以确保我们拥有轻便的可以移植到其他应用服务器方案的代码。

因此我们选择了Orion—这意味这启动成本为零，因为Orion是免费的。

Web服务器选择

Orion带有高速的内建的Web服务器，因此当Orion被选定后Web服务器的选择过程也就有了结论。

它主要的竞争对手是Apache。

然而，在Orion网站上显示Orion已经在某些测试方面达到并超过了Apache。

数据库选择

使用哪一个数据库的选择不是显而易见的。

数据库通常不会执行高负载，但是它需要有丰富的特性支持。

比如，复杂的数据关系要求有完全的引用完整性限制。

同时，系统必须可以24小时不间断运行，因此我们希望它具有热备功能、复制、其他的可用性和容错特性。

我们是否会用到所有的特性将在以后被决定。

我们觉得PostgreSQL仅仅是一个有资格的开放源码的候选者。

它有很好的ANSISQL支持和引用完整性，并且只要并发用户的增长不太大它可以保持良好的性能。

然而，数据存储需要更多的来自于一个供应商的committed支持。

此外，我们觉得PostgreSQL在线支持（比如用户社区讨论）对我们来说是不够的。

MySQL实际上是更加流行的开放源码的数据库，但是它缺少太多的特性（比如，外键支持）。

然后我们转到主流的数据库：

DB2，Oracle，andMicrosoftSQL。

我们在Oracle上有着丰富的经验，但是新的处理器单元价格模式对于我们的这个应用来说是过于昂贵了。

Oracle的每MHz每CPU的基本负荷，意味着ASDI将为系统忍受高的生产环境成本，除非他们愿意将Oracle安装在一台P-133的机器上。

MicrosoftSQL被淘汰了，因为它是基于私有平台的。

如果创建一个基于DNA的方案，MicrosoftSQL自然是首选的，但是对于J2EE来说很少被选择的。

最后，我们选择了DB2，我们的调查表明DB2对SQL有着非常优秀的支持、强大的容错特性、公道的价格模式和正在增长的和被培训的在线用户集合。

IBM的JDBC驱动是高性能的，而且他们的个人版可以被免费的用于开发团队中。

不幸的是，我们缺乏DB2的技能，这就意味着一些培训在原型活动期间被需要。

你也许正想知道对于ASDI首选的OODB的选择发生了什么。

在通过原型和探索产品后，我们很快个到了结论，使用OODB得到的好处不足以抵消它带来的风险。

集成开发环境（IDE）选择

在这一点上，我们不想使用任何高端的IDE产品，有几个原因：

∙我们并不明确第1阶段概念的证明需要使用EnterpriseJavaBeans。

∙IDE的投入是昂贵的。

∙团队的成员已经有了他们自己的选择。

∙因为第1阶段的时间是很紧的，使用如IBM的VisualAge所带来的学习曲线是我们无法承受的。

相反，我们混合使用了以下工具：

∙JCreator—免费的基于Java的IDE

∙CodeGuide—低成本的IDE

∙log4j—简化服务器端调试的日志工具

∙Jikes—快速严格的Java编译器

很自然，这些工具可通过使用Rational工具来弥补在测试、调优和代码覆盖上的缺乏。

总结

在这个阶段我们看到了用例的演进（通过可跟踪性和文档化）并且通过ASDI参与的用例的检查，我们快速的发现我们是自由主题方式的专家。

这通常是软件开发项目中的最大挑战之一，因此早期的并有效地建立这种关系才是真正的胜利。

我们与ASDI的关心通常是很好的。

他们很快的理解并同意了基于RUP的开发过程而没有花费我们太多的精力。

这是令人惊讶的，被他们给的首选的瀑布型的开发最终取得了这个和约。

很多被RUP鼓励的迭代和增量开发的方法被良好的进行了调整，并且ASDI也看到可好处。

我们幸运的是工具的选择相当的简单，并在项目的早期被完成。

Rational的一些工具被用来节省我们的时间。

在之前的项目中我们使用Excel来管理需求，但是我们发现RationalRequisitePro是一流的并是完整的方案。

此外，RationalSoDA报告可以大大的降低我们的文档生成的成本。

因为这个项目是我们第一次使用SoDA，我们非常高兴ASDI对标准的SoDA模板表示满意。

计划未来

到现在为止，我们把焦点放到了需求相关的产物上，并且花费了相对来说不多的时间来评估技术并创建原型以支持工具的选择。

现在对我们来说重要的是通过创建更有挑战的原型来揭示系统更加复杂的领域，并开始在实际的开发中使用工具。

我们是否会用到XML？

如果会用到，我们应该使用什么样的解释器？

我们需要什么样的安全机制？

我们应该使用EnterpriseJavaBeans吗？

象这些问题我们将很快有答案。

换句话说，是时候从分析转移到架构和设计了—尽可能快而不是晚，因为大多数的技术风险将在接下来的几周显现出来。

我们有一个很好的功能基线包含一系列定义良好的用例。

对于我们来说避免分析麻痹大意和维护前进的动力是重要的。

主要风险

没有新的风险被识别出来；

实际上我们的风险列表比以前更短了。

因为ASDI同意对于这个项目OODB是不合适的，我们因此不再有技术上的风险要管理。

他们也放松了对我们的交付产物的正规形式和他们预想的结构，并且他们毫无保留的批准了我们的基于RUP框架的文档。

在我们关心的剩余时间和工作量的问题上，当我们增加了对所需能够的理解和对技术熟悉后，我们觉得预算更加符合项目情况了。

更进一步的技术探索勿庸置疑的将揭开新的挑战。