Proiectare arhitecturală

1. Proiectare arhitecturală

2. Obiective • Introducere în proiectarea arhitecturală şi discutarea importanţei acesteia • Explicarea deciziilor ce trebuie luate în proiectarea arhitecturală • Introducerea de stiluri arhitecturale care acoperă trei probleme complementare: organizarea de ansamblu a sistemului, descompunerea modulară şi controlul • Discutarea modului în care arhitecturile de referinţă sunt utilizate pentru a comunica concepte arhitecturale şi a compara şi evalua arhitecturi

3. Arhitectura software Def. Proiectarea arhitecturală este procesul de proiectare pentru identificarea subsistemelor ce compun un sistem şi a cadrului pentru control şi comunicare între subsisteme. • Ieşirea acestui proces de proiectare este o descriere a arhitecturii software.

4. Proiectarea arhitecturală • Etapă timpurie în procesul de proiectare a sistemului. • Reprezintă legătura dintre procesul de specificare şi cel de proiectare. • Deseori realizată în paralel cu unele activităţi de specificare. • Implică identificarea componentelor majore ale sistemului şi a comunicării dintre acestea.

5. Avantajele arhitecturii explicite • Comunicarea cu părţile interesate • Arhitectura poate fi utilizată ca element central al discuţiei de către părţile interesate în sistem. • Analiza sistemului • Face posibilă analiza faptului că sistemul îşi poate atinge obiectivele non-funcţionale. • Reutilizare pe scară largă • Arhitectura se poate reutiliza pentru o gamă largă de sisteme.

6. Arhitectura şi caracteristicile sistemului • Performanţă • Localizarea operaţiilor critice şi minimizarea comunicării. Utilizare de componente cu granularitate mare. • Securitate • Utilizarea unei arhitecturi multi-nivel cu componentele critice plasate în nivelele interioare. • Siguranţă • Izolarea, într-un număr mic de subsisteme, a caracteristicilor critice din punct de vedere al siguranţei. • Disponibilitate • Includerea de componente redundante şi de mecanisme pentru toleranţă la defecte. • Mentenabilitate • Utilizare de componente cu granularitate mică, înlocuibile.

7. Conflicte arhitecturale • Utilizarea de componente cu granularitate mare îmbunătăţeşte performanţa dar reduce mentenabilitatea. • Introducerea de date redundante îmbunătăţeşte disponibilitatea dar complică asigurarea securităţii. • Localizarea caracteristicilor legate de siguranţă înseamnă de obicei mai multă comunicare şi deci degradarea performanţei.

8. Structurarea sistemului • Descompunerea sistemului în subsisteme care interacţionează. • Proiectul arhitectural este exprimat, în mod normal, ca diagramă bloc ce prezintă o imagine de ansamblu asupra structurii sistemului. • Se pot dezvolta, de asemenea, modele mai specifice care prezintă modul în care subsistemele partajează date, sunt distribuite şi se interfaţează.

9. Exemplu: Robot de împachetare

10. Diagrame bloc • Foarte abstracte – NU ilustrează: • natura relaţiilor între componente • proprietăţile vizibile din exterior ale subsistemelor. • Totuşi, utile pentru: • comunicarea cu părţile interesate • planificarea proiectului.

11. Subiecte tratate • Decizii în proiectarea arhitecturală • Organizarea sistemului • Stiluri de descompunere • Stiluri de control • Arhitecturi de referinţă

12. Decizii în proiectarea arhitecturală • Proiectarea arhitecturală este un proces creativ, deci diferă funcţie de tipul sistemului ce este dezvoltat. • Totuşi, există o serie de decizii comune tuturor proceselor de proiectare arhitecturală. • Există o arhitectură generică ce poate fi utilizată? • Cum va fi distribuit sistemul? • Care sunt stilurile arhitecturale potrivite? • Ce abordare se va utiliza în structurarea sistemului? • Cum va fi descompus sistemul în module? • Ce strategie de control trebuie utilizată? • Cum va fi evaluat proiectul arhitectural? • Cum trebuie documentată arhitectura?

13. Reutilizarea arhitecturii • Sistemele din acelaşi domeniu au deseori arhitecturi similare care reflectă conceptele domeniului. • Liniile de producţie de aplicaţii sunt construite în jurul unei arhitecturi nucleu cu variante care satisfac cerinţele clienţilor particulari.

14. Modele arhitecturale Utilizate pentru a documenta un proiect arhitectural. • Modelul structural static care ilustrează componentele majore ale sistemului. • Modelul dinamical procesului care ilustrează structura de procesare a unui sistem. • Modelul interfeţelor care defineşte interfeţele sub-sistemelor. • Modelul relaţiilor, cum ar fi modelul fluxului datelor, care ilustrează relaţiile între sub-sisteme. • Modelul distribuirii care ilustrează modul în care subsistemele sunt distribuite pe calculatoare.

