HOVEDPROSJEKT Studieprogram: Informasjonsteknologi. Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Transkript

1 1

2 PROSJEKT NR. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Webgrensesnitt og Android applikasjon for Oslo Fight Center DATO ANTALL SIDER / BILAG Telefon: Telefaks: PROSJEKTDELTAKERE Olav Ro s Robin Berg Jønsson s Vizllim Rustemi s Mariusz Krzysztof Zych s INTERN VEILEDER Omar al-khayat OPPDRAGSGIVER OFC Oslo Fight Center KONTAKTPERSON Ole Boe SAMMENDRAG Webgrensesnitt og Android applikasjon for Oslo Fight Center, er en mobil applikasjon og et webgrensesnitt som kommuniserer med hverandre. Brukeren av applikasjonen finner generell informasjon som blir lagt ut fra webgrensesnittet. 3 STIKKORD Mobil applikasjon og webgrensesnitt Android, PHP & Query Oslo Fight Center 2

3 Forord Dette er en hovedoppgave i bachelor for ingeniør, teknologi og data linjen høgskolen i Oslo og Akershus våren Denne oppgaven er laget for Oslo Fight Center (OFC). Dette er et sammensatt dokument av prosessdokumentasjon, produktdokumentasjon, testdokumentasjon og brukermanual. Prosessdokumentasjon utdyper prosessutviklingen av prosjektet, mens produktdokumentasjonen beskriver selve produktet. Testdokumentasjonen består av ulike tester vi har kjørt på produktet, og brukermanualen tar for seg brukerveiledning for produktet. Hovedprosjektet er beregnet for arbeidsgiver og sensor, men vil også være tilgjengelig for dem som ønsker å videreutvikle produktet ved forespørsel til gruppen som har utviklet dette. Dokumentformatet er PDF og er tilgjengelig for de fleste plattformer. Vedlagt følger stikkordsliste og kildeliste Takk til Vi ønsker å takke Oslo Fight Center og Ole Boe for å ha gitt oss denne oppgaven. Takk til Omar al-khayat for veildening og hjelpen under hele arbeidsprosessen. Takk til Amir Maqbool Ahmed for hjelp til oppsett av server. Takk til Tor Krattebøl for å ha hjulpet oss med bytting av oppgave. 3

4 Innholdsfortegnelse HOVEDPROSJEKT...2 Forord...3 Takk til...3 Presentasjon...6 Android applikasjon og webgrensesnitt for Oslo Fight Center...6 Prosessdokumentasjon Innledning Bakgrunn for valget av plattform: Android og webgrensesnittet Om gruppen Navn Studie Studentnummer Vizllim Rustemi Robin Berg Jønsson Olav Ro Mariusz Krzysztof Zych Om Oslo Fight Center Oslo Fight Center (OFC) Krav Maga K Submission wrestling MMA Om OFC og registrering Dagen situasjon Begrensninger Planleggingsfasen Begynnelsen av prosjektet Planleggingsprosessen Arbeidsfordeling Møtereferat Gant-diagram Milepæler Verktøy Litt om verktøyene Ny kunnskap Utviklingsprosessen Arbeidsmetode Faser Research Gjennomføring

5 3.2.3 Avslutningsfasen Utviklingsprosessen: Utfordringer Android & JSON PHP og jquery Sikkerhet Oppbygging og funksjon Bruk av versjonskontroll(tls) Design Utelate funksjoner Oppdragsgiver under prosessen Tilbakemeldingen av oppdragsgiveren Kravspesifikasjon Endelig kravspesifikasjon Endringer Samsvar mellom kravspesifikasjoner og produkt Om resultatet Oppsummering Konklusjon Avslutning Videreutvikling Stikkordliste...38 Kildeliste...39 Vedlegg...42 Vedlegg 1 Kravspesifikasjon Endringer Vedlegg 2 SQL

6 Presentasjon Android applikasjon og webgrensesnitt for Oslo Fight Center Oslo Fight Center (OFC) er et treningssenter med mange ulike kampsport og vokser stadig. Vi skal lage en applikajson som skal hjelpe medlemmene til å ha informasjon om senteret på mobilen. Målet vårt er å lage en Android applikasjon som skal kunne gi medlemmene informasjonen som trengs rett på mobilen, lett og enkelt. Det å ha en applikasjon hvor man kan få informasjon om blant annet om OFC, timeplaner, utstyr, hvilken type kampsport som er tilgjengelig å trene hos dem, kontakt informasjon, nyheter og kalender for ulike hendelser som er relevant for dem. Veldig mange bruker smarttelefoner og dette har tatt over markedet, folk ønsker ting lett tilgjengelig og ved å lage en mobilapplikasjon gjør vi nettopp dette, gjør det enklere. Oppgaven vår er å kunne ha mange ulike løsninger, vi fikk ingen spesifikke krav om hvordan vi skulle gjøre ting, siden oppdragsgiver ikke hadde den tekniske forståelsen over hvordan man programmerer og hva som er mulig til å få til og ikke mulig, derfor fikk vi velge løsning selv. Dette gir oss friheten til å være selvstendige, og ettersom to av medlemmene i gruppen har kampsportbakgrunn og er instruktører som har jobbet lenge med dette, føler vi at vi kan tilfredsstille en god del av behovene som et vanlig medlem vil trenge. Vi valgte en Android løsning siden dette er det mest voksende operativsystemet for smarttelefoner, Android finnes i ca. 80 % av smarttelefonene ute i markedet. 1 Dette er en av grunnene, den andre grunnen er at flere gruppemedlemmer har hatt Androidprogrammering som fag og kan en god del om Android. Vi håper denne applikasjonen vil være til god hjelp for medlemmene og gjøre det enklere for alle. Webgrensesnittet var noe vi lagde først for å kommunisere med Android applikasjonen, men utviklet seg til å være en muligens løsning for administrasjonen for Oslo Fight Center. Webgrensesnittet er for å registrere medlemmer og instruktører, men skal kunne legge til nye 1 Googles-OS_id

7 varer, kurs og hendelser. Webgrensesnittet er blitt laget til for å kommunisere med mobilapplikasjonen. 7

8 8

9 Prosessdokumentasjon 9

