SW01: Software Design. Gruppe 4

SW01: Software Design Gruppe 4 Rune Schjellerup (141081), alberd, bioinformatik Mikael Guldager Dahl (290381), mikaeld, datateknologi Morten Thomsen (070481), rahvin, datalogi via datateknologi Jacob Christiansen (130282), moffe42, datalogi via datateknologi Lasse Birnbaum Jensen (040380), gymer, datalogi via datateknologi Afleveret: 17. maj 2004 Samlet antal sider: 28 1

INDHOLD INDHOLD Indhold 1 Reflection 1 1.1 Vores projekt....................................... 1 1.2 Problemer........................................ 1 1.3 Implementations status................................ 1 1.4 Anvendelse af JAVA libraries............................. 2 2 System Vision 3 2.1 Introduktion....................................... 3 2.2 Forretningsmulighed.................................. 3 2.3 Produkt beskrivelse................................... 3 2.4 Risokotagere og deres problemer........................... 3 2.5 Hjælp/Dokumentation................................. 4 2.6 FURPS+......................................... 4 2.6.1 Functionality.................................. 4 2.6.2 Usability..................................... 4 2.6.3 Reliability.................................... 4 2.6.4 Performance................................... 4 2.6.5 Supportability.................................. 4 2.6.6 +.......................................... 5 3 Use-case model 6 3.1 Aktører.......................................... 6 3.1.1 Bruger...................................... 6 3.1.2 Administrator.................................. 6 3.1.3 Gæst....................................... 6 3.1.4 Sensor...................................... 6 3.2 Aktørtabel........................................ 7 3.3 Use-cases......................................... 7 3.3.1 createuser.................................... 7 3.3.2 creategroup................................... 8 3.3.3 createevent................................... 8 3.3.4 locateuser.................................... 8 3.3.5 locategroup................................... 9 3.3.6 sendmessage................................... 9 3.3.7 changelocation................................. 9 3.3.8 getmessages................................... 9 3.3.9 deluser...................................... 9 i

INDHOLD INDHOLD 3.3.10 findfreeroom.................................. 9 3.4 Yderligere use-cases.................................. 10 4 Domain model 11 4.1 Domæne modellen.................................... 11 4.1.1 User........................................ 12 4.1.2 Room....................................... 12 4.1.3 Message..................................... 12 4.1.4 Calendar..................................... 12 4.1.5 Andre overvejelser............................... 12 4.2 Specialisering af Room................................. 12 4.3 Specialisering af Event................................. 13 5 Architecture 14 5.1 Design class diagram - packages........................... 14 5.2 Faktorer......................................... 16 5.2.1 Faktor - Udvidelighed............................. 16 5.2.2 Faktor - Persistens............................... 16 5.2.3 Faktor - Terminaler............................... 16 5.2.4 Faktor - Direkte beskeder........................... 16 5.2.5 Faktor - Registrering.............................. 17 6 Detailed Design 18 6.1 Use-case realisation................................... 18 6.1.1 findfreeroom.................................. 18 6.1.2 createevent................................... 19 6.1.3 locategroup................................... 20 6.2 Design class diagram.................................. 21 6.2.1 controlgroup................................... 21 6.2.2 controluser.................................... 22 6.2.3 controlevent................................... 22 6.2.4 controlroom................................... 22 6.2.5 Group....................................... 22 6.2.6 User........................................ 22 6.2.7 Event....................................... 23 6.2.8 Lecture...................................... 23 6.2.9 Meeting...................................... 23 6.2.10 Calendar..................................... 23 6.2.11 UserCalendar.................................. 24 ii

INDHOLD INDHOLD 6.2.12 RoomCalendar.................................. 24 6.2.13 Mailbox...................................... 24 6.2.14 Message..................................... 24 6.2.15 Room....................................... 24 6.2.16 Classroom.................................... 25 6.2.17 Auditorium.................................... 25 6.2.18 Restroom..................................... 25 iii

