Komponent baseret udvikling

Transkript

1 Komponent baseret udvikling Lars Christensen, Jacob Johan Jensen og Jacob Atzen 9. april 2005 Indhold 1 Introduktion Problembeskrivelse Instansbeskrivelse Ambitionsniveau Systembeskrivelse Overordnet beskrivelse Funktionelle krav til systemet Kvalitative krav Drivere Arkitektur Lagdelt arkitektur Data Forretningslogik Brugergrænseflade Brugsscenarier Klientscenarier Booking af tid Visning af reserverede tider Behandlerscenarier Visning af bookinger Ny klient ønsker tid Klient melder afbud Aflysning af møde Administratorscenarier Oprettelse af gentagne bookinger Oprettelse af behandler Midlertidig fjernelse af behandler Sletning af behandler

2 5 Usecases En bruger logger ind En bruger logger ud Klient booker ledig tid hos sin behandler Klient ønsker at se tider som hun har booket tidligere Behandler ser bookinger i sin kalender Behandler skal oprette klient Behandler booker en tid for en klient Behandler aflyser en booket tid Behandler sletter bookede tider i kalender Behandler opretter tider i kalender der er ledige for bookning Administrator skal oprette en serie af ledige bookings hos en behandler En ny behandler skal oprettes i systemet En behandler skal ikke kunne bookes i en periode En behandler skal slettes fra systemet Komponentbeskrivelser Forretningslogik Adgangskontrol Sikkerhed Kalender Lager Generelle overvejelser Flow beskrivelse En bruger logger ind En klient booker ledig tid hos sin behandler OCL Security Calendar Storage AccessControl BusinessLogic Betydningen af OCL constraints Afrunding 34 2

3 1 Introduktion I det følgende gives en beskrivelse af det problem vi ønsker at løse. Formålet med rapporten er, at opnå erfaring med design af komponentbaserede løsninger. Vi har taget udgangspunkt i et konkret problem som beskrevet herunder. 1.1 Problembeskrivelse Det problem vi ønsker at løse er det velkendte ressourcebookingsproblem. Problemet er altså at gøre det muligt at reservere ressourcer på baggrund af en defineret mængde ressourcer, f.eks. lokaler. Denne opgave bygger på en instans af problemet, hvor ressourcerne er tre psykologers tid. Problemet bliver således en kalendervariant af bookingsproblemet. Problemet er allerede løst med et kørende system og det er med udgangspunkt i dette system, at nærværende rapport er udarbejdet. 1.2 Instansbeskrivelse Den aktuelle instans er som nævnt booking af tre psykologers tid. Der er to hovedroller knyttet til dette: Psykolog og klient. Booking af tider er underlagt nogen regler, som beskrevet herunder. Psykologerne arbejder uafhængigt af hinanden, så hver psykolog har sin egen kalender. Psykologerne er kun tilgængelige for klienter på forud definerede tidspunkter og disse tidspunkter skal reserveres af psykologen. Disse tider er ikke reserveret til en specifik klient, men kun gjort tilgængelige så klienter kan reservere tiden. Derudover bruger psykologerne tid på andre ting som også skal reserveres, f.eks. møder. En konsultation varer typisk 1 time men kan have en anden varighed. Derudover skal psykologen bruge 15 minutter før hver konsultation på forberedelse. En klient skal maksimalt kunne booke 3 tider frem i tiden. Klienter er knyttet til en bestemt psykolog og kan kun reservere tid hos denne. Af hensyn til psykologernes planlægning, er det ikke muligt at booke tider til den efterfølgende dag efter kl

4 1.3 Ambitionsniveau Den beskrevne løsning er forsøgt holdt så simpel som muligt i forhold til de givne krav. Motivationen for dette er, at det er svært at forudsige, hvilke krav fremtiden vil stille. Desuden er en af løfterne ved komponentbaseret udvikling, at det bliver nemmere at rette dele af systemet til, hvorfor prisen ved ikke at prøve at gøre løsningen fremtidssikker vil være mindre. 4

