Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 2: Khái quát về UML

PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 
OBJECT ORIENTED ANALYSIS AND DESIGN 
DR. DAO NAM ANH 
Bài giảng 2: 
KHÁI QUÁT VỀ UML 
1 
RESOURCE - REFERENCE 
1. Ian Sommerville, Software Engineering, Ninth Edition, 2011 
2. Bernd Bruegge & Allen H. Dutoit. Object-Oriented 
Software Engineering: Using UML, Patterns, and Java, 
Third Edition, Prentice Hall, 2010 
3. Russell C. Bjork, ATM Simulation Links, Gordon College 
4. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David 
Fado, UML 2 Toolkit, John Wiley & Sons Inc, 2003 
5. Dương Kiều Hoa – Tôn Thất Hoà An, Phân tích và thiết kế 
Hệ thống thông tin với UML, 2006 
6. Đào Nam Anh, Giáo Trình Phân Tích Và Thiết Kế Hướng 
Đối Tượng, Đại học Điện lực, 2013 
2 
CONTENT – NỘI DUNG 
Phương pháp hướng đối tượng và quá trình phát 
triển hệ thống phần mềm 
1. Giới thiệu về hệ thống phần mềm 
2. Sự phát triển hệ thống 
3. Các cách tiếp cận trong phát triển phần mềm 
4. Quá trình phát triển phần mềm hợp nhất 
3 
Ký hiệu (notation) 
 Ký hiệu (notation) cho phép thể hiện ý 
tưởng phức tạp một cách ngắn gọn và 
chính xác. 
 Trong các dự án liên quan đến nhiều 
người tham gia, có kiến thức, kỹ thuật và 
văn hóa khác nhau, trao đổi thông tin có 
nguy cơ bị hiểu sai lệch, nên sự chính xác 
và rõ ràng là rất cần thiết. 
4 
Ký hiệu (notation) 
 Để một ký hiệu có thể dùng chính xác trong trao 
đổi thông tin, ký hiệu đó phải có một ngữ nghĩa 
xác định, phải là đại diện thích hợp cho một khía 
cạnh nhất định của hệ thống, và nó phải được hiểu 
rõ với tất các thành viên tham gia dự án. 
 Khi một ký hiệu trở thành chuẩn mực, được sử 
dụng bởi một số lượng lớn người tham gia, thì khả 
năng hiểu sai và mơ hồ là rất ít. 
 Ngược lại, khi có nhiều ký hiệu có cùng nghĩa, 
hoặc khi có một ký hiệu rất đặc biệt, người sử 
dụng dễ hiểu lầm vì mỗi người có cách giải thích 
riêng của mình. 
5 
Unified Modeling Language 
 UML (ngôn ngữ mô hình hóa thống nhất, 
Unified Modeling Language) cung cấp 
một dải các ký hiệu đại diện cho các khía 
cạnh khác nhau của một hệ thống và đã 
được chấp nhận là một ký hiệu tiêu chuẩn 
trong công nghiệp. 
6 
Lịch sử hình thành UML 
Kết quả của sự thống nhất của 
 OMT (Object Modeling Technique), Rumbaugh 
và cộng sự năm 1991, 
 Booch năm 1994, và 
 OOSE (Object-Oriented Software Engineering) 
Jacobson và cộng sự năm 1992. 
 UML cũng đã bị ảnh hưởng bởi các ký hiệu theo 
định hướng đối tượng khác, chẳng hạn như Mellor 
và Shlaer năm 1998, Coad và Yourdon năm 1995, 
 Wirfs Brock năm 1990, Martin và Odell năm 
1992. 
7 
Lịch sử hình thành UML 
8 
Unifield Modeling Language - UML 
 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 hệ thống. 
 Đó là một ngôn ngữ để đặc tả, trực quan hoá, 
xây dựng và làm tư liệu cho nhiều khía cạnh 
khác nhau của một hệ thống. 
 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, thiết kế 
viên và lập trình viên. 
9 
Unifield Modeling Language - UML 
 UML cung cấp hệ thống ký hiệu chuẩn có 
thể được sử dụng bởi tất cả các phương pháp 
hướng đối tượng và để lựa chọn và tích hợp 
các yếu tố tốt nhất của từ các ký hiệu trước 
đó. 
 Ví dụ, UML có các biểu đồ Use Case của 
OOSE và sử dụng nhiều tính năng của các 
biểu đồ lớp của OMT. 
 UML cũng bao gồm các khái niệm mới 
không được trình bày trong các phương pháp 
khác tại thời điểm đó, chẳng hạn như cơ chế 
mở rộng và một ngôn ngữ các hạn chế. 
10 
UML - ngôn ngữ mô hình 
 UML sử dụng các mô hình để xác định các yêu cầu của người dùng đối với 
hệ thống và qua đó giúp chúng ta đánh giá tính khả thi của dự án. 
 Tầm quan trọng của mô hình đã được lĩnh hội một cách thấu đáo trong hầu 
như tất cả các ngành khoa học kỹ thuật từ nhiều thế kỷ. 
 Khi muốn xây dựng một vật thể nào đó, đầu tiên cần tạo ra các bản vẽ để 