1 REFLECTION 1 Reflection Det er ofte svært og tidskrævende at lokalisere personer på MIP, hvis de ikke befinder sig på deres kontor. Denne proces vil blive nemmere og hurtigere ved at lave et system, som kan holde styr på, hvor de registrerede brugere af systemet befinder sig. Ved hjælp af et antal sensorer vil systemet kunne registrere når en bruger bevæger sig ind og ud af overvågede områder. 1.1 Vores projekt Det største problem vi i vores projekt har haft, har været at finde ud hvordan selve koblingen mellem en bruger og de andre funktionaliteter i systemet skulle ske. I første iteration af projektet, havde vi en besked direkte koblet til bruger, hvilket ikke gav os den flexibilitet vi gerne ville have. Samtidig gav det en ret høj kobling mellem bruger og besked, da en mindre ændring i bruger-klassen ville have stor indvirkning på besked delen. Dette har vi ændret i anden iteration, så vi nu har en mailbox, som er direkte knyttet til den enkelte. Dette bevirker at bruger og mailbox er uafhængig, så ændringer i bruger-klassen ikke har indvirkning på mailboxen, da det er brugeren der tilgår mailboxen. Det samme var tilfældet med arrangementer i første iteration. Her var arragementer og brugere tæt koblet. Igen har vi indført et mellemled, her en kalender, så både bruger og arrangement kan ændres uafhængigt af hinanden. Alt dette har gjort det nemmere at rette i de vitale dele i systemet, så som bruger, besked og arrangement. Et tiltag som har medført lavere kobling i systemet. Det vigtige i vores projekt, og det vi har lagt størst vægt på, er at få koblingen så lav som muligt og samtidig holde en relativ høj samhørighed i systemet. Dette lykkes ikke rigtigt i første iteration, da en ændring i domænelaget, medførte ændringer i andre klasser, hvilket gav meget arbejde til ingen nytte. I anden iteration, hvor vi har indført bl.a. mailbox og kalender, har ændringer i de vitale klasser været nemmere, da dette ikke har medført ændringer i andre klasser. Dog har mindre justeringer i mailbox og kalender været nødvendigt. Dette har også vist sig at hjælpe på applikationslaget, da næsten ingen ændringer her har været nødvendige. Fordelen ved alle disse justeringer har været at vi nu har et relativt fast interface til alle de vitale klasser. På trods af alt dette har vi dog haft mulighed for, at holde et konstant interface ud til UI. Da vi ikke har haft en decideret UI, har vi ikke haft stor glæde af dette. Det vil dem, der skal lave en UI, nok have sat pris på. 1.2 Problemer Vi antager at sensorerne er perfekte, og de altid opdager når en bruger ændrer lokation. Man kan imidlertid godt forestille sig, at en bruger ved en fejl kan være registreret til stede i et lokale, selvom brugeren har forladt MIP (f.eks. hvis denne kravler ud af et vindue). 1.3 Implementations status Efter anden iteration har systemet fået mere funktionalitet og eksisterende funktionalitet er blevet refineret. Nogen funktionalitet mangler dog stadig. F.eks. ønskes at hvis en bruger ikke er til stede oplyses forventet ankomsttidspunkt. Endvidere bør en bruger kunne tilkendegive systemet at han ikke ønskes forstyrret, således man ikke kan finde brugeren. I selve use-case implementation mangler der opslagstavler i form af f.eks. forums. Ellers er de fleste blevet implementeret. Med hensyn til sikkerhed i systemet, f.eks. at systemet skal styre adgang til forskellige rum, er dette ikke implementeret da systemet på nuværende 1

1.4 Anvendelse af JAVA libraries 1 REFLECTION tidspunkt udelukkende er et overvågningssystem. Dette kan dog implementeres i senere iterationer, hvor al basal funktionalitet er på plads. 1.4 Anvendelse af JAVA libraries Vi har brugt følgende packages i vores JAVA-inplementation. java.util.arraylist - til brug ved ikke indekserede lister (samlinger). java.util.hashmap - anvender vi til at lave indekserede lister. Dette er en fordel de steder hvor man via en unik identifikation, f.eks. exnr (eksamensnummer) for brugere, kan finde brugere. Endnu en fordel ved at anvende Map er at man kan "konvertere"et Map fra f.eks. HashMap til SortedMap. Overordnet set har vi anvendt en del af JAVAs Collection Framework. 2

2 SYSTEM VISION 2 System Vision 2.1 Introduktion Nedenfor bruges betegnelsen bruger om en person der er blevet oprettet i systemet. Vi forestiller os et system, som gør det muligt at pin-pointe brugere og grupper samt lette kommunikationen mellem brugere på MIP (Mærsk Mc-Kinney Møller Instituttet for Produktions Teknologi). Systemet vil bruge sensorer, der skal placeres forskellige steder på MIP, til at lokalisere/registere brugerne. 2.2 Forretningsmulighed Det eksisterende system registrerer kun personer, der ankommer til MIP efter dørene er låst. Disse informationer bruges kun i forbindelse med tyveri. Lokalisering af personer er så godt som umuligt, da løbende registrering ikke foretages. Det nuværende system til kommunikation mellem personer er telefon og e-mail. Der mangler mulighed for at kontakte personer direkte, uanset hvor de befinder sig i bygningen. Reservering af lokaler sker gennem sekretæren. 2.3 Produkt beskrivelse Systemet laves i Java. Systemet er tiltænkt alle brugere af MIP. Dette vil give mulighed for at lokalisere brugere, som befinder sig på MIP. Systemet vil registrere personer udvalgte steder, for derved at kunne lokalisere folk. Præcisionen hvormed man kan lokalisere brugere øges i takt med at der sættes sensorer op i flere lokaler. Det, der vil adskille dette system fra det nuværende system, er mulighederne for at: 1. Lokalisere personer hele tiden. 2. Kunne kommunikere med brugere, såfremt de er i besiddelse af eller i nærheden af en terminal, f.eks. PDA, mobil telefon eller lignende, der er koblet til systemet. 3. Bruger selv kan reservere lokaler til møder. Administrationen af lokaler vil blive lettet, da systemet hele tiden gennem en kalender funktion holdes ajour med hvilke lokaler der er reserverede og hvilke der er ledige. Systemet vil til dels øge sikkerheden på MIP med hensyn til tyveri, da man kan hente oplysninger om hvilke personer der har opholdt sig hvor og hvornår. Dog er systemet ikke et sikkerhedssystem, men et kommunikationssystem. 2.4 Risokotagere og deres problemer Personer på MIP har brug for at kunne lokalisere brugere, finde ledige/bestemte lokaler, samt at sende beskeder til personer, som skal modtages med det samme. Personer, der ikke er oprettede som brugere i systemet, gæster, skal kunne tilgå basale funktioner, f.eks. lokalisering af brugere. Brugerne ønsker at systemet skal være ligetil at bruge uden at læse dokumentationen (intuitivt). Registreringen må ikke gøre det mere besværligt at bevæge sig rundt på MIP end det nuværende system gør det. Desuden ønsker brugerne at kunne tilgå alle funktioner fra personligt udstyr (bærbar computer, PDA, mobil telefon,.), som var det en af terminalerne installeret på MIP. Registreringen af brugere skal ske uden fejl. Folk vil ikke bruge systemet, 3

