Projekt i OOAD og Databaser

Størrelse: px
Starte visningen fra side:

Download "Projekt i OOAD og Databaser"

Transkript

1 Projekt i OOAD og Databaser Christian Høgh Pedersen (s125111) Christian Holm-Pedersen(s120036) Rasmus Lundsgaaard Christiansen (s123344) Anna Thideman(s124334) Philip Nicolas Adrian Velando Arosemena(s123301) 5. december 2013

2 Indhold 1 Introduction Forord - Anna Thideman Arbeidskontrakt - Anna Thideman Overordnet prosjektopgavebeskrivelse - Anna Thidema Vårt projekt - Anna Thideman og Christian Høgh Pedersen Kunden Kundens ønsker Læsevejledning - Christian Høgh Pedersen Analyse Vision - Christian Høgh Pedersen og Anna Thidemann Eksisterende system Rigt billede Funktionelle krav Ikke-funktionelle krav: Rammer: Aktører - Christian Høgh Pedersen, Christian Holm-Pedersen og Anna Thideman Sammenhæng mellem krav og aktører Use Cases - Christian Høgh Pedersen, Anna Thideman, Rasmus, Christian Holm-Pedersen Sammenhæng mellem krav og use cases Kort udlægning af use case Uformel udlægning af use case Fuldstændigt use case Navneordsanalyse CRC Kort Systemmodeller - Rasmus Domænemodel Systemopførsel Design Opbygning Klassediagram - Christian Høgh Pedersen Pakkediagram - Rasmus og Christian Holm-Pedersen Opførsel - Christian Høgh Pedersen og Anna Thideman Tilstandsdiagram Sekvensdiagram Data flow - Philip Velando GRASP - Holm-Pedersen Information Expert Controller Creator High Cohesion Low Coupling Anvendelse af polymorfi - Philip Velando

3 4 Database Konceptuel - Anna Thideman og Christian Høgh Pedersen Transaktionsbekræftelse Logik - Anna Thideman og Christian Høgh Pedersen Transaktionsbekræftelse Fysisk - Christian Høgh Pedersen, Anna Thideman, Philip, Christian Holm-Petersen og Rasmus DBMS Tabeller Triggers Users Stored Procedures Views Indexes Implementation Programmering - Christian Høgh Pedersen AdminConnector Prototype - Christian Høgh Pedersen Installationsvejledning - Christian Høgh Pedersen og Rasmus Database Program Test - Christian Høgh Pedersen AdminConnector Testplan Testresultater Konklusion - Alle gruppemedlemmer Reflektion Tidsmåling Udviklingsprocesser - Anna og Rasmus Gruppearbejde Videre udvikling - Christian Høgh Pedersen Bibliography 34 A Analyse 36 B Brugervejledning 37 B.1 Brugere B.2 Administrator C Database 41 C.1 Konceptuel C.2 Logik

4 Figurer 2.1 Rigt billede - person bliver medlem ved personlig oppmøde og utfyllelse af medlemskjema Use Case Diagram. Administratorer har interesse i alle use cases Domænemodel Oprettelse af prøvemedlem - systemsekvensdiagram Udsnit af klassediagram der viser hvordan klasserne er delt op Pakkediagram Tilstandsdiagram over Opdater information -use case Sekvensdiagram over Opret prøvemedlem -use case Dataflowdiagram med aktivitetsdiagram notation over Opret prøvemedlem -use case EER-diagram for databasen Resultat af test 1, AdminConnector Resultat af test 2, AdminConnector Resultat af test 1, AdminConnector A.1 Rigt billede - medlem ønsker å finde oplysninger om hold, træner og lokale på FSK nettside.. 36 B.1 Prototypens loginside B.2 Prototypens medlemsvisning efter administratorlogin B.3 Prototypens holdvisning efter administratorlogin B.4 Prototypens opret hold dialog B.5 Prototypens slet hold dialog B.6 Prototypens edit hold dialog B.7 Prototypens side for aktivering af statistikside, tilgængelig som administrator B.8 Prototypens statistikvisningsdialog. Der er diverse statistikker i hver fane

5 Tabeller 2.1 Sammenhæng mellem krav og aktører Sammenhæng mellem krav og use cases CRC: Medlemskab CRC: Medlem CRC: Administrator CRC: Ansat CRC: Træner CRC: Hold CRC: Lektion Entiteter C.1 Medlem-attributter C.2 Ansat/Administrator-attributter C.3 Træner-attributter C.4 Hold-attributter C.5 Lektion-attributter C.6 Besked-attributter

6 Kapitel 1 Introduction 1.1 Forord - Anna Thideman (Anna Thideman) Denne rapport er udarbejdet i forbindelse med et eksamensprojekt i kurset OOAD og database, efteråret Gruppen har fem medlemmer, der alle studerer på diplomingeniør-retningen Teknologi og økonomi(it-retning) på Danmarks Teknisk Universitet, undtaget Christian Høgh Pedersen der er meritstuderende. Kurset afholdes normalt på 3. semester i studieforløbet, og eksamensprojektet er det formelle grundlag for bedømmelse af de studerendes indsats på kurset. Opgaven bygger på undervisning i ovenstående kursus, samt kurser på 1. semester, hvor størstedelen af vores viden og erfaringer med Java stammer fra, mens vi på 2. semester har modtaget undervisning i MySQL. Specificering af opgaven kan findes i filen: E13ProjektDTU.pdf som ligger på campusnet.dtu.dk under siden til kursus (OBS! Kræver login). 1.2 Arbeidskontrakt - Anna Thideman (Anna Thideman) Gruppemedlemmer: Anna Thideman Christian Holm-Pedersen Philip Nicolas Adrian Velando Arosemena Christian Høgh Pedersen Rasmus Lundsgaaard Christiansen Mødested: I aftalt lokale, se skema på campusnet. Bygning 325. Forberedelse: Læs SVN-commits for at forberede sig og vide hvad som er sket siden sidste møde, og hvor langt vi er nået. Forsinkelser: Hvis et gruppemedlem er mere end 15 minutter forsinket, skal de sende en SMS og orientere gruppen. Hvis ingen kontakt efter 30 min, kontaktes medlemmet telefonisk. Sanktioner: Sover man betydeligt (cirka 30 min) over sig, eller undlader man at anmelde væsentlige forsinkelser til gruppen, skal skyldige medlem give kage/kaffe/kakao/eller lignende. 1.3 Overordnet prosjektopgavebeskrivelse - Anna Thidema (Anna Thideman) Prosjektgruppene skal bli dannet av de studerende selv, og gruppene skal velge en case selv som de vil anvende i prosjektoppgaven. I oppgaven skal man belyse relevant teori og verktøyer fra kurset I prosjektet skal gruppene altså utvikle et kjørende databaseapplikasjon, som skal utvikles på bakgrunn av et konkret behov hos en organiasjon eller virksomhet. Det må gjerne være et behov hos en virkelig bedrift. Gruppene skal utvikle en prototype, der programmet skal være menustyret slik at man kan velge mellom 1

7 forskjellige muligheter. Det skal også være minimum tre ulike brukere i programmet, med ulike rettigheter og muligheter. Endvidere skal det utarbeides analyse- og designdokumentasjon til prototypen, og programmet skal implementeres i programmeringsspråket Java. Også prosjektplanlegning skal utføres, dokumenteres og vurderes. 1.4 Vårt projekt - Anna Thideman og Christian Høgh Pedersen (Anna Thideman og Christian Høgh Pedersen) Udvikling af et databasebaseret system til medlemsstyring, med videre, til en sportsklub. Kunden ønsker et system der kan strømline indmeldelsen af medlemmer, samt gøre det lettere at holde styr på dem. Desuden vil de gerne have at medlemmer skal kunne bruge systemet til forskellige ting (Tilmeldning til hold, upload af billeder) Kunden Fightsport Køge er en kampsportsklub i Køge [1]. Det er en forholdsvis lille klub, som har brug for yderligere redskaber til at at forøge og håndtere fremtidig vækst. Deres Hjemmeside bliver admnistreret af virksomheden Noke ApS [2], og de vil sandsynligvis også overtage driften af dette projekts produkt, såfremt det bliver taget i brug Kundens ønsker Der er brug for en medlemsdatabase, hvor de oplysninger medlemmerne lægger ind den allerførste gang vi ser dem i klubben løbende kan udbygges, så vi ikke skal have flere formularer og database, regneark osv. men har en samlet medlemsdatabase, hvor det hele er samlet samme sted. Medlemmerne taster oplysninger ind over flere gange, hvilket giver flere forskellige steder de er samlet. Det er et ønske at dette i meget højere grad bliver automatiseret. Desuden er der et øsnke om at systemet i fremtiden vil kunne udføre en række andre opgaver, som er beskrevet herunder. * Automatik på flere punkter -eks. meddelelse om manglende informationer tastet ind, betalingsstatus, kontakt foretaget/ skal foretages. * mulighed for at PBS databasen med betalinger ikke betalinger kan overføres nemt, så man ikke skal taste manuelt på alle. på den måde kan man se hvem der ikke har betalt på PBS, som der så kan få noget automatisk besked. * Mulighed for at kunne grupperer folk eks. alle nye prøvemedlemmer mhp. at de automatisk får mail/sms beskeder om de forskellige faser i indmeldelsen eks. kvitteringer * Oversigt over de forskellige hold. Folk krydser af ved oprettelsen hvad hold de går på og selv får mulighed for at holde det ved lige * Et personaleblad på hvert medlem, hvor de selv kan logge ind og rette oplysninger, lægge billeder osv. * Integration med en sms service, så der kan sendes gruppe sms er afsted til de grupper der er behov for eks. ved aflysning at alle på holdet kl får besked * En mulighed for at kunne tilmelde sig forskellige hold, så andre kan se hvor mange deltagere der er (klik på websitet) og vi kan aflyse/ informerer ved under eks. 3 deltagere * En login skærm til at melde sig tilstede i klubben - noget man kan klikke på når man kommer ind, så vi kan følge hvor mange der kommer og træner på hvilke tidspunkter * En app til telefoner, der melder en tilstede/ forladt igen når man forlader klubben, så man ikke manuelt skal melde sig til og fra, men man har sagt ja til at gps trackeren må melde en til. 2

8 1.5 Læsevejledning - Christian Høgh Pedersen (Christian Høgh Pedersen) Ved hver sektion i denne rapport er det beskrevet hvilke gruppemedlemmer der har arbejdet på den givne sektion. Dette er angivet i kursiv i starten af sektionen. Står det intet under en sektion, så kan du regne med det er skrevet av det navnet/navnene som står på oversåtende sektion. E.g. kan det ses at denne sektion er skrevet af Christian Høgh Pedersen. Den fastlagte grænse for sideantallet på 30 normalsier er overholdt, såfremt man påregner at eksempelvis billeder såsom diagrammer og figurer svarer til 700 ansalg per styk. Derudover er der mange steder meget ubrugt plads. Eksempelvis har denne dette kapitel meget spildplads for at holde rapporten pæn. 3

9 Kapitel 2 Analyse 2.1 Vision - Christian Høgh Pedersen og Anna Thidemann Christian Høgh Pedersen og Anna Thidemann Vi, gruppe 13, er kommet i kontakt sportsklub FightSport Køge, og har lavet en aftale om at designe et produkt til dem i forbindelse med projektarbejdet i kurset OOAD og databaser - efteråret Vi har givet opgaven navnet Medlemskartoktek til Sportklub i Køge. Produktet som ønskes fra sportsklubbens side er et database-basert program som skal hjelpe dem til å administrere og styre klubben. De ønsker en medlemsdatabase, hvor oplysninger kan registreres, ændres, slettes, tilføjes undervejs etcetera. Information skal altså løbende udbygges, således at vores kunde(fightsport Køge) ikke skal være nødt til at have flere forskellige formularer, databaser, regneark og papirer som de har den dag i dag. Hovedformålet med dette planlagte program vil, fra kundens side, være at registrere nye medlemmer. Da dette i dag gøres over flere trin, så ønskes det at denne funktionalitet også findes i det planlagte program, men at information ikke lagres de i forskellige medier, men lagrer det et enkelt, centralt sted Eksisterende system I dag taster medlemmene opplysninger inn flere ganger, som registreres på forskjellige steder(i ulike databaser), og dette ønskes samlet i EN felles database ved hjelp av den nye program. I disse trinnene blir ulike informasjoner registrert: 1. Kundene starter med å opprette seg som prøvemedlemmer. Her får klubben noen grunnleggende opplysninger, som navn, telefonnummer, , fødselsdato og informasjon om hva slags trening de er interessert i. Denne informasjonen er rettet mot at klubben skal kunne kontakte dem ved et senere tidspunkt. Dette lagres i en database. 2. Hvis et medlem etter prøvetiden beslutter seg for å melde seg inn, skal de utfylle et nytt formular. Her skal de gjenta en del av opplysningene, som navn, telefonnummer og , men nå registreres det også CPR-nummer, opplysninger om hvor de bor og bankopplysninger. Denne informasjonen ender så i en helt annen database. 3. Når dette er gjort, foregår det en tredje registrering, hvor alle opplysningene blir samlet på et felles regneark. Her er det også felter som kan krysses av, så sportsklubben kan se om fakturaene er betalt, om de ønskes å kontaktes per mail eller SMS, om det er annen informasjon som er nyttig for klubben å vite om deres medlem etc. Altså de ønsker at dette i høyere grad enn nå blir automatisert, slik at medlemmene bare skriver videre på opplysningene fra prøvemedlemsregistreringen(punkt 1), når de fyller inn opplysningene som medlemmer(punkt 2). Så den siste delen med å samle opplysningene kan droppes(punkt 3). Alt for å optimere prosessen. 4