quyết định cả hình thức và phương thức hoạt động của nó. 
 Mô hình nhìn chung là một cách mô tả vật thể. Vật thể đó có thể tồn tại 
trong một số giai đoạn nhất định, như giai đoạn thiết kế hay giai đoạn xây 
dựng hoặc chỉ là có trong kế hoạch. 
 Thiết kế viên cần phải tạo ra các mô hình mô tả tất cả các khía cạnh khác 
nhau của sản phẩm. 
 Ngoài ra, một mô hình có thể có nhiều hướng nhìn, mỗi hướng nhìn sẽ mô 
tả một khía cạnh riêng biệt của sản phẩm hay hệ thống cần được xây dựng. 
 Một mô hình cũng có thể được xây dựng trong nhiều giai đoạn và ở mỗi 
giai đoạn, mô hình sẽ được bổ sung thêm một số chi tiết nhất định. 
11 
UML - ngôn ngữ mô hình 
Mô hình đảm bảo các yếu tố: 
 Chính xác (accurate): Mô tả chính xác hệ 
thống cần xây dựng, 
 Đồng nhất (consistent): Các mô hình, hướng 
nhìn khác nhau không được mâu thuẩn với 
nhau, 
 Có thể hiểu được (understandable): Dễ hiểu 
cho những người tham gia phát triển, 
 Dễ thay đổi (changeable), 
 Dễ dàng kết nối với các mô hình khác. 
12 
UML - ngôn ngữ mô hình 
Mô hình hóa một hệ thống nhằm mục đích: 
 Hình dung một hệ thống theo thực tế hay 
theo mong muốn, 
 Chỉ rõ cấu trúc hoặc cách ứng xử của hệ 
thống, 
 Tạo một khuôn mẫu hướng dẫn nhà phát 
triển trong suốt quá trình xây dựng hệ thống, 
 Ghi lại các quyết định của nhà phát triển để 
sử dụng về sau. 
UML chính là một ngôn ngữ mô hình. 
13 
Lĩnh vực ứng dụng UML 
 Hệ thống thống tin (Information system): Cất giữ, lấy, 
biến đổi biểu diễn thông tin cho người sử dụng. Xử lý 
dữ liệu lớn có các quan hệ phức tạp, được lưu trữ trong 
các cơ sở dữ liệu quan hệ hay hướng đối tượng . 
 Hệ thống kỹ thuật (Technical system): Xử lý và điều 
khiển các thiết bị kỹ thuật như viễn thông, hệ thống quân 
sự, hay các quy trình công nghiệp. Đây là loại thiết bị xử 
lý các giao tiếp đặc biệt, không có phần mềm chuẩn và 
thường là các hệ thống thời gian thực (real time). 
 Hệ thống nhúng (Embeded system): Thực hiện trên phần 
cứng gắn vào các thiết bị như điện thoại di động, điều 
khiển xe hơi. Điều này được thực hiện bằng lập trình 
mức thấp với hỗ trợ thời gian thực. Những hệ thống này 
thường không có các thiết bị như màn hình đĩa cứng. 
14 
Lĩnh vực ứng dụng UML 
 Hệ thống phân tán (Distributed system): Được phân bố 
trên một số máy cho phép truyền dữ liệu từ nơi này đến 
nơi khác một cách dễ dàng. Hệ thống này có cơ chế liên 
lạc đồng bộ để đảm bảo sự toàn vẹn dữ liệu và thường 
được xây dựng trên một số các kỹ thuật đối tượng như 
CORBA, COM/DCOM, hay Java Beans/RMI. 
 • Hệ thống giao dịch (Business system): Mô tả mục 
đích, nguồn lực (con người, máy tính), các quy tắc (luật 
pháp, chiến thuật, cơ chế), và công việc hoạt động 
nghiệp vụ. 
 • Phần mềm hệ thống (System software): Định nghĩa cơ 
sở hạ tầng kỹ thuật cho phần mềm khác sử dụng, chẳng 
hạn như hệ điều hành, cơ sở dữ liệu, giao diện người sử 
dụng. 
15 
Lĩnh vực ứng dụng UML 
UML được sử dụng trong ba loại mô hình hệ thống: 
 Các mô hình chức năng, được thể hiện trong 
UML với biểu đồ Use Case, mô tả các chức năng 
của hệ thống từ quan điểm của người sử dụng. 
 Các mô hình đối tượng, được thể hiện trong UML 
với biểu đồ lớp, mô tả cấu trúc của hệ thống bằng 
các đối tượng, các thuộc tính, các liên kết, và các 
hoạt động. 
 Các mô hình động, được thể hiện trong UML với 
biểu đồ tương tác, biểu đồ trạng thái, và biểu đồ 
hoạt động, mô tả các hành vi nội bộ của hệ thống. 
16 
UML và các giai đoạn phát triển hệ 
thống 
Tập hợp yêu cầu 
 UML dùng Use Case để nắm bắt các yêu cầu của 
