Software Design Document

Transcriptie

1 Software Design Document GameTrac Versie Datum Auteur(s) Opmerking /11/10 Matthijssens Roeland Eerste versie /11/10 Matthijssens Roeland Uses cases toegevoegd /12/10 Matthijssens Roeland Spellings fouten, afbeeldingen 1

2 Door hieronder te tekenen verklaart u akkoord te zijn met dit document en zijn inhoud. Het team Tom Strickx Brecht Van Laethem Bram Bruyninckx Roeland Matthijssens Gil Moeremans Goedele Van kerkhoven 2

3 Inhoudsopgave 1 Inleiding Doel Conventies Evolutie Acroniemen Termen Taak verdeling 5 3 Architecturaal design Vereisten Systeem structuur Multi-tier architectuur Three-tier architectuur Blok diagram Gebruikte technieken Logic-tier Python (fast)cgi Client tier (X)HTML CSS AJAX Database tier MySQL Databank model 10 6 Beschrijving vereisten Basis vereisten Inloggen Uitloggen Registreren Aanmaken van een spel Registreren op een bestaand spel

4 1 Inleiding 1.1 Doel Dit document bepaalt het design en samenhang van de software van groep 1. Het project doelt op het modelleren van een portaal web-site voor het aanmaken van location-based spellen. Door middel van gestructureerde diagrammen en modellen wordt een duidelijk overzicht gegeven van de structuur van de software. De modellen dienen als leidraad voor voor de implementatie van de software, en kunnen beschouwd worden als conventie voorschrift om de code duidelijk en consistent te houden. 1.2 Conventies Elke verandering in dit document zal beschreven worden op de eerste pagina. Elke verandering aan dit document vereist specifieke toelating van de design manager of, in geval van afwezigheid, zijn backup. Elke verandering in dit document moet goedgekeurd worden door de design manager of, in geval van afwezigheid, zijn backup. Iedereen die betrokken is bij het project, zij het klanten of staff-leden, krijgt de mogelijkheid om zijn/haar opmerkingen kenbaar te maken. Deze opmerkingen worden door de design manager of zijn backup binnen een realistische tijdspanne behandeld. Wanneer nodig geacht door de project manager of zijn backup zullen maatregelen getroffen worden betreffende deze opmerkingen. 1.3 Evolutie Het Software Design Document (SDD) zal frequent geupdate worden naargelang er nieuwe noden of gebreken bekend raken. Het document zal voorzien worden van een overzicht van deze evolutie, en gekenmerkt worden door een identificatie nummer. Dit nummer is van de vorm x.y. In het geval dat een belangrijke of grote update gedaan wordt zal het versie nummer (het x gedeelte) verhogen. Kleine aanpassingen zullen door een verhoging in het y gedeelte kenbaar gemaakt worden. 1.4 Acroniemen CSS: Cascading Style Sheet: Een techniek om de vormgeving van een set web-pagina s in een enkele file vast te leggen. HTML: HyperText Markup Language: Een opmaaktaal voor de specificatie van documenten, voornamelijk bedoeld voor Web-sites. AJAX: Asynchronous JavaScript and XML: Een term voor het ontwerp van interactieve webpagina s waarin asynchroon gevraagde gegevens worden opgehaald van de webserver. Daardoor hoeven dergelijke pagina s niet in hun geheel ververst te worden en kunnen dmv. javascript functies stukken van de pagina worden aangepast. SQL: Structured Query Language: Een gestandaardiseerde taal die gebruikt kan worden voor taken zoals het bevragen en het aanpassen van gegevens in een relationele databank. ERM: Entity Relationship Model: Een datamodel of diagram voor het grafisch representeren van een conceptueel datamodel. 4

