(Luận văn thạc sĩ) 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 ths công nghệ thông tin 1 01 10

ĐẠ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 qt ........................................................................................................... 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:
5.1

Áp dụng UML ...................................................................................... 29

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 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 khn 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
Association
Business Modeling
Class Diagram
Development Case
Discipline
Domain Model

GRASP
Interaction Diagram
Problem Domain
RUP
Scenario
SSD
UML
Use Case
Visibility

Sản phẩm trong quy trình RUP
Liên kết
Mơ hình hóa tác nghiệp
Biểu đồ lớp
Một tập hợp các Artifact cho một quy trình phát triển dự án cụ
thể
Kỷ luật
Mơ hình nghiệp vụ
Hình mẫu phần mềm gán trách nhiệm chung
Biểu đồ tƣơng tác
Vùng nghiệp vụ
Rational Unified Process - Quy trình phần mềm hợp nhất
Tình huống
Biểu đồ tuần tự hệ thống
Ngơn ngữ mơ hình hóa hợp nhất
Trƣờng hợp sử dụng
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ó 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 q 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 qt
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 ngồ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.

Order Product

Supply Customer Data

Arrange Payment

<<include>>
<<include>>
<<include>>

Salesperson

Place Order

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
[ not all items checked ] / get next item

/ get first item

Checking

item received[ some items not in stock ]

[ all items checked and
some items not in stock ]

Waiting

do/ check item

[ all items checked and
all items available ]
Dispatching

item received
[ all items available ]

delivered

Delivered

do/ initiate delivery

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 đồ
ngồ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

[ no coffee ]

Find
Beverage
[ found coffee ]

Put Coffee in
Filter

[ found cola ]

Get Cups

Add Water to
Reservoir

[ no cola ]

Get Cans of
Cola

Put Filter in
Machine

/ coffeePot.turnOn
Turn on
Machine

Brew Coffee
light goes out

Pour Coffee

Drink

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

receiver

exchange

caller
1: lift receiver
2: dial tone
3: dial digit
4: route
6: ringing tone

5: phone rings
7: answer phone

9: stop tone

8: stop ringing

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
1: prepare()
: Order

5: needToReorder()
2: prepare()
3: check()
Macallan line :
Order Line

: Stock
Item

4: [check = true] remove()

7: [check = true] new

6: new

: Reorder Item

: Delivery
Item

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. Q 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 tố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 hồ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 q 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 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 tố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ề tồ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 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: