Tôi muốn biểu diễn logic của chương trình thông qua sơ đồ, vì chương trình khá phức tạp; Tôi cần một cách để giải thích cho người khác, tại sao và làm thế nào một cái gì đó xảy ra trong chương trình của tôi. Sơ đồ có phải là tùy chọn duy nhất không?Đại diện trực quan của Logic chương trình
Nếu bạn cần giải thích mọi thứ ở cấp độ từng bước, vâng một sơ đồ thực sự là những gì bạn cần. Nếu bạn có thể nói ở mức cao hơn, một tùy chọn khác có thể là biểu đồ trạng thái.
Sơ đồ luồng là một lựa chọn phổ biến, và thường thích hợp cho những người phi kỹ thuật.
Nếu bạn quan tâm đến việc cung cấp chế độ xem kỹ thuật hơn về tình hình, UML có thể là lựa chọn tốt hơn.
A sequence diagram cho biết cách các thành phần tương tác với nhau.
Trong UML, các biểu đồ khác nhau dành cho những thứ khác nhau, sử dụng các phương pháp khác nhau. Xem xét chúng ta có khuynh hướng dựa vào các phương pháp hướng đối tượng, tôi sẽ giải thích các sơ đồ khác nhau và cách chúng hoạt động.
Trường hợp sử dụng Sơ đồ - Mục đích của trường hợp sử dụng mô hình là xác định và xác định tất cả các quy trình kinh doanh tiểu học mà hệ thống phải hỗ trợ. Điều này là từ cả người dùng và quan điểm hệ thống. Bất kỳ hành động nào trong hệ thống của bạn đều có thể được sử dụng trong trường hợp sử dụng, sau đó sẽ cho phép sử dụng thêm các mô hình giải thích thêm.
Sơ đồ hoạt động - Đây là loại biểu đồ quy trình làm việc được sử dụng để mô tả những gì diễn ra trong biểu đồ ca sử dụng. Về cơ bản nó là một phương pháp trực quan để mô tả dòng chảy của một hoạt động, hoặc nhiều hoạt động.
Sơ đồ tuần tự - Đây là biểu đồ hiển thị liên lạc giữa các đối tượng khác nhau trong hệ thống hoặc quá trình. Biểu đồ trình tự rất quan trọng trong phân tích, vì chúng trở nên rất quan trọng đối với thiết kế hệ thống chi tiết và thiết kế giao diện người dùng. Tôi thực sự thích những điều này khi họ đưa ra một cái nhìn tuyệt vời về những gì đang xảy ra trong hệ thống.
Sơ đồ trạng thái máy - Điều này cho phép bạn theo dõi chi tiết về cách hoạt động của đối tượng. Điều này cho phép khả năng lập bản đồ các sự kiện và các sự kiện tương tự trong hệ thống.
Sử dụng các biểu đồ được đề cập ở trên là cơ sở tuyệt vời để phân tích và thiết kế, và lưu ý rằng khi các sơ đồ này được tạo, chúng không nhất thiết phải hoàn thành. Trong các quy trình thiết kế, bạn sẽ thay đổi các sơ đồ này khi hệ thống phát triển. Tôi hy vọng cái này sẽ giúp bạn. Dưới đây là các liên kết đến wikipedia cho các biểu đồ khác nhau được đề cập.
Đằng sau mỗi chương trình là một miền vấn đề, trong đó có lẽ là một tập hợp các vấn đề mà cũng được hiểu bởi một nhóm các miền-am hiểu mọi người và miền giải pháp, trong đó các phương pháp giải quyết các vấn đề đó được thu thập và sử dụng để xử lý các vấn đề.
Để giải thích điều gì đó, trước tiên bạn phải đồng ý về miền sự cố. Nếu miền vấn đề của bạn là xử lý tín hiệu và lời giải thích sẽ dẫn đến một người không quen thuộc với miền, bạn đã có bánh mì nướng. Sau đó, bạn cần giải thích miền giải pháp (hoặc tham khảo một tập hợp các giải pháp nổi tiếng có thể tìm thấy trong sổ tay kỹ thuật), để bạn có thể biện minh cho một lựa chọn giải pháp cụ thể phù hợp cho vấn đề cụ thể này và các ràng buộc khác có thể được đặt vào câu trả lời (chạy trong máy nhỏ, có thể được xây dựng trong một ngày, v.v.). Nếu người mà bạn đang giải thích mọi thứ không hiểu một chuyển đổi Fourier nhanh như là một giải pháp có thể cho một vấn đề trong lĩnh vực xử lý tín hiệu mà bạn đã chọn, bạn sẽ không thể giải thích được giải pháp một cách tốt nhất lựa chọn.
Khi bạn vượt qua hai trở ngại này, thì có thể một sơ đồ có thể hữu ích. Các nạng khác như các loại sơ đồ UML khác nhau là tất cả về giải thích cấu trúc của giải pháp từ các quan điểm khác nhau. Quan điểm nào phụ thuộc vào mục đích của giải thích là gì.
Về lưu đồ: trong khi chúng phổ biến một lần, để mô tả thuật toán, mã psuedo nói chung là đủ tốt. Những người không thể theo dõi mã psuedo cũng không có khả năng theo một biểu đồ lớn. Và nếu flowchart của bạn là tầm thường, bạn không cần nó. Tôi đã không sử dụng một cách nghiêm túc trong 20 năm. Hầu hết các tài liệu khoa học máy tính dường như không sử dụng nó. Sau khi nói điều này, khi người ta muốn hiểu chi tiết cực kỳ thật là một đoạn mã thực sự đang làm gì, đặc biệt với mục đích phân tích chương trình tự động, lưu đồ (dưới tên "dòng điều khiển") vẫn khá hữu ích . Xem a COBOL control flow graph (và xem this for an explanation). Rõ ràng là bạn không muốn sử dụng điều này để giải thích một thuật toán cho người khác.
Ngoài ra còn có các sơ đồ ca sử dụng. Nhưng dựa trên câu hỏi, tôi đồng ý - sơ đồ sẽ là lựa chọn đầu tiên của tôi. – TrueWill