Stiluri si tipare arhitecturale fundamentale Stiluri arhitecturale fundamentale

Stiluri si tipare arhitecturale fundamentale

Stiluri arhitecturale fundamentale • Continutul cursului si bibliografie: • Layers • [POSA 1] – in 2. 2 • Pipes and Filters • [POSA 1] – in 2. 2 • Blackboard; cu variantele Repository, Active Database • [POSA 1] – in 2. 2 • • Event-driven (Implicit Invocation); cu variantele Publisher-Subscriber, Event. Bus • [POSA 1] – din 3. 6 • S. Gupta, J. Hartkopf, S. Ramaswamy: Event Notifier, a Pattern for Event Notification, in Java Report, 1998 (republished as chapter 11 in the book More Java Gems, Cambridge University Press, 2000) http: //sites. google. com/site/jeffhartkopf/notifier Bibliografie generala optionala: • David Garlan, Mary Shaw, An Introduction to Software Architecture, online http: //www. cs. cmu. edu/afs/cs/project/able/ftp/intro_softarch. pdf

Layers Stilul Layers (pe niveluri): adecvat aplicatiilor care pot fi descompuse in grupuri de subtaskuri, fiecare grup reprezentand un anumit nivel de abstractizare. Fiecare nivel utilizeaza servicii furnizate de nivelul(urile) de sub el • Exemplu tipic: – Stive de protocoale de retea – Fiecare nivel se ocupa de un anumit aspect al comunicarii in retea si utilizeaza serviciile nivelului inferior

Exemplu tipic pentru Layers [POSA]-Fig/P. 31

Layers: Context & Problema • Context: – Un sistem de mari dimensiuni care necesita descompunere in subsisteme (nu poate fi implementat monolitic) • Problema: – Caracteristica dominanta a sistemului este un amestec de operatii de nivel inalt si de nivel scazut de abstractizare, operatiile de nivel inalt depind de operatiile de nivel mai jos – Uneori apare si o structurare pe orizontala, independenta de structurarea verticala pe niveluri: mai multe operatii sunt pe acelasi nivel de abstractizare, dar intre ele independente (exemplu – nivelurile OSI unde apar mai multe functii insirate cu and) – Date initiale: specificatiile functionale pentru operatiile de nivel inalt, descrierea unei platformei tinta, dar cu mentiunea de portabilitate si pentru alte platforme.

Layers - Analiza • Interfetele intre layers trebuie proiectate astfel incat sa fie stabile (modificarile facute intr-un layer sa nu afecteze celelalte) • Partile sistemului (layers) trebuie sa fie inlocuibile (se poate inlocui implementarea unui layer) • Partile de nivel mai scazut (layers de la baza stivei) trebuie proiectate astfel incat sa poata fi eventual reutilizate si in alte sisteme • Granularitatea descompunerii in layers trebuie bine determinata ! – Granularitate prea mare: (prea putine layers de mari dimensiuni) – Granularitate prea mica: (prea multe layers de mici dimensiuni)

Layers: Solutie - structura • Sistemul este structurat pe subsisteme organizate ca o stiva de nivele • Nivelul cel mai jos este Layer 1 • Nivelul cel mai sus este Layer. N • Tiparul se bazeaza pe restrictionarea relatiei uses, aceasta fiind permisa doar intre anumite subsisteme: • Layer. J is allowed to use Layer. J-1 [POSA]-Fig/P. 34

Layers: structura caracteristica • Fiecare layer ascunde layer-ele de sub el fata de layer-ele de deasupra [POSA]-Fig/P. 35

Structura nivelurilor [POSA]-Fig/P. 35

Layers: Scenarii de comportament • Top-down communication • Bottom-up communication

Layers: Scenarii de comportament • Top-down communication: – un client adreseaza o cerere nivelului superior Layer. N. Acesta are nevoie de serviciile nivelului de sub el pentru a rezolva cererea clientului. Layer N 1 la randul sau va utiliza Layer N-2, etc, pana ajunge la Layer 1. – Variante: daca nivelurile implementeaza si informatii de “stare”, este posibil ca comunicatia nu ajunga pana la nivelul de jos, ci sa fie rezolvata complet de un nivel intermediar – De obicei, Layer J transpune o cerere primita de la Layer J+1 in mai multe operatii cerute la Layer J-1, considerate la un “nivel de abstractizare mai redus”

