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
Let's examine these diagrams in more detail.
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:
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.
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 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:
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.
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:
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.
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.
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.
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:
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:
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.
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:
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:
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.