5 CGI: Common Gateway Interface: Een standaard voor dataoverdracht tussen client en de server WSGI: Web Server Gateway Interface: Een eenvoudige universele interface voor communicatie tussen web-servers en web-applicaties in Python geschreven. 1.5 Termen Apache: Software voor het hosten van web-servers. Location-based spellen: Spellen waarbij de virtuele en de echte wereld elkaar aanvullen. JavaScript: Een programmeertaal die veel gebruikt wordt om webpagina s interactief te maken en webapplicaties te ontwikkelen. Wilma: Een multifunctionele linux-server voor de studenten van de faculteit Wetenschappen van de VUB. 2 Taak verdeling De Design manager is verantwoordelijk voor het onderhouden en aanpassen van het design document. Het is zijn taak om het team op de hoogte te houden van de veranderingen in het design. Wanneer problemen opduiken in het design is het de verantwoordelijkheid van de design manager om het design aan te passen. In het geval van kleine aanpassingen is het de design manager toegelaten zonder toestemmingen het design aan te passen. Bij grote aanpassingen zal de toelating van de project manager nodig zijn. In beide gevallen is het de taak van de design manager om de andere teamleden op de hoogte te houden van de veranderingen. De effectieve taakverdeling is terug te vinden in het SPMP. 3 Architecturaal design De architectuur van de software is het hoogste niveau van design. Op dit niveau wordt beschreven hoe de organizatie van het gehele systeem in zijn werk gaat. Dit niveau abstraheert van de componenten van de software en de onderlinge relaties en kenmerken van componenten. In deze sectie zal een overzicht gegeven worden over de gebruikte architectuur. De beschrijving van de subsystemen, en de communicatie tussen deze subsystemen zal tevens beschreven worden. 3.1 Vereisten De gekozen architectuur zal moeten voldoen aan de volgende vereisten Uitbreidbaarheid: Het moet eenvoudig zijn om functionaliteit toe te voegen aan het systeem. Flexibiliteit: Het moet eenvoudig zijn om bestaande functionaliteit aan te passen, om aan nieuwe vereisten te voldoen. Eenvoud: Het systeem moet eenvoudig te begrijpen zijn voor buitenstaanders. Dit verhoogt eveneens de mogelijkheid om teamleden aan te werven, of te vervangen. 5

6 Herbruikbaarheid: Voldoende abstractie moet hergebruik van het systeem, of stukken van het systeem mogelijk maken. Efficientie: De gekozen architectuur is efficient als het probleem effectief wordt opgelost, zonder nodeloze kosten, tijd, of inspanningen. 3.2 Systeem structuur Deze sectie beschrijft de structuur van het systeem. Om een goed begrip van het gebruikte systeem te garanderen zal eerst dieper ingegaan worden op het type van de architectuur dat gehanteerd zal worden. Namelijk de Multi-tier architectuur en meer specifiek de Three-tier architectuur Multi-tier architectuur De multi-tier architectuur beschrijft een client-server architectuur waarin de componenten van het systeem logisch onafhankelijke proccessen zijn. Deze architectuur gaat ervan uit dat de software componenten in twee groepen gesplitst kunnen worden : de service-providers en de service-requesters. De providers kunnen allerhande systemen zijn bijvoorbeeld databank servers, ftp-servers, etc... De requesters zijn de software componenten die de gebruikers hanteren, bijvoorbeeld web-browsers, -clients, etc... De meest gebruikte versie van deze architectuur is een die slechts uit 3 van zulke software componenten is opgebouwd. Ook voor dit project zal een three-tier architectuur gebruikt worden. Het feit dat deze architectuur ideaal is voor web-aplicaties, zoals ons project, heeft een sterke impact gehad op de keuze voor deze architectuur Three-tier architectuur Voor de portaal web-site werd gekozen voor een three-tier architectuur. Dit is een architectuur die slechts uit 3 componenten bestaat. deze componenten zijn gebruikers interface of client-tier Logic-tier of middel-tier, deze component wordt ook wel bussiness-logic genoemd. Databank of database-tier. Wanneer we dit toepassen op een web-applicatie zoals een portaal web-site krijgen we Web-browser Web-server Databank server Het splitsen van het systeem in kleinere deel systemen geeft enkele belangrijke voordelen. Omdat elk van de subsystemen gemakkelijker te implementeren is dan 1 groot systeem vergemakkelijkt het development process. Ook zorgt de modulariteit van het geheel ervoor dat subsystemen makkelijk kunnen aangepast worden onafhankelijk van de andere subsystemen. Er volgt nu een beschrijving van de subsystemen. 6

