ĐẠ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

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

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

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

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

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ể.

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


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

đó. 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.

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

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