Klavar Card-box. Eindverslag IN Bachelor project TI E.M. Bongers & G.J. Kunst TU Delft - Klavarskribo. TU Delft - Klavarskribo

Transcriptie

1 Oriëntatieverslag IN3540 BSc project Delft, Klavar Card-box Eindverslag IN Bachelor project TI TU Delft - Klavarskribo Begeleider TU Delft: P.R. van Nieuwenhuizen Begeleider(s) Klavarskribo: J.P.H. Kuiper (H. Kuiper) TU Delft - Klavarskribo

2

3 VOORWOORD Dit eindverslag is geschreven ten behoeve van het bachelor project, vak code IN3405, voor de studie Technische Informatica van de Technische Universiteit te Delft, ter verdienste van stichting Klavarskribo. Het verslag is bedoeld voor een ieder die geïnteresseerd is in het ontwikkelproces van een nieuwe elektronische kaartenbak voor stichting Klavarskribo. Hieronder wordt verstaan: het bestuur en de medewerkers van Klavarskribo en daarnaast alle betrokkenen bij het bachelor project. Lezers die slechts geïnteresseerd zijn in de mogelijkheden voor de toekomst en aanbevelingen daaromtrent, worden doorverwezen naar hoofdstuk 4. Een beknopte handleiding voor het nieuwe systeem kan gevonden worden in Bijlage 10: Beknopte handleiding. Onze dank gaat uit naar Arjan Kuiper en zijn vader, voor de waardevolle en duidelijke informatie die ze hebben gegeven. Daarnaast bedanken we P.R. van Nieuwenhuizen voor de goede en prettige begeleiding bij ons bachelor project. Delft, 19 maart 2011 Ewout Bongers, Gerben Kunst 2

4 INHOUDSOPGAVE Voorwoord Inleiding Stichting Klavarskribo De oude kaartenbak... 6 Functionaliteit... 6 Boekinformatie... 8 Auteursrechten De nieuwe kaartenbak Algemeen Data Projectverloop Planning Analyse Ontwerpfase Implementatie- en testfase Implementatieproblemen Gebruikersreview SIG codereview Projectevaluatie Behaalde resultaten Ervaringen Aanbevelingen Bijlage 1: Afbeeldingen oude kaartenbak... Bijlage 2: Functionaliteit oude kaartenbak... Bijlage 3: Opdrachtomschrijving... Bijlage 4: Oriëntatieverslag... Bijlage 5: Requirements document... Bijlage 6: Architectural Design Document... Bijlage 7: Technical Design Document... Bijlage 8: SIG Codereview 1... Bijlage 9: SIG Codereview 2... Bijlage 10: Beknopte handleiding... 3

5 1. INLEIDING Al jaren gebruikt stichting Klavarskribo een programma voor het registreren van informatie over de boeken die zij uitgeeft en/of verkoopt. In de loop der jaren is dit programma niet alleen sterk verouderd door de nieuwe ontwikkelde technieken, maar ook door veranderdingen aan de eisen aan de registratie van de boeken. Daarnaast zijn er enkele tijdrovende handelingen betreffende voornamelijk de afdracht van de auteursrechten, die eenvoudig geautomatiseerd zouden kunnen worden. Om deze en nog andere redenen wilde Klavarskribo een nieuwe applicatie die de huidige moet vervangen. Het doel van dit eindverslag is om een beeld te geven van het ontwikkelproces dat doorlopen is voor de ontwikkeling van een nieuwe elektronische kaartenbak; het bachelor project voor de studie Technische Informatica. In dit inleidende hoofdstuk worden in paragraaf 1.1 de opdrachtgever en de eindgebruiker belicht waarna paragraaf 1.2 een overzicht geeft van het oude systeem van de stichting, dat aan vervanging toe was. Paragraaf 1.3 geeft in het kort een overzicht van het nieuwe systeem. Het tweede hoofdstuk beschrijft het verloop van het project, aan de hand van de verschillende fases die doorlopen zijn. Hoofdstuk 3 evalueert het verloop van het project en geeft conclusies over de keuzes die gemaakt zijn. Tot slot worden in het 4 e hoofdstuk aanbevelingen gedaan wat betreft de mogelijkheden voor de toekomst STICHTING KLAVARSKRIBO Stichting Klavarskribo is uitgever, drukker en distributeur van bladmuziek op een alternatief muziekschrift dat de naam Klavar draagt. Ze geeft voornamelijk muziekboeken uit voor toetsinstrumenten wegens het feit dat het muziekschrift daarop gebaseerd is. Daarnaast geeft ze ook muziektheoretische boeken en lesmateriaal uit. De stichting wordt in stand gehouden door enkele medewerkers en door de bijdrage van vele vrijwilligers. De medewerkers hebben geen verreikende computervaardigheden en kennis. Ze zijn gewend met Microsoft besturingssystemen te werken (Windows XP, Windows Vista en Windows 7). Verder wordt er gebruik gemaakt van Microsoft Office, Adobe Acrobat voor PDF bestanden, waaronder bladmuziek in PDF formaat en software voor administratie en muzieknotatie. De belangrijkste, op zichzelf staande taken die door de medewerkers van stichting Klavarskribo, hetzij gedeeltelijk of geheel op computervlak worden verricht, zijn: de administratie van de boeken die worden uitgegeven en gedistribueerd; het afdrukken van boeken; het bijhouden van de website (d.w.z. bijhouden van de collectie muziekboeken); 4

6 het afhandelen van online bestellingen; het omzetten van muziekboeken vanuit het notenschrift naar Klavar; het maken van een boek; aanvullende administratieve handelingen. Zoals eerder gezegd, zijn de bovengenoemde taken op zichzelf staand. Dat willen zeggen dat ze uitgevoerd worden met behulp van verschillende applicaties die onderling niet gekoppeld zijn. Bijvoorbeeld als een nieuw muziekboek gemaakt, uitgegeven en gedistribueerd moet worden, moeten er in 3 verschillende omgevingen/applicaties zo goed als identieke wijzigingen doorgevoerd worden, namelijk: in de database die gekoppeld is aan de website, in de catalogus m.b.v. Microsoft Excel en in de SnelBase kaartenbak. Daarnaast zorgt deze gescheiden benadering ervoor dat veel andere dingen (waaronder de verkoop van een boek) handmatig geregistreerd moet worden op verschillende plaatsen, terwijl veel handelingen zeer eenvoudig geautomatiseerd zouden kunnen worden, wat een grote tijdwinst zou opleveren. Maar voordat die tijdwinst verkregen kan worden, moet eerst de functionaliteit van het oude programma geanalyseerd worden. Het volgende hoofdstuk beschrijft het oude programma en geeft daarbij ook gelijk enkele mogelijke verbeterpunten aan voor het nieuwe programma. 5

7 1.2. DE OUDE KAARTENBAK Klavarskribo gebruikt momenteel een sterk verouderd programma voor de registratie van de boeken die zij uitgeeft en verkoopt. Deze paragraaf bevat een uiteenzetting van de functionaliteit en daarnaast worden de belangrijkste onderdelen van het programma, namelijk de informatie over een muziekboek en de berekening van af te dragen auteursrechten, uitvoerig besproken. FUNCTIONALITEIT Het programma dat Klavarskribo al jaren gebruikt voor o.a. de registratie van haar boeken, draait enkel op MS-DOS, of onder Windows met behulp van een virtual machine. Het is dus sterk verouderd. De afbeeldingen in Bijlage 1 zijn schermafdrukken van het hoofdscherm van de kaartenbak met de belangrijkste menuonderdelen en een lege kaart. Zoals te zien is in figuur 1 van Bijlage 1, kan er in het oude programma niet alleen informatie over boeken bijgehouden worden, maar ook andere informatie waaronder cursisten en koor muziek. Klavarskribo heeft aangegeven welke onderdelen van het oude programma overbodig zijn. 6

8 Bijlage 2 is een overzicht van de onderdelen van het oude programma op basis van de menuonderdelen. De nuttige onderdelen zijn gemarkeerd (dikgedrukt en cursief). De belangrijke functies van het oude programma zijn: 1) het bijhouden van informatie over boeken; 2) het printen van een afdrukoverzicht t.b.v. afdragen van auteursrechten; 3) het zoeken van informatie over boeken; 4) het terughalen van informatie over gedane betalingen. Deze genoemde functies zijn niet volledig geïmplementeerd. Daarnaast is het programma vaak erg inefficiënt. Belangrijke negatieve kanten van het programma zijn: 1) er zijn velden die ontbreken; zo kent de oude kaartenbak o.a. geen vaste boekenprijs en kan dus bepaalde informatie niet opgenomen worden op een juiste plaats. 2) Een zoekopdracht duurt ongeveer 5 seconde op één van de snellere computers van dit moment(dat is: Corei7 processor en 6gb geheugen) 3) het maken van afdrukoverzicht voor een bepaalde auteur moet gedeeltelijk handmatig gedaan worden; 4) er is te weinig ruimte in sommige informatievelden, door het beperkt aantal karakters wat ingevoerd kan worden, waardoor niet alle informatie over een boek op de juiste wijze worden opgeslagen; 5) er kan niet met de muis gewerkt worden; er wordt heel veel gebruik gemaakt van standaard F-toetsen; 6) er past te weinig tekst in bepaalde informatievelden. 7

9 BOEKINFORMATIE Het oude programma biedt de mogelijkheid tot het opnemen van de volgende informatie over een muziekboek (zie ook figuur 3A en 3B); niet relevante informatievelden zijn doorgestreept: 1) Nummer Het unieke nummer (ook: catalogusnummer) van het boek 2) Titel De titel van het boek 3) Componist: De componist van het (muziek)boek a. Voornaam b. Achternaam 4) Arrangeur De arrangeur van het (muziek)boek 5) Instrument Het instrument waarvoor het (muziek)boek geschikt is 6) Graad Moeilijkheidsgra(a)d(en) van het muziekboek 7) In catalogus opgenomen Bepaald of het boek wel of niet in een catalogus is opgenomen 8) Aantal pagina s Het aantal pagina s dat het boek telt 9) Disk nummer Nummer van de diskette waarop het boek staat 10) Geregistreerd onder A: LP De Klavar Publisher bestanden voor het boek 11) Uitgever oud schrift De uitgever van het boek in notenschrift 12) Nummer oud schrift Het nummer wat aan het notenschriftboek is toegekend 13) Auteursrecht geregeld Bepaalt of het auteursrecht van een boek geregeld is met de auteur 14) Inhoud De inhoud van een boek 15) Prijs De verkoopprijs van een boek 16) Aantal Het aantal boeken dat de laatste keer is afgedrukt 17) Datum De datum van de laatste druk 18) Auteursrecht % Het percentage auteursrecht dat afgedragen moet worden aan de auteur(ook: % royalty) 19) Selektie Het nummer van de periode waarover auteursrechten zijn betaald 20) Afgerekend t/m De datum en het aantal waarover tot die datum auteursrechten(royalty) zijn afgedragen 21) Voorraad per Datum van een bepaalde voorraad 22) Aantal Het aantal waarover geen auteursrechten zijn afgedragen tot de datum van (nr. 21) 23) Voorraad ligt op De plaats waar de voorraad zich bevindt (bijvoorbeeld S 6 7 3(kast) of kopie PDF) 24) Origineel in De plaats waar het origineel zich bevindt (bijvoorbeeld in de kluis) 25) Voorraad Datum Naast deze velden waarin informatie kan worden ingevoerd, wordt er in bepaalde velden extra informatie toegevoegd. De belangrijkste velden en de informatie die daar extra bij ingevuld wordt, zijn de volgende. 26) Auteursrecht geregeld: indien het auteursrecht geregeld is moet er ingevoerd kunnen worden op welke datum het geregeld is. 8

10 a. Datum 27) Prijs: de mutatiedatum van de prijs, en een overzicht van de oude prijzen. a. Mutatiedatum De informatievelden voor de boeken zijn op een zeer inconsistente manier ingevoerd. Zo is bijvoorbeeld bij sommige boeken de naam van een componist ingevoerd zonder voornaam of met alleen voorletters, met een afgekorte naam en op nog veel meer andere manieren. Klavarskribo heeft aangegeven dat er nog andere informatie ingevoerd zou moeten kunnen worden, waaronder o.a. de omslag van, en voorraadinformatie over een boek en daarnaast een vaste boekenprijs. AUTEURSRECHTEN Een van de belangrijkste onderdelen van het oude programma is het maken van een overzicht voor af te dragen auteursrechten aan de uitgever. Auteursrechten worden afgedragen per selektie. Een zgn. selektie is, zoals eerder gezegd, een bepaalde periode waarover auteursrechten moeten worden afgedragen. Dit kan een periode van bijvoorbeeld een jaar zijn, maar ook van een half of van 2 jaar. Zo kan selektie: *31 duiden op de periode t/m of op het eerste kwartaal van Voor een bepaalde uitgever wordt aan het einde van een jaar een overzicht gemaakt met daarin de aantallen en te betalen auteursrechten van de boeken van die uitgever, die gedrukt of verkocht zijn door Klavarskribo. De uitgever stuurt dan in reactie daarop een factuur. Het maken van een zogenaamde afrekening voor af te dragen auteursrechten gaat bij de oude kaartenbak als volgt. Handmatig wordt bij elk boek (kaart in de kaartenbak) de selektie (zie 19) ingesteld op bijvoorbeeld *30 (het voorgaande jaar was het *29). Daarnaast wordt in het veld datum (zie 17) de datum ingevoerd tot wanneer auteursrechten worden afgedragen. Het aantal (zie 22) is dan het aantal boeken dat op de afrekening van de gedrukte boeken komt te staan. 9

11 1.3. DE NIEUWE KAARTENBAK Deze paragraaf beschrijft beknopt de belangrijkste eisen aan en mogelijkheden van de nieuwe kaartenbak. De eisen aan het nieuwe programma zijn grotendeels gebaseerd op het oude programma en de gebreken hiervan. Voor meer informatie over de nieuwe kaartenbak en zijn functionaliteit, verwijzen wij de lezer naar Bijlage 5: Requirements document. ALGEMEEN Het nieuwe programma moest in ieder geval de relevante functionaliteit van het oude programma bevatten, zoals beschreven is in paragraaf 1.2. Daarnaast moet het nieuwe programma ook over de in paragraaf 1.2 beschreven ontbrekende functies beschikken en moeten sommige onderdelen verbeterd en/of geautomatiseerd worden. Wat betreft de compatibiliteit en platformonafhankelijkheid: het programma moet op zowel Windows XP, Windows Vista, als op Windows 7 werken. Meestal wordt maar door één gebruiker tegelijk het programma gebruikt. Maar er moet rekening worden gehouden met de mogelijkheid dat 2 of 3 gebruikers simultaan de database benaderen. Verder zou de mogelijkheid om extern vanaf elke willekeurige locatie te werken via het internet, zeer op prijs gesteld worden. De belangrijkste onderdelen van het nieuwe programma zijn: De mogelijkheid tot het gebruik van de muis in plaats van alleen het toetsenbord. De mogelijkheid tot het invoeren van informatie waar in het oude programma geen ruimte voor is. Het automatisch genereren van een overzicht/afrekening t.b.v. af te dragen auteursrechten. DATA In de oude kaartenbak kan, zoals eerder gezegd, niet alle vereiste informatie over een boek worden opgenomen. Er moesten dus nieuwe velden toegevoegd worden waarin de informatie waar nu geen veld voor is, kan worden opgenomen. Ook moesten er beperkingen gesteld worden aan de informatie die in een bepaald veld ingevuld kan worden ter bevordering van de consistentie van de database, ten behoeve van ten eerste een mogelijke toekomstige koppeling van andere software met de database, waaronder de website van Klavarskribo en daarnaast om het mogelijk te maken om catalogi automatisch te maken. 10

12 2. PROJECTVERLOOP 2.1. PLANNING In de eerste week is er begonnen met het maken van een planning en het regelen van enkele praktische zaken, zoals afspraken maken met zowel de klant als de begeleider bij de TU. De planning was niet ruim maar zeker niet onhaalbaar. Uiteindelijk is er ongeveer 1 week extra uitloop nodig geweest. Op drie punten is de benodigde tijd onderschat bij het maken van de planning. Ten eerste heeft bij het maken van het ontwerp, het maken van de ontwerp-deliverables meer tijd gekost dan verwacht. Hiervoor is een extra week nodig geweest. Deze week is deels weer gecompenseerd met een week van de implementatiefase. Ten tweede bleek dat voor de implementatie van sommige onderdelen meer tijd nodig was dan was geschat. Maar door het goede ontwerp verliep de implementatiefase als geheel toch volgens schema. Ten derde was er onvoldoende rekening gehouden met de verwerking van de verschillende deliverables. Als er een document wordt verstuurd duurt het al gauw weer een week voordat de feedback gemaakt, ontvangen en verwerkt is ANALYSE Na de aanvang van het project en het maken van de planning is er een oriënterend onderzoek gehouden naar de methoden en middelen die goed bij het project aansluiten. Zo is ervoor gekozen om onder andere gebruik te maken van: C# 4.0, Visual Studio 2010, Windows Presentation Foundation (WPF) 4.0 en Subversion. [Bijlage 4: Oriëntatieverslag] Tijdens het oriënterend onderzoek heeft ook het meeste inhoudelijke contact met de klant plaats gevonden. Hierbij is een duidelijk beeld ontstaan van de wensen van de klant en hoe daar invulling aan gegeven kan worden. Ook is het oude systeem onderzocht op functionaliteit die vervangen moest worden. Hiervoor is een requirements document opgesteld, dat te vinden is in Bijlage 5: Requirements document. De requirements zijn enigszins optimistisch geformuleerd. Er zijn onderdelen als must-have opgenomen die eigenlijk, zo bleek later, geen musthave requirements waren. In het requirements document wordt bijvoorbeeld vermeld dat een muziekboek in pdf-vorm moet kunnen worden weergegeven. Tijdens het ontwerp en de implementatie, bleek bij het overleg met de opdrachtgever, dat enkel een locatie van de bestanden voor een muziekboek moet kunnen worden opgenomen in de applicatie. Aangezien er vanwege de nieuwe printer bij stichting Klavarskribo, geavanceerde printersoftware gebruikt wordt en moet worden gebruikt voor het afdrukken van een muziekboek, hoeft er niet geprint te kunnen worden vanuit de kaartenbak en is het niet nodig om een muziekboek in pdf-vorm weer te geven. Een ander requirement dat als must-have was opgenomen, is het maken van catalogi. [Bijlage 5; Functionele eisen: Algemeen] Omdat dit ten eerste niet behoorde tot de verplichte functionaliteit, en er ten tweede veel vereist handwerk aan te pas komt, levert het weinig tot geen vooruitgang op voor stichting Klavarskribo, om 11

