Come rappresentare un tipo specifico di dipendenza dell'interfaccia nel diagramma dei componenti?

Question

Come rappresentare un tipo specifico di dipendenza dell'interfaccia nel diagramma dei componenti?

#1 da (0 voti)

1

Attualmente sto attraversando un periodo difficile con la creazione di un diagramma di componenti che dovrebbe rappresentare un certo tipo di dipendenza da componente / interfaccia e spero che tu possa darmi qualche suggerimento. Come sfondo, ho iniziato a studiare UML e ingegneria del software solo qualche settimana fa, quindi presumo di avere una barriera di pensiero e / o sto facendo cose più complicate del necessario.

Supponiamo di avere un componente "virtuale" Servizi . In questo componente voglio raccogliere e modellare tutti i servizi che il mio sistema può offrire. Successivamente, ho un componente Admin che (a questo livello) può utilizzare (e quindi dipendere da) qualsiasi servizio fornito da Servizi . Ultimo ma non meno importante, c'è un componente Utente che può utilizzare solo un servizio specifico che è già noto. Questo sarebbe correttamente rappresentato dal diagramma dei componenti allegato? In caso contrario, come sarebbe rappresentato correttamente? Vorresti solo indicare che Utente dipende anche dalla porta Servizi e modellare la dipendenza dell'interfaccia conrete in un diagramma diverso? È una dipendenza da Admin alla porta Servizi il modo corretto di mostrare la dipendenza all'interfaccia Servizi "virtuale" o sarebbe meglio mostra solo una dipendenza dal componente Servizi ?

Grazie per il tuo aiuto e amp; la pazienza
Daniel

interfaces component uml

posta LtSchnitzel 03.09.2018 - 10:06

fonte

1 risposta

Leggi altre domande sui tag interfaces component uml

Che cos'è una funzione che crea funzioni chiamate? Come testare il viaggio del cliente con la maggior parte della stessa struttura

score 0 · Answer 1

Prima di tutto, il tuo diagramma sembra buono e documenta molto bene la tua architettura. Tuttavia, se si prende UML per lettera, ci sono alcuni aspetti da chiarire.

Qual è la natura del tuo componente "virtuale"?

Il tuo diagramma dice che Service è un sottosistema / componente che è esso stesso composto da UserService , Service1 , Service2 . Ciò sarebbe coerente con il termine "virtuale", che suggerisce che Service è un raggruppamento mentale dei componenti in qualcosa di più grande.

Tuttavia, il termine "virtuale" è ambiguo. È possibile che Service possa essere una componente reale che offre servizi virtuali e che funge da facciata o gateway API al mondo esterno? In questo caso, dovrebbe essere rappresentato come componente separato.

Link ambigui

Sul lato interno, i connettori delegati suggeriscono che la porta Service è una porta complessa che fornisce 3 interfacce diverse.

Tuttavia, sul lato esterno, il singolo UserService lollipop indica che la porta è una porta semplice che fornisce solo quel servizio. Questo è almeno quello che dice lo standard UML 2.5 in Fig.11.3 Parti e ruoli con le porte e Fig.11.4 Notazioni alternative per connettere parti e ruoli

Le seguenti soluzioni potrebbero rimuovere questa contraddizione:

Rimuovi l'ambiguo UserService lollipop: allora vedi che il componente User dipende dai servizi (che offrono diverse interfacce), ma il socket USerService di User mostra che richiede solo quei servizi. Da lì il lettore può dedurre che non può usare le altre interfacce in quanto non le conosce.
Utilizza una porta Service diversa per UserService : l'utente sarebbe quindi connesso solo a quella porta, mentre Admin verrebbe collegato a entrambe le porte.
Usa una disambiguazione artistica, aggiungendo al tuo diagramma corrente un paio di lecca-lecca senza nome alla porta Service , per chiarire che si tratta di una porta complessa, anche se l'Utente ne usa solo uno specifico.