Sử dụng hiệu quả ngôn ngữ đặc tả UML trong phát triển phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI
ĐẠI HỌC CÔNG NGHỆ



Trần Thịnh Phong




SỬ DỤNG HIỆU QUẢ NGÔN NGỮ ĐẶC TẢ UML
TRONG PHÁT TRIỂN PHẦN MỀM





LUẬN VĂN THẠC SĨ

Hà Nội - 2008

ĐẠI HỌC QUỐC GIA HÀ NỘI
ĐẠI HỌC CÔNG NGHỆ


Trần Thịnh Phong


SỬ DỤNG HIỆU QUẢ NGÔN NGỮ ĐẶC TẢ UML
TRONG PHÁT TRIỂN PHẦN MỀM

Ngành: Công nghệ thông tin
Mã số: 1.01.10


LUẬN VĂN THẠC SĨ


NGƯỜI HƯỚNG DẪN KHOA HỌC







PGS.TSKH Nguyễn Xuân Huy

Hà Nội - 2008

Trang 1
Mục lục
Mở đầu 6
Chương 1: Tổng quan 7
1.1 Mô tả vấn đề 7
1.2 Mục tiêu 7
Chương 2: Ngôn ngữ mô hình hóa thống nhất UML 8
2.1 Khái quát 8
2.2 Các biểu đồ của UML 8
2.2.1 Use Case Diagram – Biểu đồ Use Case 8
2.2.2 Class Diagram – Biểu đồ Lớp 9
2.2.3 Statechart Diagram – Biểu đồ Trạng thái 10
2.2.4 Activity Diagram – Biểu đồ hoạt động 11
2.2.5 Sequence Diagram – Biểu đồ Tuần tự 12
2.2.6 Collaboration Diagram – Biểu đồ cộng tác 13
2.2.7 Component Diagram – Biểu đồ Thành phần 14
2.2.8 Deployment Diagram – Biểu đồ Triển khai 15
Chương 3: Phương pháp hướng đối tượng 17
3.1 Lập trình hƣớng cấu trúc 17
3.2 Cách tiếp cận hƣớng đối tƣợng 17
3.3 Phân tích và Thiết kế hƣớng đối tƣợng là gì 18
Chương 4: Quy trình phát triển phần mềm 19
4.1 Mô hình thác nƣớc 19
4.2 Mô hình xoắn ốc 20
4.3 Cơ cấu lặp, tăng dần – Iterative, Incremental Framework 22
4.3.1 Pha khởi đầu – Inception 22
4.3.2 Pha chuẩn bị - Elaboration 22

4.3.3 Pha xây dựng – Construction 22
4.3.4 Pha chuyển giao – Transition 23
4.3.5 Phân bổ thời gian của một dự án tiêu biểu 23
4.4 Microsoft Solution Framework 24
4.5 Rational Unified Process (RUP) 25
Chương 5: Áp dụng UML 29
5.1 Pha khởi đầu (Inception) 29
Trang 2
5.1.1 Khái quát 29
5.1.2 Các sản phẩm(Artifact) có thể bắt đầu trong pha khởi đầu 30
5.1.3 Tìm hiểu yêu cầu(Requirement) 30
5.1.4 Mô hình Use Case: Viết yêu cầu trong ngữ cảnh 31
5.2 Pha chuẩn bị - Vòng lặp 1 33
5.2.1 Mô hình Use Case: Vẽ các Sơ đồ tuần tự hệ thống 33
5.2.2 Mô hình Nghiệp vụ: Hình tƣợng hóa các Khái niệm 34
5.2.3 Mô hình Nghiệp vụ: Thêm các Liên kết 35
5.2.4 Mô hình Nghiệp vụ: Thêm các Thuộc tính 36
5.2.5 Các biểu đồ tƣơng tác 36
5.2.6 GRASP: Thiết kế các đối tƣợng cùng các Trách nhiệm 37
5.2.7 Mô hình Thiết kế: Hiện thực hóa Use Case với các khuôn mẫu GRASP 38
5.2.8 Mô hình Thiết kế: Xác định tính khả năng thấy đƣợc 39
5.2.9 Mô hình Thiết kế: Tạo ra các Biểu đồ Lớp Thiết kế 40
Chương 6: Áp dụng UML để phân tích thiết kế ứng dụng 41
6.1 PHÁT BIỂU BÀI TOÁN 41
6.2 SƠ ĐỒ TỔNG THỂ NGHIỆP VỤ BÀI TOÁN 43
6.3 SƠ ĐỒ USE CASE 44
6.3.1 Sơ đồ use case Main: 44
6.3.2 Sơ đồ use case Main 2: 45
6.4 CÁC TÁC NHÂN 46
6.4.1 Tác nhân – Cán bộ tiếp nhận 46

