TDDC69 Objektorienterad prog. och Java

Projektuppgift

Introduktion till projektuppgift

I projektuppgiften kommer ni att få designa och implementera ett eget objektorienterat program från grunden. En viktig poäng är att ni ska få använda de tekniker ni har lärt er utan att vara bundna av en fördefinierad uppgift eller ett kodskelett. Därför är projektuppgiften väldigt fri.

Språket som används i projektet är Java, version 7.

Att välja projekt

Att välja projekt är kanske inte helt lätt. Några saker att ha i åtanke är:

• Efter att vi räknar bort föreläsningar och inledande labbar bör det bli ungefär 100-110 timmars arbetstid kvar till projektet inklusive dokumentation (vilket är en del av examinationen), finputsning och demonstration. Det projekt ni väljer måste vara så litet att ni hinner med det, men samtidigt så stort att det motsvarar den tänkta omfattningen.

• Det är extremt svårt att uppskatta utifrån en specifikation hur lång tid ett projekt tar att genomföra. Därför rekommenderar vi starkt att ni hittar ett projekt som kan byggas upp steg för steg, på ett sådant sätt att ni efter varje steg kan avsluta om tiden börjar ta slut. Då kan ni balansera projektets omfattning mot dess kvalitet.

• Projektet ska vara objektorienterat. Det betyder inte bara att ni programmerar i ett objektorienterat språk, utan också att det läggs en viss vikt på att ni demonstrerar att ni kan utnyttja objektorientering på ett bra sätt för att uppnå era mål. Vissa typer av projekt lämpar sig mindre bra för detta. Om ni skulle vilja implementera bildbehandlingsoperatorer kan det t.ex. kräva stora mängder matrismatematik men väldigt lite användning av polymorfism, designmönster, och så vidare. Det är inget fel med att implementera detta i ett objektorienterat språk men det ger er inte så stor möjlighet att visa vad ni har lärt er inom just OO.

Ni får som sagt välja projekt fritt. För de som inte vill hitta på något själva har vi följande förslag. De olika funktionerna hos programmen är bara exempel. Välj och vraka, och kombinera beroende på vad ni har tid för och är intresserade av – och ge gärna egna förslag till framtida kurser!

• Ett vektorritprogram / CAD-program.

• En CPU-emulator där man kan köra små program för en påhittad eller verklig CPU-arkitektur, med grafisk visualisering av vad som händer i CPUn i varje steg.

• En FTP-klient.

• Ett brädspel för två spelare, med nätverkskoppling mellan spelarna.

• Ett enklare grafiskt "actionspel" i stil med Breakout / Arkanoid, alternativt ett plattformsspel.

• Ett kalenderprogram där användaren kan boka tider. Tänkbara finesser: Visa grafiskt i olika vyer. Kanske drag-and-drop i den grafiska vyn? Sökning. Utskrift av schema. Export till standardiserade kalenderformat.

• Ett grafiskt ZIP-verktyg. Java har inbyggt stöd för ZIP-formatet i paketet java.util.zip. Lägg till filer, extrahera filer, testa arkiv, sortera fillistan i olika ordning...

• En distribuerad fraktalvisare. Använd flera datorer samtidigt för att räkna ut fraktaler – Mandelbrot, Julia, ...

• Ett system för att skapa, visa och skriva ut UML-diagram från existerande Java-klasser, med möjlighet att manipulera diagrammen på skärmen.

• En Instant Messaging-klient för ett existerande öppet och känt protokoll, till exempel Jabber (som också används i Google Talk).

Att tänka på – råd och tips

Innan ni börjar vill vi gärna att ni läser genom dessa råd och tips. En del kan verka självklara, men läs ändå genom dem från början till slut. Alla råd och tips kommer från konkret erfarenhet i tidigare projekt i denna kurs, och många av dem har sitt ursprung i tidigare studenters erfarenhetsrapporter!

