The first step is to examine how a mechanism will be used, and identify the available design and implementation alternatives.

Let's consider two mechanisms from our list–persistency and presentation request processing.

Persistency is a mechanism that is used in two different situations:

For both situations, the J2EE platform provides various design and implementation alternatives (or strategies). For short-term (user session) persistency, there are at least two strategies: (1) we can store the data in an HTTP session object that is managed by the Web container or (2) we can store the data in a stateful session EJB managed by the EJB container. For long-term (application data) persistency, we can store the data in a database or in a file. If we decide to use a database, we still have two options: (1) use container-managed persistence (CMP) or (2) use bean-managed persistence (BMP).

Presentation Request Processing is a mechanism that ensures that we handle the user requests coming to the system over the Web in a consistent way. The Front Controller J2EE design pattern (Alur et al. 2001) provides us with a design alternative, which is shown in Figure 8.4^[2].

Figure 8.4. Participants in the Front Controller J2EE Pattern

This design alternative recommends that all user requests come to a single element (the Controller). It is the responsibility of the Controller to determine if a request is legal before it is processed. As shown in Figure 8.4, there are two implementation strategies that we need to consider: (1) implement the controller as a servlet («HttpServlet») or (2) implement the controller as a JSP («ServerPage»).

These two examples illustrate that there are usually different alternatives for how we can design and implement a mechanism. In order to choose between those alternatives, we inventory (make a list of) them. RUP refers to the design alternatives as Design Mechanisms and the implementation alternatives as Implementation Mechanisms. Table 8.2 summarizes some of the alternatives we considered for the Online Auction application.

It is hard to give a general set of rules for selecting a design and an implementation mechanism from those identified in the previous step. Some choices may be obvious, while others may not. Some may be relatively equivalent, while others may have more far-reaching implications. For example, selection of the Front Controller J2EE design pattern to handle Web requests has many implications. One of them illustrates, that design and implementation mechanism choices are not independent. As we briefly discuss in Table 8.3, the choice of how to handle the user's presentation requests in the Web container influences the choice of how to handle user-session persistency. If you are the Software Architect, it is your responsibility to make these selections. Table 8.3 shows the choices we made for our Online Auction application (we only list the mechanisms for which we identified multiple design and implementation alternatives).

The results of this activity, such as Table 8.3, which documents the choice of mechanisms, should be captured in the Software Architecture Document^[3]. Details, such as sample interaction diagrams, usage rules, information about the participants, common parameters, and so on, should be documented in the Design Guidelines.

Within our architecture, Design Subsystems are used to represent enterprise components. We use enterprise components to encapsulate business behavior as well as access to, and the management of, system data. The best place to start looking for the application's enterprise components is the set of Analysis Classes (control, boundary, and entity classes) that were identified during the Use-Case Analysis activity.

Some general guidelines for identifying enterprise components are as follows.

Each group of responsibilities that we identify by following the above guidelines becomes a base from which we can derive the Interface of an enterprise component. As we work through the above steps, we should start putting information into the Design Model, as described here.

Let's illustrate the process with an example. During the Architectural Analysis activity, we defined the key abstractions of our Online Auction application, and we put them in the “Key Abstractions” package of the Design Model as shown in Figure 8.9. Unlike other Analysis Classes that we don't intend to maintain after they have been used to identify and define the design elements, we will keep the key abstractions as the base of the system's information model.

Figure 8.9. Root-level Packages of the Design Model

The key abstractions we have identified are shown in Figure 8.10.

Figure 8.10. The Key Abstractions Identified During Analysis

We have divided the entities into two groups:

Our initial design assumption is that we will have an enterprise component that manages each group. We name these components User Account Manager and Auction Manager as we show in Figure 8.11. We will discuss the other two components, Credit Service and Sign In Logger, shortly.

Figure 8.11. Enterprise Components in the Online Auction Application

We show the resulting organization of the Design Model^[7] in Figure 8.12. The newly identified enterprise components reside in the Business layer of the model.

Figure 8.12. The Business Layer in the Design Model Structure

