Ontwerpen

Sequence Diagrammen & Toestandsdiagrammen

Interactie van objecten Gegeven:

Use case Diagram & beschrijving WAT gaat het systeem doen

Klassendiagram WAT is de structuur van het systeem

Gevraagd HOE worden de Use Cases door het systeem

uitgevoerd mbv de bedachte structuur

Interactie van objecten

• Oftewel:

Welke interactie hebben de objecten met elkaar om een bepaalde Use Case uit te voeren

Interactie van objecten

• Vooraf:– Objecten kunnen alleen met elkaar interacteren als

hun klassen met elkaar verbonden zijn in het Klassendiagram

– Interacteren gaat altijd met behulp van berichten• Het ene object stuurt een bericht naar een ander object.

Dat object reageert hierop• In de praktijk is dat meestal: het ene object roept een

methode aan van het andere object– Dit verschilt per programmeertaal!

– We modelleren dit interne gedrag PER Use Case

Sequence Diagram

• Is een type interaction diagram binnen UML• Geeft de interactie weer tussen objecten op basis

van– Tijd– Onderlinge volgorde

• Geeft aan op welk moment binnen een Use Case objecten– Bestaan– Actief zijn– Elkaar berichten sturen

Case 1: Shooter

Case 1: ShooterUse Case: Vuur Wapen

ID: 1

Description: Gebruiker vuurt een wapen af. Er wordt ammo verbruikt

Primary Actor: Speler

Secondary Actor: nvt

Preconditions: geen

Main flow: 1. De speler geeft aan dat er gevuurd moet worden2. De Held vuurt het geselecteerde wapen3. Het wapen vuurt ammo [1]4. De gebruikte ammo wordt verwijderdPostconditie: er is ammo verbruikt

Alternative flow:[1] Er is geen ammo voor dit wapen. Het wapen wordt niet gevuurd

Case 1: ShooterSpeler

Betrokken elementen: UML SyntaxActor (zelfde als bij UC Diagram)Hier begint elk Sequence Diagram

ObjectSyntax: <object> : <klasse v. Object>Dit is een ‘naamloos’ object van klasse ‘Held’

ObjectDit is object ‘selected’ van klasse ‘Wapen’

De volgorde maakt in principe niet uit. Het ligt voor de hand om de volgorde van aanroepen aan te houden

‘Leven’ van objecten: UML Syntax

LifeLine: het object bestaat in het systeemActivatie(balk): er wordt op dit

moment een methode van dit object uitgevoerd (officieel: gereageerd op bericht)

Tijd

Berichten tussen objecten: UML Syntax

Message: actor stuurt een bericht naar de ‘naamloze’ held.Deze wordt nu ‘actief’ Nummer:

nummering van het bericht;

