DB Flow. en evolutionær udvikling

Transkript

1 DB Flow en evolutionær udvikling

2

3 Institut for Datalogi Selma Lagerlöfs Vej Aalborg Øst Telefon: (45) Telefax: (45) Titel: DB Flow - en evolutionær udvikling. Tema: Industrirettet forskning Projekt periode: DAT8, forår 2008 Projekt gruppe: dat8f081 Gruppe medlemmer: Jacob Volstrup Vejleder: Kurt Nørmark Antal eksemplarer: 4 Antal sider: 53 Afleveret: 4. juni 2008 Synopsis: I denne rapport har jeg set på processen med at bruge en software prototype som udgangspunkt for at udvikle et software produkt forfra. Til brug for dette har jeg haft en projektgruppe fra Aalborg Universitet til at teste prototypen. Produktet, en compiler, indlæser et databaseskema, og laver ud fra dette et specialtilpasset modellag som letter arbejdet med en database. Erfaringerne indsamlet i forbindelse med denne test har jeg brugt til at lave en gennemgående analyse, som påpeger hvilke dele af softwareproduktet som skal vægtes højest. Analysen har resulteret i et design som lægger vægt på brugergrænsefladen samt muligheden for at indføre genraliseringer over udvalgte klasser i modellaget. For at give mulighed for disse ændringer, har jeg fokuseret på den interne opbygning af selve compileren, for bedst at kunne undersætte dette.

4 ii

5 Indhold 1 Forord 1 I Baggrund 3 2 Motivation 5 3 Tema 7 4 Status for VDO Statisk framework Compiler Modellag II Problem 13 5 Eksperiment med prototype Magic stats Evaluering af prototype og test 19 7 Analyse Formål og systemdefinition Målgruppe Database Compiler Brugergrænseflade Modellag Nedarvning Problemformulering 27 iii

6 INDHOLD INDHOLD III Produktudvikling 29 9 Design Compiler Nedarvning Grafisk brugergrænseflade Opret forbindelse til database Statusvindue Visualisering af modellag Fejlhåndtering Statisk framework Afvigelser Produkttest Mailserver med Amavis IV Afslutning Evaluering af nye tiltag Konklusion Fremtidige fokus SQLite Grafisk komponenter Litteratur 53 iv

7 1 Forord Denne rapport er blevet udarbejdet i løbet af forårssemestret 2008 på datalogi ved Aalborg Universitet, og dækker det projekt jeg har lavet i løbet af dette semester. Store dele af projektet og rapporten bygger videre på indhold fra tidligere projekter [6, 5, 7] og der kan derfor forekomme tekstuelle sammenfald med disse, selvom disse ikke nødvendigvis er anført som kilder. Rapporten henvender sig til folk med interesse for objektorienteret programmering, og forudsætter derfor også et vist kendskab hertil. Da der arbejdes specifikt med sproget C# vil der blive brugt termer som måske ikke stemmer overens med termenes anvendelse i forbindelse med andre objektorienterede sprog. Da projektet arbejder med at bygge bro til den relationelle databaseverden, vil et vist kendskab hertil hjælpe med at forstå sammenhængen. Forkortelser og væsentlige emner vil blive fremhævet i teksten så de vil fremstå som fx. DB Flow og VDO. Desuden vil nogle brugte titler på kilder blive angivet med kursiv. Kilder vil i teksten blive angivet som [7], hvor nummeret angivet kildens indeks i litteraturlisten, som findes sidst i rapporten. I litteraturlisten er det muligt at se på hvilke sider der er blevet henvist til de enkelte kilder. Compileren DB Flow, som er blevet lavet i forbindelse med dette projekt, vil være tilgængelig på adressen efter torsdag d. 12. juni Jeg vil gerne komme med en stor tak til min vejleder Kurt Nørmark, som har hjulpet mig over nogle af de bump man støder på undervejs med et projekt, til Alex H. Johannesen, som jeg udarbejdede to projekter sammen med; projekter som er grundlaget jeg har bygget videre på i dette projekt, samt projektgruppen i201ba på informatikstudiet ved Aalborg Universitet, som har hjulpet mig med at afprøve prototypen VDO i en sammenhæng som jeg ikke havde mulighed for at kontrollere. 1

8 2 1. Forord

9 3 IBaggrund

10

11 2 Motivation I løbet af mit syvende og ottende semester på datalogistudiet på Aalborg Universitet lavede jeg sammen med Alex H. Johannesen to projekter som tilsammen behandlede problemstillingen med at benytte en relationel database fra et objektorienteret sprog. Det første af projekterne, An Exploration of the Impedance Mismatch [6], klarlagde nogle problemstillinger og så på hvordan forskellige projekter havde prøvet at løse disse, hvorefter det næste, Vivid Data Objects (VDO) [5], med udgangspunkt i de klarlagte problemstillinger, udviklede en prototype til et værktøj som man som programudvikler kan bruge når en relationel database skal bruges fra det objektorienterede sprog C#. Prototypen brugte til dels teknikker vi havde observeret i vores analytiske tilgang, og dels teknikker som vi mente ville gøre værktøjet endnu stærkere at bruge. Alle teknikkerne blev nøje udvalgt og hele opbygningen af prototypen skete ud fra vores ønske om at hjælpe programudvikleren. Ud fra vores egen mening endte vi ud med en ganske fornuftig prototype som, selvom den havde børnesygdomme, var velfungerende og løste de problemer vi havde fået øje på gennem vores analytiske tilgang: at det er besværligt og omstændigt, med risiko for fejl til følge, at programudvikleren manuelt skal tilpasse sine programmer til databasen. En del af idéen bag VDO var at fjerne noget af kompleksiteten fra de opgaver programudvikleren sidder med, på samme måde som brugen af højniveau sprog har fjernet noget af den kompleksitet der hører med til at udvikle programmer i fx. assembler. Efter arbejdet med VDO så jeg en forretningsmulighed i at gøre udviklingen af programmer mindre kompleks samtidig med at det kunne spare tid, som jeg beskrev i mit projekt DB Flow - fra prototype til forretningsplan [7]. På et tidspunkt hvor der er stor mangel på højtuddannede virker det som en fornuftig tilgang, da virksomheder gennem værktøjet ville have mulighed for at spare mange mandetimer under udviklingen. Jeg valgte derfor at udarbejde en forretningsplan som 5

