Eindverslag. Versiebeheer Repository Invantive Producer. Versie 1.0 Wouter Vos Project: C412 Proces: t20879 Laatst bewerkt:

Transcriptie

1 Eindverslag Versiebeheer Repository Invantive Producer Versie 1.0 Wouter Vos Project: C412 Proces: t20879 Laatst bewerkt: Wouter Vos 1/53

2 Voorwoord Ik studeer Technische Informatica en werk graag aan technische software oplossingen. Ter afronding van mijn studie heb ik mijn afstudeeropdracht uitgevoerd bij Invantive in Harderwijk. De producten die deze afstudeerperiode heeft voortgebracht zullen binnen Invantive gebruikt worden bij het beheren van specificaties op basis waarvan software gemaakt wordt. Gegenereerde software wordt steeds belangrijker. Ik ben dan ook erg blij om bij Invantive aan een dergelijk technisch en relevant project gewerkt te hebben. Als programmeur sta je bij Invantive midden in een dynamisch en professioneel bedrijf en werk je in een informele en constructieve werkomgeving. Mijn dank gaat uit naar Patrick Hofman voor goede begeleiding en hulp bij technisch moeilijke stukken. Guido Leenders heeft veel nuttige feedback gegeven. Johan de Zwaan verzorgde fijne woonruimte in de buurt van Invantive en heeft mij uitgelegd hoe Invantive Producer en Invantive Studio werken. Leoni Heijman en Paul Lindhout hebben een aantal keer geholpen met grammatica en zinsopbouw. Wouter Vos 2 / 53

3 Samenvatting Invantive is een softwarebedrijf dat projectmanagement software voor bedrijven maakt. Daarvoor hebben ze Invantive Producer. Het genereert op basis van specificaties een softwarepakket. Die staan opgeslagen staan in een repository. De afstudeeropdracht is het ontwikkelen van een versiebeheersysteem voor die specificaties dat volledig in Invantive Producer geïntegreerd is. Invantive moet regelmatig wijzigingen aanbrengen in de specificaties op basis waarvan software wordt gegenereerd. Via de huidige werkwijze zijn er nogal wat beperkingen aan het maken van die wijzigingen. Voor het beheren van wijzigingen aan specificaties zullen toevoegingen gemaakt moeten worden op Invantive Studio; een nieuwe applicatie voor het werken met Invantive Producer. Als gereedschap heeft de afstudeerder vooral gebruik gemaakt van Microsoft-technologie. De uitvoering van deze opdracht begon met een onderzoek naar versiebeheer. Het prototype dat daarop volgde bleek niet op Invantive Producer aan te sluiten. Daarom is in overleg besloten niet in een keer een prototype te ontwikkelen, maar stap voor stap functionaliteit toe te voegen aan het bestaande systeem. Om dit te bereiken zijn we overgestapt op een iteratief ontwikkelmodel. Hierdoor konden we het bereik beter beheersen en steeds als een deelproduct af was gaf de opdrachtgever feedback. Programmeurs die direct op de database van Invantive werken hebben nu een functie om het verschil tussen twee teksten te berekenen. Gebruikers van Invantive Studio kunnen een venster oproepen dat in detail de verschillen tussen de onderdelen van twee versies van een specificatie visualiseert. Daarnaast kunnen ze in detail de verschillen tussen de eigenschappen van specificaties of hun onderdelen zien. Het resultaat is dat de gebruiker precies kan ontdekken wat de verschillen zijn tussen specificaties. Invantive is zeer tevreden met het resultaat, gebruikt het bij de ontwikkeling van hun specificaties en zal het in de toekomst uitbreiden tot een volledig versiebeheeersysteem. Wouter Vos 3 / 53

4 Inhoudsopgave Voorwoord... 2 Samenvatting... 3 Inhoudsopgave Inleiding Invantive Organisatie Werkomgeving Probleemanalyse Probleemsituatie Werkwijze Probleemstelling Bereik Prototype Verschilfunctie Invantive Studio Planning Methoden en Technieken Inleiding Interview Waterval ontwikkelen Iteratief ontwikkelen Model View ViewModel Mockup C# NET Framework PL/SQL WPF Infragistics Gereedschappen Vooronderzoek Inleiding Waarom versiebeheer? Centraal versiebeheer Gedistribueerd versiebeheer Voordelen van elk type Toestanden van een werkkopie Op een database werkt het anders Functies en kwaliteiten Wouter Vos 4 / 53

5 8 Uitvoering Inleiding Waarom verschillen berekenen Verschil algoritme Snel algoritme Welke eigenschappen zijn verschillend Visualiseer verschillen tussen eigenschappen Visualiseer verschillen tussen de specificaties Resultaten Inleiding Verschilberekening Snelle Verschilberekening Welke eigenschappen zijn verschillend? Verschillen tussen eigenschappen Verschillen tussen inhoud specificaties Prestaties berekening verschil tussen specificaties Conclusie Verschillen zijn duidelijk zichtbaar Persoonlijk Advies voor de opvolger Advies voor leidinggevende bij Invantive Woordenlijst Bibliografie Bijlagen Oorspronkelijke tijdsindeling afstudeerperiode Gerealiseerde tijdsindeling afstudeerperiode Prestaties van algoritmen die verschillen berekenen PL/SQL verschilberekening C# snelle verschil berekening PL/SQL snelle verschil berekening Wouter Vos 5 / 53

6 1 Inleiding Als onderdeel van zijn afstudeerstage heeft Wouter Vos, vanaf nu de afstudeerder deze scriptie geschreven. In het kader van zijn opleiding HBO Technische Informatica bij Avans hogeschool in Breda heeft de afstudeerder het project Versiebeheer Repository Invantive Producer uitgevoerd. Opdrachtgever voor dit project is Guido Leenders, eigenaar en directeur van Invantive. Invantive is een klein softwarebedrijf. Het werkproces voor de ontwikkeling van hun automatisch gegenereerde software mist de volledige ondersteuning van een versiebeheersysteem. Daarom heeft de afstudeerder een literatuurstudie uitgevoerd om een beeld te krijgen van hoe de belangrijkste versiebeheersystemen werken. Dit gecombineerd met bestaande kennis over databases heeft geleid tot inzicht over hoe versiebeheer op een database zal werken. Daarna is die kennis toegepast door het systeem bij Invantive uit te breiden. De resultaten kunt u verder in dit verslag lezen. Wouter Vos 6 / 53

