Mönsterspråk för hantering av konfigurationsdata i Java

Institutionen för datavetenskap

Department of Computer and Information Science

Examensarbete

Mönsterspråk för hantering av

konfigurationsdata i Java

Helena Ferry

LIU-IDA/LITH-EX-A--08/041--SE

2008-10-02

Linköpings universitet Institutionen för datavetenskap

Examensarbete

Mönsterspråk för hantering av

konfigurationsdata i Java

Helena Ferry

LIU-IDA/LITH-EX-A--08/041--SE

2008-10-02

Handledare: Jonas Liljenfeldt Examinator: Lars Degerstedt

Sammanfattning

Genom litteraturstudier samt praktiskt arbete med f¨orb¨attringar av programvaran File Secure har ett antal l¨ampliga designm¨onster f¨or konfigurationshantering i Java identifierats och applicerats. Den typ av konfigurationshantering som h¨ar avses innefattar inl¨asning fr˚an en databas till en objektrepresentation, samt ett grafiskt gr¨anssnitt som l˚ater anv¨andaren modifiera datat. Det antas att m¨angden data ¨ar f¨orh˚allandevis liten, vilket har gett upphov till vissa f¨orenklingar.

Resultatet av arbetet presenteras i form av ett m¨onsterspr˚ak f¨or konfigurations-hantering, innefattande designm¨onstren Domain Model, Active Record och det befintliga m¨onsterspr˚aket Model - View - Controller. Detta kan appliceras i m˚anga olika sorters system.

Nyckelord: M¨onsterspr˚ak, designm¨onster, Java, konfiguration, MVC, Domain Model, Active Record, databas, objektrepresentation

Inneh˚

all

1 Introduktion 7

1.1 Uppdragsgivare och produkt . . . 7

1.2 Konfigurationshantering . . . 8 1.3 M˚al . . . 9 1.4 Metod . . . 9 1.5 Rapportens struktur . . . 10 1.6 Termer . . . 10 2 Designm¨onster 12 2.1 Nyttan av designm¨onster . . . 12

2.2 Att beskriva designm¨onster . . . 13

2.3 Domain Model . . . 14

2.4 Active Record . . . 15

2.5 Model – View – Controller . . . 16

3 File Secure 19 3.1 Anv¨andarscenario . . . 20

3.2 Gr¨anssnitt och funktioner . . . 22

3.3 Arkitektur . . . 23

3.4 Liknande system . . . 27

4 Utvidgning av File Secure 29 4.1 Funktionella krav . . . 29

4.2 Uppdaterat anv¨andarscenario . . . 31

5 M¨onsterspr˚ak f¨or konfigurationshantering 41 5.1 Datamodellering . . . 43 5.2 Anv¨andargr¨anssnitt . . . 46 5.3 Praktiska r˚ad vid till¨ampning . . . 47

6 Diskussion 50

6.1 M¨onsterspr˚ak f¨or konfigurationshantering . . . 50 6.2 File Secure och dess framtid . . . 52

Figurer

1.1 File Secure ¨oversiktsskiss . . . 8

2.1 Active Record . . . 15

2.2 Klassernas samband enligt MVC . . . 16

3.1 Anv¨andarscenario . . . 21

3.2 Menyn f¨or File Secure . . . 22

3.3 Systemskiss, installation och konfiguration . . . 25

3.4 Systemskiss, bakgrundstj¨anst . . . 26

4.1 Valda filer hanteras . . . 32

4.2 Katalogstruktur . . . 34

4.3 ER-diagram f¨or konfigurationsdatabasen . . . 37

4.4 Undantagsm¨onster . . . 38

4.5 Kataloginst¨allningar . . . 40

5.1 M¨onsterspr˚ak f¨or konfigurationshantering . . . 42

Tabeller

1.1 Termer . . . 11

4.1 JavaSVN-metoder f¨or Subversion-kommandon . . . 36

5.1 Applicerade designm¨onster per delproblem . . . 41

5.2 Alternativ f¨or databasmodellering . . . 44

5.3 Alternativ f¨or databaskoppling . . . 45

Kapitel 1

Introduktion

Att anv¨anda designm¨onster inneb¨ar att dra nytta av erfarna utvecklares tidigare erfarenheter genom att efterh¨arma dokumenterade generella l¨osningar. Detta ¨ar intressant vid all programutveckling och applicerbara designm¨onster kan hittas f¨or n¨ara nog vilken till¨ampning som helst.

Ett m¨onsterspr˚ak ¨ar en samling designm¨onster som grupperats ihop f¨or att tillsammans uppn˚a ett st¨orre syfte.

Denna rapport presenterar ett m¨onsterspr˚ak som fungerar som en modul f¨or konfigurationshantering. M¨onsterspr˚aket har vuxit fram under vidareutveckling av programvaran File Secure.

1.1

Uppdragsgivare och produkt

Uppdragsgivare och handledare f¨or examensarbetet ¨ar Jonas Liljenfeldt, som tagit fram en f¨orsta version av produkten File Secure. File Secure ¨ar ett program utvecklat i Java med syftet att tillhandah˚alla automatisk s¨akerhetskopiering av filer fr˚an en klient till en central server med versionshantering. Figur 1.1 visar en ¨

oversiktsskiss med en klientdator som har en krypterad anslutning ¨over internet mot File Secures server. Projektet har bedrivits av Jonas Liljenfeldt p˚a hans fritid och tankar har funnits p˚a att i framtiden utveckla File Secure till en kommersiell produkt. Mer om File Secure finns att l¨asa i kapitel 3.

Figur 1.1: File Secure ¨oversiktsskiss

1.2

Konfigurationshantering

Den typ av konfigurationshantering som behandlas i denna rapport best˚ar av tv˚a delar:

1. Inl¨asning av konfigurationsdata fr˚an en databas till en objektrepresentation. 2. Grafiskt gr¨anssnitt f¨or att modifiera datat.

Med konfigurationsdata menas h¨ar data f¨or de inst¨allningar anv¨andaren v¨aljer att g¨ora i programmet. I fallet File Secure g¨aller det fr¨amst data om de kataloger som programmet ska bevaka och s¨akerhetskopiera.

Konfigurationshantering kan betraktas som en begr¨ansning av det st¨orre omr˚adet modellering och modifiering av databasdata. Rapportens resultat kan sannolikt appliceras ¨aven i andra typer av databasl¨osningar, men utg˚angspunkten ¨

ar begr¨ansningen konfigurationshantering.

Utg˚angspunkt f¨or begr¨ansningen ¨ar att konfigurationsdata k¨annetecknas av f¨oljande:

1. M¨angden data ¨ar liten - ett system beh¨over i regel ett f˚atal konfigura-tionsparametrar.

2. Programmet kan inte k¨oras tillfredsst¨allande utan datat (i mycket enkla fall kan det vara m¨ojligt att falla tillbaka p˚a standardv¨arden).

3. Datat m˚aste lagras mellan k¨orningar av programmet.

5. Anv¨andaren kan n¨ar som helst modifiera konfigurationsdatat via ett grafiskt gr¨anssnitt.

Denna rapport presenterar ett s¨att att ˚astadkomma en konfigurationshantering med hj¨alp av etablerade designm¨onster som sammanst¨alls i ett m¨onsterspr˚ak.

1.3

M˚

al

Rapportens m˚al ¨ar att presentera ett l¨ampligt m¨onsterspr˚ak f¨or konfigurations-hantering i Java. D˚a konfigurationshantering ¨ar en begr¨ansning av databas-modellering b¨or m¨onsterspr˚aket rimligtvis vara en f¨orenkling av mer avancerade strategier f¨or detta. Att applicera avancerade m¨onster i enkla till¨ampningar kan verka avskr¨ackande, varf¨or m¨onsterspr˚aket kan ge enklare tillg˚ang till de f¨ordelar designm¨onster medf¨or.

Vidare ska m¨onstret kunna appliceras i system liknande File Secure. File Secure tillhandah˚aller automatiska s¨akerhetskopieringar och versionshantering, men d˚a m¨onsterspr˚aket endast r¨or den konfigurationshanterande delen inneb¨ar ett system liknande File Secure fr¨amst ett Java-utvecklat system som har en konfigurations-hantering motsvarande den som beskrevs i kapitel 1.2. Detta kan st¨amma in p˚a m˚anga olika typer av system, oavsett vilken tj¨anst de tillhandah˚aller.

1.4

Metod

Programvaran File Secure har studerats och f¨orb¨attrats med hj¨alp av befintliga designm¨onster. Utifr˚an detta har observerats hur designm¨onster kommit till nytta i olika stadier i utvecklingsprocessen och resultatet har sammanst¨allts i form av ett m¨onsterspr˚ak.

Arbetet inleddes med att programvaran testades och utv¨arderades. F¨orslag till f¨orb¨attringar diskuterades med handledaren och slutsatserna formulerades i ett antal funktionella krav (se kapitel 4.1). F¨or att realisera dessa krav gjordes f¨orst en litteraturstudie kring designm¨onster. Relevanta designm¨onster identifierades och de som bed¨omdes mest l¨ampade applicerades, ibland med modifikationer.

Det praktiska arbetet mynnade ut i en fungerande modul f¨or att hantera data om de kataloger File Secure bevakar, samt andra inst¨allningar. P˚a ett mer teoretiskt plan kunde l¨osningen generaliseras till ett m¨onsterspr˚ak f¨or konfigurationshantering.

1.5

Rapportens struktur

I detta introduktionskapitel presenteras f¨oruts¨attningarna f¨or arbetet: uppdrags-givare, avgr¨ansningar, m˚al, metod, rapportstruktur och termer. Kapitel 2 ¨ar en genomg˚ang av begreppet designm¨onster och av de designm¨onster som applicerats i projektet. I kapitel 3 presenteras File Secure som det s˚ag ut innan examens-arbetet och i kapitel 4 beskrivs de ¨andringar som gjorts. I kapitel 5 presenteras det m¨onsterspr˚ak f¨or hantering av konfigurationsdata som arbetet lett fram till. Rapporten avslutas med en diskussion i kapitel 6.

1.6

Termer

