Prosjektoppgave INF2120 Våren 2007: Rebusløp Versjon 070219. Vi skal lage programvare for å kunne gjennomføre et Rebusløp. Prosjektformalia Generelt Alle prosjektgruppene får samme oppgave Det lages ny oppgave hvert år. Det er 3 delleveranser Drop 0: individuell innlevering: demonstrerbar minstemodell Drop 1: prosjekt: modell med 2 tjenester for 1 bruker Drop 2: prosjekt: modell med flere tjenester for mange brukere Gruppene skal evaluere hverandre kursledelsen vil også evaluere prosjektene Alle delleveranser skal presenteres og kritiseres offentlig Prosjektgruppestørrelse gruppene settes opp med 4-5 personer om en gruppe blir på 2 personer pga. frafall, fusjoneres den Prosjektgruppesammensetning: Studentene plasseres i øvelsesgruppe (av 2 mulige) Prosjektgruppene trekkes tilfeldig innen hver øvelsesgruppe Delleveransene Krav til delleveransene Leveransen er ett pdf-dokument (Adobe Acrobat) som skal inneholde beskrivelser med diagrammer og tekst det skal være mulig å evaluere arbeidet fra dette dokumentet! én emx-fil (RSM format) av UML2 modellen Filnavnene skal være: Gnn-Dx.emx og Gnn-Dx.pdf der nn er prosjektgruppenummer og x er drop-nummer (1 eller 2) Filene leveres ved at de lastes opp på området: http://www.uio.no/studier/emner/matnat/ifi/inf2120/v07/leveranser/? vrtx=admin&action=upload-file Leveransen presenteres ved en presentasjon med videokanon enten fra pdf-fil eller fra Powerpoint Presentasjonsfila skal hete: Gnn-Dx.ppt eller Gnn-Dx-P.pdf og presentasjonsfila skal også lastes opp på leveranseområdet på forhånd. Kritikken leveres muntlig, men skal deretter leveres skriftlig på mail Kritiker-gruppa skal definere en testmodell som tar utgangspunkt i den modellen de vurderer. Testmodellen skal benytte UML Testing Profile og inneholde et lite antall test cases (2+).
Minst 1 test case skal utføres ved at kritiker-gruppa instruerer demogruppa hva som skal gjøres. Kritiker-gruppa skal også kritisere modellering og kvalitet på den modellen de er satt til å vurdere. Ved delleveranse 1 skal gruppe 2 evaluere gruppe 1 osv. Direkte etter gruppe 1 sin presentasjon, vil gruppe 2 stille kritiske spørsmål som skaper en diskusjon med gruppe 1 Gruppe 2 sender sine kommentarer og testmodell til Gruppe 1 på mail i etterkant (med Cc til hjelpelærer og foreleser) Så gir hjelpelærer og foreleser sine vurderinger Foreleser gir så en tentativ karakter som altså er uformell og ikke teller såsant den er en ståkarakter Noen enkeltstudenter blir plukket ut til å presentere for foreleser Dette er en sikkerhetsventil for å unngå gratispassasjerer Ved dellev. 2 snur vi evalueringen slik at gruppe 1 evaluerer gruppe 2 Ved dellev. 1 gjøres gjennomgangen i øvelsesgruppene Ved delleveranse 2 gjøres demo etc. i plenum Deltakelse på gjennomgangene er obligatorisk! Krav til student og prosjektgruppe Krav til den enkelte student Han/hun skal delta i prosjektgruppe Han/hun skal delta på lik linje med de andre i gruppa uansett om vedkommende er deltidsstudent Han/hun skal kunne alle detaljer i den felles besvarelse slik at vedkommende skal kunne eksamineres i dette av kursledelsen Han/hun skal trekke seg om han/hun ikke kan fylle disse kravene Krav til den enkelte prosjektgruppe Prosjektgruppene skal sette opp sin egen organisering Prosjektgruppene velger 1 kontaktperson som er ansvarlig for all kommunikasjon med kursledelsen Prosjektgruppene skal motta veiledning av gruppelærer Delleveransen skal leveres på tid! Utsettelser gis IKKE. Juks Det er juks hvis deler av en prosjektoppgave er tilnærmet identisk med en annen gruppes uten at det redegjøres for evt. samarbeid mellom grupper på enkeltproblemer Det er lov å samtale mellom gruppene, men jobb selvstendig! Det er juks hvis deler av en besvarelse er tilnærmet identisk med resultater funnet på Internett uten at det er referert til opprinnelsen Det er lov å finne løsninger på Internett, men ikke å la være å referere Prosjektgruppa skal i alle høve forstå alt hva de har levert! Det er juks å være gratispassasjer Studenter som ikke gjør sin del av prosjektoppgaven kan strykes individuelt
Rebusløp Hva er et rebusløp: Det er flere deltakere, gjerne lag, som disponerer bil/sykkel og mobil Starten går på ett bestemt sted En deltaker registrerer seg fra mobilen på SMS og får vite hvor starten er. På startstedet sender deltakeren en ny SMS med teksten first systemet ser etter at mobilen er på riktig startsted og sender første rebus tilbake på SMS Deltakeren løser rebusen (som har et sted som svar) kjører så til stedet og sender en SMS med svaret om svaret er riktig og mobilen er på riktig sted, returneres neste rebus Helt til deltakeren er i mål Programvaren skal også: gi oppdaterte oversikter over hvor deltakerne er på GoogleEarth der også stillingen står Vinneren er den som har kjørt kortest (luftlinje mellom SMS-ene) Drop 0: Minimal, kjørende Rebus-applikasjon Drop 0 skal innleveres individuelt. Hjelpelærer vil også for hver enkelt sjekke at han/hun kan manipulere, kompilere og kjøre Drop 0 ved hjelp av RSM med plugins. Absolutt deadline er 13.2.2007 kl. 23.59. Vi kaller programvaren for det som skal leveres i Drop 0 for RebusDrop0. RebusDrop0 skal ha følgende karakteristika: 1. Programvaren skal kompileres fra en eksekverbar modell i UML 2 med profilen JavaFrame. 2. Programvaren skal inneholde (minst) 1 tilstandsmaskin. 3. Systemet skal være spesifisert ved hjelp av (minst) 1 UML sekvensdiagram og systemet skal være konsistent med spesifikasjonen. RebusDrop0 skal ha følgende funksjonalitet: 1. Brukeren sender en Sms med teksten reg navn til programmet der navn er en selvvalgt identifikator. 2. Systemet skal sende tilbake en SMS med en URL som viser til en KML-fil. Denne KML-fila forteller hvor starten på rebusløpet er. Rebusløpet skal starte på Ifi-bygget. KML fila skal også inneholde posisjonen til den som registrerer seg. 3. Brukeren skal kunne lese denne KML-fila fra GoogleEarth og få opp rebusløpets startpunkt og sin egen posisjon plassert på satelittbildet. 4. Programmet skal ikke terminere, men behøver ikke på noen måte ta vare på registreringene. Drop 1: Rebusløp for 1 bruker av gangen Drop 1 skal innleveres i prosjektgruppe. Alle personene i gruppa stryker samlet hvis totalresultatet er for dårlig. Videre kan enkeltpersoner strykes hvis de ikke har deltatt
tilstrekkelig og oppnådd tilstrekkelig kompetanse på prosjektets innhold. Dette fastsettes ved at hjelpelærer og/eller foreleser eksaminerer personen i prosjektoppgaven. Absolutt deadline er 20.3.2007 kl. 23.59 Vi kaller dette systemet for RebusDrop1 RebusDrop1 skal ha følgende karakteristika: 1. Programvaren skal være produsert fra en eksekverbar modell i UML2+JavaFrame 2. Programvaren skal kunne virke for 1 bruker av gangen a. Dette betyr at man ikke behøver å ta høyde for at flere benytter applikasjonen samtidig b. Likevel skal systemet i prinsippet ha flere brukere, men man kan anta at disse brukerne ikke bruker systemet på samme tid. Det er altså nødvendig at dataene for ulike brukere blir holdt adskilt i data-prosessen. 3. Modellen skal inneholde submachine states i (minst en av) tilstandsmaskinene. 4. Dataene behøver ikke være persistente, men de skal kontrolleres av 1 tilstandsmaskin. a. Sentrale data skal altså ikke være distribuert over flere prosesser b. De enkelte tilstandsmaskiner kan sjølsagt ha egne lokale variabler c. Dataene om rebusene skal være hardkodet (dvs. settes opp gjennom programvaren selv under initialiseringen). Rebusdataene blir gjort tilgjengelig fra kursledelsen. 5. Systemet skal kunne emuleres ved FakePats. RebusDrop1 skal ha følgende funksjonalitet: 1. Tjenesten reg navn skal fungere som for RebusDrop0, men registreringen skal bevares (i hurtiglageret). 2. Tjenesten rebus svar : a. Brukeren sender melding rebus og står i Rebusløpets startposisjon. Da sender systemet Rebusløpets første rebus tilbake. b. Brukeren sender meldingen rebus riktigsvar og står på riktig svarsted (dvs. både svartekst og svarposisjon er korrekt). Da sender systemet neste rebus tilbake hvis ikke brukeren er i mål. c. Hvis svartekst er korrekt, men svarposisjon er feil, gis en enkel feilmelding, og brukeren får ikke ny rebus. Brukeren må gi samme svar igjen fra riktig posisjon. Riktig posisjon må regnes innafor en rimelig distanse (ca. 300 meter i virkeligheten, men nærmere ved bruk av FakePats) d. Hvis svarposisjon er korrekt, svarteksten er feil, gis en enkel feilmelding. Brukeren gis straffedistanse og brukeren må prøve igjen å finne korrekt svartekst. e. Hvis brukeren er i mål, regnes distansen ut (summen av alle distansene mellom SMS-stedene) og svaret sendes til brukeren på SMS. 3. Tjenestene reg og rebus skal være spesifisert med sekvensdiagrammer der også de skisserte alternativer er beskrevet. 4. Systemet skal være konsistent med spesifikasjonen.
Drop 2: Multibruker Rebusløp konkurranse med persistente data Drop 2 skal innleveres i prosjektgruppe. Alle personene i gruppa stryker samlet hvis totalresultatet er for dårlig. Videre kan enkeltpersoner strykes hvis de ikke har deltatt tilstrekkelig og oppnådd tilstrekkelig kompetanse på prosjektets innhold. Dette fastsettes ved at hjelpelærer og/eller foreleser eksaminerer personen i prosjektoppgaven. Absolutt deadline er 22.5.2007 kl. 23.59 Vi kaller dette systemet for RebusDrop2. RebusDrop2 skal ha følgende karakteristika: 1. Programvaren skal være produsert fra en eksekverbar modell i UML2+JavaFrame 2. Programvaren skal kunne brukes av et ubestemt antall brukere samtidig. a. Dette innbærer at programvaren skal ha sesjoner modellert som tilstandsmaskiner som genereres dynamisk. 3. Modellen skal inneholde submachine states i (minst en av) tilstandsmaskinene. 4. Dataene skal være persistente. a. Det stilles ikke noen spesielle krav til persistens utover at dataene skal overleve multiple kjøringer der eksekveringen avsluttes kontrollert. b. Databasen skal styres av 1 tilstandsmaskin. c. Rebusdataene kan legges inn i databasen uavhengig av RebusDrop2 sin programvare f.eks. vha. SQL-interpret direkte. 5. Systemet skal kunne kjøre ved ekte PATS. RebusDrop2 skal ha følgende funksjonalitet: 1. Tjenesten reg navn skal fungere som i RebusDrop1, men registreringen skal bevares persistent. Alle de registrerte deltakerne regnes å delta i ett rebusløp (én konkurranse) 2. Tjenesten rebus svar skal fungere som i RebusDrop1. 3. Tjenesten stat skal returnere statistikk over egen innsats, dvs. når hver post ble løst og tilbakelagt distanse. 4. Tjenesten map er en administrator-tjeneste som bare kan invokeres av den personen som er registrert som admin : a. En KML-fil genereres og legges på et på forhånd kjent sted b. KML-fila inneholder posisjonen til alle deltakerne i konkurransen med en tekst som angir nummeret på deres sist besvarte post og deres samlede distanse. c. KML-fila skal også inneholde alle postene med en tekst som angir postens nummer. Start og Mål skal også være med. Start har nummer 0. 5. Tjenesten clear er en administrator-tjeneste som skal nullstille hele konkurransen slik at programmet er klart til et nytt rebusløp. Rebuser Alle svarene er holdeplasser på Bus 37 slik at FakePats kan benyttes til testingen. Spørsmål Riktig svar Hellig topp St. Hanshaugen
Hundrekroningsdama Torturskolen Hovedcampus minus B pluss L Skjæreinstrumentene pluss gudshus Ikke gamle dumpa Retterstedet Medisinmannens vei Colletts gate Tannlegehøyskolen Lindern Sagene kirke Nydalen Galgeberg Apotekergata