12 2. Motivation en del af mit projekt, sammen med en plan for hvordan den videre udviklingen skulle forløbe For at adskille den forretningsmæssige tilgang til produktet fra VDO valgte jeg at omdøbe det til DB Flow, da jeg synes dette navn bedre beskriver hvad produktet kan. Derudover flyttede mit fokus i større grad over til at se på hvad virksomheder sandsynligvis ville ønske af et sådant produkt. Efter udarbejdelsen af forretningsplanen i forbindelse med mit sidste projekt blev jeg klar over at produktet langt fra var modent nok til at kunne danne fundament for opstart af en virksomhed. Jeg kunne med denne erkendelse have valgt at droppe alt om VDO/DB Flow, men valgte i stedet at træde et skridt tilbage og se på hvad der ville være behov for, hvis produktet skulle modnes. Grunden til dette er at jeg ikke ønsker at droppe DB Flow på et tidspunkt hvor den videre udvikling stort set vil kræve at starte forfra hvis andre ville ønske at tage arbejdet op, og dermed ville være det samme som helt at droppe produktet. Mit ønske med dette projekt er derfor dels at se på hvad en udvikler kunne ønske af funktionalitet i DB Flow samt se på hvilke tiltag som er krævet for at kunne fortsætte udviklingen af DB Flow på en fornuftig måde, med udgangspunkt i prototypen. 6

13 3 Tema Temaet for dette projekt er udstukket af den gældende studieordning som udstikker tre overordnede muligheder for udarbejdelse af projekt [1]. Af disse tre muligheder har jeg valgt Industrirettet forskning som det overordnede tema for mit projekt. Studieordningen siger om dette tema at der skal forskes med henblik på industrirettede aspekter ved en specifik teknologi. For mit vedkommende drejer dette sig om at videreudvikle et produkt som ved semestrets start fandtes i en simpel, men dog fungerende, prototype. Det industrirettede perspektiv ved dette handler om at gå fra en prototype mod et brugbart produkt, ved hjælp af tilbagemeldinger fra brugen af prototypen. Der lægges i studieordningen op til at gennemføre projektet som et samarbejde med en eller flere virksomheder, hvilket fra starten også var mit mål. Det viste sig dog langt sværere end forventet at finde og etablere kontakt til interesserede virksomheder, hvilket resulterede i at jeg i stedet endte jeg ud med at etablere et samarbejde med en projektgruppe på Aalborg Universitet. Selvom denne projektgruppe ikke er en virksomhed, har de dog stadig benyttet produktet som jeg skal videreudvikle på i løbet af dette semester, og jeg anser derfor denne løsning som den næstbedste løsning. Temaet for dette projekt er hvordan man kan benytte respons fra en testgruppe til at indføre ændringer i en ny version af et produkt som er under udvikling. Gruppen vil afprøve en prototype af produktet. Derudover vil jeg se på hvordan man kan opstille testcases som man kan bruge til selv at teste anvendeligheden af sit produkt, hvis det er svært at skaffe testbrugere. Ud fra problemformuleringen i kapitel 8 vil jeg se på hvordan den fremtidige udvikling af produktet vil blive, med udgangspunkt i prototypen, som bliver beskrevet nærmere i kapitel 4. 7

14 8 3. Tema

15 4 Status for VDO Jeg vil i dette kapitel gennemgå prototypen Vivid Data Objects (VDO), med både positive og negative aspekter. Da prototypen skal bruges som en væsentlig del af dette projekt, i forbindelse med brugertests og for at danne grundlag for den videre udvikling, er det vigtigt at læseren har indblik i status for VDO ved projektets start. acrovdo var et vellykket forsøg på at automatisere processen med at generere et objektorienteret modellag ud fra et relationelt databaseskema. Da VDO består af to dele, et statisk framework og en compiler, vil jeg først gennemgå disse to, hvorefter jeg vil beskrive de forskellige teknikker som blev brugt i det modellag som compileren genererede. Prototypen VDO var på mange områder udelukkende lavet for at kunne afprøve nogle opstillede problemstillinger, og løste dette til fulde. VDO bestod af to dele; en compiler og et API. Compileren kunne, ud fra en forbindelse til en given database, generere et specialtilpasset modellag, som ud fra nogle udvalgte designmønstre, skabte klasser som tilsvarede databasens tabeller. Det statiske API indeholdt de ting som ikke skulle specialtilpasses, herunder klasser til at håndtere de forskellige datatyper i databasen. 4.1 Statisk framework Det statiske framework dækker over det API som ikke skulle tilpasses den enkelte database og dermed kunne anses som værende statisk. Dette API indeholdt klasser til at håndtere kommunikation med databasen, specielle exceptions, samt klasser til at håndtere datatyper og søgeresultaterne. Ved at have den generelle funktionalitet i dette API adskilt fra selve modellaget, ville det genererede modellag dels være så minimalt som muligt, samtidig med at det ville være lettere at rette fejl i det generelle, uden at skulle generere et nyt modellag. 9

16 4.2 Compiler 4. Status for VDO Datatyperne i en database stemmer ikke helt overens med typerne i C#, især når der benyttes teksttyper, da der på databasesiden kan være begrænsninger på længden af en streng. Hver af typerne fra databasen skulle derfor oversættes til den C# type som var det tætteste match. For at sikre at den data som blev indsat i databasen var korrekt, blev der indbygget diverse kontrolrutiner, som kunne servere exceptions i de tilfælde hvor den givne data ikke overholdt disse restriktioner. Disse kontrolrutiner blev bygget ind i nogle klasser, som så kunne bruges i det genererede modellag. En af de vigtigste egenskaber ved disse typeklasser var i forbindelse med SQL queries, hvor de håndterede nogle generelle egenskaber til at forhindre Injection Attacks. 4.2 Compiler Under udarbejdelsen af vores compiler blev det primære fokus lagt på det modellag som skulle skabes, hvilket medførte nogle uheldige designmæssige beslutninger omkring den interne opbygning af compileren. Kort fortalt bestod den del af compileren som skulle generere selve modellaget, af en masse tekststrenge som der skulle søges og erstattes tekst i, for at tilpasse modellaget til den givne database. I starten fungerede dette fint, men efterhånden som vi nærmede os målet, begyndte det at blive komplekst at håndtere de sidste funktioner som skulle med, især i de tilfælde hvor der var mange undtagelser at tage hensyn til. Disse undtagelser drejede sig bla. om tilfælde hvor en kolonne i en tabel var primær nøgle, hvor kolonnen indeholdt en relation til en anden tabel, eller for streng properties, da disse havde behov for ekstra exception-håndtering. Der var derudover mange mindre undtagelser, som i den sidste ende blot gjorde koden uoverskuelig. Udover måden at håndtere kodegenereringen på, var datastrukturen undervejs i processen besværlig at benytte, da vi skulle rette mange steder når vi stødte på nye informationer vi havde behov for, men som vi ikke havde været opmærksomme på fra starten af udviklingsprocessen. På den brugsmæssige side var det meget tydeligt at der var tale om en prototype, da compileren bestod af en konsolapplikation, som blev compilet med faste værdier for databasen. Dette hang sammen med at vi under udviklingen havde behov for at køre compileren mange gange, for at kontrollere om resultatet fra compileren var som ønsket. Denne opbygning gjorde det nødvendigt at have kildekoden til compileren for at kunne bruge den på en database. Fordi vores fokus var på resultatet fra compileren, så vi ikke dette som noget problem, da alle tabeller blev oversat til tilsvarende klasser i det resulterende modellaget, som indeholdt den funktionalitet som vi ønskede at implementere. 10

