Introduction

It is assumed you are familiar with general information on J2EE as a technology platform, covered in Concept: Java 2 Platform Enterprise Edition (J2EE) Overview and Concept: Mapping from Design to Code. Some of the concepts in this guideline belong to UML 1.4, whereas you may be using it in the context of a UML 1.3-based plug-in. If you have a hard time making sense of something, check what the two UML specifications have to say on the matter.

Structuring the Implementation Model

Task: Structure the Implementation Model describes how to produce an Implementation Model structure that is strongly aligned with the structure of the Design Model, but, at the same time, reflects any development environment constraints, and supports parallel development and incremental integration.

The Implementation Model structure for a J2EE application is dependent on the development and implementation environment, however, in general, there are four potential structures within a J2EE Implementation Model:

• Deployment support (J2EE modules and deployment descriptors)
• Virtual directory structure (JSPs, HTML pages)
• Java directory for elements deployed on a Web server (servlets, JavaBeans)
• Java directory for elements deployed on an EJB application server (EJBs)

Modeling Implementation Subsystems

The Implementation View in the Artifact: Software Architecture Document provides a high level overview of the implementation model. This includes identifying the Implementation Subsystems. In a J2EE application, the Implementation Subsystems might not map to a single directory in the file system or a single package in a model, because the Implementation Subsystem might include non-Java elements from one model (such as JSPs and HTML pages) and Java elements from another. One strategy for handling this is to have a parallel packaging structure in each model. Packages with the same name in each model are implicitly associated.

It is common for an Implementation Subsystem to provide the implementation for a single deployable Implementation File (a JAR, WAR, or EAR file). In this case, identifying the deployable files might serve to identify the Implementation Subsystems.

A representation of physical elements, consisting of Implementation Directories and Implementation Files, might be within each Implementation Subsystem. There could also be logical elements, consisting of classes, components, packages, and so on, that correspond to the Artifact: Design Model elements, but are a precise model of the source code (a round-trip engineering model). See Concept: Mapping from Design to Code for more information on the relationship between the Design Model and the Implementation Model.

Round-trip engineering models provide a precise representation of source code. In J2EE, each package in a Java model represents a Java package, each class represents a Java class, and so on. However, there is often a need to supplement round-trip engineering models with additional information, including:

• diagrams that show information not automatically produced as part of round-trip engineering
• higher level abstractions of the model

The Design Model abstracts classes, components, packages, and so forth. However, there might also be a need for higher level abstractions or additional diagramming for the physical elements (files and directories). These are described in the subsequent sections.

Modeling Implementation Directories

Round-trip engineering generally handles only a subset of the directories required in the development environment. Additional directories are often needed to organize test artifacts, deployment units, documentation, and so on. Generally no modeling is required, as directories can be viewed as part of the file system.

Modeling Implementation Files

Implementation files are generally not modeled unless some support is provided by a round-trip engineering tool or some not-so-obvious relationships need to be shown.

There is generally one .java file for each Java interface or class, and one compiled .class file for each .java file. So, modeling these files is not of much interest.

In J2EE, a subsystem usually contains one or more archive files (JAR, WAR, or EAR files).

Archive files are most correctly modeled as a composition relationship from the archive file to the files that it contains. However, when compiled .class files are combined to make up a JAR file it might be more useful to show a dependency from the JAR file to the classes and interfaces that it ultimately implements.

If the Implementation Subsystem only produces one JAR file, then perhaps no modeling will be necessary at all; especially if all deployable files in the Implementation Subsystem can be assumed to be part of the JAR file.

Overlapping Archive Files

It is possible, but generally not advisable, to define two archive files that contain some of the same elements. For example, two EAR files might contain some, but not all, of the same EJB JARs; or two EJB JARs could contain the same EJBs, but have different deployment descriptors.

It's best that archive files do not overlap to keep a close correspondence between the implementation subsystems and deployable archive files. However, when overlapping is necessary, it might be helpful to model this along with rationale for those overlaps.