Những sơ đồ UML nào vẫn đang được sử dụng rộng rãi? [đóng cửa]

Tôi dạy kỹ thuật phần mềm ở bậc đại học và tôi có một câu hỏi cho các học viên UML.

Hầu hết các sách giáo khoa kỹ thuật phần mềm đều nỗ lực nghiêm túc trong việc trình bày các sơ đồ UML. Nhưng mặt khác, tôi đã nghe từ nhiều sinh viên tốt nghiệp rằng UML dường như không còn được sử dụng trong các chiến hào nữa.

Sơ đồ UML nào vẫn đang được sử dụng rộng rãi trong thực tiễn chuyên nghiệp và tại sao? Có sơ đồ không còn được sử dụng và tại sao?

Lưu ý: Để tránh các cuộc tranh luận và thảo luận dựa trên ý kiến, vui lòng minh họa câu trả lời của bạn bằng các yếu tố thực tế và khách quan (nếu có thể, có thể kiểm chứng) hoặc quan sát trung lập về kinh nghiệm cá nhân

Từ nhiều sơ đồ được đề xuất bởi UML, sơ đồ lớp và sơ đồ trình tự vẫn được sử dụng rộng rãi, chắc chắn theo sau là sơ đồ trạng thái:

• chúng có thể dễ dàng được sử dụng trên bảng trắng để xây dựng và thảo luận về thiết kế trước khi nhảy vào mã
• họ cho phép truyền tải rất nhanh một cái nhìn tổng quan mà một mình mã không dễ dàng đưa ra và không có sự thay thế khả thi nào cho nó.

Tôi nghĩ trường hợp sử dụng trong cuộc sống thực được sử dụng theo cách thường xuyên hơn. Trong các dự án lớn, với hàng trăm trường hợp sử dụng, sơ đồ rất khó vẽ và cung cấp ít lợi ích so với dạng bảng. BPMN cho thiết kế quy trình, lập bản đồ câu chuyện người dùng hoặc phân tách bảng sự kiện theo kiểu Cockburn được sử dụng nhiều hơn. Tại sao ? Bởi vì họ dễ dàng chia sẻ hơn với người dùng doanh nghiệp để giải quyết các yêu cầu một cách hiệu quả.

Tôi chắc chắn rằng đó là những nơi mà UML vẫn được sử dụng rất nhiều và có hệ thống. Tôi không tưởng tượng rằng phần mềm hàng không vũ trụ hoặc hệ thống điều khiển động cơ hạt nhân được sản xuất mà không có bộ tài liệu UML đầy đủ. Nhưng tôi tin rằng đó là ngoại lệ nhiều hơn so với quy tắc.

Tôi cảm thấy được xác nhận trong tuyên bố này khi tìm kiếm trong các hiệu sách. Một vài năm trước, bạn có thể tìm thấy rất nhiều sách về UML 2.0. Ngày nay, nếu bạn đang tìm kiếm UML 2.5, sự lựa chọn khá hạn chế. Tồi tệ hơn: nhiều tác giả thậm chí không nỗ lực sửa đổi các cuốn sách cũ của họ để cập nhật chúng (ví dụ: phần giới thiệu " UML chưng cất " đẹp của Fowler vẫn xuất hiện từ năm 2003 với UML 2.0 và tương tự cho các yếu tố "của Ambler theo kiểu UML 2.0 "!).

Tôi không nghĩ rằng xu hướng giảm này sẽ thay đổi, nhìn vào sự khái quát của nhanh nhẹn và việc quảng bá "Phần mềm làm việc trên tài liệu toàn diện".

Cuối cùng, tôi rất khẳng định rằng các phương pháp mô hình hóa dường như tuân theo sơ đồ darwinistic: chỉ có kỹ thuật lập sơ đồ phù hợp nhất mới tồn tại, những phương pháp mang lại lợi thế rõ ràng so với các phương pháp không chính thức (ví dụ minh họa khăn ăn) và mã chi tiết (ví dụ tại sao vẽ sơ đồ hoạt động A1, khi mã tương ứng có thể vừa trên một tờ A4?) ;-)

Mặt khác, tôi đã nghe từ nhiều sinh viên tốt nghiệp rằng UML dường như không còn được sử dụng trong các chiến hào nữa.