13 het op te nemen in de kaartenbak. Daarom is deze requirement geen must-have maar could-have ONTWERPFASE Aansluitend op de analysefase is er een ontwerp gemaakt van het nieuw te realiseren systeem. In eerste aanzet was dit een ruwe beschrijving van de onderdelen en de eisen waaraan het nieuwe systeem moest voldoen. Later een gedetailleerdere uitwerking in het architectural design document [Bijlage 6: Architectural Design Document] en het technical design document [Bijlage 7: Technical Design Document]. Een centraal element in het ontwerp is de keuze voor het gebruik van het Model-View-ViewModel ontwikkelpatroon in combinatie met WPF. Dit bleek een een zeer effectieve combinatie te zijn. De opzet is logisch en is eenvoudig om mee te werken. Het is zelfs relatief moeilijk om per ongeluk anti-patterns te gebruiken omdat de complexiteit van het ontwerp dan snel toeneemt. Dit is een indicatie dat er iets mis zou zijn met het ontwerp. De goede en gedetailleerde uitwerking van het ontwerp heeft haar vruchten afgeworpen tijdens de implementatiefase waardoor er bijna geen refactoring en herontwerp nodig is geweest. Maar natuurlijk was het ontwerp niet perfect. Een ontwerpfout is de opzet van de entitymapper; de module die data converteert tussen het entityframework en het model van de applicatie. Het concept is dat de database dan niet rechtstreeks een afbeelding van het model hoeft te zijn, maar dat een aantal tabellen uit een database dan samen geconverteerd kunnen worden naar een object in het model van de applicatie. Naar het einde van het project werd duidelijk dat dit met het huidige ontwerp niet haalbaar is. Dit heeft vooral te maken met het type templating systeem in het.net framework: generics. In het eerste ontwerp waren de basisklassen niet generiek. Dit leidde echter tot veel copy/paste code, en dan voornamelijk van de ondersteunende functies (bijvoorbeeld het mappen van collecties). Door de basisklassen generiek te maken is veel functionaliteit gegeneraliseerd en is het aantal code-duplicaten sterk gereduceerd. Echter is hierbij niet gerealiseerd dat dit, expliciet een entityframework type verbind aan een object model type. Met andere woorden, de mappermodule dwingt nu een 1-op-1 relatie af van applicatie model naar database tabellen. Zie bijvoorbeeld de volgende definitie van de musicbookrepositoy. public class MusicBookRepository : BaseRepository<MusicBook, ED.MusicBook> {... } Een mogelijke oplossing zou zijn om de repository enkel nog via een interface te benaderen met als generic type het applicatie object type. Dit elimineert de directe referenties naar BaseRepository, en dus zijn ook andere implementaties mogelijk dan de 1-op-1 relatie. Dus bijvoorbeeld: public interface IRepository<T> where T : BaseModel {... } public class MusicBookRepository : BaseRepository<MusicBook, ED.MusicBook>, IRepository<MusicBook> {... } 12

14 Dit wordt echter pas noodzakelijk op het moment dat de database niet meer een 1-op-1 relatie is van het applicatie model, maar het is zeer onwaarschijnlijk dat dit in de toekomst nodig zal zijn. Er was in de planning geen ruimte meer om dit nog goed op te lossen. ACTIVITY DIAGRAM 1 Validatie van een Publisher van een MusicBook, resulterend in een validatiesequentie met een oneindige loop (geen eindtoestand). Het laden van een object had eenzelfde sequentie. Een ander gemis in het ontwerp was het niet voorzien, en op meerdere plaatsen terug komen van, onbegrensde recursie in de functies over de data. Een eenvoudig voorbeeld is het laden van een object uit de database. Stel MusicBook A wordt geladen uit de database. Deze bevat een PublicationRemarkCollection die een relatie weergeeft tussen een MusicBook en een Publisher, inclusief opmerkingen en andere gegevens. De Publisher bevat ook een PublicationRemarkCollection. Door tijdens het laden de volledige objectgraaf af te lopen wordt niet alleen de volledige database (of een groot deel daarvan) geladen, maar komt ook MusicBook A onherroepelijk nogmaals aan de beurt om geladen te worden. Dit resulteert in een race tussen de OutOfMemoryException en de StackOverflowException, waarbij beide natuurlijk niet wenselijk zijn. De eerste aanzet tot het oplossen van dit probleem, was het idee om collecties lazy te maken en dus slechts te laden als hun elementen ook echt nodig zijn. Dit bleek echter niet dekkend omdat: er nog steeds teveel objecten uit de database worden geladen omdat er ook referenties buiten de collections bestaan, cycles in de object graaf kunnen optreden die niet door collecties ontstaan, en het gebruik van de.net collection basisklasse (ObservableCollection<T>) wel veel werk scheelt, maar wel vereist dat de collection geladen is op het moment dat de instantie wordt aangemaakt. Uiteindelijk is ervoor gekozen om model objecten zelf lazy te maken. Dit is (bijna) volledig gerealiseerd in de mapper module door gebruik te maken van proxy klassen. Dit is een systeem binnen het.net framework waarmee instanties kunnen worden gegenereerd die de eigenschappen (properties en methods) van een andere klasse kunnen nabootsen. Pas als er een methode aanroep gedaan wordt (of property get/set, wat achter de schermen ook methoden zijn), onderschept de proxy de aanroep. Na het onderscheppen kan de proxy het werkelijke object uit de database laden en de methode aanroep daarop uitvoeren. Deze oplossing heeft als voordeel dat: er echt niet meer dan het strikt noodzakelijke uit de database wordt gelezen het onzichtbaar is voor de rest van de applicatie er geen noemenswaardige wijzigingen in het model nodig zijn 13

15 Er wordt wel een prijs betaald door een aantal extra complicaties bij methoden aanroepen. Voor de geïnteresseerde lezer, zie de EntityProxy klasse in de code. Een ander voorbeeld van de onbegrensde recursie die niet was voorzien bij het ontwerp is de validatiemodule. Deze heeft als taak te bepalen of een applicatie modelobject geldig is of niet. Over het algemeen bevat de geldigheidseis ook de geldigheid van alle gerelateerde modelobjecten. Zo is een MusicBook niet geldig als zijn Publisher null of ongeldig is. Anderzijds is een Publisher niet geldig als deze ongeldige MusicBook objecten bevat. Hier ontstaat dus eenzelfde situatie als bij het laden uit de database. Een voor de hand liggende eerste stap om dit op te lossen is door het limiteren op proxy objecten. Immers als een MusicBook geldig is, en de bijbehorende Publisher (proxy) is niet geladen, dan moet die Publisher nog geldig zijn, onder de aanname dat de database enkel geldige objecten bevat. Deze implicatie is echter niet meer geldig als er geldigheidseisen worden geformuleerd voor de collectie MusicBooks van Publisher als geheel. Bijvoorbeeld als er een eis is "er mogen maar 5 MusicBooks zijn per publisher", dan moet de publisher geladen worden om dit te controleren. In de Klavar- Cardbox applicatie zijn deze formuleringen vermeden en niet noodzakelijk gebleken. ACTIVITY DIAGRAM 2 Validatie van een MusicBook waarbij bijgehouden wordt of een Publisher al gevalideerd is. Voor de overzichtelijkheid is de validatie van de muziekboeken van een Publisher weggelaten. Dit gaat op dezelfde wijze als de validatie van publishers. Voor de validatie module is een restrictie op een proxy echter niet genoeg. Als namelijk het MusicBook een Publisher heeft die wel uit de database geladen is, is het nog steeds mogelijk om in een ongelimiteerde recursieve aanroep te geraken, nl. MusicBook A valideert Publisher 1, Publisher 1 bevat en valideert MusicBook A, MusicBook A valideert Publisher 1, etc. Uiteindelijk is ervoor gekozen om per thread een stack bij te houden, die wordt gevuld met objecten die op dat moment worden gevalideerd. Zodra er dan een object wordt gevalideerd die al op de stack staat, wordt die overgeslagen (de decision in ). Dit vormt dan een depthfirst over de objectgraaf van geladen objecten IMPLEMENTATIE- EN TESTFASE Deze paragraaf bespreekt het verloop van de implementatiefase en de tests die gedaan zijn. Omdat er gedurende de implementatie getest is en het vervolg van de implementatie afhankelijk is van de reviews van de tests, zijn deze twee 14

16 onderdelen, implementatie en testen, als één paragraaf opgenomen. IMPLEMENTATIEPROBLEMEN De implementatiefase begon met het opzetten van het model en de entitymapper module. Dit verliep goed en was relatief eenvoudig. Het opzetten van de eerste paar klassen was het meeste werk, maar toen die eenmaal gemaakt waren, was het opzetten van de overige modellen een combinatie van in het ontwerp kijken, copy/paste en namen aanpassen en zo nodig het instellen van initialisatiewaardes. Voor de entitymapper was initieel een zelfde ontwikkelprocedure. Echter was hier later nog aanvullend werk voor nodig; voornamelijk voor de proxy objecten. De applicatiemodule bestaat hoofdzakelijk uit WPF/XAML elementen. Dit was voor beide ontwikkelaars onbekend terrein. Initieel ging de ontwikkeling wat langzaam, maar na een opstart en leerperiode verliep het ontwikkelwerk gestaag. Door het verbeterende inzicht in de werking van WPF is het vaak voorgekomen dat reeds opgeloste problemen werden vervangen door een betere oplossing. Daarnaast is gebleken dat WPF zelf niet bug vrij is. Daardoor is het meerdere malen voorgekomen dat er een alternatieve en/of suboptimale oplossing gemaakt moest worden, wat ook de nodige tijd kostte. FIGUUR 4 Een geopende BaseModel- SelectionBox met geselecteerde componisten. Naar het einde van de ontwerpfase, werd al snel duidelijk dat het veel werk zou schelen als er een paar herbruikbare elementen gemaakt zouden worden. De BaseModelSelectionBox is het meest prominente voorbeeld hiervan. Het doel van dit element is om de gebruiker een collectie model objecten te laten selecteren, bijvoorbeeld de componisten bij een muziekboek. Visueel ziet het er uit als een groot uitgevallen ComboBox, maar het biedt ondersteuning voor data binding, zoeken op invoertekst en direct editen en aanmaken van elementen. De gedachte was, dat als dit element eerst gemaakt zou worden, dat veel tijd zou besparen bij de rest van de implementatie. Dit bleek slechts ten dele waar, er is inderdaad tijd bespaard met het hergebruiken van dit element. Echter, omdat dit een van de eerste ontwikkelstappen was van de applicatie module, bleek dit met de prille WPF-kennis een lastige opgave. Na de eerste versie is er nog gedurende 2/3 e van de implementatiefase verbeterd en veranderd aan de BaseModelSelectionBox. Niet alleen de zelfgemaakte elementen bleken lastig, maar ook een aantal standaard elementen uit WPF bleken in de praktijk vrij complex te zijn. Zo zou het DataGrid component een standaard oplossing moeten zijn voor de weergave van data in tabelvorm voor bijvoorbeeld de royalty gegevens van een muziekboek. Al snel bleek dat het databinding concept van WPF lastig in te passen was in het DataGrid. Daarnaast was het voor de gebruiker vrij eenvoudig om het object model van het DataGrid in een inconsistente staat te brengen. Hierover is veel te vinden op het internet, maar geen van de gevonden oplossingen (of combinatie daarvan) was voor ons een acceptabele en dekkende oplossing. Daarom hebben we zelf een oplossing bedacht, die zeer goed bleek te 15

17 werken en door de gebruiker als zeer aangenaam werd ervaren. Deze oplossing is te vinden in de volgende paragraaf. GEBRUIKERSREVIEW Eind januari is er samen met de klant een testmoment met observatie geweest. De applicatie was vergenoeg gevorderd om een duidelijk beeld te geven van de functionaliteit. De klant kreeg zonder al te veel instructies een versie van de applicatie om mee te werken. Het doel was het doorlopen van de normale workflow, beginnend bij het invoeren van een muziekboek tot aan het maken van het verkoopoverzicht. Hieruit bleek duidelijk hoe de klant verwachtte om te kunnen gaan met de applicatie/interface, en hoe dat soms botste met de opzet van de applicatie. De belangrijkste punten waren: De DataGrids werkten erg onbetrouwbaar en resulteerden vaak in een exceptie voordat de taak was voltooid. De BaseModelSelectionBox bleek niet "natuurlijk" te werken voor de klant, de opties waren te complex, en hier en daar vertoonde ze net als de DataGrids ook onbetrouwbaar gedrag. Datasynchronisatie was niet als verwacht. Bijvoorbeeld: o User begint een nieuw MusicBook o User begint een nieuwe Publisher o User slaat de nieuwe Publisher op o User verwacht nu bij MusicBook de nieuwe Publisher te kunnen selecteren Publishers worden pas geladen bij het beginnen van een nieuw MusicBook, de nieuwe Publisher is dus nog niet zichtbaar. Een aantal kleine punten die naar voren kwam bij de test kon worden opgelost door de gebruiker vooraf instructies te geven. De meeste problemen konden worden opgelost door een andere invulling te geven aan gebruikersinterface elementen. Tot aan het evaluatiemoment met de klant verliep de implementatiefase redelijk conform de planning. Er is toen gekozen om gelijktijdig verder te werken aan het wegwerken van de issues van de klant en het verder gaan met en compleet maken van de functionaliteit. Bij problemen/vastlopen is er gewisseld van taak zodat er zo min mogelijk tijd verloren ging. Dit bleek een effectieve strategie. FIGUUR 5 De vervangende oplossing voor datagrids, met buttons voor update/create/delete. Uiteindelijk is van de DataGrids de ingebouwde update/create/delete functionaliteit uitgezet en zijn er buttons toegevoegd om de lijst en de elementen te bewerken. Bij de BaseModelSelectionBox is er voor gekozen om de edit en nieuw element functies niet meer in de dropdown weer te geven, maar om deze in een dialoog venster te zetten. Zo blokkeert de applicatie tot er wordt geaccepteerd of geannuleerd. Dit bleek een goede oplossing te zijn; niet alleen visueel maar het heeft ook de logica van de BaseModelSelectionBox sterk vereenvoudigd. 16

18 SIG CODEREVIEW Naar het einde van de implementatiefase was er de mogelijkheid om een codereview te laten uitvoeren door de Software Improvement Group (SIG). Er is voor gekozen om hieraan deel te nemen, waarop de code werd opgestuurd naar SIG. Een korte tijd later kwam er de volgende reactie: "[... ] De code van het systeem scoort bijna 4 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. Dit is vooral toe te schrijven aan de relatief kleine omvang van het systeem. De score wordt naar beneden gehaald door duplicatie en module coupling. De lage score op duplicatie wordt veroorzaakt door een relatief hoog percentage van gedupliceerde code (ongeveer 15%). [... ] Het tweede aspect waarop het systeem laag scoort is de module coupling, oftewel het percentage van code wat relatief vaak wordt aangeroepen. Normaal gesproken zorgt code die vaak aangeroepen wordt voor een minder stabiel systeem omdat veranderingen binnen dit type code kan leiden tot aanpassingen op veel verschillende plaatsen. [... ] [Over de klasse BaseModel] Het versimpelen van de class en het uit elkaar trekken van de verschillende rollen zou het voor toekomstige ontwikkelaars makkelijker maken om wijzigingen aan te brengen en wordt daarom ook aanbevolen. Over het algemeen is de code in het systeem kort en simpel, voor zowel methode-lengte als methode-complexiteit scoort het systeem bovengemiddeld. Blijf dit ook in de gaten houden tijdens de laatste fase van het ontwikkelen. Als laatste nog de opmerkingen dat er geen (unit)test-code is gevonden in de codeupload. Het is sterk aan te raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gedefinieerd te hebben [ ]" van Eric Bouwers (SIG) dd. 13-feb-2011 (Zie 17

19 Bijlage 8: SIG Codereview 1 voor de volledige tekst) Het commentaar van SIG was zeer helder en goed bruikbaar om de code te verbeteren. De hoofdzakelijke boosdoeners voor het punt van duplicatie waren een tweetal testklassen, waarvan nog niet duidelijk was wat de beste oplossing was. Uiteindelijk zijn hierover beslissingen genomen en is het grootste deel van de duplicatie verwijderd. Wat nog wel resteert aan "duplicatie" is voornamelijk te vinden in de model klassen, namelijk de definitie van alle eigenschappen. Strikt genomen is dit geen duplicatie omdat de namen en types van deze eigenschappen verschillen, toch is het zo dat de code sterk op elkaar lijkt. Hetzelfde geldt ook voor de mappers en repositories uit de mapper module. Er was helaas geen tijd meer om ook dit goed op te lossen door bijvoorbeeld een (runtime) code generator, wat dan weer een performance drawback zou hebben. Het probleem van de module coupling was lastiger aan te pakken. Dit heeft te maken met het ontwerp van de BaseModel klasse, dat een belangrijk element in het ontwerp als geheel vormt. Vanuit de applicatiemodule is de eis aan deze klasse dat deze de interfaces INotifyPropertyChanged en IDataErrorProvider implementeert. Dit bespaart veel tijd bij het ontwikkelen en elimineert veel complexe code die anders nodig zou zijn om de weergave en het model synchroon te houden. Hieruit volgt dan inderdaad dat de klasse twee rollen vervult zoals Eric opmerkt. Omdat het gros van de validatie code al uit BaseModel was verplaatst naar andere klassen, zijn de implementaties van de laatste paar validatiemethoden ook uit BaseModel verwijderd en in een aparte Validator klasse gezet. Zo wordt in ieder geval de taakverdeling en de functie van de klasse duidelijk. Dit verhelpt echter nog niet het probleem van de hoge mate van module coupling omdat er nog geen methode aanroepen zijn gereduceerd. Alle eigenschappen van een modelklasse bevatten een getter en een setter. De eis van INotifyPropertyChanged is dat een wijziging van de eigenschap een event genereert, zodat de weergave synchroon gehouden kan worden. Er zijn dan 2 mogelijke implementaties: 1. Elke eigenschap krijgt zijn eigen veld, getter en setter, en elke setter genereert zelf een event: private int feigenschapx; public.ctor() { feigenschapx = <defaultwaarde>; } public int EigenschapX { get { return feigenschapx; } set { if (feigenschapx!= value) { feigenschapx = value; GenereerEvent("EigenschapX"); } 18

20 } } 2. De basis klasse (of een andere klasse) houdt alle velden bij in een dictionary en biedt een generieke methode voor de setter: [DefaultValue(<defaultwaarde>)] public int EigenschapX { get { return GetValue("EigenschapX"); } set { SetValue("EigenschapX", value); } } Er is gekozen voor de 2de oplossing omdat dan enkel de methoden van de basisklasse getest hoeven te worden en de basis klasse automatisch de standaardwaardes kan initialiseren, wat weer resulteert in minder code. Het is waarschijnlijk dat ook de referenties binnen de model-module zijn geteld voor het meten/bepalen van de module coupling score. Met 101 eigenschappen is het dan ook niet verwonderlijk dat de module coupling score op ongeveer 200 uitkomt. Wij zijn echter van mening dat de functies van GetValue en SetValue zo duidelijk zijn begrensd, dat een wijziging in hun implementatie niet zal leiden tot een vereiste aanpassing op alle punten waar deze methodes worden gebruikt. Daarom zal de hoge mate van coupling op dit punt dus niet leiden tot vermindering van de onderhoudbaarheid van de code. De suggestie om unit-tests op te zetten is wegens gebrek aan tijd niet meer uitgevoerd. Het komt de onderhoudbaarheid natuurlijk ten goede om dit in de toekomst zeker toe te voegen aan het project. Net na het begin van de implementatiefase is er wel geëxperimenteerd met het opzetten van unit tests. Echter is het (met opzet) zo dat er weinig complexe logica en code is. In het experiment werd de meeste unit-test code complexer dan de te testen code, waardoor eigenlijk de testcode getest zou moeten worden in plaats van de te testen code. Dit heeft deels te maken met de volgorde waarin de implementatie is verlopen. Toen het unit-test systeem geprobeerd werd, waren enkel de mapper en de model module ver genoeg gevorderd om te kunnen testen. Dit zijn voor het grootste deel simpele en copy/paste methodes. Zoals Eric al aangeeft heeft het wel de voorkeur om de naderhand gemaakte code te doorlopen om te kijken of er complexere methoden zijn waarvoor een unit-test nuttig kan zijn. 19

