UNIVERSITETET I OSLO

Transkript

1 UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler: Alle trykte og skrevne Les nøye igjennom hver oppgave og kontroller at oppgavesettet er komplett før du begynner å besvare spørsmålene. Gjør dine egne forutsetninger og vurderinger hvis du mener oppgaven er mangelfull eller du ønsker å legge til noe eller gjøre endringer. Gjør i så fall rede for de forutsetningene du tar. Oppgave 1: Multiple choice (25 %) For alle oppgavene gjelder at det bare er ett riktig svar. Det holder at du i besvarelsen oppgir alternativene A, B, C eller D for hver oppgave. No Spørsmål Svar A Svar B Svar C Svar D 1 Hva gjør Spesifikasjonen er Det er mer omfattende Smidig metode kontraktregulering ikke avklart ved endringshåndtering enn i forutsetter at det ikke av smidig mer krevende enn tradisjonelle "fossefall" prosjekter? kontraktsinngåelse. "fossefall" prosjekter. inngås kontrakt mellom partene. 2 Hvilket svar er ikke i samsvar med PS2000? 3 Et inkrement i inkrementell utvikling indikerer... 4 Validering i testing av programvare betyr å teste at.. 5 Hva representerer en valgdiamant i et aktivitetsdiagram? 6 I hvilken prosessmodell er det vanligst med daglige standupmøter? Læring absorberes underveis i utviklingsprosessen.... et tillegg i programvaren.... komponenter og delsystemer fungerer sammen. Gjennomføringsmodellen er beskrevet i kontrakten.... en iterasjon i smidig utvikling.... produktet bygges på riktig måte. Endelig spesifikasjon av utviklingsiterasjonene skjer ved kontraktsinngåelse. et tillegg i kravspesifikasjonen.... systemet gjør det brukeren virkelig ønsker. Det forutsetter en klar spesifikasjon ved kontraktsinngåelse. Partene deler kommersiell risiko gjennom en målprismodell. en milepæl for prosjektet. 'for'-løkke 'Class' 'while'-løkke 'if then else'-test XP Fossefall Spiralmodellen Scrum 1

2 No Spørsmål Svar A Svar B Svar C Svar D 7 Hvilken kontraktmodell "Fossefall" Ressurskjøp Iterativ modell En smidig kontraktmodell gir leverandøren mest omfattende ansvar for hvilket resultat som vil bli levert? 8 Kanban brukt i. indikerer bruk av indikerer anvendelse av er en fase i er en del av Scrum. systemutvikling... 9 Hva brukes i UML for spesifikasjon av grensesnitt (Interface)? 10 Hva menes med høy kohesjon for et objekt? 11 Hva menes med lav kobling for et objekt? 12 Hva inngår i kontrollobjekt prinsippet (Kontroller)? 13 Hva er sammenhengen mellom systemutvikling og programmering? 14 Hvilket av disse utsagnene er feil? tidsbokser. konseptet just-in-time. fossefallsmodellen. Sekvensdiagrammer Klassediagrammer Use Case-diagrammer Tilstandsdiagrammer Objektet har oppgaver innenfor ett funksjonelt område. Objektet samarbeider med så mange andre objekter som mulig. Kontrolleren har kun attributter. Programmering gjøres uavhengig av systemutvikling. Prototyping er gunstig for å hindre feil i koden. 15 Hva er Kjennskap til domenekunnskap? aspektene ved domeneservere 16 Hvilket krav er funksjonelt? 17 Når to eller flere Use Cases har en felles del kan vi benytte Hvilke av følgende er et ikke-funksjonelt krav? 19 Hvilken hovedtype av krav omhandles i Use Casediagrammer? 20 Hvilke diagramtyper er sentrale i modeller av brukerinteraksjoner? Systemet skal implementeres i Java. Objektet har oppgaver innenfor mange funksjonelle områder. Objektet samarbeider med et lite antall andre Kontrolleren gjør all jobben selv. Programmering og systemutvikling er det samme. Prototyping gjøres før produksjon av mange typer produkter. Kunnskap om et bestemt fagfelt Skjermbildet som vises skal kunne skrives ut. include-relasjonen. extend-relasjonen. multiplisere to tall. Krav til brukergrensesnitt Klassediagrammer og aktivitetsdiagrammer Systemet bør kunne legge til registreringer av flybilletter. Ikke-funksjonelle krav Use Case diagrammer og sekvensdiagrammer Objektet oppretter mange andre Objektet har ingen kobling til andre Kontrolleren delegerer oppgaver og styrer ett eller flere Use Case. Programmering er en viktig del av systemutvikling. En prototype kan tidlig vise viktig funksjonalitet til kunden. Utvikling av domener Innlogging skal ta mindre enn 15 sek. i gjennomsnitt. generalisering. søke etter navn i et personregister. Funksjonelle krav Aktivitetsdiagrammer og tilstandsdiagrammer Objektet kaller mange metoder i andre Kontrolleren ligger alltid på serveren. Systemutvikling er en viktig del av programmering. En prototype kan være gunstig for å vise et brukergrensesnitt. Utvikling av nettsider med eget domene takle 1000 samtidige brukere. 2

