Gli oggetti JavaScript e PHP devono essere trattati come oggetti diversi in un diagramma di interazione?

_{Data l'incertezza della mia risposta, la faccio diventare una wiki della comunità. Sentiti libero di modificarlo.}

Dipende dal livello di astrazione che usi. Un modo è quello di essere indipendenti dalla lingua. Ecco un esempio di diagramma di sequenza :

Fonte: Esempi di diagrammi di sequenza UML

Come puoi vedere, il diagramma comprende sia lato client che lato server. Applicare lo stesso a un diagramma di comunicazione sarebbe più difficile, dal momento che i diagrammi di comunicazione hanno generalmente un ambito più piccolo, ma è ancora possibile.

Il fattore principale da prendere in considerazione è qual è lo scopo del tuo diagramma di comunicazione.

• Una possibilità è usare un diagramma di comunicazione per mostrare l'intero processo. Tale diagramma può essere indipendente dalla lingua e mescolare diverse parti del sistema o dei livelli all'interno di esso.

  Questo è adatto per una visione d'insieme di un sistema in un modo molto astratto. Può essere usato, ad esempio, per dare un'idea generale a un nuovo sviluppatore di alcune cose complicate che avvengono tra un client e un servizio, tra JavaScript e il linguaggio lato server o tra un utente e la sua API.

  Se la tua azienda ha un singolo sviluppatore che esegue sia la programmazione client che quella lato server, allora tale diagramma potrebbe esserti utile.

• Un'altra possibilità è usare un diagramma di comunicazione per mostrare il flusso preciso all'interno di uno strato di una parte di un sistema. Qui, altre parti e livelli sarebbero interpretati come scatole nere che comunicano attraverso le interfacce.

  Questo è adatto per una visione dettagliata del flusso di comunicazioni all'interno di un sistema. Ad esempio, uno sviluppatore di JavaScript si preoccupa del flusso di comunicazioni che avviene nel browser, ma non si preoccupa delle cose sul lato server. Allo stesso modo, uno sviluppatore di un'API non avrà bisogno di guardare il diagramma delle comunicazioni che spiega come un client dell'API si occupa dei diversi messaggi.

  Se la tua azienda ha programmatori dedicati lato client e programmatori dedicati lato server, probabilmente preferirebbero questo tipo di diagrammi di comunicazione (che non esclude che dovrebbero avere anche una buona visione generale dell'intero sistema.)

In pratica, non ho mai visto diagrammi di comunicazione così generici da includere, ad esempio, sia i client che i server. Non penso che sia sbagliato fare questi diagrammi, ma non è una pratica comune.

Modifica: ho parlato con un collega più esperto di me in UML; il suo suggerimento è di creare due diagrammi di comunicazione, uno per JavaScript, un altro per il lato server. Mescolare entrambi renderebbe il diagramma più complicato di quanto dovrebbe essere, e alcune persone potrebbero non capire quale fase sta accadendo dove.

Quindi, a meno che tu non sia sicuro che avere un singolo diagramma ti avvantaggerà, segui diagrammi separati che puoi affiancare per una visione d'insieme.