EFFICIËNT ONDERHOUD & BEHEER VAN WEBSITES

EFFICIËNT ONDERHOUD & BEHEER VAN WEBSITES Een theoretische bespreking van de mogelijkheden

S. J. Welas

Faculteit der Natuurwetenschappen, Wiskunde en Informatica Afstudeerrichting : Bedrijfsgerichte Informatica Afstudeernummer : 456

Mei 1999

ii

voor Mohamed Sahri Marijs (ter ere van jouw zestigste verjaardag) & voor Rinia Hermien

iii

iv

Voorwoord Het belang van informatiemodellering binnen de wereld van informatiesystemen wordt algemeen erkend. We kunnen daar lering uit trekken en ons inzetten ook voor hypermedia het belang te onderkennen. Deze scriptie is het product van mijn afstudeerproject, de afsluiting van mijn studieperiode aan de Katholieke Universiteit Nijmegen. Tijdens mijn afstuderen ben ik begeleid door drs. Henk Boeke en dr. ir. Theo van der Weide. Mijn dank hiervoor gaat vanaf deze plek naar hen uit. Mijn dank gaat tevens uit naar het thuisfront (mijn ouders) en in intensievere mate naar Zeger van Vreeswijk : jouw bemoeienis tijdens de totstandkoming van de scriptie is niet altijd gekoesterd, maar wel enorm gewaardeerd.

S. J. Welas Nijmegen, 12 Mei 1999

v

vi

Inhoudsopgave 1. Inleiding ...................................................................................................................................... 1 1.1. Probleemstelling .................................................................................................................. 2 1.2. Opbouw scriptie................................................................................................................... 3 2. Huidige situatie Ouders Online ................................................................................................ 5 2.1. Het ontstaan van de website ............................................................................................... 5 2.2. Verantwoordelijkheid medewerkers .................................................................................... 5 2.3. Doelgroep, Karakter & Doelstelling ..................................................................................... 6 2.4. Presentatie van de website ................................................................................................. 6 2.5. Ouderhoud en Beheer van de website................................................................................ 8 2.6. Problematiek........................................................................................................................ 9 2.6.1. Inconsistentie,onvolledigheid en actualiteit .................................................................... 10 2.6.2. Gegevensopslag............................................................................................................. 10 2.6.3. Tijd.................................................................................................................................. 11 3. Efficiënt onderhoud en beheer............................................................................................... 13 3.1. Inefficiëntie bronnen .......................................................................................................... 13 3.2. Onderhouds- en beheer-criteria ........................................................................................ 14 4. Hypermedia Design Methode ................................................................................................. 17 4.1. Hypermedia hype .............................................................................................................. 17 4.2. Design methoden .............................................................................................................. 18 4.2.1. Top-Down view............................................................................................................... 20 4.2.2. Bottom-Up view .............................................................................................................. 24 4.3. De WSDM methode........................................................................................................... 25 4.3.1. User Modeling fase ........................................................................................................ 28 4.3.2. Conceptual Design fase ................................................................................................. 31 4.3.2.1. Object Modeling subfase..................................................................................... 32 4.3.2.2. Navigational Design subfase................................................................................ 35 4.3.3. Implementation Design fase........................................................................................... 37 4.3.4. Implementation fase ....................................................................................................... 38 4.4. Evaluatie beschreven methode ......................................................................................... 38 5. Toepassing hypermedia design............................................................................................. 41

vii

5.1. De keuze maken ............................................................................................................... 41 5.2. De voordelen ..................................................................................................................... 42 5.3. De architectuur .................................................................................................................. 42 5.4. De migratie ........................................................................................................................ 44 5.4.1. Het migratieproces ......................................................................................................... 45 5.4.2. Te verwachten problemen.............................................................................................. 48 6. Rol Active Databases .............................................................................................................. 51 6.1. Een Active Database Management Systeem.................................................................... 51 6.1.1. Dimensies active database ............................................................................................ 52 6.1.1.1. Granularity of korreligheid van updates en regels ............................................... 52 6.1.1.2. Verschillende koppel-modes ................................................................................ 54 6.1.1.3. Atomaire uitvoering van de regel-actie ................................................................ 55 6.1.1.4. Relatie van regel-uitvoering tot transactie-uitvoering........................................... 55 6.1.1.5. Conflict resolutie mechanisme ............................................................................. 56 6.1.1.6. Tijd en bereik van event consumption ................................................................. 56 6.1.1.7. Inspectie van de transactie-geschiedenis ............................................................ 57 6.1.1.8. Samengestelde events en manipulatie event net effect ...................................... 59 6.1.2. Regelsyntax active database ......................................................................................... 61 6.1.3. Core model active database........................................................................................... 64 6.2. Active DBMS en hypermedia systemen............................................................................ 65 7. Evaluatie en conclusie ............................................................................................................ 67 Nawoord ....................................................................................................................................... 69 Lijst van Figuren .......................................................................................................................... 70 Lijst van Tabellen......................................................................................................................... 71 Bibliografie ................................................................................................................................... 72 Index.............................................................................................................................................. 75

viii

1. Inleiding Er zijn verschillende perspectieven om het ‘fenomeen’ Internet te bekijken. De meest voor de hand liggende is natuurlijk vanuit de gebruikerskant, de surfer die op zoek gaat naar voor hem nuttige informatie. Een ander perspectief is dat vanuit de informatieaanbieders, diegenen die de websites tot stand brengen. Vanuit dit laatste perspectief zal het onderwerp van deze scriptie vorm krijgen. Diegenen die zich ertoe wagen één of meerdere websites op te zetten hebben een bepaald doel voor ogen. Het opzetten van een website vormt echter geen grote technische drempel meer. Het wordt pas interessant wanneer naar de organisatie achter de website gekeken wordt. Laten we in deze een website beschouwen die zichzelf als ‘elektrisch’ tijdschrift presenteert. Er is bewust gekozen voor elektrisch in plaats van elektronisch, omdat die woordkeuze meer warmte zou uitstralen en tevens een verwijzing is naar ‘draden en stekkers’ : het staat nog in de kinderschoenen. Het magazine gedeelte van de website ‘verschijnt’ elke maand op het World Wide Web (WWW) en heeft een aantal vaste rubrieken waarvan enkele de mogelijkheid tot interactie bieden. De website is zo georganiseerd dat informatie uit ‘oudere edities’ nog steeds toegankelijk blijft via een archief. Met behulp van de aanwezige zoekfunctie is zo informatie op te zoeken die reeds eerder gepubliceerd is, maar nog steeds relevant. Er zijn vier redacteuren die de website thans vier jaar in bedrijf hebben. Na vier jaar is het aantal pagina’s die de website opbouwen enorm. Er zijn rubrieken die als het ware uit hun voegen barsten en het beheer vergt steeds meer tijd. De website vertoont een thematische structuur die ook in papieren tijdschriften terug te vinden is, de onderliggende gegevens worden echter niet geheel gestructureerd opgeslagen. Uitgekeken wordt naar een manier om het onderhoud en beheer van de website zodanig te organiseren dat het tijdsaspect betreffende het onderhoud drastisch zou afnemen. Er zijn verschillende problemen die een rol spelen waardoor het tijdsaspect op dit moment zo een cruciale rol speelt. De hoeveelheid aan gegevens die niet gestructureerd worden opgeslagen vormt geen basis voor het verminderen van het belang van het tijdsaspect. Verder zorgt diezelfde hoeveelheid aan gegevens voor een overzichtsprobleem. Er is te veel informatie om daar handmatig een checklist van bij te houden. Zo zitten er gegevens in het archief waar de redactie geen weet meer van heeft en het actueel houden hiervan is thans afhankelijk van lezers die daar de redactie over inseinen. De gegevens in het archief krijgen namelijk geen houdbaarheidsdatum toegewezen. Het gaat immers niet over goederen ter consumptie, maar artikelen die handelen over bijvoorbeeld geldende wetten of procedures. In het kader van mijn afstuderen zal ik de mogelijkheden bekijken welke oplossingen voor bovengenoemde situatie een uitweg kunnen bieden. Daarbij zal de huidige 1 situatie van de website van Ouders Online als startpunt dienen.

1

http://www.ouders.nl

1

HOOFDSTUK 1. INLEIDING

2

1.1. Probleemstelling Het onderwerp van mijn afstudeerproject biedt de mogelijkheid tot zowel een inhoudelijke als een strategische doelstelling.

Inhoudelijke doelstelling Aan de hand van een praktijkvoorbeeld nagaan hoe een DataBase Management Systeem kan bijdragen aan een efficiënter verloop van het onderhoud en beheer van een website met onderhoudsen beheerproblemen. De niet-database ondersteunde opslag van de gegevens aanwezig bij de website van Ouders Online zal in deze als praktijkvoorbeeld dienen. Het gaat dus om het identificeren van de wijze waarop de toepassing van aspecten binnen de database technologie kan bijdragen aan het efficiënter verloop van het onderhoud en beheer van websites. De aandacht zal zich met name vestigen op de ondersteuning die een Hypermedia Design methode mogelijkerwijs kan bieden.

Strategische doelstelling De strategische doelstelling bestaat uit het brengen van een advies aan de beheerders van de website Ouders Online betreffende de toepasbaarheid van de resultaten die het afstudeerproject heeft opgeleverd.

Hoofdvraag Kan het gebruik van een Hypermedia Design methode leiden tot verhoging van de efficiëntie binnen het onderhoud en beheer van een website met onderhoudsen beheerproblemen ?

Sub-vragen 1. Hoe ziet de huidige situatie van ons praktijkvoorbeeld eruit ? 2. Wat wordt verstaan onder efficiënt onderhoud en beheer van een website ? 3. Wat is een Hypermedia Design methode ? 4. (a) Welke aspecten van het onderhoud en beheer van een website zijn te realiseren door middel van het toepassen van een Hypermedia Design methode; (b) Welke rol zou een Active Database hier kunnen spelen ? 5. Hoe kan een Hypermedia design methode worden toegepast om tot een onderhoudbare structuur van een website te komen ?


3

1.2. Opbouw scriptie De globale opbouw van de scriptie ziet er als volgt uit. Ten eerste zal in hoofdstuk 2 worden ingegaan op de huidige situatie van de website van Ouders Online waarin tevens de sleutelwoorden onderhoud en beheer [2.5] aan bod komen. Criteria met betrekking tot de onderhoudsaspecten zullen in hoofdstuk 3 aan bod komen. Daarna kan in hoofdstuk 4 verklaard worden wat een Hypermedia Design methode inhoudt. De toepassing van een Hypermedia Design methode wordt binnen de context geplaatst in hoofdstuk 5. De rol die Active Databases kunnen spelen met betrekking tot bepaalde aspecten van een DataBase Management Systeem zullen in hoofdtsuk 6 worden besproken. Tenslotte zal een evaluatie plaatsvinden van het voorgaande en daarop volgend gelijk de conclusie in hoofdstuk 7.


4

2. Huidige situatie Ouders Online In dit hoofdstuk zal getracht worden antwoord te geven op subvraag 1 van de probleemstelling (zie p. 2). Dat zal gebeuren aan de hand van een profielschets van de website van Ouders Online. Ouders Online is een voorbeeld uit de praktijk van een website met onderhoudsen beheerproblemen. Hierbij zal kort ingegaan worden op achtergrond informatie zoals het ontstaan en de presentatie van de website. De problematiek zal wat uitgebreider besproken worden om het onderwerp van de scriptie verder uit te diepen.

2.1. Het ontstaan van de website De website Ouders Online werd in 1995 geïnitieerd door drs. H. Boeke, in samenwerking met drs. P. van Scherpenberg. Het idee is voortgekomen uit interesse voor de mogelijkheden die het medium Internet te bieden heeft in combinatie met een eigen journalistieke achtergrond. Thans hebben vaders een andere rol binnen het gezin dan voorheen en moeders streven veel meer naar een carrière. Dit zijn slechts enkele ontwikkelingen betreffende het ouderschap die hebben benadrukt dat er sprake is van een enorme behoefte aan externe (buiten het gezin) informatie op dit gebied. Gestreefd werd naar een tijdschrift met een zakelijke uitstraling dat tevens informatief, interactief en van hoge kwaliteit zou zijn. Met die instelling is de VOF Ouders Online tot stand gekomen. De VOF is samengesteld uit de twee initiatoren van de website en een 2 derde vennoot : TEQ (voorheen Riverland).

2.2. Verantwoordelijkheid medewerkers De redactie van Ouders Online wordt gevormd door mw. N. Veenma, mw. J. Pardoen, dhr. H. Boeke en dhr. P.van Scherpenberg. Verder is er een lijst van medewerkers die per editie kan verschillen. De taken van TEQ als derde vennoot zijn : 1. Technische ondersteuning : hosting, dwz onderhoud van scripts, systeem engineering. 2. Marketing : Zorgen voor naamsbekendheid, dus promoten van Ouders Online en advertentie acquisitie tot en met de administratieve afhandeling. Deze taken leken gecombineerd te kunnen worden, in de praktijk is de naamsbekendheid aan de redactie te danken. TEQ kon allebeide taken niet aan en heeft zich ontwikkeld op het gebied van de techniek en de marketing verwaarloosd. Ouders Online is op zoek naar een derde partij die de advertentie acquisitie en handeling op zich kan nemen. 2

Een electronische uitgeverij, http://www.riverland.nl

5

HOOFDSTUK 2. HUIDIGE SITUATIE OUDERS ONLINE

6

2.3. Doelgroep, Karakter & Doelstelling Ouders Online is een electronisch tijdschrift, in eerste instantie bedoeld voor (aanstaande) ouders van kinderen tussen de 0 en 12 jaar. Vanaf 1999 wordt ook de periode van de puberteit behandeld. Er wordt naar gestreefd elke maand een nieuwe editie uit te brengen waarvan de hoofdonderdelen worden te vinden zijn in de volgende rubrieken : Magazine, het redactionele gedeelte Forum, de nieuwsgroep Leeszaal, een archief Themapagina’s, sub-websites onder Ouders Online Oneliners, vraag en aanbod advertenties Galerij, geboorte-advertenties en kinderfoto’s De website heeft een commercieel karakter waarvan de toegang gratis is en er geen sprake is van financiële exploitatie van de lezers. Uit eigen onderzoek door middel van een lezers-enquête gehouden in 1997, blijkt ondermeer dat 10 % van de lezers zich in het buitenland bevinden. Er is sprake van een journalistieke en interactieve doelstelling. De journalistieke doelstelling uit zich door de informatieve rubrieken die in elke editie worden gepresenteerd, waarbij de laatste ontwikkelingen op bijvoorbeeld cultureel of wettelijk gebied worden gesignaleerd. Door de mogelijkheid te bieden van informatie-uitwisseling die mogelijk tot discussies kan leiden wordt de interactieve doelstelling in praktijk gebracht.

2.4. Presentatie van de website Een conceptueel ontwerp is net als een database ontwerp vrij van implementatie details en richt zich op de inhoud en structurering van de website. Een ontwerp van de presentatie daarentegen beschouwt de gebruikte implementatie taal, de groepering in pagina' s en de feitelijke ‘ uitstraling’ van de website. Dit onderscheid tussen een conceptueel ontwerp en een ontwerp van de presentatie wordt in [1] gemaakt. Op grond hiervan zal in deze paragraaf worden ingegaan op de presentatie van de website. Voor teksten op papier kunnen doorgaans vier soorten structuren worden gehanteerd [2] : chronologisch, geografisch, thematisch en methodisch. Dezelfde structuur principes kunnen ook op websites worden toegepast, zoals in [2] wordt beschreven. Een beschrijving van de presentatie van de website zal hierop gebaseerd zijn.


7

3

De gebruikte implementatie taal is de huidige standaard HTML . Er is een frames versie beschikbaar van de pagina’s die de rubriek Forum opbouwen, de andere rubrieken (zie paragraaf 2.3) hebben deze optie niet. Tevens worden de ingezonden berichten, bedoeld voor het Forum automatisch geplaatst en een keer per dag handmatig gescreend voor berichten die buiten de orde zijn. De groepering van de pagina’s en de uitstraling van de website wordt tot stand gebracht door de redactionele formule die wordt gehanteerd. Die vindt namelijk zijn weerslag op de vormgeving van de website. De website heeft een logische structuur die de plaatsing van gegevens min of meer dwingend oplegt. De website is in principe thematisch opgebouwd. Dat wil zeggen dat er een indeling naar rubrieken is die van dezelfde orde zijn, onafhankelijk van elkaar en hetzelfde gewicht hebben. Hoewel ook gesproken kan worden van een methodisch gestructureerde website, omdat er een thematische structuur met vaste thema’s aanwezig is, is dat niet voor de volle 100 % terecht. Er zijn in elke editie wel terugkerende elementen, maar door gebrek aan ruimte worden er vaak keuzes gemaakt die leiden tot enkele verplichte items en de resterende losse items. Toch kan gesteld worden dat de volgende indeling van kracht is : Welkomspagina Inhoudsopgave Magazine (Nieuws, Columns, Opinies, Recenties, etc) Discussieforum Archief Vraag- en aanbodrubriek Prikbord voor aankondigingen Zoekfunctie Uit deze indeling zijn inhoudelijke rubrieken ontstaan (zie paragraaf 2.3). Het Forum is de enige rubriek waar enige chronologie in zit. Binnen alle rubrieken wordt gestreefd naar een zo plat mogelijke hierarchie om te voorkomen dat de gebruikers gedesoriënteerd raken en om het aantal muiskliks te beperken. Het principe van het beperken van het aantal items staat bekend als Miller’s Law on the Magic Number (‘ span of immediate memory’) [3] die zegt dat de mens 7 (+/- 2) stukjes informatie tegelijk aankan. Meer zou leiden tot een aanslag op het korte termijn geheugen. Aan de andere kant leidt een platte hierarchie ook tot problemen. Het aantal items neemt toe naarmate de website groeit en het wordt moeilijk om vast te houden aan Miller’s Law. Bovendien kan de vormgeving eronder leiden.

