lectures.alex.balgavy.eu

Lecture notes from university.
git clone git://git.alex.balgavy.eu/lectures.alex.balgavy.eu.git
Log | Files | Refs | Submodules

sequence-diagrams.wiki (6853B)


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