Sakfrågan Preliminär specifikation

Transkript

1 KTH Programutvecklingsprojekt, 2D1954 Nada - Institutionen för Numerisk analys och datalogi Sakfrågan Preliminär specifikation Amr El-Ghazaly Joakim Andersson John Holmström Jens Modig Carl Drott Ranin Jouda

2 PROBLEMBESKRIVNING... 3 Bakgrund... 3 Syfte... 3 Krav och avgränsningar... 3 Funktioner... 3 Användare... 4 FÖRSLAG TILL LÖSNING... 5 MODULER... 5 Databasserver... 5 Connection pooling via jdbc... 5 Servlets... 5 JSP/XHTML/CSS... 5 Systemskiss... 5 DATORMILJÖ... 5 Hårdvara... 5 Mjukvara... 6 GENOMFÖRANDE... 7 ARBETSGÅNG... 7 Vald metod... 7 Ansvarsfördelning... 7 TIDSPLANERING... 7 Administration... 7 Design... 7 Implementation... 7 Systemtester... 8 Dokumentation...8 Total planerad tid... 8 RISKANALYS... 9 BILAGA Systemskiss BILAGA Skiss av användargränssnittet BILAGA Databasstruktur

3 Problembeskrivning Bakgrund Detta projekt utgör kursen programutvecklingsprojekt. Projektgruppen består av tre personer från Datateknik (Joakim, John och Ranin) och tre från Industriell ekonomi (Amr, Jens och Carl). Projektet gruppen har valt att genomföra är beställt av Oskar Rönnberg på Svenska Institutet för Tillämpad Beteendeanalys. I Projektet ska vi ta fram en hemsida som presenterar argument för och emot olika aktuella politiska sakfrågorna. Inför emu-valet kan man tänka sig att en sådan fråga lyder: Ska Sverige gå med i EMU?. Syfte Syftet med detta projekt är att hjälpa folk i ett virrvarr av löften, påståenden och argument kring olika politiska sakfrågor. Hemsidan är tänkt att skapa någon form av ordning i detta virrvarr av argument för att folk själva lättare ska kunna bilda sig en egen välgrundad uppfattning. Krav och avgränsningar Ett krav är att varje sakfråga ska utformas till ett opartiskt påstående i den mån det är möjligt. Detta ligger naturligtvis inte inbyggt i den tekniska lösningen utan detta ligger på den eller de som driver sidan. Sidan ska vara lättanvänd för användarna, man ska inte behöva läsa någon manual för att komma igång. Tanken är att sidan ska fungera i nyare versioner av Explorer, Netscape/Mozilla samt Opera utan tredje parts program installerade. Vi lägger stor vikt vid en trevlig och lättöverskådlig design av sidan. Rent tekniskt så försöker vi bygga mjukvarulösningen så att den klarar många samtidiga användare. Då vi inte har en stor användarbas så är det svårt att verifiera att lösningen uppfyller kraven på tillgång vid hög belastning. Vi försöker som sagt i största möjliga mån ta hänsyn till att lösningen klarar hög belastning, men det är naturligtvis ingenting vi kan garantera. Både hårdvara och mjukvara kan komma att behöva uppgraderas vid ökad popularitet för sidan. Eftersom användarvänlighet är så pass viktigt kommer vi att utföra användartester. Vi kommer i huvudsak använda oss själva, beställaren Oskar Rönnberg och eventuellt kamrater för dessa tester. Funktioner Man ska kunna registrera sig som en användare, samt logga in som en användare. Det ska gå att lägga upp samt ta bort sakfrågor (Detta gör normalt en administratör). För varje sakfråga kommer två forum att skapas, ett för och ett emot sakfrågan. Det ska även gå att lägga in argument för eller emot en viss sakfråga. Om något argument är olämpligt (dvs. tveksamt ur laglig synvinkel) så kommer det finnas möjlighet för en priviligerad användare (Administratör eller Moderator) att plocka bort argumentet. Argumentet tillsammans med användarinfo kommer att sparas undan för ev. framtida användande. Det ska gå att rösta på argument man tycker är bra. För att undvika okynnesröstning kommer detta kräva att man är en inloggad användare och man kommer bara att få rösta på argument för den sida man själv förespråkar. Det ska gå att läsa de bästa argumenten (högst röstpoäng) för/emot en sakfråga. Det är även tänkt att man ska ha en separat röstning direkt i sakfrågorna, ungefär som kvällstidningarna brukar ha på sina hemsidor (t ex Aftonbladet.se). 3