3

HyperText Markup Language.


8

2.5. Ouderhoud en Beheer van de website Onderhoudsproblemen betreffende een website worden in de literatuur [1] doorgaans vergeleken met die problemen die bij databases ook een rol spelen. Ze worden samengevat onder de volgende noemers : Redundantie Inconsistentie Onvolledigheid Actualiteit De nadruk ligt duidelijk bij gegevens, terwijl er sprake kan zijn van meer onderhoudsen ook beheerproblemen van een website. Voordat gekeken kan worden naar de problemen, zou eerst een beschrijving van de handelingen die leiden tot bovengenoemde problemen op zijn plaats zijn. Onder het onderhoud en beheer van een website vallen de handelingen die verricht moeten worden om de website in zijn geheel te kunnen presenteren. Enkele van dit soort werkzaamheden zijn : 1. Het vergaren van informatie die relevant is voor de website. 2. Het daadwerkelijk verwerken van de informatie in de reeds bestaande structuur van de website. 3. Het actueel en consistent houden van zowel reeds bestaande informatie, als de vormgeving. 4. Het afhandelen van elektronische post (email) ten behoeve van de website, dit omvat tevens de interne afhandeling van email binnen de organisatie. 5. Het bepalen van kwaliteitscriteria waaraan de website moet voldoen binnen de gestelde doelstellingen van de website. 6. Het bewaken van de kwaliteit door middel van bovengenoemde kwaliteitscriteria. 7. Technische handelingen zoals het HTML-coderen en uploaden van bestanden. 8. Budgettering. 4

9. Uitvoeren van een zelfanalyse, bijvoorbeeld een SWOT analyse ter ondersteuning van de beleidsvoering. Sommige van deze handelingen vinden dagelijks plaats, andere minder frequent. De onderhoudsen beheerwerkzaamheden die bij Ouders Online worden verricht kunnen aan de hand van deze lijst nader worden gespecificeerd. Het afhandelen van email (4) bestaat bijvoorbeeld uit : 4

Strenghts Weaknesses Opportunities Treaths.


9

De archivering van emailberichten. Het beantwoorden van email aan de redactie. Geposte email op de website van b.v. het Forum screenen (6). Email met b.v. uitgevers, de leveranciers van potentiële informatie, de overheid, 5 het maatschappelijk middenveld , medewerkers en vrijwilligers, kortom met een netwerk van contacten. Verwerken van email van interactieve onderdelen die niet geautomatiseerd zijn (dit valt onder (2) en (3), het verwerken van informatie en het actueel houden). Het gaat om de volgende onderdelen : - One-liners : vraag en aanbod. - Galerij : foto’s en foto advertenties. - Vragen aan de experts. - Prijsvraag oplossingen. - Aanvullingen op eerder geplaatste artikelen en oude prijsvragen. Interne berichten van de redactie i.v.m. overleg, dit vergt correspondentie over en weer van de redactie en de medewerkers, de experts en taalkundigen (dit valt onder (1), (5) ).

Verder zijn er ook nog : Onderdeel (7) is een typische handeling die door de redactie wordt uitgevoerd en onderdeel (8) gaat over het financiële plaatje. De jaarlijkse kosten lopen op tot 7 à 8 ton, waarbij meer geneigd wordt naar 8 ton wanneer de betaling (het loon) van de medewerkers ook wordt beschouwd/meegerekend. Zoals de situatie nu is, is er sprake van een uitwisseling van goederen : betaling in natura, dat wil zeggen al lerend onderwijs over het medium voor iemand die interviews maakt, of CD’s voor iemand die programma’s becommentarieert. Onderdeel (9) kan goed dienst doen bij het werven van sponsors en toekomstige aandeelhouders.

In paragraaf 2.6 wordt ingegaan op de problemen die genoemde handelingen met zich mee brengen.

2.6. Problematiek De website wordt thans, gezien de bedrijfsvorm, uit eigen zak van de eigenaars gefinancierd. Dit wordt aangevuld met inkomsten uit advertenties. Deze vorm van financiering is echter niet toereikend en onmogelijk vol te houden op de lange duur. Zonder adequate financiering is het onmogelijk een groep vaste medewerkers in dienst te nemen om het aantal persoons-uren dat nu wordt gemaakt te verdelen. Een adequate financiering zou echter niet alle problemen gelijk oplossen, vandaar dat in de volgende paragrafen verder op de problemen wordt ingegaan. 5

Organisaties voor jeugdzorg, kraamzorg etc.


10

2.6.1. Inconsistentie,onvolledigheid en actualiteit Doordat het aantal pagina’s van de website steeds toeneemt, ontstaat een overzichts probleem ten opzichte van verouderde informatie die zich in het archief of de leeszaal bevindt. Informatie raakt verouderd wanneer die niet meer juist is door veranderingen die zich thans hebben afgespeeld (bijvoorbeeld wetten die zijn aangepast). In de praktijk leent zich daar de volgende oplossing voor, namelijk : de bezoekers van de website laten aangeven wanneer er informatie aangetroffen is die niet meer correct is. Er heeft zich een soort van online-gemeenschap gevormd. Een online-gemeenschap kan zich het best beschrijven door het feit dat subgroepen gevormd worden door mensen die affiniteit voelen of ervaren ten opzichte van elkaar. Zo hebben zich subgroepen gevormd door ouders van Grote Gezinnen of Een-ouder gezinnen. Door gedeelde interesse in sociale aspecten worden ook chat groepen opgericht. De online-gemeenschap suggereert een zekere betrokkenheid van de lezers bij de website waardoor ze zich verbonden voelen en er zo sneller toe overgaan om de redactie erop attent te maken wanneer informatie wordt aangetroffen die niet meer actueel is. Op deze manier wordt vertrouwd op de lezers door de verbondenheid die zij voelen met de website. Voor de website komt dit neer op een oplossing voor het inconsistentie-,onvolledigheid- en actualiteitsprobleem. In het voorgaande is in het rijtje van bovengenoemde problemen redundantie ook genoemd. Hoewel redundantie binnen de sfeer van informatiesystemen over het algemeen als negatief wordt ervaren, hoeft dat met betrekking tot websites niet persé het geval te zijn. Denk bijvoorbeeld aan de overzichtelijkheid van een pagina van een website. Eenmaal een paar pagina’s verder dan de hoofdpagina is de gebruiker het overzicht al snel kwijt. Op dit punt is een korte weergave aan het eind van elke pagina, weliswaar redundant, maar welkom. Redundantie is dus niet noodzakelijkerwijs een presentatieprobleem, maar eerder een probleem van de opslag van gegevens.

2.6.2. Gegevensopslag De gebruikersvriendelijkheid en populariteit van de website leiden tot enorm veel forumberichten, waardoor de overzichtslijst te lang wordt. Het moment van verplaatsing naar het archief was vroeger een maand, later 2 weken, thans 8 dagen. Het Forum is zodanig opgezet dat de gegevens in een onderliggende SQL database (Standard Query Language database) worden opgeslagen. Desondanks maakt de enorme hoeveelheid aan informatie de website traag. Hoewel (een deel van) de data dus gestructureerd wordt opgeslagen in een database, blijft de response tijd onder de maat. Het vergroten van de bandbreedte van de webserver biedt slechts een tijdelijke oplossing. Dit vormt een probleem van gegevensopslag. Vooral op de lange termijn gezien, is de website ‘ uit zijn voegen’ aan het groeien door de enorme hoeveelheid aan gegevensverkeer.


11

2.6.3. Tijd Het onderhouden van alle pagina’s kost, door de enorme hoeveelheid aan pagina’s, te veel tijd. Vooral wanneer er, zoals hier, sprake is van een aantal medewerkers op vrijwillige basis. Dit probleem heeft te maken met tijdgebrek. Verder zijn er ook nog enkele problemen van een andere aard die zich voordoen : De website vormt een aantrekkingspunt voor sociale discussies. Dit uit zich doordat er sociale ontmoetingspunten worden gecreëerd in plaats van inhoudelijke discussies. Dit is tegen het beleid dat gevoerd wordt door de redactie. Enig afschrikbeleid dat gevoerd is werkt averechts : het toepassen van cynisme komt niet over en de lezers reageren enthousiast. Het profiel van de doelgroep is aan het veranderen. Aanvankelijk ging het om hoger opgeleiden van gemiddeld HBO/WO niveau, thans is dat sterk aan het verbreden.(Deze informatie is verzameld door toedoen van het houden van een lezersenquete in 1997 door de website). Hier zal op ingespeeld moeten worden, waardoor het karakter van de website zou kunnen veranderen. De gebruikersvriendelijkheid en populariteit van de website leiden tot enorm veel emailberichten, waardoor de overzichtslijst te lang wordt. Het moment van verplaatsing naar het archief was vroeger een maand, later 2 weken, nu 8 dagen. De website wordt erg traag door de hoeveelheid aan informatie. De financiering van het geheel. Na vier jaar waarin de vennoten zelf de kosten dekten, zijn er thans sponsors in zicht die voor een financiële doorbraak zouden kunnen zorgen. De bedrijfsvorm VOF is niet handig, het zal geprofessionaliseerd moeten worden door bijvoorbeeld een BV. Een BV biedt een platform om te investeren, een VOF kan geen aandelen uitzetten. In hoofdstuk 3 zal nader worden ingegaan op aspecten van de thans geschetste problematiek welke in het kader van de scriptie relevant zijn. Daarbij zal worden ingegaan op het efficiënt onderhoud en beheer van een website.


12

3. Efficiënt onderhoud en beheer Het onderhoud van websites beslaat veel meer en beschouwt ook andere aspecten dan bij conventionele software informatiesystemen. Met de ontwikkeling van websites gaan namelijk ook cognitieve en esthetische aspecten gepaard [5, 10]. In de volgende twee paragrafen zullen eerst de inefficiëntie aspecten aan bod komen. Tevens zal besproken worden welke criteria gelden wanneer het over 6 efficiënt onderhoud en beheer gaat.

3.1. Inefficiëntie bronnen Bij het beschouwen van efficiënt onderhoud en beheer van een website is het handig eerst de bron(nen) van inefficiëntie te identificeren. Dit is mogelijk door deze uit de problematiek te lichten waarin ze verscholen liggen. Voor de website van Ouders Online (zie hoofdstuk 2) zijn de volgende bronnen van inefficiëntie te onderkennen : A. Met betrekking tot de gegevens, de data van de website : 1. Inconsistentie 2. Onvolledigheid 3. Actualiteit 4. Opslag B. Met betrekking tot de presentatie van de website : 1. Lange overzichtslijsten 2. Cognitieve aspecten

C. Met betrekking tot het karakter van de website : 1. Sociale discussies i.p.v. inhoudelijke discussies 2. Profielverandering D. Met betrekking tot de organisatie achter de website : 1. Financiering van de website 2. Niet professionele bedrijfsvorm

6

Zie subvraag 2 van de probleemstelling, p. 2

13

HOOFDSTUK 3. EFFICIËNT ONDERHOUD EN BEHEER

14

In een organisatie is er altijd sprake van een besturing van de organisatie. (Hiermee gaan beleid en besluitvorming gepaard.) Besturing kan plaatsvinden op drie niveaus : strategische, tactische en operationele besturing. Op elk niveau doet zich de besturingscyclus Plannen-Uitvoeren-Controle voor [21, p. 22-25]. Twee van de genoemde bronnen van inefficiëntie, namelijk die met betrekking tot het karakter van de website en de organisatie erachter ( C en D), bevinden zich op het strategische en tactische besturingsniveau. Dit valt buiten het bereik van de scriptie en verder zal hier geen aandacht aan worden besteed. Inefficiëntie bronnen A en B echter, zijn onderhouds aspecten die verbeterd zouden kunnen worden. De bronnen van inefficiëntie, betrekking hebbend op de gegevens en de presentatie van de website (A en B), zouden geëlimineerd kunnen worden door een migratie naar een DBMS-ondersteunde website te overwegen. Dit zou bereikt kunnen worden door een herstructurering van de website door middel van het toepassen van een hypermedia design methode. In het volgende hoofdstuk wordt daarop ingegaan, namelijk een methode om een website op een gestructureerde manier op te zetten.

3.2. Onderhouds- en beheer-criteria Onderhoud aan een website kan gezien worden als een verzameling van activiteiten en/of handelingen die uitgevoerd moeten worden om het beleid van de organisatie tot uitvoering te brengen. In [21, p. 24] wordt beleid als volgt gedefinieerd : ‘ De wegen waarlangs en de middelen waarmee een organisatie haar doeleinden tracht te realiseren.' Het gaat in wezen dus om het halen van de doelstelling die ten grondslag ligt aan de website. Onderhoud zou derhalve gerekend kunnen worden tot operationeel beleid : ‘ operationeel beleid heeft betrekking op de activiteiten die op de werkvloer plaatsvinden.’

In paragraaf 2.5 zijn reeds enkele voorbeelden genoemd die betrekking hebben op het onderhoud aan een website. De verzameling van activiteiten die tot het onderhoud van conventionele software informatiesystemen behoort zou volgens [19] verdeeld kunnen worden in drie groepen : Perfectief onderhoud Adaptief onderhoud Correctief onderhoud Deze drie groepen van onderhoud zouden ook op website onderhoud van toepassing kunnen zijn, omdat een website beschouwd kan worden als een informatiesysteem.


15

Perfectief onderhoud is onderhoud dat wordt verricht ter verbetering van het systeem op een bepaalde manier, zonder de functionaliteit aan te tasten (tunen van het systeem). Toegepast op websites, kan dit bijvoorbeeld te maken hebben met de presentatie van een website. Van het onderhoud van de presentatie van een website zijn tal van voorbeelden genoemd in paragraaf 2.5. Omdat het onderwerp van de scriptie gericht is op de structuur van een website en niet de populatie (de invulling of inhoud), zullen de cognitieve en esthetische aspecten van de presentatie buiten beschouwing worden gelaten.

Adaptief onderhoud is onderhoud dat vereist is omdat er veranderingen hebben plaatsgevonden in de omgeving van het systeem (evolutie van het systeem). Een goed voorbeeld hiervan is onderhoud dat plaatsvindt in verband met technologische ontwikkelingen. Dit soort onderhoud is sterk afhankelijk van de laatste technologische ontwikkelingen. Er gaat meestal een grote investering mee gepaard. Het overstappen naar en/of het integreren met een nieuwe manier van werken kan niet licht opgevat worden en vergt beslissingen op beleidsniveau. De beslissing om over te stappen op iets nieuws zal altijd wel een of andere migratie inhouden. Een concreet voorbeeld van adaptief onderhoud is de migratie van een ‘ gewoon netwerk’ naar een intranet.

Correctief onderhoud is het corrigeren van systeemfouten die niet eerder zijn ontdekt tijdens de validatie van het systeem (herstel van het systeem). Een concreet voorbeeld hiervan, toegepast op websites is een andere (verbeterde) manipulatie van de input die gegeven wordt bij een interactief website onderdeel.

Beheer aan een website suggereert niet alleen het verrichten van onderhoud op de werkvloer, maar tevens de beslissingen die op het beleidsniveau van de organisatie genomen (moeten) worden. Het beheer van een website omvat dus onder meer het onderhoud aan de website. In deze scriptie worden de termen onderhoud en beheer steeds afwisselend gebruikt maar er wordt hetzelfde mee bedoeld. Met efficiënt (‘ doing things right’) [21, p. 45] wordt bedoeld de relatie tussen de verkregen resultaten en de opgeofferde middelen. Toegepast op onderhoud en beheer betekent dat, dat het onderhoud en beheer minimaal moet worden gehouden zowel qua manuren als bestede uren omgezet in geld (ervan afgezien of het doel waarvoor het gebeurt wel juist is). Bovendien moet het eenvoudig uit te voeren blijven. (Dit verschilt enigszins met ‘doing the right things’ : effectief onderhoud en beheer.) Er zit dus een tijdsaspect verbonden aan efficiënt onderhoud. Daarbij wordt er van uitgegaan dat het effectieve aspect van het onderhoud en beheer impliciet ten grondslag ligt aan het nastreven van de doelstelling van de organisatie.


16

Om efficiënt onderhoud en beheer van de website te bewerkstelligen zullen de ouderhoudswerkzaamheden zodanig verricht moeten worden dat er een duidelijk merkbare vermindering in bestede uren is. Tevens mag er geen sprake zijn van complexere taken. Het onderhoud dient zich te beperken tot het perfectief onderhoud dat bovengenoemd is. Deze drie criteria kunnen gerealiseerd worden door het verhelpen van de inefficiëntie bronnen A en B. Als de data van de website op een gestructureerde manier zou worden opgeslagen in een database kunnen de problemen van inconsistentie, onvolledigheid en opslag verholpen worden. Het actualiteitsprobleem zou mogelijkerwijs verholpen kunnen worden door gebruik van een active database (in hoofdstuk 6 wordt deze mogelijkheid besproken). Een hypermedia design methode houdt ook rekening met de presentatie van de website. De lange overzichtslijsten en cognitieve aspecten zouden met het gebruik van een hypermedia design methode aangepakt kunnen worden. De website dient dus zodanig gestructureerd te worden opgezet dat enkele onderhoudswerkzaamheden geautomatiseerd kunnen plaatsvinden. Ondersteuning van een DataBase Management Systeem zou dit kunnen bewerkstelligen. De functionaliteit van een DBMS zit verscholen in de opslaglaag van een gestructureerd opgezette website (Figuur 10 (c), p. 43). In hoofdstuk 4 worden enkele hypermedia design methoden en engines besproken omdat die zo een DBMS in de opslaglaag hebben zitten.

4. Hypermedia Design Methode In dit hoofdstuk zal worden ingegaan op wat een Hypermedia Design Methode is en 7 welke op dit moment betekenis hebben binnen de toepassingswereld . Een methode zal uitgebreid worden beschreven, teneinde een beter beeld te krijgen van hypermedia.

