University College Nordjylland BachelorProjekt

Transkript

1 University College Nordjylland BachelorProjekt Forfatter: Aso Zada UCN, PBA Software udvikling 3. semester BachelorProjekt: 14. november 2013 til 15. januar 2014 Praktiksted: Region Nordjylland - Koncern IT Titel : Massage system Dato: 15. januar 2014 Side 1 af 77

2 University College Nordjylland Teknologi og Business PBA Softwareudvikling 3. semester Hold: Titel: Forfatter: psue0912 Massage system Aso Zada Resumé/synopsis Region Nordjylland har ønsket at fornye og forbedre et tids booking system, til bestilling af massage, kaldt massage systemet. Det nuværende system er blevet udviklet i VB.NET. Opgaven er derfor, at omsætte det eksisterende Massage system som er kodet i VB.NET til en C#.NET systemkode. Dette før til flere problemstillinger: Vejleder: Finn Nordbjerg Afleveringsdato: Underskrift: Hvordan forberedes et eksisterende system i platformen VB.NET til en C#.NET platform? Hvordan bliver systemet brugergrænseflad præsenteret bedst og mest simpel til brugerne? Hvordan bliver dataforbindelsen håndteret? Konklusion må være, at den ny massage system kunne forberders ved at være mere dynamisk. Brugergrænsefladet vil bedste præsenteres til brugerne ved at gør brug af HTML og CSS, da dette vil være mest enkel og overskuligt for disse type bruger. Efter flere overvejelser blev der besluttet, at Entity Framework vil være den teknologi der vil andvendes til håndtering af data forbindelsen. Side 2 af 77

3 1 Forord Indledning Beskrivelse af virksomheden Nuværende eksisterende massage system Integration til Regionens bruger Den ny massage system Problemformulering Metode Centrale elementer fra fagene på PBA Databases for Developers Test Nyt viden og emne for praktik Valg af udviklingsmetode Personnel Dynamism Culture Size Criticallity Konklusion på moddelen Valg af agile udviklingsmetode Mockups Brug af udviklingsmetoden Scrum Product backlog Sprint backlog Sprint Daily Scrum Meeting Release Sprint Sprint Review Sprint backlog Release sprint Sprint Review Arkitektur Præsentations lag Logik lag Side 3 af 77

4 3.3 Data lag Baggrund for valg af 3 lags arkitekturen Fordel ved 3 lags arkitekturen Vedligeholdelse Genbrugelighed Fleksibilitet Database design Entity-relationship model Beskrivelse af Entity-relationship model Mapping af Entity-relationship model til relations tabeller: Beskrivelse af Mapping Normalisering af tabellerne Data definition language Implementering af præsentations lag Kommunikationen fra applikationen til databasen Entity Framework Opsætning af Entity Framework Brug af Entity Framework Implementering af applikationslageret Test Hvorfor test? Test med V-modellen Agile testing Test Driven Development (TDD) Traditionelt vs. Agile testing Test af projektet Acceptance testing Fremtidens webdesign er med Html5 & CSS Konklusion Bilag Udviklingsmetoden Scrum Scrum Team Product backlog Sprint planning Side 4 af 77

5 9.5 Sprint backlog Sprint Daily Scrum Meeting Burndown Chart Release sprint Sprint Review Test bilag Ganttproject tidsplan Side 5 af 77

6 1 Forord Denne Bachelorprojekt er skrevet på baggrund af et samarbejde med min praktikplads hos Region Nordjylland - Koncern IT, som har været i perioden 11. november 2013 til 15. januar Hensigten med rapporten er, at beskrive de metoder, arbejdsgang og teknologier der er blevet anvendt, samt at give et klart billede af hvad der kræves og hvordan man kan udvikle et tids booking system i C#.NET. Der rettes en varm tak til Region Nordjylland - Koncern IT for, at have givet mig muligheden for samarbejdet og mindst ikke udviklingsafdelingen som har været til hjælp hele vejen igennem. Ligeledes vil jeg takke min vejleder Finn Nordbjerg for, at have vejledet og aktivt bidraget med input igennem hele projektet. Side 6 af 77

7 1.1 Indledning På nuværende tidspunkt gør Region Nordjylland i flere afdelinger brug af et tids booking system, til bestilling af massage, kaldt massage systemet. Det nuværende system er blevet udviklet i VB.NET og fungere i bund og grund, men med tiden har man fundet ud af, at der er brug for en fornyelse og forbedring af systemet. Opgaven er derfor, at omsætte det eksisterende Massage system som er kodet i VB.NET til en C#.NET systemkode. Dette indebære, at der skal arbejdes på alle 3 lag i systemudvikling Database oprettelse, GUI og nyt systemkode. Påbegyndelse af opgaven startede d. 2. september i samarbejde med min praktikperiode, men da opgaven var mere tidskrævende end den tid jeg havde til rådighed i praktikperioden, blev der indgået et nyt samarbejde i forbindelse med min bachelorprojekt for, at forhåbentlig fuldfører projektet. Under praktikperiodens forløb var der en masse nyt der skulle undersøges for mit vedkommende, hvilket resulterede i, at jeg ikke kom så langt med projektet. Jeg fik dog skrevt en kravspicifiktion på baggrund af de 6 eksisterende massage systemer, dannet et udkast til Mockups af systemet og et udkast af databasen designet. Bachelorprojektet skal derfor dokumentere, opsamle, og fuldende de ikke fuldførte opgaver. Rapporten vil desuden give et klart billede af hvad jeg har fået ud af opholdet hos Region Nordjylland - Koncern IT. Rapporten vil ydermere synliggøre hvilke værktøjer, centrale elementer fra fagene jeg har gjort brug af, som jeg har tilegnet mig under uddannelsen. Sidst man ikke mindst, vil hovedeformålet med mit bachelorprojekt i forbindelse med udvikling af massage systemet være, at gør brug af ny teknologier som jeg ikke har fået undervisning og kendskab til under uddannelsen. Side 7 af 77

8 1.2 Beskrivelse af virksomheden Region Nordjylland blev dannet den 1. januar 2007 i fobindelse med sammenlægning af de eksisterende amter. Region Nordjyllands hovedopgaver er sundhedsvæsnet i det nordjyske, herunder sygehusvæsnet og den behandlende psykiatri. Regionen har desuden et overordnet ansvar for udvikling og det sociale område. Regionen er delt i flere afdelinger som det ses på nedenstående figur og har omkring ansatte, den afdeling jeg var i praktik hos var Koncern IT. IT afdelingen består på nuværende tidspunkt af ca. 150 ansatte, de har til opgave at håndtere opgaver, lige fra store kliniske systemer til små egenudviklede systemer. 1.3 Nuværende eksisterende massage system Det nuværende eksisterende system er et tids booking system til bestilling af massage, kaldt massage systemet. Det nuværende system er blevet udviklet i VB.NET for mange år siden og fungere i bund og grund, men med tiden har man fundet ud af, at der er brug for en fornyelse og forbedring af systemet, da det nuværende system ikke er særlig dynamisk. Det nuværende massage system har dog været med til at definere kravene og give et bedre overblik over de data som der skal håndteres. Dog har data håndtering ikke været særlig Side 8 af 77

9 hensigtsmæssig(dårlig database design er ikke normaliseret) hvilket er en af de ny forbedringer der skal tages hensyn til under udvikling af den ny massage system. 1.4 Integration til Regionens bruger Data om regionens bruger bliver trukket fra regionens egenudviklet løsning som har fungeret i produktion de sidste 4 år. Bruger administrationen bliver omtalt som OneSystem i rapporten. Onesystem er efterhånden et kompleks system som jeg ikke vil hverken beskrive eller komme ind på under rapporten. Men jeg har dog fået udleveret en standard som via en webservice kalder Onesystem og jeg kan få integrationen af brugerlogin til massa ge systemet. 1.5 Den ny massage system Som beskrevet tidligere skal massage systemet fungere som et tids booking system til bestilling af massage, kaldt massage systemet for regionens bruger. Den ny massage system skal være en ny version af de 6 eksisterende massage system som bruges til, at bestille tid til massage hos de forskellige afdelinger. Kravene til det ny massage system overordnet er, fornyelse og forbedring af systemet da det nuværende system ikke er særlig dynamisk og at den ny massage system ska l indeholde de vigtigste funktioner fra alle de 6 forskellige massage systemer, der er kørende på nuværende tidspunkt. Side 9 af 77

