Bestaansafhankelijkheid: Conceptueel modelleren volgens contract

Bestaansafhankelijkheid: Conceptueel modelleren “volgens contract”. Dr. M. Snoeck Prof. dr. G. Dedene Katholieke Universiteit Leuven Dept. Toegepaste Economische Wetenschappen Naamsestraat 69, 3000 Leuven Email: {Monique.Snoeck, Guido.Dedene}@econ.kuleuven.ac.be http://www.econ.kuleuven.ac.be/tew/academic/infosys/research/merode.htm

Abstract In object oriëntatie zijn de inheritance- of "IS-A"- hiërarchie en de Aggregatie- of "Part-Of"- hiërarchie de belangrijkste classificatieprincipes voor objecttypes. In dit artikel wordt een nieuw classificatieprincipe voorgesteld dat "bestaansafhankelijkheid" heet. Bestaansafhankelijkheid omvat een deel van de semantiek die gewoonlijk geassocieerd wordt met het concept van aggregatie. In feite bestaat het concept van bestaansafhankelijkheid reeds lang, maar de semantiek ervan is verborgen in het Enititeit-Relatie model en werd nooit expliciet vermeld. We zullen aantonen hoe het expliciet classificeren van objecttypes volgens het principe van bestaansafhankelijkheid heel wat mogelijkheden biedt voor het controleren van de specificatie van statische en dynamische aspecten van objecten op interne consistentie op een formele manier. Bovendien gaat deze consistentiecontrole veel verder dan een pure syntactische controle.

1. INLEIDING Een van de belangrijkste taken bij conceptueel modelleren is de identificatie van componenten in het relevante domein. Typische componenten zijn objecttypes, attribuuttypes, methoden en relaties tussen objecttypes. Deze relaties organiseren objecttypes tot schema’s. De meeste ontwikkelaars zullen het ermee eens zijn dat de principes van generalisatie/specialisatie (IS-A) en aggregatie (PartOf) de belangrijkste classificatieprincipes zijn. Bijna elke objectgerichte methode heeft een aparte notatie voor het aangeven van deze speciale relaties [2, 5, 7, 12, 16, 19, 20]. Vooral de generalisatie/ specialisatie wordt als cruciaal beschouwd, omdat het toelaat de complexiteit van schema’s te reduceren. Er zijn natuurlijk veel meer soorten relatietypes tussen objecttypes en deze worden meestal samengevat onder de algemene term "relatietypes". In dit artikel stellen we u een nieuw classificatieprincipe voor dat belangrijk genoeg is om er speciaal aandacht aan te besteden en dat we "bestaansafhankelijkheid" noemen. We zullen aantonen hoe het concept van bestaansafhankelijkheid altijd aanwezig is in elk gegevensmodel dat minstens twee objecttypes bevat. In dit opzicht is bestaansafhankelijkheid misschien nog meer fundamenteel dan generalisatie/specialisatie en aggregatie.

1

De belangrijkste reden om deze relatie apart te modelleren is de mogelijkheden die zo geboden worden voor een verregaande kwaliteitscontrole van specificaties. In objectgericht modelleren besteed men evenveel aandacht aan de statische en aan de dynamische aspecten van objecttypes. Om schema’s overzichtelijk te houden, worden meestal verschillende technieken gebruikt voor het modelleren van deze aspecten, wat resulteert in een subschema per gebruikte techniek. Al deze subschema’s samen vormen dan het eigenlijke conceptueel schema. Veel objectgerichte analyse methoden gebruiken bijvoorbeeld een variante van het ER-model voor het modelleren van statische aspecten terwijl Finite State Machines (FSMs) and Event Trace Diagrams worden gebruikt voor het modelleren van gedrag en communicatie. Deze technieken hebben voor sommige aspecten wel overlappende semantiek. En omdat dezelfde objecttypes gemodelleerd worden door middel van deze technieken, betekent dit dat dezelfde aspecten kunnen gemodelleerd worden in meer dan één schema. In het statisch schema kan men bijvoorbeeld specificeren dat het ene objecttype een specialisatie is van een ander objecttype (het generalisatietype). Deze relatie tussen objecten heeft echter gevolgen wat betreft het modelleren van gedrag door middel van FSMs1. We moeten ons dan bijvoorbeeld de volgende vragen stellen: − Erft de specialisatie de FSM van de generalisatie ? − Kan het specialisatietype deze FSM verder verfijnen door het toevoegen, weglaten of splitsen van toestanden ? De meeste objectgerichte analysemethoden beantwoorden dit soort vragen niet op een precieze of formele manier. In OOSA [21] bijvoorbeeld, is de FSM van een specialisatie (of subtype) een deel van de FSM van de generalisatie. Dit is in tegenstrijd met het begrip van inheritance dat bepaalt dat een subtype alles erft van het supertype. Het is zonder meer duidelijk dat er enige vorm van consistentiecontrole tussen de verschillende subschema’s nodig is om de kwaliteit van specificaties te waarborgen. Deze consistentiecontrole kan gaan van een eenvoudige syntactische controle op consistente naamgeving tot een doorgedreven controle op semantische overeenstemming tussen subschema’s. In [ 22] werd aangetoond hoe overeenstemming tussen de "IS-A" hiërarchie en gedragsmodellering kan geverifieerd worden. In dit artikel tonen we aan hoe door bestaansafhankelijkheid als vertrekpunt te nemen, we gebieden van overlappende semantiek kunnen identificeren en hoe we kunnen komen tot een aantal voorwaarden die de consistentie tussen het statische en dynamische schema kunnen waarborgen. De volgende paragraaf definieert het begrip bestaansafhankelijkheid en motiveert de bewering dat dit concept aanwezig is in elke datamodel. Vervolgens definiëren we een conceptueel model waarin bestaansafhankelijkheid centraal staat en tonen we aan hoe dit als vertrekpunt voor consistentiecontrole kan dienen. De vierde paragraaf presenteert een uitgebreide case-study en tenslotte wordt bestaansafhankelijkheid vergeleken met generalisatie/specialisatie en het concept van aggregatie.

1. Finite State Machines (FSMs) modelleren gedrag door het specificeren van toestanden en mogelijke overgangen tussen toestanden. 2

2. DE ALOMTEGENWOORDIGHEID VAN BESTAANSAFHANKELIJKHEID 2.1.

Bestaansafhankelijkheid: definitie

Het begrip bestaansafhankelijkheid is gebaseerd op de notie van het "leven" van een object. Het leven van een object is de tijd die verloopt tussen het ogenblik van de creatie van het object en het ogenblik van de vernietiging ervan. Bestaansafhankelijkheid wordt gedefinieerd op twee niveaus: op het niveau van de objecttypes en op het niveau van de objecten zelf. Bestaansafhankelijkheid is een partiële orde op objecten en objecttypes die we als volgt definiëren: Definitie 1. Zij P en Q objecttypes. P is bestaansafhankelijk van Q (notatie P ← Q) als en alleen als het leven van elk object p van type P ingebed is in het leven van één en altijd hetzelfde object q van type Q. p noemt men het buidelobject (marsupial) en q het moederobject. P is het buideltype en Q het moederobjecttype. Een meer informele manier om bestaansafhankelijkheid te definiëren is als volgt: als elk object van klasse P steeds verwijst naar minimum 1, maximum 1 en altijd hetzelfde object van klasse Q, dan is P bestaansafhankelijk van Q. Het resultaat is dat het leven van een buidelobject nooit kan beginnen voor het leven van de moeder. Analoog eindigt het leven van een buidelobject altijd voor of ten laatste wanneer het leven van de moeder eindigt. Dit wordt geïllustreerd in Fig. 1. TIJD Leven van het moederobject

Mogelijkheden voor het leven van een buidelobject

Fig. 1. Leven van moeder- en buidelobject Voorbeeld 1 Het leven van een uitlening van een boek is altijd ingebed in het leven van dat boek. Het objecttype UITLENING is dus bestaansafhankelijk van het objecttype BOEK.

3

2.2.

Het Entiteit-Relatie Model en bestaansafhankelijkheid

Bestaansafhankelijkheid speelt een sleutelrol in het Entiteit Relatie Model. P.P. Chen gebruikt dit begrip wanneer hij de definitie geeft van "weak entity type" en "ID-dependency" ([3], p. 24): Weak entity type. The existence of a weak entity depends on the existence of other entities. The ‘E’ in the relationship box indicates that it is an “existence dependent” relationship. ID dependency. In case of ID dependency, entities are identified by their relationships with other entities. Het zwakke entiteittype is dus bestaansafhankelijk van de andere entiteittypes die deelnemen aan de zwakke relatie. ID dependency impliceert bestaansafhankelijkheid, maar het omgekeerde is niet noodzakelijk waar. Fig. 2. geeft een voorbeeld van een zwak entiteittype en een ID-dependent entiteittype. Beide soorten relaties worden weergegeven door middel van een ruit met een dubbele lijn aan de kant van het zwakke entiteittype. Gewone bestaansafhankelijkheid wordt aangeduid met de letter ‘E’ in de ruit terwijl ID dependency wordt aangegeven door middel van de letters ‘ID’ in de ruit. Voorbeeld 2 Kamer

E

Orderlijn

ID

Gebouw

Order

Fig. 2. Zwak entiteittype and ID dependent entiteittype. is een zwak entiteittype, bestaansafhankelijk van GEBOUW. Inderdaad, een kamer maakt steeds deel uit van exact één en altijd hetzelfde gebouw. ORDERLIJN is ID-dependent van ORDER omdat een orderlijn wordt geïdentificeerd aan de hand van het order waarvan het deel uitmaakt. In beide gevallen is de relatie die de twee objecttypes verbindt een zwak relatietype2. KAMER

Noteer dat het verschil tussen zwak en ID-dependent een kwestie is van attributen en sleutels. Indien men de identificatie van het gebouw opneemt als deel van de identificatie van de kamer, dan wordt KAMER ID-dependent van GEBOUW. Omgekeerd, indien de identificatie van het order geen deel uitmaakt van de identificatie van de orderlijn, dan is ORDERLIJN gewoon zwak t.o.v. ORDER, en niet 2. In [10] wordt een onderscheid gemaakt tussen zwakke relatietypes en zwakke entiteittypes, maar de semantiek van deze begrippen is op een zeer onduidelijke manier gedefinieerd. In een latere publicatie [11] worden meer precieze definities gegeven en hierin wordt bepaald dat een zwak relatietype een zwak entiteittype verbindt met een sterk entiteittype. 4

