Business Modelling Patterns: Three-party pattern, een uitgewerkt voorbeeld

Beleidsinformatica Tijdschrift

Volume 30 Nummer 4 (2004)

Business Modelling Patterns: Three-party pattern, een uitgewerkt voorbeeld Lotte De Rore, Monique Snoeck, Guido Dedene KBC-leerstoel ‘Managing efficiency aspects of software factory systems’ K.U.Leuven, FETEW, onderzoeksgroep LIRIS {Lotte.DeRore; Monique.Snoeck; Guido.Dedene}@econ.kuleuven.be

Abstract Patterns voor software ontwikkeling zijn al een tijdje een belangrijke topic binnen de object-geörienteerde gemeenschap. Het begon allemaal eind jaren '90 met Design Patterns, maar gaandeweg werden patterns toegepast op een veel ruimer aantal aspecten van systeemontwikkeling. Een belangrijke categorie vormen de analyse- en bedrijfsmodelleringspatronen. In dit artikel wordt eerst een algemene inleiding over patterns gegeven. Daarna wordt een uitgewerkt voorbeeld van een bedrijfsmodelleringspatroon, m.n. de Three-party pattern, beschreven. Deze pattern werd voorgesteld op de EuroPLoP 2005-conferentie. Het is een domeinonafhankelijke pattern die kan toegepast worden in een situatie met drie businessobjecten, die zowel tastbare als ontastbare objecten uit de reële wereld kunnen zijn. Het probleem is om te beslissen welke associaties in het model moeten opgenomen worden en om de mogelijke interferenties tussen de verschillende associaties te vatten.

1

Inhoudsopgave 1

Inleiding patterns .............................................................................................3 1.1 Definitie ...................................................................................................3 1.2 Soorten patterns .......................................................................................3 1.3 Elementen van een pattern.......................................................................4 1.4 Anti-patterns en pattern language ............................................................6 1.5 Pattern mining en PLoP ...........................................................................7 2 Three-party pattern ..........................................................................................8 Naam........................................................................................................................8 Publiek .....................................................................................................................8 Context.....................................................................................................................8 Probleem ..................................................................................................................8 Voorbeeld.................................................................................................................8 Krachten...................................................................................................................9 Een stapsgewijze oplossing ...................................................................................10 Stap 1: Toevoeging van een ternaire relatie...........................................................12 Voorbeeld...........................................................................................................12 Probleem ............................................................................................................12 Krachten.............................................................................................................12 Oplossing ...........................................................................................................12 Gevolgen............................................................................................................13 Voorbeeld opgelost ............................................................................................13 Stap 2: Beheer van historiek, evolutie en levenscyclus van de associaties. ..........14 Probleem ............................................................................................................14 Voorbeeld...........................................................................................................14 Krachten.............................................................................................................15 Oplossing ...........................................................................................................15 Gevolgen............................................................................................................16 Voorbeeld opgelost ............................................................................................17 Stap 3: Three-party pattern ....................................................................................19 Context...............................................................................................................19 Voorbeeld...........................................................................................................19 Probleem ............................................................................................................19 Krachten.............................................................................................................20 Oplossing ...........................................................................................................20 Gevolgen............................................................................................................21 Voorbeeld opgelost ............................................................................................21 Samenvatting .........................................................................................................23 Variaties .................................................................................................................24 Uitbreidingen .........................................................................................................26 Conclusie ...............................................................................................................27 Gerelateerde Patterns .............................................................................................27 3 Dankwoord.....................................................................................................28 4 Referenties .....................................................................................................28

2

1 1.1

Inleiding patterns Definitie “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over without ever doing it the same way twice.”

Deze woorden van architect Christopher Alexander [3] waren de aanleiding voor het gebruik van steeds terugkerende patterns in de ontwikkeling van software. Coad [3] stelt vast dat patronen in een breed gamma aan disciplines een belangrijke rol spelen: architectuur, muziek, literatuur, psychologie, archeologie, productie, luchtvaart, numismatiek, het spelen van schaak. Al deze disciplines hebben met elkaar gemeen dat ze voor hun patronen kleine eenheden standaardiseren tot grotere betekenisvolle componenten. Om patronen te ontdekken moeten we op zoek gaan naar de dingen die herhaaldelijk voorkomen. Wanneer we een patroon ontdekt hebben, moeten we denken in termen van deze nieuwe bouwsteen in zijn geheel en niet in termen van de kleinere deeltjes die ze bevatten. Een iets algemenere definitie van een pattern wordt gegeven door Dirk Riehle en Heinz Zullighoven [5]: ‘A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts.’ Waarom zijn patterns nu zo bruikbaar? Ze helpen ons vooral door problemen op te lossen uit de ‘reële wereld’. Ze omvatten de domeinkennis en documenteren design beslissingen en grondgedachten. Ze hergebruiken de wijsheid en ervaring van meesters uit het vakgebied en dragen zo de inzichten van de experts over naar de nieuwelingen. Ze leveren een vocabulaire dat kan gebruikt worden bij een probleemoplossende discussie. Tenslotte leveren ze niet enkel een oplossing, maar ook een context (waar en wanneer kan de pattern gebruikt worden), de krachten (trade-offs tussen de alternatieven, de buitenbeentjes, de doelstellingen en beperkingen) en de ontleding van de oplossing ( hoe en waarom brengt de oplossing de krachten in evenwicht). 1.2 Soorten patterns Er bestaan verschillende soorten patterns. In [5] wordt een onderscheid gemaakt volgens de fases in het ontwikkelproces: analyse, design en implementatie. Zo kan men de patterns als volgt opsplitsen: conceptuele of analyse-patterns, designpatterns en codepatterns.

3

