Lecture 08: UML
What is UML?
• Unified Modeling Language
– OMG Standard, Object Management Group
– Based on work from Booch, Rumbaugh, Jacobson
• UML is a modeling language to express and design
documents, software
– Particularly useful for OO design
– Not a process, but some have been proposed using UML
– Independent of implementation language
Why use UML
• Open Standard, Graphical notation for
– Specifying, visualizing, constructing, and documenting software systems
• Language can be used from general initial design to very specific detailed
design across the entire software development lifecycle
• Increase understanding/communication of product to customers and
developers
• Support for diverse application areas
• Support for UML in many software packages today (e.g. Rational, plugins for
popular IDE’s like NetBeans, Eclipse)
• Based upon experience and needs of the user community
Brief History
• Inundated with methodologies in early 90’s
– Booch, Jacobson, Yourden, Rumbaugh
• Booch, Jacobson merged methods 1994
• Rumbaugh joined 1995
• 1997 UML 1.1 from OMG includes input from others, e.g.
Yourden
• UML v2.0 current version
History of UML
Contributions to UML
Systems, Models and Views
• A model is an abstraction describing a subset of a system
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual rules for depicting views
• Views and models of a single system may overlap each other
Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system
Systems, Models and Views
Flightsimulator
Blueprints
Aircraft
Model 2
View 2
View 1
System
View 3
Model 1
Electrical
Wiring
Scale Model
UML Models, Views, Diagrams
• UML is a multi-diagrammatic language
– Each diagram is a view into a model
• Diagram presented from the aspect of a particular stakeholder
• Provides a partial representation of the system
• Is semantically consistent with other views
– Example views
Models, Views, Diagrams
How Many Views?
• Views should to fit the context
– Not all systems require all views
– Single processor: drop deployment view
– Single process: drop process view
– Very small program: drop implementation view
• A system might need additional views
– Data view, security view, …
UML: First Pass
• You can model 80% of most problems by using about 20
% UML
• We only cover the 20% here
Basic Modeling Steps
• Use Cases
– Capture requirements
• Domain Model
– Capture process, key classes
• Design Model
– Capture details and behaviors of use cases and domain objects
– Add classes that do the work and define the architecture
UML Baseline
• Use Case Diagrams
• Class Diagrams
• Package Diagrams
• Interaction Diagrams
– Sequence
– Collaboration
• Activity Diagrams
• State Transition Diagrams
• Deployment Diagrams
Use Case Diagrams
• Used during requirements elicitation to represent external behavior
• Actors represent roles, that is, a type of user of the system
• Use cases represent a sequence of interaction for a type of functionality; summary of
scenarios
• The use case model is the set of all use cases. It is a complete description of the
functionality of the system and its environment
PurchaseTicket
Passenger
Actors
• An actor models an external entity which communicates
with the system:
– User
– External system
Passenger
– Physical environment
• An actor has a unique name and an optional description.
• Examples:
– Passenger: A person in the train
– GPS satellite: Provides the system with GPS coordinates
Use Case
A use case represents a class of functionality provided by the system as
an event flow.
A use case consists of:
• Unique name PurchaseTicket
• Participating actors
• Entry conditions
• Flow of events
• Exit conditions
• Special requirements
Use Case Diagram: Example
Name: Purchase ticket Event flow:
1. Passenger selects the
Participating actor: Passenger number of zones to be
traveled.
Entry condition: 2. Distributor displays the amount
due.
• Passenger standing in front of ticket distributor.
3. Passenger inserts money, of
• Passenger has sufficient money to purchase ticket.
at least the amount due.
4. Distributor returns change.
Exit condition:
5. Distributor issues ticket.
• Passenger has ticket.
Anything missing?
Exceptional cases!
The <<extends>> Relationship
• <<extends>> relationships
represent exceptional or Passenger
seldom invoked cases.
• The exceptional event flows
are factored out of the main
event flow for clarity. PurchaseTicket
• Use cases representing
exceptional flows can extend <<extends>>
more than one use case.
• The direction of a <<extends>>
<<extends>> relationship is to <<extends>>
the extended use case OutOfOrder TimeOut
<<extends>>
Cancel NoChange
The <<includes>> Relationship
• <<includes>> relationship represents
behavior that is factored out of the use
case. Passenger
• <<includes>> behavior is factored out for
reuse, not because it is an exception.
PurchaseMultiCard
• The direction of a <<includes>>
relationship is to the using use case PurchaseSingleTicket
(unlike <<extends>> relationships). <<includes>>
<<includes>>
CollectMoney
<<extends>> <<extends>>
NoChange Cancel
Use Cases are useful to…
• Determining requirements
– New use cases often generate new requirements as the system is
analyzed and the design takes shape.
• Communicating with clients
– Their notational simplicity makes use case diagrams a good way for
developers to communicate with clients.
• Generating test cases
– The collection of scenarios for a use case may suggest a suite of test
cases for those scenarios.
Use Case Diagrams: Summary
• Use case diagrams represent external behavior
• Use case diagrams are useful as an index into the use
cases
• Use case descriptions provide meat of model, not the use
case diagrams.
• All use cases need to be described for the model to be
useful.
Class Diagrams
• Gives an overview of a system by showing its classes and
the relationships among them.
– Class diagrams are static
– they display what interacts but not what happens when they do
interact
• Also shows attributes and operations of each class
• Good way to describe the overall architecture of system
components
Class Diagram Perspectives
• We draw Class Diagrams under three perspectives
– Conceptual
• Software independent
• Language independent
– Specification
• Focus on the interfaces of the software
– Implementation
• Focus on the implementation of the software
Classes – Not Just for Code
• A class represent a concept
• A class encapsulates state (attributes) and behavior (operations).
• Each attribute has a type.
• Each operation has a signature.
• The class name is the only mandatory information.
TariffSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)
TariffSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TariffSchedule
Instances
• An instance represents a phenomenon.
• The name of an instance is underlined and can contain the class
of the instance.
• The attributes are represented with their values.
tarif_1974:TariffSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}
UML Class Notation
• A class is a rectangle divided into three parts Employee
– Class name
-Name : string
– Class attributes (i.e. data members, variables)
– Class operations (i.e. methods) +ID : long
• Modifiers #Salary : double
– Private: - +getName() : string
– Public: + +setName()
– Protected: # -calcInternalStuff(in x : byte, in y : decimal)
– Static: Underlined (i.e. shared among all members of the class)
• Abstract class: Name in italics
UML Class Notation
• Lines or arrows between classes indicate relationships
– Association
• A relationship between instances of two classes, where one class must know about the other to
do its work, e.g. client communicates to server
• indicated by a straight line or arrow
– Aggregation
• An association where one class belongs to a collection, e.g. instructor part of Faculty
• Indicated by an empty diamond on the side of the collection
– Composition
• Strong form of Aggregation
• Lifetime control; components cannot exist without the aggregate
• Indicated by a solid diamond on the side of the collection
– Inheritance
• An inheritance link indicating one class a superclass relationship, e.g. bird is part of mammal
• Indicated by triangle pointing to superclass
Binary Association
Binary Association: Both entities “Know About” each other
myB.service(); myA.doSomething();
Optionally, may create an Associate Class
Unary Association
A knows about B, but B knows nothing about A
myB.service(); Arrow points in direction
of the dependency
Aggregation
Aggregation is an association with a “collection-member” relationship
void doSomething() Hollow diamond on
aModule.service();
the Collection side
No sole ownership implied
Composition
Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Employee
Team
-Name : string
-members : Employee +ID : long
1 #Salary : double
-adfaf : bool
*
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
members[0] =
new Employee();
… Filled diamond on
delete members[0]; side of the Collection
Inheritance
Standard concept of inheritance
Base Class
Derived Class
class B() extends A
…
UML Multiplicities
Multiplicities Meaning
Links on associations to specify more details about the relationship
zero or one instance. The notation n . . m indicates n to m
0..1
instances.
0..* or * no limit on the number of instances (including none).
1 exactly one instance
1..* at least one instance
UML Class Example
Association Details
• Can assign names to the ends of the association to give
further information Employee
Team - group
- Name : string
- members : Employee - individual + ID : long
1 # Salary : double
- adfaf : bool
*
+ getName () : string
+ setName ()
- calcInternalStuff ( in x : byte , in y : decimal )
Static vs. Dynamic Design
• Static design describes code structure and object relations
– Class relations
– Objects at design time
– Doesn’t change
• Dynamic design shows communication between objects
– Similarity to class relations
– Can follow sequences of events
– May change depending upon execution scenario
– Called Object Diagrams
Object Diagrams
• Shows instances of Class Diagrams and links among
them
– An object diagram is a snapshot of the objects in a system
• At a point in time
• With a selected focus
– Interactions – Sequence diagram
– Message passing – Collaboration diagram
– Operation – Deployment diagram
Object Diagrams
• Format is
– Instance name : Class name
– Attributes and Values
– Example:
Objects and Links
Can add association type and also message type
Package Diagrams
• To organize complex class diagrams, you can group classes into
packages. A package is a collection of logically related UML
elements
• Notation
– Packages appear as rectangles with small tabs at the top.
– The package name is on the tab or inside the rectangle.
– The dotted arrows are dependencies. One package depends on another if
changes in the other could possibly force changes in the first.
– Packages are the basic grouping construct with which you may organize
UML models to increase their readability
Interaction Diagrams
• Interaction diagrams are dynamic -- they describe how
objects collaborate.
• A Sequence Diagram:
– Indicates what messages are sent and when
– Time progresses from top to bottom
– Objects involved are listed left to right
– Messages are sent left to right between objects in sequence
Sequence Diagram Format
Actor from
Use Case Objects
2
Activation 3
Lifeline Calls = Solid Lines
Returns = Dashed Lines
Sequence Diagram : Destruction
Shows Destruction of b
(and Construction)
Sequence Diagram : Timing
Slanted Lines show propagation delay of messages
Good for modeling real-time systems
If messages cross this is usually problematic – race conditions
Sequence Example: Alarm System
• When the alarm goes off, it rings the alarm, puts a message on
the display, notifies the monitoring service
Sequence Diagram Example
Hotel Reservation
Summary and Tools
• UML is a modeling language that can be used independent of development
• Adopted by OMG and notation of choice for visual modeling
– http://www.omg.org/uml/
• Creating and modifying UML diagrams can be labor and time intensive.
• Lots of tools exist to help
– Tools help keep diagrams, code in sync
– Repository for a complete software development project
– Examples here created with TogetherSoft ControlCenter, Microsoft Visio, Tablet UML
Exercises
• Time to practices