10 1.6 Problemformulering Hvordan forberedes et eksisterende system i platformen VB.NET til en C#.NET platform? Hvordan bliver systemet grænseflad præsenteret bedst og mest simpel til brugerne? Hvordan bliver dataforbindelsen håndteret? Side 10 af 77

11 1.7 Metode For at fuldende opgaven og have styre på tidsforløbet har jeg valgt, at gør brug af udviklingsmetoden, Scrum i et GanttProject. Scrum er en agile udviklingsmetode som bliver anvendt til udviklingsprojekter med henblik på ændrende krav, hvilket kan opstå løbende under udvikling af massage systemet, da det er 6 forskellige systemer der skal forenes ned til et kørende system. Der findes en dybtgående beskrivelse af udviklingsmetoden, Scrum under bilag i rapporten. 1.8 Centrale elementer fra fagene på PBA Udvikling af den ny massage system vil indebære, at jeg skal gør brug af nogle af de centrale elementer fra fagene, Databases for Developers og Test Databases for Developers For at fuldføre den første del af opgaven som var, at oprette databasen, blev der gjort meget brug af det vi lært under faget Databases for Developers. Der kan nævnes: Relational Model Design of relational schemas Normalisation of tables SQL Disse punkter er beskrevet under del Test For at se om systemet og den funktioner agger som de skal, vil der løbende blive lavet følgende tests: Acceptance test TDD Disse punkter er beskrevet under afsnitet om Test(6). Side 11 af 77

12 1.9 Nyt viden og emne for praktik Under udvikling af massage systemet vil der undervejs blive gjort en masse undersøgelse og nyt viden vil blive opdaget. Der vil derfor være et dybgående beskrivelse om disse punkter: HTML5 CSS Entity framework Side 12 af 77

13 2 Valg af udviklingsmetode For at sikre kvaliteten og at tidsplanen overholdes i et udviklings projekt, er det essentielt, at man benytter, den rette uviklingsmetode. Der findes 2 forskellige måder, at arbejde på under udvikling af et projekt, nemlig agilt eller plandrevent. Til at fastslå dette, kan man anvende Barry Boehms model, som kigger på 5 faktorer der er essentielt, for valget af hvilken fremgangsmetode, der egner sig bedst til det pågældende projekt: Ved at bedømme projektet i forhold til de 5 faktorer der er i Barry Boehms model, som ses ovenstående, kan man vurdere om projektet, skal gør brug af en agilt eller plandrevent fremgangsmetode. De 5 faktorer der er afgørende i moddelen er: Personnel: Bedømmelse af medlemmernes erfaringer og viden om det projekt der skal udvikles. Dynamism: Her kigger man på, om kravene til projektet er fastlagt på forhånd eller hvor meget de ændres undervejs på en måned. Culture: Hvilken arbejdsmetode passer bedst til er projektets medlemmer, under kaos eller orden. Size: Her kigger man på størrelsen af antal medlemmer til udvikling af projektet. Side 13 af 77

14 Criticallity: Hvor kritisk er systemet? Kan fejl i systemet forsage større problemer og i værste tilfælde koste menneske liv? 2.1 Personnel For udvikling af dette projekt skal der arbejdes med alle 3 lag, nemlig systemkode, GUI og database. Dette betyder, at man skal have viden og erfaring om alle 3 lag, jeg har igennem udannelsen erhvervet mig den grundlæggende teori om alle 3 lager og igennem projektarbejde, opnået en masse erfaring om database og lidt om systemkode. Da dette er et web projekt er der en masse ny ting der skal undersøges, især for udvikling af GUI en, som er noget helt nyt for mig. Desuden har jeg valgt, at gør brug af ny teknologier, som jeg ikke har brugt før, for at opnå nyt viden og gør projektet mere spændende, som resulterer i, formindske mine kompetencer i faktoren Personnel. Kravspecifikation har jeg dannet ved, at se på de eksisterende systemer, som er kodet i VB. Dette formindsker også mine kompetencer i faktoren Personnel, da jeg ikke har stiftet kendskab til VB før dette projekt. Igennem uddannelsen har jeg arbejdet en del med de forskellige udviklingsmetoder, samt deres værktøjer, hvilket styrker mine kompetencer til udvikling af dette projekt, da jeg ikke ha r behov for, at sætte mig ind i brugen af disse fra bunden af. Desuden har jeg min sparringspartner Anders og ugentlig møde med min vejleder, Finn Nordbjerg som jeg vil bruge til, at spørge til råds undervejs. Dette styrker faktoren i Personnel. På bag grund af de ovenstående udfordringer og problemstillinger har jeg valgt, at placer mig selv på 15/20 på faktoren Personnel. 2.2 Dynamism Da kravspecifikationen er dannet på baggrund af de 6 forskellige eksisterende systemer, forsagede det, at der forekom flere ændringer i kravspecifikationen løbende. Desuden vil der løbende være ønsker om nogle ny features fra massørerne af, da det er mening, at det ny system skal være mere dynamisk. Faktoren Dynamism vil derfor være placeret på 25/30 %, da der tages højde for projektet på længere sigt. Side 14 af 77

15 2.3 Culture Jeg trives bedst med at have friheden til, at selv kunne vælge de værktøjer jeg vil bruge til udvikling af et projekt, med det sagt, kan jeg under udvikling af et projekt stød på nu teknologier, som jeg godt kunne tænke mig at afprøve. Personligt mener jeg at det i bund og grund handler om at lære noget nyt under uddannelsen og ikke nødvendigvis kun, at udvikle et fejlfrit system. Dog ønsker jeg at der er en form for orden under udvikling af et projekt, i form a f tidsplan, møder og deadlines. Derfor placeres faktoren Culture på 65/70 %. 2.4 Size Størrelsen på projektets medlemmer er, 1 da jeg er alene om at udvikle projektet. Dog har jeg min sparringspartner Anders og vejleder Finn Nordbjerg, som jeg vil bruge til at spørge til råds undervejs. Size faktoren angives til Criticallity Dette projekt er på ingen måder kritisk og de fejl der kan forekomme, har ikke større betydning, da dette kun er et bookingsystem og ikke forsager tab af menneskeliv. Faktoren Criticallity vil derfor være placeret på den mindste grad på modellen. Med de fem faktor beskrevet og placeret på dimensionerne kan jeg nu indsætte linjerne på hver af de 5 akser på modellen. På den måde kan der tages stilling til om, hvorvidt projektet ligg er i det agile eller i det disciplinerede område: Side 15 af 77