7 2 Invantive 2.1 Organisatie Invantive maakt projectmanagement software voor bedrijven [1]. De organisatie heeft een platte structuur. Het werk verloopt altijd gezellig en informeel. De afstudeerder kent het personeel dat op het kantoor in Harderwijk werkt persoonlijk. Zij zijn HBO of universitair opgeleid [2] en vervullen meerdere rollen: - Guido Leenders, vervult o.a. de rollen van directeur-eigenaar, programmeur, verkoper support medewerker en kantoorinrichter; - Patrick Hofman, vervult o.a. de rollen van programmeur, verkoper, leidinggevende, support en bezoekt klanten; - Bastiaan Hup, vervult o.a. de rollen van administratief medewerker, business analist en receptionist; - Joshua Hazelaar, werkt met een imac aan de grafische kant van de software. - Juan Bijzeit, doet de marketing voor Invantive; - Johan de Zwaan, werkt aan de software en doet support als niemand anders het doet; - Hans Busschers, activeert zijn omgeving. Werkt aan de software; - Wouter Vos, studeert Technische Informatica. Werkt voor zijn afstudeerstage aan het project Versiebeheer Repository Invantive Producer In figuur 1 zijn de onderlinge relaties weergegeven. Figuur 1: Medewerkers bij Invantive, pijlen geven autoriteit weer Wouter Vos 7 / 53

8 2.2 Werkomgeving Invantive is gevestigd in Harderwijk in pand waar in een ruimte voor elke medewerker een werkplek aanwezig is. Hierdoor kunnen werknemers gemakkelijk met elkaar communiceren en samenwerken. De server verzorgt voor iedere werknemer een virtuele desktop omgeving die op elke werkplek kan worden aangeroepen. Tijdens de afstudeerperiode is er regelmatig overleg tussen de afstudeerder en de bedrijfsbegeleider Patrick Hofman. Dan worden de voortgang en wat er de komende periode nog moet gebeuren besproken. Bij problemen die tussentijds de kop op steken zijn hij en Johan de Zwaan de vraagbaak waarbij de afstudeerder terecht kan. Op grond van deze intensieve contacten beoordeelt hij het werk van de afstudeerder. Hij doet dit in samenspraak met de opdrachtgever Guido Leenders. Naast opdrachtgever treedt hij ook op in de rol van eindgebruiker. Invantive heeft als uitgangspunt dat ze hun eigen software ook zelf gebruiken, dat geldt ook voor dit project. In eerste instantie zullen de medewerkers van Invantive gebruik maken van de producten die dit project oplevert. Wouter Vos 8 / 53

9 3 Probleemanalyse 3.1 Probleemsituatie Invantive maakt een standaard softwarepakket dat bij meerdere klanten in gebruik is. De software wordt per klant naar wens aangepast waardoor klanten het ervaren als op maat gemaakte software. Invantive verzorgt ook de ondersteuning voor deze software en dus moeten regelmatig aanpassingen worden uitgevoerd. Invantive Producer (IP) is het belangrijkste softwarepakket van Invantive; het genereert projectmanagement software op basis van een ontwerp. IP is zo krachtig dat het ook gebruikt wordt om zichzelf te genereren. Invantive werkt continu aan de doorontwikkeling van IP en dus ook aan de gebruikte specificaties. Die ontwikkeling is echter lastiger dan de ontwikkeling van andere software. Omdat er geen adequaat versiebeheersysteem bestaat voor het opgeslagen ontwerp. Hierdoor kunnen ontwikkelaars niet gelijktijdig aan een specificatie voor IP werken. Een voorbeeld van een probleem is dat een fout soms wel binnen de interne ontwikkelversie van Invantive opgelost is, maar nog niet in de versie bij de klant. Het is dan gebruikelijk dat de versie die bij de klant geïnstalleerd staat ook aangepast wordt. Alleen het lastig te zien hoe de aanpassing bij de klant gerealiseerd kan worden. Soms is de klantsituatie zodanig verouderd dat de huidige oplossing niet meer van toepassing is. Mede hiervoor wordt bij wijzingen in het ontwerp ook de oude versie bewaard. Wanneer een programmeur een wijziging uitvoert wordt deze de daaropvolgende nacht getest en binnen het bedrijf uitgerold. Het programma IP verandert daardoor intern voortdurend, maar dat geldt niet automatisch voor de versies die bij klanten geïnstalleerd zijn. 3.2 Werkwijze De afstudeerder kreeg een introductie in het programma Invantive Producer ofwel IP. Hierbij werd uitgelegd hoe Invantive Producer werkt en de specificatie aangepast kan worden. Ook stelde de afstudeerder regelmatig vragen over IP en voerde gesprekken met collega s over IP. Door al die bronnen te combineren kreeg de afstudeerder een duidelijk beeld van de werking van IP. Gemiddeld wordt er eens in de maand bedrijfsoverleg gevoerd, dan bespreekt de eigenaar met alle medewerkers de bedrijfsvoering. Door hieraan deel te nemen heeft de afstudeerder veel kennis opgedaan over het interne werkproces en de situaties bij klanten. 3.3 Probleemstelling De specificaties voor IP worden momenteel bewerkt vanuit een Excel bestand dat via een traditioneel versiebeheersysteem opgeslagen wordt. Dat systeem kan alleen verschillen berekenen tussen tekstbestanden. Hierdoor is er onvoldoende ondersteuning van de werkprocessen die bij software ontwikkeling heel gebruikelijk zijn. Invantive wenst daarom een versiebeheersysteem dat aansluit bij de structuur van IP. Wouter Vos 9 / 53

10 4 Bereik 4.1 Prototype De eerste stap bij de uitvoering van deze afstudeerstage zou een prototype voor versiebeheer op een database opleveren. Daarna zou dat uitgebreid worden met meer functionaliteit. Tijdens de uitvoering van het project bleek dat het bouwen van een volledig systeem in één keer te moeilijk was en te weinig zou aansluiten op IP. Daarom werd in overleg met de opdrachtgever en bedrijfsbegeleider besloten om over te gaan op een iteratieve ontwikkelmethode. Hierbij wordt in eerste instantie een onderdeel volledig ontwikkeld. Pas wanneer de opdrachtgever daar tevreden over is begint de uitvoerder met het volgende onderdeel. 4.2 Verschilfunctie In week 12 van het project (19 november) bleek het bouwen van een volledig systeem voor de afstudeerder toch te moeilijk en werd in overleg met de afstudeerdocent besloten de focus te richten op de verschilfunctie. Dit gereedschap heeft tot doel inzichtelijk te maken welke rijen in de database van elkaar verschillen. Diezelfde functionaliteit dient ook van toepassing te zijn op bedrijfsobjecten, die soms verspreid over meerdere tabellen staan opgeslagen. Het verschil wordt alleen berekend tussen teksten. Andere datasoorten kunnen immers niet deels gewijzigd worden. Een getal bijvoorbeeld kan je niet een beetje veranderen; als het ook maar met 1 verhoogd wordt is het een volledig nieuw getal. In figuur 2 staan twee voorbeeld van teksten die aanzienlijk veranderd zijn: Figuur 2: Twee Eigenschappen die behoorlijk veranderd zijn. 4.3 Invantive Studio Invantive Studio is een nieuwe applicatie van Invantive, het wordt gebruikt om de specificaties voor IP te beheren. Aan het begin van de afstudeerperiode werd dat met Excel gedaan, dat is steeds meer overgenomen door Invantive Studio. De functionaliteit met een visuele interface is aan de applicatie Invantive Studio toegevoegd. Het is de bedoeling dat Invantive Studio uitgebreid word om de volledige functionaliteit van een versiebeheer systeem te bieden. Wouter Vos 10 / 53