Chúng đều được sử dụng trong thực tế. Nhưng không phải ai cũng sử dụng chúng. Một số người tránh thiết kế hoàn toàn, và nhảy thẳng vào tiền mã hóa. Bạn không thể dựa vào bằng chứng giai thoại để biết "mọi người" làm gì.

Các công cụ như UML hoạt động tốt nhất nếu bạn sử dụng khi chúng thêm giá trị ; ví dụ

• cho các dự án lớn hơn
• cho các phần phức tạp của một dự án
• khi thiết kế dự án yêu cầu đầu vào từ nhiều người

Tạo chúng chỉ vì mục đích thực hiện chúng (hoặc vì quy trình nói rằng bạn phải) không hiệu quả. Thực hành tốt nhất là chọn lọc trên những gì bạn biểu đồ, và những loại mà bạn sử dụng. Sử dụng UML khi nào và ở đâu giúp ... và điều đó bao gồm việc chọn lọc các loại sơ đồ UML bạn sử dụng.

Ngoài ra ... UML được thiết kế chủ yếu như một công cụ thiết kế. Nó không hiệu quả (ngày nay) như một công cụ tài liệu. IDE điển hình giúp bạn hình dung nhiều khía cạnh nếu cấu trúc cơ sở mã đang hoạt động. Điều này thường tốt hơn so với việc dựa vào các sơ đồ UML có thể đã lỗi thời / không chính xác.

UML vẫn được sử dụng trong các chiến hào. Nhưng, như mọi khi, mọi người sử dụng một tập hợp con của nó. Những tập hợp con là đối tượng của các vấn đề trong tầm tay.

UML có nhiều phiên bản. Nhưng, như mọi khi, mọi người sử dụng biểu tượng của nó một cách không chính thức và bất tiện.

UML là cách chúng tôi hiểu nhiều về các mẫu sách ngoài kia. Đó cũng là một trong những cách chúng ta giao tiếp trên bảng trắng. Nó không biến mất. Nhưng nó sẽ không bao giờ được sử dụng chính thức như mã.

Thay vì tạo ra những sinh viên có thể sửa bất kỳ sơ đồ UML nào để tuân thủ UML phiên bản 2.5 hoặc bất cứ điều gì mới nhất, hãy tạo ra những sinh viên có thể hiểu sơ đồ đó đang cố gắng giao tiếp ngay cả khi nó không hoàn toàn phù hợp với phiên bản UML cụ thể vì đó là UML được sử dụng như thế nào trong các chiến hào. Nó xuất hiện trong các phương ngữ địa phương kỳ lạ, trộn lẫn với các hệ thống khác, và đôi khi chúng ta chỉ tạo nên các biểu tượng của riêng mình.

Dạy họ rằng bạn có thể hỏi những điều đó có nghĩa gì. Đừng dạy họ sửa những thứ khác đang phá vỡ một số quy tắc tưởng tượng. Chúng tôi chỉ đang cố gắng để giao tiếp ở đây.

Cách sử dụng tốt nhất mà tôi thấy uml đưa vào là để một lập trình viên mới chỉ cho chúng tôi kế hoạch của họ để giải quyết vấn đề. Nó nhanh chóng cho chúng ta thấy các phần của hệ thống mà họ đã bỏ qua hoặc không nhận ra đã tồn tại.

Tôi cũng đã làm việc ở những nơi cần UML ngay cả khi không cần thiết. Chúng tôi luôn luôn sử dụng cùng một mô hình vì vậy nó chỉ là một hình thức. Chúng tôi đã đến điểm mà chúng tôi chỉ hình ảnh mua sắm tên mới vào sơ đồ cũ. Đừng khuyến khích sử dụng loại này.

Nhưng tôi nghĩ tất cả chúng ta đều biết có sự khác biệt giữa đầu mũi tên bình thường và đầu mũi tên mở. Đúng?

Tôi sẽ cụ thể theo kinh nghiệm của mình: - Sơ đồ triển khai - Sơ đồ trình tự - Sơ đồ lớp Ba thứ được sử dụng nhiều nhất trong bất kỳ dự án nào, chúng cung cấp giá trị giao tiếp thực sự với nhóm ở các cấp độ khác nhau.