Systemarkitektur. INF1050: Gjennomgang, uke 07

Transkript

1 Systemarkitektur INF1050: Gjennomgang, uke 07

2 Kompetansemål Systemarkitektur Hva og hvorfor? Arkitektoniske modeller Kjennetegn Fordeler og ulemper Arkitektoniske stiler Ulike typer: Pipe-and-Filter / Client-Server / MVC / SOA

3 Gjennomgang av ukesoppgaver Ukens tema: Systemarkitektur

4 Oppgave 1 Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon.

5 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Mange definisjoner, men noen fellestrekk Strukturen / systemets struktur Består av elementer / synlige egenskaper / forholdet mellom disse Systemarkitektur Abstraksjon som hjelper til med å håndtere systemkompleksitet Viser hvordan man har valgt å strukturere et system i flere elementer Viser hvordan samspill og organisering mellom komponenter foregår

6 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Hvordan passer arkitektur inn i systemutviklingsbildet? Systemutvikling Utvikling og forvaltning av programvaresystemer Består (og påvirkes av) en rekke komponenter / personer / øvrige faktorer Programvare og kode / Hardwarekomponenter Krav og spesifikasjoner Aktører og interessenter (både interne og eksterne) Systemutviklingsprosess (plandrevet, smidig)

7 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Tradisjonell systemutvikling: Fossefallsmodellen

8 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Inkrementell systemutvikling: Flere aktiviteter gjøres samtidig Ofte i iterasjoner

9 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Felles for begge: Må ha en viss spesifikasjon / beskrivelse i bunn

10 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Spesifikasjonen leder til designprosessen

11 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Design av arkitektur Første steget i designprosessen Forstå hvordan systemet skal organiseres Redegjør for de strukturelle komponentene som utgjør et system Forholdene mellom disse komponentene Output Modell som beskriver systemets organisering

12 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Lavnivå-design: Architecture in the small Tar for seg arkitekturen til individuelle programmer / Indre struktur Hvordan er hvert program bygget? Hvilke komponenter består programmet av? Høynivå-design: Architecture in the large Tar for seg arkitekturen til hele, komplekse systemer / Hovedmoduler Kan inkludere arkitekturen til undersystemer, programmer, komponenter Kan være systemer som administreres på flere maskiner / av flere bedrifter

13 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Hvordan representeres arkitektur? Tradisjonelt: Enkle, uformelle blokkdiagrammer Viser de ulike komponentene som utgjør et system og deres forhold Kritikk: Ikke detaljerte nok Har i senere tid blitt mer komplekse (detaljerte) Skal gi tilstrekkelig informasjon om et system for å kunne forstå det på detaljnivå Ulike standarder ISO/IEC/IEE "System and SW Engineering: Architecture Description"

14 Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Eksempel: Pakkerobot Viser arkitekturen til systemet Viser komponenter som må utvikles Viser forhold mellom komponentene Kan pakke ulike objekter Vision system identifiserer objektene Velger rett innpakningsmetode Figur 6.1 (Sommerville)

15 Oppgave 2(a) Angi fordeler og ulemper ved å lage arkitektur før utviklingen starter

16 Oppgave 2(a): Løsningsforslag Angi fordeler og ulemper ved å lage arkitektur før utviklingen starter Fordeler: Arkitektur før utviklingen starter Gir økt forståelse av helheten / god oversikt Fungerer som et kommunikasjonsverktøy i dialog med kunder Setter rammer for viktige detaljer i systemet Teknologi / Plattform / Struktur Vanlig å sette sammen team basert på valg av arkitektur Kan bidra til å avdekke problemer tidlig i utviklingen

17 Oppgave 2(a): Løsningsforslag Angi fordeler og ulemper ved å lage arkitektur før utviklingen starter Ulemper: Arkitektur før utviklingen starter Kan føre til feil fokus Bruker tid på et problem som viser seg å ikke eksistere Kan gi en falsk trygghetsfølelse Store beslutninger tas på manglende grunnlag Kravendringer underveis kan føre til at arbeid må gjøres på nytt Vanskelig for en arkitekt å forespeile seg hele systemet på forhånd

