Procesmodellering II : de gebeurtenissen als uitgangspunt

Procesmodellering II : de gebeurtenissen als uitgangspunt

Het logboek met registratie van gebeurtenissen In een logboek zijn opgenomen, wàt er gebeurde, wanneer dat iets gebeurde, wie daarbij betrokken waren, wat de rol van elk van de betrokkenen daarbij was en welke eigenschappen van die betrokkenen daarbij relevant waren.

Voorbeeld een stadhuis met een logboek m.b.t de bevolkingsregistratie: ‘op tijdstip T1 deed persoon P1 aangifte van de geboorte van persoon P2, waarbij P1 zelf de moeder en persoon P3 de vader is en de geboorte plaatsvond op tijdstip T2 en persoon P2 ingeschreven werd als woonachtig op adres A1’ en: ‘op tijdstip T3 meldde persoon P4 het overlijden op tijdstip T4 van persoon P5’ en: ‘op tijdstip T5 meldde persoon P6 zijn verhuizing naar adres A2’ etc.

Achteraf is uit de registratie van deze gebeurtenissen voor elk moment uit het verleden (+ heden) de inhoud van de betreffende database te reconstrueren.

© RU Nijmegen / NIII

1

Cursus IS0 / Informatiesystemen in hun context

Een aanpak via ‘objecten’

Een gebeurtenissen-analyse kunnen we uitvoeren door allereerst te bepalen welke objecten (beter: objecttypen) binnen het UoD een rol spelen.

Onder een object verstaan we een reëel of conceptueel ‘iets’, waarvan we een of meer (gegevens-) waarden willen of kunnen vastleggen/opslaan en dat een ‘gedrag’ heeft.

Het ‘gedrag’ van een object wordt (vooral) bepaald door de wijze waarop veranderingen in de attribuutwaarden van dat object tot stand komen.


2


• Gebeurtenissen betekenen acties op objecten. • Acties op objecten veroorzaken veranderingen in de object-eigenschappen. • Acties hebben over het algemeen te maken met invoer-functies. Input functions Actions Operations Attributes Objects Output functions Figuur 1 Structuur van een object-georiënteerd informatiesysteem (Schema uit ‘de KISS-methode’)

• ‘Acties op objecten’ veroorzaken ‘operaties op attributen’ van die objecten. • Bij een bepaalde ‘Input function’ kunnen meerdere ‘acties’ horen. • Dit heeft meestal consequenties voor de user interface van die invoerfunctie. Als we bijvoorbeeld ook de gezinssamenstellingen willen bijhouden, dan zal vaak gelijktijdig met een actie op een object van het type Persoon ook een (update-) actie op een object van het type Gezin moeten plaatsvinden. In zo’n geval zal het voor de hand liggen om bij een invoerscherm voor het verwerken van een nieuwe geboorte-aangifte ergens op dat scherm ook de huidige samenstelling van het betreffende gezin te tonen.


3


Het object life model : de levenscyclus van een object We kunnen schematisch de samenhang tussen acties op objecten aangeven. Voorbeeld:

Rekening

Then

Then

Opmaken

Versturen

Then

Archiveren

Betalen

Figuur 2 De levenscyclus van een 'rekening'-object

De in deze ‘object life model’ schematechniek meest gebruikte symbolen zijn: 1

objecttype

actie

vervolg actie

herhaling van acties

decompositie van acties

keuze tussen acties

parallelle acties

objecttype initialisatie

herhaling/keuze van acties

Algemene levenscyclus voor een object:

• het object wordt aangemaakt (Create); • tijdens ‘het bestaan’ van het object zijn er -al dan niet in een herhalingmeerdere Update- en/of Opvraag(/inspectie)-acties op mogelijk; • (niet per se noodzakelijk): het object wordt verwijderd (Destroy). 1

Afkomstig uit het proefschrift van Paul Frederiks.


4


Toepassing: op de eerder gebruikte levenscyclus van een object van het Persoon-type, waarbij we tevens de acties ‘huwen’ en ‘scheiden’ en diverse wijzen van ‘verhuizen’ introduceren.

Persoon

Repeatedly Then

Then

*

Verhuizen van buiten stad