Layers: top-down communication EVENIMENT, CAUZA calls Directie permisa pentru relatii de tip uses

Layers: Scenarii de comportament • Bottom-up communication: – Un lant de actiuni este declansat din nivelul inferior Layer 1 (de ex un device driver detecteaza o modificare). Layer 1 trimite o notificare catre Layer 2, acesta incepe transformarea datelor asociate si trimite o notificare catre Layer 3, etc. – Trebuie realizata prin callback ! Acest mecanism realizeaza un flux ascendent de date si control, dar fara a rezulta relatii Uses de tip ascendent

Layers: Bottom-up communication Directie permisa pentru relatii de tip uses calls via callback EVENIMENT, CAUZA

Paranteza despre Mecanismul Callback • Solutia pentru situatiile descrise de relatiile: – FB calls FA dar A uses B si B does not use A • Mecanismul Callback: numele rutinelor din modulul A (de ex FA) de apelat din cadrul modulului B sunt transmise de sus in jos, in forma de date. Specificatia unui nivel inferior include doar obligatia ca intr-o anumita situatie (FB) sa apeleze rutina care i-a fost comunicata mai sus • Acest mecanism realizeaza un flux ascendent de date si control, dar fara a rezulta relatii Uses de tip ascendent -> nu contravine restrictiilor stilului Layered FA A FB B

Exemplu situatie callback • • • O aplicatie gestioneaza date despre studenti si realizeaza diferite prelucrari asupra acestora, inclusiv sortarea alfabetica. O alta aplicatie lucreaza cu reprezentarea unor puncte geometrice in plan, printre prelucrarile asupra acestora este si sortarea in ordinea distantei fata de origine Posibil ca alte aplicatii din alte domenii sa necesite sortarea unor date Pentru toate aplicatiile, se va alege o arhitectura de tip layers, cu 2 nivele Layer-ul Generic Utilities este refolosit intre diferitele aplicatii si trebuie sa contina o rutina generica de sortare Domain. Logic uses Generic. Utilities

Exemplu situatie callback main Student. Administration sort Generic. Utilities compare

Posibilitati implementare callback

Layers: Pasi de definire a unei arhitecturi Definirea criteriului de abstractizare: ce “inrudeste” elementele apartinand aceluiasi nivel ? De ex: distanta fata de HW, complexitatea conceptuala Determinarea numarului de niveluri: compromis intre: Prea multe: regie prea mare, probleme de performanta Prea putine: structura deficitara Numirea nivelurilor si atribuirea de functii: Specificarea serviciilor: Good practice: nivelurile inferioare implementeaza un numar restrans de servicii, nivelurile superioare implementeaza un numar mai mare de servicii Reconsiderarea pasilor anteriori, pana la solutia finala Specificarea interfetelor nivelurilor Asigura posibilitatea de a schimba implementarea unui nivel Stabilirea structurii nivelurilor Un nivel complex este implementat prin mai multe componente Asigurarea decuplarii intre niveluri Un nivel nu trebuie sa cunoasca identitatea nivelului de deasupra sa

Layers: variante • Relaxed Layered Systems: – se relaxeaza restrictia is-allowed-to-use: • Un nivel poate utiliza toate nivelurile de sub el – un nivel poate fi doar partial opac: • Anumite servicii sunt vizibile doar nivelului imediat urmator, dar alte servicii pot fi utilizate de toate nivelurile de deasupra – Afecteaza negativ maintenability • Merita utilizat in doar in sisteme care nu se modifica des si a caror performanta e importanta • Layering through inheritance – Nivelul inferior = clasa de baza; Nivelurile superioare sunt realizate prin mostenire (implementation inheritance) de la nivelurile inferioare – Fragile base class problem: o modificare a reprezentarii datelor in clasa de baza (nivelul inferior) necesita recompilarea tuturor celorlalte – Nu e o idee buna!