6.4.2 Tác nhân – Trƣởng phòng 46
6.4.3 Tác nhân – Cán bộ thụ lý 46
6.4.4 Tác nhân – Văn thƣ lƣu trữ 46
6.4.5 Tác nhân – Lãnh đạo 46
6.4.6 Tác nhân – Ngƣời quản trị 46
6.5 MÔ TẢ CHI TIẾT CÁC USE CASE 47
6.5.1 Use Case – Tiếp nhận hồ sơ 47
6.5.2 Use Case – Thụ lý 57
6.5.3 Use Case – Phê duyệt 68
6.5.4 Use Case – Trả hồ sơ thu lệ phí 73
6.5.5 Use Case – Quản lý sau cấp phép 77
Trang 3
6.5.6 Use Case – Lập báo cáo 83
6.5.7 Use Case – Tra cứu WEB 87
6.5.8 Use Case – Tiện ích hỗ trợ 89
6.5.9 Use Case – Quản trị hệ thống 98
6.5.10 Use Case – Quản lý các danh mục 103
Kết luận 113
Tài liệu tham khảo 114
Trang 4
Danh mục hình vẽ
Hình 2.1 Ví dụ về biểu đồ Use case 9
Hình 2.2 Ví dụ về biểu đồ lớp 10
Hình 2.3 Ví dụ về biểu đồ trạng thái 11
Hình 2.4 Ví dụ về biểu đồ hoạt động 12
Hình 2.5 Ví dụ về biểu đồ tuần tự 13
Hình 2.6 Ví dụ về biểu đồ cộng tác 14
Hình 2.7 Ví dụ về biểu đồ thành phần 15
Hình 2.8 Ví dụ về biểu đồ triển khai 16
Hình 4.1 Mô hình “Thác nƣớc” truyền thống 19

Hình 4.2 Nguy cơ và chi phí xử lý lỗi trong mô hình “Thác nƣớc” 20
Hình 4.2 Một quy trình “Xoắn ốc” 21
Hình 4.4 Bốn pha của “Cơ cấu lặp, tăng dần” 22
Hình 4.5 Pha “Xây dựng” bao gồm một chuỗi các “Thác nƣớc nhỏ” 23
Hình 4.6 Độ dài mỗi pha cho một dự án dài 2 năm 24
Hình 4.7 Mô hình quy trình MSF 24
Hình 4.8 Các pha và mốc thời gian của mô hình quy trình MSF 25
Hình 4.9 Các discipline trong RUP 27
Hình 4.10 Các Artifact(sản phẩm) và khung thời gian của RUP 28
Hình 5.1 Biểu đồ tuần tự hệ thống cho tình huống xử lý bán hàng 34
Hình 5.2 Một mô hình nghiệp vụ 35
Hình 5.3 Một mô hình nghiệp vụ với các liên kết 36
Hình 5.4 Biểu đồ cộng tác 37
Hình 5.5 Biểu đồ tuần tự 37
Hình 5.6 Biểu đồ tuần tự dùng hiện thực hóa Use Case 39
Hình 5.7 Minh họa khả năng nhìn thấy 40
Hình 5.8 Minh họa biểu đồ lớp thiết kế 40

Trang 5
Bảng thuật ngữ chuyên môn

Artifact
Sản phẩm trong quy trình RUP
Association
Liên kết
Business Modeling
Mô hình hóa tác nghiệp
Class Diagram
Biểu đồ lớp
Development Case

Một tập hợp các Artifact cho một quy trình phát triển dự án cụ
thể
Discipline
Kỷ luật
Domain Model
Mô hình nghiệp vụ
GRASP
Hình mẫu phần mềm gán trách nhiệm chung
Interaction Diagram
Biểu đồ tƣơng tác
Problem Domain
Vùng nghiệp vụ
RUP
Rational Unified Process - Quy trình phần mềm hợp nhất
Scenario
Tình huống
SSD
Biểu đồ tuần tự hệ thống
UML
Ngôn ngữ mô hình hóa hợp nhất
Use Case
Trƣờng hợp sử dụng
Visibility
Khả năng thấy đƣợc
Trang 6
Mở đầu

Nền kinh tế đang phát triển với tốc độ ngày càng cao với một nhu cầu cạnh tranh và
giữ vững thị trƣờng ngày càng lớn. Trong thời đại thƣơng mại điện tử, kinh doanh điện
tử nhƣ hiện nay thì phát triển hệ thống theo kiểu truyền thống sẽ không còn thích hợp