16 2.6 Konklusion på moddelen Som det ses tydeligt på ovenstående model er projektet meget tæt på midten, når man ser på Size og Criticallity, hvorimod Personnel og Culture afviger lidt fra midten. Disse afvigelser kan der tages højde for ved at behandle dem som risikofaktor. Personnel kan behandles bedst vis ved, at jeg kan sørge vejledning og hente råd hos min sparringspartner i virksomheden og ellers ugentlig dialog med min vejleder, Finn Nordbjerg, som kan kommenter og vejlede om de enkelte modeller og løsninger, før igangsættelse af selv ved udvikling af produktet, hvor der på bedst vis kan tages højde for de oversete problemstillinger eller udfordringer. Cultur kan bedste behandles ved, at jeg ikke har en alt for struktureret tidsplan, da der skal være plads til de ændringer der vil forekomme i kravspecifikationen og mindst ikke at have forudbestemt alle værktøjer til udvikling af projektet på forhånd. Der kan ud fra Barry Boehms model og ovenstående afsnit udlades, at det vil være mest optimalt for projektet, at anvende en agil fremgangsmetode. 2.7 Valg af agile udviklingsmetode I forrige afsnit blev der ved hjælp af Barry Boehm's model konkluderet, at det vil være mest oplagt at anvende en agil fremgangsmåde. Dette afsnit vil der være en beskrivelse af den valgte udviklingsmetode og hvordan jeg vil tilpasse det til mit projekt. Der findes flere forskellige agile udviklingsmetoder såsom, Kanban, Scrum og XP. Scrum og XP er de agile udviklingsmetoder som jeg kender til og har erfaringer med igennem udannelsen. Det vil derfor være oplagt at jeg gør brug af enten Scrum eller XP som udviklingsmetoder, da der er en begrænset tidsperiode til udvikling af projektet og at det er en forholdsvis lang proces, at undersøge og for forståelse for en ny udviklingsmetode. Jeg har valgt at anvende Scrum som udgangspunkt for udviklingsmetode, da jeg har en masse erfaring med det og organisationen Region Nordjylland også gør brug af det. Scrum er en udviklingsmetode der fokuser meget på håndtering af projektets udviklingsproces via de værktøjer der er til rådighed som, product backlog, sprint planning, sprint backlog, daily scrum meeting, burn down chart og sprint review. Ideelle brug af disse værktøjer kan hjælpe et projekt til succes, da man konstant har overblik over de krav der er og de krav der skal nås en for givende tidspunkt via product og sprint backloggen. Via Burn down charten kan man nemt overskue og have overblik over forløbet for den overordnet tidsplan for projektet. Side 16 af 77

17 Scrum afhjælper desuden den risiko faktor i Personnel, som jeg kom frem til i forrige afsnit ved hjælp af Barry Boehm's model. Det gør den ved at man i scrum holder, daily scrum meeting, hvor man fortæller teamets medlemmer om hvor lang man er og de evt. problemer man er stødt på, som de andre medlemmer kan hjælpe med. Dette punkt har jeg dog tilpasset lidt til projektet som er beskrevet i næste afsnit, om brugen af scrum. Desuden passer udviklingsmetoden Scrum bedst til udvikling af dette projekt af flere grund: At man ikke kender alle kravene fra start af projektet. At man forbereder sig på at der kan forekomme ændring af både i krav og teknologi. At man nedbryder opgaver i mindre dele så de kan gøres helt færdige i et Sprint En beskrivelse af de væsentligste punkter i Scrum er til at find under bilag. 2.8 Mockups I dette afsnit vil der være et udkast til massage systemets brugergrænseflade. Dette bliver vist ved hjælp af de Mockups der er blevet dannet på bag grund af kravspecifikationen. Mockups er en visualisering af produktet, som udvikles inden der påbegyndes på udvikling af produktet. Mockups bliver hovedsaligt brugt i begyndelse af softwareudvikling til, at kunne definere alle kravene til systemet med henblik på brugergrænsefladet og hvordan systemet agere. Mockupsene kan desuden anvendes til, at skabe overblik over tids processen, da man hele tiden har overblik over hvor langt man er med udvikling af systemet og hvor meget der skal laves. Eksempel på log ind siden: Log ind siden er en del af standarden som Regionen selv har stået for.men dette er det første en bruger ser når de vil tilgå systemet. For at kunne tilgå systemet skal man være ansat hos Regionen og have fået tildelt en Brugnavn og Adgangskode. Side 17 af 77

18 Eksempel på forsiden: Når en bruger er logget ind i systemet vil de møde forsiden. På forsiden vil der være en velkomst og en beskrivelse af hvordan brugeren kan anvende systemet. Desuden vil der være en menulist til systemet som brugeren kan bruge til at navigere rundt i systemet. Eksempel på opret en bestilling siden: Når en bruger er kliker på opret en bestilling menulisten vil de møde en kalender som de kan vælge en dato på. Dette vil navigere dem videre til de mulige massage tid til den valgte dato. Side 18 af 77

19 Eksempel på opret en bestilling siden med valgte dato: Dette er hvad brugeren vil møde, når de har valgt en dato fra kalenderen. Som det ses er det alle de mulige massage tider der er for den valgte dato. Her kan brugeren vælge den tid de ønsker at bestille. Eksempel på en bestilt massage tid: Nedenstående ses der et eksempel på hvikle skærmbillede brugeren vil møde når de har valgt og bestilt en mulige massage tid. Som det ses er har brugeren valgt at få oversigt over mulige tider for den hvor der derefter blevet bestilt den ønskede tid. Side 19 af 77

20 Eksempel på en bestilt massage tid: Nedenstående ses der et eksempel på hvikle skærmbillede brugeren vil møde når de har valgt at klikke på mine bestillinger på menulisten. Her vil der være en oversigt over alle de bestilte tider med muligheden for afmelding af dem. Eksempel på kalender opsætning: Nedenstående ses der et eksempel på hvikle skærmbillede massøren vil møde når de har valgt at klikke på kalenderopsætning på menulisten. Her vil der være en oversigt over alle de opsætninger der skal til for at danne de mulige massage tider som brugerne kan bestille. Side 20 af 77

21 Side 21 af 77

22 2.9 Brug af udviklingsmetoden Scrum Da Scrum er som tidligere beskrevet er en udviklingsmetode der er hensigtsmæssige og bruge i en Scrum Team og jeg er alene under udvikling af projektet, vil der være tilpasning af Scrum for, at kunne gør brug af det, til udvikling af massage systemet. Der vil derfor være et eksempel på hvordan jeg gør brug af Scrum og hvordan er det blevet tilpasset til mit projekt. For at have overblik over tidsplanen har jeg valgt at bruge Ganttproject i forbindelse af de 2 sprints fra Scrum, som er beskrevet i de følgende afsnit. Tidspanen der er til at finde under bilag Product backlog Product backlogen skal indeholder alle de krav der er stillet til massage systemet fra kunden. Der vil derfor være en liste over alle de krav der er til systemet. Product backlogen er et svar på hvad kunden ønsker af systemet og som Product Owneren har til ansvar for at Scrum Teamet udvikler det der ønskes af systemet. Under udvikling af projektet har jeg ageret både som Scrum Teamet, da jeg har været alene om at udvikle systemet og Anders Barsk som er min sparringspartner fra IT-afdeling ageret som Product Owner. Der skal være en velkomst side når brugeren er logget ind. Der skal være en menu list så brugeren nemt kan navigere rundt. Der skal være en kalender med en liste over mulig tider til massage bestilling. En bruger skal have mulighed for, at bestil en tid via kalenderen. En bruger skal kunne se ens bestillinger og kunne afmeld dem. Massøren skal kunne indtaste de tider der er mulighed for massage via en kalenderopsætning. Massøren skal kunne vælge aftalelængden for den ønskede dag via kalenderopsætning(30,45,60 eller 90 min). Massøren skal kunne vælge antal af mulig pladser til bestilling af massage for den ønskede dag. Massøren skal kunne have mulighed for at skrive en tekst for den givende dag via kalenderopsætning til brugerne. Massøren skal kunne have muligheden for, at fravælge bestillinger for en enkelt dag via kalenderen. Massøren skal have muligheden for, at oprette pauser i løbet af dagen via kalenderen. Side 22 af 77