17 4. Status for VDO 4.3 Modellag 4.3 Modellag Som skabelon for modellaget benyttede vi os af flere velkendte teknikker (design mønstre) indenfor databasebrug fra objektorienterede sprog [2]. Compileren sørgede derfor for at indbygge disse teknikker i det modellag som blev genereret, og dermed blev modellaget specielt tilpasset den ønskede database. Da vi ønskede at gøre repræsentationen af data lettere for udvikleren, var vi primært på udkig efter designmønstre som kunne hjælpe med dette. Mønstrene skulle derfor kunne bidrage positivt indenfor CRUD operationer (opret, indlæs, gem og slet). Med mønstret Active Record laver man en klasse for hver tabel, som indeholder statiske metoder til at arbejde på tabellen, og instanser af tabellen svarer til en række i tabellen. Med dette mønster kunne vi gøre data fra tabellerne tilgængelige på en logisk måde, hvor vi lod properties på klasserne svare til kolonner på tabellerne, eller oversætte relationer fra tabellerne til referencer i objekterne. Mønstret pakker kommunikationen med databasen ind, og giver et modellag som er let at forstå for udvikleren [2]. Med mønstret Lazy Load venter man med at indlæse informationer til de rent faktisk skal bruges. Dette passede ret godt med at vi oversatte relationer til referencer, og dermed potentielt kunne ende ud med at skulle indlæse store mængder data grundet samhørighed imellem disse. Første gang referencerne blev efterspurgt blev de indlæst fra databasen, hvilket selvfølgelig gjorde denne operation en anelse langsommere, men til gengæld blev der ikke brugt tid i de tilfælde hvor referencerne ikke skulle bruges. Samlet set giver Lazy Load ikke øget indlæsningstid, selvom man bruger alle referencer, men til gengæld spares der indlæsningstid i de tilfælde hvor man ikke benytter referencerne. For at hjælpe udvikleren med at håndtere ændringer i den indlæste data benyttede vi eventmekanismen i C# som stort set svarer til mønstret Observer. Med denne mekanisme kunne udvikleren abonnere på specifikke hændelser, i vores tilfælde hvis et objekt eller en bestemt property på et objekt ændrede sig, eller hvis en liste med indlæste objekter ændrede sig. For at sikre at der ikke eksisterer flere objekter som skal repræsentere den samme mængde data, kan mønstret Identity map bruges. Mønstret fungerer ved at man vedligeholder en intern statisk liste i hver klasse, som indeholder alle de objekter som er indlæst fra databasen. Når et givent objekt skal indlæses fra databasen tjekkes denne liste først efter forekomst af objektet, og hvis det findes, 11

18 4.3 Modellag 4. Status for VDO returneres det allerede eksisterende objekt. På denne måde sikrer man at der kun findes ét objekt som tilsvarer en given række i den tilhørende tabel. Vi valgte desuden at implementere Identity map for listerne med søgeresultater, da dette både kunne nedsætte mængden af kommunikation med databasen, samt gøre det lettere at holde listerne opdateret med de objekter som svarer til søgekriterierne. Ved kun at tillade læsning fra listerne sikres det at de udelukkende indeholder de rette objekter. For at holde de indlæste objekter opdaterede valgte vi at implementere en mekanisme som skulle simulere samtidighed. Ved jævnligt at lave forespørgsler til databasen efter ændrede rækker, kunne vi opdatere de objekter som svarede til de ændrede rækker ud fra listen med indlæste objekter. Når ændringer blev gemt til databasen, ville andre klienter derfor selv sørge for at indlæse ændringerne. I kraft af den brugte event-mekanisme ville udvikleren derfor kunne reagere, når der indløb ændringer, udført på andre klienter. For at kunne implementere denne opdateringsmekanisme, var det vigtigt at der, for alle tabeller i databasen, blev oprettet en tabel som indeholdt data omkring ændringerne som blev udført. Denne tabel blev automatisk holdt opdateret igennem triggers på den oprindelige tabel, som sørgede for at indsætte den rette data. Ved at kombinere den oprindelige tabel med tabellen som indeholdt historikken, var det muligt kun at udtrække de ændrede rækker i tabellen, og dermed spare på mængden af data som klienterne skulle hente. 12

19 IIProblem 13

20

