Løsningsforslag – Oblig 3. Oppgave 1: Estimering a. Foreslå egnet måte (eller egnede måter) for å måle størrelsen eller mengde funksjonalitet til systemet for leie av markasykler. Begrunn svaret og gjør nødvendige antagelser. Svar: Her kan nevnes andre lignende systemer – spesielt systemet for bysykkel som er godt kjent. Andre ting som kan nevnes er function points, object points, antall skjermbilder, antall usecases, antall user stories eller ”epics” hvis slike ting eksisterer Antall kodelinjer (LOC) er ikke aktuelt siden det neppe er tilgjengelig på et så tidlig tidspunkt. b. Foreslå egnet måte (eller egnede måter) for å måle kompleksiteten til systemet for leie av markasykler. Begrunn svaret og gjør nødvendige antakelser. Her kan nevnes målinger basert på ytelseskrav, kompleksitet i skjermbilder (subjektiv ekspertvurdering), algoritmisk kompleksitet, sikkerhetskrav. Temaet kan utvides til faktorer som påvirker produktivitet og/eller kompleksitet siden det står mer om produktivitet i boka. Kan også benytte det som i COCOMO kalles product cost drivers. Oppgave 2: Arkitektur Innen arkitektur bruker man ofte ulike “views” for å illustrere systemet fra ulike perspektiver. a. I forelesningen om arkitektur ble 4+1 view-modellen nevnt. Forklar kort hva de fire ulike view-ene innebærer. (Lærebok kap. 6.2 ) 1. Logisk view 2. Prosessview 3. Utviklingsview 4. Fysisk view Denne oppgaven er forholdsvis enkel, og går ut på å kunne gjengi stoff fra forelesning/lærebok. b. Hvorfor er det nyttig å benytte seg av ulike views for å beskrive arkitekturen for et system? Dette kan også hentes fra lærebok/forelesning. Nyttig å vise systemet fra ulike perspektiv. Se på helheten, ikke alle detaljene c. Gi et eksempel på hvordan systemet for markasykler kan settes opp som ee: 1. 3. lags logisk arkitektur 2. 4. lags fysisk arkitektur 3. lags logisk arkitektur Presentasjonslag: Dette laget tar for seg brukerinteraksjon. Brukerinteraksjon kan i markasykkelsystemet skje gjennom sykkelstativene, billettmaskinen, app og nettside. Business-logikk lag: Dette laget kan hente ut data og informasjon brukeren ber om gjennom presentasjonslaget. Datalag: Database som lagrer alle sykkelkunder, sykler og stasjoner. 4. lags fysisk arkitektur Klient: Klienter i markasykkelsystemet kan være billettautomatene, sykkelstativene, app og nettside. Data kan vises til bruker på disse klientene. Webserver og applikasjonsserver: Applikasjonsservere og webservere har mange bruksområder, og det er vanlig å ha begge disse serverne. Webserveren leverer hovedinnholdet mens applikasjonstjeneren kjører programmene som gir ekstra innhold. Begger serverne kan ligge på same maskin. Database : Database for sykkelkunder, sykler og statsjoner samt statistikk og rapporter. d. Hva er fordelene ved å benytte seg av lagdelt arkitektur? Systemet organiseres i lag - hvert lag er delt opp og organisert ut i fra funksjonelle fellestrekk. Dermed er hvert lag ansvarlig for seg selv og eventuelt uavhengig av hverandre, og det kan enkelt gjøres endringer i et eller flere lag uten for store påvirkninger til andre lag av systemet. e. Kan det være en ulempe å benytte seg av lagdeling? Begrunn svaret. For at systemet skal kunne utnytte fordelen av å være lagdelt, er det nødvendig at lagene er tydelig separert og riktig inndelt etter funksjonelle fellestrekk, hvis ikke kan et lag måtte kommunisere med et annet lag som ikke ligger i umiddelbar nærhet, og skillene viskes ut og man mister poenget med lagdeling – at hvert lag er uavhengig og enkelt å bytte ut. Flere lag kan bruke lengre tid på å betjene en tjeneste enn færre lag. f. Redegjør for de viktigste karakteristikkene for de arkitektoniske stilene: 1. Klient-server 2. MVC 3. SOA 4. Pipe and filter 1. Klient-server arkitektur består av en eller flere klienter som ber om en tjeneste fra en eller flere servere som utfører tjenesten. Klienten kobler seg til serveren ved å be om en tjeneste og klienten trenger ikke laste ned for eksempel programvaren selv på egen maskinvare. Fordelen kan være uavhengighet – en server kan byttes ut eller endres uten for store konsekvenser for levering av andre tjenester i samme system. En ulempe er at når serveren er nede, påvirker det alle brukere og klienter av serveren. 2. MVC står for model view controller. View representerer grensesnittet, og controller er bindeleddet mellom view og model. Brukes ofte når det er flere måter å se data på, for eksempel på en nettside. Fordelen med MVC er gjenbruk av kode – det er lettere å bytte ut ulike views for samme modell. 3. SOA står for service oriented architecture. I SOA består systemet av flere uavhengige tjenester som er løst koblet sammen og utgjør et system. Stilen tok utgangspunkt i høye kostnader ved å drive store systemer, og ønsket var å dele opp systemet slik at hver del fikk en funksjon hver og dermed ble mer uavhengig av hverandre. Oppdelingen gjør systemet mer håndterbar da hver del kan endres, byttes ut eller vedlikeholdes uten store konsekvenser for resten av systemet. 4. Pipe and filter. Pipe fører data gjennom et filter eller mellom flere filtrer. Hvis data skal gjennom flere filtrer, er prosessert data i et filter, neste filter sin inndata. Et eksempel på pipe and filter er et unix shell der tegnet « | » representerer en pipe, og kommandoer som ls (lists) og cd (change directory) er filtrer. Oppgave 3: Aktivitets- og tilstandsdiagram a. Hva er karakteristisk for et tilstandsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Begrunn svaret og kom med et eksempel på når det lønner seg. Et tilstandsdiagram viser tilstanden til et objekt (eller system) når objektet responderer på interne eller eksterne hendelser - objektet går fra en tilstand til en annen. Diagrammet er blant annet nyttig for utviklere da det kan være nødvendig å vite alle tilstander til et objekt og for å ha kontroll over hvordan objektene endrer oppførsel når de påvirkes av input. b. Hva er karakteristisk for et aktivitetsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Begrunn svaret og kom med et eksempel på når det lønner seg. Et aktivitetsdiagram viser det dynamiske aspektet ved et system – hvilke aktiviteter som utgjør et system og flyten mellom dem. I motsetning til et sekvensdiagram som viser en flyt ved en aktivitet, viser aktivitetsdiagrammet alle potensielle flyt. Diagrammet er enkelt og intuitivt å forstå, og viser ved hjelp av symboler tilhørende diagrammet alternative aktiviteter, og hvilke aktiviteter som kan gå i parallell. Systemet for markasykler skal som nevnt tidligere benytte seg av Ruters betalingsautomater. Her har man mulighet til å fylle opp et reisekort med penger eller en billett, og man kan også kjøpe enkeltbilletter uten reisekort. c. Modellér et tilstandsdiagram for betalingsautomaten. d. Modellér et aktivitetsdiagram for betalingsautomaten. Oppgave 4: Testing a. Forklar hva de ulike testfasene innebærer, og få med hva som skiller dem fra hverandre: - Enhetstesting - Integrasjonstesting - Systemtesting Akseptansetesting Enhetstesting tester alle operasjoner i et objekt, som metoder og funksjoner, for å stimulere frem tilstander objektet kan være i, og for å oppdage eventuelle feil og mangler ved en operasjon. En testmåte er å notere forventet resultat av en operasjon og måle mot faktisk resultat. Integrasjonstesting tester grensesnittet mellom flere komponenter når det settes sammen til en større komponent. Hver komponent kan bestå av flere objekter. Ved enhetstesting kan det være vanskelig å finne feil som kan oppstå hvis et objekt settes sammen med andre objekter da det ved eneshetstesting kun tester et objekt, mens ved en integrasjonstest kan slike feil lettere oppdages. Å teste på denne måten kan være å sjekke om komponentene kommuniserer med hverandre riktig, for eksempel at en komponent klarer å koble seg til en database. Integrasjontesting kan også brukes for grensesnittet mellom systemvare og maskinvare. I systemtesting settes alle komponenter som skal med i systemet sammen, og systemet testes i sin helhet. En av grunnene til systemtesting kan være at det finnes komponenter som er avhengig av at systemet integreres som en helhet før feil i dem, og mellom dem og andre komponenter, kan oppdages. Et eksempel er en komponent som har som funksjon å autorisere brukere med passord, men som ikke er satt sammen med komponenten som styrer tilgang til informasjon brukeren kan se. Begge komponentene kan være feilfri i en integrasjonstest, men feil i systemtest. Det kan også testes for det som går på ytelse, for eksempel om data blir overført mellom og gjennom komponentene til riktig tid, sikkerhet eller hvordan systemet reagerer under stort press fra mange brukere. Integrasjon- og systemtesting kan oppfattes likt, men forskjellen mellom dem er som nevnt at det i integrasjonstesting er flere komponenter som utgjør en større komponent og i systemtesting er alle komponentene som utgjør hele systemet. En annen forskjell er at systemtesting ikke tar for seg å teste den indre virkemåten til komponentene, dette er forventet å være testet før systemtesting som utgjør en av de siste testfasene. Akseptansetesting er til forskjell fra de tre ovenfornevnte, testing på brukernivå. Brukeren tester om systemet oppfyller kriterier som brukeren og utvikleren har avtalt på forhånd, for å eventuelt akseptere systemet. Akseptansetesting består av seks steg. Det første steget å definere og bli enige om kriteriene brukeren stiller til systemet, helst så tidlig som mulig i utviklerprosessen. Det andre steget er å avtale kostnader i form av tid og penger, og det praktiske rundt testingen – i hvilken fase det skal finne sted, risiko forbundet med testing og hvor mye ressurser som skal brukes på testing. Tredje og fjerde steget er å lage og utføre testene, for så i det femte å drøfte dem. Hvis systemet er godkjent vil det i det siste steget bli akseptert og betalt for, eventuelt blir systemet avslått og utvikleren må forbedre systemet i en ny runde. Brukeren bør teste produktet i domenet systemet er ment å brukes i, for å lettere oppdage feil og mangler i forbindelse med bruk, men også for å isolere dem til riktig brukergruppe eller situasjon slik at det kan være enklere å finne feil. Både funksjonelle og ikke-funksjonelle krav bør testes. Under smidig utvikling er akseptansetesting ikke en egen aktivitet som blir gjort i en bestemt fase, en av hovedgrunnene er fordi brukeren er en del av utvikler-teamet. I ekstrem programmering lager brukeren brukerhistorier og tester som skal teste om systemet møter kravene i brukerhistoriene, og kan gjennom dette gi kunnskap om domenet systemet er ment å brukes i. Prosessen bør ikke fortsette uten at testene er godkjent. b. Gi forslag på hvilke deler av systemet for markasykler som kan testes i hver av de ulike testfasene nevnt over. Sørg for at dere får med minst ett eksempel for hver av dem. Enhetstesting lar oss teste individuelle klasser og metoder i markasykkelsystemet, for eksempel metoden startUtlaan(Kunde k, int klokkeslett, String dato) i klassen Sykkel. Under integrasjonstesting kan vi teste sammensetningen av flere klasser, for eksempel klassene Sykkel, Stativ og Markasykler. Med systemtesting kan vi teste hele systemet – alle komponentene i markasykler. Akseptansetesting av ferdigproduktet. Oslo kommune kan teste om de kan logge inn med eget passord, hente ut relevante rapporter og statistikker til eget bruk og om de er forståelige, brukervennligheten til systemet samt det og leie og levere tilbake en sykkel.
© Copyright 2024