3.1 Opsomming data type

Deel I Hoofdstuk 3: Klasse Model gevorderd

© 2005 Prof Dr. O. De Troyer | Klasse Model - gevorderd pag. 1

3.1 Opsomming data type Opsomming (enumeration) data type Data type waarvan de verzameling waarden eindig en opsombaar is Voorbeelden: • Klasse Person, attribuut sex: {m, f} • Klasse Figure, attribuut penType: {solid, dashed, dotted} • Klasse TwoDimentional, attribuut fillType: {solid, grey, none, horizontal lines, vertical lines} Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 2

3.1 Opsomming data type

Colour: {red, yellow, green}

Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 3

3.1 Opsomming data type • Gebruik geen subklassen om enkel de waarden van een opsombaar attribuut weer te geven • Gebruik enkel subklassen indien ten minste 1 subklasse significant andere attributen, operaties of associaties heeft die niet van toepassing zijn voor het supertype


3.1 Opsomming data type UML notatie


3.2 Multipliciteit voor attributen Multipliciteit voor een attribuut Aantal mogelijke waarden voor het attribuut voor één instantie [1] [0 ..1] [*]

juist é én (verplicht enkelwaardig attribuut) optioneel enkelwaardig attribuut meerdere waarden

Default: [1]


Klasse multipliciteit Klasse multipliciteit Geeft aan hoeveel instanties de klasse kan hebben Default is 0 of meer (geen beperking) Soms is het nuttig om aan te duiden dat een klasse maar 1 instantie kan hebben


3.3 Klasse attributen en operaties Klasse attribuut is een (benoemde) eigenschap van de klasse zelf die een waarde beschrijft voor de klasse

Klasse operatie Een functie of een procedure die kan worden toegepast door de klasse Klasse attributen - voorbeelden: Mailbox: maxMessages, maxLengthMessage Klasse operaties - voorbeelden: creëer, totaalAantal, gemiddelde

UML notatie: klasse attribuut/operatie wordt onderlijnd Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 8

3.4 Zichtbaarheid Principe OO: Encapsulatie attributen en methoden zijn niet zichtbaar buiten de methoden van de klasse; operaties wel

