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.