Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16

Transkript

1 Obligatorisk oppgave 3 INF1050: Gjennomgang, uke 16

2 Pensum for oppgaven Estimering Arkitektur 4+1 view-modellen og lagdeling Arkitektoniske stiler UML-modellering Tilstands- og aktivitetsdiagrammer Testing

3 Oppgave 1(a) og (b) a) Foreslå egnet måte for å måle størrelsen eller mengde funksjonalitet til systemet for leie av markasykler. b) Foreslå egnet måte for å måle kompleksiteten til systemet for leie av markasykler.

4 Oppgave 1(a, b): Løsningsforslag Estimere størrelse Kravspesifikasjonen må være fastsatt Fremgangsmåte Få oversikt over lignende systemer Få oversikt over hvordan denne spesifikasjonen skiller seg fra eksisterende systemer La erfarne utviklere bryte opp kravspesifikasjonen til spesifikke funksjonelle krav Kan estimere følgende Antall kodelinjer Antall funksjoner som skal implementeres (function points / story points) Hvor stort / omfattende er klassehierarkiet?

5 Oppgave 1(a, b): Løsningsforslag Estimere kompleksitet Gir opphav til viktige spørsmål Hvor mange subsystemer skal vi implementere? Hvor mange oppgaver er det vi mangler kompetanse til å løse her og nå? Hvor mange oppgaver/funksjonalitet har vi ikke gjort/implementert i tidligere? Hvor mange story- eller function-points skal implementeres? Hvor mange lag består arkitekturen av? Hvilken type og hvor mange systemer skal integreres? Kan estimere på følgende måte COCOMO II Planning Poker

6 Arkitektur

7 Oppgave 2(a): Arkitektur I forelesningen om arkitektur ble 4+1 view-modellen nevnt. Forklar kort hva de fire ulike view ene innebærer.

8 Oppgave 2(a): Løsningsforslag Logisk view Viser nøkkelabstraksjoner i systemet Objekter / objektklasser UML: Klassediagram, sekvensdiagram Prosessview Presenterer de dynamiske aspektene ved systemet Forklarer systemprosesser og hvordan disse samhandler ved kjøretid UML: Aktivitetsdiagram

9 Oppgave 2(a): Løsningsforslag Utviklingsview Viser hvordan programvaren er dekomponert for utvikling Hvilke komponenter har blitt implementert av hvilke utviklere? Nyttig for prosjektledere og utviklere UML: Package diagram Fysisk view Viser systemets maskinvare Hvordan programvarekomponenter er distribuert over HW i systemet UML: Deployment diagram

10 Oppgave 2(a): Løsningsforslag +1 Bruksmønstre Bruker relevante scenarier (bruksmønstre) Viser hvordan views henger sammen med et bestemt bruskmønster

11 Oppgave 2(a): Løsningsforslag 4+1 view-modellen Architectural Viewpoints:

12 Oppgave 2(b) Hvorfor er det nyttig å benytte seg av ulike views for å beskrive arkitekturen for et system?

13 Oppgave 2(b): Løsningsforslag Hvorfor er det nyttig å benytte seg av ulike views for å beskrive arkitekturen for et system? Umulig å representere alle aspekter ved et system i én modell Sentrale spørsmål Hva er det vi ønsker å kommunisere? / Hvem snakker vi med? 4+1 view-modellen lar oss Uttrykke aspekter ved systemet fra ulike perspektiver Inkluderer ulike interessenter Kunde, sluttbrukere, utviklere, prosjektledere

14 Oppgave 2(c.i) Gi et eksempel på hvordan systemet for markasykler kan settes opp som 3-lags logisk arkitektur.

15 Oppgave 2(c.i): Løsningsforslag Gi et eksempel på hvordan systemet for markasykler kan settes opp som 3-lags logisk arkitektur. Logisk arkitektur (Hvordan) Hvert lag forklares rent konseptuelt Mer abstrakt enn fysisk arkitektur Beskriver hvordan systemet fungerer Gir oversikt over Ulike komponenter som inngår i programvaren Logiske forhold mellom ressurser / komponenter

16 Oppgave 2(c.i): Løsningsforslag Gi et eksempel på hvordan systemet for markasykler kan settes opp som 3-lags logisk arkitektur. Eksempel på logisk arkitektur Presentasjonslaget Presenterer data til brukeren Ofte i form av et grensesnitt Logikklaget Prosesserer data i henhold til domeneregler / forretningslogikk Datalaget Stedet hvor data struktureres og lagres