10 1. Innledning I høst møttes vi og diskuterte sammen om hva vi skulle gjøre og hvem vi kunne tenke oss å ha oppgave for. En av oss jobbet i OFC og dette var en av oppgavene vi tenkte på, samtidig tenkte vi at det ville ha vært en god erfaring å ta en oppgave som er levert av skolen, den oppgaven var: K-SPICE App for Android/iOS platforms, Kongsberg Oil & Gas. Vi hadde møter med dem og brukte mye tid på å finne mulige løsninger. Dessverre tok det tid før vi fikk hjelp, blant annet OPC-server løsning tok en del tid før vi fikk svar på. Vi hadde ikke noe kompetanse med OPC-Servere og vi klarte heller ikke å finne god nok dokumentasjon på hvordan det fungerte, eller noen som kunne hjelpe oss med dette. Dermed endte det med at vi ønsket å trekke oss fra oppgaven før det var for sent, vi følte at vi ikke kunne levere et produkt som vi var godt nok tilfredsstilte med. Dette medførte til at vi mistet nesten to måneder med arbeid, og vi endret til slutt oppgave og startet med løsningen for OFC. Valget endte på oppgaven om å lage en mobilapplikasjon og et webgrensesnitt for Oslo Fight Center dette er noe kampsportsenteret manglet og vi syntes det virket som et spennende prosjekt. Hovedprosjektoppgaven er ikke utlyst fra skolen, men er en oppgave hvor en i gruppen har forhørt seg med en mulig prosjektoppgave fra våres side. Vi fikk grønt lys fra kampsport senteret om at vi kunne lage en mobil applikasjon og frie tøyler til å lage noe mer vi så de kunne ha behov for. 1.1 Bakgrunn for valget av plattform: Android og webgrensesnittet Vi har lenge før bacheloroppgaven snakket om å lage en applikasjon sammen som en gruppe og nå som vi hadde muligheten valgte vi Android som plattform for mobilapplikasjonen. Dette er et av de største mobil OS-ene og siden to medlemmer av gruppen også hadde hatt Androidprogrammering som programfag ble dette et naturlig valg. Metodene vi bruker for å løse denne oppgaven skal også være enklere for oss eller andre som senere skulle komme og ta prosjektet til videreutvikling, eller for å få det ut i andre plattformer som ios og Windows Phone. 10

11 For at det skulle fungere optimalt, er det nødvendig med et webgrensesnitt som er et kommunikasjonsledd mellom databasen og applikasjonen. Webgrensesnittet brukes til å legge til informasjon i databasen som applikasjonen vil hente ut ifra. 1.2 Om gruppen Navn Studie Studentnummer Vizllim Rustemi Robin Berg Jønsson Olav Ro Mariusz Krzysztof Zych Bachelor Ingeniørfag(Data) Bachelor Ingeniørfag(Data) Bachelor Informasjonsteknologi Bachelor Ingeniørfag(Data) s s s s Vi er fire studenter hvor tre av oss går ingeniørfag (data) og en går informasjonsteknologi linjen. Gruppen har jobbet sammen siden studiestart, og har jobbet mye som en gruppe siden. Gruppemedlemmene har blitt godt kjent med hverandre i løpet av de tre årene. Vi kjenner hverandres styrker og svakheter og føler at som en gruppe dekker vi hverandres svakheter. Gruppesamarbeidet har fungert bra og vi har felles mål og ambisjoner som får hvert enkelt av oss til å jobbe mot vårt ytterste. 11

12 1.3 Om Oslo Fight Center Oslo Fight Center (OFC) Oslo Fight Center er et av Norges største treningssentre som tilbyr kampsport- og selvforsvarstrening. I dag er det rundt 500 medlemmer i OFC. Som medlem i OFC kan man fritt velge å trene hvilken kampsport man velger å trene Krav Maga Krav Maga-trening er selvforsvarstrening. Man lærer effektive slag og spark, og hvordan man kan forsvare seg mot en eller flere angripere, også dersom de har våpen. Treningen foregår som regel inne, men vi arrangerer også utendørs treninger; i buss, i nattklubber og andre realistiske omgivelser. Krav Maga passer alle K1 K1 ligner thaiboxing og kickboxing, og inkluderer slag-, spark- og kneteknikker. K-1 gir deg utholdenhets og teknikktrening med mye "padwork" og oppgavesparring som alle har godt av, uavhengig av treningsnivå. OFC har eget konkurranselag for de som ønsker å konkurrere Submission wrestling Denne kampsporten kombinerer de fleste teknikker innen bryting/grappling, og man skal prøve å kontrollere motstanderen ved å låse ledd eller ved kvelninger. Det setter store krav til teknikk og evne til å holde hodet kaldt, så det er ikke alltid den sterkeste som vinner. OFC har eget konkurranseteam i submission wrestling MMA Mixed Martial Arts er verdens raskest voksende kampsport! MMA kombinerer både stående slag og spark med liggende teknikker likt submission wrestling med slag av ulike typer. Treningen passer for alle som har noe erfaring fra stående og liggende kampsport fra før. OFC har et konkurranseteam. 12

13 1.3.6 Om OFC og registrering OFC har en hjemmeside som inneholder generell informasjon om senteret. Her finner man nyheter om nye hendelser, timeplan for medlemmene og informasjon for de som ønsker å starte. OFC bruker Excel for å registrere medlemmer og for registrering av oppmøte på treningene. Oppmøte registreres på bakgrunn av gradering, man må møte et viss antall ganger for å kunne gradere seg Dagen situasjon OFC har bare en hjemmeside og ingen mobilapplikasjon. De bruker Excel til å registrere nye brukere og til eventuelle oppmøter. Vi har kommet fram til å programmere backenden på applikasjonen. Det trengs en database og webgrensesnitt til å dekke de behovene OFC kan trenge. Disse Figur 1 viser innloggingsiden, guiden og hovedmenyen pr dags dato. Figur 1 Prototype av innloggingssiden, guide og hovedmenyen. 13

14 Oppgavens mål Det ble laget en kravspesifikasjon som ble vist frem til OFC under det første møtet. Under møtet fikk vi beskjed om at siden de ikke viste hvor komplekst det ville være å lage programmet, ville det være opp til oss hvordan vi skulle gå fram med oppgaven. Det var som mål å lage et webgrensesnitt og mobilapplikasjon som kommuniserer med hverandre og som OFC kunne bruke. 14

15 Krav og rammebetingelser En applikasjon som gir kundene informasjon over treningssenterets tilbud. Applikasjonen skal gjerne ha informasjon om treningstider, terminplaner/stevner, ulike typer kampsport og informasjon om OFC som f.eks. beliggenhet, åpningstider og om OFC. Mulighet for å få kontaktinformasjon til senteret skal også være mulig. Applikasjonen skal være to-delt: 1. Informasjon til medlemmene 2. Personlig bruk Med personlig bruk menes det at applikasjonen skal ha en funksjon hvor brukeren, kan skrive treningsnotater i applikasjonen og bruke dette som treningsdagbok. Samtidig ulike øvelser som nybegynnere kan bruke til å trene på dersom de ikke vet helt hvor de skal starte. 1. Informasjon til medlemmene: - Om OFC - Timeplaner - Priser - Hvilke typer kampsport - Kontakt - Nyheter - Blogg - Kalender for ulike hendelser som er relevant for senteret - Notat - Ulike treningsøkter (for nybegynnere, On-The-Go) 15