khách hàng. UML sử dụng biểu đồ Use case (Use 
Case Diagram) để nêu bật mối quan hệ cũng như 
sự cách thức giao tiếp với hệ thống. 
 Trong Use case, các tác nhân (Actor) bên ngoài 
quan tâm đến hệ thống sẽ được mô hình hóa song 
song với chức năng mà họ đòi hỏi từ phía hệ 
thống (tức là Use case). Các tác nhân và các Use 
case được mô hình hóa cùng với các mối quan hệ 
và được miêu tả trong biểu đồ Use case của UML. 
17 
UML và các giai đoạn phát triển hệ 
thống 
Giai đoạn phân tích 
 quan tâm đến quá trình trừu tượng hóa, hình thành các lớp và 
các đối tượng cũng như cơ chế hiện hữu trong phạm vi vấn đề. 
 Sau khi nhà phân tích đã nhận biết được các lớp thành phần của 
mô hình cũng như mối quan hệ giữa chúng với nhau, các lớp 
cùng các mối quan hệ đó sẽ được miêu tả bằng biểu đồ lớp 
(class diagram) của UML. 
 Sự cộng tác giữa các lớp nhằm thực hiện các Use case cũng sẽ 
được miêu tả nhờ vào các mô hình động (dynamic models) của 
UML. Trong giai đoạn phân tích, chỉ duy nhất các lớp có tồn tại 
trong phạm vi vấn đề (các khái niệm đời thực) là được mô hình 
hóa. 
 Giai đoạn này chưa xét đến các lớp kỹ thuật, định nghĩa chi tiết 
cũng như giải pháp trong hệ thống phần mềm, ví dụ như các lớp 
cho giao diện người dùng, cho ngân hàng dữ liệu, cho giao tiếp. 
18 
UML và các giai đoạn phát triển hệ 
thống 
Thiết kế 
 Kết quả của giai đoạn phân tích sẽ được mở rộng thành 
giải pháp kỹ thuật. 
 Các lớp mới sẽ được bổ sung để tạo thành hạ tầng cơ sở 
kỹ thuật: Giao diện người dùng, các chức năng để lưu 
trữ các đối tượng trong ngân hàng dữ liệu, giao tiếp với 
các hệ thống khác, giao diện với các thiết bị ngoại vi và 
các máy móc khác trong hệ thống. 
 Các lớp thuộc phạm vi vấn đề có từ giai đoạn phân tích 
sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra 
khả năng thay đổi trong cả hai phương diện: Phạm vi 
vấn đề và hạ tầng cơ sở. Giai đoạn thiết kế sẽ đưa ra kết 
quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ 
thống. 
19 
UML và các giai đoạn phát triển hệ 
thống 
Xây dựng (triển khai lập trình) 
 Các lớp của giai đoạn thiết kế sẽ được chuyển thành 
những dòng code trong một ngôn ngữ lập trình hướng 
đối tượng cụ thể (lưu ý không nên dùng ngôn ngữ lập 
trình hướng chức năng). 
 Đây có thể là một công việc khó khăn hay dễ dàng tùy 
theo khả năng của ngôn ngữ được lựa chọn. 
 Khi tạo ra các mô hình phân tích và thiết kế trong 
UML, tốt nhất nên tránh biến đổi ngay lập tức các mô 
hình này thành các dòng code. 
 Mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo 
nên cấu trúc của hệ thống trong những giai đoạn 
trước. 
20 
UML và các giai đoạn phát triển hệ 
thống 
Kiểm thử 
Các nhóm sử dụng biểu đồ UML khác nhau làm nền 
tảng cho công việc của mình: 
 Kiểm thử đơn vị sử dụng biểu đồ lớp (class 
diagram) và đặc tả lớp, 
 kiểm thử tích hợp thường sử dụng biểu đồ thành 
phần (component diagram) và biểu đồ cộng tác 
(collaboration diagram), và 
 giai đoạn kiểm thử hệ thống sử dụng biểu đồ Use 
case (Use Case diagram) để đảm bảo hệ thống có 
phương thức hoạt động đúng như đã được định 
nghĩa từ ban đầu trong các biểu đồ này. 
21 
Các khái niệm cơ bản của UML 
 Hướng nhìn (view): Hướng nhìn chỉ ra 
những khía cạnh khác nhau của hệ thống 
cần phải được mô hình hóa. Một hướng 
nhìn không phải là một bản vẽ, mà là một 
sự trừu tượng hóa bao gồm một loạt các 
biểu đồ khác nhau 
 Biểu đồ (diagram): Biểu đồ là các hình vẽ 
miêu tả nội dung trong hướng nhìn. UML 
có tất cả 9 loại biểu đồ được sử dụng kết 
hợp để mô tả các hướng nhìn của hệ 
thống. 
22 
Các khái niệm cơ bản của UML 
 Phần tử mô hình (model element): Các 
khái niệm được sử dụng trong các biểu đồ 
được gọi là các phần tử mô hình, thể hiện 
các khái niệm hướng đối tượng quen 
thuộc. 
 Cơ chế chung: Cơ chế chung cấp thêm 
