Chapter-3 Femke.docx

# Introductie tot informatiemanagement en enterprise architectuur Dit document introduceert de basisprincipes van informatiemanagement en de plaats ervan binnen enterprise architectuur, met specifieke aandacht voor datamodelleringstechnieken zoals UML Class Diagrams. ## 1. Introductie tot informatiemanagement ### 1.1 Wat is informatiemanagement? Informatiemanagement omvat het verzamelen, opslaan, verwerken en ontsluiten van gegevens en informatie binnen een organisatie. Het doel is om de juiste informatie op het juiste moment, bij de juiste persoon te krijgen om bedrijfsprocessen te ondersteunen en strategische doelen te bereiken. #### 1.1.1 Dataopslag: gecentraliseerd versus gedecentraliseerd * **Gecentraliseerde database:** Voorkomt datadubplicatie en zorgt voor consistentie. * **Gedecentraliseerde database:** Elke functie of afdeling heeft een eigen systeem en gegevensopslag, wat kan leiden tot inconsistenties en duplicatie. #### 1.1.2 Informatieverwerking in bedrijfsprocessen Informatie moet stapsgewijs worden verwerkt gedurende een bedrijfsproces, van begin tot eind. Diverse informatiebronnen moeten worden samengebracht om processen, zoals budgetverdeling, te ondersteunen. ### 1.2 Datamodellering en enterprise architectuur Datamodellering is een cruciaal onderdeel van enterprise architectuur. Het stelt organisaties in staat om hun informatiebehoeften te structureren en te visualiseren. #### 1.2.1 Strategisch alignment framework Een strategisch alignment framework integreert business, technologie en informatie. Bedrijfsprocessen en -doelen vallen onder de 'business'-peiler. Informatiedoelen en benodigde gegevens worden uitgewerkt in conceptuele en logische datamodellen, ondersteund door technologie. #### 1.2.2 Het Zachman framework Binnen het Zachman framework richt datamodellering zich op de "What"-kolom, met name op het niveau van conceptuele datamodellen (rij 2). Dit omvat het identificeren van relevante gegevens, hun onderlinge relaties en de eerste opzet van een database. #### 1.2.3 Plaats in TOGAF Hoewel niet gedetailleerd beschreven in de verstrekte tekst, wordt datamodellering binnen TOGAF (The Open Group Architecture Framework) ook beschouwd als een essentieel onderdeel om de informatiearchitectuur van een onderneming te definiëren. ### 1.3 Datamodellering: UML Class Diagrams Datamodellering, met name met behulp van UML Class Diagrams, is een techniek om de structuur van een bedrijfsdomein in kaart te brengen. #### 1.3.1 Wat is een datamodel? Een model is een systematische en vereenvoudigde beschrijving van een object of fenomeen, die de belangrijkste kenmerken ervan weergeeft. Dit is een handig instrument voor studie en begrip. #### 1.3.2 UML (Unified Modelling Language) UML is een objectgeoriënteerde modelleringstaal die bestaat uit diverse modelleertechnieken. Het biedt een visuele, symbolische taal die software-engineers helpt bij het begrijpen van vereisten en het ontwerpen van softwaresystemen. * **Modelleertaal:** Een verzameling van modelleertechnieken (bv. UML). * **Modelleertechniek:** Een specifieke methode om een model te beschrijven met symbolen en regels (bv. UML Class Diagrams, BPMN procesdiagrammen). #### 1.3.3 Voordelen van UML Class Diagrams UML Class Diagrams bieden een middenweg tussen puur tekstuele en puur formele technieken: * **Voordelen:** Gemakkelijk te begrijpen, voldoende formeel voor precisie en verificatie. * **Representatie:** Klassen worden weergegeven als rechthoeken, associaties als pijlen. #### 1.3.4 Waarom is datamodellering belangrijk? Het creëren van een domeinmodel leidt tot een dieper begrip van het domein, wat essentieel is voor het bouwen van aanpasbare informatiesystemen die kunnen omgaan met veranderende vereisten. Het focussen op het kernconcept van het bedrijf in het model zorgt voor de levensvatbaarheid van het systeem. ### 1.4 Concepten binnen UML Class Diagrams #### 1.4.1 Klassen en attributen * **Klasse:** Een abstractie of concept dat objecten met vergelijkbare eigenschappen groepeert (bv. "Student", "Product", "Auto"). Het dient als een sjabloon voor reële objecten. * **Intentie van een klasse:** De definitie die bepaalt wanneer een object tot de klasse behoort. * **Uitbreiding van een klasse:** De verzameling objecten die voldoen aan de intentie. * **Instantie:** Een individueel, werkelijk bestaand object van een klasse (bv. "Student Jan", "Product MilkyWay"). * **Attributen:** Eigenschappen waarover informatie wordt verzameld voor elk individueel object in een klasse (bv. voornaam, achternaam, studentnummer). * **Gegevenstypes (Data Types):** Beperken de waarden die aan een attribuut kunnen worden toegekend (bv. tekst, getal, datum). Dit is cruciaal voor correcte bewerkingen. > **Tip:** Een klasse kan zowel tastbare als ontastbare objecten vertegenwoordigen. #### 1.4.2 Representatie van instanties in databases Instanties van klassen kunnen worden weergegeven in tabellen, zoals in Microsoft Access (met expliciete datatypes voor velden) of Microsoft Excel (waar kolomtitels attributen zijn en cellen de waarden; datatype wordt bepaald door celformaat). #### 1.4.3 De definitie van een klasse (klassendiagram) Een klasse-definitie beschrijft duidelijk wanneer iets tot die klasse behoort. Een UML-klassendiagram wordt gemaakt voor een specifiek domein en definieert begrippen, eigenschappen en relaties binnen dat domein, vergelijkbaar met een ontologie. #### 1.4.4 Associaties Associaties vertegenwoordigen abstracties van relaties tussen instanties van klassen. Ze verbinden klassen en beschrijven de aard van de koppeling. * **Multipliciteit:** Geeft aan hoeveel instanties van de ene klasse gekoppeld kunnen zijn aan instanties van de andere klasse. Dit wordt weergegeven als een interval: `(minimum, maximum)`. * `0..1`: nul of één * `1..1`: precies één * `0..*`: nul of meer ("veel") * `1..*`: één of meer * **Rollen:** De namen die de richting van een associatie aangeven (bv. van student naar opleiding, is de rol "ingeschreven voor"). * **Meerdere associaties:** Tussen twee klassen kunnen meerdere verschillende associaties bestaan (bv. een persoon kan eigenaar én bestuurder van een auto zijn). #### 1.4.5 Unary Associations Associaties kunnen ook een klasse met zichzelf verbinden. Voorbeelden zijn hiërarchische structuren (afdelingen) of stuklijsten (bill of materials). #### 1.4.6 Ternary Associations Wanneer relaties tussen drie entiteiten complex zijn, volstaan binaire associaties niet. Een ternaire associatie koppelt drie klassen direct aan elkaar, waarbij de multipliciteit genuanceerder wordt bepaald door het fixeren van twee entiteiten en te kijken naar het aantal van de derde. #### 1.4.7 Aggregatie (Deel-geheel relaties) Drukt een deel-geheel-relatie uit. * **Shared Aggregation (witte diamant):** Delen kunnen bij meerdere gehelen horen (bv. modules in verschillende cursussen). * **Composite Aggregation (zwarte diamant):** Een deel hoort bij maximaal één geheel (exclusief eigendom, bv. orderlijnen bij een order). Dit impliceert vaak "cascading delete" (verwijderen van het geheel verwijdert ook de delen). > **Advies:** Het gebruik van gewone associaties met duidelijke rolnamen wordt vaak aangeraden boven aggregatiesymbolen, omdat deze minder ambiguïteit veroorzaken. #### 1.4.8 Derived/Implicit Associations Indirecte relaties die ontstaan door navigatie via meerdere opeenvolgende associaties. De cardinaliteit hiervan volgt uit de cardinaliteiten van de originele relaties. Deze worden niet getekend maar moeten wel begrepen worden bij het lezen van een model. #### 1.4.9 Superclass/Subclass/Inheritance (Generalisation) * **Generalisation (generaliseren):** Creëert een algemeen concept (superclass) uit specifiekere concepten (subklassen). De subklassen erven eigenschappen van de superclass. * Voorbeeld: Bankrekening (superclass) met Zichtrekening en Spaarrekening (subklassen). * **Specialisation (specialiseren):** Het proces van het creëren van specifieke subklassen uit een algemene superclass. * **Generalisation Sets:** Soms kan een supertype op meerdere manieren worden opgesplitst (bv. vervoermiddel op basis van motor of op basis van habitat). Dit kan op verschillende manieren worden genoteerd (naam bij lijnen, gedeelde pijl, gestreepte lijn). * **Constraints:** * **Complete vs. Incomplete specialisatie:** Bepaalt of er instanties van de superclass bestaan die niet tot een subklasse behoren. * **Disjuncte vs. Overlappende subklassen:** Bepaalt of een instantie tot meerdere subklassen tegelijk kan behoren. Standaard zijn subklassen overlappend. #### 1.4.10 Association Class Een Association Class wordt gebruikt wanneer attributen werkelijk bij de relatie tussen twee klassen horen, en niet bij de klassen zelf. De objecten van de Association Class bestaan zolang de gekoppelde objecten bestaan. #### 1.4.11 Multiple Inheritance Structures Bij meerdere generalisatiehiërarchieën in een diagram is het belangrijk te modelleren of specifieke subklassen alleen met specifieke superklassen kunnen interageren. Dit wordt vaak bereikt door associaties op het niveau van de subtypes te modelleren en de associatie op het supertype te verwijderen. --- # Conceptuele datamodellering met UML Class diagrammen Dit onderwerp introduceert de principes en geavanceerde concepten van UML Class diagrammen voor conceptuele datamodellering, met de nadruk op het identificeren van klassen, attributen, datatypes en associaties. ### 2.1 Wat is datamodellering? Datamodellering is een proces dat wordt gebruikt om de structuur van bedrijfsgegevens te beschrijven en hoe deze gegevens aan elkaar gerelateerd zijn. Het creëren van een domeinmodel, zoals een UML-klassendiagram, leidt tot een dieper begrip van het domein. Dit is cruciaal voor het bouwen van softwaresystemen die flexibel kunnen inspelen op veranderende gebruikersvereisten. #### 2.1.1 Het belang van datamodellering Een goed datamodel is de basis voor het bouwen van aanpasbare informatiesystemen. Als het ontwerp van een systeem het kernconcept van een bedrijf niet belichaamt, zal het systeem falen bij het toevoegen van nieuwe vereisten. #### 2.1.2 Modelleertalen en technieken Een modelleertaal is een verzameling van modelleertechnieken. UML (Unified Modelling Language) is een objectgeoriënteerde modelleertaal die een notatie van visuele, symbolische modellen biedt. Deze modellen helpen software-engineers bij het begrijpen van vereisten en het ontwerpen van softwaresystemen. **Modelleertechnieken kunnen variëren van puur tekstueel tot puur formeel:** * **Tekstuele diagrammen:** Makkelijk te begrijpen, maar vaak onnauwkeurig en dubbelzinnig. Bieden geen intelligente verificatie. * **Puur formele technieken:** Bieden veel formele mogelijkheden, maar zijn moeilijker te begrijpen en te gebruiken. * **UML-klassendiagrammen:** Bevinden zich ergens in het midden, zijn relatief makkelijk te begrijpen en voldoende formeel voor precisie en verificatie. ### 2.2 UML Class diagrammen - basisconcepten UML-klassendiagrammen zijn een techniek om de structuur van een bedrijfsdomein in kaart te brengen. Ze visualiseren bedrijfsobjecten, geven de benodigde informatie over deze objecten weer en laten zien hoe objecten met elkaar verbonden zijn. #### 2.2.1 Klassen Een klasse is een abstractie, een soort of categorie van objecten. Een klasse definieert een verzameling objecten die vergelijkbare eigenschappen delen. * **Intentie van een klasse:** De definitie van het concept dat bepaalt of een object tot de klasse behoort. Een klasse dient als sjabloon of model voor een groep reële objecten. * **Uitbreiding van een klasse:** De verzameling objecten die voldoen aan de intentie van de klasse. In UML wordt een klasse weergegeven als een rechthoek met de naam van de klasse erin. Klassen kunnen zowel tastbare als ontastbare objecten vertegenwoordigen. > **Tip:** Modelleren is abstractie maken. We gaan van het instantie- of objectniveau (niveau 0, individuele objecten) naar het model-/diagramniveau (niveau 1, de definitie van klassen). #### 2.2.2 Attributen en datatypes * **Attributen:** De eigenschappen of kenmerken waarover informatie wordt bijgehouden voor elk individueel object binnen een klasse. * **Datatypes:** Beperken de waarden die aan een attribuut kunnen worden toegekend. Een waarde moet voldoen aan de beperkingen van het datatype. In een UML-klassendiagram worden attributen en hun datatypes geschreven in een rechthoek onder de naam van de klasse. > **Tip:** Het correct instellen van datatypes is belangrijk. Als getallen als tekst worden opgeslagen, kunnen berekeningen mislukken. #### 2.2.3 Class definities en ontologieën Elke klasse heeft een **klasse-definitie**, een duidelijke beschrijving die aangeeft wanneer iets tot die klasse behoort. Een UML-klassendiagram wordt gemaakt voor één specifiek domein en definieert concepten, eigenschappen en relaties binnen dat domein. Dit vormt in feite een **ontologie**, een gemeenschappelijke woordenschat binnen een organisatie of vakgebied. #### 2.2.4 Associaties Een associatie is een abstractie van relaties of koppelingen tussen objecten van verschillende klassen. Het verbindt klassen en vertegenwoordigt een type koppeling met specifieke kenmerken. * **Rollen:** De richtingen waarin een associatie gelezen kan worden (bijvoorbeeld van 'student' naar 'opleiding' of van 'opleiding' naar 'student'). * **Multipliciteit:** Geeft de minimale en maximale aantal objecten aan dat betrokken kan zijn bij een associatie. Dit wordt weergegeven als een interval, bijvoorbeeld (0,1), (1,1) of "veel" (*). * `(0,1)`: Nul of één. * `(1,1)`: Precies één. * `(0,*)`: Nul of veel. * `(1,*)`: Eén of veel. UML-associaties worden weergegeven als lijnen tussen klassen. Er kunnen meerdere associaties tussen twee klassen bestaan, en ze kunnen verschillende rollen hebben. > **Voorbeeld:** Een student kan voor nul of veel programma's ingeschreven zijn `(0,*)`. Een programma heeft nul of veel studenten `(0,*)`. #### 2.2.5 Unary association Een associatie kan ook één klasse met zichzelf verbinden. Dit wordt een unary association genoemd. > **Voorbeeld:** Een persoon die een andere persoon superviseert ("superviseert" en "supervised by" zijn de rollen). Een afdeling kan subafdelingen hebben. #### 2.2.6 Ternary association Wanneer binaire of uniaire associaties niet volstaan om complexe relaties te beschrijven, wordt een **ternary association** gebruikt. Dit is één associatie die drie entiteiten koppelt. De multipliciteit bij een ternaire associatie is subtieler en wordt bepaald door combinaties van entiteiten. > **Voorbeeld:** Het vastleggen welke leverancier welk product voor welk project heeft geleverd. #### 2.2.7 Aggregatie Aggregatie drukt een deel-geheel-relatie uit. In UML wordt dit aangeduid met een diamant aan de kant van het geheel. * **Witte diamant (Shared Aggregation):** Delen kunnen bij meerdere gehelen tegelijk horen. * **Zwarte diamant (Composite Aggregation):** Een deel hoort bij maximaal één geheel. Dit impliceert exclusief eigendom en vaak 'cascading delete' (wanneer het geheel wordt verwijderd, worden de onderdelen ook verwijderd). > **Advies:** De diamant-symbolen voor aggregatie veroorzaken vaak onduidelijkheid en worden beter vermeden ten gunste van gewone associaties met duidelijke rolnamen. #### 2.2.8 Derived/implicit association Een **impliciete associatie** ontstaat wanneer je via meerdere opeenvolgende associaties kunt navigeren. Deze relaties worden niet expliciet in het diagram getekend, maar hun cardinaliteit volgt uit de oorspronkelijke relaties. > **Voorbeeld:** Als een student zich inschrijft voor een programma en elk programma bij een faculteit hoort, ontstaat er een impliciete associatie tussen student en faculteit. ### 2.3 UML Class diagrammen - geavanceerde concepten #### 2.3.1 Superclass/subclass/inheritance (Generalisatie) Generalisatie is het principe waarbij een algemeen concept (superclass, supertype) wordt gedefinieerd, en daaronder meer specifieke soorten (subklassen, subtypes) vallen. De specifieke soorten erven de eigenschappen van het algemene begrip. * **Generalisatie:** Lijn van de specifieke klasse naar de algemene klasse, met een driehoek aan de kant van de algemene klasse. * **Specialisatie:** Het proces van het definiëren van specifieke subklassen. #### 2.3.2 Generalisatiesets Generalisatiesets helpen bij het organiseren van specialisaties wanneer er meerdere mogelijke indelingen van een supertype bestaan. * **Notaties voor generalisatiesets:** Naam bij de generalisatie-lijnen, 'shared target'-stijl, of een gestreepte lijn over meerdere generalisaties. #### 2.3.3 Constraints on generalisation/specialisation * **Complete vs. Incomplete specialisatie:** Geeft aan of er objecten bestaan die tot de superklasse behoren maar niet tot één van de subklassen. * **Disjuncte vs. Overlappende subklassen:** Geeft aan of een object tegelijk tot meerdere subklassen kan behoren. Standaard zijn subklassen overlappend. Constraints worden genoteerd tussen haakjes naast de generalisatie-driehoek. > **Voorbeeld:** Een bankrekening kan compleet en disjunct gespecialiseerd zijn in betaalrekeningen en spaarrekeningen (een rekening is óf betaal, óf spaar, en er zijn geen andere soorten rekeningen). #### 2.3.4 Association Class Een **association class** wordt gebruikt wanneer een eigenschap hoort bij de relatie tussen twee klassen, en niet bij één van die klassen afzonderlijk. Een object van een association class bestaat alleen zolang beide verbonden objecten bestaan. > **Voorbeeld:** 'ProductOffer' met attributen zoals prijs en leveringsvoorwaarden, die specifiek zijn voor de relatie tussen een leverancier en een product. #### 2.3.5 Multiple Inheritance Structures Bij meerdere generalisatiehiërarchieën in een diagram moet extra aandacht worden besteed aan associaties. Associaties op het niveau van de superklassen gelden voor alle subklassen. Om specifieke regels af te dwingen (bijvoorbeeld dat alleen passagiersvliegtuigen passagiersvluchten gebruiken), moeten de associaties op het niveau van de subklassen worden gemodelleerd en de associatie op het supertype niveau verwijderd. --- # Logische en fysieke datamodellen Dit gedeelte beschrijft de transformatie van conceptuele modellen naar logische en vervolgens naar fysieke datamodellen, en behandelt de implementatie in systemen zoals MS Access en Excel. ### 3.1 Van conceptueel naar logisch en fysiek datamodel De kern van datamodellering ligt in het abstraheren van de werkelijkheid naar een gestructureerd model. Dit proces doorloopt verschillende niveaus, van conceptueel naar logisch en uiteindelijk naar fysiek. #### 3.1.1 Conceptuele datamodellering Conceptuele datamodellen beschrijven op een hoog abstractieniveau de gegevens en hun relaties binnen een domein. Ze beantwoorden de vragen: welke gegevens zijn relevant, hoe zijn ze aan elkaar gerelateerd, en vormen ze de eerste opzet voor een database? * **Doel:** Het vastleggen van de belangrijkste gegevens en hun onderlinge verbindingen, zonder in te gaan op technische details. Dit vormt de basis voor communicatie tussen belanghebbenden en het ontwerp van informatiesystemen. * **UML Class Diagrams:** Een populaire techniek voor conceptuele modellering is het gebruik van UML (Unified Modelling Language) Class Diagrams. Deze objectgeoriënteerde taal richt zich op het beschrijven van objecten/concepten die relevant zijn voor een specifiek domein. * **Klassen:** Een klasse is een abstractie die een soort of categorie van objecten vertegenwoordigt. Het definieert een verzameling objecten met vergelijkbare eigenschappen. In UML wordt een klasse weergegeven als een rechthoek. * **Intentie van een klasse:** De definitie die bepaalt wanneer een object tot de klasse behoort. * **Uitbreiding van een klasse:** De verzameling objecten die voldoen aan de intentie van de klasse. * **Attributen:** Eigenschappen van een klasse waarover informatie wordt bijgehouden voor elk individueel object. Elk attribuut heeft een gegevenstype dat de toegestane waarden beperkt. In UML worden attributen en hun datatypes genoteerd in de rechthoek onder de klassenaam. * **Relaties (Associaties):** De koppelingen tussen objecten van verschillende klassen. Associaties worden weergegeven door lijnen tussen klassen. * **Rollen:** De richting waarin een associatie gelezen kan worden (bv. van student naar opleiding). * **Multipliciteit:** Geeft aan hoeveel instanties van de ene klasse gekoppeld kunnen zijn aan instanties van de andere klasse. Dit wordt weergegeven als een interval (minimum, maximum), bijvoorbeeld $(0,1)$ of $(0,\ast)$ (veel). * **Unary Associations:** Een associatie die een klasse met zichzelf verbindt (bv. een persoon die een andere persoon superviseert). * **Ternary Associations:** Associaties die de relatie tussen drie klassen tegelijkertijd modelleren, wanneer binaire associaties onvoldoende zijn om de relatie correct te beschrijven. * **Aggregation:** Drukken een deel-geheel-relatie uit. * **Shared Aggregation (witte diamant):** Delen kunnen bij meerdere gehelen horen. * **Composite Aggregation (zwarte diamant):** Een deel hoort bij maximaal één geheel en wordt vaak automatisch verwijderd als het geheel wordt verwijderd (cascading delete). Het gebruik van diamant-symbolen wordt vaak afgeraden ten gunste van duidelijke rolnamen. * **Impliciete/Derived Associations:** Ontstaan door het navigeren via meerdere opeenvolgende associaties, waardoor indirecte relaties tussen klassen ontstaan. De cardinaliteit hiervan volgt uit de originele relaties. * **Generalisation/Specialisation (Inheritance):** Modellen van een algemeen begrip (superclass) en meer specifieke soorten (subclasses) die de eigenschappen van de superclass erven en eventueel aanvullen. * **Generalisation sets:** Mogelijkheden om specialisaties te groeperen. * **Complete vs. Incomplete specialisatie:** Geeft aan of er objecten bestaan die tot de superclass behoren, maar niet tot een van de subclasses. * **Disjuncte vs. Overlappende subklassen:** Geeft aan of een object tot meerdere subclasses tegelijk kan behoren. * **Association Class:** Wordt gebruikt wanneer een eigenschap hoort bij de relatie tussen twee klassen, en niet bij één van de klassen afzonderlijk. Een object van een association class bestaat alleen zolang de verbonden objecten bestaan. #### 3.1.2 Logische datamodellering Een logisch datamodel beschrijft de structuur van de gegevens op een niveau dat nog steeds onafhankelijk is van een specifieke databasesoftware, maar wel meer gedetailleerd is dan een conceptueel model. Het vertaalt het conceptuele model naar een gestructureerde lay-out die klaar is voor implementatie. * **Focus:** Het definiëren van entiteiten, attributen met specifieke datatypes en de relaties daartussen. Een voorbeeld hiervan is het concept van een uniek studentennummer, wat een attribuut kan zijn in de entiteit 'Student'. * **Implementatie in MS Access en Excel:** * **Microsoft Access:** Biedt de meeste databasefunctionaliteit. In het ontwerpvenster van een tabel worden attributen als velden weergegeven, elk met een specifiek datatype (bv. Number, Short Text, Date/Time). * **Microsoft Excel:** Hoewel geen databasesoftware, biedt Excel database-achtige functionaliteit. Kolomtitels fungeren als attributen en cellen als attribuutwaarden. Elke rij is een object. Het datatype wordt deels bepaald door het celformaat. Een nadeel is dat niet elke cel in een kolom hetzelfde datatype hoeft te hebben, wat problemen kan geven bij consistente dataclassificatie. #### 3.1.3 Fysieke datamodellering Het fysieke datamodel is de meest gedetailleerde weergave en beschrijft hoe de gegevens daadwerkelijk in een specifieke database worden opgeslagen. Het houdt rekening met de beperkingen en mogelijkheden van de gekozen databasesoftware. * **Detailniveau:** Dit niveau specificeert zaken als fysieke datatypen, indexen, constraints en partities, direct gericht op de implementatie in een DBMS (Database Management System). > **Tip:** Het belang van datatypes kan niet genoeg benadrukt worden. Een correct ingesteld datatype (bv. naar 'getal' in plaats van 'tekst') is cruciaal voor de correcte werking van bewerkingen zoals sommaties en voorkomt fouten. > **Tip:** Een UML-klassendiagram is een krachtig hulpmiddel om de unieke kenmerken van een bedrijf te modelleren. Het vormt een goede basis voor de ontwikkeling van een aanpasbaar informatiesysteem. > **Tip:** Het maken van een domeinmodel zorgt voor een dieper begrip van het domein, wat essentieel is voor het bouwen van softwaresystemen die effectief kunnen omgaan met veranderende vereisten. Als het kernconcept van het bedrijf niet in het ontwerp is belichaamd, zal het systeem falen. --- # Geavanceerde UML-concepten en modelleringstechnieken Dit gedeelte behandelt geavanceerde UML-concepten en modelleringstechnieken die essentieel zijn voor het gedetailleerd in kaart brengen van complexe bedrijfsdomeinen. ### 4.1 Generalisatie, specialisatie en overerving Generalisatie en specialisatie, ook wel bekend als overerving (inheritance), zijn fundamentele concepten in objectgeoriënteerd modelleren. Ze maken het mogelijk om hiërarchische relaties tussen klassen te definiëren, wat leidt tot herbruikbaarheid en structuur. #### 4.1.1 Generalisatie en specialisatie * **Generalisatie (Superklasse/Supertype):** Dit is het algemene concept of de categorie. Een superklasse definieert gedeelde eigenschappen die van toepassing zijn op meerdere specifieke subtypen. * **Specialisatie (Subklasse/Subtype):** Dit zijn de meer specifieke soorten of categorieën die een algemeen concept (superklasse) specialiseren. Subklassen erven automatisch de eigenschappen van hun superklasse en kunnen bovendien eigen, specifieke eigenschappen toevoegen. **Voorbeeld:** Een algemene klasse "Bankrekening" kan eigenschappen hebben zoals `IBAN` en `Saldo`. Specifieke subklassen hiervan kunnen "Betaalrekening" en "Spaarrekening" zijn. Een "Betaalrekening" erft `IBAN` en `Saldo` en voegt mogelijk een `creditcardnummer` toe. Een "Spaarrekening" erft eveneens `IBAN` en `Saldo` en voegt mogelijk een `spaardoel` toe. #### 4.1.2 Notatie in UML * Een generalisatie wordt weergegeven door een lijn van de subklasse naar de superklasse. * Aan de zijde van de superklasse staat een witte, gevulde driehoek. * Meerdere subklassen kunnen naar dezelfde driehoek wijzen, wat aangeeft dat ze tot dezelfde generalisatieset behoren. #### 4.1.3 Generalisatiesets Soms kan een supertype op meerdere manieren worden gespecialiseerd. Generalisatiesets helpen om deze verschillende indelingen te organiseren. * **Notaties voor generalisatiesets:** 1. **Naam bij de generalisatie-lijnen:** Elke generalisatielijn krijgt een naam die aangeeft tot welke generalisatieset de specialisatie behoort. Generalisaties met dezelfde naam horen bij dezelfde set. 2. **"Shared target"-stijl:** Meerdere lijnen wijzen naar dezelfde driehoek, en deze lijnen krijgen één gezamenlijke naam. 3. **Gestreepte lijn:** Een gestreepte lijn wordt over meerdere generalisatielijnen getrokken. De generalisatieset krijgt één naam. #### 4.1.4 Constraints op generalisatie/specialisatie Er zijn twee belangrijke soorten constraints die de relatie tussen super- en subklassen definiëren: * **Complete vs. Incomplete specialisatie:** * **Complete specialisatie:** Elk object dat tot de superklasse behoort, behoort *ook* tot ten minste één van de subklassen. Er zijn geen objecten in de superklasse die niet in een subklasse vallen. * **Incomplete specialisatie:** Het is mogelijk dat een object tot de superklasse behoort, maar niet tot een van de gespecialiseerde subklassen. * **Disjuncte vs. Overlappende subklassen:** * **Disjuncte subklassen:** Een object kan slechts tot *één* subklasse tegelijk behoren. * **Overlappende subklassen:** Een object kan tot *meerdere* subklassen tegelijk behoren. Indien niet gespecificeerd, worden subklassen als overlappend beschouwd. **Voorbeeld van constraints:** Een "Account" (superklasse) kan "Betaalrekening" en "Spaarrekening" (subklassen) hebben. Als elke rekening *verplicht* een betaal- of spaarrekening moet zijn, is de specialisatie **compleet**. Als een rekening *nooit* zowel een betaal- als spaarrekening tegelijk kan zijn, zijn de subklassen **disjunct**. #### 4.1.5 Overerving en associaties Subklassen erven niet alleen attributen en operaties van hun superklassen, maar ook de associaties. * **Lezen van supertype naar subtype:** Een associatie die gedefinieerd is op de superklasse, geldt voor alle subklassen. * **Lezen van subtype naar supertype:** Subtypen erven de relaties en cardinaliteiten van het supertype. **Tip:** Als specifieke associaties tussen subtypes gewenst zijn (bijvoorbeeld dat "Vliegvluchten" alleen met "Vliegtuigen" kunnen worden geassocieerd en "Vrachtvluchten" met "Vrachtvliegtuigen"), moeten deze associaties expliciet op het niveau van de subklassen worden gemodelleerd, en de associatie op het niveau van de superklasse wordt dan verwijderd. ### 4.2 Aggregatie Aggregatie is een speciale vorm van associatie die een deel-geheel-relatie uitdrukt. #### 4.2.1 Basisconcept * Het drukt een relatie uit waarbij één object (het geheel) is samengesteld uit andere objecten (de delen). * Voorbeelden: een cursus bestaat uit modules, een order bestaat uit orderlijnen, een pakket bestaat uit items. #### 4.2.2 Notatie in UML * Een aggregatie wordt aangeduid met een diamantvorm aan de zijde van het "geheel". * **Witte diamant (Shared Aggregation):** De delen kunnen deel uitmaken van meerdere gehelen tegelijk. De relatie is niet exclusief. * **Voorbeeld:** Modules kunnen in verschillende cursussen gebruikt worden. * **Zwarte diamant (Composite Aggregation/Compositie):** Een deel behoort tot maximaal één geheel. Dit impliceert exclusief eigendom. * **Voorbeeld:** Een orderlijn hoort exclusief bij één specifieke order. #### 4.2.3 Kenmerken van Compositie * **Exclusief eigendom:** Een onderdeel kan maar bij één geheel horen. * **Cascading delete:** Wanneer het "geheel" wordt verwijderd, worden de bijbehorende onderdelen automatisch ook verwijderd. > **Tip:** De diamant-symbolen voor aggregatie kunnen vaak onduidelijkheid veroorzaken. Het wordt vaak aangeraden om gewone binaire associaties met duidelijke rolnamen te gebruiken, omdat deze de relatie duidelijker kunnen maken zonder de potentiële ambiguïteit van de diamant. ### 4.3 Ternaire associaties Soms volstaan binaire associaties (associaties tussen twee klassen) niet om complexe relaties tussen drie of meer entiteiten te beschrijven. #### 4.3.1 Noodzaak voor ternaire associaties * Wanneer een relatie tussen drie entiteiten cruciaal is en deze relatie niet adequaat kan worden uitgedrukt met drie aparte binaire associaties. * **Voorbeeld:** Het vastleggen welke leverancier welk product voor welk project heeft geleverd. Drie binaire many-to-many associaties tussen Leverancier, Product en Project zijn onvoldoende om te weten welke specifieke combinatie van leverancier, product en project daadwerkelijk heeft plaatsgevonden. #### 4.3.2 Notatie en interpretatie * Een ternaire associatie wordt weergegeven als een enkele lijn die drie klassen verbindt. * De multipliciteiten aan de uiteinden van de associatie worden op een subtielere manier geïnterpreteerd. Om de multipliciteit aan één kant te bepalen, worden de andere twee klassen gefixeerd. Vervolgens wordt gekeken hoeveel instanties van de derde klasse bij deze combinatie passen. **Voorbeeld:** Voor de associatie tussen `Leverancier`, `Product` en `Project`: Om de multipliciteit voor `Leverancier` te bepalen, fixeren we een combinatie van `Project` en `Product`. Vervolgens tellen we hoeveel `Leveranciers` deze specifieke combinatie hebben geleverd. Dit kan nul, één of meerdere leveranciers zijn. ### 4.4 Association Classes Een association class wordt gebruikt wanneer een attribuut of een operatie niet direct bij één van de twee geassocieerde klassen hoort, maar bij de relatie zelf. #### 4.4.1 Toepassingsgebied * Wanneer attributen expliciet bij de *relatie* tussen twee objecten horen, in plaats van bij de objecten zelf. * Wanneer de relatie existentieel afhankelijk is van beide objecten. **Voorbeeld:** De relatie tussen `Leverancier` en `Product`. De prijs van een product kan verschillen per leverancier. In dit geval hoort "prijs" niet bij `Leverancier` of `Product` alleen, maar bij de combinatie van een specifieke leverancier en een specifiek product. Dit kan worden gemodelleerd met een `ProductOffer` als association class met attributen zoals `prijs`, `leveringsvoorwaarden` en `gemiddelde levertijd`. #### 4.4.2 Verschil met gewone klassen * **Association Class:** Een object van een association class bestaat alleen zolang beide verbonden objecten bestaan. Het wijzigen van de link impliceert vaak het verwijderen en opnieuw creëren van de association class instantie. * **Gewone klasse:** Een object van een gewone klasse is niet strikt afhankelijk van de relatie. Relaties kunnen vaak onafhankelijk worden aangepast. ### 4.5 Afgeleide/Impliciete associaties Impliciete associaties ontstaan door navigatie over meerdere opeenvolgende associaties. Ze worden niet expliciet in het diagram getekend, maar zijn wel afleidbaar. #### 4.5.1 Ontstaan van impliciete associaties * Door het volgen van een pad van associaties tussen klassen ontstaat er een indirecte relatie. * **Voorbeeld:** Als een `Student` is geassocieerd met een `Programma`, en `Programma` is geassocieerd met een `Faculteit`, dan is er een impliciete associatie tussen `Student` en `Faculteit`. #### 4.5.2 Cardinaliteit De cardinaliteit (multipliciteit) van een impliciete associatie wordt afgeleid uit de cardinaliteiten van de oorspronkelijke relaties in het pad. **Voorbeeld:** Als elke `Student` minstens één `Programma` volgt (`1..*`) en elk `Programma` behoort tot minstens één `Faculteit` (`1..1`), dan behoort elke `Student` tot minstens één `Faculteit` (`1..1` minimum). Als een `Student` meerdere `Programma's` kan volgen, mogelijk aan verschillende `Faculteiten` (`*` maximum), dan kan een `Student` tot meerdere `Faculteiten` behoren (`*` maximum). > **Tip:** Wees je bewust van impliciete associaties bij het lezen van UML-diagrammen, omdat ze belangrijke informatie bevatten over de relaties in het domein die niet altijd expliciet worden weergegeven. ### 4.6 Ternaire associaties Soms volstaan binaire associaties (associaties tussen twee klassen) niet om complexe relaties tussen drie of meer entiteiten te beschrijven. #### 4.6.1 Noodzaak voor ternaire associaties * Wanneer een relatie tussen drie entiteiten cruciaal is en deze relatie niet adequaat kan worden uitgedrukt met drie aparte binaire associaties. * **Voorbeeld:** Het vastleggen welke leverancier welk product voor welk project heeft geleverd. Drie binaire many-to-many associaties tussen Leverancier, Product en Project zijn onvoldoende om te weten welke specifieke combinatie van leverancier, product en project daadwerkelijk heeft plaatsgevonden. #### 4.6.2 Notatie en interpretatie * Een ternaire associatie wordt weergegeven als een enkele lijn die drie klassen verbindt. * De multipliciteiten aan de uiteinden van de associatie worden op een subtielere manier geïnterpreteerd. Om de multipliciteit aan één kant te bepalen, worden de andere twee klassen gefixeerd. Vervolgens wordt gekeken hoeveel instanties van de derde klasse bij deze combinatie passen. **Voorbeeld:** Voor de associatie tussen `Leverancier`, `Product` en `Project`: Om de multipliciteit voor `Leverancier` te bepalen, fixeren we een combinatie van `Project` en `Product`. Vervolgens tellen we hoeveel `Leveranciers` deze specifieke combinatie hebben geleverd. Dit kan nul, één of meerdere leveranciers zijn. ### 4.7 Aggregatie Aggregatie is een speciale vorm van associatie die een deel-geheel-relatie uitdrukt. #### 4.7.1 Basisconcept * Het drukt een relatie uit waarbij één object (het geheel) is samengesteld uit andere objecten (de delen). * Voorbeelden: een cursus bestaat uit modules, een order bestaat uit orderlijnen, een pakket bestaat uit items. #### 4.7.2 Notatie in UML * Een aggregatie wordt aangeduid met een diamantvorm aan de zijde van het "geheel". * **Witte diamant (Shared Aggregation):** De delen kunnen deel uitmaken van meerdere gehelen tegelijk. De relatie is niet exclusief. * **Voorbeeld:** Modules kunnen in verschillende cursussen gebruikt worden. * **Zwarte diamant (Composite Aggregation/Compositie):** Een deel behoort tot maximaal één geheel. Dit impliceert exclusief eigendom. * **Voorbeeld:** Een orderlijn hoort exclusief bij één specifieke order. #### 4.7.3 Kenmerken van Compositie * **Exclusief eigendom:** Een onderdeel kan maar bij één geheel horen. * **Cascading delete:** Wanneer het "geheel" wordt verwijderd, worden de bijbehorende onderdelen automatisch ook verwijderd. > **Tip:** De diamant-symbolen voor aggregatie kunnen vaak onduidelijkheid veroorzaken. Het wordt vaak aangeraden om gewone binaire associaties met duidelijke rolnamen te gebruiken, omdat deze de relatie duidelijker kunnen maken zonder de potentiële ambiguïteit van de diamant. ### 4.8 Unary associaties Een associatie kan ook een klasse met zichzelf verbinden. #### 4.8.1 Basisconcept * Een unary associatie beschrijft een relatie waarbij instanties van dezelfde klasse met elkaar verbonden zijn. * **Voorbeelden:** Een persoon die een andere persoon superviseert, een hiërarchie van afdelingen, een stuklijst (bill of materials). #### 4.8.2 Notatie en interpretatie * Wordt getekend als een lijn die begint en eindigt bij dezelfde klasse. * Rollen worden gebruikt om de richting en aard van de relatie aan te geven (bijv. "superviseert" en "supervised by"). * Multipliciteiten worden ook hier toegepast om het aantal verbindingen te specificeren. > **Tip:** Zonder extra constraints (zoals OCL - Object Constraint Language) kan een unary associatie tot recursieve relaties leiden die mogelijk niet gewenst zijn (bijvoorbeeld een component die zichzelf gebruikt). ### 4.9 Ternaire associaties Soms volstaan binaire associaties (associaties tussen twee klassen) niet om complexe relaties tussen drie of meer entiteiten te beschrijven. #### 4.9.1 Noodzaak voor ternaire associaties * Wanneer een relatie tussen drie entiteiten cruciaal is en deze relatie niet adequaat kan worden uitgedrukt met drie aparte binaire associaties. * **Voorbeeld:** Het vastleggen welke leverancier welk product voor welk project heeft geleverd. Drie binaire many-to-many associaties tussen Leverancier, Product en Project zijn onvoldoende om te weten welke specifieke combinatie van leverancier, product en project daadwerkelijk heeft plaatsgevonden. #### 4.9.2 Notatie en interpretatie * Een ternaire associatie wordt weergegeven als een enkele lijn die drie klassen verbindt. * De multipliciteiten aan de uiteinden van de associatie worden op een subtielere manier geïnterpreteerd. Om de multipliciteit aan één kant te bepalen, worden de andere twee klassen gefixeerd. Vervolgens wordt gekeken hoeveel instanties van de derde klasse bij deze combinatie passen. **Voorbeeld:** Voor de associatie tussen `Leverancier`, `Product` en `Project`: Om de multipliciteit voor `Leverancier` te bepalen, fixeren we een combinatie van `Project` en `Product`. Vervolgens tellen we hoeveel `Leveranciers` deze specifieke combinatie hebben geleverd. Dit kan nul, één of meerdere leveranciers zijn. ### 4.10 Association Classes Een association class wordt gebruikt wanneer een attribuut of een operatie niet direct bij één van de twee geassocieerde klassen hoort, maar bij de relatie zelf. #### 4.10.1 Toepassingsgebied * Wanneer attributen expliciet bij de *relatie* tussen twee objecten horen, in plaats van bij de objecten zelf. * Wanneer de relatie existentieel afhankelijk is van beide objecten. **Voorbeeld:** De relatie tussen `Leverancier` en `Product`. De prijs van een product kan verschillen per leverancier. In dit geval hoort "prijs" niet bij `Leverancier` of `Product` alleen, maar bij de combinatie van een specifieke leverancier en een specifiek product. Dit kan worden gemodelleerd met een `ProductOffer` als association class met attributen zoals `prijs`, `leveringsvoorwaarden` en `gemiddelde levertijd`. #### 4.10.2 Verschil met gewone klassen * **Association Class:** Een object van een association class bestaat alleen zolang beide verbonden objecten bestaan. Het wijzigen van de link impliceert vaak het verwijderen en opnieuw creëren van de association class instantie. * **Gewone klasse:** Een object van een gewone klasse is niet strikt afhankelijk van de relatie. Relaties kunnen vaak onafhankelijk worden aangepast. ### 4.11 Afgeleide/Impliciete associaties Impliciete associaties ontstaan door navigatie over meerdere opeenvolgende associaties. Ze worden niet expliciet in het diagram getekend, maar zijn wel afleidbaar. #### 4.11.1 Ontstaan van impliciete associaties * Door het volgen van een pad van associaties tussen klassen ontstaat er een indirecte relatie. * **Voorbeeld:** Als een `Student` is geassocieerd met een `Programma`, en `Programma` is geassocieerd met een `Faculteit`, dan is er een impliciete associatie tussen `Student` en `Faculteit`. #### 4.11.2 Cardinaliteit De cardinaliteit (multipliciteit) van een impliciete associatie wordt afgeleid uit de cardinaliteiten van de oorspronkelijke relaties in het pad. **Voorbeeld:** Als elke `Student` minstens één `Programma` volgt (`1..*`) en elk `Programma` behoort tot minstens één `Faculteit` (`1..1`), dan behoort elke `Student` tot minstens één `Faculteit` (`1..1` minimum). Als een `Student` meerdere `Programma's` kan volgen, mogelijk aan verschillende `Faculteiten` (`*` maximum), dan kan een `Student` tot meerdere `Faculteiten` behoren (`*` maximum). > **Tip:** Wees je bewust van impliciete associaties bij het lezen van UML-diagrammen, omdat ze belangrijke informatie bevatten over de relaties in het domein die niet altijd expliciet worden weergegeven. --- ## Veelgemaakte fouten om te vermijden - Bestudeer alle onderwerpen grondig voor examens - Let op formules en belangrijke definities - Oefen met de voorbeelden in elke sectie - Memoriseer niet zonder de onderliggende concepten te begrijpen