16 2. Personlig bruk/instruktør: - Logg inn - Din timeplan(instruktør kan redigere/endre timeplan?) - Poste events (I dag har vi ) - Øvelser(Øvelser spesialisert til deg) - Din tid(du har ikke trent på 17 Dager) Ting vi diskuterte: - Server til å hente data fra nettsiden direkte - Dekke øvrige kampsport (Krav maga, MMA, k1, submission wrestling) - Vise hvordan man tar øvelsen riktig? (Instruks) Dette er kravspesifikasjonen for hoveddelen av applikasjonen. Teknologi brukt: Vi har valgt MySQL for databaseprogrammeringen og kjører dette på skoleserveren via XAMPP. Siden vi har brukt MySQL på skolen så velger vi dette ettersom vi har litt kjennskap til dette tidligere Begrensninger Vi begrenser mobilapplikasjonen til Android, og webapplikasjonen til nettlesere som Google Chrome og Opera. Vi har valgt å optimalisere for disse nettlesere av statistiske undersøkelser som viser tydelig hva brukermassen bruker til daglig

17 2. Planleggingsfasen 2.1 Begynnelsen av prosjektet Gruppen hadde allerede startet tidlig i semesteret med å diskutere hva vi hadde lyst til å jobbe med. Som gruppe har vi hatt kurs i ulike programmeringsspråk og markeringsspråk, med blant annet, HTML, CSS, Java, MySQL, PHP, C# (C-sharp), Android-programmering. Noen av gruppemedlemmene har også vært igjennom andre språk også, blant annet jquery og JSON. Vi sendte mail til ulike firmaer vi kunne tenke oss å ha en oppgave for, men flere svarte ikke. Høgskolen hadde lagt ut ulike arbeidsgivere/oppgaver, men vi fant ingen spesielle som vi følte var tiltrekkende. Etter en stund med diskusjoner kom vi fram til og fant fram til en arbeidsgiver, OFC. En av medlemmene i gruppen foreslo denne oppgaven, han trener og er instruktør i OFC og mente det kunne være nyttig for OFC. Vi hadde et møte med Ole (kontaktperson for OFC) og diskuterte kravspesifikasjonen for applikasjonen, om hva som var ønskelig. Han ville at vi skulle komme med forslag for hva vi skulle ha med. Det var ikke noe konkret han kom med og var litt usikker siden han ikke viste hvor komplekst dette kunne bli. Vi hadde en kravspesifikasjon som vi hadde tenkt på forhånd, siden to av gruppemedlemmene er instruktører i to ulike treningssenter. Den ene jobber på et treningssenter hvor han har vært daglig leder. Sammen kunne vi som en gruppe komme frem til hva vi burde ha med. Siden alle gruppemedlemmene har trent og vært elever gjør dette at vi har en tanke over hva applikasjonen burde dekke. 2.2 Planleggingsprosessen Planleggingen av prosjektet startet i januar, hvor vi hadde en del diskusjoner og møter om hvordan vi ser for oss applikasjonen. Vi snakket om hvilke type programmeringsspråk det kunne hende vi skulle bruke, og flere av disse hadde vi gått igjennom, men om det dukket opp noe nytt skulle vi bare sette oss inn i det. Siden to av gruppemedlemmene jobber som instruktører og ene har jobbet som daglig leder på et treningssenter, hadde vi en ganske god 17

18 bakgrunn og kunne enklere se for oss hva vi burde ha med i applikasjonen. Dette gav oss mye bedre oversikt slik at vi kan dekke behov fra både medlemmene sin side og senteret sin side. Etter at vi hadde møtet med OFC så satte vi i gang med programmering av backenden og applikasjonen. 2.3 Arbeidsfordeling Vi valgte å fordele arbeidsoppgave slik at vi får et felt der vi er best, og hjelpe hverandre dersom vi følte at det er noe vi ikke fikk til. Vi hadde ulike arbeidsoppgaver, som dokumentasjon, design og programmering. Navn Robin Olav Vizllim Mariusz Arbeidsoppgaver Koding og design Dokumentasjon og koding Design, dokumentasjon og prosjektets hjemmeside Dokumentasjon og holdt kontakt med OFC Vi valgte en slik arbeidsfordeling etter å ha diskutert sammen, slik at vi kunne jobbe mest effektivt. 2.4 Møtereferat Møtereferat ble skrevet hver dag når vi møttes og jobbet sammen. Dette er for å gi en oversikt over hva vi gjorde når, deretter kunne vi se om vi har klart å holde oss til fremdriftsplanen. Møtereferat er også viktig for å vite hva vi har blitt enige i tilfelle det skulle oppstå problem eller misforståelser om hva vi har sagt eller hva vi har valgt ha med. Møtereferatet er lagt ut på gruppens hjemmeside: 18

19 2.5 Gant-diagram Vi satt opp gant-diagram(se figur 2) for hvordan vi skulle jobbe mot innleveringen av hovedprosjekt. Gant-diagrammet viser starttidspunkt og sluttidspunkt for hver av oppgavene, dette gjorde vi for å ha et klart mål på å fullføre hva vi har startet på. Figur 2 Gant-diagram 19

20 2.6 Milepæler Hva? Når? Forprosjekt rapport Kravspesifikasjoner Ferdig med web-grensesnitt Ferdig med applikasjon Testing/forbedring Ferdig produkt Prosjektrapport Presentasjon

21 2.8 Verktøy Vi har brukt ulike verktøy i denne oppgaven for å få utviklet applikasjonen slik vi ønsker og med de verktøyene vi føler vi får best mulig utnyttelse av slik at det dekker våres behov Litt om verktøyene Eclipse XAMPP Vi brukte Eclipse til å kode, vi har brukt Eclipse før og har blitt godt kjent med den og den dekker våres behov. Den har også Android emulator hvor vi testet applikasjonen. Dette programmet brukes også i Androidprogrammerings kurset. Vi bruker XAMPP, som er vår webserver. Denne gir oss muligheten til å bruke Apache, MySQL, PHP og Pearl uten å måte laste ned hver av dem enkeltvis og sette dem opp og konfigurere dem Microsoft Word Microsoft Word brukte vi til å skrive dokumentasjon, referater, tester osv. Dette er den mest brukte programmet til å skrive dokumenter. Vi har alle brukt dette programmet og kjenner godt til det. Skype Vi brukte Skype til å holde kommunikasjonen når noen var borte slik at vi kunne snakke sammen og jobbe videre. Skype var veldig nyttig siden vi ikke ble handlingslammet når vi ikke hadde møte, vi kunne sitte og jobbe hjemmefra også. 21

