Dynamisch onderhoud van kritieke applicaties door middel van een reflectief raamwerk

Aanvraag IWT Specialisatiebeurs gedetailleerde beschrijving van het onderzoeksproject

Dynamisch onderhoud van kritieke applicaties door middel van een reflectief raamwerk.

RSITEIT VE BR NI

VRIJ E

SEL US

U

Peter Ebraert

NT

EB

RA

S

S CIE

IA

VIN

E CERE T

N

Departement Informatica Faculteit van de Wetenschappen Vrije Universiteit Brussel

Inhoudstafel 1 Probleemstelling

2

2 Doelstelling

3

3 Projectbeschrijving 3.1 Dynamisch onderhoud van kritieke applicaties . . . . . . . . . 3.1.1 Kritieke applicaties . . . . . . . . . . . . . . . . . . . . 3.1.2 Dynamisch onderhoud . . . . . . . . . . . . . . . . . . 3.1.3 De problematiek in een notedop . . . . . . . . . . . . . 3.2 Gerelateerd Onderzoek . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Scheiding van bekommernissen in software ontwikkeling 3.2.2 Reflectie . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Herstructureringstechnieken . . . . . . . . . . . . . . . 3.3 Het onderzoeksproject . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Parti¨ele gedragsmatige reflectie . . . . . . . . . . . . . 3.3.2 Scheiding van bekommernissen met reflectie . . . . . . 3.3.3 Observeren van programma’s met reflectie . . . . . . . 3.3.4 Aspect ontginning door middel van reflectie . . . . . . 3.3.5 Ontwikkeling en onderhoud door middel van reflectie . 3.4 Onderzoekspunten . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Literatuur studie . . . . . . . . . . . . . . . . . . . . . 3.4.2 Aspect ontginning . . . . . . . . . . . . . . . . . . . . . 3.4.3 Dynamische scheiding van bekommernissen . . . . . . . 3.4.4 Parti¨ele reflectie . . . . . . . . . . . . . . . . . . . . . . 3.4.5 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . 4 Planning 4.1 Tekstueel . . 4.1.1 Deel 1: 4.1.2 Deel 2: 4.1.3 Deel 3: 4.1.4 Deel 4: 4.1.5 Deel 5: 4.1.6 Deel 6: 4.2 Grafisch . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatuurstudie (4 maanden) . . . . . . . . . . . . . . . . Aspect ontginning (14 maanden) . . . . . . . . . . . . . . Dynamische scheiding van bekommernissen (10 maanden) Parti¨ele reflectie (6 maanden) . . . . . . . . . . . . . . . . Evaluatie (5 maanden) . . . . . . . . . . . . . . . . . . . . Conferenties en Rapportering (9 maanden) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

4 4 4 4 5 5 5 6 7 7 7 8 8 9 9 10 10 10 11 11 11

. . . . . . . .

13 13 13 13 13 13 13 13 14

5 Toepassingsmogelijkheden

15

Referenties

16

1

1

Probleemstelling

Een intrinsieke eigenschap van een succesvolle software toepassing is de noodzaak aan evolutie. Om de toepassing actueel te houden, dienen er continu aanpassingen aangebracht te worden, en dienen er nieuwe functionaliteiten toegevoegd te worden. Een belangrijk probleem dat zich hierbij stelt is de beschikbaarheid van de toepassing tijdens het installeren van de allernieuwste versie ervan. De dag van vandaag is het immers zo dat een toepassing moet worden afgesloten vooraleer ze kan geactualiseerd worden, om bijvoorbeeld data corruptie te vermijden. In vele gevallen is dit echter onaanvaardbaar, bijvoorbeeld voor kritische systemen zoals webdiensten, telecommunicatie switches, bankautomaten, enz. Daarenboven heeft het niet beschikbaar zijn van een toepassing onaanvaardbare financi¨ele implicaties voor bedrijven en voor hun positie op de concurrenti¨ele markt. Rekening houdend met de steeds toenemende snelheid waarmee nieuwe versies ontwikkeld worden, kunnen we stellen dat dit probleem alsmaar acuter zal worden. De huidige manier waarop dit probleem aangepakt wordt is door gebruik te maken van redundantie [OC02]. Voor elk (kritiek) systeem wordt een dubbelganger voorzien, die de functies van het oorspronkelijke systeem kan overnemen indien dat tijdelijk niet beschikbaar is. Het moge duidelijk wezen dat deze oplossing allesbehalve bevredigend is. Eerst en vooral is er het financi¨ele plaatje: alle hardware en software dient in veelvoud aangeschaft te worden. Verder is het zo dat dergelijke redundante systemen hun eigen problemen kennen: het beheren van verschillende versies wordt bemoeilijkt, alsook het onderhoud en omschakelen tussen de redundante systemen. Een meer ideale oplossing voor dit probleem zou erin bestaan om toepassingen te ontwikkelen volgens het principe van het scheiden van bekommernissen [Dij68]. Elke verschillende bekommernis die door de toepassing geadresseerd wordt, bestaat dan als een aparte entiteit, die los van alle andere entiteiten kan aangepast en vervangen worden. Indien dit het geval is, kan deze entiteit zelfs vervangen worden tijdens de uitvoering van de toepassing, zodat deze steeds beschikbaar blijft. In de praktijk blijkt echter dat dit principe van scheiding van bekommernissen bijzonder moeilijk te realiseren valt. Hoewel er reeds een paar experimentele technieken bestaan die dit principe ondersteunen, worden deze nog al te vaak niet aangewend. Het overgrote deel van de hedendaagse toepassingen is dus simpelweg een verzameling van sterk verweven bekommernissen. Verder is het zo dat deze huidige technieken nog steeds te statisch zijn om dynamisch onderhoud in de praktijk te ondersteunen. Ze voorzien immers een model waarbinnen de gescheiden bekommernissen op voorhand vastgebakken worden in de toepassing [Szy98, Hyp, Asp, AT98]. Dit verhindert het wijzigen ervan tijdens de uitvoering van de toepassing. Initi¨ele prototypes van meer dynamische technieken bestaan reeds [DSC, Pro], maar ontberen een degelijk en wetenschappelijk onderbouwd model, wat ze niet toepasbaar maakt in een brede en realistische context.

2

2

Doelstelling

