Arya Institute of Engineering &Technology, Jaipur

Presented By:
Satish Kumar Alaria
Department of CSE/IT
Subject: Software Engineering
Object-Oriented Analysis and Design

• Design review
• Object Modeling Technique
• Object-Oriented Analysis
• Object-Oriented Design
• Three models
• Object model
• Dynamic model
• Functional model
• Four phases
Design - Review

• Design transforms requirements into

• an architecture diagram
• subsystems, modules and their relationships
• a detailed design
• a specification of the abstract interface, data structures, and algorithms of each
module
• Also develops
• a review plan for ensuring the design meets the requirements
• a test plan for ensuring the implementation meets the design
Object-Oriented Software Development

• Object-Oriented Methodology
• development approach used to build complex systems using the
concepts of object, class, polymorphism, and inheritance with a
view towards reusability
• encourages software engineers to think of the problem in terms
of the application domain early and apply a consistent approach
throughout the entire life-cycle
• Object-Oriented Analysis and Design
• analysis models the “real-world” requirements, independent of
the implementation environment
• design applies object-oriented concepts to develop and
communicate the architecture and details of how to meet
requirements
Object Modeling Technique Process via UML (OMT
turned into UML)
• OMT [Rumbaugh et al.,1991] consists of
• building three complementary models of the system
• adding implementation details to the models
• implementing the models
• OMT includes a set of
• phases [processes]
• diagramming techniques
• OMT has four phases
• object-oriented analysis builds a real-world model
• system design determines overall architecture of system
• object design decides upon data structures and algorithms
• implementation translates design into programming
language
OMT Stages and Models

- Static structure of objects and their relationships

Analysis
- Model of real-world situation
- What ?

- Control aspects of the system

- Data value transforamtions

System Design

(dataflow diagrams)

Functional Model
- Overall architecture (sub-

Dynamic Model
(state diagrams)
(object diagram)

Object Model
systems)

Object Design
- Refinement of Design
- Algorithms/data structures to
implement each class

Implementation
- Translation of object classes
time

and
relationships to a particular
object-oriented language
System
Introduction to Object-Oriented Analysis

• Object-Oriented Analysis is the “requirements phase” of

Object-Oriented Software Development
– think of it as an alternative semi-formal technique

• Semi-formal technique • Reuses familiar tools

• class modeling • E-R diagrams
• dynamic modeling • Finite State Machines
• functional modeling • Data flow diagrams
• These steps focus on • Steps and diagrams
• data • are typically performed in parallel
• actions after initial class definition
• and their relationships • must be kept in synch
Object-Oriented Analysis

• Builds a real-world model from requirements

• client interviews
• domain knowledge
• real-world experience
• Model is more precise and concise than the informal
problem definition
• The model addresses three aspects of objects
• class structure and relationships
• sequencing of interactions and events
• data transformations and computations
Models of Object-Oriented Analysis

• Class Model • Data-Oriented

• static structure
• what objects are in the system?
• how are they related?
• Dynamic Model • Action-Oriented
• behavioral aspects
• what events occur in the system
• when do they occur and in what
order?
• Functional Model • Both Data and Actions
• data transformations
• “what” does the system do
OO Analysis and Design: Steps

• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel
or out of order
• All models must be kept in synch as changes are made
Class Modeling

• Identify objects and classes

• Prepare a data dictionary
• Identify associations between objects
• Identify class attributes and initial set of operations
• Organize object classes using inheritance
Classes, Attributes and Operations

• Attributes define the properties of the objects

• every instance of the class has the same attributes
• an attribute has a data type
• the values of the attributes may differ among instances
• Operations define the behavior of the objects
• action performed on or by an object
• available for all instances of the class
• need not be unique among classes

Class Attributes Operations

ball radius, weight catch, throw
football air pressure pass, kick, hand-off
baseball liveness hit, pitch, tag
Object Model Notation, Review

Class Name Classes are represented as rectangles;

InstanceVariable1 The class name is at the top, followed by attributes

InstanceVariable2: type (instance variables) and methods (operations)

Method1() Depending on context some information can be

Method2(arguments) return type hidden such as types or method arguments

Objects are represented as rounded rectangles;

(Class Name)
The object’s name is its classname surrounded by
InstanceVariable1 = value parentheses
InstanceVariable2: type
Method1() Instance variables can display the values that they
Method2(arguments) return type have been assigned; pointer types will often point
(not shown) to the object being referenced
OMT Instantiation Notation

