OrganisatieModellering

OrganisatieModellering Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

Master’s Thesis

Afstudeerscriptie Naam: Ing. A.C. van Bers Studentnr: 0229342 Begeleider: Dr.Ir. Gert Veldhuijzen van Zanten Referent: Prof.Dr. Erik Proper Datum: 18-06-2004

Master’s Thesis

Voorwoord Deze scriptie is het resultaat van mijn afstudeeronderzoek dat ik uitgevoerd heb op de Katholieke Universiteit Nijmegen en de Hogeschool van Arnhem & Nijmegen. Het onderzoek is ontstaan uit interesse voor het vakgebied, praktijkervaringen bij het ontwikkelen van een groot informatiesysteem en via onderzoeken van A.P. Barros en H.A. Proper [Pro02] waarin dit gebied als verder onderzoeksgebied is aangeduid. Met dit onderzoek rond ik mijn Informatiekunde studie te Nijmegen af. Ondanks dat het een individueel onderzoek is geweest, had ik het niet kunnen doen zonder de hulp en ondersteuning van een aantal personen. Ten eerste wil ik Gert Veldhuijzen van Zanten (Katholieke Universiteit Nijmegen) bedanken voor zijn intensieve begeleiding. Dankzij zijn begeleiding ben ik weer op het goede spoor gezet nadat ik verdronk in ideeën. Verder wil ik Deny Smeets (Hogeschool van Arnhem & Nijmegen) bedanken voor het geven van zijn nuttige inzichten en het aangeven van contacten op het gebied van modellering. Ook wil ik graag Arie Schinkel bedanken voor het presenteren van zijn methode en het tonen van interesse binnen het probleemgebied. In het bijzonder wil ik mijn ouders, vrienden en vriendin bedanken voor hun voortdurende steun en geduld tijdens mijn studieperiode. Arnoud van Bers

Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

2/61

Master’s Thesis

Inhoudsopgave Voorwoord....................................................................................................................................... 2 Inhoudsopgave ................................................................................................................................ 3 1 Inleiding .................................................................................................................................. 4 1.1 Structuur .......................................................................................................................... 4 2 Onderzoek ............................................................................................................................... 6 2.1 Probleemgebied................................................................................................................. 6 2.2 Doelstelling & Formulering .................................................................................................. 7 2.3 Onderzoeksvragen ............................................................................................................. 8 2.4 Afbakening ....................................................................................................................... 8 2.4.1 Schermen ................................................................................................................. 9 2.5 Methodiek....................................................................................................................... 10 2.6 Toepassingsgebied........................................................................................................... 10 3 Modellering: een overzicht ....................................................................................................... 12 3.1 Informatiemodellering ...................................................................................................... 12 3.2 Procesmodellering ........................................................................................................... 12 3.2.1 Methodiek ............................................................................................................... 12 3.2.2 Procesmodellen........................................................................................................ 12 3.3 Organisatiemodellering..................................................................................................... 12 3.3.1 Testbed Studio......................................................................................................... 12 3.3.2 Actor Classificatie ..................................................................................................... 12 4 Schermgeneratie op basis van het logische datamodel................................................................. 12 4.1 User-Interface Definitie .................................................................................................... 12 4.2 Beschouwing van het logisch model met als doel schermgeneratie......................................... 12 5 Conceptuele Specificatie van het Onderzoeksgebied .................................................................... 12 5.1 Niveaus van Processen ..................................................................................................... 12 5.2 Informatiebehoefte voor schermgeneratie........................................................................... 12 5.2.1 Informatieselectie .................................................................................................... 12 5.2.2 Eigenaren / verantwoordelijken van informatie ............................................................ 12 5.2.3 Hiërarchische Rollen ................................................................................................. 12 5.3 Koppelen van werkzaamheden aan informatie ..................................................................... 12 5.3.1 Soorten handelingen................................................................................................. 12 5.3.2 Constraints op bewerkingen....................................................................................... 12 5.3.3 Toegang.................................................................................................................. 12 5.4 Navigatie ........................................................................................................................ 12 5.5 Voorgestelde Analysemethode........................................................................................... 12 6 Evolutie van het FCO-IM metamodel.......................................................................................... 12 6.1 Huidige Repository........................................................................................................... 12 6.2 Uitbreiding Repository ...................................................................................................... 12 7 Schermgeneratie op basis van het organisatiemodel.................................................................... 12 7.1 Naar het logisch model..................................................................................................... 12 7.2 Generatie van de Grafische User-Interface.......................................................................... 12 7.2.1 Lay-out Problematiek................................................................................................ 12 7.3 Algoritmiek ..................................................................................................................... 12 7.4 Terugkoppeling naar de gebruiker...................................................................................... 12 7.5 Mapping Procesniveaus .................................................................................................... 12 8 Procesindeling ........................................................................................................................ 12 8.1 Procesuitbreiding in het metamodel ................................................................................... 12 9 Bedrijfsindeling op basis van het organisatiemodel ...................................................................... 12 10 Concluderend...................................................................................................................... 12 10.1 Suggesties voor verder onderzoek ..................................................................................... 12 11 Literatuurlijst ...................................................................................................................... 12 11.1 Personen en Bedrijven...................................................................................................... 12 Lijst van Afbeeldingen ..................................................................................................................... 12 Lijst van Tabellen ........................................................................................................................... 12 Bijlage A FCO-IM Grafische Symbolen ..........................................................................................XII Bijlage B Data Flow Diagram Grafische Symbolen..........................................................................XII Bijlage C Testbed Studio Grafische Symbolen ...............................................................................XII Bijlage D FCO-IM Repository .......................................................................................................XII Bijlage E Triggergeneratie op SQL Server 2000 .............................................................................XII


3/61

Master’s Thesis

1 Inleiding In deze scriptie zal het onderzoek dat ik uitgevoerd heb ten behoeve van het behalen van de titel Master of Science besproken worden. Het onderzoek gaat in op problematiek waar systeemontwikkelaars vandaag de dag mee kampen. Tegenwoordig worden informatiesystemen door middel van analysetrajecten vanuit verschillende perspectieven bekeken. Dit wordt gedaan om te zorgen dat het systeem goed in de organisatie past en dat het voldoet aan de eisen en wensen van de verschillende stakeholders. Een probleem hierbij is dat deze perspectieven moeilijk aan elkaar te relateren of te koppelen zijn, waardoor de effectiviteit van het analysetraject vaak tegenvalt. Het wordt steeds moeilijker een informatiesysteem te ontwikkelen dat aansluit bij de wensen van de gebruikers en de opdrachtgever. Informatiesystemen worden steeds omvangrijker omdat ze steeds grotere delen van de organisatie automatiseren. Ze hebben dus rekening te houden met een grotere verscheidenheid aan gebruikers, die ieder hun eigen eisen aan het systeem stellen. De opdrachtgever stuurt vaak aan op een zo kort mogelijke realisatietijd, omdat een groot deel van de organisatie óf afhankelijk is van het systeem óf vanuit concurrentiepositie zo snel mogelijk tot invoer over wil gaan. De belangen van deze stakeholders zijn vaak moeilijk tegelijkertijd te behartigen: om het systeem eerder af te krijgen wordt er vaak bekort op functionaliteit en kwaliteit. In dit onderzoek wordt getracht een oplossing te vinden om, zonder dat de belangen van de gebruikers te kort worden gedaan, de realisatietijd van het systeem te verminderen. Een manier om dit te doen is het automatiseren van een deel van het ontwikkelwerk. De constructiefase in het ontwikkeltraject komt hier het meest voor in aanmerking, omdat na de analysefase precies vaststaat wat het systeem moet doen en welke grenzen aangehouden moeten worden. Wanneer het systeem automatisch gemaakt kan worden vanuit de opgestelde specificaties uit de analysefase, wordt dit genereren genoemd. Het is nodig om de basis van generatie formeel vast te leggen, zodat een computer hiermee overweg kan. Door hierbij rekening te houden met het perspectief van de gebruikers kan generatie ook voor deze groep voordelen bieden.

1.1 Structuur De scriptie is als volgt opgebouwd: ten eerste zal de opzet van het onderzoek uitgediept worden in hoofdstuk 2. Hierin komen het probleemgebied, de onderzoeksdoelstelling, de onderzoeksvragen en de onderzoeksafbakening aan bod, alsmede de toegepaste onderzoeksmethodiek. Ook wordt er een situatie beschreven waaraan oplossingen gevalideerd kunnen worden. In hoofdstuk 3 wordt ingegaan op de analysetechnieken die op dit moment ‘state of the art’ zijn. Hierin zullen bestaande technieken bekeken worden op hun bruikbaarheid binnen het onderzoeksgebied. In hoofdstuk 4 wordt ingegaan op een bestaande methode. Enkele denkwijzen hiervan kunnen meegenomen worden in het onderzoek. In hoofdstuk 5 zal er beschouwd worden welke informatie er benodigd is om het onderzoeksdoel te behalen en de onderzoeksvragen te beantwoorden. Hierbij worden deels concepten uit de vorige hoofdstukken overgenomen, maar worden tevens nieuwe denkwijzen uitgewerkt.


4/61

Master’s Thesis

In hoofdstuk 6 wordt het formele model aangekaart, waar de resultaten uit hoofdstuk 5 een plaats in vinden. Hoofdstuk 7 bespreekt het generatieprincipe op basis van het vastgelegde formele model, met de hierbij tegengekomen problemen. In hoofdstuk 8 wordt het formele model verder uitgebreid, waarna in hoofdstuk 9 wordt beschreven hoe organisaties verder ondersteund kunnen worden met behulp van de vastgelegde gegevens in het formele model. Uiteindelijk zullen de bevonden resultaten samengevat worden en zal er een conclusie gevormd worden over de methode. Hierbij zal een verder onderzoeksgebied voorgesteld worden in hoofdstuk 10.


5/61

Master’s Thesis

2 Onderzoek In dit hoofdstuk zal het uitgevoerde onderzoek beschreven worden. Allereerst wordt in paragraaf 2.1 een algemeen probleem geschetst. In paragraaf 2.2 wordt een doelstelling geformuleerd om een bijdrage te leveren aan het oplossen van dit probleem. Hier zal ook een duidelijke omschrijving gegeven worden van het onderzoek, waarna in 2.3 de onderzoeksvragen verduidelijkt worden, en in 2.4 worden deze afgebakend. In de daarop volgende paragraaf 2.5 wordt de gevolgde methodiek beschreven. Tenslotte wordt in 2.6 het onderzoek in een toepassingsgebied geplaatst, die dient om het onderzoek in de praktijk te toetsen.

2.1 Probleemgebied Ten tijde van de eerste computer dacht men dat computers vooral gebruikt zouden worden voor het uitrekenen van ballistische banen en andere militaire taken. In de jaren ‘60 dacht men dat computers vooral ingezet zouden worden voor bedrijfsadministratieve taken. In de jaren ‘80 kwamen hier vooral PC toepassingen bij, ter ondersteuning van de persoonlijke productiviteit. Vandaag zien we dat de computer vooral een communicatiemiddel is geworden, opgenomen in een netwerk, met standaard toepassingen als e-mail, agenda en Web browser. De PC als communicatiemiddel geeft ons de mogelijkheid om groepen beter te laten samenwerken door middel van digitale informatie die altijd en overal beschikbaar kan zijn. Zo is de PC onmisbaar geworden bij het efficiënt uitvoeren van onze werkzaamheden. In deze onmisbaarheid schuilt een gevaar waar we ons in de toekomst zeker bewust van moeten zijn, namelijk dat door verdere digitalisering van de maatschappij informatiestress en informatiemoeheid steeds grotere vormen aannemen. Deze vormen van stress ontstaan door het onvermogen om alle informatie te verwerken, of door de verzameldrang vanwege de angst informatie te missen. Managers hebben tegenwoordig 1400 maal meer informatie dan in 1980. Iedere dag komen er 1,5 miljoen internetpagina’s bij. Een internationaal onderzoek van Reuters [Wad96] waarin de informatiestromen bij managers in kaart gebracht zijn, geeft aan dat tweederde van hen enorme hoeveelheden informatie nodig denkt te hebben om hun werk goed uit te kunnen voeren, bang dat ze zijn belangrijke informatie over het hoofd te zien. Een andere bevinding uit het onderzoek is dat de beschikbare informatie niet ten volle wordt benut, omdat deze óf niet op de juiste wijze wordt aangeboden óf dat logische verbanden met de werkzaamheden niet getrokken worden. De verwachting is dat de komende jaren het informatieaanbod alsmaar blijft toenemen, waardoor de kans bestaat dat mensen deze stroom niet meer aankunnen. Een onderzoek dichter bij huis ondersteunt dit beeld: Onder de Vlamingen blijkt dat 1 op de 3 lijdt aan informatiestress of stress ten gevolge van het niet kunnen verwerken van data. “Bepaalde bevolkingsgroepen zullen afhaken in de samenleving, omdat ze gewoonweg niet in staat zijn om de steeds toenemende stroom informatie die via een steeds groter aantal kanalen op ons afkomt, te verwerken” [Deg01]. Volgens Degroof [Deg01] is dit alleen het probleem van de samenleving. Naar mijn mening is dit probleem niet alleen meer toe te schrijven aan de samenleving, maar is het ook zeker het punt waar analysetrajecten van informatiesystemen de mist ingaan! De systemen worden weinig afgestemd op de informatiewensen van gebruikers, maar meer andersom. Ze bieden nauwelijks ondersteuning voor de taken die de gebruikers uitvoeren, terwijl dit juist op het vlak van informatiesysteemontwikkeling als principe ingevoerd zou moeten worden om de gebruiker gericht met informatie te bedienen. Rijsenbrij deelt deze opvatting in [Rij02] als hij schrijft dat de menselijke maat in IT systemen is verdwenen en vanaf architectuurniveau aangebracht dient te worden.


6/61

Master’s Thesis

De verkenningscommissie Informatica [VI96] heeft een definitie gegeven van informatiesystemen: “Informatiesystemen realiseren de informatievoorziening van organisaties, individuen en apparaten door middel van generatie, opslag, interpretatie, transformatie, transport en presentatie van gegevens, in de verschijningsvormen tekst, beeld of geluid”. Ook deze definitie mist het aspect gebruiksvriendelijkheid van het systeem. De informatiebehoeften kunnen wel gerealiseerd zijn, maar als niemand er mee kán of wíl werken schiet het zijn doel voorbij. Als oplossing voor dit probleem is een extra perspectief op informatiesystemen sterk in opkomst. Dit perspectief is het beschouwen van bedrijfsprocessen binnen de organisatie. Bedrijfsprocessen vormen een logisch geheel van taken, die uiteindelijk leiden tot een meetbaar resultaat voor een stakeholder [Sha02]. Ze beschrijven dus de taken die in de organisatie uitgevoerd worden en in welke volgorde dit gedaan wordt. Het organiseren in processen lijkt uit evolutie bepaald. Er wordt naar gestreefd er gezamenlijk beter op te worden als samenleving. We werken om te leven, of eigenlijk omdat we producten nodig hebben om ons leven te onderhouden (eten, kleding, woning). We produceren deze dingen niet allemaal zelf, omdat dit ontzettend inefficiënt zou zijn. Het zou tegenwoordig zelfs onmogelijk zijn om alle producten die we gebruiken zelf te maken, omdat we dan zoveel kennis en kunde nodig hebben, dat we alleen daaraan al ons hele leven kunnen besteden. Dit is dan ook de reden dat we ons organiseren in gespecialiseerde groepen waarin we een beperkt aantal producten produceren; efficiënt en met behulp van informatietechnologie. Een probleem hierbij is dat mensen hun taak binnen het geheel niet meer overzien, wat een negatief effect heeft op de productiviteit [AaHee00]. Het beschrijven van bedrijfsprocessen en het aanpassen van systemen hierop zorgt ervoor dat gebruikers gericht informatie kunnen opvragen naargelang hun taken binnen de organisatie. Het biedt dan namelijk de mogelijkheid om een cluster van gegevens te koppelen aan een bepaalde taak in de organisatie. De gebruiker krijgt slechts de informatie die hij nodig heeft bij deze taak: het informatieaanbod wordt verkleind en toegespitst. Dit helpt bij het motiveren en verhoogt de productiviteit van de individuele medewerker.

2.2 Doelstelling & Formulering Denken in processen is modern en wordt gebruikt om ICT verder te integreren in de organisatie. Helaas is de analyse van processen vaak onafhankelijk uitgevoerd van de andere analyses op het systeem. Zonder een sterke cohesie tussen de verschillende views op het te bouwen systeem is er voor de systeemontwikkelaar onduidelijkheid en interpretatieruimte, wat het systeem niet ten goede komt. Wanneer procesdenken wordt geïntegreerd met de andere views in de analysefase, wordt het mogelijk om per proces of taak aan te geven welke informatie daarmee gemoeid gaat. Hierdoor kan het systeem beter aansluiten op de werkzaamheden die de eindgebruiker uitvoert. Hoewel procesdenken steeds meer zijn plaats aan het vinden is in ontwikkeltrajecten van systemen, zijn deze trajecten nog steeds voornamelijk datageoriënteerd. Met behulp van informatiemodellering worden requirements vastgelegd over de gegevens die in de organisatie behandeld worden. Bij de implementatie wordt er datageoriënteerd gewerkt, wat vaak inhoudt dat de systeemarchitectuur leidend is en de gebruikers op de tweede plaats komen. Gebruikers zullen zich aan moet passen aan de wijze waarop het systeem is gebouwd: er is immers geen rekening gehouden met hun werkwijzen, alleen met de gegevensstructuur. Deze structuur is geoptimaliseerd voor het hebben van zo weinig mogelijk redundantie, en daarom meestal ingewikkeld van aard. Dit zorgt vaak voor irritatie bij de gebruikers, omdat de leercurve vaak stijl is en aan veel informatiewensen wordt niet voldaan.


7/61

Master’s Thesis

Door middel van deze scriptie wil ik een aanzet geven om procesdenken te integreren in de analysefase van het informatiesysteem, waardoor samenwerking tussen mens en systeem beter ontwikkeld wordt. Door een sterke cohesie tussen de gebieden gegevens en processen te bewerkstelligen zou het ook mogelijk moeten zijn de constructiefase van het informatiesysteem te automatiseren. Dit is mogelijk als, op basis van formeel vastgestelde patterns, schermen te genereren zijn. De gegevens die invulling geven aan de generatie komen rechtstreeks voort uit de analysefase. Dit kan enkele voordelen bieden zoals kortere ontwikkeltijd, betere afstemming op gebruikerswensen en uniformiteit in de manier van werken. Om deze voordelen te behalen zal een onderzoek uitgevoerd worden. Het onderzoek uit deze scriptie is als volgt geformuleerd: “Onderzoek of er overeenkomsten zijn tussen de informatieanalyse- en procesanalyseslagen en of deze samen gebruikt kunnen worden voor een beter op de bedrijfsprocessen afgestemde schermgeneratie”. Wanneer dit leidt tot een positief resultaat zal gekeken worden hoe de generatie dan gedaan kan worden. Het gewenste doel is te komen tot aanbevelingen naar een methodiek om automatisch schermen te genereren die toegesneden zijn op de taken van de gebruikers van het systeem.

2.3 Onderzoeksvragen Zoals aangegeven in de probleemstelling verdrinken veel mensen in de informatie die via diverse soorten media aangeboden wordt. Omdat ze door de bomen het bos niet meer zien, wordt hun werk minder efficiënt. Een goed gebruik van informatietechnologie zou een oplossing kunnen bieden voor dit probleem. De hoofdvraag hierbij is “hoe er bewerkstelligd kan worden dat gebruikers voor hun dagelijkse werkzaamheden precies die informatie krijgen die ze nodig hebben om hun taken uit te voeren, en niet meer dan dat?” [1]. Een deelvraag hiervan is “welke aspecten zullen meegenomen moeten worden in de modelvorming tijdens het analysetraject van systeemontwikkeling om te voldoen aan deze eis?” [2]. Ook is er de vraag of dit analysetraject voldoende informatie oplevert om het mogelijk te maken automatisch de user-interface voor de gebruikers te genereren. De deelvragen die hierbij horen zijn: • “Hoe zijn de schermen afhankelijk van de taken, informatie, behoefte en kennis van de betreffende gebruiker?” [3]; • “Welke beperkende factoren zijn er die betrekking hebben op de koppeling tussen de verschillende gebieden processen, informatie en rollen?” [4]; Een andere vraag is of de organisatie ondersteund kan worden in de optimalisering van processen en medewerkers met behulp van het model waarin de organisatie is vastgelegd? [5].

2.4 Afbakening De focus zal in dit onderzoek liggen op de koppeling tussen informatiemodellering en procesmodellering, met het doel de automatische generatie van de user-interface als beperking. Het uiteindelijke doel is het in dezelfde termen en op hetzelfde abstractieniveau beschrijven van informatiesystemen, op een dusdanige manier dat het resulterende


8/61

Master’s Thesis

informatiesysteem de eindgebruikers actief ondersteunt in het uitvoeren van hun dagelijkse werkzaamheden. De informatiemodellering wordt uitgevoerd met FCO-IM [BZL96], of een techniek die voortborduurt op deze ontwikkelmethode. Het doel is de informatie en de communicatie daarover in kaart te brengen. Als basisregistraties hebben organisaties grote database systemen, die de informatie voor hun core-business bevatten. FCO-IM is een goede methode om te komen tot zulke ingewikkelde en grote databases. Dit wordt onderstreept door het grote aandeel dat NIAM en afgeleiden (FCO-IM) innemen in de curricula van de opleidingen Hogere Informatica en Informatiekunde. Tevens wordt het bij o.a. KLM gebruikt voor het modelleren van hun vluchtsysteem. Dit aandeel en het gebruik in grote organisaties geeft de significantie van de methode aan. Binnen dit onderzoek zorgt het voor een vaste basis. Als beperking geldt dat slechts de basisgegevens beschouwd worden, waardoor er geen datawarehouse en aggregatieproblematieken bij komen kijken. Deze problematiek wordt reeds op de HAN nader onderzocht door met name de grondlegger van FCO-IM G. Bakema, in samenwerking met E. Monoku. Qua omvang is dit een geheel eigen onderzoek. Basisgegevens zijn de gegevens die rechtstreeks in het model opgenomen zijn. Het onderzoek wordt gedaan in het kader van de studie Informatiekunde, wat de wetenschap is, die zich bezighoudt met “theorieën, methoden en technieken voor het ontwikkelen en in stand houden van vergaand gecomputeriseerde informatiesystemen, met specifieke aandacht voor de doelbewuste afstemming tussen de organisatorische, menselijke, informationele en technologische aspecten van dergelijke systemen” [Pro03b]. Vooral de afstemming tussen de verschillende aspecten van de informatiesystemen is de focus van dit onderzoek en past dus goed in deze geschetste context.