21 3. PROJECTEVALUATIE 3.1. BEHAALDE RESULTATEN Het hoofddoel van dit project was maken van een vervanging voor het oude systeem en daarbij het automatiseren van enkele zeer tijdrovende handelingen. Dit doel is helemaal behaald. Ook is het systeem dermate stabiel dat het, na korte instructie van de eindgebruikers, in de praktijk ingezet kan worden. De applicatie is daarmee het stadium prototype voorbij gestreefd, wat we als doel hadden gesteld. Er zijn nog wel enkele must-haves and could-haves die geïmplementeerd moeten worden, maar dit zijn management functies (zoals het maken van een back-up) die ook in een latere release mee genomen kunnen worden, en geen belemmering vormen voor het correct vervullen van het primaire doeleinde van de kaartenbak. Na het afronden van de implementatiefase, is er samen met de klant een evaluatie geweest om te zien in hoeverre het nieuwe systeem voldoet aan de eisen en verwachtingen. De klant was zeer tevreden met het eindproduct voor het project, en voldeed aan zijn eisen en verwachtingen. Er zijn alleen enkele kleine verbeteringen geopperd, en de opmaak van het overzicht voor de te betalen auteursrechten is iets aangepast ERVARINGEN Het is duidelijk dat de TU heeft geprobeerd om met de studie Technische Informatica ons goed voor te bereiden op het ontwerpen en maken van software op een degelijke manier. Voor het grootste gedeelte is de opleiding erin geslaagd ons genoeg kennis mee te geven om een software-ontwikkelproject tot een goed einde te brengen. Toch zijn er een aantal fijne kneepjes die enkel in de praktijk geleerd kunnen worden. Een voorbeeld hiervan is het maken van een inschatting van de benodigde tijd voor het implementeren van softwareonderdelen. In veel van de voorgaande projecten in de opleiding (waaronder ST1 t/m ST4) ligt de nadruk voornamelijk op het correct doorlopen van het ontwikkeltraject, en is de implementatiefase minder belangrijk. Het is met dergelijke kleinere projecten lastig om dit goed te leren. Een ander fijn kneepje is het maken van een systeem voor de eindgebruiker conform alle wensen en met volledige functionaliteit. Daarnaast is het moeilijk om te bepalen wanneer het systeem stabiel genoeg is om het daadwerkelijk in te kunnen zetten. Bij voorgaande projecten van TI kon altijd worden volstaan met een demo met geprepareerde data, waarbij bekend was welke functionaliteit wel en niet werkte, en waar de grote bugs zaten. Hierbij werd de laatste stap altijd afgedaan met slogans als bug count richting 0 of polishing. In praktijk is dit uiteraard niet mogelijk en het oplossen van al deze problemen bleek zeer tijdrovend te zijn; iets wat we niet bij de projecten van de opleiding TI ervaren hadden. Daarnaast is het in realiteit van groot belang om in een systeem wat in ontwikkeling is, een logging mechanisme op te nemen zodat de status bewaakt kan worden, waardoor foutopsporing achteraf mogelijk is; ook als het systeem in gebruik genomen is. Dit is iets wat nooit bij projecten op de TU aan de orde is gekomen. 20

22 Andere zaken zijn juist wel geleerd in voorgaande TU vakken en practica. Een mooi voorbeeld zijn de lambda-expressies die nodig zijn om bijvoorbeeld een dialoogvenster te openen en te sluiten. Het resultaat kan worden geïnterpreteerd als een continuation style programma, iets wat in Principles of Programming languages uitgebreid aan bod is gekomen. Dit is een elegante stijl van programmeren waar de uiteindelijke bewerking wordt uitgesteld tot het einde van een keten, en alle benodigde (variabele) informatie wordt meegenomen in de closure van de lambda expressie. Het gebruik van het V-model voor het doorlopen van het softwareontwikkeltraject bleek erg flexibel en goed. Bij de vakken software engineering zijn modellen voor het ontwikkelen van software uitgebreid aan bod gekomen. Hierom hebben we voor een bepaald model gekozen, wat in praktijk veel houvast gaf. De keuze voor het V-model gaf, zoals we tijdens de oriëntatiefase al verwacht hadden veel vrijheid en de mogelijkheid om simultaan aan verschillende fases te werken. Ook konden we daardoor tijdens de implementatie al een test met de gebruiker doen. [Bijlage 4; Softwareontwikkelproces: Ontwikkelmodel] Er is veel geleerd over de gebruikte ontwikkelomgeving. Met name WPF en XAML, aan het begin nog terra incognita, bleken een hele nieuwe wereld van ongekende mogelijkheden. De combinatie van het MVVM ontwikkelpatroon in combinatie met WPF en C# bleek zeer krachtig te zijn. Het geeft een perfecte scheiding van data, logica en weergave; iets wat we niet met andere programmeertalen in combinatie met design patterns zoals MVC konden doen. Het is in ieder geval in theorie zelfs mogelijk om een compleet nieuwe gebruikersinterface te ontwikkelen zonder één enkele regel C# code met betrekking tot de programma logica te moeten aanpassen. Het vak Datastructuren en Algoritmes is zeer goed van pas gekomen bij de recursieve functies van het datamodel. De geleerde inzichten over de werking van recursieve functies, te weten het ontbreken van stop condities, was direct van toepassing bij het oplossen van problemen. Ook bood het inzicht in het herkennen van recursieve functies ook al zijn ze niet direct als zodanig gedefinieerd. We concluderen dat we zeer veel hebben geleerd bij dit project en daarbij veel hebben gehad aan de onderdelen van de opleiding TI wat betreft het ontwikkelen van software. 21

23 4. AANBEVELINGEN Dit hoofdstuk beschrijft de mogelijke toekomstige uitbreidingen en verdere ontwikkeling van de kaartenbak en andere software die hier mee te maken heeft. Klavarskribo heeft verschillende dingen aangedragen en zelf hebben we ook veel ideeën gevormd voor verdere uitbreiding in de toekomst. Voor de verdere ontwikkeling van de kaartenbak, zijn er een drietal modules die gemaakt kunnen worden. Dit zijn het maken van een backup van de database, het maken van catalogi en het factureren. De backup van een database zou gemaakt kunnen worden door middel van het gebruik van batch files. Daarnaast kan er aan de kaartenbak een knop worden toegevoegd waarmee backups gemaakt en teruggezet kunnen worden. Er moet hiervoor een module gemaakt worden die batch-files kan uitvoeren. Bij het maken van een module die catalogi kan maken, moet rekening gehouden worden met het feit dat in de catalogi verschillende ordeningen worden aangehouden waaronder series van muziekboeken zoals Nederlandse orgelmuziek Boek I en Nederlandse orgelmuziek Boek II, die ondanks een verschillende componist en catalogusnummer in sommige gevallen toch achtereenvolgens in een catalogus moeten worden gezet. Daarnaast bevatten de catalogi verschillende categorieën. Zo staat bijvoorbeeld in de catalogus Klassiek orgel naast de hoofdcategorie ook een categorie Orgel met solo instrument. We raden daarom aan om voor catalogi categorieën en series te maken. Klavarskribo beschikt momenteel over een programma voor het doen van de financiële administratie. Het kan onder andere facturen maken voor de klant. Deze facturen worden meegestuurd met de bestelling. In het programma voor de financiële administratie moet informatie worden bijgehouden die ook al in de kaartenbak wordt bijgehouden. Het zou daarom goed zijn om deze twee systemen te koppelen, of aan de kaartenbak een module toe te voegen voor het doen van de financiële administratie. Daarnaast heeft stichting Klavarskribo een website waarop het mogelijk is om muziekboeken te bestellen en door de collectie te bladeren. Ook op deze website moet veel informatie uit de kaartenbak worden ingevoerd in een aparte database. De website zou gekoppeld kunnen worden met de database van de kaartenbak. De bestellingen zouden dan ook in die database geplaatst kunnen worden waardoor de voorraad, in combinatie met een koppeling met het betaalsysteem, automatisch bijgewerkt kan worden. Ook kunnen er dan, in combinatie met de module voor financiële administratie, automatisch facturen gegenereerd worden. Met zo n systeem kunnen de medewerkers direct zien van welke boeken nieuwe exemplaren moeten worden gedrukt en welke bestellingen verzonden moeten worden. Daarnaast hoeft slechts één database onderhouden en bijgewerkt te worden, er hoeven geen facturen en catalogi meer gemaakt te worden en er kunnen verkoopstatistieken worden bijgehouden. Een laatste mogelijkheid voor de toekomst die we willen noemen is een scankassa voor de winkel van Klavarskribo. Hierdoor kan er worden 22

24 bijgehouden welke boeken verkocht zijn en dus ook van welke boeken nieuwe exemplaren afgedrukt moeten worden. Al met al zijn er dus zeer veel mogelijkheden voor de toekomst. 23

25 BIJLAGE 1: AFBEELDINGEN OUDE KAARTENBAK FIGUUR 1 Hoofdscherm met het menu onderhoud van de oude kaartenbak van Klavarskribo. FIGUUR 2 Hoofdscherm met het menu afdrukken van de oude kaartenbak van Klavarskribo.

26 FIGUUR 3A Het eerste scherm met velden waarin informatie kan worden ingevuld over een muziekboek van de oude kaartenbak. FIGUUR 3B Het tweede scherm met velden waarin informatie kan worden ingevuld over een muziekboek van de oude kaartenbak.

27 HIËRARCHIE 1 Hiërarchisch overzicht van de functionaliteit van de kaartenbak software van firma Stark op basis van de menuhiërarchie. BIJLAGE 2: FUNCTIONALITEIT OUDE KAARTENBAK 1. Kaartenbak 1.1 Onderhoud bestanden(snelbase) Onderhoud Kaartenbak Koor muziek Cursistenbestand Orgelklanken Oud schrift Afdrukken Kaartenbak Koor muziek Cursistenbestand Orgelklanken Oud schrift Lijst lay-outs Kaartenbak Koor muziek Cursistenbestand Orgelklanken Oud schrift Structuur/scherm ontwerp Terug 1.2 Mailen Adressen importeren/bundelen Verwijderen bundeletiketten Onderhoud bundeladressen Onderhoud bundelbrieven Onderhoud bundellijst Importeren externe adressen Onderhoud importwijze addressen Respons analyse 1.3 Bestandsstructuren Ontwerpen/aanpassen/verwijderen Afdrukken/opvragen Begeleid lay-out ontwerp Velden verplaatsen 1.4 Opties Tekstverwerking Datum & tijd Kalender Kleuren Informatie Printerinstellingen 1.5 Einde 2. Kaartenbak kopiëren(back-up van de database)

28 BIJLAGE 3: OPDRACHTOMSCHRIJVING AANLEIDING Stichting Klavarskribo beschikt momenteel over een programma waarin informatie over de muziekboeken die zij uitgeeft wordt opgeslagen en bijgehouden. De huidige versie is sterk verouderd (werkt enkel nog in MS-DOS met behulp van een virtuele machine). De database bestaat uit een tekstbestandje; verschillende velden zijn inconsistent gebruikt, voor sommige informatie die zou moeten worden opgeslagen in de kaartenbak is geen ruimte; verder moeten auteursrechten die moeten worden afgedragen, handmatig worden berekend. Ook ontbreekt de volgende functionaliteit: er kunnen geen catalogi gemaakt worden en het vinden van een bepaald muziekboek met bepaalde informatie is traag en zeer gelimiteerd (het is bijvoorbeeld niet mogelijk om alle boeken van een bepaalde componist te zoeken). Klavarskribo wil een nieuw programma omdat dit meer mogelijkheden voor de toekomst biedt. Voorbeelden hiervan zijn onder andere: integratie met de huidige website, minder risico van verlies van data door betere technieken en de mogelijkheid om vanuit meerdere locaties te werken. Verder wil de stichting graag dat het sneller werkt dan de huidige versie en meer overzicht biedt. DELIVERABLES Er is geen uiterste datum gesteld voor de voltooiing van het eindproduct. Daarnaast moet het een standalone applicatie worden en moet minimaal de functionaliteit van het oude programma vervangen, waarbij enkele extra informatievelden voor een muziekboek moeten kunnen worden opgeslagen. Begindatum project: Einddatum project: (hier wordt eindverslag en eindpresentatie niet onder geschaard)

29 CONTACT Begeleider(s) Klavarskribo: J.P.H. Kuiper H. Kuiper info@klavarskribo.nl Begeleider TU Delft: P. R. van Nieuwenhuizen P.R.vanNieuwenhuizen@tudelft.nl Bezoekadres stichting Klavarskribo: De Schans GT Ridderkerk

30 BIJLAGE 4: ORIËNTATIEVERSLAG INLEIDING Bij het maken van een nieuwe kaartenbak voor stichting Klavarskribo kunnen veel keuzes gemaakt worden bij het software ontwikkeltraject. Het doel van dit oriëntatieverslag is om een uiteenzetting en rechtvaardiging te geven van verschillende aspecten die bij het ontwikkelen van de software aan bod komen. Dit is gedaan door middel van het uiteenzetten van verschillende mogelijkheden voor die aspecten en de gemaakte keuzes uit die mogelijkheden. De opbouw van dit verslag is als volgt. In het tweede hoofdstuk wordt beargumenteerd wat voor soort, en welke programmeertaal het meest geschikt is voor het programmeren van de kaartenbak. Het derde hoofdstuk bespreekt de tools of patterns waarmee de user interface gemaakt kan worden. Vervolgens wordt het beheer van de database besproken in hoofdstuk 4 waarna hoofdstuk 5 besluit met de belangrijke onderdelen van het softwareontwikkelingsproces, waaronder het ontwikkelmodel dat wordt toegepast.

31 PROGRAMMEERTAAL Voor het project moeten verschillende beslissingen gemaakt worden, waaronder die van een programmeertaal. In dit hoofdstuk worden verschillende soorten programmeertalen en programmeertalen van eenzelfde soort vergeleken. Daarna wordt geconcludeerd wat de meest geschikte programmeertaal is. Deze taal zal gebruik worden bij het implementeren van de software. PARADIGMA S Om een juiste keuze voor een programmeertaal te maken, moet eerst kort uiteengezet worden wat voor soorten programmeertalen of programmeerparadigma s er zijn. Vervolgens moet er een programmeertaal gekozen worden die in ieder geval het meest geschikte paradigma gebruikt. Belangrijke paradigma s zijn de volgende: Procedureel/imperatief: beschrijft berekeningen als reeksen van statements die worden uitgevoerd en leiden tot een bepaald resultaat. Functioneel: gefocust op het retourneren van functiewaarden. Er worden, i.t.t. bij het procedurele paradigma, meestal geen tussentijdse resultaten opgeslagen. Object-georiënteerd: beschouwt de wereld als een verzameling objecten met data en manieren om die data te benaderen. Het doel is om een probleem op te delen in verschillende deelproblemen of onderdelen die gebruikt kunnen worden om het probleem op te lossen. Scripting: deze talen zijn vaak procedureel en kunnen onderdelen van object-georiënteerde talen bevatten, maar zijn geen full-fledged programmeertalen die geschikt zijn voor het ontwikkelen van grotere systemen. Daarnaast wordt de code snel onoverzichtelijk. Logisch: logische talen verschaffen de mogelijkheid om statements op te nemen zoals: gras impliceert groen. Het zijn kortweg geen talen die de computer vertellen wat er moet gebeuren, maar ze verschaffen de mogelijkheid om de computer te laten redeneren over de gevolgen van bepaalde statements. [1] Uit de beschrijvingen van bovenstaande soorten programmeertalen, volgt dat imperatieve en object-georiënteerde talen twee soorten talen zijn, die geschikt zouden zijn voor het ontwikkelen van software zoals de te ontwikkelen kaartenbak. Er moet namelijk de mogelijkheid zijn om tussentijds waardes op te slaan tijdens, voor en na berekeningen, en er moeten opdrachten gegeven worden aan de computer. Eventueel zou een taal voor één van de twee genoemde programmeerparadigma s gecombineerd kunnen worden met een taal die het functionele paradigma handhaaft. Het object georiënteerde paradigma is ontworpen om het programmeren te vereenvoudigen. Met de toenemende grootte van programma s werd de software die geschreven werd met een taal van het oudere, procedurele paradigma steeds moeilijker te debuggen. Daarnaast werd de code steeds onoverzichtelijker en werd de kans op corruptie van data veel groter. [2] Ook was onderhoud aan de

