1. Calitati si tactici arhitecturale
Bibliografie:
Bass, Clements, Kazman: Software Architecture in Practice, Second edition, Addison Wesley, 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 Q2
cu Arhit2 Q3
cu Arhit3
Quality

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

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: (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.
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

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

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

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

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

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

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.

51. Security Tactics Resisting attacks Detecting attacks
Recovering from attacks

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

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

54. [Bass] – fig.5.9.

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

56. [Bass] – fig.5.11.

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

58. [Bass] – fig.5.13.

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

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

61. Exemplu ISSS: Requirements & Qualities
Cerinte esentiale:
Ultrahigh availability: availability requirement = : 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

62. 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.”

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

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

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

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

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

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