Fast Track UML 2.0

This chapter focuses on the UML structural diagrams that you use to capture the fundamental structure of your models at the class and object levels.

Class Diagrams

A class diagram focuses on a set of classes (see Chapter 1) and the structural relationships among them (see Chapter 2). It may also show interfaces (see the section "Interfaces, Ports, and Connectors" in Chapter 1).

The UML allows you to draw class diagrams that have varying levels of detail. One useful way to classify these diagrams involves three stages of a typical software development project: requirements, analysis, and design. These stages are discussed in the following sections.

Domain-Level Class Diagrams

A domain-level class diagram shows just the names of classes. The purpose of the diagram is to show part of the initial core vocabulary with which system modeling can proceed.

Figure 3-1 shows an example of a domain-level class diagram.

Figure 3-1: Domain-level class diagram

The layout of this diagram suggests five conceptual groupings of classes around which more expansive diagrams might center. Starting in the upper-left corner and moving clockwise, these groupings are as follows :

• PurchaseOrder, Shipment, and Stock

• Category, Catalog, Book, BookAndAuthor, and Author

• Customer, Account, BillingInfo, and ShippingInfo

• Item, ShoppingCart, Order, and OrderHistory

• GLAccount

In the meantime, this diagram provides a view of a useful cross section of the relevant starting classes.

Analysis-Level Class Diagrams

An analysis-level class diagram typically shows attributes; it may show other adornments such as multiplicity and role names as well. An analysis-level diagram, though, shouldn't have operations, because deciding where to put what operations definitely falls into the design arena. (See Use Case Driven Object Modeling with UML ^[2] for more on this topic.)

Figure 3-2 shows an example of an analysis-level class diagram.

Figure 3-2: Analysis-level class diagram

This is clearly an early version of this diagram, because there will certainly be more attributes for PurchaseOrder, GLAccount, Order, and Account, as well as a full set of attributes for the other classes. The point is that class diagrams evolve as knowledge of the domain being modeled grows.

Note the term {encrypted} that is attached to the Account attribute password . This is a user -defined constraint that indicates that the password undergoes encryption before being stored in the system. This is something of a design decision, but since this decision exists at the attribute level, it makes sense to go ahead and include the constraint on a class diagram at this level of precision.

Design-Level Class Diagrams

Once a project starts exploring design issues, class diagrams tend to be more varied. You can expand your classes using the full UML notation, or you can explore classes at a lower level of abstraction and continue to suppress the details (perhaps because those details are well-defined elsewhere).

One form of design-level class diagram is simply a more expansive version of an analysis-level diagram. Figure 3-3 expands the analysis-level class diagram of Figure 3-2 to show operations.

Figure 3-3: Expansion of analysis-level class diagram

Figure 3-4 delves into some of the design-level classes that are connected with the ShoppingCart class that appears in Figure 3-1.

Figure 3-4: High-level design class diagram

The new ShoppingCart class is an HTML page that contains a static form displaying the contents of the cart and a Java applet that allows the Customer to make changes to the contents of the cart. The CandidateOrder is a JavaServer Page that retrieves the essential information from the ShoppingCart page (the client) and stores the information on a server in a format suitable for further processing by the system. SShoppingCart is an Enterprise JavaBean that lives only until the Customer is done with his or her shopping cart, at which point the system creates a "persistent" EJB with the name EOrder; this is the form that the Customer's order takes going forward.

Figure 3-5 takes things another step closer to implementation by showing the classes that sit underneath the ShoppingCart class shown in Figure 3-4.

Figure 3-5: Low-level design class diagram

The elements of Figure 3-5 are as follows:

• Remote is the superclass of all interfaces through which clients have remote access to EJBs.

• EnterpriseBean is the superclass of EntityBean (not shown) and SessionBean.

• EJBHome defines operations such as create and remove for an EJB.

• EJBObject defines operations for accessing an EJB's data.

• ShoppingCartIF contains the user-defined operations for our EJB.

• SessionBean is a form of EJB that lives only while the system's session with the client is alive .

• ShoppingCartHome is the interface to the "factory" that creates instances of our EJB.

• ShoppingCart is the interface to our EJB. It offers the operations defined by both EJBObject and ShoppingCartIF, via multiple inheritance (see the section "Generalization" in Chapter 2).

• ShoppingCartBean implements the operations that ShoppingCartIF offers.

Figure 3-5, which is adapted from a diagram in The Art of Objects , ^[3] can serve as a diagram of a pattern in that everywhere ShoppingCart appears, you can simply plug in the name of another design-level class that involves EJBs. One idea, then, is to replace ShoppingCart with a generic class name and then refer to the resulting diagram from various other diagrams as appropriate.

^[1] Stephen J. Mellor, Kendall Scott, Axel Uhl, and Dirk Weise, MDA Distilled: Principles of Model-Driven Architecture (Boston, MA: Addison-Wesley, 2004).

^[2] Doug Rosenberg with Kendall Scott, Use Case Driven Object Modeling with UML (Boston, MA: Addison-Wesley, 1999).

^[3] Yun-Tung Lau, The Art of Objects: Object-Oriented Design and Architecture (Boston, MA: Addison-Wesley, 2001).