Het doel van ons onderzoek is een oplossing te voorzien voor het probleem van de beschikbaarheid van toepassingen tijdens hun evolutie. Zoals reeds besproken in de probleemstelling dienen we twee fundamentele problemen op te lossen om continu aanpasbare software te verkijgen. Enerzijds zullen we ervoor moeten zorgen dat de toepassingen voldoen aan het principe van scheiding van bekommernissen, anderzijds zullen we technieken voor het dynamisch toepassen van dit principe ontwikkelen of reeds bestaande experimentele technieken uitbreiden. Concreet stellen we voor om reflectie te gebruiken als onderliggende techniek om beide problemen aan te pakken. We motiveren dit in het vervolg van de tekst. Huidige toepassingen voldoen vaak niet aan het principe van scheiding van bekommernissen. Nochtans is dit een absolute vereiste om toepassingen dynamisch te kunnen actualiseren. Daarom willen we nagaan in hoeverre we bekommernissen in een reeds bestaande toepassing automatisch kunnen identificeren en hoe we deze toepassing dan kunnen veranderen zodat alle bekommernissen netjes gescheiden zijn. We kunnen dit realiseren door het dynamisch gedrag van een toepassing te observeren en hieruit af te leiden welke delen sterk/zwak verbonden zijn, welke communicatiepatronen vaak voorkomen, etc. Het is duidelijk dat reflectie – berekeningen over berekeningen [Tan02] – hierbij een absolute noodzaak is. Onderzoek in dit domein, dat aspect ontginning wordt genoemd, is pas recent opgestart. Hoewel de abstracte resultaten veelbelovend zijn, laten concrete resultaten nog op zich wachten. Eens we de bekommernissen ge¨ıdentificeerd hebben, dienen we de toepassing zelf nog te herstructureren zodat deze de bekommernissen expliciet maakt. Hierbij denken we aan het gebruik van geavanceerde herstructureringstechnieken (eng. refactorings) [Fow99], die ons in staat stellen de interne structuur van een toepassing aan te passen zonder het gedrag ervan te be¨ınvloeden. Meer dan waarschijnlijk dienen bestaande herstructureringstechnieken uitgebreid te worden met de notie van gescheiden bekommernissen. Om het mogelijk te maken bekommernissen dynamisch te wijzigen en te vervangen door nieuwe versies, zullen we tevens onderzoeken hoe we dynamische ondersteuning kunnen voorzien voor het scheiden van bekommernissen. Zoals reeds gesteld voorzien huidige technieken enkel in een statische ondersteuning. Ook hier stellen wij reflectie voor als een oplossing voor dit probleem. Eens dit alles gerealiseerd dienen we na te gaan in hoeverre het gebruik van reflectie de performantie van de resulterende toepassing be¨ınvloedt. Een algemeen erkend nadeel van reflectie is immers dat dit een negatieve invloed heeft op de performantie. We zullen dit trachten te minimaliseren door gebruik te maken van parti¨ele reflectie [H.90]. Hierdoor kunnen we precies aangeven welke entiteiten reflectief dienen te zijn, en kunnen we aldus een betere performantie garanderen. Een studie van de wisselwerking tussen de benodigde flexibiliteit en effici¨entie, en de optimalisatie ervan, maakt dus ook deel uit van ons onderzoek.

3

3 3.1

Projectbeschrijving Dynamisch onderhoud van kritieke applicaties

Eerst zullen we wat dieper ingaan op de abstracte visie van het probleem zoals aangekaart in de probleemstelling. Daarna geven we een korte conclusie om bondig te herhalen wat het probleem juist inhoudt. 3.1.1

Kritieke applicaties

Kritieke applicaties zijn applicaties die een dienst aanbieden die niet onderbroken mag worden. Denk maar aan de switches in de telecommunicatie, de router van een lokaal netwerk, de servers van BankSys – die het betalen per bankkaart aanbieden – het systeem dat de lucht toevoer in een ruimtestation beheert, de web diensten die een bedrijf aanbiedt om zijn producten te verkopen, enz. Daar dat soort diensten continu in gebruik moeten zijn en dat – afhankelijk van om welke specifieke toepassing en onderhoud het gaat – een onderhoud vaak verlangt dat de diensten stopgezet worden, moeten er speciale technieken aangewend worden om deze systemen te onderhouden. Vandaag de dag wordt dit gedaan door redundantie waarin een systeem voorzien wordt van een dubbelganger die de dienst van het kritieke systeem overneemt wanneer dit stopgezet wordt. Jammer genoeg heeft deze oplossing verschillende nadelen waarvan we er enkele noemen. Eerst en vooral brengt deze oplossing een extra financi¨ele kost met zich mee die niet te verwaarlozen is. De prijs van het gehele systeem is dan immers een veelvoud van de oorspronkelijke prijs. Ten tweede is het beheer van zo’n redundant systeem complex. Er moet immers een mechanisme in staat zijn om om te schakelen tussen de dubbelgangers wanneer er ´e´en van hen uit valt. Een derde probleem is het versie beheer van de verschillende dubbelganger systemen. Indien we het systeem up to date wensen te brengen, moeten we de dubbelgangers ´e´en voor ´e´en gaan onderhouden, wat uiteraard ook een meerkost met zich meebrengt. 3.1.2

Dynamisch onderhoud

Een belangrijk software engineering principe, dat reeds veel aandacht geniet in de objectgeori¨enteerde onderzoekswereld, is het principe van het “scheiden van bekommernissen”. De reden waarom dit recent aan belang toenam, ligt aan het feit dat het de onderhoudbaarheid en evolueerbaarheid, maar ook de ontwikkeling van software systemen ten goede komt. Het principe van scheiding van bekommernissen werd voor het eerst ge¨ıdentificeerd door Dijkstra [Dij76] en geeft weer dat het voor mensen moeilijk is om zich op meerdere bekommernissen tegelijkertijd te concentreren en in een ideale situatie worden deze bekommernissen dan ook afzonderlijk van elkaar behandeld. Het is immers belangrijk dat bekommernissen afzonderlijk kunnen evolueren zonder dat dit grote gevolgen heeft voor andere bekommernissen. In de ontwikkeling van kritieke software moeten we er ons van verzekeren dat de verschillende bekommernissen ook hier gescheiden worden. De aanpassing van de veiligheid mag bijvoorbeeld geen impact hebben op de structurering van de informatie of de user interface. Op die manier kunnen we dan ´e´en specifieke bekommernis afscheiden van de rest van het systeem, aanpassen, en terug in pluggen in het actieve systeem. 4