32 code moeilijk. Object georiënteerde talen zijn vervolgens hoofdzakelijk ontwikkeld ter ondersteuning van het imperatieve paradigma. [3] Een objectgeoriënteerde taal lijkt dus het beste voor dit project. Ook wordt op de TU Delft hoofdzakelijk het object-georiënteerd programmeren aangeleerd. TALEN Twee zeer bekende voornamelijk gebaseerd op het object-georiënteerde paradigma programmeertalen waar beide ontwikkelaars ervaring mee hebben zijn Java en C#. Deze talen ondersteunen naast het object georiënteerde paradigma ook het imperatieve paradigma. C# ondersteunt ook het functionele paradigma. [4] De twee programmeertalen zijn zeer geschikt voor het ontwikkelen van applicaties zoals de digitale kaartenbak. Nu volgen enkele voordelen van de twee programmeertalen t.o.v. elkaar. Naast de voordelen hebben de talen overigens wat betreft de OOP modellen zeer veel gemeen. [5] Enkele voordelen van Java ten opzichte van C# zijn: Java is platformonafhankelijk; C# applicaties kunnen wel m.b.v. andere opties zoals Mono voor Linux, gebruikt worden op een ander platform. Java heeft meer API s dan Windows voor C#; daarnaast hebben alle API s cross-platform ondersteuning. Ondersteund door veel verkopers.(c# alleen door Microsoft) In contrast zijn de voordelen van C# ten opzichte van Java: Ondersteuning van het functionele paradigma. Mogelijkheid tot het gebruik van properties; Java daarentegen, gebruikt twee functies per object (zgn. getters en setters). LINQ is geïntegreerd voor vereenvoudiging van communicatie tussen applicatie en data(base). Er is een goede object-relationeel mapping framework (ORM) beschikbaar, namelijk het ADO.NET Entity Framework (EF). C# lijkt onder Windows beter te presteren. Bij het gebruik van Mono is er weinig verschil tussen Java en C#. [6] Mogelijkheid tot het gebruik van lambda expressies. Grafische onderdelen hebben een betere performance. [7] Bij het maken van de kaartenbak is de platformonafhankelijkheid, een voordeel van Java, niet van belang aangezien alleen het platform Windows wordt gebruikt. De cross-platformondersteuning van de API s is dus ook niet van belang. Daarnaast heeft de ondersteuning door veel verkopers geen enkele functie voor de kaartenbak. Wat wel een pluspunt van Java ten opzichte van C# blijft is het aantal beschikbare API s, maar dat weegt niet op tegen de voordelen van C#. Een goede ORM is erg handig bij het maken van de database. Met behulp van LINQ kan er op eenvoudige wijze gecommuniceerd worden met de database. Ook is het erg handig dat C# het fenomeen properties kent. Properties geven de mogelijkheid om zeer beknopt en overzichtelijk velden met getters, setters en eventuele validatie te maken, in plaats van dat er verschillende functies moeten geschreven worden voor dit doeleinde. Dit resulteert in overzichtelijke code. Bij het maken van de nieuwe kaartenbaksoftware voor Klavarskribo zal daarom gebruik gemaakt worden van de programmeertaal C#.

33 GEBRUIKERSINTERFACE Er zijn twee belangrijke tools die beide veel gebruikt worden voor gebruikersinterfaces voor het.net platform. In dit hoofdstuk zullen opnieuw, zoals in het vorige hoofdstuk, de voordelen van verschillende mogelijkheden tegen elkaar worden afgewogen. Op basis daarvan zal een conclusie getrokken worden. De keuze voor de programmeertaal C# geeft twee veelgebruikte tools voor het maken van gebruikersinterfaces, namelijk: WinForms (Windows Forms) WPF (Windows Presentation Foundation) WPF is nieuwer dan WinForms. Maar dit impliceert natuurlijk niet dat het beter is en WPF is dan ook in eerste instantie niet ontwikkeld om WinForms te vervangen maar biedt andere mogelijkheden. Ondanks dat zal WPF WinForms in de nabije toekomst waarschijnlijk wel vervangen. Hieronder volgen de voordelen die een rol zouden kunnen spelen in het project, van de tools ten opzichte van elkaar: Windows Forms heeft als voordelen: Geen vereiste kennis van de programmeertaal XAML. Grotere beschikbaarheid van 3rd party controls. Meer online resources. Meer ontwikkelaars-communities. [8] Maar ten opzichte van WinForms heeft WPF als voordelen: Betere mogelijkheden voor data binding. Een betere techniek voor het omgaan met verschillende resoluties. [9] Een betere scheiding tussen C# code en de GUI logica. Virtualisatie van de user interface(resulterend in betere performance bij het laden van grote lijsten met informatie van bijvoorbeeld muziekboeken). [10] Betere mogelijkheden wat betreft het integreren van o.a. een viewer voor PDF bestanden. Een betere gebruikers- en ontwikkelervaring. [8] Uit bovenstaande voordelen blijkt dat WPF het op vele punten beter doet dan Windows Forms. De voordelen van Windows Forms komen bijna allemaal voort uit het feit dat het ouder is en er daardoor meer controls en andere aanvullingen beschikbaar voor zijn. Aangezien beide ontwikkelaars het leuk vinden om een nieuwe programmeertaal, namelijk XAML, te leren (één van de ontwikkelaars is er overigens al mee bekend) valt logischerwijs Windows Forms af en zal de gebruikersinterface van de kaartenbak ontwikkeld worden met WPF.

34 DATABASE MANAGEMENT Naast een tool voor de user interface en een programmeertaal, moet ook een keuze gemaakt worden voor het database management systeem. Dit hoofdstuk beschrijft waarom in ieder geval voorlopig MySQL gebruikt zal worden. Er zijn drie veelgebruikte (R)DMBS s, namelijk Microsoft SQL Server, Oracle en MySQL. MySQL is tegenwoordig onderdeel van Oracle, maar benadert een andere groep van database gebruikers. [11] De belangrijkste redenen voor het gebruik van MySQL zijn: Het is gratis; een Microsoft SQL Server database, bijvoorbeeld, is te duur voor de stichting. De betaalde webhost die Klavarskribo momenteel gebruikt biedt alleen de mogelijkheid tot hosten van MySQL databases. Er kan automatisch een DDL script voor een MySQL database (hetgeen ook kan voor een Microsoft SQL Server database) gegenereerd worden m.b.v. Visual Studio 2010 en Connector/NET. De ontwikkelaars hebben ervaring met MySQL databases. Er is sprake van goede integratie met het ADO.NET Entity Framework. Zoals gezegd moet voor het gebruik van Oracle en Microsoft SQL Server beide betaald worden. Mocht Klavarskribo de mogelijkheid hebben tot bijvoorbeeld het hosten van een Microsoft SQL Server database, dan kan op zeer eenvoudige wijze hierop worden overgegaan door het generen van een DDL script dat een beschrijving geeft van de structuur van de database. Als dataprovider zal Connector/NET, de standaard (native).net data provider voor MySQL, gebruikt worden. De reden dat er geen ODBC(Open DataBase Connectivity) wordt gebruikt is de minder goede integratie met het.net framework. ODBC heeft o.a. t.o.v. de standaard dataprovider lagere prestaties. [12] [13] MySQL biedt verschillende mogelijkheden wat betreft de opslag-engines. InnoDB is het standaardtype naast het belangrijke MyISAM. In tegenstelling tot verschillende andere opslag-engines, waaronder MyISAM, is InnoDB transactioneel, ondersteunt het gebruik van foreign keys en is fail-safe. Echter verbruikt MyISAM minder resources, heeft een zeer hoge leessnelheid en maakt het eenvoudiger om data modellen te ontwikkelen. [14] [15] Overigens levert InnoDB toch zeer goede prestaties t.o.v. MyISAM. [16] Het is voor de kaartenbak van Klavarskribo belangrijk dat de data zeer betrouwbaar is en in geval van fouten consistent blijft. Daarnaast resulteert de mogelijke koppeling van de website aan de database waarschijnlijk in gelijktijdige operaties van de kaartenbak en de website op de database. Database transacties zorgen voor een isolatie van de beide operaties onderling. Uit deze belangen van Klavarskribo volgt de keuze voor het opslag-engine InnoDB. Voor het benaderen van de data in de database zal het eerdergenoemde ADO.NET Entity Framework worden gebruikt. De structuur van dit framework is in schematische vorm weergegeven in figuur 1.

35 FIGUUR 1 Schematische weergave van ADO.NET Entity Ten opzichte van andere technologieën, vereenvoudigt deze relatief nieuwe technologie het communiceren met de database vanuit de applicatie. In plaats van dat er SQL queries moeten worden geschreven, kan bij het gebruik van het ADO.NET Entity Framework gebruik gemaakt worden van LINQ(Language- Integrated Query)-to-Entities voor het manipuleren van de data, zoals weergegeven in de bovenste laag van het schema van figuur 1. Hiermee kunnen queries geschreven worden tegen het conceptuele(conceptual) model. Dit model kan worden weergegeven door een EDM(Entity Data Model) met behulp van een Entity Designer waarmee de database automatisch gegenereerd kan worden en data entiteiten worden vertaald naar standaard.net objecten(het blauwe gedeelte van figuur 1). [17]

36 SOFTWAREONTWIKKELPROCES Aangezien stichting Klavarskribo zich niet bezighoudt met de ontwikkeling van software, mogen de ontwikkelaars zelf keuzes maken wat betreft alle aspecten van het softwareontwikkelproces. Dit hoofdstuk beschrijft de belangrijke keuzes die gemaakt zijn en geeft daar een korte rechtvaardiging van. ONTWIKKELMODEL Het ontwikkelmodel wat zal worden gebruikt bij het ontwikkelen van de software is het V-model. De opzet van dit model is weergegeven in figuur 2. FIGUUR 2 Het V-model van het systeemontwikkelingsproces. Voor dit ontwikkelmodel is gekozen omdat het een onder andere een uitgebreide testfase kent waarbij er ook ruimte is voor verificatie en validatie. Dat zal gebruikt worden voor o.a. het verifiëren van de compleetheid van de informatievelden die kunnen worden ingevuld, over een boek. Daarnaast lopen de ontwikkelstappen geleidelijk in elkaar over. Hierdoor kan één van de softwareontwikkelaars de requirements afmaken, terwijl de ander begint met het gedetailleerde ontwerp. Daarnaast is er afgesproken met de opdrachtgever dat er tijdens de implementatie al een versie opgeleverd zal worden om uit te proberen; dit is mogelijk als van dit ontwikkelmodel wordt uitgegaan omdat integratie, test en verificatie gedeeltelijk samenvallen of in elkaar overvloeien. Er zijn verschillende andere ontwikkelmodellen overwogen. Er zullen er hier twee genoemd worden. Het waterval-model bijvoorbeeld, is niet geschikt voor dit project omdat de fases volledig voltooid moeten zijn voordat aan een nieuwe fase wordt begonnen. Het iteratieve- of incrementele ontwikkelingsmodel leek in eerste instantie ook goed toepasbaar te zijn. Dit ontwikkelmodel is een verbetering op het watervalmodel en biedt de mogelijkheid tot het simultaan uitvoeren van verschillende ontwikkelfases van de software. Dit model is zeer geschikt voor grotere projecten waarbij verschillende specialisten voor de verschillende fases worden gebruikt. Maar aangezien het te ontwikkelen systeem voor Klavarskribo niet zo groot is en slechts twee personen aan het project werken, lijkt het verstandiger om fases zoveel mogelijk af te ronden.

37 MODELLEERTAAL Als modelleertaal zal voornamelijk UML 2.1 gebruikt worden. Deze modelleertaal wordt veel op de TU gebruikt en de studenten moeten deze taal leren. Hieruit volgt logischerwijs dat de ontwikkelaars enige ervaring met UML hebben. TOOLS VISUAL STUDIO 2010 Visual Studio 2010 is de meest geschikte ontwikkeltool voor de kaartenbak. Visual Studio bevat onder andere de volgende onderdelen die tot die keuze leidden: Een test suite voor het maken en uitvoeren van o.a. unit tests. Een designer voor de WPF gebruikersinterface. Een designer voor de database(entity Data Modellen). Mogelijkheid tot het automatisch genereren van een script voor de database. Tools om UML diagrammen te maken. IntelliSense. Daarnaast zijn de ontwikkelaars gewend met Visual Studio te werken en hebben er goede ervaringen mee. Ook zijn er ontzettend veel plugins beschikbaar om prettiger te kunnen werken en de productiviteit te verhogen. Een van de plugins die zal worden gebruikt AnkSVN voor ondersteuning van SVN in Visual Studio. APACHE SUBVERSION(SVN) Subversion is een veelgebruikt softwareversie en revisiebeheersysteem. [18] Het zal tijdens het project gebruikt worden voor alle documenten en code. Voordelen hiervan zijn: - Een oudere versie van de code en van een document is eenvoudig terug te vinden. - Het is eenvoudig om code te vergelijken na wijzigingen. - Op de TU Delft is een cliënt, namelijk TortoiseSVN aanwezig op de computers. - Op de TU Delft kan er gratis een repository worden aangemaakt die ook vanuit thuis te benaderen is. ITEXTSHARP ITextSharp is een product van IText voor het maken van PDF bestanden vanuit C# code. Dit zal gebruikt worden voor het maken en wijzigen van PDF bestanden van de verkoopoverzichten met daarop de boeken waarover Klavarskribo auteursrechten moet afdragen. Natuurlijk zijn er nog veel meer

38 tools en libraries die deze functionaliteit bevatten, maar ITextSharp is gratis en open source, en is ver ontwikkeld. [19] BIBLIOGRAFIE 1. Eric Suh with large additions by the webmaster. The Tower of Babel. [Online] Gebaseerd op een article van de 'Code Journal' Pagewise. Object paradigm vs. procedural paradigm. essortment. [Online] Microsoft. Functional Programming vs. Imperative Programming. MSDN Library. [Online] 4. Comparison of programming languages. Wikipedia. [Online] 5. Jawahar Puvvala, Alok Pota. NET for Java developers migrating to C#. Boston : Pearson Education, Inc, Warren, Matt R. C# versus C++ versus Java performance comparison. [Online] [Cited: ] 7. Tummy. Java vs C#/.NET. Veridicus. [Online] 8. Smith, Josh. WPF vs. Windows Forms. Josh Smith On WPF. [Online] [Cited: ] 9. Simser, Bil. WPF or WinForms, choose wisely. ASP.NET weblog/general Software Development. [Online] [Cited: ] Davey, M. WPF vs Windows Forms. Wordpress. [Online] [Cited: ] Messages from Oracle OpenWorld 2010: Exadata Exceeds Expectation and MySQL Thrives. Olofson, Carl W. Framingham : IDC, 2010, Vol Performance Benchmarks For ODBC Vs. Oracle, MySql, SQL Server.NET Providers. DevToolShed. [Online] [Cited: ] MySQL Connector/NET. MySQL. [Online] [Cited: ] Yang, Yang. MySQL Engines: InnoDB vs. MyISAM A Comparison of Pros and Cons. Kaivor. [Online] [Cited: ]

39 15. Sanders Kaufman, Jr. A fast and furious guide to MySQL database engines. TechRepublic. [Online] [Cited: ] Vadim. InnoDB vs MyISAM vs Falcon benchmarks. MySQL Performance Blog. [Online] [Cited: ] The ADO.NET Entity Framework. MSDN. [Online] [Cited: ] Wikipedia. Apache Subversion. Wikipedia. [Online] [Cited: ] IText. [Online]

40 BIJLAGE 5: REQUIREMENTS DOCUMENT 1. INLEIDING Stichting Klavarskribo beschikt momenteel over een applicatie om de informatie van de muziekboeken die zij bezit op te slaan. Ook wordt hiermee het bijhouden van af te dragen rechten aan de uitgevers gedaan. Helaas ontbreken vele functies, en draait het programma enkel op het oude besturingssysteem MS- DOS. Klavarskribo heeft daarom gevraagd of er een nieuw systeem ontwikkeld kan worden. Het doel van dit document is om de eisen aan het vervangende systeem te presenteren. Door het inventariseren van de actoren en de use cases komen de eisen aan het licht. Zowel voor de ontwerper als voor de opdrachtgever is het de moeite waard om dit document te lezen. De opbouw is als volgt. Het begint met een korte beschrijving van de gebruikte methodiek. Hoofdstuk 3 bevat een korte beschrijving van de context van het project. Daarna, in hoofdstuk 4, worden de use cases gespecificeerd. Vervolgens worden in hoofdstuk 5 de eisen aan het nieuwe systeem gepresenteerd verdeeld over verschillende aspecten die van belang zijn. Met behulp van dit document wordt er een ontwerp gemaakt van de te realiseren applicatie. Omdat sommige aspecten van het ontwerp al worden bepaald door de requirements, kan er in hoofdstuk 6 al een schets gegeven worden van enkele onderdelen van het ontwerp. Tot slot is er, in hoofdstuk 7, een verklarende woordenlijst opgenomen die de technische termen beschrijft.

41 2. METHODIEK In de eerste fase zijn er gesprekken gevoerd met de contactpersoon bij de stichting Klavarskribo, om een globaal beeld te krijgen van de actoren, use cases en verwachtingen. Aan de hand van deze gegevens en de verkregen informatie over het oude programma zijn de primaire use cases vastgesteld. Na het gesprek zijn de use cases geheel uitgewerkt om een compleet beeld te krijgen van de samenhang tussen de verschillende aspecten van de applicatie. Uit deze use cases en besproken eisen volgen de functionele requirements. In de tweede fase is aan de hand van de vragen rondom de use cases een tweede gesprek gevoerd met de contactpersoon bij de stichting. Aan de hand van een aantal punten van verschillende aspecten, zoals veiligheid en usability, zijn er voornamelijk niet functionele eisen verkregen. Dit heeft geleid tot een revisie van de use cases en bijwerking van de requirements. Hoewel er natuurlijk vooraf geprobeerd wordt om zoveel mogelijk requirements boven tafel te krijgen en te specificeren, is het zeer waarschijnlijk dat er tijdens de implementatiefase eisen bij komen of dat een of meerdere eisen worden aangepast. In dat geval zal er duidelijk onderbouwd moeten worden waarom die requirements veranderen. Die wijzigingen worden doorgevoerd in dit document en de ontwerp documenten.

42 3. CONTEXT In de elektronische kaartenbak wordt allerlei informatie bijgehouden over de muziekboeken die Klavarskribo bezit. Er kan in deze kaartenbak gezocht worden naar een specifiek boek, informatie kan worden aangepast, er kan een nieuw boek worden aangemaakt en er kunnen rapporten gemaakt worden voor de uitgeverijen van de boeken met daarop een overzicht van gedrukte aantallen per boek. Die rapporten worden opgestuurd, en in reactie daarop sturen de uitgevers een rekening. In de oude kaartenbak kan op een kaart niet alle vereiste informatie over een muziekboek op gestructureerde wijze opgeslagen worden. Er moeten dus nieuwe velden waarin voor informatie kan worden ingevuld, gemaakt worden. Ook moeten er beperkingen gesteld worden aan de informatie die in een bepaald veld ingevuld kan worden. Hierdoor wordt de mogelijkheid gecreëerd om een goede koppeling te maken tussen de kaartenbak, de website en het boekhoudprogramma. Ook beschikt Klavarskribo over catalogi voor verschillende instrumenten in verschillende bestanden, gescheiden van de kaartenbak. Daarnaast is er ook een aparte database voor de website waarop boeken kunnen worden besteld. Het komt dus voor dat in drie verschillende systemen data moet worden aangepast bij het wijzigen van informatie over een boek.

