Stiluri arhitecturale fundamentale Layers Pipes and Filters Blackboard; cu variantele Repository, Active Database Event-driven (Implicit Invocation); cu variantele Publisher-Subscriber, Event-Bus POSA

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 POSA

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

Layers: Context & Problema 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: Solutie - structura Sistemul este structurat pe subsisteme organizate ca o stiva de nivele Nivelul cel mai jos este Layer1 Nivelul cel mai sus este LayerN Tiparul se bazeaza pe restrictionarea relatiei uses, aceasta fiind permisa doar intre anumite subsisteme: LayerJ is allowed to use LayerJ-1 [POSA]-Fig/P.34

Structura nivelurilor POSA pag 35 [POSA]-Fig/P.35

Layers: Scenarii de comportament Top-down communication: un client adreseaza o cerere nivelului superior LayerN. 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” Bottom-up communication: Un lant de actiuni este declansat din nivelul inferior Layer1 (de ex un device driver detecteaza o modificare). Layer1 trimite o notificare catre Layer2, acesta incepe transformarea datelor asociate si trimite o notificare catre Layer 3, etc. Realizata prin callback [POSA]-Fig/P.35 POSA pag 36

Mecanismul Callback Necesitatea de a transmite in sus fluxuri de control si informatii Exemplu: tratarea erorilor: nivelul care a cauzat eroarea este locul cel mai bun de a asigura tratarea ei, indiferent de nivelul inferior in care aceasta a fost detectata A PA din A apeleaza PB din B, PB din B apeleaza PC din C. PC detecteaza eroarea, isi da seama ca a fost apelat incorect PC nu trebuie sa cunoasca detaliile lui B si nici PB nu trebuie sa cunoasca detaliile lui A, ca sa nu le limiteze portabilitatea B C Clements 85-86 Solutia: Mecanismul Callback: numele “programelor” de apelat in caz de eroare sunt transmise de sus in jos, in forma de date. Specificatia unui nivel inferior include doar obligatia ca in caz de eroare sa apeleze programul cu numele care i-a fost transmis Acest mecanism realizeaza un flux ascendent de date si control, dar fara a rezulta relatii Uses de tip ascendent -> nu contravine restrictiilor stilului Layered

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: Layering through inheritance 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 POSA

Pipes and Filters 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. 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 AuLait (Another Universal Language for IntermediateTranslation) care se executa pe o masina virtuala Cup (Concurrent Uniform Processor)

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

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

Alt exemplu: domeniu aplicatie: Signal processing&Virtual Instrumentation

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.

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

[POSA]-Fig/P.56

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

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

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 | optauLait | auLait2SPARC > prog.exe Exemplu de compilare si interpretare: Mocha <prog.mocha | cup [POSA]-Fig/P.65

Exemplu – Implementare Filtre active

Exemplu – implementarea de Filtre active in Java Variante de realizare a concurentei in Java: Filter extends Thread: Trebuie se redefineasca metoda run() Firul de executie este pornit invocand metoda start() a obiectului Thread Filter implements Runnable Trebuie sa implementeze metoda run() Obiectul Runnable este apoi transmis parametru constructorului unui Thread care va fi pornit cu start Mai multe detalii despre concurenta in java: Java.sun.com/docs/books/tutorial/essential/concurrency/runthread.html

Exemplu – implementarea de Filtre active in Java Constructia unei pipeline out in out Filter f1 = new FilterSource(); Filter f2 = new FilterT1(); Filter f3 = new FilterT2(); Filter f4 = new FilterSink(); Pipe p1 = new Pipe(f1, f2); Pipe p2 = new Pipe(f2, f3); Pipe p3 = new Pipe(f3, f4); new Thread(f1).start(); new Thread(f2).start(); new Thread(f3).start(); new Thread(f4).start(); F2 F3 P2 R Tr1 W R Tr2 W Buf While (! in.end()) { DataItem d=in.get(); d=transform(d); out.put(d); }

Exemplu – implementarea de Filtre active in Java Probleme de sincronizare out in out in F2 F3 P2 R Tr1 W R Tr2 W Buf Trebuie prevenit faptul ca F2 sa execute write pe P2 in acelasi timp cand F3 executa read pe P2 - Metodele write() si read() ale Pipe trebuie sa fie de tip synchronized Pipe trebuie sa contina un buffer de o anumita capacitate Daca se incearca un read si buffer-ul e gol, thread-ul trebuie pus in wait Daca se inceraca un write si bufferul e plin, thread-ul trebuie pus in wait Alternativa la construirea bufferului propriu: PipedReader+PipedWriter

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 POSA

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 Layers Layer A Filter A Filter B Filter C Layer B Layer C

Discutie: Pipes-and-Filters vs Decorator

Blackboard 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 POSA

Exemplu pentru arhitectura BB Sistem de recunoastere a vorbirii HEARSAY-II KS BB Word Creation POSA 71 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: KS Control 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 79 [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 lor (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 execCondition 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