Modulehandleiding Object georiënteerd ontwerpen HE – ICT CP/HIO

IG9OGO 

Instituut Informatie- en 

Communicatietechnologie 

Modulehandleiding 

Object georiënteerd ontwerpen 

HE – ICT CP/HIO 

(januari 2002: JAN/PRA/VRJ) 

versie 3.0 

1 

1

IG9OGO 

Modulehandleiding Object georienteerd ontwerpen 

Inhoudsopgave 

Inhoudsopgave .............................................................................................................................................................2 

Introductie....................................................................................................................................................................6 

INTRODUCTIE 1: Gebruik van de modulehandleiding Object georiënteerd ontwerpen .................................6 

Moduleopzet....................................................................................................................................................................6 

Introductie per moduletaak..............................................................................................................................................6 

Module verwerkingsaktiviteiten......................................................................................................................................6 

Terugkoppeling per moduletaak en toetsing van het geheel ...........................................................................................6 

INTRODUCTIE 2: Verslaggeving bij de praktikumopdrachten........................................................................6 

Planning........................................................................................................................................................................8 

Toelichting.................................................................................................................................................................8 

Planning per week......................................................................................................................................................8 

Moduletaak 1: Correct en robuust programmeren ..................................................................................................9 

INTRODUCTIE en TAAKOMSCHRIJVING .........................................................................................................9 

Voorkennis:.....................................................................................................................................................................9 

Taakdoel:.........................................................................................................................................................................9 

Oriëntatie:........................................................................................................................................................................9 

Verwerking:.....................................................................................................................................................................9 

Verdieping:......................................................................................................................................................................9 

Zelftoets: .........................................................................................................................................................................9 

LEESTEKST: Design by contract ..........................................................................................................................10 

Samenvatting.................................................................................................................................................................10 

Correctheid....................................................................................................................................................................10 

Assertie..........................................................................................................................................................................10 

Classinvariant................................................................................................................................................................11 

Nut van asserties ...........................................................................................................................................................11 

Design-by-contract........................................................................................................................................................12 

Design-by-contract : pre- en postcondities....................................................................................................................12 

Policy m.b.t. asserties....................................................................................................................................................13 

Run-time support...........................................................................................................................................................13 

Praktisch gebruik van asserties......................................................................................................................................13 

Hoe “ontdek” ik asserties? ............................................................................................................................................14 

VALKUILEN................................................................................................................................................................14 

UITGEWERKT VOORBEELD .............................................................................................................................15 

Voorbeeldopgave asserties:...........................................................................................................................................15 

Voorbeelduitwerking asserties: .....................................................................................................................................16 

OEFENINGEN moduletaak 1 ................................................................................................................................18 

Oefening 1.1 De bus......................................................................................................................................................18 

Oefening 1.2 Boekenplank...........................................................................................................................................18 

Oefening 1.3 Postorderbedrijf. ......................................................................................................................................19 

Oefening 1.4 Postzegelclub...........................................................................................................................................19 

ZELFTOETS moduletaak 1....................................................................................................................................21 

Moduletaak 2: Afbeelding NIAM analyse naar ontwerp van classes....................................................................22 

INTRODUCTIE en TAAKOMSCHRIJVING .......................................................................................................22 

Relevante voorkennis ....................................................................................................................................................22 

Taakdoel........................................................................................................................................................................22 

Oriëntatie.......................................................................................................................................................................22 

Verwerking....................................................................................................................................................................22 

Verdieping.....................................................................................................................................................................22 

Zelftoets ........................................................................................................................................................................22 

2


LEESTEKST: omzetting van NIAM IGD naar ontwerp van classes .....................................................................23 

Ontwerpen m.b.v. NIAM ..............................................................................................................................................23 

NIAM en ontwerp .........................................................................................................................................................23 

Voorbeeld classes..........................................................................................................................................................24 

Verfijning - schrappen van variabelen ..........................................................................................................................25 

Beperkingsregels (constraints) ......................................................................................................................................25 

Voorbeeld invariant.......................................................................................................................................................25 

Voorbeeld constructor ...................................................................................................................................................26 

Ontwerpen NIAM - nominalisatie.................................................................................................................................26 

Ontwerpen NIAM - n-aire feittypen..............................................................................................................................27 

Vereenvoudigen bij omzetting van n-aire feittypen ......................................................................................................28 

Ontwerpen NIAM - over identificatie ...........................................................................................................................28 

Samenvatting multipliciteit van types ...........................................................................................................................29 

Ontwerp en inheritance .................................................................................................................................................29 

OEFENINGEN moduletaak 2 .................................................................................................................................31 

OEFENING 2.1.............................................................................................................................................................31 

OEFENING 2.2.............................................................................................................................................................31 

OEFENING 2.3.............................................................................................................................................................31 

OEFENING 2.4.............................................................................................................................................................32 

OEFENING 2.5.............................................................................................................................................................32 

OEFENING 2.6.............................................................................................................................................................33 

OEFENING 2.7.............................................................................................................................................................34 

OEFENING 2.8.............................................................................................................................................................34 

OEFENING 2.8.............................................................................................................................................................35 

ZELFTOETS moduletaak 2..................................................................................................................................36 

Moduletaak 3: Introductie UML: use cases , class- en sequencediagrams ...........................................................37 


Voorkennis ....................................................................................................................................................................37 

Taakdoel........................................................................................................................................................................37 

Oriëntatie.......................................................................................................................................................................37 

Verwerking....................................................................................................................................................................38 

Verdieping.....................................................................................................................................................................38 

Zelftoets ........................................................................................................................................................................38 

LEESTEKST bij moduletaak 3 : Introductie in UML en Rational Rose2000 ........................................................39 

L3.1 Geschiedenis van UML.........................................................................................................................................39 

L3.2 Overzicht van UML..............................................................................................................................................40 

L3.2.1 Views .................................................................................................................................................................40 

L3.2.2 Diagrammen.......................................................................................................................................................41 

L3.2.3 Bouwstenen........................................................................................................................................................45 

L3.3 Gebruik van Classdiagrams , Use Casediagrams en Sequencediagrams ..............................................................45 

L3.3.1 Gebruik van Classdiagrams ...............................................................................................................................45 

L3.3.2 Gebruik van Use Case Diagram.........................................................................................................................48 

L3.3.3 Gebruik van Sequence Diagram ........................................................................................................................52 

UITGEWERKT VOORBEELD Garage Straatdijk BV.........................................................................................55 

Opdrachtomschrijving...................................................................................................................................................56 

Uitwerking ....................................................................................................................................................................56 

NIAM: feittypen en afgeleide feittypen ........................................................................................................................58 

Afbeelding naar classes in eerst opzet...........................................................................................................................58 

Use Cases bepalen.........................................................................................................................................................60 

SequenceDiagram .........................................................................................................................................................63 


OEFENING 3.1:............................................................................................................................................................65 

OEFENING 3.2: Bankautomaat (uitwerken op het systeem).......................................................................................65 

OEFENING 3.3: vervolg van bankautomaat oefening 3.2............................................................................................66 

OEFENING 3.4.............................................................................................................................................................66 

OEFENING 3.5.............................................................................................................................................................66 


IG9OGO 

3


Moduletaak 4: Uitbreiding Java taal concepten: interfaces en inheritance (verv.) .............................................68 

INTRODUCTIE en TAAKOMSCHRIJVING ........................................................................................................68 

Voorkennis ....................................................................................................................................................................68 

Taakdoel........................................................................................................................................................................68 

Oriëntatie.......................................................................................................................................................................68 

Verwerking....................................................................................................................................................................68 

Verdieping.....................................................................................................................................................................68 

Zelftoets ........................................................................................................................................................................68 

LEESTEKST Moduletaak 4: JAVA interface concept , inner class en inheritance (vervolg) . ............................68 

Java interface concept..............................................................................................................................................68 

Java interface................................................................................................................................................................69 

Eigenschappen van Java interfaces ...............................................................................................................................70 

Interfaces en vergelijking van objecten: Comparable ...................................................................................................71 

Interfaces en kopieën van objecten : Cloneable ............................................................................................................72 

Inner class ...............................................................................................................................................................73 

Inner class als Java taalconcept.....................................................................................................................................74 

Nogmaals: inheritance ............................................................................................................................................74 

Abstract class ................................................................................................................................................................74 

Opmerkingen over Ontwerpen met interfaces en abstract classes. .........................................................................75 


OEFENING 4.1 Toepassingen interfaces in JDK 1.2 ...................................................................................................76 

OEFENING 4.2 Overerving (nogmaals).......................................................................................................................76 

OEFENING 4.3. Gebruik van Java interface concept...................................................................................................76 

OEFENING 4.4 Adressen vergelijken met herdefinitie equals methode .....................................................................77 

OEFENING 4.5 Interface Comparable toepassing........................................................................................................78 

OEFENING 4.6 Inheritance en interface toepassing (op systeem uitwerken) ..............................................................78 


Moduletaak 5 : Collections.......................................................................................................................................81 


Voorkennis ....................................................................................................................................................................81 

Taakdoel........................................................................................................................................................................81 

Oriëntatie.......................................................................................................................................................................81 

Verwerking....................................................................................................................................................................81 

Verdieping.....................................................................................................................................................................81 

Zelftoets ........................................................................................................................................................................81 

LEESTEKST: Collecties .........................................................................................................................................82 

L5.0 Samenvatting ........................................................................................................................................................82 

L5.1 Scheiden van implementatie en zijn interface.......................................................................................................82 

L5.2 Standaard collectie types.......................................................................................................................................83 

L5.2.1 Set ......................................................................................................................................................................83 

L5.2.2 Map....................................................................................................................................................................85 

L5.2.3 List .....................................................................................................................................................................88 

L5.2.3.1 Stack ...............................................................................................................................................................89 

L5.2.3.2 Queue..............................................................................................................................................................91 

L5.2.3.3 Sequence .........................................................................................................................................................91 

L5.3 De Java Collections Framework (JCF) .................................................................................................................93 

L5.3.1 Interface Collection............................................................................................................................................94 

L5.3.2 Interface Set .......................................................................................................................................................94 

L5.3.3 Interface SortedSet.............................................................................................................................................94 

L5.3.4 Interface Comparable, ‘Natural Ordering’.........................................................................................................95 

L5.3.5 Interface Comparator .........................................................................................................................................95 

L5.3.6 Interface Map.....................................................................................................................................................98 

L5.3.7 Interface SortedMap ..........................................................................................................................................98 

L5.3.8 Interface List......................................................................................................................................................98 

L5.3.9 De Collections class...........................................................................................................................................99 

L5.3.10 Legacy, Vector & Hashtable............................................................................................................................99 

IG9OGO 

4


L5.4 De juiste collectie kiezen ....................................................................................................................................100 

L5.5 Gelijkheid van objecten ......................................................................................................................................101 

L5.6 Optional operations.............................................................................................................................................102 

OEFENINGEN moduletaak 5 ..............................................................................................................................103 

Oefening 5.1:...............................................................................................................................................................103 

Oefening 5.2:...............................................................................................................................................................103 

Oefening 5.3:...............................................................................................................................................................103 

ZELFTOETS moduletaak 5..................................................................................................................................104 

Moduletaak 6: Ontwerpen van collections ............................................................................................................105 

INTRODUCTIE en TAAKOMSCHRIJVING .....................................................................................................105 

Voorkennis ..................................................................................................................................................................105 

Taakdoel......................................................................................................................................................................105 

Oriëntatie.....................................................................................................................................................................105 

Verwerking..................................................................................................................................................................105 

Verdieping...................................................................................................................................................................105 

Zelftoets ......................................................................................................................................................................105 

LEESTEKST bij moduletaak 6 : Ontwerpen van collections............................................................................106 

L6.0 Samenvatting ......................................................................................................................................................106 

L6.1 Afleidingen uit de NIAM analyse.......................................................................................................................106 

L6.1.1 Analyse leidend tot de keuze van een Set ........................................................................................................106 

L6.1.2 Analyse leidend tot de keuze van een Map .....................................................................................................107 

L6.1.3 Analyse leidend tot keuze van een Stack .........................................................................................................108 

L6.1.4 Analyse leidend tot de keuze van een queue...................................................................................................109 

L6.1.5 Analyse leidend tot de keuze van een Sequence .............................................................................................110 

L6.2 Implementatie van een stack...............................................................................................................................112 

L6.2.1 De werking van de stack..................................................................................................................................112 

L6.2.2 Analyse van de Stack.......................................................................................................................................113 

L6.2.3 Implementatie van de classes...........................................................................................................................114 

L6.2.3 Implementatie van de classes...........................................................................................................................115 

L6.3 Analyse van een lijst ...........................................................................................................................................116 

L6.3.1 Implementatie van een Lijst.............................................................................................................................118 

OEFENINGEN moduletaak 6 .............................................................................................................................123 

OEFENING 6.1...........................................................................................................................................................123 

OEFENING 6.2...........................................................................................................................................................123 

OEFENING 6.3 (Uitwerken op het systeem en inleveren op het werkcollege) ..........................................................123 

OEFENING 6.4 (Verdieping) .....................................................................................................................................123 

ZELFTOETS bij moduletaak 6 ...................................................................................................................................124 

Opdracht 1. Onroerend goed.................................................................................................................................125 

Opdracht 2. Paardensport......................................................................................................................................126 

BIJLAGE A. UML Quick Reference for Rational Rose 2000............................................................................128 

BIJLAGE B. Uitwerkingen van de zelftoetsen.....................................................................................................134 

UITWERKING Zelftoets bij moduletaak 1 .........................................................................................................134 

UITWERKING Zelftoets bij moduletaak 2 ..........................................................................................................136 





Index .........................................................................................................................................................................145 

IG9OGO 

5

IG9OGO 


Introductie 

INTRODUCTIE 1: Gebruik van de modulehandleiding Object georiënteerd ontwerpen 

Moduleopzet 

Evenals bij de voorafgaande JAVA-modulen P_J1 en P_J2 is de te verwerken stof ingedeeld in 

moduletaken. De modulehandleiding dient als leidraad bij het uitvoeren van deze taken. 

Introductie per moduletaak 

Per moduletaak is in een introductieparagraaf aangegeven wat de vereiste voorkennis is en hoe 

het concrete taakdoel geformuleerd kan worden. In het onderdeel oriëntatie wordt de stof 

geplaatst in een groter geheel. 

Module verwerkingsaktiviteiten 

De activiteiten die kunnen resulteren in een goede verwerking van de stof beginnen reeds bij de 

aanwijzingen met betrekking tot de oriëntatie en worden verder uitgewerkt bij verwerking en 

verdieping: 

Oriëntatie: Hier wordt na een presentatie van de context van het onderwerp van deze taak een 

hoeveelheid te bestuderen materiaal aangedragen. Eén of meerdere onderwerpen worden in een 

leestekst aangeboden ter bestudering 

Verwerking: Na dit bestuderen van de leestekst dient de stof verder verwerkt te worden door het 

maken van oefeningen, eventueel voorzoen van toelichting door de docent daar waar dit nodig is. 

Enkele van deze oefeningen dienen ook op het systeem te worden uitgewerkt. Een beperkt aantal 

uitwerkingen wordt ingeleverd, ter beoordeling. 

Verdieping: Dit onderdeel bestaat doorgaans uit extra stof en / of extra oefeningen. De extra stof 

behoort niet tot de tentamenstof. De extra oefeningen kunnen wel nuttig zijn voor het tentamen 

Practicumopdrachten: In afwijking van de voorafgaande JAVA-modulen zijn de taaktoetsen hier 

vervangen door meer integrerende practicumopdrachten, waarin de stof van enkele moduletaken 

tot een geheel is verwerkt. 

Terugkoppeling per moduletaak en toetsing van het geheel 

Zelftoets: Om aan te tonen dat je de oriëntatie en verwerking van de in de taak doorgewerkte stof 

beheerst, wordt de moduletaak afgesloten met een individuele toets. Deze dient zelfstandig 

uitgevoerd te worden en is voorzien van een terugkoppelmogelijkheid door de in een bijlage 

beschikbaar gestelde uitwerking. In deze zelftoetsen is steeds zo direct mogelijk uitgegaan van de 

geformuleerde taakdoelen. 

Eindbeoordeling: Aan het eind van de module wordt een tentamen als theorietoets afgenomen. 

Als je alle moduletaken naar behoren hebt afgewerkt zou je deze toets voldoende moeten kunnen 

scoren. Dit tentamenresultaat, samen met de werkcollegeactiviteiten vormen de theoretische, de 

beoordeling van de practicumopdrachten de praktische waardering voor de module. Zie verder de 

modulebeschrijving op het net. http://www.ict.hen.nl 

INTRODUCTIE 2: Verslaggeving bij de praktikumopdrachten 

Voor deze module hebben de practicumopdrachten een grotere omvang en een integrerend 

karakter. De twee practicumopdrachten zijn onderverdeeld in een aantal voorgeschreven 

activiteiten, teneinde een probleem op te lossen. In hoofdlijn is dit aan te geven met 

• Analyse 

• Ontwerp 

• Implementatie 

Voor het eerste onderdeel wordt een volledige NIAM analyse gemaakt, uiteindelijk 

6

IG9OGO 


resulterend in een IGD. Met een standaard conversie wordt dit analyseresultaat omgezet in een 

statisch ontwerp, weergegeven in een UML Class diagram. Bij opdracht 2 worden de dynamische 

aspecten toegevoegd met het opstellen en uitwerken van use cases uit een UML Use case 

diagram, gespecificeerd in UML Sequence diagrams. Het aldus voltooide ontwerp wordt 

vervolgens geïmplementeerd in JAVA. 

Verslaggeving 

Bij het inleveren van de opdracht wordt een beknopt verslag geëist waarin minimaal het volgende 

moet worden opgenomen: 

Voorblad: met naam, module, opdrachttitel en datum. 

Probleembeschrijving (kort, je eigen verwoording van de opdracht) 

Uitwerking van de opdracht in 

Een volledige NIAM analyse, met als eindresultaat een IGD 

Een volledig ontwerp: class diagram en alleen voor opdracht 2: use case en sequence 

diagrams 

Een volledige implementatie in JAVA 

Evaluatie: tegen welke problemen ben je aangelopen en hoe heb je deze opgelost. 

Conclusie 

Bijlage: Broncode van de Java implementatie 

Let wel, het moet een kort en bondig verslag blijven. 

7

Planning 

Toelichting 

IG9OGO 


De aangegeven planning is een standaard planning voor deze module. Overleg met je eigen 

docent of hij aanpassingen wil aanbrengen. Aanleiding hiervoor kan bijvoorbeeld de verroostering 

van practica en werkcolleges zijn. 

Planning per week 

WEEK MODULETAAK PRAKTIKUM inleveren 

opdracht pract.taak 

Wk1 Mtk1 

Mtk2a 

Ptk1 Ptk1 Analyse 

WK2 Mtk2b 

Ptk1 Ptk1 Ontwerp 

Mtk3a 

Usecases , 

classdiagram 

WK3 Mtk3b Ptk1 Ptk1 

Implementatie 

WK4 Mtk3c 

Ptk2 Ptk1 Verslag 

Mtk4 

Ptk2 Analyse 

WK5 Mtk5 Ptk2 Ptk2 Ontwerp 

Usecases, 

Classdiagram, 

Sequencediags 

WK6 Mtk6 Ptk2 Ptk2 

Implementatie 

WK7 Oud tentamen Ptk2 Ptk2 

Impl. Vervolg 

WK8 Uitloop Ptk2 Ptk2 

Verslag 

8

INTRODUCTIE en TAAKOMSCHRIJVING 

Voorkennis: 

Taakdoel: 

Oriëntatie: 

Verwerking: 

Verdieping: 

Zelftoets: 

IG9OGO 


Moduletaak 1: Correct en robuust programmeren 

Voorkennis P_J2 onderwerp Programming by Contract. 

Student leert als voorbereiding op de eerste practicumopdracht oefenen met andere Collections: 

Bijvoorbeeld : Map. 

Student kent de begrippen: 

Asserties, precondities, postcondities 

Student kan asserties toepassen, als ontwerper van software en als gebruiker van bestaande 

software componenten 

Om kwalitatief hoogwaardige software te ontwerpen en te implementeren is het concept “Design by 

contract” een essentiële leidraad. Betrouwbare software is het einddoel, met als kenmerken: 

correctheid en robuustheid. Het eerste geeft aan dat de software “doet wat deze moet doen, 

volgens de specs” en het tweede dat de software, onder afgesproken voorwaarden, gegarandeerd 

goed functioneert. 

“Design by contract” legt de formele overeenkomst, het contract, vast tussen softwareleverancier 

en software(ontwerper!)-gebruiker, met de rechten en verplichtingen van beide partijen. 

In de practicumsituatie vervult de student beide rollen: immers je maakt zelf in je volledige 

programma gebruik van zelfgeschreven onderdelen. Daarmee ben je tegelijkertijd leverancier en 

gebruiker. 

“Design by contract” is in verschillende vormen te realiseren. De manier waarop het in deze 

module wordt toegepast is door het gebruik van asserties, het checken van pre- en postcondities 

van een methode en eventuele class-invarianten. In sommige programmeertalen zijn asserties een 

standaard onderdeel, in Java niet. Vandaar het gebruik van een “nl.hen.ict” assertieclass definitie. 

Een lightweight variant is het vermelden van de afspraken in de vorm van commentaar: 

voorwaarden, akties of terug te geven waarde en eventueel aanvullend commentaar. In de praktijk 

is dit de meest voorkomende vorm. Echter van gegarandeerde kwaliteit kan dan geen sprake zijn. 

Bestudeer de leestekst Design by contract ,pagina 10 

Bestudeer het uitgewerkte voorbeeld, pagina 15 

In het werkcollege worden in overleg met de begeleidende docent een selectie van de 

oefeningen uitgevoerd. Bestudeer voorafgaand aan Oefening 1.2 ev. de Introduktie voor het 

gebruik van een Map, in de leestekst L5.2.2 van Moduletaak 5. 

De niet geselecteerde oefeningen kunnen als extra oefening worden gemaakt. 

Maak ter afronding van deze module de zelftoets en controleer zelf je uitwerking door deze te 

vergelijking met die in de bijlage van deze modulehandleiding. Herhaal zonodig enkele oefeningen. 

9

LEESTEKST: Design by contract 

Samenvatting 

Correctheid 

Assertie 

IG9OGO 


• design by contract 

• asserties: 

pre- en postcondities 

classinvarianten 

• vooral pre- (en post)condities zijn belangrijk 

• in Java te testen met 

Assertion.require (preconditie, “melding indien niet voldaan ”); 

Assertion.ensure (postconditie, “melding indien niet voldaan”); 

• nut zit in duidelijker ontwerp van software: 

wie is verantwoordelijk voor wat? 

Correctheid van programmatuur 

Principe: 

“Design by contract” 

Basisidee: 

Ontwerper van een class 

• formuleert onder welke voorwaarden een methode (procedure/functie) gebruikt 

mag worden 

(d.m.v. precondities); 

• geeft garanties m.b.t. wat de methode doet 

(d.m.v. postcondities). 

Voorbeeld 

• een lamp mag alleen aangeschakeld worden wanneer hij uit is (preconditie) 

(met als idee dat je hem niet onnodig aanschakelt); 

• na het aanschakelen krijg je ook de garantie dat hij aan is (postconditie). 

Soorten asserties 

per methode: preconditie (require) 

postconditie (ensure) 

voor hele class: classinvariant 

Een assertie 

• is een bewering die altijd waar moet zijn 

(dan is de software correct) 

• wordt als een boolean-expressie geformuleerd. 

Formulering soms lastig: 

• soms alleen uit te voeren met behulp van extra (boolean-)functies; 

• in enkele gevallen onmogelijk: 

in dat geval als commentaar opnemen. 

Pre- en postcondities en class-invarianten zijn asserties. 

Preconditie 

Een preconditie is een assertie waaraan voldaan moet worden voordat een methode 

uitgevoerd mag worden. 

10

Classinvariant 

Nut van asserties 

IG9OGO 


Postconditie 

Assertie die na aanroep van methode geldig is. 

Voorbeeld 

In de class Lamp 

public void doeAan () { 

Assertion.require (! isAan (), “Lamp mag niet aan zijn”);//precond. 

isAan = true; 

Assertion.ensure (isAan (), “Lamp is aan”); //postcond. 

} 

Bij aanroep (in een andere methode/class): 

if (! lampje.isAan()) { 

lampje.doeAan(); 

} 

Indien pre- of postconditie niet waar is wordt boodschap afgedrukt. 

Classinvariant 

Classinvariant specificeert eigenschappen die altijd geldig zijn voor een object beschreven 

door die class. 

Dit zijn afhankelijkheden tussen variabelen en functies van een class. 

Bijvoorbeeld: 

Voor een Persoon zal altijd gelden: 

(leeftijd >= 0) && (leeftijd

Design-by-contract 

IG9OGO 


VOORBEELD ter illustratie: classes Huis en Lamp 

class Huis { 

private Lamp hangLamp; 

// de enige aanwezige lamp in dit huis: 

} 

public void doeLampAan(){ 

// Schakelt de lamp aan. 

if (! hanglamp.isAan()) { 

hangLamp.doeAan (); 

} 

} 

class Lamp { 

private boolean aan; 

} 

public boolean isAan() {// Is de lamp aan? 

return aan; 

} 

public doeAan { // Schakelt de lamp aan. 

Assertion.require (!isAan(), “lamp mag niet aan zijn”); 

aan = true; 

Assertion.ensure (isAan(), “lamp is aan”); 

} 

Design by contract 

• er zijn twee partijen: 

de aanroeper en de aangeroepene 

• elke partij heeft zijn verantwoordelijkheden én verplichtingen 

• wanneer aanroeper zich niet aan de verplichtingen houdt hoeft de aangeroepene ook 

niets te garanderen. 

Software kan dan crashen of in foute toestand doorgaan. 

Terug naar het voorbeeld: 

class Huis maakt gebruik van methode 

doeAan () van class Lamp: 

aanroeper 

(hier: Huis ) 

aangeroepene 

(hier: Lamp) 

Design-by-contract : pre- en postcondities 

recht 

(“voordeel”) 

Kan na aanroep zeker zijn 

dat aan postconditie (isAan) 

is voldaan 

Kan er zeker van zijn 

dat bij aanroep aan 

preconditie is voldaan 

verplichting 

Mag routine alleen aanroepen 

als aan preconditie(isUit) is 

voldaan 

Moet er voor zorgen dat 

aan postconditie voldaan 

wordt 

Preconditie: 

in de class van waaruit de methode wordt aangeroepen moet gecontroleerd worden of dit 

mag; 

Postconditie: 

verplichting voor implementatie van de methode zelf; 

Class-invariant: 

verplichting voor implementatie van alle public methoden aangeroepen class. 

Een bewering die geldig moet zijn bij elk gebruik van een object van de class. 

Waar moet een fout gezocht worden bij overtreding: 

preconditieovertreding: 

12

IG9OGO 


fout van de aanroeper (deze had moeten controleren of de omstandigheden van aanroep 

correct waren); 

postconditie- of classinvariantovertreding: 

fout van implementator van methode cq. class. 

Policy m.b.t. asserties 

Run-time support 

• Asserties zó formuleren dat duidelijk is wat de afspraak (contract) tussen aanroeper en 

aangeroepene is. Dus ook in documentatie van een methode opnemen !! 

• Zo strak mogelijk formuleren. 

class Assertion opnemen in software: 

import nl.hen.ict.assertion.Assertion; 

Tijdens testfase: 

Assertiecontrole is actief. 

Run-time-systeem “kijkt” mee of aan asserties wordt voldaan. 

Tijdens executie: 

Assertiecontrole wordt afgezet, door er commentaar van te maken. 

(Asserties niet verwijderen! (specificatie)) 

Voordelen van werken met asserties en ondersteuning door run-time-systeem: 

• meer inzicht in wat geïmplementeerd moet worden (specificatie van de software) 

• duidelijke scheiding van verantwoordelijkheden 

• fouten gemakkelijker op te sporen: run-time-systeem geeft aan waar de fout zit 

• productie-software bevat geen run-time controle meer; wel op de juiste plaats de 

normale controles 

• asserties blijven in sources als commentaar aanwezig 

• documentatie 

Vergelijk: 

functie van rij-instructeur, zolang geen rijbewijs behaald is. 

Praktisch gebruik van asserties 

Tijdens ontwikkeling van software controle laten uitvoeren op classes die in ontwikkeling zijn. 

(A,B,C) 

Van classes die direct gebruikt worden precondities gecontroleerd (D, E) 

Overige classes kunnen zonder assertiecontrole gebruikt worden. (F, G, H) 

G 

B 

E 

A 

F 

D 

C 

H 

In ontwikkeling: 

alle asserties 

laten controleren 

Direct gebruikt: 

precondities 

laten controleren 

Niet direct gebruikt: 

geen assertiecontrole 

nodig 

13

Hoe “ontdek” ik asserties? 

VALKUILEN 

IG9OGO 


Indien grondig getest en stabiel: 

assertiecontrole omzetten in commentaar 

Invarianten en pre- en postcondities zijn op de volgende manier te vinden: 

vanuit informatieanalyse: als implementatie van constraints; 

door systematisch alle methoden na te lopen en daarover uitspraken te doen. 

Invarianten: 

per variabele nagaan aan welke voorwaarden die moet voldoen; 

idem per functie; 

voor iedere combinatie van variabelen en methods nagaan welk verband ze hebben. 

Precondities: 

per procedure (en functie) nagaan onder welke omstandigheden die procedure (functie) mag 

worden aangeroepen; 

Postconditie: 

afvragen wat het gewenste effect van de methode is 

Bij het leren gebruiken van asserties treden vaak terugkerende problemen op. 

1. Let op dat de berichten Omschrijving moeten zijn van de assertieexpressie zelf: 

Voorbeeld : 

double wortel(double getal){ 

Assertion.require (getal>0,” Getal moet groter dan nul zijn”); 

// Let op: dit bericht verschijnt als niet aan voorwaarde is voldaan !! 

return sqrt(getal); 

} 

2. Asserties zijn niet bedoeld (en niet geschikt) als user input controle 

Voorbeeld van hoe het niet moet: FOUT voorbeeld !!! 

double wortel(double getal){ 

Assertion.require (getal>0,” Getal moet groter dan nul zijn”); 

return sqrt(getal); 

} 

class Appl{ 

public static void main(String[ ] arg ){ 

int invoerGetal; 

Console.readInt(invoerGetal); 

Assertion.require (invoerGetal>0,” Getal moet > 0 zijn”); 

// Voldoet niet als controle. Controle blijft nodig ook na 

// testfase! 

// Volgende controle blijft dan ook onmisbaar en verplicht door 

// contract in sqrt 

if (invoerGetal>=0){ 

System.out.println (wortel(invoerGetal)); 

} 

else 

System.out.println(“Negatief getal ingevoerd !”); 

} 

} 

} 

3. Veronderstel niet dat alle beschikbare packages voldoende getest zijn met asserties 

Bij gebruik van door anderen aangeleverde software is enige voorzichtigheid op zijn plaats. 

Ook al zijn de precondities helder geformuleerd, dat wil nog niet zeggen dat er ook voldoende 

getest is met behulp van asserties. Niet iedere software engineer levert “ingebouwde 

betrouwbaarheid en correctheid door een juiste toepassing van Design by Contract” 

4. In afgeleide classes is in de constructor geen assertiecontrole mogelijk als eerste 

