Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk

Transkript

1 Universitetet i Bergen Det matematisk-naturvitenskapelige fakultet Institutt for informatikk BOKMÅL EKSAMEN I EMNET INF 112 Systemkonstruksjon Tirsdag 13. juni 2006 Tid: 09:00 14:00 Tillatte hjelpemidler: Ingen Viktige generelle råd og kommentarer: Oppgavesettet består av 4 oppgaver. Kontroller at oppgavesettet er fullstendig. Den første oppgaven omhandler en problemstilling som beskrives i "Generell innledning til oppgavene". Les nøye gjennom hele oppgavesettet før du begynner å besvare enkelte delspørsmål. For den første oppgaven er det viktig å holde seg til momenter som er nevnt i "Generell innledning til oppgavene", og ikke trekke inn andre aspekter. Bruksmønstre og UML diagrammer må være formatert slik at de er leselige og enkle å forstå. Drøftinger i de to siste oppgavene bør være formatert slik at det er lett å få oversikt over besvarelsen. Bruk gjerne punktvis oppstilling eller overskrifter for å skille svarene på de enkelte momentene fra hverandre. Synes du at oppgaveteksten er uklar eller ufullstendig noe sted, må du lage dine egne presiseringer og angi disse i besvarelsen. Prosentsatsene ved hver deloppgave angir omtrentlig vektlegging ved sensur. LYKKE TIL! Torill Hamre Khalid A. Mughal 1 / 8

2 Generell innledning til oppgavene Fjernundervisningen ved Institutt for Informatikk, Universitetet i Bergen, tilbyr i dag to kurs i objektorientert programmering via Internett. I den forbindelse er det implementert flere nettbaserte informasjonssystemer, blant annet for: Dynamisk generering av kurssider Innlevering av obligatoriske oppgaver Kontrollspørsmål og interaktive (tidsbegrensede) prøver Disse systemene er utviklet gjennom flere prosjekter, deriblant flere hovedfagsoppgaver ved instituttet. De har derfor ulike måter å håndtere data på, og delvis forskjellige aksesskontrollmekanismer. Systemet for kontrollspørsmål og interaktive prøver, SYSTEKON, består av tre deler: Oppgavebyggeren - som lar en undervisningsansvarlig opprette og oppdatere oppgavesett som skal brukes i prøver og til eksamen. Presentasjonsdelen - som legger ut oppgavesett på nettet og lar en bruker (student) løse disse og registerer resultatet. Statistikkdelen - som genererer statistikk for besvarte prøver og presenterer denne for undervisningsansvarlig. Vårens INF112 prosjekt videreutviklet Oppgavebyggeren som er en desktop applikasjon, men med mulighet for tilkobling til en nettbasert database for opplasting av oppgavesett til bruk i Presentasjonsdelen. De andre to delsystemene i SYSTEKON er nettbaserte applikasjoner, utviklet vha. standard Java og W3C teknologi. Alle tre systemer videreutvikles i regi av JAFU (JAva for FjernUndervisning) prosjektet. Et oppgavesett består av ett eller flere emner, som hver inneholder ett eller flere spørsmål. Hvert spørsmål har en rekke svaralternativer, hvorav minst ett er riktig, og tilhørende kommentar som forklarer hvorfor svaret er riktig eller galt. Hvert svar har en poengsum som summeres når en prøve eller eksamen tas. For å gjøre SYSTEKON tilgjengelig for flere kursansvarlige, også dem med begrensede muligheter for å sette opp nettbaserte applikasjoner, ønsker ledelsen i JAFU prosjektet, heretter kalt kunde, å lage en desktop versjon av Presentasjonsdelen, kalt SolveIt. SolveIt skal la en student løse prøver og ta eksamen, etter å ha logget inn med et gyldig brukernavn og passord. Studenten mottar dette brukernavnet og passord i posten etter å ha registrert seg og betalt kursavgift hos administrasjonen for fjernundervisningen ved Universitetet i Bergen. Samtidig får studenten også en nettadresse der han kan laste ned både program og alle oppgavesettene for det eller de kurs han har meldt seg på. SolveIt skal være filbasert, men krever tilgang til Internett for innlevering av besvarelser for obligatoriske prøver og eksamen. Oppgavesettene som kan løses, er enten tester uten tidsbegrensning (type "KodeKnekker") eller obligatoriske prøver eller eksamen som begge har tidsbegrensning (type "Eksamen"). Alle oppgavesett og besvarelser skal lagres kryptert for å hindre at obligatoriske prøver og eksamener endres eller kopieres fra andre studenter, slik at en student urettmessig får lov til å gå opp til eller består eksamen. Ved besvarelse av prøver og eksamen skal svarene lagres sammen med studentens brukernavn og poengsum. Dersom prøven er en test, kan studenten se på svar og kommentarer både underveis og etter at prøven er ferdig. SolveIt skal også vise antall poeng oppnådd etter hvert som studenten besvarer spørsmålene og samlet poengsum når testen er ferdig. Han skal også kunne ta testen på ny, og i så fall skal systemet ta vare på alle besvarelser av testen. 2 / 8

