Cuprins Introducere in Arhitectura Software Ce este arhitectura

Cuprins • Introducere in Arhitectura Software – Ce este arhitectura software ? – Care e diferenta intre arhitectura si design ? – Concepte: Architectural patterns, Architectural styles, Reference Models, Reference Architectures, Frameworks – De ce e importanta arhitectura software • Architectural Styles & Architectural Patterns

Introducere in arhitectura software

Arhitectura software - definitie • “The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them” [Bass]

Arhitectura software – definitia explicata • Elemente: – Arhitectura este o abstractizare a sistemului – Arhitectura omite anumite detalii: se exclud acele proprietati ale elementelor care nu afecteaza modul cum elementele pot fi utilizate de alte elemente sau interactiunile intre elemente – Proprietati vizibile din exterior: servicii furnizate, caracteristici de performanta, utilizarea resurselor partajate de mai multe elemente, etc. • Vederi structurale multiple: Arhitectura poate fi compusa din vederi structurale multiple. – De exemplu: • O vedere structurala asupra unui sistem poate captura relatiile dintre modulele in care este impartit proiectul in faza de dezvoltare. • O alta vedere structurala poate captura relatiile dintre elementele care apar in timpul executiei programului – Implicatii: Termenii “Elemente” si “Interactiuni intre elemente” pot avea diferite semnificatii: • Elemente pot fi: obiecte, clase, functii, procese, programe, biblioteci, etc. • Interactiuni intre elemente: subdivizare, sincronizare, apel de functie, etc. • Comportamentul elementelor (behaviour): – Partea observabila din exterior a comportamentului elementelor face parte din arhitectura

Care e diferenta intre arhitectura si design ? • “Architecture is design but not all design is architecture” [Clements] – Multe decizii privitoare la design nu sunt luate de arhitectura, ci sunt lasate la latitudinea proiectantului de detaliu si implementatorului • Ce decizii sunt ne-arhitecturale ? – Cele care se refera la elemente ale caror proprietati nu sunt vizibile din exterior – Exemplu: • prescriptie arhitecturala: Modulul M trebuie sa furnizeze apelantilor sai o modalitate de a salva si regasi date • decizii nearhitecturale: structurile de date (lista, tablou, etc) si algoritmii utilizati pentru implementare • Elemente arhitecturale vs Elemente nearhitecturale – Elemente nearhitecturale: ar putea fi acele elemente a caror existenta este necunoscuta in afara unui anumit context ?

Care e diferenta intre arhitectura si design ? (cont) • Elemente arhitecturale vs elemente nearhitecturale (cont): Exemplul 1: Modulul M -> M 2 Exemplul 2: arhitectura layered L 1 M M 2 L 3 • • • Faptul ca existenta unui element “nu este cunoscuta in afara unui context redus” nu este un bun criteriu pentru ca acesta sa fie declarat element nearhitectural ! In exemplul 1, M 2 este element nearhitectural ca urmare a deciziei proiectantului arhitecturii sistemului Un modul de tip M 2 poate fi atat element arhitectural cat si nearhitectural • Concluzie: [Clements]: “Architecture is in the eye of the beholder”

Concepte Reference Model Reference Architecture Design Pattern Architectural Style Software Architecture Framework

Architectural Pattern • “An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. ” [POSA 1]/pag. 12 • Exemplu: Model-View-Controller

Architectural Style • “An architectural style defines a family of software systems in terms of their structural organization. An architectural style expresses components and the relationships between them, with the constraints of their application, and the associated composition and design rules for their construction. ” [POSA 1]/pag. 394 • Exemplu: stilul Pipes-and-filters – Componente: toate au acelasi tip, Filter. • componente procesatoare de date, au 1 sau mai multe porturi de intrare si 1 sau mai multe porturi de iesire – Relatii dintre 2 componente: conectori Pipe • conector binar unidirectional care transmite fluxul de date de la un port de iesire al unui filtru spre un port de intrare al altui filtru – Constrangeri si reguli: • Un filtru nu trebuie sa cunoasca identitatea filtrelor de la care primeste sau la care transmite date

Relatia Architectural style ↔ Architectural pattern • Unii autori [Bass] interpreteaza architectural style = architectural pattern • Un stil arhitectural poate fi descris sub forma unui tipar arhitectural [POSA 1] • Diferente: – Stilurile se refera la aspecte macro, legate de structura globala a unei aplicatii. Tiparele pot acoperi o gama larga de aspecte, de la arhitectura -> design -> limbaj – Tiparele sunt mai concrete (mai orientate pe probleme concrete) – Stilurile nu sunt legate de probleme sau domenii de aplicatie concrete

