Deel 9: 9.1 Inleiding

IS0-cursus: Procesmodellering : objectgerichte analyse

Deel 9:

Procesmodellering : 9.1

objectgerichte analyse

Inleiding

In het eerste deel van deze cursus hebben we bij het deel 3 (‘Organisatie-modellering’) ons beperkt tot het in kaart brengen van activiteiten en gegevens- (en goederen-) stromen binnen een organisatie en die via een SADT- en/of ISAC-A-schematechniek e.d. gemodelleerd en gevisualiseerd. Het zo verkregen schema bood ons de mogelijkheid een aantal controlerende analyse-activiteiten uit te voeren op de gegevensstromen, zoals: • hebben alle processen wel invoer en uitvoer? • worden ‘opgeslagen gegevens’ wel ergens voor gebruikt (zoniet: waren ze dan ‘onnodig’ of ontbrak er iets aan onze analyse?) • bestaat er consistentie tussen in-/uitvoer/aansturing in een hiërarchisch verfijnd schema? • welke gegevenssoorten (‘entiteiten’, ‘objecten’ en/of database-gegevenstabellen) zijn betrokken bij elk proces? (nodig om desgewenst te kunnen aangeven, hoe van een informatiesysteem eventueel al een deelsysteem met voorrang ontwikkeld en gebruikt zou kunnen worden). Een proces is daarbij voor ons een duidelijk afgebakende (bedrijfs-) activiteit, die gegevens verwerkt en tot het beschouwde informatiesysteem behoort. Over dergelijke processen kunnen we opmerken: • Het begrip ‘proces’ is hier synoniem aan ‘(deel-)systeem’; zelfs het gehele informatiesysteem is te beschouwen als een proces, dat initiële invoergegevens verwerkt en de (eind-) uitvoer produceert. • Processen kunnen door mensen en/of machines worden uitgevoerd. Na het zo in kaart brengen van processen en gegevensstromen (al dan niet met die controle-checks), hebben we in het vervolg van de cursus ook geleerd een data-model te maken van de gegevens, die een rol spelen in een organisatie, en van de relaties tussen die gegevens. We gebruikten daarvoor de concrete informatie-analyse-methode ORM. Door transformatie van het verkregen datamodel (lees: het CS; het conceptuele schema) zijn we in staat een ‘optimale’ structuur te bepalen voor een in de aangetroffen situatie te gebruiken relationele database. Elke daarbij verkregen gegevenstabel bestaat uit records, waarin op een specifieke manier losse, bij elkaar behorende gegevens bij elkaar geclusterd zijn. Uit het SQL-deel van de cursus weten we, dat gegevensrecords toegevoegd, veranderd en verwijderd kunnen worden via respectievelijk INSERT-, UPDATE- en DELETE-opdrachten. Uiteraard zijn ook SELECT-queries mogelijk om opgeslagen gegevens te tonen. Kortom, er zijn operaties op zulke (tabellen en) records mogelijk. Die operaties op gegevens zijn nodig voor het ondersteunen van processen binnen de organisatie. Een analyse van de bedrijfsprocessen geeft inzicht in de aard van de benodigde operaties op gegevens(records). En dan deden we in deze inleidende cursus alsof het verder ontwerpen en implementeren van een informatiesysteem nu verder een fluitje van een cent zou zijn… Een typische data-georiënteerde gedachtengang. Een zwak punt van de informatie-analyse-aanpak is echter, dat je (achteraf) apart moet gaan analyseren welke operaties op welke gegevensrecords er nodig zijn voor ondersteuning van een bepaald bedrijfsproces. Er valt dus nog veel te doen, voordat we een ‘echt’ informatiesysteem voor de bewuste organisatie kunnen ontwikkelen. Belangrijk daarbij is een nadere bestudering van de aanwezige bedrijfsprocessen. In allerlei meer proces-georiënteerde systeemontwikkelmethoden wordt veel meer aandacht aan een gedetailleerdere proces-analyse (+uitwerking) besteed 1. Vele van de verschillende ‘proces-georiënteerde systeemontwikkelmethoden’ komen, behalve op vormaspecten, sterk met elkaar overeen en/of bouwen op elkaar voort. Helaas zijn er al te veel gelovige ‘adepten’ van een bepaalde methode, die alleen die bepaalde methode boven alles willen toepassen.

1

N.B. Interessant zou het zijn om iemand via (vooral) informatieanalyse een specificatie + ontwerp te laten opzetten en iemand anders dat (vooral) via een procesanalyse te laten doenen en dan de zo verkregen resultaten naast elkaar te leggen en met elkaar te vergelijken (op volledigheid en uiteraard of ze wel correct zijn). Zo’n aanpak is in de praktijk echter ‘te duur’.

1


Wij willen ons hier niet vastpinnen op een van die methodes, maar een aantal algemene aspecten en ontwikkelingen binnen de ‘proces-georiënteerde’ aanpak proberen duidelijk te maken. We geven hier alvast een algemene voorzet om alvast wat relativering aan te brengen bij enerzijds data-georiënteerde en anderzijds proces-georiënteerde ontwikkelmethodes. Binnen een bepaald bedrijf of organisatie is over het algemeen de aard van de gebruikte gegevens en de samenhang tussen die gegevens vrij stabiel. Denk hierbij bijv. aan klant-, leveranciers-, product-, order-, betalings-, productie- en planningsgegevens. Ook processen (lees desgewenst ‘activiteiten’) zijn binnen een bedrijf of organisatie vrij stabiel. Hoe je een bedrijf intern ook opdeelt in afdelingen en/of personen die je het werk laat uitvoeren, steeds zullen in dat bedrijf processen bestaan voor b.v. planning, productie, inkoop, verkoop, financiële administratie etc.. Je kunt je waarschijnlijk voorstellen, dat bij een klein beginnend bedrijfje al die processen door één persoon in één ruimte worden uitgevoerd, dat bij groei van dat bedrijf diezelfde processen door verschillende mensen worden uitgevoerd en dat bij nog verdere groei gespecialiseerde afdelingen ontstaan. De processen zijn tijdens die groei vaak min of meer hetzelfde gebleven. De structuur van de organisatie (afdelingen, verantwoordelijke personen) is dus vaak erg veranderlijk. Binnen een bedrijf/organisatie zullen informatiesystemen gebruikt worden om de bedrijfsprocessen (“waar het binnen een bedrijf immers allemaal om draait”) zo goed mogelijk te ondersteunen. Zo kun je je ongetwijfeld voorstellen, dat (een functie van) een informatiesysteem, aan de hand van eerder in de database opgeslagen ordergegevens, het productieplanningsproces kan ondersteunen en dat een andere functie van dat informatiesysteem (het al dan niet binnenkomen van) de betalingen van klanten mee in de gaten kan helpen houden. Als voor een bedrijf een informatiesysteem ontwikkeld moet worden, zal men zich daarom niet moeten laten ‘afleiden’ door het bestaan van afdelingen en verantwoordelijke per sonen, maar moet men zich primair richten op de vraag hoe bedrijfsprocessen zo goed mogelijk door een IS ondersteund kunnen worden.

9.2

Achtergrond: de BSP-methode (BSP: ‘Business Systems Planning’)