17 Oppgave 2(c.i): Løsningsforslag Gi et eksempel på hvordan systemet for markasykler kan settes opp som 3-lags logisk arkitektur.

18 Oppgave 2(c.ii) Gi et eksempel på hvordan systemet for markasykler kan settes opp som 4-lags fysisk arkitektur.

19 Oppgave 2(c.ii): Løsningsforslag Gi et eksempel på hvordan systemet for markasykler kan settes opp som 4-lags fysisk arkitektur. Fysisk arkitektur (Hva) Hvert lag består av fysiske komponenter (maskiner / hardware) Redegjør for hvordan det fysiske miljøet er utformet Gir oversikt over Ulike maskiner (hardware) / enheter Hva som kjører på de fysiske komponentene Nettverks- og serverspesifikasjoner

20 Oppgave 2(c.ii): Løsningsforslag Gi et eksempel på hvordan systemet for markasykler kan settes opp som 4-lags fysisk arkitektur. Eksempel på fysisk arkitektur Klient Applikasjonen som kjører på enheten Webserver Mottar forespørsler fra klienten (sender videre) Applikasjonsserver Prosesserer data (henter fra databasen) Database Lagringsmedium for all nødvendig informasjon

21 Oppgave 2(c.ii): Løsningsforslag Gi et eksempel på hvordan systemet for markasykler kan settes opp som 4-lags fysisk arkitektur.

22 Oppgave 2(d) Hva er fordelene ved å benytte lagdelt arkitektur?

23 Oppgave 2(d): Løsningsforslag Hva er fordelene ved å benytte lagdelt arkitektur? Utgangspunkt for lagdeling Systemutviklingsprosessen er i stadig endring Ønsker en viss grad av separasjon og uavhengighet Bør kunne gjøre utskiftninger uten at det påvirker hele systemet Lagdelt arkitektur Organiserer systemet i flere lag Hvert lag kan i prinsippet erstattes uten at det påvirker resten av systemet Spesielt viktig for å støtte effektiv, inkrementell utvikling Skiller mellom fysisk og logisk lagdeling

24 Oppgave 2(d): Løsningsforslag Hva er fordelene ved å benytte lagdelt arkitektur? Fordeler ved lagdeling Tydelig inndeling av komponentenes ansvarsområder Hvert lag har en spesifikk funksjon / oppgave Bidrar til å gjøre systemet modulbasert Enklere å gjøre utskiftninger av ineffektive / utdaterte lag Kobler systemet sammen på en robust / intuitiv måte Vi får et hierarki å forholde oss til Sørger for god struktur og kan forbedre koden (lesbarhet)

25 Oppgave 2(e) Kan det være en ulempe å benytte seg av lagdeling?

26 Oppgave 2(e): Løsningsforslag Kan det være en ulempe å benytte seg av lagdeling? Ulemper ved lagdeling Kan være unødvendig i systemer med lav utskiftning av moduler Kan virke påtvunget / kunstig Spesielt for mindre systemer Vanskelig å dele systemet i enkeltlag for sammensatte systemer Kan resultere i et tregere system Spørringer må gjennom flere lag Ofte avhengige av ett språk og ett sentralisert applikasjonslag

27 Oppgave 3(f) Redegjør for de viktigste karakteristikkene for de arkitektoniske stilene i. Klient-server ii. MVC iii. SOA iv. Pipe-and-filter

28 Oppgave 3(f.i): Løsningsforslag Klient-server Funksjonalitet deles inn i tjenester (services) Hver tjeneste leveres av en egen server Klienter benytter seg av tjenestene ved å søke tilgang til ønsker server

29 Oppgave 3(f.i): Løsningsforslag Klient-server Består av tre hovedkomponenter Servere Tilbyr tjenester til andre komponenter Eksempel: Printer- og filtjenester Klienter Forespør tjenestene Nettverk Gir klientene tilgang til tjenestene

30 Oppgave 3(f.i): Løsningsforslag Klient-server Fordeler Servere kan fordeles over et distribuert nettverk All funksjonalitet trenger ikke implementeres av alle servere (tjenester) Kan allikevel gjøres tilgjengelig for alle klienter Ulemper Hver server (tjeneste) er såkalt single point of failure Hvis én server feiler vil hele nettverket påvirkes Uforutsigbar ytelse Kan lede til DoS-angrep Organisatoriske problemer hvis servere eies av ulike organisasjoner