2.5 Hjælp/Dokumentation 2 SYSTEM VISION hvis de flere gange er ude for at systemet ikke er pålideligt. Det er et stort administrativt arbejde at oprette alle brugerne. Hvis systemet går ned må der derfor ikke gå data tabt. Systemet skal kunne genstartes uden problemer i det tilfælde at det går ned. Tilslutningen af nye sensorer og lokaler skal være en enkel og hurtig process. 2.5 Hjælp/Dokumentation Brugere af systemet vil modtage en kort introduktion til systemet, hvor den basale funktionalitet vil blive gennemgået. Yderligere hjælp og information om mere avancerede funktioner i systemet vil kunne findes i den tilhørende dokumentation. 2.6 FURPS+ Vi har set på FURPS+ udfra vores system og er nået frem til følgende. 2.6.1 Functionality Systemet kan finde en brugers placering, eller brugere i en gruppes placering, i bygningen. Endvidere kan der sendes beskeder imellem brugere, reserveres lokaler og oprette arrangementer ved brug af et kalender system. 2.6.2 Usability Brugere uden viden om systemet skal kunne tilgå informationer let og ubesværet via terminaler placeret på centrale steder. Administrator opgaver kræver dog større indsigt i systemet. Dokumentation for systemet skal være let tilgængelig og let forståelig. Gæster skal kunne tilgå basale information uden brug af login. 2.6.3 Reliability Det forventes at systemet er pålideligt og driftsikkerheden er høj. Hvis systemet bryder sammen, skal denne kunne genstartes uden problemer. Hardware, såsom sensorer, er af høj kvalitet, og derfor vil defekt hardware sjældent opstå. 2.6.4 Performance Præcision skal være høj og responstid lav. Dermed forventes der at interaktion med bruger sker hurtigt og uden fejl. 2.6.5 Supportability Systemet skal kunne klare et stort antal brugere, samt mange forspørgsler på samme tid. Samtidig skal det være skalerbart således resourcer ikke går til spilde. Konfiguration og vedligeholdelse skal kunne klares ubesværet. Hardware installation skal være plug and play. 4

2.6 FURPS+ 2 SYSTEM VISION 2.6.6 + Systemet implementeres i Java, vha. OOP, således det er nemt porterbart til andre platforme. Der indkøbes adgangs terminaler til centrale positioner, såsom indgange. Ligeledes indkøbes sensorer til alle rum, samt udskifning af UI. Systemet tilgås vha. terminaler eller ekstern elektronik, såsom bærbare computere eller PDA er med mere. 5

3 USE-CASE MODEL 3 Use-case model Først identificeres aktørerne i systemet. Herefter sammensættes de med de use-cases der er implementeret, og tilsidst beskrives use-cases. 3.1 Aktører Under design af systemet har vi fundet 4 aktører. Disse er identificeret som bruger, gæst, administrator og sensor. Nedenfor er disse beskrevet og i afsnit 3.2 er rettighederne beskrevet ved hjælp af aktørtabellen, figur 3.2. 3.1.1 Bruger En bruger er den almindelige aktør overfor systemet og vil derfor kunne bruge størstedelen af systemet funktioner. Der skelnes ikke mellem underviser og studerende, dog vil dette senere kunne differentieres, når det bliver muligt at angive rettigheder til de forskellige brugere. På den måde vil det være muligt at kunne give undervisere flere rettigheder end studerende. 3.1.2 Administrator Administrator er den aktør der har ansvaret for at oprette brugere i systemet, vedligeholde systemet, nedlægge grupper osv. 3.1.3 Gæst Forskellen mellem en gæst og andre brugere af systemet, er begrænsningerne i gæstens brug af systemet. Dette skyldes at en gæst ikke er identificerbar over for systemet, og dermed er der ikke mulighed for at kontrollere gæstens brug af systemet. Gæstens brug af systemet begrænser sig derfor til at kunne lokalisere brugere og rum. Da en gæst ikke er identificerbar over for systemet ville en gæst med, rettighed til f.eks. at sende beskeder, kunne misbruge systemet. 3.1.4 Sensor En sensor er en meget begrænset aktør i systemet, da dens eneste formål er, at sende opdateringer til systemet, så det er muligt at lokalisere brugere. 6

