Basisonderdelen van een klassendiagram
Afhankelijk van de context kunnen klassen in een klassendiagram de hoofdobjecten, interacties in de applicatie of de te programmeren klassen vertegenwoordigen. Om de vraag "Wat is een klassendiagram in UML?" te beantwoorden, moet je eerst de basisopbouw begrijpen.
- Klassen: een sjabloon voor het maken van objecten en het implementeren van gedrag in een systeem. In UML vertegenwoordigt een klasse een object of een reeks objecten die een gemeenschappelijke structuur en gedrag delen. Ze worden weergegeven door een rechthoek met rijen voor de klassenaam, de attributen en de bewerkingen. Wanneer je een klasse in een klassendiagram tekent, hoef je alleen de bovenste rij in te vullen — de andere zijn optioneel als je meer details wilt toevoegen.
- Signalen: symbolen die eenrichtings-, asynchrone communicatie tussen actieve objecten vertegenwoordigen.
- Datatypen: classifiers die gegevenswaarden definiëren. Datatypen kunnen zowel primitieve typen als enumerations modelleren.
- Packages: vormen die zijn ontworpen om gerelateerde classifiers in een diagram te ordenen. Ze worden gesymboliseerd door een grote rechthoekvorm met een tabblad.
- Interfaces: een verzameling bewerkingssignaturen en/of attribuutdefinities die een samenhangende set gedragingen definiëren. Interfaces lijken op klassen, met het verschil dat een klasse een instantie van zijn type kan hebben en een interface ten minste één klasse moet hebben die deze implementeert.
- Enumerations: representaties van door de gebruiker gedefinieerde datatypen. Een opsomming bevat groepen id's die waarden van de opsomming vertegenwoordigen.
- Objecten: instanties van een of meer klassen. Objecten kunnen aan een klassendiagram worden toegevoegd om concrete of prototypische instanties te vertegenwoordigen.
- Artifacts: modelelementen die de concrete entiteiten in een softwaresysteem vertegenwoordigen, zoals documenten, databases, uitvoerbare bestanden, softwarecomponenten, enz.
Secties binnen een klasse
De standaardklasse bestaat uit drie secties:
Bovenste sectie
Bevat de naam van de klasse. Deze sectie is altijd vereist, of het nu gaat om de classifier of een object. De klassenaam moet:
- Met een hoofdletter beginnen.
- Vetgedrukt zijn.
- In de bovenste sectie gecentreerd zijn.
- Beschrijvend zijn.
Middelste sectie
Bevat de attributen van de klasse. Gebruik deze sectie om de eigenschappen van de klasse te beschrijven. Dit is alleen vereist bij het beschrijven van een specifieke instantie van een klasse.
Onderste sectie
Bevat de klassebewerkingen (methoden). Deze worden in lijstvorm weergegeven, waarbij elke bewerking een eigen regel inneemt. De bewerkingen beschrijven hoe een klasse met gegevens omgaat. De tekst in de onderste twee secties is meestal links uitgelijnd en begint met een kleine letter.
Toegangsspecificaties (access modifiers)
Alle klassen hebben verschillende toegangsniveaus, afhankelijk van de toegangsspecificatie (zichtbaarheid). Dit zijn de toegangsniveaus met de bijbehorende symbolen:
- Public (+)
- Private (-)
- Protected (#)
- Package (~)
- Afgeleid (/)
- Statisch (onderstreept)
Bereik van elementen (member scopes)
Er zijn twee bereiken voor elementen: classifiers en instanties.
Classifiers worden vaak herkend als statisch, wat betekent dat attribuutwaarden in alle instanties hetzelfde blijven en dat het aanroepen van methoden de status van de instantie niet beïnvloedt. Instanties bevatten daarentegen methoden die de status van de instantie kunnen veranderen en attribuutwaarden die per instantie kunnen verschillen. Om een classifier aan te geven, onderstreep je de naam; laat de tekst normaal om een instantie aan te geven.
Interacties
De term "interacties" verwijst naar de verschillende relaties en koppelingen die kunnen bestaan in klassen- en objectdiagrammen. Enkele van de meest voorkomende interacties zijn:
Overerving: het proces waarbij een subklasse de functionaliteit van een superklasse overneemt, ook wel generalisatie genoemd. Dit wordt gesymboliseerd door een rechte verbindingslijn met een gesloten pijlpunt die naar de superklasse wijst.
In dit voorbeeld erft het object "Auto" alle attributen (snelheid, aantal passagiers, brandstof) and methoden (gaan(), stoppen(), richtingVeranderen()) van de bovenliggende klasse ("Voertuig"), naast de specifieke attributen (modeltype, aantal deuren, autofabrikant) en methoden van de eigen klasse (Radio(), ruitenwisser(), airco/verwarming()). Overerving wordt in een klassendiagram weergegeven met een ononderbroken lijn met een gesloten, oningevulde pijl.
Bidirectionele associatie: de standaardrelatie tussen twee klassen. Beide klassen zijn zich bewust van elkaar en hun relatie met de andere klasse. Deze associatie wordt weergegeven door een rechte lijn tussen twee klassen.
In het bovenstaande voorbeeld zijn de klasse Auto en de klasse RoadTrip aan elkaar gerelateerd. Aan het ene uiteinde van de lijn neemt de Auto de associatie "assignedCar" aan met de multipliciteitswaarde 0..1. Dus wanneer de instantie van RoadTrip bestaat, kan er één instantie van Auto aan gekoppeld zijn, of geen. In dit geval is een aparte klasse Caravan met een multipliciteitswaarde van 0..* nodig om aan te tonen dat een RoadTrip meerdere instanties van Auto's aan zich gekoppeld kan hebben. Aangezien één Auto-instantie meerdere "getRoadTrip"-associaties kan hebben — met andere woorden, één auto kan meerdere roadtrips maken — is de multipliciteitswaarde ingesteld op 0..*
Unidirectionele associatie: een iets minder vaak voorkomende relatie tussen twee klassen. De ene klasse is zich bewust van de andere en heeft er interactie mee. Een unidirectionele associatie wordt gemodelleerd met een rechte verbindingslijn die een open pijlpunt van de wetende klasse naar de bekende klasse richt.
Als voorbeeld: tijdens je roadtrip door Arizona kom je een snelheidscontrole tegen waarbij een flitspaal je rijgedrag registreert, maar dat weet je pas als je een melding in de brievenbus krijgt. Het is niet in de afbeelding getekend, maar in dit geval zou de multipliciteitswaarde 0..* zijn, afhankelijk van hoe vaak je langs de flitspaal rijdt.
