You are on page 1of 81

UML

Lecture on

Building Blocks of UML

At

Indur Institute of Engineering & Technology,Siddipet

On
02- July-2010

by
N V Ganapathi Raju
Associate Professor,GRIET,Hyderabad

OOAD 1
UML

O O Philosophy

 Most traditional development methodologies are either


algorithm centric or data centric.

 In an algorithm-centric methodology, an algorithm that


can accomplish the task.

 In a data-centric methodology, we think how to


structure the data , then build the algorithm around that
structure.

OOAD 2
UML

Survey of Methodologies

 Many methodologies are available for system development.

 Each methodology is based on modeling the business problem


and implementing the application in OO fashion.

 The differences lie preliminary in the documentation of


information and modeling notations and language.

 Application can be implemented in many ways to meet same


requirements and provide same functionality.

OOAD 3
UML

UML (Unified Modeling Language)


 An emerging open standard for modeling object-oriented software.
 Resulted from the convergence of notations from three leading object-
oriented methods:
 OMT (James Rumbaugh), OOSE (Ivar Jacobson), Booch (Grady Booch)
 Supports the entire software development lifecycle
 Supports diverse applications areas
 Supported by several CASE tools

 e.g. Rational ROSE, Visual Paradigm


 Three categories
 Modeling Elements (Things)
 Relationships
 Diagrams

OOAD 4
UML
Why do we model?
 Provide structure for problem solving
 Experiment to explore multiple solutions
 Furnish abstractions to manage complexity
 Reduce time-to-market for business problem solutions
 Decrease development costs
 Manage the risk of mistakes
The UML is a graphical
language for
specifying
visualizing
constructing
documenting

OOAD 5
UML

Building Blocks of UML


1. Things
- structural things
- behavioral things
- grouping things
- annotational things
2. Relationships
- dependency
- generalization
- association
- realization

OOAD 6
UML

3. Diagrams ( 9 types of diagrams)


- class diagrams
- object diagrams
- component diagrams
- deployment diagrams
(to view static parts of the system)
- use case diagram
- Sequence diagrams
- collaboration diagrams
- state chart diagrams
- activity diagrams
( to view dynamic parts of a system)

OOAD 7
UML

Building Blocks

OOAD 8
UML
UML Concepts and Notation1
UML

Things Relationships Diagrams


Dependency Use case
Association Class
Generalization Sequence
Collaboration
State chart
Activity
Component
Deployment
Structural Behavioral Grouping Annotational
Use case Interaction Package Note
Class State Machine Model
Active Class Subsystem
Interface Framework
Component
Collaboration
Node

OOAD 9
UML

Modeling Elements
 Structural elements
 class,
interface, collaboration, use case, active class, component
 Behavioral elements
 interaction, state machine

 Grouping elements
 package, subsystem

 Other elements
 note

OOAD 10
UML

Structural Elements

OOAD 11
UML

Class

OOAD 12
UML

Interface

OOAD 13
UML

Collaboration

OOAD 14
UML

Use Case

OOAD 15
UML

Active Class

OOAD 16
UML

Component

OOAD 17
UML

Node

OOAD 18
UML

Behavioral Elements

OOAD 19
UML

Interaction

OOAD 20
UML

State Machine

OOAD 21
UML

Package

OOAD 22
UML

Note

OOAD 23
UML

Relationships

 Dependency
 Association
 Generalization
 Realization

OOAD 24
UML
UML Concepts and Notation
Class Active Class Package Component
Name Name Name
Attributes Attributes
(private) (private)
Operations Operations
(public) (public)
Respon- Respon-
sibilities sibilities
(public) (public)
Analysis Analysis Analysis
Entity Class Boundary Class Control Class
Use case Actor

Action
Relationships
Association
Note Dependency or Flow
Realization
Textual Generalization
content Composition
Aggregation

OOAD 25
UML

Dependency

OOAD 26
UML

Association

OOAD 27
UML

OOAD 28
UML

Association
• A link between two classes
• Name
• Multiplicities

Employee Department

Name 1..1 Manages 0..1 Name


