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

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

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

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

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

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

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

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

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

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

OO Analyse, III Use Cases & OOD-principes Single Responsibility Liskov Substitutie Dependency Inversion 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. 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

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

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

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

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

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

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

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

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

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

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

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