Community

Di Ding Yi, soprannominato Sanhua in Alibaba.

Il valore della comunicazione tecnica non si riflette solo nel modo in cui le applicazioni vengono sviluppate attraverso prodotti commerciali e progetti open-source e nel modo in cui vengono accelerati vari processi di lancio del business. Ma, il suo valore si riflette anche nell’esperienza condivisa da diversi ingegneri eccezionali nel migliorare la produttività, ottimizzare le prestazioni del prodotto e promuovere l’esperienza dell’utente. In una frase, la comunicazione tecnica è importante perché migliora le nostre capacità professionali.

In questo articolo, un esperto tecnico di Alibaba, Ding Yi, condividerà le sue idee ed esperienze nella creazione di diagrammi architettonici efficaci.

Per descrivere il nostro sistema in uno o più diagrammi, spesso incontriamo i seguenti problemi:

• Non sappiamo da dove cominciare.
• Non sappiamo come descrivere il sistema in un diagramma che sia abbastanza chiaro da essere compreso chiaramente dai team dei prodotti, delle operazioni e dello sviluppo.
• A metà strada, ci accorgiamo di non sapere chi è il pubblico.
• Non sappiamo se stiamo rappresentando un diagramma funzionale di prodotto, un diagramma tecnico o semplicemente un misto.
• Quando ci sono troppo poche caselle nel diagramma, non sappiamo cos’altro aggiungere.
• Non siamo mai soddisfatti del layout del diagramma.

Se vi siete imbattuti negli stessi problemi, questo articolo introduce una metodologia di disegno per produrre chiari diagrammi architettonici.

Concetti

Che cos’è un’architettura?

Un'”architettura” può essere definita come una descrizione astratta delle entità in un sistema e le relazioni tra loro. Implica una serie di processi decisionali.

L’architettura è una struttura e una visione.

Una “architettura di sistema” è l’incarnazione dei concetti e la distribuzione delle corrispondenze tra le funzioni delle cose o delle informazioni e gli elementi formali. Definisce le relazioni tra gli elementi così come tra gli elementi e l’ambiente circostante.

Costruire una buona architettura è un compito complesso e un grande argomento da discutere qui. Dopo aver costruito un’architettura, le parti interessate devono capirla e seguire i suoi dettami.

Che cos’è un diagramma architettonico?

Un diagramma architettonico è un diagramma di un sistema che viene usato per astrarre lo schema generale del sistema software e le relazioni, i vincoli e i confini tra i componenti. E’ uno strumento importante in quanto fornisce una visione d’insieme della distribuzione fisica del sistema software e la sua roadmap di evoluzione.

Quali sono le funzioni di un diagramma architettonico?

Un diagramma, come un’immagine, vale più di mille parole. In altre parole, un diagramma architettonico deve servire diverse funzioni. Per permettere agli utenti rilevanti di capire un’architettura di sistema e seguirla nel loro processo decisionale, abbiamo bisogno di comunicare informazioni sull’architettura. I diagrammi architettonici forniscono un ottimo modo per farlo. Per mettere giù alcune funzioni principali, un diagramma architettonico ha bisogno di:

• Rimuovere le barriere di comunicazione
• Raggiungere un consenso
• Ridurre l’ambiguità

Tipi di diagrammi architettonici

I diagrammi possono essere classificati in molte categorie. Un tipo popolare di diagramma è la vista 4+1, che include le viste scenario, logica, fisica, processo e sviluppo dell’architettura.

Vista scenario

La vista scenario descrive le relazioni tra i partecipanti al sistema e i casi d’uso funzionali e riflette i requisiti finali e il design dell’interazione del sistema. Questa vista è generalmente un diagramma dei casi d’uso.

Vista logica

La vista logica è usata per descrivere le relazioni dei componenti, i vincoli dei componenti e i confini dopo la scomposizione delle funzioni software del sistema. Riflette la composizione generale del sistema e come il sistema è costruito. Questa vista è generalmente un diagramma dei componenti UML o un diagramma di classe.

Vista fisica

La vista fisica descrive la mappatura tra il software del sistema e l’hardware fisico e mostra come i componenti del sistema sono distribuiti ad un gruppo di nodi fisici calcolabili. Fornisce una guida nel processo di distribuzione del sistema software.

Vista del processo

