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

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

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.

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

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

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

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

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

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

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

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

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

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

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

[POSA]-Fig/P.152

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

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

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

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

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

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

Discutie: PAC vs MVC