Layers: Proprietati ale stilului • Avantaje: – Reusability: fiecare layer poate fi reutilizat individual, daca implementeaza o abstractizare coerenta a unor servicii si are o interfata bine definita si documentata – Portability: interfetele standardizate ale nivelurilor permit limitarea efectelor modificarilor in cadrul unui singur nivel – Testability: nivelurile pot fi testate independent – Exchangeability: se poate inlocui implementarea unui anumit nivel • Atentionari: – Cascades of changing behaviour: modificarea comportamentului unui nivel poate avea efecte negative asupra comportamentului sistemului: – Lower efficiency: daca la fiecare nivel apar transormari ale datelor transferate, performanta este mai slaba decat in cazul unei implementari monolitice – Unnecessary work: daca nivelurile inferioare realizeaza operatii care nu sunt cerute de nivelurile superioare

Layers: Observatii in concluzie • Stitul arhitectural layers se bazeaza pe restrictionarea directiilor permise ale relatiilor de dependenta statica de cod (de tip uses) • Restrictionarea directiilor permise ale relatiilor de tip uses (si mai ales evitarea dependentelor ciclice !) este pe de alta parte si un principiu general pentru un design bun! • Exista tool-uri care permit analiza relatiilor de dependenta – Exemple: – NDepend, dependencyfinder, Lattix, JDepend, etc – ART

Pipes and Filters: structura adecvata pentru sistemele care proceseaza fluxuri de date. Fiecare pas de procesare este realizat de un Filtru. Datele sunt transmise intre doua filtre succesive prin conducte (Pipes). Este posibila recombinarea Filtrelor in alte sisteme. • Exemplul cel mai tipic: pipeline de comenzi unix: ls | grep old | more

Alt exemplu: domeniu aplicatie: Signal processing&Virtual Instrumentation

Context & Problema • Context: Procesarea fluxurilor de date • Problema: o aplicatie care poate fi descompusa in mod natural in mai multe etape de procesare; – Este nevoie de flexibilitate in viitor, obtinuta prin reordonarea componentelor (etapelor de procesare) – Este posibila constructia unei familii de sisteme asemanatoare prin utilizarea a diferite subseturi de componente – Componentele ne-adiacente nu utilizeaza informatii comune – Este luata in considerare posibilitatea ca etapele sa fie rulate in regim multitasking – Solutia nu este aplicabila aplicatiilor interactive, conduse de evenimente

Solutie - structura • Sistemul se descompune natural in etape de procesare secventiala • Fiecare etapa este implementata de o componenta de tip Filtru • Caracteristicile unui Filtru: – Citeste date din fluxul de intrare – Realizeaza un anumit tip de procesare pe datele de intrare – Produce date pe fluxul de iesire • Etapele de procesare sunt legate prin fluxul de date din sistem • Pipes (conducte): – transporta fluxul de date intre 2 filtre consecutive – Implementarea unei conducte poate utiliza diferite tehnici: apel de functie, apeluri sistem pipe, etc.

[POSA]-Fig/P. 56

Solutie - comportament • Tipuri de Filtre: – Pasive: activitatea lor este declansata explicit de filtrul precedent (push) sau de filtrul urmator (pull) – Active: corpul filtrului consta dintr-un ciclu continuu in care citeste-proceseaza-scrie date • Daca filtrele sunt de tip activ, Pipe trebuie sa realizeze si sincronizarea intre filtre active, prin bufferare • Citirea si producerea datelor trebuie facuta incremental, pentru a reduce latenta si a permite o eventuala procesare concurenta

Passive Filters: Push pipeline vs Pull pipeline [POSA]-Fig/P. 58

Active Filter: Push/pull pipeline [POSA]-Fig/P. 60

Pipes and Filters – Exemplu ? [POSA] Exemplu: Un compilator pentru un nou limbaj de programare Mocha (Modular Object Computation with Hypothetical Algorithms) Compilatorul trebuie sa fie portabil pe diferite platforme => se defineste limbajul intermediar Au. Lait (Another Universal Language for Intermediate. Translation) care se executa pe o masina virtuala Cup (Concurrent Uniform Processor)

Exemplu Compilator Pipes and Filters [POSA]-Fig/P. 53

