Modeling objects interaction via UML sequence diagrams [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]
•
2 likes•1,413 views
This presentation is about a lecture I gave within the "Software Design" course of the Computer Science bachelor program, of the Vrije Universiteit Amsterdam. http://www.ivanomalavolta.com
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Modeling objects interaction via UML sequence diagrams [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]
Similar to Modeling objects interaction via UML sequence diagrams [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018] (10)
More from Ivano Malavolta
More from Ivano Malavolta (20)
Recently uploaded
Recently uploaded (20)
Modeling objects interaction via UML sequence diagrams [Software Design] [Computer Science] [Vrije Universiteit Amsterdam] [2017/2018]
- 1. Software and Services research group (S2) Department of Computer Science, Faculty of Sciences Vrije Universiteit Amsterdam VRIJE UNIVERSITEIT AMSTERDAM Modeling objects interaction via UML sequence diagrams Software modeling (400170) – 2017/2018 Ivano Malavolta i.malavolta@vu.nl
- 2. VRIJE UNIVERSITEIT AMSTERDAM Examples of questions in the final exam (1) 2
- 3. VRIJE UNIVERSITEIT AMSTERDAM Examples of questions in the final exam (2) 3
- 4. VRIJE UNIVERSITEIT AMSTERDAM Examples of questions in the final exam (3) 4
- 5. VRIJE UNIVERSITEIT AMSTERDAM Examples of questions in the final exam (4) 5
- 6. VRIJE UNIVERSITEIT AMSTERDAM Roadmap § Introduction § Basics § Interactions and interaction partners § Messages § Combined fragments § Branches and loops § Concurrency and order § Filters and assertions § Further language elements 6
- 7. VRIJE UNIVERSITEIT AMSTERDAM Introduction §Interaction § Specifies how messages and data are exchanged between objects §Interaction partners § Human (lecturer, administrator, …) § Non-human (server, printer, executable software, …) §Examples of interactions § Conversation between persons § Message exchange between humans and a software system § Communication protocols § Sequence of method calls in a program § … 7 MAIN GOAL To model interactions between objects
- 8. VRIJE UNIVERSITEIT AMSTERDAM Sequence Diagram § Two-dimensional diagram § Horizontal axis: involved interaction partners § Vertical axis: chronological order of the interaction § Interaction = sequence of event specifications 8
- 9. VRIJE UNIVERSITEIT AMSTERDAM Interaction Partners § Interaction partners are depicted as lifelines § Head of the lifeline § Rectangle that contains the expression object:Class § Body of the lifeline § Vertical dashed line § Represents the lifetime of the object associated with it Head of the lifeline Body of the Lifeline 9
- 10. VRIJE UNIVERSITEIT AMSTERDAM Exchanging Messages (1/2) § Interaction: sequence of events § Message is defined via send event and receive event § Execution specification § Continuous bar § Used to visualize when an interaction partner executes some behavior Send event Receive event Execution specification 10
- 11. VRIJE UNIVERSITEIT AMSTERDAM Exchanging Messages (2/2) 3. on different lifelines which exchange messages 2. on different lifelines1. on one lifeline »Happens before« 11 3 rules about order of messages:
- 12. VRIJE UNIVERSITEIT AMSTERDAM Messages (1/3) § Synchronous message § Sender waits until it has received a response message before continuing § Syntax of message name: msg(par1,par2) § msg: the name of the message § par: parameters separated by commas §Asynchronous message § Sender continues without waiting for a response message § Syntax of message name: msg(par1,par2) §Response message § May be omitted if content and location are obvious § Syntax: att = msg(par1,par2):val § att: the return value can optionally be assigned to a variable § msg: the name of the message § par: parameters separated by commas § val: return value 12
- 13. VRIJE UNIVERSITEIT AMSTERDAM Messages (2/3) § Object creation § Dashed arrow § Arrowhead points to the head of the lifeline of the object to be created § Keyword new § Object destruction § Object is deleted § Large cross (×) at the end of the lifeline 13
- 14. VRIJE UNIVERSITEIT AMSTERDAM Messages (3/3) § Found message § Sender unknown or not relevant § Lost message § Receiver unknown or not relevant § Time-consuming message § "Message with duration" § Usually messages are assumed to be transmitted without any loss of time § Express that time elapses between the sending and the receipt of a message 14
- 16. VRIJE UNIVERSITEIT AMSTERDAM Combined Fragments § Model various control structures § 12 predefined types of operators Operand Operand Combined Fragment Operator Operand 16
- 17. VRIJE UNIVERSITEIT AMSTERDAM Types of Combined Fragments Operator Purpose alt Alternative interaction opt Optional interaction loop Repeated interaction break Exception interaction seq Weak order strict Strict order par Concurrent interaction critical Atomic interaction ignore Irrelevant interaction consider Relevant interaction assert Asserted interaction neg Invalid interaction Branchesand loops Concurrency andorder Filtersand assertions 17
- 18. VRIJE UNIVERSITEIT AMSTERDAM alt Fragment § Similar to switch statement in Java § Guards are used to select the one path to be executed § Guards § Modeled in square brackets § default: true § predefined: [else] § Multiple operands § Guards have to be disjoint to avoid indeterministic behavior 18 To model alternative sequences
- 19. VRIJE UNIVERSITEIT AMSTERDAM opt Fragment §Actual execution at runtime is dependent on the guard § Exactly one operand § Similar to if statement without else branch 19 To model an optional sequence
- 20. VRIJE UNIVERSITEIT AMSTERDAM loop Fragment § Exactly one operand § Minimal/maximal number of iterations § (min..max) or (min,max) § default: (*) .. no upper limit § Guard § Evaluated as soon as the minimum number of iterations has taken place § Checked for each iteration within the (min,max) limits § If the guard evaluates to false, the execution of the loop is terminated Notation alternatives: loop(3,8) = loop(3..8) loop(8,8) = loop (8) loop = loop (*) = loop(0,*) loop is executed at least once, then as long as a<1 is true Min Guard Max To model repeated sequences
- 21. VRIJE UNIVERSITEIT AMSTERDAM break Fragment § Exactly one operand with a guard § If the guard is true: § Interactions within this operand are executed § (b à c) § Remaining operations of the surrounding fragment are omitted § (d) § Interaction continues in the next higher level fragment § (e) Not executed if break is executed To model exception handling
- 22. VRIJE UNIVERSITEIT AMSTERDAM loop and break Fragment - Example 22
- 23. VRIJE UNIVERSITEIT AMSTERDAM Types of Combined Fragments Operator Purpose alt Alternative interaction opt Optional interaction loop Repeated interaction break Exception interaction seq Weak order strict Strict order par Concurrent interaction critical Atomic interaction ignore Irrelevant interaction consider Relevant interaction assert Asserted interaction neg Invalid interaction Branchesand loops Concurrency andorder Filtersand assertions 23
- 24. VRIJE UNIVERSITEIT AMSTERDAM seq Fragment § Weak sequencing: 1. Events on different lifelines from different operands may come in any order 2. Events on the same lifeline from different operands are ordered such that an event of the first operand comes before that of the second operand 3. The ordering of events within each of the operands is maintained in the result 24 The default order of events
- 25. VRIJE UNIVERSITEIT AMSTERDAM strict Fragment § Order of event occurrences on different lifelines between different operands is significant § Messages in an operand that is higher up on the vertical axis are always exchanged before the messages in an operand that is lower down on the vertical axis 25 Fixed sequence of events across lifelines
- 26. VRIJE UNIVERSITEIT AMSTERDAM strict Fragment - Example 26
- 27. VRIJE UNIVERSITEIT AMSTERDAM par Fragment 27 § Execution paths of different operands can be interleaved § Restrictions of each operand need to be respected § Order of the different operands is irrelevant To relax the chronological order between messages in different operands
- 28. VRIJE UNIVERSITEIT AMSTERDAM par Fragment - Example 28
- 29. VRIJE UNIVERSITEIT AMSTERDAM critical Fragment § To make sure that certain parts of an interaction are not interrupted by unexpected events 29 Atomic area
- 30. VRIJE UNIVERSITEIT AMSTERDAM critical Fragment - Example 30
- 31. VRIJE UNIVERSITEIT AMSTERDAM Types of Combined Fragments Operator Purpose alt Alternative interaction opt Optional interaction loop Repeated interaction break Exception interaction seq Weak order strict Strict order par Concurrent interaction critical Atomic interaction ignore Irrelevant interaction consider Relevant interaction assert Asserted interaction neg Invalid interaction Branchesand loops Concurrency andorder Filtersand assertions 31
- 32. VRIJE UNIVERSITEIT AMSTERDAM ignore Fragment § Messages may occur at runtime but have no further significance § Exactly one operand § Irrelevant messages in curly brackets after the keyword ignore 32 To represent irrelevant messages
- 33. VRIJE UNIVERSITEIT AMSTERDAM consider Fragment § Exactly one operand, dual to ignore fragment § Considered messages in curly brackets after the keyword consider 33 To represent messages with particular importance
- 34. VRIJE UNIVERSITEIT AMSTERDAM ignore vs. consider 34 These are the same
- 35. VRIJE UNIVERSITEIT AMSTERDAM assert Fragment § Deviations that occur in reality but that are not included in the diagram are not permitted 35 To represent mandatory interactions In this case, the model is COMPLETE
- 36. VRIJE UNIVERSITEIT AMSTERDAM neg Fragment § Describing situations that must not occur § Purpose § Explicitly highlighting frequently occurring errors § Depicting relevant, incorrect sequences 36 To explicitly represent invalid interactions
- 38. VRIJE UNIVERSITEIT AMSTERDAM Time Constraints §Types § Point in time for event occurrence § Relative: e.g., after(5sec) § Absolute: e.g., at(12.00) § Time period between two events § {lower..upper} § E.g., {12.00..13.00} §Predefined actions § now: current time § Can be assigned to an attribute and then used in a time constraint § Duration: calculation of the duration of a message transmission 38
- 39. VRIJE UNIVERSITEIT AMSTERDAM Interaction Reference § Integrates one sequence diagram in another sequence diagram 39 Definition Usage
- 40. VRIJE UNIVERSITEIT AMSTERDAM Gate § Allows you to send and receive messages beyond the boundaries of the interaction fragment 40
- 41. VRIJE UNIVERSITEIT AMSTERDAM Local Attributes and Parameters § Every sequence diagram is enclosed by a rectangular frame with a small pentagon in the upper left corner § Keyword sd, name of the sequence diagram, parameters (optional) § Example: Option 1: Option 2: void func (int par1, int par2) { int x = 0; String y = "Test"; ... } Parameter Local attributes 41
- 42. VRIJE UNIVERSITEIT AMSTERDAM State Invariant § Asserts that a certain condition must be fulfilled at a certain time § Evaluation before the subsequent event occurs § If the state invariant is not true, either the model or the implementation is incorrect § Three alternative notations: 42 Useful for linking your state machines and sequence diagrams
- 43. VRIJE UNIVERSITEIT AMSTERDAM Notation Elements (1/2) Name Notation Description Lifeline Interaction partners involved in the communication Destruction event Time at which an interaction partner ceases to exist Combined fragment Control constructs 43
- 44. VRIJE UNIVERSITEIT AMSTERDAM Notation Elements (2/2) Name Notation Description Synchronous message Sender waits for a response message Response message Response to a synchronous message Asynchronous communication Sender continues its own work after sending the asynchronous message Lost message Message to an unknown receiver Found message Message from an unknown sender 44
- 45. VRIJE UNIVERSITEIT AMSTERDAM What this lecture means to you? • You can model how objects interact with each other now! • Use case • main features of the system • how external actors interact with them • Class diagram • main entities of your system • data types • Object diagram • snapshots of your system at run-time • State machine diagram • internal behaviour of your objects • Sequence diagram • how objects interact with each other (aka external behaviour) • actors from UML use case diagrams also involved here 45
- 46. VRIJE UNIVERSITEIT AMSTERDAM Readings • UML@Classroom: An Introduction to Object-Oriented Modeling” – chapter 6 • Learning UML 2.0 – chapter 7 46
- 47. VRIJE UNIVERSITEIT AMSTERDAM Solution to the state machine exercise Event sequence: e1, e2, e4, e4, e3, e1 Value of x?
- 48. VRIJE UNIVERSITEIT AMSTERDAM Solution to the state machine exercise