Arkitektur

Kapittel 6: Arkitekturdesign
Carl-Fredrik Sørensen
Innhold
1. Arkitektoniske
designbeslutninger
2. Arkitektoniske synsvinkler
3. Arkitekturmønstre/patterns
4. Applikasjonsarkitekturer
–
(web based ++ Chap. 18)
2
Arkitektur: Hvorfor?
• Er dette relevant kunnskap?
• Hvem etterspør slik kunnskap?
• Hvordan kan jeg lære mer?
TDT4240 Programvarearkitektur
3
Programvarearkitektur
• Designprosess for å identifisere
delsystemene som skal danne
løsningen/systemet og
rammeverket for delsystem
kontroll og kommunikasjon er
arkitekturdesign.
• Resultatet av denne
designprosessen er beskrivelse
av programvarearkitekturen.
• Spesifikasjon
• Utvikling
• Validering
• Evolusjon
Arkitekturdesign: når og hva?
• Når?
– I et tidlig stadium av utvikling.
– Gjennomføres ofte parallelt med noen spesifikasjonsaktiviteter.
• Hva?
– Representerer koblingen mellom spesifikasjon- og
designprosess.
– Det innebærer å identifisere viktige systemkomponenter og
deres relasjoner og kommunikasjon.
7
Arkitekturen til et kontrollsystem for
en pakkerobot
8
Arkitektonisk abstraksjon
• Arkitektur i det små omhandler arkitekturen i individuelle
dataprogrammer. På dette nivået er vi opptatt av
hvordan et individuelt program er splittet opp i
komponenter.
• Arkitektur i det store omhandler arkitekturen i komplekse
forretningssystemer (enterprise systems) som inkluderer
andre systemer, programmer og programkomponenter.
Forretningssystemer er distribuert over forskjellige
datamaskiner som kan være eid og forvaltet av
forskjellige bedrifter.
9
Fordeler med eksplisitt arkitektur
• Interessentkommunikasjon
– Arkitekturen kan bli benyttet som et fokus for diskusjon mellom
systeminteressenter.
• Systemanalyse
– Analyse for å fastslå om det er mulig at systemet kan møte sine
ikke-funksjonelle krav.
• Storskala gjenbruk
– Arkitekturen kan bli gjenbrukt over et utvalg av systemer.
– Det kan utvikles arkitekturer for produktlinjer.
10
Boks og linjediagrammer
• Veldig abstrakt – de viser verken naturen til relasjoner
mellom komponenter eller de eksternt synlige
egenskapene til delsystemene.
• Men, nyttig for kommunikasjon med interessenter og for
prosjektplanlegging.
11
Arkitekturen til et kontrollsystem for
en pakkerobot
12
Arkitektur-representasjoner
• Enkle, uformelle blokkdiagrammer som viser entiteter og
relasjoner, er mest benyttet for å dokumentere
programvarearkitekturer.
• Disse blir kritisert fordi de
– mangler semantikk,
– ikke viser typene av relasjoner mellom entiteter
– ikke viser synlige egenskaper til entitetene i arkitekturen.
• Avhengig av hvordan bruken er av arkitekturmodeller.
Kravene til modellsemantikk er avhengig av hvordan
modellene blir brukt.
13
Arkitektroller
•
•
•
•
•
•
•
•
Enterprise arkitekt
Forretningsarkitekt
Informasjonsarkitekt
Applikasjonsarkitekt
Infrastruktur/teknologiarkitekt
Forandringsarkitekt
IAM-arkitekt
Dataarkitekt
15
Bruk av arkitekturmodeller
• Fasilitere diskusjon om systemdesign
– Et høynivås bilde av et system er nyttig som et hjelpemiddel i
kommunikasjon med systeminteressenter og i
prosjektplanlegging.
– Ikke overfylt med detaljer.
– Interessenter kan relatere seg til og forstå et abstrakt bilde av
systemet.
– Interessenter kan diskutere systemet som en helhet uten å bli
forvirret av alle detaljer.
• Dokumentere en allerede designet arkitektur
– Hensikten er å produsere en komplett systemmodell som viser
de forskjellige komponentene i systemet, deres grensesnitt og
deres koblinger.
16
Arkitektoniske designbeslutninger
• Kreativ prosess som er forskjellig avhengig av hvilken
type system som skal utvikles.
• Men, en del generiske beslutninger omfatter alle
designprosesser og påvirker ikke-funksjonelle
karakteristikker til systemet
– Eks.: FEIDE som påloggingsløsning for alle web-baserte NTNUløsninger.
17
Arkitektoniske designbeslutninger –
spørsmål
• Finnes de en generisk applikasjonsarkitektur som kan
benyttes?
• Hvordan vil systemet bli distribuert (servere)?
• Hvilke arkitekturstiler/mønstre er passende?
• Hvilken metodikk vil bli benyttet til å strukturere
systemet?
• Hvordan vil systemet bli oppdelt i
moduler/komponenter/tjenester?
• Hvilken kontrollstrategi bør bli brukt?
• Hvordan evaluere arkitekturdesignet?
• Hvordan bør man dokumentere arkitekturen?
18
Arkitektur og gjenbruk
• Systemer innenfor det samme forretningsdomenet har
ofte lignende/like arkitekturer som reflekterer
domenekonsepter.
– Lønnssystem, banksystem, forsikringssystem, biblioteksystem,
etc.
• Applikasjonsproduktlinjer er bygget rundt en
kjernearkitektur med varianter som tilfredsstiller særskilte
kundekrav.
– ERP, CRM
• Systemarkitekturen kan bli designet rundt en eller flere
arkitekturmønstre eller stiler.
– Disse fanger essensen av en arkitektur og kan bli instansiert på
forskjellige måter.
19
Arkitektur og ikke-funksjonelle
karakteristikker - designvalg
• Performance – Gjør kritiske operasjoner lokalt (på en
datamaskin) og minimaliser kommunikasjon. Bruk store heller
en små finkornede komponenter.
• Security – Bruk en lagdelt arkitektur med de kritiske aktiva I
de innerste lagene
• Safety - Lokaliser sikkerhetskritiske funksjoner i lite antall
delsystemer.
• Availability – Inkluder overflødige komponenter og
mekanismer for feiltoleranse.
• Maintainability – Benytt finkornete, erstattelige komponenter.
• Simplicity – “når du kan velge, velg den løsningen som leder
mot færre komponenter, relasjoner, kodelinjer, dupliseringer”
20
Arkitektoniske synsvinkler –
representasjoner
• Hvilke synsvinkler eller perspektiver er nyttig når man
designer og dokumenter et systems arkitektur?
• Hvilke notasjoner bør bli brukte for å beskrive
arkitekturmodeller?
• Hver arkitekturmodell viser bare en side/perspektiv av
systemet.
– Dekomposisjon i moduler
– Interaksjon mellom kjøretidsprosesser
– Forskjellige måter systemkomponenter er distribuert over et
nettverk
• Behov for å vise mange perspektiver av arkitektur både I
design og dokumentasjon.
21
4 + 1 view model of software architecture
• A logical view, which shows the key abstractions in the system as
objects or object classes – Class Diagrams
• A process view, which shows how, at run-time, the system is
composed of interacting processes - Activity Diagrams
• A development view, which shows how the software is decomposed
for development – Objects; Sequence Diagrams
• A physical view, which shows the system hardware and how
software components are distributed across the processors in the
system (Boxes – Arrows)
• Related using use cases or scenarios (+1)
22
Mer om arkitekturdesign
Carl-Fredrik Sørensen
Archimate
motiv ation Oppgav e 1a
Improve Portfolio and Claims
Management
-Provide personal assistance to
each customer
++
Systems should be
customer-facing
Provide support for online
portfolio and claims
management
+
-- Additional personnel cost
should be kept limited
Provide online portfolio
information
Provide online claim
information
Provide online claim
information
technology Oppgav e 4b
Q-Claim
ODBC Client
DMBS
Data Access
SOAP/XML Client
Application
Container
Application Server
Content Repository
Internet Web Server
Integration Server
Application Access
Application Hosting
Internet Web
Hosting
Virtual Machine
Hypervisor A
Management
Application
Programming
Interface
Hosting
Management
Web Server
Directory Structure
Virtual Hosting
Arkitekturmønstre/
Architectural patterns
• Metode for å representere, dele og gjenbruke kunnskap.
• Et pattern er en stilisert beskrivelse av god designpraksis
som har blitt utprøvd og testet I forskjellige miljøer.
• Patterns bør inkludere informasjon om når de er og ikke er
nyttige.
• Patterns kan bli representert vha tabeller og grafiske
beskrivelser.
•
•
•
•
•
MVC
Layered
Repository
Client-server
Pipe and filter
The Model-View-Controller (MVC) pattern
Name
MVC (Model-View-Controller)
Description
Separates presentation and interaction from the system data. The system is
structured into three logical components that interact with each other. The
Model component manages the system data and associated operations on
that data. The View component defines and manages how the data is
presented to the user. The Controller component manages user interaction
(e.g., key presses, mouse clicks, etc.) and passes these interactions to the
View and the Model. See Figure 6.3.
Example
Figure 6.4 shows the architecture of a web-based application system
organized using the MVC pattern.
When used
Used when there are multiple ways to view and interact with data. Also used
when the future requirements for interaction and presentation of data are
unknown.
Advantages
Allows the data to change independently of its representation and vice versa.
Supports presentation of the same data in different ways with changes made
in one representation shown in all of them.
Disadvantages
Can involve additional code and code complexity when the data model and
interactions are simple.
27
The organization of the Model-ViewController
Java SWING
PHP
.NET
Ruby on Rails
osv
28
Web application architecture using the
MVC pattern
29
Lagdelt arkitektur
• Benyttes til å modeller grensesnitt mellom delsystemer.
• Organiserer systemet i et sett av lag (eller abstrakte
maskiner) som hver enkelt tilbyr et sett av tjenester.
• Supporter inkrementell utvikling av delsystemer i
forskjellige lag. Når et grensesnitt i et lag endres, så er
bare tilstøtende lag som blir påvirket.
• Det er imidlertid ofte kunstig å strukturere systemer på
denne måten.
30
The Layered architecture pattern
Name
Layered architecture
Description
Organizes the system into layers with related functionality
associated with each layer. A layer provides services to the layer
above it so the lowest-level layers represent core services that
are likely to be used throughout the system. See Figure 6.6.
A layered model of a system for sharing copyright documents
held in different libraries, as shown in Figure 6.7.
Used when building new facilities on top of existing systems;
when the development is spread across several teams with each
team responsibility for a layer of functionality; when there is a
requirement for multi-level security.
Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the
system.
In practice, providing a clean separation between layers is often
difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately
below it. Performance can be a problem because of multiple
levels of interpretation of a service request as it is processed at
each layer.
Example
When used
Advantages
Disadvantages
31
A generic layered architecture
hvert lag tilbyr tjenester til laget over og bruker
tjenestene som tilbys av den underliggende lag
32
The architecture of the MHC-PMS
33
Organisasjon og samfunn
Gjester, potensielle
studenter, offentlig
forvaltning, bedrifter,
samarbeidspartnere,
NFR, alumni etc.
Ansatt
Student
Andre
Brukertjenester
Virksomhet
Styrings- og ledelsesprosesser
Forskning
Utdanning
Kompetanse
Nyskaping
Arbeidsflyt
Aksesskontroll
Forskningsadm
IKT og
bibliotek
Studieadm
HMS
Økonomi
FDV
HR
Formidling
Forretningstjenester
Applikasjon
HR
LMS
Studentsystem
Økonomi
Datatjenester
Strategi,
Rammebetingelser,
Behov,
Sikkerhet,
Lovgivning,
Protokoller,
Standarder
Informasjon
Data
Data
Data
Data
Data
Data
Semantikk,
domenemodeller,
fysiske datamodeller
Virksomhetsarkitektur
Pr
in
sip
Eksempelvis… psk
iss
Virksomhet & Verdiskaping
• Utdanning
• Forskning
• Innovasjon
• Etc…
Funksjoner & Prosesser
• Undervisning
• Studieadministrasjon
• Publisering
• FoU administrasjon
• Etc…
Systemer & Rammeverk
• Økonomisystem
• HR/Personalsystem
• Fagsystemer
• Etc…
Teknologi & Infrastruktur
• Ne verk
• Servere
• Databaser
• Mellomvare
• Etc…
e
Oppsummering
• En programvarearkitektur er en beskrivelse av hvordan
et programvaresystem er organisert.
• Beslutninger om arkitekturdesign inkludere beslutninger
om applikasjonstype, systemdistribusjon og
arkitekturstiler som skal benyttes.
• Arkitekturer kan bli dokumentert på mange forskjellige
måter eller perspektiver, f.eks. conceptual, logical,
process, and development view.
• Arkitekturmønstre er en metode for å gjenbruke
kunnskap om generiske systemarkitekturer. De beskriver
arkitekturen, når de kan bli brukt samt fordeler og
ulemper med bruk.
36
Repository arkitektur
• Delsystemer må utveksle data. Dette kan bli gjort på to
måter:
– Delte data blir holdt i en sentral database eller repository og kan
bli aksessert av alle delsystemene;;
– Hvert delsystem vedlikeholder sin egen database og sender data
eksplisitt til andre delsystemer..
• Når store volum av data skal deles, så er
repositorymodellen den mest vanlige siden denne er en
effektiv mekanisme for deling av data.
37
The Repository pattern
Name
Repository
Description
All data in a system is managed in a central repository that is
accessible to all system components. Components do not
interact directly, only through the repository.
Figure 6.9 is an example of an IDE where the components use
a repository of system design information. Each software tool
generates information which is then available for use by other
tools.
You should use this pattern when you have a system in which
large volumes of information are generated that has to be
stored for a long time. You may also use it in data-driven
systems where the inclusion of data in the repository triggers
an action or tool.
Components can be independent—they do not need to know
of the existence of other components. Changes made by one
component can be propagated to all components. All data can
be managed consistently (e.g., backups done at the same
time) as it is all in one place.
The repository is a single point of failure so problems in the
repository affect the whole system. May be inefficiencies in
organizing all communication through the repository.
Distributing the repository across several computers may be
difficult.
Example
When used
Advantages
Disadvantages
38
A repository architecture for an IDE
39
Klient-tjener arkitektur
• Distribuert systemmodell som viser hvordan data og
prosessering er distribuert over et sett av komponenter.
• Sett av “stand-alone” tjenere som tilbyr spesifikke tjenester som
f.eks. printing, data management, etc.
• Sett av klienter som kaller på disse tjenestene.
• Nettverk som tillater klienter å aksessere tjenere.
40
The Client–server pattern
Name
Client-server
Description
In a client–server architecture, the functionality of the system is
organized into services, with each service delivered from a
separate server. Clients are users of these services and access
servers to make use of them.
Figure 6.11 is an example of a film and video/DVD library organized
as a client–server system.
Used when data in a shared database has to be accessed from a
range of locations. Because servers can be replicated, may also be
used when the load on a system is variable.
The principal advantage of this model is that servers can be
distributed across a network. General functionality (e.g., a printing
service) can be available to all clients and does not need to be
implemented by all services.
Each service is a single point of failure so susceptible to denial of
service attacks or server failure. Performance may be unpredictable
because it depends on the network as well as the system. May be
management problems if servers are owned by different
organizations.
Example
When used
Advantages
Disadvantages
41
“Pipe and filter” arkitektur
• Funksjonelle transformasjoner prosesserer sin input til å produser
en output.
• Lignende som pipe and filter modell (UNIX shell).
• Varianter av denne metoden er veldig vanlig. Når transformasjoner
kan utføres sekvensielt så er dette en modell som er veldig mye
brukt i dataprosesseringssystemer.
• Lite passende i interaktive systemer.
42
The pipe and filter pattern
Name
Pipe and filter
Description
The processing of the data in a system is organized so that each
processing component (filter) is discrete and carries out one type of
data transformation. The data flows (as in a pipe) from one component
to another for processing.
Figure 6.13 is an example of a pipe and filter system used for
processing invoices.
Commonly used in data processing applications (both batch- and
transaction-based) where inputs are processed in separate stages to
generate related outputs.
Easy to understand and supports transformation reuse. Workflow style
matches the structure of many business processes. Evolution by
adding transformations is straightforward. Can be implemented as
either a sequential or concurrent system.
The format for data transfer has to be agreed upon between
communicating transformations. Each transformation must parse its
input and unparse its output to the agreed form. This increases system
overhead and may mean that it is impossible to reuse functional
transformations that use incompatible data structures.
Example
When used
Advantages
Disadvantages
43
Applikasjonsarkitekturer
• Applikasjonssystemer er designet for å møte et
organisatorisk behov.
• Siden organisasjoner har mye til felles, så tenderer
applikasjonssystemene til å en felles
applikasjonsarkitektur som reflekterer
applikasjonskravene.
– F.eks. Telekommunikasjon, økonomi, arkiv, bibliotek
• En generisk applikasjonsarkitektur er en arkitektur for en
type programvaresystemer som kan bli konfigurert og
tilpasset til å lage et system som møter spesifikke krav.
44
Bruk av applikasjonsarkitekturer
•
•
•
•
•
Som start for arkitekturdesign.
Som en sjekkliste for design.
Som en måte organiser arbeidet til utviklingsteamet.
Som en metode for å vurdere komponenter for gjenbruk.
Som et vokabular for å snakke om applikasjonstyper.
45
Eksempler på applikasjonstyper
• Dataprosesseringsapplikasjoner
– Data driven applications that process data in batches without
explicit user intervention during the processing.
• Transaksjonsprosesseringsapplikasjoner
– Data-centred applications that process user requests and update
information in a system database.
• Hendelsesprosesseringssystemer
– Applications where system actions depend on interpreting
events from the system’s environment.
• Språkprosesseringssystemer
– Applications where the users’ intentions are specified in a formal
language that is processed and interpreted by the system.
46
Transaction processing applications
• Data-centred applications that process user requests
and update information in a system database.
– E-commerce systems
– Reservation systems
– ATM
Pipe and filter
Input
processing
output
47
Informasjonssystem-arkitektur
• Informasjonssystemer har en generisk arkitektur som
kan bli organisert som en lagdelt arkitektur.
• Disse er transaksjonsbaserte systemer siden interaksjon
generelt involverer databasetransaksjoner.
• Typiske lag:
–
–
–
–
Brukergrensesnitt
Brukerkommunikasjon
Informasjonsgjenfinning
Systemdatabase
48
Layered information system architecture
49
The architecture of the MHC-PMS
50
Web-baserte informasjonssystemer
• Informasjons- og ressurshåndteringssystemer er i dag
webbaserte systemer hvor brukergrensesnittet er
implementert vha. en web-browser.
• eHandling:
– Amazon, komplett.no, etc.
– Applikasjonsspesifikt lag inkluderer tilleggsfunksjonalitet som håndterer ‘handlevogn’ hvor
brukere kan plassere ønskede produkter som
separate transaksjoner, og så betale for alle i en
enkel transaksjon.
51
Server implementering
• Slike systemer er ofte implementert som et flerlags
klient/tjener arkitektur.
– Web server er ansvarlig for all brukerkommunikasjon,
brukergrensesnittet er en webleser;
– Applikasjonsserveren er ansvarlig for å implementere
applikasjonsspesifikk logikk i tillegg til informasjonslagring og
gjenfinning;
– Databaseserveren flytter informasjon til og fra databasen og
håndterer transaksjoner.
52
Organisasjon og samfunn
Gjester, potensielle
studenter, offentlig
forvaltning, bedrifter,
samarbeidspartnere,
NFR, alumni etc.
Ansatt
Student
Andre
Brukertjenester
Virksomhet
Styrings- og ledelsesprosesser
Forskning
Utdanning
Kompetanse
Nyskaping
Arbeidsflyt
Aksesskontroll
Forskningsadm
IKT og
bibliotek
Studieadm
HMS
Økonomi
FDV
HR
Formidling
Forretningstjenester
Applikasjon
HR
LMS
Studentsystem
Økonomi
Datatjenester
Strategi,
Rammebetingelser,
Behov,
Sikkerhet,
Lovgivning,
Protokoller,
Standarder
Informasjon
Data
Data
Data
Data
Data
Data
Semantikk,
domenemodeller,
fysiske datamodeller
Språkprosesseringssystemer
• Accept a natural or artificial language as input and generate
some other representation of that language.
• May include an interpreter to act on the instructions in the
language that is being processed.
• Used in situations where the easiest way to solve a
problem is to describe an algorithm or describe the system
data
– Meta-case tools process tool descriptions, method rules, etc
and generate tools.
• XML, REST/SOAP/JSON
54
The architecture of a language
processing system
55
Compiler components
• A lexical analyzer, which takes input language tokens
and converts them to an internal form.
• A symbol table, which holds information about the names
of entities (variables, class names, object names, etc.)
used in the text that is being translated.
• A syntax analyzer, which checks the syntax of the
language being translated.
• A syntax tree, which is an internal structure representing
the program being compiled.
56
Compiler components
• A semantic analyzer that uses information from the
syntax tree and the symbol table to check the semantic
correctness of the input language text.
• A code generator that ‘walks’ the syntax tree and
generates abstract machine code.
57
Language processing systems
• Applications where the users’ intentions are specified in
a formal language that is processed and interpreted by
the system.
– Compilers
– Command interpreters
XML
Database
English
Norsk
58
58
A repository architecture for a language
processing system
59
Konklusjon
• Modeller av applikasjonssystemarkitekturer hjelper oss å
forstå og sammenligne applikasjoner, validere
applikasjonssystemdesign og vurdere stor-skala
komponenter for gjenbruk.
• Transaksjonsprosesseringssystemer er interaktive
systemer som tillater informasjon i en database til å bli
aksessert utenfra og modifisert av mange brukere.
• Språkprosesseringssystemer blir benyttet til å oversette
tekst fra et språk til et annet og til å gjennomføre
instruksjoner spesifisert i input-språket. Disse systemene
inkluderer en oversetter og en abstrakt maskin som
eksekverer det genererte språket.
60
Konklusjon
• Google
–
–
–
–
–
«model view control» gives 90.700 results
«pipe and filter architecture» gives 27.000 results
«layered architecture» 362.000
«repository architecture» 47.400
«client server architecture» 1.130.000
• Video: a song about MVC
http://www.youtube.com/watch?v=YYvOGPMLVDo
61
What are the advantage of explicitly
designing and documenting a software
architecture?
• It improves stakeholder communications
• It encourages a detailed analysis of the system with
respect to its quality attributes
• It helps with large-scale reuse.
62
What are the two ways in which an
architectural model of a system may be
used?
• As a means of facilitating discussion about the most
appropriate architecture for a system.
• As a means of documenting the architecture of an
existing or an intended system.
63
List 5 fundamental questions that should
be addressed in architectural design?
• Is there a generic application architecture that can be
used?
• How will the system be distributed?
• What architectural style or patterns are appropriate?
• How should the system be structured?
• What control strategy should be used?
64
What are the fundamental architectural
views proposed in Krutchen’s 4+ 1
model?
• A logical view that shows the key abstractions of the
system.
• A process view that shows the interacting processes in
the system
• A development view that shows how the system is
decomposed for development
• A physical view that shows the distribution of software on
the system hardware
• Use Cases (+1)
65
What is an architectural pattern?
• A stylized abstract description of good practice in
architectural design that has been tried and tested in
different systems and environments. The pattern should
include information on when it is and is not appropriate
to use that architectural design.
66