mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
4.6 KiB
4.6 KiB
| title | aliases | tags | sr-due | sr-interval | sr-ease | ||
|---|---|---|---|---|---|---|---|
| 13-UML-sequence-diagrams |
|
2022-05-17 | 24 | 270 |
sequence diagrams document a sequence of particpant interactions required to carry out a use case
- actor <-> object
- actors are outside the system
- objects are otside the system
- via a method call
- might get a result
- object <-> object
- lifetime of interactions and objects
- when they are created updated destroyed
- time is a key aspect
- use-case-diagrams dont have order
These diagrams are:
- detailed, low level, bottom up
- behavioural diagram
- not structural
- common in industry
- along with class diagrams
- need to be designed and read alongside corresponding class diagrams
- e.g., class diagrams with inform sequences diagrams and vice versa
- back and forth process
General overview example: annotated example
- time goes from top to bottom
- however no specific time units
- can have actors as participants
- but not usually
- existence of actor usualy indicates a sequence is owned by a use case
- interactions are indicated by messages (solid arrows)
- e.g. actor to main menu
- actor clicks a button
- menu reacts
- etc
- messges are synchronous
- i.e., thing sending message must wait for result
- always method calls (or something that equated to a method call)
- e.g. actor to main menu
- participants are supposed to be instances of classes
- however we are usually more interested in the class name
- the dashed lines are lifelines
- can also be solid
- basically indicate the existenc of something
- e.g., Thingform gets destroyed, thingfinder and thing remain throughout
- the rectangles (activation bars) indicate when an a thing is doing somethin
- caused by incoming message
- ended by a return
- these can have sub activations
- i.e., nested
- these can be self-activations
- implcit: not all methods return something
Messages
- direction
- <- or ->
- easier to under stand if most messages are ->
- however this is not always possible
- same object used by multiple other objects
- an object calls back to the object that called it
- can be conditions (guards) example
- only sent if condition is true
- able to approximate if-then-else using multiple branches with exclusive conditions
- this is better done in activity diagram
- looping messages example
- an asterisk idicated looping
- repeat message until condition id false
- send messge to each object in a collection
- may also be better in activity diagram
- an asterisk idicated looping
Interaction frames (UML 2.x)
- loop frame
- any kind of loop
- replaces * notation
- opt frame
- optional or conditional processing
- can replace [] notation
- alt frame
- if-then-else
- can replace [] notation
one thing that can cause complications is
- when something can a top level loop which is waiting for input.
- a cancel anytime option
Basic process of creation
- identity participants of a use case (dont always need to use a use-case diagram)
- use use case to create first version of the activity diagram. as you implement the code update the class and activity diagrams
- identify messges required to carry out use case
- for each message
- it is always sent
- is it sent conditionally
- is it sent multiple times
- assemble messages in correct sequence and attach to relevant lifelines/activations
- add returns where necessary
Case study ATM
bank is developing a new ATM system for their customers
scope and requirements
- each customer has one or mor accounts
- transaction types are
- view balance
- withdraw cash
- deposit funds
- the customer can cancel at any point before final confirmation
- customer authenticates by inserting bank card and entering four digit pin
process
- choose account
- choose amount
- check customer funds
- check amount in cash dipenser
- results
- withdraw amount
- dispense amount
- remind user
this diagam is probably too general for this case
note navigability of domain
sequence diagram


