3.4.1 Class Diagram
A class diagram is a way of visualizing a software system based on the abstractions, or classes, that it is comprised of and the relationships between them.
Class diagrams are generated throughout the software development process.
During the analysis phase of development, class diagrams are used to indicate the common roles and responsibilities associated with all of the entities that define the system’s behavior. Class diagrams are used in the design phase to describe the system’s architecture, based on the structure of the classes, which it is composed of. A given class diagram may not represent a system’s entire class structure, but rather can be specified and tailored for the situation at hand.
The major component of the class diagram is, of course, the class. As we said earlier, a model of a class consists of the class’ name, attributes and methods. We can now add constraints enforced upon the class to this list, such as the class’s multiplicity. The Booch abstract image of a class and the important information that will be shown in the model is given below in Fig.3.10.
A class diagram consists of many classes, and is used to depict their structure and relationships in a logical and meaningful way. Class diagrams are considered static. That is, they are used to illustrate which classes interact, but they do not go so far as to describe what occurs when said interaction occurs. In the figure below, a class diagram is used to model a customer order system. The diagram is centered around the Order class, which interacts with both a Customer class, and a Paymentclass. Contained within the Order class is an OrderDetail class,
Company
Person 1.
Fig. 3.9 Multiplicity
Fig. 3.10 Booch class image (Booch1994)
3.4 Models 47
which is associated with an Item class that describes the actual item being ordered, and contains information regarding specific individual orders. From the Paymentclass, we find three derived classes, Credit, Cash, and Check, all of which are, quite literally, different types of Payment (Fig.3.11).
3.4.2 Use Case Diagram
As we briefly explained earlier, a use case represents an interaction between a software system and an external entity. A use case diagram then, similarly, models the system from the view of an external observer. Like class diagrams, use case diagrams are considered static views of a system. They are also a type of abstraction in that they limit the information presented to that which is necessary and useful for an external understanding of a system. In essence, while many aspects of software development focus on the intricacies of how a software system works, a use case diagrams describes a system based on what it does. A scenario describes what takes place when some external entity interacts with the system. The entity that interacts with the system in a scenario is an actor. A use case, then, is a compilation and summary of all of the scenarios involved in an individual task. The figure below illustrates a use case diagram for a patient’s interactions with a medical clinic.
Figure3.12 includes 4 use cases and 4 actors. Remember, each use case is denoted by an oval, and each actor by a stick figure. Note that in this use case diagram, each use case involves 2 separate actors. When all of the information is
Customer
Fig. 3.11 Class diagram (Miller2003)
presented together, as it is here, the result is a use case diagram which describes not how this medical clinic functions, but, rather, what it does.
Use case diagrams are helpful in determining the features of a system, as each scenario can reveal some new information; in communicating with clients by providing a non-technical visualization of what a system will do; and in testing, by providing scenarios which can be used to develop test cases.
3.4.3 Sequence Diagram
As we have said, class and use case diagrams are considered static models of a system. They describe the structure and function of a system. Sequence diagrams, on the other hand, are a type of interaction diagram, which describe what takes place when the various entities associated with a system interact. A sequence diagram details not what operations are meant to do, but how they are performed, which includes the following: what information is changed, what communication takes place, and when those actions occur. Sequence diagrams, as the name sug-gests, are sequential based and derive their structure from a timeline. The top of a diagram represents the earliest time in the sequence, which then progresses downward. The actions performed are known as communications and can be thought of as the sending of messages. The objects involved in a message sequence are listed from left to right according to the order in which they participate in that communication. The diagram below is used to represent making a hotel reserva-tion (Fig.3.13).
Process Sale
Process Sale
Process Sale
Process Sale
Patient Scheduler
Doctor
Clerk
Fig. 3.12 Use case diagram (Miller2003)
3.4 Models 49
In the figure above, the sequence is initiated by the UserInterface instance of the window class, which sends a message to the HotelChain object via the makeReservation method. At this point, HotelChain then sends a makeReservationmessage to Hotel. Here we can see an iteration through which Hotel moves in order to test whether or not a room is available for each day requested. If this condition is met, Hotel creates the Reservation object, which in turns creates a Confirmation notice to complete the sequence. In this image, each box represents an object and each straight arrow depicts a message call. The vertical dotted lines represent lifelines, which define how long an object exists before destruction. The activation bars shown denote the time for the exe-cuting of the message. The topmost message call made by the Hotel object is a call back to itself, and is an iteration, which is denoted by the asterisk. Expressions shown in square brackets are conditions that are tested. The note contained in the rectangle is simply for clarification, and can be used in any UML diagram.
3.4.4 State Diagrams
An object’s state describes that object based on all of its properties and their values at a given instant in time. An object’s behavior is a response to its state, and thus changes based on its current state. Similarly, a state diagram describes a software system based on its behavior, and thus in relation to the states of the objects that
window
[for each day] isRoom := available():boolean
[isRoom]
If a room is available for each day of the stay, make a reservation and spend a
Fig. 3.13 Sequence diagram (Miller2003)
make it up. For the creation of a state diagram to be possible, the system must have a finite number of states, or an abstraction must be used to this end. State transition diagrams, similarly, depict all of the information involved in a state change, including the events that trigger the change and the actions that occur as a result of it. Harel provided the following common notations for use in state diagrams (Figs.3.14,3.15,3.16).
The first image is used to depict a state, which is given a unique name and, if necessary, some actions that are associated with it. The second shows a history icon, which can be attached to a state to indicate its’ lastly assumed state, which it will go into upon entry. The last image depicts state nesting, in which a superstate consists of some number of substates.
Actions are often associated with states in the sense that they occur when a state changes (i.e.: when a state is entered or exited). State transitions connect one state to another or one state back to itself, and denote the specific changes in state. Each state transition is unique, that is, given a certain set of circumstances (the overall state of the system) a certain trigger even must result in exactly one new state.
3.4.5 Activity Diagram
Similar to a state diagrams, activity diagrams provide a way of understanding a system based on the processes that occur within it. While a state diagram’s main
name actions Fig. 3.14 State icon (Harel
1987)
H
Fig. 3.15 History icon (Harel 1987)
state 1
state 1
state 1 superstate Fig. 3.16 Nesting (Harel
1987)
3.4 Models 51
focus is on an object and its response to changes in state, an activity diagram depicts all of the activities associated with a single process and the dependencies that relate those activities. The diagram below shows the processes involved in withdrawing money from an ATM. The black circle labeled start indicates the beginning of the process, and the similar circle labeled end denotes where the process stops.
As depicted in Fig.3.17, activity diagrams are divided into sections called swimlanes. The names at the top of each swimlane represent the three objects involved in our example: Customer, ATM Machine, and Bank. Each object is
Customer ATM Machine Bank
Insert card
Enter pin
Enter amount
Take money from slot
Take card
Show balance
Eject card
Authorize
Check account balance
Debit account swimlane
start
activity guard expression
branch
fork
join
merge
end
Fig. 3.17 Activity diagram (Miller2003)
responsible for all of the activities contained within its swimlane. The arrows depict transitions. Each activity results in a single outgoing transition, which can then branch into separate transitions, as denoted by the diamond symbol. For example, the outgoing transition from the Authorize activity branches into two possible transitions, one to the Enter Amount activity and the other to the merge diamond before the Eject Card activity. At runtime, the transition used will be determined by the existence of either the Valid PIN or InvalidPIN state. As evidenced by the branches-merge combination in this example, transitions branch apart due to some varied data and will eventually merge together again when the set of activities dependent on that data is complete. The solid black rectangles in the diagram depict forks, at which one transition forks into two or more parallel activities. Similar to a branch, the transitions created in a form will later join back together when the activities being carried out in parallel have been completed. The same solid black rectangle is used to indicate a join.
3.4.6 Collaboration Diagram
Like activity, state, and sequence diagrams, collaboration diagrams are inter-action diagrams that describe what a system does. They are very similar to sequence diagrams in that they show the same information, but collaboration diagrams focus on object-roles rather than a timeline. As the name suggests, object-roles describe the role that an object is to play; what it is to do as relative to the software system. The following diagram gives an example of a collaboration diagram (Fig.3.18).
window:UserInterface
aChain:HotelChain
aHotel:Hotel aReservation:Reservation
1.1 : makeReservation():void
1.1.1 : makeReservation():void
1.1.1.2 : [isRoom]
1.1.1.1 : *[for each day] isRoom:=available(): boolean
1.1.1.2.1 : message
object
iteration self link
sequence number
Fig. 3.18 Collaboration diagram (Miller2003)
3.4 Models 53
The rectangles in the diagram represent object-roles, labeled by the object name, class name or both (class names are always preceded by a colon (:). The arrows represent the messages being sent, and each is labeled with a number, with the top level message labeled 1. For each level below the top, a new number is appended, preceded by a decimal point. Messages on the same level share the same prefix number, different suffixes determined by the order in which they occur. For example two messages, one labeled 1.1.1 and 1.1.2, both originated at the second level down from the top, but the second occurred before the first.
3.4.7 Component Diagram
A component diagram is a code model used to indicate how various components are linked together in order to form either larger components or an entire software system. These provide an easy to understand visual for a system’s architecture. A component diagram is a very high level view of a software system, and is made possible by the generous use of abstraction. In a sense, a component diagram can be used as a map for the software system, made up of logical units of decompo-sition (Fig.3.19).
3.4.8 Deployment Diagram
A deployment diagram depicts the physical configuration of a software system upon hardware. This is a useful way of presenting a software project because it allows both the client and the developers to gain an understanding of the system’s distribution across physical resources from a unique overview. Figure3.20depicts such a system.