23 Der skal sendes en til bestilleren som bekræftelse på bestillingen. En bruger skal kun have muligheden for at bestille 2 massage tider af gangen. Kalenderen skal kunne via en farve beskrive aktiviteten af bestilte tider, så det nemt for brugeren at overskue. Systemet skal være meget simpelt at bruge Sprint backlog Sprint backlogen indeholder alle de task som skal med i næste sprint. Sprint backlogens indhold er blevet dannet på bag grund af sprint planning meeting som består af Scrum Temaet, i mit tilfælde mig selv. Under mødet bliver der udvalgt nogle af de task fra product backlogen af som skal med i 1. Sprint, som er estimeret til 4 uger. De task der blev udvalgt til 1. Sprint fra Product backlogen er: Der skal være en velkomst side når brugeren er logget ind. Der skal være en menu list så brugeren nemt kan navigere rundt. Massøren skal kunne indtaste de tider der er mulighed for massage via en kalenderopsætning. En bruger skal have mulighed for, at bestil en tid via kalenderen. Massøren skal kunne vælge aftalelængden for den ønskede dag via kalenderopsætning(30,45,60 eller 90 min). Massøren skal kunne vælge antal af mulig pladser til bestilling af massage for den ønskede dag. Massøren skal kunne have mulighed for at skrive en tekst for den givende dag via kalenderopsætning til brugerne Sprint Som der ses fra overstående afsnit og den vedlagte tidsplan(bilag), kommer 1. sprint til at vare 4 uger. Der vil derfor efter 1. sprint være en præsentation af sprintet som jeg skal præsentere for Product Owneren Anders Barsk, min sparringspartner fra Region Nordjylland. Side 23 af 77

24 2.13 Daily Scrum Meeting Daily Scrum er ikke noget jeg har gjort brug af, da Daily Scrum er et møde der dagligt bliver holdt for, at give de andre medlemmer af teamet indsigt i, hvad hvert medlem fortager sig. Jeg har dog brugt Daily Scrum på ugeplan hvor jeg hver uge har besvaret følgende 3 spørgsmål som er blevet tilpasset fra den oprindelige version: Hvad jeg fik lavet i løbet af ugen? Hvad jeg vil lave næste uge? Hvilke hindringer der er/har været? Disse 3 spørgsmål har givet en opdatering til Anders Barsk og min vejleder Finn Nordbjerg som har givet dem en indsigt i hvordan det går og hjulpet mig igennem de hindringer der har været. Grunden til at jeg har gjort brug af Daily Scrum Meeting på ugeplan er, at Scrum Teamet består kun af mig selv, men hvorimod jeg ugentlig har haft et møde med min vejleder hvor mødet har fungeret som et Daily Scrum Meeting dog på uge basis Release Sprint Efter 1. Sprint havde jeg et møde Product Owneren Anders Barsk, hvor jeg fik præsenterr de tasks som jeg havde nået igennem 1. Sprint. Anders syns at projektet var på rette vej Sprint Review Overordnet kan der konkluders at der har været en del forsinkelse under dette Sprint, da jeg har brugt meget tid på at lære de ny teknologier at kende og dermed ikke nået alt det der var planlagt. De task som ikke blev gennemført under dette Sprint blev overført til næste sprint Sprint backlog Der skal være en kalender med en liste over mulig tider til massage bes tilling. En bruger skal kunne se ens bestillinger og kunne afmeld dem. Der skal sendes en til bestilleren som bekræftelse på bestillingen. En bruger skal kun have muligheden for at bestille 2 massage tider af gangen. Kalenderen skal kunne via en farve beskrive aktiviteten af bestilte tider, så det nemt for brugeren at overskue. Systemet skal være meget simpelt at bruge. Side 24 af 77

25 Massøren skal kunne have muligheden for, at fravælge bestillinger for en enkelt dag via kalenderen. Massøren skal have muligheden for, at oprette pauser i løbet af dagen via kalenderen Release sprint Efter 2. Sprint havde jeg et møde med Anders Barsk hvor jeg fik præsenterr de tasks som jeg havde nået at implementeret. Jeg fik desværre ikke implementeret alle task pga tidsmangel. Anders syns at projektet var på rette vej, men han kunne godt se at der var brug for mere tid for at afslutte alle task Sprint Review Overordnet kan der konkluders at jeg har estimeret tidsforbruget på hver task alt for lidt, men det skyldes hovedsageligt at jeg har brugt meget tid på at lære de ny teknologier at kende. Men havde der været mere tid til rådighede og dermed et 3. Sprint vil systemet blive færdig udviklet. Side 25 af 77

26 3 Arkitektur Dette afsnit vil indeholde en beskrivelse af hvilke overvejelser der er blevet gjort om valget af arkitekturen til udvikling af massage systemet. Desuden vil der være en kort beskrivelse af den valgte arkitekturen og grunden til udfaldet. Til udviklingen af massage system har jeg benytter 3 lag arkitekturen. 3 lags arkitekturen er en måde at opbygge ens systems arkitektur på, med formålet, at der er mulighed for vedligeholdelse, genbrugelighed og fleksibilitet. 3 lags arkitekturen består af: Præsentations lag Logik lag Data lag TempCore.Service som kommuniker med OneSystem. Præsentations lag Web Projekt CSS HTML5 Logik lag Applikationslageret Data Acces Tier (Entity Framework) Data lag MS SQL Server MassageBestilling Side 26 af 77

27 3.1 Præsentations lag Præsentationslageret er det øverste lag som kan ses på ovenstående figur. Præsentationslageret indeholder brugergrænsefladet som har til funktion, at vise indholdet til brugeren via browseren. Det er via dette lag, at brugernes input og interaktioner bliver håndteret. Som regel er det brugeren der skaber kommunikationen ved, at sende et forespørgsel på eksempel vis en massage tid, på en givende dag, via browseren, hvor systemet bearbejder forespørgslen i logik lageret og laver et forespørgsels i data lageret, hvor datalageret sender et svar tilbage som så bliver vist til brugerne via præsentationslageret. Som overstående beskriver, forgår processen for forespørgslen meget uafhængigt af de forskellige lag, hvilket er formålet med 3 lags arkitekturen. 3.2 Logik lag Logik lageret også kaldt applikationslageret er mellem lageret som kan ses på figur xx, hvor applikationens funktioner er og bliver udført når brugerne indtaster data eller navigere rundt på præsentationslageret. Applikationslageret bearbejder alle de informationer der kommer fra brugerne via præsentationslageret, som bliver sendt videre til datalageret hvor de bliver lageret. 3.3 Data lag Datalageret er det nederste lag som består af den/de server der er tilsluttet til systemet, som lager alle de data der kommer fra brugerne via præsentationslageret som bliver bearbejdet via applikationslageret. 3.4 Baggrund for valg af 3 lags arkitekturen Fordelen ved 3 lags arkitekturen er, at der nemt er mulighed for, at videre udvikle eller lave ændringer i et distribueret system. Grunden til, at massage systemet er blevet udviklet med henblik på 3 lags arkitekturen, er med tanken om at der kan forekomme ændringer til systemet, da systemet skal opfylde ønsker fra flere afdelinger og at der kan være mulighed for, at lave en mobil applikation på et tidspunkt da det sikkert vil blive efterspurgt nu hvor smartphones er blevet en del af vores hverdag. En 3 lags arkitektur kræver ved dannelsen mere kode arbejde og dermed mere tidskrævende end den velkendte 2 lags arkitektur, hvor selv ved præsentations og logik lageret er i et lag og data lageret i et. Dog er der en masse fordel ved 3 lags arkitekturen som vil blive beskrevet i de nedenstående afsnit. Side 27 af 77

28 3.5 Fordel ved 3 lags arkitekturen Vedligeholdelse Vedligeholdelse af et system med 3 lags arkitekturen er meget simpel da hvert lag er uafhængig af hinanden. Et eksempel kunne være, at systemet bliver udleveret til kunden, men man opdager, at systemet ikke lever op til kravspecifikationen. Det kunne være, at præsentationslageret ikke ser ud som ønsket og derfor skal der laves ændringer så systemets præsentationslager svare til kravspecifikationen. Ved hjælp af 3 lags arkitekturen kan man lave de ændringer i præsentationslageret filen og behøver ikke tænk på de andre lag Genbrugelighed Skal systemet videreudvikles eller skal der udvikles et app til smartphone. Besidder 3 lags arkitekturen den fordel at det er muligt, at genbruge noget af systemets kode igen i stedet for at starte forfra Fleksibilitet Ved at separere lageren i 3 del gør det systemet meget fleksibelt over for ændringer. Hvis man antager at organisationen vælger, at udskifte data lageret kan dette nemt gøres og har ikke større påvirkning på hverken præsentationslageret eller logik lageret. Side 28 af 77

