How can you explain the effect of
polluted water or global warming issue?
1 picture’s worth 1000 words
UNIFIED MODELING LANGUAGE
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?
Standard language for specifying, visualizing, constructing, and documenting
the artifacts of software systems, business modeling and other non-software
systems.
The UML represents a collection of best engineering practices that have proven
successful in the modeling of large and complex systems.
The UML is a very important part of developing object oriented software and the
software development process.
The UML uses mostly graphical notations to express the design of software
projects.
Using the UML helps project teams communicate, explore potential designs, and
validate the architectural design of the software.
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.5 current version
HISTORY OF UML
CONTRIBUTIONS TO UML
DIAGRAMS
Structure diagram
Object diagram
Class diagram
Component diagram
Deployment diagram
Package diagram
Composite structure diagram (UML 2.2)
Profile diagram (UML 2.2)
Behavior diagram
Interaction diagrams:
Sequence diagram
Collaboration diagram (communication diagram in UML 2.2)
Interaction overview diagram (UML 2.2)
Timing diagram (UML 2.2)
Use case diagram
Activity diagram
State diagram
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, machine model
Views: Radar, electrical wiring, fuel system
SYSTEMS, MODELS AND VIEWS
Flightsimulator
Weather
Radar
Aircraft
Model 2
View 2
View 1
System
View 3
Model 1
Electrical
Wiring
Machine 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 Passenger
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 Purchase Ticket
description of the functionality of
the system and its environment
ACTORS
An actor models an external entity which
communicates with the system:
User
External system
Physical environment
An actor has a unique name and an optional Passenger
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:
Purchase Ticket
Unique name
Participating actors
Entry conditions
Flow of events
Exit conditions
Special requirements
USE CASE DIAGRAM: EXAMPLE
Name: Purchase ticket Event flow:
1. Passenger selects the number of
Participating actor: Passenger zones to be traveled.
2. Distributor displays the amount
due.
Entry condition:
Passenger standing in front of 3. Passenger inserts money, of at
least the amount due.
ticket distributor.
Passenger has sufficient money to 4. Distributor returns change.
purchase ticket. 5. Distributor issues ticket.
Exit condition:
Passenger has ticket.
THE <<EXTENDS>> RELATIONSHIP
<<extends>> relationships
Passenger represent exceptional or
seldom invoked cases.
The exceptional event flows
are factored out of the main
PurchaseTicket event flow for clarity.
<<extends>>
<<extends>>
<<extends>> TimeOut
Use cases representing
OutOfOrder <<extends>>
exceptional flows can extend
more than one use case.
Cancel
NoChange
THE <<INCLUDES>> RELATIONSHIP
<<includes>> relationship
Passenger represents behavior that
PurchaseMultiCard
is factored out of the use
case.
<<includes>> behavior is
PurchaseSingleTicket <<includes>> factored out for reuse, not
<<includes>> because it is an
exception.
The direction of a
CollectMoney <<includes>> relationship
<<extends>> <<extends>> is to the using use case
(unlike <<extends>>
relationships).
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.
Explain?
USE CASE DIAGRAMS: SUMMARY
Explain?
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
Name
TariffSchedule
TariffSchedule Table zone2price
zone2price Attributes Enumeration getZones()
getZones() Price getPrice(Zone)
getPrice()
Operations
Signature
TariffSchedule
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.
UML CLASS NOTATION
A class is a rectangle divided into three parts
Class name
Class attributes (i.e. data members, variables)
Class operations (i.e. methods)
Modifiers
Private: -
Public: +
Protected: #
Static: Underlined (i.e. shared among all members of the class)
Abstract class: Name in italics
Employee
-Name : string
+ID : long
#Salary : double
+getName() : string
+setName()
-calcInternalStuff(in x : byte, in y : decimal)
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
Example?
myB.service(); Arrow points in direction
of the dependency
AGGREGATION
Aggregation is an association with a “collection-member” relationship
void Hollow diamond on
doSomething() the Collection side
aModule.service(); 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 side of
… the Collection
delete
members[0];
INHERITANCE
Standard concept of inheritance
Base Class
Derived Class
class B() extends
A
…
UML MULTIPLICITIES
Multiplicities Meaning
zero or one instance. The notation n . . m
0..1
indicates n to m instances.
no limit on the number of instances
0..* or *
(including none).
1 exactly one instance
1..* at least one instance
UML CLASS EXAMPLE
ASSOCIATION DETAILS
Employee
Team -group
Can -Name : string
assign
-members names to the ends of
: Employee the association
-individual +ID : long to give further information
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
PACKAGE EXAMPLE
Dispatcher Interface
Notification IncidentManagement
MORE PACKAGE EXAMPLES
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 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
COLLABORATION DIAGRAM
Collaboration Diagrams show similar information to sequence diagrams, except
that the vertical sequence is missing. In its place are:
Object Links - solid lines between the objects that interact
On the links are Messages - arrows with one or more message name that show the
direction and names of the messages sent between objects
Emphasis on static links as opposed to sequence in the sequence diagram
COLLABORATION DIAGRAM
ACTIVITY DIAGRAMS
Fancy flowchart
Displays the flow of activities involved in a single process
States
Describe what is being processed
Indicated by boxes with rounded corners
Swim lanes
Indicates which object is responsible for what activity
Branch
Transition that branch
Indicated by a diamond
Fork
Transition forking into parallel activities
Indicated by solid bars
Start and End
SAMPLE ACTIVITY DIAGRAM
Ordering System
May need multiple diagrams from
other points of view
ACTIVITY DIAGRAM EXAMPLE
STATE TRANSITION DIAGRAMS
Fancy version of a DFA
Shows the possible states of the object and the transitions that cause a change in
state
i.e. how incoming calls change the state
Notation
States are rounded rectangles
Transitions are arrows from one state to another. Events or conditions that trigger
transitions are written beside the arrows.
Initial and Final States indicated by circles as in the Activity Diagram
Final state terminates the action; may have multiple final states
STATE REPRESENTATION
The set of properties and values describing the object in a well defined instant are
characterized by
Name
Activities (executed inside the state)
Do/ activity
Actions (executed at state entry or exit)
Entry/ action
Exit/ action
Actions executed due to an event
Event [Condition] / Action ^Send Event
NOTATION FOR STATES
SIMPLE TRANSITION EXAMPLE
MORE SIMPLE STATE EXAMPLES
STATE TRANSITION EXAMPLE
Validating PIN/SSN
STATE CHARTS – LOCAL VARIABLES
State Diagrams can also store Borrow
their own
/ local variables, do processing on them
Library example counting booksN = N+1
checked out and returned
Is-Member Clean-Up
Start / N=0 Stop / N=0
Return /
N=N-1
COMPONENT DIAGRAMS
Shows various components in a system and their dependencies, interfaces
Explains the structure of a system
Usually a physical collection of classes
Similar to a Package Diagram in that both are used to group elements into logical
structures
With Component Diagrams all of the model elements are private with a public interface
whereas Package diagrams only display public items.
COMPONENT DIAGRAM NOTATION
Components are shown as rectangles with two tabs at the upper left
Dashed arrows indicate dependencies
Circle and solid line indicates an interface to the component
COMPONENT EXAMPLE - INTERFACES
Restaurant ordering
system
Define interfaces
first – comes from
Class Diagrams
COMPONENT EXAMPLE -
COMPONENTS
Graphical depiction
of components
COMPONENT EXAMPLE - LINKING
Linking
components
with
dependencies
DEPLOYMENT DIAGRAMS
Shows the physical architecture of the hardware and software of the deployed
system
Nodes
Typically contain components or packages
Usually some kind of computational unit; e.g. machine or device (physical or logical)
Physical relationships among software and hardware in a delivered systems
Explains how a system interacts with the external environment
SOME DEPLOYMENT EXAMPLES
DEPLOYMENT EXAMPLE
Often the Component Diagram is combined with the Deployment
SUMARY
DISCUSSION
PROBLEM
1. Draw Fit portal use case diagram
2. Describe the function “Send message” on Fit portal by an Activity diagram
3. Design the function “Send message” by a Sequence diagram
USE CASE DIAGRAM
ACTIVITY DIAGRAM
SEQUENCE DIAGRAM
THANKS FOR YOUR ATTENTION
