EFFICIËNT ONDERHOUD & BEHEER VAN WEBSITEScs.ru.nl/mtl/scripties/1999/456.Welas.pdf · Het belang...

EFFICIËNT ONDERHOUD &BEHEER VAN WEBSITES

Een theoretische bespreking van de mogelijkheden

S. J. Welas

Faculteit der Natuurwetenschappen, Wiskunde en Informatica Mei 1999Afstudeerrichting : Bedrijfsgerichte InformaticaAfstudeernummer : 456

iii

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

&

voor Rinia Hermien

v

Voorwoord

Het belang van informatiemodellering binnen de wereld van informatiesystemenwordt algemeen erkend. We kunnen daar lering uit trekken en ons inzetten ook voorhypermedia het belang te onderkennen.

Deze scriptie is het product van mijn afstudeerproject, de afsluiting van mijnstudieperiode aan de Katholieke Universiteit Nijmegen. Tijdens mijn afstuderen benik begeleid door drs. Henk Boeke en dr. ir. Theo van der Weide. Mijn dank hiervoorgaat vanaf deze plek naar hen uit. Mijn dank gaat tevens uit naar het thuisfront (mijnouders) en in intensievere mate naar Zeger van Vreeswijk : jouw bemoeienis tijdensde totstandkoming van de scriptie is niet altijd gekoesterd, maar wel enormgewaardeerd.

S. J. Welas

Nijmegen, 12 Mei 1999

��

vii

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........................................................................................................................ 92.6.1. Inconsistentie,onvolledigheid en actualiteit .................................................................... 102.6.2. Gegevensopslag............................................................................................................. 102.6.3. Tijd.................................................................................................................................. 11

3. Eff iciënt ond erhoud en beheer............................................................................................... 13

3.1. Inefficiëntie bronnen .......................................................................................................... 13

3.2. Onderhouds- en beheer-criteria ........................................................................................ 14

4. Hypermedia Design Method e ................................................................................................. 17

4.1. Hypermedia hype .............................................................................................................. 17

4.2. Design methoden .............................................................................................................. 184.2.1. Top-Down view............................................................................................................... 204.2.2. Bottom-Up view .............................................................................................................. 24

4.3. De WSDM methode........................................................................................................... 254.3.1. User Modeling fase ........................................................................................................ 284.3.2. Conceptual Design fase ................................................................................................. 314.3.2.1. Object Modeling subfase..................................................................................... 324.3.2.2. Navigational Design subfase................................................................................ 354.3.3. Implementation Design fase........................................................................................... 374.3.4. Implementation fase ....................................................................................................... 38

4.4. Evaluatie beschreven methode ......................................................................................... 38

5. Toepassing hypermedia design ............................................................................................. 41

viii

5.1. De keuze maken ............................................................................................................... 41

5.2. De voordelen ..................................................................................................................... 42

5.3. De architectuur .................................................................................................................. 42

5.4. De migratie ........................................................................................................................ 445.4.1. Het migratieproces ......................................................................................................... 455.4.2. Te verwachten problemen.............................................................................................. 48

6. Rol Active Databases .............................................................................................................. 51

6.1. Een Active Database Management Systeem.................................................................... 516.1.1. Dimensies active database ............................................................................................ 526.1.1.1. Granularity of korreligheid van updates en regels ............................................... 526.1.1.2. Verschillende koppel-modes ................................................................................ 546.1.1.3. Atomaire uitvoering van de regel-actie ................................................................ 556.1.1.4. Relatie van regel-uitvoering tot transactie-uitvoering........................................... 556.1.1.5. Conflict resolutie mechanisme ............................................................................. 566.1.1.6. Tijd en bereik van event consumption ................................................................. 566.1.1.7. Inspectie van de transactie-geschiedenis ............................................................ 576.1.1.8. Samengestelde events en manipulatie event net effect ...................................... 596.1.2. Regelsyntax active database ......................................................................................... 616.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

1

1. Inleiding

Er zijn verschillende perspectieven om het ‘fenomeen’ Internet te bekijken. De meestvoor de hand liggende is natuurlijk vanuit de gebruikerskant, de surfer die op zoekgaat naar voor hem nuttige informatie. Een ander perspectief is dat vanuit deinformatieaanbieders, diegenen die de websites tot stand brengen. Vanuit dit laatsteperspectief zal het onderwerp van deze scriptie vorm krijgen.

Diegenen die zich ertoe wagen één of meerdere websites op te zetten hebben eenbepaald doel voor ogen. Het opzetten van een website vormt echter geen grotetechnische drempel meer. Het wordt pas interessant wanneer naar de organisatieachter de website gekeken wordt. Laten we in deze een website beschouwen diezichzelf als ‘elektrisch’ tijdschrift presenteert. Er is bewust gekozen voor elektrisch inplaats van elektronisch, omdat die woordkeuze meer warmte zou uitstralen entevens een verwijzing is naar ‘draden en stekkers’ : het staat nog in dekinderschoenen.

Het magazine gedeelte van de website ‘verschijnt’ elke maand op het World WideWeb (WWW) en heeft een aantal vaste rubrieken waarvan enkele de mogelijkheidtot interactie bieden. De website is zo georganiseerd dat informatie uit ‘oudereedities’ nog steeds toegankelijk blijft via een archief. Met behulp van de aanwezigezoekfunctie is zo informatie op te zoeken die reeds eerder gepubliceerd is, maar nogsteeds relevant. Er zijn vier redacteuren die de website thans vier jaar in bedrijfhebben. Na vier jaar is het aantal pagina’s die de website opbouwen enorm. Er zijnrubrieken die als het ware uit hun voegen barsten en het beheer vergt steeds meertijd. De website vertoont een thematische structuur die ook in papieren tijdschriftenterug te vinden is, de onderliggende gegevens worden echter niet geheelgestructureerd opgeslagen. Uitgekeken wordt naar een manier om het onderhoud enbeheer van de website zodanig te organiseren dat het tijdsaspect betreffende hetonderhoud drastisch zou afnemen.

Er zijn verschillende problemen die een rol spelen waardoor het tijdsaspect op ditmoment zo een cruciale rol speelt. De hoeveelheid aan gegevens die nietgestructureerd worden opgeslagen vormt geen basis voor het verminderen van hetbelang van het tijdsaspect. Verder zorgt diezelfde hoeveelheid aan gegevens vooreen overzichtsprobleem. Er is te veel informatie om daar handmatig een checklistvan bij te houden. Zo zitten er gegevens in het archief waar de redactie geen weetmeer van heeft en het actueel houden hiervan is thans afhankelijk van lezers diedaar de redactie over inseinen. De gegevens in het archief krijgen namelijk geenhoudbaarheidsdatum toegewezen. Het gaat immers niet over goederen terconsumptie, maar artikelen die handelen over bijvoorbeeld geldende wetten ofprocedures.

In het kader van mijn afstuderen zal ik de mogelijkheden bekijken welke oplossingenvoor bovengenoemde situatie een uitweg kunnen bieden. Daarbij zal de huidigesituatie van de website van Ouders Online1 als startpunt dienen.

1 http://www.ouders.nl

HOOFDSTUK 1. INLEIDING 2

1.1. Probleemstelling

Het onderwerp van mijn afstudeerproject biedt de mogelijkheid tot zowel eeninhoudelijke als een strategische doelstelling.

Inhoudelijke doelstelling

Aan de hand van een praktijkvoorbeeld nagaan hoe een DataBase ManagementSysteem kan bijdragen aan een efficiënter verloop van het onderhoud en beheer vaneen website met onderhouds- en beheerproblemen. De niet-database ondersteundeopslag van de gegevens aanwezig bij de website van Ouders Online zal in deze alspraktijkvoorbeeld dienen. Het gaat dus om het identificeren van de wijze waarop detoepassing van aspecten binnen de database technologie kan bijdragen aan hetefficiënter verloop van het onderhoud en beheer van websites. De aandacht zal zichmet name vestigen op de ondersteuning die een Hypermedia Design methodemogelijkerwijs kan bieden.

Strategische doelstelling

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

Hoofdvraag

Kan het gebruik van een Hypermedia Design methode leiden tot verhoging van deefficiëntie binnen het onderhoud en beheer van een website met onderhouds- enbeheerproblemen ?

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 terealiseren 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 eenonderhoudbare structuur van een website te komen ?


1.2. Opbouw scriptie

De globale opbouw van de scriptie ziet er als volgt uit. Ten eerste zal in hoofdstuk 2worden ingegaan op de huidige situatie van de website van Ouders Online waarintevens de sleutelwoorden onderhoud en beheer [2.5] aan bod komen. Criteria metbetrekking tot de onderhoudsaspecten zullen in hoofdstuk 3 aan bod komen.Daarna kan in hoofdstuk 4 verklaard worden wat een Hypermedia Design methodeinhoudt. De toepassing van een Hypermedia Design methode wordt binnen decontext geplaatst in hoofdstuk 5. De rol die Active Databases kunnen spelen metbetrekking tot bepaalde aspecten van een DataBase Management Systeem zullen inhoofdtsuk 6 worden besproken.

Tenslotte zal een evaluatie plaatsvinden van het voorgaande en daarop volgendgelijk de conclusie in hoofdstuk 7.

5

2. Huidige situatie Ouders Online

In dit hoofdstuk zal getracht worden antwoord te geven op subvraag 1 van deprobleemstelling (zie p. 2). Dat zal gebeuren aan de hand van een profielschets vande website van Ouders Online. Ouders Online is een voorbeeld uit de praktijk vaneen website met onderhouds- en beheerproblemen. Hierbij zal kort ingegaan wordenop achtergrond informatie zoals het ontstaan en de presentatie van de website. Deproblematiek zal wat uitgebreider besproken worden om het onderwerp van descriptie verder uit te diepen.

2.1. Het ontstaan van de website

De website Ouders Online werd in 1995 geïnitieerd door drs. H. Boeke, insamenwerking met drs. P. van Scherpenberg. Het idee is voortgekomen uitinteresse voor de mogelijkheden die het medium Internet te bieden heeft incombinatie met een eigen journalistieke achtergrond.