18 Oppgave 2(b) Angi fordeler og ulemper ved å lage arkitektur mens utviklingen pågår

19 Oppgave 2(b): Løsningsforslag Angi fordeler og ulemper ved å lage arkitektur mens utviklingen pågår Fordeler: Arkitektur mens utviklingen pågår Bedre samspill mellom kode og arkitektur Fanger lettere opp endringer i behov Lettere å håndtere endringer i omgivelser og teknologi Gir frihet til å inkludere sene innspill fra kunden Det lages ikke mer enn nødvendig Lettere å holde seg innenfor budsjett- og tidsrammer

20 Oppgave 2(b): Løsningsforslag Angi fordeler og ulemper ved å lage arkitektur mens utviklingen pågår Ulemper: Arkitektur mens utviklingen pågår Fare for å møtte gjøre ting om igjen Blir nødt til å endre ting / komponenter uten å produsere mer Fare for å være korttenkt Antar at nærmeste løsning er beste løsning Ikke nok tid til både design og dokumentasjon av arkitekturen Utfordrende for ikke-tekniske interessenter å forstå konsepter

21 Oppgave 3 Hva kjennetegner god arkitektur?

22 Oppgave 3: Løsningsforslag Hva kjennetegner god arkitektur? Kjennetegn for god systemarkitektur

23 Oppgave 3: Løsningsforslag Hva kjennetegner god arkitektur? Kjennetegn for god systemarkitektur Mulig å implementere et system i henhold til arkitekturen Arkitekturen er et resultat av konsekvent bruk av Prinsipper / Teknikker gjennom alle prosjektfaser Robust når det gjøres endringer i systemet Kilde til veiledning gjennom hele systemets levetid Gjenbruk av etablerte ingeniørprinsipper

24 Oppgave 3: Løsningsforslag Hva kjennetegner god arkitektur? Øvrige fordeler med god systemarkitektur Gjenbruk Arkitekturen gir en helhetlig beskrivelse av hvordan systemet er strukturert Ofte den samme for systemer med relativt like krav Kan støtte gjenbruk Dokumentasjon Arkitektur kan fungere som dokumentasjon for systemet Utfyllende dokumentasjon til kravspesifikasjonen

25 Oppgave 3: Løsningsforslag Hva kjennetegner god arkitektur? Ikke alltid like enkelt å lage god systemarkitektur Architecture Tradeoff Analysis Method (ATAM) Evaluere systemarkitekturen i henhold til kvalitetsmål Kartlegge risiko knyttet til valgt arkitektur Eksempler

26 Oppgave 4 Hva er forskjellen på fysisk og logisk arkitektur?

27 Oppgave 4: Løsningsforslag Hva er forskjellen på fysisk og logisk 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 Spesielt gunstig for utviklere / ingeniører

28 Oppgave 4: Løsningsforslag Hva er forskjellen på fysisk og logisk arkitektur? Logisk arkitektur (HVORDAN) Hvert lag forklares rent konseptuelt Mer abstrakt enn fysisk arkitektur Beskriver hvordan systemet fungerer Funksjoner og informasjon Gir oversikt over Ulike komponenter som inngår i programvaren Logiske forhold mellom ressurser / komponenter

29 Oppgave 4: Løsningsforslag Hva er forskjellen på fysisk og 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

30 Oppgave 4: Løsningsforslag Hva er forskjellen på fysisk og logisk arkitektur?

31 Oppgave 4: Løsningsforslag Hva er forskjellen på fysisk og logisk 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

32 Oppgave 4: Løsningsforslag Hva er forskjellen på fysisk og logisk arkitektur? Viser de ulike lagene: Klient-, web-, logikk-, og databaselaget Disse lagene har fysiske komponenter Klient / Webserver / Applikasjonsserver / Database

