Apa yang digunakan programmer fungsional sebagai ganti UML?

Saya pelajar CS. Saat ini saya menghadiri kuliah, di mana kami diajarkan Analisis dan Desain Objective. Ini sebagian besar terdiri dari penulisan use case, menganalisis masalah yang bisa kita hadapi ketika menulis beberapa aplikasi untuk klien, dan bagaimana merancang proyek sehingga itu bisa diperluas, jelas untuk pengembang, dan tidak memunculkan masalah ketika klien berdebat tentang beberapa fitur. Karena 'obyektif', kami mempelajarinya dari sudut pandang OOP (kelas dan semacamnya).

Sekarang kami menggunakan UML sebagai alat bantu. Saya percaya saya memiliki pemahaman yang baik tentang OOP, tetapi saya juga telah mempelajari paradigma fungsional dan menggunakannya dengan sukses di beberapa proyek kecil saya.

Guru kami, ketika dihadapkan dengan "bagaimana dengan paradigma fungsional?" pertanyaan, dijawab bahwa dia tidak memprogram proyek yang lebih besar dalam bahasa fungsional, dan dia tidak tahu alat apa yang mungkin digunakan program fungsional.

Jadi, apa yang akan mereka gunakan? Apakah ada beberapa metodologi untuk ini? Atau mungkin tidak perlu hal seperti itu?

Saya tidak dapat berbicara untuk semua programmer fungsional, tetapi mereka yang saya tahu semua memulai dengan menulis tanda tangan jenis fungsi tingkat atas, kemudian karena mereka membutuhkan lebih detail, mereka menulis tanda tangan jenis fungsi pembantu, dan sebagainya.

Ini berfungsi karena kurangnya efek samping dalam pemrograman fungsional, jadi semua fungsi ditentukan hanya dari input dan outputnya saja. Ini membuat tanda tangan tipenya jauh lebih berguna sebagai alat desain daripada dalam pemrograman imperatif. Itulah salah satu alasan Anda melihatnya digunakan bahkan ketika kompiler dapat menyimpulkannya.

Sejauh mengenai alat diagram, dengan segala hormat kepada profesor Anda, saya belum menggunakannya pada derajat yang signifikan dalam paradigma apa pun sejak saya meninggalkan sekolah.

Standar UML mendefinisikan lebih dari selusin jenis diagram yang berbeda, seperti yang ditunjukkan dalam bagan praktis ini:

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

Lihat juga Gambar A.5 Taksonomi diagram struktur dan perilaku dalam spesifikasi UML 2.5.

^{Perhatikan bahwa ini adalah contoh diagram kelas, dengan is-a hubungan subtyping antara tipe diagram, dan tipe diagram abstrak dalam huruf miring. Meskipun tipe diagram ini sebenarnya adalah kelas dalam metamodel UML, diagram kelas ini masih berguna untuk menggambarkan hierarki, tanpa ada koneksi ke OOP.}

Ada beberapa jenis yang jelas hanya berlaku untuk OOP, misalnya diagram kelas atau diagram objek . Tetapi sisanya lebih banyak diterapkan daripada hanya untuk sistem berorientasi objek.

• State Machine Diagram - FP tidak menghindari status, itu hanya membuatnya eksplisit. State Machine Diagram dapat berguna untuk menjelaskan aliran kontrol, atau berbagai transisi status dalam program.

• Activity Diagram - berguna dalam kasus serupa seperti untuk Diagram Mesin Negara, tetapi pada tingkat yang lebih tinggi. Mereka dapat digunakan untuk menjelaskan aliran data antara berbagai subsistem, atau untuk memodelkan proses bisnis eksternal.

• Diagram Interaksi - model interaksi antara berbagai proses stateful. Jelas, ini tidak berguna untuk memodelkan internal program fungsional murni. Namun, UML tidak hanya tentang pemodelan struktur kode, tetapi terutama tentang menyediakan bahasa pemodelan universal. Dengan diagram interaksi, saya dapat menggunakan diagram interaksi untuk memodelkan perilaku eksternal antara sistem, misalnya antara browser dan server web - bahkan ketika itu ditulis menggunakan teknik FP.

• Use Case Diagram - Use case dan persyaratannya tidak tergantung pada teknologi yang digunakan untuk memuaskan mereka. OOP atau FP sama sekali tidak relevan di sini.

• Deployment Diagram - Jenis diagram ini digunakan untuk menggambarkan hubungan antara perangkat lunak yang dapat dijalankan dan sumber daya perangkat keras. Apakah perangkat lunak itu ditulis dalam bahasa FP tidak masalah.

• Component Diagram - Sebagian besar bahasa fungsional memiliki dukungan eksplisit untuk pemrograman modular hari ini. Diagram Komponen menggambarkan komponen / modul, dan antarmuka yang ditawarkan dan diperlukan. Ini mengingatkan saya pada banyak modul Functor OCaml.

• Profile Diagram - mendeskripsikan ekstensi ke UML itu sendiri dan karena itu tidak pernah digunakan.

• Diagram Struktur Komposit - menggambarkan struktur komposit. Ini dapat digunakan untuk menggambarkan struktur data, atau bahkan titik interaksi suatu fungsi. Wikipedia menunjukkan diagram untuk fungsi Fibonacci sebagai contoh:

  

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

  Dalam arti tertentu, ini akan menjadi pilihan programmer fungsional daripada diagram kelas, tapi ini sepertinya rekayasa berlebihan….

• Package Diagram - Paket adalah ekuivalen UML dari namespaces. Jenis diagram ini lebih merupakan bagian dari infrastruktur bahasa UML daripada jenis diagram yang terpisah. Misalnya, Anda bisa menggunakan paket untuk mengategorikan Diagram Kasus yang besar.

Jadi seperti yang telah kita lihat, berbagai jenis diagram UML masih bisa berguna ketika melakukan pemrograman fungsional.

Saya jarang merasakan keinginan untuk menggunakan UML ketika mendesain sistem, dan terutama menggunakan UML untuk melakukan pekerjaan rumah yang ditugaskan kepada saya, atau untuk mengomunikasikan garis besar arsitektur dengan sketsa cepat. Bahkan untuk sistem OOP, UML tidak memberikan nilai yang cukup untuk menggunakannya sepanjang waktu - kode aktual mengatakan lebih dari seribu diagram. Saya bisa membayangkan menggunakan diagram mirip UML untuk menjelaskan ketergantungan antara berbagai fungsi dan struktur data dalam program FP, tetapi belum melakukannya - gaya pribadi saya lebih suka perpaduan OOP dan FP di mana teknik FP digunakan pada skala lokal, tetapi tidak mempengaruhi arsitektur keseluruhan.