De BSP-methode 2 is oorspronkelijk rond 1980 ontwikkeld door IBM en vooral bedoeld om de informatievoorziening (lees: informatiesystemen) beter af te stemmen op de diverse bedrijfsprocessen. Sebus schrijft: “Ook voor automatisering geldt, dat technische efficiency -‘doing things right’- , alhoewel belangrijk, geenszins alleenzaligmakend is: er bestaat ook zoiets als ‘doing the right thing’.” Zeer kort samengevat kun je zeggen, dat bedrijfs-processen uitgevoerd worden in een of meer afdelingen van een organisatie. Die afdelingen leveren input voor een bij te houden gegevensverzameling (database). Vervolgens kunnen die gegevens door informatiesystemen zodanig verwerkt/ ‘veredeld’ worden, dat het uitvoeren van de bedrijfsprocessen effectief ondersteund kan worden. We hebben dit geheel schematisch samengevat in het weergegeven ‘informatiekruis’.

Een dergelijk informatiekruis dreigt bij een ietwat grotere

Relatie informatiesystemen en processen

Reëel bedrijfsgebeuren (wie doet wat!)

Processen worden uitgevoerd in afdelingen

Systemen ondersteunen processen Bedrijfsprocessen

Informatiesystemen

Organisatie (afdelingen)

Dataklassen Data worden veredeld door systemen

Relatie informatiesystemen en dataklassen

Afdelingen leveren input voor de data verzamelingen

Gegevensorganisatie (wie levert welke gegevens)

Figure 1 Het BSP-' informatiekruis' 2

Informatie over dit onderwerp is vooral gehaald uit een artikel over de BSP-methode (BSP: ‘Business Systems Planning’) door drs. G.M.W. Sebus, in ‘Informatie’, jrg. 23, 1981, blz. 142-152;

2


organisatie als snel ‘erg groot’ te worden als men processen e.d. ver opsplits t in deelprocessen (letterlijk ‘erg groot’ als het op een groot vel papier moet worden geschreven). Men zal dan processen net groeperen 3. Als voorbeeld bespreken we hierna ‘deel-opvullingen’ van zo’n informatiekruis en hun betekenis. In dit ‘informatiekruis’ staat een ‘U’ voor ‘ use’ (gebruik van bestaande gegevens van die dataklasse) en ‘C’ voor ‘ create’ (maak een nieuw gegevensrecord van deze dataklasse). Een ‘X’ linksboven in het informatiekruis betekent, dat er een informatiesysteem (‘A’ .. ‘F’) bestaat, dat een brugfunctie heeft tussen de ruwe gegevens in de database en de eisen van het betreffende bedrijfsproces 4. Zo is uit de gegeven invulling van dit informatiekruis op te maken, dat het proces ‘Besturen van productie’ blijkbaar ondersteund wordt door het informatiesysteem ‘D’, dat bij zijn ‘gegevensveredelingsactiviteiten’ gebruik maakt van artikelen- en ordersgegevens en daarbij zelf productieplangegevens aanmaakt.

Onderzoeken van de markt Werven van klanten

X X X

Behandelen van orders X X X

Processen worden uitgevoerd in afdelingen

Besturen van productie Factureren ..... Bedrijfsprocessen

A

B

C

D

E

F Informatiesystemen

Organisatie (afdelingen)

Dataklassen ...’) ..... Klanten (‘gegevens over

C U

C U U C U

U U U C U U

U

Afdelingen leveren input voor de data verzamelingen

Orders Produktieplan Artikelen ……

Figure 2 ' Ideale' relatie tussen processen, systemen en dataklassen (BSP)

Werven van klanten .....

C

Behandelen van orders Besturen van productie

U

Factureren .....

C U C U U

.....

Artikelen

Orders

Bedrijfsprocessen

Klanten

...’) .....