nữa. Hệ thống giờ đây cần phải đƣợc phát triển trong “thời gian Internet”, nhu cầu với
các hệ thống có độ mềm dẻo cao cũng tăng lên, điều này đòi hỏi việc thay đổi hệ thống
phải đƣợc thực hiện rất nhanh.
Đây là lúc mà UML(Unified Modeling Language – Ngôn ngữ mô hình hóa thống nhất)
xuất hiện để giải quyết vấn đề. UML là hệ thống ký hiệu chuẩn công nghiệp để mô
hình hóa cho các hệ thống hƣớng đối tƣợng và là nền tảng cho khả năng phát triển
nhanh ứng dụng.
Tuy nhiên thực tế cho thấy khả năng sử dụng hiệu quả UML trong phát triển phần
mềm là còn rất hạn chế trong các công ty phần mềm ở Việt nam, luận văn này sẽ
nghiên cứu và trình bày cách thức sử dụng UML một cách hiệu quả trong các dự án
phần mềm.
Trang 7
Chương 1: Tổng quan
1.1 Mô tả vấn đề
Công cụ sản xuất phần mềm với sự trợ giúp của máy tính (CASE tool) là một công cụ
sử dụng máy tính để hỗ trợ quy trình phát triển phần mềm, nhờ đó tăng năng suất và
giảm thiểu khả năng thất bại của dự án. CASE tool có thể là một trình dịch (Compiler)
để tạo ra phần mềm từ mã nguồn. Một kiểu khác của CASE tool không tham gia trực
tiếp vào việc tạo ra sản phẩm phần mềm. Ví dụ nhƣ là các công cụ đánh giá và hoạch
định, để đánh giá chi phí của dự án phát triển phần mềm và giúp quản lý nguồn lực
cho dự án phát triển phần mềm.
Phƣơng pháp phát triển phần mềm đƣa ra các hạng mục cho quy trình phát triển phần
mềm. Một phƣơng pháp phát triển phần mềm có thể đƣợc hỗ trợ bởi một CASE tool.
Mục đích của một công cụ nhƣ vậy là bao phủ mọi thông tin mà có bất kỳ quan hệ nào
với sản phẩm phần mềm. Nó cung cấp khả năng quản lý tất cả từ yêu cầu cho đến cấu
trúc ứng dụng rồi các mô đun và thành phần của phần mềm cũng nhƣ quan hệ giữa
chúng. Mô hình này của sản phẩm phần mềm giúp ta hiểu đƣợc quan hệ giữa yêu cầu
và kiến trúc của ứng dụng vì thế nó rất hữu dụng khi có yêu cầu thay đổi sản phẩm.
Thông thƣờng các ký hiệu đồ họa đƣợc sử dụng để biểu diễn mô hình này, vì nó dễ
đọc hơn đối với mọi ngƣời. Trong quá khứ ngƣời ta đã sử dụng nhiều ngôn ngữ hình

tƣợng để biểu diễn một mô hình sản phẩm phần mềm. Hiện nay Ngôn ngữ Mô hình
hóa Hợp nhất (UML) là ngôn ngữ hình tƣợng chuẩn cho mục đích này. UML định
nghĩa làm thế nào để mô tả một đối tƣợng phần mềm trừu tƣợng. Có nghĩa là UML
độc lập với ngôn ngữ và môi trƣờng lập trình và nó có thể mô tả kiến trúc phần mềm
mà ta có thể triển khai trên mọi môi trƣờng phát triển.
Phát triển phần mềm dựa trên phƣơng pháp hƣớng đối tƣợng, có ƣu thế vƣợt trội so
với phƣơng pháp hƣớng cấu trúc, đã ra đời để đáp ứng các bài toán lớn và phức tạp.
Và UML là ngôn ngữ phù hợp nhất dành cho phân tích và thiết kế hƣớng đối tƣợng.
Việc áp dụng hiệu quả UML vào quá trình phát triển phần mềm sẽ đem lại lợi ích lớn
cho các dự án phần mềm. Để áp dụng hiệu quả UML chúng ta cần hiểu rõ về nó, cách
thức áp dụng nó và các công cụ hỗ trợ liên quan.

1.2 Mục tiêu
Đồ án có những mục tiêu sau:
 Nghiên cứu và trình bày vai trò của UML trong công nghệ phần mềm
 Nghiên cứu và trình bày các Quy trình phát triển phần mềm tiêu biểu
 Trình bày phƣơng pháp ứng dụng UML trong phân tích thiết kế
 Áp dụng UML trong phân tích thiết kế một ứng dụng hệ thông tin quản lý cụ
thể: “Chương trình quản lý cấp phép xây dựng”

Trang 8
Chương 2: Ngôn ngữ mô hình hóa thống nhất UML
2.1 Khái quát
UML là ngôn ngữ đồ họa dùng để hình tƣợng hóa, xác định và xây dựng các đối tƣợng
của một hệ thống phần mềm.
UML đã xuất hiện nhƣ là các ký hiệu sơ đồ chuẩn cho việc mô hình hóa hƣớng đối
tƣợng. Nó đƣợc tạo ra bởi Rational Software và đƣợc công bố nhƣ là một chuẩn năm
1997 bởi OMG, hiện tại nó đƣợc OMG duy trì và phát triển qua nhiều phiên bản,
phiên bản hiện tại mới nhất cho tới thời điểm này là phiên bản 2.0
UML là ngôn ngữ mô hình hóa đa mục đích(GPL) trái với các ngôn ngữ mô hình hóa

