Ti raccomando di non prendere troppo vicino i diagrammi raffigurati. Quelli raffigurati nel libro di GoF dovrebbero essere esempi di riferimento. Inoltre, ci sono variazioni dei modelli causati dall'ambiente in cui viene utilizzato.
L'unica cosa che possiamo fare è validarla formalmente per UML e conformità logica.
Al primo diagramma vedo che il progettista voleva mostrare l'accumulo degli ordini nell'istanza dell'agente, quindi utilizza "< >", ma:
- All'interno di una grande casella gialla con codice di esempio
Client non chiama agent.sell() e quindi tutti trattenuti nell'istanza 'Agent' 'Gli ordini (bsc, ssc) non verranno mai elaborati.
- Uso di "< >" sottolinea che gli ordini sono trattenuti all'interno di "Agente" e la sua relazione è strong. L'uso dell'aggregazione (< >) invece di un'associazione semplice significa semantica più strong, ma penso che in questo specifico caso l'aggregazione non sia necessaria. Quindi, hai ragione, l'associazione semplice (freccia piena) è abbastanza buona.
- L'omissione della relazione tra istanze "Client" e "Agent" è un bug. Deve esserci una dipendenza (linea tratteggiata con < > e \ o < >) tra di loro.
- Inoltre, il progettista era incoerente nella sua decisione. Ha collocato in modo ridondante il campo '+ Stock: StockTrace' in 'BuyStockOrder' e 'SellStockOrder' e ha anche aggiunto l'associazione tra 'BuyStockOrder' e 'SellStockOrder' e 'StockTrace'. Ma per un caso simile con "Cliente" e "StockTrace", la classe "Cliente" non contiene il campo "+ Stock: StockTrace".
Al secondo diagramma non ci sono invocatori, quindi si presume che sia implicito :). L'unica cosa che voglio aggiungere che "usa anche la classe CallbackTwo per aggregare i ricevitori" è sbagliata. La parola "anche" è sbagliata.
- Esempio precedente raffigurato
Invoker (Agent) contenente Comamnds (Orders) , ma là Command (CallbackTwo) contiene alcuni dati ( Receiver ).
- Inoltre, la definizione di entrambe le associazioni e il campo privato in
CallbackTwo è ridondante.