(‘gegevens over

Uit het voorgaande komt sterk het beeld naar voren, dat het de bedrijfsprocessen zijn die van belang zijn bij het toegrijpen op data en dat de opdeling van die processen over afdelingsorganisaties (en personen) ‘buiten zicht’ kan blijven en voor dit overzicht eigenlijk niet zo essentieel is! 5 (Uiteraard zal men toch in kaart willen brengen, waar –op welke afdelingen- die bedrijfsprocessen zich afspelen en eventueel door wie het werk wordt uitgevoerd.)

Produktieplan

Als we de overgang processen => organisatie => dataklassen in één stap doen, dan zouden we bijvoorbeeld de volgende situatie kunnen krijgen, waarin de duidelijk kunnen zien (zie bijgaande figuur), welke data gecreëerd en gebruikt worden Dataklassen door de afzonderlijke bedrijfsprocessen.

U U U

Figure 3 Direct verband tussen processen en dataklassen

3

Uit een BSP-bespreking in het boek ‘Bestuurlijke informatiesystemen en automatisering’ door Prof. Dr. T.M.A. Bemelmans halen we: ‘BSP beveelt in dit verband sterk aan het aantal bedrijfsprocessen beperkt te houden tot zestig à zeventig. Eenzelfde aanbeveling geldt ook voor het aantal te onderscheiden afdelingen, informatiesystemen en dataklassen.’ 4 Indien de opzet en ordening van processen (en ondersteunende informatiesystemen ‘A’ .. ‘F’) zodanig is, dat die ‘X’-en linksboven op de diagonaal staan, dan spreekt men wel van een ‘ideale relatie’. 5 N.B. Een opmerking van ‘een docent uit de praktijk’ was: ‘die BSP -aanpak is wat achterhaald; vaak krijg je, als je bij een bedrijf aankondigt dat je de BSP-methode wilt gebruiken, te horen: ja we weten al wel hoe die processen bij ons in elkaar zitten en door welke informatiesystemen ze ondersteund moeten worden ..’ (een vergelijkbare uitspraak staat ook min of meer zo in Bemelmans, blz 104 in de paragraaf met ‘Ervaringen van vandaag de dag.’).

3


9.3

De gebeurtenissen als uitgangspunt

Een andere, veelbelovende aanpak voor het ontwikkelen van informatiesystemen is daarom die via een analyse van de gebeurtenissen binnen een organisatie; van de processen die zich daar afspelen. Via zo’n procesanalyse is het niet alleen mogelijk te bepalen welke gegevens binnen die organisatie een rol spelen, maar ook welke operaties er op/met die gegevens mogelijk zijn, door wie die operaties worden uitgevoerd (en geautoriseerd zijn) en welke ‘user interfaces’ er op die plek in de organisatie nodig zijn.

9.3.1

Het logboek met registratie van gebeurtenissen

Als we een logboek zouden hebben bijgehouden over welke gebeurtenissen zich binnen ons UoD (=Universe of Discourse ; lees: onze organisatie) successievelijk hebben voorgedaan, is daarmee voor elk moment in de tijd exact de populatie van een database te reconstrueren. In zo’n l ogboek moeten dan 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.6 Als we bijvoorbeeld op een stadhuis een logboek van alle relevante gebeurtenissen met betrekking tot de bevolkingsregistratie zouden hebben, zoals bijvoorbeeld: ‘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., dan achteraf uit de registratie van deze gebeurtenissen voor elk moment uit het verleden (en uiteraard het heden) de inhoud van de database van het bevolkingsregister van die stad te reconstrueren.

9.3.2

Een aanpak via ‘objecten’

Zo’n gebeurtenissen -analyse (lees: procesanalyse) kunnen we uitvoeren door allereerst te bepalen welke objecten (beter: objecttypen) binnen die organisatie een rol spelen. Onder een object verstaan we een reëel of conceptueel ‘iets’, waarvan we een of meer (gegevens -) waarden (lees ook: kenmerken, eigenschappen, attribuutwaarden of toestandswaarden) willen of kunnen vastleggen/opslaan en dat een ‘gedrag’ heeft. Dat ‘gedrag’ van een object wordt (vooral) bepaald door de wijze waarop veranderingen in de attribuutwaarden van dat object tot stand komen. 7 Verderop in dit hoofdstuk zal duidelijk worden, waarom we hier liever abstraheren en kunnen stellen, dat dat ‘gedrag’ van een object bepaald wordt door de set van mogelijke acties op het object. Let op het verschil tussen het begripsmatige objecttype (hier: Persoon) en de concrete objecten van dat type (hier: P1, ... P6). We moeten vervolgens bepalen wanneer (en uiteraard: waar en door wie) objecten ontstaan (create), wanneer (waar/door wie…) hun eigenschappen veranderen ( update) en/of opgevraagd worden en wanneer (waar/wie …) hun ‘bestaan’ ophoudt ( destroy); of in andere bewoordingen: bepalen op welke wijzen de acties op zo’n object mogelijk zijn. Zo zouden we in voorgaande beschrijving van vastgelegde gebeurtenissen met betrekking tot een bevolkingsregistratie daarin objecten van het objecttype ‘Persoon’ kunnen onderkennen, waarbij een persoon-object (bij geboorte) gecreëerd kan worden, gedurende zijn leven meerdere keren kan verhuizen (een ‘update’-actie) en uiteindelijk zal overlijden. (Of dit laatste als een ‘update’- of een ‘destroy’-actie gezien moet worden, is afhankelijk van de doelstelling van die bevolkingsregistratie. Moet het desbetreffende persoonsobject (lees desgewenst: de gegevens ervan) verwijderd worden of moet ergens van die persoon aangegeven worden, dat hij/zij is overleden? 8).

6

Voor een nadere beschouwing over (de rol van) logboeken zie: ‘Object-Oriented Modeling based on Information Grammars’ door Paul Frederiks (KUN; proefschrift, 1997). 7 Soms wordt een ‘object’ slechts gedefinieerd als ‘iets’ wat een gedrag heeft (lees: gedra gingen die toestandsveranderingen doorvoeren). 8 Merk op, dat we hier alleen hebben gesproken over een object van het type Persoon en de acties erop resp. het gedrag ervan en dat conceptueel geheel duidelijk is, wat er met het betreffende object gebeurt (zonder dus over gegevens/attributen ervan te praten).

4


De al eerder genoemde gebeurtenissen betekenen dus acties op objecten. Als we in een logboek zouden hebben bijgehouden welke acties op welke objecten zich successievelijk hebben voorgedaan, is daarmee voor elk moment in de tijd exact de populatie van een database te reconstrueren. Acties op objecten hebben veranderingen in de eigenschappen van die objecten tot gevolg. Acties hebben over het algemeen te maken met (/zijn gevolg van) invoer-functies van een informatiesysteem. Uit ‘de KISS-methode’ 9 (zie b.v. het boek ‘Object Orientation; the KISS method’ door Gerald Kristen; 1994) halen we het hiernaast weergegeven schema. Daaruit komt ook het taalgebruik naar voren, dat ‘acties op objecten’ ‘operaties op attributen’ van die objecten tot gevolg hebben. Volgens dit schema kan een uitvoer-functie het antwoord op informatievragen rechtstreeks van geïnspecteerde objecten ontvangen.

Input functions Actions Operations Attributes Objects Output functions

Figuur 4 Structuur van een object-georiënteerd IS

Let op de weergegeven ‘inkapseling’ van de operaties op attributen. Zo hebben we tot nu toe in ons voorbeeld over Persoon-objecten het alleen over de mogelijke acties op Persoon-objecten gehad zonder dat we in detail erop zijn ingegaan wat dan precies voor gegevens(/attribuut)waarden moeten worden ingevuld. En toch is het ons duidelijk waar het in deze situatie om gaat. 10 Als we in dit voorbeeld van het bevolkingsadministratie-systeem de begripsmatige actie ‘verhuizen’ van een Persoon willen implementeren, dan zullen we nog in detail moeten bepalen welke operaties op welke manier op welke attributen van het betreffende Persoon-object moeten werken om de gewenste verhuis-actie in de opgeslagen waarden binnen het informatiesysteem doorgevoerd te krijgen. Aan de hand van deze gegeven figuur kunnen we ons ook gemakkelijk voorstellen, dat het mogelijk is dat bij een bepaalde ‘Input function’ meerdere ‘acties’ vallen. Dit zal meestal consequenties voor de user interface van die invoerfunctie hebben. Als we in ons bevolkingsadministratie-voorbeeld ook de gezinssamenstellingen willen bijhouden (via een apart objecttype ‘Gezin’), dan zal vaak gelijktijdig met een actie op een object van het type Persoon ook een (waarschijnlijk meestal een update-) actie op een object van het type Gezin moeten plaatsvinden. In zo’n geval zal het voor d e 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.

9.3.3

Het object life model : de levenscyclus van een object

We kunnen schematisch aangeven hoe de samenhang is tussen acties op objecten. We zullen dat eerst voor een specifiek geval doen, daarna ‘in het algemeen’ en tot slot voor ons bevolkingsadministratie voorbeeld. Stel je allereerst voor dat binnen een bedrijf (na een levering of verkoop) een rekening opgemaakt en naar de klant toe verstuurd moet worden. Die rekening zal (hopelijk) een keer betaald Rekening worden; het kan zijn dat tenslotte die rekening òf ‘vernietigd’ moet worden (maar meestal vindt de belastingdienst dat niet zo prettig), of ‘gearchiveerd’. Schematisch Then Then Then kunnen we het hele gebeuren (met dat archiveren) als volgt weergeven (zie Opmaken Archiveren Versturen Betalen bijgaande figuur). De (ellipsachtige) cirkel staat daarbij voor Figuur 5 De levenscyclus van een ' rekening' -object een objecttype, de vierkantjes voor ‘acties’, 9

‘KISS’ : Kristen Information and Software Services. Als het verschil tussen een ‘object’ en zijn ‘attributen’ je niet duidelijk is, dan kun je dat ‘tot op bepaalde hoogte’ vergelijken met het bij de eerder in deze cursus bij het (ORM) Informatie Analyse-deel besproken verschil tussen de ‘non lexical objects’ (de ‘entiteiten’) en de ‘ lexical objects’ (de ‘value-typen’). 10

5


de gestippelde pijl voor een initialisatie van een object van het bewuste objecttype en de continue pijlen geven aan welke acties achtereenvolgens op dat object (kunnen..) werken. Een ‘vervolgactie’ (zoals ‘Betalen’) kan uiteraard pas plaatsvinden als de voorafgaande actie uit de levenscyclus (hier: ‘Versturen’) al eerder is uitgevoerd (er zitten dus een soort impliciete beperkingsregels in dit schema). We geven hier een overzicht van de in deze ‘object life model’ schematechniek meest gebruikte symbolen: 11

objecttype

actie

vervolg actie

herhaling van acties

decompositie van acties

keuze tussen acties

parallelle acties

objecttype initialisatie

herhaling/keuze van acties

Figuur 6 Meest gebruikte symbolen in de object life model -schematechniek

We kunnen ‘in het algemeen’ de volgende algemene levenscyclus voor een object opstellen: • het object wordt aangemaakt (Create); • tijdens ‘het bestaan’ van het object zijn er -al dan niet in een herhaling- meerdere Updateen/of Opvraag(/inspectie)-acties op mogelijk; • (niet per se noodzakelijk): het object wordt verwijderd (Destroy). Schematisch is dit in de figuur hiernaast aangegeven. 12

Object type

Repeatedly Then

Then

Destroy

Create i

j

k

l

Acties i, j, k, l, ..

Figuur 7 De algemene levenscyclus van een object

We hebben hiernaast deze schematechniek Persoon toegepast op de eerder gebruikte levenscyclus van een object van het Repeatedly Persoon-type, waarbij Then Then we tevens de mogelijke acties ‘huwen’ en ‘scheiden’ en diverse wijzen van ‘verhuizen’ * * introduceren. Uiteraard zal die tweede Huwen Scheiden Verhuizen naar Overlijden Verhuizen van Aanmelden Verhuizen genoemde actie bij geboorte binnen stad andere stad buiten stad (‘scheiden’) alleen *) extra constraint: scheiden kan kunnen optreden na dat slechts bij een gehuwd persoon de eerste is gebeurd. Dat Figuur 8 Levenscyclus ' Persoon' -object binnen bevolkingsadministratie-systeem levert ons het getoonde schema voor de levenscyclus voor een ‘Persoon’-object in het bevolkingsadministratie-systeem.

