Table of Contents

Reflection
Project: Introduction, problems, discussion, søforklaringer, implementation status, use of Java libraries, …
System vision
Remember identified factors
Use-case model
Domain model
Architecture
View of the design class diagram – layers & parts
Packages and dependencies
Explain how you deal with the identified factors
Detailed design
Design class diagram (one or more)
Use-case realizations
State-charts

Reflection

Projektet ligger i sin definition opad beskrivelsen af Doorman-delen af Ubiquitious Dream Team som beskrevet på de udleverede ark fra Mærsk Instituttet for Produktions Teknologi. I vores version af Ubiquitous Doorman (UbiDoor) har vi lagt vægt på et hændelsesbaseret system, frem for et informationssystem hvor brugeren selv skal opsøge informationerne. Det vil sige at UbiDoor af sig selv viderebringer informationer til slutbrugeren hvis de pårører denne. UbiDoor understøtter dog at informationer kan hentes fra systemet af tilmeldte brugere. Brugere opdeles i vores system, jvf. Visionen, i forskellige grupper.

Denne taksonomi af brugerne giver anledning til at system, udover at være den aktive informationsformidler, også er den passive informationsformidler, i.e. at gæster kan indhente informationer der opbevares i systemet.

I forbindelse med vores Use Cases var er i starten af projektet en overgang hvor UbiDoor blev beskrevet som værende et passivt informationssystem. Efter revision af Use Cases blev UbiDoor redefineret til at være et aktivt, hændelsesbaseret system.

Der har været interne problemstillinger i gruppen der til tider har hindret en normal fremdrift. Enkelte gruppemedlemmer har til tider ikke fulgt den planlagte projekttidsplan hvilket har bevirket, at resten af gruppen måtte bruge unødig tid på at bringe pågældende up-to-date. Yderligere har der så været frister der ikke har været overhold, hvilket igen har bevirket at de resterende gruppemedlemmer har måttet påtage sig ansvaret for færdiggørelsen af opgaver. Dette har igen indvirket at progressionen i projektet ikke har været optimalt.

Vores tilgang til kodningen af systemet har ikke været baseret på en færdig designmodel. Derimod har vi kodet udvalgte Use Cases og set dem i forhold til gennemgået læsning og derefter identificeret Patterns der passer på vores kode. Dette er nok lidt omvendt, men det virker meget godt. Også fordi at vi potentielt senere vil kigge mere på Patterns først og kodning derefter; altså en proces. Vi har implementeret ca. en fjerdedel af de klasser og den funktionalitet der indgår i vores design. Det er primært ukompliceret kode, med brug af ArrayList og Date.

Gruppens sammensætning har gjort at vi har anskuet problemet fra flere forskellige sider. Dette har været en stor fordel.

System Vision

Ubiquitous Doorman er et centralt styret system der holder styr på personer i bygningen, møder, aftaler, kalendere, og meget andet. UbiDoor er underbygningen for de andre dele i Ubiquitous Dream Team. Det er primært til for at lette arbejdsbyrden for administrationen og sekretærerne ved at gøre den information de normalt formidler lettere tilgængelig. Dog kan alle personer tilknyttet systemet kan indlægge egne relevante informationer. Det ville ikke være utænkeligt at systemet udvikler sig til et nøglepunkt i dagsordenen for mange ikke-privilegerede personer. Studerende kan bruge det til at aftale gruppemøder, lærere kan oplyse om aflysning eller flytning af timer, og alle kan sende beskeder til hinanden.

Systemet er ansvarlig for at holde alle personer ajour med informationer der er relevante for dem. Om en given information er relevant er det mest personens eget ansvar at gøre systemet opmærksom på idet personerne kan tilmelde sig informationsgrupper, men systemet skal også delvist kunne (kritisk) forudsige at en person har brug for den givne information. Yderligere er der serviceelementer der tillader at udvalgte brugere af systemet at automatisk aktivere/kontrollere undervisningselementer i lokaler.

UbiDoor er i første omgang indskrænket til Mærsk Instituttets bygning for afprøvning og stabilisering før det eventuelt kan bruges på SDU et al. Af den grund behøver systemet ikke at være absolut solidt fra første implementation. Der skal dog tænkes på at systemet bør kunne arbejde sammen med eksisterende systemer, og derfor skal den første implementation være gennemtænkt med hensyn til mulighed for udbyggelse og interoperabilitet. Og, idet systemet er stærkt centraliseret, skal det kunne modstå diverse ustabiliteter. Altså ikke noget med at miste skemaet for semesteret bare fordi systemet genstartes.