những lời nhận xét bổ sung, các thông tin 
cũng như các quy tắc ngữ pháp về một 
phần tử mô hình. Cơ chế chung còn có các 
cơ chế để có thể mở rộng ngôn ngữ UML 
23 
Các khái niệm cơ bản của UML 
Hướng nhìn 
 Một hệ thống cần phải được miêu tả với 
nhiều khía cạnh khác nhau: về mặt chức 
năng (cấu trúc tĩnh cũng như các tương 
tác động), về mặt phi chức năng (yêu cầu 
về thời gian, về độ đáng tin cậy, về quá 
trình thực thi) cũng như về khía cạnh tổ 
chức (tổ chức làm việc, quan hệ mô hình 
với dòng code). 
24 
Các khái niệm cơ bản của UML 
Hướng nhìn 
 Mỗi một hướng nhìn được miêu tả bằng 
nhiều biểu đồ, chứa đựng các thông tin 
nêu bật khía cạnh đặc biệt đó của hệ 
thống. Trong thực tế khi phân tích và thiết 
kế rất dễ xảy ra sự trùng lặp thông tin, cho 
nên một biểu đồ trên thật tế có thể là 
thành phần của nhiều hướng nhìn khác 
nhau. 
25 
Các khái niệm cơ bản của UML 
Hướng nhìn 
 Hướng nhìn Use case (Use Case view): 
đây là hướng nhìn chỉ ra khía cạnh chức 
năng của một hệ thống, nhìn từ hướng tác 
nhân bên ngoài. 
 Hướng nhìn Logic (logical view): chỉ ra 
chức năng sẽ được thiết kế bên trong hệ 
thống như thế nào, qua các khái niệm về 
cấu trúc tĩnh cũng như ứng xử động của 
hệ thống. 
26 
Các khái niệm cơ bản của UML 
Hướng nhìn 
 Hướng nhìn Thành phần (component 
view): chỉ ra khía cạnh tổ chức của các 
thành phần code. 
 Hướng nhìn Song song (concurrent view): 
chỉ ra sự tồn tại song song/ trùng hợp 
trong hệ thống, hướng đến vấn đề giao 
tiếp và đồng bộ hóa trong hệ thống. 
 Hướng nhìn Triển khai (deployment 
view): chỉ ra khía cạnh triển khai hệ thống 
27 
Các khái niệm cơ bản của UML 
28 
Các khái niệm cơ bản của UML 
29 
Hướng nhìn Use case (Use case View) 
 miêu tả chức năng của hệ thống sẽ phải 
cung cấp do được tác nhân từ bên ngoài 
mong đợi. 
 Tác nhân là thực thể tương tác với hệ 
thống; đó có thể là một người sử dụng 
hoặc là một hệ thống khác. 
 Biểu đồ Use case (Use Case diagram) và 
thỉnh thoảng cũng bao gồm cả các biểu đồ 
hoạt động (activity diagram). 
Các khái niệm cơ bản của UML 
30 
Hướng nhìn Use case (Use case View) 
 Mục tiêu của hệ thống là cung cấp các 
chức năng được miêu tả trong hướng nhìn 
này, cùng với một vài các thuộc tính mang 
tính phi chức năng. 
 Hướng nhìn Use case có ảnh hưởng đến 
tất cả các hướng nhìn khác. 
 Hướng nhìn này cũng được sử dụng để 
thẩm tra (verify) hệ thống trong kiểm thử, 
xem hệ thống có các chức năng yêu cầu. 
 
Các khái niệm cơ bản của UML 
31 
Hướng nhìn Use case (Use case View) 
 
Các khái niệm cơ bản của UML 
32 
Hướng nhìn logic (Logical View) 
 miêu tả phương thức mà các chức năng 
của hệ thống sẽ được cung cấp. 
 Nó được sử dụng chủ yếu cho các thiết kế 
viên và nhà phát triển. 
 Ngược lại với hướng nhìn Use case, 
hướng nhìn logic nhìn vào phía bên trong 
của hệ thống. 
 
Các khái niệm cơ bản của UML 
33 
 Cấu trúc tĩnh được miêu tả bằng các biểu 
đồ lớp (class diagram) và biểu đồ đối 
tượng (object diagram). 
 Quá trình mô hình động được miêu tả 
trong các biểu đồ trạng thái (state 
diagram), Biểu đồ trình tự (sequence 
diagram), biểu đồ tương tác (collaboration 
diagram) và biểu đồ hoạt động (activity 
diagram). 
 
 
Các khái niệm cơ bản của UML 
34 
Hướng nhìn thành phần (Component 
View) 
 mô tả việc thực thi các module cũng như 
sự phụ thuộc giữa chúng với nhau. Nó 
thường được sử dụng cho nhà phát triển 
và bao gồm nhiều biểu đồ thành phần. 
 Thành phần ở đây là các module lệnh 
thuộc nhiều loại khác nhau, sẽ được chỉ ra 
trong biểu đồ cùng với cấu trúc cũng như 
sự phụ thuộc của chúng. 
Các khái niệm cơ bản của UML 
35 
Hướng nhìn song song (Concurrency 
View) 
 nhắm tới việc chia hệ thống thành các qui 
