1 / 16

Relatia Tactici <-> Tipare arhitecturale

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

judah
Download Presentation

Relatia Tactici <-> Tipare arhitecturale

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Relatia Tactici <-> Tipare arhitecturale

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

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

  4. Relatia tipare <->tactici • Exemplu: identificati tacticile arhitecturale pentru Modifiability continute in tiparul arhitectural Layers

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

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

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

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

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

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

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

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

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

  14. Exemplu ADD: Automatizarea usii de garaj: Combinarea tacticilor intr-un pattern [Bass]-Fig.7.2

  15. Exemplu ADD: Automatizarea usii de garaj: Solutia arhitecturala Performance Critical Computation Non-Performance Critical Computation [Bass]-Fig.7.3

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

More Related