Tại sao không phù hợp khi sử dụng sơ đồ UML để lập kế hoạch cách mã của bạn sẽ được tổ chức?

Vì vậy, vâng, sơ đồ có thể không phù hợp đôi khi. Khi nào thì chúng không phù hợp? Khi bạn tạo chúng mà không có mã để xác thực chúng, và sau đó có ý định theo dõi chúng. Không có gì sai khi vẽ sơ đồ để khám phá một ý tưởng.

_{Phát triển phần mềm Agile: Nguyên tắc, mô hình và thực tiễn - Robert C. Martin}

Chính xác thì anh ta có ý gì? Không phải UML được thiết kế để giúp lên kế hoạch về cách cấu trúc mã của bạn trước khi "lặn vào"? Điểm quan trọng của việc sử dụng nó là gì nếu bạn không tuân theo các sơ đồ bạn đã đưa ra?

Bối cảnh: Trong chương này, chú Bob tạo ra một sơ đồ UML cho Trình giữ điểm của trò chơi Bowling. Sau đó, anh tiếp tục phát triển chương trình theo cách thử nghiệm, mà không tham khảo sơ đồ UML. Chương trình kết quả không giống như sơ đồ UML và chú Bob đi đến kết luận được trích dẫn ở trên.

Để giải thích chính xác điều này, chúng ta cần một bài học lịch sử ngắn. Trong những ngày đầu của công nghệ phần mềm, một sự tương tự thường được sử dụng là xây dựng một ngôi nhà. Một kiến ​​trúc sư và kỹ sư kết cấu thảo luận về kế hoạch với khách hàng và đưa ra một thiết kế. Nhà xây dựng sau đó theo thiết kế đó để xây dựng ngôi nhà thực tế. Viết mã được coi là tương đương với việc xây dựng ngôi nhà thực tế. Do đó, có một nhu cầu nhận thức về thiết kế phía trước trước khi việc xây dựng đó có thể diễn ra. Các công cụ thiết kế đồ họa khác nhau đã được tạo ra, với UML là một trong số đó.

Ý tưởng ban đầu với UML, là người ta sẽ thiết kế đầy đủ một hệ thống với UML, sau đó bàn giao cho các lập trình viên để dịch thiết kế đó thành mã. Trong thực tế, điều này chỉ không hoạt động, và dẫn đến nhiều năm lập trình viên được coi là "người thực hiện", thay vì "nhà thiết kế", các dự án bị trễ, các thiết kế phải liên tục thay đổi sau khi chúng được hoàn thành, v.v.

Lý do rất đơn giản. Mã hóa là thiết kế . Với sự tương tự ngôi nhà, mã là bản vẽ của kiến ​​trúc sư. Trình biên dịch là trình xây dựng lấy các thiết kế đó và xây dựng một chương trình từ chúng. Nhận thức này sau đó đã dẫn đến các kỹ thuật nhanh, TDD, vv được sinh ra: các công cụ giúp cải thiện chất lượng của thiết kế mã đó.

Giống như một kiến ​​trúc sư có thể tạo ra các bản phác thảo sơ bộ để giúp cô ấy và nhóm của mình hình dung ra thiết kế tổng thể, do đó, nhà phát triển có thể sử dụng UML hoặc các công cụ khác để giúp trực quan hóa thiết kế cần thiết. Giống như những bản phác thảo đó không được theo dõi một cách mù quáng, vì vậy UML không nên được theo dõi một cách mù quáng. Thiết kế mã sẽ phát triển ra khỏi các lần lặp nhanh và sử dụng TDD. LIkewise, giống như một kiến ​​trúc sư có thể xây dựng một mô hình của ngôi nhà để giúp cô ấy và nhóm của cô ấy trực quan hóa các bản vẽ, vì vậy UML có thể được sử dụng để giúp trực quan hóa cấu trúc mã.

Như chú Bob nói, bạn không thể xác nhận UML, bạn chỉ có thể xác thực mã. Do đó, mã là tài liệu thiết kế chính và UML, nếu được sử dụng, chỉ là thông tin thứ cấp.

Tôi đoán rằng không phải mọi thành ngữ lập trình (hoặc thiết kế hoặc mã) đều phù hợp với UML (mà tôi thừa nhận rằng tôi không biết rõ - chỉ đọc một vài cuốn sách về nó - tôi không bao giờ sử dụng nó và tôi có thể không thích nó).

Mã Plain C (ví dụ mã nguồn của nhân Linux) có thể không được mô hình chính xác bởi UML.

Mã Ocaml (với các mô-đun và hàm xử lý) hoặc thậm chí mã C ++ 11 (với lambdas và mẫu) có thể không phù hợp với UML.

Lập trình nhiều tầng là MetaOcaml có thể không phù hợp với UML.

Mã Prolog hoặc mã Lisp thông thường có thể không phù hợp với UML.

Xem thêm này câu trả lời & này câu hỏi của tôi.

Đọc Ngôn ngữ lập trình của Scott và các khái niệm, kỹ thuật và mô hình của sách về lập trình máy tính của Scott , sau đó tự hỏi liệu mọi mô hình lập trình ở đó có phù hợp với UML không.

Xem thêm Thiết kế đã chết của Martin Fowler ? Blog.