trình (process) và các bộ xử lý 
(processor). 
 Khía cạnh này vốn là một thuộc tính phi 
chức năng của hệ thống, cho phép ta sử 
dụng một cách hữu hiệu các nguồn tài 
nguyên, thực thi song song, cũng như xử 
lý các sự kiện không đồng bộ từ môi 
trường. 
Các khái niệm cơ bản của UML 
36 
Hướng nhìn triển khai (Deployment View) 
 Có các biểu đồ triển khai về mặt vật lý 
của hệ thống, ví dụ các máy tính, thiết bị 
và sự liên kết giữa chúng với nhau. 
 Hướng nhìn triển khai giành cho các nhà 
phát triển, người tích hợp cũng như người 
kiểm thử hệ thống và được thể hiện bằng 
các biểu đồ triển khai. 
Các khái niệm cơ bản của UML 
37 
Các khái niệm cơ bản của UML 
38 
Biểu đồ (Diagram) 
 là các hình vẽ bao gồm các ký hiệu phần 
tử mô hình hóa được sắp xếp để minh họa 
một thành phần cụ thể hay một khía cạnh 
cụ thể của hệ thống. 
 Một mô hình hệ thống thường có nhiều 
loại biểu đồ, mỗi loại có nhiều biểu đồ. 
Một biểu đồ là một thành phần của một 
hướng nhìn cụ thể; và khi được vẽ ra, nó 
thường thường cũng được xếp vào một 
hướng nhìn. 
Các khái niệm cơ bản của UML 
39 
Biểu đồ (Diagram) 
Các khái niệm cơ bản của UML 
40 
Biểu đồ (Diagram) 
Use Case được sử dụng trong quá trình tập 
hợp yêu cầu và phân tích yêu cầu để mô tả 
chức năng của hệ thống. Use Case xem các 
hành vi của hệ thống với góc nhìn từ bên 
ngoài hệ thống. Một Use Case mô tả chức 
năng của hệ thống với sự tham gia của tác 
nhân (actor). Một tác nhân thể hiện một 
thực thể tương tác với hệ thống. 
Các khái niệm cơ bản của UML 
41 
Biểu đồ (Diagram) 
Việc xác định các tác nhân và các Use Case 
sẽ định ra phạm vi của hệ thống: phân biệt 
các nhiệm vụ thực hiện bởi hệ thống và các 
nhiệm vụ thực hiện bởi môi trường. Các tác 
nhân đứng ở bên ngoài phạm vi của hệ 
thống, trong khi các Use Case nằm bên 
trong phạm vi của hệ thống. 
Các khái niệm cơ bản của UML 
42 
Biểu đồ (Diagram) 
Check Balance
Card Holder
Withdraw Cash
Các khái niệm cơ bản của UML 
43 
Biểu đồ lớp (Class Diagrams) 
Các lớp là khái niệm trừu tượng về cấu trúc 
chung và hành vi của một tập hợp các đối 
tượng. 
Đối tượng là các trường hợp của các lớp 
được tạo ra, sửa đổi, và bị xóa trong quá 
trình thực hiện của hệ thống. 
Một đối tượng có trạng thái, bao gồm giá trị 
của các thuộc tính của nó và liên kết với các 
đối tượng khác. 
Các khái niệm cơ bản của UML 
44 
Biểu đồ lớp (Class Diagrams) 
Các khái niệm cơ bản của UML 
45 
Các lớp có thể quan hệ với nhau trong nhiều 
dạng thức: liên kết (associated - được kết 
nối với nhau), phụ thuộc (dependent - một 
lớp này phụ thuộc vào lớp khác), chuyên 
biệt hóa (specialized - một lớp này là một 
kết quả chuyên biệt hóa của lớp khác), hay 
đóng gói (packaged - hợp với nhau thành 
một đơn vị). 
Các khái niệm cơ bản của UML 
46 
Các khái niệm cơ bản của UML 
47 
Biểu đồ đối tượng 
 Một biểu đồ đối tượng (Object Diagram) 
là một phiên bản của biểu đồ lớp và 
thường cũng sử dụng các ký hiệu như biểu 
đồ lớp. 
 Sự khác biệt giữa hai loại biểu đồ này 
nằm ở chỗ biểu đồ đối tượng chỉ ra một 
loạt các đối tượng thực thể của lớp, thay 
vì các lớp. Một biểu đồ đối tượng vì vậy 
là một ví dụ của biểu đồ lớp 
Các khái niệm cơ bản của UML 
48 
Biểu đồ đối tượng 
Các khái niệm cơ bản của UML 
49 
Biểu đồ trạng thái (State Diagram) 
 Không được vẽ cho tất cả các lớp, mà chỉ 
riêng cho những lớp có một số lượng các 
trạng thái được định nghĩa rõ ràng và hành 
vi của lớp bị ảnh hưởng và thay đổi qua 
các trạng thái khác nhau. 
 Chỉ ra tất cả các trạng thái mà đối tượng 