Now we need to look at the analysis Use-Case Realizations to come up with groups of responsibilities, which will become the first approximation of the Interfaces of the enterprise components. Let's consider the Auction Manager enterprise component. This enterprise component will be involved in the realization of the auction-related Use Cases (Create Auction, Browse Auction Catalog, Place Bid and Close Auction). In Figure 8.13 we show a sequence diagram of the Create Auction Use Case basic flow of events. We captured the sequence during analysis.

Figure 8.13. Create Auction Basic Flow of Events from Analysis

The place to look for the responsibilities of enterprise components, is the methods of the controller Analysis Classes. The sequence in Figure 8.13 shows two responsibilities that the Auction Manager enterprise component will have to fulfill (see the messages to the CreateAuctionController instance):

It is important to notice that the CreateAuctionController communicates with the User Account entity to see if the seller has pending payments. Since the entity is not in the group of entities managed by the Auction Manager enterprise component (see Figure 8.10), we assume that the //has pending payment message in Figure 8.13 represents a responsibility of the User Account Manager enterprise component.

After looking at the basic and alternative flows of the Create Auction, Browse Auction Catalog, Place Bid, and Close Auction Use Cases, and also at the requests to the Auction Manager from other Use Cases, we have arrived at the initial set of Auction Manager enterprise component responsibilities shown in Table 8.4. For clarity, we have grouped similar responsibilities.

The last step of identifying an enterprise component is placing its initial Interface description in the Design Model. The result is shown in Figure 8.14. We have created an Interface that has the same name as the enterprise component, and that has an operation defined for each responsibility of the enterprise component. These operations are revisited in the Detail the Design workflow detail.

Figure 8.14. Auction Manager Interface Description

There are two other enterprise components in Figure 8.11. The Credit Service component is an example of a boundary analysis class representing an external system that evolved into an enterprise component during design. This happens if a boundary class handles nontrivial connection logic. For example, elements of our system may issue concurrent requests to an external system, but that system may be able to process them only sequentially. In such a case, it will be the responsibility of such a “boundary” enterprise component to queue the requests, invoke the service sequentially and then return the results to the appropriate clients. The Credit Service component is used by the Auction Manager enterprise component to charge the Seller a transaction fee when his or her auction is closed with a winning bid.

The Sign In Logger enterprise component, also shown in Figure 8.11, is used by the User Account Manager component during the sign-in process to log who has signed into the system and when they signed in.

The following list gives a few simple and useful checkpoints for evaluating the result of the Identify Design Subsystems and Their Interfaces step.

Looking at the above checkpoints and at the Table 8.4, you may be asking if we should have one Auction Manager enterprise component or four smaller components each responsible for one identified group of responsibilities. We have decided to have one component mainly because of its relatively small size.

As we explained earlier when discussing the granularity of the design elements, in our architecture, Framework Components represent EJBs.

Our architecture provides heuristics for identifying entity and session EJBs associated with enterprise components. The heuristics we used are summarized below.

For each enterprise component:

Let's illustrate the process using the Auction Manager enterprise component as an example. For this component, we create a façade session EJB called AuctionManagerEJB. Figure 8.15 shows the UML representation of this EJB. We represent EJBs as UML components with an appropriate stereotype (such as «EJBEntityBean» or «EJBSessionBean»)^[8]. Entity and Session EJBs expose both a home and a remote Interface, which we represent as UML classes^[9] with the appropriate stereotypes applied. The bean implementation class has the stereotype «EJBImplementation». The «reside» dependency is drawn between the UML component and the classes that comprise the EJB.

Figure 8.15. The UML Representation of the Auction Manager Session EJB

If you go back to Figure 8.10, you will see that we decided that the Auction Manager enterprise component should manage four entities: Auction, Auction Item, Bid, and Category. We could represent each entity as a separate entity EJB, but we know that each Auction always contains one and only one Auction Item. Hence we have decided to put both entities into one entity EJB (AuctionEJB) that will store both auction and auction item information. The EJBs we have identified are shown in Figure 8.16.

Figure 8.16. Auction Manager EJBs

Let's also make an assumption that the Auction, Bid and Category entity EJBs will always run in the same container as the associated AuctionManager session EJB. As a result, the EJBs provide local (rather than remote) EJB interfaces, as described in Chapter 2, An Introduction to the Java 2 Platform, Enterprise Edition.