Sikkerhedsmæssigt deles brugere op i 3 overgrupper: Fastansatte, studerende, og gæster. Kun fastansatte og studerende har mulighed for at lægge information ind i systemet, og disse grupper skal bære deres barcode-bearer (BCB) device eller logge ind med navn og password. Gæster har adgang til at se visse informationer, såsom at lokalisere en person. Fastansatte kan ydermere blive tildelt visse privilegier, for eksempel at kunne tilføje og slette brugere eller at kunne oprette et fag.

Det hele kører over et netværk i bygningen. Der er den centrale server, og til denne er der tilsluttet en række klienter. En klient kan være alt fra en PDA, over diverse computere i bygningen, til de fysiske UbiDoor konsoller og sensorer. Derfor skal der udvikles en række protokoller for disse client-server forhold. I sidste ende er de egentlige klienter dog brugerne, så måske det er bedre at sige client-frontend-server forhold. Noget af det fysiske UbiDoor udstyr bliver designet til opgaven (sensorer, BCB-devices), hvor andre dele kan afvikles på normale computere (konsoller, central server). Specielt derfor bliver systemets software udviklet i Java. Valget af Java hjælper også til senere videreudvikling og vedligeholdelse.

Use Case Model

For nemheds skyld er Use Cases opdelt i brugere af tre forskellige grupper: administrationen, undervisere, og studerende. Derudover er der gæster. Hvis der er tale om flere fra samme gruppe er de benævnt StudA og StudB f.eks.

EnterBuilding
En bruger ankommer til MIP, UbiDoor registrerer dette.

ExitBuilding
En bruger forlader MIP, UbiDoor registrerer dette.

EnterRoom
En bruger går ind i et lokale, UbiDoor registrerer dette.

ExitRoom
En bruger går ud af et lokale, UbiDoor registrerer dette.
 
EnterBuildingExpanded
En bruger kommer til indgangen af Mærsk Instituttet og skal ind af en af indgangene. Brugerens ankomst til Mærsk Instituttet bliver registreret. Brugeren får at vide at nogle timer han er tilmeldt er flyttet fra lokale 1 til lokale 2.

LocatePerson
En bruger, StudA, ankommer til Mærsk Instituttet. StudA skal finde en anden bruger, StudB. StudA henvender sig til en UbiDoor. StudA spørger UbiDoor hvor StudB er. UbiDoor fortæller StudA at StudB er i mødelokale 1.

NotWriteMessage
En bruger, StudA, henvender sig til en fysisk UbiDoor. StudA spørger om brugeren StudB er i bygningen, hvilket StudB ikke er. UbiDoor spørger om StudA vil skrive en besked til StudB, men det vil StudA ikke. StudA afslutter.

WriteMessage
En bruger, StudA, henvender sig til en fysisk UbiDoor. StudA skriver en besked til brugeren StudB. UbiDoor afleverer beskeden til StudB hvis StudB er indenfor UbiDoors område, ellers gemmer UbiDoor beskeden og afleverer beskeden når StudB kommer indenfor UbiDoors område.

InterruptWriteMessage
Vi har 2 brugere, StudA og StudB. StudA spørger UbiDoor hvor StudB er, men StudB er ikke i bygningen. StudA vælger at lægge en besked til StudB. Imens StudA skriver beskeden kommer StudB ind i bygningen. UbiDoor fortæller da StudA at StudB nu er her, så han behøver ikke skrive videre (men må godt hvis han vil), og fortæller StudB at StudA leder efter hende.

RegisterMeeting
En bruger finder et møde der har hans interesse. Brugeren tilmelder sig dette møde. UbiDoor registrer dette. UbiDoor spørger brugeren om han vil varsles om mødet. Brugeren vælger at det vil han godt. Brugeren afslutter.

NotifyMeeting
En bruger har tilmeldt sig et møde og valgt at få varsler om dette. UbiDoor registrer at brugeren ikke er i nærheden af mødelokalet hvor mødet afholdes, men han er dog indenfor UbiDoors område.  UbiDoor fortæller brugeren at mødet begynder om 5 min.