10 2.1.2 Rigt billede Et rigt billede brukes ofte til å få overblikk, og til å udtrykke problematiske forhold. Det skal gi insigt i situasjonen, så en løsning kan defineres og utvikles. Figur 2.1: Rigt billede - person bliver medlem ved personlig oppmøde og utfyllelse af medlemskjema Vores rige billede på Figur 2.1 viser hvordan situasjonen var hos FightSport Køge før vi begynte vårt samarbeid med dem. Billede viser hvordan det foregikk når en person ønsket at blive medlem i sportsklubben. Det hele foregikk ved at medlemmet skulle fylde ut et skjema i hånden eller online, og vedlegge det i en mail eller give det personligt til en admin i sportsklubben, hvorefter denne admin skulle skrive inn alle opplysningene i et excel-ark. Dette var en omstendig måte at gøre det på, og svært at endre i og vedligeholde. Vores program skal derfor løse dette problemet ved at et medlem skal kunne melde seg inn ved å skrive alle informationene direkte inn på nettsiden, og informationen så lagres i en database. Denne databasen kan selvfølgelig admin se og endre i. På denne måten slipper Fightsport Køge en masse arbeide og blir kvitt de uoversiktelige excel-arkene. Et annet rigt billede kan findes i bilag A Funktionelle krav Christian Høgh Pedersen og Anna Thidemann Beskriver krav til systemets funktion. Kravene er herunder skrevet op i en liste, og efter listen er der uddybninger af hvert krav. 1. Gemme medlemsoplysninger 2. Gemme holdoplysninger. 3. CRUD medlemsoplysninger. 4. CRUD holdoplysninger. 5. Funktionalitet skal kunne tilgås gennem en GUI. 5

11 6. Systemet skal kunne skelne mellem forskellige brugertyper. 7. Systemet skal benytte MySQL til at gemme data. Gemme medlemsoplysninger - Oplysninger skal gemmes centralt. - Hvert medlem skal have login info, kontaktinfo og betalingsoplysninger. Gemme holdoplysninger - Oplysninger skal gemmes centralt. - Hold skal kunne identificeres og der skal kunne skelnes mellem forskellige niveauer inden for samme type hold. e.g. skal der MMA-begynderholdet, og MMA-sparringsholdet være forskellige. CRUD medlemsoplysninger - Medlemmer skal kunne se/ændre i deres egne oplysninger, administratorer ansat af klubben skal kunne se/ændre alle medlemmers oplysninger. Klubbens trænere og andre ansatte skal have begrænset adgang til medlemsinformation. - Systemet skal give besked gennem brugergrænsefladen såfremt der er opstået en form for fejl eller inkonsistens når information indtastes. - Systemet skal indikere om medlemmer har betalt deres kontingent. Hver gang betalingsdatoer nås skal systemet checke om der er gyldige betalinger fra alle medlemmer. CRUD hold - Medlemmer skal kunne melde sig til/fra hold som de vil gå på. - Alle brugere skal kunne se hvor mange der er meldt til et givet hold. - Trænere og administratorer skal kunne give tilladelse til at folk må melde sig til de avancerede hold. - Administratorer skal kunne oprette nye hold, slette eksisterende og ændre i holdinformation. - Trænere skal kunne ændre i lektionplanen for hold de er ansvarlige for. Funktionalitet skal kunne tilgås gennem en GUI. - Brugere skal have fuld funktionalitet gennem et enkelt program. Systemet skal kunne skelne mellem forskellige brugertyper. - Når programmet starter op skal brugeren identificere sig via et login system. - En administrator har tilgang til alt og kan ændre alt. - En træner kan kontrollere adgang til avancerede hold, og oprette ekstra lektioner til hold - En ansat kan kontrollere al ikke-kritisk information. Kan e.g. se medlemmers betalinger og kontaktinformation, men ikke deres betalingsoplysninger. - Medlemmer kan se alle deres egne informationer og lave ændringer der involverer dem personligt(e.g. ændre deres egen betalingsplan, melde sig til/fra hold), men har kun begrænset adgang til resten af systemets data. Systemet skal benytte MySQL til at gemme data. - Som et krav fra Noke ApS, der vil overtage driften af systemet når det bliver taget i brug, skal oplysninger lagres gennem DBMS et MySQL, for at kunne samarbejde med deres webteknologier. 6

12 2.1.4 Ikke-funktionelle krav: Svartid skal være ubelastende. Systemet skal kunne bruges af personer uden særlige IT-fagligheder. Systemet skal kunne udvides i fremtiden. Svartid skal være ubelastende. - Systemet skal kunne køre på en moderne computer, uden at der opstår ventetider som vil være bemærkelsesværdige for brugeren. Systemet skal kunne bruges af personer uden særlige IT-fagligheder. - FSKs medlemmer og ansatte er ikke et IT-uddannet udsnit af befolkningen, og vil ikke bruge systemet medmindre det er meget brugervenligt. Systemet skal kunne udvides i fremtiden. - Der er en del ønsker fra FSK der ligger uden for dette projekts rammer. Disse skal kunne tilføjes af andre udviklere i fremtiden. - Databasen som udvikles i dette projekt skal understøtte disse fremtidige udvidelser, uden at der skal tilføjes nye tabeller Rammer: Aflevering Aflevering - Projektet afleveres d. 29/11/2013. På denne dato skal der være en prototype af systemet klar, og denne skal afleveres sammen med denne rapport i tre fysiske og en digital kopi. 2.2 Aktører - Christian Høgh Pedersen, Christian Holm-Pedersen og Anna Thideman Christian Høgh Pedersen, Christian Holm-Pedersen og Anna Thideman Aktører er roller brugere udfylder i forbindelse med deres brug af systemet. I dette tilfælde vil aktørens rolle i systemet typisk repræsentere deres forhold til klubben. Medlem: Person der er meldt ind i klubben. Prøvemedlem: Person der er meldt ind i klubben som prøvemedlem. Gæst: Person der ikke er meldt ind i klubben, men i gang med indmeldelsesforløb. Træner: Ansat i klubben der varetager træning på et eller flere hold Administrator Ansat i klubben der håndterer andre rolle end varetagning af hold. Medlem: Vil gerne have information omkring hold. Deres egen medlemskabsstatus. Deltager i hold. Vil kunne ændre deres egen information. Oprette sig i systemet. Gæst: Vil gerne have information omkring klubben. Vil gerne kunne udføre sit eget indmeldelsesforløb Prøvemedlem: Vil gerne have holdinformation. Vil gerne se hvilket prøvetimer de har igen. Vil gerne færdiggøre deres indmelding. 7

13 Ansat: Vil gerne kunne kontrollere medlemmers kontaktinformation, og at de har udført deres betalinger. Træner: Vil gerne se hvor mange der er tilmeldt hvert hold. Lave programmer for holdene. Vil kunne Give tilladelse til at medlemmer kan tilmelde sig avancerede hold. Administrator: Vil kunne se al information. Vil kunne CRUD medlemmer/ansatte/hold Sammenhæng mellem krav og aktører Se Tabel 2.1 for en oversigt over sammenhængen mellem krav og aktører. Gæst Medlem Ansat Træner Administrator Krav 1 X X X Krav 2 X Krav 3 X X X X X Krav 4 X X X Krav 5 X X X X X Krav 6 X X X X X Krav 7 Tabel 2.1: Sammenhæng mellem krav og aktører. 2.3 Use Cases - Christian Høgh Pedersen, Anna Thideman, Rasmus, Christian Holm-Pedersen Christian Høgh Pedersen, Anna Thideman, Rasmus, Christian Holm-Pedersen Vi har identificeret en række grundlæggende use cases for systemet. Disse er i denne sektion opridset, sammen med deres forhold til aktører og funktionelle krav. Use cases er summeret i den herunder følgende liste. Enkelte use cases er yderligere uddybet i kommende sektioner. Se Figur 2.2 for en oversigt over hvilke aktører der deltager i hvilke use cases. Oprettelse af prøvemedlem. Oprettelse af medlem. Kontrol af medlemsinfo. Opdatering af medlemsinfo. Se holdinfo. Kontrol af opmøde. Udmeldelse af medlem Sammenhæng mellem krav og use cases I Tabel 2.2 kan læseren se sammenhængen mellem krav og use cases Imellem krav og use cases er der tale om mange-til-mange relationer; Et krav kan forekomme i flere use cases, mens en use case kan dække over flere funktionelle krav. 8

14 Figur 2.2: Use Case Diagram. Administratorer har interesse i alle use cases. U1 U2 U3 U4 U5 U6 U7 U8 Krav 1 X X X X Krav 2 X X Krav 3 X X X Krav 4 X X X X Krav 5 X X X X X X X X Krav 6 X X X X X X X X Krav 7 X X X X X X X X Tabel 2.2: Sammenhæng mellem krav og use cases. 9

15 2.3.2 Kort udlægning af use case Et use case beskrevet i tekst. Oprettelse af Prøvemedlem Interesseret person henvises til FSK-program. Aktiverer prøvemedlemsoprettelse. Program viser en GUI hvor der kan indtastes den nødvendige information. Når information er indtastet, trykker bruger videre, og bliver præsenteret med en side hvor informationen står og de bliver bedt om at bekræfte dens korrekthed. Brugeren bekræfter, og programmet opretter en ny Medlem-tuple i databasen med den indtastede information Uformel udlægning af use case Mere detaljeret beskrivelse af et use case. Detaljerer forskellige slutresultater af use casen. Oprettelse af Prøvemedlem Main success scenario: Interesseret person henvises til FSK-program. Aktiverer prøvemedlemsoprettelse. Program viser en GUI hvor der kan indtastes den nødvendige information. Når information er indtastet, trykker bruger videre, og bliver præsenteret med en side hvor informationen står og de bliver bedt om at bekræfte dens korrekthed. Brugeren bekræfter, og programmet opretter en ny Medlem-tuple i databasen med den indtastede information. Alternate scenario:...bruger opdager fejl i information. Trykker lav ændringer. Bruger præsenteres for samme informationsside, med den information de har indtastet allerede udfyldt. Bruger laver ændringer. Bruger godkender Alternate scenario:...bruger fortryder indmeldelse. Afbryder indmeldelse ved at lukke program, eller at trykke afbryd indmeldelse. Program sletter eventuel indtastet information og lukker. Alternate scenario:...bruger standser indtastning. Efter at bruger ikke har interageret med programmet i tidsmængde laver program en besked om at indtastingstid er løbet ud. Program sletter indtastet information og vender tilbage til startside Fuldstændigt use case Opret Prøvemedlem Omfang: Niveau: Fightsport Køge(FSK) Klubstyringsprogram Brugermål Primære aktør: Gæst. Interessenter og andre aktører: Gæst: Vil gerne have sin information korrekt til klubben hurtigt og smertefrit. FSK: Vil gerne have medlemsinformation på en overskuelig måde. Vil have at brugere har en behagelig oplevelse. Administrator: Vil gerne have at det er let nok for medlemmer at oprette sig til at de ikke spørger om hjælp. Påkrævet grundlag: Ingen. 10

16 Resultater: Prøvemedlem er oprettet. Data er gemt i database. Kvittering er genereret til bruger. Primære succes-scenarie: 1. Gæst tilkendegiver interesse. Bliver dirigeret til program af administrator. 2. System viser muligheder for ikke-registrerede brugere. PM vælger Opret prøvemedlem mulighed. 3. System viser indmeldelsesformular. 4. Gæst indtaster information. 5. Gæst trykker Fortsæt. 6. System viser information som den er registreret, spørger om bekræftelse. 7. Gæst bekræfter. 8. System lagrer et prøvemedlem med den indtastede information i databasen. 9. System viser kvittering. 10. Gæst lukker program. Alternative forløb: *a: Any time. PM fortryder indmeldelse PM trykker afbryd indmeldelse. System sletter indtastet information. Viser startside. *b: Any time. PM standser indtasting. System venter tidsmængde. System sletter indtastet information. Viser startside og timeout-besked. 6a: Gæst opdager fejl i information. PM trykker lav ændringer. System viser information som blev indtastet. PM indtaster information og trykker gå videre. GOTO Main Success Scenario tring 7. Særlige krav: Kørende database med relevante tabeller. Variationer i teknologi: Ingen. Hyppighed: Daglig/Ugentlig Navneordsanalyse På baggrund af use cases, krav og aktører, har vi udarbejdet følgende kandidater til klasser: Medlem. Ansat. Træner. Administrator. Hold. 11