3.2 Aktørtabel 3 USE-CASE MODEL 3.2 Aktørtabel Bruger Administrator Gæst Sensor createuser X locateuser X X X deluser X creategroup X locategroup X X X delgroup X createevent X X delevent X X sendmessage X X getmessages X X showmesage X X delmessage X X createreminder X X sendreminder X X showreminder X X delreminder X X findfreeroom X X changelocation X viewboard X X X delboard X postboard X X Tabel 1: Aktørtabel Et Board er en "online" opslagstavle, hvor brugerne af systemet kan annoncere møder, køb, salg o.s.v. En Reminder er en kort besked brugeren kan sende til sig selv eller andre, som vil minde modtageren om en specifik event, f.eks. 5 minutter før denne starter. Forskelllen mellem en Reminder og en Message er, at Reminderen er en besked, som først sendes til brugeren når tidskriteriet for Reminderen er opfyldt. I tabel 1 er rettighederne for hver aktør beskrevet. En bruger skal have adgang til megen funktionalitet. Essentielle funktioner for systemet skal dog varetages af administrator som har rettighed til alt undtaget ændring af lokation. Sensor er den eneste, der kan ændre lokation for en bruger, da kun denne ved, hvor alle brugere befinder sig. 3.3 Use-cases Vores use-cases, der ønskes implementeres i systemet, er beskrevet nedenfor. De er alle beskrevet i casual format. I tabel 2, afsnit 3.4, er der angivet de use-cases, som ikke er medtaget i denne iteration,disse ønskes implementeret i systemet i senere iterationer.. 3.3.1 createuser Administrator angiver eksamensnummer og navn på en ny bruger. Systemet opretter den nye bruger, dennes mailbox og kalender. Derefter sender det brugerens kodeord tilbage. 7

3.3 Use-cases 3 USE-CASE MODEL Alternativ: - Den nye bruger findes allerede i systemet. Passende fejlmeddelelse sendes til Administratoren. 3.3.2 creategroup Administatoren angiver et gruppenavn. Systemet meddeler tilbage at navnet er OK. Adminitratoren angiver brugere som skal tilføjes gruppen. Systemet tilføjer brugerne til gruppen. Alternativ: - Gruppenavnet findes allerede. Passende fejlmeddelelse sendes til brugeren. - En af de tilføjede brugere findes ikke i systemet. Passende fejlmeddelelse sendes til brugeren. - En af brugerne er allerede tilføjet gruppen. Passende fejlmeddelelse sendes til brugeren. 3.3.3 createevent Brugeren angiver, at han ønsker at afholde et arrangement ved at angive tid, dato og arragementdeltagere. Systemet finder og reserverer ledigt lokale, og sender besked ud til de pågældende deltagere. System fortæller brugeren, at arrangementet er oprettet. Alternativ: - En eller flere af arrangementdeltagerne findes ikke i systemet. Passende fejlmeddelelse sendes til brugeren. - Der er ikke et ledigt lokale på det tidspunkt hvor arragementet ønskes afholdt. Passende fejlmeddelelse sendes til brugeren. Systemet beder brugeren om et nyt tidspunkt. 3.3.4 locateuser Brugeren angiver eksamensnummer eller navn på den person han ønsker at finde. Systemet melder tilbage med hvilket lokale brugeren er i. Alternativt: - Den søgte person er ikke oprettet i systemet og kan derfor ikke findes. Passende fejlmeddelelse oplyses. - Den søgte person er ikke til stede. Sidste tidspunkt hvor personen var til stede oplyses. - Den søgte person er ikke til stede. Personen har angivet næste ankomsttidspunkt og dette oplyses. - Den søgte person har valgt at han ikke vil forstyrres. Dette oplyses og evt. tidspunkt for hvornår personen er ledig igen. 8