Class Name
Class
attribute_1: data_type_1 = default_1
attribute_2: data_type_2 = default_2
...
attribute_m: data_type_m =
default_m

(Class Name)

Instance attribute_1 = value_1

attribute_2 = value _2
...
attribute_m = value _m
Instantiation - Example

Person (Person)

name Joe Smith

age age=39
weight weight=158

(Person)

Mary Wilson
age=27
weight=121
Inheritance

• Classes with a set of similar attributes and operations may

be organized into a hierarchical relationship
• Common attributes and operations are factored out and
assigned to a broad superclass (generalization)
• generalization is the “is-a” relationship
• superclasses are ancestors, subclasses are descendants
• A class can be iteratively refined into subclasses that
inherit the attributes and operations of the superclass
(specialization)
OMT Inheritance Notation

Generalization
Superclass

Class Ball
Attributes Radius, Weight
Operations Throw, Catch

Subclasses

Football Baseball Basketball

air pressure liveness air pressure , dimples
pass, kick, hand-off hit, pitch, tag shoot, dribble, pass

Specialization
Association and Links

• An association is a relation among two or more classes

describing a group of links, with common structure and
semantics
• A link is a relationship or connection between objects and
is an instance of an association
• A link or association is inherently bi-directional
• the name may imply a direction, but it can usually be inverted
• the diagram is usually drawn to read the link or association from
left to right or top to bottom
• A role is one end of an association
• roles may have names
OMT Association Notation

Class, Association, and Roles

Person Company
Works For

equivalent

Company Person
Employs
Employer Employee

Object and Link

(Person) (Company)
Works For
Johnson IBM
Association and Links

Country has-capital City

Class diagram
nam nam
e e

(Country) has-capital (City)

Canada Ottawa

(Country) has-capital (City)

Instance diagram
France Paris

(Country) has-capital (City)

Austria Vienna
Multiplicity of Associations

•Multiplicity is the number of instances of one class

that may relate to a single instance of an
associated class
• 1-to-1
• 1-to-many (0 or more)
• 1-to-(zero-or-one) ‘optional’
• 1-to-(one-or-more) ‘required’ 1+
• 1-to-n n
OMT Multiplicity Notation

Instructor Courses
1+ Teaches

Takes
6-65
Student

Each course has at least one instructor

and between 6 and 65 students
A student may take many courses
An instructor may teach many courses
Link attributes for associations

Person works-for Company

name name
address
salary
job title
Aggregation

• Aggregation is a special form of association that indicates

a “part-of” relationship between a whole and its parts
• Useful when the parts do not have independent existence
• A part is subordinate to the whole
• In an aggregation, properties and operations may be
propagated from the whole to its parts
OMT Aggregation Notation

Window

TitleBar ScrollBar Border

Multilevel aggregation

Microcomputer

1+

Monitor System box Mouse Keyboard

1+ 1+

Chassis CPU RAM Fan

An Example

FastData Inc. wants a subsystem to process office supply orders via the Web.
The user will supply via a form their name, password, account number, and a
list of supplies along with an indication of the quantities desired. The
subsystem will validate the input, enter the order into a database, and
generate a receipt with the order number, expected ship date, and the total
cost of the order. If the validation step fails, the subsystem will generate an
error message describing the cause of the failure.
Purpose of Example

• We will demonstrate the UML /OMT using this example

• Class modeling will be done first
• Dynamic and Functional modeling will occur next lecture
• Detailed design will also occur next lecture
• Things to remember
• This example does not demonstrate how the technique is applied to ALL problems. Be
sure to distinguish between the details of the example and the details of the
technique!
Nouns

• Out-of-Domain • Good Candidates

• Internal Web • employee
• Abstract • item (was office supplies)
• user name • receipt
• user password • order
• account number • order database
• order number • error message
• ship date • Notes
• total cost We have decided not to worry
• list of supplies about the Web in this design.
• office supplies -> item Instead we focus on the inputs and
outputs and defer the Web details
until later.
Class Model

employee order order DB

name number
password account
total cost

error message receipt item

explanation order number name
ship date quantity
total cost price
Class Model, continued

Since both receipts and error messages will be generated as output

it might make sense to have them as subclasses of a more general
class. We do not know enough yet to assign it attributes however.

response

error message receipt

explanation order number
ship date
total cost
Class Model, relationships

employee order order DB

name
number
password
account
total cost

1+

error message receipt item

explanation order number name