2.4.1 Schermen Zonder aan te geven waar de gegenereerde schermen aan moeten voldoen, is het moeilijk te specificeren welke elementen er meegenomen moeten worden in de modelvorming die generatie mogelijk maakt. Schermgeneratie is een spel van invoer en uitvoer, waar de gedetailleerdheid van de invoer de mate van de uitvoer bepaalt (zie Figuur 1). Als er meer gegevens bekend zijn bij de invoer, kan er een betere generatie plaatsvinden. Input Data

Transformatie & Generatie Output Output

Model

Figuur 1: “Generatie bepaald door invoer”

Door vast te leggen waar de uitvoer aan moet voldoen, wordt hiermee de invoer afgebakend. In dit onderzoek is de centrale vraag hoe schermgeneratie beter af te stemmen is op de informatiebehoeften van de gebruikers. Hiermee beperken we ons tot het genereren van schermen die de juiste informatie bevatten, op een juiste wijze gegroepeerd en voor de juiste groep gebruikers toegankelijk zijn. Hiermee is het mogelijk om schermen te genereren die werkbaar zijn voor een gebruiker, echter niet op de meest optimale wijze. Het is immers denkbaar dat gebruikers andere wensen hebben op het gebied van grafische presentatie (kleur, positie) en volgorde in de inhoud van de schermen. Dit proces kan natuurlijk aan de ontwikkelaar overgelaten worden, maar zou vanwege bovenstaand principe ook toegevoegd kunnen worden bij de input.


9/61

Master’s Thesis

2.5 Methodiek Het onderzoek is begonnen met een literatuurstudie. Er is gekeken naar de volgende gebieden: • ‘State of the art’ modelleertechnieken op het gebied van proces- en organisatiemodellering (Hoofdstuk 3); • Bestaande oplossingen waarmee met behulp van een model schermen gegenereerd worden die aansluiten bij de wensen van de gebruiker (Hoofdstuk 4); • Belangrijke concepten, frameworks en denkwijzen op de gebieden organisatiemodellering en schermgeneratie. Hierna volgde een definitiefase waarin het probleem duidelijk afgebakend werd. Daarna volgde de verdiepingsfase. Hierin werden de problemen uitgediept en mogelijke oplossingen beschouwd. Gedurende dit proces werden bevindingen gedocumenteerd. De bevindingen zijn terug te vinden in hoofdstuk 10 ‘Concluderend’. De literatuurstudie was er op gericht om te inventariseren welke problemen er spelen bij het koppelen van informatie- en procesgegevens tijdens de analysefase van informatiesysteemontwikkeltrajecten. De aandacht werd hierbij gericht op de vakgebieden ontwikkeling van informatiesystemen onder architectuur, het modelleren van workflows en objectgeoriënteerde en relationele systeemontwikkeling, omdat deze gebieden raakvlakken hebben met de onderzoeksvragen en -doelstelling. Bouwen onder architectuur zorgt voor een onderhoudbaar systeem, waarbij de eisen en wensen van stakeholders hoog in het vaandel staan. Bij het modelleren van workflows worden taken van gebruikers geanalyseerd en optimaal ingericht. Deze kennis zal goed van pas komen voor het ontwerpen van een methodiek die rekening houdt met de taken van gebruikers. Als laatste gebied werd de objectgeoriënteerde en relationele systeemontwikkeling beschouwd, omdat deze methoden toegespitst zijn op het maken van informatieverwerkende systemen, zoals ook voor dit onderzoek het uitgangspunt is geweest. Na de literatuurstudie zijn bestaande modelleertechnieken op zowel informatie- als op procesgebied (hoofdstuk 3 ‘Modellering: een overzicht’), geëvalueerd op hun bruikbaarheid ten aanzien van het doel zoals geschetst voor dit onderzoek. Er is getracht de sterke punten van bestaande technieken te combineren. Van de elementen van deze technieken is een metamodel opgesteld (hoofdstuk 6 ‘Evolutie van het FCO-IM metamodel’). Dit is de typedefinitie van hoe domeinmodellen opgebouwd zijn [KWB95]. Na deze inventarisatie kon vastgesteld worden welke informatie extra in het model opgenomen moest worden om automatische schermgeneratie mogelijk te maken. Deze informatie is gebruikt om het metamodel uit te breiden met user-interface elementen. Met behulp van een compleet metamodel dat het domeinmodel beschrijft, is er een aanzet gegeven tot de mogelijkheden van schermgeneratie. Tevens is er bekeken tot welke functie het model nog meer kon dienen, naast het genereren van een user-interface, om de organisatie te ondersteunen. Hierna is een conclusie getrokken, die de gestelde onderzoeksvragen beantwoord heeft. Een verder onderzoeksgebied is vervolgens afgebakend.

2.6 Toepassingsgebied Sinds 2001 is er bij de faculteit Informatica & Communicatie Academie (ICA) van de Hogeschool van Arnhem & Nijmegen (HAN) een probleem met de onderhoudbaarheid van het faculteit informatie systeem (FIS). Dit systeem wordt zo groot, dat de ontwikkelaar geen


10/61

Master’s Thesis

tijd meer heeft om alle vernieuwingen tijdig te verwerken. Doordat incrementele toevoegingen zorgen voor een steeds groter wordende fragmentatie van dit pakket, is er de wens een geheel nieuwe versie op te leveren welke een betere integratie als doel heeft. Het volledig opnieuw bouwen van het systeem zal echter jaren vergen, wat geen optie is. Om deze problemen, samen met de steeds groter wordende gebruikerseisen, op te lossen is er gekeken of het systeem op een andere wijze gebouwd kan worden. Na analyse van het ontwikkeltraject is gebleken dat 80-90% van het programmeerwerk standaard en herhalend werk is. Wanneer voor dit repeterende werk een algoritme wordt gevonden, dan kan dit werk uit handen van de programmeur worden genomen waardoor de ontwikkeling van het informatiesysteem in een stroomversnelling komt. Omdat het oude systeem een puur op data gerichte applicatie is, is gekeken hoe er op basis van het informatiemodel een applicatie gegenereerd kan worden. Deze generatieslag zal in het volgende hoofdstuk besproken worden, omdat enkele van de aspecten gebruikt kunnen worden voor het onderzoek.


11/61

Master’s Thesis

3 Modellering: een overzicht Het ontwikkelen van informatiesystemen begint met het afbakenen van het domein waarvoor het systeem de ondersteuning zal bieden. Deze afbakening, het Universe of Discourse (UoD), bevat alle denkbare manieren van kijken op het systeem [Pro03]. Een manier van kijken wordt een ‘view’ genoemd. Op het gebied van systeemontwikkeling weerspiegelt het UoD vaak de werkelijkheid, of de situatie zoals die ideaal wordt voorgesteld. Dat laatste wordt gedaan om in het informatiesysteem niet de onvolkomenheden van de organisatie mee te nemen. Enkele voorbeelden van redenen om een idealere wereld te schetsen voor het systeem dan de werkelijkheid eigenlijk is, zijn doelmatigheid, performance en security. Een view die over de tijd relatief stabiel is, is de conceptuele structuur van de data die binnen de organisatie gebruikt wordt [BZL96]. Zo lang de essentie van de organisatie niet verandert, verandert er ook weinig aan de taal waarin data wordt uitgedrukt. Een onderwijsinstelling zal bijvoorbeeld altijd studenten, docenten, roosters etc blijven houden. Bij het modelleren van deze view wordt vooral gekeken naar de documenten die gebruikt worden binnen de organisatie. Deze documenten worden in natuurlijke taal uitgedrukt en de patronen in deze taal worden middels bepaalde technieken omgevormd tot een conceptueel schema. Deze technieken zijn veelal ER of NIAM gerelateerd. Een andere stabiele view op het Universe of Discourse zijn de bedrijfsprocessen binnen de organisatie [Fre97]. Zolang de essentie van de organisatie niet verandert, zullen de bedrijfsprocessen ook niet veranderen. Hoe je de organisatie intern ook opdeelt in afdelingen of personen die je het werk laat uitvoeren, steeds zullen in de organisatie processen bestaan voor bijvoorbeeld planning, productie, inkoop, verkoop etc. Bij een beginnend bedrijf zullen deze processen mogelijk door 1 persoon uitgevoerd worden, terwijl na de groei van het bedrijf gespecialiseerde afdelingen ontstaan. De processen zijn tijdens de groei min of meer gelijk gebleven. Voor procesmodellering bestaat geen formele methode. Dit komt doordat procesmodellering gebruikt wordt voor een breed scala aan toepassingen. Van visualisatie van bedrijfsprocessen tot procesoptimalisatie waarbij het meerdere lagen van de organisatie raakt. Voor informatiemodellering geldt dit niet, omdat daar sprake is van een beperkt doel: komen tot een redundantievrij relationeel model. Doordat er geen methode is om te komen tot een procesmodel hangt de kwaliteit van het model geheel af van de nauwkeurigheid van de modelleur. Om deze modellen te kunnen gebruiken voor applicatiegeneratie zal er eerst een uniformeringslag moeten plaatsvinden. Tevens kan er een methode voorgesteld worden, omdat nu wel naar een specifiek doel toegewerkt wordt. Als datamodellering en procesmodellering gecombineerd worden tot een gezamenlijke view, dan is er in kaart gebracht welke data in het domein gebruikt wordt binnen welk proces. Dit is een stabiele basis voor applicatiegeneratie. Het probleem is echter dat er nu nog niet bekend is wie welk proces of welke taak uitvoert. Hiervoor wordt een andere view op het Universe of Discourse geïntroduceerd, namelijk de organisatiestructuur. In tegenstelling tot de vorige views is deze erg veranderlijk, omdat om de organisatie optimaal te laten functioneren de rollen van mensen en afdelingen in de loop der tijd wijzigen. Zo worden de taken van medewerkers kleiner naar mate de organisatie groeit, omdat de totale workload per taak toeneemt. Door mensen te laten specialiseren op een kleiner gebied stijgt de productiviteit en kwaliteit. In dit hoofdstuk zal bekeken worden welke modelleertechnieken er zijn voor de in hoofdstuk 2 geïntroduceerde perspectieven informatiemodellering (3.1), procesmodellering (3.2) en organisatiestructuur (3.3) en hoe goed dergelijke technieken bruikbaar om het gestelde onderzoeksdoel te halen. Om dit te toetsen wordt kritisch gekeken naar de eigenschappen en beperkingen. Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

12/61

Master’s Thesis

Figuur 2: “Het UoD met de views die door deze scriptie bekeken worden”

3.1 Informatiemodellering Voor het modelleren van informatie zal de FCO-IM techniek gebruikt worden. Hiervoor is gekozen omdat core-systemen van organisaties een database als ruggengraat hebben en FCO-IM een degelijke methode is om te komen tot dergelijke ingewikkelde relationele structuren. Verder bieden de tools die FCO-IM ondersteunen toegang tot de repository, een collectie van metagegevens die het model beschrijven, zodat het mogelijk is om uitbreidingen te maken. FCO-IM is de afkorting voor Fully Communication Oriented Information Modeling [BZL96]. In plaats van de realiteit van gebruikers te modelleren gaat FCO-IM uit van de taal waarin gebruikers communiceren over die realiteit. Het biedt een methode om de analyse stapsgewijs en volgens instructies uit te voeren. Als analist is het moeilijk om het domein van de gebruiker compleet te doorgronden. Het is nog moeilijker om een geïntegreerde visie te krijgen over hoe meerdere gebruikers denken over eenzelfde domein. Door totaal te focussen op de communicatie over het domein kunnen discussies over hoe bepaalde zaken worden geïnterpreteerd worden voorkomen. Om de discussie tussen domeinexpert en analist relevant te houden is het gewenst om te praten in voor de domeinexpert begrijpbare taal. Dit is ook de reden dat FCO-IM uitgaat van natuurlijke taal, waarin representatieve voorbeelden worden gegeven over feiten die van


13/61

Master’s Thesis

belang zijn in de communicatie. Zo kunnen ontwerpbeslissingen genomen worden op basis van concrete voorbeelden. FCO-IM gaat uit van elementaire zinnen. Dat zijn zinnen die slechts 1 feit over de realiteit vertellen, niet gesplitst kunnen worden en die voor de domeinexpert goed te begrijpen zijn. Deze zinnen worden de verbalisaties genoemd. Als een gebruiker zegt: “Klant 1001 heeft een opnamelimiet van € 3000” en de andere gebruiker is ermee eens dat deze zin de realiteit goed weergeeft, dan kan de aandacht puur gelegd worden op de structuur van deze zin, in plaats van op de betekenis ervan. Dit omdat de betekenis niet zal worden gerepresenteerd in de database (omdat dit niet mogelijk is). Door classificatie van de informatie van de elementaire zinnen, het aangeven en benoemen van relevante informatie in de expressie, ontstaat een aan NIAM-verwant [NijsHal89] conceptueel schema. Een conceptueel schema is een schema dat voldoet aan het conceptualisatie-principe [Gri82], wat zegt dat het schema slechts die aspecten binnen de te modelleren wereld in kaart brengt die in de gebruikerscommunicatie tot uitdrukking komen. Er worden dus geen implementatieaspecten meegemodelleerd! In het conceptuele schema worden grafische symbolen gebruikt om de informatiestructuur weer te geven. Deze zijn te vinden in Bijlage A - FCO-IM Grafische Symbolen. Nadat het informatiedomein verwoord is met elementaire zinnen, moeten deze geclassificeerd en gekwalificeerd worden. Classificeren is het indelen in groepen en kwalificeren is het geven van een zinvolle naam aan zo’n groep. In de zin wordt aangegeven welke verwoordingen door een object worden gerepresenteerd en waar deze objecten uit bestaan. Een object is een uniek identificeerbaar geclassificeerd element in de zin. Zo is een adres een object dat geïdentificeerd wordt door postcode + huisnummer. Een object kan dus samengesteld zijn uit meerdere elementen die tezamen de identificatie verzorgen. Ieder afzonderlijk element uit de zin dat geclassificeerd is wordt ‘rol’ genoemd. De elementen waar een object uit bestaat zijn dus ook rollen. Tussen objecten bestaan relaties. Twee soorten relaties worden onderkend: de ‘heeft-een’ relatie en de ‘is-een’ relatie. De eerste soort geeft aan dat een object een verband heeft met een ander object; de tweede soort geeft aan dat een object een verbijzondering is van een ander object. In Figuur 3 wordt de ‘heeft-een’ relatie weergegeven (KlantOpnamelimiet), waarbij Klant middels KlantOpnamelimiet een ‘heeft-een’ relatie heeft met een opnamelimiet label. Rol 1 wordt gespeeld door het object Klant en rol 2 door opnamelimiet. Een ‘is-een’ relatie wordt weergegeven door een lijn tussen 2 objecten waarbij de rollen van het verbijzonderde object verbonden zijn met het bovenliggende object.

Klant klantnummer

3 O1 : 'klant <3>' 1001 1:

KlantOpnamelimiet O1

1

2

opnamelimiet

F1 : "<1> heeft een opnamelimiet van $ <2>." 1:

1001

300

Figuur 3: “Conceptuele weergave van een feit over het UoD”

Het resultaat van de classificatie van een feit is een feittype. Hiermee wordt één feit veralgemeniseerd, waardoor alle feiten van eenzelfde type in het model geplaatst kunnen worden. Na het classificeren worden de constraints ofwel beperkingregels bekeken. Eerst wordt de uniciteit per feit over het informatiedomein bekeken. De uniciteit houdt in dat er slechts één van is. Dit wordt gedaan met een methode waarin gekeken wordt of een bepaalde vulling van een rol, oftewel onderdeel van een feit, meerdere keren mag voorkomen in een populatie. Een voorbeeld is te zien in Tabel 1: Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

14/61

Master’s Thesis

Test UC op Tupel Rollen: Nr Feittype, zintype, tupels

Doel

Feittype KlantOpnamelimiet F1: <1> heeft een opnamelimiet van $ <2> 1001 300

1: Testen van UC op rol 1 Testen van UC op rol 2

Mogen tupels samen? Antw Conclusie

1 2:

1001

500 1+2?

N

UC op 1

2 3:

2003

300 1+3?

J

Geen UC op 2

Tabel 1: “UC bepaling bij een niet-elementair feittype”

Het resultaat van deze bepaling komt weer terug in het conceptuele schema van Figuur 4 als tweevoudige pijl boven één of meerdere rollen.

Klant

KlantOpnamelimiet

1

2 O1

3

klantnummer

1

O1 : 'klant <3>' 1001 1:

2

opnamelimiet

F1 : "<1> heeft een opnamelimiet van $ <2>." 1:

1001

300

Figuur 4: “Conceptueel schema na UC bepaling”

De uitgevoerde uniciteitsbepaling kan middels enkele simpele testen gecontroleerd worden. Zo is er de n-1 regel, die stelt dat een feittype met n rollen ten minste één uniciteitregel moet hebben over n-1 rollen omdat het anders splitsbaar is. Omdat deze regel de BoyceCodd normaalvorm garandeert, maar niet de vierde normaalvorm kan er nog de zogenaamde projectie/join-test [NijHal89] uitgevoerd worden. Voor objecttypen geldt de nregel die inhoudt dat ieder objecttype precies één uniciteitregel over alle rollen moet hebben. Dit komt omdat de rollen in een objecttype de identificatie van het object aangeven. Na de uniciteitbepaling wordt de totaliteitbepaling uitgevoerd. Deze bepaling gaat uit van een objecttype en kijkt of de verbonden feittypen verplicht ingevuld moeten zijn. Het gaat uit van de vraag of een feittype niet gevuld mag zijn. Deze vraag kan dan door een domeinexpert beantwoord worden, waarna het schema verder aangevuld kan worden. Het proces van de bepaling is in Tabel 2: “TC bepaling” uitgevoerd. Objecttype: Klant 1001 1001

Rol 1 uit KlantOpnameLimiet 300 -

Mag dit? J N

Conclusie OK TC op rol 1

Tabel 2: “TC bepaling”

Het uiteindelijke schema voor deze verwoording ziet er dan als volgt uit:

Klant 1

klantnummer

3 O1 : 'klant <3>' 1: 1001

KlantOpnamelimiet 1

2 O1

1

2

opnamelimiet

F1 : "<1> heeft een opnamelimiet van $ <2>." 1001 300 1:

Figuur 5: “Conceptueel schema met UC en TC bepalingen”

Vanuit een conceptueel schema kan een mapping plaatsvinden naar een logisch schema. In het logisch model worden wel implementatieaspecten meegenomen en is er vaak op gericht een zo efficiënt mogelijke datastructuur te gebruiken. Het logische model voor een redundantievrije database is een relationeel schema in de 3e normaalvorm wat gevormd kan worden door de groepeer-, lexicaliseer- en reduceerslagen (GLR-Algoritme) toe te passen


15/61

Master’s Thesis

[BZL96]. Als het GLR algoritme wordt toegepast op het gebruikte voorbeeld ontstaat het volgende diagram.

Klant

p

1

2

opnamelimie t

3

klantnumme r

F1 : "Klant <3> heeft een opnamelimiet van $ <2>." 1:

300

1001

Figuur 6: “Gegroepeerd, gelexicaliseerd en gereduceerd informatiemodel”

Uit het GLR-informatiemodel kan een relationeel schema afgeleid worden door voor ieder feittype een aparte tabel te nemen. De rollen worden vervangen door attributen en de tabelen kolomnamen krijgen zinvolle namen ter vervanging van de rolnummers. De uniciteitsconstraints vormen de primaire en unieke sleutels. Het conceptuele model representeert de feiten binnen het domein en de onderlinge verbanden hiertussen. Het logische model doet dit ook, echter worden feiten gecombineerd, geclusterd en verwijderd zodat een model ontstaat met zo weinig mogelijk redundantie en een zo groot mogelijke samenhang.

3.2 Procesmodellering Het onderkennen van processen bestaat sinds de industrialisering en is het product van de zoektocht naar steeds efficiëntere productiemethoden. Het inzicht is ontstaan dat er, door de routineaspecten van werkactiviteiten te concentreren, efficiënter gewerkt kan worden. Processen splitsen werkactiviteiten in goed gedefinieerde taken, rollen, regels en procedures die gezamenlijk het werk op kantoor en de werkvloer beschrijven. In het begin werden processen geheel uitgevoerd door mensen die fysieke producten bewerkten. Sinds de introductie van informatie technologie worden processen vaak geheel of gedeeltelijk uitgevoerd door geautomatiseerde systemen. Georgakopoulos [GeHor95] categoriseert processen binnen een organisatie in: materiaalprocessen, informatieprocessen en bedrijfsprocessen. Materiaalprocessen zijn menselijke taken in de fysieke wereld. Voorbeelden hiervan zijn het opslaan, bewerken en samenstellen van fysieke producten. Informatieprocessen zijn gerelateerd aan (gedeeltelijk) (geautomatiseerde) taken die informatie bewerken, creëren of gebruiken. De infrastructuur waarop informatieprocessen berusten zijn vaak databases, transactiesystemen en gedistribueerde systemen, maar ook mens-mens communicatie. Bedrijfsprocessen zijn beschrijvingen van de organisatie, gericht op de markt. Deze zijn georganiseerd als materiaal- of informatieprocessen. Een bedrijfsproces is er vaak op gericht om een stakeholder, zoals een klant of businesscontract, tevreden te stellen. Het abstractieniveau van een bedrijfsproces is dus hoger dan dat van een informatie- of materiaalproces. Het doel van deze scriptie is het beter afstemmen van de informatieomgang van de gebruiker op zijn dagelijkse werkzaamheden. Hiervoor zal er dus vooral gericht worden op bedrijfsprocessen waarin informatieprocessen een belangrijke rol spelen. Materiaalprocessen zullen buiten beschouwing worden gelaten omdat deze niet relevant zijn voor het onderzoek. Vanzelfsprekend kan de optimalisatie van de informatieomgang leiden tot een beter materiaalproces, omdat er hedendaags bij materiaalprocessen ook veel informatieprocessen komen kijken. Denk hierbij bijvoorbeeld aan tracking en tracing van producten, een vereiste voor ISO certificering. Zoals materiaalprocessen werken met een fysiek object, werken informatieprocessen met een verzameling van informatie. Omdat in dit onderzoek een link gelegd wordt met informatiemodellering, en dan feitelijk FCO-IM op conceptueel niveau, beschouwen we die informatie als ware het feiten in het domein [BaHaPr]. Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

