“The Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, ... Grady Booch, James Rumbaugh, and Ivar Jacobson (1999).
Introduction to the UML
Page 1
Introduction to the UML Civil Engineering with Computing by Andrew Bond (Geocentrix Ltd) www.geocentrix.co.uk/oop
What is the UML? “The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system” Grady Booch, James Rumbaugh, and Ivar Jacobson (1999) The Unified Modeling Language User Guide, pXV The UML: # Provides a standard means of expressing design that reflects the best practices of industry # Aims to de-mystify the process of software system modelling # Adopts the best of the Booch, Rumbaugh, & Jacobson (“the three amigos”) notations # Has been accepted as a standard by the Object Management Group (OMG) - an industry-wide body The 4+1 view model The architecture of software-intensive systems can best be described by five interlocking views, each of which is a projection into the organization and structure of the system.
Design view
Implementation view
Use case view
The use case view encompasses the use cases that describe the behaviour of the system to its end-users. The design view encompasses the classes, interfaces, and collaborations that describe the problem and its solution. This view primarily supports the functional requirements of the system.
Process view
Figure 1. 4+1 view model (Booch et al, p31)
The process view encompasses the threads and processes that form the system’s concurrency and synchronization mechanisms. This view primarily addresses the performance, scalability, and throughput of the system. The implementation view encompasses the components and files that are used to assemble and release the system. The static aspects of this view are captured in component diagrams; the dynamic aspects in interaction, statechart, and activity diagrams. The deployment view encompasses the nodes that form the system’s hardware topology. This view addresses the distribution, delivery, and installation of the system. UML diagrams The UML defines various diagrams that can be used to visualize the static and dynamic parts of a computer system:
Introduction to the UML
Page 2 Diagram
Static diagram
Dynamic diagram
Class
Object
Use case
Component
Deployment
Collaboration
Sequence
Statechart
Activity
Figure 2. UML diagrams
Use case diagrams Use case diagrams help you to visualize the relationships between use cases and actors. Use case diagrams show the dynamic behaviour of a system.
Set Limits
Update Accounts
Accounting System Trading Manager Analyze Risks «uses»
«uses» Price Deal
Trader
Valuation
Capture Deal
«extends»
Salesperson Limits Exceeded
Figure 3. Example of a use case diagram (Fowler and Scott, p45) Use cases A use case describes a sequence of actions that a system performs on behalf of an actor (see below). In the UML, a use case is represented by an ellipse containing the name of the use case. In the example here (taken from a banking application), a use case named “Deposit money” is defined.
Deposit money
Introduction to the UML
Page 3
A use case describes what a system does, but does not specify how it does it. Actors An actor is a role that a user plays when interacting with the computer system. In this context, a user may be a human, a hardware device, or even another computer system. In the UML, an actor is represented by a stick figure with the name of the actor beneath it. In the example here, an actor named Customer is defined. An actor describes who uses the system.
Customer
System boundaries A system boundary is exactly what its name implies: the boundary of some system. In the UML, a system boundary is represented by a rectangular box with the name of the system inside it. In the example here, the system boundary of a bank is shown. Associations In a use case diagram, an association typically represents a relationship between an actor and one or more use cases. Associations are represented in the UML by straight lines connecting the actor to the use cases he or she carries out. In the example here, the customer deposits money, withdraws money, and orders a statement – all of which are within the boundaries of the bank’s system. Actors may be connected to use cases only by association. An association between an actor and a use case indicates that they communicate with each other, possibly by sending and receiving messages.
Bank
Bank Deposit money
Withdraw money
Customer Order statement
Generalization of actors In a use case diagram, you can define general types of actors and specialize them using generalization relationships. Generalization is represented in the UML by a white arrowhead pointing from the specialized thing to the generalized thing. In the example here, Commercial Customer is a special type of Customer (and Customer a general type of Commercial Customer). Generalization of use cases In a use case diagram, you can also define general types of use cases and specialize them using generalization relationships.
Customer
Commercial Customer
Deposit money
«extends»
Withdraw money
«extends»
Order statement As for actors, generalization of use cases is represented in the UML by a white «uses» arrowhead pointing from the specialized to Money transaction the generalized use case. However, these «uses» relationships are typically stereotyped by one Validate account of two keywords, extends or uses, depending number on their intent: # Extends indicates that the specialized use case is similar to the general use case but does something more (typically, the extended use case deals with a variation of the general use case)
Introduction to the UML
#
Page 4
Uses indicates that the specialized use case is a common part of several use cases and has been factored out to avoid repetition
In the example here, Deposit money and Withdraw money both extend Money transaction. Order statement and Money transaction both use Validate account number. Since generalization relationships are transitive, this implies that Deposit money and Withdraw money also use Validate account number. Example from the literature The use case diagram at the start of this section shows a financial trading system. There are four actors involved (Trading Manager, Trader, Salesperson, and Accounting System) and seven use cases. The relationships between the actors and use cases are as follows: The Trading Manager sets limits The Trader analyses risks, prices deals, and captures deals The Salesperson also captures deals The Accounting System updates accounts Two uses cases (Analyze Risks and Price Deals) use the Valuation use case The use case Limits Exceeded extends Capture Deal
# # # # # #
Class diagrams Class diagrams help you to visualize the relationships between classes, interfaces, and collaborations. Class diagrams show the static (structural) design of a system.
0..1
University
-chairperson
Department
-name : std::string -address : std::string -phone_number : std::string +Add(in who : Student) +Remove(in who : Student) +GetAllStudents() +Add(in which : Department) +Remover(in which : Department) +GetAllDepartments()
Instructor
-name : std::string 1
-name : std::string
+Add(in who : Instructor) +Remove(in who : Instructor) +GetAllInstructors()
1..*
1..*
0..1
1..*
1..*
1..*
