In primul articol am identificat cateva din provocarile care apar atunci cand dezvoltam diagrame arhitecturale – de la culorile pe care le alegem pana la amestecarea elementelor statice cu cele de runtime sau dezvoltarea unor diagrame care sunt prea aglomerate.

Instructiuni pentru dezvoltarea diagramelor arhitecturale

In afara de provocarile discutate in articolul anterior si care ar fi util sa faca parte dintr-un checklist pe care sa il avem langa noi, exista si o serie de reguli generale legate de modul in care ar trebui sa arate o diagrama:

Alegeti numarul optim de diagrame

• Philippe Kruchten spunea ca “arhitectura este un animal complex. Folosirea unei singure schite pentru a reprezenta arhitectura duce la o semantica neinteligibila.” Pentru a documenta sistemele moderne nu putem sa avem doar un singur model de diagram, dar cand dezvoltam diagrame arhitecturale nu este de fiecare data foarte usor sa ne dam seama ce diagrame sa alegem si cat de multe sa cream. Sunt mai multi factori pe care trebuie sa ii luam in considerare inainte de a lua o decizie. Cum ar fi spre exemplu natura si complexitatea arhitecturii, abilitatile si experienta arhitectului software, timpul disponibil, volumul de munca necesar pentru a le mentine si elementele care au sens sau sunt utile din punct de vedere al cerintelor persoanelor implicate in proiect. Spre exemplu, un inginer de retea va vrea probabil sa vada un model explicit al retelei unde apar host-urile, porturile de comunicare si protocoalele folosite. Un administrator de baze de date ar fi interesat de modul in care sistemul manipuleaza, distribuie si administreaza datele. Pe baza acestor aspecte, este recomandat sa alegem numarul optim de diagrame, indiferent de cat de multe sunt.
• Daca exista un numar insufficient de diagrame (e.g. nivel scazut de documentare), anumite aspecte care tin de arhitectura ar putea sa fie ascunse sau nedocumentate. Pe de alta parte daca sunt prea multe, efortul necesar pentru a le actualiza s-ar putea sa fie foarte mare.

Pastrati o consistenta structurala si semantica intre diagrame

• Fiecare diagrama trebuie sa fie la fel ca celelalte in termeni de forme, margini, culori folosite etc. Designul ar trebui sa fie asemanator si fiecare persoana cheie implicata in proiect nu ar trebui sa aiba dificultati in a intelege diagramele dezvoltate de diferiti developeri din cadrul unei echipe. Ideal ar fi sa avem un singur program cu ajutorul caruia sa facem diagrame si sa il folosim in toate proiectele.
• Din punct de vedere semantic, fiecare din aceste diagrame ar trebui sa fie sincronizate periodic intre ele dar si cu ultimele schimbari la nivel de cod, din moment ce o schimbare operata intr-o diagrama are un impact asupra altora. Acest proces poate sa fie activat manual sau automat folosind un instrument de modelare. Acesta din urma este de preferat, insa acest lucru depinde de la proiect la proiect – indiferent de situatie, idea de baza este sa avem consistenta intre diagrame si cod. Simon Brown spunea ca “diagramele nu sunt utile pentru imbunatatiriea arhitecturii daca ele nu sunt legate de cod”, aspect care scoate in evidenta idea de consistenta semantica.

Prevenirea fragmentarii diagramelor

• Atunci cand avem multe diagrame nu este dificila doar intelegerea descrierii arhitecturii ci avem de-a face si cu un efort mult mai intens pentru a le actualiza. Ca efect secundar, poate sa apara si fragmentarea (spre exemplu doua sau mai multe diagrame ilustreaza acelasi atribut de calitate – performanta, scalabilitate etc – dar fiecare interpretata individual nu este completa). In astfel de cazuri este recomandat fie sa eliminam diagramele care nu reflecta in mod relevant atributele de calitate (mai exact cele care nu sunt legate de cerinte arhitecturale semnificative) sau, si mai bine, de a uni diagramele (precum concurrency si deployment)
  

Asigurati-va ca diagramele sunt versionate

• Pentru a putea verifica istoricul unei diagrame, trebuie sa putem compara diferite versiuni dar trebuie sa si putem sa revenim la o versiune anterioara daca este necesar. Folosirea unui tool de modelare care nu permite acest lucru ar putea sa fie un impediment. Ultimele trenduri din industrie se bazeaza pe folosirea unui limbaj simplu si intuitiv de pe urma carora se pot genera diagrame – aspect care pana acum pare ca a rezolvat provocarea legata de trasabilitate. Un alt avantaj al unei astfel de abordari este ca asigura in mod implicit o consistenta structurala omogena intre diagrame.
  