ship date quantity
total cost price
Overview - Object-Oriented Analysis and Design
• Three models
• Object model
• Dynamic model
• Functional model
• Four phases
• object-oriented analysis
• system design
• object design
• Implementation
• Detailed Design
• Integration Testing
OMT Analysis and Design: Steps

• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel
or out of order
• All models must be kept in synch as changes are made
Dynamic Modeling

• Prepare scenarios
• Identify events between objects
• Prepare an event trace for each scenario
• Build a state diagram
• Match events between objects to verify consistency
Dynamic Model Diagrams

• The dynamic model tracks behavior over time

• described in terms of change in objects or event sequences between objects
• Event Trace Diagrams
• show typical dialog or usage scenarios as well as exceptional and/or special cases
• State Diagrams
• relates events, states, and state transitions
• a scenario is a path through the state diagram
Events and Scenarios

• An event is something that occurs between objects

• events have attributes, which are the information transferred from one object to
another
• A scenario is a specific sequence of events representing a path through a
system’s states
• Legitimate scenarios
• common paths (e.g. frequently used functionality)
• Error conditions and known exceptions
• An event trace extends the scenario to clarify events between objects
Event classes and attributes

• Event Classes • Events

• airplane departs (airline, flight • United Flight 23 departs from
number, city) Rome
• mouse button pushed (button, • right mouse button pushed at (29,
location) 30)
• phone receiver lifted • phone receiver lifted
• digit dialed (digit) • digit dialed (2)
An example scenario

• Scenario for a phone call

• caller lifts receiver
• dial tone begins
• caller dials digit (2)
• caller dials digit (7)
• caller dials digit (7)
• caller dials digit (6)
• specified phone rings
• etc.
OMT Event Trace Notation

• objects are vertical lines • arrows indicate sender and receiver

• events are horizontal lines • time passes from top to bottom

Customer Pump Credit Corp

“select method of payment”
select “credit”
insert card
slide card through reader verify account
“select grade” return “approved”
select “premium”
“pump on”
display unit cost, total cost, gallons dispensed
pump gas
update display with total cost, gallons dispensed
charge total cost to account
Event Trace: example

Caller Phone line Callee

caller lifts receiver
dial tone begins
dials (2)
dial tone ends
dials (7)
dials (7)
dials (6)
ringing tone phone rings
answers phone
phones connected phones connected
callee hangs up
connection broken connection broken
caller hangs up
States and Transitions

• A state is an interval between events

• it may have an activity that can trigger starting, intermediate and ending events
• defined in terms of a subset of object attributes and links
• A state transition is a change in an object’s attributes and links
• it is the response of an object to an event
• all transitions leaving a state must correspond to distinct events
OMT State Notation

• states represented as nodes: rounded rectangles with state name

• initial state represented as solid circle
• final state represented as bull’s eye
• transitions represented as edges between nodes and labeled with an event name

Event-b
STATE-1 STATE-2

Event-a
Event- Event-e
c
STATE-3 Event-d result
OMT State Diagram - Example

Chess game

checkmate
Start White´s Black wins
turn
stalemate

black white
moves moves Draw

stalemate

Black´s
White wins
turn
checkmate
Guards, Activities and Actions

• Guards are boolean conditions on attribute values

• transition can only happen when guard evaluates to “true”
• automatic transitions occur as soon as an activity is complete (check guard!)
• Activities take time to complete
• activities take place within a state
• Actions are relatively instantaneous
• actions take place on a transition or within a state (entry, exit, event actions)
• output can occur with an event

A-STATE [guard-1]
STATE-1
entry / entry-action action-Event / action
do: activity-A
event-1 / action-1 output-Event / output
... guarded-Event [guard-2]
exit / exit-action
STATE-2
Guards, Activities and Actions - Example

Vending machine model

coins in (amount) / set balance
Collecting money
Idle cancel / refund coins coins in (amount) / add to balance

[item empty] select (item)

[change < 0]

do: test item and compute change

[change = 0] [change > 0]

do: dispense item do: make change

 OMT State Relationships
• States can be nested or concurrent
• Events can be split and merged event-1

Superstate (nesting) Superstate (concurrency)

event-1 substate-1 substate-3
substate-1 substate-2
event-2

event-3 substate-2 substate-4

event-2

(Synchronization)
event-1 substate-3
split-event-0 substate-1 merged-event-3

event-2 merged-event-4
substate-2 substate-4
State Generalization: example

Transmission

push N
Neutral Reverse
push R

push N push F

Forward upshift upshift

stop
First Second Third