The resulting Design Model structure we use to capture the identified Framework Components is shown in Figure 8.17. As you can see, we place all elements associated with a particular EJB in the same package.

Figure 8.17. The Auction Manager Enterprise Component-Related EJBs

This is the last step of the Identify Design Elements activity. We showed how to identify the Design Subsystems (the enterprise components) and the Framework Components (the EJBs). What is left is to identify Design Classes. As before, our architecture greatly simplifies that task. If you look at Figure 8.7, you can see that there are only a few kinds of Design Classes in our architecture:

We can defer the discovery of any other classes, such as additional “helpers,” until detailed design and implementation.

Let's start from the Presentation layer. We know that we have only one front controller in the system, so we create a class PresentationRequestController, stereotyped as «HttpServlet». We place it in a “Common Elements” package in the Presentation layer package of the Design Model. Now, for each Use Case we do the following (see Figure 8.7 for reference):

The results of applying the above rules for the Create Auction Use Case are shown in a fragment of the Design Model shown in Figure 8.18.

Figure 8.18. Design Model Structure Showing Design Classes in the Presentation Layer

The CreateAuctionDispatcher class is the use-case dispatcher, and the auction_create_success, auction_info, and auction_info_confirmation server pages are associated with the Screens from the Create Auction Use-Case Storyboard.

We now consider the Design Classes in the Business layer. Following our architectural guidelines we can identify some of the key classes that will be part of the identified enterprise components. For each enterprise component we do the following (see Figure 8.7 as a reference):

The results of applying the above rules to the Auction Manager enterprise component are shown in a fragment of the Design Model in Figure 8.19. The AuctionManagerDelegate and the AuctionManagerHomeLocator classes are the component's business delegate and service locator classes, respectively. The AuctionValues and ItemValues classes are used to pass the entity EJB values to the clients of the enterprise component.

Figure 8.19. Design Model Structure Showing Design Classes in the Business Layer

In Figure 8.20 we show another view of the identified classes. It is a view from the perspective of a particular Use Case and can be thought of as an instantiation of the patterns shown in Figure 8.7. All classes in Figure 8.20 participate in the Create Auction Use Case. We will discuss use-case participants and interactions between them in more detail in the Use Case Design activity of the Detail the Design workflow detail.

Figure 8.20. Participants in the Create Auction Use Case

At that beginning of describing this activity, we mentioned that we decided to use the Composite View pattern to organize the view classes (see Figure 8.5). We can now explain this in more detail. The essence of the pattern is that use-case dispatchers always call the same JSP (the CompositeView Template in Figure 8.5 and the template JSP in Figure 8.20). This JSP provides the overall look and feel of the site^[11] and includes other JSPs such as menus and use-case-specific pages. Some of these view classes are included statically, such as the menu JSP in Figure 8.20 to build the “standard” page elements such as the menus, header, and footer. Others JSPs can be included at runtime, like all other JSPs in Figure 8.20. These view classes build the “dynamic” elements of pages.

This concludes the steps of the Identify Design Elements activity. We have spent a disproportionate amount of time describing this activity, but we believe we have done that for some very good reasons, which we summarize here.

Before we move on, we would like to make a couple of important points. While performing this activity, it is important to maintain a delicate balance between identifying design elements and refining their design. This activity should focus on identifying the elements. The activities of the Detail the Design workflow detail focus on refining their design.

We would also like to emphasize that, in reality, the steps for identifying the design elements are performed concurrently. There is no rule that enterprise components must be identified before Presentation layer classes are identified. On the other hand, there are obvious sequential dependencies. For example, we cannot identify facade session EJBs until we know what enterprise components we have in the system.

We start by looking for design elements, such as enterprise components and EJBs, that offer Interfaces similar to the candidate Interfaces identified in the design. We should look for similar responsibilities, attributes, parameters and return values. Even if there is not an exact match, there may be opportunities to make minor changes to the design of the system that will allow the reuse of an identified component. Simple changes include rearranging or adding parameters to an Interface or refactoring the Interface by splitting it into several Interfaces, one or more of which match those of the existing component. When we identify a reuse candidate, we need to consider its non-functional properties, as well as its functionality. For example performance, security or cost of a component may disqualify it from being reused despite an otherwise perfect match of its Interfaces.

