指南:为 J2EE 应用程序构造实施模型
本指南讨论了如何为 J2EE 应用程序构造实施模型。
关系
相关元素
主要描述

简介

假定您熟悉有关 J2EE 作为技术平台的常规信息, 概念:Java 2 Platform Enterprise Edition(J2EE)概述概念:从设计到代码的映射中涵盖了这些信息。该指南中的某些概念属于 UML 1.4,但是您可能在基于 UML 1.3 的插件的环境中使用它。如果您理解某些方面很费劲,请查阅这两种 UML 规范在该主题上必须讲述些什么内容。

构造实施模型

任务:构造实施模型描述如何生成与设计模型的结构非常匹配的实施模型结构,但同时反映开发环境的所有限制,并支持并行开发和增量集成。

J2EE 应用程序的实施模型结构依赖于开发和实施环境,但是,通常在 J2EE 实施模型中有四种潜在的结构:

  • 部署支持(J2EE 模块和部署描述符)
  • 虚拟目录结构(JSP、HTML 页)
  • 部署在 Web 服务器上的元素(servlets、JavaBeans)的 Java 目录
  • 部署在 EJB 应用程序服务器上的元素(EJB)的 Java 目录

对实施子系统建模

工作产品:软件体系结构文档中的实施视图提供了实施模型的高级概述。这包括标识实施子系统。在 J2EE 应用程序中,实施子系统可能没有映射到文件系统中的单个目录或模型中的单个包上,因为实施子系统可能包含来自某一个模型的非 Java 元素(例如 JSP 和 HTML 页),以及来自另一个模型的 Java 元素。处理该问题的一项策略是在每个模型中有一个并行的包结构。隐式地关联每个模型中有相同名称的包。

实施子系统通常提供单个可部署实施文件(JAR、WAR 或 EAR 文件)的实施。在此情况中,标识可部署文件可能用于标识实施子系统。

由实施目录和实施文件组成的物理元素说明可能在每个实施子系统中。还可有逻辑元素,逻辑元素由、组件和等组成,并且对应于工作产品:设计模型元素,但它们是源代码的精确模型(往返工程模型)。请参阅概念:从设计到代码的映射以获取关于设计模型实施模型之间关系的更多信息。

往返工程模型提供源代码的精确表示。在 J2EE 中,Java 模型中的每个包表示一个 Java 包,每个类表示一个 Java 类,依此类推。但是,经常需要使用附加信息补充往返工程模型,包括:

  • 显示某种信息的图,这些信息不会作为往返工程的一部分自动产生
  • 模型的较高层抽象

设计模型抽出类、组件和包等等。但是,对于物理元素(文件和目录),可能还需要更高级别的抽象或额外的图示。在以下部分中描述这些内容。

对实施目录建模

往返工程通常仅处理开发环境中所需的目录的子集。 通常需要附加目录来组织测试工件、部署单元和文档等。 通常不需要建模,因为可以将目录看成文件系统的一部分。

对实施文件建模

通常不对实施文件建模,除非往返工程工具提供了一些支持,或需要显示一些不那么明显的关系。

每个 Java 接口或类通常都有一个 .java 文件,而每个 .java 文件都有一个已编译的 .class 文件。 所以,对这些文件建模不是很有意义。

在 J2EE 中,子系统通常包含一个或更多归档文件(JAR、WAR 或 EAR 文件)。

归档文件最适合建模为从该归档文件到它包含的文件的组装关系。但是,当组合已编译的 .class 文件以组成 JAR 文件时,显示从 JAR 文件到它最终实现的类和接口的依赖关系可能更有用。

如果实施子系统仅产生一个 JAR 文件,则可能根本不需要建模;特别是可以假设实施子系统中的所有可部署文件都是 JAR 文件的一部分的时候。

重叠归档文件

通常建议不要定义两个包含某些相同元素的归档文件(虽然这么做是可能的)。例如,两个 EAR 文件可能包含一些(但不是全部)相同的 EJB JAR 或两个 EJB JAR 可能包含相同 EJB。却有不同部署描述符。

最好归档文件不要重叠,以保持实施子系统与可部署归档文件之间的紧密对应性。但是,如果必须重叠,则将该重叠与那些重叠的基本原理建模在一起可能会很有帮助。