Adaugati legende langa diagramele arhitecturale

• Daca nu urmariti un limbaj standard de descriere al arhitecturii (e.g. UML, ArchiMate), atunci detaliati fiecare element al diagramei in legenda (forme, margini, linii, culori, acronime etc.)
• Daca nu este cazul, adaugati in legenda doar limbajul pe care il folositi si nu mai este nevoie de alte explicatii, din moment ce fiecare persoana care o citeste stie ce limbaj sa foloseaca pentru a intelege.

Face vreo diferenta limbajul care descrie arhitectura (UML, ArchiMate)?

Sunt nenumarate opinii legate de limbajul care ar trebui ales intr-un proiect. Unii oameni sustin ca UML-ul este rigid si ca nu este indeajuns de flexibil pentru a modela un design de arhitectura – un punct de vedere cu care sunt de acord. Cu toate acestea, in anumite cazuri poate sa fie mai mult decat suficient pentru a documenta elementele fundamentale ale unei arhitecturi fara a ne baza pe functiile extensiilor UML precum profile sau stereotipuri. Uitandu-ne la alte limbaje de descriere arhitecturala, putem sa vedem ca ArchiMate este mult mai puternic si mai potrivit pentru modelarea sistemelor de tip enterprise in comparatie cu UML-ul. Mai exista, spre exemplu, si BPMN care este orientat mai degraba spre procesele de business. Aceasta comparatie poate continua insa nu intentionez sa le revizuiesc in detaliu, nu este obiectivul acestui articol.

Faptul ca avem un limbaj de descriere arhitectural care este indeajuns de cuprinzator si flexibil este un pas major si aceste doua aspecte ar trebui sa conteze atunci cand facem o alegere. Dar din perspectiva mea, adevarata problema este alta si are de a face cu faptul ca in multe cazuri nu avem documentatie legata de arhitectura. De multe ori oamenii considera aceasta etapa ca fiind plictisitoare, nefolositoare si lipsita de scop. Numarul de proiecte software fara documentatie sau care au documentatie lipsa sau incorecta este imens. Nu cred ca acest lucru se intampla pentru ca oamenii nu folosesc un limbaj corect. Mai degraba, acest lucru apare pentru ca cei implicati in proiect nu dezvolta nici un fel de documentatie legata de arhitectura (inclusiv diagrame de arhitectura). Si mai rau decat asta, multi nici nu stiu cum sa dezvolte documentatia asa cum trebuie.

Sunt niste lucruri pe care trebuie sa le adresam mai intai pentru a intelege de ce documentatia conteaza si cum sa o dezvoltam corect. Mai exact pregatirea programatorilor pentru asta si selectarea instrumentelor potrivite.

Cum putem sa ne asiguram ca diagramele sunt actualizate pe masura ce sistemul este dezvoltat si arhitectura se schimba?

Sunt cateva abordari legate de actualizarea diagramelor si mai jos voi discuta despre cateva dintre ele. Prima optiune si cea mai usoara, ar fi sa generam in mod automat diagrame pe baza codului sursa. Acest lcuru ne-ar asigura ca absolut tot ceea ce generam este consistent cu codul. Din pacate, cu instrumentele actuale pe care le avem la dispozitie acest lucru nu este inca pe deplin posibil (cel putin nu din cunostintele mele). Instrumentele actuale nu pot sa dezvolte o diagrama utila si corecta doar pe baza codului sursa, fara ca noi sa intervenim. Len Bass spunea ca “mediul de dezvoltare ideal este unul unde documentatia este disponibila fara efort, doar apasand un buton”. Implicit vorbea de generarea automata a diagramelor, dar nu am ajuns inca in acest punct in industria software.

O a doua abordare ar fi ca mai intai sa dezvoltam diagramele folosind un tool dedicat care apoi sa genereze un schelet al codului sursa (componente/pachete cu limitari, APIs) si care mai tarziu sa fie folosit de programatori. In acest fel fiecare schimbare la nivel de arhitectura trebuie sa fie activata din cadrul diagramei care ar putea sa genereze sau sa actualizeze automat codul schelet.