DeferNotifyMeeting
En bruger har tilmeldt sig et møde og har valgt at få varsler om dette. Brugeren ankommer til det rigtige mødelokale mere end 5 min. før mødets start. UbiDoor sender derfor ikke varsel til brugeren.

MoveMeeting
En administrator fortæller UbiDoor at studienævnsmødet er aflyst i morgen med afholdes mandag i stedet for. Alle brugere der sidder i studienævnet bliver fortalt af UbiDoor at mødet i morgen er aflyst, men at det afholdes mandag i stedet for.

RescheduleMeeting
En administrator fortæller UbiDoor at studienævnsmødet er flyttet fra mandag til fredag fremover. Alle brugere der sidder i studienævnet bliver fortalt af UbiDoor, at mødet er blevet flyttet varigt fra mandag til fredag.

CancelMeeting
En administrator fortæller UbiDoor at studienævnsmødet mandag er aflyst pga. sygdom. Alle brugere der sidder i studienævnet bliver fortalt af UbiDoor, at mødet mandag er aflyst.

MoveLecture
En underviser fortæller UbiDoor at øvelsestimerne til hans kursus er flyttet fra onsdag til fredag i denne uge. Når en studerende der er tilmeldt kurset er indenfor UbiDoors område, fortæller UbiDoor den studerende at øvelsestimerne er flyttet til fredag.

RescheduleLecture
En underviser fortæller UbiDoor at øvelsestimerne til hans kursus er flyttet fra onsdag til fredag fremover. Når en studerende der er tilmeldt kurset er indenfor UbiDoors område, fortæller UbiDoor den studerende at øvelsestimerne er flyttet til fredag varigt.

CancelLecture
En undervisers undervisning er blevet aflyst. Underviseren fortæller UbiDoor at undervisningen er aflyst i lokale 3 fra 12-14. UbiDoor registrerer dette. En studerende ankommer til MIP og skal have undervisning i lokale 3 fra 12-14. UbiDoor fortæller den studerende af undervisningen er aflyst.

CancelClass
En undervisers kursus er blevet aflyst fordi der var for få tilmeldte. Underviseren fortæller UbiDoor at kurset er aflyst dette semester. UbiDoor registrerer dette. Når en studerende der havde valgt kurset ankommer til MIP, vil UbiDoor fortælle den studerende at kurset er aflyst.

ReverveRoom
En underviser vil reservere et lokale til ekstra undervisning en onsdag kl. 12. Underviseren henvender sig til en UbiDoor. Underviseren finder oversigten over lokaler der er ubenyttede i tidsrummet onsdag 12-14. Underviseren finder lokalet og reserverer det.

CancelRevervedRoom
En underviser vil afmelde reserveringen af et lokale onsdag kl. 12. Underviseren henvender sig til en UbiDoor. Underviseren finder lokalet og afmelder det.

InformClass
En underviser finder et foredrag der har relevans for hans undervisning. Underviseren giver UbiDoor informationerne om foredraget og fortæller at de studerende der følger hans undervisning skal have informationerne næste gang de er indenfor UbiDoor. Når en studerende der er tilmeldt undervisningen kommer indenfor UbiDoors område, vil UbiDoor fortælle den studerende om foredraget.

FrontDoor
En bruger kommer til MIP efter lukketid. Hoveddøren er låst. Brugeren har sin BCB med sig, og døren åbnes automatisk da han nærmer sig. Døren lukkes og låses når han er inde i bygningen.

SecureRoom
Nogle rum er altid låst af (såsom server-rum). En administrator med BCB ankommer til rummet, og indtaster sin kode for at låse rummet op. UbiDoor verificerer dette, og tillader adgangen.

Interesting Use Cases in Casual Format

InterruptWriteMessage
Primært succes scenarie: StudA og StudB. StudA spørger UbiDoor hvor StudB er, men StudB er ikke i bygningen. StudA vælger at lægge en besked til StudB. Imens StudA skriver beskeden kommer StudB ind i bygningen. UbiDoor fortæller da StudA at StudB nu er her, så han behøver ikke skrive videre, og fortæller StudB at StudA leder efter hende.

Alternativt scenarie: StudA vælger at skrive videre på beskeden selvom StudB ankommer imens.

