Tài liệu BÀI 1: GIỚI THIỆU UML ppt

BÀI 1:
GIỚI THIỆU UML

UML là viết tắt của Unified Modeling Language (ngôn ngữ mô hình hóa thống nhất). Đó là
một trong các công cụ nổi bật nhất trong việc phát triển hệ thống ngày nay. Tại sao vậy?
UML cho phép người xây dựng hệ thống không chỉ tạo ra các bản thiết kế chứa đựng những
cái nhìn/nhận thức của họ theo một cách dễ hiểu và chuẩn xác mà còn có thể truyền đạt với
nhau về chúng.
Nội dung chính trong bài học:
+ Tại sao UML là cần thiết
+ UML hình thành như thế nào
+ Các loại sơ đồ (diagram) khác nhau của UML
+ Tại sao cần thiết phải sử dụng nhiều loại diagram khác nhau
Thuật ngữ: trong giáo trình này, hệ thống (system) được xem là sự kết hợp giữa phần mềm
(software) và phần cứng (hardware) nhằm cung cấp một giải pháp cho một vấn đề. Phát
triển hệ thống (system development) là việc tạo ra một hệ thống cho khách hàng, người có
vấn đề cần giải quyết. Một phân tích viên (analyst) tài liệu hóa vấn đề của khách hàng và
chuyển nó sang người phát triển (developer), lập trình viên (programmer) để xây dựng
phần mềm giải quyết vấn đề và triển khai phần mềm trên phần cứng máy tính.

UML hình thành như thế nào
UML là sản phẩm trí óc của Grady Booch, James Rumbaugh và Ivar Jacobson. Trong
những năm từ 80 đến 90, mỗi người trên làm việc tại những tổ chức khác nhau và phát minh
phương pháp phân tích thiết kế hướng đối tượng riêng của mình. Những phương pháp của
họ đạt được tính ưu việt hơn so với nhiều phương pháp khác. Đến giữa những năm 90, họ
bắt đầu mượn ý tưởng của nhau và dần tiến đến hợp tác cùng nhau.
Năm 1994, Rumbaugh gia nhập Rational Rose Corporation cùng với Booch và sau đó một
năm thì Jacobson cũng cùng gia nhập.
Phiên bản khởi đầu của UML bắt đầu được truyền bá khắp ngành công nghiệp phần mềm và
đem lại những thay đổi đáng kể. Nhiều công ty phần mềm cảm thấy rằng UML đáp ứng
được mục tiêu chiến lược của họ, do vậy một liên minh tạm thời được dựng lên. Các thành

viên của liên minh gồm EDC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas
Instruments, Rational và một số khác. Đến năm 1997, liên minh cho ra đời version 1.0 của
UML và đệ trình nó lên Tổ chức quản lý đối tượng (Object Management Group – OMG) để
trở thành ngôn ngữ mô hình hóa chuẩn.
Liên minh tiếp tục cho ra version 1.1 và đưa nó đến OMG cuối năm 1997. Vào 1998, có
thêm 2 version nữa của UML được tạo ra. UML trở thành một tiêu chuẩn trong công nghiệp
phần mềm và nó không ngừng phát triển.
Các thành phần của của UML
UML bao gồm một số thành phần đồ họa kết hợp với nhau hình thành nên các sơ đồ
(diagram). Do là một ngôn ngữ, UML có những qui tắc cho việc kết hợp các thành phần
này. Việc giới thiệu cho tiết về các thành phần cũng như các qui tắc sẽ thực hiện sau, chúng
ta cùng hiểu sơ qua về các diagram bởi chúng sẽ được dùng cho phân tích hệ thống.
Thuật ngữ: Mục tiêu của các diagram là trình bày những cái nhìn (view) khác nhau về một
hệ thống và tập hợp các view được gọi là mô hình (model). Một mô hình UML của một hệ
thống. Chú ý rằng UML mô tả những cái mà một hệ thống được giả định thực hiện. Nó
không cho biết cách thức thực hiện hệ thống.
Sơ đồ đối tượng (Object Diagram)
Thuật ngữ: Các vật được phân chia một cách tự nhiên thành các nhóm (automobile,
furniture, washing machines, …). Chúng ta gọi các nhóm này là lớp (class). Một class là
một nhóm các vật có cùng thuộc tính (attribute) và hành vi (behavior). Ví dụ, Bất cứ máy
giặt nào thuộc lớp “washing machines” đều có các thuộc tính như tên hiệu, model, số serial,
và sức chứa. Hành vi của chúng gồm “add clothes”, “add detergent”, “turn on” và “remove
clothes”.
Hình 1.1
Biểu tượng class của UML



Tại sao cần bận tâm về các class và các thuộc tính, hành vi của chúng? Để tương tác với thế
giới phức tạp của chúng ta, các phần mềm hiện nay cần mô phỏng một số khía cạnh của thế