3 Oppgave 2: Modellering sykkelutleie og bestilling av hotellrom (45 %) Sykling på Mallorca har blitt svært populært. Et norsk firma har etablert seg med sykkelutleie, sykkelverksted og sykkelgarasje i tilknytning til et hotell på Mallorca. Firmaet har også avtale med andre hoteller i nærheten. Firmaet tilbyr i dag en enkel webside der interesserte kan sende e-post om ønsket periode for leie av sykkel og tilsvarende ønsket periode for bestilling av hotellrom. Ettersom det blir stadig flere interesserte, er det tungvint å håndtere all e-post på grunn av mye manuelt arbeid i etterkant. Selskapet ønsker nå å tilby et web-basert system for bestilling og betaling av både sykler og hotellrom. Web-løsningen skal altså kommunisere med to forskjellige bestillingssystemer: ett for bestilling av sykler og et annet for bestilling av hotellrom. Bestillingssystemene kommuniserer igjen med hvert sitt betalingssystem. Ved bestilling av sykkel og/eller hotellrom oppgis personalia: Navn, adresse, telefon og e-postadresse. Personalia oppgis kun én gang, selv om kunden vil bestille både sykkel og hotellrom. Ved bestilling av sykkel oppgis type sykkel (landeveissykkel eller vanlig sykkel) og ønsket periode (fra og til dato). Ved bestilling av hotellrom velges hotell fra en liste av hoteller, type rom (singel eller dobbeltrom) og ønsket periode (fra og til dato). Det er ikke lagt opp til å ha med barn, slik at maksimalt to personer kan dele rom. Alle rom har inkludert frokost, men det er mulig å bestille opphold med alle måltider inkludert mot et tillegg i prisen. Det er mulig å bestille hotellrom uten å bestille sykkel, og bestille sykkel uten å bestille hotellrom. Periode for leie av sykkel og hotellopphold trenger ikke være det samme. Leie av sykkel og hotellrom må betales med Visa eller Mastercard via den web-baserte løsningen. Betalingen gjøres separat: ett beløp for sykkel og ett beløp for hotellrom. Endelig bekreftelse på bestilling av sykkel og hotellrom gis først når betalingen er fullført. Man antar at mange vil ønske å endre tidsperiode for bestillingen hvis det ikke er ledig sykkel eller hotellrom i angitt periode. Det skal derfor være mulig å bestille både sykkel og hotellrom før man starter betalingen. Hvis det ikke finnes ledig sykkel av angitt type i hele perioden bestillingen gjelder for, gis det melding om dette, og det må bestilles på nytt. Tilsvarende gjelder for bestilling av hotellrom. a) Lag et aktivitetsdiagram for bestilling av sykkel og hotell. Diagrammet skal ta hensyn til at den som bestiller, kan bestille to typer sykler (vanlig sykkel eller landeveissykkel). Hotellrom kan være singel eller dobbeltrom, og det skal være mulig å bestille med full pensjon (alle måltider) hvis ønskelig. Det skal være mulig å avbryte bestillingen hvis ingen sykler av valgt type er ledige eller ingen rom er ledige på valgt hotell. b) Definer aktører for det web-baserte systemet (sykkel- og hotellbestilling) og tegn et use-case diagram. 3

