From Design to J2EE By Example: A Truck Rental Business

This section presents a sample design model of an application, which will allow you to gain exposure to the process of mapping UML artifacts to a J2EE application architecture. The example showcased will be focused on the administration and customer support for a truck rental business, which will require developing the following UML artifacts:

• Use cases

• Activity diagrams

• Class diagrams

• Sequence diagrams

• Deployment and component diagrams

Truck Rental Business Requirements

The first step is to consolidate the requirements that are focused on the types of rental queries that a customer may make and the administration of those requests , as follows :

• Customer requires a particular type of vehicle, i.e. truck or van.

• Customer requests a capacity, i.e. number of passengers, payload.

• Customer requests a price range.

• Customer requests number of days for rental.

• Customer searches for vehicle meeting requirements.

• Administrator updates persistent data to maintain inventory of vehicles.

• Administrator views status of requests, i.e. success or no matching vehicles.

These requirements indicate the need for a user interface that is easily accessible by multiple clients . There is also a need to maintain persistent data.

Truck Rental Use Cases

You can visualize the analysis of the requirements through use case diagrams. The process of creating use case diagrams helps you analyze the requirements and gain a deeper understanding of the problem domain. As you gain this understanding, you can refine the use case to better describe the results of the analysis.

The process is fairly straightforward. First, you choose actors to represent system roles that users play and choose the use cases, or system interactions, that they will perform. Second, you review the use cases to make sure that the scenarios adequately portray the requirements. In the diagram, the actor with its use case should sound like a simple sentence , such as "Customer specifies type of vehicle required" or "Customer searches for vehicle matching requirements," as illustrated in Figure 6.8.

Figure 6.8. The Truck Rental use case visually communicates the analysis of the requirements.

As you refine the use cases, you can identify Generalizations, Include, or Extension relationships.

To learn about applying Generalizations, Include, or Extension relationships in Use Cases, see "The Features of a Use Case Diagram," p. 102 .

The following sections will elaborate the use cases shown in Figure 6.8.

Use Case 1: Edit Request

The Edit Request use case is performed by the Customer actor, as follows:

1. Customer fills out form specifying request criteria.

2. Update the form to include the new field if it is a common request.

An alternative flow occurs if the form does not include an entry for a request of the customer.

Use Case 2: Search for Vehicle

The Search for Vehicle use case is also performed by the customer, as follows:

1. Customer submits vehicle request form.

2. All matching results are presented to the customer.

However, a prerequisite is that Use Case 1 has already been performed by the same customer.

The alternative flow for this use case occurs if no matches are found, hence the request form will be stored in a list of failed searches. The Administrator will view the failed searches to determine if the inventory of available vehicles needs to updated for a particular type of vehicle. The alternative flow is therefore to have the Administrator perform the View Search Results use case.

Use Case 3: View Search Results

The View Search Results is performed by the Administrator. The purpose is to determine if the inventory matches the customer requests, as follows:

1. Administrator specifies search criteria for search results to match.

2. All matching results are presented to the Administrator.

3. Administrator evaluates list against inventory.

Use Case 4: Update Inventory

The Update Inventory use case is also performed by the Administrator, as follows:

1. Administrator determines types of vehicles that always fail the search.

2. Administrator determines types of vehicles that are never requested .

However, a prerequisite is that Use Case 3 has already been performed. There are no alternative flows for this use case.

Note

UML does not require that every use case specify alternative flows.

Truck Rental Activity Diagrams

To gain further understanding of the Truck Rental use cases, you may find it useful to create an activity diagram. This diagram helps identify the activities that are performed in each use case. Also, since the prevalent design pattern for enterprise J2EE applications is the Model-View-Controller pattern, it is very valuable to initially map the Truck Rental use cases to activity diagrams with MVC swimlanes, as illustrated in Figure 6.9, which will assist you in identifying what J2EE components could potentially be targeted for implementing those activities.

Figure 6.9. The Truck Rental activity diagram displays which domain may be taking responsibility for each activity.

Truck Rental Class Diagrams

The Together ControlCenter Model-Build-Deploy platform is the perfect tool for creating the EJB class diagrams, since its class diagram design tool contains templates for creating entity, session, and message-driven EJBs.

As illustrated in Figure 6.10, the View domain is designed as a servlet, the Control is designed as session EJBs, and the Model is designed as entity EJBs. The design for the user interface will be an HTML form with the servlet to service the request. The servlet will encapsulate a client-link to a session EJB, which will perform the application business logic. The session EJB will in turn use an entity EJB to maintain persistent storage of inventory and logged status information.

Figure 6.10. An EJB Class diagram of the Truck Rental example using the MVC Design Pattern.

Note

A JSP could have also been used as the View, with the Servlet and Session bean as the Control, and the Entity bean as the model.

Truck Rental Sequence Diagrams

The Together ControlCenter can automatically generate Sequence and Collaboration diagrams from methods in the class diagram. The method that has particularly interesting interaction behavior in this design model is the service() method in the RentalServlet . From the sequence diagram in Figure 6.11 and collaboration diagram in Figure 6.12, you can see that the Enterprise Java Beans are dynamically created when the client requests their services.

Figure 6.11. The Sequence diagram for the Service method.

Figure 6.12. The Collaboration diagram for the Service method.