4.1. Hypermedia hype Hypermedia is hypertext met multimedia. Hypertext (niet-lineaire tekst) kan gezien worden als een wijze van informatiebeheer alwaar data wordt opgeslagen in een netwerk van knopen die verbonden zijn door links (een soort van database). Een knoop kan daarbij verschillende soorten data bevatten, bijvoorbeeld tekst, audio, video, bron code en grafische data [6, 20]. Een essentieel aspect van hypertext is het concept van machine-ondersteunde links, waardoor een niet-lineaire organisatie van tekst mogelijk is. Een hypermedia toepassing is een toepassing waarbij gebruik is gemaakt van hypermedia. De reeks van hypermedia toepassingen is niet gelijksoortig, er zijn elektronische boeken, product catalogi en presentaties, leren en oefenen m.b.v. multimedia software, website ontwikkeling etc. Het meest opvallende aan hypermedia toepassingen is de multimediale representatie van informatie en objecten. Verder worden hypermedia toepassingen gekarakteriseerd door speciale elementen en structuren. Bijvoorbeeld kan een presentatie van informatie zodanig zijn, dat de stroom van wat kan gebeuren of wordt gepresenteerd vergeleken kan worden met een filmscript (denk bijvoorbeeld aan guided tours). Hypermedia Design is het ontwerpen van hypermedia toepassingen. Een hypermedia design methode is een proces dat gevolgd kan worden om te komen tot het ontwerp. Zo een ontwerp kan geïmplementeerd worden door gebruik te maken van de ondersteuning van een hypermedia engine. Een hypermedia engine (website ontwikkelomgeving) is een abstracte machine die via een interface toegang biedt tot hypermedia structuren om die te kunnen aanpassen en manipuleren [22] (zie paragraaf 4.2.2 voor voorbeelden). Dit kan gebeuren aan de hand van het ontwerp dat voortgekomen is uit de hypermedia design methode. Het ontwerp en de ontwikkeling van hypermedia toepassingen bestaat uit verschillende activiteiten op opslag-, toepassings- en presentatie-niveau. Bij een project ter ontwikkeling van een hypermedia toepassing zouden allerlei vakmensen betrokken kunnen worden : grafische ontwerpers, schrijvers, bibliothecarissen, musici, evenals programmeurs, systeem analisten en gebruikers. Een hypermedia toepassing vergt de beschouwing van esthetische en cognitieve aspecten. Binnen een traditionele software ontwikkelomgeving zijn die aspecten irrelevant. Er is dus behoefte aan speciale methodologiën en tools om het ontwerp en de ontwikkeling van hypermedia toepassingen te ondersteunen [13].

7

Zie subvraag 3 van de probleemstelling, p. 2.

17

HOOFDSTUK 4. HYPERMEDIA DESIGN METHODE

18

In de volgende paragraaf zal ingegaan worden op bestaande hypermedia design methoden en hypermedia engines.

4.2. Design methoden Zoals reeds in de vorige paragraaf is aangegeven is een hypermedia design methode een methode om hypermedia toepassingen op een gestructureerde en systematische manier te ontwerpen. In de context van websites, wordt in [1] beargumenteerd dat het gebruik van een goede ontwikkelmethode zou kunnen bijdragen aan een oplossing van de onderhoudsproblemen die reeds genoemd zijn in paragraaf 2.5 : redundantie, inconsistentie, onvolledigheid en actualiteit. In [10] wordt verder uitgelegd hoe een gestructureerde aanpak bijdraagt aan het begrip dat mensen zich van de inhoud van een website vormen (het zogeheten ‘ mentale model’). Er is nog geen formeel model waaraan hypermedia design methoden geëvalueerd zouden kunnen worden [5]. Hierdoor is het niet mogelijk op een eenduidige manier vast te stellen of er sprake is van een adequaat ontwerpproces van hypermedia design methoden. Dit betekent dat er ook geen mechanisme is ter verbetering van bovengenoemd ontwerpproces. Teneinde de design methoden op een structurele manier te kunnen beschrijven, zal gebruik worden gemaakt van het raamwerk dat in [8] wordt genoemd. In dit raamwerk kunnen verschillende aspecten van een informatiesysteem ontwikkelmethode gevangen worden. Figuur 1 geeft hier een voorstelling van. Dezelfde algemene structuur zal gehanteerd worden voor het beschrijven van de bestaande hypermedia design methoden in de volgende paragraaf. De concepten die in Figuur 1 genoemd worden hebben betrekking op het volgende : In de way of thinking worden de beginselen en onderliggende doelen van een methode beschreven. De way of controlling bevindt zich op het bestuursniveau. Hier zijn aspecten die betrekking hebben op project management aan de orde. Die kunnen tijd, middelen en kwaliteit zijn. De way of modeling (product georiënteerd) beschrijft de modelleer concepten, de betreffende regels en de onderlinge relaties en ook de representaties van deze concepten. In de way of working (proces georiënteerd) wordt de strategie bepaald waarmee een informatiesysteem ontwikkeld zal worden. Dit bestaat uit de identificatie van relevante taken van het ontwikkelproces en de volgorde van de taken. De way of supporting wordt gedefinieerd als een verzameling van tools. Tools vormen middelen ter ondersteuning van de uitvoering van systeemontwikkeltaken. De way of modeling en de way of working bevinden zich op operationeel niveau.


19

way of thinking

way of controlling

way of modeling

managerial

way of working

product oriented

operational

process oriented

way of supporting

Figuur 1 : Raamwerk ter beschrijving van een methode

Het is van belang op dit punt op te merken dat het hier gaat om de beschrijving van methoden en niet een methodologie. Een methode [16, p. 18] is een gedisciplineerd proces dat gevolgd kan worden om een verzameling van modellen te genereren. Deze modellen beschrijven aan de hand van een wel-gedefinieerde notatie de verschillende aspecten van het te ontwikkelen software systeem. Een methodologie [16, p. 18] is een verzameling van methoden die toegepast zijn tijdens de software ontwikkelingscyclus en die verenigd zijn door een algemene, filosofische aanpak. Er zijn verschillende manieren om tegen genoemd raamwerk aan te kijken. In [19, p. 68] worden drie gangbare manieren genoemd om een ontwerpproces te beschouwen : (1) Top-Down gestructureerd ontwerp, (2) Data-driven ontwerp en (3) Object-georiënteerd ontwerp. Bij het Top-Down gestructureerd ontwerp wordt een algoritmische decompositie gebruikt om een groot probleem op te splitsen in kleinere delen. Aan de hand hiervan kan gesproken worden van een Top-Down view [17, p. 15-20]. De hypermedia design methoden kunnen het best aan de hand van een TopDown view besproken worden. Naast een Top-Down view kan er ook sprake zijn van een Bottom-Up view.


20

Vanuit de Top-Down view wordt dus eerst een grove formulering bepaald (op een hoog abstractie niveau) en dat wordt verder verfijnd tot een mogelijk gedetailleerd niveau. Bij de Bottom-Up view wordt gewerkt vanuit een gedetailleerd niveau en door middel van samenstellingen wordt een algemene formulering verkregen (meestal een concrete aanpak of ad hoc tool). De genoemde views hoeven niet noodzakelijk complementair te zijn. In de volgende paragrafen zal getracht worden aan de hand van genoemde views de ontwerpmethoden te beschrijven.

4.2.1. Top-Down view In [4] wordt een overzicht gegeven van de state of the art betreffende hypermedia design methoden en bestaande hypermedia engines. De methoden die worden genoemd zijn HyDev, OOHDM en RMM. In de volgende summiere beschrijving is de way of controlling niet van toepassing (het bevindt zich namelijk op het bestuursniveau). HyDev : De way of thinking HyDev staat voor HYpermedia DEVelopment en past een modelgerichte aanpak toe om hypermedia toepassingen te ontwerpen [9]. In vergelijking met de ontwerpcyclus bij conventionele software ontwikkeling vindt ook bij het ontwerpen van hypermedia toepassingen een requirements analyse plaats. Deze concentreert zich echter meer op de inhoud en kwaliteit van de presentatie. De idee achter HyDev is dat een hypermedia toepassing gebaseerd is op een verzameling van objecten met mogelijk complexe relaties onderling [9]. De way of modeling Het ontwikkeltraject bestaat uit verschillende fasen, waarbij de nadruk ligt bij de analyse en het ontwerp, de eerste fasen van het ontwikkeltraject. Tijdens de analyse en ontwerp fasen worden er drie modellen gemaakt om de structuur, de inhoud en de presentatie van een website te beschrijven : het domein model, het instantie model en het representatie model [9]. Het domein model wordt grafisch gerepresenteerd en gebruikt verschillende klassen waaronder ook de speciale N-classes (klassen van narrative structuring units), Sclasses (klassen van objecten met een spatial dimension) en A-classes (klassen van agents). De notatie is in UML (Unified Modeling Language). Het instantie model wordt opgebouwd uit instanties van de klassen uit het domein model en geïnstantieerde relaties. Ook het instantie model wordt grafisch weergegeven. De instanties worden weergegeven als knopen en de lijnen ertussen vormen de relaties tussen de instanties. Niet alle in het instantie model voorkomende objecten hoeven te corresponderen met een klasse uit het domein model.


21

Het representatie model bevat aspecten die te maken hebben met de presentatie van objecten en de gebruikers interactie. De input is afkomstig van de twee vorige modellen. Het gaat daarbij vooral om de attributen van een object (welke en hoe) die aan de gebuiker wordt getoond. Enerzijds wordt grondig gespecificeerd welke media object typen nodig zijn ( bijvoorbeeld tekst, grafische en beeld aspecten, audio etc) en ook een lijst van de output van de media (audio kanalen, externe apparaten, etc.). Anderzijds echter dient enige abstractie in acht te worden gehouden door bijvoorbeeld niet zodanig in detail te treden over het formaat van de data files of hun concrete namen. De resterende fasen van HyDev zijn de Specification & Design fase en de Implementation fase. OOHDM : De way of thinking OOHDM (Object Oriented Hypermedia Design Method [14]) is een uitbreiding van HDM, de Hypermedia Design Model. OOHDM past een modelgerichte aanpak van hypermedia toepassingen toe die varieert tussen een iteratieve, incrementele en prototype-gebaseerde manier van ontwikkeling. In OOHDM worden hypermedia toepassingen vanuit een object georiënteerd perspectief benaderd. Daarbij wordt een hypermedia toepassing gezien als een navigatie view op het conceptuele domein. De way of modeling & de way of working Het ontwikkeltraject bestaat uit vier fasen : conceptual design, navigational design, abstract interface design en implementation. In elke fase wordt een model gemaakt óf het resultaat van de vorige fase wordt verder uitgebreid [14]. De conceptual design fase [14] levert een object georiënteerd model op van het toepassingsdomein. Het model bestaat uit een klassen- en instantie-schema dat opgebouwd is uit attributen, subsystemen en relaties. De toekomstige gebruikers en/of taken van de toepassing worden niet beschouwd, alleen de semantiek betreffende het toepassingsdomein. De navigational design fase [14] kan verschillende navigatie modellen opleveren. Elk navigatie model drukt een navigatie view uit. Een navigatie view wordt vanuit het gezichtspunt van de typen van toekomstige gebruikers (en hun handelingen) gemaakt. Omdat er meestal verschillende typen (toekomstige) gebruikers te onderkennen zijn, is er sprake van verschillende navigatie views (dit op één en hetzelfde conceptuele domein), en zo dus ook verschillende navigatie modellen. De navigatie structuur van een hypermedia toepassing wordt gedefinieerd in termen van het navigatie verband dat afgeleid wordt uit de navigatie klassen Nodes, Links, Indices en Guided Tours. De navigatie klassen reflecteren de gekozen view op het toepassingsdomein en hun definitie bouwt de navigatiestructuur op. In [14] wordt verder ingegaan op genoemde navigatie klassen.


22

In de abstract interface design fase [14] wordt een abstract interface model gemaakt. In dit model wordt beschreven hoe navigatie objecten zichtbaar zullen zijn voor de gebruiker, welke interface objecten de gebruiker zal waarnemen en hoe navigatie mogelijk is. Ook synchronisatie aspecten worden beschouwd. Om het concept van ‘ verschillende interfaces voor hetzelfde navigatie model’ te ondersteunen wordt in deze fase een strikte scheiding gehanteerd tussen navigatie aspecten en abstract interface design aspecten. Er worden ADV’s (Abstract Data Views) gebruikt om de user interface te beschrijven. Door in de implementation fase [14] de navigatie modellen en de abstracte interface modellen af te beelden op objecten uit de implementatie omgeving, wordt een feitelijke hypermedia toepassing operationeel gemaakt.

RMM : De way of thinking RMM is de afkorting van Relationship Management Methodology, afgeleid van de visie dat het managen van de relaties tussen informatie objecten essentieel is bij hypermedia. In principe is het een lineaire methode maar het is ook mogelijk om tijdens het ontwerpproces feedback loops, klonen en prototyping te verkrijgen om een combinatie van een Top-Down en Bottom-Up aanpak te bewerkstelligen [13]. De basis van RMM wordt gevormd door RMDM, Relationship Management Data Model, een modelleringstechniek ter beschrijving van de informatie objecten en navigatie mechanismen van een hypermedia toepassing. Het behoort tot de categorie van ER (Entity-Relation) methoden. De way of modeling & de way of working De RMM methode bestaat uit zeven fasen, waarvan de eerste drie de belangrijkste zijn : ER Design, Slice Design en Navigational Design [13]. De ER Design fase is te vergelijken met de conceptual design fase in OOHDM, met het verschil dat hier gebruik wordt gemaakt van ER in plaats van OO. Deze fase levert een ER diagram op dat het informatie domein van de toepassing beschrijft. In de Slice Design fase wordt een slice diagram gemaakt. Een slice is een deelverzameling (groepering) van de attributen van een entiteit. In een slice diagram worden slices en de tussenliggende links gedefinieerd, waardoor er een soort ‘ verrijkt’ ER diagram ontstaat met entiteiten, relaties en slices. De informatie wordt als het ware gegroepeerd in de slices. In de Navigational Design fase worden de relaties tussen de entiteiten uit het ER diagram toegankelijk gemaakt voor navigatie. Alle navigatie paden worden afgeleid van de relaties die tussen de entiteiten bestaan en worden weergegeven in termen van entiteits-eigenschappen en relaties.


23

De resterende fasen zijn : conversion protocol design, user-interface design (paginaindeling voor elk object uit het RMM diagram), runtime behavior design (aspecten zoals link traversal, backtracking en navigatie mechanismen) en implementation [13].

Samenvattend In Tabel 1 worden de verschillende fasen van de methoden die zojuist besproken zijn op een rij gezet.

HyDev

1. Analysis

OOHDM

1. Conceptual Design

RMM

1. ER Design

2. Slice Design

2. Navigational Design

3. Navigational Design 4. Conversion Protocol Design

2. Specification & Design

3. Abstract Interface Design

5. User-Interface Design

6. Runtime Behavior Design

3. Implementation

4. Implementation

7. Implementation

Tabel 1 : Verschillende fasen genoemde hypermedia design methoden

De fasen die zich op dezelfde rijhoogte bevinden komen enigszins met elkaar overeen. Het gaat dan voornamelijk om dezelfde activiteiten die plaatsvinden. Ondanks het feit dat geen van bovengenoemde ontwikkelmethoden een formele specificatietaal gebruikt ter definiëring van de syntax en semantiek, is gebruik gemaakt van een algemeen raamwerk (zie Figuur 1) waarin de ontwikkelmethoden op informele wijze beschreven konden worden. De HyDev methode zou waarschijnlijk een ontwerp van een website kunnen opleveren, maar de daadwerkelijke implementatie van het ontwerp wordt niet besproken in de literatuur. Er is geen beschrijving van de stap van ontwerp naar complete website. De way of working is dus afwezig. De mate van abstractie die wordt aangehouden lijkt willekeurig. Zowel RMM als OOHDM blijken het meest geschikt voor toepassingen met uniform gestructureerde data zoals bijvoorbeeld product catalogi [9]. Complexere hypermedia toepassingen zoals ingenieuze games zullen betere specificatie technieken nodig hebben [9].


24

Zowel Hydev, OOHDM als RMM hebben ondanks de afwezigheid van een formele basis, een specifieke betekenis binnen hun eigen context. Hoewel RMM veel gebruikt wordt voor web ontwikkelingen, wordt RMM gedefinieerd als een proces dat impliciet onderdeel van een ontwikkelmethodologie is en daardoor wordt het proces niet beschreven in de context van een complete life-cycle, nog worden activiteiten anders dan design & implementation beschouwd. Net zo is OOHDM gelijk aan RMM in die zin dat het proces impliciet wordt gedefinieerd door een methodologie [5].

4.2.2. Bottom-Up view De way of supporting Er zijn drie klassen van ondersteunende tools ter ontwikkeling van websites. Dat zijn page editors, website editors en website ontwikkelomgevingen. Zoals reeds eerder aangegeven (zie p. 17) wordt een hypermedia engine gezien als een abstracte machine die een interface aanbiedt om hypermedia structuren te kunnen manipuleren. Een hypermedia systeem dat ontwikkeld is met behulp van een hypermedia engine bestaat over het algemeen uit drie lagen : de storage layer (opslaglaag), de application layer (toepassingslaag) en de presentation layer (presentatielaag) [22]. Het is de storage layer die ondersteund wordt door een DBMS (DataBase Management Systeem), zie Figuur 10 (c). De bestaande systemen die in [4] genoemd worden behoren tot de klasse van website ontwikkelomgevingen : WebComposition WebComposition is gebaseerd op een object georiënteerd webmodel, waarin een website als een hiërarchie van componenten wordt gepresenteerd. Er is nog geen gestructureerde aanpak ontwikkeld voor het maken van een componenten model. Er is dus ook geen specifieke design methode die gekoppeld kan worden aan deze hypermedia engine. Er zijn twee soorten van componenten : primitieven (laagste niveau van de hiërarchie) en composities. Elke component heeft een toestand en gedrag. Hoewel WebComposition gebaseerd is op een object georiënteerd webmodel, maakt het gebruik van een onderliggende relationele database [4]. OOHDM web OOHDM web maakt rapid prototyping van hypermedia toepassingen (ontworpen 8 met behulp van OOHDM) mogelijk. De laatste drie fasen van de OOHDM methode worden hier ondersteund. De realisatie van het systeem komt tot stand door middel van het gebruik van cgi programma’s en een relationele database [4]. RMCase De in paragraaf 4.2.1 besproken hypermedia ontwerpmethode RMM wordt als 8

