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

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]

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

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

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

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

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.

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)

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:

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

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

General Scenario for Availability [Bass] – Table 4.1. Source Internal to the system; external to the system Stimulus Fault: omission, crash, timing, response Artifact What should be available ? System's processors, communication channels, persistent storage, processes Environment State/mode of the system: Normal operation; degraded mode (i.e., fewer features, a fall back solution) Response System should detect event and do one or more of the following: record it notify appropriate parties, including the user and other systems disable sources of events that cause fault or failure according to defined rules be unavailable for a prespecified interval, where interval depends on criticality of system continue to operate in normal or degraded mode Response Measure Time interval when the system must be available Availability time Time interval in which system can be in degraded mode Repair time

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 ?

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

General Scenario for Modifiability [Bass] – Table 4.2. Source End user, developer, system administrator Stimulus Wishes to add/delete/modify/vary functionality, quality attribute, capacity Artifact System user interface, platform, environment; system that interoperates with target system Environment At runtime, compile time, build time, design time Response Locates places in architecture to be modified; makes modification without affecting other functionality; tests modification; deploys modification Response Measure Cost in terms of number of elements affected, effort, money; extent to which this affects other functions or quality attributes

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

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

General Scenarios for Performance [Bass] – Table 4.3. Source where does the event come from? One of a number of independent sources, possibly from within system Stimulus characterize arrival: Periodic events arrive; sporadic events arrive; stochastic events arrive Artifact System Environment System mode: Normal mode; overload mode Response Processes stimuli; changes level of service Response Measure Latency, deadline, throughput, jitter, miss rate, data loss

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

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

Security General Scenarios [Bass] – Table 4.4. Source Individual or system that is: correctly identified/ identified incorrectly/ of unknown identity who is: internal/external, authorized/not authorized with access to: limited resources/ vast resources Stimulus The attack: Tries to: display data, change/delete data, access system services, reduce availability to system services Artifact System services; data within system Environment Either: online or offline, connected or disconnected, firewalled or open Response Authenticates user; hides identity of the user; blocks access to data and/or services; allows access to data and/or services; grants or withdraws permission to access data and/or services; records access/modifications or attempts to access/modify data/services by identity; stores data in an unreadable format; recognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of services Response Measure Time/effort/resources required to circumvent security measures with probability of success; probability of detecting attack; probability of identifying individual responsible for attack or access/modification of data and/or services; percentage of services still available under denial-of-services attack; restore data/services; extent to which data/services damaged and/or legitimate access denied

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

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

General Scenarios for Testability [Bass] – Table 4.5. Source Who performs test: Unit developer/ Increment integrator / System verifier / Client acceptance tester / System user Stimulus What triggers testing: Analysis, architecture, design, class, subsystem integration completed; system delivered Artifact Piece of design, piece of code, complete application Environment Time at which test occurs: At design time, at development time, at compile time, at deployment time Response Provides access to state values; provides computed values; prepares test environment Response Measure Percent executable statements executed Probability of failure if fault exists Time to perform tests Length of longest dependency chain in a test Length of time to prepare test environment

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

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.

General Scenarios for Usability [Bass] – Table 4.6. Source End user Stimulus Wants to: learn system features / use system efficiently / minimize impact of errors/ adapt system / feel comfortable Artifact System Environment At runtime or configure time Response System provides one or more of the following responses: to support "learn system features“: help system is sensitive to context; interface is familiar to user; interface is usable in an unfamiliar context to support "use system efficiently": aggregation of data and/or commands; re-use of already entered data and/or commands; support for efficient navigation within a screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities to "minimize impact of errors": undo, cancel, recover from system failure, recognize and correct user error, retrieve forgotten password, verify system resources to "adapt system": customizability; internationalization to "feel comfortable": display system state; work at the user's pace Response Measure Task time, number of errors, number of problems solved, user satisfaction, gain of user knowledge, ratio of successful operations to total operations, amount of time/data lost

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

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

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

ISO 9126 / ISO SQuaRE Quality model

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

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

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

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?

Availability: Fault Detection Ping/Echo Heartbeat/Watchdog Exceptions

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

Availability: Fault Prevention Removal from service to prevent failures Transactions

[Bass] – fig.5.3

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

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

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

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

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

[Bass] – fig.5.5.

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

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

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

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

[Bass] – fig.5.7.

Security Tactics Resisting attacks Detecting attacks Recovering from attacks

Security: Resisting Attacks Authenticate users Authorize users Maintain data confidentiality (encryption) Maintain integrity (checksums) Limit exposure Limit access

Security: Detection and Recovery Intrusion detection systems Recovery State restoration (availability) Attacker identification (maintain an audit trail)

[Bass] – fig.5.9.

Testability Scop: inlesnirea testarii incrementale Providing Input and capturing Output Record & play back Separate interface from implementation Specialize access routines/interfaces Internal monitoring Built-in monitors

