ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 31
Abonament PDF

Arhitectura software (I)

Levente Veres
Design Lead
@Endava
PROGRAMARE


Timpul trece, știința evoluează, cerințele oamenilor cresc, adaptarea la schimbări în orice domeniu devine cerință de bază. În același timp, așteptările sunt în creștere dacă vine vorba despre calitate, accesibilitate, securitate și nu în ultimul rând cost.

Industria de IT din ultimi ani a adus în discuție necesitatea sau inutilitatea arhitecturii de software sau arhitecților de software.

În articolele ce vor urma doresc să abordăm câteva teme legate de domeniul arhitecturii de software și cel al rolurilor de arhitect software, business, IT etc. Vom încerca să schițăm un proces de lucru care să ne ajute la crearea unei arhitecturi. Vom aborda cerințele unui document SAD (software architecture document), ce Framework-uri putem aplica (4+1 View model, Togaf, Zachman), uneltele ce se pot folosi și desigur niște noțiuni care țin mai mult de Business, resurse umane şi comunicarea cu alții.

Istoria arhitecturii software

Cuvântul în sine provine din limba latină architectura, adaptat la rândul său din cuvântul grecesc arkhitekton. Acesta este un cuvânt compus din arkhi (lider, șef, cel pe care se poate urma) și cuvântul tekton (constructor, artizan, creator, planificator, maestru în domeniu).

În IT primele noțiuni au apărut în ani 60, urmând ca după ani80 când deja sistemele au ajuns la o complexitatea ce necesita organizare și planificare mai eficientă, dezvoltatorii au început să exploateze avantajele de a planifica intenționat structura soluțiilorîn diferite domenii. Au început să definească soluții comune pentru probleme specifice sau repetabile, reutilizabile.

Să nu uitam ca în `79 a apărut primul calculator personal (Apple II) care aducea cu el VisiCal (predecesorul lui Excel ). În 1981 apare MS-DOS, iar în 1983 apare Word din bucătăria firmei Microsoft.

Până la finele anilor `90 s-au tot definit metodologii, teorii, "best practice"- uri în diferite domenii din industria IT și structuri comune refolosibile. În 1995, Philippe Kruchten definește modelul arhitectural de "4+1 View" unde descrie vederile (view) :logical view, development view, process view, physical view și scenarios (cunoscut și sub numele de use case view).

Punctul culminant l-au adus anii 2000 când cunoștințele și teoriile acumulate au început să se aplice în practică. Momentan suntem participanți activi la aplicarea și popularizarea necesității arhitecturilor software și metodologiilor aferente.

Din studiile realizate de IEEE am selectat graficul de mai jos care oferă o vizualizare completă a evoluției arhitecturii software.

Ce este Arhitectura software?

Arhitectura software poate fi definită în termeni generali ca structura de nivel superior a unui sistem. În cartea Software Architecture in Practice, Third Edition, apărută în 2012 la Addison-Wesley (autorii Bass, Clements și Kazman) se definește în următorul format:

_"Arhitectura este rezultatul unui set de decizii de afaceri și tehnice. Schița (desing) în momentul creării este influențat_ădin mai multe părți, astfel și execuția va fi influențată de schimbări în funcție de mediul din jur pe care arhitectul trebuie să cunoască."

["An architecture is the result of a set of business and technical decisions. There are many influences at work in its design, and the realization of these influences will change depending on the environment in which the architecture is required to perform."]

Maturitatea domeniul de arhitectură software

O altă definiție din aceeași lucrare este: "Arhitectura software a unei aplicații sau sistem este structura sau structura sistemelor, ce combină elemente de aplicații, proprietățile vizibilității externe a acestor elemente și relația între ele."

IASA (The Global IT Architect Association) definește noțiunea de IT arhitectură ca: "Arta sau știința schițării (design) și arta de a livra strategie tehnologică utilă."

Dar arhitectura software poate fi considerată ca un mediu de facilitare de discuții a alegerii unei soluții de aplicații între solicitanții aplicației (business owner, stackeholder) și cei care vor livra, astfel încât să se ia decizii fundamentale de creare de aplicații care pe parcurs vor ajuta ca produsul finit să aibă factori de cerințe satisfăcătoare tuturor. Dintre acești factori menționăm: eficiență de cost, extensibilitate, modularitate, adaptabilitate, scalabilitate, securitate, calitate etc. .

Concluzionând, putem considera arhitectura software ca mediul de definire a structurilor, elementelor și a relațiilor.

Scopul Arhitecturii software.

Scopul unei arhitecturi de software poate fi diferit, de la caz la caz în funcție de necesitățile specificațiilor inițiale. Totuși se poate defini un subset de scopuri comune care vizează:

  1. Beneficiile care sunt aduse în urma modificărilor.
  2. Selectarea motivației principale referitoare la crearea sau schimbarea soluției? (De exemplu, de ce dorim ca noua aplicație de HR să aibă acces la cheltuielile personale din aplicația XYZ).
  3. Perspectiva generală asupra structurilor, interacțiunilor cu alte sisteme (high level overview)
  4. Componentele, cerințele importante. Acestea vor fi punctele critice care pot avea impact major. De exemplu: securitatea aplicației sau aspectul responsiv al interfeței.

Lista se poate extinde după dorințele fiecăruia, e important ca la final să se răspundă la întrebările:

  1. Ce dorește să rezolve arhitectura software?
  2. Costurile acesteia? E asumabilă de către beneficiar?
  3. Implicațiile personalelor- _stackeholder-_i, dezvoltatori, designeri, arhitecți, project manager-i, administratori de sisteme.

Planul de arhitectură SAD (Software Architecture Document) .

Ecosistemul de arhitectură IT

Putem considera că o arhitectura software este încadrat într-un ecosistem organizațional ce e întreținut de sisteme care la rândul lor sunt compuse din aplicații, hardware, structura de organizație, surse și structuri de informații.

Nivelele de arhitectură din IT se pot structura astfel:

  1. Arhitectura de Întreprindere (Enterprise) este compusă din arhitecturile de mai jos, dar are un status mai special prin interferența sa cu mediul de afaceri și cu implicațiile sale asupra mai multor sub entități sau firme (Cross Company Boundaries).
  2. Arhitectura software, cu scop de definire a designului de aplicație, componente/elemente și relație între componente/elemente.
  3. Arhitectura hardware definește designul de hardware necesar cum ar fi CPU, spațiu de stocare, spațiu de memorie, mediu de transfer de date (Wan, Lan), echipamente conexe (ex.: imprimanta sau echipament de scanare), medii de backup, medii de funcționare (in house, hosted, cloud).
  4. Arhitectura organizațională definește relațiile de afaceri (business relations), procese de afaceri (business process), structură organizațională (ierarhizare), roluri și responsabilități, competentele organizaționale (departamentele) și relația lor.
  5. Arhitectura informațională definește structura entităților de date, sursa și organizarea acestora, de fapt structura datelor și accesibilitatea eficientă acestora în diferite baze de date.

Sperăm că prin acest prim articol am reușit să vă introducem într-un domeniu complex precum cel al arhitecturii software.

LANSAREA NUMĂRULUI 87

Prezentări articole și
Panel: Project management

Joi, 19 Septembrie, ora 18:00
Hugo (The Office), Cluj-Napoca

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • Colors in projects