Community

De Ding Yi, supranumit Sanhua la Alibaba.

Valoarea comunicării tehnice nu se reflectă doar în modul în care sunt dezvoltate aplicațiile prin produse comerciale și proiecte open-source și în modul în care sunt accelerate diverse procese de lansare a afacerilor. Dar, valoarea sa se reflectă foarte mult și în experiența împărtășită de mai mulți ingineri remarcabili diferiți în îmbunătățirea productivității, optimizarea performanței produselor și promovarea experienței utilizatorului. Într-o propoziție, comunicarea tehnică este importantă pentru că ne îmbunătățește capacitățile profesionale.

În acest articol, un expert tehnic Alibaba, Ding Yi, va împărtăși ideile și experiența sa în crearea de diagrame arhitecturale eficiente.

Pentru a descrie sistemul nostru într-una sau mai multe diagrame, ne confruntăm adesea cu următoarele probleme:

• Nu știm de unde să începem.
• Nu știm cum să descriem sistemul într-o singură diagramă care să fie suficient de clară pentru ca echipele relevante de produs, operațiuni și dezvoltare să înțeleagă clar.
• La jumătatea drumului, ne dăm seama că nu știm cine este publicul.
• Nu știm dacă reprezentăm o diagramă funcțională a produsului, o diagramă tehnică sau pur și simplu un amestec.
• Când sunt prea puține casete în diagramă, nu știm ce să mai adăugăm.
• Nu suntem niciodată mulțumiți de aspectul diagramei.

Dacă v-ați confruntat cu aceleași probleme, acest articol prezintă o metodologie de desen pentru a produce diagrame arhitecturale clare.

Concepte

Ce este o arhitectură?

O „arhitectură” poate fi definită ca o descriere abstractă a entităților dintr-un sistem și a relațiilor dintre ele. Ea implică o serie de procese decizionale.

Arhitectura este o structură și o viziune.

O „arhitectură de sistem” este întruchiparea conceptelor și distribuția corespondențelor dintre funcțiile lucrurilor sau ale informațiilor și elementele formale. Ea definește relațiile dintre elemente, precum și dintre elemente și mediul înconjurător.

Constituirea unei arhitecturi solide este o sarcină complexă și un subiect important pentru noi de discutat aici. După ce construiți o arhitectură, părțile relevante trebuie să o înțeleagă și să îi urmeze dictaturile.

Ce este o diagramă de arhitectură?

O diagramă de arhitectură este o diagramă a unui sistem care este utilizată pentru a abstractiza conturul general al sistemului software și relațiile, constrângerile și limitele dintre componente. Este un instrument important, deoarece oferă o imagine de ansamblu a desfășurării fizice a sistemului software și a foii de parcurs a evoluției acestuia.

Care sunt funcțiile unei diagrame arhitecturale?

O diagramă, la fel ca o imagine, valorează cât o mie de cuvinte. Cu alte cuvinte, o diagramă arhitecturală trebuie să îndeplinească mai multe funcții diferite. Pentru a permite utilizatorilor relevanți să înțeleagă arhitectura unui sistem și să o urmeze în luarea deciziilor, trebuie să comunicăm informații despre arhitectură. Diagramele arhitecturale oferă o modalitate excelentă de a face acest lucru. Pentru a pune jos câteva funcții majore, o diagramă de arhitectură trebuie să:

• Înlătura barierele de comunicare
• Atinge un consens
• Diminuează ambiguitatea

Tipuri de diagrame de arhitectură

Diagramele pot fi clasificate în mai multe categorii. Un tip popular de diagramă este vederea 4+1, care include vederile de scenariu, logică, fizică, de proces și de dezvoltare a arhitecturii.

Vederea de scenariu

Vederea de scenariu descrie relațiile dintre participanții la sistem și cazurile de utilizare funcțională și reflectă cerințele finale și designul de interacțiune al sistemului. Această vedere este, în general, o diagramă a cazurilor de utilizare.

Vedere logică

Vederea logică este utilizată pentru a descrie relațiile dintre componente, constrângerile componentelor și limitele după defalcarea funcțiilor software ale sistemului. Ea reflectă compoziția globală a sistemului și modul în care este construit sistemul. Această vedere este, în general, o diagramă de componente UML sau o diagramă de clasă.

Vedere fizică

Vederea fizică descrie corespondența dintre software-ul sistemului și hardware-ul fizic și arată modul în care componentele sistemului sunt implementate pe un grup de noduri fizice calculabile. Aceasta oferă îndrumare în procesul de desfășurare a sistemului software.

Visualizare de proces

