Arhitecturi pentru sisteme soft w are

1. Arhitecturi pentru sisteme software Curs 1

2. Arhitecturi software - exemple

3. Arhitecturi software - exemple

4. Arhitecturi software - exemple

5. Arhitecturi software - exemple

6. Arhitecturi software - exemple

7. Arhitecturi software - exemple

8. Arhitecturi software - exemple

9. Concluzie • Probleme ale descrierilor naive ale arhitecturii software • Text informal şi diagrame de tip box-and-lines. • Intuitive • Precizie slabă • Rareori formalizată • O soluţie : Dezvoltarea ARHITECTURALĂ a sistemelor software.

10. Dezvoltarea arhitecturală a sistemelor software • Compunerea sistemelor din părţi componente. • Asigurarea conformităţii sistemului cu arhitectura şi cu proprietăţile dorite. • Utilizare arhitecturi standard pentru integrare. • Reutilizare. • Reducere costuri utilizând linii de producţie.

11. PLAN CURS • Obiectivele cursului • Definiţia şi rolul arhitecturii software • Evoluţia domeniului • Arhitectura software în context • Analiza definiţiei arhitecturii software • Impactul arhitecturii software • Relaţiile de influenţă ale arhitecturii software • Rolul şi calităţile arhitectului software

12. Obiectivele cursului - 1 • Rolul arhitecturii software în procesul de dezvoltare a software-lui. • Recunoaşterea principalelor stiluri şi şabloane arhitecturale. • Descrierea cerinţelor astfel încât arhitectura să poată fi evaluată. • Înţelegerea principiilor unei bune documentaţii arhitecturale. • Înţelegerea modului de incorporare a COTS şi middleware în proiectele arhitecturale. • Generarea de alternative arhitecturale pentru o problemă şi alegerea uneia dintre ele.

13. Obiectivele cursului - 2 • Proiectarea şi construirea unui sistem de dimensiuni medii care satisface o specificaţie arhitecturală • Înţelegerea modului în care notaţiile formale pot fi utilizate pentru a specifica arhitecturi. • Evaluarea adecvării (potrivire) unei arhitecturi date în îndeplinirea unui set de cerinţe sistem şi echilibrarea compromisurilor asupra calităţii. • Cunoaşterea tendinţelor de viitor în domeniul arhitecturilor software.

14. PLAN CURS • Obiectivele cursului • Definiţia şi rolul arhitecturii software • Evoluţia domeniului • Arhitectura software în context • Analiza definiţiei arhitecturii software • Impactul arhitecturii software • Relaţiile de influenţă ale arhitecturii software • Rolul şi calităţile arhitectului software

15. Arhitectură software - Definiţie Definiţii la: http://www.sei.cmu.edu/architecture/start/definitions.cfm Definiţia adoptată la acest curs: “Arhitectura software a unui sistem constă din structura sau structurile sistemului şi conţine elementele software, proprietăţile vizibile din exterior ale acestora şi relaţiile dintre ele”.

16. Proiectare arhitecturală Elemente ale modelului analitic Informaţii despre domeniul aplicaţiei Şabloane şi stiluri arhitecturale existente PROIECTARE ARHITECTURALĂ Arhitectura aplicaţiei = Perspectivă de generală asupra software-lui.

17. Locul şi rolul arhitecturii software Proiect de nivel superior al sistemului Abstractizări la nivel de sistem Modele reutilizabile la nivel de sistem

18. Contextul activităţilor de dezvoltare a arhitecturii software http://bredemeyer.com/where.htm

19. Importanţa arhitecturii software Reducerea costurilor de dezvoltare şi de mentenanţă - clarificarea structurii sistemului pe diferite nivele - reutilizare Creşterea calităţii produsului software - clarificarea cerinţelor - explicitarea deciziilor, realizate pe bază de principii, şi a implicaţiilor lor - analize la nivel de sistem - analiza timpurie a problemelor de proiectare