3 For obligatoriske prøver, som må bestås for å kunne gå opp til eksamen, og eksamen skal besvarelsen også lagres på lokal disk på samme måte som for tester. Studenten får derimot kun se total poengsum etter at prøven/eksamen er ferdig. Fasit, dvs. svar og kommentarer for enkeltspørsmål, blir kun tilgjengelig etter at prøven/eksamen er levert inn og godkjent, og kun dersom kursansvarlig har angitt at fasit skal gjøres tilgjengelig. Obligatoriske prøver og eksamen må sendes inn til JAFU-systemet, som består av Statistikkdelen og en kursadministrasjondel, innen gitte datoer. Disse datoene sendes ut sammen med alle oppgavesett og kan vises i SolveIt. Studenten er selv ansvarlig for å sende inn besvarelsen sin innen gitt frist. Innsendelsen gjøres gjennom SolveIt og skjer gjennom sikker overføring vha. HTTPS protokollen. Addressen besvarelsene skal sendes til ligger kryptert i applikasjonen sammen med studentens brukernavn og passord. Andre deler av konfigurasjonen, som f.eks. DTD for validering av oppgavesett, valg av språk, o.l. kan ligge i en åpen konfigurasjonsfil. Under besvarelse av oligatoriske prøver og eksamen skal SolveIt holde rede på hvor lang tid studenten har igjen til å løse oppgavesettet. Det skal være mulig å ta en pause under løsning av prøver med tidsbegrensning, men dersom tiden er oppbrukt lukkes settet. Da kan ikke studenten gjenåpne det for å svare eller se på de gjenværende spørsmålene. Ved forsettelse av besvarelse skal tiden løpe fra den tiden da besvarelse ble avbrutt. Etter at besvarelsen er sendt til JAFU-systemet, kontrollert og godkjent, sendes en kvittering tilbake til SolveIt der studenten kan se på innholdet. Kvitteringen vil inneholde beskjed om prøven er bestått eller om når og hvordan han vil få beskjed om eksamensresultatet. Den vil også inneholde en nøkkel for å "låse opp" fasiten til en obligatorisk prøve slik at studenten kan se på denne i SolveIt, f.eks. for å forberede seg til eksamen. Dagens Presentasjonsdel har ingen automatiserte tester. Kunden ønsker at dette utvikles for SolveIt, slik at det blir enklere å kontrollere at det nye systemet oppfyller gitte krav og at retting av "bugs" ikke innfører nye feil i programmet. Disse testene skal bygge på siste versjon av rammeverket JUnit, og skal dekke alle datalagrings- og prosesseringsklasser, samt brukergrensesnittet. Kunden ønsker også at SolveIt skal ha et grafisk brukergrensesnitt som brukerne vil være vant med fra andre (desktop) applikasjoner. Det blir derfor en viktig oppgave å utvikle et skjermdesign som er intuitivt og krever lite eller ingen opplæring. 3 / 8