3.3 Use-cases 3 USE-CASE MODEL 3.3.5 locategroup Bruger angiver gruppenavn. Systemet melder tilbage med gruppemedlemmernes position. Alternativ: - Gruppenavnet findes ikke. Passende fejlmeddelelse sendes til brugeren. 3.3.6 sendmessage Brugeren laver en besked og angiver hvilken bruger, han vil sende beskeden til. Systemet sender beskeden til den pågældende bruger. Systemet melder tilbage, at beskeden er sendt. Alternativ: - Brugeren, som beskeden sendes til, findes ikke i systemet. Passende fejlmeddelelse sendes til brugeren, der sendte beskeden. 3.3.7 changelocation Sensoren modtager et signal fra en bruger og sender besked til systemet, at den pågældende bruger befinder sig inde for sensorens rækkevidde. 3.3.8 getmessages Brugeren angiver, at han ønsker at få præsenteret alle sine beskeder. Systemet returnerer beskederne. Alternativt: - Der er ingen beskeder i mailboxen. Passende fejlmeddelse sendes til brugeren. 3.3.9 deluser Administratoren angiver, at han vil slette en bruger fra systemet. Systemet sletter brugeren, hans mailbox og kalender. Alternativt: - Den angivne bruger findes ikke i systemet. Passende fejlmeddelse sendes til brugeren. 3.3.10 findfreeroom Brugeren angiver, at han ønsker at finde et ledigt lokale med mindst x antal pladser i et angivet tidsrum. Systemet finder et lokale med x eller flere pladser, som ikke benyttes i det angivne tidsrum. Systemet returnere information om lokalet. Alternativt: - Ingen ledige lokaler i det angivne tidsrum. Passende fejlmeddelse sendes til brugeren. - Ingen ledige lokaler med mindst x pladser. Passende fejlmeddelse sendes til brugeren. 9

3.4 Yderligere use-cases 3 USE-CASE MODEL 3.4 Yderligere use-cases Vi har følgende use-cases, som ønskes i systemet når det er færdigt. Disse indarbejdes i løbet af senere iterationer. delgroup delevent sendreminger createreminder showreminder delreminder viewboard delboard postboard delmessage showmessage Tabel 2: Yderligere use-cases 10

4 DOMAIN MODEL 4 Domain model Ved at analysere på de valgte use-cases, har det været muligt at lave partielle domæne modeller, for de valgte use-cases. De objekter, der igennem analysen er blevet defineret, bliver til sidst sat sammen til en overordnet domæne model. Formålet med domæne modellen er, at give et billede af systemet, set ud fra den virkelige verden. Domæne modellen vil senere give anledning til navngivning af de reelle software klasser, samt at give en ide om, hvordan selve softwaren skal struktureres, så der er en naturlig sammenhæng i systemet. Dette giver en nemmere forståelse og mulighed for lettere at udvide systemet. 4.1 Domæne modellen Ud fra de partielle domæne modeller kan en domæne model udarbejdes. Denne ses på figur 1. For at simplificere domæne modellen har vi udeladt de konceptuelle subklasser til de abstrakte konceptuelle klasser, Room og Event. Figur 1: Domæne model Vores domæne model kan ses som 4 dele: - User - Room - Message - Calendar 11

4.2 Specialisering af Room 4 DOMAIN MODEL 4.1.1 User User er den centrale konceptuelle klasse i systemet. Stort set al kommunikation i systemet indvolverer en bruger. Denne bruger kan være en del af en eller flere grupper, men ikke nødvendigvis. 4.1.2 Room Dette er en abstrakt konceptuel klasse, da denne er en generalisering af specifikke rumtyper. Dette beskrives yderligere i afsnit 4.2. Et rum har tilknyttet en sensor, der benyttes til at ændre brugeres lokation. Room er ligeledes knyttet til User for at beskrive, hvor de registrede brugere befinder sig. 4.1.3 Message Her har vi besluttet at lave et mailbox system. Hver bruger har tilknyttet en mailbox, som indeholder de beskeder der er blevet sendt til denne bruger. 4.1.4 Calendar I domæne modellen har vi lavet 2 kalendere. En kalender der er tilknyttet til en bruger og en tilknyttet et rum, hhv. UserCalendar og RoomCalendar. Event er en abstrakt konceptuel klasse beskrevet yderligere i afsnit 4.3. Event gemmes i de 2 kalendere, når der f.eks. oprettes et møde. 4.1.5 Andre overvejelser I analyse og design fasen af domæne modellen, har vi overvejet at implementere rettigheder for brugere. Dette kunne med fordel benyttes til at begrænse adgang til rum. Vi blev dog enige om, at systemet er et overvågnings system og ikke et sikkerheds system. Dette kan dog implementeres i senere iterationer. 4.2 Specialisering af Room Den abstrakte konceptuelle klasse Room, er vist herunder. Figur 2: Partial domæne model for Room 12

4.3 Specialisering af Event 4 DOMAIN MODEL Som det ses af figur 2, har den abstrakte konceptuelle klasse Room, underklasserne; Auditorium, Restroom og Classroom. Disse laves da lokaletyperne generelt ligner hinanden meget. De har alle en attribut om rygning er tilladt og et id. Underklasserne har hver især deres egne specifikke attributter. 4.3 Specialisering af Event Vi har ligeledes valgt at lave Event, som en abstrakt konceptuel klasse. Dette gøres for nemt at kunne tilføje nye typer af events, hvis dette ønskes senere. Figur 3: Partial domæne model for Event Af figur 3 ses det at vi har valgt at medtage 2 typer af events. Disse er medtaget for at vise funktionaliteten af Events, som en abstrakt konceptuel klasse. 13