In our Online Auction application, the User Account Management enterprise component would be a good candidate for being implemented by an existing reusable component. User account management is a rather common function and there are commercially available components that could be considered as candidates. Were we building a commercial auction system, we would have seriously considered acquiring the User Account Management enterprise component from a third party rather than building it ourselves.

If reuse of an existing Design Subsystem or Framework Component in its entirety is not possible, we may still consider reusing one or more of its parts. This is more ad hoc than systematic reuse, but is a viable option as software round-trip-engineering tools have become quite sophisticated. Some of these tools can reverse-engineer Java classes, JSPs, deployment descriptors and database schemas. They can also generate the implementation from the design elements.

Databases, and the data residing in them, represent an important source of reusable assets. For example, reverse-engineering a database schema is an excellent first step in identifying what information used by the application already resides in existing databases. The set of Design Classes that result from such reengineering can be then mapped into the entity EJBs and/or types identified in the Identify Design Elements activity.

As we decide to incorporate existing elements in our design, we need to account for them in the Design Model. The extent of the model changes may vary. On the one hand we may modify a candidate Interface of a Design Subsystem to allow for reuse of an existing, functionally similar component. This will not result in changes to the overall Design Model structure. On the other hand, we may refactor an identified Design Subsystem into two Design Subsystems, one that will be reused and another that will still have to be developed. This will add a new Design Subsystem to the model structure.

In the context of J2EE, the concept of a “node” can be confusing. In RUP, a node represents a processing device, such as a server computer, to which elements can be deployed. However, as described in Chapter 2, we do not deploy elements directly to nodes for two reasons. The first is that we physically deploy J2EE modules, not the elements contained in those modules. The second is that we deploy to a container that executes on a particular node (a server), not to the node directly (containers can be considered “virtual nodes”).

It can be argued that describing the deployment of J2EE modules to containers is of little value because it is obvious that a WAR is deployed to a Web container, an EJB-JAR to an EJB container, and so on. However, there is value in describing the deployment of a system when there are explicit requirements that certain elements of the system reside on a node with specific characteristics (for example, a node that supports a database, or a node supporting a legacy system).

In cases like this, where there is value in articulating the physical distribution of the system, the first step is to show the distributed configuration of the nodes (and, optionally, the system resources allocated to each node^[12]) in the Deployment Model. An example of a deployment diagram is shown in Figure 8.21. In this example, which is a refinement of the initial Deployment Model diagram from the Architectural Analysis activity, the database with user accounts and the components that access that data run on a specialized node (EJB server) identified as the “User Accounts Server.”

Figure 8.21. An Initial Deployment Diagram

This step is a complement to the previous step. Having identified the nodes, we now need to decide which elements to deploy on them.

As described in Chapter 2, J2EE elements are packaged within J2EE modules, which are then deployed. Elements that need to run on a specific node must be packaged together in a separate J2EE module, and then that module is deployed only to that node.

For example, if we know that the elements that access the user accounts database must be deployed to a separate node (the User Accounts Server shown in Figure 8.21), then these elements must be packaged in a separate J2EE module that is then deployed to the User Accounts Server. We illustrate such situation in Figure 8.22, where the useraccountmanager.jar file (which will contain the UserAccountManager EJB) is only deployed to the User Accounts Server node. We discuss J2EE modules in some more detail in Chapter 9.

Figure 8.22. Elements Deployed on Separate Physical Nodes

Application concurrency is a term used to refer to the splitting of application logic into concurrent threads of execution in order to initiate multiple parallel activities. This is usually done for performance reasons. For example, this might allow an application to do useful work while waiting for a response from a slower legacy system. The purpose of this step is to analyze the application and identify opportunities for application concurrency.

The Online Auction application does not present many opportunities for application concurrency, because most of its operations are relatively simple and naturally sequential. However, the Close Auction Use Case presents some interesting possibilities. As first presented in Chapter 6, Requirements, the basic flow of the Close Auction Use Case is detailed in the following list.