43 4. USE CASES Bij en na de gesprekken met stichting Klavarskribo zijn de volgende use cases gedefinieerd: UC-M: Muziekboeken o UC-M-Z: Muziekboek Zoeken o UC-M-W: Muziekboek Wijzigen o UC-M-A: Muziekboek Aanmaken o UC-M-V: Muziekboek Verwijderen o UC-M-P: Muziekboek Afdrukken UC-C: Musici (Componist / Arrangeur) o UC-C-Z: Musicus Zoeken o UC-C-W: Musicus Wijzigen o UC-C-A: Musicus Aanmaken o UC-C-V: Musicus Verwijderen UC-U: Uitgever o UC-U-Z: Uitgever Zoeken o UC-U-W: Uitgever Wijzigen o UC-U-A: Uitgever Aanmaken o UC-U-V: Uitgever Verwijderen UC-R: Reporting o UC-R-CA: Catalogus Afdrukken o UC-R-NV: Lijst niet voorradig, het betreft hier boeken die nog wel verkocht worden maar niet meer op voorraad zijn. o UC-R-AR: Verkoopoverzicht maken o UC-R-AR: Weergeven van een lijst met alle verkoopoverzichten o UC-R-AA: Verkoopoverzichten afdrukken o UC-R-AI: Verkoopoverzicht inzien o UC-R-AB: Verkoopoverzicht betalen o UC-R-AV: Verkoopoverzicht verwijderen UC-B: Beheer o UC-B-BU: Back-up maken. o UC-B-BR: Back-up terugzetten.

44 De relatie van deze use cases kan globaal met het volgende schema worden weergegeven. Bij Klavarskribo is de gebruiker ook altijd de beheerder. Dit komt overeen met het eenvoudige karakter van de bedrijfsprocessen bij Stichting Klavarskribo. Voor de applicatie betekent dit dat er geen eisen zijn aan wie wat mag doen, en dat er geen gebruikersauthenticatiesysteem nodig is. Aan het einde van de eerste fase zijn de use cases in detail uitgewerkt. In het use case model wordt een gedetailleerder beeld gegeven van alle handelingen die moeten worden ondersteund, wat het doel is van die handelingen, aan welke condities moet worden voldaan, e.a. De uitwerking hiervan is bedoeld om een duidelijk beeld te geven van de vereiste functies en de handelingen van de gebruiker en de reacties van het systeem daarop. De use cases moeten in dit licht dan ook gezien worden als eisen aan de applicatie net als de requirements. Deze uitwerkingen van use cases kunnen worden gebruikt als basis voor het ontwerp van de gebruikersinterface, een gebruikersinterfacetest en de gebruikers documentatie.

45 USE CASES UC-M: MUZIEKBOEKEN USE CASE UC-M-Z: MUZIEKBOEK ZOEKEN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Muziekboek zoeken UC-M-Z Het opzoeken van een specifiek muziekboek Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. Het gezochte muziekboek bestaat in de database 1. Gebruiker selecteert een tekstvak onder het kopje 'Zoeken'. Systeem verzet focus naar tekstvak. 2. Gebruiker typt een deel van het zoekattribuut. Systeem zoekt op elke toetsaanslag mee naar resultaten en toont deze onder Zoekresultaten 3. Gebruiker klikt op het gezochte muziekboek. Systeem opent de detailweergave van het muziekboek. 1. Het gezochte muziekboek is geopend in de detailweergave. Opmerkingen Deze use case komt voor als onderdeel van andere use cases. USE CASE UC-M-W: MUZIEKBOEK WIJZIGEN Naam Identificatie Omschrijving Actor Muziekboek wijzigen UC-M-W Aanpassen van een van de eigenschappen van een muziekboek Medewerker Precondities 1. Applicatie is gestart en focus is op het hoofdscherm 2. Het te wijzigen muziekboek bestaat Acties 1. Gebruiker zoekt het te wijzigen muziekboek op middels use case UC-M-Z Systeem toont detailweergave van het muziekboek 2. Gebruiker maakt aanpassingen en zorgt dat tenminste de volgende velden zijn ingevuld: a. Titel b. Componist(en) c. Instrument(en) d. Opnemen in catalogus e. Auteursrecht geregeld f. Uitgever klavarnotatie

46 Postcondities: Systeem markeert eventuele (validatie) fouten tijdens het invoerproces Systeem markeert de detailweergave als bewerkt in de header 3. Gebruiker klikt op de knop 'Opslaan' Systeem verwerkt de wijzigingen Systeem verwijdert de markering bewerkt in de header 1. De gewijzigde gegevens zijn opgeslagen in de database. 2. Bij een fout is de gebruiker erop geattendeerd dat zijn wijzigingen niet zijn doorgevoerd. Bevat use cases: 1. UC-M-Z Opmerkingen Ook als de gebruiker de procedure afbreekt zonder op te slaan moet hij geattendeerd worden op het mogelijk onbedoelde verlies van gegevens. USE CASE UC-M-A: MUZIEKBOEK AANMAKEN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Muziekboek aanmaken UC-M-A Een nieuw muziekboek aanmaken in de applicatie Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm. 2. Het in te voeren muziekboek bestaat niet in het systeem. 1. Gebruiker klikt op de knop nieuw muziekboek Systeem toont een lege muziekboekdetailweergave 2. Gebruiker voert het nieuwe muziekboek in en zorgt dat tenminste de volgende velden zijn ingevuld: a. Titel b. Componist(en) c. Instrument(en) d. Opnemen in catalogus e. Auteursrecht geregeld f. Uitgever klavarnotatie Systeem markeert eventuele (validatie) fouten tijdens het invoerproces Systeem markeert de detailweergave als bewerkt in de header 3. Gebruiker klikt op de knop 'Opslaan' Systeem verwerkt de wijzigingen Systeem verwijdert de markering bewerkt in de header 1. Het nieuwe muziekboek is opgeslagen in de database 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd

47 Opmerkingen Ook als de gebruiker de procedure afbreekt zonder op te slaan moet hij geattendeerd worden op het mogelijk onbedoelde verlies van gegevens. USE CASE UC-M-V: MUZIEKBOEK VERWIJDEREN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Muziekboek verwijderen UC-M-V Herstellen van foutief aangemaakt muziekboek Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. Het te verwijderen muziekboek bestaat 3. Het te verwijderen muziekboek heeft geen relaties in de database 1. Gebruiker zoekt het te verwijderen muziekboek op middels use case UC-M-Z Systeem toont detailweergave van het muziekboek 2. Gebruiker klikt op de knop 'Verwijderen' Systeem verwijdert het muziekboek uit het systeem en sluit de detailweergave 1. Het muziekboek bestaat niet meer in het systeem 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd Bevat use cases: 1. UC-M-Z Opmerkingen Verwijderen kan alleen als er geen verwijzingen naar het boek zijn in de database, anders zouden er gegevens (bijvoorbeeld over auteursrechten), onbedoeld, ook verwijderd worden. USE CASE UC-M-P: MUZIEKBOEK AFDRUKKEN Naam Identificatie Omschrijving Actor Precondities Acties Muziekboek afdrukken UC-M-P Een of meerdere malen afdrukken van een muziekboek. Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. Het te wijzigen muziekboek bestaat

48 Postcondities Bevat use cases 1. Gebruiker zoekt het af te drukken muziekboek op middels use case UC-M-Z Systeem toont detailweergave van het muziekboek 2. Gebruiker klikt op tabblad Overig Systeem toont de inhoud van tabblad Overig 3. Gebruiker zoekt het pdf-bestand van het muziekboek in de lijst van bestanden 4. Gebruiker dubbelklikt op het pdf bestand Systeem toont de inhoud van het PDF bestand 5. Gebruiker klikt op de knop of menu item 'Print' Systeem toont een dialoog voor de print instellingen 6. Gebruiker geeft op hoeveel kopieën er afgedrukt moeten worden 7. Gebruiker drukt op Afdrukken Systeem drukt gewenst aantal kopieën af en boekt een afdracht van auteurs rechten voor dit muziekboek. 1. Het muziekboek is afgedrukt 1. UC-M-Z USE CASES UC-C: MUSICI (COMPONISTEN/ARRANGEURS) USE CASE UC-C-Z: MUSICUS ZOEKEN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Musicus zoeken UC-C-Z Het opzoeken van een specifieke musicus Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. De gezochte musicus bestaat in de database 1. Gebruiker klikt op het menu item Beheren Systeem opent het beheerscherm voor musici 2. Gebruiker selecteert het tekst vak 'Musicus' Systeem verzet focus naar tekst vak 3. Gebruiker typt (een deel van) de naam van de musicus Systeem zoekt op elke toetsaanslag mee naar resultaten en toont deze 4. Gebruiker selecteert de gezochte musicus Systeem opent de detailweergave van de musicus 1. De gezochte musicus is geopend in de detailweergave

49 Opmerkingen Deze use case komt voor als onderdeel van andere use cases. USE CASE UC-C-W: MUSICUS WIJZIGEN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Musicus wijzigen UC-C-W Aanpassen van een van de eigenschappen van een musicus Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. De te wijzigen musicus bestaat 1. Gebruiker zoekt de te wijzigen musicus op middels use case UC- C-Z Systeem toont detailweergave van de musicus 2. Gebruiker maakt aanpassingen en zorgt dat tenminste de volgende velden zijn ingevuld: a. Voornaam of initialen b. Achternaam Systeem markeert eventuele (validatie) fouten tijdens het invoerproces Systeem markeert de detailweergave als bewerkt in de header 3. Gebruiker klikt op de knop 'Opslaan' Systeem verwerkt de wijzigingen Systeem verwijdert de markering bewerkt in de header 1. De gewijzigde gegevens zijn opgeslagen in de database. 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd. Bevat use cases: 1. UC-C-Z Opmerkingen Ook als de gebruiker de procedure afbreekt zonder op te slaan moet hij geattendeerd worden op het mogelijk onbedoelde verlies van gegevens. USE CASE UC-C-A: MUSICUS AANMAKEN Naam Musicus aanmaken Identificatie UC-C-A Omschrijving Een nieuwe musicus aanmaken in de applicatie Actor Medewerker Precondities

50 Acties Postcondities 1. Applicatie is gestart en focus is op het hoofdscherm 2. De in te voeren musicus bestaat niet in het systeem 1. Gebruiker klikt op de knop Musici beheren Systeem opent het beheerscherm voor musici 2. Gebruiker klikt op de knop Nieuw musicus Systeem toont een lege musicusdetailweergave 3. Gebruiker voert de nieuwe musicus in en zorgt dat tenminste de volgende velden zijn ingevuld: a. Voornaam of initialen b. Achternaam Systeem markeert eventuele (validatie) fouten tijdens het invoerproces Systeem markeert de detailweergave als bewerkt in de header 4. Gebruiker klikt op de knop 'Opslaan' Systeem verwerkt de wijzigingen Systeem verwijdert de markering bewerkt in de header 1. De nieuwe musicus is opgeslagen in de database 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd Opmerkingen Ook als de gebruiker de procedure afbreekt zonder op te slaan moet hij geattendeerd worden op het mogelijk onbedoelde verlies van gegevens. USE CASE UC-C-V: MUSICUS VERWIJDEREN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Musicus verwijderen UC-C-V Herstellen van foutief aangemaakte musicus Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. De musicus heeft geen relaties in de database 3. De te verwijderen musicus bestaat 1. Gebruiker zoekt de te verwijderen musicus op middels use case UC-C-Z Systeem toont detailweergave van de musicus 2. Gebruiker klikt op de knop 'Verwijderen' Systeem verwijdert de musicus uit het systeem en sluit de detailweergave 1. De musicus bestaat niet meer in het systeem

51 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd Bevat use cases: 1. UC-C-Z USE CASES UC-U: UITGEVERS USE CASE UC-U-Z: UITGEVER ZOEKEN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Uitgever zoeken UC-U-Z Het opzoeken van een specifiek uitgever Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. De gezochte uitgever bestaat in de database 1. Gebruiker klikt op het menu item Beheren Systeem opent het beheerscherm voor uitgevers 2. Gebruiker selecteert het tekst vak Uitgever' Systeem verzet focus naar tekst vak 3. Gebruiker typt (een deel van) de naam van de uitgever Systeem zoekt op elke toetsaanslag mee naar resultaten en toont deze 4. Gebruiker selecteert de gezochte uitgever Systeem opent de detailweergave van de musicus 1. De gezochte uitgever is geopend in de detailweergave Opmerkingen Deze use case komt voor als onderdeel van andere use cases. USE CASE UC-U-W: UITGEVER WIJZIGEN Naam Identificatie Omschrijving Actor Precondities Acties Uitgever wijzigen UC-U-W Aanpassen van een van de eigenschappen van een uitgever Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. De te wijzigen uitgever bestaat

52 Postcondities 1. Gebruiker zoekt de te wijzigen uitgever op middels use case UC- U-Z Systeem toont detailweergave van de uitgever 2. Gebruiker maakt aanpassingen en zorgt dat tenminste de volgende velden zijn ingevuld: a. Naam Systeem markeert eventuele (validatie) fouten tijdens het invoerproces Systeem markeert de detailweergave als bewerkt in de header 3. Gebruiker klikt op de knop 'Opslaan' Systeem verwerkt de wijzigingen Systeem verwijdert de markering bewerkt in de header 1. De gewijzigde gegevens zijn opgeslagen in de database 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd Bevat use cases: 1. UC-U-Z Opmerkingen Ook als de gebruiker de procedure afbreekt zonder op te slaan moet hij geattendeerd worden op het mogelijk onbedoelde verlies van gegevens. USE CASE UC-U-A: UITGEVER AANMAKEN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Uitgever aanmaken UC-U-A Een nieuwe uitgever aanmaken in de applicatie Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. De in te voeren uitgever bestaat niet in het systeem 1. Gebruiker klikt op het menu item Beheren Systeem opent het beheerscherm voor uitgevers 2. Gebruiker klikt op de knop Nieuwe uitgever Systeem toont een lege uitgeverdetailweergave 3. Gebruiker voert de nieuwe uitgever in en zorgt dat tenminste de volgende velden zijn ingevuld: a. Naam Systeem markeert eventuele (validatie) fouten tijdens het invoerproces Systeem markeert de detailweergave als bewerkt in de header 4. Gebruiker klikt op de knop 'Opslaan' Systeem verwerkt de wijzigingen Systeem verwijdert de markering bewerkt in de header

53 1. De nieuwe uitgever is opgeslagen in de database 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd. Opmerkingen Ook als de gebruiker de procedure afbreekt zonder op te slaan moet hij geattendeerd worden op het mogelijk onbedoelde verlies van gegevens. USE CASE UC-U-V: UITGEVER VERWIJDEREN Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Uitgever verwijderen UC-U-V Herstellen van foutief aangemaakte uitgever Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm. 2. De te verwijderen uitgever heeft geen relaties in de database. 3. De te verwijderen uitgever bestaat. 1. Gebruiker zoekt de te verwijderen uitgever op middels use case UC-U-Z Systeem toont detailweergave van de uitgever 2. Gebruiker klikt op de knop 'Verwijderen' Systeem verwijdert de uitgever uit het systeem en sluit de detailweergave 1. De uitgever bestaat niet meer in het systeem. 2. Bij een fout is de gebruiker er op geattendeerd dat zijn wijzigingen niet zijn doorgevoerd. Bevat use cases: 1. UC-U-Z Opmerkingen Verwijderen kan alleen als er geen verwijzingen naar de uitgever zijn in de database, anders zouden er gegevens (bijvoorbeeld over auteursrechten) onbedoeld ook verwijderd worden.

54 USE CASES UC-R: REPORTING USE CASE UC-R-CA: CATALOGUS AFDRUKKEN Naam Catalogus afdrukken Identificatie Omschrijving Actor Precondities UC-K-P Een of meerdere malen maken en afdrukken van een catalogus. Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. De af te drukken catalogus bestaat Acties 1. Gebruiker klikt op het menu item Rapporteren Systeem toont de rapporten weer die gemaakt kunnen worden 2. Gebruiker klikt op het submenu item Catalogi Systeem toont het scherm waarop catalogi gemaakt kunnen worden 3. Gebruiker selecteert het type catalogus dat hij wil maken Systeem toont een selectie van de boeken die in deze catalogus staan 4. Gebruiker selecteert de boeken waarvan hij wil dat deze in de catalogus staan 5. Gebruiker klikt op de knop of menu item 'Afdrukken' Systeem toont een dialoog voor de print instellingen 6. Gebruiker geeft op hoeveel kopieën er afgedrukt moeten worden 7. Gebruiker drukt op Print Systeem drukt gewenst aantal kopieën af Systeem slaat de gemaakte catalogus op als pdf-bestand Postcondities Bevat use cases 1. De catalogus is afgedrukt en opgeslagen als pdf-bestand 1. UC-K-Z USE CASE UC-R-NV: LIJST INZIEN VAN MUZIEKBOEKEN DIE WORDEN VERKOCHT MAAR NIET OP VOORRAAD ZIJN Naam Identificatie Omschrijving Actor Precondities Acties Lijst 'niet voorradig' inzien UC-R-NV Om te kunnen zien welke boeken uitverkocht zijn en wellicht moeten worden bij gedrukt is het handig om een lijst in te kunnen zien, die aangeeft welke boeken voor verkoop er niet meer voorradig zijn. Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm.

55 Postcondities 1. Gebruiker drukt op menu item 'Rapport' Systeem toont menu Rapport 2. Gebruiker selecteert menu item 'Lijst niet voorradig' Systeem toont lijst van niet voorradige muziekboeken 1. De applicatie heeft een lijst getoond van alle niet voorradige boeken die nog verkocht worden. USE CASE UC-R-AR: VERKOOPOVERZICHT MAKEN Naam Identificatie Omschrijving Actor Precondities Overzicht van te betalen auteursrechten maken UC-R-AR Om auteursrechten te betalen moet er een overzicht zijn van alle verkochte boeken per uitgever per periode. Deze use case beschrijft het maken van die lijst. Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm. Acties Postcondities 1. Gebruiker klikt op het menu item Rapporteren Systeem toont de rapporten weer die gemaakt kunnen worden 2. Gebruiker klikt op het submenu item Overzichten auteursrechten Systeem toont het scherm waarop lijsten van af te dragen auteursrechten gemaakt kunnen worden 3. Gebruiker zoekt de uitgever door in het tekstvak Uitgever een gedeelte van de naam van de uitgever te typen, en uit de lijst te selecteren Systeem toon een selectie van de boeken van deze uitgever 3. Gebruiker maakt een selectie van de boeken waarover hij auteursrechten wil afdragen 4. Gebruiker klikt op de knop of menu item 'Opslaan' Systeem slaat de selectie van af te dragen auteursrechten op 1. De applicatie heeft de selectie van af te dragen auteursrechten voor de geselecteerde uitgever opgeslagen in een verkoopoverzicht. USE CASE UC-R-AW: WEERGEVEN VAN VERKOOPOVERZICHTEN Naam Identificatie Weergeven van de verkoopoverzichten die gemaakt zijn UC-R-AW Omschrijving De lijst met verschillende verkoopoverzichten moet weergegeven kunnen worden om deze te kunnen verwijderen, af te drukken en te wijzigen; ook moet hun status bekeken kunnen worden

