Che cos'è un diagramma appropriato per descrivere l'architettura del software

-3

Mi chiedo se ci sono tipi di schemi ben accettati / standardizzati per descrivere l'architettura di un software che implementa per esempio un Clean Architecture .

Con architettura software , intendo un insieme di moduli, che vengono definiti utilizzando astrazioni di alto livello senza includere librerie, framework, database.

Finora, ho trovato solo il diagramma dei componenti come diagramma adatto. È corretto per rappresentare i diversi livelli del mio software? Ed è sufficiente documentare l'architettura del software?

    
posta bxfvgekd 27.11.2017 - 23:19
fonte

3 risposte

3

Qual è lo scopo dei livelli?

L' architettura pulita mira a raggiungere la separazione delle preoccupazioni , dividendo il software in strati concentrici. La principale differenza rispetto alle tradizionali architetture stratificate è il principio di dipendenza: le parti esterne dipendono dalla parte interna e non il contrario.

Nell'architettura a strati, i livelli più alti dipendono dal livello inferiore. Tuttavia, per ragioni grafiche, il livello più basso tende a fare affidamento (e quindi a dipendere) dal livello di accesso ai dati che si trova nell'anello esterno nelle architetture pulite. Questo porta quindi alle entità che dipendono dal livello di accesso al database, quindi dalla loro implementazione.

Per architetture concentriche e stratificate, esiste comunque una base comune: i livelli corrispondono a un raggruppamento logico di dipendenze. Questi raggruppamenti possono in alcuni casi coincidere con componenti, ma non è una regola generale.

Come diagrammi i livelli in UML

In UML non esiste un singolo diagramma di architettura che riassuma tutto. Per quanto riguarda un edificio, la cui architettura sarà descritta da diversi diagrammi (ad esempio diagramma di facciata frontale, diagramma laterale, diagramma di terra per l'implementazione dell'edificio sul terreno, e un diagramma per ogni piano) l'architettura del software sarà descritta con diversi diagrammi che ciascuno si concentra su diversi aspetti.

Per i livelli, il raggruppamento logico delle risorse correlate del software e le relative dipendenze viene mostrato in un pacchetto schema . Un pacchetto può raggruppare non solo classi, ma anche componenti e casi d'uso. Qui un bel esempio .

Più architettura

Viste strutturali

Al livello più alto, descrivi il sistema preso in considerazione nel suo ambiente e descrivi le funzioni principali. Per questo avrai un schema dei casi d'uso .

Quindi puoi dividere il sistema in componenti indipendenti e mostrare come questi sono correlati tra loro. Lo descriveresti in un diagramma dei componenti .

Quindi puoi ingrandire e mostrare la struttura interna dei componenti e mostrare le classi che vengono assemblate come componenti. Lo mostri con un diagramma composito .

Infine, ingrandirai ulteriormente e mostrerai i dettagli delle classi e delle loro associazioni in un diagramma di classe.

Vista comportamentale: la vita interiore della tua struttura

Per ciascuno di questi aspetti strutturali, puoi anche mostrare aspetti comportamentali pertinenti:

  • per ogni classificatore, puoi documentarne il ciclo di vita spiegando in un diagramma di stato i diversi afferma che un oggetto o un componente potrebbero avere e come gli eventi stanno cambiando questo stato.
  • con diagramma di sequenza puoi modellare come interagiscono gli oggetti
  • con diagrammi delle attività puoi modellare la panoramica di un flusso complesso di esecuzione che coinvolge oggetti.

Vista fisica

Tutti questi componenti e artefatti sono stati considerati così lontani dal punto di vista logico (cioè come lo vede lo sviluppatore). Tuttavia, a volte è necessario comprendere come questi componenti verranno distribuiti sull'infrastruttura operativa, ad esempio cosa succede sul server e cosa succede sul client.

Per questo, puoi utilizzare i diagrammi di implementazione , che mostrano come i componenti / gli artefatti sono distribuiti tra i nodi (ad es. hardware e all'interno di un dispositivo, diversi ambienti operativi (sistema operativo, server virtuali, ecc.).

Nota finale

L'ordine sopra è puramente illustrativo. In generale l'elaborazione di un tale modello è iterativa. Quindi puoi anche iniziare con un diagramma di classe, elaborare le interazioni, mettere a punto le classi, assemblarle in compositi, ecc ...

    
risposta data 28.11.2017 - 22:32
fonte
1

Ci sono molti approcci allo sviluppo di software. Alcuni non usano affatto diagrammi. Quindi non esiste una sola risposta "giusta".

Detto questo, se stai cercando idee per diagrammi di architettura, forse considera la vista architettonica 4 + 1 approccio, che potrebbe includere:

  • Diagrammi dei componenti
  • Diagrammi del pacchetto
  • Diagrammi delle classi
  • Diagrammi di stato
  • Diagrammi di implementazione
  • Diagrammi delle attività
  • Digram di sequenza
  • Usa visualizzazione caso
risposta data 28.11.2017 - 04:46
fonte
1

Risposta breve - Dipende.

Risposta più lunga, dipende dal pubblico. Lo schema è rivolto agli sviluppatori che implementeranno il software oi dirigenti di livello "C" che accetteranno il finanziamento per implementare il software? Lo stesso diagramma non soddisfa entrambi i gruppi. Come dice TOGAF, tutto riguarda il "punto di vista" e la stessa architettura può sembrare molto diversa dai diversi gruppi di stakeholder.

Segui la tua strada verso modelli di livello inferiore di dettagli crescenti, forse la soluzione Gli architetti sono in una posizione migliore per crearli. Costruisci su ciò che è lì, crea ciò che non è all'inizio di alto livello e aggiungi tatticamente i dettagli mentre le aree vengono elaborate. Non sprecare tempo e denaro per dettagliare dettagliatamente un sistema stabile su cui non si sta lavorando.

Usa diagrammi di alto livello per mostrare gli elementi costitutivi principali e cosa parla di cosa. Usa il colore per evidenziare le somiglianze e le differenze, usa il colore per evidenziare le aree di interesse. I dirigenti sono praticamente cablati per eliminare Red e Amber, utilizzare quella psicologia a proprio vantaggio.

A livelli più bassi forse è appropriata una notazione più formale (ad esempio UML) ma solo se i consumatori del modello possono comprendere la notazione e ottenerne il valore altrimenti si sta perdendo tempo.

I diagrammi di architettura sono principalmente uno strumento di comunicazione, quindi non rimanere troppo attaccato alla formalità, a meno che tu non sia in un ambiente molto formale.

    
risposta data 28.11.2017 - 07:22
fonte

Leggi altre domande sui tag