Navigational Design, Abstract Interface Design en Implementation.


25

basis gezien voor de software ontwikkel tool RMCase. RMCase is een ontwikkelomgeving die gebaseerd is op RMM en is niet incrementeel. Het ondersteunt de bouw van een hypermedia toepassing. De ondersteuning van het cognitieve ontwerpproces wordt verkregen door drie vooronderstellingen die de basis van RMCase vormen [13] : (1) wisselende feedback loops tussen de verschillende fasen van de methode. (2) manipulatie van objecten op instantie niveau. (3) lichtgewicht prototypering. RMCase ondersteunt Top-Down, Bottom-Up en Middle-Out software ontwerp stijlen door de manier waarop RMCase zelf in elkaar zit. Het is namelijk ontworpen als een hypermedia toepassing met navigatie aspecten die feedback loops implementeert. Het is in principe platform onafhankelijk en de mogelijkheid bestaat tot het bouwen van systemen die moeten draaien op het WWW [13]. HyperStorm Bij deze hypermedia engine is sprake van een object georiënteerde aanpak en hergebruik. Het is gebouwd als een extensie van het OODBMS Vodak. Geprobeerd wordt de nadelen uit eerder verschenen hypermedia engines te verwijderen, het gaat om aspecten zoals de uitbreidbaarheid van het model of de ondersteuning van het modelleringsproces. Er blijven enkele nadelen aan deze engine vastzitten, zoals het feit dat voor elke nieuwe website nieuwe speciale relaties gedefinieerd moeten worden [4].

Teneinde meer inzicht te verkrijgen in de werking van een hypermedia ontwerpmethode wordt in de volgende paragraaf een methode uitgewerkt.

4.3. De WSDM methode De way of thinking... De WSDM methode wordt in [7] beschreven en betekent WebSite Design Method. Volgens [7] zijn er twee soorten van websites, namelijk kiosk websites en applicatie websites. 9

Kiosk websites zijn websites die voornamelijk informatie ter beschikking stellen aan gebruikers, waarbij de mogelijkheid tot interactie van de gebuiker niet aanwezig is. 10 Daarentegen zijn applicatie websites interactieve informatiesystemen.

9

Een voorbeeld van een kiosk website : http://www.kub.nl Een voorbeeld van een applicatie website : http://www.efteling.nl/efteling/het_park/sprookje.html

10


26

WSDM is thans bedoeld voor kiosk websites. De essentie van de aanpak van de WSDM is het feit dat het user-centered in plaats van data-driven is. Bij een usercentered aanpak is het startpunt van de methode de verwachte gebruikers van de website. De aspecten die aan de user-centered aanpak zijn gerelateerd lopen als een rode draad door de WSDM. Bij een data-driven aanpak daarentegen, is de data die aanwezig is in de organisatie het startpunt van de modellerings aanpak : eerst wordt het applicatie domein gemodelleerd en daarna wordt informatie geassocieerd met elke klasse van gebruikers (bijvoorbeeld door middel van views of externe schema’s). Echter zou de data en de manier waarop het georganiseerd is in het toepassingsdomein de gebruikersbehoeften (requirements) niet te hoeven weergeven. Dit kan leiden tot een verkeerde combinatie van informatierepresentatie. Let op dat de zojuist beschreven user-centered aanpak verschilt van een user-driven aanpak. Een user-driven aanpak wordt tijdens het ontwerpproces grotendeels begeleid door de gebruikersbehoeften. Die zijn verkregen door middel van vooraf gehouden interviews e.d., bij kiosk websites een onmogelijke taak. De kern van WSDM bestaat uit de volgende vier fasen (weergegeven in Figuur 2) : fase een : User Modeling fase twee : Conceptual Design fase drie : Implementation Design fase vier : Actual Implementation

User Modeling

User Classification

User Class Description

Conceptual Design

Object Modeling

Navigational Design

Implementation Design

Implementation

Website

Figuur 2: Overzicht van de verschillende fasen van WSDM


27

Elke fase uit Figuur 2 levert een (aantal) model(len) op. Voorondersteld wordt dat de doelstelling van de website vóór de start van de eerste fase geformuleerd is. De doelstelling dient het onderwerp en het doel van de website én de te verwachten gebruikers te beschrijven. De methode maakt onderscheid tussen het conceptuele ontwerp (fase een en twee) en het ontwerp van de feitelijke presentatie (fase drie en vier). Het conceptuele ontwerp is, net als in database ontwerp, vrij van implementatie details en gericht op de inhoud en structurering van de website. Het ontwerp van de feitelijke presentatie beschouwt de implementatie taal, het groeperen in pagina’s en de eigenlijke ‘ uitstraling’ van de website (vergelijk met de eerste fasen van HyDev : analyse en ontwerp, paragraaf 4.2.1). De relaties tussen de modellen uit de eerste twee fasen (User Modeling en Conceptual Design) wordt schematisch weergegeven in Figuur 7. Zoals in [12, p. 6-7] verschillende niveaus van abstractie m.b.t. een database systeem worden onderkend, behoren de vier fasen van de WSDM ook tot verschillende niveaus. In [12] wordt gesproken van drie niveaus van abstractie : de fysieke database, de conceptuele database (abstractie van de wereld die betrekking heeft op een organisatie) en de views of subschema’s (abstract model van een deel van de conceptuele database). In die context kan de eerste fase van WSDM, de User Modeling fase beschouwd worden als de fase waarin verschillende external views tot stand komen. Deze external views beschrijven op informele wijze de manier waarop tegen de (aanstaande) website kan worden aangekeken. In een later stadium (paragraaf 4.3.2) worden deze views samengebracht tot een conceptueel model. Dan kan gesproken worden van external view integration. Figuur 3 geeft hier een grafische representatie van.

External view

External view

Conceptueel model

Interne representatie

Figuur 3 : Overzicht van external views


28

Om de bespreking van WSDM te vergemakkelijken is het gebruik van een lopend voorbeeld handig. Beschouw in deze dus de website van een vakgroep aan de universiteit.

Lopend voorbeeld (0) : Website van de vakgroep aan de universiteit.

Typische gebruikers van deze website zijn (toekomstige) studenten, onderzoekers en universiteits medewerkers. Allen hebben verschillende behoeften : De toekomstige student is bijvoorbeeld op zoek naar algemene en curriculum informatie. De ingeschreven student is op zoek naar gedetailleerde informatie zoals bijvoorbeeld vakkenroosters. De onderzoekers en medewerkers van de universiteit zijn op zoek naar onderzoeks projecten, publicaties e.d.

In de hierna volgende paragrafen worden de vier hoofdfasen van de WSDM beschreven.

4.3.1. User Modeling fase De way of modeling De User Modeling fase bestaat uit twee subfasen : User Classification en User Class Description. In de User Classification subfase worden de toekomstige gebruikers van de website door middel van een informele beschrijving geïdentificeerd en geklassificeerd in user classes. De doelstelling van de website zal een indicatie geven van de te verwachten gebruikers, maar dit moet verder gedefinieerd worden. In een user class wordt de informatiebehoefte van de toekomstige gebruikers gedefinieerd. Een user class kan gezien worden als een beschrijving van een subset (echt álle toekomstige gebruikers onderkennen is onmogelijk, vandaar dat hier gesproken wordt van een subset) van alle toekomstige gebruikers. Elke subset bevat toekomstige gebruikers met dezelfde informatiebehoefte. In het volgende voorbeeld wordt het allemaal wat duidelijker.


29

Voorbeeld 1 De activiteiten waaruit elke organisatie bestaat geven een indicatie van de betrokken personen. In ons voorbeeld (voorbeeld 0) zijn onder andere de volgende activiteiten te onderscheiden : onderwijzen, onderzoeken, adviseren van bedrijven, publiceren. Identificatie van de personen die bij elke activiteit horen leidt tot de user classes : Toekomstige Studenten (afgeleid van de activiteit onderwijzen). Ingeschreven Studenten (afgeleid van de activiteit onderwijzen). Onderzoekers (afgeleid van de activiteiten onderzoeken, adviseren van bedrijven, publiceren). Stafleden (afgeleid van de activiteiten onderwijzen, publiceren, onderzoeken, adviseren van bedrijven). Bedrijven (afgeleid van de activiteit adviseren van bedrijven). Figuur 4 geeft weer hoe de omgeving van ons universiteitsvoorbeeld eruit ziet.

Toekomstige studenten

Ingeschreven studenten

Medewerkers Onderwijzen

Bedrijven Publiceren Onderzoeken

Onderzoekers

Bedrijven adviseren

Betekenis der symbolen :

user class

activiteit

afgeleide user class

onderkende activiteit horende bij de organisatie


user class

afgeleid van

activiteit


Figuur 4 : Schema van de omgeving van de universiteit


30

In de User Class Description subfase worden de geïdentificeerde user classes verder geanalyseerd. Een user class bevat een groep van gebruikers (bijvoorbeeld Ingeschreven Studenten) met dezelfde informatiebehoefte (bijvoorbeeld informatie over roosters e.d.). Dezelfde informatiebehoefte kan echter op verschillende manieren (bijvoorbeeld in verschillende talen, om buitenlandse studenten te onderscheiden van inheemse studenten) gepresenteerd worden. Binnen een user class kunnen dus verschillende ‘varianten’ bestaan van dezelfde informatiebehoefte. Om deze varianten te kunnen onderkennen worden de karakteristieken van alle gebruikers van een user class bepaald. De karakteristieken kunnen aangeven hoe bepaalde informatie gepresenteerd moet worden aan de user class. Verschillende karakteristieken in een user class duiden op verschillende bruikbaarheidsbehoeften van gebruikers (usability requirements). Om de zogeheten bruikbaarheidsbehoeften te specificeren wordt een user class verder ontleed in user subclasses : perspectives. Een perspective wordt dus gevormd door een deel van de gebruikers uit een user class met dezelfde karakteristieken en dezelfde usability requirements. Kortom, in een user class wordt de informatiebehoefte van een groep van gebruikers beschreven. Een subclass van een user class, oftewel perspective, beschrijft de karakteristieken en usability requirements van een deel van de groep gebruikers. De verdere analyse van de user classes uit de User modeling subfase legt dus de nadruk op twee verschillende aspecten : De informatiebehoefte van de verschillende user classes (het conceptuele ‘ wat’) De karakteristieken van de user classes (het conceptuele ‘ hoe’). Voorbeelden van karakteristieken zijn : ervaringsniveau’s met websites in het algemeen, taal aspecten, onderwijs/intellectuele vaardigheden, leeftijd, etc.

Voorbeeld 2 Een informele beschrijving van de user class Ingeschreven Studenten uit voorbeeld 1 (pagina 28) zou kunnen zijn : Ingeschreven Studenten : Deze studenten hebben behoefte aan een gedetailleerd informatiepakket waarin zaken zoals roosters, tentamendata, studiebegeleiding en universiteitsregels zijn opgenomen. De leeftijd varieert tussen de 18 en 28 jaar en aangenomen mag worden dat het ervaringsniveau met het WWW goed is. Hier kunnen twee perspectives onderscheiden worden : Inheemse Studenten : Deze studenten zijn op de hoogte van het leef- en werk-klimaat op de universiteit. Ze zijn zich ook bewust van de tradities en regels die gelden (ongeschreven wetten). De voertaal is hun eigen.

Buitenlandse Studenten : Deze studenten zullen in de meest gangbare taal moeten communiceren (Engels) als ze de voertaal niet of nauwelijks beheersen. Verder zullen ze minder op de hoogte zijn van regels en tradities die gelden.


31

In [15] wordt een verfijnde versie van WSDM gepresenteerd namelijk URWSDM(User Requirement-WSDM). In UR-WSDM worden de user classes van de User Modeling fase gedetailleerder geanalyseerd dan in WSDM gebeurd. In WSDM wordt aangenomen dat de perspectives van een user class onderling een set van requirements gemeen hebben. Die worden niet expliciet gedefinieerd in een lijst van behoeften. Dat gebeurd wel in UR-WSDM. Zo ontstaat een lijst van user requirements waarbij elke requirement gezien kan worden als een reden om te browsen op de website.

Voorbeeld 3 Een analyse van de requirements van de user class Ingeschreven Studenten volgens UR-WSDM ziet er als volgt uit : 1. Voor elke docent, geef een lijst van de vakken die hij doceert, geef voor elk vak een korte beschrijving, de voorwaarden, de verplichte literatuur, de syllabus in electronisch formaat en ander materiaal dat door de docent is toegevoegd. 2. Schrijf je in voor een vak Deze lijst van requirements (onvolledig !) is nog steeds vrij informeel, maar in vergelijking met voorbeeld 2 zijn de aspecten met betrekking tot retrieval en manipulatie van data beter zichtbaar.

4.3.2. Conceptual Design fase Het doel van de Conceptual Design fase is om de informatiebehoefte van de user classes en perspectives uit de User Modeling fase formeel te beschrijven. Deze formele beschrijving kan gebruikt worden om later automatisch of semi-automatisch websites te genereren. De Conceptual Design fase bestaat uit twee subfasen : Object Modeling en Navigational Design. In de Conceptual Design fase wordt geconcentreerd op het ‘ conceptuele wat en hoe’ in plaats van het ‘ visuele wat en hoe’. Dat betekent een beschrijving van de soort van informatie die zal worden gepresenteerd en ook hoe genavigeerd zal kunnen worden door die informatie.


4.3.2.1.

32

Object Modeling subfase

De zojuist genoemde formele beschrijving van de informatiebehoefte van de user classes en perspectives vindt plaats in de Object Modeling subfase. Dit gebeurt door conceptuele object modellen, genaamd User Object Models (UOMs), te bouwen voor de user classes. Een UOM (User Object Model) is een model waarin de zakelijke aspecten binnen de organisatie bezien worden vanuit het perspectief van de gebruikers in een user class. Een user class heeft een beperkt perspectief op de organisatie. Dus zal een UOM (User Object Model) slechts een deel van de verzameling van zakelijke aspecten van de organisatie bezien. In tegenstelling tot object georiënteerde object modellen waarin onder andere ook het gedrag van een object type wordt vastgelegd, is bij kiosk websites een beschrijving van het gedrag niet nodig in een UOM (User Object Model). Om een UOM (User Object Model) te bouwen kan een keuze worden gemaakt uit verschillende methoden die geschikt zijn voor conceptuele modellering, bijvoorbeeld de Entity Relation methode ER of de object georiënteerde methode OMT.

Voorbeeld 4 Voor de user class Ingeschreven studenten kunnen de object typen Tentamen, Cursus, Docent en Cursus Materiaal worden vastgesteld (Figuur 5). In de notatie is gebruik gemaakt van object georiënteerde concepten zoals die in [16] terug te vinden zijn. Daar wordt een object gedefinieerd als iets waarmee je bepaalde handelingen mee kan verrichten : het heeft een toestand, een gedrag en een identiteit. Zoals reeds eerder aangegeven is het gedrag bij kiosk websites niet van toepassing.


33 Tentamen

voor 2

Datum Plaats Tijd Duur

met Cursus nodig

voorwaarde voor

Id Naam Beschrijving Nieuwsgroep Tentamen Soort Verplichte Literatuur Programma Jaar

Docent gegeven door 1+

geeft 1+

gebruikt

Naam Titel Plaats Telefoon E-Mail 1+

schrijver van

Cursus Materiaal gebruikt voor

Id Naam Prijs Aanschaf Datum

geschreven door

Figuur 5 : User Object Model voor ‘Ingeschreven Studenten’

Naast de UOMs (User Object Models) voor de verschillende user classes zullen ook POMs (Perspective Object Models) gebouwd moeten worden. Een POM (Perspective Object Model) bestaat uit variaties op een perspective (door de verschillende perspectives die een user class kan hebben) en kan vergeleken worden met een subtype. De POM (Perspective Object Model) voor een gegeven perspective wordt verkregen door in het UOM (User Object Model) de user Object Types te vervangen door de corresponderende perspectives (Figuur 6). Voorwaarden hierbij zijn : Als een user Object Type geen variaties op een perspective heeft wordt er niets gedaan en blijft de user Object Type ongewijzigd. Als een user class geen verschillende perspectives heeft, heeft de User Object Model slechts één Perspective Object Model die gelijk is aan de User Object Model. De Object Types van een Perspective Object Model worden Perspective Object Types (POTs) genoemd. Elke POM (Perspective Object Model) zal beschreven worden als een (mogelijk complexe) view op een Business Object Model (BOM). Een BOM is een conceptuele beschrijving van de aanwezige informatie van business objecten binnen de organisatie. Voor het weergeven van de verschillende perspectives van een Object Type wordt de ouder-kind notatie aangehouden (Figuur 6). Alle tot dusver genoemde modellen uit de conceptual design fase worden in Figuur 7 in relatie tot elkaar weergegeven.


34

Cursus Id Naam Beschrijving Nieuwsgroep Tentamen Soort Verplichte Literatuur Programma Jaar

Cursus/ Inheemse Studenten

Cursus/ Buitenlands Studenten

Id Naam/ Naam Ned. Beschrijving/ Beschrijving Ned. Nieuwsgroep Tentamen Soort/ Tentamen Soort Ned. Verplichte Literatuur/ Verpl. Lit. Ned. Programma Jaar

