uml và ứng dụng để xây dựng mô hình cho hệ thống tín dụng

ĐẠI HỌC QUỐC GIA HÀ NỘI
KHOA CÔNG NGHỆ
MAI THỊ THANH HƯỜNG
UML VÀ ÚNG DỤNG ĐỂ XÂY DỤNG MÔ
HÌNH CHO HỆ THỐNG TÍN DỤNG
LUẬN VĂN THẠC sĩ KHOA HỌC
• • •
0A>
HÇC C.UOC G f>- Î". ft
TRŨKGTÀM ■S’HGÎÎ-'- í Hư'
Y - tẸ. sụ
HÀ NỘI, NĂM 2001
ĐẠI HỌC QUỐC GIA HÀ NỘI
KHOA CÔNG NGHỆ
MAI THỊ THANH HƯỜNG
UML YÀ ÚNG DỤNG ĐỂ XÂY DựNG MÔ
HÌNH CHO HỆ THỐNG TÍN DỤNG
CHUYÊN NGÀNH : CÔNG NGHỆ THÔNG TIN
MẢ SỐ:
LUẬN VĂN THẠC sĩ KHOA HỌC
• « a
NGƯỜI HƯỚNG DAN KHOA HỌC: PGS N G UYẺN Quốc TOẢN
HÀ NỘI, NÁM 2001
MỤC LỤC
CHƯƠNG 1 TỔNG QUAN VỀ ƯML
3
1.1 Mục đích của việc xây dựng mồ hình cho hệ thống

3
1.2 Lịch sử phát triển của UM L 5
1.3 Mục liêu của UM L 7

1.4 ứng dụng của UM L 7
1.5 Các thảnh phần của UML 8
1.5.1 Các phần tử mô hình 8
1.5.2 Các biểu đồ 9
1.5.3 Các view 13
1.5.4 Các cơ chế chung của UM L 16
CHƯƠNG 2 PHÂN TÍCH, THIÊT KẾ HƯỚNG ĐÔÍ TƯỢNG s ử DỤNG UML

.
!

19
2.1 Phân tích Use case 22
2.1.1 Actor 22
2.1.2 Xác định các Actor 23
2.1.3 Use case 24
2.1.4 Các mối quan hệ 30
2.1.5 Biếu đồ Use case 31
2.2 Tim lớp 34
2.2.1 Đối tượng 34
2.2.2 Lớp r 34
2.2.3 Các quan hệ 38
2.2.4 Gói

42
2.2.5 Biểu đồ đối tượng 44
2.3 Phàn tích sự tương tác giữa các đối tượng 45
2.3.1 Kịch bản 45
2.3.2 Biểu đồ trình tự 47
2.3.3 Biểu đồ hợp tác 49

2.4 Them vào các thuộc tính và phương thức cho lớp 50
2.4.1 Thuộc tín h 50
2.4.2 Phương thức 51
2.5 Xác định ứng xử của đối tượng 52
2.5.1 Biểu đồ trạng thái 52
2.5.2 Biêu đồ hoạt động 55
2.6 Xác định kiến trúc của hệ thống 57
2.6.1 Thành phần (xem [3]) 57
2.6.2 Biểu đồ thành phần 57
2.6.3 Biêu đồ triển khai
.
58
CHƯƠNG 3 - ÚNG DỤNG ƯML ĐỂ XÂY DựNG MÔ HÌNH CHO HỆ THỐNG
TÍN DỤNG 59
3.1 Phát biểu bài toán 59
3.2 Mô tá nghiệp vụ 59
3.3 Mỏ tả quy trình kỹ thuật 60
3.4 Yêu cầu 60
3.5 Phân tích Use case 61
3.5.1 Các Actor của hệ thống 61
3.5.2 Danh sách Use case: 62
3.5.3 Mô tả các Use case 66
3.5.4 Các biểu đồ Use case 71
3.6 Biểu đồ lớp 74
3.6.1 Các lớp thực thể (Entity Class) 74
3.6.2 Các lớp biên (Boundary Classes) 83
3.6.3 Các lớp điều khiển (Control Classes) 102
3.7 Sự tương tác giữa các đối tượng 103
3.7.1 Kịch bản

.7.

'
103
3.7.2 BỈểu đồ trình tự 104
3.7.3 Biểu đổ hợp tác 105
3.8 Biêu đồ triển khai 106
KẾT LUẬN 107
- 2-
LỜI NÓI ĐẦU
Trong những nãm gần đây, thuật ngữ UML đã dần trở nên quen thuộc đối với
những người làm tin học nói chung và những người làm phần mềm nói riêng. Vậy
UML là gì. nó được sử dụng để làm gì, cách thức sử dụng nó như thế nào? Luận văn
“ UML và ứng dụng để xây dựng mô hình cho hệ thống tín dụng” sẽ trả lời cho các
câu hỏi đó.
Luận văn này gồm 3 phần. Phần I giới thiệu tổng quan về ƯML, sự ra đời,
phát triển và các thành phần của ƯML. UML là một ngổn ngữ mô hình hoá thống
nhất, nó tổng hợp được ưu điểm trong các phương pháp của 3 nhà sáng lập (Grady
Booch, James Rumbaugh và Ivar Jacobson) và hạn chế khuyết điểm trong các
phương pháp đó. UML được sử dụng đê mổ hình cho rất nhiều hệ thống, không nhất
thiết phái là các hệ thống phần mềm.
Phần II xây dựng quy trình cho việc phân tích thiết kế hệ thống sử dụng
ƯML. Quy trình này bao gồm các bước như sau:
Bước 1 : Cách xác định các Actor, các use case, mối quan hệ giữa các use
case từ đó xây dựng được biểu đồ use case.
Bước 2: Cách xác định các lớp, các đối tượng, mối quan hệ giữa các lớp hay
giữa các đối tượngbiểu đổ lớp và biểu đồ đối tượng.
Bước 3: Cách xác định các kịch bản từ use case, từ đó xây dựng biểu đồ trình
tự và biểu đồ hợp tác.
Bước 4: Thêm vào các thuộc tính và phương thức cho các lớp

