Interaction In UML model the static aspects of

Interaction

In UML model the static aspects of a system by using such elements as class diagrams and object diagrams. These diagrams let you visualize, specify, construct and document the things that live in your system, including classes, interfaces, components, nodes and use cases and their instances, together with the way those things sit in relationship to one another

In UML model the dynamic aspects of a system by using interaction. An interaction statically sets the stage for its behavior by introducing all objects that work together to carry out some action. Interaction also introduce messages that are dispatched from object to object.

Interactions • an interaction is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose • a message is a specification of a communication between objects that conveys information with the expectation that activity will ensue. Most often, messages involve the invocation of an operation or sending of a signal; messages may also encompass the creation and destruction of other objects.

Messages • In UML, you can model several kind of actions: – Call – Return – Send – Create – Destroy

Interactions cont. • You use interaction to model the flow of control whitin an operation, a class, a component, a use case or the system as a whole.

Sequencing • When an object passes a message to antoher object, the receiving object might in turn send a message to another object, which might send a message to yet a different object, and so on. This stream of messages forms a sequence.

Representation • When you model an interation, you typically include both – objects – each one playing a specific role – messages – each one representing the communication between objects, with some resulting action

Representation cont. • You can visualize those objects and messages involved in an interaction in two ways: – by emphasizing the time ordering of its messages sequence diagram – by emphasizing the structural organization of the objects that send and receive messages collaboration diagram

Sequence and collaboration diagram • Largely isomorphic, meaning that you can take one and transform it into the other witout loss of information. • Visual differences: – Sequence diagrams: permit you to model the lifeline of an object – Collaboration diagrams: permit you to model the structural links that may exist among the objects in an interaction

Sequence and Collaboration Diagram Print(file) : Computer : Printer. Server Print(file) : Printer [printer free] Print(file) [printer busy] Store(file) : Queue

Sequence and Collaboration Diagram Print(file) : Computer [printer busy] 1. 2: Store(file) : Queue 1. Print(file) : Printer. Server [printer free] 1. 1: Print(file) : Printer

Sequence diagram • emphasizes the time ordering of messages • reveals the interaction for a specific scenario – a specific interaction between the objects that happens at some point in time during the system’s execution • the object that initiates the interaction at left, and increasingly more subordinate objects to the right • the messages that these object send and recieve along the y axis, in order of increasing time from time to bottom

Sequence Diagram Print(file) : Computer : Printer. Server Print(file) : Printer [printer free] Print(file) [printer busy] Store(file) : Queue

Sequence diagram – two features • the object lifeline • the focus of control object 1 <<create>> <<destroy>> object 2 X

Modeling a Flow of Control • Set the context for the interaction • Set the stage for the interaction by identifying which objects play a role • Set the lifeline for each object • Starting with the messages that initiates this interaction

Examples current thread Creates a Runnable interface <<create>> Creates a Thread object runner new Thread(runner) : Thread start() Starts new Thread Call returns immediatly run() Two threads are now running concurrently Figure: Spawning Threads

application quit. Button: Button quit. Handler evt: Action. Event add. Action. Listener(this) …… user clicks button action. Performed(evt) get. Source() quit. Button dispose() Figure: Delegating Events

gfx: Graphics : Image. Applet AWT get. Image(…) paint(gfx) draw. Image(…) false image. Update(…) …. repaint() update(gfx) …. paint(gfx) draw. Image(…) true Figure: Image Drawing gfx: Graphics

A well-structured interaction • is simple and should encompass only those objects that work together to carry out some behavior bigger than the sum of all these elements • has a clear context and may represent the interaction of objects in the context of an operation, a class, or the system as a whole • is efficient and should carry out its behavior with an optimal balance of time and resources • is adaptable and elements of an interaction that are likely to change should be isolated so that they can be easily modified • is understandable and should be straightforward, involving no hacks, hidden side effects or obscure semantics

When you draw an interaction i the UML • Choose an emphasis for the interaction. You can emphasize either the ordering of messages over time or the sequencing of messages in the context of some structural organization of objects. You can’t do both at the same time • Show only those properties of each object that are important to understanding the interaction in its context • Show only those properties of each message that are important to understanding the interaction in its context