1.

Tổng quan về UML

1.1. Sự ra đời của UML
Đầu thập kỷ 80, ngành CNPM chỉ có duy nhất một ngôn ngữ hướng đối
tượng là Simula. Sang nửa thập kỷ 80, các ngôn ngữ hướng đối tượng như
Smalltalk và C++ xuất hiện. Cùng với chúng, nhu cầu mô hình hóa các hệ thống
phần mềm theo hướng đối tượng đã nảy sinh. Và vào đầu thập kỷ 90, một số
ngôn ngữ mô hình hóa xuất hiện và được nhiều người sử dụng:

• Grady Booch’s Mooch Modeling Methodology

• James Rambaugh’s Object Modeling Technique – OMF

• Ivar Jacobson’s OOSE Methodology

• Hewlett-Packard’s Fusion

• Coad and Yordon’s OOA and OOD

Mỗi phương pháp và ngôn ngữ trên đều có hệ thống ký hiệu riêng,
phương pháp xử lý riêng và công cụ hỗ trợ riêng, khiến nảy ra cuộc tranh luận
phương pháp nào là tốt nhất. Trong thực tế, sự khác biệt giữa các phương pháp
đó hầu như không đáng kể và theo cùng tiến trình thời gian, tất cả những
phương pháp trên đã tiệm cận lại và bổ sung lẫn nhau.
Trong bối cảnh trên, người ta nhận thấy cần thiết phải cung cấp một
phuơng pháp mô hình hóa chuẩn và thống nhất cho việc mô hình hóa hướng đối
tượng. Yêu cầu cụ thể là đưa ra một tập hợp chuẩn hóa các ký hiệu (Notations)
và các biểu đồ (Diagrams) để nắm bắt các quyết định về mặt thiết kế một cách rõ
ràng, rành mạch. Đã có ba công trình tiên phong nhắm đến mục tiêu đó,c húng
được thực hiện dưới sự lãnh đạo của James Rumbaugh, Grady Booch và Ivar
Jacobson. Chính những cố gắng này đã dẫn đến kết quả là xây dựng được một
Ngôn Ngữ Mô Hình Hóa Thống Nhất UML (Unified Modeling Language).
1.2. UML là gì?
UML là một ngôn ngữ mô hình hóa thống nhất có phần chính bao gồm
những ký hiệu hình học, được các phương pháp hướng đối tượng sử dụng để
thể hiện và miêu tả các thiết kế của một hệ thống.
UML là ngôn ngữ để đặc tả, trực quan hóa, xây dựng và làm sưu liệu cho
nhiều khía cạnh khác nhau của một hệ thống.
 1.3. Vai trò của UML
UML có thể được sử dụng làm công cụ giao tiếp giữa người dùng, nhà
phân tích, nhà thiết kế và nhà phát triển phần mềm.
UML được xây dựng với chủ đích chính là:

• Mô hình hóa các hệ thống sử dụng các khái niệm hướng đối
tượng.

• Thiết lập một kết nối từ nhận thức của con người đến các sự kiện
cần mô hình hóa.

• Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp,
có nhiều ràng buộc khác nhau.

• Tạo một ngôn ngữ mô hình hóa có thể được sử dụng bởi người và
máy.
1.4. Những lĩnh vực có thể sử dụng UML
UML có thể được sử dụng trong nhiều giai đoạn, từ phân tích, thiết kế cho
đến thực hiện và bảo trì. Do đặc trưng của ngôn ngữ này là dùng các biểu đồ
hướng đối tượng để mô tả hệ thống nên miền ứng dụng của UML bao gồm
nhiều loại hệ thống khác nhau như:

• Hệ thống thông tin (Information Systems).

• Hệ thống kỹ thuật (Technical Systems).

• Hệ thống nhúng (Embeded Systems).

• Hệ thống phân bố (Distributed Systems).

• Hệ thống giao dịch (Business Systems).

• Phần mềm hệ thống (System Softwares).

2. Các giai đoạn và thành phần của UML

3. 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í.