The Unified Modeling Language

Building a model requires a suitable modeling material. For software models, this modeling material is the UML, which enables analysts, designers, and developers to describe the static and dynamic structure of all aspects of the system. The UML diagrams most commonly used in software development are

• Use-case diagrams for defining the organization of a system's use cases

• Activity diagrams for representing process flow

• Class diagrams to show the static structure of software

• Interaction diagrams to show the dynamic structure of software

• State diagrams for depicting an object's possible states

• Component diagrams for defining the relationships between system components

• Deployment diagrams for illustrating the physical configuration of software and hardware

Let's examine these diagrams in more detail.

Use-Case Diagrams

If you are employing use cases to drive the development approach, then a use-case diagram will form part of the analysis model of the functional requirements of the system. The use-case diagram provides a pictorial representation of the various relationships between the use cases and actors that make up the system. A member of the team wearing the analyst's hat generally produces use-case diagrams in consultation with business representatives.

Use cases are discussed in Chapter 3.

The notation of the use-case diagram is very simple and generally easily understood by nontechnical staff. This makes use-case diagrams an ideal mechanism for discussing system requirements with the customer. Figure 5-1 illustrates a basic use-case model.

Figure 5-1. Use-case diagram.

The use-case diagram depicts the following elements:

• Actors, represented as stick men

• Use cases, shown as ellipses

• The communication association between an actor and a use case, as defined by a solid line

• The relationship between use cases, depicted by a dashed line with an arrow for indicating the direction of the relationship

• The system responsible for executing a use case, identified as an enclosing rectangle

The use-case diagram in Figure 5-1 shows the three main actors of Customer, Shipping Clerk, and Warehouse Clerk. The Customer actor communicates with the Login, Register for Account, Search for Items, and Place Order use cases. Each use case resides in the Online Ordering system. A relationship is shown between the Login and Register for Account use cases.

Note

Use-case diagrams might suggest that use cases are graphical rather than text-based, detailed requirements documents. You may find the use-case model is a nicety rather than an essential modeling element. UML diagrams are not a prerequisite for working effectively with use cases.

It is more important that the use cases themselves correctly detail the system requirements than that a use-case diagram exists. If you are running short on time, you may wish to ignore the initial use-case diagram and concentrate your efforts on accurately defining the content of each use case.

For the architect, a use-case model serves as the use-case view of the software architecture. This is the special fifth view of the architecture, and it defines the key system use cases as being architecturally significant.

These use cases are a subset of the total that make up the complete system and form the basis for ongoing modeling and prototyping efforts during the inception and construction phases. During later stages of the project, they offer a baseline against which system changes that impact the software architecture can be measured. These use cases are also known as primary use cases.

Care should be taken when selecting the primary use cases that shape the system's architecture. Be sure to pick a diverse cross-section of use cases to model for the initial architecture rather than focus exclusively on one functional area. Avoid the obvious high-profile candidates that concentrate on screen inputs and outputs, and instead look to functionality that defines integration requirements, security concerns, exception handling, and batch processes. These all assist in addressing technical risk early in the project.

Activity Diagrams

Activity diagrams are similar to flow charts and describe process flow, representing both conditional and parallel behavior. Consequently, activity diagrams model the system's dynamic behavior. Figure 5-2 shows an activity diagram.

Figure 5-2. Activity diagram.

The notation of the activity diagram defines a process flow for a specific scenario:

• Activities performed at each step of the process flow are shown as rounded rectangles

• Transitions between activities are denoted using arrows

• A fork, where a transition splits into two or more parallel activities, is shown as a black bar with one transition entering and several leaving

• A join, where two or more parallel activities converge into a single activity, is shown as a black bar with several transitions entering and one leaving

• The object, actor, or system responsible for a particular activity is represented by an enclosing rectangle known as a swim lane

Activity diagrams are applicable to all five architectural views. One of the most effective uses of the activity diagram is to include it within a use-case document to illustrate the use case's different flows.

Class Diagrams

The class diagram is probably the most widely known UML notation and defines the static organization and structure of the software. Class diagrams receive the most attention from software engineers because they offer a convenient notation for conveying software structure. They are commonly used in the definition of the logical and process views.

Figure 5-3 depicts the basic notation of a class diagram and shows the classes involved in the system, modeling the relationships between classes of type Customer, Account, Corporate, Personal, Order, and Item:

• Classes are shown as rectangles with the name of the class at the top of the rectangle

• Attributes and operations are shown inside of the class element

• Associations between classes are represented by solid lines

• Adornments on associations further describe the relationships that exist between classes, such as generalization and aggregation

• Role navigability is represented by arrows on association relationships

• Associations with no arrowheads are bidirectional

• Multiplicity is shown by numbers on the association

Figure 5-3. Class diagram.

From the UML diagram, an association exists between the classes of Customer and Account. The multiplicity for the association specifies a Customer may have one or more instances of the Account class. The association between these two classes is unidirectional, meaning Account objects are visible to objects of type Customer, but not vice versa.