Let's assume that auctions are closed on the hour. In a large auction system, many auctions may have to be closed at the same time. As we see from the Use Case flow, there are quite a number of bookkeeping operations that must be performed on each closed auction. On the other hand, we would like to close auctions instantaneously so we can stop the bidding. We can leverage concurrency to help us with this by following the algorithm described here.

As we mentioned earlier, the concurrency associated with load balancing is supported by most J2EE platform implementations. However, application concurrency has to be supported by the application logic and hence needs to be designed. The objective of this step is to identify the mechanisms that will support application concurrency.

Application concurrency mechanisms are somewhat limited in the J2EE platform. In general, any Java class can create a new thread of execution. An EJB, however, cannot start, stop, suspend or resume a thread. This restriction is due to the fact that an EJB container must provide a predictable environment in which an EJB executes.

We can, however, make use of message-driven EJBs that can execute concurrently. Following our Close Auction processing example discussed in the previous step, we can create a queue that is processed by a number of concurrently executing message-driven EJBs. In this design the AuctionManager EJB is responsible for populating the queue (using the Java Messaging Service, JMS), and each of the message-driven EJBs is responsible for processing items on the queue by charging the Seller's account and e-mailing both the Buyer and the Seller.

We strongly advise that someone external to the project participate in the review of the architecture. A good review should examine multiple aspects of the system and include aspects often neglected such as system operations, administration and maintenance.

There are three major areas that the review should concentrate on:

In analysis we developed a Use-Case Realization that shows how Analysis Classes realize the Use Case. We represented the participants in the analysis-level Use-Case Realization on a class diagram. We also represented the realization of each flow of events on an interaction diagram (such as a sequence diagram). For example, the basic flow interaction diagram of the analysis-level Create Auction Use-Case Realization is shown in Figure 8.13.

In design, we describe the realization of the Use Case in terms of the design elements identified in the Identify Design Elements activity. For example, Figure 8.20 depicts the participants of the Create Auction Use Case. In Figure 8.24, we describe how some of these participants interact to realize the Use Case functionality.

Figure 8.24. Create Auction Use-Case Realization

We have simplified both diagrams for readability without, we hope, obscuring the Use Case description. In the Participants diagram (shown in the model structure in Figure 8.20) we only show business delegates and locators of the enterprise components. As noted earlier, a business delegate provides a convenient representation of an enterprise component in that it exposes the interface to the enterprise component, but completely encapsulates its internals (a business delegate is a “smart proxy” for an enterprise component). Business delegates, therefore, allow us to create greatly simplified interaction diagrams when describing the realization of the flow of events of a Use Case. For example, in the sequence diagram shown in Figure 8.24, we don't describe the details of how the use-case dispatcher obtains an instance of the business delegates using the enterprise component service locator. We only show the use-case dispatcher communicating with the business delegate.

As we work through each analysis-level Use-Case Realization, we refine the design of the participating design elements and, in particular, we fully describe their operations.

The architecture and the mechanisms developed in the Refine the Architecture workflow greatly simplify the development of Use-Case Realizations. Because most of the Use-Case Realizations follow the same set of patterns and use a common set of mechanisms, their structure is similar to the one shown in Figure 8.24 and Figure 8.20.

By now we should have a design-level Use-Case Realization for each Use Case addressed in the current iteration. In this step, we reconcile the individual Use-Case Realizations and unify design elements by identifying:

For example, in the Online Auction application, we recognized that all use-case dispatchers were performing integrity checks on the data input by the user. After closer examination, we decided to develop a generic input field validation mechanism. In order to simplify the code of the use-case dispatchers, we implemented the logic of the mechanism as a method on a DefaultDispatcher class, from which all of the use-case dispatchers inherit.

Given the discussion in the Identify Design Elements activity described earlier, we already have an initial draft of the elements of the Design Subsystems representing our enterprise component. We will now concentrate on the refinement of these design elements.