5 2 Systembeskrivelse Dette afsnit beskriver mere konkret det aktuelle system. Først gives en overordnet beskrivelse af systemet og dernæst detaljeres de forskellige krav der er identificeret. 2.1 Overordnet beskrivelse Det eksisterende system er en webbaseret grænseflade, hvorfra en database tilgås mere eller mindre direkte. Det nye system vil ligeledes være webbaseret, men vil prøve at fjerne den hårde afhængighed mellem brugergrænseflade og database. Vi vil læne os op af det eksisterende system i forhold til at identificere krav til systemet. Det eksisterende system definerer tre roller til løsningen af problemet: Klient, behandler og administrator. Klienter er kunder, der har behov for behandling. Behandlere er de psykologer, hvis tid kan reserveres. Administrator en ekstern person, der har til opgave at drive systemet. En bruger af systemet har tilknyttet en bestemt rolle og det er denne rolle, der definerer hvilke rettigheder brugere har i systemet. Bemærk, at begrebet behandler optræder i to kontekster. Først og fremmest er en behandler en af de psykologer, hvis tid er en ressource i systemet. Derudover er behandler en rolle som en bruger af systemet kan være tilknyttet. Det vil normalt være oplagt, hvilken kontekst der benyttes når behandlere omtales i teksten. Klienter har kun rettighed til at booke ledige tider og se tidligere bookede tider for dem selv. Det er meningen, at behandlere skal have rettighed til at reservere både egen og andres tid og håndtere eksisterende bookinger. Administrator har samme rettigheder som behandlere, men kan tillige oprette og fjerne behandlere fra systemet. 2.2 Funktionelle krav til systemet Her gennemgås hvilke funktionelle krav, der er til systemet. Det skal være muligt at: Oprette og nedlægge ressourcer (behandlere) i det tilfælde, at en psykolog siger op eller en ny bliver ansat. Oprette og nedlægge brugere med brugernavn, rolle og evt. yderligere information. Knytte en klient til en behandler. Oprette og nedlægge bookinger. 5

6 Ændre status på en booking, f.eks. ændre den fra ledig til optaget. Oprette og nedlægge andre aftaler, eksempelvis møder, kurser etc. Få et overbliksbillede over aftaler for dag/uge/måned. Incl. de ikke bookede tider. Oprette klienter. Ændre klient data. Brugerhåndtering igennem login, så det sikres, at brugere kun får mulighed for at gøre det, de har rettigheder til. En klient skal maksimalt kunne booke 3 tider frem i tiden. Klienter er knyttet til en bestemt psykolog og kan kun reservere tid hos denne. Af hensyn til psykologernes planlægning, er det ikke muligt, at booke tider til den efterfølgende dag efter kl. 20. Klienter skal kun kunne booke foruddefinerede tidspunkter. 2.3 Kvalitative krav Udover de funktionelle krav er der også nogen kvalitative krav: Stabilt - forretningen er meget afhængig af dette system. Høj sikkerhed da der arbejdes med følsomme klientdata. Disse må ikke lækkes til tredie-part. Nemt at udvide, så system eksempelvis kan bruges på andre grænseflader såsom mobiltelefon. Brugervenligt og hurtigt for behandlere, jo færre avancerede muligheder, jo bedre. Ekstremt simpelt og brugervenligt for klienter. 2.4 Drivere På baggrund af de gennemgåede krav kan vi udvælge de vigtigste i forhold til valg af arkitektur for systemet. Vi har identificeret følgende drivere i forhold til systemet: Nemt at lave forskellige frontends. Nemt at modellere business logic for forskellige roller. 6

7 Udvidbart. Skal kunne udvides med ny funktionalitet. Sikkerhed. Klientdata må ikke kunne lækkes til tredjepart. 7

