Có phải là thông lệ để chuyển đổi các đặc tả yêu cầu thành logic vị ngữ cho lập trình chức năng?


8

Gần đây tôi đã được phân công làm việc trong một dự án nhỏ đang được triển khai tại Haskell. Đến từ nền tảng OO / bắt buộc, tôi đã quen với việc chuyển đổi các yêu cầu / câu chuyện của người dùng thành các trường hợp sử dụng và sơ đồ trình tự trước khi mã hóa.

Tuy nhiên, dự án Haskell mà tôi đã được chỉ định, nhóm thích chuyển đổi các yêu cầu của người dùng thành các mệnh đề / mệnh đề logic vị ngữ. Tôi đã nhận thức được logic được sử dụng trong các hệ thống quan trọng an toàn và các phương pháp chính thức cho công nghệ phần mềm, nhưng không quá nhiều trong lập trình hàng ngày. Đây có phải là thực tế phổ biến trong vương quốc FP? Tôi có thể tìm hiểu thêm về điều này ở đâu?

Nó có vẻ như là một cách tự nhiên để 'mô hình hóa' các yêu cầu và rút ra 'các hàm' từ các vị từ cùng với việc viết ra các đặc tả loại cần thiết cho các chức năng để hoạt động. Nhưng đó là cách nó được thực hiện / khuyến nghị trong thực tế hay nó là một cái gì đó đặc biệt đối với đội của tôi?

(Tôi đã thử tìm kiếm rộng rãi trước khi đặt câu hỏi này tại đây. Tìm kiếm "đặc tả yêu cầu trong lập trình chức năng" (và các từ đồng nghĩa và kết hợp từ khóa khác nhau) không dẫn đến bất cứ điều gì có ý nghĩa.)


Câu trả lời:


1

Tôi sẽ nói rằng nó không giới hạn trong lập trình chức năng, nó liên quan nhiều hơn đến mục tiêu của dự án. Bằng cách sử dụng logic vị ngữ (logic bậc cao hơn), bạn có thể tạo chứng minh cho logic được sử dụng trong yêu cầu. Dịch logic sang ngôn ngữ chức năng có lẽ dễ dàng hơn. Sau đó, cũng có thể dịch việc triển khai ngôn ngữ chức năng đã được chứng minh sang các ngôn ngữ thủ tục để có được một số cách thức đã được chứng minh để thực hiện nó.

Nếu chúng tôi có thể chứng minh chương trình thì chúng tôi không cần phải kiểm tra nó. Ngay cả khi một chương trình vượt qua 1000 bài kiểm tra, nó vẫn không được chứng minh. Rõ ràng, không dễ để tạo ra các bằng chứng nên chúng tôi chỉ tạo các bài kiểm tra thay thế.

Bạn cũng có thể muốn tìm kiếm prover prover, isabelle / hol.


-1

Đó là một cách để đối phó với lập trình chức năng. Nó có xu hướng rơi ra khỏi sơ đồ và sơ đồ luồng dữ liệu của "ngày xưa". Thay vì suy nghĩ về các đối tượng, lập trình chức năng có xu hướng tập trung vào những hành động cần được thực hiện. Dữ liệu trở nên ngẫu nhiên, các mẩu lông tơ mang theo để giữ lấy những gì bạn đang cố gắng thực hiện.


Điều này đọc giống như một bình luận, xem Cách trả lời
gnat

2
Lấy làm tiếc. Nhận xét của một người là câu trả lời của người khác. Đây không phải là cuộc trao đổi Stack Exchange đầu tiên của tôi.
Joe Sewell

Không chắc tôi đồng ý. Bản thân câu hỏi sẽ thu thập ý kiến ​​vì vậy có thể có vấn đề với câu hỏi nhưng câu trả lời tôi tin thực sự giải quyết câu hỏi được hỏi. Lưu đồ và luồng dữ liệu là một phần quan trọng của thông số kỹ thuật yêu cầu kinh doanh.
maple_shaft
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.