đặc thù lĩnh vực DSLs (Domain Specific Languages)
Cả UML và DSLs đều dựa trên nền tảng định nghĩa ngôn ngữ MOF, dựa trên MOF mà
các sơ đồ UML không chỉ đơn thuần là các hình vẽ, một công cụ mô hình hóa tƣơng
thích MOF sẽ tạo ra các sơ đồ dƣới dạng mà máy có thể đọc đƣợc, nhờ đó có thể sinh
ra các phần của mã chƣơng trình từ các sơ đồ này
2.2 Các biểu đồ của UML
UML 2.0 có tất cả 13 biểu đồ chia làm 3 loại: Có 6 biểu đồ là biểu đồ cấu trúc, 3 biểu
đồ hành vi và 4 biểu đồ tƣơng tác thể hiện trong sơ đồ khối dƣới đây

Sau đây chúng ta sẽ xem xét 7 biểu đồ chính của UML
2.2.1 Use Case Diagram – Biểu đồ Use Case
Khái niệm tác nhân: là những ngƣời, hệ thống khác ở bên ngoài phạm vi của hệ thống
mà có tƣơng tác với hệ thống.
Biểu đồ Use case bao gồm một tập hợp các Use case, các tác nhân và thể hiện mối
quan hệ tƣơng tác giữa tác nhân và Use case. Nó rất quan trọng trong việc tổ chức và
mô hình hóa hành vi của hệ thống
Trang 9
Một ví dụ về biểu đồ Use case trong hình 2.1. Trong biểu đồ này một tác nhân
Salesperson đƣợc gán cho một use case Place Order. Use case này bao gồm 3 use
cases Supply Customer Data, Order Product và Arrange Payment.
Supply Customer Data
Order Product
Arrange Payment
Salesperson
Place Order
<<include>>
<<include>>
<<include>>

Hình 2.1 Ví dụ về biểu đồ Use case

2.2.2 Class Diagram – Biểu đồ Lớp
Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống. Các lớp là đại diện cho
các “vật” đƣợc xử lý trong hệ thống. Các lớp có thể quan hệ với nhau trong nhiều dạng
thức: liên kết (associated - đƣợc nối kết 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ị). Tất cả các mối quan hệ đó đều đƣợc thể hiện trong biểu đồ lớp, đi kèm với cấu
trúc bên trong của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation).
Biểu đồ đƣợc coi là biểu đồ tĩnh theo phƣơng diện cấu trúc đƣợc miêu tả ở đây có hiệu
lực tại bất kỳ thời điểm nào trong toàn bộ vòng đời hệ thống.
Một hệ thống thƣờng sẽ có một loạt các biểu đồ lớp – chẳng phải bao giờ tất cả các
biểu đồ lớp này cũng đƣợc nhập vào một biểu đồ lớp tổng thể duy nhất – và một lớp có
thể tham gia vào nhiều biểu đồ lớp.
Một ví dụ về biểu đồ lớp ở trong hình 2.2.
Trang 10

Hình 2.2 Ví dụ về biểu đồ lớp
2.2.3 Statechart Diagram – Biểu đồ Trạng thái
Một biểu đồ trạng thái thƣờng là một sự bổ sung cho lời miêu tả một lớp. Nó 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 thái. Một sự kiện có thể xảy ra khi một đối tƣợng tự gửi thông
điệp đến cho nó - ví dụ nhƣ để thông báo rằng một khoảng thời gian đƣợc xác định đã
qua đi – hay là một số điều kiện nào đó đã đƣợc thỏa mãn. Một sự thay đổi trạng thái
đƣợc gọi là một sự chuyển đổi trạng thái (State Transition). Một chuyển đổi trạng thái
cũng có thể có một hành động liên quan, xác định điều gì phải đƣợc thực hiện khi sự
chuyển đổi trạng thái này diễn ra.
Biểu đồ trạng thái 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. Biểu đồ trạng thái cũng có thể đƣợc vẽ cho
hệ thống tổng thể.

Một ví dụ về biểu đồ trạng thái ở hình 2.3. Biểu đồ này chỉ ra trạng thái của một đơn
đặt hàng.
Trang 11
Checking
do/ check item
Dispatching
do/ initiate delivery
Waiting
Delivered
/ get first item
[ not all items checked ] / get next item
item received[ some items not in stock ]
[ all items checked and
some items not in stock ]
[ all items checked and
all items available ]
item received
[ all items available ]
delivered

Hình 2.3 Ví dụ về biểu đồ trạng thái
2.2.4 Activity Diagram – Biểu đồ hoạt động
Một biểu đồ hoạt động chỉ ra một trình tự lần lƣợt của các hoạt động (activity). 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. Biểu đồ hoạt
động bao gồm các trạng thái hành động, chứa đặc tả của một hoạt động cần phải đƣợc
thực hiện (một hành động - action). Một trạng thái hành động sẽ qua đi khi hành động
đƣợc thực hiện xong (khác với biểu đồ trạng thái: một trạng thái chỉ chuyển sang trạng
thái khác sau khi đã xảy ra một sự kiện rõ ràng !). 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.
Một ví dụ về biểu đồ hoạt động ở trong hình 2.4. Biểu đồ này biểu diễn hoạt động
chuẩn bị của một đồ uống.
Trang 12
Find
Beverage
Put Coffee in
Filter
Add Water to
Reservoir
Get Cups
Put Filter in
Machine
Turn on
Machine
Brew Coffee
Pour Coffee
Drink
Get Cans of
Cola
[ found coffee ]
/ coffeePot.turnOn
[ no coffee ]
[ found cola ]
[ no cola ]
light goes out