3.1.3

De problematiek in een notedop

In dit onderzoeksproject concentreren we ons op de problematiek van het onderhoud van kritieke software. We gaan ervan uit dat alle soorten software onderhouden moeten worden, en dat – afhankelijk van welk soort onderhoud en toepassing – dit onderhoud vaak verlangt dat het systeem wordt stopgezet. Het probleem is dat kritieke systemen niet zomaar mogen stopgezet worden daar ze diensten aanbieden die vaak levensbelangrijk zijn. Daarvoor moeten we voorzien in een mechanisme om dynamisch onderhoud toe te staan; een onderhoud terwijl de software actief is.

3.2 3.2.1

Gerelateerd Onderzoek Scheiding van bekommernissen in software ontwikkeling

Er zijn reeds enkele bestaande technieken voorhanden die scheiding van bekommernissen in het algemeen ondersteunen. Naast een aantal triviale abstracties, zoals modulaire en procedurele abstractie, sommen we hier de twee modernste technieken ter verkrijgen van scheiding van bekommernissen op. Het gaat over component gebaseerde ontwikkeling en aspect geori¨enteerd programmeren. 3.2.1.1 Componenten In [Szy98] definieert Szyperski components als computationele entiteiten die gemakkelijk aan een systeem toegevoegd kunnen worden, om vervolgens hun ‘werk’ te doen. Het gebruik van componenten leidt tot makkelijk uitbreidbare en evolueerbare systemen. Voor elke bekommernis kan een aparte component voorzien worden, en zodoende worden de bekommernissen van elkaar gescheiden omdat de components van elkaar gescheiden zijn. Om tot een werkende applicatie te komen worden de components, en dus de bekommernissen, aan elkaar gekoppeld. 3.2.1.2 Aspect geori¨ enteerd programmeren Aspect geori¨enteerd programmeren is een reeds vrij ver ge¨evolueerde techniek om een scheiding van bekommernissen te bewerkstelligen [KLM+ 97]. Er wordt een onderscheid gemaakt tussen een basisbekommernis of ook het basissysteem, en een aantal bijkomende bekommernissen, in dit geval aspecten genoemd. Voorbeelden van aspecten zijn foutenbehandeling, optimalisatie, persistentie, concurrentie en distributie. Karakteristiek voor deze aspecten (en wat ze verschillend maakt van componenten) is dat ze systeem verspreid zijn. Zo is distributie bijvoorbeeld een aspect waar we relatief ge¨ısoleerd kunnen over redeneren, maar wat technisch gezien ‘overal’ in de code aanwezig is. Het is onmogelijk een ‘component’ of ‘module’ voor distributie te ontwikkelen. Daarom noemt men het een aspect. Het doorsnijdt als het ware alle andere componenten van het systeem. Aspect geori¨enteerd programmeren is een recent programeerparadigma en stelt een programmeeromgeving voor waar verschillende aspecten in aspecttalen uitgedrukt worden, en waar het basissyteem in een klassieke programmeertaal ge¨ımplementeerd wordt. De programmeur kan zich om de verschillende aspecten ´e´en voor ´e´en bekommeren. Het basissysteem wordt met de aspecten ge¨ıntegreerd door middel van een wever, met als resultaat 5

een programma in de programmeertaal van het basissysteem waarin de ‘aspect instructies’ tussen de basisinstructies verweven zitten in het hele systeem. Dit programma kan dan via de compiler of interpreter van die taal uitgevoerd worden. 3.2.2

Reflectie

Een alternatief voor de bovenvermelde benaderingen voor het scheiden van bekommernissen is reflectie. Bovendien zullen we zien dat reflectie nog heel wat meer in huis heeft dan alleen een scheiding van bekommernissen. 3.2.2.1 Definitie Reflectie in programmeertalen is een paradigma dat het daglicht zag in de studies van Brian Smith rond de fundering van het zelfbewustzijn en de zelfreferentie, alsook in zijn werk rond de toepassing van deze concepten in de computer wetenschappen, en de implementatie van een reflectief Lisp dialect [Smi84]. Deze idee¨en werden vervolgens toegepast op een aantal programmeerparadigmas, zoals het object ge¨orienteerd programmeren [Mae87], en had een enorme impact op talen zoals CLOS [KDRB91] of Smalltalk [Riv96]. In een object ge¨orienteerde taal wordt reflectie verzorgd door een metaobject protocol (MOP), hetwelk een object ge¨orienteerde interface vormt naar de implementatie van die taal [KDRB91]. Het doel van reflectie is de ondersteuning van meta-berekeningen (berekeningen over berekeningen). Dat gebeurt door de meta-berekeningen en basisberekeningen te scheiden in twee niveaus, het basis en het meta-niveau. Beide niveaus worden causaal verbonden. Dat betekent dat langs ´e´en kant het reflectief programma vanuit zijn basisniveau toegang heeft tot zijn representatie op het meta-niveau en dat, langs de andere kant, een verandering in die representatie een impact heeft op het gedrag van dat programma op het basis niveau. Deze causale connectie is de basis-eigenschap van reflectie. Afhankelijk van welk deel van de representatie geraadpleegd wordt, het deel dat de (statische) structuur beschrijft, of het deel dat het (dynamische) gedrag beschrijft wordt de reflectie structureel of gedragsmatig genoemd. Een andere opsplitsing wordt gemaakt tussen introspectie, wanneer de representatie alleen geraadpleegd wordt, en intercessie, wanneer de representatie ook gewijzigd wordt. 3.2.2.2 Toepasbaarheid van gedragsmatige reflectie In dit onderzoeksproject zullen we focussen op gedragsmatige reflectie, die voorzien wordt door de zogehete runtime MOPs. De grootste sterkte van gedragsmatige reflectie is dat ze kan aangewend worden om een scheiding van bekommernissen te implementeren [Dij68, Par72], inclusief dynamische bekommernissen, en zo een modulaire ondersteuning geven voor aanpassingen in software systemen [BCA+ 00, RC02]. Deze krachten werden reeds uitgebuit in een aantal domeinen, zoals gedistribueerde systemen [McA95, CKV98], mobiele objecten [LBS00, TVP02, BCA+ 00], concurrente systemen [MMY94] en in fout-tolerante systemen [FNP+ 95]. De toepasbaarheid van gedragsmatige reflectie is echter gelimiteerd door het gebrek aan infrastructuur om reflectieve systemen te implementeren doch wordt hier aan gewerkt [TNCC03, Ebr03]. Ook de extra kosten (op gebied van prestaties) die reflectie