22 Dropbox Vi brukte Dropbox til å ha et felles lagringsområde hvor alle hadde tilgang til alt. Dette gjorde dokumenter og andre filer letter tilgjengelig for gruppen. Siden alle hadde Dropbox og vi har brukt dette gjennom studietiden så var det veldig enkelt og en av de første tingene vi gjorde, lage felles mappe. Vi tok også backup underveis for å unngå at vi mistet viktige dokumenter og filer. WhatsApp Messenger Remote desktop Vi valgte å bruke WhatsApp Messenger som er et gratisprogram for å sende tekstmeldinger med hverandre, vi lagde en gruppe hvor alle medlemmene var lagt til og kunne kommunisere med hverandre hvor vi oppdaterte gruppen om hva vi hadde gjort osv. Vi brukte Remote desktop for å få tilgang til serveren på skolen. Adobe Photoshop CS6 Photoshop CS6 ble brukt til å designe bilder, som forsidebildene i dokumentasjonene. 22

23 GIMP GIMP ble brukt til å skalere og fikse på ikoner som er brukt på hjemmesiden og applikasjonen Visio 2013 Professional Visio 2013 ble brukt til å lage de ulike diagrammene, som tilstandsdiagram, sekvensdiagram, klasser osv. Nettlesere Google Chrome og Opera er nettleserne som er brukt. Notepad++ Notepad++ er brukt til å lage klasser i webgrensesnittet, brukt mest på server og er brukt til å lage gruppens hjemmeside. Bitbucket Vi testet Bitbucket med versjonskontroll (TLS), men det tok for lang tid, for hver gang vi skulle pushe (laste opp noe), måtte vi skrive begrunnelse også. 23

24 2.9 Ny kunnskap Vi fikk ny kunnskap innenfor jquery, PHP og Androidprogrammering. Noe kunnskap hadde vi allerede med noen av disse språkene, men vi har lært oss mer object-orientert programmering innenfor PHP. Samtidig lærte vi oss å programmere API med JSON til å kommunisere mellom Android applikasjonen, webapplikasjonen og server databasen. JSON konverterer Java koden til plain-text og sender parameteren til PHP scriptet. Vi har fått et bedre bilde over hvordan Android kan kommunisere med server og webapplikasjonen. 24

25 3. Utviklingsprosessen 3.1 Arbeidsmetode Gruppen har valgt å bruke Kanban inspirert arbeidsmetode. Dette er et rammeverk som er tilegnet seg for utvikling av programvarebaserte systemer, vi bruker just-in-time prinsippet som er å overbelaste gruppen med arbeid til å levere til rett tid. Vi har som regel fordelt arbeidsoppgaver i gruppen til å jobbe fullt fokusert med de ulike oppgavene. Vi hadde som mål med å bli ferdig med visse arbeidsoppgaver innen gitt periode. Vi hadde møter med veileder for å spørre om råd og tilbakemeldinger underveis i prosessen. Når gruppen møttes på skolen for å jobbe, hadde vi ofte diskusjon om hvordan vi lå an i forhold til tidskjema, hva vi manglet og hva vi burde ha hovedfokus på slik at vi kunne starte på nye oppgaver. 3.2 Faser Research Første fasen i denne oppgaven var research. Vi satte oss ned og søkte litt over mulige løsninger på oppgaven, hvilke teknologier vi eventuelt måtte bruke og hvordan vi kan gå fram for å løse oppgaven. Med dette fikk vi en viss oversikt over hvordan det kunne se ut og hvordan vi kunne gå fram. At det ville dukke opp problemer underveis var vi helt klare på, derfor var det veldig viktig at vi diskuterte hvordan vi kunne gå fram, hva som kunne dukke opp og hvordan vi kunne løse dette Gjennomføring Gjennomføringsfasen startet vi med når vi var klare med kravspesifikasjon. Vi jobbet hver dag med oppgaven, og lagde en plan for når vi burde være ferdig med ulike deler. Vi hadde en idé, et bilde av hvordan vi så for oss oppgaven og resultat, men ettersom vi kom dypere i oppgaven ble noen ting endret ettersom at vi følte at vi kom med bedre løsninger en det som var planlagt på forhånd 25

26 3.2.3 Avslutningsfasen I avslutningsfasen jobbet vi intenst med applikasjonen og webgrensesnittet, samtidig drev vi med testing av de ulike funksjonene som vi har utviklet. Dette var svært viktig for oss ettersom vi ville levere et sluttprodukt i samsvar med kravspesifikasjonen. Når vi var ferdig med testene og var godt fornøyde med resultatet vi hadde oppnådd under testingen og sluttproduktet, var vi klar for levering av hovedoppgaven. 3.3 Utviklingsprosessen: Utfordringer Android & JSON I Android hadde vi stor utfordring med å kommunisere med server, ettersom vi skulle hente informasjon fra databasen måtte vi finne en måte til å hente ut dataen fra. For at applikasjonen skal hente ut data måtte vi bruke JSON objekt for å innpakke data som vi skulle hente fra server, via HTTP protokollen sendes det en forespørsel til server som sender dataene tilbake innpakket som et JSON objekt tilbake til applikasjonen. Utfordringen var at vi måtte sette oss inn i hvordan man programmerer et sånn JSON objekt og http protokoll, dette var et av de mest tidskrevende og omfattende å beherske PHP og jquery I PHP og jquery hadde vi utfordringer med å sette sammen alt på plass, vi hadde utfordring med å programmere først i PHP og html, så skulle vi bruke jquery til å få til en dynamisk side for så style det med CSS. Vi fikk noen utfordringer med server ettersom vi selv måtte oppdatere server på grunn av Heartbleed 3. Vi løste utfordringen med kodingen med at vi fordelte oppgaven mellom hver av oss, en tok for seg programmering i PHP, en annen for styling og for jquery. Vi satt programmeringsdelene sammen tilslutt

