Topics

Introduction To top of page

These guidelines supplement Guidelines: 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 Guidelines: Enterprise Java Beans.

Note also that an Application Client is considered to be a specialized Design Subsystem. See Guidelines: Application Client.

Evolving Design Subsystems To top of page

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.

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. 

Diagram described in accompanying text.

Figure 1: Preliminary Design-Customer Subsystem

ICustomerMgt is further defined to have operations, such as "getCustomerDetails" and "setCustomerDetails".

As the design becomes more detailed (activity: 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 Concepts: Mapping from Design to Code for a discussion of these options.) The corresponding design use-case realizations 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:

  • ICustomerMgt =>
    • CustomerHome ?EJBEntityHomeInterface?
  • ICustomer =>
    • Customer ?EJBRemoteInterface?

Diagram described in accompanying text.

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 Guidelines: 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 Guidelines: Interfaces for J2EE Applications. For more information on modeling EJBs, see Guidelines: Enterprise JavaBeans.

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?
  • CustomerBean ?EJBImplementation?
  • 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 Guidelines: Enterprise JavaBeans. 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 Guidelines: Enterprise JavaBeans for more information on DAO classes.

Diagram described in accompanying text.

Figure 3: White-box View of the Customer Design Subsystem



Rational Unified Process   2003.06.15