4 Oppgave 1. (30%) (3 deloppgaver; a: 7.5%, b: 7.5%, c: 15%) a) Skriv 3-6 funksjonelle krav og 3-6 ikke-funksjonelle krav til SolveIt ut fra den beskrivelsen som er gitt i "Generell innledning til oppgavene". Forklar hvordan du vil teste at disse er oppfylt under utviklingen av systemet. Marker hvilke av kravene som er funksjonelle (F) og hvilke som er ikke-funksjonelle (IF). b) Identifiser aktørene til SolveIt, og tegn et bruksmønsterdiagram for operasjoner knyttet til besvarelser og innlevering av prøver og eksamen. Skriv et bruksmønster for besvarelse av en obligatorisk prøve. c) Lag en analysemodell (UML klassediagram) som tilfredsstiller kravene gitt for løsning og levering av oppgavesett i "Generell innledning til oppgavene". Identifiser assosiasjonene mellom klassene, og ta med de attributter og operasjoner som du mener som er relevante ut fra den informasjonen som er tilgjengelig. Oppgave 2. (20%) (2 deloppgaver, begge teller likt) a) Kunden ønsker at SolveIt skal kryptere oppgavesettene og besvarelsene som studentene leverer inn. Du får i oppdrag å utvikle en krypteringsløsning, og får oppgitt en liste av skrevne (f.eks. bøker, artikler og "white papers") og digitale (f.eks. kodeeksempler og krypteringsbibiloteker) som kunden ønsker at du evaluerer og baserer løsningen på den beste algoritmen. Hvilke lover og regler må du ta hensyn til? Hvilken lisens bør du velge for krypteringsprogramvaren du utvikler, dersom kunder ønsker (1) at andre universiteter og høyskoler fritt skal kunne bruke programvaren så lenge de gjør eventuelle forbedringer tilgjengelig for JAFU-prosjektet, og (2) å kunne selge programmet etterpå? Kunden ønsker også en sikkerhetsvurdering av SolveIt som dekker disse tre aspektene: 1. Konfidensialitet - å sikre at informasjon kun er tilgjengelig for autoriserte brukere 2. Integritet - å sikre at informasjon og behandlingmetoder er nøyaktig og komplett 3. Tilgjengelighet - sikre at autoriserte brukere har nødvendig tilgang til informasjon og tilhørende funksjonalitet Diskuter hvilke av disse aspektene som er relevante for SolveIt, og skisser hvordan slik sikkerhet kan bygges inn i systemet. b) Basert på evalueringen du gjorde av ulike krypteringsalgoritmer og biblioteker, skal du utvikle programvare som oppfyller følgende designmål: Nye krypteringsalgoritmer skal kunne legges til uten at de andre delene av systemet endres. Løsningen skal være basert på kontrakter og gjøre bruk av etablerte designmønstre. Gi en kort beskrivelse av følgende designmønster og vurder hvorvidt de vil være nyttige i denne problemstillingen: (1) Adapter, (2) Bridge, og (3) Strategy. Lag et UML klassediagram som viser hvordan du vil designe en løsning som oppfyller kravene ovenfor. 4 / 8