Design pattern • “A design pattern provides a scheme for refining the subsystems of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context. [Go 4]” [POSA 1]/pag. 13 • • Tipare de scara mai mica decat cele arhitecturale Independente de un limbaj de programare (de obicei) independente de o paradigma de programare Aplicarea unor tipare din aceasta categorie nu afecteaza structura fundamentala a unui sistem

Reference Models • “A reference model is a division of functionality together with data flow between the pieces. It is a standard decomposition of a known problem into parts that cooperatively solve the problem. ” [Bass]/&2. 3 • Rezulta din experienta indelungata intr-un anumit domeniu de aplicatie • Sunt caracteristice domeniilor mature • Exemple: – Compilatoare: analiza lexicala, analiza sintactica, analiza semantica, optimizare de cod, generare de cod, – Retele: Modelul de referinta OSI

Reference Architectures • “A reference architecture is a reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them. ” [Bass]/&2. 3 • Reference model defineste o descompunere a functionalitatilor • Reference architecture defineste modul de mapare a functionalitatilor pe niste definitii de subsisteme/componente • Maparea poate fi 1 -1 dar nu neaparat necesar • Exemplu: CORBA (Common Object Request Broker Architecture)

Frameworks • “A framework is a partially complete software system that is intended to be instantiated. It defines the architecture for a family of systems and provides the basic building blocks to create them. ” [POSA 1]/pag. 396 • Defineste locurile unde se pot face insertii/adaptari la instantiere: hot spots / frozen spots • Instantierea: prin compunerea si subclasarea claselor furnizate de framework • Diferenta framework ↔ reference architecture: un framework este dat sub forma de cod, reference architecture nu • Diferenta framework ↔ biblioteca: la dezvoltarea unei aplicatii noi: – biblioteca: scrii main body si utilizezi elemente (functii, clase, etc) din biblioteca – framework: de obicei framework furnizeaza un main body predefinit, mai trebuie adaugate/concretizate unele elemente (functii, clase) pe care acesta le utilizeaza. “inversion of control”

De ce e importanta arhitectura software? • Pentru ca reprezinta: – Mijloc de comunicare intre stakeholders – Primele decizii de proiectare – Abstractizare transferabila a unui sistem

Arhitectura ca mijloc de comunicare intre stakeholders • Fiecare stakeholder este interesat de anumite caracteristici ale sistemului • Rolul proiectantului arhitecturii: gasirea strategiilor de a echilibra caracteristicile diferite si/sau contradictorii • Rolul arhitecturii: un limbaj comun in care se exprima, negociaza si rezolva aceste caracteristici – Arhitectura e suficient de abstracta ca sa poata descrie la un nivel general inteligibil un sistem complex – Arhitectura poat fi analizata din punct de vedere al principalelor caracteristici ale sistemului

Architectura ca decizie de proiectare • Defineste unele constrangeri privind implementarea • Influenteaza structura organizationala • Promoveaza anumite calitati ale sistemului (modifiability, performance, safety, security, etc) • Permite predictia calitatilor/proprietatilor sistemului • Permite estimarea costurilor si termenelor de realizare

Arhitectura ca model transferabil, reutilizabil • Reutilizarea arhitecturii - Software product lines • Arhitectura poate fi realizata utilizand componente dezvoltate independent de externi

Tipare si stiluri arhitecturale

Stiluri / tipare arhitecturale • Structurare: metode de descompunere controlata in subtaskuri cooperante – – Layers Pipes and Filters Blackboard; cu variantele Repository, Active Database Event-driven (Implicit Invocation); cu variantele Publisher-Subscriber, Event-Bus • Sisteme interactive: – Model-View-Controller – Presentation-Abstraction-Control • Sisteme distribuite: – Client-Server – Client-Dispatcher-Server – Broker • Sisteme Adaptabile: – Reflection – Microkernel

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: 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

Structura nivelurilor [POSA]-Fig/P. 35

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” • 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. • Stive comunicante [POSA]-Fig/P. 35, P. 37

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 B C • • 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 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: Exemplu de implementare • Exemplu de implementare in C++, folosind tehnici OO – [POSA 1]/pg. 42 • Vezi Layers. cpp • Observatie: Acesta este un EXEMPLU de implementare. Stilul Layers poate fi implementat si prin alte metode, iar utilizarea tehnicilor OO NU este obligatorie! • OO sau NON-OO este un detaliu de implementare, nu afecteaza stilul arhitectural

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 executa operatii care nu sunt cerute de nivelurile superioare

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 Au. Lait (Another Universal Language for Intermediate. Translation) 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

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 Citirea si producerea datelor trebuie facuta incremental, pentru a reduce latenta si a permite o eventuala procesare concurenta • Exemple discutie: Filtru Sumator, Filtru Sort – Tipuri de Filtre: • Active: corpul filtrului consta dintr-un ciclu continuu in care citesteproceseaza-scrie date • Pasive: activitatea lor este declansata explicit de filtrul precedent (push) sau de filtrul urmator (pull) • Etapele de procesare sunt legate prin fluxul de date din sistem • Pipes (conducte): – transporta fluxul de date intre 2 filtre consecutive – Realizeaza sincronizarea intre filtre active, prin bufferare – Implementarea unei conducte poate utiliza diferite tehnici: apel de functie, apeluri sistem pipe, etc.

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

