it-swarm.com.de

Was verwenden funktionale Programmierer anstelle von UML?

Ich bin CS-Student. Ich besuche derzeit Vorlesungen, in denen uns objektive Analyse und Design beigebracht werden. Es besteht hauptsächlich aus dem Schreiben von Anwendungsfällen, der Analyse des Problems, mit dem wir beim Schreiben einer Anwendung für den Client konfrontiert sind, und der Gestaltung des Projekts, sodass es erweiterbar und für Entwickler klar ist und keine Probleme hervorruft, wenn der Client über einige argumentiert Eigenschaften. Da es 'objektiv' ist, lernen wir es aus der Sicht von OOP (Klassen und so)).

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

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

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

20
MatthewRock

Ich kann nicht für alle funktionalen Programmierer sprechen, aber diejenigen, die ich kenne, beginnen mit dem Schreiben der Typensignaturen der Funktionen der obersten Ebene. 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 spezifiziert werden. Dies macht ihre Typensignaturen als Entwurfswerkzeug viel nützlicher als bei der imperativen Programmierung. Das ist ein Grund, warum Sie sehen, dass sie verwendet werden, auch wenn der Compiler darauf schließen kann.

Was Diagrammwerkzeuge angeht, habe ich diese bei allem Respekt vor Ihrem Professor in keinem wesentlichen Maße in any Paradigma verwendet, seit ich die Schule verlassen habe.

24
Karl Bielefeldt

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

UML diagram types

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 eine Subtypisierungsbeziehung zwischen Diagrammtypen und kursiven abstrakten Diagrammtypen handelt. Während diese Diagrammtypen tatsächlich Klassen innerhalb des UML-Metamodells sind, ist dieses Klassendiagramm immer noch 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 breiter anwendbar als nur für objektorientierte Systeme.

  • Zustandsmaschinendiagramme - FP vermeidet Zustände nicht, sondern macht sie lediglich explizit. Ein Zustandsmaschinendiagramm kann nützlich sein um den Kontrollfluss oder die verschiedenen Zustandsübergänge im Programm zu erklären.

  • Aktivitätsdiagramme - sind in ähnlichen Fällen nützlich wie für das 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 die Interaktionen zwischen mehreren zustandsbehafteten Prozessen. Dies ist natürlich nicht nützlich, um die Interna eines reinen Funktionsprogramms zu modellieren. Bei UML geht es jedoch nicht nur um die Modellierung der Codestruktur, sondern vor allem um die Bereitstellung einer universellen Modellierungssprache. Mit einem Interaktionsdiagramm könnte ich z. Verwenden Sie Interaktionsdiagramme, um das externe Verhalten zwischen Systemen zu modellieren, z. zwischen einem Browser und einem Webserver - 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 - Dieser Diagrammtyp wird verwendet, um die Beziehung zwischen ausführbarer Software und Hardwareressourcen zu beschreiben. Ob diese Software in einer Sprache FP) geschrieben wurde, spielt keine Rolle.

  • Komponentendiagramme - Die meisten Funktionssprachen unterstützen heutzutage ausdrücklich die modulare Programmierung. Ein Komponentendiagramm beschreibt Komponenten/Module sowie deren angebotene und erforderliche Schnittstellen. Dies erinnert mich sehr an die Functor-Module von OCaml.

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

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

    Composite Structure Diagram for a Fibonacci funciton

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

    In gewisser Hinsicht wäre dies eher die Wahl der funktionalen Programmierer als ein Klassendiagramm, aber dies scheint schrecklich überarbeitet zu sein.

  • Paketdiagramme - Pakete sind das UML-Äquivalent von Namespaces. Dieser Diagrammtyp ist mehr Teil der UML-Sprachinfrastruktur als ein separater Diagrammtyp. Sie können beispielsweise 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 hatte selten den Wunsch, 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 genügend 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 diesen zu erklären verschiedene Funktionen und Datenstrukturen in einem FP Programm, aber noch nicht - mein persönlicher Stil bevorzugt eine Mischung aus OOP und FP where FP Techniken werden auf lokaler Ebene verwendet, haben jedoch keinen Einfluss auf die Gesamtarchitektur.

19
amon