5 Oppgave 3. (30%) (2 deloppgaver; a: 20%, b: 10%) I denne oppgaven besvarer du ett punkt under hvert delspørsmål, avhengig av hvilken gruppe du var med på i vår (Gruppe 1 eller Gruppe 2), eller i fjor (Vår 2005): a) Gruppe 1: Figur 1 viser overordnet design for den nye Oppgavebyggeren, tatt fra gruppens systemdesigndokument. Forklar hvilke begrunnelser som ligger til grunn for dette designet, hva som er hovedansvaret for hver pakke, og hvilke avhengigheter som gjelder mellom pakkene. Gi en kort vurdering av gruppens design opp mot designet i den "gamle" Oppgavebyggeren med tanke på fremtidig vedlikehold. Gruppe 2: Figur 2 viser overordnet design for den nye Oppgavebyggeren, tatt fra gruppens systemdesigndokument. Forklar hvilke begrunnelser som ligger til grunn for dette designet, hva som er hovedansvaret for hver pakke, og hvilke avhengigheter som gjelder mellom pakkene. Utdyp designet for en av pakkene som vises. Gi en kort vurdering av gruppens design opp mot designet i den "gamle" Oppgavebyggeren med tanke på fremtidig vedlikehold. Vår 2005: Figur 3 viser foreslått arkitektur for det planlagte systemet (uportal), tatt fra gruppens systemdesigndokument. Forklar hvilke begrunnelser som ligger til grunn for dette designet, hva hovedansvaret til hvert delsystem eller komponent er, og hvordan eksisterende systemer skulle integreres. Hva var den sentrale mekanismen for kommunikasjon mellom de ulike delsystemene / komponentene i uportal systemet? Gitt den raske utviklingen innen nettbaserte applikasjoner, ville du ha foreslått en annen arkitektur dersom du skulle utviklet systemet på nytt? b) Gruppe 1: Testing var en av hovedaktivitetene i del 2 av prosjektet. Forklar hvilke mål gruppen satte for testing av hhv. modell-, logikk- og GUI-klasser, og hvilke testverktøy som ble brukt. Gi noen få konkrete eksempler på hva som ble testet og vurder nytteverdien av disse testene. Dersom du skulle gjennomført del 2 på nytt, er det deler av testingen du ville planlagt og/eller utført på forskjellig måte? Gruppe 2: Testing var en av hovedaktivitetene i del 2 av prosjektet. Forklar hvilke mål gruppen satte for testing av hhv. modell-, logikk- og GUI-klasser, og hvilke testverktøy eller -metoder som ble brukt. Gi noen få konkrete eksempler på hva som ble testet og vurder nytteverdien av disse testene. Dersom du skulle gjennomført del 2 på nytt, er det deler av testingen du ville planlagt og/ eller utført på forskjellig måte? Vår 2005: Test & integrasjonsteamet definerte en rekke tester i del 1 av prosjektet. Beskriv formålet med noen få av disse testene, og skisser hvordan de ble eller kunne blitt testet i praksis. Angi hvilke testverktøy som ble (planlagt) brukt. I prosjektet var et eget team ansvarlig for test og integrasjon av alle subsystemer og integrasjonen av disse i uportal. Diskuter fordeler og ulemper med en slik organisering, og foreslå eventuelt en bedre måte å organisere testingen på. Oppgave 4. (20%) (2 deloppgaver; begge teller likt) Anta at du blir gruppeleder for neste års INF112 prosjekt der studentene skal videreutvikle et system på størrelse med Oppgavebyggeren, dvs. med rundt 50 klasser og linjer med kode og kommentarer. Studentene vil jobbe i grupper på ca. 10 personer der en student også vil fungere som prosjektleder. Alle studenter skal være med og i størst mulig grad dele likt på arbeidet gjennom hele prosjektperioden på 12 uker. a) Hvordan ville du organisere prosjektet og fordele ressurser innenfor rammene av utviklingsmetoden Unified Process? Hvilke verktøy for prosjektstyring og programutvikling vil du anbefale at studentene bruker? Er det andre praktiske råd du vil gi studentene, utover de rent tekniske? Bruk gjerne egne erfaringer fra INF112 prosjektet til å vurdere ulike alternativer. 5 / 8

6 b) Følgende leveranser fra et programutviklingsprosjekt blir ofte høyt prioritert av kunder Dokumentasjon av krav, analyse og design, tester, installering og bruk. Organisert og godt kommentert kildekode. Automatiserte tester, både for databehandling og i brukergrensesnittet. Vurder i hvilken grad din gruppe oppfylte kundens krav i årets eller fjorårets INF112 prosjekt og hva som eventuelt kunne vært gjort annerledes for å oppnå et bedre resultat. Hvilke konkrete tiltak ville du sette i verk som gruppeleder for neste års prosjekt for å forbedre kvaliteten på disse leveransene? 6 / 8

7 Figur 1: UML-diagram for det nye systemet Package Diagram for Assignmentbuilder Assignmentbuilder Gui DNDTree Menu Preview Editor Model IO Settings ProjectElements DB HTML XML ExceptionHandlers Actionlisteners TestCases 7 / 8

8 Figur 2: Ny struktur Figur 3: Foreslått programvarearkitektur 8 / 8