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

Maat: px
Weergave met pagina beginnen:

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

Transcriptie

1 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; 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.

2 Inhoudsopgave Inleiding patterns...3. Definitie Soorten patterns Elementen van een pattern Anti-patterns en pattern language Pattern mining en PLoP Three-party pattern...8 Naam...8 Publiek...8 Context...8 Probleem...8 Voorbeeld...8 Krachten...9 Een stapsgewijze oplossing...0 Stap : Toevoeging van een ternaire relatie...2 Voorbeeld...2 Probleem...2 Krachten...2 Oplossing...2 Gevolgen...3 Voorbeeld opgelost...3 Stap 2: Beheer van historiek, evolutie en levenscyclus van de associaties....4 Probleem...4 Voorbeeld...4 Krachten...5 Oplossing...5 Gevolgen...6 Voorbeeld opgelost...7 Stap 3: Three-party pattern...9 Context...9 Voorbeeld...9 Probleem...9 Krachten...20 Oplossing...20 Gevolgen...2 Voorbeeld opgelost...2 Samenvatting...23 Variaties...24 Uitbreidingen...26 Conclusie...27 Gerelateerde Patterns Dankwoord Referenties

3 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)..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

4 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..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 []: 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

5 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

6 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..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

7 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..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

8 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 ). Object Object 2 Object 3 Figuur : 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

9 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 taak beschikbaarheid verantwoordelijkheid 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

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

11 Context stap: Toevoeging van ternaire relatie stap2: Association Objects Pattern stap3: Threeparty pattern Volledigheid, Eenvoud Volledigheid Correctheid Consistentie Beheersbaarheid Eenvoud Figuur 3: stapsgewijze oplossing

12 Stap : 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 2

13 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 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. 3

14 Stap 2: Beheer van historiek, evolutie en levenscyclus van de associaties. Probleem Op het einde van stap 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. 4

15 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 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. 5

16 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 Name Description Set Association Object Begin date End date Set Object 2 Object 3 Name Name Description Description Set Ternary Association Object Begin date End date Association Object 2 Begin date End date Set Set Set Association Object 3 Begin date End date 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. 6

17 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). arbeider Name Description Set taak Name Description Taakcapaciteit Begin date End date Set Set Taakuitvoering : {ordered, cancelled, delivered, paid} Ordering date Cancellation date Delivery date Payment date afdeling Name Description Set Set Taakverantwoordelijkheid Insertion date Set Arbeiderallocatie Begin date End date Percentage 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 7

18 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 00% 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. 8

19 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 9

20 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

Inhoudstafel. UML (Unified Modeling Language)

Inhoudstafel. UML (Unified Modeling Language) UML (Unified Modeling Language) Inhoudstafel Inleiding...2 Waarvoor dient UML...2 Wat is UML... 2 Use-cases... 2 Inleiding...2 Voorbeeld...3 Eigenschappen van een goede use-case...3 Wat is een actor...4

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie?

1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? 1. Welke diagrammen beschrijven het dynamisch gedrag van een applicatie? -Use case-diagram -Use case-beschrijving -Activity diagram -Sequentie diagram 2. Welke diagrammen beschrijven de structuur van de

Nadere informatie

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Een introductie voor leden van de expertgroep Informatiemodellen Harmen Mantel, Ordina ICT Management & Consultancy, werkzaam voor KING DOELSTELLING PRESENTATIE GEMEENSCHAPPELIJKE

Nadere informatie

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan.

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan. Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. De puntenverdeling is 2 punten per theorie-vraag en 8 punten per oefening. Het totaal is 40. Vraag 1. Er bestaan verschillende

Nadere informatie

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient

vanuit de technische en organisatorische omgeving, werk-verdeling, budget, planning, en hergebruik van componenten. Het documenteren van SA dient 9 Samenvatting Software heeft vooruitgang in veel vakgebieden mogelijk gemaakt en heeft een toenemend invloed op ons leven en de samenleving in zijn geheel. Software wordt gebruikt in computers, communicatienetwerken,

Nadere informatie

UML is een visuele taal om processen, software en systemen te kunnen modeleren.