11

Afkomstig uit het eerder genoemde proefschrift van Paul Frederiks. Bij twijfel over het precieze verloop van een object live cycle kun je uiteraard terugvallen op de timestamps in het logboek van de geregistreerde gebeurtenissen binnen die organisatie. 12

6


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

9.3.4

Inventarisatie van (potentiële) objecttypen via zinsanalyse

Om te komen tot een compleet overzicht binnen ons Universe of Discourse van objecttypen en bijbehorende acties, bestaan meerdere mogelijkheden. De meest voor de hand liggende aanpak is die via een analyse van de verwoordingen van de gebeurtenissen zoals die in een logboek staan vermeld. Als er geen concreet logboek bestaat, dan is het misschien mogelijk te komen tot een ‘verzonnen’ logboek, uitgaande van de vraag: “Wat kan er allemaal gebeuren in ons UoD en wat zouden we er dan van willen vastleggen? Een andere mogelijke aanpak voor het bepalen van de binnen een organisatie bestaande objecttypen en hun gedrag is, door een beschrijving van de bedrijfsprocessen van die organisatie te analyseren. Ruwweg kunnen we proberen de objecttypen te ontdekken door in die beschrijving van elk daarin voorkomend zelfstandig naamwoord te bepalen of van het achterliggende concept (waar dat zelfstandig naamwoord naar verwijst) gegevens moeten worden opgeslagen. Indien dat zo is, dan hebben we een ‘kandidaat objecttype’ gevonden (dat we verder moeten bekijken om te bepalen of het een écht objecttype is). Het gedrag van die objecttypen is af te leiden uit de bij zinsanalyse aangetroffen werkwoordsvormen. In het algemeen zijn we daarbij niet zo geïnteresseerd in vormen van werkwoorden, die een (stabiele) situatie aanduiden of opvragen, zoals ‘zijn’, ‘hebben’ etc., maar net wel in de werkwoorden, die een actie aanduiden die veranderingen in de eigenschappen (…attribuutwaarden) tot gevolg hebben. Over het algemeen zullen we ons baseren op zinnen in de actieve vorm (zoals: ‘Persoon P1 schrijft rekening R1 uit’) en niet op zinnen in de passieve vorm (zoals : ‘Rekening R1 wordt uitgeschreven door Persoon P1’). Bij onze analyse baseren we ons bij voorkeur op elementaire zinnen. Zelfstandige naamwoorden verwijzen echter ook vaak naar kenmerken. Als we bijvoorbeeld binnen ons UoD ontdekt hebben, dat ‘Persoon P1 de hond H1 aanschaft’, dan hoeft dat niet te betekenen, dat we hier met twéé verschillende objecttypen (Persoon en Hond) van doen hebben. Afhankelijk van de situatie kunnen we hier met slechts één objecttype te maken hebben; dat kan zowel met het objecttype ‘Persoon’ zijn (met als een van zijn kenmerken/attributen dat nu die persoon de hond H1 ‘heeft’) als met het type ‘Hond’ (met als een van zijn kenmerken, dat de eigenaar persoon P1 is). We vragen ons in dit voorbeeld dan af of we van de hond of van de baas/bazin eigenschappen willen kunnen opvragen en/of veranderen. Daaronder vallen dan vragen als: “Wie is (momenteel) de baas van de hond?” versus “Is deze persoon momenteel baas van een hond en zo ja: van welke?”. Uiteraard moeten we erop bedacht zijn, dat in een omschrijving ook synomiemen kunnen voorkomen (woorden met dezelfde betekenis). In zo’n geval nemen we slechts één van de synonieme zelfstandige naamwoorden als ‘kandidaat objecttype’. Van de gevonden potentiële objecttypen wordt gaandeweg bepaald of zij inderdaad van belang zijn in de betreffende organisatie. Na een paar iteratieslagen krijgen we meestal een consistent beeld van de in de gegeven situatie van belang zijnde objecttypen. Handige -niet altijd geldende- vuistregels hierbij zijn: • als we van “iets” (lees: zo’n ‘kandidaat object’/het begrip ‘achter’ het zelfstandig naamwoord) bemerken, dat er méérdere eigenschappen van vastgelegd moeten worden (bijvoorbeeld van een hond: naam, ras, kleur, geboortejaar of van een persoon: naam, adres, lengte, gewicht), dan kunnen we er welhaast zeker van zijn met een ‘object’ te doen te hebben; • ook hebben we (vrijwel zeker) met een object te doen, als we van zo’n “iets” (later) eigenschappen (/attribuutwaarden) willen kunnen veranderen (en uiteraard registreren in ons informatiesysteem). Voor elk object (van een bepaald type) zullen we minimaal zoveel attribuutwaarden moeten registreren, dat het mogelijk is dat object daarmee te kunnen identificeren. Meestal zullen we van zo’n object nog méér gegevens dan alleen de identificerende attribuutwaarde(n) willen vastleggen, maar bij een eerste analyse voldoet vaak het vastleggen van die identificerende attribuutwaarde(n) van een object(type) én de acties die eigenschappen van een object kunnen wijzigen (d.w.z. create-, updateen destroy-acties). Ook de opvraag(/inspectie)-acties laten we bij zo’n eerste analyse vaak achterwege.

7


9.3.5

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.

Analyse Voor het uitvoeren van een analyse voor het bepalen van de binnen deze boekhandel te herkennen objecttypen en hun gedrag zijn de volgende ‘formulieren’ beschikbaar: • een kassabon met verkoopgegevens; • een klein deel van een lijst met catalogus-informatie over boeken, gesorteerd op auteursnaam; • een deel van een magazijn/inventarislijst, waarop aangegeven staat hoeveel exemplaren van elk boek op dat moment in het magazijn aanwezig waren en in de winkelrekken zou moeten zijn; • aanvulgegevens (deels) van een bepaalde dag • een deel van een bestellings/leveringslijst

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

