Find vej Skrevet af: Gruppe D109A Aalborg Universitet 2004
TITEL Find vej PROJEKTPERIODE Dat1 2. September - 21. December 2004 PROJEKTGRUPPE D109A GRUPPEMEDLEMMER Morten Dahl Uffe Sørensen Martin Clemmensen Claus Thrane VEJLEDER Keld Pedersen Synopsis Dette projekt omhandler udviklingen af et Find vej system, med baggrund i en analyse af Aalborg Universitet s campus. Projektet er udviklet vha. OOA&D metoden. I analysedokumentet beskrives systemets problem- og anvendelsesområde. I designdokumentet specificeres designkriterierne, der lægges vægt på i dette projekt. Desuden beskrives detaljer for systemet og dets funktionalitet. Implementeringsdokumentet beskriver hvordan systemet er blevet implementeret, med udgangspunkt i oprettelsen af en lokation. Studierapporten beskriver hvilke overvejelser vi har gjort os og indeholder et afsnit, der omhandler vores fokusområde; Algoritmer og datastrukturer. Resultatet af dette er et funktionsdygtigt find vej system med AAU som eksempel. OPLAG: 6 SIDEANTAL: 119
Forord Denne rapport er sammen med implementeringen af det i rapporten beskrevede system, resultatet af vores DAT1 projektforløb fra primo september til medio december 2004 ved Institut for Datalogi på Aalborg Universitet. Den teoretiske baggrund for projektet er primært kurserne Systemanalyse og Design, Design af Brugergrænseflader, Objekt Orienteret Programmering og Algoritmer og datastrukturer. Kildekoden til programmet findes på den vedlagte cdrom under mappen src/, og Javadoc for kildekoden findes i mappen doc/. Desuden kan kildekoden og dokumentationen findes på webadressen http://www.cs.aau.dk/ us/dat1/. Læsevejledning Rapporten består af flere individuelle dokumenter, hvilke kan læses uafhængigt af hinanden. I rapporten vil man løbende kunne finde referencer til relevant litteratur, kilder, billeder, tabeller og appendiks. Desuden vil der forekomme uddrag af kildekode. Disse vil være markeret på følgende måde. Kilder Henvisninger til eksterne kilder vil i denne rapport være markeret på følgende måde:... Composite design mønsteret [10]... Hvor nummeret i klammerne, repræsentere en kilde i kildefortegnelsen, i dette tilfælde henvises til bogen Design Patterns Elements og Reusable Object-Oriented Software. Referencer Der vil i teksten forekomme referencer til afsnit og figurer, disse vil være udformet således:... se figur 1.2 på side 16,... hvilket referere til klassediagrammet på side 16. Referencer til tabeller, ordforklaring m.v. vil fremkomme på samme måde. Kildekode Der vil visse steder forekomme Kildekode i rapporten. Disse kode eksempler, vil fremtræde på følgende måde: class Hello { public static void main ( String [ ] args ) { System. out. println ( Don t Panic! ) ; } 5 }
Indledning Denne rapport beskæftiger sig med analyse, design og implementering af et find vej system. Analysen er baseret på et specifikt problem på Aalborg Universitet (AAU) hvor det for nye brugere af området, kan være besværligt at finde rundt. Designet af systemet henvender sig derimod til den mere generelle problemstilling: at kunne modellere et geografisk område elektronisk inklusiv den organisation der er beboende på dette område. Både analyse og design, tager udgangspunkt i de nuværende muligheder, samt ønsker fra reelle brugere af AAU (gruppe d109a). Rapporten er inddelt i fire dele, der dokumenterer hver sin del af projektforløbet. Første del er Analysedokumentet. Analysedokumentet introducerer systemet, og beskriver analysen af problemområdet og anvendelsesområdet. Gennem analysen formuleres kravene til systemets funktionallitet og udseende. Anden del er Designdokumentet, hvor systemet modelleres og designes, hvilket vil sige at det klarlægges hvordan systemets arkitektur og komponenter, i praksis skal realisere de formelle krav fra analysen. Tredje del er Implementeringsdokumentet, hvor projekt gruppen redegør for dele af systemets implementering. Dette dokument demonstrere hvorledes systmets design medvirker til at opfylde de formelle krav fra analysen. Sidste del er Studierapporten, hvor rapporten afrundes ved at reflektere over beslutninger og handlinger, der er truffet gennem udviklingsforløbet. Idet algoritmer er valgt som vores fokusområde, vil der i denne del findes et afsnit om disse, hvor der, ud fra teorien om algoritmer og datastrukturer, argumenteres for de valg, vi har truffet indenfor dette område i forbindelse med design og implementering af systemet. Derudover er de overordnede beslutninger, der er truffet i implementeringsfasen beskrevet. Desuden indeholder denne del et afsnit, hvor vi reflekterer over gruppearbejdet, beskriver de brugte metoder og værktøjer, samt følger op på succeskriterier for vores system og tidsplan.
Indhold 1 Analysedokument 11 1.1 Formål...................................... 12 1.2 Systemdefinition................................ 12 1.3 System omgivelser............................... 12 1.4 Analyse af problemområde........................... 15 1.5 Analyse af anvendelsesområdet........................ 24 1.6 Anbefalinger................................... 38 2 Designdokument 41 2.1 Formål...................................... 42 2.2 Kvalitetsmål................................... 42 2.3 Teknisk platform................................ 44 2.4 Grundarkitektur................................. 45 2.5 Brugergrænseflader............................... 50 2.6 Model...................................... 69 2.7 Datamapperne................................. 80 2.8 Anbefalinger................................... 84 3 Implementering 85 3.1 Overblik..................................... 86 3.2 Gennemgang af implementering........................ 87 4 Studierapport 97 4.1 Projekt strategi................................. 98 4.2 Projektforløb.................................. 99 4.3 Fokusområde - algoritmer........................... 107 A Appendix 113 A.1 Brugergrænseflade skærmbilleder....................... 113 A.2 Forbilleder.................................... 117 A.3 Interaktionsmodel................................ 118
Kapitel 1 Analysedokument Dette kapitel kan læses som et selvstændigt analysedokument. I kapitlet dokumenteres de analytiske overvejelser, som projektgruppen har baseret udviklingen af find-vej systemet på. I denne analyse redegør gruppen blandt andet for problemområdet og anvendelseområdet. Indholdsfortegnelse 1.1 Formål................................. 12 1.2 Systemdefinition........................... 12 1.3 System omgivelser.......................... 12 1.3.1 Definition af problemområde.................... 13 1.3.2 Definition af anvendelsesområde.................. 15 1.4 Analyse af problemområde..................... 15 1.4.1 Struktur................................ 15 1.4.2 Klassebeskrivelser.......................... 17 1.4.3 Hændelsestabel............................ 23 1.5 Analyse af anvendelsesområdet.................. 24 1.5.1 Brug.................................. 24 1.5.2 Aktører................................ 24 1.5.3 Brugsmønstre............................. 25 1.5.4 Funktioner.............................. 31 1.5.5 Systemgrænseflade.......................... 32 1.5.6 Brugergrænseflade.......................... 32 1.6 Anbefalinger............................. 38 1.6.1 Nytte og realiserbarhed....................... 38 1.6.2 Strategi................................ 38 1.6.3 Økonomi............................... 38
12 Analysedokument 1.1 Formål Aalborg Universitet dækker over flere relativt store campus, fordelt i forskellige byer. Brugere af universitetet har ofte brug for at finde vej mellem flere campus eller rundt på et enkelt. Ideen er derfor at udvikle et system til at støtte brugerne i dette, på en mere hensigtsmæssig måde end de nuværende hjælpemidler. Systemets formål er, på en imødekommende måde, at lette tilgangen til information om placering af lokaliteter og faciliteter for brugere af disse, samt at hjælpe disse med at finde vej fra et sted til et andet. Desuden skal man kunne finde frem til institutter, studieretninger og personer. Systemet skal også fungere som en elektronisk opslagstavle for diverse begivenheder i området. 1.2 Systemdefinition Dette afsnit beskriver systemdefinitionen jf. Objekt Orienteret Analyse & Design OOADmodellens BATOFF-kriterier [8]. Betingelser: Informationssøgere og administrative aktører med varierende IT erfaring. Anvendelsesområde: Systemet anvendes af AAU og hertil knyttede personale til styring af information samt vejledning i at finde rundt på området. Teknologi: Systemet skal være anvendeligt på en computer med en CPU hastighed på 1300 MHz, 512 MB RAM-lager og 50 MB fri harddisk-plads, samt have installeret en Java runtime i standard udgaven. Endvidere skal det være muligt at benytte systemet via en touch-screen. Objekter: I systemet arbejdes der med elementerne lokation, organisation, knudepunkt, vej og opslag. Funktioner: Støtte informationssøgeren i at finde rundt på campus, samt at finde opslag og information om organisationer. Filosofi: Systemet skal kunne anvendes, hvor man ønsker at give personer et overblik over et fysisk område og placering af organisatoriske elementer. Dette skal foregå på en nem og brugervenlig måde, således at brugeren hurtigt kan føle sig bekendt med området. 1.3 System omgivelser Dette analysedokument bygger OOAD-modellen [8], hvori der tages hensyn til følgende to områder.
1.3 System omgivelser 13 1.3.1 Definition af problemområde Problemområdet består af de elementer, der findes i et givent fysisk område, hvorom man kunne have interesse i at stille spørgsmål. I systemet vil diverse fakulteter, studieretninger, personer m.m. være indbefattet. Personer kan opdeles i to kategorier: Personer der kan lokaliseres i systemet og dem der ikke kan, i systemets model medtages kun kategorien der kan lokaliseres. Problemskitse Problemskitsen figur 1.1 repræsenterer situationen, som den er i øjeblikket for personer, som har svært ved at finde rundt på campus. Når en sådan person ønsker at finde et givet sted på campus, kan vedkommende enten 1) søge hjælp på de opsatte kort og vejvisere, som findes i og uden for bygningerne, 2) søge hjælp hos en sekretær eller 3) spørge en tilfældig person på campus, medmindre personen ikke allerede ved hvor det er. Den første løsning henvender sig mest til studerende og ansatte, der har deres daglige gang på campus. Blandt andet fordi kortene som regel kun indeholder beskrivelser for den bygning de er placeret i, og vejviserne kun findes i et fåtal. Det andet scenarie kræver, at gæsten ved hvor der kan findes en sekretær og vil i givet fald afhænge en del af de tre andre muligheder. Den tredje mulighed en gæst har, kan resultere i en del usikkerhed hos denne, da det er umuligt at vide om den adspurgte ved hvor lokationen findes og i så fald taler sandt. Den sidste mulighed finder hovedsageligt sted, når gæsten tidligere har været på campus en eller flere gange og skal finde et sted, som vedkommende har været før.
14 Analysedokument Figur 1.1: Skitsering af problemområdet
1.4 Analyse af problemområde 15 1.3.2 Definition af anvendelsesområde Anvendelsesområdet indbefatter de aktører, der, direkte eller indirekte, har til opgave at informere om, hvorledes man orienterer sig i området. Endvidere indeholder anvendelsesområdet de aktører, der skal anvende systemet til at orientere sig i området med. På AAU campus, består aktørerne af informationssøgere, sekretærer og administratorer. Forbilleder I forbindelse med foranalysen af anvendelsesområdet, har gruppen haft tre forbilleder. Internetsiden www.krak.dk, informationsstander-systemet der allerede eksisterer på campus - Kroghstræde 3 og et lignende system der benyttes i City Syd indkøbscentret. Internetsiden www.krak.dk inspirerer til, hvordan en informationssøger relativt nemt kan finde fra et punkt til et andet, eller finde information om en virksomhed eller person. Informationsstanderne på Kroghstræde 3, er et godt eksempel på hvordan information om begivenheder, aktiviter, nyheder mm. nemt og overskueligt kan offentliggøres til universitets brugere. City Syd er en samling af små og store butikker, med varer fra vidt forskellige kategorier. Informationsstanderen i City Syd har inspireret til, hvordan de to forrige systemer, kan kombineres og derved både vise information om begivenheder m.m., samt skabe et overblik via interaktiv vejvisning på kort (Appendix A.2 side 117 beskriver disse forbilleder yderligere). 1.4 Analyse af problemområde Dette afsnit er en dybdegående analyse af det før beskrevne problemområde. Først konstrueres en model af problemområdet og derefter beskrives de enkelte klasser og hændelser i detaljer. 1.4.1 Struktur I klassediagrammet på figur 1.2 har vi tolv klasser, der modellerer problemområdet. Klassen Knudepunkt er hovedsageligt noget kortteknisk, men også sådan som en person vil opfatte virkeligheden, f.eks. hvor to veje mødes. Den abstrakte klasse Lokation nedarver fra Knudepunkt, da enhver lokation i sig selv også er et knudepunkt. Klasserne Plads, Campus, Bygning samt Lokale nedarver alle fra Lokation klassen, da de alle er lokationer. Plads og Bygning er en dekomponering af Campus, da et Campus består af en mængde pladser og Bygninger. Lokale er en dekomponering af Bygning, da en bygning indeholder et eller flere lokaler. Der eksisterer en relation mellem Knudepunkt og Vej, da en vej går fra et knudepunkt til
16 Analysedokument Figur 1.2: Klassediagram et andet og et knudepunkt kan have uendeligt mange veje tilkoblet. Klasserne Fakultet, Studieretning og Person nedarver alle fra den abstrakte klasse DelOrganisation, da alle objekter af disse klasser er et element i den samlede organisation der udgør AAU. Fakultet en relation til Campus, da et fakultet kan høre hjemme på et eller flere campus. Studieretning har en relation til Bygning, da en studieretning er tilknyttet en eller flere bygninger. Person har en relation til Lokale, da en person er tilknyttet et lokale, f.eks. et grupperum, et kontor m.v. Vi har bevidst valgt ikke at bruge rollemønstret i forbindelse med person klassen, da de ting der adskiller ansatte fra studerende sagtens kan beskrives alene ud fra attributter. Den abstrakte klasse Opslag har tre relationer, en til Lokation, DelOrganisation (Arrangør) samt Person (Kontaktperson). Relationen til Lokation viser at et Opslag kan have tilknyttet nul til mange lokationer, f.eks. en fest der har tilknyttet et eller flere lokaler. Relationen til Person viser at et Opslag har en kontaktperson. Relationen til DelOrganisation viser at et Opslag har en Arrangør i form af en delorganisation. Klassen kan deles op i uendeligt mange underklasser, da et opslag om en organisatorisk ændring og et opslag for en gæsteforelæsning vil have forskellige attributter. Det kan sammenlignes lidt med en opslagstavle,
1.4 Analyse af problemområde 17 hvor vi leverer tavlen og tegnestifterne, men hvad der bliver opsat på tavlen, er ligegyldigt for systemet. Klynger For at øge overskueligheden yderligere har vi delt klasserne op i følgende tre klynger: kort, organisation og begivenheder. Kort: Indeholder klasserne Vej, Knudepunkt, Lokation, Plads, Campus, Bygning og Lokale, da disse klasser indeholder data om, hvorledes campusområdet er opbygget rent geografisk og hvilke elementer campusområdet indeholder. Organisation: Indeholder klasserne Institut, Studieretning, Person og DelOrganisation, da disse klasser indeholder data om den organisatoriske opbygning af AAU. Begivenheder: Indeholder klassen Opslag, da denne indeholder data om hvor og hvornår en begivenhed foregår og hvem den afholdes af, samt en kontaktperson. 1.4.2 Klassebeskrivelser I det følgende afsnit redegør vi for klasserne i problemområdet. Nedarvede attributter er ikke nævnt i attributlisterne. Vej Et objekt af klassen Vej er defineret ved et stykke vej, der går fra et knudepunkt til et andet. I vores eksempel er dette de forskellige veje, stier osv. på AAU. Attributter: Længde, Type, Navn. Figur 1.3: Tilstandsdiagram for klassen Vej
18 Analysedokument Knudepunkt Et objekt af klassen Knudepunkt er defineret ved et punkt, hvor en eller flere veje ender. I vores eksempel er dette f.eks. vejkryds, lokationer osv. Attributter: Placering (definerer knudepunktets placering i et koordinatsystem, via et koordinatsæt). Figur 1.4: Tilstandsdiagram for klassen Knudepunkt Lokation Klassen Lokation er en abstrakt klasse, som repræsenterer et sted. Attributter: Navn, Kommentar. Campus Et objekt af klassen Campus er defineret ved et givet universitetsområde, f.eks. området omkring Kroghstræde eller Myrdahlstræde, eksklusiv bygninger der ikke tilhører universitetet. Attributter: Adresse, Kontaktinfo. Figur 1.5: Tilstandsdiagram for klassen Campus
1.4 Analyse af problemområde 19 Bygning Klassen repræsentere en bygning på et givet campus, f.eks. E-bygningen på Frederik Bajers Vej 7. Attributter: Adresse, Tilstand. Figur 1.6: Tilstandsdiagram for klassen Bygning Lokale Et objekt af klassen Lokale er defineret ved et givet lokale i en given bygning. I vores eksempel er disse lokaler i bygninger på campusområdet. Attributten Navn som er arvet fra Lokation, agerer lokale-nummer. Attributter: Etage, Type. Figur 1.7: Tilstandsdiagram for klassen Lokale
20 Analysedokument DelOrganisation Klassen DelOrganisation er en abstrakt klasse, som repræsenterer en del af en organisation. Attributter: Navn, Kommentar. Fakultet Et objekt af klassen Institut er defineret ved et givet institut på et givet campus. I vores eksempel er dette fakulteterne, der hører hjemme på campusområdet. Typen på attributten Kontaktinfo er ikke fastlagt, og bestemmes af organisationen; muligheder er e-mail-adresser og telefonnumre. Attributter: Kontaktinfo. Figur 1.8: Tilstandsdiagram for klassen Fakultet Studieretning Et objekt af klassen Studieretning er defineret ved en given studieretning ved et givet institut. I vores eksempel er dette alle studieretningerne ved institutterne på AAU. Attributter: Sekretær. Figur 1.9: Tilstandsdiagram for klassen Studieretning
1.4 Analyse af problemområde 21 Person Et objekt af klassen Person er defineret ved en person tilknyttet en given studieretning. I vores eksempel er dette alle personer på AAU, der er tilknyttet en given studieretning ved et af institutterne på AAU. Attributter: Titel, Type, Kontaktinfo. Figur 1.10: Tilstandsdiagram for klassen Person En person kan naturligvis også skifte studie/job, samt flytte lokale, men dette ændrer ikke på andet end relationerne til hhv. studieretning og lokale.
22 Analysedokument Opslag Et objekt af klassen Opslag er defineret ved et opslag om et arrangement, der kan afholdes på en lokation, af en arrangør og en kontaktperson. Attributter: Titel, StartTid, SlutTid, Beskrivelse, UdløbsTidspunkt. Figur 1.11: Tilstandsdiagram for klassen Opslag
1.4 Analyse af problemområde 23 1.4.3 Hændelsestabel Hændelser/Klasser Vej Knudepkt. Lokation Plads Lokale Delorg. Fak. Stud. retn. Person Opslag Campus Bygning Vej bygget + * Vej revet ned + * Vejtype ændret * * Vej frakoblet * * Vej tilkoblet * * Vejkrydsning * * Campus bygget * * + Campus revet ned * * + Campusinfo ændret * * * Bygning bygget * * + Bygning revet ned * * + Bygningsinfo ændret * * * Lokale bygget + * Lokale revet ned + * Fakultet oprettet + * Fakultet nedlagt + * Fakultet info ændret * * Studieretn. oprettet * + * Studieretn. nedlagt * + * Studieretninfo ændret * * * Optaget/Ansat * * + Udmeldt/Opsagt * * + Offentliggjort * * * + Ændret * * * + Aflyst * * * + Udløbet * * * + Figur 1.12: Hændelsestabel - * betyder multibelt og + betyder enkelt
24 Analysedokument 1.5 Analyse af anvendelsesområdet I dette afsnit vil vi analysere det tidligere definerede anvendelsesområde. Herunder gennemgåes brug af systemet, funktioner, brugergrænseflade, den tekniske platform og anbefalinger. 1.5.1 Brug Aktørenes brug af systemet forventes, i søgningshenseende, primært at foregå i et miljø med begrænset input muligheder, såsom på en information-stander med touch-screen. Det er derfor nødvendigt at gøre søgning af informationer så let, at der ikke er behov for gængse input enheder (mus og tastetur). Desuden har gruppen valgt, at der parallelt med en søgning af steder (lokations elementer) kan skiftes til kort tilstand hvor skærmbilledet viser det område der søges efter, desuden vil det være muligt at skifte fra kort tilstand til tekst tilstand. Systemets opgaver er naturligt opdelt i tre dele, jf. systemets tre aktører (se afsnit 1.5.2). Gruppen har med baggrund i dette besluttet at opdele systemets brugergrænseflade i tre separate komponenter. Disse er Informationsstander-, Administrator- og Sekretærbrugergrænsefladen. 1.5.2 Aktører Der findes tre aktører, Informationssøgere, Sekretær og Administrator, hvor de sidste to er dem, der i definitionen bliver omtalt som administrative aktører. Denne specialicering skyldes deres roller. Det er dog relevant at tydeliggøre, at disse ikke nødvendigvis har samme funktion i den oprindelige organisation, f.eks. kan en studerende ved AAU godt være administrator i dette system. Informationssøgere Formål: En person der anvender systemet til at finde vej eller information om elementer i problemområdet. Informationssøgerens basale behov, er at kunne foretage forespørgelser om en lokation i området. Karakteristik: Informationssøgere omfatter mange personer med forskellige erfaringer og behov. Blandt andet har studerende og ansatte behov for hurtigt og nemt at kunne lave forespørgsler. En gæst vil ofte have behov for en mere udførlig hjælp til at stille de rigtige spørgsmål, for dermed at kunne få det ønskede svar. Systemet henvender sig til fodgængere, der er i stand til at aflæse og anvende en touch-screen. Sekretær Formål: En sekretær er administrator for systemets informations indhold.
1.5 Analyse af anvendelsesområdet 25 Karakteristik: Systemet omfatter flere sekretærer, der har stor kendskab til brug af systemet, samt til redigering af opslag og organisationen. Administrator Formål: En administrator er en person med fuld adgang til alle dele af systemet. En administrators primære opgave er at vedligeholde de basale forudsætninger for systemet (herunder opsætning af kortet). Desuden har denne til opgave at administrere eventuelle brugerrettigheder (for systemets sekretærer). Karakteristik: Systemet indeholder en eller flere administratorer med udvidet kendskab til systemet og de underliggende teknologier, desuden kræves det af administratoren at denne har god kendskab til områdets fysiske layout. 1.5.3 Brugsmønstre Anvendelsen af systemet omfatter syv primære mønstre, Find Person, Find Sted, Find Studie, Se Opslag, Behandl opslag Behandl kort og Behandl Organisation. Mønstrene Behandl kort og Behandl Organisation er sammensat af en mængde sekundære brugsmønstre, figur 1.14 side 26 beskriver sammenhængen mellem mønstrene og afsnit 1.5.3 side 30, beskriver sekundære brugsmønstre mere detaljeret. Aktør Brugsmønster Informationssøger Sekretær Administrator Find Person Find Sted Find Studie Se Opslag Behandl opslag Behandl kort Behandl Organisation X X X X X X X Figur 1.13: Primære Aktør- og brugsmønstertabel
26 Analysedokument Figur 1.14: UML Brugsmønster: relationer mellem brugsmønstre, de grå elementer er primære brugsmønstre og de hvide er sekundære
1.5 Analyse af anvendelsesområdet 27 Find Person Målet med dette brugsmønster er at finde frem til information om, eller placeringen af en person. Dette er opnået når informationssøgeren er overbevist om, at den søgte person ikke findes eller de ønskede informationer er fundet og aflæst. Søgning efter person er tilgængelig fra systemets hovedmenu, figur 1.15 beskriver denne situation. Det er desuden muligt at tilgå information om en person via information om et sted eller studie (se evt. afsnit Find Sted og Find Studie ). Find Person Brugsmønster: (1) Vælg Find Person i menuen, indtast personens navn helt eller delvist og tryk søg. (2) Systemet svarer med et eller flere resultater. (3) Hvis nødvendigt præciseres søgningen for at mindske antallet af resultater. (4) Information om den valgte person vises. Funktioner: Find Person, Vis Person Figur 1.15: Brugsmønster: Find Person Find Sted Målet med dette brugsmønster er at finde information om den søgte lokation (se klasse diagrammet figur 1.2 for klasserenes sammenhæng). Figur 1.18 der kombiner tilstandsdiagrammet for dette og Find Studie mønstreret, endvidere viser figur 1.16 fremgangsmetoden for dette mønster. Find Sted Brugsmønster: (1) Vælg Find sted i menuen og naviger 1 til det ønskede sted eller naviger via kortet til det sted der ønskes information om. (2) Information og evt. rute til det valgte vises. Objekter: Alle objekter i modellens organisations- og kortklynge kan blive berørt i dette mønster Funktioner: Vis Sted, Find Sted, Vis Rute Figur 1.16: Brugsmønster: Find Sted
28 Analysedokument Find Studie Målet med dette brugsmønster er at finde information om, eller placeringen af, en delorganisation (se klasse diagrammet figur 1.2 for klasserenes sammenhæng). For at opnå målet skal informationssøgeren navigere sig til den ønskede niveau i modellen, via systemets Tekst tilstand (Se figur 1.17 og 1.18). Find Studie Brugsmønster: (1) Vælg Find Studie i menuen og naviger til den delorganisation der ønskes information om. (2) Information om det valgte vises. Objekter: Alle objekter i modellens organisationsklynge kan blive berørt i dette mønster Funktioner: Vis Studie, Find Studie Figur 1.17: Brugsmønster: Find Studie Figur 1.18: UML Brugsmønster: Find information om Sted eller Studie Se Opslag Målet med dette brugsmønster er at aflæse et opslag på systemets opslagstavle, dette mønster vil typisk resultere i et spring til et af de foregående mønstre. Fx kunne man tænke sig, efter at have læst et opslag om et foredrag, at ville vide hvor det tilknyttede lokale befinder sig på campus. Figur 1.19 beskriver dette mønster nærmere. 2 2 Dette brugsmønster er ikke implementeret i brugergrænsefladen
1.5 Analyse af anvendelsesområdet 29 Se Opslag Brugsmønster: (1) Vælg Opslag i menuen. (2) Opslag for den pågældende dag vises. (3) Hvis opslag for en anden dato ønskes vist, vælges dette i kalenderen. Systemet svarer med opslag for den valgte dato. (4) Opslag vælges og information og valgmuligheder om det valgte vises. Bemærkning: Fra et opslag er det muligt at skifte til et af Find mønstrene. Punkt 2 og 3 er iterative. På opslagstavlen er opslag er sorteret efter dato. Funktioner: Find/Vis Opslag Behandl opslag Figur 1.19: Brugsmønster: Se Opslag Målet med dette mønster er at oprette/slette/redigere opslag, som informationsøgeren har mulighed for at se i systemets opslagstavle, dette foregår via Sekretær-brugergrænsefladen. Dette opnås når sekretæren har indtastet de nødvendige informationer defineret i systemets klassediagram side 16. Figur 1.20 illustrerer dette mønster. Behandl opslag Brugsmønster: (1) Vælg Opslag i menuen. (2) Opslag for den pågældende dag vises. (3) Hvis opslag for en anden dato ønskes vist, vælges dette i kalenderen. Systemet svarer med opslag for den valgte dato. (4) De viste opslag kan vælges og information og redigeringsmuligheder om denne vises. Yderligere kan der tilføjes nye opslag og slettes eksisterende. Objekter: opslag, lokation, arrangør, person Bemærkning: Se klassediagrammet side 16 for krav til tilknyttede objekter Funktioner: find/vis/rediger/opret Opslag Figur 1.20: Brugsmønster: Behandl opslag
30 Analysedokument Behandl kort Målet med dette sammensatte mønster er at administrere fysiske dele af modellen (se evt. kort klyngen side 16). For at opnå dette mål er det administratorens opgave at kombinere de sekundære brugsmønstre. (Se figur 1.21 og afsnittet Sekundære brugsmønstre for en komplet liste over de sekundære brugsmønstre). Ved behandling af kort vælges først et værktøj til at udføre et af de sekundære brugsmønstre på figur 1.21 (der tilhører kategorien Behandl kort ), derefter vælges der hvor på kortet det valgte ønskes udført. Behandl organisation Målet med dette sammensatte mønster er at administrere organisatoriske dele af modellen (se evt. organisations klyngen side 16). Mønsteret er tæt knyttet til det foregående, da elementerne af organisationen skal have tilknytning til en specifik lokation. Målet for dette mønster opnås, når en sekretær har behandlet en tilstrækkelig delmængde af den faktiske organisation, til at tilfredsstille informationssøgerens behov. Dette opnås ved at anvende mønsterets tilhørende sekundære brugsmønstre, der hver især behandler enkeltstående elementer i modellen (se afsnittet Sekundære brugsmønstre side 30). Sekundære brugsmønstre Disse mønstre er atomare og omhandler redigering/oprettelse/slettese af fænomener tilknyttet modellens kort eller organisations klynge. I forbindelse med oprettelse/redigering af de enkelte elementer, er deres attributter og kardinalitet eksplicit defineret i klassediagrammet side 16 og afsnittet Klassebeskrivelser side 17. Sekundære mønstre Brugsmønster Behandl Kort Behandl Organisation Opret/rediger/slet Knudepunkt Opret/rediger/slet Vej Opret/rediger/slet Plads Opret/rediger/slet Campus Opret/rediger/slet Bygning Opret/rediger/slet Lokale Opret/rediger/slet Fakultet Opret/rediger/slet Studieretning Opret/rediger/slet Person Funktioner: find/vis/rediger/opret element X X X X X X X X X Figur 1.21: Sekundære, sammensatte brugsmønstre
1.5 Analyse af anvendelsesområdet 31 1.5.4 Funktioner Ud fra brugsmønstrene, udarbejdet i det foregående afsnit, har gruppen udarbejdet en tabel over systemets funktioner (se figur 1.22). Her er det dog værd at bemærke, at funktionen Rediger inbefatter tilknytning og ændring af attributter på de enkelte klasser. Lokation redigeres fx når navnet ændres eller når den tilknyttes en organisation. Funktion Kompleksitet Type Skift View Simpel Aflæsning Find Person/Sted/Studie Simpel Aflæsning Find Rute Særdeles kompleks Beregning Find Opslag Simpel Aflæsning Find Bygning/Lokale/Plads Simpel Aflæsning Vis Person/Sted/Studie Simpel Aflæsning Vis Opslag Simpel Aflæsning Vis Bygning/Lokale/Vej/Plads Simpel Aflæsning Opret/Rediger/Slet Opslag Simpel Opdatering Opret/Rediger/Slet Knudepunkt Simpel Opdatering Opret/Rediger/Slet Vej Simpel Opdatering Opret/Rediger/Slet Plads Simpel Opdatering Opret/Rediger/Slet Bygning Simpel Opdatering Opret/Rediger/Slet Lokale Simpel Opdatering Opret/Rediger/Slet Studie Simpel Opdatering Opret/Rediger/Slet Person Simpel Opdatering Figur 1.22: Funktionstabel i campus eksemplet I tabellen er funktionen Find Rute defineret som en særdeles kompleks funktion. Dette skyldes at denne funktion er ansvarlig for at udregne og vise den korteste rute mellem to lokationer på kortet. Gruppen anser dette problem for værende komplekst, da denne funktion vil kræve anvendelse af grafteori herunder best route algoritmer. De resterende funktioner er defineret som simple, da disse kun opretter, sletter, retter, finder eller viser data, der ikke behandles af komplekse algoritmer. I forbindelse med denne analyse og det senere design, har gruppen analyseret de algoritmer og datastrukturer der anvendes af denne funktion. For mere information om denne analyse se afsnit 4.3 side 107 i projektets studierapport under fokusområde.
32 Analysedokument 1.5.5 Systemgrænseflade På AAU er studerende, ansatte, undervisere, lokaler osv. registreret i diverse andre systemer. Derfor ville det være en fordel at kunne drage nytte af disse systemer, for at undgå at indtastning og opdatering af data foregår flere steder. Systemet kunne med fordel gøre brug af universitetets LDAP, server til at hente information om studerende og ansatte. Dette bliver ikke implementeret i programmet, men vi opbygger det således, at det senere er muligt at implementere. 1.5.6 Brugergrænseflade Da opbygning af kort til brug i systemet er en relativ kompleks aktivitet, bliver det nødvendigt med et værktøj til at tegne disse. Derfor er der, udover informationsstanderbrugergrænsefladen, planlagt at lave en administrator-brugergrænseflade, der stiller værktøjer til korttegning til rådighed. Informationstanderen Dette afsnit omhandler brugergrænsefladen til informationsstanderen. På figur 1.23 vises et navigeringsdiagram over hvorledes informationsstander-brugergrænsefladen er opbygget. Systemet startes i Kort tilstand, hvorefter der kan vælges mellem at navigere på kortet eller at trykke på en af de fire knapper i menuen. Disse knapper viser enten vinduet Vis Sted, Opslag, Vis studie eller Find Person. På figur 1.24 ses hovedskærmen som vises ved opstart af programmet. I venstre side ses en menu, som er tilgængelig i alle dele af programmet. Menuen indeholder en Reset-knap, som gør at alle søgninger bliver nulstillet og hovedskærmen skifter til det første kort i systemet. Under denne indeholder menuen tre Find -knapper, der benyttes til følgende: Find sted: Benyttes til at finde steder. Dette foregår ved at der på øverste niveau findes en liste med lokationer i området, hvis man derefter trykker på en af disse, vises en liste over lokationer i den valgte lokation. Et billede af Find sted skærmbilledet kan ses i Appendix A.3, side 115. Find person: Benyttes til at finde personer der er tilknyttet AAU. Dette foregår ved at brugeren indtaster hele, eller dele af navnet på den person der ønskes fundet. Da programmet som nævnt afsnit 1.5.1, side 24 skal være anvendeligt i forbindelse med en touch-screen, er der lavet et virtuelt tastatur på skærmen. Et billede af Find person funktionen kan ses i Appendix A.2, side 114. Find studie: Benyttes til at finde organisatoriske enheder på AAU, såsom studieretninger, fakulteter osv. Dette foregår ved, at der på øverste niveau findes en liste
1.5 Analyse af anvendelsesområdet 33 Figur 1.23: Navigeringsdiagram for informationsstander-brugergrænsefladen med fakulteter. Trykker man derefter på en af disse fakulteter, vises en liste over tilhørende studieretninger. Et billede af Find studie funktionen kan ses i Appendix A.4, side 116.
34 Analysedokument Figur 1.24: Informationsstander programmets udseende
1.5 Analyse af anvendelsesområdet 35 Administrator Dette afsnit beskriver administratorens brugergrænseflade. Figur 1.25 vises et navigeringsdiagram over hvorledes administrations-brugergrænsefladen er opbygget. Ved første programstart skal navn på campus indtastes og et billede der repræsenterer et kort over det pågældende område indsættes. Herefter vises kortet, med værktøjer så det er muligt at placere korttekniske elementer herpå. Det er derudover muligt at tilknytte organisationer til disse elementer i form af tilknyt organisationer vinduet. Figur 1.25: Navigeringsdiagram for administrations-brugergrænsefladen Ved første opstart af programmet vises en dialogboks, hvor stednavnet og navnet på den organisation kortet skal dække over indtastes. Derefter vises en dialogboks hvor baggrundsbilledet for det øverste kort indsættes, dette gøres ved at benytte et eksisterende billede, luftfoto eller lignende, på filsystemet. Figur 1.26 viser dette skærmbillede, efter indtastning af førnævnte informationer, samt oprettelse af fire lokationer med tilhørende veje.
36 Analysedokument Figur 1.26: Kort administrations programmets udseende
1.5 Analyse af anvendelsesområdet 37 Hovedskærmen består af fire undervinduer samt en værktøjslinje. De fire undervinduer er navngivet Værktøjer, Tegneflade, Egenskaber og Hjælp, de benyttes til følgende: Værktøjer: Benyttes til at vælge hvad der skal tegnes/redigeres på tegnefladen, f.eks. en vej eller et knudepunkt. Tegneflade: Benyttes til redigere kortet, med det valgte værktøj fra Værktøjer - undervinduet. Egenskaber: Viser egenskaber for det valgte element på tegnefladen og gør det muligt at redigere disse. Fx længden på en vej, navnet på en bygning osv. Hjælp: Viser en hjælpetekst til det aktuelle værktøj. Værktøjslinjen indeholder Et niveau op -knappen, til at navigere til niveauet over det der p.t. vises på tegnefladen. Knappen Tilknyt Organisation viser vinduet på figur 1.27. Dette benyttes til at visualiserer lokations- og Organisationshierarkiet, samt at redigere mange-til-mange forholdet mellem delorganisationer og lokationer. Figur 1.27: Tilknyt Organisation vinduet
38 Analysedokument 1.6 Anbefalinger Dette afsnit indeholder gruppens anbefalinger og vurdering i forbindelse med viderudvikling af den belyste problemstilling. 1.6.1 Nytte og realiserbarhed Det er gruppens forventning, at der med det rette design, ikke foreligger opgaver af en sådan karakter, at man på forhånd kan afvise projektets succes. Dette skyldes, at de tekniske krav til systemet anses for værende tilgængelige under de fleste forhold. Desuden forventer gruppen, at systemets kompleksitet relativt uproblematisk vil kunne håndteres i en projektorganisation, hvor ressourcer og planlægning håndteres korrekt. Endvidere er det gruppens formodning, at systemet vil kunne bidrage positivt til den daglige arbejdsgang hos brugerne ved en organisation som AAU. 1.6.2 Strategi Under den videre udvikling vil gruppen anbefale en udviklingsmodel, baseret på en iterativ proces såsom OOAD eller extreme Programming XP[3]. Da design, implementering og testing foregår jf. analysens brugsmønstre i tæt samarbejde med den endelige bruger. Endvidere vil gruppen anbefale, at der på et tidligt stadie, hvis muligt, fastlægges en prioritering af de tre kvalitetsparametre[11]: tid, pris og kvalitet. 1.6.3 Økonomi For at kunne vurdere hvad det vil koste at udvikle dette system, vil vi beregne hvilke udgifter der ville være for et softwarehus; skulle det udvikles af dem. Følgende betragtning er meget simpel, dog mener vi, at dette er nok til at vurdere hvorvidt systemet er rentabelt. Det antages, at medarbejderne er timelønnet til en pris på 500 kr 3 når kunden skal faktureres. Der er andre udgifter end til betaling af udviklere, men dem vælger vi at se bort fra. Vi kun er interesseret i at konkludere, om systemet bliver for dyrt at udvikle til én enkelt kunde, eller om det istedet egner sig bedre som et hyldeprodukt. Udaf en gruppe på fire studerende, udregnes hvor mange timer hver enkel har til rådighed; Semesterskemaet viser at hver studerende har 48 timer 4 til rådighed til analysedokumentet 5, dvs. fra semester-start og indtil 1. review. Til udarbejdelse af designet har hver studerende 44 timer (11 moduler), dvs. fra 1. review indtil 2. review. Slutteligt haves 148 timer 3 Denne pris er fastsat som mindstepris 4 12 moduler * 4 timer/modul 5 timer udenfor arbejdstid medregnes ikke
1.6 Anbefalinger 39 (37 moduler) pr. studerende inden aflevering. I alt giver dette 240 timer. Da der er fire studerende i gruppen, er der sammenlagt 960 timer til rådighed. Med en takst på 500 kr/time, er det 480,000 kr. Det vil derfor være mere fordelagtigt at finde flere købere til systemet.
40 Analysedokument
Kapitel 2 Designdokument Dette designdokument er udarbejdet under projektet Findvej. Dokumentet redegører for systemets design, herunder kvalitetsmål, arkitektur og komponent design. Slutteligt vil dette dokument indeholde gruppens anbefalinger i forbindelse med implementering af systemet. Indholdsfortegnelse 2.1 Formål................................. 42 2.2 Kvalitetsmål............................. 42 2.3 Teknisk platform........................... 44 2.4 Grundarkitektur........................... 45 2.5 Brugergrænseflader......................... 50 2.5.1 Informationsstander brugergrænsefladen.............. 50 2.5.2 Administrator brugergrænsefladen................. 58 2.6 Model................................. 69 2.6.1 Domæne-objekter........................... 70 2.6.2 Findvej................................ 73 2.6.3 Kernen................................ 74 2.7 Datamapperne............................ 80 2.7.1 JDBC mapperne........................... 80 2.7.2 Memory Mapperne.......................... 81 2.7.3 Persistens............................... 82 2.8 Anbefalinger............................. 84 2.8.1 Systemets nytte............................ 84 2.8.2 Plan for ibrugtagning........................ 84 2.8.3 Implementeringsplan......................... 84
42 Designdokument 2.1 Formål Systemets formål er, på en imødekommende og effektiv måde, at lette tilgangen til information om placering af faciliteter ved AAU. Desuden skal systmet hjælpe med at finde vej fra et sted til et andet, via den kortest tilgængelige rute. Den grundlæggende problematik, at finde vej, er af så generel karakter, at man vil kunne drage fordel af at abstrahere fra AAUs problem. I stedet vil man kunne designe systemet med henblik på den generelle problemstilling at modellere, et givet geografisk område og tilhørende organisationer elektronisk. Dette skal modelleres på en sådan måde at man derefter at benytte data fra denne model til at finde den korteste rute mellem to punkter. Dette dokument vil derfor afvige fra projektets analysedokument, der er skarpt tilknyttet AAU. Istedet er det hensigten at tilpasse designet til en generel hierarkisk model af organisationer og lokationer, der samtidig opfylder kravene fra analysedokumentet. Ved at tilstræbe en generel løsning af problemet, tilgodeses gruppens anbefalinger fra afsnit 1.6.3 i analysedokumentet. Afgrænsninger Grundet gruppens prioritering af kvalitet over tid, er den mindste af de tre grænseflader, Sekretær, ikke blevet designet og vil derfor ikke optræde yderligere i dette dokument. Endvidere har gruppen valgt at fravælge design af informationsstanderens opslagstavle. Dog understøttes denne funktionallitet af modellens design. 2.2 Kvalitetsmål I forbindelse med evaluering af systemets design, har gruppen prioriteret OOAD[8] designkriterierne som beskrevet i figur 2.1. Gruppen har vurderet kriterierne Effektivt, Korrekt, Testbart og Genbrugbart som meget vigtige og kriteriet Flytbart som trivielt. Denne prioritering skyldes hovedsageligt, at visse kvalitetsmål har høj interesse fra et udannelsesmæssig synspunkt. Desuden skyldes den høje prioritering, af netop disse kriterier, at dette vil resultere i et produkt af højere kvalitet 1. Vi vil i det følgende argumentere for det enkelte kriteries medvirken til at opnå denne kvalitet. Ved at levere et effektivt produkt, sikrer vi at brugeren inden for en tilfredsstillende tids- 1 Et produkts kvalitet er defineret ved, en eller flere personers vurdering af overensstemmelsen mellem deres forventninger til- og oplevelse af et produkt
2.2 Kvalitetsmål 43 ramme 2, (efter indtastning) kan aflæse den ønskede information. Ved at sikre at programmets funktionalitet er korrekt og ikke resulterer i ugyldig data, øges pålideligheden og brugbarheden af systemet indirekte. Gruppen har prioriteret testbar kriteriet højt, da dette påviser hvorvidt systemet reagerer forudsigeligt i udviklingsforløbet (se afsnit 4.2.3, side 104 om automatiserede tests). Indirekte øger kriteriet testbar, i forbindelse med filosofien bag Test-Driven Development [2](TDD), forståeligheden af systemets kildekode. Dette resultere i, at mængden af fejl, der opstår under vedligeholdelse af systemet, mindskes. Som beskrevet i afsnit 2.1, er det gruppens hensigt at udvikle et design, der kan tilpasses andre systemer, der omhandler samme grundlæggende problematik. Dette afspejles i design kriteriet genbrugbart, som gruppen ligeledes har prioriteret højt. Klassificering af kriteriet flytbart som triviel, skyldes det valgte implementering sprog Java (se afsnit 2.3 side 45). Kriterie Brugbart Sikkert Effektivt Korrekt Pålideligt Vedligeholdbart Testbar Fleksibelt Forståeligt Genbrugbart Flytbar Integrerbar Meget vigtig Vigtig Mindre vigtig Irrelevant Trivielt X X X X X X X X X X X X Figur 2.1: Kriterier i forbindelse med design Succeskriterier og kvalitetssikring Gruppen har i forbindelse med kvalitetsmål, valgt at opstille en række succeskriterier, til evaluering af designet i forhold til højt prioriterede kvalitetsmål. 2 Ifølge Dr. Jakob Nielsen, er denne tidsramme 10 sekunder, taget fra http://www.useit.com/papers/ responsetime.html, et uddrag fra bogen Usability Engineering
44 Designdokument For at sikre systemets effektivitet, kontroleres systemets design for særligt tidskrævende operationer. Sådanne operationer vil efterfølgende blive analyseret, for at vurdere om en bedre løsning eksisterer. Gruppen anser dette kvalitetsmål som værende opfyldt, når systemet har opnået en tilstand, hvor der ikke længere eksisterer usikre designelementer, der kan resultere i høje svartider. For at sikre at systemet fungerer korrekt, vil designvalg løbende blive sammenlignet med brugsmønstre og hændelser fra analysedokumentet. Gruppen anser dette kvalitetsmål, som værende nået når samtlige brugsmønstre understøttes af designet. For at opnå kvalitetsmålet testbar, vil gruppen designe systemet således, at der for flest mulige klasser findes fastlagte interfaces. Dette gør det muligt at bygge udførlige tests via værktøjet JUnit, der kan teste implementationen af disse. Gruppen anser dette mål for værende opfyldt, når testfunktioner er bygget for samtlige interfaces. For at sikre, at systemet bliver genbrugbart, vil gruppen tilstræbe at designe systemets komponenter således, at disse har en høj binding 3 og en lav kobling 4. For at sikre, at så stor en del som muligt af systemet kan genbruges, har gruppen blandt andet valgt at anvende generelle termer, således at disse ikke knytter sig til det aktuelle problemområde. Desuden udarbejdes designet således, at applikations- og forretningsspecifik logik, holdes til de klasser der i forvejen kun har med problemområdet at gøre. Gruppen anser dette mål for nået, når alt applikations- og forretningslogik er fjernet fra systemets kerne (se evt afsnit 2.6.3 side 74). 2.3 Teknisk platform I dette afsnit beskrives den tekniske platform, hvortil systemet bygges. Endvidere indeholder afsnittet begrundelser for specifikke valg og referencer til relevant litteratur. Udstyr For at køre systemet, kræves der en Java runtime version 1.4 eller højere, installeret på en 1300Mhz Pentium 3 med 512Mb RAM eller tilsvarende. Desuden kræves det at computer og skærm kan køre med en opløsning på mindst 1024*768 pixels. Endvidere vil informationssøgerens brugergrænseflade kunne bruges via. en touch-screen, dog er dette ikke et krav. 3 At komponenterne har et snævert ansvarsområde 4 At koblingen mellem objekterne foregår vha. fast definerede interfaces
2.4 Grundarkitektur 45 Basisprogrammel Da programmet skal være uafhængigt af det underliggende operativsystem, er der intet krav til dette. Dog skal dette understøtte kravene til udstyr, samt kunne afvikle en Derby database. Derby er valgt fordi den er en del af undervisningen på AAU i faget persistens. Derudover kan Derby afvikles i embedded mode, hvilket vil sige, at der ikke kræves en seperat databaseserver. Derby er ikke specielt hurtig, men da vi benytter Java DataBase Connectivity(JDBC), er det relativt nemt at udskifte databasen med en anden, hvortil der findes en JDBC driver. Systemgrænseflade I analysedokumentet, afsnit 1.5.5 side 32, har vi beskrevet en mulig systemgrænseflade til AAU s LDAP server. Vi har valgt at designe systemet således, at det ville være muligt at tilgå denne grænseflade, dog er dette ikke implementeret. Designsprog Det valgte designsprog til designdokumentet er UML 2.0[6], endvidere benyttes metoder og diagrammer fra OOAD [8]. Dog skal det bemærkes, at for at øge overskueligheden af designdokumentets UML diagrammer, er getter og setter funktioner til klassernes attributter ikke medtaget. 2.4 Grundarkitektur Designet af grundarkiteturen er baseret på en lukket-streng arkitektur [8]. Komponenterne der udgør systemet kan inddeles i tre lag, som vist på figur 2.2. Endvidere illustrere figuren afhængighed af den tekniske platform. Komponenterne er forbundet via fastlagte interfaces og hvert enkelt lag bliver indkapslet af det overliggende lag. Systemets grundlæggende tre-lags arkitektur er hentet fra bl.a. OOAD[8], dog suppleres der med mønstrene Service Layer, Domain Model og Data Mapper fra bogen Patterns of Enterprise Applications Architecture[5]. Arkitekturen er nærmere beskrevet i de følgende afsnit. Figur 2.2 illustrerer denne, samt lagenes afhængighed. Dette arkitektur-design er valgt, for at kunne udskifte de individuelle lag, uden at dette berører de overliggende. Det er f.eks. muligt i DataAccess laget, at skifte DataBase Management System (DBMS) da forbindelsen nedaf er bundet til et JDBC interface (se evt. afsnit 4.2.2, der beskriver en problemstilling, der løses af dette design). Endnu et eksempel er, at der kan udskiftes datamappere og derved skifte persistens type, til f.eks. flade filer eller en objekt-orienteret
46 Designdokument database (se evt. afsnit 2.7 om memorymappere). Det er yderligere muligt at benytte kernen i andre systemer, med helt andre problemstillinger. Dette betyder at kernen ikke indeholder kildekode, der er specifik for hverken find-vej problemstillingen eller vores specifikke problem. Kernen kan benyttes i alle systemer der bruger Domain Model-mønstret. Dette er valgt jf. designkriteriet afsnit 2.2 om genbrugeligt software, samt for at give kernen en lav kobling til resten af systemet.
2.4 Grundarkitektur 47 Figur 2.2: Konceptuel komponentarkitektur med afhængighedsforhold
48 Designdokument Komponentarkitektur På figur 2.2, ses den overordnede konceptuelle arkitektur og de tilhørende komponenter, samt hvorledes disse er afhængige af hinanden. Vi vil i dette afsnit gennemgå design filosofien bag denne arkitektur. Brugergrænseflade-laget Dette lag vil bestå af en af de tre brugergrænseflade komponenter: Informationsstander, Administrator og Sekretær. Disse komponenter repræsenterer individuelle brugergrænseflader til hver af de tre aktører fra analysen. Designet af disse komponenter er derfor tæt knyttet til det aktuelle problem, f.eks. at finde vej på AAU. Model-laget Dette lag indeholder tre konceptuelle komponenter: Kernen, Domæne Objekter og FindVej, der hver har deres centrale ansvarsområde. Kerne-komponenten indeholder det centrale framework i systemet. Dette framework er ansvarlig for, usynligt for klient-programmøren 5, at tildele DataMappers til de enkelte typer af domæne objekter, alt efter hvilke ressourcer der er tilrådighed i systemet. Endvidere styrer frameworket identits- og tilstandskontrol af domæne objekter (se afsnit 2.6.3). Domæne Objekter-komponenten indeholder de klasser, der skal modellere problemområdet. Desuden indeholder disse funktionalitet til at validere tilstanden af objektet i forhold til den gældende forretningslogik. Findvej-komponenten indeholder de klasser der ud fra modeldata, kan beregne den bedste rute mellem lokationer. Persistens-laget Dette lag indeholder komponenten DataMappers, der indkapsler persistens-laget (fx en JDBC DBMS). Da implementeringen af disse komponenter kan variere kraftigt, afhængig af den underliggende persistens, er designet baseret på fastlagte interfaces. Disse interfaces fungerer samtidig som et indikator til systemets framework, der indikere om mapperen er i stand til både at hente og gemme data, eller at kun hente. Tekniskplatform-laget Dette lag består af det før omtalte basisprogrammel (se evt. 2.3). 5 En klienten er et stykke software, der anvender en anden komponent i sit arbejde
2.4 Grundarkitektur 49 Design Standarder Den grafiske brugergrænseflade benytter de, i Java, indbyggede grafikkomponenter (SWING og AWT) og vil derfor have udseende derefter. Som omtalt i analysedokumentet, vil vi benytte JUnit til komponent-test, samt JavaDoc til en dokumentation af kildekoden. Vi vil følge Code Conversions for the Java Programming Language. Det oprindelige dokument fra Sun Microsystems 6, men da et så grundigt dokument ikke er nødvendigt, vil vi nøjes med den reducerede udgave fra Java bogen[4]. Til implementeringen anvendes Eclipse Platform 3.0 fra IBM, samt supplerende værktøjer til at konstruere og vedligeholde databasen. Indbygget i Eclipse er der understøttelse for CVS, så dette er et naturligt valg til versionsstyring. 6 findes på http://java.sun.com/docs/codeconv/
50 Designdokument 2.5 Brugergrænseflader Det følgende afsnit beskriver designet af systemets brugergrænseflader. Dette design er baseret på anvendelse af Java pakkerne AWT og Swing. For mere information om hvorledes disse virker, se pakkernes API på java.sun.com. 2.5.1 Informationsstander brugergrænsefladen Brugergrænsefladen til informationsstanderen er den del af systemet, hvor man jf. de opstillede krav fra analysen, har mulighed for at foretage søgninger på steder, personer, studier og opslag. Endvidere er det muligt at finde vej fra sted til sted. Følgende vil gennemgå klasser og hierarkier der anvendes til opbygning af denne brugergrænseflade. Det skal endvidere bemærkes, at termen komponent i dette afsnit, opfattes som en grafisk komponent og ikke nødvendigvis en opdeling i kildekoden. Figur 2.3 viser sammenhængen mellem logiske grupperede klasser i denne komponent. Figur 2.3: Oversigt over subarkitekturen i brugergrænsefladen til informationsstanderen. Hovedvindue klasserne Denne komponent indeholder klasserne: ViewChoice, LeftMenu, PathWindow, PublicGui og AsmBottom. Komponenten er ansvarlig for at samle hovedpanelerne i programmet og tilknytte dem til PathWindow. ViewChoice har forbindelse til komponenterne Grafik view og Tekst view. LeftMenu har ikke nogen videre forbindelse til de øvrige lag af brugergrænsefladen men leverer en menu der sørger for at få vist de rigtige paneler.
2.5 Brugergrænseflader 51 PathWindow klassen er en container for klasserne: ViewChoice, LeftMenu og AsmBottom og bliver vist som et fuldskærms vindue. PublicGui indeholder main metoden der starter og viser programmet. AsmBottom har forbindelse til komponenten Bundlinie. For at opfylde kravet om, at programmet skal afvikles på en touch-screen, genererer PathWindow klassen et fuldskærmsvindue uden mulighed for at afslutte. Figur 2.4 viser sammenhængen i denne komponent. ViewChoice Denne klasses ansvar er at levere to visningstilstande for brugeren og gør brug af et Card- Layout. Klassen har forbindelse til klasserne DrawPanel og TextPanel. Dette er designet således, for at opfylde kravet om at kunne søge i både tekst tilstand og kort tilstand (Se afsnit 1.5.1 side 24). Klassen er tilknyttet PathWindow klassens contentpane. LeftMenu Denne klasse er ansvarlig for at levere en menu hvor brugeren kan vælg søgningsmetode jf. afsnit 1.5.3 om brugsmønstre. Endvidere er den ansvarlig for at det korrekte panel til brugerens valg vises. LeftMenu klassen giver brugeren mulighed for at nulstille 7 systemet. Knapperne bliver præsenteret via et GridLayout med seks rækker og en kolonne. Klassen er tilknyttet PathWindow klassens contentpane. PathWindow Denne klasse er ansvarlig for at programmet vises i full-screen. Endvidere er PathWindow ansvarlig for at levere en container, som alle hovedelementerne bliver samlet på. Klassen kontrollerer om maskinen, der afvikler programmet, direkte understøtter fullscreen og gør den ikke dette, simulerer den en tilsvarende tilstand. Klassen bliver instantieret af PublicGui og derefter fremvist. PublicGui Denne klasses ansvar er at starte og vise programmet. Desuden sørger klassen for at alle hovedelementer (ViewChoice, LeftMenu og AsmBottom) bliver samlet på PathWindow klassens container. Klassen laver en instans af klassen PathWindow og synliggør vinduet. AsmBottom Denne klasse er ansvarlig for at samle klasserne BottomMenu og BotStatus der udgør komponenten Bundlinie. Endvidere er den ansvarlig for at levere niveau op knappen, der giver brugeren mulighed for at steppe et niveau op i modellen. Klassen anvender desuden GridBagLayout til placering af elementer. Klassen er tilknyttet PathWindow klassens contentpane. 7 Retunerer til systemets hovedskærm og nulstiller søgninger
52 Designdokument Figur 2.4: Informationsstander brugergrænsefladens Hovedvindue klasser. Bundlinie klasserne Denne komponent indeholder klasserne: BottomMenu og BotStatus. Komponenten er ansvarlig for at fremvise hjælpeinformation til brugeren, samt at give mulighed for at skifte mellem de to visningstyper; tekst og kort jf analysens afsnit 1.5.1 side 24. Komponenten er tilknyttet PathWindow klassens contentpane. Figur 2.5 viser sammenhængen i denne komponent. BottomMenu Denne klasse er ansvarlig for knapperne Tekst og Kort, der giver brugeren mulighed for at vælge mellem disse to tilstande. Endvidere er klassen ansvarlig for at aktivere det relevante JPanel i ViewChoice klassens CardLayout, i forhold til brugerens valg. Klassen anvender et GridLayout med én række og to kolonner. Klassen bliver tilknyttet AsmBottomklassens contentpane. BotStatus Denne klasses ansvar er at fremvise hjælpe-tekst for brugeren. Klassen indeholder et JTextArea, der tilgås statisk af klassen LeftMenu. Klassen bliver tilknyttet AsmBottom klassens contentpane. Grafik view klasserne Denne komponent indeholder klasserne: DrawPanel og PathObject. Komponenten er ansvarlig for at vise systemets kort tilstand for brugeren, samt at sikre, at objekterne fra modellen bliver vist korrekt. Endvidere er klassen ansvarlig for at håndtere brugerens input i form af tryk på skærmen. Komponenten er tilknyttet ViewChoice klassens CardLayout. Figur 2.6 viser sammenhængen i denne komponent.
2.5 Brugergrænseflader 53 Figur 2.5: Informationsstander brugergrænsefladens Bundlinie klasser. DrawPanel Denne klasse er ansvarlig for programmets kort tilstand. Klassen henter lagerede elementer fra datakilden og viser disse i henhold til brugerens valg. Hvis der i den aktive datakilde ikke er tilknyttet et billede til den øverste lokation i hierarkiet, bliver brugeren gjort opmærksom på dette. Klassen er en specialisering af JPanel og for at kunne tegne på panelet, overskrives dennes paintcomponent metode. Denne klasse tilgåes via singleton mønsteret[10], for at sikre, at der kun eksisterer én instans af klassen. Dette anvendes for at brugeren kun bliver præsenteret for ét vindue. DrawPanel anvender endvidere rendering og antialiasering af grafikken for at sikre et pænere billede. PathObject Denne klasse er ansvarlig for at konvertere modellens Edge (se afsnit 2.6.1) objekt til en GeneralPath, der tegnes på tegnefladen. PathObjekt kontrollerer under konvertering, skærmens aktuelle opløsning, således at outputtet er tilpasset tegnefladen. Tekst view klasserne Denne komponent indeholder klasserne: TextPanel, EventView, StudyView, PlaceView, PersonView og VirtualKeyboard. Komponenten er ansvarlig for at vise systemets tekst tilstand. Endvidere er den ansvarlig for at håndtere brugerens input i form af tryk på skærmen. Komponenten leverer ydermere søgefunktionalitet, der giver brugeren mulighed for at finde ønskede elementer fra modellen. Komponenten er tilknyttet ViewChoice klassens CardLayout. Figur 2.7 viser sammenhængen i denne komponent. TextPanel Denne klasse er ansvarlig for at samle klasserne EventView, StudyView, PlaceView og PersonView, der hver repræsenterer et skærmbillede, i et CardLayout med statisk tilgang. Klassen er tilknyttet ViewChoice klassens CardLayout. EventView
54 Designdokument Figur 2.6: Informationsstander brugergrænsefladens Grafik view klasser. Denne klasse er endnu ikke implementeret, men det var hensigten, at den skulle give brugeren mulighed for at søge efter begivenheder og nyheder i systemet. Det eneste klassen gør nu er at vise en JLabel. Klassen er tilknyttet TextPanel klassens CardLayout og er en specialisering af JPanel. StudyView Denne klasse er ansvarlig for at hente og vise Organization objekter fra modellen. Endvidere er klassen ansvarlig for at brugeren har mulighed for at navigere i organisationsobjekterne. Klassen gør brug af GridBagLayout til placering elementer og er tilknyttet TextPanel klassens CardLayout. Den er desuden en specialisering af JPanel. Denne klasse er designet for at opfylde den ønskede funktionallitet fra afsnit 1.5.3 om systemets brugsmønstre PlaceView Denne klasse er ansvarlig for at hente og vise Locations objekter fra modellen. Endvidere er klassen ansvarlig for at give brugeren mulighed for at navigere i lokationsobjekterne. Klassen gør brug af GridBagLayout til placering af elementer og er tilknyttet TextPanel klassens CardLayout. Den er desuden en specialisering af JPanel. Denne klasse er designet for at opfylde den ønskede funktionallitet fra afsnit 1.5.3 om systemets brugsmønstre. PersonView Denne klasse er ansvarlig for at levere en søgefunktion til brugeren, hvor det er muligt at
2.5 Brugergrænseflader 55 finde personer. Endvidere gør klassen brug af VirtualKeyboard klassen for at give brugeren et grafisk tastatur. Dette er designet således, for at leve op til kravet om at programmet skal fungere på en touch-screen, samt at alt informationssøgning kan foregå udelukkende ved brug af tryk på denne skærm (se afsnit 1.2 i analysedokumentet). Klassen gør brug af GridBagLayout til placerin af elementer og er tilknyttet TextPanel klassens CardLayout. Den er desuden en specialisering af JPanel. Denne klasse er endvidere designet for at opfylde den ønskede funktionallitet fra afsnit 1.5.3 om systemets brugsmønstre VirtualKeyboard Denne klasse er ansvarlig for stille et grafisk tastatur og en søgefunktion til rådighed. Klasse er lavet for at opfylde kravet, om at programmet skal afvikles på en touch-screen og at alt informationssøgning skal foregå udelukkende ved brug af tryk på denne skærm (se afsnit 1.2 i analysedokumentet). Klassen gør brug af FlowLayout til placering af Keyboardknapper og er tilknyttet PersonView klassens GridBagLayout. Den er desuden en specialisering af JPanel. Figur 2.7: Informationsstander brugergrænsefladens Tekst view klasser. Globals klasserne Denne komponent indeholder klasserne AbsButton, Globals, GlobalStrings og ImageLoader der alle består af statiske variabler og funktioner der er tilgængelige for hele brugergrænsefladen. Denne komponent er ansvarlig for at tilstande, tekster, udseender og generelle funktioner er til rådighed for resten af systemet. Figur 2.8 viser sammenhængen i denne komponent. AbsButton Denne klasse er en specialisering af JButton og er ansvarlig for at knapperne på bruger-
56 Designdokument grænsefladen ser ens ud. Endvidere er det muligt at oprette 4 forskellige typer af Abs- Button; MENU (menu knap), LETTER (tastatur knap), SPACE (tastatur knap) og DELETE (tastatur knap). Endvidere er det muligt at tilknytte et Location eller et Organization objekt til knappen. Klassen anvendes globalt af alle klasser på brugergrænsefladen. Globals Denne klasse er ansvarlig for at holde styr på tilstande samt udseende af brugergrænsefladen. Klassen anvendes globalt af alle klasser i brugergrænsefladen. GlobalStrings Denne klasse er ansvarlig for alle tekststrenge på brugergrænsefladen. Klasse er designet som sprogfil, hvor det centralt er muligt at ændre teksten på planeler, knapper mm. GlobalStrings anvendes af samtlige visuelle objekter på brugergrænsefladen. ImageLoader Denne klasse er ansvarlig for at levere et ImageIcon ud fra en relativ sti. Klassen bliver primært brugt af LeftMenu, men er tilgængelig for alle objekter i brugergrænsefladen.
2.5 Brugergrænseflader 57 Figur 2.8: Informationsstander brugergrænsefladens globals klasser.
58 Designdokument 2.5.2 Administrator brugergrænsefladen Administrator brugergrænsefladen er den del af systemet, der giver mulighed for at redigere korttekniske detajler, samt organisatoriske data. Følgende vil gennemgå de klasser og hierarkier der anvendes til opbygning af dette. Figur 2.9 viser den logiske sammenhæng mellem klasserne i denne komponent. Denne brugergrænseflade er designet, med det primære mål at opfylde kravene fra analysedokumentets brugsmønstre, hvor krav til redigering af modellen og objekter opstilles. Det visuelle design bærer præg af traditionelle udviklingsværktøjer, så som MS Visual Studio. Endvidere er det gruppens ønske at levere et design, der gør brugeren istand til at udvikle og tilpasse systemets grundlæggende model, uanset hvilken sammenhæng den offentlige brugergrænseflade (fx vores Informationstander) anvendes i. Admin Denne indeholder systemets main metode og er ansvarlig for at starte og vise programmet. Klassen laver en instans af klassen AdminDesktop og synliggør denne. Figur 2.9: Oversigt over subarkitekturen i administrator brugergrænsefladen.
2.5 Brugergrænseflader 59 Desktop klasser Klasserne i denne komponent repræsenterer vinduerne på programmets desktop, samt logisk tilhørende klasser. Figur 2.10 viser sammenhængen i denne komponent. Toolbar Denne klasse er ansvarlig for at vise en værktøjslinie med knapperne Ét niveau op og Tilknyt organisation. Klassen sørger for at registrere brugerens interaktion på de enkelte knapper og udføre den ønskede handling. Endvidere er klassen designet for at lette tilgang til funktioner, der ikke har tegnemæssig karakter. Klassen er tiltænkt som en pladsholder for fremtidige genvejsknapper i forbindelse med udvidelser af systemet. ToolFrame Denne klasse er en del af programmets desktop og er ansvarlig for, at værktøjskassen har et dynamisk tilpasset layout i forhold til skærmopløsningen. Brugeren har via denne klasse mulighed for at ændre størrelsen af værktøjskassen, dog er det ikke muligt at lukke eller maximere denne. Klassen bygger på en JInternalFrame, der er tilknyttet AdminDesktop klassens JDesktopPane. Klassen fungerer som container til klassen ToolPanel, der er den reelle værktøjskasse. ToolPanel Denne klasse er ansvarlig for at præsenterer værktøjskassens knapper via et GridLayout med seks rækker og en kolonne. Klassen sørger for at registere brugerens interaktion på de individuelle knapper og udføre handliger herefter. Klassen er endvidere ansvarlig for bringe tegnefladen i fokus, samt at ændre tegnefladens tilstand i Globals klassen. Når et element vælges, er ToolPanel endvidere ansvarlig for at ændre hjælp vinduets indhold. StartupDialog Denne klasse er ansvarlig for, i et popup vindue, at få brugeren til at angive hovedorganisation og lokation i forbindelse med en nyoprettet datakilde. Klassen er baseret på en JFrame, der indeholder en JPanel med et pålagt GridBagLayout. Dette vindue fungere uafhængig af desktoppen, men det er her muligt at afslutte programmets kørsel. AdminDesktop Denne klasse er ansvarlig for at kontrollere datakildens tilstand og starte StartupDiaglog om nødvendigt. Klassen er endvidere ansvarlig for at samle klasserne: Toolbar, ToolFrame, HowToFrame, ImageFrame, MenuBar, OrganizationFrame og PropertyFrame på en JDesktopPane. Klassen er derudover ansvarlig for at kontrollere, om det er nødvendigt at gemme brugerens arbejde ved lukning af programmet. Findes dette nødvendigt, bliver brugeren præsenteret for et modal-vindue, hvor det er muligt at gemme. HowToFrame Denne klasse er ansvarlige for et dynamisk tilpasset layout af Hjælp vinduet i forhold
60 Designdokument til skærmopløsningen og er en del af programmets desktop. Brugeren har via denne klasse mulighed for at ændre størrelsen af Hjælp vinduet, dog er det ikke muligt at lukke eller maximere dette. Klassen bygger på en JInternalFrame, tilknyttet AdminDesktop klassens JDesktopPane. Klassen er endvidere designet som dynamisk hjælp hvis indhold tilpasser sig det valgte værktøj. ImageFrame Denne klasse er ansvarlig for et dynamisk tilpasset layout af tegnefladen i forhold til skærmopløsningen og er en del af programmets desktop. Brugeren har via denne klasse mulighed for at ændre størrelsen af tegnefladen, dog er det ikke muligt at lukke eller maximere denne. Klassen bygger på en JInternalFrame, tilknyttet AdminDesktop klassens JDesktopPane. Klassen fungerer som container til klassen AdminDrawPanel, der er den reelle tegneflade. MenuBar Denne klasse har ansvaret for brugergrænsefladens menu, samt genvejstaster til de enkelte menupunkter. Menuen indeholder to elementer, Gem og Afslut, der hver udfører de respektive handlinger. OrganizationFrame Denne klasse er ansvarlige for et dynamisk tilpasset layout af Organisations værktøjet i forhold til skærmopløsningen og er en del af programmets desktop. Brugeren har via denne klasse mulighed for at ændre størrelsen af organisations værktøjet, dog er det ikke muligt at lukke eller maximere dette. Klassen bygger på en JInternalFrame, tilknyttet AdminDesktop klassens JDesktopPane. Klassen indeholder en JPanel med et GridBagLayout, der er container for klasserne DNDTree og DTree der udgør organisations værktøjet. PropertyFrame Denne klasse er ansvarlige for et dynamisk tilpasset layout af egenskabsvinduet i forhold til skærmopløsningen og er en del af programmets desktop. Brugeren har ikke mulighed for at ændre størrelsen af dette vindue, dog er det muligt at minimere dette. Klassen bygger på en JInternalFrame, tilknyttet AdminDesktop klassens JDesktopPane. Klassen fungerer som container til klassen PropertyPanel der er den reelle egenskabsbeholder. Design board klasser Denne komponent indeholder klasser, der udgør systemets tegneflade. Figur 2.11 viser sammenhængen i denne komponent. AdminDrawPanel Denne klasse er ansvarlig for programmets tegneflade, herunder visning og handlinger. Klassen er tager sig af at hente lagerede elementer tilknyttet den aktuelle tegneflade. I
2.5 Brugergrænseflader 61 Figur 2.10: Administrator brugergrænsefladens Desktop klasser. forbindelse med dette startes en global transaktion (se afsnit 2.6.3). Hvis der i den aktive datakilde ikke er tilknyttet et billede til den øverste lokationen i hierarkiet, anmodes brugeren om dette. Desuden er klassen ansvarlig for at aktivere det korrekte panel i klassen PropertyPanel, samt at knytte de relevante data fra det aktive objekt til PropertyPanelets felter. Klassen er en specialisering af JPanel og for at kunne tegne på panelet, overskrives dennes paintcomponent metode. Denne klasse tilgås via singleton mønsteret[10], for at sikre, at der kun eksisterer én instans af klassen. Dette er designet således for at øge overskueligheden af desktoppen, samt den visuelle struktur af modellen. AdminDrawPanel anvender endvidere rendering og antialiasering af grafikken for at give et pænere billede. Når størrelsen af tegnefladen ændres af brugeren er AdminDrawPanel endvidere ansvarlig for at skalere de viste elementer. PathObject Denne klasse er ansvarlig for at konvertere modellens Edge (se afsnit 2.6.1 side 71 om Edge klassen) objekt til en GeneralPath, der tegnes på tegnefladen. PathObjekt kontrollerer under konvertering, skærmens aktuelle opløsning, således at outputtet er tilpasset tegnefladen.
62 Designdokument Figur 2.11: Administrator brugergrænsefladens Designboard klasser.
2.5 Brugergrænseflader 63 Property inspector klasser Denne komponent indeholder klasser der repræsenterer indholdet af desktoppens egenskabsvindue. Figur 2.12 viser sammenhængen i denne komponent. PropertyPanel Denne klasse sørger for at samle de forskellige property paneler i et CardLayout. Dette CardLayout tilgås statisk af klasserne: AdminDrawPanel, DTree og ToolBar. PropertyPanel er en speciallisering af JPanel. PathProperty Klassen er ansvarlig for at egenskaberne for en Edge (se afsnit 2.6.1 side 71 om Edge klassen) bliver vist og giver mulighed for at redigere disse. Endvidere er klassen ansvarlig for at brugeren kun kan indtaste tilladte karakterer. Klassen indgår i CardLayoutet fra PropertyPanel klassen og er en specialisering af JPanel. Desuden anvendes GridBagLayout på panelet. Klassen anvendes af AdminDrawPanel. Denne klasse er designet for at tilgodese krav fra afsnit 1.5.3 i analysedokumentet. JunctionProperty Klassen er ansvarlig for at egenskaberne for en Junction (se afsnit 2.6.1 side 70 on Junction klassen) bliver vist og giver mulighed for at slette den valgte Junction. Klassen indgår i CardLayoutet fra PropertyPanel klassen og er en specialisering af JPanel. Desuden anvendes GridBagLayout på panelet. Klassen anvendes af AdminDrawPanel. Denne klasse er designet for at tilgodese krav fra brugsmønstrene i afsnit 1.5.3 i analysedokumentet. LocationProperty Klassen er ansvarlig for at egenskaberne for en Location (se afsnit 2.6.1 side 70 om Location klassen) bliver vist og giver mulighed for at redigere disse. Endvidere er klassen ansvarlig for at brugeren kun kan indtaste tilladte karakterer. Ved tilknytning af et billede til en Lokation, anvendes JFileChooser. Klassen indgår i CardLayoutet fra PropertyPanel klassen og er en specialisering af JPanel. Desuden anvendes GridBagLayout på panelet. Klassen anvendes af AdminDrawPanel. Denne klasse er designet for at tilgodese krav fra analysedokumentets afsnit 1.5.3 om brugsmønstre. OrganizationProperty Klassen er ansvarlig for at egenskaberne for en Organization (se afsnit 2.6.1 side 71 om Organization klassen) bliver vist og giver mulighed for at redigere disse. Endvidere er klassen ansvarlig for at brugeren kun kan indtaste tilladte karakterer. Klassen indgår i CardLayoutet fra PropertyPanel klassen og er en specialisering af JPanel. Desuden anvendes GridBagLayout på panelet. Klassen anvendes af organisations handling klasserne. Klassen anvendes af AdminDrawPanel. Denne klasse er designet for at tilgodese krav fra analysedokumentets afsnit 1.5.3 om brugsmønstre.
64 Designdokument Figur 2.12: klasser til Administrator brugergrænsefladens egenskabsvindue. Image chooser klasser Klasserne i denne komponent indeholder udvidelser til javax.swing.jfilechooser. Figur 2.13 viser sammenhængen i denne komponent. Denne komponent benyttes til at vælge det billede på filsystemet, der skal benyttes som baggrund for et kort. JFileChooser er overskrevet for at kunne vise brugeren et miniaturebillede af det markede billede, inden det sættes ind som baggrund. Dette er gjort for at undgå at brugeren vælger at hente det forkerte billede ind i programmet. ImageFileView Denne klasse er ansvarlig for at tildele ikoner til filtyperne: JPG, JPEG og GIF i brugergrænsefladens billedvælger. Dette opnås ved at udvide FileView klassen fra javax.swing.filechooser pakken. Klassen gør brug af Utils klassen til definering af filtyper. Klassen anvendes af Globals klassen under instansiering af en JFileChooser.
2.5 Brugergrænseflader 65 ImageFilter Denne klasse er ansvarlig for filtreringen, således at JFileChooseren kun viser: mapper, JPG, JPEG og GIF filer. ImageFilter gør brug af Utils klassen til identificering af filtyperne. Klassen anvendes af Globals klassen under instansiering af en JFileChooser. ImagePreview Denne Klasse er ansvarlig for at lave et thumbnail view af markerede billeder. Klassen anvendes af Globals klassen under instansiering af en JFileChooser som accessory komponent. ImagePreview er en specialisering af JComponent klassen. Utils Denne klasse er ansvarlig for at bestemme om en fil er af typen: JPEG, JPG eller GIF. Desuden er klassen ansvarlig for, ud fra en relativ sti, at hente og repræsentere et billede som javax.swing.imageicon. Klassen fungerer som hjælpeklasse til ImageFilter og Image- FileView. Figur 2.13: Administrator brugergrænsefladens Image chooser klasser.
66 Designdokument Organization handling klasser Klasserne i denne komponent anvendes til redigering af organisatoriske elementer, samt tilknytning af disse til én eller flere lokationer, via en javax.swing.jtree struktur. Figur 2.14 viser sammenhængen i denne komponent. JTree er brugt for at visualisere træ-strukturen i Lokationer og Organisationer, samt relationerne mellem disse, på en brugervenlig måde. Da denne måde at illustrere en træ-struktur på bliver brugt adskillige andre steder, f.eks. i forbindelse med Windows stifinder, kan det forventes at mange brugere vil kunne genkende denne. AbstractTreeTransferHandler Denne klasse er ansvarlig, som abstrakt superklasse, for visuelle og funktionelle Drag and Drop funktionaliteter. Desuden pålægges nedarvende klasser at implementere executedrop() metoden. Klassen er endvidere ansvarlig for at sikre, at handlinger der udføres ikke modstrider modellens opbygning (fx at tilknytte en organisation til sig selv). Klassen anvendes af de specialiserende klasser TreeTransferHandler og TreeNonDropTransferHandler. TreeNonDropTransferHandler Denne klasse er ansvarlig for at executedrop() metoden ikke udfører en drop handling. Klassen nedarver fra AbstractTreeTransferHandler, hvilket giver drag funktionalitet. Denne design skyldes, at det skal være muligt at trække en organisation over under en lokation, men ikke omvendt. Klassen anvendes af DTree. TreeTransferHandler Denne klasse er ansvarlig for at udføre den korrekte executedrop() metode, når der modtages et objekt af JTree typen. Denne klasse anvendes af klassen DNDTree, til at gøre input JTree objektet dropbart. DNDTree Denne klasse er ansvarlig for at visualisere modellens Lokations struktur. Endvidere er klassen ansvarlig for at kopiere droppede organisationsnoder, samt at gøre disse umodtaglige for flere drops. Allerede droppede organisationer får endvidere tildelt et nyt ikon, så det er muligt at skelne lokationer fra organisationer. Klassen anvendes i kombination med OrganizationFrame klassen. DTree Denne klasse er ansvarlig for at visualisere modellens organisationsstruktur. Endvidere er klassen ansvarlig for at vise de enkelte organisationers data i desktoppens egenskabsvindue. Klassen anvedes i kombination med OrganizationFrame klassen. TransferableNode
2.5 Brugergrænseflader 67 Denne klasse er ansvarlig for at afgøre om et objekt, i forbindelse med Drag and Drop, er flytbart. Klassen anvendes af klasserne TreeTransferHandler og AbstractTreeTransfer- Handler. Klassen implementerer Transferable interfacet, da dette skal implementeres for at kunne udføre Drag and Drop funktionallitet. Klassen understøtter endvidere DataFlavouren Node, der bruges til at verificere hvor noden må droppes. ExtendedTreeNode Denne klasse er ansvarlig for at tilføje funktionallitet til noderne i DNDTree og DTree. Den tilførte funktionallitet gør det muligt at låse de enkelte noder i træet. Klassen anvendes af klasserne: AbstractTreeTransferHandler, TreeNonDropTreeTransferHandler, TreeTransferHandler, DNDTree, DTree og TransferableNode. klassen nedarver fra Default- MutableTreeNode. Figur 2.14: Administrator brugergrænsefladens klasser til håndtering af Organisationer. Globals klasser Denne komponent indeholder klasserne Globals og GlobalStrings, der begge består af statiske variabler og funktioner, der er tilgængelige for hele brugergrænsefladen. Figur 2.15
68 Designdokument viser sammenhængen i denne komponent. Globals Denne klasse er ansvarlig for at holde styr på tilstande af brugergrænsefladen, desuden indeholder klassen variabler der styrer brugergrænsefladens udseende. Endvidere leverer Globals klassen en metode til at vise en specialiseret JFileChooser (se afsnit 2.5.2 side 64), samt en funktion til angivelse af kolonnebredde i et GridBagLayout (primært brugt af property inspectoren). Klassen anvendes globalt af alle klasser i brugergrænsefladen. GlobalStrings Denne klasse er ansvarlig for alle tekststrenge i brugergrænsefladen. Klasse er designet som sprogfil, hvor det centralt er muligt at ændre teksten på planeler, knapper mm. Global- Strings anvendes af samtlige visuelle objekter på brugergrænsefladen. Figur 2.15: Admin brugergrænsefladen globals klasser.