Il diagramma è un diagramma di classe UML , usando le notazioni per classi, associazioni (con molteplicità) e generalizzazione. Sebbene la notazione utilizzi UML perfettamente valido, sembra essere in una delle notazioni meno complete che Martin Fowler descrive come UML come note o UML come schizzo . Sta usando correttamente la simbologia della lingua, ma omettendo i dettagli per renderlo più facile da leggere. Tale notazione è utile per comunicare tra le persone, ma non supporta qualcosa come l'ingegneria avanzata dai modelli al codice.
Nel diagramma che hai presentato, ciascuna delle scatole è una classe. Esiste una classe Game con metodi pubblici roll(int) e score() , una classe Frame con metodo pubblico score() e una classe Roll con una variabile membro privata pins . Esiste anche una classe TenthFrame che eredita da Frame .
Alcuni dettagli sui membri delle classi sono stati omessi dal diagramma. Ad esempio, esiste una relazione di associazione tra Game e Frame - Game conosce 10 istanze di Frame . L'uso della relazione di associazione implica che Game non solo conosca l'interfaccia di Frame (una dipendenza su Frame ), ma mantiene anche 10 istanze come parte dell'oggetto. Sebbene tu possa mostrarlo esplicitamente aggiungendo una variabile membro a Game che mostri una matrice di oggetti con il 10% diFrame, questo è semplicemente la duplicazione di ciò che la relazione di associazione ti sta già mostrando. Esiste una relazione simile tra Frame e Roll - a Frame ha almeno 1 e non più del 2 Roll s.
Guardando attraverso le diapositive a cui sei collegato, hai ragione che la soluzione finale non sembra utilizzare nulla di diverso da una classe Game (almeno che posso vedere guardando attraverso il codice nella diapositiva). Quando si seguono i principi di Agile Modeling, ci sarebbe una singola fonte di informazioni , il che significa che probabilmente questi modelli sarebbero stati gettati via dopo che il codice è stato scritto e sono sopravvissuti alla loro utilità.
Ciò che sembra accaduto è che gli autori hanno usato UML (poiché è una notazione familiare e standardizzata) per analizzare il problema e spiegare come è stato scomposto. Tuttavia, mentre stavano scrivendo il codice, decisero che non avevano bisogno di tutte le classi per realizzare l'implementazione più semplice. Tuttavia, l'atto di modellazione ha migliorato la loro comprensione del problema e le regole ad esso associate, ma potrebbe non aver guidato l'implementazione.
