Discovering object interaction

Use case realisation

• The USE CASE diagram presents an outside view of the system.

• The functionality of the use case is captured in the flow of events.

• Scenarios are used to describe how the use cases are realised as interactions among societies of objects.

Scenarios

• A scenario is simply an instance of a use case.– It is one path through the flow of events for the use

case.

• Scenarios are developed to help identify the objects , classes, and the object interactions needed to carry out a piece of functionality specified by the use case.

• Scenarios document decisions how the responsibilities specified in the use case are distributed among classes and objects in the system.

Scenarios

• Provide an excellent communication media to be used in the discussion of the system.– They speak the language of the end user and

domain experts.

• Each use case is a web of scenarios – Primary scenario – is the normal flow of the

use case– Secondary scenarios – the what if logic of the

use case.

Documenting scenarios

• The flow of events for a use case is captured in text whereas scenarios are captured in interaction diagrams.

Interaction Diagrams• Interaction diagrams model the behavior of  use

cases by describing the way groups of objects interact to complete the task. 

• Interaction diagrams are used to define and clarify the roles of the objects that perform a particular flow of events of a use case. – They are the primary source of information used to

determine class responsibilities and interfaces. • There are two types of interaction diagrams.

– Sequence diagrams and – Collaboration diagrams

• The collaboration diagram and the sequence diagram are interchangeable, they show the same use-case realization, but they focus on different aspects of the interaction.

When to Use: Interaction Diagrams

• Interaction diagrams are used when you want to model the behavior of several objects in a use case. 

• They demonstrate how the objects collaborate for the behavior. 

• Interaction diagrams do not give a in depth representation of the behavior. 

• If you want to see what a specific object is doing for several use cases use a state diagram. 

• To see a particular behavior over many use cases or threads use an activity diagrams.

How to Draw: Interaction Diagrams

• Sequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate the interaction of objects in a use case. 

• Sequence diagrams generally show the sequence of events that occur. 

• Collaboration diagrams demonstrate how objects are statically connected. 

• Both diagrams are relatively simple to draw and contain similar elements.

Sequence Diagrams

• A sequence diagram is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events.

• All systems are treated as a black box; the diagram places emphasis on events that cross the system boundary from actors to systems.

Sequence diagrams

• Shows object interactions arranged in time sequence.

• Depicts – the objects and classes involved in the

scenario and – the sequence of messages exchanged

between the objects

• Sequence diagrams typically are associated with use case realisations

Drawing System Sequence Diagrams

• System Behaviour and UML Sequence Diagrams– It is useful to investigate and define the behaviour of

the software as a “black box”.– System behaviour is a description of what the system

does (without an explanation of how it does it).– Use cases describe how external actors interact with

the software system. During this interaction, an actor generates events.

– A request event initiates an operation upon the system.

Basic Sequence Diagram Symbols and Notations

• Class rolesClass roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list object attributes.

                                                                     

Activation

• Activation boxes represent the time an object needs to complete a task.

• They indicate whenever a method is active,

• They show methods which are waiting for returns.

Messages

• Messages are arrows that represent communication between objects.

• Use half-arrowed lines to represent asynchronous messages.

• Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks.

• An asynchronous message is a message that does not block the caller, i.e., caller and receiver execute concurrently.

Messages

Lifelines

• Lifelines are vertical dashed lines that indicate the object's presence over time.

Destroying objects

• Objects can be terminated early using an arrow labeled "< < destroy > >" that points to an X.

Loops

• A repetition or loop within a sequence diagram is depicted as a rectangle.

• Place the condition for exiting the loop at the bottom left corner in square brackets [  ].

Sequence diagrams

History 101-section2History 101 : CourseOfferingObject name

Object name and class

:ClassOffering

Class Name( Anonymous object

In UML an object is a sequence diagram is drawn as a rectangle containing the name of the , underlined

An object can named can be named in one of the following three ways

Object names

• Can be specific e.g algebra• Or they can be general e.g course offering• Often an anonymous object (class name only)

may be used to represent any object in the class.

• Each object also has its timeline represented by a dashed line below the object.

• Messages between objects are represented by arrows that point from the client (Sender of the message) to the supplier( receiver)

UML notation for objects and messages

: Professor CourseManager Math 101 : CourseOffering

Add professor (Professor)

Sequence diagrams and boundary classes

• Boundary classes are added to sequence diagrams to show the interaction with the user or with another system.

• The actual messages from the actor to the boundary class along with their sequence information are dependant upon the applications framework that is chosen later in development.

Example

: Registrar A course form the manager A course : Course

Set course info

Process

add course

new course

Example: Drawing System Sequence Diagrams

• Example when the cashier enters the item id, the cashier is requesting the POS system to record that item’s sale. That request event initiates an operation upon the system..

• It is desirable to identify the operations that an external actor requests of a system, because they very important in as far as understanding the system behaviour is concerned.

• UML uses the system sequence diagram to illustrate the actor interactions and the operations initiated by them.

Example: Drawing System Sequence Diagrams

• A system sequence diagram is a picture that shows for a particular scenario of the use case, the events that external actors generate, their order and inter system events.

• We design a system sequence diagram for the main success scenario of the use case and the complex alternative scenarios.

Process Sale Scenario example

enterItem(itemID, quantity)

:System: Cashier

endSale()

makePayment(amount)

box may enlose aniteration area

the * [...] is an iterationmarker and clauseindicating the box is foriteration

external actor to system Process Sale Scenario

system as black box

the name could be "NextGenPOS" but "System" keeps it simple

the ":" and underline imply an instance, and are explained in alater chapter on sequence diagram notation in the UML

a message withparameters

it is an abstractionrepresenting thesystem event ofentering thepayment data bysome mechanism

description, total

return value(s)associated with theprevious message

an abstraction thatignores presentation andmedium

the return line is optionalif nothing is returned

total with taxes

change due, receipt

* [more items]

makeNewSale()

Sequence diagrams and Use Cases

: Cashier :System

Simple cash-only Process Sale scenario:

1. Customer arrives at a POS checkoutwith goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item andpresents item description, price, andrunning total.Cashier repeats steps 3-4 until indicatesdone.5. System presents total with taxescalculated.6. Cashier tells Customer the total, andasks for payment.7. Customer pays and System handlespayment....

enterItem(itemID, quantity)

endSale()

makePayment(amount)

description, total

total with taxes

change due, receipt

* [more items]

makeNewSale()

The ATM example

Complexity and sequence diagrams

• How complex should a sequence diagram be?

• Just keep it as simple as possible.

• Make sure that it is very easy to see the objects, interactions, the messages and the functionality captured by the scenario.