1. Sequence diagrams Lecture 5

2. Main terms  Interaction  Life line  Activation  Executable behavior and derived behavior  Messages  Trajectory  Frame of interaction use  Operators of interactions

3. Interaction diagrams  The interaction is described by the following types of diagrams: sequence diagram and communication (cooperation) diagram  Sequence diagrams can (and should!) be used to detail the use cases for more detailed description of the logic of usage scenarios.  Sequence diagrams contain objects, messages and return results related to communications.

4. Example of a sequence diagram

5. Communication diagram  It is equivalent to the sequence diagram  Ascent is not on the time of interaction (as it is on the sequence diagram), but on the structure of connections between objects.  Position of the elements does not matter. In order to show the order of messages in time a hierarchical decimal numbering is applied.

6. Example of a communication diagram

7. Main terms

13. Types of messages a)Call of procedures, executable operations b)Asynchronous message, which is sent at any moment, accompanied by the getting of focus of the object. Sometimes is represented by the line with a half of the arrow c)Return from the call of procedure (end of calculations without result)

14. Example of different types of messages

15. Types of messages  Synchronous message (synchCall) – corresponds to a synchronous call operation and waits for a respond from the recipient object. While the response is not received, no actions perform in a system.  Asynchronous message (asynchCall) – corresponds to a asynchronous call operation and means that the object can continue its work without waiting the response.  Response message (reply) – the response message from the called method. This type of message is shown in a diagram as necessary.  Lost message (lost) – message, which doesn’t have the recipient, i.e. there is the event of submit and there is not the event of admission  Found message (found) – message, which doesn’t have the initiator of the message, i.e. there is not the event of submit and there is the event of admission

16. Stereotypes of messages  "call" – message requiring call of operation and procedure of the recipient object  "return" – message, returning the value of the performed operation or procedure to the object, which caused the operation  "create" – message, requiring the creation of another object for performing definite actions  "destroy" – message with explicit requirement to destroy a corresponding object  "send" – denotes the sending of some signal, which asynchronously initiates by one object and received by another object

17. Time constraints  Duration Constraint – minimum and maximum value of duration of message sending  Duration Constraint Between Messages – constraint of duration of waiting between sending and receiving of a message  Duration Observation – interception of message duration  Timing Constraint – time interval, while which the message must reach the target (set at the side of the receiver)  Timing Observation – time interception when the message was sent

18. Example of time constraints

19. Interaction operators  Definite fragments of interaction diagrams can be allocated in a frame. Frame must contain the label of interaction operator:  Alt – several alternative fragments; only that fragment executes, whose condition is true  Opt – not required, optional fragment; it executes only if the condition is true. It is equivalent the alt with one branch

20. Interaction operators  par – parallel; all fragments executes in parallel  loop – loop; fragment can execute several times; you can specify minimum and maximum number of iterations. You must specify the condition of repetition  region – critical region; fragment can have only one flow, executed at one time  neg – negative fragment; means wrong interaction

21. Interaction operators  ref – reference; references to the interaction, specified in another diagram. You can determine parameters and returned values  Sd - sequence diagram; used to outline the whole diagram

22. Example of a frame

23. Implementation of use cases 1.Textual descriptions  Simple, understandable, easily and quickly made  Often incomplete and inaccurate 2.Pseudo code  Familiar, understandable to any developer  Badly consistent with object-oriented programming  Lost visibility of UML  Cannot be reused

24. Implementation of use cases 3.Activity diagrams  Can lead to deeper understanding of the problem  Can open abilities for improvement of application  Can lead to change and improvement of implemented use case  Does not close to the final aim – source code

25. Implementation of use cases 4.Sequence diagrams  Most consistent to methodology UML  Always leads to determination of several classes (because objects interacts) and some of their operations (because messages “call” are defined).  Matches the OOP paradigm. There are a lot of CASE tools can convert to program code.  Allow to describe the protocol only, but not the algorithm! What to do? Draw several sequence diagrams. Each will show one scenario, all together gives the representation of the whole use case