16/61

Master’s Thesis

Voor de definitie van een proces bestaat in de literatuur eenzelfde beeld. Zowel Van Der Aalst [AaHee00] als Georgakopoulos [GeHor95] definiëren een proces als volgt: Een proces bestaat uit taken die uitgevoerd moeten worden en een aantal condities die de volgorde van de taken bepalen. Een taak is een logische werkeenheid die als geheel uitgevoerd wordt door 1 actor, waarbij actor een generieke naam is voor een persoon, machine of groep van personen of machines. Een proces heeft één duidelijk startpunt en kan op meerdere plaatsen ten einde lopen. De in deze scriptie gebruikte definitie van een proces breidt bovenstaande procesdefinitie uit met die van Sharp [Sha02], die aangeeft dat een proces tevens een meetbaar resultaat voor een stakeholder moet hebben. Processen kunnen op verschillende manieren gestart worden. Veelal worden processen getriggerd door een eindconditie van een ander proces. Andere manieren zijn op basis van een planning, bijvoorbeeld een datum waarop de belastingaangifte uitgevoerd moet worden, of bij het veranderen van een gegevensverzameling. Het te laag zijn van een voorraad kan bijvoorbeeld een trigger zijn om het inkoopproces te starten. Taken kunnen op verschillende manieren samenhangen. Een aantal taken die in een bepaalde volgorde uitgevoerd moeten worden, wordt een ‘sequence’ genoemd. Sommige taken hoeven niet uitgevoerd te worden als er aan een bepaalde conditie is voldaan. Er moet dus een keuze gemaakt worden tussen bepaalde taken. Deze keuze wordt een ‘choice’ genoemd. Ook zijn er taken die parallel uitgevoerd kunnen worden, de zogenaamde ‘parallellisation’ die op zijn beurt kan leiden tot een samenkomst van de parallelle taken, de ‘synchronisation’. Als laatste zijn er ook taken die meerdere malen uitgevoerd moeten worden totdat een conditie bereikt is. Deze worden ‘iteration’ genoemd.

3.2.1 Methodiek Zoals aangegeven bestaat er voor procesmodellering geen echte methode. Het modelleren van processen in een organisatie gaat dan ook vaak uit van een domeinexpert die de procesanalist informatie verschaft over de gang van zaken binnen desbetreffende organisatie. De procesanalist zal vaak op top-level beginnen, wat inhoudt dat hij begint met gerichte vragen stellen aan het management. Van deze interviews wordt een beschrijving bijgehouden; de zogenaamde procesbeschrijving. Door steeds verder in te zoomen op de werkzaamheden binnen het gestelde kader wordt de procesbeschrijving steeds gedetailleerder, tot er uiteindelijk voldaan is aan het gewenste detailniveau. Dit niveau is afhankelijk van wat het doel is van het in kaart brengen van de processen. Wanneer er slechts op managementniveau duidelijkheid verkregen moet worden over de indeling van de organisatie zal er minder diep geanalyseerd worden dan wanneer processen op de werkvloer geoptimaliseerd moeten worden, of als er een systeem moet worden gemaakt wat de processen ondersteunt. Procesanalisten zijn vooral geïnteresseerd in de vraag wie bepaalde zaken wanneer afhandelt en wie de eigenaar of verantwoordelijke van een bepaald proces of taak is. Van processen wordt ook bijgehouden wanneer en onder welke condities ze beginnen en eindigen. Als laatste punt wordt er genoteerd met welke documenten de processen een relatie hebben [Pro02]. Een puntsgewijs voorbeeld van een indeling van een procesbeschrijving (volgens Atos-Origin [ATOS]):


17/61

Master’s Thesis

Proces: Procesnaam • Proces start met • Proces eindigt met • Korte Procesbeschrijving • SubProcessen/Taken • Input • Output • Proceseigenaar

3.2.2 Procesmodellen Na het completeren van een tekstuele beschrijving van de processen in de organisatie wordt hiervan een diagram gemaakt. Diagrammen geven een duidelijker beeld van de stroom en behoeven weinig uitleg. Er zijn meerdere manieren om processen visueel weer te geven. De meest gebruikte maar inmiddels gedateerde techniek is DFD (Data Flow Diagram). In een DFD worden processen en gegevensstromen in hun onderlinge relatie met elkaar vastgelegd weergegeven. De gegevens zijn in DFD alleen met hun naam weergegeven, zonder dat hieruit is af te lezen waar deze precies uit bestaan. Dit houdt in dat gegevens vaak niet op feitniveau maar op formulierniveau worden weergegeven. Het diagram kent gegevensstromen, processen, gegevensverzamelingen en externe bronnen en bestemmingen van gegevens. DFD’s hebben slechts een volgorde van uitvoeren en bevatten dus geen tijdsaspecten zoals parallellisatie en synchronisatie. Keuzemogelijkheden worden ook gemist. Hoewel DFD’s beschikken over functionele decompositie blijft het niveau vaak te abstract voor nuttig gebruik in de implementatiefase van een systeem. 4) Inning collegegeld

Webform

CBAP file

2) Verwerken webform gegevens

1) Verwerken CBAP gegevens

3) Inschrijving

5) Uitschrijving

6) Switch

??

7) Verwerken inschrijving buitenlandse student

Figuur 7: “DFD van een proces”

Een nieuwere methode om processen te beschouwen komt van BPMI [BPMI] en BiZZDesign [BiZZ], die een vergelijkbare methode gebruiken om processen te analyseren, visualiseren en verbeteren. Deze methode is veel meer dan DFD’s gericht op tijdsaspecten, actoren en de onderliggende datastructuren (op logisch niveau). Deze tools, vooral gericht op het verbeteren van bedrijfsprocessen missen helaas wel een echte methodiek om tot het model te komen. In een workshop met 10 ervaren procesmodelleurs en een testcase van één A4 worden 10 significant verschillende modellen opgeleverd. Voor toepassing binnen schermgeneratie zal er in ieder geval een methodiek toegevoegd moeten worden om te komen tot een consistent model dat eenduidig en geautomatiseerd te interpreteren is. Een ander probleem met deze techniek is dat processen afgebeeld worden op het logische Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

18/61

Master’s Thesis

informatiemodel. Voor het doel van deze tool is het een logische keuze, omdat Testbed Studio bedoeld is voor het herinrichten van bedrijfsprocessen. Op dat moment bestaat er dus al een proces en zijn er tevens reeds systeemimplementaties waar niet meer omheen gegaan kan worden. Dit is voor een conceptuele benadering van het domein niet gewenst en vaak ook niet het geval. Ook bevat het logische model minder informatie dan het conceptuele model. Deze verloren informatie is waarschijnlijk voor gebruikersvriendelijke en taakspecifieke schermgeneratie van groot belang. Een goed punt aan de techniek is dat er een duidelijk onderscheid gemaakt kan worden tussen de verschillende procesniveaus, hoewel de koppeling hiertussen matig uitgewerkt is en dit onderscheid niet afgedwongen wordt. De procesniveaus zijn de mate van abstractie van een procesbeschrijving. Een manager gebruikt bij eenzelfde proces een hoger abstractieniveau dan bijvoorbeeld een baliemedewerker. Door het proces in verschillende niveaus in te delen, kan hieraan tegemoet gekomen worden. In hoofdstuk 5.1 wordt hier dieper op ingegaan, maar voor het onderstaande voorbeeld zullen de niveaus beknopt beschreven worden. Een organisatie kent gemiddeld 5 verschillende abstractieniveaus in de opdeling in processen. Zoals hierboven genoemd onderkennen we de bedrijfsprocessen die bestaan uit informatieprocessen. Bedrijfsprocessen zijn de globale processen, gericht om een stakeholder tevreden te stellen. Informatieprocessen zijn de processen hierin die informatie behandelen. Deze zijn onder te verdelen in taken, een groepering van bewerkingen met een bepaald doel. De bewerkingen zijn logische werkeenheden die op hun beurt weer bestaan uit elementaire handelingen. Een elementaire handeling is een handeling die niet splitsbaar is, dus door een actor in zijn geheel uitgevoerd moet worden. Hieronder is een voorbeeld weergegeven van een procesbeschrijving van een verzekeringsbedrijf in Testbed Studio van BiZZDesign. Hierbij is het model al zo veel mogelijk ingericht als in de indeling van hoofdstuk 5: Conceptuele Specificatie van het Onderzoeksgebied. Op het bovenste niveau vinden we de bedrijfsprocessen, die in Figuur 8: “Bedrijfsprocessen in Testbed Studio” zijn gevisualiseerd. Verzekeringsbedrijf Relatiebeheer

Innen premies

Beheer klantgegevens

Afhandelen schade

Marketing

Verwerken mutaties pers. gegevens

Factureren

Verwerken contractwijzigingen

Ontvangen

Risicomanagement

Accepteren Productontwikkeling

Beheer conto Uitkeren schade

Beheer vermogen

Systeemontwikkeling

Niet-primaire functies

Figuur 8: “Bedrijfsprocessen in Testbed Studio”

Een uitwerking van één van de bedrijfsprocessen levert een indeling in informatieprocessen op, met daarbij weergegeven de taken die hierbij horen. Het indienen van een claim is hier een informatieproces, waar de taken Registreren, Accepteren, Beoordelen en Uitbetalen onder vallen. Indienen claim

Re gistre re n

Acce pte re n

Be oorde le n

Uitbe tale n

Figuur 9: “Informatieproces met zijn taken”


19/61

Master’s Thesis

Deze taken bestaan op hun beurt weer uit bewerkingen, waar we gelijk de principes als keuzes, synchronisatie etc. tegenkomen (3.2), die zich dus niet enkel op taakniveau voordoen. Door in te zoomen op de bewerkingen die horen bij de taak Registreren wordt het volgende beeld (Figuur 10: “Bewerkingen van de taak Registreren”) verkregen. Een overzicht van de betekenis van de grafische symbolen is te vinden in Bijlage C Testbed Studio Grafische Symbolen. Registreren schadedossier

afwijzen claim geen bestaande klant

ontvangen claim

opzoeken klantdossier

*

aanmaken schadedossier

controleren compleetheid

bestaande klant

compleet

incompleet

invoeren claimgegevens *

klantdossier

aanvullen claim

claim

schadedossier

Figuur 10: “Bewerkingen van de taak Registreren”

De techniek houdt hier op met verder uitwerken van de processen. Dit houdt in dat het niveau van elementaire handelingen niet bereikt wordt. Zoals te zien is in het voorbeeld van Figuur 10, is de bewerking ‘ophalen klantgegevens’ nog niet voldoende specifiek om precies te weten wat dit inhoudt. Een elementaire handeling zou dan kunnen zijn het zoeken op een klantnummer, dat op zichzelf een feit van het klantendossier is in het informatiedomein.

3.3 Organisatiemodellering Met proces- en informatiemodellering, die in de vorige paragrafen toegelicht zijn, kan er aangegeven worden welke informatie in welk proces behandeld wordt. Met procesmodellering zal het mogelijk zijn om aan te geven in welke volgorde bepaalde taken uitgevoerd moeten worden. Met het oog op schermgeneratie is het echter ook van belang om te weten wie de taken uitvoert en vooral hoe hij/zij in de organisatie staat. De uitvoerders van het proces worden actoren genoemd. Een actor wordt gedefinieerd als iets dat een bepaalde taak uitvoert, uniek te identificeren is en een bepaalde capaciteit heeft. Deze definitie komt overeen met het begrip ‘resource’ zoals dat gebruikt wordt binnen Workflow Modelling technieken [AaHee00]. Er is echter voor gekozen om dit begrip ‘actor’ te noemen omdat dit duidelijker verwijst naar een uitvoerende. Omdat in dit onderzoek schermen door mensen behandeld worden en niet volledig geautomatiseerd door een systeem of robot, wordt er uitgegaan van een capaciteit van 1 voor een actor. Dit houdt in dat deze persoon niet meer dan 1 taak tegelijk kan uitvoeren.

3.3.1 Testbed Studio De voorgaande diagrammen uit Testbed Studio omhelzen 2 van de 3 werelden in het UoD, namelijk de proces- en informatiemodellering. Ook de 3e, organisatiestructuur, heeft zijn weg gevonden in Testbed Studio. Hoewel het precieze organogram van de organisatie niet in te vullen is, denk aan de formele structuur waar van een medewerker aangegeven is aan wie hij verantwoording schuldig is en wie aan hem, kan er wel een functionele indeling gemodelleerd worden, zoals weergegeven in Figuur 11.


20/61

Master’s Thesis

Verzekeringsbank Ondersteunende staf Administratief medewerker [5]

Werkverdeler

Medewerker Polisbeheer

Klant [*]

Specialisten Specialist Autoschade [2]

Medewerker Autoschade

Financieel medewerker

Taxateur

Figuur 11: “Functionele indeling van de organisatie”

Door een koppeling te maken tussen bewerkingen en rollen is het duidelijk wie de stakeholders van een bewerking zijn. Helaas is er met deze techniek geen onderscheid te maken tussen uitvoerders en eigenaren, wat voor de schermgeneratie een groot gemis is. De modellen opgeleverd door o.a. Testbed Studio, een CASE-tool volgens de BiZZDesign techniek bevatten veel meer relevante details opgenomen dan modellen gemaakt met de DFD techniek. Om te komen tot een totaalmodel voor de analysefase zullen veel aspecten hiervan meegenomen worden.

3.3.2 Actor Classificatie In het algemeen is het actoren slechts toegestaan een beperkt aantal taken uit te voeren. Zo mag op een school bijvoorbeeld de conciërge geen stages toewijzen aan studenten. Het omgekeerde is ook waar: een taak kan uitgevoerd worden door een beperkt aantal actoren. Omdat het niet praktisch is om alle actoren binnen een organisatie aan taken te koppelen, er kunnen immers duizenden medewerkers zijn, worden ze geclassificeerd in groepen. De groep ‘Docent’ kan bijvoorbeeld bestaan uit Harrie, Martijn en Johan. Een actor kan ingedeeld zijn in meerdere groepen. Zo kan Martijn bijvoorbeeld niet alleen ‘Docent’ zijn, maar bijvoorbeeld ook ‘Stagebegeleider’. In het algemeen bestaan er twee vormen van actor classificatie: 1. gebaseerd op functionele eigenschappen; 2. gebaseerd op de positie binnen de (formele) organisatie. Een groep actoren gebaseerd op functionele eigenschappen wordt ook wel rol, functie of kwalificatie genoemd. Een rol is een groep actoren die over een aantal specifieke vaardigheden, authorisaties, verantwoordelijkheden, belangen of motieven beschikken. Door een rol aan een taak te verbinden kan er verzekerd worden dat de actor die de taak uitvoert genoeg kennis en kunde heeft om deze uit te voeren. Een groep actoren samengesteld op hun positie binnen de organisatie wordt ook wel unit of afdeling genoemd. Deze vorm van classificatie zorgt ervoor dat een taak op de juiste plaats binnen de organisatie wordt uitgevoerd. Hieronder weergegeven zijn de verschillende rollen en functies waar een actor zich in kan bevinden. Rollen hebben een afhankelijkheid van elkaar, bijvoorbeeld de relatie die een medewerker heeft met zijn supervisor of andersom. Dit kan weergegeven worden in een organogram.


21/61

Master’s Thesis

Arnhem

Directeur

Nijmegen Directeur

Jeroen

Modelleur

Analist

Formele Indeling

Modelleur Freek

Willem

Analist Jan

Piet Business Unit

Figuur 12: “De functionele en formele actorindeling binnen een organisatie”


22/61

Master’s Thesis

4 Schermgeneratie op basis van het logische datamodel In het vorige hoofdstuk zijn de verschillende perspectieven op het UoD uitgediept. In dit hoofdstuk zal gekeken worden naar een datageoriënteerde schermgeneratietechniek zoals deze al wordt toegepast. Deze techniek gaat uit van het logische informatiemodel, zoals beschreven in hoofdstuk 3.1. Alvorens de techniek te beschrijven wordt eerst in 4.1 gedefinieerd wat er onder een database user-interface wordt verstaan. Op basis van deze definitie wordt in 4.2 de techniek besproken hoe er vanaf een logisch datamodel schermen gegenereerd kunnen worden.

4.1 User-Interface Definitie In de zoektocht naar snellere applicatieontwikkeling is er gekeken naar de werkzaamheden die verricht moeten worden om een gewenste database interface te verkrijgen. Een database-interface is de manier waarmee de gebruiker bewerkingen op de gegevens in de database kan uitvoeren c.q. de communicatielaag tussen database en gebruiker. Deze kan op veel manieren bewerkstelligd worden: tekstueel, grafisch, spraakgestuurd, etc. In dit onderzoek zal er ingegaan worden op de grafische window-based interface, zoals deze veruit het meeste gebruikt wordt tegenwoordig. Een window-based interface bevat schermen (de zgn. windows) die op hun beurt schermen, controls en containers kunnen bevatten. Controls zijn user-interface elementen die waarden grafisch weergeven uit het informatiemodel representeren en het mogelijk maken deze waarden te veranderen. Ze hebben een positie op het scherm (een x en een y coördinaat) en een grootte (hoogte en breedte). Verschillende typen controls onderscheiden zich door de manier waarop ze waarden representeren en door de manier waarop ze het wijzigen van de waarde ondersteunen. Ieder control geeft de waarde van een rol in een feit weer, waarbij de controls die een verbinding hebben met een objecttype een lijst van mogelijke waarden bevatten. Deze lijst van waarden kan tevens beperkt worden door constraints op de gegevens, zodat niet alle maar een selectie hieruit mogelijke invoerwaarden zijn. Er is dus een duidelijk verschil te onderkennen tussen de geselecteerde waarde en de lijst van mogelijke waarden. We onderkennen dus de typen controls die geen selectielijst van waarden bevatten en controls die wel een selectielijst bevatten. Deze controls kunnen in verschillende toestanden staan, namelijk de bewerkbare- en de weergavetoestand. De bewerkbaretoestand laat de gebruiker de mogelijkheid de geselecteerde waarde van een control te wijzigen, terwijl de weergavetoestand dit niet biedt. De waarde van de rol die weergegeven wordt door een control heeft een specificatie, namelijk het datatype. Het datatype geeft aan wat voor soort waarden de rol bevat. Algemeen en globaal wordt er een onderscheid gemaakt tussen tekst, numerieke waarden, datum en booleaanse datatypen, waar voor iedere variant hiervan specifiekere varianten bestaan. Dit laatste is echter voor dit onderzoek niet van fundamenteel belang. Afhankelijk van de toestand, type en datatype wordt de grafische weergave en het gedrag gekozen. Een voorbeeld hiervan is weergegeven in Figuur 13 "Verschil van grafische weergave afhankelijk van toestand, type en datatype", waar te zien is dat dezelfde gegevens zichtbaar zijn, alleen op een andere manier weergegeven. In de leestoestand is het de gebruiker niet toegestaan gegevens te wijzigen, dus zullen er geen controls gegenereerd worden die dat gedrag impliceren. Dit is wel het geval in de bewerkingstoestand.


23/61

Master’s Thesis Bewerkingstoestand

Leestoestand StudentNaam

StudentNaam

Voornaam:

Voornaam:

Arnoud

Arnoud

Achternaam:

Achternaam:

Van Bers

Van Bers

Vooropleiding:

Vooropleiding:

HAVO

HAVO VWO HBO MBO

Figuur 13: "Verschil van grafische weergave afhankelijk van toestand, type en datatype"

Containers zijn evenals controls grafische elementen, met het verschil dat deze geen waarde representeren maar controls kunnen bevatten, wat ze ideaal maakt om andere controls te groeperen. Figuur 14 “UML Diagram van een windows-based database interface” geeft de belangrijkste concepten en hun onderlinge relaties weer in UML notatie. 1

Form

1

-Title : string -CRUDstate -Bewerking

0..n 0..n

0..n 0 1..n

Container -Title : string -Position

Control 0..n

1 1

0..n

Grid

-Label : string -Accented : bool -Position -Width : int -Height : int

Button -Action

1

+Zoom()

+Click()

Weergave Control

1

Invoer Control -Datatype -Selection : bool -MultiSelect : bool -Rol

-Datatype -Rol

1..n Single Value

1

-Value

Figuur 14: “UML Diagram van een windows-based database interface”

Momenteel bestaat er reeds een generator die op basis van het logische informatiemodel schermen kan genereren. Deze generator, UFG, is ontwikkeld op de Hogeschool van Arnhem en Nijmegen [Ber01]. De algoritmiek hierachter wordt besproken in de volgende paragraaf. Hoewel het goed mogelijk om schermen van het logische datamodel te genereren werpt dit enkele beperkingen op die het gebruik van de resulterende schermen bemoeilijkt voor de eindgebruiker. Doordat het logische model is geoptimaliseerd middels het GLR-algoritme voor het verkrijgen van zo weinig mogelijk redundatie, is het vaak zo dat de tabelstructuur geen logische structuur heeft voor het ondersteunen van de werkzaamheden van de eindgebruiker. Er is dus de wens het generatieprincipe te verleggen naar het conceptuele niveau. Hier komen echter belemmeringen naar voren die in hoofdstuk 5 nader onderzocht worden.


24/61

Master’s Thesis

4.2 Beschouwing van het logisch model met als doel schermgeneratie Als het logische informatiemodel beschouwd wordt, dan zijn er objecten te herkennen die bestaan uit hun unieke identificator, een aantal eigenschappen en verwijzingen naar andere objecten.

Figuur 15: “Voorbeeld van een logisch informatiemodel”

