Discovering object interaction

1. Discovering object interaction

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

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

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

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

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

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

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

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

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

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

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

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

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

16. Messages

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

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

19. 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 [  ].

20. Sequence diagrams 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 name and class Object name Class Name( Anonymous object

21. 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)

22. UML notation for objects and messages

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

24. Example

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

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

27. Process Sale Scenario example

28. Sequence diagrams and Use Cases

29. The ATM example

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