Arhitectura sistemului

Arhitectura sistemului  este organizarea fundamentală a sistemului , întruchipată în elementele sale , relațiile acestora între ele și cu mediul, precum și principiile care ghidează proiectarea și evoluția acestuia [1] :3 .

Conceptul de arhitectură este în mare măsură subiectiv și are multe interpretări contradictorii; în cel mai bun caz, reflectă viziunea de ansamblu a echipei de dezvoltare asupra rezultatelor proiectării sistemului. [2] :27 Există multe definiții ale arhitecturii. O colecție de definiții, legate în principal de arhitectura software , este compilată pe site -ul Institutului de Inginerie Software de la Universitatea Carnegie Mellon [3] .

În prezent, există o tendință puternică de a considera proiectarea arhitecturală și non-arhitecturală ca activități diferite; se încearcă definirea lor ca practici separate, dar aceste tipuri de design sunt în mare măsură „împletite”. Deciziile arhitecturale sunt văzute ca fiind mai abstracte, conceptuale și globale decât deciziile de proiectare convenționale; ele vizează succesul întregii misiuni şi structurile de cel mai înalt nivel ale sistemului [4] :272 .

Alte definiții ale arhitecturii sistemului

Istoria conceptului

Pe măsură ce complexitatea sarcinilor de rezolvat a crescut, a apărut nevoia de structurare a sistemelor. Cu toate acestea, practicienii au considerat că termenul „structură” este insuficient pentru a descrie toate aspectele sistemului [4] :272 .

Termenul „arhitectură” în ingineria sistemelor a fost introdus de profesorul Eberhardt Rechtin de la Universitatea din California de Sud la începutul anilor 1990 .  El credea că, pe măsură ce sistemele deveneau mai complexe, „designul lor la nivel înalt” (sau „designul conceptual”), așa cum era înțeles în acei ani, nu era suficient pentru a conduce inginerii și designerii să creeze proiecte precise și eficiente. El a studiat principiile arhitecturale în construcție pentru a înțelege cum sunt create și proiectate sistemele complexe (de exemplu, clădirile) [6] :223 .

Rekhtin explică termenul arhitectură de sistem după cum urmează:

Esența arhitecturii este structurarea. Structurarea poate însemna transformarea formei în funcție , extragerea ordinii din haos sau transformarea ideilor parțial formate ale unui client într-un model conceptual funcțional [6] :223-224 .

Termenii „arhitectură” și „proiect arhitectural” au fost folosiți de aproximativ 30 de ani, în special în ingineria software și în zonele cu probleme precum racheta și spațiul [4] :272 .

Concepte înrudite

Pentru o descriere mai detaliată a principiilor arhitecturii, standardul ISO/IEC/IEEE 42010-2011 introduce următoarele concepte [7] :2 .

Tipuri de arhitectură

Corpul de cunoștințe de inginerie a sistemelor (SEBoK) împarte arhitectura în logică și fizică [4] :269 .

Arhitectură logică

Arhitectura logică susține funcționarea sistemului de-a lungul întregului său ciclu de viață la nivel logic. Acesta constă dintr-un set de concepte și principii tehnice conexe. Arhitectura logică este reprezentată prin metode corespunzătoare grupelor tematice de descrieri și, cel puțin, include o arhitectură funcțională, o arhitectură comportamentală și o arhitectură temporală.

Arhitectura functionala . Arhitectura funcțională este un ansamblu de funcții și subfuncții ale acestora care determină transformările pe care sistemul le realizează atunci când își îndeplinește scopul.

Arhitectura comportamentală . Arhitectura comportamentală este un acord asupra funcțiilor și subfuncțiilor acestora, precum și a interfețelor (intrări și ieșiri), care determină secvența de execuție, condițiile de control sau fluxul de date, nivelul de performanță necesar pentru a satisface cerințele sistemului. Arhitectura comportamentală poate fi descrisă ca o colecție de scenarii, funcții și/sau moduri de operare interconectate.

Arhitectură temporară . Arhitectura temporală este o clasificare a funcțiilor sistemului, care se obține în funcție de nivelul de frecvență al execuției sale. Arhitectura temporală include definirea aspectelor sincrone și asincrone ale funcțiilor. Monitorizarea deciziilor care au loc în cadrul sistemului urmează aceeași clasificare temporală [4] :287 .

Arhitectură fizică

Scopul proiectării arhitecturii fizice este de a crea o soluție fizică, concretă, care să fie în concordanță cu arhitectura logică și să satisfacă cerințele de sistem specificate.

Odată definită arhitectura logică, trebuie identificate elementele fizice specifice care susțin proprietățile funcționale, comportamentale și temporale, precum și proprietățile așteptate ale sistemului derivate din cerințele sistemului nefuncțional.