17 Lektion. Betaling. Medlemskab CRC Kort Som et led i designet har vi lavet flere CRC (Class-Responsibility-Collaboration)-kort. CRC Metodens formål kan minde om et Sekvensdiagram, blot lettere fordøjeligt for mennesker uden UML indsigt. Formålet med CRC-kort er at man på et tidligt tidspunkt i forløbet kan gøre brug af kortene til at udlægge et basalt sekvensdiagram, uden at være fanget af et diagrams restriktioner mens man udvikler programmet. Tabel 2.3: CRC: Medlemskab Medlemskab Medlem Medlemskabstype Betalingsplan Kender Betalingplanens pris Tabel 2.4: CRC: Medlem Medlem Medlemskab Person info Besked Event info Hold Tilmeldte lektioner Lektion Beskeder Hold Betalinger Bankinfo Tabel 2.5: CRC: Administrator Administrator Medlem Har fuld adgang til systemet Ansat Kan ændre i Ansatte og medlemmero Træner Tabel 2.6: CRC: Ansat Ansat Medlem Person info Lektion Træner Tabel 2.7: CRC: Træner Træner Hold Personinfo Lektion Ansvarlig for hold/lektioner 2.4 Systemmodeller - Rasmus (Rasmus) Indeholder domænemodel for hele systemet, og andre modeller for dele af systemet. 12

18 Tabel 2.8: CRC: Hold Hold Medlem Kender tilmeldte medlemmer Lektion Kender holdets lektioner Træner kender Træneren som er ansvarlig for holdet Tabel 2.9: CRC: Lektion Lektion Medlem Kender tilmeldte medlemmer Træner Info for lektionen Kender Træneren som er ansvarlig for holdet Domænemodel En domænemodel beskriver problemstillinger i den konceptuelle del af analysen. Der fremgår således i modellen bud på entiteter samt deres relationer, roller og begrænsninger (constraints). Figur 2.3: Domænemodel Systemopførsel Indeholder systemsekvensdiagram og operationskontrakter for kernefunktionalitet i systemet. Kontrakt: indtastinformation Operation: confirminformationnavn: String, String, tlf: String, cpr: String. Krydsreference: Use Case: Opret prøvemedlem. Forudantagelser: Gæst er ved at melde sig som prøvemedlem. Resultater: - tlf konverteres til int. - MedlemData objekt oprettes. - Databaseforbindelse oprettes. - Række med medleminformation indsættes i Medlem-tabel, med information svarende til medlemd oprettet med data fra MedlemData-objekt. 13

19 Figur 2.4: Oprettelse af prøvemedlem - systemsekvensdiagram. 14

20 Figur 3.1: Udsnit af klassediagram der viser hvordan klasserne er delt op Kapitel 3 Design 3.1 Opbygning Denne sektion detaljerer hvordan systemet er bygget op Klassediagram - Christian Høgh Pedersen (Christian Høgh Pedersen) Designklassediagrammet er i store udtræk ækvivalent med analyseklassediagrammet. Det gælder dog for de klasser der er repræsenteret designklassediagrammet, at de typisk er blevet delt op i tre klasser, der udfylder forskellige roller i forhold til klassens funktionalitet. Et eksempel på denne opdeling kan ses i Figur 3.1, hvor det kan ses hvordan Admin-klassen er delt op Pakkediagram - Rasmus og Christian Holm-Pedersen (Rasmus og Holm-Pedersen) Pakkediagrammer er utrolig brugbart til at visualisere opdelingen af software klasserne i lag. Et lag er en gruppering af flere klasser, pakker eller undersystemer der har en høj sammenhørighed gennem deres funktion inden for systemet, og vil ikke ændre sig i løbet af et projekt med mindre der bliver ændret i klasseopbygningen. Disse lag er rangeret efter en top-down metode hvor de øverste lag kalder de lag under sig. D.v.s. at højere lag har mulighed for at bede lavere rangerede lag håndtere data og sende svar tilbage, mens lavere rangerende lag ikke kan kalde på højere lag(generelt). Når man ser på alle disse lag sammen på et diagram taler man om den logiske arkitektur. 3.2 Opførsel - Christian Høgh Pedersen og Anna Thideman Christian Høgh Pedersen og Anna Thideman Denne sektion detaljerer hvordan nogle dele af systemet opfører sig Tilstandsdiagram Et tilstandsdiagram er en grafisk repræsentation af en del af systemet, der viser hvilke tilstande systemet går ind i som reaktion på hændelser. De oblonge elementer er de tilstande systemet går ind i som resultat 15

21 Figur 3.2: Pakkediagram af de transitioner, som er pilene, der opstår. Teksten på pilene navngiver den hændelse der forårsager transitionen. Systemets opførsel er bundet op i at der er en bruger der interagerer med det gennem en GUI. Systemet fungerer derfor primært som en række af reaktioner på brugerens input. Som eksempel kan ses Opdater information -use casen, hvor et klubmedlem vil ændre sine personlige informationer v.h.a. systemet. Systemets opførsel i denne situation er illustreret i et tilstandsdiagram i Figur 3.3. Figur 3.3: Tilstandsdiagram over Opdater information -use case Sekvensdiagram Sekvensdiagrammet er en udvidet version af systemsekvensdiagrammet, der også viser hvordan systemets interne komponenter reagerer opfører sig i sekvensen. Et sekvensdiagram kan sees på figur 3.4 nedenunder. 16

22 Figur 3.4: Sekvensdiagram over Opret prøvemedlem -use case Data flow - Philip Velando (Philip Velando) Data flow diagrammet med aktivitetsdiagram notation viser flowet i use casen oprettelse af prøvemedlem og de aktiviteter henholdsvis en gæst of systemet foretager sig ved denne operation. 3.3 GRASP - Holm-Pedersen (Holm-Pedersen) Information Expert, Controller og Creator er en del af GRASP(General Responsibility Assignment Software Patterns) principperne. Disse pricipper bruges i software programmering og har til formål at strømline og optimere de forskellige dele af programmet Information Expert Princippet i designeringen af en information expert klasse er at samle al information i en enkelt klasse for dermed at lade denne klasse overtage det fulde ansvar for en specifik funktion. fx ville en klasse der indeholdte al information omkring alle medlemmer være en information expert klasse i relation til medlemmer. Dette 17

23 Figur 3.5: Dataflowdiagram med aktivitetsdiagram notation over Opret prøvemedlem -use case gør at man kan samle information et sted og derved samle overblikket over programmet og gøre det nemmere at tilgå efter en eventuel videregivelse af kode til programmørere eller kunden. En sammenligning ville fx. være med en chef for en afdeling eller en ekspert inden for et felt Controller En Controller klasse er brugt til at samle de forskellige kommandoer der er mulighed for i programmet for på den måde at skabe lavere kobling. Denne klasse vil lægge lige under GUI en og har det overordnede ansvar for at håndtere system operationer. Vores Statistik klasse er fx. en Controller klasse der håndterer alle statistik operationer der forekommer i programmet. Sådanne klasser bruges specifikt til at klumpe flere ens handlinger sammen, såsom oprettelsen og opdatering af bruger oplysninger Creator En Creator klasse vil have ansvaret for instancieringen af objekter der bruges af en anden klasse og ligger sig derved op af denne klasse. Ofte vil dette svare til at en Creator klasse vil lægge sig op af en Information Expert klasse som den kan hive data ud fra for at instanciere objektet A High Cohesion Høj samhørighed i en klasse er en analyse af hvor fokuseret klassens formål er. D.v.s. at hvis klassen kun har et formål, selv hvis der er flere andre klasser der gør brug af den, har den stadig høj samhørighed(kan også siges som der er mange tilnærmelsesvis end metoder der udfører sammenlignelige opgaver). Derimod vil en klasse med metoder der udfører mange forskellige opgaver skabe lav samhørighed i klassen Fordelen ved høj samhørighed i klasser udbunder i en nemmere forståelse af programmet og muliggør et hurtigere udviklings- og overdragelsesforløb, da man kan isolere ændringer i koden og skabe mere overksuelighed. 18

24 3.3.5 Low Coupling lav kobling i et system betyder at komponenterne i et system ikke er direkte bekendte med hinanden, fx. kalder en direkte, men kalder metoder i stedet. Ved lav kobling er det fx. muligt at skabe udvidelser hurtigt da man så kan skære ned på antallet af korrektioner der skal gøres. I vores program er det sammenhøngen mellem GUI en og databasen der er adskilt ved hjælp af logicklasserne. Hvis vi i stedet havde sat GUI en direkte i forbindelse med databasen ville vi se en meget højkobling der besværliggjorde ændringer i softwaren. 3.4 Anvendelse af polymorfi - Philip Velando (Philip Velando) Vi kan med fordel benytte os af polymorfi i vores system, da flere af funktionaliteterne går igen hos de forskellige brugere, dog med lidt forskellige restriktioner. Admin brugeren har, som det fremgår af vores databaseopbygning, adgang til alle funktionaliteter, mens de andre brugere har adgang til brudstykker af disse. Eksempelvis har et Medlem adgang til at se andre brugeres profilsider, altså en samling ikkepersonfølsomme informationer som eksempelvis navn, alder og fødselsdato. Samtidig har en Ansat bruger adgang til at se flere informationer hos de forskellige brugere, såsom betalingsinformationer, telefonnummer, og adresse. 19

25 Kapitel 4 Database Dette kapitel dokumenterer udarbejdelsen af databasen. Det er inddelt i flere sektioner, hver indeholdende et led i udviklingen. Første sektion detaljerer den konceptuelle model, anden sektion den logiske model. Tredje sektion detaljerer udviklingen af den fysiske model. 4.1 Konceptuel - Anna Thideman og Christian Høgh Pedersen (Anna Thideman og Christian Høgh Pedersen) På baggrund af de ønsker Fightsport Køge har til databasens funktionalitet, har vi udarbejdet en række entiteter, som kan ses i Tabel 4.1. Entiteternes attributter er dokumenteret i Tabel C.1 til C.6, som er at finde i Bilag C.1. For en illustration af forholdene mellem disse entiteter, henvises til Figur 4.1, som er et EER-diagram over databasen. Vi designer ikke specifikke domæner til nogen attributter, da databasen ønskes implementeret i MySQL, som ikke understøtter oprettelsen af domæner Transaktionsbekræftelse Eksempler på transaktioner som modellen skal kunne udføre er opskrevet i den følgende liste. Der er ikke listet transaktioner for Data-indtastning/opdatering/sletning, da de kan ses at være overholdt ved eksistensen af relevante entiteter. 1. List et givent medlems navn. 2. List hvornår et givent medlem foretog en betaling. 3. List navnet på træneren der er ansvarlig for et givent hold. 4. List hvem der er ansvarlig for at betale for et givet medlem 5. List hvilke medlemmer der er tilmeldt et givent hold 6. List hvilke dage på ugen et givet hold har lektion Det kan ses ud fra EER-diagrammet at disse transaktioner kan udføres af modellen, ved eksempelvis de følgende fremgangsmåder. Nummerering tilsvarende transaktionsliste: 1. Medlemmers navne er givet i medlem-entiteten, og kan findes kun ved brug af dette. 2. Medlem-entiteten har den komplekse attribut betalinger, som indeholder alle betalinger medlemmet har foretaget. Hver af disse har en dato som kan hentes. Hent den højeste. 3. Træner-entiteten har træneres navn. Gennem forholdet ErAnsvarligFor kan vi finde træneren der er ansvarlig for et givet hold. 4. Medlemmer kan have forholdet DelerHusstand. Hvis de er en del af dette forhold med rollen husstandsmedlem er medlemmet der deltager i forholdet som betaler ansvarlig for at betale for det givne medlem. 5. Kan ses ud fra forholdes MeldtTil. 20

