Stiluri si tipare arhitecturale fundamentale

Stiluri si tipare arhitecturale fundamentale

Stiluri arhitecturale fundamentale
Continutul cursului si bibliografie: Layers [POSA1] – in 2.2 Pipes and Filters Blackboard; cu variantele Repository, Active Database Event-driven (Implicit Invocation); cu variantele Publisher-Subscriber, Event- Bus [POSA1] – 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) Bibliografie generala optionala: David Garlan, Mary Shaw, An Introduction to Software Architecture, online POSA

Stilul arhitectural Layers
Bibliografie: [POSA1] – in cap. 2.2 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 - 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 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

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

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

Layers: Scenarii de comportament
Top-down communication Bottom-up communication POSA pag 36

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

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” POSA pag 36

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

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. Trebuie realizata prin callback ! Acest mecanism realizeaza un flux ascendent de date si control, dar fara a rezulta relatii Uses de tip ascendent POSA pag 36

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 A FA B FB Clements 85-86

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 DomainLogic uses GenericUtilities Clements 85-86

Exemplu situatie callback
StudentAdministration main compare GenericUtilities sort Clements 85-86

Posibilitati implementare callback

Layers: Pasi de definire a unei arhitecturi pe nivele
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

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

Stilul arhitectural Pipes and Filters

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. 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 60 [POSA]-Fig/P.60

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 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 anumiti design patterns

Tiparul arhitectural Blackboard

Blackboard Blackboard: tipar adecvat problemelor in care mai multe subsisteme specializate, independente, contribuie la gasirea unei solutii, lucrand pe date comune (accesibile tuturor inmod egal) 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
Varianta hibrida, rezultata din combinatia cu stilul event-driven 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; dispare ciclul de control extern in care KS testeaza execCondition() (se muta in active database)!

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

Stilul arhitectural Event-driven (Publisher-Subscriber, Event Bus)
Bibliografie: [POSA1] – din cap. 3.6 S. Gupta, J. Hartkopf, S. Ramaswamy: Event Notifier, a Pattern for Event Notification, in Java Report, (republished as chapter 11 in the book More Java Gems, Cambridge University Press, 2000) POSA

Stilul arhitectural Event-driven
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. Definitioa din Garlan&Shaw – Intro to SwArch Exemplu din Event Notifier, a Pattern for Event Notification, Gupta, Hartkopf, Ramaswamy, Java Report 1998 Event Service op Obj1 op Obj2 Obj1 Obj2 Explicit invocation Implicit invocation

Stilul arhitectural Event-driven
Componentele unei aplicatii nu interactioneaza direct unele cu altele, ci prin invocare implicita Interactiunea implicita este facilitata de o infrastructura de Event Service Interactiunea prin invocare implicita poate avea loc in variantele (dupa tiparele): Publisher/Subscriber simplu (direct) Event Channel (Event Bus)

Event Channel - Structura
Publisher Publisher Subscriber Subscriber Event Channel (Event Bus) Publisher Publisher Subscriber Subscriber Publish Event Receive Event

Event Channel - Descriere
Elementul central = tipurile de Evenimente Exista componente care produc evenimente, dar nu cunosc identitatea componentelor care vor “consuma” aceste evenimente (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)

Structura unei aplicatii Event-Driven
Componente (Elemente): Publishers, Subscribers Connectori (Relatii): publish event, subscribe to event type Infrastructura: Event Channel (Event Bus). De obicei nu face parte din aplicatie ! Publisher Publisher Subscriber Subscriber Event Channel (Event Bus) Publisher Publisher Subscriber Subscriber

Infrastructura Event Channel (Event Bus): EventChannel: subscribe(Subscriber, Event); publish(Event) Subscriber: notify(Event) Publisher Publisher Subscriber Subscriber Event Channel (Event Bus) Publisher Publisher Subscriber Subscriber

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 Push data Notifier Publish Event Receive Event Data Transfer

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

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

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

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

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