• Planera innan ni börjar skriva kod! Detta betyder inte nödvändigtvis att ni vet exakt hur programmet ska se ut innan ni skriver en enda rad kod – vi förespråkar inte vattenfallsmodellen. Däremot kan man spara mycket tid på att ta en ordentlig funderare på t.ex. vad programmet ska göra, ungefär hur funktionaliteten kan delas upp mellan olika klasser, och så vidare.

• Om ni utvecklar t.ex. ett grafiskt spel är det viktigt att inte spendera för mycket tid på själva bilderna (spelpjäser, rymdskepp, ...). Detta är trots allt en kurs i objektorienterad programmering, inte spelgrafik eller ens spelprogrammering. Tror ni att ni ändå har tid att göra snygga bilder, gör dem då sist när ni ser att ni verkligen har tid över.

• Tight synkronisering över nätverk är svårt! Det kan vara väldigt roligt att implementera ett nätverksspel för flera spelare, men håll er i så fall till brädspel eller liknande. Att utveckla t.ex. ett plattformsspel där spelarnas förflyttningar och andra händelser synkroniseras i realtid över nätet är svårare än man kan tro. Det är lätt hänt att man får spendera veckor bara på att få en bra implementation av denna synkronisering.

• Fastna inte i sådant som är mindre relevant för kursen! Vi har redan nämnt att man inte ska spendera för mycket tid på att göra snygga bilder om man väljer att göra ett spel. Att animera bilderna är ytterligare ett exempel, även om det är mer programmeringsrelaterat: Vill ni få en spelarfigur att röra sig snyggt över skärmen kan det ta mycket tid och kräva mycket lågnivåprogrammering. Låt hellre rörelsen förbli en aning hackig, om den nu skulle råka vara det, och spendera mer tid på den objektorienterade programmering som faktiskt examineras i kursen.

• Tänk efter hur ni kan utveckla programmet stegvis så att ni hela tiden kan testa programmet, verifiera att det fungerar, och se konkreta resultat! Programmering är roligt, men att verkligen se ett fungerande program är ännu roligare. Planera därför ett antal delmål, där varje delmål kan vara relativt litet, kan klaras av relativt snabbt, och kan testas och användas konkret! Gör ni på det sättet kan ni dessutom vara mer säker på att ni har ett fungerande program när perioden tar slut, även om ni inte har hunnit med alla funktioner ni tänkte er från början.

  Tänk er t.ex. att ni skriver ett vektoriserat ritprogram och att ni börjar med att implementera den interna representationen av alla 30 grafiska former ni vill stödja och därefter skriver kod för att rita upp varje form på skärmen. Det tar ganska lång tid. Får ni sedan problem med mushanteringen i GUIt kanske ert färdiga program kan visa 30 former men inte flytta dem eller spara en ritning till en fil...

  Tänk er istället att ni börjar med en generell basklass för former plus en rektangelklass, samt en struktur för att hålla reda på alla former som finns i en ritning. Därefter programmerar ni en enkel testklass som skapar 10 rektanglar och lägger in dem i ett ritningsobjekt, och skriver ett enkelt GUI som bara kan rita upp ett ritningsobjekt, inte manipulera det grafiskt. Vips har ni en milstolpe: En användbar ritningsvisare för rektanglar. Sedan implementerar ni ytterligare 3 formtyper (cirklar, linjer och trianglar) och testar dem. Nästa milstolpe: En mer generell ritningsvisare. Därefter går ni vidare till kod för att skapa grafiska former med musen, vilket tar lite tid men när det är klart har ni ytterligare en milstolpe. Att spara dina ritningar till disk och läsa in dem igen blir nästa milstolpe. Därefter går ni vidare med att kunna flytta former som redan är skapade (milstolpe), och att ändra attribut som färger (milstolpe). Sedan inser ni att ni bara hinner med två former till och måste skippa komplicerade splines – men ni har ett fullt fungerande program och har hela tiden kunnat känna glädjen av att ni kommer framåt.

  I ett grafiskt spel där en spelare rör sig i en värld skulle ni på motsvarande sätt kanske implementera grundläggande uppritning av en spelare (en rektangel!), därefter ett sätt att styra spelaren från tangentbordet, sedan en enkel grafisk värld att röra sig i, sedan kollisionshantering, sedan en korkad fiende – inte en snygg värld och intelligenta fiender innan spelaren ens kan röra sig runt i världen.

  Ta er alltså en ordentlig funderare på hur ni kan dela upp programmeringen i steg där ni kan känna att ni har åstadkommit så mycket så möjligt efter varje enskilt steg – och skriv ner en punktlista som visar er själv i vilken ordning ni ska utveckla programmet. Detta är viktigt både för att programutvecklingen ska bli roligare och för att ni ska kunna minska ambitionsnivån om det tar längre tid än ni hade tänkt er!