8 3 Arkitektur Nærværende afsnit beskriver den arkitektur designet er baseret på. 3.1 Lagdelt arkitektur På baggrund af de drivere, der er identificeret i afsnit 2.4 har vi valgt en klassisk lagdelt arkitektur. At arkitekturen er lagdelt betyder, at komponenter i et vilkårligt lag udelukkende stiller services til rådighed for komponenter i sig eget lag og laget over og udelukkende bruger komponenter i sit eget lag og laget under. Der er identificeret tre overordnede lag: Brugergrænseflade, forretningslogik og data. Hvert af disse lag kan underinddeles mere finkornet. De tre lag gennemgås herunder nedefra: Data Datalaget står for håndtering af data i applikationen. Datalagets eneste opgave bliver således at stille datalagringsservices til rådighed for forretningslogikken. Dette kan f.eks. være komponenter til databaseabstraktion og håndtering af transaktioner. I det aktuelle eksempel er datalaget tænkt som en database, med en meget tynd logik ovenpå, der tillader lokalisering, hentning og lagring af poster gennem et API Forretningslogik Forretningslogikken indeholder kerne komponenterne for applikationen. Det er disse komponenter, der beskriver hvilke regler, der eksisterer i applikationen. Det kan f.eks. være regler for autorisering og reservation. Forretningslogikken har ligeledes til ansvar, at stille model services til rådighed for brugergrænsefladen. Det vil sige komponenter, der beskriver applikationens aktuelle tilstand, f.eks. hvilke tider, der er til rådighed. I det aktuelle design indeholder forretningslaget adskillige komponenter. Den primære er forretningslogikkomponenten, der definerer reglerne for adgang til systemet. Herudover findes to sikkerhedskomponenter og en kalender komponent Brugergrænseflade Brugergrænsefladelaget indeholder de komponenter, der står for at interagere med brugeren. Komponenter i dette lag omfatter komponenter til rendering af skærmbilleder, generering af fejlbeskeder, håndtering af brugerinput, styring af flowet i applikationen, etc. Man kan forestille sig flere forskellige måder at eksponere applikationen til brugere på. Umiddelbart ligges der op til en webbaseret grænseflade til 8

9 applikationen, men i og med den er komponent baseret vil man nemt kunne erstatte web frontenden med f.eks. en SOAP frontend, så man kan lave native klient applikationer, der kan snakke med serveren. 9

10 4 Brugsscenarier Dette afsnit beskriver forskellige brugsscenarier for systemet. Scenarierne beskriver i rimelig detalje, hvilke skridt der er involveret i at gennemføre en given opgave i systemet. Som hjælp til forståelsen af beskrivelserne er hentet nogen skærmbilleder fra det eksisterende system, der ligger til grund for systemet beskrevet her. Billederne vil blive refereret med figur reference første gang de bruges, herefter vil de kun blive refereret til ved navn. 4.1 Klientscenarier I det følgende beskrives to scenarier for, hvad klienter kan ønske at gøre med systemet Booking af tid Klienten sætter sig for at bestille en tid hos en behandler. Klienten starter sin browser og logger ind på systemet. Her bliver klienten præsenteret for et skærmbillede, der indikerer, at han er logget ind og han kan her fra en menu vælge yderligere handlinger, se figur 1. Figur 1: Klient menu Da klienten gerne vil booke en tid hos en behandler, vælger han menupunktet Book ny tid og bliver sendt til en oversigtsside, der viser en delmængde af de ledige tider klienten har mulighed for at reservere, se figur 2. Klienten vælger nu en tid på listen og bliver bedt om at bekræfte, at han virkelig ønsker at booke den valgte tid. Han bekræfter, at han gerne vil booke tiden og bliver sendt tilbage til siden vist på figur 1. 10

11 Figur 2: Klient book tid 11

12 Idet klienten er færdig med at bruge systemet vil han gerne logge ud, hvilket sker, når der trykkes på knappen logout Visning af reserverede tider Efter et stykke tid har klienten glemt, hvilke tider han har booket i systemet. Han vil derfor gerne undersøge, hvilke tider han aktuelt har booket. Klienten logger derfor ind på systemet og præsenteres for samme side som beskrevet i forrige afsnit. Han vælger nu Vis bookede tider og bliver sendt til en oversigtsside over hans bookinger som vist på figur 3. Figur 3: Klient vis bookede tider Klienten har således fået det ønskede overblik og ved at klikke på Din menu menupunktet bliver han sendt tilbage til siden med logout knappen så han kan afslutte sin session i systemet. 4.2 Behandlerscenarier Herunder er beskrevet, hvilke opgaver behandlere kan tænkes at ville løse med systemet Visning af bookinger Behandleren møder på arbejde og vil have et overblik over hvilke klienter, der kommer denne dag. Behandleren logger ind på systemet og bliver mødt af en oversigt over ressourcerne som vist på figur 4. Behandleren har nu fået det overblik, der ønskes og behandleren logger ud af systemet. 12

