Prosjekt B

Systemarktitektur 4.0

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

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

• 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.