Consider, for example, the Auction Manager enterprise component shown in Figure 8.25. Following the pattern names discussed at the start of this chapter, the AuctionManagerDelegate Java class is the business delegate, the AuctionManagerHomeLocator class is the service locator, the AuctionManagerEJB component is the session façade, and the CategoryEJB, AuctionEJB and BidEJB components are business entities. From an “internal” perspective, we should expect to see these elements used when describing the subsystem's behavior.

Figure 8.25. Design Elements of the Auction Manager Enterprise Component

From an “external” perspective, the subsystem behavior is described by its Interface, which is realized in our architecture by the business delegate and the session façade. The operations that a business delegate must support were first identified during the Identify Design Elements activity as the business operations of an enterprise component's Interface. During the Use-Case Design activity these operations were further refined. Because business delegates realize their enterprise component's Interfaces, they can be conveniently used as an enterprise component proxy.

The business delegate of the Auction Manager enterprise component is shown in Figure 8.26.

Figure 8.26. Auction Manager Business Delegate

Each business service listed in an enterprise component's Interface is realized by a collaboration of its elements. Descriptions of these collaborations can be represented in the same way as the design element collaborations documented within the Use-Case Realizations in the Use-Case Design activity—as UML collaboration instances. If you choose to model the realization of an enterprise component's operation in terms of the interactions of its elements, define a collaboration instance for the operation, using the operation name as the collaboration instance name, and stereotype the collaboration instance «interface realization». Then define a sequence diagram that describes the collaboration among the subsystem elements when performing the operation. An example is shown in the sequence diagram in Figure 8.27. This diagram represents a collaboration of the elements of the Auction Manager enterprise component realizing the addBid operation. The UserTransaction object represents a transaction context and the two methods begin() and commit() demarcate the transaction boundaries. This object is a low-level helper class that we have included for completeness.

Figure 8.27. The addBid Operation of the Auction Manager Enterprise Component

The Interface operation realizations are placed within the “Interface Realizations” subpackage of the enterprise component, as shown in Figure 8.28.

Figure 8.28. Interface Realization in the Design Model

During the Subsystem Design activity, we make sure that all subsystem external dependencies are identified. Dependencies between enterprise components can be represented as dependencies between the Design Subsystems that represent the enterprise components and the Interfaces of the other enterprise components that the enterprise components are dependent on. An example from our Online Auction system is shown in Figure 8.29.

Figure 8.29. Design Subsystem Dependencies in the Design Model

Design Subsystems should only depend on the Interfaces of other Design Subsystems and not on their internals. In the architecture of the Online Auction application, this means that an enterprise component should only depend on the business delegates of the enterprise components it depends on. This approach ensures that a subsystem is treated as a “black box” and, while its internal implementation may change, other components don't see that change as long as its external Interface stays the same.

As described in Chapter 2, an EJB comprises a number of elements. Specifically, all EJBs (with the exception of message-driven EJBs) have a home and remote Interface (or local home and local Interface), and an implementation class. Entity EJBs also have an associated primary key class.

The behavior of an EJB is characterized by the operations on its home and remote Interfaces. The purpose of this step is to specify how the EJB implementation class, and the elements it depends on, realizes these operations. We also need to specify any operations that the EJBs must implement in order to be managed by the container. For example, BMP entity EJBs must implement operations that store and restore their state.

In this step, we should also define the transactional properties of the EJBs.

We have already seen in Figure 8.15 how to model the structure of an EJB in UML. The elements that comprise an EJB are also grouped in a Design Package in the Design Model structure. We show a recommended model structure in Figure 8.17.

In the previous step, by defining the interactions of the EJB implementation classes, we may have identified specific dependencies of the EJB implementation classes on other design elements. In this step, we simply describe and document these dependencies for the team members that will be using and implementing them.

Classes can be assigned a visibility with respect to the Design Package in which they reside. For example, a particular class may be considered “private” to the Design Package in which it resides, if it is only ever used by other elements inside that Design Package. Keep in mind that elements within a Design Subsystem are implicitly private and therefore don't need to be declared as having private visibility. In our architecture, the only public class shown in the enterprise component structure is the business delegate.

The majority of operations on classes are identified during the Use-Case Design, Subsystem Design and Component Design activities. However, we may not have identified all operations. For example, we may need additional operations to support:

