Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering

Transcriptie

1 Deel II: Modelleren en software ontwikkeling Hoofdstuk 7 Software ontwikkeling - Overzicht 2005 Prof Dr. O. De Troyer, pag. 1 Naïeve benadering De vereisten voor het systeem worden geformuleerd en op basis hiervan wordt de code geschreven 2005 Prof. Dr. O. De Troyer pag. 2 1

2 Naïeve benadering Deze benadering leidt vrijwel altijd tot problemen: Meer tijd nodig dan voorzien Meer middelen (geld) nodig dan voorzien Voldoet niet aan de verwachtingen Methoden voor het ontwikkelen van software zijn noodzakelijk 2005 Prof. Dr. O. De Troyer pag. 3 Software ontwikkelingsmethode Een software ontwikkelingsmethode biedt twee vormen van hulp: Een stappenplan (proces) dat men kan volgen Meestal gebaseerd op het maken van modellen Een aantal notaties om de modellen in neer te schrijven Meestal grafisch 2005 Prof. Dr. O. De Troyer pag. 4 2

3 Software ontwikkelingsmethode UML is vrij populair als standaard notatie voor OO ontwikkeling Er is minder eensgezindheid over het te gebruiken proces 2005 Prof. Dr. O. De Troyer pag. 5 Het waterval proces 2005 Prof. Dr. O. De Troyer pag. 6 3

4 2005 Prof. Dr. O. De Troyer pag. 7 Het waterval ontwikkelingsproces Elke stap (fase) vertegenwoordigt een andere activiteit Basis aannames van het waterval ontwikkelingsproces De verschillende stappen vinden sequentieel plaats Elke fase moet volledig beëindigd zijn voor de volgende kan aangevangen worden Meestal is er wel een vorm van feedback tussen de verschillende fasen 2005 Prof. Dr. O. De Troyer pag. 8 Het waterval ontwikkelingsproces Oudste ontwikkelingsproces Goed voor wel gekende systemen met weinig problemen en stabiele requirements Dit is echter zelden het geval Nadelen Het succes van het systeem enkel te verifiëren door testen Testen kan pas op het einde van het volledige proces Hoog risico: We kunnen enkel zien of het systeem voldoet wanneer al het werk al gedaan is 4

5 Iteratief ontwikkelingsproces Antwoord op de tekortkomingen van het waterval proces: Incrementeel: volledig systeem wordt deel per deel ontwikkeld Iteratief: de verschillende fasen van het ontwikkelingsproces worden verschillende keren herhaald De moderne ontwikkelingsprocessen zijn allemaal iteratief en incrementeel 2005 Prof. Dr. O. De Troyer pag. 9 Spiraal proces model Uitgangspunt: Meestal onmogelijk om iets van de eerste keer juist te hebben Daarom worden de verschillende fasen verschillende malen herhaald De 4 kwadranten vertegenwoordigen de belangrijkste fasen Geen vast proces 2005 Prof. Dr. O. De Troyer pag. 10 5

6 Unified Process (UP) Verschillende activiteiten (workflows) in verschillende iteraties Verschillende fasen Elke fasen bevat verschillende iteraties 2005 Prof. Dr. O. De Troyer pag. 11 De balans tussen de activiteiten is verschillend voor verschillende fasen UML en UP UML kan gebruikt worden met verschillende ontwikkelingsprocessen Omdat UP ontwikkeld werd door de ontwerpers van UML wordt UML vaak gebruikt in combinatie met UP 2005 Prof. Dr. O. De Troyer pag. 12 6

7 Ontwikkelingsfasen Systeem conceptie Analyse Design Implementatie Testen Training Ingebruikname Onderhoud 2005 Prof. Dr. O. De Troyer pag. 13 Ontwikkelingsfasen Systeem conceptie Bedenken van de applicatie; formuleren van de initiële vereisten 2005 Prof. Dr. O. De Troyer pag. 14 7