Aanmelden Verhuizen bij geboorte binnen stad

Huwen

*

Scheiden

Verhuizen naar andere stad

Overlijden

*) extra constraint: scheiden kan slechts bij een gehuwd persoon

Voor het op deze proces-analyse-manier ontwikkelen van een informatiesysteem moeten we een ‘compleet’ overzicht hebben van alle object(typ)en en acties die daarop kunnen toegrijpen en hoe daardoor hun kenmerken (attribuutwaarden) veranderen.


5


Inventarisatie van (potentiële) objecttypen via zinsanalyse Om een overzicht van objecttypen en bijbehorende acties te maken, bestaan meerdere mogelijkheden: a) via een analyse van verwoordingen van gebeurtenissen zoals die in een logboek staan. Als er geen concreet logboek bestaat, dan kunnen we misschien een ‘verzonnen’ logboek maken, uitgaande van: “Wat kan er allemaal gebeuren in ons UoD en wat zouden we ervan willen vastleggen?

b) door een beschrijving van de bedrijfsprocessen van die organisatie te analyseren. Bepaal van elk in zo’n beschrijving voorkomend zelfstandig naamwoord of van het achterliggende concept gegevens moeten worden opgeslagen. Indien dat zo is, dan hebben we een ‘kandidaat objecttype’.

Handige -niet altijd geldende- vuistregels hierbij zijn: • als er méérdere eigenschappen van zo’n ‘kandidaat object’ vastgelegd worden, dan hebben we welhaast zeker met een ‘object’ te doen; • ook hebben we (vrijwel zeker) met een object te doen, als we van zo’n ‘kandidaat object’ eigenschappen (/attribuutwaarden) willen kunnen veranderen (en uiteraard registreren in ons informatiesysteem).

Bij een eerste analyse leggen we vaak alleen de identificerende attribuutwaarde(n) van een object(type) vast én de acties die eigenschappen van een object kunnen wijzigen (d.w.z. create-, update- en destroy-acties).

Het gedrag van objecttypen is af te leiden uit aangetroffen werkwoordsvormen. De opvraag(/inspectie)-acties laten we bij een eerste analyse vaak achterwege. © RU Nijmegen / NIII

6


Een uitgewerkt voorbeeld: de boekhandel Situatieschets In het functioneren van een plaatselijke boekhandel kan men vier (hoofd)activiteiten onderscheiden. Op de eerste plaats worden in de winkel de te verkopen boeken op een aantrekkelijke manier op rekken geëtaleerd en te koop aangeboden. Klanten nemen de door hen uitgekozen boeken mee naar de kassa, waar het afrekenen met geld of cheques plaatsvindt. Tevens worden daar de gegevens van de verkochte boeken bijgehouden. De klant neemt de gekochte boeken mee naar huis. Op het einde van de werkdag gaan geld, cheques en verkoopgegevens van de kassa naar de afdeling administratie. Die afdeling administratie zorgt ervoor, dat nog diezelfde dag het geld en cheques naar de nachtkluis van de bank wordt gebracht. Bovendien zorgt die afdeling ervoor dat de die dag verkochte boeken weer worden aangevuld, door bestellingen te plaatsen bij de groothandel. Die bestelde boeken worden -meestal binnen een paar dagen- door de groothandel afgeleverd bij de magazijnbeheerder van de boekhandel. De bijbehorende leveringsgegevens worden doorgespeeld naar de afdeling administratie. Vanuit het magazijn worden systematisch de winkelrekken afgespeurd en worden de erin opengevallen plaatsen weer aangevuld met boeken uit het magazijn. Die aanvulgegevens worden per dag geregistreerd, waardoor later (als je aanvulgegevens combineert met verkoopgegevens) een overzicht te genereren is van de boeken die in de winkelrekken moeten staan. De magazijnbeheerder zorgt er ook voor, dat iedere eerste maandag van de maand een lijst met voorraadgegevens van zowel het magazijn als wat in de winkelrekken staat (althans: zou moeten staan) aan de administratie wordt verstrekt. Door een vergelijk van die voorraadgegevens van de magazijnbeheerder en de die maand van de kassa verkregen verkoopgegevens, kan de administratie erachter komen of er boeken op een ongewenste manier uit de winkel zijn verdwenen. De afdeling administratie verzorgt halverwege de maand voor de eigenaar van de zaak een overzicht van die verdwenen boeken en plaatst in de winkelrekken weer nieuwe, vervangende exemplaren.