Bước 5: Cách xác định các ứng xử của mỗi đối tượng thông qua biểu đồ trạng
thái và biêu đồ hoạt động. Một số gợi ý để có thể xây dựng biểu đồ trạng thái từ biểu
đồ trình tự.
Bước 6: Xác định kiến trúc của hệ thống bẳng cách xác định các thành phần
của hệ thống, xây dựng các biểu đồ thành phần và biểu đồ triển khai.
Đối vói mỗi bước trong quy trình trên, luận văn đều đưa ra các ví dụ minh
hoạ cụ thế.
Phần III của luận văn tập trung vào việc sử dụng UML để mô hình hệ thống
tín dụng. Tín dụng là một hoạt động rất quan trọng trong ngành Ngân Hàng, quản lý
các hồ sơ và hợp đổng tín dụng là việc iàm không thế thiếu của các cán bộ tín dụng.
Việc mô hình hệ thống tín dụng giúp các cán bộ tín dụng nói riêng và các cán bộ
Ngân Hàng nói chung trong việc quản lý các hổ sơ. hợp đồng tín dụng một cách
chính xác và hiệu quả. Phần III bắt đầu bàng việc tìm hiểu quy trình nghiệp vụ tín
dạne. các yêu cầu mà hệ thống cần phải đáp ứng. Trên cơ sở các yêu cầu đó xây
dựng nên một mô hình, việc xây dựng mô hình này áp dụng các lý thuyết đã được
nêu ở phần II. Đầu tiên là xác định các Actor của hệ thống, sau đó liệt kê các use
case có thể có dựa trên các yêu cầu đã được xác định trong phần trên. Việc xác định
các lớp thực thể, các lớp biên và các lớp điểu khiển dựa vào các Actor và các use
case đã tìm được. Việc mô tả chi tiết các use case giúp tìm kiếm các kịch bản và từ
các kịch bản này các biểu đồ trình tự và biểu đồ hợp tác được xây dựng. Từ đó ta có
thê hình dung được hệ thống theo cả hai mặt tĩnh và động. Phần này sử dụng công
cụ Rational Rose để vẽ các lớp, các Actor cũng như các biểu đồ. Thông qua phần
này, ta có thế hiểu được cách thức sử dụng UML đê’ giải quyết một bài toán trong
thực tế.
Trong quá trình làm chắc chắn không thể tránh khỏi những sai sót, em rất
mong nhộn được sự góp ý của các thầy cô. Em cũng xin gửi lời cảm ơn chân thành
đến PGS Nguyền Quốc Toản, người đã giúp đỡ em rất nhiều để em có thể hoàn
thành luận vãn này.
Hà Nội ngày 14 tháng 11 năm 2001
Mai Thị Thanh Hường

CHƯƠNG 1 TỔNG QUAN VỀ UML
1.1 Mục đích của việc xây dựng mò hình cho hệ thống
Mô hình hóa là một cách xem xét bài toán thông qua việc sử dụng các mỏ
hình. Mó hình sẽ giúp con người hiểu rõ bài toán, và thông qua mô hình việc trao
đổi thống tin giữa những người liên quan như khách hàng, chuyên gia, người phân
tích, người thiết kế trở nên thuận tiện hơn. Mô hình giúp cho việc xác định các yêu
cầu tốt hơn, thiết kế rõ ràng hơn và khả năng bảo trì hệ thống cao hơn.
Mô hình là sự trừu tượng hóa, mô tả mặt bản chất của một vấn đề hoặc một
cấu trúc phức tạp bằng cách loại bò những chi tiết không quan trọng, khiến cho bài
toán trở nên dễ hiểu và dễ nắm bắt hơn. Người ta đã sử dụng mô hình hoá để giải
quyết các vấn đề của cuộc sống đời thường. Chẳng hạn trước khi sản xuất một chiếc
ô tố, ta phải có bản thiết kế của chiếc ô tô đó, hình dáng của nó ra sao, màu sắc như
thế nào? Việc phát triển các hệ thống phần mềm cũng tương tự như vậy. Để xây
dựng một hệ thống phức tạp, những người phát triển phải trừu tượng hóa những
View khác nhau của hệ thống, xây dựng các mô hình bằng cách sử dụng các kí hiệu,
kiểm tra xem các mô hình đã thoả mãn các yêu cầu của hệ thống chưa và dần dần
thêm vào các chi tiết để có thể chuyển đổi từ mô hình sang một cài đặt cụ thể.
Một câu hỏi đặt ra là tại sao chúng ta phải xây dựng mô hình của hệ thống,
đặc biệt là những hệ thống phức tạp? Bởi vì chúng ta không thể hình dung, không
thể hiểu trọn vẹn một lúc toàn bộ hệ thống đó. Ví dụ như khi thêu một bông hoa
chúng ta có thể thêu ngay, nhưng khi thêu một bức tranh ta phải có một bức tranh
mẫu trên giấy. Trong việc sản xuất phần mềm cũng tương tự như vậy. Hệ thống càng
phức tạp thì việc xây dựng mô hình càng quan trọng. Xây dựng mô hình cho phép
người thiết kế thấy được bức tranh tổng quan của hệ thống, thấy được các thành
phần của hệ thống tương tác với nhau như thế nào, hình dung được hệ thống từ nhiều
View khác nhau.
Ngày nav việc xây dựng các ứng dụng không còn là vấn đề, mà vấn đé là ớ
chỗ xây dựng được các ứne dụng có chất lượng cao, đáp ứng đầy đủ các yêu cầu của
khách hàng, đúng thời hạn và với chi phí hợp lý. Một tổ chức phát triển phần mềm
thành công là tổ chức xây dựng được các phần mém thoả mãn được những yêu cầu

