Första veckan Gruppen satte sig ner för att ha ett öppningsmöte där vi disskuterade upplägget för projektet, vilka funktioner vi skulle ha med och en generellt övergripande blick på hur vi ska lösa dessa uppgifter. Vi började med en brainstorm för att få fram många olika idéer för att sedan solla i ett par omgångar så att vi bara behöll de bästa funktionerna och lösningarna. När vi väl hade kommit fram till hur projektet skulle vara uppbyggt så började vi med designen. En handfull dokument har producerats, däribland UML-diagram, flowcharts, ER-diagram, användarscenarion, kravspecifikation, målformuleringar samt projektavgränsningar. Vi har valt att dela in projektgruppen i två lag, ena laget kommer främst att arbeta med klientsidan och användargränssnittet medan det andra arbetslaget kommer att syssla med serversidan och databaskopplingen. Vi har identifierat vissa problem och utmaningar som vi kan komma att uppstå, däribland hur servern och klienten ska kunna kommunicera på ett bra sätt, och hur skyffling av object mellan olika lager ska ske. Vi kommer att använda oss av MVC och Trelagersarkitekturen för att separera på databaslagret, logiken och användargränssnittet. De tekniker vi hade tänkt att använda oss av är RMI för koppling mellan serverapplikation och klientapplikationen. Vi jämförde lite med CORBA, men för detta system så var RMI bättre anpassat då CORBA är mer svårkonfigurerat och anpassat för större affärssystem. Mellan serverapplikationen och databasen kommer en teknik som heter Hibernate att användas. Hibernate utvecklas av Red Hat och JBoss Community. Hibernate är den mest frekvent använda lösningen för databaskopplingar ute på företag, och då kändes det som en god idé att få en större inblick i denna teknik. Hibernate skapar en spegling av databasen i applikationen i form av entiteter. Detta gör att man inte behöver skriva SQL-satser själv, utan hela databasen blir i stort sett objektorienterad. Man kan alltså skicka ett helt objekt till databasen, och Hibernate sköter allt bakomliggande jobb. Det enklaste sättet är att använda sig av Criterias, men vill man ha total kontroll så kan man använda HQL (Hibernate Query Language), som bygger på det robusta språket SQL men gör det möjligt att skriva objektorienterad kod med arv och dynamiska bindningar till databasen. För att mappa upp detta så har vi använt oss av Annotations i form av EJBs (Enterprise Java Beans). Andra veckan Förberedelserna är klara och all dokumentation som behövs för att sätta igång med utvecklingen av applikationen är färdigställd. Det första som behövde göras är att sätta igång databasen. Vi valde att använda databasen MySQL av kostnadsskäl och för enkelhet men ändå för en kraftfull och stabil lösning. Efter att vi hade satt upp och konfigurerat den samt lagt till alla tabeller och fält så var det bara att få igång en koppling mellan databaslagret på serverapplikationen mot databasen. Hibernate är mycket lätt att använda när man väl har fått igång konfigurationen. Detta var det första stora problem som uppkom. Varje tabell i databasen var tvungen att vara speglad i applikationen, vilket vi skapade entiteter för. I entiteterna så svarade annotations och Enterprise Java Beans för kopplingen mellan metoderna och fälten i databasen. När detta var klart så var vi tvungna att skapa en konfigurationsfil där man mappar upp alla kopplingar, referenser och även hur Hibernate ska bete sig. Här ställer man även in konfigureringar för en så kallad Connection Pool. Hibernate har en egen Connection Pool om man väljer att använda den istället för att skapa en egen, vilket vi gjorde. Därefter skapade vi en sessionsfabrik som skulle ha hand om sessionerna mot databasen. När en session mot databasen startar så öppnas även en transaktion. Detta medför att tabellen i databasen låses när en transaktion sker, så att flera transaktioner inte kan skriva eller läsa från en databasta- 1 KTH Haninge
bell samtidigt. Genom detta får man inte några så kallade Dirty Reads". Denna metod kallas Pessimistic Approach", sombetyder att man säkerställer att inga fel kan förekomma, till skillnad från Öptimistic Approachsom bygger på tanken att fel händer såpass sällan så att det inte är något problem med att inte låsa tabellerna vid en transaktion. Eftersom Pessimistic Approach låser tabellen så är denna metod något slöare eftersom andra trådar måste vänta på varandra innan de kan använda tabellen, men man vinner istället säkerhet. Databasen och transaktionerna är uppbyggda enligt ACID-modellen. Detta står för Atomicity, Consistent, Isolation samt Durable, och om man följer detta så får man en stabil och välutvecklad databas. Om ett fel skulle uppstå (ett exception genereras) när en transaktion bara har hunnit halvvägs genom att modifiera en tabell, så sker en Rollback. Då återställs alla ändringar som gjorts i databasen av den transaktionen, så att tabellen inte blir korrupt på grund av att den bara blev halvt uppdaterad. Mer på klientsidan så har vi utvecklat konverteringar från persistenta entiteter till detached objects, så att man ska slippa ha en session öppen när objektet skickas mellan serverapplikationen och klientapplikationen. När det väl är dags igen att spara eller uppdatera objektet till databasen så konverteras det igen från ett transient objekt till en persistent entitet. Tredje veckan Vi har skapat hela kedjan som objekt kommer att slussas genom, från datalagret genom logiklagret ut till fasaden. De flesta funktioner för att hantera data till och från databasen är klart. Detta har medfört vissa klurigheter till och från, men med utmärkt hjälp av Hibernates dokumentation och Google så har de problem kunnat lösas utan större svårigheter. Några få finslipningar av databasen har genomförts, men inget som kommer att ändra någon funktionalitet. På logiklagret så har vi använt en Bubblesort-algoritm för att sortera listor, men efter ett stresstest med den så märkte vi att den algoritmen var alldeles för krävande för större listor med fler än 20 element att sortera. En genomsnittlig sorteringstid för Bubblesort-algoritmen är n2, och vid vidare forskning i ämnet bestämde vi oss för att använda Divide and Conquer algoritmen MergeSort, vilket har en statisk sorteringstid på n log n, oberoende av antalet element i listan. Att implementera en Divide and Conquer-algoritm visade sig vara lite mer problematiskt än väntat, och när den väl var på plats så visade det sig att den var mycket mer optimerad för sortering jämfört med Bubblesort, som väntat. På klientsidan har vi utvecklat en MD5 krypterings-algoritm som krypterar lösenord innan de skickas över nätverket. På detta vis skickas aldrig ett lösenord i klartecken. När det gäller RMI-strömmar så kommer de att vara serialiserade när de skickas över nätverket, så även om någon försöker sniffa trafiken så kommer det att vara mycket svårt, om inte omöjligt, att urskilja objekten från RMI-strömmarna. Vi har spenderat mycket tid på att fundera över arkitekturen i applikationen under tiden, just för att göra det så skalärt som möjligt. Detta betyder att man lätt kommer att kunna byta ut, uppdatera eller lägga till moduler utan att behöva programmera om massa onödiga kringsaker. Detta anser vi en självklarhet i en applikation som framåt i tiden ska kunna vidareutvecklas. Vi har även gjort utökade tester med alla Hibernate-metoder för att säkerställa att dessa fungerar som de ska och utan några problem. När varje modul är slutförd så buggtestar vi dessa, så att vi inte upptäcker buggarna för sent när man måste programmera om andra moduler som bygger på en modul som inte fungerar korrekt på grund av att vi inte har gjort tillräckligt med tester. 2 KTH Haninge
Fjärde veckan. Denna vecka har vi haft stor framgång gällande flera delar av projektet. En av de största nyheterna är att Project COFFEE nu har en egen hemsida på webben, där man kan följa projektets gång och läsa om uppdateringar, framsteg och även lämna förslag om förbättringar till det excellenta utvecklar-teamet. Hemsidan finnas på en server som hostas av KTH, och man kan komma åt den via http://www.colossos.se/coffee i webbrowsern. Senare så kommer addressen ersättas av http://coffee.colossos.se. En andra stor nyhet är att vi har fått godkänt av vår handledare, Håkan Strömberg, att vi får göra detta projekt. Utöver detta så har vi arbetat mycket med det grafiska gränssnittet och fått ett första utkast på hur vårt forum kommer att se ut. Vi har prövat oss fram med olika tekniker, och vi valde att använda oss av lite mer avancerade Swing-objekt för att på ett snyggt sätt bygga upp en trädstruktur över forumet. Klientapplikationen och serverapplikationen har hittills utvecklats enskilt, men nu har vi börjat sammanföra dessa två genom en fungerande RMI-anslutning. Sammanförningen genererade några problem och felmeddelanden, men de kunde lösas ganska snabbt. Det största problemet med sammanfogandet var att Hibernates säkerhetshanterare konfliktade med RMIs säkerhetshanterare, men efter att ha läst lite om hur man inkorporerar dessa för att kunna arbeta tillsammans så kunde även det lösas utan alltför stora svårigheter. Eftersom vi nu har sammanfört klientapplikationen med serverapplikationen så krävdes utökade tester för att se att alla funktioner fungerar som det är tänkt. Vi var tvugna att rätta till en hel del, och uppdatera ett par funktioner i fasaden som var utdaterade. Vi har utvecklat en enkel filhanterare som använder sig av serialization, där man sparar objekt till filer. Informationen sparas lokalt på datorn, och innehåller bland annat information om vilka servrar som finns tillgängliga för användaren. Femte veckan. Denna vecka har mest handlat om att bygga på RMI-uppkopplingen mellan server och klient så att alla funktioner fungerar som de ska. Detta fungerar nu utmärkt och en handfull av funktioner har testats. Basen har vi byggt på en hel del, så att den ska stödja framtida påbyggnader. Det grafiska gränssnittet har fått sig en uppiffning och även det har blivit utvecklat för att stödja chatt- och forumfunktioner. Det går nu alldeles utmärkt att logga in, skapa konto och så vidare. Projektet är byggt på att ha en mycket stark bas som man sedan lätt kan bygga vidare på, istället för att bygga modul för modul. Detta har vi märkt ha medfört att vissa funktioner har tagit något längre tid att implementera än beräknad då den mesta tiden hittills har gått åt till att bygga grunden. När grunden är färdigställd och väl utvecklad så kommer det dock att vara lätt att snabbt bygga på moduler. Projekttiden börjar dra sig mot sitt slut, men vi kommer att hinna med det som vi hade planerat. Vi valde att satsa på, som tidigare nämnt, en stabil grund till projektet, även om detta medför färre funktioner att visa upp till redovisningen så kommer det att vara mycket enklare för oss att vidareutveckla även efter projekttidens slut. Nyckelordet är skalärt. Har man ingen bra grund så kommer varje ny modul att ta mycket längre tid att implementera efter hand. 3 KTH Haninge
Vi har också gått igenom koden en extra gång och snyggat till den en del. När man skriver mycket kod på en gång så blir det lätt lite rörigt ibland, och en städning då och då behövs för att snygga till det. På detta sätt så slipper man även framtida förvirringar. Vi har lagt upp ett litet skelett för projektrapporten, och vi kommer att spendera en del tid på den nästkommande vecka samtidigt som vi har ett par nya funktioner planerade att skapa. Sjätte veckan. Denna vecka har varit något stillastående för projektet. Gruppen har kämpat och slagits tappert mot demoner (sjukdomar) som fällt sitt mörker över oss. I slutet av veckan har dock mörkret börjat skingras och ljuset lyser åter igen mot Project COFFEE, som nästa vecka ska ta upp kampen för bättre kod. Det som mest har skett är lite planering och sedan även upplägget av rapporten i stort. Rapporten beräknas vara klar lagom tills dess att redovisningen äger rum. Nätverkslagret för projektet är helt klart. Det blev klart mer invecklat än från början tänkt, men detta för att säkerställa enklare implementation av kommande moduler, istället för att bygga en nätverkslösning för varje modul för sig, som även tidigare nämnt. Vi har utvecklat vidare på de tekniker vi valde att använda oss av i början. Några fler tekniker har inte behövts läggas till i efterhand, då vi hade en mycket stark dokumentation och planering innan vi började knacka kod. Nästa vecka kommer garanterat att bli mycket mer intensiv, då det är en hel del saker vi ska finslipa och några funktioner ska implementeras. Vi ska även föra ihop grunden till projektet till en helhet. Följ oss på bloggen så får ni se hur nästa vecka kommer att te sig! Sjunde veckan Slutspurten. Efter några dagars bortfall förra veckan på grund av sjukdom så har projektet nu kommit igång igen och jobbar för fullt. Veckan har till stor del spenderats på att förbättra de redan existerande moduler på serversidan och optimerat dessa. Algoritmen Divide and Conquer har implementerats helt i systemet och används vid en Merge Sort av en ArrayList med objekt. Utöver optimering så är datalagret i stort sett helt klart för de funktioner som vi kommer att implementera för detta projekt. Den grafiska delen av projektet är i full gång och här har vi kommit riktigt långt. Alla de grafiska delarna som behövs är programmerade. Vi har kommit på andra intressanta upplägg av det grafiska, men det är något som man kan fixa i efterhand och ingenting som är nödvändigt för projektet, mest en ytterligare estetisk del. Utöver detta så har givetvis en hel del tid gått åt till att skriva rapporten, förbereda presentationen och även gå igenom tidrapporterna och andra dokument så att allt är uppdaterat och stämmer överens. Vi känner att vi har uppnått de mål (äntligen) somvi har ställt på detta projekt under denna period. Det finns även mycket rum för expansioner och påbyggnader av projektet, vilket kan vara en rolig sommarhobby att arbeta på. Vi sitter nu tillsammans och kör utförliga tester för att säkerställa att buggar inte finns och att kommunikationen mellan server och klient fungerar felfritt. Programmet börjar se riktigt färdigt ut, och man kan nu utnyttja de tjänster som finns. 4 KTH Haninge
Det har varit en hektisk vecka, men vi har hunnit med mycket arbete. Äntligen så börjar vi se slutet på detta projekt och de faser vi hade planerade. Det var verkligen ett ambitiöst projekt för två personer och denna korta tid vi egentligen hade, men då får man komplettera med att jobba hårdare och dricka mer kaffe. Hittills har det varit mycket roligt och vi har lärt oss många nya saker, speciellt sammansättningen i ett stort system. Det har även lags mycket fokus på nätverkslösningar och även den grafiska delen, hur man bygger upp en sådan på ett bra sätt för att användaren ska känna sig hemma i systemet. Ett komplext projekt med många delar som vi har sammanfogat, vi har fått många nya erfarenheter och kunskaper inom ett väldigt brett område. 5 KTH Haninge