21 5 Eksperiment med prototype Da den primære del af dette projekt omhandler udvikling af DB Flow har det været vigtigt at inddrage forskellige former for tests til brug for den videre udvikling. Den oprindelige tilgang var at finde 2-3 industrielle brugere (dvs. softwareudviklere) som er vant til at benytte en relationel database til at skabe persistens, gerne på tværs af flere samtidige klienter. Overfor disse industrielle brugere ville jeg præsentere VDO prototypen, fremvise nogle af de centrale elementer, samt tage en diskussion om hvordan DB Flow skulle laves med dette som udgangspunkt. Hvis brugerne skulle udvise interesse for at teste enten prototypen VDO eller DB Flow efterhånden som udviklingen ville skride frem, havde dette været meget nyttigt. Desværre lykkedes det ikke for mig at finde virksomheder som var interesserede i et sådant samarbejde. Det er svært at sige helt prcæist hvorfor dette var tilfældet, men jeg gætter på en modvilje mod at bruge tid på noget man ikke ville være helt sikker på at profitere fra. En anden grund kan være at jeg til dels ikke fandt virksomheder som udvikler applikationer i C# eller de på anden vis ikke har haft behov som DB Flow dækker over. Udover de industrielle brugere ønskede jeg at få etableret et samarbejde med grupper af studerende på Aalborg Universitet, med et ønske om at de ville bruge prototypen som en del af den software de skulle udvikle i forbindelse med deres projekter. Det viste sig overordentlig svært at finde grupper som havde behov for at benytte en database som jeg kunne tilbyde. Efter at jeg havde sendt s og været rundt i grupperum for at præsentere rammerne som DB Flow ville tilbyde i sammenhæng med projektudvikling var jeg så heldig at en enkelt gruppe (i201ba) havde et udviklingsprojekt, hvor et framework til at kommunikere med databasen ville passe godt ind. Samarbejdet med denne gruppe vil blive beskrevet i det følgende afsnit. 15

22 5.1 Magic stats 5. Eksperiment med prototype 5.1 Magic stats Projektgruppen i201ba var en gruppe på informatikstudiet, hvilket betyder at deres fokus ikke ville ligge på den applikation som skulle udvikles. Deres primære fokus var lagt på brugerinddragelse i forbindelse med udviklingsmetoden SCRUM, og derfor var selve applikationen i stor grad et biprodukt. i201ba ville lave En webapplikation udviklet til, at administrere og vise statistikker af kampafviklinger, mellem spillere af kortspillet Magic The Gathering [4, s. 74]. Netop fordi fokus hos i201ba var på processen fremfor udviklingen af applikationen, passede det godt ind i deres planlægning med et værktøj som kunne tage sig af at håndtere persistens. i201ba indvilligede i at benytte prototypen VDO i deres projekt, velvidende at der kunne være uhensigtsmæssigheder med denne som følge af at den netop kun var en prototype. Desuden havde i201ba ikke umiddelbart nogen erfaring med at bruge en database og derfor heller ikke hvordan de skulle designe et databaseskema. En del af aftalen blev derfor også at de skitserede hvordan de kunne tænke sig deres modellag skulle se ud, hvorefter jeg lavede skemaet for dem. Dette var primært for at hjælpe dem i gang, så de hurtigt kunne komme i gang med at bruge prototypen og derved give mig tilbagemeldinger. Deres udkast til modellaget er vist i figur 5.1. Figur 5.1: Diagram som jeg lavede første databaseskema ud fra. i201ba havde fra starten planlagt at benytte MySQL som underliggende database, men da prototypen i stor grad var opbygget til udelukkende at virke med 16

23 5. Eksperiment med prototype 5.1 Magic stats MS SQL Server 2005 gav dette nogle problemer. Først prøvede jeg at tilpasse prototypen til MySQL, men måtte opgive da det indebar langt større ændringer i prototypen end tiden tillod. Heldigvis lykkedes det for i201ba at få adgang til en MS SQL Server Selvom dette også krævede en del arbejde, da der er væsentlige forskelle mellem version 2000 og 2005 (som prototypen var lavet til), lykkedes det at få værktøjet til at virke så i201ba kunne udvikle deres applikation. I starten gik det fint for i201ba med at udvikle vha. grænsefladen, men efterhånden som deres udvikling skred frem, fandt de flere graverende fejl i prototypen. I de fleste tilfælde lykkedes det for mig at rette fejlene så i201ba kunne fortsætte med deres udvikling, men i enkelte tilfælde var fejlene så gennemgribende i både opbygning af compiler og selve grænsefladen, at jeg måtte opgive at løse dem uden at skulle omskrive alt for store dele af prototypen. i201ba fandt måder at omgå problemerne på, som bla. omfattede flere referencer til den samme klasse (flere spillere tilknyttet et spil) hvor referencen skulle kunne være null. Derudover opstod der pludselig problemer med at indlæse samtlige elementer af en bestemt type, så i201ba løste i stedet dette ved at indlæse forskellige grupper af elementer, som tilsammen resulterede i samtlige elementer. Denne fejl hang sammen med deres brug af version 2000 af databasen, og blev derfor ikke fanget under deres første del af udviklingen, da denne skete med en lokal version Da gruppen fandt en løsning omkring problemet valgte jeg ikke at bruge tid på at løse dette problem, så jeg i stedet havde tid til at løse mere kritiske fejl. Samtidig med at jeg løste nogle af problemerne som i201ba stødte på, skabte jeg nye. Dette hang i stor grad sammen med den opbygning compileren til prototypen havde, som gjorde at det var let at lave ting som havde utilsigtede konsekvenser. Dette illustrerer i høj grad at en intern struktur i compileren bør være gearet til at understøtte muligheden for rettelser uden de store hovedbrud samt give mulighed for lettere at finde fejl når disse opstår. i201ba klagede dog på intet tidspunkt over dette, da de hele tiden havde forståelse for de problemer som kan opstå i forbindelse med produktudvikling, og dermed var de perfekte samarbejdspartnere i dette forløb. 17

24 5.1 Magic stats 5. Eksperiment med prototype 18

25 6 Evaluering af prototype og test Jeg vil i dette kapitel opsummere og evaluere VDO prototypen og test af denne. I de fleste tilfælde vil evalueringen hænge nært sammen med respons i forbindelse med test af prototypen, men der vil også være gange hvor jeg reflekterer over detaljer som jeg selv har bemærket. Samarbejdet med i201ba var meget givtigt, da gruppen stillede mange gode spørgsmål, som hjalp mig med at forbedre prototypen og gav idéer til DB Flow. I de tilfælde hvor jeg ikke var i stand til at komme med et velargumenteret svar, var jeg klar over at bevæggrunden ikke var i orden. Derudover har det været interessant at se frameworket afprøvet i forbindelse med en hjemmeside, en sammenhæng som slet ikke havde været med i overvejelserne da prototypen blev udviklet. Jeg har dog også lært at bare fordi man har en prototype som man har brugt til at afprøve og demonstrere noget funktionalitet, er det ikke det samme som at man har en prototype som er klar til at blive afprøvet på mulige brugere. Selvom det i dette tilfælde gik godt, var der mange problemer som kunne have skræmt brugerne væk fra samarbejdet. Det er dog umiddelbart svært at gøre noget ved dette, så man bør nok i stedet overveje forskellige grupper af testbrugere, opdelt efter hvor fleksible de vil være overfor fejl i prototypen. I et tilfælde som dette, hvor brugerne selv arbejder på en form for prototype, vil brugerne være mere åbne overfor alternative løsninger, sammenlignet med brugere som arbejder på en applikation som de skal tjene på så hurtigt som muligt. På den brugsmæssige front af compileren lærte jeg også en hel del, da jeg sjældent fik særlig meget ud af de tilbagemeldinger i201ba kunne give når de stødte på en fejl, selvom de udførligt beskrev hvordan den var opstået. Jeg blev derfor nødt til at udføre store mængder manuel fejlfinding, som ikke altid var lige let. Dette hang i stor grad sammen med at fejlene først blev fanget når der 19