13 Figur 4: Behandler dagsoversigt 13

14 4.2.2 Ny klient ønsker tid En klient ringer for at bestille en tid. Da klienten ikke eksisterer i systemet skal klienten først oprettes. Behandleren logger derfor ind og navigerer til klient oprettelses siden, se figur 5. Behandleren indtaster klientens data og opretter klienten. Klienten vil nu gerne have reserveret en tid, så behandleren navigerer til ugeoversigten for den ønskede behandler, som vist på figur 6. Behandleren kan her se, hvilke tider der er ledige og vælger den tid klienten ønsker. Behandleren får herefter redigeringssiden for den valgte booking (figur 7) frem og ændrer status (type) og klient på bookingen. Behandleren er nu færdig med at bruge systemet og logger ud Klient melder afbud En klient ringer for at fortælle, at hun ikke kan møde op til aftalt tid alligevel. Klienter kan ikke selv fjerne deres reservationer fra systemet, så behandleren skal afmelde bookingen. Behandleren logger nu ind på systemet og navigerer til ugeoversigten for den pågældende tid. Herfra navigeres videre til bookingen og redigeringssiden kommer frem. Behandleren markerer nu, at tiden igen er ledig ved at ændre status (type) på tiden og tømmer tillige klientfeltet. Bookingen gemmes og behandleren logger ud af systemet Aflysning af møde En behandler har aftalt et møde næste uge. Da mødet bliver aflyst vil behandleren fjerne sin mødebooking fra systemet og istedet oprette to nye tider, så dagen kan bruges på klienter. Behandleren logger nu ind i systemet og navigerer til redigeringssiden for mødebookingen. Herfra slettes mødebookingen og dagen er nu fri til andre opgaver. Behandleren navigerer til dagsoversigten og opretter en formiddagstid ved at klikke på et ledigt tidspunkt om formiddagen, hvorefter booking redigeringssiden kommer frem. Behandleren angiver, hvor længe tiden varer og opretter tiden. Herefter gøres det samme for eftermiddagstiden. Endelig logger behandleren ud af systemet. 4.3 Administratorscenarier I det følgende er beskrevet, hvilke opgaver administratorer kan løse med systemet. Bemærk, at administratorer også har adgang til at løse de samme opgaver som behandlere, så behandlernes scenarier gælder også for administratorer. 14

15 Figur 5: Opret klient 15

16 Figur 6: Behandler ugeoversigt Figur 7: Behandler book tid 16

17 4.3.1 Oprettelse af gentagne bookinger Administratoren har mulighed for at foretage en hurtig oprettelse af adskillige tider. Behandlerne har principielt samme mulighed, men de har svært ved at overskue det, hvorfor det typisk er administratoren, der foretager denne handling. På sit månedlige møde med behandleren bliver det aftalt, at administratoren skal oprette en tid tirsdag kl. 10 for behandleren de næste to måneder frem. Administratoren logger nu ind på systemet og navigerer til dagsoversigten for den førstkommende tirsdag. Herefter vælger behandleren tiden kl. 10 og kommer ind på bookingredigeringsbilledet. Administratoren kan nu ved at sætte en gentagelse oprette de ønskede tider for behandleren. Administratoren er nu færdig med opgaven og logger ud Oprettelse af behandler En ny behandler er blevet ansat. Administrator bliver derfor bedt om at oprette denne behandler i systemet, så behandleren kan bookes. Administratoren logger ind i systemet og navigerer til administrationssiden, se figur 8. Bemærk at behandlere her bliver omtalt som lokaler. Figur 8: Administrations side På administrationssiden opretter administratoren en ny behandler og logger derefter ud af systemet. 17

