1 Rijksuniversiteit Groningen, Faculteit Bedrijfskunde Syllabus Rapid Application Development 7e editie Henk W.M. Gazendam en Simon Sibum Groningen, j...
Inhoudsopgave 1. Projectmanagement ..................................................................................................................... 6 1.1. Samenwerken onder tijdsdruk...................................................................................... 6 1.2. Interviews ..................................................................................................................... 6 1.3. Rolverdeling ................................................................................................................. 6 1.4. Literatuur over projectmanagement ............................................................................. 7 2. Gebruiksmogelijkheden (use cases) ............................................................................................ 7 2.1. Inleiding gebruiksmogelijkheden................................................................................. 7 2.1.1. Toepasbaarheid van gebruiksmogelijkheden (use cases).............................. 7 2.1.2. De rol van verschillende soorten modellen ................................................... 7 2.1.3. Het onderkennen van gebruiksmogelijkheden (use cases)............................ 9 2.2. Begrippen rond gebruiksmogelijkheden: organisatie en interactie ............................ 10 2.2.1. Actor............................................................................................................ 10 2.2.2. Programma, impuls, actie, activiteit, proces ............................................... 10 2.2.3. Organisatie .................................................................................................. 11 2.2.4. Zaak, prestatie ............................................................................................. 11 2.2.5. Subjectsysteem en objectsysteem................................................................ 12 2.2.6. Communicatieve actie, interactie, overdrachtsactie, DEMOtransactie.................................................................................................... 12 2.2.7. Algemene structuur van de DEMO-transactie volgens Dietz ..................... 12 2.2.8. Transactie .................................................................................................... 13 2.2.9. Transformatie .............................................................................................. 14 2.3. Probleemanalyse......................................................................................................... 15 2.3.1. Opdrachtformulering................................................................................... 15 2.3.2. Organisatiebeschrijving............................................................................... 15 2.3.3. Probleeminventarisatie en structuur van de problemen .............................. 16 2.3.4. De oplossingsrichting schetsen ................................................................... 17 2.4. Informatie-analyse...................................................................................................... 18 2.4.1. Actoren en communicatie............................................................................ 18 2.4.2. Analyse van bedrijfsprocessen en taken...................................................... 23 2.4.3. Informatiegebruik bij het uitvoeren van taken ............................................ 29 2.5. De organisatorische gebruiksmogelijkheden (use cases) ........................................... 34 2.6. De informatiesysteem gebruiksmogelijkheden (use cases)........................................ 36 2.6.1. De gebruiksmogelijkheden (use cases) voor procesuitvoering ................... 36 2.6.2. De gebruiksmogelijkheden (use cases) voor informatiebeheer en systeembeheer ........................................................................................... 37 2.6.3. Verbanden tussen use cases......................................................................... 38 2.6.4. Verdere uitwerking van use cases in scenario's .......................................... 39 2.7. Literatuur over gebruiksmogelijkheden (use cases)................................................... 41 3. Objectmodel .............................................................................................................................. 42 3.1. Componenten van een informatiesysteem.................................................................. 42 3.2. Het begrippennetwerk rond het begrip 'objecttype'.................................................... 45 3.2.1. Abstractie en reticulatie............................................................................... 45 3.2.2. Soorten handelingen.................................................................................... 47 3.2.3. Soorten modellen......................................................................................... 48 2
3.2.4. Objectmodellen ........................................................................................... 48 3.2.5. Object, begrip, symbool .............................................................................. 48 3.2.6. Objecttype en attribuuttype ......................................................................... 49 3.2.7. Associatie, associatietype............................................................................ 50 3.2.8. Generalisatie................................................................................................ 51 3.2.9. Structuren .................................................................................................... 52 3.2.10. Categorieën................................................................................................ 53 3.3. Top-down ontwikkeling van het objectmodel voor het domein met de categorieënmethode............................................................................................... 54 3.3.1. Inleiding top-down ontwikkeling ................................................................ 54 3.3.2. Objecttypen ................................................................................................. 55 3.3.3. Een abstract objectmodel gebaseerd op associatietypen ............................. 56 3.3.4. Het eerste objectmodel ................................................................................ 57 3.3.5. Het registreren van gebeurtenissen ............................................................. 58 3.3.6. Het onderscheiden van structuren ............................................................... 61 3.3.7. Het onderzoeken en vereenvoudigen van het objectmodel......................... 62 3.3.8. Het uitgebreide objectmodel ....................................................................... 64 3.4. Bottom-up ontwikkeling objectmodel voor het domein ............................................ 65 3.4.1. Inleiding bottom-up ontwikkeling............................................................... 65 3.4.2. Invoer/uitvoerdocumenten .......................................................................... 66 3.4.3. Normaliseren ............................................................................................... 68 3.4.4. Bubble charts............................................................................................... 72 3.4.5. Vergelijking resultaten bottom-up ontwikkeling met resultaten top-down ontwikkeling ............................................................................. 75 3.5. Objectmodel voor taken ............................................................................................. 77 3.5.1. Van use cases naar taakmodel..................................................................... 77 3.5.2. Van taakmodel naar objectmodel voor taken.............................................. 79 3.6. Objectmodel voor het gebruikersinterface ................................................................. 83 3.6.1. Principes voor het gebruikersinterface en huisstijl ..................................... 83 3.6.2. Inleiding gebruikersinterface....................................................................... 84 3.6.3. Menustructuur ............................................................................................. 91 3.6.4. Objectmodel van een formulier................................................................... 91 3.6.5. Specificatie van formulierinvulmethoden in pseudocode ........................... 93 3.6.6. Specificatie van formulierinvulmethoden in taal ........................................ 95 3.7. Literatuur over objectmodellen .................................................................................. 96 4. Constructieplan.......................................................................................................................... 97 4.1. Keuze ontwikkelomgeving en technische componenten ........................................... 97 4.2. Implementatiewijze .................................................................................................... 98 4.2.1. Het strokenschema ...................................................................................... 98 4.2.2. Relaties tussen tabellen ............................................................................. 100 4.3. Componenten ........................................................................................................... 100 4.3.1. Naamgevingsconventies............................................................................ 100 4.3.2. Overzicht componenten............................................................................. 101 4.4. Handleiding en overige documentatie...................................................................... 103 4.5. Literatuur over het constructieplan .......................................................................... 104 5. Testplan ................................................................................................................................... 105 5.1. Testplan .................................................................................................................... 105 3
5.2. Resultaten uitvoering testonderzoek ........................................................................ 105 6. Programmeren in Access......................................................................................................... 105 6.1. Inleiding ................................................................................................................... 105 6.2. Belangrijke vensters ................................................................................................. 106 6.2.1. Database Window ..................................................................................... 106 6.2.2. Database Wizard ....................................................................................... 106 6.2.3. De verschillende ontwerpvensters............................................................. 106 6.2.4. Object Browser.......................................................................................... 106 6.2.5. Debug Window ......................................................................................... 107 6.3. Namen in Visual Basic for Applications (VBA)...................................................... 107 6.3.1. Symbolen................................................................................................... 107 6.3.2. Objectnamen.............................................................................................. 108 6.3.3. Variabelen ................................................................................................. 109 6.3.4. Toekenning van waarde of object aan een variabele................................. 110 6.3.5. Modulair programmeren ........................................................................... 110 6.4. Structuur van een Access applicatie......................................................................... 111 6.4.1. Structuur van een Access applicatie.......................................................... 111 6.4.2. De basis van de applicatie ......................................................................... 112 6.4.3. De functionele structuur neergelegd in de Switchboard Manager ............ 112 6.4.4. Verbanden via de RecordSource eigenschap ............................................ 113 6.4.5. Verbanden via subformulieren .................................................................. 115 6.4.6. Verbanden via comboboxen...................................................................... 115 6.4.7. Gebeurtenisprocedures .............................................................................. 115 6.4.8. Algemene functies en procedures ............................................................. 116 6.5. Gestructureerd programmeren.................................................................................. 116 6.5.1. De ontwikkeling in het programmeren...................................................... 116 6.5.2. Imperatieve programmastructuren ............................................................ 116 6.5.3. Functionele programmastructuren............................................................. 118 Array operaties .................................................................................................... 119 Collection methoden ........................................................................................... 119 6.5.4. Objectgeoriënteerde programmastructuren ............................................... 120 6.5.5. Event-georiënteerde programmastructuren ............................................... 122 6.5.6. De in Access gebruikte talen..................................................................... 122 6.6. De gegevensbanktaal van Access............................................................................. 123 6.6.1. Inleiding .................................................................................................... 123 6.6.2. Data Definition Language ......................................................................... 123 6.6.3. Data Manipulation Language .................................................................... 124 6.6.4. Berekeningen gekoppeld aan tabellen....................................................... 126 6.6.5. Filters definiëren ....................................................................................... 126 6.6.6. Recordset-methoden.................................................................................. 126 6.6.7. Transacties................................................................................................. 128 6.7. Invoer en uitvoer ...................................................................................................... 129 6.7.1. Invoermaskers en validatieregels .............................................................. 129 6.7.2. Menustructuur ........................................................................................... 130 6.7.3. Uitvoer naar scherm en printer.................................................................. 130 6.8. Literatuur over programmeren in Access................................................................. 131
4
Bijlage 1. Case Fietsenhandel JEEKAA ..................................................................................... 132 Omschrijving................................................................................................................... 132 Bestelformulier................................................................................................................ 133 Factuur............................................................................................................................. 134 Bijlage 2. Het gebruik van System Architect.............................................................................. 135
5
1. Projectmanagement 1.1. Samenwerken onder tijdsdruk Een belangrijk kenmerk van het werken in projecten is het moeten werken onder tijdsdruk. Besteed daarom vanaf het begin aandacht aan een goed projectmanagement, dat wil zeggen planning, taakverdeling en onderlinge communicatie. Zorg voor taakverdeling, maar ook voor integratie van de resultaten van taakuitvoering. Trek elke dag tijd uit voor het bespreken van wat ieder heeft gedaan. Laat niet alles op de laatste week aankomen. Besteed vooral in het begin aandacht aan teambuilding en het sociaal gebeuren. In de verantwoording van het projectmanagement wordt het verloop van het project verantwoord. Registreer wie aan welke onderdelen heeft gewerkt en vermeld de tijdsbesteding in uw eindrapportage. Geef in het bijzonder aan wie welke onderdelen van het eindproduct heeft gemaakt (rapportages, modules), en welke tijd daaraan is besteed. 1.2. Interviews Na het doorlezen van het schriftelijke materiaal over de uit te voeren opdracht wordt er een eerste gesprek gevoerd met de opdrachtgever. Het doel van dit eerste interview is: een heldere opdrachtformulering, waarbij de opdracht voldoende wordt afgebakend; een lijstje met de concrete klachten / problemen waaraan moet worden gewerkt. Bedenk dat in dit eerste interview en in de vervolginterviews belangrijke aanvullende informatie boven water moet komen. Bereid alle interviews voor door het opstellen van vragen. Zorg de juiste personen te spreken te krijgen. Stel de conclusies van het interview op schrift en laat deze bij een eerstvolgende gelegenheid door de geïnterviewde persoon valideren. Gedraag u bij de interviews fatsoenlijk en geïnteresseerd (Bots e.a., 1990: 475). 1.3. Rolverdeling De ervaring leert dat een rolverdeling waarbij één van de teamleden al het programmeerwerk doet tot grote problemen leidt. Bij het maken van de opgaven, en bij het programmeren van de verschillende bouwstenen van het systeem, is het nuttig om het werk over alle teamleden te spreiden. Laat daarom alle teamleden zich voldoende verdiepen in het programmeren. Beheer de opgeleverde resultaten (documenten, programmatuur) zorgvuldig. Zorg voor duidelijke naamgeving en beheer van versies. Maak back-ups. Brooks (1995. 32) beschrijft hoe in een klein team (surgical team) snel programmatuur kan worden ontwikkeld. Het voordeel van een dergelijke aanpak is dat het aantal overdrachtsmomenten, waarbij een product door een groep wordt overgedragen aan een andere groep die ermee verder moet gaan, tot een minimum wordt gereduceerd. Overdrachtsmomenten in een project leiden tot erg veel inefficiency door het uitvoerig moeten documenteren en uitleggen van het product door de groep vóór het overdrachtsmoment, het zich eigen moeten maken van de eigenschappen van hetgeen is overgedragen door de groep na het overdrachtsmoment, en het ontbreken van inzicht in het gehele ontwikkelproces bij beide groepen. Als de deelnemers aan een groep min of meer all round zijn en het gehele ontwikkeltraject kunnen overzien kan ook veel efficiënter worden gewerkt dan wanneer een ieder zich terugtrekt op zijn eigen specialisme en zich niet kan inleven in de taken van anderen.
6
Wij hanteren een iets simpeler rolverdeling dan Brooks. Het is aan te bevelen dat de volgende verdeling van rollen/ verantwoordelijkheden wordt gehanteerd, waarbij elke rol bij toerbeurt door één van de groepsleden wordt vervuld: programmeur: verantwoordelijk voor het algemeen projectmanagement, de ordelijke opbouw (de architectuur) van de programmatuur en het maken van het programma; bibliothecaris: verantwoordelijk voor naamgevingsconventies, van commentaar voorzien van de programmacode, de relatie tussen programmatuur en ontwerpdocumentatie, het beheer van de back-ups en het versiebeheer, het bevorderen van hergebruik, en het documenteren van objectmodel en constructieplan; tester: verantwoordelijk voor het testen en bijstellen van de programmatuur vanuit het gezichtspunt van de gebruiker, het maken en uitvoeren van het testplan en het documenteren van de use cases, het testplan en de uitgevoerde tests. 1.4. Literatuur over projectmanagement Bots, J.M., E. van Heck, V. van Swede en J.L. Simons. Bestuurlijke Informatiekunde. Rijswijk: Cap Gemini Publishing/ PANDATA, 1990. Brooks, Frederick P. The Mythical Man-Month. Reading, MA: Addison-Wesley, 1995. Samenvatting van de System Development Methodology. Rijswijk: PANDATA, 1988. Snoo, H.C.R. de. De IDO-methodiek: Het ontwerpen van een administratief automatiseringssysteem. Schoonhoven. Academic Service, 1987. Zeist, Bob van, Paul Hendriks, Robbert Paulussen, en Jos Trienekens. Kwaliteit van softwareprodukten. Deventer: Kluwer, 1996.
2. Gebruiksmogelijkheden (use cases) 2.1. Inleiding gebruiksmogelijkheden 2.1.1. Toepasbaarheid van gebruiksmogelijkheden (use cases) In deze syllabus wordt het ontwikkelen van een informatiesysteemontwerp in termen van use cases en een objectmodel behandeld aan de hand van de JEEKAA-case (zie Bijlage 1. Case Fietsenhandel JEEKAA). Het modelleren van gebruiksmogelijkheden (use cases), geintroduceerd door Jacobson c.s. (1994), is een effectief middel gebleken om de functionaliteit van een systeem vast te leggen. De methode kan niet alleen worden toegepast op informatiesystemen, maar ook op organisaties. Rond het praktisch toepassen van use cases kan echter allerlei verwarring ontstaan, bijvoorbeeld het verwarren van organisaties met informatiesystemen, het door elkaar halen van verschillende beschrijvingsniveaus en het op een onjuiste maner behandelen van relaties tussen use cases. In deze tekst wordt aan de hand van de Case Fietsenhandel JEEKAA (Bijlage 1) uiteengezet hoe een verzameling gebruiksmogelijkheden (use cases) op een min of meer systematische wijze top down kan worden gedefinieerd. 2.1.2. De rol van verschillende soorten modellen Bij het modelleren gebruiken we verschillende soorten modellen. Waarom gebruiken we eigenlijk niet één samenhangend model? Dat komt omdat we onderscheid willen maken tussen het modelleren van de organisatie (in het bijzonder: het informatie-aspectsysteem van de organisatie) en van het informatiesysteem. Ook willen we onderscheid maken tussen het naar buiten toe zichtbare gedrag van een systeem (de buitenkant) en de interne werking ervan (de binnenkant). Het onderscheid tussen buitenkant en binnenkant is in de informatiekunde gebruikelijk omdat het beter is stapsgewijs te ontwerpen, d.w.z. eerst de eisen aan het informatiesysteem (de z.g. requirements) op te schrijven in de vorm van het te vertonen gedrag, en pas daarna een informatiesysteem te ontwerpen (het z.g. design) dat aan deze 7
eisen voldoet. Eisen en ontwerp, buitenkant en binnenkant worden losgekoppeld. Een voordeel hiervan is dat bij technische vernieuwing de buitenkant in stand kan blijven en alleen de binnenkant hoeft te worden veranderd. Een dergelijk onderscheid vinden we ook in de functionele versus de analytische definitie van een systeem: de functionele definitie specificeert de buitenkant, het naar buiten toe zichtbare gedrag, en de analytische definitie zegt iets over de binnenkant, de interne opbouw van het systeem uit deelsystemen. Op grond van deze twee onderscheidingen (organisatie/ informatiesysteem en buitenkant/ binnenkant) kunnen we vier soorten modellen afleiden: 1. modellen over de buitenkant van organisaties, zoals use case modellen; 2. modellen over de binnenkant van organisaties, zoals role activity diagrams; 3. modellen over de buitenkant van informatiesystemen, zoals use case modellen, maar dan in een andere rol; 4. modellen over de binnenkant van een informatiesysteem , zoals objectmodellen. Bij elk van deze modellen kan in principe een model worden gemaakt van de huidige situatie en van een ontworpen, gewenste situatie. Veel oude informatiekundige methoden berusten op het idee dat een huidige organisatorische, niet-geinformatiseerde, situatie moest worden ondersteund door een nieuw informatiesysteem. Men maakte dan alleen organisatiemodellen van de huidige situatie en informatiesysteemmodellen van de gewenste situatie. Bij de ontwikkeling van een informatiesysteem maakt men normaliter de verschillende modellen in de volgorde 1, 2, 3, 4. Eerst wordt het relevante deel van de organisatie of het bestuurlijk netwerk in kaart gebracht, eventueel herontworpen, en daarna wordt de rol en de opbouw van het huidige informatiesysteem (indien aanwezig) beschreven, en vervolgens (her)ontworpen.
Organisatie Informatiesysteem
In bovenstaande figuur zijn actoren door poppetjes weergegeven, systemen door rechthoeken en use cases door ovalen. In de ovalen staan pijlen met punten aan beide kanten die aanduiden dat de use cases zich op interactieniveau bevinden. We zien dat er twee typen use cases zijn: de use case tussen externe actor en organisatie, en de use case tussen interne actor (plus eventueel de externe actor) en informatiesysteem.
8
Er zijn nog veel andere typen modellen over de binnenkant van en informatiesysteem. Het objectmodel is eigenlijk een statisch model over de bestanddelen van een informatiesysteem. De samenwerking van deze objecten bij het afhandelen van taken kan door diverse typen gedragsmodellen worden beschreven1. Opmerkelijk is dat use case modellen in twee rollen voorkomen, namelijk bij de beschrijving van de buitenkant van organisaties en bij de beschrijving van de buitenkant van informatiesystemen. Dit zijn dus verschillende modellen, alhoewel ze wel iets met elkaar te maken hebben, zoals hieronder zal worden uitgelegd. Organisatorische use cases kunnen op vier niveau’s worden beschreven: het niveau van de (economische) transactie tussen actoren, dit houdt meestal in het leveren van een prestatie en een tegenprestatie, inclusief de nodige voorbereiding en nazorg (contact, contract en controle uit de transactiekostentheorie); het niveau van de halve transactie of DEMO-transactie, bestaande uit de levering van een prestatie met de bijbehorende communicatieve acties die als besturing van het leveren van de prestatie dienen (Dietz, 1996); het niveau van de interactie of conversatie tussen actoren, meestal het uiten van een boodschap en een tegenboodschap zoals vraag en antwoord; het niveau van de actie en de activiteit die allebei gebeurtenissen zijn die op een bepaald moment plaatsvinden, waarbij een actie geen duur heeft en een activiteit wel. Informatiesysteem use cases worden vaak op het niveau van de interactie beschreven en soms op het niveau van de actie/ activiteit. In het boek The Object Advantage geven Jacobson c.s. (1994) aan dat de organisatorische use case eigenlijk moet worden beschreven op het niveau van de transactie, omdat dit voor de gebruikende actor een afgerond resultaat geeft. Andere bronnen geven aan dat use cases eerst grof mogen worden gedefinieerd en vervolgens mogen worden verfijnd: een transactie zou dan bijvoorbeeld in termen van interacties kunnen worden uiteengelegd en vervolgens in termen van acties. Om een verband te kunnen leggen tussen organisatorische use cases en informatiesysteem use cases zouden de organisatorische use cases eerst tot op het niveau van de interacties moeten worden uitgeschreven. Vervolgens moet voor een bepaalde actor in een interactie worden bepaald of de rol van deze actor (1) alleen door de mens moet worden uitgevoerd, of (2) door de mens ondersteund door de computer of (3) alleen door de computer (geautomatiseerd dus). Op deze manier kan een verzameling use cases (gebruiksmogelijkheden) voor het informatiesysteem worden afgeleid (d.w.z. die gebruiksgevallen waarin het informatiesysteem de mens ondersteunt of vervangt). 2.1.3. Het onderkennen van gebruiksmogelijkheden (use cases) Voor het op een systematische manier onderkennen van use cases doen we een aantal voorbereidende stappen. Allereerste bakenen we het te bestuderen probleemgebied af in een probleemanalyse. Daarna doen we een informatie-analyse bestaande uit het tekenen van drie soorten diagrammen voor de in de toekomst beoogde gang van zaken. Daarbij kunnen de diagrammen voor de huidige situatie eventueel behulpzaam zijn. De te tekenen diagrammen zijn: het actor-interactiediagram, het bedrijfsprocesanalysediagram en het ISAC-A-schema. Deze diagrammen helpen ook bij een verdere afbakening van het probleemgebied. Het actorinteractiediagram en het bedrijfsprocesanalysediagram geven aanwijzingen over 1
Zie bijvoorbeeld de website over de Universal Modeling Language (UML): http://www.rational.com/uml/ of http://www.rspa.com/spi/OOanal.html.
9
organisatorische use cases; het ISAC-A-schema geeft aanvullende informatie over informatiesysteem uses cases. 2.2. Begrippen rond gebruiksmogelijkheden: organisatie en interactie 2.2.1. Actor Een actor is een systeem dat zelfstandig handelingen uitvoert gebruik makend van een stelsel van regels, een programma of script, adequaat reagerend op de omstandigheden, zodanig dat daarbij min of meer intelligente beslissingen worden genomen (Gazendam en Jorna, 1993; Carley en Prietula, 1994; Jorna, Gazendam, Heesen en Van Wezel, 1996: 20). Organisaties, mensen en in werking zijnde computers kunnen worden opgevat als actoren. Het beschouwen van mensen als actoren betekent overigens niet dat mensen niet meer creatief zouden mogen zijn of mogen improviseren of vage begrippen mogen gebruiken. Het tegendeel is het geval. Het is juist een uitdaging om deze verschijnselen te verklaren door een beroep te doen op goed definieerbare mechanismen in plaats van begrippen met een onduidelijke status. Ook betekent het hanteren van de actorbenadering niet dat machines gelijk of gelijkwaardig zijn aan mensen. Volgens de physical symbol system theorie van Newell en Simon (1972) bestaat een actor (physical symbol system) uit een samenhangend geheel van sensoren, processoren en effectoren dat in staat is tot het zelfstandig toepassen en genereren van symboolstructuren zoals gegevens, kennis, en programma's (Gazendam, 1993: 14; Russell and Norvig, 1995: 31).
Bij actoren moeten we een onderscheid maken tussen actortype en individuele actor. Op grond van de gekozen beschouwingswijze kan elke individuele actor tot één of meer actortype worden gerekend. De actortypen worden onderscheiden op grond van de vervulde rol. Waar we in het navolgende bij de modellering over actoren spreken wordt steeds het actortype bedoeld. Daarnaast houden wij ons bij de modellering van organisaties veelal niet bezig met computer-actoren. In de praktijk van de modellering is een actor dus steeds een persoon of een groep van personen die een bepaalde rol vervult. Een persoon kan eventueel worden opgesplitst in de verschillende rollen die hij vervult en komt dan overeen met meerdere actoren. Dit is vooral bij kleine organisaties van belang. Hoe onderscheiden we rollen? Hierbij is het onderscheiden van interacties (die hieronder worden uitgelegd) behulpzaam. Voor elke interactie is binnen het systeem één bepaalde actor verantwoordelijk. De rol van die actor is het besturen of het besturen en het uitvoeren van een bepaalde interactie. 2.2.2. Programma, impuls, actie, activiteit, proces Rol, script en programma zijn (in toenemende mate meer formele) beschrijvingen van de handelingen die een actor onder bepaalde omstandigheden normaliter zal doen. Rol, script en programma zijn door een actor uitvoerbare beschrijvingen van handelingen. De meest formele beschrijving is een programma. Een programma is een samenhangende beschrijving van een hoeveelheid werk, inclusief eventueel de daarbij behorende doelen, eisen, randvoorwaarden, te volgen procedures en te volgen gedragsregels. Als de actor een computer is, dan is het programma een computerprogramma. Een taak is een programma waarvoor de verantwoordelijkheid aan een bepaalde actor is toegewezen. Om een actor een programma te laten uitvoeren is een gebeurtenis nodig die als impuls (trigger) werkt.
De uitvoering van een programma leidt tot een feitelijk in de tijd plaatsvindende handelingen. Handelingen kunnen acties of activiteiten zijn. Om het verschil tussen actie en activiteit uit te leggen hebben we het systeembegrip nodig. Het objectsysteem kan worden beschreven in 10
termen van toestanden en gebeurtenissen voor. Als een gebeurtenis optreedt hangt de volgende toestand zowel van de gebeurtenis als van de huidige toestand af (Rumbaugh e.a., 1991, p.89). Een actie is een handeling door een actor waarvan de tijdsduur te verwaarlozen valt in het kader van het reticulatieniveau van de toegepaste modellering. Een actie is geassocieerd met een gebeurtenis die als impuls werkt. Een activiteit is, in tegenstelling tot een actie, een handeling door een actor die tijd in beslag neemt. In veel gevallen is een activiteit geassocieerd met een toestand waarin het systeem bezig is met het uitvoeren van die activiteit. Bij essentiële acties zoals overdrachtshandelingen (overdrachtsacties) of omzettingshandelingen wordt veelal een prestatie geleverd. Taalhandelingen (communicatieve acties) bestaan uit op het verzenden en ontvangen van berichten. Een proces is een verzameling samenhangende, door impulsrelaties verbonden, acties en activiteiten. Een proces dat op organisatieniveau wordt onderscheiden is een bedrijfsproces. 2.2.3. Organisatie Een organisatie is een samenhangend geheel van (1) samenwerkende actoren, (2) door hen uitgevoerde processen van taakuitvoering en (3) door hen gegenereerde en gebruikte kennis en informatie (Gazendam, 1993: 14; Jorna. Gazendam, Heesen en Van Wezel, 1996: 20). De grenzen van een organisatie kunnen worden vastgesteld op grond van kenmerken van de samenwerking. Een werkorganisatie is een verzameling samenwerkende actoren die wordt onderscheiden op grond van een stabiel patroon van samenwerkingsrelaties. Een organisatie kan ook worden afgebakend op grond van formele relaties tussen personen zoals eigendomsverhoudingen, arbeidscontracten, en dergelijke. In dat geval is een formele organisatie een verzameling samenwerkende actoren die wordt onderscheiden op grond van formele relaties tussen actoren. Die formele relaties zijn bijvoorbeeld eigendomsrelaties en contracten zoals arbeidsovereenkomsten. Werkorganisatie en formele organisatie hoeven niet congruent te zijn. Volgens Schmidt (1991) doet men er goed aan om de werkorganisatie als basis te zien en de formele organisatie te interpreteren als een extra laag van gedragsbepalende informatie.
Een organisatie bestaat niet alleen uit menselijke en machine actoren. Mensen en machines kunnen instromen en uitstromen in een organisatie, en toch blijft het karakter van een organisatie daarbij soms min of meer hetzelfde. Om deze reden is het van belang om naast actoren ook de in een organisatie plaatsvindende processen en de symboolstructuren (d.w.z. alle in documenten vastgelegde kennis en informatie) die bij een organisatie horen zoals de programma's van de bedrijfsprocessen, de gedragsregels, de briefhoofden, bij een organisatie te rekenen. 2.2.4. Zaak, prestatie Een zaak is een voor menselijke beheersing vatbaar stoffelijk object (Algra, Ten Berge en Sleurink, 1986: B1/66). Een prestatie is een handeling die voor degene waarvoor zij wordt verricht waarde heeft. Prestaties kunnen in het samenspel tussen twee (of meer) organisaties worden geleverd (transactiegerichte prestaties) of binnen een organisatie (transformatiegerichte prestaties). Een transactiegerichte prestatie kan zijn: het in eigendom overdragen van een zaak (P van product); het verlenen van een dienst (S van service); het verlenen of in eigendom overdragen van een recht (R van rights); het in eigendom overdragen van geld (F van finance).
11
Een transactie bestaat in de regel uit een transactiegerichte prestatie en een tegenprestatie. De tegenprestatie kan ook nil (N), d.w.z niet aanwezig c.q. gewenst zijn. Transformatiegerichte prestaties bestaan in de regel uit: het creëren of van toestand veranderen van zaken (T van transformation) Bij het veranderen van de toestand van een zaak kan men denken aan het veranderen van de tijdsdimensie (bewaren, opslaan), van plaats (transporteren) en van hoedanigheid (produceren). 2.2.5. Subjectsysteem en objectsysteem Het te bestuderen probleemgebied beschouwen wij in termen van een subjectsysteem en een objectsysteem. Het subjectsysteem is het geheel van actief handelende actoren, gegroepeerd in systemen die we organisaties noemen. Het objectsysteem is het onderwerp van de handelingen der actoren. Het subjectsysteem kan onderdeel van het objectsysteem zijn, d.w.z. de handelende actoren kunnen zichzelf (mede) als onderwerp van handeling hebben (Dietz, 1992: 72). Het subjectsysteem wordt bestudeerd met behulp van actor-interactiemodellen en bedrijfsprocesmodellen. Het objectsysteem wordt bestudeerd met behulp van objectmodellen. 2.2.6. Communicatieve actie, interactie, overdrachtsactie, DEMO-transactie Een communicatieve actie of taalhandeling bestaat uit het maken en overbrengen van een bericht. Een interactie of conversatie is een afgeronde uitwisseling van boodschappen tussen twee actoren. Een interactie bestaat normaliter uit twee communicatieve acties zoals bijvoorbeeld een vraag en een antwoord. Bij een overdrachtsactie of essentiële actie worden rechten, goederen, diensten of geld overgedragen. Die overdracht van rechten, goederen , diensten of geld is een prestatie (of tegenprestatie). Een overdrachtsactie wordt meestal omgeven door communicatieve acties; dit geheel van overdrachtsactie en bijbehorende communicatieve acties noemen we een DEMO-transactie. 2.2.7. Algemene structuur van de DEMO-transactie volgens Dietz Volgens de theorie van Dietz (1996) heeft een DEMO-transactie, als we die maar abstract genoeg beschouwen, een standaardstructuur. De kern van deze DEMO-transactie wordt gevormd door een overdrachtshandeling. Om die overdrachtshandeling heen worden berichten uitgewisseld die kunnen worden gezien als de besturing van de overdrachtshandeling. Bij de DEMO-transactie zijn twee partijen betrokken: de initiator en de executor. De executor voert de overdrachtshandeling uit, terwijl de initiator degene is waarvoor de overdrachtshandeling wordt uitgevoerd en die ook het initiatief neemt voor de DEMO-transactie. Voordat de overdrachtsactie wordt ondernomen, vindt eerst een actagene conversatie plaats waarbij het uitvoeren van de overdrachtshandeling op de agenda van de executor wordt geplaatst. Nadat de overdrachtsactie heeft plaatsgevonden moet in een factagene conversatie worden geconstateerd dat zulks het geval is. De hieruit volgende algemene structuur van een DEMO-transactie is volgens Dietz (1996: 33): actagene conversatie, bestaande uit de communicatieve acties: verzoek tot uitvoering van de overdrachtsactie door de initiator; belofte tot uitvoering van de overdrachtsactie door de executor; uitvoering van de overdrachtsactie (executie) door de executor; factagene conversatie, bestaande uit de communicatieve acties: verklaring dat de overdrachtsactie is uitgevoerd door de executor; aanvaarding van de verklaring dat de overdrachtsactie is uitgevoerd door de initiator .
12
In een actagene conversatie komt een agendum tot stand, een punt op het actielijstje van de verzoek belofte
executor
initiator
uitvoering verklaring aanvaarding
uitvoerder van de overdrachtsactie (Dietz, 1992: 78). De actagene conversatie bestaat uit een verzoek en een belofte: "Ik verzoek u mij 10 fietsen van het type Gazelle Tour de France Heren te leveren." (verzoek door JEEKAA, optredend als Initiator); "Ik beloof u deze fietsen binnen 12 weken te leveren onder voorwaarde van de bijgesloten leveringsvoorwaarden." (belofte door Gazelle, optredend als Executor). In de factagene conversatie komt een feit tot stand, een door beide actoren geaccepteerde constatering (Dietz, 1992: 79). "Hierbij lever ik u 10 fietsen van het type Gazelle Tour de France Heren." (verklaring van Gazelle, optredend als Executor) "OK" (aanvaarding van deze verklaring door JEEKAA, optredend als Initiator) Actagene conversatie en factagene conversatie vormen samen de besturing van de overdrachtsactie. De rol van de initiërende actor is daardoor besturend. De rol van de executerende actor is besturend én uitvoerend. De hierboven genoemde stappen zijn de stappen die gedaan worden als de DEMO-transactie op de standaard (default) manier verloopt. De uitzonderingen op dit standaardproces, zoals bijvoorbeeld het intrekken van het verzoek (bijvoorbeeld annulering van een bestelling) kunnen in een toestandsdiagram worden gemodelleerd. 2.2.8. Transactie Een transactie is een geheel van interacties tussen actoren die tot verschillende organisaties behoren, waarbij op grond van een overeenkomst een uitwisseling van zaken of rechten plaatsvindt. Een transactie is een proces. De meeste gebruikelijke transactie bestaat uit een prestatie en een tegenprestatie, zoals het leveren van een fiets en het betalen van die fiets. Dat wil zeggen dat de hierboven beschreven DEMO-transactie eigenlijk maar de helft is van datgene wat wij een transactie noemen. De gegven definitie van 'transactie' komt overeen met het algemeen gangbare gebruik van het woord 'transactie'. In de economische transactiekostentheorie (TCE, transaction cost economics) wordt een onderscheid gemaakt tussen drie reticulatieniveau's waarop 'transactie' kan worden gedefinieerd (Williamson, 1985: 1): de transactie als overdracht van goed of dienst; de transactie als ruilproces waarin de fasen contact, contract en controle worden onderscheiden; de transactie als gebeurtenis waarbij rechten van eigendom of beheer worden overgedragen, te onderscheiden van het leveren van de goederen of diensten en het eventueel betalen van die goederen of diensten. Het meest gedetailleerde reticulatieniveau, namelijk de overdracht van eigendom of beheer, komt overeen met ons interactie-beschrijvingsniveau. Ook het leveren van goederen of diensten is een interactie, evenals het betalen van deze goederen of diensten. Het meest
13
globale reticulatieniveau van de TCE komt overeen met ons transactie-beschrijvingsniveau. Het ertussen liggende reticulatieniveau geeft ons de aanwijzing om naast contract (het afsluiten van een overeenkomst) en controle (hiertoe zullen we wel de interacties leveren en betalen moeten rekenen) ook een contact-interactie te onderscheiden. We krijgen zo een meer uitgebreide transactiestructuur zoals die bijvoorbeeld door Gale en Eldred (1996: 282) is uitgewerkt: opnemen contact (een interactie waarin alleen informatie wordt uitgewisseld, bijvoorbeeld offerte); afsluiten overeenkomst c.q. contract (als gevolg van onderhandelen); leveren prestatie (meestal: leveren product of dienst); leveren tegenprestatie (meestal: betalen); verlenen/ verkrijgen nazorg. In de overheid is het gebruikelijk om de volgende fasen te onderscheiden: raming van een uitgave (bijvoorbeeld de jaarlijkse rijksbijdrage aan een universiteit); autorisatie om deze uitgave te doen (b.v. doordat een begroting is goedgekeurd); verplichting c.q. afsluiten overeenkomst (men heeft een bestelling gedaan of een subsidie toegekend); leveren prestatie (er is geleverd of aan andere voorwaarden voldaan en derhalve een recht op betaling ontstaan); betaling. Deze fasen kan men zien als fasen in een transactieproces. Bij dat transactieproces zijn dan meestal drie partijen betrokken, te weten de autoriserende instantie (bijvoorbeeld de StatenGeneraal), de uitvoerende instantie (bijvoorbeeld een minister) en een derde instantie (bijvoorbeeld een universiteit). Er is sprake van een dubbele contractstructuur: er is zowel een fase voor het contract tussen autoriserende instantie en uitvoerende instantie (het goedkeuren van de begroting), als een fase voor het contract tussen uitvoerende instantie en derde instantie (het aangaan van een verplichting). Meestal komt elke fase in een transactieproces overeen met een interactie, d.w.z. uitwisseling van een bericht van de ene actor naar de andere actor, en van een tegenbericht. Soms is een bericht als verklaring gekoppeld aan het leveren van een prestatie. Zo beschouwd, is de standaardstructuur van de DEMO-transactie van Dietz een uitwerking van twee fasen in het transactieproces, namelijk de fase van het afsluiten van een contract en de fase van het leveren van een prestatie. In wezen bestaat de standaardstructuur van Dietz dus uit twee interacties: interactie 1: het afsluiten van een overeenkomst c.q. contract: acties: verzoek (b.v. bestelling) (door initiator); belofte, bevestiging van verzoek (b.v. orderbevestiging) (door executor); interactie 2: het leveren van een prestatie: acties: levering van de prestatie (uitvoering) (door executor); verklaring dat prestatie is geleverd (door executor); aanvaarding van de verklaring dat de prestatie is geleverd (door initiator). 2.2.9. Transformatie Een transformatie is een geheel van interacties tussen actoren die tot dezelfde organisatie behoren, waarbij zaken worden gecreëerd of van toestand worden veranderd. Waar bij een transactie de centrale plaats wordt ingenomen door overdrachtshandelingen, wordt binnen de transformatie de centrale plaats ingenomen door omzettingshandelingen (omzettingsacties). Een transformatie is een proces. De interacties van een transformatie kunnen eventueel ook zijn tussen een actor en zichzelf. We hebben dan te maken met een zelfactiverend en
14
zelfsturend proces. In het geval van een zelfactiverend, zelfsturend proces kan aan de stappen in de standaardstructuur van de DEMO-transactie volgens Dietz de volgende betekenis worden toegekend: Opdrachtfase: maken van een plan (verzoek); zich vastleggen om het plan uit te voeren (belofte); Executiefase: uitvoeren van de geplande omzettingsactie (uitvoering); constateren dat de geplande actie is uitgevoerd (verklaring); Resultaatfase: beoordelen of de uitgevoerde omzettingsactie aan de gestelde eisen voldoet (aanvaarding). 2.3. Probleemanalyse2 2.3.1. Opdrachtformulering Het is van belang de opdracht voor het ontwikkelen van een informatiesysteem via rapid application development (RAD) goed af te bakenen. Over de opdracht dient overeenstemming te bestaan met de opdrachtgever. De overeengekomen opdrachtformulering is de basis voor de het onderkennen van use cases. Zorg ervoor dat de opdracht voldoende is afgebakend. Dus niet "Het automatiseren van de administratie van JEEKAA", maar "Het automatiseren van de voorraadadministratie van JEEKAA, waarbij de volgende problemen worden opgelost . . . ". 2.3.2. Organisatiebeschrijving In een organisatiebeschrijving wordt een globaal inzicht gegeven in het assortiment producten, de markt, de toeleveranciers, en het productieproces van de organisatie. De organisatie kan worden gekarakteriseerd met behulp van de door Starreveld e.a. (1997b: 19) gegeven indeling (b.v. groothandel, nutsbedrijf, e.d.). Deze karakteristiek is van belang omdat in de administratief-organisatorische literatuur, zoals in Starreveld c.s., aanwijzingen staan hoe men de administratieve bedrijfsprocessen voor een bepaald organisatietype idealiter zou moeten organiseren. Voor het afbeelden van de organisatiestructuur kan een organigram worden gebruikt.
Zie voor organigram JEEKAA hieronder. JEEKAA Jeen Kaats Ondernemer / Inkoper Albert Adriaanse Technicus / Verkoper
Bert de Boer Technicus / Verkoper
Charles Ciborra Accountant / Administratieconsulent
Beschrijf de huidige technische infrastructuur (computers, netwerken, operating systems, standaardpakketten) en de daarmee gerealiseerde informatiesystemen. JEEKAA bezit geen computer.
2
Vermeld steeds de bronnen (documenten, interviews, etc.) op grond waarvan u tot bepaalde constateringen of conclusies komt.
15
2.3.3. Probleeminventarisatie en structuur van de problemen In een probleeminventarisatie wordt eerst een opsomming gegeven van de geconstateerde problemen die door middel van het ontwikkelen van een informatiesysteem moeten worden opgelost. Daarna wordt de samenhang van deze problemen geanalyseerd.
We gaan ervan uit, dat in het geval van de JEEKAA-case de volgende concrete klachten / problemen uit de analyse van het schriftelijk materiaal en de interviews naar voren zijn gekomen: 1. de opdrachtgever heeft geen inzicht in de voorraad; 2. de controle bij aflevering van goederen is niet in orde; 3. bij verkoop van een fiets wordt een kopie van een handgeschreven factuur naar de administratie doorgegeven; 4. klanten lopen weg omdat de door hen gewenste fietsen niet in voorraad zijn; 5. teveel klanten willen bestellingen annuleren omdat het te lang duurt voordat bestellingen worden geleverd; 6. wanneer een klant een bestelling wil annuleren, moet er lang worden gezocht naar het bestelformulier; 7. het bestellen van fietsen bij de leverancier kost nu teveel tijd en is nu niet gebaseerd op goede informatie over de voorraad en zonder inzicht in de te verwachten omzet; 8. als door klanten, de politie of de verzekering naar het framenummer van een verkochte fiets wordt gevraagd, is die vraag erg moeilijk te beantwoorden; 9. door tijdgebrek voert JEEKAA een gebrekkige facturenadministratie, waardoor het invullen van de maandelijkse BTW-formulieren veel tijd kost en bovendien erg onnauwkeurig gebeurt, wat al kritiek van de belastinginspecteur heeft uitgelokt. Daarna wordt een structuur in de problemen aangegeven. Het doel is de kluwen van problemen te ontwarren en daarna de op te lossen problemen af te bakenen. Dit gebeurt in drie stappen: het schiften van problemen door te kijken naar de probleemhebber en de aard van de problemen; het inschatten van de ernst en de oorzaken van de problemen; het aanwijzen van de door het ontwikkelen van een informatiesysteem op te lossen problemen. Bij de eerste stap worden de op te lossen problemen van de niet op te lossen problemen onderscheiden door op bedrijfskundige wijze te kijken naar de probleemhebber (indien niet aanwezig, dan géén probleem om aan te werken) en de aard van het probleem (indien perceptie- of doelstellingsprobleem, dan géén probleem om aan te werken). In de bedrijfskundige probleemanalyse volgens De Leeuw (1988) worden problemen die het waard zijn om aan te werken onderscheiden op grond van twee criteria: 1. Is er een probleemhebber (een persoon die zich verantwoordelijk weet voor de oplossing van het probleem en het probleem daadwerkelijk ondervindt)? Zo niet, dan geen probleem om aan te werken. 2. Is het probleem het gevolg van verkeerde perceptie of van te hoog gespannen verwachtingen of doelstellingen? Zo ja, dan geen probleem om aan te werken. Maar al te vaak is er in de praktijk sprake van problemen die voortkomen uit een ideologische wens om dingen 'volgens het boekje' geregeld te hebben, terwijl er geen negatieve gevolgen van het voortbestaan van die zogenaamde problemen zijn. Als men aan een dergelijk
16
probleem gaat werken blijkt na enige tijd vaak dat er geen probleemhebbers, d.w.z. mensen die zich voor de oplossing van het probleem willen inzetten, meer over zijn. Bij JEEKAA vervalt probleem 3 omdat er geen probleemhebber is, terwijl de problemen 1 en 2 vervallen omdat het perceptieproblemen zijn. Bij de tweede stap worden de problemen geanalyseerd door naar de mogelijke gevolgen en oorzaken te kijken. De gevolgen van een probleem moeten worden ingeschat qua ernst (b.v. als ernstig, lastig en niet-lastig), omvang en groeitendens. Bij elk probleem moet worden getracht de oorzaak aan te wijzen, b.v. aan de hand van het gebruiken van een referentiemodel (een beschrijving van hoe het eigenlijk hoort) (Tansley and Hayball, 1993). Referentiemodellen voor administratie worden o.a. door Starreveld (1997a) gegeven. Indien noodzakelijk moet de structuur van de probleemkluwen ontward, bijvoorbeeld door het geven van een symptoom-probleem-oorzaak diagram. Bij JEEKAA zijn de problemen 4 en 5 als probleem ernstig omdat ze tot aanzienlijk minder verkopen leiden en zo de effectiviteit van een kernactiviteit van het bedrijf aantasten. De problemen 6, 7, 8 en 9 zijn lastig omdat ze wijzen op een ongewenste tijdrovendheid en gebrekkigheid van de gevoerde administratie. De problemen 4, 5, 6 en 7 worden veroorzaakt door het ontbreken van een goede administratieve procedure voor het inkopen. Probleem 8 wordt veroorzaakt door de afwezigheid van een bestand met framenummers van verkochte fietsen en bijbehorende klanten. Probleem 9 wordt veroorzaakt door een gebrekkige facturenadministratie. Bij de derde stap worden uit de nu resterende ernstige en lastige problemen die problemen gekozen die goed door het ontwikkelen van een informatiesysteem op te lossen zijn. Men komt zo tot de eerste afbakeningsbeslissing: Welk deel van de problemen ga ik oplossen? Bij JEEKAA zullen de problemen 4, 5, 6 ,7 en 8 worden opgelost. 2.3.4. De oplossingsrichting schetsen De te kiezen oplossingsrichting volgt als het goed is uit de aangewezen oorzaken en is vaak gebaseerd op het gebruikte referentiemodel (b.v. een procedure die te vinden is in handboeken voor administratieve organisatie). Geef bij de oplossingsrichting ook aan wat de organisatorische gevolgen zijn van de gekozen oplossing (Zie Bots e.a. p.361). Geef ook aan welke klassen gebruikers van het systeem kunnen worden onderscheiden.
Bij JEEKAA wordt ervoor gekozen om een betere procedure voor het inkopen te realiseren, ondersteund door de computer. In deze procedure zal voor de fietsen een basisassortiment worden gehanteerd dat jaarlijks wordt vastgesteld aan de hand van een overzicht van de verkopen in het voorgaande jaar en de catalogi van de leveranciers. Voor goed lopende typen en voor accessoires zal een bestelformule worden gehanteerd om de optimale bestelhoeveelheid te bepalen. Deze luidt: bestelkosten∗ vraagprognose bestelhoeveelheid = 2∗ voorraadkosten Daarnaast zullen de framenummers van de verkochte fietsen en de bijbehorende klanten in een computerbestand worden vastgelegd, dat wordt gevoed door een registratie bij de verkoop. Het is de bedoeling dat het te realiseren informatiesysteem informatie kan uitwisselen met de facturenadministratie en de financiële administratie, waarvoor een standaardpakket zal worden aangeschaft. De organisatorische gevolgen zullen zijn dat zowel 17
de verkopers als de inkoper van de computer gebruik moeten leren maken. Eén van de technici/ verkopers zal als systeembeheerder gaan werken ene daarvoor een cursus gaan volgen. Als klassen gebruikers van het te realiseren systeem kunnen worden onderscheiden: de inkoper, de verkopers, de accountant/ administratieconsulent, en de systeembeheerder. 2.4. Informatie-analyse 2.4.1. Actoren en communicatie Het gekozen probleemgebied kan worden beschreven in termen van interne actoren (afdelingen, gebruikersgroepen, eventueel mensen) en externe actoren (klanten, leveranciers e.d.). Een actor is een persoon of een groep van personen die een rol vervult. Een persoon kan eventueel worden opgesplitst in de verschillende rollen die hij vervult en komt dan overeen met meerdere actoren. Dit is vooral bij kleine organisaties van belang. In de JEEKAA-case zijn de volgende actoren te onderscheiden: Binnen de organisatie: de verkopers; de inkoper (Jeen Kaats treedt als zodanig op). Buiten de organisatie: fietsenfabrieken, de leveranciers; klanten; derden (politie, verzekeringsmaatschappijen).
Het is mogelijk actoren en communicatie tussen actoren weer te geven met behulp van een Data Flow Diagram (DFD). We noemen deze toepassing van de DFD tekentechniek een actor-communicatie-diagram. De communicatie wordt beschreven in termen van de uitgewisselde documenttypen, die met pijlen worden weergegeven. In het actorcommunicatie-diagram verloopt de tijd van links naar rechts en van boven naar beneden (dit in tegenstelling tot gewone DFD's). De plaats van de pijlen is dus van belang. Lege formulieren mogen niet in het actor-communicatie-diagram voorkomen. We beginnen met het tekenen van de onderscheiden actoren en het trekken van de systeemgrens. In het actor-communicatie-diagram wordt door het trekken van een systeemgrens aangegeven welke actoren door het informatiesysteem zullen worden ondersteund. In veel gevallen valt deze systeemgrens samen met de systeemgrens die zou worden getrokken op grond van de formele grenzen van een organisatie op grond van arbeidsrechtelijke verhoudingen, eigendomsverhoudingen of andere gezagsverhoudingen. Soms zijn deze twee soorten systeemgrenzen verschillend en men doet er dan goed aan ze beide expliciet aan te geven. Soms zijn er duidelijk te onderscheiden actorgroepen. Men moet dan voor elke actorgroep een systeemgrens trekken; dit betekent dat er ook meerdere informatiesystemen moeten komen (voor elke actorgroep één). Deze tweede afbakeningsbeslissing die men neemt is: Welke actoren zullen worden ondersteund? Bij JEEKAA zijn de gekozen actoren de inkoper en de verkoper. Er is sprake van het samenvallen van de 'ondersteunings'-systeemgrens met de organisatorische systeemgrens. Als er in het diagram organisatorische systeemgrenzen voorkomen, corresponderen de pijlen die de systeemgrens overschrijden met op de andere actor gerichte acties. Deze actor-gerichte acties hebben tot gevolg dat bij de betrokken actoren de wettelijke of cultureel bepaalde verplichtingenpositie verandert. Bij JEEKAA kunnen we bijvoorbeeld de actor-gerichte actie orderacceptatie onderscheiden die is neergeslagen in het ingevulde orderformulier. Deze actie geeft de verkoper de verplichting om de fiets te leveren en de klant de verplichting de bestelde fiets in principe af te nemen en te betalen. Actor-gerichte acties kunnen vragen zijn die een 18
antwoord verwachten, maar bijvoorbeeld ook wilsverklaringen die uiteindelijk een overeenkomst conform het verbintenissenrecht tot gevolg hebben, of handelingen die de prestatie leveren waardoor aan de verplichtingen in een overeenkomst wordt voldaan. Een ander voorbeeld van een actor-gerichte actie is de beschikking in de overheid, een actie die de toepassing van wet-en regelgeving op een individueel geval inhoudt. Het opbouwen van de verschillende communicaties kan op twee manieren geschieden: op grond van impulsen (triggers) en op grond van stromen. Bij organisaties die sterk zijn gekoppeld aan een fysieke stroom wordt het actor-communicatie-diagram opgebouwd op grond van stromen. Allereerst wordt de hoofdstroom van het productieproces getekend. Dit is in het geval van JEEKAA een fysieke stroom, namelijk die van de fietsen. Deze gaan van leverancier naar inkoper, van inkoper naar verkoper, en van verkoper naar klant. Tegengesteld aan de fysieke stroom gaat de geldstroom vanuit klant via verkoper en inkoper naar de leverancier. Deze twee stromen worden bestuurd (en getriggerd) door besturingsimpulsen zoals het plaatsen van een order of annulering door de klant, het plaatsen van een bestelling door de inkoper, het zenden van facturen door leverancier en verkoper. Bij dienstverlenende bedrijven en overheidsorganisaties is veelal geen sprake van een duidelijke fysieke hoofdstroom. Hier kan men beter op grond van impulsen werken. In het diagram kunnen op grond van het voorkomen van impulsen (triggers) bedrijfsprocessen worden onderscheiden. Per gebeurtenis (ook impuls, event of trigger genoemd) kan een manier van afhandelen, een taak of activiteit, worden bepaald. Die activiteit kan uit een aantal stappen bestaan. Activiteitenreeksen die samenhangen worden samen in een bedrijfsproces geplaatst. Die samenhang kan bijvoorbeeld zijn gelegen in de manier van werken (b.v. de algemene verkooproutine die ervan uitgaat dat een fiets pas kan worden verkocht als hij binnengekomen is) of in een conversatie tussen actoren (b.v. de verkoop naar aanleiding van een wens van een klant). Nadat het bedrijfsproces is getriggerd worden verplichtingen gecreëerd door middel van een actor-gerichte actie. Daarna volgen er andere stappen, meestal volgens een door conventies bepaald scenario. Bij bedrijven is er veelal sprake van het aangaan van een overeenkomst in een aantal stappen, en het vervolgens voldoen aan de verplichtingen die volgen uit die overeenkomst. Het bedrijfsproces is pas beëindigd als er, soms na vele stappen, weer een vereffende verplichtingenpositie is ontstaan en men dus zonder verdere verplichtingen uiteen kan gaan. Als een dergelijk bedrijfsproces is afgesloten kan men het dan voltooide proces op een hoger niveau van beschouwing zien als een samenhangende transactie, een geheel van acties door de verschillende betrokken actoren waarbij op grond van een overeenkomst een uitwisseling van zaken of rechten heeft plaatsgevonden. Om te beginnen kan elk bedrijfsproces worden beschreven door de activiteiten (+ impulsen) die erin plaatsvinden. Bij JEEKAA kunnen op grond van impulsen de volgende vier bedrijfsprocessen worden onderkend: A. algemene verkooproutine: a. bestellen fietsen (trigger: het is maandag) (actor: inkoper): . opnemen voorraad; . opnemen aangevraagde fietsen; . invullen bestelformulier; . bewaren kopie bestelformulier; b. arriveren fietsen (trigger: fietsen komen binnen) (actor: inkoper): . bewaren vrachtbon;
19
c. d.
e.
. maken aantekening op bestelformulier (soms); . voorzien fietsen van prijs en opstellen in winkel; bewaren inkoopfactuur (trigger: binnenkomen factuur) (actor: inkoper); verkopen fietsen (trigger: klant wil fiets kopen) (actor: verkoper): . ter hand stellen van fiets; . invullen verkoopfactuur; . in ontvangst nemen verkoopbetaling; . doorslag 1 verkoopfactuur bewaren; . doorslag 2 verkoopfactuur naar verzekering; betalen inkoop (trigger: het is maandag) (actor: inkoper).
B.
verkopen naar aanleiding van wens klant: a. noteren vraag klant om fiets (trigger: klant wil fiets kopen uit catalogus) (actor: verkoper); b. (zie verder) verkopen op voorraad.
C.
annuleren bestellingen: a. noteren annulering door klant (trigger: klant annuleert) (actor: verkoper); b. annuleren bestelling bij leverancier (trigger: het is maandag) (actor: inkoper).
D.
beantwoorden vragen om informatie: a. noteren vraag om informatie (trigger: klant, politie of verzekering wil framenummer weten) (actor: verkoper); b. beantwoorden vraag om informatie (trigger: het is maandag) (actor: verkoper).
In het actor-communicatie-diagram worden de verschillende bedrijfsprocessen door middel van letters bij de pijlen aangegeven, terwijl cijfers de volgorde van de acties aangeven.
20
Het actor-communicatie-diagram kan het beste met een gewoon tekenpakket zoals het tekenpakket van MS-Word worden getekend. Geavanceerde pakketten zoals System Architect geven geen betekenis aan de plaats van de pijlen en gooien al gauw de pijlen in de war. Om het tekenen van deze diagrammen niet te complex te maken, kan ervoor worden gekozen om meerdere diagrammen te tekenen, bijvoorbeeld per bedrijfsproces één. Een alternatief voor actor-communicatie-diagrammen is de volgende reeks diagrammen die
te ondersteunen actoren, organisatorische systeemgrens
A4. fiets + prijsgegevens A8. verkoopbetaling
C2. notitie annulering
Verkoper
D1. vraag
Derde
D2. antwoord A5. fiets
B1. order C1. annulering
A6. verkoopfactuur A7. verkoopbetaling
Klant Actoren en communicatie in de huidige situatie bij JEEKAA samen dezelfde informatie-inhoud hebben: actoren en functionele relaties; use cases van de organisatie; actoren en informatie-uitwisseling. Een voordeel van deze diagrammen is dat ze met System Architect kunnen worden getekend. Het nadeel ervan is dat er meer diagrammen nodig zijn. Controleer het resulterende actor-communicatie-diagram door te letten op: conversaties: op elke vraag moet een antwoord komen; 21
-
de cirkel moet rond zijn, uitgaande van een order van een klant moet men via de tijdsvolgorde van de verschillende pijlen terug komen bij de klant; de goederenstroom en de geldstroom dienen tegengesteld te zijn. de logica van bedrijfsprocessen (b.v. offerte, bestelling, . . ., levering, betaling); de logica van bestuurlijke processen (b.v. verzoek, beschikking, bezwaar, beroep, uitspraak);
Als derde afbakeningsbeslissing worden die taken uitgekozen die door het te bouwen informatiesysteem zouden moeten worden ondersteund: Welke taken moeten door het informatiesysteem worden ondersteund? Voor JEEKAA zijn de volgende activiteiten (taken) uitgekozen: A. algemene verkooproutine: a. bestellen fietsen (trigger: het is maandag) (actor: inkoper): b. arriveren fietsen (trigger: fietsen komen binnen) (actor: inkoper): d. verkopen fietsen (trigger: klant wil fiets kopen) (actor: verkoper): B.
verkopen naar aanleiding van wens klant: a. noteren vraag klant om fiets (trigger: klant wil fiets kopen uit catalogus) (actor: verkoper); b. (zie verder) verkopen op voorraad.
D.
beantwoorden vragen om informatie: a. noteren vraag om informatie (trigger: klant, politie of verzekering wil framenummer weten) (actor: verkoper); b. beantwoorden vraag om informatie (trigger: het is maandag) (actor: verkoper).
In de beoogde nieuwe situatie is de communicatie tussen actoren anders omdat de verkopers zelf spoedbestellingen en annulering doorgeven naar de leverancier, met behulp van het te ontwikkelen fietsinformatiesysteem. Dit leidt tot het volgend, aangepaste, actorcommunicatie-diagram dat de herontworpen communicatie tussen de actoren weergeeft.
Actoren en communicatie voor de toekomstige situatie bij JEEKAA 2.4.2. Analyse van bedrijfsprocessen en taken De bedrijfsprocessen kunnen worden geanalyseerd met een uitgebreid actor-activity-diagram (AADX-diagram). Een belangrijk onderscheid van het AADX-diagram ten opzichte van het actor-communicatie-diagram is (1) dat de tijd expliciet wordt afgebeeld, (2) dat activiteiten binnen actoren worden onderscheiden, en (3) dat de triggers en condities op grond waarvan activiteiten beginnen worden weergegeven.
23
Klant
C
plaatsen order
Verkoper accepteren order
Inkoper notitie order of annulering klant
C
[fiets niet in voorraad]
[fiets in voorraad]
T
D
D
plaatsen annulering
kopen fiets
Leverancier
D
D
bestellen /
bestelformulier
annuleren fiets
fiets + vrachtbon accepteren annulering
leveren fiets
fiets + prijs
arriveren fiets
verkopen fiets
inkoopfactuur
schrijven inkoopfactuur
betalen
inkoopbetaling
fiets
T
verkoopfactuur
T
C
inkoopfactuur
betalen verkoopbetaling
verkoopfactuur
vragen naar framenummer
C
noteren vraag
vraag
T
beantwoorden vraag
antwoord op vraag
D
luisteren naar antwoord
D
mededelen antwoord op vraag
Bedrijfsprocesanalyse (AADX) diagram van de huidige situatie bij JEEKAA 24
Uit dit AADX-diagram volgt dat er een bottleneck zit in de bestelprocedure omdat eerst een notitie wordt gemaakt van de fiets die de klant wil bestellen en er vervolgens wordt gewacht tot de eerstvolgende maandag. Ook moet worden geconstateerd dat de kopie van het bestelformulier en de vrachtbon niet met elkaar worden vergeleken omdat dit teveel werk is. De gebruikte symbolentaal voor bedrijfsprocesanalyse is deels ontleend aan de Role Activity samenwerkingstaak die doorgaat zolang de deelnemende actoren willen meewerken individuele taak die plaatsvindt zodra er tijd / gelegenheid voor is en er werk voorhanden is T
individuele taak die op vast tijdstip / met vaste frequentie plaatsvindt mits er werk voorhanden is (batchverwerking)
C
individuele taak die plaatsvindt mits aan bepaalde condities is voldaan en mits er werk voorhanden is voorraad documenten / objecten die werk betekenen samenwerkingsverband (koppeling van samanwerkingstaken) waarbij het initiatief van beide partijen kan uitgaan samenwerkingsverband waarbij het initiatief van de actor uitgaat waar de pijl begint tussen taken: de ene taak triggert de andere pijl van taak naar voorraad: deelactiviteit van taak voegt document of object aan voorraad toe pijl van voorraad naar taak: deelactiviteit van taak neemt document of object uit voorraad en (logisch AND) boogje tussen uitgaande of inkomende pijlen: beide deelactiviteiten moeten worden gerealiseerd géén boogje tussen uitgaande of inkomende pijlen betekent logisch OR: slechts één van beide deelactiviteiten kan worden gerealiseerd voorwaarde waaronder verder verloop van het werk plaatsvindt; inhoud voorwaarde staat er in de regel bij tussen vierkante haken []
Gebruikte symbolen in bedrijfsprocesanalyse (AADX) diagrammen Diagrams van Ould (1985), en deels aan de Petrinet-notatie (Reisig, 1985). In het bedrijfsprocesanalyse-diagram zijn er van boven naar beneden lopende tijdslijnen voor elk der actoren (aangegeven door een gestippelde lijn). Als een actor op de tijdslijn niet bezig is met werk, moet hij/ zij wachten. De tijdslijn van een actor kan zich splitsen; hij/ zij doet
25
dan parallelle activiteiten. Taken worden door blokjes weergegeven, voorraden door rondjes. In Petrinet-taal: de taken (blokjes) zijn transformaties en de voorraden (rondjes) zijn kanalen. Objecten die werk betekenen, zoals documenten, grondstoffen, halffabrikaten en producten stromen door het diagram en kunnen in een voorraad worden opgeslagen. Een taak wordt actief (schakelt, gaat werken) als een object uit één der toeleverende kanalen kan worden genomen (mits aan bepaalde voorwaarden is voldaan). Triggers worden aangegeven met de letters C (conditie, d.w.z. onder een bepaalde conditie wordt een taak actief) en T (tijd, d.w.z. op een bepaald tijdstip wordt een taak actief) die in de taakblokjes kunnen voorkomen. Het voltooien van een bepaalde taak kan de volgende taak triggeren; dit wordt door middel van een open pijl aangegeven van de eerdere naar de opvolgende taak. Er zijn vier typen taken: samenwerkingstaak die plaatsvindt op initiatief van één der actoren en doorgaat zolang de deelnemende actoren willen meewerken (twee door een lijn verbonden witte blokjes); individuele taak die plaatsvindt zodra er tijd en gelegenheid voor is en er werk voorhanden is (zwart blokje); individuele taak die plaatsvindt op een vast tijdstip of met een vaste frequentie mits er werk voorhanden is; dit wordt meestal batchverwerking genoemd (zwart blokje met letter T); individuele taak die plaatsvindt mits aan bepaalde condities is voldaan en mits er werk voorhanden is (zwart blokje met letter C). Deze vier typen taken komen overeen synchronisatiemechanismen (Birtwistle, 1979).
met
vier
in
de
simulatie
bekende
Taken kunnen taken à charge zijn , waarbij een actor werk aanneemt, en taken à décharge, waarbij een actor een bepaalde hoeveelheid werk afrondt en het resultaat aan de opdrachtgever teruggeeft. Taken à charge worden met een C aangeduid; taken à décharge met een D. Sommige taken zijn beslispunten: er zijn daar meerdere vervolgtrajecten mogelijk en er wordt beslist naar welk vervolgtraject het object toe gaat. De mogelijke verdere afwikkelingspaden worden met driehoekige symbolen aangegeven; de condities voor een bepaald afwikkelingspad worden daarbij tussen vierkante haken vermeld. Het is van belang de status van de in het AADX-diagram voorkomende voorraden (Petrinet kanalen) nader te onderzoeken. Deze zijn immers de in de logistiek bekende ontkoppelpunten. Deze ontkoppelpunten kunnen de status hebben van klantorderontkoppelpunt of verzamelpunt; dit moet dan expliciet worden vastgelegd. Een nogal vereenvoudigd bedrijfsprocesdiagram kan worden getekend met de System Architect module OMT event trace (zie hieronder)
26
Klant
Verkoper
T. elke eerste van de maand B1.Plaatsen order Accepteren order
Inkoper
Leverancier
Geven verkoopprognose B2.Geven notitie order
C1.Plaatsen annulering Accepteren annulering C2.Geven notitie annulering T. elke maandag
A1/C3.Bestellen/ Annuleren Bestelling Zenden orderbevestiging A2.Leveren fiets door leverancier
A4.Geven fiets en prijsgegevens
Tekenen ontvangstbewijs
S. fiets is in de verkoop Kopen fiets A5.Leveren fiets aan klant Doorgeven verkoopgegevens A6.Zenden verkoopfactuur A7.Betalen fiets A8.Doorgeven betaling
Derde
T. maandag om de week
A3.Zenden inkoopfactuur A9.Betalen inkoop
D1.Stellen vraag over framenr C. zodra er tijd is D2.Beantwoorden vraag framenr
Actoren en informatieuitwisseling in de huidige situatie bij JEEKAA [OMT Event Trace]
In de business process redesign school (Hammer, 1990) wordt bij het herontwerp van bedrijfsprocessen onder meer naar het volgende gekeken: 1. onderzoek de breuklijnen in de bedrijfsprocessen (zoals opnieuw invoeren van dezelfde gegevens) en ruim deze uit de weg; 2. schrap alle materiële voorraden behalve de directe werkvoorraden, de klantorderontkoppelpunten en de verzamelpunten; 3. schrap voorraden documenten die met de computer niet meer nodig zijn; 4. probeer complexe processen met veel uitzonderingen te vereenvoudigen door ze te splitsen in een netwerk van eenvoudige, gestandaardiseerde, processen; 5. schrap controle en beheersingsactiviteiten die geen toegevoegde waarde hebben;
27
6. 7. 8.
schrap onnodige stappen in de bedrijfsprocessen (o.a. door verruiming van verantwoordelijkheden kan de overdracht van een taak van actor naar actor veelal vervallen); maak de capaciteit van de organisatie groter door flexibele inzet van personeel (o.a. mogelijk gemaakt door taakverbreding) en parallel werken; zorg voor betere specificaties en snellere feedback zodat werk niet over gedaan hoeft te worden, o.a. door het werk dicht bij de klant te brengen.
Het toepassen van deze principes betekent veelal dat allerlei overbodig werk kan worden geschrapt en dat wachttijden vervallen. Bij JEEKAA kan op grond van principe 3 de voorraad notities met orders van klanten geschrapt en wordt het noteren van de wens van een klant vervangen door een spoedbestelprocedure. Bij JEEKAA kunnen de verkopers hun taak verbreden door ook spoedbestellingen te doen (toepassing van principe 7), waardoor de tijdrovende overdracht van werk aan de inkoper kan worden vermeden. Eén van de verkopers kan worden opgeleid tot systeembeheerder en zal ook de administratieve controles op de binnengekomen fietsen (kloppen ze met bestelformulier en factuur) voor zijn rekening nemen (dit betekent een kwaliteitsverbetering van de administratie). Met behulp van de computer kan ook het beantwoorden van vragen naar framenummers vereenvoudigd worden. Voor het herontworpen bedrijfsproces moet een nieuw AADX-diagram worden getekend.
28
Klant
C
plaatsen order
Verkoper accepteren order
D
[fiets niet in voorraad]
D
accepteren annulering
bestellen
bestelling
fiets + vrachtbon
leveren fiets
T
fiets + prijs
D
kopen fiets
Leverancier
C
[fiets in voorraad] plaatsen annulering
Inkoper
D
arriveren fiets
afgetekende vrachtbon
verkopen fiets
inkoopfactuur
schrijven inkoopfactuur
betalen
inkoopbetaling
fiets
T
verkoopfactuur
inkoopfactuur
betalen
T
verkoopfactuur
verkoopbetaling
vragen naar
beantwoorden vraag
framenummer
Bedrijfsprocesanalyse (AADX) diagram van de toekomstige situatie bij JEEKAA 2.4.3. Informatiegebruik bij het uitvoeren van taken Na het bekijken van actoren en hun communicatie, en van bedrijfsprocessen en taken, wordt nu aandacht besteed aan de manier waarop taken worden vervuld op het punt van informatiegebruik en beslissingsregels. Het uitvoeren van taken kan vaak beter (met name rationeler) als beslissingsregels worden gehanteerd die bewezen hebben goed te werken en daarom in handboeken e.d. zijn vermeld en er gebruik wordt gemaakt van informatie die
29
voorhanden is om die beslissingsregels te voeden. Het gebruik van informatie en van beslissingsregels zal door middel van ISAC-A-schema's worden weergegeven. Het is nodig om eerst de ingaande en uitgaande documenttypen te inventariseren en ook de aanwezige bestanden. Dit geeft een referentiekader voor de hierna te maken ISAC-Aschema's. De ingaande documenttypen uit het actor-communicatie-diagram, met tussen haakjes de actor waarvan het document afkomstig is zijn in het geval van JEEKAA: A2. fiets + vrachtbon (leverancier); A3. inkoopfactuur (leverancier); A8. verkoopbetaling (klant); B1. order klant (klant); C1. annulering door klant (klant); D1. vraag over framenummer (derden). De uitgaande documenttypen uit het actor-communicatie-diagram, met tussen haakjes de actor waar het document naar toe gaat: A1. bestelformulier (leverancier); A5. fiets (klant); A6. verkoopfactuur (klant); A9. inkoopbetaling (leverancier); C3. annulering bij leverancier (leverancier); D2. antwoord (derden). De bestanden (ordners, stapels documenten, kaartenbakken, computerbestanden, e.d. die nu worden bijgehouden en/ of gebruikt bij JEEKAA zijn: A1. kopie bestelformulieren; A2. fietsen met vrachtbron; A2a. vrachtbonnen; A3. inkoopfacturen; A4. fietsen met prijsgegevens; A6. doorslagen van verkoopfacturen; A7. verkoop-betalingsafschriften; A9 inkoop-betalingsafschriften; B2. notities met orders klanten (o.a. met NAW gegevens klant); C2. notities met annulering door klanten; C3. kopie annuleringen van bestellingen;
30
D1. notities met vragen van derden. Als men één ISAC-A-schema voor het gehele nu afgebakende probleemgebied gaat tekenen 1A
ISAC-A-schema van de huidige situatie bij JEEKAA komen boven de streep de ingaande documenttypen uit het actor-communicatie-diagram, en onder de uitgaande documenttypen uit het actor-communicatie-diagram. Voor de activiteiten bekijken we onze lijst met bedrijfsprocessen en taken. De taken zijn daarbij al onderscheiden naar actor en impuls (ritmiek). Dit leidt tot het volgende ISAC-A-schema voor JEEKAA (huidige toestand). Het is mogelijk een ISAC-A-schema te tekenen met System Architect, module Flowchart.
31
De grondgedachte achter ISAC is de informatieprecedentie: informatie gaat vooraf aan andere informatie. ISAC stamt uit de tijd dat automatisering in de meeste gevallen gelijk stond met het automatisch produceren van documenten zoals facturen, rekeningen en overzichten. Met de ISAC schematechniek kan helder worden weergegeven welke activiteiten en gegevens nodig zijn om een bepaald document te maken. Bij informatiesystemen waar interactie met de gebruiker door middel van een grafische interface voorop staat, zoals in veel moderne informatiesystemen, is de ISAC methode slechts beperkt bruikbaar. In een ISAC-A-schema moet nagegaan kunnen worden welke informatie wordt gebruikt bij een bepaalde taak. In het bij het schema behorende tekstblad wordt beschreven welke beslissingsregels bij het uitvoeren van taken gelden. In het geval van JEEKAA is het zinvol om de activiteit bestellen fietsen verder te analyseren. Deze analyse luidt als volgt. De inkoper maakt gebruik van de stapel notities met orders van klanten en de fysieke voorraad fietsen om na te gaan wat besteld moet worden. Het tellen van de aanwezige fietsen is tijdrovend. Uit een vervolginterview met de inkoper blijkt dat hij bestelt wat door de klanten is besteld (op grond van notities) en wat volgens hem ontbreekt in het standaard-assortiment (op grond van het opnemen van de voorraad). Zijn formule voor het inkopen luidt als volgt: I = F + (A−V ) I : verzameling in te kopen fietsen F: verzameling door klanten bestelde fietsen die niet in voorraad is A : verzameling fietsen die geldt als basisassortiment voor dit kwartaal (dames en herenfiets van de meest verkochte typen) V: verzameling fietsen in voorraad Deze formule moet op het tekstblad worden opgenomen.
De manier waarop taken worden uitgevoerd kan worden geoptimaliseerd. Het is hierbij vaak nodig om de manier van administreren of beslissen zoals het volgens het boekje (b.v. Starreveld) hoort te combineren met de nodige pragmatische overwegingen om de nieuwe manier van werken ook praktisch aanvaardbaar/ uitvoerbaar te maken. In het geval van JEEKAA is het wenselijk om het reageren op een order van een klant te veranderen door een spoedbestelprocedure toe te passen. In deze procedure zal een (lichte) toets kunnen worden verwerkt in verband met de kredietwaardigheid van een klant, om bijvoorbeeld bekende wanbetalers uit te sluiten (vermeld deze procedure op het tekstblad van het nieuwe ISAC-A-schema). Ook annuleringen zouden op een dergelijke manier moeten worden verwerkt. Vanuit een oogpunt van rationalisatie is het onwenselijk om steeds weer de fysieke verzameling fietsen te moeten tellen. Het is gewenst dat de verzameling voorradige fietsen in de computer is vastgelegd om het tellen te vermijden. Dit betekent dat het verkopen van fietsen en het controleren van gearriveerde fietsen anders zal gaan omdat het een en ander met behulp van de computer moet worden geregistreerd. Deze registratie zal plaatsvinden met behulp van een te realiseren fietsinformatiesysteem. Evenmin is het rationeel om met een niet expliciet gemaakt basisassortiment te werken. Het werken met een basisassortiment moet expliciet worden gemaakt en door de computer worden ondersteund. Hierbij kan b.v. per kwartaal een basisassortiment worden vastgesteld n.a.v. de catalogi van de leveranciers en de voorspelde vraag. Wekelijks zou dit basisassortiment kunnen worden aangevuld. Voor fietsen en accessoires die goed lopen kan met behulp van de 32
bestelformule wekelijks een optimale bestelhoeveelheid worden bepaald. Deze bestelformule (zie Paragraaf 2.2.4) moet op het tekstblad van het ISAC-A-schema voor de nieuwe situatie worden vermeld. Voor de nieuwe situatie, voorzover qua informatiegebruik of beslisregels afwijkend van de oude, moeten een ISAC-A-schema's (inclusief tekstblad) worden gegeven. Bij het tekenen van dit nieuwe ISAC-A-schema kan het actor-communicatie-diagram van de nieuwe situatie goede diensten bewijzen om de ingaande en uitgaande documenttypen op te sporen. Uit dit nieuwe ISAC-A-schema kunnen we de gewenste functionaliteit van het te realiseren fietsinformatiesysteem aflezen. Dit fietsinformatiesysteem ondersteunt de taken spoedbestelling (verkoper), annuleren bestelling (verkoper) en bestellen fietsen (inkoper) op een interactieve manier (d.w.z. er is zowel invoer als uitvoer naar/ van het systeem). De taken arriveren fietsen (inkoper) en verkopen fietsen (verkoper) voeden het fietsinformatiesysteem. De taken betalen inkoop (inkoper) en beantwoorden vragen (verkoper) maken gebruik van informatie uit het fietsinformatiesysteem. De binnenkomst van een order van een klant, een annulering door een klant en een vraag van derden wordt nu direkt afgewerkt met behulp van het fietsinformatiesysteem. Bij de binnenkomst van een inkoopfactuur wordt deze nog steeds eerst opgeborgen en pas later betaald. De financiële taken rond facturen en betalen zullen immers niet door het nieuwe informatiesysteem worden ondersteund; hiervoor is een ander informatiesysteem gepland. Wel levert het fietsinformatiesysteem informatie ten behoeve van de inkoopfactuurcontrole.
ISAC-A-schema voor de toekomstige situatie bij JEEKAA 2.5. De organisatorische gebruiksmogelijkheden (use cases) De organisatorische use cases (gebruiksmogelijkheden) beschrijven in eerste instantie het gedrag van een organisatie dat waarneembaar is van buiten af, vanuit het gezichtspunt van een actor die met deze organisatie interacteert. In tweede instantie worden ook transformaties, interne overdrachten van enig belang en besturingsactiviteiten meegenomen. Deze use cases kunnenop vier niveau’s van detaillering worden beschreven: de transactie, de DEMOtransactie, de interactie en de actie.
34
Het actor-interactiediagram geeft aanwijzingen over de organisatorische use cases op het niveau van de actie en op het niveau van de transactie. De berichten die tussen actoren worden uitgewisseld komen overeen met use cases op actieniveau. Deze berichten zijn geordend in processen, en elk proces komt min of meer overeen met een transactie. Dit betreft de use cases aan de buitenkant. Kijken we binnen de organisatie met het bedrijfsprocesanalysediagram dan zien we daarin ook allerlei interne activiteiten namelijk overdrachtsacties (actieniveau), transformaties (actieniveau) en soms diverse besturingsacties (zoals controle, goedkeuring, etc.). Dit geeft een aanvulling en correctie op de use cases op actieniveau. Bovendien kan het bedrijfsprocesanalysediagram nieuwe inzichten geven over de ordening van activitwiten in interacties, DEMO-transacties en transacties. In het geval van JEEKAA kunnen op transactieniveau de volgende use cases worden onderscheiden: 1. de inkoop bij leveranciers; 2. de verkoop aan klanten; 3. het beantwoorden van vragen over framenummers door derden. Externe actoren zijn dus de leverancier, de klant en de derde. Als we deze use cases willen beschrijven op DEMO-transactieniveau, moeten we kijken naar de producten, diensten, geldhoeveelheden, e.d. die worden uitgewisseld. We zien al gauw dat de inkooptransactie bestaat uit het leveren van goederen door de leverancier en het betalen van de geleverde goederen door JEEKAA. Iets dergelijks geldt ook voor de verkoop. Het beantwoorden van vragen is verder niet op te splitsen, het is een door JEEKAA geleverde dienst zonder tegenprestatie. Voor het verder detailleren tot op interactieniveau moeten we de DEMO-transacties, waar toepasselijk, splitsen in bestellen en leveren. Verder herinneren wij ons nog dat volgens de transactiekosteneconomie twee fasen (te interpreteren als interacties) aan de prestatie en tegenprestatie vooraf kunnen gaan, namelijk het contact en het contract. Deze fasen zijn bij de inkoop aanwezig; bij de verkoop is alleen de bestelling aanwezig. Na de prestatie en de tegenprestatie kan er service worden geleverd. Bij de verkoop bestaat deze service o.a. uit het beantwoorden van vragen. Op deze manier krijgen we de volgende organisatorische gebruiksmogelijkheden (use cases) op interactieniveau: 1. uitbrengen offerte van de leverancier aan JEEKAA (de inkoopofferte); 2. bestellen van JEEKAA bij de leverancier (de inkoopbestelling); 3. leveren van goederen aan JEEKAA door leverancier (de inkooplevering); 4. betalen van geleverde goederen aan de leverancier door JEEKAA (de inkoopbetaling); 5. bestellen van goederen door de klant bij JEEKAA (de verkoopbestelling); 6. leveren van goederen aan de klant door JEEKAA (de verkooplevering); 7. betalen van geleverde goederen aan JEEKAA door de klant (de verkoopbetaling); 8. het beantwoorden van vragen van derden door JEEKAA (de beantwoording). Bij nadere bestudering blijkt de inkoopbestelling te moeten worden onderscheiden in: 2a. reguliere inkoopbestelling; 2b. spoed-inkoopbestelling; 2c. annulering inkoopbestelling. Het blijkt namelijk dat er drie soorten bestelactiviteiten zijn: de spoedbestelling voor een klant als een fiets niet op voorraad is, de annulering van een bestelling en de reguliere inkoopbestelling. Omdat deze drie typen inkoopbestelling verschillen in hun afhandeling moeten ze als verschillende use cases worden aangemerkt.
35
2.6. De informatiesysteem gebruiksmogelijkheden (use cases) 2.6.1. De gebruiksmogelijkheden (use cases) voor procesuitvoering De gewenste gebruiksmogelijkheden (use cases) van een informatiesysteem worden in drie stappen afgeleid uit de organisatorische use cases op actieniveau: 1. selecteren van die organisatorische use cases op interactieniveau die het informatiesysteem moet ondersteunen of automatisch uitvoeren (dit zijn de use cases voor procesuitvoering); 2. aanvulling van deze use cases met use cases m.b.t. informatiegebruik die volgen uit het ISAC-A schema; 3. toevoegen van use cases voor de ondersteuning van informatiebeheer; 4. toevoegen van use cases voor de ondersteuning van systeembeheer. Voor de JEEKAA case gaat dit als volgt. De oorspronkelijke organisatorische use cases op interactieniveau waren: 1. verzoeken om offerte van de leverancier aan JEEKAA (de inkoopofferte); 2. bestellen van JEEKAA bij de leverancier (de inkoopbestelling); 2a. reguliere inkoopbestelling; 2b. spoed-inkoopbestelling; 2c. annulering inkoopbestelling; 3. leveren van goederen aan JEEKAA door leverancier (de inkooplevering); 4. betalen van geleverde goederen aan de leverancier door JEEKAA (de inkoopbetaling); 5. bestellen van goederen door de klant bij JEEKAA (de verkoopbestelling); 6. leveren van goederen aan de klant door JEEKAA (de verkooplevering); 7. betalen van geleverde goederen aan JEEKAA door de klant (de verkoopbetaling); 8. het beantwoorden van vragen van derden door JEEKAA (de beantwoording). Voor het fietsinformatiesysteem wordt besloten dat dit zich niet bezig gaat houden met financiële zaken. Dit betekent dat de use cases 4 en 7 niet door het fietsinformatiesysteem zullen worden ondersteund. Ook wordt er van afgezien om de offertes (use case 2) via het informatiesysteem te registreren. Dit leidt tot de volgende use cases voor het fietsinformatiesysteem m.b.t. de procesuitvoering. Procesuitvoering: (opnieuw genummerd!) 1. reguliere inkoopbestelling door JEEKAA bij de leverancier (regulier bestellen) (actor: inkoper; trigger: het is maandag); 2. spoed-inkoopbestelling door JEEKAA bij de leverancier (spoedbestelling) (actor: verkoper; trigger: klant wil fiets kopen die niet in voorraad is); 3. annulering inkoopbestelling door JEEKAA bij de leverancier (annuleren bestelling) (actor: verkoper; trigger: klant annuleert); 4. leveren van goederen aan JEEKAA door leverancier (inkooplevering) (actor: inkoper; trigger: fietsen komen binnen); 5. bestellen van goederen door de klant bij JEEKAA (verkopen) (actor: verkoper; trigger: klant wil fiets kopen); 6. leveren van goederen aan de klant door JEEKAA (verkooplevering) (actor: verkoper; trigger: fiets is klaar om geleverd te worden); 7. het beantwoorden van vragen van derden door JEEKAA (beantwoorden vragen) (actor: verkoper; trigger: vraag wordt gesteld).
36
Deze use cases kunnen als volgt worden afgebeeld. Regulier bestellen
Leverancier
Inkoper
Spoedbestelling
Annuleren bestelling
Inkooplevering
Verkopen
Klant
Verkoper
Verkoop levering
Derde Beantwoorden vragen
2.6.2. De gebruiksmogelijkheden (use cases) voor informatiebeheer en systeembeheer Hieraan worden toegevoegd de gebruiksmogelijkheden (use cases) van het informatiesysteem voor informatiebeheer en systeembeheer: Een informatiesysteem ondersteunt taken altijd op grond van gegevens die over objecten in de wereld zijn geregistreerd. Het registreren van objecten dicht bij de bron is dan ook een belangrijke taak die door informatiesystemen wordt ondersteund. Met name het up-to-date houden van gegevens (over b.v. actoren en typen) die niet gekoppeld zijn aan te ondersteunen gebeurtenissen is een apart te onderscheiden taak. Het toewijzen van het beheer van objecttypen is overigens een belangrijke beslissing. De bedoeling is dat degene die het meeste met bepaalde objecttypen werkt en de gegevens over de er onder vallende objecten ook in de meeste gevallen registreert de verantwoordelijkheid voor die objecttypen krijgt. Daarnaast zijn er redeneerregels nodig voor het informatiesysteem om bepaalde gevolgtrekkingen te kunnen maken en bepaalde simulaties of rapportages te kunnen verrichten. Deze redeneerregels (eventueel wettelijke regels) moeten ook zoveel mogelijk dicht bij de bron ervan worden geregistreerd. Soms zijn deze regels gebaseerd op expliciete of geëliciteerde kennis die door een knowledge engineer wordt onderhouden. Tenslotte is er werk nodig om het informatiesysteem zelf te onderhouden en in goede staat te houden: het systeembeheer. Op het gebied van systeembeheer zijn er meestal de algemene taken van het maken van back-ups, het opschonen van bestanden (o.a. door het wegschrijven van niet meer gebruikte gegevens in historische bestanden) en het beveiligen van de toegang door passwords e.d. Een en ander leidt voor JEEKAA tot de volgende gebruiksmogelijkheden voor informatiebeheer en systeembeheer.
37
Informatiebeheer: 8. klantgegevens beheren (actor: verkoper; trigger: verhuisbericht klant of ander bericht over klant komt binnen); 9. algemene fietsgegevens beheren (actor: inkoper; trigger: nieuwe catalogus komt binnen); 10. leveranciersgegevens beheren (actor: inkoper; trigger: verhuisbericht, naamsverandering, of ander bericht leverancier komt binnen); 11. bijwerken algemene gegevens (actor: systeembeheerder; trigger: organisatieverandering, verhuizing of ander relevante gebeurtenis). 12. inkoopformule en verwante regels beheren (actor: inkoper; trigger: veranderde inzichten). Systeembeheer: 13. maken backup (actor: systeembeheerder: trigger: het is 8.00 uur); 14. opschonen bestanden (actor: systeembeheerder; trigger: het is 1 januari); 15. beveiliging (actor: systeembeheerder; trigger: het is de eerste van de maand, diversen). Een en ander leidt dus tot 15 gebruiksmogelijkheden (use cases) van het fietsinformatiesysteem, die samen bepalen wat het fietsinformatiesysteem geacht wordt te doen in de organisatie. 2.6.3. Verbanden tussen use cases Met name voor de use cases voor procesuitvoering is het van belang mogelijke verbanden tussen use cases te onderzoeken. Die verbanden worden onderscheiden op het aanwezig zijn van gemeenschappelijke elementen in de afhandeling van use cases. Het onderkennen van gemeenschappelijke elementen in de afhandeling maakt het mogelijk om de afhandeling daarvan door het informatiesysteem slechts éénmaal in te programmeren in plaats van meerdere malen. Verder kan soms tot een meer logische afhandeling van taken worden besloten op grond van verbanden tussen use cases. Bij het onderzoeken van verbanden tussen use cases zijn beschrijvingen van scenario’s het uitgangspunt. Uit de voor JEEKAA gemaakte scenario’s blijkt dat het regulier bestellen en de spoedbestelling gemeen hebben dat er een bestelformulier wordt ingevuld en verzonden naar de leverancier. Deze gemeenschappelijke activiteit noemen we ‘bestellen’. De aan het ‘bestellen’ voorafgaande activiteiten bij het regulier bestellen noemen we ‘toepassen bestelformule’. De aan het ‘bestellen’ voorafgaande activiteiten bij de spoedbestelling noemen we ‘voortraject spoedbestelling’. We kunnen dan noteren als verbanden tussen use cases: ‘regulier bestellen’ USES ‘toepassen bestelformule’; ‘regulier bestellen’ USES ‘bestellen’; ‘spoedbestelling’ USES ‘voortraject spoedbestelling’; ‘spoedbestelling’ USES ‘bestellen’. Het ‘bestellen’ zonder voortraject komt incidenteel ook voor. In dat geval kunnen we het ‘toepassen bestelformule’ en het ‘voortraject spoedbestelling’ zien als optionele uitbreidingen van het ‘bestellen’. We kunnen dus opschrijven: ‘toepassen bestelformule’ EXTENDS ‘bestellen’; ‘voortraject spoedbestelling’ EXTENDS ‘bestellen’. We zien dat de structuur die EXTENDS oplevert eenvoudiger is dan de structuur op grond van de USES relaties. Daarom vervangen we waar mogelijk de USES structuren door de meer eenvoudige structuren met EXTENDS. Dit geeft een ‘genormaliseerde’ use case structuur.
38
Het annuleren van een bestelling kunnen we zien als een optionele uitbreiding van het ‘bestellen’. Het komt dus ook voor bij het regulier bestellen en de spoedbestelling. Het is zelf een soort bestelling, maar dan in negatieve zin. Als voortraject moeten de gegevens over de te anlluren bestelling worden opgezocht. We schrijven daarom op: ‘voortraject annuleren bestelling’ EXTENDS ‘bestellen’. Verder kunnen we het hele proces van inkoop (de inkooptransactie) als één use case op een hoger niveau zien, evenals het hele proces van verkoop (de verkooptransactie). Deze transacties bestaan uit een aantal kleinere use cases. We schrijven op: ‘inkooptransactie’ USES ‘bestellen’; ‘inkooptransactie’ USES ‘inkooplevering’; ‘verkooptransactie’ USES ‘verkopen’; ‘verkooptransactie’ USES ‘verkooplevering’. Of men het beantwoorden van vragen als en service ziet die onderdeel is van de verkooptransactie is een kwestie van smaak. Wij rekenen het beantwoorden van vragen niet onder de verkooptransactie. Hieronder zijn deze verbanden tussen use cases schematisch weergegeven. Daarbij zijn de gewone, getrokken pijlen de USES relaties en de gestippelde pijlen de EXTENDS relaties. Toepassen bestelformule
2.6.4. Verdere uitwerking van use cases in scenario's Bij een verdere detaillering van deze use cases in scenarios kijken we naar de berichten die worden uitgewisseld en naar andere niet-talige overdrachten. Elke uitwisseling van goederen, diensten, geld, e.d. kunnen we immers zien als een niet-talige handeling die op gang moet 39
worden gebracht door talige handelingen (berichten zoals brieven, telefoongesprekken), en ook door talige handelingen als afgesloten moet worden verklaard. Voor deze verdere gedetailleerde beschrijving van use cases op het actieniveau is het eerder besproken standaardmodel van Dietz erg handig. Aan het produceren van een bericht gaan meestal enige stappen vooraf, waarbij informatie wordt gebruikt, bepaalde cognitieve taken worden verricht, en dergelijke. Bij het bepalen van die stappen kan het van nut zijn om naar het informatiegebruik te kijken dat in het ISAC-A-schema is afgebeeld. Een voorbeelduitwerking voor JEEKAA staat hieronder. 1.
bestellen 1.1. Verzoek tot leveren fietsen d.m.v. bestelformulier (JEEKAA Leverancier) invullen bestelformulier verzenden bestelformulier naar leverancier 1.2. Belofte tot leveren fietsen d.m.v. brief orderacceptatie (Leverancier JEEKAA) registratie orderacceptatie
2.
toepassen bestelformule opvragen gegevens bestelkosten, voorraadkosten en maken vraagprognose ten behoeve van de bestelformule uitrekenen te bestellen hoeveelheden met de bestelformule
voortraject annuleren bestelling opvragen klantgegevens opvragen gegevens over de te annuleren bestelling
5.
inkooplevering 5.1. Uitvoering van leveren fietsen d.m.v. fiets (Product) (Leverancier JEEKAA) registratie gegevens op grond van waarneming fiets en levering 5.2. Verklaring dat leveren fietsen is uitgevoerd d.m.v. vrachtbon (Leverancier JEEKAA) registratie gegevens vrachtbon 5.3. Aanvaarding van verklaring dat leveren fietsen is uitgevoerd d.m.v. aftekenen vrachtbon (JEEKAA Leverancier) opvragen bestelgegevens aftekenen vrachtbon registratie acceptatie levering
6.
verkopen 6.1. Verzoek tot levering fiets door klant d.m.v. mondeling of schriftelijk bericht JEEKAA) (Klant opvragen/invullen klantgegevens kredietwaardigheid nagaan opvragen fietsgegevens invullen verkoopformulier
40
verzenden verkoopformulier naar financiële administratie 6.2. Belofte tot leveren fietsen d.m.v. brief orderacceptatie (JEEKAA Klant) [indien mondeling verzoek dat meteen kan worden afgehandeld] mededelen dat bestelling is geaccepteerd [indien schriftelijk verzoek] maken brief aan klant over orderacceptatie [indien schriftelijk verzoek] verzenden brief orderacceptatie aan klant Bij de het laatste scenario zien we dat er twee verschillende afhandelingspaden zijn. In dat geval moeten we ook twee verschillende use cases onderscheiden, hetgeen weer een wijziging geeft in de verzameling informatiesysteem use cases. 7.
verkooplevering 7.1. Uitvoering van leveren fietsen d.m.v. fiets (Product) (JEEKAA Klant) registratie gegevens op grond van waarneming fiets en levering 7.2. Verklaring dat leveren fietsen is uitgevoerd d.m.v. vrachtbon ) (JEEKAA Klant) maken en geven vrachtbon 7.3. Aanvaarding van verklaring dat leveren fietsen is uitgevoerd d.m.v. aftekenen JEEKAA) vrachtbon (Klant aftekenen vrachtbon registratie acceptatie levering
We zien dat de verkooplevering erg veel lijkt op de inkooplevering. Dit komt ook door het toepassen van de methode Dietz voor de uitwerking van de use case. 8.
beantwoorden vragen JEEKAA) 8.1. Vraag over fiets door derde (Derde registratie vraag 8.2. Antwoord op vraag door JEEKAA (JEEKAA Derde) maken en mededelen antwoord registratie antwoord
2.7. Literatuur over gebruiksmogelijkheden (use cases) Algra, N.E., J.B.J.M. ten Berge en P.H. Sleurink. Poly-Juridisch Zakboekje. Arnhem: PBNA, 1986. Birtwistle, G.M. DEMOS: A system for discrete event modelling on Simula. Houndmills: MacMillan, 1979. Carley, K.M., and M.J.Prietula (eds.). Computational Organization Theory. Hillsdale, NJ: Lawrence Erlbaum Associates, 1994. Dietz, J.L.G. Introductie tot DEMO: Van informatietechnologie naar organisatietechnologie. Alphen a/d Rijn: Samsom, 1996. Dietz, J.L.G. Leerboek Informatiekundige Analyse. Deventer: Kluwer Bedrijfswetenschappen, 1992. Gale, Thornton, and James Eldred. Getting Results with the Object-Oriented Enterprise Model. New York: SIGS, 1996. Gazendam Henk W.M. Variety Controls Variety: On the Use of Organization Theories in Information Management. Groningen: Wolters-Noordhoff, 1993. Gazendam, Henk W.M., and René J.Jorna. "Theories about Architecture and Performance of Multi-Agent Systems." Paper presented at the III European Congress of Psychology, July 4-9-1993, Tampere, Finland. Hammer, Michael. “Reengineering Work: Don't Automate, Obliterate.”, Harvard Business Review, July-August 1990: 104-112. Jacobson, Ivar, Maria Ericsson, Agneta Jacobson. The Object Advantage: Business Process Reengineering with Object Technology. Wokingham, England: Addison-Wesley, 1994. Jorna, R.J., H.W.M.Gazendam, H.C.Heesen en W.M.C.van Wezel. Plannen en Roosteren: Taakgericht analyseren, ontwerpen en ondersteunen. Leiderdorp: Lansa, 1996.
41
Leeuw, A.C.J. de. Organisaties: Management, analyse, ontwerp en verandering: 3e druk. Assen: Van Gorcum, 1988. Newell, A., and H.A.Simon. Human Problem Solving. Englewood Cliffs, NJ: Prentice-Hall, 1972. Ould, Martyn A.. Business Processes: Modelling and analysis for re-engineering and improvement. Chichester: John Wiley, 1995. Reisig, W. Systementwurf mit Netzen. Berlin: Springer, 1985. Rumbaugh, James, Michael Blaha, William Premerlani, Frederick Eddy and William Lorensen. Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall, 1991. Russell, Stuart J., and Peter Norvig. Artificial Intelligence: A Modern Approach. Upper Saddle River, NJ: Prentice-Hall, 1995. Schmidt, K."Cooperative work: conceptual framework." In: J. Rasmussen, B. Brehmer and J.Leplat (eds.). Distributive decision making: cognitive models for cooperative work. Chichester: Wiley, 1991. Williamson, Oliver E. The Economic Institutions of Capitalism. New York: The Free Press, 1985. Starreveld, R.W., H.B. de Mare en E.J.Joëls. Bestuurlijke Informatieverzorging: Deel 2A: 4e druk. Alphen a/d Rijn: Samsom, 1997a. Starreveld, R.W., H.B. de Mare en E.J.Joëls. Bestuurlijke Informatieverzorging: Deel 2B: 4e druk. Alphen a/d Rijn: Samsom, 1997b. Tansley, D.S.W., and C.C.Hayball. Knowledge-Based Systems Analysis and Design: A KADS Developers Handbook. New York: Prentice-Hall, 1993
3. Objectmodel 3.1. Componenten van een informatiesysteem Veel informatiesystemen kunnen worden gezien als opgebouwd uit: 1. een kern bestaande uit een wereldbeeld of domeinmodel, een afbeelding van het relevante deel van de wereld (het domein) bestaande uit objecten die de wereld representeren (Paragraaf 3.3. en 3.4.); 2. een verzameling taakgerichte modules die ter ondersteuning van de gebruiker dan wel zelfstandig taken uitvoeren, waarbij het wereldbeeld wordt gebruikt en wordt bijgehouden en waarbij resultaten via documenten aan de gebruiker worden getoond (Paragraaf 3.5.); 3. een schil van zichtbare en bewerkbare documenten (b.v. formulieren en HTMLpagina’s) (Paragraaf 3.6.);
42
besturingselementen voor de gebruikers zoals knoppen, invoervelden, en menustructuren invoerdocumenten (schermen, formulieren, EDI-berichten) taakgerichte modules die taken van actoren ondersteunen wereldbeeld (tabellen in relationele structuur)
De componenten van een informatiesysteem 4. besturingselementen op de documenten voor de gebruiker zoals knoppen, invoervelden en menustructuren die ervoor dienen het wereldbeeld te wijzigen en de taakgerichte modules aan te sturen (Paragraaf 3.6.). In bovenstaande figuur wordt deze architectuur van een informatiesysteem weergegeven. Hierin komen de volgende symbolen voor die soorten objecten volgens de notatie van Jacobson (1992) weergeven.
43
domeinmodelobjecten: afbeeldingen van objecten in de wereld ("domeinmodel", "model" in MVC) taakobjecten: objecten die taken van actoren ondersteunen ("systeemfuncties") interfaceobjecten: documenten en andere zichtbare elementen in het interface, besturingselementen ("interface-objecten", "controller" en "view" in MVC) abstracte datatypen ("algemeen bruikbare programmamodules")
Soorten objecten volgens Jacobson Deze indeling van soorten objecten berust voor een deel op de Model-View-Controller (MVC) opvatting in het object-georiënteerd modelleren, waarbij de het modelleren van de wereld (model), het weergeven van dit model en andere objecten in het gebruikersinterface (view) en het besturen van het programma in reactie op de acties van de gebruiker (controller) als drie verschillende verantwoordelijkheden worden gezien. De domeinmodelobjecten hebben als verantwoordelijkheid een afbeelding van de toestand en het gedrag van de entiteiten in de voor het informatiesysteem relevante wereld (het domein) te maken en over die afbeelding informatie te verstrekken. Deze domeinmodelobjecten moeten zichzelf consistent houden. De taakobjecten hebben als verantwoordelijkheid de structuur van het proces van taakuitvoering af te beelden, de toestand (het punt waar men nu is) bij het proces van taakuitvoering te weten, bepaalde taakonderdelen zelf automatisch uit te voeren en informatie te verschaffen over de voortgang van een taak. Hierdoor kan een taakobject helpen bij het uitvoeren van een taak, onder meer door het aangeven van alternatieve uitvoeringspaden op een bepaald punt van afhandeling van de taak en door het doorsturen van documenten waaraan moet worden gewerkt naar degenen die de volgende bewerking moeten doen. Taakobjecten spelen een belangrijke rol in bijvoorbeeld workflowsystemen. Interfaceobjecten hebben als verantwoordelijkheid om de menselijke gebruiker informatie te tonen, en om bewerkingen en opdrachten van de menselijke gebruiker mogelijk te maken. Dit alles op een doorzichtige, begrijpelijke en samenhangende manier. Abstracte datatypen zijn objecten die gegeven een bepaalde datastructuur zoals een tabel, matrix of graaf, bepaalde bewerkingen op de meest efficiënte manier kunnen doen. Een voorbeeld de verzameling van diverse statistische bewerkingen op een datamatrix. Algemeen bruikbare programmamodules berusten vaak op abstracte datatypen. Het maken van een objectmodel is belangrijk omdat het over de kern van een informatiesysteem gaat, namelijk het model van de wereld dat het informatiesysteem kent. Zonder de elementen van een objectmodel, te weten objecttypen, associatietypen en attribuuttypen kan geen informatiesysteem bestaan. Voor het maken van een dergelijk model zijn er twee invalshoeken: een wiskundige en een filosofische. Er is gekozen voor de meer 44
filosofisch getinte methode, te weten objectgeoriënteerde modellering. Een eerste versie van het objectmodel kan met behulp van enkele regels ‘afgeleid’ worden uit de eerder gemaakte modellen, en vervolgens verfijnd. De gebruikte notatie is de OMT-notatie (Rumbaugh c.s, 1991), die later is uitgebreid tot de UML taal (Fowler and Scott, 1997). Bij de categorieënmethode voor het ontwerpen van een objectmodel voor het domein begint men met een lijst met categorieën. Deze categorieën worden toegepast op het te onderzoeken toepassingsgebied. Bij die toepassing definieert men de objecttypen waarover iets moet worden geregistreerd. In deze werkwijze zijn de volgende stappen te onderscheiden: het maken van een lijst met categorieën; het maken van een ruwe lijst met objecttypen op grond van eerdere schema's; het beslissen over de registratie van gebeurtenissen; het onderscheiden van structuren; het tekenen van het ruwe objectmodel; het onderzoeken en vereenvoudigen van het objectmodel; de uitwerking van het objectmodel door attribuuttypen en methoden toe te voegen. In deze tekst wordt aan de hand van de Case Fietsenhandel JEEKAA uiteengezet hoe een objectmodel voor het domein kan worden ontwikkeld met behulp van deze categorieënmethode. Daartoe wordt eerst het begrippennetwerk rond het begrip objecttype uiteengezet (paragraaf 3.2.). Daarna volgt een beschrijving van het opbouwen van een objectmodel voor het domein (paragraaf 3.3.). Het totale objectmodel dient niet alleen aandacht te besteden aan het domein maar ook aan de uit te voeren taken en aan het gebruikersinterface. Het objectmodel voor uit te voeren taken kan worden ontworpen in aansluiting aan de reeds onderscheiden use cases (Paragraaf 3.5.). Het objectmodel voor het gebruikersinterface gaat uit van de informatie, geordend in documenten, die voor de gebruiker zichtbaar moet zijn bij het uitvoeren van taken (Paragraaf 3.6.) . Deze drie perspectieven op het objectmodel moeten vervolgens worden geïntegreerd (Paragraaf 3.7.). De behandeling van het objectmodel bestaat daarom uit: 3.1. Objectmodel voor het domein top-down ontwikkeling (Paragraaf 3.3.) bottom-up ontwikkeling (normaliseren en bubble chart) (Paragraaf 3.4.) 3.2. Objectmodel voor taken (Paragraaf 3.5.) 3.3. Objectmodel voor het gebruikersinterface (Paragraaf 3.6.) 3.4. Geïntegreerd objectmodel (Paragraaf 3.7.) 3.2. Het begrippennetwerk rond het begrip 'objecttype' 3.2.1. Abstractie en reticulatie Bij het modelleren gekozen beschouwingsniveaus kunnen op twee manieren van elkaar verschillen: in de mate van reticulatie, d.w.z. de fijnmazigheid waarmee wordt gekeken, en in de mate van abstractie, d.w.z. de het kijken naar algemene eigenschappen en het afzien van individuele gevallen. Reticulatie is het proces waarbij men meer fijnmazig gaat waarnemen (De Leeuw, 1988: 105). Dereticulatie is het proces waarbij men minder fijnmazig gaat waarnemen. Als reticulatie delen van een geheel zichtbaar maakt die eerst niet zichtbaar waren spreekt men ook wel van decompositie. Het reticulatieniveau is de mate van fijnmazigheid waarmee een systeem wordt waargenomen en beschreven. Het verhogen van het reticulatieniveau zorgt dat andere verschijnselen kunnen worden waargenomen. Decompositie is een vorm van reticulatie. Bij een decompositiestap 45
worden de delen van een geheel beschreven, mogelijk inclusief de relatie tussen die delen. Op die delen kan vervolgens weer een decompositiestap worden toegepast, enzovoorts. Het aantal decompositiestappen dat kan worden toegepast is onder meer afhankelijk van het bestaan van een laagste, ondeelbaar niveau (bijvoorbeeld de mens in een organisatie). Het reticulatieniveau wordt in modellen vaak geteld als het aantal decompositiestappen dat bij een beschrijving is genomen vanaf het ongedeelde systeem (dat is dus 0, 1, 2, etc.). Voorbeeld: men begint bij het waarnemen van het systeem Rijksuniversiteit Groningen (reticulatieniveau 0). Daarna past men een decompositiestap toe en ziet de subsystemen Bestuur, Bureau, en Faculteit A, Faculteit B, Faculteit C, . . . (reticulatieniveau 1). Vervolgens verhoogt men het reticulatieniveau, maar zonder decompositie toe te passen, en ziet dat er geldstromen lopen vanuit het Bureau naar de Faculteiten. Verhoogt men het reticulatieniveau nog eens, dan ziet men bijvoorbeeld ook de besturingsrelaties tussen Bestuur, Bureau en Faculteiten. Abstractie is het proces waarbij men de algemeen geldende eigenschappen van entiteiten in beschouwing neemt en afziet van identificerende en toevallige eigenschappen van individuele entiteiten. Een verzameling bij elkaar horende eigenschappen noemen we een type. Bijvoorbeeld: men abstraheert van de identificerende en toevallige eigenschappen van de personen A.Alberts en E.Egberts en spreekt over de 'student' die verplicht is om jaarlijks 21 studiepunten te halen. STUDENT is dan het type, iets waarover men spreekt op een hoger abstractieniveau in plaats van over de specifieke A.Alberts en E.Egberts die beiden ook als student zijn ingeschreven en derhalve ook 21 studiepunten moeten halen. Concretisatie is het proces waarbij individuele entiteiten die behoren bij een type in ogenschouw worden genomen. Een type kan zelf ook weer worden beschouwd als een entiteit met eigenschappen zodat een type type mogelijk wordt; een type type noemen we een categorie. We onderscheiden drie abstractieniveaus: het niveau der entiteiten; het niveau der typen; het niveau der categorieën. De modellen die wij zullen maken liggen allemaal op het type-abstractieniveau.
46
Categorie
Systeem als geheel
abstractiestap
decompositiestap
Type
Subsystemen
abstractiestap
decompositiestap
Entiteit
Sub-subsystemen
3.2.2. Soorten handelingen Handelingen kunnen worden onderscheiden in: essentiële handelingen: alle handelingen waar geen taal aan te pas komt; taalhandelingen: handelingen waar taal aan te pas komt. Binnen de essentiële handelingen kunnen we onder meer onderscheiden: overdrachtshandelingen waarbij een product of dienst door een actor aan een andere actor wordt overgedragen (deze overdracht kan zowel fysiek zijn en/of rechten en verplichtingen betreffen); omzettingshandelingen waarbij een object wordt gecreëerd of van toestand wordt veranderd. Als een spreker een zin uit, voert hij tegelijkertijd drie soorten taalhandelingen uit (Searle, 1969/1977:33): hij produceert woorden die samen een zin vormen (uitingshandeling); hij verwijst ergens naar en kent daar een eigenschap aan toe (propositionele handeling); hij beweert, vraagt, belooft, beveelt, etc. (illocutionaire handeling). Voorbeeld: "Geef mij dat boek." Uitingshandeling: ik zeg: "geef mij dat boek". Propositionele handeling: ik verwijs naar dat rechthoekige voorwerp op tafel en ken daar de eigenschap 'het zijn van een boek' aan toe. Illocutionaire handeling: ik maak duidelijk dat ik wil dat jij mij dat boek geeft (van de toon en omstandigheden is afhankelijk of dat een bevel of verzoek is).
47
3.2.3. Soorten modellen Gebaseerd op de nu onderscheiden handelingen kunnen de volgende soorten modellen worden onderscheiden (zie ook Dietz, 1996: 4): actor-interactiemodellen (bijvoorbeeld use case diagrammen) onderscheiden essentiële handelingen; bedrijfsprocesmodellen (bijvoorbeeld role activity diagrams) onderscheiden essentiële handelingen en illocutionaire handelingen, in het bijzonder besturingsgerichte illocutionaire handelingen; objectmodellen onderscheiden propositionele handelingen. 3.2.4. Objectmodellen Objectmodellen zijn modellen van de mogelijke uitspraken die door een informatiesysteem kunnen worden vastgelegd. De objectmodellen die wij behandelen zien de mogelijke uitspraken die kunnen worden gedaan over de wereld in termen van objecttypen, associatietypen, en attribuuttypen. De uitspraken die op grond van het onderscheiden van een objecttype en een attribuuttype kunnen worden gedaan zijn van de aard: Het object van objecttype A met naam B heeft een attribuut (kenmerk) van type C met waarde D. Voorbeeld: We onderscheiden het objecttype AUTO. We kunnen nu de volgende informatie vastleggen: De auto met kenteken SP-04-DL heeft de kleur rood. Hier is: A = AUTO; B = SP-04-DL; C = KLEUR; D = rood. De uitspraken die op grond van het onderscheiden van een associatietype kunnen worden gedaan zijn van de aard: Het object van objecttype A met naam B heeft een associatie genaamd C met een object van objecttype D genaamd E. Voorbeeld: We onderscheiden het associatietype IS UITGELEEND AAN tussen de objecttypen CD en PERSOON. We kunnen nu de volgende informatie vastleggen: De CD genaamd 'Irish Heartbeat' is uitgeleend aan de persoon Karel Hageman. Hier is: A = CD; B = Irish Heartbeat; C = IS UITGELEEND AAN; D = PERSOON; E = Karel Hageman. 3.2.5. Object, begrip, symbool Een object is iets waaraan we een invariante identiteit toekennen. Een object kan worden aangewezen in de reële wereld, of door de menselijke geest worden geconstrueerd in de conceptuele wereld. Met andere woorden, een object is iets dat een afzonderlijk bestaan heeft in de reële of conceptuele wereld en daardoor met een (zo mogelijk) unieke naam wordt benoemd. Voorbeelden: die appel daar, Jan Jansen, Nederland, mijn banksaldo, de RUG. Een begrip of concept is een iets dat door de menselijke geest is geconstrueerd en tot de conceptuele wereld behoort. Een concept heeft eigenschappen die al dan niet toepasbaar zijn op objecten. Voorbeelden van concepten zijn: het begrip appel, organisatie, democratie. Het begrip appel is toepasbaar op die appel daar. Democratie is toepasbaar op Nederland. Organisatie is toepasbaar op bijvoorbeeld de Universiteit Twente. Een symbool is een inscriptie in een fysiek medium behorende tot een symbooltype (Gazendam, 1993: 64). Een symboolstructuur is een bij elkaar horende groep symbolen. De meest voorkomende symboolstructuren zijn woorden, zinnen en verhalen. Voorbeeld: het woord 'appel'. Ter onderscheiding van object, begrip en woord wordt het object appel gewoon
48
geschreven, het begrip appel cursief of met hoofdletters (APPEL) en het woord 'appel' tussen aanhalingstekens. Objecten, begrippen, symbolen en symboolstructuren zijn allen entiteiten. Een entiteit is iets waarover gesproken kan worden. In de semiotiek (Peirce, 1958) wordt de drie-eenheid 'object - woord (of meer algemeen: symboolstructuur) - begrip' onderscheiden. Het object is datgene waarnaar wordt verwezen, het woord is datgene wat verwijst. Object, woord en begrip worden in een proces dat semiosis heet met elkaar verbonden. Het proces van semiosis verbindt de uitingshandeling met de propositionele handeling en de illocutionaire handeling. Dit kan het meest duidelijk worden uitgelegd voor het verband tussen het uiten van een woord (uitingshandeling) en het leggen van een verband met een object in de wereld en het toekennen van eigenschappen aan dat object (propositionele handeling). Het begrip dient als verzameling eigenschappen die sturend is bij het proces van semiosis, en daar helpt bij het selecteren van het object en het koppelen
appel (object)
'appel' (woord)
(
(
appel (begrip) ( van betekenis aan het woord. Bijvoorbeeld: het begrip appel dient om de appels te onderscheiden van de peren in een mand en het woord 'appel' daarvoor te kunnen gebruiken. Informatiesystemen bevatten symbolen of symboolstructuren die naar objecten verwijzen. Om bruikbaar te zijn moet een informatiesysteem, conform de semiotiek, ook op de een of andere manier begrippen bevatten. De voor een informatiesysteem noodzakelijke begrippen behoren tot onder meer de objecttypen, attribuuttypen, associatietypen en generalisaties.. De begripsstructuur waarop een informatiesysteem berust maakt het mogelijk dat de symboolstructuren in het informatiesysteem iets zeggen over de objecten in de fysieke of conceptuele wereld. Men zou zelfs kunnen zeggen dat informatiesystemen niet alleen afbeelden maar ook virtuele werelden creëren. Dat kan alleen maar dankzij het begrippennetwerk waarop een informatiesysteem berust. 3.2.6. Objecttype en attribuuttype Een attribuut van een entiteit A is een entiteit B die de betreffende entiteit A beschrijft in termen van een waarde behorend tot een bepaald domein. Bijvoorbeeld het begrip rood beschrijft de appel die op mijn bureau ligt op het gebied (domein) van de kleur. Een eigenschap is de aanwezigheid van een attribuut met waarden binnen een bepaald bereik, of de aanwezigheid van een regel die het gedrag van een entiteit in bepaalde omstandigheden definieert. Bijvoorbeeld: deze appel is eetbaar. Een type is een verzameling bij elkaar horende eigenschappen (Ter Bekke, 1988: 75; Gazendam, 1993: 92). Een type is een begrip dat zelf weer eigenschappen heeft. De belangrijkste eigenschappen van een type zijn: (1) de eigenschappen die bij het type behoren (de intensie van het type), en (2) de verzameling entiteiten die voldoen aan deze eigenschappen (de extensie van het type).
49
Een type is dus niet gelijk aan de verzameling entiteiten die van dat type zijn (Ter Bekke, 1988: 75). Deze verzameling is echter wel een eigenschap van het type. Voorbeeld: de verzameling personen die medewerker is van de Faculteit Bedrijfskunde is niet gelijk aan het type MEDEWERKER FACULTEIT BEDRIJFSKUNDE. Het type kan min of meer constant zijn, terwijl de verzameling personen een steeds veranderende verzameling is. De namen van types schrijven we met hoofdletters. Voorbeeld: Het type APPEL is gedefinieerd door de volgende eigenschappen: het is een vrucht van de boom behorende tot de familie der Pomacaea. En instantie van een type is een entiteit die van dat type is. De Appel op mijn bureau is een instantie van het type APPEL. De namen van instanties schrijven we ter onderscheiding van de rest van de tekst vet en, eventueel behalve de beginletter, met kleine letters. Een objecttype is een type dat van toepassing is op objecten. Een attribuuttype is een type dat van toepassing is op attributen. 3.2.7. Associatie, associatietype Een associatie is een relatie tussen twee of meer objecten, bijvoorbeeld een deel-geheel relatie, een groep-groepslid relatie, een huwelijk, een gezin, een contract tussen twee organisaties, en dergelijke. Een bepaalde associatie tussen de instanties van twee objecttypen P en Q kan worden beschreven als bestaande uit twee verzamelingen, namelijk een verzameling objecten van type P en een verzameling objecten van type Q. Bijvoorbeeld een bepaald huwelijk kunnen we zien als een associatie. Die associatie bestaat uit een verzameling mannen en een verzameling vrouwen. Van belang is het redeneren over associaties in termen van de aantallen van de deelnemende objecten. Het huwelijk waarover we net spraken, bijvoorbeeld is een conventioneel huwelijk als het gaat om één man en één vrouw. Met andere woorden, het aantal mannen dat mag deelnemen in een dergelijke associatie is precies één en het aantal vrouwen ook. Die aantallen van de deelnemende objecten noemen we ook wel cardinaliteiten, en geldende regels voor de aantallen deelnemende objecten heten multipliciteitsregels. Dergelijke multipliciteitsregels gelden voor een bepaald associatietype, bijvoorbeeld het conventionele huwelijk. Associaties behoren tot een associatietype3. De belangrijkste kenmerken van een associatietype zijn: (1) de verzameling associaties die ertoe behoort. (2) de objecttypen waartoe de deelnemende objecten behoren; (3) het soort relatie tussen de deelnemende objecten in een associatie; (4) de multipliciteitsregels voor het associatietype. Als we bijvoorbeeld het associatieype GEBOUW-KAMER nemen, dat gaat over gebouwen en de daarin aanwezige kamers, kunnen we zeggen dat: een gebouw in de regel minimaal één kamer bevat; een gebouw ook meerdere kamers kan bevatten; een kamer deel kan uitmaken van één gebouw (en niet van meerdere gebouwen). In termen van minimale en maximale cardinaliteit van de instanties van de deelnemende objecttypen betekent dit het volgende (zie tabel).
3
De namen of afkortingen van associatietype worden net als objecttypen met hoofdletters geschreven.
50
Associatie GEBOUWKAMER
Objecttype GEBOUW minimale cardinaliteit 1
Objecttype KAMER maximale cardinaliteit 1
minimale cardinaliteit 1
maximale cardinaliteit M
Hierbij betekent M: meer, d.w.z. een geheel getal groter of gelijk aan twee. We spreken kortheidshalve van een 1:M associatietype als de maximale cardinaliteiten 1 resp. M zijn. Op dit gebied zijn er de volgende mogelijkheden: 1:1 associatietype (één op één) of 1:M associatietype (één op meer) of M:M associatietype (meer op meer). In objectmodellen wordt een objecttype door een rechthoek (met erin de naam van het objecttype in hoofdletters) weergegeven; een associatietype wordt door een lijn tussen de rechthoeken van de deelnemende objecttypen getekend. De multipliciteitsregel wordt in de z.g. crowfoot-notatie op de lijn weergegeven door de volgende symbolen: 0: een rondje (lijkt op een nul); 1: een streepje (lijkt op een één); M: een kraaiepootje (lijkt op een M). In de wat minder direct duidelijke OMT notatie worden de volgende symbolen gebruikt: 0 tot 1: een open rondje (lijkt op een nul); 0 tot M: een dicht rondje (lijkt op een dikke stip); 1 tot 1: een doorlopende lijn (d.w.z. geen extra symbool op de lijn); 1+ 1 tot M: naast de lijn is 1+ geschreven. Voor ons voorbeeld van het associatietype GEBOUW-KAMER en de objecttypen GEBOUW en KAMER komt het objectmodel er als volgt uit te zien (zie linker figuur hieronder). GEBOUW
GEBOUW
BEVAT
BEVAT
1+
1+
KAMER
KAMER
Bij dit objectmodel is echter nog iets bijzonders aan de hand. De kamer is onverbrekelijk altijd een onderdeel van een gebouw. Eeen kamer kan niet van gebouw wisselen. Als het gebouw wordt afgebroken zijn ook alle kamers weg. Er is hier dus sprake van een deel-geheel relatie, en dat wordt in OMT aangegeven met een ruitje aan de kant van het geheel (zie rechter figuur hierboven). 3.2.8. Generalisatie Een relatiesoort die direct tussen de objecttypen zelf zit is de generalisatie. In een generalisatie-relatie tussen twee objecttypen zijn twee rollen: het supertype en het subtype. Het subtype heeft altijd tenminste alle definiërende eigenschappen van het supertype. Het supertype heeft daardoor altijd tenminste alle instanties van het subtype zelf als instantie. Voorbeeld: de aap is een subtype van het dier. De aap heeft daardoor alle eigenschappen van
51
het dier. De verzameling instanties van het dier omvat in ieder geval alle apen. In het objectmodel ziet dit er als volgt uit. DIER
AAP
3.2.9. Structuren Een structuur bestaat uit een associatietype en de daarin deelnemende objecttypen. Voorbeelden zijn de organisatiestructuur, de 'bill of materials' structuur of de verpakkingsstructuur. Een organisatiestructuur is meestal een hiërarchische deel-geheel structuur. Bijvoorbeeld: een universiteit bestaat uit een aantal faculteiten; elke faculteit bestaat uit een aantal vakgroepen; elke vakgroep bestaat uit een aantal personen. Er is dan een 1:M associatietype tussen organisatie en deelorganisatie. Het bijzondere van een organisatiestructuur is dat zij kan worden weergegeven als één objecttype ORGANISATIE dat tweemaal deelneemt in een associatietype (zie figuur). Op deze manier kan een hiërarchie van onbeperkte diepte worden weergegeven. Let erop dat het aantal hogere organisaties nul of één is; immers de allerhoogste organisatie heeft zelf geen hogere. Bijvoorbeeld een subfaculteit maakt deel uit van een faculteit, een faculteit maakt deel uit van een universiteit, maar een universiteit heeft zelf geen hogere organisatie. Ook hier is weer sprake van een deel-geheel verhouding, hetgeen door een ruitje wordt aangegeven bij het geheel.
ORGANISATIE IS DEEL VAN
Sommige organisatiestructuren zitten ingewikkelder in elkaar, bijvoorbeeld de matrixorganisatie. Hierbij kan bijvoorbeeld een persoon van meerdere vak- of werkgroepen deel uitmaken. Er is dan sprake van een M:M-associatietype. Dit M:M: associatietype komt voor in de bill-of-materials structuur. Een bill of materials is een lijst waarop staat welke onderdelen moeten worden gebruikt in de assemblage van een groter onderdeel of eindproduct. 52
Een voorbeeld is het volgende. Op de lijst met producten en onderdelen (objecttype. ONDERDEEL) staat bijvoorbeeld dat er drie staande lampen, één schemerlamp, vijf lampekappen, twee voeten, één lange staander en zes korte staanders in voorraad zijn. Op de stuklijst of bill-of-materials (objecttype DEEL-GEHEEL hieronder) staat dat een staande lamp één lampekap bevat, evenals één lange staander en één voet. Dit terwijl de schemerlamp één lampekap bevat, één korte staander en één voet. Een bill-of-materials structuur is een M:M deel-geheel structuur, waarbij onderdelen deel kunnen uitmaken van meerdere grotere onderdelen. Een voedingseenheid kan bijvoorbeeld deel uitmaken van zowel een printer als een computer. Een schroefje kan deel uitmaken van vele andere onderdelen. Deze M:M deel-geheel structuur ziet er in een objectmodel als volgt uit. ONDERDEEL
IS GEHEEL
IS DEEL
DEEL-GEHEEL
De bill-of-materials structuur is een productstructuur. Daarnaast kennen we ook een verpakkingsstructuur: een product, bijvoorbeeld een kaars, gaat in een doosje samen met nog een aantal andere kaarsen; dat doosje gaat in een kist; die kist wordt op een pallet geplaatst, het pallet gaat in een container; de container gaat in een schip. Eén en ander betekent dat een object van meerdere structuren deel kan uitmaken. Deel-geheel structuren zijn in principe recursieve structuren, hetgeen wil zeggen dat een deel van het geheel zelf weer een geheel kan zijn dat uit delen bestaat, enzovoorts. Deel geheel structuren zijn de belangrijkste structuren waarmee we te maken kunnen krijgen. Daarnaast bestaan er nog enkele andere typen structuren. De volgende typen structuren kunnen worden onderscheiden: geheel/ deel structuur(object A is een deel van object B); generalisatiestructuur (type A is een subtype van B). processtructuur (actie A veroorzaakt activiteit B; activiteit B veroorzaakt actie C). 3.2.10. Categorieën Voor het ordenen en onderscheiden van objecttypen is het handig om over een lijst met categorieën te beschikken. Een categorie is een type objecttype. In deze paragraaf stellen wij ons tot doel om een handzame (d.w.z. niet uitputtende) lijst met categorieën te maken die van nut is bij het categoriseren van objecttypen in een objectmodel. Deze lijst moet aansluiten bij de gevolgde werkwijze van het modelleren van organisaties in termen van actoren en interacties. De lijst met categorieën bouwen we als volgt op. We beginnen met het onderscheiden van actoren, transacties, en de onderwerpen van die transacties. Het onderwerp van een transactie is in de regel de toestandsverandering van meerdere verzamelingen objecten. Bij de transactie Inkoop #26 gaat het over:
53
-
drie fietsen van type Gazelle Superieur Special, 5 versnellingen, 57 hoog, heren, Boston Groen (verzameling Inkoop #26 regel 1); één fiets van het type Gazelle Paris, 57 hoog, dames, Daytona Violet (verzameling Inkoop #26 regel 2). De verzamelingen die onderwerp zijn van Inkoop #26 ondergaan in ieder geval de volgende toestandsveranderingen: zij veranderen van eigenaar; zij veranderen van plaats; zij worden betaald. De toestandsverandering kan meer of minder zijn gespecificeerd, bijvoorbeeld alleen ‘in eigendom overdragen’ of daarnaast ook ‘bij JEEKAA te Schiermonnikoog op 5 december 1997’. De verzameling objecten kan abstract zijn: van de verzameling objecten is dan alleen de hoeveelheid en het type bekend, of concreet: elk van de objecten in de verzameling is dan identificeerbaar met een naam of nummer. Verzamelingen moeten worden onderscheiden van individuen en typen. Een verzameling is bijvoorbeeld een aantal fietsen dat wordt besteld bij de leverancier. De fietsen in die verzameling kunnen abstract zijn. Een individu is bijvoorbeeld één bepaalde fiets met een bepaald framenummer. Een individu is altijd concreet. Een type is bijvoorbeeld een model fiets. We hebben hier dus de categorie type, die scherp moet worden onderscheiden van het begrip objecttype. Tot de categorie type behoort bijvoorbeeld het objecttype FIETSTYPE met instanties als Gazelle Superieur Special, 5 versnellingen, 57 hoog, heren, Boston Groen. De verzamelingen worden meestal op grond van een bepaald doel onderscheiden, bijvoorbeeld het bestellen van fietsen. Bij typen geldt de regel dat elke verandering van een type in principe tot de definitie van een nieuw type leidt. Het fietstype Gazelle Tour de France heren wit 1994 is een ander type dan Gazelle Tour de France heren wit 1995 als bijvoorbeeld de prijs verschilt of als er belangrijke onderdelen verschillen. Typen blijven geregistreerd zolang ze relevant zijn, d.w.z. zolang er verzamelingen of individuen van dat type in de gegevensbank zitten of kunnen worden verwacht. Meestal zijn tijd en plaats attributen van objecten. In sommige gevallen is het echter wenselijk om deze attributen tot objecttypen te verheffen (dit proces heet verdinglijking of reïficatie). Zo kan het in de logistiek wenselijk zijn om objectverzamelingen te onderscheiden op grond van de plaats waar zich objecten bevinden. Men kan dan bijvoorbeeld nagaan of de capaciteit van magazijn C (maximum capaciteit 250 items) is benut. In dat geval komt er een objecttype plaats en een objecttype voor de verzameling objecten die zich op die plaats bevinden. Bij het roosteren kan daarnaast het verdinglijken van tijd een rol spelen. Men moet bijvoorbeeld na kunnen gaan of in week 32 de nachtdienst is ingeroosterd. Eén en ander leidt tot de volgende categorieën: 1. actor; 2. transactie; 3. verzameling; 4. individu; 5. type; 6. plaats; 7. tijd. Van deze categorieën zullen we in de regel categorie 1 t/m 5 gebruiken. 3.3. Top-down ontwikkeling van het objectmodel voor het domein met de categorieënmethode 3.3.1. Inleiding top-down ontwikkeling Bij de top-down ontwikkeling van een objectmodel volgens de categorieënmethode worden objecttypen onderscheiden aan de hand van een stelsel van categorieën. Een dergelijk stelsel 54
van categorieën is in Paragraaf 3.2.10. geschetst. Na het onderscheiden van objecttypen (Paragraaf 3.3.2.) wordt het objectmodel verfijnd door het toepassen van een abstract objectmodel gebaseerd op associatietypen (Paragraaf 3.3.3.), het bepalen van de associatietypen (Paragraaf 3.3.4.), het beslissen over de manier waarop gebeurtenissen worden geregistreerd (Paragraaf 3.3.5.), het onderscheiden van levenscycli van objecten (paragraaf 3.3.5.), het onderscheiden van structuren (Paragraaf 3.3.6.), en het onderzoeken van het objectmodel op verschillende valkuilen (Paragraaf 3.3.7.). Tenslotte wordt een uitgebreid objectmodel inclusief attribuuttypen gemaakt (Paragraaf 3.3.8.). 3.3.2. Objecttypen Bij het maken van onze lijst met objecttypen hanteren we de reeks categorieën actor, transactie, verzameling die onderwerp is van transactie, individu, type als leidraad. De voor ons relevante actoren en transacties kunnen worden afgeleid uit actorinteractiediagrammen zoals het use case diagram. Voor JEEKAA krijgen we de volgende objecttypen die met actoren (in dit geval organisaties) corresponderen: JEEKAA; KLANT; LEVERANCIER; DERDE. De volgende objecttypen corresponderen met transacties (objecttypen zijn altijd enkelvoud; dit vergt herschrijven van de namen van de transacties): INKOOPTRANSACTIE; VERKOOPTRANSACTIE; BEANTWOORDING VRAAG. Eigenlijk moeten we voor elke interactie één objecttype onderscheiden. Als een transactie echter homogeen is, dat wil zeggen dat alle fasen in een transactie op dezelfde verzameling producten, diensten, etc. betrekking hebben, mogen we deze objecttypen echter samenvoegen tot één objecttype voor de hele transactie. Dat is wat hier is gebeurd. Immers, we gaan ervan uit dat zowel levering als betaling op dezelfde verzameling fietsen betrekking hebben. Een levering wordt bijvoorbeeld niet in twee keer betaald. Vervolgens komt een moeilijke stap: we moeten nagaan welke verzamelingen onderwerp van deze transacties zijn. Het gaat in alle gevallen om verzamelingen fietsen. Bij een INKOOPTRANSACTIE horen enkele verzamelingen INGEKOCHTE FIETSEN. Idem dito horen bij een VERKOOPTRANSACTIE in principe ook enkele verzamelingen VERKOCHTE FIETSEN. Voor het gemak stellen we dat het onderwerp van BEANTWOORDING VRAAG een verzameling fietsen is die uit één fiets bestaat: NAGEVRAAGDE FIETS. De hierna volgende stap is kijken uit welke individuen de onderscheiden verzamelingen bestaan. Het gaat hier steeds om individuen van het objecttype FIETS. Tenslotte kijken we naar de types waartoe die individuen behoren. We hoeven alleen maar het objecttype FIETSTYPE te onderkennen. Als we alles samenvatten en ordenen, krijgen we in het geval van JEEKAA de volgende naar categorieën ingedeelde lijst met objecttypen: actoren: JEEKAA; KLANT; LEVERANCIER;
55
DERDE. transacties (in min of meer chronologische volgorde): INKOOPTRANSACTIE; VERKOOPTRANSACTIE BEANTWOORDING VRAAG; verzamelingen: INGEKOCHTE FIETSEN: VERKOCHTE FIETSEN; NAGEVRAAGDE FIETS; individuen: FIETS. typen: FIETSTYPE. 3.3.3. Een abstract objectmodel gebaseerd op associatietypen Bij het bepalen van de multipliciteitsregels van de associatietypen gaan we uit van de volgende beweringen: een actor kan bij al dan niet bij transacties zijn betrokken bij een transactie is altijd één actor betrokken; een transactie omvat verzamelingen; een transactie omvat tenminste één verzameling; een verzameling hoort altijd bij één bepaalde transactie; een verzameling kan bestaat uit individuen; een verzameling bestaat uit tenminste één individu; een individu kan, maar hoeft niet, lid te zijn van een verzameling; een verzameling is altijd van één type; een type hoeft niet als verzameling voor te komen; een type is toepasbaar op meerdere individuen; een individu is altijd van één type; een type hoeft niet als individu voor te komen; een type is toepasbaar op meerdere verzamelingen. Op grond van deze beweringen over associatietypen kan een abstract objectmodel worden afgeleid dat er als volgt uit ziet..
56
ACTOR 1
TRANSACTIE 1
1+ VERZAMELING 1
ACTOR 2
TRANSACTIE 2
TRANSACTIE 3
1+
1+
VERZAMELING 2
1+
VERZAMELING 3
1+
INDIVIDU 1
1+ INDIVIDU 2
TYPE 1
TYPE 2
3.3.4. Het eerste objectmodel Nu kan het objectmodel worden getekend. Het is gebruikelijk om in het objectmodel het objecttype dat betrekking heeft op het bedrijf zelf (bij ons: JEEKAA) weg te laten. De objecttypen worden in nette rijen gerangschikt, die, van boven naar beneden, bestaan uit: actoren; transacties; verzamelingen; individuen; typen. Bij de eerder genoemde algemene beweringen over associatietypen kunnen we extra beweringen toevoegen voor de te modelleren organisatie. Bij JEEKAA zijn dat: een FIETS behoort altijd tot de eens INGEKOCHTE FIETSEN (buiten de inkoop om kan er geen fiets bij JEEKAA terecht komen). de verzameling NAGEVRAAGDE FIETSen bestaat altijd uit één FIETS. We krijgen zo het volgende objectmodel.
57
LEVERANCIER
KLANT
DERDE
1+
INKOOPTRANSACTIE
VERKOOPTRANSACTIE
1+
1+
INGEKOCHTE FIETSEN
BEANTWOORDING VRAAG
1+
VERKOCHTE FIETSEN
NAGEVRAAGDE FIETS
FIETS 1+
FIETSTYPE
3.3.5. Het registreren van gebeurtenissen Gebeurtenissen en bij deze gebeurtenissen betrokken verzamelingen zijn gebonden aan een tijdstip of tijdsperiode en mogen eigenlijk niet worden veranderd als ze eenmaal als gebeurtenis zijn geregistreerd. Dit staat in tegenstelling tot de registratie van actoren en individuen waar in de regel alleen de meest recente toestand wordt vastgelegd. Een gebeurtenis heeft in de regel effect op de toestand van een actor of individu. In plaats van de gebeurtenis zelf zou men dus ook de resulterende veranderde toestand kunnen vastleggen. Bijvoorbeeld las er een fiets wordt verkocht kan men de verkooptransactie als zodanig vastleggen, maar men kan ook de toestand van de fiets veranderen van 'in de verkoop' naar 'verkocht'. Bij het registreren van gebeurtenissen zijn er drie mogelijkheden: 1. registratie als gebeurtenis (dit is de regel bij bijvoorbeeld transacties en rechtshandeling zoals beschikkingen); 2. registratie als toestandsverandering, bijvoorbeeld als genomen stap in de levenscyclus van het onderwerp van de gebeurtenis; 3. registratie als gebeurtenis en registratie van de meest recente toestand van het onderwerp van de gebeurtenis (dit dan wel redundant!); 4. geen registratie van de gebeurtenis. (Ad 1.) Hier wordt de gebeurtenis verdinglijkt of reïficeerd; er wordt van iets vlottends een ding of object gemaakt. Als allerlei details over de gebeurtenis moeten worden vastgelegd, zoals betrokken actoren, tijdstip, en meerdere onderwerpen is dit de aangewezen methode. Bij transacties en rechtshandelingen is het de regel.
58
(Ad 2.) Als de levenscyclus van een actor, verzameling of individu uit enkele vaste gebeurtenissen is opgebouwd kan soms worden volstaan met de registratie van gebeurtenissen als genomen stap in de levenscyclus van het objecttype. Als voorbeeld hier de levenscyclus van een fiets. offerte
bestelling
annulering
inkooplevering
verkoop
verkooplevering
beantwoording vraag
Het is bijvoorbeeld niet nodig om het afleveren van een fiets door de leverancier als zodanig te registreren; er kan worden volstaan met bij de betreffende fiets het attribuut 'leveringsdatum' in te vullen. Bij het verkopen van een fiets worden de attributen 'verkoopdatum' en 'klantnr' ingevuld. Er doet zich hier wel een moeilijkheid voor dat bij de fasen 'offerte', 'bestelling' en 'annulering' sprake is van aan abstracte fiets, een fiets die nog nooit gezien is en waarvan het framenummer dus nog niet is waargenomen. Pas als de fiets is geleverd is er sprake van een concrete fiets. Aan de abstracte fiets moet dan een voorlopige identificatie worden toegekend, die later wordt gekoppeld aan het framenummer. (Ad 3.) Bij het dubbel boekhouden wordt steeds zowel de gebeurtenis (in de vorm van een memoriaalpost of journaalpost) als de daaruit voortvloeiende veranderde toestand (in de vorm van een verandering van de hoogte van in de regel twee grootboekrekeningen) geregistreerd. (Ad 4.) Soms mag een gebeurtenis worden vergeten. Men registreert dan alleen de meest recente toestand van het onderwerp van die gebeurtenis. Het is bijvoorbeeld voldoende om te vermelden of een fiets geleverd is of niet; de handeling van het verkoopklaar maken van de
59
fiets (verpakking verwijderen, in elkaar zetten. e.d.) hoeft niet als zodanig te worden geregistreerd. Bij het doen van keuzen op het gebied van de registratie van gebeurtenissen is het vaak nodig om de transacties meer gedetailleerd te bekijken, namelijk op het niveau van de interactie. We moeten dus kijken naar de volgende interacties, die bij het maken van het informatiesysteem use case model zijn onderkend: bestelling (met de uitbreidingen toepassen inkoopformule, voorbereiding spoedbestelling en annulering); inkooplevering; verkoop; verkooplevering; beantwoorden vragen. De keuze die we op het gebied van de registratie van gebeurtenissen voor JEEKAA doen is de volgende: registratie als gebeurtenis: bestelling; registratie als onderdeel levenscyclus fiets: inkooplevering; verkoop; verkooplevering; geen registratie: beantwoorden vragen. Eén en ander betekent dat VERKOOPTRANSACTIE en BEANTWOORDEN VRAGEN uit de lijst van objecttypen worden geschrapt. Ook de verzamelingen van VERKOCHTE FIETSEN en NAGEVRAAGDE FIETS kunnen vervallen, mits het objecttype FIETS blijft bestaan voor het registreren van de levenscyclus van de fiets. Het registreren van de DERDE is ook niet meer relevant omdat er niets over het proces van het beantwoorden van vragen hoeft te worden vastgelegd. In de levenscyclus van de FIETS moeten worden vastgelegd: de datum van de inkooplevering, de leverancier, de datum van de verkoop, de klant, de datum van de verkooplevering en eventueel bijzonderheden over deze gebeurtenissen. Op deze manier komen we aan het tweede objectmodel, dat hieronder is afgebeeld.
60
LEVERANCIER
KLANT
INKOOP TRANSACTIE
1+ INGEKOCHTE FIETSEN
FIETS 1+
FIETSTYPE
3.3.6. Het onderscheiden van structuren Het is soms gewenst om structuren te registreren. Voorbeelden zijn de organisatiestructuur, de 'bill of materials' structuur of de verpakkingsstructuur. Als registratie van structuren (deel-geheel, processtructuur, etc.) nodig is, zullen nieuwe objecttypen nodig zijn zodra er méér op méér relaties tussen elementen in die structuren moeten worden vastgelegd. Een voorbeeld hiervan is de 'bill of materials' structuur: een onderdeel bestaat uit meerdere kleinere onderdelen, terwijl een onderdeel van meerdere grotere gehelen deel kan uitmaken. Soms is het zinvol om op grond van gemeenschappelijke gegevens in objecttypen een supertype boven deze objecttypen te onderscheiden. De gemeenschappelijke gegevens komen in néén objecttype, de niet-gemeenschappelijke gegevens in subtypen van dat objecttype. Een voorbeeld zijn de gemeenschappelijke gegevens in de actoren JEEKAA, klant, leverancier en
61
derde. Bij al deze actoren zijn NAW gegevens van toepassing. Daarom kan eventueel een objecttype actor worden onderscheiden, waarvan JEEKAA, klant, leverancier en derde dan subtypen zijn. 3.3.7. Het onderzoeken en vereenvoudigen van het objectmodel Bij het onderzoeken vereenvoudigen van het objectmodel is het nodig te letten op: het waar mogelijk schrappen van kortere wegen (in het geval van JEEKAA niet van toepassing)4; het samenvoegen van 1:1-relaties tot één objecttype; het vermijden van de Howe (1983) valkuilen: splitsingsvalkuil, waaiervalkuil en kloofvalkuil. LEVERANCIER
Kloofvalkuil: geen relatie tussen LEVERANCIER en FIETSTYPE
FIETSTYPE
INKOOP TRANSACTIE
1+ INGEKOCHTE FIETSEN
Waaiervalkuil: geen relatie tussen FIETS en INKOOPTRANSACTIE
FIETS
In bovenstaande figuur zijn twee van de Howe-valkuilen weergegeven. De ontwerper heeft vergeten om een verband te leggen tussen LEVERANCIER en FIETSTYPE, terwijl het informatiesysteem wel informatie moest kunnen leveren over door een leverancier te leveren fietsen (kloofvalkuil). Ook is vergeten om een relatie te leggen tussen FIETS en INGEKOCHTE FIETSEN, terwijl men wel moest kunnen nagaan wanneer en waar een fiets was besteld (waaiervalkuil). Een beroemd voorbeeld van de splitsingsvalkuil is het Manhattan project voorbeeld van Date. In een gegevensbank over projecten, producten en leveranciers zijn drie tabellen opgenomen: (1) leveranciers die aan projecten leveren, (2) producten geleverd door een leverancier, en (3) producten gebruikt door een project. Uit deze opzet is niet af te leiden welke leverancier een bepaald product aan een bepaald project heeft geleverd, want (Date, 1995: 11): 4
Dit mag alleen als die kortere weg géén andere betekenis heeft dan de langere weg. De kortere weg tussen LEVERANCIER en FIETSTYPE kan bijvoorbeeld als betekenis hebben welke fietstypen leverbaar zijn door een leverancier, en mag dan niet worden geschrapt.
62
"(a) Smith supplies monkey wrenches to the Manhattan project. Tells us more than the following three statements do: (b) Smith supplies monkey wrenches, (c) Monkey wrenches are used in the Manhattan project, and (d) The Manhattan project is supplied by Smith." In het geval van JEEKAA zien we dat er geen verband is tussen FIETSTYPE en LEVERANCIER, terwijl het toch wel wenselijk is om te weten welke leverancier welke fietsen kan leveren., anders wordt het bestellen wel heel lastig. Dit leidt tot de derde versie van ons objectmodel. LEVERANCIER
KLANT
leverbare fietstypen INKOOP TRANSACTIE
1+ INGEKOCHTE FIETSEN
FIETS 1+
FIETSTYPE 1+
63
3.3.8. Het uitgebreide objectmodel Dit objectmodel is eenvoudig uit te bereiden met attribuuttypen. Dat zijn de kenmerken die we moeten registreren van de objecttypen om uitspraken vast te leggen. Bijvoorbeeld als we de uitspraak: "De afdeling Inkoop van JEEKAA heeft Bestelling #15 op 3 maart 1997 geplaatst bij Gazelle." willen registreren moeten we een objecttype INKOOPTRANSACTIE hebben met daarin de attribuuttypen: organisatie ("Afdeling Inkoop van JEEKAA"); bestelnr ("Bestelling #15"); besteldatum ("3 maart 1997"); levnr (nr 1, behorende bij LEVERANCIER "Gazelle"). Hierbij is bestelnr de sleutel van de INKOOPTRANSACTIE, d.w.z. het attribuuttype dat elke afzonderlijke inkooptransactie uniek identificeert. Elk objecttype dient een sleutel te hebben, een uniek identificerend attribuut. Om deze reden worden vaak nummers ingevoerd, zoals bijvoorbeeld het levnr dat een leverancier uniek identificeert. Dit levnr gebruiken we om in het objecttype INKOOPTRANSACTIE aan te duiden bij welke LEVERANCIER een bepaalde inkooptransactie hoort. Een attribuut dat op deze manier wordt gebruikt om naar een ander objecttype te verwijzen heet een verwijzende sleutel. Alle associaties in het objectmodel moeten door verwijzende sleutels worden vormgegeven. Daarbij wordt altijd de verwijzende sleutel opgenomen in het objecttype waarvan er in de associatie in principe méér zijn. Voorbeeld: Het objecttype INGEKOCHTE FIETSEN dient een verwijzende sleutel bestelnr te hebben die verwijst naar de sleutel bestelnr van het objecttype INKOOPTRANSACTIE. Op deze manier wordt de 1:M-associatie tussen INKOOPTRANSACTIE en INGEKOCHTE FIETSEN vormgegeven. Een uitgewerkt objectmodel voor JEEKAA met daarin ook de attribuuttypen is hieronder weergegeven. We zien dat de attribuuttypen van de verschillende actoren een zekere gelijkenis vertonen.
lotnr bestelnr fietstypenr aantal annulering ja/nee leverbare fietstypen 1+ FIETSTYPE fietstypenr levnr model soort hoogte kleur inkoopprijs verkoopprijs voorraad bestelkosten voorraadkosten
3.4. Bottom-up ontwikkeling objectmodel voor het domein 3.4.1. Inleiding bottom-up ontwikkeling Bij de bottom-up methode voor de ontwikkeling van een objectmodel wordt uitgegaan van een verzameling documenttypen die samen de inhoud (op typeniveau) dekt van het wereldbeeld dat als representatie van de werkelijkheid in het informatiesysteem moet komen. 65
Traditioneel worden in ieder geval alle soorten documenten die het informatiesysteem moet kunnen maken meegenomen. Alle attribuuttypen (ook wel elementaire gegevenstypen genoemd) die op deze documenttypen voorkomen zijn het uitgangspunt voor verdere analyse. Op grond van een analyse van de relaties tussen de diverse attribuuttypen worden de attribuutypen gegroepeerd in objecttypen. De documenten die het uitgangspunt vormen voor de bottom-up methoden zijn vaak formulieren met een hiërarchische gegevensstructuur. Dergelijk hiërarchische gegevensstructuren kunnen met behulp van een ISAC-C-schema worden beschreven (Paragraaf 3.4.2.). Het normaliseren is een methode uit de werld van de relationele gegevensbanken om vanuit hiërarchische gegevensstructuren tot genormaliseerde gegevensstructuren te komen (die weer het uitgangspunt kunnen zijn voor objectmodellen). Het normaliseren wordt behandeld in Paragraaf 3.4.3. Een alternatieve methode voor het normaliseren is de bubble-chart methode, die gebaseerd is op de grafentheorie (Paragraaf 3.4.4.). De bubble chart-methode werd oorspronkelijk gebruikt om verschillende losstaande genormaliseerde gegevensstructuren te integreren. 3.4.2. Invoer/uitvoerdocumenten Door middel van ISAC-C-schema's kunnen de hiërarchische gegevensstructuren goed worden weergegeven. We komen deze gegevensstructuren tegen in documenten, formulieren, schermen, rapporten, en dergelijke. Een verzameling van hiërarchische gegevensstructuren is het startpunt voor het normalisatie-traject en voor het tekenen van bubble-charts. De Cschema's kunnen later, bij het constructieplan, worden gebruikt voort het specificeren van toegangspaden. Voor de symbolentaal van de ISAC-C-schema's, en ook enkele voorbeelden, zie de bijlagen 9.2. en 9.4.
12A bestelformulier (bestelnr)
spoedbestelling
bestelregel
gegevensverzameling met tussen haakjes het sleutelattribuut
lijst met attributen aantal annulering j/n
deelgegevensverzameling leverancier
deelgegevensverzameling die meerdere keren voorkomt
levnr levnaam levadres levw levpc
samengesteld attribuut (lijst met bij elkaar horende attributen van bepaald objecttype, in dit geval het objecttype leverancier)
Symbolen die worden gebruikt in ISAC-C-schema's ISAC-C-schema's (Componenten-schema's) worden gebruikt om de componenten (bestanddelen) van een hiërarchische gegevensverzameling of een document weer te geven. Dit gaat zo: een gegevensverzameling wordt aangeduid met en parallellogram bevattende de naam van de gegevensverzameling en (tussen haakjes) het identificerende attribuut; de gewone attributen worden opgenomen in een attributenlijst; men is vrij om samengestelde attributen te onderscheiden (doe dit met name voor bij elkaar horende attributen die op één objecttype betrekking hebben); 66
-
voor elke zich herhalende groep wordt een deelgegevensverzameling onderscheiden; de herhaling wordt aangegeven door een sterretje in het parallellogram; men is vrij andere deelverzamelingen te onderscheiden; dit wordt aanbevolen als sprake is van een zekere samenhang of als deze gegevensverzameling elders ook voorkomt.
De te tekenen ISAC-C-schema's moeten samen goed de informatie-inhoud van het te maken informatiesysteem weergeven. We gaan daarbij uit van de specificatie die wordt gegeven door het ISAC-A-schema van de gewenste situatie. Volgens de informatieprecedentie zijn vooral van belang de uitgaande documenten. Verder moeten we kijken naar de documenten die moeten worden geregistreerd en de bij de toepassing van beslisregels benodigde informatie. Voor de JEEKAA-case zijn de uitvoerdocumenten van de te ondersteunen taken van belang: 7B spoedbestelling; 8A spoedannulering; 12A bestelformulier; 11A antwoord op vraag naar framenummer. We gaan ervan uit dat de documenten spoedbestelling en spoedannulering dezelfde structuur hebben als het bestelformulier. Er moet alleen een extra gegeven worden opgenomen om aan te duiden of het om een bestelling dan wel annulering gaat. Ook is het van belang te noteren om welke klant het gaat. Verder weten we dat moeten worden geregistreerd voor de ondersteuning van het bestellen en het beantwoorden van vragen: 3A fiets + leverancier (bij inkomende fietsen; activiteit arriveren fietsen); 13A fiets + klant (bij uitgaande fietsen; activiteit verkopen fietsen). Analyse van de toe te passen bestelformule leert ons dat we per type fiets de bestelkosten, de voorraadkosten en de vraagprognose moeten weten. Deze gegevens geven we het nummer 12B. Zodoende hebben we voor de JEEKAA-case zeven gegevensverzamelingen of documenten die de inhoud van het te verwezenlijken fietsinformatiesysteem bepalen: 7B, 8A, 12A, 15A, 3A, 13A en 12B. Voor elk van deze gegevensverzamelingen dient een ISAC-C-schema te worden getekend. De deelverzamelingen die betrekking hebben op de leverancier, het fietstype, JEEKAA en de klant komen verschillende keren voor. Daarom worden er ook aparte deelverzamelingen voor onderscheiden (te tekenen onder een dubbele streep). Het onderkennen dat het om gegevens gaat die op objecttypen zoals leverancier, klant, etc. betrekking hebben is een abstractiestap.
67
12A
7B
bestelformulier (bestelnr)
besteldatum
JEEKAA
leverancier
naam adres w pc
levnr levnaam levadres levw levpc
bestelregel
fietstype typenr model soort hoogte kleur inkoopprijs
3A fiets+ leverancier (framenr)
arrivdatum
8A
spoedbestelling (bestelnr)
fietstype
leverancier
typenr model soort hoogte kleur inkoopprijs
levnr levnaam levadres levw levpc
bestelformulier
klant
aantal annulering j/n
spoed annulering (bestelnr)
spoedbestelling
klantnr klantnaam klantadres klantw klantpc
13A
11A
fiets+klant (framenr)
verkdatum
antwoord (framenr)
fietstype
klant
typenr model soort hoogte kleur verkoopprijs
klantnr klantnaam klantadres klantw klantpc
fiets+klant
12B fietstype+ kosten (typenr)
fietstype model soort hoogte kleur
bestelkosten voorraadkosten
vraag prognose
periode vraag
ISAC-C-schema's voor de toekomstige situatie bij JEEKAA 3.4.3. Normaliseren Normaliseren is het omzetten van een verzameling hiërarchische gegevensstructuren (zoals bijvoorbeeld weergegeven door ISAC-C-schema’s) in een relationele gegevensstructuur die uit tabellen bestaat. Enkele kenmerken van een genormaliseerde relationele gegevensstructuur zijn: zij bestaat uit louter tabellen; elke tabel bestaat uit rijen (ook wel tupels genoemd) en kolommen (ook wel attributen genoemd); elke rij komt slechts éénmaal voor;
68
-
de in een rij opgenomen gegevens zijn atomair (d.w.z. bevatten geen zich herhalende of recursieve gegevensgroepen); elke tabel heeft een sleutel die bij voorkeur uit één attribuut en soms uit meerdere attributen bestaat; de waarde van deze sleutel is voor elke rij in de tabel verschillend (uniekheid van de sleutel); de sleutel moet identificerend zijn voor de objecten die door de tabel worden afgebeeld (existentiële integriteit); de attributen in de tabel moeten functioneel afhankelijk zijn van de sleutel en mogen alleen van de (gehele) sleutel functioneel afhankelijk zijn.
Normaliseren is een bottom-up methode omdat van de structuur van gegevensverzamelingen op het detailniveau van het attribuut wordt uitgegaan. Uitgangspunt voor onze normalisatie zijn de ISAC-C-schema’s met de nummers 12A (), 12B (<prognose0>) en 13A (). Deze C-schema’s bevatten samen voldoende informatie voor het normalisatietraject. Het noteren van een normalisatietraject gaat als volgt. Achtereenvolgens worden de nulde normaalvorm (0NV), eerste normaalvorm (1NV), tweede normaalvorm (2NV) en derde normaalvorm (3NV) genoteerd. Elke normaalvorm bestaat uit een verzameling gegevensverzamelingen, hetzij hiërarchische structuren, hetzij objecttypen Dit wordt in een formule opgeschreven gebruik makend van de gangbare notatie om verzamelingen weer te geven. Elke gegevensverzameling bestaat weer uit andere gegevensverzamelingen dan wel uit attributen. Dit wordt met vergelijkbare formules opgeschreven. In de normalisatie worden objecttypen met hoofdletters geschreven, sleutels worden onderstreept. Gegevensverzamelingen die verderop worden uitgeschreven worden tussen <> haken geplaatst. De samenstelling van een objecttype wordt opgeschreven door na het objecttype een : (dubbele punt) te schrijven en daarna de verzameling van samenstellende attributen en gegevensverzamelingen. Een sterretje * betekent dat een gegevensverzameling meerdere keren kan voorkomen (dit is de zogenaamde zich herhalende groep). Men begint met het noteren van de gegevens afkomstig uit het ISAC-C SCHEMA, dit is de nulde normaalvorm <0NV>. Het is gebruikelijk de gegevens betrekking hebbend op JEEKAA zelf weg te laten. = {, <prognose0>, }. = BESTELLING:{bestelnr, besteldatum, levnr, levnaam, levadres, levw, levpc, *}. = {typenr, model, soort, hoogte, kleur, inkooppprijs, aantal, annulering}. <prognose0> = PROGNOSE:{typenr, model, soort, hoogte, kleur, bestelkosten, voorraadkosten, *}. = {periode, vraag}. =
De zich herhalende groepen, aangegeven met een sterretje worden bij de overgang naar de eerste normaalvorm <1NV> afgesplitst. Dit zijn en , leidend tot de nieuwe objecttypen FIETS-BESTELLING en FIETSPROGNOSE. De sleutel van het moeder-objecttype (waaruit het kind-objecttype - de zich herhalende groep- heeft losgemaakt) wordt gekopieerd naar het kind-objecttype om de relatie te kunnen leggen. Met de notatie . . . (drie puntjes) wordt weergegeven dat niets is veranderd en dat men daarom bij de voorgaande normaalvorm moet kijken voor de inhoud. <1NV> = {, , <prognose1>, , }. = BESTELLING:{bestelnr, besteldatum, levnr, levnaam, levadres, levw, levpc}. = FIETS-BESTELLING: {bestelnr, typenr, model, soort, hoogte, kleur, inkooppprijs, aantal, annulering}. <prognose1> = PROGNOSE:{typenr, model, soort, hoogte, kleur, bestelkosten, voorraadkosten}. = FIETSPROGNOSE: {typenr, periode, vraag}. = . . . Bij de overgang van de eerste naar de tweede normaalvorm worden de objecttypen die een meervoudige (meestal dubbele) sleutel hebben nader bekeken. Daarbij wordt gekeken of attributen afhankelijk zijn van een deel van de sleutel dan wel de gehele meervoudige sleutel. Attributen die afhankelijk zijn van een deel van de sleutel worden samen met dat deel van de sleutel (één van de sleutelattributen dus) afgesplitst naar een nieuw objecttype. het blijkt dat FIETS-BESTELLING moet worden gesplitst, waarbij een objecttype dat betrekking heeft op het FIETSTYPE wordt afgesplitst. Hoewel dit eigenlijk niet bij het normaliseren hoort, wordt geconstateerd dat het objecttype FIETSTYPE een geschikte plaats is om de totale voorraad van een bepaald fietstype te registreren. Het objecttype FIETSPROGNOSE verandert niet. <2NV> = {, , , <prognose1>, , }. = . . . = FIETS-BESTELLING: {bestelnr, typenr, aantal, annulering}. = FIETSTYPE: {typenr, model, soort, hoogte, kleur, inkooppprijs, voorraad}. <prognose1> = . . . = . . . = . . . Bij de overgang van de tweede normaalvorm naar de derde normaalvorm worden verborgen objecttypen recursief afgesplitst. Dit zijn (groepen) attributen, die niet alleen van de sleutel, 70
maar ook van een ander attribuut afhankelijk zijn. Een voorbeeld hiervan is het objecttype LEVERANCIER binnen BESTELLING, en het objecttype LEVAWPC5 binnen LEVERANCIER. Ook KLANT (aanwezig binnen FIETS) moet worden afgesplitst, evenals FIETS-TYPE binnen FIETS. Binnen KLANT is weer een afsplitsing van een tweede AWPC objecttype (KLANTAWPC) mogelijk. De AWPC tabellen voor leverancier en klant kunnen op grond van generalisatie worden samengevoegd: = {levadres, levw, levpc}. ={klantadres, klantw, klantpc}. "Generaliserende definities:" = {levadres| klantadres}. <w> = {levw| klantw}. = {levpc| klantpc}.
Op grond van deze generaliserende definities kunnen en samengevoegd worden tot . = {adres, w, pc}. Het blijkt dat FIETSTYPE en PROGNOSE dezelfde sleutel hebben; deze objecttypen worden samengevoegd onder de naam FIETSTYPE. Bij het afsplitsen blijft een de sleutel van het afgesplitste kind-objecttype in het moeder-objecttype behouden als attribuut om de relatie te kunnen blijven leggen; dit attribuut heet ook wel een verwijzende sleutel. De derde normaalvorm wordt helemaal voluit geschreven om een overzicht te maken. <3NV> = {, , , , , , , }. = BESTELLING:{bestelnr, besteldatum, levnr}. = LEVERANCIER: {levnr, levnaam, levadres, levw}. = AWPC: {adres, w, pc}. = FIETS-BESTELLING: {bestelnr, typenr, aantal, annulering}. = FIETSTYPE: {typenr, model, soort, hoogte, kleur, inkooppprijs, verkoopprijs, voorraad, bestelkosten, voorraadkosten}. = FIETSPROGNOSE: {typenr, periode, vraag}. = FIETS:{framenr, verkdatum, typenr, klantnr}. = KLANT: {klantnr, klantnaam, klanta, klantw}. Het blijkt dat de objecttypen die eerder top-down werden afgeleid ook bottom-up uit de normalisatie komen. Daarnaast komen de AWPC-tabel en de FIETSPROGNOSE uit de normalisatie. Een probleem is echter, dat de normalisatie heeft geleid tot een waaier-valkuil: 5
AWPC is een adres-woonplaats-postcode tabel.
71
er kan geen relatie meer gelegd worden tussen fiets en leverancier. Dit probleem is op te lossen door in het objecttype FIETS een attribuut (verwijzende sleutel) bestelnr op te nemen, zodat de relatie met FIETS-BESTELLING kan worden gelegd. = FIETS:{framenr, verkdatum, typenr, bestelnr, klantnr}.
3.4.4. Bubble charts Het tekenen van bubble charts is bedoeld als controle en waar nodig verfijning van het door middel van normalisatie ontworpen gegevensmodel. Het opstellen van bubble charts is evenals het normaliseren een bottom-up methode om tot een gegevensmodel te komen. Het startpunt is dan ook hetzelfde: een verzameling ISAC-C-schema’s die de inhoud van de te ordenen gegevensverzameling voldoende afdekken. In het geval van JEEKAA zijn dat de Cschema’s met de nummers 12A, 12B en 13A. De bubble chart methode leidt tot een iets strengere normaalvorm dan het normaliseren, namelijk de Boyce-Codd normaalvorm. In deze normaalvorm bevat elk objecttype een sleutel (die samengesteld kan zijn) en alle daarvan functioneel afhankelijke attributen. De bubble charts, evenals de normalisatie overigens, berusten op het idee van determinatie. Attribuut A determineert attribuut B als men B kan opzoeken wanneer A bekend is. Bijvoorbeeld als ik het klantnummer weet, kan ik het klantadres opzoeken. Het attribuut klantnummer determineert dan het attribuut klantadres. Men zegt ook wel dat het klantadres functioneel afhankelijk is van het klantnummer. Ook wordt wel gezegd dat het klantnummer een determinant is. In bubble-charts worden attributen aangegeven door bubbles (bellen, ovalen met de naam van het attribuut erin). De relaties tussen bubbles worden aangegeven door pijlen: een dubbele pijl betekent dat in de relatie het betreffende attribuut meerdere malen kan voorkomen, en enkele pijl dat het maar éénmaal mag voorkomen. De enkele pijlen geven de richting van de determinatierelaties aan. Voor het tekenen van bubble-charts kan de System Architect module Entity Relation worden gebruikt.
72
voorraadkosten
bestelnr
bestelregel
a+w
attribuut
A
B A determineert B
determinant
A
B A determineert B en B is een deel van A
A
B de verhouding A:B is 1:M, dus B determineert A
A
B bij A hoort een zich herhalende groep waarvan B de determinant is
determinant van zich herhalende groep
combinatie van twee attributen die als determinant optreedt
(door een pijl): de betreffende relatie is geschrapt
Symbolen te gebruiken in bubble-charts
Het tekenen gaat als volgt. Men begint met de bubbles voor de identificerende attributen (determinanten) van de C-schema’s. Voor de JEEKAA-case zijn dat bestelnr, typenr en framenr. Kijk voor de lay-out naar de lay-out van het Bachman-diagram. Daarna zijn de determinanten van de deelgegevensverzamelingen en samengestelde attributen aan de beurt om getekend te worden. Bij JEEKAA zijn dat gewone bubbles voor JEEKAA-naam, levnr, klantnr en gestippelde bubbles voor bestelregel en vraagprognose. Daarna worden per Cschema de relaties getekend tussen de determinant van het hele schema (de z.g. root) en de determinanten van deelgegevensverzamelingen /samengestelde attributen. Denk erom dat bij de determinanten van zich herhalende groepen (deelgegevensverzamelingen die meerdere keren kunnen voorkomen zoals bestelregels) steeds gestippelde bubbles en pijlen moeten worden getekend. Vervolgens wordt per gestippelde bubble, die aangeeft dat daar sprake is van een samengesteld attribuut, bepaald wat de samenstellende delen zijn en daar worden gestippelde pijlen naar toe getekend, als die er nog niet zijn. Het is immers zo dat een combinatie van attributen determinerend is voor elk der deelnemende attributen. Bij JEEKAA moet hier een bubble voor periode worden getekend. Op deze manier ontstaat een raamwerk. Het zo ontstane raamwerk wordt vervolgens aangevuld met de overige attributen en de daarbij behorende relaties. Pas op om niet teveel pijlen te tekenen, want kortere wegen in het netwerk moeten worden geschrapt.
73
w
levw
a + w (1)
a
leva
pc (2)
JEEKAA
klanta
levpc (2)
levnr
levnaam
klantpc (2)
klantnr
bestelnr
besteldatum
klanta + klantw (1)
klantw
leva + levw (1)
klantnaam
verkdatum
framenr
aantal bestelregel annulering voorraad
periode
vraagprognose
typenr
voorraadkosten
model vraag
bestelkosten soort verkoopprijs hoogte kleur
inkoopprijs
Bubble-chart van JEEKAA Het zo ontstane netwerk ondergaat nog enkele bewerkingen. Allereerst wordt gekeken of een combinatie van twee of meer attributen determinerend is voor een bepaalde groep gegevens. Bij JEEKAA zijn adres en woonplaats determinerend voor de postcode. Dit komt drie maal voor: bij JEEKAA, bij de leverancier en bij de klant. Voor elk van deze determinerende combinaties wordt een gestippelde bubble getekend met uitgaande (gewone) pijlen naar de ervan afhankelijke attributen. Vervolgens worden alle kortere wegen geschrapt (dit wordt aangegeven door V-tekens). Daarna worden alle determinanten onderstreept. Indien er 1 op 1 relaties zijn tussen determinanten moeten deze worden samengevoegd. Eén van de determinantnamen verdwijnt dan, hierdoor wordt een V-teken gezet. Uit de bubble-chart van JEEKAA zou nu volgen dat er eigenlijk drie AWPC-tabellen zouden moeten zijn. Dat is iets wat we niet willen; één AWPC-tabel is voldoende. In de bubble-chart kan het samenvoegen worden aangegeven door de overeenkomende bubbles te voorzien van eenzelfde nummer: de combinaties van adres en woonplaats een 1, de postcodes een 2. Uit de bubble-chart van JEEKAA zijn de volgende objecttypen af te leiden door steeds uitgaande van een sleutelattribuut de bijbehorende gedetermineerde attributen bij de attributenverzameling van het objecttype te voegen. 74
3.4.5. Vergelijking resultaten bottom-up ontwikkeling met resultaten top-down ontwikkeling Uit de bottom-up ontwikkeling volgen alle objecttypen die ook uit de top-down methode volgen, namelijk: LEVERANCIER, KLANT, INKOOPTRANSACTIE (BESTELLING), INGEKOCHTE FIETSEN (FIETS-BESTELLING), FIETS, FIETSTYPE. Daarnaast worden onderscheiden: AWPC, JEEKAA en FIETSPROGNOSE. Het objectmodel zal met deze objecttypen moeten worden uitgebreid (zie hieronder voor een diagram, ditmaal met crowfootnotatie).
AWPC
LEVERANCIER
KLANT
leverbare fietstypen JEEKAA
FIETSPROGNOSE
INKOOPTRANSACTIE
INGEKOCHTE FIETSEN
FIETS
FIETSTYPE V
Het uitgebreide objectmodel voor het domein (inclusief attributen) ziet er als volgt uit.
FIETSTYPE fietstypenr levnr model soort hoogte kleur inkoopprijs verkoopprijs voorraad bestelkosten voorraadkosten
76
V
3.5. Objectmodel voor taken 3.5.1. Van use cases naar taakmodel In Paragraaf 2.4. is de gewenste functionaliteit van het informatiesysteem beschreven in termen van vijftien use cases, waarvan er een aantal zijn geanalyseerd op hun onderlinge verbanden. In het nu te maken taakmodel wordt deze verzameling use cases verder uitgebreid en verfijnd. De uitbreiding gebeurt op grond van het onderscheiden van de belangrijkste cognitieve taken. De verfijning gebeurt op grond van een karakterisering van de rolverdeling tussen mens en informatiesysteem bij elk der onderscheiden use cases. Het op die manier gemaakte taakmodel wordt vervolgens omgezet in een objectmodel. In paragraaf 2.4. zijn use cases onderscheiden voor procesbeheer (zie Paragraaf 2.4.1., 2.4.3. en 2.4.4.); informatiebeheer (zie Paragraaf 2.4.2.); systeembeheer (zie Paragraaf 2.4.2.). De beschrijving van deze use cases wordt nog eens bekeken vanuit het oogpunt van cognitieve taken. Daarbij kijken we naar beslissingen die het nodige denkwerk (cognitieve activiteit) vergen. We identificeren de volgende beslissingen: het maken van een verkoopprognose (fietsprognose); het bepalen van de te bestellen hoeveelheden met behulp van de bestelformule; het bepalen of een bepaalde levering van fietsen geaccepteerd kan worden; het aanbevelen van een bepaalde fiets aan een klant. Deze beslissingen worden als activiteiten in de scenario’s van de desbetreffende use cases verwerkt. De wijze van ondersteuning van de mens door een informatiesysteem is onder te verdelen in drie categorieën (aangegeven door de symbolen - + en *): mens ondersteunen; + mens vervangen; * mens niet ondersteunen of vervangen, maar wel registreren wat mens doet. Dit wordt per activiteit aangegeven. (De meeste use cases zijn verdeeld in activiteiten). Een en ander leidt tot het volgende model van de taak van het informatiesysteem in termen van use cases. Procesbeheer: 1. reguliere inkoopbestelling door JEEKAA bij de leverancier (regulier bestellen) (actor: inkoper; trigger: het is maandag); + maken van een verkoopprognose + opvragen gegevens bestelkosten, voorraadkosten ten behoeve van de bestelformule + bepalen van de te bestellen hoeveelheden met behulp van de bestelformule invullen bestelformulier * verzenden bestelformulier naar leverancier (JEEKAA Leverancier) registratie orderacceptatie (Leverancier JEEKAA) 2.
spoed-inkoopbestelling door JEEKAA bij de leverancier (spoedbestelling) (actor: verkoper; trigger: klant wil fiets kopen die niet in voorraad is); opvragen/invullen klantgegevens
annulering inkoopbestelling door JEEKAA bij de leverancier (annuleren bestelling) (actor: verkoper; trigger: klant annuleert); opvragen klantgegevens opvragen gegevens over de te annuleren bestelling + invullen bestelformulier * verzenden bestelformulier naar leverancier (JEEKAA Leverancier) registratie acceptatie annulering order (Leverancier JEEKAA)
4.
leveren van goederen aan JEEKAA door leverancier (inkooplevering) (actor: inkoper; trigger: fietsen komen binnen); registratie gegevens op grond van waarneming fiets en levering (Leverancier JEEKAA) opvragen bestelgegevens + vergelijken levering met bestelling vaststellen of een bepaalde levering van fietsen geaccepteerd kan worden * aftekenen vrachtbon (JEEKAA Leverancier)
5.
bestellen van goederen door de klant bij JEEKAA (verkopen) (actor: verkoper; trigger: klant wil fiets kopen); * verzoek tot levering fiets door klant d.m.v. mondeling of schriftelijk bericht JEEKAA) (Klant opvragen/invullen klantgegevens het aanbevelen van een bepaalde fiets aan een klant + kredietwaardigheid nagaan opvragen fietsgegevens invullen verkoopformulier + verzenden verkoopformulier naar financiële administratie [indien mondeling verzoek dat meteen kan worden afgehandeld] mededelen dat bestelling is geaccepteerd (JEEKAA Klant) + [indien schriftelijk verzoek] maken brief aan klant over orderacceptatie [indien schriftelijk verzoek] verzenden brief orderacceptatie aan klant (JEEKAA Klant)
6.
leveren van goederen aan de klant door JEEKAA (verkooplevering) (actor: verkoper; trigger: fiets is klaar om geleverd te worden); * uitvoering van leveren fietsen d.m.v. fiets (Product) (JEEKAA Klant) verklaring dat leveren fietsen is uitgevoerd d.m.v. vrachtbon ) (JEEKAA Klant) * aanvaarding van verklaring dat leveren fietsen is uitgevoerd d.m.v. aftekenen JEEKAA) vrachtbon (Klant
7.
het beantwoorden van vragen van derden door JEEKAA (beantwoorden vragen) (actor: verkoper; trigger: vraag wordt gesteld). JEEKAA) registratie vraag (Derde maken en mededelen antwoord (JEEKAA Derde)
78
+
registratie antwoord
Informatiebeheer: 8. klantgegevens beheren (actor: verkoper; trigger: verhuisbericht klant of ander bericht over klant komt binnen); 9.
-
algemene fietsgegevens beheren (actor: inkoper; trigger: nieuwe catalogus komt binnen);
10.
-
leveranciersgegevens beheren (actor: inkoper; trigger: naamsverandering, of ander bericht leverancier komt binnen);
11.
-
bijwerken algemene gegevens (actor: systeembeheerder; organisatieverandering, verhuizing of ander relevante gebeurtenis).
12.
-
bestelformule en verwante regels beheren (actor: inkoper; trigger: veranderde inzichten).
verhuisbericht, trigger:
Systeembeheer: 13. + maken backup (actor: systeembeheerder: trigger: het is 8.00 uur); 14.
-
opschonen bestanden (actor: systeembeheerder; trigger: het is 1 januari);
15.
-
beveiliging (actor: systeembeheerder; trigger: het is de eerste van de maand, diversen).
Als men de taken van het informatiesysteem in kaart heeft gebracht verdient het aanbeveling om de samenwerking tussen de verschillende soorten gebruikers (actoren) in een samenhangend bedrijfsproces nog eens na te lopen (gebruik hiervoor het AADX-diagram van de toekomstige situatie). Dit als controle op de volledigheid van, en samenhang tussen, de verschillende use cases. Het taakmodel op basis van use cases dat we nu hebben kan heel goed worden gebruikt bij het maken van een menustructuur voor het informatiesysteem (hetgeen een onderdeel is van de verzameling interfaceobjecten). 3.5.2. Van taakmodel naar objectmodel voor taken Het taakmodel heeft op vier manieren doorwerking in het objectmodel: 1. de structuur van use cases (interacties) en scenariostappen (acties) wordt vertaald in een (hiërarchische of bill-of-materials) menustructuur of schakelbord die wordt opgeslagen in één of twee objecttypen (TAAK en eventueel TAAKSTRUCTUUR) (zie voor deze recursieve structuren paragraaf 3.2.9.); aan de taken die niet van overkoepelende aard zijn moeten systeemfuncties (op te nemen in het objecttype TAAK) worden gekoppeld; deze systeemfuncties kunnen de vorm hebben van bijvoorbeeld het oproepen van een scherm, of het uitvoeren van een stuk programmacode;
79
2.
3. 4.
de domeinobjecttypen van de transactie-categorie zullen moeten registreren wanneer een fase in de transactie definitief is afgesloten en ook moeten bewaken of deze toestandsovergang wel volgens de gestelde regels gebeurt; dit gebeurt na elke scenariostap (actie) waarbij een bericht tussen actoren wordt verzonden (zoals aangegeven in het taakmodel); de hierbij onderscheiden fasen komen overeen met de DEMO-fasen; het registreren gebeurt door het vastleggen van een datum en eventueel een verantwoordelijke (als het niet zo is dat de hele transactie onder één verantwoordelijke valt); er komen dus diverse attribuuttypen bij voor o.a. de datum waarop een fase is afgesloten; er komen objecttypen bij voor het beheren van regels (bij JEEKAA de BESTELFORMULE); de objecttypen worden uitgebreid met methoden voor het invoeren, veranderen, verwijderen en opvragen van gegevens (de insert, update, delete en select methoden); daarnaast komen er bij elk domeinobjecttype op transactiegebied methoden voor het veranderen van de toestand (de commit transaction en reject transaction methoden).
Bij het procesbeheer kennen we de INKOOPTRANSACTIE waarvan de toestandsovergangen moeten worden bewaakt en geregistreerd, terwijl de verkooptransactie wordt geregistreerd als fasen in de levenscyclus van een FIETS. Het beantwoorden van vragen wordt niet geregistreerd; het in beschouwing nemen van toestandsovergangen hierbij is dus niet zinvol. Voor de INKOOPTRANSACTIE en de FIETS nemen we in ieder geval de afronding van de fasen van de DEMO-transactie op als toestanden. Ook kijken we nog eens naar de life cycle van de FIETS in Paragraaf 3.3.5. We beperken ons tot dat deel van de life cycle waarin de fiets zelf fysiek aanwezig is (er is dus een concrete fiets). Dat geeft het probleem dat als een klant een fiets bestelt die niet aanwezig is, deze toestand elders (d.w.z. niet bij de FIETS) moet worden geregistreerd. Dit gebeurt door bij de inkooptransactie te registreren dat een dergelijk klantverzoek is gedaan (hetgeen tot een spoedbestelling leidt); naast klantverzoekdatum registreren we hier ook het klantnr. We komen zo tot de volgende toestandsvariabelen, toestanden en de daarmee samenhangende gegevens: INKOOPTRANSACTIE Afgeronde fase (toestandsvariabele): Bestelling begonnen d.d. Bestelformulier verzonden d.d. Inkooporder geaccepteerd d.d Inkooporder geleverd d.d. Inkooplevering geaccepteerd d. Bestelling afgebroken d.d. Reden afbreken bestelling Klantkoppeling (toestandsvariabele): Door klant aangevraagd d.d. Klantnr FIETS Afgeronde fase (toestandsvariabele): Fiets gearriveerd d.d Fiets door klant besteld d.d 80
Deze gegevens kunnen als attribuuttype bij het betreffende objecttype worden opgenomen, maar als de lijst met mogelijke toestanden erg lang wordt of variabel is zal het noodzakelijk zijn voor de toestanden/ toestandsovergangen een objecttype “TOESTAND INKOOPTRANSACTIE” resp. “TOESTAND FIETS” af te splitsen van de betreffende transactie. Dit heeft als voordeel dat ook allerlei bijzonderheden over de toestandsovergang kunnen worden vastgelegd zoals de verantwoordelijke persoon, de betrokken externe actor, het waarom van de transactie, etc. In onderstaande figuur zijn de generieke (abstracte) objecttypen TRANSACTIE en TOESTAND getekend, waarbij we TRANSACTIE moeten zien als een supertype van INKOOPTRANSACTIE en FIETS. TOESTAND is het supertype van “TOESTAND INKOOPTRANSACTIE” en “TOESTAND FIETS”. De verschillende te onderscheiden typen toestanden en de daarmee samenhangende toestandsovergangen kunnen worden vastgelegd in de objecttypen TRANSACTIETYPE, TOESTANDTYPE en TOESTANDSOVERGANGTYPE. In deze objecttypen wordt vastgelegd welke typen toestanden en toestandsovergangen normaliter voorkomen (d.w.z. het is dan een soort classificatie) of toegestaan zijn (in dat geval wordt in feite een norm vastgelegd die bij een voorgenomen toestandsovergang kan worden geraadpleegd; men kan bijvoorbeeld geen fiets leveren die men zelf nog niet heeft ontvangen). Het toestandovergangtype is gerelateerd aan de al eerder onderscheiden TAAK en de daarmee samenhangende TAAKSTRUCTUUR. Een en ander leidt tot het volgende abstracte objectmodel voor taken. TRANSACTIETYPE transactietype
TOESTAND transactie begintoestandtype eindtoestandtype 1+ uitgevoerde taak datum verantwoordelijke externe actor waarom bijzonderheden
81
TAAKSTRUCTUUR taak hogere taak volgnr
Bij het informatiebeheer hebben we te maken met objecttypen waarvan de meeste al uit het domeinmodel bekend zijn. De BESTELFORMULE komt erbij. Daaraan worden toegevoegd methoden voor insert, update, delete en select. Voor het systeembeheer is het in het kader van de beveiliging noodzakelijk om een objecttype GEBRUIKER te gebruiken voor het bijhouden van gebruikers van het informatiesysteem, hun passwords en hun toegangsrechten. Daarnaast is het gewenst om voor het beheren van de verschillende backups, actuele en historische bestanden een objecttype BESTAND te gebruiken. De effecten van het taakmodel op de reeds eerder onderscheiden domeinobjecttypen in de vom van de insert, update, delete en select methoden (bij de transacties nog aangevuld met en commit transaction en reject transaction) is aangegeven in het onderstaande objectmodel. Daarnaast zijn voor INKOOPTRANSACTIE en FIETS de betreffende TOESTAND objecttypen opgenomen. Tenslotte zijn BESTELFORMULE, GEBRUIKER en BESTAND opgenomen. Dit onderstaande aangepaste objectmodel geeft in combinatie met het eerder gepresenteerd abstracte objectmodel voor taken de effecten van het taakmodel op het objectmodel weer.
insert update delete select 1+ BESTAND bestandsnaam locatie datum laatst bijgewerkt insert update delete select
1+
TOESTAND
BESTELFORMULE
TOESTAND
transactie begintoestandtype eindtoestandtype uitgevoerde taak datum verantwoordelijke externe actor waarom bijzonderheden
bestelformule
transactie begintoestandtype eindtoestandtype uitgevoerde taak datum verantwoordelijke externe actor waarom bijzonderheden
insert update delete select
fietstypenr levnr model soort hoogte kleur inkoopprijs verkoopprijs voorraad bestelkosten voorraadkosten insert update delete select
FIETSPROGNOSE fietstypenr periode vraag insert update delete select
FIETS
INKOOPTRANSACTIE
3.6. Objectmodel voor het gebruikersinterface 3.6.1. Principes voor het gebruikersinterface en huisstijl Een aantal principes voor het ontwerpen van een gebruikersinterface (ontleend aan Schneiderman (1987) zijn: 1. consistentie in lay-out, symbolen, terminologie door het gebruiken algemeen aanvaarde conventies (b.v. Windows, MS-Office) en een daarop gebaseerde huisstijl (hoe onderscheid je je van anderen, hoe presenteer je je consistent); 2. laat de gebruiker aan het stuur zitten, niet de machine: geef kortere wegen voor ervaren gebruikers; geef altijd een 'undo' mogelijkheid; 3. houd rekening met de beperkingen aan het geheugen van de gebruiker: 83
4.
5.
geen ingewikkelde combinaties van functietoetsen e.d.; geef steeds aan wat de gebruiker kan doen (vermijd 'geheime' toetsaanslagen); ontwerp duidelijke dialogen: maak duidelijk wat van de gebruiker wordt verwacht aan het begin van de dialoog; geef duidelijke feed-back (vermijd 'dead air'); ontwerp de boodschappen die door het informatiesysteem worden gegeven als reactie op een bepaalde handeling van de gebruiker; handel fouten goed af: de gebruiker mag geen ernstige, rampzalige fouten kunnen maken; het systeem mag niet kunnen crashen; geef eenvoudige en begrijpelijke foutmeldingen.
Bij het kiezen van een huisstijl moet ermee rekening worden gehouden dat er grofweg gezegd twee soorten gebruikers zijn: toetsgeoriënteerde gebruikers en muisgeoriënteerde gebruikers. Muisgeoriënteerde gebruikers kenmerken zich door een fijne motoriek en een visuele instelling. Zij kunnen reeksen aanslagen minder goed onthouden. Zij vinden het werken met een muis en met vensters fijn. Bij toetsgeoriënteerde gebruikers is soms een minder fijne motoriek aanwezig die leidt tot problemen bij langdurig muisgebruik (muishand of muisarm). Ook kan het voor sommige taken handiger zijn om met enige toetsaanslagen een resultaat te bereiken (een voorbeeld is de fietsenmaker die met vuile handen snel gegevens moet kunnen zoeken). Toetsgeoriënteerde gebruikers vinden het geen probleem om reeksen aanslagen te onthouden. Bij het kiezen van de huisstijl moet worden gelet op eenheid van lettertype, kleurgebruik, layout en dergelijke. Het is vaak het meest praktisch om verdere details over de huisstijl toe te voegen na het programmeren. Tijdens het programmeren moeten dan de gemaakte keuzen over huisstijl worden genoteerd. Bij JEEKAA wordt ervoor gekozen de Windows conventies te volgen (d.w.z. primair een visuele en muisgeoriënteerde interface te maken die echter ook met toetsaanslagen kan worden afgehandeld). 3.6.2. Inleiding gebruikersinterface Het gebruikersinterface bestaat uit schermen (ook wel formulieren, schermformulieren of windows genoemd) waarop gegevens in hun samenhang worden getoond en waarop ook bewerkingsmogelijkheden aanwezig zijn d.m.v. besturingselementen (controls) in de vorm van bijvoorbeeld invoervelden of knoppen. Er zijn verschillende soorten schermen: algemene schermen zoals het welkomstscherm (splash screen) waarop de gebruiker welkom wordt geheten en de naam van het informatiesysteem en/ of het bedrijf staat; menuschermen die dienen om taken te kiezen en de voortgang ervan te volgen; menuformulieren zijn gekoppeld aan het use case taakmodel in de objecttypen TAAK en TAAKSTRUCTUUR; bewerkingsschermen tonen gegevens en laten bewerkingen door de gebruiker plaatsvinden; per use case is er meestal één bewerkingsscherm (soms meerdere); deze bewerkingsschermen zijn gekoppeld aan een samenwerkende groep domeinobjecten (soms in de vorm van een query) die de benodigde gegevens leveren en opslaan.
84
-
subformulieren dienen om bepaalde gegevens binnen een ander formulier te tonen en te bewerken.
Bij JEEKAA is er een welkomstscherm frmFIETSIS en een menuscherm frmMENU. Het menuscherm toont de beschikbare menukeuzen op een bepaalde plaats in de menuhiërarchie. Dit scherm wordt dynamisch aangepast op grond van het selecteren van die taken die op een bepaald moment kunnen worden uitgevoerd. Op het meest gedetailleerde niveau zijn dat scenariostappen binnen een use case. De bewerkingsschermen worden onderscheiden aan de hand van een combinatie van de use cases in het taakmodel (Paragraaf 3.5.1.) en de ISAC-C-schema’s die de structuur van de gebruikte informatieverzamelingen weergeven (Paragraaf 3.4.2.). Mede op grond van het ISAC-A-schema over het informatiegebruik bij het uitvoeren van taken (Paragraaf 2.4.3.) is het mogelijk om de procesbeheer use cases te koppelen aan de informatieverzamelingen. Eén en ander is weergegeven in onderstaande figuur. In de linkerkolom staan de procesbeheer use cases, in de tweede kolom de informatieverzamelingen uit de ISAC-C-schema’s. De getrokken pijlen geven een USES relatie weer en de gestippelde pijlen een EXTENDS relatie. Daarna wordt de figuur aangevuld met de informatiebeheer use cases en de systeembeheer use cases, waarbij er per use case in principe één nieuwe informatieverzameling wordt onderscheiden, tenzij de betreffende informatieverzameling al eerder is opgenomen. Dit leidt tot de informatieverzamelingen en use cases aan de rechterkant van de onderstaande figuur. Met elke informatieverzameling correspondeert een bewerkingsscherm. In het ISAC-Cschema kunnen we zien welke bewerkingsschermen identiek zijn. Dat zij Spoedannulering 8A = Spoedbestelling 7B en Antwoord 11A = Fiets+Klant 13A. Dit leidt tot de volgende bewerkingsschermen. De formuliertypen laten we in de naamgeving beginnen met frm, met uitzondering van de subformulieren die met fsub beginnen. Bewerkingsscherm frmINKOOP
Voor het identificeren van de relaties tussen schermen en van de subformulieren kunnen we eveneens gebruik maken van het ISAC-C-schema. De relaties tussen informatieverzamelingen zijn in onderstaande figuur weergegeven. De USES relatie wijst op een subformulier. De EXTENDS relatie wijst op een uitbreiding van het formulier waarmee de EXTENDS relatie bestaat. Het frmInkoop (informatieverzameling Bestelformulier) heeft bijvoorbeeld een subformulier fsubINGEKOCHTE_FIETSEN (informatieverzameling Bestelregel), terwijl het frmSPOEDBESTELLING (informatieverzameling Spoedbestelling) een uitbreiding (superset) is van het frmINKOOP (de informatieverzameling Bestelformulier). In onderstaande figuur is identiteit met een = aangegeven. 86
D fsubFIETSPROGNOSE
D frmFIETSTYPECIJFERS
D frmJEEKAA
D frmINKOOP
D fsubINGEKOCHTE_ FIETSEN
D frmSPOEDBESTELLING
D frmLEVERANCIER
D frmKLANT
D frmLEVERANCIER_ FIETSTYPE
= D frmSPOEDANNULERING
D frmFIETS
D frmVERKOOP
D frmBESTAND
D frmBESTELFORMULE
= D frmANTWOORD
D frmGEBRUIKER
Dit leidt tot de volgende subformulieren: Subformulier Informatieverzamel Gebaseerd op ing fsubFIETSPROGNOSE Vraagprognose fsubJEEKAA
JEEKAA
frmJEEKAA
fsubKLANT
Klant
frmKLANT
fsubINGEKOCHTE_ FIETSEN fsubFIETSTYPE
Bestelregel Fietstype
frmLEVERANCI ER_FIETSTYPE
fsubLEVERANCIER
Leverancier
frmLEVERANCI ER
De volgende uitbreidingen kunnen worden opgeschreven: 87
Opgenomen in
frmFIETSTYPECIJF ERS frmINKOOP, frmVERKOOP frmSPOEDBESTELL ING frmINKOOP fsubINGEKOCHTE_ FIETSEN, frmVERKOOP, frmFIETS frmINKOOP
frmSPOEDBESTELLING is uitbreiding van frmINKOOP met fsubKLANT, frmFIETSTYPECIJFERS is uitbreiding van frmLEVERANCIER_FIETSTYPE met fsubFIETSPROGNOSE. Na deze analyse van de verschillende typen schermen en subformulieren kunnen we de relatie tussen schermen en de achterliggende domeinobjecttypen vaststellen. Dat doen we alleen voor de basisschermen, d.w.z. de schermen zonder de afgeleide schermen zoals de meeste subformulieren en de uitbreidingen. Ook het subformulier fsubINGEKOCHTE_FIETSEN, dat alleen als deel van frmINKOOPTRANSACTIE voorkomt, laten we weg. Achter elk bewerkingsformulier zijn de domeinobjecttypen aangegeven die dienen als bron en bewaarplaats van de gegevens op het formulier. We krijgen dan het volgende overzicht van de verbanden tussen schermen en achterliggende domeinobjecttypen. Scherm frmFIETSIS frmMENU frmINKOOP
Omdat deze tabel nogal onoverzichtelijk is, is het gebruikelijk om de verbanden tussen schermen en domeinobjecttypen aan te geven in een scherm/ domein-matrix. In deze matrix wijst een C (create) symbool op de methoden insert, update delete, select, commit, reject en select. Hier kunnen veranderingen in de gegevens plaatsvinden. Het symbool U (use) wijst op de methode select. Hier vinden geen veranderingen in de gegevens plaats. We rangschikken de rijen en kolommen zodanig dat we een nette gediagonaliseerde matrix krijgen.
3.6.3. Menustructuur Een relatief eenvoudige menustructuur is de volgende. Er is in het hoofdmenu een eerste indeling naar gebruikende actor (verkoper, inkoper, systeembeheerder). Verder komen hier commando's voor die het systeem besturen zoals einde programma. De tweede indeling bevat alle use cases uit het taakmodel in Paragraaf 3.5.1. In de menustructuur is aangegeven welke bewerkingsformulieren worden opgeroepen. Bedenk dat elk menukeuze in principe een andere toestand veroorzaakt van het taakobject dat bij het opgeroepen bewerkingsformulier hoort. 0.
hoofdmenu (frmMENU 0) 0.1. taken verkoper frmMENU 1 0.2. taken inkoper frmMENU 2 0.3. taken systeembeheerder frmMENU 3 0.4. einde programma 1. taken verkoper (frmMENU 1) 1.1. verkopen frmVERKOOP 1.2. verkooplevering frmVERKOOP 1.3. spoedbestelling frmINKOOP, frmKLANT 1.4. annuleren bestelling frmINKOOP, frmKLANT 1.5. beantwoorden vragen frmVERKOOP 1.6. klantgegevens beheren frmKLANT 1.7. naar hoofdmenu frmMENU 0 2. taken inkoper (frmMENU 2) frmINKOOP, frmLEVERANCIER_FIETSTYPE, 2.1. regulier bestellen fsubVRAAGPROGNOSE 2.2. inkooplevering frmINKOOP, frmFIETS 2.3. leveranciersgegevens beheren frmLEVERANCIER 2.4. fietstypegegevens beheren frmLEVERANCIER_FIETSTYPE 2.5. bestelformule beheren frmBESTELFORMULE 2.6. naar hoofdmenu frmMENU 0 3. taken systeembeheerder (frmMENU 3) 3.1. maken backup frm BESTAND 3.2. opschonen bestanden frmBESTAND frmGEBRUIKER 3.3. beveiliging 3.4. algemene gegevens beheren frmJEEKAA 3.5. naar hoofdmenu frmMENU 0 Een alternatieve hoofdindeling is die naar procesbeheer, informatiebeheer en systeembeheer. 3.6.4. Objectmodel van een formulier Taken worden afgehandeld in formulieren. Formulieren tonen gegevens uit achterliggende domeinobjecttypen en laten ook bewerking van deze domeinobjecttypen toe. Dit betekent dat de structuur van een formulier wordt bepaald door de structuur van de achterliggende objecttypen. Hieronder het objectmodel voor de domeinobjecttypen achter frmSPOEDBESTELLING.
TOESTAND transactie begintoestandtype eindtoestandtype uitgevoerde taak datum verantwoordelijke externe actor waarom bijzonderheden actuele toestand ja/nee
levnr
fietstypenr
fietstypenr levnr model soort hoogte kleur inkoopprijs verkoopprijs voorraad bestelkosten voorraadkosten insert update delete select
CREATE
1+
USE
INKOOPTRANSACTIE CREATE
In de figuur zijn de domeinobjecttypen waarin het formulier de gegevens mag veranderen met CREATE aangegeven. Het hoofdformulier is aan INKOOPTRANSACTIE gekoppeld; aan TOESTAND INKOOPTRANSACTIE en INGEKOCHTE FIETSEN zijn subformulieren gekoppeld. De overige domeinobjecttypen hebben een rol als selectielijsten die helpen bij het invullen van met name de verwijzende sleutels in INKOOPTRANSACTIE en
92
INGEKOCHTE FIETSEN. De uitdrukking USE geeft aan dat het formulier in deze overige objecttypen niets mag veranderen. De gegevens op een formulier kunnen op drie manieren tot stand komen: aut: ze worden automatisch gegenereerd; dit is met name bij sleutels het geval; select: ze worden geselecteerd uit een selectielijst (bijvoorbeeld een combobox of subformulier); edit: ze worden ingevuld (bijvoorbeeld in een textbox). Het elementen van het type aut laat geen bewerking toe. Naast deze drie gegevensgeoriënteerde elementen zijn er ook actiegeoriënteerde elementen, commandoknoppen. Het objectmodel voor de achterliggende objecttypen van een formulier kan op de volgende manier worden vertaald in formulieren, subformulieren en besturingselementen. 1. het CREATE objecttype dat het geheel is wordt de basis voor het hoofdformulier; 2. de CREATE objecttypen die deel zijn worden de basis voor subformulieren; 3. de USE objecttypen corresponderen met selectielijsten (b.v. comboboxen of subformulieren) voor het bepalen van referentiële sleutels; 4. de sleutels van de CREATE objecttypen corresponderen met elementen van type aut (worden automatisch gegenereerd; kunnen veelal onzichtbaar blijven); 5. de referentiële sleutels binnen de CREATE objecttypen corresponderen met elementen van type select (die met behulp van de de selectielijsten genoemd onder 3 worden gevuld); 6. de overige, beschrijvende attribuuttypen in de CREATE objecttypen corresponderen met elementen van type edit (die met de hand moeten worden ingevuld); 7. de methoden in de CREATE objecttypen corresponderen met commandoknoppen. Het verdient aanbeveling om voor de elementen 3 (de selectielijsten) en type 5 (de referentiële sleutels) aparte elementen aan te maken. Men kan dan in de selectielijsten onbekommerd browsen zonder meteen de gekozen referentiële sleutel in de war te gooien. Als men een keuze heeft gemaakt kan die met een commandoknop naar het veld van type 5, waar de referentiële sleutel wordt bewaard, worden overgeheveld. 3.6.5. Specificatie van formulierinvulmethoden in pseudocode De per interfaceobject verder te specificeren methode ‘frm invullen’ kan desgewenst op een meer exacte manier in pseudocode worden uitgeschreven. De daarvoor te gebruiken notatie is een variant van de BNF-notatie. Hierbij hebben de symbolen de volgende betekenis: {} betekent dat er een verzameling van elementen of mogelijke elementen is. | (verticale streep) betekent 'exclusief of' (exclusive OR, o.a. te gebruiken bij opsomming subtypen). , (komma) betekent 'en' (er wordt dan een reeks van elementen of van parallelle processen opgesomd). ; (puntkomma) betekent 'vervolgens', [] duidt op een optioneel element. * na de {} haken betekent dat de verzameling uit nul of meer van tussen de haken opgesomde elementenreeksen bestaat. + na de {} haken betekent dat de verzameling uit één of meer van de tussen de haken opgesomde elementenreeksen bestaat. duidt op invoer door de gebruiker (de betreffende gegevens worden bewaard of weggeschreven).
93
duidt op onstaan van gegevens die door programmatuur binnen het systeem zijn gemaakt (de betreffende gegevens worden bewaard of weggeschreven). <> duidt op een verzameling elementen die elders is gespecificeerd. KLANT (hoofdletters) duidt objecttype aan. bestelformulier (cursief) duidt op document send (kleine letters) duidt op operatie/ actie if (vet) duidt op keyword. . (punt) duidt op operatie/ actie op objecttype of document; of hierarchische geleding (opbouw) van object of document De standaard operaties zijn: insert, update, delete en select. Insert-methoden zijn methoden die een nieuw object toevoegen; Update-methoden zijn methoden die de toestand van een object in termen van bijbehorende attribuutwaarden veranderen; Delete-methoden zijn methoden die alle gegevens over een bepaald object verwijderen; Select-methoden zijn methoden die de gegevens over een bepaalde verzameling objecten en een bepaalde verzameling attributen opvragen. Verder is op documenten van toepassing send en receive. Door middel van if, then en else, in combinatie met begin en end kan men de condities aangeven waaronder een optioneel element van toepassing is. Begin en eind van transacties worden aangegeven door begin_transaction en end_transaction. Met end_transaction corresponderen de methoden commit transaction of reject transaction. Er wordt aangenomen dat de standaard-ondersteuning van insert, update, delete en select wordt geregeld zoals eerder aangegeven bij de taak/ objecttype matrix. Verder wordt aangenomen dat begin_transaction en end_transaction worden ondersteund door het commit/ rollback mechanisme, waarbij aan de gebruiker middels een dialoogschermpje wordt gevraagd de transactie goed te keuren. Het woord me slaat op het document of scherm waarin de taak zich af speelt. het woord in slaat op het scherm (form) of deelscherm (subform) dat wordt gebruikt bij een bepaalde handeling. Een voorbeeld is: FrmSPOEDBESTELLING.invullen = begin { {KLANT.select(klantnaam ) in me.(klantnr)fsubKLANT; [KLANT.insert|update in frmKlant]; klantnr}, {LEVERANCIER.select(levnaam ) in me.(levnr)fsubLEVERANCIER_FIETSTYPE; [LEVERANCIER. insert|update in frmLeverancier] ); levnr}, {maak_bestelregel = FIETSTYPE.select(model+soort+hoogte+kleur ) in me.(levnr)fsubLEVERANCIER_FIETSTYPE.(levnr)fsubFIETSTYPE; fietstypenr; aantal }, {JEEKAA.select(organisatie ) in cboOrganisatie}, datum , }; begin_transaction ; INKOOPTRANSACTIE.insert(klantnr, levnr, organisatie, datum); bestelnr; {insert_bestelregel = INGEKOCHTE FIETSEN.insert(bestelnr, fietstypenr, aantal);
94
lotnr}; {maak_bestelregel; insert_bestelregel}*; end_transaction ; if commit begin rptINKOOP.send end; initialize; end.
Men ziet dat deze specificatie van het met spoed bestellen van fietsen ongeveer even lang is als de meer verbale specificatie van de spoedbestelling. Een dergelijke specificatie in pseudocode staat dichter bij het programmeren, maar is voor niet-ingewijden weer moeilijker te lezen. In het eerste deel van de specificatie zien we vijf parallelle taken: KLANT.select, LEVERANCIER.select, maak_bestelregel, JEEKAA.select en invoer besteldatum. Dat wil zeggen dat zij door de gebruiker in een zelf gekozen volgorde kunnen worden gedaan. Daarna kan de gebruiker opdracht geven tot het aanmaken van een bestelling met de eerste bestelregel erin. Vervolgens kan hij/ zij bestelregels invoeren, die ook worden bijgeschreven, tot de opdracht wordt gegeven tot afsluiting van de bestelling. Als de gebruiker de gegevens dan accepteert wordt vervolgens de bestelling definitief gemaakt en wordt een bestelformulier gemaakt en verzonden. De expressie in me.(levnr)fsubLEVERANCIER_FIETSTYPE.(levnr)fsubFIETSTYPE
laat een hierarchische opbouw van het formulier frmSPOEDBESTELLING (aangeduid met me) zien. Dit bevat namelijk het subformulier fsubLEVERANCIER_FIETSTYPE, dat op zijn beurt weer het subform fsubFIETSTYPE bevat. De geleding wordt door punten aangeven. Na elke punt staat tussen haakjes het attribuut dat zorgt voor een koppeling tussen de hierarchische lagen; in beide gevallen is dit levnr. 3.6.6. Specificatie van formulierinvulmethoden in taal Een formulierinvulmethode wordt in de regel opgeroepen doordat een methode in een taakobject wordt geactiveerd door een menu-optie of een button aan te klikken. Anders dan bij de ouderwetse DOS-programma's is in de Windows-omgeving de logische volgorde niet meer dwingend omdat de gebruiker door het selecteren en bewerken van objecten in de meeste gevallen zelf een volgorde kan bepalen. Met elke stap in de invulmethode hoort iets op het scherm te corresponderen dat de gebruiker kan manipuleren (een button, een invoerveld, een lijstje waaruit kan worden geselecteerd, etc.). Een paar voorbeelden van specificaties van formulierinvulmethoden voor JEEKAA staan hieronder. frmKLANT klantgegevens beheren (gegevensbron: KLANT) 1. select KLANT op klantnaam 2. insert/ update KLANT frmLEVERANCIER_FIETSTYPE algemene fietsgegevens beheren (gegevensbron: LEVERANCIER, FIETSTYPE) 1. select LEVERANCIER op levnaam 2. select FIETSTYPE op model+soort+hoogte+kleur in fsubFietstype 3. insert/ update FIETSTYPE in fsubFietstype (gegevensbron: FIETSTYPE; link via levnr) 95
frmSPOEDBESTELLING spoedbestelling (gegevensbron: INKOOPTRANSACTIE, KLANT, JEEKAA) 1.1. select KLANT op klantnaam in fsubKLANT (gegevensbron: KLANT); uitvoer: klantnr 1.2. [insert/ update KLANT in frmKLANT] 2.1. select LEVERANCIER op levnaam in fsubLEVERANCIER (gegevensbron: LEVERANCIER en FIETSTYPE; link via levnr); uitvoer: levnr 2.2. [insert/ update LEVERANCIER in frmLeverancier] 3. select FIETSTYPE in fsubFIETSTYPE (gegevensbron: FIETSTYPE, link via levnr), dat opgenomen is in fsubLEVERANCIER (gegevensbron: LEVERANCIER, link via levnr), op model+soort+hoogte+kleur; uitvoer: fietstypenr 4. invoeren van aantal 5. select JEEKAA op organisatie met cboOrganisatie 6. controleren, [eventueel invoeren] van datum 7. insert INKOOPTRANSACTIE automatisch met geselecteerde klantnr, levnr, organisatie, datum; hierbij wordt bestelnr automatisch gegenereerd 8. insert INGEKOCHTE FIETSEN (bestelregel) automatisch met geselecteerde bestelnr, fietstypenr, aantal; hierbij wordt lotnr automatisch gegenereerd 9. {herhalen van invoeren bestelregel zoveel als nodig is (nrs. 3, 4, 7)}* 10. accepteren INKOOPTRANSACTIE, waarna rptINKOOP automatisch wordt gemaakt en verzonden; vervolgens weer met schone lei beginnen met nieuwe (spoed)bestelling 3.7. Literatuur over objectmodellen Bekke, J.H. ter. Database ontwerp: Tweede, geheel herziene druk. Leiden: Stenfert Kroese, 1988. Date, C.J. An Introduction to Database Systems: Sixth Edition. Reading, MA: Addison-Wesley, 1995. Dietz, J.L.G. Introductie tot DEMO: Van informatietechnologie naar organisatietechnologie. Alphen a/d Rijn: Samsom, 1996. Dietz, J.L.G. Leerboek Informatiekundige Analyse. Deventer: Kluwer Bedrijfswetenschappen, 1992. Fowler, M., and K.Scott. UML Distilled: Applying the Standard Object Modeling Language. Reading, MA: Addison-Wesley, 1997. Gazendam Henk W.M. Variety Controls Variety: On the Use of Organization Theories in Information Management. Groningen: Wolters-Noordhoff, 1993. Howe, D.R. Data Analysis for Data Base Design. London: Edward Arnold, 1983. Jacobson, Ivar, Maria Ericsson, Agneta Jacobson. The Object Advantage: Business Process Reengineering with Object Technology. Wokingham, England: Addison-Wesley, 1994. Leeuw, A.C.J. de.Organisaties: Management, analyse, ontwerp en verandering: 3e druk. Assen: Van Gorcum, 1988. Peirce, Charles Sanders. Selected Writings: Values in a Universe of Chance. Philip P. Wiener (ed.). New York: Dover, 1958. Rumbaugh, James, Michael Blaha, William Premerlani, Frederick Eddy and William Lorensen. Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall, 1991. Searle, John R. Speech Acts. 1969. Vertaald als: Taalhandelingen. Utrecht: Het Spectrum, 1977. Schneiderman, Ben. Designing the User Interface. Reading, MA: Addison-Wesley, 1987.
96
4. Constructieplan Het constructieplan bestaat uit de volgende onderdelen: 4.1. Keuze ontwikkelomgeving en technische componenten 4.2. Implementatiewijze strokenschema relaties tussen tabellen 4.3. Componenten overzicht componenten 4.4. Handleiding en overige documentatie 4.1. Keuze ontwikkelomgeving en technische componenten In het afgelopen decennium is er aan de aanbodkant van de informatietechnologie een ontwikkeling te bespeuren in de richting van taakverdeling in de bedrijfskolom. Dit betekent dat bedrijven zich er op hebben toegelegd om bepaalde producten goedkoper en met hogere kwaliteit te leveren. De bedrijfskolom in de informatietechnologie ziet er (aan de hand van de soorten producten) ongeveer als volgt uit: besturingssystemen; programmeertalen, database-systemen. middleware; applicaties voor generieke taken (tekstverwerking, office pakketten, e.d.); generieke applicaties voor specifieke taken in te stellen met bedrijfsspecifieke parameters (SAP. Triton, BAAN, e.d.); branchegerichte programmatuur en andere componenten (referentiegegevensmodellen, architecturen, criteria) (Exact, Grote Beer, e.d.). Eén en ander betekent dat er aan de vraagkant een ontwikkeling te zien is van zorgvuldig plannen van wat men zelf gaat uitvoeren (make) naar het tamelijk ad-hoc uitkiezen van de meest geschikte producten op de markt (buy). Met andere woorden, aan de vraagkant is er een ontwikkeling van make naar buy. Wat geschikt gekocht kan worden, wordt gekocht. Datgene wat overblijft om zelf te doen is veelal kleinschalig en moet dat ook zijn. Het voordeel van iets zelf doen, en niet uitbesteden moet vooral liggen in de benutting van specifieke kennis die in de organisatie aanwezig is. Dus wel: bedrijfsprocessen herontwerpen, parameters invullen en de gegevensbank ontwerpen, en niet: generieke componenten e.d. ontwikkelen. Projecten mogen niet langer duren dan drie à zes maanden als ze door informatiekundige specialisten worden uitgevoerd, en moeten binnen enkele weken klaar zijn als ze door z.g. eindgebruikers worden gedaan. Deze kleinschalige, snelle systeemontwikkeling staat bekend als rapid application development (RAD) of model-based application development (MAD)’ (Kranenburg en Van Riel, 1995). Het vak Bouw van Informatiesysteem is gebaseerd op een combinatie van organisatiekundige modellering, de keuze van een gebruikersvriendelijke ontwikkelomgeving, en snelle applicatie-ontwikkeling. In paragraaf 3.1. van de rapportage wordt de keuze van de ontwikkelomgeving en de technische componenten van het systeem beschreven en gemotiveerd. De ontwikkelomgeving is in ons geval Visual dBASE 5.5. of Access. Andere (software) componenten of voorbeelduitwerkingen kunnen wellicht elders worden verkregen (denk aan Internet). Uitgaande van een capaciteitsberekening zowel voor gegevensopslag als voor verwerkingscapaciteit dient een voorstel te worden gedaan voor de benodigde
97
computercapaciteit en de daarbij meest aangewezen computerconfiguratie (b.v. 5 Pentiumcomputers op 120 MHz met ieder 16MB geheugen gekoppeld aan een netwerk waarbij één van deze computers als server optreedt en een hard disk van 12 gigabyte heeft). Voor de berekening van de minimaal benodigde harddiskcapaciteit CHD kan de volgende formule worden toegepast: 10 n m CHD = ∗ ∑ i ∑ j( ni∗ cij ) + cp . 8 1 1 Waarbij: ni = geschat aantal regels voor tabel i cij = capaciteit nodig voor attribuut j in tabel i cp = capaciteit nodig voor programmatuur
4.2. Implementatiewijze 4.2.1. Het strokenschema Het uitgewerkte objectmodel kan worden weergegeven d.m.v. een strokenschema. Dit is een vertaling van het objectmodel naar het relationele gegevensmodel. Bij de implementatie kan men beslissen om tabellen uit efficiëncy-overwegingen samen te voegen. Een bekend voorbeeld is het laten vervallen van een aparte AWPC-tabel, omdat een dergelijke tabel niet loont wanneer er bijna geen adressen met dezelfde postcode in het adressenbestand zijn. Ook andere wijzigingen uit praktische overwegingen kunnen worden toegepast. In het strokenschema worden de sleutels onderstreept en de verwijzende sleutels cursief gedrukt. Onder de namen van de attributen worden het type, de lengte, de decimalen en indexeren aangegeven conform de conventies van de programmeeromgeving (een streepje betekent dat de betreffende waarde niet van toepassing is). Conventies strokenschema Type N C M D A L O
Access Number Text Memo Date/Time Autonumber Yes/No OLE object
98
Index N A D U O
Access None Unique (No Duplicates) Duplicates OK
LEVERANCIER
levnr
levnaam
leva
levw
levpc
levtel
levgiro
A,4,0,A
C,20,-,A
C,30,-,N
C,15,-,N
C,6,-,A
C,10,-,N
C,7,-,N
klantnr
klantnaam
klanta
klantw
klantpc
klanttel
A,4,0,A
C,20,-,A
C,30,-,N
C,15,-,N
C,6,-,N
C,10,-,N
organisatie
naam
a
w
pc
C,4,-,A
C,20,-,N
C,30,-,N
C,15,-,N
C,6,-,N
INKOOPTRANSACTIE
bestelnr
levnr
organisatie
besteldatum
A,6,0,A
N,4,0,A
C,4,-,A
D,-,-,D
INGEKOCHTE FIETSEN
lotnr
bestelnr
typenr
aantal
annulering
N,10,0,A
N,6,0,A
N,4,0,A
N,4,0,N
L,-,-,-
FIETSTYPE
typenr
levnr
model
soort
hoogte
kleur
inkoopprijs
A,4,0,A
A,4,0,A
C,30,-,A
C,1,-,A
N,3,0,A
C,20,-,A
N,8,2,N
verkoopprijs
voorraad
bestelkosten
voorraadkosten
N,8,2,N
N,4,0,N
N,8,2,N
N,8,2,N
framenr
typenr
lotnr
klantnr
organisatie
verkdatum
A,12,0,A
N,4,0,A
N,4,0,A
N,4,0,A
C,4,-,A
D,-,-,D
KLANT
JEEKAA
FIETS
verkleverdatum inkleverdatum D,-,-,D
D,-,-,D
Strokenschema JEEKAA Alle sleutels die uit één attribuut bestaan moeten in principe een automatische nummertoekenning hebben en dus van het type A zijn. Het kan gunstig zijn om bij nietenkelvoudige sleutels een nieuw sleutelattribuut in te voeren dat op automatische nummering is gebaseerd. In één attribuut kunnen veel gegevens worden samengeperst, bijvoorbeeld: Boertjens, Koos. Basiscursus Access 7 voor Windows 95 UK Versie.Schoonhoven: Academic Service, 1996.' Hierin zijn zes attributen samengeperst: auteur-achternaam; auteur-voornaam; titel; plaats van uitgave; uitgever;
99
jaar van uitgave. Een ander voorbeeld is '[email protected]'. Hierin zijn 5 attributen samengeperst. In een objectmodel moeten deze samengeperste attributen zoveel mogelijk worden vermeden. Zij vereisen immers extra programmatuur bij het ontcijferen.
4.2.2. Relaties tussen tabellen De relaties tussen tabellen moeten in Access worden gelegd in de vorm van Relationships. Op deze wijze is het mogelijk om referentiële integriteit af te dwingen. Per relatie moet aangegeven worden op grond van welk veld (of combinatie van velden) de relatie wordt gelegd, welke cardinaliteitsregel de relatie heeft, en welke integriteitsafhandeling is gewenst. Bij de integriteitsafhandeling kan elk van de volgende eigenschappen aan of uit worden gezet: Enforce referential integrity; cascade Updated related fields; cascade Delete related fields. Voor JEEKAA geeft dit het volgende overzicht: Tabel 1
4.3. Componenten 4.3.1. Naamgevingsconventies Volgens de Leszynski-Reddick standaard naamgeving voor Access moet elke naam van een object in Access bestaan uit een voorvoegsel (prefix) van (meestal) drie letters en een basisnaam6. Een voorbeeld is tblLeverancier, de tabel met Leveranciers. De belangrijkste voorvoegsels zijn:
6
Leszynski, Stan, and Greg Reddick. "Naming Objects in Access: Version 2 of a Proposed Standard.", Smart Access Journal, Aug. 1993. Leszynski, Stan, and Greg Reddick. "Revisions to the Leszynski-Reddick Naming Standard for Access 2.", Smart Access Journal, May. 1994. Leszinsky, Stan. Access Expert Solutions. Que Books, 1995. Microsoft Consulting Services Naming Conventions for VB. http://support.microsoft.com/support/kb/articles/Q110/2/64.asp
100
Leszynski-Reddick Naming Convention Prefix Object type First´Level Objects tbl Table qry Query qfil Query (Filter; used to filter a Form's or Report's underlying Table or Query) qpar Query (Parameters specified by a Form) qlkp Query (Lookup; used to provide lists for ComboBox or ListBox) qddl Query (Data Definition Language) qapp Query (Append) qupd Query (Update) qdel Query (Delete) qtot Query (Totals) frm Form fsub Form (Subform) rpt Report rsub Report (Subreport) ncr Macro bas Module Controls lbl txt grp tgl opt chk cbo lst cmd sub
Variables dbs rst a e c bln int str dbl dtm cur var typ
Database Recordset Array Collection (uses Each) Constant Boolean Integer String (Text) Double Date Currency Variant User-Defined Type
4.3.2. Overzicht componenten Componenten zijn alle onderdelen van het informatiesysteem die men gaat maken. Dit zijn: tabellen (tables) (tbl), toegangspaden (queries) (qry), schermformulieren (forms) (frm) (vaak kortheidshalve ook schermen genoemd), rapport-lay-outs (reports) (rpt), macro's (mcr);
101
-
programmamodules (programs / modules) (bas).
Het is belangrijk om in zoveel mogelijk gebruik te maken van algemeen toepasbare componenten. Ook kunnen voorbeeld-componenten bij het programmeren een nuttige rol vervullen. De verzameling schermformulieren is opgebouwd uit applicatieschermen, eenvoudige schermen en complexe schermen. Tot de applicatieschermen horen het titelscherm (splash screen), het schakelbord (switchboard) en eventuele beveiligingsschermen. Bij het starten van de applicatie krijgt men eerst het titelscherm te zien met mooie plaatjes, de titel van de applicatie, de namen van de makers, enzovoorts. Dan volgt een eventueel beveiligingsscherm waarin de gebruiker zich moet identificeren en passwords moeten worden ingevoerd. Vervolgens komt het schakelbord. Het schakelbord moet de mogelijkheid bieden om de uit te voeren taak te kiezen. Voor elk van de beheerstaken, zoals het bijwerken van de gegevensbestanden over o.a. actoren en typen, is er een eenvoudig scherm. De complexe schermen ondersteunen de hoofdtaken die in het ISAC-A-schema en het use-case diagram voorkomen. Per hoofdtaak is er een complex scherm. De structuur van complexe schermen berust vaak op één of meer ISAC-C-schema's. De werking van de complexe schermen is in de taak/ objecttype matrix beschreven. In het constructieplan moet een opsomming van de te implementeren componenten komen. Geef per component: de naam (gebruik de naamgevingsconventies); een omschrijving; de programmeur en de tester (dit zijn in principe verschillende personen). Een (verre van volledige) opsomming van componenten voor het JEEKAA Fietsinformatiesysteem is hieronder gegeven. Merk op dat het officiële voorvoegsel ‘tbl’ is weggelaten bij de tabellen (vanwege de leesbaarheid van programmacode). Ook bij het schakelbord is afgeweken van de naamgevingsconventie omdat we daar bebruik willen maken van de switchboard add-in van Access.
Controleer of de gemaakte tabellen, queries, schermen, menu's, boodschappen, rapporten, labels en programmamodules in het constructieplan zijn gedocumenteerd; stel het constructieplan zo nodig bij. Zorg ervoor dat de programmateksten voorzien zijn van commentaar, onder meer verwijzingen naar de in het constructieplan onderscheiden modules. Per module moet bekend zijn wie de programmeur en wie de tester is.
4.4. Handleiding en overige documentatie De handleiding en overige documentatie dient de volgende zaken te bevatten: handleiding systeemeigenschappen (functionaliteit); installatiehandleiding; gebruikershandleiding; systeemhandleiding (o.a. programmacode).
103
Systeemeigenschappen (functionaliteit) Geef een overzicht van die bijzondere eigenschappen van het door u gemaakte informatiesysteem, waardoor het interessant is voor een potentiële gebruiker. Deze tekst moet bruikbaar zijn voor een reclamefolder of de doos waarin het product is verpakt. Installatiehandleiding Geef aan hoe het informatiesysteem moet worden geïnstalleerd. Vermeld ook de systeemeisen. Gebruikershandleiding Leg het gebruik van het informatiesysteem uit vanuit de taken van de gebruiker. Systeemhandleiding (o.a. programmacode) In de systeemhandleiding wordt een technische uitleg van de opbouw van het informatiesysteem gegeven. Deze handleiding bevat ook een afdruk van de zelf geschreven programmacode in zo min mogelijk bladzijden. De volumineuze uitvoer van bepaalde documentatietools wordt niet op prijs gesteld. Als het gegevensmodel anders is geïmplementeerd dan in het strokenschema en het objectmodel is voorzien, verander deze diagrammen dan alsnog in de uiteindelijke documentatie. 4.5. Literatuur over het constructieplan Kees Kranenburg en Ad van Riel. Model-based Application Development (MAD): .Deventer: Kluwer Bedrijfswetenschappen, 1995.
104
5. Testplan 5.1. Testplan Het testplan volgens het V-model [OMT State] Realisatie
Specificatie
Geaccepteerd systeem
Functionaliteit (Use cases)
Acceptatietest Installatietest
Specificatie
Realisatie Geintegreerd systeem
Basisontwerp (Gegevensmodel Taakmodel)
Integratietest Systeemtest
Specificatie
Realisatie
Detailontwerp (Specificatie Componenten)
Gerealiseerde componenten Componenttest
Specificatie
Realisatie Programma, Specificaties
Geef weer welke tests van het systeem zijn gepland. Over het algemeen zal een testplan de volgende tests bevatten: componenttest: per component wordt een test uitgevoerd; integratietest: test van een (steeds groter ) aantal componenten samen, uiteindelijk van alle componenten; systeemtest: test van de technische eigenschappen (o.a. responsietijd, gebruik van geheugen en harde-schijf-ruimte) van het systeem; acceptatietest: test vanuit het oogpunt van de gebruiker, liefst door de gebruikers zelf; installatietest: installeren van het systeem in verschillende omgevingen, om zo de portabiliteit van het systeem te testen. Stel voor elke test een testprotocol op bestaande uit ca. 10 stappen. Gebruik een realistisch testbestand van ca. 100 gebeurtenissen en 20 à 30 actoren en typen. Programma’s zonder een realistisch testbestand worden niet geaccepteerd.
5.2. Resultaten uitvoering testonderzoek Vermeld de uitkomsten van het uitgevoerde testonderzoek. Dit aan de hand van het opgestelde testprotocol.
6. Programmeren in Access 6.1. Inleiding Deze tekst over het programmeren in Access is géén uitgebreide handleiding voor het programmeren in Access. Daarvoor zijn vele geschikte boeken (zie Paragraaf 6.8.) Ook op Internet 105
is de nodige informatie te vinden7. Het is de bedoeling om uiteen te zetten wat Access kan en niet kan, en hoe de structuur van een Access applicatie er uit ziet. Daarbij wordt met name aandacht besteed aan de taal Visual Basic for Applications (VBA). Deze tekst veronderstelt basiskennis over het programmeren in Access, zoals bijvoorbeeld te vinden is in het boek van Boertjens (1997) Bij het programmeren in Access maken we gebruik van een aantal belangrijke vensters (windows) (paragraaf 2.) en gebruiken we namen voor objecten, variabelen, functies en procedures (paragraaf 3.). Een Access applicatie heeft een structuur waarbij de basis bestaat uit tabellen en de bovenbouw uit formulieren en rapporten (paragraaf 4.). In de programmeertaal van Access weerspiegelt zich de geschiedenis van het programmeren (paragraaf 5.). De gegevensbanktaal van Access is een vrij volledige implementatie van SQL met daaraan toegevoegde extra mogelijkheden (paragraaf 6.). Invoer en uitvoer zijn nodig om een Access programma met de buitenwereld te laten interacteren (paragraaf 7.)
6.2. Belangrijke vensters 6.2.1. Database Window Dit venster wordt automatisch geopend als een database wordt geopend. Het geeft een overzicht van Tables, Queries, Forms, Reports, Macros en Modules. Het verschil tussen macro's en modules is dat macro's een eenvoudig soort programmeertaal bieden en modules de volledige rijkdom van Visual Basic for Applications (VBA), inclusief een goed foutafhandelingssysteem. In de Database Window kunnen objecten worden geopend (Open), ontworpen (Design) en nieuw aangemaakt (New). Bij het nieuw aanmaken van objecten helpt een Wizard. 6.2.2. Database Wizard Als men een nieuwe database wil maken wordt de database Wizard geopend. Hierin kan men kiezen uit één van de vele voorbeeld databases van Access, of zelf beginnen met een blanco database (Blank Database). De voorbeeld databases zijn erg instructief en het loont de moeite om ze te bekijken. Er zijn bijvoorbeeld databases voor grootboek (Ledger), voorraadbeheer (Inventory Control), orderacceptatie (Order Entry), relatiebeheer (Contact Management), boekenverzameling (Book Collection). Een zeer uitgebreid voorbeeld is de Noordenwind (Northwind) database. 6.2.3. De verschillende ontwerpvensters Voor elk van de soorten onderdelen van de database is er een ontwerpvenster. Deze vensters heten in Access Design View. Er zijn vensters geheten Table Design, Query Design (grafisch ontwerpen van queries), SQL (ontwerpen van queries in SQL), Form Design, Report Design, Macro Builder, Expression Builder en Code Builder (ook wel Module Design geheten). Elke macro bestaat uit een aantal regels. Op elke regel staat waarin een conditie, een actie en een lijst met argumenten. Voor het opbouwen van deze argumenten wordt een apart venster gebruikt, de Expression Builder, dat erg handig is. 6.2.4. Object Browser Dit venster kan via het menu alleen in een Module-Editor worden geopend. Kies Module| New| View| Object Browser of F2 om er een te openen. In dit venster ziet u alle bekende 7
The Access Page. http://www.access-developer.com/ Microsoft Office Developer Forum. http://www.microsoft.com/Accessdev/
106
modules en klassen (Modules/Classes) en de daarbij behorende publieke eigenschappen (Properties) en methoden (Methods). Alle programmatuur in Access is georganiseerd in eenheden die modules of klassen heten. Een klasse is een objecttype waaraan programmatuur kan worden gehangen. Klassen zijn meestal formulieren (Forms) of rapporten (Reports). Daarnaast zijn er algemene programmamodules (Modules) die algemene stukjes programma die niet specifiek voor een bepaald soort formulier of rapport gelden bevatten. Achter de namen van eigenschappen (Properties) staat niets en deze kan men ook niet voor inspectie openen. Bij veel properties kan men wel uitleg krijgen via de ? button. De module zelf is benaderbaar als Module eigenschap. Een eigenschap (Property) kan een object zijn. Elk formulier (Form) heeft bijvoorbeeld een ActiveControl. De programmatuur in Access is georganiseerd in Subroutines en Functies. Subroutines geven geen waarde of object terug; functies doen dit wel. De subroutines en functies die bij een klasse horen heten ook wel methoden (Methods). Achter Subroutines staat in de Object Browser [Sub]; achter functies [Function]. Subroutines en functies kan men voor inspectie openen. Ook kan men de programmacode ervan kopiëren.
6.2.5. Debug Window Ook het Debug Window kan via het menu alleen in de Module Editor worden geopend. Kies Module| New| View| Debug Window of Ctrl-G om er een te openen. In het Debug Window kunnen de waarden van variabelen worden afgedrukt met behulp van het Debug.Print commando. Hieronder een voorbeeld voor het afdrukken van de elementen uit een Array met 5 elementen dat is genummerd van 1 tot 5. Sub PrintA(x) Dim i As Integer For i = 1 To 5 Debug.Print x(i) Next End Sub In het Debug Window kan men met behulp van het vraagteken ? commando de waarde van een expressie of variabele opvragen. Probeer maar eens het volgende in te typen: ?1+1 a = 1 ?a 6.3. Namen in Visual Basic for Applications (VBA) 6.3.1. Symbolen In principe bevat elke regel één statement (welgevormde programma-opdracht). Hert teken is dus een statement-beëindiger. Enkele nuttige symbolen bij het programmeren zijn: ' hierna komt commentaar (behalve als dit binnen in een string staat); _ (aan einde regel en gevolgd door nieuwe-regel) het statement gaat op de volgende regel verder; : (midden in een regel) hier is het einde van een statement en hierna komt een nieuw statement (mogelijkheid om meer statements op een regel te krijgen; men mag binnen in strings echter niet op deze manier afbreken); & (tussen twee strings) aan elkaar koppelen van deze twee strings; . (stip operator) hierna komt een eigenschap van een object; ! (uitroepteken operator) hierna komt een element uit een verzameling; [] (vierkante haken) hiertussen staat de naam van een object (verplicht indien in de naam spaties voorkomen); 107
"" = , .
(dubbele aanhalingstekens) hiertussen staat een string; gewone assigment (toekenning waarde aan variabele); list separator (bij Nederlandse setting : puntkomma ;); decimale punt (bij Nederlandse setting: komma ,).
Voorbeeld (goed) a = 1: b = 2: c = 5 'Hierboven meerdere statements op één regel. 'Dit is commentaar. frmLeverancier.RecordSource = _ "Leverancier" rstA.FindFirst_ "[Leveranciersnr] = 12345" Set rstB = dbs.OpenRecordset(_ "SELECT * FROM Leverancier "&_ "WHERE [Woonplaats] = 'Loppersum'") Voorbeeld (fout) Set rstB = dbs.OpenRecordset("SELECT * FROM Leverancier_ WHERE [Woonplaats] = 'Loppersum'") 'Afbreken met _ binnen in een string mag niet. 6.3.2. Objectnamen In Access zijn er vijf namen die altijd bekend zijn. Dit zijn: Application; Forms; Screen; Reports; DoCmd. De meeste andere namen zijn daarvan afgeleid. Een bepaald formulier met naam wordt aangeduid met Forms!. Een alternatieve manier van aanduiden is Form_. Rapporten worden op dezelfde manier aangeduid. Let op het uitroepteken. Dit betekent dat er een element uit een verzameling wordt gekozen. Met het DoCmd object kunnen allerlei methoden worden uitgevoerd, bijvoorbeeld DoCmd.OpenForm "Klanten". Enkele bijzondere namen zijn: Me (hiermee wordt een Form of Report aangeduid als men in de bijbehorende module zit); Screen.ActiveForm (het actieve Form); Screen.ActiveControl (de actieve Control); Screen.PreviousControl (de Control die hiervoor actief was); Screen.ActiveReport (het actieve Report). -
Voorbeeld: Het formulier MijnInvoer is bekend als lid van de verzameling Forms als Forms!MijnInvoer. Zit men in het formulier zelf, dan is het formulier bekend als Me. De class module van een (Form) MijnInvoer is bekend onder de naam Form_MijnInvoer.
108
6.3.3. Variabelen Om in programma's objecten aan te duiden gebruiken we variabelen. Een variabele is een object dat behoort tot een bepaald type, bijvoorbeeld een string (tekst) of een integer (geheel getal). Tijdens het uitvoeren van het programma kan een waarde aan een variabele worden toegekend (dit heet in het Engels assignment); ook kan de aarde van een variabele in het programma worden gebruikt. Hoewel het in VBA niet persé hoeft, is het gebruikelijk (en beter) om in het begin van een stukje programma de variabelen te declareren, d.w.z. de namen te noemen die voor variabelen zullen worden gebruikt, en daarbij aan te geven tot welk type ze horen. In VBA wordt voor het declareren van variabelen het Dim statement gebruikt: Dim As Bijvoorbeeld: Dim strSQL As String Er zijn drie soorten variabelen: Public (globaal); Private (locaal); Static (locaal en blijvend na afloop van uitvoering functie of procedure). Variabelen die met het woord Public zijn gedeclareerd zijn globaal. Een globale variabele is bekend binnen alle modules. Daarbij moet erop worden gelet dat een variabele Getal binnen de eigen module bekend is als Getal, terwijl in andere modules er een objectnaam Forms!MijnKlasse.Getal of aan vooraf moet gaan bijvoorbeeld Form_MijnKlasse.Getal. Een locale variabele is alleen bekend binnen de module of de functie of procedure waarin zij is gedeclareerd. Standaard is dat de variabelen altijd locaal zijn als ze niet met het woord Public worden gedeclareerd. Een variabele heeft als zij met Dim wordt gedeclareerd altijd een scope die overeenkomt met de plaats waar zij is gedefinieerd, d.w.z. dat een variabele gedeclareerd in een functie of procedure alleen binnen die functie of procedure bekend is (d.w.z. locaal), terwijl een variabele die is gedefinieerd op moduleniveau (in de afdeling declarations) binnen die module bekend is. Een static variabele wordt binnen een functie of procedure gedeclareerd. Na afloop van het uitvoeren van de functie of procedure blijft zij beschikbaar en kan dan wordt gebruikt bij een volgende keer dat de betreffende functie of procedure wordt uitgevoerd.
Voorbeeld In het Module Window (Code Builder) onder object: (general), proc: (declarations) staat: Option Compare Database 'Dit is een standaard setting. Option Explicit 'Dit is een standaard setting. Dim strCurrentQuery As String 'Deze variabele is locaal voor de module, dus bij alle 'functies en procedures binnen de module bekend. Const strAll = "SELECT * FROM Groep WHERE Groep > 0" 'Dit is de declaratie van een constante die locaal binnen 'de module bekend is.
109
Public strTrimester As Integer 'Deze variabele is globaal.Omdat zij is gedeclareerd in 'een Standard Module is zij overal bekend zonder een 'voorvoegsel met de naam van de module.
6.3.4. Toekenning van waarde of object aan een variabele De toekenning van een waarde aan een variabele gaat met het = teken. Hierbij wordt de waarde naar de variabele gekopieerd. De toekenning van een object aan een variabele gaat met het SET statement. Hierbij krijgt de variabele een pointer naar het betreffende object en verandert van waarde mee als het betreffende object verandert. De praktijk is dat bij wat ingewikkelder datatypen steeds SET moet worden gebruikt en bij gewone getallen of strings steeds =. Een voorbeeld: a = 10 b = a a = 11 'b is nu nog steeds 10. a = 10 SET b = a a = 11 'b is nu ook 11, omdat a inmiddels van waarde is 'veranderd. 6.3.5. Modulair programmeren Modulair programmeren betekent het opdelen van het programma in een aantal kleinere bouwstenen. Deze bouwstenen kunnen idealiter meerdere keren worden gebruikt. In Access zijn de kleinste bouwstenen functies of procedures (subroutines). Een functie bestaat uit: een regel met de functienaam plus de parameters tussen haakjes; zowel functie als parameters horen een typedeclaratie met As te krijgen; daarop volgende regels met declaraties van locale variabelen door het Dim … As statement; de 'body' van de functie waarin het werk wordt gedaan en een waarde of object aan de functienaam wordt toegekend en een slotregel. Een procedure (subroutine) ziet er ongeveer net zo uit. Alleen het toekennen van een type aan de naam van de procedure ontbreekt evenals het toekennen van een waarde of object aan de procedurenaam. Function ({<parameter> As },*) As Dim { As },* <statement in function body>* End Function
Procedures (subroutines) zien er als volgt uit: [Private] Sub ({<parameter> As },*) Dim { As },* <statement in subroutine body>* End Sub
110
Functies en procedures zijn weer georganiseerd in modules. Modules kunnen horen bij een type Form of Report (dan heten ze Class Modules) of zelfstandig zijn (dan heten ze Standard Modules). Modules bevatten naast functies en procedures ook nog een gedeelte Declarations. Hierin worden variabelen gedeclareerd die hetzij globaal zijn (dus bij alle modules bekend zijn) of lokaal voor de hele module gelden (d.w.z. niet voor een bepaalde functie of procedure afzonderlijk).
Voorbeeld Function strReverse(str As String) As String 'Functie voor het omkeren van een string Dim n, i As Integer n = Len(str) strReverse = "" For i = 1 To n Step 1 strReverse = strReverse & Mid(str, n - i + 1, 1) Next End Function 6.4. Structuur van een Access applicatie 6.4.1. Structuur van een Access applicatie In Access bestaat een applicatie uit een basis van tabellen en relaties waarop een bovenbouw van formulieren en rapporten rust. Aan de bovenbouw is een stelsel van programmatuur bevestigd in de vorm van functies en procedures opgenomen in z.g. class modules en van macro's die in de algemene macrobibliotheek worden opgenomen.
Class Modules/ Macros Forms Reports Queries Tables/ Relationships Een Form (formulier) of Report (rapport) is altijd gebaseerd op een (combinatie van) tabellen en queries. Er staan verschillende Controls (besturingselementen) op. Bij elke Control hoort een verzameling Events (gebeurtenissen) waarvan sommigen zijn gekoppeld aan een uit te voeren macro, procedure, functie of query. Alle bij een Form behorende definities, procedures en functies zijn georganiseerd in een bij het Form behorende module, een z.g. class module. Binnen elke class module zijn de
111
procedures en functies ingedeeld naar control (besturingselement ) en event. Daarnaast bestaan er ook onafhankelijke modules die definities, procedures en functies bevatten, de z.g. standard modules. Macro's bieden een alternatief voor functies en procedures. Alle macro's zijn opgeslagen in een afzonderlijke macrobibliotheek. SQL statements kunnen in de vorm van een string worden opgeslagen en ergens in een eigenschap of variabele worden bewaard of apart worden opgeslagen in de querybibliotheek. Deze structuur van een Access applicatie wordt hieronder verder uitgelegd.
6.4.2. De basis van de applicatie De basis van een Access applicatie wordt gevormd door de tabellen en de relaties tussen de tabellen. Deze zijn direct uit het objectmodel en het strokenschema af te leiden. Denk erom dat de verbanden tussen de tabellen goed worden gelegd met behulp van verwijzende sleutels ("referential keys"). Dit gaat als volgt. Als er tussen twee tabellen een één op meer relatie bestaat (bijvoorbeeld tussen Leverancier en Bestelling), dan moet vanuit de méér-tabel (hier de Bestelling) naar de gerelateerde record in de één tabel (d.w.z. een bepaalde leverancier) worden verwezen door middel van het opnemen van een verwijzende sleutel (een veld dat de sleutel van de één-tabel bevat). In het geval van Leverancier en Bestelling moet er dus in de tabel Bestelling een veld LeveranciersNr worden opgenomen, dat verwijst naar het sleutelveld LeveranciersNr in de tabel Leverancier. Hiervoor worden de Table Design View en de Relationship Design View gebruikt (de laatste op te roepen door de menukeuze Tools| Relationships). De relaties dwingen referentiële integriteit af indien Enforce Referential Integrity is aangekruist. De twee Cascade mogelijkheden betekenen een versoepeling van de afgedwongen referentiële integriteit en kunnen in de meeste gevallen beter niet worden aangekruist (een uitzondering is het geval waarbij de delen moeten worden verwijderd of veranderd als het geheel ook wordt verwijderd of veranderd).
6.4.3. De functionele structuur neergelegd in de Switchboard Manager De functionele structuur van een Access applicatie kan men heel goed uitwerken met behulp van de add-in Switchboard Manager. In het Database Window is deze add-in op te starten met Tools| Add-ins| Switchboard Manager. Met de Switchboard Manager kan een applicatiescherm, ook wel schakelbord of switchboard geheten, worden gemaakt waarop knoppen staan die de verschillende functies van de toepassing oproepen. Het switchboard is ingedeeld in een aantal schermen die in een hiërarchische structuur met elkaar samenhangen. In principe moet men alle systeemfuncties die in het constructieplan zijn onderscheiden als keuzemogelijkheid in het applicatiescherm kunnen onderbrengen. Bij het maken van een dergelijk applicatiescherm met de Switchboard Manager merkt men vaak dat er verschillende systeemfuncties zijn vergeten. De structuur van de applicatie wordt door de Switchboard Manager opgeslagen in de tabel Switchboard Items. Het is interessant om deze tabel eens te bekijken. Zij bevat de volgende velden: Veld SwitchboardId ItemNumber ItemText Command Argument
Betekenis het nummer van het scherm waar de knop bij hoort het volgnummer van de knop op het scherm de tekst behorende bij de knop code voor het uit te voeren commando parameters voor het uit te voeren commando
De volgende commando's worden onderscheiden:
112
Code 0 1 2 3 4 5 6 7 8
Betekenis doe niets ga naar een ander scherm open formulier in edit mode open formulier in add mode open rapport in preview mode verander switchboard sluit applicatie voer macro uit voer code uit
Parameters (geen) nummer van het scherm formuliernaam formuliernaam rapportnaam (geen) (geen) macronaam naam van functie of procedure
Als we een dergelijk switchboard hebben gemaakt hoeven we eigenlijk alleen nog maar de nodige formulieren en rapporten te maken.
6.4.4. Verbanden via de RecordSource eigenschap In de relationele database theorie kennen tabellen geen aanwijzer die een bepaald record aangeeft waarmee wordt gewerkt. Access kent wel een mogelijkheid om met aanwijzers te werken. Dit gebeurt met Recordsets. Een Recordset is een soort kopie van de tabel waaraan een aanwijzer (Bookmark) wordt toegevoegd. Bij een kunnen één of meer recordsets worden gemaakt. Een Recordset kan ook worden gebaseerd op een SQL query. Dit gebeurt met de methode OpenRecordset van de huidige database. Dim dbs As Database, rstA As Recordset, rstB As Recordset Set dbs = CurrentDb Set rstA = dbs.OpenRecordset("Leverancier", dbOpenTable) Set rstB = dbs.OpenRecordset(_ "SELECT * FROM Leverancier "&_ "WHERE [Woonplaats] = 'Loppersum'") Voor het afbeelden van een record uit een tabel in een Form is een Recordset nodig, immers de Form moet 'weten' welk record moet worden afgebeeld. Elke Form kan aan één tabel (of query) worden gekoppeld door middel van een Recordset. Deze recordset die bij een Form hoort is voor ons niet direct toegankelijk; we kunnen er wel een kopie van maken met de RecordsetClone methode. Set rstA = frmLeverancier.RecordsetClone In deze kopie van de recordset kunnen we een bepaald record opzoeken, en daar de aanwijzer (Bookmark) van opvragen: rstA.FindFirst "[Leveranciersnaam] = 'Jansen'" book = rstA.Bookmark Hierna kunnen we de Bookmark van het formulier (d.w.z van de recordset van het formulier) opvragen en verzetten: frmLeverancier.Bookmark = book Het kan natuurlijk ook meer direct: frmLeverancier.Bookmark = rstA.Bookmark Aan elk hoofdformulier of subformulier (allemaal Forms) ligt in de regel een tabel of query ten grondslag. De naam van deze tabel of query wordt ingevuld bij de eigenschap RecordSource van de Form. frmLeverancier.RecordSource = "Leverancier"
113
Als dit is gedaan kunnen velden zoals TextBoxes in het formulier worden gekoppeld aan velden in de gekoppelde tabel of query. Als men nu gegevens in een gekoppelde TextBox gaat veranderen, veranderen de gegevens in de onderliggende tabel mee. Denk erom dat het invullen van een ander nummer in bijvoorbeeld een aan het ordernummer gekoppelde TextBox niet zorgt voor het navigeren naar het record dat hoort bij het nieuwe ordernummer maar het ordernummer van het CurrentRecord probeert te veranderen (en dat geeft bij referentiële integriteit vaak een foutmelding). Navigeren in de Recordset van een Form kan daarom alleen via niet-gekoppelde besturingselementen. Daarom onderscheiden wij weergave-elementen van selectie-elementen. Het navigeren via een niet-gekoppeld selectie-element gaat als volgt: 1. eerst wordt de waarde van het element veranderd; 2. daarna wordt een event gegenereerd waar we gebruik van maken (meestal AfterUpdate); aan dat event zijn dan de navolgende acties gekoppeld; 3. in een RecordsetClone van het Form wordt met behulp van de waarde van het element een record gezocht (bijvoorbeeld met de FindFirst methode); 4. de aanwijzer (Bookmark) van de RecordsetClone wordt gekopieerd naar de aanwijzer van het Form; het hoofdformulier wordt nu bijgewerkt 5 de subformulieren worden door middel van een Requery commando bijgewerkt. Deze werkwijze wordt hieronder aan de hand van een voorbeeld uitgewerkt. We gaan een combobox maken waarmee we een bepaalde leveranciersnaam kunnen opzoeken. Het formulier schakelt dan over naam de overige gegevens van die leverancier. Het formulier frmLeverancier wordt met een wizard gemaakt op grond van de leverancierstabel. Alle velden van de tabel staan dan als textboxen op het formulier. Er wordt een combobox cboLeverancier gemaakt. In deze combobox is de ControlSource leeg (dus deze combobox is een niet-gekoppeld elemenet dat als selectieelement kan worden gebruikt). Als RowSource wordt de tabel Leverancier gekozen; het systeem vraagt om hier een query te definieren en we kiezen levnr en levnaam uit als op te halen gegevens. De query luidt dan: SELECT Leverancier.Levnr, Leverancier.Levnaam FROM Leverancier; Hierna vullen we in bij BoundColumn:, en bij ColumnCount: 2. We werken immers met twee kolommen waarvan de waarde van de eerste kolom moet worden uitgekozen. Daarna zetten we de breedte van de eerste kolom op nul om hem onzichtbaar te maken; we kiezen dan uit de namen van de leveranciers; ColumnWidths wordt dan 0;4. Daarna kiezen we het AfterUpdate event, vervolgens de CodeBuilder en typen de volgende programmacode in. In deze programmacode zijn de bovengenoemde stappen 3 en 4 verwerkt. Omdat er geen subformulieren aanwezig zijn is er geen requery voor deze subformulieren nodig. Vergeet deze requery echter niet als er wel subformulieren zijn! Private Sub cboLeverancier_AfterUpdate() Dim rstA As Recordset Set rstA = Me.RecordsetClone rstA.FindFirst "[Levnr] = " & Me![cboLeverancier] Me.Bookmark = rstA.Bookmark End Sub
114
6.4.5. Verbanden via subformulieren Subformulieren moeten eerst apart als formulier worden gemaakt. Daarna kunnen ze aan een Subform/subreport-element (Control) in het hoofdformulier worden verbonden. Dit gebeurt door de eigenschap SourceObject van deze Control in te stellen op de naam van het gemaakte subformulier. Het verband tussen de waarden van hoofdformulier en subformulier gebeurt door het invullen van de eigenschappen LinkChildFields en LinkMasterFields van deze Subform/subreport Control. Men vult dan in de regel de naam in van de sleutel van de gegevens onder het hoofdformulier en de (als het goed is identieke) naam van de daarnaar verwijzende sleutel van de gegevens onder het subformulier. 6.4.6. Verbanden via comboboxen ComboBoxen (lijsten met invulmogelijkheid) worden in het algemeen gebruikt om waarden op te zoeken. Na het opzoeken krijgt de ComboBox een andere waarde en wordt een AfterUpdate gebeurtenis (event) gegenereerd. In de procedure bij deze gebeurtenis kan vervolgens worden gespecificeerd wat er met de nieuwe waarde van de ComboBox moet gebeuren. Dat kan bijvoorbeeld zijn het navigeren in een RecordSet (zie hierboven)of het invullen van een waarde in een veld of TextBox. Laten we als voorbeeld nemen dat op grond van een ComboBox waarin leveranciersnamen zichtbaar zijn een leveranciersnummer moet worden ingevuld in het Bestelformulier. Daarna moeten de op het formulier zichtbare leveranciersgegevens worden ververst. We krijgen dan de volgende programmacode. Private Sub cboLeverancier2_AfterUpdate() Me![Leveranciersnr] = [cboLeverancier2] Me.subfLeverancier.Requery End Sub Enige belangrijke eigenschappen van de ComboBox cboLeverancier2 zien er als volgt uit. Eigenschap ControlSource
Waarde
RowSourceType
Table/Query
RowSource BoundColumn
"SELECT (Leveranciersnr, Leveranciersnaam) FROM Leverancier" 1
LimitToList
Yes
ColumnCount ColumnWidths
2 0cm,2.56cm
Betekenis veld waaraan ComboBox is gekoppeld (geen i.v.m. selectiefunctie) soort bron voor de regels waaruit gekozen kan worden query die de te gebruiken regels geeft kolom waarvan de waarde na keuze de waarde van de ComboBox wordt (het Leveranciersnr dus) ingevoerde waarden moeten in de lijst staan twee kolommen delen van de kolommen die zichtbaar zijn; de eerste kolom (het Leveranciersnr) is dus onzichtbaar
Het is belangrijk te onderscheiden dat een ComboBox een invoerkoppeling (de RowSource) heeft en een uitvoerkoppeling (de ControlSource). Bij een ComboBox die een selectiefunctie heeft wordt de ControlSource niet ingevuld.
6.4.7. Gebeurtenisprocedures Aan elke Control is een standaard gebeurtenisprocedure gekoppeld die in de Form Design View via een | Build Event is op te roepen. Kies vervolgens Code Builder om in VBA verder te gaan.
115
6.4.8. Algemene functies en procedures Het verdient aanbeveling om de programmatuur behorende bij een Access-applicatie op een nette manier in te richten. Daarbij moeten de te verrichten taken zo goed mogelijk worden verdeeld over Standaard-Modules, abstracte klassen (Forms die uitsluitend als Class Module worden gebruikt) en de modules die aan de verschillende Forms en Reports zijn gekoppeld. Binnen de modules die bij Forms en reports behoren moet weer worden gekeken welke zaken onder algemeen (General) moeten vallen en welke aan een bepaalde Control zijn gekoppeld. Maak waar mogelijk algemeen bruikbare programmamodules. Hierbij kan onder andere worden gedacht aan modules voor: bepaalde meldingen en dialogen (o.a. foutmeldingen); zoeken in de wereld van de tekst; bepaalde berekeningen. Algemeen bruikbare programmamodules worden in ieder geval daar toegepast waar sprake is van abstracte datatypen en van algoritmen die volgens de handboeken een efficiënte oplossing kennen. Deze worden in de vorm van een abstracte klasse vormgegeven (d.w.z. aan een Form gekoppeld dat uitsluitend als dient als anker voor een Class Module). Plaats systeeminformatie in een apart bestand met algemene gegevens. Dit bestand kan de structuur hebben van ALGEMEEN:{attribuut, waarde}. In een dergelijk bestand kunnen bijvoorbeeld worden opgeslagen: hoogste in gebruik zijnde klantnummer; helpboodschappen; BTW percentages; gebruikers en wachtwoorden. Als dit bestand teveel uitdijt, moet worden overwogen om het te splitsen in meer gespecialiseerde systeembestanden.
6.5. Gestructureerd programmeren 6.5.1. De ontwikkeling in het programmeren De ontwikkeling van het programmeren is terug te vinden in de Access taal. Men vindt er de volgende soorten programmeren in terug: imperatief programmeren (uitgebreid); functioneel programmeren (zeer beperkt!); object-georiënteerd programmeren (beperkt); event-georiënteerd programmeren (zeer uitgebreid). 6.5.2. Imperatieve programmastructuren Imperatief programmeren gebeurt vaak in de talen programmastructuren zijn: sequentie; selectie of keuze(if- then structuur); iteratie (loop). In Access zijn deze structuren als volgt geïmplementeerd.
BASIC
of
PASCAL.
De
Sequentie Bij sequentie worden programmaregels na elkaar uitgevoerd. Dit is de basisstructuur van Access functies en procedures (maar bijvoorbeeld niet van Prolog-programma's).
116
Selectie If Then <statementT>* [Else <statementF>* End If Voorbeeld: If VoorraadFietsen < 10 Then BestelFietsen(3) Else BestelFietsen(1) End If of Select Case Case <expression1> <statement1>* Case <expression2> <statement2>* . . . Case Else <statementE> End Select
Voorbeeld: Select Case Beoordeling Case "goed" Cijfer = 8 Case "voldoende" Cijfer = 6 Case "onvoldoende" Cijfer = 4 Case Else BeoordeelOpnieuw() End Select Iteratie Een iteratie is een lus of 'loop', een blok code dat meerdere keren wordt uitgevoerd tot aan een bepaalde conditie wordt voldaan: Do While <statement1>+ [Exit Do] [<statement2>*] Loop Bij iteratie is het belangrijk om de stopconditie goed te specificeren, ander krijgt men een eindeloze lus. Zorg er daarom voor dat in de lus de waarde van de variabelen die een rol spelen in de worden veranderd. Als bekend is hoeveel keer een iteratie moet worden uitgevoerd, gebruikt men de 117
For . . . Next constructie: For = To <end> [Step ] <statement1>+ [Exit For] [<statement2>*] Next Zorg ervoor dat de teller (counter) in de lus van waarde wordt veranderd, anders ontstaat er een eindeloze lus.
6.5.3. Functionele programmastructuren De talen die hiervoor vaak gebruikt worden zijn LISP en APL. Het programma bestaat uit louter datastructuren en functies. De verschillende datastructuren voeren functies uit. Het nieuwe aan functionele talen is de recursie die op drie plaatsen optreedt: recursie van functies: een functie roept zichzelf aan (recursie in engere zin); recursie van datastructuren: een datastructuur kan als element eenzelfde soort datastructuur bevatten; recursie van programmacontrole: onder programmacontrole wordt een stukje programma geschreven, daarna wordt dit stukje programma gecompileerd en uitgevoerd waarbij de programmacontrole aan dat stukje programma wordt overgedragen. Daarnaast komt in functionele talen verzamelings-iteratie voor: alle elementen uit een verzameling datastructuren worden gecombineerd met alle elementen uit een verzameling functies. In Access zijn deze programmastructuren beperkt geïmplementeerd, en wel als volgt.
Recursie Men spreekt van recursie als een functie zichzelf aanroept. Dit kan binnen Access. Een bekend voorbeeld is de berekening van een faculteit. Function Faculty(A As Integer) As Double If A <= 1 Then Faculty = 1 Else Faculty = Faculty(A - 1) * A End If End Function Het datatype van de functie moet geschikt gekozen worden. In bovenstaand voorbeeld loopt Access na 7 recursiestappen vast wegens stack overflow als voor de Function Faculty het datatype Integer wordt gekozen. Met het datatype Double werkt het echter wel. Zie voor andere voorbeelden van recursie Getz and Gilbert (1998: 235, 261)
Recursieve datastructuren Access kent de volgende standaard datastructuren: arrays; collections. Een array heeft een vast aantal elementen. Het kan meerdimensionaal zijn. Een collection heeft een variabel aantal elementen en is ééndimensionaal. Een array kan als element een
118
ander array bevatten. Een collection kan als element echter niet een andere collection bevatten. Recursieve datastructuren zoals stacks, binaire bomen, wachtrijen, en lists kunnen wel met Access worden geprogrammeerd. Zie hiervoor Getz and Gilbert (1998: 355-410).
Array operaties Dim aMijnArray( 1 To 5, 1 To 5) Een 5 bij 5 array wordt gedeclareerd waarin de telling steeds van 1 tot 5 loopt (standaard telt Access vanaf 0). Redim Preserve aMijnArray (1 To 6, 1 To 6,) Het oorspronkelijke array wordt uitgebreid tot 6 bij 6 met behoud van de erin opgeslagen waarden. aMijnArray(3,4) = 12 De waarde 12 wordt aan element 3,4 toegewezen. Een array kan gegevens van slechts één datatype bevatten. Dat datatype mag ook Variant zijn, d.w.z. dat alles is toegestaan. x = aMijnArray(3,4) De waarde van element 3,4 wordt aan de variabele x toegewezen.
Collection methoden Dim eMijnCollectie As New Collection Declaratie van een nieuwe collectie genaamd eMijnCollectie. eMijnCollectie.Add 10 Voeg het getal 10 toe aan eMijnCollectie. eMijnCollectie.Add 20 Voeg het getal 20 toe aan eMijnCollectie. eMijnCollectie.Add 30 Voeg het getal 30 toe aan eMijnCollectie. Dim Aantal As Integer Aantal = eMijnCollectie.Count Debug.Print Aantal Toont het aantal elementen in eMijnCollectie. eMijnCollectie.Remove(aantal) Verwijdert het laatste getal uit eMijnCollectie. eMijnCollectie.Remove(1) Verwijdert het eerste getal uit eMijnCollectie.
119
Recursie van programmacontrole Recursie van programmacontrole houdt in de omzetting van tekst in programmacode die vervolgens wordt uitgevoerd. Dit is een erg handig hulpmiddel voor de gevorderde programmeur. Het programma kan als het ware zichzelf schrijven. Helaas is deze vorm van recursie in Access slechts zeer beperkt toepasbaar. In Access kan dit alleen bij het uitvoeren van SQL queries: men kan zelf een string samenstellen die dan vervolgens uitvoeren door bijvoorbeeld het gebruiken van de .OpenRecordset methode Verzamelings-iteratie Met de For Each . . . In iteratie kan men alle elementen van een verzameling (collection) een bepaalde bewerking laten doen. Voorbeeld: Dim element As Variant For Each element In colExample Debug.Print element Next 6.5.4. Objectgeoriënteerde programmastructuren Object-georiënteerd programmeren bestaat uit het definiëren van klassen van objecten, en het laten werken van instanties van deze klassen (de eigenlijke objecten). Objecten hebben attributen die alleen voor het object zelf toegankelijk zijn. Aan de klasse van een object zijn de methoden gehangen die een object kent en die bepalen hoe het op boodschappen reageert. Klassen zijn georganiseerd in een klassehiërarchie. Het bekendste, en meest zuivere, voorbeeld van object-georiënteerd programmeren is Smalltalk. Object Pascal en C++ zijn andere voorbeelden die door sommigen niet als zuiver object-georiënteerd worden gezien. Access kent een aantal objectgeoriënteerde eigenschappen. Het kan echter geen objectgeoriënteerde taal worden genoemd omdat het niet mogelijk is klassehiërarchieën met overerving te bouwen. Het is wel mogelijk om zelf typen (datastructuren) en klassen te definiëren. Het definiëren van klassen gaat via een omweg. Typen (datastructuren) In objectgeoriënteerde programmastructuren bestaan objecten waaraan attributen zijn gekoppeld. Stel men heeft het object met de objectnaam Karel. De attributen van Karel kunnen worden bereikt met behulp van de stip-operator: Karel.Leeftijd geeft toegang tot de leeftijd van Karel, bijvoorbeeld: Debug.Print Karel.Leeftijd drukt de leeftijd van Karel af Karel.Leeftijd = 24 wijst de waarde 24 aan het attribuut leeftijd van Karel toe. Welke attributen aan een object bekend zijn is gedefinieerd in het type van een object. Een voorbeeld van een typedefinitie is: Type Persoon Naam As String * 20 Adres As String * 30 Woonplaats As String * 20 Leeftijd As Integer Kredietlimiet As Integer End Type Een typedefinitie moet op moduleniveau (declarations) worden gedaan. Meestal is een standaard module de aangewezen plaats; de typedefinities in een class module moeten altijd Private zijn.
120
Van een type kunnen instanties (de eigenlijke objecten) worden gemaakt door een declaratie: Dim Karel As Persoon Karel is nu een variabele van het type Persoon geworden.
Klassen Naast typen kent Access ook klassen (class modules) die steeds zijn gekoppeld aan een soort Form of Report. Men kan zelf een nieuw soort Form definiëren met als doel dit te gebruiken als klasse waarin attribuuttypen en methoden zijn gedefinieerd. Hieronder een voorbeeld. In het Form MijnKlasse is alleen het volgende opgenomen (er zijn geen controls aan toegevoegd!): (declarations) Option Compare Database Option Explicit Dim Getal As Integer Sub Schrijf(a As Integer) Getal = a End Sub Function Lees() As Integer Lees = Getal End Function Function Kwadraat() As Integer Kwadraat = Getal * Getal End Function
In het Form Twee zijn de volgende Controls opgenomen: Kijk (een Text); Zie (een Text); Schrijfgetal (een Button); Leesgetal (een Button); Kwadraat (een Button). Daarnaast is de volgende programmacode opgenomen: (declarations) Option Compare Database Option Explicit Dim Instantie As New Form_MijnKlasse Private Sub SchrijfGetal_Click() Instantie.Schrijf (Me.Kijk) End Sub Private Sub LeesGetal_Click() Me.Zie = Instantie.Lees() End Sub Private Sub Kwadraat_Click() Me.Zie = Instantie.Kwadraat() End Sub
121
Deze programmacode maakt gebruik van de instantie Instantie van de klasse Form_MijnKlasse (let op het voorvoegsel Form_ dat nodig is om de klasse MijnKlasse te bereiken). Met deze instantie worden allerlei dingen gedaan: een waarde opgeslagen, teruggevraagd en gekwadrateerd. De invoer gaar via het tekstveld Kijk, de uitvoer via het tekstveld Zie.
6.5.5. Event-georiënteerde programmastructuren Event-georiënteerd programmeren berust op het maken van zichtbare objecten (b.v. Windows) en deelobjecten (b.v. buttons, textboxen, scrollbars) waarop acties van de gebruiker mogelijk zijn. Elke actie leidt tot een event dat afgehandeld moet worden. Het programmeren gebeurt door het (visueel op het scherm) samenstellen van objecten met deelobjecten. De bij deze (deel)objecten behorende events staan meestal vast. Vervolgens kan per event een afhandeling worden gedefinieerd. Het bekendste voorbeeld van deze programmeerstijl is Visual Basic, waarvan VBA een subset is. Het programmeren in Access is event-georiënteerd programmeren. In Access bestaat een applicatie uit een basis van tabellen en queries waarop formulieren en rapporten berusten, terwijl macro's en modules helpen bij het afhandelen van gebeurtenissen (events). Een Form (formulier) is altijd gebaseerd op een (combinatie van) tabellen en queries. Er staan verschillende Controls (besturingselementen) op. Bij elke Control hoort een verzameling Events (gebeurtenissen) waarvan sommigen zijn gekoppeld aan een uit te voeren macro, procedure, functie of query. Alle bij een Form behorende definities, procedures en functies zijn georganiseerd in een bij het Form behorende module. De organisatie van de programmatuur (met name functies en procedures) volgt in Access sterk de opbouw FormControl-Event. 6.5.6. De in Access gebruikte talen Het taalsysteem waarin de programmatuur kan worden geschreven is gemengd: het bestaat uit de Access macrotaal, Visual Basic for Applications (VBA) en SQL. In de Access macrotaal kan een VBA functie worden aangeroepen door het gebruik van de RunCode action, en SQL door middel van de RunSQL <SQL statement> actie. Een andere macro kan met de RunMacro <macro name> actie worden uitgevoerd. In VBA kan SQL worden uitgevoerd door middel van de methode OpenRecordset die bij een database object behoort. Er wordt dan een recordset gemaakt op basis van een SQL query. Een voorbeeld : Dim dbs As Database, rst As Recordset Dim strSQL As String Set dbs = CurrentDb strSQL = "SELECT * FROM Groep "&_ "WHERE Praktijkopdracht = True" Set rst = dbs.OpenRecordset(strSQL) Een andere mogelijkheid is het uitvoeren van een SQL statement door middel van de DoCmd.RunSQL methode. Een voorbeeld: DoCmd.RunSQL "INSERT INTO Bestelling "&_ "VALUES (234, 24, "Inkoop", #20-2-1997#);"
122
In VBA kan een macro worden aangeroepen door de DoCmd.RunMacro <macro name> methode. Een voorbeeld: DoCmd.RunMacro "Print Overzicht" Binnen VBA wordt een VBA procedure (subroutine ) aangeroepen door: <subroutinenaam>(<parameter>,*) een functie door: = (<parameter>,*)
Voorbeeld: PrintOverzicht(1994, "inkopen") 'Aanroep procedure PrintOverzicht a = Fibonacci(5) 'Aanroep functie Fibonacci met parameter 5
6.6. De gegevensbanktaal van Access 6.6.1. Inleiding Access biedt een implementatie van alle kenmerken van een relationele gegevensbank (Date,1995) , inclusief bewaking van existentiële en referentiële integriteit en de toepassing van de taal SQL (Structured English Query Language). Een relationele gegevensbank kent twee deeltalen: de Data Definition Language voor het definiëren van de gegevensstructuur en de Data Manipulation Language voor het werken met de gegevens die in die gegevensstructuur zijn opgeslagen. De DDL (Data Definition Language) kent de volgende commando’s: CREATE TABLE, ALTER TABLE en DROP TABLE. De DML (Data Manipulation Language) van Access kent de volgende commando’s: SELECT, INSERT, UPDATE, DELETE, UNION, en CROSSTAB commando's; diverse functies die op de database of query als geheel werken (Avg, Count, Sum, Min, etc.). Daarnaast biedt Access de mogelijkheid om met Recordsets (ook wel Dynasets genoemd) te werken die zijn gecreëerd op basis van een query. In een recordset kan worden genavigeerd op basis van een recordpointer, en zijn de velden die behoren tot een individueel record benaderbaar. Bij één tabel kunnen vele recordsets worden gemaakt. Bij elk formulier (Form) hoort één recordset (de RecordSource eigenschap van het formulier verwijst naar de betreffende recordset). In de SQL voorbeelden hieronder wordt er van uitgegaan dat de verschillende statements in het SQL Design View venster worden ingetypt. In dat geval hoeft er geen _ (line continuation) te worden gebruikt en wordt het SQL statement met ; (puntkomma) afgesloten.
6.6.2. Data Definition Language Het maken van tabellen kan heel gemakkelijk grafisch gebeuren met behulp van de TABLE DESIGN VIEW die vanuit het DATABASE WINDOW te bereiken is . Het leggen van relaties tussen tabellen kan grafisch gebeuren met het menucommando Tools| Relationships dat in het DATABASE WINDOW beschikbaar is. Onder programmacontrole tabellen creëren gebeurt met CREATE TABLE commando in SQL. CREATE TABLE
de tabelnaam, bijvoorbeeld KLANT; een veldnaam, bijvoorbeeld Naam; het type van het veld bijvoorbeeld TEXT of INTEGER; <size> de lengte van het veld, bijvoorbeeld 30. Bij kan een constraint voor het betreffende veld worden ingevuld. Een bekende constraint is bijvoorbeeld dat een veld fungeert als PRIMARY KEY. Dit wordt aangegeven door de constraint: CONSTRAINT DeSleutelVanKlant PRIMARYKEY Een andere constraint kan zijn het zijn van een verwijzende sleutel, zoals bijvoorbeeld een leveranciersnr in een ordertabel dat verwijst naar een leveranciersnr in een leverancierstabel: CONSTRAINT VerwijzendeSleutelNaarLeverancier REFERENCES Leverancier Leveranciersnr Door het aangeven van verwijzende sleutel constraints worden relaties tussen tabellen gelegd. Ook andere constraints zijn mogelijk. Raadpleeg hiervoor de Access documentatie of Helpfunctie. Een <multifieldconstraint> kan bijvoorbeeld een PRIMARY KEY zijn die uit verschillende velden bestaat, bijvoorbeeld naam, adres en woonplaats: CONSTRAINT DeSleutelVanStudent (Naam, Adres, Woonplaats) PRIMARYKEY Tabellen kunnen op een vergelijkbare manier worden veranderd met het ALTER TABLE
…. commando. Tabellen kunnen worden verwijderd met het DROP
commando.
6.6.3. Data Manipulation Language Access ondersteunt een volledige versie van SQL. Hier worden de INSERT, UPDATE, SELECT en DELETE commando's behandeld. Daarnaast zijn er nog de SELECT INTO, INNER JOIN, LEFT JOIN , RIGHT JOIN, UNION en CROSSTAB commando's; hiervoor wordt naar de Access documentatie of Helpfile verwezen. Insert Met het INSERT statement kan een nieuw record aan een tabel worden toegevoegd. INSERT INTO
[({},+)] VALUES (,+); De lijst met velden (fields) is optioneel. Normaliter geeft men na VALUES een lijst met waarden gelijk aan het aantal velden in een record, en wel in de juiste volgorde. Let erop dat tekst tussen dubbele aanhalingstekens moet worden opgegeven. Een datum staat tussen hekjes (# tekens).Voorbeeld: INSERT INTO Bestelling VALUES (123, 28, "Inkoop", #1 Wouter 93#)
Update Met het UPDATE statement kunnen een aantal records tegelijkertijd via dezelfde formule worden veranderd.
124
UPDATE
SET WHERE ;
Voorbeeld: UPDATE Klant SET Kredietlimiet = Kredietlimiet* 1.10 WHERE Woonplaats = "Loppersum"; In de specificatie van de conditie zijn handige operatoren: LIKE *<substring>* geeft True indien de substring in een bepaald veld voorkomt; AND, OR en NOT geven logische combinatiemogelijkheden; verder werken =, <, >, <=, >-, en <> zoals gebruikelijk. Select Met het SELECT statement kunnen gegevens uit een tabel worden geselecteerd. Hieronder de eenvoudige variant. SELECT {},+ FROM
[WHERE ]; Voorbeeld: SELECT Model, Soort, Hoogte, Kleur, Inkoopprijs, Voorraad FROM Fietstype WHERE Verkoopprijs < 1000; In plaats van een lijst met velden kan men ook een sterretje * opgeven. Het sterretje * betekent dat men alle velden wil selecteren. Nu de iets ingewikkelder variant: SELECT [ALL| DISTINCT| DISTINCTROW] {*|{{[AS ]},+}}} FROM
[WHERE ];
Het gebruik van DISTINCT of DISTINCTROW wordt gebruikt om alleen die records te selecteren die niet gelijk zijn aan andere. M.a.w. als er een groep records is die (voor de geselecteerde velden) gelijk is, wordt er slechts één van in de selectie opgenomen. Dit is bijvoorbeeld handig bij het nagaan bij welke leveranciers men nu eigenlijk bestelt: SELECT DISTINCT Leveranciersnr FROM Bestelling; Het gebruik van AS is zinvol om de geselecteerde velden een naam te geven die afwijkt van de oorspronkelijke naam. Dit is in het bijzonder van belang als men een berekening op het geselecteerde veld heeft toegepast. Er zijn nog ingewikkelder vormen van het SELECT statement, onder andere met HAVING en GROUP BY. Zie hiervoor de Access documentatie of Helpfunctie.
Voorbeeld: SELECT LastName & Firstname AS Name, Salary FROM Employees; Delete Met het DELETE statement verwijdert men records uit een tabel die aan bepaalde voorwaarden voldoen. DELETE FROM
WHERE ;
125
Voorbeeld: DELETE FROM Bestelling WHERE Besteldatum < #1 Jan 1995#; 6.6.4. Berekeningen gekoppeld aan tabellen In het SELECT statement kan men ook functies opnemen die op de verzameling geselecteerde records werken. Op dit gebied kent Access de functies Avg, Count, Min, Max, Sum en de statistische functies StDev, StDevP, Var en VarP. Een voorbeeld: SELECT SUM(Voorraad) AS [Totale Voorraad] FROM Fietstype WHERE Verkoopprijs < 1000;
Let erop dat rond [Totale Voorraad] vierkante haken zijn geplaatst. Dit is verplicht bij velden waarvan de naam een spatie bevat. Het mag bij andere veldnamen ook.
6.6.5. Filters definiëren Op tabellen, queries en formulieren kan een filter worden toegepast. Het filter is een eigenschap (property) van deze objecten. Aan het filter moet een string worden toegewezen die een expressie bevat die ook in een WHERE expressie in SQL zou kunnen staan (zonder WHERE). Een voorbeeld: Me.Filter = "Verkoopprijs < 1000" Het filter kan aan en uit worden gezet met de FilterOn eigenschap: Me.FilterOn = True
6.6.6. Recordset-methoden Formulieren berusten meestal op een tabel of query (die in de RecordSource eigenschap is opgegeven) en maken van die tabel of query een recordset. Een kopie van deze recordset kan worden opgevraagd met de property Me.RecordsetClone. Een recordset maakt het mogelijk van record naar record te navigeren, de betreffende gegevens zichtbaar te maken en/of te veranderen. Met de OpenRecordset methode van een tabel kan (met behulp van een query) onder programmacontrole een recordset worden gemaakt. Voorbeeld: Dim dbs As Database, rst As Recordset Dim strSQL As String Set dbs = CurrentDb strSQL = "SELECT * FROM Bestelling" Set rst = dbs.OpenRecordset(strSQL) Heeft men eenmaal een recordset, dan is het zaak om de recordset-methoden te kennen die navigatie toelaten. De eenvoudigste verplaatsingsmethoden zijn MoveFirst, MoveLast, MoveNext en MovePrevious. Deze verplaatsen de aanwijzer (Bookmark) in de recordset naar resp. de eerste, laatste, volgende en vorige record. De aanwijzer van een recordset kan worden opgevraagd met de Bookmark eigenschap. Als men via de RecordsetClone eigenschap heeft gewerkt met de kopie van de recordset van een Form, is het vaak zinvol de aanwijzer in het Form weer gelijk te maken met de aanwijzer in de kopie-recordset. Voorbeeld: Dim rst As Recordset Set rst = Me.RecordsetClone
126
rst.MoveNext Me.Bookmark = rst.Bookmark Bij het verplaatsen van de aanwijzer (Bookmark) is net vaak nuttig te testen of men aan het einde van de recordset is gekomen. Dit gebeurt met de methode EOF die true wordt als het einde is bereikt. Voorbeeld: Do Until rstB.EOF rstB.MoveNext Loop
Andere verplaatsingsmethoden berusten op zoeken in de recordset. Dit gebeurt met de methoden FindFirst, FindLast, FindNext en FindPrevious. zoekmethode FindFirst FindLast FindNext FindPrevious
begint bij begin van recordset einde van recordset huidig record huidig record
zoekrichting naar einde naar begin naar einde naar begin
De syntax is: . De conditie is een string die een conditie bevat. Een voorbeeld: Me.RecordsetClone.FindFirst_ "[Leveranciersnr] = " & Me![cboLeverancier] Me.Bookmark = Me.RecordsetClone.Bookmark In de recordsetkopie (RecordsetClone) wordt, vanaf het begin, het eerste record gezocht waarin het Leveranciersnr gelijk is aan de inhoud van de combobox cboLeverancier. Daarna wordt de aanwijzer (Bookmark) van het formulier ververst. Met behulp van een index kan snel worden gezocht in een recordset die direct aan een tabel is gekoppeld. Deze tabel moet dan al wel een index hebben in de vorm van bijvoorbeeld een Primary Key. Voordat het zoeken begint moet de index van de recordset op deze index van de tabel worden gezet. Het zoeken gaat met de methode Seek. Syntax: .Seek , Hierbij is de een string die <, <=, =, >=, of > bevat. De is de waarde van de index waarnaar moet worden gezocht.
Voorbeeld: Dim rstBestelling as Recordset, dbs as Database Set dbs = CurrentDb Set rstBestelling = _ dbs.OpenRecordset("Bestelling",dbOpenTable) rstBestelling.Index = "PrimaryKey" rstBestelling.Seek "=", 45 rstBestelling.Edit rstBestelling!Datum = #11 Feb 1997# rstBestelling.Update rstBestelling.Close dbs.Close
127
Na het opzoeken van het record met Bestelnr 45 in de tabel Bestelling wordt het betreffende record bijgewerkt door de recordset voor editen te openen (er wordt dan een tijdelijke editbuffer aangemaakt), de datum te veranderen, de tabel te updaten vanuit de editbuffer. Vervolgens wordt eerst de recordset en daarna de tabel netjes gesloten. In dit voorbeeld zien we dat de INSERT, UPDATE en DELETE commando's ook via een recordset kunnen worden uitgevoerd. Dit gaat als volgt: (declaraties en openen recordset) Dim dbsA AS Database, rstA as RecordSet Set dbsA = CurrentDB Set rstA = dbsA.OpenRecordset("TabelB", dbsOpenTable) (update) rstA.Edit 'open een editbuffer rstA![veldC] = iets 'toekennen van iets aan veld in buffer rstA.Update 'wegschrijven buffer naar tabel (insert) rstA.AddNew 'voeg nieuw record toe rstA![veldC] = ietsnieuws 'toekennen waarde rstA.Update 'wegschrijven nieuw record naar tabel (delete) rstA.FindFirst "[veldC] = " & Me![cboRommel] 'opzoeken van te verwijderen record rstA.Delete 'verwijderen record rstA.MoveLast 'verzetten bookmark naar laatste record 'ter vermijding van foutmeldingen (netjes afsluiten) rstA.Close dbsA.Close
6.6.7. Transacties Een geheel van bij elkaar behorende handelingen groeperen we in een transactie (Deze database-transactie is heel iets anders dan de transactie uit de economische en bedrijfskundige theorie). Als deze reeks handelingen om de een of andere reden wordt afgebroken of moet worden afgebroken wordt de toestand van de database hersteld zoals zij voor het begin van de transactie was. Men begint een transactie met de BeginTrans methode, men beëindigt de transactie met de CommitTrans methode. Wil men een transactie afbreken dan kan dit met de Rollback methode. Deze methoden horen bij een Workspace object, dat is een object dat verschillende database objecten kan omvatten. Het huidige Workspace object kan worden verkregen met de DBEngine.Workspaces(0) methode. Voorbeeld Dim wspA dbsA rstA Set wspA
As Workspace, _ As Database, _ As Recordset = DBEngine.Workspaces(0)
128
Set dbsA = wspA.Databases(0) Set rstA = dbsA.Openrecordset("Betaling",dbOpenTable) wspA.BeginTrans rstA.AddNew rstA![Datum] = txtDatum rstA![Relatie] = cboRelatie rstA![Debet] = cboDebet rstA![Credit] = cboCredit rstA![Bedrag] = txtBedrag rstA![BTW] = cboBTW rstA![Omschrijving] = cboOmschrijving rstA.Update If rstA!Bedrag = 0 Then wspA.Rollback 'Transactie wordt bij _ bedrag 0 teruggedraaid Else wspA.CommitTrans End If rstA.Close dbsA.Close
6.7. Invoer en uitvoer 6.7.1. Invoermaskers en validatieregels Bij het inlezen van gegevens in een tekstveld (Text Box) of Combo Box (of andere Control) op een formulier kunnen de in te voeren gegevens worden gecontroleerd op grond van een invoermasker (Input Mask). Het invoermasker kan worden opgegeven onder de InputMask eigenschap van de Control. In het invoermasker kunnen de volgende symbolen voorkomen: 0 cijfer van 0 tot 9 9 cijfer of spatie # cijfer of spatie (invoer niet verplicht, plus en min tekens toegestaan) L letter (verplichte invoer) ? letter (invoer niet verplicht) A letter of cijfer (verplichte invoer) a letter of cijfer (invoer niet verplicht) & elk symbool of een spatie (invoer verplicht) C elk symbool of een spatie (invoer niet verplicht) Ook kunnen functies worden opgegeven < alle letters worden hierna naar kleine letters geconverteerd > alle letters worden hierna naar hoofdletters geconverteerd ! het veld wordt van rechts naar links ingevuld \ het hierna volgende symbool wordt letterlijk afgedrukt Een voorbeeld is het invoermasker voor de Nederlandse postcode(na de \ streep staat een spatie die automatisch wordt afgebeeld): Me.Postcode.InputMask = "0000\ >LL"
129
Als controle op de invoer kan ook een Validation Rule met bijbehorende Validation Text worden opgegeven. Bijvoorbeeld voor het tekstveld Leeftijd: Me.Leeftijd.ValidationRule = ">= 0 And <= 125" Me.Leeftijd.ValidationText = _ "De leeftijd moet tussen de 0 en 125 jaar liggen."
6.7.2. Menustructuur Een menustructuur kan worden gemaakt met de Menu Builder. Deze wordt opgeroepen door in het Database Window de menukeuze Tools| Add-Ins| Menu Builder te maken. 6.7.3. Uitvoer naar scherm en printer Debug.Print geeft uitvoer naar Debug Window (openen met Ctrl-G) van één variabele tegelijk. Voor arrays en collections moet een iteratie worden geprogrammeerd. Ook kan het vraagteken ? commando in het Debug Window worden gebruikt. Een formulier kan worden geopend met de OpenForm methode van het DoCmd object. DoCmd.OpenForm Er kunnen nog meer parameters worden meegegeven. Raadpleeg hiervoor de Access documentatie of Helpfunctie. Gegevens kunnen vrij eenvoudig in een tekstveld (Text Box) van een formulier (Form) worden geschreven. Stel er is een formulier genaamd MijnFormulier, waarop een tekstveld genaamd Tekst staat. Als men nu de inhoud van de variabele Getal op het scherm wil afbeelden kan dit met: Form_MijnFormulier.Tekst = Getal of Form_MijnFormulier!Tekst = Getal of Forms!MijnFormulier.Tekst = Getal of Forms!MijnFormulier!Tekst = Getal Een rapport kan worden geprint met de OpenReport methode van het DoCmd object. DoCmd.OpenReport [, ]_ [, ] [, ] Het is de naam van een rapport (Report). Bij de parameter kan men invullen acPreview. Men krijgt dan het af te drukken rapport eerst nog te zien voordat het wordt afgedrukt. De is de naam van een query die de records die moeten worden afgedrukt selecteert. De selecteert ook records, maar hier moet men niet de naam van een query invoeren, maar het WHERE gedeelte van de query zelf (zonder het woord WHERE), zoals dat ook gaat bij het toepassen van filters. Denk eraan om eerst de juiste printer te selecteren met het NOVELL commando CAPTURE <printername>. Dit DOS commando kan binnen Access worden gegeven met behulp van de functie Shell("<pathname> [<arguments>]", 0). De 0 slaat erop dat alles in een hidden window gebeurt; 1 is een normale window.
130
6.8. Literatuur over programmeren in Access Bär, Jürgen, en Irene Bauder. Het programmeren met Access 97 boek. Brussel: EASY COMPUTING, 1997. Hierin staan veel praktische programeervoorbeelden. Barker, F. Scott. Programmeren in Access 7 voor Windows 95. Schoonhoven: Academic Service, 1996. Boertjens, Koos. Basiscursus Access 97. Schoonhoven: Academic Service, 1997. f.29,50. Zie ook de website van Koos Boertjens: http://www.boertjens.nl/. Brien, Timothy M.O., Steven J.Pogge, and Geoffrey E.White. Microsoft Access 97 Developers Handbook. Redmond, Washington: Microsoft Press, 1997. Veel aandacht vor het programmeren van Foms en Controls, uitleg van het Access object model, lijkt erg op de Help functie van Access maar is meer toegankelijk. Date, C.J. An Introduction to Database Systems: Sixth Edition. Reading, MA: Addison-Wesley, 1995. Zie voor de SQL taal blz. 219 en volgende. Getz, Ken and Mike Gilbert. Programmeren met VBA. Soest: SYBEX, 1988. In dit boek veel aandacht voor het programmeren van abstracte datastructuren in Access. Korpershoek, Ies en Ben Groenendijk. Databases en Access: Van ontwerp tot professioneel gebruik. Schoonhoven: Academic Service, 1998. Dit boek gaat een stapje verder dan het boek van Boertjens en bevat o.a. het normaliseren. Novalis, Susann. Automating Access with Macros. Alamedo, CA: SYBEX, 1996. Lomax, Paul. VB & VBA in a nutshell. Beijing: O Reilly, 1988. Een boek banuit het gezichtspunt van professionele programmeurs, dus met veel aandacht voor datatypen, variabelen, programmastructuren en modules.
131
Bijlage 1. Case Fietsenhandel JEEKAA Omschrijving Fietsenhandel JEEKAA, opgericht door Jeen Kaats, bestaat al 22 jaar. De laatste jaren is het bedrijf door toenemende vraag gestaag gegroeid. Het is een typische eenmanszaak. Er werken naast de eigenaar nog twee verkopers en drie onderhoudsmonteurs. Voor de koopavond en de zaterdag is er nog een parttime verkoper. De laatste tijd heeft de eigenaar het gevoel dat hij het overzicht wat verliest. Om zijn voorraadadministratie doorzichtelijker te maken verzoekt de eigenaar U een oplossing te zoeken. Hieronder staan enkele details van de gang van zaken in het bedrijf. De activiteiten die betrekking hebben op de voorraad vallen uiteen in drie categorieën. Het bestellen van de fietsen, het arriveren van bestelde fietsen en het verkopen van fietsen. Deze drie processen worden nu handmatig uitgevoerd. Het bestellen van fietsen gebeurt met behulp van bestelformulieren (zie bijlage 1). Het bestelmoment is van een aantal factoren afhankelijk. Over het algemeen worden de bestelformulieren ingevuld op een moment waarop de eigenaar toevallig even wat tijd heeft. De bestellingen gebeuren grotendeels op het gevoel. Er bestaat geen duidelijk inzicht in de aanwezige voorraad. Soms vraagt een klant om een specifieke fiets die niet in voorraad is. Deze fiets wordt dan op dat moment genoteerd om besteld te worden. Kopieën van de bestelformulieren worden bewaard in een ordner. Als bestelde fietsen binnenkomen, wordt hiervan de vrachtbon bewaard in een ordner. De factuur, die bij aflevering wordt meegegeven of later wordt opgestuurd, wordt ook in een ordner opgeborgen. Bij binnenkomst van een bestelde fiets moet in principe hiervan een aantekening op het bijbehorende bestelformulier komen. In de praktijk gebeurt dit echter nooit. Het terugzoeken van de juiste bestelformulier is tijdrovend, en bovendien vinden de werknemers het zinloos. Na het binnenkomen van de fiets wordt deze door een technicus uitgepakt en gecontroleerd. Vervolgens worden, indien de klant dat heeft besteld, bepaalde speciale onderdelen zoals andere zadels, bagagedragers, drinkflessen, fietstassen, sloten gemonteerd. Bij verkoop van een fiets worden de gegevens van de fiets en de klantgegevens handmatig ingevuld op een voorgedrukt formulier. Dit formulier dient als verkoopfactuur. Een doorslag wordt gebruikt voor de administratie van de winkel. Een tweede doorslag van dit formulier wordt eventueel voor de verzekering gebruikt. Deze verzekering betreft voor brommers de WA-verzekering en voor fietsen en brommers een diefstalverzekering. Nadat een fiets is verkocht wordt de fiets door een technicus voor aflevering klaar gemaakt door onder meer schoonmaken, in de was zetten, oliën en banden oppompen. Het gebeurt steeds vaker dat er gegevens moeten worden opgezocht. Het komt bijvoorbeeld voor dat een bestelling geannuleerd wordt. Dit moet op het bijbehorende bestelformulier worden vermeld. Het terugvinden van dit formulier is lastig. Er is geen overzicht over de aanwezige voorraad. Het komt regelmatig voor dat er om een specifieke fiets wordt gevraagd. De voorraad is echter gegroeid tot zo'n 400 fietsen, waardoor het moeilijk is om een specifieke fiets terug te vinden. Hier komt nog bij dat de eigenaar nu niet precies weet wat hij moet bestellen. Dit gebeurt nu min of meer intuïtief. Wanneer er vragen binnenkomen over een verkochte fiets zijn de gegevens van deze fiets moeilijk terug te vinden. Dit gebeurt
132
vooral in het geval van diefstal: een klant wil het framenummer van zijn fiets weten, of de politie wil van een gevonden fiets de eigenaar achterhalen.
Bestelformulier
BESTELFORMULIER Volgnummer
JEEKAA Tweewielers Kooistraat 12 3354 FF Schiermonnikoog Kamer van Koophandel Groningen 3251 Datum
Aan: Leveranciersnr: Naam Adres Postcode Woonplaats Hierbij plaats ik de volgende bestelling: Type Soort Hoogte
Hoogachtend, Jeen Kaats, directeur
133
Kleur
Aantal
Factuur
FACTUUR Factuurnr
Batalle Fietsenfabriek Groeneweg 27 8233 AF Beesten Datum
Klantnr Naam Adres Postcode Woonplaats Type
441 JEEKAA Kooistraat 12 NL-3354 FF Schiermonnikoog Soort
Hoogte
Kleur
Framenr
Prijs
Totaal BTW 17,5% Factuurbedrag Betaling binnen 14 dagen. Kamer van Koophandel Peerstekel nr.3456
134
Korting
Bijlage 2. Het gebruik van System Architect Het gebruik van System Architect is grotendeels duidelijk door de manier waarop het gebruikersinterface is vormgegeven. Er is een redelijke Help functie. Enkele aandachtspunten worden hieronder gegeven. We kunnen diagrammen tekenen met System Architect, en vervolgens het diagram met kopiëren (Edit| Select All; Edit| Copy beide in System Architect) en plakken (Edit| Paste in MS Word) vanuit System Architect naar een tekstverwerker (zoals MS Word) overhalen. Het diagram kan in MS Word eventueel verder worden geëdit. Met name stippellijnen moeten soms opnieuw worden getekend in MS Word omdat ze niet goed worden afgedrukt. Door een rechtermuisklik op een symbool krijgen we een pop-up menu te zien dat gaat over de eigenschappen van dat symbool. Erg handig is bijvoorbeeld de eigenschap Name, Number, Properties waarmee de naam van het symbool kan worden veranderd. Wil men de naam veranderen van een symbool waarvan men al attributen en methoden heeft gedefinieerd, dan kan men deze verandering het beste doen in het scherm voor de Definition van een symbool; bij de dialoog die volgt na het veranderen van de naam kan men vervolgens kiezen voor Global Change, waarbij allle reeds gedefinieerde onderdelen van een symbool worden meegenomen. De eigenschap Addresses kan worden gebruikt om aan te geven of een symbool betrekking heeft op een Business Objective, Business Process, Critical Success Factor, Geographic Location, etc. Dit is vooral van belang bij hiërarchisch opgebouwde decompositiediagrammen (te tekenen met module Auto Decomposition) die voor allerlei doeleinden (bijvoorbeeld organigram, doelstellingsboom) kunnen worden gebruikt. De eigenschap Comment maakt het mogelijk uitleg aan een symbool toe te voegen. Het toekennen van tweemaal dezelfde naam mag niet in System Architect. Wil men een symbool met een bepaalde naam toch opnemen in een diagram, dan kan dit alsnog gebeuren door het kopiëren en plakken van het originele symbool (meestal vanuit een ander diagram). Het gekopieerde symbool kan eventueel van aard worden veranderd door | Transform Symbol. Pijlen zitten soms niet goed vast aan een symbool. Ze worden dan grijs. Pijlen kunnen goed worden vastgemaakt door het uiteinde ervan over het symbool te trekken. Er verschijnt dan een kruisje. Soms geeft het automatisch route kiezen van pijlen een verward beeld. Het automatisch route kiezen van pijlen kan worden uitgeschakeld door de optie Set| Preferences| Immediate Auto-Routing uit te zetten. Als dit automatisch route kiezen is uitgeschakeld kan door middel van Edit | Route Now (of de flits-knop rechts bovenaan) het automatisch route kiezen eenmalig worden uitgevoerd. Het traject van de verbindingspijlen kan na uitschakeling van automatisch route kiezen worden veranderd door de pijl te selecteren en vervolgens de knikpunten te verslepen. Men kan door een op de pijl en vervolgens de optie Insert Line Segment een knikpunt toevoegen. Met een op de pijl en Make Orthogonal kan men de pijl netjes orthogonaal maken. Bij het gebruik van het Rectangle symbool, bijvoorbeeld om een systeemgrens aan te geven, gaat System Architect zich vaak narrig gedragen. Verbindingslijnen worden bij het automatisch route kiezen dan soms heel vreemd getekend. Het is soms beter deze optie niet te gebruiken en de rechthoek/systeemgrens in MS Word bij te tekenen (bijvoorbeeld als men een grijze systeemgrens wil tekenen zoals in deze syllabus is gebeurd). Een andere mogelijkheid is het automatisch route kiezen van verbindingspijlen uit te schakelen (zie hierboven).
135
Een overzicht van de al gemaakte diagrammen wordt verkregen door Diagram| Open| Search. Het overzicht kan als een aparte window (genaamd Diagrams) open blijven, maar moet na het wissen van een diagram door middel van het Search commando weer worden ververst. Het gebruik van de onderwijsversie van System Architect houdt beperkingen in. Zo kunnen er maximaal 2 projecten, 10 diagrammen en 300 symbolen worden gemaakt. Het is aan te raden zodra deze beperkingen zich laten gelden de volgende stappen te zetten: een back-up van de twee directories/ folders Project1 en Project2 maken; alle gemaakte figuren naar MS-Word kopiëren om ze daar verder te kunnen gebruiken; de figuren die niet direct meer nodig zijn wissen. Ook kan een geheel nieuwe directory met een tweede versie van System Architect en lege subdirectories Project1 en Project2 uitkomst bieden. Bij het maken van deze syllabus zijn in totaal vier van deze System Architect directories aangemaakt. De volgende opties kan men beter niet gebruiken: Run Report; OMT Data Flow| OMT Rules Check; OMT Data Flow| Expression Check; OMT State| OMT Rules Check; Definition| Add; Definition| Modify; Definition| Create Undefined List. Gebruikt men de OMT Rules Check of Expression Check toch, dan wordt het diagram door FOUT symbolen ontsierd. Deze kan men weer weghalen door de commando's OMT Data Flow| Clear Errors of OMT State| Clear Errors.