M˚anga av de termer som anv¨ands i en rapport som denna ¨ar mer k¨anda i sina engelska varianter ¨an p˚a svenska. M˚als¨attningen f¨or rapporten ¨ar att anv¨anda svenska termer i den m˚an det ¨ar m¨ojligt, med undantag f¨or de-signm¨onster som har inarbetade och sv˚ar¨oversatta engelska namn. Tabell 1.1 listar n˚agra av de vanligaste termerna p˚a b˚ade svenska och engelska.

Svenska Engelska arbetskatalog working copy centralkatalog repository checka in commit

designm¨onster design pattern m¨onsterspr˚ak pattern language s¨akerhetskopiering backup

undantagsm¨onster ignore pattern versionshantering revision control

Kapitel 2

Designm¨

onster

Begreppet designm¨onster myntades av en byggnadsarkitekt vid namn Christopher Alexander, som f¨orespr˚akade att dra l¨ardom av tidigare anv¨anda l¨osningar f¨or att ˚atg¨arda vanligt f¨orekommande problem. F¨or honom handlade det visserligen prim¨art om att designa hus och planera st¨ader, men resonemanget kunde l¨att generaliseras till att handla om n¨astan vad som helst. Ett designm¨onster ¨ar helt enkelt ett recept f¨or att l¨osa en uppgift och det kan g¨alla konstruktion av program-varor lika v¨al som byggnader. [3]

Ett designm¨onster uppst˚ar i regel inte av att n˚agon ”hittar p˚a” det, utan det handlar snarare om att se m¨onster i anv¨anda l¨osningar och identifiera de-signm¨onster i form av generaliserade beskrivningar av standardl¨osningarna.

En gruppering av flera designm¨onster som tillsammans uppfyller ett m˚al kallas f¨or ett m¨onsterspr˚ak.

2.1

Nyttan av designm¨

onster

I alla stadier av utvecklingsprocessen kan designm¨onster utg¨ora ett stort st¨od f¨or utvecklaren och bidra till att bra l¨osningar uppn˚as. I planeringsfasen ger studier av designm¨onster inspiration och hj¨alp att unders¨oka f¨or- och nackdelar med olika alternativ utan att alla m˚aste testas. Under implementationsfasen f˚ar utveck-laren konkret designhj¨alp och drar nytta av erfarna utvecklares tidigare bepr¨ovade l¨osningar. I vilket stadium som helst ¨ar det effektivt att diskutera systemet genom

att namnge applicerade designm¨onster. Den som ¨ar insatt i designm¨onster kan d˚a snabbt kan f˚a en bild av systemets bakomliggande principer.

Designm¨onster m˚aste alltid anpassas till det aktuella systemet. Ibland kan man f¨olja m¨onsterbeskrivningen till punkt och pricka, andra g˚anger blir m¨onstret snarare en k¨alla till inspiration. Det ¨ar inte meningen att designm¨onster ska upplevas som begr¨ansande: uppn˚ar man en b¨attre l¨osning genom att avvika fr˚an m¨onstret ska man naturligtvis g¨ora det. Men ofta ges tillr¨ackligt stor frihet ang˚aende implementationen, eftersom designm¨onster beskriver generaliserade snarare ¨an specifika l¨osningar.

2.2

Att beskriva designm¨

onster

Standardverket inom designm¨onsterlitteraturen anses ofta vara ”Design Patterns: Elements of Reusable Object-Oriented Software”[2], skriven av fyra m¨an (Gamma et al) som blivit k¨anda som ”Gang of Four” eller ”GoF”. De fyra valde en struktur f¨or att presentera designm¨onster som ofta ˚ateranv¨ants. Enligt deras presentations-metod best˚ar ett designm¨onster av:

Namn – ett beskrivande och unikt namn som identifierar m¨onstret.

Klassificering – en kategorisering av m¨onstret f¨or att man ska kunna tala om grupper av m¨onster.

Syfte – m¨onstrets m˚al och anledningen att anv¨anda det.

Andra namn – eventuella andra namn som anv¨ants f¨or m¨onstret.

Motivation – ett scenario med ett problem och en kontext f¨or vilka m¨onstret kan appliceras.

Till¨amplighet – situationer d¨ar m¨onstret ¨ar anv¨andbart.

Struktur – en grafisk representation av m¨onstret, ofta klassdiagram och interak-tionsdiagram.

Best˚andsdelar – klasser och objekt som anv¨ands i m¨onstret och vilken roll de har.

Interaktion – hur klasser och objekt samarbetar.

Konsekvenser – en beskrivning av resultat, sidoeffekter och kompromisser som m¨onstret ger upphov till.

Implementation – en beskrivning av hur l¨osningen ser ut. Kodexempel – exempel p˚a anv¨andning i praktiken.

Exempel – teoretiska exempel p˚a anv¨andning i praktiken.

Relaterade m¨onster – andra m¨onster som relaterar till m¨onstret, diskussion om likheter och olikheter.

Martin Fowlers Patterns of Enterprise Application Architecture [1] ¨ar en annan v¨alk¨and bok. Fowler ¨ar en mycket ber¨omd f¨orfattare och talare inom omr˚adet datorarkitektur och designm¨onster. Fowler sj¨alv s¨ager att enterprise application ¨ar ett sv˚art begrepp att definiera, men n¨amner att det f¨orutom att till¨ampningen ska vara intressant inom aff¨arsverksamhet ofta handlar om att hantera stora m¨angder av data som ska ¨overleva mellan k¨orningar av programmet. Konfigurations-hantering inneh˚aller visserligen en v¨aldigt liten m¨angd data, men det st¨ammer att den m˚aste lagras mellan k¨orningar. Fowlers m¨onster ¨ar d¨arf¨or applicerbara i detta fall med vissa f¨orenklingar tack vare implementationens n¨atthet.

I detta examensarbete har tv˚a designm¨onster ur Fowlers bok applicerats, n¨amligen Domain Model och Active Record. Dessa beskrivs i detta kapitel. ¨Aven MVC, ett m¨onsterspr˚ak som f¨orst utvecklades av Trygve Reenskaug, tas upp. Alla best˚andsdelar i GoFs lista ovan kommer inte att behandlas, d˚a det finns gott om litteratur som beskriver m¨onstren i mer detalj. H¨ar ges endast en tillr¨acklig inblick f¨or att den oinsatte ska kunna f¨orst˚a hur m¨onstret ¨ar relevant f¨or hantering av konfigurationsdata.

2.3

Domain Model

Domain Model ¨ar ett av Fowlers [1] designm¨onster f¨or dom¨anlogik, det vill s¨aga hur ansvaret f¨or datahantering f¨ordelas i programmet. M¨onstret st˚ar f¨or det objekt-orienterade angreppss¨attet. Med detta designm¨onster modelleras dom¨anen med

objekt som inneh˚aller data och metoder f¨or att manipulera datat. Man skapar en instans per f¨orekomst av det objektet st˚ar f¨or. Modellerar man till exempel en kunddatabas kan varje kund i systemet f˚a en egen instans av objektet Customer. Det enklaste fallet ¨ar n¨ar hela databasen l¨ases in i objekt vid uppstart av programmet. F¨or stora databaser ¨ar detta inte m¨ojligt och man l¨aser d˚a in den information som f¨or tillf¨allet efterfr˚agas. Resten av programmet ser det som att datat alltid finns i objekten och beh¨over inte bry sig om den underliggande datak¨allan.

Ett enkelt alternativ till Domain Model ¨ar Transaction Script, som ¨ar en procedur som sekventiellt g˚ar igenom allt som ska g¨oras. Fowler n¨amner ocks˚a Table Module, som liknar Domain Model men l˚ater varje instans st˚a f¨or en hel databastabell snarare ¨an en enskild post.

2.4

Active Record

Active Record ¨ar ett av Fowlers [1] designm¨onster f¨or koppling till databas eller motsvarande datak¨alla. Varje Active Record ¨ar en objektrepresentation av en databasrad som ¨aven inneh˚aller funktionalitet f¨or att h¨amta och manipulera datat, samt ¨ovrig dom¨anlogik relaterad till datat. M¨onstret passar enligt Fowler utm¨arkt med en enkel Domain Model och resulterar i en objektrepresentation som f¨oljer den underliggande databasstrukturen v¨al.

Figur 2.1, h¨amtad fr˚an Fowlers bok, visar ett exempel p˚a en Active Record som representerar en person. Objektet h˚aller data om personen, lastName, firstName, och numberOfDependents. D¨ar finns ocks˚a metoder f¨or skrivning och l¨asning till databasen, insert och update, samt ¨ovriga metoder som manipulerar datat.

Som alternativ till Active Record n¨amner Fowler designm¨onstren Table Data Gateway och Row Data Gateway som endast h˚aller metoder med SQL-kommandon f¨or databaskommunikation. Med Table Data Gateway skapas en instans per tabell och med Row Data Gateway skapas en instans per rad. Den st¨orsta skillnaden mot Active Record ¨ar att andra klasser f˚ar st˚a f¨or ¨ovrig logik relaterad till datat. Ett annat alternativ ¨ar Data Mapper, som skiljer sig fr˚an Active Record p˚a s˚a s¨att att SQL-fr˚agorna separeras ut till ett eget lager med Data Mappers som skickar information mellan databasen och objekten.

2.5

Model – View – Controller

Model – View – Controller, f¨orkortat MVC, ¨ar ett m¨onsterspr˚ak f¨or utveckling av system med grafiska gr¨anssnitt. Det utvecklades 1979 av Trygve Reenskaug f¨or Smalltalk [5]. I Java implementeras det enklast genom anv¨andning av de-signm¨onstren Command och Observer, som finns implementerade i Javas grund-paket. Syftet med MVC ¨ar att separera ett intressant objekt (modellen) fr˚an de anv¨andargr¨anssnittselement som st˚ar f¨or visualisering och interaktion (vyn och kontrollklasserna) [3].

De olika komponenterna kan beskrivas [3]:

Modell – en abstrakt datamodell som representerar m˚alobjektet. Har ingen direkt k¨annedom om vyer eller kontrollklasser.

