smbsolutions
Thành viên hoạt động
- Tham gia
- 12/7/07
- Bài viết
- 167
- Được thích
- 294
Tuân and all đọc cái này nhé:
Bản gốc tiếng anh:
Copy & paste from VietRose
Xin chào mọi người,
Tôi nghĩ, mọi người, ai đã từng dùng UML để phân tích thiết kế, đều cũng ít nhiều thất vọng về khả năng của UML. Tôi cũng đã thất vọng nhiều. Ban đầu tôi cố gắng vẽ nhiều diagram cho project của mình, nhưng sau đó hầu như tôi vứt bỏ tất cả. Một phần là do không có thời gian để cập nhật chúng, một phần là do UML không có tác dụng lắm với việc lập trình. Thông thường, gần 99,99% mã nguồn hoàn toàn khác xa so với các lược đồ mà tôi vẽ cho các thành viên trong nhóm lập trình.
Tôi nghĩ ngay đến nguyên nhân:Tôi suy nghĩ khá nhiều và ngày càng thiên về lý do thứ 2. Tôi nghĩ, mọi người sẽ có cùng cách nghĩ như tôi. Vì vậy, tôi xin trích dịch một đoạn trong quyển UML for Java Programer của Rober C. Martin mà tôi rất tâm đắc khi đọc.
- Tôi chưa áp dụng triệt để process để vẽ UML tốt
- Tôi chưa hiểu về cách áp dụng UML
---------------------------------------------
Trích dịch một phần chương 2 từ quyển UML for Java Programmer của Rober C. Martin
* UML là chữ viết tắt của Unified Modeling Language, tức Ngôn ngữ Mô Hình hóa thống nhất.
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 giá đượ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ả.
Phần này cũng rất thú vị, tôi sẽ dịch tiếp khi có thời gian
Bản gốc tiếng anh:
Working with Diagrams
Before we explore the details of UML, it would be wise to talk about when and why we use it. Much harm has been done to software projects through the misuse and overuse of UML.
Why Model?
Why do engineers build models? Why do aerospace engineers build models of aircraft? Why do structural engineers build models of bridges? What purposes do these models serve?
These engineers build models to find out if their designs will work. Aerospace engineers build models of aircraft and then put them into wind tunnels to see if they will fly. Structural engineers build models of bridges to see if they will stand. Architects build models of buildings to see if their clients will like the way they look. Models are built to
find out if something will work.
This implies that models must be testable. It does no good to build a model if there are no criteria you can apply to that model in order to test it. If you can’t evaluate the model, the model has no value.
Why don’t aerospace engineers just build the plane and try to fly it? Why don’t structural engineers just build the bridge and then see if it stands? Because airplanes and bridges are a lot more expensive than the models. We investigate designs with models when the models are much cheaper than the real thing we are building.
Why build models of software?
Can a UML diagram be tested? Is it much cheaper to create and test than the software it represents? In both cases the answer is nowhere near as clear as it is for aerospace engineers and structural engineers. There are no firm criteria for testing a UML diagram. We can look at it, and evaluate it, and apply principles and patterns to it; but in the end the evaluation is still very subjective. UML diagrams are less expensive to draw than software is to write; but not by a huge factor. Indeed, there are times when it’s easier to change source code than it is to change a diagram. So then, does it make sense to use UML?
I wouldn’t be writing this book if UML didn’t make sense to use. However, the above illustrates just how easy UML is to misuse. We make use of UML when we have something definitive we need to test, and when using UML to test it is cheaper than using code to test
it.
For example, lets say I have an idea for a certain design. I need to test whether the other developers on my team think it is a good idea. So I write a UML diagram on the whiteboard and ask my teammates for their feedback.
Why should we build comprehensive designs before coding?
Architects, aerospace engineers, and structural engineers all draw blueprints. Why? Because one person can draw the blueprints for a home that will require five or more people to build. A few dozen aerospace engineers can draw blueprints for an airplane that will
require thousands of people to build. Blueprints can be drawn without digging foundations, pouring concrete, or hanging windows. In short, it is much cheaper to plan a building up front, than it is to try to build it without a plan. It doesn’t cost much to throw away a faulty blueprint, but it costs a lot to tear down a faulty building.
Once again things are not so clear cut in software. It is not at all clear that drawing UML diagrams is much cheaper than writing code. Indeed, many project teams have spent more on their diagrams than they have on the code itself. It is also not clear that throwing away a diagram is much cheaper than throwing away code. Therefore, it is not at all clear that creating a comprehensive UML design before writing code is a cost effective option.
Copy & paste from VietRose