O arhitectură fizică este o sistematizare a elementelor fizice (elementele sistemului și interfețele fizice) care implementează soluțiile proiectate pentru un produs, serviciu sau întreprindere. Este conceput pentru a satisface cerințele pentru sistem și elementele arhitecturii logice și este implementat prin elementele tehnologice ale sistemului. Cerințele de sistem sunt distribuite atât în ​​arhitecturi logice, cât și în arhitecturi fizice. Arhitectura globală a sistemului este evaluată prin analiza sistemului și, după ce toate cerințele sunt îndeplinite, devine baza pentru implementarea sistemului [4] :296 .

Descriere arhitecturală

O arhitectură poate fi capturată folosind o descriere completă a arhitecturii (AO) (vezi figura). Standardul ISO/IEC/IEEE 42010-2011 prescrie o distincție între arhitectura conceptuală a unui sistem și una dintre descrierile acelei arhitecturi, care este un anumit produs sau artefact.

În sistemele complexe, AO poate fi dezvoltat nu numai pentru sistemul ca întreg, ci și pentru componentele sistemului. Două AO conceptuale diferite pot include grupuri de descrieri care vor corespunde aceleiași metode de descriere. Deși sistemele descrise de aceste două grupuri de descriere vor fi legate ca întreg și parțial, acesta nu este un exemplu de grupuri de descriere multiple care corespund unei singure metode. Aceste AO sunt considerate separate chiar dacă sunt legate prin sistemele pe care le descriu [7] :3 .

Abordare conceptuală

Abordarea conceptuală definește termeni și concepte legate de conținutul și aplicarea AO. Figura prezintă principalele concepte și relațiile lor. Toate conceptele sunt definite în contextul unei arhitecturi specifice de sistem și al descrierii arhitecturale asociate. Nu trebuie să presupunem că există o singură arhitectură pentru un sistem sau că această arhitectură este reprezentată de o singură descriere arhitecturală.

În figură, casetele reprezintă clasele de entități.

Liniile care leagă dreptunghiurile reprezintă relațiile dintre entități. Comunicarea include două roluri (câte unul în fiecare direcție). Fiecare rol poate fi denumit opțional cu o etichetă. Un rol îndreptat de la A la B este [etichetat] mai aproape de B și invers. De exemplu, rolurile dintre „sistem” și „mediu” s-ar putea citi „„sistemul” trăiește în „mediu” și „„mediul” influențează „sistemul””. În figură, rolurile au o aritate de 1:1, dacă nu este menționat altfel. Un rol poate avea o aritate multiplă, de exemplu, un rol notat ca „1..*” este folosit pentru a desemna mulți, ca în relațiile unu-la-mulți sau mai mulți-la-unu. Rombul (la capătul liniei de comunicație) denotă relația unei părți a întregului. De exemplu, „grupurile de descriere” fac parte din „descrierea arhitecturală”. Această notație este împrumutată din UML.

Să luăm în considerare fiecare componentă a schemei conceptuale mai detaliat. În contextul schemei luate în considerare, sistemul se extinde la aplicații software individuale, sisteme în sens tradițional, subsisteme, sisteme de sisteme, produse, familii de produse, organizații în ansamblu și alte populații de interes.

Sistemul trăiește într-un mediu oarecare. Mediul unui anumit sistem poate influența acest sistem. Mediul sau contextul său definește mediul și circumstanțele dezvoltării, funcționării, influențelor politice și de altă natură asupra unui sistem dat. Un astfel de mediu poate include alte sisteme care interacționează cu sistemul țintă, fie direct prin interfețe, fie indirect în alte moduri. Un astfel de mediu definește limitele care definesc subiectul sistemului țintă în raport cu alte sisteme.

Fiecare sistem are unul sau mai mulți factori interesați . Fiecare parte interesată participă de obicei la sistem sau are un interes în sistem. Interesele implică luarea în considerare a unor aspecte ale sistemului precum performanța, fiabilitatea, securitatea, distribuția și capacitatea de a evolua.

Orice sistem există pentru a implementa una sau mai multe misiuni în mediul său.

În abordarea conceptuală, o descriere arhitecturală este organizată ca unul sau mai multe grupuri de descriere arhitecturală.

Descrierea arhitecturală selectează una sau mai multe metode de descriere adecvate de aplicat. Alegerea metodelor de descriere se bazează de obicei pe considerentele și interesele părților interesate cărora li se adresează AO. Definiția metodei de descriere poate apărea împreună cu AO sau poate fi definită separat. O metodă de descriere definită separat de AO se numește metodă de descriere a bibliotecii.

Un grup de descrieri poate consta din una sau mai multe descrieri arhitecturale. Fiecare astfel de descriere arhitecturală este elaborată folosind metodele stabilite de descriere arhitecturală adecvate acesteia. O descriere arhitecturală poate fi inclusă în mai mult de un grup de descrieri [7] :4-6 .

Tipuri de grup de descriere arhitectură

Există trei tipuri de grup de descriere: funcțional, logic și fizic. Fiecare dintre grupuri are scopul de a descrie propriile puncte de vedere și nivelul de complexitate corespunzător [6] :224 .

