Ontwerpen

1. Ontwerpen Sequence Diagrammen & Toestandsdiagrammen

2. 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

3. Interactie van objecten • Oftewel: Welke interactie hebben de objecten met elkaar om een bepaalde Use Case uit te voeren

4. 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

5. 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

6. Case 1: Shooter

7. Case 1: Shooter

8. Case 1: Shooter Speler

9. Betrokken elementen: UML Syntax Object Dit 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 Actor (zelfde als bij UC Diagram) Hier begint elk Sequence Diagram Object Syntax: <object> : <klasse v. Object> Dit is een ‘naamloos’ object van klasse ‘Held’

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

11. 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-entrantmessage: een methode wordt actief van een object dat al actief is

12. 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 vuur vuur gebruikAmmo Actieve Objecten Held selected Held Er zijn dus meerdere methoden & objecten tegelijk actief

13. Case 1: Shooter

14. Case 1: Shooter

15. 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 Parameter: Meegeven als het van belang is voor de werking binnen dit diagram 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.

16. destroy: een object wordt vernietigd. Lifeline eindigt met een schuin kruis. Syntax van destroymessage zelf verschilt. Niet alle programmeertalen handelen dit makkelijk af! Create, delete & self-message: UML syntax recursivemessage: is geen recursieve aanroep!! Is een selfmessage waarbinnen je weer berichten wil sturen naar andere objecten createmessage: Het object wordt hier pas aangemaakt. Het vak met de objectnaam en klassenaam staat pas hier, niet bovenaan. De lifeline begint hier selfmessage: Een object stuurt een bericht aan zichzelf

17. Combined Fragment, Hiërarchisch nummeren, durationmessage: UML Syntax 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 1: if Voorwaarde 2: else Alt fragment: if-else constructie Combined Fragment: Een bepaalde groep berichten hoort bij elkaar ({ } in code)

18. CombinedFragments • 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

19. 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

20. 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

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

22. 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…

23. Hoe modelleren we dit: Mario wordt klein Mario verliest cape Mario gaat dood Mario stijgt af & Yoshi gaat rennen

24. Hoe modelleren we dit: Opslaan mushroom Opslaan mushroom Mario wordt groot Opslaan mushroom Zelfde!

25. 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)

26. 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 Geraakt() Groot Klein Toestand Transitie Event

27. 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

28. Case: MarioKlassendiagram

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

30. 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

31. 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

32. 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.

33. Case MarioVersimpeld toestandsdiagram Pseudo Toestanden: Meerdere ‘ingangen’, 1 uitgang

34. Case MarioVersimpeld toestandsdiagram Meerdere uitgangen mag alleen met guards (welke kies je anders?)

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

36. 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.