DeferNotifyMeeting
Primært succes scenarie: Stud har tilmeldt sig et møde og har valgt at få varsler om dette. Stud ankommer til et rigtige mødelokale mere end 5 min. før mødets start. UbiDoor sender ikke varsler til Stud.

Alternativt scenarie: Stud ankommer til mødelokalet mere end 5 minutter før, men forlader lokalet igen og kommer ikke tilbage inden 5-minutters fristen. Derfor sender UbiDoor alligevel en besked.

RescheduleMeeting
Primært succes scenarie: En administrator fortæller UbiDoor at studienævnsmødet er flyttet fra mandag til fredag fremover. Alle personer der sidder i studienævnet bliver fortalt af UbiDoor, at mødet er blevet flyttet varigt fra mandag til fredag.

Alternativt scenarie: Administratoren omlægger mødet, men UbiDoor ser at mere end 25% der skal deltage har andre møder på det givne tidspunkt. UbiDoor melder dette tilbage til Administratoren.

CancelRevervedRoom
Primært succes scenarie: En underviser vil afmelde reserveringen af et lokale onsdag kl. 12. Underviseren henvender sig til en UbiDoor. Underviseren finder lokalet og afmelder det.

Alternativt scenarie: Underviseren afmelder reserveringen. UbiDoor ser at nogen der har prøvet at reservere lokalet for ikke så lang tid siden. UbiDoor sender en besked til disse personer om at lokalet nu er ledigt.

FrontDoor
Primære succes scenarie: En person kommer til MIP efter lukketid. Hoveddøren er låst. Personen har sin BCB med sig, og døren åbnes automatisk da han nærmer sig. Døren lukkes og låses når han er inde i bygningen.

Alternativt scenarie: Personen har ikke sin BCB med sig, men han logger ind ved en UbiDoor terminal i stedet for.

Alternativt scenarie: Personen har ikke nogen BCB, og ikke noget login. Han kan ikke komme ind.

SecureRoom
Primære succes scenarie: Nogle rum er altid låst af (såsom server-rum). En administrator med BCB ankommer til rummet, og indtaster sin kode for at låse rummet op.

Alternativt scenarie: Administratoren har ikke sin BCB med, men login er ikke nok så han kan ikke komme ind.

Alternativt scenarie: Rummet kræver enten BCB eller login (ikke begge), og administratoren kan logge ind og låse op.

Architecture
Hubba

Detailed Design
Hubba

Actor Description
Gæster
En end-user af systemet. Har næsten ingen privilegier, andet end at kunne se hvornår der er offentlige foredrag, og lignende.

Studerende
En end-user af systemet. Kan sende/modtage beskeder, oprette gruppemøder, og tilmelde sig notifications.

Undervisere
Også en end-user af systemet, men disse brugere har privilegier til at lave om på deres fag, reservere lokaler.

Administratorer
Endnu en end-user af systemet, men disse brugere har alle privilegier, såsom at oprette og slette andre brugere.

Table of Use Case Actors

	Legend:
		P	Primary actor, highest priority
		S	Secondary actor, medium priority
		T	Tertiary actor, low priority

Use Case / Actor	Studenter	Undervisere	Administratorer	Gæster	
EnterBuilding	P	P	P		
ExitBuilding	P	P	P		
EnterRoom	P	P	P		
ExitRoom	P	P	P		
EnterBuildingExpanded	P	P	P		
					
LocatePerson	P	P	P	P	
NotWriteMessage	P	P	P		
WriteMessage	P	P	P		
InterruptWriteMessage	P	P	P		
					
RegisterMeeting	P	P	P		
NotifyMeeting	S	S	S		
DeferNotifyMeeting	S	S	S		
MoveMeeting	P	P	P		
RescheduleMeeting	P	P	P		
CancelMeeting	P	P	P		
					
MoveLecture	S	P		T	
RescheduleLecture	S	P		T	
CancelLecture	S	P		T	
CancelClass	S	P		T	
					
ReserveRoom	P	P	P		
CancelReservedRoom	P	P	P		
					
InformClass	S	P			
					
FrontDoor	P	P	P		
SecureRoom	P	P	P		

Table 1: Use Case Actors
Identificerer og markerer aktører i overensstemmelse med deres prioritet i forhold til Use Case