Tiêu chuẩn để mô hình hóa các ứng dụng hiện đại trước khi phát triển là gì?

Tôi đang sử dụng ứng dụng cấp doanh nghiệp đầu tiên của mình và tôi muốn nhóm của mình mô hình hóa toàn bộ ứng dụng ASP.NET MVC C # trước khi chúng tôi thậm chí khai thác một dòng mã.

CẬP NHẬT: Đây không phải là một cuộc thảo luận triết học về khi nào tài liệu / mô hình hóa một ứng dụng. Vui lòng chỉ cung cấp câu trả lời cho "cách" tài liệu / mô hình.

Sự thật là tôi đã luôn lướt qua bộ phận này và tôi chưa bao giờ thực sự mô hình hóa một ứng dụng trước đây. Cách tiêu chuẩn để làm điều này là gì? Loại sơ đồ nào nên được sử dụng và tài liệu sẽ như thế nào? Liên kết đến sơ đồ mẫu và tài liệu được đánh giá cao.

Khi tìm kiếm tôi có thể tìm thấy nhiều thứ trên mạng nhưng tôi muốn xem liệu có sự đồng thuận hiện đại nào về cách thực hiện việc này không.

Cảm ơn trước!

Tuyên bố đóng cửa

Tôi không biết đây là một chủ đề dính. Cảm ơn tất cả các bạn đã có thể gác lại những tranh cãi rõ ràng và cung cấp câu trả lời hữu ích. Đó là một cuộc thảo luận thú vị để nói rằng ít nhất :)

Một liên kết hữu ích khác mà tôi đã khám phá là: /programming/61487/do-you-use-uml-in-agile-development-practices/61519#61519

một sự đồng thuận hiện đại

Sự thật là: hiện tại, đó là điều mà sự phát triển phần mềm hiện đại đang thiếu - một sự đồng thuận về mô hình hóa. UML dường như là một loại ước số chung nhỏ nhất, nhưng trong thực tế chỉ có sự đồng thuận về ký hiệu, không phải về ngữ nghĩa. Có tồn tại hàng tá ý kiến ​​khác nhau về cách UML nên được diễn giải để tạo mã (có lẽ bạn có thể tìm thấy một cách giải thích phù hợp với nhóm của mình).

Mặt khác, có một cuộc chiến thần thánh đang diễn ra giữa những người "nhanh nhẹn" đó nói rằng "đừng tạo ra các mô hình chính thức, viết mã làm việc tốt hơn" và những người "BDUF" (thiết kế lớn lên phía trước), những người đang nghĩ về các công cụ như " MDA "(kiến trúc hướng mô hình) là giải pháp.

Những người khác (lại) đã phát hiện ra lập trình dựa trên dòng chảy cho thiết kế phần mềm hiện đại như là một thay thế cho UML. Đọc ở đây và ở đây để tìm hiểu thêm về điều đó.

Tôi muốn nhóm của mình mô hình hóa toàn bộ ứng dụng ASP.NET MVC C # trước khi chúng tôi thậm chí khai thác một dòng mã

Vấn đề mà tôi thường tìm thấy với cách tiếp cận như vậy là sự hiểu biết của tôi về giải pháp luôn không đầy đủ ngay từ đầu. Chỉ thông qua sàng lọc khi tiến hành công việc mà tôi đi đến một giải pháp cuối cùng.

Cố gắng thiết kế toàn bộ ứng dụng lên phía trước, trước bất kỳ mã nào (trong tất cả nhưng đơn giản nhất là các ứng dụng) thường là hoàn toàn.

Bạn có thực sự tin rằng bạn có thể trình bày chi tiết từng lớp và phương thức và cấu trúc dữ liệu không?

Tôi chỉ muốn biết một số giải pháp mô hình tốt.

Đối với các công cụ thực tế để tạo mô hình, tôi đã thử một vài và luôn kết thúc tại Microsoft Visio.

Trong tất cả các sản phẩm tôi đã dùng thử, có vẻ như là đơn giản nhất và thực sự ổn định (kinh nghiệm của tôi với các công cụ mô hình là chúng rất lỗi). Để công bằng, tôi làm rất ít mô hình, vì vậy hãy đưa ra khuyến nghị này với một hạt muối.