20. Importanţa arhitecturii software – reducerea costurilor de mentenanţă Aproape 50% din efortul de mentenenţă este investit în analiza şi înţelegerea codului şi documentaţiei existente.

21. Arhitectură software vs. programare PROGRAMAREA • Implementarea părţilor componente • Proprietăţile computaţionale • Operaţională • În mare parte dinamică • Performanţă la nivel de algoritm • “vedere” interioară a modulelor ARHITECTURA SOFTWARE • Interacţiunile dintre părţile componente • Proprietăţile structurale • Declarativă • În mare parte statică • Performanţă la nivel de sistem • “vedere” exterioară a modulelor

22. PLAN CURS • Obiectivele cursului • Definiţia şi rolul arhitecturii software • Evoluţia domeniului • Arhitectura software în context • Analiza definiţiei arhitecturii software • Impactul arhitecturii software • Relaţiile de influenţă ale arhitecturii software • Rolul şi calităţile arhitectului software

23. Evoluţia domeniului - anii 1980 • Utilizare informală de diagrame de tip box-and-lines • Aplicare ad-hoc a expertizei arhitecturale • Utilizarea neorganizată, necodificată, a şabloanelor şi stilurilor • Majoritatea proiectelor nu au “arhitect”

24. Evoluţia domeniului - anii 1990 • Recunoaşterea importanţei arhitecţilor în companiile de dezvoltare de software • Procese software ce includ revizuiri ale arhitecturii şi documentaţie arhitecturală explicită • Utilizare de linii de producţie, de standarde arhitecturale, de cadre pentru integrare de componente • Codificarea vocabularului, notaţii şi instrumente pentru proiectare arhitecturală • Cărţi şi cursuri de arhitecturi software

25. Evoluţia domeniului - anii 2000 • Încorporarea notaţiilor arhitecturale în principalele limbaje de proiectare (ex. UML 2.0) şi instrumente (ex. Software Architect de la IBM) • Metode bazate pe proiectare arhitecturală şi rafinarea acesteia (ex. MDA – Model Driven Architecture) • Unele instrumente pentru analiză arhitecturală • Standarde arhitecturale pentru sisteme enterprise (ex. RM-ODP, TOGAF)

26. PLAN CURS • Obiectivele cursului • Definiţia şi rolul arhitecturii software • Evoluţia domeniului • Arhitectura software în context • Analiza definiţiei arhitecturii software • Impactul arhitecturii software • Relaţiile de influenţă ale arhitecturii software • Rolul şi calităţile arhitectului software

27. Ingineria sistemelor Ingineria sistemelor – disciplină de proiectare şi management pentru proiectarea şi construirea de sisteme mari, complexe, interdisciplinare. Arhitectura sistemului – element critic al ingineriei sistemelor: • Descrie elementele şi interacţiunile unui sistem complet precum şi contribuţia acestora la scopul sistemului • Include identificarea şi caracterizarea elementelor sistemului, fără a descrie substructurile acestor elemente.

28. Ingineria sistemelor Principiu: integrarea sistemului (de jos în sus) este posibilă doar pe baza proiectării (de sus în jos), care începe cu o arhitectură robustă a sistemului. Modelul SE “Vee” de proiectare şi dezvoltare în ingineria sistemelor

29. Ingineria sistemelor Există cadre standard (ex. TOGAF) care adresază în general • entităţile, • procesul de inginerie a sistemului, • infrastructura. Critică: Nivelul de abstractizare este prea înalt. NU adresează problemele tehnice de dezvoltare a soluţiei arhitecturale.

30. Arhitectură “enterprise” Arhitectura “enterprise” descrie structurile business şi procesele care conectează aceste structuri. Descrierea conţine: • Logica de organizare a procesului business – fluxul informaţiilor şi activităţile dintre entităţile firmei Dacă e cazul: • Infrastructura IT ce reflectă cerinţele de integrare şi standardizare ale modelului de operare al firmei. În general – cadru ce se referă la documentaţiile implicate în procese. Există multiple cadre pentru arhitecturi “enterprise” (EAF).