Ultimul tip de abordare implica actualizarea manuala a diagramelor de fiecare daca cand o functionalitate noua este implementata – o functionalitate care are un impact asupra designului arhitecturii. Pentru a ne asigura ca toate schimbarile la nivel de cod se reflecta in diagrame, este recomandat sa punem actualizarea diagramelor conform “definition of done” in cadrul procesului de dezvoltare. Acest scenariu nu este chiar recomandabil deoarece ar putea sa genereze cu usurinta diagrame lipsite de consistenta sau neactualizate (i.e. programatorii uita de multe ori sau nu vor sa actualizeze diagramele) si din pacate acest lucru inca se intampla in multe proiecte.

Luand in considerare instrumetele pe care le avem acum la dispozitie, recomandarea mea este sa avem un mix. Sa imbinam diagramele generate automat cu cele dezvoltate manual. Spre exemplu, incercati sa generati automat diagrame, care pot sa fie cu usurinta randate de catre tool-uri pe baza codului sursa si fara prea multe provocari (informatii prea multe sau lipsite de importanta). In aceasta categorie putem sa includem oricare din diagramele cu un nivel ridicat de volatilitate (mai predispuse la schimbari frecvente si cu un nivel de abstractizare mai scazut) sau dimpotriva diagrame statice. Asemenea diagrame ar putea sa fie cele de context, de arhitectura de referinta, diagramele pentru pachete, diagramele pentru clase etc.

Cu toate acestea, in anumite cazuri nu este chiar atat de evident, doar pe baza codului sursa, modul in care sistemul indeplineste o parte din atributele legate de calitate (disponibilitate, scalabilitate, performanta) astfel ca generarea automata de diagrame nu este suficienta. Trebuie sa fie completata cu diagrame modelate manual. Spre exemplu diagrame de secventa, diagrame de stare, diagrame de concurenta, diagrame deployment sau diagrame operationale.

Ce complicatii sau simplificari apar pentru diagramele de arhitectura atunci cand lucram cu arhitecturi moderne (e.g. microservices)?

Microservices sau orice alt stil arhtiectural modern (e.g. serverless, event driven) pune in miscare doar structura sistemului, modul in care componentele comunica unele cu altele (relatiile dintre ele) si ce principii le guverneaza. Personal nu consider ca stilul arhitectural ar trebui sa schimbe principiile sau conceptele ce tin de crearea diagramelor (si implicit descrierea arhitecturala) si nici ce ar trebui sa reprezinte. Cu toate acestea, cand discutam despre sistemele de arhitectura moderne, care au de obicei un nivel de complexitate mai mare in comparatie cu sistemele clasice (monolit), acestea au un impact asupra descrierii arhitecturale si implicit asupra diagramelor.

Mai exact sunt niste aspecte de care trebuie sa avem grija. Aceste aspecte ar putea sa tina de intelegerea numarului de componente distribuite (distributed microservices), tipul fiecarei componente, cum comunica componentele intre ele (API, mesaje, protocoale), ciclul lor de viata si de ce tine fiecare componenta.

Ca sa putem avea toate aceste lucruri in vedere trebuie sa vizualizam fiecare componenta a sistemului, dezvoltarea acestuia, implementarea acestuia si modul in care va opera. Imaginati-va un un sistem cu un numar impresionant de microservicii. In aceasta situatie numarul de diagrame ar putea sa creasca considerabil deoarece fiecare microserviciu ar putea ajunge sa aiba propriul set de diagrame.

Astfel ca apar provocari legate de consistenta (schimbarea unui API pentru un serviciu are un impact asupra altor servicii si astfel toate diagramele in care acestea sunt reflectate trebuie actualizate). Putem avea fragmentare (disponibilitatea sau performanta ridicata intre servicii distribuite nu este consolidata intr-o singura diagrama) sau dificultati legate de responsabilitati (cine este responsabil sa ilustreze, intr-o maniera consolidata, aspectele legate de monitorizare sau securitate in cadrul tuturor elementelor sistemului). Separat, pot sa apara si provocari legate de modul in care echipa lucreaza sau colaborareaza in cadrul proiectului si chiar si dupa terminarea acestuia pentru a mentine diagramele actualizate.

Asa ca trebuie sa fiti atenti deoarece sistemele moderne cu arhitecturi complexe pot sa aduca provocari in plus care pot duce la complicatii la nivelul diagramelor arhitecturale.

Vrei sa iti imbunatatesti abilitatile de arhitectura software?
Inscrie-te la cursul nostru de Arhitectura software - Metodologie si Concepte

Ionut Balosin
Software Architect