26 6. Gennem forholdet ErDelAf kan det ses hvilket hold hver lektion deltager, og det kan derved bruges til at danne en liste over alle lektioner der er del af et givet hold. Fra denne liste kan man så hente dagene. 1. Hent alt information omkring et givent medlem. 2. List træneren der er ansvarlig for et givent hold. 3. List hvem der er ansvarlig for at betale for et givet medlem 4. List hvilke medlemmer der er godkendt til et givet hold 5. List hvilke medlemmer der er tilmeldt et givent hold 6. List hvilke dage på ugen et givet hold har lektion Entitet Beskrivelse Aliaser Fremkomst Medlem Medlem af FSK Intet alias Medlemmer kan deltage i forskellige lektioner, og være godkendt til/deltage i forskellige hold Ansat Person ansat hos FSK. Mindre administrativt ansvar Medarbejder Ansatte kan kontrollere basal information i databasen og kontakte medlemmer. Træner Træner ansat af FSK Instruktør Trænere kan have ansvar for flere hold og dele ansvar for lektioner. Hold Administrator Generelt udtryk for de forskellige kampsportshold udbudt af FSK FSK ansat der er betroet med større administrativt ansvar. Intet alias Leder Hvert hold varetages af én træner. Flere medlemmer kan deltage i hvert hold. Administratoren er ansvarlig for at vedligeholde informationen i databasen, og at hjælpe medlemmer/ansatte der har problemer. Lektion Instanser af hold. Time I hver lektion deltager op til flere medlemmer og trænere. Besked Besked sendt fra FSK ansat til /SMS Beskeder sendt fra ansatte medlem. til medlemmer lagres i databasen, for at gøre kontrol mulig. Tabel 4.1: Entiteter. 4.2 Logik - Anna Thideman og Christian Høgh Pedersen (Anna Thideman og Christian Høgh Pedersen) Denne sektion detaljerer den logiske model for databasen, som er bygget ud fra den konceptuelle, efter metodologien i [3]. Relationer er normaliseret til trejde normalform efter betingelserne for denne, som beskrevet i [3, 4]. Der er ingen delvise afhængigheder (2NF) og alle transitive afhængigheder er fra kandidatnøgler(e.g. i Medlem) eller supermængder af primærnøglen for den givne relation(e.g. i Lektion), som kan ses herunder. De resterende relationer er at finde i Bilag C.2. 21

27 Figur 4.1: EER-diagram for databasen. (Medlem-entity) Medlem (medlemid, navn, adresse, telefon, , kaldenavn, adgangskode, basisopprettelsesdato, fuldopprettelsesdato, betalinger, betalingsform, pbs, magnetfarve, bemærkninger, cpr, bankreg, bankkonto, ansatid, betalerid, medlemskabstype) Udledt attribut godbetaler Primærnøgle medlemid Fremmednøgle ansatid henviser til Administrator(ansatID) ON UPDATE CASCADE ON DELETE SET NULL Fremmednøgle betalerid henviser til Medlem(medlemID) ON UPDATE CASCADE ON DELETE SET NULL Fremmednøgle medlemskabstype henviser til Medlemskaber(medlemskabstype) ON UPDATE CAS- CADE ON DELETE SET NULL (Lektion-entity) Lektion (dag, tidspunkt, varighed, lokale, holdid) Primærnøgle (dag, tidspunkt, lokale) Fremmednøgle holdid henviser til Hold(holdID) ON UPDATE CASCADE ON DELETE NO ACTION 22

28 4.2.1 Transaktionsbekræftelse Eksempler på transaktioner som modellen skal kunne udføre er opskrevet i den følgende liste. Der er ikke listet transaktioner for Data-indtastning/opdatering/sletning, da de kan ses at være overholdt ved eksistensen af relevante relationer. 1. List et givent medlems navn. 2. List hvornår et givent medlem foretog en betaling. 3. List navnet på træneren der er ansvarlig for et givent hold. 4. List hvem der er ansvarlig for at betale for et givet medlem 5. List hvilke medlemmer der er tilmeldt et givent hold 6. List hvilke dage på ugen et givet hold har lektion 1. Navn er en attribut i Medlem-relationen 2. Betaling-relationen har en attribut medlemid, som er en fremmednøgle der peger på en medlemrelation. Ved at finde betalingen med den højeste dato, som har en medlemid svarende til et givet medlem, kan transaktionen udføres. 3. trænerid er en fremmednøgle i hold-relationen, som peger på træneren der er ansvarlig for holdet. Gennem denne kan man finde trænerens navn. 4. medlem-relationen har en fremmednøgle betalerid der peger på det medlem som er ansvarlig for at betale for medlemmet. 5. Holdtilmeldelse-relationen har holdid og medlemid og ved at tælle antallet af medlemid er for et givent holdid kan man udføre transaktionen. 6. Med fremmednøglen holdid i lektion-relationen, kan man finde alle lektioner der tilhører et givet hold. hvis man lister dagene for disse lektioner er transaktionen udført. 4.3 Fysisk - Christian Høgh Pedersen, Anna Thideman, Philip, Christian Holm-Petersen og Rasmus Christian Høgh Pedersen, Anna Thideman, Philip, Christian Holm-Petersen og Rasmus I denne fasen kommer SQL på banen, og det er her man f.eks oversetter den logiske model til valgt DBMS, og man opretter sikkerhetsmekanisker som ulike brukere og stored procedures, da disse ikke ikke repræsenteret af den logiske model DBMS Vi har valgt at benytte MySQL af flere årsager. En af de mere luksoriøse årsager, var at vi alle har arbejdet med DBMSen før, og derfor også havde den installeret ved projektets begyndelse. Den primære årsag er dog at vores kunde Fightsport Køge og deres IT leverandør NOKE.dk, allerede benytter MySQL som DBMS i deres nuværende web stack/hjemmesidesystem, hvorfor de har adgang til de ressourcer der skal bruges til DBMS drift på sigt. Der er mange DBMSer at vælge imellem; vi har kort overvejet at benytte PostgreSQL eller IBMs DB2 i stedet, desværre nåede vi aldrig at få mulighed for at benytte DB2 og til trods for ekstra godbidder som brug af eksempelvis de mere avancerede WITH-queries eller funktionen check som kan benyttes til referentiel integritet, som både Postgres, DB2 og mange andre modne DBMSere understøtter. Vi har gangske kort også undersøgt de mere moderne datastores der populært kaldes NoSQL. Mange mennesker mener at NoSQL systemer (der hver især også varierer og adskiller sig fra hinanden en hel del i 23

29 metode og funktionalitet) ikke kan kaldes databaser, idet de ikke følger den relationelle tankegang vi kender fra gængse databaser (de er derfor bevist benævnt som datastores ) men i stedet har en meget løs (ofte ikke-eksisterende) struktur og anderledes metoder til at få fat i den ønskede data. Eksempelvis benytter CouchDB sig udelukkende af views (en funktionalitet der også findes i de fleste relationsdatabaser), som skal skrives på forhånd (f.eks. getuserbyuserid-viewet) hvor MongoDB benytter en mere SQL-lignende struktur. Fælles for NoSQL databaserne er at de er gode/hurtige/effektive til enten at hente eller skrive data (READ- S/WRITES) men kan være mindre robuste og sikre (data integritet) end traditionelle relationsdatabaser. Da det ikke er den nye Facebook eller Twitter (der begge er store på Big Data-tjenester) vi skal lave, er der ingen oplagt årsag til at benytte en NoSQL datastore, desuden modtog vi aldrig undervisning i NoSQL, som det ellers var planen Tabeller Se vedlagte fil CreateTables.sql Relationer implemerenteret. Enkelte værdityper ændret, e.g. INT til BIGINT eller UNSIGNED INT fordi værdier blev opdaget der overskred INT grænsen Triggers Se vedlagte fil CreateTriggers.sql Triggers er blevet brugt til at opretholde constraints der ikke dækkes af fremmednøgler. Eksempelvis at medlemmer der er tilmeldt/fravalgt et hold, også tilmeldes/frameldes holdets lektioner Users Se vedlagte fil CreateUsers.sql Der oprettes brugere svarende til de forskellige brugertyper (Admin, Træner, Ansat og Medlem) samt en bruger der vil kunne bruges til oprettelse af basismedlemmer. Brugere er tildelt forskellige rettigheder på FSK-schemaet afhængigt af type, se GRANT-statements i vedlagte fil for en uddybning. Da databasen i sidste ende vil blive oprettet i et DBMS indeholdende andre databaser med privat indhold, er det ikke sikkert at give brugere adgang til DBMS ens stored procedure tabel v.h.a. grants. Rettigheder til brug af stored procedures skal derfor håndteres på applikationsniveau Stored Procedures Se vedlagte fil CreateStoredProcedures.sql Der er oprettet en række stored procedures der returnerer et udvalg af statistiske informationer omkring databasen, til opfyldelse af projektkrav Views Se vedlagte fil CreateViews.sql Der er oprettet ét view, ud fra medlemmer, beregnet til at give ansatte adgang til en delmængde af de tilgængelige medlemsinformationer. Der oprettes views til at afgrænse den information trænere og ansatte har adgang til. Administratoren vil have adgang til den fulde database, og der er ikke tilstrækkelig grund til at lave et view til denne bruger. Medlemmer og trænere vil have adgang til forskellig information afhængigt af den specifikke bruger, og vil blive håndteret på application-niveau. 24

30 4.3.7 Indexes MySQL laver automatisk indekser på primærnøgler og fremmednøgler. Vi gennemgik indekseringsovervejelserne som beskrevet i [3], kapitel 18. Resultatet af dette er givet i næste paragraf. De fleste af relationerne er ikke store nok til at retfærdiggøre tilføjelsen af sekundære indekser. Medlem er den eneste relation som har tilstrækkelig størrelse, men da de fleste af dens interessante attributter er enten primærnøgler, unikke, eller fremmednøgler, har MySQL automatisk oprettet indekser på dem. Vi har tilføjet sekundære indekser over medlemmets, attributter basisoprettelsesdato og fuldoprettelsesdato med henblik på brug i statistikfunktionalitet. 25