Figure 9 Voorbeeld kassabon Opmerkingen bij de getoonde ‘kassabon’: 1) Let er bij op, dat niet de identificerende ISBNnummers voor de aanduiding van de verkochte boeken staan vermeld, maar de titels. Dit gebeurt Figuur 6 Voorbeeld kassabon voor de ‘klantvriendelijkheid’ vanwege de grotere leesbaarheid. 2) Het maakt voor deze mini-casus niet uit, of er voor deze aankoop nu één totale kassabon of twéé (of zelfs drie) aparte kassabonnen (voor elk soort boek of zelfs voor elk exemplaar) worden gemaakt. Ook dit is weer een uitvloeisel van het ‘klantvriendelijke karakter’. 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

Figure 10 Deel gebruikte lijst met catalogusgegevens van verkrijgbare boeken

De gegevens uit deze catalogus zijn (vrijwel) ‘statisch’ van aard; dit is géén gebeurtenisregistratie! Figuur 7 Deel gebruikte lijst met catalogusgegevens van verkrijgbare boeken 8


Voorraadsituatie d.d. 6-12-‘99 auteur Date, C.J.

ISBN-nr

aantal in voorraad in magazijn

titel

0-201-96426-0


3

0-201-82458-2


1

in winkelrek 2

1

Figure 11 Deel van de voorraadstaat zoals opgemaakt op een bepaalde datum

Merk bij deze voorraadstaat op, dat ook deze staat géén gebeurtenisregistratie is; hij is ontstaan omdat Figuur 8 éénmaal per maand de voorraad(staat) opgemaakt wordt. Die actuele voorraadstaat wordt ter controle van de aanwezige boekenvoorraad telkens gegenereerd en wordt daarna niet bewaard. Bestel- / leveringsgegevens ISBN-nr

besteldatum

Uit de bestellings/leveringsstaat blijkt, dat het ‘een poos’ kan duren, voordat een geplaatste bestelling inderdaad door de groothandel wordt geleverd. Hier wordt wél een registratie van gebeurtenissen weergegeven en bewaard.

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

Figuur 12 Deel van de bestellings/leveringsstaat

Aanvulgegevens van woensdag 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

Figure 13 Deel van de aanvulgegevens zoals een bepaalde datum gedaan.

Blijkbaar worden ook deze aanvulgegevens per dag geregistreerd en als in een logboek van Figuur 4 Deel bewaard. van de aanvulgegevens op een bepaalde datum gebeurtenissen Merk ook op, dat er afleidbare waarden aanwezig zijn; de voorraadsituatie (zowel in het magazijn als in de winkelrekken) is immers af te leiden uit de combinatie van verkoop-, aanvul- en leveringsgegevens. We kunnen die laatste drie gegevens zien als in een logboek neergeschreven gebeurtenissen, waaruit de voorraadsituatie op elk moment van verleden+heden te reconstrueren is. Ook al om practische redenen (het zou immers veel computertijd kosten om aan de hand van (tien/honderd-) duizend gebeurtenisrecords steeds weer opnieuw de voorraadsituatie te reconstrueren) is het geen probleem deze afleidbaarheid mee te nemen in ons model.

Op zoek naar objecttypen binnen dit UoD We speuren de situatieschets af op zinvolle zelfstandige naamwoorden, die ons op het idee van ‘hé, dit zou wel eens een objecttype kunnen zijn’ kunnen brengen. Bekijken we de eerste paar zinnen uit die beschrijving: 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.

Tot ‘zinvolle zelfstandige naamwoorden’ behoren beslist nìet zaken als ‘boekhandel’, ‘activiteiten’, ‘plaats’, ‘winkel’, ‘manier’, ‘rekken’, ‘klant’, ‘geld’ etc.. Van geen van deze zaken willen we in ons UoD gegevens opslaan. Wèl interessant als kandidaat objecttypen lijken: ‘Boek’ (of vanwege eigenlijk foutief taalgebruik misschien beter: ‘Exemplaar’), waarbij (zie de werkwoorden in hun gebruikte vorm) ‘ verkopen’ en ‘etaleren’ op acties kan slaan (“zijn ze geëtaleerd/verkocht?”). Hier zit echter een probleem; verandert er iets in de eigenschappen van een boek als het geëtaleerd of verkocht wordt en zo ja: welke boek-eigenschap verandert er dan en hoe? Een probleempje om te onthouden en om verderop in onze analyse over na te denken…

9


We vervolgen: 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.

Interessant als kandidaat objecttypen lijken: ‘verkoopgegevens’ (maar als we ons afvragen naar wat er achter dat ‘gegevens’ zit, dan komen we op het begrip ‘ Boekverkoop’) en ‘Bestelling’ (met als acties: ‘plaatsen’ en ‘afleveren’); het ‘leveringsgegevens’ lijkt nauw verweven met (geleverde) ‘bestellingen’ (zie voor deze suggestie ook de getoonde figuur over ‘Bestel-/leveringsgegevens’). Interessant voor wat betreft ‘acties’ lijkt bovendien: het ‘aanvullen’ (in de winkelrekken) van boeken. In:

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.

Het vaker voorkomen van het (zelfstandig naam-) woord ‘aanvulgegevens’ (plus het bestaan van een getoonde- ‘gebeurtenissenlijst’ daarvan) duidt op het bestaan van een objecttype ‘ Aanvulling’. We vervolgen: 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, aanvullende exemplaren.

De context suggereert hier de volgende (bedachte) zelfstandig naamwoorden ‘Magazijnvoorraad’ en ‘Winkelvoorraad’; van beiden blijken gegevens te worden bijgehouden (zie ook de figuur met het voorraadoverzicht). Maar …het worden dan wel objecttypes met ieder slechts één (aantal -) attribuut. Dat is een veeg teken… En welke acties werken er dan op, waardoor dat ‘aantal’-attribuut verandert? Die aantallen veranderen enerzijds door de verkoop-actie van een boek en anderzijds door een aflever-actie van een bestelling. We kunnen nu mede het eerder gesignaleerde knelpunt rond het mogelijke objecttype ‘Boek’ oplossen, door het objecttype ‘Boek’ als extra attributen te geven: ‘voorraad-in-winkel’ en ‘voorraad -inmagazijn’. We hebben dan tevens een update-actie op ‘Boek’ gevonden: het verkopen van een boek vermindert het voorrraad-aantal in de winkel, het afleveren van een bestelling verhoogt het voorraadaantal in het magazijn en een ‘aanvulling’ heeft een (a)symmetrisch effect op deze beide aantallen. Aanvullende aspecten voor onze analyse: • ‘etaleren’ van boeken betekent voor ons UoD eigenlijk: het doen van een ‘Aanvulling’ vanuit het magazijn van de winkelrekken, waarbij zowel de magazijnvoorraad als de winkelvoorraad van het betreffende ‘Boek’ verandert; • de actie ‘verkopen’ bij het objecttype ‘ Boek’ is in werkelijkheid (een initiëren van) een ‘Boekverkoop’ en tevens een verminderen van de winkelvoorraad van dat boek; • het gesuggereerde objecttype ‘Boek’ heeft dus nu een aantal update-acties gekregen; • het op de koopbon vermelde: ‘ruilen binnen 2 weken na aankoopdatum’ betekent in werkelijkheid het ‘te niet doen’ van een ‘ Boekverkoop’ en weer ‘ophogen’ van de winkelvoorraad van het ‘ Boek’ • een benodigde ‘Aanvulling’ zal ook nodig zijn na het constateren van de verdwijning van boeken (maar dat vereist verder niets extra’s van attributen of update -acties). Samenvattend hebben we als kandidaat objecttypen (met mogelijke acties erop) verzameld: Objecttype Actie ‘Boek’ invoeren en verwijderen (uit de boekencatalogus), boekverkoop realiseren en annuleren en afleveren van een bestelling en het aanvullen uit het magazijn van de boeken in de winkelrekken; ‘Boekverkoop’ realiseren (‘create’) en (binnen 2 weken) ‘annuleren’ (‘destroy’)

