Utforming av arkitektur

1. Utforming av arkitektur In 140 Sommerville kap 10

2. Mål • Forstå hvorfor arkitektur er viktig • Forstå at arkitektur kan dokumenteres med forskjellige modeller • Bli introdusert til noen arkitekturtyper både for systemstruktur, kontroll og modulær dekomponering • Forstå hvordan anvendelsesspesifikk arkitektur kan danne grunnlag for arkitekturen til en produktlinje • Sammenligne arkitekturutforminger

3. Systemarkitektur - Introduksjon • Det finnes forskjellige modeller for arkitektur • Delsystemer av store systemer kan godt ha forskjellig arkitektur • Vi må velge en eller sette sammen flere • Arkitekturen påvirker • Ytelse • Robusthet • Distribuerbarhet • Vedlikeholdbarhet

4. Systemarkitektur og ikke-funksjonelle krav • Ytelse – Bruk få moduler med lite innbyrdes kommunikasjon • Sikkerhet – Bruk lagdelt arkitektur der kritiske data lever trygt i et sikkerhetsvalidert indre lag • Trygghet – Plasser kritiske funksjoner samlet, slik at trygghetsvalidering blir mulig. • Tilgjengelighet – Bruk redundans og gjør det mulig å skifte ut moduler uten å stoppe systemet. • Vedlikeholdbarhet – Bruk mange små og innkapslede moduler. Unngå avhengigheter

5. Strukturering av systemer • Dette er første aktivitet i arkitekturutforming • Blokkdiagram med en boks per delsystem. Delsystemer kan deles igjen. • Blokkdiagrammet er lett å forstå

6. Blokkdiagram - eksempel

7. Blokkdiagrammer – 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

8. Repository-arkitektur • Brukes i systemer som håndterer store datamengder • Systemet organiseres rundt en felles database (repository) • Passer der data produseres av et delsystem og brukes av et annet.

9. Fordeler og ulemper med repositoryarkitektur • Enkel deling av store mengder data • Delsystemene må tilpasses en felles datamodell • Dataproduserende delsystem trenger ikke å kjenne detaljene i data-konsummerende delsystem • Tungt å endre systemet fordi datamodellen blir en tvangstrøye • Backup, sikkerhet, gjenstart løses sentralt • Dermed samme løsning for alle • Integrasjon av nye verktøy mulig hvis de kan tilpasses til datamodellen • Vanskelig å fordele på flere maskiner

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

11. Film and picture library

12. Abstrakt-maskin modell • Også kalt lagdelt arkitektur • Hvert lag en abstrakt maskin som leverer tjenester til neste lag • OSI-modellen for nettverksarkitektur • 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

13. Kontrollmodeller • Undersystemer må styres for å levere rette tjenester til rett tid. • Strukturell modell vs kontrollmodell • Kontrollmodeller på arkitekturnivå beskriver kontrollflyten mellom delsystemer • Sentralisert kontroll • Hendelsesbasert kontroll

14. Sentralisert kontroll • Et av undersystemet er systemkontroller • Sekvensiell modell=call- returnmodell. • Parallell modell = manager model.

15. Sekvensiell modell • call- returnmodell. • Top down subrutinehierarki. • Subrutinen som har kontrollen kan • kalle andre lavere nivå subrutiner • returnere til kallende rutineAda, Pascal, C • Rigid og begrenset modell • Lett å analysere kontrollflyt og systemreaksjon • Vanskelig å håndtere unntak

16. Call-return modell

17. Parallell modell • manager model • System med flere prosesser • Systemkontrolleren • starter, • stopper • koordinerer andre systemprosesser. • Kan også implementeres sekvensielt. • Case fra tilstand • Kontrollprosessen går i evig sløyfe (event loop model)

18. Parallell modell

19. Hendelsesdrevne systemer • Eksterne hendelser • To typer • Kringkasting til alle undersystemer som har erklært interesse (broadcast) • Avbruddsdrevne modeller (interrupt)

20. Kringkastingssystemer • Brukes der delsystem er på nett • Kan også befordre meldinger Event and message handler • Selektive og ikke-selektive • Lett å utvide • Synkroniseringsproblemer

21. Selective broadcasting

22. Avbruddsdrevne modeller • Intterrupt handler og Interrrupt servicerutine • Brukes i sanntidssystemer • Eneste som garanterer responstid • Kan være komplisert å programmere og validere. • Mangel på avbruddsmuligheter

23. Avbruddsdreven kontroll

24. Modulær dekomponering • Når vi er ferdig med strukturell arkitektur • Objektorientert modell • Dataflyt-modell

25. Objektmodeller • Dele inn systemet i objekter som er løst koblet via veldefinerte grensesnitt • Objekter bruker tjenester fra andre objekter • UML-notasjon • Tredelte bokser • Stiplede piler viser tjenestebruk • Fordeler • Løs kobling gir frihet til endringer i objektimplementeringen • Objektene svarer til ting, personer og begreper i virkelighetens verden • Samme objekt kan brukes i forskjellige systemer • Begrensninger • Mange interaksjoner å vurdere ved endret grensesnitt • Hårete begreper kan være vanskelige.

26. Fakturabehandlingssystem

27. Dataflytmodeller • Behandlingsprosesser transformerer data • Data som kommer inn ender til slutt som utdata • Pipes and filters • Batch-modeller • Brukes når store mengder data konverteres til store mengder rapporter i en behandling

28. Invoice processing system

29. Fordeler og ulemper med dataflytmodellen • Støtter ombruk av transformasjoner • Intuitivt - ligner på eget arbeid • Lett å legge inn nye transformasjoner • Kan lett utformes som parallelt eller sekvensielt system • Setter krav til felles standard for dataformater • Vanskelig å bruke på interaktive systemer. • Musklikk • Skjermbilder

30. Arkitektur spesielt tilpasset anvendelsesområdet • Kompilator • Referansearkitekturen ISO OSI

31. Compiler model

32. Language processing system

33. OSI reference model Application