Sequence Diagrammen & Toestandsdiagrammen 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: Shooter Use 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: De speler geeft aan dat er gevuurd moet worden De Held vuurt het geselecteerde wapen Het wapen vuurt ammo [1] De gebruikte ammo wordt verwijderd Postconditie: er is ammo verbruikt Alternative flow: [1] Er is geen ammo voor dit wapen. Het wapen wordt niet gevuurd

Case 1: Shooter Speler

Betrokken elementen: UML Syntax De volgorde maakt in principe niet uit. Het ligt voor de hand om de volgorde van aanroepen aan te houden Actor (zelfde als bij UC Diagram) Hier begint elk Sequence Diagram Object Dit is object ‘selected’ van klasse ‘Wapen’ Object Syntax: <object> : <klasse v. Object> Dit is een ‘naamloos’ object van klasse ‘Held’

‘Leven’ van objecten: UML Syntax Tijd LifeLine: het object bestaat in het systeem Activatie(balk): er wordt op dit moment een methode van dit object uitgevoerd (officieel: gereageerd op bericht)

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 Hierarchische nummers: eerste nummer: bericht van actor, tweede nummer: bericht van eerst gecallde object, derde nummer bericht van tweedst gecalld object, etc. Re-entrant message: een methode wordt actief van een object dat al actief is

Sequence diagram doorlopen Stappen: Begin linksboven bij actor Volg de activatie naar beneden Volg het eerste bericht dat je tegenkomt Herhaal vanaf stap 2 Stop als je bij actor geen berichten meet tegenkomt Actieve Methoden Actieve Objecten Er zijn dus meerdere methoden & objecten tegelijk actief vuur Held vuur selected gebruikAmmo Held

Case 1: Shooter Use 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 aanvalt Primary Actor: Speler Secondary Actor: nvt Preconditions: speler staat naast een bepaalde knop Main flow: De speler geeft aan dat er op knop gedrukt moet worden De Held drukt op de knop De knop opent de bijbehorende deur [1] Na 10 seconden sluit de deur weer Postconditie: nvt Alternative flow: [1] De knop was een val De knop activeert een transporter De transporter laat een vijand verschijnen De vijand valt de mens aan

Case 1: Shooter

Asynchroon, parameter: UML Syntax Parameter: Meegeven als het van belang is voor de werking binnen dit diagram 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.

Create, delete & self-message: UML syntax destroy: een object wordt vernietigd. Lifeline eindigt met een schuin kruis. Syntax van destroy message zelf verschilt. Niet alle programmeertalen handelen dit makkelijk af! create message: Het object wordt hier pas aangemaakt. Het vak met de objectnaam en klassenaam staat pas hier, niet bovenaan. De lifeline begint hier 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 Alt fragment: if-else constructie Combined Fragment: Een bepaalde groep berichten hoort bij elkaar ({ } in code) Voorwaarde 1: if 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. Voorwaarde 2: else Hierarchische nummers: eerste nummer: bericht van actor, tweede nummer: bericht van eerst gecallde object, derde nummer bericht van tweedst gecalld object, etc.

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 gates 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

Continuations: UML Syntax De Lifelines moeten exact hetzelfde zijn Let op! Er kunnen geen messages tijdens de continuation gegeven worden. Alleen ervoor en erna 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

Diagrammen We weten nu: Maar… 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 wordt klein Mario verliest cape Mario stijgt af & Yoshi gaat rennen Mario gaat dood

Hoe modelleren we dit: 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 Geraakt() Klein 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: Mario Klassendiagram

Case Mario: Eerste Toestandsdiagram Start Toestand: In deze toestand begint het object (bij ‘new’) Deze Transitie is gratis; je volgt hem automatisch (geen event) 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? Eind Toestand: In deze toestand eindigt het leven van het object Hoe modelleer je het pakken van een mushroom als je al groot bent? Bij deze transitie moet de oude mushroom worden ‘opgeslagen’ Hoe modelleren we dat?

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 Mario Uitgebreider toestandsdiagram Een transitie naar zichzelf; hoe reageert het object op dit event? Een action doen en in dezelfde toestand blijven… Een guard: we doorlopen deze transitie als we ook aan deze voorwaarde voldoen Nog een action: er gebeurt iets ‘extra’s’ als we de transitie gebruiken 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 Mario Versimpeld toestandsdiagram Pseudo Toestanden: Meerdere ‘ingangen’, 1 uitgang

Case Mario Versimpeld toestandsdiagram Meerdere uitgangen mag alleen met guards (welke kies je anders?)

Case Mario: Ster Hoe modelleren we dat er na 30 seconden ‘automatisch’ iets gebeurt? 30 seconden onkwetsbaar

Case Mario toestandsdiagrammetje NB: het diagram is hier even versimpeld. 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.