downshift downshift
Returning to the FastData example

• Lets define a scenario for an office supply order processor: a successful order
• Alternatively we could describe a scenario for an unsuccessful order
• Assumptions
• We are not going to consider how the order form is transmitted to our system nor how
our receipt is transmitted back
• The employee object is responsible for validating the input to the system
A successful order

• input received (we don’t care how)

• create employee object
• pass input to employee
• validate name and password
• create order object
• validate account number
• for each item
• create item
• add item to order and validate item
• compute total cost
• add order to order DB and retrieve order number and ship date
• generate receipt
• return receipt (we don’t care how)
Event Trace

Employee Order Item Receipt Order Employee Product Account

DB DB DB DB
validate name/password

validated
create

validate account number

validated

create

add
repeat

validate item
validated
Event Trace, continued

Employee Order Item Receipt Order Employee Product Account

DB DB DB DB
compute cost

retrieve cost

add order

retrieve order number

retrieve ship date

create
(One Possible) State Transition Diagram

input
Employee Initialization
Created
received
Idle validated
Employee Order
Validated Created
create
return
receipt validated

Finalize Process Order

Create [remaining
do: add order Item items > 0]
add
create receipt Process Order
Order Finished?
validated
[remaining items = 0]
OMT Analysis and Design: Steps

• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel
or out of order
• All models must be kept in synch as changes are made
Functional Modeling

• Identify input and output values

• Build data flow diagrams showing transformation and functional
dependencies (expanding non-trivial processes)
• Describe functions (in some language)
• Identify constraints between objects
(add to DM and FM)
OMT DFD Notation

• Processes transform data

• Actors are sources or sinks of data (= Active Objects)
• Data stores are persistent repositories of data, which may be accessed or
updated (= Passive Objects)
• Data flows between processes, actors, and data stores

data-1 sink-data
Process-1 Process-2 Actor-2

source-data data-2

Actor-1 DataStore-1
Data Value Notation

• Data may be a composed, decomposed, or duplicated

data-1
composite

data-2

data-1
data-
1
composite data-1

data-1
data-
2
Control Flow in the DFD

coded
password Account

verify
password password balance
OK
amount
Customer update
cash
Hierarchical DFD

• High-level functionality iteratively refined into smaller functional

units
• each high-level process may be expanded into a separate DFD
• top-level processes correspond to operations on complex objects, while
lower-level processes are operations on basic objects
• Nesting depth is dependent on application
• terminates with simple functions
• each level must be coherent
• Hierarchical DFD corresponds to the following
• context diagram shows boundaries of system
• mid-level DFDs show context decomposition
• primitive DFDs are simple functions that need not be expanded
Data Flow Diagram: Office Supply example

Employee Account
DB DB

verification name/ verification

account
password number

Web input validate employee validate order

Server stream employee order

response (receipt)
Data Flow Diagram: Office Supply example

Product Order
DB DB

verification item order order

info
order process validated finalize
order order order

response (receipt)
OMT Analysis and Design: Steps

• Class Modeling
• Dynamic Modeling
• Functional Modeling
• Add Operations to the Class Model
• Iterate and refine the models
• After the first iteration, steps may occur in parallel
or out of order
• All models must be kept in synch as changes are made
 Add Operations to the Object Model
• From the Object Model:
• Reading/writing object attributes (e.g., get_width, get_height of Rectangle)
• From Events, State Actions, and Activities
in the Dynamic Model:
• Each event sent to an object => operation
(e.g., Vending machine: set_balance)
• Actions/activities may be operations
(e.g., Vending machine: do: test item and compute change)
• From Functions in the Functional Model:
• Each function in the DFD corresponds to an operation (e.g., bank example: subtract
withdrawal from Account)
Relation of the three models

Things
object model

Transformations
Interactions functional model
dynamic model
Relation of Dynamic Model
to Class Model
• Dynamic model provides a second dimension - time - to objects and
classes
• Dynamic model builds upon and is derived from object model
• states in dynamic model represent sets of attribute and link values in object
model
• events in dynamic model represent operations in object model
• Relation between organization
• inherent differences in objects are distinguished in object model as distinct
classes
• temporal differences in object attributes are distinguished in dynamic model
as distinct states
Relation of Functional Model
to Class and Dynamic Model
• Functional model describes the actions (what), the dynamic model
describes the timing (when), and the class model describes what
takes action (who)
• Functional model builds upon and is derived from class model
• processes in the functional model correspond to operations on objects
• The input streams of processes in the functional model identify objects that
are related by function
• data flows in the functional model correspond to objects or attribute values
in the class model
• Functional model may capture actions not part of any scenario
OMT: Four phases