31 Kapitel 5 Implementation 5.1 Programmering - Christian Høgh Pedersen (Christian Høgh Pedersen) Denne sektion indeholder et uddrag af enkelte mere interessante kodesegmenter AdminConnector Der er to metoder fra klassen AdminConnector som vi vil inddrage som interessante. I Kodeblokken 5.1 Er AdminConnector.connectDB(), som bliver kaldt hver gang der skal forbindes til databasen. Den bruger databasebrugeren fskadmin, som er oprettet sammen med databasen, til forbindelsen. For at gøre det muligt for AdminConnector at benytte lagrede procedurer i databasen, uden at give den adgang til proceduretabellen for hele vores DBMS, er det nødvendigt at bruge denne listede version af MySQL JDBC s getconnection()-metode. AdminConnector bruger ikke lagrede procedurer på dette tidspunkt, men en anden klasse, StatististikConnector, gør. AdminConnector.connectDB() behøver ikke at returnere noget for at bevare sin funktionalitet, men returværdien bliver brugt i tests. I Kodeblok 5.2 kan det ses hvordan AdminConnector.editHold() henter holddata ud af databasen. Først forbindes via ConnectDB(). Derefter lagres de resulterende værdier i en lokal variabel, som kan bruges af andre systemklasser som er ansvarlige for at operere på dataen, og vise den til brugeren. Listing 5.1: AdminConnector.connectDB() private boolean connectdb ( ) { try { connection = DriverManager. getconnection ( jdbc : mysql : / / l o c a l h o s t / fskdb? noaccesstoprocedurebodies=true, fskadmin, adminpass ) ; } } catch ( SQLException e ) { // TODO Auto generated catch b l o c k e. printstacktrace ( ) ; return f a l s e ; } return true ; Listing 5.2: AdminConnector.editHold() public boolean edithold ( S t r i n g orgid, S t r i n g nyid, 26

32 S t r i n g nytnavn, S t r i n g nytniveau ) { connectdb ( ) ; // TODO Auto generated method s t u b try { preparedstatement = connection. preparestatement ( UPDATE hold SET holdid =?, navn =?, niveau =? WHERE holdid =? ) ; preparedstatement. s e t S t r i n g ( 1, nyid ) ; preparedstatement. s e t S t r i n g ( 2, nytnavn ) ; preparedstatement. s e t S t r i n g ( 3, nytniveau ) ; preparedstatement. s e t S t r i n g ( 4, orgid ) ; } preparedstatement. execute ( ) ; } catch ( SQLException e ) { // TODO Auto generated catch b l o c k e. printstacktrace ( ) ; return f a l s e ; } return true ; 5.2 Prototype - Christian Høgh Pedersen (Christian Høgh Pedersen) Prototypen demonstrerer at det er muligt at logge ind med forskellige brugertyper, og at lave ændringer i databasen gennem en GUI. Der er dog en del funktionalitet der ikke er færdiggjort. Herundet er der listet en række begrænsninger for prototypen: Træner/Ansat profiler er ikke implementeret Fejl i forbindelse med eksevering af SQL-kommandoer, e.g. INSERT der duplikerer eksisterende værdier, bliver ikke håndteret. Medlemmer kan hente deres egen information, men kan ikke ændre den. Administratorer, har fuld CRUD på hold-tabel via brugergrænsefladen, men begrænset på andre tabeller. Prototype kun beregnet til lokal demonstration. Alle databasebrugere er begrænset Der er ikke taget højde for sikkerhedshensyn såsom at hashe strings i programmet. Grundet tidspres i at få en prototype sat op, er der utilstrækkelig observans af objektorientede principper i koden, og afvigelser fra designet. E.g. er der variabler og metoder der ikke burde være public. 5.3 Installationsvejledning - Christian Høgh Pedersen og Rasmus (Christian Høgh Pedersen og Rasmus) Denne installtionsvejledning er udarbejdet med henblik på at gøre databasen og programmet klar til funktionalitetsdemonstration. Der tilføjes derfor noget testdata som ikke nødvendigvis bør være endeligt med. 27

33 5.3.1 Database Vejledning for opsætning af database. Forudsætninger: Installeret MySQL database som kan tilgås som root, eller med rettigheder tilsvarende root. Kør script filen komplet data.sql gennem konsol/cmd (i filens mappe): mysql u root p < komplet data. s q l Listing 5.3: AdminConnector.editHold(), eller benyt en grafisk klient såsom MySQL Workbench. Får du fejl eller behov for at installere database strukturen manuelt, indeholder FSKDBSScripts.zip filer der skal installeres i følgende rækkefølge: 1. CreateDatabase.sql 2. CreateTables.sql 3. CreateViews.sql 4. CreateTriggers.sql 5. CreateUsers.sql 6. CreateStoredProcedures.sql 7. TestData.sql Program Inden programmet kan køres skal det sikres at en korrekt database er sat op, som anført ovenstående og DBMSen (MySQLd) kører. Herudover skal Java (JRE) være 7 (1.7), da der er benyttet funktionalitet i programmet der kun findes i Java (7) 1.7 eksempelvis automatisk garbage-collection og lukning af eksempelvis streams og mulighed for at bruge switch() på en String. Java/JRE skal ydermere være opsat med JDBC udvidelsen, for at kunne forbinde til databaseserveren. Uddybende brugervejledning kan findes i Bilag B. 28

34 Kapitel 6 Test - Christian Høgh Pedersen (Christian Høgh Pedersen) Testing er begrænset til unit/accept tests der kontrollerer resultaterne af programmets funktioner og kommunikation med databasen. Da det endelige resultat af dette projekt er en funktionel database, men med en meget begrænset brugergrænseflade, har vi ikke fundet det traktabelt at have yderligere testforløb. Produktet vil ikke blive implementeret som det ser ud ved projektafslutning, og tidshorisonten taget i betragtning, vil der ikke kunne udføres nyttige korrektioner på baggrund af brugertests. Det i mente har vi kun benyttet os af tests til at sikre at systemets metoder udfører korrekte handlinger. Oprindeligt var der en ambition om at forsøge sig med principperne fra Test Driven Development men grundet tidspres kunne dette ikke følges til bunds. Vi har oprettet unit tests der kontrollerer om systemets funktioner giver forventede returværdier, givet bestemte inputs, og vi har vist at testede klasser fungerer korrekt. 6.1 AdminConnector odenne sektion omhandler unit/acceptesting af klassen AdminConnector, som er implementeret i java-filen AdminConnector.java, testene er at finde i den vedlagte fil AdminConnectorTest.java Testplan Der er foretaget tre planlagte tests: 1. Alting er sat op så test burde lykkes. 2. Databasen er sat forkert op/slukket. Alle tests der involverer en databaseforbindelse burde fejle. 3. Tests udføres med forventning om forkerte resultater. Alle tests burde fejle. Begrænsninger for test: Grundet tidspres er tests der sammenligner resultater af SELECT statements ikke sat op til at sammenligne alle resultaterne. Der sammenlignes kun på første resultat af hvert ResultSet. Dette betyder at der strengt taget kunne være fejl i de andre værdier, men metodens funktionalitet taget i betragtning er det særdeles usandsynligt Testresultater Test 1 se resultater i Figur 6.1. Som det kan ses ud fra disse testresultater, fungerer AdminConnectors metoder korrekt når de gives parametre der burde medføre succes. 29

35 Test 2 se resultater i Figur 6.2. Det kan ses at alle metoder der involverer et kald til databasen fejler. Den eneste metode der kan kaldes er AdminConnector(). Programmet ville teknisk set kunne køre selvom forbindelsen til databasen blev tabt, men da det i skrivende stund ikke har en offline -mode ville det have meget begrænset funktionalitet. Test 3 se resultater i Figur 6.3. Denne test har mere interessante resultater. henthold() fejler når den forsøger at sammenligne værdier der ikke eksisterer i den tabel den henvender sig til. Det samme gør hentmedlemmer(). Men edithold() og slethold(). Giver ikke noget fejlresultat til trods for at deres parametre var fejljusterede i en sådan grad at de var meningsløse. Dette er på den ene side forståeligt; Der returneres kun fejl hvis SQL-statementet ikke kan eksekveres. Men på den anden side betyder det også at der er metoder som det er muligt for brugeren at give forkerte parametre, uden at der er en mulighed for at systemet kan opdage det. Dette vil muligvis være fornuftigt at forbedre i fremtidige udviklingsiterationer. 30

36 Figur 6.1: Resultat af test 1, AdminConnector Figur 6.2: Resultat af test 2, AdminConnector Figur 6.3: Resultat af test 1, AdminConnector 31

37 Kapitel 7 Konklusion - Alle gruppemedlemmer (Alle gruppemedlemmer) Der er udviklet en prototype af programmet til Fightsport Køge, samt scripts der kan sætte en MySQL database op der opfylder kravene fra kunden. Prototypen kan demonstrere forskellige bruger-logins, og begrænset adgang til databasens CRUD-muligheder. Prototypen kan desuden vise begrænset statistik omkring databasens indhold. 7.1 Reflektion Reflektion over processen Tidsmåling Forbrugt tid beregnet som: Skemalagt: 3 timer om ugen per person (5) i 8 uger(før efterårsferie, så kun OOAD-opgaveregningstid plus løs databaseopgaveregningstid). Skemalagt: 8 timer om ugen per person (5) i 4 uger(efter efterårsferien) Desuden er der brugt ca. 50 timer udover den skemalagte. I alt: 330 LoC: Omkring 1367, ikke medregnende GUI. Da der er meget autogenereret kode i den. Dokumentsider: omkring 42, inklusive bilag. Målinger Beregninger Personer i gruppen 5 Persontimer(timer) 66 Use cases, der er implementeret 82.5 analyseklasser svarende til use cases 82.5 Implementerede klasser svarende til analyseklasser 3.5 lines of code(loc) Dokumentsider Udviklingsprocesser - Anna og Rasmus (Anna og Rasmus) I den innledende fase av prosjektet, så er det veldig viktig at hele gruppen enes om om hvordan prosessen skal være fra start til slutt i prosjektet. Dette er viktig så alle i gruppen vet hva som skal lages til et hvert tidspunkt, men også for at man skal unngå misforståelser og oppnå høyest mulig kvalitet. Et gjennomtenkt og planlagt prosessforløp kan også give større produktivitet. 32

38 Det finnes flere forskjellige typer av modeller innfor softwareudvikling. Og før dette kursus har de fleste af os allerede stiftet bekendtskab med udviklingsprocesserne UP (Unified Process) samt XP (Extreme Programming) i tidligere kurser. Begge disse processer er Agile hvor man, altså modsat eksempelvis vandfalds modellen, der man udvikler iterativt og inkrementelt i korte stræk. Vi er i dette kursus blevet præsenteret for processen Scrum både af vores forelæsere men også eksterne talere har advokeret for brugen af Scrum. Scrum er ligeledes en Agil-process og har mange fællesnævnere med de andre metoder. Et (stræk) i Scrum kaldes en Sprint og varierer i længde. Ofte benytter Scrum-teams to eller fire ugers perioder per sprint - Det er oplagt at have flere, eksempelvis to, udgivelser per sprint. Grundlæggende er Scrum meget punktlig omkring dens ceremonier hvilket ofte betyder at udviklingshold der tror de bruger Scrum, ofte ikke gør det, fordi processen er så punktlig. Vi har forsøgt at benytte os af de delelementer vi syntes gav mest mening i vores projekt og har ligeledes fravalgt delelementer vi anså som problematiske i vores gruppe. Eksempelvis har vi fra start valgt ikke at indføre Scrum-rollerne PO (Project Owner) og Scrum-Master i vores gruppe, da vi var under opfattelsen at disse roller ikke helt fungerede efter hensigten i dette prosjektet idet alle skulle ha ansvar for dele af opgaven i både OOAD og database. Derudover var der personer i gruppen der fra ikke ønskede at indtage en lederrolle og derved skabe hieraki/diktatur i gruppen. I retrospekt var dette en utrolig dårlig beslutning der resulterede i at flere medlemmer ofte følte at de ikke havde noget at lave, medmindre der på egen hånd traf en beslutning der potentielt kunne overlappe resten af gruppens arbejde. Vi har fra starten gjort meget brug af pair programming, som er et af kendetegnene ved XP. Pair programming er både elsket og forhadt af mange. Især argumentet men vil I få lavet lige så meget sammen, som hver for sig gør mange brug af - Denne sammenligning er dog ikke gyldig i vores optik, særligt da god kode oftest fylder mindre en dårlig. Større problemstillinger løses oftest også bedre med en sparringspartner. Et hold med en øvet og nybegynder kunne ligeledes lyde kedsommelig (for den øvede) og måske stressende for nybegynderen - denne metode har dog også vist sig at være brugbar både for nybegynder (man lærer åbenlyst meget med fingrende på tastaturet tips i venstre øre) og øvede (man lærer også meget ved at lære fra sig.) Vi har også brukt UML(Unified modelling language), som er et verktøy meget brukt i UP til å strukturere og beskrive det forløp som gjennomgår i utviklingen av et softwaresystem. Vannsfallsmodellen vs UP: I UP kalles fasene for inception, elaboration, construction og transistion, hvor de i vannfallsmodellen kalles requirements, design, implementation, vertification, maintenance. Hovedforskjellen på disse to, er at i UP kan begynne på flere faser samtidig, hvor man i vannfallsmodellen gjør en fase ferdig, før man begynner på den neste. Man pleier derfor å si at i UP så kan man ta høyde for alle de problemer som er ved den tradtionelle vannfallsmodellen. Dette gjør at man i UP kan ta høyde for endringer under, da det er svært å definere alle krav fra begynnelsen. Scrum og XP vs UP: Disse minner litt om hinanden, ved at man her arbeider med flere faser på samme tid. Felles for Scrum og XP er at kunden står sentral i prosessen og er innblandet hele tiden, dog i SCRUM represenrt som en product owner. Scrum skiller seg ut ved at det er bygger meget på cermonier og sprints, og i XP står test og kollektivt eierskap sentralt. Men det som er likt for begge to er at dokumentasjonen er mindre viktig enn i UP der dokumentastion utgjør en stor del av prosessen. Omfattende dokumentasjon kan være meget tidskrevende, noe som kan være negativt om man tenker på at time is money, men dokumentasjon kan også spare masse tid ved at de kan gjøre det nemmere å identifisere problemet dersom det oppstår problemer/feil. Scrum og XP egner seg til små prosjekter, mens UP er god i store prosjekter Gruppearbejde Der har været problemer med at koordinere gruppearbejdet, og uddelegere opgaver mellem medlemmer. Vi har haft problemer med at den udarbejdede arbejdskontrakt ikke blev respekteret, og ikke blev håndhævet. 33

39 Vi har forsøgt os med forskellige softwareværktøjer, eksempelvis [5] til at styrke gruppens evne til at koordinere sit arbejde, men der har det til trods været tilbagevendende problemer med at gruppemedlemmer ikke har kommunikeret, eller undladt at udføre opgaver de havde påtaget sig. Under forløbet har vi gjort brug af værktøjerne SVN og Google Drive til at samle vores arbejde og for at være opdateret konstant. Google Drive fungerer som et online samlingssted for office dokumenter som alle kan redigere i samtidig. I vores tilfælde har det været brugt som et samlingssted for notater og ideas-pitching inden SVN blev taget i brug under udformningen af rapporten. SubVersion er et program brugt til at udføre versions og revisions kontrol af kode. Programmet er især brugbart til at holde styr på kode og lade flere personer arbejde på dele af programmer for derefter at føre dem sammen(merge) delene. Fordelen ved brugen af det, er at hvis der opstår fejl i koden er det muligt at føre koden tilbage til et tidligere tidspunkt, fx. hvis man støder på uforudsete problemer man ikke kan løse. Ligeledes er det en god mulighed for at man kan se hvem der har tilføjet til et program og referere til personen hvis man har problemer med koden. I vores tilfælde gjorde vi brug af TortoiseSVN da vi tidligere har arbejdet med det på andet semester og derfor var bekendte med det. Vi gjorde dog ikke brug af det før end midten af forløbet da vi begyndte at kode programmet og under rapportskrivningen viste det sig meget nyttigt da der var mulighed for at arbejde samtidig i Latex. 7.2 Videre udvikling - Christian Høgh Pedersen Der mangler dele af funktionaliteten for nogle af programmets klasser. Admin-klassegruppen har e.g. kun fuld CRUD på databasens hold-tabel via programmet. Denne skal udvides til hele databasen. Medlemmer kan kun læse deres personlige information gennem programmet. De skal desuden have adgang til holdtilmelding, lektiontilmelding, mulighed for at se deres betalinger og mulighed for at ændre deres personlige information. Ansat/Træner klassegrupperne har ingen funktionalitet udover mulighed for at logge ind. Desuden gælder det generelt at der skal gøres overvejelser omkring brugergrænsefladen, for at gøre den til noget der er virkelig brugbart. Data-adgang og login bør muligvis splittes op i forskellige databaser, af sikkerhedshensyn. Desuden vil det være nødvendigt at oprette et serversystem der kan bruges til at implementere den mere vidtrækkende ønskede funktion. Eksempelvis et beskedsystem der sender medlemmer beskeder omkring betaling hver måned. Java-programmet vil blive erstattet af en web-baseret løsning når vi overdrager projektet til Noke ApS. 34

40 Litteratur [1] Fightsport Koege. Mma, muay thai og brasiliansk jiu-jitsu i fightsport kã ge, November [2] Noke Aps. Virtualisering, hosting og outsourcing, November [3] Thomas Connoly and Carolyn Begg. Database Systems: A Practical Approach to Design, Implementation and Management. Pearson Education Inc., fifth edition, [4] Abraham Silberschatz, Henry F. Korth, and S. Sudarshan. Database System Concepts. McGraw-Hill, sixth edition, [5] Trello. Trello, November

41 Bilag A Analyse i dette bilag er der listet ting fra analyse-kapitlet, som ikke er relevant nok til at have i selve afsnittet. Figur A.1: Rigt billede - medlem ønsker å finde oplysninger om hold, træner og lokale på FSK nettside. 36

42 Bilag B Brugervejledning Vejledning for brug af prototype. Det forudsættes at databasen kører. Filen FSKclient.jar kan placeres et vilkårligt sted. Ved dobbeltklik startes den grafikse brugergrænseflade. Alternativt kan programmet også køres fra konsol/cmd med kommandoen: java j a r FSKclient. j a r Listing B.1: Kør program fra konsol/cmd B.1 Brugere Der eksisterer effektivt set en bruger for hvert medlem, ansat, træner og administrator registreret i databasen, herunder er eksempler på gyldige login: Admin: 3/kode Træner: 2/kode Ansat: 7/kode Medlem: /kode B.2 Administrator Herunder er der en række opgaver administratoren kan udføre, og hvordan de udføres. Se medlemmers info: 1. Kør FSKclient.jar, enten dobbelt klik med mus, eller gennem konsol. 2. Skriv id/password i de relevante felter og tryk OK. Se Figur B.1 3. Vælg fanen medlemmer i det åbnede vindue. Se Figur B.2. Figur B.1: Prototypens loginside Se hold: 1. Kør FSKclient.jar 2. Skriv id/password i de relevante felter og tryk OK 3. Vælg fanen Hold i det åbnede vindue. Se Figur B.3. 37

43 Figur B.2: Prototypens medlemsvisning efter administratorlogin. Figur B.3: Prototypens holdvisning efter administratorlogin. Figur B.4: Prototypens opret hold dialog 38

44 Figur B.5: Prototypens slet hold dialog Figur B.6: Prototypens edit hold dialog Opret hold: 1. Udfør trin 1-3 for Se hold 2. Klik på Opret Hold 3. Skriv ønsket information i felterne i det åbnede vindue. Se Figur B Tryk Gem Hold Slet hold: 1. Udfør trin 1-3 for Se hold 2. Klik på Slet Hold 3. Skriv holdid for det hold der ønskes slettet i det åbnede vindue. Se Figur B.5 4. Tryk Slet Hold 39

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

WISEflow Guide til deltagere

WISEflow Guide til deltagere WISEflow Guide til deltagere Version 2.8.0 1 Indhold Deltager: Sådan kommer du i gang... 3 Opsætning af profil... 3 Flow-oversigt... 6 Flow-typer... 7 Flowets tilstand... 7 Hvordan afleverer jeg min besvarelse?...

Læs mere

Sådan bruger du Facebook

Sådan bruger du Facebook Sådan bruger du Facebook 1 Sådan kommer du på Facebook 2 Oprettelse af en Facebook-profil 3 Opsætte privatindstillinger, så kun venner kan følge med 4 Søge efter venner og bekendte 5 Skrive beskeder både

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

Indhold. Side 2 af 26

Indhold. Side 2 af 26 Tema Design Design, Programmering og test af Adressebog Fra d. 17 april til 20 april 2012 Vejledere: Gunhild Marie Andersen Kis Boisen Hansen Gruppe B Deltagere Side 1 af 26 Indhold Indledning.... 3 Kodestandard...

Læs mere

Brugermanual til Assignment hand in

Brugermanual til Assignment hand in Brugermanual til Assignment hand in Indhold: Undervisere:...2 Hvor finder jeg Assignment hand in?...2 Opret en opgave...4 Slet en opgave...5 Rediger en opgave...5 Hvor finder jeg de afleverede filer?...5

Læs mere

Lavet af Danni jensen og David Olsen

Lavet af Danni jensen og David Olsen Projekt Delfin Lavet af Danni jensen og David Olsen 19/5-2008 Indholdsfortegnelse. Side 1: Indholdsfortegnelse og forord. Side 2: Kravsliste. Side 3: Use Case Model. Side 4: Formandens aktørbeskrivelse

Læs mere

Skriftlig eksamen i kurset. Informationssystemer

Skriftlig eksamen i kurset. Informationssystemer 6. semester sundhedsteknologi Skriftlig eksamen i kurset Informationssystemer Der er 3 timer til at besvare opgaven. Alle hjælpemidler er tilladte. Skriv kort og præcist. Referer gerne til kursuslitteraturen.

Læs mere

Nyt i SkoleIntra 5.10

Nyt i SkoleIntra 5.10 Nyt i SkoleIntra 5.10 Sidst ændret den 13 10 2015 Ny loginside Med SkoleIntra 5.10 introduceres et nyt fælles login, som giver single sign on mellem det nye SkoleIntra, det klassiske SkoleIntra og itslearnings

Læs mere

GUIDE FOR BRUG AF SPORTI s MEDLEMSDATABASE NORGE. SPORTI Tarp Byvej Esbjerg N 1

GUIDE FOR BRUG AF SPORTI s MEDLEMSDATABASE NORGE. SPORTI Tarp Byvej Esbjerg N  1 GUIDE FOR BRUG AF SPORTI s MEDLEMSDATABASE NORGE Udarbejdet af Martin Skov, november 2015 1 Indhold Generelt om SPORTI s medlemsdatabase i Norge... 3 Profiler... 3 Data i medlemsdatabasen... 3 Medlemsnumre...

Læs mere

EVALUERING I SURVEYXACT TRIN FOR TRIN

EVALUERING I SURVEYXACT TRIN FOR TRIN EVALUERING I SURVEYXACT TRIN FOR TRIN LÆR AT TACKLE 2015 KOMITEEN FOR SUNDHEDSOPLYSNING 1 INDLEDNING Komiteen for Sundhedsoplysning stiller SurveyXact et internetbaseret redskab til kvalitetssikring til

Læs mere

Vejledning til prækvalifikation. Rev.: 2015-05-27 / LW. Side 1

Vejledning til prækvalifikation. Rev.: 2015-05-27 / LW. Side 1 Vejledning til prækvalifikation Rev.: 2015-05-27 / LW Side 1 Indhold Indhold... 2 Indledning... 3 Log på... 4 Opret din bruger... 4 Personlige informationer... 4 Gem login... 5 Glemt password... 5 Brugerfladen

Læs mere

Guide til medlemskartoteket

Guide til medlemskartoteket Guide til medlemskartoteket Bliv klogere på Í Redigerer af foreningens medlemmer Í Oprettelse af nye medlemmer Í Udtræk af medlemslister Í Registrering af ansvarsområder Í Indberetning Í Kontingentsatser

Læs mere

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen.

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen. Copenhagen Business Academy Multimediedesigner 3. semester - 1. projekt, september 2014 Gruppe 1 - MulA Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen. Study: Multimedia Design Project:

Læs mere

Obligatorisk opgave i objektorienteret analyse og design

Obligatorisk opgave i objektorienteret analyse og design Obligatorisk SD-opgave s. Obligatorisk opgave i objektorienteret analyse og design Løs følgende, som en indviduel opgave. I må gerne samarbejde i grupper, men alle har ansvar for at udfærdige sin egen

Læs mere

FSFI s guide til DFR s elektronisk bevissystem

FSFI s guide til DFR s elektronisk bevissystem FSFI s guide til DFR s elektronisk bevissystem Dette er en kort guide i anvendelsen af Dansk Førstehjælpsråd elektroniske bevissystem. Guiden viser og forklarer, hvordan du som instruktør og medlem af

Læs mere

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen.

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen. Copenhagen Business Academy Multimediedesigner 3. semester - 1. projekt, september 2014 Gruppe 1 - MulA Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen. Study: Multimedia Design Project:

Læs mere

Indholdsfortegnelse for kapitel 3

Indholdsfortegnelse for kapitel 3 Indholdsfortegnelse for kapitel 3 Kapitel 3 Design............................................................ 2 Database........................................................... 3 ER-diagram.................................................

Læs mere

My booking. Generelt. Forsiden. Version 9.0

My booking. Generelt. Forsiden. Version 9.0 My booking Version 9.0 System til at lave online bookinger, med mulighed for opdeling i grupper, forskellige booking typer, ændre layout indstillinger, status styring, sprogvalg samt en del mere, detaljer

Læs mere

Velkommen til OnReg Agent.

Velkommen til OnReg Agent. Velkommen til OnReg Agent. 2 OnReg Agent Velkommen til Onreg Agent Du er blevet tildelt brugernavn og kodeord til OnReg Agent. Denne guide beskriver hvordan du benytter systemet. Hvis arrangøren tillader

Læs mere

Dynamicweb Quickguide

Dynamicweb Quickguide Brugervejledning Dynamicweb Quickguide Version: 1.1 2012.03.15 Dansk JURIDISK MEDDELELSE Copyright 2012 Dynamicweb Software A/S. Alle rettigheder forbeholdes. Dette dokument eller dele heraf må på ingen

Læs mere

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE Fact sheet Indholdsfortegnelse Fact Sheet Gantt kort Valgt af virksomhed Brainstorm Attribut tabel ER-diagram Skitse MySQLWorkbench

Læs mere

Databaseadgang fra Java

Databaseadgang fra Java Databaseadgang fra Java Grundlæggende Programmering med Projekt Peter Sestoft Fredag 2007-11-23 Relationsdatabasesystemer Der er mange databaseservere Microsoft Access del af Microsoft Office MySQL god,

Læs mere

Spiller / Pårørende manual Til www.kampseddel.dk

Spiller / Pårørende manual Til www.kampseddel.dk Spiller / Pårørende manual Til www.kampseddel.dk Brugervejledning for Spiller/Pårørende Kort om kampseddel.dk Kampseddel.dk er udarbejdet som et webbaseret værktøj til den frivillige Træner/Leder i en

Læs mere

DATABASE Projekt 1-3. semester

DATABASE Projekt 1-3. semester DATABASE Projekt 1-3. semester Gruppe 2- CLmul-a12e Projekt URL http://www.lucasperch.dk/projekter/database.pdf Gruppe 2 Lucas Perch-Nielsen cph-lp14@cphbusiness.dk http://lucasperch.dk/skole.php Niclas

Læs mere

Katrines Kælder Kasseapparat

Katrines Kælder Kasseapparat Katrines Kælder Kasseapparat Projektdokumentation Aarhus Universitet Gruppe 4-4. Semester - E15 Vejleder: Lars Mortensen Dato 11-09-2015 David Heilesen Danielewicz - 201400148 - IKT Kalle Rønlev Møller

Læs mere

EVALUERING I SURVEYXACT TRIN FOR TRIN

EVALUERING I SURVEYXACT TRIN FOR TRIN EVALUERING I SURVEYXACT TRIN FOR TRIN LÆR AT TACKLE 2015 KOMITEEN FOR SUNDHEDSOPLYSNING 1 INDLEDNING Komiteen for Sundhedsoplysning stiller SurveyXact et internetbaseret redskab til kvalitetssikring til

Læs mere

Startpakke**: kr. 1.500,- Licens: kr. 0,-

Startpakke**: kr. 1.500,- Licens: kr. 0,- Kontingentsystem med ClubPeople ClubPeople tilbyder nu klubberne et integreret kontingentsystem. Kontingentsystemet sikrer, at du som klubansvarlig kan få overblik over dine medlemmers betalinger og restancer.

Læs mere

Bruger v1.5 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk

Bruger v1.5 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk Bruger v1.5 QUICK GUIDE Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk INTRODUKTION TIL REKVI-SKOLE Ideen med Rekvi-skole systemet udsprang fra et behov

Læs mere

Generel projektbeskrivelse

Generel projektbeskrivelse 02121 Ingeniørarbejde Softwareteknologi Januar 2010 1 Introduktion Generel projektbeskrivelse Formålet med programmeringsprojektet er at give deltagerne erfaring med at designe og konstruere et simpelt

Læs mere

4 diaphoni.dk/version 2.2 - opdateret 24.3.2014

4 diaphoni.dk/version 2.2 - opdateret 24.3.2014 Brugervejledning for aftenskoler - oprettelse af stamdata, aftenskolehold og undervisningssteder MANUAL 1 3 2 4 diaphoni.dk/version 2.2 - opdateret 24.3.2014 intro! Hjemmesiden aftenskole.nu giver borgerne

Læs mere

Vejledning i brug af system til online indberetning af mønstringsdata

Vejledning i brug af system til online indberetning af mønstringsdata Vejledning i brug af system til online indberetning af mønstringsdata Søfartsstyrelsen kan tilbyde samtlige rederier mulighed for at kunne indberette mønstringsdata elektronisk. Den elektroniske indberetning

Læs mere

Eksempel: et ordresystem note 5 Lagdeling s. 1

Eksempel: et ordresystem note 5 Lagdeling s. 1 Eksempel: et ordresystem note 5 Lagdeling s. 1 Eksempel: et ordre-system NiceHair er et firma, som sælger udstyr, inventar og frisørartikler til frisørsaloner over hele landet. Det er ejet af et ægtepar

Læs mere

Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge.

Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge. Danmarks Statistik, Velfærd 22. januar 203 Børn og Unge, Udsatte børn Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge. Indhold Baggrund...2 2 Formål...2

Læs mere

Web Admin 5.5. Brugsvejledning for Domain admin. Copyright 2003 Gullestrup.net

Web Admin 5.5. Brugsvejledning for Domain admin. Copyright 2003 Gullestrup.net Web Admin 5.5 Copyright 2003 Gullestrup.net Log ind på systemet Start med at gå ind på http://mailadmin.gullestrup.net i din browser. Indtast din Email Adresse samt Password, som du tidligere har modtaget

Læs mere

Projekt Database, Gruppe 4A. Projekt 1, 3. Semester D A T A B A S E. Klasse MulA13 Gruppenummer: A4

Projekt Database, Gruppe 4A. Projekt 1, 3. Semester D A T A B A S E. Klasse MulA13 Gruppenummer: A4 Projekt Database, Gruppe 4A 0 Projekt 1, 3. Semester D A T A B A S E Klasse MulA13 Gruppenummer: A4 Projekt Database, Gruppe 4A 1 Fakta-ark Klasse MulA13, Gruppenummer: A4 Gruppemedlemmer: Amalie Ardahl

Læs mere

TESTPORTAL: BRUGERVEJLEDNING LOG IND ADGANGSKODE

TESTPORTAL: BRUGERVEJLEDNING LOG IND ADGANGSKODE TESTPORTAL: BRUGERVEJLEDNING LOG IND Testportalen befinder sig på internetadressen http://www.testportal.hogrefe.dk/default.aspx. På denne adresse mødes man af ovenstående skærmbillede. Indtast her dit

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

FSFIs lynguide til DFRs elektronisk bevissystem

FSFIs lynguide til DFRs elektronisk bevissystem FSFIs lynguide til DFRs elektronisk bevissystem Dette er en kort guide i anvendelsen af Dansk Førstehjælpsråd elektroniske bevissystem. Guiden viser og forklarer hvordan du som instruktør og medlem af

Læs mere

Indhold 1 Om Skolekvalitet.dk...3. 2 Vælg evalueringsmodel før du går i gang...3. 3 Overblik over siderne... 5

Indhold 1 Om Skolekvalitet.dk...3. 2 Vælg evalueringsmodel før du går i gang...3. 3 Overblik over siderne... 5 Skolekvalitet.dk Manual Version 1.0 Indhold 1 Om Skolekvalitet.dk...3 2 Vælg evalueringsmodel før du går i gang...3 3 Overblik over siderne... 5 3.1 Oversigt over centrale funktioner:... 6 4 Kom godt i

Læs mere

CLmul-b14e Gruppe 2 2. Database projekt

CLmul-b14e Gruppe 2 2. Database projekt 1 2 CLmul-b14e Gruppe 2 2. Database projekt JONAS FALK sniller27@hotmail.com Projekt vejledere Ivan Rosenvinge Frederiksen CHRISTIAN BRAMS halkjaer-brams@hotmail.com Tue Becher LINE RASMUSSEN line-rasmussen@live.com

Læs mere

Conventus og SFGIF Hvordan opretter jeg en ny træner?

Conventus og SFGIF Hvordan opretter jeg en ny træner? Kaj Heydt 18-09- INDHOLDSFORTEGNELSE LOG IND I CONVENTUS... 3 TRÆNEREN ER OPRETTET I CONVENTUS MEN HAR INGEN RETTIGHEDER... 4 TRÆNEREN ER IKKE OPRETTET I CONVENTUS... 10 TRÆNEREN KNYTTES / FJERNES FRA

Læs mere

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh Databasesystemer, forår 2005 IT Universitetet i København Forelæsning 3: E-R modellering 17. februar 2005 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvornår, hvorfor og hvordan? Business

Læs mere

Systemair Connect. Opsætning

Systemair Connect. Opsætning Systemair Connect Opsætning Opsætning af Systemair Connect Denne vejledning er lavet for at hjælpe dig i gang med opsætningen af Systemair Connect. Du kan bl.a. læse om, hvordan du opbygger en understruktur

Læs mere

INSTRUKTIONSMANUAL FOR SPILLERE OG FORÆLDRE TIL HIFEREN

INSTRUKTIONSMANUAL FOR SPILLERE OG FORÆLDRE TIL HIFEREN INSTRUKTIONSMANUAL FOR SPILLERE OG FORÆLDRE TIL HIFEREN Hjallerup Idrætsforening har fået ny hjemmeside. Dette har betydning for dig som bruger/medlem af HIF og som forældre til børn, der er bruger/medlem

Læs mere

GUIDE Oprettelse og administration af Stævne annoncer og tilmeldinger på Staevner.dk

GUIDE Oprettelse og administration af Stævne annoncer og tilmeldinger på Staevner.dk GUIDE Oprettelse og administration af Stævne annoncer og tilmeldinger på Staevner.dk 02. april 2009 1 Staevner.dk Log ind Brug den nye log ind boks øverst på siden til at logge ind på siden. Bruger navn/email

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

Vejledning til de bydende

Vejledning til de bydende Vejledning til de bydende Juni 2013/JET Indledning Indledning ibinder er et web-baseret program, til håndtering af byggeprojekter og ejendomsdrift på en hidtil uset brugervenlig og økonomisk måde. ibinder

Læs mere

Database. Pr jekt. Hold CLmul-a14e Gruppe 3 3. semester 2015. Vejledere: Tue Becher Ivan R. Frederiksen

Database. Pr jekt. Hold CLmul-a14e Gruppe 3 3. semester 2015. Vejledere: Tue Becher Ivan R. Frederiksen Database Pr jekt Hold CLmul-a14e Gruppe 3 3. semester 2015 Vejledere: Tue Becher Ivan R. Frederiksen Indholdsfortegnelse 1. Problemformulering 2. ER-diagram 3. Attribut-tabel 4. Use Case-model 5. Use Case

Læs mere

Bruger (kursist/deltager) Kom godt i gang med plan2learn. Version 0.01 Versionslog: 0.01

Bruger (kursist/deltager) Kom godt i gang med plan2learn. Version 0.01 Versionslog: 0.01 Bruger (kursist/deltager) Kom godt i gang med plan2learn Version 0.01 Versionslog: 0.01 1 Oprettet: 01.08.2014 Indhold 1. Formål med vejledningen...3 2. Katalogforsiden...4 2.1 Brugeradgang...5 2.2 Skift

Læs mere

Nyt i SkoleIntra 5.10

Nyt i SkoleIntra 5.10 Nyt i SkoleIntra 5.10 Sidst ændret den 18 09 2015 Ny version af editor SkoleIntra benytter som bekendt en editor ved navn CKeditor til online redigering af tekster. I SkoleIntra 5.10.0 opdateres editor

Læs mere

FORCE Inspect Online Manual v. 1.02. FORCE Inspect Online Manual. 1 af 18

FORCE Inspect Online Manual v. 1.02. FORCE Inspect Online Manual. 1 af 18 FORCE Inspect Online Manual 1 af 18 Indholdsfortegnelse Indholdsfortegnelse... 2 FORCE Inspect Online Manual... 3 Generelt... 3 Login... 3 Main... 4 Intro sektion... 4 Links sektion... 4 News sektion...

Læs mere

Vejledning til bydende. Rev.: 2015-05-27 / LW. Side 1

Vejledning til bydende. Rev.: 2015-05-27 / LW. Side 1 Vejledning til bydende Rev.: 2015-05-27 / LW Side 1 Indhold Indhold... 2 Indledning... 3 Log på... 4 Opret din bruger... 4 Personlige informationer... 4 Gem login... 5 Glemt password... 5 Brugerfladen

Læs mere

Introduktion. Pacsoft Online 11-11-2013

Introduktion. Pacsoft Online 11-11-2013 Introduktion Pacsoft Online 11-11-2013 2 Indhold 1 Introduktion til Pacsoft Online... 3 1.1 Grundlæggende navigering... 3 1.2 Søgning af information... 3 1.3 Indtastning af faste oplysninger... 4 1.4 Din

Læs mere

Vejledning til. Svejsevisitering. Oprettelse af kursister i testsystemet... 2. Opret Booking... 5. Kursisten tager test... 10

Vejledning til. Svejsevisitering. Oprettelse af kursister i testsystemet... 2. Opret Booking... 5. Kursisten tager test... 10 Kompetencecenter for e-læring Det Nationale Videncenter for e-læring Vejledning til Svejsevisitering Indhold Oprettelse af kursister i testsystemet... 2 Opret Booking... 5 Kursisten tager test... 10 Læreren

Læs mere

Vejledning i brug af BadmintonPeople.dk

Vejledning i brug af BadmintonPeople.dk Vejledning i brug af BadmintonPeople.dk Læs grundigt denne vejledning igennem. BadmintonPeople.dk er skabt igennem et samarbejde imellem DGI og DBF. Meningen er at lette klubbernes ledere, administratorer

Læs mere

Website Redaktør - Brugermanual version Zonta District 13, Area 01, 02, 03 og 04 inkl. klubber

Website Redaktør - Brugermanual version Zonta District 13, Area 01, 02, 03 og 04 inkl. klubber Website Redaktør - Brugermanual version 3 11.01.2017 Zonta District 13, Area 01, 02, 03 og 04 inkl. klubber Indhold: 1. Login på redaktørside 2 2. Første login som redaktør 3 3. Login fremover 7 4. Ændring

Læs mere

Web Admin 5.5. Brugsvejledning for User admin. Copyright 2003 Gullestrup.net

Web Admin 5.5. Brugsvejledning for User admin. Copyright 2003 Gullestrup.net Web Admin 5.5 Copyright 2003 Gullestrup.net Log ind på systemet Start med at gå ind på http://mailadmin.gullestrup.net i din browser. Indtast din Email Adresse samt Password, som hører til din konto, tryk

Læs mere

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 -

Indholdsfortegnelse. Hvorfor skal jeg tage backup af min blog? Side 3. Tag backup med UpDraft Side 4. Tag manuelt backup Side 8 - 2 - - 1 - Indholdsfortegnelse Hvorfor skal jeg tage backup af min blog? Side 3 Tag backup med UpDraft Side 4 Tag manuelt backup Side 8-2 - Hvorfor skal jeg tage backup af min blog? Lige meget om du har opbygget

Læs mere

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4 Maskine Udlejning 15. oktober 2010 Jacob Weng, Jeppe Boese og Mads Anthony Roskilde Tekniske Gymnasium Udlejningsvirksomhed 3.4 Indholdsfortegnelse Problemformulering:... 2 Planlægning:... 2 Analyse af

Læs mere

Brugervejledning til Online-JitBesked. Version 1.2

Brugervejledning til Online-JitBesked. Version 1.2 Brugervejledning til Online-JitBesked Version 1.2 Indhold 1. Helt grundlæggende... 4 Ikoner... 4 2. Sådan logger du på... 6 Husk mig... 6 3. Sådan logger du af... 7 Husk mig... 7 Sådan logger du aktivt

Læs mere

Hvad er en relationsdatabase? Odense, den 19. januar Version 1.0

Hvad er en relationsdatabase? Odense, den 19. januar Version 1.0 Hvad er en relationsdatabase? Odense, den 19 januar 2004 Version 10 Program for 6 kursusdag: Databaser 0900-0945 Hvad er en relationsdatabase? -1045 Opgave om normalisering 1100-1145 Eksempel på database

Læs mere

Vejledning til BadmintonPeople

Vejledning til BadmintonPeople Herunder følger en vejledning i hvordan man kommer i gang med BadmintonPeople til stævnetilmeldinger. 1. Opret bruger Hvis du har fået en invitation tilsendt fra klubben gå da direkte til pkt. 1.b. 1.a.

Læs mere

Indholdsfortegnelse for kapitel 2

Indholdsfortegnelse for kapitel 2 Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database.................................................

Læs mere

My Shop. Funktioner, oversigt: Kom i gang: Online shop system

My Shop. Funktioner, oversigt: Kom i gang: Online shop system My Shop Online shop system Infusion name: My_Shop Ajax baseret, online SHOP system Vejledning til installation og brug -------------------------------------------------------- Author: Egon Jessen, webmaster@myphp.dk

Læs mere

Introduktion. Unifaun Online 29-04-2014

Introduktion. Unifaun Online 29-04-2014 Introduktion Unifaun Online 29-04-2014 2 Indhold 1 Introduktion til Unifaun Online... 3 1.1 Grundlæggende navigering... 3 1.2 Søgning af information... 3 1.3 Indtastning af faste oplysninger... 4 1.4 Din

Læs mere

Smart-ebizz Manual til Bookinsystem Indholdsfortegnelse Kom hurtigt i gang med dit booking system:... 3 Overblikket over dit bookingsystem... 4 Hovedside... 4 Kunder... 4 Opret ny Kunde... 4 Vagtplaner...

Læs mere

Database. lv/

Database. lv/ Database 1 Database Design Begreber 1 Database: En fælles samling af logiske relaterede data (informationer) DBMS (database management system) Et SW system der gør det muligt at definer, oprette og vedligeholde

Læs mere

Udeblivelse.dk Introduktion

Udeblivelse.dk Introduktion Udeblivelse.dk Introduktion 26 JANUAR 2015 Copyright 2014-2015, Udeblivelse Aps, Web: www.udeblivelse.dk, Email: info@udeblivelse.dk Indledning:... 2 Login... 3 Opret Klinik... 4 1. Administrator... 4

Læs mere

ONE BUSINESS - ONE APP BRUGER MANUAL

ONE BUSINESS - ONE APP BRUGER MANUAL ONE BUSINESS - ONE APP BRUGER MANUAL 1 INDHOLDSFORTEGNELSE KOM I GANG MED SHOPBOX OPRET EN PROFIL 4 OPRET EN BUTIK 4 STARTSIDE 5 HVORDAN DU OPRETTER, REDIGERER OG SLETTER PRODUKTER OG KATEGORIER 6 OPRET

Læs mere

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO...

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO... INDHOLDSFORTEGNELSE INDLEDNING... 7 Kristian Langborg-Hansen KAPITEL ET... 9 I gang med App Inventor Installation af App Inventor... 10 Trådløs installation... 11 Installation af emulator (Windows)...

Læs mere

Vejledning til. DUI-LEG og VIRKEs

Vejledning til. DUI-LEG og VIRKEs Vejledning til DUI-LEG og VIRKEs Medlemssystem version 1.0 Opdateret 1. november 2009 Indholdsfortegnelse Sådan får du en kode til systemet...3 Sådan logger du ind på systemet...3 Forsiden og ændring af

Læs mere

ViKoSys. Virksomheds Kontakt System

ViKoSys. Virksomheds Kontakt System ViKoSys Virksomheds Kontakt System 1 Hvad er det? Virksomheds Kontakt System er udviklet som et hjælpeværkstøj til iværksættere og andre virksomheder som gerne vil have et værktøj hvor de kan finde og

Læs mere

Brugervejledning til DHF's onlinesystem

Brugervejledning til DHF's onlinesystem Brugervejledning til DHF's onlinesystem Indholdsfortegnelse Oprette ny bruger 2 Login 4 Oprettelse af arrangement 5 Rettelse af arrangementsdata 7 Tilmelding på lukket liste 8 Deltagerliste 13 Ændre deltagerdata

Læs mere

Efteruddannelse.dk. Marianne Guerry Larsen

Efteruddannelse.dk. Marianne Guerry Larsen Efteruddannelse.dk Marianne Guerry Larsen Handler om administrativ lettelse på skolerne CPP1 Dias nummer 2 CPP1 [..]kommunikation MED kursisterne [..] Christina P. Bach Pedersen; 16-09-2009 3 faser Test

Læs mere

DNOR (Dansk Neuro Onkologisk Register) Brugervejledning til KMS

DNOR (Dansk Neuro Onkologisk Register) Brugervejledning til KMS 1 DNOR (Dansk Neuro Onkologisk Register) Brugervejledning til KMS Man kommer ind i KMS systemet til dataindberetning ved at skrive adressen http://nip.medcom/kms eller http://195.80.243.98/kms i sin browser.

Læs mere

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...

Læs mere

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag Hvem er vi? Kursus Introduktion Anne Haxthausen ah@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark 100 studerende med forskellig baggrund: software teknologi It og Kom

Læs mere

Introduktion til frontend

Introduktion til frontend Side 1 af 43 Introduktion til frontend Dette dokument beskriver kort, hvordan du bruger WeroShop frontend. Dette omfatter at sætte dig ind i varegrupper, producenter og produkter, filtrering af produkter,

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

DANSK SKOLEDATA APS. Tlf. 86 44 80 99 E-mail DSD@skoledata.dk DSA-Ventelisten

DANSK SKOLEDATA APS. Tlf. 86 44 80 99 E-mail DSD@skoledata.dk DSA-Ventelisten Indholdsfortegnelse Overordnet beskrivelse af programmets funktioner... 2 Log på... 2 Manuel oprettelse af elev.... 3 Optagelse af elever... 3 1 Gruppering og sortering af elever... 3 2 Udvælg aspiranter...

Læs mere

Vejledning til online blanketten Industriens salg af varer

Vejledning til online blanketten Industriens salg af varer Vejledning til online blanketten Industriens salg af varer Din vej gennem blanketten Her er en kort vejledning om hvordan du udfylder online blanketten trin for trin. Har du spørgsmål, er du velkommen

Læs mere

Erfaringer med CPR-replikering

Erfaringer med CPR-replikering Erfaringer med CPR-replikering Dette dokument beskriver en række overvejelser vi har gjort os i forbindelse med at vi har udviklet en Proof of Concept (PoC) af en CPR-replikeringstjeneste for KOMBIT. CPRs

Læs mere

Elevadministrations modulet. Brugervejledning Optagelse.dk

Elevadministrations modulet. Brugervejledning Optagelse.dk Elevadministrations modulet Brugervejledning Optagelse.dk Elevadministrations modulet Brugervejledning Optagelse.dk Forfatter: Tine Kanne Sørensen UNI C UNI C, 19.12.2013 Indhold 1 Indledning... 5 1.1

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539)