14

IG9OGO 


statement, als er een expliciete aanroep van een superconstructor noodzakelijk is . Java vereist 

dat deze altijd als eerste statement optreedt inde constructor van de afgeleide class. In dat 

geval is het handig om toch een assertiecontrole in commentaarvorm op te nemen, om op die 

manier de preconditie te specificeren. 

class Medewerker extends Persoon 

{ 

public Medewerker(String nwNaam) { 

// Assertion.require( nwNaam != null, “nwNaam mag niet null zijn”) 

super(nwNaam); 

……… 

} 

…….. 

} 

class Persoon 

{ 

private String naam; 

public Persoon(String nwNaam) { 

Assertion.require( nwNaam != null, “nwNaam mag niet null zijn”) 

naam= nwNaam; 

} 

} 

UITGEWERKT VOORBEELD 

Voorbeeldopgave asserties: 

We gaan uit van een class Bank met een Map rekeninghouders en een Map rekeningen. Verder is 

er een class Rekeninghouder en een class Rekening. 

Een rekeninghouder wordt geïdentificeerd door een naam. Verder kan hij/zij een rekening openen, 

geld storten op z’n rekening, geld opnemen van z’n rekening, z’n rekening opheffen, etc. 

Een rekening wordt aangeduid met een rekeningnummer en van een rekening wordt o.a. het saldo 

bijgehouden. 

Vanuit de class Bank worden de diverse administratieve handelingen verricht, zoals het creëren 

van rekeningen, en inschrijven van rekeninghouders, het koppelen van rekeninghouders aan 

rekeningen, etc. 

Hieronder wordt een deel van de classes Bank, Rekeninghouder en Rekening gegeven: 

class Bank { 

... 

private Map rekeninghouders = new HashMap(); 

// key: String; value: Rekeninghouder 

private Map rekeningen = new HashMap(); 

// key: Integer; value: Rekening 

} 

class Rekeninghouder { 

... 

public void open(Rekening deRekening) { 

... 

} 


private Rekening rekening; 

} 

class Rekening { 

... 

private int nummer; 

} 

Schrijf de volgende methoden voor de class Bank: 

15

IG9OGO 


boolean rekeninghouderBestaat(String naam) 

// zoekt uit of een rekeninghouder al bekend is bij de bank 

boolean rekeningBestaat(int nummer) 

// zoekt uit of een rekening al bekend is bij de bank 

Rekeninghouder geefRekeninghouder(String naam) 

// levert de rekeninghouder op met deze naam 

// preconditie: rekeninghouder moet bestaan 

Rekening geefRekening(int nummer) 

// levert de rekening op met dit nummer 

// preconditie: rekening moet bestaan 

void koppel(String naam, int nummer) 

// koppelt een rekening aan een rekeninghouder, indien mogelijk 

Voorbeelduitwerking asserties: 

Uitwerking assertievoorbeeld: 

:::::::::::::: 

Bank.java 

:::::::::::::: 

import java.util.*; 

class Bank { 

private Map rekeninghouders = new HashMap(); 

// key: String; value: Rekeninghouder 

private Map rekeningen = new HashMap(); 

// key: Integer; value: Rekening 

public boolean rekeninghouderBestaat(String naam) { 

return rekeninghouders.containsKey(naam); 

} 

public boolean rekeningBestaat(int nummer) { 

return rekeningen.containsKey(new Integer(nummer)); 

} 

public Rekeninghouder geefRekeninghouder(String naam) { 

return (Rekeninghouder) rekeninghouders.get(naam); 

} 

public Rekening geefRekening(int nummer) { 

return (Rekening) rekeningen.get(new Integer(nummer)); 

} 

public void koppel(String naam, int nummer) { 

if (rekeninghouderBestaat(naam) && rekeningBestaat(nummer)) { 

Rekeninghouder rekh = geefRekeninghouder(naam); 

Rekening rek = geefRekening(nummer); 

if (!rekh.heeftRekening()) 

rekh.open(rek); 

else 

System.out.println(“Rekeninghouder heeft al rekening”); 

} 

else 

System.out.println(“Rekeninghouder en/of rekening onbekend”); 

} 

} 

:::::::::::::: 

Rekening.java 

:::::::::::::: 

class Rekening { 

} 

private int nummer; 

public Rekening(int hetNummer) { 

nummer = hetNummer; 

} 

:::::::::::::: 

Rekeninghouder.java 

16

IG9OGO 


:::::::::::::: 


class Rekeninghouder { 

} 


private Rekening rekening; 

public Rekeninghouder(String deNaam) { 

Assertion.require(deNaam != null, “Naam mag niet null zijn”); 

naam = deNaam; 

Assertion.ensure(naam == deNaam, “naam ingevoerd met deNaam”); 

} 

public void open(Rekening deRekening) { 

Assertion.require(!heeftRekening(),”Heeft nog geen rekening”); 

rekening = deRekening; 

Assertion.ensure(rekening == deRekening,” Rekening is geopend”); 

} 

public boolean heeftRekening() { 

return rekening != null; 

} 

17

OEFENINGEN moduletaak 1 

Oefening 1.1 De bus. 

IG9OGO 


Een bus kan door een stad langs een bepaalde route rijden. De route bestaat uit een aantal 

straten, in sommige straten is een halte. Een buschauffeur moet ervoor zorgen dat de route correct 

gereden wordt. 

Gegeven zijn een aantal public procedures en functies van de class Bus: 

• boolean inStraatMetHalte() // is er een halte in de straat waar de bus nu is? 

• boolean isInGarage() // is de bus in de garage? 

• boolean laatsteHalteIsBereikt() // is de bus bij de laatste halte van de route? 

• boolean inLaatsteStraat() //is de bus in de laatste straat van zijn route? 

• boolean rijdt() // rijdt de bus? 

• void verlaatGarage() // de bus rijdt de garage uit en is in de eerste straat van de route 

• void rijNaarVolgendeStraat() 

• void keerTerugNaarGarage() 

• void stop() // zet de bus stil 

• void handelHalteAf() 

• boolean iemandWilInstappen() 

• boolean iemandWilUitstappen() 

• boolean isLeeg() 

• boolean isVol() 

• void laatPassagierInstappen() 

• void laatPassagierUitstappen() 

• boolean deurIsOpen() 

• void openDeur() 

• void sluitDeur() 

Geef van alle procedures een zo goed mogelijke specificatie met behulp van pre- en postcondities 

en beschrijf de class-invariant. 

Oefening 1.2 Boekenplank. 

Op een boekenplank staan een aantal woordenboeken. Elk van de woordenboeken heeft een 

andere doeltaal (bijvoorbeeld Duits, Frans, Engels, etc.). In de woordenboeken staan Nederlandse 

woorden met daarachter per woord een vertaling naar de betreffende taal. 

Ontwerp een datastructuur voor een systeem dat deze boekenplank representeert. 

Bij het creëren van deze boekenplank wordt onderstaand bestand ingelezen. 

Het eerste getal geeft het aantal woordenboeken weer, verder wordt per woordenboek (aangeduid 

met de betreffende doeltaal) vermeld hoeveel vertaalde woorden er volgen, en vervolgens komen 

deze woorden met hun vertaling. 

5 

Frans 

3 

NB. Voorafgaand aan de oefeningen 1.2, 1.3 en 1.4 dient de introductie voor het 

gebruik van een Map bestudeerd te worden, zoals weergegeven in Moduletaak 

5 Leestekst L5.2.2, met een Mapvoorbeeld voor de Supermarkt. 

hond chien 

kat chat 

paard cheval 

18

IG9OGO 


Engels 

4 

hond dog 

kat cat 

paard horse 

leeuw 

Spaans 

2 

lion 

hond cane 

paard caballo 

Latijn 

2 

hond canus 

paard equus 

Duits 

3 

hond Hund 

kat Katze 

paard Pferd 

Implementeer de constructor(en) van het ontworpen systeem. 

Oefening 1.3 Postorderbedrijf. 

(UITWERKEN OP HET SYSTEEM) 

Een postorderbedrijf heeft een klantenbestand. Klanten worden door hun naam geïdentificeerd. 

Verder is er een magazijn met artikelen waarvan de prijs is vastgelegd. Artikelen worden door een 

artikelnummer geïdentificeerd. 

Een klant kan een artikel telefonisch bestellen door zijn naam en het artikelnummer op te geven. 

Een klant kan, gegeven zijn naam, ook opvragen hoeveel moet worden betaald voor de geplaatste 

bestellingen. 

Ontwerp en implementeer een systeem waarmee je de administratie van het postorderbedrijf kunt 

voeren. Test je systeem door een aantal artikelen te maken en vervolgens enkele klanten te 

creëren, die een aantal bestellingen plaatsen en druk van enkele klanten af wat ze nog moeten 

betalen. Druk ook af hoeveel de totale schuld is van alle klanten samen. 

De classes Klant (deels) en Artikel zijn gegeven (zie /hio/praktikum/i1/OGO/postorder). 

Oefening 1.4 Postzegelclub 

Een clubje postzegelverzamelaars houdt een administratie bij van zijn leden. Van alle leden wordt 

de naam, het adres en de postzegelverzameling bijgehouden. Van postzegels wordt het land van 

herkomst, het jaar van uitgifte, de zegelwaarde en de geschatte handelswaarde geregistreerd. Een 

deel van de classes Club, Lid en Postzegel is gegeven. Implementeer in Java de volgende 

methoden: 

a) public boolean bestaatLidMetNaam(String deNaam) in de class Club; 

Toelichting: bestaat er in de Map leden een lid met de betreffende naam 

b) public Lid geefLidMetNaam(String deNaam) in de class Club; 

Toelichting: zoekt in de Map leden naar het lid met de betreffende naam (Preconditie?!) 

c) public void ruil(Postzegel eenZegel, String gever, String ontvanger) in de class Club; 

Toelichting: zorgt ervoor, dat de genoemde postzegel van de gever naar de ontvanger gaat 

d) public Map zegelsPerLand() in de class Lid; 

Toelichting: levert een Map met per land een Set van zegels dat het lid heeft uit dat land 

class Club { 

private Map leden = new HashMap(); 

// key: String (naam); value: Lid 

public Club() { ...} 

public boolean bestaatLidMetNaam(String deNaam) {...} 

public Lid geefLidMetNaam(String deNaam) {...} 

public void ruil(Postzegel eenZegel, String vanNaam, 

String metNaam) {...} 

... 

} 

19

IG9OGO 

class Lid { 

} 



private String adres; 

private Set postzegelverzameling; 

public Lid(String deNaam, String hetAdres, Set dePostzegels) {...} 

public String getNaam() { 

return naam; 

} 

public Set getVerzameling() { 

return postzegelverzameling; 

} 

public Map zegelsPerLand() {...} 

... 

class Postzegel { 

private String landVanHerkomst; 

private int jaarVanUitgifte; 

private double zegelwaarde; 

private double handelswaarde; 

public Postzegel(String hetLand, int hetJaar, double zWaarde, 

double hWaarde) {...} 

public String getLandVanHerkomst() { 

return landVanHerkomst; 

} 

... 

} 

20

ZELFTOETS moduletaak 1 

IG9OGO 


1. Wat is het doel van het gebruik van asserties? 

2. Wat verstaat men onder Design by Contract? 

3. Leg het verschil uit tussen pre- en postcondities. 

4. Welke rol vervullen asserties in de testfase en in de opleveringsfase? 

5. Welke verantwoordelijkheid heeft de “client” ten aanzien van het gebruik van precondities? 

6. Ligt de volgende uitspraak toe: 

“Asserties zijn niet bedoeld ter vervanging van input controle” 

7. Voeg in onderstaande constructor van Persoon een correct gebruik van asserties toe. 

/* 

persoon registreert gegevens van een patient geidentificeerd door een naam 

tevens wordt de geboortedatum bijgehouden en de huisarts van deze patient 

*/ 

class Persoon{ 

private String naam; //identificatie 

private Arts huisArts; 

private String gebDatum; 

} 

public Persoon(String nwNaam, String nwGebDatum){ 

} 

naam= nwNaam; 

gebDatum= nwGebDatum; 

8. Geef aan hoe op een correcte manier in een hoofdprogramma een Persoon object wordt 

aangemaakt volgens het “contract” van vraag 7. 

9. Onderstaande codefragment uit het uitgewerkte voorbeeld van deze moduletaak wordt op een 

juiste manier “Design by Contract “ toegepast. Licht toe in welke coderegels hiervan sprake is 

en leg uit waarom dit een correct gebruik ervan is. 

public void koppel(String naam, int nummer) { 

if (rekeninghouderBestaat(naam) && rekeningBestaat(nummer)) { 

Rekeninghouder rekh = geefRekeninghouder(naam); 

Rekening rek = geefRekening(nummer); 

if (!rekh.heeftRekening()){ 

rekh.open(rek); 

} 

else { 

System.out.println(“Rekeninghouder heeft al rekening”); 

} 

} 

else { 

System.out.println(“Rekeninghouder en/of rekening onbekend”); 

} 

} 

Controleer tenslotte je uitwerking aan de hand van de uitwerking van deze zelftoets in 

Bijlage B van deze modulehandleiding. 

21

IG9OGO 


Moduletaak 2: Afbeelding NIAM analyse naar ontwerp van classes 


Relevante voorkennis 

Taakdoel 

Oriëntatie 

Verwerking 

Verdieping 

Zelftoets 

Basiskennis Java uit de modulen IG9_PJ1 IG9P_J2 en basiskennis informatieanalyse uit 

IG9_IA1, IG9_IA2 

De student leert een IGD volgens NIAM omzetten naar een statisch ontwerp van samenhangende 

classes: 

hanteert standaard omzettingsregels 

elk object, elke ternair feittype, elke nominalisatie wordt een class 

elke subtypering leidt tot afgeleide classes 

attributen op basis van verplichte feittypen worden meegenomen in de constructor 

hanteert standaard vereenvoudigingen in een specifieke situatie 

geeft resultaten in tekst weer 

In veel methodieken voor object georiënteerd ontwerpen van software wordt de startfase 

overgelaten aan de creativiteit van de ontwerper. Het vinden van een geschikte set van classes die 

kan dienen als model van een systeem is daarmee een wat vage bezigheid, met niet 

noodzakelijkerwijs reproduceerbare resultaten. Enig houvast dat geboden wordt is meestal het 

traceren van zelfstandige naamwoorden in een specificatie van het te bouwen systeem, om 

daarmee de voor het systeem relevante objecten op te sporen. Gevolg hiervan is dat deze 

ontwerpvaardigheid dan vrijwel niet anders te verkrijgen is dan door te leren van kostbare fouten. 

ER ZIJN ANDERE MOGELIJKHEDEN: 

Uitgaande van een NIAM analyse kunnen er voor het omzetten van een analyseresultaat, 

bijvoorbeeld in de vorm van een IGD, naar een kwalitatief goed ontwerp van software een aantal 

regels gehanteerd worden om tot een ontwerp van classes te komen. Dit leidt tot een standaard 

methodiek voor het afbeelden van een NIAM IGD naar een ontwerp van classes. 

De leestekst behandelt de belangrijkste elementen hiervan en geeft voorbeelden. 

Bestudeer de leestekst van deze moduletaak. 

Maak een selectie uit de oefeningen, in overleg met de begeleidende docent. 

Maak de nog niet geselecteerde oefeningen 

Maak de zelftoets en controleer je uitwerking 

22


LEESTEKST: omzetting van NIAM IGD naar ontwerp van classes 

Ontwerpen m.b.v. NIAM 

NIAM en ontwerp 

IG9OGO 

Ontwerpen vanuit NIAM 

• Hoe ontwerp je grote softwaresystemen? 

• zo, dat het systeem onderhoudbaar is 

• en zo, dat je een reproduceerbaar resultaat hebt 

Oplossing: 

• Gebruik NIAM als methode voor data-analyse 

• Pas een aantal vuistregels toe om tot een ontwerp te komen. 

Analyse 

• analyseren is “nadenken over probleem”: 

• beschrijven wat het systeem moet doen 

• maken van keuzes wat het systeem wel/niet moet doen 

• m.b.v. NIAM: beschrijven welke gegevens nodig zijn 

• m.b.v. UML( zie Moduletaak3): beschrijven welke processen uitgevoerd moeten worden 

Ontwerp 

• beschrijven hoe de oplossing eruit ziet 

• maken van keuzes hoe implementatie wordt 

• beschrijving is onafhankelijk van de gekozen taal, 

• maar is wel eenvoudig om te zetten in programmeertaal 

NIAM biedt een uitstekende basis om tot een goed ontwerp te komen. 

Basisregels: 

Ieder objecttype wordt in principe een class. 

• De identificatie van een NIAM-objecttype wordt een attribuut ,vervolgens 

in JAVA een instancevariabele. 

Ieder feittype wordt een attribuut, vervolgens in JAVA weer een instance 

variabele. 

• Een unair feittype wordt een instancevariabele van het type boolean. 

• Een één-op-één of een meer-op-één feittype wordt een enkelvoudige 

instancevariabele. 

• Een één-op-meer of een meer-op-meer feittype wordt een 

instancevariabele van het type “collection van ...” met Set 

eigenschappen. 

Een afleidbaar feittype wordt een operatie , in Java een methode (en wel een 

functie). 

Voor het beheer van dit alles dient altijd een Admin class als UoD class te 

worden toegevoegd met Sets van de hiervoor gevonden objecten 

Een HashSet beantwoordt aan de eisen van een Set 

Herkennen van enkelvoudig of meervoudig type: 

enkelvoudig: aan de kant van het (NIAM)objecttype staat een enkele pijl over de rechthoek, 

meervoudig: aan de kant van het (NIAM)objecttype staat geen pijl of een pijl over meer 

rechthoeken. 

23

Voorbeeld classes 

IG9OGO 

Land 

Diepte 


L S 

De hoofdstad van is 

L S 

is een stad van 

L Z 

grenst aan 

D Z 

heeft gemiddelde meters 

Stel een land, een stad en een zee worden geïdentificeerd door een naam; een diepte door een 

getal in meters. Een zee is een diepzee wanneer de diepte meer dan 2000 m bedraagt. 

Dit leidt tot vier classes: 

Land, Stad, Zee en Diepte 

Variabelen en functies van de classes 

Land 

String naam 

Stad hoofdstad 

Set steden // Stad 

Set aangrenzendeZeeen // Zee 

Stad 

String naam 

Land hoofdstadVan 

Land ligtIn 

Zee 

String naam 

Set omringendeLanden // Land 

Diepte diepte 

boolean isDiepzee // functie 

Diepte 

int aantalMeters 

Set zeeen // Zee nl. alle zeeën met deze diepte 

Class-invariant voor de class Zee: 

isDiepzee == (diepte > 2000) 

Hieruit volgt meteen de implementatie van de functie: 

public boolean isDiepzee( ){ 

return (diepte > 2000); 

} 

Stad 

Zee 

Z 

* 

is een diepzee 

24

Verfijning - schrappen van variabelen 

IG9OGO 


Uit nadere analyse, wanneer de procedures beschreven worden, kan blijken dat bepaalde 

variabelen niet gebruikt worden. 

Deze variabelen kunnen dan geschrapt worden. 

Voorbeeld: 

Bij Diepte zullen de zeeën (met die diepte) niet bijgehouden worden (dit is veel te onhandig; 

waarom?) 

Voorbeeld: 

Bij Diepte worden de zeeën niet bijgehouden. 

Dan blijft over 

Diepte 

Zee 

int aantalMeters 

Nu wordt overal Diepte vervangen worden door int 

... 

int diepte 

Beperkingsregels (constraints) 

Beperkingsregels leiden tot diverse speciale zaken bij een class. 

Uniciteitsregels 

leiden tot een al/niet collection-type-object 

soort collection moet gekozen worden op grond van gewenst gedrag : 

volgorde doet er wel toe: Sequence 

volgorde doet er niet toe: Set 

In moduletaak 5 en 6 wordt hier dieper op ingegaan. 

Verplichtingsregels 

leiden tot een constructorvoorschrift 

(Een collection-object wordt altijd onmiddellijk aangemaakt maar niet gevuld, 

onafhankelijk van een verplichting.) 

Overige beperkingsregels en beperkingsregels m.b.t. verzamelingen in NIAM: 

leiden in het algemeen tot class-invarianten 

leiden soms tot precondities 

Voorbeeld invariant 

Regel voor vereenvoudigingen : 

Wanneer door dit schrappen van variabelen slechts één instancevariabele in 

een class overblijft kan doorgaans de naam van de class overal veranderd 

worden in de naam van het type van die ene instancevariabele. 

Regel voor de constructor: 

In de constructor moeten de volgende variabelen een waarde krijgen: 

de variabelen die de identificatie bepalen 

de variabelen waar een verplichting op staat 

25

Voorbeeld constructor 

IG9OGO 


(Verplichting impliceert deelverzameling!) 

Overzicht 

× 

class Overzicht 

int nummer 

Set artikelen // Artikel 

Set hogeBtwArtikelen // Artikel 

Set lageBtwArtikelen // Artikel 

invariant 

hogeBtwArtikelen.is_subset (artikelen) 

hogeBtwArtikelen.difference(lageBtwArtikelen).isEmpty() 

N.B. Bij Artikel is slechts één variabele overzicht nodig 

(in plaats van drie). 

Bij het eerste voorbeeld: 

Land 

Land (String nwNaam, String nwHoofdstad) 

naam = nwNaam 

hoofdstad = nwHoofdstad 

Zee 

Zee (String nwNaam, int nwDiepte) 

naam = nwNaam 

diepte = nwDiepte 

Bij het vorige voorbeeld: 

Overzicht 

Overzicht (int nwNummer) 

nummer = nwNummer 

artikelen = new Set() 

hogeBtwArtikelen = new Set() 

Overigens is de volgende een functie en geen variabele: 

public Set lageBtwArtikelen ( ) { 

return (artikelen.difference 

(hogeBtwArtikelen)); 

} 

Ontwerpen NIAM - nominalisatie 

O A 

bevat 

172 

172 

O A 

a1 

a2 

op heeft een hoog BTW-tarief 

172 a1 

O A 

op heeft een laag BTW-tarief 

172 a2 

Artikel 

26

IG9OGO 

Voorbeeld: 


class Plaats 

Provincienaam provincie 

Plaatsnaam naam 

Set bedrijven // Bedrijf 

class Bedrijf 

String naam 

Plaats vestigingsplaats 

class Provincienaam 

String naam 

Set plaatsen // Plaats 

class Plaatsnaam 

String naam 

Set plaatsen // Plaats 

Ontwerpen NIAM - n-aire feittypen 

Voorbeeld: 

Regel i.v.m. nominalisatie: 

samengesteld objecttype wordt class 

Regel i.v.m. n-aire feittypen (n >= 3) 

(ternair, quarternair, etc.): 

Feittype behandelen alsof deze genominaliseerd is. 

(Wel een geschikte naam voor het objecttype kiezen!) 

27

Voorbeeld NIAM- n - aire feittypen: 

IG9OGO 


Ternair feittype krijgt de naam Bezoek en leidt tot class Bezoek. 

class Bezoek 

Persoon persoon //identificatie 

Datum datum //identificatie 

Plaats plaats //identificatie 

class Persoon 

String naam 

Set bezoeken // Bezoek 

classes Datum en Plaats: analoog aan Persoon. 

Vereenvoudigen bij omzetting van n-aire feittypen 

In veel gevallen kan ook bij de omzetting van n-aire feittypen een vereenvoudigde werkwijze 

gevolgd worden. In plaats van het creëren van een aparte class hiervoor kan vaak volstaan worden 

met het opnemen van een Map in één of meer van de classes met een key en item van de andere 

betrokken classes. In bovenstaand voorbeeld: In class Persoon een Map bezoeken met key Datum 

en item Plaats. 

De formele aanpak, waarbij in elke class van de betrokken objecten een Map wordt gedefinieerd is 

vaak overbodig. In bovenstaand voorbeeld zou dit betekenen dat er in de class Datum een Map 

bezoeken wordt opgenomen met key Persoon en item Plaats en in de class Plaats een Map 

bezoeken met key Persoon en item Datum. 

De ontwerper dient zelf kritisch te beoordelen wat wel en niet zinvol hiervan is op basis van de 

opdrachtomschrijving. 

Ontwerpen NIAM - over identificatie 

Bij classes afkomstig van genominaliseerde feittypen en 

van classes van n-aire (n>=3) feittypen 

is de identificatie van de objecten expliciet aanwezig: 

Identificatie wordt bepaald door de uniciteitspijl boven het feittype. 

Identificatie in NIAM en creatie van objecten 

De identificerende objecten moeten altijd aanwezig zijn c.q. een waarde hebben. Zoals 

eerder opgemerkt moeten ze dus in de constructor een waarde krijgen. 

TIP : geef in commentaar aan welke instance variabele(n) 

identificerend is (zijn). 

28

IG9OGO 

Voorbeeld , zie bovenstaande IGD : 


Voor Bezoek zijn persoon, datum en plaats identificerend; komen dus in constructor: 

class Bezoek 

... 