11 5 Planning Startdatum: 20 augustus 2012 Einddatum: 25 januari 2013 Vakantie: De weken van 10 en 17 augustus 2012 Totale duur: 21 weken In overleg met de opdrachtgever en bedrijfsbegeleider is er aan het begin van de afstudeerperiode een planning gemaakt. Die is te zien in bijlage De vakantieperiode is afgesproken omdat de bedrijfsbegeleider toen met vakantie was. Gedurende de afstudeerperiode bleek echter dat de planning anders gestructureerd moest worden. Ook bleek het niet praktisch direct na de afstudeerperiode de afstudeerpresentatie te houden. Die werd twee maanden later ingepland. Gedurende die twee maanden heeft Invantive een werkplek voor de afstudeerder beschikbaar gehouden. De afstudeerder heeft daar gebruik van gemaakt en vooral gewerkt aan het verslag, de poster en zijn afstudeerpresentatie. Maar kon ook enkele verbeteringen aan het eindproduct realiseren. De gerealiseerde planning is te zien in bijlage 13.2 en heeft een totale duur van 30 weken. Wouter Vos

12 6 Methoden en Technieken 6.1 Inleiding In dit hoofdstuk komen de belangrijkste methoden en technieken aan bod die tijdens deze afstudeerperiode zijn gebruikt. Tevens worden de gebruikte gereedschappen besproken. 6.2 Interview Tijdens de eerste weken van zijn stage kreeg de afstudeerder een introductie in het ontwikkelen van software met Invantive Producer. Hierbij werd aandacht besteed aan de werking van het programma met ruimte voor vragen. 6.3 Waterval ontwikkelen Om een goed overzicht te krijgen in hoe een versiebeheersysteem geïmplementeerd moet worden, begon de afstudeerder via een waterval model met de ontwikkeling van een prototype. 6.4 Iteratief ontwikkelen Bij deze ontwikkelmethode bouwt de ontwikkelaar steeds een zo klein mogelijk onderdeel van de uiteindelijke applicatie. Daarna wordt dit voorgelegd aan de opdrachtgever, klant en eindgebruiker die dan feedback geven over het ontwikkelde onderdeel. Het doel hiervan is de ontwikkelaar zo snel mogelijk bij te sturen als het ontwikkelproces de verkeerde kant op gaat. 6.5 Model View ViewModel Een techniek met als doel om alles wat met het uiterlijk van het venster te maken heeft op één plek declaratief te definiëren. Om dit te realiseren is er apart ruimte gereserveerd voor het opslaan van gegevens en ruimte voor alle overige zaken. Die overige zaken bestaan meestal uit het berekenen van resultaten en toepassen van relevante logica. Declaratief betekent dat de ontwikkelaar aangeeft wat het resultaat moet zijn. Dit is het tegenovergestelde van procedureel. Waarbij de programmeur een aantal precieze opdrachten geeft die de computer uitvoer waarna een resultaat bereikt wordt. Het model bevat informatie die weergegeven wordt en die de gebruiker kan wijzigen. Dit verbetert uitbreidmogelijkheden en hergebruik van code. De view is zoveel mogelijk beschreven in een declaratieve taal. Dit maakt het mogelijk voor niet-technische ontwikkelaars een grote bijdrage te leveren aan het uiterlijk van het venster. Het ViewModel verzorgt de communicatie tussen deze twee onderdelen. Hier kan ook alle overige functionaliteit toegevoegd worden. Wouter Vos 12 / 53

13 6.6 Mockup Voordat ontwikkelaars beginnen met het schrijven van code voor een nieuw venster is het goed om het ontwerp voor het venster vast te stellen. Hierin is te zien hoe het venster er ongeveer uit komt te zien en welke functies de gebruiker kan oproepen. Een mockup is in korte tijd samen te stellen en laat duidelijk zien welke functionaliteit waar kom te zitten. Hierop kan de klant meteen feedback geven en kan het ontwerp zonder tijdverspilling bijgesteld worden. Bij het ontwikkelen van de functionaliteit Welke eigenschappen zijn verschillend heeft het maken van een mockup de afstudeerder veel werk bespaard. Na feedback van de klant moest het ontwerp twee keer volledig omgegooid worden. Figuur 3: Een mockup in Balsamiq geeft een idee weer 6.7 C# Een moderne programmeertaal gebaseerd op C++, Java en Visual Basic. Modern betekent dat het geheugengebruik automatisch beheerd wordt. Dit voorkomt fouten en versnelt het ontwikkelproces. Een nadeel is dat sommige optimalisatietechnieken niet meer mogelijk zijn en de programmeur minder direct toegang heeft tot de hardware. Echter het automatisch geheugenbeheer is zo goed dat de meeste programma s in C# beter presteren dan wanneer ze in C++ geschreven zouden zijn. Verder werkt C# vanuit het door Microsoft ontwikkelde.net Framework. 6.8.NET Framework Wouter Vos 13 / 53