5 ARCHITECTURE 5 Architecture For at sikre at man hele tiden har høj samhørighed og lav kobling, er det vigtigt at man holder sine klasser adskilt, så mange ting kan klares i de klasser, hvor de relevante informationer findes. En anden ting, som bruges til at strukturere softwaren, er lagdeling. Lagdelingen sker ved at ting som minder om hinanden, ligges i samme lag. Koplingen mellem disse lag skal være så lav som muligt, så ændringer i et underliggende lag ikke har indflydelse på de overliggende. På den måde sikre man at systemet er konsistent efter en ændring. Som nævnt må ændringer i et lag ikke påvirke andre lag. For nemmere at overholde dette, skal man sikre at man kun kalder ned igennem lagene og ikke kalder op. På den måde sikrer man sig lav kopling, hvilket igen gør det nemmere at vedligeholde og udvikle systemt. 5.1 Design class diagram - packages For at få bedre overblik over strukturen i softwaren, er det muligt at lave nogle overordnede indelinger af de klasser der bruges. Dette gøres ved at inddele alle klasser i pakker. Disse pakker siger ikke så meget om selve klasserne, men en hel del om hvordan de forskellige klasser afhænger af hinanden og arbejder sammen. Figur 4: Design class diagram - packages 14

5.1 Design class diagram - packages 5 ARCHITECTURE Overordnet er hvert lag i hver sin pakke. I domænelaget er de relevante ting i hver sin pakke. Øverst har vi presentationslaget som er en selvstændig pakke. Da dette er det brugeren har adgang til, er der ikke direkte adgang til funktionaliteten i systemet. Dette tilgås via facaden. Facade objektet håndterer samspillet mellem UI og systemet. Adgang til funktionaliteten i de forskellige pakker er markeret med pile i figur 4. Pilene skal forstås på denne måde: Pilen på User betyder at man fra applikationslaget direkte kan tilgå User. For at få fat i en Mailbox skal man igennem User. I Domænelagets klasser ligger de nødvendige informationer om objekterne. Applikationslaget indeholder controllerne, som udfører arbejdet på domænelaget. Altså består Applikationslaget af funktioner/algoritmer og domænelaget af data. Figur 5: Design class diagram - package dependency Figur 5 viser hvordan de forskellige pakker afhænger af hinanden. Pilene viser hvilke klasser der tilgår hvilke underliggende eller sidestillede klasser. Det ses at den brugerflade som brugeren af systemt har, kan tilgå alle relevante klasser i applikationslaget, som så igen 15

5.2 Faktorer 5 ARCHITECTURE kalder de relevante klasser i domain laget. Sensorenes interface kan, som brugerinterfacet, tilgå de klasser der er nødvendige, så de kan udføre sit job. Her kan de tilgå controlroom, så de relevante Room skaffes og herefter kalde controluser, så en brugers aktuelle position kan opdateres. 5.2 Faktorer I visions dokumentet og use-case modellen er der beskrevet en masse faktorer. Vi har overvejet indflydelsen af disse faktorer. Nedenfor har vi beskrevet de, i vores system, vigtigste af disse. 5.2.1 Faktor - Udvidelighed Det skal være nemt at opsætte nye sensorer og koble nye lokaler til systemet. Scenario: Ved tilkobling af nye lokaler skal en sensor tilkobles og lokalet oprettes af administratoren i systemet. Ingen yderligere konfiguration skal være nødvendig. Indflydelse: En ekspert inden for sensorer skal konsulteres. Typen af sensor kan påvirke hvilken information der er nødvendig at gemme om hver bruger til brug for genkendelse. Faktoren registrering påvirker også valget af sensor. 5.2.2 Faktor - Persistens Systemet skal kunne genstartes uden tab af data. Scenario: Alt data i systemet, højst 1 sekund før genstart, skal være til stede i konsistent form efter genstart. Indflydelse: Vi har valgt at udskyde dette element. I senere iterationer vil dette blive vigtigt mere essentielt. 5.2.3 Faktor - Terminaler Der skal udover de af instituttet installerede terminaler, kunne bruges personligt udstyr (bærbare computere, PDAer, mobil telefoner o.s.v.) som terminaler. Scenario: Tilkobling af personligt udstyr skal foregå uden problemer. Indflydelse: En ekspert på området skal konsulteres. Alle typer terminaler, personlige som MIPs, skal tilgå systemet via samme interface (adapter mønstret). Der skal overvejes, hvorledes det bliver genkendt hvilken bruger, der er ved terminalen. 5.2.4 Faktor - Direkte beskeder Beskeder skal modtages med det samme. Scenario: Når der bliver afsendt en besked til en bruger, skal modtageren gøres opmærksom herpå, såfremt denne er i nærheden af en terminal. Systemet skal aktivt informere modtageren om beskeden. Det må ikke være nødvendigt at brugeren selv aktivt gør noget for at tjekke sine beskeder, da det i så fald ikke vil være en forbedring af e-mail systemet. Indflydelse: Der skal placeres minimum 1 terminal per sensor. For at modtage beskeder til brugere i nærheden følges observer mønstret. Af praktiske årsager bliver det også nødvendigt at brugere kan melde til systemet, at de ikke vil forstyrres. 16