56 Actor Precondities en datum waarop ze gemaakt zijn kunnen worden bekeken Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm Acties Postcondities 1. Gebruiker drukt op menu item 'Rapport' Systeem toont menu Rapport 2. Gebruiker selecteert menu item 'Auteursrechten verwerken' Systeem toont een overzicht van alle overzichten die gemaakt zijn m.b.v. use case UC-R-AR Bevat use cases: 1. De lijst van alle verkoopoverzichten wordt weergegeven 1. UC-U-AW Opmerkingen Deze use case vormt de basis voor enkele andere use cases USE CASE UC-R-AA: VERKOOPOVERZICHT AFDRUKKEN Naam Identificatie Actor Precondities Acties Postcondities Afdrukken van een verkoopoverzichten UC-R-AW Omschrijving Verkoopoverzichten moeten verzonden worden naar de uitgever; daarvoor moeten ze afgedrukt worden Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 1. Gebruiker voert use case UC-R-AW uit 2. Gebruiker klikt op de knop afdrukken bij het verkoopoverzicht dat hij wil afdrukken Systeem toont een dialoog voor de print instellingen 3. Gebruiker geeft op hoeveel kopieën er afgedrukt moeten worden 4. Gebruiker drukt op Print Systeem drukt gewenst aantal kopieën af Bevat use cases: 1. Het gewenste verkoopoverzicht is afgedrukt 1. UC-U-AW

57 USE CASE UC-R-AI: VERKOOPOVERZICHT INZIEN Naam Identificatie Actor Precondities Acties Inzien van de inhoud van een verkoopoverzicht UC-R-AW Omschrijving Verkoopoverzichten moeten soms gecontroleerd worden op correctheid, en er moet gekeken kunnen worden de de inhoud van het overzicht is Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 1. Gebruiker voert use case UC-R-AW uit 2. Gebruiker selecteert het gewenste verkoopoverzicht Systeem toont de details van het verkoopoverzicht Bevat use cases: Postcondities 1. UC-U-AW 1. De inhoud van een verkoopoverzicht wordt weergegeven USE CASE UC-R-AB: VERKOOPOVERZICHT BETALEN Naam Identificatie Actor Precondities Acties Postcondities Overzicht van te betalen auteursrechten verwerken UC-R-AB Omschrijving Na het uitbetalen de factuur die in reactie op het overzicht van te betalen auteursrechten wordt gestuurd, moet de gebruiker registreren dat dit gebeurd is zodat de status van betaling van auteursrechten over de muziekboeken bijgewerkt kan worden tot de aanmaakdatum van het verkoopoverzicht. Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 1. Gebruiker voert use case UC-R-AW uit 2. Gebruiker klikt op Betaald bij een overzicht Systeem werkt de laatste datum van auteursrechtenafdracht van de muziekboeken op het verkoopoverzicht bij 1. De auteursrechten zijn betaald en de registratie bijgewerkt

58 Opmerkingen Het is mogelijk dat er besloten word om bepaalde muziekboeken niet in een verkoop overzicht op te nemen, omdat deze incorrect is, of omdat de uitgever aangeeft dat het bedrag zo laag is dat er bij de volgende periode mag worden geboekt. In dat geval moet het verkoopoverzicht worden verwijderd en moet er middels use case UC-R-AR een nieuw verkoopoverzicht gemaakt worden. USE CASE UC-R-AV: VERKOOPOVERZICHT VERWIJDEREN Naam Identificatie Actor Precondities Acties Verwijderen van een eerder gemaakt verkoopoverzicht UC-R-AW Omschrijving Verkoopoverzichten moeten soms verwijdert worden als ze incorrect zijn, of als ze niet meer bekeken hoeven te worden Medewerker 1. Applicatie is gestart en focus is op het hoofdscherm 2. Het verkoopoverzicht bestaat in het systeem 1. Gebruiker voert use case UC-R-AW uit 2. Gebruiker klikt op de knop verwijderen bij het verkoopoverzicht dat hij wil verwijderen Systeem toont een dialoog met daarin een vraag om bevestiging van het verwijderen 3. Gebruiker bevestigd dat het verkoopoverzicht verwijderd moet worden Systeem verwijdert het verkoopoverzicht Bevat use cases: Postcondities 1. UC-U-AW 1. Het verkoopoverzicht is verwijderd uit het systeem 2. De lijst van alle verkoopoverzichten wordt weergegeven USE CASES UC-B: BEHEER USE CASE UC-B-BU: BACK-UP MAKEN Naam Identificatie Omschrijving Back-up maken UC-B-BU Voor de zekerheid wil de beheerder naast de nachtelijke back-up een handmatige back-up kunnen maken.

59 Actor Precondities Beheerder 1. Applicatie is gestart en focus is op het hoofdscherm Acties Postcondities 1. Gebruiker drukt op menu item 'Beheer' Systeem toont menu Beheer 2. Gebruiker selecteert menu item 'Back-up maken' Systeem toont een Opslaan als dialoog venster 3. Gebruiker selecteert een locatie om de back-up op te slaan Systeem maakt de back-up en slaat hem op 1. De applicatie heeft een back-up gemaakt en op de aangewezen locatie opgeslagen USE CASE UC-B-BR: BACK-UP TERUGZETTEN (RESTORE) Naam Identificatie Omschrijving Actor Precondities Acties Postcondities Back-up Terugzetten UC-B-BR Om een weloverwogen reden wil de beheerder een back-up terug zetten. Beheerder 1. Applicatie is gestart en focus is op het hoofdscherm 2. Beheerder heeft een geldige/bruikbare back-up 1. Gebruiker drukt op menu item 'Beheer' Systeem toont menu Beheer 2. Gebruiker selecteert menu item 'Back-up terugzetten' Systeem toont een Open Back-up dialoog venster 3. Gebruiker selecteert het back-up bestand Systeem zet de back-up terug 1. De inhoud van de back-up heeft de inhoud van de database vervangen.

60 5. REQUIREMENTS Uit de use cases en de gesprekken met de stichting volgen de requirements. De stichting kwam hoofdzakelijk met globale functionele eisen zoals de applicatie moet dit of dat. Na het stellen van gerichtere vragen werden de eisen aan de informatie die moet kunnen worden opgeslagen, duidelijk. In een tweede vragenronde kwamen ook onderwerpen aan bod die de stichting nog niet had overwogen, zoals beveiliging, operationele zaken en user interface eisen. In dit hoofdstuk zijn de eisen onderverdeeld in: functionele, gebruikersinterface/gebruiks, performance, operationele veiligheid en toekomst requirements. FUNCTIONELE EISEN ALGEMEEN Must 1. De volgende onderdelen moeten kunnen worden opgezocht, toegevoegd, aangepast en verwijderd: a. Muziekboeken b. Musici (Componisten en Arrangeurs) c. Uitgevers d. Catalogi 2. Er moet voorraad informatie bijgehouden worden van muziekboeken. 3. Er moet een back-up van de database kunnen worden gemaakt. 4. Er moet een back-up van de database kunnen worden teruggezet. 5. Muziekboeken moeten in pdf-vorm weergegeven kunnen worden en worden afgedrukt. 6. Catalogi moeten gemaakt en afgedrukt kunnen worden. 7. Er moet een lijst weergegeven kunnen worden met boeken die niet in voorraad zijn, maar nog wel verkocht worden. 8. Er moet een verkoopoverzicht gemaakt, ingezien, afgedrukt en verwijderd kunnen worden van uit te betalen auteursrechten per uitgever. 9. Van het verkoopoverzicht moet per uitgever een deelverzameling muziekboeken geselecteerd kunnen worden en in een lijst gezet kunnen worden. 10. Een gemaakt overzicht met af te dragen auteursrechten kan gemarkeerd worden als betaald. De muziekboeken worden dan bijgewerkt met de einddatum van de selectie op de factuur.

61 DATAOPSL AGEISEN Must 1. Voor een muziekboek moeten de volgende attributen kunnen worden bijgehouden: a. Titel b. Beschrijving c. Moeilijkheidsgraad d. Afgesproken royalty percentage e. Disc nummer f. Indicatie handgeschreven g. Indicatie print on demand h. Aantal pagina's i. Locatie master copy j. Locatie voorraad k. Laatste datum royalty uitbetaling l. De verkoopprijs (incl. 6% btw) m. Aantal afgedrukt/verkocht per prijs n. Instrumenten o. Omslag bestand(en) p. PDF bestand(en) q. KPU bestand(en) r. Uitgever s. Componist(en) t. Arrangeur(s) u. Aantal pagina's v. Opmerkingen van de uitgever w. Selectiedatum x. Selectie van boeken die afgedrukt/verkocht zijn in de selectie (periode). 2. Voor een musicus: a. Voornaam b. Achternaam c. Tussenvoegsel 3. Voor een uitgever: a. Naam b. Adresgegevens c. Website adres d. adres e. Telefoonnummers 4. Voor een catalogus a. Naam/Titel Should 1. Willekeurige files bij een muziekboek (bijvoorbeeld MIDI of Klavar notatie)

62 LOOK, FEEL & USAGE REQUIREMENTS ALGEMEEN Must (met interface wordt de gebruikersinterface bedoeld) 1. De interface moet grafisch zijn. 2. De interface moet bij voorkeur native Windows zijn. 3. Alle invoer velden die geen vrije tekst mogen bevatten moeten gevalideerd worden. 4. Bij invoer fouten moet de interface duidelijk aangeven welke velden fout zijn en waarom ze fout zijn. 5. De interface moet waarschuwen als er niet opgeslagen wijzigingen zijn. 6. De interface moet waarschuwen bij verwijderen en om een bevestiging vragen. 7. Bij zoeken moet er een type-ahead suggestie komen. 8. Bij zoeken moet er direct een lijst van (tussen)resultaten verschijnen. STIJL VAN DE GEBRUIKERSINTERFACE Must 1. De interface moet helder en duidelijk te onderscheiden kleuren gebruiken. 2. De interface moet goed leesbaar zijn Could 1. De interface moet de keuze geven uit verschillende thema s. USABILITY REQUIREMENTS Must 1. De meest gebruikte functies, Zoeken, Opslaan en Nieuw Muziekboek, moeten op het beginscherm direct zichtbaar zijn, indien niet verborgen. 2. De interface moet zoveel mogelijk lijken op standaard software pakketten als bijvoorbeeld Microsoft Office, met voor de gebruiker herkenbare elementen en gedrag. 3. De interface moet bruikbaar zijn voor mensen met weinig computervaardigheden. Should 1. Er zou geen operatie mogen zijn waarbij meer dan 5 handelingen (klikken/typen) nodig zijn. PERFORMANCE REQUIREMENTS SPEED REQUIREMENTS Must 1. Binnen 2 seconden een zoek opdracht hebben afgehandeld. 2. Opstarten moet binnen 1 minuut gebeuren 3. Alle handelingen, anders dan zoeken en opstarten, binnen 4 seconden hebben afgehandeld.

63 BESCHIKBAARHEIDSEISEN Must 1. Up-time van 99,9% Won't 1. Een redundante/hot-backup/replicated database. SCAL ABILITY REQUIREMENTS Must 1. De database moet één read/write-gebruiker ondersteunen. 2. De database moet tenminste 5 simultane read-only-gebruikers ondersteunen. 3. Er moeten tenminste records per entiteit kunnen worden ingevoerd. OPERATIONELE REQUIREMENTS OMGEVING Must 1. De applicatie moet werken op zowel de 32 bits als de 64 bits versies van Windows (XP, Vista en 7). 2..NET Framework versie 4.0 is aanwezig op de cliëntcomputer. Could 1. De applicatie moet van een datastick kunnen opstarten en geen instellingen vooraf vereisen, of de gebruiker informeren over het maken van deze instellingen. Won't 1. De applicatie is standalone en verwacht geen webserver of application hosting framework. PARTNER APPLICATIES Must 1. De applicatie verwacht te kunnen communiceren met een MySQL database ONDERHOUDBAARHEIDSEISEN Must 1. De applicatie moet bestaan uit nette code om onderhoud te vergemakkelijken. PORTABILITEITSEISEN Won't 1. De mogelijkheid om de software op andere platformen te draaien; bijvoorbeeld op Windows Mobile/Linux. HERSTEL BAARHEIDSEISEN

64 Must 1. Back-ups moeten gemaakt kunnen worden in SQL-script formaat. Could 2. Elke nacht moet er automatisch een back-up gemaakt worden. 3. Hersteloperaties kunnen gedaan worden met behulp van SQL scriptimports. BETROUWBAARHEIDSEISEN Must 1. De applicatie moet foutmeldingen uit de database kunnen opvangen. 2. Na een fout uit de database moet de applicatie zijn gegevens herladen. 3. Wanneer er gegevens verloren gaan (een concurrente update forceert bijvoorbeeld een transactie-rollback) moet de gebruiker hier over geïnformeerd worden. VEILIGHEIDSEISEN INTEGRITEIT Must 1. De applicatie moet bij de koppelingen tussen objecten afdwingen dat die daadwerkelijk bestaan (referentiële integriteit). 2. De gebruiker mag niet (door invoer) SQL commando's uit kunnen voeren. (SQL-Injection). AUTHENTICATIE Could 1. De applicatie moet beveiligd zijn tegen ongeautoriseerd gebruik door middel van een wachtwoord. CONSTRAINTS & AANNAMES Should 1. Er wordt niet van uit gegaan dat de huidige database met muziekboeken geïmporteerd kan worden in de nieuwe database. Maar de titel en het catalogusnummer zouden wel geïmporteerd moeten kunnen worden. TOEKOMSTSEISEN Could 1. De boeken die online worden verkocht, worden direct van de voorraad in de database afgehaald. 2. De applicatie kan direct in het financiële systeem de betaalde auteursrechten verwerken.

65 6. ONTWERPSUGGESTIES De requirements geven samen met de use cases al veel duidelijkheid over wat er minimaal aan informatie moet kunnen worden bijgehouden en hoe de data samenhangt. Dit leidt heeft geleid tot het onderstaande model van de data. Daarnaast bieden de use cases een goed inzicht in welke menu items, knoppen en andere componenten er nodig zijn. Dit resulteerde in een mock-up van de interface. In het model van de data staat het muziekboek centraal. Verder is het nodig om de wijzigingen van alle prijzen bij te houden om ervoor te zorgen dat de af te dragen auteursrechten correct berekend worden. Het is nog onduidelijk of het royaltypercentage over tijd kan verschillen, en of dat dus ook moet worden bijgehouden. Ook zien we dat de realisatie van een eerste could have, te weten het koppelen van files aan een muziekboek, niet veel meer is dan een generalisatie van de koppeling van pdf en cover files. MusicBook Representeert een muziekboek met een uniek catalogusnummer. Musician MusicScore Catalog PriceDatePair Representeert een muzikant. Dat kan zowel een componist als een arrangeur zijn. Representeert een muziekstuk in een MusicBook, in de toekomst wordt informatie over muziekstukken wellicht ook ingevuld. Representeert een catalogus die 0 of meer muziekboeken kan bevatten. Een muziekboek kan gedurende een auteursrechtelijke periode

66 van prijs veranderen. Omdat dit van invloed is op de auteursrechten die moeten worden afgedragen, is het belangrijk om de gehele prijsgeschiedenis bij te houden. De entiteit PriceDatePair dient hiertoe. QuantityDatePair Publisher KlavarFile Representeert een aantal afdrukken van een boek en de datum waarop dat aantal is afgedrukt. Samen met PriceDatePair kan het verschuldigde auteursrecht worden berekend. Representeert de uitgever van een boek. Representeert een bestand dat bij dit muziekboek hoort. Dit kan zijn bijvoorbeeld de cover, full-text pdf of een midi file van de muziek. De interface zou er ongeveer zo uit kunnen gaan zien: We zien hier een informatiescherm voor een boek. De informatievelden zijn verdeeld over tabbladen om een goed overzicht te geven. De meest gebruikte elementen komen op het eerste geneste tabblad om ervoor te zorgen dat de gebruiker zo min mogelijk handelingen moet verrichten. Het is niet ondenkbaar dat dit later nog verandert. Verder valt het volgende op: het gebruik van heldere kleuren; genoeg marge voor de leesbaarheid; input validatie; terugkoppeling naar de gebruiker.

67 Daarnaast is er een duidelijke herkenbaarheid van elementen en kunnen de gebruikers er dus snel mee aan de slag, zonder veel benodigde instructies.

68 7. VERKLARENDE WOORDENLIJST Use Cases Een use case model is een methode om de eisen aan een systeem te definiëren. Het use case model geeft gedetailleerde informatie weer over het gedrag van het systeem. Het geeft ook weer aan welke voorwaarden het systeem moet voldoen om de doelstelling van de gebruiker te bereiken. Actor Een persoon die acties uitvoert binnen het systeem. Bijvoorbeeld een medewerker. In de use cases wordt beschreven welke actoren welke acties uitvoeren. Een medewerker kan de rol van meerder actoren spelen, bijvoorbeeld: bij het maken van back-up speelt de medewerker voor het systeem de rol van beheerder. Als de medewerker aanmaakt is hij voor het systeem een gebruiker. Er kunnen ook actoren zijn die niet door natuurlijke personen worden gespeeld. Het maken van een back-up kan immers ook automatisch gebeuren. Het systeem fungeert dan zelf als de actor beheerder. Precondition Precondities zijn voorwaarden waaraan het systeem moet voldoen bij het begin van een use case. de applicatie is opgestart is bijvoorbeeld een voorwaarde die gesteld wordt voordat een actor andere acties kan uitvoeren. Postcondition Dit zijn voorwaarden waaraan het systeem moet voldoen na het doorlopen van een use case. Bijvoorbeeld de wijzigingen zijn opgeslagen na het klikken op de knop opslaan. Requirement Een eis aan het systeem. Elke eis die gesteld wordt aan het systeem is een requirement. Requirements worden doorgaans opgedeeld in twee groepen, te weten, functionele requirements en niet functionele requirements. Functional requirement Een functionele requirement is een eis die gesteld word over een functie die het systeem ondersteunt. Bijvoorbeeld er moet een back-up gemaakt kunnen worden. Non-functional requirement Dit zijn niet-functionele eisen, ofwel eisen aan de applicatie die geen deel uitmaken van de functionaliteit. Bijvoorbeeld: de software moet snel zijn. Usability Met usability wordt vaak bedoeld hoe bruikbaar een bepaalde keuze is voor de gebruiker. Bijvoorbeeld maken we deze knop blauw of groen kan van invloed zijn op hoe de gebruiker de applicatie ervaart en gebruikt. Deze afwegingen en de uiteindelijke keuze worden vaak verwoord in termen van usability. Typeahead