• Object-oriented analysis
• builds a real-world model
• System design
• determines overall architecture of system
• Object design
• decides upon data structures and algorithms
• Implementation
• translates design into programming language
System Design

• Devises high-level strategy for solving problem

• Set trade-off priorities
• Construct system architecture by organizing into subsystems (system
structuring)
• Choose an approach for persistent data management (repository
model)
• Allocate components to processors and tasks (distribution model)
• Choose the implementation of control in software system (control
modeling)
• Identify concurrency inherent in the problem
• Define access to global resources
• Divide problem into implementable components (modular
decomposition)
Object Design

• Full definition of all the classes in the system

• Implementation alternatives evaluated and chosen
• Combine three models to obtain class operations
• Design algorithms to implement operations
• Optimize access paths to data
• Implement control for external interactions
• Adjust class structure to increase inheritance
• Design associations
• Determine object representation
• Package classes and associations into implementable modules
Detailed Design

• Detailed design is the process of completely specifying an

architectural design such that module implementation can proceed
(independently)
• Interface specifications
• brief description of each module
• attributes
• brief description and specify types
• operations
• brief description
• list of parameters and parameter types
• return type (if applicable)
Detailed Design, continued

• Algorithm and data structure specification

• the designer can give hints as to what algorithms or data structures might be
most useful for a particular module
• also, the client may have specified a particular algorithm or data structure
that must be used
• in addition, constraints in the requirements may require one approach over
another
• for instance, implementing a data structure so that it uses the minimum amount of
memory possible vs. keeping everything in memory for speed
Mapping design into code

• Most programming languages provide very similar sets of features

• user-defined types
• control structures
• if...then...else...
• while x do y
• for i = 1 to x
• etc
• etc.
• This means that, in general, operations can be expressed in many
different languages
Mapping design into code, continued

• Major differences between languages usually fall into these

categories
• compiled vs. interpreted
• procedural vs. object-oriented
• general purpose vs. application/domain specific
• e.g. C++ vs. FileMaker Pro’s scripting language
• If a design takes advantage of, or depends on, one or more of these
features then certain programming languages have to be excluded
from implementation
Modularity Mechanisms

• One import feature of any programming language is how it can

represent modules directly
• C and C++ have separate header and body files
• Java has package names and class files
• Ada has a construct called a package with a specification and body
(implementation)
• etc.
• These features are important since it makes it easier to map the
design into code and to trace a code module back to its design
counterpart
Arya Institute of Engineering &Technology, Jaipur

Presented By:
Satish Kumar Alaria
Department of CSE/IT
Subject: Software Engineering Lab
 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
 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, …
 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

Passenger • 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
PurchaseTicket all use cases. It is a complete
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
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.

PurchaseTicket A use case consists of:

• 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
Entry condition: due.
• Passenger standing in front of 3. Passenger inserts money, of at
ticket distributor. least the amount due.
• Passenger has sufficient 4. Distributor returns change.
money to purchase ticket. 5. Distributor issues ticket.

Anything missing?
Exit condition:
• Passenger has ticket.
Exceptional cases!
 The <<extends>> Relationship
• <<extends>> relationships represent
exceptional or seldom invoked cases.
• The exceptional event flows are
Passenger factored out of the main event flow for
clarity.
• Use cases representing exceptional
flows can extend more than one use
PurchaseTicket case.
• The direction of a <<extends>>
<<extends>> relationship is to the extended use case

<<extends>>
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
 The <<includes>>
Relationship
• <<includes>> relationship
represents behavior that is
Passenger
factored out of the use case.
• <<includes>> behavior is
factored out for reuse, not because
PurchaseMultiCard it is an exception.
PurchaseSingleTicket • The direction of a <<includes>>
<<includes>> relationship is to the using use
<<includes>> case (unlike <<extends>>
relationships).

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
TariffSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TariffSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations 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.
 Instances
tarif_1974:TariffSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

• 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.
 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

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
Links on associations to specify more details about the relationship

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
• 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
Package Example

DispatcherInterface

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 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
 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 their own local
variables, do processing on them
• Library example counting books checked out
and returned
Borrow /
N = N+1

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

 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
– Other tools:
• Rational Rose, Cetus, Embarcadero
• See http://plg.uwaterloo.ca/~migod/uml.html for a list of tools, some free