Limitazioni di UML? [chiuso]

Ho incontrato difficoltà nel tentare di utilizzare UML:

• come strumento di comunicazione, è più lento del diagramma ad hoc. Immagina di essere in piedi a una lavagna, dicendo a un altro sviluppatore come funziona un'interazione basata sul callback. Probabilmente disegneresti due caselle che rappresentano il chiamante e il chiamato, quindi parlerai con il tuo collega durante il processo mentre disegni le frecce ogni volta che dici " questo invia il messaggio foo ", e scrivendo le proprietà nelle caselle quando dici "così questo restituisce la sua barra ". In UML, sono necessari due diagrammi (un diagramma di classe per le proprietà e un diagramma di sequenza per le frecce).
• come modello di un sistema complicato (il codice), è ancora abbastanza complicato. Molte persone hanno sottolineato nei commenti che il mio reclamo di cui sopra non è valido perché c'è un tipo di diagramma che può fare ciò che voglio. Questo rappresenta un problema diverso: è abbastanza difficile ricordare i dettagli di UML che usarlo come un semplice modello per scopi di comunicazione è difficile.
• come strumento di documentazione, può richiedere troppe pianificazione anticipata. Non ricordo le specifiche del mio problema, ma alcuni anni fa stavo documentando una struttura del pacchetto per un'applicazione Mac (quindi non scritta). Lo strumento che stavo usando per costruire l'UML ha rafforzato i vincoli nel linguaggio. Penso che stavo cercando di esprimere qualcosa del tipo "questa classe consumerà un'interfaccia esposta da qualcosa in questo pacchetto, ma non ho ancora deciso cosa farò così a livello di pacchetto. Come ho detto, non lo faccio ricorda se questo era il mio compito esatto, ma i vincoli dell'UML significavano che lo strumento non mi avrebbe permesso di farlo.
• come strumento di generazione del codice (o analisi del codice), le sue capacità potrebbero non essere mappate esattamente sulla lingua di destinazione. È progettato per linguaggi di programmazione orientati agli oggetti basati sulla classe e per la risoluzione del metodo in fase di compilazione. Ho difficoltà ad ottenere di più dalla semplice rappresentazione di Objective-C o Javascript. Prendendo come esempio l'Objective-C, ho più esperienza nell'affrontare l'UML, non puoi facilmente esprimere categorie. La differenza tra un protocollo (come un'interfaccia Java) e una classe astratta deve essere espressa tramite sterotipi personalizzati. Fare uno strumento ObjC-UML di andata e ritorno significa incapsulare tutte queste differenze in uno schema di metadati in aggiunta alla lingua esistente. Come ho detto, tutto dipende dal linguaggio di programmazione che stai cercando di rappresentare: i programmatori C ++ non hanno nessuno di questi problemi.

Finalmente un mio piccolo bugbear che non è un limite, ma causa problemi cognitivi quando si usa l'UML per rappresentare ObjC: in ObjC + e - significano metodi di classe e istanza, mentre in UML essi significa pubblico e privato.

Limitazione 1: essere rapidamente fuori sincrono con l'origine

Limitazione 1bis: è necessario uno sforzo costante per mantenerlo sincronizzato

Limitazione 2: risponde "come" è, ma non "perché"

Limitazione 3: mancanza di espressività:

• è difficile sottolineare cosa è importante e cosa non lo è
Il testo puro
• ti consente una maggiore flessibilità quando spieghi le cose
• mostra solo un aspetto isolato alla volta (i diagrammi delle classi, i casi d'uso, il flusso, ecc.) ma di solito, quello che ti serve per una buona comprensione è un mix di quelli

Limitazione 4: difficilmente puoi esprimere concetti insoliti (riflessione, funzioni di prima classe, chiusure, puntatori di puntatori, annotazioni, dinamiche ...)

Solo un'osservazione: le persone non condividono i loro modelli UML liberamente come condividono il loro codice.

Anche se lo facessero, ci sarebbero problemi di compatibilità degli strumenti software usati (non esiste un formato di scambio, l'XMI è insufficiente)

Per quanto riguarda i tipi di diagramma. Nei libri di computer che mi piacciono, gli autori sembrano preferire solo un tipo di diagramma semplificato ("Head First Design Patterns" usa solo diagrammi di classe semplificati, "Portlet in action" usa quasi esclusivamente diagrammi di sequenza). Altri tipi di diagrammi sembrano essere usati molto meno frequentemente nella letteratura del computer. Per non parlare di altri costrutti UML come "linguaggio dei vincoli di oggetto".

Il problema che ho usato con UML è la sua complessità. Anche con lo standard di 800 pagine (che è chiaramente un segno di un grave problema), trovo interpretazioni di utilizzo estremamente diverse da uno sviluppatore all'altro. Tanto che può richiedere molto tempo per comprendere con precisione quale codice o processo risultante sta modellando. Spesso un diagramma molto più semplice con commenti è migliore di quello che altri hanno indicato.

Ci sono anche alcune cose fondamentali che non mi piacciono come l'associazione nel diagramma delle classi. Spesso non è chiaro cosa l'associazione rappresenti nel codice perché le persone li ometteranno dall'elenco degli attributi. Questo perché il link dovrebbe implicare questo. Tuttavia, inserisco sempre gli attributi specificati dall'associazione per evitare potenziali confusioni.

L'altro problema è che spesso le stesse persone con cui è possibile condividere UML, i clienti e i manager non capiranno o apprezzeranno comunque le sue caratteristiche più esoteriche. Lavorare in particolare nel settore dello sviluppo di applicazioni mobili è stato il vero caso.

Tuttavia, come altri hanno detto in forma semplice, trovo davvero utili i diagrammi di classe, specialmente gli strumenti CASE che possono generare la struttura di base da un diagramma di classe. Questo mi ha permesso di risparmiare molte ore e alcuni potenziali spacciatori.

Le mie due limitazioni sarebbero: -

1. Non è abbastanza astratto - I diagrammi delle classi sono fondamentalmente un elenco di campi e metodi in una classe e il suo probabilmente più sforzo per codificare il diagramma delle classi piuttosto che codificare la classe. Evidenzia le relazioni tra le classi - ma con non molto più dettagli rispetto alla lettura delle istruzioni "import" dal codice.

2. Loro mi trattano in modo molto dettagliato e non mi interessa ma manco cose interessanti come lo scopo di una relazione, o parti vitali della logica. Un altro poster ha sottolineato questo problema come "tutto è uguale" - non è possibile evidenziare le cose importanti.

3. (So di averne detto due!) Gli sviluppatori pensano a "Use Case" come diagrammi di figure stilizzate con alcune etichette allegate, mentre casi d'uso reali - > le descrizioni di testo in formato libero di ciò che il sistema dovrebbe fare sono lo strumento singolo più utile nella raccolta dei requisiti.