Om iets zinvols te ontwerpen, is er nood aan een conceptueel model van het applicatiedomein van het te ontwikkelen systeem. Zo’n model van het applicatiedomein moet niet zozeer formeel zijn, maar wel begrijpbaar voor alle betrokken partijen. Meestal bestaat het uit een set van gerelateerde deelbeschrijvingen gebaseerd op de concepten en vigerende regels van het applicatiedomein, en hierbij de verschillende visies van de verschillende groepen betrokken in het ontwikkelproces omvattend. Een conceptuele pattern of analysepattern kan dus gedefinieerd worden als een pattern waarvan de vorm beschreven wordt met behulp van de voorwaarden en concepten uit het applicatiedomein. Wanneer we de activiteiten verbonden met de designfase bekijken, hebben we een model nodig dat gerelateerd is aan het conceptueel model van het applicatiedomein maar waarbij rekening gehouden wordt met de formele beperkingen van het software systeem. Een designpattern kan dus gedefinieerd worden als een pattern waarvan de vorm beschreven wordt met behulp van software design constructies zoals objecten, klassen, overerving, aggregatie en use-relaties. Bij het bouwen van het software systeem, brengen we het applicatiedomein samen met het software designmodel. Dit resulteert in een systeem implementatie, het derde relevante model. Programmeertalen leveren de notatie voor dit model. Een codepattern kan dus gedefinieerd worden als een pattern waarvan de vorm wordt beschreven met behulp van programmeertaalconstructies. 1.3 Elementen van een pattern Het beschrijven van een pattern kan op verschillende manieren gebeuren. Maar de volgende essentiële elementen moeten bij elke vorm duidelijk herkenbaar zijn bij het lezen van de pattern [1]: Naam Een pattern moet een zinvolle naam hebben. Dit laat ons immers toe om met één enkel woord of een korte zin te refereren naar de pattern en daarmee verbonden de kennis en de structuur die deze omschrijft. Soms kan een pattern meerdere vaak gebruikte of herkenbare namen hebben in de literatuur. In dat geval is het gebruikelijk om deze synoniemen of bijnamen te documenteren onder het element: ‘aliassen’ of ‘ook gekend als’. Probleem Een uiteenzetting van het probleem, met name het bereiken van de doelstellingen binnen de gegeven context en krachten. Vaak zijn deze krachten tegengesteld aan de objectieven als ook onderling.

4

Context De precondities of randvoorwaarden waaronder het probleem en zijn oplossing schijnen terug te komen en waarmee de oplossing moet rekening houden. Dit vertelt ons de toepasbaarheid van de pattern. Het kan gezien worden als de initiële configuratie van het systeem alvorens de pattern wordt toegepast. Krachten Een beschrijving van de relevante krachten en beperkingen als ook hoe ze op elkaar inwerken en hoe ze in conflict staan met elkaar en met de doelstellingen die we wensen te bereiken (mogelijks met een indicatie van hun prioriteiten). Vaak wordt ook een concreet scenario als de motivatie voor de pattern aangewend. Krachten onthullen de gecompliceerdheid van het probleem en definiëren door de spanning of onverenigbaarheid die ze creëren een soort van trade-offs waarover moet nagedacht worden. Een goede patternbeschrijving zou alle krachten die een impact hebben volledig moeten omvatten. Oplossing Statische relaties en dynamische regels beschrijven hoe de gewenste uitkomst gerealiseerd kan worden. Dit is vaak equivalent met het geven van instructies die beschrijven hoe de nodige werkproducten moeten geconstrueerd worden. De beschrijving mag tekeningen, diagrammen en tekst bevatten die de structuur van de pattern, de deelnemers, en hun samenwerking identificeert om te tonen hoe het probleem wordt opgelost. De oplossing zou niet enkel de statische structuur, maar ook het dynamische gedrag moeten beschrijven. De statische structuur vertelt ons de vorm en de organisatie van de pattern, maar vaak is het de gedragsdynamiek die de pattern ‘tot leven’ brengt. De beschrijving van de oplossing van de pattern kan ook richtlijnen aangeven die in gedachten moeten gehouden worden (zowel als valkuilen die vermeden moeten worden) bij de concrete implementatie van de oplossing. Soms worden ook mogelijke varianten of specialisaties van de oplossing beschreven. Voorbeelden Een of meerdere voorbeeldtoepassingen van de pattern illustreren de specifieke initiële context, hoe de pattern toegepast wordt op die context en tenslotte de resulterende context. Voorbeelden helpen de lezer om het gebruik en de toepasbaarheid van de pattern te begrijpen. Visuele voorbeelden en analogieën kunnen vaak zeer verhelderend zijn. Aan het voorbeeld kan ook een implementatie toegevoegd worden om te tonen hoe de oplossing gerealiseerd kan worden. Eenvoudig te begrijpen voorbeelden van gekende systemen krijgen de voorkeur. Resulterende context De staat of configuratie van het systeem nadat de pattern is toegepast, zoals ook de gevolgen (goede en slechte) van het toepassen van de pattern en andere

5

problemen of patterns die kunnen voortkomen uit deze nieuwe context. Hierin worden dus de postcondities en de neveneffecten van de pattern beschreven. Dit wordt vaak de oplossing van de krachten genoemd omdat het beschrijft welke krachten opgelost zijn en welke onopgelost blijven alsook welke patterns er nu toepasbaar kunnen zijn. Het documenteren van deze resulterende context helpt om de pattern te correleren met de initiële context van andere patterns (een pattern is vaak gewoon één stap naar het oplossen van een grotere taak in een project). Rationale Een verklaring van de stappen of regels in de pattern alsook van de pattern op zijn geheel in termen van ‘hoe’ en ‘waarom’ de krachten opgelost worden en dit in lijn met de gewenste doelstellingen, principes en filosofieën. Het vertelt ons hoe de pattern echt werkt, waarom het werkt en waarom het ‘goed’ is. De oplossingscomponent van de pattern kan de uiterlijk zichtbare structuur en gedrag van de pattern beschrijven, maar de rationale is wat inzicht levert in de diepe structuren en sleutelmechanismen onder het oppervlak van het systeem. Gerelateerde patterns De statische en dynamische relaties tussen deze pattern en andere binnen dezelfde ‘pattern language’ (zie verder) of systeem. Gerelateerde patterns delen vaak dezelfde krachten. Ook hebben ze vaak een initiële of resulterende context die compatibel is met de resulterende of initiële context van een andere pattern. Zo’n patterns kunnen voorlopers van de beschreven pattern zijn (hun applicatie leidt tot deze pattern), ze kunnen opvolgers zijn (hun applicatie volgt uit deze pattern), ze kunnen alternatieve patterns zijn die een andere oplossing beschrijven voor hetzelfde probleem maar met andere krachten en beperkingen of ze kunnen afhankelijke patterns zijn die simultaan met deze pattern kunnen (of moeten) toegepast worden. Gekende gebruiken Beschrijft gekende voorkomens van de pattern en zijn applicatie binnen bestaande systemen. Dit helpt het valideren van de pattern door het verifiëren dat het inderdaad een bewezen oplossing is voor een terugkerend probleem. Gekende gebruiken kunnen dienen als educatieve voorbeelden. 1.4 Anti-patterns en pattern language Een pattern beschrijft een ‘best practice’. Maar er bestaat ook zoiets als een ‘lesson learned’ en dit wordt beschreven in de zogenaamde anti-pattern. Er zijn twee soorten anti-patterns: Enerzijds deze die een slechte oplossing beschrijven voor een probleem wat dus resulteerde in een slechte situatie. En anderzijds deze die beschrijven hoe je uit een slechte situatie kan komen en hoe van daaruit gewerkt kan worden naar een goede oplossing. Deze laatste zijn de meest bruikbare anti-patterns.

