1. Stiluri si tipare arhitecturale fundamentale
Partea 1

2. 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
PART 1
POSA

3. Stilul arhitectural Layers
Bibliografie:
[POSA1] – in cap. 2.2
POSA

4. 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

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

6. 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.

7. 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)

8. 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

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

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

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

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

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

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

15. Layers: Scenarii de comportament
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

16. 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

17. 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

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

19. Posibilitati implementare callback

20. 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

21. 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!

22. 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

23. 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

24. Stilul arhitectural Pipes and Filters
Bibliografie:
[POSA1] – in cap. 2.2
POSA

25. 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

26. Alt exemplu: domeniu aplicatie: Signal processing&Virtual Instrumentation

27. 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

28. 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.

29. [POSA]-Fig/P.56

30. 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

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

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

33. 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

34. 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

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

36. Discutie: Pipes-and-Filters vs anumiti design patterns

37. Tiparul arhitectural Blackboard
Bibliografie:
[POSA1] – in cap. 2.2
POSA

38. 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

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

40. 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

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

42. 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

43. Scenariu exemplu
[POSA]-Fig/P.80

44. 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

45. 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

46. 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)!

47. 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

48. 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

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

50. 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 ?

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