Een sluitende modelleringstechniek
Merode
Innovatie voor een stabiele toekomst
februari 2013
Inhoudsopgave 1.
INLEIDING .......................................................................................................................1
2.
AARD EN WERKING VAN EEN ORGANISATIE..............................................................2
3.
DE ONDERSCHEIDEN MODELONDERDELEN BINNEN MERODE ................................3
5.
METHODE MERODE .......................................................................................................4
6.
EEN (GEDEELTELIJK) UITGEWERKT VOORBEELD .....................................................6
7
TOT SLOT .....................................................................................................................11
7 februari 2013
1
1.
Inleiding
In het kader van het ontwikkelen van een referentiemodel voor het modelleren van wetgeving (Norim), is de markt onderzocht op toe te passen methodes. De gekozen toegepaste methode is Merode, een techniek ontwikkeld aan de Katholieke Universiteit Leuven. De methode kent een minimaal benodigde, exact gedefinieerde set gereedschap voor het modelleren. Navolgend wordt het principe van de methode beschreven. Bij elke methode hoort een denkwijze, een werkwijze een een schrijfwijze welke kort zullen worden toegelicht. Voor de volledige beschrijving wordt verwezen naar het handboek waarin Merode in al zijn facetten wordt beschreven. Voor een goed begrip voor de toepassing van deze methode wordt eerst aandacht geschonken aan het onderscheid tussen Aard en Werking van een organisatie. Voordat vervolgens denkwijze, werkwijze en schrijfwijze van Merode worden toegelicht, wordt eerst het onderscheid aangegeven tussen het Business Model, de Business Information System Layer en het Business Proces Model. Om de methode in werking te zien is een voorbeeld opgenomen in hoofdstuk 5.
7 februari 2013
1
2.
Aard en Werking van een organisatie
Bedrijfsobjecten (business objecten) vinden hun oorsprong in de bedrijfsdoelstellingen en in de eisen die een organisatie stelt aan haar functioneren. Een bedrijfsobject kent echter gedrag (dynamiek) onder invloed van allerlei mogelijke gebeurtenissen (business-events). De bedrijfsobjecten, de hiermee samenhangende gebeurtenissen en benodigde elementaire services om zo’n gebeurtenis te “triggeren”, te kunnen verwerken cq te kunnen implementeren, bepalen de AARD van een organisatie. De AARD van een organisatie is inrichtingsonafhankelijk. De manier waarop elementaire services echter in procestaken als onderdeel van een proces(gang) gemodelleerd worden en de toekenning van deze taken aan functionarissen en organisatieonderdelen bepalen de WERKING van een organisatie. Dit deel is dus inrichtingsafhankelijk. In onderstaande figuur is dit onderscheid weergegeven.
WERKING
AARD
Business Object, Events
Elementaire Services
Stabiel Inrichtingsonafhankelijk
Organisatie
Proces
Flexibel Inrichtingsafhankelijk
Figuur 1 Aard en Werking van een organisatie
19-2-2013
2
3.
De onderscheiden modelonderdelen binnen Merode
Op basis van het voorgaande komen wij tot de onderscheiden modelonderdelen zoals getoond in figuur 2, het Business Proces Model waarin de processen en de organisatieinrichting zijn vastgelegd, het Business Model waarin de gemodelleerde bedrijfsobjecten, tezamen met de gebeurtenissen en de bijbehorende regels zijn vastgelegd en de Business Information System Layer waarin de elementaire services worden benoemd. Duidelijk mag zijn dat er een ontkoppeling is tussen enerzijds het Business Proces Model, het meer flexibele deel van een organisatie, en anderszijds het Business Model en de Business Information System Layer, welk deel staat voor het stabiele deel van een organisatie. Een organisatie kan opnieuw worden ingericht op het niveau van het Business Proces Model waarbij het stabiele deel volledig of nagenoeg geheel in tact blijft.
Organisatie
Business Proces en Organisatie
Werking Proces Input service
Elementaire Services
Output service
Business Proces Model Information System Layer
Aard Domeinmodel (Object, Event, Regel)
Bedrijfs Objectmodel
Business Model
Figuur 2 Onderscheiden onderdelen Business Model, Information System Layer en Business Proces Model Bron : KU Leuven , Prof. M. Snoeck
In vele werkwijzen vindt bij de start van een ontwerp de techniek reeds een plaats (eoverheid i.p.v. i-overheid). Het modelleren volgens de methode Merode vindt volledig plaats op het niveau van de business om pas op het laatste moment het ontwikkelde model om te zetten in techniek (zie figuur 3). Om dit mogelijk te maken worden modellen dan ook ontwikkeld vanuit het oogpunt van engineering d.w.z. preciese business-modellering. Ontwerpproces Merode modellering Transformatie
Business
Techniek
Figuur 3 Gevolgde werkwijze in ontwerpproces Bij Merode eerst volledige business modellering dan techniektransformatie
7 februari 2013
3
5.
Methode Merode
5.1
Denkwijze Merode
Zoals reeds vermeld behoort bij een methode een denkwijze. De denkwijze kan als volgt worden samengevat: 1. 2. 3. 4. 5. 6. 7. 8.
5.2
De concepten Object, Event en Regel (in de vorm van pre- en postcondities) zijn onlosmakelijk met elkaar verbonden Events bepalen de levenscyclus van een object In een event kunnen meerdere objecten hun betrokkenheid hebben. Elk object kent minimaal twee gebeurtenissen, een “Create” en een “End” Regels in de vorm van precondities bepalen of een event mag en kan optreden Regels in de vorm postcondities leggen het op te leveren resultaat vast na het optreden van een event Tussen objecten bestaan slechts twee relevante exact gedefinieerde relaties: bestaansafhankelijkheid en generalisatie/specialisatie In de werkorganisatie uit te voeren procestaken, triggeren via gedefinieerde services een of meerdere events
Werkwijze Merode
Binnen Merode wordt op hoofdlijn de volgende werkwijze gevolgd: 1. 2. 3.
4.
5.
6.
8.
9.
Voor een vooraf bepaald beschouwingsgebied worden op basis van de businessdoelstellingen en -eisen de business-objecten bepaald De objecten worden gemodeleerd in een EDG (Existence Dependency Graph) Relaties tussen objecten die van betekenis zijn voor de “business” worden geinstantieerd Voorbeeld : in geval van een huwelijksrelatie : geinstantieerd object : Huwelijk Alle events worden geinventariseerd, dit zijn alle events die een voor de organisatie van belang zijnde invloed hebben op de (business)objecten Voorbeeld events: in het huwelijk treden, scheiden, etc. Per event wordt bepaald welke objecten door dit event worden beïnvloed. Voorbeeld : Event “In het huwelijk treden”; hierin participeren de objecten Natuurlijke persoon1, Natuurlijke persoon2 en Huwelijk Voor elke combinatie tussen een event en een participerend object worden de precondities (type bedrijfsregel) bepaald. Voorbeeld : Event “In het huwelijk treden” en Objecttype “Natuurlijk Persoon1”: Preconditie : Natuurlijk Persoon1 mag niet overleden zijn, mag niet reeds gehuwd zijn, etc. Postconditie: Natuurlijk Persoon1 is getrouwd Er wordt een lijst opgesteld ten aanzien van de benodigde elementaire services (Information services) Per service wodt hierbij aangegeven of het een input- dan wel een output-service betreft. Bij het opstellen van het procesmodel worden de procestaken gekoppeld aan information services die op hun beurt één of meerdere events triggeren
19-2-2013
4
5.3 1.
Schrijfwijze Merode Voor de twee genoemde relaties “bestaansafhankelijkheid” en “generalisatie/specialisatie” worden de onderstaande symbolen gebruikt. Bestaansafhankelijkheid
2. 3. 4.
Specialisatie/generalisatie
Voor de events, de objecten en de bijbehorende regels wordt een zogeheten objectevent table (OET) ingevuld Per cel in deze object – event table worden de bedrijfsregels vastgelegd (pre- en postcondities). Voor elk object wordt een zogeheten FSM (finite state machine) vastgesteld. De FSM geeft de levenscyclus van een object aan en dus ook de toegestane toestanden van een object tijdens zijn leven. De algemene vorm van een life cycle ziet er uit als onderstaand, waarbij de “C’ staat voor de Creatie, de “E” voor de beeindiging ’ en de “M” voor toegestane mutaties van het object.
C1,C2
E1,E2
M1,M2 Figuur 4 Algemene vorm van een life cycle van een object
7 februari 2013
5
6. Een (gedeeltelijk) uitgewerkt voorbeeld voor “Voertuigen”
In het onderstaande voorbeeld gaan wij er van uit dat op basis van onder meer de wegenverkeerswet, de wet op de motorrijtuigenbelasting en het bijbehorende beleid een model ontwikkeld moet worden. 6.1
Existence Depency Graph
Voor een deel van dit gebied zijn wij tot het onderstaande model gekomen, gegoten in een zogeheten EDG (Existence Dependency Graph).
Persoon
Natuurlijk_ Persoon
Kenteken_ houder
Kenteken
Houder_gekentekend_ vervoermiddel
Gekentekend_ vervoermiddel
Vervoermiddel
Rechts_ Persoon
Landvoertuig
Motorrijtuig
Luchtvaartuig
watervoertuig
Aanhangwagen
Figuur 5 De Existence Depency Graph voor (een deel van) de vervoermiddelen en houders er van. De verschillende soorten voertuigen zijn gegeneraliseerd tot “Vervoermiddel”, de “Natuurlijke Persoon” en de “Rechtspersoon” tot “Persoon”. Het kenteken is als apart objecttype opgenomen. De combinatie tussen een vervoermiddel en een kenteken levert het gekentekende vervoermiddel. Een “Persoon” kan nu houder zijn/worden van een gekentekend voertuig of houder zijn/worden van een kenteken (handelaren).
19-2-2013
6
6.2
De object Event Table
Kenteken
Houder_Kenteken
Houder_gekent_vervoermiddel
Gekentekend_vervoermiddel
Vervoermiddel
Op basis van de van toepassing zijnde wetgeving en het beleid worden alle events geinventariseerd en opgenomen in de object – event table. In onderstaande tabel 3 zijn enkele events als voorbeeld opgenomen.
4
5
6
7
8
Event
Persoon
Object
1
Nat. Rechts Persoon Persoon
2
3
Introduceren kenteken
9
Motor rijtuig
Aanhang wagen
10
11
Water Lucht vaartuig voertuig 12
13
C E
Intrekken kenteken
C
Opvoeren vervoermiddel Opvoeren landvoertuig Opvoeren motorrijtuig Opvoeren aanhangwagen
S/ C S/ C S/ C
Kentekenen_vervoermiddel
C
M
Tenaamstellen_gekentek_vervoermid. M
I/ M
I/ M
C
M
M
I/ M
I/ M
E
M
Intrekken_tenaamst_gekent_vervoerm.
Landvoertuig
M
I/ M
I/ M
I/ M
Tabel 3 Een klein deel van de Object-Event Table behorend bij het EDG uit figuur 5 De Object Event Table leert ons onder meer direct het volgende. 1.
In events zoals het “introduceren van een kenteken” en het “intrekken van een kenteken” speelt slechts 1 objecttype een rol, in deze gevallen het objecttype “Kenteken”. In eventtypes zoals “Opvoeren van een Vervoermiddel” wordt een vervoermiddel gecreerd, waarbij echter voor de betreffende subklasse eveneens een object moet worden aangemaakt (S/C) In het geval van een eventtype “Kentekenen van een Vervoermiddel” spelen meerdere objecttypes een rol. Een object van het type Gekentekend_vervoermiddel” wordt gecreerd. Een mutate (M) geldt voor zowel het kenteken als het vervoermiddel (stel men wenst bij elk vervoermiddel bij te houden het aantal keren dat een nieuw kenteken is uitgegeven, dan leidt dit tot een ‘mutate’ bij “Vervoermiddel). Een I/M is aangegeven bij respektievelijk “Landvoertuig”, “Motorrijtuig” en “Aanhangwagen”. De “I” staat voor ‘Inheritance’ of wel als gevolg van de specialisatie overerven deze de mutate voor “Vervoermiddel”.
7 februari 2013
7
2.
Elke kolom dient op zijn minst een “C” (Create) en een “E” (End) te bevatten wat duidt op respektievelijk de aanvang en het einde van de levenscyclus van een object. Indien een “C” en/of een “E“ ontbreken in een kolom duidt dit op onvolledige inventarisatie van de events. In de kolom voor Voertuigen ontbreekt bijvoorbeeld deze “E” of wel events zoals bijvoorbeeld “Slopen van een voertuig” of “Exporteren van een voertuig”, die de levenscyclus kunnen beeindigen, ontbreken.
3.
De kolommem in de Object Event Table bevatten de basis voor het specificeren van de zogeheten “Finite State Machines (FSM). De FSM geeft de toegestane opeenvolging van toestanden in het “leven” van een object aan. De algemene vorm van een life cycle ziet er uit als onderstaand. Meerdere soorten events kunnen leiden tot een “Create” (C1, C2), meerdere soorten events kunnen leiden tot een “Mutate” (M1, M2) en meerdere soorten events kunnen leiden tot een beeindiging van de levenscyclus ( E1, E2).
C1,C2
E1,E2
M1,M2
6.3
Vastlegging bedrijfsregels
Op basis van de object event table worden nu bedrijfsregels vastgelegd in de vorm van pre- en postcondities. Zoals de woorden al aangeven betreffen de precondities condities waaraan moet worden voldaan, wil een event geimplementeerd kunnen en mogen worden. Als voldaan wordt aan alle precondities van de participerende objecten, dan wordt een resultaat opgeleverd in de vorm van de postcondities. Voorbeeld uit de tabel Eventtype : “Tenaamstellen van een motorrijtuig” en Objecttype : “Natuurlijk Persoon” : Regels : 1. Natuurlijk Persoon moet ouder zijn dan 18 jaar 2. Natuurlijk Persoon mag niet overleden zijn Eventtype : “Tenaamstellen van een motorrijtuig” en Objecttype : “Motorrijtuig” : Regels : 1. Motorrijtuig mag niet gesloopt zijn 2. Motorrijtuig mag niet gexporteerd zijn. Etc.
19-2-2013
8
6.4
Geinventariseerde informatie services
Voor het betreffende beschouwingsgebied (modelgrenzen) inventariseren wij alle benodigde elementaire information services en plaatsen deze in een lijst. Zie als voorbeeld onderstaande tabel 4 (let op : is een voorbeeld, dus geen volledigheid).
Nr 1 2 3 4 5 6 7 8 9 Tabel 4
6.5
Type (Input/Output)
Omschrijving Information Service Opvoeren nieuwe kenteken Intrekken kenteken Opvoeren nieuw motorrijtuig Kentekenen van een motorrijtuig Check bevoegdheid Persoon aanvraag overboeking tenaamstelling Overboeken tenaamstelling motorrijtuig Print lijst alle ingetrokken kentekens per opgegeven datum Print lijst gekentekende motorrijtuigen met ingetrokken kenteken etc. Voorbeeld van geinventariseerde, benodigde Information Services
Input Input Input Input Output Input Output Output
Het Business Proces Model gekoppeld aan information Layer en Domeinmodel
Na het tekenen van het procesmodel, weergegeven in vereenvoudigde vorm in onderstaande figuur 6, worden de koppeling tussen de procestaken, de information services en de te triggeren (business)events gelegd.
Melding overboeking
10 Ontvangen 4
1 Zend en
Afd “Ontvangen/Verzenden
Aanvraag Overboeking tenaamstelling
3
2 Ontvangen Aanvraag Overboeking tenaamstelling
Afd. “Verwerking”
RDW
RDW bedrijf of Postkantoor
12 Ontvangen
Figuur 6
Melding Afwijzing aanvraag
Ontvangen Melding Ontvangst zending
Melden ontvangst Zending Aanvraag overboeking
5
Ontvangen Melding Fouten in zending
7
6
Melden Fouten in zending
9
Melden Afwijzing
11
Melden Overboeking
Nee
Check zending -Bevoegdheid Persoon overboeken -Etc.
Oke? Ja
Nee
8
Overboeken Tenaamstelling
Oke?
Ja
Vereenvoudigd (deel) procesmodel voor overboeken tenaamstelling motorrijtuig
7 februari 2013
9
De koppeling tussen de procestaken, de information services en de te triggeren events worden nu vastgelegd zoals weergegeven in onderstaand tabel 5.
Nr
Procestaak
Information Service
Triggered Business event
Nr 1 Zenden aanvraag overboeking tenaamstelling
Buiten systeem
2 Ontvangen aanvraag overboeking tenaamstelling
Input service, buiten model, behoort tot interactie domein
3 Melden ontvangst zending aanvraag overboeking
Output service, buiten model, behoort tot interactie domein
4 Ontvangen Melding ontvangst zending
Buiten systeem
5 Check zending . check bevoegdheid aanvrager
Buiten model, behoort tot interactie domein Output service
5
6 Melden fouten in zending
Output service, buiten model, behoort tot interactie domein
7 Ontvangen melding fouten in zending
Buiten systeem
8 Overboeken tenaamstelling
9
Input service
9 Melden afwijzing
Output service
10 Ontvangen melding afwijzing aanvraag
Buiten systeem
11 Melden overboeking
Output service
12 Ontvangen melding overboeking
Buiten systeem
1. Intrekken_tenaamstelling_gekentekend_vervoermiddel 2. Tenaamstellen_gekentekend_vervoermiddel
Tabel 5 Koppeling tussen procestaken, information services en (business)events
19-2-2013
10
7
Tot slot
Er gaat niets boven een goede methode, eenvoudig, precies, helder gedefinieerd en volledig in zijn toepassing. Merode kan dit worden toegedicht. Want zeg nu zelf: “wat zal het resultaat zijn als je uitgaat van procesmodellen” en - er is geen of weinig verband gelegd met de information service laag en het Business Model - het Business model telkens opnieuw wordt ontwikkeld of beschreven. - de koppeling tussen de information system service laag en het Business model niet of niet helder wordt vastgelegd - de bedrijfsregels geen heldere plaats vinden in het ontwikkelde model Ga dus voor methoden die voldoen aan eenvoud, eenduidigheid, helderheid en exactheid.
7 februari 2013
11