6

Wanneer men gerelateerde patterns aan elkaar weeft, vormen ze een pattern language. Als men een pattern ziet als een terugkerende oplossing voor een probleem in een context waar bepaalde krachten spelen, dan kan een pattern language gezien worden als de collectie van zo’n oplossingen die, op ieder niveau, samenwerken om een complex probleem op te lossen in overeenstemming met de vooropgestelde doelstelling. 1.5 Pattern mining en PLoP Het schrijven van goede patterns is niet eenvoudig. Patterns moeten niet enkel feiten weergeven, maar ook een verhaal vertellen dat de ervaring omvat die ze wensen over te dragen. Een pattern moet zijn gebruikers helpen om de bestaande systemen te begrijpen, systemen aan te passen aan de noden van de gebruiker en om nieuwe systemen te bouwen. Het proces van het zoeken naar patterns om deze te documenteren wordt pattern-mining genoemd. De beste manier om bruikbare patterns te leren herkennen en documenteren is door het leren van anderen die het reeds goed gedaan hebben. PLoP (Pattern Languages of Programming)-conferenties zijn een mogelijkheid voor auteurs van patterns om hun werk kritisch te laten beoordelen door andere auteurs. Alvorens een paper (pattern) toegelaten wordt tot de conferentie, gebeurt een proces van ‘shepherding’, iedere paper krijgt een niet-anonieme herder toegewezen die overlegt met de auteur hoe de pattern verder uitgeklaard of verbeterd kan worden. Op de conferentie zelf wordt in plaats van presentaties te geven, writer’s workshops georganiseerd. Deze workshops zijn een soort open forum waar alle aanwezigen de voorgestelde pattern proberen te verbeteren door te discussiëren over wat ze goed vonden aan de pattern als ook over de plaatsen waar tekort geschoten werd. Deze feedback laat de deelnemers toe om hun patterns te verbeteren en deze bruikbaarder en beter geschikt voor publicatie te maken. In wat volgt, wordt een pattern beschreven die werd voorgesteld op de EuroPLoP 2005-conferentie en verder verbeterd en gepolijst werd aan de hand van de feedback van de writer's workshop. Het is een domeinonafhankelijke pattern die kan toegepast worden in een situatie met drie businessobjecten, die zowel tastbare als ontastbare objecten uit de reële wereld kunnen zijn. De drie businessobjecten zijn met elkaar verbonden door drie binaire associaties. Het probleem is om te beslissen welke associaties in het model moeten opgenomen worden en om de mogelijke interferenties tussen de verschillende associaties te vatten.

7

2

Three-party pattern

Naam Three-party pattern.

Publiek Business architecten, domein modelmakers, systeem analisten.

Context Stel drie businessobjecten die zowel tastbare als ontastbare objecten uit de reële wereld kunnen zijn. Deze entiteiten zijn met elkaar verbonden door drie meer-opmeer binaire associaties. Voorbeelden van zo’n drie gerelateerde entiteiten zijn: [‘project’, ‘onderdeel’, ‘leverancier’], [‘werknemer’, ‘project’, ‘afdeling’] of [‘persoon’, ‘taak’, ‘tool/middel’] (zie Figuur 1). Object 1

*

*

Object 2

*

*

Object 3

*

* Figuur 1: context

De binaire associaties kunnen feitelijke relaties tussen twee van de basisobjecten voorstellen (vb. ‘speler’ is een deel van ‘team’), de historiek en de duurtijd van de relatie bijhouden (vb. ‘werknemer’ werd toegewezen aan ‘afdeling’) of de toegestane relaties bijhouden (vb. ‘tool’ kan gebruikt worden voor ‘taak’, ‘onderdeel’ kan geleverd worden door ‘leverancier’, ‘werknemer’ is bekwaam voor ‘taak’, ‘werknemer’ is toegelaten voor ‘taak’). Elk van de drie businessobjecten heeft mogelijkerwijs een levenscyclus gedurende de welke de businessobjecten evolueren over een aantal statussen. De status waarin een businessobject zich bevindt, bepaalt de instanties van de associatie die kunnen gecreëerd, aangepast of verwijderd worden.

Probleem Hoe kan je beslissen welke associaties in het model moeten opgenomen worden? En hoe kan je de mogelijke interferenties tussen de verschillende associaties in rekening brengen?

Voorbeeld Neem als voorbeeld een transportbedrijf. Een dergelijk bedrijf bestaat uit verschillende afdelingen (nationaal transport, eurozone transport, overzees transport). Elke afdeling beschikt over een aantal arbeiders. Het werk van de arbeiders is samengesteld uit een aantal standaardactiviteiten (taken), bijvoorbeeld

8

pallet handling, order picking, …. Elke standaardactiviteit kan in meerdere afdelingen, door één of meerdere arbeiders uitgevoerd worden. Alvorens een arbeider een standaardactiviteit kan uitvoeren, moet hij/zij hierin opgeleid worden. Er zijn dus drie businessobjecten: ‘afdeling’, ‘arbeider’ en ‘taak’. De veel op veel binaire associatie tussen ‘afdeling’ en ‘arbeider’ vertelt welke arbeider tot welke afdeling behoort. Een arbeider kan tot meerdere afdelingen behoren (bv. telkens voor een bepaald percentage). De associatie tussen ‘arbeider’ en ‘taak’ vertelt welke taken een arbeider kan uitvoeren, voor welke taken een arbeider is opgeleid. De associatie tussen ‘taak’ en ‘afdeling’ vertelt welke afdelingen verantwoordelijk zijn voor welke taken. Dus de meer-op-meer binaire associaties drukken beschikbaarheid, verantwoordelijkheid en capaciteit uit (zie Figuur 2). arbeider