5.2 Faktorer 5 ARCHITECTURE 5.2.5 Faktor - Registrering Registreringen må ikke besværliggøre brugernes daglige gang på instituttet. Indflydelse: Sensorerne skal kunne genkende brugerne passivt. Brugeren skal ikke angive et kodeord eller lignende. Løsningen kunne være små sendere der giver sensoren det nødvendige ID, eller genkendelse ud fra udseende. Der skal konsulteres en ekspert inden for området. Faktoren udvidelighed påvirker også valget af sensor. 17

6 DETAILED DESIGN 6 Detailed Design Designet af systemet, tager udgangspunkt i de valgte use-cases. På baggrund af de forskellige use-cases er der lavet sekvens rller collaboration digrammer, som så danner basis for de klasser, som det endelige system indeholder. På de forskellige use-cases er der, brugt GoF og GRASP mønstre, da dette er velafprøvede mønstre, som virker, såfremt de bruges rigtigt. Slut produktet af alle disse use-cases kan ses i vores DCD, hvor alle de software klasser vi har lavet kan ses. I dette diagram ses også den sammenhæng der er mellem klasserne. 6.1 Use-case realisation I afsnit 3.3 er der beskrevet den ønskede funktionalitet, i form af use-cases. Disse use-cases fortæller, hvad der forventes af resultat, når en interaktion mellem bruger og system. I det følgende specificeres systemets use-cases. Vi har valgt tre use-cases, som vi vil kigge nærmere på. For disse tre vil vi beskrive udførelsen af opgaven, ved hjælp af sekvens diagrammer eller kollaborations diagrammer. Vi vil også beskrive hvilke mønstre der bliver brugt, og hvorfor de bliver brugt. 6.1.1 findfreeroom Figur 6: findfreeroom - Sekvens diagram I realiseringen af denne use-case bruges følgende mønstre : - Controller (GRASP) - Singleton (GoF) Controller-mønsteret bruges til at styre sammenhæng mellem metode-kald. Dvs. at control- Room håndterer alle kald omkring Room. Singleton, da der ikke må oprettes flere instanser af control-classerne. Dette gør sig gældende for alle control-classerne. For at finde et ledigt lokale med nok pladser fortages et kald. Dette gøres i form af funktionen getroomminseat, som sortere rummene med bedst egnet lokale først i den liste der bliver returneret, og de dårligste til sidst. 18

6.1 Use-case realisation 6 DETAILED DESIGN Metoden findfreeroom kaldes med start tidspunkt, slut tidspunkt og hvor mange pladser der skal bruges. Klassen controlroom kalder da getroomminseat på en kollektion af Room, og kører derefter i en løkke, hvor den første Room i listen om den er ledig i givne tids rum. Room kalder derefter videre til dennes RoomCalender, så returnere et boolean som svar. Denne løkkes fortsættes til der er fundet èt Room som er ledigt. 6.1.2 createevent Figur 7: createevent - Sekvens diagram I realiseringen af denne use-case bruges følgende mønstre : - Controller (GRASP) - Singleton (GoF) Controller og singleton-mønsteret anvendes med samme begrundelser som angivet i afsnit 6.1.1. Klassen controlevent er controller da denne har ansvaret for at opgaven bliver udført med gennemgående lav kobling. Metoden createevent kaldes med et start tidspunkt, slut tidspunkt og en liste af brugere der skal med til mødet. Først findes et egnet, ledigt lokale til arrangementet. Dernæst oprettes en ny instans af event-typen med angiven tids rum, brugere og lokalet. Nu reseveres det valgte lokale, med metoden addevent i classen RoomCalender, til dette event. Tilsidst startes en løkke, der tilføjer arragementet til alle deltagernes tilknyttede kalender. Dette gøres også med kaldet addevent til UserCalender 19

6.1 Use-case realisation 6 DETAILED DESIGN 6.1.3 locategroup Figur 8: locategroup - Kollaborations diagram I realiseringen af denne use-case bruges følgende mønstre: - Controller (GRASP) - Singleton (GoF) Controller mønstert bruges for at holder diverse kald i tæt sammenhæng, og derved opnå lav kobling. Metoden locategroup kaldes med et gruppe navn. Klassen controlgroup finder da gruppen, og spørger denne gruppe ( ved getusers-metoden), hvilke personer der er tilknyttet denne gruppe. Disse returnes i form af en list af brugere. Til sidst startes en løkke der løber denne liste af brugere igennem, og opretter en liste med de lokaler, som gruppen bruger opholder sig i. 20

