Praktikum i programvaruproduktion

Transkript

1 Praktikum i programvaruproduktion

2 Introduktion Föreläsare/Ansvarig: Pontus Boström Rum A5055 Assistent: Petter Sandvik Rum: A5048 Föreläsningar: Kurssida: Kursen betsår av att utföra ett lite större projekt Arbetet uförs i grupper (2 pers/grupp)

3 Projekt: Uppgiften är att konstruera en enkel musikspelare som kan spela olika typer av ljudfiler: Spelar det som Javas ljudsystem klarar av (.vaw,.mp3,.ogg,...) Se beskrivning av uppgiften

4 Arbete Tidigare har studeranden fått en uppgift som lösts självständigt på egen hand I år ska en utvecklingsprocess följas Efter varje steg i processen diskuteras lösningarna på det senaste steget i utvecklingsprocessen Det här betyder strikta deadlines på de olika delmomenten Missad deadline betyder 0 poäng för den uppgiften För att få godkänt behövs Man har utfört varje steg i utvecklingsprocessen (Gjort reviews) Som tidigare år lämnas allt material in via ett subversion repository. Ett repository/grupp

5 Verktyg UML ArgoUML rekommenderas Dvs andra modellformat kan nödvändigtvis inte läsas av läraren Programmering Eclipse Versionhantering Subversion Subclipse plugin för Eclipse Testning Junit plugin för Eclipse

6 Utvecklingsprocess En typ av waterflow model Arbetet uförs i fem steg Kravanalys 1, beskrivning i text Kravanalys 2, domänmodell Design Programmering, iteration 1 Programmering, iteration 2 Kravanalys 1 För att kunna konstruera ett program måste man veta vad man vill ha Uppgiften ger bara en grov överblick av funktionaliteten för spelaren I det här steget skall precisa krav på funktionaliteten definieras Kravanalys 2 I det här steget beskrivs domänen för spelaren mera precist med UML diagram Tillståndsmaskiner används för att beskriva hur händelser ska hanteras

7 Utvecklingsprocess Design I det här skedet skapas en detaljerad design av spelaren i UML Programmering, iteration 1 Spelaren kan på ett ganska bra sätt delas upp två delar, spelare och hantering av spelningslistor I den här iterationen skapas spelaren Programmering, iteration 2 I den här iterationen görs hantering av spelningslistor De integreras också med själva spelaren

8 Krav Krav Är uttryck för intressenternas behov av ett system för att nå ett speciellt mål Beskriver hur ett system skall fungera utan att ta ställning till hur funktioner i systemet ska implementeras Är grundpelaren för utvecklingen av ett system Indelning av krav Funktionella krav Icke-funktionella krav T. ex. Kvalitetskrav, spelningen ska ha hög kvalitet (inga hopp) Krav bör skrivas så att de är verifierbara Det ska gå för en person eller maskin att kontrollera att mjukvaran uppfyler kraven Kravdokument format Rational Unified Process - Template for Software Requirements Specification

9 Kravanalys 1 Flera olika sätt att samla och organisera krav för ett program Use cases (Användningsfall) User stories Problem frames Ett långt textdokument utan egentlig ordning... Användningsfall hör till de vanligare sätten Används här för att beskriva spelarens funktio Två aktörer Användare AudioSystem (Ljudsystemet)

10 Användningsfall Användningsfall: Spela ID: SP1 Aktörer: Användare Förvillkor: Inget Flöde av händelser: 1. Användaren väljer en fil att spela 2. Stoppa eventuell pågående spelning 3. Användaren klickar på spela knappen 4. Spelaren börjar spela filen Eftervillkor: Den nyligen valda filen spelas Alternativt flöde 1: Filen som valdes var inte av rätt format 1. Användaren informeras om att filen inte kan spelas Användningsfall: Stoppa spelning ID: SP2 Aktörer: Användare Förvillkor: Inget Flöde av händelser: 1. Användaren klickar på stopp knappen 2. Spelningen av filen stoppas 3. Den nuvarande positionen i filen sätts till början av filen Eftervillkor: Ingen fil spelas och nuvarande positionen i filen är i början av filen Alternativt flöde 1: Ingen fil var vald för spelning 1. Ingenting görs

11 Användningsfall Användningsfall: Felaktig fil i lista ID: SP3 Aktörer: Användare, AudioSystem Förvillkor: Spelning från spelningslista pågår Flöde av händelser: 1. Audiosystem meddelar att filen inte kan spelas 2. Filen tas bort från spelningslistan (?) 3. Användaren meddelas om felet (?) 4. Nästa fil i spelningslistan väljs 5. Spelaren börjar spela filen Eftervillkor: Den nyligen valda filen spelas och den felaktiga filen är borttagen Alternativt flöde 1: Det finns inte fler filer i listan 1. Vad betyder detta för random-play (?)

12 Uppgift till nästa gång Kravanalys Skriv användningsfall som beskriver funktionen hos spelaren Alla knapptryckningar och dylikt bör beaktas Kravbeskrivning skall i princip vara komplett. Det ska vara möjligt att implementera spelaren baserat på kravspecifikationen utan att behöva fundera på hur någonting borde fungera Ge även prioritet för kraven från 1 (högst) till 4 (lägst). Det finns för mycket jobb att göra förrän spelaren har all funktionalitet i kravenspecifikationen Vi kommer bara att göra krav med hög prioritet Där borde vara ungefär lika många krav i varje prioritetsklass Gör det möjligt att utveckla systemet iterativt

13 forts Gör en mock-up för ett användargränssnitt Vilka Grafiska användargränsnitts element behövs (knappar, textboxar, etc Vad skulle vara en bra layout Designan gränsnsittet för hur du vill att en dylik spelare ska fungera Detta kan göras i Java, någon GUI-builder för Java, Något grafik program. Om gjort i annat än Java behöver den inte se helt rätt ut. Det viktiga är att layouten av de olika elementen är utfunderad Tänk på att ert gränssnitt ska vara implementerbart på den här kursen (Alltså inte alltför invecklat om man inte har tänkt jobba extra hårt)