ITWIN1. Afsluttende projekt. PhotoDays. Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 Afsluttende projekt PhotoDays Benjamin Sørensen (02284) Tomas Stæhr Berg (03539) ITWIN1 - AFSLUTTENDE PROJEKT PhotoDays Benjamin Sørensen & Tomas Stæhr Berg 02284 & 03539 1 1 Underskrifter Rapporten

Læs mere

Vejledning til Kilometer Registrering

Vejledning til Kilometer Registrering Vejledning til Kilometer Registrering iphone Appen som holder styr på dit firma og privat kørsel. Udviklet af Trisect Development 2011. www.trisect.dk For iphone version 4.2 og nyere. Med Kilometer Registrering

Læs mere

Prøveeksempler 2012. ClinicCare. Web

Prøveeksempler 2012. ClinicCare. Web ClinicCare Web Prøveeksempler 2012 Hvem er ClinicCare? ClinicCare udvikles af firmaet Novolog, som siden 1995 har udviklet systemer til sundhedssektoren. Over 900 klinikker anvender idag ClinicCare. Det

Læs mere

Brugervejledning Digital Post for administratorer

Brugervejledning Digital Post for administratorer Brugervejledning Digital Post for administratorer 1. Login Login til administrationsmodulet i Digital Post sker via Admin -knappen på forsiden. I login-billedet tastes det opgivne brugernavn og adgangskode