7 Client tier: Dit is de bovenste laag van de applicatie en is degene die de gebruiker van het systeem te zien krijgt. In het geval van een web-applicatie zal de client-tier bestaan uit een web-browser die op de Desktop van de gebruiker draait. De browser zal gebruikt worden om binnen de site te navigeren en om informatie over de spellen en spelers op te vragen. Bijvoorbeeld op welke spellen heb ik me ingeschreven?. JavaScript, HTML, CSS en AJAX zijn enkele technieken die gebruikt zullen worden om de gebruikersinterface te ontwerpen. Logic-tier: Deze module draait op een server en dient om alle berekeningen te maken en beslissingen te nemen op basis van de informatie beschikbaar in de databank. Deze applicatie dient dus als brug tussen de gebruikersinterface en de databank. Wanneer een gebruiker zou opvragen op welke spellen heb ik me ingeschreven? berekent de logic-tier op basis van wat in de database staat welke spellen op het scherm van de gebruiker zullen verschijnen. De logic-tier is vaak opgesplits in meerdere modules en is op zijn beurt dus ook multi-tiered. Database-tier Dit subsysteem bestaat uit een of meerdere databank servers. Hier wordt de informatie bijgehouden voor latere referentie. Deze module bewaart de data op een neutrale manier, onafhankelijk van de logic-tier en de client-tier. MySQL zal gebruikt worden voor deze module Blok diagram Een blok diagram is een voorstelling van een Three-tier architectuur voorzien van een voorbeeld van hoe de architectuur gebruikt wordt voor de portaal web-site. 7

8 4 Gebruikte technieken 4.1 Logic-tier Python Python is een geinterpreteerde hoog niveau programeertaal. De filosofie van de taal benadrukt gebruiksvriendelijkheid, en leesbaarheid van de code zonder in te boeten voor kracht en expressiviteit. Python ondersteunt meerdere programmeer paradigma s maar bied het meeste ondersteuning voor een object gerichte stijl (OO). Python werd gekozen als programmeertaal voor het project om de volgende reden: Python heeft dynamische typering. Python is een zeer expresieve taal, waardoor complexe stukken code op een elegantere, leesbaardere, vaak kortere manier kunnen neergeschreven worden dan in talen als C++ en JAVA. Python heeft een zeer goede ondersteuning voor object gericht programmeren, en het was een vereiste van het project dat een OO-stijl gehanteerd werd (fast)cgi De eerste keuze om de Apache server met de code te laten comuniceren was door gebruik te maken van WSGI. Dit was niet mogelijk omdat de code op de Wilma server moet draaien, en er geen ondersteuning gegeven wordt voor WSGI. Als alternatief werd er dan voor CGI gekozen. Maar omdat CGI scripts traag zijn, omdat voor elke request naar de server de python interpretor opnieuw moet worden opgestart, werd geopteerd om over te schakelen naar fast-cgi. Fast-CGI zal de python interpretor slechts een keer runnen, en de requests doorsturen naar deze interpretor, wat veel performantiewinst betekent. 4.2 Client tier Voor de gebruikers interface zal gebruik gemaakt worden van een web-browser. Om de interface te maken zal dus gebruik gemaakt worden van technieken als AJAX, CSS en javascript. 8

9 4.2.1 (X)HTML HTML is de dominante manier om web-pagina s op te bouwen, en wordt door vrijwel elke webbrowser ondersteund. De structuur van HTML laat toe om op een eenvoudige manier pagina s te genereren op de server. Alle nodige technieken om het project tot een goed einde te brengen worden ondersteund door html. Bijvoorbeeld links naar pagina s, embedded fotos en interactieve forms CSS Cascading Style Sheets zullen gebruik worden om de opmaak van de site op een generische manier te bepalen. Het gebruik van CSS laat toe om de volledige opmaak aan te passen zonder de eigenlijke html structuur te veranderen. Daarenboven kunnen meerdere CSS-files gemaakt worden, zodat de gebruiker de layout van zijn pagina zelf kan kiezen. Vrijwel elke web-browser ondersteunt CSS voor HTML en voor XHTML AJAX Asynchronous JavaScript and XML zal gebruikt worden om de pagina s interactief te maken. Het laat toe om stukken van een pagina aan te passen, en op de achtergrond requests naar de server te sturen. Dit heeft 2 grote voordelen. Ten eerste heeft de gebruiker minder vertraging in het browsen, want de pagina s kunnen deels aangepast worden, zonder een hele nieuwe pagina te moeten aanvragen. Ten tweede zal het de server een last sparen aangezien het de stukken HTML die op elke pagina getoond worden slechts een keer moet genereren in plaats van voor elke request. De banners en het logo zijn bijvoorbeeld stukken van de HTML die niet zullen veranderen. 4.3 Database tier MySQL MySQL is een relationeel database management systeem dat als een server draait en ondersteuning geeft voor multi-user acces. MySQL is een zeer veel gebruikte database voor zowel grootschalige als kleinere applicaties. MySQL is op veel vlakken beter dan het alternatief SQLite, alleen op portability scoort SQLite beter. Maar omdat voor dit project een web-applicatie gebouwd wordt, is portability geen groot probleem. Omdat een web-applicatie toelaat aan veel gebruikers om tegelijk requests te sturen is MySQL een betere keuze. Elke keer er naar de database geschreven wordt zal SQLite de database afsluiten, waardoor andere requests zullen moeten wachten. MySQL heeft dit probleem niet, en is dus beter geschikt voor web-applicaties dan SQLite. 9

