Endringshistorie
| 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 |
Innhold
1. Introduksjon
1.1 Hensikt
Dette dokumentet skal gi en oversikt over arkitektoriske valg som vi har gjort gjennom utviklingen av systemet vårt.
1.2 Omfang
Dokumentet beskriver brukstilfeller og realisering av disse, oppbygningen av den logiske strukturen, brukergrensesnittet mot kundene, og antall mulige brukere samtidig.
1.3 Definisjoner og forkortelser
Det er ikke brukt noen forkortelser.
1.4 Referanser
- Spesifikasjon av brukstilfeller
- Realisering av brukstilfeller
1.5 Oversikt over dokumentet
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.
2. Hva omfatter arkitektur for Prosjekt B
- I dette dokumentet består arkitekturbeskrivelsen av
- Hvilke faktorer som påvitrker arkitekturmessige beslutninger (Kap 2)
- De viktigste brukstilfellene :
- bestille billett på nett
- hente bestilt billett
- kjøpe billett direkte i luken
- billettselger loger på systemet
- arrangør loger inn
- endre bygning/sal/forestilling/arrangement
- slette bygning/sal/forestilling/arrangement
- opprette ny bygning/sal/forestilling
- opprette nytt arrangement
For mer utfyllende informasjon se eget dokument - Spesifikasjon av brukstilfeller
Hvordan brukstilfellene er realisert, se kap 5.1
- En oversikt over systemets komponenter :
- Bestille billett på nett
- Side
- Kontroll
- Mysql
- Bestilling
- Hente bestilt billett
- GUI
- Kontroll
- Bestilling
- Arrangement
- Kjøpe billett direkte i luken
- GUI
- Kontroll
- Mysql
- Bestilling
- Billettselger logger på systemet
- GUI
- Kontroll
- Mysql
- Bestille billett på nett
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.
3. Arkitekturmessige mål og begrensninger
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.
4. Logisk View
- Skjermbilder : brukerens grensesnitt for søking og bestilling av billett, skrevet i html, css og php.
- Arrangør : Denne pakken inneholder klasser som kun “arrangøren” kan og har tilgang til å bruke. Operasjonene i disse klassene manipulerer innholdet i databasen så det er ikke anbefalt at enhver får tilgang til disse. Skrevet i php.
- Billett og Info : Denne pakken inneholder klasser som kunden trenger for å ha nytte av systemet, dvs operasjoner i forbindelse med bestilling og kjøp av billetter. I tillegg til henting av forskjellig informasjon. Skrevet i php.
- Sikkerhet : Pakke for å gi systemet et visst nivå av sikkerhet. Den er også nødvendig for å gi bruker tilgang til de andre pakkene. Skrevet i php.
- Tid : Pakken inneholder klasser som blir brukt til å hente tidspunkt fra databasen, vise tidspunkt, endre/legge til tid og andre funksjoner som har med tidspunkt å gjøre. Skrevet i php.
- Arrangement : hente ut informasjon fra tabellen Arrangement i databasen, skrevet i php.
- Bestilling : hente ut informasjon fra tabellen Bestilling i databasen, skrevet i php.
- Bygning : hente ut informasjon fra tabellen Bygning i databasen, skrevet i php.
- Forestilling : hente ut informasjon fra tabellen Forestilling i databasen, skrevet i php.
- Sal : hente ut informasjon fra tabellen Sal i databasen, skrevet i php.
- Plass : hente ut informasjon fra tabellen Plass i databasen, skrevet i php.
- Valider : hente ut informasjon fra tabellen Valider i databasen, skrevet i php.
- Oppbyggingen av systemet er basert på en 3-lags arkitektur
- Hvilke pakker inneholder hvert lag
- Kort beskrivelse av hver pakke og dens ansvar
- Diagram som viser strukturen
- Beskrive hvilken programvarelattform (PHP etc) som en komponent er implementert I
- Eks.: oppdeling I lag med flere pakker I hvert lag. (neste side)
- Merk: I eksempelet er det kun en kontrollerklasse under GUI pakken (Façade Controller).
- Ofte kan det være flere, feks en for hvert brukstilfelle (Use Case controller)
4.1 Oversikt - designmodell
4.2 Arkitekturmessig viktige moduler og pakker
5. Brukstilfelle View
5.1 Brukstilfelle diagrammer
5.1.1 Bestille billett
Kunden bestiller billett på internett.
5.1.2 Hente bestilt billett
Kunden kommer til luken for å hente bestilt billett. Billettselger logger på systemet, får referansenummeret av kunden og skriver ut bestilt billett.
5.1.3 Kjøpe billett direkte fra luken
Kunden kommer til luken får å kjøpe billett. Billettselger logger på systemet, selger billett til kunden og skriver ut billetten(e).
5.1.4 Billettselger logger på systemet
Når billettselger logger på systemet kan han skrive ut bestilt billett og selge billett til kunder.
5.1.5 Arrangør logger inn
Når arrangør logger på systemet kan han opprette ny sal/forestilling, opprette nytt arrangement og slette sal/forestilling/arrangement.
5.2 Realisering av brukstilfeller - Sekvensdiagrammer
5.2.1 Bestille billett på nett
5.2.2 Hente bestilt billett
5.2.3 Kjøpe billett direkte i luken
5.2.4 Billettselger logger på systemet
5.2.5 Arrangør logger på systemet
6. Beskrivelse av brukergrensesnitt
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.
- Innhold : Her skrives all tekst som du ser på sidene, bare ren tekst.
- CSS : All plassering av tekst og farger som utgjør utseendet gjøres her.
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.
7. Ytelser og størrelser
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.
8. Kvalitet
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.
]]>
]]>