31. Orientare business Orientare tehnică Implementare Arhitecturi “enterprise” - exemplu Enterprise Architecture Framework – John Zachman (IBM).

32. Interese în proiectări arhitecturale

33. Ierarhia proiectării arhitecturale Principii: • Interese diferite pe nivele diferite • Deciziile de pe nivelele superioare impun constrângeri nivelelor inferioare • Nivelul superior transferă responsabilitatea detalierii către nivelul inferior

34. Ierarhia proiectării arhitecturale ENTERPRISE: procesul business mapat pe o infrastructură cu granularitate mare. SYSTEM: Concentrare pe cerinţele funcţionale alocate elementelor fizice. (sisteme de sisteme) SOFTWARE: multidemnsională; satisfăcând cerinţe funcţionale şi non-funcţionale. Deseori ortogonală în raport cu structurile sistemului. Critică în satisfacerea obiectivelor business.

35. PLAN CURS • Obiectivele cursului • Definiţia şi rolul arhitecturii software • Evoluţia domeniului • Arhitectura software în context • Analiza definiţiei arhitecturii software • Impactul arhitecturii software • Relaţiile de influenţă ale arhitecturii software • Rolul şi calităţile arhitectului software

36. Arhitectura software - definiţie “Arhitectura software a unui program sau a unui sistem de calcul constă din structura sau structurile sistemului şi conţine elementele software, proprietăţile vizibile din exterior ale acestor elemente şi relaţiile dintre elemente.” • Proiectarea şi documentarea arhitecturii software sunt esenţiale în dezvoltarea şi evaluarea produsului software. • Dacă nu se realizează proiectarea arhitecturală, în paralel cu dezvoltarea produsului software se va dezvolta implicit o arhitectură. Care ar putea să nu vă placă!!!

37. Arhitectura software - definiţie Caracteristici ale arhitecturii software: • Abstractizare a sistemului. • Partiţionare declarativă şi asignare de responsabilităţi. • Defineşte elementele şi modul în care sunt acestea relaţionate. • Suprimă detaliile despre comportamentul intern şi informaţiile locale ale elementelor. Orice sistem are o arhitectură software (chiar dacă aceasta nu a fost proiectată în mod deliberat). Cel mai simplu sistem este compus dintr-un singur element aflat în relaţie cu el însuşi. Arhitectura îndeplineşte cerinţele funcţionale şi în acelaşi timp promovează o serie de calităţi ale sistemului (ex. performană, flexibilitate, etc.).

38. Arhitectura software - definiţie “Arhitectura software a unui program sau a unui sistem de calcul constă din structura sau structurile sistemului şi conţine elementele software, proprietăţile vizibile din exterior ale acestor elemente şi relaţiile dintre acestea.” Abstractizare a structurilor reale ce compun sistemul software. • Structurile sunt reale • Reprezentările lor sunt abstracte

39. Arhitectura software - definiţie “Arhitectura software a unui program sau a unui sistem de calcul constă din structura sau structurile sistemului şi conţine elementele software, proprietăţile vizibile din exterior ale acestor elemente şi relaţiile dintre acestea.” Tipuri de structuri software: • Structură statică - cod, apel metodă/funcţie,… • Structură dinamică - proces/fire de execuţi, flux de date,… • Structură fizică - alocarea sistemului de fişiere, procesor, reţea, ….

40. Structură, perspectivă, vedere Un edificiu trebuie să aibă trei calităţi: durabilitate (firmitas), utilitate (utilitas), estetică (venustas). Marcus Vitruvius Pollio, De architectura

41. O vedere din perspectivă dinamică O vedere din perspectivă statică Structură, perspectivă, vedere Vedere (view) – o reprezentare a unei structuri, văzută dintr-o anumită perspectivă.

