JAVA网页设计使用Rational工具简化基于J2EE项目（四...

你通过从书的数量和开发周期及运行速度来证明：net和ruby要比java简单。j2ee|项目第4部分：剖析和工具的停顿

StevenFranklin
软件计划师和历程专家
2004年4月

在这个展现了RUP和其他Rational工具利用的样例项目标接上去的阶段，用例经由过程增加文档和可跟踪性到需求被细化，而且利用的工具和手艺被评价和选择。

这个第4部分文章的重点在于ASDI项目标细化阶段，特别是在用例剖析方面（细化我们的用例以对事情形态（SOW）增加可跟踪性，而且尺度化和天生用例文档）并选择符合的工具和手艺。

第4部分快照
在第4部分演示的工具和手艺：

RationalRose企业版―用于用例细化
RationalSoDA―为客户反省的低本钱的发生用例文档的工具
RationalRequisitePro―用于办理SOW需乞降用例之间的可跟踪性
发生大概被更新的产品：

RationalRose模子―被修正并在用例的各个方面增加了加倍具体的内容
用例呈报―用RationalSoDA从Rose用例中天生
RequisitePro数据库―被更新以包含SOW需乞降用例之间的可跟踪性


细化并文档化用例
显现了在ASDI项目标第1阶段（RUP的初始和细化阶段）中的用例的演变。就像我们在第3部分会商的，我们在初始阶段创立了营业用例，然后在细化阶段的早期将营业用例转换成表现了“今朝的”体系的用例。如今我们是在细化阶段的最剧烈的时候，我们正筹办细化我们的用例，为体系完成向具体需求的转换。这个演进是天然构成的，由于直到判定了是不是我们入手下手界说的用例是准确的，我们才能够为用例举行更加具体的信息增加。一旦具体的体系需求被完成，我们将它作为一个正式的托付物被ASDI检察经由过程。


:第1阶段用例的演进

尺度化用例文档
在我们与ASDI对用例举行非正式的反省的集会中我们对用例举行了正文。用例图和包也被我们的初级团队成员按期的反省了，一个“健全的”反省将带来以下的了局：

将不不乱的大概漏掉的方面反应给组长
有效的剖析倡议、形式和功效分化方面的思索
分歧的体系视图
工程团队对具体需求的交换
我们如今的重点是纪录我们已懂得到的工具。我们与ASDI在用例文档的情势上告竣了分歧，而且我们十分乐意他们乐意承受在Rose模子中对每个用例间接增加文档的体例。这关于我们来讲，事变变得加倍复杂了，由于这意味着更低的对文档美妙的希冀。

在多个团队成员配合事情的情形下，我们发明我们必要尺度化与每一个用例相干联的文档。因而，我们草拟一份用例的文档模板，并使用于Rose模子的每一个用例中。在中显现的内容是被粘贴到每一个用例作为模板的文档窗口。注重我们在这个模板中利用术语“variation”作为对RUP可选流观点的速记标志。


:用例文档模板

在项目标厥后，我们意想到在模子（*.mdl和*.cat）文件中有大批ASCII情势的文档，使模子的加载慢了上去。感激我们的疾速的电脑，这个反作用还能够被容忍，可是在厥后的项目中我们利用了加倍正式的办法来保护用例的内容，经由过程一个自界说接口的体例（就像在文章FineTuningRosetoComplementYourProcess所会商的那样）。另外一个可选的办法是利用Rose附带独自的MicrosoftWord文档到用例的特征（经由过程右键点击用例并从高低文菜单当选择New>File）。

用例的可跟踪性
ASDI本来的希冀是SOW将终极成为一个年夜的笔墨情势的文档。我们经由过程与他们的不休的会商，终极他们意想到这类办法的弱点，并作出了妥协的姿势。他们如今分明了利用用例的优点并很快的把握了相干的观点，并了解了利用用例将给他们一种不必要对模子举行预排的十分壮大并得当的反应的体例。不管怎样，一个好的工夫和精神的分派已进进了SOW，能够了解ASDI但愿我们可以确保不会漏掉任安在SOW中被捕捉的工具。

为了供应这个包管，我们利用了Rational的工具来创建在SOW需乞降我们的相称不乱的用例之间的可跟踪性。起首我们经由过程RequisitePro将Rose模子与被办理的需求文档联系关系起来，经由过程选择Tools>RationalRequisitePro>AssociateModeltoProject并选择SOW。然后我们响应的映照每个用例到主SOW需求，经由过程右键点击用例并在高低文菜单当选择RequirementProperties>New。如所示，我们展现了一个SOW需求列表，并从当选择得当的需求。


:联系关系需求与用例

我们已在模子中创建起了这些联系关系，我们能够跟踪需求到用例，相反也能够。双向的可跟踪性是非常主要的，因而我们既能够发明漏掉的需求也能够发明新增加的需求。漏掉某一需求是不成承受的，跟踪需求到用例可使我们很简单的发明我们的任何漏掉。增加需求而没有明晰的调剂将招致项目局限的伸张并对项目标工夫企图和预算有着负面的影响。为了避免这统统，我们应当跟踪一切的用例到每个存在的SOW需求大概变动哀求。

