De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

OO Analyse in de praktijk OO Analyse in de praktijk III Use Cases & OOD-principes.

Verwante presentaties


Presentatie over: "OO Analyse in de praktijk OO Analyse in de praktijk III Use Cases & OOD-principes."— Transcript van de presentatie:

1 OO Analyse in de praktijk OO Analyse in de praktijk III Use Cases & OOD-principes

2 2 OO Analyse, III Use Cases & OOD- principes Boeken/tutorials: UML for JAVA Programmers UML for JAVA Programmers (Robert C. Martin © Copyright 2003.) Vooral hoofdstuk 5 & 6 Vooral hoofdstuk 5 & 6 UML distilled UML distilled Martin Fowler

3 3 OO Analyse, III Use Cases & OOD- principes Inhoudstafel Use Cases Use Cases OOD-principes OOD-principes

4 4 OO Analyse, III Use Cases & OOD- principes Use Cases: Het Idee Martin: Martin: Beschrijft de voor de gebruiker merkbare gebeurtenissen, als gevolg van één gebruikersstimulus Beschrijft de voor de gebruiker merkbare gebeurtenissen, als gevolg van één gebruikersstimulus Fowler: Fowler: =Voor de gebruiker merkbare functie =Voor de gebruiker merkbare functie Bereikt 1 welbepaald doel voor de gebruiker Bereikt 1 welbepaald doel voor de gebruiker

5 5 OO Analyse, III Use Cases & OOD- principes Use Cases - Algemeen Beginfase van requirements analyse. Gaat de andere technieken vooraf. Beginfase van requirements analyse. Gaat de andere technieken vooraf. =Beschrijving van gedrag (evt in ovaaltjes). =Beschrijving van gedrag (evt in ovaaltjes). Eenvoudige techniek. Weinig precies. Klant kan meedoen. Eenvoudige techniek. Weinig precies. Klant kan meedoen. Helpt om klassen en relaties te vinden. Helpt om klassen en relaties te vinden. De diagrammen worden voortdurend bijgewerkt. De diagrammen worden voortdurend bijgewerkt. Gedetailleerde diagrammen bestaan maar zijn nutteloos. Gedetailleerde diagrammen bestaan maar zijn nutteloos.

6 6 OO Analyse, III Use Cases & OOD- principes Use Cases: Voorbeeld primary course Context: de producten van een winkelbezoeker passeren langs de kassierster. Een ‘normale piste‘ =‘primary course’=‘normal use case’ zou kunnen zijn: Registreer produkt (= 1 use case) Registreer produkt (= 1 use case) 1. Kassierster beweegt product over de barcodescanner (de ene stimulus !!) 1. Kassierster beweegt product over de barcodescanner (de ene stimulus !!) 2. Systeem geeft ‘piep‘-signaal om aan te geven dat de barcode werd begrepen. (hoorbaar !!) 2. Systeem geeft ‘piep‘-signaal om aan te geven dat de barcode werd begrepen. (hoorbaar !!) 3. Prijs en subtotaal verschijnen op het scherm. (zichtbaar !!) 3. Prijs en subtotaal verschijnen op het scherm. (zichtbaar !!) 4. Productbeschrijving en prijs worden gedrukt. (zichtbaar !!) 4. Productbeschrijving en prijs worden gedrukt. (zichtbaar !!)

7 7 OO Analyse, III Use Cases & OOD- principes Use Cases: Voorbeeld alternate course Context: de producten van een winkelbezoeker passeren langs de kassierster. Een ‘alternate course’ geeft een use case in geval van ‘problemen’: Barcode niet gekend Barcode niet gekend i.p.v. 2: Systeem geeft signaal om opnieuw te scannen. Als het na 3 pogingen niet lukt, geeft de kassierster het product manueel in.

8 8 OO Analyse, III Use Cases & OOD- principes Use Case/System Boundary Diagram Registreer produkt Barcode niet gekend >