của lớp này có thể có, và những sự kiện 
(event) nào sẽ gây ra sự thay đổi trạng. 
Các khái niệm cơ bản của UML 
50 
Biểu đồ trạng thái (State Diagram) 
 Một trạng thái đại diện cho một tập hợp 
các giá trị cho một đối tượng. 
 Một trạng thái có thể chuyển đổi sang một 
trạng thái khác khi có thỏa mãn một điều 
kiện nhất định. 
 Vòng tròn nhỏ màu đen là trạng thái ban 
đầu. 
 Một vòng tròn xung quanh một vòng tròn 
nhỏ màu đen là trạng thái cuối cùng. 
Các khái niệm cơ bản của UML 
51 
Biểu đồ trạng thái (State Diagram) 
White's turn
Black's turn
Black wins
Draw
White wins
Start
checkMate
staleMate
staleMate
checkMate
Chess game
Các khái niệm cơ bản của UML 
52 
 Biểu đồ hoạt động (Activity Diagrams) 
 Chỉ ra một trình tự lần lượt của các hoạt 
động. 
 Biểu đồ hoạt động thường được sử dụng 
để miêu tả các hoạt động được thực hiện 
trong một thủ tục, mặc dù nó cũng có thể 
được sử dụng để miêu tả các dòng chảy 
hoạt động khác, ví dụ như trong một Use 
case hay trong một trình tự tương tác. 
Các khái niệm cơ bản của UML 
53 
Biểu đồ hoạt động (Activity Diagrams) 
 Dòng điều khiển ở đây chạy giữa các 
trạng thái hành động liên kết với nhau. 
 Biểu đồ còn có thể chỉ ra các quyết định, 
các điều kiện, cũng như phần thực thi 
song song của các trạng thái hành động. 
 Biểu đồ ngoài ra còn có thể chứa các loại 
đặc tả cho các thông điệp được gửi đi 
hoặc được nhận về, trong tư cách là thành 
phần của hành động được thực hiện. 
Các khái niệm cơ bản của UML 
54 
Biểu đồ hoạt động (Activity Diagrams) 
Receive 
order
Fill order Send invoice
Overnight 
delivery
Regular 
delivery
Receive 
payment
Close order
End
Các khái niệm cơ bản của UML 
55 
Biểu đồ trình tự (Sequence Diagram) 
 Mô hình hóa các hành vi động của hệ 
thống và dễ hình dung cách liên lạc giữa 
các đối tượng. 
 Biểu đồ tương tác có ích cho việc xác 
định các đối tượng bổ sung tham gia trong 
các Use Case. Trong biểu đồ có trình tự 
các thông điệp (message) được gửi giữa 
các đối tượng và trình tự tương tác giữa 
các đối tượng, 
Các khái niệm cơ bản của UML 
56 
Biểu đồ trình tự (Sequence Diagram) 
ATM BankAccount Holder
Identify
Request authentication
Provide authentication
Authenticate identity
Confirm identity
Các khái niệm cơ bản của UML 
57 
Biểu đồ cộng tác (Collaboration 
Diagram) 
 Việc lựa chọn sử dụng Biểu đồ trình tự 
hay biểu đồ cộng tác thường sẽ được 
quyết định theo nguyên tắc chung sau: 
Nếu thời gian hay trình tự là yếu tố quan 
trọng nhất cần phải nhấn mạnh thì hãy 
chọn biểu cộng tác. Trình tự tương tác 
giữa các đối tượng được thể hiện trong cả 
hai loại biểu đồ này 
Các khái niệm cơ bản của UML 
58 
Biểu đồ cộng tác (Collaboration 
Diagram) 
Các khái niệm cơ bản của UML 
59 
Biểu đồ thành phần (Component Diagram) 
miêu tả cấu trúc vật lý của các dòng lệnh 
(code) theo khái niệm thành phần code. 
 Một thành phần code có thể là một tập tin 
source code, một thành phần nhị phân 
(binary) hay một thành phần thực thi được 
(executable). 
 Một thành phần chứa các thông tin về các 
lớp logic hoặc các lớp mà nó thi hành, như 
vậy nó tạo ra một ánh xạ từ hướng nhìn 
logic vào hướng nhìn thành phần. 
Các khái niệm cơ bản của UML 
60 
Biểu đồ thành phần (Component Diagram) 
Các khái niệm cơ bản của UML 
61 
Biểu đồ triển khai (Deployment Diagram) 
 mô tả kiến trúc vật lý của phần cứng cũng 
như phần mềm trong hệ thống. 
 Biểu đồ có thể chỉ ra từng máy tính cụ thể 
và từng trang thiết bị cụ thể (node) với sự 
kết nối giữa chúng. 
 Biểu đồ cũng có thể chỉ ra loại của các 
mối kết nối. d 
Các khái niệm cơ bản của UML 
62 
Biểu đồ triển khai (Deployment Diagram) 
Các khái niệm cơ bản của UML 
63 
Phần tử mô hình 
 Các khái niệm được sử dụng trong các 
