Att välja projektuppgift

Projektets syfte

Välja projekt: Allmänna kriterier

Att välja projekt är kanske inte helt lätt. Här ska vi ge lite hjälp. Vi kommer också att diskutera projektet under en föreläsning.

• Ni ska inte fortsätta med Tetris-projektet. Ni bör inte heller fastna alltför hårt i strukturen från Tetris-projektet, även om ni väljer att implementera ett spel (ett Breakout-spel är till exempel för nära Tetris). Utforska hellre nya delar av Java och OO. Vi tar hänsyn till detta i bedömningen.

• Projektet bör ha en liten kärna som kan utökas i många steg. Det är ju inte lätt att uppskatta exakt vad ni kommer att hinna med på de drygt 100 timmar som ni har för design, kodning, finputsning och dokumentation. Kan projektet byggas upp steg för steg, kan ni helt enkelt "programmera till tiden tar slut" och sedan avsluta, istället för att få panik för att inte allt ni tänkt er hinna med är klart. Då kan ni balansera projektets omfattning mot dess kvalitet.

  Detta kommer att reflekteras i er projektbeskrivning, där ni får dela upp projektarbetet i milstolpar att uppnå.

• Ni måste kunna visa upp hur ni uppnått målen i just denna kurs. Med andra ord, använd projektet till att lära er mer om just objektorientering, och visa upp i slutresultatet att ni kan utnyttja OO och Java på ett bra sätt. Ni behöver alltså ett projekt där ni aktivt använder klasser, ärvning, polymorfism, inkapsling av information, designmönster, och så vidare.

  Detta går bra i de flesta projekt, så ni behöver inte oroa er alltför mycket över det. Men ibland blir det för stark tyngdpunkt på annat än OO. Sådana projekt ska undvikas, även om de är roliga och intressanta ur ett "allmänt" programmeringsperspektiv! Ett par exempel:

  1. Android-projekt kräver mycket Android-specifik programmering som inte är direkt OO/Java-relaterad. Givet vår erfarenhet från tidigare år avråder vi starkt från detta.

  2. Bildbehandlingsfunktioner kräver mycket matrismatematik men kan ge ont om tid till användning av polymorfism, designmönster, osv.

• Undvik tidskrävande svårigheter som inte är kursrelaterade. Till exempel:

  1. Snygg grafik tar mycket tid. Eftersom detta inte är en designkurs kan vi inte premiera detta i bedömningen. Gör hellre enkel grafik och koncentrera er på programmering och OO.

  2. Snygga animeringar kan ta tid. Låt hellre rörelser förbli en aning hackiga, om de nu skulle råka vara det, och spendera mer tid på OO.

  3. Synkronisering över nätverk i realtid är mycket 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 mycket 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, och eftersom detta varken är en nätverkskurs eller en spelkurs är denna svårighet inget vi kan premiera i bedömningen!

Välja projekt: Exempel

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 som inspiration, till stor del från projekt som tidigare kursdeltagare har genomfört. 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. Här kan man göra en enkel grund och sedan bygga på gradvis med olika former, ritverktyg, och så vidare.

• En CPU-emulator där man kan köra små program för en påhittad eller verklig CPU-arkitektur. Här kan man bygga på med fler instruktioner, med visualisering av vad som händer i CPUn i varje steg, med funktioner för att spara och ladda program, och så vidare.

• Ett spel som inte sker i realtid utan "drag för drag", till exempel ett brädspel, kortspel, Word Wars, och så vidare. Gärna för två spelare, med nätverkskoppling mellan spelarna – utan realtidskrav blir det relativt enkelt att synkronisera dragen över nätet. Detta är en stor skillnad jämfört med actionspel där millisekunderna spelar roll och där det kan vara mycket svårt att få ett konsistent gemensamt tillstånd. Det går också bra att göra en enkel kärna som sedan utökas med att ladda och spara spelpositioner, med animerad flyttning av spelpjäser, med en enkel AI-spelare, och så vidare.

• 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 icke nätverksbaserat grafiskt "actionspel" (plattformar, bilspel, ...). Men tänk på att det kan vara krångligt att animera bilder, hantera kollisioner och så vidare i realtid, särskilt om man inte har hållt på med det förut.

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

• Ett program för att hålla reda på TV-serier med hjälp av information från thetvdb.com.

• 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 utvecklingsmiljö för ett eget programspråk, där man kan skriva, spara, och köra sina egna program. (Detta skiljer sig från CPU-emulatorn i att man programmerar på en mycket högre nivå.)

• En Instant Messaging-klient för ett existerande öppet och känt protokoll, till exempel Jabber/XMPP.

• En ljuddesigner där man kan skapa ljud med FM-syntes, med grafisk redigering.

• Ett budgetprogram där man kan hantera konton, transaktioner och en budget.

• Ett schemaprogram med gränssnitt mot TimeEdit, där man kan hålla reda på sitt schema, hitta lediga salar, och så vidare.

• En aktiemarknadssimulator

• En musikspelare (bara för den som själv vill ta reda på hur Javas mer avancerade ljudhantering fungerar!)

Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2015-02-05