public Bezoek (Persoon nwPersoon, Datum 

nwDatum, Plaats nwPlaats) { 

persoon = nwPersoon; 

// etc. 

Samenvatting multipliciteit van types 

In schema wordt de omzetting van multipliciteit van typen in een IGD naar regels voor class 

ontwerp als volgt: 

class B 

A a; 

class B 

Set aas; //A 

Gebruik van het schema: 

Ontwerp en inheritance 

Voorbeeld: 

class A 

B b; 

A B 

A 

B 

A B 

class A 

Set bees; //B 

A B 

• Zoek in de tabel de juiste figuur op. 

• Ga dan naar de buitenkant om bij de classes het juiste type voor de variabele te vinden. 

Regel voor subtypering: 

Nominalisatie van een unair feittype (subtypering) wordt zo mogelijk 

afgebeeld met inheritance: 

er ontstaat een afgeleide class 

A 

B 

A B 

29

IG9OGO 

Persoon 

P 

is directeur 

D.w.z.: “Een directeur is een persoon.” 


P A 

woont op 

Directeur 

D B 

Adres 

is directeur van 

Bedrijf 

class Persoon 

String naam 

Adres adres 

class Directeur extends Persoon 

Bedrijf bedrijf // dat hij/zij leidt 

class Bedrijf 

String naam 

Directeur directeur 

class Adres 

String straatPlaats 

Set bewoners // Persoon 

30


OEFENING 2.1 

OEFENING 2.2 

OEFENING 2.3 

IG9OGO 


Lampenfabrieken hebben lampen in voorraad die getest kunnen zijn. 

Fabriek Lamp 

F L L 

heeft in voorraad is getest 

philips 1 

1 

philips 2 

3 

osram 3 

Leid classes, variabelen, functies en class-invarianten af. 

Beeld het volgende NIAM diagram af op een geschikte class-structuur 

gemeente provincie land 

G P P L 

ligt in ligt in 

aantal 

G A 

heeft inwoners 

P 

* 

A A L 

* 

heeft inwoners heeft inwoners 

Beeld het volgende NIAM diagram af op een geschikte class-structuur 

31

OEFENING 2.4 

OEFENING 2.5 

IG9OGO 


Leid classes, variabelen en class-invarianten af en schrijf de bijbehorende constructoren. 

Rekening Bedrag 

Overzicht 

W U 

heeft 

wedstrijd uitslag 

totoformulier T W U 

op staat voor een voorspeld 

T A 

* 

aantal 

op staan goede voorspellingen 

deelnemer 

T D D A 

* 

is ingevuld door doet keer mee 

* 

D 

heeft gewonnen 

R B 

het saldo van is 

123 100.00 

456 0.00 

789 84.67 

007 385.00 

O R1 R2 B 

bevat een overboeking van van naar 

2171AR 123 456 125.00 

2171AR 456 789 25.95 

4599BS 123 007 87.50 

Transformeer het vorige schema naar een schema met één ternair en twee binaire feittypes met 

exact dezelfde informatie-inhoud. Leidt dan opnieuw classes en variabelen af. 

32

OEFENING 2.6 

IG9OGO 


Leid uit onderstaand NIAM diagram een geschikte OO-class-structuur af. 

naam 

film 

leerling 

met 

N 

is een leerling 

L S 

zit op 

L K 

zit in 

L F 

koos voor 

F K P 

koos op 

F 

heeft gewonnen 

F A 

heeft stemmen 

* 

F N 

heeft 

* 

* 

school 

aantal 

plaats 

klasjaar 

nummer 

klas 

 

K O G 

met en is een klas 

opleiding 

groep 

33

OEFENING 2.7 

IG9OGO 


Leid uit onderstaand NIAM diagram een geschikte OO-class-structuur af. 

artikelcode 

A S D 

bevat van 

met artikel 

stof 

A 

identificeert 

een artikel 

A 

is een nonfood_artikel 

X 

 

food_artikel 

A 

is een food_artikel 

A O 

heeft als 

ex_eeg_artikel 

 

A 

komt van buiten de eeg 

A VP 

heeft 

 

A 

is duur 

A GH 

heeft dagen 

delen_per_miljoen 

gem_houdbaarheid 

oorsprong 

invoerheffing 

A IH 

is onderhevig aan 

duur_artikel 

verkoopprijs 

fabrikant 

A FK 

wordt gemaakt door 

34

OEFENING 2.8 

IG9OGO 


(UITWERKEN OP SYSTEEM) 

Leid classes, variabelen, functies en class-invarianten af. 

P A 

is huisarts van 

Arts 

Persoon 

P 

is arts 

P D 

is geboren op 

A P 

Datum 

Plaats 

heeft gestudeerd in 

Implementeer het systeem en test het met drie personen, waarvan er twee arts zijn. Eén arts is 

huisarts van de persoon die geen arts is en de artsen zijn elkaars huisarts. 

35


IG9OGO 


1. Welke elementen uit een NIAM IGD worden standaard omgezet naar een class bij afbeelding 

naar een ontwerp van classes? 

2. Welke constructor-eisen volgen uit een NIAM IGD bij het ontwerpen van een class? 

3. Wanneer kunnen er in afwijking van de formele afbeelding naar het ontwerp van classes 

vereenvoudigingen worden toegepast? Geef een toelichting. 

4. Zet het volgende NIAM IGD om naar een ontwerp van classes: 

Sitenaam 

Site 

N L 

Land 

[NL, DE, CH] 

In is een site met 

 

hen NL 

Knoop 

Subnet 

S SN M 

in op is een 

netwerkknoop 

hen.NL hio bach 

Message 

K1 K2 T 

Machine 

M U 

Tijdstip 

K S 

heeft het beheer over in 

subnet “hio” 

K S 

heeft het beheer 

over 

is bestemd voor 

bach@hio.hen.nl \ 12 karel 

op is van naar een 

bericht verzonden 

bach@hio.hen.nl 

rome@cs.ibm.de 

12 

M T 

bevat 

bach@hio.hen.nl \ 12 hallo 

is systeembeheerder 

Tekst 

Controleer je uitwerking van de zelftoets aan de hand van Bijlage B van deze 

modulehandleiding. 

User 

* 

Systeembeheerder 

Afgeleid feittype bevat feiten over alle knopen in het subnet “hio” 

U 

36

IG9OGO 


Moduletaak 3: Introductie UML: use cases , class- en sequencediagrams 


Voorkennis 

Taakdoel 

Oriëntatie 



Stof van moduletaken 1 en 2 is afgerond. 

Leren kennen van basisbegrippen en hun notatie in UML : 

Class Diagrams: 

classes 

attribuut en methoden specificatie 

relaties: 

inheritance, associaties en aggregaties 

Use Cases: 

actor, use case en onderlinge relaties 

specificatie use cases volgens sjabloon 

use case realizations 

Sequence Diagrams: 

objecten en messages 

OO ontwerp na omzetting NIAM classes uitbreiden op basis van use cases en met behulp 

van sequence diagrams 

Modellen hebben we leren kennen in de modulen IA1 en IA2 als abstracties die een relevant deel 

van de werkelijkheid van een complex probleem weergeven. Voor het bouwen van software spelen 

deze modellen een wezenlijke rol: voor kleine systemen lijkt dit wel eens overbodig, zolang het 

systeem met niet al te veel regels code te realiseren is. Iedereen zal er mee instemmen dat voor 

grotere en meer complexe systemen modellering een absolute noodzaak is. Het opzetten van een 

model stelt immers de ontwerper in staat zich te beperken tot hoofdlijnen waarbij het grotere 

geheel goed in beeld blijft. Stap voor stap kan er meer detailinformatie aan toegevoegd worden bij 

de transformatie van model naar implementatie. 

Visuele modellen hebben het voordeel dat ze complexere systemen eenvoudiger te begrijpen 

maken en de communicatie vergemakkelijken over de structuur van systemen. Bijkomend voordeel 

is dat het documenteren van een systeem op een meer uniforme en volledige wijze kan 

plaatsvinden. Notatie speelt hierbij een belangrijke rol en is een voorwaarde voor eenduidige 

communicatie. Hierbij kan de Unified Modeling Language (UML) als standaard goede diensten 

bewijzen. Sterk punt hiervan is dat deze standaard mogelijkheden beidt voor het hele traject van 

analyse naar ontwerp. 

Een belangrijke factor is de benodigde tijd voor het analyseren ontwerpen en bouwen van 

software. Time to market is voor bedrijven een op de voorgrond tredend concurrentieaspect. 

Visuele modellen kunnen dan sterk optimaliseren 

Al met al helpen goede modellen voor het beter begrijpen van complexe problemen, bevorderen 

van de communicatie erover, leiden tot een betere documentatie van de probleemanalyse en 

oplossing, en resulteren uiteindelijk in kwalitatief betere ontwerpen en implementaties van 

software. Het zal niemand verbazen dat daarmee de geproduceerde software ook beter te 

onderhouden is. Als tol maken we in deze module gebruik van enkele diagramtechnieken van 

Rational Rose 2000. Use cases, classdiagrams en sequencediagrams zullen we leren gebruiken. 

Lees de LEESTEKST bij deze moduletaak 3: Introductie in UML en Rational Rose 2000 

37

Verwerking 

Verdieping 

Zelftoets 

IG9OGO 


Zoek op het systeem de in de leestekst L3.3 aangegeven pdf file op: 

/hio/praktikum/i1/OGO/Rose_usingrose.pdf ( een gebruikershandleiding voor Rational 

Rose2000) 

Bestudeer hierin in ieder geval Chapter 2 Getting started with Rational Rose 

Verder eventueel Chapter 6, 7 en 9 : Class, Use Case en Interaction Diagrams 

Maak in overleg met de begeleidende docent een selectie uit de oefeningen. 

Een verder verkenning van Rational Rose biedt nog veel mogelijkheden, maar let wel op de 

juiste prioriteit. 

Maak de bij de verwerking nog niet geselecteerde oefeningen 

Maak de zelftoets en controleer je eigen oplossingen aan de hand van de uitwerking. Maak 

zonodig een herhaling van enkele oefeningen en/of bestudeer opnieuw delen van de 

leestekst. 

38


LEESTEKST bij moduletaak 3 : Introductie in UML en Rational Rose2000 

L3.1 Geschiedenis van UML 

IG9OGO 

In de jaren negentig werden er verschillende methodieken voor de ondersteuning van 

softwareontwikkeling met hun eigen set van notaties op de markt gebracht. De 3 populairste: OMT 

van Rumbaugh, Booch van Booch en OOSE van Jacobson. Elke methode met zijn specifieke 

sterke en zwakke punten: 

• OMT (Object Modeling Technique) werd bij General Electric ontwikkeld, geïnitieerd door James 

Rumbaugh. Deze methode had zijn kracht in de procesbeschrijving voor testen op basis van 

een specificatie van de gestelde eisen. Een aantal modellen beschrijven hierin samen het 

systeem: objectmodel, dynamisch model, het functionele en het use-case-model. Daardoor 

was deze methode sterk in analyse en minder sterk in ontwerp 

• Booch heeft het idee gelanceerd om een systeem als een aantal “views” te analyseren. Voor 

elke view is een reeks modeldiagrammen beschikbaar. De methoden kende een uitgebreide 

reeks van symbolen. De “clouds” waren voor sommige ontwerpers een continue worsteling met 

hun creatieve talenten. 

• OOSE en Objectory stoelen op de visie van Jacobson op object georiënteerde software 

ontwikkeling Deze waren sterk in analyseren van gedrag van een systeem, minder sterk in de 

overige gebieden. Beide benaderingen zijn gebaseerd op use cases waarin de vereisten van 

een systeem vanuit het gezichtspunt van een gebruiker van het systeem worden gedefinieerd. 

Met het uitkomen van nieuwe versie van deze methoden bleek er een sterke convergentie plaats te 

vinden, terwijl de notaties bleven verschillen. Voor Booch werd een class aangegeven met een 

wolksymbool, de beruchte clouds, voor de andere door middel van een rechthoek. Deze verschillen 

leiden gemakkelijk tot verwarring. Deze starre handhaving van verschillen in notaties staat bekend 

als “ method wars”. 

In 1994 begonnen Booch en Rumbaugh toen beiden werkzaam bij Rational Software Corporation 

aan UML te werken. Hun doel was het ontwikkelen van een nieuwe methode “Unified Method”, die 

de methoden van Booch en OMT moest samenvoegen. Het jaar daarna voegde ook Jacobson zich 

bij dit team. Rational had Objective Systems, de ontwikkelaar van Objectory aangekocht. 

Het besef groeide dat in de eerste plaats een standaard modelleertaal in ontwikkeling was vandaar 

de naamswijziging in “Unified Modeling Language”, een veel eenvoudiger doelstelling dan het 

ontwerpen van een nieuwe methode voor een proces. 

In januari 1997 werd een definitieve versie 1.0 uitgebracht van UML. Deze is door de Object 

Management Group (OMG) als een formele standaardisatie aangenomen in juli 1997 . 

Onderstaand plaatje vat de historische ontwikkeling van UML samen en geeft de geplande revisies 

weer. 

39

IG9OGO 


Met nadruk wordt erop gewezen dat een modelleertaal iets anders is dan een ontwikkelmethode. 

Het voornaamste verschil zit hem in het feit dat een modelleertaal niet beschikt over een proces of 

een set van instructies voor het wat, hoe, wanneer en waarom van ontwikkelstappen. Rational 

heeft als methode RUP, Rational Unified Process. In de documentatie van Rational Rose2000 is 

hier meer over te vinden, met name de verschillende stappen die gevolgd kunnen worden in het 

software-ontwikkelproces, met bijbehorende tools en diagramtechnieken. 

L3.2 Overzicht van UML 

L3.2.1 Views 

2001 

(planned major revision) 

Q3 2000 

(planned minor revision) 

Q3 1999 

Q2 1998 

Q3 1997 

(OMG Adopted 

Technology) 

 

UML 1.2 

 

UML 1.1 

 

UML 1.4 

 

UML 1.3 

 

 

UML 2.0 

 

 

 

 

 

Other relevant 

standards TBA 

ISO Publicly 

Available 

Specifications 

(PAS) 

Editorial revision 

with no significant 

technical changes. 

UML is erg breed georiënteerd en zowel bruikbaar voor het ontwerpen van bedrijfsmodellen als 

voor het ontwerpen van complexe systemen, met als speciaal toepassingsgebied real-time 

systemen. Omdat het wenselijk is de basisversie van UML klein te houden, biedt deze niet 

voldoende mogelijkheden voor het bestrijken van al deze domeinen. Vandaar dat de basis versie 

open-ended ontworpen is, zodat er uitbreidingen op de taal toegevoegd kunnen worden. De 

gelaagde architectuur van UML bestaande uit een basisversie met uitbreidingen, ziet er als volgt 

uit: 

UML kent verschillende invalshoeken om een model weer te geven. Elke view is een abstractie die 

bestaat uit verschillende diagrammen. Er is enige variatie in benadering vanuit UML, RUP of 

Rational Rose. 

De volgende views worden gehanteerd: Use-case view, Logical view, Component view, 

Deployment view en Process view 

De Use Case view is bewust centraal geplaatst in onderstaande figuur : de methode wordt 

40

IG9OGO 

dan ook wel “use case driven” genoemd. 


In de Rational Rose2000 browser zijn de eerste 4 direct terug te vinden: 

In de Use-case view wordt de functionaliteit van het systeem weergegeven zoals deze door de 

externe gebruikers (actors) wordt waargenomen. 

In de Logical view wordt benadrukt hoe de functionaliteit binnen het systeem is ontworpen, zowel in 

een statische structuur als wat het dynamische aspect betreft. 

In de Component view is de organisatie van de codecomponenten aan de orde: hoe zijn de 

verschillende onderdelen gegroepeerd. 

De Deployment view is een weergave van de afbeelding van de softwarecomponenten op de 

hardware van het al of niet-gedistribueerde systeem 

De Process view omvat de processen en threads die het concurrency en synchronisatiemechanisme 

van het systeem bepalen. Deze afbeelding is in Rose2000 voor een groot deel terug 

te vinden in de Component View met een restant in de Logical view. 

L3.2.2 Diagrammen. 

Logical view 

Deployment 

view 

Use 

Case 

view 

Component 

view 

Process view 

In het voorgaande is al opgemerkt dat elke view een aantal diagrammen kent voor de weergave 

van het model. Een ontwerpdiagram zal dus altijd aan een view worden toegekend en wordt in de 

browser weergegeven conform deze hierarchische structuur. 

41

IG9OGO 


Diagrammen zijn weer te groeperen in structuur en gedrag diagrammen (structure/ behavior) 

Structure : class , collaboration, component, deployment. 

Behavior: Use case, State en Sequence diagram 

Een korte beschrijving van de basis concepten van de diagrammen, met voorbeelden, zonder 

gebruiksdetails(zie L3.3 en volgende.): 

Use casediagram 

In het use case diagram kan een overzicht gegeven worden van de functionaliteit van het systeem 

voor een externe gebruiker. In het volgende voorbeeld van een systeem voor een garage zijn in het 

diagram een aantal use cases te onderscheiden , elk aangeduid met een ovaal. Bij elke use case 

kan één of meer actoren betrokken zijn en omgekeerd. Een actor wordt aangegeven met het 

persoonsymbool omdat eindgebruikers van het systeem meestal personen zijn. Overigens kan een 

actor ook best een extern systeem zijn dat gebruik maakt van resultaten van het beschouwde 

systeem. 

Deze Use cases worden doorgaans van een documentatie voorzien in de vorm van een 

usecasespecification waarin de basic en alternate flow of events worden aangegeven, een 

beschrijving van de akties die samen het gewenste resultaat van de use case leveren. Iedere flow 

of events wordt vervolgens uitgewerkt in de usecase realization in een sequence diagram, waarin 

de samenwerking tussen de verschillende objecten in het systeem wordt uitgebeeld. 

Het eerste document heeft dus een gebruikers- , het tweede een ontwikkelaarsperspectief. 

42

IG9OGO 


Classdiagram 

Een klasse diagram toont de statische structuur van klassen en hun onderlinge samenhang 

In het systeem. De samenhang tussen de klassen kan weergegeven worden met associaties, 

aggregaties of generalisaties / specialisaties. Met generalisaties / specialisaties kan inheritance in 

beeld worden gebracht. Aanvullend kan ook nog gebruik gemaakt worden van dependency 

relationships. Naast deze onderlinge samenhang kan ook per klasse de interne structuur worden 

weergegeven met in UML terminologie attributen en operaties, overeenkomend met de java 

begrippen Instance variables en methods. De toegangsspecificaties zijn met symbolen per attribuut 

en methode weergegeven. 

In verschillende stadia van het ontwerpproces kan men kiezen welke details worden weergegeven 

en welke niet. Aanvankelijk zal vanuit een NIAM analyse alleen een specificatie van instance 

variables en constructoren plaatsvinden, later na uitwerking van de use cases in sequence 

diagrams kunnen de overige methoden worden toegevoegd. 

Objectdiagram 

Een objectdiagram is een uitwerking van een class diagram, op basis van vrijwel identieke 

symbolen. In feite een momentopname van de uitvoering van het systeem. 

Alleen de naamgeving in de kop van een objectrechthoek wijkt af van die in een klasse 

rechthoek: een objectnaam wordt onderstreept en wordt na een dubbele punt gevolgd door de 

klassenaam. Objectdiagrams kunnen als nadere toelichting dienen van een class diagram. 

Bovendien komen objectdiagrams terug in sequence diagrams of de ermee verwante collaboration 

diagrams. 

Statediagram (nieuwe benaming: state chartdiagram) 

Van elke class kan een state diagram worden gespecificeerd. Hierin worden de toestanden 

aangegeven waarin een object van een bepaalde klasse zich kan bevinden. Tevens 

43

IG9OGO 


worden de gebeurtenissen (“events”) vastgelegd die aanleiding zijn voor de overgang naar een 

andere toestand, ook wel een state transition genoemd. Aan deze overgangen kunnen nog 

speciale acties worden verbonden. Voor real time systemen spelen deze state diagrams een 

essentiële rol. In deze module blijven deze verder buiten beschouwing. 

Sequence diagram 

Een sequence diagram toont dynamische aspecten van een systeem. Deze kunnen gebruikt 

worden voor het uitwerken van een bij een use case geformuleerde flow of events. Het geeft een 

beeld van hoe de communicatie tussen de verschillende objecten in het systeem verloopt. De 

messages worden getoond in volgorde van verzenden. Verticaal is een tijdas weergegeven zonder 

schaal. 

Vanwege de koppeling aan een use case is dit element in de browser van Rational Rose2000 

ondergebracht als onderdeel van de betreffende use case realization in de Logical View hierarchy 

Collaborationdiagram 

Het collaborationdiagram is een alternatief voor een sequencediagram. Deze diagrammen kunnen 

44

IG9OGO 


1 op 1 op elkaar worden afgebeeld. Het sequence diagram legt de nadruk op de tijdvolgorde, het 

collaborationdiagram meer op de onderlinge samenhang van objecten. 

Activitydiagram 

Voor het specificeren van use cases kan ook gebruik gemaakt worden van activity diagrams. 

Bovendien is dit diagram bruikbaar voor het weergeven van de opbouw binnen methoden van een 

class. In deze module zullen we daar geen gebruik van maken. 

Component View en Deployment View 

Deze views kennen geen aparte diagrammen: de views zelf vormen de diagrammen. In ontwerpen 

voor real-time applicaties spelen beide een belangrijke rol: ze bepalen de afbeelding van het 

systeem op een target en leggen tevens de randvoorwaarden voor code generatie vast. Hiervoor 

verwijzen we naar een vervolgmodule Real-time Objectgeorienteerd Ontwerpen. 

L3.2.3 Bouwstenen 

Nog een stap verder in de detaillering van een model worden de elementaire bouwstenen 

gevonden. De modellen die in UML diagrammen worden voorgesteld kunnen opgebouwd worden 

uit verschillende groepen bouwstenen: 

• Structurele bouwstenen: 

De structuur van een systeem legt de objecten vast die gemodelleerd worden. De primaire 

relaties tussen deze elementen bestaan uit communicatie en bevattingsrelaties. Ze bestaan 

uit de volgende elementen: (NB Realtime specializations: vooruitlopend op module RTOGO) 

UML Base classes, interfaces , use cases, components, 

nodes 

Real-time 

Capsules 

specializations 

• Bouwstenen die systeemgedrag beschrijven 

Deze elementen geven het dynamische deel van een model aan, waarin de veranderingen 

van de toestanden van een systeem in de tijd aan bod komen 

UML Base State machines, interactions 

Real-time 

specializations 

Protocols 

• Groeperende elementen 

Deze elementen helpen een model overzichtelijk te houden. Er is maar een element voor: 

packages 

• Bouwstenen voor toelichtingen 

Opmerkingen, toelichtingen of beschrijvingen kunnen met notes aangegeven worden. 

L3.3 Gebruik van Classdiagrams , Use Casediagrams en Sequencediagrams 

/hio/praktikum/i1/OGO/Rose_usingrose.pdf is een gebruikershandleiding voor Rational Rose2000 

L3.3.1 Gebruik van Classdiagrams 

Is eenmaal de afbeelding gemaakt van een NIAM analyse naar samenhangende classes, 

voorlopig in tekst weergegeven, dan is de stap naar een grafische weergave van dit model 

opgebouwd uit classes met onderlinge relaties niet zo groot. In Rose2000 is daarvoor het class 

diagram beschikbaar. Basiselement hierin is vanzelfsprekend de 

weergave van een class. 

Een class wordt weergegeven als een rechthoek met enkele 

compartimenten. 

Van boven naar beneden: 

45

IG9OGO 


Een compartiment voor de naam van de class, met eventueel een extra aanduiding voor een 

stereotype, bijvoorbeeld voor een abstract class. Daaronder een vak voor attributen 

(in Java: instance variabelen). Tenslotte is er een vak voor operaties (in Java: methoden), inclusief 

de constructor(en). 

De specificatie van attributen 

en operaties kan vanuit de 

browser gebeuren met het 

“new” menu item of vanuit 

een “Open specification” 

menuitem van het pop-up 

menu in het class diagram 

zelf. 

De specificatie kent 

verschillende tabbladen die vrij 

sterk voor zich spreken. 

Invoegen van een nieuw 

attribuut of nieuwe operatie 

gebeurt met “insert” pop-up 

menu item in het betreffende 

tabblad. 

Na invoeging van een attribuut 

of operatie kan deze weer 

verder gedetailleerd worden 

via het eigen “specification” 

dialoogvenster ervan. 

Voor relaties tussen classes zijn verschillende symbolen beschikbaar: symbool voor generalisatie, 

voor associatie en aggregatie en tenslotte 

voor afhankelijkheid. Daarnaast is er nog 

een mogelijkheid om afhankelijkheden 

voor te stellen. 

Het is van belang de eerste vier goed te 

onderscheiden: 

In nevenstaande afbeelding van een 

toolbox zoals deze in enigszins 

aangepaste vorm aanwezig is voor class 

diagrams zijn de verschillen nog eens op 

een rij gezet door toelichtingen per 

symbool. 

Overigens zijn de toolboxes bij de 

verschillende diagrammen aan te passen 

met de opdracht “customize” uit het popup 

menu, bij indrukken van de rechter 

muisknop, vandaar de aangepaste vorm. 

46

IG9OGO 


Onderstaande tabel geeft nog eens het verschil tussen aggregaties en associaties aan: 

Kan éénzijdig of tweezijdig karakter hebben, wel/niet beheerd door de Klasse zelf. 

associatie 

aggregatie 

in één richting In beide richtingen 

associatie in één richting 

aggregatie in één richting 

associatie in beide richtingen 

aggregatie met terugverwijzing 

TOELICHTING: 

1. Bij de eenzijdige relaties: A heeft attribuut van B (of attribuut van set van B's) 

Associatie: A kent een attribuut van type B maar beheert dit niet. 

Bij verdwijnen van A , kan B blijven bestaan 

Aggregatie: A beheert een attribuut van type B, of : B is onderdeel van A 

Bij verdwijnen van A verdwijnt ook B 

NB " wybertje" aan de kant van de beheerder !! 

2. Tweezijdige relaties A heeft attribuut van type B , maar ook B heeft 

attribuut van Type A 

Relaties tussen classes kunnen in Rose2000 ingevoerd worden door het selecteren van een 

associatie of aggregatie in de toolbox van het diagram. Vervolgens kan vanaf ClassA naar ClassB 

getrokken worden met de muiscursor. Hetzelfde geldt voor het 

aangeven van inheritance met een generalisatiesymbool. 

Intermezzo (verdieping) : 

Aangezien bij deze module de implementatie van het ontworpen 

systeem in Java wordt uitgevoerd, kan composition als 

verwantschap tussen objecten buiten beschouwing blijven. 

Composition is een bijzondere vorm van aggregatie, waarbij de 

ene class binnen de andere bestaat. Voor een composition moet 

de “containment by value” gekozen worden in plaats van 

“containment by reference” 

In Java worden objecten altijd “by reference” opgenomen in een 

class, waardoor alleen een (normale) aggregatie voorkomt. 

In C++ hoeft dat niet het geval te zijn. 

Specificatie van relaties, aggregatie- en associatiedetails 

Zoals gebruikelijk in Rose2000 kunnen specificaties langs verschillende wegen worden 

opgegeven. Allereerst via de Browser door in de Logical View de te specificeren associatie aan te 

klikken en vervolgens “Open specification” te selecteren in het bijbehorende pop-up menu. De 

andere weg is weer vanuit het class diagram, aanklikken van het symbool voor associatie of 

aggregatie, etc. 

De volgende gegevens kunnen worden ingevoerd: 

• Naam voor de relatie zelf 

• Navigabiliteit: 

een open pijl geeft hierbij de richting aan waarin men van een class naar een target 

class kan gaan. Bij ontbreken van de open pijl kennen beide objecten elkaar en is 

verkeer in beide richtingen mogelijk ( Zie ook tabel op deze pagina) 

• Naam voor de rol of rollen bij een bidirectionele relatie: rol A is van en rol B is 

• Multipliciteiten 

47

IG9OGO 


aantal instanties dat betrokken is bij de associatie met aanduidingen : 

n voor precies n , 

* voor nul of meer 

n .. m voor minstens n, hoogstens m 

m.. * voor minstens m 

Ter illustratie een voorbeeld: 

Bij een order hoort één klant, een klant heeft 0 of meer orders geplaatst. Een klant kent 1 of meer 

afleveradressen, en precies één factuuradres. 

L3.3.2 Gebruik van Use Case Diagram 

Use cases algemeen 

Voor de implementatie onafhankelijke beschrijving van de functionaliteit van een systeem zijn use 

cases een geschikt hulpmiddel. Dit hulpmiddel beoogt meer: het geeft tevens de grens van het 

systeem aan: wat wordt afgehandeld binnen en wat wordt afgehandeld buiten het systeem. 

In UML zijn 3 elementen als bouwstenen van use case diagrams aan te geven: 

actors, personen of systemen in interactie met het te 

ontwikkelen systeem. 

een use cases, in een ellipssymbool, 

elk een verzameling van door het systeem uitgevoerde 

akties die voor één actor een zichtbaar resultaat van waarden 

opleveren de relaties ertussen, 

associatierelaties tussen een use case en 

een actor, 

In wat ingewikkelder gevallen komen en ( ook wel aangeduid met 

) generalisatierelaties tussen use cases onderling ook nog voor, overeenkomend 

met overerving van classes. 

48

IG9OGO 


In onderstaand voorbeeld zijn deze “advanced elements” weergegeven: 

De generalisatie aangeduid met de stereotype geeft aan dat de usecase is op gebouwd 

met behulp van een basis usecase die in meerdere usecases kan voorkomen. Een extends 

generalisatie geeft doorgaans aan dat de derived usecase als een exceptional flow of events 

optreedt binnen de “base” usecase. 

Een volledig uitgewerkt voorbeeld is verderop in deze moduletaak te vinden. 

Een use case zoeken. 

Om actors te vinden kan men zich de volgende vragen stellen: 

• Welke gebruikersgroep heeft ondersteuning van het systeem nodig om hun taak uit te 

kunnen voeren? 

• Welke gebruikers zijn nodig om de meest voor de hand liggende hoofdtaken van het 

systeem uit te voeren? 

• Welke gebruikers zijn nodig om secundaire taken van het systeem uit te kunnen voeren: 

zoals systeem opstart en onderhoud, bijvoorbeeld door invoer van nieuwe gegevens. 

• Zal het systeem interactie vertonen met andere hardware of softwaresystemen? 

Dit betekent dat gestart kan worden met eerst te kijken welke personen gebruik zullen maken van 

het systeem, en dat vervolgens nagegaan moet worden in welke rol een persoon gebruik maakt 

van het systeem. Doorgaans is de rol een goede naam voor de actor. Vervolgens kan nog bekeken 

worden welke gegevensuitwisseling met andere systemen nodig is of plaatsvindt. 

Voor het vinden van de use cases gelden soortgelijke vragen, te stellen per gevonden actor: 

• Wat zijn de primaire taken die de actor van het systeem wil gebruiken? 

• Zal de actor gegevens creeren, opslaan, veranderen, verwijderen of lezen in het 

systeem? 

• Moet de actor het systeem informatie geven over bepaalde gebeurtenissen buiten het 

systeem? 

• Zal de actor een systeemstart of -afsluiting uitvoeren? 

Als derde stap kan gekeken worden welke actor of actoren betrokken zijn bij welke use cases. Eén 

actor kan bij meerdere use cases betrokken zijn en omgekeerd kan ook . 

In veel gevallen zijn de use cases knoppen of andere keuze elementen in een grafisch user 

interface behorend bij het systeem. 

Beschrijving van use cases 

1. Korte beschrijving 

Documentatie van een use case kan in eerste instantie gewoon in tekst plaatsvinden. Het is een 

simpele specificatie van de interactie van gebruiker en systeem. De bewoording kan dan ook in de 

terminologie van de eindgebruiker. Deze documentatie zal bij selectie van de use case in het 

usecasediagram of in de browser in het documentationwindow verschijnen. 

De beschrijving dient de volgende punten te omvatten: 

• Korte weergave van het doel van de use case 

49

IG9OGO 


• Door wie en in welke situatie wordt de use case opgestart 

• Wat doet het systeem, nog niet hoe realiseert het systeem deze use case 

Onderstaande figuur geeft een voorbeeld van een usecase documentatie in een model met een 

usecase Register for Courses: 

De invoer hiervan kan in Rose op twee manieren plaatsvinden: 

a. via het documentation window bij een geselecteerde use case. ( Openen van Documentation 

Window via menu : View – Documentation ) 

b. via de Open specification optie in het pop-up menu van een geselecteerde use case, bij 

klikken rechter muisknop. Onder de tab General is ook een documentation TextField 

2. Usecase specification 

Een uitvoeriger omschrijving maken we met behulp van het usecase specification document. In 

bovenstaande figuur is een verwijzing hiernaar te vinden in de browser onder elke use case. 

Uitgewerkt in de figuur voor de Register for Courses usecase middels RegisterForCourses.doc. 

Use case specification sjabloon 

In een use case specification worden de volgende aspecten per use case vastgelegd: 

Basic flow of events ( ook wel : main flow of events) 

Deze specificatie omschrijft de acties die in de UC ondernomen interactief tussen 

gebruiker en systeem als een “HAPPY PATH” ,dwz. met een gewenste afloop. Op 

bepaalde voorwaarden kan er vanaf een zekere stap in deze flow een alternatief traject 

doorlopen worden. Dit wordt aangegeven als een Alternative flow. 

Exceptional flow of events. 

Als er een fout optreedt en de usecase daardoor niet verder normaal afgehandeld kan 

worden kunnen hiermee de afsluitende actie(s) omschreven worden. 

Precondition 

Een aanduiding van de voorwaarden waaronder deze usecase gestart kan worden. 

Postcondition 

Omschrijving van de gevolgen van het uitvoeren van de usecase in de toestand van het 

systeem: meestal een aanduiding wat er veranderd is in een aantal variabelen. 

50

IG9OGO 


De overige onderdelen spreken waarschijnlijk voor zich. In de oorspronkelijke sjabloon kan altijd een 

toelichting worden geraadpleegd bij de overeenkomstige onderdelen. 

Zie /hio/praktikum/i1/OGO/rup_ucspec.dot of .htm 

Model 

USECASE # 

Revision history 

Date Version Description Author 

 

 

Brief description < korte omschrijving van het doel van de UC> 

Main flow of events Step Action 

1 

2 

3 

< ….> 

Alternative flow Step condition: Branching Action 

1.2a : 

Preconditions 

Postconditions 

Extension points 

Voorwaarden waaronder de usecase uitgevoerd mag worden 

1 

2 < ……> 

Flow nr Result 

Main Flow 1 < resultaat : wat is er na 

(Success End) 

afloop veranderd in 

systeem> 

Altern. 1.2a 

2 < id . pt 2> 

Step Errorcondition Use case 

1.3 < welke fout> 

Bovenstaande tabel is een alternatieve specificatie van een usecase conform het RUP sjabloon 

ucsp.dot , maar weergegeven in een tabelvorm. In de directory /hio/praktikum/i1/OGO is deze te 

vinden als UCsptabel.doc. 

Use cases realiseren 

In de realisatie van een use case wordt een volgende stap gezet in de systeemontwikkeling: van 

analyse naar ontwerp. De realisatie wordt weergegeven in diagrammen van samenwerkende 

objecten. Daarvoor biedt UML een tweetal interaktiediagrammen: collaborationdiagram en 

sequencediagram kunnen één op één op elkaar worden afgebeeld. Een sequence diagram 

benadrukt het verloop van het berichtenverkeer tussen de in het systeem aanwezige objecten in de 

loop van de tijd, terwijl een objectdiagram meer de nadruk legt op het totaalbeeld van het 

berichtenverkeer tussen de diverse objecten, terwijl het tijdvolgordeaspect meer 

verborgen zit, in de vorm van een berichtennummering. 

51

IG9OGO 


In deze module worden de use cases uitgewerkt binnen Use Case Realizations in 

sequencediagrams. Het opbouwen van een sequencediagram wordt gedetailleerder behandeld in 

L3.3.3. 

Met de menu keuze vanuit een geopend en actief sequence diagram: Browse – Create 

Collaboration Diagram (F5) kan desgewenst een collaboration diagram gegenereerd worden. Na 

enige lay-outaanpassingen ontstaat meestal een bruikbaar geheel. 

Deze sequencediagrams worden geplaatst in de Logical View onder de package Designmodel in 

een subpackage UseCase Realizations met voor elke Usecase een aparte subpackage, met daarin 

een sequencediagram per flow of events. Tenslotte kan onder Designmodel nog een 

traceabilityoverzicht worden opgenomen waarin de koppeling van UC en UC realization wordt 

gevisualiseerd. Onderstaande weergave van een deel van de browser illustreert een en ander. 

L3.3.3 Gebruik van Sequence Diagram 

Per Use Case kan voor elke flow of events een Sequence Diagram aangemaakt worden in de 

overeenkomstige realizationpackage. 

Er bestaat een naming convention voor deze sequence diagrams van de usecase realizations 

in de volgende vorm: 

Naming conventions : - 

Voorbeeld: Dispense Money - Basic flow 

Flow types : basic (main) , alternate or exceptional 

In Rose is het creeren van een nieuw sequence diagram het handigst uit te voeren met menu 

keuze Browse – InteractionDiagram. Selecteer vervolgens : en kies in het volgende 

dialoogkader Diagram Type: Sequence. 

Dit kan ook rechtstreeks vanuit de browser: Selecteer de gewenste use case realization en gebruik 

het pop-up menu item New – Sequence Diagram. 

52

IG9OGO 

In de volgende figuur is dit weergegeven: 


Vervolgens kunnen in dit nieuwe Sequence Diagram objecten geplaatst worden door classes te 

slepen vanuit de Browser. Deze classes zijn ontstaan uit een eerdere afbeelding van een NIAM 

IGD naar een ontwerp van classes. Deze classes zijn eerder als onderdeel in het Design Model 

package onder de Logical View ingevoerd. Vanuit de Use case View kan vooraf een Actor gesleept 

worden die de use case in gang zet. De weergave van de objecten in het Sequence diagram is 

met een rechthoek met daaronder een gestippelde lijn: de levenslijn van het object. 

De objectaanduiding kan op 3 manieren plaatsvinden: 

• alleen met de naam van het object zelf 

• met de naam van het object, een : en vervolgens de naam van de class 

• bij afwezigheid van een objectnaam, alleen een dubbele punt gevolgd door de naam van 

de class 

Kenmerkend is dat objectnamen onderstreept worden. 

jan jan : Docent : Docent 

Nu is het mogelijk de interactie tussen de verschillende objecten in tijdsvolgorde weer te geven 

door de achtereenvolgende berichten in het verkeer tussen de objecten uit te beelden. 

Dit gebeurt door in de toolbar (zie volgende pagina) een messagesymbool te selecteren en dit te 

plaatsen door te trekken van de levenslijn van het zendende object naar de levenslijn van het 

ontvangende object 

53

IG9OGO 


De berichten tussen de objecten worden met pijlen aangegeven, met als specificatie de 

methodenaam en eventueel een nummering om de volgorde, inclusief 

eventuele onderlinge afhankelijkheid met behulp van subnummering, nog 

eens extra te benadrukken. De nummering kan ingeschakeld worden met 

menu Tools – Options item, tab Diagram , Display Section: Sequence 

Numbering. 

Bij het invoeren van de berichten moeten deze na plaatsing 

gespecificeerd worden. De rechtermuisknopklik levert hiervoor het 

gewenste pop-up menu 

Hieirn kan gebruik gemaakt worden van bestaande operations (methods) of kunnen nieuwe 

operations ( methods) worden gedefinieerd voor bestaande classes. 

Een object kan ook een bericht naar zichzelf versturen: een reflexive message, aangegeven met 

een terugkerende pijl symbool. Het object maakt dan gebruik van een eigen method. 

NB. Verwijderen van nieuw aangebrachte berichten of objecten moet via een menuselectie 

en kan niet met de standaard delete uit een pop-up item. De selectie is: Edit – Delete from 

model. 

Ook actoren kunnen in het sequence diagram worden opgenomen: zij zullen immers vaak de 

initiator van het uitvoeren van een usecase zijn. In onderstaand voorbeeld uit de UML tutorial van 

Rose is dit aangegeven. 

Het eerder geintroduceerde begrip scenario als een globale beschrijving van een use case in de 

terminologie van een eindgebruiker, ontmoet hier een tweede betekenis. Ook de uitwerking van 

een use case instantie, namelijk voor een bepaalde flow of events, in een 

sequencediagram wordt wel als scenario voorgesteld . 

54

IG9OGO 


NB In bovenstaand voorbeeld zijn de “balkjes” , de aanduidingen voor het aktief zijn van een 

methode op een deel van de levenslijn van een object , in Rose terminologie benoemd als focus 

of control niet weergegeven. Deze optie kan worden weergegeven met de menukeuze Tools- 

Options- tab Diagram- area Display- field Focus of control . In ditzelfde Display area van de tab 

Diagram kan ook de weergave van Hierarchical Messages worden aan- of uitgezet. Onderstaande 

figuur illustreert de weergave van een bericht binnen een ander aktief bericht, met ingeschakelde 

hierarchical messages. Er verschijnen dan “subbalkjes”. 

UITGEWERKT VOORBEELD Garage Straatdijk BV 

55

Opdrachtomschrijving 

Uitwerking 

IG9OGO 


In deze opgave gaat het om een administratief systeem voor een garagebedrijf. 

In deze garage werken een monteur, een receptionist en een magazijnbediende. 

De receptionist ontvangt de klanten en spreekt met hen af wat er moet gaan gebeuren aan hun 

auto (grote/ kleine beurt, uitlaat vervangen, nieuwe banden monteren, etc.). Dit wordt opgeslagen 

in het administratiesysteem. 

De monteur voert de afgesproken werkzaamheden uit en registreert de tijd die hij eraan besteedt. 

Als er nieuwe onderdelen nodig zijn, worden deze door de monteur opgevraagd bij de 

magazijnbediende. 

De magazijnbediende zoekt met behulp van het systeem uit of de betreffende onderdelen 

voorradig zijn. Als dat zo is, dan overhandigt hij ze aan de monteur en registreert dit in het 

systeem. Als een onderdeel niet in voorraad is wordt het besteld bij een groothandel. Bij deze 

bestelling wordt de levertijd opgevraagd en in het systeem opgenomen, zodat een nieuwe afspraak 

met de klant kan worden gemaakt. 

Als de klant de auto weer komt ophalen zal de receptionist hem een rekeningoverzicht 

presenteren, waarop de door de monteurs aan de auto bestede tijd (=geld, namelijk EUR 35, - per 

uur) en de kosten van de gemonteerde nieuwe onderdelen staan vermeld, alsmede de totale 

kosten. Als er onderdelen in bestelling zijn, dan zal de receptionist bovendien een nieuwe afspraak 

met de klant maken. Deze afspraken worden ook in de administratie opgenomen. 

Alleen voor afgeronde afspraken kan een rekening opgemaakt worden. 

Gevraagd: 

Maak een NIAM-analyse voor het administratieve systeem en leidt hieruit de classes met hun 

variabelen (class diagram). 

Breid vervolgens dit ontwerp uit door het herkennen van use cases en de daaruit voortvloeiende 

operaties. 

Op grond van een NIAM analyse is een IGD te vinden. 

OPDRACHTOMSCHRIJVING UITWERKING NIAM 

In deze opgave gaat het om een 

//Comment : UoD 

administratief systeem voor een 

//Comment UoD,wel belangrijk voor Use Cases: 

garagebedrijf. 

// Wie doet wat met het systeem? 

In deze garage werken een monteur, een // Mogelijke Actor: monteur, receptionist, 

receptionist en een magazijnbediende. // magazijnbediende 

De receptionist ontvangt de klanten en //Comment: Receptionist Use case: Actor 

spreekt met hen af wat er moet gaan Voorbeeldzinnen: 

gebeuren aan hun auto (grote/ kleine Klant Jansen heeft afspraak op datum 3/2/2000 

beurt, uitlaat vervangen, nieuwe banden Klant Bakker heeft afspraak op datum 8/2/2000 

monteren, etc.). Dit wordt opgeslagen in ==================================== 

het administratiesysteem. 

OPMERKING: het ligt voor de hand deze 

afspraak te nominaliseren: een aantal feiten zijn 

eraan gekoppeld. 

Afspraak : datum voor klant definieert 

een afspraak : datum voor klant 

Evenzo voor werkorder. 

==================================== 

Werkorder: Taak uitlaatvervangen van afspraak 

3/2/2000 voor Jansen is een werkorder. 

Werkorder: Taak grote beurt van afspraak 

8/2/2000 voor Bakker is een werkorder 

OPDRACHTOMSCHRIJVING (vervolg) UITWERKING NIAM (vervolg) 

56

IG9OGO 

De monteur voert de afgesproken 

werkzaamheden uit en registreert de tijd 

die hij eraan besteedt. Als er nieuwe 

onderdelen nodig zijn, worden deze door 

de monteur opgevraagd bij de 

magazijnbediende. 

De magazijnbediende zoekt met behulp 

van het systeem uit of de betreffende 

onderdelen voorradig zijn. Als dat zo is, 

dan overhandigt hij ze aan de monteur en 

registreert dit in het systeem. 

Als een onderdeel niet in voorraad is wordt 

het besteld bij een groothandel. Bij deze 

bestelling wordt de levertijd opgevraagd en 

in het systeem opgenomen, zodat een 

nieuwe afspraak met de klant kan worden 

gemaakt. 

Als de klant de auto weer komt ophalen zal 

de receptionist hem een rekeningoverzicht 

presenteren, waarop de door de monteurs 

aan de auto bestede tijd (=geld, nl. EUR 

35 per uur) en de kosten van de 

gemonteerde nieuwe onderdelen staan 

vermeld, alsmede de totale kosten. 

Als er onderdelen in bestelling zijn, dan zal 

de receptionist bovendien een nieuwe 

afspraak met de klant maken. Deze 

afspraken worden ook in de administratie 

opgenomen. Alleen voor afgeronde 

afspraken kan een rekening opgemaakt 

worden. 


//Comment: Monteur: Actor in Use cases: 

//registratie tijd en onderdelen opvragen 

Aan werkorder grote beurt van afspraak 8/2/2000 

voor Bakker is aantal twee uren besteed. 

Aan werkorder uitlaatvervangen van afspraak 

3/2/2000 voor Jansen is aantal 1 uren besteed. 

Voor werkorder grote beurt van afspraak 

8/2/2000 voor Bakker is aantal 2 van onderdeel 

remblokjes gebruikt 

Voor werkorder uitlaat vervangen van afspraak 

3/2/2000 voor Jansen is een aantal 1 van 

onderdeel uitlaat gebruikt 

//Comment : magazijnbediende actor in Use 

//cases: onderdelen opvragen en onderdelen 

//registreren 

Van onderdeel uitlaat is aantal 3 voorradig 

Van onderdeel remblokjes is aantal 10 voorradig 

//Comment magazijnbedeinde actor in Use case: 

// onderdelen bestellen 

Bestelling van onderdeel uitlaat op datum 

3/2/2000 heeft levertijd van aantal 5 dagen 

Bestelling van onderdeel remblokjes op datum 

8/2/2000 heeft levertijd van aantal 2 dagen 

//Comment : Use case nieuwe afspraak maken 

(zie //vervolg) 

// Comment: Use case rekening maken 

Rekening van afspraak 3/2/2000 voor Jansen 

betreft totaal aantal 4 arbeidsuren 

Rekening van afspraak 8/2/2000 voor Bakker 

betreft totaal aantal 2 arbeidsuren 

Aantal 2 van onderdeel remblokjes voor afspraak 

8/2/2000 voor Bakker is een rekeningspecificatie. 

Aantal 1 van onderdeel uitlaat voor afspraak 

3/2/2000 voor Jansen is een rekeningspecificatie. 

Rekeningspecificatie 1 uitlaat voor 3/2/2000 

Jansen heeft subtotaal van 250. 

Rekeningspecificatie 2 remblokjes voor 8/2/2000 

Bakker heeft subtotaal 120. 

---------------------------------------------------- 

Nodig hiervoor: 

Onderdeel uitlaat heeft prijs 250 euro 

Onderdeel remblokje heeft prijs 60 euro 

---------------------------------------------------- 

Rekening van afspraak 3/2/2000 voor Jansen 

heeft totaalbedrag 490 euro 

Rekening van afspraak 8/2/2000 voor Bakker 

heeft totaalbedrag 240 euro 

//Comment: Use case nieuwe afspraak maken 

//In verband met wel/niet beschikbaar rekening: 

Afspraak 8/2/2000 voor Bakker heeft een vervolg 

57

NIAM: feittypen en afgeleide feittypen 

IG9OGO 


Feittypen: 

Afspraak = datum voor klant definieert een afspraak: datum < -D> voor klant < -K> 

Werkorder = Taak van afspraak is een werkorder: taak van afspraak 

Aan werkorder is aantal uren besteed 

Voor werkorder is aantal van onderdeel gebruikt 

Van onderdeel zijn aantal voorradig 

Bestelling van onderdeel op datum heeft levertijd van aantal dagen 

Onderdeel heeft prijs euro 

Afspraak heeft een vervolg 

Afgeleide feittypen: 

Rekeningspecificatie = Aantal van onderdeel voor afspraak is een 

rekeningspecificatie: aantal onderdeel voor afspraak 

Rekeningspecificatie heeft subtotaal 

Rekening van afspraak heeft totaalbedrag euro 

Rekening van afspraak betreft totaal aantal arbeidsuren 

Dit leidt tot het volgende IGD: 

afspraak 

klant datum 

K 

Afbeelding naar classes in eerst opzet. 

D 

voor is een afspraak 

van is een werkorder 

A 

A 

werkorder 

A 

T 

heeft een vervolg 

werkorder 

taak 

W 

W 

aan is uren besteed 

voor is van gebruikt 

A 

O 

U 

onderdeel 

en 

O 

aantal 

van is voorradig 

O 

O 

V 

D 

Bestelling van op 

heeft levertijd van dagen 

P 

A 

prijs 

58

IG9OGO 


Toelichting: 

Elk objecttype, dus inclusief de nominalisaties, wordt in principe een class: 

Klant , Afspraak, Werkorder, Onderdeel, Datum . 

Aantal en prijs worden direct vereenvoudigd tot attributen in betreffende classes. 

Ternaire feittypen worden een class: 

Voor Werkorder is aantal van onderdeel gebruikt 

wordt ook omgezet naar een class : de class MateriaalItem 

Bestelling van Onderdeel op datum heeft levertijd aantal dagen 

wordt omgezetnaar een class : de class Bestelling 

De UoD class is hier aangegeven met de gebruikelijke benaming class Admin 

Afbeeldingsresultaat: 

class Klant{ 

String naam; // identificatie 

Klant(String nwNaam); 

} 

class Afspraak{ 

Datum afspraakDatum; // identificatie 

Klant klantnaam; // identificatie 

Set werkOrderItems; //WerkOrder 

Afspraak (Klant invoerKlantNaam, Datum invoerAfspraakdatum); 

} 

class WerkOrder{ 

String taak; // identificatie 

Afspraak behorendtotAfspraak;// identificatie 

int uren; 

Set materiaalSpecs; //MateriaalItem 

WerkOrder(String nwTaak, Afspraak nwAfspraak); 

} 

class Onderdeel{ 

String onderdeelNaam; // identificatie 

int voorraadAantal; 

double prijs; 

Onderdeel(String nwOnderdeelNaam, int nwAantalVoorraad, double nwPrijs); 

} 

class GebruikteOnderdelenMapItem{ 

Onderdeel gebruiktOnderdeel; 

int aantal; 

GebruikteOnderdelenMapItem(Onderdeel hetGebruikteOndereel, int nwAantal); 

} 

class Bestelling{ 

Onderdeel bestelOnderdeel; //identificatie 

Datum bestelDatum; // identificatie 

int aantalLeverDagen; // verplicht 

Bestelling( Onderdeel nwBestelOnderdeel, Datum nwBestelDatum, int 

nwAantalLeverDagen); 

} 

class Admin{ 

Set afspraken; //Afspraak 

Set klanten; //Klant 

Set werkOrders; //WerkOrder 

Set onderdelen; //Onderdeel 

Set bestellingen; //Bestelling 

} 

In onderstaande figuur is het classdiagram weergegeven van het ontwerp tot nu toe.( De 

class KeuzeWindow is een onderdeel voor het UserInterface) 

59

Use Cases bepalen 

Vervolgens kunnen actors en use cases 

gezocht worden. In de eerdere NIAM 

analyse is vanuit de 

opdrachtomschrijving al direkt een en 

ander toegelicht met het oog op het 

bepalen van de Use cases van het 

garagesysteem. Als Actor treden een 

receptionist , een monteur en een 

magazijnBediende op. De klant komt 

alleen met zijn gegevens in het systeem 

voor, maar is uiteraard geen gebruiker 

van het systeem. Interactie met andere 

systemen is er ook niet. 

IG9OGO 

Dat levert het nevenstaande Use Case 

Diagram op. 

Vanuit de Use Case maakRekening 

wordt een specificatie opgesteld. 

Hierin kunnen één of meer Flow of 

events worden uitgwerkt in stappen. In 

ieder geval de basic of main flow of 

events. 


stap 1. Geef Admin opdracht maakRekening op basis van klantnaam en afspraakDatum 

stap 2. Admin zoekt klant op met klantnaam 

60

IG9OGO 


stap 3. Admin zoekt Afspraakgegevens op met klant en datum 

stap 4. Admin vraagt afspraak om kosten te berekenen 

stap 5. Afspraak haalt bestede uren op 

stap 6. Afspraak haalt werkorderitems op 

stap 7. Werkorderitem zoekt onderdelenitems op 

stap 8. Onderdeelitem zoekt aantal en onderdeel op 

stap 9. Onderdeel zoekt prijs op 

stap 10. Werkorder berekent subtotaal voor deze onderdelen 

stap 11. Admin geeft Afspraak opdracht een specificatie te maken 

etc. 

Deze gegevens zijn als documentatie op te nemen bij de Use Case conform het eerder besproken 

sjabloon voor een use case specificatie, in dit geval voor rekeningMaken. 

Op de volgende pagina is dit uitgewerkt voor de use case rekeningMaken. 

61

IG9OGO 

Model 


Garage_rose2001_4.mdl 

USECASE 5 

Revision history 

rekeningMaken 

Date Version Description Author 

10/01/2001 0.1 nieuw J. van de Vrie 

11/01/2001 0.2 Extensionpoints 

toegevoegd 

J. van de Vrie 

Brief description UC maakt rekening op voor een verrichte service in de garage 

Main flow of events Step Action 

1 Geef Admin opdracht maakRekening op basis 

van klantnaam en afspraakDatum 

2 Admin zoekt klant op met klantnaam 

3 Admin zoekt Afspraakgegevens op met klant 

en datum 

4 Admin vraagt Afspraak om kosten te 

berekenen 

5 Afspraak haalt bestede uren op 

6 Afspraak haalt werkorderitems op 

7 Werkorderitem zoekt onderdelenitems op 

8 Onderdeelitem zoekt aantal en onderdeel op 

9 Onderdeel zoekt prijs op 

10 Werkorder berekent subtotaal voor deze 

onderdelen 

11 Admin geeft Afspraak opdracht een 

specificatie te maken 

Alternative flow Step condition: Branching Action 

Preconditions 

Postconditions 

Extension points 

voorwaarden waaronder de usecase uitgevoerd mag worden 

1 Klantnaam moet bekend zijn 

2 Afspraakgegevens moeten ingevoerd zijn 

3 Werkorderitems moeten ingevoerd zijn 

4 Onderdeelitem moet ingevoerd zijn 

5 Onderdeel moet ingevoerd zijn 

6 

Flow nr Result 

Main Flow 

(Success End) 

1 Een gespecificeerde 

rekening is 

geproduceerd 

2 

Altern. nvt 

Step Errorcondition Use case 

2 Klant niet in 

gevoerd 

UC Klant niet ingevoerd 

62

IG9OGO 


Elke Use case kan tenslotte in de corresponderende Use Case Realization voorzien worden van 

een SequenceDiagram.Hieronder is een deel van het Sequencediagram behorend bij de main flow 

van rekeningMaken afgedrukt. 

SequenceDiagram 

Toelichting: 

Het SequenceDiagram is vrijwel direkt af te leiden uit de hierboven beschreven basic flow of events 

voor de Use Case . Als volgt: 

De objecten kunnen geplaatst worden zodra deze een taak te vervullen hebben volgens de 

usecase specificatie. 

In het voorbeeld kan begonnen worden met de plaatsing van de Actor :receptionist, door 

selecteren en slepen vanuit de UsecaseView in de objectbrowser. 

63

IG9OGO 


Vervolgens kan het object Admin geselecteerd uit de Logical View in dezelfde browser en gesleept 

worden naar het nieuwe sequencediagram . Nu kan er een message verstuurd worden door 

selectie uit de toolbar van een pijl als symbool voor een message of een terugkerende pijl voor een 

message naar het object zelf (reflexive message). Dit laatste is dus een bericht waar geen ander 

object bij betrokken wordt. 

In bovenstaande uitsnede uit het voorbeeld zijn dus objecten actor :receptionist geplaatst, 

vervolgens het object :Admin. Daarna is er een message geplaatst van de actor naar het Admin 

object. Hierbij is met het popupmenu een aangemaakt: maakRekening met 

parameters van String en Datum type. Bij plaatsing van messages is het van belang op het 

rechthoekje te starten. Deze rechthoek (focus of control) is in de verticale tijdlijn (of levenslijn) van 

een object een aanduiding voor een actieve methode. Bij ruimtegebrek voor plaatsing van een 

message met specificatie vindt dan automatisch verlenging plaats. Bij problemen kan ook het 

rechthoekje zelf geselecteerd worden en op de gebruikelijke manieren via de hoekpunten vergroot 

of verkleind worden. 

Voor het specificeren van de messages is veelal een uitbreiding van de operaties /methodes van 

de classes van de geplaatste objecten vereist. Dit kan gebeuren zodra een messagesymbool 

geplaatst is. In het bijbehorende pop-up menu kan het item worden geselecteerd. 

Een interactieve classuitbreiding is zo mogelijk. In de registratie van de class wordt de message als 

een nieuwe methode opgenomen. 

Het verwijderen van onjuist geplaatste objecten en messages moet via een menuoptie gebeuren. 

Dit kan niet met een delete na selectie. Hiervoor is in het Edit menu het menuitem Delete from 

Model of Ctrl-D beschikbaar. 

64


OEFENING 3.1: 

IG9OGO 


Een verzekeringsmaatschappij biedt verschillende soorten Verzekeringen aan: ziektekosten-, 

auto-, inboedelverzekeringen enz. Bovenstaande figuur geeft een niet-volledig UML diagram. 

Elk van de soorten verzekeringen wordt in één of meer polisvormen aangeboden: de 

inboedelverzekering alleen als standaard verzekering , de ziektekosten verzekering als standaard 

en als uitgebreide verzekering, de auto als wa, wa plus en casco-verzekering. Het hoogste aantal 

polisvarianten per soort is 4. 

De verzekeringspolissen worden ook in een pakket aangeboden van willekeurige samenstelling 

voor een bepaalde verzekerde, dan geldt een extra pakketKorting. Een pakket bestaat uit minimaal 

2 polissen. Ook losse polissen kunnen worden aangeboden, maar dan niet in een pakket en dus 

ook niet met extra korting. 

a. Vul de multipliciteitsaanduidingen in en geef een toelichting. 

b. De relatie tussen Verzekeringsvorm en VerzekeringsPakket is niet als aggregatie 

aangegeven . Waarom niet? 

OEFENING 3.2: Bankautomaat (uitwerken op het systeem) 

Bedrag Rekening 

Rekeninghouder 

B R 

R RH 

R P 

heeft saldo heeft heeft 

En-of-rekening 

B R 

op staat minimaal R E R 

is een heeft als 

en-of-rekening mederekeninghouder 

Pincode 

Het betreft hier een bankautomaat waarbij een rekeninghouder, na zijn rekeningnummer en 

pincode te hebben opgegeven het volgende kan doen: het saldo opvragen, geld opnemen, geld 

storten, en geld naar een andere rekening overboeken. 

Een bankmedewerker moet de automaat kunnen vullen, legen, een nieuwe rekening kunnen 

aanmaken en overzichten kunnen produceren. 

a. Maak een ontwerp van het systeem d.m.v. een class diagram en voer dit in Rational Rose in. 

b. Onderscheid verder actors en use cases en voer een use case diagram in Rational 

Rose in. 

65

OEFENING 3.3: vervolg van bankautomaat oefening 3.2 

OEFENING 3.4 

OEFENING 3.5. 

IG9OGO 


Werk uit opgave 3.2 de volgende use cases uit in een Sequence diagram: 

- saldo opvragen 

- geld naar andere rekening overboeken 

- produceer rekeningen overzicht. 

Voer een class diagram in van de eerder gemaakte uitwerking van oefening 2.8. 

Geef ook de multipliciteiten aan. 

a. Maak voor de afgeronde Practicumopdracht Onroerend Goed een Use case diagram en 

vul een specificatietabel in volgens het gegeven sjabloon. 

b. Werk de use case “eigenaar toevoegen aan eigenarenbestand” uit in de bijbehorende Use 

Case Realization met één of meer sequencediagrams, afhankelijk van het aantal flows 

waarmee de UC is te specificeren 

66


IG9OGO 


1. Waarom ontwerpen we aan de hand van modellen? 

2. Welke views vormen de basis van UML modellering in RationalRose? Wat is de betekenis 

ervan? 

3. Wat zijn associaties en aggregaties? Met welke symbolen zijn deze in UML aan te geven? 

4. Wat is het doel van een use case diagram? 

5. Wat is het verschil tussen een sequence en een collaboration diagram? 

6. Maak een class diagram bij de uitwerking van Zelftoets moduletaak 2 vraag 4. 

7. Ontwerp voor de use case “urenInvoeren “ van het Garagevoorbeeld een Sequencediagram 

voor de main flow of events. 

Controleer weer je uitwerkingen en maak een aanvullende studie van de onderwerpen die 

niet goed uit de verf kwamen bij het maken van de toets. 

Voor problemen bij het gebruik van Rational Rose voor het maken van de diagrammen is de 

volgende, eerder genoemde pdf file mogelijk een goed hulp middel: 

/hio/praktikum/i1/OGO/Rose_usingrose.pdf: gebruikershandleiding voor Rational Rose2000. 

67


Moduletaak 4: Uitbreiding Java taal concepten: interfaces en inheritance (verv.) 


Voorkennis 

Taakdoel 

Oriëntatie 

Verwerking 

Verdieping 

Zelftoets 

IG9OGO 



Verwerking moduletaken 1 t/m 3 

Student: 

leert Java interface concept begrijpen en toepassen. 

Kent toepassing in Comparable en Cloneable interface 

leert het begrip abstract class kennen en gebruiken. 

kent begrip inner class. 

Als uitbreiding van het OO inheritance mechanisme wordt het begrip abstract class behandeld. 

Hiermee wordt de mogelijkheid gecreëerd om implementatie van methoden in een subclass af te 

dwingen. 

Omdat in Java geen multiple inheritance geïmplementeerd kan worden is een interface een 

noodzakelijk aanvullend taalelement in Java. In de praktijk is er vaak behoefte aan een afleiding 

van meer dan één class: dus meerdere supers voor één sub. Met interfaces kan vrijwel hetzelfde 

bereikt worden als met meervoudige overerving zonder de beruchte complicaties ervan, in de vorm 

van complexiteit en inefficiency van de compiler, zoals bijvoorbeeld in C ++ . 

Bestudeer de leestekst bij Moduletaak 4 

Bestudeer de overeenkomstige stof uit het boek Core Java Volume 1 

uit Hoofdstuk 5: blz. 176-180, 182 abstract class 

uit Hoofdstuk 6: blz. 229-238 interfaces 

Maak de door de begeleidende docent aangegeven selectie uit de oefeningen van de 

moduletaak. 

Bestudeer uit het Core Java boek de toepassing van een inner class : blz. 238- 242 inner 

class to implement an interface. 

Als toepassing van interfaces kan vast gekeken worden naar event handling in Hoofdstuk 8 van het 

Core Java Boek Volume 1 : blz315-323. Deze stof komt uitvoerig aan bod bij de module inleiding 

Grafische User Interfaces. 

Maak de zelftoets van deze moduletaak, controleer je uitwerking en plan zonodig een 

aanvullende bestudering van deelonderwerpen van deze taak. 

LEESTEKST Moduletaak 4: JAVA interface concept , inner class en inheritance (vervolg) . 

Java interface concept 

68

Java interface 

IG9OGO 


Veel Java packages zijn opgebouwd met behulp van interfaces. In de JDK wordt er veelvuldig 

gebruik van gemaakt. (Zie oefening 1 van deze moduletaak). Ook voor zelf ontworpen software 

kan het een handig concept zijn. Wat wordt er onder verstaan? 

Een interface kan beschouwd worden als 

• een abstract class (zie vervolg), zonder data members, met uitzondering van constanten 

• waarin methoden worden vastgelegd door middel van hun “signature”, zonder verdere 

definitie. 

Het doel van interfaces is een contract vast te leggen over te implementeren methodes: 

• Interfaces zijn bedoeld om methoden te ‘erven’ en daardoor bepaald gedrag af te 

dwingen 

Men zegt dat een class een interface implementeert als de methoden aangegeven in de interface 

geïmplementeerd worden in de class. In de class definitie wordt dit volgens de syntax, als in 

onderstaand voorbeeld, aangegeven: 

Een voorbeeld uit de package java.util: 

public class HashSet implements Set { 

……… 

} 

De class HashSet verplicht zich hiermee de in de interface Set aangegeven methoden te 

implementeren en voldoet derhalve aan het “contract” gedefinieerd in de interface. 

Bij dit implementeren is dus sprake van “erven” maar nu niet van een gewone class maar van een 

interface. Voor de interface Set gaat dit om een 15-tal methoden. Dit aantal kan ook veel kleiner 

zijn. Een tweede voorbeeld, nu uit de package java.lang maakt dit duidelijk: 

public class Thread implements Runnable { 

……… 

} 

De interface Runnable legt nu alleen de signature van de methode run( ) vast. Deze moet nu in de 

class Thread geïmplementeerd worden. Overigens het gebruik van deze class Thread komt pas in 

een vervolgmodule aan de orde. 

In UML notatie wordt een interface als een class weergegeven met een stereotype 

Een implementerende class wordt verbonden met het interface door een gestreepte pijl met open 

punt, het “realize symbol”. De rechterfiguur is een alternatieve weergave meestal voor components 

of packages gebruikt, die een interface implementeren. Voor classes gebruikt men doorgaans de 

linker voorstelling. 

Eenvoudig voorbeeld van een eigen interface toepassing 

In een programmaontwikkeling waarin voorwerpen van verschillende vorm voorkomen 

69

IG9OGO 


kunnen algemene eigenschappen in een superclass worden ondergebracht waarvan de andere 

vormen erven. In geval de superclass alleen algemene methoden bevat kan hiervoor beter een 

interface worden gedefinieerd. 

De interface verplicht nu de implementerende classes te voorzien in een methode inhoud( ) en een 

methode toString( ). 

Eigenschappen van Java interfaces 

1. Allereerst is een interface impliciet public en abstract. 

Dat laatste begrip komt in het vervolg van deze leestekst aan de orde. Voorlopig houdt het 

alleen in dat er geen instanties van gecreëerd kunnen worden. 

Deze eigenschappen mogen expliciet vermeld worden: 

public abstract interface ExampleInterface { 

// eventuele definities van constanten 

// 

// method signatures 

} 

2. Een interface kan ook als typeaanduiding optreden in een declaratie van een object. 

Voor bovenstaand voorbeeld: 

Vorm tekenVorm; 

tekenVorm = new Bol(7); 

Of in het eeerdere voorbeeld van een Set interface geïmplementeerd door een HashSet 

Set voorbeelden; 

voorbeelden = new HashSet( ); 

3. Ook bij een interface typeaanduiding als onder 2 mag gebruik gemaakt worden van de 

instanceof operator, zoals bij gewone classes: 

if ( voorbeelden instanceof Set) { ………….} 

4. Evenals bij inheritance wordt door middel van dynamic binding bepaald welke definitie van 

een methode bij aanroep wordt gebruikt. 

In het voorbeeld onder 2 met tekenVorm zal tekenVorm.inhoud( ) in dit voorbeeld de 

Bol implementatie van inhoud ( ) gebruiken. 

70

IG9OGO 


Het gedeclareerde type is immers Vorm maar het actuele type is Bol. 

5. Een interface kan zelf afgeleid worden middels overerving van een ander interface. 

Het eerder aangehaalde voorbeeld van een Set interface uit de package java.util voldoet hier 

aan, door de afleiding van interface Collection: 

public abstract interface Set extends Collection { 

……………. 

} 

Let op dat hier dus weer wel extends gebruikt moet worden. Er is immers geen sprake van 

implementeren maar van overerving: het contract wordt alleen maar uitgebreid, nog steeds 

zonder invulling. 

6. Classes kunnen meerdere interfaces tegelijk implementeren, maar slechts van één super 

erven, bijvoorbeeld: 

public class InvoerScherm extends Frame implements Observable, Comparable { ….} 

De verschillende interfaces die geïmplementeerd worden, worden hierbij door een komma 

gescheiden. 

7. Er bestaan interfaces, tagging interfaces, die geen enkele methode vastleggen: het enige doel 

ervan is om te informeren en de operator instanceof te kunnen hanteren. Voorbeeld , zie 

vervolg, Cloneable interface. 

Interfaces en vergelijking van objecten: Comparable 

In de module P_J2 is in Moduletaak1 in de leestekst paragraaf 12 al aandacht besteed aan het 

vergelijken van objecten door aanroep van de methode boolean equals(Object). Daarmee is het 

mogelijk in Collections te controleren op al of niet aanwezig zijn van objecten. 

In aanvulling hierop is er in de package java.lang een interface Comparable gedefinieerd waarin 

een methode compareTo ( ) wordt vastgelegd. Hiermee is het mogelijk reeksen van gelijksoortige 

objecten te ordenen. 

public interface Comparable { 

public int compareTo(Object b ); 

} 

De JDK documentatie geeft voor compareTo( ) de volgende informatie: 

public int compareTo(Object o) 

Compares this object with the specified object for order. Returns a negative integer, zero, or 

a positive integer as this object is less than, equal to, or greater than the specified object. 

It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == 

(x.equals(y)). Generally speaking, any class that implements the Comparable interface 

and violates this condition should clearly indicate this fact. The recommended language is 

"Note: this class has a natural ordering that is inconsistent with equals." 

Parameters: 

o - the Object to be compared. 

Returns: 

a negative integer, zero, or a positive integer as this object is less than, equal to, or greater 

than the specified object. 

Throws: 

ClassCastException - if the specified object's type prevents it from being compared to this 

Object. 

71

IG9OGO 


Een class waarvan de objecten gesorteerd dienen te worden moet nu de Comparable-interface 

implementeren; dus er moet een implementatie zijn van de methode compareTo. 

Toepassing van interface Comparable: Een vergelijkbare persoon 

De class Persoon kan nu vergelijkbaar (Comparable) gemaakt worden door deze Comparable te 

laten implementeren: 

class Persoon implements Comparable { 


} 

public Persoon (String nwNaam) { 

naam = nwNaam; 

} 

public int compareTo (Object comparant) { 

Assertion.require ( 

comparant instanceof Persoon, 

“argument moet van type Persoon zijn”); 

} 

return (naam. compareTo 

(((Persoon) comparant).naam); 

// N.B. 

// 1. comparant moet eerst naar een Persoon gecast 

// worden, om de naam te pakken te kunnen krijgen. 

// 2. compareTo is een methode van String die twee strings vergelijkt. 

// String implementeert zelf ook interface Comparable 

Nu kunnen we in een eenvoudige applicatie personen vergelijken: 

class Appl { 

public static void main (String args []) { 

Appl appl = new Appl (); 

appl.doeAlles (); 

} 

} 

void doeAlles () { 

Persoon p1 = new Persoon (“alie”); 

Persoon p2 = new Persoon (“bert”); 

} 

// Met als uitvoer: 

// p1 komt voor p2 

Interfaces en kopieën van objecten : Cloneable 

if (p1.compareTo (p2) < 0) { 

System.out.println (“p1 komt voor p2”); 

} else { 

System.out.println (“p2 komt voor p1”); 

} 

Als we normaliter een kopie maken van een object wordt er gekopieerd op referentiebasis. 

Persoon a = new Persoon(“Jansen”); 

Persoon b = a; 

// a en b verwijzen nu naar het zelfde object. 

Vergelijken van de twee objecten met de operator == levert een referentievergelijking op: 

a == b; // Dwz. True als a en b naar hetzelfde object verwijzen 

Gevolg van deze kopie op referentiebasis is dat een wijziging via a ook een wijziging van b inhoudt. 

a Persoon 

String naam Jansen 

72

IG9OGO 


Voor het creëren van een nieuw object met overeenkomstige instance variabelen als een 

oorspronkelijk object, maar met een eigen geheugenopslag biedt de class Object de methode 

clone( ). 

Echter , een buitenbeentje! De methode clone( ) heeft toegangsspecificatie protected, zodat alleen 

binnen eigen methoden van een (afgeleide) class gebruik gemaakt kan worden van clone( ). 

Daar is een gegronde reden voor: de methode clone( ) van Object kan alleen een bit-by-bit kopie 

leveren , daar er niet van te voren bekend is welke instance variabelen in een class gedefinieerd 

zullen worden. 

Resultaat toepassing van clone( ) uit Object een “shallow clone”: 

Bezwaar : Persoon objecten delen nog steeds de naamstring. 

Dat vraagt om herdefinitie van de methode clone( ) in de afgeleide class. Als extra wordt er vereist 

dat bij het gebruik van deze clone( ) ook de (lege) interface Cloneable wordt gedefinieerd om te 

voorkomen dat er een Exception optreedt bij het gebruik van clone( ). Dit is ingebouwd als extra 

beveiliging om er zeker van te zijn dat clone( ) bewust , en hopelijk correct, geherdefinieerd wordt. 

Toegepast voor de class Persoon wordt een “deep clone” afgeleverd bij de volgende implementatie 

van clone( ): 

class Persoon implements Cloneable { 

{ …….. 

public Object clone( ) { 

try { 

Persoon kopie = (Persoon) super.clone( ); 

// aanroep Object.clone( ) 

kopie.naam = (String) naam .clone( ); 

return kopie; 

} 

catch (CloneNotSupportedException exc) { 

return null; 

} 

} 

} 

Resultaat: twee volledig onafhankelijke Persoon objecten ieder met eigen naamstring. 

Inner class 

Inner class als Java taalconcept 

a 

b 

a 

b 

b 

Persoon 

String naam 

Persoon 

String naam 

Persoon 

String naam 

Persoon 

String naam 

Jansen 

Jansen 

Jansen 

In de Collections zoals die opgenomen zijn in JDK 1.2 wordt gebruik gemaakt van inner classes 

Ook voor event handling in programma’s met een grafisch user interface is het soms handig 

gebruik te maken van inner classes voor het sturen van de reacties op optredende events. 

73

IG9OGO 


Hierbij zijn zogenaamde Listenerclasses vaak als inner classes geïmplementeerd. Het gebruik van 

aparte zelfstandige classes hiervoor is vaak strijdig met het ontwerpprincipe van “lokaliteit”. De 

verantwoordelijkheid voor het beheer ligt immers geheel binnen de klasse. Populair gezegd 

betekent “lokaliteit”: iedere aparte verantwoordelijkheid van het systeem als geheel dient zoveel 

mogelijk op één plek gerealiseerd te worden, zodat wijziging van deze verantwoordelijkheid op zo 

min mogelijk plaatsen tot wijziging van de code leidt. 

Voorlopig blijft de behandeling van dit Java taalconcept beperkt tot de syntax en de betekenis 

ervan. In Moduletaak 5 wordt dit gebruikt onder andere bij de Comparator interface 

Wat is een inner class? 

Definitie Een inner class is een class waarvan de definitie binnen die van een andere 

(omhullende) klasse staat. 

Syntax Syntax is precies hetzelfde als de definitie van een gewone class. 

Eigenschappen 

* Binnen de inner class definitie zijn ook alle attributen en methoden van de 

omhullende class zichtbaar 

* Instanties van de inner class kunnen alleen binnen instanties van de omhullende 

class bestaan. 

Voorbeeld 

class OmhullendeKlasse 

{ 

private int x; 

BinnenKlasse binnenIn= new BinnenKlasse(); 

Nogmaals: inheritance 

Abstract class 

} 

class BinnenKlasse 

{ 

int y = x –1; // toegang tot attributen OmhullendeKlasse 

…… 

} 

……… 

In het voorgaande is al verschillende keren het begrip abstract class opgedoken. 

In een inheritance relatie is het soms niet gewenst dat van de superclass objecten worden 

gemaakt. 

Een voorbeeld: 

Er mogen wel objecten van het type Manager etc gemaakt worden, maar niet van het type 

Personeelslid. Deze class dient alleen om gemeenschappelijke variabelen en methoden vast te 

leggen. 

74

IG9OGO 


Syntax en betekenis 

Een abstract class wordt alleen aangeduid met het keyword abstract. 

De betekenis ervan is dat er geen instanties van deze class aangemaakt kunnen en/of mogen 

worden. 

Abstracte methoden abstract class 

Het is mogelijk dat een superclass een of meer methoden heeft die we niet kunnen 

implementeren. Bijvoorbeeld: Stel we kunnen het salaris van een personeelslid niet berekenen, 

alleen die van de specifieke personeelsleden, omdat bepaalde gegevens nodig zijn die afhangen 

van het soort personeelslid. Toch willen we bij een personeelslid het salaris kunnen berekenen 

(dynamic binding). Dan moet de methode berekenSalaris in Personeelslid abstract gedefinieerd 

worden. De class Personeelslid wordt daardoor automatisch abstract. 

Een class met één of meer abstracte methoden is per definitie een abstract class 

Voorbeeld abstract method en dus: abstract class 

abstract class Personeelslid { 

// variabelen 

abstract public void berekenSalaris(); 

} 

class Laborant extends Personeelslid { 

// variabelen 

public void berekenSalaris() { 

// hier komt de implementatie 

} 

} 

Opmerkingen: 

De abstracte methode berekenSalaris in Personeelslid heeft geen implementatie; ook geen { en }. 

Een abstracte class kan meer dan één abstracte methode bevatten. Er mogen overigens in een 

abstract class wel andere methoden voorkomen die wel geïmplementeerd zijn. Dit is overigens 

een belangrijk verschil met een Java interface. 

Toepassingen. 

In veel packages zijn abstract classes terug te vinden. In het vervolg van deze module zullen in 

taak 5 bij het behandelen van Collection voorbeelden opnieuw abstract classes naar voren komen. 

Opmerkingen over Ontwerpen met interfaces en abstract classes. 

Vanuit ontwerpoptiek is er doorgaans sprake van een zinvolle toepassing van een abstract class 

als er sprake is van een “ is een ….” relatie ( in Niam van subtypering). 

Een interface daarentegen is vaak toepasbaar als er sprake is van een “kan …..” omschrijving om 

aan te geven waar objecten van verschillende klassen gemeenschappelijk toe in staat zijn. 

Overigens moet opgemerkt worden dat JAVA ook in het eerste geval soms dwingt om toch een 

interface te gebruiken in verband met het ontbreken van meervoudige overerving. Als er al sprake 

is van een superclass waarvan reeds geërfd wordt is men gedwongen om verdere “is een…” 

relaties toch met één of meer interfaces te realiseren. 

75


OEFENING 4.1 Toepassingen interfaces in JDK 1.2 

IG9OGO 


Ga in de documentatie van de JDK op het systeem na welke interfaces voorkomen in de package 

java.util en java.lang. 

Ga voor de interface Set en de interface Runnable na hoevel methoden er in een 

implementerende class gedefinieerd moeten worden. 

OEFENING 4.2 Overerving (nogmaals) 

Gegeven is de volgende zelfgedefinieerde klassehiërarchie, waarin Collectie een abstracte klasse 

is. 

Bag 

Verzameling 

Collectie 

Lijst 

Elk van de volgende vier programmafragmenten bevat een fout. Geef nauwkeurig aan wat er fout 

is en ook of deze fout door de vertaler of pas tijdens verwerking opgemerkt wordt. 

Als de fout hersteld kan worden door het toevoegen van een cast, toon dan ook de verbeterde 

versie. 

a Collectie collectie = new Collectie(); 

b Collectie collectie = new Verzameling(); 

Bag bag = collectie; 

c Collectie collectie = new Lijst(); 

Bag bag = (Bag)collectie; 

d Collectie collectie = new Bag(); 

Verzameling verzameling = (Verzameling)collectie; 

OEFENING 4.3. Gebruik van Java interface concept 

Gegeven zijn de volgende declaraties van een interface Verlengbaar en van klassen I en T. 

interface Verlengbaar 

{ 

void verleng(); 

String waarde(); 

} 

public class T implements Verlengbaar 

{ 

private String s; 

public T(String t) 

{ 

s = t; 

} 

public void verleng() 

{ 

s = s + s; 

} 

76

IG9OGO 

} 

public String waarde() 

{ 

return s; 

} 


public class I implements Verlengbaar 

{ 

private int i; 

} 

public I(int n) 

{ 

i = n; 

} 

public void verleng() 

/* "verdubbelt" i. 

* voorbeelden: als i = 56 dan wordt i 5656; 

* als i = 200 wordt i 200200. 

*/ 

{ 

i = Integer.parseInt("" + i + i); 

} 

public void verdubbel() 

{ 

i = 2*i; 

} 

public String waarde() 

{ 

return i + ""; 

} 

Geef voor elk van de volgende codefragmenten aan of dit fragment correct is en zo ja, wat na 

afloop de waarde is van de string s. Als het fragment niet correct is, geef dan ook aan waarom niet. 

a Verlengbaar v = new Verlengbaar(); 

v.verleng(); 

String s = v.waarde(); 

b Verlengbaar v = new I(43); 

v.verleng(); 


c Verlengbaar v = new T("xyz"); 

v.verleng(); 


d Verlengbaar v = new I(43); 

v.verdubbel(); 


OEFENING 4.4 Adressen vergelijken met herdefinitie equals methode 

Gegeven is een class Adres: 

class Adres { 

private String straat; 

private int huisnummer; 

private String postcode; 

private String plaats; 

... 

} 

Een tweetal adressen is gelijk als huisnummer en postcode overeenkomen. 

77

IG9OGO 


Schrijf de methode public boolean equals(Object andere). 

De postcode kan ook als volgt worden gemodelleerd met behulp van een class Postcode: 

class Postcode { 

private int cijfers; // invariant: 1000


IG9OGO 

Geef antwoord op de volgende vragen: 


1. Wat is een interface in JAVA termen? Noem een voorbeeld van een toepassing. 

2. Wat is een abstract class? Wat is het nut hiervan? 

3. Zijn een interface en een abstract class uitwisselbaar? Waarom wel/niet? 

4. De volgende figuur toont een deel van de componentenhiërarchie uit de awt. Container en 

Component zijn abstract classes 

Component 

Container TextComponent 

Panel Window 

Dialog Frame 

TextArea TextField 

Gegeven is bovendien nog het volgende: 

− De klasse Container heeft een methode add met de volgende signatuur: 

public void add(Component c) 

− De klassen Window en Dialog hebben constructoren als volgt: 

public Window(Frame parent) 

public Dialog(Frame parent) 

− Een applicatieprogrammeur definieert in een eigen klasse een methode met de volgende 

signatuur: 

public void voegLettersToe(TextField tf, Window w) 

Elk van de volgende programmafragmenten bevat een fout. Geef aan wat er fout is en 

wanneer deze fout optreedt, bij vertaling of bij verwerking. Als de fout vermeden kan worden 

door een cast toe te voegen, toon dan ook de verbeterde code. Licht je antwoorden kort toe. 

a Component c1 = new Panel(); 

Component c2 = new Frame(); 

c2.add(c1); 

b Window w = new Frame(); 

Dialog d = new Dialog(w); 

c TextComponent tc = new TextArea(); 

Frame f = new Frame(); 

voegLettersToe((Textfield)tc, f); 

79

IG9OGO 

VERVOLG ZELFTOETS bij moduletaak 4 


5. Gegeven zijn de volgende klassedefinities. 

public class A 

{ 

public int tien(int i) 

{ return i+10; } 

} 

public int twintig(int i) 


public class B extends A 

{ 


{ return i*10; } 

} 

public int superTien(int i) 

{ return super.tien(i); } 

public class C extends B 

{ 



} 

Geef voor elk van de volgende programmafragmenten aan, of het fragment correct is. Zo 

niet, wat is er fout? Zo ja, wat is na afloop de waarde van de variabele resultaat? Licht je 

antwoorden kort toe. 

a B b = new B(); 

int resultaat = b.twintig(2); 

b A a = new C(); 

int resultaat = a.tien(2); 

c A a = new C(); 

int resultaat = a.twintig(2); 

d A a = new C(); 

int resultaat = a.superTien(2); 

e B b = new B(); 

int resultaat = b.superTien(2); 

80


Voorkennis 

Taakdoel 

Oriëntatie 

Verwerking 

Verdieping 

Zelftoets 

IG9OGO 


Moduletaak 5 : Collections. 

Basiskennis Java uit de modulen IG9 P_J1 IG9 P_J2 en basiskennis informatieanalyse uit IG9 

I_A1, IG9 I_A2 


In de module Programmeren in Java 2 heb je kennis gemaakt met het gebruik van een Set, een 

dynamische datastructuur. De kennismaking was toen vrij smal, er werd van één soort collectie 

kennis gemaakt, terwijl er ook vaak behoefte is aan een collectie met andere eigenschappen. Hier 

gaan we in deze moduletaak verder op in. 

• Je maakt kennis met diverse standaard collectietypen, waarvan er een aantal te vinden zijn in 

de Java Collection Framework (JCF). 

• Je leert hoe je een aantal standaard collecties gebruikt. In taak 6 ga je zelf een collectie 

implementeren. 

• Daarnaast leer je hoe je de implementatie van een collectie scheidt van zijn interface. Dit is 

een concept wat de flexibiliteit van je software bevordert. 

• Tevens leer je gebruik te maken van de Java 2 API documentatie. 

Bestudeer de leestekst Collecties L5.1, L5.2 en L5.4 

Maak ter introductie oefening 5.1. Werk vervolgens de oefening Bank (oefening 5.2) op het 

systeem uit. Hier ga je de reeds bekende bank met behulp van een Map implementeren (ipv Set). 

In overleg met de docent wordt verder een selectie van de oefeningen op het werkcollege 

uitgevoerd. 

• In L5.5 kun je nog eens nalezen hoe een Map met gelijkheid van objecten omgaat. 

• De Java Collections Framework, en met name het sorteren van objecten in een collectie wordt 

in L5.3 gesproken. Informatie hierover kun je ook vinden op het net. 

• In de Java Tutorial kun je online (of downloaden) een uitgebreide behandeling van de Java 

Collections Framework vinden. Deze is uitgebreider dan de genoemde leestekst. 

http://java.sun.com/docs/books/tutorial/collections/index.html 

• Wat extra informatie is nog te vinden in een reader, ook bij Sun 

http://developer.java.sun.com/developer/onlineTraining/collections/Collection.html 

• Nieuw is het Hoofdstuk van Core Java 2, volume 2 over Collections: 

http://developer.java.sun.com/developer/Books/corejava/index.html 

• Tot slot vind je in de paragraaf L5.6 nog wat achtergrondinformatie over de JCF 

Maak ter afronding van deze moduletaak de zelftoets en controleer zelf je uitwerkingen met die 

in de bijlage van deze modulehandleiding. Herhaal zonodig enkele oefeningen of vraag de 

docent om extra oefenmateriaal. 

81

LEESTEKST: Collecties 

L5.0 Samenvatting 

IG9OGO 


• scheiden van implementatie en de interface 

• standaard collecties 

• Set en Map collecties 

• Lijst collecties: Queue, Stack en Sequence 

• De ‘primitieve’ array 

• Benaderen van een collectie, de Iterator 

• Collections in de Java Collection Framework 

• Ordening in collecties, de Compatator 

• Algoritmen, de Collections class 

• oude gedienden, de Vector en Hashtable 

• verdieping: optional operations, even opletten 

L5.1 Scheiden van implementatie en zijn interface 

Als we in een programma kiezen voor een bepaald soort collectie, is het nog niet altijd zeker welke 

implementatie het meest geschikt zal zijn. Zo kan het zijn dat het een kleine collectie betreft met 

weinig toegang of een uit de kluiten gewassen systeem met capaciteitsproblemen. Om te 

vermijden dat men een keuze moet maken waaraan men ‘zijn leven lang’ vastzit, ook na het 

ontstaan van andere randvoorwaarden, is het handig om de daadwerkelijke implementatie te 

scheiden van zijn interface, ofwel: je legt het type collectie wel vast, dus wat je ermee moet 

kunnen, maar hoe het onder water gerealiseerd wordt niet. Welnu, het type collectie kun je 

beschrijven middels een interface. Deze geeft aan welke functionaliteit de collectie moet bezitten. 

In de implementatie van dit interface, ofwel een class welke de interface implementeert, wordt deze 

functionaliteit dan uitgewerkt. Wil je een andere implementatie welke wellicht dan beter past bij je 

toepassing, een stukje fine- tuning, dan hoef je alleen bij het creëren van de collectie dit te 

veranderen. 

Voor de rest blijft het gebruik van de collectie gelijk omdat overal in je programma wordt uitgegaan 

van de beschikbare methoden zoals in de interface beschreven. 

We hebben dit ook al gezien in de module Programmeren in Java 2. Hier hebben we een 

algemene collectie gebruikt met het interace Set, met de implementatie HashSet() 

Set boeken = new HashSet(); 

Je kunt hier een eigen implementatie aan hangen door een kleine wijziging: 

Set boeken = new MySet(); 

Verder hoef je in je programma niets te wijzigen, wat vervelende bugs voorkomt. 

Het scheiden van een implementatie en zijn interface wordt ook wel ‘Programming to the interface’ 

genoemd en wordt o.a. toegepast bij collecties, maar ook bij andere classes waarbij men de 

vrijheid van implementatiekeuze wil houden. 

82

L5.2 Standaard collectie types 

L5.2.1 Set 

IG9OGO 


Het aantal soorten collecties dat als standaard geld zijn redelijk beperkt. In taak 6 geen we kijken 

hoe je tot een keuze van een collectie-type komt. Eerst laten we zien hoe je ze kunt gebruiken. Dit 

zal de keuze later vereenvoudigen. Als gemeenschappelijke kenmerk hebben ze dat ze allemaal 

een serie elementen beheren. Een deel van de hier genoemde collecties is opgenomen in de Java 

Collections Framework (JCF). 

Om deze serie elementen te kunnen benaderen is onder andere de iterator een nuttig hulpmiddel. 

De iterator stelt ons in staat om in de elementen te ‘bladeren’. Dit is eerder besproken in de module 

‘Programmeren in Java 2’ en wordt hier niet verder op ingegaan. 

We bekijken hier drie soorten collecties: 

• De Set 

Een verzameling van objecten, met als bijzonder kenmerk dat elk object maar één keer in de 

Set kan voorkomen. De Set is opgenomen in de JCF. 

• De Map 

Een verzameling key / value combinaties. Ook de map is opgenomen in de JCF. 

• De List 

Bij een lijst liggen de elementen in een bepaalde volgorde. Dit is niet persé gesorteerd. Er zijn 

vele vormen van lijsten te bedenken. De List is als interface opgenomen in de JCF. 

• Stack (stapel: last in, first out) 

• Queue (wachtrij: first in, first out) 

• Sequence of ook de LinkedList. De LinkedList is opgenomen in de JCF 

• array: als primitieve- type houdt de array zijn bepaald aantal elementen op volgorde. 

Een dynamische variant is de ArrayList, welke opgenomen is in de JCF 

De list kent nog uitbreidingen zoals een tree. Dit zijn complexere structuren die in de modulen 

verder niet aan de orde komen, maar wel als implementatie in de Java Collections Framework 

terug te vinden zijn. (TreeSet en TreeMap). 

De functionaliteit van de collecties, behalve van de array, kun je vastleggen in een interface zoals 

voor een deel al is gedaan in de Java Collection Framework. Dit betekent dat er per interface 

implementaties beschikbaar moeten zijn met allemaal hun eigen specifieke gedrag. Echter, daar 

de functionaliteit is vastgelegd in de interface zal vooral de interface besproken worden. 

In het navolgende wordt elk type kort belicht. In de bespreking van de Java Collections Framework 

(L5.3) wordt het gebruik nader toegelicht. 

De Set is eigenlijk de wiskundige vorm van een verzameling. Er kunnen Objecten geplaatst worden 

en weer verwijderd. Tevens kan gekeken worden of een object al in de Set zit. Hiernaast zie je een 

eenvoudige interface zoals dat voor een Set kan gelden. Voor 

de notatie is UML gebruikt. Deze Set interface is niet die zoals 

 

Set 

in de Java Collection Framework is gedefinieerd, maar bevat 

Set 

add(element 

slechts een subset van de functionaliteit. 

add(element : : Object) : : void 

contains(element : : Object) : : boolean 

remove(element : : Object) : : void 

Er geld dat een object maar één keer in een Set mag 

isEmpty() : : boolean 

voorkomen. Als we dus objecten gaan plaatsen moeten we er size() : : int int 

dus zeker zijn dat het obejct niet al geplaatst is, eventueel eerst iterator() : : Iterator 

controleren met de methode contains. Voor het bepalen of een 

object gelijk is aan een al eerder geplaatst object, wordt in de HashSet implementatie gebruik 

gemaakt van een combinatie van de functies hashcode en equals een object. Dus niet op 

referentiebasis. Zie hiervoor L5.3. Wil je dus eigen klasses in een Set plaatsen, moet je dus deze 

methoden ook implementeren. Een class als de String heeft dit al. 

In de JCF kent de Set één implementatie , de HashSet. Deze implementatie gebruikt zg hashing 

om de elementen te beheren. Zie ook Computer Science (Brooksheare) L8.4. De Set is 

ook een onderdeel van de Java Collections Framework. 

83

IG9OGO 


Een voorbeeld van gebruik van de Set met de implementatie HashSet: 

Class SuperMarkt 

import java.util.Set; 

import java.util.HashSet; 

import java.util.Iterator; 

public class SuperMarkt { 


private Set artikelen = new HashSet(); 

public SuperMarkt(String deNaam) { 


} 

// een aantal methoden zijn weggelaten 

public void nieuwArtikel(String naam, String code, double prijs) { 

// !artikelCodeBestaat 

Artikel artikel = new Artikel(naam, code, prijs); 

artikelen.add(artikel); 

} 

public void remove(String code} { 

// artikelcode bestaat 

Artikel artikel = getArtikel(code); 

artikelen.remove(artikel); 

} 

public void aanvullenVoorraden() { 

// codeBestaat == true; 

Iterator i = artikelen.iterator(); 

Artikel artikel; 

while (i.hasNext()) { 

artikel = (Artikel)i.next(); 

if (artikel.onderMinimumVoorraad()) { 

bestel(artikel); 

} 

} 

} 

public boolean codeBestaat(String code) { // controlefunctie voor gui 

// code != null 



boolean gevonden = false; 

while (i.hasNext() && !gevonden) { 


if (code.equals(artikel.getCode())) { 

gevonden = true; 

} 

} 

return gevonden; 

} 

private Artikel getArtikel(String code) { 



Artikel artikel = null; 

boolean gevonden = false; 

while (i.hasNext() && !gevonden) { 


if (code.equals(artikel.getCode())) { 

gevonden = true; 

} 

} 

return artikel; 

} 

} // einde class Supermarkt 

84

L5.2.2 Map 

Map 

IG9OGO 

Map.Entry 

Map.Entry 

Map.Entry 


Een sleutel is een uniek identificatie/key- object voor een 

bepaald value- object zoals bijvoorbeeld het isbn- nummer 

voor een boek of een sofinummer van een werknemer. Het 

begrip key of sleutel kennen we ook bij databases. 

Bij een map wordt gesproken van het plaatsen van een value 

onder zijn key. De key wordt ook weer gebruik om het value 

bij een bepaalde key weer te benaderen. Dit kan vrij efficient 

zijn 

Key 

Value 

Key 

Value 

Key 

Value 

Terwijl een key altijd uniek is, kan een value wel onder 

meerdere keys in de map staan. 

Het objectdiagram toont hoe een drietal key/value, 

gebundeld in een map-entry, in de map staan. Elke 

map entry is uniek omdat elke key/value combinatie 

uniek is. De Map is dus een Set van entry’s. 

De Map is opgenomen als interface in de JCF en kent 

een implementatie HashMap. Onderstaand voorbeeld, 

analoog aan het voorbeeld bij de Set laat het gebruik 

zien in de Supermarkt. 

Interessant is bij de Map het gebruik van de iterator. Daar een Map in principe key/value entrys 

bevat, kun je niet rechtstreeks een iterator opvragen. Wel kun je een iterator van de keys of van de 

values opvragen door eerst alleen de keys of alleen de values als collectie op te vragen. Daarna 

kun je de iterator bemachtigen. 

Toevoegen aan een Map gaat als volgt. We gaan uit van een map van boeken 

Map boeken = new HashMap(); 

String isbn = “0-13-766957-7”; 

String titel = “Core Java 1.1 Volume 1 – Fundamentals” 

String schrijver = “Cay S. Horstmann”; 

Boek boek = new Boek(isbn, titel, schrijver); 

boeken.put(isbn, boek); // gebruik isbn als key voor het boek 

Benaderen gaat ook via de key 

String isbn = “0-13-766957-7”; 

Boek boek = (Boek)boeken.get(isbn); 

Verwijderen gaat ook weer met de key. De key mét de value (entry) worden uit de map verwijderd. 

String isbn = “0-13-766957-7”; 

boeken.remove(isbn); 

Controle op aanwezigheid kan voor de key én voor de value 

String isbn = “0-13-766957-7”; 

Boolean keyAanwezig = boeken.containsKey(isbn); 

Boolean valueAanwezig = boeken.containsValue(boek); 

Verkrijgen van de iterators 

Iterator keysIterator = boeken.keySet().iterator() 

Iterator valuesIterator = boeken.values().iterator(); 

 

Map 

put(key : : Object, value : : Object) : : void 

containsKey(key : : Object) : : boolean 

containsValue(value : : Object) : : boolean 

remove(key : : Object) : : void 

get(key : : Object) : : Object 


size() : : int int 

iterator() : : Iterator 

85

IG9OGO 


Een voorbeeld van gebruik van de Map met de implementatie HashMap 

Class SuperMarkt 

import java.util.Map; 

import java.util.HashMap; 

import java.util.Iterator; 

public class SuperMarkt { 


private Map artikelen = new HashMap(); 

public SuperMarkt(String deNaam) { 


} 

// een aantal methoden zijn weggelaten 

public void nieuwArtikel(String naam, String code, double prijs) { 

// !artikelCodeBestaat 

Artikel artikel = new Artikel(naam, code, prijs); 

artikelen.put(code, artikel); //zet artikel onder code weg 

} 

public void remove(String code} { 

// artikelcode bestaat 

artikelen.remove(code); 

} 

public void verkoop(String code, int aantal) { 

// codeBestaat == true 

// artikelVoorraad > aantal 

Artikel artikel = (Artikel)artikelen.get(code); 

artikel.verlaagVoorraad(aantal); 

} 

public void aanvullenVoorraden() { 

Iterator i = artikelen.values().iterator(); 


while (i.hasNext()) { 


if (artikel.onderMinimumVoorraad()) { 

bestel(artikel); 

} 

} 

} 

public boolean codeBestaat(String code) { // controlefunctie voor gui 

// code != null 

return artikelen.containsKey(code); 

} 

private Artikel getArtikel(String code) { 


return (Artikel)artikelen.get(code); 

} 

} // einde class Supermarkt 

86

L5.2.3 List 

IG9OGO 


Een List of lijst beheert zijn objecten in een bepaalde volgorde, die, afhankelijk van de 

implementatie, te beïnvloeden is. Er is dus sprake van samenhang tussen de objecten. 

Vanuit NIAM duiden zinnen als ‘Huis met nummer 14 staat rechts van huis met nummer 16’, of 

‘Persoon Jan staat achter Persoon Piet’ op zo’n samenhang.. Dit wordt bij Taak 6 nader belicht. 

De volgorde is vaak niet een alfabetische sortering maar een volgorde op andere gronden. 

Bijvoorbeeld de huizen staan op nummer (1, 1a, 3, 5, 9, 9a) in de straat en tijdstip van aankomst in 

een rij voor de kassa. Taken in een project die achtereenvolgens moeten worden uitgevoerd, of 

een stapel kaarten waarbij je slechts vanaf de bovenkant dient te delen. Een adressenlijst ligt 

eventueel wel alfabetische volgorde. 

Duidelijk niet gesorteerd is een emmer met daarin knikkers, of een oerbos met bomen. 

Een lijstimplementatie kan er als volgt uitzien, het betreft hier een een SingleLinkedList ofook een 

enkel gelinkte lijst. Kenmerkend zijn de elementen die het te bewaren Object kennen maar ook het 

volgende element. Op deze manier kun je telkens elementen en objecten toevoegen en zo de lijst 

uitbreiden. Je kunt natuurlijk ook elementen (met object) verwijderen. Een Stack zou dit in zijn 

implementatie kunnen gebruiken, waarbij de head het bovenste element is. 

SingleLinkedList 

head 

Element 

Object 

next next next next 

Element Element Element 

element element element element element 


Object Object 

We kennen dus verschillende lijsten, waarbij het verschil tot uitdrukking komt in de beschikbare 

functionaliteit en de daaruit voortvloeiende wijze van onderhouden van de volgorde. We zullen een 

paar bekende doornemen…. 

In L6.3 en L 6.3.1 wordt een implementatie van de List uitgewerkt. 

Element 


87

L5.2.3.1 Stack 

IG9OGO 


De stack is een typisch voorbeeld van een lijst waarbij de 

toegang tot de elementen duidelijk beperkt is. 

peek() : Object 

Als voorbeeld van gebruik kan dienen een Stapel kratten waarbij 

pop() : void 

nieuwe kratten steeds bovenop worden geplaatst, het bovenste 

isEmpty() 

krat als enige toegankelijk is, en ook het bovenste krat als enige 

isEmpty() : boolean 

size() 

te verwijderen is. Door het bovenste krat telkens te verwijderen 

size() : int 

worden de onderliggen kratten weer toegankelijk. 

De Stack geeft een (minimale) interface zoals hiernaast is aangegeven. 

De methode push, duwt een object op de stack, terwijl de peek toegang geeft tot het bovenste 

element. Met pop kan het bovenste element van de stack afgestoten worden. 

Bij een stack spreekt met ook wel van ‘last in, first out’ of lifo. 

Een stack wordt ook veel in een computersysteem zelf gebruik, bijvoorbeeld om tussenwaarden 

van een berekening te bewaren en door de Java Virtuele Machine om parameters en lokale 

variabelen, tijdelijk, te bewaren. 

Een voorbeeld van een Stack en zijn implementatie. Overigens maakt deze stack (stapel) 

implementatie ‘handig’ gebruik van een al in java beschikbare class LinkedList. Zo kan men 

bijvoorbeeld ook een implementatie maken op basis van een Vector (VectorStack) of er voor 

kiezen om een geheel eigen implementatie te creëren (MyStack) of een stack die op schijf wordt 

bijgehouden (FileStack). 

public interface Stack { 

public void push(Object element); 

public void pop(); 

public Object peek(); 

public boolean isEmpty(); 

public int size(); 

} 

public class LinkedListStack implements Stack { 

private LinkedList elements = new LinkedList(); 

// zet het object boven op de stapel 

public void push(Object element) { 

elements.addLast(element); 

} 

//verwijder het bovenste element 

public void pop() { 

elements.removeLast(); 

} 

// kijk wat er bovenop de stapel ligt 

public Object peek() { 

return elements.getLast(); 

} 

public boolean isEmpty() { 

return elements.isEmpty(); 

} 

public int size() { 

return elements.size(); 

} 

} 

Je kunt je nu afvragen waarom je een ‘wrapper’ om de al 

 

Stack 

push(element : Object) : void 

 

Stack 



pop() : void 


size() : int 

LinkedListStack 

elements : LinkedList 



pop() : void 


size() : int 

beschikbare LinkedList zou leggen als deze al die functionaliteit al in zich heeft…. 

Welnu, de LinkedList is een soort manusje van alles. Je kunt er op allerlei manieren de elementen 

inzetten en verwijderen. Als uit een analyse volgt dat ik voor mijn toepassing de functionaliteit van 

een stack nodig heb, en niet meer dan dat, is een stack de betere keus omdat ik onbedoelde 

manipulatie kan voorkomen, en dus foutief gebruik, van de collectie in mijn programma, wat de 

robuustheid bevordert. 

88

L5.2.3.2 Queue 

IG9OGO 


Als er in een lijst sprake is dat geld ‘first in, first out’ of fifo (wie het eerst is, het eerst maalt) dan 

spreken we van een queue of een wachtrij. Dit kennen we van de rijen voor de kassa of de printopdrachten 

die via een netwerk worden uitgevoerd. Bij de queue kunnen aan het eind objecten 

worden toegevoegd. Benaderen en weghalen gebeurt aan het begin. Net als bij de stack wordt de 

samenhang van de objecten niet door de objecten zelf verzorgd maar door elementen. 

Ook de queue kent net als de stack een beperkte functionaliteit, opnieuw om foutief gebruik te 

voorkomen. Een voorbeeld van een Queue interface en implementatie staan hieronder. Opnieuw is 

er geimplementeerd op basis van een LinkedList 

public interface Queue { 

public void add(Object element); 

public Object get(); 

public void remove(); 

public boolean isEmpty(); 

public int size(); 

} 

public class LinkedListQueue implements Queue { 

private LinkedList elements = new LinkedList(); 

} 

L5.2.3.3 Sequence 

// voeg achter aan de Queue toe 

public void add(Object element) { 

elements.addLast(element); 

} 

// haal het eerste element 

public Object get() { 

return elements.getFirst(); 

} 

// verwijder het eerste element 

public void remove() { 

elements.removeFirst(); 

} 

public boolean isEmpty() { 

return elements.isEmpty(); 

} 

public int size() { 

return elements.size(); 

} 

De sequence beheert zijn elementen in een bepaalde volgorde en deze zijn dus alleen in die 

volgorde te benaderen. Je kunt dus niet even een element zomaar overslaan. In tegenstelling tot 

de stack en queue hoef je hier echter niet een object te 

verwijderen om bij de volgende te komen. Je kunt dus 

 

herhaaldelijk door de sequence lopen zonder deze te 

Sequence 

veranderen. Overigens wordt ook hier de samenhang tussen add(element : : Object) : : void 

de objecten verzorgd door elementen (ook wel entry’s). 

remove(element : : Object) : : void 

contains(element : : Object) : : void 

Het toevoegen van een object geschied ook weer achteraan. 

Het verwijderen van een bepaald object is overal mogelijk, dit 

in tegenstelling tot het verwijderen bij de stack en queue. 

 

Queue 

add(element : : Object) : : void 

get() : : Object 

remove() : : void 




Overigens zijn er meerdere definities van de sequence mogelijk. Volgens de JCF is de LinkedList 

een Sequence. Dit is er dan wel één met heel veel –niet sequence- functionaiteit. Wel kun je heel 

makkelijk een sequence op basis van een LinkedList implementeren. (zie voorbeelden bij stack en 

queue). 

Het doorlopen van een sequence geschiedt met een iterator, of ook een ListIterator in de JCF. 

89

L5.3 De Java Collections Framework (JCF) 

IG9OGO 


Nu we een aantal collecties al wat nader hebben bekenen kunnen we eens wat verder kijken naar 

de met Java 2 meegeleverde classes en interfaces. De JCF is nadrukkelijk gericht op het scheiden 

van implementatie en interface. Het kent dan ook een uitgebreide hierarchie van interfaces, welke 

uiteindelijk resulteren in een implementatie. De JCF-classes vindt je in de package java.util. 

Onderstaande class diagram laat de structuur van de JCF-interfaces met de bijbehorende 

implementaties zien. 

 

Set 

 

SortedSet 

 

Collection 

Collections – de interfaces 

 

List 

TreeSet HashSet LinkedList ArrayList 

 

Iterator 

 

ListIterator 

Collections – de implementaties 

 

Map 

 

SortedMap 

HashMap TreeMap 

90

L5.3.1 Interface Collection 

IG9OGO 


In de Collection interface zijn de gemeenschappelijkheden van 

de Set en de List neergelegd. Zo kun je Objecten toevoegen, 

controleren op aanwezigheid, verwijderen, controleren of de 

collectie leeg is, de grootte opvragen en doorzoeken met behulp 

van een Iterator, zoals we al eerder hebben gezien bij de Set en 

de LinkedList. 

In nevenstaand diagram zie je dat er heel wat extra functionaliteit 

standaard in elke Collection is ingebouwd. Veel hiervan zul je 

vooreerst niet of nauwelijk gebruiken. Raadpleeg de JDK 1.2 API 

voor gedetailleerde informatie. 

L5.3.2 Interface Set 

De Set interface van de JCF erft van de Collection interface en is 

veel uitgebreider dat de eerder voorgestelde Set. Net zoals van 

de collection zul je ook hiervan in eerste instantie het meeste 

niet gebruiken. 

In de Java 2 API (JavaDoc documentatie) vind je gedetaileerde 

informatie bij elke beschikbare methode. 

L5.3.3 Interface SortedSet 

De Set kent nog een variant, de interface SortedSet. Waar een 

Set een ongeordende verzameling van objecten is, bewaart een 

SortedSet de objecten volgens een ordening. 

Deze ordening kan worden bepaald door de ‘natural ordering’, 

ofwel aan de hand van de compareTo methode uit de interface 

Comparable of met behulp van een Comparator, met de 

methode public int compare (Object o1, Object o2), een class 

welke de interface Comparator implementeert en twee objecten 

van het juiste zelfde type met elkaar vergelijkt. 

De Comparator biedt hierbij de meeste flexibiliteit, omdat 

meerdere comparators bij een object - type kunnen worden gedefinieerd, en verdient daarom 

veelal de voorkeur eventueel in combinatie met de ‘natural ordening’. 

Comparators kunnen ook voor andere doeleinden worden gebruikt zoals voor de sorteeralgoritmen 

in de class Collections uit de java.util package. 

De SortedSet heeft extra methoden 

beschikbaar, die naast dat ze informatie 

geven over de gebruikt ordening, gebruik 

maken van de ordening. In de API- 

documentatie van de SortedSet kun je dit 

nalezen. De ordening van de SortedSet vind 

je terug in de volgorde waarop de iterator de 

SortedSet doorloopt en de methode toString. 

Ook de first en last maken hiervan gebruik. 

 

Collection 

(from 

(from 

util) 

util) 


isEmpty () () : : boolean 

contains(o : : Object) : : boolean 


toArray () () : : Object[] 

toArray (a[] (a[] : : Object) : : Object[] 

add(o : : Object) : : boolean 

remov e(o e(o : : Object) : : boolean 

containsAll(c : : Collection) : : boolean 

addAll(c : : Collection) : : boolean 

remov eAll(c : : Collection) : : boolean 

retainAll(c : : Collection) : : boolean 

clear() : : v oid oid 

equals(o : : Object) : : boolean 

hashCode() : : int int 

 

Set Set 

(from 

(from 

util) 

util) 
















 

SortedSet 

(from 

(from 

util) 

util) 

comparator() : : Comparator 

subSet(f romElement : : Object, toElement : : Object) : : SortedSet 

headSet(toElement : : Object) : : SortedSet 

tailSet(f romElement : : Object) : : SortedSet 

ffirst() irst() : : Object 

last() : : Object 

De enige implementatie van een SortedSet in de JCF is de TreeSet. Deze implementatie geeft 

invulling aan de door de SortedSet interface voorgeschreven methoden en heeft nog een wat extra 

functionaliteit, welke implementatie gebonden is. (Zie volgende voorbeeld) 

91

L5.3.4 Interface Comparable, ‘Natural Ordering’ 

IG9OGO 


Het toepassen van de ‘natural order’ vereist dat de objecten die we plaatsen Comparable zijn dus 

het type moet het interface Comparable implementeren die de methode public int 

compareTo(Object o) voorschrijft. De methode geeft uitsluitsel of dit object kleiner, gelijk of groter 

dan het opgegeven object is. Het resultaat is een negatief, nul of positief getal. Bij gelijkheid, ofwel 

resultaat nul, moet dit overeenstemmen met een true resultaat van de equals methode. De 

‘natural ordering’ staat slechts één volgorde toe. 

Meer over de Comparable interface is te vinden in moduletaak 4. Ik het navolgende voorbeeld 

wordt het Comparable interface ook gebruikt. 

L5.3.5 Interface Comparator 

Een Comparator is een object van een type dat de interface Comparator implementeert. 

Gewoonlijk kunnen we bij het te ordenen object de gewenste Comparator opvragen. Deze levert 

telkens een Comparator met een andere compare methode. 

Het creëren van een Comparator kan slim worden gedaan met behulp van een zogenaamde 

anonymous inner class. Met andere woorden, we declareren een referentie van het type 

Comparator, kennen er een object aan toe van het interface - type Comparator, waarbij we ter 

plekke de implementatie van de methode compare definiëren. 

Dit bespaart het definiëren van extra classes, terwijl er wel class-files gegenereerd worden door de 

compiler (Artikel$1.class)) . Vaak is het handig om van een object type zowel zijn ‘natural ordering’ 

als ook extra Comparators te implementeren. 

In het volgende voorbeeld zie je een supermarkt, waar gebruik wordt gemaakt van een SortedSet 

om zijn artikelen in te beheren. De code - Comparator kan worden opgevraagd bij het Artikel door 

aanroep van de static methode getCodeComparator. 

Voorbeeld SortedSet en Comparator 

import java.util.SortedSet; 

import java.util.TreeSet; 

public class Supermarkt { 

} 


private SortedSet artikelen = new TreeSet(Artikel.getCodeComparator()); 

// private SortedSet artikelen = new TreeSet(); // natural ordening 

public Supermarkt(String deNaam) { 


} 

public void nieuwArtikel(int code, String naam, double prijs) { 

Artikel artikel = new Artikel(code, naam, prijs); 

artikelen.add(artikel); 

} 

public SortedSet getArtikelenMetGrotereCode(Artikel ditArtikel) { 

SortedSet gezochteArtikelen = artikelen.tailSet(ditArtikel); 

gezochteArtikelen.remove(ditArtikel); // verwijder deze 

return gezochteArtikelen; 

} 

public String toString() { 

return "Supermarkt " + naam + "\n" + artikelen; 

} 

// en nog veel meer methoden……… 

92

IG9OGO 


De Supermarkt maakt gebruik van de Class Artikel, welke ook naast de gebruikte code Comparator 

ook een naam- en een prijsComparator levert. Deze laatste twee zijn niet bruikbaar als Comparator 

voor de SortedSet, daar in de naam en prijs dubbelingen kunnen voorkomen, wat verlies van 

elementen in de Set zou veroorzaken. Je zou ze wel goed kunnen gebruiken in collecties waar wel 

dubbelingen mogen voorkomen zoals de List. Ook de diverse algoritmen uit de Collections class 

kunnen ervan gebruik maken. 

De code-comparator is daarentegen wel uniek en bruikbaar als ordening in de TreeSet. Bij de 

prijsComparator is het noodzakelijk om te zien dat de vergelijking opgaat tot op 2 decimalen. 

Kleinere verschillen worden door de afronding van de double naar int niet gedetecteerd. 

import java.util.Comparator; 

public class Artikel implements Comparable{ 

} 

private int code; 


private double prijs; 

public Artikel(int deCode, String deNaam, double dePrijs) { 

code = deCode; 


prijs = dePrijs; 

} 

public int compareTo(Object anderObject) { // interface Comparable 

Artikel anderArtikel = (Artikel)anderObject; 

return code - anderArtikel.code; 

} 

public static Comparator getCodeComparator() { 

Comparator codeComparator = new Comparator() { 

public int compare(Object eneObject, Object andereObject) { 

Artikel eneArtikel = (Artikel)eneObject; 

Artikel andereArtikel = (Artikel)andereObject; 

return eneArtikel.code - andereArtikel.code; 

} 

}; 

return codeComparator; 

} 

public static Comparator getNaamComparator() { 

Comparator naamComparator = new Comparator() { 




return eneArtikel.naam.compareTo(andereArtikel.naam); 

} 

}; 

return naamComparator; 

} 

public static Comparator getPrijsComparator() { 

return new ArtikelPrijsComparator(); 

} 

public boolean equals(Object anderObject) { 

Artikel anderArtikel = (Artikel)anderObject; 

return code == anderArtikel.code && 

naam.equals(andereArtikel.naam) && 

prijs == andereArtikel.prijs; 

} 

public int hashCode() { 

return code; //de unieke code volstaat als hashCode 

} 


return code + " : " + naam + " voor f " + prijs + "\n"; 

} 

// en nog veel meer methoden……… 

93

IG9OGO 


Het Artikel maakt als voorbeeld gebruik van de externe ArtikelPrijsComparator: 

import java.util.Comparator; 

public class ArtikelPrijsComparator implements Comparator { 

} 


// pre: eneObject instanceof Artikel && andereObject instanceof Artikel 



return (int)((eneArtikel.getPrijs() - andereArtikel.getPrijs())*100); 

} 

Het verdient aanbeveling om ook bij eigen implementaties waar ordening van objecten een rol 

spelen de Comparator interface te gebruiken. 

Overigens gaan alle comparators ervan uit dat de opgegeven objecten van het juiste type zijn en 

geven een ClassCastException indien dit niet het geval is. Er is hier dus sprake van een niet 

afgedwongen, middels asserties, maar wel gedocumenteerde pre-conditie. Zie hiervoor de APIdocumentatie 

bij de Comparator. 

L5.3.6 Interface Map 

De Map kent in de JCF en implementatie HashMap zoals we in L5.2 al hadden gezien, maar ook 

een variant, de SortedMap waarbinnen de keys van de map op orde worden gehouden conform 

de elementen in een SortedSet. De SortedMap kent een implementatie TreeMap. 

L5.3.7 Interface SortedMap 

Naast de Map interface is er, in analogie met de Set en SortedSet, de SortedMap welke zijn keys 

op orde houdt. Deze ordening wordt bepaald door de ‘natural ordering’ met de Comparable 

interface, of de meegegeven Comparator. Het gebruik van de interfaces Comparable en Compare 

is precies eender te gebruiken als bij de SortedSet. 

L5.3.8 Interface List 

Een (JCF)list bewaard zijn elementen in een vaste 

volgorde. Op een bepaalde plaats, aangeduid met een 

index, kun je elementen benaderen, tussenvoegen en 

verwijderen. Een volgorde wil zeker niet zeggen dat er 

sprake is van ordening. De volgorde van de elementen is 

volkomen afhankelijk door de wijze en volgorde van 

toevoegen en verwijderen. Een List kent dan ook geen 

sorted variant zoals de Set en Map. 

De (JCF)list lijkt qua omgang veel op een primitieve array 

omdat hij werkt met een index, maar dan wel een 

dynamische variant. Een kijkje in de source van de Listimplementatie 

ArrayList leert dat deze inderdaad is 

gebaseerd op een array van Objecten. Dit maakt dat deze 

implementatie vaak snel is, maar duur als het op het 

verwijderen van objecten, of juist het tussenvoegen ervan 

aankomt. Dan moet namelijk de array wordt opgeschoven 

om plaats te maken of een ontstaan gat te vullen. 

De LinkedList implementatie vanuit de object orientatie 

gezien een fraaier oplossing met Entry’s (inner class van 

LinkedList) welke de objecten bewaren, en verwijzen naar 

de vorige en volgende Entry. 

Dit komt overeen met de wijze waarop we in Moduletaak 6 

een eigen List variant gaan maken. Dit betreft dan 

bijvoorbeeld een Queue, Stack, een .Sequence of een 

Circular- List. 

 

List List 

(from 

(from 

util) 

util) 











addAll(index : : int, int, c : : Collection) : : boolean 






get(index : : int) int) : : Object 

set(index : : int, int, element : : Object) : : Object 

add(index : : int, int, element : : Object) : : v oid oid 

remov e(index : : int) int) : : Object 

indexOf (o (o : : Object) : : int int 

lastIndexOf (o (o : : Object) : : int int 

listIterator() : : ListIterator 

listIterator(index : : int) int) : : ListIterator 

subList(f romIndex : : int, int, toIndex : : int) int) : : List 

List 

94

L5.3.9 De Collections class 

IG9OGO 


Buiten de leerstof van deze module taak valt de Collections class met zijn algoritmen voor gebruik 

met de diverse collecties. Je vind deze class ook in de java.util package. Nadere informatie kun je 

vinden in de java 2 - api-documentatie . 

L5.3.10 Legacy, Vector & Hashtable 

De Java Collections Framework was onder eerdere versies van java, dat wil zeggen vóór het 

verschijnen van het Java Platform 2 (of ook jdk1.2) niet beschikbaar, tenzij men zelf de collectionpackage 

aan de 1.1 packages had toegevoegd. 

De plaats voor de import van deze extra collections- package was een andere dan de huidige, de 

java.utils- package. Dit levert nu nog soms problemen op. 

In java 1.0 en 1.1 was standaard uiteraard de array als primitieve- niet OO- oplossing beschikbaar, 

maar ook de Vector (List) en de HashTable (Map). 

De Vector komt qua functionaliteit overeen met de ArrayList en wordt vaak gebruikt als een 

manusje van alles (tricky), terwijl de Hashtable te herkennen is in de HaskMap. 

Orgineel waren bij deze classes de implementatie niet gescheiden van de interface, het principe 

waarop in de JCF zwaar wordt geleund. Met ingang van java 2, hebben de Vector en Hashtable 

een opwaardering gekregen door ze de nodige interfaces te laten implementeren. De Vector 

implementeert de List en de Hashtable de Map. 

Deze aanpassing is een tegemoetkoming aan oude java versies, maar moet worden gezien als 

verouderd. Ze staan echter (nog) niet als depricated aangemerkt. Desondanks is het over het 

algemeen wenselijk om de universelere ‘nieuwe’ JCF-structuur te gebruiken. 

95

L5.4 De juiste collectie kiezen 

IG9OGO 


We hebben een aantal collectievormen gezien en er ontstaan nu diverse keuzemogelijkheden. 

Welke nu te kiezen is afhankelijk van het resultaat van je analyse. In principe kies je allereerst voor 

het meest geschikte interface op basis van de typische eigenschappen, welke volgen uit een 

analyse. 

Daarna kies je pas de feitelijke implementatie op basis van efficiëntie. Zo is het van belang of een 

applicatie hebt die vaak wijzigingen aanbrengt in de collectie of juist relatief vaak in de collectie 

zoekt. 

Een paar hints: 

• Is er geen sprake van specifieke eigenschappen, maar slechts een serie objecten, dan voldoen 

de Collection met implementatie HashSet, mits er geen dubbelingen voorkomen. Is dit wel het 

geval, kies dan een ArrayList. Wordt er veel tussengevoegd en verwijderd dan verdient de 

LnikedList de voorkeur boven de ArrayList. 

• Mogen er duidelijk geen dubbelingen voorkomen, neem dan de Set met als implementatie de 

HashSet. 

• Is er duidelijk sprake van een volgorde of rij door een feittype als ‘na Persoon volgt 

Persoon ’, dan is een List, met implementatie ArrayList vaak een juiste keuze. Wordt er 

veel tussengevoegd en verwijderd dan verdient de LnikedList de voorkeur boven de ArrayList. 

• Als er een unieke key te vinden is bij het te beheren object-type dan ligt de keuze voor een 

Map voor de hand. Dit bied snelle toegang tot de values. 

• Sorteren helpt vaak bij het snel opzoeken van gegevens, maar kosten extra tijd bij wijzigingen. 

Je hebt de keuze tussen SortedSet en SortedMap. Een SortedList bestaat niet (waarom ?) 

Tabel 1, Implementaies van de diverse interfaces in de JCF 

Interfaces 

Implementaties 

HashTable Resizable array Balanced Tree LinkedList 

Set HashSet TreeSet 

List ArrayList LinkedList 

Map HashMap TreeMap 

Als er geen passende collection te vinden is, dan kun je natuurlijk je eigen variant schrijven, al dan 

niet gebaseerd op de beschikbare abstracte classes van de JCF. Voor elk van de interface 

Collection, Set, List en Map is er minimaal één beschikbaar. Bestudeer hiertoe de APIdocumentatie. 

Het verdient altijd de voorkeur om ook voor je eigen implementaties gebruik te maken van een 

interface, één van de beschikbare of een nieuw gedefinieerde. 

96

L5.5 Gelijkheid van objecten 

IG9OGO 


De HashSet staat slechts één keer hetzelfde object toe, het is tenslotte een verzameling. Alleen 

wanneer is nu een object gelijk aan een ander. Als het echt hetzelfde object is, of als de inhoud 

gelijk is. 

We kunnen zelf bepalen of het ene Object inhoudelijk gelijk is aan het andere door zelf de nodige 

functionaliteit aan te leveren in de class. 

De HashSet bepaald namelijk aan de hand van de hashcode van het object , welke op te vragen is 

met de methode int hashCode(), en daarna door aanroep van de methode boolean 

equals(Object), of een object gelijk is.. 

Als we dus zelf in onze classes de gelijkheid voor onder andere de HashSet willen aangeven, 

moeten we hier dus een eigen hashCode en equals methoden implementeren. In de o.a. de String 

is dit dit toegepast. Vandaar dat we ook maar één keer een String met dezelfde inhoud in de 

HashSet kunnen plaatsen. 

De hashcode is een integer representatie van het object, wat niet uniek hoeft te zijn. Dit is 

standaard het referentie adres, maar bij een String is deze bijvoorbeeld afgeleid van de inhoud 

(characters). Als we bijvoorbeeld bij de Lezer van de Bieb een int lezersnummer kennen kan dit 

een prima hashCode leveren. De hashcode hoeft niet uniek te zijn, maar bijvoorbeeld voor de 

HashSet, slechts een grove selectie te vormen voordat de duurdere equals zijn werk kan doen. 

De methode equals bepaald of een object op inhoud gelijk wordt beschouwd in plaats van de 

referentie vergelijking (eneObject == andereObject wordt eneObject.equals(andereObject)). 

Het volgende voorbeeld bevat methoden voor een class Adres. Als zowel de hashCode gelijk is en 

de equals geeft true gaat de HastSet ervan uit dat de objecten gelijk zijn. Dit is van belang bij o.a. 

de methode contains maar ook add en remove. Implementeren we deze methoden niet, dan is elk 

object voor de HashSet verschillend. 

public class Adres { 

private String postCode; 

private String straat; 

private String huisNummer; 

private String woonPlaats; 

} 

// bevat diversen methoden 

public int hashCode() { 

return postCode.hashCode(); // gebruik de hashCode van de postCode 

} 

public boolean equals(Object object) { 

boolean gelijk = false; 

if (object instanceof Adres) { // juiste type ? 

Adres adres = (Adres)object; // casten neer juiste type 

gelijk = postCode.equals(object.postCode) && 

huisNummer.equals(object.huisNummer); 

} 

return gelijk; 

} 

Het is van belang de gelijkheid van objecten goed te documenteren om fouten te voorkomen, zoals 

onbedoeld verdwijnen van objecten. 

97

L5.6 Optional operations 

IG9OGO 

Modulehandleiding Object georiënteerd ontwerpen 

De Java Collection Framework kent zogenaamde optional operations. Dit wil zeggen dat nog 

steeds verplicht is om deze methoden in een implementatie op te nemen, maar men het kan 

verkiezen niet meer te doen dan het ‘at runtime’ opwerpen van een 

UnsupportedOperationException. De java-compiler detecteert overigens de onterechte aanroep 

van een unsupported operation niet. 

Wil men gebruik maken van zo’n operatie in een collectie, dan dient met vooraf zich te vergewissen 

dat deze operaties ook daadwerkelijk ‘supported’ zijn. Eventueel zal men de aanroep van zo’n 

optional methode moeten vatten in een ‘try en catch’ blok. Dit vereist dus een bewust gebruik van 

bepaalde methoden en dat zal goed gedocumenteerd moeten worden. Men kan dus niet 

zondermeer tegen de gekozen interface aan programmeren. 

Anderzijds is zeker ook nuttig om, voor zover mogelijk, bij implementatie alle door het interface 

vereiste methoden volledig te implementeren, teneinde vreemde, buggie constructies te vermijden. 

De standaard collection implementaties maken wel van deze optional opraties gebruik, 

bijvoorbeeld bij de HashSet de methoden addAll en RemoveAll. 

Deze optionele operaties zijn geïntroduceerd om het Framework eenvoudig te houden en niet voor 

elke variant een interface te hoeven definiëren. Hierbij kun je denken aan read- only (immutable of 

unmodifiable) collections waarbij bijvoorbeeld de add en de remove geen uitwerking dienen te 

hebben. De in de JCF gekozen oplossing is enigszins omstreden. 

Praktisch gezien is er best wel mee te leven, mits men zich goed realiseert wat wel en niet te 

gebruiken. 

98


IG9OGO 


Oefening 5.1: 

Kies uit de volgende datastructuren de best passendevoor elk van de genoemde toepassingen. 

Data structuren waaruit gekozen kan worden : Set, Map, Array, Queue, Sequence, Stack. 

1. Een parkeerterrein met honderd plaatsen en opeenvolgende nummers. 

2. Werkplaatshandboek waarin achtereenvolgens te verrichten handelingen staan. 

3. Kratten worden op elkaar gezet. Om bijvoorbeeld het onderste krat te bereiken moet men de 

kratten er één voor één afhalen. 

4. Adressenboek waarin aan de hand van postcode en huisnummer, een naam en adres 

worden gevonden 

5. Een dienstverlenend bedrijf krijgt storingsmeldingen binnen welke op volgorde van 

binnenkomst worden afgehandeld. 

6. Een aantal achter elkaar staande mensen voor het loket van een stadion. 

7. Een eindige geschakelde ketting , welke aan één zijde bevestigd is. 

8. Een telefoonboek (voor één plaats). 

9. Een emmer met loten waaruit het winnende lot kan worden gevist. 

10. Een lijst met spelers van een voetbalelftal, waarbij voor elk van de 25 rugnummers de speler, 

of juist geen speler , wordt genoemd. 

Oefening 5.2: 

Herschrijf de oefening Bank van het tweede Java Module, maar nu gebruik makend van één Map. 

Bedenkt dat een Map eigenlijk twee collecties bevat, Eén van de keys en één van de values 

Het betreft die bank met een verzameling rekeninghouders met rekeningen. Een rekeninghouder 

kan slechts één rekening hebben. Bedenk de methoden maakRekening, maakRekeninghouder, 

KoppelRekeningAanHouder. 

• Tot welke verplichtingen leidt het gebruik van de Map hier ? 

• Welke problemen kom je tegen. 

• Hoe zou je de Bank realiseren met meer Map’s (2 of 3) 

Oefening 5.3: 

Schrijf zelf een Sequence implementatie op de manier zoals dit ook voor de stack en de queue in 

de voolbeelden was gedaan, op basis van een LinkedList. Schrijf ook een eenvoudige test. 

99


IG9OGO 


Geef antwoord op de volgende vragen 

1. Wat is het verschil tussen een Set en een Map 

2. Waartoe dient een interface in de Jaca Collections Classes 

3. Welke collection interface kies in als ik studenten met studentnummer wil gaan registreren. 

4. Hoe kan ik in een collectie door de elementen zoeken (bijvoorbeeld een Set of een LinkedList). 

5. Waarom kan ik bij een map niet direct een iterator opvragen 

6. Welke collectie interface en/of implementatie schiet je te binnen bij een parkeerplaats met 

genummerde plaatsen. 

7. Hoe verwijder in een object uit een Set 

8. Hoe gaat een en ander in het werk als ik een object ‘uit’ een Map haal. 

9. Waarom zou ik er voor kiezen om een wrapper rond een bestaande implementatie te maken 

met een functionele beperktere interface in plaats van de beschikbare interfaces (zoals List). 

100


Voorkennis 

Taakdoel 

Oriëntatie 

Verwerking 

Verdieping 

Zelftoets 

IG9OGO 


Moduletaak 6: Ontwerpen van collections 




• De student kan vanuit de analyse standaard datastructuren herkennen. 

• De student is in staat om zelf een implementatie van een datastructuur mbv een gelinkte lijst te 

maken 

In het voorgaande hebben we gezien wat er beschikbaar is aan collections. We moeten echter 

vanuit onze NIAM- analyse in staat zijn te oordelen over welk collectie – interface, bijvoorbeeld uit 

de Java Colections Framework, het beste past. Vaak is het herkennen een structuur in delen in het 

IGD voldoende om tot een keuze te komen. 

Bestudeer daartoe de navolgende leestekst Ontwerpen van collections L6.0 t/m L6.3.1 

Om dieper in de structuur van een collection te duiken implementeren we zelf ‘from scratch’ zelf 

een collectie. 

Werk daartoe oefening 6.3 uit achter het systeem. 

Verder wordt een selectie van de oefeningen op het werkcollege uitgevoerd. 

Om nog wat vertrouwder te raken met het implementeren van gelinkte lijsten, kun je de 

bovengenoemde opdracht ook uitvoeren met behulp van een LinkedList. 

Daarnaast is het bestuderen van de API-documentatie en Java Tutorial bij Javasoft aan te raden. 

Eventueel kun je eens een kijkje werpen in de sources van de java- classes. 

Maak ter afronding van deze moduletaak de zelftoets en controleer zelf je uitwerkingen met 

die in de bijlage van deze modulehandleiding. Herhaal zonodig enkele oefeningen of vraag de 

docent om extra oefenmateriaal. 

101

L6.0 Samenvatting 

IG9OGO 


LEESTEKST bij moduletaak 6 : Ontwerpen van collections 

• Analyse leidend tot keuze van een Set 

• Analyse leidend tot keuze van een Map 

• Analyse leidend tot de keuze van een Stack 

• Analyse leidend tot de keuze van een Queue 

• Analyse leidend tot de keuze van een Sequence 

• Analyse en implementatie van een Stack 

• Analyse en implementatie van een LinkedList 

L6.1 Afleidingen uit de NIAM analyse 

Vanuit het NIAM –IGD kun je diverse typen van collecties herkennen. In het navolgende geven we 

een aantal voorbeelden die leiden tot een bepaalde keuze. 

L6.1.1 Analyse leidend tot de keuze van een Set 

In NIAM is elk object uniek, twee keer hetzelfde object komt niet voor. Dit betekent dat vanuit NIAM 

elke n op n relatie, met 2 deelnemende object- typen in principe leidt tot het gebruik van een Set. 

• Één op meer relatie 

A B 

A B 

dit leidt tot een Set van Bees in A, en één A in B 

• meer-op-meer relatie 

A B 

A B 

dit leidt tot een Set van Bees in A, en een Set van Aas in B 

Keuze voor een andere collectie- vorm kan op basis van gewenst gedrag wat niet direct volgt uit de 

NIAM analyse. 

• Indien de volgorde van de elementen van belang is kan worden gekozen voor een List variant 

• Als er van het objecttype een unieke identificator beschikbaar is, is het vaak handig om deze 

te kiezen als key voor een Map. 

Als het om een of andere reden nodig of gunstig is om de elementen gesorteerd te houden is een 

SortedSet de aangewezen keuze. 

102

L6.1.2 Analyse leidend tot de keuze van een Map . 

IG9OGO 


De keuze van een Map volgt meestal uit het gebruik van een collection met random access. 

Voorwaarde is dat er een identificerende (unieke) key beschikbaar is. 

Soms volgt een Map direct uit de analyse: 

Bank Rekening 

In afwijking van de standaard regels voor ternaire feittypen (nominaliseren) kan dit voorbeeld leiden 

tot een Map met rekeningen met key/value is Persoon/Rekening bij een Bank, maar ook tot een 

Map met personen met key/value is Rekening/Persoon. Let hierbij op de uniciteiten. 

Een schema dat tot een zelfde structuur met een Map kan leiden: 

Bank 

B 

Persoon 

P 

R 

Bij heeft de 

Rekeninghouder 

B 

R 

Persoon 

is bij rekeninghouder 

Rekening 

Ondanks de aangegeven nominalisatie in bovenstaand IGD, welke gewoonlijk tot een aparte class 

leidt, kun je hier ook gebruik maken van een Map: 

• Bank heeft onder sleutel Persoon een Rekening 

• Persoon heeft onder sleutel Bank een Rekening 

In het algemeen zul je het gebruik, voor zover niet direct uit het IGD af te leiden, moeten kiezen 

aan de hand van het gebruik van de collectie. Vaak is het voorhanden zijn van een identificerende 

key een hint. 

Voorbeelden: 

• Unieke naam bij een persoon 

• Klantcode bij een bank 

• Isbn nummer van een boek 

• Streepjescode van een artikel 

• Wegnummer van de auto(snel)weg 

• Postcode met huisnummer bij de post (benodigd daarvoor een extra key-class) 

Implementatie van de Map interface in de JCF is o.a. de HashMap. Zijn voorganger, de Hashtable 

is intussen (JDK 1.2) ook voorzien van de Map interface. 

Rh 

P 

heeft 

103

L6.1.3 Analyse leidend tot keuze van een Stack 

IG9OGO 


Alle IGD’s voor collectie met een volgorde (Sequence, Stack, Queue en List ) hebben een 

vergelijkbaar schema. 

Onderstaand schema leidt op basis van het feittype “ ligt bovenop ” tot de keuze van 

een stack 

Pallet Krat 

Eigenaar 

P K 

Op staat 

Het verschil in keuze tussen een Sequence, Stack, Queue of List zit hem vooral in de verwoording 

van de feittypen. 

Typisch voor een Stack zijn verwoordingen als 

• “staat bovenop” 

• “heeft als bovenste” 

K1 K2 

ligt bovenop 

K E 

is eigendom van 

K I 

bevat 

Inhoud 

104

L6.1.4 Analyse leidend tot de keuze van een queue 

IG9OGO 


Onderstaand schema leidt tot de keuze van een queue 

Kassa Klant 

Artikelen 

A K 

staat vooraan bij 

A K 

staat achteraan bij 

K1 K2 

K A 

heeft 

staat voor 

Opnieuw is de verwoording van het feittype hier van belang. Typisch voor een Queue zijn 

verwoordingen als 

• “staat vooraan” of 

• “staat achteraan” 

• “staat achter” 

De uiteindelijke keuze hangt af van wat met de collection gedaan wordt: 

• waar moet een nieuw object worden toegevoegd? 

• hoe moet de collection doorlopen kunnen worden? 

• etc. 

105

IG9OGO 


L6.1.5 Analyse leidend tot de keuze van een Sequence . 

Als uit de analyse een bepaalde volgorde tussen de elementen volgt, zoals in onderstaand 

voorbeeld zal de keuze van een lijst-vorm volgen. Dat kan dus zijn een Stack, Queue, Sequence of 

een List uit de JCF. Welke keuze je maakt is afhankelijk van de vereiste functionaliteit. 

Voorbeeld voor keuze van een Sequence 

Of 

Filmrol Foto 

Nummer 

R F 

bevat 

F N 

volgt op 

Foto 

Herkenningspunten voor de Sequence zijn 

• het feittype “ volgt op ” 

• de een-op-een relatie tussen elkaar opvolgende foto’s 

Voorgaande leidt tot de volgende implementatiekeuzes 

• In Filmrolletje een Sequence van foto’s 

• In Foto een nummer en een Onderwerp 

F N 

heeft 

F O 

betreft 

Onderwerp 

FolmRolletje Nummer 

R N 

Op staat foto met 

F1 F2 

komt na 

F O 

betreft 

Onderwerp 

Dit betekent dat de volgorde van de foto’s niet gehandhaafd blijft door de foto’s zelf maar deze taak 

wordt overgelaten (gedelegeerd) aan de Sequence. De feittypen “ volgt op ” en “ 

heeft als eerste ” vind je dus niet terug in de de fabeelding van een Foto- class ! 

Je maakt dus nooit een Foto met een referentie naar een volgende foto, of een boek dat verwijst 

naar een volgend boek. 

106

IG9OGO 


In het volgende geval kan eveneens tot gebruik van een Sequence worden besloten: 

Boekenplank Boek 

Auteur 

P B 

Op staat 

B1 B2 

staat naast 

• In Boekenplank leidt dit tot een Sequence van boeken 

• In Boek een Auteur en een Onderwerp 

B A 

En dan niet bij Boek opnemen : “volgend boek” of “vorig boek” ! 

Dit zou slecht (en dus FOUT) ontwerp zijn. 

is geschreven door 

B O 

betreft 

Onderwerp 

De List interface van de JCF lijkt veel op een Sequence, echter een echte sequence heeft een veel 

beperktere interface, wat robuustheid kan bevorderen. 

107

L6.2 Implementatie van een stack 

IG9OGO 


De in taak 5 getoonde implementatie van een stack was gebaseerd op de LinkedList. Het vormde 

een wrapper om deze beschikbare implementatie. Dit is handig maar verschaft niet veel inzicht in 

de werking van een LinkedList. In deze paragraaf gaan we een Stack implementatie ‘from scratch’ 

opzetten. 

We beginnen met een voorbeeld van een toepassing van de stack. In dit voorbeeld wordt de stack 

gebruikt voor het opslaan van tussenwaarden bij een berekening. 

Rekenmachine die RPN gebruikt. 

RPN: Reverse Polish Notation: Manier van opschrijven van rekenkundige bewerkingen zonder 

haakjes 

Voorbeeld: (3 + (5 + 8)) * (2 + 4) wordt geschreven als: 3 5 8 + + 2 4 + * 

De bewerking wordt uitgevoerd met een stack: 

enter 

3 

In diverse gevallen in de informatica worden stacks gebruikt. 

Bijvoorbeeld bij het onthouden van de toestand van een proces, die weer een ander proces kan 

aanroepen. 

L6.2.1 De werking van de stack 

3 

enter 

5 

5 

3 

enter 

8 

8 

5 

3 

+ 

13 

3 

+ 

16 

enter 

2 

Bij een stack worden de objecten aan de bovenkant toegevoegd (push) en daar ook er weer 

afgehaald (pop). Tevens kan het bovenste object worden benaderd (peek). Let wel, dit is zoals de 

stack lijkt te werken. Na analyse weten we we pas hoe hij intern is georganiseerd. 

Stack 

Stack 

bovenste 




Werking van put en remove op een 

stack 

bovenste 





2 

16 

Start Na toevoegen van een object 

(push) 

enter 

4 

4 

2 

16 

+ 

6 

16 

Stack 

bovenste 

* 

96 




Na verwijderen van een object 

(pop) 

108

L6.2.2 Analyse van de Stack 

IG9OGO 


Ten einde een ontwerp te kunnen maken voor een (generieke) stack, analyseren we eerst de stack 

mbv NIAM. Het resultaat geven we weer in een IGD 

De volgende schets levert ons de nodige voorbeelden. Let op, de elementen van de stack bevatten 

de objecten (getallen) en zijn wel genummerd maar liggen niet op die volgorde. 

De nummering naast de elementen is voor de identificatie van de elementen. De getallen in de 

elementen staan voor het object. Ons voorbeeld kent twee stacks. 

S2 

5 

3 

Als we dit voorbeeld analyseren kan het volgend IGD het produkt zijn. 

Stack 

has as 

topmost 

S2 

S3 

S E 

2 of S2 

2 of S3 

2 

1 

Element 

S3 

of Number 

S N 

has an element with 

S2 

S2 

S3 

1 

2 

1 

E1 E2 

is on 

top of 

2 of S2 1 of S2 

1 of S3 3 of S3 

2 of S3 1 of S3 

8 

5 

3 

E 

2 

1 

3 

O 

8 

5 

3 


contains 

2 of S3 

1 of S3 

3 of S3 

109

IG9OGO 


Omzetting van het IGD naar classes en attributen levert het volgende op. 

• Class Stack 

• Set elements 

• Element topElement 

• Class Element 

• Stack hoortByStack 

• Stack topOfStack (alleen als hij topelement is) 

• Element elementBelow 

• Element elementAbove 

• Object object 

• Number number 

• Class Number……. 

• Class Object……. (de te plaatsen objecten) 

We kunnen dit nog vereenvoudigen: 

• Het object is een Java-Object, voor de op de stack te plaatsen objecten 

• Nummer kan vervallen (object referentie van een Element maakt hem al uniek) 

• De stack hoeft alleen het bovenste element te kennen. De rest ligt daaronder. 

• Een Element hoeft niets te weten van de class Stack 

• Een element hoeft niet te weten welk element boven hem ligt 

• Een object weet niets van de stack (Java- Object) 

Er blijft dan over: 

• Class Stack 

• Element topElement 


• Element elementBelow 


Zie ook nevenstaand class diagram 

topElement 

Stack Element 

object 


elementBelow 

Een object diagram, na respectievelijke toevoeging van de objecten Mies, Noot en Aap ziet er dan 

als volgt uit. 

Stack 

topElement 

elementBelow 

elementBelow 

Element 

Element 

Element 

object 

object 

object 


Aap 


Noot 


Mies 

110

L6.2.3 Implementatie van de classes 

IG9OGO 


Nu weten we nagenoeg alles wat we nodig hebben om te gaan implementeren. In Taak 5 is 

gesteld dat het voor de flexibiliteit handig is om een interface te maken, waarvoor we de 

implementatie maken. Dit is dus een extra ontwerpstap, welke je zichtbaar maakt in het class- 

diagram.. We maken dus een interface Stack, met een implementatie LinkedListStack (hadden we 

die niet al in taak 5 gezien ?) 

Het class diagram ziet er dan als volgt uit: 

 

Stack 

push(object : Object) : void 


pop() : void 

LinkedListStack 

push(object : Object) : void 


pop() : void 

topElement 

De methoden push en pop zijn mogelijk wat lastig te doorzien. De volgorde van handelen is 

kritisch, je raakt je hele stack kwijt als het niet klopt. 

1. Eerst de oude stack veilig stellen in het nieuwe element 

2. Daarna pas het topelement op het nieuwe 

public void push(Object object) { 

Element element = new Element(); // een element om het object te beheren 

element.setElementBelow(topElement); // dit element krijgt de huisige 

// bovenste als onderliggende 

element.setObject(object); // plaats het object in dit element 

topElement = element; // nieuwe element is nu bovenste 

} 

public Object peek() { 

return topElement.getObject(); 

} 

Element 

getObject() : Object 

setObject(object : Object) : void 

getElementBelow() : Element 

setElementBelow(element : Element) : void 


public void pop() { 

topElement = topElement.getElementBelow(); // huidige top overslaan 

// de garbagecollector doet de rest 

} 

Voor het inzichtelijk maken van deze acties, is het altijd handig om voor jezelf object plaatjes te 

maken, welke je dat stap voor stap opbouwd. Dezelfde strategie van toevoegen en verwijderen kun 

je ook gebruiken bij het implementeren van LinkedList versies van de Queue en de Sequence (en 

andere List-vormen). 

object 

elementBelow 

111

L6.3 Analyse van een lijst 

IG9OGO 


Een lijst is een reeks objecten. Deze reeks objecten heeft een bepaalde volgorde. Deze volgorde is 

bepaald door de plaats waar en tijdvolgorde waarin we in de verschillende objecten toevoegen en 

verwijderen. Voor de implementatie wordt gebruik gemaakt van elementen die de te plaatsen 

elementen beheren, teneinde te voorkomen dat objecten die we ooit in een lijst kwijt willen zelf 

deze functionaliteit moeten herbergen. We hebben nu nog de keuze om een dubbel of enkel 

gelinkte lijst uitwerken. Een enkele biedt alleen de mogelijkheid om van voor naar achter door de 

lijst te werken terwijl de dubbel gelinkte lijst in beide richtingen kan werken. Dit laatste kost echter 

meer overhead. 

first 

Analyse met NIAM van een dubbel gelinkte lijst levert het volgende IGD: 

heeft volgende * 

heeft vorige * 

Element 

is sentinel * 

Lijst Nummer 

is leeg * 

wijzer van staat achter de lijst * 

Element Element Element 

next next next 

object 


object 


heeft element met 

heeft vorig 

heeft volgend 

wijzer van staat op 

object 


bevat 


112

IG9OGO 


Dit resulteert in de volgende classes en attributen 

• Class LinkedList 

• Element huidige 

• boolean leeg //afleidbaar 

• boolean heeftVolgende //afleidbaar 

• boolean heeftObject //afleidbaar 

• boolean isAchterLijst //afleidbaar 


• Lijst lijst // vervalt 

• Nummer nummer // vervalt 

• Lijst aangewezenDoor // vervalt 

• Element volgende 


• boolean isSentinel // afleidbaar 

• Class Object // standaard java root class 

• Class Nummer // elementnummer (vervalt door referentieadres) 

Dit levert het volgende class Diagram op, uitgebreid met de methoden insert, set, get en remove 

LinkedList 


hasNext() : boolean 

next() : void 

-current 

reset : void 

clear() : void 

insert(object : Object) : void 

get() : Object 

set(object : Object) : void 

remove() : void 

Element 

getObject() : Object 

setObject(object : Object) : void 

getNext() : Element 

-next 

setNext(next : Element) : void 

getPrevious() : Element 

setPrevious(previous : Element) : void 

-object 


Met next kunnen we deze wijzer naar het volgende element verplaatsen, mits deze niet al achter 

de lijst staat (hasNext()). 

De methode insert voegt voor het huidige element een nieuw element/object tussen. Terwijl de set 

het nieuwe object onder de wijzer plaatst, hij vervangt het oude object. 

Remove haalt het object onder de wijzer weg en wijst vervolgend naar het (oude) volgende 

element. 

De add en de remove zijn enigszins lastig vanwege het manipuleren van de referenties. Men raakt 

hier licht de draad (lees referentie) kwijt. 

Onderstaande object diagram laat de insert zien. De insert plaatst een nieuw element met object 

voor de wijzer. 

113

L6.3.1 Implementatie van een Lijst 

IG9OGO 


De List (of lijst) zoals we hem hier bekijken wijkt enigszins af af van de List zoals deze wordt 

gebruikt in de JCF. Wil je er meer over lezen dan kun je bijvoorbeeld het boek Data Structures & 

Problem Solving Using Java door Mark Allen Weiss er op naslaan. 

Terwijl de List in de JCF met een index werkt, werken we hier met een reeks geschakelde 

(gelinkte) dynamische gegenereerde elementen. In een enkel gelinkte lijst bestaat elk element uit 

een Object referentie en één naar het volgende element. 

Om een element in te voegen (insert), moeten we eerst bepalen waar we dit doen. In de gegeven 

implementatie is gekozen om het object voor de wijzer in te voegen. 

We hebben nu het probleem dat we niet terug in de lijst kunnen (enkele link). Dus niet een nieuw 

vorig element kunnen maken omdat we dan de lijst structuur niet kunnen onderhouden, door een 

vorig element een nieuwe volgend te geven. We kunnen dit echter eenvoudig oplossen door het 

nieuwe element niet voor maar achter de wijzer toe te voegen en vervolgens door de objecten te 

verwisselen de juiste volgorde van de objecten, waar het uiteindelijk om gaat, te herstellen. 

‘nieuwe’object 


Element 

current 


‘nieuwe’element 

Element 

Element 


Element insert = new Element(); // creëer nieuw element 

insert.setNext(current.getNext()); // link deze naar zijn volgende 

current.setNext(insert); // link de huidige naar de nieuwe 

insert.setObject(current.getObject); // plaats huidige object in het Element 

current.setObject(object); // plaats nieuwe object in huidige 

current = insert; // verplaats huidige 

114

IG9OGO 


Bij het verwijderen van een Element uit de lijst kan men niet volstaan met het overslaag van het 

huidige element, omdat dit slechts gerealiseerd kan worden vanuit het vorige element die we dus 

niet kennen. We passend een soortgelijke handelswijze als bij de insert toe. We verwijderen niet 

het wijzer element, maar het volgende, waarbij we onder de wijzer het object van de volgende 

gaan bewaren. Uiteindelijk het ik nu het gewenste object verwijderd en mijn structuur in tact 

gehouden. Teven staat mijn nieuwe wijzer op de juiste plaats. De garbage collector ruimt 

vervolgens het overbodige element en verwijderde object op omdat er niet meer aan wordt 

gerefereerd. 

Element 

current 

object 


Element Element 

next next next 


object 

object 


Een implementatie van de remove vind je in het navolgende uitwerking. 

Het verhaal is nog niet compleet. wat gebeurt er als ik niet midden in een langere lijst toevoeg of 

verwijder, maar aan de uiteinden. Of wat gaat er mis als de lijst leeg is ? 

Sentinel elementen 

Als er dus niet een huidig element is om achter toe te voegen of een volgende element is om te 

verwijderen hebben we een probleem. We kunnen alle uitzonderingssituaties achterhalen en 

hierop in onze code gaan controleren. Dit is een minder gelukkige keuze omdat 

uitzonderingssituaties vaak tot bugs leiden. Een mogelijke oplossing is het gebruik van 

zogenaamde sentinels. Dit wil zeggen dat we aan het begin van een lijst en/of aan het eind een 

extra element toevoegen wat geen object bevat, maar puur bedoeld is om de implementatie te 

vereenvoudigen. In de lijst is dan altijd een start en/of een eind element aanwezig. Voor het 

voordeel van het voorkomen van uitzonderingssituatie op deze wijze betalen we de prijs van een 

enkel (of twee) kleine extra objecten (ruimte). 

In de navolgende implementatie wordt gebruik gemaakt van een sentinel aan het einde van de lijst. 

Het gebruik van de sentinel blijft voor de ‘gebruiker’ verborgen. 

Iterator 

In de navolgende implementatie van een Enkel gelinkte lijst is gekozen voor een wijzer in de lijst 

zelf. Dit levert problemen op zodra we meerdere wijzers willen gebruiken. Dit probleem kunnen we 

oplossen door een extra Iterator-class te maken die een wijzer voor ons beheert en manipuleert. 

Deze iterator is, anders dan de ‘gebruiker’ op de hoogte van de interne structuur van de lijst. Deze 

uitbreiding is in de implementatie nog niet toegepast. 

115

IG9OGO 

Sources van een enkel gelinkte lijst. 

import nl.hen.ict.assertion.*; 

public class SingleLinkedList { 

private Element current; 

private Element first; 


public SingleLinkedList() { 

first = new Element(); //sentinel; 

reset(); 

} 

public void insert(Object object) { 

Element insert = new Element(); 

insert.setNext(current.getNext()); //element invoegen 

current.setNext(insert); 

insert.setObject(current.getObject()); //objecten plaatsen 

current.setObject(object); 

current = insert; //current opschuiven 

} 

public void set(Object object) { 

Assertion.require(hasNext(), 

"Kan object niet plaatsen want de wijzer staat op de sentinel"); 

current.setObject(object); 

} 

public Object get() { 


"Kan object niet opvragen want de wijzer staat op de sentinel"); 

return current.getObject(); 

} 

public void remove() { 


"Kan niet verwijderen want de wijzer staat op de sentinel"); 

current.setObject(current.getNext().getObject()); 

current.setNext(current.getNext().getNext()); 

} 

public void next() { 


"Kan de wijzer niet opschuiven want deze staat op de sentinel"); 

current = current.getNext(); 

} 

public boolean hasNext() { 

return !current.isSentinel(); 

} 

public void reset() { 

current = first; 

} 

public void clear() { 

first = new Element(); 

reset(); 

} 


String result = ""; 

Element iterator = first; 

while (!iterator.isSentinel()) { 

result += iterator.getObject().toString(); //object afbeelden 

iterator = iterator.getNext(); //opschuiven 

} 

return result; 

} 