8 Ontwikkelingsfasen Analyse Doel is specificeren wat moet ontwikkeld worden; niet hoe het zal gebeuren Het probleem/systeem moet men begrijpen voor men het kan oplossen/maken Input: bestaande documenten, interviews, bestaande toepassingen,... Modellen om de problematiek te begrijpen 2005 Prof. Dr. O. De Troyer pag. 15 Ontwikkelingsfasen Analyse omvat: Domein analyse Het analyseren van het domein deel van de reële wereld dat relevant is voor het systeem Het maken van het domein model Beschrijft de relevante objecten en relaties in het domein Applicatie analyse (ook wel systeem analyse genoemd) Focus is nu op de applicatie/het systeem zelf. Verschillende gebruikers, gevraagde functionaliteit E.g. Applicatie objecten ipv domein objecten» bestaan niet in het domein maar zijn relevant voor de applicatie Het applicatie model beschrijft het systeem van buiten af (niet de implementatie - zwarte doos principe) 2005 Prof. Dr. O. De Troyer pag. 16 8

9 Ontwikkelingsfasen Systeem Design Ontwerp van de architectuur van het systeem Architectuur: Hoog niveau plan van het systeem Beslissen over strategieën Klasse Design Meer gedetailleerde modellen gericht op het realiseren van het systeem Gebaseerd op de resultaten van de analyse fase en rekening houdend met het systeem design 2005 Prof. Dr. O. De Troyer pag. 17 Ontwikkelingsfasen Implementatie Het programmeren Ontwerp modellen moeten vertaald worden naar code Tools kunnen tot op zeker niveau automatisch code genereren 2005 Prof. Dr. O. De Troyer pag. 18 9

10 Ontwikkelingsfasen Testen Om fouten uit de software te halen Om na te gaan dat het systeem inderdaad aan de verwachtingen voldoet Zowel wat betreft functionaliteit Als wat betreft gebruikersgemak Testen is niet enkel op het einde van het ontwikkelingsproces maar gedurende het gehele traject! 2005 Prof. Dr. O. De Troyer pag. 19 Ontwikkelingsfasen Training Opleiden van de gebruikers Hoeveelheid afhankelijk van het systeem en de gebruikers 2005 Prof. Dr. O. De Troyer pag

11 Ontwikkelingsfasen Ingebruikname (deployment) Installatie scripts nodig Interactie met andere systemen mogelijk Verschillen wat betreft OS Soms lokalisatie nodig (aanpassen aan de lokale gewoonten - taal, cultuur,...) 2005 Prof. Dr. O. De Troyer pag. 21 Ontwikkelingsfasen Onderhoud Oplossen van bugs Nieuwe vereisten 2005 Prof. Dr. O. De Troyer pag

12 Overzicht 2005 Prof. Dr. O. De Troyer pag. 23 Analyse Probleembeschrijving (in natuurlijke taal) is de input Onvolledig, niet precies, niet consistent Analyse moet dit omzetten naar precieze, ondubbelzinnige modellen Domein Analyse & Applicatie Analyse 2005 Prof. Dr. O. De Troyer pag

13 Overzicht 2005 Prof. Dr. O. De Troyer pag. 25 Domein analyse Beschrijving van de domein (deel van de reële wereld) Domein klassenmodel Domein toestandsmodel Domein interactiemodel 2005 Prof. Dr. O. De Troyer pag

14 Domein Klassenmodel Domein klassenmodel klassen en relaties van het domein Statische structuur is meestal stabieler dan de andere aspecten Daarom belangrijk vertrekpunt Initieel model bevat meestal tekortkomingen Verbeteren door iteraties 2005 Prof. Dr. O. De Troyer pag. 27 Domein toestandsmodel Maak een toestandsmodel indien relevant Identificeer klassen met toestandsafhankelijk gedrag Maak de toestandsdiagrammen 2005 Prof. Dr. O. De Troyer pag

15 Domein interactiemodel Een interactiemodel is zelden relevant voor domein analyse Nadruk ligt op de structuur van het domein 2005 Prof. Dr. O. De Troyer pag. 29 Overzicht 2005 Prof. Dr. O. De Troyer pag

16 Applicatie analyse Beschrijving van de applicatie Applicatie interactiemodel Applicatie klassenmodel Applicatie toestandsmodel 2005 Prof. Dr. O. De Troyer pag. 31 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag

17 Baken de grenzen af Use cases delen het systeem op in delen en tonen wie betrokken is met elke deel Ze beschrijven echter niet het dynamisch gedrag 2005 Prof. Dr. O. De Troyer pag. 33 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag

18 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag. 35 Maak activiteitendiagrammen Maak activiteitendiagrammen voor complexe use cases Sequentiediagrammen geven niet duidelijk weer wanneer er keuze en alternatieven zijn 2005 Prof. Dr. O. De Troyer pag

