Semantica di modellazione UML

In my opinion it's not necessary to describe semantics of diagram elements which are already standardized by UML.

Sì, non sarebbe necessario descrivere la semantica degli elementi del diagramma quando quella semantica sarebbe correttamente definita da qualche parte nello standard UML. Il problema è che, specialmente con MDD, la semantica completa dipende dalla generazione del codice per questi elementi e poiché non esiste uno standard ampiamente accettato per la mappatura UML-to-code, lo standard UML non semplicemente non definisce l'intera semantica per i suoi elementi. Infatti, anche i paragrafi "Semantica UML" nello standard riguardano principalmente la sintassi UML e fornisce solo una nozione molto informale sulla semantica.

Ovviamente, quando si esegue MDD e si dispone dei generatori di codice, è possibile creare una meta-descrizione solo una volta, indicando quale semantica si applica a voi / al vostro team / al vostro progetto / alla vostra azienda, invece di distribuire lo stesso descrizione con ogni diagramma ancora e ancora.

Ecco un documento scientifico che si occupa del problema che la semantica UML è per lo più informale . Una ricerca su google per "uml semantic rules" ti porterà più articoli a discutere approfonditamente di questo argomento.

Hai ragione nel dire che gli stereotipi non dovrebbero aver bisogno di spiegazioni esplicite (a parte la loro definizione, se usi qualche stereotipo personalizzato per qualche motivo); questo è il punto di usare uno stereotipo. Questo di solito non significa che tu possa evitare di descrivere le cose, dato che è raro che il software sia solo un coordinamento di stereotipi. Alcune descrizioni, anche sulle parti che fanno qualcosa di interessante (come l'emissione di un ID o l'esecuzione di un calcolo) possono salvare un sacco di complessità altrove. Si noti che il testo in una lingua leggibile dall'uomo non è l'unico modo per farlo; a seconda di ciò che si sta facendo, equazioni matematiche, annotazioni semantiche da un'ontologia o anche collegamenti a documenti accademici appropriati possono essere più adatti. Tutto dipende.

È possibile scrivere virtualmente un intero programma usando UML e la generazione di codice appropriata. Probabilmente non vorrai farlo per niente di reale, dato che la difficoltà di gestire la complessità delle dimensioni dei diagrammi richiesti per descrivere un programma di dimensioni medie renderà l'uso di modelli di progettazione grafica come UML piuttosto poco pratico. UML è buono per l'architettura, il cui scopo reale deve essere mostrato ai programmatori in modo che capiscano l'immagine più grande, ma non è adatto al lavoro dettagliato. (Rabbrividisco a pensare alla complessità dei miei programmi a livello di UML se espongo tutto ...)

Non penso che il punto del docente sia che i commenti dovrebbero insegnare più e più volte su ciò che rappresenta UML. Invece, interpreto la tua domanda come un caso speciale di: Devo commentare il mio codice? Se sì, come? .

La solita controversia riguarda il fatto che la tua produzione (essendo codice o UML) sia auto-documentante senza bisogno di commenti, o se i commenti in realtà aggiungano un valore alla tua produzione o se i commenti siano coerenti con la tua produzione.