giới thực. Class diagram trợ giúp về mặt phân tích. Chúng cho phép các phân tích viên nói
chuyện với khách hàng với những ngôn từ của họ và từ đó khuyến khích khách hàng trình
bày các chi tiết quan trọng của vấn đề họ gặp phải.
Sơ đồ đối tượng (Object diagram)
Thuật ngữ: Một đối tượng (object) là một thể hiện của một class - một vật cụ thể có các giá
trị cụ thể cho các thuộc tính và hành vi. Ví dụ, cái máy giặt của bạn có nhãn hiệu là
“Laundatorium”, tên đời là “Washmeister”, số serial là GL57774 và sức chứa là 16 kg. Đó
chính là một đối tượng.
Hình 1.2 cho thấy UML biểu diễn một object. Chú ý rằng biểu tượng là một hình chữ nhật
như biểu tượng class, nhưng tên gạch dưới. Tên của một thể hiện cụ thể nằm bên trái dấu :,
còn tên class nằm bên phải.
Hình 1.2
Biểu tượng object của UML


Sơ đồ tình huống ứng dụng (Use Case Diagram)
Thuật ngữ: Một tình huống ứng dụng (use case) là một mô tả về một hành vi của hệ thống
từ quan điểm người dùng. Đối với người phát triển hệ thống, đây là một công cụ có giá trị:
nó là một kỹ thuật thử-và-đúng (tried-and-true technique) cho việc thu thập yêu cầu hệ
thống từ quan điểm người dùng. Điều đó rất quan trọng nếu mục tiêu là xây dựng một hệ
thống mà con người thực có thể sử dụng.
Chúng ta sẽ tìm hiểu sâu hơn về use case sau này. Bây giờ, hãy xem ví dụ hình 1.3, chúng ta
dùng máy giặt rõ ràng để giặt áo quần.
Hình 1.3
Sơ đồ use case của UML


Thuật ngữ: Hình nhân (stick) nhỏ tượng trưng cho người dùng máy giặt được gọi là tác
nhân (actor). Hình ellipse biểu diễn use case. Chú ý rằng actor–thực thể kích hoạt use case–
có thể là con người hoặc một hệ thống khác.

Sơ đồ trạng thái (State Diagram)
Tại thời điểm nào thì một object cũng phải có một trạng thái xác định. Một người có thể là
sơ sinh, đứa bé còn ẵm ngửa, trẻ em, thiếu niên hoặc trưởng thành. Một thang máy có thể
đang đi lên, đi xuống hoặc đứng yên. Một máy giặt có thể đang ngâm (soak), giặt (wash),
giũ (rinse), vắt (spin) hoặc không hoạt động.
Sơ đồ trạng thái hình 1.4 cho thấy máy giặt dịch chuyển giữa các trạng thái. Biểu tượng tại
đầu diagram là trạng thái bắt đầu (start state) còn ở cuối là trạng thái kết thúc (end state).
Hình 1.4
Sơ đồ trạng thái của UML




Sơ đồ trình tự (Sequence Diagram)
Class diagram và object diagram biểu diễn thông tin tĩnh. Trong một hệ thống chức năng,
các object luôn tương tác lẫn nhau. Sơ đồ trình tự của UML (sequence diagram) biểu diễn
sự tương tác theo thời gian.
Tiếp tục với ví dụ máy giặt, các thành phần của máy gồm một ống cấp nước (cấp nước
sạch), một trống giặt (chứa áo quần) và một ống thoát. Chúng dĩ nhiên cũng là các object.
Điều gì xảy ra khi ta kích hoạt use case “wash clothes”? Giả sử ta đã hoàn tất các hoạt động
“add clothes”, “add detergent” và “turn on”, chuỗi các bước tiến hành sẽ như sau:
1. Nước vào trống thông qua ống cấp
2. Trống đứng yên trong 5 phút
3. Nước ngừng cấp
4. Trống quay ngược và xuôi trong 15 phút
5. Nước xà phòng thoát ra thông qua ống thoát
6. Nước sạch được cấp lại
7. Trống tiếp tục quay ngược và xuôi
8. Nước ngừng cấp

9. Nước vắt thoát ra thông qua ống thoát
10. Trống quay 1 chiều nhanh dần trong vòng 5 phút
11. Trống ngừng quay và việc giặt hoàn tất.
Hình 1.5 biểu diển sequence diagram ghi nhận các tương tác giữa cấp nước, trống giặt và
ống thoát (biểu diễn bằng các hình chữ nhật phía trên) diễn ra theo thời gian. Thời gian
trong diagram trôi theo chiều từ trên xuống.
Hình 1.5
Sơ đồ trình tự của UML







Trở lại ý tưởng về trạng thái, chúng ta có thể phân chia các bước 1 và 2 là trạng thái ngâm,
các bước 3 và 4 là trạng thái giặt, các bước 5-7 là trạng thái giũ và bước 8-10 là trạng thái
vắt.
Sơ đồ hoạt động (Activity Diagram)
Các hoạt động xuất hiện trong một use case hoặc trong một hành vi của object thường diễn
ra theo một trình tự như 11 bước ở ví dụ trên. Hình 1.6 cho thấy cách sơ đồ hoạt động UML
biểu diễn các bước 4-6 của trình tự.
Hình 1.6
Sơ đồ hoạt động của UML