29 4 Database design Dette afsnit vil indeholde en beskrivelse af min database design og hvilke overvejelser jeg har gjort mig under design processen. Jeg vil desuden igennem de 4 trin som jeg mener, er essentielt for at kunne designe en god database design 1 : Entity-relationship model Mapping af Entity-relationship model til relations tabeller Normalisering af tabellerne Data definition language 1 Ramez E lmas ri & s hamkant B. Navathe: Fundamentals of database s ystems, SIXTH EDITION, 2011 s Side 29 af 77

30 M M M 1 M 1 1 M PBA-Projekt, Januar 2014, udarbejdet af As o Zada 4.1 Entity-relationship model 2 Description Required Id MaxLength Sorting ParebtId DataExtensi FormId on_id Name Type Authorized User_Id Data LastEditedB y LastEditedD ate DisplayNam e RegionId Id OSId Deleted FirstLogin MinLength DefaultValu e DateExtension 1 1 AuthorizedUser_DataExte nsion 1 1 AuthorizedUser LastLogin Id Description ValidTo ValidForm Password Username Deleted LocalUser AutherUser ID ValidTo Id Deleted 1 FAccess_Id FRole_Id RAccess_Role 1 Id Deleted ValidFrom Organizatio nid Acces Role Name Description Id Deleted GSSlutTidD ag GSStartTid Dag Weekend PeriodeSlut PeriodeStar t Organizatio nid Kalender_Setup_Standar dværdier Deleted Tekst Dag Deleted Id Kalender_Tekst Dato Note Id Ingen_Bestilling Deleted Overskrift Id Afsender Indhold Tilmeldings Frist StartTid SlutTid Deleted Afmeldings Frist Id Mail_Tekster Kalender_Setup_Ugedag e 1 M Kalender_Dage_Tider UgedageSlu ttid Dag M Bestilling 1 Deleted Modtager Id Deleted AfaleLaeng de Deleted Dato Mail_Sendt Dato UgedageSta rttid Deleted Id Kalender_Setup_Ugedag e_parameter AntalPladse r Aktiv SmsBesked Id Note Id Status 2 Ramez E lmas ri & s hamkant B. Navathe: Fundamentals of database s ystems, SIXTH EDITION, 2011 s Side 30 af 77

31 4.2 Beskrivelse af Entity-relationship model Kalender_Setup_Standardværdier entityen: Massøren skal via kalenderopsætning indtaste nogle standardværdier som bruges til, at danne rammerne for den næste periodes massage-tider. Felterne PeriodeStart og PeriodeSlut angiver hvornår perioden starter og slutter. Tabellen(Kalender_Setup_Ugedage) vil indeholde de mulige tider for en givende dag via de standardværdier som massøren har indtastet, derfor skal massøren som udgangspunkt vide hvornår den første og sidste mulig bestillings dato der er for massage, for den ønskede periode. Desuden skal massøren indtaste en generel standard start og slut tid for dagene, som fremgår af felterne GSStartTidDag og GSSlutTidDag. I tilfælde af at brugerne ønsker, at tilmeld eller afmelde sig fra en massage tid for samme dag, har massøren et krav om hvornår brugerne senest må fortage en tilmelding og afmelding for samme dag, som fremgår af felterne TilmeldingsFrist og AfmeldingsFrist. Der er som udgangspunkt ikke mulighed for bestilling af massage i weekenderne, men det kan massøren realisere ved, at check Weekend checkboxen af. Da systemet skal bruges af flere afdelinger og massør, bruges OrganizationId feltet til, at gemme opsætning for den givne afdeling som massøren har sat op, da hver massør tilhøre en afdeling og hver afdeling har en OrganizationId, dermed behøver massøren ikke indtaste de standard værdier igen, medmindre der er ændringer til standard værdierne. Beskrivelse af relation til entityen Kalender_Setup_Standardværdier: Kalender_Setup_Standardværdier har relationen 1 til M til Kalender_Setup_Ugedage tabellen som det fremgår af overstående diagram, eftersom der kan være mange Kalender_Setup_Ugedage baseret på en Kalender_Setup_Standardværdier. Visuelt eksempel på entityens formål: Side 31 af 77

32 Kalender_Setup_Ugedage entityen: Massøren har nu fået dannet et udkast til en kalender tabellen ved, at indtaste nogle standardværdier i Kalender_Setup_Standardværdier, men kan via tabellen, Kalender_Setup_Ugedage og Kalender_Setup_Ugedage_Parameter, fuldende kalenderen med de mere præcise data via de tilhørende felter. Felterne UgedageStartTid og UgedageSlutTid angiver hvornår der er mulighed for massage for den enkelte dag, som kan bestå af flere start tid og slut tid, da der er behov for fx spisepause eller andre pauser i mellem tiderne, som kan være forskellige fra dag til dag. Beskrivelse af relation til entityen Kalender_Setup_Standardværdier: Kalender_Setup_Ugedage har 2 relationer. Relationen til kalender_dage_tider er 1 til M, da der kan være mange Kalender_Dage_Tider baseret på en Kalender_Setup_Ugedage. Den anden relation er til Kalender_Setup_Parameter som har relationen M til 1 da hvert Kalender_Setup_Parameter er specifik for Kalender_Setup_Ugedage, men der kan godt være flere Kalender_Setup_Ugedage baseret på Kalender_Setup_Parameter, siden der kan forekomme flere UgedageStartTid og UgedageSlutTid for den samme dag. Visuelt eksempel på entityens formål: Kalender_Setup_Parameter entityen: Da systemet skal bruges af flere afdelinger og der tilbydes massage på forskellige dage for hvert afdeling, kan massørerne til de forskellige afdelinger aktiver og deaktiver dagene efter ønske via feltet Aktiv, aftalelængde på massage tiderne for en tilhørende dag vælges via feltet AftaleLaengde og antal af massører der er på arbejde ad gangen for den tilhørende dag, vælges via feltet AntalPladser. Side 32 af 77

33 Beskrivelse af relationerne til entityen Kalender_Setup_Parameter: Er beskrevet under Kalender_Setup_Ugedage. Visuelt eksempel på entityens formål: Kalender_Dage_Tider entityen: Indeholder alle de mulige massage tider for den enkelte dag, som brugerne kan bestille, og er dannet på bag grund af tabellen Kalender_Setup_Ugedage. Felterne StartTid og SlutTid er baseret på Kalender_Setup_Ugedage og Kalender_Setup_Ugedage_Parameter tabellerne. Felterne StartTid og SlutTid fra Kalender_Dage_Tider tabellen indeholder de forskellige mulige tider for massage, for den givne dag. Beskrivelse af relationerne til entityen Kalender_Dage_Tider: Kalender_Dage_Tider har 3 relationer. Relationen fra Kalender_Dage_Tider til Kalender_Tekst er M til 1 da der kan være mange Kalender_Dage_Tider der har den samme Kalender_Tekst. Relationen fra Kalender_Dage_Tider til Bestilling er 1 til M, da der kan være mange bestillinger til en Kalender_Dage_Tider, men hvert bestilling er specifik. Den sidste relation til entityen fra Kalender_Dage_Tider er til Ingen_Bestilling som er 1 til M, eftersom der kan være flere Kalender_Dage_Tider oprettet, kan der derfor være mange Ingen_Bestilling, men hvor hvert Kalender_Dage_Tider er specifik. Side 33 af 77

