Các sơ đồ UML thực sự hữu ích

UML có một rừng Sơ đồ.
Sơ đồ hồ sơ, Sơ đồ lớp, Sơ đồ gói ...

Tuy nhiên, (IMH và không quá kinh nghiệm-O) Tôi hoàn toàn thấy rằng việc thực hiện từng sơ đồ là quá mức cần thiết.

Do đó, Sơ đồ UML nào phù hợp hơn trong ngữ cảnh web, đặc biệt hơn là một blog (chúng tôi muốn xây dựng nó từ đầu).

_{Tôi hiểu rằng chỉ vì tôi đã sử dụng Biểu đồ UML không ngụ ý rằng mã của chúng tôi sẽ tuyệt vời và tuyệt vời ... nhưng, nó chắc chắn sẽ tốt hơn so với mã không được lập kế hoạch ...}

Như một hướng dẫn chung:

• Một sơ đồ triển khai cho tổng quan về kiến ​​trúc (tốt cho mọi hệ thống)
• Một sơ đồ ca sử dụng để biết tổng quan về những gì người dùng sẽ làm với hệ thống (dito)
• Sơ đồ một lớp cho mô hình dữ liệu
• Sơ đồ hoạt động cho luồng của các trường hợp sử dụng riêng lẻ nếu chúng phức tạp
• Có lẽ là sơ đồ máy trạng thái nếu bạn có quy trình tạo / đánh giá / xuất bản cho các mục blog

Một số loại sơ đồ (ví dụ biểu đồ thời gian) có cách sử dụng khá chuyên biệt, một số loại khác có xu hướng hướng tới mức độ chi tiết trong đó mã thực tế thực hiện công việc tốt hơn (ví dụ: sơ đồ trình tự) và các loại khác dường như được dành cho các dự án khổng lồ nhưng có tiện ích đáng ngờ ngay cả ở đó ( Sơ đồ gói nào? Bất kỳ IDE nào cũng có thể hiển thị cho bạn các gói của bạn).

Sơ đồ ít quan trọng hơn các cuộc hội thoại bạn có khi truyền đạt các khái niệm giữa các bên liên quan khác nhau trong một dự án. Sau nhiều năm phát triển phần mềm, tôi đã thấy mình cố gắng nắm bắt thông tin theo sơ đồ thậm chí ít hơn trong những năm gần đây so với trước đây khi tôi mới bắt đầu. Ngày nay, tôi có thể rút ra một vài trường hợp sử dụng đơn giản trên bảng trắng khi thảo luận về các khái niệm và tôi sẽ thường sử dụng một sơ đồ đơn giản nhưng cổ điển nếu tôi cố gắng hiểu được cách khách hàng muốn hệ thống hoạt động. Nếu tôi đặc biệt lo lắng, tôi sẽ sử dụng máy ảnh trên điện thoại của mình để ghi lại hình ảnh trên bảng trắng để giúp tôi nhớ những điều cụ thể.

Thiết kế phía trước nặng nề không phải là rất nạc. Nó không khuyến khích thay đổi và khắc phục suy nghĩ của bạn xung quanh một kế hoạch tấn công duy nhất có thể kết thúc hoàn toàn sai cho tổng thể dự án. Bạn muốn có thể trì hoãn thiết kế của mình nhiều nhất có thể đến phút cuối cùng để giảm khả năng một thay đổi lớn sẽ làm xáo trộn thiết kế và lịch trình của bạn sau này. Điều này không có nghĩa là không nên sử dụng UML mà nên sử dụng một cách tiết kiệm, như một phương tiện để cải thiện việc truyền đạt các khái niệm và không phải là phương tiện để xác định các hệ thống bạn định xây dựng.

UML được thiết kế như một ngôn ngữ giao tiếp giữa những người liên quan. (lập trình viên-lập trình viên, lập trình viên-doanh nhân, doanh nhân-người dùng) Mọi người thể hiện mô hình tinh thần của họ bằng một ngôn ngữ đơn giản, thống nhất mà mọi người đều hiểu.

Bạn cần tự hỏi mình cần bao nhiêu thông tin liên lạc đó.

• Đây có phải là một phần mềm nội bộ hoặc sản phẩm bạn muốn bán cùng với tài liệu không?
• Bạn sẽ duy trì phần mềm trong bao lâu? Bạn sẽ thuê một lập trình viên để duy trì nó?
• Bạn muốn nhanh nhẹn đến mức nào? Bạn có thể lãng phí thời gian bằng cách lập kế hoạch quá chi tiết.
• Làm thế nào những điều kỳ lạ mà bạn muốn làm? Bạn thường không cần phải ghi lại các mẫu phổ biến như trường hợp sử dụng chi tiết đăng ký hoặc kiến ​​trúc tổng thể của blog.

Một nguyên tắc nhỏ là làm các sơ đồ cấp cao để cung cấp cho bạn tổng quan và dành thời gian cho những thứ phức tạp hoặc không phổ biến. Viết / vẽ mô hình tinh thần của bạn trong UML buộc bạn phải hiểu đầy đủ về nó và giải quyết nhiều lỗi trước khi viết một dòng mã.