14 Een flexibel platform, ondersteunt meerdere talen, technieken en mogelijkheden om deze met elkaar te integreren. Ook biedt het.net Framework een uitgebreide set hulpmiddelen die het ontwikkelen van software makkelijker maken. Verder zijn er bedrijven die pakketten functionaliteit speciaal voor het.net Framework ontwikkelen. 6.9 PL/SQL Deze taal van Oracle is gebaseerd op Ada en maakt het mogelijk op een goed gestructureerde manier programmeren. De taal maakt gebruik van Oracle technologie en is speciaal gemaakt om binnen Oracle database omgevingen uitgevoerd te worden. Hierdoor werken programma s zeer dicht op de gegevens die opgeslagen staan in de database en kunnen ze optimaal presteren. Daarbij kan de programmeur gebruik maken van de uitgebreide functionaliteit die in elke Oracle database omgeving aanwezig is WPF Windows Presentation Foundation [3] is een onderdeel van het.net Framework speciaal voor het maken van de vensters in een applicatie. Microsoft vind dat het bepalen hoe een venster eruit ziet heel ander werk is dan bepalen hoe het technisch werkt. Daarom gaat WPF er vanuit dat het uiterlijk van het venster op een aparte plek en in een andere taal gedefinieerd word. Om dit te bereiken ondersteund WPF het Model View ViewModel ontwerp principe Infragistics Infragistics levert sets visuele componenten, de nieuwste gebaseerd op WPF. Hun componenten zijn standaard veel mooier en bieden veel extra mogelijkheden. Bijvoorbeeld bij hun tabel, die biedt gebruikers standaard de mogelijkheid kolommen te verplaatsen Gereedschappen Invantive Estate wordt door Invantive zelf gemaakt en gebruikt om de eigen projecten te beheren. Als werknemer bij Invantive heeft de afstudeerder deze software elke dag gebruikt, voornamelijk voor het bijhouden van de gewerkte uren. Maar ook organisatorische zaken worden vaak via de agenda van Invantive Estate geregeld. Visual Studio is een krachtige ontwikkel omgeving voor het ontwikkelen van complexe software. Het is gemaakt door Microsoft en is dan ook bedoeld om.net applicaties mee te maken. Het is op bijna elke denkbare manier uitbreiden, waardoor het bijvoorbeeld ook mogelijk is Java projecten te ontwikkelen. De afstudeerder heeft Visual Studio gebruikt om de aanpassingen in het programma Invantive Studio te maken. Toad for Oracle is een programma om Oracle databases te beheren. Maar ook om PL/SQL code op die database uit te voeren. Dit was handig voor het testen van de algoritmen om verschillen te berekenen. Notepad++ is een tekst verwerker maar dan met wat functionaliteit voor programmeurs. Het standaard lettertype bevat letters die allemaal even groot zijn, waardoor code Wouter Vos 14 / 53

15 makkelijker te analyseren is. En het herkent de meeste programmeertalen waarbij het de sleutelwoorden herkenbaarder maakt door ze een kleur te geven. De afstudeerder heeft Nodepad++ gebruikt voor het schrijven van PL/SQL code. Balsamiq is een tool om mockups mee te maken. De plaatjes die je ermee maakt zullen er nooit gepolijst uit zien. Dit voorkomt dat de ontwikkelaar tijd besteed om alles er netjes uit te laten zien. Daarbij is het voor iedereen duidelijk dat het om een idee gaat, zodat er geen tijd besteed wordt aan allerlei details die in de ontwerpfase niet van belang zijn. Invantive Studio is een applicatie die door Invantive is ontwikkeld voor het beheer van de specificaties die door IP gebruikt worden. Het geeft een boomstructuur weer die te vergelijken is met de bestandstructuur op je eigen computer. Alleen bevat de structuur van Invantive Studio specificaties die bestaan uit bedrijfsobjecten in plaats van mappen en bestanden. Wouter Vos 15 / 53

16 7 Vooronderzoek 7.1 Inleiding Dit hoofdstuk legt uit wat een versiebeheersysteem is [4] en bekijkt een aantal manieren waarop Versiebeheer Repository Invantive Producer zou kunnen werken. Tegenwoordig maakt ieder software project gebruik van versiebeheer en buiten de software wordt versiebeheer zeer weinig toegepast, daarom zullen gebruikte voorbeelden uit de software wereld komen. 7.2 Waarom versiebeheer? Traditioneel zijn er meestal 5 tot 20 ontwikkelaars betrokken bij de ontwikkeling van een software project. Zij willen allemaal hun bijdrage leveren en daarvoor moeten ze vaak aan dezelfde bestanden werken. Echter wanneer zij hun werk willen samenvoegen levert dat vaak problemen op. Bijvoorbeeld: - twee gebruikers hebben beiden hetzelfde stuk code aangepast; - iemand heeft een functie aangepast of verwijderd die een anders juist ging gebruiken; - een wijziging zorgt ervoor dat het programma vastloopt. Een traditioneel versiebeheersysteem [5] maakt werkprocessen mogelijk waardoor deze problemen worden voorkomen of opgelost. Wanneer een gebruiker wijzigingen maakt kunnen andere gebruikers die aan hun eigen versie toevoegen. Als nieuwe functionaliteit problemen veroorzaakt kan gekeken worden hoe de software sinds de vorige versie veranderd is. Invantive wil deze werkprocessen ook toepassen bij de ontwikkeling van specificaties voor Invantive Producer. 7.3 Centraal versiebeheer De meeste versiebeheersystemen worden centraal op een server geïnstalleerd waar de huidige versie van het project en alle wijzigingen tot nu toe worden bewaard. Iedere gebruiker download de meest recente versie van het project, dat heet een werkkopie. De gebruiker werkt aan de code in zijn werkkopie en controleert of het programma naar tevredenheid werkt. Wanneer de functie naar tevredenheid is geïmplementeerd geeft de gebruiker het versiebeheer de opdracht commit. Het versiebeheersysteem vergelijkt de toestand van de werkkopie en berekent welke veranderingen zijn gemaakt ten opzichte van de meest recente versie. Met de resultaten van die berekening maakt hij een patch die alle gemaakte wijzigingen bevat. Dan wordt het meest recente versienummer verhoogd met 1. Vervolgens hebben alle andere gebruikers een verouderde versie omdat hun versienummer lager is. Iedere gebruiker kan dan opdracht geven tot een update, het systeem berekent dan welke wijzigingen die gebruiker nodig heeft. Die wijzigingen worden samengevoegd tot een patch en uitgevoerd op zijn werkkopie. Waardoor die alle wijzigingen bevat en overeen komt met de meest recente versie. Wouter Vos 16 / 53

