Có một tiêu chuẩn để ghi lại kiến ​​trúc cấp cao của chương trình không?

Tôi là một nhà phát triển nghiệp dư và tất cả các chương trình của tôi cho đến nay đều đủ đơn giản để được ghi lại trong mã. Trong khi đọc mã, rõ ràng tôi đã làm gì và hành động như vậy (bài kiểm tra tiêu chuẩn của tôi là xem mã 6 tháng sau và hiểu mọi thứ ở lần đọc đầu tiên - và tôi có khoảng thời gian bộ nhớ ngắn).

Bây giờ tôi phải đối mặt với một chương trình vượt xa khả năng của mình để ghi nhớ các tương tác khác nhau giữa

• bản thân mã
• các chỉ mục trong cơ sở dữ liệu
• sự tương tác giữa các mô-đun khác nhau (mã lõi "worker" và "library")

Tài liệu hiện tại của tôi là một bảng trắng nơi tôi có tất cả các loại hộp và mũi tên trỏ đến mã, chỉ mục cơ sở dữ liệu, hành động được thực thi, thay đổi trạng thái, v.v. Chỉ để tham khảo, một đoạn của mớ hỗn độn:

Câu hỏi của tôi là liệu có một tiêu chuẩn, hoặc được đặt tên là tập hợp thực hành tốt nhất (được đặt tên theo nghĩa là đây là một tập hợp được nhóm theo một tên cụ thể) cho tài liệu về các sản phẩm phức tạp hơn.

Các từ khóa tôi nên tìm là gì (những nỗ lực chung về "tiêu chuẩn kiến ​​trúc phần mềm tài liệu" và các biến thể tương tự thường dẫn đến phần mềm cho quy trình công việc hoặc xây dựng hệ thống CAD kiến ​​trúc).

Tôi cũng hy vọng rằng có thể không có thực tiễn tốt nhất chung cho các mô tả cấp cao và mọi người đều xây dựng triết lý riêng của mình.

Không có một tiêu chuẩn mà mọi người tuân thủ. Các dự án phần mềm có thể khác nhau rất nhiều (nghĩ: helloworld.py so với mã trong tàu con thoi).

Một phương pháp rất phổ biến là sử dụng mô hình 4 + 1 . Thay vì cố gắng nhồi nhét mọi thứ vào một kiểu tài liệu duy nhất, phương pháp này chia thiết kế thành năm thành phần:

• Các phát triển tầm nhìn
• Các logic xem
• Các Physical xem
• Các quá trình xem
• Kịch bản

Các quan điểm khác nhau mô tả sản phẩm từ bốn quan điểm khác nhau. Các kịch bản là nơi các trường hợp sử dụng sống và mô tả sự tương tác của các khung nhìn khác.

Lưu ý: Đây là mô hình khái niệm và không bị ràng buộc với bất kỳ công cụ cụ thể nào.

Bạn có thể đọc thêm ở đây:

1. Mô hình xem kiến ​​trúc 4 + 1 (wikipedia)
2. Kiến trúc Blueprints Kiến trúc mô hình Kiến trúc phần mềm 4 + 1 của Chế độ xem Kiến trúc (Giấy IEEE - pdf)

IMHO UML không phải là một công cụ hoạt động tốt để ghi lại kiến ​​trúc của phần mềm trong thế giới thực. Biểu đồ lớp rất hữu ích, nhưng sử dụng mức độ trừu tượng thường quá thấp cho mục đích này. Sơ đồ ca sử dụng thường quá "cao cấp" và bỏ lỡ các khía cạnh nhất định. Các loại sơ đồ UML khác có vấn đề tương tự (Công bằng, sơ đồ gói, sơ đồ triển khai, sơ đồ thành phần có thể ghi lại các khía cạnh kiến ​​trúc nhất định, nhưng cá nhân tôi chưa bao giờ thấy chúng rất hữu ích).

Nếu bạn đang tìm kiếm một cách làm việc, thực dụng để ghi lại các kiến ​​trúc cấp cao, tôi khuyên bạn nên làm quen với các sơ đồ luồng dữ liệu . Đây là những điều dễ hiểu và có lợi thế họ có thể mở rộng đến các mức độ trừu tượng khác nhau. Tôi đã tìm thấy chúng hữu ích nhất để ghi lại các loại hệ thống khác nhau. Thật tệ là họ không tìm thấy chúng vào UML, nhưng bạn vẫn tìm thấy rất nhiều công cụ - ngay cả những công cụ miễn phí như Dia hay DrawIO - để tạo các sơ đồ này.

Là một lưu ý phụ, tại sao bạn yêu cầu "chỉ mục trong cơ sở dữ liệu" trong một tài liệu cấp cao? Tôi nghĩ rằng chúng là một chi tiết triển khai của mô hình dữ liệu (quan hệ?) Của bạn và nếu bạn thêm chúng hay không - theo kinh nghiệm của tôi - thêm một câu hỏi về hiệu suất và tối ưu hóa.

Ngôn ngữ mô hình hóa thống nhất (UML) là ngôn ngữ mô hình hóa, phát triển, đa mục đích trong lĩnh vực công nghệ phần mềm, nhằm cung cấp một cách tiêu chuẩn để trực quan hóa thiết kế của một hệ thống.

Tôi nghĩ chúng ta đã từng làm tốt hơn. UML dường như ném em bé ra ngoài bằng nước tắm. Khi cung cấp một Ngôn ngữ mô hình thống nhất, nó đã xóa bỏ sự khác biệt giữa kiến ​​trúc và triển khai. Hoặc nếu nó không có ý định này dường như sẽ có hiệu lực.

Tôi đã thấy một số mô hình UML quái vật và thật lòng họ không làm gì cho tôi mà mã không thể làm được, và làm điều đó tốt hơn.