9 9 OO Analyse, III Use Cases & OOD- principes Opmerkingen Het figuurtje (stick figure) stelt de ‘actor’ voor. Het figuurtje (stick figure) stelt de ‘actor’ voor. Dit is de externe figuur die de externe stimulus geeft. Dit is de externe figuur die de externe stimulus geeft. Actors kunnen ook machines zijn, bvb een klok. Actors kunnen ook machines zijn, bvb een klok. Actors kunnen meerdere use cases opstarten. Actors kunnen meerdere use cases opstarten. De >-pijl vertrekt van uit de alternate course. De >-pijl vertrekt van uit de alternate course. De >-pijl wijst naar een gemeenschappelijk gedeelte van een use case. De >-pijl wijst naar een gemeenschappelijk gedeelte van een use case. De rechthoek geeft de systeemgrenzen (system boundaries) weer. Zo hoort de ‘actor’ niet tot het systeem. De rechthoek geeft de systeemgrenzen (system boundaries) weer. Zo hoort de ‘actor’ niet tot het systeem. Strict genomen is het diagram een mix van een use case diagram en een system boundary diagram. Strict genomen is het diagram een mix van een use case diagram en een system boundary diagram.

10 10 OO Analyse, III Use Cases & OOD- principes Extra toeters en bellen In principe kan het diagram verrijkt worden met precondities en postcondities. In principe kan het diagram verrijkt worden met precondities en postcondities. In het vroege stadium waarin use cases gebruikt worden, hebben die dingen nog weinig zin. In het vroege stadium waarin use cases gebruikt worden, hebben die dingen nog weinig zin. Pre- en postcondities zijn wel nodig voor de uitvoerbare code. Ze hangen samen met het testen Pre- en postcondities zijn wel nodig voor de uitvoerbare code. Ze hangen samen met het testen

11 11 OO Analyse, III Use Cases & OOD- principes OOD principes Single Responsibility Single Responsibility Liskov Substitutie Liskov Substitutie Dependency Inversion Dependency Inversion

12 12 OO Analyse, III Use Cases & OOD- principes OOD principe: Single Responsibility Een klasse mag maar één reden hebben om te veranderen Waarom: Eenvoud. Stel een klasse verenigt verschillende functionaliteiten: Clients die maar in een beperkt aantal methoden geïnteresseerd zijn worden overweldigd door nutteloze methoden. Clients die maar in een beperkt aantal methoden geïnteresseerd zijn worden overweldigd door nutteloze methoden. Als een publieke methode veranderd, moet de client hercompileren, zich zorgen maken of hij zijn code moet aanpassen,… Als een publieke methode veranderd, moet de client hercompileren, zich zorgen maken of hij zijn code moet aanpassen,…

13 13 OO Analyse, III Use Cases & OOD- principes Single Responsibility: Tegenvoorbeeld Zo moet het NIET: Probleem: Een client van Werknemer die geen persistentie nodig heeft wordt overladen met nutteloze details > Persistent Werknemer Bedrijf

14 14 OO Analyse, III Use Cases & OOD- principes Single Responsibility: Oplossing Zo moet het: Oplossing: Code ivm persistentie staat nu apart. Een client die denkt met een Werknemer te werken, kan een PersistenteWerknemer krijgen zonder dat hij last heeft van de extra persistentie-methoden. > Persistent Werknemer PersistenteWerknemer

15 15 OO Analyse, III Use Cases & OOD- principes OOD principe: Liskov’s Substitutie Binnen client code moet een klasse steeds kunnen vervangen worden door en subklasse, zonder dat de functionaliteit verandert. Waarom: Vermijden van onvoorziene bugs. Stel dat hierop gezondigd wordt, doordat zonet een subklasse is ontworpen met uitzonderlijk gedrag. De clientcode moet aangepast worden om te voorzien in het speciaal geval. De clientcode moet aangepast worden om te voorzien in het speciaal geval. Er moet getest worden van welk type de gebruikte klasse is. Er moet getest worden van welk type de gebruikte klasse is.

16 16 OO Analyse, III Use Cases & OOD- principes Liskov’s Substitutie: Tegenvoorbeeld Zo moet het NIET: Zo moet het NIET: > Werknemer BetaaldeWerknemer Vrijwilliger +berekenSalaris {A}