27 3.3.3 Sikkerhet Passord på webside og applikasjon: Når man oppretter en bruker så genereres det et salt som er unikt for den brukeren, saltet er random tegn som settes foran passordet før det hashes (SHA MD5). Alle passord som lagres i våre databaser krypteres (hashes) ved hjelp av en algoritme kalt SHA512, et tilfeldig "salt" kodet med base-64. SSL Hva er SSL? SSL står for Secure Sockets Layer som betyr at data som sendes mellom bruker og tjener sendes kryptert. Grunnen til at det sendes kryptert er at det ikke skal være mulig å sniffe over nettverket for å hente ut informasjonen som sendes mellom bruker og tjener. Tjeneren har krypteringsnøkkel med to passord, hvor den ene brukes til å kryptere innhold, mens den andre brukes til å dekryptere innhold (må være kjent for eieren). Nøkkelen for å kryptere innhold kalles for en offentlig nøkkel, mens nøkkelen for dekryptering kalles for en privat nøkkel. En måte å se om nettsiden benytter seg av SSL kan man se på nettadressen, SSL bruker i stedet for SSL- sertifikat er et digitalt sikkerhetssertifikat som er utstedt til et domene, en organisasjon eller privatperson for å bevise at nettstedet er ekte. SSL-sertifikat pleier vanligvis å inneholde: - Identitet til den/det sertifikatet skal identifisere - Gyldighetsperiode - Unik ID-nummer som identifiserer sertifikatet - Sertifikatets anvendelsesområder - En offentlig nøkkel (Public Key) Utsteder av sertifikatet har signert sertifikatet og kan bekrefte sertifikatets gyldighet. Vi har ikke brukt SSL sikkerheten i vårt webgrensesnitt. Grunnen til dette er at det koster å få SSL sertifisering. Vi valgte å ikke gjøre dette siden vi ikke har et webhotell noe som ville ha vært naturlig, i stedet for at vi setter det opp på egen server. 27

28 Hvis OFC velger å sette dette i produksjon må vi undersøke om det er mer lønnsomt å sette opp en server hos dem eventuelt kjøpe et webhotell. 3.4 Oppbygging og funksjon Bruk av versjonskontroll(tls) Vi tok i bruk Bitbucket som vårt versjonskontrollsystem. Et slikt system gir mer kontroll over på hvem som redigerer/endrer og for å se hvem som har kodet siste versjon. Vi som gruppe har ikke brukt versjonskontrollsystem før, men ble anbefalt av veileder til å bruke dette. Med dokumentasjon har vi valgt å bruke versjonskontrolleren til Dropbox ettersom dette var noe alle i gruppen brukte ofte Design Arbeidsgiveren stilte ingen krav når det gjaldt design, og lot gruppen selv bestemme hvordan dette skulle utføres. Webgrensesnitt: Vi har valgt en design på webgrensesnittet som er enkelt og oversiktlig (se figur 3). Knappene er store og oversiktlige slik at man ser godt både med illustrasjon og tekst hva de ulike knappene på siden er. Fargevalget er hvitt og sølv, som gir et veldig enkel og stilren design vi fikk litt inspirasjon fra fargen til iphone 5s (sølv versjonen). Fargen på teksten er mørkegrått, noe som gir god lesbarhet. 28

29 Figur 3 Illustrasjon av webgrensesnittet, kalendersiden Applikasjonen: Designen på applikasjonen er veldig simpel, fargevalget er nesten det samme som på webgrensesnittet. Bakgrunnsfargen er lysegrå, og mørkegrå tekst (som på websiden). Designen på webgrensesnittet og applikasjonen speiler hverandre slik at man skal få litt av den samme følelsen ved designen. Figur 4 illustrerer matching av webgrensesnittet med blant annet bruk av like ikoner. Figur 4 Illustrasjon av applikasjonen, menyen på applikasjonen 29

30 3.4.3 Utelate funksjoner Underveis i prosessen kom vi frem til at vi måtte prioritere hvilke funksjoner som skulle programmeres først. Applikasjonen ble ikke todelt som var tanken i starten, med en personlig del og en informasjonsdel i selve applikasjonen. - Blogg - Notat - Endring av timeplan i applikasjonen - Øvelser - Ulike treningsøkter for nybegynnere Er funksjoner som ble endret/fjernet ettersom vi valgte å gjøre en del endringer. Mer om disse utelatte og endrede funksjoner står i avsnitt Oppdragsgiver under prosessen Oppdragsgiver under prosessen har vært veldig lett å jobbe med. Ole Boe er sjefsinstruktør og deleier av Oslo Fight Center, og er personen vi har hatt møte med i starten og fått tilbakemelding fra. Sammen under det første møtet diskuterte vi oppgaven og ble enige om visse kriterier som skulle være med. Vi ble enige om å lage en Android applikasjon for OFC. Oppdragsgiver har alltid vært tilgjengelig for oss da vi har hatt noen spørsmål rundt for eksempel OFC, eller ønsker fra dem angående applikasjonen. Vi hadde en kontaktperson fra gruppen, Mariusz, som hadde jevnlig kontakt med Ole Boe. 30

31 3.6 Tilbakemeldingen av oppdragsgiveren Underveis i utviklingsprosessen kom vi frem til at det være nødvendig med et webgrensesnitt (backend-løsning). Hovedgrunnen til at vi valgte å ha et webgrensesnitt er for å gjøre det enklere å endre innhold i applikasjonen for de som jobber der. Det skal ikke være nødvending med programmeringskunnskaper for å endre innhold i applikasjonen, som for eksempel legge til kurs, instruktør, medlemmer osv. Vi fikk positiv tilbakemelding på webgrensesnittet fra oppdragsgiver, de var fornøyde over hvor oversiktlig og enkelt det var å bruke samtidig ble de overasket over designen, noe de likte. De mente det er veldig bra at applikasjonen kommuniserer med webgrensesnittet på så enkelt måte, noe som gjør det blir enklere for dem å endre innhold. 31

32 3.7 Kravspesifikasjon Endelig kravspesifikasjon Kravspesifikasjonen ble en del endret underveis, grunnen er at vi fant nye løsninger som gir et bedre resultat enn det vi først så for oss. Vi var klare over at det måtte bli endringer underveis, og var nødt til å finne andre løsninger som er bedre enn det vi hadde først planlagt. Applikasjonen vil ikke bli i to, men fant et bedre løsning med å hente ut data fra en nettside (server). Dette skal være en backend løsning, å lage et webgrensesnitt som kommuniserer med applikasjonen. Ting skal være med: 1. Applikasjonen: Logg inn Hjem Min trening Instruktør Trening og hendelser Kurs Utstyr Om oss (OFC) Logg ut 2. Webgrensesnitt: Logg inn Hjem Kalender Kurs Utstyr Medlem Instruktør Logg ut 32