17 Een belangrijke eigenschap hieraan is dat alleen de gemaakte wijzigingen uitgevoerd worden. Wanneer een ontwikkelaar bij een update een nieuwe kopie van de meest recente versie zou krijgen zouden al zijn gemaakte wijzigingen verloren gaan. In plaats daarvan worden de wijzigingen van andere ontwikkelaars op zijn werkkopie uitgevoerd en waarna hij weer verder kan werken. Verder is het mogelijk een aparte ontwikkeltak of branch aan te vragen, bijvoorbeeld voor de ontwikkeling van een speciale functie. Het versiebeheersysteem maakt dan een apart project met een eigen geschiedenis en zonder dat andere branches aangepast worden wanneer de ontwikkelaar een commit doet. Vaak wordt de meest recente versie van de hoofdtak of trunk gebruikt als basis waarop de ontwikkelaar dan verder kan werken zonder zich zorgen te maken over het veroorzaken van fouten of, of de wijzigingen van andere ontwikkelaars in de weg zullen zitten. Het is meestal de bedoeling dat die functie uiteindelijk samen gevoegd wordt met de trunk. Daarom kunnen wijzigingen op de trunk nog wel op de onafhankelijke tak worden uitgevoerd, zodat het samenvoegen zo eenvoudig mogelijk is. 7.4 Gedistribueerd versiebeheer Een recente ontwikkeling is versiebeheer dat bij iedere gebruiker geïnstalleerd staat; hierdoor heeft iedere gebruiker de hele geschiedenis van het project [4] [6]. Een commit maakt geen verbinding meer met een centraal systeem in plaats daarvan wordt het werk meteen lokaal opgeslagen. Wanneer de gebruiker een stukje gewerkt heeft kan hij meteen een commit uitvoeren om het werk op te slaan. Pas wanneer een functie klaar is voor gebruik en de gebruiker beschikking heeft over een internetverbinding geeft hij opdracht tot een push. Dan worden alle wijzigingen samengevoegd in een patch en aan collega s beschikbaar gemaakt. Die collega s kunnen vervolgens zelf beslissen of ze de wijzigingen willen hebben en geven dan opdracht tot een pull. Een voordeel hiervan is dat de gebruiker geen verbinding met andere gebruikers of het internet nodig heeft om zijn werk op te slaan. Hierdoor worden opdrachten aan het versiebeheer meestal veel sneller uitgevoerd. Ook heeft iedere gebruiker bij calamiteiten een reservekopie van het systeem, inclusief geschiedenis. Een nadeel is dat de volgorde waarop gebruikers updates binnen krijgen niet vastligt. Bij een centraal systeem kun je aan de versienummers altijd zien in welke volgorde ze gemaakt zijn. Een gedistribueerd systeem weet niet welke versienummers bij collega s in gebruik zijn. Dit wordt opgelost door een lange willekeurige code te genereren; die bijna altijd uniek is. 7.5 Voordelen van elk type Gedistribueerd: 1. Elke ontwikkelaar kan eenvoudig zijn wijzigingen vastleggen, zonder internetverbinding. Ze hoeven zich ook geen zorgen te maken of iedereen ze zou moeten zien; 2. Goede prestaties omdat de wijzigingen lokaal opgeslagen worden, bij de overige gegevens die allemaal lokaal aanwezig zijn; Wouter Vos 17 / 53

18 3. Goede ondersteuning voor vertakkingen en samenvoegen; 4. Nieuwe ontwikkelaars kunnen gemakkelijk bijdragen aan het project. Gecentraliseerd: 1. Centraal geregelde auticatie en autorisatie leiden tot betere beveiliging; 2. Een duidelijke lineair verloop van wijzingen door de geschiedenis; 3. Efficiënter gebruik van opslagruimte doordat de geschiedenis maar een keer opgeslagen wordt. 7.6 Toestanden van een werkkopie De toestand van een werkkopie is in beide systemen op vergelijkbare manier te beschrijven. Dit plaatje geeft aan welke acties er in welke toestand mogelijk zijn. Figuur 4: Toestanden en transities binnen de werkkopie van een gebruiker 7.7 Op een database werkt het anders Bestaande versiebeheersystemen werken op tekstbestanden in een mappenstructuur, terwijl Versiebeheer Repository Invantive Producer op een database zal werken. Die database wordt door een server toegankelijk gemaakt, dus is het logisch om het versiebeheer ook door die server uit te laten voeren. Verder heeft iedere gebruiker bij Invantive een eigen installatie van de database, die kan als werkkopie functioneren. Met Wouter Vos 18 / 53

19 een commit zal de gebruiker zijn werk opslaan, het werk naar collega s beschikbaar maken zal een aparte functie worden. Om het versiebeheer te ondersteunen komt er een extra database die de geschiedenis van alle werkkopieën bijhoud. Hier staat elke gemaakte verandering in. Een gebruiker kan met een commit natuurlijk veel veranderingen maken, dus commits staan er apart in en kunnen meerdere veranderingen bevatten. Hierdoor kan een verandering door verschillende commits toegepast worden. 7.8 Functies en kwaliteiten Doordat het versiebeheer op een database zal werken is het relatief eenvoudig zijn om het systeem bewust te laten zijn van de interne structuur. Binnen de database is namelijk expliciet opgeslagen hoe verschillende soorten data met elkaar verbonden zijn. Bijvoorbeeld: Een bedrijf heeft een aantal medewerkers en veranderingen in het bedrijf kunnen invloed hebben op de medewerkers. Dit staat opgeslagen in bedrijfsobjecten en database regels. Bij software zijn er ook afhankelijkheden, maar die moeten impliciet worden afgeleid. Dat zou de werking van een dergelijk programma zeer gecompliceerd maken. Er is bij de afstudeerder geen versiebeheersysteem bekend wat hier rekening mee houdt [7]. Een aantal eigenschappen die een versiebeheersysteem op een database zal hebben: 1. Het versiebeheersysteem houdt rekening met de interne structuur in de database; 2. Elke ontwikkelaar kan committen zonder zich zorgen te maken over de rest van het project; 3. Doordat alle databases op dezelfde server beheerd worden, hoeft het versiebeheer bij opdrachten niet over net netwerk te communiceren en zullen opdrachten snel uitgevoerd worden; 4. Het systeem maakt gebruik van de structuur in de database en de specificaties waarop het versiebeheer toegepast wordt. Het zal deze kennis gebruiken om verschillende versies op een goede manier samen te voegen; 5. Goede branch functionaliteit, die neerkomt op het aanmaken van een nieuwe database; 6. Goede centrale beveiliging; 7. Een duidelijke lineaire geschiedenis; 8. Iedere database omgeving is effectief een werkkopie en een branch; 9. Het systeem bevat beveiliging die ervoor zorgt dat samenvoegen, update of commit operaties alleen volledig of helemaal niet uitgevoerd worden. Nooit gedeeltelijk. Wouter Vos 19 / 53