31 Oppgave 3(f.ii): Løsningsforslag Model-View-Controller Skiller presentasjon og interaksjon fra selve data Systemet stykkes opp i tre logiske komponenter som samhandler MODEL VIEW Håndterer data og tilhørende dataoperasjoner Definerer og håndterer hvordan data presenteres for brukeren CONTROLLER Håndterer brukerinteraksjon og sender disse til MODEL og VIEW

32 Oppgave 3(f.ii): Løsningsforslag Model-View-Controller

33 Oppgave 3(f.ii): Løsningsforslag Model-View-Controller Fordeler Tydelig skille av ansvarsområder Data kan endres uavhengig av representasjon, og motsatt Model avhenger ikke av View, og kan endres uten å påvirke arkitekturen Enklere å støtte ulike filformater Ulemper Økt kompleksitet Ineffektiv aksess til data gjennom et bestemt grensesnitt

34 Oppgave 3(f.iii): Løsningsforslag Service-Oriented Architecture SOA En samling av tjenester Måte å utvikle distribuerte systemer på Hver komponent er en egen tjeneste Disse tjenestene er samlet i et register Tjenestene kommuniserer med hverandre Gjennom kommunikasjonsprotokoller over et nettverk XML-baserte protokoller SOAP og WSDL

35 Oppgave 3(f.iii): Løsningsforslag Service-Oriented Architecture Grunnleggende SOA Tjenesteregister "Klienter" Tjenesteleverandør

36 Oppgave 3(f.iii): Løsningsforslag Service-Oriented Architecture Fordeler Gjenbruk av tjenester Vedlikehold Hver tjeneste kan oppdateres uten at det påvirker andre tjenester Testing Små, enkeltstående komponenter er lettere å teste enn sammensatte Plattformuavhengighet Ulemper Økt overhead Validering av all input foregår hver gang tjenester interagerer Betydelige investeringskostnader med en gang (up front)

37 Oppgave 3(f.iv): Løsningsforslag Pipe-and-filter Arkitektonisk stil basert på dataflyt Baserer seg på en rekke uavhengige komponenter som filtrerer data Hver komponent utfører en dataendring / transformasjon Data flyter gjennom fra en komponent til en annen Kan minne om et samlebånd

38 Oppgave 3(f.iv): Løsningsforslag Pipe-and-filter Fordeler En stil som er enkel å forstå Utviklere for god oversikt over input / output og systemets adferd Arbeidsflyten ligner på velkjente strukturer fra forretningsprosessene Utvidelse av ytterligere transformasjoner er intuitiv Ulemper Dataformatet må avklares på forhånd og følges av alle samhandlende komponenter Hver komponent må parse input og unparse output til vedtatt format Øker systemets overhead

39 Oppgave 3(a) Hva er karakteristisk for et tilstandsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram?

40 Oppgave 3(a): Løsningsforslag Hva er karakteristisk for et tilstandsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Tilstandsdiagrammer = State diagrams Representerer en tilstandsmaskin Grafisk representasjon av de ulike tilstandene et system kan være i Beskriver hvilke hendelser som får systemet til å endre tilstand Altså: Hvordan går vi fra én tilstand og til en annen? Ytterligere informasjon følger ofte med diagrammene Fullstendig spesifikasjon som utdyper hva som inngår i en tilstand Hvordan påvirker aktiviteter / hendelser / triggere tilstandsendringer?

41 Oppgave 3(a): Løsningsforslag Hva er karakteristisk for et tilstandsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Minimale tilstander Rektangler med avrundede hjørner Navn som forklarer hva slags tilstand dette er Objektets adferd forblir stabil i dette vinduet Objektet vil være i denne tilstanden inntil det stimuleres av en hendelse Utdypende tilstander Øverste felt: Navn på tilstanden Nederste felt: Liste over interne hendelser / adferd som utføres i denne tilstanden

42 Oppgave 3(a): Løsningsforslag Hva er karakteristisk for et tilstandsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Tilstandsdiagram: Nytteverdi Viser hvilke tilstander systemet kan være i Viser hvordan vi beveger oss mellom tilstander Triggere Forutsetninger Viser deadlocks i systemet Tilstander vi ikke kan rømme fra

43 Oppgave 3(b) Hva er karakteristisk for et aktivitetsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram?

44 Oppgave 3(b): Løsningsforslag Hva er karakteristisk for et aktivitetsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Aktivitetsdiagram = Flytskjema (flowchart) Grafisk representasjon av arbeidsflyt Viser aktiviteter og tilhørende handlinger (actions) Viser overordnet kontrollflyt Beskriver hvordan mulige utfall av en aktivitet påvirker flyten Viser hvilke aktiviteter som kan utføres parallelt