Hình 2.4 Ví dụ về biểu đồ hoạt động
2.2.5 Sequence Diagram – Biểu đồ Tuần tự
Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tƣợng. Khía cạnh
quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message) đƣợc gửi giữa
các đối tƣợng. Nó cũng chỉ ra trình tự tƣơng tác giữa các đối tƣợng, điều sẽ xảy ra tại
một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống. Các biểu đồ trình tự
chứa một loạt các đối tƣợng đƣợc biểu diễn bằng các đƣờng thẳng đứng. Trục thời
gian có hƣớng từ trên xuống dƣới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông
điệp giữa các đối tƣợng khi thời gian trôi qua. Các thông điệp đƣợc biểu diễn bằng các
đƣờng gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những
đƣờng thẳng đứng thể hiện đối tƣợng. Trục thời gian cùng những lời nhận xét khác
thƣờng sẽ đƣợc đƣa vào phần lề của biểu đồ.
Một ví dụ về biểu đồ tuần tự ở trong hình 2.5.
Trang 13
caller
exchange
receiver
1: lift receiver
2: dial tone
3: dial digit
4: route
6: ringing tone
5: phone rings
7: answer phone
8: stop ringing
9: stop tone

Hình 2.5 Ví dụ về biểu đồ tuần tự
2.2.6 Collaboration Diagram – Biểu đồ cộng tác
Một biểu đồ cộng tác chỉ ra một sự cộng tác động, cũng giống nhƣ một biểu đồ trình

tự. Thƣờng ngƣời ta sẽ chọn hoặc dùng biểu đồ trình tự hoặc dùng biểu đồ cộng tác.
Bên cạnh việc thể hiện sự trao đổi thông điệp (đƣợc gọi là tương tác), biểu đồ cộng tác
chỉ ra các đối tƣợng và quan hệ của chúng (nhiều khi đƣợc gọi là ngữ cảnh). Việc nê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 đồ trình tự; nếu ngữ cảnh là yếu tố quan trọng hơn, 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.
Biểu đồ cộng tác đƣợc vẽ theo dạng một biểu đồ đối tƣợng, nơi một loạt các đối tƣợng
đƣợc chỉ ra cùng với mối quan hệ giữa chúng với nhau (sử dụng những ký hiệu nhƣ
trong biểu đồ lớp/ biểu đồ đối tƣợng). Các mũi tên đƣợc vẽ giữa các đối tƣợng để chỉ
ra dòng chảy thông điệp giữa các đối tƣợng. Các thông điệp thƣờng đƣợc đính kèm
theo các nhãn (label), một trong những chức năng của nhãn là chỉ ra thứ tự mà các
thông điệp đƣợc gửi đi. Nó cũng có thể chỉ ra các điều kiện, chỉ ra những giá trị đƣợc
trả về, v.v Khi đã làm quen với cách viết nhãn, một nhà phát triển có thể đọc biểu đồ
cộng tác và tuân thủ theo dòng thực thi cũng nhƣ sự trao đổi thông điệp. Một biểu đồ
cộng tác cũng có thể chứa cả các đối tƣợng tích cực (active objects), hoạt động song
song với các đối tƣợng tích cực khác.
Trang 14
Một ví dụ về biểu đồ cộng tác ở trong hình 2.6. Biểu đồ này biểu diễn sự cộng tác khi
một đơn đặt hàng đƣợc thực hiện.
: Order Entry
Window
: Order
Macallan line :
Order Line
: Stock
Item
: Reorder Item
: Delivery

Item
5: needToReorder()
1: prepare()
2: prepare()
3: check()
4: [check = true] remove()
7: [check = true] new
6: new

Hình 2.6 Ví dụ về biểu đồ cộng tác
2.2.7 Component Diagram – Biểu đồ Thành phần
Một biểu đồ thành phần chỉ ra 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ƣ thế có nghĩa
là nó tạo ra một ánh xạ từ hƣớng nhìn logic vào hƣớng nhìn thành phần. Biểu đồ thành
phần cũng chỉ ra những sự phụ thuộc giữa các thành phần với nhau, trợ giúp cho công
việc phân tích hiệu ứng mà một thành phần đƣợc thay đổi sẽ gây ra đối với các thành
phần khác. Thành phần cũng có thể đƣợc miêu tả với bất kỳ loại giao diện nào mà
chúng bộc lộ, ví dụ nhƣ giao diện OLE/COM; và chúng có thể đƣợc nhóm góp lại với
nhau thành từng gói (package). Biểu đồ thành phần đƣợc sử dụng trong công việc lập
trình cụ thể
Trang 15

