Dato | Versjon | Beskrivelse | Person |
---|---|---|---|
23.04.04 | 1.1 | Første utkast | Øyvind Østlund, Arild Soltvedt |
27.04.04 | 1.2 | Lagt til brukstilfelle diagram og sekvensdiagram. Fylt inn i kap 1. designmodell | Arild Soltvedt |
28.04.04 | 3.0 | Lagt til 4.2 , tatt bort litt i 5.1 , lagt til kap 6 og 7 | Øyvind Østlund, Arild Soltvedt |
10.05.04 | 4.0 | Endret 4.2. Endret 5.1. | Arild Soltvedt, Åshild Nerhus |
Dette dokumentet skal gi en oversikt over arkitektoriske valg som vi har gjort gjennom utviklingen av systemet vårt.
Dokumentet beskriver brukstilfeller og realisering av disse, oppbygningen av den logiske strukturen, brukergrensesnittet mot kundene, og antall mulige brukere samtidig.
Det er ikke brukt noen forkortelser.
Vi vil gå gjennom brukstilfeller og realisering av disse, oppbygningen av den logiske strukturen, se på hvordan brukergrensesnittet mot kundene er lagt opp, og til slutt si noe konkret om antall mulige brukere samtidig.
For mer utfyllende informasjon se eget dokument - Spesifikasjon av brukstilfeller
Hvordan brukstilfellene er realisert, se kap 5.1
For sekvensdiagram se kap 5.2
En server eller tjener er den eller de maskiner som kjører nettverksrelaterte applikasjoner og leverer data til andre datamaskiner i nettverket.
Systemet vårt er kun web basert, dermed velger vi HTML, CSS, PHP, MySQL som våre verktøy for å realisere prosjektet. Systemet trenger en Apache eller IIS server som støtter PHP og har MySQL installert for å kunne kjøre systemet. Dette er ikke noe problem i starten, siden vi har fått utdelt en eple konto hvor alt dette er ordnet på forhånd. Må vi flytte prosjektet et annet sted senere, så må vi passe på at serveren(e) har disse minimumskravene. Brukerne selv trenger en datamaskin med kravene som er listet i punkt 7.1 i Visjonsdokumentet.
Målet for applikasjonen er at det skal bli et felles brukergrensesnitt for alle typer billettbestilling. Det skal være web basert for både billettbestillere og folk som sitter i billettluken. Det skal ikke være nødvendig for en bruker å ha internett for å bestille billetter. De kan komme rett i luken for å bestille, men poenget er at de som ikke har tid eller lyst til å dra til billettluken for å bestille billetter, skal kunne gjøre dette hjemmefra i fred og ro. Det skal være mulig for alle arrangører som ønsker å ta dette systemet i bruk å få en konto på serveren vår så de kan legge til saler, arrangementer også videre, så deres kunder kan bestille over nett.
Vi regner ikke med at alle arrangører i hele norge kommer til å ta systemet i bruk med en gang. Derfor nøyer vi oss med en konto på eple for å starte prosjektet. Dette begrenser bruken en del i første omgang, men vi regner med å kunne ha opp til 2-3000 brukere for dagen er ikke urealstisk at systemet skal takle. Det blir fredags kvelder og romjulen som blir de store flaskehalsene, samt når store artister kommer til landet og biletter blir lagt ut for salg. Når vi får mange nok arrangører som bruker systemet vårt og slike hendelser ser ut til å forbigå 2-3000 brukere på en dag, må vi invistere i en eller flere servere til, som vi kan flytte systemet over på. Systemet i seg selv har ingen begrensning i antall brukere samtidig. Det er båndbredden og server kapasiteten som nøye må overvåkes i fremtiden etter hvert som det blir flere arrangører/brukere som tar systemet i bruk.
En vanlig kunde skal ikke kunne gå inn i systemet og endre oppsatte arrangementer, dette er det arrangører som skal gjøre. Arrangørene får tilgang til flere funksjoner enn bare å bestille billetter. Endre bygning/sal/forestilling/arrangement og slette bygning/sal/forestilling/arrangement er funksjoner som krever passord for innlogging, og skal ikke kunne nås av andre personer/kunder. Innlogging for arrangører skjer via egen innloggingsside for å opprettholde sikkerheten.
I dette tilfelle kan det også være naturlig å ta med teknisk arkitektur her, siden den er gitt: Ta med et diagram som viser hvordan web-server, databaseserver er organisert og samvirker.
Kunden bestiller billett på internett.
Kunden kommer til luken for å hente bestilt billett. Billettselger logger på systemet, får referansenummeret av kunden og skriver ut bestilt billett.
Kunden kommer til luken får å kjøpe billett. Billettselger logger på systemet, selger billett til kunden og skriver ut billetten(e).
Når billettselger logger på systemet kan han skrive ut bestilt billett og selge billett til kunder.
Når arrangør logger på systemet kan han opprette ny sal/forestilling, opprette nytt arrangement og slette sal/forestilling/arrangement.
Brukergrensesnittet er laget med størst mulig vekt på rene linjer og enkel logikk for brukeren, det skal ikke være nødvendig å lete seg i hjel etter noen funksjoner. Funksjonene skal være enkle og lettfattelige.
Prosjektet har 2 hoved sider (bold). En side for kunder og en for bilettluker og arrangører. Her kan arrangørene logge seg på, og komme inn til menyer hvor de kan velge hva de vil gjøre. Legg merke til at bilettluken kommer inn på kundene sine sider hvis en kunde kommer inn uten å ha bestilt bilett på internet. Alle navnene på tekstboksene er navnet på filene. Alle filene har etternavn .php. Merk at de stiplede linjene er veien tilbake når en operasjon er utført.
Serveren som oppgaven ligger på kan ta 256 henvendelser samtidig. Utenom dette vil den holde i live 100 henvendelser til, som vil slippe til så fort noen er ferdig med å bestille billett. Det vil si at så lenge systemet ligger på Eple, så kan vi maksimalt ha 122880 henvendelser i døgnet. Vi må regne med at i snitt er nesten halvparten av disse henvendelsene billettkontorer og arrangører. Det vil si at serveren klarer 61440 bestillinger fra kunder i døgnet. Men dette er det optimale. Ved slipp av billetter til store forestillinger/arrangementer så vil pågangen i perioder være mye større, enn andre tider på døgnet, sov ved nattetider. Så begrensningen som er viktigst å få med seg er at det kun kan være 256 henvendelser på samme tid. Dette vil holde i starten, men når flere kinoer, teater osv adopterer systemet vårt er det ikke nok lenger. Ved store slipp av billetter som ved Ringenes Herre forestillinger kan det komme flere tusen henvendelser samtidig. Det er viktig å få med seg at ikke båndbredden er flaskehalsen, men at det er serveren som ikke klarer mer. Løsningen i fremtiden her vil være å bruke flere servere. Og spre de størst underholdningsarenaene kommer på forskjellige servere. På den måten kan vi spre henvendelsene likt utover serverne.
Vi regner med at systemet skal klare 2-3000 henvendelser for dagen. Antall treff samtidig skal da ligge på ca 200 i timen. Er serveren som setter grensene.
Slik som systemet er implementert nå, så er arrangørene selv ansvarlig for å slette gamle arrangementer. Dette er ikke optimalt. Det burde vært lagt til en ”nattkjørings” funksjon som slettet gamle arrangementer så det ikke tar opp unødvendige systemresurser, og forlenger søk hastigheten på de forskjellige sidene.
Vi har blitt pålagt å bruke MySQL for databasen. Dette krever at skal systemet benyttes ved en annen server, så må MySQL være installert. MySQL finnes dor alle de store operativsystemene så i utgangspunktet er systemet vårt plattformuavhengig. Brukerene av systemet trenger kun en maskin med internettilgang, og en grafisk nettleser for å bruke systemet.