Bachelorproject Veel Modules

Bachelorproject Veel Modules Projectleden

Sander van den Berg Ronald van Etten Michel van Tol

1296647 1262947 1263226

Vak Omgeving

Bachelorproject – IN3405 TOPdesk TU DELFT Faculteit EWI Technische Informatica Variant Softwaretechnologie(ST)

Commissie

J. Ouwens (TOPdesk, opdrachtgever) R. Spilker (TOPdesk, coördinator) H. Geers (TU Delft, begeleider) B. Sodoyer (TU Delft, coördinator)

Voorwoord Aan het einde van het bachelorgedeelte van de opleiding Technische Informatica aan de Technische Universiteit te Delft moet een afsluitend project worden uitgevoerd. Dit project zorgt ervoor dat de studenten de opgedane kennis van de eerste drie jaar van de studie in praktijk kunnen brengen. Dit verslag is het resultaat van het bachelorproject van Sander van den Berg, Ronald van Etten en Michel van Tol. Het project is uitgevoerd bij TOPdesk Delft van 8 april tot en met 27 juni 2008. In dit voorwoord willen wij graag onze dank uitspreken aan TOPdesk voor het faciliteren van het project. Verder willen we ing. R. Spilker bedanken voor de verschaffing van de opdracht, ir. T.J. Ouwens voor de dagelijkse begeleiding en ir. H.J.A.M. Geers voor de begeleiding vanuit de Technische Universiteit. Sander van den Berg, Ronald van Etten en Michel van Tol Delft, 10 juni 2008

TOPdesk Stage: Veel Modules

1

Samenvatting Wij hebben ons bachelorproject uitgevoerd bij software- en consultancy bedrijf TOPdesk. Zij hadden ons een interessante opdracht te bieden waarmee wij 8 april 2008 begonnen zijn. De opdracht hield in dat er een systeem gemaakt moest worden waarmee het toevoegen van softwaremodules (Eclipse-projecten) aan de Eclipse workspace vereenvoudigd wordt, en het aanpassen van de instellingen van een project vanuit een centraal systeem kan worden doorgevoerd. Dit systeem is ontwikkeld onder de naam TOPspace. Het project begon in april met het houden van interviews met ir. T.J. Ouwens en ing. R. Spilker, waardoor een lijst met requirements opgesteld kon worden. Deze lijst is uitgewerkt in Use Cases en scenario’s, waardoor een beter inzicht werd verkregen voor de ontwerpfase, deze fase sloten we eind april af. Voordat we in mei aan het ontwerp konden beginnen is er een klein onderzoek gedaan. Tijdens dit onderzoek zijn de verschillende implementatievormen, het gebruik van Subversion en het hergebruik van Eclipse-functionaliteiten onderzocht. In de ontwerpfase is de afweging gemaakt tussen de verschillende implementatievormen die we voor het ontwerpen onderzocht hebben en is besloten dat een Eclipse-plugin de beste oplossing bood. Bij het ontwerp is rekening gehouden met de modulariteit van het systeem en de samenwerking tussen Eclipse en de gemaakte Eclipse-plugin. De modulariteit is gerealiseerd door gebruik te maken van Java als programmeertaal en door reflection toe te passen. Tot slot zijn we begonnen met de implementatiefase, waarin het implementeren en testen in parallel uitgevoerd is. Voor het testen is gebruik gemaakt van JUnit en JMock. Tijdens deze fase zijn er ook gebruikerstests uitgevoerd. Uit deze tests kwamen een aantal extra functionele wensen, alsmede een aantal bugs. Wij denken dat voldaan is aan alle requirements die opgesteld zijn in ons requirements document. Hiertoe behoren de twee verschillende delen van de opdracht, namelijk het implementeren van het stappenplan voor het toevoegen van een project en template (standaardwaarden voor nieuwe CodeBunches) mogelijkheden.


2

Verklarende woordenlijst Deze lijst is opgenomen om duidelijkheid te scheppen omtrent bepaalde begrippen. Deze lijst is ook aanwezig in het ‘Requirements Analysis Document’ (zie bijlage C). Ant Ant is een build tool waarmee programmeurs builds kunnen maken, unit tests kunnen uitvoeren en externe tools kunnen aanroepen. Een voorbeeld van een externe tool die aangeroepen kan worden door Ant is Javadoc kunnen aangeroepen worden door Ant. Build Het volledig compileren van een project (CodeBunch) of een volledig systeem bestaande uit projecten (CodeBunches) naar een direct distribueerbaar formaat, dat direct gebruikt kan worden door de gebruikers. Build script Een build script bevat taken die uitgevoerd moeten worden door een build tool zoals Ant of Maven. Changeset Bestanden die op het systeem van de gebruiker aangepast of verwijderd zijn, en doorgevoerd moeten worden aan SVN. CodeBunch Op dit moment een Eclipse-project, gekoppeld aan Ant, maar mogelijk later een ‘project’ voor een andere tool gekoppeld aan bijvoorbeeld Maven. Een CodeBunch bevat de sourcecode die de gebruikersmodules vormt, en de build file (zie Build). CruiseControl CruiseControl is een programma dat constant builds maakt. De tool heeft een front-end die werkt als diagnostisch middel om te controleren of de nightly build geslaagd is. Eclipse Eclipse is een Integrated Development Environment waarin programmeurs eenvoudig kunnen programmeren in Java. Code wordt meestal opgeslagen in projecten. Eclipse kent verder een aantal aanvullende functionaliteiten in de vorm van zogenaamde plugins. (Verder bevat Eclipse veel refactoring-tools. Op deze manier kan er d.m.v. sneltoetsen efficiënt gewerkt worden). Eclipse-plugin Een Eclipse-plugin verzorgt bijna altijd een zelfstandige taak. Sommige plugins, zoals Subversive en Subclipse, zorgen bijvoorbeeld voor communicatie met SVN-repositories. Maven Maven is een build-tool, waarin meer functionaliteit geautomatiseerd is dan in Ant. Module Om ambiguïteit te voorkomen gebruiken we deze term voor de code die TOPspace gaat beheren. TOPdesk maakt ‘gebruikersmodules’ voor klanten, en hanteert tegelijkertijd de term ‘modules’ voor Eclipse-projecten. De gebruikersmodules die TOPdesk voor klanten maakt worden aangeduid als‘TOPdesk modules’. Wanneer ‘module’ als woord gebruikt wordt in dit document dan wordt hiermee een CodeBunch bedoeld. Subversion Subversion, kortweg SVN, is een gereedschap waarmee sourcecode beheerd kan worden. Hiermee kunnen meerdere gebruikers tegelijk gebruik maken van dezelfde bestanden en deze delen met elkaar. Aanpassingen in een bestand kunnen simpel worden gedeeld met andere gebruikers.


3

Template Build script template Een build script template is een default-configuratie voor een build script. In een template staan geen afhankelijkheden. Deze worden door TOPspace toegevoegd bij het aanmaken van een CodeBunch. Instellingen-template Een instellingen-template bevat een default-configuratie voor de instellingen van een CodeBunch. TOPspace De naam van ons product. De naam is samengesteld als TOP en space, waarbij ‘TOP’ verwijst naar TOPdesk en ‘space’ naar het feit dat ons product een workspace management tool is. TOPspace systeemmodule Een TOPspace systeemmodule is een implementatie van een abstracte klasse die binnen TOPspace voor een bepaalde stap of dataopslag de verantwoordelijkheid heeft. Deze systeemmodules zijn eenvoudig aan ons systeem te koppelen, zodat de nieuwe functionaliteit beschikbaar is. Workspace Een map waarin alle Eclipse-projecten danwel CodeBunches van de gebruiker zijn opgeslagen.


4

Inhoudsopgave Voorwoord Samenvatting Verklarende woordenlijst

1 2 3

1. Inleiding 2. Project 3. Requirements 4. Onderzoeksfase 5. Ontwerp 6. Implementatie 7. Tests 8. Conclusies en toekomstig werk 9. Aanbevelingen 10. Persoonlijke reflecties Literatuurlijst

6 7 8 9 11 14 16 18 19 20 23

Bijlage A: Onderzoeksdocument Bijlage B: Plan van Aanpak Bijlage C: Requirements Analysis Document Bijlage D: Design Document Bijlage E: Adding a project Bijlage F: Vragenlijst voor interview

24 32 36 52 69 71


5

1. Inleiding Dit document is geschreven door drie bachelorstudenten Technische Informatica. De bacheloropdracht is uitgevoerd bij het software en consultancy bedrijf TOPdesk in Delft en heeft een duur gehad van 11 weken. Deze bacheloropdracht vormt de afrondende fase van de opleiding Technische Informatica aan de Technische Universiteit te Delft. Het doel van het project is om alle verworven kennis van de opleiding in de praktijk te brengen. Dit dient gedaan te worden bij een door de studenten zelf te kiezen bedrijf. Wij hebben gekozen voor TOPdesk in Delft omdat zij de meest uitdagende opdracht aanbood. Na een aantal korte overleggen zijn we op 8 april 2008 begonnen bij TOPdesk. De opdracht die wij gekregen hebben was het maken van een systeem waarmee het toevoegen van Eclipse-projecten aan de workspace vereenvoudigd wordt en configuraties centraal kunnen worden beheerd. Hoe we dit aangepakt hebben is te lezen in dit document. In hoofdstuk 2 van dit document is de opdracht kort en globaal omschreven. Hoofdstuk 3 gaat dieper in op de manier waarop de requirements bepaald zijn en worden de belangrijkste requirements uiteengezet. In hoofdstuk 4 wordt beschreven hoe het implementatie-onderzoek verricht is. Het ontwerp is uitgewerkt in hoofdstuk 5. In hoofdstuk 6 wordt kort ingegaan op de implementatiefase. In hoofdstuk 7 zijn onze bevindingen in de gebruikerstest uiteengezet. De conclusies en aanbevelingen worden in hoofdstuk 8 en 9 gepresenteerd. Tot slot zijn de individuele reflecties in hoofdstuk 10 weergegeven.


6

2. Project 2.1 Bedrijfsprofiel TOPdesk is een jong bedrijf uit Delft dat sinds 1993 het gelijknamige product TOPdesk verkoopt. TOPdesk is een Service Management Applicatie en wordt veel gebruikt bij ICT-helpdesks en andere servicedesks. Het bedrijf is in 15 jaar gegroeid naar ongeveer 250 medewerkers die verantwoordelijk zijn voor ontwikkeling, testen, advies en verkoop. TOPdesk heeft zo’n 3000 klanten in 34 verschillende landen. Door deze klanten worden ruim 1.000.000 werkplekken ondersteund. Naast de vestiging in Delft zijn er ook nog vestigingen in Antwerpen, Londen en Kaiserslautern. 2.2 Probleemdomein Het nieuwste product van TOPdesk heet TOPdesk 4. Dit product is voor een groot deel in Java geïmplementeerd. De ontwerpers hebben de sourcecode van dit product in losse functionele modules verdeeld. Zo’n module wordt vanaf nu aangeduid als CodeBunch omdat deze naast de sourcecode bijvoorbeeld ook nog uit de benodigde buildfiles bestaat. In de huidige situatie is ir. T.J. Ouwens binnen TOPdesk verantwoordelijk voor het toevoegen van een nieuwe CodeBunch. Het toevoegen van een nieuwe CodeBunch gebeurt handmatig en bestaat uit diverse stappen, waardoor het een foutgevoelige procedure is. 2.3 Probleemstelling Door deze vele stappen en foutgevoeligheid rees de vraag of de procedure niet geautomatiseerd kan worden. De opdracht is dan ook om een systeem te ontwikkelen waarmee het toevoegen van CodeBunches vereenvoudigd wordt, en het aanpassen van de configuraties vanuit een centraal systeem kan worden uitgevoerd. Hierbij moet per CodeBunch kunnen worden aangegeven wat de afhankelijkheden zijn en welke uitzonderingen er van toepassing zijn.


7

3. Requirements Om het probleem goed te begrijpen voorafgaand aan het ontwerp van het systeem, moesten er requirements verzameld worden. Tijdens deze fase hebben wij diep nagedacht over het probleem en hebben wij een vragenlijst opgesteld om de benodigde requirements te achterhalen. Met behulp van de gemaakte vragenlijst (zie bijlage F) hebben wij interviews af kunnen nemen met ir. T.J. Ouwens en ing. R. Spilker. Beiden zijn ontwikkelaars bij TOPdesk en weten exact hoe een nieuwe module (Eclipse-project) gemaakt moet worden. Aangezien zij het dichtst bij dit proces betrokken zijn, hebben wij besloten om het interviewen te beperken tot deze twee personen. Na deze interviews zijn er twee lijsten met requirements opgesteld. De lijst met functionele requirements bevat alle requirements die nodig zijn om een werkend systeem te produceren. De niet-functionele requirements zullen het systeem voorzien van hoge kwaliteit. Uiteraard zijn voor beide typen requirements de prioriteiten vastgelegd. Dit is gedaan volgens het MoSCoW-model. Hoe de prioriteiten precies verdeeld zijn is terug te zien in tabel 1 en tabel 2 van het Requirements Analysis Document, dat is bijgevoegd als Bijlage C. Voor de ‘projecten’ die ons systeem maakt is de benaming CodeBunch bedacht. Dit is gedaan omdat zowel de termen ‘project’ als ‘module’ al vaak binnen het bedrijf TOPdesk gebruikt worden voor andere doeleinden, en dus zouden zorgen voor ambiguïteit. Ook de naam ‘bundel’ voldeed niet omdat het OSGi Framework van Eclipse die term al hanteert. Bovendien kon hier ook niet voor Eclipse Project gekozen worden omdat ons systeem uitbreidbaar moet zijn. Hierdoor is er de mogelijkheid om een andere IDE dan Eclipse te gebruiken, wat ervoor zou zorgen dat de naam Eclipse Project niet meer consistent is. Na enig brainstormen en overleg is er gekozen voor CodeBunch. Meer termen die gebruikt worden in onze documenten zijn terug te vinden in de verklarende woordenlijst aan het begin van dit document. De scenario’s en use cases zijn na het verzamelen van de requirements uitgewerkt. Deze scenario’s en use cases geven een beter inzicht in het door ons te maken systeem. Door het specificeren van de scenario’s werd duidelijker welke mogelijkheden ons systeem moet bieden en hoe bepaalde acties (bijvoorbeeld het toevoegen van een CodeBunch) uitgevoerd dienen te worden. Het Use Case-diagram laat zien welke bewerkingen kunnen worden gedaan op twee verschillende entiteiten, namelijk CodeBunches en Templates. De bijbehorende Use Case beschrijvingen brengen vervolgens de gebruikersacties en systeemreacties in kaart. Dankzij het specificeren van de scenario’s en Use Cases hebben wij een beter inzicht gekregen over hoe ons systeemontwerp eruit moet komen te zien. Tijdens de ontwikkelfase kwam er nog één nieuwe requirement bij, namelijk het instellen van de tekstencodering. Deze moet voor elke CodeBunch standaard ingesteld worden op UTF-8. Na enig onderzoek was het duidelijk dat dit niet al teveel werk zou gaan kosten, waardoor wij besloten hebben ook deze requirement te implementeren. De functionele requirement ‘Changeset’ is geïmplementeerd zodanig dat ons systeem een Changeset aanmaakt. Na het aanmaken van deze Changeset kan met behulp van tools zoals Subclipse en Subversive gezien worden welke bestanden er aangepast zijn. Hierdoor kunnen deze bestanden vervolgens met behulp van dezelfde tool, of met een andere tool, gecommit worden naar SVN. De niet-functionele requirement ‘Engelstalig’ heeft betrekking op de interne werkwijze. Dit houdt in dat zowel code, commentaar als interne documentatie Engelstalig moet zijn in verband met internationale werknemers die werkzaam zijn bij TOPdesk Delft of bij een van de andere vestigingen in het buitenland. Indien er Engelstalige werknemers aanwezig zijn bij presentaties dan worden deze in het Engels gehouden.


8