26 6. Evaluering af prototype og test oversættedes fra den genererede kode til den dll-fil som skulle være compilerens resultat, og derfor var det C# compileren, og dermed ikke direkte en del af vores compiler, som fandt fejlen. Dette gjorde at jeg først var nødt til at se hvilken fejl det drejede sig om i den genererede C# kode, for derefter at finde ud af hvorfor denne kode var blevet genereret, inden fejlen kunne blive rettet. Ofte var det et større puslespil at få det hele til at virke, uden samtidig at ødelægge noget andet. i201ba har efterfølgende givet udtryk for at de har været glade for samarbejdet, da de mener det har sparet dem for en hel del arbejde. Desuden fik jeg ros for at reagere hurtigt når de stødte på kritiske fejl, også selvom det ikke altid lykkedes at løse disse. Til den hjemmeside som i201ba udviklede, havde de behov for at håndtere forskellige typer af kampe til magic spillet, men grundet begrænsningerne i VDO havde de brugt én klasse til at håndtere dem alle. Dette var ikke en optimal løsning, hvorfor de udviste stor interesse for indførsel af abstraktioner, hvor flere klasser kunne have en fælles superklasse, indeholdende generel funktionalitet. Den generelle brug af compileren var noget som i201ba synes der kunne arbejdes meget med, da de ofte skiftede mellem at køre compileren op mod deres testdatabase og den database som hørte til deres webhotel, og dermed skulle ændre i kildekoden for at dette kunne lade sig gøre. Selvom stedet hvor dette skulle ændres var i en enkelt fil, var de interesserede i en compiler de kunne bruge direkte, uden at skulle lave specielle tilpasninger hver gang de ændrede databaseværten. I VDO prototypen var det svært at skabe et overblik over det modellag som blev genereret af compileren, og det var kun muligt at rette deri ved at ændre på selve databaseskemaet. Da måden der navngives på i en database ofte afviger fra måden man navngiver på i opbygning af klasser, både i forhold til klasser og properties, kunne man godt ønske sig en mulighed for at ændre på hvordan modellaget navngives af compileren. 20

27 7 Analyse I dette kapitel vil jeg beskrive analysen som ligger til grund for udviklingen og videre design af DB Flow. Jeg vil fokusere på hvilke områder som er vigtigst, med udgangspunkt i erfaringer indsamlet i forbindelse med brug og test af prototypen VDO. Analysen vil derfor starte med at definere hvad DB Flow skal kunne, for derved at kunne arbejde videre med de gode dele af prototypen, men samtidig frasortere de dårlige aspekter. 7.1 Formål og systemdefinition Formålet med DB Flow er at gøre det lettere for en systemudvikler at benytte en relationel database fra C#. Dette skal ske for at opfylde følgende mål: Systemudvikleren skal slippe for at udføre dobbelt bogføring, hvor ændringer manuelt skal indføres flere forskellige steder. Det skal ikke være nødvendigt for systemudvikleren at have indgående kendskab til brugen af en relationel database. Modellaget skal være bygget på en måde så systemudvikleren kan benytte velkendte objektorienterede løsningsmodeller. Det skal være muligt for systemudvikleren at udføre ønskede ændringer direkte på modellaget. Systemudvikleren skal have mulighed for at kunne arbejde videre med tidligere ændringer til modellaget. DB Flow skal automatisere så stor en del af kommunikationen med databasen som muligt. 21

28 7.2 Målgruppe 7. Analyse Systemudvikleren skal være fri for at tage hensyn til forskellige opbygninger på tværs af databasesystemer. DB Flow skal sørge for at løse eventuelle uoverensstemmelser mellem datatyper i databasen og C#. DB Flow skal sikre at data som er indlæst fra databasen holdes opdateret i forhold til ændringer udført af andre klienter. DB Flow skal gøre det let for systemudvikleren at håndtere ændringer til indlæst data, som følge af ændringer udført af andre klienter. DB Flow skal med andre ord fungere som en compiler, som indlæser et databaseskema og ud fra dette skaber en grænseflade indeholdende et modellag. Modellaget skal gøre det muligt at tilgå den relationelle database på en objektorienteret facon. Compileren skal bistå systemudvikleren i at lave modellaget og derved give mere tid til udviklingsarbejde, samtidig med at den skal minimere behovet for at vedligeholde konfiguration. 7.2 Målgruppe DB Flow målrettes efter systemudviklere som er vant til at arbejde med objektorienteret udvikling, men som ikke nødvendigvis har indgående kendskab til brug af en database. 7.3 Database En systemudvikler vil ikke altid vælge en database ud fra præferencer, men i lige så stor grad ud fra hvilke systemer der stilles til rådighed. Af hensyn til mulig udbredelse af DB Flow vil det derfor være vigtigt at understøtte de bredeste spektre af udviklingsmiljøer. DB Flow skal som udgangspunkt indeholde understøttelse for både MS SQL Server og MySQL. Da det kan forventes at en systemudvikler netop vælger den underliggende database udfra tilgængelige muligheder, kan dette også skifte fra projekt til projekt. Grundet dette er det derfor vigtgt at der ikke er nogen forskel på hvordan systemudvikleren skal bruge det genererede modellag, og dermed ikke skal tage hensyn til hvilken underliggende database som bruges. Dette er vigtigt hvis en systemudvikler skal blive glad for at bruge DB Flow, da denne abstraktion vil gøre det lettere at udvikle på tværs af flere forskellige systemer, da de forskellige modellag vil blive bygget omkring den samme skabelon. 22