[Bass] – fig.5.11.

Usability Runtime => for the End User Separate user interface Support user initiative Cancel, undo, aggregate Support system initiative User model, System model, Task model Design Time => for the Designer Separate UI from rest of design

[Bass] – fig.5.13.

Studiu de caz: Controlul traficului aerian (ATC) ISSS (Initial Sector Suite System) Tower Ground Control Airport B Air Route Center 4 Air Route Center 1 Tower Ground Control Air Route Center 2 Air Route Center 3 Airport A

Exemplu ISSS: Architecture Business Cycle [Bass] – fig.6.3.

Exemplu ISSS: Requirements & Qualities Cerinte esentiale: Ultrahigh availability: availability requirement = 0.99999: mai putin de 5 minute pe an timp cumulat in care este unavailable. Sunt permise failures din care sistemul isi reia functionarea normala in mai putin de 10 secunde. High performance: sistemul trebuie sa poata procesa pana la 2,440 avioane fara sa “piarda” niciunul. Un Air Route Center are are pana la 210 console si pana la 40 de radare; Retelele de comunicatie trebuie sa poata asigura comunicatiile necesare iar software-ul trebuie sa poata efectua calculele la timp si in mod predictibil. Alte cerinte: Openness: sistemul trebuie sa poata integra unele componente comerciala dezvoltate separat Incremental development-deployment: dezvoltarea de subseturi functionale incrfemental (posibilitatatea de a abandona pe parcurs anumite functionalitati, in caz de reduceri bugetare) Modifyability: Posibilitatea de a face modificari in functionalitate si de a permite upgrade hardware/software (noi procesoare, noi dispozitive I/O, noi versiuni ale compilatorului Ada) Interoperability: Capacitatea de a interopera cu sisteme foarte diverse, unele legacy altele dedicate noi in faza de proiectare

Exemplu ISSC: Functionalitatea ISSS system must do the following [Bass]: “Acquire radar target reports that are stored in an existing ATC system called the Host Computer System. Convert the radar reports for display and broadcast them to all of the consoles. Each console chooses the reports that it needs to display; any console is capable of displaying any area. Handle conflict alerts (potential aircraft collisions) or other data transmitted by the host computer. Interface to the Host for input and retrieval of flight plans. Provide extensive monitoring and control information, such as network management, to allow site administrators to reconfigure the installation in real time. Provide a recording capability for later playback. Provide graphical user interface facilities, such as windowing, on the consoles. Special safety-related provisions are necessary, such as window transparency to keep potentially crucial data from being obscured. Provide reduced backup capability in the event of failure of the Host, the primary communications network, or the primary radar sensors.”

Exemplu ISSC: Structura hardware Spare Passive redundancy Redundant pair [Bass] – fig.6.5.

Exemplu ISSC: Structura modulelor Semantic coherence Module: Computer Software Configuration Items (CSCIs) 5 Modules with carefully designed interfaces: Display Management: responsible for producing and maintaining displays on the common consoles. Common System Services: responsible for providing utilities generally useful in air traffic control software—recall that the developer was planning to build other systems under the larger AAS program. Recording, Analysis, and Playback: responsible for capturing ATC sessions for later analysis. National Airspace System Modification: entailing a modification of the software that resides on the Host The IBM AIX operating system: providing the underlying operating system environment for the operational software. Anticipation of expected changes Abstract common services Record/ playback

Exemplu ISSC: Structura proceselor Passive redundancy State resynch. Shadowing Heartbeat [Bass] – fig.6.6.

Exemplu ISSC: Structura interactiunilor Adherence to defined protocols Component replacement Maintaining interface stability [Bass] – fig.6.7.

Exemplu ISSC: Code templates Abstract common services Anticipation of expected change Adherence to defined protocols Conceptual integrity [Bass] – fig.6.10.

Exemplu ISSS: Tactici utilizate Table 6.1. How the ATC System Achieves Its Quality Goals Exemplu ISSS: Tactici utilizate [Bass] – Table 6.1. Goal How Achieved Tactic(s) Used High Availability Hardware redundancy (both processor and network); software redundancy (layered fault detection and recovery) State resynchronization; shadowing; active redundancy; removal from service; limit exposure; ping/echo; heartbeat; exception; spare High Performance Distributed multiprocessors; front-end schedulability analysis, and network modeling Introduce concurrency Openness Interface wrapping and layering Abstract common services; maintain interface stability Modifiability Templates and table-driven adaptation data; careful assignment of module responsbilities; strict use of specified interfaces Abstract common services; semantic coherence; maintain interface stability; anticipate expected changes; generalize the module; component replacement; adherence to defined procotols; configuration files Ability to Field Subsets Appropriate separation of concerns Abstract common services Interoperability Client-server division of functionality and message-based communications Adherence to defined protocols; maintain interface stability