View
234
Download
1
Category
Preview:
Citation preview
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.
Recommended