Hình 2.7 Ví dụ về biểu đồ thành phần

2.2.8 Deployment Diagram – Biểu đồ Triển khai
Biểu đồ triển khai chỉ ra kiến trúc vật lý của phần cứng cũng nhƣ phần mềm trong hệ
thống. Bạn có thể chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) đi
kèm sự nối kết giữa chúng với nhau, bạn cũng có thể chỉ ra loại của các mối nối kết

đó. Bên trong các nút mạng (node), các thành phần thực thi đƣợc cũng nhƣ các đối
tƣợng sẽ đƣợc xác định vị trí để chỉ ra những phần mềm nào sẽ đƣợc thực thi tại những
nút mạng nào. Bạn cũng có thể chỉ ra sự phụ thuộc giữa các thành phần.
Biểu đồ triển khai chỉ ra hƣớng nhìn triển khai, miêu tả kiến trúc vật lý thật sự của hệ
thống. Đây là một hƣớng nhìn rất xa lối miêu tả duy chức năng của hƣớng nhìn Use
case. Mặc dù vậy, trong một mô hình tốt, ngƣời ta có thể chỉ tất cả những con đƣờng
dẫn từ một nút mạng trong một kiến trúc vật lý cho tới những thành phần của nó, cho
tới lớp mà nó thực thi, cho tới những tƣơng tác mà các đối tƣợng của lớp này tham gia
để rồi cuối cùng, tiến tới một Use case. Rất nhiều hƣớng nhìn khác nhau của hệ thống
đƣợc sử dụng đồng thời để tạo ra một lời miêu tả thấu đáo đối với hệ thống trong sự
tổng thể của nó
Trang 16

Hình 2.8 Ví dụ về biểu đồ triển khai

Trang 17
Chương 3: Phương pháp hướng đối tượng
Trong phần này chúng ta sẽ xem xét khái niệm hƣớng đối tƣợng. UML đã đƣợc thiết
kế để hỗ trợ hƣớng đối tƣợng, và trƣớc khi đi sâu vào việc áp dụng UML sẽ hữu ích
khi chúng ta tìm hiểu các lợi ích mà hƣớng đối tƣợng đem lại cho phát triển phần
mềm.
3.1 Lập trình hướng cấu trúc
Trƣớc hết chúng ta hãy xem xét các hệ thống phần mềm đƣợc thiết kế nhƣ thế nào sử
dụng cách tiếp cận hƣớng cấu trúc (hay đôi khi còn gọi là hƣớng chức năng)
Trong lập trình hƣớng cấu trúc, phƣớng pháp chung là xem xét vấn đề, rồi sau đó thiết
kế một tập hợp các hàm thực thi các nhiệm vụ đƣợc yêu cầu. Nếu nhƣ các hàm này
quá lớn thì chúng đƣợc chia nhỏ tới khi đủ để có thể hiểu và điều khiển. Quá trình này
gọi là phân dã chức năng.
Vấn đề đối với cách tiếp cận này đó là nếu bài toán mà chúng ta đang giải quyết trở
nên quá phức tạp thì việc bảo trì phần mềm cũng trở nên vô cùng khó khăn.

3.2 Cách tiếp cận hướng đối tượng
Phƣơng pháp hƣớng đối tƣợng giảm thiểu ảnh hƣởng của vấn đề bằng cách đơn giản
đó là tổ hợp các chức năng và dữ liệu liên quan vào cùng một mô đun.
Có vài điểm đáng chú ý với hệ thống mới này nhƣ sau:
 Khi chƣơng trình chạy thì có thể tồn tại nhiều thực thể của cùng một mô đun.
Mỗi thực thể sẽ có giá trị dữ liệu của riêng nó và tất nhiên là chúng có những
cái tên khác nhau
 Mô đun thì có thể nói chuyện với các mô đun khác bằng cách gọi các hàm của
nhau.
Khái niệm đóng gói (Encapsulation): Các thực thể là chủ nhân của một mục dữ liệu thì
mới đƣợc phép sửa hay đọc nó. Khái niệm này gọi là đóng gói, nó làm cho cấu trúc
của hệ thống bền vững hơn và tránh đƣợc các nhƣợc điểm của hệ thống hƣớng cấu trúc
khi một thay đổi nhỏ tới thành viên dữ liệu sẽ dẫn tới sự thay đổi liên hoàn. Với khái
niệm đóng gói thì ảnh hƣởng của sự thay đổi dữ liệu đƣợc cô lập trong phạm vi một
mô đun mà thôi.
Một điểm yếu của Hƣớng đối tƣợng trong quá khứ đó là nó rất mạnh khi làm việc ở
mức lớp và đối tƣợng nhƣng lại rất tồi khi biểu diễn hành vi của toàn bộ hệ thống.
Phƣơng pháp tiếp cận hiện đại đƣợc hỗ trợ bởi UML đó là không quan tâm tới đối các
đối tƣợng và các lớp vào giai đoạn đầu của dự án, thay vào đó là tập trung vào việc hệ
thống phải làm đƣợc cái gì. Sau đó, khi dự án tiến triển thì các lớp dần dần đƣợc dây
dựng để thực hiện các chức năng hệ thống đƣợc yêu cầu.

