ncora qualche premessa.
E' proprio vero. Provate a fare una riunione per discutere del vostro dominio attorno ad un tavolo, tra developer, esperti di dominio, architetti e chi volete voi, e vedrete che ognuno andrà per la propria strada. Farà le proprie supposizioni e i propri voli pindarici.
Provate a schizzare un grafico alla lavagna con sole 5 classi in UML e fare la stessa riunione con le stesse persone e vi accorgerete della differenza.
Quella sola presenza al centro del tavolo riesce a far tenere l'attenzione sul modello analitico (di cui è una mera rappresentazione), e pone le basi per una corretta evoluzione.
UML presenta però un limite: può diventare mastodontico mostrare il funzionamento del modello.
Lo Static Class Diagram si ferma alle classi, agli attributi e alle loro relazioni. Poi ci vuole anche un Sequence Diagram a mostrare il vero scopo delle funzioni. Ma può non essere sufficiente. Quello che sfugge all'UML stesso è il significato vero e proprio del modello. Purtroppo la visualizzazione grafica di una relazione o una dipendenza non ne esprime il vero significato. Così come una business rules è difficilmente rappresentabile.
Dalla bibbia secondo Eric Evans:
"...The diagram's purpose is to help communicate and explain the model.
The code can serve as a repository of the details of the design.
Well-written Java is as expressive as UML in its way..."