La vista del processo descrive la sequenza di comunicazione e l’input e output di dati tra i componenti software del sistema e riflette i flussi funzionali e di dati del sistema. Questa vista è normalmente presentata come un diagramma di sequenza o un diagramma di flusso.

Vista di sviluppo

La vista di sviluppo è usata per descrivere la divisione e la composizione dei moduli del sistema e perfezionare il design compositivo dei pacchetti interni. Questa vista è usata dagli sviluppatori e riflette i processi di sviluppo e implementazione del sistema.

Le cinque viste architettoniche di cui sopra rappresentano diverse caratteristiche di un sistema software da prospettive diverse. Combinandole in un blueprint architettonico, possiamo descrivere molto chiaramente l’architettura generale del sistema.

Cosa rende un diagramma architettonico efficace?

Come possiamo sapere se un diagramma è un buon diagramma? E quali metodi dovremmo usare per creare un diagramma?

I diagrammi di cui sopra sono stati scelti per illustrare i diversi tipi di diagrammi, con poca attenzione alla loro qualità. Noi crediamo che, per rappresentare un buon diagramma architettonico, dobbiamo sapere chi è il nostro pubblico e considerare quali informazioni vogliamo trasmettere. Pertanto, non dovremmo rappresentare una vista fisica o una vista logica per se stessa. I diagrammi dovrebbero essere usati per trasmettere accuratamente le informazioni richieste da un certo pubblico per essere efficaci. Solo allora, dovremmo preoccuparci di quale tipo di diagramma sia. Quindi, lo standard più diretto con cui possiamo giudicare la qualità di un disegno è se il pubblico può capire accuratamente le informazioni che abbiamo cercato di trasmettere.

Questo significa che un buon ed efficace diagramma architettonico non ha bisogno di essere spiegato al pubblico. Dovrebbe esprimere tutto ciò che si vuole dire da solo. Inoltre, un buon diagramma dovrebbe anche avere una struttura coerente, accurata ai dati che sta rappresentando, e corrispondere direttamente al codice.

Common Challenges When Depicting Architectural Diagrams

What does a square represent?

Perché usiamo i quadrati invece dei cerchi? L’uso casuale di quadrati o di altre forme può causare confusione.

Cosa significano le linee tratteggiate e le linee continue? Cosa significa una freccia? Cosa significano i colori?

L’uso arbitrario di linee o frecce può portare a malintesi.

Ci sono conflitti tra runtime e compile time? Ci sono conflitti di livello?

Costruire un’architettura è un lavoro complesso. Perciò, usare solo un diagramma per rappresentare l’architettura può facilmente portare a confusione su aspetti specifici dell’architettura.

Il mio metodo di disegno consigliato

Il modello C4 usa contenitori, come applicazioni, negozi di dati e microservizi, così come componenti e codice per descrivere la struttura statica di un sistema software. Questi diagrammi sono facili da disegnare e i loro elementi chiave sono espliciti. Tuttavia, la cosa più importante è che possono indicare chiaramente il pubblico e il significato di ogni diagramma.

L’esempio seguente è dal sito ufficiale di C4. Su questa base, riusciamo ad usare la nostra comprensione per esprimere meglio l’architettura del software.

Diagramma del contesto del sistema

Questo è un diagramma di un sistema bancario pianificato. Utilizza un sistema bancario mainframe esterno per accedere ai conti dei clienti e alle informazioni sulle transazioni e invia e-mail ai clienti attraverso un sistema di posta elettronica esterno. Come potete vedere, il diagramma è semplice e chiaro. Non richiede alcuna spiegazione aggiuntiva perché il pubblico lo capisca. Possiamo anche vedere che contiene il sistema da costruire, i clienti del sistema, e i sistemi periferici che interagiscono con questo sistema.

Usage

Un diagramma così semplice può dire quale tipo di sistema deve essere costruito, chi sono i suoi utenti, chi lo manipolerà, e come sarà integrato in un ambiente IT esistente. Il pubblico di questo diagramma può essere il personale interno del team di sviluppo, il personale tecnico esterno o il personale non tecnico. Ci dice:

• Quale sistema deve essere costruito?
• Chi lo manipolerà?
• Come è integrato nell’ambiente IT esistente?

Come rappresentare il diagramma