34 Visuelt eksempel på entityens formål: Kalender_Tekst entityen: Massøren vil gerne have muligheden for at kunne skrive en tekst til de enkelte dage, til brugerne i form af Husk at møde 5 min før massage tiden. Dette kan angives via felterne Dag og Tekst, hvor Dag er den givende dag teksten tilhøre og Tekst er den tekst der skal vises. Beskrivelse af relationerne til entityen Kalender_Tekst: Er beskrevet under Kalender_Dage_Tider. Visuelt eksempel på entityens formål: Bestilling entityen: For at en bestilling kan gennemføres, skal brugerne klik på opret bestilling og via OneSystem bliver alle data om brugeren gemt. Beskrivelse af relationerne til entityen Bestilling: Relationen fra Bestilling til Mail_Sendt 1 til M da en bestilling har fået tilsendt en specifik mail hvor den samme mail kan være sendt til mange bestillinger. Får at få data om brugeren har vi en relation til AuthorizedUser som er en standard udviklet af Regionen til at kommunikker med Side 34 af 77

35 OneSystem. Relationen er M til 1, da der er mange bruger hvor hvert bruger har en specifik bruger. Visuelt eksempel på entityens formål: Ingen_Bestilling entityen: Det kan forekomme, at massørerne ikke kan tilbyde massage for en bestemt dag i en periode. Det vil derfor være essentielt med en funktion der kan deaktiver den givne dag. For at kunne realiserer det, er der behov for et felt hvor den valgte dag kan angives og evt. en note til brugerne, her kan felterne Dag og Note anvendes. Beskrivelse af relationen til entityen Ingen_Bestilling: Er beskrevet under Kalender_Tekst. Visuelt eksempel på entityens formål: Side 35 af 77

36 Mail_Sendt entityen: Mail_Sendt entityen indeholder alle de mulige standart mail der er blevet sendt. Det kan forekomme, at massøren alligevel ikke kan tilbyde massage på en bestemt dag, i en aktiv periode, og at nogle af brugerne allerede har bestilt en massage tid. For at informere brugerne om, at massage-tiden er aflyst, skal der sendes en standart afbuds-mail til de bruger der har bestilt en massag-tid. Teksten til den tilhørende mail er angivet i feltet Indhold og overskriften på den pågældende mail er angivet i feltet Overskrift. For at sikrer, at mailen bliver sendt korrekt af sted, er der et felt i tabellen, Status, som registrer statussen på om mailen er blevet leveret, eller om der er opstået fejl under afsendelse af mailen. Den sendte mail refererer til den dag som mailen er vedrørende og er angivet ved feltet Dag. Modtager feltet vil indeholde den bruger der har fået en mail, det kunne være en mail angående aflyst massage-tid. Beskrivelse af relationerne til entityen Mail_Sendt: Relationen fra Bestilling til Mail_Sendt er beskrevet under Bestilling. Mail_Sendt har en relation til Mail_Tekster som M til 1, da der kan være mange af den samme Mail_Tekster der er sendt, men hvert Mail_Sendt tilhøre til en specifik Mail_Tekster. Visuelt eksempel på entityens formål (at få sendt de standarter mail): Mail_Tekster entityen: Massøren har ønsket at der skal være nogle standard mails, med en standard tekst, som automatik vil blive sendt af sted til brugerne af systemet. Disse standard mails har en tilhørende overskrift og tekst som kan angives i felterne Overskrift og Indehold. Side 36 af 77

37 Beskrivelse af relationerne til entityen Mail_Tekster: Er beskrevet under Mail_Sendt. Visuelt eksempel på entityens formål: Se Mail_Sendt eksemplet. 4.3 Mapping af Entity-relationship model til relations tabeller 3 : AuthorizedUser Id OSId Deleted FirstLogin LastLogin RegionId DisplayName Kalender_Setup_Standardværdier KalenderSSVId Deleted PeriodeStart PeriodeSlut OrganizationId GSSlutTidDag GSStartTidDag Weekend TilmeldingsFrist AfmeldingsFrist Kalender_Setup_Ugedage KalenderSUId Deleted UgedageStartTid UgedageSlutTid KalenderSSVId_FK KalenderSPId_FK Kalender_Setup_Parameter KalenderSPId Aktiv AntalPladser AftaleLaengde Deleted Dag Kalender_Dage_Tider KalenderDageTiderId StartTid SlutTid Deleted KalenderSUId_FK KalenderTekstId_FK Kalender_Tekst KalenderTekstId Dag Deleted Tekst Ingen_Bestilling IngenBestilingId Note Dato Deleted KalenderDagetiderId_FK Bestilling BestillingId BrugerNavn Dato Note SmsBesked Deleted AuthorizedUserId_FK KalenderDageTiderId_FK Mail_sendt MailSendtId Status Dato Modtager Deleted BestillingId_FK MailTeksterId_FK Mail_Tekster MailTeksterId Afsender Overskrift Indhold Deleted 3 Ramez E lmas ri & s hamkant B. Navathe: Fundamentals of database s ystems, SIXTH EDITION, 2011 s Side 37 af 77

38 4.3.1 Beskrivelse af Mapping Processen af mapping af ER til relation tabeller består af 8 steps, men jeg har valgt at begrænse mig til at skrive om de steps der har relevant for opgaven: Mapping af regulær entity. For hvert regulær entity bliver der oprettet en tabel og denne tabel består af alle tilhørende attributter. Mapping af 1 til M relationen. Relationen mellem de entity har relationen 1 til M som forsager at primærenøglen fra 1 siden bliver fremmedenøglen hos M siden. Som det ses af min relation tabeller har jeg gjort brug af de 2 overstående steps for mapping af ER-modelen. Jeg har dog begrænset mig til at ikke have alle tabeller med fra Onesystem, da det ikke er relevant for massage systemet om hvordan OneSystem genererer svaret Normalisering af tabellerne Normalisering af tabellerne er en metode der nedbryder ens tabeller og modvirker, at der ikke opstår redundans i databasen. Der findes 6.normalformer, men som regel bestræber man på, at opnår 3.normalform hvilket vil resultere i et godt database design 4 : Første normalform (1NF) En tabel der er normaliseret på første normalform betyder, at der ikke er gentagende grupper og alle værdier i tabellen er atomic. Alle mine værdier i tabellerne er atomic, derfor har jeg ikke behov for at fokusere på det, men for at der ikke er gentagende grupper har jeg fx splittet min Kalender_Setup_Ugedage op i to tabeller da jeg begyndt og normalisere tabellerne: 4 Ramez E lmas ri & s hamkant B. Navathe: Fundamentals of database s ystems, SIXTH EDITION, 2011 s Side 38 af 77

39 Et eksempel på at værdierne er atomic, men tabellen indeholdt gentagende grupper inden jeg fik normaliseret Kalender_Setup_Ugedage tabellen: Kalender Ugedage Ugedage Ugedage Ugedage Aktiv Antal Aftale Deleted Kalender SUId StartTid1 SlutTid1 StartTid2 SlutTid2 Pladser Lengde SSVId_FK Aktiv :45:00 11:15:0 12:00:00 13:00: Aktiv :00:00 11:45:00 12:15:00 13:45: 00 Overstående tabel indeholder flere UgedageStartTid og UgedageSlutTid for samme dag og antallet af dem varigere, hvilket er et godt eksempel på gentagende grupper, som er i mod første normalform. Desuden er den også imod 3.normalform, da der er flere felter fra tabellen der ikke er nøgle-felt som kan udregne et andet ikke nøgle-felt, fx hvis vi kender UgedageStartTid og UgedageSlutTid kan vi udregne AftaleLengde. For at opnå første normalform på overstående eksempel, kan tabellen splittes op i to tabeller, henholdsvis Kalender_Setup_Ugedage og Kalender_Setup_Parameter: Kalende_Setup_Ugedage: Kalender Ugedage Ugedage Deleted Kalender Kalender SUId StartTid SlutTid SSVId_FK SPId_FK :45: :00: :00: :15: :00: :45:00 Aktiv 2 1 Aktiv 2 1 Aktiv 2 1 Side 39 af 77

