ARHITEKTURA PROGRAMSKE POTPORE engl Software Architecture 1 Prednosti

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) Visual. Basic, 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 13 izlazne sekvence.

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 Lab. View 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 Lab. VIEW 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, 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 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 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. Savings. Account might charge an extra fee following every debit • For optimization —E. g. The get. Perimeter. Length 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 Sun. World ’ 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 (P 2 P) A type of distributed architecture in which each station has equivalent capabilities and responsibilities (both servers and clients). The P 2 P network itself relies on computing power at the ends of a connection rather than from within the network itself. P 2 P is often mistakenly used as a term (Affinity Communities) to describe one user linking with another user to transfer information and files (MP 3 s, videos, images, etc. ). P 2 P 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 P 2 P networking is Instant Messaging, where software applications, such as MSN Messenger allow users to chat via text messages in real-time. 57

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 ? ) 63

Components and connectors 64

65

66

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 67

mali izresci 68

69

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 71

72

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 73

Nije na prodaju ! 74

DEC protocol in VAX IP = intelektualno vlasništvo 75

76

77

Operating environment 78

79

Some Potential Key Technologies What software technology, or technologies will play the central role in enabling such a distributed component architecture ? • CORBA • Java and Java. Beans • Microsoft DCOM (. NET) 80

(. NET) 81

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) ( Do. D 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 Active Rules Trigger Data Outputs Rule Interpreter Selected Rule Selected Data Rule & Data Element Selection Select 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