LØSNINGSMOMENTER FOR : EKSAMEN FAGNAVN: FAGNUMMER: SYSTEMUTVIKLING IMT2243 EKSAMENSDATO: 4. juni 2007 KLASSE: 05HBINDA, 05HBINFA, 05HBISA, 05HBMETEA, 06HBINFA TID: 0900-1200 FAGLÆRER: Tom Røise ANTALL SIDER UTLEVERT: TILLATTE HJELPEMIDLER: 4 inkl. denne forsiden Alle trykte og skrevne INNFØRING MED PENN, evt. trykkblyant som gir gjennomslag Ved innlevering skilles hvit og gul besvarelse og legges i hvert sitt omslag. Oppgavetekst, kladd og blå kopi beholder kandidaten. Husk kandidatnummer på alle ark. Denne skriftlige eksamen teller 40 % av samlet karakter i emnet og må bestås separat for å oppnå tellende karakter i emnet. På hver oppgave er det angitt en prosentsats som viser oppgavens vekt ved sensur. Ta hensyn til dette når du disponerer tiden for å løse oppgaven.
Oppgavesett med sentrale løsningsmomenter (utgjør ikke noe fullstending fasit, men påpeker sentrale forhold som forventes dekket i en god besvarelse) : Oppgave 1 Leveranseutfordringen (10 %) Sommerville mener kundenes stadig strengere krav om hurtig leveranse av programvare med høy kvalitet blir en nøkkelutfordring innen systemutvikling fremover. Valg av systemutviklingsmodell er med å legge premissene på dette området. Beskriv kort de muligheter og begrensinger henholdsvis extreme Programming og Fossefallsmodellen gir utviklerne med hensyn på å tilfredsstille krav rundt rask levering av kvalitetsprogramvare. Kandidatene forventes å kommenterer systemutviklingsmodellene både med hensyn til håndtering av TID og håndtering av KVALITET. Generell omtale av hva XP og/eller Fossefall er belønnes ikke. I XP styrer man TID ved å garantere rask levering av del-produkter, mens modellen er svak på å si noe om når totalleveransen er klar. KVALITET håndteres med sterk fokus på testing og felles eierskap, men hensynet til helhetlig struktur i programvaren lider under at man bygger programvaren bit for bit. XP er derfor god til å styre både KVALITETEN og TID på delleveranser, men gir svakere styring på med hensyn på ferdigsstillelse av samlet løsning. Fossefallsmodellen søker derimot å ivareta helheten i prosjektet og gi forutsigbarhet både på kvalitet og tid for hele prosjektet. Den sentrale begrensingen i modellen er systemutviklingsprosjekters iboende innslag av endringer underveis i prosessen. Når det gjelder KVALITET gir modellen svært gode muligheter til å lage en ryddig og helhetlig programvare der kravene holdes stabile. Når det gjelder TID er modellen svært dårlig mht. hurtig leveranse siden man lager en totaltløsningen og ikke baserer seg på delleveranser. Oppgave 2 Brukermedvirkning (20 %) Offshore Software Development og Open Source Software Development er to tilnærminger til å drive systemutvikling som blir stadig mer utbredt. Diskuter holdninger og sentrale utfordringer knyttet til brukermedvirkning i hver av disse tilnærmingene. Igjen er det viktig at kandidatene ikke gir en generell innføring i utviklingsmetodene. Spørsmålet går utelukkende på hvordan brukermedvirkning håndteres. Brukermedvirkning i Offshore Software Development : Her må problematikken i at programmerere/utviklere ofte sitter i et helt annet land/miljø enn brukerne belyses. Mulighetene for direkte kontakt mellom brukerrepresentanter og utviklere er minimal da man både av språklige, tidssonemessige, kulturelle og kontraktsmessige forhold må gå veien via egne kontaktpersoner både på kunde og leverandørsiden. Brukermedvirkning vil ofte begrenses til at man deltar i utformingen av en tidlig kravspesifikasjon, men at man senere har minimale muligheter til reelt og direkte samarbeid med utviklerne. Innen Open Source Software Development er det store forskjeller på hvordan ulike prosjekter håndterer dette, men utviklingsmetoden legger i prinsippet opp til at det skal være svært stor grad av direkte brukermedvirkning i disse prosjektene. User Community og Developer Community bør kommenteres av kandidatene. Alle brukere oppfordres til å teste og gi rask
feedback på testversjoner av programvaren gjennom User Community. Her ønsker kjerneutviklerne å involvere sluttbrukerne i testing, samtidig med at de ber brukernes beskrive ønsker om nye features. Det tradisjonelle skillet mellom Brukere og Utviklere er ikke så tydelig i Open Source Software Development. Gjennom deltagelse i Developer Community har brukere mulighet til direkte å medvirke i selve utviklingen gjennom å levere inn egne bidrag. I Open Source Software Development er altså aktiv brukermedvirkning gjennom henholdsvis User Community og Developer Community helt nødvendig for hele fremdriften i programvareutviklingen. Oppgave 3 Konfigurasjonsstyring og Arkitektur Figuren over viser en arkitekturskisse hentet fra dokumentasjonen på konfigurasjonsstyrings-systemet Subversion (SVN). Merk at Berkeley DB og FSFS er alternative lagringsteknologier, det ene et database system det andre basert på lagring av filstrukturer. a) Beskriv kort hovedprinsippene rundt hvordan et konfigurasjonsstyringsverktøy benyttes av en gruppe utviklere i et systemutviklingsprosjekt. (10 %) Spørsmålet går på Hvordan verktøyet benyttes ikke hva det er for noe eller hvorfor man bør benytte det. Det bør forklares at deltagerne i en utviklingsgruppe har en felles informasjonsbank (repository) der de til enhver tid henter ut, bearbeider og legger tilbake ulike artefakter de jobber med. Artefaktene kan være dokumenter, modeller og i særdeleshet kildekode. Verktøyet hjelper dermed prosjektgruppa til å håndtere ulike versjoner av artefaktene slik at deltagerne kan hente ut ulike versjoner alt etter hva de ønsker. b) Subversion er i hovedsak basert på en repository-arkitektur, men har også innslag av prinsipper hentet fra Lagdelingsarkitektur og Klient/Tjener-arkitektur. Gi en tekstlig beskrivelse av det du ut fra figuren kan si om kombinasjonen av de tre arkitekturmodellene i denne programvaren. (20 %) At SVN i hovedsak er basert på en Repository-arkitektur ser man ut fra at all informasjon ligger lagret i en sentral database (Subversjon Repository). Lagdelingsarkitekturen ser man ved at figuren viser en 3- lagsarkitektur, med Presentasjonslaget øverst (GUI og kommandolinje-basert ), Applikasjonslaget med alle bearbeidingsmekanismer i midten, og Databaselaget nederst som har en sentralisert lagring av all informasjon i et Repositoruy (enten i database eller på filformat). Klient Tjener arkitektur kommenteres med at man har et Client interface. Man har altså tynne klienter som kun tar seg av presentasjonen av dataene.
Oppgave 4. Objektorientert Analyse (oppkonstruert case): Det tradisjonelle brettspillet Monopol har fortsatt stor popularitet. Spillet er i nyere versjoner også kalt Millionær av den norske utgiveren Damm og i denne oppgaven er figurer og utdrag av spilleregler hentet fra denne utgaven. Utgiveren ønsker nå at det skal utvikles en nettversjon av spillet. Selv om moderne teknologi gir muligheter for dramatisk modernisering, mener oppdragsgiveren at hemmeligheten bak suksessen ligger i at man i stor grad har bevart spillets opprinnelige regler. Som systemutvikler har du hittil kun fått den informasjonen som ligger ved dette oppgavesettet (figurene under samt vedlegg 1). Din oppgave er å foreta en objektorientert analyse basert på dette materialet og besvare følgende tre deloppgaver: a) Sett opp en detaljert Use Case beskrivelse som dekker alle funksjonelle krav knyttet til Flytt ut av fengsel (10 %) Svaret bør struktureres etter den mal vi har benyttet i emnet. Siden det bes om en detaljert UC må denne gå helt ned i detaljene når det gjelder å spesifisere funksjonalitetskrav rundt Flytt ut av fengsel. Kandidatene må holde seg kun til det med å Flytte ut, det trekkes for eventuelt å omtale hvordan man havner i fengsel. Beskrivelsen bør dekke alle alternative måter å komme ut av fengsel på (jfr. vedlagte spilleregler), og også forklare hvordan spillet skal forholde seg til feilsituasjoner. b) Man kan velge å operere med et Use Case for Bygg hus og et annet Use Case for Bygg hotell. Alternativt kan man slå dette sammen i et Use Case kalt Bygg bebyggelse. Argumenter med utgangspunkt i det som står i reglene og din kunnskap om objektorientert analyse for hvilket alternativ som er best i dette tilfellet. Underbygg dine argumenter med informasjon hentet fra vedlegget (10 %) Det er nøyaktig de samme reglene som gjelder for å bygge Hus og Hotell. Et Hotell er kun å betrakte som en spesialvariant når du har fire hus fra tidligere på en tomt. Alle likheter når det gjelder at du må ha alle tomter i en farge, at det er din tur til å slå, pris etc. gjør at det er klart best å samle dette i et Use Case Bygg bebyggelse, og kun la hotell være en alternativ til Main Success Senario. På denne måten unngår man Use-Case eksplosjon. c) Sett opp en domenemodell (også kalt konseptuelt klassediagram) som viser den virkelighet figurene og reglene omtaler (20 %) I domenemodellen skal de sentrale konseptene knyttet til dette brettspillet fremgå. Videre skal sentrale koblinger (assosiasjoner, aggregeringsstrukturer, arvestrukturer) fremgå, samtidig med at man unngår å koble alt sammen med alt siden modellen da blir lite lesbar. Benyttes aggregeringsstrukturer eller arvestrukturer er det viktig at dette gjøres riktig. Viktige attributter skal inngå, samtidig som det er understreket at metoder/operasjoner ikke skal inn i domenemodellen. Som alltid er det en fordel å kommentere modellen kort. Konseptene skal navnsettes i entall, og samme konsept skal ikke gjentas flere ganger. Under følger en modell der sentrale konsepter og koblingene mellom disse fremgår.