meer ID-dependent. In een dataschema zonder attributen en sleutels vervalt dus het onderscheid tussen zwak en ID-dependent. De semantiek van het Entiteit Relatie Model werd herhaaldelijk gedefinieerd door het specificeren van insert-, delete- en update-regels [4, 10, 11]. De eerste definities [4, 10] waren onduidelijk in die zin dat er geen duidelijk onderscheid werd gemaakt tussen verplichte (of totale) relaties en zwakke relaties. De verwarring ontstaat door het feit dat een verplichte relatie een zekere vorm van bestaansafhankelijkheid impliceert. Stel dat PROJECT en WERKNEMER verbonden zijn door een relatietype dat verplicht is aan de kant van WERKNEMER, dan kan een werknemer enkel toegevoegd worden indien men tegelijk een relatie toevoegt die deze werknemer koppelt aan een project. Andersom, indien men een project schrapt, dan moeten alle werknemers die enkel met dat project gerelateerd zijn, ook geschrapt worden. In die zin is WERKNEMER bestaansafhankelijk van PROJECT. Zoals opgemerkt wordt in [11, 18] ligt het verschil tussen zwakke en totale relaties in de regels die gelden voor het bijwerken van gegevens. In het volgende voorbeeld (Fig. 3) is in geval (a) een orderlijn altijd verbonden met exact één en altijd hetzelfde order. In geval (b) is het relatietype wel verplicht, maar niet zwak. Dit wil zeggen dat een orderlijn wel altijd naar exact één order moet verwijzen, maar dat in de loop van de tijd, dit wel een ander order kan worden. Indien nodig, kan men dus de orderlijn toewijzen aan een ander order. (a)

ORDER

1

groepeert

M

ORDERLIJN

(b)

ORDER

1

groepeert

M

ORDERLIJN

Fig. 3. Orders and Orderlines Indien men deze schema’s implementeert door in ORDERLIJN een referentie naar ORDER op te nemen, dan mag in geval (a) deze referentie niet worden gewijzigd terwijl dit in geval (b) wel toegelaten is. Alhoewel het nooit zo wordt gezegd, is het concept van bestaansafhankelijkheid ook aanwezig in het concept van een relatietype. Relatietypes kunnen als objecttypes beschouwd worden en in de definitie van P.P. Chen worden relatietypes geïdentificeerd door de identificaties van de deelnemende entiteittypes samen te voegen [3]. Indien men relatietypes dus als objecttypes beschouwt, dan zijn ze per definitie ID dependent (en dus bestaansafhankelijk) van de deelnemende entiteittypes. Meer algemeen kan men stellen dat het concept van relatie en de regels voor insert, delete en update [4, 10, 11], de volgende drie veronderstellingen impliceren:

5

Veronderstelling 1: De relatie kan niet gecreëerd worden indien de deelnemende entiteiten nog niet bestaan. De creatie van een relatie valt dus altijd na (of tegelijkertijd met) de creatie van de deelnemende entiteiten. Veronderstelling 2: De relatie kan niet langer bestaan dan de deelnemende entiteiten. De relatie wordt ten laatste geschrapt wanneer een van de deelnemende entiteiten geschrapt wordt. Veronderstelling 3: Een relatie verbindt altijd dezelfde entiteiten. Dit betekent dat indien een relatie tussen entiteiten verlegd wordt, we een nieuw relatieobject hebben3. Deze veronderstellingen betekenen niet meer of minder dan dat wanneer relatietypes worden beschouwd als objecttypes, zij bestaansafhankelijk zijn van de deelnemende entiteittypes. We illustreren dit aan de hand van een voorbeeld over een bibliotheek. Voorbeeld 3 In een bibliotheek kunnen boeken uitgeleend worden door leden. Fig. 4 toont een mogelijk ERschema voor een bibliotheek. Volgens veronderstellingen 1 en 2 kan een uitlening slechts gecreëerd worden indien het uitgeleende boek al bestaat en indien het uitlenend lid al bestaat. De uitlening kan ook niet langer bestaan dan het uitgeleende boek en het uitlenend lid. Volgens veronderstelling 3 is het bovendien zo dat een uitlening altijd naar hetzelfde boek en naar hetzelfde lid verwijst. Een ander boek of een ander lid impliceren in ieder geval een andere uitlening. Een uitlening verwijst dus steeds naar exact één en altijd hetzelfde boek en naar exact één en altijd hetzelfde lid. Daarom is uitlening bestaansafhankelijk van boek en lid.

U IT L E N IN G BOEK

L ID

Fig. 4. Een klein bibliotheek-schema

3. BESTAANSAFHANKELIJKHEID: DE SLEUTEL TOT KWALITEITSCONTROLES VOOR CONCEPTUELE SCHEMAS

In deze paragraaf geven we een definitie van een objectgericht conceptueel model met expliciete aandacht voor bestaansafhankelijkheid. Het conceptueel schema bestaat uit vier subschema’s: een ER-schema, een bestaansafhankelijkheidsschema, een gedragsschema en een object-gebeurtenis tabel. Kwaliteits- en consistentiecontrole gebeurt door na te gaan of elk schema in overeenstemming is met het bestaansafhankelijkheidsschema. Daar bovenop moet er nog een controle gebeuren tussen de object-gebeurtenis tabel en het gedragsschema. In wat volgt definiëren we achtereenvolgens het 3. Dit is een gevolg van het feit dat relaties gezien worden als tuples en geïdentificeerd worden door middel van de identificaties van de deelnemende entiteiten. Met andere woorden: de sleutel van de relatie is de samenvoeging van de sleutels van de deelnemende entiteiten. 6

bestaansafhankelijkheidsschema, het ER-schema, de object-gebeurtenis tabel en het gedragsschema. Voor elk van de laatste drie schema’s wordt eveneens uiteengezet hoe de controle op overeen stemming met het bestaansafhankelijkheidsschema moet gebeuren. Fig. 5 geeft een overzicht van de verschillende stappen in de kwaliteitscontrole.

Bestaansafhankelijkheidsschema

ER schema

Object Gebeurtenis Tabel

Gedragsschema

Fig. 5. Consistentiecontrole tussen de vier subschema’s

3.1.

Het bestaansafhankelijkheidsschema

Basisdefinitie Bestaansafhankelijkheid is een partiële orde op objecttypes zoals gedefinieerd in Definitie 1. Met partieel wordt bedoeld dat niet elk paar objecttypes geordend is: tussen sommige objecttypes bestaat geen verband m.b.t. bestaansafhankelijkheid. Grafische weergave. De naam van het moederobjecttype wordt geplaatst boven de naam van het buidelobjecttype en de twee worden verbonden met een lijn. Voorbeeld 4 wordt grafisch weergegeven in Fig. 6. Voorbeeld 4 In een bibliotheek-omgeving wordt het concept BOEK gebruikt om te verwijzen naar het abstract begrip van een boek terwijl COPIE verwijst naar het fysieke exemplaar. Leden kunnen copieën uitlenen. Een mogelijk conceptueel schema voor dit domein bevat vier objecttypes: BOEK, COPIE, LID, UITLENING. En de bestaansafhankelijkheidsrelaties liggen als volgt: COPIE ← BOEK UITLENING ← COPIE UITLENING ← LID

7

BOEK

LID COPIE

UITLENING

Fig. 6. Bestaansafhankelijkheidsschema voor de bibliotheek Syntactische correctheid. Een syntactisch correct bestaansafhankelijkheidsschema voldoet aan de volgende beperkingen: 1) Het moet volledig geconnecteerd zijn. Dit wil zeggen dat het schema niet kan opgesplitst worden in twee afzonderlijke schema’s zonder gemeenschappelijke objecttypes. 2) Een objecttype is nooit bestaansafhankelijk van zichzelf. 3) Het schema is a-cyclisch. Met andere woorden: indien men de bestaansafhankelijkheidsrelatie volgt van moederobjecttype naar buideltype, dan mogen er geen lussen voorkomen.

Noteer dat het best mogelijk is dat een bepaald objecttype bestaansafhankelijk is van eenzelfde moederobjecttype op twee verschillende wijzen. Zo hangt het bestaan van een huwelijk4 zowel af van het bestaan van een man als van het bestaan van een vrouw. Er zullen dus twee lijnen zijn tussen huwelijk en persoon (zie Fig. 7).

PERSOON

HUWELIJK

Fig. 7. Dubbele bestaansafhankelijkheid Cardinaliteit van Bestaansafhankelijkheid In het bestaansafhankelijkheidsschema definieert ook de cardinaliteit van de bestaansafhankelijkheidsrelatie. Deze cardinaliteit zegt hoeveel buidelobjecten een moederobject kan hebben op één ogenblik in de tijd.

4. Veel ontwerpers zullen argumenteren dat een huwelijk een relatietype is eerder dan een objecttype. Maar zoals verder uit de tekst zal blijken, worden relatietypes hier altijd beschouwd als objecttypes, tenzij ze zwak zijn. 8

Notatie. P(1) ← Q indien elk voorkomen q van Q hooguit één bestaansafhankelijk voorkomen p van P kan hebben op één ogenblik in de tijd5. P(n) ← Q indien elk voorkomen q van Q meerdere bestaansafhankelijke voorkomens van P kan hebben op één ogenblik in de tijd. Grafische weergave. De cardinaliteiten worden naast de lijn geschreven die het buidelobjecttype verbindt met het moederobjecttype. Voorbeeld 5 In het bibliotheekvoorbeeld kunnen er van een boek meerdere copies bestaan op één ogenblik in de tijd en dus is er hier een cardinaliteit N. Een copie kan slechts één maal uitgeleend zijn op één ogenblik in de tijd, maar een lid kan daarentegen meerdere boeken tegelijk uitlenen. Zodus hebben we hier respectievelijk een cardinaliteit van 1 en van N. Fig. 8 geeft het bestaansafhankelijkheidsschema met cardinaliteiten. Dus: COPIE (n)← BOEK, UITLENING (1)← COPIE en UITLENING (n)← LID

BOEK M

LID

COPIE M

1 UITLENING

Fig. 8. Bestaansafhankelijkheidsschema met cardinaliteiten

3.2.

Het ER-model

Basisdefinitie Entity-Relationship modelling is een techniek die oorspronkelijk werd ontwikkeld door P.P. Chen [3, 4]. Hoewel het gebaseerd is op het relationeel model van Codd [6], kan de ER-techniek niet als een formele techniek beschouwd worden. Zoals Webre [24] terecht opmerkt, is het ER-model, ondanks de vele publicaties, nog altijd onnauwkeurig gedefinieerd. En dus is een nauwkeurige definitie van het ER-model hier aangewezen. In deze paragraaf definiëren we wat we verstaan onder een syntactisch correct Entiteit-Relatie schema. In het tweede deel van deze paragraaf worden de elementen uit het ER-model gerelateerd met de componenten van het bestaansafhankelijkheidsschema. Dit geeft meteen ook een partiële definitie van de semantiek van het Entiteit-Relatie model. 5. Noteer dat de bepaling "op één ogenblik in de tijd" essentieel is in de definitie van de cardinaliteit. Door de tijd heen kunnen de meeste objecten meerdere bestaansafhankelijke objecten hebben. 9