Vy – tolkar och presenterar modellens data och uppdateras vid ¨andringar i mod-ellen eller vid h¨andelser fr˚an kontrollklasser.

Kontrollklasser – kontrollerar vyn och f¨orser modellen med nytt data. Skickar h¨andelser till b˚ade modell och vy.

Detta illustreras i figur 2.2, d¨ar heldragen linje st˚ar f¨or direkt k¨annedom och streckad linje st˚ar f¨or indirekt k¨annedom mellan objekten.

2.5.1

Command

Syftet med Command-m¨onstret ¨ar att kapsla in ett kommando i ett objekt som kopplas till exempelvis en knapp eller ett menyobjekt som aktiverar det. I Java ˚astadkommer man detta med hj¨alp av lyssnare (listeners) och h¨andelser (events). P˚a s˚a s¨att kan man helt frikoppla koden som ska exekveras fr˚an objektet som initierar den, enligt kodexemplen nedan. [3]

Exempel 1, funktionalitet i anonym klass: JButton button = new JButton();

button.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) {

// Kod som ska exekveras }

});

Exempel 2, funktionalitet i frist˚aende klass: JButton button = new JButton();

Ofta i de enklare fallen g¨or man detta genom att skriva en anonym klass p˚a plats enligt Exempel 1 snarare ¨an att skapa en helt ny klass som i Exempel 2. Den senare varianten ger dock en tydligare frikoppling och en bra uppdelning i klasser med tydliga uppgifter.

2.5.2

Observer

M¨onstret Observer g˚ar ut p˚a att ett objekt kan registrera sig f¨or att bli notifierat n¨ar ett annat intressant objekt ¨andras. I termer av MVC handlar detta allts˚a om att vyn kan registrera sig f¨or att notifieras om ¨

andringar i modellen. I Java g¨ors detta l¨att genom att vyklassen ¨arver java.util.Observer och modellklassen java.util.Observable. Vyn registreras via metoden addObserver(Observer x). N¨ar v¨arden ¨andras i modellen anropas metoderna setChanged() och notifyObservers() enligt nedan. [3]