Active Filter: Push/pull pipeline [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 | optau. Lait | au. Lait 2 SPARC > prog. exe • Exemplu de compilare si interpretare: Ø Mocha <prog. mocha | cup [POSA]-Fig/P. 65

Exemplu – implementarea de Filtre active pe threads Filter f 1 = new Filter. Source(); Filter f 2 = new Filter. T 1(); Filter f 3 = new Filter. T 2(); Filter f 4 = new Filter. Sink(); Pipe p 1 = new Pipe(f 1, f 2); Pipe p 2 = new Pipe(f 2, f 3); Pipe p 3 = new Pipe(f 3, f 4); new Thread(f 1). start(); new Thread(f 2). start(); new Thread(f 3). start(); new Thread(f 4). start(); F 2 R Tr 1 F 3 P 2 W out in Buf While (! in. end()) { Data. Item d=in. get(); d=do. Transform(d); out. put(d); } R Tr 2 W

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

Exemplu domeniu aplicatie: Signal processing&Virtual Instrumentation

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

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 • 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): In loc de a apela direct operatii ale altor elemente, un element difuzeaza evenimente. Alte elemente din sistem pot sa-si declare interesul (sa se inregistreze) pentru un tip de eveniment si sa asocieze o procedura cu acest tip de eveniment. Cand evenimentul are loc, sistemul invoca toate procedurile care au fost inregistrate pentru tipul acestuia. • Exemplu: Network Management System Managed Objects Router Hub Management System Console Paging

Varianta: Publisher-Subscriber • • Echivalent cu Observer Publisher=Subject Subscriber=Observer Toate elementele Subscriber sunt notificate de Publisher daca apar schimbari in starea acestuia

Publisher-Subscriber: Solutia • Publisher: – intretine o baza de date a tuturor componentelor care au subscris la el – Cand isi schimba starea, trimite o notificare tuturor Subscriberilor • Variante: – Publisher decide ce modificari in starea sa interna vor fi notificate Subscriber-ilor – Un obiect poate fi Subscriber la mai multi Publisheri – Un obiect poate fi implementat sa joace atat rol de Subscriber cat si de Publisher – Publisher poate trimite detaliile schimbarilor produse odata cu notificarea (model push) sau nu, lasand subscriber-ii sa le ceara daca le vor (model pull)

Publisher-Subscriber: Exemplu • Un Concrete Publisher nu are fixate din start identitatile obiectelor Concrete Subscriber care depind de actiunile sale – Este OK • Fiecare Concrete Subscriber trebuie sa cunoasca identitatea fiecarui Concrete Publisher ale carui actiuni il intereseaza, pentru a se inregistra la el. – pentru exemplul dat, acesta este un dezavantaj major, deoarece obiectele din retea care sunt de tipul Managed Objects (Hub-uri, Router-e, Noduri, etc) sunt foarte multe si pot sa apara si sa dispara in mod dinamic

Suport in limbaje de programare • Java: mecanismul Event-Listener (vezi exemplul rezolvat in Nw. Mng. java) • C#: mecanismul Event- delegate (vezi exemplul rezolvat in Nw. Mng. cs) public delegate void Subscriber (Fault. Event ev); Inlocuieste Interface Subscriber { Update(Fault. Event ev); } In interiorul Publisher: public event Subscriber subscribers; Inlocuieste Protected List subscribers; Ca urmare se genereaza automat membrii attach si detach , care se apeleaza prin operatorii supraincarcati += si -= pp. subscribers+=new Subscriber(Console. Msg);

Varianta: 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 Scenariu: 1. Concrete Subscriber se inregistreaza la Event Channel, specificand tipul de evenimente de care este interesat 2. Concrete Publisher anunta la Event. Channel producerea unui eveniment 3. Event. Channel determina ce Concrete Subscribers sunt interesati de acest eveniment 4. Event Channel ii informeaza pe acestia de evenimentul produs

Event Channel: Exemplu

Event Channel: Solutia generala [POSA]-Fig/P. 342