Descriere grup funcțional

Acest grup oferă o vizualizare utilizator sau operator care include produse legate de fazele, scenariile și fluxurile de sarcini ale sistemului de operare. Fluxul de informații poate fi vizualizat din perspectiva utilizatorului și sunt descrise și interfețele utilizatorului. Exemple de produse care pot fi incluse în această descriere ar fi date funcționale sau grafice, descrieri de scenarii (inclusiv utilizarea de studii de caz), diagrame de flux de sarcini, organigrame și diagrame de flux de informații [6] :224 .

Grup logic de descrieri

Acest grup oferă o vedere din punctul de vedere al managerului sau al clientului. Vederea logică include produse care definesc limitele sistemului cu mediul său și interfețele funcționale cu sistemele externe, precum și principalele funcții și comportamentul sistemului, fluxurile de informații, seturile de date interne și externe, utilizatorii interni și externi și interfețele funcționale interne. . Exemplele de produse includ diagrame bloc de flux funcțional (FFBD), diagrame de context, diagrame , diagrame IDEF0 , date diagramă de flux și diverse părți interesate - produse caracteristice (inclusiv produse specifice afacerii) [6] :224 .

Descrierile grupurilor fizice

Acest grup oferă o vedere din punctul de vedere al designerilor. Include:

  • produse care definesc limitele fizice ale sistemului;
  • componentele fizice ale sistemului și modul în care acestea interacționează și se influențează reciproc;
  • baze de date interne și structuri de date;
  • sisteme de infrastructură a tehnologiei informației (IT);
  • infrastructura IT externă cu care interacționează sistemul;
  • cerinţele necesare dezvoltării sistemului.

Produsul poate include diagrame bloc fizice la un nivel destul de ridicat de detaliu, topologii de baze de date , interfețe de gestionare a documentelor și standarde. Toate cele trei tipuri de grup trebuie să fie prezente în fiecare descriere a arhitecturii [6] :224 .

Aplicarea descrierilor arhitecturale

Descrierile arhitecturale în timpul ciclului de viață pot fi aplicate diferit de către toți părțile interesate. Astfel de aplicații includ, dar nu se limitează la, următoarele:

  • analiza arhitecturilor alternative
  • planificarea afacerilor pentru tranziția de la o arhitectură moștenită la o nouă arhitectură;
  • comunicarea organizațiilor implicate în dezvoltarea, producția, instalarea, operarea și întreținerea sistemelor;
  • comunicarea între clienți și dezvoltatori ca parte a pregătirii acordului;
  • criteriile pentru certificarea conformității unei implementări cu o arhitectură dată;
  • documentarea dezvoltării și întreținerii, inclusiv pregătirea materialelor pentru depozite pentru reutilizare și materiale de instruire;
  • input pentru activitățile ulterioare de proiectare și dezvoltare a sistemului;
  • materiale sursă pentru instrumente pentru crearea și analiza sistemului;
  • suport operațional și de infrastructură; gestionarea configurației și reparații; reproiectarea și întreținerea sistemelor, subsistemelor și componentelor;
  • sprijin pentru planificare și finanțare [7] :9 .

Note

  1. GOST R ISO / IEC 15288, 2008 .
  2. 1 2 Fowler M., 2006 .
  3. Community Software Architecture Definitions Arhivat 22 mai 2014 la Wayback Machine // Software Engineering Institute, Carnegie Mellon University
  4. 1 2 3 4 5 6 SEBoK, 2012 .
  5. Danilin, Slyusarenko, 2005 .
  6. 1 2 3 4 5 6 Systems Engineering Principles and Practice, 2011 .
  7. 1 2 3 4 ISO/IEC 42010, 2011 .

Literatură

  • GOST R ISO/IEC 15288-2008. Ingineria sistemelor - Procese ale ciclului de viață al sistemelor. — 2008.
  • Danilin A., Slyusarenko A. Arhitectură și strategie. "Yin" și "Yang" a întreprinderilor de tehnologia informației. - M. : Internet University of Information Technologies, 2005. - 504 p. — ISBN 5-9556-0045-0 .
  • Fowler M. Arhitectura aplicaţiilor software corporative.: Per. din engleza. — M.: Editura Williams, 2006. — 544 p. ISBN 5-8459-0579-6
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry și A. Squires (eds). Ghid pentru corpul de cunoștințe de inginerie a sistemelor (SEBoK) versiunea 1.0 . — Administratorii Institutului de Tehnologie Stevens, 2012.
  • Kossiakoff A., Sweet WN, Seymour SJ, Biemer SM Systems Engineering Principles and Practice. - Ed. a II-a. - Hoboken, New Jersey: A John Wiley & Sons, 2011. - 599 p. — ISBN 978-0-470-40548-2 .
  • ISO/IEC 42010:2011. Inginerie de sistem și software - Descrierea arhitecturii. — 2011.

Link -uri