*

*

*

afdeling

beschikbaarheid

*

*

verantwoordelijkheid

taak

*

capaciteit

Figuur 2: context voorbeeld

Het bedrijf wenst de prestaties van haar arbeiders te registreren teneinde per afdeling productiviteits- en kostenanalyses uit te voeren. Aangezien een arbeider tot meerdere afdelingen kan behoren, is het in het kader van de productiviteits- en kostenanalyses van belang deze afdelingen mee in de registratie op te nemen. Het is immers verkeerd om kosten van een taakuitvoering toe te kennen aan alle afdelingen waartoe een arbeider die de taak uitvoerde behoort. Voor de productiviteitsanalyse is het ook verkeerd om de som van alle gepresteerde uren van alle arbeiders van een afdeling te nemen. Een arbeider zou immers ook uren kunnen presteren voor een andere afdeling dan diegene waartoe hij/zij behoort.

Krachten De voornaamste kracht die in deze pattern speelt, is de kwaliteit van het conceptueel modelleren. Volgens Lindland & Sindre [4] kan deze ‘conceptual modeling quality’ opgesplitst worden in syntactische kwaliteit, semantische kwaliteit en pragmatische kwaliteit. Syntactische kwaliteit houdt verband met de modelleertaal, UML in dit geval. Semantische kwaliteit verbindt het model met het domein door niet enkel de syntaxis te bekijken, maar ook de relaties tussen de statements en hun betekenis. Pragmatische kwaliteit tenslotte verbindt het model met de deelname van het publiek door niet alleen de syntaxis en de semantiek te bekijken, maar ook hoe het publiek (iedereen die betrokken is in het modelleren) het zal interpreteren. Bij deze pattern ligt de focus vooral op de semantische kwaliteit. In [4] wordt semantische kwaliteit opgesplitst in de volgende minder abstracte attributen:

9

-

volledigheid: het model bevat alle statements over het domein die correct en relevant zijn consistentie: het model bevat geen contradicties in de statements semantische correctheid: ieder statement gemaakt door het model is waar in de reële wereld.

Bijkomend kunnen ook volgende krachten beschouwd worden: - minimaliteit of eenvoud: hoewel het model volledig moet zijn, mag het toch niet meer klassen en associaties bevatten dan echt nodig. In het bijzonder moeten overbodige associaties tussen klassen vermeden worden omdat deze de consistentie van het model in gevaar kunnen brengen. - Instance-manipulatie (invoegen, wijzigen en verwijderen van klassen en associatie instanties): wanneer een instantie van een klasse of associatie toegevoegd, gewijzigd of verwijderd wordt, moet het model de nodige informatie leveren om deze instance-manipulaties te valideren.

Een stapsgewijze oplossing De oplossing voor dit probleem om de drie veel op veel binaire associaties tussen de drie businessobjecten te modelleren wordt op een stapsgewijze manier voorgesteld. In de opeenvolgende stappen, startend van de initiële context, zullen de verschillende krachten ons leiden naar de uiteindelijke oplossing (zie Figuur 3). Iedere stap wordt op een pattern-manier uitgewerkt, maar is geen op zichzelf staande pattern.

10

Context Volledigheid, Eenvoud stap1: Toevoeging van ternaire relatie Volledigheid Correctheid stap2: Association Objects Pattern Consistentie Beheersbaarheid Eenvoud stap3: Threeparty pattern

Figuur 3: stapsgewijze oplossing

11