Trang 18
3.3 Phân tích và Thiết kế hướng đối tượng là gì
Trong phân tích hƣớng đối tƣợng, ngƣời ta chú trọng vào việc tìm kiếm và mô tả các
đối tƣợng hoặc khái niệm trong problem domain(vùng vấn đề). Ví dụ trong trƣờng hợp
hệ thống thƣ viện có một số khái niệm bao gồm: Sách, Thƣ viện và Ngƣời mƣợn.
Trong thiết kế hƣớng đối tƣợng, ngƣời ta chú trọng vào việc định nghĩa các đối tƣợng
phần mềm và việc chúng cộng tác thế nào để đáp ứng các yêu cầu. Ví dụ trong hệ
thống thƣ viện thì Đối tƣợng phần mềm Sách có thể có thuộc tính Tiêu đề và thƣơng

thức getChapter().

Trang 19
Chương 4: Quy trình phát triển phần mềm
Khi phát triển UML các tác giả đã quyết định rõ ràng là phải loại bỏ mọi vấn đề liên
quan tới quy trình ra khỏi ngôn ngữ này, lý do là vì các quy trình thƣờng hay mâu
thuẫn, một quy trình có thể đúng với công ty A nhƣng sẽ là thảm họa với công ty B. Vì
vậy UML là một ngôn ngữ rộng và chung tạo khả năng để các khía cạnh chính của
phát triển phần mềm có thể đƣợc mô tả trên ”giấy”
Nói cách khác UML chỉ là đơn giản là một ngôn ngữ, một ký hiệu, một cú pháp và
quan trọng là nó không nói cho chúng ta phát triển phần mềm nhƣ thế nào.
Để học cách sử dụng UML một cách hiệu quả, chúng ta sẽ theo một quy trình đơn
giản, và cố gắng hiểu UML sẽ giúp đƣợc gì trong mỗi giai đoạn. Nhƣng trƣớc hết
chúng ta hãy xem xét ƣu nhƣợc vài quy trình phần mềm cơ bản.
4.1 Mô hình thác nước
Mô hình thác nƣớc quy định rằng mỗi giai đoạn phải đƣợc hoàn thành trƣớc khi giai
đoạn tiếp theo có thể bắt đầu

Hình 4.1 Mô hình “Thác nƣớc” truyền thống
Quy trình quá đơn giản và dễ quản lý này bắt đầu bị phá vỡ khi độ phức tạp và kích
thƣớc của dự án tăng lên. Các vấn đề chính bao gồm:
Trang 20
 Ngay cả các hệ thống lớn cũng phải đƣợc hiểu đầy đủ trƣớc khi có thể tiến tới
giai đoạn thiết kế. Độ phức tạp tăng lên và trở nên quá sức đối với các lập trình
viên
 Mạo hiểm tăng. Các vấn đề lớn thƣờng phát sinh ở giai đoạn sau của quá trình,
đặc biệt là lúc tích hợp hệ thống. Và chi phí để xử lý lỗi tăng hàm số mũ với
trục thời gian
 Với các dự án lớn thì mỗi pha sẽ trải qua các giai đoạn rất dài. Một pha kiểm
thử dài 2 năm không phải là phƣơng pháp để giữ nhân viên

Hình 4.2 Nguy cơ và chi phí xử lý lỗi trong mô hình “Thác nƣớc”

4.2 Mô hình xoắn ốc
Một phƣơng pháp tiếp cận khác đó là mô hình xoắn ốc. Trong cách tiếp cận này chúng
ta thực hiện dự án theo một loạt các chu kỳ ngắn, mỗi chu kỳ kết thúc với một phiên
bản phần mềm có thể thực hiện
Trang 21

Hình 4.3 Một quy trình “Xoắn ốc”

Ƣu điểm của phƣơng pháp này là:
 Đội phát triển có thể làm việc hết cả chu trình(Phân tích, thiết kế, lập trình và
kiểm thử) chứ không phải tiêu tốn cả năm trời chỉ cho một hoạt động
 Chúng ta nhận đƣợc phản hồi sớm của khách hàng một cách đều đặn, và có thể
phát hiện các vấn đề tiềm tàng trƣớc khi đi quá xa
 Loại bỏ nguy cơ. Các vòng lặp đặc biệt mạo hiểm có thể đƣợc phát triển trƣớc
 Quy mô và độ phức tạp của công việc có thể đƣợc phát hiện sớm hơn
 Những thay đổi trong công nghệ có thể đƣợc kết hợp dễ dàng hơn
 Các phiên bản phần mềm thƣờng xuyên sẽ cải thiện tinh thần làm việc
 Trạng thái của dự án có thể đƣợc xác định chính xác hơn