69 Typeahead is het gedrag van software waarbij direct bij het intypen van zoekwoorden door een gebruiker, gezocht wordt naar wat de gebruiker zou kunnen bedoelen. Bijvoorbeeld als een gebruiker Aa intypt, dan zal de software direct in de zoekresultaten Aap maar ook Aardbij kunnen tonen. GUI Afkorting van de term Graphical User Interface; dit is een grafische werkomgeving die o.a. gebruik kan maken van formulieren, knoppen en vensters. Dit staat in contrast met tekst-gebaseerde werkomgevingen waaronder MS-DOS. Themes/Thema s Een verzameling van regels met een bepaalde samenhang, die de stijl en de vorm van weergave van een gebruikersinterface bepalen. Een voorbeeld van zo n regel is: knoppen zijn groen en afgerond met een hoekje van 2 pixels. In veel applicaties kan de gebruiker zelf een thema kiezen. Mock-up Een voorbeeld van een element. Vaak met betrekking tot een gebruikersinterface. Een voorbeeldscherm wordt dan een mock-up genoemd en is enkel bedoeld om een idee te geven van de grafische weergave van de software. Back-up Een reserve kopie, vaak van data/gegevens; overigens kan dit ook betrekking hebben op hardware, bijvoorbeeld een reservecomputer. SQL Een afkorting van Structured Query Language; dit is een de taal die softwarewereld gebruikt om vragen te stellen aan een database systeem om er informatie uit te halen. Dit gaat in termen van Selecteer alle muziekboeken uit catalogus Piano. MySQL Een specifiek database systeem van Oracle dat SQL vragen kan beantwoorden en data op een bepaalde wijze opslaat.

70 BIJLAGE 6: ARCHITECTURAL DESIGN DOCUMENT 1. INLEIDING 1.1. DOEL VAN HET SYSTEEM Stichting Klavarskribo beschikt momenteel over een programma waarin informatie over hun muziekboeken wordt opgeslagen. Daarnaast worden lijsten met te betalen royalties of auteursrechten gemaakt voor de uitgevers waarvan Klavarskribo muziek verkoopt of omzet van het notenschrift naar Klavar. Dit programma is al erg oud, en werkt alleen op het besturingssysteem MS-DOS. Daarnaast maakt Klavarskribo met behulp van Microsoft Office Excel catalogi, waarin de boeken die Klavarskribo uitgeeft gevonden kunnen worden DESIGN DOELEN Er moet een vervangend systeem gemaakt worden dat op de drie nieuwste versies van Windows werkt, namelijk Windows XP, Windows Vista en Windows 7. Daarnaast moeten momenteel zeer tijdrovende handelingen uitgevoerd worden voor het maken van een lijst met te betalen auteursrechten. Deze handelingen moeten met het nieuwe systeem geautomatiseerd worden. Daarnaast moet het mogelijk zijn om met het nieuwe systeem een catalogus te maken, in plaats dat die gemaakt worden met Microsoft Office Excel. Ook zou de database waar de website gebruik van maakt, in de toekomst samengevoegd moeten kunnen worden met de database van het huidige programma en moet het mogelijk worden om vanaf elke willekeurige locatie het kaartenbak programma te gebruiken DEFINITIES, ACRONIEMEN & AFKORTINGEN Klavarskribo De stichting waarvoor het nieuwe systeem moet worden gemaakt. Klavar Entity Data Model Subsystem Decomposition MySQL Server MVVM Het muzieknotatieschrift waarin Klavarskribo muziekboeken uitgeeft. Model van de data dat de attributen van, en onderlinge relaties tussen de entiteiten weergeeft. De verdeling van het systeem in kleinere deelsystemen. Een database systeem van Oracle dat SQL vragen kan beantwoorden en data op een bepaalde wijze opslaat. Een systeem dat diensten aanbiedt. Afkorting van Model-View-ViewModel

71 Design pattern Een richtlijn om op een gestructureerde manier software te ontwikkelen REFERENTIES Dit architectural design is gebaseerd op de eisen uit het requirements document voor de kaartenbak STRUCTUURBESCHRIJVING Dit document is als volgt opgebouwd. Hoofdstuk 2 beschrijft beknopt de architectuur van het oude systeem. Vervolgens wordt een voorgestelde architectuur voor het nieuwe systeem besproken in het derde hoofdstuk. Hoofdstuk 4 beschrijft welke services geboden worden door de verschillende deelsystemen in de voorgestelde architectuur.

72 2. HUIDIGE SOFTWARE ARCHITECTUUR Het huidige systeem wat Klavarskribo gebruikt voor het opslaan van informatie van haar muziekboeken bestaat uit verschillende onderdelen. Van deze onderdelen moet het kaartenbakprogramma vervangen worden. Het kaartenbakprogramma bestaat uit een MS-DOS applicatie voor de weergave van informatie over muziekboeken die opgeslagen zijn in een database. Deze database is momenteel een tekstbestand met een zeer slechte structuur. Deze slechte structuur resulteert samen met de slechte opbouw van het oude programma in: 1) inefficiënte en daardoor trage zoekacties; 2) veel handmatig uit te voeren acties die eenvoudig geautomatiseerd zouden kunnen worden; 3) inconsistente informatie; 4) ontbrekende informatie; 5) hoge foutgevoeligheid en bijna geen fouttolerantie. Daarnaast ontbreken enkele mogelijkheden, waaronder de mogelijkheid tot het maken van catalogi. De catalogi worden nu handmatig met behulp van Microsoft Office Excel gemaakt. Daarnaast is er ook een MySQL database aan de website van Klavarskribo gekoppeld die handmatig moet worden bijgewerkt. Hierdoor moet dus op 3 verschillende plaatsen dezelfde of een gedeelte van de informatie over een bepaald muziekboek worden ingevoerd in de computer. Meer informatie over het huidige programma en enkele voorbeelden van eerder genoemde resultaten van de slechte structuur en slechte opbouw van het oude systeem kunnen gevonden worden in het eindverslag. 3. VOORGESTELDE SOFTWARE ARCHITECTUUR Een goede architectuur is één van de belangrijkere onderdelen van een goed systeem. Dit hoofdstuk beschrijft de voorgestelde architectuur voor het nieuwe systeem. Eerst wordt er een decompositie van het systeem gegeven. Vervolgens wordt in paragraaf 3.2 kort iets gezegd over de hardware/software mapping. Paragraaf 3.3 geeft een uitgebreide beschrijving van het persistent data management in het systeem. Verder worden toegangsbeheer, concurrente processen en de grensvoorwaarden van het systeem, besproken.

73 3.1. SUBSYSTEM DECOMPOSITION Het systeem wordt onderverdeeld in verschillende deelsystemen. Deze paragraaf geeft een korte beschrijving van deze deelsystemen. Het systeem is ontbonden in de volgende zes verschillende componenten. Deze ontbinding is weergegeven in de vorm van een componentdiagram die te vinden is in

74 Bijlage 6.1: Subsystem DecompositionBijlage 6.1: Subsystem Decomposition. De componenten zijn de volgende: DatabaseManagement: het MySQL DBMS voor de opslag en het management van de data. EntityData: deelsysteem voor het transformeren van data uit de database naar entiteiten met hun onderlinge relaties. CardBoxDataMapper: deelsysteem voor de transformatie van modelobjecten voor de kaartenbak naar entiteiten, en andersom. Model: deelsysteem dat als datamodel voor de kaartenbak fungeert. ViewModel: deelsysteem dat als controller fungeert voor het afhandelen van gebruikersacties en het uitvoeren van operaties op de data. View: deelsysteem dat gebruikt wordt voor de representatie van de data richting de gebruiker. De ontbinding is als volgt tot stand gekomen. Stichting Klavarskribo wil in de nabije toekomst dezelfde database voor zowel de kaartenbak als de website gebruiken. De website heeft een ander onderliggend datamodel dan de kaartenbak en gebruikt momenteel een database waarin informatie staat die niet in de kaartenbak gebruikt zal worden. Als nu ten behoeve van de koppeling met de website de database aangepast moet worden, zouden in elk deelsysteem van de kaartenbak referenties, veldtypes en andere onderdelen moeten worden aangepast. Om ervoor te zorgen dat bij het wijzigen van de database niet de hele kaartenbak aangepast moet worden, is ervoor gekozen om een datamodel voor de kaartenbak te maken dat onafhankelijk is van de database. Met behulp van het deelsysteem CardBoxDataMapper kan de entity data naar model objecten, en andersom getransformeerd worden. Als nu de entiteiten en hun relaties, die overeenkomen met de tabellen en hun relaties in de database, gewijzigd worden, is het slechts nodig om de CardBoxDataMapper aan te passen, om ervoor te zorgen dat de mapping correct is. Er is dus sprake van een hoge mate van onafhankelijkheid tussen de database en de deelsystemen van het eigenlijke kaartenbakprogramma. Deze onafhankelijkheid vereenvoudigt het testen van het systeem na het wijzigen van de database, omdat alleen de mappers opnieuw getest moeten worden. Naast bovengenoemde ontbinding met betrekking tot de data, is het eigenlijke kaartenbakprogramma 1 ontbonden in een View, een ViewModel en het Model, die aan het begin van deze paragraaf in het kort zijn beschreven. Deze ontbinding is gebaseerd op het MVVM design pattern en is zeer geschikt bij het gebruik van C# met WPF. 2 Meer informatie over het MVVM pattern kan gevonden worden in [1]. Ook hier is sprake van een grote mate van onafhankelijkheid tussen de verschillende deelsystemen. Zo bevat bijvoorbeeld het ViewModel alle logica van het programma en hoeft bij het aanpassen van de View of het Model, de logica van programma niet aangepast te worden. Dit biedt onder andere de mogelijkheid om op zeer eenvoudige wijze de gebruikersinterface te veranderen zonder het ViewModel te moeten aanpassen en dus ook te testen. De grote mate van onafhankelijkheid volgt uit de services 1 Lees: het kaartenbaksysteem zonder de database en data mapping. 2 De achterliggende redenen voor de keuze voor het MVVM design pattern en de afweging van verschillende design patterns, namelijk MVC en MVP, zullen worden beschreven in het eindverslag.

75 die de deelsystemen onderling bieden. Een uitgebreidere beschrijving van die services, en dus ook de redenen voor de onafhankelijkheid tussen de verschillende deelsystemen, kunnen gevonden worden in hoofdstuk HARDWARE/SOFTWARE MAPPING Stichting Klavarskribo beschikt over enkele cliënt computers, en een webserver die ze huurt voor het hosten van de website. Bij de keuze voor hardware/software mapping is de centrale vraag, waar de processen van de kaartenbak uitgevoerd moeten worden. Aangezien het een stand-alone applicatie moet worden, zal in eerste instantie gebruik gemaakt worden van een lokale MySQL server op de cliënt computer, waar ook alle andere processen met betrekking tot de kaartenbak zullen worden uitgevoerd. In een later stadium wordt de database online gehost PERSISTENT DATA MANAGEMENT Er zijn drie vormen van persistent data management die van belang zijn bij de nieuwe kaartenbak voor Klavarskribo. Deze drie vormen zijn het messagebestand, het settings- of configuratiebestand en de database MESSAGE-BESTAND Een van de vormen van persistent data management is het message-bestand dat alle validatie berichten en foutmeldingen bevat die gebruikt worden in de applicatie. Dit geeft een goed overzicht van de meldingen die kunnen gegeven worden en deze kunnen op deze manier aangepast worden zonder dat de programmacode gewijzigd moet worden SETTINGS-BESTAND Het settings-bestand bevat alle instellingen die de gebruiker in het programma maakt en instellingen die de beheerder kan doen. De volgende instellingen zouden er onder andere in kunnen worden opgeslagen: Het volledige adres met inlogdata van de MySQL server Het volledige adres met inlogdata van de back-up server (bij gebruik van automatische back-up) Inlogdata in de vorm van een opgeslagen gebruikersnaam en wachtwoord voor het programma (indien er ingelogd moet worden) De modus van het programma: online of offline (indien hier onderscheid tussen gemaakt wordt [volgt uit het requirement over de beschikbaarheid van de data]) Het gebruikte kleurenschema (indien er verschillende zijn) De gebruikersinterface (indien er verschillende zijn)

76 De weergavemodus van het programma bij het starten (bijvoorbeeld initieel gemaximaliseerd, geminimaliseerd, gedeeltelijk of volledig scherm) De venstergrootte van het programma De instellingen van elementen in de gebruikersinterface (breedte van werkbalken, lettergrootte etc.) DATABASE De database is de belangrijkste vorm van persistent data. In de database wordt alle informatie over de muziekboeken opgeslagen. Het Entity data model in Bijlage 6.2: Entity Data Model geeft de onderlinge relaties tussen de entiteiten in de database weer. Hieronder volgt een korte beschrijving van elk van deze entiteiten. Entiteit Catalog Cover Instrument KlavarFile MusicBook Musician MusicScore PriceDatePair PublicationRemark Publisher QuantityDatePair RoyaltyPaymentOverview Beschrijving Een catalogus waarin muziekboeken staan. De omslag (kaft) van een boek. Een instrument waarvoor een boek is gemaakt. Een bestand (bijvoorbeeld pdf of midi) dat behoort bij een boek of kaft. Een muziekboek. Een musicus (componist of arrangeur) Een muziekstuk uit een muziekboek. Een prijs met bijbehorende mutatiedatum. Een opmerking m.b.t. de uitgever van een muziekboek in het notenschrift, bij een publicatie van een boek met bijbehorend royaltypercentage en datum van laatste betaling. Een uitgever van muziekboeken en/of muziekstukken. Een hoeveelheid van muziekboeken die zijn afgedrukt, met bijbehorende datum. Een overzicht van de te betalen auteursrechten.

77 3.4. TOEGANGSBEHEER In het requirements document zijn twee actoren onderscheiden. Deze twee actoren zijn de beheerder en de gebruiker. Zowel beheerder als gebruiker heeft in de software de zelfde rechten en elke gebruiker is dus ook tegelijkertijd beheerder. Initieel zullen er geen beperkingen op de toegang worden gelegd. Wel is de database beveiligd met een wachtwoord. In de toekomst of als er genoeg tijd over is, zal de beveiliging in overeenstemming met het could-have requirement onder (Veiligheidseisen- >Authenticatie) in het requirements document, worden geimplementeerd. De applicatie is dan beveiligd met een wachtwoord tegen ongeautoriseerd gebruik CONCURRENCY Bij de kaartenbak is er geen sprake van concurrente processen in het systeem die problemen kunnen geven. In een later stadium zal misschien de mogelijkheid worden gegeven om tegelijkertijd met twee versies van de applicatie dezelfde data te wijzigen, maar aangezien een transactionele database wordt gebruikt en er geen sprake is van replicatie van de database, worden de transacties op de juiste manier afgehandeld doordat ze samengevoegd worden of de nieuwste transactie de oudere overschrijft GRENSVOORWAARDEN Het systeem zal in eerste instantie slechts op één computer draaien. Daarbij kunnen twee belangrijke onderdelen onderscheiden worden, namelijk de (lokale) databaseserver en de cliëntapplicatie. Om te voorkomen dat het systeem onderuit gaat, moet rekening gehouden worden met de volgende dingen: - De databaseserver is niet gestart: De cliëntapplicatie moet controleren of de server is gestart. Als dat niet zo is, moet de cliëntapplicatie proberen om de server te starten. Als dit niet lukt, moet de applicatie dit melden richting de gebruiker. - De databaseserver stopt terwijl de cliëntapplicatie in gebruik is: De gebruiker krijgt een foutmelding en de applicatie herstart. Als de database op een externe server wordt gezet, geldt hetzelfde als voor een lokale database, met het enige verschil dat er gecommuniceerd wordt met de database via een TCP/IP verbinding. Dagelijks zal er een back-up gemaakt worden van het systeem m.b.v. Backup Online van KPN. Hier maakt stichting Klavarskribo momenteel al gebruik van. In het geval van ernstige beschadigingen van de database, kan deze back-up teruggezet worden door de gebruiker. Daarnaast kan de gebruiker zelf een lokale back-up maken vanuit het programma.

78 Eindverslag IN3405 BSc project Delft,

79 4. SUBSYSTEM SERVICES De deelsystemen waarin het systeem is onderverdeeld, bieden allen hun eigen diensten aan andere deelsystemen. Dit hoofdstuk beschrijft de services die de deelsystemen onderling aanbieden. Het EntityData deelsysteem biedt een interface aan de CardBoxDataMapper voor alle mogelijke operaties (aanmaken, lezen, wijzigen en verwijderen) op de entiteiten in de database. De CardBoxDataMapper vertaalt op zijn beurt de entiteiten naar modelobjecten en modelobjecten naar entiteiten. Daarnaast vertaalt dit deelsysteem de onderlinge operaties op entiteiten en modelobjecten naar elkaar. Het ViewModel maakt van deze (mapping)service van de CardBoxDataMapper gebruik door modelobjecten te initialiseren. Het Model biedt een representatie van de data aan het ViewModel aan. Het ViewModel kan deze modelobjecten aanbieden aan de View. De View biedt een service aan de gebruiker in de vorm van een gebruikersinterface, waarmee de gebruiker op een prettige manier met de modelobjecten kan werken.

80 BIBLIOGRAFIE 1. WPF Apps With The Model-View-ViewModel Design Pattern. Smith, Josh. 2009, MSDN Magazine.

81 BIJLAGE 6.1: SUBSYSTEM DECOMPOSITION

82 BIJLAGE 6.2: ENTITY DATA MODEL

83 BIJLAGE 7: TECHNICAL DESIGN DOCUMENT 1. INLEIDING Bij de ontwikkeling van de nieuwe kaartenbak voor stichting Klavarskribo wordt er een traject doorlopen waarbij er een ontwerpdocument van de architectuur en de technische kant van het nieuwe systeem gemaakt wordt. Hierbij geeft het ontwerpdocument van de architectuur een globaal ontwerp van de architectuur van het systeem, waaronder de deelsystemen waarin het systeem wordt onderverdeeld, en het technische ontwerp document geeft een gedetailleerde uitwerking in termen van componenten, klassen, methoden en properties. De opzet van dit technische ontwerp document is als volgt. In hoofdstuk 2 wordt een beschrijving gegeven van de translatie van de beschreven architectuur naar namespaces. Vervolgens geeft hoofdstuk 3 een gedetailleerdere beschrijving van de belangrijkste klassen. Tot slot is er in appendix A een complete uitwerking van het technische ontwerp opgenomen, waar alle klassen, methode en eigenschappen zijn opgenomen.