7


De boekhandel: gebruikte ‘gegevensformulieren’ Boekhandel ‘De Boekenwurm’ Kassabon Aankoop d.d.

Tijd:

24-11-99

Titel

14:22 u

Aantal Prijs

Mussen onder uw dak

2

35,90

Introduction to Database Systems

1

87,35

123,25

Totaalbedrag U werd geholpen door verk.nr: 3 Ruilen binnen 2 weken na aankoopdatum

Voorbeeld kassabon auteur

ISBN-nr

titel

uitgave

Daniels, N.C.

0-201-63195-4

Information Technology

Addison-Wesley, 1994

64,90

Date, C.J.

0-201-96426-0

Guide to SQL-Standard, A


64,90

0-201-82458-2



87,35

0-201-62438-9

Indispensable Guide to C, The


54,95

Davies, P.

verkoopsprijs

Deel gebruikte lijst met catalogusgegevens van verkrijgbare boeken

Voorraadsituatie d.d. 26-11-‘99

aantal in voorraad

auteur

ISBN-nr

titel

Date, C.J.

0-201-96426-0


3

2

0-201-82458-2


1

1

in magazijn

in winkelrek

Deel van de voorraadstaat op een bepaalde datum Aanvulgegevens d.d. 24-11-‘99

aantal van magazijn naar winkelrek

auteur

ISBN-nr

titel

Date, C.J.

0-201-96426-0


2

0-201-82458-2


1

Deel van de aanvulgegevens op een bepaalde datum Bestel- / leveringsgegevens besteldatum

ISBN-nr

aantal besteld leveringsdatum

0-201-96426-0

16-9-1999

2

0-201-82458-2

16-9-1999

1

0-201-82477-1

18-9-1999

1

17-9-1999

19-9-1999

Deel van de bestellings/leveringsstaat


8


Op zoek naar objecttypen binnen dit UoD We verzamelen als kandidaat objecttypen (met mogelijke acties erop):

Objecttype

Actie

‘Boek’

invoeren en verwijderen (uit de boekencatalogus)

‘Boekverkoop’

realiseren (‘create’) en (binnen 2 weken) ‘annuleren’ (‘destroy’)

‘Bestelling’

plaatsen (‘create’) en afleveren

‘Aanvulling’

aanvullen (‘create’) en ‘aanvullen_na_ verdwijning’

‘Magazijnvoorraad’ aanvullen (boeken gaan naar winkel) en ‘bestelling_aannemen’ ‘Winkelvoorraad’

aanvullen (boeken komen uit magazijn), verkopen (het verkopen van een boek vermindert de winkelvoorraad), ‘constateren verdwijning’ (deze zal een ‘Aanvulling’ moeten triggeren).

In dit overzicht zijn geen verdere benodigde ‘inspectie’-acties opgenomen.


9


De diverse object-levenscycli

Boek

Repeatedly

Then

Invoeren in catalogus (create)

Seldom

verkopen

verkopen (create)


Verwijderen uit catalogus (destroy)

aanvullen afleveren annuleren (winkelrek) (bestelling ) verkoop

Aanvulling

Boekverkoop

Then

eventueel ooit

Bestelling

Then

Seldom

annuleren verkoop (destroy)

aanvullen (winkelrek) (create)

10

plaatsen bestelling (create)

afleveren (bestelling)


Boekverkoop

Boek

Then

eventueel ooit

Then



verkopen (create)

Seldom

annuleren Verkoop (destroy)

Magazijn voorraad

Bestelling Then

Repeatedly

Then

(create)

plaatsen bestelling (create)

afleveren (bestelling)

aanvullen afleveren (winkelrek) (bestelling )

Winkel voorraad Aanvulling Then

Repeatedly

(create) Seldom

aanvullen (winkelrek) (create)


verkopen annuleren verkoop

11

