IV、对象设计

在体系规范的指导下，设计可在技术上扩展和适应分析的结果。分析阶段时，域对象模型化应该和技术的细节无关，而对象设计时则是和技术因素密切相关的，包括在体系开发阶段时，采用哪一类的平台、语言和厂家。理论上，你不要修改商业对象，除非是为了维护它们基本的属性和行为而必须这样做。

在体系决议的指导下，一个详细的设计说明应该提到所有类的规范，包括必要的实现属性，它们详细的接口和伪代码或者操作的纯文本描述。规范的详细程度应该达到只要和模型框图结合，就可得到所有必要的编程信息。在许多自动化的软件生产流程中，你可以从面向对象的框图中产生代码的框架。要注意的是stub和skeleton通常是无需在框图中展示出来的，因为它们对于设计者和编程者来说都是透明的。我在图6中包含它们只是为了说明EJB的基本点。

    在你完成详细的对象设计后，你就完成了域对象的对象相关映射。这样做的原因是，虽然面向对象的方法论在目前是比较先进的，不过最流行和持久的商店都是关系型的。此外，一个客户的IT架构在许多方面都已经反映了现有的投资和商业RDBMS厂家的选择。因此将域对象模型转换为关系模型或者数据库表是非常重要的。有很多容器管理的工具，不过它们不能代替一个好的关系数据库设计。

V、实现

有了一个好的架构和细节设计，实现将是一个很清晰的任务。此外，由于我们在体系原型阶段设计和实现了系统的一个垂直部分，因此在实现阶段我们不会碰到很多麻烦事情。在许多公司中，开发者通常都是过早进入实现阶段，特别是当经理在监视他们的时候，因为对于他们，做其它的事情等于浪费公司的时间。

结果是，不再花时间来画UML框图，而是在代码开发中测试想法，这要花数星期和几个月的时间，在这种情形下，所有的体系决议和设计都是在代码阶段作出的，通常要在几个月后才会发现开发已经进入了一个错误的方向。

VI、确认

确认包括有测试以验证该系统符合设计并且满足需求。在整个开发周期中，验证发生在开发和安装阶段。单元测试、集成测试和用户容忍度测试都是重要的主题。

VII、组合和配置

组件装配和方案配置在J2EE的开发中是特别重要的。开发和安装的环境可能是完全不同的。如果EJB处在系统中，你需要使用厂家的专门工具来提出产生容器的类，上面我也提到过，Web或者应用组件的配置对于不同的厂家都是不一样的。你还必须考虑要配置的系统是否拥有任何厂家指定的代码实现。在一个可扩展的体系中，系统的结构应该是稳定的，但是应该可以支持增加配置新的或者旧的组件，而无需影响整个系统。

VIII、运作和维护

在最后的阶段，应用交付到用户的手中，你必须为他们提供培训、文档和教育。用户将会发现问题和可能会提出新的改进。你必须通过正确地修改管理过程来处理这些需求。你无需为了配置一个新的组件或者替换一个旧的组件而关闭一个正在工作的系统。

体系开发流程

我们必须做许多体系的决定，因此我们必须整理出一个体系开发的流程。对于一个企业来说，通常有许多应用项目，其中的一些甚至会跨越几年，从而导致系统围绕许多周期而变化。在你的领域中，许多同样的项目中都会出现同样的需求。你应该很容易地重新使用一个扩展的和可重用的体系，它们可能在上个项目周期或者其它的项目中。这样会有一个对普遍架构的需求，可重用的软件架构可为家族式的软件应用提供一个普遍的架构。

如果这是你的首个J2EE项目，你的体系必须被原型化，进行测试、分析，然后再重复。BluePrint提供了许多好的设计指导方针和最佳的练习，宠物店的例子也是一个很好的参考体系。要很快地提出一个好的并且是高质量的解决方案的有效方法是使用和扩展BluePrint参考体系，然后插入到你自己的商业组件中。

使用参考体系