10 Nog enkele redenen waarom er voor MySQL gekozen werd: Een grote community Open-Source Zeer goede performantie Zeer betrouwbaar Makkelijk te gebruiken Goede integratie van Python met MySQL 5 Databank model Een ERM wordt gebruikt om een overzicht te geven van de structuur van de gebruikte database. 6 Beschrijving vereisten 6.1 Basis vereisten In deze sectie zullen de basis vereisten van de portaal web-site besproken worden. De manier waarom dit zal gebeuren is aan de hand van use-case diagrammen. Deze worden opgebouwd gebruik makend 10

11 van use-case analyses. Het doel hiervan is een grafische voorstelling te bieden van de functionaliteit die het systeem biedt in functie van de actors, hun doelen en afhankelijkheden tussen de taken Inloggen Om in te loggen zal de gebruiker naar de login-pagina moeten surfen. Daar zal hij de mogelijkheid krijgen om zijn gegevens in te vullen. Wanneer hij zijn gegevens naar de server post, zal er geverifieerd worden of deze gegevens juist zijn en indien dit niet het geval is zal een foutboodschap getoond worden. Wanneer de server de gegevens aanvaardt, en de gebruiker dus ingelogd wordt, zal in de database een sessie voor de gebruiker aangemaakt worden. Ook zal een unieke code in een cookie geplaatst en doorgestuurd worden naar de gebruiker zodat voor de volgende requests de juiste sessie uit de database gehaald kan worden. Eventueel kan de server dan ook de nodige html als response sturen zodat de gebruiker doorverwezen wordt naar de home-pagina Uitloggen Om uit te loggen zal de gebruiker op de logout knop drukken. Hierdoor zal de server de sessie van deze gebruiker in de database als inactief zetten. De volgende keer er een request gedaan wordt met de cookie van die gebruiker, (en zijn unieke code), zullen toch opnieuw de gegevens van die gebruiker gevraagd worden. Ook zal de gebruiker naar de home-pagina doorverwezen worden. 11

12 6.1.3 Registreren Om te registreren zal de gebruiker naar de registratie pagina surfen. Daar worden de nodige gegevens gevraagd. Nadat de gebruiker zijn gegevens gepost heeft, zal de server deze gegevens verifiëren. Net als bij het inloggen zal de server foutmeldingen weergeven wanneer nodig. In het geval dat de gebruiker alle nodige informatie heeft gegeven wordt een nieuw account aangemaakt in de database. Daarna zal de gebruiker naar de login-pagina doorverwezen worden, en kan hij met zijn gegevens inloggen Aanmaken van een spel Om een spel aan te maken zal de gebruiker naar de juiste pagina moeten surfen, waar om de nodige gegevens gevraagd wordt om een spel aan te maken. Om het zoeken van spellen te vergemakkelijken zal ieder spel van een naam en van een van de speltypes voorzien moeten zijn, eventueel kan een aantal beschrijvende woorden gegeven worden. Deze informatie zal gecontroleerd worden door de 12

13 server. Indien alles in orde is zal op basis van de template van het spel-type een spel aangemaakt worden. Dit spel plaatst de server dan in de database. Als tweede stap bij het aanmaken van het spel kan de gebruiker locaties toevoegen aan zijn spel. Dit gebeurt door de locatie waar de QR-tag geplaatst zal worden in te geven, en de informatie die getoond moet worden wanneer de tag gescanned wordt in te geven. Indien er al locaties gespecifieerd werden binnen het spel zal de server een lijst van deze locaties beschikbaar maken, zodat locaties aan elkaar gelinkt kunnen worden Registreren op een bestaand spel Om zich in te schrijven op een bestaand spel kan de gebruiker een lijst vragen van alle bestaande spellen, of zoeken naar bepaalde woorden die met de tag of naam van de resulterende spellen moet matchen. De server zal de gevraagde spellen oplijsten, waarna de gebruiker op het gewenste spel kan klikken. Dan krijgt de gebruiker de mogelijkheid om zich op het geslecteerde spel in te schrijven. De server zal deze informatie in de database opslaan. 13