Visualizarea de proces descrie secvența de comunicare și intrările și ieșirile de date între componentele software ale sistemului și reflectă fluxurile funcționale și de date ale sistemului. Această vedere este prezentată în mod normal sub forma unei diagrame de secvență sau a unei diagrame de flux.

Vedere de dezvoltare

Vedere de dezvoltare este utilizată pentru a descrie diviziunea și compoziția modulelor sistemului și pentru a rafina proiectarea compozițională a pachetelor interne. Această vedere este utilizată de către dezvoltatori și reflectă procesele de dezvoltare și implementare a sistemului.

Cele cinci vederi arhitecturale de mai sus reprezintă caracteristici diferite ale unui sistem software din perspective diferite. Combinându-le într-o schiță arhitecturală, putem apoi să descriem foarte clar arhitectura generală a sistemului.

Ce face ca o diagramă arhitecturală să fie eficientă?

Cum putem ști dacă o diagramă este o diagramă bună? Și ce metode ar trebui să folosim pentru a crea o diagramă?

Diagramele de mai sus au fost selectate pentru a ilustra diferitele tipuri de diagrame, fără să ne gândim prea mult la calitatea lor. Credem că, pentru a descrie o diagramă arhitecturală bună, trebuie să știm cine este publicul nostru și să luăm în considerare ce informații dorim să transmitem. Prin urmare, nu ar trebui să reprezentăm o vedere fizică sau o vedere logică de dragul ei. Diagramele ar trebui să fie utilizate pentru a transmite cu acuratețe informațiile necesare unui anumit public pentru a fi eficiente. Abia apoi, ar trebui să ne facem griji cu privire la ce tip de diagramă este. Prin urmare, cel mai direct standard după care putem judeca calitatea unei desene este dacă publicul poate înțelege cu acuratețe informațiile pe care am încercat să le transmitem.

Aceasta înseamnă că o diagramă de arhitectură bună și eficientă nu trebuie să fie explicată publicului. Ea ar trebui să exprime de la sine tot ceea ce doriți să spuneți. Mai mult, o diagramă bună ar trebui, de asemenea, să aibă o structură coerentă, precisă față de datele pe care le reprezintă și să corespundă direct codului.

Provocări comune la reprezentarea diagramelor de arhitectură

Ce reprezintă un pătrat?

De ce folosim pătrate în loc de cercuri? Folosirea aleatorie a pătratelor sau a altor forme poate provoca confuzie.

Ce înseamnă liniile punctate și liniile continue? Ce înseamnă o săgeată? Ce înseamnă culorile?

Utilizarea arbitrară a liniilor sau săgeților poate duce la neînțelegeri.

Există conflicte între timpul de execuție și timpul de compilare? Există conflicte de nivel?

Construirea unei arhitecturi este o muncă complexă. Prin urmare, utilizarea unei singure diagrame pentru a reprezenta arhitectura poate duce cu ușurință la confuzii cu privire la aspecte specifice despre arhitectură.

Metoda de desenare recomandată de mine

Modelul C4 utilizează containere, cum ar fi aplicații, magazine de date și microservicii, precum și componente și cod pentru a descrie structura statică a unui sistem software. Aceste diagrame sunt ușor de desenat, iar elementele lor cheie sunt explicite. Cu toate acestea, cel mai important lucru este că pot indica în mod clar publicul vizat și semnificația fiecărei diagrame.

Următorul exemplu este preluat de pe site-ul oficial C4. Pe această bază, reușim să folosim propria noastră înțelegere pentru a exprima mai bine arhitectura software.

Diagrama contextului sistemului

Aceasta este o diagramă a unui sistem bancar planificat. Acesta utilizează un sistem bancar mainframe extern pentru a accesa conturile clienților și informațiile privind tranzacțiile și trimite e-mailuri către clienți prin intermediul unui sistem de e-mail extern. După cum puteți vedea, diagrama este simplă și clară. Nu necesită nicio explicație suplimentară pentru ca publicul să o înțeleagă. De asemenea, putem vedea că ea conține sistemul care urmează să fie construit, clienții sistemului și sistemele periferice care interacționează cu acest sistem.

Utilizare

O astfel de diagramă simplă poate spune ce tip de sistem urmează să fie construit, cine sunt utilizatorii săi, cine îl va manipula și cum va fi integrat într-un mediu IT existent. Publicul acestei diagrame poate fi personalul intern al echipei de dezvoltare, personalul tehnic extern sau personalul non-tehnic. Ea ne spune:

• Ce sistem urmează să fie construit?
• Cine îl va manipula?
• Cum este integrat în mediul IT existent?