The empty diamond states that the relationship between the two classes is one of simple aggregation. A solid diamond denotes an association by composition, which links the lifetimes of the two objects in the relationship.

composition and aggregation

Composition and aggregation are both forms of containment whereby one object holds a reference to another object. The semantics of aggregation and composition relationships define how the lifetime of the contained object is managed.

With composition, the containing class is responsible for creating and removing the internal object. The contained object cannot exist after its parent has been removed.

In an aggregation relationship, the lifetime of the contained object is independent of the containing object, and so it is free to live a life of its own.

Looking at other parts of the diagram, we can see that classes Corporate and Personal are both specialized forms of Account, thanks to the generalization relationship depicted in the diagram.

Tip

Class diagrams can describe the organization of a system's design elements in fine detail. However, many architects find detailed class diagrams become cluttered and difficult to read. Consequently, basic class diagrams that describe the software at a high level are often more informative than those containing a highly detailed view.

The class diagram can also be used in a high-level form as a package diagram. Here, the package diagram shows the organization of the software into packages and defines the dependencies that exist between them.

Interaction Diagrams

Whereas class diagrams give a static view of the software, interaction diagrams are dynamic. Interactions diagrams are found in all five of the view models of architecture.

Interaction diagrams come in two types: sequence and collaboration. They both demonstrate the dynamics of the software system and illustrate how objects defined in the class diagram collaborate to execute each of the system's use cases. In this way, interaction diagrams are a means of demonstrating that the model can meet all the business requirements detailed in each use case.

Sequence and collaboration diagrams model essentially the same information, but each has a slightly different emphasis.

• Sequence diagrams are organized on time, with events occurring in chronological order as you progress down the page

• Collaboration diagrams emphasize object organization and message flow

Models can be built using either or both types of interaction diagram, depending on preference. Most modeling tools automatically generate the alternate diagram type for you.

The sequence diagram in Figure 5-4 depicts the following information:

• The object or actor who initiates the scenario is located at the left edge of the diagram

• Objects are shown at the top of the diagram as rectangles

• The lifetime of each object is represented by a vertical dotted line

• Messages passed between objects are defined by solid arrows

• The activation bar, a thin vertical rectangle drawn over the object's lifetime, illustrates the duration of a message

Figure 5-4. Sequence diagram.

The example is for a very simple scenario and models the passing of messages between objects for associating an order with a Customer account and adding items to the Order.

Sequence diagrams enjoy greater popularity than collaboration diagrams, but the choice of interaction diagram type is purely one of preference. For comparison, Figure 5-5 depicts the collaboration diagram equivalent of the sequence diagram represented in Figure 5-4.

Figure 5-5. Collaboration diagram.

Message flow in a collaboration diagram uses a different notation than that of the sequence diagram:

• Associations between objects are shown with solid lines

• Small arrows on the associations show the passing of messages

• Message sequencing is defined by numbering each message

Be sure to define interaction diagrams for the primary use cases that form the use-case view of the architecture; otherwise, validation of the static model is not possible. The interaction diagram proves the objects in the system can collaborate to execute the flows specified in each architecturally significant use case. Furthermore, interaction diagrams help members of the project understand how objects in the system should interact.

Statechart Diagrams

Objects in a system have both state and behavior. Statechart diagrams map the different states of objects within the system and identify the actions that trigger an object's change in state. Like interaction and activity diagrams, statechart diagrams model the dynamic aspects of the system and apply to all five views.

Figure 5-6 shows a UML statechart diagram.

Figure 5-6. Statechart diagram.

The statechart diagram conveys the following information:

• The different states of an object, shown as rounded rectangles

• The actions resulting from a change in state, defined in the lower part of the state's rectangle

• Transitions between states, represented by arrows

• The event that triggers a state transition, shown as text on the transition arrow

Figure 5-6 shows the basic states in sending out a customer invoice. The Preparing Invoice state is entered by the event account outstanding.

Within the Preparing Invoice state, the action of calculating the invoice is undertaken. On leaving the state, the action is to mail the invoice to the customer.

Statechart diagram are excellent for modeling any part of the system considered state-driven.

Deployment and Component Diagrams

Component and deployment are two different diagram types that are often merged into a single diagram. They fall into the category of a physical diagram, showing the packaging and deployment structure of system components.

Component diagrams show static structure and are incorporated into the implementation view if created as a single diagram. Deployment diagrams also describe static structure and form part of the deployment view.

Figure 5-7 depicts a combined component and deployment diagram.

Figure 5-7. Combined deployment and component diagram.

Architectural elements defined in the diagram shown in Figure 5-7 include:

• Hardware nodes, represented by the rectangular boxes

• Physical software components, shown by the rectangles with two large tabs on the left edge

• The relationships between components, shown as dashed arrows

• The communications protocol between hardware nodesfor example, TCP/IP

The diagram depicts the three server nodes of a multitier distributed architecture, with software components deployed to each tier. Communication between the tiers is over TCP/IP.