| Term | Definition | |------|------------| | Informatiemanagement | Het systematisch plannen, organiseren, leiden en beheersen van alle activiteiten die verband houden met het verwerken en verspreiden van informatie binnen een organisatie, om strategische doelen te ondersteunen. | | Enterprise Architectuur | Een blauwdruk die de structuur en de operaties van een organisatie beschrijft, en die de relatie tussen businessstrategie en IT-infrastructuur faciliteert om bedrijfsdoelstellingen te bereiken. | | Conceptueel datamodel | Een abstracte weergave van data die de belangrijkste entiteiten, hun attributen en de relaties daartussen definieert, zonder specifieke technische implementatiedetails. | | Logisch datamodel | Een gedetailleerdere representatie van data die de structuur van de data beschrijft, inclusief tabellen, kolommen en relaties, maar nog steeds onafhankelijk is van specifieke databasesystemen. | | Fysiek datamodel | Een concrete implementatie van het logische datamodel, waarbij specifieke datatypes, indexen en andere databasedetails worden gedefinieerd die geschikt zijn voor een bepaald databasesysteem. | | UML Class Diagram | Een diagram uit de Unified Modelling Language dat de structuur van een systeem visualiseert door klassen, hun attributen, operaties en de relaties tussen klassen weer te geven. | | Klasse | Een blauwdruk voor objecten, die een concept of entiteit in een systeem vertegenwoordigt met gemeenschappelijke attributen en gedrag. | | Attribuut | Een eigenschap of karakteristiek van een klasse die specifieke informatie over een object opslaat, zoals een naam, een ID of een waarde. | | Datatype | Een classificatie die aangeeft welk soort waarde een attribuut kan bevatten en welke bewerkingen erop mogelijk zijn, zoals tekst, getal of datum. | | Associatie | Een relatie tussen twee klassen die aangeeft hoe objecten van die klassen met elkaar verbonden zijn, vaak met specificaties over multipliciteit. | | Multipliciteit | Een aanduiding in een UML-diagram die het aantal instanties van een klasse specificeert dat gerelateerd kan zijn aan één instantie van een andere klasse, uitgedrukt als reeksen zoals 0..1, 1..*, of *. | | Generalisatie | Een "is-een"-relatie waarbij een meer algemene klasse (supertype) de eigenschappen van één of meerdere meer specifieke klassen (subtypes) erft. | | Specialisatie | Het proces van het creëren van meer specifieke klassen (subtypes) die eigenschappen erven van een algemene klasse (supertype), waarbij unieke kenmerken kunnen worden toegevoegd. | | Aggregatie | Een speciaal type associatie dat een deel-geheel-relatie uitdrukt, waarbij de delen onafhankelijk van het geheel kunnen bestaan (shared aggregation) of er exclusief aan gebonden zijn (composite aggregation). | | Ternaire associatie | Een relatie die drie klassen tegelijkertijd verbindt, gebruikt wanneer een simpele binaire associatie niet voldoende is om de complexiteit van de interactie vast te leggen. | | Association Class | Een klasse die geassocieerd wordt met een relatie tussen twee andere klassen, wanneer de attributen en operaties specifiek bij die relatie zelf horen en niet bij de individuele klassen. | | Ontologie | Een formele specificatie van een gedeelde conceptionalisatie binnen een bepaald domein, die de begrippen, hun eigenschappen en de relaties daartussen definieert. | | TOGAF | The Open Group Architecture Framework; een uitgebreid framework voor enterprise architectuur dat een methode en tools biedt voor het ontwerpen, plannen, implementeren en beheren van enterprise informatiesarchitectuur. | | Zachman framework | Een ontologie voor Enterprise Architectuur, die een matrix biedt van zes fundamentele vragen (wat, hoe, waar, wie, wanneer, waarom) over een onderneming, onderverdeeld in zes perspectieven van architecten tot gebruikers. |