Bất kỳ phương pháp toán học nào để quản lý trạng thái của các đối tượng phức tạp?

Question

Tôi thường sử dụng các biểu mẫu web ASP.net cho GUI, có thể là một trong hầu hết các công nghệ "trạng thái". Nhưng nó áp dụng cho bất kỳ công nghệ nào có trạng thái. Đôi khi các biểu mẫu phức tạp và phức tạp, với> 30 phần tử và> 3 trạng thái của mỗi phần tử. Cách trực quan để thiết kế một biểu mẫu như vậy thường hoạt động với 90%. 10% khác thường tìm người thử nghiệm hoặc người dùng cuối :).

Vấn đề như tôi thấy rằng chúng ta nên tưởng tượng rất nhiều kịch bản trên cùng một đối tượng, đó là khó khăn hơn nhiều so với kết quả của các hoạt động độc lập.

Từ các khóa lập trình chức năng Tôi biết rằng cách tốt nhất là không sử dụng quản lý nhà nước và sử dụng các hàm thuần túy và biến đi qua giá trị và tất cả những thứ này, được chính thức hóa rất nhiều. Đôi khi, chúng ta không thể tránh nó.

Bạn có sử dụng bất kỳ hình thức toán học và cách tiếp cận nào để quản lý nhà nước đối tượng phức tạp không? Không giống như monads trong Haskell, nhưng có thể được sử dụng trong các ứng dụng và ngôn ngữ kinh doanh truyền thống hơn - Java, C#, C++.

Nó có thể không phải là hình thức hoàn thiện Turing, nhưng 99% cũng sẽ tuyệt vời :).

Xin lỗi nếu nó chỉ là một câu hỏi tumbleweed :)

Answer 1

Sử dụng tính năng truyền thông báo làm trừu tượng. Ưu điểm:

1. Khó khăn với trạng thái phức tạp là các tương tác phức tạp, đặc biệt là lông trong các hệ thống đồng thời như GUI điển hình. Gửi tin nhắn, bằng cách loại bỏ trạng thái chia sẻ, dừng sự phức tạp của trạng thái trong một tiến trình không bị lây nhiễm.
2. Đồng thời truyền thông báo có mô hình nền tảng tốt đẹp: ví dụ: mô hình diễn viên, CSP, cả hai đều ảnh hưởng đến Erlang.
3. Nó tích hợp tốt với lập trình chức năng: hãy kiểm tra lại Erlang. Peter van Roy's book *Concepts, Techniques, and Models of Computer Programming là một văn bản tuyệt vời cho thấy các thành phần cơ bản của ngôn ngữ lập trình, chẳng hạn như các hàm thuần túy, và truyền thông điệp, và cách chúng có thể được kết hợp. Các văn bản là avilable như một PDF miễn phí.

Answer 2

Nó có thể không Turing hoàn tất hình thức, nhưng 99% sẽ là tuyệt vời cũng :).

Xin lỗi, nhưng tôi thà cung cấp giải pháp NP-đầy đủ :)

câu trả lời nhanh từ tôi sẽ Test-Driven Approach. Nhưng đọc thêm để biết thêm.

Vấn đề như tôi nhìn thấy nó mà chúng ta nên tưởng tượng rất nhiều kịch bản trên cùng một đối tượng , đó là khó khăn hơn nhiều so với một hệ quả hoạt động độc lập.

Trong trường hợp này các phân hủy (không chỉ ở computer science nghĩa nào đó, nhưng trong mathematical quá) là rất hữu ích. Bạn phân tách kịch bản phức tạp trong nhiều số đơn giản hơn, do đó có thể vẫn phức tạp và có thể bị phân tách thêm.

Do quá trình như vậy, bạn nên kết thúc với một số chức năng đơn giản (nhiệm vụ) chủ yếu là độc lập với từng chức năng. Điều này rất quan trọng vì sau đó bạn có thể UNIT TEST những tình huống đơn giản đó. Ngoài ra, việc theo dõi test-first approach dễ dàng hơn và tốt hơn, cho phép xem sự phân hủy ngay từ đầu của quá trình phát triển.

Bạn có sử dụng bất kỳ hình thức toán học và cách tiếp cận nào để quản lý nhà nước đối tượng phức tạp không?