Het ER-schema definieert entiteittypes en relatietypes. Omdat ook geaggregeerde relatietypes mogelijk zijn, maken we in de definitie geen onderscheid tussen entiteittypes en relatietypes: elk relatietype kan immers potentieel de rol van een entiteittype spelen. De term associatie wordt gebruikt om de connectie tussen een relatietype en een entiteittype weer te geven. Definitie. Een ER-schema is opgebouwd uit relatietypes en entiteittypes die met elkaar verbonden worden d.m.v. associaties. Een associatie heeft een richting: ze gaat van een relatietype naar een entiteittype. Sommige associaties zijn zwak. Het relatietype van waaruit de zwakke associatie vertrekt en het entiteittype waarin de associatie toekomt noemen we dan eveneens zwak. Een relatietype kan geaggregeerd worden. Een geaggregeerd relatietype kan overal voorkomen waar een entiteittype voorkomt. Bijgevolg is het onderscheid tussen entiteittype en relatietype een beetje artificieel, en daarom beschouwen we beide soorten componenten als objecttypes. Conventies i.v.m. naamgeving. Een component noemen we een entiteittype indien geen enkel associatie van dit entiteittype vertrekt. Vertrekt er wel een associatie van deze component, dan gaat het om een relatietype. Een relatietype is geaggregeerd indien er tevens een associatie is dat naar dit relatietype gaat. Een relatietype is zwak indien er een zwakke associatie uit vertrekt. Syntactische correctheid. Een ER-schema is syntactisch correct indien het voldoet aan de volgende beperkingen: − Elke associatie verbindt exact twee verschillende objecttypes (entiteittypes of geaggregeerde relatietypes) − Elk niet zwak relatietype relateert minstens twee (niet noodzakelijk verschillende) objecttypes. − Een zwak relatietype en een geaggregeerd relatietype kunnen niet naar zichzelf verwijzen. − Een zwak relatietype kan niet geaggregeerd worden. − Uit elk relatietype vertrekt hoogstens 1 zwakke associatie. Grafische weergave. Een entiteittype wordt weergegeven door een rechthoek, een relatietype als een ruit, een geaggregeerd relatietype als een ruit in een rechthoek en een zwak relatietype als een ruit met een dubbele lijn aan de kant van de zwakke associatie. Associaties worden weergegeven als een lijn die de geassocieerde elementen met elkaar verbindt. De grafische weergave van Voorbeeld 6 wordt gegeven in Fig. 9. Voorbeeld 6 Een ER-schema voor het bibliotheekvoorbeeld zou als volgt kunnen zijn: Objecttypes in het ER-schema zijn: UITLENING, BOEK, COPIE, LID, IS_VAN. Associaties zijn leent, uitgeleend_door, heeft en van. van is een zwakke associatie. De richting van de associaties wordt gegeven in de volgende tabel:

10

Associatie leent uitgeleend_door heeft van

van

naar

UITLENING

LID

UITLENING

COPIE

IS_VAN

BOEK

IS_VAN

COPIE

BOEK heeft

IS_VAN van

COPIE

uitgeleend door

leent

LID

UITLENING

Fig. 9. ER-schema voor de bibliotheek

Cardinaliteit en optionaliteit van Associaties Zij R een relatietype dat de entiteittypes E1, ..., En verbindt. Dit betekent that er n associaties ai (i=1,...,n) zijn die elk vanuit R vertrekken en naar Ei (i=1,...,n) gaan. De associatie ai heeft cardinaliteit 1 als en alleen als een voorkomen van (E1,…,Ei-1,Ei+1,…,En) met hoogstens 1 voorkomen van Ei geassocieerd kan zijn. In het andere geval heeft deze associatie de cardinaliteit many. De optionaliteit van een associatie duidt aan of deelname aan de relatie verplicht is of niet. Als een associatie verplicht is, dan betekent dit dat elke voorkomen van het entiteittype dat via deze associatie verbonden wordt met het relatietype, altijd minstens één maal moet participeren in de relatie. In het andere geval is de associatie optioneel. In Voorbeeld 6 kan een copie met hoogstens 1 lid geassocieerd worden, en dus heeft de associatie ' leent' cardinaliteit 1. Een lid daarentegen, kan met meerdere boeken geassocieerd zijn via uitlening, en dus heeft de associatie ' uitgeleend_door' de cardinaliteit many. De associatie ' van' is verplicht omdat een copie altijd moet relateert zijn met een boek. Met andere woorden: voor elk voorkomen van COPIE is er minstens een overeenkomstig voorkomen van IS_VAN. De associatie ' heeft' is daarentegen niet verplicht omdat het mogelijk is boeken te registreren waarvan (nog) geen copies beschikbaar zijn.

11

Grafische weergave. De cardinaliteit van 1 wordt weergegeven door een 1 te schrijven naast de lijn die de associatie weergeeft. Een cardinaliteit van many wordt op analoge manier weergegeven door een N of M. Fig. 10 geeft de cardinaliteiten en optionaliteiten weer voor Voorbeeld 6. De cardinaliteiten die opgegeven worden in het ER-schema kunnen afwijken van diegenen die men vindt in het bestaansafhankelijkheidsschema omdat in het ER-schema men de relaties niet noodzakelijk bekijkt op één ogenblik in de tijd (zie ook verder).

BOEK heeft 1

IS_VAN van M COPIE

uitgeleend leent door 1 M UITLENING

LID

Fig. 10. ER-schema met cardinaliteiten and optionaliteiten

Het ER-schema versus het bestaansafhankelijkheidsschema Zoals in het voorgaande deel werd uitgelegd, is de semantiek van bestaansafhankelijkheid vervat in die van het ER-schema. Meer bepaald is het concept van bestaansafhankelijkheid equivalent met het begrip zwakke verplichte associatie met cardinaliteit 1. Inderdaad, indien men zo' n associatie heeft, dan zal de zwakke entiteit verbonden zijn met minimum 1 (verplicht), maximum 1 (cardinaliteit 1) en altijd dezelfde (zwak) entiteit van het sterke type. Het is dus mogelijk om het bestaansafhankelijkheidsschema af te leiden uit het ER-schema en wel door middel van de volgende regels: − Elk entiteittype is een objecttype in het bestaansafhankelijkheidsschema. − Elk relatietype dat niet zwak is, is een objecttype in het bestaansafhankelijkheidsschema, dat bovendien bestaansafhankelijk is van de deelnemende entiteittypes. − Een zwak relatietype dat bovendien verplicht is ten opzichte van het zwakke entiteittype wordt niet gemodelleerd als objecttype, maar het zwakke entiteittype wordt rechtstreeks gemodelleerd als bestaansafhankelijk van het sterke entiteittype. − Een zwak relatietype dat niet verplicht is t.o.v. het zwakke entiteittype is een objecttype in het bestaansafhankelijkheidsschema, bestaansafhankelijk van de participerende entiteittypes. Als we deze regels toepassen op het ER-schema van Fig. 9, dan bekomen we het volgende:

12

Voorbeeld 7 Objecttypes zijn UITLENING, BOEK, LID en COPIE. IS_VAN is geen objecttype want het is een zwakke relatie die verplicht is voor het zwakke entiteittype COPIE. Uit het ER-schema leiden we verder de volgende bestaansafhankelijkheden af: UITLENING ← LID and UITLENING ← COPIE omdat UITLENING een niet zwak relatietype is waaraan LID en COPIE deelnemen; COPIE ← BOEK omdat COPIE en BOEK gerelateerd worden door een zwak en verplicht relatietype. Het resultaat is precies het bestaansafhankelijkheidsschema van Fig. 6. Voor binaire relatietypes zijn de cardinaliteiten in het bestaansafhankelijkheidsschema meestal gelijk aan de cardinaliteiten in het ER-schema, op voorwaarde dat het ER-schema de realiteit weergeeft op één ogenblik in de tijd. Het moet m.a.w. een time-sliced ER-schema zijn. Ten gevolge van bepaalde informatiebehoeften kunnen de cardinaliteiten in het ER-schema echter afwijken van die in het bestaansafhankelijkheidsschema. Voorbeeld 8 Leden kunnen boeken uitlenen. Op één ogenblik in de tijd kan een boek maar door één persoon uitgeleend zijn (Fig. 11 (b)). Indien echter een historie van uitleningen moet bijgehouden worden, dan zal het ER-schema zijn zoals in Fig. 11 (a). Door de tijd heen, kan een boek immers meerdere malen uitgeleend worden. In beide gevallen echter blijven de cardinaliteiten van het bestaansafhankelijkheidsschema zoals in Fig. 11 (c). (a) UITLENING COPIE

N M N

M

LID

(b) UITLENING COPIE

M

1

LID

(c) LID

COPIE 1

M UITLENING

Fig. 11. Cardinaliteiten in het ER-schema en het bestaansafhankelijkheidsschema

13

Alhoewel de semantiek van het bestaansafhankelijkheidsschema deel uitmaakt van de semantiek van het ER-schema, is het omgekeerde niet waar. Een bestaansafhankelijkheidsschema dat de objecttypes classificeert volgens de bestaansafhankelijkheidsrelatie kan niet evenveel uitdrukken als het ER-schema. Fig. 12 toont twee ER-schema’s die aanleiding geven tot hetzelfde bestaans afhankelijkheidsschema (Fig. 12(c)). In Fig. 12(a) wordt een RESERVATIE gedefinieerd als een zwak entiteittype dat verplicht verwijst naar KAMERTYPE en KLANT. Volgens dit schema kan een klant verschillende reservaties maken voor hetzelfde kamertype. Elke reservatie verwijst naar één enkel kamertype en één enkele klant, maar niets zegt dat er geen twee reservaties mogen zijn die verwijzen naar hetzelfde kamertype en dezelfde klant. In Fig. 12(b) daarentegen, is RESERVATIE gedefinieerd als een relatie tussen KLANT en KAMERTYPE. Bijgevolg wordt een reservatie uniek geïdentificeerd door de combinatie van de sleutels van klant en kamertype en kan een klant dus hooguit één reservatie maken voor een gegeven kamertype.

(a) KLANT

KAMER TYPE RESER VATIE

(b) RESERVATIE KLANT

KAMER TYPE

(c) KAMER TYPE

KLANT

RESERVATIE

Fig. 12. Hotelreservaties.

Een vereenvoudigde notatie voor het ER-schema Zoals hoger uiteengezet, bevat het ER-model meer semantiek dan het bestaansafhankelijkheidsschema. Omdat niet alle CASE-tools de mogelijkheid bieden voor het weergeven van concepten zoals ternaire, zwakke of geaggregeerde relatietypes, kan het interessant zijn om een vereenvoudigde notatie voor het ER-schema te gebruiken, met enkel binaire relatietypes (1 op 1 of 1 op N). Als we bovendien overeenkomen dat al deze relaties zwak en verplicht zijn aan een kant, dan bevat het vereenvoudigde ER-schema exact dezelfde relaties als het bestaansafhankelijkheidsschema. Fig. 13

14

geeft een mogelijke grafische weergave van deze relaties. Het bestaansafhankelijke entiteittype bevindt zich aan de kant van de pijl(en). Een enkele pijl geeft een cardinaliteit 1 weer; een dubbele pijl een cardinaliteit many. Een witte stip betekent dat deelname aan de relatie optioneel is terwijl een zwarte stip een verplichte participatie weergeeft. Noteer dat de participatie altijd verplicht is voor het zwakke entiteittype.

A

B

Een B is geassocieerd met exact een en altijd dezelfde A Een A is geassocieerd met nul, een of meerdere B’s

A

B

Een B is geassocieerd met exact een en altijd dezelfde A Een A is geassocieerd met een of meerdere B’s

A

B

Een B is geassocieerd met exact een en altijd dezelfde A Een A is geassocieerd met nul of een B