Id Naam/ Naam Engels Beschrijving/ Beschrijving Engels Nieuwsgroep Tentamen Soort/ Tentamen Soort Engels Verplichte Literatuur/ Verpl. Lit. Engels

Figuur 6 : Perspectives variaties voor het Object Type Cursus

Toekomstige studenten

Ingeschreven studenten

Medewerkers Onderwijzen

Bedrijven Publiceren Onderzoeken

Onderzoekers

Bedrijven adviseren

Betekenis der symbolen :

user class

activiteit




user class

afgeleid van

activiteit


Figuur 7 : De verschillende object modellen in relatie tot elkaar


4.3.2.2.

35

Navigational Design subfase

In de Navigational Design subfase wordt een Conceptual Navigation Model gemaakt. Dit conceptuele navigatie model bestaat uit een aantal navigatie paden (navigation tracks). Voor elke Perspective Object Model (POM) wordt namelijk een apart navigatie pad gemaakt. Een navigatie pad geeft aan hoe gebruikers van een perspective door de aanwezige informatie kunnen navigeren. Elk navigatie pad bestaat uit drie lagen (zie onderstaand algoritme voor verdere uitleg): 1. De bovenste laag is de context layer, hier worden de verschillende navigatie paden aan elkaar verbonden. 2. De middelste laag heet de navigation layer, deze laag bevat verschillende toegangs mogelijkheden tot de informatie. 3. De onderste laag is de information layer, deze bevat de feitelijke informatie, opgeslagen in informatie componenten. Het beschrijven van een navigatie pad wordt gedaan in termen van componenten en links. Deze concepten (zie Figuur 8) kunnen zijn : Informatie component : correspondeert met een Perspective Object Type (POT). Elke POT kan gerelateerd zijn aan andere Perspective Object Types. Dit kan worden aangegeven d.m.v. links naar andere componenten. Navigatie component : groepering van links. Externe component : referentie naar een component van een andere website.

Navigational component

Information component

External component

Figuur 8 : Representatie van de navigatie concepten

Voorbeeld 5 In

Figuur 9 wordt een voorbeeld gepresenteerd van een navigatie track voor de perspective Buitenlandse Studenten.

Link


Context Layer

36

Perspective van Buitenlandse Studenten

Navigation Layer Tentamens per Vak

Vakken bij Naam

Vak Materiaal

Vak Materiaal per Id

Tentamen/ Buitenlandse student

Vak/Buitenlandse student

Docenten bij Naam

Vak Materiaal per Vak

Vak Materiaal Buitenlandse student

Docent/ Buitenlandse student

Information Layer

Figuur 9 : Navigatie track (pad) voor de perspective van Buitenlandse Studenten

Het construeren van een navigatie pad (navigatie track) uit een Perspective Object Model gebeurd aan de hand van een algoritme. Het volgende informele algoritme kan hiervoor gebruikt worden.

Algoritme voor het construeren van een navigatie pad : 1. Bouw de context layer : Maak een navigatie component met dezelfde naam als de perspective. 2. Bouw de information layer : Elke Perspective Object Type wordt óf een informatie component óf een externe component. De keuze is uiteraard afhankelijk van de aanwezige informatie. 3. Bouw de navigation layer : Voor elke Perspective Object Type wordt een navigatie component geconstrueerd met dezelfde naam als de Perspective Object Type. Deze navigatie component wordt gelinked aan de context layer. Als dezelfde informatie component op verschillende manieren toegankelijk moet zijn, worden intermediaire navigatie componenten en links gecreëerd. Op deze manier zijn de drie lagen in


37

Figuur 9 ontstaan.

4.3.3. Implementation Design fase In de Implementation Design fase wordt de ‘ uitstraling’ van de website ontworpen. Het doel is een consistent, aangename en efficiënte uitstraling van het conceptuele ontwerp uit de vorige fase (Conceptual Design) te maken. Deze fase levert een Implementation Model op. Op het WWW zijn er vele methoden te vinden die betrekking hebben op website design. Enkele algemene richtlijnen zijn : De hoeveelheid aan informatie op één pagina moet de gebruiker niet bedelven, maar in redelijk grote hoeveelheden worden gepresenteerd (denk aan Miller’s Law on the Magic Number, paragraaf 2.4). Ook de download tijd moet minimaal blijven, bij hele grote stukken informatie heeft zelfs een snelle server veel tijd nodig. Bij gebruik van de WSDM kan de bouwer van een website zelf besluiten om componenten die door links zijn verbonden te groeperen (clustering) en op één pagina te representeren. Daarbij kunnen navigatie componenten geïmplementeerd worden d.m.v. (on)geordende lijsten. Maak gebruik van een index pagina. Dit zou een simpele versie van het conceptuele model kunnen zijn. Een index pagina kan de gebruiker behulpzaam zijn bij het localiseren van informatie , maar ook om een mentaal plaatje van de website te maken. Zo kan het lost-in-hyperspace syndroom geminimaliseerd worden. Gebruik inhoudelijke en informatieve leidraden en vermijd pagina’s zonder leidraad. Op deze manier heeft de gebruiker meteen door of de pagina voor hem of haar relevant is. Gebruik navigatie leidraden. Een website die gecreëerd is m.b.v. de WSDM concentreert op het perspectief van de gebruiker. De pagina’s van een website kunnen externe links en ook inter-perspectieve links (links tussen pagina’s van verschillende navigatie paden) bevatten. Gebruik van verschillende navigatie leidraden maakt het de gebruiker makkelijk dit onderscheid op te merken. Het implementation model wordt gecreëerd door als startpunt het navigatie model onder handen te nemen. Door gebruikmaking van grafische ontwerp principes en visuele communicatie technieken kunnen de karakteristieken van de verschillende perspectieven beschouwd worden. Zo kan het navigatie model vertaald worden in een presentatie model. Dit presentatie model beschrijft dan de inhoud van de pagina’s en de lay out.


38

4.3.4. Implementation fase De way of supporting De laatste fase, Implementation, is de feitelijke realisatie van de website met gebruikmaking van de gekozen implementatie omgeving, bv HTML. Hierbij zal het implementation model geconverteerd moeten worden naar een verzameling van files die HTML source code bevatten. Verbeterd onderhoud aan een website verrichten is mogelijk door de onderliggende informatie of gedeelten daarvan in een database op te slaan. Pagina’s kunnen dan gegenereerd worden door de informatie uit de database te halen. De basis van het database design zit in de Business Object Model (zie paragraaf 4.3.2.1). De BOM kan gezien worden als het conceptuele schema van de database omdat het de business objects beschrijft op een conceptueel niveau. Van het conceptueel schema kan een logisch database schema gegenereerd worden (met gebruikmaking van de juiste database development tools) of het kan ook handmatig gebouwd worden. Uit de Perspective Object Models kunnen de queries voor de database worden afgeleid omdat Perspective Object Models worden weergegeven als views op de Business Object Model. Een grondige uitleg over het linken van een relationele database aan een website is te vinden in [18].

4.4. Evaluatie beschreven methode De in paragraaf 4.2 genoemde methoden hebben enkele algemene concepten met elkaar gemeen die een belangrijke rol spelen in de huidige ontwikkelmethoden voor hypermedia. De WSDM methode heeft in tegenstelling tot eerder genoemde methoden een totaal ander uitgangspunt, namelijk een user-centered aanpak. WSDM begint met het identificeren van de verschillende typen toekomstige gebruikers. Daarna worden hun karakteristieken en informatiebehoefte beschreven. Pas hierna begint het conceptuele ontwerp van de website met als input de reeds gedefinieerde perspectives en de zakelijke doelstelling van de organisatie achter de website (de informatie-aanbieder). De WSDM methode beperkt zich tot kioskwebsites. De eerste twee fasen (User Modeling en Conceptual Design) van WSDM lijken de belangrijkste te zijn, zij leggen immers de basis voor verdere implementatie. In de literatuur worden de eerste twee fasen vrij uitgebreid met voorbeelden gestaafd. Doordat echter ook deze methode geen formele semantiek heeft, blijft het begrip over elke te ondernemen fase beperkt tot de gegeven voorbeelden. Op die manier is het uiterst moeilijk de methode toe te passen op een organisatie anders dan een universitaire omgeving. Dit onderstreept nog eens het belang van de aanwezigheid van een formele beschrijving van een methode.


39

De implematation fase uit WSDM wordt summier beschreven en volgt geen speciale werkwijze. Hoewel er wel aandacht wordt besteed aan de presentatie van de website (Implementation Design fase, paragraaf 4.3.3), is er geen specifiek platform waarop het ontwerp ontwikkeld kan worden. Dit kan gezien worden als een groot minpunt, de implementatie van het ontwerp wordt overgelaten aan het gebruik van website editors en page editors. Desondanks stelt de methode een logische manier van werken ten toon die ook bij de andere methoden (paragraaf 4.2) te zien is. Binnen de hypermedia ontwikkelingen is er misschien nog geen sprake van een ondubbelzinnige beschrijving en formele semantiek, het belang van de algemene richtlijnen ter ontwikkeling van hypermedia ligt er al (zie Tabel 1).


40

5. Toepassing hypermedia design In het vorige hoofdstuk is uitvoerig ingegaan op wat een hypermedia design methode is. Hoewel de ontwikkeling van hypermedia toepassingen nog steeds ad hoc verloopt, heeft hypermedia design de potentie om de efficiëntie van het onderhoud en beheer aan websites te verbeteren. In dit hoofdstuk zal besproken worden waarom een migratie overwogen kan worden. De voordelen van zo een beslissing worden daarna geschetst, waarna het migratieproces zal worden besproken. Op deze manier zal getracht worden antwoord te geven op subvragen 4 (a) en 5 van de probleemstelling (zie p. 2).

5.1. De keuze maken In hoofdstuk 4 zijn enkele hypermedia design methoden en hypermedia engines besproken. Hierbij is ingegaan op zowel de sterke als zwakke punten van genoemde methoden. Het zou absurd zijn te beweren dat er slechts één enkele methode bestaat die ‘ juist’ is, daarom zal in de navolgende theoretische bespreking uitgegaan worden van het concept hypermedia design methode. De uitgebreide beschrijving van WSDM in paragraaf 4.3 biedt de mogelijkheid die methode als leidraad te gebruiken. Met betrekking tot de website van Ouders Online is het niet onvoorstelbaar dat een herstructurering van de website nodig zal zijn om te komen tot efficiënter onderhoud en beheer. In [19] worden enkele factoren overwogen bij de beslissing om conventionele software te herstructureren. Dergelijke criteria zijn nog niet specifiek voor hypermedia systemen geformuleerd. Om desondanks een idee te krijgen van wat de bedoeling is, kunnen de criteria in [19] toegepast worden op websites. Dan geldt : 1. Als een significant gedeelte van de website stabiel is en niet onderhevig aan veranderingen is een herstructurering aan te bevelen. Het is dan alleen nodig dat deel dat veranderd moet worden te herstructureren. 2. Is de website geïmplementeerd met behulp van verouderde software (bijvoorbeeld in een verouderde taal), dan is herschrijven aan te bevelen. Dit om tijdig in te kunnen spelen op nieuwe technologiën. 3. Is de onderliggende structuur van de website niet gedocumenteerd, dan is herstructurering (op conceptueel niveau) aan te bevelen. Dit zal verbeterde mogelijkheden scheppen in verband met technologische ontwikkelingen en toekomstig adaptief onderhoud. 4. Als er geen tools bestaan die het herstructureringsproces kunnen ondersteunen, is handmatige herstructurering de enige oplossing. Handmatige herstructurering is uiteraard geen reële optie. Punt 4 kan daarom beter omgezet worden in het construeren van een tool die het herstructureringsproces kan ondersteunen.

41

HOOFDSTUK 5. TOEPASSING HYPERMEDIA DESIGN

42

Herstructurering van een website houdt een migratie in van de oude toestand naar een nieuwe. De migratie naar een DBMS-ondersteunde omgeving betekent een financiële investering die in eerste instantie niet goedkoper zal zijn dan de handmatige voortzetting van het onderhoud. Het gestructureerd voortzetten van het onderhoud en beheer is echter een punt dat aan bovengenoemde criteria kan worden toegevoegd. Door een gestructureerde opslag van gegevens (bijvoorbeeld in een databasestructuur) kunnen namelijk een groot deel van de genoemde problemen in paragraaf 2.6 worden geëlimineerd.

5.2. De voordelen Hoewel het proces van de ontwikkeling van hypermedia toepassingen thans nog niet formeel gedefinieerd is, zijn er reeds voordelen te onderkennen. In [5] worden enkele voordelen genoemd van hypermedia die, toegepast op website ontwikkeling, zouden kunnen gelden : Verbeterde kwaliteit en betrouwbaarheid van de toepassing. Zichtbaar verbeterd ontwerp van de website voor zowel het management van de organisatie als de gebruikers. Meer zelfvertrouwen en tevredenheid bij de gebruikers. Verminderde kosten aan de ontwikkeling en het onderhoud. Verbeterde controle van het management. Beter begrijpbare en makkelijker te onderhouden toepassingen. Deze voordelen zouden gelden wanneer een website gebouwd is middels het toepassen van een hypermedia design methode. De gestructureerde aanpak vormt een goede basis voor ondersteuning van een implementatie van het geheel door een website ontwikkelomgeving.

5.3. De architectuur Sinds de opkomst van hypermedia zijn er verschillende architecturen aangehouden voor hypermedia systemen. De eerste pogingen leidden tot een systeem dat op maat gebouwd werd (Figuur 10 (a)). Daarna kwam de twee-niveau architectuur (Figuur 10 (b) [23]). Thans wordt de basis van de meeste systemen gevormd door een drie-niveau architectuur (Figuur 10 (c) [24]).

43


Custom

Custom

Custom

Hyperbase

(a)

Database

Database

(b)

(c)

Figuur 10 : Architectuur van drie hypermedia systemen

Beschrijving van figuur 10: In (a) wordt een hypermedia systeem gepresenteerd dat op maat gebouwd is. De hypermedia systemen van deze architectuur waren gebaseerd op mainframes. De knopen in zo een systeem waren hoofdzakelijk tekstueel. De presentatie had geen tot weinig grafische aspecten [25]. In (b) wordt een tweede generatie hypermedia systemen gepresenteerd. Het concept is hetzelfde gebleven als in (a). Echter hebben de mainframes plaats gemaakt voor workstations. Hierdoor konden de user interfaces verbeterd worden. Grafische aspecten en knopen met animatie werden mogelijk. Navigatie werd makkelijker gemaakt door de grafische presentatie van de netwerk structuur. Helaas waren deze systemen alleen geschikt voor kleine groepen individuen [25]. Het custom gedeelte wordt ook wel hyperindex genoemd. De hyperindex bevat de representatie van de karakterisatie van de documenten. De database bevat de verzameling van documenten. In (c) is er sprake van drie lagen : de presentatielaag (Custom), de toepassingslaag (Hyperbase) en de opslaglaag (Database). De presentatielaag wordt custom made gemaakt en de interfaces zijn geavanceerder. De toepassingslaag bevat de hyperbase en die bevat de links. In de database is informatie opgeslagen a.d.h.v. een conceptuele beschrijving. Het onderhoud aan een website heeft niet alleen een geautomatiseerd aspect, maar ook een handmatig aspect. In een vereenvoudigde situatie zou gesproken kunnen worden van een handmatig deel en een geautomatiseerd deel van het onderhoud. Het handmatige deel is van toepassing op het reeds genoemde perfectief onderhoud en tevens het aansturen van het geautomatiseerde deel. Het geautomatiseerde deel van het onderhoud is dat deel waar een DataBase Management Systeem (DBMS) wordt gebruikt (in de opslaglaag van Figuur 10 (c)). Er zijn verschillende manieren om een DataBase Management Systeem te definiëren. In [26] wordt een DBMS beschouwd als een geautomatiseerde tool


44

die gebruikers van het DBMS in staat stelt handelingen uit te voeren op een efficiënte en effectieve manier. De handelingen kunnen bijvoorbeeld bestaan uit het raadplegen van de data in de database of het onderhouden van de data. Het DBMS werkt dus als een soort van interface tussen de gebruiker en de database. De manier waarop de gebruiker communiceert met het DBMS is via een query taal. Een DataBase Management Systeem kent grofweg gezien drie soorten gebruikers [26] : Programmeurs, schrijven toepassingen die gebruik maken van de database. Eindgebuikers, maken gebruik van de toepassing en kunnen communiceren met de database via een query taal. De DataBase Administrator (DBA), diegene die verantwoordelijk is voor onder andere de performance van het systeem. De DBA bepaalt zaken zoals de opslagstructuur, indexering en bijvoorbeeld ook het tunen van de database. Volgens [22] is de implementatie van een OODBMS (Object Oriented DBMS) thans de beste keus voor de opslaglaag van een hypermedia systeem. Een andere mogelijkheid die onderzocht zou kunnen worden is een DBMS dat zichzelf kan sturen en onderhouden. In hoofdstuk 6 zal hier verder op worden ingegaan.

5.4. De migratie De voorgaande paragrafen hebben als het ware de argumenten bepleit om te kiezen voor een DBMS-ondersteunde website. In deze paragraaf zal het daadwerkelijke proces beschreven worden van een migratie naar een website die door een DBMS wordt ondersteund vanuit een niet-DBMS ondersteunde situatie.

Met betrekking tot een website zijn er twee soorten van migratie te onderkennen : de structurele migratie en de concrete migratie. Een structurele migratie is een migratie van ‘ de structuurbeschrijving in de huidige situatie’ naar ‘ de structuurbeschrijving in de nieuwe situatie’. Zoals in Figuur 3 (p. 27) te zien was, zijn er verschillende external views op een website mogelijk. Bij een structurele migratie is het de bedoeling dat de external views op de website niet veranderen in de nieuwe situatie. Dat wil zeggen dat de gebruiker niet uit de presentatie van de website zal kunnen opmaken dat de website DBMSondersteuning ondervindt.

