Deel 9: 9.1 Inleiding

Transcriptie

1 Deel 9: Procesmodellering : objectgerichte analyse 9.1 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

2 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. Relatie informatie- Reëel bedrijfsgebeuren systemen en (wie doet wat!) processen Systemen ondersteunen processen Data worden veredeld door systemen Bedrijfsprocessen Informatiesystemen Dataklassen Organisatie (afdelingen) Processen worden uitgevoerd in afdelingen Afdelingen leveren input voor de data verzamelingen Een dergelijk informatiekruis dreigt bij een ietwat grotere Relatie informatie- Gegevensorganisatie systemen en dataklassen (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 ; 2

3 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 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. A B C D E F C U U C U C U C U U U U U U Onderzoeken van de markt Werven van klanten Behandelen van orders Besturen van productie Factureren..... Bedrijfsprocessen Informatiesystemen Organisatie (afdelingen) Dataklassen ( gegevens over... )..... Klanten Orders Produktieplan Artikelen Processen worden uitgevoerd in afdelingen Afdelingen leveren input voor de data verzamelingen Figure 2 ' Ideale' relatie tussen processen, systemen en dataklassen (BSP) 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 door de afzonderlijke bedrijfsprocessen. 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.) Dataklassen ( gegevens over... ) Bedrijfsprocessen Werven van klanten..... Behandelen van orders Besturen van productie Factureren Klanten C Orders Produktieplan Artikelen U C U U C U 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 -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

4 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 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 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, 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

5 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 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 worden; het kan zijn dat tenslotte die rekening òf vernietigd moet worden (maar meestal vindt de belastingdienst dat niet zo prettig), of gearchiveerd. Schematisch kunnen we het hele gebeuren (met dat archiveren) als volgt weergeven (zie bijgaande figuur). De (ellipsachtige) cirkel staat daarbij voor een objecttype, de vierkantjes voor acties, Rekening Opmaken Versturen Betalen Figuur 5 De levenscyclus van een ' rekening' -object Archiveren 9 KISS : Kristen Information and Software Services. 10 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 ). 5

6 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 vervolg actie decompositie van acties objecttype initialisatie actie herhaling van acties keuze tussen acties parallelle acties 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 Create Repeatedly i j k l Destroy Acties i, j, k, l,.. Figuur 7 De algemene levenscyclus van een object We hebben hiernaast deze schematechniek toegepast op de eerder Persoon gebruikte levenscyclus van een object van het Repeatedly Persoon-type, waarbij we tevens de mogelijke acties huwen en scheiden en diverse wijzen van verhuizen * * introduceren. Uiteraard zal die tweede genoemde actie Verhuizen van Aanmelden Verhuizen Huwen Scheiden buiten stad bij geboorte binnen stad ( scheiden ) alleen kunnen optreden na dat de eerste is gebeurd. Dat levert ons het getoonde schema voor de levenscyclus voor een Persoon -object in het bevolkingsadministratie-systeem. Verhuizen naar andere stad *) extra constraint: scheiden kan slechts bij een gehuwd persoon Overlijden Figuur 8 Levenscyclus ' Persoon' -object binnen bevolkingsadministratie-systeem 11 Afkomstig uit het eerder genoemde proefschrift van Paul Frederiks. 12 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. 6

7 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 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-, update- en destroy-acties). Ook de opvraag(/inspectie)-acties laten we bij zo n eerste analyse vaak achterwege. 7

8 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: 14:22 u Titel Mussen onder uw dak Aantal 2 Prijs 35,90 Introduction to Database Systems 1 87,35 Totaalbedrag 123,25 U werd geholpen door verk.nr: 3 Ruilen binnen 2 weken na aankoopdatum Opmerkingen bij de getoonde kassabon : Figure 9 Voorbeeld 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 voor de klantvriendelijkheid vanwege de grotere leesbaarheid. Figuur 6 Voorbeeld kassabon 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 verkoopsprijs Daniels, N.C Information Technology Addison-Wesley, ,90 Date, C.J Guide to SQL-Standard, A Addison-Wesley, Introduction to Database Systems Addison-Wesley, ,90 87,35 Davies, P Indispensable Guide to C, The Addison-Wesley, ,95 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

9 Voorraadsituatie d.d auteur ISBN-nr titel in magazijn Date, C.J Guide to SQL-Standard, A Introduction to Database Systems Figure 11 Deel van de voorraadstaat zoals opgemaakt op een bepaalde datum aantal in voorraad 3 1 in winkelrek 2 1 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 aantal besteld Figuur 12 Deel van de bestellings/leveringsstaat leveringsdatum 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. Aanvulgegevens van woensdag auteur ISBN-nr titel Date, C.J Guide to SQL-Standard, A Introduction to Database Systems aantal van magazijn naar winkelrek 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 gebeurtenissen Figuur 4 Deel bewaard. van de aanvulgegevens op een bepaalde datum 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

10 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

