Domeinmodel (DM) - Documentatie

**[1.0 Doel]** - Domeinmodel (DM) = visuele representatie v/concepten uit werkelijkheid n hun onderlinge relatie - Wordt opgesteld aan hand v/contextuele beschrijving i/combinatie met uitgewerkte use cases - Schema wordt opgesteld om op visuele n eenduidige manier over...

**[1.0 Doel]** - Domeinmodel (DM) = visuele representatie v/concepten uit werkelijkheid n hun onderlinge relatie - Wordt opgesteld aan hand v/contextuele beschrijving i/combinatie met uitgewerkte use cases - Schema wordt opgesteld om op visuele n eenduidige manier over probleemdomein v/project te kunnen communiceren met klant - Domeinmodel bevat dan ook enkel terminologie zoals gebruikt door klant - Dit schema vormt dan ook belangrijkuitgangspunt n inspiratiebron voor verder ontwerp v/applicatie - Aangezien DM nog steeds model is v/werkelijkheid bevat dus zeker x alles maar enkel noodzakelijke elementen nodig binnen probleemdomein Als vb. kunnen we bibliotheek beschouwen - Zeker x noodzakelijk om alle tafels n stoelen op te nemen i/schema omdat deze x meerwaarde bieden binnen bibliotheeksysteem al zijn deze i/werkelijkheid wel aanwezig - We beperken ons dus enkel tot klassen die nodig zijn uit probleemdomein met hun zinvolle eigenschappen n verbanden onderling **[2.0 Onderdelen]** - DM bevat steeds volgende onderdelen - Conceptuele klassen \| Associatie n multipliciteiten - Daarnaast kan DM ook volgende onderdelen hebben: - Rolnaam v/conceptuele klasse i/associatie - Generalisatie/specialisatie - Aggregatie - Compositie - Associatieklasse ***2.1 Conceptuele klasse*** - Is bouwsteen v/DM stelt object uit werkelijkheid voor - Naam v/conceptuele klasse begint steeds met hoofdletter daarnaast bevat enkel relevante attributen binnen probleemdomein - Naam v/attribuut wordt via camelCasing uitgewerkt - Bemerk dat we i/DM x datatypes kennen, dus ook attribuut heeft x aanduiding v/mogelijk datatype - Dit wordt immers pas i/ontwerpfase later toegevoegd - Ook slaan we x attributen op die berekend gegeven zijn, maar wel attributen die nodig zijn om gegeven te kunnen berekenen - Bv. leeftijd v/persoon = berekening, we slaan dus als attribuut "geboorteDatum" op zodat we later leeftijd kunnen berekenen - Afh. v/gekozen probleemdomein kan conceptuele klasse al dan x andere attributen bevatten bij bv. op slide i.v.m. dobbelsteen kunnen beiden afh. v/context correct zijn - I/ons geval modelleren we dobbelsteenspel dus is enkel weergave met attributen "aantalZijdes" n "aantalOgen" correct - Andere weergave kan juist zijn, mocht context bv. speelgoedwinkel zijn waari/zij versch. types dobbelstenen verkopen ***2.2 Associatie en multipliciteiten*** - Conceptuele klassen op zich vertellen natuurlijk x veel i/DM drm wensen we ook verbanden uit te drukken tussen zo 2 klassen - Dit doen we door associatie te leggen tussen betrokken conceptuele klassen - Opnieuw leggen we x tussen elk paar v/conceptuele klassen associatie maar modelleren we associatie enkel indien die zinvol is binnen probleemdomein - We verbinden betrokken conceptuele klassen dan met volle lijn - Ook mogelijk om, indien zinvol, meerdere versch. associaties te leggen tussen zelfde conceptuele klassen - Daarnaast kan je ook conceptuele klasse ook geassocieerd worden met zichzelf - Dat noemen we reflexieve associatie - Op associatie wordt i/midden steeds associatienaam geplaatst dit is ww, beginnend met hoofdletter, dat zorgt voor duidelijk die standaard leesbaar is v/links nr rechts of v/boven nr onder - Wens je associatie afwijkende leesrichting te geven dan duid je dit aan met pijl die correcte leesrichting weergeeft - Elke associatie tussen zelfde conceptuele klassen heeft dus steeds unieke associatienaam - Aan elke uiteinde, per rol, v/associatie wordt bij elke conceptuele klasse multipliciteit geplaatst Dit is aanduiding v/hvl instanties v/conceptuele klasse verbonden zijn via associatie met andere conceptuele klasse - Mulitpliciteit wordt weergegeven als "min. \#\...max. \#" waarbij min. \# getal is dat 0,1 of exacte waarde heeft - Max. \# is min. even hoog als min. \# maar kan groter exacte waarde zijn of \* (oneindig veel) - Als min. \# = max \# mag er ook exact 1 waarde als multipliciteit vermeld worden - Ook mag je 0... \* vervangen door \* - Als laatste mogelijkheid heb je i.p.v. bereik ook mogelijkheid om exacte opsomming te geven ***2.3 Rolnaam*** - Soms is associatienaam x voldoende duidelijk om rol v/conceptuele klasse i/associatie aan te duiden - Om deze te verduidelijken plaatsen we dan rolnaam langs kant v/conceptuele klasse die we wensen toe te lichten - Rolnaam is steeds verplicht om langs min. 1 kant op te nemen bij reflexieve associatie rolnaam = zelfstandig naamwoord i/kleine letters uitgedrukt ***2.4 Generalisatie/specialisatie*** - I/bepaalde gevallen kan zijn dat conceptuele gemeenschappelijke attributen heeft met andere conceptuele klasse maar toch nog \# eigen eigenschappen heeft - Dan kunnen we gebruik maken v/principe generalisatie/specialisatie - Hierbij hebben we 1 conceptuele basisklasse (=generalisatie) met alle gemeenschappelijke attributen die door afgeleide klassen (=specialisatie) worden overgeërfd - Elke conceptuele klasse, generalisatie of specialisatie, kan zijn eigen associaties hebben met andere conceptuele klassen - Indien generalisatieklasse associatie aangaat dan geldt die onmiddellijk ook voor al zijn specialisatieklassen - Specialisatieklasse kan echter ook nog z'n eigen attributen hebben los v/generalisatieklasse - Je kan dit enkel gebruiken als je kan zeggen "naam specialisatie = naam generalisatie" ***2.5 Aggregatie*** - Wnnr 2 conceptuele klassen v/gelijk niveau deel uitmaken v/associatie die "deel/geheel" relatie voorstelt dan kunnen we die associatie als aggregatie modeleren - Aggregatie is dus speciale voorstelling v/gewone associatie waarbij we lege ruit modeleren aan kant v/conceptuele klasse die "geheel" vormt - Minimummultipliciteit v/die conceptuele klasse mag voor die associatie enkel waarde 0 of 1 hebben - Extra voorwaarde is ook dat conceptuele klasse die "deel" vormt ook op zich kan bestaan - Heeft m.a.w. "geheel" x nodig n blijft dus bestaan als "geheel" wordt verwijderd n omgekeerd - Je kan dit enkel modelleren als je kan zeggen "naam geheel heeft naam deel" ***2.6 Compositie*** - Andere speciale notatie v/associatie = compositie - Dit is strengere vorm v/aggregatie hierbij wordt volle ruite gemodelleerd langs kant v/"geheel" n moet multipliciteit langs die zijde ook exact 1 zijn - Instantie v/geheel is verantwoordelijk voor creatie n vernietiging v/delen - Deze speciale soort v/associatie kan je enkel gebruiken als je kan zeggen: "naam geheel bestaan uit naam deel" - Dit is enkel mogelijk bij "fysiek" verband tussen 2 conceptuele klassen 2.7 Associatieklasse - Laatste optioneel onderdeel v/DM deze klasse gebruik je als je nood hebt aparte attributen die horen bij bepaalde associatie - Levensduur v/associatieklasse is dan ook afh. v/associatie tussen 2 conceptuele klasse waartoe ze hoort - Naam n attributen v/associatieklasse volgen dan ook regels v/gewone conceptuele klasse - Je kan deze dus ook associëren met andere conceptuele klasse - Associatieklasse zelf wordt steeds met stippellijn verbonden met associatie waartoe ze behoort - Je kan associatieklasse enkel gebruiken bij associatie waarv/maximummultipliciteit langs beide kanten \* is, m.a.w. veel-op-veel relatie - X altijd nodig om associatieklasse te modelleren - Associatie tussen 2 conceptuele klassen met associatieklasse kan steeds omgevormd worden tot 2 aparte associaties tussen 3 conceptuele klasse **[3.0 Stappenplan]** - DM wordt iteratief opgesteld aan hand v/context n/of use case(s) bij verwerken v/context of use case volgen w steeds volgende stappen - Identificeren v/kandidaatsklassen - Selecteren v/conceptuele klassen - Associaties leggen n/of aanpassen - Attributen toevoegen, verplaatsen n/of schrappen - Optimalisatie (Enkel bij laatste keer stappenplan wordt uitgevoerd) - Indien je zowel over context als use case(s) beschikt, is aan te raden om eerst context te verwerken n nadien elke use case volgens stappenplan te behandelen ***3.1 Stap 1: Identificeren van de kandidaatsklassen*** - Deze stap heeft als doel om zo veel mogelijk kandidaten conceptuele klassen te vinden - We verwerven inzicht i/probleemdomein door nodige bouwstenen te zoeken v/schema - We stellen aan hand v/context of use case lijst op v/alle zelfstandige nw die er i/voorkomen - Daarnaast plaatsen we ook alle bijvoeglijke nw bij zelfstandig nw i/lijst - V/use case worden volgende onderdelen gebruikt: - Pre- n postcondities \| normaal verloop \| alternatieve verlopen \| (relevante) domeinspecifieke regels - Op einde v/deze stap hebben we dus heel uitgebreide lijst v/allemaal mogelijke conceptuele klassen ***3.2 Stap 2: Selecteer de conceptuele klassen*** - Uit lijst die we uit stap 1 verkregen hebben, overlopen we nu alle kandidaatsklassen n beslissen we dan telkens of al dan x conceptuele klasse wordt - Om dat te doen, stellen we telkens volgende 3 vragen: - Speelt klasse zelfstandige rol i/probleemdomein? - Willen we iets v/kandidaat weten of willen we dat hij iets doet? - Heeft klasse duidelijke verantwoordelijkheid? - Antwoorden we op elke vraag telkens "ja", dan behouden we kandidaatsklasse n wordt uiteindelijk echte conceptuele klasse - Kandidaatsklasse "systeem" kan nooit conceptuele klasse zijn omdat DM net systeem voorstelt! - Ook kandidaatsklassen met naam die synoniem is aan reeds opgenomen conceptuele klasse worden nooit weerhouden aangezien ze dan al bestaan - Op einde v/deze stap hebben we dus alle bouwstenen voor voorlopige DM gevonden n voegen we deze als lege conceptuele klassen aan DM toe ***3.3 Stap 3: Identificeer associaties*** - Nu we bouwstenen, conceptuele klassen, geïdentificeerd hebben i/vorige stap, gaan we op zoek nr mogelijke verbanden tussen elke klasse - Kan ook zijn dat leidt tot bijkomende associaties voor bestaande conceptuele klassen indien we iteratief werken - We herlezen context of use case n zoeken nr structurele verbanden tussen conceptuele klassen die voor zekere tijd moeten aangehouden worden - Hierbij letten we vooral op ww n bezittelijke vnw - Let wel op dat je x gedrag of synoniem voor reeds bestaande associatie modelleert! - Daarnaast kan deze stap ook aanleiding geven tot ontdekken v/associatieklassen indien dit verband duidelijk uit context of use case voor komt ***3.4 Stap 4: Identificeer attributen*** - Nadat we conceptuele klassen met elkaar verbonden hebben met zinvolle associaties, gaan we i/laatste op zoek nr zinvolle eigenschappen v/elke conceptuele klasse op zich - Indien je iteratief werkt, kan zijn dat je bijkomende relevante attributen ontdekt - Om dit te doen overlopen we lijst die opgesteld hebben i/stap 1 waarbij we vermelding gemaakt hebben "x conceptuele klasse maar mogelijk attribuut" - Daarnaast nemen we context of use case nogmaals door n gaan we op zoek nr volgende: - Dingen die voorgesteld worden via simpele waarde - Woorden waarvoor je ja kan antwoorden op "Is... eigenschap v/andere klasse" wijzen vaak op attribuut - Bijvoeglijk vnw wijzen vaak op attributen - Na deze stap eindigen we met voorlopig afgewerkt DM ***3.5 Stap 5: Optimalisatie*** - Deze stap voer je enkel uit indien alle use cases n contexten verwerkt zijn M.a.w. extra stap nadat je laatste keer stappenplan hebt doorlopen - I/deze stap gaan we vooral alle overbodige zaken uit DM verwijderen die x relevante meerwaarde hebben ook al hadden we ze i/eerdere stappen toegevoegd - Zo wordt DM minder complex n bevat enkel zaken die effectief nodig zijn - Om dit te doen verwijderen we alle conceptuele klassen zonder attributen die x relevatie/noodzakelijke associatie heeft met andere conceptuele klasse - Daarnaast worden alle generalisatie/specialisatie omgevormd tot 1 klasse met attribuut type indien specialisaties zelf x aparte eigenschappen hebben of relevantie zelfstandige associaties met andere conceptuele klassen - Attributen v/generalisatieklasse worden uiteraard wel behouden - Na uitvoeren v/deze optimalisatie houden we dan ook volledige afgewerkte DM over