Door de relaties tussen de objecten te analyseren is er iets zinnigs te zeggen over het gewenste gedrag van de applicatie [RR97]. In dit voorbeeld is de relatie tussen Personen en Studenten een subtypenrelatie omdat de verwijzende sleutel (foreign key) over exact dezelfde rollen in beide objecten ligt en deze tevens de identificerende sleutel is (primary key). De relaties tussen Studenten en de objecten Inschrijvingen en Scores zijn 1:n relaties omdat de identificator van Studenten vaker voor kan komen in de populaties van Inschrijvingen en Scores. Als er datageoriënteerd naar dit informatiemodel gekeken wordt, met als doel op basis van dit model een applicatie genereren, dan is er waarschijnlijk de wens dat in het scherm Personen een verwijzing naar Studenten voorkomt. Wanneer men in het scherm Studenten is aanbeland, dan moeten van de gekozen student zijn scores en inschrijvingen zichtbaar zijn. Deze moeten dan in hetzelfde scherm weergegeven worden, omdat dit extra gegevens zijn over deze persoon als student. Uit user-interface oogpunt biedt een grid-layout de beste manier om 1:n gegevens te tonen. 1:1 gegevens worden het best weergegeven in een panel. Een voorbeeld hiervan is weergegeven in Figuur 16 “Een gegenereerde interface voor het geschetste voorbeeld”. Niet alleen de multipliciteit van de objecten geeft een sturing voor de te maken interface, maar ook het soort of type gegevens dat zich in een object bevindt [RR97] [PEG94]. Ieder attribuut in het model heeft een aantal eigenschappen. Voor relationele databases zijn deze eigenschappen vaak een datatype, lengte, naam en een sleutelwaarde. Sommige databases voegen hier nog meer informatie aan toe (zoals default waarden, patronen waar de invoer aan moet voldoen etc.), waardoor het makkelijker genereren wordt, omdat er meer informatie beschikbaar is over het object. In de user-interface wordt ieder veld gemapped op een control. Het datatype van een veld zegt veel over het gewenste control dat de gebruiker het best in staat stelt om zijn acties mee uit te voeren. Wanneer een veld bijvoorbeeld van het ‘datum’type is, is er de wens om een kalenderfunctie te zien om deze eigenschap van waarde te veranderen. Hetzelfde principe geldt ook voor bijvoorbeeld booleaanse keuzevelden welke Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

25/61

Master’s Thesis

door middel van een selectievak de waarde ‘aan’ of ‘uit’ moeten kunnen krijgen. Voor textvelden (datatype ‘string’) wordt bepaald of de invoer kan bestaan uit 1 of uit meerdere regels. Bij een enkele regel wordt een zogenaamde editbox gebruikt, anders een memoveld. De grootte van het veld wordt bepaald aan de hand van de maximale veldlengte in de database. Als er immers 4 karakters in een attribuut mogen worden ingegeven (postcodecijfers), dan hoeft het veld ook maar ruimte te geven voor 4 karakters. Als de scherminhoud bekend is, dan kunnen op basis hiervan commando’s gegenereerd worden die opvraag-, invoer-, bewerkingen verwijderacties op de gepresenteerde data uitvoeren. Dit werkt met SQL statements [Lan92] die gegenereerd kunnen worden op ongeveer dezelfde manier als het scherm. Bij het genereren van SQL statements komen nog enkele andere problemen kijken, zoals het bijhouden van een historie en het oplossen van problemen die komen kijken bij multi-user omgevingen. Deze problematiek zullen we ook tegenkomen bij het maken van de interface op basis van een domeinmodel. Er zal dan ook op worden teruggekomen in hoofdstuk 7.4 ‘Terugkoppeling naar de gebruiker’.

Figuur 16: “Een gegenereerde interface voor het geschetste voorbeeld”

Figuur 16 geeft een gegenereerde interface weer. Het scherm wordt een form genoemd, hier met de titel ‘Studenten’. Bovenaan het form vinden we de buttons die een specifieke actie toegewezen hebben gekregen. De invoeren, bewerken en verwijderbuttons nemen een centrale plaats in. Hiermee wordt de het scherm in een andere toestand gezet, namelijk de bewerkbare toestand. Tevens zien we navigatiebuttons om door het aantal instanties van studenten te doorlopen. Onder de buttons zijn alle rollen van het logische informatiemodel gemapped op een control. De verplichte velden (not null) zijn geaccentueerd. Duidelijk is te zien dat er verschil zit tussen de controls die een ander type en datatype representeren. De rollen die gespeeld worden door een objecttype worden weergegeven als een combobox, de rollen die een datum representeren hebben de mogelijkheid tot een selectie uit een kalender. De rollen die slechts 1 waarde representeren zonder selectielijst worden weergegeven met een editbox. Daaronder worden de relaties die andere objecttypen met Studenten hebben weergegeven in tabbladen. Voor 1:1 relaties tussen de twee objecttypen wordt hetzelfde principe als hierboven herhaald met de controls en buttons. Voor 1:n relaties wordt een grid weergegeven.


26/61

Master’s Thesis

5 Conceptuele Specificatie van het Onderzoeksgebied Informatiesystemen worden gebruikt om te voldoen aan de informatiebehoefte van (een deel van) een organisatie. De informatie waartoe deze systemen toegang geven is ontstaan uit de bedrijfsprocessen, waarbij via de dagelijkse taken en handelingen van medewerkers een informatievraag en -aanbod ontstaat. Deze informatiebehoeften, vastgelegd in fysieke formulieren of digitale vorm, worden geanalyseerd door een informatieanalist die wordt bijgestaan door één of meerdere domeinexperts. Met behulp van de FCO-IM methode levert dit een conceptueel datamodel op. Naast een informatiemodel is er behoefte aan een organisatiemodel, waarin op conceptueel niveau beschreven staat hoe de gehele organisatie in elkaar steekt. In dit hoofdstuk onderzoeken we de vraag wat er nodig is om over genoeg informatie te beschikken om schermen te kunnen genereren. Als dit duidelijk is kan er bekeken worden of deze informatie verloren gaat bij het volgen van de opeenvolgende stappen in het traditionele modelleerproces. Zo ja, dan is het de vraag hoe dit op te vangen is door uitbreidingen aan te brengen. Alvorens hiertoe wordt overgegaan, zal er in 5.1 eerst duidelijkheid verschaft worden over de niveaus van processen.

5.1 Niveaus van Processen In een organisatie spelen processen, rollen en informatie een belangrijke rol. Processen zijn de werkzaamheden die uitgevoerd worden. Rollen geven aan wie deze werkzaamheden uitvoert. De informatie geeft aan wat er door die rollen in deze processen wordt verwerkt. Helaas is er geen eenduidige wijze om te komen tot een conceptueel procesmodel, omdat er zoals reeds eerder opgemerkt geen exact doel aan te wijzen is waar procesmodellen primair op gericht zijn. Dit probleem wordt versterkt doordat het begrip ‘proces’ op meerdere manieren is te interpreteren en op meerdere niveaus is te gebruiken. Omdat procesmodellen geen duidelijk doel voor ogen hebben, is het niet mogelijk de scope van een model aan te geven. Het model kan immers alleen de belangrijkste processen beschrijven voor de manager, het kan stap-voor-stap de taken van een medewerker beschrijven, of ieder ander gewenst detailniveau. Door wel een duidelijk doel aan procesmodellen te geven, namelijk applicatiegeneratie, is het mogelijk om op eenduidige wijze een procesmodel samen te stellen. Zo is het dan ook mogelijk om de elementen van het conceptuele informatiemodel te koppelen aan het procesmodel, omdat er zelf richting aan wordt gegeven. Organisatie Bedrijfsprocessen

1..n 1..n Informatie processen

1..n 1..n Taken

1..n 1..n Bewerkingen

1..n 1..n (Elementaire) Handelingen

Zoals hierboven geschetst bestaan er verschillende procesniveaus. Om duidelijkheid te scheppen in de verschillende procesniveaus, kunnen deze duidelijk gesplitst en gedefinieerd worden. Schinkel [Sch02] stelt dat organisaties in minstens 3 en hoogstens 7 niveaus op te delen zijn, afhankelijk van complexiteit en gewenste detaillering van de omgeving waarin de processen zich afspelen. De meeste organisaties hebben een ordening van 5 niveaus, die aangehouden worden voor dit onderzoek. Het onderste niveau, ‘handelingen’, zijn de elementaire acties die zich afspelen binnen een organisatie, waarbij elementair inhoudt dat ze slechts door 1 actor tegelijk uitgevoerd kunnen worden en slechts 1 deel van een object behandelen. Meerdere handelingen vormen een ‘bewerking’, wat een logische werkeenheid is, die gedaan kan worden door meerdere actoren op een enkel object. Deze hiërarchie gaat verder tot het niveau van informatieprocessen op bedrijfsprocessen is bereikt, die op hun beurt bestaan uit taken. Taken worden door Schinkel ‘activiteiten’ genoemd. In de context van deze scriptie is voor het Figuur 17: “Decompositie van processen in een organisatie”


27/61

Master’s Thesis

woord ‘taak’ gekozen omdat dit beter aangeeft dat het gaat over uitvoeren van een werkeenheid. Een activiteit is wat dat betreft een vager begrip, terwijl een taak duidelijk gekoppeld is aan een doel. De in deze scriptie genoemde informatieprocessen worden door Schinkel werkprocessen genoemd, maar zoals eerder aangegeven richt deze scriptie zich enkel op de informatieprocessen binnen bedrijfsprocessen. Om dit onderscheid duidelijk naar voren te laten komen is voor een andere naamgeving gekozen. In de hoofdstukken 5 en 6 worden de laagste 3 procesniveaus gedetailleerd besproken met het oog op schermgeneratie. In de daaropvolgende hoofdstukken worden de hoogste 2 niveaus besproken met betrekking tot hoger niveau terugkoppeling op de gebruiker.

5.2 Informatiebehoefte voor schermgeneratie Om uiteindelijk schermgeneratie mogelijk te maken, moet de vraag gesteld worden welke informatie er nodig is om schermen te definiëren. Algemeen kan er gesteld worden dat een scherm een titel een inhoud heeft. De titel van het scherm geeft aan waar de inhoud van het scherm over gaat. De inhoud van een scherm wordt weergegeven middels controls. Een control is een grafisch element dat primair een waarde representeert en een gedrag specificeert. Daarnaast heeft een control ook eigenschappen die de grafische weergave bepalen, als een positie, kleur en een bepaalde volgorde. Deze grafische eigenschappen zijn wel van belang om een voor de gebruiker zo vriendelijk mogelijk scherm op te bouwen, maar vallen buiten de scope van het onderzoek. We zullen volstaan met een standaard patroon, waarin controls een bepaalde vastgestelde kleur krijgen, en een willekeurige volgorde en positie op het scherm. Middels uitlijning kan toch een werkbare interface gegenereerd worden. In de vraagstelling focussen we ons op de volgende principes: 1. Hoe beperken we de inhoud van het scherm tot de informatie die daadwerkelijk nodig is voor het uitvoeren van de taak die de gebruiker probeert uit te voeren? 2. Hoe zorgen we ervoor dat de schermen alleen toegang bieden tot de informatie die past bij de verantwoordelijkheden die de gebruiker heeft ten aanzien van de informatie? Om te weten wat een gebruiker op zijn scherm wenst, dus wat de inhoud van het scherm is, moet er duidelijk zijn welke informatie van de hele berg in de organisatie hij gebruikt in zijn dagelijkse werkzaamheden. Om hem niet met een hele waslijst aan informatie te bedienen is het wenselijk de informatie in delen op te splitsen, afhankelijk van zijn werkzaamheid op dat moment. Om vast te stellen welke informatie voor welke taak van belang is, moet een taakanalyse uitgevoerd worden. FCO-IM biedt hiervoor niet genoeg informatie, omdat deze slechts de structuur van gegevens modelleert en niet de afbakening. Deze gegevens moeten echter wel bekend zijn, en dienen dus gehaald te worden uit óf het procesmodel óf de organisatiestructuur. De processen bieden hiervoor uitkomst omdat hierin beschreven staat welke taken er uitgevoerd worden. In hoofdstuk 5.2.1 wordt besproken hoe dit gedaan kan worden. Het procesmodel wordt gebruikt om een duidelijke afbakening te krijgen op de informatiebehoefte voor een bepaalde werkzaamheid en voor de toewijzing van wie welke taak uitvoert. Het procesmodel wordt niet gebruikt om gebruikers te dwingen in een bepaalde volgorde waarin zij werkzaamheden uitvoeren. De flexibiliteit van gebruikers zou hiermee worden hiermee beperkt, en dat is niet het uitgangspunt. Tevens moet ervoor gewaakt worden dat het samenstellen van het model niet meer tijd gaat kosten dan het programmeerwerk voor dezelfde applicatie. In dat geval heeft generatie weinig toegevoegde waarde meer. Omdat informatie niet zomaar ontstaat in een organisatie, maar uit een informatiebehoefte van een bepaalde functie of taak, moet er aangegeven worden wie er verantwoordelijk is voor een bepaald deel van de informatie. Deze verantwoordelijkheid houdt in dat er alle Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

28/61

Master’s Thesis

rechten op deze informatie wordt verkregen. Een bespreking hiervan wordt in hoofdstuk 5.2.2 gedaan. Zoals er een hiërarchie geldt in de formele organisatiestructuur, geldt dat ook voor de informatiebehoeften van de functies die hier een rol in spelen. Door de controlerende rol van de hoger liggende functies in de organisatie is er een wens naar de informatie van lager gelegen rollen. Deze informatie wordt geëxtraheerd uit het organisatiemodel. Dit aspect wordt beschreven in hoofdstuk 5.2.3.

5.2.1 Informatieselectie Om de vraag “Hoe zijn de schermen afhankelijk van de taken, informatie, behoefte en kennis van de betreffende gebruiker?” te beantwoorden, zal er per taak bekeken moeten worden welk type informatie nodig is om deze uit te voeren, ofwel er zal een taakanalyse uitgevoerd moeten worden. Een taak bestaat uit logische werkeenheden: de bewerkingen. Een logische werkeenheid bevat een duidelijke afbakening wat betreft werkzaamheden. Het is dan logisch om de informatie af te bakenen op welke objecttypen danwel relaties vallen binnen het taakgebied. Deze afbakening kan per bewerking in de organisatie door de modelleur worden vastgelegd. Het zou echter handiger en consistenter zijn wanneer deze reeds uit de analysefase te abstraheren is. Om te komen tot een taakanalyse zal er duidelijk moeten worden welke bewerkingen er uitgevoerd worden. Een manier om hierachter te komen is door te kijken naar de documenten die ingevuld worden, omdat de bewerking van een document immers een logische werkeenheid is. FCO-IM gaat uit van feiten over het te modelleren domein. De feiten komen voort uit documenten, die in de organisatie gebruikt worden om te communiceren binnen en tussen de verschillende afdelingen en actoren. In de modelleringslag wordt echter niet bijgehouden welke feiten voortkomen uit welke documenten. Hierdoor is in een later stadium deze informatie geheel niet meer voorhanden. Dit kan gezien worden als een groot gemis. Deze documenten circuleren vaak al jaren in de organisatie en zijn daarom geoptimaliseerd op inhoud en functionaliteit. Het invullen van een document is een afgebakende hoeveelheid werk, essentieel voor de organisatie. Met het oog op schermgeneratie is het behouden van deze documenten van groot belang, omdat hiermee de taakanalyse gemaakt kan worden. Het document bevat immers een afgebakende hoeveelheid werk en informatie die uitgevoerd wordt door een bepaalde rol of binnen het kader van een functie in de organisatie. Dit geheel is een mooi uitgangspunt om te gebruiken als scherm. Een bijkomstigheid is dat de schermen zo herkenbaar zijn voor de gebruiker, omdat ze weten welke informatie in welk formulier te vinden is. Om deze documenten in het conceptuele model te bewaren zal de huidige FCO-IM methode uitgebreid moeten worden met een groepering die één of meer feittypen bevat. Een document kan dus gezien worden als een clustering van feittypen, waarbij een feittype zich in meerdere clusters kan bevinden. Een illustratie hiervan is gegeven in Figuur 18 : “Afbakening van feittypen naar de informatie die nodig is voor een bewerking”. Inschrijven van een student

Hu i sn u m m e r S tra a tn a a m

H u is n u m m e r

Plaats

Adre s Stude ntAdre s 6

7

8

O3

F2 : "< 6> woont op < 7> ." 1: 0229342 Schoolstr aat,1,Ar nhem

Stude nt S tu de n tNu m m e r

9

10

O3 : ' < 8> < 9> te < 10> ' 1: Schoolstr aa 1

O1

da g

O4

11

S tra a tn aa m Pl a a ts n a am

Stude ntAdre s 6

8

O3

15

16

O6

O1 F4 : "< 15> is g ebor en op <16> ." 1: 0229342 05,09,1979

3 0229342

O1

17

18

1: Schoolstraa

Stude nt

1979

naam

Stude ntNaam 1

2

O2

F1 : "< 1> heet < 2> ." 1:

4

S tu de n tN u m m e r

3

O1

O2 : ' <4> < 5>'

0229342 Ar noud,van Ber s

1:

Ar noud

O6

O1 F4 : "< 15> is g ebor en op < 16> ." 1: 0229342 05,09,1979

O1 : 'student < 3>' 1: 0229342

5

16

17

2

O2

4

0229342

VWO

Ach te rn a a m

Voo rople iding

vo o ro ple i di n gs n a a m

Stude ntVo orople iding

O5 : ' voor opleiding < 14> ' 1:

van Bers

Vo o rn a a m

Voorople iding 14

5

O2 : '< 4> <5> ' 1: Arnoud

Stude ntVooro ple iding

1:

19 1979

O1

Ach te rn a a m

F3 : "< 12> heeft < 13> ."

18

naam

Stude ntNaam 1

O5

Pl a a ts n a a m

Arnhem

ja a r

O6 : '< 17> -< 18> - < 19> ' 1: 09 05

F1 : "< 1> heet <2> ." 1: 0229342 Arnoud,van Bers

Vo o rn a a m

13

m aan d

1:

van Ber s

O1

12

11 O4 : ' <11>'

Ar nhem

Datum

Stude ntGe boo rte Datum 15

O4

10

1

da g

19

O6 : ' <17>- < 18> -< 19> ' 1: 05 09

9

O3 : '< 8> < 9> te <10>'

O1

O1 : ' student < 3> ' 1:

7

F2 : "< 6> woont op < 7> ." 1: 0229342 Schoolstraat,1,Arnhem

ja a r

Datum

Stude ntGe boorte Datum

Plaats

Adre s

O4 : '< 11> ' 1: Arnhem

Arnhem

m aan d

VWO

12

13

F3 : "< 12> heeft < 13> ." 1:

O5

0229342

VWO

O5

vo o ro pl e idi n g s n a a m

14 O5 : 'vooropleiding <14>' 1:

VWO

Vak Voorople iding Vak ke n 20

21

F5 : "<20> bevat het <21> ." 1:

VWO

Wiskunde B

O7

O5

22

Vak

Vak n aam

O7 : 'vak < 22> '

Voo rople idingVakk e n

1: Wiskunde B

20

21

F5 : "< 20> bevat het < 21> ." 1:

VWO

Wiskunde B

O7

22

Va k n a a m

O7 : ' vak <22> ' 1: Wiskunde B

Figuur 18 : “Afbakening van feittypen naar de informatie die nodig is voor een bewerking” Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

29/61

Master’s Thesis

Naast het bijhouden van de bewerking waaruit de informatie is ontstaan, zal er nog bijgehouden moeten worden welke personen, rollen of taken betreffend document behandelen. Door dit te doen wordt het informatiegebied ingeperkt voor die groep. Dat is niet alleen prettig voor de gebruiker, maar ook kan op deze manier de beveiliging van gegevens beter en automatisch geregeld worden. Op toegangsaspecten wordt in paragraaf 5.3.3 ‘Toegang’ verder ingegaan.

5.2.2 Eigenaren / verantwoordelijken van informatie Binnen een organisatie is het vaak zo dat een medewerker of groep van medewerkers eigenaar van een stuk informatie is. Zo worden bijvoorbeeld de adressen van de medewerkers bijgehouden door de afdeling P&O. Zij zijn verantwoordelijk voor het bijwerken van de gegevens en kunnen er op aangesproken worden wanneer deze onjuist zijn. Voor deze groep is deze informatie van groot belang. Voor de generatie van de schermen voor deze groep heeft het daarom tevens impact. Om dit te kunnen modelleren zal het FCO-IM metamodel uitgebreid moeten worden zodat bij ieder feittype een eigenaar kan worden aangegeven, waarbij een eigenaar wederom een rol, groep of taak kan zijn. Een voorbeeld hiervan is gegeven in Figuur 19: “Verantwoordelijken van informatie in FCO-IM” op de volgende pagina. Huisnum m er S tra at n aa m

Plaats

A dre s Stude ntA dre s 6

7

da g

15

3

1:

O1 : ' student < 3> ' 1: 0229342

O1

16

O6

Pl a ats n a am

17 1:

2

jaa r

18

05

19

09

1979

naam

Stude ntN aam 1

m aa n d

O6 : ' < 17> -< 18> -< 19> '

0229342 05,09,1979

O2

F 1 : "< 1> heet < 2> ." 1:

11 O4 : '< 11> ' 1: Arnhem

Arnhem

D atum

Stude ntGe bo o rte D atum O1 F 4 : "< 15> is g eboren op <16> ."

S tu de n tN u m m e r

O4

10

0229342 Schoolstr aat,1,Arnhem

O1

Stude nt

9

O3 : '< 8> < 9> te <10>' 1: Schoolstr aa 1

F 2 : "< 6> woont op <7>." 1:

8

O3

4

5

O2 : ' < 4> < 5> '

0229342 Arnoud,van Bers

1:

Ar noud

van Bers

O1

Vo orn a a m Ach te rn aa m

Vo o ro ple iding Stude ntVo o ro ple iding 12

13

F 3 : "< 12> heeft < 13> ." 1: 0229342 VWO

O5

14

vo oropl e i di n gs n a am

O5 : ' voor opleiding < 14>' 1: VWO

O5

Vak Vo o ro ple iding Vak k e n 20

21

F 5 : "< 20> bevat het < 21>." 1: VWO Wiskunde B

O7

22

Vak n a am

O7 : ' vak < 22> ' 1: Wiskunde B

Figuur 19: “Verantwoordelijken van informatie in FCO-IM”

Het probleem dat zich voordoet is dat constraints op het informatiemodel bepaalde actor toewijzingen kunnen tegenhouden. Een voorbeeld hiervan zijn totaliteitsconstraints (TC’s). TC’s dwingen af dat de populatie van een bepaald feittype niet leeg mag zijn. Stel dat in het voorbeeld in Figuur 19: “Verantwoordelijken van informatie in FCO-IM” de rollen van StudentAdres een TC hebben op Student, dan houdt dit in dat een student altijd een adres moet hebben. Wanneer degene die eigenaar is van Student geen eigenaar is van StudentAdres, dan kan er nooit een nieuwe student met onbekend adres toegevoegd worden, omdat de eigenaar van Student geen recht heeft om een nieuw adres aan te maken (er kan wel een student toegevoegd worden die samenwoont met een reeds ingeschreven student). Dit is wel vereist is volgens de constraints. Er wordt dus opgemerkt dat constraints leidend zijn in dit proces. De generator zal hiervan bewust moeten zijn en een probleem moeten signaleren met een voorstel over een mogelijke oplossing.