biểu đồ được gọi là các phần tử mô hình 
(model element). 
 Một phần tử mô hình được định nghĩa với 
ngữ nghĩa (semantic), đó là một định 
nghĩa về bản chất phần tử hay là ý nghĩa 
chính xác xem nó sẽ thể hiện điều gì. Mỗi 
phần tử mô hình còn có được miêu tả trực 
quan bằng một ký hiệu hình học. 
Các khái niệm cơ bản của UML 
64 
Phần tử mô hình 
Các khái niệm cơ bản của UML 
65 
Kết nối (Association): nối các phần tử và các thực thể 
nối. 
Khái quát hóa (Generalization): còn được gọi là tính 
thừa kế, có nghĩa rằng một phần tử này có thể là một sự 
chuyên biệt hóa của một phần tử khác. 
Sự phụ thuộc (Dependency): chỉ ra rằng một phần tử 
phụ thuộc vào một phần tử khác trong một phương thức 
nào đó. 
Kết tập (Aggregation): Một dạng của kết nối, trong đó 
một phần tử này chứa các phần tử khác. 
Các khái niệm cơ bản của UML 
66 
Cơ chế chung 
 UML thể hiện một số các cơ chế chung 
(general mechanism) trong tất cả các biểu 
đồ nhằm mục đích cung cấp thêm các 
thông tin bổ sung, đây thường là những 
thông tin không thể được thể hiện qua các 
chức năng và khả năng cơ bản của các 
phần tử mô hình. 
Các khái niệm cơ bản của UML 
67 
 Trang trí (adornment) trực quan có thể 
được sử dụng thêm cho các phần tử mô 
hình trong biểu đồ. 
 Động tác trang trí bổ sung ngữ nghĩa cho 
phần tử. 
 Ví dụ kỹ thuật để phân biệt một loại thực 
thể (lớp) và một thực thể: khi thể hiện một 
loại, tên phần tử sẽ được in đậm; khi 
chính phần tử đó thể hiện chỉ một thực thể 
của loại này, tên phần tử sẽ được gạch 
dưới 
Các khái niệm cơ bản của UML 
68 
Các khái niệm cơ bản của UML 
69 
 Để bổ sung thêm cho một mô hình những 
thông tin không thể được thể hiện bằng 
phần tử mô hình, UML cung cấp khả năng 
kèm theo lời ghi chú (Note). 
 Một lời ghi chú có thể được để bất kỳ nơi 
nào trong bất kỳ biểu đồ nào, và nó có thể 
chứa bất kỳ loại thông tin nào. 
 Dạng thông tin của nó là chuỗi ký tự 
(string). 
Các khái niệm cơ bản của UML 
70 
Use-Case Model
The Use-Case Model is 
traceable to (and deriv es 
f rom) the Business Model. 
 The sy stem (as described 
in the Use Case Model) 
prov ides behav ior that 
supports the business.
Business Use-Case 
Model
Các khái niệm cơ bản của UML 
71 
Đặc tả (specification) có nhiều hình thức. 
Các phần tử mô hình có thuộc tính 
(property) chứa các giá trị dữ liệu về phần 
tử này. 
 Một thuộc tính được định nghĩa với một 
tên và một giá trị đính kèm (tagged value), 
thường ở trong một dạng thông tin được 
xác định trước, ví dụ như số nguyên hay 
chuỗi kí tự. 
Các khái niệm cơ bản của UML 
72 
Đặc tả (specification) 
Các khái niệm cơ bản của UML 
73 
Khuôn mẫu (Stereotype) định nghĩa một loại 
phần tử mô hình mới dựa trên một phần tử mô 
hình đã tồn tại. 
• Khuôn mẫu có thể được coi là "tương tự" như 
một phần tử đã có sẵn, cộng thêm phần quy 
định ngữ nghĩa (semantic) riêng biệt không có 
trong phần tử gốc kia. 
• Khuôn mẫu của một phần tử có thể được sử 
dụng trong cùng tình huống như phần tử căn 
bản. 
Các khái niệm cơ bản của UML 
74 
Khuôn mẫu (Stereotype) 
Các khái niệm cơ bản của UML 
75 
Giá trị đính kèm (Tagged Value). Các phần tử 
mô hình UML có nhiều các thuộc tính được 
định nghĩa trước, nhưng người sử dụng có thể 
định nghĩa ra các thuộc tính mới để bổ sung 
thông tin các phần tử mô hình. 
Các khái niệm cơ bản của UML 
76 
 Một sự hạn chế (Constraint) là một giới 
hạn về sử dụng hoặc ý nghĩa của một phần 
tử. Sự hạn chế hoặc sẽ được khai báo 
trong công cụ và được sử dụng nhiều lần 
trong nhiều biểu đồ khác nhau, hoặc được 
định nghĩa và sử dụng chỉ trong một biểu 
đồ, theo yêu cầu. 
Các khái niệm cơ bản của UML 
77 
Mô hình hóa với UML 
 Khi xây dựng hệ thống với UML, người ta 