6

met zich meebrengt hebben een negatieve weerslag op de toepasbaarheid ervan. Daardoor wordt het noodzakelijk om te kunnen preciseren waar en wanneer we reflectie willen toepassen. Dit heet parti¨ele reflectie [H.90]. Parti¨ele reflectie maakt het mogelijk om een evenwicht te vinden tussen compilatie, hetgeen een set van veronderstellingen inhoudt (een specialisatie) en reflectie, hetgeen enkele van die veronderstellingen wegneemt (een generalisatie). Vele talen ondersteunen een soort parti¨ele reflectie, waar de gebruiker kan kiezen welke entiteiten reflectief zijn en welke niet (Smalltalk [FJ89, Duc99, Riv97], C++ [GC96, Chi95], Java [CM93, WS99, RC00, TVP02, McA95]). 3.2.3

Herstructureringstechnieken

Vele ontwerpmethoden werden reeds voorgesteld in het verleden met als doel goede principes voor object geori¨enteerde software ontwikkeling te promoten. Terzelfder tijd is er veel onderzoek gebeurd naar het identificeren van software herstructureringen die ons kunnen helpen om een slecht ontworpen systeem om te zetten in een beter, meer flexibel systeem. Ze stellen ons immers in staat om de interne structuur van een toepassing aan te passen zonder het gedrag ervan te be¨ınvloeden. Op PROG voert men actief onderzoek naar geautomatiseerde technieken voor herstructurering [TMB02, TM03] en de aanwezige kennis zal dus tevens van nut kunnen zijn voor dit onderzoeksproject. Maar in de bestaande technieken werd tot nu toe nog geen rekening gehouden met de notie van scheiding van bekommernissen. We zullen die technieken dan ook aanpassen waar nodig zodat ze ook deze notie in rekenschap kunnen brengen.

3.3 3.3.1

Het onderzoeksproject Parti¨ ele gedragsmatige reflectie

In [McA96] onderscheidt J. McAffer twee benaderingen van reflectie: startende van de elementen van het basis niveau (bvb. klassen) of van de basis operaties (bericht zenden of ontvangen, veld raadpleging, object creatie, enz.) die een gedrag defini¨eren van een object. Hij refereert naar deze twee benaderingen respectievelijk als de top-down en de bottomup benadering. Eigenlijk zou men er ook naar kunnen verwijzen als de structurele en de gedragsmatige benadering. J. McAffer verantwoordt het gebruik van de tweede benadering in een context waar hij ge¨ınteresseerd is in het beschrijven van het object gedragsmodel – een re¨ıficatie. Aangezien wij ge¨ınteresseerd zijn in gedragsmatige reflectie nemen we dit als startpunt van ons onderzoek. Het meta-niveau is gestructureerd in meta-objecten die redeneren en handelen over re¨ıficaties van basis niveau berekeningen die omschreven worden als operaties. Het voorkomen van zo’n operatie refereert naar een bepaalde instantie van een operatie die vervolgens geklasseerd kan worden als statisch of dynamisch, naargelang de operatie respectievelijk verwijst naar de programma tekst of de uitvoering. De benadering van parti¨ele gedragsmatige reflectie die wij wensen te ontwikkelen is een benadering van een veel effici¨entere en gemakkelijker toepasbare parti¨ele gedragsmatige reflectie die berust op het vermijden van nutteloze re¨ıficaties. Om dat te verwezenlijken moet het specifi¨eren van de reflective noden zeer flexibel zijn. Parti¨ele gedragsmatige reflectie adresseert de flexibiliteit versus effici¨entie door het aantal controle verschuivingen te 7

beperken. Verschuiven naar het meta-niveau is immers krachtig maar duur. Zo’n verschuiving bestaat uit eerst het reifi¨eren van de basis operatie instantie en dan het delegeren van de interpretatie naar het meta-object. Re¨ıficatie is een belangrijke oorzaak van prestatie verlies. Vanuit het effici¨entie oogpunt is het daarom cruciaal om het aantal verschuivingen te beperken en zo de prijs van de re¨ıficatie alleen te betalen wanneer het echt nodig is. We kunnen twee dimensies onderscheiden bij het selecteren van re¨ıficaties: de ruimtelijke en de tijdelijke. De ruimtelijke dimensie duidt op het feit dat we precies kunnen specifi¨eren welke entiteiten reflectief zullen zijn en welke niet. De tijdelijke dimensie bestaat uit het selecteren wanneer re¨ıficaties effectief actief zijn. Zo kunnen we een reflectief systeem maximaal optimiseren. De verwante idee¨en en technieken zouden toepasbaar zijn op een groot gamma van object ge¨orienteerde talen, maar wij gaan focussen op Smalltalk daar die taal de flexibiliteit biedt die we nodig achten om de gewenste functionaliteiten aan te kunnen bieden. 3.3.2

Scheiding van bekommernissen met reflectie