Användning av klassbibliotek

I projektet får ni använda alla klasser i Java 7:s klassbibliotek.

Ni får också använda andra klassbibliotek och fritt tillgängligt material som bilder eller ljud. I detta fall måste ni skriva ner i projektbeskrivningen vilket material ni har använt som inte är en del av Java 7. Tänk dock på att användningen av klassbibliotek inte får resultera i att ni själva saknar tillfällen att visa upp era kunskaper i objektorienterad programmering, designmönster och så vidare!

Steg 1: Projektbeskrivning

En projektbeskrivning måste skrivas och lämnas in till labbhandledaren. En projektbeskrivningsmall i OpenOffice-format är tillgänglig och innehåller mer instruktioner.

Beskrivningen måste först lämnas in en gång tidigt i projektet. Den största anledningen till detta är att er handledare ska kunna ge er feedback på era tankar runt projektet. Ingen hård deadline finns, däremot en mjuk (se deadlines). Ju tidigare ni lämnar in, desto större chans att ni får feedback i tid.

När projektet lämnas in ska även en uppdaterad version av projektbeskrivningen lämnas in.

Steg 2: Programutveckling

Under programutvecklingsfasen följer ni de milstolpar som ni skrev ner i projektbeskrivningen. Tänk även på att dokumentera regelbundet. Upptäcker ni problem uppdaterar ni projektbeskrivningen – den är inte en kravspecifikation, utan projektet kan vid behov ändras under tiden. Diskutera gärna större ändringar med labbhandledaren.

Diskutera också projektet med labbhandledaren på labbtillfällena, gärna en gång i veckan. Be om feedback på lösningar ni har gjort och ta chansen att fixa eventuella problem så tidigt som möjligt, även om vi så klart inte kan garantera att allt upptäcks vid 5 minuters "inspektion".

Tänk på att projektet är till för att ni ska lära er, och visa att ni har lärt er, både Java och objektorientering. Fundera hela tiden på vad som är ett bra objektorienterat sätt att implementera!

Steg 3: Finputsning

Se till att vara klara med alla finesser/features i er slutliga "produkt" i tillräckligt god tid för att kunna finputsa programkod och dokumentation inför demonstration och inlämning. Det är oftast bättre att ha ett projekt med lite mindre omfattning men högre kvalitet än att ha ett större antal features som tyvärr inte riktigt fungerar. Sätt av tid till detta!

Steg 4: Demonstration

Ni kommer att ha runt 15 minuter att demonstrera ert projekt för labbhandledaren i sista veckan. (Det går även bra att demonstrera tidigare om handledaren har tid.)

• Var förberedda! Allt ska gå att starta smidigt när labbhandledaren kommer till er.

• Om projektet är för buggigt kan handledaren välja att gå vidare till en annan grupp så att ni får försöka igen senare. Är programmet för buggigt när sista labbtillfället närmar sig sitt slut kan ni bli hänvisade till omredovisning efter nyår.

• Demonstrationen inleds med att ni själva demonstrerar funktionaliteten i projektet under några minuter. Var beredda på att visa hur det används och att visa upp de finesser ni själva tycker är viktigast givet tidsbegränsningen.

