Why UML ?

Chapter 2 Working with diagram

Trước khi khảo sát chi tiết UML, sẽ là khôn ngoan khi chúng ta tìm hiểu về nguyên nhân và các tình huống sử dụng UML. Đã có nhiều dự án phần mềm bị tổn hại vì sử dụng sai hoặc lạm dụng UML

Tại sao phải Mô Hình

Tại sao các kỹ sư làm mô hình? Tại sao các kỹ sư hàng không tạo mô hình máy bay? Tại sao kỹ sư cầu đường làm mô hình cây cầu? Mục đích của những mô hình này là gì?

Kỹ sư làm mô hình để xác định xem liệu thiết kế của họ có hoạt động chính xác không? Kỹ sư hàng không làm mô hình máy bay và đưa chúng vào các ống gió (wind tunnel) để xem chúng có bay được không. Kỹ sư cầu đường tạo mô hình cây cầu để xem chúng có đứng vững hay không. Kiến trúc sư xây dựng mô hình các tòa nhà để xem khách hàng có thích kiểu dáng như thế không. Mô hình được tạo để xác định xem một vật nào đó có hoạt động không.

Điều này ẩn chứa ý rằng mô hình có thể kiểm thử được. Thật là vô nghĩa khi tạo mô hình mà bạn không có cách nào để thực hiện các phép kiểm thử trên nó. Nếu bạn không định lượng được mô hình, thì mô hình đó không có giá trị.

Tại sao kỹ sư hàng không không chế tạo ra máy bay và lái thử nó? Tạo sao kỹ sư cầu đường không cho xây cây cầu rồi mới xem chúng có đứng vững không? Bởi vì máy bay và cây cầu đắt hơn rất nhiều so với mô hình. Chúng ta nghiên cứu các thiết kế bằng cách làm mô hình nếu như việc làm mô hình rẻ hơn nhiều lần so với việc chúng ta tạo ra vật thể thực.

Tại sao tạo mô hình phần mềm?

Liệu có thể kiểm thử các lược đồ UML? Liệu tạo các lược đồ UML có rẻ hơn và dễ kiểm thử hơn cái phần mềm mà nó biểu diễn? Trong cả hai tình huống, câu trả lời không bao giờ rõ ràng như lĩnh vực hàng không và cầu đường. Không có phương pháp chắc chắn nào để kiểm thử các lược đồ UML. Chúng ta có thể nhìn chúng, định lượng chúng, áp dụng các nguyên tắc thiết kế và các mẫu thiết kế lên chúng, nhưng kết quả của việc đánh giá chúng vẫn rất chủ quan. Vẽ lược đồ UML thì dễ hơn là viết phần mềm, nhưng với hệ số không lớn. Thật vậy, thay đổi mã nguồn dễ hơn rất rất nhiều lần so với việc thay đổi một lược đồ. Như vậy dùng UML liệu có hợp lý không?

Tôi đã không viết một quyển sách về UML nếu như dùng nó là không hợp lý. Tuy nhiên, những lập luận trên nhằm giải thích rằng UML rất dễ bị dùng sai mục đích. Chúng ta sử dụng UML khi chúng ta có một thứ gì đó mà chúng ta dứt khoát phải kiểm thử nó, và khi dùng UML để kiểm thử thì rẻ hơn là dùng mã nguồn để kiểm thử nó.

Ví dụ, nói rằng tôi có một ý tưởng cho một thiết kế nào đó. Tôi muốn kiểm tra rằng liệu những thành viên trong nhóm của tôi có cho rằng đấy là một ý tưởng đúng đắn. không. Vì vậy tôi vẽ lược đồ UML lên bảng và hỏi thành viên trong nhóm để nhận phản hồi.

Tại sao chúng ta tạo các thiết kế đầy đủ trước khi lập trình?

Kiến trúc sư, kỹ sư hàng không, kỹ sư cầu đường luôn vẽ các bản vẽ thiết kế (blueprint)? Tại sao? Bởi vì một người có thể vẽ bản thiết kế cho một ngôi nhà mà để xây nó cần đến năm người hoặc hơn. Khoảng một chục kỹ sư hàng không có thể vẽ bản thiết kế cho chiếc máy bay mà để chế tạo nó phải cần hơn cả ngàn người. Có thể vẽ bản thiết kế mà không cần phải đào móng, không cần phải trộn bê tông hay lắp cửa sổ.... Nói ngắn gọn, lập một kế hoạch xây dựng trước sẽ rẻ hơn nhiều so với việc xây dựng mà không có kế hoạch nào. Và nó sẽ không tốn nhiều chi phí khi bỏ đi những bản vẽ tồi, nhưng sẽ tốn rất nhiều nếu giựt sập một tòa nhà.

Một lần nữa, điều này lại không rõ ràng khi áp dụng cho phần mềm. Vẽ các lược đồ UML không thực sự rẻ hơn là viết mã nguồn. Thật vậy rất nhiều nhóm đã tiêu tốn nhiều thời gian trên lược đồ hơn là ngồi làm việc thực sự trên mã nguồn. Và việc ném bỏ các lược đồ không thực sự rẻ hơn là ném bỏ những đoạn mã. Vì vậy việc tạo một bộ đầy đủ các lược đồ UML trước khi viết code không thực sự là chọn lựa hiệu quả về chi phí.

Sử dụng UML một cách hiệu quả.