Vandaag de dag laat standaard object geori¨enteerde software ontwikkeling ons niet toe om verweven bekommernissen (Eng. crosscutting concerns) op een nette manier te scheiden. Verweven bekommernissen zijn een bepaald soort bekommernissen die verweven zitten op verschillende plaatsen op het basis niveau. Typische voorbeelden hiervan zijn logging, veiligheid, fout behandeling (Eng. error handling), opgelegde ontwikkeling-standaarden, enz. Zoals reeds gesteld in de vorige sectie, bestaan er reeds enkele technieken die de scheiding van ook die bekommernissen toelaten. We noemden de ontwikkeling door middel van componenten, aspect geori¨enteerd programmeren en reflectie. In een reflectief systeem wordt er typisch een onderscheid gemaakt tussen het basis- en meta-niveau. Reflectie – in de ruime zin van het woord – laat ons toe om een programma op basis-niveau te observeren (introspectie) en het eventueel aan te passen (intercessie). Die observaties en aanpassingen worden ge¨ımplementeerd op het meta-niveau. De causale verbinding tussen het basis- en het meta-niveau laat ons toe om de verschillende bekommernissen gescheiden te implementeren op het meta-niveau en ze vanuit het basis-niveau programma aan te roepen op de juiste momenten. Het nadeel van deze benadering ligt in de extra kost die reflectie met zich meebrengt. De omschakelingen tussen basis- en meta-niveau vertragen immers aanzienlijk de uitvoering van toepassingen. Zoals reeds gesteld, kunnen we dankzij de ruimtelijke en tijdelijke dimensies van parti¨ele reflectie het aantal omschakelingen tot het absolute minimum beperken. op die manier kunnen we het grootste nadeel van reflectie enorm beperken, wat deze benadering uiteraard ten goede komt. 3.3.3

Observeren van programma’s met reflectie

Reflectie kan ook aangewend worden om een programma op basis niveau te observeren. Eerst en vooral moet de gebruiker specifi¨eren welke delen van de basis applicatie hij wenst te observeren. Dit gebeurt in de configuratie van het reflectief raamwerk. Hierdoor is het mogelijk om precies te controleren welke delen van het systeem en welke operatie

8

instanties geobserveerd zullen worden. Ook op welk tijdstip de basis entiteiten geobserveerd worden kan op die manier geconfigureerd worden. Bijvoorbeeld kan een gebruiker kiezen dat een bepaald deel moet geobserveerd worden indien een dynamisch ge¨evalueerde activatie conditie waar is. Deze preciseringen laten de ons toe om alleen de facetten dewelke ons interesseren te observeren. 3.3.4

Aspect ontginning door middel van reflectie

Het idee is om op meta-niveau de nodige architecturale en domein-kennis uit te drukken [D’H02]. Een applicatie op meta-niveau zal dan een lopende basis-niveau applicatie observeren en de domein-specifieke kennis aanwenden om die applicatie te analyseren [DW99]. Dit moet leiden tot de ontdekking van verborgen verweven bekommernissen. De applicatie op meta-niveau kan in tweede instantie aangewend worden om de nodige veranderingen automatisch aan te brengen in de basis-niveau applicatie. Om deze herstructureringen tot stand te brengen zijn er reeds enkele technieken voorhanden. De Refactoring Browser [Ref] is een Smalltalk grasduiner die reeds enkele automatische herstructureringen toelaat. Bovendien is hij open bron en wordt hij nog constant uitgebreid om nieuwe herstructureringen mogelijk te maken. Declaratief Meta Programmeren (DMP) is een recent multi-programmeer paradigma ontwikkeld op het Programming Technology Laboratory van de VUB (PROG) [Wuy01]. Daar wordt een declaratieve meta-laag gebruikt wordt om te redeneren over en het manipuleren van programmas geschreven in een onderliggende basis-laag taal [DDVMW00]. In recent onderzoek werd dit principe reeds aangewend om herstructureringen waar te maken [TDM99, TMB02, TM03]. Wij stellen voor om de theori¨en achter deze benaderingen te analyseren en ze uit te breiden om ook de detectie van verwoven bekommernissen toe te laten. 3.3.5

Ontwikkeling en onderhoud door middel van reflectie

Typisch bestaat het leven van kritieke systemen – en software in het algemeen – uit twee grote delen: de ontwikkeling en het onderhoud. In software ontwikkeling is de scheiding van bekommernissen een absolute must geworden. Het reflectief raamwerk zal toelaten dat alle soorten bekommernissen gescheiden kunnen worden. Op die manier zal het een kwaliteitsvolle ontwikkeling van software toelaten. Reflectieve raamwerken werden reeds aangewend om in een statisch onderhoud te voorzien. De resultaten dan die studies [TBN01, ET03] vormen een duidelijke indicatie dat ook een dynamisch onderhoud mogelijk is met datzelfde soort raamwerken. Doch is dit ´e´en stap verder en zal dat alleen mogelijk zijn indien het raamwerk dynamische intercessie implementeert. Indien dat het geval is kunnen we het meta-niveau aanwenden om alle entiteiten (klassen, methoden, velden, bepaalde instanties, enz.) op het basis-niveau te manipuleren terwijl deze actief zijn. Een gevolg is dat we dan zowel de structuur als het gedrag van het programma op basis-niveau kunnen aanpassen, om zo het programma te onderhouden zonder het stop te zetten. Toch moet meer onderzoek aantonen hoe we de extra problemen, die dit dynamisch onderhoud met zich meebrengt, zullen oplossen. Denk maar aan de processen die actief zijn terwijl we de updates effectief doorvoeren in het systeem. 9

3.4

Onderzoekspunten

In dit onderzoeksproject willen we een raamwerk ontwikkelen dat het onderhoud van kritieke software toelaat terwijl deze diensten actief zijn. Om dit te verwezenlijken moeten we er echter voor zorgen dat die software op een goede manier ontwikkeld werd en de verschillende bekommernissen op een nette manier gescheiden werden. Is dit niet gebeurd, dan moeten we die bekommernissen ontginnen uit de bestaande applicatie, en die afzonderen. Zo valt dit project eigenlijk uiteen in drie grote delen: aspect ontginning om de bekommernissen te ontdekken, herstructureren van die applicaties om de bekommernissen te scheiden en het dynamisch onderhouden om de programma’s niet stop te moeten zetten voor een onderhoud te verwezenlijken. Het te ontwikkelen raamwerk zal ons bijstaan om elk van deze delen tot een goed einde te brengen. 3.4.1

Literatuur studie