4. Onderzoeksfase In dit hoofdstuk wordt beschreven welke activiteiten van belang zijn geweest voor de keuze van de uiteindelijke implementatievorm. De overwogen implementatievormen zijn terug te zien in het Design Document (bijlage D). Hierna zullen drie onderwerpen besproken worden, waarnaar door ons onderzoek verricht is. Deze onderwerpen waren voor ieder van ons nieuw. Het onderzoek heeft zich gericht op het vinden van informatie, zoals bijvoorbeeld de API van Eclipse, de API van Java en bronnen met betrekking tot Subversion toolkits. 4.1. Projectbeheer in en met Eclipse Omdat TOPspace Eclipse moet ondersteunen was het van belang verschillende taken te kunnen uitvoeren met diezelfde ontwikkelomgeving. Allereerst is er onderzocht of er vanuit een zelfgemaakte plugin op eenvoudige manier een nieuw Eclipse-project gemaakt kon worden. Na Eclipse API’s te hebben doorgelezen, kwamen we tot de ontdekking dat dit inderdaad vrij eenvoudig kon. De gewenste functionaliteit wordt door packages geboden die standaard meegeleverd zijn met Eclipse. Voor het aanmaken van een nieuw project vonden we allereerst de klasse ResourcesPlugin. Deze klasse heeft onder andere de taak om de naam en het volledige pad van de huidige workspace bij te houden. Met behulp van deze workspace kan dan weer een nieuw project met een willekeurige naam worden aangemaakt. Nadat de Eclipse-projecten aangemaakt konden worden, was het volgende belangrijke onderzoekspunt het bepalen of alle settings uit deze projecten konden worden gehaald. Hiervoor bleken de klasse JavaProject en de interface IProject bijzonder geschikt. Eclipse biedt verder de mogelijkheid om afhankelijkheden tussen Eclipse-projecten in te stellen. Deze optie kan ook door een programmeur worden ingesteld. Ook hiervoor kunnen de klasse JavaProject en de interface IProject gebruikt worden. Een interessant detail is dat Eclipse zelf bij het compileren al een melding geeft als klassen circulaire afhankelijkheden hebben. Dit kan ontstaan als project ‘A’ afhankelijk is van project ‘B’, en ‘B’ op zijn beurt weer (in)direct afhankelijk is van ‘A’. Tot slot bezit het Workspace-object van Eclipse de mogelijkheid om in één keer de build-volgorde vast te stellen. Dit houdt tevens in dat deze gebruikt kan worden bij het opstellen van de Ant buildfiles, hier is immers diezelfde volgorde van toepassing. 4.2. Subversion gebruiken als communicatiemiddel Voor het leggen van een verbinding naar een Subversion-server is er gekozen voor de toolkit SVNKit (website: http://www.svnkit.com) waarmee ook de Eclipse Subversion plugins Subclipse en Subversive zijn gemaakt. Deze twee plugins worden veel gebruikt door de programmeurs bij TOPdesk, zodat zij geïntegreerd in Eclipse gebruik kunnen maken van Subversion. Na een tijdje te hebben rondgezocht in de API van SVNKit is er besloten om de implementatie van de SVN-verbinding pas later te voltooien. De nadruk is gelegd op het onderhouden van CodeBunches zelf, welke een hogere prioriteit hebben. De Subversion-tool is feitelijk alleen nodig voor de bestanden die niet in de workspace van de programmeur staan. Dit zijn de CruiseControl-bestanden en de nightly build batch-bestanden.


9

4.3. Reflection als middel ten behoeve van modulariteit 1

Om onze applicatie modulair te maken is er voor gekozen om te werken met reflection . Op deze manier kan er aan de ClassLoader van Java een instantie van een klasse opgevraagd worden die bij een willekeurig opgegeven naam hoort. In plaats van in de code een object te definiëren en vervolgens te instantiëren, hoeft alleen het Class-object die aangemaakt dient te worden, gedeclareerd te worden. Door deze constructie te gebruiken is er inzicht verkregen in hoe de Java Runtime Environment zelf objecten aanmaakt. 4.4. Conclusies met betrekking tot het onderzoek Na de voltooiing van dit onderzoek zijn een aantal belangrijke beslissingen genomen. Reflection is inderdaad nodig voor het ontwerp, omdat hiermee direct nieuwe modules kunnen worden gekoppeld aan het systeem. Ook de resultaten van het onderzoek naar projectbeheer in Eclipse zijn van grote waarde voor het ontwerp van ons systeem en zullen uitvoerig worden gebruikt tijdens de implementatiefase. Op het eerste gezicht was ook SVNKit voor ons systeem een aantrekkelijke optie. Later zal echter blijken dat we als alle benodigde bestanden in de workspace te vinden zijn, er geen SVN-verbinding meer nodig is. Verder is gebleken in de requirementsfase dat ons systeem niet direct zal hoeven committen naar de SVN-server.

1

Reflection: “the process by which a computer program can observe and modify its own structure and behavior”, bron: http://www.wikipedia.org


10

5. Ontwerp In dit hoofdstuk wordt een aantal zaken besproken die tegen gekomen zijn tijdens de ontwerpfase. 5.1. Naamgeving project Tijdens deze ontwerpfase is ervoor gekozen om ons project de naam TOPspace te geven. Deze naam refereert aan de term ‘workspace’ omdat onze applicatie een ‘workspace management tool’ is. Verder wordt de naamgevingconventie gebruikt die binnen TOPdesk gebruikelijk is, en we dus op een combinatie van TOPdesk en workspace uitkwamen. 5.2. Belangrijkste ontwerpkeuzes •

Het gebruik van de programmeertaal Java

De ontwerpkeuze op het gebied van de programmeertaal waarin het systeem geïmplementeerd dient te worden was snel duidelijk. Binnen TOPdesk wordt hoofdzakelijk in Java geprogrammeerd en daarnaast is het ook de programmeertaal waar wij de meeste ervaring mee hebben. Bovendien is het voor ons gemakkelijk om met Java uitbreidbare software te maken. •

Eclipse-plugin als implementatievorm

We hebben er voor gekozen om een Eclipse-plugin te implementeren. Zo kan de functionaliteit uit Eclipse hergebruikt worden, zoals de standaard weergave en de workspace zelf. Bij het maken van een plugin kwam voor ons een aantal nieuwe dingen kijken; allereerst hoe de plugin vormgegeven zou worden. De plugin moest zo vormgeven worden dat de weergaven en acties logisch uit elkaar volgen. Al implementerend zijn we tegen de wizards aangelopen, waarmee precies aangegeven kan worden wat de plugin moet doen. In het volgende hoofdstuk over de implementatie is meer te lezen over de keuzen die tijdens het implementeren van de plugin gemaakt zijn. •

Uitbreidbaarheid van het systeem d.m.v. een core-package

Het belangrijkste aspect van het ontwerp van TOPspace is gebaseerd op de uitbreidbaarheid van het systeem. Door hiermee rekening te houden is een ontwerp tot stand gekomen dat bestaat uit een kern en een omliggende schil. De kern bestaat uit functionaliteiten zoals het lezen van en schrijven naar bestanden en systeeminstellingen laden (SettingsManager), het beheren van Templates en CodeBunches (Template en CodeBunch), het schrijven van log-bestanden (Logger) en de communicatie tussen deze klassen en de omliggende schil (Backbone). Bovendien bevat de kern ook nog abstracte klassen zoals een RevisionTool, Tool, GUI, CodeBunchAccess en Steps waarvan de concrete implementaties buiten de kern liggen. De grafische weergave hiervan is terug te zien in het klassendiagram (figuur 1) waar de kern zich binnen de Core-package bevindt. De Core-package hoeft niets te weten van de concrete klassen in de omliggende schil omdat deze geladen worden vanuit de configuratie en vervolgens in het systeem geladen worden door de SettingsManager.


11

Figuur 1: klassendiagram van de TOPspace applicatie

•

Concrete klassen

Bij het maken van de eerdergenoemde concrete klassen kwam een hoop werk kijken. Zo zijn er de Stepssubklassen waar het TOPspace-project feitelijk om draait. Verder is er de concrete CodeBunchAccess klasse die EclipseCodeBunchAccess genoemd is. Tot slot zijn er nog de tools. Elk van de hiervoor genoemde groepen van concrete klassen zullen hieronder worden toegelicht. We hebben ervoor gekozen om de bewerkingen die te maken hebben met eenzelfde applicatie te groeperen. Alle bewerkingen met betrekking tot bijvoorbeeld Ant worden gegroepeerd in de klasse AntStep. Hetzelfde geldt voor de klassen CruiseControlStep, BuildScriptStep en TeamProjectSetStep, die respectievelijk de CruiseControl-bestanden, de scripts voor de build server en de Team Project Sets beheren. In het klassendiagram is de klasse SVNStep te vinden; deze is later komen te vervallen omdat alle invoerbestanden in de workspace te vinden zijn. Verder zijn in het originele diagram op de plaats van SVNStep de klassen BuildScriptStep en TeamProjectSetStep komen te staan. Om de plugin te laten communiceren met de Eclipse workspace is een laag nodig die alle acties kan uitvoeren om de workspace aan te passen. Dat wil zeggen dat een CodeBunch aangemaakt en beheerd moet worden op workspace-niveau. CodeBunches worden dus vertaald naar Eclipse-projecten in deze klasse. Verder zijn er faciliteiten nodig om settings van een CodeBunch in de workspace op te vragen en de build-volgorde van de CodeBunches vast te stellen. Deze faciliteiten kunnen aangeroepen worden in Eclipse zelf, wat betekent dat deze functionaliteit hergebruikt kan worden in TOPspace. In eerste instantie dachten we een SVNTool danwel RevisionTool nodig te hebben. Later bleek echter dat we alle data die nodig is in de workspace konden krijgen door de batch-bestanden zodanig aan te passen dat deze batch-bestanden en alle CodeBunches kunnen worden uitgecheckt. Uiteindelijk wordt alleen nog gebruik gemaakt van een FileTool die bestandsbewerkingen op een simpele manier mogelijk maakt. Om dit mogelijk te maken hebben, is de volgende bewerking uitgevoerd: Het bestaande batch-bestand wordt verplaatst, en er wordt een nieuw batch-bestand gemaakt. Dit nieuwe bestand zorgt ervoor dat het originele batch-bestand van de SVN-server afgehaald wordt. Het originele batch-bestand is ongewijzigd en blijft daarom werken.


12

•

Updatemethoden in Backbone

Zoals in het klassendiagram te zien is, bestaan de methoden updateCodebunch en updateTemplate. Deze zijn slechts in één vorm te vinden, in een variant waarbij alle belangrijke attributen worden meegegeven. Later is te zien dat deze keuze niet handig uitpakte.


13

6. Implementatie Dit hoofdstuk beschrijft de belangrijkste zaken die tegengekomen zijn tijdens de implementatiefase, van de implementatievolgorde tot en met de struikelpunten. Implementatievolgorde Allereerst is de core-package geïmplementeerd. Daarbinnen was de volgorde als volgt: Er is begonnen met de SettingsManager en de Logger, daarna de klasse Backbone, en als laatste de klassen Tool, RevisionTool, Steps en CodeBunchAccess. Nadat deze klassen gemaakt zijn, is er specifiek Eclipse-gericht geïmplementeerd. Dit hield in dat de klasse EclipseCodeBunchAccess geïmplementeerd werd en de eerste versie van de GUI is uitgewerkt. De GUI is later steeds meer uitgebouwd met elke keer een extra wizard die een functionaliteit toevoegt aan het systeem. Parallel met het grootste gedeelte van de GUI zijn de Step-subklassen geïmplementeerd. Dit komt grotendeels neer op het functionele gedeelte van TOPspace. De klassen AntStep, CruiseControlStep, BuildScriptStep en TeamProjectSetStep bieden de feitelijke functionaliteit die dit project vereist. Ze representeren het stappenplan dat in bijlage E te zien is. In figuur 2 vindt u een voorbeeld van hoe de graphical user interface er uit ziet.

Figuur 2: de graphical user interface

Tests Het systeem is op uitvoerige wijze getest, zowel tijdens als na het implementeren van de klassen. Bij het maken van een nieuwe klasse, is tegelijk een gerelateerde testklasse gemaakt die de gedragingen van de methoden test. Voor de Backbone hebben we naast de normale JUnit test ook een ‘mock’ gemaakt van de SettingsManager waarmee de aanroepen die Backbone naar SettingsManager verstuurt getest worden. Het framework waarmee hier gewerkt is, is het softwarepakket ‘jMock 2’ (website: http://www.jmock.org/). We hebben voor het eerst mocks gebruikt tijdens dit project en zijn erachter gekomen dat het een erg nuttige manier van testen kan zijn, omdat op deze manier kan worden gecontroleerd of aan de expliciet aangegeven verwachtingen (methodeaanroepen) voldaan is. Zo is het mogelijk om aan te geven dat een methode een exact aantal keer moet worden aangeroepen, of juist dat een methode nooit zal worden aangeroepen. De tests laten dus goed zien hoe de geteste klasse aanroepen doet naar methoden in het mock-object. Tot nu toe zijn alleen geautomatiseerde tests in de vorm van JUnit test cases genoemd. Deze voldoen om de functionaliteit te testen, maar voor een plugin is de grafische weergave van de informatie van net zo groot belang. Om deze reden kan in het volgende hoofdstuk gelezen worden over de gebruikerstest die we gehouden hebben onder een aantal medewerkers van TOPdesk.


14

Struikelpunten en leermomenten Aan het begin van de implementatiefase is niet veel rekening gehouden met het feit dat onze Stepklassen (AntStep, CruiseControlStep, etc.) bestanden op verschillende locaties moesten lezen. Dit had als gevolg dat al deze bestandslocaties in eerste instantie in de code nog vast ingesteld waren. Nu is dit opgelost door de Eclipse workspace als basis te gebruiken en van daaruit verder te werken. Dit heeft als voordeel dat er geen vaste map meer hoeft te worden gebruikt, wat de plugin flexibeler maakt. Verder is ervoor gekozen om de settings.ini van TOPspace op een vaste plaats neer te zetten, waar de plugin ook van af weet. We hebben geprobeerd de locatie van de gegevens zo flexibel mogelijk te kiezen. Tot op een zeker niveau is het goed mogelijk om bijvoorbeeld bestandslocaties te flexibel te maken, maar settings.ini zal altijd een vaste plaats moeten krijgen. De settings.ini en de overige TOPspace bestanden zoals die in de bijlage van het Design Document te vinden zijn, zijn in de map ‘topspace’ in de workspace van de gebruiker geplaatst, omdat de data dan op een overzichtelijke plaats verzameld is, en deze dan gedeeld kan worden via SVN met andere gebruikers. Voor het maken van de graphical user interface is gebruik gemaakt van een concept dat te lezen is in een 2 artikel over JFace Wizards . Hierbij worden modellen gebruikt om informatie door de verschillende pagina’s van een Wizard door te geven. Een model heeft invoergegevens en na de uitvoer van de wizard uitvoergegevens. Deze uitvoer wordt toegepast op de gegevens die de Backbone beheert. Waar verder bij de graphical user interface tegenaan gelopen werd was het opnieuw weergeven van de view waarbinnen TOPspace weergegeven wordt. Dit probleem had te maken met het complexere gedrag van SWT. Uiteindelijk is hier een oplossing voor gevonden. De view van TOPspace wordt vernieuwd door de tree die als invoer is opgeslagen te veranderen en opnieuw aan de view te koppelen. Op een gegeven moment kwam aan het licht dat er in de graphical user interface een kloon gemaakt moest worden van lijsten, omdat deze objecten in de Backbone dusdanig aangepast werden dat de originele data (List of Map) altijd verwijderd werd. Dit heeft te maken met de updateCodebunch- en updateTemplate-methoden in de klasse Backbone. Deze wilden we liever in een variant houden waarbij de instellingen zoals settings en folders en bij CodeBunches ook de products in één keer meegaven. Achteraf zouden we er liever voor kiezen om 3 losse methoden aan te maken, zodat dan niet iedere keer een kloon van een bestaande List of Map hoeft te worden gemaakt. Wat tot nu toe werkt is het opnemen van losse klassen zoals de implementaties van de Tools en Steps in hetzelfde Jar-bestand als de plugin zelf. Wat we in de toekomst nog willen aanpassen is het dusdanig plaatsen van deze losse klassen dat ze in dezelfde map als het Jar-bestand kunnen worden geplaatst in plaats van in het Jar-bestand zelf.

2

Doina Klinger (16 december 2002). Creating JFace Wizards.


15

7. Tests Dit hoofdstuk beschrijft alle tests die uitgevoerd zijn. Hierin komen de JUnit tests, integratietests en gebruikerstests aan bod. Eerst wordt er omschreven hoe er precies getest is. Hierna wordt er aandacht besteed aan de testresultaten. Testmethoden Er zijn verschillende niveaus van testen toegepast. Ten eerste zijn de methoden apart getest door middel van JUnit- en JUnit-plugin tests. Deze tests zijn geschreven voor elke methode, vóórdat de betreffende methode daadwerkelijk geïmplementeerd werd. Ten tweede zijn de integratie-/communicatietest uitgevoerd. Tijdens deze tests zijn de klassen aan elkaar gekoppeld. Deze koppelingen zijn voor een groot deel getest door middel van mocks. Met mocks worden methode-aanroepen getest. Hierdoor kan worden nagegaan of de juiste methoden aangeroepen zijn. Ten derde is er een gebruikerstest gemaakt en is deze uitgevoerd door een zestal ontwikkelaars. Deze gebruikerstest heeft als doel om te achterhalen of bepaalde combinaties van Eclipse en een besturingssysteem niet naar behoren werken. Een ander doel was om te controleren of TOPspace gemakkelijk te gebruiken is voor mensen die het nog nooit gebruikt hebben. Bij de test werd de tester gevraagd een aantal basistaken met de TOPspace plugin uit te voeren. Deze basistaken zijn: • • • • • • • •

maken van een nieuwe CodeBunch zonder template maken van een nieuwe Template maken van een nieuwe CodeBunch met de zojuist aangemaakte Template aanpassen van een CodeBunch aanpassen van een Template verwijderen van een CodeBunch verwijderen van een Template aanpassen van producten bij CodeBunches

Testresultaten De testresultaten kunnen worden opgedeeld in vier categorieën. Deze categorieën worden één voor één behandeld. •

Functionele fouten

De functionele fouten die tegengekomen zijn, zijn grotendeels tijdens de JUnit-tests naar voren gekomen. De grootste functionele fout die we tegengekomen zijn is al in de paragraaf over struikelpunten en leermomenten aan bod gekomen. Deze fout houdt in dat er lijsten leeg gemaakt worden bij het updaten van een CodeBunch/Template. De tweede functionele fout is naar voren gekomen tijdens het implementeren van de stappen. Bij deze stappen waren dermate veel uitzonderingen dat het nodig was om een manual optie in te bouwen. Hiermee kan de gebruiker aangeven of zij bepaalde CodeBunches handmatig in de uitvoerbestanden wil beheren. De derde functionele fout kwam aan het licht tijdens de gebruikerstest. Deze fout houdt in dat de dependencies niet van de workspace in TOPspace overgenomen worden tijdens de initiële import.

•

Communicatiefouten

De belangrijkste communicatiefout die tegengekomen is vond plaats in de GUI. In de GUI bleek het onmogelijk om te communiceren met de EclipseCodeBunchAccess, omdat deze simpelweg geen toegang tot elkaar hadden. Dit is opgelost door de aanroepen via de Backbone te laten lopen.


16

•

Testomgeving fouten

Er zijn tijdens het uitvoeren van de tests een aantal omgevingsfouten aan het licht gekomen. De eerste is dat er bij de gebruikerstest overcomplete testdata werd meegegeven. Hierdoor waren er in de TOPspace configuratiebestanden wel CodeBunches aanwezig die zich nog niet in de workspace bevonden. Dit zorgde voor exceptions waardoor TOPspace onhandelbaar werd. De tweede ligt in het feit dat Eclipse Jar-packages in zijn cache plaatst. Dit is op zich een goede eigenschap, als Eclipse er ook voor zou zorgen dat deze cache overschreven wordt als er een nieuwe versie van de Jar benodigd is. Door dit probleem werd er gestuit op vooraf onverklaarbare “method not found exceptions”. De derde bug die gevonden werd is wederom te verhalen op Eclipse. Deze bug houdt in dat als er in een tekstveld op ‘Tab’ wordt gedrukt om naar knoppen binnen het venster te navigeren, deze knoppen hun layout verliezen. Deze bug ligt in het feit dat Eclipse 3.4M6 een SWT versie bevat waarin mogelijk fouten zitten. In latere en eerdere versies is dit probleem niet terug te vinden. Gewenste extra functionaliteiten Tijdens de gebruikerstests zijn de gewenste functionaliteiten getoond in tabel 1 naar voren gekomen. Deze zouden in een later stadium kunnen worden toegevoegd aan TOPspace. Wat Focus niet op finish, maar op add bij het toevoegen van een folder Fraaiere foutafhandeling TOPspace disablen als de tijdelijke CodeBunch aanwezig is topspace map in de workspace onhandig (Rechtermuis) acties op Templates Onduidelijke berichtgeving

Prioriteit Could have, Should have, + Should have, + Would have, -Could have, Should have, +

Tabel 1: Toekomstige features

Een dubbelklik op een Template zorgt er nu voor dat de wizard ‘new CodeBunch’ weergegeven wordt.


17

8. Conclusies en toekomstig werk Het doel van dit bachelorproject was het ontwikkelen van “een systeem waarmee het toevoegen van projecten (CodeBunches) aan de Eclipse workspace vereenvoudigd wordt, en het aanpassen van de configuraties vanuit een centraal systeem kan worden doorgevoerd”. Dit doel kunnen we globaal opsplitsen in twee gedeeltes. Ten eerste het gedeelte van configuraties aanpassen. Ten tweede het builden testproces vereenvoudigen. Aanpassen van configuraties Het eerste doel van ons project, het gemakkelijk centraal kunnen aanpassen van configuraties, is gerealiseerd door het gebruik van Templates binnen ons systeem. Met deze Templates is het mogelijk om voorgedefinieerde instellingen aan een nieuwe CodeBunch te koppelen. Templates zelf zijn ook aanpasbaar. Verder is de mogelijkheid geboden om voor meerdere CodeBunches tegelijk instellingen te doen. Verder bestaat er ook ondersteuning voor het toegevoegen van de CodeBunch-afhankelijkheden, dit in verband met het tweede doel waarin deze afhankelijkheden belangrijk zijn in het bepalen van de build-volgordes. Vereenvoudigen van builden testproces Het tweede doel van ons project, het vereenvoudigen van het builden testproces, hebben wij in de praktijk gebracht door dit proces op te delen in een eindig aantal stappen. Deze stappen zijn als aparte routines geïmplementeerd zodanig dat ze individueel aan of uit te zetten zijn. Verder is een functionaliteit ingebouwd waarin aan te geven is welke CodeBunch bij welke producten hoort. Hierdoor is in de losse routines via de GUI op een gemakkelijke manier te selecteren welke CodeBunches er in een product-specifiek build-bestand moeten worden verwerkt. Toekomstig werk Zoals in bijna elk project het geval is, is bij ons project ook duidelijk gebleken dat er nog een aantal extra functionaliteiten aan toegevoegd kunnen worden. Een korte greep uit de mogelijkheden om verder te bouwen op en om ons project is hieronder kort uiteengezet. Jar met losse klassen Hoewel ons systeem erg modulair is, is het nu nog niet direct mogelijk om de losse “Steps” klassen buiten het Jar-bestand te laten. Nu is het zo dat deze in hetzelfde Jar-bestand moeten komen te staan als de GUI. In de toekomst zou er uitgezocht kunnen worden hoe deze klassen uit het Jar-bestand te halen zijn waardoor de modulariteit verbeterd kan worden. Dit kan bijvoorbeeld gedaan worden door middel van een Service Provider Interface. Help documentatie De documentatie die voor TOPspace geschreven is, kan verwerkt worden in de applicatie zodat via de GUI de documentatie bekeken kan worden. Deze functionaliteit kan geïmplementeerd worden door de documentatie te laten zien wanneer er op de helpknop in een venster gedrukt wordt. Automatisch Eclipse wizards aanroepen Op dit moment geeft TOPspace na het toevoegen of het wijzigen van een CodeBunch een dialoog met daarin het bericht dat de Eclipse-instellingen ingesteld kunnen worden door naar de properties van de CodeBunch te gaan. In het ideale geval wordt in plaats van dit bericht, automatisch de betreffende wizard geopend zodat de gebruiker niet zelf deze stappen hoeft te doorlopen en direct weet waar hij dingen moet gaan aanpassen.


18

9. Aanbevelingen In dit hoofdstuk zullen een aantal activiteiten omschreven worden die wij in een volgend project anders zouden aanpakken. Ook worden er activiteiten besproken waarbij wij erg tevreden zijn met de manier waarop we deze hebben toegepast. Om te beginnen zijn we erg tevreden met de manier waarop wij onze werkwijze gekozen hebben. Dit hebben we gedaan door regelmatig de verdeling van de taken af te wisselen. Verder hebben we doordat we elke maandag om 10:00 een afspraak hadden met de opdrachtgever duidelijk onze voortgang en problemen kunnen bespreken. Als derde punt willen we aandragen dat we een groot fan geworden zijn van pair-programming. Door met meerdere personen te programmeren worden de meeste bugs al direct gecorrigeerd. Tot slot willen we hieraan toevoegen dat we erg blij zijn dat er de mogelijkheid was om elke dag bij TOPdesk in de kantine te lunchen. Dit heeft ervoor gezorgd dat de werkdag gebroken werd op vaste tijdstippen waardoor onze gedachten op iets anders gericht werden. We zijn natuurlijk ook op een aantal vlakken iets minder tevreden. Deze dingen zouden we bij een volgende project zeker anders aanpakken. Zo zouden we een meer gedetailleerdere tijdslijn willen maken. We hebben alleen tijdens de planning aan het begin van het project een tijdlijn gemaakt, maar het zou handig zijn geweest als we voor elke fase een tijdlijn zouden maken. Hieruit kunnen we opmaken dat we in het vervolg nauwkeuriger moeten plannen. We hebben er bij de planning niet over nagedacht om onze software te laten testen door andere medewerkers binnen TOPdesk. In het vervolg moeten we zeker een week inplannen voor een dergelijke test omdat medewerkers niet altijd beschikbaar zijn. Hierdoor gaat het meer tijd kosten om de software door meerdere personen te laten testen. Hiernaast hadden we ook nog wat meer tijd kunnen besteden met het nadenken over het ontwerp. Als we hier wat dieper op in waren gegaan hadden we al een implementatie in ons hoofd kunnen uitstippelen, waardoor de implementatiefase misschien gemakkelijker gelopen zou zijn en dat we meer design-issues al tijdens de ontwerpfase afgehandeld zouden hebben. Qua implementatie zijn we van mening dat we volgende keer meer tijd in moeten plannen voor het programmeren zodat alle code wat uniformer wordt. Verder lijkt het ons handig om vaker een release vrij te geven, dit omdat aan het begin van het project de software nog gemakkelijker (ver)vormbaar is. Dit komt van pas als de requirements door het project heen kunnen veranderen.


19

10.

Persoonlijke reflecties

Sander van den Berg Het bachelorproject is begonnen met het vormen van een groepje. In december 2007 heb ik samen met Ronald van Etten en Michel van Tol een groepje gevormd. Ik heb nog nooit samen met een van hen een project gedaan, en daarom leek het mij extra leuk om met hen het bachelorproject uit te voren. Bij het zoeken naar een geschikt bedrijf hebben we ieder een bedrijf uitgekozen en hiermee contact gelegd. Michel legde contact met Matthijs de Weerdt voor een interne opdracht bij de TU zelf en ik had een afspraak gemaakt voor een sollicitatiegesprek bij Fox-IT Delft. Ronald was bij het bedrijf TOPdesk beland, waar hij een afspraak regelde. De sollicitatiegesprekken vonden eind januari 2008 plaats. Na deze gesprekken is gebleken dat voor ons alledrie TOPdesk sterk de voorkeur had. Bovendien hadden zij ons een interessante opdracht te bieden die perfect was voor een bachelorproject. Na TOPdesk ervan op te hoogte hebben gebracht dat wij het project graag bij hen wilden doen hebben we een klein onderzoekje moeten doen dat nodig was alvorens met het project te kunnen beginnen. Eenmaal goedgekeurd konden we daadwerkelijk beginnen bij het bedrijf zelf. Het begon natuurlijk allemaal met een rondleiding, het leren kennen van de medewerkers en het thuis voelen op de werkplek. Vervolgens waren we direct begonnen met de analysefase waarin we allen goed over het probleem na hebben kunnen denken en interviews af hebben kunnen nemen met ir. T.J. Ouwens en ing. R. Spilker. Bovendien hebben we als projectgroep goed met elkaar kunnen discussiëren over de eisen. Tijdens deze fase kwamen we tot de conclusie dat de te ontwikkelen software modulair moest worden en dat het nauw samen dient te werken met een IDE. Tijdens de ontwerpfase hebben we beter moeten nadenken over de modulariteit van het systeem. Hier hebben we een kern en een buitenliggende schil kunnen specificeren. In deze fase hebben wij de kans gehad goed na te denken over hoe een modulair systeem het beste ontworpen kan worden. Bij de projecten en practica van de bacheloropleiding is modulariteit van software nog nooit in de praktijk toegepast. Het is dus erg leerzaam geweest om eindelijk eens een dergelijk systeem te ontwerpen en te bouwen. De implementatie van ons systeem heeft veel leermomenten geboden. Om te beginnen hebben we besloten onze eigen configuratie op te slaan in XML-formaat, waardoor we hebben leren werken met een XML-parser binnen Java. Daarnaast hebben we natuurlijk de modulariteit van het systeem kunnen implementeren en hebben we ervaring op kunnen doen met het maken van Eclipse-plugins. Ook is er nog een implementatie gedaan om SVN-operaties uit te kunnen voeren via een Java toolkit genaamd SVNKit. Verder heb ik nog mijn kennis over Unit testen met JUnit kunnen uitbreiden. Voor het testen van een bepaalde klasse is er gebruik gemaakt van Mock-objecten. Ook hier was ik nog niet mee bekend. Het groepsproces verliep over het algemeen goed, maar niet altijd even soepel. Hier en daar waren er wat onenigheden over het ontwerp van het systeem en de implementatie van bepaalde klassen en methoden. Door goed en kritisch naar elkaar te luisteren en alle mogelijke opties serieus te nemen en te overwegen waren we tot goede besluiten gekomen waar we allemaal achter stonden. Dit heeft geleid tot een goed prototype waar we allemaal zeer tevreden mee zijn.


20

Ronald van Etten Elk project heeft drie verschillende fasen. Ten eerste is er de "opstartfase". Een kenmerk van deze fase is dat alle deelnemers erg enthousiast aan de slag gaan en zoveel mogelijk willen uitvoeren in een zo klein mogelijk tijdsbestek. Ten tweede komt de "clashfase". In deze fase is het vaak zo dat leden van een team tegen onenigheden aanlopen. De laatste fase, de "neuzen-dezelfde-richting-op fase" houdt in dat elk teamlid precies weet wat van hem verwacht wordt en wat hij van andere leden kan verwachten. Een succesvol project doorloopt alle drie de fasen, minder goede projecten stranden in de eerste of tweede fase. Met gepaste trots kan ik mededelen dat ons bachelorproject zeker de derde fase heeft bereikt, wat zeer duidelijk te zien is aan onze wederzijdse aanvullingen. In dit opzicht ben ik zeker tevreden met de gang van zaken tijdens dit project. Nu ik de voortgang op een meta niveau beschreven heb wil ik mij kort richten op de verschillen tussen educatie en werkelijkheid. Verder wil ik nog wat aandacht besteden aan dingen die ik geleerd heb en dingen die ik in het vervolg anders zou willen doen. Qua verschillen tussen educatie en werkelijkheid valt mij als eerste op dat er bij TOPdesk de laatste versie van Java gebruikt wordt om te programmeren, maar bij de TU niet. Dit verschil in versies is opgevangen doordat we in het begin van het Bachelorproject de cursus "Java-met-Roel" gehad hebben. Hierin hebben we allerlei tips en trucs binnen Java geleerd, zoals bijvoorbeeld de enhanced for loop waarvan we veelvuldig gebruik gemaakt hebben. Een ander handige functie die ik nooit zo veelvuldig gebruikt heb zijn de sneltoetsen binnen Eclipse. Hierdoor is het werk een stuk vlotter verlopen dan het zou zijn gegaan zonder hulp van deze sneltoetsen. Aan deze sneltoetsen zit ook een nadeel. Door het veelvuldig gebruik van "ctrl-spatie" binnen Eclipse gebruik ik dat, tot ongenoegen van mezelf, ook in andere programma's en kom er pas verdacht laat achter dat ik niet in Eclipse bezig ben. Tijdens ons bachelorproject zijn mij een aantal dingen opgevallen. Zo is het mij opgevallen dat de tijd razendsnel voorbij vliegt, en dat we hierdoor misschien een iets specifiekere planning hadden moeten maken. In dit project hadden we natuurlijk wel een goede planning maar ik zou een volgende keer, zeker voor mezelf, een duidelijke tijdslijn maken dat ik op elk willekeurig moment exact zou weten waaraan ik aan het werk zou moeten zijn. Hoewel we op het moment van schrijven het bachelorproject nog niet af hebben kan ik al wel terugkijken op een leuke tijd bij TOPdesk die mijn horizon in vele opzichten aardig verbreed heeft.


21

Michel van Tol Mijn bachelorstage bij TOPdesk heb ik als zeer prettig ervaren. Dit is mijn eerste stage bij een bedrijf en direct vanaf de eerste dag was mij duidelijk dat de sfeer er erg open was. Binnen TOPdesk heb ik veel contacten opgedaan, onder andere door de gezamenlijke lunches en de borrels op vrijdagavond. Daarnaast kom je ook collega’s tegen op plekken waar je het niet verwacht, zoals ’s ochtends op het treinstation. Door niet alleen met ontwikkelaars maar ook met verkopers en adviseurs te praten, heb ik een hoop bijgeleerd over de activiteiten binnen een bedrijf. Van de opdracht zelf heb ik ook ontzettend veel geleerd. Allereerst ben ik blij dat we voor deze opdracht gekozen hebben, omdat het me vooraf al een uitdaging leek om dit specifieke probleem op te lossen. Tijdens het onderzoeken wat mogelijk was en hoe we het probleem zouden moeten aanpakken heb ik veel geleerd over zowel de werking van de Java Runtime Environment als de werking van de Eclipse IDE. Ook zijn mijn programmeertechnieken nog verder aangescherpt door de inwerkcursussen die we de eerste weken van onze stage hebben gevolgd, met dank aan Jan Ouwens en Roel Spilker. Ik gebruik vaker dan ooit refactoring en de code wordt mooier en vooral compacter door het veelvuldige gebruik van inlining. Een andere nuttige refactoring vind ik het extraheren van een methode uit een stukje code. Op deze manier wordt code reuse vele malen versimpeld. Als intermezzo hebben we deelgenomen aan een cursus ‘Mango’, de grafische toolkit die TOPdesk zelf gebruikt in al hun nieuwe producten. Vooral ‘WebMango’ vond ik erg leuk omdat dit de laag is die ervoor zorgt dat er met Java een complete website kan worden geprogrammeerd. Zelf heb ik ervaring met talen als HTML, PHP, CSS en JavaScript dus heeft deze cursus me weer een heel nieuw inzicht in webapplicaties gegeven. Het groepsproces tijdens het project heeft me achteraf bekeken een goed gevoel gegeven over het project. Af en toe waren we het uiteraard wel eens oneens met elkaar, maar uiteindelijk zijn we met elkaar iedere keer weer tot een goede oplossing gekomen. Door de problemen met elkaar te bespreken hebben we af en toe goede oplossingen bedacht, die zonder het samenwerken niet zo snel waren opgekomen. Mijn allergrootste leermoment was het maken van de graphical user interface met behulp van SWT. Het onderzoeken hoe dit precies te werk ging heeft me op een goed spoor gezet om vervolgens zelf een interface te implementeren. Zowel met de functionaliteiten die TOPspace biedt als met de grafische weergave ervan ben ik erg tevreden. Dat we met een groepje van drie man sterk in betrekkelijk korte tijd een compleet en toch uitbreidbaar systeem hebben kunnen maken vind ik een leuke vaststelling. Tot slot wil ik de hoop uitspreken dat ons prototype de komende jaren nog veelvuldig en vooral succesvol zal worden gebruikt.


22

Literatuurlijst 1) Doina Klinger (16 december 2002). Creating JFace Wizards. Gevonden op 2 mei 2008, op Eclipse.org: http://www.eclipse.org/articles/Article-JFace%20Wizards/wizardArticle.html 2) Eclipse.org Foundation, Inc. (29 juni 2007). Eclipse SDK. Gevonden op 1 mei op Eclipse.org: http://help.eclipse.org/help32/index.jsp 3) Joshua Bloch (2001). Effective Java Programming Language Guide. Sun Microsystems. 4) Mauro Pezze, Michal Young (2007). Software Testing and Analysis. Wiley. 5) Timothy C. Lethbridge, Robert Laganière (2005). Object-Oriented Software Engineering. McGraw Hill.


23

Bijlage A: Onderzoeksdocument

Onderzoeksverslag stageopdracht “veel modules”

Begeleidend docent: Opdrachtgever: Sander van den Berg Ronald van Etten Michel van Tol

Ir. Hans Geers TOPdesk Delft 1296647 1262947 1263226 April 2008


24

Inhoudsopgave 1. Inleiding 2. Uitleg opdracht 3. Afhankelijkheden van andere projecten 4. Mogelijke eisen 5. Gebruikte methodes 6. Afhankelijk van de volgende data (interfaces) 7. Te gebruiken software 8. Algoritmen en datastructuren 9. Mogelijke implementatie-oplossingen 10. Huidige keuze 11. Mogelijk te gebruiken literatuur


26 26 27 27 27 28 29 29 29 30 30

25

1. Inleiding In dit document gaan wij beschrijven welk onderzoek wij verricht hebben in het derde kwartaal van 2007-2008. Het doel hiervan was het verduidelijken van bepaalde niet genoemde of minder heldere elementen in de opdrachtomschrijving, alsmede het uitdiepen van enige details omtrent onze werkzaamheden. In hoofdstuk 1 beginnen we met het uitleggen van de opdracht zelf. We vervolgen in hoofdstuk 2 met het aanstippen van andere projecten waarvan wij afhankelijk zijn bij de implementatie. Vervolgens gaan we in hoofdstuk 3 een begin maken met de eisen die gesteld kunnen worden aan ons systeem, en welke we dus tijdens de requirements elicitation moeten vastleggen. In hoofdstuk 4 zullen we de door ons gebruikte methoden uitwerken, hierin komen bijvoorbeeld verschillende aspecten van eXtreme Programming aan de orde. Hoofdstuk 5 betreft een opsomming van welke data we afhankelijk zijn (hoe wordt een Ant build script opgeslagen). Het volgende hoofdstuk, hoofdstuk 6, betreft de door ons te gebruiken software. Waarna we in hoofdstuk 7 een blik werpen op de (te maken) algoritmen en datastructuren. Het daarop volgende hoofdstuk, hoofdstuk 8, zullen we gebruiken om een aantal mogelijke oplossingen aan te kaarten, waarna we in hoofdstuk 9 zullen trachten een voorlopige beslissing te maken. In het laatste hoofdstuk, nummer 10 zullen we een overzicht geven van de literatuur welke we zouden kunnen gebruiken.

2. Uitleg opdracht Het project dat wij bij TOPdesk uit gaan voeren is gebaseerd op het volgende probleem: Binnen TOPdesk Enterprise willen we de sourcecode graag zo veel mogelijk in modules opsplitsen. De voordelen daarvan zijn o.a.: - Het team dat verantwoordelijk is voor een module kan eenvoudig wijzigingen in deze module inspecteren. - Ongewenste koppelingen tussen de modules kunnen worden voorkomen . - Het builden testproces wordt eenvoudiger Op dit moment onderscheiden we 35 verschillende modules. Maar graag zouden we er veel meer willen hebben (80+). De reden dat we dat nog niet gedaan hebben is dat het aanmaken en beheren van modules op dit moment veel te moeilijk is. Bij het aanmaken van een nieuwe module moet nu een checklist van 39 stappen worden uitgevoerd. Deze stappen beslaan het toevoegen van de module in ons versiebeheersysteem (SVN), het correct aanmaken en configureren binnen onze IDE Eclipse, het aanpassen van de build-scripts en het toevoegen en configureren van de module aan ons continuous integration system. Daarnaast geldt dat als van één van deze systemen een nieuwe versie uitkomt we alle bestaande configuraties moeten aanpassen om hier optimaal gebruik van te kunnen maken. Het idee achter deze opdracht is dus het stappenplan te automatiseren zodat het niet meer zo arbeidsintensief is. Verder is het de bedoeling dat we een soort van template-methode bouwen waarmee bijvoorbeeld gezegd kan worden "ik wil een module aanmaken analoog aan deze andere module, maar op deze puntjes moet het template wijken voor andere settings". Verder is het erg belangrijk dat ons systeem goed samenwerkt met het Continuous Integration System welke in gebruik is bij TOPdesk, het systeem moet er voor zorgen dat de programmeurs van TOPdesk snel aan de slag kunnen met hun nieuw aangemaakte module. Als laatste aandachtspuntje hebben we dat als er een nieuwe release uitkomt van een van de bij TOPdesk gebruikte programma's, het de bedoeling is dat ons systeem gemakkelijk aan de nieuwe versies aangepast wordt. Ons project bij TOPdesk is een automatiseringsproject waarbij de Eclipse IDE een centrale rol vervult. Het probleem is dat er veel interactie nodig is, dat veel tijd vergt voor de programmeurs. Het handmatig doorlopen van een checklist van ongeveer 40 stappen kost verder teveel moeite voor de programmeurs. De programmeurs besteden deze moeite het liefst aan hun eigen programmeerwerk. Een geautomatiseerd systeem dat ervoor zorgt dat de programmeurs deze stappen niet meer handmatig hoeven te doen zou dus een ideale oplossing zijn.


26

3. Afhankelijkheden van andere projecten Wij zijn met ons project van een aantal andere projecten / software pakketten afhankelijk: Allereerst hebben we natuurlijk Java, als er wederom een nieuwe grote release van Java uit komt dan moet onze code op een dusdanige manier aangepast worden dat het ook met de nieuwe versie van Java overweg kan. Denk hierbij bijvoorbeeld aan een dusdanig grote release als Java 1.5 waarbij er opeens 3 generics en meta-data bijkwamen . Het tweede project waarvan wij afhankelijk zijn is het Eclipse project. Als zij besluiten om bijvoorbeeld te wijzigen waar en hoe zij instellingen opslaan, zullen wij dat ook in ons systeem moeten doorvoeren. Verder kan het zijn dat er nieuwe functionaliteiten bijkomen in Eclipse die ook per project onafhankelijk aangepast moeten kunnen worden, wat ook eenvoudig moet kunnen worden toegevoegd aan ons systeem. De derde categorie projecten waar wij rekening mee dienen te houden zijn de build-scripts die gebruikt worden bij TOPdesk. Ook hier kunnen nieuwere versies van uitkomen of nieuwe functionaliteiten aan worden toegevoegd. Als laatste moet ons systeem rekening houden met het Continuous Integration System welke in gebruik is bij TOPdesk, ook hier moeten we rekening houden met de interface geboden door ons systeem.

4. Mogelijke eisen De eisen die niet expliciet vermeld zijn kunnen bijvoorbeeld de volgende omvatten: Multi-user: Het kan de bedoeling zijn dat er rekening gehouden wordt met de verschillende gebruikers binnen het systeem. Zo zou het bijvoorbeeld goed mogelijk zijn dat alleen een projectmanager bepaalde settings centraal mag wijzigen, en dat gebruikers alleen lokaal mogen testen. Logboek: Het is een goede functionele capaciteit om bij te houden wanneer door welke gebruiker welke aanpassingen gedaan worden, zodat duidelijk gekeken kan worden waardoor welke fout opgetreden is. Hierbij zouden we bijvoorbeeld de eerste build uitvoer kunnen opslaan, waardoor we zien: "Na het aanpassen van die setting door Bert is er een fout opgetreden. Hierdoor is in de runtime het een en ander fout gegaan. Wat is er precies aan de hand?". Bijhouden van configuraties uit het verleden: Deze functionaliteit zouden we kunnen zien als een aanvulling op het logboek, we zouden van een geselecteerd aantal eerdere configuraties kunnen bijhouden zodat we op een makkelijke manier verkeerd ingestelde settings kunnen terugdraaien. Predefined templates voor modules: Een vierde functionaliteit die mogelijk geïmplementeerd dient te worden is om bepaalde templates al in het systeem op te slaan, zodat men direct aan de gang kan gaan met de nieuwe module. Verder moeten de gebruikers in staat zijn een nieuwe template aan te maken.

5. Gebruikte methodes We hebben ons project in vier verschillende fasen opgedeeld namelijk oriëntatie, ontwerp, implementatie+tests en deployment. Deze zien we niet als vaste delen van ons project, maar meer als een richtlijn. Dat wil zeggen dat we ons in deze intervallen voornamelijk gaan focussen op deze vier onafhankelijke fasen. Maar omdat we voor een groot deel op de eigenschappen van Extreme Programming gaan richten zullen we door steeds incrementele updates te reviewen steeds de requirements een klein beetje aanpassen naar wens van de opdrachtgever. Een andere eigenschap van XP die we gaan gebruiken is het zogenaamde pair-programming, dit wil zeggen dat we om beurten met twee personen achter een pc gaan zitten programmeren. Hierdoor is er direct al veel communicatie en code-review mogelijk. Verder is het zo dat we op deze manier de kennis van alle personen onafhankelijk in ons systeem kunnen verwerken, zonder één persoon op te zadelen met enorm veel werk. En tot slot is het een belangrijk gegeven om niet alle kennis in één persoon op te slaan.

3

Sun, New Features and Enhancements J2SE 5.0


27

Verder gaan wij uitermate veel gebruik maken van test-driven-development, waarmee we dus eerst de unit tests schrijven en vervolgens pas onze functies implementeren. Hiermee verplichten wij ons tot het zeker stellen dat alle functies die we moeten implementeren daadwerkelijk en goed geïmplementeerd worden. Het design-by-contract principe is een methode die we zullen aanhangen tijdens het programmeren. Het vierde punt van Extreme Programming wat erg bij ons van toepassing is, is het feit dat onze 'klant' ook een werknemer van TOPdesk is. Deze kunnen we als het nodig is de nodige vragen stellen, ook gaat de klant op vaste milestones (rond de release) zijn mening uiten over het systeem. We gaan een werkweek van minimaal 32 regelmatig, waarschijnlijk eens per twee weken.

uur

per

week

hanteren.

Verder releasen

we

Ons ontwerptraject proberen we te laten verlopen aan de hand van het boek over ontwerpen van 4 Object-georiënteerde systemen van Lethbridge , zoals dat bij Software Engineering deel 1 gebruikt is. Het ontwerpen van de tests zullen we doen aan de hand van het boek van Pezze & Young, zoals dat bij 5 Software Engineering deel 2, Software Testing and Quality Engineering is gebruikt. We willen ons wel fasegewijs bezig houden met het ontwerp, en al vroeg in de ontwikkeling testen. Testen is voor ons geen laatste fase maar een onderdeel van het product dat vanaf het begin af aan veel aandacht verdient. Dit houdt in dat we in een heel vroeg stadium al een parallelle testhiërarchie ontwerpen, waarmee direct een test harness gevormd kan worden.

6. Afhankelijk van de volgende data (interfaces) De stappen die doorlopen worden om een nieuwe module aan te maken zijn onderverdeeld in de volgende categorieën: Eclipse: Eerst moet er een nieuw Subversion (SVN) project aangemaakt worden. Vervolgens moeten de eigenschappen van het Eclipse project ingesteld worden zodat er gebruik gemaakt kan worden van Java 1.6 en zodat project specifieke instellingen gedaan zijn. Ant scripts: Er moeten een aantal aanpassingen gedaan worden aan de targets in bepaalde XML bestanden. Build-scripts: In de nightly build batch file moet de projectnaam toegevoegd worden. Vervolgens moeten de scripts gecommit worden. Cruise control: In het config.xml bestand moeten referenties naar de projectlocaties toegevoegd worden in de bootstrap- en modificationset sectie. Vervolgens moet er een initiële checkout van het project gedaan worden en moet de aangepaste config.xml gecommit worden via subversion. Tot slot: Een e-mail rond sturen om anderen te laten weten dat ze een checkout van het project kunnen doen. Bij TOPdesk wordt gebruik gemaakt van een systeem waarop alle software code wordt verzameld. In de nacht wordt dan een nieuwe versie van het systeem gebouwd. Ons systeem moet in staat zijn om te communiceren met dit centrale systeem, mogelijk wordt onze centrale server-applicatie op dezelfde machine gedraaid als het Continuous Integration System. Naast de nightly build moet ons systeem ook in staat zijn om de verscheidene build-scripts en andere applicaties bij TOPdesk te ondersteunen. Voor ieder van de (sub)systemen die TOPdesk aan zijn klanten verstrekt zijn een aantal build-scripts verantwoordelijk. Als er een nieuwe module gegenereerd wordt, is het de bedoeling dat verwijzingen hiernaar in de bestaande build-scripts of in een nieuw script worden toegevoegd. Als er een nieuwe release uitkomt van bijvoorbeeld de Java Runtime Environment, moet het systeem de nieuwe versie als een extra mogelijkheid aankaarten om een nieuwe module mee te kunnen implementeren. Hierna kan deze nieuwe JRE-versie eventueel in nieuwe templates worden geïntroduceerd.

4 5

T. Lethbridge, Object-Oriented Software Engineering 2nd edition M. Pezzè & M. Young, Software Testing and Analysis


28

7. Te gebruiken software De software waarmee wij van plan zijn te gaan werken zijn de volgende pakketten: Eclipse - De editor die wij gaan gebruiken. Subclipse - Een plugin in Eclipse welke we gaan gebruiken om SVN tijdens ons project zo efficiënt mogelijk te gebruiken. Ant - Ant gebruiken we om Ant build-scripts te kunnen aanmaken voor ons eigen systeem. JUnit - JUnit wordt ons platform dat we gebruiken we om onze unit- en integratietests uit te voeren. XML-parser - Wellicht is er al een licentie binnen TOPdesk of wordt een bepaalde parser al gebruikt, deze gaan wij dan ook in de arm nemen. Als dit niet het geval is gebruiken we SAX, omdat deze sneller is en 6 het niet nodig is om door de XML te bladeren alsof het een boom is . Emma - Om code coverage te meten kunnen we Emma gaan gebruiken. We gebruiken dit samen met Ant, om bijvoorbeeld een code coverage test van een gecompileerd systeem te meten. Mylyn - Wellicht gaan we Mylyn gebruiken, om bugs efficiënt te tracken en op te lossen. Mylyn is een Eclipse plugin.

8. Algoritmen en datastructuren Wij zijn sterk van mening dat we niet een speciaal algoritme hoeven te ontwerpen. We gaan hooguit gebruik maken van de standaard sorteer- en zoekalgoritmen. Op het gebied van datastructuren hebben we verschillende keuzen die we kunnen maken. De keuze bestaat uit het wegschrijven naar plain-text, XML of een database. Omdat we tegenwoordig een trend zien in de richting van het extensief gebruik van XML lijkt het ons een goed idee om hier ook de nodige ervaring mee op te doen. Nu we het opslag gedeelte van datastructuren op de schijf gehad hebben kunnen we ons richten op de datastructuren die binnen een programma zelf gebruikt worden. Binnen het programma gaan we in ieder geval gebruik maken van collections zoals bijvoorbeeld de linked-list om onder andere de settings van een bepaalde module in op te slaan (een gelinkt object met , zodat we ook bij nieuwe settings deze gemakkelijk kunnen toevoegen). Vooralsnog is ons alleen bekend dat er een grote checklist is die afgelopen moet worden om een module te construeren, van ongeveer 40 stappen lengte. We weten nog niet wat de exacte requirements zijn, maar we gaan er van uit dat de stappen onderlinge afhankelijkheden kennen waardoor ze dus alleen op een lineaire, sequentiële manier kunnen worden uitgevoerd. Een eenvoudig lineair looptijd-algoritme zal voldoende zijn. Mocht blijken dat we een sneller algoritme moeten ontwerpen, dan kunnen wij een beroep doen op het 7 boek Algorithm Design . Naar alle waarschijnlijkheid is er geen sprake van routeringproblemen of allocatieproblemen, maar 8 mocht dit wel het geval zijn dan kunnen we het boek Operationele Analyse hierop naslaan . De datastructuren die we willen gebruiken willen we eenvoudig in het gebruik maken. Een mogelijke oplossing is het opslaan van data in XML-bestanden, zoals bijvoorbeeld de Ant-scripts werken.

9. Mogelijke implementatie-oplossingen SERVER - website De eerste mogelijke implementatie-oplossing is erop gericht dat wij een nieuwe server aanmaken die TOPdesk kan gaan draaien. Hierop draait een webserver waarmee gebruikers via hun browser instellingen aan kunnen maken en kunnen veranderen. Het voordeel van deze oplossing is dat we nooit data-inconsistentie problemen kunnen hebben. Een nadeel van deze methode is dat de server binnen de 6

Nazmul Idris, Should I use SAX or DOM Jon Kleinberg & Éva Tardos, Algorithm Design 8 Henk Tijms, Operationele analyse 7


29

SVN repository dingen aanpast, hierdoor is het niet mogelijk om lokaal een kleine test te draaien met specifieke instellingen. De manier waarop we deze methode tot implementatie om kunnen zetten is om een dynamische PHP-site te maken die de configuratie uitleest uit bestanden (XML) of vanuit een database. SERVER - client program De tweede mogelijke implementatie-oplossing is erop gericht dat we alsnog een server maken maar dan de communicatie tussen de server en de programmeur laten verlopen door een apart programma danwel een plugin voor in dit geval Eclipse. Een groot voordeel van deze methode is dat we hierbij wél de mogelijkheid hebben om lokaal instellingen op te slaan. Een probleem van deze methode is wel dat we een extra server moeten gaan draaien. SVN uitbuiten De derde mogelijke implementatie-oplossing is erop gericht om SVN uit te buiten. We maken een programma of een uitbreiding van een programma aan (zoals een Eclipse-plugin), die de data welke zich in de SVN repository bevindt aanpast zodat zowel lokaal als centraal instellingen bijgehouden worden. Om even een instelling te testen kan een gebruiker deze aanpassen, testen, en weer terug zetten (en dan in de tussentijd uiteraard niet comitten). We zouden als toevoeging een instelling in ons systeem kunnen maken van "het is alleen een lokale test". Een nadeel hiervan is dat gebruikers ervoor zorg moeten dragen dat ze niet zomaar committen.

10. Huidige keuze De bedoeling is dat mensen lokaal kunnen testen met bepaalde instellingen, hierdoor is het niet handig om alle informatie alleen remote op te slaan, hierdoor valt server - website al af. Wij hebben voordat we aan het project zijn begonnen sterk de neiging naar het maken van een Eclipse uitbreiding. Dit omdat het ten eerste een mooie ervaring is om eens niet van scratch te beginnen bij een project maar een echt 'uitbreid' project uit te voeren. Ten tweede is er al aardig wat kennis binnen TOPdesk opgebouwd over het maken van een plugin, deze kennis zouden wij kunnen utiliseren. Ten derde worden we op deze manier doormiddel van het framework 'Eclipse' geholpen, dit doordat Eclipse bepaalde functionaliteit biedt die we anders zelf hadden moeten maken (we kunnen met onze plugin gebruik maken van andere plugins).

11. Mogelijk te gebruiken literatuur Eerder in dit verslag verwezen we al naar Lethbridge en Pezzè & Young. Deze boeken zijn naar ons inzien erg geschikt om mee te werken, omdat ze goed beschrijven hoe een Software Engineer te werk zou moeten gaan tijdens een project. Verder hebben we nog een aantal boeken vermeld waarmee we eventueel zouden kunnen werken, zoals boeken over algoritmes, elementaire datastructuren en optimalisering. De lijst hieronder is een overzicht van boeken en andere literatuur waar we mogelijk gebruik van gaan maken tijdens het project: Object-Oriented Software Engineering 2nd edition Practical Software Development using UML and Java Timothy C. Lethbridge, Robert Laganière Beschrijving: In dit boek wordt het softwareontwikkelproces onder de loep genomen. Allerlei handige design patterns passeren er de revue. Software Testing and Analysis Process, principles and techniques Mauro Pezzè and Michal Young Beschrijving: Dit boek gaat dieper in op de essentie van testen. Test-driven development wordt aangeraden en allerlei interessante testmethodieken worden aangereikt. Java Structures 2nd edition Data Structures in Java for the Principled Programmer Duane A. Bailey


30

Beschrijving: Dit boek beschrijft de interne werking van elementaire datastructuren. Deze omvat onder andere de Stack, gelinkte lijsten en de Queue. Met behulp van dit boek is het mogelijk om zelf nuttige datastructuren te ontwerpen en implementeren. Algorithm Design Jon Kleinberg & Éva Tardos Beschrijving: In dit boek worden verschillende algoritmen behandeld, waaronder zoekalgoritmen, greedy algoritmen, dynamic programming. Operationele analyse een inleiding in modellen en methoden Henk Tijms Beschrijving: Dit boek behandelt een basis van mathematisch optimalisering. Problemen zoals allocatieproblemen en logistieke problemen worden opgelost met behulp van simpele modellen. Your first Eclipse Plugin Developing the Eclipse "Hello World" plug-in http://www.eclipse.org/articles/Article-Your%20First%20Plug-in/YourFirstPlugin.html Beschrijving: Een eerste Hello World-plugin voor Eclipse, dit is een standaard tutorial om mee te beginnen. Developing Eclipse Plugins http://www.ibm.com/developerworks/Java/library/os-ecplug/ Beschrijving: Een meer uitgebreid document over het ontwikkelen van Eclipse plugins. Hier wordt onder andere in beschreven hoe een Eclipse plugin aangemaakt wordt. Parsing XML http://Java.sun.com/developer/Books/xmlJava/ch03.pdf Beschrijving: Een beschrijving over Simple API for XML (SAX) en XML parsers in het algemeen. Deze kennis kunnen we gebruiken om XML configfiles te maken en uit te lezen. Extensible Markup Language XML Tutorial http://www.freeJavaguide.com/xml_tutorial.html Beschrijving: Een korte tutorial over XML. Java XML Parsing: SAX vs DOM http://tech.inhelsinki.nl/2007-08-29/ Beschrijving: Een korte vergelijking tussen en SAX en DOM XML-files in een applicatie. Structured XML parsing using SAX http://www.Javalobby.org/Java/forums/t104100.html Beschrijving: Een korte beschrijving over een mogelijke implementatie met SAX.


31

Bijlage B: Plan van Aanpak Voorwoord Dit plan van aanpak document beschrijft de plannen en eisen voor het Bachelor of Science-project "Veel Modules" van de Technische Universiteit Delft. Dit project zal gaan plaatsvinden bij TOPdesk in Delft. 0. Management samenvatting In dit verslag zijn onze besluiten vastgelegd ten aanzien van het traject dat we gaan doorlopen tijdens het uitvoeren van het project. 1. Introductie TOPdesk is een bedrijf die haar sourcecode het liefst zoveel mogelijk in modules op wil splitsen. Gezien het feit dat het een lastige procedure betreft waarmee nieuwe modules aangemaakt worden, is het niet echt heel makkelijk uit te voeren. Dit leidt tot de wens om een systeem te hebben welke al deze lastige stappen voor de gebruiker automatiseert. We bespreken achtereenvolgens de volgende punten. De projectopdracht, de aanpak die wij gaan nemen, de projectinrichting en voorwaarden, onze planning en de kwaliteitsborging. 2. Projectopdracht 2.1 Projectomgeving Bij TOPdesk wordt onder andere helpdesksoftware gemaakt, deze software is van dusdanige grootte dat het handig is om de software zoveel mogelijk op te delen in verschillende modules. Dit omdat dan het verantwoordelijke team efficiënter de modules kan wijzigen en inspecteren. Verder is het op deze manier gemakkelijker om ongewenste koppelingen te voorkomen. Het ontbreken van een dergelijk systeem heeft TOPdesk ertoe gedwongen om zich beperkt te houden in het aantal modules, en dus eigenlijk haar wens niet te kunnen vervullen. 2.2 Doelstelling project De doelstelling van het project is te komen tot een systeem waarmee modules kunnen worden toegevoegd en effectief kunnen worden beheerd en geïnspecteerd. Het systeem moet kunnen samenwerken met Eclipse IDE, SVN en het continuous integration system waarmee TOPdesk werkt. Verder is het de bedoeling dat als er nieuwe versies van bepaalde software uitkomen het programma de nodige aanpassingen maakt en de build scripts ook weer up-to-date brengt. 2.3 Opdrachtformulering De opdracht is het ontwikkelen van een systeem waarmee het toevoegen van modules vereenvoudigd wordt. Het idee hierbij is dat we aan alle hierboven genoemde doelstellingen voldoen (SVN, IDE, CIS & build scripts) en dat we aan het einde van de stage periode (omtrent eind juni) een werkend systeem opleveren. 2.4 Op te leveren producten en diensten Het op te leveren product betreft het hiervoor beschreven systeem. 2.5 Eisen en beperkingen De volgende eisen zijn gesteld: - het systeem moet op een overzichtelijke manier modules kunnen toevoegen en beheren - alle configuraties van een module moeten kunnen worden aangepast - het systeem moet in goede samenwerking zijn met de bestaande SVN, IDE, CIS en build scripts - er moet een update functionaliteit aanwezig zijn voor het geval er nieuwe versies van gebruikte software uitkomen - er dient veelvuldig gebruik gemaakt te worden van Extreme programming 2.6 Cruciale succesfactoren De factoren die vanuit de opdrachtgever gezien essentieel zijn, omvatten de Java programmeerervaring, de samenwerking en de formele verslaglegging (denk aan presentaties en documentatie).


32

3. Aanpak Wij hebben voor de aanpak van ons project gekozen voor een gefaseerde aanpak, we onderscheiden de volgende fasen: a. Oriëntatie a.1 Domein analyse a.2 Requirements analyse a.3 Use Cases opstellen b. Ontwerp b.1 Globale ontwerp van systeem b.2 Testplan en implementatieplan opstellen c. Implementatie d. (Deployment, project open source maken) 4. Projectinrichting en voorwaarden 4.1 Projectinrichting De volgende OPAFIT-aspecten zijn van belang: • Organisatie rondom het project: - Ir. J. Ouwens, opdrachtgever vanuit TOPdesk - Ing. R. Spilker, senior software ontwikkelaar, TOPdesk Delft, Mentor • Het personeel van TOPdesk is een van de gebruikers, immers het plan is er om het project achteraf open-source te maken • De administratieve procedures die van toepassing zijn, zijn het Plan van Aanpak, het Requirements Analysis Document, het ontwerp document en het eindverslag • De financiering is niet van toepassing omdat alle faciliteiten door TOPdesk aangeleverd worden • Voor informatie over de modules kunnen we terecht bij de opdrachtgever. Mochten we eventueel vragen hebben zal er de nodige informatie uitgewisseld kunnen worden. Voor en na elke werkdag zullen we onderling een kleine reflectie/planning sessie houden. • De techniek die TOPdesk voornamelijk gebruikt is vooral gericht op Java. Verder gebruikt TOPdesk SVN voor versioning en een continous integration system. Het systeem wordt geacht hiermee rekening te houden, alsmede met build scripts. De TOPdesk-systemen draaien op verschillende platforms zoals Windows en Linux. 4.2 Voorwaarden aan opdrachtnemer Er moet door de opdrachtnemers worden nagedacht over mogelijke oplossingen. De opdrachtnemers moeten actief, leergierig en gemotiveerd van aard zijn. De opdrachtnemer moet de adviezen van de opdrachtgever in acht nemen. Na 12 weken is er door de opdrachtnemers een eerste werkende versie van het systeem opgeleverd. Het systeem moet makkelijk onderhoudbaar en uitbreidbaar zijn, dit kan bereikt worden door goede documentatie en commentaar bij de sourcecode. De opdrachtnemers moeten voldoen aan een werkweek van 32 uur. 4.3 Voorwaarden aan opdrachtgever Bij onduidelijkheden moet de opdrachtgever open staan voor vragen. Op vaste momenten, zoals rond de tweewekelijkse release, zullen de opdrachtnemers aan de opdrachtgevers vragen om een review. Verder wensen de opdrachtnemers vragen via bijvoorbeeld e-mail te kunnen stellen waar nodig. 4.4 Voorwaarden aan derden De derden (medewerkers van TOPdesk) moeten de opdrachtnemers de mogelijkheid geven om het systeem te kunnen ontwikkelen. Er moet ruimte gereserveerd worden (al dan niet op een server) waarop het systeem getest kan worden. Het is wenselijk dat de derden zowel gevraagd als ongevraagd advies geven.


33

5. Planning

Tijdens deze fasen vinden er nog formele activiteiten plaats zoals het maken van documenten en het houden van presentaties. Bovendien hebben we in de planning één week speling gehouden. Mocht het zo zijn dat een deadline niet word gehaald, dan kunnen wij gebruik maken van deze speling. 6. Kwaliteitsborging 6.1 Productkwaliteit Intuïtiviteit Data-integriteit Regressiviteit (update-functie) eventueel: 'Last working' configuration

Geen leercurve nodig voor gebruik (elke actie moet binnen een tiental muisklikken geregeld kunnen worden). De settings mogen niet verloren gaan. Bij nieuwe software-versies moet het systeem blijven werken. Updates/revisies van configuraties bijhouden.

6.2 Proceskwaliteit De ontwikkelmethoden die we gaan gebruiken zijn onderdelen uit het Extreme Programming-model en het Cascade-model. We stellen een testplan op om risico's zoveel mogelijk uit te sluiten en bovenstaande eisen te garanderen.


34

Bijlage 1: opdracht zoals uitgegeven door TOPdesk Opdracht “Veel modules” Achtergrond Binnen TOPdesk Enterprise willen we de sourcecode graag zo veel mogelijk in modules opsplitsen. De voordelen daarvan zijn o.a.: - Het team dat verantwoordelijk is voor een module kan eenvoudig wijzigingen in deze module inspecteren. - Ongewenste koppelingen tussen de modules kunnen worden voorkomen. - Het builden testproces wordt eenvoudiger Op dit moment onderscheiden we 35 verschillende modules. Maar graag zouden we er veel meer willen hebben (80+). De reden dat we dat nog niet gedaan hebben is dat het aanmaken en beheren van modules op dit moment veel te moeilijk is. Bij het aanmaken van een nieuwe module moet nu een checklist van 39 stappen worden uitgevoerd. Deze stappen beslaan het toevoegen van de module in ons versiebeheersysteem (SVN), het correct aanmaken en configureren binnen onze IDE Eclipse, het aanpassen van de build-scripts en het toevoegen en configureren van de module aan ons continuous integration system. Daarnaast geldt dat als van één van deze systemen een nieuwe versie uitkomt we alle bestaande configuraties moeten aanpassen om hier optimaal gebruik van te kunnen maken. Opdracht De opdracht is om een systeem te ontwikkelen waarmee het toevoegen van modules vereenvoudigd wordt, en het aanpassen van de configuraties vanuit een centraal systeem kan worden doorgevoerd. Hierbij moet per module kunnen worden aangegeven welke afhankelijkheden hij heeft en welke uitzonderingen op deze module van toepassing zijn.


35

Bijlage C: Requirements Analysis Document

Requirement Analysis Document TOPdesk: veel modules



36

Inhoudsopgave 1. Inleiding 38 2. Probleemomschrijving 39 3. Requirements 40 3.1. Definities .................................................................................................................................................................... 40 3.2. Omgeving................................................................................................................................................................... 41 3.3. Functionele requirements..................................................................................................................................... 42 3.4. Non-functionele requirements............................................................................................................................ 43 4. Scenario’s 44 5. Use Case modellen 46 5.1. Use Case diagram .................................................................................................................................................... 46 5.2. Use Cases ................................................................................................................................................................... 47 Bijlage 1: Settings 50


37

1. Inleiding Dit document is bedoeld om een inzicht te geven in het probleem dat wij benaderen en de requirements die aan onze oplossing worden gesteld. In hoofdstuk 2 zetten we het probleem uit waar TOPdesk mee kampt en welke wij gaan aanpakken. We geven hierin de huidige situatie weer en wat er van ons verwacht wordt als we een oplossing uit gaan werken. In hoofdstuk 3 geven we de requirements weer. In dit hoofdstuk zullen we ten eerste definities uitwerken die in onze documenten kunnen worden gebruikt. Hierna volgt een beschrijving van de werkomgeving van ons te bouwen systeem. Hierin worden voornamelijk het platform en software(versies) uitgewerkt. Vervolgens stellen we de functionele requirements voor ons systeem op en tot slot worden ook de niet-functionele eisen weergegeven. In hoofdstuk 4 worden scenario’s omschreven, waarna we aan de hand hiervan in hoofdstuk 5 verscheidene use-cases opstellen.


38

2. Probleemomschrijving Bij TOPdesk Delft en Kaiserslautern (Duitsland) worden applicaties gemaakt binnen de Eclipse IDE met Java. Eclipse staat de programmeur toe om projecten te maken, waardoor op een functionele manier code gescheiden kan worden. Op deze manier kan op een overzichtelijke manier sourcecode van de applicatie TOPdesk gescheiden worden in projecten die aparte verantwoordelijkheden hebben. Een gevolg van deze aanpak is dat de projecten afhankelijk worden van andere projecten. Dit houdt in dat sommige projecten gecompileerd moeten zijn voor de volgende gecompileerd kunnen worden. Bij TOPdesk wordt gebruik gemaakt van verschillende systemen, waaronder SVN (Subversion) om de sourcecode te beheren. In de nacht worden builds gemaakt van de TOPdesk projecten op een aparte buildserver. De sourcecode die dan op SVN staat wordt gecompileerd en de unit tests worden uitgevoerd. Deze build wordt onder andere gebruikt om functioneel te testen door de testafdeling van de firma TOPdesk en wordt daarom bewaard. De ‘sneak preview’ server bevat de laatste build die onder andere gebruikt wordt om mee te testen. Verder kan de interface worden gebruikt om demonstraties mee te geven voor klanten. De sourcecode van de applicatie TOPdesk wordt verder door de dag heen regelmatig gebuild op dezelfde buildserver met het programma CruiseControl die de builds inplant. De resultaten van deze build worden gepubliceerd zodat de programmeurs kunnen zien of er errors zijn in de code en of alle unit tests nog slagen. De code wordt ook hier door de buildserver uit SVN gehaald, gecompileerd en getest. Het enige wat bewaard wordt zijn de logbestanden die gegenereerd worden door de build. Deze worden gebruikt door de programmeurs om te controleren of er problemen zijn geconstateerd waardoor de nightly build mogelijk niet succesvol kan worden uitgevoerd. CruiseControl heeft een front-end die de resultaten van de build kan laten zien zodanig dat de ontwikkelaars de status van het systeem op dat moment kunnen zien. De buildserver gebruikt op dit moment Ant om te builden, in de toekomst wil TOPdesk waarschijnlijk overstappen op Maven. De complicatie ligt nu in het feit dat handmatig alle scripts en tools moeten worden aangepast en ingesteld voor ieder toe te voegen project. Een voorbeeld van een taak is het bijwerken van het master build-script. Het nieuw aan te maken project moet aan dit script toegevoegd worden. De takenlijst (zie bijlage 1) bestaat op dit moment uit ongeveer 40 stappen en is erg foutgevoelig. De taak aan ons is om dit proces te automatiseren. Dit houdt dus in dat het door ons te bouwen systeem de Ant/Maven build scripts aanmaakt of aanpast. De SVN repository maakt een bestandshiërarchie aan, en daarin worden files zoals o.a. de Eclipse settings files opgeslagen. Het doel van ons systeem is dat er op deze manier veel tijd kan worden bespaard en er minder fouten worden gemaakt. Verder is het van belang dat van tevoren kan worden bepaald of de nightly build zal slagen. Op dit moment is de complexiteit van het toevoegen van een project te groot, wat TOPdesk ervan weerhoudt om meer projecten aan te maken. Ons systeem moet het mogelijk maken dat TOPdesk ook daadwerkelijk meer projecten kan aanmaken en dat dit ook correct werkt. Ook het onderhoud is een belangrijke issue, bij meer projecten is de kans groter dat er fouten optreden. Het moet dan ook mogelijk gemaakt worden om te kunnen zien wat er fout gaat, zodat dit snel en accuraat kan worden opgelost.


39

3. Requirements In dit hoofdstuk behandelen we achtereenvolgens de gehanteerde definities, waarin wij een lijstje opstellen met termen die wij in onze verslagen zullen gebruiken. Hierna zullen we een korte omschrijving van de omgevingseisen geven. Vervolgens zullen we de functionele en niet-functionele requirements in een lijst met uitleg weergeven. Verder geven we aan hoe de prioriteiten verdeeld zijn tussen de requirements.

3.1. Definities De volgende termen zullen we gebruiken in dit (en de volgende) verslag(en), hier volgt een korte uitleg. Ant Ant is een build tool waarmee programmeurs builds kunnen maken, unit tests kunnen uitvoeren en externe tools kunnen aanroepen. Ook tools als Javadoc kunnen aangeroepen worden door Ant. Build Het volledig compileren van een project (CodeBunch) of een volledig systeem bestaande uit projecten (CodeBunches) naar een direct distribueerbaar formaat, dat direct gebruikt kan worden door de gebruikers. Build script Een build script bevat taken die uitgevoerd moeten worden door een build tool zoals Ant of Maven. Changeset Bestanden die op het systeem van de gebruiker aangepast of verwijderd zijn, en doorgevoerd moeten worden aan SVN. CodeBunch Op dit moment een Eclipse-project, gekoppeld aan Ant, maar mogelijk later een ‘project’ voor een andere tool gekoppeld aan bijvoorbeeld Maven. Een CodeBunch bevat de sourcecode die de gebruikersmodules vormt. CruiseControl CruiseControl is een programma dat constant builds maakt. De tool heeft een front-end die werkt als diagnostisch middel om te controleren of de nightly build geslaagd is. Eclipse Eclipse is een Integrated Development Environment waarin programmeurs eenvoudig kunnen programmeren in Java. Code wordt meestal opgeslagen in projecten. Eclipse kent verder een aantal aanvullende functionaliteiten in de vorm van zogenaamde plugins. (Verder bevat Eclipse veel refactoring-tools. Op deze manier kan er d.m.v. sneltoetsen efficiënt gewerkt worden). Eclipse-plugin Een Eclipse-plugin verzorgt bijna altijd een zelfstandige taak. Sommige plugins, zoals Subversive en Subclipse, zorgen bijvoorbeeld voor communicatie met SVN-repositories. Maven Maven is een build-tool, waarin meer functionaliteit geautomatiseerd is dan in Ant. Module Om ambiguïteit te voorkomen gebruiken we deze term voor de code die TOPspace gaat beheren. TOPdesk maakt ‘gebruikersmodules’ voor klanten, en hanteert tegelijkertijd de term ‘modules’ voor Eclipse-projecten. De gebruikersmodules die TOPdesk voor klanten maakt worden aangeduid als ‘TOPdesk modules’. Wanneer ‘module’ als woord gebruikt wordt in dit document dan wordt hiermee een CodeBunch bedoeld.


40

Subversion Subversion, kortweg SVN, is een gereedschap waarmee sourcecode beheerd kan worden. Hiermee kunnen meerdere gebruikers tegelijk gebruik maken van dezelfde bestanden en deze delen met elkaar. Aanpassingen in een bestand kunnen simpel worden gedeeld met andere gebruikers. Template Build script template Een build script template is een default-configuratie voor een build script. In een template staan geen afhankelijkheden. Deze worden door TOPspace toegevoegd bij het aanmaken van een CodeBunch. Instellingen-template Een instellingen-template bevat een default-configuratie voor de instellingen van een CodeBunch. TOPspace De naam van ons product. De naam is samengesteld als TOP en space, waarbij ‘TOP’ verwijst naar TOPdesk en ‘space’ naar het feit dat ons product een workspace management tool is. TOPspace systeemmodule Een TOPspace systeemmodule is een implementatie van een abstracte klasse die binnen het door ons te maken systeem voor een bepaalde stap of dataopslag de verantwoordelijkheid heeft. Deze systeemmodules zijn eenvoudig aan ons systeem te koppelen, zodat de nieuwe functionaliteit beschikbaar is. Workspace Een map waarin alle Eclipse-projecten danwel CodeBunches van de gebruiker zijn opgeslagen.

3.2. Omgeving Het idee is dat ons programma op de minst snelle computer moet draaien die bij TOPdesk aanwezig is. Na kort onderzoek is gebleken dat dit een computer betreft met: 3Ghz Pentium 4 met 2048 Mb RAM aan boord, welke draait op Windows 2000 Service Pack 4. De door ons te ontwikkelen software moet kunnen worden uitgevoerd met Java JDK 6.0. Gezien de uitbreidbaarheid is het handig als we ook testen of het systeem ook op Linux en Solaris werkt, maar dit heeft geen hoge prioriteit. Een andere eis aan de omgeving is dat we moeten uitkijken met de naamgeving van onze bestanden, gezien het feit dat de bestandsystemen waar Linux op draait wél hoofdlettergevoelig zijn maar die van Windows niet. De applicatie moet op dit moment zodanig worden ontworpen dat het in ieder geval samen werkt met Eclipse 3.3, Ant 1.7, CruiseControl 2.7.1 en Subversion server-versie 1.1.4.


41

3.3. Functionele requirements De requirements worden gerangschikt op prioriteit door de laatste vier kolommen. De kolom ‘M’ staat voor requirements die in ons systeem moeten worden verwerkt (must have). De kolom ‘S’ geeft de requirements weer die we zouden moeten verwerken in ons systeem (should have). In de derde kolom, worden de requirements weergegeven die we zouden kunnen inbouwen, de zogenaamde could haverequirements (‘C’). Tot slot zijn er requirements die we misschien kunnen inbouwen in een latere versie. Deze worden aangegeven met de ‘W’ van would like to have. Requirement met beschrijving 1.1 Settings/Stappen De settings die getoond worden in bijlage 1 moeten door ons systeem worden geïmplementeerd. 1.2 Data/Sourcecode Het systeem haalt de benodigde data van SVN, past deze aan en zet het eventueel weer terug. 1.3 Templates Het systeem moet het gebruik van zowel instellingen- als build script templates ondersteunen, wat het instellen van een aantal settings vergemakkelijkt door standaard waarden te gebruiken. 1.4 Aanpasbaarheid template De templates die gebruikt worden dienen gemakkelijk aangepast te kunnen worden. Hierin moet ook kunnen worden aangegeven dat er een andere bestandshiërarchie gekozen wordt. 1.5 Changeset Het systeem moet een changeset kunnen tonen, hiermee worden de veranderingen weergegeven. 1.6a Logbestanden Het systeem moet duidelijke logbestanden bijhouden, waardoor op elk moment kan nagegaan worden wat en wanneer er fout is gegaan. 1.6b Foutenherstel Bij een foutieve uitvoering van het systeem moet bij een volgende start (of direct) weergeven dat er iets fout is gegaan en mogelijkerwijs het probleem herstellen. 1.7 Eclipse settings De CodeBunch settings, maar in het bijzonder de errors en warnings moeten kunnen worden ingesteld. 1.8 Projectafhankelijkheden Het systeem moet projectafhankelijkheden aangeven 1.9 Projecten verwijderen Een functionaliteit om projecten te verwijderen.

M

S

C

W

X X

X

X

X X

X

X X X

Tabel 1: Functionele requirements


42

3.4. Non-functionele requirements Requirement met beschrijving 2.1 Engelstalig Ons systeem is Engelstalig, zo ook de code en de comments. 2.2 Uitbreidbaarheid Het systeem moet eenvoudig uitbreidbaar zijn, om toekomstige upgrades mogelijk te maken. 2.3a Onderhoudbaarheid De sourcecode van ons systeem moet goed leesbaar zijn. 2.3b Javadoc Voor onze tool genereren we Javadoc documentatie. 2.4 Bestandsnamen Bestandsnamen moeten zodanig gekozen worden, zodat platformafhankelijkheden voorkomen worden. 2.5 Implementatievorm Er zijn effectief geen implementatievormen voorgeschreven, dit wil zeggen dat wij zelf tijdens de ontwerpfase een implementatievorm kunnen kiezen. We maken in de design-fase een afweging tussen de mogelijke implementatievormen en kiezen de vorm die het beste aansluit bij de tijd en de requirements. 2.6 Stappen De lijst met stappen die we in ons onderzoeksdocument hebben aangevoerd zijn in principe niet sequentieel. De laatste stap moet het instellen van CruiseControl zijn. Verder hoeven deze stappen niet parallel uitgevoerd te worden. 2.7a Modulariteit van het ontwerp Het systeem moet modulair zijn opgebouwd, waardoor het toevoegen of aanpassen van systeemmodules die stappen uitvoeren danwel dataopslag verzorgen makkelijk te realiseren is. 2.7b Andere programmaversie/programma’s Door 2.7a te realiseren is het mogelijk om andere programma’s dan de huidige (b.v. Maven i.p.v. Ant) aan het systeem te koppelen. 2.8 Dynamische instellingen In onze sourcecode moet qua functionaliteit niets gehardcoded worden. Dit betekent dat de eigenschappen voor bijvoorbeeld externe programma’s niet in onze code mogen voorkomen. 2.9 Resource usage Het is van belang dat het systeem werkt op het bij ‘omgeving’ gedefinieerde systeem.

M

S

C

W

X X X X X

X

X

X

X

X

X

Tabel 2: Niet-functionele requirements


43

4. Scenario’s In dit hoofdstuk beschrijven we een aantal scenario’s die uitvoerbaar zijn op ons systeem. Het hoofddoel is het achteraf checken of alle functionele requirements vervuld zijn. Een tweede doel hiervan is om de lezer van dit document een idee te geven van de functionele werking van het systeem, voordat deze werkelijk geïmplementeerd is. Scenario 1: Project bekijken Gebruiker: Jan, softwareontwikkelaar Jan heeft het project ‘veel modules’ toegevoegd, maar is vergeten welke instellingen hij precies gemaakt heeft. Om dit te achterhalen selecteert Jan het project ‘veel modules’ waarna hij ‘project bekijken’ kiest. Deze actie heeft tot gevolg dat het systeem alle instellingen (op dit moment 367, b.v. warnings als een lokale variabele niet gebruikt wordt) en afhankelijkheden van het betreffende project naar andere projecten weergeeft. Nadat Jan alle instellingen bekeken heeft bevestigd Jan dat hij het gezien heeft en keert het systeem terug naar het keuzemenu. Scenario 2: Template bekijken Gebruiker: Jan-Willem, softwareontwikkelaar Jan-Willem wil graag een eerder toegevoegde template bekijken. Dit doet hij door in het systeem een template te selecteren en voor ‘template bekijken’ te kiezen. Na het bekijken van de instellingen bevestigd Jan-Willem dat hij de instellingen gezien heeft en gaat het systeem terug naar het keuzemenu. Scenario 3: Project aanpassen Gebruiker: Roel, softwareontwikkelaar Roel heeft in de ochtend een nieuw project aangemaakt, maar toen hij de settings liet controleren door zijn collega’s kwamen zij erachter dat een bepaalde setting niet correct is voor het project. Het aangemaakte project diende dus aangepast te worden. Roel start het systeem waarna hij het nieuwe project selecteert. Hij kiest nu voor ‘Aanpassen’ waarna het systeem de instellingen van het project weergeeft. Roel kan nu de onjuiste instellingen wijzigen en kiezen voor ‘Opslaan’ waardoor het systeem een changeset aanmaakt. Hij bevestigt om vervolgens terug te keren naar het keuzemenu, waar hij de changeset kan committen. Scenario 4: Template aanpassen Gebruiker: Karina, softwareontwikkelaar Karina heeft de opdracht gekregen om de standaardinstellingen in een template aan te passen. Zij gaat als volgt te werk: Om te beginnen selecteert ze een template en vervolgens kiest ze ‘template aanpassen’ waardoor het systeem de gewenste template weergeeft. Nu kan zij aanpassingen maken en ervoor kiezen om de gemaakte aanpassingen op te slaan waarna ze weer terugkeert naar het keuzemenu. Hierna heeft zij de mogelijkheid om de changeset voor de template te committen. Scenario 5: Project toevoegen – template Gebruiker: Bert, softwareontwikkelaar Bert heeft de taak gekregen een nieuw project aan te maken. Om dit te bewerkstelligen besluit hij om het nieuwe project analoog aan een bestaande template te maken. Dit doet hij door de betreffende template te selecteren en te kiezen voor ‘Project aanmaken’. Het systeem geeft nu de lijst met instellingen weer die de Bert kan maken. Bert vult alle instellingen in, geeft de afhankelijkheden aan en kiest voor ‘Ok’. Na deze actie heeft het systeem een changeset aangemaakt die gecommit kan worden en bevindt Bert zich weer in het keuzemenu.


44

Scenario 6: Project toevoegen – handmatig Gebruiker: Willem, softwareontwikkelaar Willem, de nieuwe stagiair bij TOPdesk, heeft de opdracht gekregen om een nieuw project toe te voegen met specifieke eisen. Hem is verteld dat er nog geen template bestaat dat grotendeels aan deze eisen voldoet. Dus besluit Willem om een nieuw project aan te maken waarin hij handmatig alle instellingen aanbrengt, dit doet hij door voor ‘Nieuw project’ te kiezen. Het systeem geeft vervolgens een lijst met instellingen weer die Willem moet invullen. Ook moet Willem de afhankelijkheden aangeven. Na een bevestiging genereert het systeem een changeset die gecommit kan worden en keert Willem terug naar het keuzemenu. Scenario 7: Template toevoegen Gebruiker: Els, softwareontwikkelaar Els is van mening dat er te veel tijd verloren gaat door het niet gebruiken van templates. Zij heeft besloten om een template te gaan maken die in het vervolg bij het aanmaken van een nieuw project gebruikt kan worden. Dit doet zij door de optie ‘Nieuwe template’ te kiezen. Hierdoor krijgt zij de mogelijkheid om de instellingen van de template in te voeren, waarna zij de mogelijkheid heeft om de gemaakte template op te slaan. Het systeem keert hierna terug naar het keuzemenu. De template kan nu in gebruik genomen worden. Scenario 8: Template verwijderen Gebruiker: Kees, softwareontwikkelaar Omdat de template ‘nooit_gebruiken’ nooit gebruikt wordt om een nieuw project aan te maken, is besloten om deze maar te verwijderen. Kees heeft deze taak op zich genomen en hij voert hem uit door de template ‘nooit_gebruiken’ te selecteren en voor ‘Verwijderen’ te kiezen. Het systeem vraagt aan Kees of hij zeker weet dat hij de template wil verwijderen. Kees bevestigt zijn keuze en er wordt een changeset gemaakt die specificeert dat de template ‘nooit_gebruiken’ van de SVN server verwijderd mag worden. Scenario 9: Systeemmodule toevoegen/wijzigen Gebruiker: Jorn, softwareontwikkelaar Omdat er besloten is een nieuwe stap toe te voegen voor het aanmaken van een module zal er een nieuwe systeemmodule toegevoegd moeten worden aan het systeem om dit te realiseren. Jorn zet de systeemmodule in een door het systeem gespecificeerde map en geeft aan binnen het systeem dat de nieuwe systeemmodule gebruikt dient te worden.


45

5. Use Case modellen In dit hoofdstuk worden de Use Cases besproken. Eerst geven wij het door ons gemaakte Use Case diagram waarin de relaties te zien zijn tussen verschillende functionaliteiten en de gebruiker. De include laat zien dat als je bijvoorbeeld een template gaat aanpassen, dat je dan ook de functionaliteit van ‘Template bekijken’ gebruikt. De changeset committen is het gevolg van een van de acties van aanmaken, verwijderen en bewerken, in UML heet dit ‘extensie’ van use cases.

5.1. Use Case diagram In figuur 1 is een Use Case diagram te zien, waarin is weergegeven welke interacties ons systeem moet ondersteunen. Deze zijn in de volgende paragrafen verder uitgewerkt.

Figuur 1: Use Case diagram van het te ontwerpen systeem


46

5.2. Use Cases Use Case 1: Project toevoegen – Template Actoren: Gebruiker Doel: Het toevoegen van een project aan de hand van een bestaand template Precondities: Het systeem is gestart en er zijn een of meerdere templates beschikbaar Samenvatting: De gebruiker voegt een project toe aan de hand van een bestaande template, dit wordt gedaan door eerst de template te laten zien zodat de gebruiker er aanpassingen in kan maken en het dan op kan slaan als een nieuwe changeset. Gerelateerde use cases: Template bekijken Stappen: Gebruikersacties Systeemreacties 1. De gebruiker selecteert een template en kiest 2 . Het systeem geeft een nieuw scherm weer voor ‘Project aanmaken’ waarop de naam en de afhankelijkheden van het nieuwe project opgegeven dienen te worden. De settings worden gemaakt aan de hand van de geselecteerde template dat zichtbaar is. 3. De gebruiker wijzigt 0 of meer settings en kiest 4. Het systeem genereert de changeset en geeft voor ‘Opslaan’ een melding aan de gebruiker 5. De gebruiker kiest voor ‘Ok’ waarmee hij 6. Het systeem geeft het keuzemenu weer met de aangeeft terug te keren naar het keuzemenu extra optie om de changeset te committen in SVN Postcondities: De changeset is aangemaakt en is klaar om gecommit te worden. Use Case 2: Project toevoegen – handmatig Actoren: Gebruiker Doel: Het handmatig toevoegen van een project. Precondities: Het systeem is gestart. Samenvatting: De gebruiker voegt handmatig een project toe. Dit kan hij doen door bepaalde settings in te stellen. Stappen: Gebruikersacties Systeemreacties 1. De gebruiker kiest voor ‘nieuw project’ 2 . Het systeem laat een nieuw venster waarop de settings te zien zijn die ingesteld kunnen worden. 3. De gebruiker stelt de settings naar wens in. Ook 4. Het systeem genereert de changeset en geeft geeft de gebruiker een projectnaam op en de een melding aan de gebruiker afhankelijkheden van het project aan en kiest voor ‘Aanmaken’ 5. De gebruiker kiest voor ‘Ok’ waarmee hij 6. Het systeem geeft het keuzemenu weer met de aangeeft terug te keren naar het keuzemenu extra optie om de changeset te committen in SVN Postcondities: De changeset is aangemaakt en is klaar om gecommit te worden. Use Case 3: Changeset committen Actoren: Gebruiker Doel: Het committen van de changeset naar SVN Precondities: Het systeem is gestart en er is een changeset beschikbaar Samenvatting: De gebruiker heeft zojuist een changeset aangemaakt, welke opgeslagen is. Deze changeset wordt nu tot de gebruiker gecommit naar SVN. Gerelateerde use cases: Project toevoegen – Template, Project toevoegen – Handmatig, Template toevoegen, Template aanpassen, Project aanpassen Stappen: Gebruikersacties Systeemreacties 2 . Het systeem commit de changeset naar SVN en 1. De gebruiker kiest de optie ‘changeset laat een statusrapport zien committen’ nadat hij een project heeft aangemaakt 3. De gebruiker kiest de optie ‘okay’ 4. Het systeem geeft het keuzemenu weer Postcondities: De changeset is gecommit, het systeem laat het keuzemenu zien.


47

Use Case 4: Project aanpassen Actoren: Gebruiker Doel: Het maken van een changeset voor een bestaand project Precondities: Het systeem is gestart en er bestaan een of meerdere projecten Samenvatting: De gebruiker gaat een bestaand project aanpassen, waarin hij bepaalde settings wijzigt Gerelateerde use cases: Project bekijken Stappen: Gebruikersacties Systeemreacties 2 . Het systeem toont een nieuw scherm waarin 1. De gebruiker kiest het project dat aangepast de instellingen en de afhankelijkheden van het dient te worden uit de lijst met projecten en kiest project zijn te zien voor ‘Project aanpassen’ 3. De gebruiker past nu afhankelijkheden en 4. Het systeem genereert een changeset en geeft settings aan en kiest voor ‘Opslaan’ om de een melding aan de gebruiker aangepaste instellingen op te slaan 5. De gebruikt kiest voor ‘Ok’ waarmee hij 6. Het systeem geeft het keuzemenu weer, met de aangeeft terug te keren naar het keuzemenu extra optie om deze changeset te committen Postcondities: De changeset is aangemaakt en is klaar om gecommit te worden Use Case 5: Project bekijken Actoren: Gebruiker Doel: Het bekijken van een bestaand project Precondities: Het systeem is gestart en er bestaan een of meerdere projecten Samenvatting: De gebruiker zou graag de settings van een bepaald project willen bekijken om het project te controleren op settings. Stappen: Gebruikersacties Systeemreacties 1. De gebruiker selecteert een project en kiest voor 2 . Het systeem toont een nieuw scherm waarop ‘Project bekijken’ de afhankelijkheden en settings van het betreffende project te zien zijn 3. De gebruiker kiest voor ‘Ok’ om aan te geven 4. Het systeem keert terug naar het keuzemenu dat hij de afhankelijkheden en settings bekeken heeft en terug wil keren naar het keuzemenu Use Case 6: Template aanpassen Actoren: Gebruiker Doel: Het maken van een changeset voor een bestaand template Precondities: Het systeem is gestart en er bestaan een of meerdere templates Samenvatting: De gebruiker zou graag een changeset aanmaken voor een bestaande template, waarin hij bepaalde settings aanpast Gerelateerde use cases: Template bekijken Stappen: Gebruikersacties Systeemreacties 1. De gebruiker kiest de template dat aangepast 2 . Het systeem toont een nieuw scherm waarin dient te worden uit de lijst met projecten en kiest de instellingen van de template zijn te zien voor ‘Template aanpassen’ 4. Het systeem genereert een changeset en geeft 3. De gebruiker heeft nu de mogelijkheid om een melding aan de gebruiker settings aan te passen en kiest voor ‘Opslaan’ om de aangepaste instellingen op te slaan 5. De gebruikt kiest voor ‘Ok’ waarmee hij 6. Het systeem geeft het keuzemenu weer, met de aangeeft terug te keren naar het keuzemenu extra optie om deze changeset te committen Postcondities: De changeset is aangemaakt en is klaar om gecommit te worden


48

Use Case 7: Template bekijken Actoren: Gebruiker Doel: Het bekijken van een bestaande template Precondities: Het systeem is gestart en er bestaan een of meerdere templates Samenvatting: De gebruiker zou graag de settings van een bepaalde template willen bekijken om de setting van de template te controleren. Stappen: Gebruikersacties Systeemreacties 1. De gebruiker selecteert een template en kiest 2 . Het systeem toont een nieuw scherm waarop voor ‘Template bekijken’ de settings van de betreffende template te zien zijn 3. De gebruiker kiest voor ‘Ok’ om aan te geven 4. Het systeem keert terug naar het keuzemenu dat hij de settings bekeken heeft en terug wil keren naar het keuzemenu Use Case 8: Template aanmaken Actoren: Gebruiker Doel: Het aanmaken van een template Precondities: Het systeem is gestart Samenvatting: De gebruiker maakt een template aan waardoor deze in de toekomst gekozen kan worden bij het aanmaken van een project aan de hand van een template. Stappen: Gebruikersacties Systeemreacties 1. De gebruiker kiest voor ‘Template aanmaken’ 2 . Het systeem laat een nieuw venster zien met alle mogelijke settings 3. De gebruiker geeft een naam op voor de 4. Het systeem slaat de zojuist aangemaakte template en stelt de settings in die tot de template template op en geeft een bevestiging aan de behoren gebruiker en maakt een changeset aan zodat deze gecommit kan worden 5. De gebruiker kiest voor ‘Ok’ waarmee hij 6. Het systeem laat het keuzemenu zien aangeeft terug te keren naar het keuzemenu Postcondities: De changeset is aangemaakt en is klaar om gecommit te worden. Use Case 9: Template verwijderen Actoren: Gebruiker Doel: Het verwijderen van een template Precondities: Het systeem is gestart en er bestaan een of meerdere templates Samenvatting: De gebruiker verwijdert een template Stappen: Gebruikersacties Systeemreacties 1. De gebruiker kiest een template en kiest voor 2 . Het systeem geeft een melding dat de ‘Verwijderen’ geselecteerde template verwijderd gaat worden en vraagt de gebruiker of hij dit zeker weet. 3. De gebruiker kiest voor ‘Ja’ als hij de template 4. Indien de gebruiker op ‘Ja’ heeft gekozen echt wil verwijderen en kiest voor ‘Nee’ als deze verwijdert het systeem de template. Indien de de actie niet uit wil laten voeren gebruiker ‘Nee’ heeft gekozen wordt er geen actie ondernomen. 5. De gebruiker kiest nu voor ‘Ok’ waarmee hij 6. Het systeem laat het keuzemenu zien aangeeft terug te keren naar het keuzemenu Postcondities: De changeset is aangemaakt en is klaar om gecommit te worden.


49

Bijlage 1: Settings All the steps To add a project to the build, perform the following steps:

Eclipse • Check out the project from SVN (or create it from scratch and commit it) • Go to the project's properties o Set the project's encoding to UTF-8 • In Java Compiler o Check Enable project specific settings o Set the Compiler compliance level to 1.6 • In Errors/Warnings o Check Enable project specific settings o Set all the appropriate levels o Alternatively, copy the org.eclipse.jdt.core.prefs file from the .settings folder of another project that has similar error-levels • Commit the preference files to SVN ANT scripts • In build_properties.xml o Add a property for the directory of the project o Add a property for the jar file of the project • In build_includes.xml o Add a reference to the jar file in the project.class.path section • Create a build_<projectname>.xml • If you copy an existing build_<projectname>.xml: o Update the project name o Update title and jarfile parameters in the makeJar call within the build target o Update the dependencies in buildPrerequisites • In build_projects.xml o Add targets for build, test, and clean. (Check the variables within the targets!) • If other projects depend on this project, update the buildPrerequisites target in their respective build_.xml files. • In build_enterprise.xml o Add a reference to cleanAllProjects o Add a reference to buildPrerequisites o And also to testAllProjects o Add the jar file to the list in createDirectoryStructure • In build_mangosneak.xml o Add a reference to mangoClean o Add a reference to mangoBuild o And, again, also to mangoTest o Add the jar file to the list in mangoPackage • In build_Javadoc.xml o Add a reference to generateJavadoc • Add a test folder to the project, if it doesn't exist yet • Commit the scripts


50

Build scripts • In the nightly build batch files for trunk, streamdatabases and possibly mango and Javadoc: o Add the project name to the rd line o Add a line for the project to the SVN checkout block • Commit the scripts to SVN CruiseControl • Go to the build server • Open config.xml in the CruiseControl folder • For all affected projects (usually enterprise and testwebmango), do the following: o Add a reference to the projects location to the bootstrappers section o Add a reference to the projects location to the modificationset section o In the CruiseControl folder, open the subfolder projects/<project_name> Open the file fresh_checkout.bat Add the project name to the rd line Add the project name to the svn line o Run fresh_checkout.bat for the initial checkout of the new project • Commit the config.xml file to subversion When you're done • Update the Team Project Sets (I:\Ontwikkeling\TAS\Ontwikkel\Team Project Sets) • Send a mail to the team telling them to check out the new project!


51

Bijlage D: Design Document Delft, 27-05-2008

Design Document TOPdesk: veel modules



52

Inhoudsopgave

Inleiding 1. Karakteristieke issues 2. Designbeslissing 3. Implementatie van onze applicatie

54 54 57 58

Bijlage 1: TOPspace settings and files Bijlage 2: Architectuur, implementatievorm en programmeertaal

64 68


53

Inleiding Dit design document bevat alle belangrijke beslissingen over de implementatie. We beginnen met een hoofdstuk over de voor- en nadelen van de architecturen, zoals die in appendix B vermeld zijn. Vervolgens wordt de afweging tussen de implementaties gegeven. Als laatste is ons ontwerp te zien, waarbij ook gedetailleerd wordt uitgewerkt hoe dit ontwerp tot stand is gekomen.

1. Karakteristieke issues In dit hoofdstuk zullen we een aantal criteria behandelen en kijken in hoeverre de implementatieoplossingen hier aan voldoen. Eenvoud van settings / stappen inbouwen Als we kiezen voor een Java-implementatie zonder een server dan kunnen we nieuwe klassen toevoegen om extra stappen of settings mogelijk te maken. Voor een implementatie in Java met een server zullen we deze server-applicatie tijdelijk moeten stilleggen en mogelijk herstarten nadat de functionaliteit is aangepast. Dit komt doordat anders de nieuw ingebouwde functionaliteit niet direct werkt. De serverapplicatie moet namelijk opnieuw opgestart worden om de nieuwe functionaliteit te kunnen inlezen. Deze functionaliteiten worden bij het herstarten van de server-applicatie direct meegenomen in de inlaadprocedure. Bij het maken van een website met een taal als bijvoorbeeld PHP, Python of Ruby is het mogelijk om bestanden die op de server aanwezig zijn aan te passen, zodanig dat ze nieuwe stappen of settings ondersteunen. Als er een nieuwe stap moet worden uitgevoerd dan zal de server-applicatie ook tijdelijk stilgelegd en/of herstart moeten worden om de veranderingen door te voeren. Ook hier is na een herstart van de server-applicatie namelijk de nieuwe functionaliteit toegevoegd aan de inlaadprocedure. Eenvoud van templategebruik Onder een template verstaan wij een verzameling van standaard-instellingen die voor een nieuwe CodeBunch gebruikt kunnen worden. Voornamelijk zijn deze ‘settings’ de instellingen die in Eclipse bij een Eclipse project instelbaar zijn, maar verder worden ook de aan te maken mappen in het project aan een template gekoppeld. Dit vergemakkelijkt het aanmaakproces van een CodeBunch aanzienlijk, omdat niet iedere setting hoeft worden doorlopen voor een bepaalde CodeBunch. Bij de commandline-implementaties is het erg lastig om de templates overzichtelijk weer te geven. Hierdoor is het gemak ervan erg beperkt. Bij de overige opties kan op een overzichtelijke manier een template weergegeven worden, hierdoor zijn deze implementaties geschikter voor het gebruik van templates. Het aanpassen of aanmaken van een nieuwe template is bij de grafische implementatievormen op een makkelijke manier mogelijk, in tegenstelling tot een commandline tool. Concurrency Als we kiezen voor een centrale implementatie is er een grote kans dat er concurrency issues optreden. Deze issues ontstaan doordat meerdere gebruikers tegelijkertijd proberen bestanden op de server aan te passen. Bij het aanmaken van een decentrale implementatie zal er geen sprake zijn van concurrency, omdat veranderingen alleen op het systeem van de gebruiker worden doorgevoerd. Mogelijkheid tot maken van SVN-verbinding Om de benodigde invoerdata te verkrijgen moeten we een connectie kunnen maken met de Subversion server. In een website-implementatie is dit een erg lastige opgave omdat we daar de kennis (nog) niet voor hebben en we veel moeite moeten doen om eenvoudige SVN-operaties uit te voeren. In de overig genoemde implementaties echter kunnen we simpelweg de externe Java package “SVNKit” gebruiken die de Subversion-communicatie op zich neemt. Eenvoud van instellen van Eclipse Omdat we settings van Eclipse willen kunnen instellen voor CodeBunches moeten we rekening houden met het gemak waarmee dit in te bouwen is. Als er een nieuwe versie van Eclipse uitkomt, zijn er vaak nieuwe instellingen voor een CodeBunch beschikbaar. Om de complete lijst van settings te kunnen opvragen kunnen we de interne klassen van Eclipse gebruiken om deze op te vragen. Ook het aanmaken en verwijderen van CodeBunches kan via deze interne klassen van Eclipse worden gedaan.


54

De Eclipse settings kunnen uiteraard gemakkelijk ingesteld worden vanuit een Eclipse plugin. Als we naar andere oplossingen kijken zien we dat het daarin minder gemakkelijk is. Hierbij zullen we aparte features moeten inbouwen die alle Eclipse settings op zich nemen terwijl we in een Eclipse plugin de functionaliteit, geboden door Eclipse, kunnen gebruiken. Uitbreidbaarheid, modulariteit, onderhoudbaarheid Als we kijken naar de uitbreidbaarheid en modulariteit die een programmeertaal ons biedt, dan is het belangrijk om te weten of een taal die mogelijkheden biedt. Doordat we deze kennis niet paraat hebben als het gaat om het bouwen van websites, heeft Java in dit opzicht onze voorkeur. Immers in Java kunnen we heel gemakkelijk nieuwe klassen toevoegen, aanpassen of verwijderen op zo’n manier dat hier geen extra aanpassingen in de basis van het systeem voor nodig zijn. Met betrekking tot de leesbaarheid en onderhoudbaarheid van de code bieden zowel de eerdergenoemde talen PHP, Ruby en Python als Java de mogelijkheid om helder leesbare code te schrijven, zodat ons systeem ook gemakkelijk onderhoudbaar gemaakt kan worden. Gebruik van instellingen We willen voor het gebruiken van instellingen die alleen onze applicatie aangaan gebruik maken van een configuratiebestand. Met instellingen bedoelen we dan ook de instellingen die instelbaar zijn voor onze applicatie zelf, bijvoorbeeld waar de invoerbestanden gevonden kunnen worden en waar de logs moeten komen te staan. Deze instellingen willen we niet door onze sourcecode heen verspreid hebben staan. We slaan ze liever in één configuratiebestand op, zodat alles wat aangepast moet kunnen worden ook direct te vinden is. Elk van de genoemde talen heeft de mogelijkheid om een bestand uit te lezen en de instellingen te gebruiken tijdens runtime. Benodigde extra kennis Eclipse plugins hebben wij nog niet eerder gemaakt en met het maken van websites met Python, Ruby of PHP hebben we evenmin voldoende ervaring. Omdat we met Java zelf wel ervaring hebben, hebben we voor het maken van een commandline tool of een GUI geen extra kennis nodig. De optie Eclipse plugin sluit beter bij ons aan omdat Eclipse plugins in Java geschreven kunnen worden en we hier dus minder voor hoeven te leren dan voor een website-implementatie. Gebruikersgemak Een commandline tool is niet gebruiksvriendelijk omdat er veel informatie moet worden weergegeven maar hier slechts beperkte mogelijkheden voor zijn. Hierdoor ontbreekt het overzicht. Een Java GUI is wat dat betreft al een grote vooruitgang. Deze interfaces kunnen de gebruiker een veel beter overzicht geven van wat hij kan doen. Hetzelfde geldt voor een Eclipse plugin, waar verschillende views kunnen worden aangeboden door de plugin. Een website kan op een overzichtelijke manier weergeven wat de gebruiker kan en mag op een dusdanige manier dat de gebruiker efficiënt kan handelen. Scripting Het grote voordeel van een commandline tool is dat je het kan besturen met een geautomatiseerd script. Dit is een aanvullende functionaliteit die de opdrachtgever erg handig zou vinden. Verder is het zo dat websites in principe bestaan uit scripts dus dit voordeel geldt ook voor deze oplossing. Bij de andere implementatievormen ontbreekt deze functionaliteit. Haalbaar in de gestelde tijd Het maken van websites wordt lastig in de gestelde tijd, gezien het feit dat we in de resterende tijd nog veel over de programmeertalen moeten leren. We hebben wel al ervaring met Java, waardoor de Javaimplementaties gezien de tijd die we tot onze beschikking hebben goed haalbaar zijn. Wat betreft een implementatie als Eclipse plugin zijn er een aantal taken waarvan we moesten uitzoeken of deze in Eclipse gemakkelijker zijn dan in andere implementatievormen. Deze taken omvatten het aanmaken van CodeBunches, het uitlezen en instellen van settings van deze CodeBunches en hoe we de user interface kunnen weergeven. Na een kort onderzoek is gebleken dat we met Eclipse de bijbehorende settings kunnen instellen en CodeBunches kunnen beheren. In contrast met de andere implementatievormen is dit erg gemakkelijk om te gebruiken, zodat we dit niet zelf hoeven te implementeren. Ook qua user interface kunnen we concluderen dat dit wel binnen de gestelde tijd te realiseren is omdat we al ruimschoots ervaring hebben met AWT en Swing. Eclipse maakt gebruik van SWT, dat niet heel erg verschillend is van AWT en Swing.


55

Platformonafhankelijkheid (Browser en OS) Als we naar de platformonafhankelijkheid van implementatievormen kijken kunnen we twee categorieën onderscheiden. Ten eerste hebben we de Java-implementaties waarbij platformonafhankelijkheid eenvoudig haalbaar is, mits we geen besturingssysteemspecifieke system calls gebruiken. Ten tweede hebben we de website-implementatie waarbij we niet alleen rekening moeten houden met het besturingssysteem, maar ook met de gebruikte browser, wat weer een extra moeilijkheid met zich mee brengt.


56

2. Designbeslissing In dit hoofdstuk maken we een afweging tussen de verschillende in dit document behandelde architecturen en implementatievormen. De afweging is gedaan met de criteriamatrix (zie tabel 1) waarin we de voor- en nadelen tegen elkaar uitgezet hebben.

IMPLEMENTATIEVORM Centraal Decentraal

Commandline tool

Website

Eclipse plugin

GUI

Commandline Tool

Eclipse plugin

CRITERIA

-1 0 1

GUI

Legenda:

1 1 -1 1 0 1 1 1 1 -1 1 1 7

1 -1 -1 1 0 1 1 1 -1 1 1 1 5

1 1 -1 -1 0 1 1 -1 1 1 -1 -1 1

1 1 -1 1 1 1 1 0 1 -1 1 1 7

1 1 1 1 0 1 1 1 1 -1 1 1 9

1 -1 1 1 0 1 1 1 -1 1 1 1 7

1 1 1 1 1 1 1 0 1 -1 1 1 9

slecht matig goed

Eenvoud van settings / stappen inbouwen Eenvoud van templategebruik Concurrency Mogelijkheid tot maken van SVN-verbinding Eenvoud van het instellen van Eclipse Uitbreidbaarheid, modulariteit, onderhoudbaarheid Gebruik van instellingen Benodigde extra kennis Gebruikersgemak Scripting Haalbaar in de gestelde tijd Platformonafhankelijkheid TOTAAL

Tabel 1: Weergave van alle issues

Vanwege het feit dat we als we voor de centrale architectuur kiezen rekening moeten houden met concurrency issues, hebben we gekozen voor een decentrale architectuur. Als extra voordeel van deze decentrale architectuur kunnen we op deze manier de gebruikers nieuwe instellingen alleen lokaal laten testen. Zoals uit tabel 1 te lezen is hebben we een gelijke stand tussen een GUI en een Eclipse plugin met een decentrale architectuur. De enige verschillen tussen deze twee opties zijn dat we voor het implementeren van de GUI niet heel veel meer bij hoeven te leren, en dat we via de Eclipse pluginimplementatie veel gemakkelijker de Eclipse specifieke instellingen kunnen instellen. We moeten dus deze twee criteria tegen elkaar afwegen. Omdat het erg onwaarschijnlijk is dat TOPdesk over gaat naar een andere IDE én omdat we voor het maken van een Eclipse plugin een en ander kunnen bijleren lijkt het ons het beste om voor deze optie te kiezen zodat we weer een ervaring rijker zijn.


57

3. Implementatie van onze applicatie In dit hoofdstuk behandelen we de implementatie van onze applicatie. De datastromen zijn van essentieel belang voor onze applicatie, en zullen we daarom behandelen.

Data Invoerdata Zoals in tabel 2 is aangegeven bevindt niet alle data zich op eenzelfde plaats. Het merendeel van de data staat op de Subversion server. Twee bestanden staan op de buildserver, en een staat er op het netwerk. Het is handig om alle data lokaal te hebben. Dit zou bijvoorbeeld gedaan kunnen worden door een nieuw batch-bestand op de server uit te voeren die dynamisch het originele batch- bestand van de Subversion server haalt. Hierdoor is het voor ons programma mogelijk om de aanpassingen alléén op de Subversion server uit te voeren. Uitvoerdata Als álle invoerdata op Subversion staan, en niet op meerdere locaties, dan kan ons programma de getransformeerde bestanden ook weer terug op Subversion zetten. Onze opdrachtgever echter wenst dat hij zelf de mogelijkheid heeft om te controleren of de transformaties goed zijn uitgevoerd. Verder wil hij zelf de bestanden op Subversion zetten. Actie Maak nieuwe mappenstructu ur

Invoer- / uitvoerbestand

Locatie

Postconditie Mappenstructuur is aangemaakt op de betreffende locaties

Maak nieuw bestand aan

.project

Maak nieuw bestand aan

.classpath

Pas bestand aan Pas bestand aan Maak bestand nieuw aan Pas bestand aan

build_properties.xml

In de root van de workspace en in de nieuwe SVN repository: svn://~// In de root van de workspace en in de nieuwe SVN repository: svn://~// In de root van de workspace en in de nieuwe SVN repository: svn://~// svn://~/tas/

build_includes.xml

svn://~/tas/

build_.xml build_projects.xml

svn://~/< CodeBunchName >/ svn://~/tas/


De afhankelijkheden tussen projecten zijn opgeslagen

De classpath en de compilersettings zijn opgeslagen Specificeert de locatie van de Jar van de nieuwe CodeBunch Voegt een referentie toe aan een Jar-bestand Maakt een nieuwe Ant build script aan Nieuwe target gemaakt die build_<projectname>.xml aanroept.

58

Pas bestand aan

build_enterprise.xml

svn://~/tas/

Pas bestand aan

build_mangosneak.xm l

svn://~/TestWebMango/

Pas bestand aan

build_Javadoc.xml

svn://~/TestWebMango/

Pas bestand aan

config.xml

svn://build/trunk/cruisec ontrol

Pas bestand aan

fresh_checkout.bat

Pas bestand aan

nightly build batchbestand

buildserver /projects// Op de buildserver

Pas bestand aan

Team Project Set

Netwerk/Team Project Sets

Aangegeven welke CodeBunches worden toegevoegd aan de Enterprise versie van TOPdesk Aangegeven welke CodeBunches worden toegevoegd aan Mango Hier wordt een referentie toegevoegd aan de generateJavadoc target Hier wordt de locatie van de nieuw aangemaakte CodeBunch toegevoegd Hier wordt aan toegevoegd hoe de nieuwe CodeBunch uitgecheckt kan worden Hier wordt aan toegevoegd hoe de nieuwe CodeBunch uitgecheckt kan worden Hier wordt aan toegevoegd dat een nieuwe CodeBunch uitgecheckt moet worden

Tabel 2: Invoer en uitvoerbestanden met bijbehorende locaties en transformaties

Toelichting ontwerp Ontwerp De modulariteit van ons systeem bereiken we door het systeem in twee delen op te splitsen. Het eerste deel is de core-package. Het tweede deel bestaat uit de implementaties van de verschillende abstracte klassen in de core-package. Deze abstracte klassen hebben we geïntroduceerd zodat onze core-package weet wat het kan verwachten van de aanpasbare subklassen. De core-package bevat functionaliteit voor het loggen en het laden van instellingen (zie bijlage A) van ons systeem. Verder coördineert de core-package alle activiteiten, door acties door te geven aan de betreffende subklassen. De administratie van de systeeminstellingen gebeurt in de klasse “SettingsManager”. Deze klasse houdt bij welke CodeBunches en Templates er zijn, en verder laadt deze klasse de instellingen en geeft deze aan de “Backbone”. De Backbone maakt op zijn beurt instanties van de gewenste subklassen zodat deze gebruikt kunnen worden. Het aanpassen van de invoerbestanden gebeurt in de subklassen van de abstracte klasse “Steps”. Deze subklassen weten allemaal welke tools zij nodig hebben (b.v. FileTool / SVNTool) en kunnen deze dan ook gebruiken. Om te kunnen communiceren met CodeBunches in hun bestaande omgeving, zoals bijvoorbeeld Eclipse, maken we een specifieke klasse die alle handelingen uit kan voeren die nodig zijn om een CodeBunch te onderhouden. Deze klasse noemen we de CodeBunchAccess klasse, welke zelf abstract is. Een concrete instantiatie van deze klasse zorgt in onze klasse voor de Eclipse CodeBunch handelingen. Deze noemen we de klasse EclipseCodeBunchAccess. Control flow De control flow van de applicatie is hieronder in figuur 1 weergegeven in de vorm van een volgordediagram. In dit volgordediagram is een voorbeeld uitgewerkt van het toevoegen van een CodeBunch waarin te zien is op welke plekken er gelezen en/of geschreven wordt van of naar data.


59

Figuur 1: Volgordediagram voor het toevoegen van een CodeBunch

Als het systeem opgestart wordt vinden de volgende acties plaats: 1 De Backbone wordt geïnitialiseerd, hierin wordt een logger aangemaakt en de SettingsManager gevraagd alle instellingen te lezen (1.1). Met deze informatie maakt de Backbone verschillende tools, stappen en een CodeBunchAccess aan. Vervolgens kan het systeem opdrachten van de gebruiker krijgen. 2 Allereerst wordt de gebruiker in staat gesteld om aan te geven welke substappen er wel en niet uitgevoerd dienen te worden. 3 Vervolgens stelt een gebruiker in wat de gewenste stappen zijn die uitgevoerd moeten kunnen worden. Hierna kan bijvoorbeeld aangegeven worden dat de gebruiker een CodeBunch wil aanmaken, als dit het geval is vinden de volgende acties plaats: 4 De gebruiker geeft aan dat zij een nieuwe CodeBunch wil aanmaken met een bepaalde naam en bepaalde instellingen. 4.1 De Backbone roept alle stappen aan zodat deze de nodige aanpassingen maken. 4.1.1 Een stap vraagt aan een nodige tool een gewenst bestand aan, past deze aan 4.1.2 en vraagt deze weer weg te schrijven. 4.2 Vervolgens vraagt de Backbone aan de CodeBunchAccess om een nieuwe CodeBunch aan te maken (de file hiërarchie) 4.3 Als laatste stap wordt aan de SettingsManager doorgegeven dat er een nieuwe CodeBunch is. Deze gaat op zijn beurt de systeemadministratie in orde brengen. Niet toegevoegd aan het sequentie diagram zijn de aanroepen naar de logger. Dit is gedaan om het diagram overzichtelijk te houden. De logger wordt elke keer aangeroepen als er een actie mislukt is, of als het systeem de gewenste actie succesvol uitgevoerd heeft.


60

Klassendiagram In figuur 2 is het klassendiagram van onze te maken applicatie zien. De core-package zal het modulaire gedeelte van ons systeem voorstellen.

Figuur 2: Klassendiagram van onze te maken applicatie

Toelichtingen op het klassendiagram Backbone Deze klasse is de kern van het systeem. Deze regelt de communicatie met de klassen die zowel binnen als buiten de core-package liggen. De “getTool()”-methode heeft als attribuut een String. Via deze String wordt het bestandstype meegegeven waardoor de methode kan bepalen of de te gebruiken tool een SVNTool of een FileTool is. Ook hier is het mogelijk om zelf eigen tools te introduceren en deze aan het systeem te koppelen, door de tool te compileren in een klasse anders genaamd dan de bestaande Toolklassen FileTool en SVNTool. SettingsManager De SettingsManager heeft de verantwoordelijkheid om klassen te laden en het configuratiebestand te lezen, en voert bootstrap-functionaliteit uit door ervoor te zorgen dat alle systeeminstellingen van ons programma worden geladen voordat de gebruiker een actie uitgevoerd. Logger De Logger wordt gebruikt om de voortgang van het uitvoeren van de stappen vast te leggen. Verder kunnen wij gebruik maken van deze klasse om te debuggen/troubleshooten. Steps Dit is een abstracte klasse die de stappen beheert van ons systeem, bijvoorbeeld de stappen voor CruiseControl, Ant en SVN. De concrete stappen bezitten een sequentieel stappenplan waarvoor geldt dat elke substap in- of uitgeschakeld kan worden via de GUI. Een nadeel van een eventuele losse SubStep-klasse zou zijn dat je hieronder weer een veertigtal substappen (subklassen) zou moeten implementeren, waar de huidige keuze met gegroepeerde


61

substappen in bijvoorbeeld AntStep er voor zorgt dat alle Ant gerelateerde handelingen in deze klasse te vinden zijn. Tool De abstracte klasse Tool maakt het mogelijk om verschillende tools te gebruiken. Denk hierbij aan een SVNTool en een FileTool. Mocht er bijvoorbeeld een andere datastructuur gebruikt worden voor de configuratiebestanden dan kan er een nieuwe tool toegevoegd worden die het mogelijk maakt deze configuratiebestanden uit te lezen. RevisionTool Deze abstracte klasse biedt naast de functionaliteit van Tool de extra functionaliteit die een versiebeheersysteem vereist. Dit houdt in dat ook met hele mappen kan worden gewerkt, zoals dat bij bijvoorbeeld Subversion gebruikelijk is. Verder kun je hiervoor de credentials instellen, zodat verbindingen naar de versiebeheersystemen gelegd kunnen worden. GUI Deze klasse is het gezicht van het systeem. De GUI is een layer tussen de gebruiker en het systeem. Bij gebruikersacties zorgt de GUI ervoor dat de core-package van het systeem de gewenste acties uitvoert. Verder wordt de GUI gebruikt om diverse informatie weer te geven zoals CodeBunches, Templates en CodeBunch-eigenschappen (afhankelijkheden en compiler settings). CodeBunchAccess De abstracte klasse CodeBunchAccess maakt het mogelijk om een klasse aan het systeem toe te voegen die CodeBunches en de afhankelijkheden en settings van die CodeBunches kan uitlezen, aanmaken en wijzigen. Omdat we besloten hebben om een Eclipse plugin te maken, implementeren wij een EclipseCodeBunchAccess klasse die alle CodeBunches met hun betreffende afhankelijkheden en settings kan instellen en uitlezen. Deze kan alleen gebruikt worden als er ook gebruik wordt gemaakt van EclipseGUI.

Andere implementatiebeslissingen Design patterns Omdat de expliciete eis werd uitgesproken dat het systeem dat we gaan bouwen modulair moet zijn, hebben we ervoor gekozen om “factory-methods” toe te voegen aan abstracte klassen. Deze zorgen er dan voor dat we de juiste instantie van een bepaalde klasse aanmaken. Verder gaan we gebruik maken van het Model-View-Controller design pattern. Hierbij hebben we ervoor gekozen om de GUIimplementaties de rollen van View en Controller op zich te laten nemen. De core-package neemt in dit geval de Model functie op zich. Volgorde We maken gebruik van een incrementele implementatiemethode. Daarbij wordt begonnen met het implementeren van de abstracte klassen, waardoor we interfaces hebben naar klassen die buiten de core-package komen te liggen. Hierdoor kunnen we vervolgens de externe tools implementeren waardoor er file access mogelijk is zodat er bestanden benaderd kunnen worden. Parallel hieraan gaan we de SettingsManager en de Logger implementeren. Vervolgens gaan we verder met het implementeren van de Backbone-klasse. De klassen die we erna gaan implementeren zijn de EclipseCodeBunchAccess-klasse en de verscheidene stappen. Op dit punt aangekomen hebben we in principe de functionaliteit van de core af zodat we verder kunnen gaan met de laatste stap, het implementeren van de EclipseGUI-klasse. Tijdens het implementeren van alle klassen gaan we uit van een parallelle testhiërarchie. Het testen zal gebeuren met behulp van JUnit 4.0. We beginnen voor elke klasse die we gaan implementeren met het aanmaken van stubs voor de methoden. Vervolgens gaan we tests schrijven en als laatste stap de methoden implementeren. Om de verschillende klassen te koppelen zullen we integratietests schrijven en deze incrementeel uitvoeren om de koppelingen tussen de klassen te testen. De klassen die met bestanden en de GUI werken gaan we handmatig testen.


62

Configuratiebestanden Voor het bijhouden van de configuratie van ons eigen systeem hebben we een XML-bestand waar alle externe klassen in opgenomen zijn. Dit houdt in dat de te faciliteren stappen, de klassen voor het toegankelijk maken van CodeBunches (CodeBunchAccess) en de diverse tools in dit configuratiebestand bijgehouden worden. De SettingsManager leest het configuratiebestand uit en zorgt ervoor dat de juiste klassen worden aangemaakt en dat de Backbone deze kan bijhouden. Ook wordt de volgorde van de uit te voeren stappen hierin vastgelegd. Verder is er nog een apart configuratiebestand voor het opslaan van CodeBunch-settings (denk aan projectafhankelijkheden, compiler warning settings en locaties van verschillende bestanden). Ook dit wordt weggeschreven in een XML-bestand. Als derde configuratiebestand is er nog een XML-bestand dat de templates opslaat. Wij hebben voor het wegschrijven van deze bestanden voor het XML-formaat gekozen omdat de geboden invoerdata (Eclipse settings, Ant etc.) ook in XML-formaat opgeslagen zijn. Hierdoor zijn we sowieso al verplicht om XML te gebruiken, en zou het logisch zijn dat we het ook voor de opslag van onze eigen instellingen gebruiken. Invoerdatabeheer Doordat de invoerdata op verschillende computers staat, is bij ons de vraag gerezen of het niet gemakkelijker is als alle data op een enkele computer te vinden zou zijn. Na een klein onderzoek bleek dat alle XML-configuratiebestanden op de Subversion server te vinden waren, maar dat de batch bestanden die door CruiseControl gebruikt worden op een andere server (namelijk de server waar CruiseControl op draait) staan. We kunnen onze applicatie op sommige punten vereenvoudigen door de communicatie met de verschillende servers te verminderen. Hierbij is het handig om ook de eerder genoemde batchbestanden op de Subversion server te zetten zodat ons programma ze gemakkelijk aan kan passen. Dit is te realiseren door een loader batch-bestand te maken die het benodigde batch bestand van de Subversion server afhaalt en uitvoert. Hiervan hebben we uitgezocht hoe dit moet en hebben we een voorstel gedaan aan Jan Ouwens, de beheerder van de build, zodat de verandering doorgevoerd kan worden.


63

Bijlage 1: TOPspace settings and files Dit document is in het Engels geschreven omdat er naast de Nederlandstalige vestiging in Delft ook vestigingen in het buitenland zijn.

Overview This chapter describes all TOPspace settings and related files. In figure 3 you can see a valid (and default) file hierarchy for the TOPspace settings and other TOPspace related files. We will briefly describe every file in this chapter. Please note that ‘core’ represents your TOPspace root directory.

Figure 3: sample view of TOPspace root directory

Configuration file of the application settings.ini # master file: MASTER_CONFIG=topspacesettings.xml # codebunches file: CODEBUNCHES_CONFIG=codebunches.xml # templates file: TEMPLATES_CONFIG=templates.xml # codebunches folder: CODEBUNCHES_FOLDER=codebunches # templates folder: TEMPLATES_FOLDER=templates # perform xml validation: PERFORM_XML_TESTS=true # perform logging in console: CONSOLE_LOGGING=true # log file attributes: LOG_FOLDER=C:/log/ LOG_NAME=TOPspace_log These master settings are used throughout the files you will view later on in this document. They are used by the application to read external data, and in the end making sure the modified data is stored in the correct file.


64

XML master-file for the storage of all Steps, Tools and the Gui topspacesettings.xml <step name="AntStep"/> This file manages every Tool, Step and GUI possible. The settings file starts with a entry, followed by the variables. These are the actual types of classes that can be included. The variables entry marks the beginning of the variables section in the xml-file. In this section, entries of type are inserted. These variables can be referred to, as is shown in the implementation section. The implementation entry marks the beginning of the actual implementable classes. An entry can in this case be either of codebunchaccess, gui, revisiontool, step or tool. These types can be found in this file in the variables section, so that when a new type must be added, it can be done at great ease. For example, ConcreteRevisionTool (a revisiontool entry) would refer to a RevisionTool object in runtime. The ConcreteRevisionTool.class file is automatically loaded by the loader if you decide to leave this entry inside the topspacesettings.xml file. The same applies to Tools, Steps, CodeBunchAccess and the GUI. Of course when giving a class like ConcreteRevisionTool, you have to make sure the ConcreteRevisionTool.class does exist in the correct folder for .class-files.

XML-file for the storage of all CodeBunches codebunches.xml Make a new entry to add a new CodeBunch and specify a correct file name as its attribute. These files should be in the folder specified by CODEBUNCHES_FOLDER (see settings.ini). XML-file for the storage of all Templates templates.xml


65

Make a new

Bachelorproject Veel Modules

Recommend Documents