Exemplu – aplicarea solutiei [POSA]-Fig/P. 57

Exemplu – aplicarea solutiei (cont) • • Primele 4 etape ale compilatorului Mocha sunt implementate in acelasi program pentru ca utilizeaza date in comun Codificarea tabelei de simboluri pentru a fi transmisa intre aceste etape ar fi fost mult mai voluminoasa decat restul datelor transmise, rezultand scaderea eficientei Ultima etapa (backend) este realizata ca procese separate, pentru ca necesita flexibilitate Exemplu de compilare si optimizare program pentru HW Sun: Mocha <prog. mocha | optau. Lait | au. Lait 2 SPARC > prog. exe • Exemplu de compilare si interpretare: Mocha <prog. mocha | cup [POSA]-Fig/P. 65

Pasi de definire a unei arhitecturi pipes-and-filters • Divizarea functionalitatii sistemului intr-un numar de stagii intermediare de procesare • Definirea formatului datelor care se transmit pe fiecare pipe – Format uniform => flexibilitate maxima, dar poate afecta negativ eficienta • Alegerea tipului de pipe pentru fiecare conexiune. Tipul de pipe influenteaza tipurile de filtre – pasive sau active • Proiectarea filtrelor – Rule of thumb: One filter should do one thing well => asigura reutilizarea individuala • Proiectarea mecanismului de tratare a erorilor – Mecanisme de resincronizare a pipeline • Realizarea sistemului prin asamblarea filtrelor

Proprietati ale stilului Pipes-and-filters • Avantaje: – – Flexibilitate prin recombinare: Reusability pentru componentele filtru Dezvoltare rapida Posibilitate de procesare concurenta • Atentionari: – Imposibil de mentinut o informatie de stare comuna accesibila in mod eficient tuturor filtrelor – Overhead datorita operatiilor de transformare a formatului datelor – Error handling

Discutie: Pipes-and-Filters vs Layer A Layer B Layer C Filter A Filter B Filter C

Discutie: Pipes-and-Filters vs anumiti design patterns

Blackboard: tipar adecvat problemelor in care mai multe subsisteme specializate, independente, contribuie la gasirea unei solutii • Exemplu: Inteligenta artificiala – recunoasterea vorbirii • Date de intrare: – vorbirea inregistrata ca waveform – Sistemul accepta nu numai cuvinte izolate, ci si fraze – Sintaxa frazelor si vocabularul utilizat sunt restrictionate in concordanta cu un anumit tip de aplicatie (ex interogare baza de date) • Date de iesire: – reprezentare interna (comanda corespunzatoare) pentru fraza recunoscuta – La gasirea solutiei contribuie subsisteme independente, specializate pe domenii diferite: acustica-fonetica, lingvistica, statistica

Exemplu pentru arhitectura BB • Sistem de recunoastere a vorbirii • HEARSAY-II KS BB Word Creation Syllable Creation Segmentation [POSA]-Fig/P. 70

Solutie - Blackboard • Structura: o colectie de elemente independente (Knowledge Sources) care lucreaza in acelasi timp pe o structura de date comuna (Blackboard), in vederea rezolvarii unei probleme • Fiecare KS este specializat pe o anumita parte a problemei comune • KS sunt independente: nu exista interactiuni directe intre ele • Ordinea de activare a KS nu este prestabilita, ci rezulta in mod dinamic in functie de evolutia datelor din BB. – Poate utiliza o componenta centrala de control care evalueaza starea curenta a BB si activeaza KS • Continutul BB: Solution space – consta din solutii partiale (hypotesis), la diferite nivele de abstractizare • Pe parcursul rezolvarii problemei, KS produc noi ipoteze, modifica gradul de incredere in valabilitatea unei ipoteze, sau elimina ipoteze care se dovedesc false

Solutie - Blackboard [POSA]-Fig/P. 77

Solutie - Blackboard • BB: – Permite KS sa citeasca si sa scrie date • KS – Conditie: evalueaza starea curenta a solutiilor partiale din BB si determina daca in aceste conditii are ceva de facut – Actiune: efectueaza calculele specifice, acestea pot duce la modificarea starii BB • Control – Monitorizeaza BB – Activeaza activitatile de evaluare sau de actiune ale KS [POSA]-Fig/P. 79