29 7. Analyse 7.4 Compiler Det bør ikke være nødvendigt for systemudvikleren at håndtere forbindelsen til databasen, udover at skabe denne inden første behov for kommunikation med databasen, idet systemudvikleren så kan fokusere på udviklingen af sit system. Når et databaseskema er klargjort til brug med DB Flow, skal en klient som benytter et DB Flow-skabt modellag kunne fungere sideløbende med tidligere klienter til databaseskemaet. Dette betyder også at klienter som benytter DB Flow stadig skal kunne modtage ændringer fra andre klienter, selvom ændringer skulle være indført af tidligere klienter. 7.4 Compiler DB Flow compileren skal fungere efter et tredelt princip, hvor der først indlæses informationer fra databasen, herefter skal brugeren have mulighed for at kunne ændre i modellaget, og til sidst skal nødvendige ændringer til databasen udføres, samtidig med at modellaget skal genereres og serveres for brugeren som en færdig dll-fil. Når informationerne indlæses fra databasen, er det vigtigt at den interne datarepræsentation er tilpas fleksibel, så det er muligt for brugeren at udføre ændringer til modellaget, inden det genereres. Alle nødvendige modifikationer til databasens skema skal compileren automatisk stå for, så brugeren ikke behøver at bekymre sig om dette. Disse modifikationer skal bla. sørge for at tidligere klienter kan fortsætte med at bruge databasen. 7.5 Brugergrænseflade For at sikre brugen af DB Flow er det vigtigt at compileren har en brugergrænseflade som er brugervenlig. Grundet målgruppen, skal det tilstræbes at compileren benytter objektorienterede termer fremfor termer som har rødder i databaseverdenen. Brugergrænsefladen skal være visuelt orienteret, og, så vidt muligt, illustrere modellaget på en genkendelig måde for systemudvikleren som bruger compileren. Denne visualisering bør tage udgangspunkt i Unified Modelling Language (UML), da en systemudvikler som er vant til at arbejde med objektorienteret udvikling vil være vant til at benytte denne til at illustrere klassediagrammer. Brugeren skal desuden have mulighed for at redigere direkte i modellaget, og i de tilfælde hvor ændringerne vedrører selve databasens skema, skal det være let at gemme disse ændringer. For den del af brugergrænsefladen som ikke omhandler visualisering af modellaget, skal disse tilnærmes at ligne dialogvinduer fra tilsvarende programmer. 23

30 7.6 Modellag 7. Analyse Når compileren arbejder med data, enten ved at udtrække information fra databasen eller når modellaget genereres, skal det være muligt for brugeren at følge med i processen igennem et statusvindue. Statusvinduet bør indeholde alle relevante informationer om hvad der sker, så brugeren kan følge med i hvad der sker, men også så det er lettere at vide på hvilket tidspunkt en given fejl skulle opstå. 7.6 Modellag Som med prototypen skal modellaget, der genereres, laves med udgangspunkt i passende designmønstre. Disse mønstre er Active Record som definerer de ydre rammer for klasserne, Lazy Load som minimerer kommunikationen med databasen, Identity Map som sikrer at der højst findes ét objekt som repræsenterer en given række i en tabel, samt Observer som giver mulighed for at lade brugeren af modellaget udføre bestemte operationer når data ændrer sig. Modellaget skal stå for at holde indlæste objekter opdaterede i forhold til databasen, og derved simulere samtidighed i forhold til andre klienter som bruger den samme database. Hvis et lokalt objekt er blevet ændret, skal det ikke overskrives med ændringer udført af andre klienter, og det skal heller ikke være muligt ubevidst at overskrive ændringer fra andre klienter. På de klasser som genereres skal der være statiske metoder til at indlæse klassens elementer, dvs. søgninger i den tilhørende tabel. Der skal som minimum være mulighed for at indlæse alle elementer, ud fra de eksakte værdier for de berørte properties samt specielle muligheder for bestemte typer. For strengproperties skal det være muligt at søge ud fra om strengen indeholder, starter med eller slutter med en given streng, og for numeriske typer og datotyper skal det være muligt at kunne søge ud fra et givet interval. Den liste med søgeresultater som brugeren får returneret fra søgemetoden, skal automatisk holdes opdateret hvis nye objekter skulle passe sammen med søgekriterierne, eller objekter i listen ophører med at opfylde kriterierne. For hver kolonne i den tilsvarende tabel, skal der på klassen være en tilgængelig property med kolonnens værdi. I de tilfælde hvor kolonnen har relation til en anden tabel, skal den tilgængelige property være en reference til objektet svarende til rækken som relationen peger på. I de tilfælde hvor en klasse refereres fra andre klasser, skal det være muligt at få en liste for hver af disse relationer, indeholdende de refererende objekter. På modellagets klasser skal der også være instansmetoder der håndterer specifikke databaserelaterede operationer som at gemme, slette og genopfriske objek- 24

31 7. Analyse 7.6 Modellag tet. Genopfriskningen kan bruges til at overskrive lokale ændringer til et objekt, med de data som findes i databasen. Bevæggrunden for at have eksplicitte metoder til databaserelaterede operationer, hænger sammen med at man ikke nødvendigvis ønsker at gemme et objekt i databasen så snart det er oprettet, og uden en metode til at slette, vil det ikke være muligt at nedlægge en række, da man i C# ikke selv tager sig af at slette objekter i hukommelsen, og dermed ikke har mulighed for at nedlægge et objekt. På alle tilgængelige dele af modellagets klasser skal der være dokumentation, som hjælper brugeren når modellaget bruges. Dokumentationen skal fortælle i hvilke tilfælde der kan være risiko for at der kastes exceptions samt hvilke dele af databasen som fx. en property svarer til. For de operationer som har indflydelse på databasens indhold skal dette fremstå af dokumentationen Nedarvning I de tilfælde hvor klasserne til modellaget har egenskaber til fælles, skal det være muligt at samle disse under en fælles superklasse, på samme måde som når man selv koder klasserne. Det skal være muligt at definere en abstrakt superklasse for en eller flere klasser som hører til modellaget. For de properties som klasserne skulle have til fælles, skal det være muligt at placere disse på den abstrakte klasse. For at properties skal kunne placeres på den abstrakte superklasse skal alle klasserne under denne have properties af præcis samme type. For at udnytte at klasserne kan samles under en fælles abstrakt superklasse, skal det på denne være muligt at søge ud fra de properties som findes herpå. Resultatet af søgningen skal derfor indeholde alle klasser under superklassen som overholder de givne søgekriterier. Det er vigtigt at det ikke kræver ændringer til databasens skema at indføre denne generalisering gennem en fælles superklasse, da dette vil bryde med princippet om at ældre klienter fortsat skal kunne operere mod databasen. 25