15. Stiluri arhitecturale • Modelul arhitectural al unui sistem se poate conforma unui model arhitectural generic (stil arhitectural). • Cunoaşterea acestor stiluri poate simplifica problema definirii arhitecturilor sistemelor. • Totuşi, majoritatea sistemelor mari sunt eterogene şi nu urmează un singur stil arhitectural.

16. Subiecte tratate • Decizii în proiectarea arhitecturală • Organizarea sistemului • Stiluri de descompunere • Stiluri de control • Arhitecturi de referinţă

17. Organizarea sistemului • Reflectă strategia de bază care este utilizată pentru a structura sistemul. • Trei stiluri organizaţionale sunt larg utilizate: • Stilul repozitoriu; • Stilul servicii şi servere partajate (client-server); • Stilul maşină abstractă (sau multi-nivel). Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

18. Stilul repozitoriu • Subsistemele trebuie să schimbe date. Acest lucru se poate realiza în două moduri: • Datele partajate sunt păstrate într-o bază de date centrală (repozitoriu) şi pot fi accesate de către toate subsistemele; • Fiecare subsistem păstrează o bază de date proprie şi transferă date în mod explicit către alte subsisteme. • Stilul repozitoriu este folosit în majoritatea cazurilor în care trebuie partajate cantităţi mari de date. Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

19. Exemplu: Arhitectura unui set de instrumente CASE Editor pentru design Generator cod Editor program Traducător design Repozitoriul proiectului Analizor design Generator rapoarte Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

20. Caracteristicile stilului repozitoriu • Avantaje • Mod eficient de a partaja cantităţi mari de date; • Subsistemele nu trebuie să fie preocupate de modul în care sunt produse datele şibeneficiază de management centralizat (ex. backup, security, etc.)‏ • Modelul de partajare este publicat sub formă de schemă a repozitoriului. • Dezavantaje • Subsistemele trebuie să realizeze un acord asupra modelului datelor din repozitoriu. Acesta se stabileşte în mod inevitabil pe baza unui compromis; • Evoluţia datelor este dificilă şi costisitoare; • Nu se pot defini domenii cu politici de management specifice; • Sunt dificil de realizat distribuiri eficiente. Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

21. Stilul client-server • Model de sistem distribuit care ilustrează modul în care datele şi procesările sunt distribuite pe un set de componente. • Set de servere de sine statătoare (stand-alone) care oferă servicii specifice cum ar fi imprimare, management date, etc. • Set de clienţi care apelează aceste servicii. • Reţea ce permite clienţilor să acceseze server-ele. Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

22. Client 1 Client 2 Client 3 Client 4 Internet Server video Server fotografii Server catalog Server Web Fotografii digitizate Informaţii despre filme şi fotografii Catalogul bibliotecii Fişiere cu clip-uri filmate Exemplu: Bibliotecă de filme şi imagini Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

23. Caracteristicile stilului client-server • Avantaje • Distribuirea datelor este evidentă; • Utilizează în mod eficient sistemele de reţea. Pot necesita hardware mai ieftin; • Simplu de adăugat servere noi sau de actualizat (upgrade) serverele existente. • Dezavantaje • Nu există un model partajat al datelor deci sub-sistemele utilizează diferite organizări ale datelor. Schimbul de date poate fi ineficient; • Management redundant în fiecare server; • Nu există un registru central de nume şi servicii – găsirea serverelor şi a serviciilor poate fi dificilă. Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

24. Stilul maşină abstractă (multi-nivel)‏ • Utilizat pentru a modela interfaţarea sub-sistemelor. • Organizează sistemul într-un set de nivele (sau maşini abstracte), fiecare nivel oferind un set de servicii. • Suportă dezvoltarea incrementală a sub-sistemelor de pe nivelediferite. Când se schimbă interfaţa unui nivel, doar nivelele adiacente sunt afectate. • Totuşi, structurarea sistemelor în acest mod este deseori artificială. Stilul repozitoriu Stilul client-server Stilul maşină abstractă (multi-nivel)

25. Subiecte tratate • Decizii în proiectarea arhitecturală • Organizarea sistemului • Stiluri de descompunere • Stiluri de control • Arhitecturi de referinţă

26. Sub-sisteme şi module • Un sub-sistem operează de sine stătător, independent de servicile oferite de alte sub-sisteme. • Un modul este o componentă a sistemului care oferă servicii altor componente dar care în mod normal nu e considerată sistem separat.

27. Stiluri de descompunere modulară • Descompunerea modulară oferă un alt nivel structural, unde sub-sistemele sunt descompuse în module. • Stilurile de descompunere modulară sunt stiluri de descompunere a sub-sistemelor în module. Obs. Nu există o diferenţă rigidă între organizarea sistemului şi descompunerea modulară.