Scenariu exemplu [POSA]-Fig/P. 80

Pasi de definire a unei arhitecturi Blackboard • Definirea problemei: stabilirea domeniilor de cunostiinte implicate, definirea intrarilor si a proprietatilor (zgomote, variatiuni) • Definirea spatiului solutiei: solutii partiale/complete, de nivel inalt/de nivel intermediar • Divizarea procesului de rezolvare in pasi: defineste regulile dupa care solutiile se transforma in solutii de un nivel de abstractizare mai inalt; • Stabilirea knowledge sources si a a sarcinilor acestora • Definirea vocabularului BB: gasirea unei reprezentari a datelor astfel incat toate KS sa poata scrie si citi din BB • Descrierea controlului: Controlul implementeaza o strategie oportunista care determina ce KS pot face modificari la BB. Tinta este construirea unei ipoteze acceptabile (credibilitatea > prag) • Implementarea KS: separarea in partea de conditie si partea de actiune; o KS nu trebuie sa cunoasca celelalte KS sau componenta de Control

Varianta - Repository • Generalizare a Blackboard • Nu exista o componenta centrala de control si KS nu au partea de exec. Condition • Ordinea de executie a KS este determinata de utilizator sau de un program principal • Exemple: – Baze de date clasice – CASE Toolset

Varianta – Active Database • Baza de date contine mai multe tipuri de date • Un KS este asociat cu un anumit tip de date si este activat cand un element de acel tip este modificat • Activarea KS se face prin evenimente: initial, fiecare KS isi inregistreaza interesul pentru o anumita portiune a bazei de date. Cand se intampla modificari in acea portiune, KS este notificat

Proprietati ale stilului Blackboard • Avantaje: – – Permite experimentarea cu diferiti algoritmi si euristici Changeability Reusability pentru KS Fault tolerance • Atentionari: – Testability: redusa – Low efficiency – Complexitate ridicata la realizare

Event-driven(Implicit invocation): componente reactioneaza la evenimente produse de alte componente necunoscute lor. Stilul suporta un grad mare de dinamism in ceea ce priveste aparitia de noi componentele participante si introducerea unor noi tipuri de evenimente. Event Service op Obj 1 op Explicit invocation Obj 2 Obj 1 Obj 2 Implicit invocation

Event Channel - Structura Publisher Subscriber Event Channel Publisher Subscriber

Event Channel - Aplicabilitatea Exista componente care produc evenimente, dar nu cunosc identitatea componentelor care vor “consuma” aceste evenimente si nici exact modul in care vor consuma evenimentele. (Publisher) Este posibil ca mai multi publisheri sa produca acelasi tipuri de evenimente. Exista componente care sunt interesate sa primeasca anumite tipuri de evenimente, dar nu cunosc/nu le intereseaza identitatea componentelor care le-au produs (Subscriber) Este posibil ca un Subscriber sa fie interesat de mai multe tipuri diferite de evenimente Este posibil ca o componenta sa fie in acelasi timp Publisher si Subscriber pentru diferite evenimente Componentele participante (Publisheri sau Subscriberi) pot fi adaugate/scoase in mod dinamic din sistem Noi tipuri de evenimente pot fi adaugate in mod dinamic Componetele pot fi localizate in procese distincte (distribuite)

Event Channel – Modele de comunicare De obicei, cand un eveniment este receptionat de (unul sau mai multi) Subscriber-i, se realizeaza un transfer de date intre Publisher-ul care a generat evenimentul si Subscriber-ii respectivi Se pot defini 4 categorii de modele de comunicare, in functie de modul in care se realizeaza acest transfer de date: Push: Publisher-ul este sursa activa care initiaza transferul de date, Subscriber este destinatie pasiva. Event Channel = Notifier Pull: Subscriber initiaza (cere) transferul de date de la sursa (Publisher) pasiva. Event Channel = Procurer Hibrid Push/Pull: Publisher-ii si Subscriber-ii sunt initiatori activi ai transferurilor, care au loc intr-un/dintr-un buffer de la Event Channel = Queue Hibrid Pull/Push: Publisher-ii si Subscriber-ii sunt entitati pasive, initiativa transferurilor de date ii apartine lui Event Channel = Intelligent Agent