Stap 1: Toevoeging van een ternaire relatie Voorbeeld Onderstel het transportbedrijf. Het model bestaat uit drie businessobjecten: ‘arbeider’, ‘afdeling’ en ‘taak’ met de binaire relaties als hoger omschreven. Wanneer Jan de capaciteit bezit om meerdere taken uit te voeren, zoals pallet handling en order picking en wanneer Jan behoort tot verschillende afdelingen, afdeling Nationaal Transport en afdeling Eurozone Transport (verder afgekort als "NT" en "ET", en wanneer in beide afdelingen, zowel NT als ET, beide taken kunnen uitgevoerd worden, dan vertellen de drie individuele associaties niet welke taak, pallet handling of order picking, door Jan werd uitgevoerd voor afdeling NT. Probleem Stel drie businessobjecten. Je wenst de relaties tussen deze drie objecten vast te leggen. De binaire associatie tussen ieder paar van businessobjecten geeft je verschillende views op de beschikbare informatie. Maar zelfs de combinatie van deze partiële informatie omvat niet alle informatie die je nodig hebt. Krachten De voornaamste kracht die hier speelt is de volledigheid van het conceptuele model: niet al de statements uit de reële wereld zijn momenteel vervat in het model met enkel de drie binaire associaties. Wanneer je meer relaties toevoegt om deze informatie toch te omvatten, ontstaat er een trade-off tussen volledigheid, eenvoud en consistentie. - Omwille van minimaliteit of eenvoud wensen we het model zo eenvoudig mogelijk te houden. - Een model met slechts 3 deelnemers kan snel overladen worden met relaties, wat redundantie- en inconsistentieproblemen veroorzaakt. - Aan de andere kant, moeten omwille van de volledigheid alle statements over de reële wereld vervat zijn in het model. De binaire associaties vervangen zou kunnen leiden tot een onvolledig model. Bijkomend moet het model ook consistent blijven wanneer het gewijzigd of uitgebreid wordt. Oplossing Om de nodige informatie te vervatten, voeg een ternaire associatie toe die de drie businessobjecten met elkaar verbindt. Om de informatie consistent te houden op ieder moment in de tijd, is het nodig dat de binaire associaties die de businessobjecten twee per twee met elkaar verbinden behouden blijven (zie Figuur 4). Deze definiëren immers de geldige instanties van

12

de ternaire associatie. De instanties van de binaire associaties kunnen gebruikt worden ter validatie bij het creëren van instanties van de ternaire associatie. *

Object 1

*

*

Object 2

*

*

*

* *

Object 3

*

Figuur 4: ternaire relatie pattern

Gevolgen De ternaire relatie levert de nodige informatie terwijl de binaire relaties zorgen voor de validatie bij het invoegen van een instantie van de ternaire relatie. Voor iedere instantie van de ternaire relatie moet er een binaire relatie bestaan tussen ieder paar van de instanties van de objecten. Voorbeeld opgelost Het drietal (afdeling: NT, taak: pallet handling, arbeider: Jan) geeft weer welke taak door welke arbeider onder welke afdeling werd uitgevoerd. Dit drietal is enkel geldig wanneer arbeider Jan opgeleid is voor de taak pallet handling, in afdeling NT de taak pallet handling kan uitgevoerd worden en arbeider Jan behoort tot afdeling NT. Alvorens dit drietal te creëren, kan men verifiëren of (afdeling: NT, arbeider: Jan) een bestaande/geldige instantie is van de associatie tussen ‘afdeling’ en ‘arbeider’, of (afdeling: NT, taak: pallet handling) een bestaande/geldige instantie is van de associatie tussen ‘afdeling’ en ‘taak’ en of (arbeider: Jan, taak: pallet handling) een bestaande/geldige instantie is van de associatie tussen ‘arbeider’ en ‘taak’.

13

Stap 2: Beheer van historiek, evolutie en levenscyclus van de associaties. Probleem Op het einde van stap 1 bevat ons model de drie businessobjecten, drie binaire associaties en een ternaire associatie. Iedere instantie van een associatie stelt een link tussen twee of drie businessobjecten voor. Deze instanties kunnen wel wijzigen over de tijd heen en de historiek van iedere associatie kan in sommige gevallen als waardevolle informatie beschouwd worden. Meer nog, de aard of de cardinaliteit van de relatie kan veranderen wanneer deze wordt bekeken over de tijd heen in plaats van op één bepaald punt in de tijd. Tenslotte zijn associaties een soort van ontastbare objecten die eigen gedrag kunnen hebben dat niet kan gemodelleerd worden als deel van de levenscyclus van de businessobjecten en dat ook niet kan opgenomen worden in het concept van de associatie zelf. Samengevat, de associaties geven waardevolle informatie, maar dit slechts als een momentopname. Hoe kan het model in staat gesteld worden om de bijkomende behoeften voor historiek, evolutie over de tijd en levenscyclusinformatie voor associaties te ondersteunen? Voorbeeld Veronderstel het model van het transportbedrijf met de drie businessobjecten ‘afdeling’, ‘arbeider’ en ‘taak’ die verbonden zijn door een ternaire associatie en twee-aan-twee met drie binaire associaties zoals hierboven beschreven. Wanneer je de huidige staat van een associatie bekijkt, is die associatie vaak erg eenvoudig: vb. een afdeling beschikt over arbeiders, taken kunnen uigevoerd worden in een afdeling en een arbeider is opgeleid voor taken. Over de tijd heen echter, kan een arbeider die beschikbaar was voor een bepaalde afdeling niet langer voor deze afdeling ter beschikking staan. En een arbeider die gecertificeerd is voor een bepaalde taak, kan na verloop van tijd mogelijkerwijs zijn certificaat verliezen om deze taak uit te voeren. Stel, als ander voorbeeld, dat iedere arbeider op een bepaald punt in de tijd slechts tot één afdeling kan behoren. Over de tijd heen, kan deze afdeling veranderen en dus behoort een arbeider dan tot meerdere afdelingen. Tenslotte, het toekennen van een arbeider aan een taak in opdracht van een afdeling kan een volledig proces doorlopen resulterend in een levenscyclus met verschillende opeenvolgende staten: gepland, uitgevoerd, gefactureerd. De staat van deze toekenning van een arbeider aan een taak in opdracht van een afdeling kan niet gemodelleerd worden als een staat in de levenscyclus van de individuele afdeling, arbeider of taak. Analoog heeft de ‘arbeider-taak’ relatie ook een levenscyclus: een arbeider kan tijdelijk niet in staat zijn om een bepaalde taak uit te voeren. Deze onbekwaamheid is noch een eigenschap van de arbeider noch van de taak. Het is een eigenschap van de associatie tussen ‘arbeider’ en ‘taak’.

14

Krachten Volledigheid en correctheid zijn hier de voornaamste krachten: - Historiek: Als een relatie verandert, bijvoorbeeld een arbeider verandert van afdeling, dan verlies je de informatie over de vorige afdeling. Omwille van volledigheid van het model, zou je de historiek willen bijhouden. Analoog, als je wenst te controleren of een arbeider bekwaam was voor een taak op een bepaald punt in de tijd, maar die relatie is ondertussen al gewijzigd of zelfs verdwenen, dan zal het model de verkeerde informatie leveren. Ook hier kan het bijhouden van historiek een oplossing bieden. - Levenscyclus van de associatie: Omwille van de volledigheid van het model, zou je de associatie extra attributen willen meegeven die toelaten om de staat waarin de associatie zich bevindt bij te houden (zoals bv. gepland, uitgevoerd, gefactureerd, betaald). - Wijzigen van de aard van de associatie attributen en correctheid van het model: Als een associatie-uiteinde een cardinaliteit van 1 heeft op een bepaald punt in de tijd, kan deze cardinaliteit veel worden wanneer je beslist om de historiek van de associaties bij te houden. Dan stelt zich het probleem dat je toch moet kunnen verzekeren dat er op één bepaald punt in de tijd slechts één actieve instantie van de associatie kan zijn. Oplossing De sleutel tot de oplossing is dat het omvormen van de associaties tot objecten en het bijhouden van datum-attributen toelaat een onderscheid te maken tussen actieve, historische en geplande instanties van de associaties. Als de einddatum in het verleden ligt, dan is de instantie van de associatie historisch. Als de begindatum in het verleden ligt en de einddatum in de toekomst, dan is de instantie de actieve, de huidige instantie. Ligt de begindatum in de toekomst, dan gaat het om een geplande instantie. Definieer dus eerst drie (binaire) associatieobjecten, een voor ieder van de binaire associaties, om de datum en tijd van de associaties vast te leggen. Deze binaire associatieobjecten werken elk samen met de twee businessobjecten die gerelateerd werden door de associatie. Bepaal attributen en operaties die uniek zijn aan deze associatie. De implementatie hiervan wordt beschreven in ‘ASSOCIATION PATTERN’ [2]. Vervolgens, definieer een ternair associatieobject dat de informatie, datum en tijd van de ternaire associatie vastlegt. Dit ternaire associatieobject werkt samen met de drie businessobjecten. Nu kan de historiek van de associaties bijgehouden worden (zie Figuur 5). Als er op één punt in de tijd slechts één actieve instantie mag zijn, kan dit afgedwongen worden door de einddatum van de laatste actieve instantie op een datum in het verleden te zetten telkens een nieuwe instantie toegevoegd wordt.

15

Het is ook mogelijk om de begindatum in de toekomst te plaatsen, dit wijst dan op een geplande associatie. Door een statusattribuut toe te voegen kan het associatieobject gebruikt worden voor de levenscyclus van de associatie. Het associatieobject integreert dus historiek en levenscyclussen in een object en is in staat om te gaan met de veranderende aard van de associaties terwijl het model correct gehouden wordt. Object 1

1

1

Object 2

Name Description State


Get Set

Get Set

1 1

*

*

1

Description State

*

1

Association Object 1

Object 3

1 Name

*


Begin date End date State

Get Set

1

1


*

Get Set

*

Ternary Association Object

Get Set

*

Begin date End date State Get Set

*


*

Begin date End date State Get Set

Figuur 5: Association Objects Pattern

Gevolgen • Door associatieobjecten te definiëren in plaats van associatierelaties, kan men de historiek van de associaties bijhouden. • Door een status toe te voegen aan de attributen van de associatie objecten, kan men een levenscyclus opbouwen. • Er blijft nog steeds een moeilijkheid om het geheel consistent te houden. Wanneer men de validatie voor het ternaire associatieobject wil testen, moet naar de binaire associatieobjecten gekeken worden. Deze zijn enkel indirect gelinkt met het ternaire object.

16

Voorbeeld opgelost Als de drie binaire associaties en de ternaire associatie vervangen worden door de associatieobjecten ‘arbeiderallocatie’ (tussen ‘arbeider’ en ‘afdeling), ‘taakcapaciteit’ (tussen ‘taak’ en ‘arbeider’), ‘taakverantwoordelijkheid’ (tussen ‘taak’ en ‘afdeling’) en ‘taakuitvoering’ (tussen ‘taak’, ‘arbeider’ en ‘afdeling’), dan kan je de historiek van deze associaties bijhouden (zie Figuur 6).

1

arbeider

1

taak

1

afdeling

1




Get Set

Get Set

Get Set

1 1

*

*

*

1

Taakcapaciteit

*

Taakverantwoordelijkheid


1

1

Insertion date State Get Set

Get Set

* Taakuitvoering

*

State: {ordered, cancelled, delivered, paid} Ordering date Cancellation date Delivery date Payment date

*

Get Set

*

Arbeiderallocatie

*

Begin date End date State Percentage Get Set

Figuur 6: association objects pattern (voorbeeld)

Het systeem houdt bij voor welke set van taken een arbeider bekwaam is. Deze capaciteit is het resultaat van een evaluatie voor iedere arbeider en taak en is alleen geldig vanaf de gegeven begindatum. Geen enkele taak (waarvoor deze

17

capaciteit nodig is) kan uitgevoerd worden door deze arbeider op een eerdere datum dan deze begindatum. In de status kan opgenomen worden of een arbeider al dan niet tijdelijk onbekwaam is voor een bepaalde taak. De datums in het ‘arbeiderallocatie’-object stellen ons in staat om de evolutie van de percentages dat een arbeider tewerkgesteld is in een afdeling over de tijd heen bij te houden: een instantie met een einddatum in het verleden refereert naar een vroeger percentage en een instantie met een lege einddatum refereert naar het huidige percentage dat een arbeider tewerkgesteld is in de afdeling. Per afdeling en per arbeider kan er slechts één huidig percentage-instantie van de associatie zijn. Een extra controle is dat de som van de percentages van een arbeider hoogstens 100% mag zijn op elk punt in de tijd. Het object ‘taakuitvoering’ houdt de toewijzing van arbeiders aan taken voor een bepaalde afdeling bij. Het status-attribuut en de datums laten toe om de opeenvolgende statussen in het uitvoeringsproces bij te houden.

18

Stap 3: Three-party pattern Context Veronderstel het model als hiervoor beschreven met drie businessobjecten, drie binaire associatieobjecten en een ternair associatieobject tussen de drie businessobjecten. Voorbeeld In het voorbeeld van de transportfirma, is de informatie die vervat zit in de binaire associaties sterk verbonden met de informatie in de ternaire relatie: - Indien een arbeider ingepland wordt voor een taak, moet deze arbeider bekwaam zijn voor de taak en mag hij/zij niet tijdelijk onbekwaam zijn. Alvorens de NT-afdeling Jan kan toewijzen aan een order picking-taak moet gecontroleerd worden of Jan op dat moment wel bekwaam is voor zo’n taak. - De gegevens betreffende het percentage van tewerkstelling in het ‘arbeiderallocatie’-object mag niet verwijderd worden zolang als er instanties van het ‘taakuitvoering’-object bestaan die refereren naar dat stuk van de percentagehistoriek. Veronderstel dat Jan, die fulltime te werk gesteld is bij NT, verandert naar een parttime toewijzing aan NT en een parttime toewijzing aan ET. Zolang als er informatie bestaat over taken die Jan uitvoerde tijdens zijn fulltime aanstelling, mag de informatie over Jans fulltime aanstelling bij NT niet verwijderd worden. - Arbeiders mogen niet verwijderd worden van de ‘arbeiderallocatie’-tabel indien die arbeider nog toegewezen is aan een taak door die afdeling. Indien Jan een order picking-taak moet uitvoeren in de afdeling NT, dan mag Jan niet verwijderd worden uit de afdeling NT. - Een arbeider kan enkel toegewezen worden aan een taak door een afdeling op een datum later dan de begindatum van de bekwaamheid voor deze taak door de arbeider. Capaciteitsinformatie moet bijgehouden worden zolang als er informatie over de toewijzing wordt bijgehouden. Jan kan enkel toegewezen worden aan een order picking-taak in de NT-afdeling nadat hij de opleiding voor order picking volgde. Zolang er informatie bestaat over de order picking-taken die Jan uitvoerde in de NT-afdeling, mag de informatie over de bekwaamheid van Jan voor order picking-taken in die periode niet verwijderd worden. - … Probleem Zoals hoger aangegeven, blijft het probleem dat de informatie vervat in de binaire associaties de geldige instanties van de ternaire associatie beperken, de historiek en de levenscyclus van de binaire associaties moeten consistent blijven met de historiek en levenscyclus van de ternaire associatie en omgekeerd. Zo mogen

19

bijvoorbeeld relevante delen van de historiek van de binaire associaties niet verwijderd worden zolang deze nodig zijn voor de correcte interpretatie van de informatie vervat in de ternaire associatie. Hoewel er een sterke relatie is tussen de informatie vervat in de binaire associatieobjecten en het ternaire associatieobject, zijn deze objecten enkel indirect met elkaar verbonden via de businessobjecten. Hoe kun je meer consistentie bieden zonder de flexibiliteit en de informatie die reeds vervat is in het model te verliezen? Krachten De voornaamste krachten hier zijn consistentie, beheersbaarheid en eenvoud voor de manipulatie van instanties: - consistentie en beheersbaarheid: Als de ternaire associatie samenwerkt met de drie businessobjecten, dan heeft het ternaire associatieobject geen directe toegang tot de informatie die de geldigheid van zijn instanties beperkt. Een directe link tussen de binaire en ternaire associatieobjecten zou het beheren van de consistentie vereenvoudigen. - Eenvoud om instantie in te voegen, te verwijderen of te wijzigen: Een directe link zou bijvoorbeeld referentiële integriteitcontroles tussen de instanties van de ternaire associatie en de relevante instantie van de binaire associaties mogelijk maken. Ook de validatie van statuswijzigingen en het invoegen van nieuwe instanties zou eenvoudiger worden. Nu is er meer complexe code nodig voor het valideren van de creatie of de evolutie van instanties van de ternaire associatie. - Aan de andere kant zou het toevoegen van meer associaties bovenop het huidige model de complexiteit van het model zichtbaar verhogen, met het risico om het gehele model onbeheersbaar te maken. - De krachten eenvoud en minimaliteit verplichten ons om zo weinig mogelijk associaties en objecten te gebruiken, terwijl het model volledig en consistent blijft. Oplossing Eerder dan additionele associaties toe te voegen, zullen de bestaande relaties tussen alle objecten gereorganiseerd worden. In plaats van het ternaire associatieobject te laten samenwerken met de businessobjecten op een directe manier, moet het samenwerken met ieder van de drie binaire associatieobjecten, zoals aangegeven in onderstaan diagram, Figuur 7.

20

1

Object 1

1

Name Description State Get set

* Association object 1

1

*


* *

Ternary association object

*

Association object 2 Begin date End date State


Get set

1

Get set

Get set

*

* 1

1 Object 2 Name Description state Get set

1

*

Association object 3

1

*

Begin date End date state

1

Object 3 Name Description state Get set

Get set

Figuur 7: Three-party pattern

Gevolgen Omdat het ternaire associatieobject direct gelinkt is aan de drie binaire associatieobjecten, is het eenvoudiger om de historiek bij te houden en om het model consistent te houden. Ook de beheersbaarheid van het model is gestegen, het invoegen van instanties is vereenvoudigd. Door de bestaande relaties te reorganiseren in plaats van relaties toe te voegen, blijft de complexiteit van het model hetzelfde. Een negatief gevolg is dat het ingewikkelder is om de hoofdobjecten te benaderen vanuit de ternaire relatie. Het model werkt dus enkel goed wanneer er nood is om veel van de historiek van de relaties bij te houden of waneer de meeste use-cases historiek-georiënteerd zijn. Voorbeeld opgelost Doordat het ternaire associatieobject ‘taakuitvoering’ samenwerkt met de drie binaire associatieobjecten ‘arbeiderallocatie’, ‘taak capaciteit’ en ‘taak verantwoordelijkheid’, is het eenvoudiger te controleren of een instantie kan ingevoegd, gewijzigd of verwijderd worden. Bijvoorbeeld:

21

-

-

Als de afdeling NT een order picking-taak voor Jan wil inplannen (creëren van een instantie van ‘taakuitvoering’), kan je via de directe link tussen ‘taakuitvoering’ en ‘taak capaciteit’ controleren of Jan bekwaam is tot een order picking-taak. Als je het percentage dat Jan toegekend is aan afdeling NT wilt wijzigen (wijzigen van instantie van ‘arbeiderallocatie’), dan kan er eenvoudig gecontroleerd worden via de directe link tussen ‘arbeiderallocatie’ en ‘taakuitvoering’ of er nog informatie bestaat over de taken die Jan uitvoerde tijdens de vorige periode van het oude percentage.

1

1

afdeling Name Description State Get set

* Arbeiderallocatie

1

*

Begin date End date State Percentage

Taak uitvoering

* *

1


State: {planned, executed, invoiced} assignment date execution date invoicing date cancellation date

Get set

*


Get set

*

Get set

* 1 arbeider Name Description state Get set

1 1

*

Taak capaciteit

1

*

Begin date End date state

1

taak Name Description state Get set

Get set

Figuur 8: Three-party pattern (voorbeeld)

22

Samenvatting Het uiteindelijke model heeft nu de volgende deelnemers en verantwoordelijkheden: • 3 Businessobjecten: o Verantwoordelijk voor het beheren van de informatie en de levenscyclus van de Businessobjecten •

3 binaire associatieobjecten: o Verantwoordelijk voor het beheren van de feitelijke relaties tussen twee van de businessobjecten o Bijhouden van historiek en de duur van de binaire relatie o Bijhouden van informatie over toegestane ternaire links o Bijhouden van levenscyclus (status) informatie van de binaire associaties o Verzekeren dat het overgaan van associatie-instanties van de ene toestand in de andere gevalideerd wordt tegenover de levenscyclusstatus van de deelnemende businessobjecten

•

Ternair associatieobject: o Verantwoordelijk voor het beheren de feitelijke relaties waar de drie businessobjecten samenwerken o Bijhouden van historiek en de duur van de ternaire relatie o Bijhouden van de levenscyclus (status) informatie van de ternaire relatie o Samenwerken met de drie binaire associatieobjecten om de bestaande feitelijke relaties en toegestane relaties tussen twee partijen in rekening te brengen om het toevoegen, wijzigen en verwijderen van instanties te valideren. o Verzekeren dat de overgang van de ene staat naar de andere van de instanties van de ternaire associatie gevalideerd is tegenover de levenscyclus status van de deelnemende instanties van de binaire associaties.

23

Variaties Wanneer de pattern wordt toegepast op een bepaalde situatie, dan moeten de drie businessobjecten gemapt worden op de objecten uit het domein dat beschouwd wordt. Een mogelijke variatie is het feit of een binaire associatie al dan niet een beperking oplegt op de toegestane instanties van de ternaire associatie. Veronderstel de situatie van [arbeider, afdeling, taak] zoals in Figuur 9 en veronderstel dat de afdeling die verantwoordelijk is voor de taak niet dezelfde moet zijn als de afdeling waartoe de arbeider die de taak uitvoert behoort, dan legt de binaire associatie tussen arbeider en afdeling ‘arbeider allocatie’ geen beperkingen op de ternaire associatie. In dat geval blijven de drie binaire associaties behouden, maar zijn er slechts twee van hen die beperkend optreden naar de ternaire associatie toe: ___: Wanneer een taak wordt uitgevoerd, dan is de afdeling waartoe de arbeider behoort die de taak uitvoerde al of niet gelijk aan de afdeling die verantwoordelijk is voor de taak. …: Wanneer een taak uitgevoerd wordt, dan moet de taak uit ‘taakverantwoordelijkheid’ overeenstemmen met de taak uit ‘taak capaciteit’. ---: Wanneer een taak uitgevoerd wordt, dan moet de arbeider die tot die afdeling behoort ook capabel zijn om deze taak uit te voeren. 1

Arbeider allocatie

*

1

*

arbeider

Taak uitvoering

*

*

1


*

* 1

afdeling 1

*

1 1

*

Taak capaciteit

*

1

1 taak

Figuur 9: variatiemogelijkheid 1

Een ander mogelijk variatiepunt is wanneer de binaire relatie tussen twee van de objecten (twee hoofdobjecten of een hoofdobject en een associatieobject) verdubbeld wordt. Je kan bijvoorbeeld twee verschillende relaties hebben tussen

24

‘afdeling’ en ‘arbeider’, de relatie wanneer een arbeider behoort tot een afdeling en de relatie wanneer een arbeider aan het hoofd staat van die afdeling (zie Figuur 10). afdeling 1

1 1 1

Hoofd afdeling

*

Arbeider allocatie

*

1

Taak uitvoering

*

*


*

* 1

*

1

*

1

1

1

arbeider

*

Taak capaciteit

1

1

*

taak


Er kan ook een verdubbeling zijn van de relatie tussen een hoofdobject en een associatieobject. Beschouw bijvoorbeeld de volgende situatie [speler, team, wedstrijddag] zoals in Figuur 11. Men kan zien dat de binaire associatie tussen ‘team’ en ‘match’ verdubbeld is aangezien er twee teams betrokken zijn bij een match, namelijk de thuisspelers en de bezoekers. 1

1

team

1

thuisspelers

bezoekers

*

contract

1

* 1 speler

*

*

*

*

*

registratie

match

1

*

1 1

*

opstelling

*


25

1

1 wedstrijddag

Uitbreidingen Deze pattern kan uitgebreid worden wanneer we ook de context bekijken waarin één of meerdere van de binaire relaties tussen de drie hoofdobjecten wegvallen of wanneer een van de binaire associaties samengenomen wordt met de hoofdentiteit. Onderstel de situatie van een alumnusvereniging, [alumnus, groep, activiteit] (zie Figuur 12). Er zijn twee soorten lidmaatschap met verschillende eigenschappen: bestuursleden en gewone alumnusleden. We krijgen dus twee associatieobjecten tussen ‘groep’ en ‘alumnus’. We zien dat er geen binaire relatie bestaat tussen ‘activiteit’ en ‘alumnus’. Iedere groep organiseert zijn eigen activiteiten, zoals aangegeven in Figuur 12 is er een 1 op 1 mapping tussen groepsactiviteit en activiteit. Het binaire associatie object kan dus worden samengenomen met het basis businessobject, zie Figuur 13.

1

1

groep

1

* bestuurslid

*

* lid

1

*

registratie

*

1

*

1

* groepsactiviteit

1

1

1

activiteit

alumnus

Figuur 12: uitbreidingsmogelijkheid

26

1

groep

1

1

* bestuurslid

*

* lid

1

*

registratie

*

1

* activiteit

*

1

1

alumnus

Figuur 13: uitbreidingsmogelijkheid

Conclusie De kunst van het conceptueel modelleren is niet eenvoudig. Een conceptueel model moet alle relevante statements uit het vakgebied op een correcte manier vervatten, gebruik makend van een minimum aan constructies. Ter zelfde tijd, moet zijn pragmatische kwaliteit behouden worden daar het vaak gebruikt wordt als instrument voor het communiceren met de eindgebruiker. De Three-party pattern komt tegemoet aan deze kwaliteitsdoelstelling door de basis businessobjecten, de binaire en het ternaire associatieobjecten op een zodanige manier te schikken dat de interacties tussen de historiek en de levenscyclus van al deze objecten eenvoudiger beheerd kan worden.

Gerelateerde Patterns Lorraine L. Boyd’s Business Pattern of Association Objects [2]

27

3

Dankwoord

Veel dank aan Jeroen Geleyn die deze pattern valideerde tegenover verschillende cases uit het echte leven in de context van zijn thesisverhandeling. Ook aan Klaus Marquardt en Dietmar Schütz die als ‘herder’ deze pattern begeleid hebben van een ruw idee naar zijn huidige vorm. Deze paper is geschreven als een deel van het ‘KBC-leerstoel’-project over ‘Managing efficiency aspects of software factory systems’ gesponsord door KBCbank en verzekeringen.

4 [1] [2] [3] [4] [5]

Referenties B. Appleton: Patterns and Software: Essential Concepts and Terminology (2000) LL. Boyd: Business Patterns of Association Objects. Pattern Languages of Program Design 3, Chapter 23 (1998) P. Coad: Object-Oriented Patterns. Communications of the ACM, September 1992, Vol. 35, No 9 O.I.Lindland, G. Sindre, A. Solvberg: Understanding Quality in Conceptual Modeling. IEEE (March 1994) D. Riehle, H. Zullighoven: Understanding and Using Patterns in Software Development. Theory and practice of Object Systems 2,1 Wiley & Sons (1996)

28

Business Modelling Patterns: Three-party pattern, een uitgewerkt voorbeeld

Recommend Documents