The Unified Modeling Language (UML) is the primary modeling language used to analyze, specify, and design software systems. A diagram simply captures a statement of a system’s behavior (for analysis), or the vision and details of an architecture (for design).
The Products of Object-Oriented Development the analysis of a system will include sets of use case and activity diagrams (to express the behavior of the system through scenarios), class diagrams (to express the roles and responsibilities of agents that provide the system’s behavior), and interaction and/or state machine diagrams (to show the event-ordered behavior of these agents). Similarly, the architecture of a system may include sets of package diagrams, class diagrams, object diagrams, component diagrams, and deployment diagrams, as well as their corresponding dynamic views
Use Case Diagrams
Sometimes development people will have specifications but will have no idea what the business’s goals are, that is, why they are building the system. Does the business, interested in being a low-cost provider, want the system to reduce costs?
Or is the goal to provide high-quality, personalized service? Does the business want to be faster or to be innovative? If the development organization does not understand the business goals, when given a choice of approaches during design and implementation, developers could make technical decisions that directly conflict with the business goals.
Use case diagrams give us that capability. Use case diagrams are used to depict the context of the system to be built and the functionality provided by that system
Essentials: Actors
Actors are entities that interface with the system. They can be people or other systems. Actors, which are external to the system they are using, are depicted as stylized stick figures. Figure 5–20 shows two actors for the Hydroponics Gardening System
Essentials: Use Cases
Use cases represent what the actors want your system to do for them. Figure 5–21 depicts some use cases, shown as ovals, for the Hydroponics Gardening System
“A use case is a specific way of using the system by using some part of the functionality. . . . A use case is thus a special sequence of related transactions performed by an actor and the system in a dialogue. . . . Each use case is a complete course of events in the system from a user’s perspective.”
To show which actors use which use cases, you can create a use case diagram by connecting them via basic associations, shown by lines, as in Figure 5–22.
Advanced Concepts: «include» and «extend» Relationships –
**** will add soon *****
Class Diagrams
A class diagram is used to show the existence of classes and their relationships in the logical view of a system. A single class diagram represents a view of the class structure of a system. During analysis, we use class diagrams to indicate the common roles and responsibilities of the entities that provide the system’s behavior.
During design, we use class diagrams to capture the structure of the classes that form the system’s architecture.
The two essential elements of a class diagram are classes and their basic relationships.
Essentials: The Class Notation
In the Hydroponics Gardening System, we have food items that have a specific vitamin content and caloric equivalent, but there is not a type of food called “food item.” Hence, the FoodItem class is abstract. Figure 5–34 also shows the subclass Tomato, which represents a concrete (instantiable) food item grown in the greenhouse
Essentials: Class Relationships
The essential connections among classes include association, generalization, aggregation, and composition, whose icons we summarize in Figure 5–35.
Consider another example. In Figure 5–36, we see the class CropHistory, whose instances physically contain * instances of the class NutrientSchedule and * instances of the class ClimateEvent. Composition implies that the construction and destruction of these parts occurs as a consequence of the construction and destruction of the aggregate. By contrast, each instance of CropHistory does not physically contain one instance of Crop. This means that the lifetimes of the two objects are independent, although the one is still considered a part of the other.
Advanced Concepts: Template (Parameterized) Classes
Some object-oriented programming languages, C++ for example, provide for template (parameterized) classes. A template class denotes a family of classes whose structure and behavior are defined independent of the formal class parameters.
Advanced Concepts: Visibility
For example, in C++, members may be public (accessible to all clients), protected (accessible only to subclasses, friends, or the class itself), or private (accessible only to the class itself or its friends). Also in C++, certain elements might be a part of a class’s implementation and thus inaccessible even to friends of the class; this is referred to as implementation visibility.
Public (+)Visible to any element that can see the class
Protected (#)Visible to other elements within the class and to subclasses
Private (-)Visible to other elements within the class
Package (~)Visible to elements within the same package
Sequence Diagrams
A sequence diagram is simply another way to represent a communication diagram.
Essentials: Objects and Interaction
In Figure 5–42, we provide a sequence diagram that duplicates most of the semantics of the communication diagram shown. The advantage of using a sequence diagram is that it is easier to read the passing of messages in relative order. Sequence diagrams are often better than object diagrams (to be discussed later in this chapter) for capturing the semantics of scenarios early in the development lifecycle, before the protocols of individual classes have been identified.
Early sequence diagrams tend to focus on events as opposed to operations because events help to define the boundaries of a system under development.
Essentials: Lifelines and Messages
In sequence diagrams, the entities of interest (which are the same as for object diagrams) are written horizontally across the top of the diagram. A dashed vertical line, called the lifeline, is drawn below each object. These indicate the existence of the object.
Messages (which may denote events or the invocation of operations) are shown horizontally. The endpoints of the message icons connect with the vertical lines that connect with the entities at the top of the diagram. Messages are drawn from the sender to the receiver. Ordering is indicated by vertical position, with the first message shown at the top of the diagram, and the last message shown at the bottom.
A synchronous message (typically an operation call) is shown as a solid line with a filled arrowhead. An asynchronous message has a solid line with an open arrowhead. A return message uses a dashed line with an open arrowhead. A lost message (a message that does not reach its destination) appears as a synchronous message that terminates at an endpoint (a black dot). A found message (a message whose sender is not known) appears as a synchronous message that originates at an endpoint symbol.
State Machine Diagrams
A state machine diagram expresses behavior as a progression through a series of states, triggered by events, and the related actions that may occur. Such state machines are also known as behavioral state machines. State machine diagrams are typically used to describe the behavior of individual objects. However, they can also be used to describe the behavior of larger elements of any system.state machine diagrams focus on the states and transitions between those states versus the flow of activities
During analysis, we may use state machine diagrams to indicate the dynamic behavior of the system. During design, we use state machine diagrams to capture the dynamic behavior of individual classes or of collaborations of classes.
Essentials: Initial, Final, and Simple States
When an object is in a given state, it can do the following
Execute an activity
Wait for an event
Fulfill a condition
Do some or all of the above
Essentials: Transitions and Events
The movements between states are called transitions. On a state machine diagram, transitions are shown by directed arrows between states. Each state transition connects two states. Figure 5–53 shows a transition from the initial state tothe state named Initializing, from Initializing to Timing, and from Timing to the final state
Object Diagrams
An object diagram is used to show the existence of objects and their relationships in the logical design of a system. Stated another way, an object diagram represents a snapshot in time of an otherwise transitory stream of events over a certain configuration of objects
Essentials: Objects
Figure 5–75 shows the icon we use to represent an object in an object diagram. Similar to class diagrams, a horizontal line partitions the text inside the icon into two regions, one denoting the object’s name and the other providing an optional view of the object’s attributes and their values.
Essentials: Object Relationships
As explained in Chapter 3, objects interact through their links to other objects, as shown in Figure 5–76, which is an object diagram corresponding to the class diagram of Figure 5–39. A link is an instance of an association, analogous to an object being an instance of a class.
Summary
Designing is not the act of drawing a diagram; a diagram simply captures a design.
- In the design of a complex system, it is important to view the design from multiple perspectives: namely, its conceptual, logical, and physical models and its structural and behavioral semantics.
- The UML includes thirteen diagrams: package diagram, component diagram, deployment diagram, use case diagram, activity diagram, class diagram, sequence diagram, interaction overview diagram, composite structure diagram, state machine diagram, timing diagram, object diagram, and communication diagram.
- A package diagram provides the means to organize the artifacts of the development process to clearly present the analysis of the problem space and the associated design. The specific reasons will be varied but will either focus on physically structuring the visual model itself or on clearly representing the model elements through multiple views.
- A component diagram shows the internal structure of components and their dependencies with other components. This diagram provides the representation of components, collaborating through well-defined interfaces, to provide system functionality.
- A deployment diagram shows the allocation of artifacts to nodes in the physical design of a system. A single deployment diagram represents a view into the artifact structure of a system. During development, we use deployment diagrams to indicate the physical collection of nodes that serve as the platform for execution of our system.
- A use case diagram depicts the context of the system to be built and the functionality provided by that system. Use case diagrams depict who (or what) interacts with the system. They show what the outside world wants the system to do.
- An activity diagram provides the visual depiction of the flow of activities, whether in a system, business, workflow, or other process. These diagrams focus on the activities performed and who (or what) is responsible for the performance of those activities.
- A class diagram shows the existence of classes and their relationships in the logical design of a system. During analysis, class diagrams indicate the common roles and responsibilities of the entities that provide the system’s behavior. During design, class diagrams capture the structure of the classes that form the system’s architecture.
- A sequence diagram traces the execution of a scenario in the same context as an object diagram. To a large degree, a sequence diagram is simply another way to represent an object diagram.
- An interaction overview diagram is a combination of activity diagrams and interaction diagrams intended to provide an overview of the flow of control between diagram elements. Though any type of interaction diagram may be used, the sequence diagram is most prevalent.
- A composite structure diagram provides a way to depict a structured classifier with the definition of its internal structure. This diagram is also useful during design to decompose classes into their constituent parts and model their runtime collaborations.
- A state machine diagram is used to design and understand time-critical systems. A state machine diagram expresses behavior as a progression through a series of states, triggered by events, and the related actions that may occur.
These are also known as behavioral state machines.
- A timing diagram is a type of interaction diagram. Its purpose is to show how the states of an element or elements change over time and how events change those states.
- An object diagram shows the existence of objects and their relationships in the logical design of a system. A single object diagram represents a view of the object structure of a system and is typically used to represent a scenario.
- A communication diagram is a type of interaction diagram that focuses on how objects are linked and the messages they pass, as they participate in a specific interaction.