Dit deel omvat de ontwikkeling van gevorderde vaardigheden in Smalltalk; de programmeertaal in dewelke we het raamwerk gaan ontwerpen. Basisvaardigheden in het Smalltalk programmeren werden reeds verworven in de master opleiding die ik vorig studiejaar volgde. Toch wensen we te – daar elke programmeertaal zijn limitaties heeft – bestuderen wat er allemaal mogelijk is en wat niet. Dankzij het feit dat er reeds heel wat Smalltalk ervaring aanwezig in de onderzoeksgroep PROG kan er op hun deskundigheid gerekend worden om dit proces te versnellen. Van het moment dat de vaardigheden volledig onder de knie zijn, kunnen we ons toe gaan leggen op de studie wat er reilt en zeilt in de onderzoekswereld op gebied van aspect ontginning, de dynamische scheiding en de parti¨ele reflectie, die we gaan aanwenden om de vorige twee te implementeren. Het spreekt vanzelf dat dit deel doorheen heel het onderzoeksproject zal plaats vinden, maar dat het vooral in het begin veel tijd zal vergen. 3.4.2

Aspect ontginning

In dit deel gaan we de bestaande theorie¨en ter ontginning van programma informatie bestuderen en vergelijken. We denken hier vooral aan de theorie¨en achter de Refactoring Browser [Ref] en achter het automatisch herstructureren door middel van DMP [TMB02]. Er zijn recent twee onderzoeksprojecten opgestart in Duitsland [Pas]en Nederland [SWE] waarmee een samenwerking op til is. Er werden reeds stappen gezet om deze samenwerking – die logischerwijs alle partijen ten goede komt – te concretiseren. Concreet gezien stellen wij voor dat een applicatie op meta niveau de applicatie op basis niveau analyseert. Deze analyse moet leiden tot een lijst van verschillende bekommernissen die niet volledig gescheiden waren in de basis applicatie. Dan gaan we programma transformaties suggereren en eventueel geautomatiseerd uitvoeren op de basis niveau applicatie. Deze transformaties zullen leiden tot een applicatie met gescheiden bekommernissen, die gemakkelijker te onderhouden is dan voordien, ´en die hetzelfde gedrag behoudt als voordien.

10

3.4.3

Dynamische scheiding van bekommernissen

Wanneer de verschillende bekommernissen allemaal gescheiden zijn in een applicatie, kunnen we deze applicatie dynamisch gaan onderhouden door middel van dynamisch aspect geori¨enteerd programmeren. Hiervoor bestaan reeds een aantal benaderingen zoals Prose [Pro] en EAOP [DSC]. Deze benaderingen en de basis waarop ze berusten zijn echter zeer experimenteel. Doch zullen we deze benaderingen bestuderen en de functionaliteiten die ze bieden als vereisten beschouwen in onze benadering. Vervolgens gaan we bekijken hoe we reflectie zullen aanwenden om een dynamische scheiding van bekommernissen te realiseren. Het idee is dat we het te ontwikkelen raamwerk aanwenden om dit waar te maken. Op het basis-niveau bevindt zich een applicatie waarin de verschillende bekommernissen netjes gescheiden zijn. Wanneer we het systeem willen aanpassen, nemen we ´e´en voor ´e´en de code van de specifieke bekommernissen waarop die aanpassingen effect hebben en wijzigen die modules. Wanneer de nieuwe bekommernis houdende modules klaar zijn, moeten deze ´e´en voor ´e´en aan het systeem toegevoerd worden om zo de aanpassingen door te voeren in het lopende systeem. 3.4.4

Parti¨ ele reflectie

Zoals reeds gesteld willen we door middel van een parti¨ele reflectie de extra kost die reflectie met zich meebrengt, zoveel mogelijk beperken. Recent zagen een aantal implementaties voor parti¨ele reflectie het leven, bijvoorbeeld Strongtalk voor Smalltalk, Reflex en Iguana/j voor Java. In dit deel gaan we de gekende implementaties van parti¨ele reflectie bestuderen en zien hoe we ze kunnen aanwenden om ons raamwerk te ontwikkelen. Daar ons raamwerk in Smalltalk ontwikkeld zal worden, gaat Strongtalk mogelijkerwijs een grondige basis vormen voor het raamwerk. Er dient ook nagegaan te worden welke andere implementaties er reeds op de markt zijn, op welke vlakken ze een oplossing bieden voor parti¨ele reflectie en hoe we deze kunnen aanwenden in de ontwikkeling van ons raamwerk. Een vergelijking van de bestaande implementaties moet aantonen waar ze tekort schieten in het vervullen van het beoogde doel: de extra kost die reflectie met zich mee brengt minimaliseren. Die kennis zal dan gebruikt worden om het nieuwe raamwerk te ontwerpen en te implementeren. 3.4.5

Evaluatie

Om te testen of onze benaderingen effectief doen wat ze beogen te doen, gaan we enkele bestaande industri¨ele applicaties nemen en hieruit de bekommernissen ontginnen, ze transformeren en daarna nagaan of of deze applicaties wel degelijk nog steeds hetzelfde gedrag vertonen. Op die manier kunnen we onze benadering voor aspect ontginning testen. Eventueel kan het raamwerk bijgestuurd worden. Daar dit onderzoeksproject uiteindelijk het dynamische onderhoud van kritieke applicaties beoogt, is de validatie van het deel dat dit mogelijk maakt een belangrijk deel van dit project. Door enkele echte applicaties te observeren en aan te passen, kunnen we testen hoe het raamwerk een dynamisch onderhoud toelaat. In het kader van het ARRIBA project [ARR] werden er reeds contacten gelegd met enkele organisaties (Banksys, KBC en 11

de Christelijke Mutualiteit) die allen kritieke software gebruiken. Zij zullen een deel van hun bron code ter beschikking stelen om onze benadering te verifi¨eren.

12

4 4.1 4.1.1

Planning Tekstueel Deel 1: Literatuurstudie (4 maanden)

(A) Reflectief programmeren in Smalltalk: 1 maand (B) Studie van de state of the art van deel 2, 3 en 4: 3 maanden 4.1.2

Deel 2: Aspect ontginning (14 maanden)

(C) Gekende methodologi¨en bestuderen en vergelijken: 4 maanden (D) Reflectie aanwenden om aspecten te ontginnen: 6 maanden (E) Een adequate herstructureringsmethode testen en aanpassen ter ondersteuning van de scheiding van bekommernissen: 4 maanden 4.1.3

Deel 3: Dynamische scheiding van bekommernissen (10 maanden)

(F) Gekende benaderingen bestuderen en vergelijken: 3 maanden (G) Reflectie aanwenden om dynamisch bekommernissen te scheiden: 7 maanden 4.1.4

Deel 4: Parti¨ ele reflectie (6 maanden)