18 4.3.3 Midlertidig fjernelse af behandler En behandler er blevet gravid og skal på barselsorlov. Administratoren skal derfor ændre behandleres aktuelle bookinger og gøre behandleren utilgængelig under orloven. Administratoren logger ind i systemet og finder månedsoversigten (figur 9) for den valgte behandler. Her kan administratoren se, hvilke bookinger behandleren har. For hver booking går administratoren ind og sætter en ny behandler for bookingen. Hvis det ikke er muligt, at tildele en ny behandler slettes bookingen. Figur 9: Behandler månedsoversigt Herefter opretter administratoren en booking på den behandler, der er på orlov dækkende hele orlovsperioden for at sikre, at ingen kommer til at oprette bookinger på behandleren ved et uheld. Administratoren er nu færdig med opgaven og logger ud Sletning af behandler En behandler siger op. Behandleren skal derfor slettes fra systemet. Administratoren logger ind og omfordeler behandleres bookinger som beskrevet i forrige afsnit. Herefter navigeres til administrationssiden, hvor administratoren sletter behandleren. 18

19 Administratoren er færdig og logger ud. 19

20 5 Usecases I det følgende afsnit beskrives hvilke usecases som brugscenarierne kan opsplittes i. 5.1 En bruger logger ind 1. Brugeren logger ind. 5.2 En bruger logger ud 1. Brugeren logger ud. 5.3 Klient booker ledig tid hos sin behandler 1. Ser ledige tider. 2. Booker en af de ledige tider hos sin behandler. 5.4 Klient ønsker at se tider som hun har booket tidligere 1. Ser bookede tider. 5.5 Behandler ser bookinger i sin kalender 1. Ser sine bookinger. 2. Planlægger sin arbejdsdag ud fra bookinger. 5.6 Behandler skal oprette klient 1. Får klientens oplysninger. 2. Opretter klient. 5.7 Behandler booker en tid for en klient 1. Ser ledige tider hos klientens behandler. 2. Booker en ledig tid. 5.8 Behandler aflyser en booket tid 1. Finder den bookede tid. 2. Gør denne ledig igen. 20

21 5.9 Behandler sletter bookede tider i kalender 1. Ser sin kalender. 2. Sletter bookede tider Behandler opretter tider i kalender der er ledige for bookning 1. Ser sin kalender. 2. Opretter tider der er ledige for bookning Administrator skal oprette en serie af ledige bookings hos en behandler 1. Ser kalenderen for behandleren. 2. Opretter en række ledige bookings hos behandleren En ny behandler skal oprettes i systemet 1. Indhenter stamoplysninger om brugeren 2. Opretter ny bruger. 3. Specificerer brugerens rolle som værende behandler En behandler skal ikke kunne bookes i en periode 1. Flytter tider der kan flyttes til anden behandler. 2. Sletter tider der ikke kan flyttes. 3. Opretter tid for hele perioden hvor behandler ikke er tilgængelig. 4. Reserverer denne tid, så den ikke kan bookes til anden side En behandler skal slettes fra systemet 1. Ser behandlers kalender. 2. Flytter tider der kan flyttes til anden behandler. 3. Sletter tider der ikke kan flyttes. 4. Sletter behandler. 21