Læs mere

09/03 2009 Version 1.4 Side 1 af 37

09/03 2009 Version 1.4 Side 1 af 37 Login til DJAS Gå ind på adressen http://www.djas.dk I feltet Brugernavn skrives den e-mail adresse som brugeren er registeret med i systemet. I feltet Password skrives brugerens adgangskode. Ved at sætte

Læs mere

GeckoBooking.dk V. 2.7 - Online kalender og bookingsystem

GeckoBooking.dk V. 2.7 - Online kalender og bookingsystem 1. Login... 2 2. Administrationens opbygning... 2 3. Kalendere... 3 3.1 Ret arbejdstid... 3 3.2 Kalender oversigt... 4 3.2.1 Månedskalender... 5 3.2.2 Uge kalender... 5 3.2.3 Dagskalender... 6 3.2.4. Bookning

Læs mere

Hjælp til MV-ID Administration

Hjælp til MV-ID Administration Hjælp til MV-ID Administration - til brugere af MV-Login Mikro Værkstedet A/S Dokumentversion: 20131002A 1 Indholdsfortegnelse Forord... 3 Kapitel 1. Aktivér MV-Login administratorkontoen... 4 Kapitel

Læs mere

MANUAL. Præsentation af Temperaturloggerdata. Version 2.0