Ssn Number
Birth Address
Sex ……
Manages
……
StartDate
OOAD 29
UML

Association Multiplicity
1 : Necessary
0..1 : Optional
0..* or * : Unspecified
1..* : One or more
1..n : between 1 and n
n,m,l : n, m or l

OOAD 30
UML

Qualified association

* 0..1
Bank Person
Account
number

• A person can be associated with many banks.


• Given a bank and an account number, there is at most one person with
that account number at that bank.

OOAD 31
UML

Associations

TarifSchedule TripLeg
Enumeration
getZones() price
Price
* * zone
many-to-many
getPrice(Zone)

Country Has- City


1 capital 1
name:String name:String
1-to-1

Polygon Point
1 *
1-to-many x:Integer
draw() y:Integer

OOAD 32
UML

Aggregation
(special case of association)

 An aggregation is a special case of association denoting a “consists of”


hierarchy.
 The aggregate is the parent class, the components are the children class.

Exhaust System

1 0..2
Muffler Tailpipe

OOAD 33
UML

OOAD 34
UML

Composition

 A solid diamond denote composition, a strong form of aggregation


where components cannot exist without the aggregate.

TicketMachine

3
ZoneButton

OOAD 35
UML

OOAD 36
UML

Generalization

OOAD 37
UML

OOAD 38
UML

OOAD 39
UML

Realization

OOAD 40
UML

OOAD 41
UML

Visibility
• Each contained element has a visibility relative to
the containing package
– A public element is visible to elements outside the
package, denoted by ‘+’
– A protected element is visible only to elements within
inheriting packages, denoted by ‘#’
– A private element is not visible at all to elements
outside the package, denoted by ‘-’
• Same syntax for visibility of attributes and
operations in classes

OOAD 42
UML

Extensibility Mechanisms

 Stereotype : extends the vocabulary of the UML


 Tagged value : extends the properties of UML building blocks
 Constraint : extends the semantics of a UML building blocks

OOAD 43
UML
DIAGRAMS

OOAD 44
UML
Diagrams

Class
Diagrams
Use Case
Diagrams Object
Sequence Diagrams
Diagrams

Collaboration Models Component


Diagrams Diagrams

Statechart Deployment
Diagrams Diagrams
Activity
Diagrams

OOAD 45
UML

Views

 There are nine standard diagrams

 Static views: use case, class, object, component, deployment

 Dynamic views: sequence, collaboration, state chart, activity

 Implementation view : component diagrams

 Deployment view: Deployment diagram

OOAD 46
UML
Class Diagram
 Shows a set of classes, interfaces and collaborations, and their
relationships.
 Address static design view of a system
 Class diagrams are used
 during requirements analysis to model problem domain concepts
 during system design to model subsystems and interfaces
 during object design to model classes.

 Purpose
 Name and model concepts in the system
 Specify logical database schemas
 Rrepresent the structure of the system.

 A class represent a concept and encapsulates state (attributes) and


behavior (operations).
 attribute has a type.
 operation has a signature.

OOAD 47
UML

Class Diagrams

TariffSchedule
Table zone2price Name
Enumeration getZones()
Signature Price getPrice(Zone)

Class
Multiplicity SimpleWatch Association
1 1 1 1
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load() now()
push() blinkSeconds(
release() )
blinkMinutes(
) Attributes
blinkHours()
stopBlinking(
) Operations
OOAD referesh()
48
UML

Object Diagram
 Built during analysis and design

 Shows a set of objects and their relationships

 Static snapshots of element instances found in class diagrams

 Purpose
 Illustrate
data/object structures
 Specify snapshots
 Captures instances and links

 Developed by analysts, designers, and implementers

OOAD 49
UML

Object Diagram

OOAD 50
UML

Use Case Diagrams


Package
SimpleWatch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

Use case
ChangeBattery

OOAD 51
UML

Actors

 An actor models an external entity which communicates with the system


by sending and receiving messages, and exchanging data and events. :
 user, external system, physical environment

 An actor has a unique name and an optional description to represent roles