32 7.6 Modellag 7. Analyse 26

33 8 Problemformulering Jeg vil i denne rapport se på hvordan der kan indføres abstrakte superklasser med generelle egenskaber for flere af de genererede klasser, herunder hvad der kræves for at gøre dette muligt. I denne forbindelse vil jeg lægge stor vægt på hvordan dette klares uden at bryde reglerne for relationelt design. Jeg vil desuden lægge stor vægt på hvilke tiltag som skal tages for at øge brugervenligheden af selve compileren, og herunder se på hvordan det gøres så let for brugeren som muligt at administrere de klasser som genereres til modellaget. Derudover vil jeg fokusere på hvad der skal til for at den interne struktur i compileren både vil give understøttelse for abstrakte klasser samt gøre compileren mere fleksibel overfor nødvendige ændringer i forbindelse med brugergrænsefladen. 27

34 28 8. Problemformulering

35 III Produktudvikling 29

36

37 9 Design Jeg vil i dette kapitel gennemgå hvordan DB Flow bliver designet, primært med fokus på compilerens opbygning. Dette vil beskrive opbygningen af DB Flow compileren samt det tilhørende framework. Herefter vil jeg i næste kapitel afprøve DB Flow i en sammenhæng som tilsvarer en mulig situation for brugen, hvorefter jeg vil slutte af med at evlauere på hvor nyttig jeg synes DB Flow er blevet. 9.1 Compiler For at muliggøre de mange krav som er fremført i analysen, er det vigtigt at den interne datastruktur i compileren er så fleksibel som mulig. I en almindelig compiler, som oversætter fra kildekode til maskinekode, bliver kildekoden omsat til et abstrakt syntaks træ (AST), hvor alle informationer gemmes som noder på træet. Ved samtidig at benytte designmønstret visitor er det muligt at traversere træet på en simpel måde. Da AST strukturen fungerer godt og samtidig er meget fleksibel, skal den danne grundlag for den interne datastruktur i DB Flow-compileren. Da træet beskriver databasen, har jeg valgt at kalde det for et Database Description Tree (DDT). Træstrukturen skal opbygges logisk, så tabeller hører under en databasenode, kolonner under en tabelnode og så fremdeles. Når DDT er blevet opbygget ud fra databasens skema, er det muligt at udføre ændringer på træet. Dette indebærer at det er muligt at gemme ændringer til modellaget til senere brug, da dette så kan indlæses og bruges til at modificere det indlæste DDT. På denne måde er det muligt at ændre navne på properties og klasser uden at ændre på databasens skema. Opbygningen af det DDT som skal danne grundlag for compilerens arbejde, skal derfor ske gennem følgende trin: Indlæse tabeller fra databasen. Indlæse kolonner for tabeller. 31

38 9.2 Nedarvning 9. Design Opbygge referencer mellem kolonner for relationer. Indlæse triggers for tabeller. Indlæse indstillinger for den givne database. Modificere DDT ud fra de indlæste indstillinger. Da det DDT tager udgangspunkt i databasen, og det først er compileren som oversætter dette til klasser med properties, skal der indføres et begreb som tilsvarer abstrakte klasser og properties tilhørende disse. For at holde terminologien indenfor databasen vil vi derfor indføre virtuelle tabeller og virtuelle kolonner, som skal oversættes til hhv. abstrakte klasser og properties på abstrakte klasser. Tabelnoder til klasser som hører under en abstrakt superklasse, skal derfor placeres under den tilsvarende virtuelle tabelnode. Kodegenereringen skal fungere ved at databasens rodnode i DDT tager imod en visitor, som traverserer igennem træet og ud fra de noder den støder på, udfører forskellige operationer. Et af principperne ved at bruge Visitor pattern er at hver enkelt visitor har en meget specifik opgave at udfylde, og den enkelte visitor vil derfor ofte benytte sig af andre visitors til underopgaver. På denne måde kan de meget specifikke visitors bruges i mange forskellige sammenhænge, og dermed nedbringe mængden af kode til selve compileren som skal vedligeholdes. Hver enkelt visitor returnerer en tekststreng dertil hvor den blev kaldt fra, og den første visitor vil derfor returnere hele koden for modellaget. Når koden for hele modellaget er lavet, leveres dette videre til en intern del af C# frameworket, som sørger for at oversætte dette til den dll fil som skal være resultatet af compilerprocessen. 9.2 Nedarvning Som fremført i analysen skal det være muligt at arbejde med generaliseringer på tværs af klasser ved hjælp af tilknytning til en abstrakt superklasse, med mulighed for at have properties til fælles igennem denne. Problemet med at overføre et nedarvningshierarki som vist på figur 9.1 er at databasen ikke har en tabeltype som vil være ækvivalent til den abstrakte klasse. Derudover er det ikke muligt at beskrive en hierarkisk opbygning igennem tabeller i den relationelle database. I artiklen Mapping Objects to Tables [3] nævnes der tre løsninger på dette problem, enten ved at have én tabel for hvert nedarvningshierarki, én tabel for hver klasse, eller én tabel for hver sti i nedarvningshierarkiet, dvs. en tabel for hver klasse som det skal være muligt at oprette instanser af. 32

39 9. Design 9.2 Nedarvning Figur 9.1: Nedarvningshierarki med klasserne ErhvervsKunde og PrivatKunde under Kunde. I løsningen med én tabel til hele nedarvningshierarkiet er der både problemer med at det bliver nødvendigt at tillade null-værdier for de properties som ikke er med i alle de ønskede klasser, selvom det måske ikke er ønskværdigt at null skal være tilladt i den klasse som feltet tilhører. Desuden vil de ekstra felter fylde unødvendigt i databasen. Det vægtigste argument imod denne løsning er dog det faktum at det ikke u- middelbart er muligt at genkende hvilken objekttype en bestemt række i en tabel skal oversættes til, uden at indføre et felt som fortæller dette. Da en af fordelene ved DB Flow skal være at det skal kunne køre sideløbende med andre systemer, er det vigtigt at systemet ikke er afhængige af at der skal indsættes bestemte værdier for at gøre det muligt at tolke informationerne korrekt. Jeg vil derfor helt se bort fra at have et nedarvningshierarki modelleret ved én tabel i databasen. Løsningen med at at have én tabel for hver klasse i nedarvningshierarkiet virker ved første øjekast oplagt, men der er også problemer ved denne løsning sammenholdt med at DB Flow skal kunne fungere sideløbende med andre systemer som bruger den samme database. Med denne løsning er der nemlig intet til hinder for at to forskellige kunder kan dele nogle informationer (Navn og Adresse) grundet måden som relationer fungerer i databasen. Alene af denne grund fravælger jeg denne løsningsform, da jeg er meget interesseret i at den underliggende database ikke kan indeholde data som bryder med den ønskede struktur. Selvom dette kan løses ved at indføre de rette constraints i databasen, vil det samtidig kræve at der tilføjes tabeller for de abstrakte klasser som indføres, og der skal flyttes kolonner fra de tabeller som svarer til klasserne under den abstrakte superklasse, til de tabeller svarende til superklassen. 33