không chỉ xây dựng duy nhất một mô 
hình. 
 Sẽ có nhiều mô hình trong các giai đoạn 
phát triển, nhắm đến các mục đích khác 
nhau. 
Các khái niệm cơ bản của UML 
78 
Mô hình hóa với UML 
Các khái niệm cơ bản của UML 
79 
Mô hình hóa với UML 
Ngôn ngữ UML không phụ thuộc vào giai 
đoạn, có nghĩa là cùng một nguyên tắc ngôn 
ngữ và các biểu đồ được sử dụng để mô 
hình hóa những sự việc trong những giai 
đoạn khác nhau. 
Các khái niệm cơ bản của UML 
80 
Mô hình hóa với UML 
Khi mô hình hóa bằng ngôn ngữ UML, toàn 
bộ công việc cần phải được thực hiện theo 
một phương pháp hay một qui trình, xác 
định rõ các bước công việc cần được tiến 
hành và cách thực thi từng bước. Một qui 
trình như vậy thường sẽ chia công việc ra 
thành các vòng lặp nối tiếp, mỗi vòng lặp 
bao gồm các công việc: phân tích yêu cầu - 
phân tích - thiết kế - thực hiện - triển khai. 
Các khái niệm cơ bản của UML 
81 
Mô hình hóa với UML 
Các khái niệm cơ bản của UML 
82 
Công cụ UML 
 Sử dụng một ngôn ngữ mô hình hóa phức 
tạp và rộng mở như UML cần thiết có trợ 
giúp của công cụ (tool). 
 Mặc dù phác thảo đầu tiên của một mô 
hình có thể được thực hiện bằng bảng, 
giấy và bút, công việc bảo trì, đồng bộ hóa 
và đảm bảo sự nhất quán trong một loạt 
các biểu đồ khác nhau thường lại không 
thể trở thành khả thi nếu thiếu công cụ. 
Các khái niệm cơ bản của UML 
83 
Công cụ UML 
 Công cụ hỗ trợ hiện đang giảm ngắn khi 
duy trì phụ thuộc hai chiều, đặc biệt là 
giữa các mô hình phân tích và mã nguồn. 
 Một số công cụ, chẳng hạn như Cơ sở lý 
luận Rose [Rational năm 2002 và cùng 
nhau kiểm soát Trung tâm [TogetherSoft, 
2002], thực hiện chức năng này bằng cách 
nhúng thông tin về Liên hệ và UML cấu 
trúc khác trong ý kiến mã nguồn. 
Các khái niệm cơ bản của UML 
84 
Công cụ UML 
Công cụ mô hình hóa hiện đại cần phải 
cung cấp các chức năng sau: 
 Vẽ biểu đồ: cần phải tạo điều kiện dễ dàng 
vẽ ra các biểu đồ trong ngôn ngữ mô hình 
hóa. 
 Hoạt động như một nhà kho (repository): 
công cụ cần phải hỗ trợ một nhà kho trung 
tâm lưu tất cả các thông tin về mô hình 
trong cùng một chỗ. 
Các khái niệm cơ bản của UML 
85 
Công cụ UML 
 Hỗ trợ định hướng (navigation): công cụ 
cần phải tạo điều kiện dễ dàng cho người 
sử dụng định hướng và chuyển dịch trong 
mô hình để theo dõi một phần tử từ biểu 
đồ này sang biểu đồ khác, hoặc để phát 
triển mô tả của một phần tử. 
Các khái niệm cơ bản của UML 
86 
Công cụ UML 
 Hỗ trợ nhiều người sử dụng (multiuser 
support): Công cụ cần hỗ trợ cho nhiều 
người sử dụng, và tạo điều kiện cho họ 
cùng làm việc với một mô hình và kiểm 
soát để những người trong nhóm không 
làm hỏng kết quả của nhau. 
 Tự động tạo code (code generate): khả 
năng tạo ra code, nơi tất cả các thông tin 
trong mô hình được chuyển tải thành các 
khung code 
Các khái niệm cơ bản của UML 
87 
Công cụ UML 
 Tái tạo mô hình (reserve engineer): Một 
công cụ cao cấp cần phải có khả năng đọc 
những thành phần code đang tồn tại và từ 
đó xây dựng mô hình tương ứng. 
 Tích hợp với các công cụ khác: một công 
cụ cần phải có khả năng tích hợp với 
những công cụ khác, với môi trường phát 
triển, 
Các khái niệm cơ bản của UML 
88 
Công cụ UML 
 Bao quát mô hình ở các mức độ trừu 
tượng hóa: công cụ cần phải dễ chuyển tải 
từ lời miêu tả ở cấp trừu tượng hóa cao 
nhất của hệ thống đi xuống cho tới cấp 
của những dòng code thật sự. 
 Trao đổi mô hình: Một mô hình hay một 
biểu đồ của một mô hình cần phải có khả 
năng được xuất ra từ một công cụ này rồi 
nhập vào một công cụ khác 
DISCUSSION – CÂU HỎI 
https://sites.google.com/site/daonamanhedu/teac
hing/objectorientedanalysisanddesign 
89