OO/UML 1

Contents

• Use-Case modeling
• Class and Object modeling
• Object-Interaction modeling
OO/UML 2

The Object-Oriented Paradigm

• Object-oriented modeling is a way of decomposing problems

• A system is viewed as a collection of loosely connected
entities, called objects.
• Each object is responsible for performing specific tasks.
• Objects can request services (tasks) from each other.
• System behavior emerges from the chaining of such service
requests.
• Each object has structure and behavior
• Every object is an instance of some class (i.e. type). The
behavior of an object is dictated by this class.
• All instances of a class will behave in a sufficiently similar
fashion in response to a similar request.
OO/UML 3

Modeling Purpose

• Object-Interaction modeling shows how a combination of use cases can

be realized through chaining services provided by objects.
• Object-Interaction modeling is auxiliary. It is not a desired result, it is a
means of obtaining a more complete specification.
– Class diagrams and Statecharts fully specify an object system
• Interaction modeling is intended to uncover:
– Basic responsibilities of objects
– Services (operations) that help to fulfil the responsibilities
OO/UML 4

Types of Interaction Diagrams

• There are two equivalent ways of presenting interactions
– Collaboration diagram
• A collaboration shows objects, their links and the messages they exchange
possibly with a sequence number
• A collaboration diagram may contain information of various scenario’s belonging
to various use-cases
– Sequence diagram
• A sequence diagram shows the objects and one scenario of exchanging
messages that correspond to a use case.
• It shows them in a time ordered fashion
• The two ways of presenting interactions are largely equivalent.
OO/UML 5

Sequence Diagram: Example

• Simple messages

John : User : ATM : Bank : Consortium

insert card
verify card
verify account

account not ok
reject card

remove card
OO/UML 6

Collaboration: Example
• Simple messages

1: insert card
John : User

6: remove card
2: verify card
: ATM

5: reject card
3: verify account
: Bank

4: account not ok

: Consortium
OO/UML 7

Sequence Diagram: Example

• Mixed messages (asynchronous and call messages)

liftRequestUpButton[i] : LiftSystem : LiftCage

: LightedButton
: Visitor
press( )
visitUp(i)
allocateCage()

visit(i)

– Call message: caller waits for answer before he continues

– Asynchronous message: caller continues after sending message
– Synchronous message: caller blocks until callee is ready to receive
• Rendez-vous
• Buffered communication
OO/UML 8

Collaboration: Example
• Mixed messages

1: press()
: Visitor

2: visitUp(i)
upButton[i]
: LightedButton

2.2: visit(i)
: LiftSystem

: LiftCage
2.1: allocateCage()
OO/UML 9

Use-Case Analysis
• Analysis of how the system fulfills Use Cases
Approach is interface driven exploration of the system
– Looking at the boundaries of the system
• Boundary objects
– Uncovering responsibilities of objects
• Boundary objects
• Control objects
<<boundary>>

<<control>>

Use-Case
behavior
System coordination
boundary
System <<entity>>
information
OO/UML 10

Use-Case Analysis Steps

• Review Use-Case descriptions
• For each Use Case :
– Identify the boundary objects
– Identify the events between the actors and the boundary objects
– Identify other analysis objects that are by their nature involved in handling the event
– Distribute Use Case behavior over analysis objects
• The allocated behavior must fit the object’s structure and states
• For each analysis class :
– Describe responsibilities
– Check attributes and associations required for carrying out the responsibilities
– Describe operations
• Unify analysis classes
OO/UML 11

Responsibilities
• What are responsibilities?
• How to find them?

Interaction (collaboration) Diagram

:LiftCage :Door

// performResponsibility

Class Diagram Door

// performResponsibility
OO/UML 12

Use-Case analysis: Lift

• Boundary classes receiving actor events:
– Buttons
– DoorDetector
– ...
• When the user presses the liftUpButton on a floor, the following responses of
the system are needed:
– Allocating a cage
– Getting the lift cage to move to the floor
– Approaching the floor
– Opening the door
– Clearing the button
– Sounding the chime
OO/UML 13

Button pressed
• The system has to process the press-button event
– Interface object: aButton
– Event: press()
– Responsible class: Button
– Response: inform other objects about a lift request
– Responsibility description of class Button:
• each button handles presses from the user and notifies its observer of such events
OO/UML 14

Process lift request

• Process the lift-request
– Required information: what floor must be serviced
– Origin: lift-request button
– Destination: lift system
• The object of this class controls the state of the complete lift system for as far as it can not be
delegated to the lift cages immediately. The requests from the lift request buttons must be
handled by a lift cage. The selection of such a cage is the responsibility of the lift system. It
can make the allocation on the basis of a cost that can be assigned to the handling of a
request by each of the cages. The cage with the minimal cost can best handle the request.
– Intermediary: floor
– Responsibility lift system:
• coordinate the allocations of requests to lift cages
OO/UML 15

Visit floor
• Visit requested floor
– Required information: what floor must be serviced by which liftcage
– Origin: lift system
– Destination: the allocated cage
• The cage object handles the visiting of the floor in and coordinates it with other requests it has
to handle.
– Responsibility:
• Each object of this class manages and controls the state of a lift cage insofar as this task
cannot be delegated to its aggregates. In particular it receives and schedules the floor
requests for the cage and takes care these requests are serviced under the functional
constraints that apply. It coordinates the actions of its aggregates such as the motor and the
doors.
OO/UML 16

Move to floor
• Move to floor
– Required information: what floor must be serviced next
– Origin: lift cage
– Destination: the cage’s motor
• The motor’s next destination is set and the motor is started to move up or down
– Responsibility:
• Each motor handles all actions and activities that pertain to moving a lift cage. Lowering,
raising, detecting floors, and stopping at destinations. The motor indicates important events to
its observer (the lift cage). The important events to indicate are the moment the motor passes
a floor sensor, or stops at a floor.
OO/UML 17

Realizing Use Case “Change Floor”

liftRequestUpButton floor1 : Floor : Door floorRequestButton : : LiftSystem : LiftCage : Motor

: LightedButton LightedButton
: Person
press( )
visitUp()
visitUp(floor1)
allocateCage()

visit(floor1)

setDestination(floor1)

justBelow(floor1)

arriveAt(floor1)
open( )

enter lift cage

OO/UML 18

Use-Case Analysis: GUI Frameworks

• Boundary classes are the “bridge” between the domain objects and the
implementation objects
– Lift Buttons are physical objects
– Lift Buttons send messages to typical control objects found in the implementation
• GUI frameworks implement this bridge by using system support for handling
user events and graphical interface representations
– They help to keep direct mapping
• Use-Case analysis can be performed at various stages of model refinement: in
the Analysis, Design and Implementation workflow
OO/UML 19

Exercise
• Realize one of the Use Cases from the Solitaire game