public boolean isEmpty(){ 

return first.isSentinel(); 

} 

116

} 

IG9OGO 


public class Element { // Inner class 

private Element next; 

private Object object; 

} 

public Element getNext() { 

return next; 

} 

public void setNext(Element newNext) { 

next = newNext; 

} 

public Object getObject() { 

return object; 

} 

public void setObject(Object newObject) { 

object = newObject; 

} 

public boolean isSentinel() { 

return object == null; 

} 

117


OEFENING 6.1 

OEFENING 6.2 

IG9OGO 


De bedoeling van deze opgave is om een wachtrij (queue) te maken. 

Bij een wachtrij worden nieuwe objecten achteraan toegevoegd en objecten worden aan de 

voorkant weggehaald. Het enige object dat toegankelijk is is het voorste object. 

Twee voorbeelden van een wachtrij: 

Een wachtrij heeft de volgende methoden: 

• public Object first() (geeft het voorste object) 

• public boolean isEmpty() (is de wachtrij leeg?) 

• public void remove() (verwijdert het voorste object) 

• public void put(Object nwObject) (voegt een nwObject achteraan toe) 

Geef een analyse van de datastructuur en ontwerp de datastructuur. 

Element dient in de implementatie als inner class te worden opgenomen. 

Implementeer de wachtrij. Maak daarbij gebruik van een sentinel achteraan de wachtrij en laat de 