22 6 Komponentbeskrivelser På baggrund af kravene til systemet og den valgte arkitektur, har vi opdelt funktionaliteten i systemet på et antal komponenter. Det drejer sig om en forretningslogikkomponent, en sikkerhedskomponent, en adgangskontrolkomponent, en kalenderkomponent og en lagerkomponent. Det er disse komponenter, der udgør grundstrukturen i systemet og de vil blive gennemgået i det følgende. Et diagram over komponenterne kan ses på figur 10. Derudover er der udarbejdet et primitivt klasediagram som kan ses på figur 11. Diagrammerne er udarbejdet på basis af [2, kapitel 14]. Brugergrænsefladelagets komponenter er ikke beskrevet og ligeledes er datalagets komponenter heller ikke beskrevet. 6.1 Forretningslogik Denne komponents opgave er at håndhæve de rettigheder en bruger har, givet af den rolle brugeren er blevet tildelt. Det vil sige, at givet en kommando fra brugergrænsefladelaget er det forretningslogikkens opgave at finde ud af, hvorvidt kommandoen kan og må gennemføres eller ej. Til dette benyttes eksterne mekanismer, som f.eks kontrol af, at brugeren har de nødvendige rettigheder til at udføre kommandoen. Ligeledes er der i forretningslogikken indeholdt nogen forretningsregler, f.eks. at en booking ikke må foretages efter kl. 20 dagen før den træder i kraft. Det er ikke forretningslogikkens opgave, at rent faktisk udføre kommandoerne, dem sender den videre til den relevante instans, f.eks. sikkerhedskomponenten eller kalenderkomponenten. 6.2 Adgangskontrol Adgangskontrolkomponenten har til ansvar, at holde styr på hvilke klienter, der har adgang til hvilke ressourcer. Navngivningen er her lidt forvirrende, da adgangskontrolkomponenten ikke håndterer egentlig adgangskontrol i større stil (det gør forretningslogikken). 6.3 Sikkerhed Denne komponent håndterer brugere og deres tilknyttede akkreditiver (password og loginticket). Brugere kan oprettes, slettes. Deres akkreditiver kan ændres via. operationen updateuser(...). Denne komponent gemmer oplysninger om brugere og deres akkreditiver ved at bruge en komponent der implementerer istorage interfacet. Brugernes oplysninger gemmes i en userlist. 22

23 Figur 10: Komponent diagram 23

24 Figur 11: Klasse diagram 24

25 6.4 Kalender Denne komponent arbejder med ressource og booking objekter. Hver ressource kan tildeles lige så mange bookings man måtte ønske sig, sålænge der ikke er overlap i tidsrummet for de bookings, der knyttes til ressourcen. En ressource er f.eks en behandler og en booking er et tidsinterval samt den klient, der har foretaget bookingen. Når bookingen knyttes til en ressource, er denne ressource optaget i det givne tidsinterval af klienten. Kalenderkomponenten er afhængig af en komponent, der implementerer istorage interfacet for at gemme de oprettede ressourcer og bookinger. Persistens for Kalenderkomponenten opnås ved at gemme ressourcer og bookinger i ressourcelister og bookinglister. 6.5 Lager Arbejder på lister af elementer. Man kan oprette og fjerne lister. Desuden kan man hente eksisterende lister fra Storage og opdatere disse lister. På et liste objekt kan der oprettes og fjernes elementer. Disse elementer kan desuden opdateres. Man kan gøre brug af lagerkomponenten ved at oprette en liste i lageret. Denne liste hentes, der oprettes et antal elementer i listen, hvorefter den modificerede liste skrives tilbage til lagerkomponenten ved at kalde updatelist(list) operationen på listen. Lister skal oprettes i lageret før disse kan hentes, eller opdateres. 6.6 Generelle overvejelser Designet er lavet med henblik på, at det skal være nemt at udskifte de enkelte komponenter. F.eks. kan man forestille sig at udskifte det aktuelle security subsystem med Kerberos. 25

26 7 Flow beskrivelse I det følgende afsnit beskrives det flow igennem applikationen som en systeminteraktion medfører. Af hensyn til rapportens størrelse beskrives kun 2 usecases. De tilhørende diagrammer er udarbejdet på basis af [2, kapitel 14] og [1]. 7.1 En bruger logger ind Det første eksempel beskriver handlingsforløbet når en bruger logger ind, baseret på usecasen beskrevet i afsnit 5.1. Brugergrænsefladen kalder ilogic::login() og får, hvis det går godt, en loginticket tilbage. Denne loginticket skal bruges i alle fremtidige kald. ilogic::login() realiseres af Logic komponenten, hvor Login() metoden ligger i interfacet isecurity som igen realiseres af Security komponenten. Security komponenten skal ved et kald til Login() tjekke at brugeren eksisterer og at kodeordet er korrekt. Hvis dette går godt opdateres brugerens ticket og en gyldig loginticket returneres. 7.2 En klient booker ledig tid hos sin behandler Dette flow-eksempel baserer sig på 5.3. Forud for, at klienten booker en ledig tid, har hun logget ind og har dermed fået udleveret en loginticket (jvf. forrige flowdiagram). Brugeren ønsker at foretage en booking. Det første der skal gøres i denne sammenhæng er at hente en liste af ressourcer, så man kan bestemme, hvilke ressourcer, der kan bookes. Forløbet er vist på figur 13 og beskrevet herunder. For at hente en ressourceliste skal operationen GetResourceList() kaldes på Logic komponenten. Kaldet videresendes til BusinessLogic komponenten, der på baggrund af den medsendte loginticket returnerer en liste over ressourcer brugeren kan tilgå. Listen genereres ved at BusinessLogic kalder GetResourceList() på Calendar og ad den vej får en liste over alle ressourcer. For hver ressource i listen checkes nu, at brugeren har adgang til ressourcen. Dette check gennemføres ved at kalde AccessControl::ResourceAcces(). Endelig kan den filtrerede liste returneres fra Logic subsystemet ud til brugergrænsefladen. For hver ressource brugergrænsefladen får stillet til rådighed ønskes en liste over ledige bookinger. Denne liste hentes med Logic komponentens GetBookingList() operation som vist på figur 14. Kaldet håndteres af BusinessLogic komponenten, der checker at brugeren har adgang til ressourcen. Herefter kalder BusinessLogic Calendar komponenten med det interval man ønsker at se ledige bookinger for. 26