5.2.3 Hiërarchische Rollen Zoals in de te modelleren organisatie mensen formulieren die met hun werkzaamheden te maken hebben invullen en verwerken, zullen in het informatiesysteem mensen tevens Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

30/61

Master’s Thesis

slechts geïnteresseerd zijn in de informatie die voor hen van belang is en dus een relatie heeft met het werk dat ze worden geacht uit te voeren. De bewerkingen die in de vorige paragraaf aangegeven zijn, worden in de organisatie uitgevoerd door medewerkers die een bepaalde positie in deze organisatie innemen, afhankelijk van hun functie of rol (zie paragraaf 3.3 ‘Organisatiemodellering’). Voor de modelvorming zijn we vooral geïnteresseerd in het minst veranderlijke van de organisatie. Als de structuur van een organisatie zo abstract mogelijk en met die denkwijze bekeken wordt, dan resulteert dat in een indeling in functies. Voor bedrijfsprocessen of informatie is het niet van belang wie de uitvoerende persoon is, maar slechts de functie die deze persoon op dat moment bekleedt. Of de directeur nou Frits of Deny heet, is ondergeschikt aan het feit dat hij directeur is en dus over betreffende informatie kan en wil beschikken. Zodoende wordt de formele functiestructuur van de organisatie in kaart gebracht, zodat hieruit de functionele indeling van actoren van het informatiesysteem te distilleren is. Zoals in organisaties vaak geconstateerd wordt, heeft de bovenliggende functie in het organogram een controlerende functie. Dit betekent dat deze functie naast zijn eigen werkzaamheden en informatiebehoeften ook de beschikking moet hebben over de informatie waartoe de onderliggende functies toegang hebben. Dit heeft voor schermgeneratie het gevolg dat er een onderscheid gemaakt wordt tussen controlerende en uitvoerende werkzaamheden.

Directeur

Hoofd Onderwijs

Hoofd Ondersteunende Diensten

Docent

Studenten Administratie

Student

Baliemedewerker

Organisatiestructuur School

Figuur 20: “Formele organisatiestructuur”

5.3 Koppelen van werkzaamheden aan informatie In 5.1 Niveaus van Processen wordt duidelijk gemaakt welke verschillende niveaus van processen erkend worden binnen een organisatie. Omdat de interesse slechts uitgaat naar de processen die over informatie gaan, de informatieprocessen, moet er een koppeling worden gemaakt tussen de feiten (informatie) en de acties hierop (proces). Het onderste niveau van processen is de elementaire handeling. Een elementaire handeling kan gezien worden als het veranderen van de populatie van precies één feit van het domein, oftewel een create, retrieve, update of delete van een object of relatie. In het voorbeeld van het inschrijfformulier in Figuur 18 : “Afbakening van feittypen naar de informatie die nodig is voor een bewerking”’ kan een elementaire handeling het wijzigen van de woonplaats van een student zijn, omdat er een elementair feit ‘StudentWoonplaats’ over het domein is dat zegt: ”Student Arnoud van Bers woont in Arnhem” Een bundeling van elementaire handelingen maakt samen een bewerking. Een voorwaarde aan deze bundeling is dat er een objecttype als beginpunt is waaraan alle objecten via relaties op eenduidige wijze verbonden zijn. Dit is noodzakelijk omdat het uitgangspunt van een bewerking een enkele instantie van een object is, waaraan alle andere gegevens gerelateerd zijn (boomstructuur).

Adres 3

13

7

14

O4 : '<13> nr <14>'

9 O4

12

11

F3 : "<11> woont op de <12>."

1: Schoolstraa 123

Student

StudentAdres

1: Schoolstraa Schoolstraa0229342 0229342

O1

1

2

StudentVooropleiding 5

3 O1 : 'student <3>' 1: 0229342

8 O1

17

18

F5 : "<17> heeft als <18>." 1: 0229342 Hogere Informatica

O5

Vooropleiding 9

19 O5 : 'vooropleiding <19>' 1: Hogere Informatica 2: VWO

Vak

VooropleidingVakken

11

13 O5

20

12 O6

21

F6 : "<20> bevat het <21>." 1:

VWO

Wiskunde B

22 O6 : 'vak <22>' 1: Wiskunde B

Figuur 21: “In een bewerking moeten alle objecten via relaties bereikbaar zijn” Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

31/61

Master’s Thesis

De elementaire handelingen: ingeven van studentnummer, woonplaats, adres en vooropleiding maken samen de bewerking ‘invullen inschrijfformulier’.

5.3.1 Soorten handelingen Op het informatiedomein kennen we verschillende soorten handelingen. We onderscheiden de handelingen ‘opvragen’, ‘invoeren’, ‘wijzigen’ en ‘verwijderen’ van de populatie van een feit in het domein. Enkele hiervan zijn van elkaar afhankelijk: Zo is er bijvoorbeeld geen mogelijkheid om gegevens te wijzigen of verwijderen als je de gegevens niet eerst opgevraagd hebt. Voor invoeren geldt deze beperking niet per definitie, omdat bijvoorbeeld nieuwe studenten in te schrijven zijn zonder dat de bestaande studenten opgehaald zijn. Voor het opvragen en wijzigen van instanties van feittypen zijn er geen afhankelijkheden met andere feittypen die van belang zijn voor het uitvoeren van de handeling. Invoeren en verwijderen zijn gecompliceerder omdat hier het relationele karakter opspeelt. Het is niet zonder meer toegestaan een nieuw element in de populatie van een feittype te zetten, omdat het afhankelijk kan zijn van andere feittypen. Hier zal verder op ingegaan worden in paragraaf 5.3.2. Een samengestelde handeling, de bewerking, bestaat altijd uit meerdere elementaire handelingen en is dus altijd deelbaar.

5.3.2 Constraints op bewerkingen Door het relationele karakter van het conceptuele datamodel zitten er enkele beperkingen op de toegestane handelingen binnen een bewerking. Zo zijn er feiten die verplicht ingevuld moeten worden, voordat een bewerking compleet is. Een voorbeeld hiervan is een totaliteitsconstraint op een rol in het datamodel. Deze constraint geeft aan dat deze rol ingevuld moet zijn voor een bepaald object. Tevens geeft een totaliteitsconstraint aan dat het feit onlosmakelijk verbonden is met een objecttype. achternaam

StudentNr

StudentNummer

Student 1

2

3

4

O1 : 'student <3> <4>' 1: Arnoud van Bers

1

O1

1

2

F1 : "<1> heeft studentnr <2>." 1: Arnoud,van0229342 Arnoud,van0229342

voornaam

Figuur 22: “FCO-IM Voorbeeld”

Wanneer Figuur 22: “FCO-IM Voorbeeld” als voorbeeld wordt beschouwd, dan geeft de totaliteitsconstraint aan dat een studentnummer niet leeg mag zijn voor een student. De bewerking kan dus niet alleen Student beslaan, maar moet tevens Studentnummer behandelen. Een andere constraint op een bewerking is dat de identificerende rollen van de combinatie van feiten altijd ingevuld en uniek moeten zijn. Dit wordt in het datamodel vastgelegd met uniciteitsconstraints. We concluderen dat een bewerking van een objecttype minstens de handelingen bevat van zijn identificerende rollen plus de unieke rollen van zijn verbonden feiten via totaliteitsconstraints.


32/61

Master’s Thesis

5.3.3 Toegang Voor de organisatie is het van belang gegevens met voorzichtigheid te behandelen. De organisatie is verplicht te voldoen aan de Wet Bescherming Persoonsgegevens [WBP01], die ervoor zorgt dat persoonlijke gegevens niet voor zomaar iedereen toegankelijk mogen zijn, en vertrouwelijk behandeld moet worden. Behalve dit is het voor de organisatie ook niet handig als bepaalde interne gegevens op straat komen te liggen, bijvoorbeeld wanneer de organisatie zich in een onderhandelingspositie bevindt. Communicatie naar de buitenwereld zal dus goed geregeld moeten zijn. Ook intern in de organisatie zal beveiliging een grote rol moeten spelen. Stel je voor dat iedere medewerker persoonlijke gegevens, zoals ziekten van zijn collega’s kan bekijken, of dat de salarissen door iedere medewerker muteerbaar zouden zijn. Om deze problemen vanaf de wortel aan te pakken kan er reeds in de analysefase bekeken worden welke informatie aan wie toebehoort. Hiervoor worden verschillende typen actoren onderscheidden: De eigenaar van een stuk informatie heeft het recht om te bekijken, invoeren, wijzigen en verwijderen; Een gebruiker heeft slechts het recht om gegevens te bekijken. Later kunnen er eventueel meerdere actortypen toegevoegd worden, maar deze set is voor het aantonen van het principe voldoende. Er zal ook weinig toepassing gevonden worden in een actortype dat slechts kan invoegen of een actortype dat slechts kan wijzigen: het zou dan namelijk niet mogelijk zijn om gegevens te bekijken en/of om fouten te herstellen. Een conclusie hieruit is dat bepaalde rechten van elkaar afhankelijk zijn. De mate van recht hebben op bepaalde informatie wordt tevens bepaald door de positie die een gebruiker inneemt in de organisatie, zoals toegelicht in paragraaf 5.2.3. De bovenliggende posities in de organisatiestructuur bezitten een controlerende rol. Hierbij horen de rechten om de aan lagere posities toegekende informatie in de gaten te houden. Door middel van de organisatiestructuur is dus de rechtenstructuur in de applicatie te genereren.

5.4 Navigatie Met het oog op schermgeneratie is er een duidelijke weg nodig binnen het conceptuele model. Deze informatie is niet uit de deelgebieden processen, informatie en organisatie te halen, en zal dus toegevoegd moeten worden. Student

Vooropleiding

StudentVooropleiding

2

8

3 O1 : 'student <3>' 1: 0229342

5

O1

11

17

18

F5 : "<17> heeft als <18>." 1: 0229342 Hogere Informatica

O5

9

19

O5 : 'vooropleiding <19>' 1: Hogere Informatica

Figuur 23: “Voorbeeld van het navigatieprobleem”

Als Figuur 23: “Voorbeeld van het navigatieprobleem” wordt beschouwd als een schermdefinitie, dan kan er niet bepaald worden of een gebruiker de studenten per vooropleiding wil bekijken of de vooropleidingen per student. Op de oplossing van dit probleem kunnen verschillende views bestaan, ieder met hun eigen voor- en nadelen. Een oplossing voor dit probleem kan zijn dat de gebruiker zelf kiest welke van deze varianten hij/zij wil gebruiken. Wanneer de gebruiker het scherm opstart krijgt hij een keuze uit de objecttypen, waarna de andere gerelateerde gegevens zich hierop verbinden. Bijvoorbeeld: de gebruiker kiest voor het object ‘Vooropleidingen’. Het scherm met vooropleidingen klapt open waarna de gebruiker door de vooropleidingen kan lopen en van iedere vooropleiding kan zien welke studenten deze vooropleiding hebben genoten. Deze


33/61

Master’s Thesis

methode kan bewerkstelligd worden met Query-by-Navigation [Pro94b] en Point-to-Point queries [Pro94a]. Deze technieken bouwen een boomstructuur in het conceptuele schema op. Door een objecttype op te geven dat centraal staat in de informatievraagstelling kunnen de feittypen die hiermee in verbinding staan de richting aangeven waarin de vraagstelling verder gedetailleerd kan worden. Wanneer in het voorbeeld uit Figuur 27: “Conceptueel diagram met bewerkingen” bijvoorbeeld ‘vooropleiding’ gekozen wordt, is de enige manier om verder te detailleren via StudentVooropleiding naar Student. Vanuit Student kan er naar woonplaats, geboortedatum en adres worden genavigeerd. Zo kan er bijvoorbeeld gemakkelijk de query gevormd worden die de vooropleidingen van de student die in een bepaalde woonplaats woont. Op deze manier wordt de informatiewens steeds gedetailleerder totdat er een bevredigend resultaat is bereikt. Hoewel de gebruiker binnen het domein van een formulier makkelijker zal navigeren dan binnen het gehele conceptuele model van de organisatie, zal er toch veel kennis van de gebruiker gevraagd worden over de structuur van de informatie. Aan de andere kant biedt het specificeren van de informatievraag door de gebruiker geweldige mogelijkheden om de juiste informatie op te zoeken wanneer er niet vooraf bekend is waarop gezocht zal moeten worden. Een vereiste is wel dat de objecten feittypen goede benamingen hebben gekregen, om zo de begrijpbaarheid te waarborgen (en de gebruiker herkenbaarheid biedt). Een nadeel is de tijd die het vergt om bij iedere informatievraag de query opnieuw op te bouwen. Bij een vaste informatievraag zal er dus een andere oplossing gebruikt moeten worden. Inschrijven Student

Adres 1..n

H u is n um m e r S tra a tn a am

Plaats

Adre s Stude ntAdre s 6

7

8

O3

1: Schoolstraa

O1

Stude nt S tu de n tNu m m e r

9

dag

15

16

O6

O1 F4 : "<15> is g eboren op < 16>." 1: 0229342 05,09,1979

O1 : 'student <3>' 1: 0229342

O1

2

Arnhem

m a an d

1:

Pl aa ts n a am

17

18

19 1979

1

1 1 1 1

naam O2

F1 : "<1> heet < 2> ." 1: 0229342 Ar noud,van Bers

Datum

Arnhem

ja a r

O6 : '<17> -< 18>-< 19>' 1: 05 09

Stude ntNaam 1

11 O4 : '<11> '

1

Datum

Stude ntGe boorte Datum

3

O4

10

O3 : '<8> <9> te < 10>'

F2 : "<6> woont op < 7> ." 1: 0229342 Schoolstraat,1,Arnhem

4

Naam

Student

1

5

O2 : '<4> <5>' 1: Arnoud

van Bers

O1

Voo rna a m

Vooropleiding

Achte rn a am

1..n

Voorople iding Stude ntVoorople iding 12

13

F3 : "<12> heeft < 13>." 1: 0229342 VWO

O5

14

voo rople idi ng sn a a m

O5 : 'vooropleiding <14> ' 1: VWO

O5

Vak Voorople idingVakke n 20

21

F5 : "<20> bevat het < 21>." 1:

VWO

Wiskunde B

O7

22

Va kn a am

O7 : 'vak < 22>' 1: Wiskunde B

Figuur 24: “Bouwen van een navigatiestructuur op basis van het conceptuele diagram"

Voor de hand ligt dan de tweede oplossing waarin het pad van de informatiebehoefte in het conceptuele model reeds vastgelegd wordt bij het modelleren van de bewerking. Zoals de bewerking reeds in gebruik is in de organisatie kan deze vastgelegd worden in het conceptuele diagram. Het voordeel hiervan is dat de informatie binnen het vastgelegde kader snel boven water komt, waarbij minder kennis van de gebruiker over het model wordt vereist. Hier tegenover staat de beperking in flexibiliteit en de extra tijd en moeite die het kost om de queries reeds in de analysefase boven water te halen. Dit laatstgenoemde minpunt kan in een derde oplossing teniet worden gedaan, wanneer de generator zelf de informatievolgorde kan voorspellen, waardoor tijd en moeite wordt bespaard in de analyseslag. De basis van deze voorspelling vormt een gedegen formulering van de expressies die leiden tot het conceptuele diagram. Wanneer de zinnen altijd in actieve vorm worden geschreven, dan kan via een taalkundige analyse een volgorde worden bepaald. Als Figuur 23: “Voorbeeld van het navigatieprobleem” beschouwd wordt, dan geeft de feitexpressie ‘Student Arnoud van Bers heeft als vooropleiding Hogere Informatica’ aan, dat vooropleiding een eigenschap is van een student. Dit komt doordat de Student het onderwerp is en Vooropleiding het lijdende voorwerp. Door middel van een taalkundige analyse, zoals voor objectgeoriënteerde ontwikkeling reeds is toegepast [Fre97], is het mogelijk schermen te definiëren zoals ze hoogstwaarschijnlijk ook zijn bedoeld door de


34/61

Master’s Thesis

modelleur. Het nadeel blijft wel dat het resultaat een vaste definitie is in plaats van een dynamische, zoals in de eerste oplossing.

5.5 Voorgestelde Analysemethode Om de extra informatie in het analyse traject mee te nemen zal een werkwijze voorgesteld worden. Met deze werkwijze zal er, zonder veel extra input, een completer model van de organisatie gevormd worden, waar tevens handelingen en bewerkingen in meegenomen zijn. Om het geheel duidelijk in beeld te krijgen zal er een simpele voorbeeldcasus gebruikt worden. Allereerst wordt er, net zoals dit gedaan wordt met FCO-IM, geïnventariseerd welke documenten van belang zijn binnen het te modelleren domein. Als voorbeeld wordt het inschrijftraject voor een opleiding genomen. Als documenten worden een inschrijfformulier en een collegekaart gevonden, die dit domein representeren. Inschrijfformulier Naam:

Naam:

Arnoud van Bers

Straatnaam,Huisnr: Schoolstraat 123

Arnoud van Bers StudentNr:

Woonplaats: Arnhem

0229342 Geboortedatum: 05-09-1979

Geboortedatum: 05-09-1979

Vooropleiding: Hogere Informatica

Figuur 25: “Voorbeeld: Collegekaart”

Figuur 26: “Voorbeeld: Inschrijfformulier”

Zoals verwacht komen veel van de gegevens overeen, wat voortkomt uit het feit dat na inschrijving een collegekaart wordt gemaakt op basis van de gegevens op het inschrijfformulier. Eerst wordt de collegekaart beschouwd, waaruit blijkt dat de informatie gaat over een student. Navraag aan een domeinexpert levert op dat een student uniek getypeerd wordt door zijn studentnummer. Vanuit de collegekaart komen dan de volgende feiten over het domein naar boven: 1. Student 0229342 heet Arnoud van Bers; 2. Student 0229342 is geboren op 05-09-1979; Als het inschrijfformulier beschouwd wordt, dan worden de volgende additionele feiten over hetzelfde domein gevonden: 3. Student 0229342 woont op de Schoolstraat nr 123 te Arnhem; 4. Student 0229342 heeft vooropleiding VWO. Als deze informatie geclassificeerd en ingevoerd wordt in een FCO-IM CASE-tool dan wordt Figuur 27: “Conceptueel diagram met bewerkingen” verkregen. Huisnummer Straatnaam Huisnum mer

Plaats

Adres Stude ntAdres 6

7

8

O3

F2 : "<6> woont op <7>." 1: 0229342 Schoolstraat,1,Arnhem

16

Stu de ntNumme r

O6

Plaatsnaam

maand

17

18

1:

05

09

1

2

O2

4

Student

1979

9

dag

15

16

O1

2

maand

11

Plaatsnaam

jaar

18

19

O6 : '<17>-<18>-<19>' 1: 05 09

17

1979

naam

Stude ntNaam 1

van Bers

Arnhem

O4 : '<11>' 1: Arnhem

Datum

O6

O1 F4 : "<15> is geboren op <16>." 1: 0229342 05,09,1979

3 O1 : 'student <3>' 1: 0229342

O4

10

O3 : '<8> <9> te <10>' 1: Schoolstraa 1

StudentGe boorteDatum

5

O2 : '<4> <5>' 1: Arnoud

F1 : "<1> heet <2>." 1: 0229342 Arnoud,van Bers

8

O3

O1

19

naam

StudentNaam

7

F2 : "<6> woont op <7>." 1: 0229342 Schoolstraat,1,Arnhem

jaar

Stude ntNum mer O1

Plaats

Adres Stude ntAdres

O6 : '<17>-<18>-<19>'

1: 0229342 05,09,1979

3 O1 : 'student <3>' 1: 0229342

11 O4 : '<11>' 1: Arnhem

Datum

StudentGeboorteDatum 15

Arnhem

Straatnaam

6 dag

O1 F4 : "<15> is geboren op <16>."

10

O3 : '<8> <9> te <10>' 1: Schoolstraa 1

O1

Student

9

O4

O2

4

5

O2 : '<4> <5>' 1: Arnoud

F1 : "<1> heet <2>." 1: 0229342 Arnoud,van Bers

van Bers

O1

Voorn aam

O1

Voornaam

Achtern aam Achternaam

Vooropleiding

Vooropleiding


13

F3 : "<12> heeft <13>." VWO 1: 0229342

O5


vooropleidingsn aam

O5 : 'vooropleiding <14>' 1: VWO

12

13

F3 : "<12> heeft <13>." 1: 0229342

VWO

O5

14 O5 : 'vooropleiding <14>' 1:

voorople idingsnaam

Collegekaart

VWO

Inschrijfformulier

Figuur 28: “Conceptueel FCO-IM diagram” Figuur 27: “Conceptueel diagram met bewerkingen” Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

35/61

Master’s Thesis

Door te achterhalen wie welke documenten in handen krijgt, is het mogelijk gebruikersgroepen toe te wijzen die iets met deze informatie van doen hebben. De gebruikersgroepen halen we uit de analyse van de organisatiestructuur. Voor dit voorbeeld is de structuur weergegeven in Figuur 29: "Voorbeeld Organogram". Een koppeling van actoren aan de documenten levert Figuur 30: “Actoren per bewerking” op: Studenten mogen hun collegekaart bekijken en het inschrijfformulier invullen. Het inschrijfformulier wordt tevens gebruikt door de baliemedewerker en de studentenadministratie voor verdere verwerking.

Directeur

Hoofd Onderwijs

Hoofd Ondersteunende Diensten

Docent

Studenten Administratie

Student

Baliemedewerker

Organisatiestructuur School

Figuur 29: "Voorbeeld Organogram"

Naast het aangeven van de actoren die een bewerking uitvoeren, kan er aangegeven worden wat voor soort bewerkingen deze actoren uitvoeren. Zo voeren studenten geen bewerkingen uit op hun collegekaart, maar zullen ze deze enkel bekijken (om bijvoorbeeld op correctheid te controleren). Op het inschrijfformulier voeren zij wel een actie uit, namelijk de ‘invoer’bewerking. Hetzelfde proces wordt herhaald voor de andere actoren. Uiteindelijk levert het Figuur 30: “Actoren per bewerking” op. B

I

S

Student

Baliemedewerker

S

S

Selecteren

I

Invoeren

B

Bewerken

V

Verwijderen

I

Student

B V

StudentenAdministratie Collegekaart

Inschrijfformulier

Figuur 30: “Actoren per bewerking”

Actoren kunnen, behalve aan bewerkingstypen, ook aan feittypen worden toegewezen. Dit geeft aan dat ze verantwoordelijk zijn voor die informatie. Dit werkt op dezelfde manier als hierboven, alleen hoeft er dan geen bewerkingssoort aangegeven te worden omdat verantwoordelijkheid altijd impliceert dat het toegestaan is alle bewerkingen uit te voeren.