A

B

Een B is geassocieerd met exact een en altijd dezelfde A Een A is geassocieerd met een B

Fig. 13 Vereenvoudigde notatie voor het ER-schema In het vierde geval zou men kunnen denken dat de levensloop van A samenvalt met die van B. Dit is echter niet zo: omdat de relatie zwak is voor B, kan een A nog altijd geassocieerd worden met meerdere B’s na elkaar. A zou bijvoorbeeld een onroerend goed kunnen zijn en B een eigendomstitel. Een eigendomstitel verwijst altijd naar één en hetzelfde onroerende goed en een onroerend goed kan op één ogenblik in de tijd maar het voorwerp zijn van één geldige eigendomstitel. Door verkoop, kan een onroerend goed door de tijd heen wel het voorwerp zijn van meerdere eigendomstitels na elkaar. Om deze reden moet er altijd minstens één pijl voorzien worden in de grafische weergave van de 1 op 1 relatie. Doet men dit niet, dan kan men het zwakke entiteittype niet meer onderscheiden van het sterke entiteittype.

3.3.

De Object-Gebeurtenis Tabel

Definitie Tot hiertoe werd enkel de statische structuur van objecttypes gedefinieerd. Door middel van de object-gebeurtenis tabel en de volgordebeperkingen kunnen we nu ook het gedrag van objecttypes gaan vastleggen. Hiertoe inventariseren we relevante gebeurtenistypes binnen het domein. Deze gebeurtenistypes zijn de basis voor interactie tussen objecten. Het conceptueel schema dat hier voorgesteld wordt, heeft, in tegenstelling tot andere objectgerichte methoden, geen apart interactieschema. De reden hiervoor is dat op het niveau van conceptueel modelleren, we opteren

15

voor communicatie door gezamenlijke deelname aan gebeurtenissen eerder dan communicatie door middel van het zenden van boodschappen. Veronderstel bijvoorbeeld de objecttypes COPIE en LID en het gebeurtenistype ‘lenen’. Communicatie door middel van message passing betekent dat bij het optreden van ‘lenen’, men moet kiezen of de boodschap door de copie naar het lid wordt verzonden of omgekeerd. Bij communicatie door gezamenlijke deelname aan gebeurtenissen, betekent dit dat bij het optreden van een gebeurtenis ‘lenen’, de betrokken copie en het betrokken lid elk een methode ‘lenen’ zullen uitvoeren. Deze manier van communiceren laat nog alle mogelijke opties toe bij implementatie en biedt bovendien interessante mogelijkheden voor implementatie in klassieke (niet objectgerichte) omgevingen. De formalisering ervan leunt nauw aan bij de procesalgebra’s CSP [ 13] en ACP [1], terwijl message passing aanleunt bij CCS [17]. Door middel van de object-gebeurtenis tabel worden de gebeurtenistypes gerelateerd met de objecttypes. De object-gebeurtenis tabel bevat een kolom per objecttype en een rij per gebeurtenistype. Elke cel in de tabel geeft weer of en hoe een objecttype betrokken is bij een gebeurtenistype. De verzameling van alle gebeurtenistype waarin een objecttype P betrokken is, noemen we het alfabet van dat objecttype P en we noteren het als SAP. Bij verdere detaillering van de objecttypes, zal elk objecttype een methode definiëren voor elk gebeurtenistype in zijn alfabet. Wanneer een objecttype participeert in een gebeurtenistype, dan kan men ook aangeven wat deze betrokkenheid juist inhoudt. Gebeurtenissen kunnen objecten creëren, wijzigen of schrappen, wat we respectievelijk aangeven door middel van een C (create), een M (modify) of een D (destroy) in de overeenkomstige cel van de object-gebeurtenis tabel. Het alfabet van een objecttype kan dus opgesplitst worden in drie disjuncte deelverzamelingen, m.n. c(P) = {a | a is een gebeurtenistype dat voorkomens van P creëert} m(P) = {a | a is een gebeurtenistype dat voorkomens van P wijzigt} d(P) = {a | a is een gebeurtenistype dat voorkomens van P schrapt} Syntactische Correctheid. Een syntactisch correcte object-gebeurtenis tabel moet bovendien aan de volgende eisen voldoen: − In elke cel komt er een of blanco, of een ' C' , of een ' M' of een ' D' ; m.a.w. c(P), d(P) en m(P) zijn disjunct. − In elk gebeurtenistype participeert er minstens één objecttype; m.a.w. per rij is er minstens één cel die geen blanco bevat. − Voor elk objecttype is er minstens een gebeurtenistype dat voorkomens van dit objecttype creëert en een ander gebeurtenistype dat voorkomens van dit objecttype schrapt; m.a.w. c(P) en d(P) zijn niet leeg. In elke kolom komt dus minstens één C en één D voor. Voorbeeld 9 Voor een kleine bibliotheek met objecttypes COPIE, LID en UITLENING is het universum van de gebeurtenistypes als volgt: {inschrijven, uitschrijven, kopen, catalogiseren, lenen, hernieuwen, terugbrengen, verliezen, decatalogiseren}, waarbij SACOPIE = {kopen, catalogiseren, lenen, hernieuwen, terugbrengen, verliezen, decatalogiseren} met c(COPIE) = {kopen} m(COPIE) = {catalogiseren, lenen, hernieuwen, terugbrengen, verliezen}

16

d(COPIE) = {decatalogiseren} SAUITLENING = {lenen, hernieuwen, terugbrengen, verliezen} met c(UITLENING) = {lenen}, m(UITLENING) = {hernieuwen} d(UITLENING)= {terugbrengen, verliezen} SALID = {inschrijven, uitschrijven, lenen, hernieuwen, terugbrengen, verliezen} met c(LID) = {inschrijven} m(LID) = {lenen, hernieuwen, terugbrengen, verliezen} d(LID) = {uitschrijven}

Grafische Weergave. De Object-Gebeurtenis Tabel wordt weergegeven als een matrix met een kolom per objecttype en een rij per gebeurtenistype. Een ' C' , ' M' of ' D' op de intersectie van een rij en een kolom betekent dat de het gebeurtenistype van die rij voorkomens van het objecttype van die kolom respectievelijk creëert, wijzigt of schrapt. Fig. 14 is een grafische weergave van Voorbeeld 9. LID

COPIE

UITLENING

inschrijven C uitschrijven D kopen C catalogiseren M lenen M M C hernieuwen M M M terugbrengen M M D verliezen M M D decatalogiseren D Fig. 14. Object-Gebeurtenis Tabel voor de bibliotheek

Het bestaansafhankelijkheidsschema versus de object-gebeurtenis tabel Het statisch en dynamisch schema beschrijven hetzelfde domein en dezelfde objecttypes. Bijgevolg moeten ze in overeenstemming zijn met elkaar, niet alleen syntactisch, maar ook naar inhoudelijke betekenis. Deze controle op overeenkomst wordt uitgevoerd door ervoor te zorgen dat alle elementen uit het bestaansafhankelijkheidsschema ook voorkomen in de object-gebeurtenis tabel en de volgordebeperkingen. Vanuit syntactisch perspectief betekent dit dat er voor elk objecttype in het bestaansafhankelijkheidsschema een kolom moet zijn in de object-gebeurtenis tabel (en vice versa). Bijkomende beperkingen volgen uit de bestaansafhankelijkheidsrelatie tussen objecten. Propagatie-regel Als een objecttype P bestaansafhankelijk is van een objecttype Q, dan moet het alfabet van P een deelverzameling zijn van het alfabet van Q.

17

Deze eis kan als volgt verklaard worden. Bestaansafhankelijke objecten kunnen niet in een gebeurtenis participeren zonder dat het moederobject weet heeft van deze gebeurtenis. Door alle gebeurtenistypes van het buideltype mee op te nemen in het alfabet van het moederobjecttype, worden alle mogelijke plaatsen voor informatievergaring geïdentificeerd. In het bibliotheekvoorbeeld is UITLENING bestaansafhankelijk van LID en COPIE. Dit betekent dat ook LID en COPIE participeren in lenen, hernieuwen, terugbrengen en verliezen. De methode ' lenen' van het objecttype LID is bijvoorbeeld de juiste plaats voor het tellen van het aantal boeken dat een persoon in leen heeft. Hier kan men ook een bedrijfsregel implementeren die bepaalt dat een lid maximaal 15 boeken tegelijk mag uitlenen. De methode ' lenen' bij het objecttype COPIE is dan weer de juiste plaats voor het tellen van het aantal keer dat een copie werd uitgeleend. Hier kan men ook een bedrijfsregel implementeren die stelt dat een copie die 1000 keer werd uitgeleend, gecontroleerd moet worden op goede staat en desnoods moet vervangen worden. Dit betekent echter niet dat met elke gebeurtenistypeobjecttype combinatie een zinvolle methode overeenkomt. Dit is geen probleem omdat tijdens implementatie lege methodes altijd verwijderd kunnen worden om de efficiëntie te bevorderen. Door het toevoegen van de gebeurtenistypes van de buidelobjecttypes aan het alfabet van het moederobjecttype, kunnen binnen de gedragsdefinitie van de moeder ook volgordebeperkingen opgelegd worden aan gebeurtenistypes uit de alfabetten van verschillende buidelobjecttypes. Veronderstel bijvoorbeeld dat copieën kunnen gereserveerd worden. Dit zal aanleiding geven tot een objecttype RESERVATIE dat bestaansafhankelijk is van COPIE en van LID. De beperking dat een copie slechts gereserveerd kan worden als zij uitgeleend is, heeft betrekking op gebeurtenistypes uit twee objecttypes, m.n. RESERVATIE en UITLENING, en moet dus gemodelleerd worden op het niveau van COPIE. Er kan ook een beperking geplaatst worden op de aard van de participatie. Omdat het leven van een buidelobject ingebed is in het leven van het moederobject, valt de creatie van het buidelobject ten vroegste tegelijk met de creatie van het moederobject. Bijgevolg weet men dat een gebeurtenistype dat een voorkomen van een buidelobjecttype creëert ofwel eveneens een voorkomen van het moederobjecttype creëert, ofwel de toestand van het moederobject wijzigt. Bijgevolg, indien P het buidelobjecttype is en Q het moederobjecttype, dan is c(P) een deelverzameling van c(Q) ∪ m(Q). Een analoge redenering leidt tot de conclusie dat gebeurtenistypes die een buidelobject schrappen ofwel het moederobject tegelijk schrappen, ofwel het moederobject wijzigen: d(P) ⊆ d(Q) ∪ m(Q). Tenslotte is een wijziging van het buidelobject altijd een wijziging van het moederobject: m(P) ⊆ m(Q). Samengevat: Aard-van-participatie-regel Als P bestaansafhankelijk is van Q dan moet er voor elke gebeurtenis waarvoor er − bij P een 'C' staat, bij Q een 'C' of een 'M' staan; − bij P een 'M' staat, bij Q eveneens een 'M' staan; − bij P een 'D' staat, bij Q een 'D' of een 'M' staan. De propagatie-regel en de Aard-van-participatie-regel zorgen er samen voor dat het leven van een buidelobject altijd ingebed is in het leven van het moederobject. De propagatie-regel heeft tot gevolg dat het alfabet van een relatietype een deelverzameling is van de doorsnede van de alfabetten van de entiteittypes die deelnemen aan dit relatietype. Omgekeerd eisen 18