public class Model extends java.util.Observable { protected double value;

public void setValue(double value) { this.value = value;

setChanged(); notifyObservers(); }

Kapitel 3

File Secure

Detta kapitel beskriver File Secure i det skick det var i september 2007. Senare kapitel redog¨or f¨or f¨orb¨attringar som gjorts.

M˚anga sm¨arre katastrofer har uppst˚att till f¨oljd av f¨orlust av viktigt data. Traditionella s¨akerhetskopieringsmetoder som exempelvis kopiering till fysiska lagringsmedia inneb¨ar risk att gl¨omma att utf¨ora kopieringen, att kopieringen obem¨arkt sker felaktigt eller att datakopiorna f¨org˚as tillsammans med datorerna vid exempelvis brand, st¨old eller ¨oversv¨amning. Preston skriver i Backup & Re-covery [4] att det s¨akraste s¨attet ¨ar att lagra sitt s¨akerhetskopierade data p˚a en helt annan plats ¨an originaldatat. Givetvis ¨ar en automatiserad l¨osning att f¨oredra framf¨or att ˚al¨agga en m¨anniska att komma ih˚ag uppgiften.

Versionshantering handlar om konsten att hantera ¨andringar i data. Tradi-tionellt ¨ar det programmerare som haft nytta av versionshantering i sina projekt, men i princip kan vem som helst som hanterar information p˚a en dator ha nytta av versionshantering.

File Secure ¨ar ett system som erbjuder automatisk och anv¨andarv¨anlig s¨akerhetskopiering av data till en server med versionshantering via Subversion. Upphovsmannen ¨ar Jonas Liljenfeldt, som drivit projektet p˚a sin fritid. M˚algruppen innefattar alla som sparar viktiga filer p˚a sin dator. Anv¨andaren beh¨over inte t¨anka p˚a att g¨ora s¨akerhetskopieringar och det ¨ar inte heller n¨odv¨andigt att k¨anna till vad versionshantering ¨ar f¨or att kunna ˚aterg˚a till tidigare

versioner av filer. File Secure har d¨arf¨or endast grundl¨aggande datork¨annedom som f¨orkunskapskrav.

Anv¨andaren v¨aljer sj¨alv under installationen av File Secure en katalog som ska bevakas genom schemalagda synkroniseringar med servern. Alla filer och under-kataloger till katalogen laddas upp och versionshanteras.

Om File Secure blir en kommersiell produkt i framtiden kommer det antagligen att handla om en helhetsl¨osning d¨ar programmet s¨aljs tillsammans med support och diskutrymme p˚a en server.

Detta kapitel ger en grundl¨aggande beskrivning av hur systemet fungerar och ¨

ar uppbyggt. F¨orst beskrivs ett anv¨andarscenario f¨or att ge l¨asaren en snabb uppfattning om vad systemet ¨ar till f¨or. Sedan beskrivs systemets gr¨anssnitt och de funktioner som ¨ar ˚atkomliga via klientprogrammets meny. Efter det beskrivs systemets arkitektur och hur dess olika delar samverkar. Till sist ges en ¨oversikt av befintliga system som liknar File Secure.

3.1

Anv¨

andarscenario

F¨or att ge en bild av hur File Secure ¨ar t¨ankt att anv¨andas presenteras h¨ar ett anv¨andarscenario med Anna Anv¨andare i huvudrollen.

Anna Anv¨andare vet hur frustrerande det ¨ar att f¨orlora vikti-ga filer, eftersom hennes h˚arddisk nyligen kraschade. Hon hade s¨akerhetskopierat n˚agra dokument genom att l¨agga in dem p˚a sitt USB-minne, men tyv¨arr skedde inte detta med n˚agon regelbundenhet och hon fick d¨arf¨or bara tillbaka gamla versioner av n˚agra f˚a viktiga filer. Fast besluten att inte uts¨atta sig f¨or detta igen installerade Anna File Secure.

Vid installationen angav Anna katalogen d¨ar hon sparar sina viktiga filer. File Secure arbetade en stund med att ladda upp Annas filer till en server. Om Annas dator skulle f¨orolyckas igen vet hon att filerna finns i s¨akert f¨orvar p˚a en annan plats.

Figur 3.1: Annas viktiga filer synkroniseras automatiskt med File Secures server.

Anna har st¨allt in File Secure s˚a att det automatiskt synkroniserar hennes filer med servern varje timme (se Figur 3.1). Hon m¨arker inte att programmet arbetar, annat ¨an genom att hon ser den lilla ikonen i aktivitetsf¨altet. N¨ar Anna g¨or ¨andringar i sina filer skickas n¨amligen inte hela den ¨andrade filen, utan bara de ¨andringar hon gjort. P˚a s˚a vis minimeras trafiken ¨over n¨atverket s˚a att Anna inte blir st¨ord om hon g¨or annat samtidigt.

En dag sitter Anna och skriver en rapport. Hon kan inte skaka av sig k¨anslan av att n˚agonting ¨ar fel med hennes grundl¨aggande fr˚agest¨allning, och vill d¨arf¨or prova att vinkla om hela rapporten. Innan Anna b¨orjar g¨ora alla ¨andringar vill hon s¨akerst¨alla att hon inte f¨orlorar den nuvarande versionen, s˚a hon h¨ogerklickar p˚a ikonen f¨or File Secure i aktivitetsf¨altet och v¨aljer ”Sync now”. Hon f˚ar upp en ruta d¨ar hon skriver en kommentar: ”F¨orsta versionen av rapporten”. Sedan b¨orjar hon g¨ora sina ¨andringar.

N¨ar Anna ¨andrat f¨ardigt skriver hon ut rapporten f¨or att be en v¨an korrekturl¨asa den. N¨ar Anna ber¨attar om hur hon vinklat om rapporten blir v¨annen nyfiken p˚a hur den tidigare versionen s˚ag ut, s˚a Anna h¨ogerklickar p˚a File Secures ikon igen och v¨aljer ”Browse Repository Files”. Hon bl¨addrar fram underkatalogen d¨ar rapporten ligger och ser d¨ar en lista med flera versioner som File Secure laddat upp automatiskt

˚at henne. Hon v¨aljer r¨att version och laddar ner den s˚a att v¨annen f˚ar j¨amf¨ora.

Figur 3.2: Menyn f¨or File Secure

3.2

Gr¨

anssnitt och funktioner

File Secure k¨ors som en bakgrundsprocess p˚a datorn och synkroniserar automa-tiskt enligt angivet tidsintervall den hanterade katalogen med sin motsvarighet i centralkatalogen. I aktivitetsf¨altet l¨aggs en ikon genom vilken anv¨andaren f˚ar tillg˚ang till en meny (se Figur 3.2) som till˚ater interaktion med programmet. Via denna meny kan anv¨andaren:

Exit – st¨anga av programmet.

Configure – se eller ¨andra inst¨allningar f¨or programmet. About/help – f˚a info om programmet (ej f¨ardigt).

Browse Repository Files – bl¨addra filerna i centralkatalogen. H¨ar kan man ¨

aven se och ˚aterg˚a till enskilda filers historia, samt ta bort filer. Denna funk-tion beh¨over f¨orb¨attras och ut¨okas.

Step back – ej implementerat, men det ska g˚a att spara tillst˚and f¨or allt hanterat data och sedan ˚aterg˚a till valfritt tillst˚and genom att v¨alja fr˚an en lista med sparade tillst˚and.

Stop autosync – st¨anga av automatisk synkronisering. N¨ar detta ¨ar gjort v¨axlar valet och blir i st¨allet ”Start autosync”.

Programmets nuvarande skick ¨ar s˚adant att allt grundl¨aggande fungerar, ¨

aven om somliga kringfunktioner endast ¨ar delvis implementerade och det finns utrymme f¨or f¨orb¨attringar och generell uppsnyggning.

3.3

Arkitektur

File Secure ¨ar en klient/server-applikation som bygger p˚a en rad etablerade stan-darder och produkter. Kommunikationen mellan klient och server sker krypterat i en SSH-tunnel.

P˚a klientsidan finns klientapplikationen, som ¨ar skriven i Java och anv¨ander sig av paketet JavaSVN1. JavaSVN ¨ar ett mycket komplett paket f¨or versionshantering genom Subversion2, och g¨or alla t¨ankbara Subversion-kommandon tillg¨angliga genom vanliga Java-metoder. Paketet har p˚a senare tid bytt namn till SVNKit, men kallas i denna rapport f¨or det ¨aldre namnet JavaSVN, eftersom det ¨ar en tidigare version som anv¨ants.

Klienten har ocks˚a en hsqldb-databas3_{, som anv¨ands f¨or att lagra anv¨andarens}

konfiguration. hsqldb ¨ar en l¨attviktsdatabas som st¨oder en delm¨angd av fr˚agespr˚aket SQL. Den kr¨aver inte n˚agot s¨arskilt av klienten, utan skapas i minnet under k¨orning av Java-applikationen, som importerar ett klassbibliotek f¨or att f˚a tillg˚ang till funktionaliteten. Mellan k¨orningar lagras den i en textfil p˚a anv¨andarens h˚arddisk.

P˚a klienten ligger givetvis ocks˚a arbetskatalogerna, som inneh˚aller de filer som bevakas och d¨ar ¨aven vissa inst¨allningsfiler sparas i dolda underkataloger med namnet ”.svn”.

1_{JavaSVN: http://svnkit.com/}

2_{Subversion: http://subversion.tigris.org/} 3_{hsqldb: http://hsqldb.org/}

P˚a serversidan finns en Java-servlet och ett Perl-script som skapar nya anv¨andarkonton. H¨ar skapas centralkataloger f¨or varje anv¨andare med versions-hanteringssystemet Subversion och anv¨andardata lagras i en MySQL-databas. H¨ar finns ocks˚a Java-servlets som sk¨oter diskutrymmeskontroll och liknande.

3.3.1

Scenario 1: Installation och konfiguration

Systemskissen i Figur 3.3 visar hur programmets delar interagerar under installa-tion och konfigurainstalla-tion.

1. H¨amta information fr˚an anv¨andaren: Via dialogrutor tillfr˚agas anv¨andaren om olika inst¨allningar f¨or programmet. Anv¨andaren v¨aljer till exempel vilken katalog p˚a datorn som ska bevakas av File Secure.

2. Lagra konfiguration: Inst¨allningarna sparas i den lokala hsqldb-databasen. 3. Skapa anv¨andarkonto p˚a servern: Applikationen kontaktar en Java-servlet

p˚a servern som skapar ett nytt anv¨andarkonto med hj¨alp av ett Perl-skript som skriver anv¨andardata till en MySQL-databas.

4. Synkronisera data: Via JavaSVN laddas filer fr˚an de angivna katalogerna upp till centralkatalogen p˚a servern.

3.3.2

Scenario 2: Bakgrundstj¨

anst

Systemskissen i Figur 3.4 visar hur programmets delar interagerar n¨ar programmet arbetar som en automatiskt synkroniserande bakgrundstj¨anst.

Via JavaSVN k¨ors synkroniseringar av den lokala katalogen och central-katalogen p˚a servern. En Java-servlet p˚a servern kontaktas f¨or att kontrollera anv¨ant diskutrymme och att det inte ¨overstiger utrymmet som anv¨andaren ¨ar ber¨attigad enligt uppgift lagrad i databasen. P˚a klienten kan anv¨andaren komma ˚at olika funktioner i programmet via en ikon i aktivitetsf¨altet.

3.4

Liknande system

Det finns en rad olika system f¨or automatisk s¨akerhetskopiering till en extern server. Listan ¨over dessa har tagits fram utg˚aende fr˚an en rad relevanta j¨amf¨orelsepunkter f¨or att avg¨ora vad som ¨ar ett liknande system, dock utan krav p˚a att samtliga punkter ska ¨overensst¨amma.

• Automatiska ¨overf¨oringar sker i bakgrunden. • Tillhandah˚aller lagringsutrymme p˚a server.

• Versionshantering eller motsvarande historikfunktion. • Plattformsoberoende klientprogramvara.

3.4.1

Vildmarksdatas Distansbackup

Distansbackup ¨ar en svensk tj¨anst f¨or s¨akerhetskopieringar till server med en ”in-byggd fil˚aterst¨allningslista som h˚aller reda p˚a alla versioner av dina filer f¨or en viss tid tillbaka”. Tj¨ansten fungerar p˚a alla operativsystem som st¨oder Java2 JRE 1.3.1 eller h¨ogre. Distansbackup st¨ammer ¨overens med File Secure p˚a samtliga j¨amf¨orelsepunkter ovan.

URL: http://www.vildmarksdata.se/distansbackup

3.4.2

Remote Data Backups

Remote Data Backups har m˚anga intressanta funktioner, men fungerar endast under Windows. Den inriktar sig mot komplett system˚aterst¨allning snarare ¨an s¨akerhetskopiering av utvalda filer och den versionshanterar 10 versioner bak˚at eller upp till 90 dagar.

URL: http://www.remotedatabackups.com/

3.4.3

Online Backups

Online Backup ¨ar en svensk tj¨anst som endast fungerar under Windows. De er-bjuder automatiska och krypterade ¨overf¨oringar av data, men sparar historik i endast en m˚anad.

URL: http://www.online-backup.se

3.4.4

Carbonite

Automatisk s¨akerhetskopiering f¨or Windows med en Mac-version p˚a v¨ag. Erbjuder obegr¨ansat utrymme p˚a servern. P˚a Carbonites hemsida hittades ingenting om versionshantering, men ett mail till kundtj¨anst gav svaret att den nya versionen erbjuder tre m˚anaders historik.

URL: http://www.carbonite.com

3.4.5

L¨

ardomar att dra av j¨

amf¨

orelsen

Endast Vildmarksdatas Distansbackup st¨ammer in p˚a samtliga j¨amf¨orelsepunkter. De flesta av dessa system fungerar endast under operativsystemet Windows och har ingen eller begr¨ansad versionshantering. File Secures plattformsoberoende m¨ojligg¨or en s¨arskild profilering och konkurrensf¨ordel som endast matchas av Dis-tansbackup i denna j¨amf¨orelse. Att versionshanteringen ¨ar s˚a fri, det vill s¨aga att man kan spara hur m˚anga versioner som helst s˚a l¨ange utrymme finns, kan ocks˚a vara en f¨ordel. Eventuellt skulle det kunna underl¨atta f¨or anv¨andaren med en auto-matisk uppr¨ojningsfunktion av gamla filer, ifall utrymmet tar slut. I nul¨aget kan anv¨andaren sj¨alv rensa bort versioner han eller hon inte beh¨over, vilket m¨ojligtvis kan vara f¨or sv˚art f¨or en del av m˚algruppen.

J¨amf¨orelsen visade ocks˚a en svaghet File Secure har gentemot de flesta liknande system: det begr¨ansade filurvalet. Tj¨ansterna till˚ater i regel anv¨andaren att fritt v¨alja filer eller kataloger ¨over hela h˚arddisken. Att File Secures anv¨andare endast kan v¨alja en katalog, och d¨armed ¨ar tvungna att l¨agga alla viktiga filer i denna eller dess underkataloger, g¨or att File Secure kan upplevas som ett begr¨ansande program.

Kapitel 4

Utvidgning av File Secure

Traditionellt inom versionshantering ¨ar att anv¨andaren v¨aljer en rotkatalog att hantera och att katalogstrukturerna f¨or centralkatalogen och arbetskatalogen matchar varandra. S˚a var ocks˚a fallet med File Secure innan examensarbetets ¨

andringar. Anv¨andaren kunde till exempel v¨alja att hantera sin hemkatalog och l˚ata alla underkataloger och deras inneh˚all automatiskt ing˚a i hanteringen. Detta medf¨orde begr¨ansningen att anv¨andaren enbart kunde v¨alja att l˚ata File Secure bevaka allt eller inget i denna hemkatalog och ingenting utanf¨or den.

Detta kapitel sammanfattar de praktiska detaljerna kring vidareutvecklingen av File Secure, som kan delas in i tv˚a huvudsakliga delar: ut¨okat katalogval och inf¨orande av st¨od f¨or undantagna filer, samt dialoger f¨or att ¨andra inst¨allningar f¨or detta. B˚ada dessa delar handlade i stor utstr¨ackning om att ut¨oka systemets konfiguration, det vill s¨aga att h˚alla reda p˚a data f¨or alla hanterade kataloger och undantagna filer. Funktionaliteten f¨or att synkronisera filer mot centralkatalogen fanns redan, men beh¨ovde kunna appliceras p˚a ett dynamiskt antal kataloger.

4.1

Funktionella krav

Tidigare fick anv¨andaren v¨alja en enda katalog att s¨atta under bevakning. Detta gjordes under installationen av systemet och valet kunde inte ¨andras i efterhand. Alla filer i katalogen och dess underkataloger kopierades till centralkatalogen och sattes under versionshantering.

I den nya versionen ska anv¨andaren kunna: • V¨alja flera kataloger under installationen.

• Ange filer och underkataloger som ska undantas hanteringen med hj¨alp av enkel m¨onstermatchning f¨or varje separat katalog.

• L¨agga till flera kataloger ¨aven efter installationen genom programmets in-st¨allningsdialoger.

• Ta bort kataloger fr˚an hanteringen ¨aven efter installationen. Filerna raderas i centralkatalogen men p˚averkas inte hos klienten.

• ¨Andra undantagsm¨onstret f¨or varje hanterad katalog. Redan uppladdade filer som st¨ammer in p˚a m¨onstret kommer att finnas kvar i centralkatalogen men kan tas bort manuellt.

4.1.1

Diskussion kring kraven

Dessa krav formulerades efter att flera olika id´eer till ny eller f¨orb¨attrad funktionalitet i File Secure diskuterats. N˚agra exempel p˚a s˚adant som diskuterats men inte ˚atg¨ardats ¨ar:

• Synkronisering mellan flera datorer.

• Tillf¨allig lokal backup om n¨atverket inte kan n˚as. • M¨ojlighet att s¨atta en ˚aterst¨allningspunkt. • Komprimering av data som skickas till servern.

• Webbgr¨anssnitt f¨or att kunna komma ˚at filerna p˚a servern fr˚an vilken dator som helst.

• Fotogalleri (m¨ojlighet att visa fotografier via webben).

Valet f¨oll p˚a att ˚atg¨arda det begr¨ansade filurvalet, som uppfattades som en stor brist i systemet av flera anledningar. Att v¨alja en enda katalog vars filer och

underkataloger hanteras och vars struktur f˚ar en exakt motsvarighet i en central-katalog st¨ammer ¨overens med det klassiska s¨attet att l¨agga upp versionshantering, men File Secures anv¨andare beh¨over inte k¨anna till standarduppl¨agget, eller ens veta vad versionshantering ¨ar, och kan uppleva det som mycket begr¨ansande att inte kunna l¨agga till filer utanf¨or den f¨orst valda katalogen. Anv¨andare b¨or kunna l¨agga sina filer var de vill och ¨and˚a kunna s¨akerhetskopiera dem.

Att ovillkorligen hantera varenda fil i katalogen och dess underkataloger ¨ar be-gr¨ansande eftersom mindre viktiga filer d˚a kan fylla utrymmet som man betalar f¨or. Kanske har man tempor¨art en v¨aldigt stor fil i sin katalog, eller s˚a programmerar man i Java och har m¨angder av genererade .class-filer som l¨att kan ˚aterskapas fr˚an .java-filerna. Det ¨ar rimligt att kunna undanta filer fr˚an hantering genom att ange specifika filnamn, delar av filnamn och filtyper som alltid ska ignoreras.

Att v¨alja en katalog vid installationen och sedan inte kunna ¨andra valet ¨ar givetvis begr¨ansande, eftersom det ¨ar oflexibelt.

4.2

Uppdaterat anv¨

andarscenario

I och med utvidgningen av File Secure beh¨over anv¨andarscenariot i kapitel 3.1 uppdateras.

Vid installationen av File Secure kan Anna ange flera kataloger som befinner sig var som helst i datorns katalogstruktur. Liksom tidigare hanteras dessa kataloger och deras underkataloger. Anna har viktiga filer p˚a flera st¨allen p˚a datorn, s˚a hon anger samtliga dessa kataloger. Anna skaffar en kamera och b¨orjar spara bilder p˚a datorn i en ny katalog som hon kallar ”Bilder”. F¨or att l˚ata File Secure hantera ¨

aven denna nya katalog ¨oppnar hon programmets meny, v¨aljer ”Configuration” och g˚ar in p˚a fliken ”Folders”. H¨ar trycker hon p˚a knappen ”Add folder” och f˚ar fram en vy av datorns katalogstruktur d¨ar hon kan v¨alja katalogen ”Bilder” och l¨agga till den. Skulle hon ˚angra sig g˚ar det ¨aven att ta bort en katalog fr˚an hanteringen.

N¨ar Anna bl¨addrar igenom sina filer p˚a servern f¨or att ˚aterst¨alla den f¨orsta rapportversionen (se kapitel 3.1) m¨arker hon att hon anv¨ander

ganska mycket utrymme p˚a servern. M˚aste hon k¨opa ¨annu mer utrymme? Hon bl¨addrar igenom sina filer och uppt¨acker att File Secure laddat upp n˚agra stora filmfiler hon tillf¨alligt hade sparade p˚a datorn. Dem tar hon bort. Anna beh¨over egentligen inte alls s¨akerhetskopiera s˚adana filer, s˚a hon ¨oppnar menyn ”Configuration” i File Secure och v¨aljer fliken ”Folders”. H¨ar ser hon en lista med alla sina hanterade kataloger och vid varje katalog finns ocks˚a ett textf¨alt d¨ar hon kan ange filer som programmet ska strunta i att ladda upp. D¨ar st˚ar redan ”*.class, *ejbackup*”, som hon skrev in vid installationen av File Secure. ”.class” har hon angett eftersom hon brukar programmera i Java och det ¨ar on¨odigt att s¨akerhetskopiera de genererade .class-filerna eftersom de kan genereras igen utifr˚an k¨allkodsfilerna med fil¨andelsen .java. ”*ejbackup*” har hon angett f¨or att kunna skapa filer som inte hanteras av FileSecure genom att hon skriver ”ejbackup” n˚agonstans i filnamnet. Hon l¨agger till ”*.avi,*.mpg” till listan f¨or katalogen d¨ar hon ibland l¨agger s˚adana filmfiler och trycker sedan p˚a ”OK”. File Secure sparar serverutrymme, n¨atverksbelastning och datorkraft genom att bara ladda upp de filer Anna faktiskt vill spara (se figur 4.1).

4.3

Implementation

Den nya versionen av File Secure har f˚att ut¨okade m¨ojligheter i och med att anv¨andaren kan l¨agga till ett godtyckligt antal kataloger som befinner sig var som helst i klientdatorns katalogstruktur. Anv¨andaren kan dessutom n¨ar som helst l¨agga till eller ta bort kataloger fr˚an File Secures bevakning. I och med detta har bevakningen av kataloger och konfigurationsdatabasens utformning p˚averkats.

Inf¨orandet av st¨od f¨or undantagsm¨onster inneb¨ar att vissa filer eller kataloger kan undantas hanteringen s˚a att systemet kan arbeta effektivare genom att kon-centrera sig p˚a de filer som anv¨andaren faktiskt vill s¨akerhetskopiera.

De nya funktionerna kr¨aver ocks˚a ett ut¨okat anv¨andargr¨anssnitt f¨or hantering av konfigurationsdata.

4.3.1

L¨

agga till kataloger

N¨ar File Secure k¨ors f¨or f¨orsta g˚angen g˚ar programmet igenom katalogerna som angivits vid konfigurationen och f¨or varje katalog skapas en motsvarande katalog p˚a rotniv˚a i centralkatalogen (se Figur 4.2). File Secure anv¨ander versions-hanteringssystemet Subversion genom paketet JavaSVN f¨or att f˚a tillg˚ang till bra funktioner f¨or att bevaka kataloger och effektivt synkronisera filerna med servern, samt f¨or att ha tillg˚ang till ¨aldre versioner av filer.

Figur 4.2: Katalogstruktur En ny katalog skapas i Subversion med kommandot: svn mkdir URL

I JavaSVN-paketet ˚aterfinns motsvarigheten i klassen SVNCommitClient genom metoden:

public SVNCommitInfo doMkDir(SVNURL[] urls,

String commitMessage) throws SVNException

Sedan g¨ors en f¨orsta utcheckning av varje katalog i centralkatalogen med aktuell arbetskatalog angiven som argument till funktionen. Detta g¨ors i Subversion med kommandot:

H¨ar ¨ar URL adressen till aktuell katalog i centralkatalogen och PATH den lokala s¨okv¨agen till katalogen p˚a klientdatorn.

Detta motsvaras i JavaSVN-paketet, i klassen SVNUpdateClient, av metoden: public long doCheckout(SVNURL url,

File dstPath,

SVNRevision pegRevision, SVNRevision revision, boolean recursive) throws SVNException

Utcheckningen knyter den lokala katalogen till sin motsvarighet i central-katalogen utan att katalogstrukturen beh¨over ¨overensst¨amma, men ¨an s˚a l¨ange har inga filer laddats upp. Det g¨ors i st¨allet av den f¨orsta synkroniseringen som sker direkt n¨ar programmet startats. D˚a l¨agger programmet alla filer i r¨att underkata-log i centralkataunderkata-logen, f¨orutsatt att de inte innefattas av n˚agot undantagsm¨onster (se kapitel 4.3.5).

N¨ar anv¨andaren under k¨orning l¨agger till en ny katalog f¨or bevakning sker samma procedur f¨or den nya katalogen.

Skillnaden mot den tidigare versionen av File Secure ¨ar att proceduren f¨or att skapa en ny katalog nu kan k¨oras flera g˚anger, b˚ade vid installation och vid senare tillf¨allen.

4.3.2

Bevakning av kataloger

Under k¨orning av programmet sker automatiska synkroniseringar, styrda av klassen PeriodicSvnCommunication som ¨arver java.util.TimerTask. Periodic-SvnCommunication skapar ett SVNOperation-objekt som inneh˚aller metoderna add, clean, commit, setIgnoreProperty, unlock och update, som i sin tur anv¨ander motsvarigheterna i JavaSVN enligt tabell 4.1.

Dessa metoder anropades tidigare med standardkatalogen angiven som argument, men nu agerar de i st¨allet p˚a varje Folder-objekt. Periodic-SvnCommunication har ¨andrats s˚a att den itererar ¨over alla existerande kataloger och anropar metoderna f¨or var och en.

svn-kommando JavaSVN-metod

add SVNWCClient.doAdd(File path, ...) clean SVNWCClient.doCleanup(File path)

commit SVNCommitClient.doCommit(File[] paths, ...) setIgnoreProperty SVNWCClient.doSetProperty(File path, ...) unlock SVNWCClient.doUnlock(File[] paths, ...) update SVNUpdateClient.doUpdate(File path, ...)

Tabell 4.1: JavaSVN-metoder f¨or Subversion-kommandon

4.3.3

Konfigurationsdatabas

Systemets konfiguration lagras lokalt i en hsqldb-databas. Tidigare lagrades s¨okv¨agen till den hanterade katalogen som ett f¨alt i tabellen Configuration. N¨ar antalet kataloger till˚ats ¨oka dynamiskt r¨acker inte l¨angre denna l¨osning, utan en ny tabell Folder kr¨avs. I denna lagras den lokala s¨okv¨agen, katalognamnet som anv¨ands i centralkatalogen, m¨onster f¨or undantagna filer och en koppling till aktuell konfiguration.

Figur 4.3 visar ett ER-diagram ¨over den nya databasstrukturen. Ytterligare en tabell f¨or undantagsm¨onster hade kunnat l¨aggas till, men d˚a systemet endast anv¨ander komma- eller radbrytningsseparerade str¨angar med dessa m¨onster (se 4.3.5) r¨acker det bra att ¨aven spara dem p˚a detta s¨att som attribut till Folder i databasen.

4.3.4

Objektrepresentation

Vid uppstart av systemet l¨ases konfigurationen in fr˚an hsqldb-databasen och en objektrepresentation skapas. Det ¨ar denna objektrepresentation av konfiguratio-nen som anv¨ands av programmet under k¨orning och n¨ar ¨andringar g¨ors i objekt-representationen sparas allt data p˚a nytt i databasen.

Objektrepresentationen av systemets konfiguration har ut¨okats och omfattar nu Configuration som tidigare, men f¨or varje hanterad katalog skapas nu ¨aven en instans av Folder, som h˚aller katalogdata.

Funktionaliteten f¨or att l¨asa och manipulera datat f¨ordelas mellan de b˚ada klasserna. Configuration har f˚att uppdraget att l¨asa in informationen fr˚an

Figur 4.3: ER-diagram f¨or konfigurationsdatabasen

databasen och skapa en instans av Folder per katalog i konfigurationen, samt h˚alla reda p˚a dem i en datastruktur av typen java.util.HashMap. Ett antal metoder f¨or att n˚a Folder-instanser har lagts till:

getFolderArray() returnerar en array som anv¨ands f¨or att stega igenom samtliga Folder-instanser.

getFolder(String name) returnerar det Folder-objekt som efterfr˚agas med hj¨alp av dess namn i centralkatalogen.

Figur 4.4: Anv¨andaren anger undantagsm¨onster.

4.3.5

Undantagna filer och kataloger

Subversion till˚ater anv¨andningen av undantagsm¨onster genom inst¨allningen svn:ignore. Formatet ¨ar begr¨ansat till textstr¨angar och jokertecknet ”*”. Flera m¨onster kan anges och ska d˚a separeras med radbrytning. T¨ankbara undan-tagsm¨onster kan allts˚a vara:

• Str¨angen ”minfil.txt” som matchar filer med exakt detta namn oavsett var i katalogstrukturen de befinner sig.

• Str¨angen ”Min Katalog” som matchar kataloger med exakt detta namn, samt alla filer och underkataloger i katalogen.

• Str¨ang med ett jokertecken, till exempel ”*.class” som matchar alla filer av typen .class.

• Str¨ang med flera jokertecken, till exempel ”*NOFS*” som matchar alla filer och kataloger med ”NOFS” n˚agonstans i namnet.

Kodbiblioteket JavaSVN gjorde det l¨att att implementera undantags-hanteringen. I SVNWCClient hittar man metoden:

public void doSetProperty(File path,

String propName, String propValue, boolean force, boolean recursive, ISVNPropertyHandler handler) throws SVNException

Denna anropas med path satt till aktuell katalogs s¨okv¨ag, propName satt till ”svn:ignore” och propValue som en blankradsseparerad str¨ang med undan-tagsm¨onster. Anv¨andaren anger undantagsm¨onster som en kommaseparerad str¨ang (se Figur 4.4), antingen under installationen eller senare genom programmets inst¨allningsdialoger, och dessa sparas i respektive katalogs Folder-objekt och databasrad. N¨ar JavaSVN anv¨ander datat f¨or att ¨andra inst¨allningen f¨or katalogen anropas en metod i Folder-objektet som byter kommatecknen mot radbrytningar, vilket kr¨avs av Subversion.

St¨od f¨or undantagsm¨onster ¨ar en helt ny funktion i File Secure, som medf¨or en stor f¨orb¨attring av friheten att v¨alja vilka filer som ska bevakas av programmet.

4.3.6

Grafiskt gr¨

anssnitt

Framf¨or allt ¨ar File Secure en bakgrundsprocess som automatiskt synkroni-serar bevakade kataloger med sina motsvarigheter p˚a servern, men det finns ocks˚a ett grafiskt gr¨anssnitt. Gr¨anssnittet best˚ar av olika inst¨allningsdialoger som anv¨andaren kommer ˚at via en ikon i aktivitetsf¨altet. Vid nyinstallation av systemet tas anv¨andaren dessutom igenom en grafisk konfigurationsdialog f¨or att ange ¨onskade inst¨allningar.

Tidigare inneh¨oll inst¨allningsdialogen endast n˚agra checkboxar och textf¨alt, vilkas v¨arden sparades n¨ar anv¨andaren tryckte p˚a OK-knappen. Det fanns tv˚a flikar, ”General” och ”Advanced”, men nu har fliken ”Folders” tillkommit (se Figur 4.5). H¨ar visas alla kataloger som hanteras av systemet, samt undantagsm¨onster

Figur 4.5: Kataloginst¨allningar

f¨or varje katalog. Man kan ocks˚a l¨agga till nya kataloger genom att trycka p˚a ”Add new folder” s˚a att f¨onstret ”Add folder” (se Figur 4.4) kommer fram. H¨ar kan anv¨andaren bl¨addra r¨att p˚a en katalog och ange undantagsm¨onster f¨or denna. Vill man senare ¨andra undantagsm¨onstren ¨ar det bara att ¨andra i textf¨altet f¨or katalogen under Folders-fliken och trycka ”OK”. ¨Andringen p˚averkar hur systemet hanterar filer i framtiden, men redan uppladdade filer finns kvar och kan raderas manuellt fr˚an centralkatalogen via ”Browse repository files”.

Genom f¨orb¨attringar av gr¨anssnittshanteringen f˚ar anv¨andaren direkt feedback p˚a att kataloger lagts till eller tagits bort, vilket inte var m¨ojligt med den tidigare enkla designen.

Kapitel 5

M¨

onsterspr˚

ak f¨

or

konfigurationshantering

Resultatet av detta arbete ¨ar ett m¨onsterspr˚ak f¨or konfigurationshantering. Det kan till¨ampas i applikationer som beh¨over lagra en rad inst¨allningsparametrar och l˚ata anv¨andaren modifiera dessa. Vad applikationen har f¨or syfte i ¨ovrigt har ingen betydelse. Ett viktigt antagande ¨ar att m¨angden data ¨ar f¨orh˚allandevis liten.

Delproblem Designm¨onster datamodellering Domain Model

Active Record anv¨andargr¨anssnitt MVC

Tabell 5.1: Sammanst¨allning av delproblem och applicerade designm¨onster.

Problemen som m¨onsterspr˚aket syftar till att l¨osa kan delas in i tv˚a delar: data-modellering och anv¨andargr¨anssnitt. Datamodellering innefattar att l¨asa in kon-figurationsdata fr˚an databasen till en objektrepresentation som kan anv¨andas av applikationen. Anv¨andargr¨anssnittet l˚ater anv¨andaren modifiera konfigurations-datat. Tabell 5.1 visar applicerade designm¨onster per delproblem.

M¨onsterspr˚aket best˚ar av designm¨onstren Active Record, Domain Model, samt det befintliga m¨onsterspr˚aket Model – View – Controller enligt Figur 5.1. M¨onstren

Figur 5.1: M¨onsterspr˚ak f¨or konfigurationshantering. Innanf¨or den streckade linjen visas MVCs olika delar - Model, View och Controller. Model byggs upp med hj¨alp av designm¨onstren Domain Model och Active Record.

hakar i varandra: Active Record ¨ar en specifik variant av Domain Model och utg¨or dessutom Model-delen i MVC.

5.1

Datamodellering

Vad g¨aller databaskommunikation ¨ar det enligt Fowler [1] ett problem att hantera SQL-kommandon i Java-koden, d˚a m˚anga utvecklare ¨ar obekv¨ama med det. Det ¨ar en vanlig men d˚alig l¨osning att l˚ata SQL-kommandon ligga utstr¨odda lite varstans i koden. Med Fowlers Domain Model och Active Record anv¨ands det objekt-orienterade angreppss¨attet och det finns en objekttyp per databastabell. Objektet inneh˚aller alla metoder som beh¨ovs f¨or att kommunicera med databasen och ¨ovriga delar av programmet anropar dessa metoder i st¨allet f¨or att sj¨alva anv¨anda SQL-kommandon. Objektrepresentationen blir logisk i och med att en instans skapas f¨or varje databasrad.

Det konfigurationsdata en applikation anv¨ander ¨ar i m˚anga fall mycket enkelt. Ett typiskt scenario ¨ar en databastabell med en enda rad. Denna motsvaras d˚a i applikationen av ett enda objekt, som byggs enligt Domain Models och Active Records principer. Givetvis kan en konfiguration vara mer avancerad och kr¨ava ett st¨orre antal objekt. File Secure kr¨aver till exempel ett dynamiskt antal objekt som motsvarar kataloger som systemet hanterar.

5.1.1

Varf¨

or Domain Model?

Fowler definierar tre f¨orh˚allningss¨att till att organisera dom¨anlogik: Transaction Script, Table Module och Domain Model (se Tabell 5.2). Transaction Script st˚ar f¨or en enkel l¨osning, som i princip ¨ar en procedur som tar emot indata, behand-lar datat, l¨aser fr˚an och lagrar i databas (eventuellt med hj¨alp av till exempel Table Data Gateway eller Row Data Gateway, som passar bra med Transaction Script) och skickar tillbaka data till presentationen - kort sagt, den sk¨oter hela jobbet sekventiellt. F¨or varje handling en anv¨andare kan vilja g¨ora finns en s˚adan procedur. F¨ordelen ¨ar att det ¨ar ett v¨aldigt enkelt och l¨attfattligt angreppss¨att, men nackdelarna visar sig snart d˚a systemen v¨axer i storlek. Man r˚akar l¨att ut f¨or duplicering av kod och att applikationen v¨axer och blir o¨oversk˚adlig.

Designm¨onster K¨annetecken

Transaction Script Sekventiella procedurer. Table Module Ett objekt per tabell. Domain Model Ett objekt per tabellrad.

Tabell 5.2: Alternativ f¨or databasmodellering

Objektorientering l¨oser detta problem. Med Fowlers terminologi anv¨ander vi designm¨onstret Domain Model f¨or att modellera v˚ar dom¨an med objekt f¨or systemets olika substantiv - det vill s¨aga, en biluthyrare kanske modellerar sin dom¨an med objekt som Car och Customer. I dessa objekt ligger metoder som utf¨or arbetet som ska g¨oras. Med Transaction Script fanns en rutin som hanterade hela sessionens logik, men med Domain Model hanterar varje objekt den logik som ¨

ar relevant f¨or den sj¨alv. N¨ar systemet v¨axer ¨ar det smidigt att inf¨ora till exempel mer specifika typer av objekt j¨amf¨ort med att l¨agga till konditionell logik i ett Transaction Script.

Table Module p˚aminner vid f¨orsta anblick om Domain Model, men skillnaden ¨

ar att Domain Model har ett objekt per databasrad medan Table Module har ett objekt per hel tabell. Table Module ¨ar mer strukturerat ¨an Transaction Script, men kan inte dra nytta av objektorienteringens alla f¨ordelar.

Fowler rekommenderar Domain Model f¨or alla n˚agot mer komplexa system. Objektorientering ¨ar idag n¨armast r˚adande praxis inom programutveckling och det ¨ar d¨arf¨or inte sv˚art att motivera varf¨or det ska anv¨andas.

I fallet File Secure, som ¨ar ett objektorienterat system, var det naturligt att anv¨anda Domain Model. File Secure modellerar konfigurationsdatat i en objekt-representation (se kapitel 4.3.4) inneh˚allande data och metoder som manipulerar datat. File Secures konfigurationsobjekt Configuration och Folder motsvaras av databastabellerna Configuration, Folder och hasFolder, som beskrivs i kapitel 4.3.3. Tabellen Configuration inneh˚aller grundl¨aggande info om konfigurationen i form av anv¨andarnamn, l¨osenord, spr˚akval, om autosync ¨ar aktiverat, om l¨osenordsfr˚aga ¨ar aktiverat och s˚a vidare. I denna tabell finns bara en rad, eftersom varje installation endast har en anv¨andare. Via tabellen hasFolder knyts ett antal rader i tabellen Folder till konfigurationen. Folder-raderna inneh˚aller information om de kataloger

som anv¨andaren valt att hantera. En logisk objektrepresentation av tabellerna ¨ar en instans av Configuration och en instans av Folder f¨or varje katalog som hanteras.

5.1.2

Varf¨

or Active Record?

N¨ar man anv¨ander Domain Model finns olika val f¨or databaskopplingen (se Tabell 5.3). Man kan till exempel anv¨anda en Gateway, som ¨ar en s¨arskild klass vars enda uppgift ¨ar att skicka data mellan databasen och objektrepresentationen. Anv¨ander man Table Data Gateway skapas en instans per tabell, och med Row Data Gate-way skapas en instans per tabellrad. En GateGate-way har metoder som motsvarar SQL-kommandon som select, insert, update och delete. F¨or att modellera riktigt avancerade strukturer n¨amner Fowler m¨onstret Data Mapper, ett lager mellan databasen och objektrepresentationen som sk¨oter konverteringen utan att vara k¨and av endera parten.

Designm¨onster K¨annetecken

Gateway En s¨arskild klass skickar data mellan databasen och objektrepresentationen. Data Mapper Ett lager mellan databas och objekt som

m¨ojligg¨or avancerad datamappning. Active Record Varje objekt sk¨oter sin egen

databaskoppling.

Tabell 5.3: Alternativ f¨or databaskoppling

Det enklaste och mest logiska ¨ar att l˚ata varje objekt ansvara f¨or sin egen databaskoppling, vilket motsvaras av m¨onstret Active Record. Varje databasrad motsvaras av ett objekt (enligt Domain Model) som ¨aven inneh˚aller funktionalitet f¨or att h¨amta och manipulera datat, samt ¨ovrig dom¨anlogik relaterad till datat (Active Records till¨agg). I v˚ar enkla konfigurationshanteringsmodul finns inget behov av n˚agon avancerad l¨osning. Datat beh¨over i regel inte genomg˚a n˚agra kom-plicerade konverteringar eller ber¨akningar och vi f¨oruts¨atter att all data l¨ases in vid uppstart av programmet. Active Records enkelhet kommer v¨al till pass.

Figur 5.2: Klassers samverkan enligt MVC

5.2

Anv¨

andargr¨

anssnitt

Det finns m˚anga olika s¨att att g¨ora anv¨andargr¨anssnitt, men det ¨ar l¨att att de blir stora och o¨oversk˚adliga. Det kan ocks˚a vara sv˚art att p˚a ett bra s¨att f˚a flexibla gr¨anssnitt som kan uppdateras medan anv¨andaren interagerar med dem.

Med MVC delas klasserna upp i grupper med tydliga uppgifter: modellklasser h˚aller data, vyklasser presenterar data och kontrollklasser ¨ar lyssnare som reagerar p˚a interaktion fr˚an anv¨andaren. N¨ar modellklassens data ¨andras notifieras och uppdateras vyklassen.

Fowler [1] s¨ager att v¨ardet av MVC ligger i dess tv˚a separationer. Separationen av vy och modell ¨ar en av de viktigaste designprinciperna f¨or mjukvara och enligt Fowler ska man alltid anv¨anda detta n¨ar det finns n˚agon form av icke-visuell logik, det vill s¨aga f¨or de allra flesta fall utom de allra enklaste. Att separera vyklasser och kontrollklasser ¨ar enligt Fowler inte lika viktigt, utan ska bara g¨oras n¨ar det ¨

ar hj¨alpsamt.

I fallet File Secure var det grafiska gr¨anssnittet, som beskrivs i kapitel 4.3.6, till en b¨orjan mycket enkelt. Det inneh¨oll n˚agra textf¨alt och kryssrutor vars v¨arden sparades n¨ar anv¨andaren tryckte p˚a OK-knappen. Med inf¨orandet av kat-aloginst¨allningar och m¨ojligheten att l¨agga till och ta bort kataloger beh¨ovde fullfj¨adrad MVC-funktionalitet inf¨oras f¨or att l˚ata vyn uppdateras n¨ar nya kataloger lagts till.

Tidigare Nu

Objektrepresentation: Objektrepresentation:

Configuration Configuration (extends Observable) Folder

Vy: Vy:

ConfigurationFrame ConfigurationFrame (implements Observer) AddFolderFrame

Kontrollklasser:

AddFolderAction (extends AbstractAction) CloseAction (extends Abstract Action) StopHandlingFolderAction (extends Abst...) UpdateConfigurationAction (extends Abst...) Tabell 5.4: Klasser uppdelade enligt MVC

ConfigurationFrame (vyn) implementerar Observer. H¨andelser som l˚ag inbakade i ConfigurationFrame separerades ut till egna kontrollklasser. Som ett resultat av detta har koden dessutom blivit betydligt mer ¨oversk˚adlig. Tabell 5.4 visar hur klasserna ut¨okats och f˚att tydliga roller. Figur 5.2 visar hur komponenterna samverkar enligt MVC-arkitekturen.

5.3

Praktiska r˚

ad vid till¨

ampning

F¨or att applicera m¨onsterspr˚aket f¨or konfigurationshantering b¨or du f¨orst och fr¨amst fundera ¨over vad som ing˚ar i din konfiguration, det vill s¨aga vilket data du ska hantera. Skapa en databas som rymmer allt som beh¨ovs.

Skriv ocks˚a en klass som ska h˚alla datat, vi kallar den Configuration. Configuration instansieras antagligen vid uppstart av ditt program, till exempel i main()-metoden. Det b¨or vara tillg¨angligt f¨or alla delar av applikationen som ¨ar beroende av n˚agon av dina inst¨allningsparametrar.

Configuration ¨ar modell-delen i MVC och byggs enligt Domain Models och Active Records principer. Det viktigaste till en b¨orjan ¨ar att Configuration ¨ar ett objekt med instansvariabler motsvarande dina databasf¨alt och att det finns en metod, till exempel readConfiguration(), som l¨aser in v¨arden p˚a dessa fr˚an databasen. Du beh¨over ocks˚a antagligen setters och getters f¨or alla variabler. B¨orja f¨orslagsvis med att l˚ata programmet anv¨anda inst¨allningar i form av fasta v¨arden fr˚an databasen.

N¨asta steg ¨ar att skapa ett grafiskt gr¨anssnitt, View-delen i MVC, som visar alla v¨arden och l˚ater anv¨andaren ¨andra dem med hj¨alp av Controller-delen i MVC. Till sist beh¨over du ¨aven en metod i Configuration f¨or att spara de nya v¨ardena i databasen.

5.3.1

Att h˚

alla reda p˚

a skapade objekt

Vad som inte framg˚ar av m¨onsterbeskrivningarna ¨ar hur man ska h˚alla reda p˚a skapade objekt. Som tidigare n¨amnts kan en konfigurationshantering ofta vara s˚a enkel att endast ett objekt kr¨avs, men i fallet File Secure f¨orekommer ett of¨oruts¨agbart antal objekt som ¨andras n¨ar anv¨andaren l¨agger till och tar bort kataloger fr˚an systemets bevakningsinst¨allningar.

Fowlers utg˚angspunkt ¨ar system med st¨orre databaser, d¨ar endast de objekt som f¨or tillf¨allet efterfr˚agas ¨ar inl¨asta. Anv¨andaren kanske matar in ett person-nummer som motsvarar en person i databasen. Objektet efterfr˚agas med detta id och om det ¨annu inte existerar m˚aste det l¨asas in. Det finns s¨arskilda designm¨onster att applicera f¨or att strukturera upp detta. Fowler beskriver till exempel Identity Map, vars uppgift ¨ar att h˚alla reda p˚a vilka objekt som l¨asts in s˚a att inte dub-bletter uppst˚ar.

I det enkla fallet konfigurationshantering utg˚ar vi fr˚an att alla objekt skapas vid uppstart och finns tillg¨angliga i minnet under hela k¨orningen. Det finns allts˚a inget behov av m¨onster som Identity Map och liknande. Har man en avancerad konfiguration med of¨oruts¨agbart antal objekt kan man beh¨ova hj¨alp av en datastruktur som inneh˚aller referenser till de skapade objekten och tillhandah˚aller uppslagsfunktionalitet. Exakt hur detta ska ske m˚aste avg¨oras av var och en som applicerar m¨onsterspr˚aket, men ett exempel ¨ar l¨osningen

som anv¨andes i fallet File Secure: Databasen inneh˚aller en rad i tabellen Configuration och flera rader i tabellen Folder. Configuration h˚aller grundl¨aggande anv¨andardata och inst¨allningar f¨or hur programmet ska arbeta, medan Folder h˚aller data om de kataloger som programmet hanterar. D˚a endast en instans av Configuration beh¨over skapas g¨ors detta genom att objektet instansieras vid uppstart och refereras med en referensvariabel som g¨ors ˚atkomlig f¨or hela applikationen via metoden getConfiguration(). Eftersom alla Folder-objekt skapas vid uppstart ¨ar det smidigt att Configuration sk¨oter detta och lagrar objekten i en java.util.HashMap. Som nyckel anv¨ands katalogens namn och v¨ardet ¨ar en referens till Folder-instansen. P˚a s˚a vis kan man antingen efterfr˚aga ett specifikt objekt med dess namn, eller stega igenom samtliga Folder-instanser.

Configuration inneh˚aller samtliga SQL-kommandon f¨or b˚ade Configuration och Folder. Folder uppfyller allts˚a inte m¨onstret Active Record, utan fungerar som en st¨odklass som hj¨alper Configuration att h˚alla data. I beskrivningen av konfigurationshantering har vi utg˚att fr˚an att inl¨asning av konfigurationsdatabasen sker i sin helhet vid uppstart av programmet. D˚a datam¨angden ¨ar liten ¨ar det rimligt att ¨aven tillbakaskrivning sker av all data samtidigt, eftersom vinsten som g¨ors av att h˚alla reda p˚a uppdaterade v¨arden och skriva endast dessa kan antas f¨orsumbar.

Exemplet visar att det i fallet konfigurationshantering kan vara rimligt med en f¨orenkling av Active Record. I detta fall hade l¨osningen blivit on¨odigt kr˚anglig om ¨

aven Folder-objektet till punkt och pricka skulle f¨olja Active Records beskrivning. Med det f¨orenklade s¨attet har antalet databasaccesser h˚allits p˚a en fortsatt l˚ag niv˚a, vilket m˚aste ses som en f¨ordel. Men det ¨ar naturligtvis upp till varje utvecklare hur han eller hon vill l¨agga upp sin implementation.

Kapitel 6

Diskussion

Det g˚ar att hitta designm¨onster som passar till n¨astan vad som helst. S¨okandet efter designm¨onster till en konfigurationshantering underl¨attades av att konfigurationshantering i synnerhet och hantering av data fr˚an underliggande datak¨alla i allm¨anhet ¨ar vanligt f¨orekommande uppgifter.

Java ¨ar ett tacksamt spr˚ak f¨or den som vill applicera designm¨onster, eftersom flera designm¨onster finns implementerade i grundbiblioteket. Exempel p˚a dessa ¨ar Command och Observer, som i egenskap av best˚andsdelar av MVC anv¨ants i detta arbete.

Programvaran File Secure har ut¨okats med den efterfr˚agade funktionaliteten och alla funktionella krav (se kapitel 4.1) har uppfyllts. Resultatet har generaliserats till ett m¨onsterspr˚ak f¨or konfigurationshantering.

6.1

M¨

onsterspr˚

ak f¨

or konfigurationshantering

Valen av designm¨onster till m¨onsterspr˚aket f¨or konfigurationshantering, som presenteras i kapitel 5, f¨oll sig v¨aldigt naturliga. D˚a File Secure utvecklats objektorienterat, och detta ¨ar r˚adande praxis idag, var Domain Model s˚a gott som givet. Den p˚ab¨orjade konfigurationshanteringen med objektet Configuration som h¨oll och manipulerade konfigurationsdata liknade redan Active Record och eftersom Fowler f¨orespr˚akar anv¨andningen av Domain Model och Active Record tillsammans blev det logiskt att forts¨atta s˚a. De grafiska dialogerna som l˚ater

anv¨andaren ¨andra inst¨allningar var v¨aldigt enkelt gjorda och beh¨ovde ut¨okas n¨ar systemet b¨orjade hantera ett dynamiskt antal kataloger. Med MVC ˚astadkoms direkt visuell ˚aterkoppling p˚a att l¨agga till och ta bort kataloger. Det var d¨arf¨or tydligt att m¨onstren passade i File Secure och de vidare litteraturstudierna bekr¨aftade m¨onstrens l¨amplighet, d˚a inga intressantare alternativ kunde hittas till den generella konfigurationshantering rapporten beskriver.

6.1.1

Nytta

Designm¨onster f¨or hantering av databasinformation fokuserar ofta p˚a att klara av stora m¨angder data. D˚a datam¨angden kan antas vara f¨orh˚allandevis liten i en konfigurationshantering ¨ar m˚anga av de standardiserade l¨osningarna on¨odigt komplicerade. Risken ¨ar d˚a att man som utvecklare undviker designm¨onster och g˚ar miste om dess f¨ordelar. M¨onsterspr˚aket presenterar ett s¨att att p˚a ett strukturerat s¨att med hj¨alp av designm¨onster hantera konfigurationsdata med en lagom avancerad l¨osning.

6.1.2

Applicerbarhet

M¨onsterspr˚aket f¨or konfigurationshantering kan appliceras i system som beh¨over lagra en m¨angd inst¨allningsparametrar och l˚ata anv¨andaren modifiera dem vid behov. Vad systemet ˚astadkommer i ¨ovrigt ¨ar av sekund¨ar betydelse. I denna rapport har visats hur m¨onsterspr˚aket applicerats i ett program f¨or automatiska s¨akerhetskopieringar till en extern server med versionshantering.

Beskrivningen ¨ar inriktad mot konfigurationshantering, men resultatet kan ¨

aven appliceras i applikationer som p˚a liknande s¨att hanterar en liten m¨angd databasdata.

6.1.3

Kritik

En inv¨andning mot m¨onsterspr˚aket kan vara att om systemet inte beh¨over en databas till n˚agonting annat kan det vara on¨odigt att anv¨anda en till konfigurationsdatat. Ett alternativ kan vara att anv¨anda java.util.Properties, som lagrar data i en textfil. M¨onsterspr˚aket kan anpassas s˚a att det passar ihop

med denna l¨osning. Man b¨or ¨aven komma ih˚ag att en databas inte n¨odv¨andigtvis m˚aste kr¨ava s¨arskilt mycket. File Secure anv¨ander hsqldb som ocks˚a lagrar data i en textfil och endast beh¨over en jar-fil f¨or att fungera (se kapitel 3.3).

Om man i st¨allet har situationen att systemet arbetar mycket med data-baser och databasmodellering kanske man redan har till¨ampat de mer avancerade metoderna och i detta fall kan det logiska vara att anv¨anda samma principer vid all modellering, inklusive den f¨or konfigurationsdatat.

Vid n˚agot mer avancerade konfigurationer, som till exempel File Secure med sitt dynamiska antal Folder-objekt, kan Active Record k¨annas on¨odigt omst¨andigt. Att varje objekt ska sk¨ota sin egen inl¨asning, trots att vi antagit att objekten l¨ases in samtidigt, resulterar i m˚anga databasaccesser. File Secures Folder-objekt avviker d¨arf¨or fr˚an Active Records principer och all inl¨asning och tillbakaskrivning hanteras av konfigurationens grundobjekt Configuration. Trots m˚als¨attningen att skapa ett enkelt m¨onsterspr˚ak valdes allts˚a att g¨ora ytterligare f¨orenklingar.

6.2

File Secure och dess framtid

Tack vare anv¨andningen av designm¨onster har File Secure dragit nytta av erfarna utvecklares tidigare erfarenheter. Detta har gett inspiration i inledningsfasen, prak-tisk hj¨alp i implementationsfasen och gett ut¨okade m¨ojligheter att snabbt beskriva dessa aspekter av systemet f¨or n˚agon som ¨ar insatt i designm¨onster.

De ut¨okade m¨ojligheterna f¨or att v¨alja filer som ska hanteras g¨or att File Secure blir betydligt mer intressant ¨an tidigare i j¨amf¨orelse med liknande, existerande system. File Secure har dessutom en f¨ordel i och med att det ¨ar operativsystems-oberoende. Av de unders¨okta liknande systemen ¨ar det endast Vildmarksdatas Distansbackup (se kapitel 3.4.1) som fungerar i fler milj¨oer ¨an Windows.

Den diskuterade ut¨okade funktionaliteten att inf¨ora st¨od f¨or synkronisering mellan flera datorer kompliceras sannolikt av den nya, ut¨okade kataloghanteringen i och med att det inte l¨angre handlar om att bara v¨alja en katalog att synkronisera. Det finns flera t¨ankbara s¨att att l¨osa problemen om det blir aktuellt att f¨orverkliga id´en. Ett alternativ ¨ar att ¨overf¨ora konfigurationsdatabasen till klient 2 och p˚a s˚a vis l˚ata den anv¨anda samma s¨okv¨agar som klient 1. D˚a man inte kan ta f¨or givet att det ¨ar ¨onskv¨art att strukturen ¨overensst¨ammer de b˚ada klientdatorerna emellan

¨

ar det troligtvis l¨ampligare att l˚ata anv¨andaren v¨alja en katalog p˚a klient 2 f¨or varje katalog i centralkatalogen, och l˚ata detta val dyka upp p˚a nytt varje g˚ang en katalog lagts till p˚a n˚agon av klienterna. En mycket enkel l¨osning ¨ar att strukturen p˚a klient 2 f˚ar motsvara centralkatalogens, men det ¨ar antagligen f¨or begr¨ansande. File Secure ¨ar ¨annu inte redo f¨or riktiga anv¨andare, men det handlar nu om ganska sm˚a f¨orb¨attringar f¨or att ut¨oka systemet till s¨aljbart skick. Givetvis hade mer arbete kunnat g¨oras inom ramen f¨or examensarbetet, men d˚a de uppst¨allda kraven uppfyllts blev det dags att s¨atta punkt och ˚aterl¨amna projektet till Jonas Liljenfeldt.