36/61

Master’s Thesis

6 Evolutie van het FCO-IM metamodel De in hoofdstuk 5 “Conceptuele Specificatie van het Onderzoeksgebied” beschreven uitbreidingen op FCO-IM zullen in het metamodel opgenomen moeten worden. Vanuit dit metamodel zal het in een later stadium mogelijk zijn om via een transformatie te komen tot het metamodel dat schermgeneratie mogelijk maakt. In dit hoofdstuk zal ingegaan worden op de benodigde veranderingen aan de FCO-IM Repository, het metamodel, die het mogelijk maken de in hoofdstuk 5 voorgestelde veranderingen door te voeren.

6.1 Huidige Repository In Bijlage D “FCO-IM Repository” is het interne conceptuele schema van FCO-IM weergegeven. Omdat dit schema zonder extra toelichting geen duidelijkheid geeft zullen hier enkele belangrijke elementen toegelicht worden. Als voorbeeldfeit StudentWoonplaats: “Student Arnoud van Bers woont in Arnhem” beschouwd wordt, dan wordt deze gehele zin een expressie genoemd. Na classificatie van deze expressie worden de objecten Student en Woonplaats gevonden, waarbij Student geïdentificeerd wordt door zijn voornaam en achternaam, terwijl woonplaats wordt geïdentificeerd door de plaatsnaam. Voornaam, achternaam en plaatsnaam worden rollen genoemd, die zich bevinden in delen van een expressie, de zogenaamde delen van een expressie (expression parts). Een voorbeeld van dit geheel • Expression: StudentWoonplaats • ExpressionParts: <3> woont in <4> • Rollen: 3: StudentWoonplaats, Student 4: StudentWoonplaats, Woonplaats 5: Student, voornaam 6: Student, achternaam 7: Woonplaats, plaatsnaam

6.2 Uitbreiding Repository Om de afbakening van bewerkingen uit hoofdstuk 5.2.1 ‘Informatieselectie’ mee te nemen in de repository, zal bekeken moeten worden wat zij nu precies bevatten als inhoud. Is het zo dat een bewerking een verzameling van rollen, van feiten of van deelfeiten beslaat? Zoals eerder opgemerkt is een elementaire handeling het behandelen van een feit. Omdat een bewerking een bundeling van elementaire handelingen is, werkt het ook op meerdere feiten. Feiten worden veralgemeniseerd in het metamodel door expressies. De conclusie is dus dat een bewerkingstype een handeling is op een verzameling van expressies op metaniveau. In het metamodel wordt tevens de Actor ingevoerd, die geplaatst kan worden in zowel een formeelhiërarchische structuur als in een functionele structuur. In de formele structuur staat zijn plaats in de organisatie vast: wie moet er aan hem verantwoording afleggen en aan wie moet hij verantwoording afleggen. In de functionele structuur kan een indeling bestaan gebaseerd op afdelingen, locaties of businessunits. Hierin bestaat een structuur waarin decompositie een belangrijke rol speelt. Zo kan bijvoorbeeld een indeling ‘Office’ de groep ‘Sales’ bevatten. De eenheid waar een actor zich in bevindt, kan bevoegd zijn bewerkingen uit te voeren, die in het metamodel wordt weergegeven als Task. Ook kan deze groep eigenaar zijn van feiten over het domein, weergegeven als InformationOwner. Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

37/61

Master’s Thesis

Het resultaat hiervan is onderstaande uitbreiding op het FCO-IM metamodel uit Bijlage D “FCO-IM Repository”. Subject

TaskSubject 78

79

126

O42

127

F69 : "Task <126> has <127>." 1: Administrat Person

O36

Unit

O31 : 'f unctional group <101>' O33 : 'f ormal role <101>' O38 : 'Formal role <101>' 1: Administration 2: Director 3: employ ee 4: administrator 5: business unit 6: Administrator

Organisation 72

107

O30

108

O31 :F64 O33, O38:O36

112 F64 O36 1: 2: 3: 4:

113

O31

: "<112> executes <113> on <114>." : '<112> executes <113> on <114>' Appliance Administra Add Appliance Administra Add Administra Mutate Appliance O35 Applicance Administra Add

63

99

71 O29

O29 : 'actor <99>' Jan 1:

97 33

60 O30

98

F59 : "<97> participates in <98>." 1: Jan Administration

O29

100 O30 1: 2: 3:

70

Actorname

102

115

MutationType

O32

F3 : "<4> is a f act ty pe." O4 : 'f act ty pe <4>' O6 : '<4>' 13

Origin 67

109

Formal Role

O4 FTE - FT

110

36

37

InformationOwner

O32 : '<104>' 1: Director 2: employ ee 38

O32

116

117

F65 : "<116> is owner of <117>." Supervisor F,1 1: Administra

105

106

58

12 FTE *

32 O16

50

57

F36 : "<57> belongs to <58>." O17

31 Expression

69

68

103

F60 : "<102> has <103>." 1: Jan Director

4

{ ADD, MUTATE, REMOVE, SEE }

F63 : "<109> contains <110>." 1: Appliance F,1 O16

O32

ActorRole

3

5

65

104

: '<100>' Administration administrator business unit

2

O34

Mutation

O33

61

111

O34 : 'source <111>' 1: Appliance 2: Applicance 32

O35 : 'mutation <115>' 1: Add 2: Mutate 39 Functional Group 40

F4 : "<5> is an object ty pe." O3 : 'object ty pe <5>' O13 : '<5>' Person 1:

FT *

O31

ActorParticipation

5

64

34

O30

Actor

35

O34

114

36

F62 : "<107> is part of <108>." 1: administratb business usiness unit

4

Source

66

101

unitName

OT *

Sourcename

Task

62

128 O42 : 'subject <128>' 1: Person O13

34 Exp _

O16

51

F32 : "There is an expression ty pe <50><51>." O16 : 'expression <50><51>' 1: f 1 2: F 1

55 F34 : "<55> is a f act ty pe expression." O17 : 'f act ty pe <55>'

F61 : "<105> has as superv isor <106>." 1: employ ee Director

*extra constraint: het Subject van een Task moet zich bevinden in de expressies van de Source Figuur 31: “Uitbreiding op het FCO-IM metamodel”

In bovenstaand model behoort iedere feittype-expressie tot minstens één clustering van gegevens die behandeld worden in een bewerking (Source). Deze bundeling van gegevens kan worden gebruikt in meerdere bewerkingen (Task). Iedere bewerking heeft via de navigatiegraaf een startpunt (Subject). Dit startpunt is een objecttype dat in een van de expressies zit van de cluster van een bewerking. Een bewerking wordt uitgevoerd door een actor, in danwel een formele positie of een functionele positie. Een actor kan tevens eigenaar zijn van een feittype-expressie. Op basis van het verkregen metamodel kan een meer procesgerichte generatie van schermen bewerkstelligd worden.


38/61

Master’s Thesis

7 Schermgeneratie op basis van het organisatiemodel In het vorige hoofdstuk is een techniek beschreven waarmee, zonder veel extra inspanning tijdens de analysefase, het mogelijk is om meer procesgerichte gegevens vast te leggen over de organisatie. Hiervoor is een metamodel voorgesteld als uitbreiding op de FCO-IM repository, waardoor het mogelijk moet zijn om schermgeneratie beter af te stemmen op de werkzaamheden van de gebruikers. In dit hoofdstuk zal dieper ingegaan worden op het proces dat zich afspeelt na het afronden van de analysefase. Van het informatiegedeelte uit het metamodel zal een tabelstructuur gegenereerd worden; de combinatie van het informatiegedeelte en de voorgestelde uitbreiding zal gebruikt worden voor de schermdefinities. In hoofdstuk 7.1 zal aangegeven worden dat bij de omzetting van een conceptueel model naar het logisch model de extra organisatie-informatie niet verloren gaat in het proces. In 7.2 wordt algemeen, en in 7.3 gedetailleerd, ingegaan op het generatie algoritme vanuit het organisatiemodel naar schermdefinities. In hoofdstuk 7.4 wordt beschreven hoe met behulp van het metamodel een hoger niveau van feedback kan worden gegeven aan de gebruiker. In hoofdstuk 7.5 tenslotte wordt een totaaloverzicht van de mapping tussen de verschillende niveaus uit 5.1 “Niveaus van Processen” gegeven.

7.1 Naar het logisch model Wanneer het voorbeeld uit hoofdstuk 5.5 geïmplementeerd dient te worden, dan zal er van het conceptuele model een logisch model gemaakt moeten worden waarvan de datastructuur in een RDBMS wordt bepaald. Het logische databasemodel is het model waarbij de gegevens met zo weinig mogelijk redundantie opgeslagen worden, zonder dat er reeds rekening is gehouden met implementatiespecifieke wensen. Om vanuit het conceptuele model te komen tot een logisch model, wordt in FCO-IM het GLR (Groeperen, Lexicaliseren en Reduceren)algoritme uitgevoerd. Omdat na het uitvoeren van het GLR-algoritme de rollen identificeerbaar blijven vanuit het conceptuele model, kunnen de geassocieerde bewerkingen overgenomen worden naar het logische model. Dit kan gedaan worden door te kijken naar de rolnummers uit het conceptuele model waarna de bewerking die met dit nummer geassocieerd wordt overgenomen kan worden in het logische model met de rollen met hetzelfde significante nummer. Als deze methode toegepast wordt op het genoemde voorbeeld ontstaat Figuur 32: “Logisch model met bewerkingen. Dit figuur borduurt voort op Figuur 27 “Conceptueel diagram met bewerkingen”. Het kleurverschil duidt op de daar geïdentificeerde bewerkingen. S tr a a tn a a m

P l a a ts n a a m

H u isn u m m e r

Stude ntA dre s p

16

6

7 .1

7 .2

7 .3

F 2 : "Student < 6> woont op < 7.1> < 7.2> te < 7.3> ." 1: 0229342 Sc hoolstr aa 1 Ar nhem

S tu de n tN u m m e r A c h t e rn a a m Vo o rn a a m

da g

m a a n d ja a r

Stude nt p

1

3 F 1 : "Student < 3> F 3 : "Student < 3> F 4 : "Student < 3> 1: 0229342

2 .1

2 .2

1 6 .1

1 6 .2

heet < 2.1> < 2.2> ." heeft voor opleiding < 13> ." is g ebor en op < 16.1> - < 16.2> - < 16.3> ." 05 Ar noud van Ber s 09

1 6 .3

13

1979

VW O

vo o ro p l e i d i n g s n a a m

Vo o ro ple iding Vak k e n p

18

Vaknaam

21

20

F 5 : "Voor opleiding < 20> bevat het vak < 21> ." 1: W iskunde B VW O

Figuur 32: “Logisch model met bewerkingen” Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

39/61

Master’s Thesis

Dit verkregen model zal omgezet worden naar een fysiek relationeel model op een RDBMS (Relationeel Database Management Systeem). Hierbij dient rekening gehouden te worden met RDBMS-specifieke optimalisaties en syntax. In dit voorbeeld zullen er 3 tabellen gegenereerd worden, namelijk Student, StudentAdres en Vooropleiding.

Figuur 33: “Tabelstructuur voorbeeld”

De overgenomen bewerkingen zullen de basis vormen voor schermen in de applicatie. Het is niet zondermeer mogelijk om een 1 op 1 koppeling te maken tussen de bewerkingen en schermen, omdat er met deze methode een afhankelijkheid is van database constraints, die er in de oude situatie op papier niet was. Dit houdt in dat er mogelijk ook een organisatieverandering plaats zal moeten vinden, wanneer er paperless gewerkt gaat worden. Wanneer in een vroegere situatie een formulier door 3 personen werd ingevoerd, waarbij ieder persoon de informatie invulde die hij of zij op dat moment beschikbaar had, was dit geen probleem: Totdat het formulier compleet ingevuld was circuleerde het op de afdeling, waarna het doorgestuurd werd naar degene die voor verdere bewerking zorgde. In een geautomatiseerd systeem is dit principe niet wenselijk omdat er constraints op gegevens zitten die de integriteit van de gegevens bewaken. Deze constraints zorgen er vaak voor dat bepaalde gegevens ingevoerd moeten worden, alvorens ze opgeslagen kunnen worden in de database. Ze kunnen dus beperken dat een gebruiker onvolledige gegevens in de database zet. Zonder constraints kunnen de gegevens snel vervallen tot een onsamenhangende bulk gegevens zonder verwijzingen, waardoor de informatie waardeloos wordt. Tevens zal het uitbreiden, re-engineeren en koppelen van het systeem in de loop der jaren steeds moeilijker worden, omdat de vervuilingsgraad snel toeneemt. In plaats van een organisatieverandering is het ook mogelijk de informatiestructuur te wijzigen aan de hand van de taken die er op deze gegevens blijken te zitten. Er is in ieder geval een noodzaak dat deze twee zaken op elkaar afgestemd zijn, en het is aan een CASE-tool om deze inconsistentie op te merken. De mate waarin constraints van belang zijn hangt af van de actie die de gebruiker pleegt op de gegevens. Voor het kijken naar gegevens zijn constraints amper van belang, omdat deze slechts getriggerd worden door een wijziging in populatie. Voor schermen die dus enkel het doel van informatiepresentatie dienen, leveren de constraints geen beperkingen op. Bij het invoeren van gegevens worden de constraints wel getriggerd, waardoor ze dus wel van belang zijn. Concluderend houdt dit in dat een scherm dat voor invoer dient, minstens moet beschikken over alle niet-optionele rollen van een tabel of tabellenset. Doordat tabellen een niet-optionele verwijzing kunnen hebben naar andere tabellen, bestaat de mogelijkheid dat een scherm dus uit een set van tabellen bestaat. Voor schermen die dienen voor aanpassing van gegevens geldt eigenlijk hetzelfde als voor de schermen waar alleen gegevens in bekeken worden: voor een aanpassing zijn reeds alle benodigde velden ingevoerd; niet alle velden hoeven getoond te worden. Wel is het in deze situatie gewenst om de unieke velden wel te tonen zodat het onderscheid gemaakt kan worden tussen de verschillende ingevoerde gegevens.


40/61

Master’s Thesis

7.2 Generatie van de Grafische User-Interface Bij interactieve databaseapplicaties beslaat de user-interface gemiddeld 50% van de code [MyR92][BHW94]. Het ontwerp van een user-interface wordt meestal beschouwd als een bijzaak, terwijl dit juist gezien moet worden als een integraal onderdeel van het project, waarvoor geld en middelen vrijgemaakt moet worden. Beslissingen op user-interface ontwerp werken door in de gehele applicatie. Daardoor is het maken van de interface vaak repeterend werk wanneer de initiële specificatie reeds opgesteld is. Wanneer een user-interface een heel gevarieerd publiek als doelgroep heeft, dan is het niet wenselijk een heel erg afwijkende of eigenzinnige weg in te slaan met het ontwerp van de lay-out. Dit fenomeen is goed op het internet waar te nemen, waar veel websites met een algemeen karakter eenzelfde uiterlijk en indeling hebben. Een veel gekozen structuur is de menubalk bovenaan waar categorieën te kiezen zijn; Links bevindt zich de lokale indeling van de huidige categorie; In het midden bevindt zich de eigenlijke content. Dit geldt niet alleen voor webinterfaces maar ook voor interfaces die werken op besturingssystemen die gebaseerd zijn op windows, waar de elementen voornamelijk bestaan uit windows, iconen, controls en menu’s. De keuze voor een bepaald user-interface element wordt niet slechts bepaald door de gebruiker die er mee aan de slag moet, maar ook door de gegevens die dat element representeert. Dit suggereert dat wanneer het gebruikersdeel van de user-interface zo algemeen mogelijk wordt vastgelegd zodat nagenoeg iedereen er mee overweg kan, het mogelijk is om de interface te genereren op basis van de gegevens die het element moet representeren. In FCO-IM wordt voor ieder labeltype op conceptueel niveau vastgelegd wat voor gegevens het bevat (tekst, waarden, lijst) en wat de maximale lengte is. Hoewel er geen echte conceptuele datatypes zijn voor het conceptuele informatiemodel, kunnen hier wel afspraken over gemaakt worden. Op conceptueel niveau zijn er geen platformspecifieke datatypes gewenst, maar wel aanduidingen die later ongeacht welke taal of platform te gebruiken zijn. Zo kan bijvoorbeeld de door ISO opgestelde standaard Language Independent Datatypes (LID) [ISO11404] gebruikt worden. Het grafische element hangt dus bij generatie af van het datatype dat gebruikt wordt. Verder van belang voor de grafische representatie is de multipliciteit van gegevens. De multipliciteit kan gehaald worden uit de uniciteitsconstraints in het conceptuele model. Gegevens met een 1:n relatie zullen anders weergegeven moeten worden dan gegevens met een 1:1 relatie. Voorbeelden van de eerste zijn bijvoorbeeld een student met meerdere adressen. Een 1:1 relatie komt bijvoorbeeld voor bij subtypen (Persoon die ook Student is), maar ook bij een eenzijdige koppeling, bijvoorbeeld: Student heeft sofi-nummer. Op het grafisch vlak zal tussen de laatste 2 typen ook een onderscheid gemaakt moeten worden. Gebruikers wensen dat gegevens die samenhang met elkaar vertonen ook als zodanig weergegeven worden. Dit maakt dat de gebruiker snel overzicht heeft en snel de gegevens kan vinden waar hij/zij op dat moment naar zoekt. Deze logische clustering is te halen uit het conceptuele model, waar de gegevens door de modelleur reeds zijn geclassificeerd als logische brokken met een eigen identificator. Voor het doel van schermgeneratie is het wenselijk meer informatie beschikbaar te hebben over de gemodelleerde gegevens. Door decompositie toe te voegen aan de FCO-IM techniek zoals in PSM [HW93], wordt het gemakkelijker om gegevens gestructureerd op het scherm weer te geven. Uitgaande van het voorbeeld uit Figuur 27: “Conceptueel diagram met bewerkingen”, kan nu het inschrijfformulier zoals weergegeven in Figuur 34: “Concept van een gegenereerd scherm op basis van het conceptuele model”’ gegenereerd worden. Centraal in het formulier staat de Student, waar de gebruiker de gegevens van wil zien. Naast zijn identificatie ‘StudentNr’ heeft de student een naam en geboortedatum. Deze zijn 1:1 gerelateerd aan het Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

41/61

Master’s Thesis Inschrijfformulier New..

Modify..

Delete...

Student Studentnr

Formulieren Collegekaart

StudentNaam

StudentGeboortedatum

Voornaam

Dag

Achternaam

Maand Jaar

StudentAdres Straatnaam

Huisnummer

Naam van de straat waar de student zich regelmatig bevindt . Eigenaar: StudentAdministratie Gebruikt in: Collegekaart, Inschrijfformulier

Record 0 van 1 Laatst gewijzigd door A. van Bers op 1-1-2001

Figuur 34: “Concept van een gegenereerd scherm op basis van het conceptuele model”

studentnr en worden als groep weergegeven. De groep omhelst dan de afzonderlijke rollen waaruit de groep bestaat. Gegevens die per Student vaker voorkomen (1:n) worden getoond in een gridstructuur, zodat meerdere gegevens in één oogopslag te zien zijn en er niet één voor één doorheen gelopen hoeft te worden. Als er meedere gridstructuren verbonden zijn met het subject, is het niet wenselijk deze allemaal onder elkaar op het scherm te hebben. De gebruiker moet dan immers veel scrollen. Een oplossing is het gebruik van tabbladen, waar de grids op geplaatst kunnen worden. Een nadeel aan tabbladen is dat er slechts 1 tegelijk geopend kan worden. Dit kan voor een gebruiker problemen opleveren als hij meerdere gegevens tegelijk wil zien. Een oplossing kan in geval gevonden worden in het onder elkaar plaatsen van openklapbare secties, die het middels een muisklik mogelijk maken de gridstructuur zichtbaar te maken.

Per object kan er weergegeven worden waar deze zich nog meer in verbindt. Wanneer desbetreffende gebruiker rechten heeft om dat formulier ook te bekijken kan hij/zij meer informatie opvragen door die gegevens ook op te vragen. Afhankelijk van de taken die de gebruiker mag uitvoeren op het scherm verschijnen de acties bovenaan het scherm (New, Modify, Delete).

7.2.1 Lay-out Problematiek Schermgeneratie vraagt veel van de manier waarop het conceptuele model ingevoerd is. Veel terminologie gebruikt door analisten en modelleurs zal niet begrepen worden door de gebruiker die met het systeem aan de slag moet. Zij kijken namelijk heel anders tegen het domein aan. De naamgeving van feiten en rollen in het domein hebben voor de gebruiker dus geen waarde en zullen daarom vervangen moeten worden door een informele maar duidelijke typering. Hiernaast heeft de gebruiker vaak behoefte aan extra informatie wanneer niet geheel duidelijk is wat er van hem/haar gevraagd wordt. Per feittype en rol zal er dus een omschrijving moeten komen, die bijvoorbeeld als tooltip kan worden weergegeven. Een ander probleem is de plaatsing van de interface elementen op het scherm. Voor standaard elementen als menubalken, statusbalken en navigatie is dit geen probleem, omdat deze repeterend zijn in de applicatie en daarom dus een standaard plaats kunnen krijgen in de schermen. Wel een probleem zijn de elementen die veranderen per informatieverzoek. Waarom staat in Figuur 34 Studentnaam links van Studentgeboortedatum bijvoorbeeld? Om het scherm efficiënt te vullen met elementen is een algoritme te bedenken, dat uitgaat van veldlengtes en schermbreedte. Beter is het afstemmen van de generatie op de wens van de gebruiker. Dit is echter moeilijk te realiseren, omdat andere typen gebruikers andere wensen hebben over dezelfde gegevens. Er zou mogelijk een waarderingssysteem ingevoerd kunnen worden, waarbij voor ieder feittype en iedere gebruiker een waardering- of relevantiecijfer kan worden gegeven binnen een scherm. Gezien de hoeveelheid werk en tijd die dan in de modelleerslag gaat zitten is dit weinig relevant. Verstandiger is het bijhouden van een positie van rollen per formulier en mogelijk ook per actor. Het scherm zal eenmalig gegenereerd worden met een algoritme, waarna de ontwerper de mogelijkheid heeft de elementposities te wijzigen.


42/61

Master’s Thesis