In questo diagramma, il tuo sistema è al centro, e gli utenti e i sistemi che interagiscono con questo sistema sono posti intorno ad esso. L’aspetto chiave di questo diagramma è che organizza e mostra chiaramente gli utenti e le dipendenze di alto livello del sistema da costruire. Dopo aver fatto il lavoro concettuale, ci vogliono solo pochi minuti per rappresentare il diagramma.

Diagramma contenitore

Il diagramma contenitore espande il sistema nel precedente diagramma del contesto del sistema.

Nella figura precedente, oltre agli utenti e ai sistemi periferici, il sistema da costruire include un’applicazione web basata su Java Spring MVC per fornire un portale di funzioni per il sistema, mentre un’applicazione mobile basata su Xamarin fornisce un portale di funzioni per i clienti mobili. Un’applicazione API basata su Java fornisce i servizi, e un database MySQL è usato per l’archiviazione. Le frecce indicano le interazioni tra le applicazioni.

Quando guardate questo diagramma, non noterete se le caselle hanno angoli acuti o arrotondati o se le frecce hanno linee solide o tratteggiate. Anche le direzioni delle frecce non attirano molta attenzione.

Ci sono molti metodi di disegno, tutti che definiscono i significati dei riquadri e delle linee. Ciò richiede che sia il disegnatore che l’osservatore del diagramma comprendano chiaramente queste definizioni. Solo allora tutte le informazioni nel diagramma possono essere comprese. Tuttavia, questo è impegnativo, e molti spettatori coglieranno solo i concetti generali.

Uso

Il pubblico di questo diagramma può essere costituito da sviluppatori interni o esterni o da personale O&M. Questo diagramma serve ai seguenti scopi:

• Presenta la struttura generale del sistema software.
• Riflette il processo decisionale tecnico di alto livello.
• Mostra come le responsabilità sono distribuite nel sistema e come i contenitori interagiscono tra loro.
• Dice agli sviluppatori dove è richiesta la programmazione del codice.

Come rappresentare il diagramma

Questo diagramma usa dei frame, che possono includere nomi, scelte tecniche, responsabilità e interazioni tra i frame. Se è coinvolto un sistema esterno, è meglio definire il confine.

Diagramma dei componenti

Un diagramma dei componenti è usato per espandere un contenitore e descrivere i suoi moduli interni.

Uso

Questo diagramma è destinato agli sviluppatori interni e mostra loro come organizzare e sviluppare codice. Questo diagramma serve ai seguenti scopi:

• Descrive i componenti o i servizi del sistema.
• Chiarisce le relazioni e le dipendenze tra i componenti.
• Fornisce un quadro che mostra come i compiti di sviluppo del software possono essere distribuiti e consegnati.

Codice o diagramma di classe

Questo diagramma è destinato al personale del supporto tecnico. È un tipo comune di diagramma, e quindi non lo descriveremo in dettaglio.

Caso di studio

La figura seguente mostra l’architettura di uno strumento interno di dati in tempo reale. Poiché un diagramma architettonico dovrebbe essere evidente, non c’è molto bisogno di spiegazioni. Se non si riesce a capirlo chiaramente, il diagramma non è sicuramente abbastanza buono.

Ci sono molte metodologie per rappresentare un buon diagramma architettonico. Questo articolo introduce il metodo C4, che tuttavia è anche in continua evoluzione. Nonostante ciò, indipendentemente dalla metodologia di disegno, dobbiamo semplicemente considerare l’intenzione del disegno e comunicarla meglio al pubblico. Non dobbiamo essere indebitamente limitati da regole nel processo di disegno. In breve, prima di iniziare un diagramma, chiedetevi: Per chi è, di cosa si tratta, e come renderlo intuitivo e comprensibile.

Informazioni sull’autore: Sanhua è un esperto tecnico di Alibaba. Anche Zijing, Pengsheng e Yule hanno contribuito a questo articolo. Ding Yi ha lavorato in precedenza nel motore di flusso R&D per molti anni, ma ora si sta concentrando sull’architettura e lo sviluppo di applicazioni Internet mobile ad alta valuta. I collaboratori di questo articolo provengono dal dipartimento LST di Alibaba.

Sei curioso di conoscere le ultime tendenze tecnologiche di Alibaba Cloud? Ascoltalo dai nostri migliori esperti nella nostra serie appena lanciata, Tech Show!