Dovremmo includere servizi esterni in un diagramma di implementazione

Nella specifica UML , la Sezione 11 descrive i diagrammi dei componenti e la Sezione 19 descrive i diagrammi di distribuzione. Non c'è nulla che dice che puoi o non puoi includere sistemi, servizi o componenti esterni su entrambi i tipi di diagrammi.

Personalmente, probabilmente farei l'opposto di quello che stai facendo. Includerei servizi esterni sul diagramma di implementazione e non sul diagramma dei componenti.

L'intenzione del diagramma di implementazione è di "catturare le relazioni tra elementi logici e / o fisici di sistemi e tecnologie dell'informazione risorse assegnate a loro ". Gli utenti di un diagramma di implementazione includono le persone responsabili dell'infrastruttura fisica del sistema, per queste persone, sapendo che il sistema interagisce con i servizi esterni può essere utile, specialmente se ci sono specifiche porte di rete che devono rimangono aperti nei firewall o assicurati che le risorse fisiche che contengono artefatti specifici rimangano accessibili al mondo esterno.

D'altro canto, un componente è una "parte modulare di un sistema che incapsula il suo contenuto e la cui manifestazione è sostituibile nel suo ambiente". Le informazioni qui sono più importanti per la mappatura dei requisiti a pezzi del sistema software, la pianificazione per il riutilizzo, le interfacce specifiche tra i pezzi del sistema, fornendo una panoramica grafica degli elementi che possono essere scomposti in maggior dettaglio in altre viste del sistema. Questi sono più interessanti per gli sviluppatori di software e gli architetti a cui potrebbero non interessare tanto la natura specifica dei servizi e dove vivono, quanto piuttosto ciò che fa parte del sistema in fase di sviluppo e il modo in cui questi pezzi interagiscono.

Tuttavia, dovresti fare in modo che gli schemi abbiano un senso per te. Forse, per il tuo pubblico, mostrare i sistemi esterni sulla distribuzione e sui diagrammi dei componenti facilita la comunicazione. UML è uno strumento di comunicazione - fornisce un linguaggio comune per comunicare il design di un sistema software. La mia preferenza è di abbracciare molte delle tecniche agile modeling e attenermi alle notazioni standard e allo spirito della lingua, ma pensa a chi sono io fare il diagramma e cosa li aiuterà a fare il loro lavoro.

Mentre ThomasOwens lascia una risposta fantastica qui, ho un'opinione diversa sulla domanda posta, tuttavia non dirò che non è corretto. Dopotutto, come aveva già sottolineato, il diagramma dovrebbe avere il massimo vantaggio comunicativo restando il più concentrato possibile.

Esistono diversi tipi di diagrammi di distribuzione che è possibile creare e ciascun tipo può essere utilizzato per mostrare una vista univoca del sistema. I diagrammi di distribuzione possono essere utilizzati per mostrare la manifestazione fisica dei componenti in un sistema, una specifica per gli artefatti per gli obiettivi di distribuzione e sì anche l'infrastruttura fisica o logica di un sistema.

I servizi esterni e le connessioni FTP come Thomas Owens hanno detto che potrebbe essere importante comunicare l'infrastruttura logica del tuo sistema (ad esempio firewall, pacchetti software client FTP, ecc ...) a meno che tu non consideri questi servizi o posizioni di trascinamento FTP come parte della tua infrastruttura logica quindi non li mostrerei come Nodi nel tuo diagramma. Quello che faccio in genere è disegnare il bordo attorno alla mia infrastruttura logica, quindi avere una scatola nebulosa solo per mettere un nome a qualcosa all'altra estremità di quel percorso di comunicazione.

Preferisco comunque mostrare servizi esterni e simili nei diagrammi dei componenti. I componenti all'interno di un sistema operano tipicamente all'interno di un sistema più grande (ad esempio Enterprise, Internet, Intranet client su VPN, ecc.) Quindi visualizzo elementi come questo come componenti esterni con un'interfaccia ben definita. Poiché i componenti possono sia fornire sia richiedere interfacce ad altri componenti, è necessario dimostrare le interfacce dei componenti di sistema esterni in modo che sia chiaro ciò che richiede il componente. Documentare questo consente agli architetti e agli sviluppatori di ragionare più facilmente sui componenti che devono costruire.

Alla fine, però, non ci sono regole rigide per questo tipo di cose e, come sempre, attenersi alle linee guida vaghe dove puoi finché non ti danno beneficio. Un diagramma dovrebbe essere uno strumento per aiutare nella comunicazione di un sistema, quindi la cosa più importante è assicurarsi che il pubblico trovi tutte le risposte di cui ha bisogno e ottiene tutto ciò che vogliono dai tuoi diagrammi.