Ich bin kein Profi, aber ich werde versuchen, einige dieser Fragen zu beantworten.
Würden Sie trotzdem die Use-Case-Analyse [?]
verwenden?
Ich verstehe nicht warum nicht. Sammeln Sie Anwendungsfälle und entwerfen Sie eine Modul-API, die Sie bereitstellen möchten und die die Anwendungsfälle erfüllt. Bestimmen Sie, ob die Anwendungsfälle eine Typklasse oder nur einfache Funktionen aufrufen.
oder vielleicht strukturierte Analyse und Design?
Ich bin mit diesem Ansatz nicht vertraut, aber nach dem, was ich aus dem Wiki-Artikel entnehme, sieht es so aus, als ob es gut funktionieren würde.
Wie definieren Software-Architekten das High-Level-Design des Systems, damit Entwickler es befolgen?
Ich würde annehmen, dass sie ein Modul und die Typen spezifizieren, die jeder Teil des Moduls haben sollte. Auch hier bin ich kein Profi, daher bin ich mir nicht wirklich sicher, was in der Praxis gemacht wird.
Was zeigen Sie Kunden oder neuen Entwicklern, wenn Sie ein Design der Lösung präsentieren sollen?
Sie zeigen den Kunden etwas, das für sie Sinn ergibt. Wenn Ihr Kunde schlau genug ist, zeigen Sie ihm einfach die Typ-Signaturen und erklären Sie die wichtigen Funktionen. Wenn sie weniger klug sind, dann zeichne hübsche Bilder oder was immer du tun musst. OOP vergleicht mit realen Objekten, während FP Vergleiche mit ... naja ... Funktionen macht. Der typische Weg, um Neulingen eine Funktion zu veranschaulichen, besteht darin, sie als eine Maschine darzustellen, in die man bestimmte Dinge hineinlegt, und dann kommen andere Dinge heraus.
Wie dokumentierst du ein Bild von der ganzen Sache, ohne erst alles schreiben zu müssen?
Ein "Bild"? Definieren Sie einfach die Typ-Signatur für die wichtigen Funktionen und belassen Sie die Implementierung dann als %code% . Es gibt irgendwo ein Paket, das Ihnen bessere Stubs gibt, die Sie zur Kompilierzeit daran erinnern, welche Teile Sie noch implementieren müssen.
Gibt es in der funktionalen Welt etwas, das mit UML vergleichbar ist?
Ähm ... nein?
Wie gehen Sie mit Analyse- und Designphasen um, wenn Sie planen, ein System mit einer funktionalen Programmiersprache wie Haskell zu entwickeln?
Mein Hintergrund ist in imperativ / objektorientierten Programmiersprachen, und deshalb bin ich es gewohnt, die Fallanalyse und die Verwendung von UML zu verwenden, um den Entwurf des Programms zu dokumentieren. Aber die Sache ist, dass UML inhärent mit der objektorientierten Art, Software zu machen, verwandt ist.
Und ich bin fasziniert darüber, was der beste Weg wäre, um Dokumentation zu entwickeln und Softwaredesigns für ein System zu definieren, das mit funktionaler Programmierung entwickelt wird.
Sehen wir uns diese Behauptung an:
UML ist inhärent mit der objektorientierten Vorgehensweise verbunden Software.
Erstens ist das nicht wirklich wahr. Sie können weiterhin Interaktionen, Anwendungsfälle, Zustände und Datenmodelle in UML modellieren, unabhängig von der Implementierung.
Zweitens sind die Typklassen von Haskell eine Form der Objektorientierung: Sie stellen eine polymorphe Verteilung für den Typ ihrer Argumente bereit (was verschiedene Funktionsimplementierungen erlaubt, die die Daten dieses Typs verwenden).
Also, ja, wenn Sie wirklich weiterhin UML verwenden wollen, gehen Sie vor.