28. Descompunere modulară Stiluritipice de descompunere modulară: • Stilul obiect - sistemul este descompus în obiecte care interacţioneză; • Stilul bandă de asamblare (pipeline) sau flux de date (data-flow) - sistemul este descompus în module funcţionale care transformă intrările în ieşiri. Pe cât posibil, deciziile referitoare la concurenţă trebuie amânate până la implementarea modulelor. Stilul obiect Stilul bandă de asamblare

29. Stilul obiect Structurează sistemul într-un set de obiecte slab cuplate cu interfeţe bine definite. • Descompunerea orientată obiect se ocupă cu identificarea claselor de obiecte, a atributelor şi a operaţiilor acestora. • La implementare, obiectele sunt create din: • aceste clase cât • un model de control utilizat pentru a coordona operaţiile pe obiecte. Stilul obiect Stilul bandă de asamblare

30. Exemplu: Sistem pentru procesare facturi Stilul obiect Stilul bandă de asamblare

31. Avantajele stilului obiect • Obiectele sunt slab cuplate, deci implementarea lor poate fi modificată fără a afecta alte obiecte. • Obiectele pot reflecta entităţi din lumea reală. • Limbajele OO sunt larg utilizate. • Totuşi: • schimbările la nivelul interfeţelor obiectelor pot cauza probleme. • entităţi complexe ar putea fi greu de reprezentat sub formă de obiecte. Stilul obiect Stilul bandă de asamblare

32. Bandă de asamblare orientată pe funcţii Transformările funcţionale procesează intrările pentru a produce ieşiri. • Pot fi referite ca model “pipe and filter” (ca în UNIX shell). • Variante ale acestei abordări sunt foarte răspândite. Când transformările sunt secvenţiale avem de-a face cu un model secvenţial în loturi de lucrări (batch sequential model) care este intens utilizat în sistemele de procesare a datelor. • Nu sunt foarte potrivite pentru sistemele interactive. Stilul obiect Stilul bandă de asamblare

33. Exemplu: Sistem pentru procesare facturi Stilul obiect Stilul bandă de asamblare

34. Avantajele stilului bandă de asamblare • Suportă reutilizarea transformărilor. • Organizare intuitivă pentru comunicarea cu părţile interesate. • Simplu de adăugat noi transformări. • Relativ simplu de implementat fie ca sistem concurent fie ca sistem secvenţial. • Totuşi: • necesită un format comun pentru transferul datelor de-a lungul benzii de asemblare. • suportă cu dificultate interacţiunile bazate pe evenimente. Stilul obiect Stilul bandă de asamblare

35. Subiecte tratate • Decizii în proiectarea arhitecturală • Organizarea sistemului • Stiluri de descompunere • Stiluri de control • Arhitecturi de referinţă

36. Stiluri de control Sunt destinate fluxului de control între sub-sisteme. Obs. Diferă de modelul de descompunere a sistemului. • Control centralizat • Un sub-sistem are responsabilitatea de a controla, porni şi opri alte sub-sisteme. • Control bazat pe evenimente • Fiecare sub-sistem poate răspunde la evenimente externe generate de alte sub-sisteme sau de contextul sistemului. Control centralizat Control bazat pe evenimente

37. Control centralizat • Un sub-sistem de control preia responsibilitatea gestionării execuţiei altor sub-sisteme. • Stilul “Call-return” • Model subrutină “top-down” în care controlul porneşte de la vârful unei ierarhii de subrutine şi parcurge ierarhia până la bază. Aplicabil sistemelor secvenţiale. • Stilul manager • Aplicabil sistemelor concurente. O componentă a sistemului controlează pornirea, oprirea şi coordonarea proceselor altor sisteme. Poate fi implementat în sistemele secvenţiale folosind instrucţiunea “case”. • Control centralizat • Stilul call-return • Stilul manager • Control bazat pe evenimente

38. Stilul “call-return” • Control centralizat • Stilul call-return • Stilul manager • Control bazat pe evenimente Program principal Subrutina 1 Subrutina 2 Subrutina 3 Subrutina 1.1 Subrutina 1.2 Subrutina 3.1 Subrutina 3.2

39. Stilul manager: sistem de control în timp real Procese senzor Procese de acţionare • Control centralizat • Stilul call-return • Stilul manager • Control bazat pe evenimente Controler sistem Procese de calcul Interfaţă utilizator Gestionar defecte