(H) Ontwerp en ontwikkeling raamwerk: 6 maanden 4.1.5

Deel 5: Evaluatie (5 maanden)

(I) Ontginning van bekommernissen uit bestaande applicaties: 2 maanden (J) Dynamische onderhoud van bestaande applicaties: 3 maanden 4.1.6

Deel 6: Conferenties en Rapportering (9 maanden)

(K) Conferenties: 2 maanden (L) Rapportering: 1 maand (M) Schrijven Doctoraat : 6 maanden

13

4.2

Grafisch

14

5

Toepassingsmogelijkheden

Het beoogde reflectief raamwerk laat toe een propere scheiding van alle soorten bekommernissen te realiseren. Dat dit kon voor het programma effectief gestart werd is niet nieuw, maar dit raamwerk laat ook toe om dynamisch bekommernissen te scheiden. Op die manier kunnen we een nieuwe bekommernis introduceren in een bestaand systeem dat actief is. Ook kunnen we programma’s die actief zijn, observeren. Zowel introspectie (observeren van het programma) als intercessie (aanpassen van het programma) worden mogelijk gemaakt door het raamwerk. Op die manier kunnen we het gedrag van een programma beter analyseren en eventuele abnormaliteiten detecteren en corrigeren. Door de evolutie van een applicatie kunnen er vaak fouten qua ontwerp in een applicatie sluipen, die verdere evolutie zou vermoeilijken. Zulke fouten kunnen ook gedetecteerd en eventueel gecorrigeerd worden op een transparente manier. Concreet laat dit principe ons toe om een applicatie te onderhouden terwijl deze actief is. Ze moet niet meer uit dienst gehaald worden, wat voor kritieke software noodzakelijk is. Zoals gezegd richtten we ons in dit project vooral op kritieke software, die constant actief moet zijn, zelfs tijdens het onderhoud. Verschillende partners in het ARRIBA project [ARR] (Banksys, KBC en de Christelijke Mutualiteit) gebruiken zulke kritieke software. Zij zullen ons hun bron code ter beschikking stellen, waardoor we een echte case study kunnen maken. Er zijn echter nog een aantal andere systemen waar een onderhoud. Het SEESCOA project [SEE] bestudeert embedded systemen. Ook die programma’s kunnen meestal niet zomaar stil gelegd worden om een onderhoud te verwezenlijken. Ook het onderhoud van gedistribueerde applicaties (zoals air traffic control, telecommunicatie en andere) vormt een probleem dat we door middel van dit raamwerk kunnen aanpakken. De doelstelling van het ARRIBA project, dat vorig jaar opgestart werd, bestaat erin onderzoek te verrichten naar methodes om grote, sterk evoluerende softwaresystemen te herstructureren en te integreren. Vooral in oude systemen is overgaan tot moderniseren erg moeilijk door bijkomende factoren zoals de complexiteit en de grootte van de software. Ook in die systemen is het probleem dat door hun grootte en complexiteit blijkt dat het erg moeilijk is om tot moderniseren over te gaan. Wij beweren dat de voorgestelde benadering kan aangewend worden net om de complexiteit van die systemen te verminderen. De complexiteit van die systemen wordt immers mede veroorzaakt door een slechte scheiding van bekommernissen. Bovendien wordt de scheiding van bekommernissen nog extra bemoeilijkt in grootte bedrijven, daar de interne bedrijfsstructuur vaak de systeem architectuur weerspiegelt. Na het scheiden van de bekommernissen zal de complexiteit van deze systemen verminderen, wat de mogelijkheid om tot modernisering over te gaan uiteraard ten goede zal komen.

15

Referenties [ARR]

Arriba project, http://progwww.vub.ac.be/project.htm.

[Asp]

AspectJ, http://aspectj.org.

[AT98]

M. Ak¸sit and B. Tekinerdo˘gan, Aspect-oriented programming using composition filters, Object-Oriented Technology, ECOOP’98 Workshop Reader (S. Demeyer and J. Bosch, eds.), Springer Verlag, July 1998, p. 435.

[BCA+ 00]

G.S. Blair, G. Coulson, A. Andersen, L. Blair, M. Clarke, F. Costa, H. Duran, N. Parlavantzas, and K. Saikoski, A principled approach to supporting adaptation in distributed mobile environments, Symposium on Software Engineering for Parallel and Distributed Systems (2000).

[Chi95]

S. Chiba, A metaobject protocol for c++, Proceedings of ACM Conference on Object-Oriented Programming Systems, Languages, and Applications 30 (1995), 285–299.

[CKV98]

D. Caromel, W. Klauser, and J. Vayssiere, Towards seamless computing and metacomputing in java, Concurrency Practice and Experience 10 (1998).

[CM93]

S. Chiba and T. Masuda, Designing an extensible distributed language with a metalevel architecture, Proc. of the 7th European Conference on ObjectOriented Programming, vol. 707, Springer-Verlag, 1993, pp. 482–501.

[DDVMW00] Theo D’Hondt, Kris De Volder, Kim Mens, and Roel Wuyts, Co-evolution of object-oriented software design and implementation, SACT Symposium Proceedings, Kluwer Academic Publishers, 2000. [D’H02]

M. D’Hondt, Explicit domain knowledge in software applications, In the Doctoral Symposium at the International Conference on Software Engineering (Orlando, Florida, USA), 2002.

[Dij68]

E. Dijkstra, The structure of THE multiprogramming system, Communications of the ACM 11 (1968), 341–346.

[Dij76]

E.W. Dijkstra, A discipline of programming, Prentice-Hall, 1976.

[DSC]

R´emi Douence, Mario S¨ udholt, and Pierre Cointe, A testbed for the design and implementation of aspect-oriented programming.

[Duc99]

S. Ducasse, Evaluating message passing control techniques in smalltalk, Journal of Object-Oriented Programming (1999), 39–50.

[DW99]

De Meuter W. D’Hondt, M. and R. Wuyts, Using reflective logic programming to describe domain knowledge as an aspect, Proceedings of the First International Symposium on Generative and Component-Based Software Engineering (GCSE’99) (Erfurt, Germany), September 1999. 16

[Ebr03]

