Geef het domeinmodel voor de POS-casus: aanbodkant!

We plaatsen een aantal opmerkingen bij dit model. Allereerst stellen we vast dat het model een interpretatie is van de use-casebeschrijving en additionele informatie.  Uit de use-casebeschrijving is niet duidelijk of het van belang is te weten aan welke kassa een medewerker werkt. We hebben daarom geen associatie gemaakt tussen Register en Cashier. Attribuutnaam itemID is eigenlijk wat ongelukkig, beter was productID geweest maar Larman gebruikt deze naam ook verder in zijn boek. Store fungeert als beheerder van Cashier en Register, ProductCatalog als beheerder van ProductDescription. Voor Cashier en Register hadden we , net als voor ProductDescription, ook aparte beheerklassen kunnen nemen.  
Klasse ProductCatalog is bijzonder in die zin dat de klasse geen attributen bevat. In het algemeen kunnen we stellen dat een klasse zonder attributen ‘verdacht’ is. Vaak duidt zo’n klasse op een ontwerpfout; de klasse is overbodig. Bij een klasse zonder attributen moeten we ook naar de associaties kijken. Soms wordt het bestaan van zo’n klasse gerechtvaardigd door de associaties die zo’n klasse heeft. Bij klasse ProductCatalog wordt het bestaan gerechtvaardigd door de associatie met ProductDescription: ProductCatalog is de beheerder van ProductDescription.