10


plaatsen (‘create’) en afleveren aanvullen (een create)

‘Bestelling’ ‘Aanvulling’

Bij de acties in dit overzicht zijn geen verder benodigde ‘inspectie’-acties opgenomen.

De diverse object-levenscycli We geven nu schematisch de verschillende levenscycli weer van de in dit Universe of Discourse aangetroffen objecttypen: ‘Boek’, ‘Boekverkoop’, ‘Bestelling’ en ‘Aanvulling’.

Boek

Repeatedly

Then

eventueel ooit

Invoeren in catalogus (create) verkopen

aanvullen afleveren annuleren (winkelrek) (bestelling ) verkoop

Aanvulling

Boekverkoop

Then

verkopen (create)

Verwijderen uit catalogus (destroy)

Seldom

Bestelling

Seldom

annuleren verkoop (destroy)

Then

aanvullen (winkelrek) (create)

plaatsen bestelling (create)

afleveren (bestelling)

Voor die verschillende object life cycles kunnen we concluderen, dat: a) de actie ‘afleveren bestelling’ zowel in de cyclus van ‘ Bestelling’ als van ‘Boek’ zit b) de actie ‘verkopen’ zowel in de levenscyclus van ‘ Boekverkoop’ (Creatie!) als van ‘Boek’ zit (hetzelfde geldt voor de actie ‘annuleren verkoop’ (binnen 2 weken…)) c) de actie ‘aanvullen’ zowel in de cy clus van ‘Aanvulling’ (Creatie!) als van ‘Boek’ zit.

Het hoeft ons niets te verbazen, dat het voor een boekhandel ongetwijfeld centrale objecttype ‘Boek’ inderdaad als een spin in het web lijkt te zitten en met bijna alle acties, te maken heeft. We kunnen de acties a), b) en c) alledrie beschouwen als ‘binaire acties’ (gekoppeld aan twéé objecttypes) terwijl alle andere voorkomende acties ‘unair’ zijn (ze werken op één objecttype).

11


We combineren de gegeven object life cycles nu als volgt in een Object-action-involvement-schema: Verwijderen uit catalogus (destroy)

Invoeren in catalogus (create)

verkopen

eventueel ooit

Seldom

annuleren verkoop

Boek

Aanvulling

aanvullen (winkelrek)

Boekverkoop

afleveren (bestelling )

Bestelling plaatsen (bestelling) (create)

Legenda: xxx

objecttype

‘normale’ actie

create-actie

destroy-actie

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

In dit schema staan ‘rechthoekjes’ voor het aangeven van acties en ‘ellipsen’ voor het aangeven van objecttypen. Verwar dit schema niet met een conceptueel schema uit ORM ! Acties die ‘initiëren’ ( Create) zijn in het schema gestippeld aangegeven, terwijl ‘Destroy’-acties gestreept zijn. 13 Alle ‘open’ (lees: ‘blanco’) rechthoekjes slaan op Update- (of Select-) acties, die alleen gedurende de ‘tijd van leven’ van het betreffende object kunnen worden uitgevoerd. Aan de hand van dit schema is in één oogopslag te zien, dat de acties ‘verkopen’, ‘annuleren verkoop’, ‘aanvullen (winkelrekken)’ en ‘afleveren bestelling’ allen effect hebben op de life cycle van objecten van telkens twéé verschillende typen. Alnaargelang het woordgebruik dat we willen hanteren, kunnen we zeggen, dat we hier te maken hebben met ‘elementaire acties’ of met ‘transacties’, waarvoor geldt, dat zo’n combinatie van meerdere acties (liefst onmiddellijk achter elkaar) moet worden uitgevoerd om de database integer te houden. 14 Pas na het doorvoeren van alle bij zo’n ‘ elementaire actie’ behorende acties zou aan het databasesysteem het commando ‘Commit Work’ moeten worden gegeven. Als na het doorvoeren van slechts een deel van de benodigde gecombineerde acties plotseling de elektriciteitsvoorziening zou uitvallen, dan zouden we een opdracht ‘Rollback Work’ kunnen geven om de database-integriteit te herstellen 15. Dit voorkomen van acties die op meerdere objecttypen werken zal waarschijnlijk ook zijn uitwerking hebben voor de user interface voor deze invoerfuncties (!). Waarschijnlijk zal de gebruiker in het behandelde voorbeeld wensen, dat bij het invoeren van ‘Aanvulling’-gegevens, dat op hetzelfde moment (lees: in hetzelfde window) ook de ‘Boek’-gegevens (zoals titel, schrijver en voorraad op zowel de winkelrekken als in het magazijn) worden weergegeven.

13

Impliciet is uit het schema op te maken, dat een ‘annuleren verkoop’ (destroy!) alleen kan optreden als het betreffende verkoop-object al eerder gecreëerd is (kortom: als het boek inderdaad al eerder verkocht is). 14 De complexiteit van deze verstrengelde acties heeft uiteraard ook te maken met de reeds eerder aangeduide afleidbaarheid tussen verkoop-, leverings- en aanvulgegevens enerzijds en voorraadgegevens anderzijds. 15 Bij een goed RDBMS zal na ‘vastlopen’ of een elektriciteitstoring na opnieuw opstarten automatisch een ‘Recover’-activiteit uitgevoerd worden.

12


9.3.6

Objecten: data + bijbehorende operaties

Als we ons een ‘object’ in het algemeen voorstellen als ‘iets’ met gegevens(velden) en mogelijke operaties op de complete objecten zèlf (voor het creëren of verwijderen) of op hun gegevensvelden via procedures (in object oriented terminologie: ‘methodes’), dan kunnen we ons de genoemde objecttypen als volgt opgebouwd voorstellen:

Boek

Boekverkoop

Data: (Attributen)

Data: (Attributen) Identificerend: ISBNnr + aantal + datum + uuraanduiding + verkopernr

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

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

...(+ evt. resterende data)

Methodes: verkopen annuleren verkoop ……

Aanvulling

Bestelling

Data: (Attributen)

Data: (Attributen)

Identificerend: ISBNnr + aantal + aanvuldatum ….(+ evt. resterende data)

Methodes: aanvullen (winkelrek) ……

Als we alleen kijken naar de identificerende attributen van de objecttypen ‘Boekverkoop’, ‘Aanvulling’ en ‘Bestelling’ -waar steeds een time stamp inzit- dan wijst dat in de richting van een logboek van gebeurtenissen.

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

Methodes: plaatsen afleveren ……

In dit overzicht komt extra goed naar voren, dat de bij een objecttype behorende methodes toegrijpen op de attributen om de waarden daarvan te wijzigen of te raadplegen. De Boek-methode ‘verkopen’ zorgt ervoor, dat de waarde van het attribuut ‘aantal -in-winkelrek’ ge update (hier: met 1 verminderd) zal worden.

9.3.7 1.

