Calitati si tactici arhitecturale

1. Calitati si tactici arhitecturale Bibliografie: Bass, Clements, Kazman: Software Architecture in Practice, Second edition, Addison Wesley, 2003. Chap: 4+5

2. Motivatie “Systems are frequently redesigned not because they are functionally deficient – the replacement are often functionally identical – but because they are difficult to maintain, port, or scale, or are too slow or have been compromised by network hackers.” [Bass – ch.4]

3. Functionality ↔ Quality Attributes Pentru o functionalitate data, deciziile arhitecturale influenteaza decisiv nivelul atributelor de calitate Functionality Q1 cu Arhit1 Quality Q2 cu Arhit2 Q3 cu Arhit3

4. Rolul arhitecturii • Arhitectura este factorul critic pentru realizarea multor atribute de calitate, DAR: • Asigurarea calitatilor necesare nu depinde numai de arhitectura: • Intervin si aspecte legate de proiectarea detaliata si implementare • Exemple: • Modifiability: determinata de structura modulelor (aspect architectural) si de tehnicile de codificare (ne-architectural) • Usability : depinde de stilul widget-urilor si layout-ul ecranelor (ne-architectural: proiectarea de detaliu) si daca sunt prevazute posibilitati de undo/cancel (aspect architectural: implica mai multe elemente care coopereaza pentru aceasta functie) • Proiectarea arhitecturala are in vedere luarea unor decizii de proiectare care sa permita asigurarea calitatilor dorite ale sistemului

5. Stakeholders Internal Metrics External Metrics Validation Verification Functional R. Requirements Engineering Design Implement. Design Product Qualities R. (Re)use tactics, strategies and patterns for achieving certain qualities Tactics Strategies Patterns

6. Probleme legate de asigurarea calitatii produselor software • Definirea unui model de calitate pentru produsele software • Cum asiguram un cadru unitar de discutie a atributelor de calitate? (ca toata lumea sa inteleaga acelasi lucru printr-un anumit atribut ?) • Identificarea de tactici arhitecturale pentru proiectarea ghidata de calitate • Se cunosc atributele dorite de calitate. Ce metode aplicate in faza de proiectare arhitecturala asigura obtinerea acestora ? • Definirea unor metrici care furnizeaza unitati de masura si metode de masurare a calitatilor software • Cum se masoara gradul in care produsul software isi indeplineste atributele de calitate • Standardul ISO/IEC 9126:1991-2001 (Software Engineering – Product Quality): specifica 1+3 • Standardele ISO/IEC 2500n:2005 (SQuaRE: Software Quality Requirements and Evaluation): inglobeaza varianta redefinita a lui 9126 • Quality attribute scenarios [Bass]: un mod de definire 1+3

7. Quality Attribute Scenarios Quality Attribute Scenario: mod de a caracteriza un atribut de calitate. Porneste de la premisa ca atributele de calitate se manifesta vizibil in anumite conditii (ca urmare a unor stimuli) sub forma raspunsului pe care il da produsul software la acesti stimuli. Metricile care evalueaza un atribut de calitate se bazeaza pe masurarea acestui raspuns. Tipuri de scenarii: Generale / Concrete [Bass] – fig.4.1.

8. Clase de atribute de calitate • System Qualities (ex: availability, modifyability, performance, security, testability, usability) • Business Qualities (ex: time to market, cost and benefit, projected lifetime, targeted market) • Qualities about the architecture itself (meta-qualities) (ex: conceptual integrity, buildability)

9. Availability • Availability: caracterizeaza comportamentul sistemului in cazul aparitiei unor situatii de Fault sau Failure • Fault = O situatie de eroare sau neprevazuta. Utilizatorul nu vede un Fault. • Failure = System is unavailable. Poate apare ca urmare a unui Fault neinterceptat corect, care devine vizibil utilizatorului prin Failure-ul provocat. • Degrees of availability: daca in urma unui Failure, numai anumite functii ale sistemului sunt reduse • Availability=probabilitatea ca sistemul sa fie operational cand e nevoie de el:

10. Scenariu concret: Exemplu Availability [Bass] – fig.4.3. Exemplu: Un scenariu concret pentru availability: An unanticipated external message is received by a process during normal operation. The process informs the operator of the receipt of the message and continues to operate with no downtime

11. Scenariu general: Definire Availability [Bass] – fig.4.2. Exemplu: Scenariu general pentru availability

12. General Scenario for Availability [Bass] – Table 4.1.

13. Modifiability • Modifiability: caracterizeaza sistemul din punct de vedere al efortului (costului) necesar realizarii unor schimbari • Principalele probleme: • Ce se schimba ? Functionalitatea sistemului, calitatile non-functionale, platforma (HW, SO), mediul (sistemele cu care coopereaza, protocoalele de comunicatie) • Cand se face schimbarea? Implementare, compilare, configuration setup, executie • Cine face schimbarea ?