Push: Notifier Active behaviour Passive behaviour Publisher Subscriber Push data Notifier Publish Event Receive Event Data Transfer

Pull: Procurer Passive behaviour Active behaviour Publisher Subscriber Pull data Procurer Publish Event Receive Event Data Transfer

Hybrid Push/Pull: Queue Active behaviour Publisher Subscriber Pull data Push data Queue Publish Event Receive Event Data Transfer

Hybrid Pull/Push: Intelligent Agent passive behaviour Publisher Subscriber Push data Pull data Intelligent Agent Publish Event Receive Event Data Transfer

Discutie: comparatie modele Push/Pull Avantaje/Dezavantaje Utilitate (exemple situatii) Posibilitati implementare

Structura unei aplicatii Event-Driven Componente (Elemente): Publishers, Subscribers Connectori (Relatii): publish event, subscribe to event type Infrastructura: Event Channel. De obicei nu face parte din aplicatie ! Poate fi un messaging/ event middleware de tip Java Message Service, CORBA message service, etc Publisher Subscriber Event Channel Publisher Subscriber

Exemplu problema si posibilitati de implementare: Network Management System Managed Objects Router Hub Management System Console Paging Managed Objects: elemente de retea monitorizate; sunt in numar mare, de diverse tipuri, si pot fi pornite sau oprite in mod dinamic. Cand sunt pornite, activitatea lor e monitorizata de elemente din Management System. Evenimente monitorizate: erori neasteptate in functionare (de diverse grade de gravitate), indicatori de performanta Management System: cuprinde elemente de tip console, pagere, e-mail. Fiecare element din management system poate fi configurat sa urmareasca anumite categorii de evenimente

Exemplu Network Management: Solutie simplista Managed Objects Management System Probleme: • Solutie nescalabila: Fiecare Managed object trebuie sa trimita direct notificari fiecarui obiect din management system • Orice schimbare/adaugare in Management System (exemplu: adaugare e-mail Notification) afecteaza toate Managed Objects

