流行的软件工程过程--Rational统一过程!
RUP提供了一个给角色分配任务和责任的严格方法，在J2EE开发中使用RUP出于以下三个原因：
- RUP以架构为中心；在将资源分配给全面开发之前，它先开发一个可执行的架构原型。
- UP是迭代并基于构件的。
- RUP利用一门工业标准语言——UML，可视化建模系统的架构和构件。
RUP有四个不同的开发阶段：初始、细化、构造和移交。然而，本文从技术角度覆盖了J2EE开发的八个必要活动，主要集中在系统架构。
从8个方面来说明:
- 需求分析：需求分析描述系统应该做什么或不应该做什么使得开发者和客户可以签署一份原始的商业合同。可以使用业务概念、领域术语、用例和用户界面（UI）模型形成功能需求文档。
对于非功能需求，如性能和事务，可以在需求文档附件中详细说明。根据参与项目深度的不同，确定在纸上还是使用HTML建造高层UI模型。 - 面向对象分析：人员构造问题领域模型：类、对象和交互。
分析应该与技术和实现细节无关，并包含一个理想的模型。
因为业务过程的改变比信息技术的改变要慢得多，所以必须要维持一个不含技术细节的纯领域模型。
需求分析中得到主要概念，把这些概念建模为对象，并标识他们的关系，为开发架构，可以使用横向联合部分来设计对象，实现，测试来部署，横向联合部分,一个RUP概念，是指系统的一小部分，他的实现结果是包括前端UI，中间业务及后端数据的完整功能的小系统。 - 架构规格说明：经过需求分析以及面向对象后的领域问题后，
将工作集中在技术策略和架构上。架构是指所有构件组合定义系统的一个蓝图：结构、接口和通讯机制。
架构可以分为：企业级架构，应用级架构 - 企业级架构：包括硬件和软件基础设施，网络部局，开发，测试，生产环境等，反映企业的长期投资。
构件组成：Web浏览器客户端，一个HTTP服务器（Web服务器主表示层，业务逻辑构件），关系型数据库主数据与数据逻辑。
你的系统架构类型依赖于：安全，性能和可靠性的需求，也依赖于客户的财务状况。
架构和设计完全不同，应用架构范围包括，系统主要结构，架构设计模式，可增加构件的框架，主要考滤非功能性方面。
设计主要考滤的是业务用例. 对象设计在架构规范下进行，设计从技术扩展跟修改分析阶段产生的领域对象模型，领域对象模型虽然与技术实现无关，
但依赖于技术因素，包括：平台，语言等等因素。
理论上，为了维持业务对象的基本属性和行为，除非绝对必要，不应该破坏它们。在架构结果的指导下，详细设计工作应该说明所有类的规格，包括必须实现的属性、它们的详细接口和伪代码或操作的纯文本描述。
规格说明应该足够详细使得和模型图结合时，它可以提供所有必须的编码信息。
-------
对象设计模型：在完成对象设计的详细设计后，还需要完成领域对象的对象-关系映射，将领域对象转化为关系模型或对象的数据库表是非常重要的。 - 实现：设计一个规范的架构，跟编写一份详细的高设计是非常重要的事情，不在需求分析定义对象模型，关系模型，对应的数据库表，以后开发过程中的各种规范，极有可能使用开发后期经常的测试功能，甚至可能到最后才发现方向跟结构不合理。
- 验证：
- 装配跟布暑：构件装配和解决方案部署在J2EE开发中特别重要。
- 运行跟维护：用程序到了用户手中，你必须给他们提供培训和文档。
客户可能对不足提出更改，我们的更改应该尽量不影响系统的运行，添加一个新的构件或去掉一个老的构掉，尽量不以关闭运行为前提。
软件架构过程必须做许多架构决定，必须为架构开发描述一个开发过程，在我们开发的多个项目中可能存在一些可通用的需求，在我们的项目周期中应该尽量使用以前项目所生成的成熟的可扩展，可重用的架构，为一系列软件应用提供同属结构和行为的通用框架和可重用软件架构是非常需要的。
可以使用设计模式来扩展参考架构，提供一组J2EE模式目录的蓝图及提从“四人帮”模式都是不错的资源。一旦建立了一个基本的J2EE框架，必须实现一些用例来说明架构确实可以为你的领域服务。可以通过选用捕获系统关键功能的场景来实现，这些场景经常使用来展现关键的技术风险。
从领域分析模型入手，可以将领域对象映射成高层和低层设计模型。如果每件事都按计划运行，那么重新评估风险开始下一个迭代，扩展要考虑的场景并选择更多的场景扩展架构的覆盖范围。经过几次迭代后，原始的架构原型应该变得稳定。识别要购买的构件，要保留的遗留系统和怎样将它们对接。
