Systemarkitektur INF1050: Gjennomgang, uke 07
Kompetansemål Systemarkitektur Hva og hvorfor? Arkitektoniske modeller Kjennetegn Fordeler og ulemper Arkitektoniske stiler Ulike typer: Pipe-and-Filter / Client-Server / MVC / SOA
Gjennomgang av ukesoppgaver Ukens tema: Systemarkitektur
Oppgave 1 Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon.
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
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)
Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Tradisjonell systemutvikling: Fossefallsmodellen
Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Inkrementell systemutvikling: Flere aktiviteter gjøres samtidig Ofte i iterasjoner
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
Oppgave 1: Løsningsforslag Hva er arkitektur innen systemutvikling? Gi forslag til en definisjon. Spesifikasjonen leder til designprosessen
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
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
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 42010 "System and SW Engineering: Architecture Description"
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)
Oppgave 2(a) Angi fordeler og ulemper ved å lage arkitektur før utviklingen starter
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
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
Oppgave 2(b) Angi fordeler og ulemper ved å lage arkitektur mens utviklingen pågår
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
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
Oppgave 3 Hva kjennetegner god arkitektur?
Oppgave 3: Løsningsforslag Hva kjennetegner god arkitektur? Kjennetegn for god systemarkitektur
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
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
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
Oppgave 4 Hva er forskjellen på fysisk og logisk arkitektur?
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
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
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
Oppgave 4: Løsningsforslag Hva er forskjellen på fysisk og logisk arkitektur?
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
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
Oppgave 5(a) Hva er fordelene ved å bruke lagdelte arkitekturer?
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
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)
Oppgave 5(b) Når kan lagdeling være en ulempe?
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
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.
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
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
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
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
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
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
Oppgave 6: Løsningsforslag Model-View-Controller (MVC)
Oppgave 6: Løsningsforslag Model-View-Controller (MVC) Figur 6.3 (Sommerville)
Oppgave 6: Løsningsforslag Model-View-Controller (MVC) Figur 6.4 (Sommerville)
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
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)
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
Oppgave 6: Løsningsforslag Service-Oriented Architecture (SOA) Grunnleggende SOA Tjenesteregister "Klienter" Tjenesteleverandør Figur 19.1 (Sommerville)
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
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
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)
Oppgave 6: Løsningsforslag Eksempler på bruk av de ulike arkitektoniske stilene
Spørsmål? Ta kontakt Yulai Fjeld ydfjeld @ uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene
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.
Takk for meg Neste uke : Testing