Find vej. Skrevet af: Gruppe D109A Aalborg Universitet 2004

Størrelse: px
Starte visningen fra side:

Download "Find vej. Skrevet af: Gruppe D109A Aalborg Universitet 2004"

Transkript

1 Find vej Skrevet af: Gruppe D109A Aalborg Universitet 2004

2

3 TITEL Find vej PROJEKTPERIODE Dat1 2. September 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

4

5 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 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 }

6

7 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.

8

9 Indhold 1 Analysedokument Formål Systemdefinition System omgivelser Analyse af problemområde Analyse af anvendelsesområdet Anbefalinger Designdokument Formål Kvalitetsmål Teknisk platform Grundarkitektur Brugergrænseflader Model Datamapperne Anbefalinger Implementering Overblik Gennemgang af implementering Studierapport Projekt strategi Projektforløb Fokusområde - algoritmer A Appendix 113 A.1 Brugergrænseflade skærmbilleder A.2 Forbilleder A.3 Interaktionsmodel

10

11 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 Systemdefinition System omgivelser Definition af problemområde Definition af anvendelsesområde Analyse af problemområde Struktur Klassebeskrivelser Hændelsestabel Analyse af anvendelsesområdet Brug Aktører Brugsmønstre Funktioner Systemgrænseflade Brugergrænseflade Anbefalinger Nytte og realiserbarhed Strategi Økonomi

12 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.

13 1.3 System omgivelser 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 14 Analysedokument Figur 1.1: Skitsering af problemområdet

15 1.4 Analyse af problemområde 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 informationsstander-systemet der allerede eksisterer på campus - Kroghstræde 3 og et lignende system der benyttes i City Syd indkøbscentret. Internetsiden 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 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 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,

17 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 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 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

19 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 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 -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

21 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 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

23 1.4 Analyse af problemområde 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 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 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 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.

25 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 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 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 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

27 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 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

29 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 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

31 1.5 Analyse af anvendelsesområdet 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 32 Analysedokument 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 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

33 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 34 Analysedokument Figur 1.24: Informationsstander programmets udseende

35 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 36 Analysedokument Figur 1.26: Kort administrations programmets udseende

37 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 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 38 Analysedokument 1.6 Anbefalinger Dette afsnit indeholder gruppens anbefalinger og vurdering i forbindelse med viderudvikling af den belyste problemstilling 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 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 Ø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

39 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 40 Analysedokument

41 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 Kvalitetsmål Teknisk platform Grundarkitektur Brugergrænseflader Informationsstander brugergrænsefladen Administrator brugergrænsefladen Model Domæne-objekter Findvej Kernen Datamapperne JDBC mapperne Memory Mapperne Persistens Anbefalinger Systemets nytte Plan for ibrugtagning Implementeringsplan

42 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 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

43 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 responsetime.html, et uddrag fra bogen Usability Engineering

44 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 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

45 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 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 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.

47 2.4 Grundarkitektur 47 Figur 2.2: Konceptuel komponentarkitektur med afhængighedsforhold

48 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

49 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å

50 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 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.

51 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 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 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 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 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.

53 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 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 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 om systemets brugsmønstre. PersonView Denne klasse er ansvarlig for at levere en søgefunktion til brugeren, hvor det er muligt at

55 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 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 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.

57 2.5 Brugergrænseflader 57 Figur 2.8: Informationsstander brugergrænsefladens globals klasser.

58 58 Designdokument 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.

59 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 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

61 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 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 62 Designdokument Figur 2.11: Administrator brugergrænsefladens Designboard klasser.