The naming conventions of the implementation language should be used when naming operations, return types, and parameters and their types. This naming convention should be described in the Design Guidelines.

We also identify the visibility of each operation as either public (the operation is visible outside of this class), protected (the operation is visible only to the class itself, or to its subclasses), or private (the operation is only visible to the class itself).

Finally, we may also identify operations that apply to the class as a whole, rather than each instance. In the Java programming language, these operations are identified using the “static” keyword. An example of such an operation is one that returns all instances of the class.

At this point, some of the attributes of the major design classes, especially those representing the key abstractions, may already be defined. However, this is where their signatures are refined. Also, during the definition of operations, we may identify additional attributes needed by the class in order to carry out the operations. For each attribute, we define characteristics such as its name, its type, any initial value, and its visibility (in terms of being private, protected, or public).

A class can also move through a number of states that affect the behavior of its operations. It is useful to consider representing these states using one or more attributes.

In this step we describe dependencies, associations and generalizations between classes.

A dependency should be added between two classes when one class needs to “use” the other. Dependencies are transient, existing only for a limited duration, and do not represent a structural relationship between classes. Class A depends on class B for reasons such as those in the following list.

An association is a relationship between two classes that implies that instances of these classes have a structural relationship. We may also choose to refine an association and make it an aggregation relationship. An association between two classes can also be given a number of attributes such as:

Classes may be organized into a generalization hierarchy to reflect common behavior and common structure. A common superclass can be defined, from which subclasses can inherit both behavior and structure.

When we find a generalization for two or more subclasses, we create a superclass to contain the common attributes, associations, aggregations, and operations. We then remove the common structure and behavior from the subclasses.

If you remember from our earlier discussion, there are two options for persistency for entity EJBs: container-managed persistence (CMP) and bean-managed persistence (BMP). In this step, we consider each of these two cases.

The EJB container persists CMP entity EJBs in the tables of a relational database. In order to store the state of an entity EJB, the container has to be given a mapping between the EJB and a table, and between the bean attributes and the rows in the table. The Application Designer and the Database Designer have to ensure that these mappings are both type-compatible and semantically correct. They have to ensure that the database types can be properly converted to and from the Java types and that the table columns and entity attributes represent the same information. In the process of defining the table-to-EJB mapping, the design of both the tables and the EJBs may have to be adjusted.

Also, an entity EJB can provide any number of custom finder methods that are exposed on its home Interface. For each such method, there must be a query statement that is executed when the method is called. The finder query statements must be consistent with the schema of the underlying database. The mappings for CMP entity EJBs and the finder query statements are captured in the EJB deployment descriptors that were introduced in Chapter 2.

BMP entity EJBs store and retrieve their state themselves, and hence, they can use any storage mechanism. In practice, however, we most often use a relational database and then use JDBC to access it.

In general, you should use BMP entity EJBs only when the deployment tools cannot map the bean to a database table. This is because BMP entity EJBs are harder to maintain and are coupled to the underlying database schema.

If you are using a BMP entity EJB, you must provide:

Because of their tight coupling with the underlying database, BMP entity EJB design cannot be done in isolation from the database design, even more so than the design of CMP entity EJBs.

Most databases support a stored procedure capability. A stored procedure runs within the process space of the database management system, and provides the ability to perform database-related actions on the server without having to transfer data across a network. Stored procedures usually come in two flavors: actual procedures and triggers.

Procedures are executed explicitly by an application and can return values. Triggers are invoked implicitly when some database event occurs (insert a row, update a row, delete a row, and so on), have no parameters (since they are invoked implicitly), and do not provide return values.

Because of their explicit invocation, procedures can only be used by BMP entity EJBs. Triggers, on the other hand, have general applicability. The use of stored procedures should be considered for performance reasons and carefullyexamined with the Database Designer. It is the responsibility of the Database Designer to write them and store them in the database system.

With each successive iteration more and more of the system design is detailed. However, before we proceed to implementation, we should review the detailed design to ensure that it meets the following criteria:

The review should concentrate on:

As always, any defects identified during the review should be documented in Change Requests, and the responsibility for finding a resolution should be assigned to a member of the team.