45 Oppgave 3(b): Løsningsforslag Hva er karakteristisk for et aktivitetsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Grunnkomponenter i et aktivitetsdiagram Start: Angir hvor flyten starter Slutt: Angir hvor flyten ender Aktiviteter: Angir ulike aktiviteter som inngår i arbeidsflyten Representeres med navngitte, avrundede rektangler Kan være fysisk ( godkjenn søknad ) eller elektronisk ( vis kjøpshistorikk ) Valg: Angir at man står ovenfor et valg (decision) Eksempel: IF, IF-ELSE, CASE, osv.

46 Oppgave 3(b): Løsningsforslag Hva er karakteristisk for et aktivitetsdiagram, og hvorfor kan det være nyttig å benytte et slikt diagram? Aktivitetsdiagram: Nytteverdi Definerer flyten for en gitt aktivitet som kan gjennomføres i systemet Finner prosesser som kan kjøres parallelt og er uavhengige av hverandre Finner deadlocks i systemet Økt forståelse av arbeidsrutiner Aktivitetsdiagram kan modellere Arbeidsflyt i et system Organisasjonsflyt

47 Oppgave 3(c) Modeller et tilstandsdiagram for betalingsautomaten.

48 Oppgave 3(c): Løsningsforslag

49 Oppgave 3(c): Løsningsforslag

50 Oppgave 3(d) Modeller et aktivitetsdiagram for betalingsautomaten.

51 Oppgave 3(d): Løsningsforslag

52 Oppgave 3(d): Løsningsforslag Ikke inkludert at man kan velge forskjellige typer periodebilletter

53 Oppgave 4(a) Forklar hva de ulike testfasene innebærer, og få med hva som skiller dem fra hverandre. i. Enhetstesting ii. Integrasjonstesting iii. Systemtesting iv. Akseptansetesting

54 Oppgave 4(a): Løsningsforslag Ulike testnivåer

55 Oppgave 4(a.i): Løsningsforslag Enhetstesting Karakteristikker Tester individuelle enheter / komponenter (kildekode) Eksempel: Enheter i programmering Klasser / Metoder Enheten testes isolert fra resten av systemet Gjennomføres ofte tidlig i utviklingen / testingen Formål Forsikre seg om at enheten gjør akkurat som den skal Uavhengig av samspill med øvrige komponenter

56 Oppgave 4(a.i): Løsningsforslag Enhetstesting Eksempel Anta at vi har satt navn til Anders Forventer at hentnavn() skal returnere en tekststreng med verdien Anders For hver gang Anders returneres, regnes testen som vellykket Hvis andre verdier returneres (feil datatype, null, osv.), regnes testen som mislykket

57 Oppgave 4(a.ii): Løsningsforslag Integrasjonstesting Karakteristikker Sammensetning av flere enkeltstående enheter til komponenter Tester disse komponentene sammen Avdekker hvordan komponentene interagerer med hverandre

58 Oppgave 4(a.iii, iv): Løsningsforslag Systemtesting Tester et fullstendig, kjørbart system Sjekker at systemet innfrir de funksjonelle kravene Akseptansetesting Tester hvorvidt systemet kan aksepteres Sjekker om systemet innfrir kravspesifikasjonen Fokus på både funksjonelle krav og ikke-funksjonelle krav Ansvaret for akseptansetesting ligger hos kunden

59 Oppgave 4(b) Foreslå hvilke deler av systemet for markasykler som kan testes i hver av de ulike testfasene.

60 Oppgave 4(b): Løsningsforslag Foreslå hvilke deler av systemet for markasykler som kan testes i hver av de ulike testfasene. Enhetstesting Test de individuelle klassene i systemet, isolert fra hverandre Eksempel settnavn() Integrasjonstesting Test interaksjon mellom klassene / samhandlende objekter Eksempel finnledigesykler(), hentsyklerpaaovertid(), osv.

61 Oppgave 4(b): Løsningsforslag Foreslå hvilke deler av systemet for markasykler som kan testes i hver av de ulike testfasene. Systemtesting Test av hele systemet, med utgangspunkt i et sentralt bruksmønster Eksempel Kjøp billett for bestemt sykkeltype Akseptansetesting Systemet testes av kunden, involverer ofte sluttbrukere Eksempel Innfrir systemet kravspesifikasjonen? Hvordan oppleves det av brukeren?

62 Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.

63 Takk for meg