45


Geen DBMS ondersteuning (huidige situatie)

migratie (*)

DBMS ondersteuning (nieuwe situatie)

structurele migratie, zelfde external view structuurbeschrijving (*)

structuurbeschrijving concrete migratie, nieuwe beschrijving

populatie v/d structuur

populatie v/d structuur

Figuur 11 : De verschillende vormen van migratie

Een concrete migratie is een migratie van ‘ de populatie van de structuur in de huidige situatie’ naar ‘ de populatie van de structuur in de nieuwe situatie’. De populatie van de structuur van de website is een invulling of beschrijving van de structuur. Deze beschrijving kan in de nieuwe situatie wel veranderen. Een migratie van data in het HTML (HyperText Markup Language) formaat naar data in het XML 11 (eXtensible Markup Language ) formaat is hiervan een voorbeeld.

5.4.1. Het migratieproces De structurele migratie is een proces dat veel eenvoudiger uit te voeren is dan de concrete migratie. Dat komt omdat dit op het conceptuele niveau plaatsvindt. Om die reden zal daar uitgebreider op worden ingegaan dan op de concrete migratie. De structurele migratie is het best te beschrijven aan de hand van ons praktijkvoorbeeld, namelijk de website van Ouders Online. Enkele fasen uit WSDM (Figuur 2, p. 26) kunnen daarbij ondersteuning bieden. De doelstelling van de website van Ouders Online is heel erg gebruikersgericht waardoor de user-centered aanpak van WSDM daar goed op aansluit. Verder is de website van Ouders Online te vergelijken met een kiosk website : immers, de lezersinput uit de interactieve delen wordt naderhand toch nog handmatig door de redactie gescreend.

11

Meer informatie over XML is bijvoorbeeld te vinden op http://www.xmlconference.com.


46

Het structurele migratieproces kan als volgt beschreven worden : De User Modeling fase (paragraaf 4.3.1) De doelstelling van de website is bekend (paragraaf 2.3). Er kan dus gelijk gestart worden met : De User Classification fase

De website van Ouders Online heeft in 1997 een lezers-enquête gehouden waaruit een gebruikersprofiel af te leiden valt. Hierdoor is het mogelijk user classes te definiëren en er een informele beschrijving van te formuleren.

Voorbeeld van een mogelijke user class De website van Ouders Online is bedoeld voor ouders van kinderen tussen de 0 en 12 jaar. Dit schept de mogelijkheid tot een heel scala van user classes. Een daarvan is bijvoorbeeld Ouders van pasgeborenen.

User Class Description

In deze subfase kunnen de user classes uit de vorige subfase in detail worden beschreven.

Voorbeeldbeschrijving van de user class Ouders van pasgeborenen Ouders van pasgeborenen : Deze groep mensen heeft behoefte aan informatie die onder andere bestaat uit : Tips met betrekking tot de kraamverzorgingsperiode.

Wat te doen bij ziekteverschijnselen.

Het verwachte gedrag van het kind op een bepaalde leeftijd.

De Conceptual Design fase (paragraaf 4.3.2)

Object Modeling (paragraaf 4.3.2.1)

In deze subfase worden onder andere conceptuele object modellen genaamd User Object Models (UOMs) voor de user classes uit de vorige fase gemaakt. Verder kunnen ook nog perspectives worden gemaakt op de UOMs.

47


Voorbeeld UOM van de user class Ouders van pasgeborenen Voor deze user class zouden de object typen kraamverzorgingsperiode, ziekteverschijnselen en gedrag kunnen worden vastgesteld (Figuur 12).

Kraam periode vertoont Verzorging Rust Voeding

uit Gedrag Ziekteverschijnselen Uitslag Kleurverandering Verstopping

komen voort uit

uit zich in

Huilen Stuiptrekken Staren

Figuur 12 : Een mogelijke UOM voor de user class ‘Ouders van pasgeborenen’

Navigational Design (paragraaf 4.3.2.2) In deze subfase worden navigatiepaden gemaakt. De website van Ouders Online vertoont reeds een onderliggende navigatiestructuur. Het construeren van de navigatiepaden komt dus neer op het weergeven van deze structuur in het drie-lagen model zoals dat in

Figuur 9 (p. 36) geschetst is.

Implementation Design fase (paragraaf 4.3.3)

Deze fase is alleen relevant wanneer gewerkt wordt vanuit een beginsituatie zonder concrete website. In het geval van Ouders Online staat er al een website. Dus is het alleen nodig de huidige presentatie van de website te beschrijven in een presentatie model. Afhankelijk van de keuze die in de volgende fase wordt gemaakt, is te zeggen of deze fase overbodig is.


48

Implementation fase (paragraaf 4.3.4) De implementation fase uit WSDM wordt in de literatuur vrij summier beschreven. Om die reden is het niet mogelijk aan te geven of deze fase ook daadwerkelijk uitgevoerd kan worden. Een andere mogelijkheid is echter het gebruik van een website ontwikkelomgeving. Die zal het conceptuele model dat tot op heden gegenereerd is als input kunnen gebruiken. Zo kan een DBMS-ondersteunde website geïmplementeerd worden. Reeds aan het begin van het structurele migratieproces zal rekening gehouden moeten worden met de keuze van de te gebruiken website ontwikkelomgeving. Dit om een relationele of object georiënteerde realisatie te kunnen bewerkstelligen. Evenals bij conventionele software informatiesystemen is documentatie gewenst in verband met technisch onderhoud.

Het concrete migratieproces bestaat uit een invulling van de nieuwe structuur van de website. Een manier om dit aan te pakken is het gebruik van een tool. De tool zal de volgende functionaliteit moeten hebben : De populatie van de huidige structuur inlezen. De ingelezen populatie omzetten naar de populatie van de nieuwe structuur (een converter). De uitvoering hiervan is vrij complex, temeer omdat de converter waarschijnlijk zelf geschreven zal moeten worden. Uiteindelijk zal het echter wel tijd schelen als het alternatief een handmatige omzetting is.

5.4.2. Te verwachten problemen In [5] zijn de resultaten verwerkt van meer dan vijftig migratieprojecten die zijn uitgevoerd met betrekking tot hypermedia ontwikkelprojecten. Het ging daarbij om de migratie van grote hoeveelheden data in HTML formaat die omgezet moesten worden naar SGML formaat. Het onderzoek dat in [5] wordt beschreven is geen afgerond geheel, maar er zijn reeds resultaten te onderkennen over bovengenoemd migratieproces. Bij de ontwikkeling van hypermedia toepassingen zal in het kort gelet moeten worden op : Prototyping.

Prototyping in het beginstadium van de ontwikkeling kan leiden tot een specificatie van requirements die later tijdens de implementatie niet te realiseren zijn.

Binding met werk.

Programmeurs kunnen een verkeerde affiniteit met hun werk opbouwen waardoor ze minder open staan voor veranderingen. Aanpassingen in hun werk vallen zwaar en dit kan leiden tot opstand.


49

Meerdere programmeurs. Door de complexiteit van het werk is het soms niet mogelijk meer dan een programmeur op een taak te zetten. Verkeerd onderhoud. Door gebrek aan begrip van de nieuwe functionaliteit van de toepassing is het onderhoud juist moeilijker geworden. Deze lijst van problemen is uiteraard verre van compleet. De genoemde aspecten hebben alleen betrekking op het proces van de migratie of de ontwikkeling van een hypermedia toepassing. Een reëel probleem van een ander formaat is de financiering van de uitvoering van het ontwikkelproces. Door de thans nog ad hoc ontwikkeling van hypermedia toepassingen is er tevens nog geen staandaard honorarium overeengekomen. Verschillende softwareontwikkelaars kunnen in de praktijk aardig verschillen in grootte met betrekking tot de offertes voor hypermedia ontwikkeling. Verder zal er voor de website met een DBMS-ondersteuning een tijdperk aanbreken met nieuwe rollen. Zo zal er een DataBase Administrator aangesteld moeten worden om onder andere de performance van het systeem te controleren.


50

6. Rol Active Databases In het vorige hoofdstuk is de rol van een hypermedia design methode in het onderhoud en beheer van een website besproken. In dit hoofdstuk zal worden ingegaan op de zelfcontrole m.b.t. het onderhoud en beheer, van een hypermedia systeem met database-ondersteuning. Volgens [27] zijn database ontwikkelaars het erover eens dat ‘ gewone’ databases vervangen moeten worden door active databases. Met active databases kan namelijk een uniform mechanisme worden toegepast om database-taken ten uitvoer te brengen. Thans zal worden ingegaan op 12 de rol die een active database kan spelen in een DataBase Management Systeem (DBMS) van een hypermedia systeem (opslaglaag van Figuur 10 (c)). Uiteraard zal eerst worden uitgelegd wat een active database is.

6.1. Een Active Database Management Systeem Een Active DataBase Management Systeem (Active DBMS) is een DBMS dat een koppeling maakt tussen database technologie en regel-gebaseerd programmeren. Een active database bestaat uit een (passieve) database en een set van actieve regels. Zoals de naam enigszins al aangeeft heeft regel-gebaseerd programmeren te maken met regels. De meest gebruikte regel is de Event-Condition-Action (ECA) regel. Die werkt als volgt : Als één of meerdere relevante Events van de regel plaatsvinden én een bepaalde Condition geldt dan voer de relevante Action van de regel uit. Een Event is een gebeurtenis die plaatsvindt als reactie op een database stimulans. Een Condition is een voorwaarde en dat is een logische staat waarin het systeem zich bevindt op het moment dat de event plaatsvindt. Een Action is een te ondernemen handeling of actie die zal worden uitgevoerd wanneer de event plaatsvindt en de condition geldt. In de ECA regel wordt dus gespecificeerd welke actie ondernomen moet worden wanneer één of meerdere gebeurtenissen plaatsvinden, voorondersteld dat een bepaalde voorwaarde geldt. Daarbij moet een regel eerst getriggerd worden, dat wil zeggen, op gang gebracht worden. Een regel wordt getriggerd door het plaatsvinden van de relevante gebeurtenis(sen). Als de regel eenmaal getriggerd is, wordt de regel overwogen om te zien of de voorwaarde geldt. Als de voorwaarde geldt, wordt de regel uitgevoerd door de actie uit te voeren. Het gevolg van de koppeling van een passieve database met actieve regels is dat er een reactievermogen van de database teweeg wordt gebracht. De database kan dan reageren op (mogelijk externe) stimulansen. Dit reactievermogen kan toegepast worden voor verschillende doeleinden. Voorbeelden daarvan zijn beveiliging en het checken en toepassen van integriteitsaspecten. 12

Zie subvraag 4 (b) van de probleemstelling, p. 2.

51

HOOFDSTUK 6. ROL ACTIVE DATABASES

52

In [11, p. 421] worden enkele bestaande active database systemen besproken. De bestaande systemen en prototypen hebben een aantal gelijke aspecten, maar ook verschillende syntactische en semantische varianten. Deze verschillen leiden ertoe dat de volle potentie van active databases moeilijk kan worden geëxploiteerd. Om dat wel te kunnen doen is volgens [11] een stabiele klassificatie van semantische dimensies en een goed begrip van hun mogelijke waarden nodig. De dimensies karakteriseren daarbij het gedrag van een active database. Naast de verschillende dimensies hebben de gebruikte regels ook een bepaalde syntax. Een formele basis voor de beschrijving van het gedrag van active databases wordt in [11] gepresenteerd door de introductie van een core taal. Deze core taal houdt sterk verband met de twee datastructuren waaruit een active database bestaat. In de volgende paragrafen zal hier verder op worden ingegaan.

6.1.1. Dimensies active database De semantische dimensies die in [11] genoemd worden om het gedrag van een active database te karakteriseren zijn : 1. De granularity of korreligheid van updates en van regels. 2. De verschillende koppel-modes of -toestanden van het verband binnen de regel : eerst het verband of de koppeling tussen Event en Condition, en dan tussen Condition en Action. 3. De atomaire uitvoering van de regel-actie. 4. De relatie van regel-uitvoering tot transactie-uitvoering. 5. Het conflict resolutie mechanisme. 6. De tijd en het bereik van event consumption. 7. De inspectie van de transactie geschiedenis. 8. Samengestelde events en de manipulatie van het event net effect.

In de volgende paragrafen wordt uitgelegd hoe bovengenoemde dimensies geïnterpreteerd kunnen worden.

6.1.1.1.

Granularity of korreligheid van updates en regels

Er zijn verschillende handelingen die op een database kunnen worden uitgevoerd, bijvoorbeeld het updaten van gegevens. Om een update op een database uit te voeren zijn er twee manieren :


53

Instantie- of tupel-georiënteerd, d.w.z. dat het doel van de update een enkele database entiteit is. Set-georiënteerd, d.w.z. dat het doel van de update een set (verzameling) van database entiteiten is. Deze onderverdeling kan doorgevoerd worden naar regels, waardoor ook gesproken kan worden van :

Instantie- of tupel-georiënteerde regels : regels die reageren op een update van een relevante item, onafhankelijk van andere updates .

Set-georiënteerde regels : regels die één keer reageren (getriggerd worden door) op de collectieve update van meerdere items.

Voorbeeld Stel dat de gegevens van een nieuwe werknemer aan de lijst van werknemers van een organisatie wordt toegevoegd. Na deze toevoeging moet de database dus geupdate worden. Bij een instantie- of tupel-georiënteerde update zal na de toevoeging van N werknemers N updates moeten plaatsvinden. Bij een setgeoriënteerde update zou slechts één update hoeven plaats te vinden na de toevoeging van de gegevens van alle N werknemers.

Voorbeeld update van SQL3 regel waarin triggers door een tupelgeoriënteerde update worden geactiveerd.

CREATE TRIGGER Compute_Emp_Number AFTER INSERT ON Employee FOR EACH ROW WHEN TRUE update Company_statistics set new_emp_number = 1 + new_emp_number


54