we dat wanneer twee objecttypes meer dan twee gemeenschappelijke gebeurtenistypes hebben, deze gebeurtenistypes worden opgenomen in het alfabet van een gemeenschappelijk bestaansafhankelijk objecttype dat de rol speelt van "contract"6. De gemeenschappelijke gebeurtenistypes kunnen eventueel over meerdere contract-objecttypes gespreid worden zodat de contractregel als volgt luidt: Contractregel Indien twee objecttypes meer dan twee gemeenschappelijke gebeurtenistypes in hun alfabet hebben, dan moeten er een of meerdere gemeenschappelijke bestaansafhankelijke objecttypes zijn die deze gebeurtenistypes in hun gemeenschappelijk alfabet hebben. Gemeenschappelijke gebeurtenistypes duiden dus steeds op de aanwezigheid van een relatie tussen deze objecttypes.

3.4.

Het gedragsschema en object interactie

Een volledige definitie van het gedrag van een objecttype omvat naast de participatie in gebeurtenistypes, ook de definitie van volgordebeperkingen die dit objecttype oplegt aan de gebeurtenistypes uit zijn alfabet. Deze volgordebeperkingen worden uitgedrukt met behulp van JSDdiagrammas [15], Finite State Machines (FSMs) of reguliere uitdrukkingen. Vanuit mathematisch oogpunt zijn deze drie specificatietechnieken equivalent [9, 23]. Een rigoureuze consistentiecontrole tussen het bestaansafhankelijkheidsschema en het gedragsschema is slechts mogelijk mits een formele definitie van de gebruikte concepten. Voor een volledige mathematische definitie van volgordebeperkingen en communicatie door gezamenlijke deelname aan gebeurtenissen, verwijzen we naar de procesalgebra van M.E.R.O.DE. [9, 23]. De volgende paragraaf licht heel summier een aantal definities toe, nodig voor het definiëren van de consistentieregels.

Basisdefinities van de procesalgebra van M.E.R.O.DE. Objecttypes kunnen volgordebeperkingen opleggen aan de gebeurtenistypes in hun alfabet. Deze beperkingen worden uitgedrukt met behulp van de drie bewerkingen selectie, sequentie en iteratie. In geval van de techniek van reguliere uitdrukkingen worden deze bewerkingen respectievelijk voorgesteld door de symbolen '+', '.' en '*', zodat a+b a.b a*

betekent betekent betekent

doe a of doe b, doe eerst a en dan b, doe a nul, één of meerdere keren.

De verzameling gebeurtenistypes wordt uitgebreid met een gebeurtenistype ' doe niets' dat wordt voorgesteld door het symbool ' 1' . Dit gebeurtenistype is een neutraal element voor de sequentie,

6. De notie "contract" komt nog verder aan bod in de paragraaf over volgordebeperkingen. 19

m.a.w. a.1 = a = 1.a. Gebruik makend van dit gebeurtenistype kan de iteratie uitgedrukt worden met behulp van de twee bewerkingen '+' en '.': a* = 1 + a + a.a + a.a.a + a.a.a.a + ... =

Σ

ai

i ∈ IN

Dit wil zeggen: doe niets of doe a één keer of doe a twee keer of ... Het symbool drukken:

Σ

wordt ook gebruikt om een selectie uit een verzameling gebeurtenistypes uit te

Σ {a , a , ..., a } = a 1

2

n

1

+ a2 + ... + an

Een objecttype P is dus een paar <α,e> waarbij α e

de verzameling is van de gebeurtenistypes relevant voor P (alfabet van P), ook aangeduid als SAP de uitdrukking is die het gedrag van P bepaalt, ook aangeduid met SRP

Voorbeeld 10 De definitie van een objecttype COPIE zou er bijvoorbeeld als volgt kunnen uitzien: COPIE

= <{kopen, catalogiseren, lenen, hernieuwen, terugbrengen, verliezen, decatalogiseren }, kopen.catalogiseren.(lenen.(hernieuwen)*.terugbrengen)*. [ 1 + (lenen.(hernieuwen)*.verliezen]. decatalogiseren },

Wat men moet lezen als: In de context van een bibliotheek, begint het leven van een copie met de aankoop ervan. De copie wordt vervolgens opgenomen in de cataloog. Het kan vanaf dan meermaals achter elkaar uitgeleend en teruggebracht worden. Eventueel kan een uitlening hernieuwd worden. Het kan voorkomen dat de copie na uitlening verloren geraakt in plaats van teruggebracht te worden. Ten laatste wordt de copie geschrapt uit de cataloog. Een bedrijfsmodel zal in de meeste gevallen uit meer dan één objecttype bestaan. In dat geval kan het gebeuren dat twee of meer objecttypes een aantal gebeurtenistypes gemeenschappelijk hebben. Dit betekent dat deze objecttypes samen deelnemen aan deze gebeurtenistypes en dat gebeurtenissen van dit type alleen dan kunnen optreden als alle betrokken objecten deze gebeurtenis kunnen accepteren overeenkomstig hun gedragsdefinitie. Zoals reeds gezegd, vindt interactie tussen objecten plaats door middel van gemeenschappelijke gebeurtenissen. Met de parallel bewerking || drukken we uit dat objecttypes moeten synchroniseren op gemeenschappelijke gebeurtenistypes in hun alfabet. In plaats van de ||-bewerking op een axiomatische manier te definiëren, geven we een definitie met behulp van de verzameling scenario’s die worden aanvaard door een object type. Een reguliere uitdrukking definieert altijd een verzameling scenario’s, dit zijn sequenties van gebeurtenissen.

20

