Come tradurre un diagramma di classi in codice?

Dipende molto dal tuo obiettivo su cosa ottenere con il tuo design.

Come sembra, non stai prendendo di mira un generatore di codice che traduce direttamente il tuo diagramma di classe in codice. Quindi, il diagramma è proprio questo: una bella immagine. Potresti voler prima ripensare al valore effettivo che ottieni e perché stai facendo lo sforzo. Contrariamente a quello di scarabocchiare il diagramma su una lavagna con i tuoi colleghi e una volta che sei soddisfatto, scatta una foto. Qual è la grande differenza?

Per quanto riguarda le tue domande: hai bisogno di includere l'architettura nella fase di progettazione - lo spereremmo. L'intero punto dell'architettura è di essere un quadro in cui si adattano le considerazioni di progettazione. Quindi, chiaramente, dovrai tenerne conto.

Hai bisogno di rivedere il tuo diagramma durante il codice? Questo dipende ancora da perché hai quel diagramma. Se vuoi che descriva il tuo codice, allora ovviamente deve essere rivisto. Se tutto ciò di cui hai bisogno è di poter dire alla gente "guarda, questo è come l'avevamo immaginata tre anni fa. Niente nel codice è qualcosa di simile a questo ora, però" quindi sentitevi liberi di trascurarlo.

Se avessi comunque bisogno di un diagramma UML aggiornato, ti suggerisco caldamente di avvicinarti alla modellazione vera e propria (al contrario del semplice disegno) in modo tale che tu possa generare codice e quindi assicurarti che il diagramma sia realmente corrispondente al tuo codice.

Infine un'osservazione sul tuo metodo "100% del tempo" per scrivere il tuo codice: sebbene questo non abbia nulla a che fare con le tue domande attuali, ti esorto a riconsiderare la tua idea di scrivere la logica di business (come l'emissione di uno stato) in gestori di azioni. Ciò viola molti buoni principi di progettazione. Se ti piace leggere, puoi dare un'occhiata al libro DDD di Eric Evans per ottenere una migliore idea di come la logica di business come quella sia servita meglio.

During the design stage ... However, during coding stage ....

Innanzitutto, risolviamo la tua confusione qui. Scrivere codice è design. Quindi quello che stai facendo non è "design", quindi "codice", è tutto di design.

Se UML è sempre utile è discutibile, ma a qualcuno piace usarlo per aiutarli a visualizzare le possibili soluzioni. Come" Zio Bob "lo mette nel suo libro" Agile Software Development: Principles, Patterns and Practices ":

So, yes, diagrams can be inappropriate at times. When are they inappropriate? When you create them without code to validate them, and then intend to follow them. There is nothing wrong with drawing a diagram to explore an idea.

Se segui le buone pratiche dell'uso di TDD e dello sviluppo iterativo, è praticamente garantito che il codice differirà da qualsiasi disegno UML che crei. Come ulteriore vantaggio, è meno probabile che tu finisca con la logica di business nei gestori di eventi e simili. Questo codice scarsamente differenziato e strettamente accoppiato raramente si sviluppa usando l'approccio TDD.

Per quanto riguarda il fatto che i due differiscono, hai due possibilità:

1. Se puoi, tratta l'UML come un esercizio di brainstorming / lavagna e buttalo via.
2. Se ti viene richiesto da qualche contratto o processo per produrre UML, quindi esegui il codice attraverso un generatore UML automatico per produrre quei diagrammi. E prova a cambiare la tua cultura aziendale per rimuovere la necessità di farlo.

Venire con i disegni (in questo caso l'UML) aiuta a visualizzare come il codice diventerà alla fine. Non vale la pena avere una classe con i suoi metodi che non possono essere tradotti in codice. In breve quello che hai la carta deve corrispondere al codice. Metodi come SearchBookActionHandler dovrebbero essere inclusi nel design della classe a meno che tu non abbia alcuni casi di ereditarietà che possono ancora essere interfacciati, ma devono ancora apparire nel tuo UML. E l'architettura del software è in fase di progettazione ... Sì, dovrebbe essere fattorizzato.