Cosa usano i programmatori funzionali al posto di UML?

Sono uno studente CS. Attualmente sto frequentando lezioni, in cui ci viene insegnato Analisi e progettazione degli obiettivi. Consiste principalmente nella scrittura di casi d'uso, nell'analisi del problema che possiamo affrontare durante la scrittura di alcune applicazioni per il client e nel modo in cui progettare il progetto in modo che sia estensibile, chiaro per gli sviluppatori e non generi problemi quando il cliente discute di alcuni Caratteristiche. Poiché è "obiettivo", lo stiamo imparando dal punto di vista OOP (classi e simili).

Ora stiamo usando UML come strumento di supporto. Credo di avere una buona conoscenza di OOP, ma ho anche imparato il paradigma funzionale e l'ho usato con successo in alcuni dei miei progetti più piccoli.

Il nostro insegnante, di fronte al "che dire del paradigma funzionale?" domanda, ha risposto che non stava programmando alcun progetto più ampio in linguaggi funzionali e non sa quale strumento potrebbero usare i programmi funzionali.

Quindi, cosa avrebbero usato? C'è qualche metodologia per questo? O forse non c'è bisogno di una cosa del genere?

Non posso parlare per tutti i programmatori funzionali, ma quelli che conosco tutti iniziano scrivendo le firme dei tipi delle funzioni di livello superiore, quindi poiché hanno bisogno di maggiori dettagli, scrivono le firme dei tipi delle funzioni di supporto e così via.

Questo funziona a causa della mancanza di effetti collaterali nella programmazione funzionale, quindi le funzioni sono tutte specificate solo in termini di input e output. Questo rende le loro firme di tipo molto più utili come strumento di progettazione che nella programmazione imperativa. Questo è uno dei motivi per cui li vedi utilizzati anche quando il compilatore potrebbe inferirli.

Per quanto riguarda gli strumenti per la creazione di diagrammi, con tutto il rispetto per il tuo professore, da quando ho lasciato la scuola non li uso in modo significativo in alcun paradigma.

Lo standard UML definisce oltre una dozzina di diversi tipi di diagramma, come mostrato in questo pratico diagramma:

Fonte: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

Vedi anche Figura A.5 La tassonomia della struttura e dei diagrammi comportamentali nelle specifiche UML 2.5.

^{Si noti che questo è un esempio di diagramma di classe, con relazioni di sottotipo is-a tra tipi di diagramma e tipi di diagramma astratti in corsivo. Mentre questi tipi di diagramma sono in realtà classi all'interno del metamodello UML, questo diagramma di classe è ancora utile per illustrare una gerarchia, senza alcuna connessione a OOP.}

Esistono un paio di tipi che si applicano chiaramente solo a OOP, ad esempio il diagramma di classe o il diagramma di oggetti . Ma il resto è più ampiamente applicabile rispetto ai sistemi orientati agli oggetti.

• Diagrammi della macchina a stati - FP non evita gli stati, ma li rende semplicemente espliciti. Un diagramma a macchina a stati può essere utile per spiegare il flusso di controllo o le varie transizioni di stato nel programma.

• Diagrammi di attività : sono utili in casi simili a quelli del Diagramma della macchina a stati, ma a un livello superiore. Possono essere utilizzati per spiegare il flusso di dati tra vari sottosistemi o per modellare processi aziendali esterni.

• Diagrammi di interazione : modella le interazioni tra più processi con stato. Chiaramente, questo non è utile per modellare gli interni di un programma funzionale puro. Tuttavia, UML non si occupa solo di modellare la struttura del codice, ma soprattutto di fornire un linguaggio di modellazione universale. Con un diagramma di interazione, potrei ad esempio usare diagrammi di interazione per modellare il comportamento esterno tra sistemi, ad esempio tra un browser e un web server, anche quando questi sono scritti usando tecniche FP.

• Schemi dei casi d'uso - I casi d'uso e i requisiti sono indipendenti dalla tecnologia utilizzata per soddisfarli. OOP o FP è assolutamente irrilevante qui.

• Diagrammi di distribuzione : questo tipo di diagramma viene utilizzato per descrivere la relazione tra software eseguibile e risorse hardware. Non importa se quel software sia stato scritto in un linguaggio FP.

• Diagrammi dei componenti - Oggigiorno la maggior parte dei linguaggi funzionali supporta esplicitamente la programmazione modulare. Un diagramma dei componenti descrive i componenti / moduli e le loro interfacce offerte e richieste. Questo mi ricorda molto i moduli Functor di OCaml.

• Diagrammi di profilo : descrivono le estensioni di UML stesso e non sono mai effettivamente utilizzate.

• Diagrammi della struttura composita: descrivono la struttura dei compositi. Può essere usato per descrivere strutture di dati o persino i punti di interazione di una funzione. Wikipedia mostra un diagramma per la funzione di Fibonacci come esempio:

  

  Fonte: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png

  In un certo senso, questa sarebbe la scelta dei programmatori funzionali piuttosto che un diagramma di classe, ma questo sembra orribilmente sovrastimato ...

• Diagrammi dei pacchetti : i pacchetti sono l'equivalente UML degli spazi dei nomi. Questo tipo di diagramma fa più parte dell'infrastruttura del linguaggio UML rispetto a un tipo di diagramma separato. Ad esempio, è possibile utilizzare i pacchetti per classificare un diagramma dei casi d'uso di grandi dimensioni.

Come abbiamo visto, vari tipi di diagrammi UML possono ancora essere utili quando si esegue la programmazione funzionale.

Raramente ho sentito il desiderio di usare UML durante la progettazione di un sistema e principalmente di usare UML per fare i compiti assegnati o per comunicare il contorno di un'architettura con uno schizzo veloce. Anche per un sistema OOP, UML non fornisce abbastanza valore per usarlo continuamente - il codice effettivo dice più di mille diagrammi. Potrei immaginare di utilizzare diagrammi simili a UML per spiegare le dipendenze tra varie funzioni e strutture di dati in un programma FP, ma devo ancora farlo: il mio stile personale preferisce una miscela di OOP e FP in cui le tecniche FP sono utilizzate su scala locale, ma non influenzano l'architettura generale.