Mogelijke uitbreidingen: gebruikers/ bedrijfsprocessen/ database-typen

Indien we bij onze voorgaande analyse niet alleen zouden bekijken welke objecten + acties daarop voorkomen, maar die analyse uit zouden breiden met het opspeuren van antwoorden op vragen als: ‘Welke gebruikers zijn geautoriseerd om Boek een bepaalde actie op een object te laten Data: uitvoeren?’ en ‘Bij welk(e) Identificerend: ISBNnr bedrijfsproces(sen) hoort een bepaald aantal-in-magazijn object+acties?’ dan wordt het eenvoudig aantal-in-winkelrek om uit het eerder besproken ….(+ evt. resterende data) ‘objecttype/acties’-schema een variant op het eerder in dit hoofdstuk besproken Methodes: Geautoriseerd: BSP-informatiekruis te destilleren. invoeren in catalogus administrateur (?) Als een intermediair product daarvoor verwijderen uit catalogus administrateur (?) hebben we hiernaast het eerder bepaalde verkopen verkopers annuleren verkoop verkopers Boek-objecttype verder uitgewerkt, door aanvullen (winkelrek) magazijnbeheerder achter de object-methodes aan te vullen afleveren (bestelling) magazijnbeheerder wie binnen de boekhandel die methodes …… kan/mag gebruiken.

13


2.

3.

Ook kan, mede aan de hand van de diverse ‘object life cycles’, een workflow-schema worden opgesteld: “Hoe bewegen objecten zich (lees: hoe ‘lopen’ documenten) door de organisatie?” (zie als eenvoudig voorbeeld hierbij het schema over de levenscyclus van een ‘rekening’-object; dit zou dan uitgebreid moeten worden met ‘bij welk bedrijfsproces hoort elke actie thuis?’). Een aspect dat we nog niet hebben besproken is de wijze van gegevensopslag binnen het te ontwerpen informatiesysteem. Daar is in onze analyse nog niets over gezegd en die analyse is te beschouwen als ‘algemeen bruikbaar’. Je kunt dat opslag probleem zien als een technisch aspect, dat te maken heeft met het voor de implementatie te gebruiken databasesysteem en/of iets waar aan de hand van performance-criteria die van invloed zullen zijn op de keuze van dat te gebruiken databasesysteem. Dat kan bijvoorbeeld een relationeel databasesysteem zijn, maar ook een ‘object-databasesysteem’. Als we via ORM een informatieanalyse doen van de in deze boekhandel gebruikte formulieren, dan komen we allereerst op het hierna getoonde conceptuele schema: "Tijdstip"

Verkoper (Verk_naam)

Auteur (Aut_naam)

Uur

heeft als

op...om...

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

Titel Boek (ISBNnr)

heeft als Verkoopsprijs (Bedrag)

Uitgever (Uitg_naam)

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

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

is geleverd op

door toepassing van het relational mapping-algoritme vinden we vervolgens de hierna getoonde relationele databasestructuur:

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

waamee we eigenlijk terecht zijn gekomen bij dezelfde tabellen als we in dit hoofdstuk objecttypen hebben gevonden: ‘Boek’, ‘Verkoop’, ‘Bestelling’ en ‘Aanvulling’. Relationele gegevenstabellen (b)lijken overeen te komen met van-acties-ontdane-objecttypen. Deze conclusie geldt niet alleen voor het door ons geanalyseerde boekhandel-UoD, maar is (min of meer) ‘in het algemeen’ geldig. We hebben via (ORM -) informatieanalyse een efficiënte databasestructuur bepaald; door onze eerdere objectanalyse weten we nu ook precies welke acties er op de ‘records’ uitgevoerd kunnen worden….

14


9.3.8

Een tweede uitgewerkt voorbeeld: een bank-afdeling

Situatieschets Bij een bank wil men voor de afdeling ‘binnengekomen schriftelijke opdrachten’ een nieuw informatiesysteem ontwerpen voor het verwerken van de diverse soorten binnengekomen opdrachten. Binnen deze afdeling kunnen drie onderdelen onderscheiden worden. Van de te verwerken binnengekomen opdrachten worden de ‘directe betalingsopdrachten’ door het gelijknamige (eerste) onderdeel ‘directe betalingsopdrachten’ verzorgd; gegevens over ' welke opdrachtgever betaalt hoeveel aan welke ontvanger en waarvoor' worden via een toetsenbord rechtstreeks ingevoerd en opgeslagen in een centrale gegevensbank. Vóórdat de betalingsopdracht inderdaad wordt opgeslagen, wordt eerst uit de gegevensbank het saldo van de opdrachtgevende rekeninghouder opgezocht; als dat saldo te laag is om het over te maken bedrag van te kunnen betalen, wordt de opdracht níet uitgevoerd en wordt de opdracht direct teruggestuurd aan de klant met de vermelding ‘te weinig saldo’. Bij het (tweede) onderdeel ‘verwerking bijzondere opdrachten’ komen alle andere (schriftelijke) opdrachten die niets met de voorgaande ‘directe betalingen’ te maken hebb en terecht, zoals adreswijzigingen en aanvragen van klanten om een nieuwe set betaalopdrachtformulieren toe te sturen. Bij adreswijzigingen worden van de betreffende klant (lees: rekeninghouder) allereerst de in de centrale gegevensbank opgeslagen oude adresgegevens getoond en vervolgens wordt gelegenheid gegeven tot het invoeren van de gewenste wijziging (de veranderde gegevens moeten uiteraard ook in de gegevensbank terechtkomen). Bij de andere ‘bijzondere opdrachten’ moeten steeds (blanco) opdrachtformulieren aan een rekeninghouder worden toegestuurd; die verzending wordt door dit onderdeel verzorgd en gebeurt naar het van die klant in de gegevensbank opgeslagen adres. Geregistreerd wordt op welke datum dat verzenden gebeurde. Het (derde) onderdeel ‘opmaken en verzenden rekeningafschriften’ wordt iedere middag om 17:00u geactiveerd. Voor alle die dag verwerkte betalingsopdrachten worden rekeningafschriften naar de betrokken klanten gestuurd, waarop naast naam- en adresgegevens ook staat vermeld welke mutaties hebben plaatsgevonden en wat het nieuwe bankgirosaldo is.