11 Bestelling Aanvulling plaatsen ( create ) en afleveren aanvullen (een create) 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 eventueel ooit Invoeren in catalogus verkopen aanvullen (winkelrek) afleveren (bestelling ) Seldom annuleren verkoop Verwijderen uit catalogus (destroy) Boekverkoop Aanvulling Bestelling Seldom verkopen annuleren verkoop (destroy) aanvullen (winkelrek) plaatsen bestelling 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

12 We combineren de gegeven object life cycles nu als volgt in een Object-action-involvement-schema: Verwijderen uit catalogus (destroy) Invoeren in catalogus verkopen eventueel ooit Seldom Boekverkoop Boek annuleren verkoop Aanvulling aanvullen (winkelrek) afleveren (bestelling ) Bestelling plaatsen (bestelling) 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

13 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 Data: (Attributen) 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) Boekverkoop Data: (Attributen) Identificerend: ISBNnr + aantal + datum + uuraanduiding + verkopernr...(+ evt. resterende data) Methodes: verkopen annuleren verkoop 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. Aanvulling Data: (Attributen) Identificerend: ISBNnr + aantal + aanvuldatum.(+ evt. resterende data) Methodes: aanvullen (winkelrek) Bestelling Data: (Attributen) 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 Mogelijke uitbreidingen: gebruikers/ bedrijfsprocessen/ database-typen 1. 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 een bepaalde actie op een object te laten uitvoeren? en Bij welk(e) bedrijfsproces(sen) hoort een bepaald object+acties? dan wordt het eenvoudig om uit het eerder besproken objecttype/acties -schema een variant op het eerder in dit hoofdstuk besproken BSP-informatiekruis te destilleren. Als een intermediair product daarvoor hebben we hiernaast het eerder bepaalde Boek-objecttype verder uitgewerkt, door achter de object-methodes aan te vullen wie binnen de boekhandel die methodes kan/mag gebruiken. Boek Data: Identificerend: ISBNnr aantal-in-magazijn aantal-in-winkelrek.(+ evt. resterende data) Methodes: Geautoriseerd: invoeren in catalogus administrateur (?) verwijderen uit catalogus administrateur (?) verkopen verkopers annuleren verkoop verkopers aanvullen (winkelrek) magazijnbeheerder afleveren (bestelling) magazijnbeheerder 13

14 2. 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? ). 3. 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: Auteur (Aut_naam) heeft als Verkoper (Verk_naam) Uur "Tijdstip" op...om... Titel heeft als Boek (ISBNnr) van...zijn door...op...verkocht Verkoopsprijs (Bedrag) heeft van...zijn...exemplaren op...in winkel aangevuld Uitgever (Uitg_naam) Jaar (Jaartal) is uitgave van met jaar van eerste uitgave van...zijn...in magazijnvoorraad van...zijn in winkelrekken...in voorraad "Bestelling" Aantal Datum 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 PK Verkoper PK Datum PK Uur Aantal Boek PK ISBNnr Titel Auteur Bedrag Uitgever Uitgavejaar Aantal_In_Magazijn Aantal_in_Winkel Aanvulllingen PK,FK ISBNnr PK Datum Aantal Bestelling PK,FK ISBNnr PK Aantal PK Besteldatum 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

15 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 Rekening(houder) Betalingsopdracht Actie 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. 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

16 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). terugsturen opdracht Seldom Opmaken+Versturen Rekeningafschrift Betalingsopdracht * * saldo verlagen saldo verhogen Rekening (houder) invoeren uitvoeren opdracht adres wijzigen? toesturen betaalformulieren invoeren 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

17 Opmaken+Versturen Rekeningafschrift Seldom terugsturen opdracht Betalingsopdracht * * saldo verlagen saldo verhogen Rekening (houder) invoeren uitvoeren opdracht adres wijzigen? toesturen betaalformulieren invoeren 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 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

18 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?) IV O utput functions C o ntro l pro c esses C o ntro l model respo nsibilities I 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. O bje cts Info rmatio n Em plo ye es Het Information quadrant uit de KISSmethode wordt hierbij in zijn algemene vorm weergegeven. Taakverdeling en/of verantwoordelijkheden van personen/afdelingen lijken hier weer een belangrijkere rol te zijn gaan spelen en de relatie tussen objecten en acties daaro p is in een meer objectgerichte aanpak (zoals de KISS-methode zich pleegt te noemen) niet verbazingwekkend. Info rm atio n architecture 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 ) III D ata Actio ns Autho risations II Figure 17 Het ' information quadrant' v/d KISS -methode 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 Een uitgewerkt en hiernaast weergegeven voorbeeld hierover vinden we in het boek over de KISS-methode. 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.. Branch Client Account Cash drawer Client recruitment Relation management Cash management Credit control Business planning Objects Processes Actions To register To open To deposit Employees General manager Cashier Counter assistant To withdraw To install To count To close To de-register Figure 18 Het KISS- ' information quadrant' voor een bank Controller 18