33 3.7.2 Endringer Vi valgte å fjerne/endre disse delene: - Notat * - Blogg * - Din timeplan(instruktør kan redigere/endre timeplan?) ** - Poste hendelser (I dag har vi ) *** - Øvelser(Øvelser spesialisert til deg) * - Din tid(du har ikke trent på 17 Dager) * - Ulike treningsøkter (for nybegynnere, On-The-Go) * Forklaringer: *(ikke tatt med) **(endret, kan kun endres i webgrensesnitt og ikke i applikasjonen) ***(endret til hendelser i kalender) Vi valgte å ikke ta med disse delene fordi vi føler at det er små endringer som kan gjøres/legges til ved senere utvikling, men at vi nå lager et produkt som kan brukes og har fokus på viktige funksjoner. Det at vi valgte å utvikle webgrensesnitt gjorde at vi måtte gjøre om prioriteringer og hadde mer å gjøre enn å bare lage en Android applikasjon. Ut i utviklingen fant vi fort ut at det måtte gjøres noen grep for at det skulle bli best mulig løsning, derfor valgte vi å kjøre cirka lik design på både applikasjonen og webgrensesnittet som for eksempel fargebruk, innhold, og ikoner. Vi har prøvd å gjenspeile webgrensesnittet i applikasjonen. Det at vi har et webgrensesnitt gjør det enklere for brukeren å endre innhold i selve applikasjonen. Brukeren trenger ikke programmeringskunnskaper i Android for å kunne endre innholdet i applikasjonen. Dette gir også OFC et bedre system som de kan bruke, det vil gi dem en bedre oversikt over medlemmer og instruktører enn å føre det på Excel. Webgrensesnittet er bygget opp med tanke på en fleksibel applikasjon som skal kunne møte de endringene OFC kan få i fremtiden, som for eksempel nye medlemmer, instruktører, nye kurs, oppdatering av utstyr, endring av kontaktinformasjon, sted m.m. Dette er ikke hardkodet i applikasjonen, og en trenger derfor ikke programmeringskunnskaper for å oppdatere og 33

34 gjøre endringer i applikasjonen. Dette var baktanken med webgrensesnittet, for å gjøre det enklere for brukeren av systemet. Dette kan i fremtiden erstatte den nåværende løsningen de bruker Samsvar mellom kravspesifikasjoner og produkt Av kravspesifikasjonen vi leverte under førprosjekt, har vi utvidet og endret en god del på. Av førprosjekt har vi samsvar av funksjonalitet tatt med: mobil applikasjon - Om OFC - Timeplaner - Priser(endret til utstyr) - Hvilke typer kampsport - Nyheter - Kalender - Server løsning og MySQL (utvidet funksjonalitet) Av endelig kravspesifikasjon har vi alt overens med kravspesifikasjonen og produkt se punkt i prosessdokumentasjon. 34

35 3.8 Om resultatet Oppsummering Etter en god del arbeid har vi kommet frem til et resultat som vi føler oss veldig fornøyd med og som vi tror at OFC vil også bli. Resultatet ble mye bedre enn hva vi først så for oss da vi startet med dette prosjektet. Vi valgte å gjøre endringer i kravspesifikasjonen, noe som gjorde at selve løsningen ble bedre enn hva vi først så for oss. Det at vi har klart å lage en helhetspakke som kan med få utvidelser settes i bruk av OFC. Det har vært en lang prosess hvor vi har vært igjennom oppturer og nedturer, men hvor vi har klart å levere et godt produkt som vi selv er fornøyd med Konklusjon Dette har vært en lærerikt, omfattende periode hvor vi har tilegnet oss mye nyttig kunnskap og erfaringer som vil være veldig viktig for oss i fremtiden. Vi har utfordret oss selv med tanke på omfang av prosjekt, utfordringer og er derfor veldig fornøyde med at vi har kommet til veis ende. Gjennom arbeidet har vi også fått erfare hvor nyttig fagene på skolen har vært, vi har blant annet fått nytte og bruk for fag som systemutvikling, web-prosjekt, webprogrammering, menneske maskin interaksjon, applikasjonsutvikling, prototyping og datasikkerhet. Vi har prøvd mest mulig å ta i bruk alle fagene vi har lært og binde det til prosjektoppgaven for å reflektere våre ferdigheter og hva vi har lært gjennom studiet. Når vi først satt oss ned for å starte på denne oppgaven, hadde gruppen allerede mindre tid på grunn av en annen oppgave. Erfaringsnivået vi sitter igjen med etter et sånt omfattende prosjekt er både positive og negative, vi opplevde at prosjektplanleggingen var det som tok mest tid. Vi hadde regnet ut at vi kommer til å bruke lengere tid på oppgaver som vi ikke hadde muligheter å gjøre, vi hadde allerede estimert tid at vi skulle være ferdig med prosjektet i begynnelsen av mai, men måtte jobbe utover det for å få alt ting på plass. Det gruppen sitter igjen med er erfaringer som vi kan ta med oss videre inn i arbeidslivet med, prosjektplanlegging og prosjektstyring har kommet godt med. Vi føler at det er veldig viktig å planlegge et så omfattende prosjekt veldig godt for å få en smidig gjennomføring, det som kommer godt med er at vi hadde tatt høyde for at kravspesifikasjonen kunne endres under veis så vi kunne få med de viktigste kravene til å bli implementert først. Vi føler vi nå kan se tilbake på arbeidsperioden og være godt fornøyde med resultatet av prosjektoppgaven. 35

36 3.9 Avslutning Videreutvikling Sosiale medier Vi har alle snakket sammen om integrasjon av sosiale medier i applikasjonen. Dette er noe de aller fleste applikasjonene har i dag for å øke brukeropplevelsen. Man kunne for eksempel dele sine treninger, eller dele utstyr en synes er kule eller ønsker osv. Områder man kan dele dette ville vært de mest populære sosiale mediene i dag, som for eksempel Facebook, Twitter, Google+ etc Utvidelse i applikasjon En tanke vi hadde var at trenerne kan for eksempel logge inn og ha mulighet til å legge ut nyheter, og administrere privattimer osv Forum / Chat En chat eller forum funksjon, hvor medlemmer kan snakke med hverandre. Egen gruppe for instruktører hvor de kan diskutere med hverandre, som for eksempel om noen kan bytte timen eller forslag til øvelser Regex Det er en feil i regex i blant annet om feltet på registrering av Instruktør, som vi ikke er fornøyd med og har kommentert ut. Vi var nødt til å prioritere og valgte å ikke bruke mye tid på regexen Bildefunksjon I webgrensesnittet kan man ikke legge til bilder i utstyrsmenyen, kursene og instruktør. Knappene for å laste opp bilde er skjult grunnen til dette er at koden mangler. Dette kan lett ordnes opp i fremtiden. 36

