1 Domæne Design valg User Klassediagran 5

Transkript

1 INDHOLD 1 Domæne Design valg User Klassediagran 5 3 Serbio Kommunikation Bruger authentificering Exceptions Database Entity Framework Booking Sædevalg Algoritme Client Eksempler Konklusion 12 1

2 KAPITEL 1 DOMÆNE I vores domæne model, som ses i figur 1.1, har vi 10 klasser, som hver især har sine attributter. Hver klasse har enten en association, aggregation, composition og generalization som forbinder de forskellige klasser med hinanden. User kan antage én af de 3 roller ( Customer, Admin eller Assistant ). En Customer kan have 0 til mange reservationer, der igen kan have 1 til mange forskellige priser. Dette giver mulighed for at have forskellige prisniveauer. For at oprette et show er en movie med yderligere detaljer om hvor og hvornår filmen bliver afspillet. Det er en 1 til 1 forbindelse mellem Show og Hall, da et show skal være tilknyttet til en sal for at kunne oprettes, og ligeledes, hvis en film skal køre i flere sale på samme tid, er der tale om flere shows. En Hall har en 1 til mange relation til Row, da man ikke kan have en sal uden rækker. Endvidere har Row en 1 til mange relation til sæder. Her gælder samme argument: Det er ikke muligt at oprette en række uden sæder. Hvis der skal oprettes gange i salen, vil dette være en række sæder, med et særligt flag, der fortæller det er tomme sæder. 1.1 Design valg Intro + Her skal vi nu nok have skrevet lidt mere? Relationen mellem Reservation og Price er lavet da det vil gøre det muligt at kunne håndtere forskellige pris niveauer (Premiere/Normale, Voksen/Barn... ) User Denne klasse er en superklasse der alt efter Role bruges til at instantiere forskellige roller af en bruger. Følgende intervaller bruges: Denne inddeling af værdier er valgt, da dette giver mulighed for flere underroller hos administratoren. Talværdien skal læses som: Prefix er altid 1 da dette indikerer admin rolle. Alle andre værdier er boolske og viser hvad man kan. 2

3 KAPITEL 1. DOMÆNE Figur 1.1: Domæne model Rolle Værdi Admin Assistant Customer Tabel 1.1: Rolle intervaller Prefix UserControl AddMovie AddShow AddHall 1 1/0 1/0 1/0 1/0 Tabel 1.2: AdminVærdier 3

4 KAPITEL 1. DOMÆNE Eksempel Admin:Alt : Admin:UserControl : Admin:UserControleAddShow :

5 KAPITEL 2 KLASSEDIAGRAN Klassediagrammet for vores data tier kan ses i figur 2. Main klassen (skal nok omdøbes?) står for selve kontrollen af laget. Det er denne brugeren kommunikere med gennem UI et. Herfra er det muligt at instantiere 4 klasser, og gemme dem i lister. Det meste af funktionaliteten er lagt ud på de forskellige klasser, og hvert kald har returntypen string. Det er her meningen at de forskellige kald skal retunere en string med SQL (eksempel ses i listing 2.1) der bliver sendt videre til serven, der eksekvere koden, og sender et resultat tilbage. Et eksempel på dette, kan ses i Listing Users.editName(string fname, string lname) 2 { 3 String SQL; 4 if (fname!= null && lname == null) 5 { 6 SQL = "UPDATE Users SET fname = "+fname+" WHERE Id = " + id+";"; 7 } return SQL; 10 } Listing 2.1: Eksempel på generering af SQL (User klassen) 1 String editdescripsql = Movie.editDescp("New description"); 2 int result = executesql(editdescripsql); 3 if (result == 1) 4 { 5 Console.WriteLine("Success!"); 6 } 7 else 8 { 9 Console.WriteLine("Some error"); 10 } Listing 2.2: Kald til Movie.editDescrip(string newdescrip) De fire lister i Main klassen (halls, movies, shows, users) står for håndteringen af de forskellige objekter i systemet. Main.addMovie(...) vil både håndtere oprettelse af en ny 5

6 KAPITEL 2. KLASSEDIAGRAN film, indsættelse i listen og generering af SQL, som set i listing Main.addNewMovie(args) 2 { 3 Movie m = new Movie(args); 4 String SQL = "SQL"; 5 int result = executesql(sql); 6 if (result == 1) 7 { 8 movies.add(m); 9 } 10 else 11 { 12 Console.WriteLine("Something fishy happened :-\("); 13 } 14 } Listing 2.3: Tilføj ny film 6

7 KAPITEL 3 SERBIO Serveren, Serbio, er opbygget efter 3-lags pricippet, og indeholder et service library, en host process, og et bussiness logic lag. Alt kommunikation går gennem hostprocessen, der sender data videre til service library et der kalder bussiness logic s funktioner for at lave udregningerne. Serbio er lavet således at så meget beregning som muligt ligger her. Dette betyder at klienterne kan være letvægtede, da det eneste de skal håndtere er diverse kald og grafisk repræsentation af data. 3.1 Kommunikation Kommunikationen mellem server og (mulige) klienter foregår via WCF 4.5, der er et framework til.net 4.5. Serveren sender SOAP data, der gør at klientent kan implementeres cross-platform, et eksempel på dette kan ses i listing 3.1(request) og listing 3.2 (response). A-B-C Konfigurationen følger ABC opsætningen af WCF (Address, Binding, Contract). I denne sektion vil de forskellige dele blive beskrevet. Address Addressen er ip en på serveren, sammen med en port. Serbio kører på port <host> 2 <baseaddresses> 3 <add baseaddress = " /> 4 </baseaddresses> 5 </host> Binding Serbio bruger basichttpbinding. Denne protokol giver i modsætning til nettcpbinding mulighed for platformfrie klienter, dog med den pris, at der bliver sendt mere data. Vi har 7

