OO Analyse in de praktijk

Presentatie over: "OO Analyse in de praktijk"— Transcript van de presentatie:

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

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

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

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

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

6 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) 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 !!) 3. Prijs en subtotaal verschijnen op het scherm. (zichtbaar !!) 4. Productbeschrijving en prijs worden gedrukt. (zichtbaar !!) OO Analyse, III Use Cases & OOD-principes

7 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 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. OO Analyse, III Use Cases & OOD-principes

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

9 OO Analyse, III Use Cases & OOD-principes
Opmerkingen Het figuurtje (stick figure) stelt de ‘actor’ voor. Dit is de externe figuur die de externe stimulus geeft. Actors kunnen ook machines zijn, bvb een klok. Actors kunnen meerdere use cases opstarten. De <<extends>>-pijl vertrekt van uit de alternate course. De <<uses>>-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. Strict genomen is het diagram een mix van een use case diagram en een system boundary diagram. OO Analyse, III Use Cases & OOD-principes

10 Extra toeters en bellen
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. Pre- en postcondities zijn wel nodig voor de uitvoerbare code. Ze hangen samen met het testen OO Analyse, III Use Cases & OOD-principes

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

12 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. Als een publieke methode veranderd, moet de client hercompileren, zich zorgen maken of hij zijn code moet aanpassen,… OO Analyse, III Use Cases & OOD-principes

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

14 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. <<interface>> Persistent Werknemer PersistenteWerknemer OO Analyse, III Use Cases & OOD-principes

15 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. Er moet getest worden van welk type de gebruikte klasse is. OO Analyse, III Use Cases & OOD-principes

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

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

18 Liskov’s Substitutie: Tegenvoorbeeld (vervolg)
Wat is het probleem met dit tegenvoorbeeld: 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. 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: OO Analyse, III Use Cases & OOD-principes

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

20 OO Analyse, III Use Cases & OOD-principes
Dependency Inversion De term was beter geweest: ‘Depend on Abstract’ De naam komt van de volgende regel Je concrete klassen moeten afhangen van abstracte klassen en niet omgekeerd. Waarom: 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 OO Analyse, III Use Cases & OOD-principes

21 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 OO Analyse, III Use Cases & OOD-principes

22 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. OO Analyse, III Use Cases & OOD-principes

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