Cum se reprezintă diagrama

În această diagramă, propriul sistem se află în mijloc, iar utilizatorii și sistemele care interacționează cu acest sistem sunt plasate în jurul său. Aspectul cheie al acestei diagrame este că organizează și arată clar utilizatorii și dependențele de nivel înalt ale sistemului care urmează să fie construit. După ce munca conceptuală este realizată, este nevoie doar de câteva minute pentru a reprezenta diagrama.

Diagrama containerului

Diagrama containerului extinde sistemul din diagrama anterioară a contextului sistemului.

În figura precedentă, pe lângă utilizatori și sisteme periferice, sistemul care urmează să fie construit include o aplicație web bazată pe Java Spring MVC pentru a oferi un portal de funcții pentru sistem, în timp ce o aplicație mobilă bazată pe Xamarin oferă un portal de funcții pentru clienții mobili. O aplicație API bazată pe Java oferă servicii, iar pentru stocare se utilizează o bază de date MySQL. Săgețile indică interacțiunile dintre aplicații.

Când vă uitați la această diagramă, nu veți observa dacă cutiile au colțuri ascuțite sau rotunjite sau dacă săgețile au linii continue sau punctate. Nici măcar direcțiile săgeților nu atrag prea mult atenția.

Există multe metode de desenare, toate acestea definind semnificațiile cadrelor și liniilor. Acest lucru presupune ca atât cel care desenează cât și cel care privește diagrama să înțeleagă clar aceste definiții. Numai atunci pot fi înțelese toate informațiile din diagramă. Cu toate acestea, acest lucru este solicitant, iar mulți privitori vor prinde doar conceptele generale.

Utilizare

Publicul acestei diagrame poate fi dezvoltatorii interni sau externi sau personalul O&M. Această diagramă servește următoarelor scopuri:

• Prezintă structura generală a sistemului software.
• Reflectă procesul de luare a deciziilor tehnice la nivel înalt.
• Află cum sunt distribuite responsabilitățile în sistem și cum interacționează containerele între ele.
• Le spune dezvoltatorilor unde este necesară programarea codului.

Cum se reprezintă diagrama

Această diagramă utilizează cadre, care pot include nume, alegeri tehnice, responsabilități și interacțiuni între cadre. Dacă este implicat un sistem extern, cel mai bine este să se definească granița.

Diagrama de componente

O diagramă de componente este utilizată pentru a extinde un container și a descrie modulele sale interne.

Utilizare

Această diagramă este destinată dezvoltatorilor interni și le arată cum să organizeze și să dezvolte codul. Această diagramă servește următoarelor scopuri:

• Descrie componentele sau serviciile sistemului.
• Clarifică relațiile și dependențele dintre componente.
• Furnizează un cadru care arată cum pot fi distribuite și livrate sarcinile de dezvoltare software.

Diagrama de cod sau de clasă

Această diagramă este destinată personalului de suport tehnic. Este un tip comun de diagramă și, prin urmare, nu o vom descrie în detaliu.

Studiu de caz

Figura următoare prezintă arhitectura unui instrument intern de date în timp real. Deoarece o diagramă arhitecturală ar trebui să fie evidentă, nu este nevoie de prea multe explicații. Dacă nu o puteți înțelege clar, diagrama nu este cu siguranță suficient de bună.

Există multe metodologii pentru reprezentarea unei diagrame arhitecturale bune. Acest articol prezintă metoda C4, care însă este și ea în continuă evoluție. În ciuda acestui fapt, indiferent de metodologia de desenare, trebuie pur și simplu să luăm în considerare intenția desenului și să o comunicăm mai bine cu publicul. Nu trebuie să fim restricționați în mod nejustificat de reguli în procesul de desenare. Pe scurt, înainte de a începe o diagramă, întrebați-vă: Cui se adresează, despre ce este vorba și cum să o facem intuitivă și ușor de înțeles.

Despre autor: Sanhua este expert tehnic la Alibaba. Zijing, Pengsheng și Yule au contribuit, de asemenea, la acest articol. Ding Yi a lucrat anterior în motorul de fluxuri de lucru R&D timp de mai mulți ani, dar acum se concentrează pe arhitectura și dezvoltarea aplicațiilor de internet mobil cu monedă mare. Cei care au contribuit la acest articol fac parte din Departamentul LST al Alibaba.

Sunteți dornici să cunoașteți cele mai recente tendințe tehnologice din Alibaba Cloud? Ascultați-le de la experții noștri de top în seria noastră recent lansată, Tech Show!

.