trên.
Mỏ hình hóa là phần trung tâm trong các cống việc để dẫn tới một phần mềm
lốt. Người ta xây dựng mô hình để trao đổi, bàn bạc về cấu trúc và ứng xử (behavior)
mong muốn của hệ thống. Người ta xây dựng mô hình để trực quan hóa và kiểm soát
kiến trúc của hệ thống.
Mô hình có thể mô tả các cấu trúc, nhấn mạnh về mặt tổ chức của hệ thống
hoặc nó có thể mô tả các hành vi, tập trung vào mặt động của hệ thống.
Việc xây dựng mô hình giúp chúng ta hiểu rõ hơn về hệ thống mà mình đang
xây dựng, tạo ra cơ hội đê đơn giản hóa và tái sử dụng. Xâv dựng mô hình cũng giúp
chúng ta Irong việc kiểm soát rủi ro.
Việc xây dựng mô hình giúp chúng ta đạt được 4 mục đích sau:
• Mô hình giúp chúng ta trực quan hóa hệ thống như là nó vốn có hay
theo cách mà chúng ta muốn nó sẽ như vậy.
• Mồ hình cho phép chúng ta chỉ rõ cấu trúc và ứng xử của hệ thống
• Mô hình cho một khuôn mẫu đế hướng dẫn chúng ta trong quá trình
xây dựng hệ thống.
• Mô hình đưa ra các dẫn chứng bằng tài liệu về các quyết định mà
chúng ta đã đưa ra trong quá trình thiết kế hệ thống.
Bằng việc mô hình hoá, tại một thời điểm chúng ta chỉ tập trung nghiên cứu
một khía cạnh nào đó của bài toán. Điều này cũng giống như việc chia một bài toán
lớn thành các bài toán nhỏ mà ta có thê’ giải quyết được.
Mỏ hình hóa là việc đơn gián hóa thực tế, loại bót những điểm không cần
thiết, nhưng ta vẫn phải đảm bảo rầng mình không bỏ sót một chi tiết quan trọng
nào.
Tùy thuộc vào vêu cầu của từng bài toán, tuv vào đặc điểm của từng hệ
thống, mỗi mô hình có thể tập trung vào những View khác nhau của hệ thống.
- 5-
1.2 Lịch sử phát triển của UML
Khái niệm đối tượng ra đời kéo theo sự ra đời của các phương pháp hướng
đối tượng. Thập niên 90 đã xuất hiện một số phương pháp hướng đôí tượng chủ yếu

