Czego używają programiści funkcjonalni zamiast UML?


18

Jestem studentką CS. Obecnie uczęszczam na wykłady, podczas których uczymy się analizy i projektowania celów. Polega głównie na pisaniu przypadków użycia, analizowaniu problemu, z którym możemy się spotkać podczas pisania aplikacji dla klienta, oraz na tym, jak zaprojektować projekt, aby był zarówno rozszerzalny, przejrzysty dla programistów, jak i nie pojawiał się problemów, gdy klient kłóci się o niektóre cechy. Ponieważ jest to „obiektywne”, uczymy się go z punktu widzenia OOP (klasy i tym podobne).

Teraz używamy UML jako narzędzia pomocniczego. Wierzę, że dobrze rozumiem OOP, ale nauczyłem się również paradygmatu funkcjonalnego i z powodzeniem stosowałem go w niektórych moich mniejszych projektach.

Nasz nauczyciel w konfrontacji z „a paradygmatem funkcjonalnym?” pytanie, odpowiedział, że nie programuje żadnego większego projektu w językach funkcjonalnych i nie wie, jakiego narzędzia mogą używać programy funkcjonalne.

Czego by użyli? Czy jest na to jakaś metodologia? A może nie ma takiej potrzeby?


8
Ponieważ FP kładzie większy nacisk na dane, schemat przepływu danych może prawdopodobnie objaśnić program FP, w sposób, w jaki schemat blokowy lub schemat sekwencji wyjaśniają kod imperatywny.
9000

9
Od wielu lat jestem programistą. Nigdy w życiu nie używałem UML z własnej woli, ani nie spotkałem ani jednej osoby, która zna cały język. diagramy są świetne ...
AK_

1
@ 9000: w rzeczywistości diagramy przepływu danych są IMHO jednym z najbardziej użytecznych rodzajów diagramów do opisywania projektowania oprogramowania na wyższym poziomie abstrakcji - mabe bardziej przydatne niż diagramy klas. Dotyczy to również FP i OOP. Niestety wynalazcy UML wybrali wiele niepotrzebnych typów diagramów do języka modelowania, ale odmówili dodania diagramów przepływu danych (tak, to rant!).
Doc Brown,

Dla mnie i prawdopodobnie wielu innych ludzi odpowiedź jest niczym. Poza uniwersytetem nigdy nie widziałem, aby ktokolwiek używał UML, ani nawet o nim wspominał.
Qwertie

Odpowiedzi:


23

Nie mogę mówić za wszystkich programistów funkcjonalnych, ale ci, których znam wszyscy, zaczynają od pisania podpisów typów funkcji najwyższego poziomu, a następnie, gdy potrzebują więcej szczegółów, piszą podpisy typów funkcji pomocniczych i tak dalej.

Działa to z powodu braku efektów ubocznych w programowaniu funkcjonalnym, więc wszystkie funkcje są określone w kategoriach tylko ich wejść i wyjść. To sprawia, że ​​ich podpisy są o wiele bardziej przydatne jako narzędzie do projektowania niż w programowaniu imperatywnym. To jeden z powodów, dla których są one używane, nawet jeśli kompilator może je wywnioskować.

Jeśli chodzi o narzędzia do tworzenia diagramów, z całym szacunkiem dla twojego profesora, nie użyłem ich w żadnym znaczącym stopniu w żadnym paradygmacie, odkąd opuściłem szkołę.


19

Standard UML definiuje kilkanaście różnych typów diagramów, jak pokazano na tej poręcznej tabeli:

Typy diagramów UML

Źródło: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg

Zobacz także rysunek A.5. Taksonomia diagramów struktury i zachowania w specyfikacji UML 2.5.

Zauważ, że jest to przykład diagramu klasowego z relacjami podtypów między typami diagramów i abstrakcyjnymi typami diagramów kursywą. Chociaż te typy diagramów w rzeczywistości są klasami w metamodelu UML, ten diagram klas nadal jest użyteczny do zilustrowania hierarchii, bez żadnego połączenia z OOP.

