Các lập trình viên chức năng đang sử dụng thay thế UML là gì?


18

Tôi là sinh viên CS. Tôi hiện đang tham dự các bài giảng, nơi chúng tôi được dạy Phân tích và Thiết kế Mục tiêu. Nó bao gồm chủ yếu là các trường hợp sử dụng bằng văn bản, phân tích vấn đề mà chúng ta có thể gặp phải khi viết một số ứng dụng cho khách hàng và cách thiết kế dự án sao cho có thể mở rộng, rõ ràng cho các nhà phát triển và không sinh ra vấn đề khi khách hàng tranh luận về một số đặc trưng. Vì đó là 'mục tiêu', chúng tôi đang học nó từ quan điểm OOP (các lớp và như vậy).

Bây giờ chúng tôi đang sử dụng UML làm công cụ trợ giúp. Tôi tin rằng tôi đã hiểu rõ về OOP, nhưng tôi cũng đã học được mô hình chức năng và sử dụng nó thành công trong một số dự án nhỏ hơn của mình.

Giáo viên của chúng tôi, khi đối mặt với "mô hình chức năng thì sao?" câu hỏi, đã trả lời rằng anh ta không lập trình bất kỳ dự án lớn hơn nào bằng ngôn ngữ chức năng và anh ta không biết công cụ nào có thể sử dụng các chương trình chức năng.

Vậy, họ sẽ sử dụng cái gì? Có một số phương pháp cho việc này? Hoặc có lẽ không cần điều đó?


8
Do FP chú trọng nhiều hơn vào dữ liệu, nên một sơ đồ luồng dữ liệu có thể làm sáng tỏ một chương trình FP, cách mà sơ đồ hoặc sơ đồ trình tự làm sáng tỏ mã mệnh lệnh.
9000

9
Tôi đã là một nhà phát triển phần mềm trong nhiều năm. Chưa bao giờ trong đời tôi sử dụng UML theo cách riêng của mình, tôi cũng không gặp một người nào quen thuộc với toàn bộ ngôn ngữ. sơ đồ là mặc dù lớn ....
AK_

1
@ 9000: thực sự, sơ đồ luồng dữ liệu là IMHO một trong những loại sơ đồ hữu ích nhất để mô tả thiết kế phần mềm ở mức độ trừu tượng cao hơn - mabe hữu ích hơn so với sơ đồ lớp. Điều này cũng áp dụng cho FP và OOP. Thật không may, các nhà phát minh UML chọn thêm nhiều loại sơ đồ không cần thiết vào ngôn ngữ lập mô hình, nhưng từ chối thêm sơ đồ luồng dữ liệu (vâng, đây là một mánh khóe!).
Doc Brown

Đối với tôi và có thể nhiều người khác, câu trả lời là không có gì. Ngoài trường đại học, tôi chưa từng thấy ai sử dụng UML hay thậm chí đề cập đến nó.
Qwertie

Câu trả lời:


23

Tôi không thể nói cho tất cả các lập trình viên chức năng, nhưng những người tôi biết đều bắt đầu bằng cách viết chữ ký loại của các hàm cấp cao nhất, sau đó khi họ cần chi tiết hơn, họ viết chữ ký loại của các hàm trợ giúp, v.v.

Điều này hoạt động vì thiếu tác dụng phụ trong lập trình chức năng, vì vậy tất cả các chức năng đều được chỉ định theo các yếu tố đầu vào và đầu ra của chúng. Điều này làm cho chữ ký loại của họ hữu ích hơn nhiều như một công cụ thiết kế so với lập trình bắt buộc. Đó là một lý do bạn thấy chúng được sử dụng ngay cả khi trình biên dịch có thể suy ra chúng.

Theo như các công cụ lập biểu đồ, với tất cả sự tôn trọng dành cho giáo sư của bạn, tôi đã không sử dụng chúng ở bất kỳ mức độ đáng kể nào trong bất kỳ mô hình nào kể từ khi tôi rời trường.


19

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:

Các loại sơ đồ UML

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ụ:

    Sơ đồ cấu trúc tổng hợp cho một funciton Fibonacci

    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ể.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.