Arkitektur Kirsten Ribu Høgskolen i Oslo 03.03.05 03.03.2005 1
I dag Generelt om arkitektur N-lags arkitektur 03.03.2005 2
Hva er arkitektur? Oppdelingen av et system i deler og spesifikasjon av samhandlingen / interaksjonen mellom disse delene for å danne helheten Den fundamentale strukturen til en enhet og samspillet mellom dens deler 03.03.2005 3
Overbelastet begrep Det finnes mange arkitekturer: 03.03.2005 4
IEEE Definisjoner Architecture: The fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. Architecture description A collection of products to document an architecture. 03.03.2005 5
Viktige prinsipper for moderne systemutvikling Arkitektur-orientert tilnærming Iterativ livssyklus prosess Komponentbasert utvikling Endrings-orientert miljø Modell-basert notasjon Objektiv kvalitetskontroll 03.03.2005 6
Programvarearkitektur Programvare består av en samling abstrakte strukturer: datastrukturer Interaksjonstrukturer concurrency (samtidighet) Transksjonsstrukturer Komponenetstrukturer. Ingen av strukturene ER arkitekturen i seg selv Bare representasjoner av ulike syn på arkitekturen. 03.03.2005 7
Modellbasert utvikling 03.03.2005 8
Komponentbasert utvikling Logisk arkitektur for et enkelt e-handels system. 03.03.2005 9
Farer i utviklingsprosessen: Mangel på styring 1 Bruk og kast kode Noen ganger oppstår store, kaotiske systemer på bakgrunn av bruk-og-kast kode Bruk-og-kast har til hensikt å bli brukt en gang prototyping for klargjøring av krav f.eks. Fare: Å sette prototypen i produksjon 03.03.2005 10
Mangel på styring 2 Spaghetti-kode Systemet viser tegn på uregulert vekst, gjentatte og kostbare reparasjoner. Informasjonen flyter åpent mellom deler av systemet som er fjernt fra hverandre Noen ganger er all informasjon global eller redundant 03.03.2005 11
The complete Pasta Theory of Software Spaghetti-kode Kaotisk, vanskelig å forstå, umulig å vedlikeholde Lasagne-kode enkel, forståelig og lagdelt struktur uheldigvis monolittisk og vanskelig å modifisere selv om den er strukturert I praksis er det vanskelig å endre bare ett lag uten at det virker inn på den øvrige struktur Ravioli-kode Den ideelle struktur Små komponenter som er løst koblet Hver komponenet er en pakke som inneholder litt kjøtt eller annen næring til systemet, enhver komponent kan modifiseres eller erstattes uten å virke inn på de øvrige komponenter. 03.03.2005 12
Mangel på styring 3 Analogi: slum Lite planlegging, ukontrollert vekst, billige materialer, manglende infrastruktur, Vedlikeholdsproblemer 03.03.2005 13
Mangel på styring forts Mange programvaresystemer er fra et arkitektursynspunkt ikke stort bedre enn en slum Det mangler gode verktøy, metoder og infrastruktur (rammeverk) Deler av systemet vokser uten kontroll Mangel på solid arkitektur gjør at problemer ett sted påvirker andre deler av systemet 03.03.2005 14
Arkitekturbegrepet Bygninger er synlige, fysiske objekter. Programvare er usynlig Et brukergrensesnitt presenterer en visualisering av programvare, slik en fasade framstiller en bygnings arkitektur I motsetning til fysisk arkitektur er det bare utviklerne som vet hvordan programvaren ser ut på innsiden 03.03.2005 15 The London Eye
Systemarkitektur - Introduksjon Det finnes forskjellige modeller for arkitektur Delsystemer av store systemer kan ha forskjellig arkitektur Vi må velge en arkitekturmodell eller sette sammen flere Arkitekturen påvirker Ytelse Robusthet Distribuerbarhet Vedlikeholdbarhet 03.03.2005 16
Systemarkitektur og ikkefunksjonelle krav Ytelse Bruk få moduler med lite innbyrdes kommunikasjon (lav kobling) Sikkerhet Bruk lagdelt arkitektur der kritiske data lever trygt i et sikkert indre lag Tilgjengelighet Gjør det mulig å skifte ut moduler uten å stoppe systemet Vedlikeholdbarhet Bruk mange små og innkapslede moduler. Unngå avhengigheter 03.03.2005 17
Blokkdiagram Første aktivitet i arkitekturutforming En boks per subsystem Identifikasjons -system Armkontroller Videosystem Klokontroller Subsystemer kan deles igjen Pakningsvalgsystem Blokkdiagrammet er lett å forstå Pakke system Transportbåndkontroller 03.03.2005 18
Blokkdiagrammer er ikke nok Viser oppbygging, men mangler detaljer Nyttig for kommunikasjon med interessenter Nyttig for å planlegge videre arbeid Trenger i tillegg informasjon om Interaksjon Datautveksling Grensesnitt Tre modeller kan brukes til dette formålet Repository Klient-tjener Abstrakt maskin 03.03.2005 19
Repository arkitektur Brukes i systemer som håndterer store datamengder Systemet organiseres rundt en felles database (repository) Passer der data produseres av ett sybsystem og brukes av et annet 03.03.2005 20
Klient/tjener modell Frittstående servere Klienter som benytter tjenester hos serverne Nettverk som tillater forbindelse mellom klient og tjener Kan kombineres med repository Ytelsesproblemer ved større datamengder Distribuert arkitektur er fleksibel Backup og datastruktur på hver server 03.03.2005 21
Abstrakt-maskin modell Også kalt lagdelt arkitektur Hvert lag en abstrakt maskin som leverer tjenester til neste lag Som OSI-modellen for nettverksarkitektur (7 lag) Støtter inkrementell utvikling Kan skifte ut et lag hvis grensesnittet er uendret Bare nabolag påvirkes av grensesnittendringer Maskinavhengighet kan avgrenses til indre lag Lagdeling kan gi ytelsesproblemer 03.03.2005 22
N-lags arkitektur Skille / isolere ansvarsområder og funksjonalitet Mestre kompleksitet dele opp i mindre deler Splitt og hersk Benytte funksjonalitet uten å kjenne virkemåte i detalj Begrense påvirkning mellom ulike lag Eks.: GUI db Utbyttbare komponenter Lett å endre deler av systemet Gjenbruke funksjonalitet fra andre prosjekt Standardisering muliggjør bruk av hyllevare 03.03.2005 23
Klassisk tre-lagsarkitektur Presentasjon Brukerinteraksjon Presentasjon av data Domene (Forretningslogikk) Data Begreper, sammenhenger, data, beregninger, regler som gjelder Utgjør kjernen i systemet Hva systemet gjør Tilgang til og lagring av data Oftest: Database + mellomvare Presentasjon Domene Data 03.03.2005 24
3 lags arkitektur (Microsoft eksempel) 03.03.2005 25
Modulkobling Modulkobling er et mål på sammenkoblingene mellom modulene vi har satt opp i designet. Det er et ideal å komme frem til moduler med lav kobling Sterk modulkobling vanskeliggjør vedlikehold. Ved lav kobling er endringer og feilsøking enklere, da datautvekslingen er minimal Ved å holde datastrukturene internt i den enkelte modul oppnår man en lavere koblingsgrad (innkapsling innen OO). Globale data er et skrekk-eksempel på høy kobling - men mange benytter seg av det likevel 03.03.2005 26
Flere lag Forfine GUI-siden Splitter Presentasjon: Datapresentasjon Kontroll Isolere brukerinteraksjon fra presentasjon Tilsvarer MVCpattern Model - View - Controller M - Domene V - Datapresentasjon C - Kontroll Datapresentasjon Kontroll Domene Data 03.03.2005 27
Ulike typer patterns - mønstre 03.03.2005 28
Patterns på ulike design nivåer 03.03.2005 29
Model-View-Controller - MVC MVC = et arkitekturmønster (pattern) En måte å strukturere arkitekturen i et system som har et grafisk brukergrensesnitt Består av tre komponenter: Datamodell, View: GUI, Controller 03.03.2005 30
MVC Arkitekturen muliggjør fleksibelt skjembilde-design og interaksjonsdesign Adskiller forretningslogikk og database fra den grafiske presentasjonen. 03.03.2005 31
MVC Model-View-Controller 03.03.2005 32
Model Modellen representerer forretningslogikken og reglene som definerer tilgang til dataene 03.03.2005 33
View View viser innholdet i modellen. Spesifiserer hvordan data skal vises Har ansvar for å opprettholde samme presentasjon når modellen endres 03.03.2005 34
Controller Kontrolleren oversetter interaksjoner med View et til handlinger (actions) som skal utføres av modellen I en stand-alone GUI klient kan interaksjon være klikk på knapper eller menyvalg. I en webapplikasjon er interaksjon representert som GET og POST Handlinger som utføres av modellen kan være: Aktivisering av business prosesser Endringer i modellen: oppdateringer etc. 03.03.2005 35
Distribuerte systemer 03.03.2005 36
Distribuerte systemer Distribuert funksjonalitet Fordeler Tilgjengeliggjøre applikasjoner over nettverk Flere maskiner involvert, kommunikasjon over nettverk Ulike distribusjonskanaler: web, wap, telefon Dele ressurser og funksjonalitet Muliggjør sentralt datalager Forenklet drift unngå desentral deployment av kode Utfordringer Ytelse - kall mellom to prosesser er DYRT! Effektive mekanismer for kommunikasjon: mye og sjelden 03.03.2005 37
Distribuerte systemer Fordeler funksjonalitet Flere maskiner Kommunikasjon over nettverk Hvor går skillelinjene? Ansvarsområder Teknologi Ytelse Transport av data Protokoll Kapasitet Remote call = fjernkall DYRT Performance killer Nettverk Lag 1 Lag 2 Lag N 03.03.2005 38
Klient-tjener arkitektur Klassisk 2-lags klienttjener 2 maskiner involvert Knyttet sammen med nettverk Klient Brukergrensesnitt Lokale beregninger Tjener Sentrale beregninger Oftest: sentralt datalager Klient Tjener 03.03.2005 39
To-delt kommunikasjonssystem 03.03.2005 40
Lagdeling distribuert prosessering 03.03.2005 41
Fordeler med N-lags arkitektur Selvstendige komponenter Kan gjenbrukes Kan deles mellom applikasjoner Gode verktøy tilgjengelige VB, JBuilder Web editorer Kan gi bedre skalerbarhet Enklere vedlikehold Endringer kan omfatte kun få lag Isolere lag mot påvirkning fra andre lag 03.03.2005 42
Problemer med N-lags arkitektur Ytelse Flere lag gir flere kall for å få utført en oppgave Må minimere datatransport og kall til tjener Husk standard design-prinsipp: Lav kopling Utvikling krever spesialisert kompetanse Feil arkitekturvalg gir mye omarbeidin GUI, mellomvare, database, nettverk Endringer kan påvirke alle lag Ett nytt datafelt i databasen påvirker helt gjennom til GUI 03.03.2005 43
Neste gang Kirsten er borte hele uka Mandag: Overraskelse Torsdag: Ingen forelesning 03.03.2005 44