Để tiếp tục những gì tôi đã nói, với tôi điều quan trọng nhất là phân tích tốt để tôi có thể đảm bảo chất lượng và có thể dễ dàng tái tạo lỗi một cách tự động.

---

Để cung cấp cho bạn một ví dụ trừu tượng:

Bạn có một kịch bản phức tạpA. Bạn luôn cần phải viết ít nhất 3 bài kiểm tra cho mỗi trường hợp: đầu vào chính xác, trường hợp nhập liệu không đúng và góc.

Bắt đầu viết kiểm tra đầu tiên (đầu vào chính xác) Tôi nhận thấy rằng thử nghiệm trở nên quá phức tạp.

Kết quả là, tôi phân hủy kịch bảnA vào ít phức tạp A1, A2, A3. Sau đó, tôi bắt đầu viết các bài kiểm tra cho mỗi người một lần nữa (tôi nên kết thúc với ít nhất 3 * 3 = 9 bài kiểm tra).

Tôi nhận ra rằng A1vẫn còn quá phức tạp để kiểm tra, vì vậy tôi phân hủy nó một lần nữa vào A1-1, A1-2. Bây giờ tôi có 4 kịch bản khác nhau (A1-2, A1-2, A2, A3) và 3 * 4 = 12 thử nghiệm tiềm năng. Tôi tiếp tục viết các bài kiểm tra.

Sau khi hoàn tất. Tôi bắt đầu triển khai, vì vậy tất cả các bài kiểm tra của tôi đều vượt qua. Sau đó bạn có 12 chứng minh rằng kịch bản A (chính xác hơn các bộ phận của nó) hoạt động chính xác. Ngoài ra, bạn có thể viết 3 thử nghiệm khác cho kịch bản A kết hợp tất cả các phần bị phân hủy của nó - loại thử nghiệm này là thường là (nhưng không phải lúc nào!) Có thể được xem là Integration testing.

Sau đó, giả sử lỗi được tìm thấy trong trường hợp A. Bạn không chắc chắn phần nào thuộc về nó, nhưng bạn nghi ngờ rằng nó có liên quan đến A1-2 hoặc A3. Vì vậy, bạn viết 2 bài kiểm tra khác cho mỗi trường hợp để tạo lại lỗi (viết bài kiểm tra không đáp ứng được kỳ vọng của bạn). Sau khi bạn đã sao chép các lỗi bạn sửa chữa nó và làm cho tất cả các bài kiểm tra vượt qua.

Bây giờ bạn có thêm 2 chứng minh về hệ thống làm việc chính xác để đảm bảo tất cả chức năng trước đó hoạt động theo cùng một cách.

Có 2 vấn đề chính chính với cách tiếp cận này IMO.

1. Bạn cần viết nhiều bài kiểm tra và hỗ trợ chúng. Nhiều nhà phát triển chỉ cần không muốn làm điều đó.
2. Ngoài ra, quá trình phân hủy mang tính nghệ thuật hơn khoa học. Phân hủy tốt sẽ dẫn đến một cấu trúc tốt, kiểm tra và hỗ trợ trong khi một xấu sẽ dẫn đến rất nhiều đau đớn và lãng phí thời gian. Và nó là khó để biết nếu phân hủy là tốt hay xấu lúc đầu.

---

Quá trình này được gọi là Test-Driven-Phát triển.Tôi thấy nó là gần nhất "chính thức hóa" quá trình phát triển đóng vai trò tốt đẹp giữa khoa học và thế giới thực.

Vì vậy, tôi không thực sự nói về trạng thái ở đây mà là hành vi và chứng minh nó hoạt động chính xác.

Từ trải nghiệm cá nhân, tôi nên đề cập đến ASP.NET WebForm về mặt kỹ thuật RẤT khó kiểm tra. Để khắc phục điều đó, tôi sẽ đề xuất apply MVP pattern for ASP.NET WebForms.

Ngược lại với WebForms, ASP.NET MVC dễ dàng hơn rất nhiều để kiểm tra. Nhưng vẫn còn, bạn nên có bộ gọi là "dịch vụ" (kịch bản của chúng tôi) và (đơn vị) kiểm tra chúng một cách riêng biệt, sau đó kiểm tra tích hợp giao diện người dùng trong môi trường gần kiểm thử Tích hợp.