160 likes | 345 Views
Relatia Tactici <-> Tipare arhitecturale. Tactici <-> Tipare. Un Tipar arhitectural ( architectural pattern) este alcatuit dintr-un grup de tactici Tacticile care formeaza un tipar adreseaza de regula mai multe atribute de calitate diferite
E N D
Tactici <-> Tipare • Un Tipar arhitectural ( architectural pattern) este alcatuit dintr-un grup de tactici • Tacticile care formeaza un tipar adreseaza de regula mai multe atribute de calitate diferite • De obicei, exista un grup de tactici “dominante” care adreseaza atributele de calitate vizate in mod special de tipar, plus altele care vin “la pachet” • O anumita implementare particulara a unui tipar poate adauga in plus tactici noi • Avantajele cunoasterii tacticilor: • Intelegerea incompatibilitatilor intre anumite atribute de calitate • Intelegerea impactului unor tactici “ascunse” intr-un “pachet de tactici” utilizat sub forma unui pattern • Proiectarea arhitecturala prin metoda Attribute-Driven Design (ADD)
Incompatibilitati intre atribute de calitate • Exemple de cerinte a caror realizare poate genera conflicte: • Modifyability vs Performance • Cost vs Reusability • Security vs Availability • “We want them all!” -> nu e practic posibil • E nevoie de o prioritizare a cerintelor / negocierea unor valori de compromis intre ele
Relatia tipare <->tactici • Exemplu: identificati tacticile arhitecturale pentru Modifiability continute in tiparul arhitectural Layers
Exemplu: Tactici pentru Modifiability in tiparul Layers • “Semantic Coherence”: fiecare layer reprezinta un grup de servicii inrudite • “Abstract Common Services”: serviciile comune pentru nivelele superioare sunt localizate in nivelele inferioare • “Hide Information”: Fiecare nivel exporta serviciile vizibile in interfata sa • “Restrict Communication Paths”: Fiecare nivel are voie sa acceseze doar serviciile din nivelul situat imediat sub el • “Use an Intermediary”: Este posibil ca un anumit nivel sa actioneze cu rol de intermediar (Façade) pentru adaptarea interactiunilor intre alte niveluri Pentru varianta “Relaxed Layered System”: • Dispare (se slabeste) “Restrict Communication Paths”: Fiecare nivel are voie sa acceseze servicii din toate nivelurile de sub el => creste cuplarea intre niveluri Pentru varianta “Layering Through Inheritance”: • Dispare “Hide Information”: Nivelurile inferioare nu mai sunt ascunse pentru nivelurile superioare, care le mostenesc
Relatia tipare<->tactici • Exemplu: identificati tacticile arhitecturale cuprinse in tiparul Active Object • “The Active Object pattern decouples method execution from method invocation to enhance concurrency and simplify synchronized access to an object that resides in its own thread of control” [POSA2]
Exemplu: Tactici cuprinse in tiparul Active Object Tactici intrinseci tiparului Active Object: • “Introduce concurrency” (performance): constituie scopul fundamental declarat al tiparului: permite ca mai multi clienti din fire de executie diferite sa acceseze in mod concurent metode ale unui obiect.(realizat prin Activation Queue + Scheduler) • “Intermediary” (modifiability): Proxy este intermediarul care ascunde modificarile privind modul in care se construiesc MethodRequest • “Binding time” (modifiability): Serverul primeste invocarile metodelor sale la runtime • “Scheduling policy” (performance): Scheduler-ul poate implementa diferiti algoritmi de planificare (scheduling) prin care decide ordinea in care ia invocarile din Activation Queue si le trimite la server Implementarea Active Object poate introduce noi tactici: • “Maintain an audit trail” (support recovery – availability)
Patterns: dezavantajul tacticilor “la pachet” – Exemplu: Iterator • Iterator pattern: • Permite prelucrarea uniforma a diferitor colectii de elemente • Avantaje: flexibilitate, transparenta • Problema cu iterator pattern: • Ar putea fi implementat si pe obiecte la distanta: Obiectul colectie este referinta unui obiect la distanta Iterator i =colectie.iterator(); while (i.hasNext()) { element =i.next(); // proceseaza element }
Dezavantaj: Consecinte negative asupra performantei in cazul in care Clientul si Colectia sunt distribuiti ! Timpul necesar pentru transmiterea unui mesaj la distanta fata de transmiterea unui mesaj local: Raport aprox 100 ! Varianta mai buna din punct de vedere al performantei: se transfera toate elementele colectiei odata, intr-un singur mesaj, fara a folosi Iterator Patterns: dezavantajul tacticilor “la pachet” – Exemplu: Iterator (cont.)
Attribute Driven Design (ADD) • Metoda de proiectare arhitecturala: • Input: porneste de la cerintele functionale si non-functionale, exprimate sub forma de Quality Attributes Scenarious • Architectural Drivers: cerintele sunt prioritizate, cele mai importante dintre acestea determina in primul rand arhitectura • Knowledge: Tactici pentru realizarea atributelor de calitate • Output: Proiect arhitectural care creaza premisele unui sistem cu atributele dorite
Exemplu ADD: Automatizarea usii de garaj • Exemplu: garage door opener [Bass] • Familie de sisteme pentru automatizarea manevrarii usilor de garaj, prin comanda de la: buton local, telecomanda, sau home information system • Input: Quality Attribute Scenarios: • Controlerul pentru manevrarea usii este diferit in fiecare sistem, in functie de modul concret de comanda. Arhitectura pentru o combinatie specifica de moduri de control trebuie sa fie direct derivabila din arhitectura familiei de sisteme • Procesoarele utilizate pentru fiecare sistem pot fi diferite. Portabilitatea trebuie asigurata prin arhitectura familiei de sisteme • Daca sesizeaza un obstacol in calea usii, in timpul manevrei de coborare a usii, trebuie sa opreasca manevra in cel mult 0.1secunde • Controlerul pentru manevrarea usii trebuie sa poate fi accesibil pentru administrare din home information system • Architectural Drivers: • Real-time performance • Modifiability to support a system family (product line) • Dupa cum s-a prezentat anterior, performance si modifiability sunt de obicei greu de combinat !
Exemplu ADD: Automatizarea usii de garaj: Architectural Drivers si Tactici • Tacticile adecvate pentru rezolvarea scenariilor de modifiability: • Modifiability: este necesara • modifiability la design time => • tactica primara este din categoria • “localize changes”. • Tactici de folosit: • Semantic Coherence • Information hiding • Tipar rezultat: descompune in module • si utilizeaza Virtual Machines • Descompunere in module dupa • functionalitate: UserInterface, • Comunicare, Senzori. • Fiecare modul poate varia
Exemplu ADD: Automatizarea usii de garaj: Architectural Drivers si Tactici • Tacticile adecvate pentru rezolvarea scenariilor de performance: • Performance: este necesara • performanta de tip real-time la • anumite operatii => • Tactici de folosit: • Increase computational efficiency • Scheduling policy
Exemplu ADD: Automatizarea usii de garaj: Combinarea tacticilor intr-un pattern [Bass]-Fig.7.2
Exemplu ADD: Automatizarea usii de garaj: Solutia arhitecturala Performance Critical Computation Non-Performance Critical Computation [Bass]-Fig.7.3
Exemplu ADD: Automatizarea usii de garaj:Verificarea si Rafinarea Quality Attribute Scenarios • Controlerul pentru manevrarea usii este diferit in fiecare sistem din familie, in functie de modul concret de comanda. => modulul User Interface • Procesoarele utilizate pentru fiecare sistem pot fi diferite. Portabilitatea trebuie asigurata prin arhitectura familiei de sisteme => toate modulele: nu se utilizeaza facilitati specifice unui anumit procesor sau nesuportate de compilatoare standard • Daca sesizeaza un obstacol in calea usii, in timpul manevrei de coborare a usii, trebuie sa opreasca manevra in cel mult 0.1secunde => modulul Scheduler, modulul Obstacle Detection • Controlerul pentru manevrarea usii trebuie sa poate fi accesibil pentru administrare din home information system => modulele Diagnosis, Communication Virtual Machine