40 Kalender_Setup_Parameter: Kalender Aktiv Antal Aftale Dag Deleted SPId Pladser laengde Mandag Aktiv Tirsdag Aktiv Anden normalform (2NF) En tabel er på anden normalform, når den er i første normalform og alle ikke nøgle-felter er afhængig af hele primærnøglen. Med andre ord, består en tabel ikke af sammensat nøgler, er den allerede i anden normalform. Der kan dermed konkluderes at alle tabeller i massage systemet er på anden normalform, da ingen af tabellerne består af sammensæt nøgler og at de er på første normalform. Tredje normalform (3NF) En tabel er på tredje normalform når den er i anden normalform og ikke er afhængig af ikke nøgle-felter. Et eksempel på at en af tabellerne kan forekomme, at ikke være ikke på tredje normalform, Kalender_Setup_Parameter tabellen alt afhængig af tilstanden på feltet Aktiv i: Kalender Aktiv Antal Aftale Dag Deleted SPId Pladser Laengde Mandg Aktiv Tirsdag Aktiv Som det ses er felterne AntalPladser og AftaleLaengde afhængig af feltet Aktiv, når dagen ikke er Aktiv, altså når der ikke er mulighed for bestilling af massage kender vi svaret på AntalPladser og AftaleLaengde, hvilket er delvis imod 3.normalform da Aktiv ikke er en nøgle felt og kan bestemme felterne AntalPladser og AftaleLaengde i tilfældet af at dagen ikke er aktiv. For at undgå overstående kan man splitte tabellen op i 2 tabeller, men jeg har valgt at se bort fra det, da det er delvis imod 3 normalform, alt afhængig af om den givne dag er Aktiv. I tilfælde af at tabellen skulle splittes op, vil det se således ud: Side 40 af 77

41 Kalender Antal Aftale Deleted KalenderSAId_FK SPId Pladser Laengde KalenderSAId Aktiv Dag Deleted 1 1 Mandag 2 1 Tirsdag 3 0 Onsdag 4 1 Torsdag 4.4 Data definition language Data definition language(ddl) bruges til at oprette og definere datastrukturen for en tabel i en database 5. Dette afsnit vil indeholde et par eksempler på DDL fra massage systemet samt en kort beskrivelse til dem. Eksempel på oprettelse af Kalender_Setup_Standardvaerdier tabbellen i SQL 2008: USE [MassageBestilling2] CREATE TABLE [dbo].[kalender_setup_standardvaerdier]( [Id] [int] IDENTITY(1,1) NOT NULL, [Deleted] [date] NOT NULL, [PeriodeStart] [date] NOT NULL, [PeriodeSlut] [date] NOT NULL, [GSStartTidDag] [time](7) NOT NULL, [GSSlutTidDag] [time](7) NOT NULL, [Weekend] [bit] NOT NULL, [TilmeldingsFrist] [time](7) NOT NULL, [AfmeldingsFrist] [time](7) NOT NULL, CONSTRAINT [PK_Kalender_Setup_Standardvaerdier] PRIMARY KEY CLUSTERED ([Id] ASC)) 5 Ramez E lmas ri & s hamkant B. Navathe: Fundamentals of database s ystems, SIXTH EDITION, 2011 s Side 41 af 77

42 I starten af sql scriptet angives der hvilken database, scriptet referere til, via USE [MassageBestilling2], som det ses hedder databsen for massage systemet, MassageBestilling2. Dernæst oprettes den ønskede tabel ved, at skrive CREATE TABLE [dbo].[kalender_setup_standardvaerdier]. De felter der er en del af tablen bliver tilføjet og datatypen bliver erklæret, eksempelvis bilver der oprettet et felt med navnet Id, som består af datatypen int hvilket består af tal, som er IDENTITY(1,1) NOT NULL hvilket betyder at den automatisk tæller op for hver gang der bliver oprettet en ny Kalender_Setup_Standardværdier og acceptere ikke, at feltet, ikke indeholder en værdi, ved oprettelse af en ny record. CONSTRAINT [PK_Kalender_Setup_Standardvaerdier] PRIMARY KEY ([Id] ASC ), beskriver at der er en CONSTRAINT til tabellen Kalender_Setup_Standardvaerdier, som er en PRIMARY KEY hvilket betyder at der er et sæt regler for primær nøgle, såsom at hvert tablel skal have en primær nøgle og hvert tabel kan kun have en primær nøgle, primær nøglen kan ikke indeholde et tom værdi og værdien skal være unik. SQL opretter automatisk CLUSTERED på PRIMARY KEY hvilket betyder, at der oprettes en Clustered index via primær nøglen. ([Id] ASC )beskriver at det er feltet ID der er primær nøglen og sorterse i en stigenede ordre. Eksempel på oprettelse af Kalender_Dage_Tider i tabbellen i SQL 2008: USE [MassageBestilling2] CREATE TABLE [dbo].[kalender_dage_tider]( [Id] [int] IDENTITY(1,1) NOT NULL, [StartTid] [smalldatetime] NOT NULL, [SlutTid] [smalldatetime] NOT NULL, [Deleted] [date] NOT NULL, [KalenderSU_Id] [int] NOT NULL, [kalendertekst_id] [int] NOT NULL, CONSTRAINT [PK_Kalender_Dage_Tider] PRIMARY KEY CLUSTERED ([Id] ASC)) GO ALTER TABLE [dbo].[kalender_dage_tider] WITH CHECK ADD CONSTRAINT [FK_Kalender_Dage_Tider_Kalender_Setup_Ugedage] FOREIGN KEY([KalenderSU_Id]) REFERENCES [dbo].[kalender_setup_ugedage] ([Id]) GO Side 42 af 77

43 ALTER TABLE [dbo].[kalender_dage_tider] CHECK CONSTRAINT [FK_Kalender_Dage_Tider_Kalender_Setup_Ugedage] GO ALTER TABLE [dbo].[kalender_dage_tider] WITH CHECK ADD CONSTRAINT [FK_Kalender_Dage_Tider_Kalender_Tekst] FOREIGN KEY([kalenderTekst_Id]) REFERENCES [dbo].[kalender_tekst] ([Id]) GO ALTER TABLE [dbo].[kalender_dage_tider] CHECK CONSTRAINT [FK_Kalender_Dage_Tider_Kalender_Tekst] GO Det der er intressent ved overstående eksempel, i forhold til forrig eksempel, er, at tabellen Kalender_Dage_Tider har 2 fremmede nøgler. Som det ses på den første del af scriptet ALTER TABLE [dbo].[kalender_dage_tider], så bliver der erklæret at det er i Kalender_Dage_Tider tabbelen der skal tilføjes en fremmednøgle hvor fremmednøglen er KalenderSU_Id i tabbelen Kalender_Setup_Ugedage. Dernæst bliver det sikkret at der er oprettet en fremmednøgle til tabellen Kalender_Dage_Tider fra Kalender_Setup_Ugedage. Side 43 af 77

