Opstellen gedetailleerd klassendiagram (in java)

[Vulchare]

Ik zie in een lap tekst niet vaak welke methodes er nodig zijn en in welke klasse deze geïmplementeerd moeten worden.

Neem onderstaande tekst van een proeftentamen van de OU. Zodra ik het diagram zie, zou ik zeggen oja, natuurlijk! Helaas gaat het zelfstandig uitwerken niet helemaal volgens plan.

Ik twijfel bijvoorbeeld over in welke klasse de methode voor het bijhouden van de woningen hoort en welke parameters erbij horen. Welke parameters ik vast moet leggen in de constructors Woning en Verkoop enz.

Ik ben dus op zoek naar extra mogelijkheden om hiermee te kunnen oefenen. Het liefst in Java, uiteraard.


Alle koopwoningen in een gemeente worden elke twee jaar getaxeerd. De getaxeerde waarde wordt vastgesteld op grond van de prijzen die vergelijkbare woningen in het jaar voor de taxatiedatum hebben opgebracht.

Een woning wordt gekenmerkt door een postcode en een huisnummer. Voor de waardebepaling zijn verder de volgende eigenschappen van belang: het woningtype (vrijstaand, twee‐onder‐een‐kap, hoekhuis, tussenwoning of appartement), het woonoppervlak en de grootte van de kavel. Voor elke woning wordt bovendien bijgehouden wanneer deze van eigenaar is gewisseld en wat de verkoopprijs was.

De gemeente ontwikkelt een informatiesysteem waarmee de taxatie automatisch kan gebeuren. In dit informatiesysteem worden onder andere de klassen Woning en Verkoop opgenomen. De klasse Verkoop representeert één verkoop, waarbij de datum en de prijs van die verkoop (in hele euro’s) worden vastgelegd (gegevens over de oude en nieuwe eigenaar blijven in deze opgave buiten beschouwing).

De klasse Woning representeert een woning met de eigenschappen als zojuist geschetst. Bij een woning worden alle geregistreerde verkopen bijgehouden, vanaf de datum dat de woning in het systeem is opgenomen. De klasse moet een nieuwe verkoop aan deze lijst toe kunnen voegen. Een belangrijke verantwoording van de klasse is verder de taxatie van de woning, waarbij een lijst wordt meegegeven van vergelijkbare woningen die in het afgelopen jaar verkocht zijn. Binnen de klasse Woning moet gecontroleerd kunnen worden of de woningen in deze lijst aan die eis voldoen.

[farlane]

Het vaststellen welke properties/methoden een class moet hebben en welke relaties klassen onderling moeten hebben blijft altijd lastig, is een kwestie van ervaring denk ik.
Ook kun je altijd discussiëren over of de gekozen oplossing nou wel echt de meest logische/handige is. In deze tekst wordt bijvoorbeeld gesteld dat de klasse Woning een lijst moet bijhouden van Verkopen; in mijn beleving zou dit niet de verantwoordelijkheid van de klasse Woning moeten zijn, maar van een WoningVerkopen klasse oid.

[Kwistnix]

Een handig hulpmiddel bij het nadenken over verantwoordelijkheden en onderlinge koppelingen tussen klassen is een CRC-kaart sessie. Dat is alleen wel een beetje een suffe exercitie om alleen te doen
Ervaring is hier inderdaad gewoon belangrijk en leren doe je door fouten maken. Veel moeilijker moet je het voor jezelf niet maken, want dan kom je in analysis paralysis terecht. Big design up front werkt sowieso vaak niet. Een ontwerp komt ook vaak iteratief tot stand (emergent design). Dus, ja, denk goed over je eerste ontwerp na, maar ga ook vooral aan de slag met implementeren, loop tegen problemen aan, pas je ontwerp aan etc.