Inhoudsopgave Inhoudsopgave
1
Dankwoord
3
Inleiding
4
1 Korte Schets Thesis 1.1 Doelstelling . . . . . . 1.2 Probleemstelling . . . 1.3 Werkwijze . . . . . . . 1.4 Achtergrondinformatie
. . . .
5 5 6 6 7
. . . .
8 8 13 13 15
. . . . . . . .
17 17 17 17 17 17 17 18 18
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2 Hoog Niveau Architectuur Elektronische 2.1 Visie Software Ontwerp . . . . . . . . . . 2.2 Intu¨ıtieve Schets Elektronische Agenda . 2.2.1 Intu¨ıtieve Schets Basis-Applicatie 2.2.2 Intu¨ıtieve Schets Extensie . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Agenda . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
3 Verkenning van het Terrein door Literatuurstudie 3.1 Lasagne: Verkenning op abstract niveau . . . . . . . . . . 3.1.1 Van Spaghetti naar Lasagne . . . . . . . . . . . . . 3.1.2 Consistentie Management . . . . . . . . . . . . . . 3.2 Lasagne: Verkenning op niveau van het programmeermodel 3.2.1 Een korte introductie tot Correlate . . . . . . . . . 3.2.2 Lasagne: wat zit er onder de motorkap . . . . . . . 3.2.3 Ontwerpmethodologi¨en van Extensies . . . . . . . . 3.2.4 Related Work . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
4 Ontwerp van Elektronische Agenda: Basisontwerp en Extensies 19 4.1 Ontwerp van Basisprogramma . . . . . . . . . . . . . . . . . . 19 4.1.1 Ontwerp en Motivatie . . . . . . . . . . . . . . . . . . 19 1
4.2
4.3 4.4
4.1.2 Moeilijkheden die optraden Ontwerp van Extensies . . . . . . . 4.2.1 Mail-Extensie . . . . . . . . 4.2.2 Strategie-Extensie . . . . . . 4.2.3 Group-Extensie . . . . . . . 4.2.4 Authenticatie-Extensie . . . Algemene Problemen . . . . . . . . Evaluatie Ontwerp . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 Implementatie van Elektronische Agenda: Extensies 5.1 Implementatie van Basisprogramma . . . . 5.1.1 Belangrijke codefragementen . . . . 5.1.2 Moeilijkheden . . . . . . . . . . . . 5.2 Implementatie van Extensies . . . . . . . . 5.2.1 Mail-Extensie . . . . . . . . . . . . 5.2.2 Strategie-Extensie . . . . . . . . . . 5.2.3 Group-Extensie . . . . . . . . . . . 5.2.4 Authenticatie-Extensie . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
19 19 19 19 20 20 20 20
Basisontwerp en . . . . . . . .
. . . . . . . .
. . . . . . . .
6 Conclusie 6.1 Doelstelling bereikt? . . . . . . . . . . . . . . . 6.2 Moeilijkheidsgraad ontwikkeling/implementatie 6.3 Persoonlijke Mening . . . . . . . . . . . . . . . 6.4 Conclusie . . . . . . . . . . . . . . . . . . . . . Bibliografie
. . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . .
21 22 22 22 22 22 22 22 22
. . . .
23 23 23 23 23 24
2
Dankwoord In de eerste plaats wil ik mijn begeleider Eddy Truyen bedanken voor de vele idee¨en die hij mij gaf voor mijn thesis en voor de vele vragen die hij steeds beantwoord heeft. Daarnaast wil ik hem ook bedanken voor het nalezen van mijn tekst. Ik wil ook mijn promotor, Prof. Dr. ir. P. Verbaeten bedanken voor het opvolgen van mijn thesis, dit ondanks zijn zware werklast. Vervolgens is het dankwoordje gericht aan Tim Verwimp, voor de vele vruchtbare gesprekken die we over Correlate en Lasagne gevoerd hebben. Ook Benjamin Taes en Stijn Cauwbergs ben ik een dankwoord verschuldigd, voor het luisterend oor dat zij boden bij de problemen die optraden tijdens het werk. Tenslotte wil ik ook mijn ouders, familie en vrienden bedanken voor de steun en het vertrouwen dat ze mij gaven tijdens mijn studies. Het laatste dankwoord is gericht aan mijn vriendin Leen, omdat ze altijd voor me klaarstond wanneer ik nood had aan een goed gesprek.
3
Inleiding Iedereen kent ongetwijfeld het nut van een elektronische agenda. Velen onder ons kunnen zich geen leven meer voorstellen zonder dit hebbeding. Zulk een agenda werkt vaak in een gedistribueerde omgeving, volgens het client-server model. Wanneer een bedrijf een agenda wil aanbieden aan haar klanten, leveren ze ten eerste een agenda met basisfunctionaliteit. Hierin zijn de basisfuncties aanwezig, zoals het maken van een afspraak, het raadplegen van je eigen of andermans agenda, . . . Er kunnen echter ook extra diensten aanwezig zijn, die de klanten kunnen gebruiken. Hierbij denken we aan het sturen van een emailnotificatie naar de andere partij bij het maken van een afspraak, het mogelijk maken van groepsafspraken, maar ook aan security related uitbreidingen, zoals toegangscontrole. Het is meteen al duidelijk dat sommige diensten optioneel zijn, terwijl bijvoorbeeld de toegangscontrole door het bedrijf zelf moet geregeld worden. Deze applicatie heb ik ontworpen en ge¨ımplementeerd in het componentenmodel Lasagne, ontwikkeld door Eddy Truyen. Dit alles om na te gaan of het moeilijk is zulk een applicatie te ontwerpen en te testen of alles werkt zoals het zou moeten.
4
Hoofdstuk 1 Korte Schets Thesis De inleiding bevat slechts een bondige introductie tot het onderwerp van mijn thesis. Daarom zal ik nu in hoofdstuk 1 een meer complete schets trachten te geven. Eerst zal ik wat dieper ingaan op de doelstelling van de thesis. Dit is de ideale gelegenheid om de opdracht exact en volledig te schetsen. Vervolgens is het tijd om de probleemstelling wat verder uit te diepen. Hierbij komen vooral het nut van de thesis en welke moeilijkheden er moeten overwonnen worden naar voren. Daarna is het tijd om wat aandacht te besteden aan de werkwijze die ik gehanteerd heb om alles tot een goed einde te brengen. Tenslotte zal ik dit hoofdstuk be¨eindigen met wat achtergrondinformatie.
1.1
Doelstelling
Het doel van de thesis bestaat erin het ontwerp en de implementatie te leveren van een basisapplicatie en enkele extensies. Als basisapplicatie heb ik geopteerd voor een elektronische agenda. Een extensie kan men zien als een plug-in, een component waarmee men de basisapplicatie kan uitbreiden om zo extra functionaliteit toe te voegen. In de basisapplicatie van de elektronische agenda is het bijvoorbeeld mogelijk om een afspraak te maken tussen 2 personen. Een uitbreiding zou hier zijn dat je afspraken kunt maken tussen meerdere personen. De implementatie van de basisagenda gebeurt in Correlate. Correlate is geen nieuwe programmeertaal, maar het is een uitbreiding van de objectgeori¨enteerde programmeertaal Java. Het breidt Java uit met ondersteuning voor concurrency en niet-functionele vereisten omtrent de distributie. 5
De implementatie van de extensies daarentegen gebeurt in Lasagne. Lasagne is een framework dat boven elke klasse-gebaseerde object-geori¨enteerde programmeertaal past. Hier is er gekozen om dit bovenop Correlate te doen, wegens de voordelen van de distributie en de concurrency. Tenslotte zijn we aangekomen bij het hoofddoel van de thesis: werkt alles zoals het hoort te werken? Hierbij is het ook belangrijk na te gaan of alles vlot verloopt en een verslag te maken van welke problemen er op treden bij de implementatie.
1.2
Probleemstelling
Omdat het een nieuw domein betreft waarvoor er bijna geen voorbeelden bestaan, was het moeilijker om met de materie vertrouwd te raken. Daar deze vorm van softwareontwikkeling zeer recent is, is er nog geen ontwerpmethodologie beschikbaar om de extensies vorm te geven. Het grote probleem is hier dat een extensie een aantal klassen moet uitbreiden met extra gedrag, wat schematisch niet eenvoudig weer te geven is. Daarom is het tweede doel van deze thesis het vinden van een geschikte ontwerpmethode. Hiervoor kan ik putten uit enkele papers waarin ik me in de literatuurstudie verdiept heb.
1.3
Werkwijze
Vooraleer het mogelijk was om aan het ontwerp van de basisapplicatie te beginnen, was het nodig om via literatuurstudie alles te weten te komen over Correlate. Toen ik dit onder de knie had, was het tijd voor het eigenlijke ontwerp en bijhorende implementatie. Hierna kwam Lasagne aan de beurt, met eveneens een uitgebreide literatuurstudie als basis. Omdat het nog een zeer recent terrein is, is er nog niet veel informatie en voorbeeldmateriaal beschikbaar. Hierdoor werd de grondige studie wel moeilijker, maar uiteraard niet onmogelijk. Voor het ontwerp van de extensies in Lasagne was het zoals vermeld heb in 1.2 nodig om wat onderzoek te doen naar een geschikte ontwerpmethode. Hiervoor heb ik verschillende papers over Contracts en Composition Patterns bestudeerd.
6
Toen ook deze ontwerp- en implementatiefase er opzat, was het tijd om uitvoerig te testen en na te gaan of intern alles opgeroepen werd zoals verwacht. Als laatste stap in het verloop van mijn thesis was het uiteraard tijd om de thesistekst te schrijven.
1.4
Achtergrondinformatie
De thesis kan geplaatst worden onder de noemer van computernetwerken en gedistribueerde systemen. Hierdoor past ze in het kader van de Distrinet werkgroep. Ook de 2 gebruikte ontwikkelingsomgevingen zijn ontwikkeld in de Distrinet groep. Correlate is enkele jaren geleden ontworpen en ontwikkeld als doctoraatsthesis door Bert Robben. Lasagne is het resultaat van het intensieve werk van mijn thesisbegeleider Eddy Truyen. Het is werkelijk een mooie ervaring om met deze 2 programmeertalen kennis op te doen. Ze zijn nog niet door “de massa” bekend, wat de uitdaging des te groter maakt.
7
Hoofdstuk 2 Hoog Niveau Architectuur Elektronische Agenda In het vorige hoofdstuk heb ik een kort overzicht gegeven van deze thesis. In dit hoofdstuk ga ik een intu¨ıtieve schets geven van hoe de applicatie logisch in mekaar steekt als een verzameling van features. Deze features kunnen dynamisch geactiveerd worden om zo een klant-specifiek perspectief te bekomen. Zo wordt de lezer niet alleen meer vertrouwd met deze nieuwe manier van denken over softwareontwikkeling, maar kan hij/zij ook het volgende hoofdstuk, de literatuurstudie, veel gerichter lezen. In een eerste deel ga ik wat meer uitleg geven over de visie op Software Ontwerp. Hierbij geef ik voornamelijk een woordje uitleg over de extensies als features. In een volgende deel wordt er een intu¨ıtieve schets gegeven van de Elektronische Agenda met zijn extensies.
2.1
Visie Software Ontwerp
Het is een onmiskenbaar feit dat het Internet een steeds belangrijker fenomeen in onze wereld aan het worden is. Het duikt plots op in tal van toepassingen. Het is niet alleen een onmetelijke en onmiskenbare bron van informatie, maar het zorgt er ook voor dat we van op afstand al onze taken kunnen uitvoeren, doordat we verbonden zijn door een groot netwerk. Op deze manier kunnen “gewone” applicaties vervangen worden door gedistribueerde applicaties, zodat zij overal ter wereld kunnen geraadpleegd worden, ongeacht de locatie. Door de snelle groei van het Internet, is de 8
interesse in en de vraag naar gedistribueerde online services alleen nog maar gestegen. Helaas heeft deze nieuwe vorm van softwareontwikkeling niet alleen maar voordelen, maar er duiken ook een aantal problemen op. Het eerste grote probleem dat we tegenkomen, kunnen we plaatsen in de context van customizatie. Met customizatie wordt de persoonlijke aanpassing van een applicatie bedoelt. Elke klant kan zo zijn applicatie aanpassen aan zijn eigen voorkeuren en noden. Op het eerste zicht klinkt dit wel goed, maar wanneer we bij zulk een implementatie van een applicatie een systeeminstantie hebben terwijl er daarop honderden klanten werken met elk hun eigen voorkeuren en noden, is het allesbehalve evident. Hierbij maken we voorlopig abstractie van het feit dat het kan gebeuren dat er tussen de klanten onderling conflicterende noden kunnen optreden. We zoeken dus naar een oplossing waarbij het mogelijk moet zijn om je eigen context aan te passen, zonder anderen hierbij te hinderen. Dit komt neer op het oplossen van het probleem van de customizatie, waarbij er verschillende klant-specifieke perspectieven moeten ondersteund worden. Een klant-specifiek perspectief is de persoonlijke kijk die de klant heeft op zijn applicatie. Een na¨ıeve oplossing zou zijn om voor elke klant een kloon bij te houden van dezelfde systeeminstantie. Hierbij is de implementatie van deze kloon dan aangepast aan de noden van de gebruiker. Zoals je Figuur 2.1 op de volgende pagina ziet, is dit echter allesbehalve effici¨ent, zeker wanneer de applicatie vele klanten heeft. Een belangrijker nadeel is dat het klonen niet voldoende is als oplossing, omdat de noden van de klanten kunnen veranderen in de tijd. Daarom moest er op zoek gegaan worden naar een oplossing waarbij het wel mogelijk is de applicatie aan te passen aan de noden van de klant, zonder hierbij gebruik te maken van klonen. We moeten met andere woorden het gedrag van de systeeminstantie kunnen manipuleren at-run time. Op deze manier is het mogelijk om de systeeminstantie op basis van de wensen van de klant te customizeren. Zo bekomen we dan de gewenste klant-specifieke kijk op de applicatie. Deze customizatie op basis van klant-aanvraag wordt mogelijk gemaakt door dynamisch en klant-specifiek in- en uitpluggen van de add-on features. Zo kan de nodige flexibiliteit geboden worden. 9
Klant 1
Klant 2 Klant 3
Klant 4
Klant 5
Klant 6
Met
als eigen kopie van systeem instantie met eigen voorkeuren van klant
Figuur 2.1: Representatie van klanten en eigen kloon van de applicatie
Om dit mogelijk te maken, moeten we vertrekken van een stabiele kern. Dit is als het ware de basisapplicatie zelf, die enkel en alleen zorgt voor basisfunctionaliteit. Onder basisfunctionaliteit verstaan we de minimale functionaliteit die elke klant zeker nodig heeft, ongeacht de extra functionaliteit die hij later zou willen toevoegen. Deze functionaliteit is dezelfde voor alle klanten. Bij het ontwerpen moet er rekening mee gehouden worden dat er niet teveel acties ondernomen mogen worden in ´e´en functie. De functies moeten zeer eenvoudig blijven, met bijvoorbeeld ´e´en operatie of actie per functie. Op deze manier is het achteraf eenvoudiger om er extra gedrag aan toe te voegen via de features. Het correct vinden van de stabiele kern is allesbehalve gemakkelijk en vergt wat ervaring. Wanneer men voor de eerste keer zulk een basisapplicatie ontwerpt, kan het tijdens de implementatie van de features gebeuren dat blijkt dat het ontwerp niet laag genoeg is. Dan zijn er met andere woorden veel te veel acties gedaan per methode en moet de methode opgesplitst worden in twee of meerdere basis-methodes. Er wordt verondersteld dat deze altijd kan gevonden worden. Daarnaast moeten er ook extensies voorzien worden. Met een extensie bedoel ik de extra functionaliteit die de klant kan gebruiken. Dit kan zowel een nieuwe functionaliteit (add-on), een aanpassing van een bestaande functio10
naliteit als een business rule zijn. At run-time kunnen er extensies geselecteerd worden per klant, om zo de gewenste customizatie voor de klant te realiseren. Welke extensies er geselecteerd worden in de kern-applicatie hangt af van de noden van de klant die op dat moment de aanvraag doet. Deze manier van customizatie (selectie van extensie door aanvraag tot gebruik van een feature) lijkt de enige oplossing om customizatie te realiseren bij het klant-specifieke vereisten. Om dit tot een goed einde te brengen, moeten er nog een aantal consistentie beheer problemen opgelost worden. Van deze problemen maken we nu abstractie. Deze zullen later besproken worden in hoofdstuk *** Wanneer men normaal gezien een kleine wijziging wil doorvoeren aan software, resulteert dit in grote wijzigingen aan de bestaande code. Vaak moet er wat code veranderd worden in een aantal klassen, wat het geheel nog ingewikkelder maakt. Het programmeren van extensies wordt in de tweede plaats ook bemoeilijkt door het bewaren van de consistentie en tenslotte nog door het voorzien van de mogelijkheid om at run-time in en uit te pluggen. Voor het realiseren van Lasagne werd een beroep gedaan op Aspect Oriented Programming (AOP), dat onderzoek levert naar mechanismen om extensies te programmeren als modulaire bouwstenen. Deze modulaire bouwstenen kunnen gezien worden als ´e´en blok code, die de aanpassing bevat voor alle componenten van de basis-applicatie. Dit is conceptueel gezien veel beter dan dat gewoon de bestaande code aangepast zou worden en dat je met andere woorden in vele klassen kleine aanpassingen moet gaan doen, de zogenaamde “croscutting features”. Het gedrag van de kern-onderdelen wordt veranderd, zonder de code van de kern te veranderen, maar door ze te encapsuleren in wrappers. (Het is ook mogelijk deze wrapper dan weer uit te breiden met extra gedrag door deze te encapsuleren in een andere wrapper) Wrappers zijn handig om systemen die een online service aanbieden aan te passen. De systeeminstantie heeft een aantal klanten, met elk hun eigen voorkeuren en noden, die als features kunnen in- en uitgeplugd worden. Dit is mogelijk door het feit dat wrappers op het instantiatie niveau werken. Zo kan het gedrag van het systeem aangepast worden aan de dynamisch evoluerende noden van de gebruikers, zonder het systeem te stoppen om de aanpassingen uit te voeren. Dit is zeer belangrijk voor tal van bedrijven die 24 uur op 24, 7 dagen op 7 online en bereikbaar moeten zijn, denken we maar 11
aan banken, verzekeringen, ziekenhuizen,. . . om er enkele te noemen.
Stabiele kern
Stabiele kern
Wrapper Wrapper Wrapper Wrapper
Person 1
Person 1
Figuur 2.2: Voorstelling van de applicatie met en zonder extensies De selectie van de extensies gebeurt per aanvraag van de klant. Omdat er zo vele componenten van de basisapplicatie kunnen aangesproken worden, moet er veel aandacht besteed worden aan de consistentie. Eens geselecteerd, moeten alle volgende oproepen volgens dit patroon opgeroepen worden. Als laatste puntje in dit hoofdstuk zou ik graag nog even willen aanhalen dat de gebruiksvriendelijkheid van wrappers in klasse-gebaseerde objectgeori¨enteerde programmeertalen gelimiteerd wordt door het onderliggende object model. Het belangrijkste probleem is dat wrappers niet dynamisch kunnen ingeplugd worden tussen de server en de klant. De klant moet namelijk tijdelijk zijn referentie naar de service veranderen naar de de referentie van de wrapper. Deze omschakeling tussen referenties wordt al snel complex en moeilijk te onderhouden voor grote systemen, zeker wanneer er dynamisch extensies kunnen in- en uitgeplugd worden.
12
2.2
Intu¨ıtieve Schets Elektronische Agenda
In het laatste deel van dit hoofdstuk ga ik de theorie van hierboven concreet maken door het op een voorbeeldje toe te passen. Ik ga de elektronische agenda in beknopte weergave schetsen, zodat de lezer zich een duidelijker beeld kan vormen van wat er allemaal verteld is. Zoals we gezien hebben in 1.1 is de doelstelling een elektronische agenda te ontwikkelen. Hierbij moeten er zowel een basis-applicatie als enkele extensies ontworpen worden. Om een duidelijk onderscheid te maken tussen basis en extensie, zal ik eerst in 2.2.1 de schets van de basis-applicatie geven. Vervolgens komen de extensies aan bod in 2.2.2.
2.2.1
Intu¨ıtieve Schets Basis-Applicatie
De basis-applicatie bestaat uit de kerncomponenten, de stabiele minimale componenten die iedereen zeker nodig heeft om met de agenda te werken. In dit geval bestaat de basis-applicatie uit 2 grote hoofdcomponenten, namelijk een Agenda en een DatingSystem.
1 1 Agenda
Dating System
Klant
*
Figuur 2.3: Kern Elektronische Agenda Dit zien we duidelijk in Figuur 2.3. We zien een Agenda en een DatingSystem component die met elkaar in verbinding staan (let op de ariteit). De Agenda is de component die de concrete agenda met afspraken voorstelt. Deze agenda behoort aan een persoon. Elke persoon heeft dus zijn eigen agenda. De andere component is het DatingSystem. Dit stelt de service voor die de afspraken tussen de verschillende agendas regelt. In de volgende Figuur, namelijk Figuur 2.4, zien we een simpele interface van de componenten gegeven. De componenten kunnen via deze interface met elkaar communiceren. 13
Interface DatingSystem{ Agenda create ( Owner owner ); void makeAppointment ( Agenda agenda1, Agenda agenda2, Period period ); Vector inspect ( String owner, Period period ); } 1 Agenda
Dating System *
Klant
* 1
Interface Agenda{ Appointment inspect ( Period period ); Appointment inspectOtherAgenda ( Agenda otherAgenda, Period period ); }
Figuur 2.4: Kern Elektronische Agenda
Zoals u ziet kan je nagaan of een bepaalde periode nog vrij is in de eigen of andermans agenda. Er is uiteraard ook een methode voorzien om een afspraak te maken. We zien ook dat er een klant aanwezig is op deze figuur. Hier moeten we ons het klantprogramma bij voorstellen. Via het klantprogramma kan de de gebruiker via een prompt-interface commandos ingeven om zo de gewenste acties uit te voeren. Als laatste puntje bij Figuur 2.4 wil ik graag opmerken dat er in de interface specificatie gebruik gemaakt wordt van Appointment en Period objecten. Deze objecten zijn weliswaar belangrijk, maar ze worden niet voorgesteld door een component dus vandaar dat ze ook niet grafisch weergegeven worden.
14
2.2.2
Intu¨ıtieve Schets Extensie
Vervolgens gaan we verder met het geven van een schets van enkele extensies. Ik zal hierbij 2 extensies wat nader toelichten, namelijk de extensie van groepsafspraken en de extensie van toegangscontrole. Om dit toch wel moeilijke concept wat beter uit te leggen, zal ik beginnen met het geven van een figuur.
Agenda
Dating System
GroupDating
AccessControl Wrapper
GroupDating Wrapper
AccessDenied Exceptionhandler
Access Rights & Rules Database
AccessControle Wrapper
Figuur 2.5: Kern Elektronische Agenda
Zoals u in Figuur 2.5 ziet, zijn er 2 wrappers toegevoegd aan het basismodel, namelijk de GroupDating Wrapper en de AccessControle Wrapper. Ik zal eerst de extensie van de groepsafspraken wat nader toelichten. Normaal gezien kan een afspraak slechts plaatsvinden tussen twee personen. Hier kan verandering in worden gebracht door de extensie van de groepsafspraken. Deze extensie kan worden geactiveerd wanneer de klant een afspraak wil maken met meerdere personen tegelijk. Na de activatie kan de klant dan meerdere personen opgeven bij het maken van een afspraak. 15
We zien dat de extensie extra gedrag toevoegt aan het DatingSystem. Wanneer de klant deze extensie geactiveerd heeft en een afspraak wil maken met meerdere personen, gaat elke oproep naar het Datingsystem eerst afgebogen worden naar de GroupDating. Deze kan extra gedrag uitvoeren en op zijn beurt methodes uit het DatingSystem oproepen om het maken van de groepsafspraak tot een goed einde te brengen. Als tweede extensie heb ik hier gekozen voor de AccessControle Wrapper. De bedoeling van deze wrapper is dat er zo aan derden lees- en/of schrijfrecht kan gegeven worden aan je elektronische agenda. Zo kan je zelf bepalen wie wat mag doen in je persoonlijke agenda. Je kan bijvoorbeeld instellen dat je naaste collegas en vrienden kijkrecht hebben, dit wil zeggen dat ze kunnen kijken wanneer je een afspraak hebt en wat deze inhoudt. Het is ook mogelijk om aan enkele personen, bijvoorbeeld je secretaresse of baas, schrijfrecht te geven. Hierdoor kunnen ze zowel afspraken maken in je agenda als wijzigingen toebrengen. Zoals je op Figuur 2.5 kan zien wordt de AccessControle Wrapper rond de Agenda geplaatst. Je kan dus met andere woorden per agenda specifi¨eren wie welke rechten heeft. Deze informatie wordt bewaard in de “Access Rights & Rules Database”. Wanneer iemand probeert een actie in je agenda uit te voeren wanneer dit niet toegelaten is, zal de AccessDenied Exception gegooid worden. Bij de uitwerking van deze korte schets heb ik ervoor gekozen om slechts twee extensies toe te lichten. Dit zou voldoende moeten zijn om de lezer een duidelijk beeld te schetsen wat er bedoelt wordt “extensies” In het eigenlijke ontwerp in Hoofdstuk 4.2 zullen er vier extensies volledig uitgewerkt worden.
16
Hoofdstuk 3 Verkenning van het Terrein door Literatuurstudie extra: geinspireerd door aspect oriented programming/// hierdoor aantal eigenschappen lasagne: p4.2
3.1 3.1.1
Lasagne: Verkenning op abstract niveau Van Spaghetti naar Lasagne
patterns (role, decorator), uitleg lasagne: tangling, scattering, croscutting features, componentenmodel, dynamische binding
3.1.2
Consistentie Management
systeemmanagement: extensies, interceptors-¿deployment, problemen
3.2 3.2.1
Lasagne: Verkenning op niveau van het programmeermodel Een korte introductie tot Correlate
uit boekje doctoraat, heel ruw
3.2.2
Lasagne: wat zit er onder de motorkap
enkele concrete details: extensionIdentifier, interceptor, composition policy, consultation, delegation 17
3.2.3
Ontwerpmethodologi¨ en van Extensies
-¿composition patterns, contracts -¿ +voorbeeldschemas
3.2.4
Related Work
alle andere papers Aspect Oriented Programming -¿kort (max 2 blz) + verschil lasagne aanduiden Composition Filters -¿kort (max 2 blz) + verschil lasagne aanduiden (Eventueel) Bespreking Related work achteraan Lasagne papers
18
Hoofdstuk 4 Ontwerp van Elektronische Agenda: Basisontwerp en Extensies 4.1 4.1.1
Ontwerp van Basisprogramma Ontwerp en Motivatie
-¿+schemas bijzetten
4.1.2
4.2 4.2.1
Moeilijkheden die optraden
Ontwerp van Extensies Mail-Extensie
Ontwerp en Motivatie -¿maak gebruik van composition patterns Moeilijkheiden
4.2.2
Strategie-Extensie
Ontwerp en Motivatie -¿maak gebruik van composition patterns
19
Moeilijkheden
4.2.3
Group-Extensie
Ontwerp en Motivatie -¿maak gebruik van composition patterns Moeilijkheden
4.2.4
Authenticatie-Extensie
Ontwerp en Motivatie -¿maak gebruik van composition patterns Moeilijkheden
4.3
Algemene Problemen
4.4
Evaluatie Ontwerp
-¿doelstelling bereikt?
20
21
Hoofdstuk 5 Implementatie van Elektronische Agenda: Basisontwerp en Extensies 5.1
Implementatie van Basisprogramma
5.1.1
Belangrijke codefragementen
5.1.2
Moeilijkheden
5.2 5.2.1
Implementatie van Extensies Mail-Extensie
Belangrijke codefragmenten Moeilijkheden
5.2.2
Strategie-Extensie
Belangrijke codefragmenten Moeilijkheden
5.2.3
Group-Extensie
Belangrijke codefragmenten Moeilijkheden
5.2.4
Authenticatie-Extensie
Belangrijke codefragmenten Moeilijkheden
22
Hoofdstuk 6 Conclusie 6.1
Doelstelling bereikt?
6.2
Moeilijkheidsgraad ontwikkeling/implementatie
-¿hoe moeilijk is het om zulk een applicatie te ontwerpen en te implementeren
6.3
Persoonlijke Mening
6.4
Conclusie
23
Bibliografie
24