Op zoek naar objecttypen binnen dit UoD Weer speuren we de gegeven situatieschets af, op zoek naar zelfstandige naamwoorden (of verwijzingen daarnaar) die ons op een idee brengen van ‘Hé, dit zou een objecttype kunnen zijn’. De eerder vermelde vuistregels (over ‘méérdere eigenschappen’ moeten vastleggen en daar veranderingen in kunnen aanbrengen) houden we daarbij uiteraard goed voor ogen. Als kandidaat objecttypen (met mogelijke acties erop) duiken dan op: Objecttype Actie ‘Rekening(houder)’ invoeren (‘create’) en verwijderen (‘destroy’; deze acties worden weliswaar niet vermeld in de situatieschets, maar ‘zoiets’ zal ooit moeten gebeuren), soms: terugsturen opdracht, saldo verhogen en saldo verlagen (bij het uitvoeren van een betalingsopdracht), adres wijzigen en misschien: toesturen betaalformulieren . N.B. afhankelijk van het taalgebruik in de organisatie kan dit objecttype beter ‘Rekening’ of ‘Rekeninghouder’ worden genoemd. ‘Betalingsopdracht’ invoeren (‘create’), uitvoeren betalingsopdracht en soms: terugsturen opdracht ; ‘Bijzondere opdracht’ invoeren (‘create’), adres wijzigen en: toesturen betaalformulieren ; ‘Rekening afschrift’ opmaken + versturen (‘create’) Een beter onder de loep nemen van deze kandidaat objecttypen levert de volgende vragen op: • ad ‘Bijzondere opdracht’ : oei; worden die opdrachtgegevens wel ingevoerd en opgeslagen/bewaard in het systeem, of wordt de betreffende opdracht (b.v. adres wijzigen) slechts uitgevoerd, zonder dat ergens geregistreerd wordt dat die adreswijziging is doorgevoerd? In het eerste geval lijkt het wél een geschikt objecttype te zijn, in het tweede geval nìet. Ook als van elk toesturen aan een rekeninghouder van een set blanco betaalformulieren wordt geregistreerd en bewaard op welke datum dit gebeurt, dan is dit een geschikt objecttype. • ad ‘Rekening afschrift’ : moet daar iets van geregistreerd worden en blijven of wordt zo’n rekeningafschrift eenmalig aangemaakt en verzonden en voor de rest ‘vergeten’? Bij de Postgirobank is het mogelijk om in geval van het vermist raken van een afschrift bij de Postbank

15


daarvan een kopie op te vragen. Blijkbaar blijft er ‘iets’ van geregistreerd, dus: dit lijkt inderdaad een geschikt objecttype.

Het Object-action-involvement-schema: Als we zonder meer een object-action-involvement schema voor dit UoD opmaken, dan blijkt, dat het ‘Rekeningafschrift’-objecttype geheel ‘los’ van de rest van het schema komt te hangen (zie figuur). Opmaken+Versturen

terugsturen opdracht

Rekeningafschrift

Seldom

* Betalingsopdracht

saldo verlagen *

saldo verhogen

uitvoeren opdracht

adres wijzigen

invoeren (create) invoeren (create)

*

Rekening (houder)

?

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

‘normale’ actie

create-actie

destroy-actie

Figure 15 Object action involvement-schema voor het bank-afdeling-voorbeeld

Ook lijkt volgens dit schema de Betalingsopdracht-actie ‘opdracht terugsturen’ niks van doen te hebben met het objecttype Rekening(houder) en dat terwijl voor het uitvoeren van die actie eerst het saldo van zo’n Rekening(houder)-object geraadpleegd moet worden. Ook voor het opmaken en versturen van een ‘Rekeningafschrift’ moet zowel een Rekening(houder)-object worden geraadpleegd (voor naam, adres etc.) als een (of meer) Betalingsopdracht-object(en) (de mutaties op het afschrift hebben immers te maken met die betalingsopdracht(en). Het lijkt daarom goed [om hier de samenhang beter te laten zien] om ook een aantal ‘inspectie’-acties in het object-action-involvement schema op te nemen (zie volgende figuur). We geven zulke inspectieacties aan met een vierkantje met een ‘o’-symbool in (denk maar aan de ‘o’ van ‘oogje’). Met het ‘?’-vraagtekentje in een van de actie-vierkantjes bij ‘toesturen betaalformulieren’ wordt hier bedoeld, dat het niet zeker is of dit een ‘update’-actie is op een object van het Rekening(houder)-type.

16


Opmaken+Versturen Rekeningafschrift Seldom

terugsturen opdracht * Betalingsopdracht

saldo verlagen *

saldo verhogen

uitvoeren opdracht

adres wijzigen

invoeren (create)

Rekening (houder)

?

toesturen betaalformulieren

Bijzondere opdracht

invoeren (create)

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 16 Object action involvement-schema voor het bank-afdeling-voorbeeld met inspectie-acties aangegeven

Ook in dit voorbeeld zal het voorkomen van acties die op meerdere objecttypen werken waarschijnlijk ook zijn uitwerking hebben voor de user interface voor deze invoerfuncties (!). Waarschijnlijk zal de gebruiker wensen, dat bij het invoeren van ‘Betalingsopdracht’-gegevens in hetzelfde window ook de NAW- en saldo-gegevens willen zien van zowel de rekeninghouder waar het bedrag van afgeboekt moet worden als van de rekeninghouder waar datzelfde bedrag bijgeboekt moet worden.

9.4

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

(of ook: Kristen' s Iteration, Sequence, and Selectionmethod) De KISS-methode is sterk gebaseerd op objectorientatie, maar ook zien we aspecten uit BSP terug. De bij de KISS-methode toegepaste zinsanalyse is veel stringenter dan wij eerder hebben toegepast. 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) én het: • meewerkend voorwerp (engels: indirect object) …verwijzen vaak naar een object(type)

17


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 IV gegevens/objecten zijn nodig? C o ntro l O utput func tio ns (toevoegen, veranderen, verwijderen, pro c e sse s opvragen van welke objecten?) De gebruikte schema-techniek voor het bepalen van de ‘informatie-architectuur’, die inzicht geeft in de wijze waarop objecten en acties gerelateerd zijn, is: het ‘information quadrant’.

I C o ntro l m o de l re spo nsibilitie s

Info rm atio n

O bje c ts

E m plo ye e s

Het ‘Information quadrant’ uit de KISSD ata methode wordt hierbij in zijn algemene vorm weergegeven. Taakverdeling en/of verantwoordelijkheden Ac tio ns van personen/afdelingen lijken hier weer een Info rm atio n arc hite c ture Autho risatio ns belangrijkere rol te zijn gaan spelen en de III II relatie tussen ‘objecten’ en ‘acties’ daaro p is Figure 17 Het ' information quadrant' v/d KISS -methode in een meer objectgerichte aanpak (zoals de KISS-methode zich pleegt te noemen) niet verbazingwekkend. Aandachtsvelden bij het opstellen van zo’n information quadrant: 1. control processes (alle activiteiten die ‘geregeld’/’gemanaged’ moeten worden) 2. employees (verantwoordelijkheden, taken, autorisaties) 3. actions (door wie en op wat?) 4. objects (wat gebeurt ermee en hoe is hun ‘toestand’)

Let er op, dat links in dit ‘information quadrant’ (pal links van het vetgedrukte woord ‘Objects’) alle binnen de organisatie bestaande objecttypen moeten voorkomen, zoals ‘Branch’ (-gegevens), ‘Client’ (-gegevens), etc..

X

X

X X

Cash management

X X X

X X

Credit control

X

Business planning

X

X

X

X X X

To register

X

X

X X

To open

X

X X X

To deposit

X

X

X

X X X

To withdraw

X

X

X X

X X

X

X

X

X

X

X

X

To install To count To close To de-register

Controller

Counter assistant

Actions

Cashier

Employees

Objects

General manager

Cash drawer

Account

Processes Client

Een uitgewerkt en hiernaast weergegeven voorbeeld hierover vinden we in het boek over de KISS-methode.

Client recruitment Relation management X

Branch

Mogelijke onderverdelingen / ‘contactvlakken’ in bovenstaand schema zijn: • bovenste helft (I+IV): ‘Controlling part’ <=> onderste helft (II+III): ‘Operating part’ • linker deel (III+IV): ‘Information system’ <=> rechterdeel (I+II): ‘Organization system’

X X X X

X

X X X

Figure 18 Het KISS- ' information quadrant' voor een bank

18

Deel 9: 9.1 Inleiding

Recommend Documents