37 37

38 Stikkordliste Navigation drawer En meny oppe til venstre i en mobil applikasjon. View Flere tabeller i en database som er satt sammen. Use Case Steg beskrivelse OFC Oslo Fight Center Interface Kommunikasjon mellom to systemer eller konsepter Fragment En atferd I brukergrensesnittet Adapter Overgang fra et format til en annen. Aktivitet En aktivitet er en pågående ikke-atomisk eksekvering innen en tilstandsmaskin. Kant Kant objektet, er selve systemet man kommuniserer med, for eksempel pcen man sitter på for å bruke webgrensesnittet. Bugs Feil i programvaren PHP Hypertext Preprocessor HTML Hypertext Markup Language jquery Rammeverk for javascript CSS Cascading Style Sheet 38

39 Kildeliste Sikkerhet: Kilde: Artikkel lagt ut: December 8, 2013 Sist sjekket: Programmering: Applikation Drawer: Tutorials på kommunikasjon mellom Android og PHP: PHP Dokumentasjon: Android API guide: Pro Android UI Skrevet av: Wallace Jackson Publisert HiOA: dokumentasjonsstandard for bachelor-prosjekter Skrevet av Ann-Mari Torvatn Publisert:

40 Bilder: Notepad++: Bitbucket: Opera og Chrome: Photoshop CS6: GIMP: VISIO2014: 3logo.png Eclipse: XAMPP: Microsoft Word: Skype: Whatsapp: Remote desktop: 40

41 Dropbox: Javafil: WUEcPN.png XML fil: 41

42 Vedlegg Vedlegg 1 Kravspesifikasjon Kravspesifikasjonen ble en del endret underveis, grunnen er at vi fant nye løsninger som gir et bedre resultat enn det vi først så for oss. Vi var klare over at det måtte bli endringer underveis, og var nødt til å finne andre løsninger som er bedre enn det vi hadde først planlagt. Applikasjonen vil ikke bli i to, men fant et bedre løsning med å hente ut data fra en nettside (server). Dette skal være en backend løsning, å lage et webgrensesnitt som kommuniserer med applikasjonen. Ting skal være med: 1. Applikasjonen: Logg inn Hjem Min trening Instruktør Trening og hendelser Kurs Utstyr Om oss (OFC) Logg ut 2. Webgrensesnitt: Logg inn Hjem Kalender Kurs Utstyr Medlem Instruktør Logg ut Endringer 42

43 Vi valgte å fjerne/endre disse delene: - Notat * - Blogg * - Din timeplan(instruktør kan redigere/endre timeplan?) ** - Poste hendelser (I dag har vi ) *** - Øvelser(Øvelser spesialisert til deg) * - Din tid(du har ikke trent på 17 Dager) * - Ulike treningsøkter (for nybegynnere, On-The-Go) * Forklaringer: *(ikke tatt med) **(endret, kan kun endres i webgrensesnitt og ikke i applikasjonen) ***(endret til hendelser i kalender) Vi valgte å ikke ta med disse delene fordi vi føler at det er små endringer som kan gjøres/legges til ved senere utvikling, men at vi nå lager et produkt som kan brukes og har fokus på viktige funksjoner. Det at vi valgte å utvikle webgrensesnitt gjorde at vi måtte gjøre om prioriteringer og hadde mer å gjøre enn å bare lage en Android applikasjon. Vi hadde en viss anelse om at vi kanskje måtte gjøre dette, men etter at vi startet med utviklingen bestemte vi oss for å lage webgrensesnittet slik at vi fikk en bedre løsning. Vi valgte å kjøre cirka lik design på både applikasjonen og webgrensesnittet som for eksempel fargebruk, innhold, og ikoner. Vi har prøvd å gjenspeile webgrensesnittet i applikasjonen. Det at vi har et webgrensesnitt gjør det enklere for brukeren å endre innhold i selve applikasjonen. Brukeren trenger ikke programmeringskunnskaper i Android for å kunne endre innholdet i applikasjonen. Dette gir også OFC et bedre system som de kan bruke, det vil gi dem en bedre oversikt over medlemmer og instruktører enn å føre det på Excel. Webgrensesnittet er bygget opp med tanke på en fleksibel applikasjon som skal kunne møte de endringene OFC kan få i fremtiden, som for eksempel nye medlemmer, instruktører, nye kurs, oppdatering av utstyr, endring av kontaktinformasjon, sted m.m. Dette er ikke hardkodet i applikasjonen, og en trenger derfor ikke programmeringskunnskaper for å oppdatere og gjøre endringer i applikasjonen. Dette var baktanken med webgrensesnittet, for å gjøre det 43

44 enklere for brukeren av systemet. Dette kan i fremtiden erstatte den nåværende løsningen de bruker. Vedlegg 2 SQL CREATE TABLE Post( PostalCode CHAR(4) NOT NULL, Post VARCHAR(100) NOT NULL, CONSTRAINT PostalCode PRIMARY KEY(PostalCode) ); CREATE TABLE Person( PNr INT AUTO_INCREMENT NOT NULL, Firstname VARCHAR(100) NOT NULL, Lastname VARCHAR(100) NOT NULL, Height INT NOT NULL, Weight INT NOT NULL, Address VARCHAR(100) NOT NULL, PostalCode CHAR(4) NOT NULL, Birthday date NOT NULL, Mobile CHAR(8) NOT NULL, Phone CHAR(8) NOT NULL, VARCHAR(100) NOT NULL, Password CHAR(128) NOT NULL, Salt CHAR(128) NOT NULL, CONSTRAINT PersonPN PRIMARY KEY(PNr), 44

45 CONSTRAINT PersonPostalCode FOREIGN KEY (PostalCode) REFERENCES post(postalcode) ); CREATE TABLE ProfilePicture( PNr INT NOT NULL, Image BLOB NOT NULL, FileName VARCHAR(100) NOT NULL, FileType VARCHAR(10) NOT NULL, CONSTRAINT ProfilePicturePN PRIMARY KEY(PNr), CONSTRAINT ProfilePersonPN FOREIGN KEY (PNr) REFERENCES person(pnr) ); CREATE TABLE Employee( EPNr INT NOT NULL, CONSTRAINT Employee PRIMARY KEY(EPNr), CONSTRAINT EmployePN FOREIGN KEY (EPNr) REFERENCES person(pnr) ); CREATE TABLE Instructor( IPNr INT NOT NULL, About TEXT(500) NOT NULL, CONSTRAINT Instructor PRIMARY KEY(IPNr), CONSTRAINT InstructorPN FOREIGN KEY (IPNr) REFERENCES Person(PNr) ); 45