7.3 Algoritmiek In de vorige hoofdstukken is beschreven welke informatie er nodig is om schermen te kunnen genereren. Het genereren van schermen gebeurt op basis van het informatiemodel, procesmodel en de organisatiestructuur. Deze gebieden moeten zo op elkaar afgestemd zijn, dat de user-interface hieruit af te leiden is. 1

Form

OrganisatieModel

1


0..n 0..n

Informatie Model

Proces Model

Organisatie Structuur

0..n 0 1..n


Control 0..n

1 1

0..n

Grid


Button -Action

User-Interface

1

+Zoom()

+Click()

Invoer Control

Weergave Control

-Datatype -Selection : bool -MultiSelect : bool -Rol

-Datatype -Rol

1

1..n Single Value

1

-Value

Figuur 36: “Het schermgeneratie-principe”

Figuur 35: “Definitie van de user-interface”

Als de definitie van de user-interface beschouwd wordt (Figuur 35), dan moet ieder element een herkomst hebben uit één van de hierboven beschreven modellen. Zoals besproken in hoofdstuk 5.1 bestaat het procesmodel uit verschillende lagen. De bewerkingen, één hiervan, vormen logische werkeenheden en zijn daarom geschikt om te dienen als schermdefinitie, zoals besproken is in hoofdstuk 5.2.1. Een scherm kan in één van enkele toestanden verkeren. Zo zijn er toestanden waarin gegevens gewijzigd kunnen worden en toestanden waarin gegevens bekeken kunnen worden. De huidige toestand wordt voor het scherm bijgehouden met de eigenschap ‘CRUDstate’. Deze toestand houdt bij of een scherm in een invoer-, bewerking-, selectie- of verwijdertoestand staat. Dit is van belang om de juiste schermcontrols te genereren. Voor het bekijken van gegevens zijn namelijk andere controls nodig dan voor het invoeren en wijzigen van gegevens. Het verschil is voornamelijk het toestaan van gebruikersinteractie met de gegevens. Om een scherm van toestand te veranderen worden buttons aangemaakt, die de CRUDstate van het scherm veranderen als er op geklikt wordt. De activering van de buttons hangt af van de toegang die de actor heeft op de bewerking: deze is direct aan hem toegekend, maar kan ook overgenomen worden door een actor die hoger in rang staat, en dus een controlerende taak heeft op dezelfde gegevens. Form

Bewerking

Actor

Form.Title = Bewerking.Naam Form.Bewerking = Bewerking


Button If Actor = Owner then Button.Action = C,R,U,D -Action else Button.Action = R +Click()

Figuur 37: “Mapping van Bewerking naar Form”

Een bewerking bestaat uit één of meerdere elementaire handelingen. Deze handelingen volgen direct uit de elementaire feiten waaruit het informatiemodel is ontstaan. In onderstaand voorbeeld bevat de bewerking ‘Inschrijving’ bijvoorbeeld de elementaire handelingen ‘handelen StudentAdres’, ‘handelen StudentWoonplaats’ en ‘handelen StudentVooropleiding’, omdat deze feiten direct uit de verwoordingen komen. Iedere handeling moet door middel van de user-interface geïnitieerd kunnen worden, en zal dus op het scherm getoond moeten worden. De manier van tonen op het scherm hangt af van de multipliciteit van de objecten, die bepaald wordt door de navigatierichting.


43/61

Master’s Thesis

De navigatiegraaf bevat een startpunt (het subject), gerepresenteerd door een object. Omdat er een vraag is naar gegevens voor een instantie van het startobject, heeft deze altijd multipliciteit 1. Figuur 38: “Navigatierichting bepaalt het uitgangspunt” verduidelijkt dit principe. Zonder rekening te houden met de navigatierichting is de multipliciteit tussen Student en Vooropleiding n:1. Door een navigatierichting vast te leggen, wordt de multipliciteit van één van deze objecten vastgelegd op 1. Stel we kiezen de Vooropleiding als uitgangspunt, dan willen we alle studenten zien die de gekozen specifieke vooropleiding hebben. Bijvoorbeeld alle studenten die de vooropleiding VWO hebben. Dat er meer studenten met dezelfde vooropleiding kunnen bestaan, is het resultaat van de afwezigheid van een uniciteitsconstraint op rol 1. Een ander geval is het als we Student als startpunt nemen. Dan willen we de vooropleiding van een specifieke student zien, bijvoorbeeld de vooropleiding van student Arnoud van Bers. Het eerste geval levert voor deze situatie een 1:n relatie op, het tweede geval een 1:1 relatie. Omdat er altijd uitgegaan wordt van een enkele instantie van een object als startpunt, is de multipliciteit hiervan altijd 1. n

1

De studenten van een vooropleiding

achte rnaam

Student

Vooropleiding


3

1

3

O1

4

O1 : 'student <3> <4>' 1: Arnoud van Bers

1

2

2

O2

F1 : "<1> heeft <2>." 1: Arnoud,van VWO

5

voorople idingsnaam

O2 : 'vooropleiding <5>' 1: VWO

voornaam

1

De vooropleiding van een student

1

Figuur 38: “Navigatierichting bepaalt het uitgangspunt”

Voor het bepalen van de multipliciteit gaan we uit van het startobject (in Figuur 39 en Figuur 40 aangeduid met een ‘S’), die middels een n-aire relatie verbonden is met 1 of meer andere objecten. Gegeven het startobject kan de multipliciteit van de gerelateerde objecten bepaald worden. Afhankelijk van de gecombineerde maximale multipliciteit van deze objecten uit de relatie kan bepaald worden welk component er getoond moet worden op het scherm. Er wordt van de gecombineerde multipliciteit uitgegaan, omdat de rollen in een relatie altijd samenhang hebben, vanwege de regel dat ze anders splitsbaar zijn. Slechts wanneer alle rollen van een relatie een multipliciteit van 1 hebben worden er enkelwaardige componenten gegenereerd. In alle andere gevallen wordt een meerwaardig component gegenereerd. De situaties die leiden tot enkelvoudige componenten voor relaties met 2 en 3 rollen zijn weergegeven in Figuur 40: “Gecombineerde multipliciteit van een relatie”. S

Navigatierichting

3

4

N

1

2

S

3

4

1

:

1

3 1

4 :

1

5 S

Multipliciteit:

:

S

?

Figuur 39: "Multipliciteitsbepaling ten opzichte van het startpunt"

3 N

4 :

1

5 :

1

S

3 1

4 :

1

5 :

1

Figuur 40: “Gecombineerde multipliciteit van een relatie”

Een 1:1 relatie levert per rol een bewerkbaar- of leescontrol op, die één waarde representeert. Een 1:n relatie levert voor de hele handeling een grid op, dat een herhaling van bewerkbaar- en leescontrols is. Als de rollen van een elementaire handeling verplicht ingevoerd moeten worden, te herkennen aan totaliteitscontraints, dan kunnen de hiermee geassocieerde controls geaccentueerd worden om aan de gebruiker kenbaar te maken dat deze een extra eigenschap bevatten. Hiervoor wordt het attribuut ‘Accented’ gezet. Dit leidt dan bijvoorbeeld op de user-interface tot een afwijkende kleur voor de control.


44/61

Master’s Thesis Control

Elementaire Handeling


Control.Label = EH.’Rol Naam’ Control.Accented = EH.’Rol Verplicht’

Figuur 41: “Mapping van Handeling naar Control”

Een beperking waar op user-interface gebied tegenaan gelopen wordt is dat het niet mogelijk, maar tevens ook niet gewenst is om grids in grids te plaatsen. Met bovenstaande methode zou dit echter wel het resultaat zijn als er een 1:n relatie gevolgd wordt door een n:m relatie. Een voorbeeld hiervan is weergegeven in Figuur 42: "Een voorbeeld van een 1:n:n relatie", waar voor alle vooropleidingen waar het gekozen vak in voorkomt een grid wordt gegenereerd. Daarna wordt voor alle studenten met deze vooropleiding hierbinnen weer een grid gegenereerd. Studenten die een bepaald vak in hun vooropleiding hebben

Vak

Vooropleiding

VooropleidingVakken

12

13 O6

22 O6 : 'vak <22>' 1: W iskunde B

11

21

O5

20

19

F6 : "<20> bevat het <21>." 1: W iskunde VW O

9

Student

StudentVooropleiding 8 O5

18

5

O1

17

O5 : 'vooropleiding <19>' F5 : "<17> heeft als <18>." 1: Hogere Informatica 1: Hogere Info 0229342 2: VW O

1

2

3

O1 : 'student <3>' 1: 0229342

n

n

Navigatierichting

Figuur 42: "Een voorbeeld van een 1:n:n relatie"

Om een gebruiker niet ineens met al deze informatie op te zadelen, zal hierin een afbakening plaats moeten vinden. Nemen we bijvoorbeeld de populatie uit Tabel 3 voor het voorbeeld van Figuur 42, dan zien we dat het vak Wiskunde B gegeven wordt op de HAVO en het VWO. Er zijn 2 studenten die VWO als vooropleiding hebben, namelijk Arnoud en Maike. Vak Wiskunde B

VooropleidingsVakken Wiskunde B / HAVO Wiskunde B / VWO Tabel 3:

Vooropleiding StudentVooropleiding Student HAVO VWO / Arnoud Arnoud VWO VWO / Maike Maike "Voorbeeldpopulatie"

Omdat we geen grid in grid structuur willen hanteren, maken we een afbakening na de eerste relatie waar een meervoudige multipliciteit optreedt. We zien dus in het hoofdscherm alleen de attributen van het object Vak en de direct daarmee verbonden objecten met meervoudige multipliciteit. Dit houdt in dat we de attributen van Vak zien als enkelvoudige controls en een grid voor Vooropleiding waar alleen alle attributen van vooropleiding te zien zijn. Als we meer gegevens van de vooropleiding willen weten, dan kunnen we dit doen middels een ‘zoom’-actie, waarmee voor een specifieke instantie van een vooropleiding bekeken kan worden welke studenten deze gevolgd hebben. Dit houdt in dat we weer een enkele instantie van Vooropleiding hebben, waarin zich hetzelfde proces kan herhalen. Als een relatie meerdere rollen heeft, dan worden deze in hetzelfde grid weergegeven als extra kolom. De zoom actie die op deze kolom werkt, zorgt dan voor het verkrijgen van extra informatie over die instantie van dat object. Ook de attributen van het object mappen op kolommen van het grid, zodat detailinformatie in één oogopslag te zien is. De gegevens in een grid mogen niet worden gemuteerd in het grid, maar moeten middels de zoom-actie benaderd worden. Bewerking

Bewerking Vak

Bewerking.Sub1

Vak 12

22 O6 : 'vak <22>' 1: Wiskunde B

Vooropleiding

VooropleidingVakken 13 O6

21

11

20

F6 : "<20> bevat het <21>." 1: Wiskunde VWO

O5

8 9

19

O5

18

17

O5 : 'vooropleiding <19>' F5 : "<17> heeft als <18>." 1: Hogere Informatica 1: Hogere Info 0229342 2: VWO

1 1

Student


n

2 O1

5

Bewerking.Sub1

Wiskunde B Vooropleiding

3

O1 : 'student <3>' 1: 0229342

n

Vooropleiding VWO

(V om Zo

ro oo

=V ng idi ple

O) W

Vooropleiding VWO Student Student Arnoud

HAVO

Maike

n

Navigatierichting

Figuur 43: "Opdeling van een bewerking t.b.v. de user-interface"

Figuur 44: "User-Interface van het voorbeeld"


45/61

Master’s Thesis

De posities van de controls zijn niet te baseren op het huidige organisatiemodel. Dit houdt in dat de user-interface deze moet bepalen. Een eenvoudig algoritme kan toegepast worden om de controls, afhankelijk van de grootte en breedte in kolommen op het scherm te plaatsen. Een andere mapping die gemaakt kan worden zijn acties die uitgevoerd kunnen worden en buttons op het scherm. Buttons maken het mogelijk een actie uit te voeren. We onderkennen 4 soorten acties, namelijk selecteren, invoeren, bewerken en verwijderen. Deze kunnen op user-interface niveau opgedeeld worden in 2 groepen: • Soort actie waarbij invoer door de gebruiker benodigd is; • Soort actie waarbij geen invoer van de gebruiker nodig is. Gegevens die slechts zijn om te tonen, het resultaat van een selecteer-actie, behoeven geen invoer van de gebruiker. Het is dus niet gewenst dat een gebruiker wel invoer kan plegen op dat moment. Dit zal dus onmogelijk gemaakt moeten worden. Hetzelfde geldt voor een verwijder-actie: de gebruiker wil alleen maar zien wat hij gaat verwijderen, en hoeft op dat moment geen invoer te plegen. Deze gegevens mappen naar een weergavecontrol, die slechts de waarde kan weergeven. De waarde van de weergavecontrol is de waarde van de rol van de elementaire handeling die de control representeert. Een ander geval zijn de invoeren bewerkingsacties, die het wel mogelijk moeten maken voor een gebruiker om invoer te plegen. Hier zal dus een ander control voor gebruikt moeten worden, namelijk de invoercontrol. De invoercontrol kan een selectie zijn van de populatie van een andere elementaire handeling. Als dit het geval is, dan wordt de eigenschap ‘Selection’ gezet, en houdt dit tevens in dat de waarden van dit control de waarden zijn uit de populatie van de verwijzende rol. Als dit niet het geval is, dan blijft de waarde leeg en kan de gebruiker zelf invoer plegen. Elementaire Handeling t.b.v Invoer& Bewerkingsactie

IC.Datatype = EH.Rol.Datatype IC.Rol = EH.Rol

Invoer Control -Datatype -Selection : bool -MultiSelect : bool -Rol

Elementaire Handeling t.b.v Selecteer& Verwijderactie

Figuur 46: “Mapping van soort Actie naar Control”

WC.Datatype = EH.Rol.Datatype WC.Rol = EH.Rol

Weergave Control -Datatype -Rol

Figuur 45: “Mapping van soort Actie naar Control”

Binnen het scherm is het mogelijk om controls te groeperen middels een container. Zo kunnen alle gegevens van een Student gegroepeerd worden, wat de samenhang van de gegevens accentueert. Een manier om te groeperen is om alle 1:1 gegevens van een object te vatten in een container. Hierbinnen kan wederom gegroepeerd worden op de identificerende rollen (de rollen in een object). Alle attributen van een object

Container.Title = Object.Title


Container.Title = Object.Title + ‘identification’

Identificerende kenmerken van een object

Figuur 47: “Mapping van Rollen naar Container"


46/61

Master’s Thesis

7.4 Terugkoppeling naar de gebruiker Niet alleen het uiterlijk van de schermen en navigatiemogelijkheden bepaalt of de gebruiker tevreden is met de gegenereerde applicatie. De gebruiker heeft tevens de wens op de hoogte gehouden te worden van wat er met de gegevens gebeurd is. Hiervoor moet een mutatiehistorie bijgehouden worden. Deze kan tevens van groot belang zijn wanneer er onduidelijkheden optreden omtrent een mutatie, waarna een vorige mutatie teruggezet kan worden. In moderne database managementsystemen kunnen triggers worden gedefinieerd. Triggers zijn regels code die uitgevoerd worden wanneer er aan een bepaalde conditie wordt voldaan. Voor het bijhouden van mutaties kunnen triggers gegenereerd worden die reageren op invoeren, wijzigen en verwijderen van gegevens. Wanneer voor iedere bewerking in het fysieke model een historietabel wordt aangemaakt, waarin de actie, tijd en datum, gebruiker en machinenaam gelogd wordt, dan is de populatie van het systeem ten aller tijde terug te halen naar een vorige toestand. De gebruiker kan dan geïnformeerd worden door in de statusbalk onderaan het scherm aan te geven wie de laatste wijziging heeft uitgevoerd, vanaf welke machine en wanneer dit gebeurd is. Een voorbeeld van triggergeneratie is te vinden in Bijlage E “Triggergeneratie op SQL Server 2000”. Dat de mutatiehistorie nog meer doelen kan dienen, wordt beschreven in hoofdstuk 9 ‘Bedrijfsindeling op basis van het organisatiemodel’. Een ander punt wat de gebruikersbeleving verhoogt is het tonen van de zojuist gemuteerde gegevens na uitvoering van een actie door een actor. Wanneer de gebruiker een bewerking uitvoert, verwacht hij daarna feedback over deze actie. Door na de mutatie direct een zoekactie op de identificerende sleutel van de bewerking te plegen, kan aan de gebruiker zijn actie worden weergegeven. In multi-user omgevingen komt het voor dat een gebruiker een mutatie open laat staan, terwijl een andere gebruiker de gegevens gewijzigd heeft. Wanneer de gebruiker dan de mutatie uitvoert, zou deze zondermeer over de zojuist gewijzigde gegevens worden uitgevoerd, zonder dat de gebruiker deze wijziging te zien heeft gekregen. Hier kan dus belangrijke informatie zoek raken! De user dient altijd feedback te krijgen wanneer hij gegevens probeert te wijzigen, die reeds in de tussentijd door een andere gebruiker gewijzigd is. Dit probleem is op te lossen door in de historie te kijken, waar de laatste mutatietijd in is opgenomen. Wanneer de opgehaalde mutatietijd niet overeenkomt met de laatste mutatietijd op het moment van wijziging is dit een indicatie dat een andere gebruiker de gegevens reeds veranderd heeft. Op dat moment dient de actie van de gebruiker afgebroken te worden, waarna hij bericht krijgt van de wijziging. De gebruiker kan dan de mutatie bekijken en besluiten of zijn wijziging nog plaats moet vinden.

7.5 Mapping Procesniveaus Zoals in de vorige paragrafen duidelijk is geworden mappen de elementaire handelingen naar user-interface elementen. Het type, multipliciteit en groepering bepalen welk grafisch element er gekozen wordt om de gegevens te representeren. De bewerkingen zijn logische werkeenheden, en daarom geschikt om als één geheel te groeperen op het scherm. Bewerkingen/schermen mappen dus naar formulieren. De activiteiten waar een gebruiker mee in aanraking komt tijdens zijn dagelijkse werkzaamheden representeren een bepaald doel. Deze vormen voor de gebruiker het hoofdmenu. Hierin geeft hij aan welke activiteit hij op dat moment wil uitvoeren. De bovenste twee niveaus zijn bedoeld voor indicatie van de performance van de organisatie, en bieden tezamen met een mutatiehistorie een mogelijkheid tot Business


47/61

Master’s Thesis

Process Redesign. Hier wordt in de volgende hoofdstukken aandacht aan besteed hoe dit uit te werken is. Het totaalbeeld van de mapping van processen naar een organisatieondersteunend informatiesysteem ziet er dan uit als in Figuur 48 “Totaalbeeld van het generatieprincipe”. Organisatie

Bedrijfsprocessen 1

2

3

4

5

Business Performance

Informatie processen

Key Performance Indicator (KPI) Hoofdmenu Mijn Taken

Supervision

? ?

Act1

Uitschrijven Diplomering

?

Act3

Inschrijven

Taken

Act2

Scherm Scherm

Bewerkingen

Interface Componenten CheckBox RadioBox

Combobox Editbox

Tabblad

Handelingen

Kolom 1

Kolom 2

Figuur 48: “Totaalbeeld van het generatieprincipe”


48/61

Master’s Thesis

8 Procesindeling In hoofdstuk 5.1 Niveaus van Processen is een indeling in procesniveaus besproken. In voorgaande hoofdstukken werd de problematiek duidelijk die speelt bij het tot stand komen van de schermen. Wanneer alle stappen in voorgaande hoofdstukken zijn doorlopen, dan zijn de bewerkingen vastgelegd. Per actor, rol of functie kan bekeken worden welke bewerkingen zij allemaal uitvoeren, omdat deze vastgelegd zijn in de permissies per bewerking. Om te komen tot taken, het bovenliggende procesniveau, zal de volgorde van de bewerkingen bepaald moeten worden. Omdat het niet het doel is een complete workflow engine te genereren, waar gebruikers afhankelijk zijn van de activiteit van andere gebruikers, zal er niet ingegaan worden op constructies met synchronisaties binnen taken (dit wordt in Testbed Studio wel gedaan, echter puur voor visualisatie). Uit het feit dat taken een opvolging van bewerkingen zijn die 1 gebruiker instantieert en het uitgangspunt de capaciteit van 1 was voor een actor, komt hieruit voort dat taken die parallel aan elkaar uitgevoerd worden toch slechts sequentieel behandeld kunnen worden. Keuzemomenten kunnen wel voorkomen in een taak, omdat dit geen bewerkingsafhankelijkheid tot stand brengt. Voor het visualiseren van de taken kan Testbed goed gebruikt worden (zie Figuur 10: “Bewerkingen van de taak Registreren”). De bewerkingen per medewerker volgen uit het, in hoofdstuk 6.2 ‘Uitbreiding Repository‘ beschreven, metamodel. Via een query kan er opgevraagd worden welke bewerkingen een medewerker uitvoert. Deze kunnen door middel van procesmodellering in sequences geplaatst worden. Constraints op de gegevens zijn leidend voor het proces, dat voor de sturing hierin zorgt. Een andere sturing is een logische volgorde van taken, die ook aan de CASE-tool kan worden toegekend. Het is immers zo dat er eerst gegevens moeten worden opgezocht, alvorens deze gewijzigd kunnen worden.

8.1 Procesuitbreiding in het metamodel Als hoofdstuk 5.1 Niveaus van Processen gerecapituleerd wordt met daarbij de hierboven gevonden bevindingen in gedachten houdend, komen de procesniveaus op het volgende neer: 1. Handeling: Wijziging op feittype niveau door 1 actor; 2. Bewerking: Wijziging van een document door 1 actor; 3. Taak: Sequence van wijzigingen door 1 actor; 4. Proces: Ordening van taken, meerdere actoren; 5. Bedrijfsproces: Verantwoordelijke voor informatieprocessen. Deze procesniveaus zullen terug moeten keren in het metamodel. Hieronder is de extra uitbreiding hierop weergegeven. Sequence 73

BusinessProcess 77

125

41

O41 : 'Business Process <125>' 1: Customer Services

74 O41

124

123

O40

F68 : "<123> is contained in <124>." 1: Customer S Advise Customer

118

Process

BusinessProcessContent 42

76

122

ProcessContent 43

O39 : 'Process <122>' O40 : 'process <122>' 1: Advise Customer

75 O39

121

120

O37

119

44F66 : "<118> is followed by <119>." O37 : '<118> is followed by <119>' 1: AdministratAdministrator,Mutate,Appliance 2: AdministratAdministrator,Add,Applicance

F67 : "<120> is part of <121>." O36 O36 1: Advise Cus(Administrator,Add,Applicance),(Administrator,Add,Applicance)