De set-georiënteerde versie van de SQL3 regel ziet er als volgt uit. CREATE TRIGGER Compute_Emp_Number AFTER INSERT ON Employee FOR EACH STATEMENT WHEN TRUE update Company_statistics set new_emp_number = new_emp_number + (select count(*) from Employee – (select count(*) from Old_Emp)

Het is niet vanzelfsprekend dat uit een set-georiënteerde taal, set-georiënteerde regels volgen.

6.1.1.2.

Verschillende koppel-modes

De verschillende koppel-modes of -toestanden binnen een regel dienen ter beschrijving van : Regel-koppel-mode : de synchronisatie tussen de activering van de regel, de evaluatie van de conditie en de uitvoering van de actie. Dit duidt op een onderverdeling in Event-Condition koppel-mode en Condition-Action koppelmode. Transactie-semantiek-mode : de triggering van een event kan plaatsvinden doordat gebeurtenissen gelijktijdig voorvallen. Dit gelijktijdige aspect staat in relatie tot conditie-evaluatie en actie-uitvoering. Deze relatie wordt ook door een mode beschreven (wordt in paragraaf 6.1.1.4 besproken). Een database-transactie van een gebruiker kan een trigger teweeg brengen die één event of meerdere events doet voorvallen. Als een event eenmaal is voorgevallen vindt de evaluatie van de conditie plaats. Deze Event-Condition koppeling kan op twee manieren plaatsvinden :

Gelijke koppeling : de evaluatie van de conditie vindt gelijk na de triggering van de event plaats.

Verlate koppeling : de evaluatie van de conditie vindt pas op een later tijdstip plaats, bijvoorbeeld totdat een ‘ andere event ’ heeft plaatsgevonden.

Nadat de Event-Condition koppeling heeft plaatsgevonden, komt de regel bij de Condition-Action koppeling. Deze koppeling is gebaseerd op tijd : de tijd die voorbij gaat tussen de evaluatie van de conditie en het moment waarop de actie wordt uitgevoerd. Net als bij de Event-Condition koppeling wordt ook hier een onderscheid gemaakt tussen gelijke koppeling en verlate koppeling.


6.1.1.3.

55

Atomaire uitvoering van de regel-actie

De triggering van een event kan leiden tot de uitvoering van de actie van een regel (als aan de conditie wordt voldaan). De uitvoering van de actie van een regel (1) op zich kan een trigger zijn voor een event van een andere regel (2). In deze situatie moet een keus gemaakt worden uit de volgende scenario’s : Automatische uitvoering van de regel-actie : uitvoering van de eerste regel (1) terwijl de triggering event voor regel (2) wordt ‘ bevroren’ totdat de actie van regel (1) is uitgevoerd. Onderbreken van de regel-actie uitvoering : de uitvoering van de regel die de triggering event heeft veroorzaakt wordt tijdelijk gestaakt om andere, mogelijk getriggerde regels uit te voeren (vergelijkbaar met recursieve procedures). De atomaire uitvoering van de regel-actie kan voorbijgaan aan de Event-Condition koppeling.

6.1.1.4.

Relatie van regel-uitvoering tot transactie-uitvoering

De transactie-semantiek-mode is reeds in paragraaf 6.1.1.2 genoemd. Een transactie wordt gezien als een opeenvolging van manipulaties op data en query operaties. De relatie van de regel-uitvoering tot de transactie-uitvoering is een relatie tussen twee soorten van transacties, te weten : 1. Een transactie waarin de triggering event van een regel plaatsvindt. 2. Een (mogelijk verschillende) transactie(s) waarin conditie-evaluatie en actieuitvoering plaatsvindt. Deze relatie wordt, afhankelijk van de situaties die zich voordoen beschreven. Die situaties kunnen zijn : Zelfde transactie : de conditie-evaluatie en actie-uitvoering vindt plaats in de transactie van de triggering event (oftewel transactie 2 vindt plaats in transactie 1). Het gevolg hiervan is dat wanneer transactie 1 plaatsvindt en er komt een opdracht binnen om de regel af te breken, ook de transactie dus afgebroken wordt. Verschillende transacties : de conditie-evaluatie en actie-uitvoering vinden niet plaats in de transactie van de triggering event. Ze vinden plaats in een aparte transactie, er kan zelfs sprake zijn van twee verschillende transacties. Dit betekent min of meer dat de volgorde van de uitvoering van de regel geregeld wordt door het concurrency control systeem en dat de regel-uitvoerings-engine hier niets mee te maken heeft.


6.1.1.5.

56

Conflict resolutie mechanisme

In een systeem kan er sprake zijn van meerdere regels die tegelijkertijd getriggerd worden. Dat kan komen doordat Eén event meerdere regels getriggerd heeft. Regels niet metéén na hun triggering event beschouwd worden. Regels een atomaire uitvoering hebben die meerdere regels triggert.

Om in dit geval een keuze te maken uit wélke regel eerst gaat, zal er een conflict resolutie mechanisme in werking moeten treden. Een conflict resolutie mechanisme biedt daarbij de keus uit twee alternatieven : een seriële uitvoering of een parallelle.

Seriële uitvoering : hier wordt één enkele regel gekozen. De keus wordt gemaakt aan de hand van bepaalde vooropgestelde criteria. De criteria kunnen deterministisch of niet-determinisisch zijn.

Een voorbeeld van een deterministisch criterium is de wijze van voorrang verlenen : er kan een totale voorrangsordening tussen de regels zijn bepaald. Een voorbeeld van een niet-deterministisch criterium is een gedeeltelijke ordening van voorrang tussen de regels. Als het de gebruiker is toegestaan een voorrangsordening te specificeren, kan zo weer deterministisch gedrag verkregen worden.

Parallelle uitvoering : alle regels die zijn getriggerd worden parallel uitgevoerd. Dat kan bijvoorbeeld door een aparte transactie uit te voeren om de conditieevaluatie en actie-uitvoering te regelen.

6.1.1.6.

Tijd en bereik van event consumption

Event consumption is het verbruiken van een event, dat wil zeggen het plaatsvinden van de event. Bij event consumption gaat het erom of : Reeds plaatsgevonden events hun vermogen om regels te triggeren behouden. En wanneer dat niet het geval is (dan vindt dus de consumptie plaats !). Het bereik van event consumption geeft aan wat er met de triggering events gebeurd nadat de regel die ze getriggerd hebben is verwerkt. De mogelijkheden daartoe zijn :

Geen consumptie : de triggering events behouden het vermogen om regels te triggeren. Ze blijven onaangetast door de conditie-evaluatie en actie-uitvoering van de regel.


57

Lokale consumptie : de triggering events zijn uitgewerkt op de geactiveerde regel. De geactiveerde regel heeft de events verbruikt. Maar de triggering events kunnen nog wel andere regels beïnvloeden die nog niet zijn verwerkt. Globale consumptie : de triggering events zijn uitgewerkt op de geactiveerde regel én alle andere regels die nog verwerkt moeten worden. De events zijn als het ware lokaal verbruikt door de getriggerde regel én door de andere regels die nu niet meer door de events worden getriggerd. De lokale consumptie is de meest gangbare in de bestaande active database systemen.

De tijd van event consumption is het tijdsbestek waarin een getriggerde event wordt verbruikt of geconsumeerd. Er zijn verschillende scenario’s mogelijk bij het consumeren van een event m.b.t. de tijd : De consumptie kan namelijk plaatsvinden nadat de regel is beschouwd en dat is onafhankelijk van de uitkomst van de conditie-evaluatie.

Maar de consumptie kan ook pas plaatsvinden wanneer een regel daadwerkelijk wordt uitgevoerd. Het gevolg van zo een late consumptie is dat wanneer de conditie-evaluatie false oplevert, de consumptie niet plaatsvindt. Het blijft als het ware hangen en wordt pas bij de uitvoering van de regel geconsumeerd.

De gangbare manier van de consumptie van triggering events is die van consumptie nadat de conditie-evaluatie heeft plaatsgevonden.

6.1.1.7.

Inspectie van de transactie-geschiedenis

Het inspecteren van de transactie geschiedenis van het systeem kan handig zijn wanneer de originele waarde, van een entiteit die aangepast is, moet worden gemanipuleerd. Het gedrag van een regel kan beïnvloed worden door de geschiedenis van de transactie. Bijvoorbeeld kan gedacht worden aan het aanpassen van een salaris na een onterechte of niet-geautoriseerde verhoging. Er kunnen daarbij twee soorten van informatie betreffende de transactie-geschiedenis opgevraagd worden : database toestanden uit het verleden en reeds plaatsgevonden events.

Database toestanden uit het verleden.

Theoretisch gezien zouden alle tussenliggende toestanden waarin de database zich bevond, van de transactie van de huidige toestand tot het begin van de transactie, toegangbaar kunnen zijn. De meeste systemen in de praktijk echter beperken zich maar tot :

De toestand voor de uitvoering van de transactie (pre-transaction).


58

De toestand na de laatste beschouwing of overweging van de regel (lastconsideration). De toestand voordat de events de regel hadden getriggerd en die nog niet verwerkt zijn (pre-event).

Voorbeeld van de set-georiënteerde versie van een SQL3 regel waarin data uit het verleden wordt gemanipuleerd (herschrijving van het voorbeeld op p. 54). CREATE TRIGGER Compute_Emp_Number2 AFTER INSERT ON Employee REFERENCING OLD_TABLE AS Old_Emp FOR EACH STATEMENT WHEN TRUE update Company_statistics set new_emp_number = new_emp_number + (select count(*) from Employee – (select count(*) from Old_Emp)

Reeds plaatsgevonden events.

Inspectie van de transactie-geschiedenis biedt de mogelijkheid om items die beïnvloed zijn door reeds plaatsgevonden events m.b.v. queries op te vragen. Het belang hiervan ligt in het feit dat alleen de conditie-evaluaties die ooit uitgevoerd of beschouwd zijn door een transactie, de relevante data dus, worden beschouwd. Dit is een optimalisatie. Verder kunnen mede hierdoor ook regels worden gedefinieerd die gebaseerd zijn op een vescheidenheid aan data (kan bijvoorbeeld nodig zijn voor integrity checking). Het inspecteren van reeds plaatsgevonden events kan op verschillende manieren plaatsvinden, afhankelijk van wat verwacht wordt. Voorbeelden zijn : Inspectie van items die beïnvloed zijn door alle events die hebben plaatsgevonden sinds de transactie werd uitgevoerd. Inspectie van de items die beïnvloed zijn door events die de meest recente triggering van de regel teweeg hebben gebracht. Inspectie van de items die beïnvloed zijn door alle events, dus ook die die de regel niet triggeren; of juist wel triggeren. De inspectie van de items wordt gerealiseerd door de querytaal in de regels te gebruiken. De querytaal wordt gebruikt door die uit te breiden met een verzameling van predicaten over items van plaatsgevonden events.


6.1.1.8.

59

Samengestelde events en manipulatie event net effect

De primitieve events die in [11] genoemd worden zijn bijvoorbeeld database updates, opdrachten van een transactie of kloksignalen. Regels kunnen getriggerd worden door willekeurige combinaties van deze primitieve events. Zo kunnen verschillende combinaties van events samengesteld worden. Er zijn hele simpele combinaties (bijvoorbeeld de disjunctie van events), maar ook vrij complexe (bijvoorbeeld met gebruikmaking van logische connectoren en tijd operatoren).

De meest voorkomende samengestelde event is de event net effect computation. Deze samengestelde event bestaat uit : Het beschouwen van de plaatsgevonden events, ongeacht wat er daarna gebeurd is. Het beschouwen van het netto effect van de volgorde van events (oftewel netto events).

Bij het beschouwen van netto events wordt het plaatsvinden van sommige events gezien als een invalidatie van de voorgaande (bijvoorbeeld een verwijder-operatie na een aanpassing). De criteria voor het bepalen van het netto effect wisselt per systeem. Het Starburst systeem (vergelijkbaar met andere systemen) past de volgende criteria toe :

Als een tupel X wordt aangemaakt en binnen dezelfde transactie wordt de tupel later geupdate en vervolgens verwijderd, is het netto effect null.

Als een tupel wordt aangemaakt (of geupdate) en vervolgens verscheidene keren wordt geupdate, is het netto effect de aanmaking (of de update) die de eindversie van de tupel oplevert.

Als een tupel wordt geupdate en vervolgens verwijderd, is het netto effect de verwijdering van de tupel.

Als meerdere events hetzelfde object beïnvloeden, worden ze beschouwd als één event. De relevante trigger wordt maar één keer beschouwd. (Dit criterium komt van het Ode systeem).

Deze criteria en andere vinden hun toepassing bij :

Netto effect voor triggering.

De triggering van een regel kan plaatsvinden door reeds plaatsgevonden events of netto events. Als netto events worden gebruikt bestaat de kans dat een eenmaal getriggerde regel nooit meer wordt getriggerd nadat de event heeft plaatsgevonden.


60

Voorbeeld Stel dat de trigger van een regel de creatie van een entiteit is. Als deze entiteit wordt verwijderd, bestaat de trigger van de regel niet meer.

Netto effect voor event predicaten. Bij het opvragen van de events van een transactie kan gekozen worden uit de plaatsgevonden events en netto events.

Verband tussen event/action Het verband tussen event en action heeft te maken met de reactie van een actieve regel. De reactie wordt meestal beschouwd na het plaatsvinden van zijn triggering events en het effect van de regel-uitvoering beïnvloedt de update van de triggering. In [11] wordt alleen deze mogelijkheid beschouwd.

De verzameling van dimensies die zojuist is beschreven wordt in [11] gebruikt om op een informele manier de verschillen en overeenkomsten van bestaande systemen te verklaren. In Tabel 2 wordt van de dimensies (besproken in paragraaf 6.1.1.1 en 6.1.1.7) aan de hand van de waarden, de bestaande systemen aangegeven zoals dat in [11] wordt gepresenteerd. Het nut van de onderverdeling in dimensies is een systematischere aanpak van de ontwikkeling van nieuwe aspecten m.b.t. regels. Zo kunnen regels van bestaande active database systemen makkelijker gecodeerd worden in een uniek formalisme. Het zal ook een beter begrip kweken van bestaande systemen.

61


Dimensies Granularity van updates

Granularity van regels

Inspectie van transactiegeschiedenis

Waarden

Bestaande systemen

Instantie-georiënteerd

Exact, NAOS, Ode, Reach, Samos, Sentinel, TriGS

Set- georiënteerd

Allbase, A-RDL, Ariel, Chimera, Informix, Ingres, Interbase, Oracle, Postgres, RDB, SQL3, Starburst, Sybase

Instantie-georiënteerd

Allbase, Exact, Informix, Ingres, Interbase, NAOS, Ode, Oracle, Postgres, RDB, Reach, Samos, Sentinel, SQL3, TriGS

Set- georiënteerd

A-RDL, Ariel, Chimera, Informix, NAOS, SQL3, Starburst, Oracle, Sybase

Event predicaten

Allbase, A-RIDL, Chimera, Informix, Ingres, Interbase, NAOS (“met” clause), Oracle, Postgres, RDB, SQL3, Starburst, Sybase

Pre-Event predicaat

Allbase, Exact, Informix, Ingres, Interbase, NAOS, Oracle, Postgres, RDB, SQL3, Starburst , Sybase

Last-consideration predicaat

Chimera, Starburst

Pretransaction predicaat

Chimera

Tabel 2 : Gedeeltelijk overzicht semantiek van bestaande active databases

6.1.2. Regelsyntax active database De eerste stap in een beter begrip van bestaande systemen is de codering van de regels in een syntaxformaat dat leesbaar is voor de gebruikers. In [11] wordt de EECA (Extended Event Condition Action) syntax als uniforme notatie voor het wijd bereik van bestaande aspecten voorgesteld. Extended Event Condition Action regels bestaan net als ECA regels nog steeds uit drie delen (Event-Condition-Action), maar


62

er zijn enkele sleutelwoorden en ad hoc notaties toegevoegd ter beschrijving van bovengenoemde dimensies. EECA regels specificeren in een systeem-onafhankelijk notatie waar een regelsysteem toe in staat is. Een EECA regel begint met een declaratief gedeelte waarin de volgende sleutelwoorden worden gebruikt : granularity : het sleutelwoord granularity specificeert de korreligheid van de regel-actie en kan de waarden instantie-georiënteerd (I/O) en set-georiënteerd (S/O) aannemen (zie paragraaf 6.1.1.1). Koppel-mode : het sleutelwoord EC specificeert de Event-Condition koppel-mode en kan de waarden immediate of deferred aannemen. De Condition-Action koppel-mode heeft altijd de waarde immediate waardoor het wordt weggelaten in de specificatie (zie paragraaf 6.1.1.2). Atomisch : de Boolean interruptable specificeert of de regel-actie automatisch (waarde = False) moet worden uitgevoerd of onderbroken (waarde = True) kan worden (zie paragraaf 6.1.1.3). Event concumption : het sleutelwoord consumption-scope specificeert het bereik van de event consumption en kan de waarden none, local, global-to{list-of-rules} aannemen. Een tweede sleutelwoord consumption-time specificeert de event consumption tijd en kan de waarden consideration en execution aannemen (zie paragraaf 6.1.1.6).

Onderstaand wordt een voorbeeldregel van het Postgres systeem gepresenteerd. Deze regel reageert op een aanpassing van het salaris van werknemers. Als de werknemer Sam heet en zijn salaris is nog steeds minder dan 5000, dan krijgt hij door deze regel een salarisverhoging van 10 %.

Voorbeeldregel van het Postgres systeem

define rule Raise_Sam‘s_salary on replace to EMP.salary where EMP.name= “Sam” and EMP.salary < 5000 then do replace EMP ( salary = 1.1*NEW.salary ) where EMP.name = CURRENT.name


63

De gebruikte sleutelwoorden uit het voorbeeld zijn : CURRENT : refereert naar de waarde van de updated tupel vóór de update die de regel heeft getriggerd. NEW : refereert naar de waarde van de tuple ná dezelfde update. De gebruikte sleutelwoorden CURRENT en NEW zijn voorbeelden van semantische dimensies in de regel-syntax inspectie van de transactie-geschiedenis. Andere systemen gebruiken ook soortgelijke sleutelwoorden, het resultaat van de actie kan echter verschillen. Dit kan worden verklaard door onder andere het verschil in de manier waarop elk systeem zijn regels update en ook hoe de activering van de regels plaatsvindt. Een vertaling van dezelfde Postgres regel naar EECA formaat wordt in het volgende voorbeeld gepresenteerd.

Voorbeeldregel van het Postgres systeem in EECA

define granularity I / O EC immediate interruptable True consumption-scope local consumption-time consideration rule Raise_Sam‘s_salary event: replace(Emp.salary) condition:pending(replace(Emp.salary),X),X.name= “Sam”, X.salary<5000 (*X=NEW tuple*) action: replace (Emp.salary, X, 1.1*X.salary)

Deze EECA regel laat meer informatie zien die niet expliciet in de originele regel was vermeld, namelijk dat de regel een granularity heeft die instantie-georiënteerd is. Dat houdt in : de regel reageert op enkelvoudige tupel-niveau updates. de regel wordt meteen gestart na zijn triggering event. de actie van de regel is onderbreekbaar om een andere regel te starten als een andere event plaatsvindt. de triggering event wordt vergeten (consumed) door deze regel nadat het overwogen is. Al deze informatie is hard-gecodeerd in de semantiek van het Postgres systeem en wordt pas duidelijk in de Extended Event Condition Action syntax. Bovengenoemde voorbeelden laten zien dat de encodering van regels van bestaande systemen naar EECA regels een grondige kennis van de semantiek van een specifiek systeem vergt.


64

6.1.3. Core model active database Informeel begrip van het gedrag van active databases (door de onderverdeling in dimensies) is niet genoeg. De semantiek van active databases dient gefundeerd te zijn op formele concepten zodat een programmeur de precieze uitkomst van zijn programma zou kunnen nagaan. Een specifieke eis die volgens [11] voor deze formele basis nodig is, is een hoge graad van modulariteit en extensibiliteit. Om dit te kunnen bewerkstelligen wordt in [11] een wat formelere regeltaal geïntroduceerd, namelijk de core taal. De core taal introduceert een core regelsyntax. Met de core taal kunnen aspecten van het gedrag van een active database weergegeven worden. EECA regels kunnen op het syntax niveau helemaal vertaald worden naar het core formaat. Regels die in het core formaat zijn, moeten door instructies te geven aan een uitvoeralgoritme, expliciet kunnen specificeren hoe een bepaald semantisch aspect wordt verkregen. Dit uitvoeralgoritme moet voor alle bestaande systemen hetzelfde zijn, het moet dus uniek zijn. Binnen de core regelsyntax wordt een active database beschouwd als een combinatie van een passieve database en een eventbase. In de passieve database wordt de data van de toepassing opgeslagen en in de eventbase worden feiten opgeslagen die relevant zijn voor de transactie-geschiedenis van de database. Een update van een active database heeft altijd een gelijktijdig effect op zowel de data in de passieve database als de events uit de eventbase. Een eventbase [11] registreert interne events en externe events. Interne events hebben te maken met database handelingen zoals bijvoorbeeld toevoegingen, verwijderingen en updates. Externe events daarentegen zijn onafhankelijk van de interne database functies. Voorbeelden zijn de commando’s commit en rollback, maar ook de tijd zou een externe event kunnen zijn, als dat wordt toegevoegd in de eventbase. De eventbase is een datastructuur die voor ons praktijkvoorbeeld van belang is en de volgende paragraaf zal daarop ingaan.


65

6.2. Active DBMS en hypermedia systemen In paragraaf 5.3 is de architectuur van een hypermedia systeem besproken. En hoewel in de literatuur ([22]) wordt aangegeven dat een Object Oriented DataBase Management System (OODBMS) de beste keus voor database ondersteuning zou zijn, kan beargumenteerd worden dat het regel-gebaseerde aspect van een active dbms in ons praktijkvoorbeeld van pas kan komen. Active databases zijn in staat handelingen uit te voeren wanneer het triggermechanisme wordt geactiveerd. Een probleem wat reeds naar voren is gekomen in paragraaf 2.6.1, is het feit dat informatie verouderd raakt en niet meer up-to-date is. De manier waarop thans dit probleem wordt verholpen heeft te maken met de afhankelijkheidsrelatie die de website heeft met de bezoekers van de website. Een migratie naar een databaseondersteunde omgeving zou echter betekenen dat gebruik zou kunnen worden gemaakt van active databases. Toepassing van een active database op de juiste manier zou de rol van de bezoekers van de website kunnen overnemen. Het gevolg hiervan is dat de afhankelijkheidsrelatie opgeheven zou worden en het probleem van inconsistentie, onvolledigheid en actualiteit (in elk geval deels) opgelost.

Zoals in paragraaf 6.1 reeds is aangegeven bestaat een active database uit een passieve database en een set van actieve regels. Onderzocht moet worden of de ECA-regel binnen de context van een Object Oriented database kan worden geplaatst. Dat zou namelijk betekenen dat ander soortige events dan de ‘ normale’ database events (object manipulatie en object selectie) zouden kunnen worden waargenomen. Zo wordt in [27] onderscheid gemaakt tussen de volgende events binnen een Object Oriented database : 1. Events die gerelateerd zijn aan de uitvoering van objectmethoden of objectklassen (bijvoorbeeld het berekenen van een waarde). 2. Events die gerelateerd zijn aan de uitvoering van een transactie (bijvoorbeeld voor de transactie begint). 3. Events die te maken hebben met tijd (bijvoorbeeld een gebeurtenis die om 8:00 u plaatsvindt). 4. Externe events (bijvoorbeeld een GUI-gebeurtenis (Graphical User Interface) of een temperatuur-meting). 5. Events die door de gebruiker worden gedefinieerd.

Het opheffen van bovengenoemde afhankelijkheidsrelatie betekent het definiëren van EECA-regels waarin externe events zijn opgenomen. De eventbase zal deze externe events moeten kunnen registreren. Omdat het in ons praktijkvoorbeeld niet gaat om meetbare aspecten zoals de temperatuur, zal het registreren van de externe events op een ingenieuze manier moeten plaatsvinden.


66

Een manier is de indexering van alle relevante events op een zodanige manier, dat de gebruiker zelf kan aangeven welke event, wanneer en hoe vaak (vergelijkbaar met bijvoorbeeld het instellen van de Scan Disk functie onder Windows) een event getriggerd moet worden. Met betrekking tot ons praktijkvoorbeeld zou het op deze manier mogelijk zijn de informatie uit het archief zelf (door de redactie) up-to-date te houden. De toepassing van het regel-gebaseerde aspect van active databases in een Object Oriented database kan ertoe leiden dat het DataBase Management Systeem in de opslaglaag van een hypermedia systeem een zelfonderhoudende functie gaat vervullen. Deze visie zal echter formeel onderbouwd dienen te worden.

7. Evaluatie en conclusie Vaststelling huidige situatie Om een verandering van de efficiëntie binnen het onderhoud en beheer van een website te bewerkstelligen, welke verandering dan ook, dient eerst de huidige situatie bekeken te worden. Als voorbeeld uit de praktijk is de huidige situatie van de website van Ouders Online onder de loep genomen. Zo zijn typische websiteproblemen naar voren gekomen. Strategie Aan de hand van de problemen zijn de bronnen van inefficiëntie vastgesteld. Die hebben onder andere geleid tot het opstellen van criteria voor efficiënt onderhoud en beheer. Het is duidelijk dat de onderliggende gegevens van een website gestructureerd opgeslagen moeten worden, teneinde problemen zoals inconsistentie, onvolledigheid en actualiteit te minimaliseren. Aangezien het doel van een hypermedia design methode het ondersteunen van een systematische ontwikkeling van hypermedia toepassingen is, was de volgende stap het nagaan van die mogelijkheid. Verschillende bestaande hypermedia ontwikkelsystemen en methoden zijn besproken met de voor- en nadelen. Om het gestructureerd opslaan van websitegegevens te ondersteunen en de genoemde problemen te minimaliseren, is de toepassing van een hypermedia design methode voorgesteld. Daarbij is de migratie besproken die nodig zou zijn om te komen tot een vernieuwde websitestructuur met een database management systeem ter ondersteuning. De aanwezigheid van een database management systeem in de architectuur van een hypermedia toepassing, heeft geleid tot de vraag welke rol active databases kunnen spelen in het actueel houden van gegevens. De toegevoegde waarde van een active database is daarbij besproken. Conclusie Een hypermedia design methode probeert niet alleen om gegevens op een gestructureerde manier op te slaan, maar heeft tevens de potentie om het onderhoud en beheer aan de website te reduceren. Door het beschrijven van de relevante informatieobjecten van een website en de navigatiemechanismen worden belangrijke dimensies van hypermedia toepassingen gevangen (inhoud, structuur, presenatie, dynamiek en interface). De voordelen van het gebruik van een hypermedia design methode zullen echter pas duidelijk tot uiting komen wanneer de procesontwikkeling van hypermedia formeel beschreven wordt. Om die reden (geen formele semantiek) vindt de ontwikkeling van hypermedia toepassingen thans nog ad hoc plaats.

67

HOOFDSTUK 7. EVALUATIE EN CONCLUSIE

68

Herstructurering van de website van Ouders Online met behulp van een hypermedia design methode zal de problemen m.b.t. de presentatie van de website en de opslag van de gegevens minimaliseren. De problemen van sociale aard zoals het karakter van de website en de organisatie (de informatieaanbieders) erachter bevinden zich buiten het bereik van automatisering. De toepassing van het regel-gebaseerde aspect van active databases in een Object Oriented database kan ertoe leiden dat het database management systeem in de opslaglaag van een hypermedia systeem een zelfonderhoudende functie gaat vervullen. De semantiek van active databases biedt in het concept eventbase daartoe een mogelijkheid die nog onderzocht moet worden.

Toekomstig onderzoek Om de ad hoc ontwikkeling van hypermedia te voorkomen of verbeteren zal begonnen moeten worden met het begrijpen van de hypermedia ontwikkelprocessen. Het is moeilijk methodologiën en technieken uit andere disciplines voor hypermedia ontwikkelprocessen te hanteren, omdat hypermedia toepassingen andersoortige dimensies beschouwen dan bijvoorbeeld informatiesystemen. Het nut van de onderverdeling in dimensies was een systematischere aanpak van de ontwikkeling van nieuwe aspecten. Dat is duidelijk naar voren gekomen bij de bespreking van active databases. Voor hypermedia is ook een systematischere aanpak vereist en onderverdeling in dimensies zou een goede start zijn om een uniek formalisme te creëren. De daadwerkelijke herstructurering van de website (de structurele migratie van de conceptuele structuur), de uiteindelijke performance van het systeem en de toepassing van een active database in een Object Oriented DBMS zijn zaken die verder in de praktijk onderzocht moeten worden.

Nawoord Het praktijkvoorbeeld dat in voorgaande hoofdstukken is besproken blijft uiteraard onderhevig aan ontwikkelingen. Zo zal medio 1999 de website van Ouders Online een karakterverandering ondergaan. De website zal voor een gedeelte nog steeds gratis toegankelijk blijven. Een deel van de website zal specifieke diensten aanbieden. De toegang tot dat deel van de website zal dan alleen mogelijk zijn wanneer de gebruiker een abonnement heeft afgesloten.

69

Lijst van Figuren Figuur 1 : Raamwerk ter beschrijving van een methode, 19 Figuur 2: Overzicht van de verschillende fasen van WSDM, 26 Figuur 3 : Overzicht van external views, 27 Figuur 4 : Schema van de omgeving van de universiteit, 29 Figuur 5 : User Object Model voor ‘ Ingeschreven Studenten’, 33 Figuur 6 : Perspectives variaties voor het Object Type Cursus, 34 Figuur 7 : De verschillende object modellen in relatie tot elkaar, 34 Figuur 8 : Representatie van de navigatie concepten, 35 Figuur 9 : Navigatie track (pad) voor de perspective van Buitenlandse Studenten, 36 Figuur 10 : Architectuur van drie hypermedia systemen, 43 Figuur 11 : De verschillende vormen van migratie, 45 Figuur 12 : Een mogelijke UOM voor de user class ‘ Ouders van pasgeborenen’, 47

70

Lijst van Tabellen Tabel 1 : Verschillende fasen genoemde hypermedia design methoden, 23 Tabel 2 : Gedeeltelijk overzicht semantiek van bestaande active databases, 61

71

Bibliografie [1] Olga De Troyer. Designing Well-Structured Websites: Lessons to be Learned from Database Schema Methodology, Tilburg University, INFOLAB, Tilburg, The Netherlands. [2] Henk Boeke, Louis Stiller, Internet voor Professionals, Academic Service, Schoonhoven, 1998. [3] G. Miller. The Magical Number Seven, Plus or Minus Two : Some Limits on Our Capacity for Processing Information. In The Psychological Review , vol. 63(2) : p. 86, March 1956. [4] Arthur Meyer. Site Works. Systematische ontwikkeling van dynamische websites. Scriptie, Katholieke Universiteit Nijmegen, Nijmegen, Nederland, November 1998. [5] Dr. David Lowe, Dr. Richard Webby. Web Development Process Modeling and Project Scoping : Work in Progress. http://btwebsh.macarthur.uws.edu.au/san/webe98/Proceedings/Lowe/WebE98LoweWebby.htm. [6] V. Balasubramanian. State of the Art Review on Hypermedia Issues And Applications. Graduate School of Management, Rutgers University, Newark, New Jersey. http://wwwis.win.tue.nl/~percy/HTML/. [7] O.M.F. De Troyer, C.J. Leune. WSDM: a User-Centered Design Method for Web Sites. In Computer Networks and ISDN Systems 30 (1998) : p. 85-94. [8] G.M.Wijers. Modeling Support in Information Systems Development. PhD thesis, Delft University of Technology, Delft, The Netherlands, 1991. [9] P.Pauen, J. Voss. The HyDev Approach to model-based Development of Hypermedia Applications. In Proc. Hypertext ’98 Workshop, 1st International Workshop on Hypermedia Development : Processes, Methods and Models, June 1998, online html version. http://www.informatik.fernunihagen.de/import/pi3/hydev/hypertext98/index.htm. [10]Manfred Thüring, Jörg Hannemann, Jörg M. Haake. Hypermedia and Cognition : Designing for Comprehension. In Communications of the ACM, vol. 38(8) : p. 5766, August 1995. [11]Piero Fraternali, Letizia Tanca. A Structured Approach for the Definition of the Semantics of Active Databases. In ACM transactions on Database Systems, vol. 20(4) : p. 414-471, December 1995. [12]J.D. Ullman, Principles of Database Systems. Second Edition. Pitman Publishing Limited, 128 Long Acre, London WC2E 9AN, 1982.

72

BIBLIOGRAFIE

73

[13]Alicia Díaz, Tomás Isakowitz. RMCase : Computer-Aided Support for Hypermedia Design and Development. In S. Fraïssé, F. Garzotto, T. Isakowitz, J. Nanard and M. Nanard, editors, Hypermedia Design : Proceedings of the International Workshop on Hypermedia Design, Montpellier, France, 1-2 June 1995. Workshops in Computing Series, edited by prof. C. J. van Rijsbergen, p. 315. Springer-Verlag, 1996. [14]G. Rossi, D. Schwabe, C.J.P. Lucena, D.D. Cowan. An Object-Oriented Model for Designing the Human-Computer Interface Of Hypermedia Applications. In S. Fraïssé, F. Garzotto, T. Isakowitz, J. Nanard and M. Nanard, editors, Hypermedia Design : Proceedings of the International Workshop on Hypermedia Design, Montpellier, France, 1-2 June 1995. Workshops in Computing Series, edited by prof. C. J. van Rijsbergen, p. 123-143. Springer-Verlag, 1996. [15]Wim Goedefroy, Robert Meersman, Olga De Troyer. UR-WSDM : Adding User Requirement to Model Web Based Information Systems. http://ise.ee.uts.edu.au/hypdev/ht98w/Goedefroy/WHDsubmitted.htm. [16]Grady Booch, Object-Oriented Analysis and Design with applications, second edition, Addison-Wesley Publishing Company, 1994. [17]C.H.A. Koster, Systematisch Leren Programmeren : Bottom-Up Programmering. Academic Service, Schoonhoven, Nederland, 1991. [18]P. Greenspun, P. Greenspun’s Database Backed Websites : The Thinking Person’s Guide to Web Publishing. ZD Press, 1997. [19]Ian Sommerville, Software Engineering. Second Edition. Addison-Wesley, Workingham, England, 1984. [20]P.M.E. De Bra. Definition of hypertext and hypermedia. TU Eindhoven University of Technology, The Netherlands. http://wwwis.win.tue.nl/2L670/static/definition.html. [21]B. Prakken, Informatie en de Besturing van Organisaties. Een Bedrijfskundige Aanpak van Informatievraagstukken. Van Gorcum & Comp. B. V., Postbus 43, 9400 AA Assen, Nederland, 1997. [22]Ajit Bapat, Jürgen Wäsch, Karl Aberer, Jörg M. Haake. HyperStorM : An Extensible Object-Oriented Hypermedia Engine. http://wwwx.cs.unc.edu/~barman/HT96/P46/HT96BapatEtAl.html. [23]P. D. Bruza. Stratified Information Disclosure : A Synthesis between Information Retrieval and Hypermedia. PhD thesis, University of Nijmegen, Nijmegen, the Netherlands, 1993. [24] John F. Buford. Evaluating HyTime : An Examination and Implementation Experience. Department of Computer Science, University of Massachusettes Lowell. http://www.cs.unc.edu/~barman/HT96/P69/buford.htm.

BIBLIOGRAFIE

74

[25]Frank G. Halasz. Reflections on Notecards: Seven Issues for the Next Generation of Hypermedia Systems. In Communications of the ACM, vol. 31(7) : p. 836-852, July 1988. [26]R. B. Buitendijk. Towards an Effective Use of Relational Database Management Systems. Proefschrift, Vrije Universiteit te Amsterdam, Amsterdam, Nederland, 1991. [27]Andreas Pfeifer, Volker Wulf. Negotiating Conflicts in Active Databases. http://www.informatik.uni-bonn.de/~volker/publication/cera.htm.

Index Active databases Active DBMS, 51 Active Databases core model, 64 dimensies, 52 eventbase, 64 Event-Condition-Action-regel, 51 Extended-Event-Condition-Action-regel, 61 hypermedia systemen, 65 applicatie website, 25 Atomaire uitvoering regel-actie, 55 bereik event consumption, 56 besturingscyclus, 14 bottom-up view, 24 conclusie, 67 concrete migratie, 48 Condition-Action koppeling, 54 Conflict resolutie mechanisme, 56 consumption-scope, 62 consumption-time, 62 database administrator, 44 data-driven aanpak, 26 dbms, 44 deferred, 62 EECA sleutelwoorden, 62 Efficiënt onderhoud en beheer adaptief onderhoud, 15 correctief onderhoud, 15 perfectief onderhoud, 15 evaluatie, 67 evaluatie hypermedia design methoden, 38 event consumption, 56 event net effect, 59 event/action, 60 Event-Condition koppeling, 54 external view, 27 external view integration, 27 Geen consumptie, 56 Globale consumptie, 57 granularity, 62 granularity van regels, 52 granularity van updates, 52 herstructurering, 41 Hypermedia Design Methode HyDev, 20 hypermedia toepassing, 17 hypertext, 17 OOHDM, 21 RMM, 22 WSDM, 25 hypermedia engines HyperStorm, 25

OOHDM web, 24 RMCase, 24 WebComposition, 24 immediate, 62 Inefficiëntie bronnen, 13 Informatie Systeem Ontwikkeling raamwerk, 18 information requirement, 30 inspectie transactie-geschiedenis, 57 Instantie- of tupel-georiënteerde regels, 53 Instantie- of tupel-georiënteerde update, 53 interruptable, 62 karakteristieken, 30 kiosk website, 25 koppel-modes, 54 last-consideration, 58 Lokale consumptie, 57 net effect computation, 59 netto events, 59 operationeel beleid, 14 Ouders Online doelgroep, karakter & doelstelling, 6 onderhoud en beheer, 8 ontstaan, het, 5 presentatie website, 6 problematiek, 9 verantwoordelijkheid medewerkers, 5 Parallelle conflict resolutie, 56 passieve database, 51 perspective, 30 pre-event, 58 pre-transaction, 57 Regel-koppel-mode, 54 Regelsyntax active database, 61 regel-uitvoering, 55 Samengestelde events, 59 scriptie inleiding, 1 opbouw, 3 probleemstelling, 2 Seriële conflict resolutie, 56 Set-georiënteerde regels, 53 Set-georiënteerde update, 53 structurele migratie, 46 tijd event consumption, 57 Toepassing hypermedia design de architectuur, 42 de migratie, 44, 48 de voordelen, 42 top-down view, 20 transactie-semantiek-mode, 55 Transactie-semantiek-mode, 54 transactie-uitvoering, 55

75

INDEX

usability requirement, 30 user-centured aanpak, 26 user-driven aanpak, 26 way of modelling HyDev, 20 WSDM, 28 way of modelling & way of working OOHDM, 21 RMM, 22 way of thinking HyDev, 20 OOHDM, 21 RMM, 22

76

WSDM Business Object Model, 33 conceptual design fase, 31 implementation design fase, 37 implementation fase, 38 Navigational Design, 35 Object Modelling, 32 Perspective Object Model, 33 user class, 29 User Class Description, 30 User Classification, 28 user modeling fase, 28 User Object Model, 32

EFFICIËNT ONDERHOUD & BEHEER VAN WEBSITES

Recommend Documents