Arhitectura software
Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de
versiunea revizuită pe 13 mai 2019; verificările necesită
8 modificări .
Arhitectura software este un set al celor mai importante decizii privind organizarea unui sistem software. Arhitectura include:
- alegerea elementelor structurale și interfețele acestora, cu ajutorul cărora este compus sistemul, precum și comportamentul acestora în cadrul cooperării elementelor structurale;
- conectarea elementelor selectate de structură și comportament în sisteme din ce în ce mai mari;
- un stil arhitectural care ghidează întreaga organizație — toate elementele, interfețele lor, colaborarea lor și conexiunea lor [1] [2] .
Documentarea arhitecturii software (SW) simplifică procesul de comunicare între dezvoltatori, vă permite să înregistrați deciziile de proiectare luate și să furnizați informații despre acestea personalului de operare al sistemului [3] , reutilizați componente și șabloane de proiect
în altele.
Nu există o definiție general acceptată a „arhitecturii software”. Deci, site-ul Institutului de Inginerie Software oferă mai mult de 150 de definiții ale acestui concept [4] [5] .
Prezentare generală
Domeniul informaticii, încă de la începuturile sale, s-a confruntat cu provocări legate de complexitatea sistemelor software. Anterior, problemele de complexitate erau rezolvate de dezvoltatori prin alegerea structurilor de date potrivite, dezvoltarea algoritmilor și aplicarea conceptului de separare a puterilor. Deși termenul „arhitectură software” este relativ nou în industria dezvoltării de software, principiile fundamentale ale domeniului au fost aplicate fără discernământ de pionierii dezvoltării de software încă de la mijlocul anilor 1980. Primele încercări de a înțelege și explica arhitectura software a unui sistem au fost pline de inexactități și au suferit de o lipsă de organizare, adesea doar o diagramă a blocurilor conectate prin linii. În anii 1990 s-a încercat definirea și sistematizarea principalelor aspecte ale acestei discipline. Un set inițial de modele de design, stiluri de design, bune practici, limbaje de descriere și logică formală au fost dezvoltate în acest timp [6] .
O idee fundamentală a disciplinei arhitecturii software este ideea de a reduce complexitatea sistemului prin abstracție și separarea puterilor. Până în prezent, nu există încă un acord cu privire la o definiție clară a termenului „arhitectură software”.
Fiind o disciplină în evoluție în prezent, fără reguli clare despre modalitatea „corectă” de a construi un sistem, proiectarea arhitecturii software este încă un amestec de știință și artă. Aspectul „artă” este că orice sistem comercial presupune o aplicație sau o misiune. Din perspectiva unui utilizator de arhitectură software, arhitectura software oferă direcție pentru deplasarea și rezolvarea problemelor legate de specialitatea fiecărui astfel de utilizator, de exemplu, o parte interesată, dezvoltator de software, echipă de asistență software, întreținător de software, specialist în implementarea software, tester, precum și utilizatorii finali. În acest sens, arhitectura software reunește de fapt diferite perspective asupra unui sistem. Faptul că aceste câteva puncte de vedere diferite pot fi combinate într-o arhitectură software este un argument în favoarea necesității și oportunității creării unei arhitecturi software chiar înainte de etapa de dezvoltare a software-ului [7] [8] [9] .
Istorie
Arhitectura software ca concept a început cu munca de cercetare a lui Edsger Dijkstra în 1968 și a lui David Parnassus la începutul anilor 1970. Acești savanți au subliniat că structura unui sistem software este importantă și că construirea structurii corecte este critică. Studiul acestui domeniu a crescut în popularitate de la începutul anilor 1990 cu lucrări de cercetare privind stilurile arhitecturale (modele), limbaje de descriere a arhitecturii, documentația arhitecturii și metodele formale.
Instituțiile de cercetare joacă un rol important în dezvoltarea arhitecturii software ca disciplină. Mary Shaw și David Garlan de la Universitatea Carnegie Mellon au scris o carte intitulată „Arhitectura software: perspective asupra unei noi discipline în 1996” în care au prezentat concepte de arhitectură software, cum ar fi componente, conectori, stiluri și așa mai departe. La Universitatea din California, Institutul Irvine pentru Cercetarea Software-ului cercetează în primul rând stilurile arhitecturale, limbaje de descriere a arhitecturii și arhitecturile dinamice.
Primul standard de arhitectură software este IEEE 1471: ANSI/IEEE 1471-2000: Guidelines for Describing Predominantly Software Systems. A fost adoptat în 2007 sub denumirea ISO ISO/IEC 42010:2007.
Limbaje de descriere a arhitecturii
Limbajele de descriere a arhitecturii (ADLS) sunt folosite pentru a descrie arhitectura software-ului. Mai multe ADLS diferite au fost dezvoltate de diferite organizații, inclusiv AADL (standard SAE), Wright (dezvoltat la Carnegie Mellon University), Acme (dezvoltat la Carnegie Mellon University), xADL (dezvoltat la UCI), Darwin (dezvoltat la Imperial College London) , DAOP-ADL (dezvoltat la Universitatea din Malaga) și ByADL (Universitatea din L'Aquila, Italia). Elementele comune pentru toate aceste limbaje sunt conceptele de componentă, conector și configurare. De asemenea, pe lângă limbajele specializate, limbajul unificat de modelare UML este adesea folosit pentru a descrie arhitectura .
Vizualizări
O arhitectură software conține de obicei mai multe vederi care sunt similare cu diferitele tipuri de desene din construcția clădirilor. Într-o ontologie definită de ANSI/IEEE 1471-2000, vederile sunt instanțe de punct de vedere, în care există un punct de vedere pentru a descrie o arhitectură din punctul de vedere al unui anumit set de părți interesate.
Vederea arhitecturală este formată din 2 componente:
- Elemente
- Relațiile dintre elemente
Vederile arhitecturale pot fi împărțite în 3 tipuri principale [10] :
- Vizualizări modulare (eng. module view ) - arată sistemul ca o structură a diferitelor blocuri software.
- Components-and-connectors (eng. component-and-connector views ) - arată sistemul ca o structură de elemente care rulează paralel (componente) și modul în care acestea interacționează (conectori).
- Alocare (îng. vizualizări de alocare ) - arată amplasarea elementelor sistemului în medii externe.
Exemple de vederi modulare:
- Descompunere (ing. vedere descompunere ) - constă din module în contextul relației „este un submodul”
- Utilizare (eng. uses view ) - constă din module în contextul relației „utilizări” (adică un modul folosește serviciile altui modul)
- Vedere nivel (îng. vedere stratificată ) - arată o structură în care modulele legate de funcționalitate sunt combinate în grupuri (nivele)
- Vedere clasă / generalizare ( vedere clasă / generalizare ing. ) - constă din clase legate prin relația „moștenit de la” și „este o instanță”
Exemple de tipuri de componente și conectori:
- Vizualizare proces (îng. vizualizare proces ) - constă din procese conectate prin operațiuni de comunicare, sincronizare și/sau excludere
- Vedere paralelă (îng. vizualizare concurență ) - constă din componente și conectori, unde conectorii sunt „fluxuri logice”
- Tip de schimb de date (de exemplu, vizualizare de date partajate (depozitare) - constă din componente și conectori care creează, salvează și primesc date persistente
- Vizualizare client-server (eng. vizualizare client-server ) - constă din clienți și servere care interacționează, precum și conectori între aceștia (de exemplu, protocoale și mesaje comune)
Exemple de tipuri de cazare:
- Deployment (eng. deployment view ) - constă din elemente software, plasarea acestora pe medii fizice și elemente de comunicare
- Implementare (de exemplu , vedere implementare ) - constă din elemente de program și corespondența acestora cu structurile de fișiere din diverse medii (dezvoltare, integrare etc.)
- Misiunea de lucru (îng. vizualizarea sarcinilor de lucru ) - constă din module și o descriere a cine este responsabil pentru implementarea fiecăruia dintre ele
Deși au fost dezvoltate mai multe limbi pentru a descrie arhitectura software, în prezent nu există un acord asupra setului de vederi care ar trebui adoptat ca referință. Limbajul UML a fost creat ca standard „pentru modelarea sistemelor software (și nu numai)”.
Modele arhitecturale
Sunt aplicate diverse modele arhitecturale pentru a satisface sistemul proiectat cu diferite atribute de calitate. Fiecare șablon are propriile sale obiective și dezavantaje.
Exemple de modele arhitecturale:
- Model stratificat. Sistemul este împărțit în niveluri, care sunt prezentate unul deasupra celuilalt în diagramă. Fiecare nivel poate invoca doar nivelul 1 de sub el. Astfel, dezvoltarea fiecărui nivel poate fi realizată relativ independent, ceea ce crește capacitatea de modificare a sistemului. Dezavantajele acestei abordări sunt complicația sistemului și scăderea performanței.
- Model de broker. Când există un număr mare de module în sistem, interacțiunea lor directă între ele devine prea complicată. Pentru a rezolva problema, este introdus un intermediar (de exemplu, o magistrală de date), prin care modulele comunică între ele. Astfel, interoperabilitatea modulelor de sistem este crescută. Toate dezavantajele provin din prezența unui intermediar: reduce performanța, indisponibilitatea acestuia poate face întregul sistem inaccesibil, poate deveni un obiect de atac și un blocaj al sistemului.
- Model „Model-View-Controller” (model Model-View-Controller). pentru că Deoarece cerințele pentru interfață se schimbă cel mai des, atunci este nevoie să o modifici des, menținând în același timp interacțiunea corectă cu datele (citire, salvare). Pentru a face acest lucru, în modelul Model-View-Controller (MVC), interfața este separată de date. Acest lucru vă permite să schimbați interfețele, precum și să creați diferite versiuni ale acestora. În MVC, sistemul este împărțit în:
- Modelul care stochează datele
- O vizualizare care afișează o bucată de date și interacționează cu utilizatorul
- Un controler care mediază între vederi și model
Cu toate acestea, conceptul MVC are și dezavantajele sale. În special, din cauza complicației interacțiunii, viteza sistemului scade.
- Model client-server (model client-server). Dacă există un număr limitat de resurse care necesită acces restricționat de către un număr mare de consumatori, atunci este convenabil să se implementeze o arhitectură client-server. Această abordare crește scalabilitatea și disponibilitatea sistemului. Dar, în același timp, serverul poate deveni un blocaj în sistem; dacă nu este disponibil, întregul sistem devine indisponibil.
Cadre de bază pentru arhitectura software
Există următoarele cadre ( cadre de arhitectură software engleză ) legate de domeniul arhitecturii software:
- 4+1
- RM-ODP (Model de referință de procesare distribuită deschisă)
- Cadrul de modelare orientată pe servicii (SOMF)
Exemple de arhitectură, cum ar fi Zachman Framework, DoDAF și TOGAF, intră în domeniul arhitecturilor de întreprindere.
Vezi și
Note
- ↑ Kruchten, Philippe . Procesul rațional unificat-o introducere, Addison-Wesley, 1998
- ↑ Rumbaugh, J. , Jacobsen, I. și Booch, G. Manualul de referință al limbajului de modelare unificat. Reading, Mass.: Addison-Wesley, 1999
- ↑ Documenting Software Architectures: Views and Beyond, 2010 , P.1.1. Prezentare generală.
- ↑ Documenting Software Architectures: Views and Beyond, 2010 , P.1.2. Arhitectură și atribute de calitate.
- ↑ Arhitectura software: Glosar arhivat la 5 ianuarie 2013 la Wayback Machine , Institutul de inginerie software
- ↑ Care este definiția dvs. de arhitectură software . resurse.sei.cmu.edu. Preluat la 23 octombrie 2019. Arhivat din original la 28 februarie 2020.
- ↑ ISO/IEC/IEEE 42010: Definirea „arhitecturii” . www.iso-architecture.org. Preluat la 23 octombrie 2019. Arhivat din original la 7 aprilie 2017. (nedefinit)
- ↑ M. Fowler. Design - Cine are nevoie de un arhitect? // Software IEEE. — 2003-9. - T. 20 , nr. 5 . — S. 11–13 . - doi : 10.1109/MS.2003.1231144 . Arhivat din original pe 23 octombrie 2019.
- ↑ O introducere în arhitectura software . Preluat la 23 octombrie 2019. Arhivat din original la 6 mai 2021. (nedefinit)
- ↑ Len Bass, Paul Clements, Rick Kazman. Arhitectura software în practică (Ediția a 3-a) (Seria SEI în Inginerie software). - ediția a 3-a (5 octombrie 2012). - 2012. - 640 p. — ISBN 978-0321815736 .
Literatură
- Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paul Merson; Robert North; Judith Stafford. Documentarea arhitecturilor software: vederi și dincolo. - A doua editie. - Addison-Wesley Professional, 2010. - ISBN 978-0-13-248861-7 .
- Len Bass, Paul Clements, Rick Kazman: Arhitectura software în practică, ediția a treia . Addison Wesley, 2012, ISBN 978-0321815736 (Această carte, aflată acum la a treia ediție, acoperă în mod elocvent conceptele fundamentale ale disciplinei. Tema este centrată pe atingerea atributelor de calitate ale unui sistem.)
Link -uri