UML is een visuele taal om processen, software en systemen te kunnen modeleren. Vragen inleinding UML 1. Wat is UML? UML is een visuele taal om processen, software en systemen te kunnen modeleren. 2. Waar bestaat UML uit? Notaties(zijn symbolen, commentaar en waarden etc.) en diagrammen(grafische

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

Nadere informatie

https://pvo-idbeheer.vlaanderen.be

https://pvo-idbeheer.vlaanderen.be HANDLEIDING Gebruikersbeheer voor intergemeentelijke entiteiten april 2015 De toegang tot het online rapporteringsinstrument van de Vlaamse Milieumaatschappij (VMM) verloopt via het gebruikersbeheerplatform

Nadere informatie

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...

Nadere informatie

Les F-02 UML. 2013, David Lans

Les F-02 UML. 2013, David Lans Les F-02 UML In deze lesbrief wordt globaal beschreven wat Unified Modeling Language (UML) inhoudt. UML is een modelleertaal. Dat wil zeggen dat je daarmee de objecten binnen een (informatie)systeem modelmatig

Nadere informatie

case: toestandsdiagrammen

case: toestandsdiagrammen Hoofdstuk 13 case: toestandsdiagrammen In dit hoofdstuk wordt het maken van de eerste versie van de toestandsdiagrammen voor het boodschappensysteem van Hans en Jacqueline uitgewerkt. 13.1 Vind klassen

Nadere informatie

Stakeholder behoeften beschrijven binnen Togaf 9

Stakeholder behoeften beschrijven binnen Togaf 9 Stakeholder behoeften beschrijven binnen Togaf 9 Inventarisatie van concerns, requirements, principes en patronen Bert Dingemans Togaf 9 kent verschillende entiteiten om de behoeften van stakeholders te

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Kenmerken van DLArchitect

Kenmerken van DLArchitect Kenmerken van DLArchitect Bert Dingemans, e-mail : bert@dla-os.nl www : http://www.dla-os.nl 1 Inhoud KENMERKEN VAN DLARCHITECT... 1 INHOUD... 2 INLEIDING... 3 ARCHITECTUUR... 3 Merode... 3 Methode en

Nadere informatie

Keteininformatiemodellering op basis van UML

Keteininformatiemodellering op basis van UML Keteininformatiemodellering op basis van UML Richtlijnen en voorbeelden versie 0.1 Bert Dingemans Keteininformatiemodellering op basis van UML... 1 Richtlijnen en voorbeelden... 1 Inleiding... 2 Documenten...

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

Nadere informatie

Informatieobjecten zijn systematisch beschreven

Informatieobjecten zijn systematisch beschreven AP17 Informatieobjecten zijn systematisch beschreven Statement De aan de dienst gerelateerde informatieobjecten zijn systematisch beschreven en op passende wijze gemodelleerd. Afgeleid van BP2 (vindbaar)

Nadere informatie

Tien tips voor canonieke datamodellering. Bert Dingemans

Tien tips voor canonieke datamodellering. Bert Dingemans Tien tips voor canonieke datamodellering Bert Dingemans Abstract Modelleren is een vakgebied gebaseerd op eenvoudige notaties. Echter op het moment dat en model opgesteld wordt blijkt de te modelleren

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan FACULTEIT WETENSCHAPPEN Software Quality Assurance Plan Software Engineering groep 3 Jeroen Van den haute Versie Datum Auteur Commentaar 0.1 09/11/2010 Jeroen Van den haute Eerste versie 0.2 12/11/2010

Nadere informatie

3.1 Opsomming data type

3.1 Opsomming data type Deel I Hoofdstuk 3: Klasse Model - gevorderd 2005 Prof Dr. O. De Troyer Klasse Model - gevorderd pag. 1 3.1 Opsomming data type Opsomming (enumeration) data type Data type waarvan de verzameling waarden

Nadere informatie

beschrijvingstechnieken bij systeemontwikkeling

beschrijvingstechnieken bij systeemontwikkeling 1 Bijlage 8 Alternatieve (UML) beschrijvingstechnieken bij systeemontwikkeling De in hoofdstuk 3 weergegeven beschrijvingstechnieken voor de beschrijving van de informatietechnologie is summier. Er wordt

Nadere informatie

Objecttype Reactie Actie EGEM

Objecttype Reactie Actie EGEM 1 Overzicht ontvangen commentaar op het Referentiemodel Gemeentelijke Basisgegeven Zaken v0.9 (Herkomst van de reacties is bij EGEM bekend) 1 2.2 / 13 Besluit Een twijfelgeval is nog BESLUIT, goed beschouwd

Nadere informatie

het bank voorbeeld ISO Datamodelleren modelleren met het E-R R model een database ontwerpen verzamelingen van relaties (verbanden)

het bank voorbeeld ISO Datamodelleren modelleren met het E-R R model een database ontwerpen verzamelingen van relaties (verbanden) het bank voorbeeld ISO Datamodelleren Prof. dr. Paul De Bra waarom zijn er drie tabellen om klanten en rekeningen voor te stellen? customer (customer_name, customer_street, customer_city) account (account_number,

Nadere informatie

Toegepaste notatiewijzen DLA software

Toegepaste notatiewijzen DLA software Toegepaste notatiewijzen DLA software Bert Dingemans info@dla-architect.nl Inleiding In de DLA Software wordt gebruik gemaakt van een aantal notatiewijzen voor het opstellen van een object- en procesmodel.

Nadere informatie

Reshaping the way you think and act to deal with the complex issues of today s world

Reshaping the way you think and act to deal with the complex issues of today s world Reshaping the way you think and act to deal with the complex issues of today s world HOE GAAT HET NU? We zetten allemaal verschillende methoden in om vraagstukken op te lossen, oplossingen te ontwerpen

Nadere informatie

Software Engineering Groep 4

Software Engineering Groep 4 Software Engineering Groep 4 Software Design Description Jeroen Nyckees (Design Manager) Jan-Pieter Hubrecht (Project Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 11 december 2011

Nadere informatie

Rapportage Lineage. Introductie. Methode. J. Stuiver

Rapportage Lineage. Introductie. Methode. J. Stuiver Rapportage Lineage Rapportage Lineage J. Stuiver Introductie In elk project is het essentieel om informatie over het project en haar activiteiten voor alle partijen beschikbaar te stellen. Deze informatie

Nadere informatie

Software Quality Assurance Plan

Software Quality Assurance Plan Software Quality Assurance Plan GameTrac Versie Datum Auteur(s) Opmerking 1.0 10-12-2010 Bram Bruyninckx Eerste iteratie 1 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn

Nadere informatie

Domeinmodellen en klassendiagrammen

Domeinmodellen en klassendiagrammen Overview Architectuur Deployment-diagram Software-architectuur 1 Architectuur Deployment-diagram Software-architectuur 2 3 Architectuur Architectuur Deployment-diagram Software-architectuur Webapplicatie

Nadere informatie

Systeem modellen. Topics covered

Systeem modellen. Topics covered Systeem modellen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 8 Slide 1 Topics covered Context models Behavioural models Data models Object models CASE workbenches Ian Sommerville 2004

Nadere informatie

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com Use-Case 2.0 Requirements Kenniscentrum 15 November 2012 Eric Lopes Cardozo elcardozo@ivarjacobson.com Agenda Use cases: Een korte geschiedenis Waarom nog steeds use cases gebruiken? Waarom Use-Case 2.0?

Nadere informatie

Keteininformatiemodellering op basis van Archimate

Keteininformatiemodellering op basis van Archimate Keteininformatiemodellering op basis van Archimate Notatie en voorbeelden versie 0.1 Bert Dingemans Inhoudsopgave Inhoudsopgave... 2 Inleiding... 3 Archimate... 3 Domeininformatiemodellen... 4 Modellering...

Nadere informatie

Methodiek. Versie: 16/05/2012 13:42:35

Methodiek. Versie: 16/05/2012 13:42:35 Methodiek Versie: 16/05/2012 13:42:35 Inhoudsopgave Methodiek... 2 Onze visie op het functioneel ontwerp... 2 Stappen in het ontwerpproces... 3 Methodiek Inleiding In dit deel van de encyclopedie wordt

Nadere informatie

Van Samenhang naar Verbinding

Van Samenhang naar Verbinding Van Samenhang naar Verbinding Sogeti Page 2 VAN SAMENHANG NAAR VERBINDING Keuzes, keuzes, keuzes. Wie wordt niet horendol van alle technologische ontwikkelingen. Degene die het hoofd koel houdt is de winnaar.

Nadere informatie

Uitgebreid eindwerkvoorstel Lokaliseren van personen en objecten met behulp van camera s

Uitgebreid eindwerkvoorstel Lokaliseren van personen en objecten met behulp van camera s Uitgebreid eindwerkvoorstel Lokaliseren van personen en objecten met behulp van camera s Sofie De Cooman 21 December 2006 Stagebedrijf: Interne begeleider: Externe begeleider: BarcoView Koen Van De Wiele

Nadere informatie

Leren bedrijfseconomische problemen op te lossen door het maken van vakspecifieke schema s

Leren bedrijfseconomische problemen op te lossen door het maken van vakspecifieke schema s Leren bedrijfseconomische problemen op te lossen door het maken van vakspecifieke schema s Bert Slof, Gijsbert Erkens & Paul A. Kirschner Als docenten zien wij graag dat leerlingen zich niet alleen de

Nadere informatie

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER

Het belang van. Data Modellering. GEMINIT Training. Data Modellering. Frédéric BARBIER Het belang van Data Modellering Studiedag Informatiemanagement Politeia, 22 februari 2013, Gent Open data en de cloud: een revolutie in de informatiehuishouding van de overheid Training Data Modellering

Nadere informatie

Data Governance van visie naar implementatie

Data Governance van visie naar implementatie make connections share ideas be inspired Data Governance van visie naar implementatie Frank Dietvorst (PW Consulting) deelprogrammamanager Caesar - Vernieuwing Applicatie Landschap Leendert Paape (SAS

Nadere informatie

Gebruikershandleiding User Management Scenario 4

Gebruikershandleiding User Management Scenario 4 Gebruikershandleiding User Management Scenario 4 Inhoud Stap 1 Registratie entiteit & aanduiding VTE, aanvraag hoedanigheid Beheerder aanvullende pensioenen, activatie hoedanigheid & aanduiding Lokale

Nadere informatie

Modeleren. Modelleren. Together UML. Waarvan maken we een model? overzicht les 14 t/m 18. ControlCenter 6.2

Modeleren. Modelleren. Together UML. Waarvan maken we een model? overzicht les 14 t/m 18. ControlCenter 6.2 Modelleren Werkelijkheid Modelleren Modeleren Waarvan maken we een model?!analyse " Maak een model van de te automatiseren werkelijkheid of van het op te lossen probleem! Domeinkennis = structuur! Functionele

Nadere informatie

S A N I T R A C E BESLAG. Versie 1.0

S A N I T R A C E BESLAG. Versie 1.0 S A N I T R A C E BESLAG Versie 1.0 25 oktober 2008 1 INHOUDSOPGAVE 1. Beslag identificeren... 3 2. Beheer beslag Creatie... 5 2.1. Creatie vanuit de inrichting... 5 2.2. Standaardwaarden... 6 2.3. Velden

Nadere informatie

NHibernate als ORM oplossing

NHibernate als ORM oplossing NHibernate als ORM oplossing Weg met de SQL Queries Wat is ORM? ORM staat in dit geval voor Object Relational Mapping, niet te verwarren met Object Role Modeling. ORM vertaalt een objectmodel naar een

Nadere informatie

Systems Engineering en de Modelgebaseerde aanpak. Eric Burgers

Systems Engineering en de Modelgebaseerde aanpak. Eric Burgers Systems Engineering en de Modelgebaseerde aanpak Eric Burgers 2 Context: Toepassing MBSE in tunnelprojecten Modelprecisie / formaliteit LST 1.2 LST 1.1 Nijverdal (2011) SysML Statisch model Dynamisch model

Nadere informatie

Verwerken van binnenkomende bedrijfsdocumenten met OpenText Business Center

Verwerken van binnenkomende bedrijfsdocumenten met OpenText Business Center Verwerken van binnenkomende bedrijfsdocumenten met OpenText Business Center Inleiding Een belangrijk component van SAP Invoice Management (SIM) is de herkenning en extractie van relevante velden van een

Nadere informatie

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

ISO 9000:2000 en ISO 9001:2000. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. ISO 9000:2000 en ISO 9001:2000 Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

Nadere informatie

Bark Verpakkingen. Outsourcing Concept

Bark Verpakkingen. Outsourcing Concept Bark Verpakkingen Outsourcing Concept Outsourcing Bark Verpakkingen BV als uw partner in strategisch verpakkingsmanagement. De win-win relatie tussen 'outsourcing' en uw 'core business efficiency'. Met

Nadere informatie

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

Nadere informatie

De logica achter de ISA s en het interne controlesysteem

De logica achter de ISA s en het interne controlesysteem De logica achter de ISA s en het interne controlesysteem In dit artikel wordt de logica van de ISA s besproken in relatie met het interne controlesysteem. Hieronder worden de componenten van het interne

Nadere informatie

Waarom een samenvatting maken?

Waarom een samenvatting maken? Waarom een samenvatting maken? Er zijn verschillende manieren om actief bezig te zijn met de leerstof. Het maken van huiswerk is een begin. De leerstof is al eens doorgenomen; de stof is gelezen en opdrachten

Nadere informatie

Objectgeoriënteerde systeemontwikkeling

Objectgeoriënteerde systeemontwikkeling 2 Objectgeoriënteerde systeemontwikkeling Objecttechnologie of objectoriëntatie is een bekende term in de automatisering. Regelmatig verschijnen artikelen over dit onderwerp in de bekende vaktijdschriften.

Nadere informatie

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging Review historie Naam Afdeling Functie Datum

Nadere informatie

14-9-2015. Scrum in het kort

14-9-2015. Scrum in het kort Les 3 Scrum in het kort Scrum is een agile proces dat het ons mogelijk maakt om de hoogste waarde in de kortste tijd te realiseren. Het maakt het ons mogelijk om snel en regelmatig echt werkende software

Nadere informatie

Een inleiding in de Unified Modeling Language 67

Een inleiding in de Unified Modeling Language 67 Een inleiding in de Unified Modeling Language 67 1.4.5. Toepassing 5: Klasse Kaart. De opdracht bestaat erin algemene klassen te maken zodanig dat het mogelijk wordt om het even welk kaartspel te maken.

Nadere informatie

Beleid inzake het beheer van belangenconflicten in de VMOB «Ziekenfonds voor Hospitalisatiekosten»

Beleid inzake het beheer van belangenconflicten in de VMOB «Ziekenfonds voor Hospitalisatiekosten» Department Legal Affairs Beleid inzake het beheer van belangenconflicten in de VMOB «Ziekenfonds voor Hospitalisatiekosten» 1. Inleiding Overeenkomstig de bepalingen van de wet van 30 juli 2013 tot versterking

Nadere informatie

Deel I Hoofdstuk 2: Het klassenmodel

Deel I Hoofdstuk 2: Het klassenmodel Deel I Hoofdstuk 2: Het klassenmodel 2005 Prof Dr. O. De Troyer Klasse Model pag. 1 Hoofdstuk 2: Het klassenmodel Het Klassenmodel Beschrijft de statische structuur van een systeem door middel van Het

Nadere informatie

Application interface. service. Application function / interaction

Application interface. service. Application function / interaction Les 5 Het belangrijkste structurele concept in de applicatielaag is de applicatiecomponent. Dit concept wordt gebruikt om elke structurele entiteit in de applicatielaag te modelleren: softwarecomponenten

Nadere informatie

Sparse columns in SQL server 2008

Sparse columns in SQL server 2008 Sparse columns in SQL server 2008 Object persistentie eenvoudig gemaakt Bert Dingemans, e-mail : info@dla-os.nl www : http:// 1 Content SPARSE COLUMNS IN SQL SERVER 2008... 1 OBJECT PERSISTENTIE EENVOUDIG

Nadere informatie

4.3 Het toepassingsgebied van het kwaliteitsmanagement systeem vaststellen. 4.4 Kwaliteitsmanagementsysteem en de processen ervan.

4.3 Het toepassingsgebied van het kwaliteitsmanagement systeem vaststellen. 4.4 Kwaliteitsmanagementsysteem en de processen ervan. ISO 9001:2015 ISO 9001:2008 Toelichting van de verschillen. 1 Scope 1 Scope 1.1 Algemeen 4 Context van de organisatie 4 Kwaliteitsmanagementsysteem 4.1 Inzicht in de organisatie en haar context. 4 Kwaliteitsmanagementsysteem

Nadere informatie

Competentiemanagement bij de federale overheid

Competentiemanagement bij de federale overheid Competentiemanagement bij de federale overheid Competentieprofielen Basis Leidinggevend D December 2009 LEIDINGGEVEND D 1/ BASISPROFIEL Tabel informatie begrijpen taken Taken uitvoeren Leidinggevend D

Nadere informatie

Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering

Deel II: Modelleren en software ontwikkeling. Hoofdstuk 7 Software ontwikkeling - Overzicht. Naïeve benadering Deel II: Modelleren en software ontwikkeling Hoofdstuk 7 Software ontwikkeling - Overzicht 2005 Prof Dr. O. De Troyer, pag. 1 Naïeve benadering De vereisten voor het systeem worden geformuleerd en op basis

Nadere informatie

Introductie ArchiMate

Introductie ArchiMate Introductie ArchiMate NAF Insight De Meern, 8 maart 2012 Egon Willemsz, enterprise architect UWV Programma Waarom ArchiMate? Praktijkvoorbeelden Samenvatting concepten Van start met ArchiMate Tot besluit

Nadere informatie

MDA experiences in een uitvoeringsorganisatie. Eelco van Mens (Architect, Mn Services) 5 juni 2008

MDA experiences in een uitvoeringsorganisatie. Eelco van Mens (Architect, Mn Services) 5 juni 2008 MDA experiences in een uitvoeringsorganisatie MDA experiences in een uitvoeringsorganisatie Eelco van Mens (Architect, Mn Services) 5 juni 2008 2 Inhoud Korte introductie Mn Services Overwegingen om met

Nadere informatie

Vraag 1... Vraag 2... Vraag 3...

Vraag 1... Vraag 2... Vraag 3... Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. Elke theorie-vraag staat ofwel op 1.5 ofwel op 2 punten, en elke oefening op 10 punten. Het geheel staat op 60. Vraag 1...[.../3]

Nadere informatie

Middelen Proces Producten / Diensten Klanten

Middelen Proces Producten / Diensten Klanten Systeemdenken De wereld waarin ondernemingen bestaan is bijzonder complex en gecompliceerd en door het gebruik van verschillende concepten kan de werkelijkheid nog enigszins beheersbaar worden gemaakt.

Nadere informatie

Toelichting bij onze werkwijze

Toelichting bij onze werkwijze Toelichting bij onze werkwijze GMI group Helpdesk Referentie: IDH_20120713_HDP_V2.0 Datum: 23 juli 2015 COLOFON TITEL Een toelichting bij onze werkwijze GMI group Helpdesk UITGEVER GMI group N.V. De Pintelaan

Nadere informatie

Wijzigingsvoorstel op het Logisch Model Aquo 2 kabel-elementen uit IMKL overnemen RfC-W-0901-0031

Wijzigingsvoorstel op het Logisch Model Aquo 2 kabel-elementen uit IMKL overnemen RfC-W-0901-0031 Wijzigingsvoorstel op het Logisch Model Aquo 2 kabel-elementen uit IMKL overnemen RfC-W-0901-0031 Indiener A. Meerkerk, Nieuwland Datum 9-3-2009 Kenmerk RfC W-0901-0031 Documentbeheer Wijzigingshistorie

Nadere informatie

Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden.

Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden. Herhaling Objectgeorïenteerd werken is gebaseerd op de objecten die door het systeem gemanipuleerd worden. De basisbouwsteen is het object; een geïntegreerde eenheid van data en operaties werkend op deze

Nadere informatie

In deze les. Het experiment. Hoe bereid je het voor? Een beetje wetenschapsfilosofie. Literatuuronderzoek (1) Het onderwerp.

In deze les. Het experiment. Hoe bereid je het voor? Een beetje wetenschapsfilosofie. Literatuuronderzoek (1) Het onderwerp. In deze les Het experiment Bart de Boer Hoe doe je een experiment? Hoe bereid je het voor? De probleemstelling Literatuuronderzoek Bedenken/kiezen experimentele opstelling Bedenken/kiezen analysevorm Hoe

Nadere informatie

Module 1 Programmeren

Module 1 Programmeren Module 1 Programmeren Programmeertalen 13 1.1 Inleiding 13 1.2 Programmeertalen in historisch perspectief 13 1.2.1 Machinecode 13 1.2.2 Assembleertalen (assembly) 14 1.2.3 Hogere programmeertalen 15 1.2.4

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

Oplossingen Datamining 2II15 Juni 2008

Oplossingen Datamining 2II15 Juni 2008 Oplossingen Datamining II1 Juni 008 1. (Associatieregels) (a) Zijn de volgende beweringen juist of fout? Geef een korte verklaring voor alle juiste beweringen en een tegenvoorbeeld voor alle foute be-weringen:

Nadere informatie

Presentatie Jaarproject. Nils De Moor Sam Verboven

Presentatie Jaarproject. Nils De Moor Sam Verboven Presentatie Jaarproject Nils De Moor Sam Verboven Story Driven Modelling Story Diagrams UML class / activity / colaboration diagrams Operatoren : - Diagram begint bij - Doorloopt activities (onderling

Nadere informatie

Flex_Rooster WERKBOEK. INTRODUCTIE iseries. Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen.

Flex_Rooster WERKBOEK. INTRODUCTIE iseries. Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen. Flex_Rooster WERKBOEK INTRODUCTIE iseries Dit werkboek is eigendom van ICS opleidingen en mag niet worden meegenomen. ICS Opleidingen Niets uit deze uitgave mag worden verveelvoudigd en/of openbaar gemaakt

Nadere informatie

NAF Insight: ArchiMate en domeintalen 1 November 2012

NAF Insight: ArchiMate en domeintalen 1 November 2012 NAF Insight: ArchiMate en domeintalen 1 November 2012 Harmen van den Berg, NAF-werkgroep ArchiMate-gebruik Een paar sfeerbeelden... Werkgroep ArchiMate-gebruik Kennis delen rond gebruik ArchiMate taal

Nadere informatie

3 De stelling van Kleene

3 De stelling van Kleene 18 3 De stelling van Kleene Definitie 3.1 Een formele taal heet regulier als hij wordt herkend door een deterministische eindige automaat. Talen van de vorm L(r) met r een reguliere expressie noemen we

Nadere informatie

EEN INLEIDING IN DE UNIFIED MODELING LANGUAGE

EEN INLEIDING IN DE UNIFIED MODELING LANGUAGE Een inleiding in de Unified Modeling Language 51 III EEN INLEIDING IN DE UNIFIED MODELING LANGUAGE Als een aannemer een huis bouwt, dan ontwerpt hij dat huis niet terwijl hij het bouwt. Hij bouwt het huis

Nadere informatie

Top-down ontwerpen. Concentreren op de hoofdzaak zonder rekening te houden met allerlei details.

Top-down ontwerpen. Concentreren op de hoofdzaak zonder rekening te houden met allerlei details. Top-down ontwerpen Concentreren op de hoofdzaak zonder rekening te houden met allerlei details. Dus: de belangrijkste entiteittypes en hun onderlinge structuur proberen te vinden. De relaties in tekst

Nadere informatie

Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting

Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting xvii Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting Samenvatting IT uitbesteding doet er niet toe vanuit het perspectief aansluiting tussen bedrijfsvoering en IT Dit proefschrift is het

Nadere informatie

Hoofdstuk 26: Modelleren in Excel

Hoofdstuk 26: Modelleren in Excel Hoofdstuk 26: Modelleren in Excel 26.0 Inleiding In dit hoofdstuk leer je een aantal technieken die je kunnen helpen bij het voorbereiden van bedrijfsmodellen in Excel (zie hoofdstuk 25 voor wat bedoeld

Nadere informatie

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium Zelftest OOAD/UML Document: N0767Test.fm 30/08/2010 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is gebaseerd op de inhoud van onze cursus OO

Nadere informatie

I-rater. Best Peter Crew Leader Brainwave

I-rater. Best Peter Crew Leader Brainwave Best Peter Crew Leader Brainwave I-rater Dit rapport werd gegenereerd op 24-11-2015 door White Alan van Brainwave Ltd.. De onderliggende data dateren van 24-11-2015. HET THALENTO I-RATER RAPPORT Het I-rater

Nadere informatie

Juli 2012. Update cijfers extreme groeiers in Vlaanderen

Juli 2012. Update cijfers extreme groeiers in Vlaanderen Juli 2012 Update cijfers extreme groeiers in Vlaanderen Evolutie extreme groeiers periode 2004 2007 1 Vanuit een beleidsstandpunt is het verkrijgen en verankeren van meer en meer succesvolle groeiondernemingen

Nadere informatie

Proces to model en model to execute

Proces to model en model to execute Proces to model en model to execute Een end-to-end (bedrijfs)proces (figuur 1) is het geheel van activiteiten die zich, op een bepaalde plaats door een bepaalde rol, in bepaalde volgorde opvolgen en waarvan

Nadere informatie

Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.'

Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.' Inhoudelijke reactie EGEM op adviesrapport Telematica Instituut: 'Over het service-georiënteerde gehalte van StUF 3.0.' Versie Concept 0.2 Datum 15-11-2007 Inhoudsopgave 1 Inleiding...2 2 Inhoudelijke

Nadere informatie

Workshop 12 ART-DECOR en Acute overdracht. Michael Tan Kai Heitmann Maarten Ligtvoet

Workshop 12 ART-DECOR en Acute overdracht. Michael Tan Kai Heitmann Maarten Ligtvoet Workshop 12 ART-DECOR en Acute overdracht Michael Tan Kai Heitmann Maarten Ligtvoet 22 november 2012 Topics Aanpak en visie Perinatologie Michael Tan Uitleg Acute Overdracht in ART-DECOR Kai Heitmann Faciliteren

Nadere informatie

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid

Bijlage 9. UNI 120621.9 REB GD. Releasebeleid Releasebeleid Ondanks alle aan de samenstelling van de tekst bestede zorg, kan Newway Retail Solutions bv (Newway) géén enkele aansprakelijkheid aanvaarden voor eventuele directe en/of indirecte schade,

Nadere informatie

KDE afstandsbediening-instellingen. Michael Zanetti Vertaler/Nalezer: Tom Albers

KDE afstandsbediening-instellingen. Michael Zanetti Vertaler/Nalezer: Tom Albers Michael Zanetti Vertaler/Nalezer: Tom Albers 2 Inhoudsopgave 1 Inleiding 5 1.1 Benodigdheden....................................... 5 2 Gebruik 6 2.1 Afstandsbedieningen en modi...............................

Nadere informatie

Methoden van het Wetenschappelijk Onderzoek: Deel II Vertaling pagina 83 97

Methoden van het Wetenschappelijk Onderzoek: Deel II Vertaling pagina 83 97 Wanneer gebruiken we kwalitatieve interviews? Kwalitatief interview = mogelijke methode om gegevens te verzamelen voor een reeks soorten van kwalitatief onderzoek Kwalitatief interview versus natuurlijk

Nadere informatie

start -> id (k (f c s) (g s c)) -> k (f c s) (g s c) -> f c s -> s c

start -> id (k (f c s) (g s c)) -> k (f c s) (g s c) -> f c s -> s c Een Minimaal Formalisme om te Programmeren We hebben gezien dat Turing machines beschouwd kunnen worden als universele computers. D.w.z. dat iedere berekening met natuurlijke getallen die met een computer

Nadere informatie

Vlaamse overheid Departement Economie, Wetenschap en Innovatie Afdeling Strategie en Coördinatie Koning Albert II-laan 35, bus 10 1030 Brussel

Vlaamse overheid Departement Economie, Wetenschap en Innovatie Afdeling Strategie en Coördinatie Koning Albert II-laan 35, bus 10 1030 Brussel Evaluatie van beleid en beleidsinstrumenten Protocol tussen de entiteit 1 verantwoordelijk voor de (aansturing van de) evaluatie en (de instelling verantwoordelijk voor) het beleidsinstrument Vlaamse overheid

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

End-to-End testen: de laatste horde

End-to-End testen: de laatste horde End-to-End testen: de laatste horde Dieter Arnouts Agenda Begrip End-to-End testen in het test proces Praktische aanpak End-to-End Test Omgeving Uitdagingen End-to-End testen: De laatste horde 11/10/2010

Nadere informatie

SCANNING HANDLEIDING. Maart 2011 DRIVE THE CHANGE

SCANNING HANDLEIDING. Maart 2011 DRIVE THE CHANGE SCANNING HANDLEIDING Maart 2011 1. Inleiding RBL zet één barcodelezer ter beschikking van alle zaken van het dealersnet. Doelstelling : Scanning in uw zaak van de gepersonaliseerde fan cards (/ cadeaubonnen)

Nadere informatie

DB2P. Gebruikershandleiding User Management. Scenario 3

DB2P. Gebruikershandleiding User Management. Scenario 3 DB2P Gebruikershandleiding User Management Scenario 3 Inhoud Stap 1 Activeren van de hoedanigheid Beheerder aanvullende pensioenen en aanduiden van een Lokale beheerder... 3 Wie dient deze stap uit te

Nadere informatie

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat:

Kennis na het volgen van de training. Na het volgen van deze training bent u in staat: Training Trainingscode Duur Gepubliceerd Taal Type Leermethode Kosten SF2015V8 4 dagen 02/02/2015 Nederlands & Engels Developer, basis Invidueel & klassikaal Op aanvraag Deze training richt zich op het

Nadere informatie

BRP-BZM Business Rule Guidelines

BRP-BZM Business Rule Guidelines BRP-BZM Business Rule Guidelines Versie 2.0 02-09-2011 Definitef Versiehistorie Datum Versie Omschrijving Auteur November 1.0 Eerste versie Eric Lopes Cardozo 2011 22-7-2011 1.1 Nette variant van business

Nadere informatie