84 2. NAMESPACES De applicatie is opgedeeld in 4 onderdelen: Het model, dat de realiteit modelleert (KlavarCardBox.Model) Het Entity Framework model, de vertalende laag naar de database De model-entity transformatie laag (mapping), die het programma koppelt met de database (KlavarCardBox.Data) De GUI en de logica, die de applicatie voor de gebruiker vormt (KlavarCardBox.Main) De gekozen tools (zie onderzoeksverslag) sluiten goed aan bij deze verdeling. Zo wordt de code voor het Entity Framework gegenereerd uit het Entity Model, zoals gepresenteerd in het architectuur-ontwerpdocument. Omdat dit onderdeel geautomatiseerd is, wordt dit onderdeel niet nader beschreven in dit document. Door het gebruik van Windows Presentation Foundation (WPF) is er de mogelijkheid tot een uiterst strikte scheiding van de GUI logica, de GUI en het Model. Onderdeel Main maakt gebruik van Model en de Entity Framework mappers. De EF mappers zijn afhankelijk van de entity data en Model. Het model is niet afhankelijk van de andere onderdelen. Hieronder volgt een inhoudelijke beschrijving van de namespaces en de sub-namespaces. Model In de root van het model bevinden zich de basis objecten die worden gebruikt door de EF mappers van het entity-mapping project. Dit zijn de hoofdobjecten zoals MusicBook en Publisher. Alle objecten in deze namespace erven van het BaseModel. Collections Deze namespace bevat alle collecties van de standaard modelobjecten. Algemeen beschouwd zijn dit wrappers om een generic 3 collectionklasse, die het generic typeargument invullen. Enumerations Deze namespace bevat enumeraties (opsommingen) die nodig zijn voor de modelklassen. Bepaalde properties van de modelklassen kunnen slechts een gering aantal waarden aannemen. Bijvoorbeeld een property status kan één van de waarden betaald, niet betaald of verzonden aannemen. Hiervoor worden enumeraties gebruikt. Attributes Deze namespace bevat validators die gebruikt worden voor de validatie van de properties van de modelklassen. Bijvoorbeeld ValidateNotNull en ValidateIntegerRange. 3 Let op: in dit document duidt generic (Engels) op het type templating systeem van c#. En generiek (Nederlands) op de normale Nederlandse betekenis.

85 Data In de root van het Entity-Mapper onderdeel komen alle basisklassen die overgeërfd worden door de mappers en repositories. EntityMappers De mapper klassen in deze namespace zijn de crux van de EF mapping. Ze zorgen voor de vertaling tussen de entiteiten uit de database en de objecten uit het model. Alle mappers erven van BaseMapper. EntityRepositories De repositories vormen het belangrijkste onderdeel voor het muteren van de data vanuit de applicatie. Ze bieden functies om objecten te zoeken, op te slaan, en te verwijderen. Alle repositories erven van BaseRepository. View In deze namespace staan alle XAML files en de bijbehorende gegeneerde C# klassen die samen de gebruikersinterface van de applicatie vormen. Omdat er in overeenstemming met het MVVM ontwerppatroon wordt ontwikkeld zal de View geen logica m.b.t. het opereren op de data bevatten. ViewModel Deze namespace bevat alle ViewModels. Voor elk van de Views is er een ViewModel. De ViewModels bevatten alle logica van het programma, en voorzien de Views van modelobjecten. Framework Als basis voor alle ViewModels staan er in deze namespace een aantal abstractielagen van het ViewModel. CustomControls In deze namespace komen alle klassen die herbruikbare GUI elementen voorstellen. Deze zijn vaak samengesteld uit eenvoudigere controls van WPF.

86 3. KLASSEN Er zijn een aantal onderdelen uit het ontwerp die nadere omschrijving behoeven, vanwege de complexiteit of vanwege het feit dat ze een belangrijke rol spelen in de applicatie. In dit hoofdstuk worden deze klassen beschreven en wordt hun doel verduidelijkt BASEMODEL De BaseModel klasse uit de KlavarCardBox.Model namespace speelt een sleutelrol in de applicatie. Alle modelklassen overerven van deze klasse. Omdat er in de Views bindingen gemaakt worden met de eigenschappen of properties van deze objecten is het natuurlijk dat het BaseModel de interface IDataErrorInfo implementeert. Deze interface van het.net Framework wordt gebruikt om validatie informatie te retourneren. Daarnaast is het ook wenselijk dat het BaseModel de interface INotifyPropertyChanged implementeert. Dit wordt gebruikt om WPF te ondersteunen bij de binding aan de Views. Door het gebruik van reflection kan een lijst worden gemaakt van alle properties die het run-time-type ondersteunen (bijvoorbeeld: Als het run-timetype Musician is, dan kunnen alle properties van Musician worden gevonden). Op deze manier kan BaseModel generieke ondersteuning bieden voor opslag en notificatie van modificatie van alle properties van alle overervende klassen. Ook validatie is met behulp van reflection eenvoudig te realiseren. Door gebruik te maken van zgn. custom attributes bij het definiëren van properties, kan het grootste deel van de validatie van properties worden gerealiseerd. Zo kan aan properties met de validator ValidateNotNull, niet de null waarde worden toegekend. Door de validatie attributen ook te voorzien van properties, kan een boodschap voor de gebruiker worden opgenomen mocht de validatie niet slagen. Hierdoor kan de gebruiker vanuit het model terugkoppeling krijgen over eventuele validatiefouten. De klassen die BaseModel overerven hoeven enkel hun properties te definiëren, en eventuele extra validatie logica toevoegen die niet gerealiseerd kan worden met de set standaard validatie attributen BASECOLLECTION Een zelfde soort structuur als BaseModel wordt ook gebruikt in de BaseCollection klasse. Deze klasse representeert een collectie van BaseModels. Omdat BaseCollection overerft van de.net Framework klasse ObservableCollection is de notificatie van aanpassingen en opslag van data al geregeld. Er hoeft dus enkel nog validatie toegevoegd te worden. De BaseCollection klasse is generic, dit heeft als gevolg dat het lastig kan werken

87 met XAML. Er zou dan gerefereerd moeten worden aan BaseCollection, gekwalificeerd met een BaseModel type. De XAML syntax hiervoor is complex en word niet ondersteund door de gebruikte design tools. Om dit probleem te omzeilen en om de mogelijkheid te bieden om later extra validatie in te bouwen, wordt er voor de meeste BaseModel klassen ook een collection klasse gedefinieerd, die het generieke type van BaseCollection bepaald MAPPERS EN REPOSITORIES Om in de GUI/logica code gebruik te kunnen maken van objecten uit de database moet er een mechanisme zijn om de objecten op te halen, bij te werken en te verwijderen uit de database. Om de database te benaderen, zonder dat het programma hiervan afhankelijk is, worden repositories en mappers gebruikt. Alle repositories en mappers erven van respectievelijk BaseRepository en BaseMapper. De mappers bevatten relatief eenvoudige methodes die een conversie uitvoeren van model naar data entiteiten en andersom. De repositories bevatten methoden om de BaseModel klassen, na de mapping, in de database op te slaan. De EF methodes Add, Save en Delete bieden hier de ondersteuning voor. Lezen uit de database is een iets complexere handeling. Niet alleen moet de repository de juiste mapper gebruiken, maar ook moet er op criteria geselecteerd kunnen worden. Hiervoor word LINQ (Language INtegrated Query) gebruikt. Dit is een.net Framework onderdeel dat middels een eenvoudige interface een (SQL) query kan opbouwen om objecten te selecteren en te transformeren. Voor de repositories betekent dit dat elke repository zelf de generieke queries met betrekking tot een bepaald object moet implementeren in LINQ. De BaseRepository klasse handelt de algemenere queries af. Een voorbeeld van de waarschijnlijk meest gebruikte algemenere query in de KlavarCardBox is de query waarbij een entity moet voldoen aan een set criteria (die verschillen per repository) en een offset en lengte voor de verzameling van resultaten wordt gegeven VIEWMODELBASE Het MVVM ontwerppatroon schrijft voor dat er een hele strikte scheiding is tussen de gui en de business logic. Het idee is dan dat er in de view (ofwel de definitie van de elementen van de gebruikersinterface) wordt gerefereerd aan eigenschappen van het viewmodel wat bij een view hoort. Zo kan de inhoud van een tekstveld bijvoorbeeld worden gekoppeld aan het property Titel van het viewmodel, waardoor het tekstveld de Titel weergeeft. Dit heet data binding. Als het gebonden object, het viewmodel, de benodigde ondersteuning biedt, kan het tekstveld synchroon blijven met de Titel. Het viewmodel moet daartoe de interface INotifyPropertyChanged implementeren. Invoer van tekst zal dan worden gepropageerd naar de setter van de property, en het tekstvak zal notificaties ontvangen als de Titel door andere operaties wordt veranderd.

88 Omdat de ViewModelBase klasse INotifyPropertyChanged implementeert, is het natuurlijk dat deze klasse op een gelijksoortige manier wordt opgezet als de BaseModel klasse. Ook hier wordt met behulp van reflection een lijst gemaakt van alle properties, en wordt er een gemeenschappelijk systeem voor opslag en notificatie gebruikt WORKSPACE- EN BASEMODELVIEWMODEL Het WorkspaceViewModel representeert een abstractie voor alle ViewModelklassen waarin de gebruiker kan werken. Het hoofdscherm kan een of meerdere workspaces bevatten. De workspaces zijn dan vergelijkbaar met tabbladen zoals we die van moderne web-browsers gewend zijn. De klasse WorkspaceViewModel biedt ondersteuning voor zaken als een save commando voor een actief tabblad, een titel voor de tab en een afhandeling van het sluiten van de tab. Naast het WorkspaceViewModel is een veelvoorkomend specifieker onderdeel in de view, namelijk het wijzigen van de eigenschappen van een modelobject. Hiertoe is de klasse BaseModelViewModel gemaakt. Deze klasse biedt, middels generics, ondersteuning voor het weergeven van een BaseModelobject. Op deze manier kan de save-functie uit het WorkspaceViewModel worden uitgebreid met een save-functie voor een BaseModel. BaseModelViewModel is tevens de klasse die in de hiërarchie van het viewmodel de resultaten van de implementatie van de interface IDataErrorInfo zichtbaar maakt. De meeste controls in WPF kunnen namelijk reageren op de implementatie van deze interface. Zo zal bijvoorbeeld het tekstvak dat is gebonden aan de property Titel een rode rand krijgen als de ingevoerde titel niet voldoet aan de eisen RELAYCOMMAND Bij de voorgaande beschrijving is het concept commando al gebruikt. WPF biedt de mogelijkheid voor een afhandeling van gebruikeracties door middel van de ICommand interface. Buttons, hyperlinks en andere interactieve elementen uit WPF hebben een Command eigenschap die kan worden gebonden aan een property van type ICommand van het ViewModel. Dit noemt men command binding. Zodra de gebruiker het interactieve element aanklikt worden methodes uit de ICommand interface aangeroepen. In KlavarCardBox is hiervoor een klasse gedefineerd, namelijk RelayCommand. Deze klasse is een implementatie van de ICommand interface. RelayCommand bevat enkel een referentie naar functies die de werkelijke actie uitvoeren. ViewModels gebruiken RelayCommand door deze te vullen met de uitvoerende functies van het ViewModel.

89 APPENDIX A Deze appendix die een technische specificatie van het systeem bevat, kan op aanvraag verstrekt worden. Het document telt enkele honderden pagina s en was te groot om hier toe te voegen. Vraag bij het aanvragen van het document om KlavarCardBox.TTD Appendix A.pdf. Een voorbeeldje van informatie die hierin gevonden kan worden is hieronder weergegeven. Class Documentation template<t > void KlavarCardBox.DataClient.Data.IRepository< T >.Delete ( CriteriaDictionary criteria ) Delete all objects that match given criteria. Parameters criteria The unique ID of the T Implemented in KlavarCardBox.DataClient.Data.BaseRepository< T, TSource > template<t > void KlavarCardBox.DataClient.Data.IRepository< T >.Delete ( T modelobject ) Delete a specific model object from the database;. Parameters modelobject The model object to delete Implemented in KlavarCardBox.DataClient.Data.BaseRepository< T, TSource > template<t > void KlavarCardBox.DataClient.Data.IRepository< T >.Save ( T modelobject ) Save the changes made to a T. Parameters modelobject The model object to change. Implemented in KlavarCardBox.DataClient.Data.BaseRepository< T, TSource >.

90 BIJLAGE 8: SIG CODEREVIEW 1 Volledige tekst van de van Eric Bouwers, betreffende codereview 1. Beste Ewout en Gerben, Bij deze stuur ik jullie mijn evaluatie van de door jullie opgestuurde code. De evaluatie bevat een tweetal aanbevelingen die jullie mee kunnen nemen in de laatste fase van jullie project. Let erop dat deze evaluatie erop gericht is om jullie bewust te maken van de onderhoudbaarheid van jullie code. Aan de evaluatie kunnen door zowel de studenten als een eventueel stage-bedrijf geen rechten ontleend worden. Mochten er nog vragen of opmerkingen zijn dan hoor ik het graag. Aanstaande donderdag ben ik weer in Delft, dan heb ik eventueel tijd voor een korte mondelinge toelichting. Met vriendelijke groet, Eric Bouwers [Evaluatie] De code van het systeem scoort bijna 4 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. Dit is vooral toe te schrijven aan de relatief kleine omvang van het systeem. De score wordt naar beneden gehaald door de duplicatie en de module coupling. De lage score op duplicatie wordt veroorzaakt door een relatief hoog percentage van gedupliceerde code (ongeveer 15%). De oorzaak van dit hoge percentage wordt onder andere veroorzaakt doordat de bestanden 'ObservableCollectionWrapper.cs' en 'BaseCollection-Alternative.cs' en de bestanden 'ExpanderResizablePopup.cs' en 'ToggleResizablePopup.cs' voor meer dan 50 procent aan elkaar gelijk zijn. Over het algemeen is gedupliceerde code niet wenselijk omdat eventuele issues in deze code op meerdere plekken opgelost moeten worden. Het advies is om kritisch te kijken naar de duplicatie binnen het systeem. Het tweede aspect waarop het systeem laag scoort is de module coupling, oftewel het percentage van code wat relatief vaak wordt aangeroepen. Normaal gesproken zorgt code die vaak aangeroepen wordt voor een minder stabiel systeem omdat veranderingen binnen dit type code kan leiden tot aanpassingen op veel verschillende plaatsen. In dit systeem wordt het bestand 'BaseModel.cs' het meest aangeroepen (op bijna 200 locaties). Daarbij is dit bestand 1 van de grootste bestanden in het systeem. Een snelle inspectie doet vermoeden dat dit bestand meerdere rollen vervuld, namelijk zowel het beheren als het valideren van de waardes van alle velden in de model-classes. Daarnaast is de implementatie van deze rollen niet in een keer duidelijk. Het enerzijds opslaan van alle waardes van de velden binnen de class zelf, maar het anderzijds aflopen van velden van subclasses via reflectie brengt enige verwarring met zich

91 mee. Het versimpelen van de class en het uit elkaar trekken van de verschillende rollen zou het voor toekomstige ontwikkelaars makkelijker maken om wijzigingen aan te brengen en wordt daarom ook aanbevolen. Over het algemeen is de code in het systeem kort en simpel, voor zowel methode-lengte als methode-complexiteit scoort het systeem bovengemiddeld. Blijf dit ook in de gaten houden tijdens de laatste fase van het ontwikkelen. Als laatste nog de opmerkingen dat er geen (unit)test-code is gevonden in de code-upload. Het is sterk aan te raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gedefinieerd te hebben om ervoor te zorgen dat eventuele aanpassingen niet voor ongewenst gedrag zorgen.

92 BIJLAGE 9: SIG CODEREVIEW 2 Beste Ewout en Gerben, Dank voor de reactie, bij deze de resultaten van het opnieuw doormeten van de broncode.voor deze hermeting gelden dezelfde opmerkingen als de eerste evaluatie. Mochten er nog vragen of opmerkingen zijn dan hoor ik dat graag. Met vriendelijke groet, Eric Bouwers [Hermeting] In de tweede meting van de code zien we dat er een sprong voorwaarts is gemaakt wat betreft duplicatie, deze is meer dan gehalveerd. De score voor module coupling is niet verbeterd, maar ook niet veel verslechterd. Helaas zien we op andere aspecten (lengte en complexiteit van methodes) wel een significante verslechtering, er zijn nu dus relatief meer langere en complexere methodes in het systeem. Doordat beide veranderingen elkaar compenseren zien we dat op het hoogste niveau de onderhoudbaarheid op hetzelfde niveau blijft. Uit deze observaties, en de meegestuurde reactie op de evaluatie, concluderen we dat de feedback is meegenomen in het ontwikkeltraject. De twee voornaamste punten zijn ofwel geadresseerd in de code, ofwel gedocumenteerd in de reactie. Helaas is het advies om unit-tests op te zetten niet opgepakt, terwijl er tegelijkertijd complexere code aan het project is toegevoegd. Dit advies blijft dus van kracht voor een eventueel vervolg-traject.

93 BIJLAGE 10: BEKNOPTE HANDLEIDING 1. TOEVOEGEN VAN EEN MUZIEKBOEK FIGUUR 1: MAKEN VAN EEN MUZIEKBOEK TABBLAD 1 Om een muziekboek toe te voegen, klikt u op de knop in de werkbalk bij [Figuur 1.1]. Het nieuwe muziekboek bestaat uit informatie die verdeeld is over drie tabbladen, zoals te zien is in [Figuur 1.2]. In [Figuur 1.3] kunt u informatie over het muziekboek dat u wilt maken, invoeren. Als de informatie die een invoerveld bevat, niet juist is, dan wordt dat weergegeven door een rode rand om het invoerveld. Door met uw muis op het veld te gaan staan, wordt weergegeven wat er niet correct is. Als een catalogusnummer ingevoerd wordt van een muziekboek dat alreeds bestaat, dan kunt u het bestaande muziekboek openen. U kunt een ander, nieuw catalogusnummer kiezen voor het muziekboek wat u aan het invoeren was.

94 In de invoervelden [Figuur 2.2] voor componisten, arrangeurs, catalogi en uitgever oud schrift, kunt u zoektekst invoeren. Let op: de zoektekst die hier invoert[figuur 2.2], wordt niet opgeslagen! Als u op [Figuur 2.1] klikt, en geen zoektekst hebt ingevoerd, wordt de complete lijst van alle componisten of andere items weergegeven. U kunt hier uit selecteren voor een muziekboek. FIGUUR 2: COMPONISTEN Als u een componist, arrangeur, catalogus of uitgever wilt toevoegen, kunt u dit doen door op [Figuur 2.1] te klikken en daarna op de knop Nieuw (zie [Figuur 2: Componisten2.3]). Voor het wijzigen van een item, klikt u op de kleine blauwe knop: [Figuur 2: Componisten2.4] U moet voor elk muziekboek in ieder geval de volgende informatie invoeren: - Op tabblad Algemeen : Catalogusnummer, Titel - Op tabblad Overige : Uitgever klavarnotatie Bij het toevoegen van uitgevers notenschrift, moet u, als er aan een bepaalde uitgever auteursrechten betaald moeten worden over bijvoorbeeld 100 van de 300 liederen uit een liedboek het 100/300 keer het percentage dat de uitgever eist, invoeren. Dan wordt dit ook meegenomen bij het maken van een overzicht van te betalen auteursrechten. U kunt een muziekboek opslaan als tenminste de vereiste velden, zoals hierboven genoemd zijn ingevuld, en u de andere informatie correct heeft ingevoerd. De knop voor het opslaan veranderd dan van inactief naar actief.