Cosa sono i programmatori funzionali che utilizzano al posto di UML?

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

Funziona a causa della mancanza di effetti collaterali nella programmazione funzionale, quindi le funzioni sono tutte specificate in termini di soli input e output. Ciò rende il loro tipo di firma molto più utile come strumento di progettazione che nella programmazione imperativa. Questo è uno dei motivi per cui li vedi usati anche quando il compilatore li può dedurre.

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

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

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

See also Figure A.5 The taxonomy of structure and behavior diagrams in the UML 2.5 spec.

^{Note that this is an example of a class diagram, with is-a subtyping relationships between diagram types, and abstract diagram types in italics. While these diagram types actually are classes within the UML metamodel, this class diagram is still useful to illustrate a hierarchy, without any connection to OOP.}

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

• Diagrammi macchina dello stato - FP non evita gli stati, ma li rende semplicemente espliciti. Un diagramma macchina dello stato 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 macchina di stato, ma a un livello superiore. Possono essere utilizzati per spiegare il flusso di dati tra vari sottosistemi o per modellare i processi aziendali esterni.

• Diagrammi di interazione - modellano le interazioni tra più processi stateful. Chiaramente, questo non è utile per la modellazione degli interni di un puro programma funzionale. 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 es. utilizzare diagrammi di interazione per modellare il comportamento esterno tra sistemi, ad es. tra un browser e un server web - anche quando sono scritti usando le tecniche FP.

• Usa i diagrammi dei casi - Usa casi e requisiti 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 il software eseguibile e le risorse hardware. Non importa se quel software è stato scritto in un linguaggio FP.

• Diagrammi dei componenti - La maggior parte dei linguaggi funzionali ha un supporto esplicito per la programmazione modulare in questi giorni. Un diagramma dei componenti descrive componenti / moduli e le loro interfacce offerte e richieste. Questo mi ricorda molti moduli di Funcam di OCaml.

• Diagrammi dei profili - descrivi le estensioni di UML e non sono mai stati utilizzati.

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

  

  Source: 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 iperspaziato ....

• Diagrammi del pacchetto - I pacchetti sono l'equivalente UML dei namespace. Questo tipo di diagramma fa più parte dell'infrastruttura del linguaggio UML rispetto a un tipo di diagramma separato. Ad esempio, potresti usare i pacchetti per classificare un ampio diagramma dei casi d'uso.

Quindi, 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 profilo di un'architettura con uno schizzo veloce. Anche per un sistema OOP, UML non fornisce un valore sufficiente per usarlo tutto il tempo - il codice effettivo dice più di mille diagrammi. Potrei immaginare di usare 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 dove le tecniche FP sono usate su scala locale, ma non influenzare l'architettura generale.