elementen verwijzen naar het volgende element. 

OEFENING 6.3 (Uitwerken op het systeem en inleveren op het werkcollege) 

Een wachtrij op basis van een LinkedList, kan op verschillende manieren geïmplementeerd 

worden: met of zonder sentinel(s). Daarnaast zijn de volgende verwijzingen tussen elementen 

mogelijk: 

• de verwijzingen gaan alleen naar achteren; 

• de verwijzingen gaan zowel van voor naar achter als van achter naar voor; 

• de verwijzingen gaan alleen naar voren. 

Implementeer de wachtrij (en de elementen) op de volgende manieren: 

a) zonder sentinels, met verwijzingen alleen naar achteren; 

b) met een sentinel vooraan en een sentinel achteraan en verwijzingen naar voren en naar 

achteren. 

OEFENING 6.4 (Verdieping) 

Veel spellen maken gebruik van een rechthoekig speelbord. In deze opgave is het de bedoeling 

een speelbord te maken dat bruikbaar is voor diverse spellen. 

Enkele eisen voor het speelbord: het speelbord is rechthoekig, de velden worden zowel horizontaal 

als vertikaal genummerd van 1 tot en met een maximum in de betreffende richting, een veld kan 

leeg zijn, maar het kan ook een speelstuk (dat afhangt van het soort spel) bevatten. 