46 CREATE TABLE Member( MPNr INT NOT NULL, CONSTRAINT Member PRIMARY KEY(MPNr), CONSTRAINT MemberPN FOREIGN KEY (MPNr) REFERENCES person(pnr) ); CREATE TABLE Event( ENr INT AUTO_INCREMENT NOT NULL, Event VARCHAR(100) NOT NULL, Type VARCHAR(100) NOT NULL, CONSTRAINT EventPN PRIMARY KEY(ENr) ); CREATE TABLE Place( Place VARCHAR(100) NOT NULL, Capacity CHAR(4) NOT NULL, CONSTRAINT PlacePN PRIMARY KEY(Place) ); CREATE TABLE Reservation( RNr INT AUTO_INCREMENT NOT NULL, Date date NOT NULL, 46

47 FromTime TIME NOT NULL, ToTime TIME NOT NULL, MaxParticipants INT NOT NULL, PlacePN VARCHAR(100) NOT NULL, EventPN INT NOT NULL, CONSTRAINT ReservationPN PRIMARY KEY(RNr), CONSTRAINT ReservationPlacePN FOREIGN KEY (PlacePN) REFERENCES Place(Place), CONSTRAINT ReservationEventPN FOREIGN KEY (EventPN) REFERENCES Event(ENr) ); CREATE TABLE Attending( RNr INT NOT NULL, PNr INT NOT NULL, Attending BOOLEAN NOT NULL, CONSTRAINT RNr PRIMARY KEY(RNr, PNr), CONSTRAINT AttendingReservationPN FOREIGN KEY (RNr) REFERENCES Reservation(RNr), CONSTRAINT AttendingPersonPN FOREIGN KEY (PNr) REFERENCES Person(PNr) ); CREATE TABLE Item( INr INT NOT NULL, Name VARCHAR(100) NOT NULL, 47

48 Description VARCHAR(500) NOT NULL, Category VARCHAR(50) NOT NULL, Price DECIMAL NOT NULL, CONSTRAINT ItemPN PRIMARY KEY(INr) ); CREATE TABLE ItemImage( IINr INT NOT NULL, INr INT NOT NULL, ImageURL BLOB NOT NULL, FileName VARCHAR(100) NOT NULL, FileType VARCHAR(10) NOT NULL, CONSTRAINT ItemImagePN PRIMARY KEY(IINr), CONSTRAINT ItemImageItemPN FOREIGN KEY (INr) REFERENCES Item(INr) ); Grade( GNr INT NOT NULL, ENr INT NOT NULL, PLNrINT NOT NULL, Date DATE NOT NULL FromTime TIME NOT NULL, ToTime TIME NOT NULL, AchievableGrade VARCHAR(100) NOT NULL, 48

49 SessionAmount INT NOT NULL, CONSTRAINT GradeNr PRIMARY KEY(GNr), CONSTRAINT GradeEventPr FOREIGN KEY (ENr) REFERENCES Event(ENr), CONSTRAINT GradePlacePr FOREIGN KEY (PLNr) REFERENCES Event(PLNr) ); GradeRegistration( PLNr INT NOT NULL, GNr INT NOT NULL, Achieved BOOLEAN NOT NULL, CONSTRAINT GradeRegistrationPlaceNr PRIMARY KEY(PLNr), CONSTRAINT GradeRegistrationGradePr FOREIGN KEY (GNr) REFERENCES Event(GNr), CONSTRAINT GradeRegistrationPlaceAndPerson PRIMARY KEY(PLNr, GNr), CONSTRAINT GradeRegistrationPlaceNr FOREIGN KEY (PLNr) REFERENCES Place(RNr), CONSTRAINT GradeRegistrationGradePr FOREIGN KEY (GNr) REFERENCES Grade(GNr) ); Place( PLNr INT NOT NULL, Type VARCHAR(100), Address VARCHAR(100) NOT NULL, PostalCode CHAR(4) NOT NULL, 49

50 About VARCHAR(500) NOT NULL, Monday VARCHAR(11), Tuesday VARCHAR(11), Wednesday VARCHAR(11), Thursday VARCHAR(11), Friday VARCHAR(11), Saturday VARCHAR(11), Sunday VARCHAR(11), CONSTRAINT PlaceNr PRIMARY KEY(PLNr) ); CREATE TABLE Course( CNr INT AUTO_INCREMENT NOT NULL, CourseName VARCHAR(100) NOT NULL, About TEXT(500) NOT NULL, MaxParticipants INT NOT NULL, PriceDetails TEXT(1000) NOT NULL, ImageURL TEXT(500) NOT NULL, FileName VARCHAR(100) NOT NULL, FileType VARCHAR(10) NOT NULL, CONSTRAINT CourseNr PRIMARY KEY(CNr) ); CREATE TABLE InstructorsOnCourse( 50

51 CNr INT NOT NULL, IPNr INT NOT NULL, CONSTRAINT InstructorsOnCourse PRIMARY KEY(CNr, IPNr), CONSTRAINT InstructorsOnCourseCNr FOREIGN KEY (CNr) REFERENCES Course(CNr), CONSTRAINT InstructorsOnCourseIPNr FOREIGN KEY (IPNr) REFERENCES Instructor(IPNr) ); CREATE TABLE Equipment( ENr INT AUTO_INCREMENT NOT NULL, Name VARCHAR(100) NOT NULL, Description VARCHAR(500) NOT NULL, Category VARCHAR(50) NOT NULL, Price DECIMAL NOT NULL, ImageURL TEXT(500) NOT NULL, FileName VARCHAR(100) NOT NULL, FileType VARCHAR(10) NOT NULL, CONSTRAINT EquipmentNr PRIMARY KEY(ENr) ); CREATE TABLE CenterInfo ( CINr INT AUTO_INCREMENT NOT NULL, Name VARCHAR(25) NOT NULL, AboutUs VARCHAR(250) NOT NULL, 51

52 OpeningHours VARCHAR(250) NOT NULL, VARCHAR(100) NOT NULL, Phone CHAR(8) NOT NULL, Address VARCHAR(100) NOT NULL, PostalCode CHAR(4) NOT NULL, CONSTRAINT CenterInfoNr PRIMARY KEY(CINr) ); CREATE TABLE News( NNr INT AUTO_INCREMENT NOT NULL, Title VARCHAR(25) NOT NULL, Message VARCHAR(250) NOT NULL, Created VARCHAR(250) NOT NULL, CONSTRAINT NewsNr PRIMARY KEY(NNr) ); 52