Bestaansafhankelijkheid: Conceptueel modelleren volgens contract.

Transcriptie

1 Bestaansafhankelijkheid: Conceptueel modelleren volgens contract. Dr. M. Snoeck Prof. dr. G. Dedene Katholieke Universiteit Leuven Dept. Toegepaste Economische Wetenschappen Naamsestraat 69, 3000 Leuven {Monique.Snoeck, 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.. 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 (Part- Of) de belangrijkste classificatieprincipes zijn. Bijna elke objectgerichte methode heeft een aparte notatie voor het aangeven van deze speciale relaties [2, 5, 7, 2, 6, 9, 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.

2 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 FSMs. 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 [2] 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.. Finite State Machines (FSMs) modelleren gedrag door het specificeren van toestanden en mogelijke overgangen tussen toestanden. 2

3 2. DE ALOMTEGENWOORDIGHEID VAN BESTAANSAFHANKELIJKHEID 2.. 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. 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, maximum 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.. TIJD Leven van het moederobject Mogelijkheden voor het leven van een buidelobject Fig.. Leven van moeder- en buidelobject Voorbeeld 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

4 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 Gebouw Orderlijn ID Order Fig. 2. Zwak entiteittype and ID dependent entiteittype. KAMER 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 relatietype 2. 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 [0] 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 [] worden meer precieze definities gegeven en hierin wordt bepaald dat een zwak relatietype een zwak entiteittype verbindt met een sterk entiteittype. 4

5 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, 0, ]. De eerste definities [4, 0] 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 [, 8] 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 groepeert M ORDERLIJN (b) ORDER M groepeert 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, 0, ], de volgende drie veronderstellingen impliceren: 5

6 Veronderstelling : 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 hebben 3. 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 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 ITLENING BO EK LID 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

7 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. ER schema Object Gebeurtenis Tabel Bestaansafhankelijkheidsschema Gedragsschema Fig. 5. Consistentiecontrole tussen de vier subschema s 3.. Het bestaansafhankelijkheidsschema Basisdefinitie Bestaansafhankelijkheid is een partiële orde op objecttypes zoals gedefinieerd in Definitie. 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

8 BOEK COPIE LID UITLENING Fig. 6. Bestaansafhankelijkheidsschema voor de bibliotheek Syntactische correctheid. Een syntactisch correct bestaansafhankelijkheidsschema voldoet aan de volgende beperkingen: ) 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 huwelijk 4 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

9 Notatie. P() Q indien elk voorkomen q van Q hooguit één bestaansafhankelijk voorkomen p van P kan hebben op één ogenblik in de tijd 5. 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 en van N. Fig. 8 geeft het bestaansafhankelijkheidsschema met cardinaliteiten. Dus: COPIE (n) BOEK, UITLENING () COPIE en UITLENING (n) LID BOEK M COPIE LID M 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

10 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 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: 0

11 Associatie van naar leent UITLENING LID uitgeleend_door UITLENING COPIE heeft IS_VAN BOEK van 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 E,..., E n verbindt. Dit betekent that er n associaties a i (i=,...,n) zijn die elk vanuit R vertrekken en naar E i (i=,...,n) gaan. De associatie a i heeft cardinaliteit als en alleen als een voorkomen van (E,,E i-,e i+,,e n ) met hoogstens voorkomen van E i 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 lid geassocieerd worden, en dus heeft de associatie ' leent' cardinaliteit. 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.

12 Grafische weergave. De cardinaliteit van wordt weergegeven door een te schrijven naast de lijn die de associatie weergeeft. Een cardinaliteit van many wordt op analoge manier weergegeven door een N of M. Fig. 0 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 IS_VAN van M COPIE uitgeleend door leent M UITLENING LID Fig. 0. 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. Inderdaad, indien men zo' n associatie heeft, dan zal de zwakke entiteit verbonden zijn met minimum (verplicht), maximum (cardinaliteit ) 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: 2

13 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. (b)). Indien echter een historie van uitleningen moet bijgehouden worden, dan zal het ER-schema zijn zoals in Fig. (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. (c). (a) COPIE M UITLENING N M LID N (b) COPIE M UITLENING LID COPIE (c) LID M UITLENING Fig.. Cardinaliteiten in het ER-schema en het bestaansafhankelijkheidsschema 3

14 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. 2 toont twee ER-schema s die aanleiding geven tot hetzelfde bestaans - afhankelijkheidsschema (Fig. 2(c)). In Fig. 2(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. 2(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. KLANT (a) RESER VATIE KAMER TYPE KLANT (b) RESERVATIE KAMER TYPE KLANT (c) KAMER TYPE RESERVATIE Fig. 2. 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 ( op of 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. 3 4

15 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 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. 3 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 op relatie. Doet men dit niet, dan kan men het zwakke entiteittype niet meer onderscheiden van het sterke entiteittype 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 5

16 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 [ 3] en ACP [], terwijl message passing aanleunt bij CCS [7]. 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 S A P. 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 S A COPIE = {kopen, catalogiseren, lenen, hernieuwen, terugbrengen, verliezen, decatalogiseren} met c(copie) = {kopen} m(copie) = {catalogiseren, lenen, hernieuwen, terugbrengen, verliezen} 6

17 d(copie) = {decatalogiseren} S A UITLENING = {lenen, hernieuwen, terugbrengen, verliezen} met c(uitlening) = {lenen}, m(uitlening) = {hernieuwen} d(uitlening)= {terugbrengen, verliezen} S A LID = {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. 4 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. 4. 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. 7

18 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 5 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 000 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 8

19 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 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 [5], 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 betekent doe a of doe b, a.b betekent doe eerst a en dan b, a* betekent doe a nul, één of meerdere keren. De verzameling gebeurtenistypes wordt uitgebreid met een gebeurtenistype ' doe niets' dat wordt voorgesteld door het symbool ' '. Dit gebeurtenistype is een neutraal element voor de sequentie, 6. De notie "contract" komt nog verder aan bod in de paragraaf over volgordebeperkingen. 9

20 m.a.w. a. = a =.a. Gebruik makend van dit gebeurtenistype kan de iteratie uitgedrukt worden met behulp van de twee bewerkingen '+' en '.': a* = + a + a.a + a.a.a + a.a.a.a +... = Σ a i i IN Dit wil zeggen: doe niets of doe a één keer of doe a twee keer of... Het symbool Σ wordt ook gebruikt om een selectie uit een verzameling gebeurtenistypes uit te drukken: Σ {a, a 2,..., a n } = a + a a n 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 S A P de uitdrukking is die het gedrag van P bepaalt, ook aangeduid met S R P Voorbeeld 0 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)*. [ + (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