17 17 OO Analyse, III Use Cases & OOD- principes Liskov’s Substitutie: Tegenvoorbeeld (vervolg) Binnen BetaaldeWerknemer hebben we: Binnen BetaaldeWerknemer hebben we: public double berekenSalaris(){ … return … ;// echt salaris > 0 } Binnen Vrijwilliger hebben we: Binnen Vrijwilliger hebben we: public double berekenSalaris(){ public double berekenSalaris(){ return 0; // fake salaris = 0 }

18 18 OO Analyse, III Use Cases & OOD- principes Liskov’s Substitutie: Tegenvoorbeeld (vervolg) Wat is het probleem met dit tegenvoorbeeld: Wat is het probleem met dit tegenvoorbeeld: Uitbetalen van een nulsalaris is niet hetzelfde als niet uitbetalen van een salaris. Uitbetalen van een nulsalaris is niet hetzelfde als niet uitbetalen van een salaris. Vb: genante situatie van een vrijwilliger die een salarisstrook met een dikke 0 krijgt. Vb: genante situatie van een vrijwilliger die een salarisstrook met een dikke 0 krijgt. De client van een Werknemer moet dus nagaan van welk dynamisch type de concrete Werknemer is. De client van een Werknemer moet dus nagaan van welk dynamisch type de concrete Werknemer is. Oproepen van berekenSalaris mogen gewoon niet gebeuren op objecten van het type Vrijwilliger. Vandaar de oplossing op de volgende slide: Oproepen van berekenSalaris mogen gewoon niet gebeuren op objecten van het type Vrijwilliger. Vandaar de oplossing op de volgende slide:

19 19 OO Analyse, III Use Cases & OOD- principes Liskov’s Substitutie: Oplossing > Werknemer BetaaldeWerknemer Vrijwilliger +berekenSalaris {A} Zo moet het:

20 20 OO Analyse, III Use Cases & OOD- principes Dependency Inversion De term was beter geweest: De term was beter geweest: ‘Depend on Abstract’ De naam komt van de volgende regel De naam komt van de volgende regel Je concrete klassen moeten afhangen van abstracte klassen en niet omgekeerd. Je concrete klassen moeten afhangen van abstracte klassen en niet omgekeerd. Waarom: Waarom: Concrete klassen veranderen vaak. Die veranderingen beïnvloeden jouw code. Concrete klassen veranderen vaak. Die veranderingen beïnvloeden jouw code. N.B: Het is misschien wel oké om concrete klassen te gebruiken die waarschijnlijk niet gaan veranderen, vb Date, HashMap, etc…. Maar je weet maar nooit. Zie VB6 -> VB.net N.B: Het is misschien wel oké om concrete klassen te gebruiken die waarschijnlijk niet gaan veranderen, vb Date, HashMap, etc…. Maar je weet maar nooit. Zie VB6 -> VB.net

21 21 OO Analyse, III Use Cases & OOD- principes Dependency Inversion: Tegenvoorbeeld Zo moet het NIET: Probleem: Indien de proprietary MicroToolForm zijn default properties wijzigt dan moet ik die ook accepteren of op verschillende plaatsen veranderen MicroToolForm MijnBoekhoudApplicatie *

22 22 OO Analyse, III Use Cases & OOD- principes Dependency Inversion: Eerste Verbetering MicroToolForm MijnBoekhoudApplicatie MijnForm Verbetering: Indien de proprietary MicroToolForm van (zeg maar) kleur verandert, dan kan ik dit nog wijzigen in MijnForm. *

23 23 OO Analyse, III Use Cases & OOD- principes Dependency Inversion: Tweede Verbetering MicroToolForm MijnBoekhoudApplicatie MijnConcreteForm * MijnForm > Verbetering: Indien nu de MicroToolForm verandert, hoeft MijnBoekhoudApplicatie zelfs niet te weten dat dit is gebeurd. Hij werkt met MijnForm abstracte klasse of interface.


Download ppt "OO Analyse in de praktijk OO Analyse in de praktijk III Use Cases & OOD-principes."

Verwante presentaties


Ads door Google