Return message: activatie is afgerond (kan return waarde bevatten

Re-entrant message: een methode wordt actief van een object dat al actief is

Sequence diagram doorlopenStappen:1. Begin linksboven bij actor2. Volg de activatie naar beneden3. Volg het eerste bericht dat je

tegenkomt4. Herhaal vanaf stap 25. Stop als je bij actor geen

berichten meet tegenkomt

Actieve Methoden Actieve Objecten

vuur Held

vuur selected

gebruikAmmo Held

Er zijn dus meerdere methoden & objecten tegelijk actief

Case 1: ShooterUse Case: Druk op Knop

ID: 2

Description: Gebruiker drukt op knop. Bij een goede knop opent een deur, bij een val verschijnt een vijand die de speler aanvaltPrimary Actor: Speler

Secondary Actor: nvt

Preconditions: speler staat naast een bepaalde knop

Main flow: 1. De speler geeft aan dat er op knop gedrukt moet worden2. De Held drukt op de knop3. De knop opent de bijbehorende deur [1]4. Na 10 seconden sluit de deur weerPostconditie: nvt

Alternative flow:[1] De knop was een val1. De knop activeert een transporter2. De transporter laat een vijand verschijnen3. De vijand valt de mens aan

Case 1: Shooter

Asynchroon, parameter: UML Syntax

Synchrone message: De zender van het bericht moet wachten tot het bericht afgehandeld is. Speler kan pas weer een opdracht geven als de Held gereageerd heeft op dit commando

Asynchrone message: De zender van het bericht hoeft niet te wachten tot het bericht afgehandeld is. De held kan nieuwe acties doen terwijl het ‘knop activeren’ wordt uitgevoerd.

Parameter: Meegeven als het van belang is voor de werking binnen dit diagram

Create, delete & self-message: UML syntax

create message: Het object wordt hier pas aangemaakt. Het vak met de objectnaam en klassenaam staat pas hier, niet bovenaan. De lifeline begint hier

destroy: een object wordt vernietigd. Lifeline eindigt met een schuin kruis. Syntax van destroy message zelf verschilt. Niet alle programmeertalen handelen dit makkelijk af!

self message: Een object stuurt een bericht aan zichzelf

recursive message: is geen recursieve aanroep!! Is een self message waarbinnen je weer berichten wil sturen naar andere objecten

Combined Fragment, Hiërarchisch nummeren, duration message: UML Syntax

Combined Fragment: Een bepaalde groep berichten hoort bij elkaar ({ } in code)

Alt fragment: if-else constructie Voorwaarde 1: if

Voorwaarde 2: else

Hiërarchisch nummeren: er zijn 3 objecten actief. We zitten nu in bericht 1 van object 1, bericht 1 van object 2 & bericht 3 van object 3

Duration Message: het duurt een tijdje voor deze message wordt doorgegeven. Hoe schuiner, hoe langer het duurt.

Combined Fragments

• opt: option, een ‘if’ zonder ‘else’• alt: alternatives, een if-else of switch• loop min, max [condition]: loop, minimaal

‘min’ keer herhalen en dan zolang ‘condition’ waar is ‘max’-’min’ keer herhalen

• break: break, uitvoeren als we voortijdig uit de loop stappen

Lost / found: UML Syntax

Found message: er komt (magischerwijs) een bericht van onbekende bron binnen

Lost message: dit object stuurt een bericht naar een onbekend object

Zou bij goed ontwerp eigenlijk niet moeten gebeuren

Gates / Ref: UML syntax

ref: je kan een deel van je interactie uitbesteden aan een ander sequence diagram. Je gebruikt dan gates om de input en output te regelen

Dit sequence diagram verricht werk dat uitbesteed is. Deze start dus niet met een actor, maar met een gate

gates

Continuations: UML Syntax

Continuation: Indien dit de duidelijkheid ten goede komt kan je een detail van een Sequence diagram in een ander diagram weergeven. Vaak gebruikt bij Combined Fragments

De Lifelines moeten exact hetzelfde zijn

Let op! Er kunnen geen messages tijdens de continuation gegeven worden. Alleen ervoor en erna

Diagrammen

• We weten nu:– De structuur van een systeem• Klassendiagram• Welke klassen hebben met welke klassen te maken en

hoe

– Het onderlinge gedrag binnen het systeem• Sequence diagram• Op wat voor manier communiceren objecten met

elkaar om Use Cases uit te voeren

• Maar…

Hoe modelleren we dit:

Mario stijgt af&

Yoshi gaat rennen

Mario verliest

cape

Mario wordt klein Mario gaat

dood

Hoe modelleren we dit:

Opslaan mushroom

Opslaan mushroom

Opslaan mushroom

Mario wordt groot

Zelfde!

Toestanden

• Het gaat hier om intern gedrag• Mario gedraagt zich in de ene toestand anders dan

in de andere toestand– Toestanden zijn hier: klein, groot, cape, opYoshi– Gedragen = reageren op andere objecten– Reageren op ander object = een method call van Mario– Niet alle reacties (ook al zijn ze per toestand anders)

leiden tot verandering van toestand.• Om dit te modelleren maak je een

toestandsdiagram (state machine diagram)

Toestandsdiagram: UML Syntax

• Een toestandsdiagram geeft per klasse het volgende aan:– Toestanden: Een object van deze klasse is in bepaalde

toestand en reageert anders op gebeurtenissen (meestal method calls) dan in andere toestanden.

– Transities: Een object van deze klasse verandert van de ene naar de andere toestand. De reden hiervoor is meestal een gebeurtenis (method call). Dit heet een event.

– x

Groot KleinGeraakt()

Toestand Transitie Event

Toestandsdiagram: ‘regels’

• Er wordt alleen een toestandsdiagram gemaakt van een klasse als er relevante toestanden zijn

• Er wordt alleen een toestand gemodelleerd als het object daadwerkelijk anders reageert in die toestand

• Events zijn in principe methoden van de klasse waar het toestandsdiagram bij hoort– Zie RDD; De attributen van een klasse (dus ook de

toestand) worden alleen aangepast door de klasse zelf.• Een enumeratie is vaak handig om de toestand bij te

houden

Case: MarioKlassendiagram

Case Mario:Eerste Toestandsdiagram

Start Toestand: In deze toestand begint het object (bij ‘new’)

Deze Transitie is gratis; je volgt hem automatisch (geen event)

Eind Toestand: In deze toestand eindigt het leven van het object

Bij deze transitie moet de oude mushroom worden ‘opgeslagen’ Hoe modelleren we dat?

Als je geraakt wordt als Yoshi, stijg je af en gaat terug naar de oude toestand. Hoe modelleer je dat en hoe modelleer je dat Yoshi dan rond gaat rennen?

Hoe modelleer je het pakken van een mushroom als je al groot bent?

Toestandsdiagram: Guard & Action

• Je kan bij een transitie een voorwaarde aangeven (Guard)– De transitie wordt dan doorlopen als het event plaatsvindt

EN aan de voorwaarde voldaan is.– Syntax: [voorwaarde]

• Je kan bij een transitie aangeven wat het effect is van het doorlopen van de transitie (Action)– Dit is een event (method call) dat gegenereerd wordt

doordat dit object van toestand verandert– Syntax: / action

• Je kan ook een transitie hebben naar dezelfde toestand

Case MarioUitgebreider toestandsdiagram

Een transitie naar zichzelf; hoe reageert het object op dit event? Een action doen en in dezelfde toestand blijven…

Nog een action: er gebeurt iets ‘extra’s’ als we de transitie gebruiken

Een guard: we doorlopen deze transitie als we ook aan deze voorwaarde voldoen

Hier zie je alle drie samen

Toestandsdiagram: pseudo-toestand

• Het diagram op de vorige slide is ‘nogal’ chaotisch geworden…

• Het leven kan makkelijker gemaakt worden door het toevoegen van pseudo-toestanden– Dit zijn een soort tijdelijke toestanden waaruit we

meteen weer vertrekken; een soort knooppunten– Syntax: zelfde als start-toestand.

Case MarioVersimpeld toestandsdiagram

Pseudo Toestanden: Meerdere ‘ingangen’, 1 uitgang

Case MarioVersimpeld toestandsdiagram

Meerdere uitgangen mag alleen met guards(welke kies je anders?)

Case Mario: Ster

30 secondenonkwetsbaar

Hoe modelleren we dat er na 30 seconden ‘automatisch’ iets gebeurt?

Case Mariotoestandsdiagrammetje

Er is geen event benodigd om een transitie te nemen. Er kan ook alleen een guard staan. De transitie wordt nu doorlopen zodra aan de voorwaarde voldaan is.Er moet wel altijd een event en / of guard staan.

NB: het diagram is hier even versimpeld.