63 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 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 i analysedokumentet. JunctionProperty Klassen er ansvarlig for at egenskaberne for en Junction (se afsnit 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 i analysedokumentet. LocationProperty Klassen er ansvarlig for at egenskaberne for en Location (se afsnit 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 om brugsmønstre. OrganizationProperty Klassen er ansvarlig for at egenskaberne for en Organization (se afsnit 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 om brugsmønstre.

64 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.

65 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 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

67 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 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 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.

Objektorienteret Analyse & Design

Objektorienteret Analyse & Design Objektorienteret Analyse & Design Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen og Jan Stage ISBN: 87-7751-153-0 Udgave: 3. udgave Udgivelsesår: 2001 Antal sider: 452 Pris: Kr. 410,00 På de

Læs mere

CampIT - Et administrationssystem. Gruppe E2-109 Aalborg Universitet

CampIT - Et administrationssystem. Gruppe E2-109 Aalborg Universitet CampIT - Et administrationssystem Gruppe E2-109 Aalborg Universitet 19. december 2002 Det Teknisk-Naturvidenskabelige Fakultet Aalborg universitet Titel: CampIT Et administrationssystem Tema: Udvikling

Læs mere

Object-Relational Mapping

Object-Relational Mapping Databaser for udviklere () Datamatiker TietgenSkolen Underviser: Allan Helboe 06-06-2010 Problemformulering Denne opgave er et forsøg på at beskrive problemerne der opstår ved anvendelsen af en relationel

Læs mere

BAAN IVc. Brugervejledning til BAAN Data Navigator

BAAN IVc. Brugervejledning til BAAN Data Navigator BAAN IVc Brugervejledning til BAAN Data Navigator En udgivelse af: Baan Development B.V. P.O.Box 143 3770 AC Barneveld Holland Trykt i Holland Baan Development B.V. 1997. Alle rettigheder forbeholdes.

Læs mere

Department of Computer Science

Department of Computer Science Department of Computer Science Aalborg Universitet Titel: ReadAllAboutIT - Udarbejdelse af et artikelstyringssystem Tema: Udvikling af programmel Projektperiode: Informatik/Datalogi 3. semester 4. september

Læs mere

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin August 2009 - juni 2010 Institution HTX Sukkertoppen/Københavns Tekniske Skole Uddannelse Fag og niveau Lærer(e)

Læs mere

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet...

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet... Indhold 1 Ordliste 2 2 Indledning 3 2.1 Problemstillinger.................................. 3 2.2 Problemformulering................................ 4 2.3 Problemafgrænsning................................

Læs mere

Jacob Nordfalk. Ingeniørhøjskolen i København. Nykøbing F itvisioncenter 24. februar 2004

Jacob Nordfalk. Ingeniørhøjskolen i København. Nykøbing F itvisioncenter 24. februar 2004 Genbrugelige komponenter og designmønstre i Java Jacob Nordfalk Ingeniørhøjskolen i København Nykøbing F itvisioncenter 24. februar 2004 Program Om Jacob Nordfalk introduktion (ikke-teknisk del) Komponentbaseret

Læs mere

Brugervejledning til Design Manager Version 1.02

Brugervejledning til Design Manager Version 1.02 Brugervejledning til Design Manager Version 1.02 Indholdsfortegnelse 1. Introduktion... 3 1.1 Det kan du med HostedShop Design Manager... 3 1.2 Feature list... 3 2. Design... 4 3. Filer og CSS... 4 3.1

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Administration af computerparty & turneringsplanlægning

Administration af computerparty & turneringsplanlægning Administration af computerparty & turneringsplanlægning Turnering System til brugeradministration og...... turneringsplanlægning af et computerparty Dat1-projekt af - Gruppe d105a - Aalborg Universitet,

Læs mere

Supermarkedsmodellen for design af brugergrænseflade

Supermarkedsmodellen for design af brugergrænseflade Supermarkedsmodellen for design af brugergrænseflade Denne note er skrevet frit efter Peter Huber, som på et kursus i Efteruddannelsescenteret fortalte om supermarkedsmodellen til design af brugergrænseflader.

Læs mere

Hjemmesiden er opdelt i et sidehoved, en sidefod og mellem disse 3 kolonner: venstre, midterste og højre. Højre kolonne vises dog kun på forsiden.

Hjemmesiden er opdelt i et sidehoved, en sidefod og mellem disse 3 kolonner: venstre, midterste og højre. Højre kolonne vises dog kun på forsiden. Hjemmesiden er opdelt i et sidehoved, en sidefod og mellem disse 3 kolonner: venstre, midterste og højre. Højre kolonne vises dog kun på forsiden. VENSTRE kolonne indeholder flere elementer (se illustration

Læs mere

Automatisk Vandingssystem

Automatisk Vandingssystem Automatisk Vandingssystem Projektdokumentation Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: 28-05-2015 Lærke Isabella Nørregård Hansen - 201205713 - IKT Kasper Sejer Kristensen

Læs mere

Viditronic NDVR Quick Guide. Ver. 2.0

Viditronic NDVR Quick Guide. Ver. 2.0 Viditronic NDVR Quick Guide Ver. 2.0 1 Indholdsfortegnelse 1. HOVEDMENU 3 1.1 START 5 1.2 AKTIVITETSINDIKATOR: 7 1.3 INFORMATIONS VINDUE: 7 1.4 PTZ KAMERA KONTROL: 7 1.5 SKÆRMMENU 8 1.5.1 AKTIVER BEVÆGELSE:

Læs mere

Sådan indlægges nyheder på DSqF s hjemmeside trin for trin

Sådan indlægges nyheder på DSqF s hjemmeside trin for trin Sådan indlægges nyheder på DSqF s hjemmeside trin for trin Systemkrav For at kunne bruge Composite kræves: Windows 95 eller nyere (bemærk - kun Windows kan bruges) Browseren Internet Explorer 6.0 eller

Læs mere

Daglig brug af JitBesked 2.0

Daglig brug af JitBesked 2.0 Daglig brug af JitBesked 2.0 Indholdsfortegnelse Oprettelse af personer (modtagere)...3 Afsendelse af besked...4 Valg af flere modtagere...5 Valg af flere personer der ligger i rækkefølge...5 Valg af flere

Læs mere

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling Java og JEE 1 2 Udfordringer og problemstillinger En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling 3 Generelt om Java og JEE 4 Generelt, I Man undervurderer hvor mange

Læs mere

Administrator manual

Administrator manual Revision 1 Administrator manual INDHOLD LOG IND 1 OVERBLIK 1 ARBEJDSRUM 1 MEDARBEJDERE 2 OPRET NY MEDARBEJDER 2 TRIN 1 AF 4: NAVN OG OPLYSNINGER 2 TRIN 2 AF 4: LEGITIMATION 2 TRIN 3 AF 4: EFFEKTIVITETSNIVEAU

Læs mere

smart-house Web-Server Manual smart-house Web-Server Manual 1 of 15

smart-house Web-Server Manual smart-house Web-Server Manual 1 of 15 smart-house Web-Server Manual CARLO GAVAZZI AS, PB 215, NO-3901 Porsgrunn Telefon: 35 93 08 00 Telefax: 35 93 08 01 Internet: http://www.carlogavazzi.no E-Mail: gavazzi@carlogavazzi.no 1 of 15 Indholdsfortegnelse

Læs mere

It-programmet CO 2 -beregning. Vejledning

It-programmet CO 2 -beregning. Vejledning It-programmet CO 2 -beregning Vejledning 18 Kom godt i gang med CO 2 -beregning Vejledning Dataindsamling CO 2 -beregning Vejledning It-programmet CO 2 -beregning Vejledning Virkemiddelkatalog CO 2 -beregning

Læs mere

Objektorienteret design med arv og polymorfi:

Objektorienteret design med arv og polymorfi: Note til Programmeringsteknologi Akademiuddannelsen i Informationsteknologi Objektorienteret design med arv og polymorfi: Substitutionsprincippet Composite Design Pattern Finn Nordbjerg Side 1 Objektorienteret

Læs mere

IsenTekst Indhold til Internettet. Manual til Wordpress.

IsenTekst Indhold til Internettet. Manual til Wordpress. Manual til Wordpress Sådan opdaterer du din hjemmeside i Wordpress. Dette er en manual til de mest grundlæggende ting, så du selv kan redigere indholdet eller tilføje nyt på din hjemmeside. Guiden er skrevet

Læs mere

Introduktion til UNGIAARHUS

Introduktion til UNGIAARHUS UNGIAARHUS- ungdomsskoleløsning, side 1 Introduktion til UNGIAARHUS et ungdomsskolesystem baseret på PHP og MySQL Indledende Den løsning, som introduceres her, blev oprindelig lavet som noget foreløbigt

Læs mere

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING 2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et

Læs mere

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England.

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England. Cookievejledningens Tekniske Guide Den tekniske guide beskriver fem skridt til overholdelse af cookiereglerne: 1. Fastlæggelse af webejendom 2. Undersøgelse af om der sættes cookies på hjemmesiden 3. Afgivelse

Læs mere

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning

2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning 2. Metode Indledning Projektet er udført med flg. faser: Foranalyse (uden iterationer) Analyse (udarbejdelse af kravspecifikation afsnit 9.1, herunder use case beskrivelser afsnit 9.2) Design af skærmbilleder

Læs mere

BørneIntra hjemmesidekursus

BørneIntra hjemmesidekursus BørneIntra hjemmesidekursus hjemmesidekursus Januar 2012 Indhold 1 Introduktion... 5 1.1 Kursets formål... 5 1.2 Hjemmesiden opbygges i PersonaleIntra... 5 2 Hjemmesidens indhold... 6 2.1 Hjemmesidens

Læs mere

Dokumentation for administration af it-systemer i PD30

Dokumentation for administration af it-systemer i PD30 Dokumentation for administration af it-systemer i PD30 1. Sikkerhed 2. Mail 3. Cloud Drive 4. Elektronisk reservation 5. Hjemmeside 1. Sikkerhed Sikkerheden for it-systemerne i PD30 hænger tæt sammen med

Læs mere

MailMax / Web v4.1. Brugsvejledning til webmail. Copyright 2003 Gullestrup.net

MailMax / Web v4.1. Brugsvejledning til webmail. Copyright 2003 Gullestrup.net MailMax / Web v4.1 Copyright 2003 Gullestrup.net Log ind på webmailen Start med at gå ind på http://webmail.gullestrup.net i din browser. Indtast din Email-adresse samt Adgangskode, som hører til din konto.

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

7DVWHYHMOHGQLQJ#²#,QWHUQHW#([SORUHU

7DVWHYHMOHGQLQJ#²#,QWHUQHW#([SORUHU 7DVWHYHMOHGQLQJ#²#,QWHUQHW#([SORUHU,QGKROGVIRUWHJQHOVH BROWSEREN - DE VIGTIGSTE FUNKTIONER OG BEGREBER.... 2 TILPAS BROWSEREN... 3 GÅ DIREKTE TIL EN KENDT ADRESSE... 5 LAV ET BOGMÆRKE... 6 ORGANISÉR DINE

Læs mere

Database "opbygning"

Database opbygning Database "opbygning" Dette områder falder mest under en DBA's ansvarsområde. Det kan sagtens tænkes at en database udvikler i nogle situationer vil blive nød til at oprette produktions og test) databaser,

Læs mere

PHP kode til hjemmeside menu.

PHP kode til hjemmeside menu. PHP kode til hjemmeside menu. Home Hovedmenu 1 Hovedmenu 2 Hovedmenu 3 Hovedmenu 4 Undermenu 1 Breadcrumb Her vises indholdet af den valgte side Undermenu 2 Undermenu 3 Undermenu 4 Evt. en mulighed for

Læs mere

My booking. Generelt. Forsiden. Version 9.0

My booking. Generelt. Forsiden. Version 9.0 My booking Version 9.0 System til at lave online bookinger, med mulighed for opdeling i grupper, forskellige booking typer, ændre layout indstillinger, status styring, sprogvalg samt en del mere, detaljer

Læs mere

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen

Programmering C Eksamensprojekt. Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Programmering C Eksamensprojekt Lavet af Suayb Köse & Nikolaj Egholk Jakobsen Indledning Analyse Læring er en svær størrelse. Der er hele tiden fokus fra politikerne på, hvordan de danske skoleelever kan

Læs mere

GRAFISK DESIGN SVENDEPRØVE Dorte Damsgaard Larsen

GRAFISK DESIGN SVENDEPRØVE Dorte Damsgaard Larsen GRAFISK DESIGN SVENDEPRØVE Dorte Damsgaard Larsen OPGAVE Designforslag til hjemmeside til motorcykelklubben Mc Chaufførerne GRAFISK DESIGN / Dorte Damsgaard Larsen 1/15 DESIGNPROCES Indledende møde med

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database Kursusbeskrivelse Oprettelse af en Access-database Som eksempel på en Access-database oprettes en simpelt system til administration af kurser. Access-databasen skal indeholde: et instruktørkartotek et

Læs mere

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.

Version Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet. MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.

Læs mere

Dette dokument beskriver SUMOshop Backend v3, med fokus på ændringer ift. v2.

Dette dokument beskriver SUMOshop Backend v3, med fokus på ændringer ift. v2. 1 SUMOshop Backend v3 Dette dokument beskriver SUMOshop Backend v3, med fokus på ændringer ift. v2. Backend v3 er primært en visuel opdatering i et mere rent og moderne design. Hertil er der en række helt

Læs mere

Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN

Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN Administration af subsites BRUGERVEJLEDNING FOR ADMINISTRATOREN Indholdsfortegnelse Introduktion... 2 Definitioner... 2 Generelt... 3 Oprettelse af en skabelon... 4 Sidetypeskabeloner... 5 Globale displaymoduler...

Læs mere

Opstart. I gang med Dreamweaver. Læs mere om...

Opstart. I gang med Dreamweaver. Læs mere om... Generelle bemærkninger Programmet Dreamweaver har været på markedet i nogle år efterhånden. Den seneste version hedder Dreamweaver CS5, og programmet er på engelsk. Dreamweaver er en såkaldt grafisk editor,

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN 1/20 Indledning Dette projekt er den afsluttende del af webudvikling-studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med

Læs mere

Ruko SmartAir. Updater installation

Ruko SmartAir. Updater installation Ruko SmartAir Updater installation Introduktion. Updateren er en speciel enhed som giver os mulighed for at tilføje, læse og skrive funktioner i en offline installation. Med læse og skrive funktionen kan

Læs mere

den rollebaserede brugergrænseflade

den rollebaserede brugergrænseflade WHITE PAPER Rollebaseret brugergrænseflade. Hvordan tilpasses profiler? Du er sikkert allerede bekendt med, hvordan brugergrænsefladerne i moderne ERP-systemer er opbygget, og hvordan de herved, danner

Læs mere

Sådan opdaterer og vedligeholder du din hjemmeside i Wordpress.

Sådan opdaterer og vedligeholder du din hjemmeside i Wordpress. Wordpress manual Sådan opdaterer og vedligeholder du din hjemmeside i Wordpress. Dette er en manual til de mest grundlæggende ting og funktioner i Wordpress, så du selv kan redigere indholdet eller tilføje

Læs mere

Guide - Sådan opretter du en backup

Guide - Sådan opretter du en backup Guide - Varighed: ca. 10 min Denne guide gennemgår hvordan en backup oprettes i Excovery. Guiden vil trinvist lede dig igennem processen og vil undervejs introducere de grundlæggende indstillingsmuligheder.

Læs mere

Synkron Via CMS er en ny generation Content Management System

Synkron Via CMS er en ny generation Content Management System Synkron Via CMS er en ny generation Content Management System De sidste par år er internettet gået fra at være endnu en marketingaktivitet for de fleste organisationer til at blive et strategisk og forretningskritisk

Læs mere

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model

Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Dm071 / Dm072 - Obligatorisk projekt 3: Design af model Fag: Projektet omhandler emner fra fagene Software Design og Software Konstruktion. Formål: Formålet med projektet er at give dig mulighed for sammen

Læs mere

Arbejdsrum i ElevIntra

Arbejdsrum i ElevIntra Arbejdsrum i ElevIntra En stærk mulighed Version: Januar 2014 Indholdsfortegnelse Hvad er et arbejdsrum?...4 Dette materiale...4 De mange muligheder...5 Drejebog for kurset...6 Opret dit første arbejdsrum

Læs mere

KIH Database. Systemdokumentation for KIH Databasen. 1. maj 2013. Side 1 af 13

KIH Database. Systemdokumentation for KIH Databasen. 1. maj 2013. Side 1 af 13 KIH Database Systemdokumentation for KIH Databasen 1. maj 2013 Side 1 af 13 Indholdsfortegnelse Indholdsfortegnelse... 2 Indledning... 3 Systemoverblik... 3 KIH Database applikationsserver... 5 Forudsætninger

Læs mere

Region Midtjylland Proces for Change Management

Region Midtjylland Proces for Change Management Region Midtjylland Proces for Change Management Version 1.1 Forord Dette dokument beskriver RMIT s Change Management proces. Processen beskriver minimumskravene (need to have) for at få processen til at

Læs mere

Drejebog til tractorpulling.dk

Drejebog til tractorpulling.dk Drejebog til tractorpulling.dk Generelt På hjemmesiden benyttes følgende som standard: - Skrifttype: Verdana - Skriftstørrelse: 12px / 9pt. 4. oktober 2011 Moskjær Marketing Falkevej 4 DK-6920 Videbæk

Læs mere

Easy Guide i GallupPC

Easy Guide i GallupPC Easy Guide i GallupPC Version. 6.00.00 Gallup A/S Masnedøgade 22-26 DK 2100 København Ø Telefon 39 27 27 27 Fax 39 27 50 80 Indhold SÅDAN KOMMER DU I GANG MED AT ANVENDE GALLUPPC... 2 TILFØJELSE AF UNDERSØGELSER

Læs mere

PID2000 Archive Service

PID2000 Archive Service PROLON CONTROL SYSTEMS Herstedvesterstræde 56 DK-2620 Albertslund Danmark Tlf.: (+45) 43620625 Fax: (+45) 43623125 PID2000 Archive Service Bruger vejledning Juni 2002 Denne manual beskriver brugen af softwaren

Læs mere

Lavet af Danni jensen og David Olsen

Lavet af Danni jensen og David Olsen Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse

Læs mere

Content Management System. Content Management System

Content Management System. Content Management System CMS Content Management System Content Management System ADventure/SequelSite: det mest optimale til etablering, vedligeholdelse og fornyelse af professionelle web-sites Slut med eksperter og dyre opdateringer,

Læs mere

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE

HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE HELLO INSTALLATIONS GUIDE - DANSK RACKPEOPLE 1 Tekniske Krav 1.1 Hardware krav: En skærm gerne med touch Hvis skærmen ikke har touch, skal du bruge et tastatur og en mus Webcam Gerne i HD En ekstern lydenhed

Læs mere

Component based software enginering Diku 2005 Kritikopgave

Component based software enginering Diku 2005 Kritikopgave Component based software enginering Diku 2005 Kritikopgave Nicolas Møller Henschel 17. april 2005 1 Indhold 1 Indledning 3 2 Indhold 3 2.1 Introduktionen.......................... 3 2.1.1 Mangler..........................

Læs mere

1. Baggrund og problemstilling

1. Baggrund og problemstilling 1. Baggrund og problemstilling 1.1 Baggrund Opgavestiller og fremtidig bruger af systemet er klinikken Tandlæge Annelise Bom 1. Opgaven udspringer af et ønske om at forbedre aftalestyringen. Nøgleordene

Læs mere

IT-Brugerkursus. Modul 1 - Introduktion til skolens netværk og FC. Modul 1 - Introduktion til FC og Lectio. Printvenligt format. Indholdsfortegnelse

IT-Brugerkursus. Modul 1 - Introduktion til skolens netværk og FC. Modul 1 - Introduktion til FC og Lectio. Printvenligt format. Indholdsfortegnelse Modul 1 - Introduktion til FC og Lectio IT-Brugerkursus Modul 1 - Introduktion til skolens netværk og FC Printvenligt format Indholdsfortegnelse Formål og opbygning Opgave Vejledning til intranettet Åbne

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav.

Miniprojekt2011. Formålet er at lære og indlære god objektorienteret programudvikling og programmering med Java, samt undervejs at opfylde studiekrav. Miniprojekt2011 Projektbeskrivelse Der skal fremstilles en lille java application på PC, hvor brugeren kan foretage interaktioner med en simpel database på disken via et grafisk brugerinterface. Formålet

Læs mere

Spiked Reality. Kvikguide til oprettelse af tilbud, nyheder og begivenheder. Version 2.0, september 2013

Spiked Reality. Kvikguide til oprettelse af tilbud, nyheder og begivenheder. Version 2.0, september 2013 Spiked Reality Kvikguide til oprettelse af tilbud, nyheder og begivenheder Version 2.0, september 2013 Indholdsfortegnelse Indledning... 3 Mine oplysninger... 3 Online Administration... 3 Dit log ind...

Læs mere

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4 Maskine Udlejning 15. oktober 2010 Jacob Weng, Jeppe Boese og Mads Anthony Roskilde Tekniske Gymnasium Udlejningsvirksomhed 3.4 Indholdsfortegnelse Problemformulering:... 2 Planlægning:... 2 Analyse af

Læs mere

Vejledning i brug af Interbook. Lokalebooking-program for foreninger, kommunale skoler og Tønder Hallerne.

Vejledning i brug af Interbook. Lokalebooking-program for foreninger, kommunale skoler og Tønder Hallerne. Vejledning i brug af Interbook Lokalebooking-program for foreninger, kommunale skoler og Tønder Hallerne. 1 Indledning Tønder Kommunes lokalebookingsystem og foreningsportal (Interbook) er et program,

Læs mere

Studieordning del 4-2014

Studieordning del 4-2014 Studieordning del 4-2014 Fagbeskrivelser Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 8 Indhold del 4 Fagbeskrivelser 1. Faget Programmering (PRO)...2 2. Faget

Læs mere

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API Release 4.0.0 DaTelTek ApS Birkevej 4 DK-4640 Faxe Denmark CVR: 31 06 05 59 +45 32 22 22 22 www.dateltek.dk info@dateltek.dk Indholdsfortegnelse Ændring

Læs mere

Produktion II. Produktionsserien er opdelt i tre områder: Del af en integreret virksomhedsløsning. Produktion ll til Microsoft Navision Axapta

Produktion II. Produktionsserien er opdelt i tre områder: Del af en integreret virksomhedsløsning. Produktion ll til Microsoft Navision Axapta h Produktion ll til Microsoft Navision Axapta introducerer begrebet rutestyring, som gør det muligt at udnytte ressourcer mere effektivt. Fordele Valg af den bedste rute til en operation på en given dag.

Læs mere

Typo3 vejledning BMI af 1 Typo3 vejledning for redaktører og skribenter i BMI

Typo3 vejledning BMI af 1 Typo3 vejledning for redaktører og skribenter i BMI af 1 side 1 Typo3 vejledning for redaktører og skribenter i BMI GENERELT...3 LOGIN...3 STARTSIDEN...4 SIDE...5 SIDE ELEMENTER...6 SIDE LAYOUT...7 STJÆL MED ARME OG BEN HEL SIDE...8 STJÆL MED ARME OG BEN

Læs mere

Konsulent resume. Referencer Svend Holm Henriksen IT-udviklingschef Region Syddanmark +45/76631169 svend.holm.henriksen@regionsyddanmark.

Konsulent resume. Referencer Svend Holm Henriksen IT-udviklingschef Region Syddanmark +45/76631169 svend.holm.henriksen@regionsyddanmark. Konsulent resume Navn: Adresse: Kemal Pajevic Klingstrupvænget 105, 2-tv 5230 Odense M Telefon: 29726221 / 63130411 Email: kemal@pajevic.dk Født: 31.07.1982 Civilstand: Gift Jeg er en meget åben og udadvendt

Læs mere

Professionel Udvælgelse i byggeriet Skabeloner

Professionel Udvælgelse i byggeriet Skabeloner Professionel Udvælgelse i byggeriet Skabeloner Vejledning i anvendelsen af skabeloner til brug for udvælgelse, herunder prækvalifikation i byggeriet Marts 2013 Byggeriets Evaluerings Center SOLIDARISK

Læs mere

Indhold. Evalueringsvejledning. En undersøgelse fra start til slut involverer 4 programmer: - SurveyXact - Excel - E-learn - SiteCore

Indhold. Evalueringsvejledning. En undersøgelse fra start til slut involverer 4 programmer: - SurveyXact - Excel - E-learn - SiteCore Evalueringsvejledning En undersøgelse fra start til slut involverer 4 programmer: - SurveyXact - Excel - E-learn - SiteCore Indhold 1 - Respondentgruppe hentes... 2 2 Undersøgelsen oprettes i SX... 4 3.

Læs mere

INDHOLDSFORTEGNELSE. En ny og moderne Project... 7 Jørgen Koch. KAPITEL ET... Kom godt i gang. KAPITEL TO... 27 Oprettelse af et nyt projekt

INDHOLDSFORTEGNELSE. En ny og moderne Project... 7 Jørgen Koch. KAPITEL ET... Kom godt i gang. KAPITEL TO... 27 Oprettelse af et nyt projekt INDHOLDSFORTEGNELSE En ny og moderne Project... 7 Jørgen Koch KAPITEL ET... Kom godt i gang Det nye look... 10 Startskærmen... 11 Programvinduet... 12 Visninger... 13 Kolonneoverskrifter... 14 Rækkeoverskrifter...

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Stamoplysninger til brug ved prøver til gymnasiale uddannelser Termin Institution Uddannelse Fag og niveau Lærer(e) Hold Termin hvori undervisningen afsluttes: maj-juni 2013 HTX

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15

Installation og Drift. Aplanner for Windows Systemer Version 8.15 Installation og Drift Aplanner for Windows Systemer Version 8.15 Aplanner for Windows løsninger Tekniske forudsætninger Krav vedr. SQL Server SQL Server: SQL Server 2008 Express, SQL Server 2008 R2 eller

Læs mere

DM502. Peter Schneider-Kamp (petersk@imada.sdu.dk) http://imada.sdu.dk/~petersk/dm502/

DM502. Peter Schneider-Kamp (petersk@imada.sdu.dk) http://imada.sdu.dk/~petersk/dm502/ DM502 Peter Schneider-Kamp (petersk@imada.sdu.dk) http://imada.sdu.dk/~petersk/dm502/ 1 DM502 Bog, ugesedler og noter De første øvelser Let for nogen, svært for andre Kom til øvelserne! Lav opgaverne!

Læs mere

Brugersiderne for renteberegninger. Indhold. 1. Indledning. Anvendelse af. (Version 28. september 2014)

Brugersiderne for renteberegninger. Indhold. 1. Indledning. Anvendelse af. (Version 28. september 2014) Anvendelse af Brugersiderne for renteberegninger. (Version 28. september 2014) Indhold Brugersiderne for renteberegninger.... 1 1. Indledning... 1 2. Forudsætninger... 4 3. Indtastning af udbetaling/skyldigt

Læs mere

Smart-ebizz Manual til Bookinsystem Indholdsfortegnelse Kom hurtigt i gang med dit booking system:... 3 Overblikket over dit bookingsystem... 4 Hovedside... 4 Kunder... 4 Opret ny Kunde... 4 Vagtplaner...

Læs mere

TDCs Signaturserver. 11/05 - Version 1.0 2005 TDC Erhverv Sikkerhed og certifikater

TDCs Signaturserver. 11/05 - Version 1.0 2005 TDC Erhverv Sikkerhed og certifikater TDCs Signaturserver Side 2 Indhold Indledning...3 Teknisk projekt... 3 Tekniske forudsætninger... 3 Installation af klienten... 4 Udstedelse af signatur... 4 Anvendelse af signaturen... 6 Eksport af signaturen...

Læs mere

Internet Information Services (IIS)

Internet Information Services (IIS) Internet Information Services (IIS) Casper Simonsen & Yulia Sadovskaya H1we080113 06-11-2013 Indholdsfortegnelse Problemformulering... 2 Hvorfor:... 2 Hvad:... 2 Hvordan:... 2 Problembehandling... 3 Introduktion...

Læs mere

xgalleri Mulige filtyper Installation web-version

xgalleri Mulige filtyper Installation web-version xgalleri xgalleri opstod ud fra ønsket om at lægge en større samling billeder på nettet. Der findes mange programmer, som kan bruges til at lægge datafiler på nettet; men de fungerer typisk på den måde,

Læs mere

Introducering af Flip MinoHD: http://celikshadow.dk/flip/

Introducering af Flip MinoHD: http://celikshadow.dk/flip/ Introducering af Flip MinoHD: http://celikshadow.dk/flip/ Ahmad Hahmoud Besir Redzepi Jeffrey Lai 04/05-2009 2.semester 3. projekt Indholdsfortegnelse: 1.0 Forord 3 2.0 Kommunikationsplan 4 3.0 Navigationsdiagram

Læs mere

Manual til Wordpress. 1. Log ind på din Wordpress-side. Indhold:

Manual til Wordpress. 1. Log ind på din Wordpress-side. Indhold: Manual til Wordpress Sådan opdaterer du din hjemmeside i Wordpress: Dette er en manual til de mest grundlæggende ting, så du selv kan redigere indholdet eller tilføje nyt på din hjemmeside. Guiden er skrevet

Læs mere

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007

IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med

Læs mere

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk OS2 Opgavefordeler Løsningsbeskrivelse Version 2 Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk 15/2/2015 Løsningsbeskrivelse for OS2 Opgavefordeler 1. Introduktion... 3 2. Kontekst... 3

Læs mere

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Kommentar fra KMS til Specifikation af Serviceinterface for Person Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt

Læs mere

Opstart. I gang med Dreamweaver. Læs mere om... Generelle bemærkninger. Hvilken skærmopløsning? OBS

Opstart. I gang med Dreamweaver. Læs mere om... Generelle bemærkninger. Hvilken skærmopløsning? OBS Generelle bemærkninger Programmet Dreamweaver har været på markedet i nogle år efterhånden. Den seneste version hedder Dreamweaver CS4, og programmet er på engelsk. Dreamweaver er en såkaldt grafisk editor,

Læs mere

Brugervejledning for. Telenor Dialer

Brugervejledning for. Telenor Dialer Brugervejledning for Telenor Dialer 1 Indholdsfortegnelse Generelt om Telenor Dialer.... 5 Telenor Dialer og OneNumber.... 6 Telenor Dialer og OneNumber Mobile.... 6 Faciliteter i Telenor Dialer...7 Installation

Læs mere

Spiller / Pårørende manual Til www.kampseddel.dk

Spiller / Pårørende manual Til www.kampseddel.dk Spiller / Pårørende manual Til www.kampseddel.dk Brugervejledning for Spiller/Pårørende Kort om kampseddel.dk Kampseddel.dk er udarbejdet som et webbaseret værktøj til den frivillige Træner/Leder i en

Læs mere

Grundlæggende IT (Pakke nr. 55 på positivlisten) IT-kurser i det du har brug for

Grundlæggende IT (Pakke nr. 55 på positivlisten) IT-kurser i det du har brug for IT Grundlæggende IT (Pakke nr. 55 på positivlisten) IT-kurser i det du har brug for Boulevarden 19D DK - 7100 Vejle tel: +45 7216 2830 www.campusvejle.dk GRUNDLÆGGENDE KURSER ER DU NYBEGYNDER, BØR DU OVERVEJE

Læs mere

1. Opbygning af et regneark

1. Opbygning af et regneark 1. Opbygning af et regneark Et regneark er et skema. Vandrette rækker og lodrette kolonner danner celler, hvori man kan indtaste tal, tekst, datoer og formler. De indtastede tal og data kan bearbejdes

Læs mere

Indholdsfortegnelse for kapitel 1

Indholdsfortegnelse for kapitel 1 Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................

Læs mere

Brugervejledning for Microstation til OpenSceneGraph konverter

Brugervejledning for Microstation til OpenSceneGraph konverter Brugervejledning for Microstation til OpenSceneGraph konverter - sidste rettelse: 10/06/2005 side 1 Indholdsfortegnelse Kort oversigt over dgn2osg... 3 Systemkrav... 3 Funktionalitet...4 Geometri...4 Materialer...

Læs mere

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER -

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER - SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW 1. - SUPERBRUGERE OG MEDLEMMER AF RETTIGHEDSGRUPPER - INTRODUKTION TIL SKOLERNES DIGITALE BLANKET FLOW Vi er glade for at kunne byde velkommen til opdateret

Læs mere