• Veel OO-talen zondigen hier echter tegen – Public (‘+’): zichtbaar en vrij toegankelijk vanuit alle methoden – Protected (‘#’): enkel zichtbaar en toegankelijk vanuit methoden van de klasse en subklassen – Private (‘-’): enkel zichtbaar en toegankelijk vanuit methoden van de klasse – package (‘~’): enkel zichtbaar en toegankelijk vanuit methoden in hetzelfde package als de klasse Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 9

3.4 Zichtbaarheid • ‘Private’, ‘protected’ en ‘package’ operaties zijn meestal bedoeld als hulpoperaties • Vermijd het wijzigen van public operaties – Alle methoden die er gebruik van maken moeten gewijzigd worden

• Vermijd public attributen – Bemoeilijkt wijzigingen – Zondigt tegen het encapsulatie principe


3.5 N-aire associaties N-aire associatie associatie tussen drie of meer klassen

• Voorbeeld – Een programmeur gebruikt een programmeertaal in een project


3.5 N-aire associaties • Gebruik zoveel mogelijk binaire associaties • N-aire associaties kunnen in principe omgezet worden naar binaire associaties – Soms is een “abstracte” klasse nodig met een extra beperking


3.5 N-aire associaties

is verschillend van


3.5 N-aire associaties • Voorbeeld

Project Taal Persoon

Project Taal

Persoon

pr1

t1

p1

pr1

t2

p2

pr2

t2

p1

pr2

t1

p2

Project Taal

Project Persoon

Taal Persoon

pr1

t1

pr1

p1

t1

p1

pr1

t2

pr1

p2

t2

p2

pr2

t2

pr2

p1

t2

p1

pr2

t1

pr2

p2

t1

p2


pr1

t1

p1

pr1

t1

p2

pr1

t2

p1

pr1

t2

p2

pr2

t2

p1

pr2

t2

p2

pr2

t1

p1

pr2

t1

p2

3.5 N-aire associaties N-aire associatie heeft hier de voorkeur!

is equivalent met

+ met elke combinatie (project, persoon, programmeertaal) kan maar 1 taalgebruik (-object) overeenstemmen (“uniqueness constraint”) Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 15

3.5 Niet N-aire associaties Niet elementaire N-aire associatie

Kan worden omgezet zonder verlies van informatie naar:


3.5 Niet N-aire associaties Auteurschap

GeschrevenDoor

UitgegevenDoor

Boek Persoon Uitgever B1 A1 P1 B1 A2 P1 B1 A3 P1 B2 A3 P2

Boek Persoon B1 A1 B1 A2 B1 A3 B2 A3

Boek Uitgever B1 P1 B2 P2


3.5 N-aire associaties • Rolnamen kunnen ook gebruikt worden bij n-aire associaties – Verplicht wanneer een klasse in meer dan 1 n-aire associatie voorkomt

• N-aire associaties kunnen ook associatie klassen hebben


3.5 N-aire associaties • Multipliciteiten in n-aire associaties

• Aantal projecten waarin een bepaalde persoon kan deelnemen met een bepaalde programmeertaal • Aantal programmeertalen die een bepaalde persoon kan hanteren in een bepaald project • Aantal personen die kunnen meewerken in een bepaald project en een bepaalde programmeertaal Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 19

3.6 Aggregatie Aggregatie is een speciale associatie; de associatie modelleert een “deel-van” (part-of) relatie. Deze associatie verbindt een samengesteld object (“assembly”) met één van zijn onderdelen (“component”).

• Voorbeelden – Een grasmaaier model bestaat uit een mestype, een motortype, wielen van een welbepaald type en een kaptype – Een fiets model bestaat uit 2 wieltypen, een stuurtype, een frametype en een zadeltype Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 20

3.6 Aggregatie • Voorbeeld-1 – Grasmaaiertype bestaat uit een mestype, een motortype, wielen(type) en een kaptype UML notatie


3.6 Aggregatie • Voorbeeld-2 – Fietstype bestaat uit 2 wieltypen, een stuurtype, een frametype en een zadeltype


3.6 Aggregatie • Eigenschappen aggregatie associatie – Transitief • Als A deel is van B en B is deel van C dan is A deel van C

– Antisymmetrisch • Als A deel is van B dan is B geen deel van A

- Licht is een deel van Frame, Frame is deel van Fiets dus Licht is deel van Fiets - Wiel is deel van Fiets maar Fiets is geen deel van Wiel


3.6 Aggregatie vs Associatie • Wanneer aggregatie - Mogelijke vragen: – Kan je spreken van een “deel-van” relatie? • Fiets-Wiel: een wiel is een deel van een fiets • Werknemer-Bedrijf: een werknemer is geen deel van een bedrijf

– Propageren sommige operaties zich automatisch naar de componenten? • Produceer fiets --> produceer wiel

– Propageren sommige attribuutwaarden zich naar de componenten? • Producent fiets

– Is er sprake van een intrinsieke asymmetrie? Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 24

3.7 Compositie Compositie beperktere vorm van aggregatie: • het onderdeel is slecht deel van maximaal 1 assembly • het onderdeel bestaat zolang de assenbly bestaat

• Voorbeelden – Een fysieke grasmaaier bestaat uit een mes, een motor, wielen en een kap. Elk van de onderdelen kan maar deel uitmaken van 1 enkele grasmaaier! – Een fysieke fiets bestaat uit 2 wielen, een stuur, een frame en een zadel. Elk van de onderdelen kan maar deel uitmaken van 1 enkele fiets! Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 25

3.7 Compositie • Voorbeeld-1 – Een grasmaaier bestaat uit een mes, een motor, wielen en een kap. Elk van de onderdelen kan maar deel uitmaken van 1 enkele grasmaaier! UML notatie


Bij een compositie is de multipliciteit: 1 of 0..1

3.7 Compositie • Voorbeeld-2 – Fiets bestaat uit 2 wielen, een stuur, een frame en een zadel. Elk van de onderdelen kan maar deel uitmaken van 1 enkele fiets!


3.7 Compositie • Voorbeeld-3 – Een bedrijf bestaat uit divisies; een divisie bestaat uit departementen en werknemers werken voor een bedrijf


3.8 Propageren van operaties • Voorbeeld – Een document bestaat uit paragrafen en een paragraaf bestaat uit karakters. • Het kopiëren van een document impliceert het kopiëren van paragrafen en dit impliceert het kopiëren van karakters • Een paragraaf kan echter gekopieerd worden zonder het volledige document te moeten kopiëren. Idem voor karakters


3.8 Propageren van operaties - notatie – Een document bestaat uit paragrafen en een paragraaf bestaat uit karakters.

Notatie maakt geen deel uit van UML - wel handig Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 30

3.9 Abstracte klassen Abstracte Klasse Klasse die geen instanties heeft maar met subklassen (directe of indirecte) die wel instanties hebben

Concrete Klasse Klasse die instanties heeft • Voorbeelden – “Figuur” is een abstracte klasse – “Vierkant”, “Rechthoek” en “Cirkel” zijn concrete klassen

De abstracte klasse is een veralgemening van de concrete klassen Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 31

3.9 Abstracte klassen -UML notatie • Voorbeeld

Naam klasse in schuin of Naam gevolgd door {abstract}

Alle bladeren in de boom moeten concrete klassen zijn


3.9 Abstracte klassen • Waarom abstracte klassen? – Om gemeenschappelijke attributen en/of operaties te specificeren • Operaties kunnen abstract zijn (zonder implementatie). De implementatie wordt dan gegeven in de concrete klassen.

• Concrete klassen mogen geen abstracte operaties meer hebben! Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 33

3.9 Abstracte klassen


3.9 Abstracte klassen


3.10 Multiple Inheritance Multiple inheritance Wanneer een klasse meerdere superklassen kan hebben en van al deze superklassen kan erven – Voordeel: • Krachtig • Bevordert hergebruik

– Nadeel • Conflicten mogelijk • Meeste programmeertalen ondersteunen geen multiple inheritance Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 36

3.10 Multiple Inheritance • Voorbeeld


3.10 Multiple Inheritance Workarounds - gebruik makend van delegatie


3.10 Multiple Inheritance Workarounds - gebruik makend van combinatie inheritance en delegatie


3.10 Multiple Inheritance Workarounds - uitsplitsing van de subtypes


3.10 Multiple Inheritance • Workarounds – Delegatie: bij verschillende subklassen allen van gelijk belang – Delegatie + inheritance: wanneer 1 subklasse duidelijk dominant (belangrijker) is – Uitsplitsen: wanneer aantal combinaties beperkt is en duplicatie van beperkt is • Gebruik voor subklassering eerst het meest belangrijk criterium Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 41

3.11 Metadata MetaData data die andere data beschrijft Voorbeeld • Klasse definitie – Beschrijft een klasse

• Modellen – Beschrijven de dingen die men modelleert

• Soms bevatten modellen ook Metadata: – Een automodel is metadata voor een fysieke auto. Beide klassen (Auto en AutoModel) kunnen voorkomen in een model Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 42

3.13 Beperkingen (“Constraints”) Beperking (constraint) een waar/onwaar uitdrukking gebaseerd op modelelementen die een beperking uitdrukt op mogelijke waarden en/of relaties Voorbeelden: • Salaris van een werknemer kan niet hoger zijn dan het salaris van de baas van deze werknemer • Het salaris van een werknemer mag niet dalen • De verhouding lengte/breedte van een schermvenster mag niet kleiner zijn dan 0.8 en niet groter dan 1.5


3.13 Beperkingen (“Constraints”) Constraints kunnen uitgedrukt worden in • natuurlijke taal of • via een constraint taal, bijv. OCL (Object Constraint Language) - zie later Constraints voor de instances van een klasse

{salaris ≤ baas.salaris} {salaris never increases} Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 44

{0.8 ≤ lengte/breedte ≤1.5}

3.13 Beperkingen (“Constraints”) Constraints op subklassen • Impliciete constraints – Zonder multiple inheritance zijn subklassen disjunct

• UML voorziet – “Disjoint”: de subklassen zijn disjunct. Elke instantie behoort tot hoogstens één subklasse – “Overlapping”: een instantie kan tot verschillende subklassen behoren – “Complete”: Elke instantie behoort tot minstens één subklasse – “Incomplete”: Niet elke instantie behoort tot een subklasse


3.13 Beperkingen (“Constraints”) -UML notatie


3.13 Beperkingen (“Constraints”) Constraints op links • Multipliciteit – Beperkt het aantal objecten die kunnen gerelateerd zijn via een associatie met een bepaald object

• {ordered} geeft aan dat er een expliciete order is op de verzameling objecten gerelateerd via een associatie met een bepaald object • Idem voor {sequence} en {bag}


3.13 Beperkingen (“Constraints”) Constraints op links (vervolg) • Expliciete constraints op links – Subset: deelverzameling vereist tussen verzameling van links – Equality: verzameling van links moet gelijk zijn – Exclusion: verzamelingen van links moeten disjunct zijn


3.13 Beperkingen (“Constraints”) • Probeer zo veel mogelijk constraints te specificeren – Verhoogt de kwaliteit van het model

• Notatie voor constraints – Tussen ‘{‘ en ‘}’ – In commentaar box • Stippellijn/stippellijnpijl om elementen in een constraint te verbinden

• OCL (zie later)


3.14 Afleidbare informatie Afleidbaar element element afleidbaar van ander elementen door middel van een functie

• Klassen, attributen en associaties kunnen afleidbaar zijn • UML notatie: ‘/’


3.14 Afleidbare informatie

Voeg enkel afleidbare elementen toe indien belangrijk of noodzakelijk (bijv. voor het gemak bij implementatie) Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 51

3.15 Packages Package groep elementen met een gemeenschappelijk thema

• Een package kan andere packages bevatten • Is een abstractie mechanisme


3.15 Packages • Denk goed na over de mogelijke opdeling in packages • Klassennamen en associatienamen moeten uniek zijn binnen een package • Probeer de overlap tussen packages te beperkingen – Zet associaties en subklassen in hetzelfde package

• Een mogelijke benadering – Definieer een package voor elke klasse met de volledige definitie van de klasse. – In andere packages kan men dan de eenvoudige rechthoek notatie voor de klasse gebruiken – de diagrammen worden luchtiger Objectgerichte modelleertechnieken © 2005 Prof. Dr. O. De Troyer | Klasse Model - gevorderd pag. 53

3.1 Opsomming data type

Recommend Documents