不像跟踪需求到用例，反偏向的跟踪常常被疏忽，可是我们能够很简单的在Rose中完成这一点。为了扫瞄与一个用例相干联的SOW需求，我们复杂的在Rose模子中右键点击用例，并选择从高低文菜单当选择ViewRequisiteProAssociation。这会弹出一个窗口唆使哪个SOW需求是被选择的用例跟踪的，如所示。假如用例没有被映照到一个SOW需求，底部的两个域将显现“NONE”。我们也能够经由过程RationalSoDA发生加倍庞大的跟踪呈报。


:被Rose呈报的关于一个用例的SOW需求

注重在这个办法中利用一个捷径是主要的。经由过程我们利用的办法，我们能够仅仅能够每次联系关系一个用例到一个需求，反之亦然；但是，一个用例实践上是能够跟踪回到几个需求的，一样一个需求大概散布到多个用例中。我们不用忧?映照多对多的干系。我们间接将用例联系关系到SOW中的需求，可是更好的办法是引进一个被RequisitePro办理的用例规格文档，它包括良多用例需求的笔墨形貌并能够完成多对多的映照。（具体的形貌能够在Rational白皮书UseCaseManagementwithRationalRoseandRationalRequisitePro中被找到。）我们如今以为用例规格文档是我们不该该跳过的主要步骤。

用例文档的反省周期
我们与ASDI都分明文档频仍的反省周期会招致无尽头的轮回下往。停止任何文档都是坚苦的，由于每次浏览文档时反省职员常常会发生一些新的设法。在迭代的办法中，不异的“什么时候停止的”的应战也会呈现在软件的文档和其他义务中。为了满意ASDI对关于停止的体贴，我们形貌了我们对用例文档的反省周期将是甚么样的，我们勉力的借用了RUP中所形貌的观点（见）。


:文档反省周期图

就像你所看到的，我们的每个文档都经由了一系列的迭代。关于我们来讲找到一个工具来撑持它是主要的，我们在RationalSoDA中发明如许一个工具，它同意我们天生Rose模子之外的文档。固然对文档间接做修正是诱人的，可是这将带来文档与模子分歧步的风险。假如你将在一个或其他的文档中投进精神，更好的办法是在模子中投进精神。除你开辟的软件用户手册之外，模子几近是能够在软件被托付后还能够持续被援用和保护的产品。

经由过程利用SoDA，发生呈报是复杂的。为客户的反省天生用例文档，我们从Rose的呈报菜单当选择SoDAReport，这将呈现一个呈报模板的列表，如所示。从中我们选择aRUPuse-casemodelsurvey模板。


:SoDA呈报选择

每个模板供应了一个缺省的呈报（作为MicrosoftWord文档）陪伴一个空的部分和响应的内容表格（TOC）。显现了我们选择呈报的TOC。我们经由过程与ASDI反省TOC入手下手，而且我们检察了我们的用例以决意是不是必要在呈报中依据我们的必要举行符合的裁剪。


: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框架的文档。

在我们体贴的残剩工夫和事情量的成绩上，当我们增添了对所需可以的了解和对手艺熟习后，我们以为预算加倍切合项目情形了。更进一步的手艺探究勿庸置疑的将揭开新的应战。


再说第三点：我并没有提到服务器也要整合，然后是IDE，一个好的IDE能够200％提高开发的速度，就说图形方面：你是经过简单托拽和点击就能实现功能好那。

其实说这种话的人就如当年小日本号称“三个月拿下中国”一样大言不惭。不是Tomjava泼你冷水，你现在只是学到了Java的骨架，却还没有学到Java的精髓。接下来你得研究设计模式了。

Java 编程语言的风格十分接近C、C++语言。

是一种使用者不需花费很多时间学习的语言

当然你也可以参加一些开源项目，一方面可以提高自己，另一方面也是为中国软件事业做贡献嘛！开发者在互联网上用CVS合作开发，用QQ,MSN,E-mail讨论联系，天南海北的程序员分散在各地却同时开发同一个软件，是不是很有意思呢？

应用在电视机、电话、闹钟、烤面包机等家用电器的控制和通信。由于这些智能化家电的市场需求没有预期的高，Sun公司放弃了该项计划。随着1990年代互联网的发展

J2SE开发桌面应用软件比起 VC,VB,DEPHI这些传统开发语言来说，优势好象并不明显。J2ME对于初学者来说，好象又有点深奥，而且一般开发者很难有开发环境。

接着就是EJB了，EJB就是Enterprise JavaBean, 看名字好象它是Javabean，可是它和Javabean还是有区别的。它是一个体系结构，你可以搭建更安全、更稳定的企业应用。它的大量代码已由中间件（也就是我们常听到的 Weblogic,Websphere这些J2EE服务器）完成了，所以我们要做的程序代码量很少，大部分工作都在设计和配置中间件上。

让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，设计模式反复向你强调一个宗旨：要让你的程序尽可能的可重用。

是一种由美国SUN计算机公司(Sun Microsystems, Inc.)所研究而成的语言

让你能够真正掌握接口或抽象类的应用，从而在原来的Java语言基础上跃进一步，更重要的是，设计模式反复向你强调一个宗旨：要让你的程序尽可能的可重用。

还好，SUN提供了Javabean可以把你的JSP中的 Java代码封装起来，便于调用也便于重用。