J2EE架构师手册中文版－第二章

这段时间有些忙,所以看这本书的时间也少了,翻译也慢了,不过我不会停止的:)
[b]第一部分 - 计划J2EE应用

[color=red]第二章 定义项目[/color]

概述[/b]

开发任何应用程序的第一步都是进行分析从而定义出项目的目标以及应用范围,J2EE应用也不例外.在开发进程中对实际应用进行分析是最基本的认识,但我发现很多项目是混乱的,没有首先定义出需要完成的目标.

架构师并不直接的定义项目,这是由项目经理,业务分析员和最终用户来确定.架构师负责确保项目定义是否一致以及是否定义的足够详细以便能进行设计和实现.J2EE开发组的其他成员并不清楚哪些东西是必须用于设计和实现应用的,架构师通常让帮助大家讨论得到较好的项目定义.

[b]架构师必须要有分析的技能.[/b]没有分析的技能,架构师就不能意识到项目定义中的一些弱点.缺少分析的项目虽然可以在建立的过程中发现大多数的错误,但这样做付出的代价是昂贵的.

我听到过许多开发人员都在抱怨我所说的,技术人员希望听到更多的是编码技术,而不是项目的定义和分析策略.我完全理解.没有什么比书写出有用的代码更重要的啦,不过要写出良好代码需求有很好的分析和完善的项目定义.根据我的经验,想要得到良好代码而没有进行很好的分析的可能性几乎没有.

[b]用例是很重要的分析工具[/b].UML(统一建模语言)被用于描述,分析,设计面向对象语言所建立的系统,如JAVA语言.主要是建立UML来描述应用系统将要完成的事.这一章定义了用例这个术语,指导你通过建立项目的用例,列出了通常建立用例时会出现的错误以及如何去避免它们,并且讨论了一个项目的用例的例子.

这一章并不是UML规范的用例的完整说明,我只是它的其中的一个子集,这子集是实际工作中要用到的.要看完整的描述,去看看Booch, Rumbaugh, and Jacobson (1999).

一些开发人员区分用例和需求,但是在我看来这没有什么不同.需求是特别的,用商业术语来书写,一个应用必须要提供这些.因此,需求是用例的总结书写形式.

如果你使用极限编程(XP),那你编故事比用例更好,尽管如此,你将仍然发现这章是很有用的. 尽管编故事相对于UML用例能够表现出更强的细粒度,我认为故事和用例的构造在概念上是统一的.主要的不同在于故事的细粒度能让两个程序员在三周内去实现它,而一个程序员要去实现一个用例则通常需要更多的时间.

[b]另外,我喜欢用户界面原型化.[/b]原型是一个优秀的设计手段,它能让客户和开发人员了解到项目的目标是什么.我通常让客户对原型感兴趣而没有任何困难,因为它代表了客户需要的一些东西.原型也可以帮助优化用例.

一旦你定义了项目的用例(或故事),你能清楚用商业术语来定义项目的细节,这样开发人员和业务人员都能看懂.可以让客户以及任何的管理层都能尽早的提供反馈信息,在项目中从用例得到形式化的信息能使项目经理更好定义项目范围.


第二章完