Modelling Behaviour


•     Phase 1 – Requirements and Planning

–Requirements specification

–Use cases for discovering and recording requirements  

–Project planning

Use Case Example

Use Case:      Buy Items

Actors:           Customer, Cashier

Description:   A customer arrives at a checkout with items to purchase.
                        The cashier records the purchase items.
                        The system presents the running total and line-item details.
                        The cashier collects the money and enters the payment information.
                        The system updates inventory.
                        The customer receives the receipt and leaves with the items.


•     Phase 2 – OOA

–Modelling Structure

–… What’s more?



More Than One View (Cont.)

    In the same way:

•     A static structure does not describe how classes or concepts interact, nor does it present the objects created and used during runtime.

•     Thus, we need to model behaviour!

What are Sequence Diagrams?

•     UML does not define something called system sequence diagrams, only sequence diagrams

•     Describe how the system works

–How the system realises use cases (i.e. interacts with actors)

•     Illustrate actor interactions with the system

–Actors interact by sending a request for an operation to be performed

•     Show the events that actors generate

–The events initiate appropriate action

•     Later, we will use sequence diagrams in another context (interacting software objects)

Purpose of Sequence Diagrams

•     Isolate and illustrate operations that actors request

•     Show a sequence of events for one scenario

–Particular instance or realisation path of a use case



–Events and their order

•     Two kinds of scenarios

–Generic scenarios – i.e. use cases

–Concrete scenarios – examples

System Sequence Diagram (SSD)

•      An SSD illustrates input and output events

•      Generic diagram depicting single use cases

•      Allows identification of system operations

•      Draw an SSD for a main success scenario of each use case and frequent or complex alternative scenarios

•      SSDs are a way of bridging natural language descriptions and models

–Use case specifications (in English) ΰ software models (in UML)

Operation Contract – Description

Operation:                  Name of operation and parameters

Cross References:    Use cases this operation can occur within

Responsibilities:        Describe the operation

Preconditions:            Assumptions about the state of the system or objects before execution of the operation

Postconditions:          The state of objects in the Domain Model after completion of the operation




•      Describe changes in the state of objects

•      Not orders

•      Not actions to be performed

•      State-change oriented – not action-oriented

•      Operation contract postcondition categories

–Creation or deletion of an instance

–Modification of attributes

–Formation or breaking of associations

Finding Postconditions

•      “Stage and Curtain” model

–The system and its objects are presented on a theatre stage

§      Take a picture of the stage before the operation

§      Close the curtains and apply the operation

§      Open the curtains and take a picture of the stage

§      Compare the before and after pictures and express the state changes as post conditions.


Sequence Diagram vs. Operation Contract

•      Sequence diagram

–Shows events that actor generates

–Does not elaborate on functions associated with operations invoked in response to the events

•      Operation contract describes

–Conditions (preconditions)

»   upon which the operations can be performed

–Changes (postconditions)

»   in the state of the system

State Machine Diagrams

•      Model state of system / object

•      State

–Condition of an object at a moment in time

•      Event

–Significant and noteworthy occurrence

•      Transition

–Relationship between two states that indicate that when an event occurs, an object moves from the prior state to the subsequent state

•      State Diagram

–Illustrates interesting events and states

–Behaviour of objects in reaction to events = transitions



Structuring Use Cases

•      Processes are described by use cases

–May include common sub-processes

»   I.e. duplication of descriptions

–Can be complex and/or conditional

»   Extract sub-processes for better understanding

•      Example: BuyItem use case

–Pay by cash

–Pay by check

–Pay by credit Card

•      Or during the process of BuyItem and ExchangeItems

–Authorisation is required