42. Perspectiva FIZICĂ • Vederi ale alocărilor: • calculatoare • dispozitive • reţele • Perspectiva STATICĂ • Vederi ale modulelor: • clase • funcţii • interfeţe • Perspectiva DINAMICĂ • Vederi ale componentelor şi conectorilor: • procese • diagrame de secvenţe • flux de date Structură, perspectivă, vedere

43. Arhitectura software - definiţie “Arhitectura software a unui program sau a unui sistem de calcul constă din structura sau structurile sistemului şiconţine elementele software, proprietăţile vizibile din exterior ale acestor elemente şi relaţiile dintre acestea.” Element – “parte” a unui sistem.

44. Arhitectura software - definiţie “Arhitectura software a unui program sau a unui sistem de calcul constă din structura sau structurile sistemului şi conţine elementele software, proprietăţile vizibile din exterior ale acestor elemente şi relaţiile dintre acestea.” • Proprietăţi funcţionale : asignarea de responsabilităţielementelor este o parte esenţială a proiectării arhitecturale. • Proprietăţi non-funcţionale : cerinţele de calitate pentru sistem şi componentele sale. • Tipurile de proprietăţi vizibile depinde de perspectiva asupra sistemului. • Exemplu: • Perspectivă statică – modificabilitatea • Perspectivă dinamică - performanţa

45. Arhitectura software - definiţie “Arhitectura software a unui program sau a unui sistem de calcul constă din structura sau structurile sistemului şi conţine elementele software, proprietăţile vizibile din exterior ale acestor elemente şi relaţiile dintre acestea.” • Elementele interacţionează prin interfeţe care împart detaliile în părţi publice şi părţi private. • Aceste interacţiuni formează relaţiile dintre elementele arhitecturale. • Arhitectura se ocupă doar cu partea publică a acestei partiţionări.

46. uses uses date date date Modul A Proces X Proces Y Modul B Modul C Vedere din perspectivă DINAMICĂ Elemente: procese Relaţii: flux de date Vedere din perspectivă STATICĂ Elemente: module Relaţii: uses Arhitectura software - definiţie “Arhitectura software a unui program sau a unui sistem de calcul constă din structura sau structurile sistemului şi conţine elementele software, proprietăţile vizibile din exterior ale acestor elemente şi relaţiile dintre acestea.” Tipurile de relaţii depind de tipurile de elemente, care depind la rândul lor de perspectivă. Exemple:

47. PLAN CURS • Obiectivele cursului • Definiţia şi rolul arhitecturii software • Evoluţia domeniului • Arhitectura software în context • Analiza definiţiei arhitecturii software • Impactul arhitecturii software • Relaţiile de influenţă ale arhitecturii software • Rolul şi calităţile arhitectului software

48. Impactul arhitecturii software • Atributele de calitate (modificabilitate, disponibilitate, performanţă, etc.) sunt dependente de design. • Gândirea arhitecturală este gândire strategică. • O arhitectură software proiectată deliberat şi bine documentată oferă valoare proiectului şi firmei ce dezvoltă software-ul.

49. Impactul arhitecturii software Proiectul arhitectural şi documentaţia asociată: • servesc ca vehicol de comunicare • ghidează deciziile iniţiale de proiectare • reduc riscul • ajută la managementul proiectului/produsului • facilitează reutilizarea

50. Impactul arhitecturii software Documentaţia arhitecturii oferă un cadru de referinţă în care pot fi expuse şi negociate interese concurente. Permite: • Negocierea cerinţelor tuturor părţilor interesate • Realizarea de informări asupra progresului • Alocare de resurse şi ghidarea construirii produsului software Documentaţia trebuie să fie: • DESCRIPTIVĂ - pentru comunicare • PRESCRIPTIVĂ - pentru proiectanţi şi pentru implementatori. • Proiectul arhitectural şi documentaţia asociată: • Serveşte ca vehicol de comunicare • Ghidează deciziile iniţiale de proiectare • Reduce riscul • Ajută la managementul proiectului/produsului • Facilitează reutilizarea