就我的理解来说，宠物店体系的本质是Model-View-Controller和Command模型。你可以将这些模型应用到以Web-centric和EJB-centric的系统。对于每个域对象，一个视图是用嵌套的JSP表现。一个controller处理与商业相关的事件，而域对象封装商业逻辑、事务和安全。我们使用前台的servlet作为中央的controller，以接收和解释所有用户的操作。它分派商业事件到指定的域对象controllers，这些controllers可调用域对象来改变持续的状态。根据这个事件处理的结果，一个controller选择下一个显示的视图。以下的组件对于体系都是很重要的，我们可以修改并且应用在大部分的J2EE应用：

MainServlet: 前台的组件是Web容器和该架构之间的接口

ModelUpdateListener: 是获取模型更新事件的对象的接口

ModelUpdateNotifier:在更新模型事件发生的时候通知监听者

RequestProcessor: 处理由MainServlet接收的全部请求

RequestHandler:plug-n-play请求处理器组件的接口

RequestHandlerMapping:包含有请求处理器映射规则

RequestToEventTranslator:根据请求处理器的映射规则，中央请求处理器委派请求处理到plug-n-play请求处理组件。到商业事件的透明http请求

EStoreEvent: 商业事件

ShoppingClientControllerWebImpl: Proxy-to-EJB层前台控制器

ScreenflowManager: 控制屏幕流，选择视图

ModelUpdateManager: EJB层模型更新管理器，通报由于一个事件而导致的模型修改

ShoppingClientControllerEJB: EJB层前台，为EJB客户提供远程服务

StateMachine:中央事件处理器，根据状态处理器的映射规则，委派事件处理至plug-n-play处理器组件

StateHandler: EJB层状态处理器接口

StateHandlerMapping: 包含状态处理器映射规则

扩展参考体系

BluePrint的例子应用是一个好的起点，你还应该修改它以配合不同的项目和领域。设计模型是可重用的微体系，你可以使用它来扩展参考体系。BluePrint提供了一个非常有用的J2EE模型目录，而23个“Gang of Four”模型都是极好的资源。例如，如果你想扩展参考体系以支持工作流管理，你可以在配置或者运行时使用中央controller来动态注册事件处理器。中央controller要求每个注册的事件处理器处理一个事件，直到一个处理器返回一个指示已经到达命令串末尾的信息。

插入你的商业组件

J2EE技术对于每个人都是一样的，但是对于不同的领域，我们需要解决的问题都是不同的。一旦你建立了一个基本的J2EE框架，你就必须利用一些use cases来展示该体系可为你的领域工作。你可以通过选择一些情形，最好是该系统的一个重要的功能，或者使用得最多的而且可带来明显的技术上的冒险的情形。由域分析模型开始，然后尝试映射你的域对象到高端和低端的设计模型，就象我们在图5和6中的所示。实现低级别的设计模型，并且测试看它是否真正地运作。如果所有都如设想般运作，你就可以再重复上一步，即找冒险的情形、更多的设想来测试以扩展体系的覆盖。在经过反复的验证后，初始化的体系原型应该就会变得稳定。你可以认识到哪些组件是可以购买的，旧系统的哪些方面是应该保留的，以及如何为它们做接口。下一步就是软件设计，你可以使用设计指南中指定的类似方法和流程来进行继续的开发。

按部就班

我们使用了一个流程的形式，将一个复杂的问题分解为几个小的部分，以便我们能更容易地理解和解决它们。在这篇文章中，我们将J2EE的开发分解为8个步骤，集中介绍了体系和设计。我这里介绍了重要的体系主题和作出体系决定的一个流程。我还讨论了J2EE体系的角色和可交付。

学习通过这些步骤来开发J2EE的方案就象学习舞蹈一样。你首先需要自觉和坚持不懈地练习基本的舞步。一旦你熟悉了它们，你就会想到将它们放在一起，并且更集中在曲子里每步的大小、速度、流和节奏。不过你不应该被一个流程来限制你的创造力。相反，你应该使用和扩展该流程来满足你的特定需要。要记住，你的最终目标是设计出一个完整的J2EE方案来满足你的客户需求。