Arkitektur. Kirsten Ribu Høgskolen i Oslo

Transkript

1 Arkitektur Kirsten Ribu Høgskolen i Oslo

2 I dag Generelt om arkitektur N-lags arkitektur MVC Model View Controller mønsteret

3 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

4 Overbelastet begrep Det finnes mange arkitekturer:

5 Viktige prinsipper for moderne systemutvikling Arkitektur-orientert tilnærming Iterativ livssyklus prosess Komponentbasert utvikling Endrings-orientert miljø Modell-basert notasjon Objektiv kvalitetskontroll

6 Inkrementell utvikling

7 Modellbasert utvikling

8 Komponentbasert utvikling Logisk arkitektur for et enkelt e-handels system

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

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

11 Thecomplete 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

12 Mangel på styring 3 Analogi: slum Lite planlegging, ukontrollert vekst, billige materialer, manglende infrastruktur, Vedlikeholdsproblemer

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

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 The London Eye, Marks Barfield Architects

15 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

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

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

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

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

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

21 Eks: Film- og bildebibliotek Client 1 Client 2 Client 3 Client 4 Wide-bandwidth network Catalogue server Video server Picture server Hypertext server Catalogue Film clip files Digitized photographs Hypertext web

22 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

23 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

24 Klassisk tre-lagsarkitektur Presentasjon Brukerinteraksjon Presentasjon av data Domene (Forretningslogikk) Begreper, sammenhenger, data, beregninger, regler som gjelder Utgjør kjernen i systemet Hva systemet gjør Data Tilgang til og lagring av data Oftest: Database + mellomvare Presentasjon Domene Data

25 3 lags arkitektur (Microsoft eksempel)

26 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

27 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

28 Ulike typer patterns

29 Patterns på ulike design nivåer

30 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

31 MVC Arkitekturen muliggjør fleksibelt skjembilde-design og interaksjonsdesign Adskiller forretningslogikk og database fra den grafiske presentasjonen

32 MVC Model-View-Controller

33 Model Modellen representerer forretningslogikken og reglene som definerer tilgang til dataene

34 View View viser innholdet i modellen. Spesifiserer hvordan data skal vises Har ansvar for å opprettholde samme presentasjon når modellen endres

35 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

36 Distribuerte systemer

37 Distribuerte systemer Distribuert funksjonalitet Tilgjengeliggjøre applikasjoner over nettverk Flere maskiner involvert, kommunikasjon over nettverk Ulike distribusjonskanaler: web, wap, telefon Fordeler 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

38 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

39 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

40 To-delt kommunikasjonssystem

41 3-lags arkitektur i endesystemene

42 Remote Data Access (RDA)

43 Lagdeling distribuert prosessering

44 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

45 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

46 Neste gang Brukergrensesnitt Interaksjonsdesign