aanvullen (winkelrek)


We combineren deze object life cycles tot een totaal Objecttype/acties-schema: Verwijderen uit catalogus (destroy)


verkopen

eventueel ooit

Seldom

annuleren verkoop

Boek

Aanvulling


Boekverkoop

afleveren (bestelling )

Bestelling plaatsen (bestelling) (create)

Legenda: xxx

objecttype

‘normale’ actie

create-actie

destroy-actie

Figure 3 Object action involvement-schema voor het boekhandel-voorbeeld

In één oogopslag is te zien, dat de acties ‘verkopen’, ‘annuleren verkoop’, ‘afleveren bestelling’ en ‘aanvullen (winkelrekken)’ allen effect hebben op de life cycle van objecten van telkens twéé verschillende typen.

Gevolgen: a) We hebben hier te maken met ‘elementaire acties’ of ‘transacties’, waarvoor geldt, dat een combinatie van meerdere acties (liefst onmiddelijk achter elkaar) moet worden uitgevoerd om de database integer te houden. 2 b) Dit zal waarschijnlijk ook zijn uitwerking hebben voor de user interface voor deze invoerfuncties (!). Waarschijnlijk zal de gebruiker wensen, dat bij het invoeren van ‘Aanvulling’-gegevens, dat op hetzelfde moment (lees: in hetzelfde window) de huidige aantallen zoals die in voorraad zijn op zowel de winkelrekken als in het magazijn worden weergegeven.

2

Het ‘verstrengelde’ van deze acties heeft ook te maken met de afleidbaarheid tussen verkoop-, leverings- en aanvulgegevens enerzijds en boek-voorraadgegevens anderzijds. © RU Nijmegen / NIII

12


verkopen


Winkel voorraad


Boek

Boekverkoop

Seldom

(create)

annuleren verkoop

Aanvulling eventueel ooit


Magazijn voorraad (create)

Bestelling plaatsen (bestelling) (create)

afleveren (bestelling )

Legenda: xxx

objecttype

‘normale’ actie

create-actie

destroy-actie

Maar: zeer vreemd dat het Boek-objecttype ‘los’ hangt van de rest …


13


Verduidelijken samenhang door opnemen van ‘inspectie’-acties

annuleren verkoop Winkel voorraad

Seldom

Boekverkoop

verkopen

(create)



Verwijderen uit catalogus (destroy) eventueel

Aanvulling

Boek

ooit

plaatsen (bestelling) (create) Magazijn voorraad (create)

Bestelling afleveren (bestelling )

Legenda: xxx

objecttype

create-actie

‘update’- actie

destroy-actie

‘inspectie’-actie

user interface aspecten nog duidelijker ..


14


Objecten: data + bijbehorende operaties (‘methodes’) Schematisch: Boekverkoop Data: Identificerend: ISBNnr + aantal + datum + uuraanduiding + verkopernr .…(+ evt. resterende data)

Boek Data: Identificerend: ISBNnr aantal-in-magazijn aantal-in-winkelrek ….(+ evt. resterende data)

Methodes: verkopen annuleren verkoop ……

Methodes: invoeren in catalogus verwijderen uit catalogus verkopen annuleren verkoop aanvullen (winkelrek) afleveren (bestelling) ……

Aanvulling Data: Identificerend: ISBNnr + aantal + datum ….(+ evt. resterende data)

Bestelling Data: Identificerend: ISBNnr + aantal + besteldatum ….(+ evt. resterende data)

Methodes: aanvullen (winkelrek) ……

Methodes: plaatsen afleveren ……

Let op de time stamp -achtige identificerende attributen van ‘Boekverkoop’, ‘Aanvulling’ en ‘Bestelling’ => logboek van gebeurtenissen!


15


Mogelijke uitbreidingen:

o.a. bepalen welk database-type + structuur (‘implementatie-aspect’)

b.v. naar een relationele database (uitgaande van het ORM-CS: ) "Tijdstip" Verkoper (Verk_naam)

Auteur (Aut_naam)

Uur

P

heeft als

op...om...

van...zijn door...op......verkocht

Titel heeft als Verkoopsprijs (Bedrag)

Uitgever (Uitg_naam)