Definitie 2 De taal van een reguliere uitdrukking is de verzameling van alle scenario’s die geldig zijn volgens deze uitdrukking en wordt gedefinieerd door: L(1) = {1} ∀ a ∈ Α : L(a) = {a} ∀ e, e' ∈ R*(A): L(e + e') = L(e) ∪ L(e'), L(e.e') = L(e).L(e'), L(e*) = L(e)* waarbij L(e).L(e') = { s^t | s ∈ L(e) en t ∈ L(e')} en L(e)* = {1} ∪ L(e) ∪ L(e).L(e) ∪ L(e).L(e).L(e) ∪ L(e).L(e).L(e).L(e) ∪ ... De taal van een object type is de taal van de reguliere uitdrukking van dat object type: L(<α,e>) = L(e) Voorbeeld 11 Indien de definitie van het objecttype COPIE is zoals in Voorbeeld 10, dan zijn mogelijke scenario’s voor COPIE: kopen^catalogeren^lenen^terugbrengen^lenen^verliezen^decatalogeren kopen^catalogeren^lenen^terugbrengen^lenen^terugbrengen^decatalogeren kopen^catalogeren^lenen^terugbrengen^lenen^hernieuwen^terugbrengen^decatalogeren kopen^catalogeren^lenen^hernieuwen^terugbrengen^lenen^terugbrengen^decatalogeren De taal van COPIE is dan de verzameling van alle mogelijke scenario’s voor COPIE. Om de scenario’s van twee objecttypes met verschillend alfabet met elkaar te kunnen vergelijken, projecteren we de scenario’s op de gemeenschappelijke gebeurtenistypes. Hiertoe definiëren we een projectiebewerking \B, waarbij B een verzameling gebeurtenistypes is. De projectie wordt bekomen door alle gebeurtenissen die niet in B voorkomen te vervangen door een 1 (“doe niets” gebeurtenis): Definitie 3 Zij B een verzameling gebeurtenistypes, dan is 1\B = 1 ∀ a ∈ A : (a\B = 1 ⇔ a ∉ B) en (a\B = a ⇔ a ∈ B) ∀ s, t ∈ A* : (s^t)\B = s\B ^ t\B Voorbeeld 12 Veronderstel dat in het bibliotheekvoorbeeld het alfabet van het objecttype UITLENING {lenen, hernieuwen, terugbrengen, verliezen} is. Volgens de definitie gegeven in Voorbeeld 10, is de volgende sequentie een mogelijk scenario voor het objecttype COPIE: kopen^catalogiseren^lenen^hernieuwen^terugbrengen^decatalogiseren Als we dit scenario bekijken vanuit het standpunt van UITLENING, bekomen we het volgende: 1^1^lenen^hernieuwen^terugbrengen^1 = lenen^hernieuwen^terugbrengen Wanneer twee objecttypes concurrent worden uitgevoerd, dan zijn enkel deze scenario’s geldig die voor elk van beide geldig zijn:

21

Definitie 4 Zij P, Q objecttypes, dan is P || Q een objecttype met alfabet SAP ∪ SAQ en met volgordebeperkingen e" zodat L(e") = { s ∈ (SAP ∪ SAQ)* | s\SAP ∈ L(P) and s\SAQ ∈ L(Q)} Dat de uitdrukking e" altijd bestaat werd reeds vroeger bewezen in de theorie van FSMs [14, theorem 8-7, p. 252]. Deze ||-bewerking kan gebruikt worden om het gedrag te berekenen van een systeem dat bestaat uit meerdere parallel lopende objecttypes [9, 23]. Om de volgordebeperkingen van twee objecttypes met elkaar te kunnen vergelijken, definiëren we wat wordt verstaan onder ‘meer deterministisch dan’: Definitie 5 Zij P, Q objecttypes, dan is P meer deterministisch dan Q (P ≤ Q) als en alleen als SAP ⊆ SAQ en L(SRP) ⊆ L[(SRQ)]\ (SAP) Met andere woorden, het alfabet van P moet een deelverzameling zijn van Q en alle scenario’s van P moeten ook geldige scenario’s zijn voor Q, waarbij we abstractie maken van gebeurtenistypes die niet in het alfabet van P voorkomen door Q te projecteren op SAP.

Definitie van het gedragsschema Definitie en grafische weergave. Het gedragsschema definieert volgordebeperkingen voor ieder objecttype met behulp van een reguliere uitdrukking, een JSD-diagramma of een FSM.

Het gedragsschema versus het bestaansafhankelijkheidsschema en de Object-Gebeurtenis Tabel In de Object-Gebeurtenis Tabel wordt het alfabet van een objecttype bepaald en wordt er ook aangegeven of de gebeurtenistypes uit dit alfabet voorkomens van het objecttype creëren, wijzigen of schrappen. Dit bepaalt natuurlijk voor een deel de volgordebeperkingen. In de eerste plaats mogen de definities van volgordebeperkingen enkel de gebeurtenistypes uit het alfabet gebruiken: Alfabet-regel De definitie van de volgordebeperkingen voor een objecttype P moet alle en enkel die gebeurtenistypes gebruiken die in het alfabet van P voorkomen zoals opgegeven in de ObjectGebeurtenis Tabel. Ook de classificatie volgens creëren, wijzigen en schrappen impliceert een default levensloop voor ieder objecttype: objecten worden eerst gecreëerd, kunnen dan nul, één of meerdere keren gewijzigd worden en worden tenslotte geschrapt. De volgordebeperkingen moeten deze default levensloop respecteren: alleen meer deterministische volgordebeperkingen zijn toegelaten:

22

Default-levensloop-regel Voor elke P geldt: als c(P) = {c1,...,cn}, m(P) = {m1,...,mk}, en d(P) = {d1,...,dm} dan moet SRP ≤ ( c1+ ... + cn) . ( m1+ ... + mk) *. ( d1+ ... + dm) De bestaansafhankelijkheidsrelatie definieert een partiële orde op objecttypes. Wat de volgordebeperkingen betreft, definieert de relatie “meer deterministisch dan” eveneens een partiële orde op objecttypes. Sterker nog, deze relatie is de equivalente van de bestaansafhankelijkheidsrelatie op het niveau van gedrag. Dit betekent dat we het volgende eisen: Restrictie-regel Als P bestaansafhankelijk is van Q, dan moet P meer deterministisch zijn dan Q: P <- Q ⇒ P ≤ Q Deze regel kan als volgt gemotiveerd worden: in een systeem bestaande uit een moederobject en een buidelobject zullen beide objecten in parallel met elkaar uitgevoerd worden. De definitie van de parallel operator || bepaalt dat dit systeem enkel die scenario’s zal aanvaarden die zowel door de moeder als door het buidelobject worden aanvaard. Met andere woorden, in we het systeem P || Q bekijken vanuit het standpunt van Q, dan moeten alle scenario’s van dat systeem aanvaardbaar zijn voor Q: L(P || Q)\SAQ ⊆ L(Q). Analoog voor P: P || Q bekeken vanuit het standpunt van P mag enkel scenario’s toelaten die toelaatbaar zijn voor P: L(P || Q)\SAP ⊆ L(P). Elk scenario van het buidelobjecttype dat dus niet aanvaardbaar is voor het moederobjecttype zal dus altijd verworpen worden omdat een buidelobject niet kan bestaan zonder overeenkomstig moederobject. Het is dus verdedigbaar om te eisen dat deze scenario’s uit de specificatie worden verwijderd door te eisen dat P ≤ Q als P een buidelobjecttype is van Q. Het verschil tussen het algemene geval en het geval waar P en Q aan de restrictie-regel voldoen is geïllustreerd in Fig. 15. Voorbeeld 13 Veronderstel de volgende volgordebeperkingen COPIE = <{kopen, catalogiseren, lenen, hernieuwen, terugbrengen, verliezen, decatalogiseren }, kopen.catalogiseren.(lenen.(hernieuwen)*.terugbrengen)*. [ 1 + (lenen.(hernieuwen)*.verliezen]. decatalogiseren }, UITLENING = <{lenen, hernieuwen, terugbrengen, verliezen}, lenen.(hernieuwen)*.(terugbrengen + verliezen)> Gezien UITLENING bestaansafhankelijk is van COPIE, moeten we controleren of UITLENING meer deterministisch is dan COPIE. Vooreerst is het alfabet van UITLENING inderdaad een deelverzameling van het alfabet van COPIE omwille van de propagatie-regel. Verder geldt: SRCOPIE\SAUITLENING = kopen.catalogiseren.(lenen (hernieuwen)*.terugbrengen)*. (1 + (lenen.(hernieuwen)*.verliezen]. decatalogiseren)\SAUITLENING = 1.1.(lenen (hernieuwen)*.terugbrengen)*.[1 + lenen.(hernieuwen)*.verliezen]. 1 = (lenen (hernieuwen)*.terugbrengen)*.[1 + lenen.(hernieuwen)*.verliezen] Deze uitdrukking laat inderdaad alle scenario’s van uitlening toe en dus is UITLENING meer deterministisch dan COPIE.

23

Algemeen geval Scenario’s aanvaard door P

Scenario’s aanvaard door Q

Scenario’s verworpen door P

Scenario’s aanvaard door P || Q

Scenario’s verworpen door Q

P bestaansafhankelijk van Q en meer deterministisch dan Q Scenario’s aanvaard door Q Scenario’s aanvaard door P

Scenario’s aanvaard door P || Q

Scenario’s verworpen door P

Fig. 15. Restrictie-regel voor bestaansafhankelijke objecttypes

Op analoge wijze kunnen we controleren of uitlening meer deterministisch is dan LID, waarbij LID = < {inschrijven, lenen, hernieuwen, terugbrengen, verliezen, uitschrijven}, inschrijven.(lenen + hernieuwen + terugbrengen + verliezen)*.uitschrijven> SRLID\ SAUITLENING = inschrijven.(lenen + hernieuwen + terugbrengen + verliezen)*.uitschrijven \ SAUITLENING = 1.(lenen + hernieuwen + terugbrengen + verliezen)*.1 = (lenen + hernieuwen + terugbrengen + verliezen)* Ook hier komen we tot het besluit dat UITLENING meer deterministisch is dan LID. Het resultaat is dat de verzameling scenario’s die aanvaard worden door een buidelobjecttype, een deelverzameling is van de doorsnede van de verzamelingen scenario’s van al de moederobjecttypes. In die zin is het buidelobjecttype een contract tussen alle moederobjecttypes: het legt vast welke

24

scenario’s door alle moederobjecttypes zullen aanvaard worden. In het bibliotheekvoorbeeld is UITLENING een contract tussen LID en COPIE (zie Fig. 16).

Scenario’s aanvaard door COPIE

Scenario’s aanvaard door LID

Contractgebied d

Scenario’s aanvaard door het contract UITLENING

Fig. 16. UITLENING als contract tussen LID en COPIE

Noteer dat de restrictie-regel slechts in één richting geldt: het kan gebeuren dat een objecttype meer deterministisch is dan een ander, zonder dat het er daarom bestaansafhankelijk van is: Voorbeeld 14 TEKENING = < …, tekenen.(weggeven + krijgen)*.wegwerpen> KIND = < …, (...).(tekenen + weggeven + krijgen + wegwerpen)*.(...)> Dan is TEKENING ≤ KIND, hoewel een tekening niet bestaansafhankelijk is van een kind. Omdat TEKENING en KIND meer dan twee gemeenschappelijke gebeurtenistypes hebben, moet er minstens een bestaansafhankelijk objecttype zijn dat deze gemeenschappelijke gebeurtenistypes in zijn alfabet heeft. In dit geval is dat het objecttype EIGENDOM = <…, (tekenen + krijgen).(weggeven + wegwerpen)>

Geïnteresseerde lezers vinden in Appendix A een volledige formele definitie van het conceptueel model. De volgende paragraaf illustreert het volledige specificatie- en controleproces met behulp van een iets groter voorbeeld.

25

4. EEN CASE-STUDY: CONCEPTUEEL SCHEMA VOOR PROJECTADMINISTRATIE Het EDP-departement van een groot bedrijf bestaat uit meerdere groepen. Voor elk ontwikkelingsproject is er een groep verantwoordelijk. Medewerkers van verschillende groepen kunnen voltijds of deeltijds aan een project toegewezen worden. Om de kostprijs van systeemontwikkeling te kunnen achterhalen, moet iedere medewerker het aantal gewerkte uren per project registreren. Een persoon kan enkel registreren voor een project waaraan hij/zij toegewezen is. Wanneer een project beëindigd is, worden alle toewijzingen eveneens afgesloten, zodat registratie voor die projecten onmogelijk wordt. De projectgegevens kunnen wel nog bewaard worden voor latere analyse. Als objecttypes vinden we GROEP, PROJECT, PERSOON en REGISTRATIE. GROEP_TOEWIJZING is de relatie die vastlegt aan welke groep een persoon is toegewezen. PROJECT_TOEWIJZING legt vast aan welke groep een project is toegewezen en TOEWIJZING legt vast welke personen aan welk project zijn toegewezen. Het ER-schema wordt weergegeven in Fig. 17.

1

GROEP

GROEP TOEWIJZING

1

PROJECT TOEWIJZING

N

N PERSOON

N

TOEWIJZING

M

PROJECT

1

N REGISTRATIE

Fig. 17. ER-schema voor de projectadministratie Het bestaansafhankelijkheidsschema wordt uit dit ER-schema afgeleid (zie Fig. 18): • PROJECT_TOEWIJZING is als relatieobjecttype bestaansafhankelijk van PROJECT en GROEP, • GROEP_TOEWIJZING is als relatieobjecttype bestaansafhankelijk van PERSOON en GROEP, • TOEWIJZING is als relatieobjecttype bestaansafhankelijk van PROJECT en PERSOON, • REGISTRATIE is rechtstreeks bestaansafhankelijk van TOEWIJZING.

26

GROEP

PERSOON

PROJECT

N N

1

PROJECT TOEWIJZING

N

1 GROEP TOEWIJZING

N

TOEWIJZING

N REGISTRATIE

Fig. 18. Bestaansafhankelijkheidsschema voor de projectadministratie In de Object-Gebeurtenis Tabel (Fig. 19) nemen we al deze objecttypes op in de kolommen en inventariseren we de relevante gebeurtenistypes. Voor elk objecttype moet er minstens een creëeren een schrap-gebeurtenis zijn. Bovendien moeten een PROJECT en een TOEWIJZING kunnen afgesloten worden, wat aanleiding geeft tot de gebeurtenistypes sluit_project en sluit_toew. Omdat bij het afsluiten van een project alle toewijzingen moeten afgesloten worden zodat er geen registraties meer kunnen gebeuren, nemen we sluit_project ook op in het alfabet van TOEWIJZING. Eens deze basisparticipaties zijn aangeduid, propageren we de gebeurtenisparticipaties volgens het bestaansafhankelijkheidsschema (propagatie-regel). Het eenvoudigste is te beginnen met de objecttypes die helemaal onderaan in het bestaansafhankelijkheidsschema staan en deze participaties te propageren naar het hogere niveau. Zo kunnen we stap voor stap opklimmen in het bestaansafhankelijkheidsschema. In dit voorbeeld beginnen we dus met het propageren van participaties in de kolom van REGISTRATIE naar die van TOEWIJZING. Deze worden op hun beurt gepropageerd naar PROJECT en PERSOON. De participaties van GROEP_TOEWIJZING worden gepropageerd naar GROEP en PERSOON en die van PROJECT_TOEWIJZING naar PROJECT en GROEP. Hierbij respecteren we de Aard-van1 participatie-regel. Daarna moet nog gecontroleeerd worden of aan de contractregel is voldaan. GROEP

cr_groep schr_groep cr_project sluit_project schr_project cr_persoon schr_persoon cr_proj_toew schr_proj_toew cr_groep_toew schr_groep_toew cr_toew sluit_toew_ schr_toew registreer schr_registratie

PROJECT

PERSOON

C M D

M

PROJECT TOEW.

GROEP TOEW.

TOEW.

REGISTRATIE

C D M

C D M M M M

M M

M M M M M

C D M M M M M M M

C D

Fig. 19. Object-Gebeurtenis Tabel voor de projectadministratie

27

C M D M M

C D

Tenslotte moeten de volgordebeperkingen opgelegd door ieder objecttype nog gedefinieerd worden. We doen dit met behulp van reguliere uitdrukkingen (zie Fig. 20). Elke reguliere uitdrukking bevat exact die gebeurtenistypes waarvoor er een C, M of D in de Object-Gebeurtenis Tabel staat (alfabetregel). Bovendien moet de default levensloop gerespecteerd worden (default-levensloop-regel). Wanneer de volgordebeperkingen gecontroleerd worden op de restrictie-regel, vinden we een fout: hoewel TOEWIJZING bestaansafhankelijk is van PROJECT, is TOEWIJZING niet meer deterministisch dan PROJECT. Inderdaad, sommige scenario’s van TOEWIJZING zijn niet conform de volgordebeperkingen opgelegd door PROJECT. De volgordebeperkingen van PROJECT eisen dat elk scenario eindigt met een sluit_project gebeurtenis: SRPROJECT\ SATOEWIJZING =

(cr_toew + sluit_toew + schr_toew + registreer + schr_registratie)*.sluit_project

Bijgevolg kan een sluit_project gebeurtenis niet meer gevolgd worden door een schr_registratie of schr_toew gebeurtenis zoals toegelaten wordt door de volgordebeperkingen van TOEWIJZING. Erger zelfs, de specificatie van PROJECT eist dat een schr_toew gebeurtenis steeds vooraf gaat aan de sluit_project gebeurtenis, terwijl in de specificatie van TOEWIJZING het omgekeerde staat: sluit_project komt steeds voor schr_toew. Het conceptueel schema bevat dus tegenstrijdige volgordebeperkingen, wat bij uitvoering kan resulteren in een deadlock. SRGROEP = cr_groep.(cr_project_toew + schr_project_toew + cr_groep_toew + schr_groep_toew)*.schr_groep SRPROJECT = cr_project . (cr_project_toew+ schr_project_toew + cr_toew + sluit_toew + schr_toew + registreer + schr_registratie)* .sluit_project .schr_project SRPERSOON = cr_persoon .(cr_groep_toew + schr_groep_toew + cr_toew + sluit_toew + sluit_project + schr_toew + registreer + schr_registratie)* . schr_persoon SRPROJECT_TOEWIJZING = cr_project_toew.schr_project_toew SRGROEP_TOEWIJZING = cr_groep_toew.schr_groep_toew SRTOEWIJZING = cr_toew.(registreer + schr_registratie)* .(sluit_toew + sluit_project).(schr_registratie)*. schr_toew SRREGISTRATIE = registreer.schr_registratie Fig. 20. Volgordebeperkingen voor de projectadministratie

Het conceptueel schema kan verbeterd worden door de sluit_project gebeurtenis te verwijderen uit de specificatie van TOEWIJZING en PERSOON. De correcte oplossing heeft als specificatie voor TOEWIJZING:

28

SRTOEWIJZING = cr_toew.(registreer + schr_registratie)* .sluit_toew .(schr_registratie)*. schr_toew Het feit dat alle toewijzingen die verwijzen naar een gegeven project moeten gesloten worden vóór het project afgesloten wordt, staat in feite al in de volgordebeperkingen van PROJECT. In deze specificatie staat immers dat een sluit_toew gebeurtenis niet na een sluit_project gebeurtenis kan komen. Een correcte procedure voor event handling zal controleren of alle toewijzingen gesloten zijn, vooraleer de sluit-project gebeurtenis toe te laten.

5. VERGELIJKING MET ANDERE CONCEPTEN 5.1.

Generalisatie/Specialisatie (Kind Of -lattice)

Alhoewel een moederobjecttype alle gebeurtenistypes van zijn buidelobjecttypes “erft” door de propagatie-regel, is er geen inheritance-relatie tussen het moederobjecttype en het buidelobjecttype. Evenzo is er geen bestaansafhankelijkheidsrelatie tussen een generalisatie en een specialisatie: het leven van een specialisatie-object hangt niet af van het leven van een generalisatie-object (Zie [22] voor meer details). Omdat een specialisatietype alle kenmerken erft van het generalisatietype, erft het ook alle buidelobjecttypes. Men zou dus kunnen verwachten dat het nodig is om de volgordebeperkingen van het specialisatietype te vergelijken met de volgordebeperkingen van de geërfde buidelobjecttypes volgens de ‘meer deterministisch dan’-relatie (restrictie-regel). Indien men echter als regel oplegt dat een specialisatietype de geërfde volgordebeperkingen ongewijzigd moet laten en zeker niet strenger mag maken, dan is dergelijke controle niet nodig: men kan wiskundig aantonen dat er dan automatisch aan de restrictie-regel is voldaan.

5.2.

Aggregatie (Part Of -lattice)

Alhoewel de ‘Part-Of’ relatie een relatie is zoals alle anderen, voorzien bijna alle objectgerichte analysemethodes in een speciale notatie voor dit concept [12, 20, 16, 19, 20, 5]. Dit ligt waarschijnlijk aan het feit dat sommige aspecten van bestaansafhankelijkheid7 en van het propageren van gebeurtenissen8 deel uitmaken van het concept van aggregatie. Bestaansafhankelijkheid en aggregatie zijn nochtans geen equivalente begrippen: soms zijn aggregatierelaties bestaansafhankelijk en 7. Zie bijvoorbeeld [19], p. 38: “The existence of a component object may depend on the existence of the aggregate object of which it is part. ... In other cases, component objects have an independent existence, ...” 8. Zie bijvoorbeeld [19], p. 60: “Propagation is the automatic application to a network of objects when the operation is applied to some starting object. For example: moving an aggregate moves its parts; the move operation propagates to the parts. Propagation of operations to parts is often a good indicator of aggregation.” 29

soms zijn ze het niet. Bijvoorbeeld, een auto is een aggregaat waarvan (onder andere) wielen deel uitmaken. De wielen zijn echter niet bestaansafhankelijk van de auto: als de auto gedemonteerd wordt, bestaat hij niet meer, maar de wielen nog wel. Een order daarentegen, is een aggregaat van orderlijnen die wel bestaansafhankelijk zijn van dat order. Ook het al of niet propageren van gebeurtenissen is niet altijd eenduidig: het schrappen van een auto betekent niet dat ook al de onderdelen geschrapt moeten worden maar het schrappen van een order impliceert wel het schrappen van de orderlijnen. Zoals terecht opgemerkt door de Champeaux et al. [8], is het concept van aggregatie slecht en onvoldoende gedefinieerd. Het is niet altijd duidelijk wanneer het concept wel of niet gebruikt moet worden en de semantiek is ook niet precies gedefinieerd. Het is niet altijd duidelijk of de delen van een aggregaat bestaansafhankelijk zijn van het aggregaat, of en welke operaties moeten gepropageerd worden en of de aggregatie-relatie transitief is [2, 5, 7, 15, 16, 19, 20]. Soms zijn de definities in de verschillende objectgerichte analysemethoden in contradictie met elkaar. Fusion [7] beschouwt aggregatie en geaggregeerde relaties als gelijkaardige concepten omdat men in beide gevallen tupels neemt van deelnemende objecten. In Fusion kunnen aggregaties dus gebruikt worden om relatietypes te modelleren als objecttypes (geaggregeerde relatietypes). Deze manier van werken contrasteert met de OMT methode [19] die geaggregeerde relatietypes en de Part-Of relatie als verschillende concepten ziet. De bestaansafhankelijkheidsrelatie die hier werd voorgesteld, biedt een alternatief voor zowel het concept van aggregatie (Part-Of) als voor het concept van geaggregeerde relaties. De vraag of relatietypes nu wel of geen objecttypes zijn, wordt opgelost door het bestaansafhankelijkheidsschema af te leiden uit het ER-schema: alle niet zwakke en verplichte relatietypes zijn objecttypes in het bestaansafhankelijkheidsschema. Een Part-Of relatie met bestaansafhankelijke componenten kan vervangen worden door zwakke en verplichte relatietypes. Zodoende is de Part-Of relatie identiek met de bestaansafhankelijkheidsrelatie in geval van bestaansafhankelijke componenten. Fig. 21 illustreert dit voor orders en orderlijnen. Links is de Part-Of relatie is weergegeven met een ruit volgens de notatie van OMT [19]; de zwarte stip geeft weer dat een order meerdere orderlijnen kan bevatten. Rechts wordt het equivalente bestaansafhankelijkheidsschema weergegeven.

ORDER

ORDER

M ORDERLIJN

ORDERLIJN

Fig. 21. Bestaansafhankelijke componenten: Object diagram en bestaansafhankelijkheidsschema

30

Wanneer de componenten niet bestaansafhankelijk zijn van het aggregaat, moet de relatie tussen aggregaat en onderdeel gemodelleerd worden als een apart objecttype. Dit objecttype is een soort contract tussen aggregaat en component voor de duur van de Part-Of-relatie. Het object diagram in Fig. 22 modelleert dat een PC bestaat uit een monitor, een systeemkast, een toetsenbord en nul, een of meerdere externe schijfeenheden.

PC

MONITOR

SYSTEEM

TOETSEN

EXTERNE

KAST

BORD

SCHIJFEENH.

CONTENT

Fig. 22. Niet bestaansafhankelijke componenten: Object diagram

MONITOR

1

TOETSEN BORD

PC

1

EXTERNE SCHIJFEENH. M

1

1

1 MONITOR GEBRUIK

SYSTEEM KAST

TOETSEN BORD GEBRUIK

1

SYSTEEM KAST GEBRUIK USE

1 EXTERNE SCHIJFEENH. GEBRUIK

Fig. 23. Niet bestaansafhankelijke componenten: bestaansafhankelijkheidsschema

Fig. 23 toont het equivalente bestaansafhankelijkheidsschema. De cardinaliteiten in dit schema bepalen dat elke component door hoogstens één PC tegelijkertijd gebruikt kan worden en dat een PC bestaat uit één monitor, één toetsenbord, één systeemkast en nul, een of meerdere externe schijfeenheden. Hergebruik van componenten door andere PC’s is mogelijk. Naast overwegingen i.v.m. bestaansafhankelijkheid, impliceert de Part-Of relatie gewoonlijk ook een aantal concurrentie-aspecten: de toestand van het aggregaat wordt mede bepaald door de toestand van de componenten. In [9, 23] werd aangetoond hoe met behulp van de parallel operator || het gedrag van een systeem dat bestaat uit meerdere objecttypes kan berekend worden, vertrekkende vanuit de individuele gedragsdefinities van elk objecttype. Dezelfde principes zijn van toepassing op een deelsysteem dat bestaat uit een aggregaat en zijn component objecttypes.

31

6. DISCUSSIE EN BESLUIT In dit artikel werd een nieuw classificatieprincipe voorgesteld: bestaansafhankelijkheid genoemd. Bestaansafhankelijkheid is aanwezig in elke gegevensmodel dat minstens twee gerelateerd entiteittypes bevat: ofwel is het ene entiteittype bestaansafhankelijk van het andere, of wel is het relatietype een derde objecttype bestaansafhankelijk van de deelnemende entiteittypes. Consistentiecontrole is gebaseerd op twee basisprincipes: het propageren van gebeurtenistypes en bestaansafhankelijke objecttypes als contract tussen moederobjecttypes. Propageren van gebeurtenistypes. Gebeurtenistypes van het bestaansafhankelijke objecttype worden gepropageerd naar het moederobjecttype. Bestaansafhankelijke objecttypes als contract. Wanneer twee objecttypes meer dan een gemeenschappelijk gebeurtenistype hebben, dan is er minstens een bestaansafhankelijk objecttype dat deze gemeenschappelijke gebeurtenistypes in zijn alfabet heeft. Dit bestaansafhankelijk objecttype speelt de rol van contract tussen de moederobjecttypes: het contract waarborgt dat de moederobjecttypes het eens zijn over de volgordebeperkingen die opgelegd worden aan de gemeenschappelijke gebeurtenistypes. Indien deze volgordebeperkingen uitgedrukt worden als reguliere uitdrukkingen (of een equivalent formalisme: JSD-diagrammas of FSMs), dan kan de controle van het contract geautomatiseerd worden. Door objecttypes te classificeren volgens bestaansafhankelijkheid, wordt de vraag of een relatietype een objecttype is of niet, irrelevant. Door relaties de facto te modelleren als objecttype zal het aantal objecttypes in het conceptueel schema weliswaar toenemen, doch de complexiteit van elk objecttype zal dalen. Dit is positief omdat een groot volume minder problemen oplevert dan een grote complexiteit. Bovendien kan tijdens de implementatie het aantal objectklassen gereduceerd worden door sommige klassen samen te voegen. In Fig. 3 (b), is het relatietype “groepeert” niet zwak, en dus is het een objecttype op zichzelf dat enkel bestaat uit referenties naar het order en de orderlijn. Dit object kan echter probleemloos samengevoegd worden met het objecttype ORDERLIJN. ORDERLIJN zal dan een referentie naar order bevatten die gewijzigd mag worden indien een orderlijn wordt toegewezen aan een ander order. In Fig. 3 (a), is het relatietype “groepeert” wel zwak, en dus hebben we hier slechts twee objecttypes, ORDER en ORDERLIJN, waarbij ORDERLIJN een referentie naar order bevat die niet gewijzigd mag worden omwille van de bestaansafhankelijkheid. Het is zonder meer duidelijk dat bestaansafhankelijkheid een alternatief biedt voor de onduidelijke gedefinieerde Part-Of-relatie. Het concept van bestaansafhankelijkheid omvat de interessante eigenschappen van de Part-Of relatie en de precieze definitie laat een ondubbelzinnig gebruik toe. In vergelijking met de Part-Of relatie heeft bestaansafhankelijkheid het voordeel dat: • de semantiek eenvoudig is en gemakkelijk te formaliseren, • het gebruik van het concept eenduidig is, • het toelaat om gedragsschema te controleren op consistentie met het statisch schema door bestaansafhankelijke objecttypes te beschouwen als contracten, • de semantiek van de concurrency-aspecten goed gedefinieerd zijn [23, 9].

32

REFERENTIES 1. Baeten, J.C.M., Procesalgebra, Kluwer programmatuurkunde, 1986 2. Booch, G., Object Oriented Analysis and Design with Applications. Second Edition, Benjamin/Cummings, Redwood City, CA, 1994. 3. Chen, P.P., The Entity Relationship Approach to logical Database Design, QED information sciences, Wellesley (Mass.),1977 4. Chen P. P., The Entity-Relationship Model - Toward a Unified View of Data, ACM Transactions on Database Systems, Vol. 1, No. 1 (1976) 9-36. 5. Coad P., and Yourdon, E. Object-Oriented analysis. Prentice Hall, Englewood Cliffs, N.J., 1991. 6. Codd E.F., A relational model of data for large shared data banks, Communication of the ACM, Vol. 13 No. 6 (June 1970), pp. 377-387 7. Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes, F. Jeremaes, P., ObjectOriented Development, The FUSION Method. Prentice Hall, Englewood Cliffs, N.J., 1994. 8. de Champeaux D., Lea D., Faure P., Object-Oriented System Development, Addison Wesley Publishing Company, 1993 9. Dedene G., Snoeck M., Formal deadlock elimination in an object oriented conceptual schema, Data and Knowledge Engineering, Vol. 15 (1995) 1-30 10. A. Dogac and P. P. Chen, Entity-Relationship Model in the ANSI/SPARC Framework, in P.P. Chen, Entity Relationship Approach to Information Modelling and Analysis, Proc. of the Second International Conference on Entity-Relationship Approach, Washington D.C., October 12- 14 , 1981, North Holland, 1983, pp. 357 - 374 11. A. Dogac, E. Ozkarahan, P. Chen, An integrity system for a relational database architecture, in F. H Lochovsky, Entity Relationship Approach to Database Design and Querying, Proc. of the Eight International Conference on Entity-Relationship Approach, Toronto, Canada, 18-20 October, 1989,North-Holland, 1990, pp. 287 - 301 12. Embley, D.W., Kurtz, B.D., and Woodfield, S.N. Object-Oriented Systems Analysis: A ModelDriven Approach. Yourdon Press, Prentice Hall, Englewood Cliffs, N.J., 1992. 13. Hoare C. A. R., Communicating Sequential Processes (Prentice-Hall International, Series in Computer Science, 1985). 14. Hopcroft John E., Ullman Jeffrey D., Formal languages and their relation to automata, Addison Wesley Publishing Company, 1969 15. Jackson, M. A., System Development, Prentice Hall Englewood Cliffs (N.J.), 1983, 418 pp. 16. Jacobson Ivar et al., Object-Oriented Software Engineering, A use Case Driven Approach, Addison-Wesley, 1992 17. Milner R., A calculus of communicating systems (Springer Berlin, Lecture Notes in Computer Science, 1980). 18. F. Put, Introducing dynamic and temporal aspects in a conceptual (database) schema, doctoral dissertation, Faculteit der Economische en Toegepaste Economische Wetenschappen, K.U.Leuven, 1988, 415 pp. 19. Rumbaugh, J., Blaha M., Premerlani, W., Eddy, F., Lorensen, W., Object Oriented Modelling and Design, Prentice Hall International, 1991 20. Shlaer, S., Mellor, S.J., Object-Oriented Systems Analysis: Modelling the World in Data, Prentice Hall, 1988

33

21. S. Shlaer, S.J. Mellor, Object Lifecycles: Modeling the World in States (Prentice Hall, Englewood Cliffs, New Jersey, 1992). 22. Snoeck Monique, Dedene Guido, Generalization/Specialization and Role in Object Oriented Conceptual Modeling, Data and Knowledge Engineering, 19(2), 1996 23. Snoeck Monique, On a Process Algebra Approach to the construction and analysis of M.E.R.O.DE.-based conceptual models, PhD. Dissertation (Katholieke Universiteit Leuven, Faculty of Science & Department of Computer Science, May 1995) 24. Webre N. W., An Extended Entity-Relationship Model and its Use on a Defence Project, in Entity Relationship Approach to Information modeling and Analysis, P. P. Chen (ed.), 1983, pp.173-193

34

APPENDIX A Definitie Een conceptueel schema is een ER-schema (ER , A , W ) en een afgeleide verzameling van objecttypes M ⊆ zodat: (a)

∪

SAP P∈M

=A

(b) Het ER-schema voldoet aan de volgende beperkingen 1) Elke associatie relateert exact twee verschillende elementen van ER : ∀ a ∈ A : from(a), to(a) ∈ ER and from(a) ≠ to(a) 2) Elk relationshietype relateerd minstens twee (niet noodzakelijk verschillende) elementen: ∀ R ∈ ER , a ∈ A : [ from(a) = R ⇒ ∃ b ∈ A : from(b) = R ] 3) Een zwak relatietype kan niet geaggregeerd worden: ∀ R ∈ ER : [ ∃ a ∈ W : from(a) = R ⇒ ¬(∃ b ∈ A : to(b) = R) ] 4) Een zwak relatietype is zwak ten opzichte van hoogstens een element: ∀ R ∈ ER : [ ∃ a ∈ W : from(a) = R ⇒ ¬(∃ b ∈ W : from(b) = R) ] (c) M bevat alle entiteittypes en relatietypes van ER , met uitzondering van de zwakke verplichte relatietypes. M = ER \ { R  ∃ b ∈W : from(b) = R} (d) Het bestaansafhankelijkheidsschema wordt afgeleid uit het ER-schema met behulp van de volgende regels: <- is een bag over M × M zodat ∀ P, Q ∈ ER : (P,Q) ∈ <- ⇔ ∃ a ∈ A \W : from(a) = P and to(a) = Q and ¬(∃ b ∈W : from(b) = P) or ∃ a ∈ W; ∃ b ∈ A\W; ∃ R ∈ ER : from(a) = R and to(a) = P and from(b) = R and to(b) = Q <- moet aan de volgende beperkingen voldoen: 1) Het bestaansafhankelijkheidsschema is volledig geconnecteerd: ∀ P ∈ M: ∃ Q ∈ M: (P,Q) ∈ <- or (Q,P) ∈ <2) Een objecttype is nooit bestaansafhankelijk van zichzelf: ∀ P ∈ M : (P,P) ∉ <3) <- is acyclisch. Dit betekent dat: ∀ n ∈ IN, n ≥ 2, ∀ P1, P2, ..., Pn ∈ M: (P1,P2), (P2,P3),..., (Pn-1,Pn) ∈ <- ⇒ (Pn,P1) ∉ <(e) De Object-Gebeurtenis Tabel is een matrix met één rij per gebeurtenistype in A en een kolom per objecttype in M. Elke cell bevat een blanco, 'C', 'M' of 'D'. T ⊆ M × A × {' ', 'C', 'M', 'D'} zodat 1) ∀ P ∈ M, ∀ a ∈ A : (P,a,' ') ∈ T or (P,a,'C') ∈ T or (P,a,'M') ∈ T or (P,a,'D') ∈ T