sau (xem [2]):
> Grady Booch: định nghĩa các khái niệm mà trong đó hệ thống được phân tích
thành 1 số các view, mổi view được mỏ tả bằng một số biểu đồ mô hình.
Phương pháp này có một khuyết điểm là có một số các ký hiệu khó sử dụng,
khó vẽ.
> OMT (Object Modeling Techique): do James Rumbaugh (trước làm ở
General Electric) đưa ra. Nó là một tiến trình mạnh để kiểm nghiệm dựa trên
việc đặc tả các yêu cầu. Được mô tả bởi một số các mô hình như mô hình đối
tượng, mô hình động, mô hình chức năng, mô hình Use-case.
> OOSE (Object - Oriented Software Engineering) /Objectory: do Ivar
Jacobson đưa ra. OOSE là một phương pháp hướng đối tượng, phương pháp
Objectory được sử dụng để xây dựng các hệ thống như hệ thống viễn thông
cho Ericson, hệ thống kế toán cho công ty WallStreat. Cả hai phương pháp
đéu dựa trên các Use-case mô tả các yêu cầu đầu tiên của hệ thống như là
được các Actor ngoài nhìn thấy. Sau đó Use-case được thi hành trong tất cả
các pha khi phát triển, tất cả các cách để kiềm nghiệm hệ thống khi nó được
(lùng đê kiểm thử hệ thống.
> Fusion do Hewlett-Packard đưa ra.
> Coad/Yourdon (OOA/OOD).
Các phương pháp trên, mỗi phương pháp lại có những điểm mạnh và điểm
yếu riêng. Vấn đề là làm sao để có được một phương pháp tích hợp được những ưu
điểm của mọi phương pháp trên và hạn chế những khuyết điểm của chúng. Ngoài
việc tích hợp các ưu điểm, hạn chế các khuyết điểm, phương pháp mới này còn phải
thống nhất được các ký hiệu của các phương pháp. Bởi vì cùng một ký hiệu nhưng
dùng trong các phương pháp khác nhau lại có thể mang V nghĩa khác nhau. Vì vậy
việc thống nhất được cách dùng các ký hiệu cũng là điều rất quan trọng.
Grady Booch, James Rumbaugh và War Jacobson bắt đầu với UML khi họ
làm việc cùng nhau tại công ly phần mềm Rational (Grady Booch và James
Rumbaugh bắt đầu trước từ năm 1994 và đến 1995 thì Ivar Jacobsson mới gia nhập
nhóm này). Mục tiêu của họ là tạo ra một phương pháp mới, phương pháp thống

nhất dựa trên các phương pháp của Booch, Rumbaugh và Jacobson. Dựa vào việc
hợp nhất các kv hiệu sử dụng trong khi phân tích, thiết kế của các phương pháp đó,
UML đưa ra một nền tảng chuẩn cho việc phân tích, thiết kế.
Tháng 7-1997 phiên bản 1.0 được còng bố và coi là chuẩn của tổ chức OMG
(Object Management Group).
Vé cơ bản ƯML dựa trên Booch của Booch, OMT của James Rumbaugh và
OOSE của Ivar Jacobson nhưng họ cũng kết hợp một vài ý tưởng cuả các phương
pháp khác như State Charts của David Hareỉ và chuyển nó thành State Diagram
trong UML hay sử dụng thao tác đánh dấu trong chú thích của Fusion trong biểu đồ
hợp tác (collaboration diagram).
UML (Unified Modeling Laguage) được dùng để mô hình cho các hệ thống
hay dùng trong những giai đoạn khác nhau của phát triển hệ thống từ đặc tả đến
kiểm thử hệ thống cuối cùng.
- 7-
Hình 1.1
Rumhaugh
numbering
1.3 Mục tiêu của UML
■ Mô hình các hệ thống (không chỉ các hệ thống phần mềm), sử dụng các khái
niệm hướng đối tượng
■ Tạo ra một ngôn ngữ mô hình có thể sử dụng được bởi cả người và máy.
1.4 ứng dụng của UML
ƯML có ứng dụng rất rộng rãi, không chỉ trong các hệ thống phần mềm mà
còn ở nhiều lĩnh vực khác như các hệ thống kỹ thuật hay các hệ thống kinh doanh,
nghiệp vụ. Một số hệ thống mà ƯML có thể mô tả là:
■ Hệ thông tin: lưu trữ, tìm kiếm, biến đổi và trình bày thông tin cho người
dùng. Phái giải quyết một số lượng lớn dữ liệu với mối quan hệ phức tạp
thường được cất giữ trong CSDL quan hệ hav CSDL đối tượng.
■ Hộ thống kỹ thuật: giải quyết các hệ thống viễn thông, quân sự hoặc các tiến
trình công nghiệp.

■ Hệ thống thời gian thực chìm (built in): được thực hiện thông qua lập trình
mức thấp và đòi hỏi sự hỗ trợ thời gian thực
* Hệ phân bố: được phân bố trên một số máy tính còn dữ liệu được truyền từ
máy nọ sang maý kia. Hệ này đòi hỏi truyền thông đồng bộ, được xây dựng
dựa trên các hệ hướng đối tượng như CORBA, COM/DCOM, JavaBean
■ Phần mềm hệ thống: hệ điều hành, CSDL
■ Hệ thống nghiệp vụ: mô tả các mục tiêu các nguồn tài nguvên (con người,
máy tính), các quy tắc (luật, chiến lược kinh doanh) và công việc thực tại
trong nghiệp vụ
1.5 Các thành phần của UML
UML có 3 thành phần chính đó là các phần tử mô hình, các biểu đồ và các
view. Phẩn tử mô hình là những khái niệm mà người la sử dụng trong các biểu đồ,
hiểu hiện cho các khái niệm đối tượng nói chung. Nó được dùng trong nhiều biểu đồ
khác nhau nhưng có cùng ký hiệu về ngữ nghĩa. View được tạo nên từ các biểu đồ.
Mỗi view cung cấp cho ta một cái nhìn về một khía cạnh nào đó của hệ thống. Tập
hợp các view cho ta một cái nhìn toàn cảnh về hệ thống.
1.5.1 Các phần tử mô hình
Các khái niệm dùng trong các biểu đồ gọi là các phần tử mô hình. Một phần
tứ mô hình được định nghĩa với ngữ nghĩa, 1 định nghĩa hình thức cho phần tử đó
hay V nghĩa đích xác của điều nó biếu diễn.
Một phần tử mô hình có một phần tử view tương írng là một thể hiện đồ hoạ
của phần tử đó hay ký hiệu đồ hoạ được dùng để thể hiện phần tử trong các biểu đồ.
Một phần tử có thể có mặt trong một vài loại biểu đồ khác nhau nhưng có một luật
để xác định phần tử nào có thể có mặt trong biểu đổ nào. Một vài ví dụ về các phần
tử mô hình là class, object, State, node, package, component.
Class
Object
attributes attributes
oprations oprations
- 9-

u<;o rasp
/
/
Node
/
~ n

Package
Note
T
Ọ
intprfarp
Component
Hình 1.2 - các phần tử
Các mối quan hệ cũng là các phần tử mô hình và được sử dụng để kết nối các
phần tử mô hình với nhau. Một vài kiêu quan hệ khác nhau là:
•S Association: Kết nối các phần tử và liên kết các thực thể.
s Generalization: còn gọi là sự kế thừa, nghĩa là một phần tử có thể là trường
hợp riêng của một phần tử khác, còn gọi là quan hệ chung - riêng.
s Dependency: một phần tử phụ thuộc một phần tử khác theo một cách nào đó.
s Aggregation: là một dạng của quan hệ association mà trong đó một phần tử
chứa một hay nhiều phần tử khác, còn gọi là quan hệ toàn thể - bộ phận.
association
dependency
aggregation (a form of association)

^ ^
generalization
>
Hình 1.3 - Các liên kết

1.5.2 Các biểu đồ
Biểu đổ (diagram) là các đồ thị mô tả các nội dung chứa trong view. UML có
9 loại hiểu đồ khác nhau. Phần lớn các biểu đổ được thể hiện như một đổ thị gồm
các đinh (các sự vật) và các cung (các quan hệ). ([6])
UML có 9 loại biếu đồ chia thành 2 nhóm khác nhau. Nhóm thứ nhất gồm 4
loại hiểu đổ là biểu đồ lớp (class diagram), biểu đồ đối tượng (object diagram), biểu
đổ thành phần (component diagram) và biểu đổ triển khai (deployment diagram).
Nhóm này mô tả các phần tĩnh của hệ thống và được gọi là các biểu đổ cấu trúc
- 10-
(stmctural diagrams) hay biểu đồ tĩnh. Nhóm thứ hai gồm các biếu đồ: biểu đồ Use-
case (Use-case diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác
(collaboration diagram), biểu đồ trạng thái (state diagram) và biểu đồ hoạt động
(activity diagram). Các biếu đồ này mô tả phần động của hệ thống và được gọi là
các biểu đồ cư xử (behavioral diagrams) hay biểu đồ động (dynamic diagrams).
1.5.2.1 Các biểu đồ câu trúc (structural diagrams)
Bốn loại biểu đồ cấu trúc của UML cho phép ta hình dung, chỉ ra, xây đựng
và làm tài liệu các khía cạnh tĩnh của hệ thống. Có thể coi các khía cạnh tĩnh của hệ
thống như một sự thể hiện tương đối phần khung cố định. Giống như các mặt tĩnh
của một ngôi nhà bao gồm các vật và cách sắp xếp như các bức tường, các cửa sổ,
các ống dẫn và các lỗ Ihông, các mặt tĩnh của hệ thống phần mềm bao gồm các lớp,
các giao diện, các sự hợp tác, các thành phần và các nút.
Các biểu đồ cấu trúc của UML được tổ chức dựa trên các nhóm sự vật chính
như sau: biểu đồ lớp dùng các lớp, các giao diện và các sự hợp tác, biểu đồ đối tượng
dùng các đối tượng, biểu đồ thành phần dùng các thành phần còn biểu đồ triển khai
dùng các nút.
1.5.2.1.1 Biểu đó lớp (class diagram)
Biêu đồ lớp: chỉ ra tập hợp các lớp, các giao diện, các sự hợp tác và các mối
quan hệ của chúng. Người ta sử dụng các biểu đồ lớp để minh hoạ thiết kế tĩnh của
hệ thống. Các lớp biểu diễn cho các sự vật được xử lý bên trong hệ thống. Các lớp có
thể có quan hệ với nhau theo một số cách sau:

s Liên kết (lớp nọ nối với lớp kia)
s Phụ thuộc ( 1 lớp này phụ thuộc hay dùng lớp kia)
S Đặc biệt hoá (lớp này ỉà một phần tử đặc biệt của lớp kia)
s Đóng gói (nhiều lớp gộp lại)
Một hệ thống có nhiều biểu đổ lớp và ngược lại một biểu đồ lớp có thể có mặt
ở nhiều hệ thống.
1.5.2.1.2 Biêu đó đỏi tượng (object diagram)
- 11-
Biểu đồ đối tượng chỉ ra tập hợp các đối lượng và các mối quan hệ của
chúng. Người ta sử dụng biểu đồ đối tượng để minh hoạ các cấu trúc dữ liệu, các
thực thế của các lớp trong biểu đồ lớp. Có thê coi biểu đồ đối tượng là một biến thể
cùa biểu đồ lớp, nó dùng các ký hiệu hầu hết giông biếu đổ lớp. Biểu đồ đối tượng
chí ra một số thể nghiệm đối tượng của một lớp.
1.5.2.1.3 Biểu dó thành phần (component diagram)
Biểu đồ thành phần chỉ ra tập hợp các thành phần và các mối quan hệ của
chúng. Người ta sử dụng biểu đồ thành phần để minh hoạ sự Ihực thi tĩnh của hệ
thống. Các biểu đồ thành phần được liên kết với các biểu đổ lớp khi thành phần đó
ánh xạ đến một hoặc nhiều lớp. giao diện hay các sự hợp tác. Thành phần
(component) có chứa thông tin về lớp logic mà nó cài đặt, và do vậy tạo ra một ánh
xạ từ logical view sang component view. Biểu đồ thành phần được đùng trong công
việc lập trình thực tế.
1.5.2.1.4 Biểu đồ triển khai (deployment diagram)
Biểu đồ triển khai chỉ ra tập hợp các nút và các mối quan hệ của chúng.
Người ta sử dụng các biểu đồ triển khai để minh hoạ phần triển khai tĩnh của kiến
trúc (chỉ ra các máy tính và các thiết bị thực tế và các liên kết của chúng với nhau).
Các biểu đồ triển khai được liên kết với biểu đổ thành phần khi mà nút đó bao gồm
một hoặc nhiều thành phần. Bên trong mỗi nút các thành phần Ihực hiện được và các
đối tượng được cấp phát để chỉ ra các đơn vị phần mềm nào thực hiện ở những nút
nào.
1.5.2.2 Các biểu đồ cư xử hay biểu đồ động (behavioral diagrams)

Nãm loại biểu đồ cư xử do UML cung cấp được sử dụng để hình dung, xác
định, xây dựng và làm tài liệu về các khía cạnh động của hệ thống. Ta có thể coi các
khía cạnh động của hệ thống thê hiện cho các phần có thể thay đổi đó là luồng các
thông báo và sự di chuyển vật lý của các thành phần trong mạng. Trong đó biểu đồ
use-case thiết lập các cư xử của hệ thống, biểu đồ trình tự tập trung vào trình tự thời
gian của các thông báo, biểu đổ hợp tác tập trung vào tổ chức về mặt cấu trúc của
- 12-
các đối tượng truyền nhận thông báo, biểu đồ trạng thái tập trung vào sự thay đổi
trạng thái của hệ thống tác động bởi các sự kiện còn biểu đổ hoạt động tập trung vào
mô tả các sự cư xử có nhiều tiến trình song song.
1.5.2.2.1 Biêu đồ Use-case (Use-case diagram) (xem [4])
Biếu đổ Use-case chi ra 1 số Actor và mối nối của chúng với các trường hợp
sử dụng (Use-case) mà hệ thống cung cấp. Nó mô tả về mặt chức năng mà hệ thống
cung cấp, được mô tả bằng lời hoặc bằng biểu đồ Ưse-case. Đồng thời nó định nghĩa
các yêu cầu chức năng cuả hệ thống. Các Actor ngoài không nhất thiết phải là con
người mà có thể là các hình vẽ trong ban thân Ưse-casc diagram. Actor ngoài cũng
có thổ là một hệ thống ngoài cần lấv thông tin từ hệ thống hiện thời.
Biểu đồ Use-case là một công cụ cần thiết trong việc nắm bắt các yêu cầu,
lên kế hoạch và kiểm soát dự án lặp lại.
1.5.2.2.2 Biểu đồ trình tự (sequence diagram)
Biểu đồ trình tự chỉ ra sự hợp tác động giữa một số đối tượng. Tầm quan
trọng của biểu đồ này là chỉ ra trình tự các thông báo được gửi đi giữa các đôí tượng,
chỉ ra lương tác giữa các đối lượng.
1.5.2.2.3 Biểu đổ trạng thái (state diagram)
Biểu đồ trạng thái chỉ ra tất cả các trạng thái có thể có mà các đối tượng của
lớp có thể nhận được và những biến cố nào gây nên việc thay đổi trạng thái. Một
biến cố có thê là một thông báo do đối lượng khác truyền đến hoặc là một điều kiện
nào đó đã được hoàn thành. Việc thay đổi trạng thái được gọi là một phép chuyển.
Một chuyển cũng có thể có một hành động được nối với nó để xác định ra cái gì cần
được thực hiện sau. Loại biểu đồ nàv không được vẽ cho tất cả các lớp mà chỉ vẽ cho

những lớp có 1 số trạng thái đã được xác định rõ và hành vi của lớp ấy bị ảnh hưởng,
bị thay đổi bởi các trạng thái khác nhau.
1.5.2.2.4 Biểu đó hoạt động (activity diagram)
Biểu đổ hoạt động chi’ ra luồng tuần tự các hoạt động, về cơ bản được dùng
để mô tả cho các hoạt động được thực hiện trong một thao tác nhưng nó cũng có thể
Á
- 13-
dưực dùng để mô tả cho các luồng hoạt động khác như Use-case hay interact. Biểu
đồ nàv bao gồm các trạng thái hành động, có chứa một đặc tả về hoạt động cần được
thực hiện. Một Irạng thái hành động sẽ từ bỏ trạng thái dó khi hành động được thực
hiện xong. Các quvết định và các điều kiện cũng như việc thực hiện song song các
trạng thái hành động cũng có thể được biểu thị trong biểu đồ này. Nó kết hợp các ý
tưởng từ rriột vài kỹ thuật như biểu đồ sự kiện (event diagram) của Jim Odell, kỹ
thuật mô hình trạng thái SDL, workflow modeling và mạng Petri. Các biểu đồ này
đặc biệt hữu dụng khi kết hợp với workflow và trong việc mô tả sự cư xử mà sự cư
xử đó có nhiều tiến trình song song. Biểu đồ hành động là một biến thể của biểu đồ
trạng thái trong trường hợp các trạng thái là các trạng thái hành động.
1.5.2.2.5 Biểu đổ hợp tác (collaboration diagram)
Biểu đồ hợp tác chỉ ra sự hợp tác động, nó giống như biểu đồ trình tự nhưng
Ihường là sự lựa chọn để biểu thị sự hợp tác hoặc như một biểu đồ tuần tự. Nó là một
cách khác đê thể hiện một tình huống có thể xảy ra trong hệ thống nhưng tập trung
vào việc thê hiện việc trao đổi qua lại các thông báo giữa các đối tượng chứ không
quan tâm đến thứ tự của các thông báo đó. Qua biểu đổ này ta sẽ nhanh chóng biết
được giữa 2 đối tượng cụ thê nào đó có trao đổi những thông báo gì cho nhau.
1.5.3 Các view
View chí ra các mặt khác nhau của hệ thống như đã được mô hình. View
không phái là đổ thị nhưng nó là một đôí tượng trừu tượng bao gồm một số các biểu
đổ. Chỉ bàng việc định nghĩa một số các view, mỗi cái chỉ ra 1 khía cạnh đặc biệt
của hệ thống, ta có một bức tranh hoàn chỉnh về hệ thống cần xây dựng. View gắn
các ngôn ngữ mô tả với các phương pháp, các tiến trình. UML có 5 loại view là Use-

case view, logical view, component view, concurrency view và deployment view.
- 14-
Hình 1.4
1.5.3.1 Use-case view
Use-case view chỉ ra chức năng của hệ thống như được Actor ngoài cảm nhận
thấy. Nó không chỉ ra cách cấu trúc của hệ thống mà dùng là cơ sở đê' làm hợp lệnh
kiểm chứng cuối cùng để xem hệ thống có đáp ứng được yêu cầu đề ra hay không.
Người dùng thông qua view này để kiểm tra xem các yêu cầu của mình có được đáp
ứng đầy đủ không, có cần thay đổi gì trong các chức năng của hệ thống hay không?
Thông thường view này được dành cho khách hàng, người thiết kế, lập trình và kiểm
thử. Biểu đồ dùng cho view này là biểu đổ Use Case.
1.5.3.2 Logical view
Logical view mô tả cách mà chức năng của hệ thống được cung cấp. Nó xác
định cả tính bền vững và tính tương tranh cũng như các giao diện và cấu trúc bên
trong lớp. Ngược với Use-case view, logical view xem xét bên trong hệ thống. Nó
mỏ tả cách thức, chức năng được thiết kế bên trong hệ thống dưới dạng cấu trúc tĩnh
- 15-
(các lớp, các đối tượng và các mối quan hệ) và các sự hợp tác động xuất hiện khi các
đối tượng gửi thông báo cho nhau để cung cấp các chức năng đã được đưa ra. Cấu
trúc tĩnh được mô tả trong các biểu đồ lớp và đối tượng. Mô hình động được mô tả
trong các biểu đồ trạng thái (state diagram), biểu dồ tuần tự (sequence diagram),
hiểu đổ hợp tác (collaboration diagram), biêu đồ hoạt động (activity diagram). View
này chủ vếu dùng cho người thiết kế và ngưưì phát triến.
1.5.3.3 Component view
Component view chi ra việc tổ chức các thành phần của chương trình. Nó mô
lá các modul cài đặt và sự phụ thuộc lẫn nhau cho các modul đó, bao gồm biểu đồ
thành phần (component diagram). View này chủ yếu dùng cho người phát triển. Các
thông tin thêm về sự quản trị như các báo cáo về sự tiến bộ của công việc cũng có
thể được thêm vào.
1.5.3.4 Concurrency view

Concurrency view chỉ ra tính chất tương tranh trong hệ thống đề cập đến các
vấn đề liên quan đến truyền thông và đồng bộ hoá thường có ở trong các hệ thống
tương tranh. Nó chia các hệ thống tương tranh thành các tiến trình và các bộ xử lý,
cho phép người ta sử dụng tài nguyên một cách hiệu quả, thực hiện song song và
giải quyết các vấn đề không đổng bộ. Giải quyết việc truyền thông và đồng bộ hoá
giữa các mạch. View này dành cho người phát triển và người thiết lập hệ thống.
View này bao gồm các biểu đổ động (dynamic diagram) như biểu đồ trạng thái
(state diagram), biểu đồ trình tự (sequence diagram), biểu đồ hợp tác (collaboration
diagram), biểu đồ hoạt động (activity diagram) và các biểu đổ thực thi
(implementation diagram) như biểu đồ thành phần (component diagram) và biểu đồ
triển khai (deployment diagram).
1.5.3.5 Deployment view
Deployment view chỉ ra việc triển khai hộ thống trong một kiến trúc vật lý có
dùng máy tính và các thiết bị (các nút). Nói cách khác là nó mô tả việc triển khai vật
lý của hệ thống. View này dành cho người phát triển, tích hợp và kiểm thử.
- 16-
1,5.4 Các cơ chê chung của UML
Các cơ chế chung đưa ra các lời chú thích phụ, các thông tin, các ngữ nghĩa
cho các phần tử mô hình, đưa ra các cơ chế mở rộng UML cho từng tổ chức, cho
từng chương trình riêng.
1.5.4.1 Chú thích
Dù cho mức độ bao quát của một ngôn ngữ có cao đến đâu thì cũng có những
thứ chưa được định nghĩa trong ngôn ngữ đó. Để có thể đưa thêm thông tin vào mô
hình mà nếu không thì không thể thể hiện được hết mọi điều, ƯML cung cấp khả
nâng chú thích. Một chú thích có thể được đặt bất cứ chỗ nào trong biểu đồ và có thể
chứa bất kỳ loại thông tin nào. Loại thông tin mà nó chứa là một chuỗi không được
thông dịch bởi UML. Chú thích được gắn vào một vài phần tử trong biểu đổ vói
đường không liền nét chỉ ra phần tử nào được giải thích thêm hay chi tiết hoá với
thông tin trên chú thích. Một chú thích thường chứa các dẫn giải hay các câu hỏi từ
người làm mô hình như là một trình nhấc để giải quyết các tình trạng khó xử trong

thời gian sau. Một chú thích có thể có các khuôn mẫu (stereotype) mô tả kiểu chú
thích. Một chú thích biểu diễn một lời chú giải không có ảnh hướng về ngữ nghĩa,
nghĩa là nội dung của nó không làm thay đổi nghĩa của mô hình mà nó gắn vào.
Điều này giải thích tại sao các chú thích thường được sử dụng để đặc tả các thứ như
các yêu cầu, các nhận xét và các sự giải thích và các ràng buộc. ([6])
Một chú thích có thể chứa bất kỳ sự phối hợp văn bản hay đồ thị nào. Ta có
thể đưa vào một URL, thậm chí liên kết hay nhúng vào một tài liệu khác. Theo cách
ta bạn có thê dùng UML để tổ chức tất cả các artifact bạn sẽ sinh ra hay dùng trong
khi phát triển.
Một chú thích là một biểu tượng đồ hoạ để diễn tả các ràng buộc hoặc các lời
chú giải gắn vào một hay một tập hợp các phần tử. Bằng biểu đồ, một chú thích được
biêu diễn như một hình chữ nhật với một nếp quân ở góc, cùng với chú giải bằng văn
bản hoặc đồ hoạ.
- 17-
1.5.4.2 Trang trí
Các trang trí đưa thêm ngữ nghĩa cho các phần tử mô hình. Các trang trí đồ
hoạ có thể được gắn vào các phần tử mô hình trong các biẻu đổ. Một ví dụ về trang
trí là kv thuật chia thực thê thành các loại. Khi một phần tử thể hiện một loại, tên nó
được hiển thị với kiểu chữ đậm, nhưng khi cũng phần tử đó thể hiện một thực thể
của loại đó Ihì tên nó được gạch dưới và có thể chỉ định cả tên của thực thế cũng như
tên của loại. Hình chữ nhật với tên chữ đậm thê hiện một lớp và tên gạch chân thê
hiện một đối tượng. Tương tự cho các nút, khi biểu tượng nút có thể là loại chữ đậm
như Printer hay một thực thể của loại nút như Huong’s HP LaserJet 4.
1.5.4.3 Các cơ chê mở rộng
Người ta không thê đưa hết mọi khái niệm vào trong một ngôn ngữ vì như thế
ngôn ngữ đó sẽ trở nên quá phức tạp, rối rắm. Thay vì việc định nghĩa tất cả các
phần tử, ƯML cung cấp một số phần tử cơ bản và các cơ chê để mở rộng các phần tử
sao cho phù hợp với mục đích của người sử dụng và yêu cầu của từng hệ thống.
UML đưa ra 3 cơ chế mở rộng đó là:
> Stereotype (khuôn mẫu): khuôn mẫu định nghĩa loại phần tử mô hình mới

dựa trôn các phần tử mô hình đã có. Vì thế, một khuôn mẫu giống như một
phần tử mô hình đã tồn tại cộng thêm một số ngữ nghĩa mở rộng mà không
được thê hiện trong các phần tử mô hình trước. Một khuôn mẫu của một phần
tử mỏ hình có thể được sử dụng trong cùng một tình huống mà phần tử mô
hình gốc được sử dụng. Khuôn mẫu dựa trên toàn bộ các loại phần tử mô
hình như lớp, các nút, các thành phần, các chú thích, các mối quan hệ như
quan hệ association, quan hệ generalization và quan hệ dependency. Một số
khuôn mẫu đã được định nghĩa trước trong UML và chúng được sử dụng để
sửa lại các phần tử mô hình đã có thay vì định nghĩa một cái mơí. Điều này
đảm bảo tính đơn giản của UML.
Một khuôn mẫu được mô tả bằng cách đặt tên chúng như là 1 chuỗi gần tên
của phần tử. Các dấu ngoặc góc được gọi là các guillemet. Một khuôn mẫu
có thể hiện đổ hoạ của riêng nó, chẳng hạn như một hình tượng nối tới nó.
V-yLy &Ị-
- 18-
> Tagged Value (giá trị the): mở rộng thuộc tính của các Ihành phần của UML,
I1Ó cho phép ta tạo thêm những thông tin mới về một phần tử. Ví dụ như khi
làm việc hợp tác để tạo ra một sản phẩm, ta muốn chi ra các phiên bản và tác
giả của một đối tượng nào đó. Điều này không được xây dựng sẩn trong
UML mà có thể thực hiện thông qua việc thêm vào một giá trị thẻ.
> Contraints (ràng buộc): một ràng buộc là một sự hạn chế trên một phần tử để
giới hạn cách sử dụng của phần tử hoặc ngữ nghĩa của phần tử đó.
- 19-
cHƯƠNG 2 PHẢN TÍCH, THIẾT KÊ HƯỚNG ĐÔÍ
TƯỢNG SỬ DỤNG UML
Trong chương I, luận vãn đã đề cập tới tầm quan trọng của việc lập mô hình
và tổng quan về UML, lịch sử phát triển và các thành phần cơ bản của UML.
Chương này ỉuận văn sẽ đề cập đến việc sử dụng UML khi phân tích, thiết kế hướng
đối tượng.
Cho đến nay, những người làm phần mềm vẫn quen với cách tiếp cận truyền

thống, đó là cách tiếp cận chức năng. Theo cách tiếp cận này ta chia hệ thống thành
một bộ các chức năng có tương tác với trạng thái hệ thống dùng chungcho các chức
năng đó. Các chức năng này có thể có các thông tin trạng thái cục bộ nhưng chỉ
dùng cho quá trình thực hiện chức năng đó. Ngoài ra các chức năng này chia sẻ với
nhau trạng thái hệ thống, trạng thái này tập trung và mọi chức năng đều có thể truy
cập được. Thiết kế hướng chức năng gắn các chi tiết của một thuật toán của chức
năng đó nhưng các thông tin trạng thái hệ thống là không bị che dấu. Điều này có
thể gây ra vấn đề khi một chức năng thay đổi trạng thái theo cách mà các chức năng
khác không ngờ tới. Việc thay đổi một chức năng và cách nó sử dụng trạng thái của
hệ thống có thể gây ra những tương tác bất ngờ đối với các chức năng khác. Do đó
cách tiếp cận này tốt nhất trong trường hợp khối lượng thông tin trạng thái hệ thống
là nhỏ nhất và thông tin dùng chung nhau là rõ ràng.
Hướng đối tượng là một cách tiếp cận khác với cách tiếp cận chức năng
truyền Ihống. Với cách tiếp cận hướng đối tượng, hệ thống được nhìn nhận như một
bộ các đối tượng. Hệ thống được phân tán, mỗi đối tượng có những trạng thái riêng
của nó. Mỗi đối tượng là một bộ các “thuộc tính” xác định trạng thái của đối tượng
đó và các phép toán thực hiện trên các thuộc tính đó. Các đối tượng liên lạc với nhau
bàng cách trao đổi các thông báo.
Một trong những thách thức đối với người làm phần mềm hiện nay là làm sao
để tạo ra được những hệ thống có khả năng thích nghi, giảm thiểu chi phí bảo hành,
sửa chữa hệ thống và đặc biệt là tăng khả năng sử dụng lại của các thành phần trong
hệ thống.
- 20-
Khái niệm hướng đối lượng ra đời đã giúp ta có cơ hội để giải quyết những
thách thức trên. Do các đối tưựng là các thực thê độc lập, các thav đổi trong thực
hiện một đối tượng hoặc thêm các dịch vụ sẽ không cần sự tham khảo cũng như
không làm ảnh hưởng tới các đối tượng khác trong hệ thống nên hệ thống sẽ trở nên
dẻ hao trì hơn. Cũng do tính độc lập của các đối tượng mà chúng tổ thành các thành
phần có thê dùng lại được. Các hệ thống khác có thể dùng lại các đối tượng đã được
thiết kế trong hệ thống trước. Và vì các đối tượng này đã được thử nghiệm trong hệ

thống cũ nên rất ít khi xảv ra các rủi ro về lỗi.
UML được xây dựng và phát triển bởi các chuvên gia hàng đầu trong lĩnh vực
hướng đối tượng, những người đã đề xuất ra những phương pháp phân tích thiết kế
hướng đối tượng được coi là điển hình nhất, như kỹ thuật phân tích Use case của
Ivar Jacobsson, biểu đồ chuyến trạng thái của Harel do đó nếu vận dụng UML một
cách hợp lý thì ta sẽ xây dựng được những hệ thống tốt.
Thông thường việc phân tích và thiết kế hệ thống được thực hiện theo các
bước sau:
> Phân tích yêu cầu: UML có các Ưse-case để thâu tóm yêu cầu của khách
hàng. Thông qua mô hình ưse-case, các Actor được mô hình cùng với các
chức năng mà nó đòi hỏi lừ hệ thống. Các Actor và các Use-case được mô
hình với các mối quan hệ và có sự kết hợp mang tính truyền thông với nhau
hav được chia theo mô hình phân cấp. Các Actor và các Use-case được mô tả
trong Use-case diagram. Mỗi Use-case được mô tả trong một văn bản và nó
đặc tả yêu cầu của khách hàng, những cái mà họ mong đợi ở hệ thống mà
khôns quan tâm đến việc các chức năng của hệ thống được thực hiện như thế
nào. Đây là một bước quan trọng quyết định sự thành công hay thất bại của
dự án. Bởi vì hệ thống chỉ được coi là thành công nếu nó đáp ứng đúng và
đầv đủ các yêu cầu của khách hàng.
> Phân tích: Pha phân tích liên quan đến các sự trừu tượng chính như các lớp
hay các đối tượng và các kỹ thuật thể hiện trong vùng chính (primary
domain). Các lớp mà mô hình đã được xác định cùng với các mối quan hệ
của chúng với nhau được mô tả trong class diagram. Sự hợp tác giữa các lớp
- 21-
được the hiện trong các Use-case cũng được mô tả thông qua bất kỳ mô hình
động nào trong UML. Trong pha phân tích chí có một số lớp được mô hình,
các lớp kỹ thuật xác định các chi tiết và các giải pháp trong hệ thống phần
mềm như các lớp cho giao diện người sử dụng, dữ liệu, truyền thông không
được đề cập đến.
> Thiết kế: Trong pha này, kết quả của pha phân tích được mở rộng thành giải

pháp kỹ thuật. Các lớp mới được thêm vào để cung cấp cơ sở hạ tầng kỹ thuật
như giao diện người sử dụng, kiểm soát dữ liệu để chứa các đối tượng trong
dữ liệu, truyền thông với các hệ thống khác, Kết quả của pha thiết kế được
đặc tả chi tiết trong pha xây dựng.
Việc phân tích thiết kế hướng đối tượng được hệ thống hóa như sau:
1 Phân tích Use case
1.1
Tim Actor
1.2
Tim Use case
1.3
Xây dựng biểu đổ Use case
2 Tim lóp
2.1
Lớp
2.2 Xác định quan hệ giữa các lớp
2.3
Gói
2.4 Xây dựng biểu đồ lớp
2.5 Xây dựng biểu đồ đối tượng
3 Phân tích sự tương tác giữa các đối tượng
3.1 Kịch bản
3.2
Xây dựng biểu đồ trình tự
3.3
Xây dựng biểu đồ hợp tác
4
Thêm vào các thuộc tính và các phương thức cho các lớp
5
Xác định ứng xử cuả đối tượng

5.1
Xây dựng biểu đổ trạng thái