19 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag. 37 Organiseer actors en use case Toevoegen van include, extend en generalizatie 2005 Prof. Dr. O. De Troyer pag

20 Applicatie interactiemodel Stappenplan Baken de grenzen van het systeem af Bepaal de actoren Bepaal use cases Komen tot sequentiediagrammen Maak scenario s voor de use cases Voeg variaties en uitzonderingen toe Maak sequentiediagrammen voor de scenario s Maak activiteiten diagrammen voor complexe use cases Organiseer de actors en use cases Check af met het domein model 2005 Prof. Dr. O. De Troyer pag. 39 Check af met domein model De modellen moeten consistent zijn met het domein model Actors, use cases, scenario's moeten gebaseerd zijn op klassen en concepten uit het domein model Check of het domein model voldoende is voor de diverse scenario's 2005 Prof. Dr. O. De Troyer pag

21 Applicatie analyse Beschrijving van de applicatie Applicatie interactiemodel Applicatie klassenmodel Applicatie toestandsmodel 2005 Prof. Dr. O. De Troyer pag. 41 Applicatie klassenmodel Definieert nu de klassen van de applicatie zelf 2005 Prof. Dr. O. De Troyer pag

22 Applicatie toestandsmodel De klassen van de applicatie hebben meestal belangrijk toestandsafhankelijk gedrag Stappenplan Zoek de applicatieklassen met toestandsafhankelijk gedrag Maak de toestandsdiagrammen Check met de andere modellen voor consistentie 2005 Prof. Dr. O. De Troyer pag. 43 Voeg operaties toe aan applicatie klassenmodel Definieer operaties voor de applicatie klassen Basis operaties om attributen en associaties op te vragen/wijzigen Mogen gedurende analyse weggelaten worden Operaties afkomstig van de interactie modellen Operaties afkomstig van reële wereld operaties 2005 Prof. Dr. O. De Troyer pag

23 Overzicht 2005 Prof. Dr. O. De Troyer pag Prof. Dr. O. De Troyer pag. 46 Klasse Design Doel Analyse model verder uitwerken richting implementatie rekening houdend met de systeem design Niet nodig om te veranderen van techniek want OO geschikt voor analyse, design en implementatie Niet nodig om een nieuw model te maken; we kunnen vertrekken van de applicatie klasse uit het applicatie klassenmodel 23

24 2005 Prof. Dr. O. De Troyer pag. 47 Klasse Design Applicatie klassen verder uitwerken rekening houdend met Uitvoeringstijd Geheugen Ander kostfactoren Beslissen over algoritmen Opsplitsen van complexe operaties Detail toevoegen - aanpassingen maken Iteratief proces Implementatie Implementatie door middel van OO taal is meest voor de handliggend, bijv. Java, C++, C# OO talen hebben ook klassen en instanties Voor sommige zaken is er geen overeenkomstig implementatie constructie: associaties toestandsdiagrammen Gebruik een systematisch en consistente benadering voor het implementeren ervan 2005 Prof. Dr. O. De Troyer pag

25 Implementeren van klassen en instanties Klasse en instanties Ook in OO-talen Terminologie kan licht verschillen, voorbeelden: Instantie variabelen ipv attributen Extend/derive ipv inherit Static methods ipv Klasse methoden Er kunnen beperkingen of relaxaties zijn Bijv. geen multiple inheritance Bijv. Geen standaard encapsulatie van attributen Pure OO talen (bijv. Smalltalk) hebben geen ingebouwde datatypen en dus ook geen waarden (enkel objecten) Meestal expliciete constructor Opgelet met inheritance (zie later) 2005 Prof. Dr. O. De Troyer pag. 49 Implementatie Type verificatie en polymorfisme Polymorfisme Verschillende operaties in verschillende klasse kunnen dezelfde naam hebben. Vraag: welke methode moet gebruikt worden wanneer zo n operatie opgeroepen wordt voor een object Oplossing late binding bij uitvoering wordt opgezocht tot welke klasse het object behoort. Indien in deze klasse een methode bestaat die de operatie implementeert dan wordt deze methode gebruikt 2005 Prof. Dr. O. De Troyer pag