40. Sisteme conduse de evenimente (event-driven)‏ Conduse de evenimente generate extern, pentru care temporizarea evenimentului este în afara controlului sub-sistemelor care procesează evenimentul. • Două modele principale pentru sistemele conduse de evenimente: • Stilul cu difuzare (broadcast). Un eveniment este difuzat tuturor sub-sistemelor. Orice sub-sistem capabil să trateze evenimentul o poate face; • Stilul condus de întreruperi (interrupt-driven). Utilizat în sistemele de timp real, unde întreruperile sunt detectate de un handler de întreruperi şi transferate altor componente spre procesare. Alte modele pentru sistemele conduse de evenimente includ spreadsheets şi sistemele de producţie. • Control centralizat • Control bazat pe evenimente • Stilul broadcast • Stilul condus de întreruperi

41. Stilul cu difuzare (broadcast)‏ • Eficient la integrarea sub-sistemelor de pe calculatoare diferite dintr-o reţea. • Sub-sistemele îşi înregistrează interesul pentru anumite evenimente. Când acestea se produc, controlul este transferat către sub-sistemele înregistrate la evenimentul respectiv, care îl pot astfel trata. • Politica de control nu este încapsulată în eveniment sau în rutina de tratare (handler) mesaj. Sub-sistemele sunt cele care decid asupra evenimentelor de interes pentru ele. • Totuşi, sub-sistemele nu cunosc când şi dacă un eveniment va fi tratat. • Control centralizat • Control bazat pe evenimente • Stilul broadcast • Stilul condus de întreruperi

42. Difuzare selectivă Sub-sistem Sub-sistem Sub-sistem Sub-sistem 1 2 3 4 Rutină tratare evenimente şi mesaje • Control centralizat • Control bazat pe evenimente • Stilul broadcast • Stilul condus de întreruperi

43. Sisteme conduse de întreruperi • Utilizate în sistemele de timp real, acolo unde este esenţial ca unui eveniment să i se răspundă “la timp”. • În sistem există un set de tipuri de întreruperi şi de rutine de tratare (handler) cunoscute, definite pentru fiecare tip. • Fiecare tip este asociat cu o locaţie de memorie şi un comutator hardware care realizează transferul la rutina corespunzătoare de tratare. • Permit răspuns rapid dar sunt complicat de programat şi dificil de validat. • Control centralizat • Control bazat pe evenimente • Stilul broadcast • Stilul condus de întreruperi

44. Control condus de întreruperi • Control centralizat • Control bazat pe evenimente • Stilul broadcast • Stilul condus de întreruperi Întreruperi Vector de întreruperi Handler Handler Handler Handler 1 2 3 4 Pr oces Pr oces Pr oces Pr oces 1 2 3 4

45. Subiecte tratate • Decizii în proiectarea arhitecturală • Organizarea sistemului • Stiluri de descompunere • Stiluri de control • Arhitecturi de referinţă

46. Arhitecturi de referinţă Modelele arhitecturale pot fi specifice unor domenii de aplicaţii. • Două tipuri de modele specifice domeniului: • Modele generice: abstractizează mai multe sisteme reale şi încapsulează caracteristicile principale ale acestor sisteme. • Modele de referinţă: sunt modele mai abstracte, idealizate. Oferă o modalitate de informare despre clasa sistemului şi de comparare între arhitecturi diferite. • Modelele generice sunt de obicei modele “bottom-up” (ascendente); • Modelele de referinţă sunt modele “top-down” (descendente).

47. Arhitecturi de referinţă • Modelele de referinţă sunt derivate din studierea domeniului aplicaţiei şi nu din sistemele existente. • Se pot utiliza ca bază pentru implementarea sistemului sau pentru a compara diferite sisteme. Acţionează ca standard faţă de care sistemele pot fi evaluate. • Modelul OSI este un model multi-nivel pentru sistemele de comunicare.

48. Modelul de referinţă OSI 7 A pplica A pplica tion tion tion tion 6 Pr esenta Pr esenta 5 Session Session 4 T t T t r anspor r anspor 3 Network Netw or k Netw or k 2 Da ta link Da ta link Da ta link 1 Ph ysical Ph ysical Ph ysical Communications medium

49. Modelul de referinţă CASE • Servicii repositoriu de date • Memorare şi management date. • Servicii pentru integrare date • Gestionarea grupurilor de entităţi. • Servicii pentru management sarcini (tasks)‏ • Definirea şi punerea în scenă a modelelor de procese. • Servicii de mesagerie • Comunicare instrument-instrument şi instrument-context. • Servicii de interfaţă utilizator • Dezvoltarea interfeţei utilizator.

50. Rezumat • Arhitectura software este cadrul (framework) fundamental pentru structurarea sistemului. • Deciziile proiectării arhitecturale includ decizii referitoare la arhitectura aplicaţiei, la distribuire şi la stilurile arhitecturale ce vor fi utilizate. • Se pot dezvolta modele arhitecturale diferite, cum ar fi un model structural, un model al controlului şi un model al descompunerii sistemului în sub-sisteme. • Modelele organizaţionale ale sistemelor includ modele repozitoriu, modele client-server şi modele maşină abstractă.