Come progettare un diagramma di classe UML per due sottosistemi?

Ci sono diverse possibilità per visualizzare i due sottosistemi.

Considerazioni preliminari

Ma il fatto che sia difficile modellare i due sistemi intrecciati in UML può indicare che ci sono alcuni problemi con la soluzione. Pertanto, per prima cosa è necessario porsi la domanda se siano realmente due sistemi. Esistono diverse possibili risposte alternative:

• i tuoi due sistemi sono un singolo sistema che ha due interfacce ^* ;
• uno dei due sistemi è costruito sopra l'altro;
• i tuoi due sistemi sono in realtà tre sistemi con i due sistemi che hai riconosciuto utilizzando le funzionalità comuni di un terzo sistema;
• i due sistemi sono un numero di micro servizi cooperanti (cioè sistemi a pieno titolo); o,
• sono davvero due (intrecciati) sistemi.

Una seconda domanda che puoi porsi è "se una classe C ha responsabilità completamente diverse nel sistema S ₁ rispetto al sistema S ₂ , è la stessa classe o dovrebbe essere due classi distinte ^** .

Per rispondere alla domanda.

Per visualizzare due sistemi intrecciati puoi usare il colore.

Ho usato classi in grey per indicare cose come "classi esistenti in un altro sistema che utilizza questo sistema" e "possibilità di estensione futura che esistono ma che non implementeremo all'inizio". Ad esempio, è possibile bluare le classi di colori oi metodi per il sistema S ₁ , giallo per il sistema S e verde per la condivisione tra entrambi i sistemi. Con qualche spiegazione i lettori umani lo capiranno e potranno vedere il quadro generale e il modo in cui i sistemi si riferiscono; gli strumenti automatici d'altra parte non saranno in grado di comprendere la semantica allegata al colore.

Oppure puoi utilizzare i pacchetti UML

Ogni sistema può fare riferimento all'altro sysem come pacchetto. È possibile creare un diagramma per ogni sistema. Includere l'altro sistema come un pacchetto nel diagramma del sistema corrente. E traccia le classi dall'altro sistema, che sono rilevanti per il sistema corrente, all'interno del pacchetto dell'altro sistema.

Gli strumenti UML comprendono i pacchetti. La dipendenza circolare può causare un problema. E quando usi i pacchetti devi davvero decidere con il sistema che appartiene a una classe. Non puoi rappresentare una classe con qualche metodo nel sistema * S ₁ e alcuni metodi nel sistema S ₂ con i pacchetti UML.

^{[*]: Forse con una o entrambe le interfacce del sistema che non forniscono l'accesso a tutte le funzionalità del sistema.}

^{[**]: Forse le due classi possono condividere lo stesso nome ma essere in pacchetti diversi (in termini UML) e in spazi dei nomi diversi nella tua lingua di implementazione.}

In una progettazione a livello di sistema, le classi di disegno sono troppi dettagli. La progettazione del sistema dovrebbe contenere solo i sottosistemi e possibilmente i componenti presenti nel sistema e il modo in cui sono connessi.
Nel tuo caso, la progettazione del sistema descrive i due sottosistemi e comunica solo attraverso il database condiviso.

Quando si progettano i sottosistemi, si descrivono le classi che ogni sottosistema ha e quali metodi ha ciascuna classe. Con due sottosistemi, creerai anche due progetti di sottosistemi.

Mi piace SysML (un profilo per UML) migliore di UML per fare questo tipo di progettazione di "Sistema di sistemi". La disposizione dei blocchi è un po 'più intuitiva. Inoltre, il gruppo di lavoro SysML ha fatto un grande sforzo per creare dei buoni costrutti di modellazione per le interfacce.