• Efter att ni demonstrerar funktionaliteten går handledaren vidare till själva programkoden, där varje gruppmedlem ska visa några aspekter av koden. Ni kan till exempel visa upp några designmönster ni har använt eller några andra övergripande aspekter (inte små detaljer).

• Labbhandledaren kan också ställa några (individuella!) frågor runt objektorienterad programmering: Vad menas med polymorfism? Varför vill man gömma information? Vad är skillnaden på ärvning mellan klasser och när man implementerar ett gränssnitt? Varför kan designmönster vara bra? Vad finns det för relation mellan meddelanden och metoder? Och så vidare. Var beredda på att svara.

• Till slut lämnar ni in ett ifyllt labbomslag där ni skriver under att ni har följt alla labbregler på IDA. Förbered omslaget innan demonstrationen.

Steg 5: Inlämning

Vid den slutliga inlämningen, senast i tentaperioden, ska ni lämna in följande:

• Den uppdaterade projektbeskrivningen, i .ODT-format alternativt .PDF-format.

• Programkoden, som en ZIP- eller tar.gz-fil enligt de allmänna instruktionerna.

• En lista på eventuella ändringar som har gjorts efter påpekanden av labbhandledaren under demonstrationen. Om inga ändringar har gjorts ska ni uttryckligen tala om det.

Se även inlämningsproceduren för mer information.

Krav för godkännande

För att ni ska få godkänt måste projektet uppfylla dessa krav. Fråga gärna labbhandledaren om ni verkar vara på rätt väg!

• Projektkoden måste hålla tillräcklig kvalitet. Svårläst, buggig och ostrukturerad kod är stora minus.

  Ett första steg är att följa de allmänna kraven på programkod. Detta är samma krav som har gällt för labbarna, men vi kommer att hålla hårdare på kraven under projektet – dels på grund av dess större omfattning, dels på grund av att ni nu har haft tid att lära er mer.

• I projektet måste det synas att ni har lärt er objektorienterade och Java-relaterade begrepp och att ni vet hur dessa ska användas. Det har två följder:

  • Givet att ni har ett problem som kan lösas på ett objektorienterat eller icke objektorienterat sätt ska ni använda den objektorienterade lösningen, om den inte är uppenbart sämre. Om ni kan lösa samma problem med subtypspolymorfism eller med en switch-sats som har grenar för olika objekttyper är det subtypspolymorfism som ska användas. Detsamma gäller för Java-begrepp: Använd inte heltalskonstanter om en enum skulle passa bättre och vara typsäkrare.

  • I vissa fall kan ni behöva utgå från lösningen och hitta ett passande problem. Om ni har ett projekt där inga designmönster passar in skulle det normalt inte vara problematiskt. Projektet är ju vad det är, och lösningar utgår ifrån de problem man faktiskt har. I en sådan här kurs leder det däremot till att ni inte får en chans att öva på designmönster eller visa att ni kan använda dem, vilket är ett problem. Därför kan ni i just den här situationen behöva justera projektet så att designmönster (och/eller polymorfism, subklasser, gränssnitt, ...) faktiskt kommer till användning: Hitta ett problem där ett designmönster är en bra lösning!

• För att ni ska få godkänt måste projektet också ha en omfattning som motsvarar projekttiden på cirka 100-110 timmar. Detta är så klart svårt att mäta på ett helt objektivt sätt. Att mäta det "i förväg" och ange vilka milstolpar som måste uppnås för att få rätt omfattning är till och med omöjligt om vi inte ska spendera veckor på att skriva extremt detaljerade krav. Vad vi kan säga i förväg är detta:

• Omfattningen har en viss betydelse, men är sekundär. Mycket hög kvalitet och mycket bra användning av objektorienterade begrepp kan väga upp liten omfattning. Men det är svårt för oss att godkänna ett projekt som ser ut att motsvara 30 timmars arbete!