MANUAL. Præsentation af Temperaturloggerdata. Version 2.0 MANUAL Præsentation af Temperaturloggerdata Version 2.0 Indholdsfortegnelse FORORD...3 INTRODUKTION...3 KRAV OG FORUDSÆTNINGER...3 INSTALLATION...4 OPSÆTNING...8 PROGRAMOVERBLIK...10 PROGRAMKØRSEL...11

Læs mere

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW - BRUGER-GUIDE -

SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW - BRUGER-GUIDE - SDBF QUICKGUIDE SKOLERNES DIGITALE BLANKET FLOW - BRUGER-GUIDE - INTRODUKTION TIL SKOLERNES DIGITALE BLANKET FLOW Som et udspring af de administrative fællesskaber og et ønske om at effektivisere og digitalisere

Læs mere

Vejledning til Klubadministratorer

Vejledning til Klubadministratorer Vejledning til Klubadministratorer til vedligeholdelse af klub- og medlemsinformationer Følgende vejledning er udarbejdet til med henblik på at informere klubadministratorer om de selvbetjeningsmuligheder

Læs mere

Vejledning - indberetning til PensionDanmark Sundhedsordning

Vejledning - indberetning til PensionDanmark Sundhedsordning Vejledning - indberetning til PensionDanmark Sundhedsordning Indhold Generelt om indberetning til sundhedsordning 1 Adgang til indberetningsløsningen 1 Indberetning af medarbejdere 2 Bekræftelse af indberetning

Læs mere

Styregruppe og Brugergruppe

Styregruppe og Brugergruppe Nr. 6, august 2004 NYHEDER OG ÆNDRINGER I LUDUS SUNDHED I dette nyhedsbrev Orientering Tilkøbsfunktionaliteter Næste version Ny e-mailadresse Ny hjemmeside design Mailservice CSC Scandihealth orienterer

Læs mere

SmartWeb Brugermanual

SmartWeb Brugermanual SmartWeb Brugermanual Table of Content Table of Content... 1 Best Practice SmartWeb:... 2 Implementering... 4 Egenskaber:... 5 Filer:... 7 Oprettelse af Kategori... 9 Sider og Tekster:... 11 Slideshow...

Læs mere

MONO.NET FORHANDLER GUIDE

MONO.NET FORHANDLER GUIDE MONO.NET FORHANDLER GUIDE INTRO Tak fordi du har valgt at blive en mono.netforhandler. Vi glæder os til vores fremtidige samarbejde! Denne guide giver en grundig introduktion til hvordan forskellige hjemmesider

Læs mere