Thans hebben vaders een andere rol binnen het gezin dan voorheen en moedersstreven veel meer naar een carrière. Dit zijn slechts enkele ontwikkelingenbetreffende het ouderschap die hebben benadrukt dat er sprake is van een enormebehoefte aan externe (buiten het gezin) informatie op dit gebied. Gestreefd werdnaar een tijdschrift met een zakelijke uitstraling dat tevens informatief, interactief envan hoge kwaliteit zou zijn. Met die instelling is de VOF Ouders Online tot standgekomen. De VOF is samengesteld uit de twee initiatoren van de website en eenderde vennoot : TEQ2 (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 vanmedewerkers die per editie kan verschillen.

De taken van TEQ als derde vennoot zijn :

1. Technische ondersteuning : hosting, dwz onderhoud van scripts, systeemengineering.

2. Marketing : Zorgen voor naamsbekendheid, dus promoten van Ouders Online enadvertentie acquisitie tot en met de administratieve afhandeling.

Deze taken leken gecombineerd te kunnen worden, in de praktijk is denaamsbekendheid aan de redactie te danken. TEQ kon allebeide taken niet aan enheeft 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 enhandeling op zich kan nemen.

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

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 deperiode van de puberteit behandeld. Er wordt naar gestreefd elke maand eennieuwe editie uit te brengen waarvan de hoofdonderdelen worden te vinden zijn inde 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 geensprake is van financiële exploitatie van de lezers. Uit eigen onderzoek door middelvan een lezers-enquête gehouden in 1997, blijkt ondermeer dat 10 % van de lezerszich in het buitenland bevinden.

Er is sprake van een journalistieke en interactieve doelstelling. De journalistiekedoelstelling uit zich door de informatieve rubrieken die in elke editie wordengepresenteerd, waarbij de laatste ontwikkelingen op bijvoorbeeld cultureel ofwettelijk gebied worden gesignaleerd.

Door de mogelijkheid te bieden van informatie-uitwisseling die mogelijk totdiscussies 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 implementatiedetails en richt zich op de inhoud en structurering van de website. Een ontwerp vande presentatie daarentegen beschouwt de gebruikte implementatie taal, degroepering in pagina' s en de feitelijke ‘uitstraling’ van de website. Dit onderscheidtussen een conceptueel ontwerp en een ontwerp van de presentatie wordt in [1]gemaakt. Op grond hiervan zal in deze paragraaf worden ingegaan op depresentatie van de website. Voor teksten op papier kunnen doorgaans vier soortenstructuren worden gehanteerd [2] : chronologisch, geografisch, thematisch enmethodisch. Dezelfde structuur principes kunnen ook op websites wordentoegepast, zoals in [2] wordt beschreven. Een beschrijving van de presentatie vande website zal hierop gebaseerd zijn.


De gebruikte implementatie taal is de huidige standaard HTML3. Er is een framesversie beschikbaar van de pagina’s die de rubriek Forum opbouwen, de andererubrieken (zie paragraaf 2.3) hebben deze optie niet. Tevens worden de ingezondenberichten, bedoeld voor het Forum automatisch geplaatst en een keer per daghandmatig gescreend voor berichten die buiten de orde zijn.

De groepering van de pagina’s en de uitstraling van de website wordt tot standgebracht door de redactionele formule die wordt gehanteerd. Die vindt namelijk zijnweerslag op de vormgeving van de website. De website heeft een logische structuurdie de plaatsing van gegevens min of meer dwingend oplegt.

De website is in principe thematisch opgebouwd. Dat wil zeggen dat er een indelingnaar rubrieken is die van dezelfde orde zijn, onafhankelijk van elkaar en hetzelfdegewicht hebben. Hoewel ook gesproken kan worden van een methodischgestructureerde website, omdat er een thematische structuur met vaste thema’saanwezig is, is dat niet voor de volle 100 % terecht. Er zijn in elke editie welterugkerende elementen, maar door gebrek aan ruimte worden er vaak keuzesgemaakt die leiden tot enkele verplichte items en de resterende losse items. Tochkan 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 Forumis de enige rubriek waar enige chronologie in zit. Binnen alle rubrieken wordtgestreefd naar een zo plat mogelijke hierarchie om te voorkomen dat de gebruikersgedesoriënteerd raken en om het aantal muiskliks te beperken.

Het principe van het beperken van het aantal items staat bekend als Miller’s Law onthe 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 kortetermijn 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 vastte houden aan Miller’s Law. Bovendien kan de vormgeving eronder leiden.

3 HyperText Markup Language.


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. Zeworden samengevat onder de volgende noemers :

� Redundantie

� Inconsistentie

� Onvolledigheid

� Actualiteit

De nadruk ligt duidelijk bij gegevens, terwijl er sprake kan zijn van meer onderhouds-en ook beheerproblemen van een website. Voordat gekeken kan worden naar deproblemen, zou eerst een beschrijving van de handelingen die leiden totbovengenoemde problemen op zijn plaats zijn.

Onder het onderhoud en beheer van een website vallen de handelingen die verrichtmoeten worden om de website in zijn geheel te kunnen presenteren. Enkele van ditsoort werkzaamheden zijn :

1. Het vergaren van informatie die relevant is voor de website.

2. Het daadwerkelijk verwerken van de informatie in de reeds bestaande structuurvan de website.

3. Het actueel en consistent houden van zowel reeds bestaande informatie, als devormgeving.

4. Het afhandelen van elektronische post (email) ten behoeve van de website, ditomvat tevens de interne afhandeling van email binnen de organisatie.

5. Het bepalen van kwaliteitscriteria waaraan de website moet voldoen binnen degestelde 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.

9. Uitvoeren van een zelfanalyse, bijvoorbeeld een SWOT4 analyse terondersteuning van de beleidsvoering.

Sommige van deze handelingen vinden dagelijks plaats, andere minder frequent. Deonderhouds- en beheerwerkzaamheden die bij Ouders Online worden verrichtkunnen aan de hand van deze lijst nader worden gespecificeerd.

Het afhandelen van email (4) bestaat bijvoorbeeld uit :

4 Strenghts Weaknesses Opportunities Treaths.


� 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,het maatschappelijk middenveld5, medewerkers en vrijwilligers, kortom met eennetwerk 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 overen weer van de redactie en de medewerkers, de experts en taalkundigen (ditvalt 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 optot 7 à 8 ton, waarbij meer geneigd wordt naar 8 ton wanneer de betaling (hetloon) van de medewerkers ook wordt beschouwd/meegerekend. Zoals desituatie 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 interviewsmaakt, of CD’s voor iemand die programma’s becommentarieert.

� Onderdeel (9) kan goed dienst doen bij het werven van sponsors entoekomstige aandeelhouders.

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

2.6. Problematiek

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

5 Organisaties voor jeugdzorg, kraamzorg etc.


2.6.1. Inconsistentie,onvolledigheid en actualiteit

Doordat het aantal pagina’s van de website steeds toeneemt, ontstaat eenoverzichts probleem ten opzichte van verouderde informatie die zich in het archief ofde leeszaal bevindt. Informatie raakt verouderd wanneer die niet meer juist is doorveranderingen die zich thans hebben afgespeeld (bijvoorbeeld wetten die zijnaangepast). In de praktijk leent zich daar de volgende oplossing voor, namelijk : debezoekers van de website laten aangeven wanneer er informatie aangetroffen is dieniet meer correct is.

Er heeft zich een soort van online-gemeenschap gevormd. Een online-gemeenschapkan zich het best beschrijven door het feit dat subgroepen gevormd worden doormensen die affiniteit voelen of ervaren ten opzichte van elkaar. Zo hebben zichsubgroepen gevormd door ouders van Grote Gezinnen of Een-ouder gezinnen. Doorgedeelde interesse in sociale aspecten worden ook chat groepen opgericht. Deonline-gemeenschap suggereert een zekere betrokkenheid van de lezers bij dewebsite waardoor ze zich verbonden voelen en er zo sneller toe overgaan om deredactie erop attent te maken wanneer informatie wordt aangetroffen die niet meeractueel is.

Op deze manier wordt vertrouwd op de lezers door de verbondenheid die zij voelenmet de website. Voor de website komt dit neer op een oplossing voor hetinconsistentie-,onvolledigheid- en actualiteitsprobleem.

In het voorgaande is in het rijtje van bovengenoemde problemen redundantie ookgenoemd. Hoewel redundantie binnen de sfeer van informatiesystemen over hetalgemeen als negatief wordt ervaren, hoeft dat met betrekking tot websites nietpersé het geval te zijn. Denk bijvoorbeeld aan de overzichtelijkheid van een paginavan een website. Eenmaal een paar pagina’s verder dan de hoofdpagina is degebruiker het overzicht al snel kwijt. Op dit punt is een korte weergave aan het eindvan elke pagina, weliswaar redundant, maar welkom. Redundantie is dus nietnoodzakelijkerwijs een presentatieprobleem, maar eerder een probleem van deopslag van gegevens.

2.6.2. Gegevensopslag

De gebruikersvriendelijkheid en populariteit van de website leiden tot enorm veelforumberichten, waardoor de overzichtslijst te lang wordt. Het moment vanverplaatsing 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 deenorme hoeveelheid aan informatie de website traag.

Hoewel (een deel van) de data dus gestructureerd wordt opgeslagen in eendatabase, blijft de response tijd onder de maat. Het vergroten van de bandbreedtevan de webserver biedt slechts een tijdelijke oplossing. Dit vormt een probleem vangegevensopslag. Vooral op de lange termijn gezien, is de website ‘uit zijn voegen’aan het groeien door de enorme hoeveelheid aan gegevensverkeer.


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 opvrijwillige 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 zichdoordat er sociale ontmoetingspunten worden gecreëerd in plaats vaninhoudelijke discussies. Dit is tegen het beleid dat gevoerd wordt door deredactie. Enig afschrikbeleid dat gevoerd is werkt averechts : het toepassen vancynisme komt niet over en de lezers reageren enthousiast.

� Het profiel van de doelgroep is aan het veranderen. Aanvankelijk ging het omhoger opgeleiden van gemiddeld HBO/WO niveau, thans is dat sterk aan hetverbreden.(Deze informatie is verzameld door toedoen van het houden van eenlezersenquete 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 veelemailberichten, waardoor de overzichtslijst te lang wordt. Het moment vanverplaatsing naar het archief was vroeger een maand, later 2 weken, nu 8dagen. De website wordt erg traag door de hoeveelheid aan informatie.

� De financiering van het geheel. Na vier jaar waarin de vennoten zelf de kostendekten, zijn er thans sponsors in zicht die voor een financiële doorbraak zoudenkunnen zorgen.

� De bedrijfsvorm VOF is niet handig, het zal geprofessionaliseerd moeten wordendoor bijvoorbeeld een BV. Een BV biedt een platform om te investeren, een VOFkan geen aandelen uitzetten.

In hoofdstuk 3 zal nader worden ingegaan op aspecten van de thans geschetsteproblematiek welke in het kader van de scriptie relevant zijn. Daarbij zal wordeningegaan op het efficiënt onderhoud en beheer van een website.

13

3. Eff iciënt onderhou d en beheer

Het onderhoud van websites beslaat veel meer en beschouwt ook andere aspectendan bij conventionele software informatiesystemen. Met de ontwikkeling vanwebsites gaan namelijk ook cognitieve en esthetische aspecten gepaard [5, 10].

In de volgende twee paragrafen zullen eerst de inefficiëntie aspecten aan bodkomen. Tevens zal besproken worden welke criteria gelden wanneer het overefficiënt onderhoud en beheer6 gaat.

3.1. Inefficiëntie bronnen

Bij het beschouwen van efficiënt onderhoud en beheer van een website is hethandig eerst de bron(nen) van inefficiëntie te identificeren. Dit is mogelijk door dezeuit de problematiek te lichten waarin ze verscholen liggen. Voor de website vanOuders Online (zie hoofdstuk 2) zijn de volgende bronnen van inefficiëntie teonderkennen :

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

HOOFDSTUK 3. EFFICIËNT ONDERHOUD EN BEHEER 14

In een organisatie is er altijd sprake van een besturing van de organisatie. (Hiermeegaan beleid en besluitvorming gepaard.) Besturing kan plaatsvinden op drie niveaus: strategische, tactische en operationele besturing. Op elk niveau doet zich debesturingscyclus Plannen-Uitvoeren-Controle voor [21, p. 22-25]. Twee van degenoemde bronnen van inefficiëntie, namelijk die met betrekking tot het karakter vande website en de organisatie erachter ( C en D), bevinden zich op het strategischeen tactische besturingsniveau. Dit valt buiten het bereik van de scriptie en verder zalhier geen aandacht aan worden besteed.

Inefficiëntie bronnen A en B echter, zijn onderhouds aspecten die verbeterd zoudenkunnen worden.

De bronnen van inefficiëntie, betrekking hebbend op de gegevens en de presentatievan de website (A en B), zouden geëlimineerd kunnen worden door een migratienaar een DBMS-ondersteunde website te overwegen. Dit zou bereikt kunnenworden door een herstructurering van de website door middel van het toepassenvan een hypermedia design methode. In het volgende hoofdstuk wordt daaropingegaan, namelijk een methode om een website op een gestructureerde manier opte zetten.

3.2. Onderhouds- en beheer-criteria

Onderhoud aan een website kan gezien worden als een verzameling van activiteitenen/of handelingen die uitgevoerd moeten worden om het beleid van de organisatietot uitvoering te brengen. In [21, p. 24] wordt beleid als volgt gedefinieerd : ‘Dewegen waarlangs en de middelen waarmee een organisatie haar doeleinden trachtte realiseren.' Het gaat in wezen dus om het halen van de doelstelling die tengrondslag ligt aan de website. Onderhoud zou derhalve gerekend kunnen worden totoperationeel beleid : ‘operationeel beleid heeft betrekking op de activiteiten die op dewerkvloer plaatsvinden.’

In paragraaf 2.5 zijn reeds enkele voorbeelden genoemd die betrekking hebben ophet onderhoud aan een website. De verzameling van activiteiten die tot hetonderhoud 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 vantoepassing kunnen zijn, omdat een website beschouwd kan worden als eeninformatiesysteem.


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

Adaptief onderhoud is onderhoud dat vereist is omdat er veranderingen hebbenplaatsgevonden in de omgeving van het systeem (evolutie van het systeem). Eengoed voorbeeld hiervan is onderhoud dat plaatsvindt in verband met technologischeontwikkelingen. Dit soort onderhoud is sterk afhankelijk van de laatstetechnologische ontwikkelingen. Er gaat meestal een grote investering mee gepaard.Het overstappen naar en/of het integreren met een nieuwe manier van werken kanniet licht opgevat worden en vergt beslissingen op beleidsniveau. De beslissing omover te stappen op iets nieuws zal altijd wel een of andere migratie inhouden. Eenconcreet voorbeeld van adaptief onderhoud is de migratie van een ‘gewoon netwerk’naar een intranet.

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

Beheer aan een website suggereert niet alleen het verrichten van onderhoud op dewerkvloer, maar tevens de beslissingen die op het beleidsniveau van de organisatiegenomen (moeten) worden. Het beheer van een website omvat dus onder meer hetonderhoud aan de website. In deze scriptie worden de termen onderhoud en beheersteeds afwisselend gebruikt maar er wordt hetzelfde mee bedoeld.

Met efficiënt (‘doing things right’) [21, p. 45] wordt bedoeld de relatie tussen deverkregen resultaten en de opgeofferde middelen. Toegepast op onderhoud enbeheer betekent dat, dat het onderhoud en beheer minimaal moet worden gehoudenzowel qua manuren als bestede uren omgezet in geld (ervan afgezien of het doelwaarvoor het gebeurt wel juist is). Bovendien moet het eenvoudig uit te voerenblijven. (Dit verschilt enigszins met ‘doing the right things’ : effectief onderhoud enbeheer.) Er zit dus een tijdsaspect verbonden aan efficiënt onderhoud. Daarbij wordter van uitgegaan dat het effectieve aspect van het onderhoud en beheer impliciet tengrondslag ligt aan het nastreven van de doelstelling van de organisatie.


Om eff iciënt ond erhoud en beheer van de website te bewerkstelligen zullen deouderhoudswerkzaamheden zodanig verricht moeten worden dat er een duidelijkmerkbare vermindering in bestede uren is. Tevens mag er geen sprake zijn vancomplexere taken. Het onderhoud dient zich te beperken tot het perfectiefonderhoud dat bovengenoemd is. Deze drie criteria kunnen gerealiseerd wordendoor het verhelpen van de inefficiëntie bronnen A en B. Als de data van de websiteop een gestructureerde manier zou worden opgeslagen in een database kunnen deproblemen van inconsistentie, onvolledigheid en opslag verholpen worden. Hetactualiteitsprobleem zou mogelijkerwijs verholpen kunnen worden door gebruik vaneen active database (in hoofdstuk 6 wordt deze mogelijkheid besproken).

Een hypermedia design methode houdt ook rekening met de presentatie van dewebsite. De lange overzichtslijsten en cognitieve aspecten zouden met het gebruikvan een hypermedia design methode aangepakt kunnen worden.

De website dient dus zodanig gestructureerd te worden opgezet dat enkeleonderhoudswerkzaamheden geautomatiseerd kunnen plaatsvinden. Ondersteuningvan een DataBase Management Systeem zou dit kunnen bewerkstelligen. Defunctionaliteit van een DBMS zit verscholen in de opslaglaag van een gestructureerdopgezette website (Figuur 10 (c), p. 43). In hoofdstuk 4 worden enkele hypermediadesign methoden en engines besproken omdat die zo een DBMS in de opslaglaaghebben zitten.

17

4. Hypermedia Design Methode

In dit hoofdstuk zal worden ingegaan op wat een Hypermedia Design Methode is enwelke op dit moment betekenis hebben binnen de toepassingswereld7. Een methodezal uitgebreid worden beschreven, teneinde een beter beeld te krijgen vanhypermedia.

4.1. Hypermedia hype

Hypermedia is hypertext met multimedia. Hypertext (niet-lineaire tekst) kangezien worden als een wijze van informatiebeheer alwaar data wordt opgeslagen ineen 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 vanhypertext is het concept van machine-ondersteunde links, waardoor een niet-lineaireorganisatie van tekst mogelijk is.

Een hypermedia toepassing is een toepassing waarbij gebruik is gemaakt vanhypermedia. De reeks van hypermedia toepassingen is niet gelijksoortig, er zijnelektronische boeken, product catalogi en presentaties, leren en oefenen m.b.v.multimedia software, website ontwikkeling etc. Het meest opvallende aanhypermedia toepassingen is de multimediale representatie van informatie enobjecten. Verder worden hypermedia toepassingen gekarakteriseerd door specialeelementen en structuren. Bijvoorbeeld kan een presentatie van informatie zodanigzijn, dat de stroom van wat kan gebeuren of wordt gepresenteerd vergeleken kanworden met een filmscript (denk bijvoorbeeld aan guided tours).

Hypermedia Design is het ontwerpen van hypermedia toepassingen. Eenhypermedia design methode is een proces dat gevolgd kan worden om te komentot het ontwerp. Zo een ontwerp kan geïmplementeerd worden door gebruik temaken van de ondersteuning van een hypermedia engine. Een hypermedia engine(website ontwikkelomgeving) is een abstracte machine die via een interface toegangbiedt 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 hetontwerp dat voortgekomen is uit de hypermedia design methode.

Het ontwerp en de ontwikkeling van hypermedia toepassingen bestaat uitverschillende activiteiten op opslag-, toepassings- en presentatie-niveau. Bij eenproject ter ontwikkeling van een hypermedia toepassing zouden allerlei vakmensenbetrokken kunnen worden : grafische ontwerpers, schrijvers, bibliothecarissen,musici, evenals programmeurs, systeem analisten en gebruikers. Een hypermediatoepassing vergt de beschouwing van esthetische en cognitieve aspecten. Binneneen traditionele software ontwikkelomgeving zijn die aspecten irrelevant. Er is dusbehoefte aan speciale methodologiën en tools om het ontwerp en de ontwikkelingvan hypermedia toepassingen te ondersteunen [13].

7 Zie subvraag 3 van de probleemstelling, p. 2.

HOOFDSTUK 4. HYPERMEDIA DESIGN METHODE 18

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

4.2. Design methoden

Zoals reeds in de vorige paragraaf is aangegeven is een hypermedia designmethode een methode om hypermedia toepassingen op een gestructureerde ensystematische manier te ontwerpen. In de context van websites, wordt in [1]beargumenteerd dat het gebruik van een goede ontwikkelmethode zou kunnenbijdragen aan een oplossing van de onderhoudsproblemen die reeds genoemd zijnin paragraaf 2.5 : redundantie, inconsistentie, onvolledigheid en actualiteit. In [10]wordt verder uitgelegd hoe een gestructureerde aanpak bijdraagt aan het begrip datmensen zich van de inhoud van een website vormen (het zogeheten ‘mentalemodel’).

Er is nog geen formeel model waaraan hypermedia design methoden geëvalueerdzouden kunnen worden [5]. Hierdoor is het niet mogelijk op een eenduidige maniervast te stellen of er sprake is van een adequaat ontwerpproces van hypermediadesign methoden. Dit betekent dat er ook geen mechanisme is ter verbetering vanbovengenoemd ontwerpproces. Teneinde de design methoden op een structurelemanier te kunnen beschrijven, zal gebruik worden gemaakt van het raamwerk dat in[8] wordt genoemd. In dit raamwerk kunnen verschillende aspecten van eeninformatiesysteem ontwikkelmethode gevangen worden. Figuur 1 geeft hier eenvoorstelling van. Dezelfde algemene structuur zal gehanteerd worden voor hetbeschrijven van de bestaande hypermedia design methoden in de volgendeparagraaf.

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 eenmethode beschreven.

� De way of controlling bevindt zich op het bestuursniveau. Hier zijn aspecten diebetrekking 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, debetreffende regels en de onderlinge relaties en ook de representaties van dezeconcepten.

� In de way of working (proces georiënteerd) wordt de strategie bepaald waarmeeeen informatiesysteem ontwikkeld zal worden. Dit bestaat uit de identificatie vanrelevante taken van het ontwikkelproces en de volgorde van de taken.

� De way of supporting wordt gedefinieerd als een verzameling van tools. Toolsvormen middelen ter ondersteuning van de uitvoering vansysteemontwikkeltaken.

De way of modeling en de way of working bevinden zich op operationeel niveau.


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 vanmethoden en niet een methodologie. Een methode [16, p. 18] is een gedisciplineerdproces dat gevolgd kan worden om een verzameling van modellen te genereren.Deze modellen beschrijven aan de hand van een wel-gedefinieerde notatie deverschillende aspecten van het te ontwikkelen software systeem.

Een methodologie [16, p. 18] is een verzameling van methoden die toegepast zijntijdens 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 tebeschouwen : (1) Top-Down gestructureerd ontwerp, (2) Data-driven ontwerp en (3)Object-georiënteerd ontwerp. Bij het Top-Down gestructureerd ontwerp wordt eenalgoritmische decompositie gebruikt om een groot probleem op te splitsen in kleineredelen. 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 Top-Down view besproken worden. Naast een Top-Down view kan er ook sprake zijn vaneen Bottom-Up view.

way ofthinking

way ofmodel ing

way ofworking

way ofsupport ing

way of controll ing

product oriented process oriented

managerial

operational


Vanuit de Top-Down view wordt dus eerst een grove formulering bepaald (op eenhoog abstractie niveau) en dat wordt verder verfijnd tot een mogelijk gedetailleerdniveau. Bij de Bottom-Up view wordt gewerkt vanuit een gedetailleerd niveau endoor middel van samenstellingen wordt een algemene formulering verkregen(meestal een concrete aanpak of ad hoc tool). De genoemde views hoeven nietnoodzakelijk complementair te zijn. In de volgende paragrafen zal getracht wordenaan 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 hypermediadesign methoden en bestaande hypermedia engines. De methoden die wordengenoemd zijn HyDev, OOHDM en RMM. In de volgende summiere beschrijving is deway of controlling niet van toepassing (het bevindt zich namelijk op hetbestuursniveau).

HyDev :

De way of thinking

HyDev staat voor HYpermedia DEVelopment en past een modelgerichte aanpak toeom hypermedia toepassingen te ontwerpen [9]. In vergelijking met de ontwerpcyclusbij conventionele software ontwikkeling vindt ook bij het ontwerpen van hypermediatoepassingen een requirements analyse plaats. Deze concentreert zich echter meerop de inhoud en kwaliteit van de presentatie.

De idee achter HyDev is dat een hypermedia toepassing gebaseerd is op eenverzameling van objecten met mogelijk complexe relaties onderling [9].

De way of modeling

Het ontwikkeltraject bestaat uit verschillende fasen, waarbij de nadruk ligt bij deanalyse en het ontwerp, de eerste fasen van het ontwikkeltraject.

Tijdens de analyse en ontwerp fasen worden er drie modellen gemaakt om destructuur, de inhoud en de presentatie van een website te beschrijven : het domeinmodel, het instantie model en het representatie model [9].

Het domein model wordt grafisch gerepresenteerd en gebruikt verschillende klassenwaaronder ook de speciale N-classes (klassen van narrative structuring units), S-classes (klassen van objecten met een spatial dimension) en A-classes (klassen vanagents). De notatie is in UML (Unified Modeling Language).

Het instantie model wordt opgebouwd uit instanties van de klassen uit het domeinmodel en geïnstantieerde relaties. Ook het instantie model wordt grafischweergegeven. De instanties worden weergegeven als knopen en de lijnen ertussenvormen de relaties tussen de instanties. Niet alle in het instantie modelvoorkomende objecten hoeven te corresponderen met een klasse uit het domeinmodel.


Het representatie model bevat aspecten die te maken hebben met de presentatievan objecten en de gebruikers interactie. De input is afkomstig van de twee vorigemodellen. Het gaat daarbij vooral om de attributen van een object (welke en hoe) dieaan de gebuiker wordt getoond. Enerzijds wordt grondig gespecificeerd welke mediaobject 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 doorbijvoorbeeld niet zodanig in detail te treden over het formaat van de data files of hunconcrete namen.

De resterende fasen van HyDev zijn de Specification & Design fase en deImplementation fase.

OOHDM :

De way of thinking

OOHDM (Object Oriented Hypermedia Design Method [14]) is een uitbreiding vanHDM, de Hypermedia Design Model. OOHDM past een modelgerichte aanpak vanhypermedia toepassingen toe die varieert tussen een iteratieve, incrementele enprototype-gebaseerde manier van ontwikkeling.

In OOHDM worden hypermedia toepassingen vanuit een object georiënteerdperspectief benaderd. Daarbij wordt een hypermedia toepassing gezien als eennavigatie 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 hettoepassingsdomein. Het model bestaat uit een klassen- en instantie-schema datopgebouwd is uit attributen, subsystemen en relaties. De toekomstige gebruikersen/of taken van de toepassing worden niet beschouwd, alleen de semantiekbetreffende het toepassingsdomein.

De navigational design fase [14] kan verschillende navigatie modellen opleveren. Elknavigatie model drukt een navigatie view uit. Een navigatie view wordt vanuit hetgezichtspunt van de typen van toekomstige gebruikers (en hun handelingen)gemaakt. Omdat er meestal verschillende typen (toekomstige) gebruikers teonderkennen zijn, is er sprake van verschillende navigatie views (dit op één enhetzelfde conceptuele domein), en zo dus ook verschillende navigatie modellen. Denavigatie structuur van een hypermedia toepassing wordt gedefinieerd in termen vanhet navigatie verband dat afgeleid wordt uit de navigatie klassen Nodes, Links,Indices en Guided Tours. De navigatie klassen reflecteren de gekozen view op hettoepassingsdomein en hun definitie bouwt de navigatiestructuur op. In [14] wordtverder ingegaan op genoemde navigatie klassen.


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 degebruiker, welke interface objecten de gebruiker zal waarnemen en hoe navigatiemogelijk is. Ook synchronisatie aspecten worden beschouwd. Om het concept van‘verschillende interfaces voor hetzelfde navigatie model’ te ondersteunen wordt indeze fase een strikte scheiding gehanteerd tussen navigatie aspecten en abstractinterface design aspecten. Er worden ADV’s (Abstract Data Views) gebruikt om deuser interface te beschrijven.

Door in de implementation fase [14] de navigatie modellen en de abstracte interfacemodellen af te beelden op objecten uit de implementatie omgeving, wordt eenfeitelijke hypermedia toepassing operationeel gemaakt.

RMM :

De way of thinking

RMM is de afkorting van Relationship Management Methodology, afgeleid van devisie dat het managen van de relaties tussen informatie objecten essentieel is bijhypermedia. In principe is het een lineaire methode maar het is ook mogelijk omtijdens het ontwerpproces feedback loops, klonen en prototyping te verkrijgen omeen combinatie van een Top-Down en Bottom-Up aanpak te bewerkstelligen [13].

De basis van RMM wordt gevormd door RMDM, Relationship Management DataModel, een modelleringstechniek ter beschrijving van de informatie objecten ennavigatie mechanismen van een hypermedia toepassing. Het behoort tot decategorie 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 belangrijkstezijn : ER Design, Slice Design en Navigational Design [13].

De ER Design fase is te vergelijken met de conceptual design fase in OOHDM, methet verschil dat hier gebruik wordt gemaakt van ER in plaats van OO. Deze faselevert 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 eendeelverzameling (groepering) van de attributen van een entiteit. In een slice diagramworden slices en de tussenliggende links gedefinieerd, waardoor er een soort‘verrijkt’ ER diagram ontstaat met entiteiten, relaties en slices. De informatie wordtals het ware gegroepeerd in de slices.

In de Navigational Design fase worden de relaties tussen de entiteiten uit het ERdiagram toegankelijk gemaakt voor navigatie. Alle navigatie paden worden afgeleidvan de relaties die tussen de entiteiten bestaan en worden weergegeven in termenvan entiteits-eigenschappen en relaties.


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

Samenvattend

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

Tabel 1 : Verschillende fasen genoemde hypermedia design methoden

De fasen die zich op dezelfde rijhoogte bevinden komen enigszins met elkaarovereen. Het gaat dan voornamelijk om dezelfde activiteiten die plaatsvinden.Ondanks het feit dat geen van bovengenoemde ontwikkelmethoden een formelespecificatietaal gebruikt ter definiëring van de syntax en semantiek, is gebruikgemaakt van een algemeen raamwerk (zie Figuur 1) waarin de ontwikkelmethodenop informele wijze beschreven konden worden.

De HyDev methode zou waarschijnlijk een ontwerp van een website kunnenopleveren, maar de daadwerkelijke implementatie van het ontwerp wordt nietbesproken in de literatuur. Er is geen beschrijving van de stap van ontwerp naarcomplete website. De way of working is dus afwezig. De mate van abstractie diewordt aangehouden lijkt willekeurig.

Zowel RMM als OOHDM blijken het meest geschikt voor toepassingen met uniformgestructureerde data zoals bijvoorbeeld product catalogi [9]. Complexerehypermedia toepassingen zoals ingenieuze games zullen betere specificatietechnieken nodig hebben [9].

1. Conceptual Design

2. Navigat ional Design

2. Sl ice Design

3. Navigat ional Design

3. Abstract Interface Design

1. ER Design

4. Conversion ProtocolDes ign

6. Runt ime Behavior Design

7. Implementat ion

5. User- Interface Design

4. Implementat ion

HyDev OOHDM RMM

1. Analysis

2. Speci f icat ion & Design

3. Implementat ion


Zowel Hydev, OOHDM als RMM hebben ondanks de afwezigheid van een formelebasis, een specifieke betekenis binnen hun eigen context. Hoewel RMM veelgebruikt wordt voor web ontwikkelingen, wordt RMM gedefinieerd als een proces datimpliciet onderdeel van een ontwikkelmethodologie is en daardoor wordt het procesniet beschreven in de context van een complete life-cycle, nog worden activiteitenanders dan design & implementation beschouwd. Net zo is OOHDM gelijk aan RMMin 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 zijnpage editors, website editors en website ontwikkelomgevingen. Zoals reeds eerderaangegeven (zie p. 17) wordt een hypermedia engine gezien als een abstractemachine die een interface aanbiedt om hypermedia structuren te kunnenmanipuleren. Een hypermedia systeem dat ontwikkeld is met behulp van eenhypermedia 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 eenDBMS (DataBase Management Systeem), zie Figuur 10 (c).

De bestaande systemen die in [4] genoemd worden behoren tot de klasse vanwebsite ontwikkelomgevingen :

� WebComposition

WebComposition is gebaseerd op een object georiënteerd webmodel, waarineen website als een hiërarchie van componenten wordt gepresenteerd. Er is noggeen gestructureerde aanpak ontwikkeld voor het maken van een componentenmodel. Er is dus ook geen specifieke design methode die gekoppeld kan wordenaan deze hypermedia engine. Er zijn twee soorten van componenten :primitieven (laagste niveau van de hiërarchie) en composities. Elke componentheeft een toestand en gedrag. Hoewel WebComposition gebaseerd is op eenobject georiënteerd webmodel, maakt het gebruik van een onderliggenderelationele database [4].

� OOHDM web

OOHDM web maakt rapid prototyping van hypermedia toepassingen (ontworpenmet behulp van OOHDM) mogelijk. De laatste drie fasen8 van de OOHDMmethode worden hier ondersteund. De realisatie van het systeem komt tot standdoor 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.


basis gezien voor de software ontwikkel tool RMCase. RMCase is eenontwikkelomgeving die gebaseerd is op RMM en is niet incrementeel. Hetondersteunt de bouw van een hypermedia toepassing. De ondersteuning vanhet cognitieve ontwerpproces wordt verkregen door drie vooronderstellingen diede basis van RMCase vormen [13] : (1) wisselende feedback loops tussen deverschillende fasen van de methode. (2) manipulatie van objecten op instantieniveau. (3) lichtgewicht prototypering.

RMCase ondersteunt Top-Down, Bottom-Up en Middle-Out software ontwerpstijlen door de manier waarop RMCase zelf in elkaar zit. Het is namelijkontworpen als een hypermedia toepassing met navigatie aspecten die feedbackloops implementeert. Het is in principe platform onafhankelijk en de mogelijkheidbestaat 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 enhergebruik. Het is gebouwd als een extensie van het OODBMS Vodak.Geprobeerd wordt de nadelen uit eerder verschenen hypermedia engines teverwijderen, het gaat om aspecten zoals de uitbreidbaarheid van het model ofde ondersteuning van het modelleringsproces. Er blijven enkele nadelen aandeze engine vastzitten, zoals het feit dat voor elke nieuwe website nieuwespeciale relaties gedefinieerd moeten worden [4].

Teneinde meer inzicht te verkrijgen in de werking van een hypermediaontwerpmethode 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 applicatiewebsites.

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

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


WSDM is thans bedoeld voor kiosk websites. De essentie van de aanpak van deWSDM is het feit dat het user-centered in plaats van data-driven is. Bij een user-centered aanpak is het startpunt van de methode de verwachte gebruikers vande website. De aspecten die aan de user-centered aanpak zijn gerelateerd lopen alseen rode draad door de WSDM. Bij een data-driven aanpak daarentegen, is de datadie aanwezig is in de organisatie het startpunt van de modellerings aanpak : eerstwordt het applicatie domein gemodelleerd en daarna wordt informatie geassocieerdmet elke klasse van gebruikers (bijvoorbeeld door middel van views of externeschema’s). Echter zou de data en de manier waarop het georganiseerd is in hettoepassingsdomein de gebruikersbehoeften (requirements) niet te hoevenweergeven. Dit kan leiden tot een verkeerde combinatie van informatierepresentatie.

Let op dat de zojuist beschreven user-centered aanpak verschilt van een user-drivenaanpak. Een user-driven aanpak wordt tijdens het ontwerpproces grotendeelsbegeleid door de gebruikersbehoeften. Die zijn verkregen door middel van voorafgehouden 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

Figuur 2: Overzicht van de verschillende fasen van WSDM

UserClassi f icat ion

User ClassDescr ipt ion

ObjectMode l ing

Navigat ionalDes ign

Implementat ionDes ign

Implementat ion

Conceptua l Des ign

User Model ing

Webs i te


Elke fase uit Figuur 2 levert een (aantal) model(len) op. Voorondersteld wordt dat dedoelstelling van de website vóór de start van de eerste fase geformuleerd is. Dedoelstelling dient het onderwerp en het doel van de website én de te verwachtengebruikers 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 conceptueleontwerp is, net als in database ontwerp, vrij van implementatie details en gericht opde inhoud en structurering van de website. Het ontwerp van de feitelijke presentatiebeschouwt de implementatie taal, het groeperen in pagina’s en de eigenlijke‘uitstraling’ van de website (vergelijk met de eerste fasen van HyDev : analyse enontwerp, 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 databasesysteem worden onderkend, behoren de vier fasen van de WSDM ook totverschillende niveaus. In [12] wordt gesproken van drie niveaus van abstractie : defysieke database, de conceptuele database (abstractie van de wereld die betrekkingheeft op een organisatie) en de views of subschema’s (abstract model van een deelvan de conceptuele database).

In die context kan de eerste fase van WSDM, de User Modeling fase beschouwdworden als de fase waarin verschillende external views tot stand komen. Dezeexternal views beschrijven op informele wijze de manier waarop tegen de(aanstaande) website kan worden aangekeken. In een later stadium (paragraaf4.3.2) worden deze views samengebracht tot een conceptueel model. Dan kangesproken worden van external view integration. Figuur 3 geeft hier een grafischerepresentatie van.

Figuur 3 : Overzicht van external views

External v iew External v iew

Conceptuee lmode l

Internerepresentat ie


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

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

Typische gebruikers van deze website zijn (toekomstige) studenten, onderzoekersen universiteits medewerkers. Allen hebben verschillende behoeften :

� De toekomstige student is bijvoorbeeld op zoek naar algemene en curriculuminformatie.

� De ingeschreven student is op zoek naar gedetailleerde informatie zoalsbijvoorbeeld vakkenroosters.

� De onderzoekers en medewerkers van de universiteit zijn op zoek naaronderzoeks projecten, publicaties e.d.

In de hierna volgende paragrafen worden de vier hoofdfasen van de WSDMbeschreven.

4.3.1. User Modeling fase

De way of modeling

De User Modeling fase bestaat uit twee subfasen : User Classification en User ClassDescription.

In de User Classification subfase worden de toekomstige gebruikers van dewebsite door middel van een informele beschrijving geïdentificeerd engeklassificeerd in user classes. De doelstelling van de website zal een indicatiegeven van de te verwachten gebruikers, maar dit moet verder gedefinieerd worden.In een user class wordt de informatiebehoefte van de toekomstige gebruikersgedefinieerd. Een user class kan gezien worden als een beschrijving van een subset(echt álle toekomstige gebruikers onderkennen is onmogelijk, vandaar dat hiergesproken wordt van een subset) van alle toekomstige gebruikers. Elke subsetbevat toekomstige gebruikers met dezelfde informatiebehoefte.

In het volgende voorbeeld wordt het allemaal wat duidelijker.


Voorbeeld 1

De activiteiten waaruit elke organisatie bestaat geven een indicatie van debetrokken personen. In ons voorbeeld (voorbeeld 0) zijn onder andere de volgendeactiviteiten te onderscheiden : onderwijzen, onderzoeken, adviseren van bedrijven,publiceren. Identificatie van de personen die bij elke activiteit horen leidt tot de userclasses :

� Toekomstige Studenten (afgeleid van de activiteit onderwijzen).

� Ingeschreven Studenten (afgeleid van de activiteit onderwijzen).

� Onderzoekers (afgeleid van de activiteiten onderzoeken, adviseren vanbedrijven, 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.

Figuur 4 : Schema van de omgeving van de universiteit

Toekomst igestudenten

Ingeschrevenstudenten

Onderwi jzen

Medewerkers

Bedri jven

Onderzoeken

Publ iceren

Bedri jvenadviseren

Onderzoekers

user class

activiteit

afgeleide user class onderkende activiteithorende bi j de

organisatieafgeleid van

user classactiviteit afgeleide user class

onderkende activiteithorende bi j de

organisatie

Betekenis dersymbolen :


In de User Class Description subfase worden de geïdentificeerde user classesverder geanalyseerd. Een user class bevat een groep van gebruikers (bijvoorbeeldIngeschreven Studenten) met dezelfde informatiebehoefte (bijvoorbeeld informatieover roosters e.d.). Dezelfde informatiebehoefte kan echter op verschillendemanieren (bijvoorbeeld in verschillende talen, om buitenlandse studenten teonderscheiden van inheemse studenten) gepresenteerd worden. Binnen een userclass kunnen dus verschillende ‘varianten’ bestaan van dezelfdeinformatiebehoefte. Om deze varianten te kunnen onderkennen worden dekarakteristieken van alle gebruikers van een user class bepaald. Dekarakteristieken kunnen aangeven hoe bepaalde informatie gepresenteerd moetworden aan de user class. Verschillende karakteristieken in een user class duidenop verschillende bruikbaarheidsbehoeften van gebruikers (usabili ty requ irements).Om de zogeheten bruikbaarheidsbehoeften te specificeren wordt een user classverder ontleed in user subclasses : perspectives. Een perspective wordt dusgevormd door een deel van de gebruikers uit een user class met dezelfdekarakteristieken en dezelfde usability requirements.

Kortom, in een user class wordt de informatiebehoefte van een groep van gebruikersbeschreven. Een subclass van een user class, oftewel perspective, beschrijft dekarakteristieken en usability requirements van een deel van de groep gebruikers.

De verdere analyse van de user classes uit de User modeling subfase legt dus denadruk 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 hetalgemeen, taal aspecten, onderwijs/intellectuele vaardigheden, leeftijd, etc.

Voorbeeld 2

Een informele beschrijving van de user class Ingeschreven Studenten uitvoorbeeld 1 (pagina 28) zou kunnen zijn :

Ingeschreven Studenten : Deze studenten hebben behoefte aan eengedetailleerd informatiepakket waarin zaken zoals roosters, tentamendata,studiebegeleiding en universiteitsregels zijn opgenomen. De leeftijd varieert tussende 18 en 28 jaar en aangenomen mag worden dat het ervaringsniveau met hetWWW goed is. Hier kunnen twee perspectives onderscheiden worden :

� Inheemse Studenten : Deze studenten zijn op de hoogte van het leef- enwerk-klimaat op de universiteit. Ze zijn zich ook bewust van de tradities enregels die gelden (ongeschreven wetten). De voertaal is hun eigen.

� Buitenlandse Studenten : Deze studenten zullen in de meest gangbare taalmoeten communiceren (Engels) als ze de voertaal niet of nauwelijksbeheersen. Verder zullen ze minder op de hoogte zijn van regels en traditiesdie gelden.


In [15] wordt een verfijnde versie van WSDM gepresenteerd namelijk UR-WSDM(User Requirement-WSDM). In UR-WSDM worden de user classes van deUser Modeling fase gedetailleerder geanalyseerd dan in WSDM gebeurd.

In WSDM wordt aangenomen dat de perspectives van een user class onderling eenset van requirements gemeen hebben. Die worden niet expliciet gedefinieerd in eenlijst van behoeften. Dat gebeurd wel in UR-WSDM. Zo ontstaat een lijst van userrequirements waarbij elke requirement gezien kan worden als een reden om tebrowsen op de website.

Voorbeeld 3

Een analyse van de requirements van de user class Ingeschreven Studentenvolgens UR-WSDM ziet er als volgt uit :

1. Voor elke docent, geef een lijst van de vakken die hij doceert, geef voor elk vakeen korte beschrijving, de voorwaarden, de verplichte literatuur, de syllabus inelectronisch 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 invergelijking met voorbeeld 2 zijn de aspecten met betrekking tot retrieval enmanipulatie van data beter zichtbaar.

4.3.2. Conceptual Design fase

Het doel van de Conceptual Design fase is om de informatiebehoefte van de userclasses en perspectives uit de User Modeling fase formeel te beschrijven. Dezeformele beschrijving kan gebruikt worden om later automatisch of semi-automatischwebsites te genereren.

De Conceptual Design fase bestaat uit twee subfasen : Object Modeling enNavigational 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 soortvan informatie die zal worden gepresenteerd en ook hoe genavigeerd zal kunnenworden door die informatie.


4.3.2.1. Object Modeling subfase

De zojuist genoemde formele beschrijving van de informatiebehoefte van de userclasses en perspectives vindt plaats in de Object Modeling subfase. Dit gebeurt doorconceptuele object modellen, genaamd User Object Models (UOMs), te bouwenvoor de user classes.

Een UOM (User Object Model) is een model waarin de zakelijke aspecten binnen deorganisatie bezien worden vanuit het perspectief van de gebruikers in een userclass. Een user class heeft een beperkt perspectief op de organisatie. Dus zal eenUOM (User Object Model) slechts een deel van de verzameling van zakelijkeaspecten van de organisatie bezien. In tegenstelling tot object georiënteerde objectmodellen 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 (UserObject Model). Om een UOM (User Object Model) te bouwen kan een keuze wordengemaakt uit verschillende methoden die geschikt zijn voor conceptuele modellering,bijvoorbeeld de Entity Relation methode ER of de object georiënteerde methodeOMT.

Voorbeeld 4

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


Figuu r 5 : User Object Model voor ‘Ingeschreven Studenten’

Naast de UOMs (User Object Models) voor de verschillende user classes zullen ookPOMs (Perspective Object Models) gebouwd moeten worden. Een POM(Perspective Object Model) bestaat uit variaties op een perspective (door deverschillende perspectives die een user class kan hebben) en kan vergelekenworden met een subtype. De POM (Perspective Object Model) voor een gegevenperspective wordt verkregen door in het UOM (User Object Model) de user ObjectTypes te vervangen door de corresponderende perspectives (Figuur 6).Voorwaarden hierbij zijn :

� Als een user Object Type geen variaties op een perspective heeft wordt er nietsgedaan en blijft de user Object Type ongewijzigd.

� Als een user class geen verschillende perspectives heeft, heeft de User ObjectModel slechts één Perspective Object Model die gelijk is aan de User ObjectModel.

� De Object Types van een Perspective Object Model worden Perspective ObjectTypes (POTs) genoemd.

Elke POM (Perspective Object Model) zal beschreven worden als een (mogelijkcomplexe) view op een Business Object Model (BOM). Een BOM is een conceptuelebeschrijving van de aanwezige informatie van business objecten binnen deorganisatie. Voor het weergeven van de verschillende perspectives van een ObjectType wordt de ouder-kind notatie aangehouden (Figuur 6). Alle tot dusver genoemdemodellen uit de conceptual design fase worden in Figuur 7 in relatie tot elkaarweergegeven.

N a a mTitelPlaatsTelefoonE-Mai l

Da tumPlaatsTi jdDuur

IdN a a mBeschr i jv ingNieuwsgroepTentamen Soor tVerpl ichte Li teratuurProgramma Jaar

IdN a a mPrijsAanschaf Datum

Cursus Mater iaal

Cursus

Docent

Ten tamen

voor

me t

nodig

voorwaardevoor

gebruikt

gebruikt voor

geeft

schr i jver van

gegeven door

geschreven door

1+

2

1+

1+


Figuur 6 : Perspectives variaties voor het Object Type Cursus

Figuur 7 : De verschillende object modellen in relatie tot elkaar

IdNaamBeschrijvingNieuwsgroepTentamen SoortVerplichte LiteratuurProgramma Jaar

Cursus

Cursus/ Buitenlands Studenten

IdNaam/ Naam EngelsBeschrijving/ Beschrijving EngelsNieuwsgroepTentamen Soort/ Tentamen Soort EngelsVerplichte Literatuur/ Verpl. Lit. Engels

Cursus/ Inheemse Studenten

IdNaam/ Naam Ned.Beschrijving/ Beschrijving Ned.NieuwsgroepTentamen Soort/ Tentamen Soort Ned.Verplichte Literatuur/ Verpl. Lit. Ned.Programma Jaar

Toekomstigestudenten

Ingeschrevenstudenten

Onderwijzen

Medewerkers

Bedri jven

Onderzoeken

Publiceren

Bedri jvenadviseren

Onderzoekers

user class

activiteit

afgeleide user class onderkende activiteithorende bij de

organisatieafgeleid van

user classactiviteit afgeleide user class

onderkende activiteithorende bij de

organisatie

Betekenis dersymbolen :


4.3.2.2. Navigational Design subfase

In de Navigational Design subfase wordt een Conceptual Navigation Modelgemaakt. Dit conceptuele navigatie model bestaat uit een aantal navigatie paden(navigation tracks). Voor elke Perspective Object Model (POM) wordt namelijk eenapart navigatie pad gemaakt. Een navigatie pad geeft aan hoe gebruikers van eenperspective door de aanwezige informatie kunnen navigeren. Elk navigatie padbestaat uit drie lagen (zie onderstaand algoritme voor verdere uitleg):

1. De bovenste laag is de context layer, hier worden de verschillende navigatiepaden aan elkaar verbonden.

2. De middelste laag heet de navigation layer, deze laag bevat verschillendetoegangs 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 enlinks. 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 kanworden aangegeven d.m.v. links naar andere componenten.

� Navigatie component : groepering van links.

� Externe component : referentie naar een component van een andere website.

Figuur 8 : Representatie van de navigatie concepten

Voorbeeld 5

In

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

Navigat ionalcomponent

Externalcomponent

Informationcomponent

Link


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

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

Algoritme voor het construeren van een navigatie pad :

1. Bouw de context layer : Maak een navigatie component met dezelfde naam alsde perspective.

2. Bouw de information layer : Elke Perspective Object Type wordt óf eeninformatie component óf een externe component. De keuze is uiteraardafhankelijk van de aanwezige informatie.

3. Bouw de navigation layer : Voor elke Perspective Object Type wordt eennavigatie component geconstrueerd met dezelfde naam als de PerspectiveObject Type. Deze navigatie component wordt gelinked aan de context layer.

Als dezelfde informatie component op verschillende manieren toegankelijk moetzijn, worden intermediaire navigatie componenten en links gecreëerd.

Op deze manier zijn de drie lagen in

Tentamen/Bui tenlandse

student

Context Layer

Tentamens per Vak Vakken b i j Naam Vak Mater iaal Docenten b i j Naam

Vak Mater iaal per Id Vak Mater iaal per Vak

Vak/Bui tenlandsestudent

Vak Mater iaalBui tenlandse

student

Docent /Bui tenlandse

student

Perspect ive van Bui tenlandseStudenten

Navigation Layer

Information Layer


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 conceptueleontwerp uit de vorige fase (Conceptual Design) te maken. Deze fase levert eenImplementation Model op. Op het WWW zijn er vele methoden te vinden diebetrekking 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’sLaw on the Magic Number, paragraaf 2.4). Ook de download tijd moet minimaalblijven, bij hele grote stukken informatie heeft zelfs een snelle server veel tijdnodig.

Bij gebruik van de WSDM kan de bouwer van een website zelf besluiten omcomponenten die door links zijn verbonden te groeperen (clustering) en op éénpagina te representeren. Daarbij kunnen navigatie componentengeïmplementeerd worden d.m.v. (on)geordende lijsten.

� Maak gebruik van een index pagina. Dit zou een simpele versie van hetconceptuele model kunnen zijn. Een index pagina kan de gebruiker behulpzaamzijn bij het localiseren van informatie , maar ook om een mentaal plaatje van dewebsite te maken. Zo kan het lost-in-hyperspace syndroom geminimaliseerdworden.

� Gebruik inhoudelijke en informatieve leidraden en vermijd pagina’s zonderleidraad. Op deze manier heeft de gebruiker meteen door of de pagina voor hemof haar relevant is.

� Gebruik navigatie leidraden. Een website die gecreëerd is m.b.v. de WSDMconcentreert op het perspectief van de gebruiker. De pagina’s van een websitekunnen externe links en ook inter-perspectieve links (links tussen pagina’s vanverschillende navigatie paden) bevatten. Gebruik van verschillende navigatieleidraden maakt het de gebruiker makkelijk dit onderscheid op te merken.

Het implementation model wordt gecreëerd door als startpunt het navigatie modelonder handen te nemen. Door gebruikmaking van grafische ontwerp principes envisuele communicatie technieken kunnen de karakteristieken van de verschillendeperspectieven beschouwd worden. Zo kan het navigatie model vertaald worden ineen presentatie model. Dit presentatie model beschrijft dan de inhoud van depagina’s en de lay out.


4.3.4. Implementation fase

De way of supporting

De laatste fase, Implementation, is de feitelijke realisatie van de website metgebruikmaking van de gekozen implementatie omgeving, bv HTML. Hierbij zal hetimplementation model geconverteerd moeten worden naar een verzameling van filesdie HTML source code bevatten.

Verbeterd onderhoud aan een website verrichten is mogelijk door de onderliggendeinformatie of gedeelten daarvan in een database op te slaan. Pagina’s kunnen dangegenereerd worden door de informatie uit de database te halen.

De basis van het database design zit in de Business Object Model (zie paragraaf4.3.2.1). De BOM kan gezien worden als het conceptuele schema van de databaseomdat het de business objects beschrijft op een conceptueel niveau.

Van het conceptueel schema kan een logisch database schema gegenereerdworden (met gebruikmaking van de juiste database development tools) of het kanook handmatig gebouwd worden. Uit de Perspective Object Models kunnen dequeries voor de database worden afgeleid omdat Perspective Object Models wordenweergegeven als views op de Business Object Model.

Een grondige uitleg over het linken van een relationele database aan een website iste vinden in [18].

4.4. Evaluatie beschreven methode

De in paragraaf 4.2 genoemde methoden hebben enkele algemene concepten metelkaar gemeen die een belangrijke rol spelen in de huidige ontwikkelmethoden voorhypermedia. De WSDM methode heeft in tegenstelling tot eerder genoemdemethoden een totaal ander uitgangspunt, namelijk een user-centered aanpak.

WSDM begint met het identificeren van de verschillende typen toekomstigegebruikers. Daarna worden hun karakteristieken en informatiebehoefte beschreven.Pas hierna begint het conceptuele ontwerp van de website met als input de reedsgedefinieerde perspectives en de zakelijke doelstelling van de organisatie achter dewebsite (de informatie-aanbieder).

De WSDM methode beperkt zich tot kioskwebsites. De eerste twee fasen (UserModeling en Conceptual Design) van WSDM lijken de belangrijkste te zijn, zij leggenimmers de basis voor verdere implementatie. In de literatuur worden de eerste tweefasen vrij uitgebreid met voorbeelden gestaafd. Doordat echter ook deze methodegeen formele semantiek heeft, blijft het begrip over elke te ondernemen fase beperkttot de gegeven voorbeelden. Op die manier is het uiterst moeilijk de methode toe tepassen op een organisatie anders dan een universitaire omgeving. Dit onderstreeptnog eens het belang van de aanwezigheid van een formele beschrijving van eenmethode.


De implematation fase uit WSDM wordt summier beschreven en volgt geen specialewerkwijze. Hoewel er wel aandacht wordt besteed aan de presentatie van dewebsite (Implementation Design fase, paragraaf 4.3.3), is er geen specifiek platformwaarop het ontwerp ontwikkeld kan worden. Dit kan gezien worden als een grootminpunt, de implementatie van het ontwerp wordt overgelaten aan het gebruik vanwebsite editors en page editors.

Desondanks stelt de methode een logische manier van werken ten toon die ook bijde andere methoden (paragraaf 4.2) te zien is. Binnen de hypermediaontwikkelingen is er misschien nog geen sprake van een ondubbelzinnigebeschrijving en formele semantiek, het belang van de algemene richtlijnen terontwikkeling van hypermedia ligt er al (zie Tabel 1).

41

5. Toepassing hypermedia design

In het vorige hoofdstuk is uitvoerig ingegaan op wat een hypermedia designmethode is. Hoewel de ontwikkeling van hypermedia toepassingen nog steeds adhoc verloopt, heeft hypermedia design de potentie om de efficiëntie van hetonderhoud 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 hetmigratieproces zal worden besproken. Op deze manier zal getracht wordenantwoord 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 enginesbesproken. Hierbij is ingegaan op zowel de sterke als zwakke punten vangenoemde methoden. Het zou absurd zijn te beweren dat er slechts één enkelemethode bestaat die ‘ juist’ is, daarom zal in de navolgende theoretische besprekinguitgegaan worden van het concept hypermedia design methode. De uitgebreidebeschrijving van WSDM in paragraaf 4.3 biedt de mogelijkheid die methode alsleidraad te gebruiken.

Met betrekking tot de website van Ouders Online is het niet onvoorstelbaar dat eenherstructurering van de website nodig zal zijn om te komen tot efficiënter onderhouden beheer. In [19] worden enkele factoren overwogen bij de beslissing omconventionele software te herstructureren. Dergelijke criteria zijn nog niet specifiekvoor hypermedia systemen geformuleerd. Om desondanks een idee te krijgen vanwat de bedoeling is, kunnen de criteria in [19] toegepast worden op websites. Dangeldt :

1. Als een significant gedeelte van de website stabiel is en niet onderhevig aanveranderingen is een herstructurering aan te bevelen. Het is dan alleen nodigdat 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 omtijdig in te kunnen spelen op nieuwe technologiën.

3. Is de onderliggende structuur van de website niet gedocumenteerd, dan isherstructurering (op conceptueel niveau) aan te bevelen. Dit zal verbeterdemogelijkheden scheppen in verband met technologische ontwikkelingen entoekomstig 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 beteromgezet worden in het construeren van een tool die het herstructureringsproces kanondersteunen.

HOOFDSTUK 5. TOEPASSING HYPERMEDIA DESIGN 42

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

5.2. De voordelen

Hoewel het proces van de ontwikkeling van hypermedia toepassingen thans nog nietformeel gedefinieerd is, zijn er reeds voordelen te onderkennen. In [5] wordenenkele 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 deorganisatie 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 hettoepassen van een hypermedia design methode. De gestructureerde aanpak vormteen goede basis voor ondersteuning van een implementatie van het geheel dooreen website ontwikkelomgeving.

5.3. De architectuur

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


Figuur 10 : Architectuur van drie hypermedia systemen

Beschrijving van figuur 10:

In (a) wordt een hypermedia systeem gepresenteerd dat op maat gebouwd is. Dehypermedia systemen van deze architectuur waren gebaseerd op mainframes. Deknopen in zo een systeem waren hoofdzakelijk tekstueel. De presentatie had geentot weinig grafische aspecten [25].

In (b) wordt een tweede generatie hypermedia systemen gepresenteerd. Hetconcept is hetzelfde gebleven als in (a). Echter hebben de mainframes plaatsgemaakt voor workstations. Hierdoor konden de user interfaces verbeterd worden.Grafische aspecten en knopen met animatie werden mogelijk. Navigatie werdmakkelijker gemaakt door de grafische presentatie van de netwerk structuur. Helaaswaren deze systemen alleen geschikt voor kleine groepen individuen [25].

Het custom gedeelte wordt ook wel hyperindex genoemd. De hyperindex bevat derepresentatie van de karakterisatie van de documenten. De database bevat deverzameling van documenten.

In (c) is er sprake van drie lagen : de presentatielaag (Custom), de toepassingslaag(Hyperbase) en de opslaglaag (Database). De presentatielaag wordt custom madegemaakt en de interfaces zijn geavanceerder. De toepassingslaag bevat dehyperbase 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, maarook een handmatig aspect. In een vereenvoudigde situatie zou gesproken kunnenworden van een handmatig deel en een geautomatiseerd deel van het onderhoud.Het handmatige deel is van toepassing op het reeds genoemde perfectief onderhouden tevens het aansturen van het geautomatiseerde deel. Het geautomatiseerde deelvan 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 tedefiniëren. In [26] wordt een DBMS beschouwd als een geautomatiseerde tool

Hyperbase

Database

CustomCustom

Database

Custom

(a) (c)(b)


die gebruikers van het DBMS in staat stelt handelingen uit te voeren op eenefficiënte en effectieve manier. De handelingen kunnen bijvoorbeeld bestaan uit hetraadplegen van de data in de database of het onderhouden van de data. Het DBMSwerkt dus als een soort van interface tussen de gebruiker en de database. Demanier 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 metde database via een query taal.

� De DataBase Administrator (DBA), diegene die verantwoordelijk is voor onderandere de performance van het systeem. De DBA bepaalt zaken zoals deopslagstructuur, indexering en bijvoorbeeld ook het tunen van de database.

Volgens [22] is de implementatie van een OODBMS (Object Oriented DBMS) thansde beste keus voor de opslaglaag van een hypermedia systeem. Een anderemogelijkheid die onderzocht zou kunnen worden is een DBMS dat zichzelf kansturen 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 kiezenvoor een DBMS-ondersteunde website. In deze paragraaf zal het daadwerkelijkeproces beschreven worden van een migratie naar een website die door een DBMSwordt ondersteund vanuit een niet-DBMS ondersteunde situatie.

Met betrekking tot een website zijn er twee soorten van migratie te onderkennen : destructurele migratie en de concrete migratie.

Een structurele migratie is een migratie van ‘de structuurbeschrijving in de huidigesituatie’ 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 eenstructurele migratie is het de bedoeling dat de external views op de website nietveranderen in de nieuwe situatie. Dat wil zeggen dat de gebruiker niet uit depresentatie van de website zal kunnen opmaken dat de website DBMS-ondersteuning ondervindt.


Figuur 11 : De verschillende vormen van migratie

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

5.4.1. Het migratieproces

De structurele migratie is een proces dat veel eenvoudiger uit te voeren is dan deconcrete migratie. Dat komt omdat dit op het conceptuele niveau plaatsvindt. Om diereden zal daar uitgebreider op worden ingegaan dan op de concrete migratie. Destructurele 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 OudersOnline is heel erg gebruikersgericht waardoor de user-centered aanpak van WSDMdaar goed op aansluit. Verder is de website van Ouders Online te vergelijken meteen kiosk website : immers, de lezersinput uit de interactieve delen wordt naderhandtoch nog handmatig door de redactie gescreend.

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

structuurbeschri jving

DBMS ondersteuning(nieuwe situatie)

structuurbeschri jving

Geen DBMS ondersteuning(huidige situatie)

structurele migratie,zelfde external view

populatie v/d structuur populatie v/d structuur

concrete migratie,nieuwe beschri jving

migratie (*)

(*)


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 gestartworden met :

� De User Classification fase

De website van Ouders Online heeft in 1997 een lezers-enquête gehoudenwaaruit een gebruikersprofiel af te leiden valt. Hierdoor is het mogelijk userclasses 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 0en 12 jaar. Dit schept de mogelijkheid tot een heel scala van user classes. Eendaarvan is bijvoorbeeld Ouders van pasgeborenen.

� User Class Description

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

Voorbeeldbeschrijving van de user class Ouders van pasgeborenen

Ouders van pasgeborenen : Deze groep mensen heeft behoefte aan informatiedie 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 genaamdUser Object Models (UOMs) voor de user classes uit de vorige fase gemaakt.Verder kunnen ook nog perspectives worden gemaakt op de UOMs.


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).

Figuu r 12 : Een mogelij ke 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 Onlinevertoon t reeds een onderliggende navigatiestructuur. Het construeren van denavigatiepaden komt dus neer op het weergeven van deze structuur in het drie-lagenmodel 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 zonderconcrete website. In het geval van Ouders Online staat er al een website. Dus is hetalleen nodig de huidige presentatie van de website te beschrijven in een presentatiemodel. Afhankelijk van de keuze die in de volgende fase wordt gemaakt, is tezeggen of deze fase overbodig is.

Hui lenStuiptrekkenStaren

VerzorgingRustVoeding

UitslagKleurverander ingVerstopping

Ziekteverschi jnselenGedrag

Kraam per iode

vertoont

uit

uit zich inkomen voort ui t


� 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 daadwerkelijkuitgevoerd kan worden. Een andere mogelijkheid is echter het gebruik van eenwebsite ontwikkelomgeving. Die zal het conceptuele model dat tot op hedengegenereerd is als input kunnen gebruiken. Zo kan een DBMS-ondersteundewebsite geïmplementeerd worden.

Reeds aan het begin van het structurele migratieproces zal rekening gehoudenmoeten worden met de keuze van de te gebruiken website ontwikkelomgeving. Ditom een relationele of object georiënteerde realisatie te kunnen bewerkstelligen.Evenals bij conventionele software informatiesystemen is documentatie gewenst inverband met technisch onderhoud.

Het concrete migratieproces bestaat uit een invulling van de nieuwe structuur vande website. Een manier om dit aan te pakken is het gebruik van een tool. De tool zalde 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 zelfgeschreven zal moeten worden. Uiteindelijk zal het echter wel tijd schelen als hetalternatief een handmatige omzetting is.

5.4.2. Te verwachten problemen

In [5] zijn de resultaten verwerkt van meer dan vijftig migratieprojecten die zijnuitgevoerd met betrekking tot hypermedia ontwikkelprojecten. Het ging daarbij om demigratie van grote hoeveelheden data in HTML formaat die omgezet moestenworden naar SGML formaat. Het onderzoek dat in [5] wordt beschreven is geenafgerond geheel, maar er zijn reeds resultaten te onderkennen over bovengenoemdmigratieproces. Bij de ontwikkeling van hypermedia toepassingen zal in het kortgelet moeten worden op :

� Prototyping.

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

� Binding met werk.

Programmeurs kunnen een verkeerde affiniteit met hun werk opbouwen waardoor zeminder open staan voor veranderingen. Aanpassingen in hun werk vallen zwaar endit kan leiden tot opstand.


� Meerdere programmeurs.

Door de complexiteit van het werk is het soms niet mogelijk meer dan eenprogrammeur op een taak te zetten.

� Verkeerd onderhoud.

Door gebrek aan begrip van de nieuwe functionaliteit van de toepassing is hetonderhoud juist moeilijker geworden.

Deze lijst van problemen is uiteraard verre van compleet. De genoemde aspectenhebben alleen betrekking op het proces van de migratie of de ontwikkeling van eenhypermedia toepassing. Een reëel probleem van een ander formaat is definanciering van de uitvoering van het ontwikkelproces. Door de thans nog ad hocontwikkeling van hypermedia toepassingen is er tevens nog geen staandaardhonorarium overeengekomen. Verschillende softwareontwikkelaars kunnen in depraktijk aardig verschillen in grootte met betrekking tot de offertes voor hypermediaontwikkeling.

Verder zal er voor de website met een DBMS-ondersteuning een tijdperk aanbrekenmet nieuwe rollen. Zo zal er een DataBase Administrator aangesteld moeten wordenom onder andere de performance van het systeem te controleren.

51

6. Rol Active Databases

In het vorige hoofdstuk is de rol van een hypermedia design methode in hetonderhoud en beheer van een website besproken. In dit hoofdstuk zal wordeningegaan op de zelfcontrole m.b.t. het onderhoud en beheer, van een hypermediasysteem met database-ondersteuning. Volgens [27] zijn database ontwikkelaars heterover eens dat ‘gewone’ databases vervangen moeten worden door activedatabases. Met active databases kan namelijk een uniform mechanisme wordentoegepast om database-taken ten uitvoer te brengen. Thans zal worden ingegaan opde rol die een active database kan spelen12 in een DataBase Management Systeem(DBMS) van een hypermedia systeem (opslaglaag van Figuur 10 (c)). Uiteraard zaleerst 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 eenkoppeling 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 programmerente 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 systeemzich bevindt op het moment dat de event plaatsvindt. Een Action is een teondernemen handeling of actie die zal worden uitgevoerd wanneer de eventplaatsvindt en de condition geldt.

In de ECA regel wordt dus gespecificeerd welke actie ondernomen moet wordenwanneer één of meerdere gebeurtenissen plaatsvinden, voorondersteld dat eenbepaalde voorwaarde geldt. Daarbij moet een regel eerst getriggerd worden, dat wilzeggen, op gang gebracht worden. Een regel wordt getriggerd door het plaatsvindenvan de relevante gebeurtenis(sen). Als de regel eenmaal getriggerd is, wordt deregel overwogen om te zien of de voorwaarde geldt. Als de voorwaarde geldt, wordtde regel uitgevoerd door de actie uit te voeren.

Het gevolg van de koppeling van een passieve database met actieve regels is dat ereen reactievermogen van de database teweeg wordt gebracht. De database kan danreageren op (mogelijk externe) stimulansen. Dit reactievermogen kan toegepastworden voor verschillende doeleinden. Voorbeelden daarvan zijn beveiliging en hetchecken en toepassen van integriteitsaspecten.

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

HOOFDSTUK 6. ROL ACTIVE DATABASES 52

In [11, p. 421] worden enkele bestaande active database systemen besproken. Debestaande systemen en prototypen hebben een aantal gelijke aspecten, maar ookverschillende syntactische en semantische varianten. Deze verschillen leiden ertoedat de volle potentie van active databases moeilijk kan worden geëxploiteerd. Omdat wel te kunnen doen is volgens [11] een stabiele klassificatie van semantischedimensies en een goed begrip van hun mogelijke waarden nodig. De dimensieskarakteriseren daarbij het gedrag van een active database.

Naast de verschillende dimensies hebben de gebruikte regels ook een bepaaldesyntax. Een formele basis voor de beschrijving van het gedrag van active databaseswordt in [11] gepresenteerd door de introductie van een core taal. Deze core taalhoudt sterk verband met de twee datastructuren waaruit een active databasebestaat. 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 eenactive 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 tussenCondition 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 dimensiesgeï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 tevoeren zijn er twee manieren :


� Instantie- of tupel-georiënteerd, d.w.z. dat het doel van de update een enkeledatabase entiteit is.

� Set-georiënteerd, d.w.z. dat het doel van de update een set (verzameling) vandatabase entiteiten is.

Deze onderverdeling kan doorgevoerd worden naar regels, waardoor ook gesprokenkan 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 vaneen organisatie wordt toegevoegd. Na deze toevoeging moet de database dusgeupdate worden. Bij een instantie- of tupel-georiënteerde update zal na detoevoeging van N werknemers N updates moeten plaatsvinden. Bij een set-georiënteerde update zou slechts één update hoeven plaats te vinden na detoevoeging van de gegevens van alle N werknemers.

Voorbeeld upd ate van SQL3 regel waarin triggers doo r een tupel-georiënteerde upd ate worden geactiveerd.

CREATE TRIGGER Compute_Emp_NumberAFTER INSERT ON EmployeeFOR EACH ROWWHEN TRUEupdate Company_statistics set new_emp_number = 1 + new_emp_number


De set-georiënteerde versie van de SQL3 regel ziet er als volgt uit.

CREATE TRIGGER Compute_Emp_NumberAFTER INSERT ON EmployeeFOR EACH STATEMENTWHEN TRUEupdate 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ënteerderegels volgen.

6.1.1.2. Verschill ende kopp el-modes

De verschillende koppel-modes of -toestanden binnen een regel dienen terbeschrijving van :

� Regel-koppel-mode : de synchronisatie tussen de activering van de regel, deevaluatie van de conditie en de uitvoering van de actie. Dit duidt op eenonderverdeling in Event-Condition koppel-mode en Condition-Action koppel-mode.

� Transactie-semantiek-mode : de triggering van een event kan plaatsvindendoordat gebeurtenissen gelijktijdig voorvallen. Dit gelijktijdige aspect staat inrelatie tot conditie-evaluatie en actie-uitvoering. Deze relatie wordt ook door eenmode beschreven (wordt in paragraaf 6.1.1.4 besproken).

Een database-transactie van een gebruiker kan een trigger teweeg brengen die éénevent of meerdere events doet voorvallen. Als een event eenmaal is voorgevallenvindt de evaluatie van de conditie plaats. Deze Event-Cond ition kopp eling kan optwee 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 deCond ition-Action kopp eling. Deze koppeling is gebaseerd op tijd : de tijd dievoorbij gaat tussen de evaluatie van de conditie en het moment waarop de actiewordt uitgevoerd. Net als bij de Event-Condition koppeling wordt ook hier eenonderscheid gemaakt tussen gelijke koppeling en verlate koppeling.


6.1.1.3. 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) opzich kan een trigger zijn voor een event van een andere regel (2). In deze situatiemoet 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 detriggering event heeft veroorzaakt wordt tijdelijk gestaakt om andere, mogelijkgetriggerde regels uit te voeren (vergelijkbaar met recursieve procedures).

De atomaire uitvoering van de regel-actie kan voorbijgaan aan de Event-Conditionkoppeling.

6.1.1.4. Relatie van regel-uitvoering tot transactie-uitvoering

De transactie-semantiek-mode is reeds in paragraaf 6.1.1.2 genoemd. Eentransactie wordt gezien als een opeenvolging van manipulaties op data en queryoperaties. De relatie van de regel-uitvoering tot de transactie-uitvoering is een relatietussen 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 actie-uitvoering plaatsvindt.

Deze relatie wordt, afhankelijk van de situaties die zich voordoen beschreven. Diesituaties kunnen zijn :

� Zelfde transactie : de conditie-evaluatie en actie-uitvoering vindt plaats in detransactie van de triggering event (oftewel transactie 2 vindt plaats in transactie1).

Het gevolg hiervan is dat wanneer transactie 1 plaatsvindt en er komt een opdrachtbinnen om de regel af te breken, ook de transactie dus afgebroken wordt.

� Verschillende transacties : de conditie-evaluatie en actie-uitvoering vinden nietplaats in de transactie van de triggering event. Ze vinden plaats in een apartetransactie, er kan zelfs sprake zijn van twee verschillende transacties.

Dit betekent min of meer dat de volgorde van de uitvoering van de regel geregeldwordt door het concurrency control systeem en dat de regel-uitvoerings-engine hierniets mee te maken heeft.


6.1.1.5. Conflict resolutie mechanisme

In een systeem kan er sprake zijn van meerdere regels die tegelijkertijd getriggerdworden. 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 conflictresolutie mechanisme in werking moeten treden. Een conflict resolutie mechanismebiedt 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 kunnendeterministisch 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 ordeningvan voorrang tussen de regels. Als het de gebruiker is toegestaan eenvoorrangsordening te specificeren, kan zo weer deterministisch gedrag verkregenworden.

� Parallelle uitvoering : alle regels die zijn getriggerd worden parallel uitgevoerd.

Dat kan bijvoorbeeld door een aparte transactie uit te voeren om de conditie-evaluatie 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 plaatsvindenvan 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 eventsgebeurd nadat de regel die ze getriggerd hebben is verwerkt. De mogelijkhedendaartoe zijn :

� Geen consumptie : de triggering events behouden het vermogen om regels te

triggeren. Ze blijven onaangetast door de conditie-evaluatie en actie-uitvoeringvan de regel.


� Lokale consumptie : de triggering events zijn uitgewerkt op de geactiveerde

regel. De geactiveerde regel heeft de events verbruikt. Maar de triggering eventskunnen 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 alshet ware lokaal verbruikt door de getriggerde regel én door de andere regels dienu niet meer door de events worden getriggerd.

De lokale consumptie is de meest gangbare in de bestaande active databasesystemen.

De tijd van event consumption is het tijdsbestek waarin een getriggerde eventwordt verbruikt of geconsumeerd. Er zijn verschillende scenario’s mogelijk bij hetconsumeren van een event m.b.t. de tijd :

� De consumptie kan namelijk plaatsvinden nadat de regel is beschouwd en dat isonafhankelijk van de uitkomst van de conditie-evaluatie.

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

De gangbare manier van de consumptie van triggering events is die van consumptienadat 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 zijnwanneer de originele waarde, van een entiteit die aangepast is, moet wordengemanipuleerd. Het gedrag van een regel kan beïnvloed worden door degeschiedenis van de transactie. Bijvoorbeeld kan gedacht worden aan hetaanpassen van een salaris na een onterechte of niet-geautoriseerde verhoging. Erkunnen daarbij twee soorten van informatie betreffende de transactie-geschiedenisopgevraagd worden : database toestanden uit het verleden en reedsplaatsgevonden events.

� Database toestanden uit het verleden.

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

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


� De toestand na de laatste beschouwing of overweging van de regel (last-

consideration).

� 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 datauit het verleden wordt gemanipu leerd (herschrijving van het voorbeeld op p. 54).

CREATE TRIGGER Compute_Emp_Number2AFTER INSERT ON EmployeeREFERENCING OLD_TABLE AS Old_EmpFOR EACH STATEMENTWHEN TRUEupdate 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 diebeïnvloed zijn door reeds plaatsgevonden events m.b.v. queries op te vragen. Hetbelang hiervan ligt in het feit dat alleen de conditie-evaluaties die ooit uitgevoerd ofbeschouwd zijn door een transactie, de relevante data dus, worden beschouwd. Ditis een optimalisatie. Verder kunnen mede hierdoor ook regels worden gedefinieerddie gebaseerd zijn op een vescheidenheid aan data (kan bijvoorbeeld nodig zijn voorintegrity checking). Het inspecteren van reeds plaatsgevonden events kan opverschillende 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 tegebruiken. De querytaal wordt gebruikt door die uit te breiden met een verzamelingvan predicaten over items van plaatsgevonden events.


6.1.1.8. Samengestelde events en manipulatie event net effect

De primitieve events die in [11] genoemd worden zijn bijvoorbeeld databaseupdates, opdrachten van een transactie of kloksignalen. Regels kunnen getriggerdworden door willekeurige combinaties van deze primitieve events. Zo kunnenverschillende combinaties van events samengesteld worden. Er zijn hele simpelecombinaties (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 daarnagebeurd is.

� Het beschouwen van het netto effect van de volgorde van events (oftewel nettoevents).

Bij het beschouwen van netto events wordt het plaatsvinden van sommige eventsgezien als een invalidatie van de voorgaande (bijvoorbeeld een verwijder-operatiena een aanpassing).

De criteria voor het bepalen van het netto effect wisselt per systeem. Het Starburstsysteem (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 deeindversie 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. (Ditcriterium 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 ofnetto events. Als netto events worden gebruikt bestaat de kans dat een eenmaalgetriggerde regel nooit meer wordt getriggerd nadat de event heeft plaatsgevonden.


Voorbeeld

Stel dat de trigger van een regel de creatie van een entiteit is. Als deze entiteit wordtverwijderd, 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 deplaatsgevonden events en netto events.

Verband tussen event/action

Het verband tussen event en action heeft te maken met de reactie van een actieveregel. De reactie wordt meestal beschouwd na het plaatsvinden van zijn triggeringevents 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 opeen informele manier de verschillen en overeenkomsten van bestaande systemen teverklaren. In Tabel 2 wordt van de dimensies (besproken in paragraaf 6.1.1.1 en6.1.1.7) aan de hand van de waarden, de bestaande systemen aangegeven zoalsdat in [11] wordt gepresenteerd.

Het nut van de onderverdeling in dimensies is een systematischere aanpak van deontwikkeling van nieuwe aspecten m.b.t. regels. Zo kunnen regels van bestaandeactive database systemen makkelijker gecodeerd worden in een uniek formalisme.Het zal ook een beter begrip kweken van bestaande systemen.


Dimensies Waarden Bestaande systemen

Granularity vanupdates

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

Granularity vanregels

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

Inspectie vantransactie-geschiedenis

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 deregels in een syntaxformaat dat leesbaar is voor de gebruikers. In [11] wordt deEECA (Extended Event Condition Action) syntax als uniforme notatie voor het wijdbereik van bestaande aspecten voorgesteld. Extended Event Condition Action regelsbestaan net als ECA regels nog steeds uit drie delen (Event-Condition-Action), maar


er zijn enkele sleutelwoorden en ad hoc notaties toegevoegd ter beschrijving vanbovengenoemde dimensies. EECA regels specificeren in een systeem-onafhankelijknotatie waar een regelsysteem toe in staat is.

Een EECA regel begint met een declaratief gedeelte waarin de volgendesleutelwoorden worden gebruikt :

� granularity : het sleutelwoord granularity specificeert de korreligheid van deregel-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-modeen kan de waarden immediate of deferred aannemen. De Condition-Actionkoppel-mode heeft altijd de waarde immediate waardoor het wordt weggelatenin 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) kanworden (zie paragraaf 6.1.1.3).

� Event concumption : het sleutelwoord consumption-scope specificeert hetbereik van de event consumption en kan de waarden none, local, global-to-{list-of-rules} aannemen. Een tweede sleutelwoord consumption-timespecificeert de event consumption tijd en kan de waarden consideration enexecution 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 dewerknemer Sam heet en zijn salaris is nog steeds minder dan 5000, dan krijgt hijdoor deze regel een salarisverhoging van 10 %.

Voorbeeldregel van het Postgres systeem

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

EMP.name = CURRENT.name


De gebruikte sleutelwoorden uit het voorbeeld zijn :

� CURRENT : refereert naar de waarde van de updated tupel vóór de update diede regel heeft getriggerd.

� NEW : refereert naar de waarde van de tuple ná dezelfde update.

De gebruikte sleutelwoorden CURRENT en NEW zijn voorbeelden van semantischedimensies in de regel-syntax inspectie van de transactie-geschiedenis. Anderesystemen gebruiken ook soortgelijke sleutelwoorden, het resultaat van de actie kanechter verschillen. Dit kan worden verklaard door onder andere het verschil in demanier waarop elk systeem zijn regels update en ook hoe de activering van deregels plaatsvindt.

Een vertaling van dezelfde Postgres regel naar EECA formaat wordt in hetvolgende voorbeeld gepresenteerd.

Voorbeeldregel van het Postgres systeem in EECA

define granularity I / O EC immediate interruptable Trueconsumption-scope local consumption-time considerationrule 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 wasvermeld, namelijk dat de regel een granularity heeft die instantie-georiënteerd is. Dathoudt 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 eenandere event plaatsvindt.

� de triggering event wordt vergeten (consumed) door deze regel nadat hetoverwogen is.

Al deze informatie is hard-gecodeerd in de semantiek van het Postgres systeem enwordt pas duidelijk in de Extended Event Condition Action syntax.

Bovengenoemde voorbeelden laten zien dat de encodering van regels vanbestaande systemen naar EECA regels een grondige kennis van de semantiek vaneen specifiek systeem vergt.


6.1.3. Core model active database

Informeel begrip van het gedrag van active databases (door de onderverdeling indimensies) is niet genoeg. De semantiek van active databases dient gefundeerd tezijn op formele concepten zodat een programmeur de precieze uitkomst van zijnprogramma zou kunnen nagaan. Een specifieke eis die volgens [11] voor dezeformele basis nodig is, is een hoge graad van modulariteit en extensibiliteit. Om ditte 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 aspectenvan het gedrag van een active database weergegeven worden. EECA regels kunnenop het syntax niveau helemaal vertaald worden naar het core formaat. Regels die inhet 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 dusuniek zijn. Binnen de core regelsyntax wordt een active database beschouwd alseen combinatie van een passieve database en een eventbase. In de passievedatabase wordt de data van de toepassing opgeslagen en in de eventbase wordenfeiten opgeslagen die relevant zijn voor de transactie-geschiedenis van de database.Een update van een active database heeft altijd een gelijktijdig effect op zowel dedata in de passieve database als de events uit de eventbase.

Een eventbase [11] registreert interne events en externe events. Interne eventshebben te maken met database handelingen zoals bijvoorbeeld toevoegingen,verwijderingen en updates. Externe events daarentegen zijn onafhankelijk van deinterne 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 deeventbase.

De eventbase is een datastructuur die voor ons praktijkvoorbeeld van belang is ende volgende paragraaf zal daarop ingaan.


6.2. Active DBMS en hypermedia systemen

In paragraaf 5.3 is de architectuur van een hypermedia systeem besproken. Enhoewel in de literatuur ([22]) wordt aangegeven dat een Object Oriented DataBaseManagement System (OODBMS) de beste keus voor database ondersteuning zouzijn, kan beargumenteerd worden dat het regel-gebaseerde aspect van een activedbms in ons praktijkvoorbeeld van pas kan komen. Active databases zijn in staathandelingen uit te voeren wanneer het triggermechanisme wordt geactiveerd. Eenprobleem wat reeds naar voren is gekomen in paragraaf 2.6.1, is het feit datinformatie verouderd raakt en niet meer up-to-date is. De manier waarop thans ditprobleem wordt verholpen heeft te maken met de afhankelijkheidsrelatie die dewebsite heeft met de bezoekers van de website. Een migratie naar een database-ondersteunde omgeving zou echter betekenen dat gebruik zou kunnen wordengemaakt van active databases. Toepassing van een active database op de juistemanier zou de rol van de bezoekers van de website kunnen overnemen. Het gevolghiervan is dat de afhankelijkheidsrelatie opgeheven zou worden en het probleem vaninconsistentie, onvolledigheid en actualiteit (in elk geval deels) opgelost.

Zoals in paragraaf 6.1 reeds is aangegeven bestaat een active database uit eenpassieve database en een set van actieve regels. Onderzocht moet worden of deECA-regel binnen de context van een Object Oriented database kan wordengeplaatst. Dat zou namelijk betekenen dat ander soortige events dan de ‘normale’database events (object manipulatie en object selectie) zouden kunnen wordenwaargenomen. Zo wordt in [27] onderscheid gemaakt tussen de volgende eventsbinnen een Object Oriented database :

1. Events die gerelateerd zijn aan de uitvoering van objectmethoden ofobjectklassen (bijvoorbeeld het berekenen van een waarde).

2. Events die gerelateerd zijn aan de uitvoering van een transactie (bijvoorbeeldvoor de transactie begint).

3. Events die te maken hebben met tijd (bijvoorbeeld een gebeurtenis die om 8:00 uplaatsvindt).

4. Externe events (bijvoorbeeld een GUI-gebeurtenis (Graphical User Interface) ofeen temperatuur-meting).

5. Events die door de gebruiker worden gedefinieerd.

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


Een manier is de indexering van alle relevante events op een zodanige manier, datde gebruiker zelf kan aangeven welke event, wanneer en hoe vaak (vergelijkbaarmet bijvoorbeeld het instellen van de Scan Disk functie onder Windows) een eventgetriggerd moet worden. Met betrekking tot ons praktijkvoorbeeld zou het op dezemanier mogelijk zijn de informatie uit het archief zelf (door de redactie) up-to-date tehouden.

De toepassing van het regel-gebaseerde aspect van active databases in een ObjectOriented database kan ertoe leiden dat het DataBase Management Systeem in deopslaglaag van een hypermedia systeem een zelfonderhoudende functie gaatvervullen. Deze visie zal echter formeel onderbouwd dienen te worden.

67

7. Evaluatie en conclusie

Vaststelling huidige situatie

Om een verandering van de efficiëntie binnen het onderhoud en beheer van eenwebsite te bewerkstelligen, welke verandering dan ook, dient eerst de huidigesituatie bekeken te worden. Als voorbeeld uit de praktijk is de huidige situatie van dewebsite van Ouders Online onder de loep genomen. Zo zijn typischewebsiteproblemen naar voren gekomen.

Strategie

Aan de hand van de problemen zijn de bronnen van inefficiëntie vastgesteld. Diehebben onder andere geleid tot het opstellen van criteria voor efficiënt onderhoud enbeheer. Het is duidelijk dat de onderliggende gegevens van een websitegestructureerd opgeslagen moeten worden, teneinde problemen zoalsinconsistentie, onvolledigheid en actualiteit te minimaliseren. Aangezien het doel vaneen hypermedia design methode het ondersteunen van een systematischeontwikkeling van hypermedia toepassingen is, was de volgende stap het nagaan vandie mogelijkheid. Verschillende bestaande hypermedia ontwikkelsystemen enmethoden zijn besproken met de voor- en nadelen.

Om het gestructureerd opslaan van websitegegevens te ondersteunen en degenoemde problemen te minimaliseren, is de toepassing van een hypermediadesign methode voorgesteld. Daarbij is de migratie besproken die nodig zou zijn omte komen tot een vernieuwde websitestructuur met een database managementsysteem ter ondersteuning.

De aanwezigheid van een database management systeem in de architectuur vaneen hypermedia toepassing, heeft geleid tot de vraag welke rol active databaseskunnen spelen in het actueel houden van gegevens. De toegevoegde waarde vaneen active database is daarbij besproken.

Conclusie

Een hypermedia design methode probeert niet alleen om gegevens op eengestructureerde manier op te slaan, maar heeft tevens de potentie om hetonderhoud en beheer aan de website te reduceren. Door het beschrijven van derelevante informatieobjecten van een website en de navigatiemechanismen wordenbelangrijke dimensies van hypermedia toepassingen gevangen (inhoud, structuur,presenatie, dynamiek en interface). De voordelen van het gebruik van eenhypermedia design methode zullen echter pas duidelijk tot uiting komen wanneer deprocesontwikkeling van hypermedia formeel beschreven wordt.

Om die reden (geen formele semantiek) vindt de ontwikkeling van hypermediatoepassingen thans nog ad hoc plaats.

HOOFDSTUK 7. EVALUATIE EN CONCLUSIE 68

Herstructurering van de website van Ouders Online met behulp van een hypermediadesign methode zal de problemen m.b.t. de presentatie van de website en de opslagvan de gegevens minimaliseren. De problemen van sociale aard zoals het karaktervan de website en de organisatie (de informatieaanbieders) erachter bevinden zichbuiten het bereik van automatisering.

De toepassing van het regel-gebaseerde aspect van active databases in een ObjectOriented database kan ertoe leiden dat het database management systeem in deopslaglaag van een hypermedia systeem een zelfonderhoudende functie gaatvervullen. De semantiek van active databases biedt in het concept eventbasedaartoe een mogelijkheid die nog onderzocht moet worden.

Toekomstig onderzoek

Om de ad hoc ontwikkeling van hypermedia te voorkomen of verbeteren zalbegonnen moeten worden met het begrijpen van de hypermediaontwikkelprocessen. Het is moeilijk methodologiën en technieken uit anderedisciplines voor hypermedia ontwikkelprocessen te hanteren, omdat hypermediatoepassingen andersoortige dimensies beschouwen dan bijvoorbeeldinformatiesystemen. Het nut van de onderverdeling in dimensies was eensystematischere aanpak van de ontwikkeling van nieuwe aspecten. Dat is duidelijknaar voren gekomen bij de bespreking van active databases. Voor hypermedia isook een systematischere aanpak vereist en onderverdeling in dimensies zou eengoede start zijn om een uniek formalisme te creëren.

De daadwerkelijke herstructurering van de website (de structurele migratie van deconceptuele structuur), de uiteindelijke performance van het systeem en detoepassing van een active database in een Object Oriented DBMS zijn zaken dieverder in de praktijk onderzocht moeten worden.

69

Nawoord

Het praktijkvoorbeeld dat in voorgaande hoofdstukken is besproken blijft uiteraardonderhevig aan ontwikkelingen. Zo zal medio 1999 de website van Ouders Onlineeen karakterverandering ondergaan. De website zal voor een gedeelte nog steedsgratis toegankelijk blijven. Een deel van de website zal specifieke dienstenaanbieden. De toegang tot dat deel van de website zal dan alleen mogelijk zijnwanneer de gebruiker een abonnement heeft afgesloten.

70

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

71

Lijst van Tabellen

Tabel 1 : Verschillende fasen genoemde hypermedia design methoden, 23

Tabel 2 : Gedeeltelijk overzicht semantiek van bestaande active databases, 61

72

Bibliografie

[1] Olga De Troyer. Designing Well-Structured Websites: Lessons to be Learnedfrom Database Schema Methodology, Tilburg University, INFOLAB, Tilburg, TheNetherlands.

[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 OurCapacity 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, November1998.

[5] Dr. David Lowe, Dr. Richard Webby. Web Development Process Modeling andProject Scoping : Work in Progress.http://btwebsh.macarthur.uws.edu.au/san/webe98/Proceedings/Lowe/WebE98-LoweWebby.htm.

[6] V. Balasubramanian. State of the Art Review on Hypermedia Issues AndApplications. Graduate School of Management, Rutgers University, Newark, NewJersey. http://wwwis.win.tue.nl/~percy/HTML/.

[7] O.M.F. De Troyer, C.J. Leune. WSDM: a User-Centered Design Method for WebSites. 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 ofHypermedia Applications. In Proc. Hypertext ’98 Workshop, 1st InternationalWorkshop on Hypermedia Development : Processes, Methods and Models, June1998, online html version. http://www.informatik.fernuni-hagen.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. 57-66, August 1995.

[11] Piero Fraternali, Letizia Tanca. A Structured Approach for the Definition of theSemantics 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 PublishingLimited, 128 Long Acre, London WC2E 9AN, 1982.

BIBLIOGRAFIE 73

[13] Alicia Díaz, Tomás Isakowitz. RMCase : Computer-Aided Support forHypermedia Design and Development. In S. Fraïssé, F. Garzotto, T. Isakowitz, J.Nanard and M. Nanard, editors, Hypermedia Design : Proceedings of theInternational Workshop on Hypermedia Design, Montpellier, France, 1-2 June1995. Workshops in Computing Series, edited by prof. C. J. van Rijsbergen, p. 3-15. Springer-Verlag, 1996.

[14] G. Rossi, D. Schwabe, C.J.P. Lucena, D.D. Cowan. An Object-Oriented Modelfor 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 HypermediaDesign, 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 UserRequirement 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, secondedition, 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 ThinkingPerson’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 Universityof Technology, The Netherlands.http://wwwis.win.tue.nl/2L670/static/definition.html.

[21] B. Prakken, Informatie en de Besturing van Organisaties. Een BedrijfskundigeAanpak 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 : AnExtensible Object-Oriented Hypermedia Engine.http://wwwx.cs.unc.edu/~barman/HT96/P46/HT96BapatEtAl.html.

[23] P. D. Bruza. Stratified Information Disclosure : A Synthesis between InformationRetrieval and Hypermedia. PhD thesis, University of Nijmegen, Nijmegen, theNetherlands, 1993.

[24] John F. Buford. Evaluating HyTime : An Examination and ImplementationExperience. Department of Computer Science, University of MassachusettesLowell. http://www.cs.unc.edu/~barman/HT96/P69/buford.htm.

BIBLIOGRAFIE 74

[25] Frank G. Halasz. Reflections on Notecards: Seven Issues for the NextGeneration 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 ManagementSystems. 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.

75

IndexActive databases

Active DBMS, 51Active Databases

core model, 64dimensies, 52eventbase, 64Event-Condition-Action-regel, 51Extended-Event-Condition-Action-regel,

61hypermedia systemen, 65

applicatie website, 25Atomaire uitvoering regel-actie, 55bereik event consumption, 56besturingscyclus, 14bottom-up view, 24conclusie, 67concrete migratie, 48Condition-Action koppeling, 54Conflict resolutie mechanisme, 56consumption-scope, 62consumption-time, 62database administrator, 44data-driven aanpak, 26dbms, 44deferred, 62EECA sleutelwoorden, 62Efficiënt onderhoud en beheer

adaptief onderhoud, 15correctief onderhoud, 15perfectief onderhoud, 15

evaluatie, 67evaluatie hypermedia design methoden, 38event consumption, 56event net effect, 59event/action, 60Event-Condition koppeling, 54external view, 27external view integration, 27Geen consumptie, 56Globale consumptie, 57granularity, 62granularity van regels, 52granularity van updates, 52herstructurering, 41Hypermedia Design Methode

HyDev, 20hypermedia toepassing, 17hypertext, 17OOHDM, 21RMM, 22WSDM, 25

hypermedia enginesHyperStorm, 25

OOHDM web, 24RMCase, 24WebComposition, 24

immediate, 62Inefficiëntie bronnen, 13Informatie Systeem Ontwikkeling

raamwerk, 18information requirement, 30inspectie transactie-geschiedenis, 57Instantie- of tupel-georiënteerde regels, 53Instantie- of tupel-georiënteerde update, 53interruptable, 62karakteristieken, 30kiosk website, 25koppel-modes, 54last-consideration, 58Lokale consumptie, 57net effect computation, 59netto events, 59operationeel beleid, 14Ouders Online

doelgroep, karakter & doelstelling, 6onderhoud en beheer, 8ontstaan, het, 5presentatie website, 6problematiek, 9verantwoordelijkheid medewerkers, 5

Parallelle conflict resolutie, 56passieve database, 51perspective, 30pre-event, 58pre-transaction, 57Regel-koppel-mode, 54Regelsyntax active database, 61regel-uitvoering, 55Samengestelde events, 59scriptie

inleiding, 1opbouw, 3probleemstelling, 2

Seriële conflict resolutie, 56Set-georiënteerde regels, 53Set-georiënteerde update, 53structurele migratie, 46tijd event consumption, 57Toepassing hypermedia design

de architectuur, 42de migratie, 44, 48de voordelen, 42

top-down view, 20transactie-semantiek-mode, 55Transactie-semantiek-mode, 54transactie-uitvoering, 55

INDEX 76

usability requirement, 30user-centured aanpak, 26user-driven aanpak, 26way of modelling

HyDev, 20WSDM, 28

way of modelling & way of workingOOHDM, 21RMM, 22

way of thinkingHyDev, 20OOHDM, 21RMM, 22

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

EFFICIËNT ONDERHOUD & BEHEER VAN WEBSITEScs.ru.nl/mtl/scripties/1999/456.Welas.pdf · Het belang...

Documents

Transcript of EFFICIËNT ONDERHOUD & BEHEER VAN WEBSITEScs.ru.nl/mtl/scripties/1999/456.Welas.pdf · Het belang...