Sơ đồ cộng tác (Collaboration Diagram)
Các thành phần của hệ thống làm việc với nhau để hoàn thành mục tiêu đặt ra và một ngôn
ngữ mô hình hóa cần có cách biểu diễn sự hợp tác này. Sơ đồ cộng tác UML được thiết kế

cho mục tiêu trên, như hình 1.7. Ví dụ này thêm bộ đếm thời gian (internal timer) trong tập
class tạo nên máy giặt. Sau một khoảng thời gian nhất định, timer dừng việc cấp nước và
trống giặt xoay ngược xuôi.
Hình 1.7
Sơ đồ cộng tác của UML


Sơ đồ thành phần (Component Diagram)
Sơ đồ này và tiếp theo thoát khỏi máy giặt bởi sơ đồ thành phần (component diagram) và sơ
đồ triển khai (deployment diagram) hướng biểu diễn sang các hệ thống máy tính.
Việc phát triển các phần mềm ngày nay tiến hành thông qua các thành phần phù hợp với
cách thức lập trình theo nhóm.
Hình 1.8
Sơ đồ thành phần của UML

Sơ đồ triển khai (Deployment Diagram)
Sơ đồ triển khai cho biết kiến trúc vật lý của một hệ thống dựa trên máy tính. Nó vẽ nên các
máy tính và thiết bị, cho thấy các kết nối giữa chúng và cho biết phần mềm trên mỗi máy.
Mỗi máy tính được biểu diễn bởi một khối lập phương với các đường nối giữa các máy tính.
Hình 1.9
Sơ đồ triển khai của UML





Một số tính năng khác
UML cung cấp một số tính năng khác cho phép tổ chức và mở rộng các diagram
Gói (package)
Thuật ngữ: Khi cần tổ chức các thành phần của một diagram vào trong một nhóm (group),

ta đưa chúng vào trong một package, biểu diễn như hình 1.10.
Hình 1.10
Gói UML cho phép
nhóm các thành phần
của một diagram

Ghi chú (Note)
Thuật ngữ: Ghi chú (note) của UML giúp tránh một thành phần nào đó trong diagram bị
hiểu nhầm.
Hình 1.11
Trong bất cứ diagram
nào, ta cũng có thể thêm
các ghi chú

Mẫu (Stereotype)
Thuật ngữ: Mẫu (stereotype) cho phép dùng các thành phần UML sẵn có để chế biến ra
những cái mới.

Thuật ngữ: Khái niệm giao diện (interface) là một ví dụ tốt cho stereotype. Một interface là
một class chỉ có operation mà không có attribute. Nó chính là một tập các hành vi mà ta
muốn dùng lại nhiều lần trên khắp mô hình. Thay vì nghĩ ra một thành phần mới để biểu
diễn một interface, ta có thể dùng một biểu tượng class với <<interface>> gắn phía trên tên
class.
Hình 1.12
Một stereotype cho phép
tạo một thành phần mới
từ những cái sẵn có.

Tại sao cần thiết phải sử dụng nhiều loại diagram khác nhau?
Thuật ngữ: Một hệ thống có nhiều người quan tâm với nhiều khía cạnh khác nhau, họ được

gọi là stakeholder.
Việc thiết kế hệ thống liên quan đến tất cả các khía cạnh (viewpoint) có thể có. Mỗi UML
diagram cho ta một cách tạo nên một cái nhìn cụ thể nhằm thỏa mãn mỗi loại stakeholder.

Tóm lược
Việc phát triển hệ thống là một hoạt động mang tính con người. Nếu thiếu một hệ thống ký
hiệu dễ hiểu thì quá trình phát triển dễ sinh lỗi.
UML là một hệ thống ký hiệu đã trở thành một chuẩn trong việc phát triển hệ thống. Nó là
phát minh của Grady Booch, James Rumbaugh và Ivar Jacobson. UML bao gồm một tập
các diagram để cung cấp một chuẩn cho phép các phân tích viên hệ thống xây dựng một bản
thiết kế đa diện dễ hiểu đối với khách hàng, lập trình viên hay bất cứ ai liên quan đến quá
trình phát triển hệ thống. Lý do cần thiết có nhiều loại diagram khác nhau vì mỗi loại dành
cho một stakeholder khác nhau trong hệ thống.

Câu hỏi:
1. Tại sao cần thiết phải có nhiều diagram khi mô hình hóa một hệ thống?
2. Những diagram nào cung cấp các nhìn tĩnh (static view) về hệ thống?
3. Những diagram nào cung cấp các nhìn động (dynamic view) về hệ thống (biểu diễn
sự thay đổi theo thời gian)?

Bài tập:
1. Giả sử bạn đang xây dựng một chương trình máy tính chơi cờ vui với người. Các sơ
đồ UML nào cần thiết trong quá trình thiết kế? Vì sao?
2. Đối với hệ thống ở bài tập trên, liệt kê các câu hỏi mà bạn sẽ đặt ra với những người
cần thiết và tại sao bạn lại hỏi họ.