Exemplu Network Management: Solutie tip Mediator Managed Objects Management System • Orice schimbare/adaugare in Management System (exemplu: adaugare e-mail Notification) afecteaza doar Mediator • Scalabilitate mai buna (numarul de dependente este n+m in loc de n*m) • Probleme: • Nu suporta adaptarea dinamica si diferentiata a sistemului de management (de ex fiecare managed object sa fie monitorizat doar de un subset (eventual dinamic variabil) de obiecte din Management System

Exemplu Network Management: Solutie tip Observer Managed Objects Management System • Managed Objects nu trebuie sa cunoasca de dinainte multimea de obiecte din management system pe care le notifica • Probleme: • Fiecare obiect din management system trebuie sa cunoasca fiecare managed object pe care il monitorizeaza. • • • Dezavantaje: Numarul de managed objects poate fi foarte mare Managed objects pot sa apara si sa dispara

Exemplu Network Management: Solutie tip Event Channel Subscriber Publisher Managed Objects Management System Event. Channel Hub Router Console Paging System Asigura o decuplare mult mai puternica intre Managed Objects si Management System Managed Objects nu cunosc identitatea obiectelor din Management System Obiectele din Management System nu cunosc identitatea managed Objects, ci doar tipurile evenimentelor generate de acestia

Event Channel Asigura o decuplare mult mai puternica intre Publisher-i si Subscriber-i Publisher-ii nu cunosc identitatea Subscriber-ilor Subscriberii nu cunosc identitatea Publisher-ilor, ci doar tipurile evenimentelor generate de acestia Intre Publisher si Subscriber se interpune un Event Channel (asemanator Mediator) Scenariu: Concrete Subscriber se inregistreaza la Event Channel, specificand tipul de evenimente de care este interesat Concrete Publisher anunta la Event. Channel producerea unui eveniment Event. Channel determina ce Concrete Subscribers sunt interesati de acest eveniment Event Channel ii informeaza pe acestia de evenimentul produs

Exemplu Implementare Event Notifier [Gupta, Hartkopf, Ramaswamy] Event. Service: intermediaza transmiterea de evenimente intre publisher si subscriber Publisher (Hub, Router): emite evenimente Subscriber: interfata pentru toti consumatorii de evenimente Concrete. Subscriber (Console, Pager): subscrie la Event. Service pentru anumite tipuri de evenimente, trateaza evenimentele implementand interfata Subscriber Event: Baza ierarhiei de tipuri de evenimente Filter: elimina evenimente care nu sunt de interes pentru un anumit subscriber (de exemplu, un Concrete. Subscriber poate fi interesat de un anumit tip de evenimente – de exemplu Fault. Event, cu exceptia celor provenind de la un anumit Hub particular)

Discutie Implementare Event Notifier Subscriptia se bazeaza pe tipuri de evenimente si nu pe identitatea unui publisher Publisheri si Subscriberi sunt independenti. Cuplarea intre ei se reduce la cunoasterea unui set de evenimente permise (semantica evenimentelor si datele asociate) Subscrierea la un anumit tip de eveniment cuprinde automat si toate subtipurile sale Filtrarea evenimentelor se poate face in plus fata de tipul evenimentului in functie de alte atribute (de ex sursa evenimentului, datele asociate, etc) Dezavantaj: type safety vs generalitate: Class is. Kind. Of method in Event Inform(event): cast la tipul (tipurile) asteptate de evenimente Dezavantaj: Event Service e un point of bottleneck – performanta si fiabilitate redusa. Solutie: mai multe Event. Services, fiecare specializat intr-o anumita categorie de evenimente Facilitati optionale: Advertisment and Discovery of available Event Types

Variante ale stilului Event-Driven Active Database: combinatie cu Blackboard: Distributed Event Notification: combinatie cu Broker:

Implementari reprezentative Publisher-Subscriber simplu: Mecanisme incorporate in unele limbaje de programare: Java: Event - Listener C#: Event - delegate Event Channel: incorporat in infrastructuri (middleware) pentru aplicatii distribuite Java Message Service (JMS) Corba Event Service

Concluzii privind Stilurile arhitecturale fundamentale (1) • descriu scheme de structurare a unui sistem din puncte de vedere diferite – Structura statica (Module viewtype): Layers – Structura dinamica de runtime (Component & connector viewtype): Pipes-Filters, Blackboard, Event-driven • Sunt solutii elementare de structuri foarte simple • In sisteme reale, pot apare in stare “pura” sau combinate/hibridizate

Concluzii privind Stilurile arhitecturale fundamentale (2) • Alegerea unui anumit stil arhitectural pentru o aplicatie poate influenta caracteristicile/calitatile proiectului • For further reading: David Garlan, Mary Shaw, An Introduction to Software Architecture, Technical Report Carnegie-Mellon University, no CMU-CS-94 -166, http: //www. cs. cmu. edu/afs/cs/project/able/ftp/intro_softarch/intro_sof tarch. pdf – Analizeaza probleme diferite din punctul de vedere al avantajelor/dezavantajelor aduse solutiei de aplicarea unui anumit stil arhitectural • Laborator: problema expresiilor aritmetice speciale

Concluzii privind Stilurile arhitecturale fundamentale (4) • Sunt stiluri/tipare cu un grad foarte ridicat de abstractizare, reprezinta solutii de organizare structurala independente de o anumita paradigma de programare sau de o anumita tehnologie – Componentele acestor tipare arhitecturale pot avea granularitati diferite, de la obiecte, componente, si pana la aplicatii care sunt integrate – For further reading: Enterprise Integration Patterns – Carte: Enterprise Integration Patterns, by Gregor Hohpe and Bobby Woolf, A Martin Fowler Signature Book, Addison Wesley, 2004 – Site asociat cartii: http: //www. eaipatterns. com/ • Shared Database (Repository): http: //www. eaipatterns. com/Shared. Data. Base. Integration. html • Pipes and Filters: http: //www. eaipatterns. com/Pipes. And. Filters. html • Messaging (Event-Driven) http: //www. eaipatterns. com/Messaging. html