Boek (ISBNnr) van...zijn...exemplaren op...in winkel aangevuld

heeft

van...zijn...in magazijnvoorraad Aantal

is uitgave van

Datum Jaar (Jaartal)

van...zijn in winkelrekken...in voorraad "Bestelling" met jaar van eerste uitgave

P van...zijn...exemplaren op...besteld


Cursus IS0 / Informatiesystemen in hun context 16

is geleverd op

Met als mogelijke relationele tabelstructuur:

Verkopen PK,FK ISBNnr Verkoper PK Datum PK Uur PK Aantal

Boek PK ISBNnr Titel Auteur Bedrag Uitgever Uitgavejaar Aantal_In_Magazijn Aantal_in_Winkel

Aanvulllingen PK,FK ISBNnr Datum PK Aantal Bestelling PK,FK ISBNnr Aantal PK Besteldatum PK Leverdatum

De relationele gegevenstabellen (b)lijken overeen te komen met de van-acties-ontdane objecttypen!


Cursus IS0 / Informatiesystemen in hun context 17

Een tweede uitgewerkt voorbeeld: een bank-afdeling Opmaken+Versturen

terugsturen opdracht

Rekeningafschrift

Seldom

* Betalingsopdracht

saldo verlagen *

Rekening (houder)

saldo verhogen

uitvoeren opdracht

adres wijzigen

invoeren (create)

?

invoeren (create)

toesturen betaalformulieren

Bijzondere opdracht

Extra constraint: eerst wordt gechecked of voldoende saldo aanwezig is; zo ja, dan wordt de betalingsopdracht teruggestuurd; zoniet, dan pas ‘uitvoeren opdracht’

*

Legenda: xxx

objecttype

create-actie

‘normale’ actie

destroy-actie

Figure 4 Object action involvement-schema voor het bank-afdeling-voorbeeld Opmaken+Versturen Rekeningafschrift Seldom

terugsturen opdracht * Betalingsopdracht

saldo verlagen *

saldo verhogen

uitvoeren opdracht

adres wijzigen

invoeren (create)

?

toesturen betaalformulieren

Bijzondere opdracht

invoeren (create) *

Rekening (houder)

Extra constraint: eerst wordt gechecked of voldoende saldo aanwezig is; zo ja, dan wordt de betalingsopdracht teruggestuurd; zoniet, dan pas ‘uitvoeren opdracht’

Legenda: xxx

objecttype

‘normale’ actie

create-actie

destroy-actie

inspectie-actie

Figure 5 Object action involvement-schema voor het bank-afdeling-voorbeeld met inspectie-acties aangegeven © RU Nijmegen / NIII

19


Aanpak via de KISS-methode (Kristen Information and Software Services BV)

De KISS-methode is sterk gebaseerd op objectorientatie, maar ook zien we aspecten uit BSP terug.

De bij de KISS-methode toegepaste zinsanalyse is zeer stringent. Er worden onderscheiden: • gezegde (engels: predicate) verwijst naar een actie; • onderwerp (engels: subject) is meestal géén object, maar wèl als door de actie de eigenschappen ervan veranderen en dat bijgehouden moet worden (b.v. als iemand iets koopt, dan veranderen de bezittingen van die persoon). Vaak zal ‘het onderwerp’ iets of iemand aanduiden die verantwoordelijk is voor, respectievelijk controle uitoefent op het verloop van een bedrijfsproces (lees in dit geval: op een of meer acties); • lijdend voorwerp (engels: direct object)

en het:

•

verwijzen vaak naar een object(type)

meewerkend voorwerp (engels: indirect object)

Aanpak: bepaal de relatie tussen het ‘organisatorische procedurele systeem’ en het informatiesysteem-in-engere-zin. Analyseer daartoe: • de ‘te regelen’ processen (vaak op basis van gegevens-output ) • verantwoordelijkheden en autorisatie van personen voor gebruik van het IS • welke ‘acties’ op welke gegevens/objecten zijn nodig? (toevoegen, veranderen, verwijderen, opvragen van welke objecten?)


20


Procesmodellering II : de gebeurtenissen als uitgangspunt

Recommend Documents