4 Användare Organisationer som använder sig av hemsidan skulle t ex kunna tänkas vara Sveriges riksdag eller någon partipolitiskt obunden förening. Huvudsaken här är att man gör det på ett objektivt sätt samt har ett genuint intresse för politik och en vilja att få allmänheten att intressera sig för politiska frågor. Administratör för hemsidan: Denne kan lägga till/ta bort sakfrågor. Kan även ta bort argument samt lägga in officiella meddelanden. Administratören utser också moderatorer till de olika sakfrågorna. Administratören kan också stänga av användare och moderatorer. Moderatorer för sakfrågor: Dessa är tilldelade en eller flera sakfrågor där de ska läsa igenom argument samt plocka bort dessa vid behov (tex. om ett inlägg är olagligt). Registrerad användare: Personen kan skriva argument för/emot olika sakfrågor. Denne får också ta ställning för eller emot en viss sakfråga och därmed bara rösta på argument för den sida som valts. Innan val av sida i en sakfråga kan användaren inte rösta på argument i den sakfrågan. Anonyma användare: Kan skriva/läsa inlägg samt rösta i sakfrågor. En anonym användare får inte rösta på enskilda argument för eller emot en sakfråga. 4

5 Förslag till lösning Moduler Databasserver På servern lägger vi en databas som lagrar alla data om systemet, t ex användarinfo, betyg, argument och sakfrågor. Som databasserver kommer vi använda Postgresql. Servern kan ligga på en egen dator eller också lägger man den på samma dator som applikations-/webbservern. Åtkomsten till databasen sker genom en applikation i java. Vill man byta databasserver ska det i princip räcka med att flytta över databasstrukturen samt byta ut drivrutinen för uppkopplingen mot databasen. För databasstruktur se bilaga 3. Connection pooling via jdbc Connection pooling är ett sätt att snabba upp åtkomsten mot databasen. Det går i princip ut på att man håller ett antal uppkopplingar öppna mot databasen och delar ut dessa till servletinstanser vid behov. På detta sätt undviker man den långsamma procedur det innebär att behöva skapa en ny uppkoppling mot databasen vid varje förfrågan. Connection pooling realiseras som en Java-applikation. Jdbc är drivrutinen som sköter kommunikationen mellan databas och Java-applikationen. Servlets För varje användare skapas en servlet-instans som sköter logiken mellan databas och presentation. Det kan tex. vara att från databasen hämta de argument som ska presenteras för en viss användare och skicka dessa argument vidare till JSP delen för presentation av dessa. JSP/XHTML/CSS JSP:S uppgift är att ta emot samt sända data till en servlet-instans och tillsammans med XHTML/CSS presentera dessa för klienten, dvs. användaren. För skiss på användargränssnitt se bilaga 2. Systemskiss Se bilaga 1. Datormiljö Hårdvara Vilka hårdvaruresurser som krävs på serversidan är naturligtvis svårt att säga eftersom det helt beror på hur många besökare sidan ska betjäna. Det viktiga på serversidan vid hög belastning är att servern har mycket internminne och snabba hårddiskar (gärna SCSI-raid). Processorns hastighet spelar mindre roll men den får gärna ha stort cacheminne. Vi kommer att köra servern på ett system med en AMD Athlon 800MHz, 512Mb RAM och en hårddisk på 20 Gb samt Linux (Slackware) som operativsystem. Behovet av bandbredd ökar naturligtvis också i 5

6 takt med att antalet användare växer, men eftersom det rör sig om relativt små datamängder så torde en 10Mbits uppkoppling räcka långt. På klientsidan krävs det bara en dator med Internetuppkoppling i hårdvaruväg. Mjukvara På serversidan kommer vi som applikations-/webbserver köra Tomcat. I Tomcat kör vi JSP/XHTML/CSS för presentation av data och Servlets för hanteringen av data som hämtas från databasen, kompilatorn som används för JSP/Servlets är Jikes. För javaklasserna som hanterar databasuppkopplingen krävs att JRE1.4.x SE från SUN Microsystems är installerat. Postgresql är den databasserver som vi kommer att utveckla i så det är naturligtvis önskvärt att det är denna som används, det går att utan alltför mycket jobb köra en annan databasserver om man så önskar. På klientsidan är tanken att det som tidigare nämnt ska räcka med en modern webbläsare (Typ Internet Explorer 5.x eller senare) utan att man behöver installera något extra. 6

7 Genomförande Arbetsgång Vald metod Vi har inte valt någon av de metoder som presenterades på föreläsningarna. Vi har istället delat in oss i mindre grupper (se nedan) och arbetar på de olika modulerna gruppvis. Sedan har vi tät kontakt under veckorna via e-post. Vi planerar även in möten cirka en gång i veckan. Under dessa möten diskuterar vi problem och ser till att alla har någonting att göra. Behöver vi träffas utöver planerade möten så går det oftast bra. Vi har även regelbunden kontakt med uppdragsgivaren (Oskar Rönnberg). Ansvarsfördelning Vi anser inte att vi behöver någon gruppledare i egentlig mening utan vi har utsett Amr till att vara kontaktperson utåt. I övrigt har vi gjort en grovindelning vad gäller implementeringsbiten. Där tre av oss (Jens, Carl och Amr) tar hand om den presentationsmässiga biten, dvs. design och JSP/XHTML/CSS delen. Övriga tre (Joakim, John och Ranin) jobbar mer med den tekniska biten, dvs. databasimplementation samt logik i servlets. Dokumentationen hjälps alla åt med. Tidsplanering Administration Vi planerar in ungefär ett möte i veckan, varje möte beräknas ta mellan en och två timmar. Vid varje möte väljs en sekreterare, en ordförande har vi inte funnit nödvändigt. Möten med beställare(oskar Rönnberg) har vi ungefär varannan vecka, dessa beräknas ligga på ungefär två timmar. Vi räknar med att genomföra sammanlagt 12 gruppmöten samt 5 möten med beställaren. Detta ger 30 timmar gånger fyra deltagare alltså är runt 120 timmar avsatta för möten. Design Designen av Användargränssnittet: avsatt tid är 140 timmar. Dessa timmar är fördelade över hela perioden till den 17 April då systemet ska vara klart. Design av Databas: Avsatt tid är 50 timmar, designen är tänkt att vara klar senast vecka 10. Implementation Databasinstallation samt konfigurering: Avsatt tid är 10 timmar, detta skall vara klart senast vecka 11. Databasimplementation: Avsatt tid är 20 timmar, detta arbete utförs parallellt med installation och konfigurering av databasen. Även detta ska vara klart senast vecka 11. 7

