Transcript ARHITEKTURA PROGRAMSKE POTPORE (engl. )

ARHITEKTURA PROGRAMSKE
POTPORE
(engl. Software Architecture)
1
Prednosti definiranja arhitekture:
•
Smanjuje cijenu oblikovanja, razvoja i održavanja
programskog produkta.
•
Omogućuje ponovnu uporabu rješenja (engl. reuse).
•
Poboljšava razumljivost.
•
Poboljšava kvalitetu produkta.
•
Razjašnjava zahtjeve.
•
Omogućuje donošenje temeljnih inženjerskih
odluka.
•
Omogućuje ranu analizu i uočavanje pogrešaka u
oblikovanju.
2
3
4
Što je arhitektura ?
Arhitektura programske potpore je struktura ili
strukture sustava koji sadrži elemente, njihova izvana
vidljiva obilježja i odnose između njih.
Koje vrste struktura ?
• Moduli (pokazuju statičku kompoziciju/dekompoziciju sustava).
• Dinamičku kompoziciju, t.j. komponente u izvođenju (engl.
runtime).
• Alocirane elemente (npr. datoteke).
• …
Svaka vrst strukture čini jedan arhitekturni pogled.
Opis arhitekture sadrži višestruke poglede.
5
Primjer pogleda: Komponente_i_Konektori
• Dekompozicija sustava u komponente.
Komponente:
osnovna jedinica izračunavanja i pohrane
podataka (npr. klijent-uslužitelj)
Tipično hijerarhijska dekompozicija.
• Konektori:
Apstrakcija interakcije između komponenata (npr. poziv
procedure).
• Uporaba stila arhitekture:
Oblikovanje kompozicije komponenata i konektora.
Respektirati ograničenja i invarijante.
6
Stilovi (familije) arhitektura programske potpore
Skupovi srodnih arhitektura. U jednom programskom
produktu može postojati kombinacija više stilova.
Opisuju se:
Rječnikom (tipovima komponenata i konektora).
Topološkim ograničenjima koja moraju zadovoljiti svi članovi
familije (stila).
Primjeri stilova:
•
protok podataka (engl. data-flow)
•
objektno usmjereni stil
•
repozitorij podataka
•
arhitektura upravljana događajima
•
…
7
Arhitektura programske potpore u kontekstu:
1950 – programiranje na bilo koji način
1960 – subrutine i posebno prevođenje dijelova
(engl. programming in the small).
1970 – apstraktni tipovi podataka, objekti, skrivanje
informacije (engl. programming in the large).
1980 – razvojne okoline, “cjevovodi i filtri”
1990 – objektno usmjereni obrasci (engl. patterns),
integrirana razvojna okruženja.
2000 – arhitektura programske potpore, jezici za oblikovanje (npr.
UML) i metode oblikovanja (npr. modelno oblikovanje
arhitekture – engl. model driven architecture MDA).
2000 + stalna potreba za oblikovanjem stabilne arhitekture (nove
značajke mogu jednostavno dodavati uz vrlo male izmjene).
Time se osigurava veća pouzdanost i mogućnost
jednostavnog održavanja sustava.
8
ARHITEKTURA PROTOKA PODATAKA
(engl. data-flow)
9
Općeniti modeli izračunavanja u programskom produktu:
Protok podataka (engl. data flow)
• Dominatno pitanje je kako se podaci pomiči kroz kolekciju
modula za izračunavanje.
• Kako se pomiču podaci tako se aktivira upravljanje.
Upravljački tok (engl. control flow)
VisualBasic, C, C++, JAVA, …:
• Dominantno pitanje je kako se središte upravljanja pomiče kroz
program ili sustav.
• Podaci mogu slijediti upravljački tok, ali taj slijed ne određuje
arhitekturu sustava.
• Rasuđivanje u sustavu je primarno fokusirano na slijed
izračunavanja.
10
Primjer arhitekture protoka podataka:
11
Primjer arhitekture protoka podataka:
12
Intuitivna semantika
• (Često bez stanja) procesni elementi – aktori izvode
izračunavanje.
• Neograničeni FIFO (first-in-first-out) međuspremnik
sudjeluje u komunikaciji preko sekvencija znački
(engl, tokens):
• cijeli brojevi, float
• matrice cijelih brojeva, float
• skup slikovnih elemenata (piksela)
• ...
• Određenost:
Na jedinstvene ulazne sekvence generiraju se jedinstvene
izlazne sekvence.
13
14
Obilježja sustava temeljenog na protoku podataka:
• Raspoloživost podataka upravlja izračunavanjem.
• Struktura arhitekture je određena redoslijedom
pomicanja podataka od komponente do komponente
(t.j. od aktora do aktora).
• Oblik strukture je eksplicitan.
• To je jedini način komunikacije između komponenata u
sustavu.
Varijacije glavne ideje:
• Izvedba upravljanja ( npr. “pull” ili “push”).
• Stupanj paralelizma između procesa.
• Topologija mreže.
15
Najpoznatiji primjer arhitekture sustava temeljenog na
protoku podataka
16
Njvažnija komponenta LabView sustava je prevoditelj
(compiler) za G dataflow programming language.
G je programski jezik zasnovan na paradigmi protoka podataka,
dobro prihvaćen zbog intuitivne grafičke reprezentacije i definirane
sintakse.
G je homogen, dinamičan i višedimenzijski:
• Homogen - G aktori proizvode i konzumiraju pojedinačne značke na
svakom luku grafa.
• Dinamičan - G sadrži konstrukcije koje dopuštaju da se dijelovi
grafa izvode uvjetno, ovisno o ulaznim podacima.
• Višedimenzijski - G podržava višedimenzijske nizove (polja).
Konstruktori petlje u G jeziku mogu kombinirati pojedinačne
značke u nizove znački, ili razdvajati nizove u pojedinačne značke.
17
18
19
Application Features of LabVIEW 7.1
• Design
– Signal and Image Processing
– Embedded System Programming
• (PC, DSP, FPGA, Microcontroller)
– Simulation and Prototyping
– And more…
• Control
– Automatic Controls and Dynamic
Systems
– Mechatronics and Robotics
– And more…
• Measurements
– Circuits and Electronics
– Measurements and Instrumentation
– And more…
20
Neki podstilovi arhitekture protoka podataka
• Skupno-sekvencijski (engl. batch – sequential)
• Cjevovodi i filtri (engl. pipes and filters)
• …
21
Skupno sekvencijski stil
22
Obilježja skupnog sekvencijskog sustava:
• Svaki procesni korak je nezavisan program.
• Svaki procesni korak (program) izvodi se do potpunog završetka, prije
prijelaza na slijedeći korak.
• Podaci se između koraka prenose u cijelosti.
Tipične primjene:
• Poslovne: Diskretne transakcije unaprijed određenog tipa i koje se
pojavljuju u periodičnim intervalima, periodični ispisi i dopune, obrada
koja nije pod strogim vremenskim ograničenjima, skupna obrada (npr:
obračun plaća).
• Transformacijska analiza podataka: Sakupljanje i analiza sirovih
podataka u koračnom i skupnom modu (npr. crna kutija u avionu).
23
Primjeri skupne sekvencijske arhitekture:
Kompilatori (prevodtelji)
• Početno mehanizam preslikavanja izvornog koda više razine u
objektni kod.
• Rani kompilatori su nastali kao skupni sekvencijski sustavi
(leksička analiza, parsiranje, semantička analiza, generiranje koda).
Computer Aided Software Engineering (CASE)
• Početno okolina za pisanje i kompiliranje.
• Rani alati su bili nezavisni programi.
• Kasniji alati međusobno dijele samo datoteke.
• Moderni alati uključuju oblikovanje, dokumentaciju, upravljanje
konfiguracijama i inačicama te generiranje koda.
24
CJEVOVODI I FILTRI (engl. pipes-and-filters)
Magnetska vrpca u skupnom sekvencijskom sustavu
poprima oblik jezika i konstruktora u operacijskom
sustavu.
25
Obilježja (čistih) filtara
Čita niz podataka (engl. stream) na ulazu i generira niz podataka na
izlazu (tradicijski byte usmjereno).
Transformira niz u niz
• Obogaćuje podatke dodajući nove informacije.
• Rafinira podatke izbacujući nerelevantne informacije.
• Transformira podatke promjenom njihovog značenja.
Inkrementalno transformira podatke
• Podaci se obrađuju po dolasku (ne prvo sakupe pa obrade).
Filtri su nezavisni entiteti
• Nema konteksta u obradi niza.
• Nema čuvanja stanja između pojedinih instanciranja sustava.
• Nema znanja o neposrednim susjedima (prethodnicima i
sjedbenicima).
26
• Ispravnost izlaza filtra ne ovisi o redoslijedu povezivanja u mreži.
Obilježja (čistih) cjevovoda
• Prenose podatke od izlaza filtra do ulaza filtra
(ulazno/izlazne naprave ili datoteke).
• Podaci se prenose u jednom smjeru. Dozvoljava se samo
eventualno upravljanje u obrnutom smjeru.
• Cjevovodi formiraju graf prijenosa podataka.
Rad sustava cjevovoda i filtera
• Akcija sustava je određena dobavom podataka.
• Cjevovodi i filtri obavljaju prijenos i obradu podataka
nedeterministički dok ne nestane podataka ili dok nije više
moguće izračunavanje (obrada).
27
Primjer cjevovoda i filtara: UNIX
UNIX philosophy (original statements)
• A program should do one thing well.
• Complex problems should be solved by
combining simple programs whenever
possible.
• Write as little new code as possible leveraging
existing code and utilities in order to solve a
problem.
• The internal software architecture is well
documented and adheres to standards.
28
Primjer cjevovoda i filtara: UNIX
UNIX procesi koji preslikavaju stdin u stdout (ili drugi izvori i
ponori) nazivaju se filtrima.
Često konzumiraju sve ulazne podatke prije generiranja izlaza.
Time narušavaju osnovnu pretpostavku o filtrima (npr. sort, grep,
awk).
UNIX cjevovodi tretiraju datoteke (i druge entitete) kao filtre te kao
izvore i ponore podataka. Datoteke (i mnogi drugi entiteti) su
pasivni te nije moguće načiniti povezivanje po volji.
UNIX pretpostavlja da cjevovodi prenose ASCII znakove. To je
povoljno jer je moguće povezivanje bez ograničenja. To je
nepovoljno jer se sve mora kodirati u ASCII i dekodirati.
29
Usporedba skupno sekvencijske arhitekture s
cjevovodima i filtrima
Skupno sekvencijska
Cjevovodi i filtri
Gruba zrnatost
Fina zrnatost
Visoka latencija
Rezultati s početkom obrade
Vanjski pristup ulazima
Lokalizirani ulazi
Nema paralelizma
Moguć paralelizam
Nema interaktivnosti
Interaktivnost moguća (ali
nespretno)
30
Razlozi izbora arhitekture protoka podataka:
• Zadatkom dominira dobavljivost podataka.
• Podaci se mogu prediktivno prenositi od procesa do
procesa.
• Cjevovodi i filtri su dobar izbor u mnogim primjenama
protoka podataka jer:
• Dozvoljavaju ponovnu uporabu i rekonfiguracija filtara.
• Rasuđivanje o cijelom sustavu je olakšano.
• Reducira se ispitivanje (testiranje) sustava.
• Može se ostvariti inkrementalna i paralelna obrada.
• Arhitektura protoka podataka može unositi smanjene
performanse (ovisi o mnogim faktorima).
31
MODULARIZACIJA I
OBJEKTNO USMJERENA ARHITEKTURA
32
Problemi u oblikovanju programske potpore (1970)
Ranjivost na globalne (ili široko dijeljene) varijable
Klasični programski jezici kreiraju dijeljenje (blokovske
strukture, globalne varijable).
Nenamjerno otkrivanje interne strukture
Točan položaj polja, linearna ili povezana reprezentacija.
Vidljiva reprezentacija može se manipulirati na neželjen način.
Prodiranje odluka o oblikovanju
Jedna promjena utječe na mnoge module.
Disperzija koda koji se odnosi na jednu odluku
Vrlo je teško utvrditi što je sve pogođeno promjenom.
Familije odluka o oblikovanju koje su povezane
Povezane definicije de-lokaliziraju odluke (definicije bi
trebale biti lokalizirane - na jednom mjestu)
33
Povijest modularizacije (u orahovoj ljusci):
Glavni program i subrutine
Dekompozicija u procesne korake s jednom niti izvođenja.
Funkcijski moduli
Agregacija (skupljanje) procesnih koraka u module.
Apstraktni tipovi podataka (ADT Abstract Data Types)
Zatvaranje podataka i operacija, skrivanje predstavljanja.
Objekti i Objektno usmjerena arhitektura
Procedure (metode) se povezuju dinamički, polimorfizam,
nasljeđivanje.
Komponente i Oblikovanje zasnovano na komponentama
(CBD Component based design)
Višestruka sučelja, posrednici, binarna kompatibilnost.
34
35
Glavni program i subrutine (obilježja)
Hijerarhijska dekompozicija
Temeljena na odnosu definicija – uporaba. Pozivi procedura
kao interakcijski mehanizam.
Jedna nit izvođenja
Potpomognuto izravno programskim jezikom.
Hijerarhijsko rasuđivanje
Korektno izvođenje ovisi o korektnom izvođenju subrutine
koja se poziva.
Implicitna struktura podsustava
Subrutine su tipično skupljene u module.
36
Stalno prisutna tema: Kriteriji za modularizaciju
Što je modul ?
•
Najčešći pogled: komad koda (ograničeno gledanje).
•
Jedinica kompilacije koja uključuje deklaracije i sučelje.
•
D.Parnas, Comm. ACM, 1972. : “Jedinica posla.”
Zašto uopće modularizirati sustav ?
•
Upravljanje, podijeli i vladaj.
•
Evolucija, promjene jednog dijela ne utječu na druge
dijelove.
•
Razumijevanje, sustav se sastoji od razumno složenih
dijelova.
37
Apstraktni tipovi podataka
Krajem 1960 dobri programeri su imali intuiciju:
“Ako dobro definiraš strukture podataka ostatak
programa je mnogo jednostavniji.”
1970: skrivanje informacija i apstraktni tipovi podataka
(ADT – abstract data types):
Definicija: ADT je skup dobro definiranih elemenata i
skup dobro definiranih operacija na tim elementima.
38
Primjer ADT: 'List'
List je sekvencija 0 ili više objekata danog tipa.
Neka su operacije: insert(x, p, L); (ubaci element x, na poziciju p, u listu
L), first(L); locate(x,L); retrieve(p, L) delete(p, L) next(p,L)
Program koji eliminira duplikate u listi L:
p = first(L);
while (p != end of List) {
q = next(p,L);
while(q != end of the List) {
if (same(retrieve(p,L),retrieve(q,L))
delete(q,L);
else
q = next(q,L)
}
p = next(p, L);
}
Prednost: kod je nezavisan o strukturi podataka i može se uporabiti u
bilo kojoj implementaciji liste (npr. od niza do povezane liste). Promjena
39
implementacije ne utječe na ovaj kod.
Object-Oriented Software Engineering
T.C.Lethbridge, R.Laganiere
2005
40
2.1 What is Object Orientation? (vs. Procedural)
Procedural paradigm:
(functions, routines)
• Software is organized around the notion of procedures
• Procedural abstraction
—Works as long as the data is simple
• Adding data abstractions
—Groups together the pieces of data that describe
some entity and manipulate as unit.
—Helps reduce the system’s complexity.
- Such as Records and structures (but different records
require different procedures).
Object oriented paradigm:
• Organizing procedural abstractions in the context of data
abstractions
41
Object Oriented paradigm
An approach to the solution of problems in which all
computations are performed in the context of objects.
(programming constructs)
• The objects are instances of classes, which:
—are data abstractions
—contain procedural abstractions that operate on the
objects
• A running program can be seen as a collection of objects
collaborating to perform a given task
42
A View of the Two paradigms ( e.g. banking system)
Procedures manipulate different
types of data
Procedures are bundled
with data
43
Classes
A class:
• A unit of abstraction in an object oriented (OO) program
• Represents similar objects
—Its instances
• A kind of software module
—Describes its instances’ structure (properties)
—Contains methods to implement their behaviour
44
Razlika: instancija – objekt
Nema razlike, odnosi se na istu stvar.
Razlika je nastala u korištenju prirodnog jezika.
Npr. kćer – djevojka
Imala je sedam kćeri (ne djevojaka).
Vidio sam prekrasnu djevojku (ne kćer).
45
Methods, Operations and Polymorphism
Method
• A procedural abstraction used to implement the
behaviour of a class.
• Several different classes can have methods with the
same name
—They implement the same abstract operation in ways
suitable to each class
—E.g. calculating area in a rectangle is done
differently from in a circle (even though the method
name is the same).
46
Polymorphism
A property of object oriented software by which an
abstract operation may be performed in different ways in
different classes.
• Requires that there be multiple methods of the same
name
• The choice of which one to execute depends on the
object that is in a variable
• Reduces the need for programmers to code many ifelse or switch statements
47
2.5 Organizing Classes into Inheritance
(nasljeđivanje)
Hierarchies
Superclasses (in C++ “base class”)
• Contain features common to a set of subclasses
Inheritance hierarchies
• Show the relationships among superclasses and
subclasses
Inheritance
• The implicit possession by all subclasses of features
defined in its superclasses
48
An Example Inheritance Hierarchy
(UML notation)
Inheritance
• The implicit possession by all subclasses of features
defined in its superclasses
49
The Isa Rule
Always check generalizations to ensure they obey the isa
rule
• “A checking account is an account”
• “A village is a municipality”
Should ‘Province’ be a subclass of ‘Country’?
• No, it violates the isa rule
—“A province is a country” is invalid!
50
Overriding (ne obaziranje)
A method would be inherited, but a subclass contains a
new version instead
• For restriction
—E.g. scale(x,y) would not work in Circle (it
would become an Elipse)
• For extension
—E.g. SavingsAccount might charge an extra fee
following every debit
• For optimization
—E.g. The getPerimeterLength method in
Circle is much simpler than the one in Ellipse
51
Dynamic binding (1) (dinamičko povezivanje)
Occurs when decision about which method to run can
only be made at run time
• Needed when:
—A variable in an OO program is declared to have a
superclass as its type, and
—There is more than one possible polymorphic
method that could be run among the type of the
variable and its subclasses
52
Key Concepts
Abstraction
• Object -> something in the world
• Class -> objects
• Superclass -> subclasses
• Operation -> methods
• Attributes and associations -> instance variables
Modularity
• Code can be constructed entirely of classes (no global vars ?)
Encapsulation
• Details can be hidden in classes
• This gives rise to information hiding:
—Programmers do not need to know all the details of a class
53
OO Programming languages
History
• The first object oriented programming language was Simula-67
—designed to allow programmers to write simulation programs
• In the early 1980’s, Smalltalk was developed at Xerox PARC
—New syntax, large open-source library of reusable code,
bytecode, platform independence, garbage collection.
• late 1980’s, C++ was developed by B. Stroustrup,
—Recognized the advantages of OO but also recognized that there
were tremendous numbers of C programmers
• In 1991, engineers at Sun Microsystems started a project to design a
language that could be used in consumer ‘smart devices’: Oak
—When the Internet gained popularity, Sun saw an opportunity to
exploit the technology.
—The new language, renamed Java, was formally presented in
1995 at the SunWorld ’95 conference.
54
OBJEKTNO USMJERENA ARHITEKTURA - 2
Stilističke varijacije:
•
Raspodijeljena arhitektura, klijent – poslužitelj,
posrednička i uslužna arhitektura
•
Oblikovanje zasnovano na komponentama
Izvori:
T.C.Lethbridge, R.Laganiere: Object-Orientd Software Engineering
55
3.4 Distributed Architecture (Client – Server)
A distributed system is a system in which:
• computations are performed by separate programs
• … normally running on separate pieces of hardware
• … that co-operate to perform the task of the system.
Server:
• A program that provides a service for other programs
that connect to it using a communication channel
Client
• A program that accesses a server (or several servers) to
obtain services
• A server may be accessed by many clients
simultaneously
56
Peer-to-peer Architecture (P2P)
A type of distributed architecture in which each station has
equivalent capabilities and responsibilities (both servers and
clients). The P2P network itself relies on computing power at the
ends of a connection rather than from within the network itself.
P2P is often mistakenly used as a term (Affinity Communities) to
describe one user linking with another user to transfer information
and files (MP3s, videos, images, etc.).
P2P network can also mean:
Collaborative Computing - combines the idle or unused CPU
processing power and/or free disk space of many computers in the
network. Collaborative computing is most popular with science and
biotech organizations where intense computer processing is
required. Examples: GRID computing.
A form of P2P networking is Instant Messaging, where software
applications, such as MSN Messenger allow users to chat via text
messages in real-time.
58
Advantages of client-server systems
• The work can be distributed among different machines
• The clients can access the server’s functionality from a
distance
• The client and server can be designed separately
• They can both be simpler
• All the data can be kept centrally at the server
• Conversely, data can be distributed among many
different geographically-distributed clients or servers
• The server can be accessed simultaneously by many
clients
59
Example of client-server systems
• The World Wide Web
• Email
• Network File System
• Transaction Processing System
• Remote Display System
• Communication System
• Database System
60
Thin- versus fat-client systems
Thin-client system (a)
• Client is made as small as possible
• Most of the work is done in the server.
• Client easy to download over the network
Fat-client system (b)
• As much work as possible is delegated to the clients.
• Server can handle more clients
61
Risks when adopting a client-server
approach
• Security
—Security is a big problem with no perfect solutions:
consider the use of encryption, firewalls, ...
• Need for adaptive maintenance
—Ensure that all software is forward and backward
compatible with other versions of clients and servers
62
(naslage ?)
Components and connectors
Why is it called “middleware”?
• It’s right in the middle of a client and a server
• Hides operating system and low-level details
from the application developer
Why do we need/have middleware?
• It makes it easier to write distributed applications
• Takes care of all the networking code and the
messaging
• Leaves you free to focus on writing the
application
mali izresci
The Service-oriented architectural pattern
This architecture organizes an application as a collection
of services that communicates using well-defined
interfaces
• In the context of the Internet, the services are called Web
services
• A web service is an application, accessible through the
Internet, that can be integrated with other services to
form a complete system
• The different components generally communicate with
each other using open standards such as XML.
70
Web services architectural model (incorporate how Web
services are advertised, discovered, selected, and used).
Universal
Description,
Discovery
and
Integration
Web
Services
Description
Language
Simple Object Access Protocol
OBLIKOVANJE ZASNOVANO NAKOMPONENTAMA
(Component Based Design – CBD)
Izvor: A.R. Newton, UC Berkeley
Hard, Still
requires OO
programming
skills
Hard, requires
OO programming
skils
Even harder;
Must meet
needs of many
users
Nije na prodaju !
DEC protocol in VAX
IP = intelektualno vlasništvo
Operating environment
Some Potential Key Technologies
What software technology, or technologies will play
the central role in enabling such a distributed
component architecture ?
• CORBA
• Java and JavaBeans
• Microsoft DCOM (.NET)
(.NET)
ARHITEKTURE PROGRAMSKE POTPORE – 2
• Protok podataka
• Objektno usmjerena arhitektura
• Arhitektura zasnovana na događajima
• Arhitektura repozitorija podataka
• Slojevita arhitektura
• Virtualni strojevi
• Arhitektura u upravljanju procesima
82
ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA
(engl. event based architecture)
( Implicitno pozivanje)
Temeljne značajke:
• Komponente se međusobno ne pozivaju eksplicitno.
• Komponente generiraju signale = događaje.
• Komponente koje objavljuju događaj nemaju informaciju koje će
sve komponente reagirati i kako na događaj.
• Asinkrono rukovanje događajima.
83
ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA
Struktura za
povezivanje
84
ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA
Generiranje
iznimke
(npr. skok
preko
vektora)
85
ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA
Prednosti:
• Omogućuje razdvajanje i autonomiju komponenata.
• Podupire evoluciju i ponovno korištenje.
• Jednostavno se uključuju nove komponente bez utjecaja na
postojeće.
Nedostaci:
• Komponente koje objavljuju događaje nemaju garancije da će
dobiti odziv.
• Komponente koje objavljuju događaje nemaju utjecaja na redoslijed
odziva.
• Apstrakcija događaja ne vodi prirodno na postupak razmjene
podataka (možda je potrebno uvođenje globalnih varijabli).
• Teško rasuđivanje o ponašanju komponenata koje objavljuju
događaje i pridruženim komponentama koje su registrirane uz te
86
događaje.
ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA
Stilistička varijacija MVC (Model View Controller)
Struktura za
povezivanje
87
MVC Example: Simple
Spreadsheet System
• Consider a simple spreadsheet system for
entering data and viewing charts (e.g Excel)
• Without major impact to the system, it
should be possible to:
– Add a new non-interactive view of the data
– Add a new interactive view of the data
88
MVC Example: Simple
Spreadsheet System
Controller:
handles user input
Model
View
89
Model-View-Controller Style
• Divides interactive application into three types of
components
– Model: Contains core functionality and data
– View: Displays information to the user
– Controller: Handles user input
• Goals: Separation of concerns
– Reuse
– Organizes code structure
– Independent development
• Change propagation (implicit invocation)
mechanism ensures consistency between user
interface and model
90
ARHITEKTURA ZASNOVANA NA DOGAĐAJIMA
Zaključak:
• Vrlo značajan stil arhitekture programske potpore.
• Očekuje se intenzivna primjena u multiprocesorskim
sustavima s više jezgara (engl. multicore).
91
ARHITEKTURA REPOZITORIJA PODATAKA
Predstavlja veliku skupinu sustava uz mnoge varijacije upravljanja i
dijeljenja podataka. Arhitektura obuhvaća načine prikupljanja,
rukovanja i očuvanja velike količine podataka.
Priodni primjer su baze podataka, ali ne i jedini (npr. oglasna ploča)
Pogled s najviše razine (dvije vrste komponenta):
92
ARHITEKTURA REPOZITORIJA PODATAKA
Dvije različite vrste komponenta:
• Središnji repozitorij podataka (predstavlja trenutno stanje)
• Kolekcija nezavisnih komponenta koje operiraju nad
središnjim repozitorijem.
Temeljna prednost ove arhitekture je jednostavno dodavanje i
povlačenje proizvođača i korisnika (konzumenata) podataka.
Problemi su koncentrirani oko:
• Sinkronizacije
• Konfiguracije i upravljanje shemama struktura podataka
• Atomičnosti
• Konzistencije
• Očuvanja (perzistencije)
• Performanse
93
ARHITEKTURA REPOZITORIJA PODATAKA
Jednostavna transakcijski usmjerena baza podataka:
3 vrste
komponenta
Komponente preko transakcija modificiraju ili čitaju podatke (preko
transakcijskog upita, engl. query) iz DB.
DB skladišti perzistentne podatke među različitim transakcijama.
Nema fiksnog uređenja redoslijeda između transakcija (nije kao u
skupno sekvencijskom modelu).
Paralelizam upravljan komponentom “Control”.
94
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
Temeljni koncept:
Mnogi eksperti promatraju jedni druge kako rješavaju problem na
ploči (npr. kriminalisti).
Svaki ekspert dodaje svoj dio u rješavanju cjelokupnog problema.
Osnovni dijelovi:
Izvori znanja (engl. knowledge sources), odvojeni i nezavisni dijelovi
primjenskog znanja. Ne surađuju međusobno izravno već samo
putem oglasne ploče.
Oglasna ploča, podaci o stanju problema, organizirani prema
primjenskoj hijerarhiji. Izvori znanja aktivirani promjenom sadržaja na
oglasnoj ploči mijenjaju pojedine sadržaje što inkrementalno dovodi
do rješenja problema.
Upravljanje stanjem oglasne ploče. Izvori znanja se odazivaju
oportunistički kada se promjene na oglasnoj ploči na njih odnosi.
95
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
Ekspertize iz
različitih domena
Upravljački dio
Važna distinkcija:
Baza podataka: vanjski procesi iniciraju promjenu sadržaja.
Oglasna ploča: promjena sadržaja inicira vanjske procese (KS).
96
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
Obilježja problema prikladnih za arhitekturu oglasne ploče
• Nema izravnog algoritamskog rješenja (višestruki pristup
rješavanju, potrebna ekspertiza iz različitih domena).
• Neizvjesnost (pogreške i varijabilnost u podacima, srednji
ili niski omjer “signala prema šumu” u podacima).
• Aproksimativno rješenje je dovoljno dobro (ne postoji
jedan diskretan odgovor na problem ili ispravan odgovor
može varirati.
Primjeri:
Obradba signala
Planiranje, logistika, dijagnostika
Optimizacija prevodioca (kompilatora, engl. compiler)
97
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
Što nije specificirano u ovoj arhitekturi:
Struktura znanja (kako je predstavljeno znanje).
Kako izvori znanja (KS) dohvaćaju podatke.
Kako izvori znanja zapisuju djelomične odgovore na oglasnu ploču.
Kako izvori znanja koriste podatke sa oglasne ploče.
Kako se određuje kvaliteta rješenja.
Kako se ustvari upravlja ponašanjem izvorima znanja.
Znanje može biti predstavljeno na različite načine (jednostavna
funkcija, kolekcija složenih logičkih izraza – pravila). Ma kako
predstavljeno znanje reflektira akciju na oglasnoj ploči pod
prikladnim okolnostima.
Statičko znanje: dugo živuća informacija, činjenice, vrijednosti
parametara, odnosi.
Dinamičko znanje: znanje generirano tijekom izvođenja, nove
činjenice, hipoteze, ciljevi, sugestije. Ovo znanje će često biti
mijenjano i brisano.
98
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
Oglasna ploča je izvor svih podataka na kojima operiraju izvori
znanja te destinacija svih zaključaka.
99
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
100
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
101
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
(rasuđivanje unatrag)
(rasuđivanje unaprijed)
(oportunističko rasuđivanje)
Proces završava kad više ne postoji niti jedan uvjet za aktivaciju
izvora znanja (ili naravno eksplicitan prekid operacijom “stop”).
102
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
Prednosti i nedostaci
Intencijsko i reaktivno ponašanje
Prednost: jednostavno integriranje različitih autonomnih
sustava.
Nedostatak: Oglasna ploča može biti vrlo složena arhitektura,
posebice ako su komponente prirodno međuzavisne.
Predstavljanje i obradba neizvjesnog znanja
Prednost: Oglasna ploča je dobra arhitektura za ovaj tip
problema.
Sigurnost i tolerancija na kvarove
Prednost: podsustavi mogu promatrati oglasnu ploču i obratiti
pažnju na potencijalne poteškoće.
Nedostatak: Oglasna ploča je kritičan resurs.
Fleksibilnost
103
Prednost: oglasna ploča je inherentno fleksibilna
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
Primjer: Hearsay – sustav za raspoznavanje govora s velikim
vokabularom (CMU, 1976). Složena struktura problema motivirala
je istraživanje organizacije i uporabe znanja u računalnim
sustavima.
Oglasna ploča daje višestruko i hijerarhijski organizirano
predstavljanje govora.
Upisom podataka aktivira se izvor znanja odgovarajuće razine:
• Valni oblici
• Fonemi
• Slogovi
• Rečenice
Cjelokupni problem se razdvaja na akustičku, fonetski, leksičku,
sintaktičku i semantičku razinu.
Sustav rangira verzije potencijalnih rečenica metrikom
vjerodostojnosti i daje najvjerojatniji prijevod.
104
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
105
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
( DoD 2000)
106
ARHITEKTURA REPOZITORIJA PODATAKA
Oglasna ploča (engl. blackboard)
107
ARHITEKTURA REPOZITORIJA PODATAKA
Primjer: Prevoditelj (engl. compiler)
Computer Aided Software Engineering (CASE)
Inicijalno: prevođenje izvornog u objektni kod (kompilator, knjižnica library, povezivanje – linker, “make”).
Razvoj uključuje zapis verzije, dokumentaciju, analizu, upravljanje
konfiguracijama, itd.
Traži se čvršća integracija pojedinačnih alata (u 20 godina još nije
postignuta).
Tradicijski prevoditelj (1970, sekvencijski) (arh. prot. pod.)
plus odvojena tablica simbola
108
ARHITEKTURA REPOZITORIJA PODATAKA
(Rudimentaran)
1985, “attribute” gramatika, stablo parsiranja
109
ARHITEKTURA REPOZITORIJA PODATAKA
Redoslijed izvođenja je predefiniran (različito od baza podataka).
Informacija u repozitoriju nije perzistentna od jedne uporabe do
druge.
110
ARHITEKTURA REPOZITORIJA PODATAKA
Poželjno CASE okruženje:
111
SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE
Primjenski program ili operacijski sustav se strukturira
tako da se dekomponira u podskupove zadataka koji
čine različite razine apstrakcije
Temeljni elementi:
• Komponente
• Konektori
=
=
slojevi
protokoli koji definiraju
interakciju između slojeva
Hijerarhijska organizacija:
• Samo susjedni slojevi komuniciraju
• Svaki sloj daje uslugu sloju iznad i postaje klijent sloju
ispod.
• Svaki sloj skriva slojeve ispod.
112
SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE
Tipični primjeri: OSI, TCP/IP
OSI slojeviti model je
danas zastario.
Zamijenjen je
popularnim Internet
Protocol Stack–om.
113
SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE
Primjer: Organizacija programskih cjelina u računalu
Primjeri:
UNIX (Linux)
jezgra,
X Window
sustav (Xlib, Xt,
Motif), API
114
SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE
Primjer: Predstavljanje znanja na Web-u (Semantički
Web)
(znanje predstavljeno kategorijama i
hijerarhijom pojmova)
115
SLOJEVITA ARHITEKTURA PROGRAMSKE POTPORE
Prednosti slojevite arhitekture:
• Sloj djeluje kao koherentna cjelina.
• Vrlo jednostavna zamjena sloja novijom inačicom.
• Jednostavno održavanje jer svaki sloj ima dobro definiranu
ulogu.
• Minimizirana je međuovisnost komponenata.
• Podupire oblikovanje programske potpore na visokoj
apstraktnoj razini.
• Podupire ponovno korištenje (engl, reuse).
Nedostaci slojevite arhitekture:
• Smanjene performanse jer gornji slojevi samo indirektno
dohvaćaju donje slojeve.
• Teško se pronalazi ispravna apstrakcija (posebice u
sustavima s većim brojem slojeva).
• Svi sustavi se ne preslikavaju izravno u slojevitu
arhitekturu (djelokrug programske jedinice može
zahvaćati više slojeva).
116
VIRTUALNI STROJEVI (VM)
Virtualni stroj je računalno okruženje čiji skup resursa i
funkcionalnost je izgrađena (kroz programski sloj) iznad nekog
drugog programskog okruženja (apstrakcija računalnih resursa).
Npr.: Java primjenski program se izvodi u okviru Java virtualnog stroja
(JVM), koji se pak izvodi u okviru nekog operacijskog sustava.
Međusloj može prenositi upravljačke naredbe u niži sloj, može sakriti
neke funkcionalnosti nižeg sloja, ali i dodati neke svoje (nove)
funkcionalnosti. Temeljna prednost je u odvajanju primjenskog
programa od ostatka sustava (nedostatak je slabljenje performansi).
VM može simulirati funkcionalnost (još) nepostojeće sklopovske
platforme (pomaže u razvoju prog. potpore za nove naprave).
Konfiguracija više ne slijedi tradicijsku organizaciju (sklopovlje – OS –
primjenski program) već jednu od nekoliko mogućnosti pod
zajedničkim nazivom Virtualni stroj (VM).
Te su konfiguracije: Hipervisorski VM, Udomaćen VM (engl. hosted),
Primjenski VM i Paralelni VM.
117
VIRTUALNI STROJEVI (VM)
Hipervisor VM (engl. hypervisor)
Dodani sloj je odmah iznad sklopovlja. Na njega se oslanjaju jedan
ili više OS gdje svaki smatra da je jedini OS u računalu
(npr. VMware ESX server).
Primjenski program 1 Primjenski program 2 Primjenski program 3
OS 1
OS 2
OS 3
Hipervizorski program (VM)
Sklopovlje
118
VIRTUALNI STROJEVI (VM)
Udomaćen VM (engl. hosted VM)
VM, kao i svaki drugi primjenski program izvodi se iznad OS-a. Shema je
manje efikasna od Hypervisorskog VM, ali osnovna prednost odvajanja ostaje
(primjer VMware GSX server, Microsoft Virtual PC).
Primjenski program 1
Primjenski program 2
OS
Sklopovlje
Primjenski program 3
Udomaćen OS_1
119
VIRTUALNI STROJEVI (VM)
Virtualni stroj primjenske razine (nije opće namjene kao udomaćen OS)
Slično udomaćenu VM, ali na primjenskoj razini. Npr. Java VM je primjenski
program (izvodi se na izvornom OS-u), a Java primjene se izvode na Java VM.
Prednost: Java primjenski program izvodit će se bez prevođenja na svakom
Java VM (koji je različit za svaki osnovni računalni sustav).
Primjenski program 1
Primjenski program 2
OS
Sklopovlje
Primjenski program 3
Java VM
Paralelni VM
Međusloj egzistira kao programski (zlo)duh (UNIX “demon”) ili uslužni
program, zajedno sa pozivima u skup rutina (“library calls”). Pozivi
rutina su uključeni (prevoditeljem) u primjenski program. Međusloj
omogućuje da su rutine raspodijeljene u mreži računala.
120
VIRTUALNI STROJEVI (VM)
Interpreter kao VM
Svrha ove arhitekture:
Poduprti prenosivost. Programski jezik ne ovisi o platformi
izvođenja.
Motivacija:
Omogućiti primjenskom programu izvođenje bez prevođenja
u prirodni kod računalnog sustava na kojem se izvodi.
Simuliraju se funkcionalnosti koje nisu urođene sustavu na
kojem se izvodi. Mogu se simulirati opasni ili skupi modovi
izvođenja.
Prednosti:
Brzo izvođenje prototipa; analiza i izmjene u programu pri
izvođenju (program se posebno ne prevodi).
Nedostaci:
Performanse su niže nego prirodni (prevedeni) kod.
121
VIRTUALNI STROJEVI (VM)
Interpreter kao VM
Arhitektura:
(pseudokod)
inputs
selected
outputs
(automat, stroj stanja)
122
VIRTUALNI STROJEVI (VM)
Interpreter kao VM
Osnovni dijelovi:
• Program koji se interpretira (katkad nazvan pseudokod),
nalazi se u memoriji.
• Podaci programa koji se interpretira. Nalaze se u memoriji.
• Predstavljanje unutarnjeg stanja interpretera u memoriji.
• Interpreterski stroj (izvodi posao), izveden kao stroj stanja.
Interpreter povezuje izvedbeni stroj dan semantikom programa i
izvedbeni stroj definiram sklopovljem računalnog sustava.
123
Inerpreter: Rule Based Style
Inputs
Knowledge base
Working
Memory
Data &
Updates
Rule
base
Fact
memory
Active Rules
& Facts
New Facts
New Active Rules
Trigger Data
Outputs
Rule
Interpreter
Selected Rule
Selected Data
Rule &
Data Element
Selection
Select and and Execute Rules based on the Current State and Derived Facts
124
ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA
Npr. ručno upravljanje hlađenjem i grijanjem u automobilu.
125
ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA
Automatizirano upravljanje grijanjem.
126
ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA
Organizacija:
Elementi izračunavanja
• Definicija procesa (kontinuirani, stohastički, ...)
• Upravljački algoritam (koristi informaciju o trenutnom stanju
procesa te na propisani način vodi proces prema željenom
stanju).
Podaci (varijable):
• Procesne varijable (mogu se mjeriti)
• Upravljive varijable (npr. temperatura grijanog zraka)
• Ulazne varijable (npr, temperatura sobe)
• Postavne veličine (“set points”)
Upravljanje s povratnom vezom (engl. feedback) informacija o procesnim
varijablama koristi se za upravljanje (inače upravljanje bez povratne
veze)
Ova arhitektura je posebice dobro prilagođena kontinuiranim procesima.
127
Nije jednostavno primjenljiva na više međusobno ovisnih procesa.
ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA
Općeniti dijagram:
128
ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA
Tehnička shema fizikalnog procesa je razumljiva, ali nejasno koje
programske jedinice uporabiti.
Potrebna općenitija analiza programskih i sklopovskih dijelova te
okoline (engl. HW + SW + environment).
Software
Hardware
Devices (peripherals)
Sensors
Actuators
Interact with
environment; e.g.
transform materials.
Environment
129
ARHITEKTURA PROGRAMA U UPRAVLJANJU PROCESIMA
Realizacija
Budući da u ovoj arhitekturi pojedine programske komponente nisu
specificirane, najčešće se koristi neka od temeljnih programskih
arhitektura kao npr.:
• Cjevovodi i filtri
• Arhitektura zasnovana na događajima
Preporuke
Upravljanje s povratnom vezom (zatvorena petlja) treba koristiti u
zadacima koji:
• Zahtijevaju kontinuiranu akciju, ponašanje ili promjenu stanja
sustava.
• Programske komponente se ugrađuju u fizički sustav (nužno
je razmatranje ograničenja okoline te intenzivnu uporabu
ekspertskog znanja domene primjene).
130