Nhƣợc điểm của quy trình xoắn ốc là:
 Quy trình thƣờng đƣợc gắn với “Rapid Application Development” (Phát triển
ứng dụng thần tốc) cái đƣợc nhiều ngƣời xem là hiến chƣơng của tin tặc
 Quy trình rất khó để quản lý. Trong khi mô hình thác nƣớc phù hợp với các kỹ
thuật quản lý dự án cổ điển nhƣ sơ đồ Gantt, thì quy trình xoắn ốc đỏi hỏi cách
tiếp cận khác
Để khắc phục các nhƣợc điểm của mô hình xoắn ốc, chúng ta hãy xem xét một cách
tiếp cận tƣơng tự nhƣng chính thống hơn, đó là Cơ cấu lặp tăng dần.

Trang 22
4.3 Cơ cấu lặp, tăng dần – Iterative, Incremental Framework
Cơ cấu lặp, tăng dần là một mở rộng logic đối với mô hình xoắn ốc. Cơ cấu này đƣợc
chia thành 4 pha chính: Inception(Khởi đầu), Elaboration(Chuẩn bị), Construction
(Xây dựng) và Transition(Chuyển giao). Các pha này đƣợc thực hiện tuần tự nhƣng
chúng ta không đƣợc lầm lẫn với các giai đoạn của mô hình thác nƣớc.

Hình 4.4 Bốn pha của “Cơ cấu lặp, tăng dần”
4.3.1 Pha khởi đầu – Inception
Pha khởi đầu đƣợc quan tâm vơi việc thiết lập phạm vi dự án và định nghĩa tầm nhìn
cho dự án. Với dự án nhỏ thì có thể chỉ là cuộc nói chuyện tại quán cà phê với sự cam
kết tiến hành, trong các dự án lớn hơn thì cần có một “Khởi đầu” kỹ lƣỡng hơn. Các
sản phẩm có thể của pha này bao gồm:
 Một tài liệu về tầm nhìn
 Một thăm dò ban đầu về các yêu cầu của khách hàng
 Một bảng chú giải thuật ngữ liên quan trong dự án
 Một bản phân tích đầu tƣ(Bao gồm tiêu chí thành công và một dự báo về tài
chính, tính toán hiệu quả đầu tƣ)
 Một phân tích ban đầu về rủi ro
 Một kế hoạch dự án
4.3.2 Pha chuẩn bị - Elaboration
Mục đích của pha này là phân tích vấn đề, phát triển tiếp kế hoạch dự án và loại trừ
các vùng rủi ro hơn của dự án. Đến cuối của pha Chuẩn bị chúng ta cần có hiểu biết
chung về toàn bộ dự án cho dù không cần thiết phải hiểu kỹ lƣỡng
Hai mô hình UML rất có giá trị trong giai đoạn này đó là mô hình Use case giúp chúng
ta hiểu yêu cầu khách hàng và Biểu đồ lớp để xem xét các khái niệm chính mà khách
hàng hiểu.
4.3.3 Pha xây dựng – Construction
Trong pha này chúng ta xây dựng sản phẩm giống nhƣ cách trong mô hình xoắn ốc,
bằng cách đi theo một chuỗi các chu kỳ lặp. Mỗi chu kỳ lặp là một mô hình thác nƣớc

đơn giản. Bằng cách giữ cho mỗi chu kỳ lặp càng ngắn càng tốt chúng ta sẽ tránh đƣợc
các nhƣợc điểm của mô hình thác nƣớc
Trang 23

Hình 4.5 Pha “Xây dựng” bao gồm một chuỗi các “Thác nƣớc nhỏ”

4.3.4 Pha chuyển giao – Transition
Pha cuối cùng đƣợc quan tâm với việc chuyển sản phẩm cuối cùng cho khách hàng.
Các hoạt động trong pha này bao gồm:
 Phiên bản bêta để kiểm thử bởi cộng đồng ngƣời dùng
 Kiểm thử nhà máy, hay chạy sản phẩm song song với hệ thống hiện tại mà sản
phẩm sẽ thay thế
 Chuyển đổi dữ liệu(Cải tạo cơ sở dữ liệu hiện tại sang định dạng mới)
 Đào tạo ngƣời sử dụng mới
 Marketing, phân phối và bán hàng
Pha chuyển giao không nên nhầm lẫn với pha kiểm thử truyền thống tại cuối kỳ của
mô hình thác nƣớc. Vào thời kỳ đầu của pha chuyển giao thì một sản phẩm chạy tốt,
đầy đủ và đã qua kiểm thử phải sẵn sàng cho ngƣời sử dụng.
4.3.5 Phân bổ thời gian của một dự án tiêu biểu
Mỗi trong bốn pha trên nên kéo dài bao lâu? Điều này hoàn toàn phụ thuộc vào từng
dự án, tuy nhiên có một hƣớng dẫn sơ bộ nhƣ sau: