Ga naar hoofdinhoud

Criteria voor Klassendiagrammen van het domein

Klassen

Alleen klassen uit het domein moeten in het klassendiagram worden opgenomen.

De klassen die niet in het domein voorkomen maar wel nodig zijn om een programma te kunnen laten werken, hoeven niet te worden opgenomen.

Avoid primitive obsession

Probeer zoveel mogelijk concepten uit het domein als klasse te modelleren en niet als primitief datatype.

Vaak kan een concept als primitief type worden gerepresenteerd, maar gelden er een paar extra regels. Je maakt dan een klasse om deze regels makkelijk af te kunnen dwingen.

Attributen en operaties

Als je al een idee hebt over belangrijke attributen en operaties, dan kun je die ook alvast toevoegen.

Als je de datatypes al weet dan kun je deze erbij zetten. Je mag hiervoor de UML-notatie gebruiken, of de Java-notatie.

Je hoeft niet aan te geven of deze attributen en operaties public, private of protected zijn (maar dat mag wel).

Entiteiten en Value Objects

Van elke klasse moet worden aangegeven of het een Entity of een Value Object is aan de hand van de stereotype-notatie

Entiteiten moeten een attribuut hebben dat als id fungeert.

Relaties

Associaties moeten worden opgenomen in het klassendiagram en moeten de volgende onderdelen bevatten:

  • Multipliciteiten
  • Rollen
  • Navigatie

De rol mag op de associatiepijl staan, maar ook als attribuut opgenomen worden in de klasse waar de rol bij hoort.

Inheritance mag je gebruiken als je denkt dat dit nodig is.

De relaties compositie, aggregate en dependency hoef je niet te gebruiken.

tip

PlantUML heeft soms wat moeite een handige layout te genereren en plaatst rolnamen soms op een erg onhandige plek. De layout is te beïnvloeden, al is dit door plantUML zelf afgeraden om te doen. Zie bijvoorbeeld de PlantUML Hitchhiker's guide .

info
Domein (Ubiquitous language)

De informatie uit klassendiagram moet zo goed mogelijk overeenkomen met andere bronnen die het domein beschrijven (waaronder domain stories).

DDD: Ubiquitous Language (extra/optioneel)

Het laatste criterium 'Domein' komt overeen wat men in DDD jargon de Ubiquitous Language noemt. Ubiquitous Language is een 'strategic pattern', en volgens sommigen zelfs het belangrijkste pattern uit Domain Driven Design. Deze hangt samen met een ander DDD pattern Bounded Context. Je hoeft deze twee voor de toets niet te kennen, maar hieronder meer info als achtergrond.

Ubiquitous Language​

Deze term hoef je nu nog niet kennen, maar je moet hem wel begrijpen ;). De term 'Ubiquitous language' komt veel voor in het 'Domain Storytelling' boek van Stefan Hofer en Henning Schwentner, alleen niet in de stukken die in de reader staan. Sowieso kunnen we in deze course NIET alles van DDD behandelen. Daarom hieronder deze quote uit H9 - 'Learning Domain Language' van het boek (Hover, 2021):

"Once you are able to speak a domain language, you can talk about requirements more effectively. We will show you more ways Domain Storytelling can help you with requirements elicitation in Chapter 11, “Working with Requirements.” The language becomes ubiquitous through being used in the source code. Which domain terms to use as names for classes, methods, functions, and variables is the topic of Chapter 12, “Modeling in Code.”

Ubiquitous betekent 'alomvertegenwoordigd' en dit gaat over het streven naar een gemeenschappelijke taal die iedereen gebruikt binnen een project/bedrijf. Dus zowel door opdrachtgevers, ontwikkelaars, product owner, gebruikers, testers, etc. Ubiquitous language komt er voor een developer een beetje op neer dat je de woorden in je domain story NIET zelf verzint, maar van business experts overneemt, of van ze uitvraagt. Of - als je erg aan het innoveren bent - samen afstemt.

Bijvoorbeeld in een Onderwijs domein spreekt men of wel van een "leerling" in het lager onderwijs, maar meestal over "student" op het MBO, HBO, etc. Als je een applicatie maakt voor een MBO school, dan moet je dus de term "student" gebruiken en niet "leerling". En als je nieuwe applicatie maakt om een nieuwe vorm van onderwijs te ondersteunen, dan moet je samen met de experts bepalen welke termen je gaat gebruiken.

Bounded Context​

Overigens kan één woord voor bijvoorbeeld verschillende bedrijfsafdelingen wel voor erschillende betekenissen hebben. Dit kan verwarrend zijn, zeker als je een 'precies' software applicatie moet schrijven. Het is dan de kunst om de juiste betekenis te achterhalen en te gebruiken voor jouw applicatie. Dit hoort bij een ander 'strategic' pattern uit DDD: 'Bounded Context'

Hieronder als concreet voorbeeld is dit weergegeven in een klassendiagram met hierin via 'package syntax' verschillende bounded context. Een keer een Onderwijsadministratie en een Digitaal Leerplatform. Deze hebben verschillende relevante Entiteiten hebben zoals gekozen Opleiding voor Studentenadministatie en Quizzes voor DLP. Maar beide delen de entiteit Student. Alleen van een student zijn in de twee verschillende context hele andere informatie (velden/attributen) en andere activiteiten/bedrijfsprocessen (methodes) relevant.

Biedt weerstand tegen de neiging om de 'one system to rule them all' te maken en alle velden en methodes te combineren. Object Oriented Programmeren biedt opties zoals overerving etc. om dit mogelijk te maken. Maar zoals Martin Fowler zegt:

"Total unification of the domain model for a large system will not be feasible or cost-effective." - Fowler (2014))

Dit onderstreept het belang van het expliciet definiëren van Bounded Contexts om complexiteit te beheersen en domeinexpertise effectief te benutten.

9b78f3357d34b1c05f049bcece24afaf

PlantUML broncode voor "Voorbeeld Stereotypes"

    package Onderwijsadministratie {
    class Student {
        + studentnummer: String
        + naam: String
        + geboortedatum: Date
        + studiepunten: Integer
        + startDatum: Date
        + eindDatum: Date
        --
        + inschrijven(opleiding)
        + uitschrijven(opleiding)
        + toonStudievoortgang()
    }

    class SLBer {
        naam: String
    }

    class Opleiding {
        naam: String
    }

    Student "*" <-- "1" SLBer: begeleid

    Student "*" --> "1" Opleiding: "primaire opleiding"

    }

    package "Digitaal Leer Platform" {

    class Student {
        + studentnummer: String
        + toegangsniveau: String
        + deadlineHerinneringen: List<Date>
        --
        + uploadOpdracht(bestand)
        + bekijkFeedback(opdrachtID)
        + startQuiz(quizID)
        + bekijkLesmateriaal(cursusID)
    }

    class Cursus {
        naam: String
        versie: Versie
    }

    class Quiz {
        naam: String
        vragen: List<Vraag>
    }

    Student "*" <--> "*" Cursus: "volgt"
    Student "1" <--> "*" Quiz: "voltooide quizzen"
    Quiz "*" <--right> "1" Cursus: "quizzen"
    }

Klassendiagram met 5 klasse(n) en 5 relatie(s).

Klassen:

  • Klasse Student met:
    • publieke methode 'inschrijven', met parameter(s) 'opleiding', return type void
    • publieke methode 'uitschrijven', met parameter(s) 'opleiding', return type void
    • publieke methode 'toonStudievoortgang', zonder parameters, return type void
    • publieke methode 'uploadOpdracht', met parameter(s) 'bestand', return type void
    • publieke methode 'bekijkFeedback', met parameter(s) 'opdrachtID', return type void
    • publieke methode 'startQuiz', met parameter(s) 'quizID', return type void
    • publieke methode 'bekijkLesmateriaal', met parameter(s) 'cursusID', return type void
    • publieke attribuut 'studentnummer' van type String
    • publieke attribuut 'naam' van type String
    • publieke attribuut 'geboortedatum' van type Date
    • publieke attribuut 'studiepunten' van type Integer
    • publieke attribuut 'startDatum' van type Date
    • publieke attribuut 'eindDatum' van type Date
    • private attribuut '-'
    • publieke attribuut 'studentnummer' van type String
    • publieke attribuut 'toegangsniveau' van type String
    • publieke attribuut 'deadlineHerinneringen' van type List van Date
    • private attribuut '-'
  • Klasse SLBer met:
    • publieke attribuut 'naam' van type String
    • geen methoden
  • Klasse Opleiding met:
    • publieke attribuut 'naam' van type String
    • geen methoden
  • Klasse Cursus met:
    • publieke attribuut 'naam' van type String
    • publieke attribuut 'versie' van type Versie
    • geen methoden
  • Klasse Quiz met:
    • publieke attribuut 'naam' van type String
    • publieke attribuut 'vragen' van type List van Vraag
    • geen methoden

Relaties:

  • SLBer heeft een associatie-relatie met naam 'begeleid' met Student, multipliciteit 1 naar *
  • Student heeft een associatie-relatie met naam '"primaire opleiding"' met Opleiding, multipliciteit * naar 1
  • Student heeft een associatie-relatie met naam '"volgt"' met Cursus, multipliciteit * naar *
  • Student heeft een associatie-relatie met naam '"voltooide quizzen"' met Quiz, multipliciteit 1 naar *
  • Cursus heeft een associatie-relatie met naam '"quizzen"' met Quiz, multipliciteit 1 naar *

Bronnen​