14. Exemplu modifiability [Bass] – fig.4.4. Exemplu: Un scenariu concret pentru modifyability: A developer wishes to change the user interface. The change will be made to the code at design time, it will take less than 3 hours to make and test the change, and no side-effects will occur in the behaviour

15. General Scenario for Modifiability [Bass] – Table 4.2.

16. Performance • Performance: se masoara prin diverse metrici de Timing: • Events, interrupts, messages, requests… • Measuring time between arrival and response • Complicat de numarul mare de posibile secvente si combinatii de evenimente diferite • Patterns of arrival for events: • Periodic • Stochastic • Sporadic • Metrici de caracterizare a performantei: • Latency • Deadlines in processing • Throughput • Jitter of response • Miss rate, Data loss

17. Exemplu Performance [Bass] – fig.4.5. Exemplu: Un scenariu concret pentru performance: Users initiate 1000 transactions per minute stochastically under normal operations, and these transactions are processed with an average latency of two seconds

18. General Scenarios for Performance [Bass] – Table 4.3.

19. Security • Security: capacitatea unui sistem de a impiedica accesul neautorizat (accidental sau deliberat) la programe sau date, permitand in acelasi timp accesul autorizat la acestea • Proprietati care caracterizeaza security: • Nonrepudiation • Confidentiality of data from unauthorized access • Integrity (delivered as intended) • Assurance of identity • Availability for authorized use • Auditing

20. Exemplu Security [Bass] – fig.4.6. Exemplu: Un scenariu concret pentru security: A correctly identified individual tries to modify system data from an external site; system maintains an audit trail and the correct data is restored within one day

21. Security General Scenarios [Bass] – Table 4.4.

22. Testability • Cat de usor este sa detectezi fault-urile in sistem? • Testability: presupunand ca software-ul contine cel putin un fault, testability se defineste prin probabilitatea ca acest fault sa fie identificat la urmatoarea rulare. => alte metrici

23. Exemplu Testability [Bass] – fig.4.7. Exemplu: Un scenariu concret pentru testability: A unit tester performs a unit test on a completed system component that provides an interface for controlling its behaviour and observing its output; 85% path coverage is achieved within 3 hours

24. General Scenarios for Testability [Bass] – Table 4.5.

25. Usability • Cat de usor este pentru utilizator sa foloseasca software-ul ? • Invatarea facilitatilor sistemului • Utilizarea eficienta a sistemului • Minimizarea impactului erorilor

26. Exemplu usability [Bass] – fig.4.8. Exemplu: Un scenariu concret pentru usability: A user, wanting to minimize the impact of an error, wishes to cancel a system operation at runtime. Cancellation takes place in less than one second.

27. General Scenarios for Usability [Bass] – Table 4.6.

28. Rolul Scenariilor in Comunicare • Fiecare atribut are propria “comunitate”, cu propriul vocabular: => acelasi stimul apare sub denumiri diferite in scenarii pentru atribute diferite

29. Business Qualities • Time to Market: reutilizare, COTS, => structura modulelor • Cost and Benefit: flexibilitate -> cost; tehnologie noua -> cost. • Projected Life of the System: modifyability, scalability, portability: cresc durata de viata dar si time to market. • Targeted Market: colectie de produse inrudite -> in-house reuse

30. Architectural Qualities • Conceptual Integrity: unitatea design-ului: ”do similar things in similar ways” • Buildability: masurata in cost si timp

31. ISO 9126 / ISO SQuaRE Quality model

32. Tactici arhitecturale Asigurarea calitatilor dorite ale produsului software in timpul proiectarii arhitecturale

33. Tactici arhitecturale • Tactic = Fundamental design decisions that impart desired quality attributes to a design [Bass] Tactics to control Response

34. Tactici, strategii, tipare • Fiecare tactica arhitecturala reprezinta o optiune elementara din timpul proiectarii arhitecturale • Uneori tacticile nu sunt independente: Alegerea unei tactici pentru rezolvarea unei cerinte de calitate poate implica necestitatea de a utiliza anumite alte tactici: • Exemplu: cerinta “high availability” => o posibila tactica este cea de “redundancy”. Pentru implementarea redundantei => este nevoie de sincronizare (intre original si copiile redundante). • Ierarhii de tactici: • Exemplu: tactica “redundancy” poate fi rafinata in “redundancy of data” sau “redundancy of control” • Un pattern arhitectural reprezinta un “pachet” format din mai multe tactici: • Exemplu: un pattern pentru a asigura availability cuprinde tactici concrete de redundancy si de synchronization

35. Availability Tactics • Scop: Impiedica un fault sa provoace un failure, sau cel putin asigura mecanisme prin care se poate repara • Fault Detection • Cum se recunoaste un fault ? • Fault Recovery • Ce se intampla daca apare un fault ? • Fault Prevention • Cum se poate evita producerea unui fault?

36. Availability: Fault Detection • Ping/Echo • Heartbeat/Watchdog • Exceptions