Exemplu problema: Network Management System
Managed Objects Management System Router Hub Console Paging Definitioa din Garlan&Shaw – Intro to SwArch Exemplu din Event Notifier, a Pattern for Event Notification, Gupta, Hartkopf, Ramaswamy, Java Report 1998 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, . Fiecare element din management system poate fi configurat sa urmareasca anumite categorii de evenimente

Exemplu problema - continuare
Pentru rezolvarea problemei de Network Management in stil Event-driven, se utilizeaza o infrastructura de tip Event Service (EventBus) care ofera un API cu urmatoarele facilitati: subscribe publish inform - in orice Subscriber Managed Objects: Publishers Management System: Subscribers

Tipuri de Evenimente:

Un Subscriber: public class PagingSystem extends Subscriber { public PagingSystem() { FaultEvent event = new FaultEvent(); CriticalFaultFilter filter = new CriticalFaultFilter(); EventService.instance().subscribe(filter.getClass(), filter, this); } public void inform(Event event) { // Assumes that this subscriber has only subscribed to FaultEvent FaultEvent faultEvent = (FaultEvent) event; // Respond to the event System.out.println("Critical Fault Event occurred:" + faultEvent); } }

Un Publisher: public class Router { public static void triggerPublication() { Event event = new FaultEvent(FaultEvent.CRITICAL); EventService.instance().publish(event); } }

Exemple de infrastructuri Event Service
Publisher-Subscriber direct: Mecanisme incorporate in unele limbaje de programare: Java: Event - Listener C#: Event – delegate Mecanismul Callback, tiparul Observer Event Bus intra-proces: Guava (Google Core Libraries for Java) Event Bus: Jeff Hartkopf Event Notifier: Event Channel (Event Bus) incorporat in infrastructuri (middleware) pentru aplicatii distribuite (mesaje intre procese diferite): Java Message Service (JMS) Corba Event Service

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

Cum se poate implementa o infrastructura de tip Event Bus ?
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)

Exemplu de implementare a unui Event-Bus simplu intra-proces
Punct de pornire: exemplul Network Management System Managed Objects Management System Router Hub Console Paging

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 Notification) afecteaza toate Managed Objects

Exemplu Network Management: Solutie tip Mediator
Managed Objects Management System Orice schimbare/adaugare in Management System (exemplu: adaugare 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
Publisher Subscriber Managed Objects Management System EventChannel Hub Console Router 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 lor 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 EventChannel producerea unui eveniment EventChannel 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]
EventService: intermediaza transmiterea de evenimente intre publisher si subscriber Publisher (Hub, Router): emite evenimente Subscriber: interfata pentru toti consumatorii de evenimente ConcreteSubscriber (Console, Pager): subscrie la EventService 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 ConcreteSubscriber poate fi interesat de un anumit tip de evenimente – de exemplu FaultEvent, 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 isKindOf 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 EventServices, fiecare specializat intr-o anumita categorie de evenimente Facilitati optionale: Advertisment and Discovery of available Event Types

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

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 , Analizeaza probleme diferite din punctul de vedere al avantajelor/dezavantajelor aduse solutiei de aplicarea unui anumit stil arhitectural Laborator: problema “Fabrica de mobila”

Laborator 1 “Fabrica de mobila”
Stilul arhitectural ales influenteaza proprietatile solutiei ! P&F BB Events Pot diversifica productia ? Doar la startup Da, la runtime Pot angaja muncitori noi ? Pot schimba procesul tehnologic ? Aplicatia poate fi testata usor ? Concurenta se realizeaza usor ? Concurenta este eficienta ? Aplicatia este eficienta ?

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: Shared Database (Repository): Pipes and Filters: Messaging (Event-Driven)

Stiluri si tipare arhitecturale fundamentale

Similar presentations

Presentation on theme: "Stiluri si tipare arhitecturale fundamentale"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Stiluri si tipare arhitecturale fundamentale

Similar presentations

Presentation on theme: "Stiluri si tipare arhitecturale fundamentale"— Presentation transcript:

Similar presentations

About project

Feedback