• Bland de projekt som har tillräcklig omfattning finns det sällan något projekt med mindre än 1000 rader kod. Många av de bästa projekten är klart större än så.

  Detta betyder inte att vi räknar kodrader och gör en bedömning utifrån det. Vi bedömer omfattningen utifrån många andra kriterier som också har att göra med bland annat "svårighetsgrad", komplexitet och variation, och omfattningen är som sagt bara ett sekundärt kriterium. Men tidigare år har det visat sig att de som klarar kraven oftast har minst 1000 rader kod.

  Vår rekommendation: Fokusera främst på kvalitet och att utnyttja era timmar väl. Om ni är oroade över omfattningen, fråga främst er labbhandledare. I sista hand, räkna kodrader för att få en allmän uppfattning.

• Dokumentation: En projektbeskrivning måste lämnas in enligt tidigare instruktioner, uppdaterad enligt instruktionerna i beskrivningen. Projektkoden måste också dokumenteras enligt de allmänna kodkraven. Det kan vara lämpligt att ha Javadoc-kommentarer för alla klasser. Kod som är viktig, icke uppenbar eller potentiellt svår att förstå måste också dokumenteras. Tänk på att handledaren och examinatorn ska läsa genom hela projektet!

Betyg och betygskriterier

Projektet ges betyg 3, 4, 5 eller komplettering. Tre betygskriterier är:

• Bra användning av objektorientering och Java (t.ex. polymorfism där detta passar)
• Hög kodkvalitet (välstrukturerad, läsbar, tillräckligt dokumenterad)
• Projektets omfattning (till viss del, se ovan)

För de högre betygen ställs högre krav inom dessa tre områden. Kraven är tyvärr svåra att kvantifiera på ett sätt där man omedelbart ser när man har uppnått nivån för ett visst betyg: Var går gränsen för "god läsbarhet"? Diskutera gärna med labbhandledaren för att få preliminär feedback.

För varje betygsnivå finns även följande krav.

Krav	Betyg 3	Betyg 4	Betyg 5
För varje betygsnivå måste ett visst antal designmönster implementeras och användas, för att ni ska visa att ni behärskar dem. Designmönstren måste användas på ett lämpligt sätt, dvs. varje mönster måste användas för att implementera funktionalitet där det mönstret faktiskt passar. Detta kan till viss del påverka vilken funktionalitet ni implementerar. Designmönstren ska implementeras från grunden. Om ni använder en Comparator som argument till Javas sorteringsmetoder räknas det inte som att ni har implementerat Strategy-mönstret.	1 mönster	2 mönster	3 mönster
För varje betygsnivå måste ni peka ut ett visst antal lösningar ni har gjort där ni använder objektorienterade "finesser" som t.ex. polymorfism, och diskutera kortfattat hur man kunde ha löst detta utan objektorientering.	1 st	2 st	3 st
För varje betygsnivå måste ni beskriva ett visst antal designbeslut ni har tagit, med särskild tonvikt på användning av objektorientering. För varje designbeslut ska ni beskriva vad ni ville åstadkomma, hur ni gjorde, minst en annan alternativ lösning, och varför den lösning ni gjorde var bättre än alternativet. (I vissa fall kanske ni inser att den lösning ni valde var sämre än alternativet – beskriv då varför.) Detta ska vara andra lösningar än de som kommer från punkten ovan. Designbesluten ska vara på rimligt hög "objektorienterad nivå", dvs. inte varför ni valde att använda "int" istället för "long" för ett visst fält... Använde ni en enda lyssnarklass för knapparna i ett GUI, eller flera? Använder ni fabriker, prototyper eller vanliga konstruktorer för att skapa brickor i Breakout?	2 beslut	5 beslut	8 beslut
För varje betygsnivå måste den slutliga projektbeskrivningen innehålla minst ett visst antal UML-diagram. Varje diagram ska illustrera en specifik aspekt av projektstrukturen och åtföljas av en beskrivning enligt instruktionerna i mallen.	1 diagram	2 diagram	4 diagram

Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2012-09-07