20 8 Uitvoering 8.1 Inleiding Dit hoofdstuk gaat over de fase na het onderzoek. Het onderzoek had een ontwerp opgeleverd voor een versiebeheersysteem dat op elke database zou kunnen werken. Echter Invantive wil een versiebeheersysteem specifiek ontworpen voor IP. Dit kost minder om te ontwikkelen en onderhouden dan een systeem dat overal rekening moet houden. Ook kan het gebruik maken van de specifieke structuur van IP om extra functionaliteit te bieden. Daarbij is IP erg complex en zou het niet lukken om een volledig prototype te ontwikkelen dat wel die volledige aansluiting zou hebben met IP. Daarom hebben we in overleg besloten de planning aan te passen en over te stappen op een iteratief ontwikkelmodel. Hierdoor zou de afstudeerder steeds een enkele maar volledige functionaliteit te ontwikkelen. De eerste te ontwikkelen functionaliteit is de verschilfunctie. Die berekent verschillen tussen specificaties. Deze gegevens moeten vervolgens ook op een begrijpelijke manier aan de gebruiker getoond worden. 8.2 Waarom verschillen berekenen Bij het werken met een versiebeheersysteem hebben gebruikers regelmatig wijzigingen gemaakt waarvan ze niet willen dat iedereen ze heeft. Een aantal voorbeelden is: - Een bestand toegevoegd om even wat notities te maken; - Iets wat specifiek voor hun systeem een beetje anders moet werken; - Even een functie uitproberen (zonder gelijk een branch te maken); - Het uitvoeren van een update, middenin de ontwikkeling van een functie. Wanneer verschillen niet berekend zouden worden zouden alle gewijzigde bestanden volledig gekopieerd moeten worden. Als een gebruiker dan een update wil uitvoeren moeten alle gewijzigde bestanden volledig vervangen worden door de nieuwe versie. Hierdoor zou er effectief maar één persoon tegelijk aan een bestand kunnen werken. De berekening van verschillen zorgt ook voor een verbetering van de prestaties. In de meeste gevallen hoeven er maar enkele regels gewijzigd te worden. De meeste software projecten hebben bestanden van duizenden regels. Als die bij elke kleine wijziging allemaal over het netwerk verstuurd moeten worden wordt het systeem erg langzaam. In plaats daarvan stuur je alleen de regels die veranderen. Doordat het systeem weet wat de verschillen zijn kun je zien hoe het bestand in de loop der tijd veranderd is. Dit is erg nuttig bij het repareren van fouten waarbij je weet dat die door een recente wijziging veroorzaakt zijn. 8.3 Verschil algoritme Als eerste stap voor de verschilfunctie was er een algoritme nodig dat verschillen zou uitrekenen. De docent geavanceerde programmeertechnieken heeft een dergelijk algoritme al een keer besproken. Dat algoritme heeft de afstudeerder omgezet naar Wouter Vos 20 / 53

21 PL/SQL, zodat het op de database zou werken. Dit bleek een goede oefening om PL/SQL te leren programmeren. Om snel en nauwkeurig vast te stellen of het algoritme goed werkte gebruikte de afstudeerder een aantal testcases. Deze werden bij elke test allemaal uitgevoerd en iedere keer was meteen te zien of de huidige uitvoering het goede resultaat opleverde en hoe snel dat ging. Dit eerste algoritme is vrij eenvoudig, het werkt echter anders dan bij traditionele versiebeheersystemen. Zij vergelijken bestanden op regelbasis en werken dus met twee groepen regels. Een database heeft echter tabellen met rijen. Die kunnen niet als geheel met elkaar vergeleken worden, omdat de betekenis van gegevens afhankelijk is van de cel waar ze instaan. Bijvoorbeeld: In een scenario met een tabel persoon, met daarin voor elke persoon een voornaam en achternaam. Als een persoon Jensen als voornaam heeft en een andere Jensen als achternaam, zijn die teksten helemaal hetzelfde. Ze hebben echter een andere betekenis. Daarom zal de gekozen oplossing steeds de inhoud van individuele cellen vergelijken. De inhoud van die cellen bestaat uit teksten die op letterbasis met elkaar vergeleken worden. Eerst wordt er een rooster gemaakt waar ruimte is voor elke letter van beide teksten en er wordt een extra regel gemaakt om het algoritme van start te laten gaan. Het vergelijken van twee teksten werkt door steeds één letter van de ene tekst met één letter van de andere tekst te vergelijken. Dan wordt in een rooster opgeslagen hoeveel wijzigingen nodig zouden zijn om de eerste tekst op dat punt in de tweede tekst te veranderen. Wanneer de letters hetzelfde zijn hoeft er in het resultaat niets te veranderen en zijn er geen kosten. Dat noemen we een copy. De kosten zijn hetzelfde als de kosten die voor de voorgangers van beide letters berekend zijn. Wanneer ze verschillen, probeert het algoritme de letter in de eerste tekst te vervangen voor de letter in de tweede. Dat noemen we een replace. De kosten worden berekend door 1 op te tellen bij de kosten die al eerder zijn berekend, voor de voorgangers van beide letters. Soms is het echter beter de letter uit de eerste groep te verwijderen. Dat noemen we een delete. Deze kosten worden berekend door 1 op te tellen bij de kosten voor de vergelijking tussen de voorganger van de eerste tekst letters (de huidige letter van die tekst vervalt) en de letter van de tweede tekst. Of het is beter een letter die in de eerste tekst niet aanwezig was uit de tweede tekst te laten staan. Dat noemen we een insert. Deze kosten bereken je door 1 op te tellen bij de kosten voor de vergelijking tussen de letter van de eerste tekst letters en de voorganger van de tweede tekst letters (de huidige letter van die tekst wordt toegevoegd). Zie Figuur 5 voor een visuele weergave van de vergelijking tussen sporten (eerste tekst) en storend (tweede tekst). Wouter Vos 21 / 53

22 Figuur 5: sporten vergeleken met storend, c = copy, r = replace, d = delete, i = insert De letter s wordt gekopieerd. De letter p wordt vervangen voor de letter t. De letter o wordt gekopieerd. De letter r wordt gekopieerd. De letter t wordt verwijderd. De letter e wordt gekopieerd. De letter n wordt gekopieerd. De letter d wordt toegevoegd. Er zijn 3 operaties nodig om sporten in storend te veranderen. Deze uiteindelijke kosten zijn te vinden als het resultaat van de vergelijking tussen de laatste twee letters. Het verander pad bepaald hoe de ene tekst in de andere veranderd kan worden. Dit kan gevonden worden door vanaf de laatste twee letters terug te lopen en steeds de beste optie te nemen. Het algoritme bekijkt alle mogelijke verander paden en zal daardoor altijd het beste pad vinden. De berekentijd en benodigde opslagruimte voor dit algoritme zijn: lengte eerste tekst vermenigvuldigd met lengte tweede tekst. In dit voorbeeld zijn de berkenkosten 7x7 = 49 vergelijkingen. Stel dat je twee teksten heb van duizend tekens dan zijn de berekenkosten 1.000x1.000 = vergelijkingen. Dat noemen we een kwadratisch algoritme. 8.4 Snel algoritme Er zijn twee problemen met het eenvoudige algoritme. Ten eerste bevat de database regelmatig teksten die tot 4000 tekens lang kunnen zijn, wat een berekening van meerdere seconden oplevert. Ten tweede is de berekentijd afhankelijk van het aantal tekens. Het aantal wijzigingen maakt geen verschil, terwijl er meestal zeer weinig wijzigingen zijn. Hierdoor is veel winst te behalen is met een algoritme dat sneller is bij weinig wijzigingen. Daarbij berekenen traditionele versiebeheersystemen ook de verschillen tussen grote bestanden heel snel. Om vergelijkbaar resultaat te bereiken heeft de afstudeerder de volgende variaties geprobeerd: - Alleen vergelijkingen maken wanneer het algoritme verschil in de tekst tegen komt; Wouter Vos 22 / 53