40 9.3 Grafisk brugergrænseflade 9. Design Med sidste løsning, hvor hver sti i nedarvningshierarkiet er modelleret ved én tabel, vil hver klasse i nedarvningshierarkiet være repræsenteret med sin egen tabel, og hver af disse tabeller vil dermed indeholde alle felter, også dem som hører til klasser højere oppe i nedarvningshierarkiet (superklasser). Med denne løsning vil det dermed ikke være muligt at oprette data i databasen som ikke er i overensstemmelse med modellen, og kan derfor uden problemer oversættes til objekter. For at simplificere implementeringen af denne løsningsmodel i DB Flow, vil jeg udelukkende fokusere på at repræsentere klasserne nederst i nedarvningshierarkiet igennem tabeller, hvilket betyder at alle superklasser vil være abstrakte. Selvom denne løsning umiddelbart kan løse en del problemer, giver den samtidig andre problemer, som kan være lidt mere besværlige at løse. Hvis vi skulle have brug for at have en reference til en Kunde-klasse, dvs. at det både kan være til en ErhvervsKunde og en PrivatKunde, er det ikke umiddelbart muligt at løse dette i databasens tilhørende tabeller, da en relation skal være fra én tabel til en anden. Jeg vil på nuværende tidspunkt ikke se på hvordan dette problem kan løses. 9.3 Grafisk brugergrænseflade Brugergrænsefladen til DB Flow-compileren skal gøre processen med at generere det specialiserede modellag så simpel som muligt, og gøre det let for brugeren at arbejde med tilpasning af modellaget. Da netop brugergrænsefladen er noget jeg lægger stor vægt på, vil jeg i de følgende afsnit gennemgå de væsentligste dele af brugergrænsefladen for compileren Opret forbindelse til database Da dialogvinduer i DB Flow i vid udstrækning tilstræbes at minde om tilsvarende fra andre programmer, vil dialogvinduet til at oprette en forbindelse til database blive baseret på forbindelsesdialogen til Microsoft SQL Server Management Studio, vist på figur 9.2. Da der skal være mulighed for at benytte forskellige underliggende databaser, skal brugeren derfor også have mulighed for at vælge imellem de understøttede typer. For at minimere risikoen for fejltastninger, skal brugeren ikke selv angive navnet på hvilken database som skal benyttes, men i stedet vælge blandt dem som den angivne bruger har læseret til. Dialogvinduet til at forbinde til en database for DB Flow er vist på figur

41 9. Design 9.3 Grafisk brugergrænseflade Figur 9.2: Forbindelsesdialog til Microsoft SQL Server Management Studio. Figur 9.3: Forbindelsesdialog til DB Flow compileren. 35

42 9.3 Grafisk brugergrænseflade 9. Design Dialogvinduet giver også mulighed for at angive en konfigurationsfil til den valgte database, som indeholder modifikationer i forhold til databasens skema, herunder ændringer til navne på klasser og properties, samt definitioner på abstrakte superklasser og klasser som hører under disse. Brugeren har endvidere mulighed for at vælge at brugernavn og filnavnet skal huskes af DB Flow Statusvindue Statusvinduet skal give brugeren mulighed for at følge med i hvad compileren foretager sig, både under udtrækning af data og efterfølgende når modellaget genereres. Statusvinduet kan se ud som vist på figur 9.4. Figur 9.4: Statusdialog til DB Flow compileren. Det er vigtigt at selve compilerens funktionalitet ikke er knyttet til statusvinduet, dvs. compileren skal ikke være afhængig af om statusvinduet vises eller ej. Dermed bør statusvinduet køre i en seperat tråd i forhold til compileren, og kommunikationen bør ske igennem en logningsmekanisme. Dermed vil det også være muligt at udskifte statusvinduet uden at ændre på andre dele af compileren Visualisering af modellag I det programvindue som skal visualisere modellaget, og dermed give brugeren mulighed for at tilføje ændringer, skal det være muligt at se klasserne på en 36

43 9. Design 9.3 Grafisk brugergrænseflade genkendelig måde. Da UML er den mest udbredte måde, skal dette være udgangspunktet for visualiseringen. På figur 9.5 kan det ses hvordan dette vindue overordnet bør se ud, med mulighed for at gemme ændringerne til både database og konfigurationsfil, samt generere modellaget til brug. Figur 9.5: Vindue med visualisering af modellag. Figuren viser også hvordan tabellernes relationer oversættes til aggregeringer og associationer, samt hvordan det er let at se det indbyrdes forhold mellem klasser og de tilhørende abstrakte superklasser. De anførte mangfoldigheder behøver ikke at blive vist, men kan til dels hjælpe med at skabe overblik i forhold til klassernes indbyrdes relationer. Da klasser som refereres fra andre klasser vil indeholde en liste over disse, vil der i praksis udelukkende være aggregeringer, og dermed vil mangfoldighederne ikke tilføre information som ikke allerede findes. For at lave en ny relation mellem to klasser, skal titlen fra klassen som der skal refereres til, trækkes over på den klasse som skal referere dertil. Hvis der allerede findes en relation imellem de to klasser, skal de automatisk tildeles nummerering, med mulighed for at brugeren kan omdøbe navnet på den property som hører til referencen. Ved at højreklikke på en klasse skal det være muligt at vælge handlinger vedrørende denne, fx. at redigere den eller tilføje en property, i en menu som skal komme frem. Ved at højreklikke på en property skal det være muligt at vælge handlinger 37