26 Implementeren van associaties in een programmeertaal Associaties kunnen worden geïmplementeerd via referentie (pointers) attributen Maar: Laten maar navigatie toe in één enkele richting Leg de verantwoordelijkheid voor het bijhouden en wijzigen van de referentie bij slechts één klasse Andere klassen hebben enkel toegang via een interface (operaties: getxxx, setxxx) 2005 Prof. Dr. O. De Troyer pag. 51 Implementeren van associaties in een programmeertaal Geval 1: associatie wordt maar in één richting doorlopen Implementeer de associatie via een referentie (pointer) attribuut naar het object in de vertrekklasse Is de multipliciteit 1 dan simpele referentie zoniet verzameling van referenties Een data structuur zoals een vector kan hiervoor gebruikt worden 2005 Prof. Dr. O. De Troyer pag

27 Implementeren van associaties in een programmeertaal 2005 Prof. Dr. O. De Troyer pag. 53 Implementeren van associaties in een programmeertaal Multipliciteit moet in de code gecheckt worden public Person(Company c) { if (c == null) { // throw NullLinkError } Employeer = c ; } 2005 Prof. Dr. O. De Troyer pag

28 Implementeren van associaties in een programmeertaal Geval 2: associatie wordt in beide richtingen doorlopen Implementeer maar 1 richting via een referentie (pointer) attribuut in één van de 2 klassen De andere richting moet dan via een zoekfunctie Enkel zinvol wanneer de niet geïmplementeerde richting maar sporadisch dient gebruikt te worden 2005 Prof. Dr. O. De Troyer pag. 55 Implementeren van associaties in een programmeertaal Geval 2: associatie wordt in beide richtingen doorlopen Implementeer beide richtingen Beide richtingen via een referentie (pointer) attribuut naar het object Voordeel : voor beide richtingen snelle toegang Nadeel: bij update moeten beide referenties aangepast worden Maak slechts 1 van de 2 klassen verantwoordelijk voor het onderhoud van de links 2005 Prof. Dr. O. De Troyer pag

29 Implementeren van associaties in een programmeertaal 2005 Prof. Dr. O. De Troyer pag. 57 Implementeren van associaties in een programmeertaal Geval 2: associatie wordt in beide richtingen doorlopen Implementeer via een associatie object 2005 Prof. Dr. O. De Troyer pag

30 Implementeren van associaties in een programmeertaal Toegang minder snel dan bij het gebruik van referenties Hashing techniek voor constante toegangstijd Goed wanneer niet alle objecten van de klassen links hebben Enkel ruimte voor de bestaande links 2005 Prof. Dr. O. De Troyer pag. 59 Implementeren van een associatie klasse Associatie met een associatieklasse Introduceer klasse voor associatie 2005 Prof. Dr. O. De Troyer pag

31 Implementeren van een associatie klasse class Registration { Registration(Student st) { student = st ; mark = 0 ; } private Student student ; private int mark ; } 2005 Prof. Dr. O. De Troyer pag. 61 Implementeren van een associatie klasse public class Module { private Vector registrations ; public void enrol(student st) { registrations.addelement( new Registration(st)) ; } } 2005 Prof. Dr. O. De Troyer pag

32 Relationele database Implementeren van klassen in een database Indien een identificerend attribuut Indien geen identificerend attribuut 2005 Prof. Dr. O. De Troyer pag. 63 Relationele database 1-to-many case Implementeren van associaties in een database 2005 Prof. Dr. O. De Troyer pag

33 Relationele database many-to-many case Implementeren van associaties in een database 2005 Prof. Dr. O. De Troyer pag. 65 Implementatie van compositie Sommige OO talen (bijv C++) laten toe dat objecten andere objecten bevatten dus compositie Andere talen (bijv Java) laten alleen een referentie naar een ander object toe. De eigenschappen van compositie (gelijktijdig bestaan) moet afgedwongen worden door middel van code 2005 Prof. Dr. O. De Troyer pag

34 Implementeren van toestanddiagrammen Oplossing 1: door het bijhouden van de toestand door middel van een attribuut public class Account { private final int InCredit = 0 ; private final int OverDrawn = 1 ; private final int Suspended = 2 ; private int state ; // } 2005 Prof. Dr. O. De Troyer pag. 67 Implementeren van toestanddiagrammen 2005 Prof. Dr. O. De Troyer pag

35 Implementeren van toestanddiagrammen Initiële toestand implementeren via de constructor public Account() { state = InCredit ; } Implementeren van de operaties via een switch public void withdraw(double amt) { switch (State) { case InCredit: if (amt > bal) { state = Overdrawn; } bal -= amt ; break ; case Overdrawn: case Suspended: break ; } } 2005 Prof. Dr. O. De Troyer pag. 69 Implementeren van toestanddiagrammen Groepeer toestanden voor samengestelde toestanden public void suspend() { switch (state) { case InCredit: case Overdrawn: state = Suspended ; break ; case Suspended: break ; } } 2005 Prof. Dr. O. De Troyer pag

36 Implementeren van toestanddiagrammen (2) Oplossing 2: Representeer elke toestand door een klasse (toestandsklasse) Elke toestandsklasse implementeert dan het gedrag voor elke operatie geldig in die toestand 2005 Prof. Dr. O. De Troyer pag. 71 Implementeren van toestanddiagrammen (2) Algemeen geval: De context klasse representeert de klasse met toestandsafhankelijk gedrag De toestanden worden voorgesteld door instanties van de Stateklassen: Elk context-object is geassocieerd met juist 1 state-object op elk moment in de tijd Wanneer een context-object een request krijgt delegeert hij dit daar het relevante state-object (door polymorfisme) 2005 Prof. Dr. O. De Troyer pag

37 Implementeren van toestanddiagrammen (2) 2005 Prof. Dr. O. De Troyer pag. 73 Or more general Implementeren van toestanddiagrammen (2) 2005 Prof. Dr. O. De Troyer pag

38 Implementeren van toestanddiagrammen Een gevolg is dat elke toestandsklasse toegang moet hebben tot het interne van de context klasse (zondigt tegen het principe van encapsulatie) 2005 Prof. Dr. O. De Troyer pag. 75 Goede en slechte programma ontwerpen Wanneer is een programma ontwerp goed? Goed Modelleert een systeem dat aan de verwachtingen van de gebruiker zal voldoen Is flexibel Requirements veranderen snel! De impact van veranderingen moet zo klein mogelijk zijn Realiseerbaar 2005 Prof. Dr. O. De Troyer pag

39 Ontwerpprincipes voor programma s 1. Lage graag van koppeling: low coupling 2. Abstractie 3. Hoge graad van samenhang: high cohesion 4. Hergebruik 5. Vervangbaarheid 6. Open-closed principe 2005 Prof. Dr. O. De Troyer pag. 77 Low coupling: encapsulatie Het principle van encapsulatie ondersteunt het principe van low coupling Hoe minder koppelingen, hoe gemakkelijker dingen kunnen gewijzigd worden zonder veel impact op de rest Wel noodzakelijk om te weten welke koppelingen er zijn Interfaces Definiëren waarop andere objecten/module zich mogen baseren Leggen dus mogelijke afhankelijkheden vast 2005 Prof. Dr. O. De Troyer pag

40 Encapsulatie interface interface Black box Als de black box wijzigt zonder dat de interface wijzigt dan heeft dit geen effect op zijn gebruikers (andere modules, andere objecten,...) Vb. Implementatie van een methode kan wijzigen zonder dat de signatuur van de methode wijzigt 2005 Prof. Dr. O. De Troyer pag. 79 Abstractie Abstractie De gebruiker moet afgeschermd worden van onnodige details De concepten encapsulatie en interface laten dit toe Gebruiker moet niet meer weten dan de interface om de module/interface te kunnen gebruiken Gebruiker mag niet meer weten dan de interface om de module/interface te kunnen gebruiken Ook wel information hiding genoemd 2005 Prof. Dr. O. De Troyer pag

41 High cohesion Een module/object zelf moet een hoge graad van samenhang hebben: high cohesion Geen samenraapsel van losse dingen Er moet een logisch verband zijn tussen de verschillende onderdelen Bijv via associaties, inheritance, Loskoppelen zou de regel van low coupling schenden! 2005 Prof. Dr. O. De Troyer pag. 81 Hergebruik Hergebruik Het opnieuw gebruiken van een module/object in een andere context Daarom object/module niet afhankelijk maken van een welbepaalde context/situatie 2005 Prof. Dr. O. De Troyer pag

42 Vervangbaarheid Vervangbaarheid Het moet gemakkelijk zijn om een object/module te vervangen door een andere zonder dat dit een effect heeft op de gebruikers Voorbeeld: sorteer-methode via buble sort te vervangen door quick sort Encapsulatie en interfaces ondersteunen dit 2005 Prof. Dr. O. De Troyer pag. 83 Open-closed principe Open-closed principe Betrand Meyer (boek: Object- Oriented Software Construction) Vaak maakt een klasse/deelsysteem gebruik van de diensten aangeboden door een andere klasse/deelsysteem Supplier module: verleent de diensten Client module : maakt gebruik van de diensten 2005 Prof. Dr. O. De Troyer pag

43 Open-closed principe Een module is gesloten indien het niet meer onderhevig is aan wijzigingen die een invloed kunnen hebben op clients De module is stabiel Clients kunnen de module gebruiken zonder dat men bevreesd moet zijn voor wijzigingen Een module is open indien het nog kan worden uitgebreid Belangrijk voor onderhoud en algemene uitbreidbaarheid van het systeem Open-closed principe Probeer modules te maken die zowel open als gesloten zijn 2005 Prof. Dr. O. De Troyer pag. 85 Open-closed principe Open-closed principe Lijkt een contradictie Daarom zijn mechanismen nodig die toelaten om een module uit te breiden zonder het te wijzigen Interfaces en encapsulatie laten dit toe clients mogen enkel afhankelijk zijn van de interface Implementatie kan gewijzigd worden zonder de clients te beïnvloeden 2005 Prof. Dr. O. De Troyer pag

44 Mechanismen - 1 Encapsulatie principe voor klassen: Alle attributen private Enkel de definitie van een publieke methode is zichtbaar, niet zijn implementatie Private methoden voor hulpmethoden Alles wat onzichtbaar is kan gewijzigd worden zonder problemen voor de clients Nadelen: Sommige programmeertalen ondersteunen dit niet volledig Niet elke client maakt gebruik van alles wat de supplier te bieden heeft Niet expliciet aan te geven 2005 Prof. Dr. O. De Troyer pag. 87 Mechanismen - 2 Abstracte Interface klassen Introductie van een extra (abstracte) klasse Definieert enkel de interface Heeft geen attributen Enkel de interface Attributen en de implementatie 2005 Prof. Dr. O. De Troyer pag

45 Mechanismen - 2 De abstracte supplier klasse is open Functionaliteit kan worden toegevoegd door extra subklassen Gesloten De concrete klasse kan worden gewijzigd zonder dat dit effect heeft op de clients Nadeel: Wijzigingen aan de interface (abstracte interface klasse) hebben nog steeds een invloed op de clients 2005 Prof. Dr. O. De Troyer pag. 89 Mechanismen - 3 Abstracte superklassen alle superklassen in een systeem zouden abstract moeten zijn Motivatie in the context of open-closed principe: Voorbeeld: Initieel enkel één soort van rekening Nu uitbreiding naar spaarrekeningen 2005 Prof. Dr. O. De Troyer pag

46 Mechanismen - 3 SavingsAccount is nu afhankelijk van CurrentAccount! Wijzigingen aan CurrentAccount hebben invloed op SavingsAccount De wijzigingen zijn niet noodzakelijk van toepassing op SavingsAccount Overwriting wordt noodzakelijk Of code in CurrentAccount nodig om uit te zoeken over welk soort rekening het gaat» Superklasse wordt afhankelijk van zijn subklasse» Toevoegen van subklasse niet meer zonder meer mogelijk 2005 Prof. Dr. O. De Troyer pag. 91 Mechanismen - 3 Oplossing Abstracte klasse 2005 Prof. Dr. O. De Troyer pag

47 Mechanismen - 4 Nadeel van abstracte interface klassen: Wijziging aan de interface klasse impliceert wijzigingen bij de clients + in de concrete klasse(n) Bijv. Toevoegen van een operatie 2005 Prof. Dr. O. De Troyer pag. 93 Mechanismen - 4 Oplossing: Abstracte Interface klassen loskoppelen Concrete klasse niet meer als subklasse van de abstracte interface klasse 2005 Prof. Dr. O. De Troyer pag

48 Mechanismen - 4 Uitbreidingen nu via specialisaties van de abstracte interface klasse 2005 Prof. Dr. O. De Troyer pag