23 - Bij gelijke tekens kopiëren en niet andere mogelijkheden bekijken; - Het algoritme uit een bron toepassen [8]. Deze bleken allemaal geen verbetering op te leveren. Het algoritme uit de bron implementeren lukte niet omdat de bron in academisch wiskundige taal geschreven was, die de afstudeerder niet voldoende begreep. Het doel om een snel algoritme te vinden was bijna opgegeven, toen de afstudeerder een project vond dat het algoritme [9] uit de bron had geïmplementeerd. De structuur van de snelle uitvoering is vanaf het begin opnieuw ontworpen om het snelle algoritme uit te voeren. Het werkt door vanaf de eerste letter van beide teksten en de laatste letter een verander pad richting het midden te berekenen. Dit resulteert in twee verander paden. Wanneer die elkaar raken, worden ze aan elkaar geknoopt tot het uiteindelijke verander pad. Verder zal het algoritme letters altijd kopiëren waar mogelijk, zonder te kijken naar andere mogelijkheden. Hierdoor wordt het beste verander pad niet altijd gevonden. Er zijn nog een aantal redenen waarom het algoritme zo snel is. Die komen in [8] en [9] uitgebreid aan bod. Het belangrijkste voordeel van dit algoritme is dat de berekentijd afhankelijk is van het aantal verschillen. Hierdoor zal het algoritme in scenario s met weinig verschillen altijd een zeer korte berekentijd hebben. 8.5 Welke eigenschappen zijn verschillend In het programma Studio kan de gebruiker specificaties selecteren en hun eigenschappen bekijken. Iedere specificatie bestaat uit bedrijfsobjecten die ieder voor een stukje functionaliteit zorgen, zoals Lego blokjes samen een geheel vormen. Wanneer meerdere bedrijfsobjecten geselecteerd zijn, worden de eigenschappen van het laatst geselecteerde element getoond. De afstudeerde heeft deze functionaliteit gewijzigd door de eigenschappen te vergelijken. Wanneer er verschil is tussen de eigenschappen word een standaard tekst weer gegeven, in plaats van de eigenlijke waarde. Hierdoor kan de gebruiker snel zien of er verschil zit in de eigenschappen van de geselecteerde bedrijfsobjecten. Om dit te kunnen doen heeft de afstudeerder eerst uitgezocht hoe Studio werkt, onder andere door vragen te stellen aan de programmeur die Studio gemaakt heeft: Johan. Daarna maakte de afstudeerde een mockup gemaakt om zo snel mogelijk een idee te krijgen hoe het er visueel uit kwam te zien. Het plan was om de manier waarop de tekst gewijzigd was direct in het venster weer te geven. Dit bleek niet gewenst. In Studio moest de gebruiker alleen kunnen zien of de bedrijfsobjecten verschil hadden. De gedetailleerde vergelijking kwam in een apart venster. Zonder de mockup zou de afstudeerder veel werk voor niets hebben gedaan hebben om de gekleurde tekst in het venster te krijgen. Dit is te zien in Figuur 9: Precieze weergave van verschillen tussen eigenschappen. Nadat dit werkte heeft de afstudeerder nog een hoop verbeteringen gemaakt om te zorgen dat het programma zich naar verwachting gedraagt. Verschillende type objecten hebben verschillende eigenschappen die niet met elkaar vergeleken kunnen worden. Daarom controleert het programma of alle geselecteerde objecten van hetzelfde type zijn en begint daarna pas met vergelijken. De gebruiker kan op allerlei verschillende manieren objecten Wouter Vos 23 / 53

24 selecteren of de-selecteren. Dus het programma moet goed opletten en wanneer dat mogelijk is zoveel mogelijk informatie weergeven. 8.6 Visualiseer verschillen tussen eigenschappen Het venster Compare Properties toont de gebruiker hoe de eigenschappen van alle geselecteerde bedrijfsobjecten verschillen. Ook bij dit venster is gebruik gemaakt van een mockup, aangezien het een nieuw venster is en de kleuring duidelijk moet maken waar verschillen zitten. Zie Figuur 8 en Figuur 9. Dit nieuwe venster maakt gebruik van WPF vanwege de verbeterde opties voor het opbouwen van visuele elementen. Onder andere voor het weergeven van tekst waar de opmaak per letter anders is. Bij dit venster moet eerst berekent worden welke gegevens getoond worden en hoe. Afhankelijk van alle waarden die verschillende bedrijfsobjecten voor een eigenschap hebben, wordt de achtergrondkleur aangepast. Dit zijn zeer visuele onderdelen. Daardoor is het niet gelukt MVVM (zie 6.5) volledig toe te passen. In de uiteindelijke oplossing maakt de View een aantal visuele hulpstukken die door het ViewModel gebruikt worden om het Model op te bouwen. Dan zit er al veel visuele informatie in het Model. Die informatie wordt dan bij de View aangeleverd zodat die alles direct kan weergeven. 8.7 Visualiseer verschillen tussen de specificaties Om ook verschillen tussen de inhoud van specificaties te visualiseren heeft de afstudeerder het venster Compare Contents gemaakt. Zie Figuur 10 en Figuur 11. Voor dit venster moeten alle aspecten van een bedrijfsobject moeten met die van een ander bedrijfsobject vergeleken worden. Verder moeten alle bedrijfsobjecten in dezelfde boomstructuur weergegeven worden als die waarin ze in Studio te zien zijn. Als eerste wordt de naam vergeleken. Als die anders is, wordt bij het resulterende bedrijfsobject weergegeven hoe dat veranderd is. Dan de eigenschappen. Als daar verschil in zit, maakt het programma een knop die een Compare Properties venster laat zien waar alle eigenschappen in detail vergeleken worden. Dan heeft ieder bedrijfsobject nul of meer groepen andere bedrijfsobjecten. Dat zijn per type bedrijfsobject altijd dezelfde groepen. Het vergelijken van twee willekeurige boomstructuren is erg complex [10]. Maar twee beperkingen zorgen ervoor dat het maximaal aantal vergelijkingen altijd het totaal aantal bedrijfsobjecten in beide groepen is. De bedrijfsobjecten staan op een bekende volgorde en er mogen geen dubbele voorkomen. Het algoritme werkt door van beide groepen een bedrijfsobject te nemen en die te vergelijken. De vergelijking geeft aan hoe de bedrijfsobjecten verschillen. Aan de hand van dit resultaat weet het algoritme hoe een of beide bedrijfsobjecten in de transformatie van de eerste groep naar de tweede verwerkt moet worden. Als een bedrijfsobject verwerkt is gaat het algoritme verder met het volgende bedrijfsobject uit die groep. In het voorbeeld is de bekende volgorde getallen van klein naar groot. Wouter Vos 24 / 53