Istnieje kilka typów, które wyraźnie dotyczą tylko OOP, na przykład diagram klas lub diagram obiektowy . Ale reszta ma szersze zastosowanie niż tylko do systemów obiektowych.

  • Diagramy automatu stanów - FP nie unika stanów, jedynie je wyraźnie określa. Diagram automatu stanów może być przydatny do wyjaśnienia przepływu sterowania lub różnych przejść stanów w programie.

  • Diagramy aktywności - są przydatne w podobnych przypadkach, jak w przypadku schematu automatu stanów, ale na wyższym poziomie. Można je wykorzystać do wyjaśnienia przepływu danych między różnymi podsystemami lub do modelowania zewnętrznych procesów biznesowych.

  • Diagramy interakcji - modeluj interakcje między wieloma stanowymi procesami. Oczywiście nie jest to przydatne do modelowania elementów wewnętrznych czystego programu funkcjonalnego. Jednak w UML chodzi nie tylko o modelowanie struktury kodu, ale przede wszystkim o zapewnienie uniwersalnego języka modelowania. Dzięki diagramowi interakcji mógłbym np. Użyć diagramów interakcji do modelowania zachowania zewnętrznego między systemami, np. Między przeglądarką a serwerem WWW - nawet jeśli są one napisane przy użyciu technik FP.

  • Diagramy przypadków użycia - przypadki użycia i wymagania są niezależne od technologii zastosowanej do ich spełnienia. OOP lub FP jest tutaj absolutnie nieistotne.

  • Diagramy wdrażania - ten typ diagramu służy do opisania relacji między oprogramowaniem do uruchomienia a zasobami sprzętowymi. To, czy oprogramowanie zostało napisane w języku FP, nie ma znaczenia.

  • Diagramy komponentów - większość języków funkcjonalnych ma obecnie wyraźne wsparcie dla programowania modułowego. Diagram komponentów opisuje komponenty / moduły oraz ich oferowane i wymagane interfejsy. To mi przypomina wiele modułów Functor OCamla.

  • Diagramy profili - opisz rozszerzenia do samego języka UML i jako takie nigdy nie są używane.

  • Schematy struktur kompozytowych - opisz budowę kompozytów. Można go użyć do opisu struktur danych, a nawet punktów interakcji funkcji. Wikipedia pokazuje schemat funkcji Fibonacciego jako przykład:

    Schemat struktury kompozytowej dla funkcji Fibonacciego

    Źródło: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png

    W pewnym sensie byłby to wybór programistów funkcjonalnych, a nie schemat klasowy, ale wydaje się to okropnie przeprojektowane….

  • Diagramy pakietów - pakiety są odpowiednikiem przestrzeni nazw UML. Ten typ diagramu jest bardziej częścią infrastruktury języka UML niż oddzielny typ diagramu. Na przykład można użyć pakietów do kategoryzowania dużego diagramu przypadków użycia.

Jak widzieliśmy, różne typy diagramów UML mogą być nadal przydatne podczas programowania funkcjonalnego.


Rzadko odczuwałem chęć użycia UML przy projektowaniu systemu, a przede wszystkim używam UML do odrabiania zadań domowych lub do szybkiego przedstawienia szkicu architektury. Nawet w przypadku systemu OOP UML nie zapewnia wystarczającej wartości, aby go używać przez cały czas - rzeczywisty kod mówi więcej niż tysiąc diagramów. Mógłbym sobie wyobrazić używanie diagramów podobnych do UML w celu wyjaśnienia zależności między różnymi funkcjami i strukturami danych w programie FP, ale jeszcze tego nie zrobiłem - mój osobisty styl woli połączenie OOP i FP, w których techniki FP są stosowane w skali lokalnej, ale nie wpływają na ogólną architekturę.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.