4 c) Lag et sekvensdiagram for brukstilfellet bestill sykkel og hotellrom. Du kan anta at det finnes en metode reserversykkel(type:string, fradato:dato, tildato:dato):pris_sykkel som returnerer totalprisen for leie av sykkelen i angitt periode hvis det finnes minst én ledig sykkel av denne typen. Du kan også anta at det finnes en metode reserverrom (hotell:string, typerom:string, fullpensjon: boolean, fradato:dato, tildato:dato): pris_rom som returnerer totalpris for rommet i angitt periode hvis det finnes minst ett ledig rom. Sekvensdiagrammet skal ha med hovedflyt (at sykkel og rom eksisterer) og alternativ flyt (mangler sykkel og/eller hotellrom) i samme diagram. Denne oppgaven skal ikke fokusere på betalingsløsningen, så du kan bruke følgende objekter i sekvensdiagrammet; bss:betalingssystem_sykkel og bsh:betalingssystem_hotell. I klassen Betalingssystem_sykkel er metoden betalsykkel(beløp:int) definert, tilsvarende i klassen Betalingssystem_hotell er betalrom(beløp:int) definert. Du kan anta at sjekking av kredittkort etc. blir utført på en tilfredsstillende måte, så dette skal du ikke modellere. d) Lag et klassediagram som tilsvarer sekvensdiagrammet fra oppgave (c). Klassediagrammet skal ha med attributter, metoder og assosiasjoner med multiplisitet. Oppgave 3: Arkitektur (10 %) Hvilken arkitektonisk stil ( architectural pattern ) mener du vil være best egnet for systemet i oppgave 2. Begrunn svaret. Oppgave 4: Testing (10 %) I oppgave 2 er det fem systemer som kommuniserer. Det web-baserte systemet kommuniserer med to ulike bestillingssystemer som igjen kommuniserer med hvert sitt betalingssystem. Beskriv hvordan du ville testet at denne kommunikasjonen fungerer som den skal. Oppgave 5: Smidig utvikling (10 %) Scrum har blitt en vanlig prosessmodell for utvikling av programvare. a) Gi en kort bekrivelse av rollen Produkteier og beskriv hvilke av de 12 smidige prinsippene denne rollen understøtter og på hvilken måte den gjør det. b) Gi en kort beskrivelse av teknikken «daily standup» og beskriv hvilke av de 12 smidige prinsippene denne teknikken understøtter og på hvilken måte den gjør det Lykke til

5 Vedlegg: De 12 smidige prinsippene: 1. Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av programvare som har verdi. 2. Ønsk endringer i krav velkommen, selv sent i utviklingen. Smidige prosesser bruker endringer til å skape konkurransefortrinn for kunden. 3. Lever fungerende programvare hyppig, med et par ukers til et par måneders mellomrom. Jo oftere, desto bedre. 4. Forretningssiden og utviklerne må arbeide sammen daglig gjennom hele prosjektet. 5. Bygg prosjektet rundt motiverte personer. Gi dem miljøet og støtten de trenger, og stol på at de får jobben gjort. 6. Den mest effektive måten å formidle informasjon inn til og innad i et utviklingsteam, er å snakke ansikt til ansikt. 7. Fungerende programvare er det primære målet på fremdrift. 8. Smidige metoder fremmer bærekraftig programvareutvikling. Sponsorene, utviklerne og brukerne bør kunne opprettholde et jevnt tempo hele tiden. 9. Kontinuerlig fokus på fremragende teknisk kvalitet og godt design fremmer smidighet. 10. Enkelhet kunsten å maksimere mengden arbeid som ikke blir gjort er essensielt. 11. De beste arkitekturer, krav og design vokser frem fra selvstyrte team. 12. Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt og så justerer det adferden sin deretter. 5