25 Bijvoorbeeld: Neem twee groepen getallen die van klein naar groot zijn gesorteerd en waar geen dubbele in voorkomen. Het algoritme begint in beide groepen bij het eerste getal en vergelijkt die. De pijl geeft aan welke bedrijfsobjecten worden bekeken. 1 is kleiner dan 3 en zit in de tweede groep. Dus die wordt toegevoegd. In de tweede groep hebben we nu een bedrijfsobject verwerkt, dus kijkt het algoritme in die groep naar het volgende bedrijfsobject. 3 is kleiner dan 4 en zit in de eerste groep. Dus die wordt verwijderd. In de eerste groep is nu een bedrijfsobject verwerkt, dus kijken we in die groep naar het volgende bedrijfsobject. 4 en 4 zijn gelijk, bij een kopie hoeft verder niets te veranderen. In het algoritme betekent dit dat de identiteiten gelijk zijn, dan gaat een ander deel van het algoritme die bedrijfsobjecten verder vergelijken. In beide groepen kijkt het algoritme naar het volgende bedrijfsobject. 6 is kleiner dan 7 en zit in de eerste groep. Dus die wordt verwijderd. In de eerste groep is nu een bedrijfsobject verwerkt, dus kijkt het algoritme in die groep naar het volgende bedrijfsobject. 7 en 7 zijn gelijk dus is in beide groepen een bedrijfsobject verwerkt en kijkt het algoritme in beide groepen naar het volgende bedrijfsobject. In de eerste groep zijn er geen bedrijfsobjecten meer, dus kunnen we de overgebleven bedrijfsobjecten uit de tweede groep kunnen allemaal toevoegen De resultaten van dit algoritme worden in een boomstructuur weergegeven, die overeenkomt met de boomstructuur waarin de bedrijfsobjecten in Studio te zien zijn. Echter dan staat er per bedrijfsobject aangegeven of het bij de transformatie van de eerste naar de tweede groep, gekopieerd, gewijzigd, verwijderd of toegevoegd moet worden. Bij dit venster zijn er vergelijkbare problemen met MVVM (zie 6.5 Model View ViewModel) als met het vorige venster en de oplossing lijkt dan ook erg op de oplossing hierboven van het vorige venster. Het verschil is dat de visualisering van het verschil tussen de specificaties in de technische code uitgevoerd wordt in plaats van in de declaratieve taal van WPF. Wouter Vos 25 / 53

26 9 Resultaten 9.1 Inleiding In dit hoofdstuk komen alle producten/functies aan bod die deze afstudeerstage opgeleverd heeft. 9.2 Verschilberekening Voor een versiebeheersysteem is het belangrijk dat verschillen tussen de gegevens die beheerd, berekend kunnen worden. Dit is besproken in 8.2 Waarom verschillen berekenen. De werking van het algoritme staat beschreven in 8.3 Verschil algoritme. Deze functie berekent welke operaties uitgevoerd moeten worden om een gegeven tekst in een andere gegeven tekst te veranderen. Hij is in PL/SQL geschreven en aan het functie pakket op de database toegevoegd. Iemand die direct met de database werkt (bijvoorbeeld via Toad) hoeft de teksten dus niet eerst uit de database op te halen en kan ze direct vergelijken. De code voor deze functie in PL/SQL is te vinden in bijlage Testresultaten van de prestaties zijn te vinden in bijlage Snelle Verschilberekening Omdat ontwikkelen in C# voor de afstudeerder bekend terrein is en het snelle algoritme ook daar nodig is, is er eerst een C# versie gemaakt. Die is te vinden in bijlage Vervolgens heeft de afstudeerder die omgezet naar PL/SQL. Die versie is te vinden in bijlage Testresultaten van de prestaties zijn te vinden in bijlage Het algoritme is ontworpen vanuit de praktijk dat een ontwikkelaar meestal een paar wijzigingen maakt. Het maakt een aantal offers om ervoor te zorgen dat de berekentijd bij weinig wijzigingen veel beter wordt, zie Welke eigenschappen zijn verschillend? Deze functie is beschreven in 8.5. Figuur 6: Mockup welke eigenschappen hebben verschillen? Wouter Vos 26 / 53

27 Dit scherm is een aanpassing op het huidige scherm in Studio. Daarom zie je screenshots van bestaande knoppen: (boven) groeperen, sorteren, property pages, (onder) Business Objects, Audit, Refresh, Help. De knop Compare Details is toegevoegd. Verder zie je een lijst met de eigenschappen van het geselecteerde object en de waarde die er bij hoort. De weergave van het scherm is zo aangepast dat het anders reageert wanneer de gebruiker meerdere objecten selecteert. Er wordt dan een vergelijking gemaakt tussen de eigenschappen van die objecten en waar de objecten een andere waarde hebben voor dezelfde eigenschap wordt er <Different Values> weergegeven. In Figuur 7 is te zien hoe het onderdeel er uiteindelijk uit is komen te zien. Figuur 7: Eigenschappen venster De uiteindelijke uitvoering is dicht bij het idee gebleven. Zie Figuur 6: Mockup welke eigenschappen hebben verschillen? Alleen de knop Compare Details is iets verschoven en bevat nu de tekst Compare. Wanneer de gebruiker op de compare knop klikt, verschijnt er een venster waarin precies de verschillen tussen eigenschappen te zien zijn. 9.5 Verschillen tussen eigenschappen De functie van dit venster is beschreven in 8.6. In Figuur 8 is het ontwerp van dit venster te zien. Wouter Vos 27 / 53

28 Figuur 8: Mockup gedetailleerde vergelijking tussen eigenschappen Dit is een nieuw venster dat geopend wordt wanneer de gebruiker in het eigenschappen venster op Compare klikt. Je ziet een tabel met alle eigenschappen en per geselecteerd object de waarde voor die eigenschap. Waar die waarde anders is dan de waarde bij het eerste object is aangegeven hoe die veranderd is. Verwijderde tekst elementen zijn rood gekleurd, toegevoegde groen en gekopieerde tekst zwart. Daarbij hebben regels waar een verschil is een andere achtergrond kleur. Op regel 4 is te zien dat de eigenschap Definitie eerst geen waarde had en later wel. Het toegevoegde deel is groen gekleurd. Op regel 5 zie je dat er één letter is verwijderd en een letter is toegevoegd. Op regel 6 zie je dat de waarde is verwijderd. Op regel 8 zie je dat er een letter is toegevoegd. Bovenin is er een knop om alleen de rijen die een verschil hebben weer te geven. Als er veel eigenschappen zijn kan de gebruiker hiermee snel eigenschappen zonder verschillen laten verdwijnen. Daarnaast is er een knop dat de verschillen tussen de inhoud van de geselecteerde objecten zal visualiseren. Wouter Vos 28 / 53