Was verwenden funktionale Programmierer anstelle von UML?

Ich bin CS Student. Ich besuche derzeit Vorlesungen, in denen wir Objektive Analyse und Design unterrichten. Es besteht hauptsächlich aus dem Schreiben von Anwendungsfällen, dem Analysieren des Problems, das beim Schreiben einer Anwendung für den Client auftreten kann, und dem Entwerfen des Projekts, so dass es erweiterbar ist, für Entwickler klar ist und keine Probleme aufwirft, wenn der Client über einige Probleme argumentiert Eigenschaften. Da es 'objektiv' ist, lernen wir es aus OOP-Sicht (Klassen und so weiter).

Jetzt verwenden wir UML als Hilfswerkzeug. Ich glaube, ich habe ein gutes Verständnis für OOP, aber ich habe auch das Funktionsparadigma gelernt und es erfolgreich in einigen meiner kleineren Projekte eingesetzt.

Unser Lehrer, wenn konfrontiert mit "Was ist mit Funktionsparadigma?" Frage, antwortete, dass er kein größeres Projekt in funktionalen Sprachen programmiert, und er weiß nicht, welches Tool funktionale Programme verwenden können.

Also, was würden sie verwenden? Gibt es eine Methodik dafür? Oder besteht keine Notwendigkeit für so etwas?

Ich kann nicht für alle funktionalen Programmierer sprechen, aber diejenigen, die ich kenne, beginnen damit, die Typensignaturen der Funktionen der obersten Ebene zu schreiben. Wenn sie mehr Details benötigen, schreiben sie die Typensignaturen der Hilfsfunktionen und so weiter.

Dies funktioniert aufgrund des Fehlens von Nebenwirkungen bei der funktionalen Programmierung, sodass alle Funktionen nur in Bezug auf ihre Ein- und Ausgänge angegeben werden. Dies macht ihre Typensignaturen als Entwurfswerkzeug viel nützlicher als bei der imperativen Programmierung. Das ist einer der Gründe, warum sie verwendet werden, auch wenn der Compiler darauf schließen kann.

Was die Diagrammwerkzeuge angeht, habe ich sie, bei allem Respekt vor Ihrem Professor, seit ich die Schule verlassen habe, in keinem Paradigma mehr in nennenswertem Umfang eingesetzt .

Der UML-Standard definiert über ein Dutzend verschiedene Diagrammtypen, wie in dieser praktischen Tabelle dargestellt:

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

Siehe auch Abbildung A.5 Die Taxonomie von Struktur- und Verhaltensdiagrammen in der UML 2.5-Spezifikation.

^{Beachten Sie, dass dies ein Beispiel für ein Klassendiagramm ist, bei dem es sich um Subtyp-Beziehungen zwischen Diagrammtypen und abstrakten Diagrammtypen in Kursivschrift handelt. Während diese Diagrammtypen tatsächlich Klassen innerhalb des UML-Metamodells sind, ist dieses Klassendiagramm dennoch nützlich, um eine Hierarchie ohne Verbindung zu OOP zu veranschaulichen.}

Es gibt einige Typen, die eindeutig nur für OOP gelten, z. B. das Klassendiagramm oder das Objektdiagramm . Der Rest ist jedoch umfassender anwendbar als nur für objektorientierte Systeme.

• Zustandsdiagramme - FP vermeidet Zustände nicht, sondern macht sie nur explizit. Ein Zustandsdiagramm kann nützlich sein, um den Steuerungsfluss oder die verschiedenen Zustandsübergänge im Programm zu erläutern.

• Aktivitätsdiagramme - sind in ähnlichen Fällen nützlich wie beim Zustandsmaschinendiagramm, jedoch auf einer höheren Ebene. Sie können verwendet werden, um den Datenfluss zwischen verschiedenen Subsystemen zu erklären oder um externe Geschäftsprozesse zu modellieren.

• Interaktionsdiagramme - Modellieren Sie die Interaktionen zwischen mehreren statusbehafteten Prozessen. Dies ist natürlich nicht nützlich für die Modellierung der Interna eines reinen Funktionsprogramms. Bei UML geht es jedoch nicht nur um die Modellierung der Codestruktur, sondern in erster Linie um die Bereitstellung einer universellen Modellierungssprache. Mit einem Interaktionsdiagramm könnte ich z. B. Interaktionsdiagramme verwenden, um das externe Verhalten zwischen Systemen, z. B. zwischen einem Browser und einem Webserver, zu modellieren - auch wenn diese mit FP-Techniken geschrieben wurden.

• Anwendungsfalldiagramme - Anwendungsfälle und Anforderungen sind unabhängig von der Technologie, mit der sie erfüllt werden. OOP oder FP ist hier absolut irrelevant.

• Bereitstellungsdiagramme - Mit diesem Diagrammtyp wird die Beziehung zwischen ausführbaren Software- und Hardwareressourcen beschrieben. Ob diese Software in einer FP-Sprache geschrieben wurde, spielt keine Rolle.

• Komponentendiagramme - Die meisten funktionalen Sprachen unterstützen heutzutage ausdrücklich die modulare Programmierung. Ein Komponentendiagramm beschreibt Komponenten / Module sowie die angebotenen und erforderlichen Schnittstellen. Das erinnert mich sehr an die Functor-Module von OCaml.

• Profildiagramme - beschreiben Erweiterungen von UML selbst und werden als solche eigentlich nie verwendet.

• Verbundstrukturdiagramme - Beschreiben Sie die Struktur von Verbundwerkstoffen. Es kann verwendet werden, um Datenstrukturen oder sogar die Interaktionspunkte einer Funktion zu beschreiben. Wikipedia zeigt ein Diagramm für die Fibonacci-Funktion als Beispiel:

  

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

  In gewissem Sinne wäre dies eher die Wahl des funktionalen Programmierers als eines Klassendiagramms, aber dies scheint schrecklich überentwickelt zu sein.

• Paketdiagramme - Pakete sind die UML-Entsprechung von Namespaces. Dieser Diagrammtyp ist mehr Teil der UML-Sprachinfrastruktur als ein separater Diagrammtyp. Beispielsweise könnten Sie Pakete verwenden, um ein großes Anwendungsfalldiagramm zu kategorisieren.

Wie wir gesehen haben, können verschiedene UML-Diagrammtypen bei der funktionalen Programmierung weiterhin nützlich sein.

Ich habe selten den Wunsch verspürt, UML beim Entwerfen eines Systems zu verwenden und UML hauptsächlich zu verwenden, um meine zugewiesenen Hausaufgaben zu erledigen oder den Umriss einer Architektur mit einer kurzen Skizze zu kommunizieren. Selbst für ein OOP-System bietet UML nicht genug Wert, um es ständig zu verwenden - der tatsächliche Code sagt mehr als tausend Diagramme aus. Ich könnte mir vorstellen, UML-ähnliche Diagramme zu verwenden, um die Abhängigkeiten zwischen verschiedenen Funktionen und Datenstrukturen in einem FP-Programm zu erläutern, muss dies aber noch tun. aber keinen Einfluss auf die Gesamtarchitektur.