OBT_Hoofdstuk_3_(2013)_Snoeck

Ontwikkeling van bedrijfstoepassingen
Hoofdstuk 3: Static Business Modelling
3.1 WAT IS MODELLEREN
Er zijn twee perspectieven op software
- Engineering perspectief: software is an artefact that will
- design
- build
- test (inspectie en validatie)
- deploy
- Wiskundigperspectief: software is een wiskundige abstractie
--> een theorie die men kan analyseren op consistentie en men kan nauwkeuriger kan maken
naar een meer gespecialiseerde theorie
3.2 ENGINEERING PERSPECTIEF
Software is hier een ARTEFACT
Analyst: zoek welk probleem met moet oplossen via software
--> hij interviewt de sleutelgebruikers en/of opdrachtgever
Het interview bestaat uit verschillende “cases”
Men gaat het probleem aanreiken via een use case
--> Waarvoor wenst u het systeem te gebruiken?
Use cases: exemplarisch karakter waarvoor men het systeem wil gebruiken (voorbeelden geven)
! Dit is niet hetzelfde als een prototypisch karakter (dit is echt de functie omschrijven)
Een goed systeem gaat alle exemplarische use cases ondersteunen
Voorbeeld: 1 + 1 , 2 + 2, 5 + 5, ...
Software is hier een ARTEFACT that will DESIGN
Men ontwerpt een oplossing door het maken v/e schets
--> plan van hoe men een oplossing kan bouwen
Model: plan v/h te ontwerpen systeem
Men kan geen oplossing zoeken zonder:
- de noden v/d gebruiker goed te kennen
- het op te lossen probleem goed te analyseren
Het model moet bij voorkeur:
- het probleemdomein beschrijven
- een blauwdruk zijn v/d oplossing zelf
Bij het opstellen v/h model moet men zich het perspectief kunnen aannemen v/d:
- Opdrachtgever
- Gebruiker
! Niet standpunt v/d bouwer innemen (aannemer), wel v/d architect v/d bouwheer
1
Jeroen De Koninck – HIRB – 2012-2013
Lastenboek: perspectief v/d opdrachtgever
--> beschrijft alle vereisten die de opdrachtgever heeft ten aanzien v/h te bouwen systeem
Er zijn twee grote categorieën van vereisten:
- functionele vereisten: beschrijft wat het systeem moet kunnen doen vanuit het perspectief
v/d opdrachtgever (Voorbeelden: zaken registreren, opvragen, ...)
- Niet-functionele vereisten: beschrijf hoe men de zaken moet realiseren
Voorbeelden: kwaliteit, performantie, technologie, responstijden, standaarden, ...
CIO: Chief Information Officer
! Kwaliteit v/h lastenboek is een primaire risicofactor voor projecten
--> heeft grote impact op de business
Probleemdomein:
- draagt bij tot de kwaliteit v/h lastenboek en is een risicoverlagende factor v/d projecten
- draagt bij tot het goed begrijpen v/h domein en geeft een beeld v/d verbeteringen
Universe of discource omschrijf het model v/h probleemdomein om een prototypische manier
--> geeft abstracte omschrijving die geldig is voor concrete feiten in het domein
Er zijn twee niveaus van denken:
- Level 1: model niveau
- Level 0: voorbeeld niveau
Voorbeeld:
Level 1
Level 0
Model niveau
* Persoon
* Product
* Opleidingsonderdeel
Voorbeeld niveau * Jan, Tom, Tim, Jos
* Dell Latitude D800, Dell XPS 1330, Peugeot 807
* OBT, Inleiding tot Economisch Recht
Modelleren is abstraheren: men gaat van level 0 naar level 1
Inspecteren is van level 1 naar level 0 gaan
3.2.1 Wiskundig perspectief
Software is a mathematical ABSTRACTION
Op level 0 vinden we de elementen v/d verzameling
Op level 1 vinden we de definitie v/d verzameling
Level 1
Level 0
2
Model niveau
* PERSOON = {p | p is een persoon}
* PRODUCT = {p | p is een product}
* OPLEIDINGSONDERDEEL = {o |o is een opleidingsonderdeel)
Voorbeeld niveau * PERSOON = {Jan, Tom, Tim, Jos}
* PRODUCT = {Dell Latitude D800, Dell XPS 1330, Peugeot 807}
* OPLEIDINGSOND. = {OBT, Inleiding tot Economisch Recht}
Jeroen De Koninck – HIRB – 2012-2013
Modelleren bevat bijgevolg volgende taken:
- Verzamelingen definiëren
- Eigenschappen v/d elementen beschrijven
- Verbanden leggen tussen verzamelingen en hun elementen definiëren
- ...
Software is a mathematical ABSTRACTION, a theory which ca, be ANALYZED FOR CONSISTENCY
Model moeten we ook kunnen valideren:
- Kunnen we het model instantiëren: (EXTERNE VALIDATIE)
--> de verzameling voorzien van elementen en na gaan of de gedefinieerde verbanden en die
we kunnen afleiden overeenkomen met de werkelijkheid
--> overgang van level 1 naar level 0
- Redeneren op het model: (INTERNE VALIDATIE)
--> toepassen van axioma’s en stellingen die we kennen uit de verzamelingenleer en algebra
--> analyse of het model consistent is
3.2.2 Modelleringstaal
Model neerschrijven kan via bepaalde taal
Lastenboek kan men neerschrijven via
- Natuurlijke taal (Nederlands, Engels)
- Specifieke taal (symbolen gebonden aan concepten)
Men gaat dus zaken omschrijven (natuurlijke taal) en schetsen (specifieke taal)
UML: de industriestandaard voor de schetsen (Unified Modeling Language)
--> veel technieken elk beschrijving v/e apart aspect v/h systeem
! Doel: neerschijven v/e oplossing (beschrijven)
MAAR: men kan UML ook aanwenden voor het beschrijven v/h probleemdomein
--> men zal minder technische details voorzien naar de opdrachtgever, dan naar de eigenlijke bouwer
We gebruiken een subset van UML
--> We beperken ons tot de technieken als communicatie met de eindgebruiker
(Deze cursus: geen technische implementatiedetails communiceren)
UML kan men vertalen naar Algebra
Het wiskundig perspectief helpt ons om:
- betekenis v/e UML-schema te definiëren
- abstract denken te stimuleren
- instrument ter validatie van modellen
3
Jeroen De Koninck – HIRB – 2012-2013
3.2.2.1 Terminologie
Modelleringstaal: geheel van technieken bedoeld voor het neerschrijven van specificaties (vb UML)
Modelleringstechniek: samenhangend geheel van symbolen en regels
--> laten toe bepaald aspect v/d software te modelleren
- UML Class Diagramming
- ER Modellering
- Data Flow Diagramming
- Use Case Diagramming
- BPMN: Business Process Modelling Notation
Diagram(ma), schema of model: model/tekening opstellen volgens bepaalde techniek
- UML Class Diagramming voor verkoopsysteem
- ER Modellering voor ISP-systeem
- BPMN schema voor afhandeling bouwaanvraag
3.3 KLASSEN OF OBJECTTYPES
Wiskundige weergave:
- Verzameling: ovaal
- Elementen: punten
ZIE VOORBEELD PAGINA 10
UML heef eigen symboliek voor elk concept in een model
--> Verzamelingen (klasse): rechthoekige vorm met naam v/d verzameling
--> Elementen (objecten): via een objectdiagram
! Een verzameling wordt dus een klasse in UML
! Een element wordt dus een object in UML
We beschrijven de objecten aan de hand v/e aantal eigenschappen
--> Statische eigenschappen: eigenschappen die elk object altijd bezit (waarde kan variëren)
Men noemt dit attributen
--> Men schrijft deze onder de klassenaam in de rechthoek v/d klasse
Voorbeeld:
Een product heeft een: - nummer
- naam
- omschrijving
- hoeveelheid
Elk object krijgt een waarde voor elk attribuut
! Kan variabel zijn doorheen de tijd
4
Jeroen De Koninck – HIRB – 2012-2013
Voorbeeld: een product met volgende waarden:
- Nummer: 123456
- Naam: MilkyWay
- Omschrijving: Snoepreep
- Hoeveelheid in voorraad: 45
Uiteraard kunnen de variabelen veranderen, voornamelijk in dit geval de voorraad
Men gaat dit gieten als:
PRODUCT
Nummer
Naam
Omschrijving
Voorraad
PRODUCT
123456
MilkyWay
Snoepreep
45
Invullen:
3.4 ASSOCIATIES: VERBANDEN TUSSEN KLASSEN
3.4.1 Algemeen principe
Sommige objecten uit een klasse hebben verbanden met andere objecten uit andere klassen
Deze verbanden kan men wiskundig definiëren als afbeeldingen tussen verzamelingen
- Afbeelding f van A naar B: functie die element uit A afbeeldt op element van B
--> A is hierbij het domein en B is het beeld
Element uit A = x-waarde
Element uit B = y-waarde
Domein: alle x-waarden
Beeld: alle y-waarden
f: A -> B : a -> f(a)
met a element van A en f(a) deelverzameling van B
“De afbeelding v/e een element (a) van A wordt gezocht in B en noemt zal f(a) zijn”
Verbanden gaan in beide richtingen
- door: GIFT -> PERSOON: g -> door(g)
“een gift g uit klasse GIFT werd gedaan door een persoon uit klasse PERSOON door(g)”
- voor: GIFT -> PROJECT: g -> voor(g)
“een gift g uit klasse GIFT werd gedaan voor een project uit klasse PROJECT voor(g)”
Verbanden kunnen nu ook omgekeerd lopen:
- door-1 (gaf): PERSOON -> GIFT: p -> door-1(p)
“een persoon p uit klasse PERSOON gaf een gift uit klasse GIFT door-1(p)”
- voor-1 (kreeg): PROJECT -> GIFT: p -> voor-1(p)
“en project p uit klasse PROJECT kreeg een gift uit klasse GIFT voor-1(p)
Associatie: verband tussen 2 of meerdere klassen in UML
--> weergegeven door een lijn tussen de twee klassen (naam v/h verband naast de lijn schrijven)
5
Jeroen De Koninck – HIRB – 2012-2013
! Een verband die in twee richtingen werk, krijgen beide een naam
--> dit noemt men de rol v/d associatie
ZIE VOORBEELD PAGINA 14 BOVENAAN
3.4.2 Verplicht of Optioneel karakter van een verband
f : A -> B is verplicht als elk element van A verplicht een beeld heeft in B
In formulevorm: f: A -> B is verplicht ⇔ ∀ a ∈ A: f(a) ≠ ∅
f : A -> B is optioneel als niet elk element van A verplicht een beeld heeft in B
Je moet kijken naar de cardinaliteit van situaties
! Het karakter (verplicht of optioneel) wordt bepaald als de toestand op elk ogenblik in de tijd
--> voor het modellering v/h karakter door de tijd heen, gebruikt men temporele kwantoren
Zo is er de kwantor ooit: (optioneel)
Voorbeeld: elk persoon zal ooit een gift doen
Bij een klassieke niet-temporele interpretatie zou het verband “gaf” willen zeggen dat er een tijdstip t
is waarop een persoon geen gift doet
Bij de temporele interpretatie zegt men dat iemand ooit een gift zal doen
--> De kwantor ooit zegt zo:
voor elk persoon p moet er ooit een tijdstip t zijn waarop geldt dat gaf(p) ≠ ∅
Zo is er de kwantor altijd: (verplicht)
--> een verband is verplicht wanneer altijd geldt dat elk element wordt afgebaald op een niet-lege
verzameling in de beeldverzameling
Dit noemt men permanente interpretatie
UML gebruikt geen temporele kwantoren
--> men gaat er vanuit dat gemodelleerde eigenschappen ALTIJD geldig zijn (op elke t)
! UML kan geen ooit-kwantoren noteren
3.4.3 Cardinaliteit v/e verband
Cardinaliteit v/e verband f
--> geeft het maximum aantal elementen weer waarop een element uit het domein wordt afgebeeld
door f (dus het maximaal aantal beelden)
Een verband f : A -> B heeft een cardinaliteit van maximum 1 indien elke a ∈ A op maximum 1 b ∈ B
wordt afgebeeld (voor elke a uit A is er dus maximum 1 b uit B)
Symbolen: f: A -> B heeft een cardinaliteit van maximum 1 ⇔ ∀ a ∈ A: |f(a)| ≤ 1
Een verband f : A -> B heeft een cardinaliteit van many indien voor elke a ∈ A op meerdere
elementen uit B wordt afgebeeld (voor elke a uit A bestaan er dus meerdere b’s uit B)
Symbolen: f: A -> B heeft een cardinaliteit van many ⇔ ∀ a ∈ A: |f(a)| ∈ ℕ
6
Jeroen De Koninck – HIRB – 2012-2013
3.4.4 Optionaliteit en cardinaliteit in UML
Bij UML schrijft men de cardinaliteit en het karakter v/e associatie als een interval
! Dit interval staat aan de BEELDVERZAMELING ZIJDE
f: A -> B
f is optioneel
f is optioneel
f is verplicht of |f(a)| > 0
f is verplicht of |f(a)| > 0
cardinaliteit
f heeft cardinaliteit 1 of |f(a)| ≤ 1
f heeft cardinaliteit many
f heeft cardinaliteit 1 of |f(a)| ≤ 1
f heeft cardinaliteit many
Schrijf langs f, aan kant van b
[0..1]
[0..*] of gewoon *
[1..1] of [1] of 1
[1..*]
3.4.4.1 Terminologie
Cardinaliteit is vaak ook de verzamelnaam voor optionaliteit en cardinaliteit
Voorbeeld:
Departement kan mogelijk werknemers hebben en het kunnen er mogelijks meerdere zijn
-> de cardinaliteit is [0..*]
De rol is namelijk optioneel en de cardinaliteit is many
Iedere werknemers hoort exact tot 1 departement en dit voor alle werknemers
-> de cardinaliteit is [1..1]
De rol is namelijk verplicht en de cardinaliteit is 1
Men schrijft dis als:
WERKNEMER [0..*]
WERKT IN ->
[1] DEPARTEMENT
<- HEEFT
De waarden die kunnen gelden voor het departement staan bij de werknemer
De waarden die kunnen gelden voor de werknemer staan bij het departement
3.4.5 Navigeren over meerdere associaties
Als het beeld v/h ene verband, het domein vormt v/h andere verband
--> combinatie v/d verbanden
Voorbeeld:
f: A -> B en g: B -> C
Het beeld van f is het domein van g
Hierdoor kunnen we dit schrijven als:
g ○ f: A -> C: a -> g(f(a))
We gaan dus de y-waarde van f invoegen als de x-waarde bij g
Notatie: g(f(a)) = (g○f)(a)
We kunnen het karakter en cardinaliteit v/h samengesteld verband afleiden uit
--> de eigenschappen van deelverbanden
7
Jeroen De Koninck – HIRB – 2012-2013
UML zal samengestelde verbanden nooit opnemen in conceptuele modellen
--> deze verbanden zijn namelijk volledig redundant
Enkel in een implementatiemodel kan men dit eventueel doen
3.5 SPECIALE VORMEN VAN ASSOCIATIES
Men kan verbanden tussen verzamelingen modelleren als:
--> een afbeelding v/e verzameling naar een andere
Maar men kan een relatie ook zien als:
--> een productverzameling van twee (of meerdere) andere verzamelingen
Relatie R tussen klasse A en klasse B wordt zo:
R⊆AxB
De overeenkomstige afbeelding is dan:
r: A -> B: a -> f(a) waarbij b ∈ f(a) ⇔ (a,b) ∈ R
Het beeld b moet dus element zijn van de verzameling beelden
Zowel het object uit domein (a) als het object uit het beeld (b) moeten tot de relatie behoren
r is verplicht ⇔ a ∈ A: ∃ b ∈ B: (a,b) ∈ R
r is verplicht als en slechts als a een element is van A
En voor a bestaat er een beeld (b) uit B zodat (a,b) elementen zijn van de verzameling
r heeft cardinaliteit maximaal 1 ⇔ |{b ∈ B| (a,b) ∈ R}| ≤ 1
r heeft cardinaliteit maximaal 1 als en als als de absolute waarde van het beeld b uit B een relatie
(a,b) uit R heeft waarvan de maximale waarde kleiner of gelijk is aan 1
Er mag dus slechts één b zijn waarvoor (a,b) uit R één of geen relatie vormt
Door het product maken we ook duidelijk dat elk product van twee klassen slechts één paar
elementen heeft dat 1 keer voorkomt in de relatie
Elk element (a,b) in een productverzameling A x B is uniek geïndentificieerd d.m.v. a en b
! Men mag wel twee verbanden (met ≠ namen) leggen tussen twee dezelfde klassen A en B
3.5.1 N-aire associaties
Door het definiëren van v/e verband als productverzameling kan men
--> gemakkelijk verbanden definiëren waar meer dan twee verzamelingen aan deelnemen
8
Jeroen De Koninck – HIRB – 2012-2013
Stel we hebben volgende informatie:
LEVERT
LEVERANCIER
PRODUCT
Janssens
Tegels
Janssens
Bakstenen
Peeters
Beton
Maes
Beton
Maes
Dakpannen
Peeters
Dakpannen
LEVERT AAN
LEVERANCIER
PROJECT
Janssens
P1
Janssens
P2
Peeters
P2
Maes
P2
Maes
P3
GEBRUIKT VOOR
PROJECT
PRODUCT
P1
Tegels
P1
Bakstenen
P2
Tegels
P2
Bakstenen
P2
Beton
P3
Dakpannen
P2
Dakpannen
We willen weten:
Wie leverde beton voor project 2
Voor welk project waren de dakpannen van Maes
Deze verbanden laten deze analyse niet toe
--> er is een gebrek aan informatie
- PROJECT-LEVERANCIER geeft te weinig informatie: er zijn meerdere producten per combi
- PROJECT-PRODUCT geeft te weinig informatie: er zijn meerdere leveranciers per combi
- LEVERANCIER-PRODUCT geeft te weinig informatie: er zijn meerdere projecten per combi
Zo kan je geen antwoord geven op wie leverde beton voor project 2
Maes leverde namelijk Beton en Dakpannen en levert aan project 2 en 3
Peeters leverde beton en dakpannen en levert aan project 2
Zo kan de beton van project 2 afkomstig zijn van Peeters en Maes of van Peeters alleen, want het kan
ook zijn dat Maes enkel dakpannen leverde aan project 2 en beton aan project 3
Hetzelfde probleem kennen we bij de vraag voor welk project waren de bakpannen van Maes
Maes levert beton en dakpannen die terecht komen bij project 2 en/of project 3
Het kan zijn dat de dakpannen terecht komen bij project 2 of bij project 2 of bij project 2 en 3
! Binaire verbanden laten geen correcte waargave v/h probleemdomein weer
Er is ook een probleem van consistentie: het zou idealiter zijn wanneer de leveranciers v/e project
overeenkomen met de leveranciers van de producten die gebruikt worden in het project
Daarom is het beter in dit geval te werken met een drie-wegs-verband tussen PROJECT,
LEVERANCIER en PRODUCT
We gebruiken een UML-model:
PROJECT
gebruikt -> [0..*]
[0...*] <- gebruikt door
PRODUCT
levert aan -> [0..*]
LEVERANCIER
9
Jeroen De Koninck – HIRB – 2012-2013
Via UML zijn er meer dan twee association ends voor 1 associatie mogelijk
Any association may be drawn as a diamond (larget than a terminator on a line) with a solid line for
earch association memberEND connecting the diamond to the Classifier that is the end’s type. An
association with more than two ends can only be drawn this way
Via dezelfde terminologie kan men cardinaliteiten als volgt interpreteren:
For an association with N memberEnd, choose any N-1 ends and associate specific instances with
those ends. Then the collection of links of the association that refer to these specific instance will
identify a collection of instances at the other end. The multiplicity of the other end constraint the size
of this collection. IF the other end is marked as isOrdered, this collecition will be ordered. If the other
end is marked is marked as isUnique, this collection is a set, otherwise, it allows duplicate elements
Men kan dit gaan vertalen naar de wiskunde:
Gegeven een verband R ⊆ (A1 x A2 x ... An)
Voor elke Ai definiëren we een verband ri als volgt:
ri: A1 x ... x Ai-1 x Ai+1 x ... x An -> Ai : (a1, ..., ai-1, ai+1, ... an) -> ai
Een verband ri wordt gevormd door de klasse af te beelden op een andere klasse
--> men gaat het object van de klasse afbeelden op een object v/d andere klasse
ri verplicht ⇔ ∀ (a1, ..., ai-1, ai+1, ... an) ∈ (A1 x ... x Ai-1 x Ai+1 x ... x An) ∃ ai ∈ Ai: (a1, ..., ai-1, ai+1, ... an) ∈ R
Het verband is verplicht als er voor elk object uit een klasse een element bestaat ui een andere klasse
zodat dit object uit de andere klasse behoort tot de relatie
ri cardinaliteit max. 1 ⇔ |{(a1, ..., ai-1, ai+1, ... an) ∈ (A1 x ... x Ai-1 x Ai+1 x ... x An) | (a1, ..., ai-1, ai+1, ... an)
∈R≤1
Er is ook een andere benadering mogelijk
--> men gaat vertrekking van een object uit een klasse
Er men ziet hoeveel tupels (eindige sequentie objecten) er met dat ene object overeen komen
Men kan dit gaan vertalen naar de wiskunde:
Gegeven een verband R ⊆ (A1 x A2 x ... An)
Voor elke Ai definiëren we een verband ri als volgt:
ri: A1 x ... x Ai-1 x Ai+1 x ... x An : ai -> (a1, ..., ai-1, ai+1, ... an)
ri verplicht ⇔ ∀ ai ∈ Ai : ∃ (a1, ..., ai-1, ai+1, ... an) ∈ (A1 x ... x Ai-1 x Ai+1 x ... x An):(a1, ..., ai-1, ai+1, ... an) ∈ R
ri cardinaliteit max. 1 ⇔ |{(a1, ..., ai-1, ai+1, ... an) ∈ (A1 x ... x Ai-1 x Ai+1 x ... x An) | (a1, ..., ai-1, ai+1, ... an)
∈R≤1
! We gebruiken voor concepten steeds de UML-interpretatie
--> vertrekken vanuit alle behalve 1 klasse en kijken hoeveel objecten we vinden
10
Jeroen De Koninck – HIRB – 2012-2013
Zo krijgen we voor het voorbeeld:
gebruikt: PROJECT x LEVERANCIER -> PRODUCT
Dit voorbeeld modelleert:
--> hoeveel producten er met een bepaald (project, leverancier) combinatie overeenkomen
Het verband is verplicht indien er voor elk (project, leverancier) combinatie er minstens één product
gebruikt is
Het verband heeft een cardinaliteit many indien er in een (project, leverancier) combinatie mogelijks
meerdere producten producten die voor die combinatie gebruikt zijn
3.5.2 Associatie van een klasse
Soms gaat men het verband tussen twee klassen modelleren als een klasse
We nemen een voorbeeld van hotelreservaties:
Het is een many-to-many verband tussen een kamer en een persoon
We hebben een verband in twee richtingen: reserveren en gereserveerd door
- Een persoon kan nul, één of meerdere kamers reserveren
- Een kamer kan gereserveerd zijn door nul, één of meerdere personen
KAMER
PERSOON
<- Reserveert
[0...*]
Gereserveerd door
[0..*]
In de kamer reserveert ⊆ PERSOON x KAMER komt elke combinatie (p, k) met p ∈ person en k ∈
kamer, slechts 1 maal voor
Is bovenstaande stelling: elke reservatie wordt uniek geïdentificeerd door de persoon en de kamer
--> is dit correct?
Neen, in sommige gevallen geeft de identiteit v/d deelnemende objecten geen unieke identificatie
v/d relatie. Zo kan dezelfde persoon dezelfde kamer op meerdere tijdstippen boeken
De reservatie wordt dan niet uniek geïdentificieerd door de persoon en de kamer
--> wel door een bijkomend element zoals de startdatum en de einddatum v/d reservatie
Men noemt dit een associatie en gaat deze zelf modelleren als een klasse aan het verband
Soms kan men wel uniek identificeren, maar zijn associaties toch handig als bijkomende informatie
--> deze geeft men ook weer in een klasse
KAMER
PERSOON
RESERVATIE
datum_van
datum_tot
Klassen moeten steeds een betekenisvolle naam krijgen
11
Jeroen De Koninck – HIRB – 2012-2013
Sommige associaties gaat men quasi als standaard modelleren in de vorm van een klasse:
- Many-to-many verbanden: men gaat bij deze relationele database het mode normaliseren
--> Many-To-Many verbanden gaat men bijgevolg omzetten naar een klasse
! Voor oorspronkelijk deelnemende klasse geldt als unieke identificatie v/h element in de
associateklasse
! Steeds nagaan of men bijkomende attributen moet opnemen
(kunnen noodzakelijk zijn voor de identificatie v/d elementen in de associatieklasse
Voorbeeld: de reservatieklasse
- N-aire verbanden (met N > 2), dit is ook standaard door de praktijk van databaseontwerp
--> relationeel model heeft enkel binaire verbanden
(men zet daarom n-aire verbanden om naar een klasse)
Voorbeeld: een gebruikt product behoort tot een project, een product en komt v/e leverancier [1]
ZIE SCHETST PAGINA 24 BOVENAAN
Men introduceert een vorm van complexiteit
Wanneer we een associatie opnemen als een klasse, zal en deze opnemen als volwaardige klasse
KAMER
[1]
[1]
[0..*]
RESERVATIE
PERSOON
[0..*]
3.5.3 Aggregatie en compositie
Aggregatie en compositie zijn soorten associaties
Men heeft verschillende soorten aggregaties:
- GEEN: er zijn geen betekenisvolle aggregaties
- GEDEELD: er zijn gedeelde betekenisvolle aggregaties
- COMPOSITIE: er zijn betekenisvolle aggregaties met een verantwoordelijke functie voor het
bestaan en de opslag van in verband gelegde objecten
Wanneer de compositie wordt verwijderd, zullen alle samengestelde objecten verdwijnen
Een samengesteld object verwijderen resulteert niet in een verwijderde compositie
! De interpretatie kan van gebruiker tot gebruik verschillen
! Een model met aggregatie heeft geen eenduidige betekenis
--> daarom wordt dit ook afgeraden
Ook een compositie is niet aangeraden
Men kan deze enkel gebruiken bij goede afspraken over:
- de betekenis aan de gedragszijde
- de implicaties aan de gedragszijde
Zo moet men afspreken wat er gebeurd met de onderdelen indien men het geheel verwijderd
12
Jeroen De Koninck – HIRB – 2012-2013
3.6 HERGEBRUIK EN OVEREVERING
3.6.1 Definitie
Men kan specificaties hergebruiken
--> de manier hiervoor komt uit de manier waarop men code herbruikt bijobjectgerichte
programmeertalen
! Soms zijn er een aantal klassen met sterke gelijkenissen
Deze gelijkenissen kunnen we capteren via een overkoepelende algemene klasse te definiëren
--> deze omschrijft de gemeenschappelijke eigenschappen
De oorspronkelijke (meer gespecialiseerde) klassen erven de eigenschappen v/d algemene klassen
--> ze verfijnen de definitie v/d algemene klasse door bijkomende eigenschappen te definiëren
We gebruiken deze manier van werken o.a. bij programmeren
--> hiermee vermijden we het herschrijven van dezelfde code
De algemene klasse bevat de gemeenschappelijke code
De gespecialiseerde klasse voegt aan deze geërfde code de nodige eigen code toe
Deze notie van generalisatie-specialisatie is nauw verwant met het concept van taxonomie
Taxonomie: wordt ondermeer gebruikt om dieren te categoriseren
Voorbeeld:
Op het hoogste niveau onderscheidt men gewervelde en ongewervelde dieren
Een niveau lager deelt men in categorieën (zoogdieren, vogels, vissen, ...)
Deze categorieën verfijnt men tot erg nauwkeurige subcategorieën
Wiskundig: men heeft een verzameling die men steeds meer opdeelt in deelverzamelingen
Men gebruikt deze strategie ook bij software ontwikkeling:
ZIE SCHETS PAGINA 27
Bij software is niet elke klasse zomaar een subklasse
--> men probeert nl. het probleemdomein weer te geven en het het oplossingsdomein te laten
beschrijven
Het model moet men kunnen omzetten naar code
Hierdoor moet het model de principes van overerving op het niveau v/d code respecteren
Bij de definiëring v/e variabele bij programmeer-code
--> de variabele dient als placeholder voor elementen v/d verzameling
(dit voor elementen die overeenkomen met het type v/d variabele)
Voorbeeld in de declaratie:
d: DIER (eiffel)
DIER d (java)
DIER verwijst naar de klasse (verzameling dieren)
d kan gelijk welk element van de klasse bijhouden
! Een variabele kan vaak niet zomaar twee types tegelijk bezitten (er zijn dan twee variabelen)
13
Jeroen De Koninck – HIRB – 2012-2013
Vaak kan het ook niet zomaar dat een variabele van type kan veranderen
Voorbeeld:
We hebben een verzameling dieren met deelverzamelingen ZOOGDIER, VOGEL en VIS
Volgens deze structuur kan een dier nooit tegelijk ZOOGDIER en VIS zijn
Volgens deze structuur kan een dier nooit van deelverzameling veranderen
Een vogel wordt geen vis na verloop van tijd
Bij klassendiagramma’s gebruiken we generalisatie-specialisatie dus best als:
- We geen overlappende subklassen hebben
- Elementen voor de duur van hun leven tot dezelfde subklasse behoren
! Bij overlappende subklassen, moet men de opdeling herbekijken
! Elementen die van klasse veranderen, kan men beter modelleren volgens rollen
Zo kan men gedragsaspecten beter modelleren a.d.v.:
- operaties
- toestanden
- toestandsovergangen
Volgende redenen zijn geen goede redenen om subklassen te definiëren:
- Deelnemen aan een verband met een andere klasse
Voorbeeld: personen indelen volgens hun al dan niet bezit v/e wagens
- Opdelen v/e klasse in functie v/d waarde v/e bepaald attribuut
Voorbeeld: dure auto’s versus goedkope auto’s
- Opdelen v/e klasse in functie v/d toestand v/h object
Voorbeeld: betrouwbare en onbetrouwbare betalers
De reden is dat deze elementen van subklasse zullen veranderen
Principe van inheritance (overerving) wordt afgeraden
3.6.2 Overerving van verbanden
Generalisatie-specialisatieverband tussen twee klassen: de gespecialiseerde klasse erg alle
eigenschappen v/d generalisatie-klasse
Men erft dus v/d generalisaties alle:
- attributen
- associaties
3.7 OCL CONSTRAINTS
3.7.1 Algemeen concept
In UML gebruiken we verschillende technieken voor het specificeren v/e probleemdomein
In de cursus specificeren we het probleemdomein via:
- Klassendiagamma
- FSM’s
- Object Event Tabel
--> samen vormen ze de (volledige) specificatie v/h probleemdomein
14
Jeroen De Koninck – HIRB – 2012-2013
Alle schema’s leggen een aantal beperkingen rond de geldigheid v/d informatie op
Voorbeeld:
Indien we in een klassediagramma een verband verplicht maken (bijvoorbeeld elke gift is door een
persoon), dan kan het informatiesysteem geen informatie registreren als men niet voldoet aan deze
voorwaarde wordt voldaan
(zo kan men de gift niet registreren zonder de persoon die hem deed te registreren)
Via constaints of beperkingen kan men de correctheid v/d geregistreerde informatie bewaken
Elk UML-schema laat enkele constraints toe om te registreren
Voorbeeld:
- In een klassendiagramma bepalen we de verbanden v/d klassen
--> we kunnen beperkingen opleggen a.d.v. cardinaliteit
- In FSMs kunnen we beperkingen opleggen aan de volgorde waarin events en de bijhorende
actie mogen optreden
3.7.2 Tips bij het formuleren van constaints
Via OCL bouw je booleaanse uitdrukkingen, ze kunnen dus een TRUE/FALSE waarde aannemen
Men verwijst naar klassen en attributen (eventueel ook operaties) uit een klassenschema
Men kan het tijdstip bepalend waarop je een booleaanse uitdrukking wil evalueren
--> hier wordt bepaalt of het over een preconditie of een invariantie gaat
Invariantie: is gekoppeld aan een klasse en moet op elk ogenblik waar zijn
--> controle bij manipulatie aan de klasse
Preconditie: is gekoppeld aan een operatie en wordt gecontroleerd voor het uitvoeren v/d operatie
--> is het resultaat TRUE: de operatie wordt uitgevoerd
--> is het resultaat FALSE: de operatie wordt geweigerd
ZIE VOORBEELD PAGINA 31
Voorbeeld invariantie: een maximum aantal deelnemers
--> Hiervoor moet men bijvoorbeeld 5 tot 30 deelnemers hebben
Dit moet altijd waar zijn, de context is dus:
Context Stadsspel
self.maxAantalPersonen >= 5 and sel.maxAantalPersonen <=30
Stel dat er een optie uitschrijven is, zodat spelers zich kunnen uitschrijven voor de uiterste datum
Een preconditie zorgt ervoor dat men zich niet meer kan uitschrijven na datum
De controle gebeurt nl. op het moment v/d uitschrijving
De context is een klasse en een operatie
Men gaat deze klasse en operatie neerschrijven als:
Context Deelname
uitschrijven requires
today <= self.stadspel.uitersteDatumUitschrijving
15
Jeroen De Koninck – HIRB – 2012-2013
Voor het zelf schrijven van OCL constraints zijn er enkele tips:
- Men moet steeds een context geven (zonder context heeft self geen betekenis)
- De context moet een klassenaam zijn die in het klasseschema voorkomt
- Bij een preconditie moet men de naam v/d operatie opgeven waarop deze van toepassing
is
- De uitdrukking moet een booleeanse waarde geven als resultaat
- Men moet rekening houden met de cardinaliteiten waarlangs men navigeert
--> cardinaliteit many geeft een verzameling terug
--> cardinaliteit van 1 geeft een singleton
! Men moet letten op de bewerkingen die men toepast: niet elke bewerking kan men
uitvoeren (zo kan een vergelijking enkel op een singleton)
(hoeveelheid spelleiders v/e deelnemer)
- De OCL-expressie “uitdr1 includes uitdr2” vraagt dat uitdr1 een verzameling teruggeeft en
uitdr2 een element of een verzameling, in beide gevallen van hetzelfde type als de
verzameling gegeven door uitdr1
- Zoek naar een goed startpunt voor de navigatie (zie voorbeeld pagina 32)
- Lees goed de opgave “er moet een spelleider” is niet hetzelfde als “alle spelleiders moeten”
16
Jeroen De Koninck – HIRB – 2012-2013