UML standardı, bu kullanışlı grafikte gösterildiği gibi bir düzineden fazla farklı diyagram türünü tanımlar:
Kaynak: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg
Ayrıca bakınız Şekil A.5 Yapı ve davranış diyagramlarının sınıflandırması UML 2.5 spesifikasyonundaki .
Bunun sınıf diyagramına bir örnek olduğuna dikkat edin; diyagram türleri ile italik olarak soyut diyagram türleri arasında bir alt tip ilişkisi vardır. Bu diyagram türleri aslında UML metamodelindeki sınıflar olsa da, bu sınıf diyagramı OOP ile herhangi bir bağlantı olmadan bir hiyerarşiyi göstermek için hala yararlıdır.
Sınıf diyagramı veya nesne diyagramı gibi sadece OOP için açıkça geçerli olan birkaç tür vardır . Ancak geri kalanı sadece nesne yönelimli sistemlerden daha yaygın olarak uygulanabilir.
Durum Makine Diyagramları - FP durumlardan kaçınmaz, sadece onları açık yapar. Bir Durum Makine Şeması, kontrol akışını veya programdaki çeşitli durum geçişlerini açıklamak için yararlı olabilir.
Faaliyet Diyagramları - Durum Makinesi Diyagramı ile benzer durumlarda, ancak daha yüksek bir seviyede yararlıdır. Çeşitli alt sistemler arasındaki veri akışını açıklamak veya harici iş süreçlerini modellemek için kullanılabilirler.
Etkileşim Diyagramları - çoklu durumsal süreçler arasındaki etkileşimleri modelleyin. Açıkçası, bu, saf bir işlevsel programın iç modellerini modellemek için yararlı değildir. Bununla birlikte, UML sadece kod yapısını modellemekle kalmayıp, öncelikle evrensel bir modelleme dili sağlamakla da ilgilidir. Bir etkileşim diyagramı ile, örneğin, bir tarayıcı ve bir web sunucusu arasındaki sistemler arasındaki dış davranışı modellemek için etkileşim diyagramlarını kullanabilirim - bunlar FP teknikleri kullanılarak yazılmış olsa bile.
Kullanım Senaryosu Diyagramları - Kullanım senaryoları ve gereklilikler, bunları karşılamak için kullanılan teknolojiden bağımsızdır. OOP veya FP burada kesinlikle alakasız.
Dağıtım Diyagramları - Bu diyagram tipi çalıştırılabilir yazılım ve donanım kaynakları arasındaki ilişkiyi tanımlamak için kullanılır. Bu yazılımın FP dilinde yazılmış olup olmaması önemli değildir.
Bileşen Diyagramları - Çoğu fonksiyonel dil, bugünlerde modüler programlama için açık bir desteğe sahiptir. Bileşen Diyagramı bileşenleri / modülleri ve bunların sunulan ve gerekli arayüzlerini açıklar. Bu bana birçok OCaml'ın Functor modülünü hatırlatıyor.
Profil Diyagramları - UML'nin kendisinin uzantılarını açıklar ve asla gerçekte kullanılmazlar.
Kompozit Yapı Diyagramları - kompozitlerin yapısını açıklar. Veri yapılarını ve hatta bir fonksiyonun etkileşim noktalarını tanımlamak için kullanılabilir. Wikipedia, Fibonacci işlevi için örnek olarak bir şema gösterir:
Kaynak: https://commons.wikimedia.org/wiki/File:Composite_Structure_Diagram.png
Bir anlamda, bu, bir sınıf diyagramından ziyade işlevsel programcıların tercihi olacaktır, ancak bu korkunç bir şekilde yeniden yapılandırılmış gibi görünüyor….
Paket Diyagramları - Paketler, ad alanlarının UML eşdeğeridir. Bu diyagram türü, UML dil altyapısının ayrı bir diyagram türünden daha bir parçasıdır. Örneğin, büyük bir Kullanım Senaryosu Şemasını kategorilere ayırmak için paketleri kullanabilirsiniz.
Gördüğümüz gibi, fonksiyonel programlama yaparken çeşitli UML diyagram tipleri hala yararlı olabilir.
Bir sistemi tasarlarken UML'yi kullanma arzusunu nadiren hissettim ve öncelikle ödevimi yapmak için UML'yi kullanmak veya bir mimarinin ana hatlarını hızlı bir taslakla iletmek istedim. Bir OOP sistemi için bile, UML her zaman kullanmak için yeterli değer sağlamaz - gerçek kod bin diyagramdan fazla diyor. Bir FP programında çeşitli işlevler ve veri yapıları arasındaki bağımlılıkları açıklamak için UML benzeri diyagramlar kullanmayı hayal edebiliyorum, ancak henüz yapmadım - kişisel tarzım FP tekniklerinin yerel ölçekte kullanıldığı OOP ve FP karışımını tercih ediyor, ancak genel mimariyi etkilemez.