8 Databaskoppling: Avsatt tid är 90 timmar, härifrån förs eventuellt timmar över till databasimplementationen beroende på hur mycket logik (triggrar, stored procedures mm.) vi lägger i databasen. Detta är tänkt att vara klart i slutet av vecka 13. Installation samt konfigurering av Tomcat: Avsatt tid är 10 timmar. Skall vara klart i vecka 11. Servlets/JSP; Avsatt tid är 100 timmar. Ska vara klart i vecka 15. XHTML/CSS: Avsatt tid är 50 timmar: Ska vara klart vecka 17. Systemtester Enhetstester: De som tar fram modulen ansvarar också för att köra verifieringstester på modulen. Vi har avsatt 40 timmar för detta, dessa tester ska vara körda innan slutdatum för respektive modul. Användartester: Avsatt tid är 40 timmar. Testerna genomförs under utvecklingstiden. Sista testet körs i vecka 17 på det färdiga systemet. Dokumentation Källkoden dokumenteras av respektive författare fortlöpande under tiden den skrivs. För Javakod används Javadoc som genererar html-dokument ur kommenterad källkod. För övrig källkod sker dokumenteringen direkt i källkodsfilen. Detta har vi avsatt 20 timmar till. Projektbeskrivning arbetas fram fortlöpande, detta dokument beskriver systemet som tagits fram, tänkta användare, lite kort om problem mm. Avsatt tid är 40 timmar. Användarhandledning tas fram i projektets slutskede och riktar sig mest till dem som ska installera och driva hemsidan, vi tar också fram en kort handledning för användarna av hemsidan. Avsatt tid är 40 timmar och kommer främst att användas mot slutet av projektet när systemet är färdigt. Systembeskrivning är av teknisk natur och beskriver hur systemet är uppbyggt. Hur olika Vilka moduler som ingår, hur dessa är uppbyggda samt hur dessa hör ihop. Här har vi avsatt 40 timmar och dessa kommer att användas när systemet är färdigprogrammerat. Vi har till sist avsatt 20 timmar till förberedelser inför samt genomförande av förhandsvisning och presentation. Total planerad tid Totalt har vi till vårat förfogande 160*6 = 960 timmar (fyra poäng och 6 personer i gruppen). Den planerade tiden ovan summeras till 830 mantimmar. Sju föreläsningar a 2 timmar för sex personer ger avrundat nedåt 80 timmar. För dokumentet om projektarbete räknade vi med 7 timmar per två personers grupp, detta ger ungefär 20 timmar. Detta dokument har tagit ungefär 30 timmar i anspråk. Sammanlagt ger detta 960 timmar. 8

9 Riskanalys En stor risk är att vi misslyckas med gränssnittet. Man kan inte nog betona vikten av ett bra gränssnitt i detta system, misslyckas det så får sidan helt enkelt inga besökare. Vi har därför valt att lägga ner en stor del av tiden på designen av gränssnittet i förhållande till övriga delar, vi kommer även att utföra användartest med prototyper så vi inte låser in oss på en lösning. Vi kommer även att försöka nyttja beställaren för test då han är väldigt engagerad i idén. En ytterligare risk är att systemet inte klarar hög belastning utan att behöva göras om från grunden. Blir det långa väntetider så är inte heller det bra för besöksstatistiken. Här har vi lite problem, vi vet inte riktigt hur vi ska kunna testa systemet under hög belastning. Det vi kan göra är att försöka optimera delar där man vet att stora flaskhalsar finns. I det här fallet ligger en stor del av tidsförlusterna i uppkoppling mot databasen och det har vi som sagt tänkt hantera genom connection pooling. Vi har också delat upp systemet i moduler så det torde vara relativt enkelt att optimera en modul utan att påverka de andra. 9

10 Bilaga 1 Systemskiss 10

11 Bilaga 2 Skiss av användargränssnittet 11

12 Bilaga 3 Databasstruktur 12