35

2) ∀ P ∈ M : c(P) = {a ∈ A | (P,a,'C') ∈ T} m(P) = {a ∈ A | (P,a,'M') ∈ T} d(P) = {a ∈ A | (P,a,'D') ∈ T} 3) c(P), m(P), d(P) zijn paarsgewijs disjunct c(P) ∪ m(P) ∪ d(P) = SAP c(P), d(P) ≠ ∅ 4) Propagatie-regel and Aard-van-participatie-regel P <- Q ⇒ SAP ⊆ SAQ and c(P) ⊆ c(Q) ∪ m(Q) and m(P) ⊆ m(Q) and d(P) ⊆ d(Q) ∪ m(Q) 5) Contract-regel : ∀ P, Q ∈ M : #(SAP ∩ SAQ) ≥ 2 ⇒ ∃ R1, R2, ... Rn ∈ M: ∀ i ∈ {1,...,n}: Ri <- P,Q and SAR1 ∪ ... ∪ SAR2 = SAP ∩ SAQ (f) M definieert volgordebeperkingen voor ieder objecttype zodat 1) Alfabet-regel : ∀ P ∈ M : ϕ(SRP) = SAP 2) Default-levenscyclus-regel : ∀ P ∈ M : SRP ≤ (Σ c(P)).(Σ m(P))*.(Σ d(P)) 3) Restrictie-regel : ∀ P, Q ∈ M: P <- Q ⇒ P ≤ Q

36