Bạn cần nhiều như yêu cầu để hiểu và giao tiếp hệ thống. Đối với phần mềm viết blog, tôi sẽ không nghĩ bạn cần nhiều. Mô hình nhiều như bạn cần để hiểu hệ thống. Dừng mô hình hóa khi nó dừng thêm bạn hiểu.

Nếu bạn chưa quen với UML, bạn có thể muốn thực hiện một vài sơ đồ chi tiết để tăng hiểu biết về sơ đồ. Một khi bạn hiểu một loại sơ đồ đủ tốt, bạn có thể làm điều đó trong tâm trí của bạn, nhu cầu về sơ đồ thực tế trở nên ít hơn.

Nếu bạn hẹn hò với các phiên bản sơ đồ của mình, nó sẽ giúp bạn đánh giá xem chúng có khả năng là hiện tại hay không. So sánh thiết kế hiện tại với các sơ đồ cũ hơn có thể hữu ích trong việc xác định khu vực nào của dự án thay đổi đáng kể so với thiết kế ban đầu.

Trừ khi bạn đang sử dụng các công cụ tạo mã từ sơ đồ hoặc nhúng đặc tả sơ đồ vào mã, có khả năng không đồng bộ với mã. Sơ đồ chi tiết sẽ có xu hướng trở nên không chính xác hơn theo thời gian. hơn sơ đồ tổng quan. Sơ đồ tổng quan cũng sẽ được yêu cầu bảo trì ít hơn để giữ cho chúng hiện tại.

Bạn có thể thấy hữu ích khi tạo sơ đồ:

• Phác thảo các tác nhân và cách họ sử dụng hệ thống.
• Phác thảo cấu trúc của các gói trong hệ thống. Lưu ý gói nào chứa các thành phần có thể tái sử dụng.
• Mô hình cấu trúc cơ sở dữ liệu.
• Sơ đồ trình tự là hữu ích để thiết kế các thành phần tiêu chuẩn. Nếu bạn có nhiều thành phần tương tự, hãy tạo mô hình một và sử dụng nó làm mẫu cho các thành phần khác. Xem xét tái sử dụng mã trong trường hợp như thế này.

Tạo sơ đồ hữu ích trong việc lập kế hoạch dự án. Nếu một sơ đồ không cần thiết để hiểu và / hoặc truyền đạt điều gì đó về dự án, đừng lãng phí thời gian vào nó. Vui lòng sử dụng sơ đồ không phải UML nếu nó giúp hiểu. UML có thể không phải là cách tốt nhất để mô hình hóa cơ sở dữ liệu.

Tôi muốn nói rằng bạn cần điều chỉnh sơ đồ UML theo cấp độ mô hình hóa của tất cả các bên liên quan và thời gian bạn phải hoàn thành dự án.

Nếu nhóm không biết UML và không có thời gian thì chỉ có sơ đồ lớp đến từ mã đảo ngược là có thể. Mỗi thành viên có thể thêm ý kiến ​​của mình trong sơ đồ lớp đã là một giải pháp tốt cho tài liệu. Trong trường hợp này, mô hình chỉ là một khung nhìn đồ họa của mã. Điều này sẽ đáp ứng gần 90% nhu cầu lập mô hình nếu được thực hiện cẩn thận và sẽ không thêm bất kỳ thời gian nào vào dự án.

Nếu bạn có kiến ​​thức về các bên liên quan nâng cao thì tất cả các sơ đồ có thể mang lại giá trị thực cho dự án để đáp ứng đầy đủ nhu cầu của dự án mô hình hóa. Điều này có thể thêm thời gian đáng kể để phân phối dự án nhưng chất lượng phân phối dự kiến ​​sẽ tốt hơn.

UML là tuyệt vời, rực rỡ và có thể thích nghi với bất kỳ dự án nào nếu sử dụng có chừng mực. Đừng uống rượu và lái xe chẳng hạn cùng một lúc :-)

Ngoài một vài sơ đồ hình ảnh lớn sẽ được sử dụng để truyền đạt kiến ​​trúc tổng thể của ứng dụng của bạn về máy chủ, lớp hoặc mô-đun lớn, tôi không nghĩ bạn có thể dự đoán sơ đồ nào bạn sẽ cần trước.

Chờ đến giây phút trách nhiệm cuối cùng. Bạn sẽ thấy khi bạn cần chúng . Thông thường, đó là một trong hai

• trong cuộc trò chuyện với khách hàng / chuyên gia / nhà phân tích tên miền, để làm rõ trường hợp sử dụng
• hoặc ngay trước khi bắt đầu viết mã, để đưa ra phiên bản đầu tiên của thiết kế của bạn.

Dù sao, các mô hình của bạn có thể sẽ trở nên lỗi thời ngay khi bạn viết một vài dòng mã hoặc nhận được phản hồi của khách hàng đầu tiên, vì vậy đừng bận tâm lên kế hoạch trước cho mọi thứ hoặc đánh bóng sơ đồ của bạn nhiều như vậy.