8 KAPITEL 3. SERBIO 1 <s:envelope xmlns:s=" 2 <s:header> 3 <Action s:mustunderstand="1" xmlns=" addressing/none"> 4 </s:header> 5 <s:body> 6 <Connect xmlns=" 7 <username>kirs</username> 8 <password>9000</password> 9 </Connect> 10 </s:body> 11 </s:envelope> Listing 3.1: Request 1 <s:envelope xmlns:s=" 2 <s:header /> 3 <s:body> 4 <ConnectResponse xmlns=" 5 <ConnectResult xmlns:a=" xmlns:i=" 6 <a:id>3</a:id> 7 <a:password>9000</a:password> 8 <a:role>1337</a:role> 9 <a:token>kirs@rksy8s12kcedetypypax</a:token> 10 <a:username>kirs</a:username> 11 </ConnectResult> 12 </ConnectResponse> 13 </s:body> 14 </s:envelope> Listing 3.2: Response 8

9 KAPITEL 3. SERBIO valgt at prioritere fleksibilitet over hastighed ved at bruge HTTPBinding fremfor nettcp- Binding. Valget er faldet på dette, da c# ikke er det mest brugte sprog 1, og ved at vælge en platformfri protokol, vil det også være muligt at forholdsvist nemt implementere løsninger på ekstempeltvist Android eller iphone. Ccontract Serbio har en masse contracts, et lille udsnit er: BookSeats(...),AddReservation(...) og GetAllReservationsForUser(...). Alle disse er stillet tilrådighed gennem interfacet ISerbioOperations Bruger authentificering WCF indeholder ikke mulighed for sessionstyring per default. Derfor er det nødvendigt at implementere vores egen løsning til dette. Vores primære grund til at skulle bruge sessionstyring er, at det skal være muligt at invalidere reservationer hvis de overskrider en prædefineret tid (i vores system, kan billetter holdes i 10 minutter - hvis de ikke er blevet reserveret efter dette, vil det være muligt for andre at vælge dem). Connect Når en klient skal logge ind, sker dette ved at kalde.connect(string username, string password). Herefter vil serveren checke om det er korrekt bruger og kodeord. Er dette tilfældet, vil serveren tildele brugeren en Token og sende en UserDTO objekt tilbage til klienten. Dette objekt skal bruges til senere kommunikation der kræver brugervalidering. Hvis ikke brugeren kan autentificeres, kastes en exception tilbage til klienten. Purger Purger er vores sessionshåndtering. Dette bliver kørt i sin egen tråd, med et interval på 500ms. Hver gang Purger ticker, vil den se om der er brugere der ikke har været aktive i over 10 minutter. Hvis dette er tilfældet, vil deres token blive fjernet og de vil blive fjernet fra listen af authentificerede brugere. Dermed vil det kræve et nyt.connect(...) før brugeren kan foretage sig ting i systemet, der kræver autentificering. Purger står også få invalidering af sæde reservationer. Koden for dette kan ses i 3.3. Det hele er pakket ind i et TransactionScope, dette vil vi forklare nærmere i sektion 3.3.2, for at sikre consistency. 1 foreach (Reservation res in context.reservation.tolist()) 2 { 3 if (res.resercationtime.addminutes(ttl) < DateTime.Now && res.paid == false) 4 { 5 logger.info("removing reservation " + res.id + " due to session timeout"); 6 context.hasseats.first(s => s.idseat == res.seats).seatstate = 0; 7 context.reservation.remove(res); 8 context.savechanges(); 9 } 10 } Listing 3.3: PurgeReservations invalidering af for gamle reservationer 1 Kilde: 9

10 KAPITEL 3. SERBIO Exceptions Hvis en klient foretager en handling, der af en eller anden grund ikke går godt, vil der blive kastet en exception tilbage. Dette sker gennem throw new FaultException<Exception> som er WCFs måde at kaste exceptions til klienten på. Følgende exceptions kan blive kastet fra serven: DatabaseOfflineException Denne kastet, hvis serveren ikke kan få kontakt til databasen. Dette er en fatal error. DuplicationFoundException Denne kastes, hvis der forsøges at indsættes duplikater af data i databasen. NoShowsException Denne kastes, hvis der ikke er nogle shows is databasen. SeatAlreadyReservedException Denne kastes, hvis der forsøges at reserveres et sæde, der allerede er reserveret. UserLoginException Denne kastes ved forkert login. UserRightsException Denne kastes, hvis en bruger forsøger ting, han ikke har rettigheder til. Excpetions bliver kastet med 2 typer af beskeder: En inner og en outer. Outer message er den, der bliver vist, hvis der ikke er blevet implementeret en try/catch; her vil der blive vist, hvilekn type exception det er, efterfulgt at fejlmeddelelsen. Dette er gjort, så udvikleren nemt kan implementere en catch til den specifikke exception. Inner message, er det der vil blive vist, hvis udvikleren direkte printer på ex.message, som bliver sat i serveren, som i throw new UserRightsException("User not authorized to action GetMovies()"); Listing 3.4: Eksempel på exception Grunden til dette er, at en udvikler skal have nemt ved at finde ud at, hvad der går galt, hvis(når) noget går galt. 3.2 Database Entity Framework 3.3 Booking Sædevalg Algoritme Concurrency 10

11 KAPITEL 4 CLIENT Eksempler 11

12 KAPITEL 5 KONKLUSION 12

13 13 LITTERATUR