De volgende methoden moeten geïmplementeerd worden: 

• public Speelbord(int aantalRijen, int aantalKolommen) (creëert een leeg bord); 

• public void put(int rij, int kolom, Stuk stuk) (zet stuk op het bord); 

• public void remove(int rij, int kolom) (verwijdert stuk van het bord). 

Ontwerp, implementeer en test het boven beschreven speelbord. 

118

ZELFTOETS bij moduletaak 6 

IG9OGO 


1. Bedenk zelf 2 voorbeelden van toepassingen/situaties voor elk van de collecties: Set, Map, 

List, Stack, Queue en Sequence. 

2. Welke collectie zou je kunnen gebruiken voor een statements in een methode? 

3. Welke collectie zou je kiezen voor de diverse methoden in een class? 

4. Welke collectie zou je kiezen voor een spaarvarken? 

5. Welke collectie zou je kiezen voor de opstelling van een voetbalelftal? 

6. Wanneer lijkt een array (toch een juiste keuze? 

7. Wat is het verschil tussen een object een een element? 

8. Hoe zou je een implementatie van een simpele Set maken op basis van de LinkedList, Teken 

een object-diagram. 

9. Bedenk welke collectie voor een (passagiers)trein wagon geschikt zou zijn. Hoe ziet dit er dan 

uit voor de hele trein(aaneenschakeling van wagons). 

119

PRAKTIKUM OPDRACHTEN. 

Opdracht 1. Onroerend goed 

IG9OGO 


Bij deze opdracht gaat het om een gemeente die in verband met allerlei belastingen en heffingen 

de waarde van onroerend goed vaststelt. Voor het gemak gaan we ervan uit dat het onroerend 

goed alleen woningen betreft. 

Van een woning, die geïdentificeerd wordt door een kadastraal nummer wordt de waarde 

vastgelegd. 

Een woning kan een bewoner hebben. Er kan maar één bewoner per woning zijn en een bewoner 

kan maar in één woning tegelijk wonen. Bij een bewoner hoort altijd een woning. 

Verder heeft een woning een eigenaar. Een woning heeft maar één eigenaar, maar een eigenaar 

kan meer woningen in bezit hebben. Bij een eigenaar hoort altijd een woning (het omgekeerde 

eisen we niet). Van de eigenaar wordt verder vastgelegd bij welke hypotheekbank hij/zij is 

aangesloten (dat kan er maar één zijn). 

Een eigenaar is altijd ook bewoner. Dit kan zowel van zijn/haar eigen woning als van een andere 

zijn. 

De waarde van een woning moet in Euro’s worden vastgelegd, maar moet ook in guldens kunnen 

worden afgedrukt. Een Euro is gelijk aan fl. 2,20371 

De gemeentelijke administratie moet de volgende handelingen kunnen uitvoeren: 

Een nieuwe woning moet aan het woningenbestand toegevoegd kunnen worden. 

Een bewoner moet aan het bewonersbestand kunnen worden toegevoegd. 

Een eigenaar moet aan het eigenaarbestand kunnen worden toegevoegd. 

Alle bewoners moeten kunnen worden afgedrukt met de gegevens van de woning (nummer en 

waarde in guldens en Euro's en eigenaar). 

Alle woningen moeten kunnen worden afgedrukt met hun kadastraal nummer, waarde, eventuele 

bewoner en eventuele eigenaar. 

De totale waarde van alle woningen moet kunnen worden bepaald. Deze totale waarde moet zowel 

in guldens als in Euro's worden afgedrukt. 

Gevraagd: 

1. Maak een NIAM-analyse van het probleem en laat deze controleren, voorafgaand aan stap 2. 

2. Maak een ontwerp voor de software: voer een Classdiagram in Rational Rose . 

3. Maak op basis van dit ontwerp een implementatie. Uiteraard dient gebruik te worden gemaakt 

van asserties. 

Bij de implementatie kunnen een aantal uitgewerkte classes worden gebruikt, waarmee een 

eenvoudige user interface wordt gegenereerd met behulp waarvan het te bouwen systeem 

soepel kan worden getest. Deze zijn te vinden in /hio/praktikum/i1/OGO/onroerendgoed. Zie 

ook de hier aanwezige README-file. 

Ingeleverd moeten worden een technisch verslag met daarin opgenomen: 

- probleemstelling 

- analyse 

- ontwerp met daarin van alles een verantwoording, class diagram. 

- evaluatie 

- de relevante classes (als bijlage en niet in het verslag opgenomen) 

Inleverdatum: in overleg met de begeleidende docent. 

120

Opdracht 2. Paardensport. 

IG9OGO 


Bij deze opdracht wordt de situatie bij dressuur- en springwedstrijden beschreven. Er zijn een 

aantal vereenvoudigingen uitgevoerd waardoor de opgave iets beknopter is, maar waarbij de 

realiteit geen geweld is aangedaan. Zo zijn er bijvoorbeeld in werkelijkheid 5 in plaats van 3 

klassen. 

In de ruitersport worden paarden en ruiters ingedeeld in categorieën en klassen. Er zijn twee 

categorieën, dressuur en springen, en drie klassen: L (licht), M (midden), en Z (zwaar). (In 

werkelijkheid ook nog B, beginners, en ZZ, zeer zwaar, maar die laten we nu buiten beschouwing.) 

Een ruiter is voor een bepaalde categorie ingedeeld in een bepaalde klasse. Een ruiter wordt altijd 

meteen in beide categorieën ingedeeld, ook al zal hij/zij maar in één categorie wedstrijden rijden. 

Voor een paard geldt hetzelfde. Enkele voorbeelden zijn in de volgende tabellen te vinden. 

Ruiter Categorie Klasse Paard Categorie Klasse 

Dirk dressuur M Branja dressuur L 

Dirk springen L Branja springen M 

Danny dressuur Z Peck dressuur Z 

Danny springen Z Peck springen Z 

Conny dressuur M Bobby dressuur L 

Conny springen L Bobby springen L 

Wendy dressuur L Quincy dressuur M 

Wendy springen Z Quincy springen L 

Voor wedstrijden in een bepaalde categorie (dus een springwedstrijd of een dressuurwedstrijd) 

komen een ruiter en een paard (een combinatie) uit in een bepaalde klasse. 

Een ruiter kan met meerdere paarden in één wedstrijd deelnemen. Ook kan een paard met 

meerdere ruiters een combinatie vormen in één wedstrijd. Voorbeelden van combinaties die in een 

wedstrijd tegelijkertijd kunnen voorkomen zijn dus: Dirk met Branja, Danny met Branja en Danny 

met Peck. 

De klasse waarin de combinatie uitkomt wordt bepaald aan de hand van de volgende regels: 

Een ruiter die nog niet eerder was ingeschreven wordt ingedeeld in L. 

Hetzelfde geldt voor een paard. 

Een L-ruiter start met elk paard in klasse L. 

Een M-ruiter start met een L-paard in klasse L. 

Een M-ruiter start met een M- of Z-paard in klasse M. 

Een Z-ruiter moet met een L-paard in M starten. 

Een Z-ruiter start met een M-paard in M. 

Een Z-ruiter start met een Z-paard in Z. 

Verder geldt ten aanzien van de puntentelling bij wedstrijden het volgende. 

Bij een wedstrijd haalt een combinatie (van ruiter en paard) een aantal punten van 0 tot en met 

260. Dit puntenaantal wordt vertaald in winst- of verliespunten: 118 t/m 155 wedstrijdpunten 

leveren géén winstpunten op; 156 t/m 168 wedstrijdpunten (60-65% score) leveren 1 winstpunt op; 

169 t/m 181 wedstrijdpunten ( 65-70% score) leveren 2 winstpunten, 182 of meer wedstrijdpunten 

(>=70 % score) leveren 3 winstpunten; 104 t/m 117 wedstrijdpunten( 40 – 45 % score) leveren 1 

verliespunt op, 91 t/m 103 wedstrijdpunten ( 35-40 % score) leveren 2 verliespunten en 90 of 

minder wedstrijdpunten ( score < 35 %) leveren 3 verliespunten. 

De winstpunten gelden niet individueel, maar voor een combinatie. Bij 10 of meer winstpunten gaat 

de combinatie over naar de volgende klasse. Dit kan dus nooit gebeuren met één wedstrijd. Na 

promotie begint de combinatie weer met 0 winstpunten. 

Voorbeeld: 

Een combinatie van een L-ruiter met een Z-paard start in L. Bij 11 winstpunten gaat de combinatie 

over naar klasse M. Dat betekent dat alleen de ruiter een klasse hoger (M) komt; het paard blijft Z. 

Wanneer beiden (in een bepaalde categorie) in dezelfde klasse zouden zitten, promoveren ze ook 

beide. 

De wedstrijdadministratie vindt plaats bij de ruitersportfederatie. Hier wordt ook de indeling 

121

IG9OGO 


in klassen geadministreerd. 

Bij de federatie moeten een aantal zaken worden uitgevoerd: 

• Een ruiter moet kunnen worden ingeschreven. Dit gebeurt tegelijk voor beide categorieën. 

(Naam en adres opgeven; indeling automatisch in klasse L voor beide categorieën.) 

• Een paard moet kunnen worden ingeschreven. (Naam van het paard en die van de eigenaar 

opgeven. Indeling in klasse L voor beide categorieën.) 

• Vóór een wedstrijd moeten combinaties kunnen worden gevormd. Dat wil zeggen dat een ruiter 

en een paard gekoppeld moeten kunnen worden. Een paard kan tegelijk met meer ruiters en 

elke ruiter met meer paarden ingeschreven staan; elke combinatie heeft zijn eigen 

puntenaantal en klasse. 

• Vóór een wedstrijd moet voor een combinatie van ruiter en paard een startbewijs afgedrukt 

kunnen worden. Dit is een bewijs waarop staat in welke klasse de combinatie mag uitkomen. 

Er staan dus vier dingen op: naam ruiter, naam paard, categorie en klasse. 

• Ná een wedstrijd moet het aantal wedstrijdpunten van een combinatie van ruiter en paard in 

een bepaalde categorie in een bepaalde klasse kunnen worden ingevoerd. Aan de hand van 

deze wedstrijdpunten worden winstpunten bepaald en geadministreerd. 

• Na invoering van de wedstrijdresultaten moeten promoties kunnen worden uitgevoerd. 

Verder moeten 

• een overzicht van alle paarden (met al hun gegevens) gemaakt kunnen worden; 

• een overzicht van alle ruiters (met al hun gegevens) gemaakt kunnen worden. 

Gevraagd: 

Maak eerst een NIAM-analyse en ontwerp op basis daarvan de software voor de administratie van 

de ruitersportfederatie. Uit bovenstaande lijst met punten kunnen daarna vrij eenvoudig de nodige 

use cases afgeleid worden. Maak een plan van aanpak met betrekking tot de volgorde waarin je de 

use cases implementeert. Je mag maar met één use case tegelijk bezig zijn, de eerder 

geïmplementeerde moeten werken en blijven werken. 

Bij de implementatie kunnen een aantal uitgewerkte classes worden gebruikt, waarmee weer een 

eenvoudige user interface wordt gegenereerd met behulp waarvan het te bouwen systeem soepel 

kan worden getest. Deze zijn te vinden in /hio/praktikum/i1/OGO/paardensport. Zie ook de hier 

aanwezige README-file. 

Ingeleverd moeten worden een technisch verslag met daarin opgenomen: 

- probleemstelling 

- analyse 

- ontwerp met daarin van alles een verantwoording. Class, Use case , Use case Realizations met 

Sequence diagrams, voor elke flow of events één. 

- evaluatie 

- de relevante classes (op regeldrukkerpapier als bijlage en niet in het verslag opgenomen) 

Inleverdatum: in overleg met de begeleidende docent. 

122

BIJLAGEN 

IG9OGO 


BIJLAGE A. UML Quick Reference for Rational Rose 2000 

To make modeling with the UML in Rational Rose easier, we’ve provided you with this quick 

reference guide. 

• General purpose concepts/use-case diagram 

• Class diagram- types of classes 

• Class diagram- relationships 

• Class diagram- more relationships 

• Class diagram- visibility & properties 

• State-transition diagram- states & transitions 

• State-transition diagram- nested states 

• Sequence diagram 

• Collaboration diagram 

• Component/deployment diagrams 

123

1. 

2. 

IG9OGO 


124

3. 

4. 

IG9OGO 


125

5. 

6. 

IG9OGO 


. 

126

7. 

8. 

IG9OGO 


127

9 

IG9OGO 

. 

10. 


128

UITWERKING Zelftoets bij moduletaak 1 

IG9OGO 


BIJLAGE B. Uitwerkingen van de zelftoetsen 

1. Wat is het doel van het gebruik van asserties? 

ANTWOORD: 

asserties zijn een hulpmiddel om software van hoge kwaliteit te realiseren: correct en robuust 

Tijdens de ontwikkelingsfase werken ze als controle op de precondities, na afronding van de 

ontwikkeling dienen ze als documentatie : van welke precondities wordt uitgegaan en welke 

postcondities worden gerealiseerd. 

2. Wat verstaat men onder Design by Contract? 

ANTWOORD: 

Design by contract geeft aan dat er software ontwikkeld wordt volgens een contract tussen 

leverancier en gebruiker van bestaande software. 

De voorwaarden waaronder de te gebruiken bestaande software goed functioneert liggen vast 

en de resultaten, bij gebruik overeenkomstig de voorwaarden. 

3. Leg het verschil uit tussen pre- en postcondities. 

ANTWOORD: 

Preconditie: formulering van de voorwaarden waaronder een methode (procedure/functie) 

gebruikt mag worden, met een gegarandeerd eindresultaat 

Postconditie: formulering van gegarandeerd eindresultaat bij gebruik van de bestaande 

software volgens de precondities 

4. Welke rol vervullen asserties in de testfase en in de opleveringsfase? 

ANTWOORD: 

Zie antwoord op vraag 1. 

5. Welke verantwoordelijkheid heeft de “client” ten aanzien van het gebruik van precondities? 

ANTWOORD: 

De gebruiker TEST ! Met andere woorden: De client moet voorafgaand aan het gebruik van 

bestaande software controleren of aan de precondities (voorwaarden) ervan is voldaan. 

6. Ligt de volgende uitspraak toe: 

“Asserties zijn niet bedoeld ter vervanging van input controle” 

ANTWOORD: 

Omdat asserties in de test of ontwikkelingsfase als controle op precondities van bestaande 

software werken, wordt gemakkelijk de vergissing gemaakt dat gegevens die door een 

systeemgebruiker worden ingevoerd dan niet meer gecontroleerd hoeven te worden. Dit moet 

wel degelijk apart gebeuren: immers de “client” moet zorgen dat aan de precondities is voldaan 

en dit kan input controle vereisen 

7. Voeg in onderstaande constructor van Persoon een correct gebruik van asserties toe. 

/* persoon registreert gegevens van een patient geidentificeerd door een naam 

tevens wordt de geboortedatum bijgehouden en de huisarts van deze patient 

*/ 


class Persoon{ 

private String naam; //identificatie 

private Arts huisArts; 

private String gebDatum; 

} 

public Persoon(String nwNaam, String nwGebDatum){ 

Assertion.require((nwNaam != null) AND (nwGebDatum!= 

null),”nwNaam mag niet null zijn en nwGebDatum mag niet null 

zijn”); 

naam= nwNaam; 

gebDatum= nwGebDatum; 

} 

129


8. Geef aan hoe op een correcte manier in een hoofdprogramma een Persoon object wordt 

aangemaakt volgens het “contract” van vraag 7. 

IG9OGO 

ANTWOORD 8 

String nwNaam ; 

String nwGebDatum ; 

…….. 

……… 

…… 

// nu is niet zeker of nwNaam en nwGebDatum naar een string verwijzen!! 

if ( nwNaam!= null AND nwGebDatum!=null ){ 

Persoon eenPersoon= new Persoon(nwNaam,nwGebDatum 

} 

9. Onderstaande codefragment uit het uitgewerkte voorbeeld van deze moduletaak wordt op een 

juiste manier “Design by Contract “ toegepast. Licht toe in welke coderegels hiervan sprake is 

en leg uit waarom dit een correct gebruik ervan is. 

10. public void koppel(String naam, int nummer) { 

11. if (rekeninghouderBestaat(naam) && rekeningBestaat(nummer)) { 

12. Rekeninghouder rekh = geefRekeninghouder(naam); 

13. Rekening rek = geefRekening(nummer); 

14. if (!rekh.heeftRekening()){ 

15. rekh.open(rek); 

} 

16. else { 

17. System.out.println(“Rekeninghouder heeft al 

rekening”); 

18. } 

} 

19. else { 

20. System.out.println(“Rekeninghouder en/of rekening 

onbekend”); 

21. } 

22. } 

ANTWOORD: 

r 11 en r14 testen door de gebruiker ingevoerd om aan de precondities te voldoen van de 

gebruikte methoden: 

voor geefReninghouder: rekeninghouder moet bestaan 

voor geefRekening: rekening moet bestaan 

voor open ( ) : rekeninghouder mag nog geen rekening hebben. 

Als niet aan deze voorwaarden is voldaan worden de methoden niet aangeroepen en wordt 

dit op het scherm aan de gebruiker gemeld. 

130


IG9OGO 


1. Welke elementen uit een NIAM IGD worden standaard omgezet naar een class bij afbeelding 

naar een ontwerp van classes? 

ANTWOORD: 

Elk objecttype wordt in principe een class, elke nominalisatie wordt een class ,elk n-air feittype 

met n>=3 , wordt ook een class 

2. Welke constructoreisen volgen uit een NIAM IGD bij het ontwerpen van een class? 

ANTWOORD: 

Identificatie attributen moeten als parameter meegegeven worden in de constructor, evenzo 

de attributen die afgeleid zijn uit een feittype waar een veplichtingsregel voor geldt. 

3. Wanneer kunnen er in afwijking van de formele afbeelding naar het ontwerp van classes 

vereenvoudigingen worden toegepast? Geef een toelichting. 

ANTWOORD: 

O.a. Als een objecttype maar in één feittype voorkomt hoeft doorgaans geen aparte class te 

worden gedefinieerd maar kan volstaan worden met een attribuut in de corresponderende 

class 

4. Zet het volgende NIAM IGD om naar een ontwerp van classes: 

Land 

Sitenaam 

[NL, DE, CH] 

Site 

N L 

In is een site met 

 

hen NL 

Knoop 

Subnet 

S SN M 

in op is een 

netwerkknoop 

hen.NL hio bach 

Message 

K1 K2 T 

Machine 

M U 

Tijdstip 

K S 

heeft het beheer over in 

subnet “hio” 

K S 

heeft het beheer 

over 

is bestemd voor 

bach@hio.hen.nl \ 12 karel 

op is van naar een 

bericht verzonden 

bach@hio.hen.nl 

rome@cs.ibm.de 

12 

M T 

bevat 

bach@hio.hen.nl \ 12 hallo 

is systeembeheerder 

Voor de eenvoud reduceren we meteen maar: 

Sitenaam -> String 

Land -> String // denk wel om class-invariant wanneer het land gebruikt wordt! 

Subnet -> String 

Machine -> String 

Tijdstip -> String 

Tekst -> String 

Waarschijnlijk zullen in de praktijk Subnet, Machine en mogelijk Tijdstip classes blijven. 

User 

* 

Systeembeheerder 

Afgeleid feittype bevat feiten over alle knopen in het subnet “hio” 

U 

Tekst 

131

IG9OGO 


Essentie die overblijft: 

class Site 

String naam // identificatie 

String land // identificatie 

Set behoortTot // Knoop 

Invariant: 

naam != null 

land.equals("NL") or land.equals("DE") or land.equals("CH") 

behoortTot != null 

class Knoop 

String machine // identificatie 

String subnet // identificatie 

Site site // identificatie 

Systeembeheerder beheerder 

Systeembeheerder hioBeheerder // functie 

Set verzondenMessages // Message 

Set ontvangenMessages // Message 

Invariant: 

machine != null 

subnet != null 

site != null 

verzondenMessages != null 

ontvangenMessages != null 

hio_beheerder == beheerder, als subnet.equals(“hio”) 

class Message 

Knoop verstuurdVan // identificatie 

String tijdstipVerzending // identificatie 

Knoop verstuurdNaar 

User geadresseerde 

String inhoud 

Invariant: 

verstuurdVan != null 

tijdstipVerzending != null 

verstuurdNaar != null 

geadresseerde != null 

inhoud != null 

class User 

String naam // identificatie 

Message ontvangenMessage 

Invariant: 

naam != null 

class Systeembeheerder extends User 

Set beheerderVan // Knoop 

Set beheerderIndienHioKnoop // Knoop 

// alleen relevant bij beheerder van hio-knoop, dus weg 

// (zie ook functie in class knoop) 

Invariant: 

beheerderVan != null 

Je zou bovendien verwachten dat een systeembeheerder minstens één systeem 

beheert, maar dat is hier niet zo (vergeten?) 

132


IG9OGO 


1. Waarom ontwerpen we aan de hand van modellen? 

ANTWOORD: 

Visuele modellen helpen omgrotere systemen eenvoudiger te begrijpen en vergemakkelijken 

de communicatie over de structuur van systemen. Bovendien kan het documenteren van een 

systeem op een meer uniforme en volledige wijze plaatsvinden 

Resultaat: kwalitatief betere software. 

2. Welke views vormen de basis van UML modellering in RationalRose? Wat is de betekenis 

ervan? 

ANTWOORD: 

Use Case View de functionaliteit van het systeem wordt weergegeven zoals deze door de 

externe gebruikers (actors) wordt waargenomen. 

Logical View statische structuur van classes geeft de functionaliteit binnen het systeem 

Component View weergave groepering van code componenten 

Deployment View model voor afbeelding softwareonderdelen op hardware , gedistribueerd en 

niet gedistribueerd 

3. Wat zijn associaties en aggregaties? Met welke symbolen zijn deze in UML aan te geven? 

ANTWOORD: 

Een associatie is een relatie tussen classes waarbij een object van een bepaalde class A een 

object van een andere class B kent. Bij een aggregatie is de relatie sterker: een object van 

class A beheert dan een object van class B, dat wil zeggen: de levensduur van object van 

class B is gekoppeld aan de levensduur van object van class A. 

4. Wat is het doel van een use case diagram? 

ANTWOORD: 

Weergeven welke gebruiken het systeem benutten: systemen en personen 

Weergeven bij welke onderdeel (use case) elke gebruiker (actor ) betrokken is 

Ook is het mogelijk de onderliggende opbouw van use cases te tonen o.a. met extends relatie 

5. Wat is het verschil tussen een sequence en een collaboration diagram? 

ANTWOORD: 

Sequence diagram geeft de samenwerking tussen objecten in het systeem weer met de 

nadruk op de tijdvolgorde. Collaboration diagram doet hetzelfde maar dan met nadruk op 

welke objecten met elkaar communiceren 

6. Maak een class diagram bij de uitwerking van Zelftoets moduletaak 2 vraag 4 

ANTWOORD: 

-verstuurdVan verstuurdNaar 

Site 

naam : String -site -behoortTot 

Knoop 

machine : String 

2 

Message 

tijdstipVerzending : String 

land : String 

* 

subnet : String 

inhoud : String 

-beheerderVan 

SysteemBeheerder 

-geadresseerde 

7. Ontwerp voor de use case “urenInvoeren “ van het Garagevoorbeeld een 

User 

naam : String 

ontvangenMessage 

name 

133

IG9OGO 

Sequencediagram. 

: monteur 

voerUrenin(String, Datum, String, float) 


: Admin : Afspraak : WerkOrder 

getKlant(String) 

getAfspraak(Klant, Datum) 

voerUrenin(String, float) 

getWerkOrder( ) 

setBestedeUren( ) 

134


IG9OGO 


5. Wat is een interface in JAVA termen? Noem een voorbeeld van een toepassing. 

ANTWOORD: 

Een interface heeft tot doel om een scheiding aan te brengen tussen interface en 

implementatie: het voor de gebruiker relevante en niet-relevante deel van de te gebruiken 

software. Een interface is eigenlijk een abstract class zonder attributen, zlleen de signature van 

de methoden wordt vastgelegd. 

Voorbeeld: Set interface . 

6. Wat is een abstract class? Wat is het nut hiervan? 

ANTWOORD: 

Een abstract class is een class waarvan geen instanties aangemaakt kunnen worden. Meestal 

bevat een dergelijke class één of meer abstracte methoden. 

Soms is het niet mogelijk in een superclass een bepaalde methode uit te voeren, terwijl we bij 

inheritance toch een dergelijke methode verplicht willen stellen. Een abstract class is dan 

handig. 

7. Zijn een interface en een abstract class uitwisselbaar? Waarom wel/niet? 

ANTWOORD: 

Nee, een abstract class mag naast de abstracte methoden ook wel geïmplementeerde 

methoden bevatten, een interface niet. 

8. De volgende figuur toont een deel van de componentenhiërarchie uit de awt. Container en 

Component zijn abstract classes 

Component 

Container TextComponent 

Panel Window 

Dialog Frame 

TextArea TextField 

Gegeven is bovendien nog het volgende: 

− De klasse Container heeft een methode add met de volgende signatuur: 

public void add(Component c) 

− De klassen Window en Dialog hebben constructoren als volgt: 

public Window(Frame parent) 

public Dialog(Frame parent) 

− Een applicatieprogrammeur definieert in een eigen klasse een methode met de volgende 

signatuur: 

public void voegLettersToe(TextField tf, Window w) 

Elk van de volgende programmafragmenten bevat een fout. Geef aan wat er fout is en 

wanneer deze fout optreedt, bij vertaling of bij verwerking. Als de fout vermeden kan worden 

door een cast toe te voegen, toon dan ook de verbeterde code. Licht je antwoorden kort toe. 

a Component c1 = new Panel(); 

Component c2 = new Frame(); 

c2.add(c1); 

135

IG9OGO 

b Window w = new Frame(); 

Dialog d = new Dialog(w); 


c TextComponent tc = new TextArea(); 

Frame f = new Frame(); 

voegLettersToe((Textfield)tc, f); 

ANTWOORD a: 

De derde regel geeft bij vertaling een foutmelding; het gedeclareerde type van c2 is Component en 

die klasse heeft geen methode add. Met behulp van een cast kan de fout verbeterd worden: 

((Container)c2).add(c1); 

of 

((Frame) c2).add(c1); 

ANTWOORD b : 

De tweede regel geeft bij vertaling een foutmelding. Het gedeclareerde type van w is Window; 

omdat Window > Frame wordt dit als parameter niet geaccepteerd. Ook hier kan een cast worden 

toegevoegd: 

Dialog d = new Dialog((Frame)w); 

ANTWOORD c: 

In de derde regel treedt bij verwerking een fout op. Er is (door middel van de cast) beloofd dat het 

actuele type van tc TextField zal zijn, maar dat blijkt niet waar: tc is van type TextArea. Tussen 

TextArea en TextField bestaat geen relatie en dus is de cast niet uitvoerbaar. 

6. Gegeven zijn de volgende klassedefinities. 

public class A 

{ 



} 



public class B extends A 

{ 



} 

public int superTien(int i) 

{ return super.tien(i); } 

public class C extends B 

{ 



} 

Geef voor elk van de volgende programmafragmenten aan, of het fragment correct is. Zo 

niet, wat is er fout? Zo ja, wat is na afloop de waarde van de variabele resultaat? Licht je 

antwoorden kort toe. 

a B b = new B(); 

int resultaat = b.twintig(2); 

b A a = new C(); 

int resultaat = a.tien(2); 

c A a = new C(); 

136

IG9OGO 


int resultaat = a.twintig(2); 

d A a = new C(); 

int resultaat = a.superTien(2); 

e B b = new B(); 

int resultaat = b.superTien(2); 

ANTWOORDEN: 

a. Klasse B heeft geen methode twintig maar erft deze van A; deze methode wordt 

uitgevoerd. Het resultaat is 2+20 = 22. 

b. Bij verwerking is het actuele type bepalend. Klasse C heeft geen methode tien maar erft 

deze van B; deze methode wordt uitgevoerd. Het resultaat is 2*10 = 20. 

c. Bij verwerking is het actuele type bepalend en dus wordt de methode twintig van C 

gebruikt. Het resultaat is 2*20 = 40. 

d. De vertaler accepteert de tweede regel niet omdat de klasse A (het gedeclareerde type) 

geen methode superTien heeft. 

e. Nu zijn het gedeclareerde en het actuele type beide B, en dat mag wel want b heeft een 

methode superTien. De methode tien van de superklasse van B wordt uitgevoerd; het 

resultaat is dus 12. 

137


IG9OGO 


1. Wat is het verschil tussen een Set en een Map? 

ANTWOORD: 

In een Set worden elementen/objecten geplaatst, terwijl in een Map een value/object via een 

key wordt geplaatst 

2. Waartoe dient een interface in de Java Collections Classes? 

ANTWOORD: 

Het interface dient om de functionaliteit van een collectie type vast te leggen, opdat er 

implementatie keuzes mogelijk blijven. 

3. Welke collection interface kies ik als ik studenten met studentnummer wil gaan registreren? 

ANTWOORD: 

Een Map (implementatie HashMap). 

4. Hoe kan ik in een collectie door de elementen zoeken (bijvoorbeeld een Set of een 

LinkedList)? 

ANTWOORD: 

Door een iterator op te vragen en met deze element na element op te vragen en te 

onderzoeken 

5. Waarom kan ik bij een map niet direct een iterator opvragen ? 

ANTWOORD: 

Omdat er in een map sprake is van een entry. Je moet kiezen tussen een iterator op de keys of 

op de values. 

6. Welke collectie interface en/of implementatie schiet je te binnen bij een parkeerplaats met 

genummerde plaatsen? 

ANTWOORD: 

List met ArrayList 

7. Hoe verwijder ik een object uit een Set? 

ANTWOORD: 

Met de referentie naar het object in de hand kan ik middels remove(object) een element 

verwijderen. Eventueel moet ik eerst met een iterator het juiste object in de set gaan zoeken. 

8. Hoe gaat een en ander in z’n werk als ik een object ‘uit’ een Map haal? 

ANTWOORD: 

Met behulp van de key wordt in de Map het juiste object gezocht (door de Map). Wat ik krijg is 

een referentie-kopie naar het gevonden object. Het object blijft dus in de collectie aanwezig. 

9. Waarom zou ik er voor kiezen om een wrapper rond een bestaande implementatie te maken 

met een functionele beperktere interface in plaats van de beschikbare interfaces (zoals List)? 

ANTWOORD: 

Te veel voor de toepassing niet relevante functionaliteit kan leiden tot foutief gebruik. Dit 

verslechtert de robuustheid van de toepassing. 

138


IG9OGO 


1. Bedenk zelf 2 voorbeelden van toepassingen/situaties voor elk van de collecties: Set, Map, 

List, Stack, Queue en Sequence. 

ANTWOORD: 

…. 

2. Welke collectie zou je kunnen gebruiken voor statements in een methode? 

ANTWOORD: 

Sequence 

3. Welke collectie zou je kiezen voor de diverse methoden in een class? 

ANTWOORD: 

Set of Map met signature-key 

4. Welke collectie zou je kiezen voor een spaarvarken? 

ANTWOORD: 

Set 

5. Welke collectie zou je kiezen voor de opstelling van een voetbalelftal? 

ANTWOORD: 

Map 

6. Wanneer lijkt een array (toch) een juiste keuze? 

ANTWOORD: 

Genummerde structuur met vaste lengte, zonder tussenvoegingen en verwijderingen. 

7. Wat is het verschil tussen een object een een element? 

ANTWOORD: 

Een element verzorgt de samenhang tussen de objecten in een lijst 

8. Hoe zou je een implementatie van een simpele Set maken op basis van de LinkedList, Teken 

een object-diagram. 

ANTWOORD : pm. 

9. Bedenk welke collectie voor een (passagiers)trein wagon geschikt zou zijn. Hoe ziet dit er dan 

uit voor de hele trein(aaneenschakeling van wagons). 

ANTWOORD: 

Wagon met genummerde zitplaatsen: List (ArrayList). 

De trein is een list van wagons, dus een lijst met lijsten. 

139

Abstract class, 74 

Aggregatie, 47 

anonymous inner class, 96 

Assertie, 10 

Associatie, 47 

Class Diagram, 43 

Class diagrams, 45 

relaties, 46 

ClassCastException, 99 

Cloneable, 72 

collectie types, 83 

Collection, 95 

Collections, 100 

Comparable, 71; 96 

Comparator, 96 

Correctheid, 10 

Design-by-contract, 12 

Design-by-Contract 

pre- en postcondities, 12 

entry, 86 

equals, 102 

feittype, 109; 110 

first in, first out, 92 

Gelijkheid van objecten, 102 

hashCode, 102 

HashSet, 83 

Hashtable, 100 

implementatie, 82 

Implementatie van een lijst, 117 

implementatie van een stack, 113 

inner class, 96 

Inner class, 74 

interface, 69; 82 

Cloneable, 72 

Eigenschappen, 70 

Interface 

IG9OGO 

A 

C 

D 

E 

F 

G 

H 

I 


Index 

Comparable, 71 

Interface Collection, 95 

Interface Comparator, 96 

Interface List, 99 

Interface Map, 99 

Interface Set, 95 

Interface SortedMap, 99 

Interface SortedSet, 95 

interfaces, 68 

Java Collections Framework, 94 

key, 86 

last in, first out, 90 

lijst, 89; 117 

LinkedList, 92 

LinkedListStack, 116 

list, 117 

List, 89; 99 

Map, 86; 99; 108 

natural ordering, 95 

NIAM, 23 

ontwerp, 23 

omzetting van NIAM, 23 

basis, 23 

constructorvoorschrift, 25 

n-aire feittypen, 27 

nominalisatie, 27 

Verfijning, 25 

Optional operations, 103 

peek, 90; 113 

pop, 90; 113 

Postconditie, 11 

Preconditie, 10 

push, 90; 113 

queue, 110 

Queue, 92 

RPN, 113 

R 

J 

K 

L 

M 

N 

O 

P 

Q 

140

Sequence, 92; 111 

Sequence diagram, 44 

Sequence Diagram, 52 

naming convention, 52 

Set, 83; 95; 107 

SingleLinkedList, 89 

SortedMap, 99 

SortedSet, 95 

Stack, 90; 109; 114 

SuperMarkt, 85; 88 

ternaire feittypen, 108 

TreeSet, 95; 97 

UML, 39 

IG9OGO 

S 

T 

U 


Diagrammen, 41 

Geschiedenis, 39 

Overzicht, 40 

Quick Reference, 129 

Views, 40 

uniciteiten, 108 

Use case diagram, 42 

Use Case Diagram, 48 

Use case specification, 50 

sjabloon, 50 

value, 86 

Vector, 100 

volgorde, 89 

wrapper, 90 

V 

W 

141

Modulehandleiding Object georiënteerd ontwerpen HE – ICT CP/HIO

Create successful ePaper yourself

Delete template?

Save as template?