people or devices play as the system functions
 Examples:
 Passenger: A person in the train
 GPS satellite: Provides the system with GPS coordinates
 ATM, the client is an actor who can withdraw money from an
account, transfer money to an account, or check balance of an account

OOAD 52
UML

Use Case
 Shows a set of actors and use cases, and their relationships

 Address static use case view of the system

 Is important for organizing and modeling the external behavior of


the system

 A use case consists of:


 Unique name
 Participating actors
 Entry conditions
 Flow of events
 Exit conditions

OOAD 53
UML

Use Case Diagram


 Captures system functionality as seen by users and from user’s point
of view

 Used during requirements elicitation to represent external behavior

 Built in early stages of development

 Purpose
 Specify the context of a system
 Capture the requirements of a system
 Validate a system’s architecture
 Drive implementation and generate test cases

 Developed by analysts and domain experts

OOAD 54
UML

Use Cases Example

 ATM. The client (actor) can withdraw money from an account,


transfer money to an account, or check the balance of an account.
These operations, correspond to flows, which can be represented
by use cases.

Transfer Money

Withdraw Money Client Check Balance

OOAD 55
UML

Use Case Example

OOAD 56
UML

Use Case Example

Name: Purchase ticket Event flow:


1. Passenger selects the number
Participating actor: Passenger of zones to be traveled.
2. Distributor displays the amount
Entry condition: due.
 Passenger standing in front 3. Passenger inserts money, of
of ticket distributor. at least the amount due.
 Passenger has sufficient 4. Distributor returns change.
money to purchase ticket. 5. Distributor issues ticket.

Exit condition: Anything missing?


 Passenger has ticket.

Exceptional cases!
OOAD 57
UML
Sequence Diagram
 shows interactions consisting of a set of objects and the messages sent
and received by those objects.
 Used during requirements analysis
 To refine use case descriptions
 to find additional objects (participating objects)
 Used during system design
 to refine subsystem interfaces
 Classes are represented by columns
 Messages are represented by arrows
 Activations are represented by narrow rectangles to sent the message,
and is as long as all nested activations
 Lifelines are represented by dashed lines
 Purpose
 Captures dynamic behavior (time-oriented) in terms of interactions.
 Model flow of control
 Illustrate typical scenarios
 Complement the class diagrams which represent structure.
OOAD 58
UML
Sequence Diagram
Objec
t
:SimpleWatch :LCDDisplay :Time
:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

pressButton2() incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Message
Activation

OOAD 59
UML

Sequence Diagram

OOAD 60
UML

Collaboration Diagram

 Shows the structural organization of objects that send and receive


messages.

 Sequence and Collaboration diagrams :


are jointly called interaction diagrams
can be transformed one into another.

OOAD 61
UML
Collaboration Diagram contd..
 Captures dynamic behavior (message-oriented)
 Purpose
 Model flow of control
 Illustrate coordination of object structure and control

OOAD 62
UML

Activity Diagrams
 Shows control/data flows from one activity to another
 Emphasizes the flow of control among objects
 Purpose
 Model business workflows, flow control within a system, and
operations
 Captures dynamic behavior (activity-oriented)

 Two types of states:


 Action state:

 Cannot be decomposed any further


 Happens “instantaneously” with respect to the level of
abstraction used in the model
 Activity state:

 Can be decomposed further


 The activity is modeled by another activity diagram
OOAD 63
UML

OOAD 64
UML

Activity Diagrams: Modeling Concurrency


 Synchronization of multiple activities
 Splitting the flow of control into multiple threads

Splitting Synchronization

Allocate
Resources

Open Coordinate Archive


Incident Resources Incident

Document
Incident

OOAD 65
UML

Activity Diagrams: Swimlanes

 Actions may be grouped into swimlanes to denote the object or


subsystem that implements the actions.

Dispatcher
Allocate
Resources

Open Coordinate Archive


Incident Resources Incident

FieldOfficer
Document
Incident

OOAD 66
UML

Statechart Diagram
 Shows a state machine consisting of states, transitions, events , and