37. Availability: Fault Recovery • Prevention and Repair • Voting • Active Redundancy (Hot restart) • Passive Redundancy (Warm restart) • Spare • Reintroduction • Shadow operation • State resynchronization • Checkpoint/Rollback

38. Availability: Fault Prevention • Removal from service to prevent failures • Transactions

39. [Bass] – fig.5.3

40. Exemplu: vezi studiul de caz “Air Traffic Control” pentru identificarea tacticilor utilizate pentru availability

41. Modifiability Tactics • Scop: Minimizarea timpului si costului necesar pentru realizarea schimbarilor • Localize modifications • Minimizarea numarului de module care sunt afectate de o schimbare • Prevent ripple effects • Limiteaza modificarile la modulele direct afectate. • Un modul se considera “direct afectat” daca schimbarile vizeaza responsabilitatile sale. Alte module, ale caror responsabilitati nu se schimba, este de dorit sa nu trebuiasca modificate • Defer binding time • Amana unele decizii lasand loc pentru modificari facute de non-developeri

42. Modifiability: Localize Modifications • Maintain semantic coherence: • Metrici: Coupling, cohesion => trebuie sa aiba in vedere si posibilele extinderi • Abstract common services • Anticipate expected changes: • Pentru schimbarile care se pot anticipa, care sunt modulele afectate de acestea? => test de verificare pentru punctul anterior • Generalize the module • De la simpla parametrizare pana la input language • Limit possible options • Variation points

43. Modifiability: Prevent Ripple Effect Ripple effect: necesitatea de a schimba module care nu sunt direct afectate: se schimba modulul A, pentru ca dorim o modificare in una din responsabilitatile sale. Modulul B se schimba doar pentru ca s-a schimbat implementarea lui A = Ripple Effect. Modulul B depinde de A: diferite tipuri de dependenta: • Sintaxa datelor sau operatiilor • Semantica datelor sau operatiilor • Secventierea datelor sau operatiilor • Identitatea (nume sau referinta) interfetelor lui A • Locatia lui A • Calitatea serviciilor/datelor furnizate de A • Existenta lui A • Resursele consumate de A Tactici: • Hide information • Maintain existing interfaces: daca dependenta e de tip sintaxa a operatiilor; • Adapter, stub • Restrict communication paths: limiteaza locurile unde interactioneaza producatorii/consumatorii de date • Use an intermediary: • Repository: sintaxa datelor • Façade, mediator: sintaxa operatiilor • Broker: identitatea interfetelor • Name server: locatia

44. Modifiability: Defer Binding Time • Runtime registration: • Plug-and-play • Publish-subscribe • Configuration files • Parametri pentru start-up • Polymorphism • Permite legarea tarzie pentru apelurile metodelor • Adherence to defined protocols • Permite comunicarea in timpul executiei intre procese decuplate

45. [Bass] – fig.5.5.

46. Exemplu: vezi studiul de caz “Air Traffic Control” pentru identificarea tacticilor utilizate pentru modifiability

47. Performance Tactics • Scop: Asigurarea faptului ca sistemul da raspunsul la un eveniment intr-un interval de timp determinat • Timpul de raspuns este dat de: • Resource consumption: • prin resurse se inteleg: procesoare, unitati de stocare de date, retele de comunicatii, buffere, etc. => fiecare introduce o anumita intarziere • Blocked time: • Contention for resources: mai multe procese isi disputa o resursa => cererile lor trebuie arbitrate • Availability of resources: o anumita resursa poate fi unavailable o perioada de timp, timp in care procesul care o solicita e blocat • Dependency on others: se asteapta rezultate produse de alte procese • Categorii de tactici: • Resource demand • Resource management • Resource arbitration

48. Performance: Resource Demand • Resource demand: caracterizata de cat de des apar cererile si cate resurse se consuma per cerere. • Reduce the resources required per event • Increase computational efficiency => resursa va fi blocata pentru mai putin timp • Reduce computational overhead => de exemplu elimina intermediarii • Reduce the number of events processed • Manage event rate: daca este posibil, reduce frecventa cererilor • Control frequency of sampling: reduce frecventa cu care sunt tratate cererile • Control the use of resources • Bound execution times: limite maxime impuse tratarii unui eveniment • Bound queue sizes

49. Performance: Resource Management and Arbitration • De aplicat si in cazurile in care caracteristicile cererilor pentru resurse nu pot fi controlate • Management • Introduce concurrency: evenimente diferite procesate in thread-uri diferite • Maintain multiple copies of data or computation: date tinute in cache-uri, calcule efectuate in regim clients-server sau master -slaves • Increase available resources • Arbitration • Implement scheduling policy: diferite strategii de arbitrare in cazul in care mai multe procese solicita simultan aceeasi resursa: • FIFO • Pe baza de prioritati statice • Pe baza de prioritati dinamice

50. [Bass] – fig.5.7.