INF2120 Prosjektoppgaven Våren 2005 (Versjon 050408) Et Trafikkoppfølgingssystem Systemet blir et Trafikanten Plus system der både trafikkselskapets ansatte og publikum kan få detaljert informasjon om hvor busser, T-baner og trikker er. Vi skal forutsette at: Alle holdeplasser er registrert med unik id, navn og global posisjon (GPS) Alle befordringsmidler er registrert med unik id, rute og dynamisk posisjon Alle rutetider er kjent (slik som hos Trafikanten nå) Tjenester Dette er noen forslag, men første delleveranse er å spesifisere disse tjenestene nøyere. Her er det mange muligheter for hvordan man kan lage tjenester. Publikum kan få vite hvor langt unna deres prefererte buss/trikk/t-bane er Man kan benytte o posisjonering fra publikums mobile terminal, o info om holdeplass, f.eks. plassering og rekkefølge o forhåndsinnstilte valg, eller... Det kan i prinsippet benyttes WAP, SMS eller Web. Trafikkselskapet kan skaffe seg dynamisk statistikk over trafikken og evt. sette inn ekstratiltak Inne i befordringsmiddelet kan man automatisk gi neste stoppested Legge inn og ta ut (evt. suspendere temporært) holdeplasser, ruter, framkomstmidler Ikke lag for mange tjenester. Lag noen få som dere hadde syntes ville vært fint å ha i et slikt system. Konkret gjennomføring Kan vi få dette til å virke på ordentlig? Vi har tilgang på et eksperimentelt tele-opplegg som gjør det mulig å få utført flere vanlige og uvanlige teletjenester fra våre datamaskiner. Vi benyttet dette opplegget for SMS-sending i INF5150 Høsten 2004. Det dreier seg om PATS Program for Advanced Telecom Services www.pats.no Det er selvfølgelig endel greier vi ikke har direkte tilgang til og som vi må bygge opp en simulering av:
rutetider holdeplassinformasjon Tidsfrister og krav til den enkelte del-leveranse våren 2005 Del-leveranse 1 (Spesifikasjon) Frist: 25.2.2005 kl. 23.59 Prosjektgruppene skal lage en spesifikasjon av Trafikkoppfølgingssystemet ved hjelp av UML 2.0 og vanlig norsk eller engelsk tekst. Spesifikasjonen skal være så nøye at det skal være mulig for en annen gruppe å forstå hvordan systemet skal fungere. Det er altså ikke nødvendig å spesifisere akkurat hvordan man skal implementere systemet, men hvordan det skal virke sett hovedsaklig fra utsida. Det er naturlig å bruke følgende beskrivelsesteknikker: Vanlig prosa for å gi uformelle beskrivelser og for å forklare enkeltheter i diagrammene Use case diagrammer o men ikke overdriv bruken av use cases! Sekvensdiagrammer o skal være det viktigste verktøyet for å beskrive oppførselen mellom ulike aktører i systemet. Systemet selv kan være en slik aktør i noen diagrammer. Klassediagrammer o for å beskrive begrepsrelasjoner Composite structure diagrammer o Disse viser innmaten til en klasse. Noen ganger er det riktig å vite hvordan en entitet ser ut inni og det kan være hensiktsmessig å benytte også i en tidlig spesifikasjon. En tentativ, men ikke obligatorisk disposisjon for rapporten til første del-leveranse ville kunne være: 1. Innledning med klar beskrivelse av forutsetninger som gjøres 2. Use-case diagrammer med forklaring 3. Klassediagrammer 4. Muligens et composite structure diagram for systemet med forklaring 5. Sekvensdiagrammer 6. Eventuelle begrensninger
Del-leveranse 2 (Design) Frist: 29.4.2005 kl. 23.59 Prosjektgruppa skal altså ta den spesifikasjonen (del-leveranse 1) som de har kritisert fra en annen gruppe og designe den. Det er lov å modifisere spesifikasjonen i samarbeid med den andre prosjektgruppen, men det er ikke lov å transformere den til noe helt annet (f.eks. gruppas egen spesifikasjon). Design vil i denne sammenheng si UML 2.0 modell som i prinsippet er eksekverende. En slik modell vil bestå av klasser med evt. composite structures og tilstandsmaskiner. Transisjonene i tilstandsmaskinene vil vi skrive direkte i java, men de skal i all hovedsak bestå av tilordninger og enkle valgsetninger (if... then... else...). Designen skal lages i et dedisert UML 2.0 verktøy (IBM Rational Software Modeler) En disposisjon for del-leveranse 2 vil kunne være: 1. Introduksjon med forutsetninger 2. En revidert spesifikasjon eller i alle fall en nøyaktig beskrivelse av endringer gjort i den spesifikasjonen som man har fått utdelt. Her er det naturlig å benytte sekvensdiagrammer såvel som use-case diagrammer 3. Design-modell (husk forklarende tekst hele tida) a. design-modellen er i samme UML 2 modell som spesifikasjonen så det er ikke nødvendig å repetere de diagrammer som er presentert tidligere i spesifikasjonen b. ytterligere klassediagrammer kan trengs c. mer detaljerte composite structure diagrammer med ports d. tilstandsmaskiner for å forklare oppførselen til systemet 4. Appendix A: UML 2.0 modellen leveres i IBM Rational Software Modeler format Del-leveranse 3 (Simulering / Implementasjon) Frist: 27.5.2005 kl. 23.59 Studentene vil før innleveringen av del-leveranse 2 få tilsendt på mail følgende nyttig informasjon: JavaFrame: et java rammeverk tatt fram på Ericsson for implementasjon av asynkront kommuniserende tilstandsmaskiner Filer og prinsipper for bruk av Trafikantens SIS (www.trafikanten.no/sis ) Grunnen til at denne informasjonen ikke legges offentlig ut, er at verken Ericsson eller Trafikanten ønsker at dette skal være åpent tilgjengelig. Implementasjonen skal mekanisk kodes direkte fra design-modellen inn i JavaFrame. Omgivelsen skal være Eclipse. Statisk informasjon om holdeplasser, stoppesteder og koordinater skal legges opp i en relasjonsdatabase på normalisert form. Data hentes fra filene 37.txt og StopList.xml. Hint:
Som relasjonsdatabasehåndteringssystem brukes Oracle (eventuelt et annet system med tilsvarende funksjonalitet). Bruk samme oppsett, brukernavn og passord som i INF1050. Kjør kommandoer mot databasen ved hjelp av SQL-Plus. Se http://www.ifi.uio.no/~inf1050/tekster/inf1050basen.pdf og http://www.ifi.uio.no/~inf1050/tekster/sqlplus.pdf Data kan legges inn i hver enkelt tabell ved hjelp av INSERT-kommandoer, en kommando for hver forekomst. INSERT-kommandoene kan genereres ved å redigere litt på datafilene, evt ved hjelp av programmet xml2reldb.php. Dynamisk informasjon om de kjørende busser og trikker skal hentes vi http fra Trafikanten. Svaret fra Trafikanten vil være en XML-fil. Programmet skal kjøres i to versjoner 1. Simulert versjon der man benytter GUI fra JavaFrame. Alt kjøres på én maskin. 2. Ekte implementasjon med ekte mobiltelefoner og bruk av PATS-laben Versjonene skal være to ulike raffineringer av den samme UML 2.0 modellen som ble laget i del-leveranse 2 (evt. med nødvendige modifikasjoner). Forskjellen mellom versjonene skal være så langt mulig kun at JavaFrame mediators er byttet ut på kanten av systemet. Del-leveranse 3 kan ha følgende disposisjon: 1. Introduksjon med forutsetninger a. Her må man beskrive evt. endringer i UML modellen man har funnet det har vært nødvendig å gjøre. 2. Implementasjon a. Her beskrives de implementasjonsvalg man har foretatt. b. Dokumentasjon på databasedesignen 3. Appendix A: Java koden (på toppen av JavaFrame) 4. Appendix B: Java-implementasjonen leveres også i et format som er lett kjørbart (.jar eller.zip) 5. Appendix C: Databaseimplementasjonen Gruppene skal være i stand til på kommando å demonstrere systemet sitt i stedet for å gjøre en foil-presentasjon. Gruppene får ikke vite på forhånd hvem som skal demonstrere og hvem som skal presentere. Administrativ Informasjon Generelt Alle prosjektgruppene får samme oppgave. Det lages ny oppgave hvert år.
Det er 3 del-leveranser (Spesifikasjon, Design, Simulering/ Implementasjon/ Validering/ Test). Gruppene skal evaluere hverandre, men kursledelsen vil også evaluere prosjektene. Alle delleveranser skal presenteres og kritiseres offentlig Gruppesammensetting Gruppene settes opp med 4-5 personer. Om en gruppe blir på 2 personer pga. frafall, fusjoneres den med en annen gruppe. De som jobber, skal ikke være skadelidende i forhold til dem som dropper ut. Ved hver del-leveranse forbeholder kursledelsen seg retten til å endre grupper for å bedre gruppenes effektivitet også selv om gruppene ikke har blitt redusert til 2 personer. Studentene er plassert i øvelsesgruppe ved emnepåmelding (av 2 mulige). Vi deler studentene i dem som har tatt INF3120 (Utvikling av store programsystemer) og dem som ikke har tatt det. Vi trekker tilfeldig fra disse to kategoriene slik at personene med erfaring fra INF3120 blir spredt. Her er gruppene før første del-leveranse våren 2005: Navn Gruppe INF3/4120 Prosjektgruppe Catrine Myhre 1 Nei 1 Christer Veland Aas 1 Ja 1 Mehdi Zare 2 Ja 1 Odd Christer Brovig 2 Nei 1 Pål Vermund Knudsen 1 Nei 1 Christian Reinholt Clasen 1 Ja 2 Ingunn Elisabeth Sundal Rønningen 2 Nei 2 Kjetil Magnus Kristiansen 2 Nei 2 Noushin Mousavi 1 Ja 2 Sjur Ohldieck Sundin 2 Nei 2 Afsheen Mahmood 2 Nei 3 Espen Aune Olsen 1 Ja 3 Fred Øvereng 1 Ja 3 Ngoc Trieu Andy Pham 1 Ja 3 Sajida Ali 1 Nei 3 Anders Bakken 1 Ja 4 Are Oppegård Pedersen 1 Ja 4 Behroz Mirzai 1 Nei 4 Naima Akram 1 Nei 4 Ronnie Østgaard 1 Ja 4 Daniel Mylius Wittwer 2 Nei 5 Jude Dhushyanthan Uruthiran 2 Nei 5 Vijayaroopan Sivarajah 2 Ja 5 Yassin Isir Hassan 2 Ja 5 Asli Samatar 1 Ja 6 Daniel-Yacin Chaibi 1 Nei 6 Sverre Krohn Tennøe 1 Nei 6
Yun Huang 1 Ja 6 Atle Wandsvik 1 Ja 7 Lars Anthony Mojares Mapoy 2 Nei 7 Nedic Damir 2 Ja 7 Sohail Ahmed Chaudry 2 Nei 7 Eigil Moe 2 Nei 8 Eivind Hasle Amundsen 1 Ja 8 Fozia Saeed 2 Nei 8 Gard Niklas Olsen 2 Nei 8 Tan Xuan Ngyuen 2 Nei 8 Dusan Dislioski 1 Nei 9 Mads Andre Bergdal 1 Nei 9 Neeru Bhardwaj 1 Ja 9 Saqib Riaz 1 Nei 9 Trond Arne Sørby 2 Nei 9 Del-leveransene Leveransen er ett pdf-dokument (Adobe Acrobat) som skal inneholde beskrivelser med diagrammer såvel som tekst. Dere kan gjerne bruke malen som finnes i dette dokumentet. Leveransen presenteres ved en presentasjon med videokanon enten fra pdf-fil eller fra Powerpoint. Dette er en presentasjon og det er altså ikke det samme som å vise rapporten med prosjektoren. Presentasjonen skal ikke ta lengre tid enn 15 minutter. Kritikken (fra en annen gruppe) presenteres muntlig direkte etter gruppas presentasjon. Kritikken sendes deretter skriftlig som en e-mail til den andre gruppas kontaktperson. I tillegg kan dere godt gi detaljerte kommentarer i form av håndnotater på utskrift. Kritikken skal framføres på max 10 minutter. Gruppa som kritiseres, får lov å kommentere kritikken fortløpende. Kritikk og samarbeid Ved Delleveranse 1 (Spesifikasjon) skal gruppe B evaluere gruppe A, C skal vurdere B, osv. Det er altså B som skal gi kritikk av A etter at A har presentert sin del-leveranse. Så skal Gruppe B gjennomføre design etter A sin spesifikasjon! Dette vil kreve at A og B samtaler og samarbeider slik at B vil være i stand til å gjennomføre del-leveranse 2. Ved Delleveranse 2 (Design) skal gruppe A evaluere gruppe B. Nå er det altså A sin tur til å vurdere om B faktisk har gjort jobben som A spesifiserte. Er designen i henhold til hva A spesifiserte med evt. seinere modifikasjoner? Ved Delleveranse 3 (Implementasjon) skal gruppene fortsette på sin egen design. Kritikken følger mønsteret fra delleveranse 2 dvs. gruppe A evaluerer gruppe B etc. Krav til den enkelte student og til prosjektgruppene 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 krav 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. Vanligvis vil dette gjøres i gruppetimene. Delleveransen skal leveres på tid! Utsettelser gis IKKE. Grunnen til at vi absolutt ikke gir utsettelser, er at vårens eksamener ikke flytter på seg, og fordi gruppene er avhengige av hverandre. Men vi vil selvfølgelig ta hensyn til situasjoner som medfører at prosjektgruppen ikke har fått levert leveransen med den nødvendige kvalitet. Men vær proaktiv! Å gjøre prosjektarbeid tar lengre tid enn man tror. Hva er 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å Internet uten at det er referert til opprinnelsen Det er lov å finne løsninger på Internet, men ikke å la være å referere. Å referere vil si å skrive i oppgaven hvor man har funnet informasjonen. Det skal være mulig for hvem som helst å finne tilbake til informasjonen for evt. å sjekke at referansen er korrekt. 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. Vi forbeholder oss retten til spontane utspørringer om detaljer i oppgaven.