44 5 Implementering af præsentations lag Dette afsnit vil indeholde en beskrivelse af hvordan jeg har kodet min præsentations lag. Der vil derfor være eksempler på hvordan jeg har gjort brug af asp.net s kontroller, HTML og CSS for at opnår den ønskede brugergrænseflade. For at sikre at systemets brugergrænseflade opfyldt alle kravene, har jeg taget udgangspunkt i de Mockups jeg fik udviklet under dannelse af kravspecifikationen. Disse Mockups har været til en stor hjælp under implementering af brugergrænsefladet, da jeg altid har haft et visue lt billede af hvordan brugergrænsefladet skulle se ud. Nedenstående ses der et eksempel en simpel brugergrænseflad fra projektet, nemlig Kalender opsætning siden, hvor massøren skal indtaste de nødvendige oplysninger for at opsætte mulige massage tider: <%@ Page Title="" Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true" Inherits="Pages_KalenderSetup" %> CodeFile="KalenderSetup.aspx.cs" <asp:content ID="Content1" ContentPlaceHolderID="head" runat="server"> </asp:content> <asp:content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server"> <!-- TODO: Side indhold her --> <h3 style="clear:both">opsætning af standarværdier</h3> <asp:hiddenfield ID="hdnId" runat="server" /> <div style="float:left;clear:left;line-height:3; margin-left:20px;"> <asp:label ID="FMBDFMlabel" runat="server" Text="Første mulig bestillings dato for massage (dd-mm-åååå):"></asp:label><br /> </div> Som <div det style="float:right;clear:right;margin-right:20px; ses, indeholder kalendersetup.aspx siden en overskrift line-height:3;"> h3, som er en HTML element. Ydermere <asp:textbox er der ID="TxtFMBD" flere Labels runat="server" og Textbox som Width="112px"></asp:TextBox> er asp.net s kontroller. Disse Labels og Textbox </div> er blevet brugt til henholdsvis at vise massøren en tekst via labelen og tag i mod indtastning fra massøren via et textbox. For at give siden layout, har jeg gjort brug af CSS som eksemplet viser. Overskriftet h3 er blevet pålagt CSS via en ekstern CSS - fil. Hvor Labelene og Textboxene har fået pålagt CSS via inline-style ved at gør brug af en HTML div element. Side 44 af 77

45 Nedenstående er der et eksempel på hvordan man kan pålægge CSS på et HTML element. I nedenstående eksempel er det overskriften h3 der får pålagt CSS, og som billedet også illustrere, har jeg lavet en mappe for alle mine eksterne CSS - filer: For at tilgå den nævnte ekstern CSS fil skal man i Masterpage.master angive et link som referer til den givende CSS fil, i dette eksempel er overskriftet h3 en del af KalenderSetup.css. Som det ses på nedenstående eksempel har jeg flere referencer til eksterne CSS filer: <%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %> <!DOCTYPE html> <html xmlns=" <head runat="server"> <title></title> <meta name="viewport" content="width=device-width"> <asp:contentplaceholder ID="head" runat="server"> </asp:contentplaceholder> <link href="styles/kalendersetup.css" rel="stylesheet" type="text/css" /> <link href="styles/forside.css" rel="stylesheet" type="text/css" /> <link href="styles/minebestillinger.css" rel="stylesheet" type="text/css" /> <link href="styles/opretbestilling.css" rel="stylesheet" type="text/css" /> </head> <body> Side 45 af 77

46 Dette afsnit var et simpelt eksempel på hvordan jeg har fået lavet implementeret præsentationslaget ved at gør brug af asp.net s kontroller, HTML og CSS. En helt anden interessant ting ved ASPX-siden er, at den i toppen af siden indeholder en såkaldt direktiv, som er en måde at give frameworket og kompileren besked om hvor den tilhørende code-behind-fil er, hvilke programmeringssprog der benyttes osv. Nedenstående eksempel er på KalenderSetup.aspx siden hvor den tilhørende CodeFile er CodeFile="KalenderSetup.aspx.cs" som det ses på nedenstående eksempel: Kigger vi så i vores tilhørende CodeFile="KalenderSetup.aspx.cs" opdager vi noget endnu mere interessant, nemlig den service der bruges for at kunne kommuniker med OneSystem, TempCore.Service. Nedenstående eksempel er når en bruger er lukket ind i systemet og siden KalenderSetup.aspx bliver loadet. På eksemplet kan man se at der bliver tjekket om det er første gang siden bliver loadet i tilfældet af at det er, skal den hente organisationsid. For at hente organisationid tilgås AuthenticatedUser objektet der er lagret i brugerens login session. Sessionen bliver generet ved login vha. OneSystem integrationen der sørger for at tilføje bruger data til objektet. For at få organisationsid et hentes den jobfunktion som brugeren har valgt (SelectedJobfunctionId) da jobfunctionen indeholder orgnaisationid. Side 46 af 77

47 5.1 Kommunikationen fra applikationen til databasen I mit bachelorprojekt har jeg valgt at anvende Entity Framework til at kommuniker med min database. Jeg har i løbet af min uddannelse ikke fået undervisning i Entity Framework, hvilket betyder at dette er en ny teknologi og emne, som jeg skal få forståelse og kendskab til. Dette afsnit vil derfor indeholde en kort beskrivelse af teknologien Entity Framework og hvordan jeg har anvendte det til at kommunikere med databasen og ikke hvordan selv ved mapping foregår. 5.2 Entity Framework I forbindelse med udvikling i et objektorienteret udviklingsmiljø og en relationel database som persistenslag opstår der nogle udfordringer, da data struktureres forskelligt i objekt-orienterede programmering, og relationelle databaser. Entity Framework er et teknologi der skaber et lag af abstraktioner henover databasen ved, at danne et konceptuelt lag og afhjælper disse udfordringer. Entity Framework tager sig af den manuelle mapping mellem vores konceptuelle model og vores relationelle model ved at dynamisk skrive den kode der skal til 6. I næste afsnit vil der være et eksempel på hvordan man kan sætte Entity Framework op og hvordan jeg har gjort det i C#. 5.3 Opsætning af Entity Framework Dette afsnit vil der være et eksempel på hvordan man kan sætte Entity Framework. For at kunne gør brug af Entity Framework, skal man blot tilføje en ny ADO.NET Entity Data Model til sit projekt (bare højreklik og tilføj nyt item). Så skal den navngives, og derefter har man 2 forskellige muligheder for at opsætte Entity Framework 7 : Hvis man har allerede har databasen. Hvis man ikke har databasen kan man ved hjælp udviklingsmiljøet oprette den. Scenarie 1: Da jeg allerede havde oprettet min database i SQL, har jeg benyttet mig af scenarie 1. Her vælger man blot at generere sin model via databasen: 6 Joydip Kanjilal: E ntity Framework T utorial, , s Joydip Kanjilal: E ntity Framework T utorial, , s dn.mic ros oft.com/en-us /data/jj Side 47 af 77

48 Derefter indtastes der de nødvendig oplysninger for at oprette forbindelse til databasen og man vælger de tabeller, views og stored procedures der skal inkluderes: Dernæst ser vi at Entity Framework har skabt en konceptuel model ud fra vores database til de tabeller vi har valgt og man kan nu gør brug af Entity Framework. Nedenstående eksempel er kun nogle enkelte tabeller fra databasen: Side 48 af 77

49 5.4 Brug af Entity Framework Dette afsnit vil indeholde en beskrivelse samt et eksempel på hvordan jeg har brugt Entity Framework til at mappe objekter fra min applikations lag til databasen 8 : public static Kalender_Setup_Ugedage CreateOrUpdateUgedag(int timetid, TimeSpan ugedagestarttid, TimeSpan ugedagesluttid, string day, int kalenderid) { using (var context = new MassageBestilling2Entities2()) { var existing = context.kalender_setup_ugedage.where(x => x.id == timetid).firstordefault(); if (existing!= null) { //update existing.ugedagestarttid = ugedagestarttid; existing.ugedagesluttid = ugedagesluttid; context.savechanges(); return existing; } else { //create new var kalendersetupugedage = new Kalender_Setup_Ugedage(); kalendersetupugedage.ugedagestarttid = ugedagestarttid; kalendersetupugedage.ugedagesluttid = ugedagesluttid; kalendersetupugedage.kalendersp_id = GetParameterByDayAndKalenderId(kalenderId, day).id; context.kalender_setup_ugedage.add(kalendersetupugedage); context.savechanges(); return kalendersetupugedage; } } Side 49 af 77