These guidelines supplement Guideline: Design Subsystem with guidance specific to
J2EE application development. We recommend you read Guidelines: Design Subsystem prior to reading these J2EE-specific
guidelines. These guidelines apply to design subsystems of larger granularity than individual EJBs. For guidelines on
EJBs, refer to Guideline: Enterprise JavaBean (EJB).
Note also that an Application Client is considered to be a specialized Design Subsystem. See Guideline: J2EE Application Client.
Evolving Design Subsystems
When a subsystem is first identified, it may initially be technology neutral. That is, it may be specified by
interfaces, a textual description, and some state machines that describe the expected behavior of the operations.
However, such technology-neutral subsystems are typically evolved to technology-specific representations.
The following gives an example of how a technology-neutral design subsystem is evolved to a technology-specific
Subsystem specification (Black-box view of the subsystem)
A subsystem specification can initially be modeled as having abstract UML interfaces.
Consider the preliminary design of a Customer subsystem, shown in Figure 1.
Figure 1: Preliminary Design-Customer Subsystem
ICustomerMgt is further defined to have operations, such as "getCustomerDetails" and "setCustomerDetails".
As the design becomes more detailed (Task: Subsystem Design),
these abstract interfaces are replaced by language and technology specific elements. (You can choose to maintain the
more abstract model of the subsystem; for example, if there's a need to implement the same design in more than one
language or technology. See Concept: Mapping from Design to Code for a discussion of
these options.) The corresponding design Artifact: Use-Case Realization are
updated to match the interface changes.
In this example, Figure 2 is a black-box or specification view of the Customer subsystem. Subsequent design indicated
that the Customer subsystem should be an entity EJB. The preliminary design subsystem is transformed into EJB
interfaces as follows:
Figure 2: Black-box View of the Customer Design Subsystem
The interfaces exposed by Design Subsystems might include regular Java interfaces, EJB interfaces (such as Java
Interfaces), EJB interfaces (remote and home), or even one or more delegate or access classes that hide
the existence of one or more EJBs entirely. Note that all of these, including Java interfaces, are modeled as UML
classes and not UML interfaces (see Guideline: Interfaces for J2EE Applications). For
example, a session bean is often used as a facade for accessing a set of closely related entity beans. In this case,
only the session bean's interfaces would be exported from the subsystem.
Message-driven beans consume messages asynchronously from a destination (or endpoint). Therefore, a destination could
also serve as an "interface" for a Design Subsystem that contains message-driven beans.
Note that since local interfaces are used by other closely-coupled EJBs within the same Design Subsystem and, they
appear in the realization of subsystems more often than in the visible interfaces exposed by a subsystem.
For more information on interfaces in a J2EE application, see Guideline: Interfaces for J2EE Applications. For more
information on modeling EJBs, see Guideline: Enterprise JavaBean (EJB).
Subsystem realization (White-box view of the subsystem)
Design Subsystems should expose only what clients require. Therefore, the class that implements an EJB is private
to the subsystem, and is logically part of the subsystem realization. The subsystem realization could become:
a set of collaborating EJBs and classes, hidden by a one or more visible delegate or access classes
a single EJB with no other collaborating classes
Continuing the previous Customer subsystem example, the realization of the subsystem includes:
CustomerEntityEJB (component) ?EJBEntityBean?
additional helper classes
Figure 3 shows a white-box view (that is, within the subsystem) of the Design Subsystem. Note that the EJB
classes are modeled as described in Guideline: Enterprise JavaBean (EJB). This internal view
of the subsystem is referred to as the subsystem realization. In this view, we see decisions not visible to clients.
For example, in this realization of the subsystem a Data Access Object (DAO) class accesses persistent data using the
JDBC API. (In another design, container-managed persistence might have been used.) See Guideline: Enterprise JavaBean (EJB) for more
information on DAO classes.
Figure 3: White-box View of the Customer Design Subsystem