27 Figur 12: Login flow Figur 13: Booking flow del 1 27

28 Figur 14: Booking flow del 2 Calendar komponenten sørger for kun at vise bookinger i det rigtige interval. BusinessLogic sørger herefter for at kun ledige bookinger returneres til brugergrænsefladen. Endelig ønsker brugeren at booke en given tid. Dette gøres ved at kalde Logic::UpdateBooking(). Kaldet håndteres igen af BusinessLogic, der checker at brugeren har ret til at booke den pågældende ressource. Herefter opdaterer BusinessLogic status for bookingen i Calendar. Forløbet er vist på figur

29 Figur 15: Booking flow del 3 29

30 8 OCL I det følgende afsnit beskrives udvalgte constraints for systemets komponenter. Constraints beskrives ved hjælp af OCL[3, afsnit 6]. 8.1 Security Brugernavn og / eller password må ikke være tomme ved kald til Login(...) operationen. Kaldet skal sætte en brugers loginticket og returnere denne. context isecurity::login(u: user): LoginTicket pre parameterok: u.username.sizeof() > 0, u.password.sizeof() > 0 post resultok: u.ticket <> Null AND LoginTicket <> Null Ved kald til GetUser(...) må loginticket ikke være tom og brugeren skal være logget ind. Kaldet skal returnere et User objekt. context isecurity::getuser(loginticket): User pre parameterok: LoginTicket > 0 pre UserLoggedIn: isecurity::userlist.user->exists(u: User u.ticket = loginticket) post User <> Null Ved kald til CreateUser(...) må der ikke forekomme brugere med samme navn, som navnet på den bruger man prøver at oprette og efter kaldet vil der være en bruger mere oprettet i systemet. context isecurity::createuser(u: User): Status pre checkusername: forall(u2: User u2.name <> u.name) post MoreThanOne: isecurity::userlist.numberofusers = isecurity::userlist.numberofusers Calendar Der må ikke være to bookings hvis tidsinterval overlapper: context icalender inv let nointersection(i1: interval, i2: interval) : Boolean = i1.begin < i2.begin AND i1.end > i2.begin AND i1.begin < i2.end AND i1.end > i2.end in forall(b,c: icalendar.booking nointersection(b.interval, c.interval) ) 30