33 Oppgave 5(a) Hva er fordelene ved å bruke lagdelte arkitekturer?

34 Oppgave 5(a): Løsningsforslag Hva er fordelene ved å bruke lagdelte arkitekturer? Utgangspunkt for lagdeling Systemutviklingsprosessen er i stadig endring Ønsker en viss grad av separasjon og uavhengighet Bør kunne gjøre utskiftinger uten at dette 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

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

36 Oppgave 5(b) Når kan lagdeling være en ulempe?

37 Oppgave 5(b): Løsningsforslag Når kan lagdeling være en ulempe? 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

38 Oppgave 6 Redegjør de viktigste karakteristikkene for følgende arkitektoniske stiler: Pipe-and-Filter Klient-Server Model-Vew-Controller (MVC) Service-orientert arkitektur (SOA) Gi eksempler på applikasjoner / systemer som typisk vil bruke de ulike stilene.

39 Oppgave 6: 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

40 Oppgave 6: 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

41 Oppgave 6: 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

42 Oppgave 6: 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

43 Oppgave 6: 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

44 Oppgave 6: Løsningsforslag Model-View-Controller (MVC) 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

45 Oppgave 6: Løsningsforslag Model-View-Controller (MVC)

46 Oppgave 6: Løsningsforslag Model-View-Controller (MVC) Figur 6.3 (Sommerville)

47 Oppgave 6: Løsningsforslag Model-View-Controller (MVC) Figur 6.4 (Sommerville)

48 Oppgave 6: Løsningsforslag Model-View-Controller (MVC) 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

49 Oppgave 6: Løsningsforslag Service-Oriented Architecture (SOA) Historisk perspektiv World Wide Web Revolusjonerer informasjonsutveksling Klienter kunne nå hente informasjon fra servere utenfor egen organisasjon Problem: Data er kun tilgjengelig via en nettleser (upraktisk) Foreslått løsning: Webtjenester Organisasjoner som ønsker å dele informasjon Web Service Interface Grensesnittet definerer: Tilgjengelig data + Hvordan data kan hentes ut Standard representasjon av informasjonsressurs (data)

50 Oppgave 6: Løsningsforslag Service-Oriented Architecture (SOA) 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

51 Oppgave 6: Løsningsforslag Service-Oriented Architecture (SOA) Grunnleggende SOA Tjenesteregister "Klienter" Tjenesteleverandør Figur 19.1 (Sommerville)

52 Oppgave 6: Løsningsforslag Service-Oriented Architecture (SOA) Grunnleggende SOA Tjenesteleverandør (Service Provider) Design + implementasjon av tjenester / Spesifiserer grensesnitt til tjenestene Publiserer tjenestene og informasjon om disse Klienter (Service Requestor) Ønsker tjeneste og finner aktuell SP / Binder egen applikasjon til tjenesten Kommuniserer med tjenesten gjennom protokoller (SOAP/WSDL) Tjenesteregister (Service Registry) Stiller ut tjenestene og lar klienten søke i registeret Match-maker

53 Oppgave 6: Løsningsforslag Service-Oriented Architecture (SOA) SOAP (Simple Object Access Protocol) Protokoll for utveksling av meldinger Støtter kommunikasjon mellom tjenester, klienter og tjenesteleverandører Påkrevde og valgfrie komponenter for meldinger som utveksles WSDL (Web Services Description Language) Web Service Definition Language Definerer standard grensesnitt for tjenester Hvordan tjenester opererer (navn, parametere, typer) og bindinger mellom tjenester

54 Oppgave 6: Løsningsforslag Service-Oriented Architecture (SOA) 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)

55 Oppgave 6: Løsningsforslag Eksempler på bruk av de ulike arkitektoniske stilene

56 Spørsmål? Ta kontakt Yulai Fjeld uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene

57 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.

58 Takk for meg Neste uke : Testing