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

2. Sisteme interactive
Sisteme interactive: exista multe interactiuni cu utilizatorul, de obicei prin intermediul unei interfete grafice
Obiectiv: independenta intre implementarea functionalitatii si interfata grafica utilizata
De ce ? Pentru ca se presupune ca partea care implementeaza functionalitatea este mai stabila, iar partea de interfata utilizator mai mult afectata de customizari
Tipare arhitecturale:
Model-View-Controller
Presentation-Abstraction-Control

3. Model-View-Controller
Tiparul arhitectural MVC structureaza aplicatiile interactive in 3 componente: Model = nucleul continand functionalitatea si datele ; Views = afisarea informatiilor; Controllers = tratarea user input. User Interface = Views+Controllers. Tiparul implementeaza un mecanism de propagare a modificarilor care asigura consistenta intre User Interface si Model.
Exemplu problema: un sistem informatic de reprezentare a rezultatelor electorale.

4. Exemplu MVC MODEL VIEWS CONTROLLER [POSA]-Fig/P.125 INTERACTIUNI
UNIDIRECTIONALE
(Output)
INTERACTIUNI BIDIRECTIONALE
(Input+Output)
VIEWS
CONTROLLER
[POSA]-Fig/P.125

5. Structura MVC Controller= un ConcreteObserver avand in plus
anumite atributii speciale
[POSA]-Fig/P.129

6. MVC – Scenariu User Input
[POSA]-Fig/P.130

7. MVC – Scenariu initializare
[POSA]-Fig/P.131

8. Proprietati ale stilului MVC
Avantaje:
Multiple views of a model
Synchronized views
Pluggable views and controllers
Exchangeability of looks
Framework potential
Atentionari:
Potential for excessive number of updates
Connection between view and controller
Coupling of views and controllers to a model

9. Presentation-Abstraction-Control
Tiparul arhitectural PAC structureaza aplicatiile interactive sub forma unei ierarhii de agenti cooperanti. Fiecare agent raspunde de un anumit aspect al functionalitatii si consta din 3 componente: Presentation, Abstraction, Control. Aceste componente separa partea de interactiune cu utilizatorul de partea de nucleu functional si de partea de comunicare cu ceilalti agenti.
Exemplu problema: un sistem informatic de reprezentare a rezultatelor electorale (problema similara cu cea de la MVC).
Ce difera de MVC: metoda de abordare a dezvoltarii aplicatiei interactive pe baza de agenti
Agent = componenta care realizeaza o procesare a informatiei
Contine:
Structuri de date reprezentand starea sa
Event receivers si event transmitters
Procesor care trateaza si produce evenimente, actualizeaza starea

10. PAC: Formularea Problemei: Ierarhie de agenti
[POSA]-Fig/P.145

11. PAC - Structura
[POSA]-Fig/P.151

12. PAC – Structura agentilor
Fiecare agent este compus din 3 componente:
Presentation: interfata utilizator proprie agentului
Abstraction: modelul de date specifice agentului
Control:
conecteaza in interiorul agentului partea lui de Presentation de cea de Abstraction
Asigura comunicarea cu alti agenti
Ierarhie de agenti:
Top-level: Realizeaza functionalitatea sistemului
Abstraction: modelul global al datelor, independent de maniera de reprezentare
Control: coordoneaza ierarhia de agenti, autorizeaza sau nu in functie de context si agenti solicitanti anumite operatii asupra modelului
Presentation: acele parti din interfata utilizator care nu tin de un anume agent (de exemplu meniul comun aplicatiei)
Bottom-level: Entitati cu o semantica proprie bine definita, asupra carora actioneaza ujtilizatorul (chart-uri, spreadsheet)
Presentation: rezolva toate operatiile facute de utilizatori asupra lor (zoom, move chart)
Abstraction: model local al datelor; nu exista alti agenti care depind de acesta.
Control: intermediaza interactiunea dintre Presentation si Abstraction in cadrul agentului; comunica cu componenta de control a agentilor ierarhici superiori pentru schimb de date si evenimente.
Intermediate level:
Coordonare: mentinerea consistentei intre agentii de nivel inferior (ex: coordonedaza vederi multiple ale acelorasi date)
Composite

13. PAC – Exemplu structura BarChartAgent
[POSA]-Fig/P.153

14. PAC – Exemplu detaliere structura BarChartAgent
[POSA]-Fig/P.159

15. [POSA]-Fig/P.152

16. PAC – Exemplu scenariu Deschidere nou BarChart View
[POSA]-Fig/P.154

17. PAC – Exemplu scenariu Introducere noi date prin Spreadsheeet
[POSA]-Fig/P.155

18. Pasi de definire a unei arhitecturi PAC
Definirea modelului aplicatiei
Definirea strategiei de organizare a ierarhiei de agenti
Specificarea agentului top-level
Specificarea agentilor bottom-level
Specificarea agentilor intermediate-level care compun mai multi agenti bottom-level
Specificarea agentilor intermediate-level care coordonedaza agenti de nivel inferior
Separarea functionalitatii de interactiunea cu utilizatorul; Definirea componentelor Abstraction, Presentation si Control pentru fiecare agent
Realizarea mecanismului de comunicare intre agenti (parte a componentei de Control).
Composite Message – interfata uniforma, aceleasi 2 operatii pentru toate tipurile de comunicari (in interiorul agentului sau intre agenti).
Legarea agentilor intr-o ierarhie
POSA

19. Exemplu aplicatie PAC: Robot mobil
[POSA]-Fig/P.165

20. Exemplu aplicatie PAC: Network management
[POSA]-Fig/P.164

21. Proprietati ale stilului PAC
Avantaje:
Separation of concerns: concepte cu semantici diferite sunt reprezentate prin agenti separati
Support for change and extension: se pot face schimbari in partea de Abstraction sau Presentation a agentilor; Se pot introduce agenti noi
Support for multitasking/distributed computing
Atentionari:
Complexitatea sistemului
Complexitatea componentelor de control
Eficienta scazuta datorita overhead-ului de comunicare intre agenti
Aplicabilitate redusa la anumite categorii de aplicatii

22. Discutie: PAC vs MVC