6.2 Design class diagram 6 DETAILED DESIGN 6.2 Design class diagram Figur 9: Design class diagram På figur 9 vises vores design class diagram (DCD), der indeholder informationer om klasser og objekter, samt deres relationer til hinanden, der er implementeret i systemet. Attributter og metoder er ikke i selve DCD en, da denne vil blive for uoverskuelig. Vi har derfor valgt at liste og beskrive disse i nedenstående. Som tidligere beskrevet har vi valgt at anvende Singleton mønstret på controllerne, disse behandler så alle kald til de tilhørende underliggerde klasser. F.eks. Alle kan til User, UserCalender, Mailbox kommer gennem controluser, på den måde vil der kunne holdes konsistens i systemet. Ved at anvende Singleton mønstret sikre vi at der kun findes én "samling"af brugere i systemet, denne styres/vedligeholdes via kald til controluser-klassen. 6.2.1 controlgroup controlgroup håndterer metoderne der kaldes på Group objektet, samt styrer relaterede metoder. -groups: List of Group +creategroup(groupname: String) +addmember(user: User, groupname: String) +locategroup(groupname: String) : List of Room +findgroup(groupname: String) : Group 21

6.2 Design class diagram 6 DETAILED DESIGN 6.2.2 controluser controluser håndterer metoder på samme måde som controlgroup, blot på User objekter. -users: List of User +createuser(exnr: Int, name: String, rights: Int) : String +locateuser(user: User) : Room +finduser(exnr, Int) : User +changelocation(user: User, room: Room) +sendmessage(message: String, from: User, to: User, subject: String) +getmessages(user: User) : List of Message +delmessage(subject: String, user: User) +getroom() : Room 6.2.3 controlevent ControlEvent styrer metoderne til Event objekter på samme måde som ControlGroup. // ingen attributer +createevent(type: Event, date: Date, time: Time, endtime: Time) 6.2.4 controlroom controlroom styrer metoderne til Room objektet på samme måde som controlgroup. -rooms: List of Room +addroom(room: Room) +findfreeroom(number_of_users: Int, date: Date) : Room 6.2.5 Group Group er et container objekt. Dvs. den indeholder informationer om en gruppe. -groupname: String -users: List of User +addmember(user: User) +getusers() : List of User 6.2.6 User User er et container objekt. 22

6.2 Design class diagram 6 DETAILED DESIGN -exnr: Int -name: String -password: String -time: TimeStamp -mailbox: Mailbox -calendar: UserCalendar // ingen metoder 6.2.7 Event Event er et abstrakt objekt. Event er tilknyttet underklasserne Lecture og Meeting. -date: Date -time: Time -endtime: Time // ingen metoder 6.2.8 Lecture Lecture nedarver attributter fra den abstrakte klasse Event, og indeholder informationer om dette arrangement. -professor: User -course: String // ingen metoder 6.2.9 Meeting Meeting fungerer på samme måde som Lecture. -participants: List of User -owner: User -subject: String // ingen metoder 6.2.10 Calendar Calender er en abstrakt klasse, Calendar er tilknyttet underklasserne UserCalendar og RoomCalendar. -events: List of Event +addevent(event: Event) 23

6.2 Design class diagram 6 DETAILED DESIGN 6.2.11 UserCalendar UserCalender nedarver attributter fra Calendar objektet. Denne er knyttet til hver User, der styrer de arrangementer vedkomne deltager i afholdes. // ingen attributer // ingen metoder 6.2.12 RoomCalendar RoomCalendar fungerer på samme måde som UserCalender. Denne er som navnet antyder tilknyttet et Room. // ingen attributer +isfree(start: Time, end: Time) : Bool 6.2.13 Mailbox Mailbox er knyttet til hver bruger, der indeholder en liste af beskeder sendt til denne bruger. -messages: List of Message +addmessage(message: Message) 6.2.14 Message Message indeholder den egentlige meddelse, dvs. afsender, indhold o.s.v. -message: String -read: Bool -time: TimeStamp -from: User -subject: String // ingen metoder 6.2.15 Room Room er et abstrakt klasse tilknyttet underklasserne Classroom, Auditorium og Restroom. -id: Int -name: String -smooking: Bool -calendar: RoomCalendar +getroomsminseats(seats: Int) : List of Room +isroomfree(start: Time, end: Time) : Bool 24

6.2 Design class diagram 6 DETAILED DESIGN 6.2.16 Classroom Classroom nedarver attributter fra Room, og indeholder informationer om rumtypen. Classroom betegner almindelige undervisningslokaler. -seats: Int // ingen metoder 6.2.17 Auditorium Auditorium fungerer på stort set samme måde som Classroom. Auditorium betegner eksempelvis en foredragssal eller seminarrum. -seats: Int -projector: Bool -microphone: Bool // ingen metoder 6.2.18 Restroom Betegner toiletter af forskellig art. -gender: String -handicap: Bool // ingen metoder 25