Task

Busine ssProce ssName 66

112

Proce ssName

113

114

F64 : "<112> executes <113> on <114>." O36 : '<112> executes <113> on <114>' 1: Administrat Add Appliance 2: Administrat Add Appliance 3: Administrat Mutate Appliance 4: Administrat Add Applicance

Figuur 49: “Procesindeling in het metamodel” Applicatie Generatie: Eindelijk actiefondersteunende informatiesystemen?

49/61

Master’s Thesis

9 Bedrijfsindeling op basis van het organisatiemodel Om aan te geven dat het organisatiemodel meerdere doelen kan dienen dan slechts schermgeneratie, zal bekeken worden hoe het model tezamen met de applicatie kan dienen om het bedrijf naar een niveau hoger te tillen. Zoals in dit onderzoek beschreven voeren actoren bewerkingen uit. Iedere bewerking duurt een bepaalde tijd. Deze tijd kan worden geschat op basis van de elementaire handelingen die deze bewerking bevat. Als verondersteld wordt dat een gebruiker alle gegevens reeds heeft klaarstaan voor invoer kan bijvoorbeeld geschat worden dat een elementaire handeling een bewerkingstijd heeft van 15 seconden. Als een bewerking dus bestaat uit 12 elementaire handelingen, dan heeft deze bewerking een geschatte uitvoertijd van 3 minuten. Naast de tijd die het duurt om een bepaalde bewerking uit te voeren, is het tevens van belang wat de frequentie van handelen is. Ook deze gegevens volgen uit de organisatie: een school weet bijvoorbeeld hoeveel studentinschrijvingen er verwacht worden dat jaar, gebaseerd op de resultaten van afgelopen jaren en het aantal aspirant-studenten die naar open- en voorlichtingsdagen komen. Als dit er ongeveer 2000 zijn per jaar, dan omvat de bewerking ‘Inschrijven Student’ 100 uur werk per jaar. Omdat inschrijvingen bij de Informatie Beheer Groep in oktober bekend moeten zijn, zit er een duidelijke trend in de toewijzing van deze taak. Deze 100 uur dient dus in de periode mei tot oktober uitgevoerd te worden, terwijl er de rest van het jaar nauwelijks werk in deze bewerking zit. Deze tijden kunnen cumulatief berekend worden per formele rol of functie in de organisatie dankzij deze indeling in het metamodel. Een formele rol of functie bestaat immers uit meerdere bewerkingen. Zo is het mogelijk een schatting te maken hoeveel mensen er benodigd zijn op een bepaalde post in de organisatie. Het kan tevens de aanleiding zijn om een nieuwe ordening en verdeling van taken te maken (Business Process Redesign), waardoor de organisatie kosten en middelen kan besparen. Het gebruik van een historie, zoals voorgesteld in hoofdstuk 7.4 ‘Terugkoppeling naar de gebruiker’, kan deze schatting verder concretiseren. Hoewel resultaten uit het verleden geen garantie geven voor de toekomst, kan de nauwkeurigheid van de schatting hier flink door verbeterd worden. Door de mutatiegraad en mutatietijden van de historie te bekijken, kan een duidelijke trend opgemaakt worden in de periode wanneer de meeste mutaties plaatsvinden, hoeveel werk een bewerking omvat en wat de gemiddelde bewerkingstijd is. Dit principe gaat echter niet altijd op. Alleen het werken met een scherm is meetbaar, dus wordt de tijd dat een medewerker bijvoorbeeld ondersteunende taken uitvoert niet meegenomen. Hieraan toevoegend kunnen de prestaties van de organisatie of per functie of rol bekeken worden aan de hand van dezelfde berekening. Door de historie te gebruiken als maatstaf, kan er gekeken worden of afdelingen hun taken goed uitgevoerd hebben. Vanzelfsprekend zal het op deze manier gebruiken van de historie op tegenwerking stuiten van medewerkers.


50/61

Master’s Thesis

10 Concluderend Centraal in dit onderzoek staat de vraag ‘hoe het mogelijk is om gebruikers slechts te bedienen met de informatie die ze nodig hebben voor hun dagelijkse werkzaamheden, en niet meer dan dat’. Zoals de resultaten uit voorgaande hoofdstukken laten zien is dit mogelijk. Door te analyseren welke functie(s) de gebruiker binnen de organisatie heeft, welke taken door deze functie uitgevoerd worden en welke specifieke gegevens bij deze taken horen kan vastgesteld worden wat een gebruiker op dat moment voor informatiebehoeften heeft. Alleen het vastleggen van deze informatie helpt de gebruiker weinig. Er is behoefte aan een informatiesysteem dat dit gegeven kan gebruiken om de gebruiker te ondersteunen. Om ontwikkeltrajecten te verkorten is er een wens naar automatische schermgeneratie, omdat zo repeterend werk voorkomen kan worden. We komen hiermee tot de onderzoeksvraag ‘welke aspecten in de modelvorming tijdens de analysefase meegenomen moeten worden om dit te realiseren’. Om dit te bewerkstelligen moet het analysetraject gestructureerd en op eenzelfde abstractieniveau formeel vastgelegd zijn, zodat automatische generatie kan plaatsvinden. Dit betekent dat de verschillende views op het systeem tot eenzelfde niveau teruggebracht moeten worden, het conceptuele niveau. De gebieden procesmodellering, informatiemodellering en organisatiemodellering zijn op elkaar afgebeeld, waarbij gebruik is gemaakt van de formele methode FCO-IM. Deze methode is uitgebreid met enkele kwalificatieslagen, die geen inbreuk doen op het ‘Fully Communicated’-aspect. In hoofdstuk 6 ‘Evolutie van het FCO-IM metamodel’ is een metamodel opgesteld voor de methode, waarna het in hoofdstuk 8.1 ‘Procesuitbreiding in het metamodel’ uitgebreid wordt voor de laatste onderzoeksvraag ‘hoe kan de organisatie ondersteund worden in de optimalisering van processen met behulp van het vastgelegde metamodel’. Om maximale flexibiliteit te handhaven tijdens de evolutie van het model en organisatie is het wenselijk het metamodel, waar de processen en database uit voortkomen, beschikbaar te hebben voor de schermgeneratie. Wanneer de schermgeneratie gebaseerd is op dat model en tevens de mapping naar het logische model 1 op 1 gehandhaafd kan blijven, dan is het mogelijk om iedere organisatie, zo veranderlijk deze ook kan zijn, te ondersteunen met deze methode. De applicatie zal zich runtime aanpassen bij het aanmaken van functies, formulieren of de toegang hierop. Dit vergt echter wel van de ontwikkelaar dat er goed getest wordt alvorens de applicatie aan te passen. De neiging om dingen snel aan ta passen is op deze wijze namelijk groter. Om de onderzoeksvraag ‘hoe zijn de schermen afhankelijk van taken, informatie, behoeften en kennis van de gebruiker’ te beantwoorden, is aangegeven hoe user-interface componenten gegroepeerd, geplaatst en gekozen kunnen worden op basis van het metamodel. Dit wordt gedaan door te kijken naar de groepering en inhoud van feiten binnen een bewerking in het conceptuele model, alsmede de cardinaliteit hiervan. Op basis van de gekozen navigatie binnen de bewerking kunnen queries of stored procedures gegenereerd worden, die de acties van de gebruikers uitvoeren op het fysieke model. Afhankelijk van de taken die een gebruiker op een bron uitvoert, kan hij wel of geen permissies hebben om deze taak uit te voeren. De onderzoeksvraag ‘welke beperkende factoren zijn er die betrekking hebben op de koppeling van de verschillende gebieden: processen, informatie en rollen’ stelt de afhankelijkheid van de modellen aan de kaak. De constraints die op de modellen liggen, bepalen dit. Op informatieanalyse gebied zijn dit de constraints op de populatie: totaliteitsconstraints, verwoordingen en uniciteitsconstraints. Hetzelfde geldt voor het gebied van procesanalyse. Zo is er bijvoorbeeld de afhankelijkheid dat gegevens eerst opgevraagd moeten zijn, alvorens deze gewijzigd kunnen worden. Op organisatiegebied moeten hoger


51/61

Master’s Thesis

gelegen functies toegang hebben tot informatie van lager gelegen functies. Deze aspecten zijn uitgewerkt in hoofdstuk 5.3 ‘Koppelen van werkzaamheden aan informatie’. Dat het organisatiemodel niet slechts het doel van schermgeneratie dient, blijkt uit het feit dat het ook kan dienen als middel om de organisatie in te delen, of te herindelen. Dit beantwoordt gelijk de laatste onderzoeksvraag ‘hoe kan de organisatie ondersteund worden in de optimalisering van processen met behulp van het vastgelegde metamodel’. Door het tijdsaspect te koppelen aan een bewerking, waarbij gebruik gemaakt kan worden van historiegegevens die bijgehouden worden bij iedere mutatie, is het mogelijk een schatting te maken van de omvang van bepaalde taken of rollen in de organisatie. Tevens kunnen de prestaties van een rol, groep of afdeling uiteengezet worden, zodat hierover een oordeel geveld kan worden.

10.1 Suggesties voor verder onderzoek In dit onderzoek is een opzet gegeven voor het maken van een user-interface op basis van het uitgebreide informatiemodel. De user-interface is eigenlijk geprojecteerd op een soort template waar gemiddelde gebruiker mee overweg kan. Ik kan me echter voorstellen dat bij meer kennis over de gebruiker (niveau, interessen, favoriete kleur etc) voor iedere willekeurige persoon een toegespitste user-interface is te maken. In mijn afstudeeronderzoek voor de opleiding Hogere Informatica [BA02] heb ik gekeken naar het definiëren van interfaces voor verschillende uitvoerapparaten en verschillende gebruikerstypen vanuit dezelfde databron. Door verschillende transformaties op de databron uit te voeren is het mogelijk de representatie van de gegevens te veranderen, zodat het voor iedereen mogelijk is om waar dan ook de gegevens die hij nodig heeft te raadplegen, ongeacht de capaciteiten van het apparaat en de handicap van de gebruiker. Om dat laatste te demonstreren heb ik een opzet gemaakt voor een interface voor blinden, met gebruik van text-to-speech technieken. Het zou mooi zijn als deze techniek gecombineerd kan worden met het automatisch genereren van de user-interface op basis van het organisatiemodel. Behalve dat het grenzen weghaalt voor gebruikers biedt het hen tevens de door hen gewenste toegang tot gegevens. Dit verhoogt het gebruikplezier. Ik heb een aanzet gegeven voor verder gebruik van het organisatiemodel om de organisatie te helpen zich te verbeteren. Hierin is het echter noodzaak goede gefundeerde statistische algoritmen te gebruiken. Het gebruik van het model in een organisatie is dus tevens verder onderzoeksgebied.


52/61

Master’s Thesis

11 Literatuurlijst [AaHee00]

W. van der Aalst, K. van Hee, Workflow Management: models, methods and systems, Massachusetts Institute of Technology, 2000

[BaHoPr]

A.P. Barros, A.H.M ter Hofstede, H.A. Proper, An Integrated Conceptual Modelling Kernel for Business Transaction Workflows, University of Queensland

[Bar98]

A.P. Barros, On the conceptualization of Workflow Specifications, PhD Thesis, Katholieke Universiteit Nijmegen, Februari 1998

[BA02]

A.C. van Bers, M. Aalbers, XML+XSL WebFrontend, User-Interfaces for the Internet, Hogeschool van Arnhem & Nijmegen, ICA, Mei 2002

[Ber01]

A.C. van Bers, Universal Form Generator Systeemhandleiding, Hogeschool van Arnhem & Nijmegen, 2001

[BHW94]

F.C. Berger, A.H.M. ter Hofstede, Th.P. van der Weide, Supporting Query by Navigation, Katholieke Universiteit Nijmegen, Maart 1994

[BMR96]

F. Benzi, D. Maio, S. Rizzi, Visionary: A Visual Query Language Based on the User Viewpoint Approach, Napier University, Edinburgh, Juli 1996

[BZL96]

G. Bakema, J.P. Zwart, H. van der Lek, Volledig Communicatiegeoriënteerde Informatiemodellering, Ten Hagen Stam, Juli 1996

[Deg01]

D. Degroof, Neveneffecten van ICT, K.U. Leuven (B), Maandblad Vacature April 2001.

[Fre97]

P.J.M. Frederiks, Object-Oriented Modeling Based on Information Grammars, PhD Thesis, Katholieke Universiteit Nijmegen, 1997

[GeHor95]

D. Georgakopoulos, M. Hornick, An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure, University of Georgia, 1995

[Gri82]

J.J. van Grietshuysen, Concepts and Terminology for the Conceptual Schema and the Information Base, 1982

[ISO11404] The International Organization for Standardization, ISO 11404 - Language Independent Datatypes, 1996 [NijHal89]

G.M. Nijssen, T. Halpin, Conceptual Scheme and Relational Database Design, Prentice-Hall, 1989

[HW93]

A.H.M. ter Hofstede, Th.P. van der Weide, Expressiveness in Conceptual Data Modelling, Data Knowledge Engineering, Februari 1993

[KWB95]

A. Kleppe, J. Warmer, W. Blast, MDA Explained: The Model Driven Architecture – Practise and Promise, Addison-Wesley, April 2003

[Lan92]

R.F. van der Lans, Het SQL Leerboek, Academic Service, November 1992


53/61

Master’s Thesis

[MyR92]

B.A Myers, M.B. Rosson, Survey on User-Interface Programming, in: Striking a Balance. Proceedings CHI’92, ACM Press, 1992

[PEG94]

A. R. Puerta, H. Eriksson, J. H. Gennari, & M. A. Musen, Beyond Data Models for Automated User Interface Generation. HCI'94, People and Computers, The University of Glasgow, 1994.

[Pro02]

H.A. Proper, Information System Architectures – Introduction to Business Process Modelling, Katholieke Universiteit Nijmegen, 2002

[Pro03]

H.A. Proper, Da Vinci: Definition & Design of Information Systems, Katholieke Universiteit Nijmegen, 2003

[Pro03b]

H.A. Proper. Informatiekunde; Exacte vaagheid. Katholieke Universiteit Nijmegen, November 2003.

[Pro94a]

H.A. Proper, Interactive Query Formulation using Point to Point Queries, Asymetrix Research Laboratory, Department of Computer Science, University of Queensland Australia, 1994

[Pro94b]

H.A. Proper, Interactive Query Formulation using Query By Navigation, Asymetrix Research Laboratory, Department of Computer Science, University of Queensland Australia, 1994

[Rij02]

D. Rijsenbrij, J. Schekkerman, H. Hendrickx, Architectuur, besturingselement voor adaptieve organisaties, Lemma BV Utrecht, 2002

[RR97]

S.R. Rollinson, S.A. Roberts, A Mechanism for Automating Database Interface Design, Base don Extended E-R Modelling, University of Leeds, Juli 1997

[Sch02]

A. Schinkel, Bank voor Werkkennis, TINFON - Tijdschrift voor informatica onderwijs, April 2002.

[Sha02]

A. Sharp, The 7 deadly sins of Process Modeling, Clariteq Consulting Inc., Februari 2002.

[Slb96a]

E. Schlungbaum, Individual User Interfaces and Model-based User Interface Software Tools, Georgia Institute of Technology Atlanta, November 1996

[Slb96b]

E. Schlungbaum, Model-based User Interface Software Tools – Current state of declarative models, Georgia Institute of Technology Atlanta, November 1996

[VI96]

Verkenningscommissie Informatica. Geen toekomst zonder Informatica – Toekomstverkenning Informatica, Juni 1996

[Wad96]

P. Waddington, Dying for Information? A Report on the Effects of Information Overload in the UK and Worldwide, Reuters United Kingdom, 1996

[WBP01]

Wet Bescherming Persoonsgegevens, Staatsblad, April 2001, Artikel 180.


54/61

Master’s Thesis

11.1 Personen en Bedrijven [ATOS]

Paul Wassenberg, Procesmodelleur ATOS-Origin.

[BiZZ]

BiZZDesign B.V, www.bizzdesign.nl, Spin-off van het Telematica Instituut op basis van de resultaten van het Testbed-project waar o.a ABP, Belastingdienst, IBM, ING aan hebben deelgenomen. Enschede

[BMPI]

Business Process Management Initiative, www.bpmi.org, opgericht door o.a. Cap Gemini Ernst & Young.

[Schk]

Arie Schinkel, Adviseur voor organisatie van ICT-toepassing, Oud-directeur van het Samenwerkingsverband voor Overkoepeling van Automatisering van Gemeenten (SOAG).


55/61

Master’s Thesis

Lijst van Afbeeldingen Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur

1: “Generatie bepaald door invoer” ........................................................................................... 9 2: “Het UoD met de views die door deze scriptie bekeken worden” ............................................. 12 3: “Conceptuele weergave van een feit over het UoD” ............................................................... 12 4: “Conceptueel schema na UC bepaling”................................................................................. 12 5: “Conceptueel schema met UC en TC bepalingen” .................................................................. 12 6: “Gegroepeerd, gelexicaliseerd en gereduceerd informatiemodel” ............................................ 12 7: “DFD van een proces” ....................................................................................................... 12 8: “Bedrijfsprocessen in Testbed Studio” ................................................................................. 12 9: “Informatieproces met zijn taken”....................................................................................... 12 10: “Bewerkingen van de taak Registreren” ............................................................................. 12 11: “Functionele indeling van de organisatie” ........................................................................... 12 12: “De functionele en formele actorindeling binnen een organisatie”.......................................... 12 13: "Verschil van grafische weergave afhankelijk van toestand, type en datatype"........................ 12 14: “UML Diagram van een windows-based database interface”.................................................. 12 15: “Voorbeeld van een logisch informatiemodel” ..................................................................... 12 16: “Een gegenereerde interface voor het geschetste voorbeeld”................................................ 12 17: “Decompositie van processen in een organisatie” ................................................................ 12 18 : “Afbakening van feittypen naar de informatie die nodig is voor een bewerking” ..................... 12 19: “Verantwoordelijken van informatie in FCO-IM” .................................................................. 12 20: “Formele organisatiestructuur” ......................................................................................... 12 21: “In een bewerking moeten alle objecten via relaties bereikbaar zijn” ..................................... 12 22: “FCO-IM Voorbeeld” ........................................................................................................ 12 23: “Voorbeeld van het navigatieprobleem” ............................................................................. 12 24: “Bouwen van een navigatiestructuur op basis van het conceptuele diagram" .......................... 12 25: “Voorbeeld: Collegekaart” ................................................................................................ 12 26: “Voorbeeld: Inschrijfformulier” ......................................................................................... 12 27: “Conceptueel diagram met bewerkingen” ........................................................................... 12 28: “Conceptueel FCO-IM diagram”......................................................................................... 12 30: “Actoren per bewerking” .................................................................................................. 12 31: “Uitbreiding op het FCO-IM metamodel” ............................................................................ 12 32: “Logisch model met bewerkingen”..................................................................................... 12 33: “Tabelstructuur voorbeeld”............................................................................................... 12 34: “Concept van een gegenereerd scherm op basis van het conceptuele model” ......................... 12 35: “Definitie van de user-interface” ....................................................................................... 12 36: “Het schermgeneratie-principe” ........................................................................................ 12 37: “Mapping van Bewerking naar Form” ................................................................................. 12 38: “Navigatierichting bepaalt het uitgangspunt” ...................................................................... 12 39: "Multipliciteitsbepaling ten opzichte van het startpunt" ........................................................ 12 40: “Gecombineerde multipliciteit van een relatie” .................................................................... 12 41: “Mapping van Handeling naar Control”............................................................................... 12 42: "Een voorbeeld van een 1:n:n relatie" ............................................................................... 12 43: "Opdeling van een bewerking t.b.v. de user-interface"......................................................... 12 44: "User-Interface van het voorbeeld" .................................................................................. 12 45: “Mapping van soort Actie naar Control”.............................................................................. 12 46: “Mapping van soort Actie naar Control”.............................................................................. 12 47: “Mapping van Rollen naar Container"................................................................................. 12 48: “Totaalbeeld van het generatieprincipe” ............................................................................. 12 49: “Procesindeling in het metamodel” .................................................................................... 12 50: ”FCO-IM Grafische Symbolen” ..........................................................................................XII 51: “Tekenobjecten bij DFD schema's” ....................................................................................XII 52: “Testbed Studio Grafische Symbolen” ................................................................................XII 53: “FCO-IM Metamodel” .......................................................................................................XII

Lijst van Tabellen Tabel 1: “UC bepaling bij een niet-elementair feittype”........................................................................ 12 Tabel 2: “TC bepaling” .................................................................................................................... 12 Tabel 3: "Voorbeeldpopulatie" .......................................................................................................... 12


56/61

Master’s Thesis

Bijlage A

FCO-IM Grafische Symbolen

Role ...

1

2

Labeltype

volgnr

3

Feittype

4

Objecttype

Constraints

Uniciteit Gelijkheid Totaliteit Uitsluiting 2,3

{1,2,3}

Cardinaliteit Aantallen

Figuur 50: ”FCO-IM Grafische Symbolen”

I

Master’s Thesis

Bijlage B

1. ...

Data Flow Diagram Grafische Symbolen

Proces of Taak

Datastore

Terminator of externe Bron

…

Gegevensstroom

Figuur 51: “Tekenobjecten bij DFD schema's”

II

Master’s Thesis

Bijlage C

Testbed Studio Grafische Symbolen

Bedrijfsproces

Informatieproces

Taak

Bewerking

Actor

Formulier

*

Formulier-relatie

OR-Split

AND-Split

OR-Join AND-Join

Figuur 52: “Testbed Studio Grafische Symbolen”

III

Master’s Thesis

Bijlage D

FCO-IM Repository

Figuur 53: “FCO-IM Metamodel”

IV

Master’s Thesis

Bijlage E

Triggergeneratie op SQL Server 2000

CREATE TRIGGER [trgHistoryUpdate_GESLACHT] ON GESLACHT FOR UPDATE AS INSERT GESLACHTHistory ( GESLACHTActie, [CODEGESLACHT], [OMSGESLACHT], [ID], [chg_User], [chg_Host], [chg_Time] ) SELECT 'BEFORE UPDATE', [CODEGESLACHT], [OMSGESLACHT], [ID], User_Name(), Host_Name(), GetDate() FROM DELETED SELECT 'AFTER UPDATE', [CODEGESLACHT], [OMSGESLACHT], [ID], User_Name(), Host_Name(), GetDate() FROM Inserted

V

OrganisatieModellering

Recommend Documents