activities

 Address the dynamic view of a system

 Is important in modeling the behavior of an interface, class

 Emphasizes the event-driven ordering

 Purpose
 Model object lifecycle
 Model reactive objects (user interfaces, devices, etc.)

OOAD 67
UML
Statechart Diagrams
Initial State
Event
state
button2Pressed
button1&2Pressed Blink Increment
Hours Hours

Transition button1Pressed

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes

button1Pressed

button2Pressed
Stop Blink Increment
Blinking Seconds Seconds
button1&2Pressed

Final state
OOAD 68
UML

Component Diagram

 Shows the organizations and dependencies among a set of


components

 Address the static implementation view of a system

 Captures the physical structure of the implementation

 Purpose
 Organize source code
 Construct an executable release
 Specify a physical database

 Developed by architects and programmers

OOAD 69
UML

Component Diagram

OOAD 70
UML

Deployment Diagram

 Shows configuration of run-time processing nodes and the


components hosted on them

 Address the static deployment view of an architecture

 Captures the topology of a system’s hardware

 Purpose
 Specify the distribution of components
 Identify performance bottlenecks

 Developed by architects, networking engineers, and system


engineers

OOAD 71
UML

Deployment Diagram

OOAD 72
UML

How all diagrams are useful in a software project development?

OOAD 73
UML

Representing System Architecture

Logical View Implementation


View
End-user Programmers
Functionality Software management
Use Case View

Process View Deployment View


System integrators System engineering
Performance System topology
Scalability Delivery, installation
Throughput Communication

Conceptual Physical

OOAD 74
UML

The use case view

 encompasses the use cases that describe the behavior of the


system as seen by its end users, analysts, and testers.
 doesn't really specify the organization of a software system.
 exists to specify the forces that shape the system's architecture.
 With the UML:

 the static aspects of this view are captured in use case


diagrams;
 the dynamic aspects of this view are captured in interaction
diagrams, state-chart diagrams, and activity diagrams

OOAD 75
UML

The design view:

 encompasses the classes, interfaces, and collaborations that


form the vocabulary of the problem and its solution.
 primarily supports the functional requirements of the system,
meaning the services that the system should provide to its end
users.
 With the UML:

 the static aspects of this view are captured in class diagrams and
object diagrams;
 the dynamic aspects of this view are captured in interaction
diagrams, state-chart diagrams, and activity diagrams.

OOAD 76
UML

The process view:

 encompasses the threads and processes that form the system's


concurrency and synchronization mechanisms.
 primarily addresses the performance, scalability, and throughput
of the system.
 With the UML:

 the static and dynamic aspects of this view are captured in the
same kinds of diagrams as for the design view, but with a focus on
the active classes that represent these threads and processes.

OOAD 77
UML

The implementation view:

 encompasses the components and files that are used to assemble


and release the physical system.
 primarily addresses the configuration management of the
system's releases, made up of somewhat independent
components and files that can be assembled in various ways to
produce a running system.
 With the UML:
 the static aspects of this view are captured in component
diagrams;
 the dynamic aspects of this view are captured in interaction
diagrams, statechart diagrams, and activity diagrams.

OOAD 78
UML

The deployment view

 encompasses the nodes that form the system's hardware


topology on which the system executes.
 This view primarily addresses the distribution, delivery, and
installation of the parts that make up the physical system.
 With the UML:

 the static aspects of this view are captured in deployment


diagrams;
 the dynamic aspects of this view are captured in interaction
diagrams, statechart diagrams, and activity diagrams.

OOAD 79
UML
Selecting a View
 If you are modeling a simple monolithic application that runs on a
single machine then:
use case view: use case diagrams
design view: class, interaction diagrams
process view: None required
implementation view: None required
Deployment view: None required

• If you are modeling a complex distributed system, you will need to


employ full range of UML diagrams
use case view: use case diagrams, activity diagrams
design view: class, interaction, state chart diagrams
process view: class, state chart diagrams
implementation view: component diagrams
Deployment view: Deployment diagrams

OOAD 80
UML

END

OOAD 81

You might also like