Tiêu chuẩn UML định nghĩa hơn một chục loại sơ đồ khác nhau, như được biểu thị trong biểu đồ tiện dụng này:
Nguồn: https://en.wikipedia.org/wiki/File:UML_diagrams_overview.svg
Xem thêm Hình A.5 Phân loại cấu trúc và sơ đồ hành vi trong thông số UML 2.5.
Lưu ý rằng đây là một ví dụ về sơ đồ lớp, với các mối quan hệ phụ là giữa các loại sơ đồ và các loại sơ đồ trừu tượng in nghiêng. Mặc dù các loại sơ đồ này thực sự là các lớp trong siêu mô hình UML, sơ đồ lớp này vẫn hữu ích để minh họa một hệ thống phân cấp, không có bất kỳ kết nối nào với OOP.
Có một vài loại rõ ràng chỉ áp dụng cho OOP, ví dụ sơ đồ lớp hoặc sơ đồ đối tượng . Nhưng phần còn lại được áp dụng rộng rãi hơn là chỉ dành cho các hệ thống hướng đối tượng.
Sơ đồ máy trạng thái - FP không tránh các trạng thái, nó chỉ làm cho chúng rõ ràng. Sơ đồ máy trạng thái có thể hữu ích để giải thích luồng điều khiển hoặc các chuyển trạng thái khác nhau trong chương trình.
Sơ đồ hoạt động - rất hữu ích trong các trường hợp tương tự như đối với Sơ đồ máy trạng thái, nhưng ở cấp độ cao hơn. Chúng có thể được sử dụng để giải thích luồng dữ liệu giữa các hệ thống con khác nhau hoặc để mô hình hóa các quy trình kinh doanh bên ngoài.
Sơ đồ tương tác - mô hình hóa các tương tác giữa nhiều quy trình trạng thái. Rõ ràng, điều này không hữu ích để mô hình hóa các phần bên trong của một chương trình chức năng thuần túy. Tuy nhiên, UML không chỉ là về mô hình hóa cấu trúc mã, mà chủ yếu là cung cấp một ngôn ngữ mô hình hóa phổ quát. Với sơ đồ tương tác, tôi có thể sử dụng sơ đồ tương tác để mô hình hóa hành vi bên ngoài giữa các hệ thống, ví dụ giữa trình duyệt và máy chủ web - ngay cả khi chúng được viết bằng kỹ thuật FP.
Sơ đồ ca sử dụng - Các ca sử dụng và yêu cầu độc lập với công nghệ được sử dụng để đáp ứng chúng. OOP hoặc FP hoàn toàn không liên quan ở đây.
Sơ đồ triển khai - Loại sơ đồ này được sử dụng để mô tả mối quan hệ giữa phần mềm có thể chạy được và tài nguyên phần cứng. Cho dù phần mềm đó được viết bằng ngôn ngữ FP không thành vấn đề.
Sơ đồ thành phần - Hầu hết các ngôn ngữ chức năng có hỗ trợ rõ ràng cho lập trình mô-đun ngày nay. Sơ đồ thành phần mô tả các thành phần / mô-đun và giao diện được cung cấp và yêu cầu của chúng. Điều này nhắc nhở tôi rất nhiều mô-đun Functor của OCaml.
Sơ đồ cấu hình - mô tả các phần mở rộng cho chính UML và như vậy thực sự chưa bao giờ được sử dụng.
Sơ đồ cấu trúc hỗn hợp - mô tả cấu trúc của vật liệu tổng hợp. Nó có thể được sử dụng để mô tả các cấu trúc dữ liệu hoặc thậm chí các điểm tương tác của hàm. Wikipedia hiển thị sơ đồ cho hàm Fibonacci làm ví dụ:
Nguồn: https : //commons.wik mega.org/wiki/File:Compổng_Str struct_Diagram.png
Theo một nghĩa nào đó, đây sẽ là sự lựa chọn của các lập trình viên chức năng chứ không phải là một sơ đồ lớp, nhưng điều này có vẻ áp đảo khủng khiếp.
Sơ đồ gói - Các gói là UML tương đương với các không gian tên. Loại sơ đồ này là một phần của cơ sở hạ tầng ngôn ngữ UML hơn là một loại sơ đồ riêng biệt. Ví dụ: bạn có thể sử dụng các gói để phân loại Sơ đồ ca sử dụng lớn.
Vì vậy, như chúng ta đã thấy, các loại sơ đồ UML khác nhau vẫn có thể hữu ích khi thực hiện lập trình chức năng.
Tôi hiếm khi cảm thấy muốn sử dụng UML khi thiết kế một hệ thống và chủ yếu sử dụng UML để làm bài tập về nhà được giao hoặc để truyền đạt phác thảo của một kiến trúc bằng một bản phác thảo nhanh. Ngay cả đối với một hệ thống OOP, UML không cung cấp đủ giá trị để sử dụng nó mọi lúc - mã thực tế cho biết hơn một nghìn sơ đồ. Tôi có thể tưởng tượng sử dụng các sơ đồ giống như UML để giải thích sự phụ thuộc giữa các chức năng và cấu trúc dữ liệu khác nhau trong một chương trình FP, nhưng vẫn chưa làm được - phong cách cá nhân của tôi thích sự pha trộn của OOP và FP trong đó các kỹ thuật FP được sử dụng ở quy mô địa phương, nhưng không ảnh hưởng đến kiến trúc tổng thể.