De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

Ontwerpen Sequence Diagrammen & Toestandsdiagrammen.

Verwante presentaties


Presentatie over: "Ontwerpen Sequence Diagrammen & Toestandsdiagrammen."— Transcript van de presentatie:

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 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: 1.De speler geeft aan dat er gevuurd moet worden 2.De Held vuurt het geselecteerde wapen 3.Het wapen vuurt ammo [1] 4.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

8 Case 1: Shooter Speler

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

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-entrant message: een methode wordt actief van een object dat al actief is

12 Sequence diagram doorlopen Stappen: 1.Begin linksboven bij actor 2.Volg de activatie naar beneden 3.Volg het eerste bericht dat je tegenkomt 4.Herhaal vanaf stap 2 5.Stop als je bij actor geen berichten meet tegenkomt Actieve MethodenActieve ObjectenvuurHeldvuurselectedgebruikAmmoHeld Er zijn dus meerdere methoden & objecten tegelijk actief

13 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: 1.De speler geeft aan dat er op knop gedrukt moet worden 2.De Held drukt op de knop 3.De knop opent de bijbehorende deur [1] 4.Na 10 seconden sluit de deur weer Postconditie: nvt Alternative flow: [1] De knop was een val 1.De knop activeert een transporter 2.De transporter laat een vijand verschijnen 3.De vijand valt de mens aan

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

16 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

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

18 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

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 Combined Fragments 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 stijgt af & Yoshi gaat rennen Mario verliest cape Mario wordt klein Mario gaat dood

24 Hoe modelleren we dit: Opslaan mushroom Mario wordt groot 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 Groot Klein Geraakt() Toestand TransitieEvent

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: Mario Klassendiagram

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) 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?

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 Mario Uitgebreider 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 Mario Versimpeld toestandsdiagram Pseudo Toestanden: Meerdere ‘ingangen’, 1 uitgang

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

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

36 Case Mario toestandsdiagrammetje 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.


Download ppt "Ontwerpen Sequence Diagrammen & Toestandsdiagrammen."

Verwante presentaties


Ads door Google