index.md (6229B)
1 +++ 2 title = 'Sequence Diagrams' 3 +++ 4 ## Sequence Diagrams 5 ### Introduction 6 it's a way to model interactions between objects 7 8 interaction specifies how messages and data are exchanged between objects 9 10 interaction partners: human (lecturer, admin) or non-human (server, printer, software) 11 12 interactions: conversation between people, message exchange between human and software, communication protocols, sequence of method calls in program, etc. 13 14 ### Basics 15 #### Interactions, interaction partners 16 a sequence diagram is 2D: 17 * horizontal axis: involved interaction partners 18 * vertical axis: chronological order of interaction 19 20 interaction: sequence of event specifications 21 22  23 24 interaction partners are lifelines: 25 * head of lifeline is rectangle containing `object:Class` 26 * body of lifeline is vertical dashed line representing lifetime of associated object 27 28 #### Messages 29 message is defined via send and receive events 30 31 execution specification (optional): 32 * continuous bar 33 * used to visualize when interaction partner executes a behavior 34 35  36 37 rules: 38 39  40 41 synchronous message: 42 * sender waits until it has received response message before continuing 43 * syntax: `msg(par₁, par₂)` 44 * `msg`: name of message 45 * `par`: parameters 46 * notation:  47 48 asynchronous message: 49 * sender continues without waiting for response msg 50 * syntax: `msg(par₁, par₂)` 51 * notation:  52 53 response message: 54 * can be omitted if content and location are obvious 55 * syntax: `att = msg(par₁, par₂): val` 56 * `att`: return value assigned to variable (optional) 57 * `msg`: name of message 58 * `par`: parameters 59 * `val`: return value 60 * notation:  61 62 object creation: 63 * dashed arrow, arrowhead pointing to head of lifeline of object that's being created 64 * keyword `new` 65 * notation:  66 67 object destruction: 68 * object is deleted 69 * large cross at end of lifeline 70 * notation:  71 72 found message: 73 * sender unknown/not relevant 74 * notation:  75 76 lost message: 77 * receiver unknown/not relevant 78 * notation:  79 80 Time-consuming message: 81 * message with duration 82 * usually messages transmitted instantly (by assumption); not in this case 83 * notation:  84 85 ### Combined fragments 86 model various control structures, have 12 predefined operators. 87 88 Example: 89 90  91 92 #### Branches & loops 93 `alt`: 94 * alternative sequence 95 * like a switch statement, with guards selecting the path to be executed 96 * guards modeled in square brackets, default true 97 * guards have to be disjoint so that behavior is deterministic! 98 99  100 101 `opt`: 102 * optional sequence 103 * like an if without an else 104 * actual execution depends on guard 105 * exactly one operand 106 107  108 109 `loop`: 110 * repeated sequence 111 * min/max number of iterations - `(min..max)` or `(min, max)`. default `(*)`, no upper limit. 112 * guard evaluated when min number of iterations took place, checked on each iteration. loop quits if false. 113 114  115 116 `break`: 117 * exception handling 118 * one operand with a guard. if true: 119 * interactions within operand are executed 120 * remaining operations of _surrounding_ fragment don't run 121 * interaction continues at next higher level fragment (so like you skip a level) 122 123  124 125 #### Concurrency and order 126 `seq`: 127 * weak sequencing, default order of events 128 * can't skip around on the same lifeline 129 130  131 132 `strict`: 133 * strict order 134 * fixed sequence of events across lifelines 135 * order of events on different lifelines between different operands is significant 136 * messages in operand higher up on vertical axis are _always_ exchanged before the ones that are lower 137 138  139 140 `par`: 141 * concurrent interaction 142 * relax chronological order between messages in different operands 143 * restrictions in each operand have to be respected 144 * order of different operands is irrelevant 145 146  147 148 `critical`: 149 * atomic interaction 150 * make sure that certain parts of interaction aren't interrupted by unexpected events 151 * _always_ has to be in that order 152 153  154 155 #### Filters and assertions 156 `ignore`: 157 * irrelevant interaction 158 * messages can occur at runtime but don't have other significance 159 * one operand, irrelevant messages in curly brackets after keyword `ignore` 160 161  162 163 `consider`: 164 * relevant interaction with a particular importance 165 * one operand. "dual" to ignore fragment 166 * considered messages in curly brackets 167 * and yes, you can use `ignore` instead of `consider` and vice-versa 168 169  170 171 `assert`: 172 * asserted interaction 173 * mandatory interactions. the model is complete. can't have any deviations. 174 175  176 177 `neg`: 178 * invalid interaction 179 * describe situations that must not occur 180 * depicting relevant but _incorrect_ sequences 181 182  183 184 ### Further language elements 185 time constraints: 186 * point in time for event occurrence: `after(5sec)`, `at(12.00)` 187 * time period between two events: `{lower..upper}` 188 * `now`: current time 189 * duration: calculation of duration of message transmission 190 191 Interaction reference: 192 * integrates one sequence diagram in another sequence diagram 193 * define with `sd name` in the corner, then use the name in the diagram with `ref` in the corner 194 195 Gate: 196 * allows to send and receive messages beyond boundaries of interaction fragment 197 198 state invariant: 199 * asserts certain condition has to be true at certain time 200 * if state invariant is not true, either model or implementation is wrong 201 * notations: 202 203 