Peter Ebraert, Tool support for partial behavioral reflection, Master thesis, Vrije Universiteit Brussel, Ecole de Mines de Nantes and Departamento de Ciencias de la Computaci´on, September 2003.

[ET03]

Peter Ebraert and Eric Tanter, A portable yet flexible approach to interactive runtime inspection, ECOOP Workshop on Advancing the State-of-the-Art in Runtime Inspection (ASARTI 2003), July 2003, Darmstadt, Germany.

[FJ89]

B. Foote and R. Johnson, Reflective facilities in smalltalk-80, Conference Proceedings of OOPSLA’89, vol. 24(10), ACM SIGPLAN Notices, 1989, pp. 327–335.

[FNP+ 95]

J.C. Fabre, V. Nicomette, T. P´erennou, R.J. Stroud, and Z. Wu, Implementing fault tolerant applications using reflective object-oriented programming, Proceedings of FTCS-25 Silver Jubilee (1995).

[Fow99]

Martin Fowler, Refactoring: Improving the design of existing code, AddisonWesley, 1999.

[GC96]

B. Gowing and V. Cahill, Meta-object protocols for c++, in Kiczales [Kic96], pp. 137–152.

[H.90]

Ibrahim M. H., Report of the workshop on reflection and metalevel architectures in object-oriented programming, OOPSLA/ECOOP’90 (1990).

[Hyp]

Hyper/J, www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm.

[KDRB91]

Gregor Kiczales, J. Des Rivi´eres, and D. Bobrow, The art of the meta-object protocol, MIT Press (1991).

[Kic96]

Gregor Kiczales (ed.), Reflection’96, CA, 1996.

[KLM+ 97]

G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingtier, and J. Irwin, Aspect-oriented programming, Proceedings of ECOOP97, 1997.

[LBS00]

T. Ledoux and M.N. Bouraqadi-Saadani, Adaptability in mobile agent systems using reflection, Workshop on Reflective Middleware RM2000 (2000).

[Mae87]

Pattie Maes, Concepts and experiments in computation reflection, PhD thesis, Artificial intelligence laboratory, VUB (1987).

[McA95]

J. McAffer, Meta-level programming with CodA, Proceedings of the 9th Conference on Object-Oriented Technologies 952 (1995), 190–214.

[McA96] [MMY94]

, Engineering the meta-level, in Kiczales [Kic96], pp. 39–61. H. Masuhara, S. Matsuoka, and A. Yonezawa, An object-oriented concurrent reflective language for dynamic resource management in highly parallel computing, IPSJ SIG Notes 94 (1994), 18. 17

[OC02]

Patrick O´ Connor, Practical reliability engineering, 4th edition ed., Wiley, 2002.

[Par72]

D. L. Parnas, On the criteria to be used in decomposing systems into modules, Comm. ACM 15 (1972), no. 12, 1053–1058.

[Pas]

Aspect mining using dynamic analysis, http://www.infosun.fmi.uni-passau.de/st/papers/badHonnef03/.

[Pro]

Prose, http://prose.ethz.ch/Wiki.jsp?page=AboutProse.

[RC00]

B. Redmond and V. Cahill, Iguana/j: Towards a dynamic and efficient reflective architecture for java, 2000.

[RC02]

, Supporting unanticipated dynamic adaptation of application behavior, Proc. ECOOP 2002 (B. Magnusson, ed.), vol. 2374, Springer Verlag, June 2002, pp. 205–230.

[Ref]

Refactoring browser, http://wiki.cs.uiuc.edu/RefactoringBrowser.

[Riv96]

F Rivard, Smalltalk: a reflective language, in Kiczales [Kic96].

[Riv97]

F. Rivard, Evolution du comportement des objets dans les langages classes reflexifs, Phd thesis, Universit de Nantes, Ecole des Mines de Nantes, January 1997.

[SEE]

SEESCOA project, http://www.cs.kuleuven.ac.be/cwis/research/distrinet/projects/SEESCOA/.

[Smi84]

B.C. Smith, Reflection and semantics in Lisp, Proceedings of the 14th Annual ACM Symposium on Principles of Programming Languages (1984).

[SWE]

Aspect mining and refactoring, http://swerl.tudelft.nl/amr.pdf.

[Szy98]

Clemens Szyperski, Component software : Beyond object-oriented programming, Addison-Wesley, January 1998.

[Tan02]

Eric Tanter, Reflexi´on, metaprogramaci´ on y programaci´ on por aspectos, Slides available at http://www.dcc.uchile.cl/∼etanter/tanter-jcc02.pdf.

[TBN01]

Eric Tanter, N. Bouraqadi, and Jacques Noy´e, Reflex: Towards an open reflective extension of java, Third International Conference on Metalevel Architectures and Advanced Separation of Concerns, vol. 2192, SpringerVerlag, 2001, pp. 25–43.

[TDM99]

Tom Tourw´e and Wolfgang De Meuter, Optimizing object-oriented languages through architectural transformations, Proceedings of the 8th International Conference on Compiler Construction, Amsterdam, The Netherlands, March 1999. 18

[TM03]

Tom Tourwe and Tom Mens, Identifying refactoring opportunities using logic meta programming, Proceedings of the Internacional Conference on Software Maintenance and Re-engineering, 2003, 2003.

[TMB02]

Tom Tourwe, Tom Mens, and Johan Brichau, Using declarative metaprogramming to detect possible refactorings, ASE 2002 Workshop on Declarative Meta Programming to Support Software Development, 2002.

[TNCC03]

Eric Tanter, Jacques Noy´e, Denis Caromel, and Pierre Cointe, Partial behavioral reflection: Spatial and temporal selection of reification, OOPSLA (2003).

[TVP02]

E. Tanter, M. Vernaillen, and J. Piquer, Towards transparent adaptation of migration policies, 8th ECOOP Workshop on Mobile Object Systems (2002), 25–43.

[WS99]

I. Welch and R. Stroud, From dalang to kava: The evolution of a reflective java extension, Proc. of the 7th European Conference on Object-Oriented Programming (Pierre Cointe, ed.), LNCS 1616, Springer Verlag, July 1999, pp. 2–21.

[Wuy01]

Roel Wuyts, A logic meta-programming approach to support the co-evolution of object-oriented design and implementation, Phd thesis, Programming Technology Lab, Vrije Universiteit Brussel, January 2001.

19