31 Der skal være mindst en booking oprettet før en klient kan foretage en booking. En booking skal have status = ledig før en klient kan sætte sig på denne. context icalender::updatebooking(b: booking): Status pre bookingmustexist: b.exists() pre bookingmustbeavailable: b.status = available Start og slutintervallet for en booking, er en dato-tidsangivelse, og start og slutintervallet for en booking skal afrundes til nærmeste hele kvarter. context ibusinesslogic inv forall(b: Bookings (b.interval.begin mod 15 = 0) AND (b.interval.end mod 15 = 0)) 8.3 Storage Før operationerne getlist(...) og updatelist(...) kaldes skal der være oprettet nogen lister i komponenten der implementerer istorage. context istorage::getlist(n: name): UserList pre listexists: n.exists context istorage::updatelist(l: List): Status pre liststillexists: l.exists 8.4 AccessControl En ressource skal forefindes i den komponent, der implementerer iaccesscontrol interfacet, før der kan oprettes adgangsrettigheder på denne. context iaccesscontrol::addac(a: AccessControl) pre resourceexists: iaccesscontrol::resourcelist.resource->exist(r: Resource a.resource = r) 8.5 BusinessLogic Komponenten skal sikre at en bruger skal være logget på, og dermed også har fået tildelt en loginticket, før brugeren kan udføre nogen operationer på komponenten overhovedet. context ibusinesslogic::allop(loginticket,...) pre userloggedin: istorage::userlist.user -> exist(u: User u.loginticket = loginticket) 31

32 Bemærk at allop er et wildcard for alle de operationer som ibusinesslogic interfacet implementerer. Følgende business regler vælger vi at afspejle som OCL. Det skal ikke være muligt at foretage en booking til den efterfølgende dag, hvis klokken har passeret 20:00. context ibusinesslogic::updatebooking(booking,loginticket) pre timecheck: if booking.date == date()+1 then currenttime() < "20:00" endif Der skal altid være minimum 15 minutters forberedelsestid mellem hver booking. context istorage::bookinglist.booking inv preparationtime: forall(b1,b2: booking b1.interval.end - b2.interval.begin < 15 minutes OR b1.status = "preparation time") Bookings på en behandler, for en bestemt bruger, skal kun foretages hvis brugeren er tilknyttet denne behandler. context ibusinesslogic::updatebooking(booking, loginticket): Status pre associatedshrink: istorage::resourcelist.resource -> exist(r: Resource r.name = booking.resource) En bruger må ikke have mere end 3 bookede tider fra dags dato og frem i tiden. context istorage::bookinglist inv max3bookings: forall(b: Booking self.booking->count(select(status="booked" AND name=b.name)) <= 3 ) 8.6 Betydningen af OCL constraints De vigtigste constraints er dem, der indrager mere end det komponentinterface, de er oprettet for. Et eksempel på dette er følgende constraint: Ved kald til GetUser(...) må loginticket ikke være tom og brugeren skal være logget ind. Kaldet skal returnere et User objekt. 32

33 context isecurity::getuser(loginticket): User pre parameterok: LoginTicket > 0 pre UserLoggedIn: isecurity::userlist.user->exists(u: User u.ticket = loginticket) post User <> Null Denne constraint laver en binding mellem den komponent, der implementerer ibusinesslogic og de komponenter, der implementerer hhv. isecurity og istorage. De constraints der spænder over flere interfaces, beskriver vigtige afhængigheder mellem komponenternes interfaces, der ikke bliver fanget af den traditionelle interfacebeskrivelse. Constraints synliggør hvilke begrænsninger, der er i brugen af komponenternes interfaces. De synliggør også hvilke antagelser, der er gjort om de komponenter, man gør brug af, når man sammensætter komponenter til et samlet system. 33

34 9 Afrunding På de foregående sider har vi beskrevet et komponentbaseret design af en løsning på det problem, der blev præsenteret i introduktionen. Det er vores indtryk, at designet lever op til den komponentbaserede præmis, at komponenter er løst koblede og dermed nemme at udskifte. Det vil f.eks. være nemt sætte nye frontends på systemet eller at ændre forretningsreglerne, da håndhævelsen er centraliseret i en enkelt komponent. Ydermere vil det være nemt, at udvide systemet med eksempelvis et regnskabssystem, hvor faktureringsregler håndhæves af forretningslogikken. Det foreslåede design håndterer sikkerhed på fornuftig vis via loginticket, men det forudsættes naturligvis, at sikkerheden også fungerer på andre niveauer. F.eks. at der benyttes krypterede forbindelser. 34

35 Litteratur [1] Fowler, Scott: UML Distilled, Addison Wesley, 1997 [2] Heinemann, Councill: Component-Based Software Engineering, Addison Wesley, 2001 [3] Object Management Group: Unified Modeling Language Specification version 1.5, Object Management Group,