EDIT: Trên thực tế, tôi nên nói rằng hầu hết các mô hình của tôi được thực hiện trên một notepad nằm trên bàn của tôi. Bởi vì tôi ít làm người mẫu, tôi cố gắng giữ cho nó nhẹ và đi vào điểm chính. Phác thảo sơ đồ bằng bút và giấy hiệu quả hơn nhiều so với sử dụng phần mềm.

Bạn có thể thấy các sơ đồ viết tay hữu ích để hình thành ý tưởng của mình, trước khi đặt chúng ra trong một phần mềm lập sơ đồ.

Loại sơ đồ nào nên được sử dụng và tài liệu sẽ như thế nào?

Hầu hết những gì tôi mô hình những ngày này là sơ đồ tương tác. Một lần nữa, tôi không làm nhiều mô hình - chỉ là nơi tôi thực sự cảm thấy bài tập vẽ mô hình giúp củng cố sự hiểu biết của tôi.

Các sơ đồ UML là một nơi tốt để bắt đầu, có nhiều cách dễ dàng để làm điều này với phần mềm miễn phí hoặc trả phí. Một ví dụ đơn giản về một công cụ để tạo UML là một cái gì đó giống như bản vẽ tài liệu của google, các gói nâng cao hơn sẽ là Visio hoặc OmniGraffle.

EDIT: Như nhiều người đã đề cập, nếu bạn đi theo con đường UML, điều đó không có nghĩa là bạn phải mô hình hóa đầy đủ mọi thứ, nhưng bạn có thể đi đến thống nhất về những gì bạn đang lập mô hình và mức độ chi tiết của các mô hình là. Các sơ đồ UML đơn giản thường có thể giúp trình bày mã của bạn trước khi viết mã và làm rõ một số vấn đề tiềm ẩn trước khi chúng phát sinh.

Như @Brett đề xuất, sơ đồ UML là tốt nhất. Với UML, thật tốt khi có sơ đồ lớp và sơ đồ dòng công việc. Hai cái này sẽ đáp ứng hầu hết các nhu cầu thiết kế.

Với sơ đồ lớp, bạn có thể mô hình hóa các thành viên của mỗi thực thể, mức độ bảo mật của chúng, v.v.

Với sơ đồ luồng công việc, bạn có thể mô hình hóa phương thức nào gọi cuộc gọi nào, kết quả của luồng công việc là gì và ngoại lệ nào có thể bật ra.

Mặc dù tôi tin tưởng mạnh mẽ vào việc tạo ra một số bản vẽ kiến ​​trúc cơ bản trước khi viết mã, tôi nghĩ rằng việc tạo một bản vẽ chi tiết của toàn bộ ứng dụng là quá nhiều công việc.

Tôi thường tạo một vài hình ảnh phác thảo trong Visio, thường sử dụng các khối xây dựng "sơ đồ" để hình dung ý tôi muốn nói. Sử dụng UML thường cảm thấy chính thức hóa và mời quá nhiều chi tiết. Các bản vẽ Visio cho thấy các khối xây dựng cơ bản của ứng dụng và loại chức năng đi đâu. Nếu bạn đang sử dụng khung MVC, bạn hầu như chỉ thực hiện bằng cách lấy một mẫu vẽ ra khỏi web và sao chép nó.

Một ý tưởng tốt là thực hiện một vài bản vẽ từ các quan điểm khác. Thay vì vẽ mọi thứ, tôi thường thích dùng một chức năng cụ thể của hệ thống và sau đó hình dung nó như sau:

• Sơ đồ ca sử dụng (UML)
• Biểu đồ luồng hoặc Làn bơi UML (mức rất cao)
• Tổng quan về thành phần kiến ​​trúc.

Sau đó, chúng tôi bắt đầu mã hóa. Trong khi mã hóa, tôi đang sử dụng doxygen với tích hợp dấu chấm để có được sơ đồ lớp, kế thừa, v.v. Xem tổng quan về doxygen tạo ra thường là một cách rất tốt để xem cấu trúc mã.