Công nghệ hướng đối tượng và ứng dụng phát triển hệ thống quản lý khách hàng trước và sau khi bán hàng của doanh nghiệp

1

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ






LÊ THỊ CHÂU




CÔNG NGHỆ HƯỚNG ĐỐI TƯỢNG
VÀ ỨNG DỤNG PHÁT TRIỂN HỆ THỐNG QUẢN
LÝ KHÁCH HÀNG TRƯỚC VÀ SAU KHI BÁN
HÀNG CỦA DOANH NGHIỆP







LUẬN VĂN THẠC SĨ

Hà Nội – 2010
3



MỤC LỤC
MỤC LỤC 1
DANH MỤC CÁC CHỮ VIẾT TẮT 6
PHẦN MỞ ĐẦU 7
Chương 1 – Cơ sở lý luận về công nghệ hướng đối tượng và ngôn ngữ mô hình hóa thống
nhất UML 9
1.1. Tổng quan về công nghệ hướng đối tượng và phương pháp mô hình hóa 9
1.2. Ngôn ngữ mô hình hóa thống nhất UML 12
1.2.1. Lịch sử phát triển của UML 12
1.2.2. UML là gì? 13
1.2.3. Mô hình khái niệm của UML 13
1.3. Quy trình phân tích thiết kế hệ thống hướng đối tượng 20
1.3.1. Xây dựng mô hình nghiệp vụ 20
1.3.2. Xác định yêu cầu 21
1.3.3. Phân tích 24
1.3.4. Thiết kế 27
1.3.5. Lập trình và kiểm tra chương trình 36
1.3.6. Vận hành và bảo trì hệ thống 36
Chương 2 – Khái quát về hệ thống quản lý quan hệ khách hàng CRM 37
2.1. Khách hàng quyết định sự thành bại của doanh nghiệp 37
2.1.1. Cạnh tranh bằng sự thân thiết với khách hàng 37
2.1.2. Vai trò của CRM trong giai đoạn khủng hoảng hiện nay 39
2.2. Cơ sở lý luận về quản lý quan hệ khách hàng CRM 40
2.2.1. Định nghĩa 40

2.2.2. Lịch sử học thuyết CRM 45
2.2.3. Lợi ích của CRM 45
2.2.4. Thực trạng triển khai CRM hiện nay 48
2.3. Quy trình tác nghiệp 49
2.3.1. Các chức năng chung 49
4

2.3.2. Các chức năng con của hệ thống CRM 50
2.3.3. Các hoạt động chính của hệ thống CRM 52
2.4. Các hoạt động nghiệp vụ của hệ thống CRM 55
2.4.1. Các quy trình tác nghiệp 55
2.4.2. Mô tả hoạt động nghiệp vụ giai đoạn trước bán hàng 59
2.4.3. Mô tả hoạt động nghiệp vụ giai đoạn bán hàng 63
2.4.4. Mô tả hoạt động nghiệp vụ giai đoạn sau bán hàng 64
Chương 3 – Đặc tả yêu cầu và các mô hình phân tích hệ thống CRM 65
3.1. Đặc tả yêu cầu 65
3.1.1. Giai đoạn trước bán hàng 65
3.1.2. Biểu đồ ca sử dụng giai đoạn bán hàng 83
3.1.3. Biểu đồ ca sử dụng giai đoạn sau bán hàng 87
3.2. Biểu đồ hoạt động 94
3.2.1. Giai đoạn trước bán hàng 94
3.2.2. Giai đoạn bán hàng 104
3.2.3. Giai đoạn sau bán hàng 106
3.3. Mô hình khái niệm và Biểu đồ tuần tự 107
3.3.1. Giai đoạn trước bán hàng 107
3.3.2. Giai đoạn bán hàng 113
3.3.3. Giai đoạn sau bán hàng 118
Chương 4 – Các mô hình thiết kế hệ thống CRM 119
4.1. Thiết kế chi tiết các biểu đồ lớp 119
4.1.1. Giai đoạn trước bán hàng 122

4.1.2. Giai đoạn bán hàng 123
4.1.3. Giai đoạn sau bán hàng 124
4.2. Thiết kế cơ sở dữ liệu vật lý 125
4.3. Thiết kế hệ thống phần mềm 141
4.3.1. Các nguyên tắc thiết kế 141
4.3.2. Mô hình dữ liệu 142
4.3.3. Mô hình hệ thống 143
Chương 5 – Thử nghiệm 144
5.1. Môi trường thử nghiệm 144
5.2. Cài đặt chương trình 144
5.3. Giao diện sử dụng 144
5

5.4. Đánh giá kết quả thử nghiệm 151
TỔNG KẾT 153
TÀI LIỆU THAM KHẢO 155

6

DANH MỤC CÁC CHỮ VIẾT TẮT

CRM
Customer Relationship Management - Quản lý Quan Hệ Khách Hàng
CSDL
Cơ sở dữ liệu
UML
Unified Modeling Language – Ngôn ngữ mô hình hóa thống nhất

7

PHẦN MỞ ĐẦU
Khi cạnh tranh không đơn thuần thông qua đầu tư trang thiết bị, sử dụng dây
truyền công nghệ hiện đại không còn là lợi thế riêng của một doanh nghiệp nào đó nữa
thì một yếu tố giúp các doanh nghiệp, đặc biệt là doanh nghiệp thuộc lĩnh vực dịch vụ, có
thể tạo cho mình lợi thế cạnh tranh không thay thế - đó là mỗi quan hệ lâu dài với khách
hàng.
Cũng như nhiều người tiêu dùng khác khi đi mua sắm, nếu bạn bước chân vào cửa
hàng mà được nhân viên tiếp đón nhiệt tình, nồng hậu thì bao giờ bạn cũng có tâm lý
thoải mái khi mua đồ và chắc chắn lần sau nếu có nhu cầu mua sắm bạn cũng sẽ quay lại.
Đó là tâm lý chung của người tiêu dùng và các cửa hàng nếu biết khai thác tốt điều đó sẽ
có thể thu được lợi nhuận to lớn từ những vị khách hàng trung thành này.
Đúc rút từ kinh nghiệm của những cửa hàng nhỏ lẻ, thì những công ty lớn cũng sẽ
cần có những khách hàng trung thành hay những khách hàng tiềm năng như vậy. Đặc biệt
trong xu hướng hiện nay, số lượng các công ty ngày càng nhiều trong khi lượng khách
hàng dường như không thay đổi tương xứng. Vì vậy, việc cạnh tranh giữa các doanh
nghiệp hay công ty là điều tất yếu và ngày càng quyết liệt tinh vi.
Trong thời buổi khủng hoảng hiện nay ảnh hưởng trực tiếp tới nền kinh tế toàn
cầu, không loại trừ những tập đoàn kinh tế lớn hay những doanh nghiệp tổ chức vừa và
nhỏ. Khủng hoảng dù tác động đến cả hai mặt nhưng tập trung chủ yếu vẫn là mặt thiệt
hại của nó. Không ít những công ty hay tập đoàn kinh tế đã chịu sự phá sản từ những tác
động của sự khủng hoảng này. Vậy làm thế nào để các doanh nghiệp hay tập đoàn kinh tế
còn lại có thể trụ vững và vượt qua được giai đoạn khó khăn hiện tại
Tất yếu công ty hay doanh nghiệp muốn tồn tại thì phải dựa vào khách hàng, càng
có nhiều khách hàng thì công ty hay doanh nghiệp càng có thể thành công lớn. Việc mở
rộng thị trường kinh doanh và tìm kiếm khách hàng là điều không thể lãng quên và phải

đặt lên làm nhiệm vụ hàng đầu. Có được khách hàng mới đã là khó khăn nhưng việc giữ
chân khách hàng để họ trở thành khách hàng tiềm năng, trung thành thì càng khó khăn
gấp bội. Điều đó đòi hỏi các doanh nghiệp hay công ty phải làm tốt các khâu ngay từ giai
đoạn marketing đến những dịch vụ sau bán hàng.
Doanh nghiệp muốn chăm sóc khách hàng tốt nhất trước hết phải nắm được những
thông tin cần thiết về khách hàng, về nhu cầu và thị hiếu của họ. Mô hình quản lý quan hệ
khách hàng CRM đã được ứng dụng phát triển mạnh mẽ và mang lại nhiều lợi ích hơn
cho người quản lý và cả doanh nghiệp nói chung.
8

Từ thực tiễn như vậy trong luận văn này đưa ra những nghiên cứu về CRM -
Customer Relationship Management (Quản lý quan hệ khách hàng) với mong muốn đưa
ra những cơ sở khoa học dựa trên công nghệ hướng đối tượng về việc quản lý quan hệ
khách hàng, đồng thời xây dựng được chương trình thử nghiệm cho những nghiên cứu lý
thuyết đạt được.
Cấu trúc của Luận văn gồm những nội dung chính như sau:
Mở đầu
Chương 1 – Cơ sở lý luận về công nghệ hướng đối tượng và ngôn ngữ mô hình hóa
thống nhất UML
Chương này trình bày những điểm khái quát hóa về phương pháp mô hình hóa,
công nghệ hướng đối tượng và ngôn ngữ mô hình hóa thống nhất trong việc xây dựng các
hệ thống tin học. Mô tả chi tiết quy trình phân tích thiết kế hướng đối tượng.
Chương 2 - Khái quát về hệ thống quản lý quan hệ khách hàng CRM
Chương này trình bày cơ sở lý thuyết về hệ thống quản lý quan hệ khách hàng
CRM của doanh nghiệp, đồng thời mô tả các hoạt động nghiệp vụ của hệ thống CRM
tổng quát và cho từng giai đoạn cụ thể.
Chương 3 – Đặc tả yêu cầu và các mô hình phân tích hệ thống CRM
Chương này tiến hành quá trình phân tích hệ thống CRM và sử dụng ngôn ngữ mô
hình hóa thống nhất để mô tả.
Chương 4 – Các mô hình thiết kế hệ thống CRM

Dựa trên những kết quả đã thu nhận được từ quá trình phân tích ở chương 3 để
tiến hành thiết kế hệ thống CRM ở chương 4.
Chương 5 – Thử nghiệm
Chương này trình bày một số kết quả thử nghiệm từ chương trình demo xây dựng
hệ thống CRM.
Kết luận

9

Chương 1 – Cơ sở lý luận về công nghệ hướng đối
tượng và ngôn ngữ mô hình hóa thống nhất UML
1.1. Tổng quan về công nghệ hướng đối tượng và phương
pháp mô hình hóa
Ngày nay, trong công nghệ phần mềm nói chung và phần mềm công nghiệp nói
riêng, công nghệ hướng đối tượng đóng vai trò then chốt. Công nghệ hướng đối tượng
không những đã cách mạng hóa phương pháp phân tích thiết kế xây dựng phần mềm, mà
còn đổi mới cả tư duy của những người sử dụng. Từ khóa “hướng đối tượng” đang trở
thành từ mốt, được sử dụng rất phổ biến trong các tiêu đề quảng cáo sản phẩm phần
mềm, từ các công cụ lập trình, phần mềm soạn thảo văn bản, xử lý đồ họa tới các hệ
thống quản lý cơ sở dữ liệu. Vậy, thực chất công nghệ hướng đối tượng là gì?
Mô hình hóa hướng đối tượng
Bất cứ thế giới thực nào cũng đều phức tạp dù đó là thế giới tự nhiên hay thế giới
do con người tạo ra. Vậy cách thức con người tiếp cận, tìm hiểu, làm chủ thế giới của
mình cũng như việc giao tiếp với nhau thế nào… Tất nhiên, con người thường thông qua
các mô hình, dù đó chỉ là những phương trình toán học, các định luật vật lý, những hình
ảnh hay thậm chí là lời nói và chữ viết. Mô hình là một ánh xạ của thế giới thực, mô tả và
phản ánh thế giới thực từ một góc nhìn. Mô hình đơn giản hơn thế giới thực rất nhiều, nó
chỉ mang những thông tin cần thiết cho một mục đích sử dụng cụ thể. Chính vì thế mà
thông qua mô hình chúng ta có thể tìm hiểu, bàn luận về vấn đề cần giải quyết, cũng như
thiết kế và kiểm chứng giải pháp trước khi tiến hành thực thi. Có thể nói, tư duy trên cơ

sở mô hình là phương pháp không thể thiếu được của mỗi người làm khoa học, kỹ thuật.
Đương nhiên, công nghệ phần mềm cũng không thể thiếu vai trò của các phương pháp
mô hình hóa.
Việc mô hình hóa hệ thống phần mềm nhằm mục đích sau: Trừu tượng hóa, đơn
giản hóa vấn đề cần giải quyết; Tạo ra phương tiện giao tiếp thống nhất trong nhóm phát
triển; Tạo ra phương tiện giao tiếp thuận tiện giữa nhóm phát triển và khách hàng; Tạo ra
cơ sở phân tích, thiết kế và kiểm chứng hệ thống; Tư liệu hóa phần mềm.
Mô hình của hệ thống có thể là một bản mô tả cách thức hoạt động, một số công
thức toán học, một hoặc vài sơ đồ mô tả thành phần và các hoạt động diễn ra trong hệ
thống. Việc sử dụng mô hình loại nào để nghiên cứu hệ thống phụ thuộc vào mức độ trừu
10

tượng hóa được chọn lựa, phụ thuộc vào quan điểm phân tích và phụ thuộc vào công cụ
sử dụng. Các mô hình vừa là công cụ nghiên cứu và tìm hiểu hệ thống, vừa là công cụ,
ngôn ngữ để trao đổi và là công cụ để điều chỉnh, hoàn thiện hệ thống.
Việc trừu tượng hóa thế giới tự nhiên thành các lớp đối tượng được gọi là mô hình
hóa hướng đối tượng.
Trong thế giới luôn biến động của các ứng dụng hướng đối tượng thì việc phát
triển và bảo trì các ứng dụng có chất lượng cao trong một khoảng thời gian hợp lý ngày
càng trở nên khó khăn hơn. 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 có chất lượng, thỏa mãn tốt những yêu cầu của khách hàng.
Mô hình hóa được đánh giá là phần trung tâm trong mọi công việc, các hoạt động để dẫn
tới việc có được một phần mềm tốt. Thông qua mô hình có thể dùng để trao đổi, bàn bạc
về cấu trúc và ứng xử mong muốn của hệ thống. Đồng thời qua mô hình để trực quan hóa
và kiểm soát kiến trúc hệ thống. Mặt khác việc sử dụ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 mô tả các hành vi ứng xử, tập trung
vào những mặt động của hệ thống.
Việc xây dựng mô hình không chỉ dành riêng cho các hệ thống lớn, mà nó mang
lại nhiều lợi ích cho tất cả các hệ thống khác nhau. Nhìn chung, khi xây dựng mô hình sẽ
đạt được những mục đích sau:

 Mô hình giúp trực quan hóa hệ thống như theo cách nó vốn có hay là theo cách mà
chúng ta muốn nó sẽ như vậy.
 Mô hình chỉ rõ các cấu trúc và ứng xử của hệ thống.
 Mô hình giúp chúng ta có được một khuôn mẫu để hướng dẫn chúng ta trong suốt
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.
Thông qua mô hình hóa, chúng ta thu hẹp bài toán mà chúng ta cần nghiên cứu
bằng cách chỉ tập trung vào một khía cạnh tại một thời điểm. Tùy thuộc vào đặc điểm tự
nhiên của hệ thống, mỗi mô hình có thể tập trung vào những mặt khác nhau của hệ thống
đó. Chẳng hạn, hệ thống tập trung vào dữ liệu thì các mô hình về phần thiết kế tĩnh của
hệ thống được chú ý hơn. Nhưng nếu hệ thống giao diện người dùng thì phần tĩnh và
phần động của các ca sử dụng sẽ là quan trọng. Đối với hệ thống thời gian thực, các tiến
trình động là quan trọng. Và cuối cùng, trong hệ thống phân tán dựa trên cơ sở Web thì
các mô hình về thực thi và triển khai là quan trọng nhất.
11

Phân tích, thiết kế hướng đối tượng
Công nghệ phần mềm không chỉ là lập trình, mà còn nhiều bước khác nữa như
phân tích, thiết kế và bảo trì. Theo dòng phát triển công nghệ phần mềm, phương pháp
lập trình đã tiến hóa từ lập trình tuần tự lên lập trình có cấu trúc và lập trình hướng đối
tượng. Phương pháp phân tích, thiết kế phần mềm cũng đi theo các bước tiến hóa này.
Phương pháp phân tích, thiết kế phần mềm tiên tiến hiện nay là hướng đối tượng, trong
đó khối cơ bản để xây dựng nên phần mềm là đối tượng hay lớp. Nói một cách đơn giản,
đối tượng là sự phản ánh thế giới tự nhiên xung quanh. Ưu điềm lớn nhất của phân tích,
thiết kế phần mền hướng đối tượng không phải nằm ở chỗ tạo ra chương trình nhanh tốn
ít công sức, mà nằm ở chỗ nó gần với thực tế và do đó thúc đẩy việc tái sử dụng lại
những thành quả đã được xây dựng trước đó.
Lập trình hướng đối tượng
Với đa số người quan tâm thì khái niệm hướng đối tượng chỉ mới dừng lại là một

phương pháp lập trình ở mức trừu tượng cao hơn lập trình hướng cấu trúc. Rõ ràng, xu
hướng phát triển của các ngôn ngữ lập trình là hướng dần tới tư duy người lập trình và
thoát khỏi sự lệ thuộc vào máy tính cụ thể. Điều đó có nghĩa là, người lập trình có thể
biểu diễn thế giới thực và ý tưởng của mình thông qua ngôn ngữ lập trình một cách tự
nhiên hơn, trực tiếp hơn là phụ thuộc vào từng câu lệnh, thanh ghi hay ô nhớ theo cách
thức làm việc của vi xử lý. Dù lập trình hướng cấu trúc khiến cho việc lập trình trở nên dễ
dàng hơn, hiệu quả hơn nên mã chương trình có độ tin cậy cao hơn và tính khả chuyển
cao hơn. Tuy nhiên, lập trình hướng cấu trúc vẫn gặp nhiều khó khăn với các dự án lớn
bởi tư duy còn gắn nhiều với cấu trúc dữ liệu cụ thể, tính mềm dẻo và khả năng sử dụng
lại tương đối thấp của mô hình phân tích, thiết kế cũng như mã chương trình. Trong khi
đó, yêu cầu của thị trường ngày càng khắt khe cả về mở rộng phạm vi chức năng, tính
thân thiện người sử dụng, độ tin cậy của phần mềm cũng như khung thời gian ra sản
phẩm.
Lập trình hướng đối tượng được coi là phương pháp lập trình chuẩn hiện nay trong
đa số các lĩnh vực ứng dụng bởi nó có nhiều ưu điểm lớn so với các phương pháp cổ
điển. Mục tiêu mà lập trình hướng đối tượng đặt ra: Đơn giản hóa việc sử dụng các thư
viện, cho phép sử dụng lại phần mềm một cách triệt để, nâng cao độ tin cậy và tính bền
vững của phần mềm, hỗ trợ các dự án phát triển phần mềm có quy mô lớn đòi hỏi nhiều
người tham gia, cải thiện khả năng bảo trì của mã nâng tính mềm dẻo linh hoạt của phần
mềm.
12

Như vậy, công nghệ hướng đối tượng là tất cả công nghệ và kỹ thuật phần mềm
dựa trên nền tảng là phương pháp luận hướng đối tượng. Nền tảng này bao gồm: mô
hình hóa hướng đối tượng, phân tích và thiết kế hướng đối tượng, lập trình hướng đối
tượng. Dựa trên mô hình đối tượng thu được khi mô hình hóa hệ thống, phương pháp
phân tích thiết kế phần mềm hướng đối tượng sẽ bổ sung thêm các liên kết và lớp đối
tượng mới, tinh chỉnh lại… để rạo ra mô hình đối tượng chi tiết của phần mềm. Cuối
cùng người sử dụng một ngôn ngữ lập trình nào đó (không nhất thiết phải mà ngôn ngữ
hướng đối tượng) thể hiện mô hình đối tượng chi tiết thành mã nguồn.

1.2. Ngôn ngữ mô hình hóa thống nhất UML
1.2.1. Lịch sử phát triển của UML
Đầu những năm 1980, ngành công nghệ phần mềm chỉ có duy nhất một ngôn ngữ
hướng đối tượng là Simula. Sang nửa sau thập niên 80, các ngôn ngữ hướng đối tượng
như Smaltalk và C++ xuất hiện. Cùng với chúng, nhu cầu mô hình hóa các hệ thống phần
mềm theo hướng đối tượng đã nảy sinh. Vào khoảng đầu thập niên 90, một số ngôn ngữ
mô hình hóa xuất hiện và được nhiều người sử dụng như: Grady Booch’s Mooch
Modeling Methodology, James Rambaugh’s Object Modeling Technique – OMT,…
Mỗi phương pháp và ngôn ngữ trên đều có hệ thống ký hiệu riêng, phương pháp
xử lý và công cụ hỗ trợ khác nhau nên đều có những điểm mạnh và yếu riêng. Từ đó
khiến nảy ra cuộc tranh luận phương pháp nào là tốt nhất. Trong thực tế, sự khác biệt
giữa các phương pháp đó hầu như không đáng kể. Hơn nữa, việc ký hiệu khác nhau của
các phương pháp đã gây ra sự mập mờ, nhầm lẫn khi mà chỉ một ký hiệu có thể mang
những ý nghĩa khác nhau trong mỗi phương pháp. Thời kỳ này còn được biết đến với tên
gọi cuộc chiến giữa các phương pháp. Tuy nhiên theo tiến trình thời gian, tất cả những
phương pháp này đã tiệm cận lại và bổ sung lẫn nhau. Trong bối cảnh trên, người ta nhận
thấy cần thiết phải cung câp một phương pháp mô hình hóa chuẩn và thống nhất cho việc
mô hình hóa hướng đối tượng.
Nhận thấy được sự bất hợp lý này, hai nhà lý luận tiên phong là James Rumbaugh
(với ngôn ngữ OMT) và Gray Booch (với ngôn ngữ Booch’94) đã kết hợp cùng công ty
Rational Rose để tìm cách đưa ra một phương pháp mô hình hóa thống nhất mang tên
UM (Unified Method). Song chỉ một thời gian ngắn sau hai vị đã kịp nhận ra rằng khó có
thể thống nhất một phương pháp, mà chỉ có thể thống nhất một ngôn ngữ mô hình hóa.
Cái tên ngôn ngữ mô hình hóa thống nhẩt UML (Unified Modeling Language) ra đời từ
13

đó. Đó là do sự hợp nhất các cách ký hiệu của Booch, OMT và Objectory cũng như
những ý tưởng tốt nhất của một số phương pháp khác.
Bằng cách hợp nhất các ký hiệu sử dụng trong phân tích, thiết kế của các phương
pháp đó, UML cung cấp một nền tảng chuẩn trong việc phân tích thiết kế. Có nghĩa là các

nhà phát triển vẫn có thể tiến hành theo phương pháp mà họ đang sử dụng hoặc có thể
tiến hành theo một phương pháp tổng hợp hơn do thêm vào những bước ưu điểm của
từng phương pháp. Cùng với sự cộng tác sau này của Ivar Jacobson (nổi tiếng với use
case) và nhiều đồng nghiệp khác, UML đã trở thành một chuẩn quốc tế được quản lý bởi
tổ chức OMG (Object Management Group) và đang trong tiến trình trở thành một chuẩn
ISO.
1.2.2. UML là gì?
Unified Modeling Language (viết tắt là UML) là một ngôn ngữ dùng để:
Trực quan hóa
Cụ thể hóa
Sinh mã ở dạng nguyên mẫu
Lập và cung cấp tài liệu [2]
1.2.3. Mô hình khái niệm của UML
Để hiểu rõ hơn về UML ta phải hình dung được mô hình khái niệm của ngôn ngữ.
Nó đòi hỏi nắm được ba vấn đề chính như sau:
Các phần tử cơ bản để xây dựng mô hình
Quy tắc liên kết các phần tử mô hình
Một số cơ chế chung sử dụng cho ngôn ngữ
Khi nắm được những vấn đề này thì ta có thể đọc được mô hình UML và tạo ra
một số mô hình cơ bản. Để hình thành mô hình UML gồm ba khối như sau: phần tử, quan
hệ và biểu đồ. Phần tử là trừu tượng căn bản trong mô hình; các quan hệ gắn kết những
phần tử này lại với nhau còn biểu đồ nhóm tập hợp các phần tử [1].
14

1.2.3.1. Phần tử mô hình trong UML
Trong UML có bốn loại phần tử mô hình, đó là phần tử cấu trúc, phần tử hành vi,
phần tử nhóm và phần tử chú thích. Các phần tử này là các khối để xây dựng hướng đối
tượng cơ bản của UML.
a. Phần tử cấu trúc
Phần tử cấu trúc là các danh từ trong mô hình UML. Chúng là bộ phận tĩnh của

mô hình, dùng để biểu diễn các thành phần khái niệm hay vật lý. Bao gồm:
Lớp (Class)
Lớp là tập hợp các đối tượng (object) có cùng một tập thuộc tính, các thao tác, các
mối quan hệ và ngữ nghĩa với các đối tượng khác.
Giao diện (Interface)
Giao diện là tập hợp các thao tác (operation) tạo nên dịch vụ của mộ lớp hoặc một
thành phần.
Phần tử cộng tác (Collaboration)
Phần tử cộng tác mô tả ngữ cảnh của tương tác. Nó thể hiện một giải pháp thi hành
bên trong hệ thống, bao gồm các lớp, quan hệ và tương tác giữa chúng để đạt được
chức năng mong đợi của Use case.
Ca sử dụng (use case)
Ca sử dụng là mô tả một tập hợp của nhiều hành động tuần tự mà hệ thống thực
hiện để đạt được một kết quả có thể quan sát được đối với một tác nhân (actor) cụ
thể nào đó. Tác nhân là những gì bên ngoài tương tác với hệ thống. Ca sử dụng mô
tả tương tác giữa tác nhân và hệ thống đang xây dựng, nó thể hiện chức năng mà
hệ thống sẽ cung cấp cho tác nhân. Tập hợp các ca sử dụng của hệ thống sẽ tạo
nên tất cả các trường hợp mà hệ thống có thể sử dụng được. Nó được hiện thực
hóa bởi phần tử cộng tác như vừa mô tả trên.
Lớp tích cực (Active class)
Lớp tích cực là lớp mà các đối tượng của nó thực hiện các hoạt động điều khiển,
có đối tượng làm chủ một hay nhiều tiến trình (process) hay luồng (thread). Lớp
tích cực cũng giống như lớp thông thường ngoại trừ việc các đối tượng của nó thể
15

hiện các thành phần có hành vi đang tương tranh hay có thể thực hiện đồng thời
với các thành phần khác. Lớp này thường dùng để biểu diến tiến trình (process) và
luồng (thread).
Thành phần (Component)
Thành phần là biểu diễn vật lý của mã nguồn. Trong hệ thống ta sẽ thấy các kiểu

khác nhau của thành phần như các thành phần COM+ hay JavaBeans cũng như
các thành phần như các file mã nguồn, các file nhị phân tạo ra trong quá trình phát
triển hệ thống.
Nút (Nodes)
Nút là thể hiện thành phần vật lý, tồn tại khi chương trình chạy và biểu diễn các tài
nguyên tính toán. Nó có thể là máy tính hay các thiết bị phần cứng. Có thể đặt tập
các thành phần trên nút và chuyển từ nút này sang nút khác.
b. Phần tử hành vi
Các phần tử thể hiện hành vi là bộ phận động của mô hình UML. Chúng là các
động từ trong mô hình, biểu diễn các hành vi theo thời gian và không gian. Có hai loại
chính là tương tác (Interaction) và máy trạng thái (States machine).
Tương tác (Interaction)
Tương tác là hành vi bao gồm tập các thông điệp (message) trao đổi giữa các đối
tượng trong một ngữ cảnh cụ thể để thực hiện một mục đích cụ thể. Hành vi của
nhóm đối tượng hay của mỗi thao tác có thể được chỉ ra bằng tương tác.
Máy trạng thái (States machine)
Máy trạng thái là hành vi chỉ ra trật tự các trạng thái mà đối tượng hay tương tác
sẽ đi qua để đáp ứng sự kiện. Hành vi của lớp hay cộng tác của lớp có thể được
xác định bằng máy trạng thái. Máy trạng thái kích hoạt nhiều phần tử, bao gồm
trạng thái, chuyển tiếp từ trạng thái này sang trạng thái khác, sự kiện và các hoạt
động đáp ứng sự kiện. Ký pháp đồ họa của nó bao gồm tên và trạng thái con nếu
có.
c. Phần tử nhóm
16

Phần tử nhóm là bộ phận tổ chức của mô hình UML. Chỉ có một phần tử thuộc
nhóm này là gói (Package).
Gói (Package)
Gói là cơ chế đa năng dùng để tổ chức các phần tử có một ý nghĩa chung nào đó
vào thành nhóm.

d. Phần tử chú thích (Annotational)
Phần tử chú thích là bộ phận chú giải của mô hình UML.
1.2.3.2. Các quan hệ trong UML
Có bốn loại quan hệ trong UML, bao gồm quan hệ phụ thuộc, kết hợp, khái quát
hóa và hiện thực hóa. Chúng là các khối cơ sở để xây dựng mọi mối quan hệ trong UML.
a. Quan hệ Phụ thuộc (Dependency)
Quan hệ phụ thuộc là quan hệ ngữ nghĩa giữa hai phần tử trong đó thay đổi phần
tử độc lập sẽ tác động ảnh hưởng tới phần tử phụ thuộc.
b. Quan hệ Kết hợp (Association)
Kết hợp là quan hệ cấu trúc chỉ ra mối liên kết giữa hai lớp, trong đó mỗi liên kết
là kết nối giữa các đối tượng. Hay nói một cách đơn giản, khi một đối tượng của lớp này
gửi thông điệp tới hoặc nhận thông điệp từ một đối tượng của lớp kia thì ta nói giữa hai
lớp có mối quan hệ kết hợp.
Quan hệ Tập hợp (Aggregation)
Quan hệ tập hợp là dạng đặc biệt của quan hệ kết hợp, nó biểu diễn quan hệ cấu
trúc giữa toàn thể và bộ phận.
Quan hệ Hợp thành (Composition)
Quan hệ hợp thành là một dạng đặc biệt của quan hệ Tập hợp (Aggregation).
Trong đó, nếu như đối tượng toàn thể bị hủy bỏ thì các đối tượng bộ phận cũng bị
hủy bỏ theo.
Quan hệ Khái quát hóa (Generalization)
17

Khái quát hóa là mối quan hệ tổng quát hóa, cụ thể hóa mà trong đó đối tượng cụ
thể sẽ kế thừa các thuộc tính và hành vi của đối tượng tổng quát hóa.
Quan hệ hiện thực hóa (Realization)
Hiện thực hóa là quan hệ ngữ nghĩa giữa giao diện (interface) và lớp (class) hay
thành phần (component) hiện thực lớp, giữa use case và phần tử cộng tác
(collaboration) hiện thực use case đó.
1.2.3.3. Các biểu đồ trong UML

Biểu đồ là biểu diễn đồ họa tập các phần tử mô hình. Vẽ biểu đồ để biểu diễn hệ
thống đang xây dựng dưới những góc độ quan sát khác nhau. Có thể hiểu biểu đồ chính là
ánh xạ của hệ thống. Một phần tử có thể xuất hiện trong một hay nhiều biểu đồ. Về lý
thuyết thì biểu đồ có thể bao gồm tổ hợp vô số phần tử đồ họa và quan hệ vừa mô tả ở
trên. UML cho khả năng xây dựng một số kiểu biểu đồ trực quan để biểu diễn các khía
cạnh khác nhau của hệ thống [1].
a. Biểu đồ ca sử dụng (Use case diagram)
Biểu đồ này chỉ ra tương tác giữa các ca sử dụng (use case) và các tác nhân
(actor). Ca sử dụng (use case) biểu diễn các chức năng của hệ thống, trong khi, tác nhân
là con người hay hệ thống khác cung cấp hay thu nhận thông tin từ hệ thống đang được
xây dựng. Biểu đồ ca sử dụng tập trung vào quan sát trạng thái tĩnh của các ca sử dụng
trong hệ thống. Nó đặc biệt quan trọng trong việc tổ chức và mô hình hóa hệ thống.Vì ca
sử dụng biểu diễn yêu cầu hệ thống từ góc độ người dùng, cho nên ca sử dụng là chức
năng mà hệ thống phải có. Biểu đồ này chỉ ra tác nhân nào khởi động ca sử dụng nào và
khi nào tác nhân nhận thông tin từ hệ thống.
Biểu đồ ca sử dụng chỉ ra chức năng tổng thể của hệ thống đang xây dựng. Thông
qua biểu đồ này, khách hàng, quản trị dự án, phân tích viên, lập trình viên, kỹ sư kiểm tra
chất lượng và những ai quan tâm tổng thể đến hệ thống đều có thể biết được hệ thống sẽ
hỗ trợ gì thông qua biểu đồ này.
b. Biểu đồ trình tự (Sequence diagram)
Biểu đồ trình tự là một dạng biểu đồ tương tác (interaction), trong đó chỉ ra luồng
chức năng xuyên qua các ca sử dụng (use case), nó biểu diễn sự tương tác giữa các đối
tượng và tập trung vào mô tả trật tự thông điệp theo thời gian. Nó mô tả các đối tượng
18

liên quan trong một tình huống cụ thể và các bước tuần tự trong việc trao đổi các thông
điệp giữa các đối tượng đó để thực hiện một chức năng cụ thể nào đó.
Biểu đồ trình tự có ích cho mọi người tham gia dự án. Khách hàng có thể thấy
được tiến trình tác nghiệp cụ thể của họ; phân tích viên thấy được luồng tiến trình, người
phát triển thấy được các đối tượng cần xây dựng và các thao tác cho các đối tượng này;

kỹ sư kiểm tra chất lượng hệ thống có thể thấy chi tiết của tiến trình để xây dựng quy
trình thử nghiệm…
c. Biểu đồ cộng tác (Collaboration diagram)
Biểu đồ cộng tác chỉ ra các thông tin như biểu đồ trình 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 nó tập trung vào việc thể hiện
việc trao đổi qua lại các thông điệp giữa các đối tượng chứ không quan tâm đến thứ tự
của các thông điệp đó. Điều đó có nghĩa rằng qua biểu đồ cộng tác chúng ta biểu được
nhanh chóng giữa hai đối tượng cụ thể nào đó có trao đổi những thông điệp gì với nhau.
Biểu đồ cộng tác và biểu đồ trình tự thuộc loại biểu đồ tương tác và chúng có thể biến đổi
qua lại với nhau. Trong biểu đồ cộng tác, đối tượng đặt trong chữ nhật và tác nhân là
người hình cây như trong biểu đồ trình tự, các đối tượng giao tiếp trực tiếp với nhau được
thể hiện bằng đường gạch nối.
Tuy rằng biểu đồ cộng tác cũng chỉ ra các thông tin như biểu đồ trình tự, nhưng
biểu đồ cộng tác được sử dụng vì mục đích khác. Thông qua biểu đồ này, kỹ sư kiểm tra
chất lượn và kiến trúc sư hệ thống thấy được việc phân bổ tiến trình giữa các đối tượng.
Chẳng hạn, nếu biểu đồ cộng tác có hình dạng phức tạp như ngôi sao, với nhiều đối
tượng giao tiếp với đối tượng trung tâm thì kiến trúc sư có thể kết luận rằng hệ thống quá
phụ thuộc vào một đối tượng và họ sẽ đi thiết kế lại phân bổ tiến trình để nâng cao hiệu
suất hệ thống.
d. Biểu đồ lớp (Class diagram)
Biểu đồ lớp chỉ ra tương tác giữa các lớp trong hệ thống, bao gồm một tập hợp các
lớp, các giao diện, các thành phần cộng tác và mối quan hệ giữa chúng. Các lớp được
xem như kế hoạch chi tiết của các đối tượng. Người phát triển sử dụng biểu đồ lớp để xây
dựng các lớp. Các công cụ phần mềm phát sinh mã trình xương sống cho các lớp, sau đó
người phát triển phải chi tiết hóa bằng ngôn ngữ lập trình. Kiến trúc sư quan sát thiết kế
hệ thống thông qua biểu đồ lớp. Nếu trên biểu đồ thấy một lớp chứa quá nhiều chức năng
thì phải chia chúng ra nhiều lớp khác nhau. Kiến trúc sư cũng dễ phát hiện ra nếu giữa
các lớp thiếu giao tiếp.
19

e. Biểu đồ chuyển trạng thái (State transition)
Biểu đồ trạng thái mô tả vòng đời của đối tượng, từ khi nó được sinh ra cho đến
khi bị phá hủy, nó chỉ ra một máy chuyển trạng thái bao gồm các trạng thái, các bước
chuyển trạng thái và các hoạt động. Biểu đồ chuyển trạng thái cung cấp cách thức mô
hình hóa các trạng thái khác nhau của đối tượng. Trong khi biểu đồ lớp cung cấp bức
tranh tĩnh về các lớp và quan hệ của chúng thì biểu đồ chuyển trạng thái đươc sử dụng để
mô hình hóa các hành vi động của hệ thống. Biểu đồ chuyển trạng thái đặc biệt quan
trọng trong việc mô hình hóa hành vi của một lớp giao diện (interface class) hay thành
phần cộng tác (collaboration) và nó nhấn mạnh vào các đáp ứng theo sự kiện của một đối
tượng, điều này rất hữu ích khi mô hình hóa một hệ thống phản ứng (reactive). Thông
thường, không tạo lập biểu đồ chuyển trạng thái cho mọi lớp mà chỉ sử dụng cho các lớp
phức tạp. Nếu đối tượng của lớp tồn tại trong nhiều trạng thái và có ứng xử khác nhau
trong mỗi trạng thái thì nên xây dựng biểu đồ chuyển trạng thái cho chúng. Nhiều dự án
không quan tâm đến loại biểu đồ này, thường nó dùng cho việc làm tài liệu.
f. Biểu đồ hoạt động (Activity)
Biểu đồ hoạt động là một dạng đặc biệt của biểu đồ chuyển trạng thái. Nó chỉ ra
luồng đi từ hoạt động này sang hoạt động khác trong hệ thống. Nó đặc biệt quan trọng
trong việc xây dựng mô hình chức năng của hệ thống và nhấn mạnh tới việc chuyển đổi
quyền kiểm soát giữa các đối tượng.
g. Biểu đồ thành phần (Component)
Biểu đồ thành phần cho ta cái nhìn vật lý của mô hình, chỉ ra cách tổ chức và sự
phụ thuộc của các thành phần (component). Biểu đồ thành phần cho thấy các thành phần
phần mềm trong hệ thống và quan hệ giữa chúng. Nó liên quan tới biểu đồ lớp, trong đó
một thành phần thường ánh xạ tới một hay nhiều lớp, giao diện và thành phần cộng tác.
Biểu đồ lớp thích hợp cho những ai quan tâm đến việc dịch chương trình. Nó cho thấy
trình tự dịch của các modun trong hệ thống. Đồng thời nó cũng cho biết rõ thành phần
nào được tạo ra trong quá trình chạy chương trình.
h. Biểu đồ triển khai (Deployment)
Biểu đồ triển khai chỉ ra cấu hình hệ thống khi thực thi, những bố trí vật lý của hệ
thống mạng và các thành phần thiết bị khác. Thông qua biểu đồ triển khai mà người quản

lý dự án, người sử dụng, kiến trúc sư và đội ngũ triển khai hiểu phân bổ vật lý của hệ
thống và các hệ thống con sẽ được đặt ở đâu.
20

1.3. Quy trình phân tích thiết kế hệ thống hướng đối tượng
1.3.1. Xây dựng mô hình nghiệp vụ
Việc đi tới nắm bắt rành mạch, rõ ràng về hệ thống cần tin học hóa cần xuất phát
từ việc tìm hiểu và nghiên cứu về hệ thống thực. Công việc tìm hiểu này được tiến hành
bằng cách tìm hiểu hoạt động nghiệp vụ và xây dựng các mô hình miền và mô hình
nghiệp vụ để nắm bắt được toàn bộ các vấn đề liên quan đến nghiệp vụ của hệ thống.
Việc tìm hiểu quy trình nghiệp vụ của hệ thống được tiến hành qua các bước sau:
Tìm hiểu bối cảnh hệ thống
Nắm bắt những yêu cầu bổ sung, các yêu cầu phi chức năng
a. Tìm hiểu bối cảnh hệ thống
Mô tả bối cảnh hệ thống bằng cách xây dựng mô hình miền và mô hình nghiệp vụ
của nó. Tùy theo yêu cầu của từng loại bài toán cụ thể mà ta có thể xây dựng mô hình
miền, mô hình nghiệp vụ đầy đủ hay cả hai mô hình trên, có đôi khi lại không cần mô
hình nào cả.
Xây dựng mô hình miền (domain model)
Mục đích của mô hình hóa miền là để hiểu và mô tả các lớp quan trọng nhất
trong bối cảnh của miền. Có thể lập một từ điển giải thích để định nghĩa các lớp
miền. Thông qua từ điển giải thích và mô hình miền giúp khách hàng và những
người phát triển hệ thống chia sẻ những thuật ngữ và khái niệm chung. Đối với
những miền nghiệp vụ nhỏ thì có thể chỉ sử dụng từ điển thuật ngữ là đủ mà không
cần xây dựng mô hình miền. Mô hình miền có thể mô tả bằng nhiều biểu đồ lớp
của UML.
Xây dựng mô hình nghiệp vụ
Một mô hình nghiệp vụ có thể được phát triển qua hai bước: Thứ nhất, Xây
dựng mô hình ca sử dụng nghiệp vụ bao gồm việc xác định các tác nhân nghiệp vụ
và các ca sử dụng mà các tác nhân sử dụng. Thông qua mô hình này người phát

triển hiểu rõ hơn về giá trị mà nghiệp vụ đem lại cho các tác nhân sử dụng nó. Thứ
hai, Phát triển một mô hình đối tượng nghiệp vụ bao gồm những người tham gia
nghiệp vụ, các thực thể nghiệp vụ và các đơn vị công việc cùng nhau thực hiện các
21

ca sử dụng nghiệp vụ. Các quy tắc nghiệp vụ và các điều chỉnh khác trong nghiệp
vụ được liên kết với các đối tượng khác.
b. Nắm bắt những yêu cầu bổ sung
Các yêu cầu bổ sung là những yêu cầu phi chức năng mà không thể liên kết với bất
kỳ ca sử dụng nghiệp vụ cụ thể nào. Chúng có thể ảnh hưởng đồng thời đến nhiều ca sử
dụng nhưng cũng có thể không ảnh hưởng đến bất kỳ ca sử dụng nào. Chẳng hạn, các
giao diện, các yêu cầu thiết kế vật lý và kiến trúc, các rang buộc về thiết kế và cài đặt…
1.3.2. Xác định yêu cầu
Từ những yêu cầu của khách hàng, chúng ta xác định được mục tiêu của hệ thống
cần thực hiện. Thường đó là các yêu cầu chức năng về những gì mà hệ thống phải thực
hiện, nhưng chưa cần chỉ ra các chức năng đó thực hiện như thế nào. Việc xác định đúng
và đầy đủ yêu cầu bài toán là nhiệm vự hết sức quan trọng, nó làm cơ sở cho tất cả các
bước tiếp theo trong dự án phát triển phần mềm. Muốn vậy, thì phải thực hiện đặc tả chi
tiết các yêu cầu của hệ thống. UML cung cấp biểu đồ ca sử dụng để đặc tả các yêu cầu
của hệ thống [1].
Các bước trong luồng công việc xác định yêu cầu được mô tả chi tiết như sau:
1.3.2.1. Tìm các tác nhân và các ca sử dụng
Việc xác định các tác nhân và các ca sử dụng gồm bốn bước:
Tìm các tác nhân
Tác nhân thể hiện cho những phần ngoài của hệ thống mà tương tác với hệ
thống. Tác nhân có thể là các kiểu người dùng hay các hệ thống ngoài. Mỗi tác
nhân đóng vai trò nào đó đối với mỗi ca sử dụng mà nó tương tác. Mỗi khi một
người dùng hay hệ thống ngoài có sự tương tác với hệ thống, thể hiện của tác nhân
tương ứng sẽ đóng một vai trò mà tác nhân thực hiện.
Tìm các ca sử dụng

Mỗi cách thức mà tác nhân sử dụng hệ thống được gọi là một ca sử dụng.
Có thể coi một ca sử dụng đặc tả một chuỗi các hành động, kể cả một chuỗi các
hành động thay thế mà hệ thống có thể thực hiện khi tương tác với tác nhân của
nó. Một thể hiện ca sử dụng là sự thực hiện hoặc xử lý của ca sử dụng đó.
Mô tả ngắn gọn mỗi ca sủ dụng
22

Sau khi tìm được các ca sử dụng, trước hết mô tả ngắn gọn để tóm tắt các
hành động của ca sử dụng. Sau này sẽ mô tả chi tiết dần.
Mô tả mô hình ca sử dụng tổng thể
Một mô hình ca sử dụng là một mô hình của hệ thống, bao gồm các tác
nhân, các ca sử dụng và các mối quan hệ giữa chúng. Chúng ta sử dụng các biểu
đồ và các mô tả để biểu diễn mô hình ca sử dụng tổng thể, đặc biết là các ca sử
dụng có liên quan đến nhau. Các ca sử dụng trong mô hình ca sử dụng có thể được
tổ chức thành các cụm ca sử dụng được gọi là các gói ca sử dụng. Kết quả của
bước này là một mô tả tổng quan về mô hình ca sử dụng. Nó mô tả các tác nhân và
các ca sử dụng tương tác với nhau như thế nào, các ca sử dụng liên kết với nhau
như thế nào.
Các bước mô tả trên đây không bắt buộc phải thực hiện theo thứ tự mà thường
được thực hiện đồng thời. Kết quả của hoạt động này là một phiên bản của mô hình ca sử
dụng với các tác nhân và các ca sử dụng.
1.3.2.2. Sắp xếp thứ tự ưu tiên các ca sử dụng
Mục đích của hoạt động này là nhằm lập thứ tự ưu tiên các ca sử dụng để quyết
định những ca sử dụng nào cần được triển khai ngay trong những lần lặp đầu và chúng
đòng vai trò gì trong kiến trúc hệ thống.
1.3.2.3. Mô tả chi tiết một ca sử dụng
Mục đích chính của việc mô tả chi tiết ca sử dụng là mô tả luồng các sự kiện của
ca sử dụng một cách chi tiết, xuất phát điểm từ khi khởi động, tương tác với các tác nhân
thế nào đến khi kết thúc. Để mô tả chi tiết ca sử dụng có thể mô tả bằng văn bản, bằng
bảng hay các biểu đồ ca sử dụng kèm theo. Với chú ý rằng, những tương tác trong luồng

sự kiện ở đây chỉ mô tả hoạt động bề ngoài của hệ thống mà một tác nhân có thể nhận
biết được từ hệ thống, còn việc làm thế nào để hệ thống đáp ứng lại các tương tác đó cho
đến lúc này vẫn hoàn toàn chưa biết.
a. Cấu trúc của một mô tả ca sử dụng
Cấu trúc của một mô tả ca sử dụng thường được tổ chức sao cho cả người phát
triển, khách hàng và người dùng có thể hiểu được. Một ca sử dụng cần có cấu trúc như
sau:
 Trạng thái xuất phát (tiền điều kiện)
23

 Làm thế nào và khi nào thì ca sử dụng khởi động (tức hành động thứ nhất được
thực hiện như thế nào?)
 Các chuỗi hành động phải được thực hiện theo thứ tự được xác định bởi chuỗi
hành động đã đánh số
 Ca sử dụng kết thúc khi nào và như thế nào
 Trạng thái kết thúc (hậu điều kiện)
 Các con đường không được phép thực hiện
 Mô tả các con đường cơ bản mà dãy hành động xảy ra
 Mô tả các con đường ngoại lệ
Một nhiệm vụ quan trọng nữa là đặc tả những yêu cầu phi chức năng. Đa số những
yêu cầu phi chức năng đều liên quan đến một ca sử dụng cụ thể nào đó, ví dụ các yêu cầu
về tốc độ thực hiện, độ chính xác, tính khả dụng… Các yêu cầu như vậy được coi như là
các yêu cầu đặc biệt của ca sử dụng đang xem xét. Ta có thể chuẩn bị chúng như một
phần của tài liệu mô tả ca sử dụng.
b. Hình thức hóa các mô tả ca sử dụng
Đối với những ca sử dụng phức tạp, có nhiều trạng thái và sự chuyển tiếp, thì hình
thức mô tả bằng văn bản hay dùng bảng thường không đảm bảo được tính nhất quán và
làm cho người phát triển khó hình dung. Do vậy, có thể hình thức hóa các mô tả ca sử
dụng bằng các biểu đồ có tính trực quan hơn, chẳng hạn biểu đồ trạng thái UML, biểu đồ
hoạt động hay các biểu đồ tương tác.

1.3.2.4. Tạo bản mẫu Giao diện người dùng
Việc phác thảo các giao diện người dùng giúp cho người dùng thực hiện các ca sử
dụng một cách hiệu quả. Với mỗi ca sử dụng, ta cố gắng nhận biết xem cái gì là cần đối
với giao diện người dùng để tạo khả năng cho mỗi tác nhân dùng các ca sử dụng. Công
việc này gọi là thiết kế giao diện người dùng logic. Sau đó ta tạo thiết kế giao diện người
dùng thực và phát triển các bản mẫu để minh họa cách thức mà các người dùng có thể
dùng hệ thống để thực hiện các ca sử dụng.
1.3.2.5. Tái cấu trúc mô hình ca sử dụng
Mục đích của việc tái cấu trúc mô hình ca sử dụng là: Thứ nhất, tìm ra các mô tả
chức năng có đặc tính chung được chia sẻ trong nhiều ca sử dụng để tách ra mô tả riêng.
Thứ hai, tìm ra các chức năng phụ hoặc tùy chọn để mở rộng mô tả chức năng thành các
chức năng mới nhằm làm phong phú thêm các yêu cầu của hệ thống.
24

1.3.3. Phân tích
Phân tích hướng đối tượng là một giai đoạn của quá trình phát triển phần mềm,
trong đó mô hình khái niệm được mô tả chính xác, súc tích thông qua các đối tượng thực
và các khái niệm của bài toán ứng dụng. Giai đoạn này tập trung vào việc tìm kiếm các
đối tượng, khái niệm trong lĩnh vực bài toán và xác định mối quan hệ của chúng trong hệ
thống. Nhiệm vụ của người phân tích là nghiên cứu kỹ các yêu cầu của hệ thống và phân
tích các thành phần của hệ thống cùng các mối quan hệ của chúng.
Kết quả chính của pha phân tích hệ thống hướng đối tượng là biểu đồ lớp (sơ
lược), biểu đồ trạng thái, biểu đồ trình tự, biểu đồ hành động [1].
Khi nắm bắt các yêu cầu ta đã nắm bắt các yêu cầu chức năng dưới dạng các ca sử
dụng và các yêu cầu phi chức năng dưới dạng các tài liệu bổ sung cho các tài liệu mô tả
ca sử dụng. Tuy nhiên, do các yêu cầu đã được diễn đạt bằng các ngôn ngữ không chính
xác của khách hàng nên vẫn còn nhiều vấn đề tồn tại chưa giải quyết được về yêu cầu của
hệ thống. Chính vì điều đó ta cần phân tích những yêu cầu bằng cách sử dụng các ngôn
ngữ của nhà phát triển để mô tả kết quả thực nhận được và ta sẽ nhận được mô hình phân
tích.

Phân tích hướng đối tượng là giai đoạn phát triển một mô hình chính xác và súc
tích của vấn đề, có thành phần là các đối tượng và khái niệm thực tế, dễ hiểu với người sử
dụng. Trong giai đoạn này, vấn đề được trình bày bằng thuật ngữ tương ứng với các đối
tượng có thực. Dựa trên những vấn đề có sẵn, nhà phân tích ánh xạ các đối tượng hay
thực thể có thực như khách hàng, nhân viên bán hàng, … vào thiết kế để tạo ra được bản
thiết kế gần cận với tình huống thực tế. Mô hình thiết kế sẽ chứa các thực thể trong một
vấn đề có thực và giữ nguyên các mẫu hình về cấu trúc, quan hệ cũng như hàng vi của
chúng. Nói cách khác, sử dụng phương pháp hướng đối tượng chúng ta có thể mô hình
hóa các thực thể thuộc một vấn đề có thực mà vẫn giữ được cấu trúc, quan hệ cũng như
hành vi của chúng. Như vậy, ta chú ý đến cả hai khía cạnh là thông tin và cách hoạt động
của hệ thống tức là những gì có thể xảy ra với những thông tin đó. Kiểu phân tích bằng
ánh xạ thực vào máy tính chính là một ưu điểm lớn của phương pháp hướng đối tượng.
Mô hình phân tích là một mô hình đối tượng khái niệm. Nó xác định các yêu cầu
và suy luận về cấu trúc nội tại của hệ thống. Mô hình phân tích được thể hiện ở mức cao
bằng hệ thống các gói phân tích. Trong mô hình phân tích, các ca sử dụng được thực thi
bởi các lớp và các đối tượng phân tích. Trong mô hình phân tích ta tập trung vào mô tả
hoạt dộng bên trong của hệ thống đã thực thi ca sử dụng như thế nào với sự cộng tác của
các đối tượng logic.
25

Để tạo ra mô hình phân tích cần tiến hành:
Phân tích kiến trúc
Phân tích một ca sử dụng
Phân tích một lớp
Phân tích một gói
Trong quá trình phân tích, ta sẽ liên tục tìm các gói, các lớp phân tích mới và các
yêu cầu chung khi mô hình phân tích được tiếp tục làm mịn bằng cách phân rã các gói
phân tích và duy trì các gói đó.
1.3.3.1. Phân tích kiến trúc
Mục đích của phân tích kiến trúc là phác họa những nét lớn của mô hình phân tích

thông qua việc xác định các gói phân tích, các lớp phân tích hiển nhiên và các yêu cầu
chuyên biệt chung.
Xác định các gói phân tích
Xử lý phần chung của các gói phân tích
Xác định các gói dịch vụ
Xác định các mối quan hệ phụ thuộc giữa các gói phân tích
Xác định các lớp thực thể hiển nhiên
Xác định các yêu cầu đặc biệt chung
1.3.3.2. Phân tích một ca sử dụng
a. Xác định các lớp phân tích
Lớp phân tích thể hiện cho sự trừu tượng của một hoặc nhiều lớp hay hệ thống con
trong thiết kế hệ thống. Có ba kiểu lớp phân tích cơ bản là lớp điều khiển, lớp thực thể và
lớp biên.
Lớp điều khiển là các lớp thể hiện sự phối hợp, sắp trình tự, các giao dịch, sự điều
khiển của các đối tượng và thường được sử dụng để bao gói điều khiển liên quan đến một
ca sử dụng cụ thể. Các khía cạnh động của hệ thống được mô hình hóa qua các lớp điều
khiển.
26

Lớp thực thể được dùng để mô hình hoác các thông tin tồn tại lâu dài và có thể
được lưu trữ. Các lớp thực thể thường được thể hiện các cấu trúc logic và góp phần làm
rõ về các thông tin mà hệ thống cần dựa vào.
Lớp biên thường được sử dụng để mô hình hóa tương tác của hệ thống với các tác
nhân của nó. Tương tác này gồm việc nhập và hiển thị thông tin từ các yêu cầu của người
dùng và các hệ thống ngoài. Mỗi lớp biên liên quan đến ít nhất một tác nhân và ngược lại.
Chúng ta sẽ xác định các lớp điều khiển, lớp thực thể và lớp biên cần thiết cho
việc thực thi ca sử dụng và phác thảo các tên gọi, các trách nhiệm, các thuộc tính và các
mối quan hệ của chúng.
b. Mô tả các tương tác giữa các đối tượng phân tích
Khi đã có những phác thảo về các lớp phân tích cần thiết để thực thi các ca sử

dụng, chúng ta cần phải mô tả cách thức mà các đối tượng phân tích tương tác với nhau
như thế nào. Việc này được thực hiện bằng các biểu đồ cộng tác, chúng chứa các thể hiện
của tác nhân tham gia, các đối tượng phân tích và các mối liên kết giữa chúng.
Một biểu đồ cộng tác xuất phát từ một điểm khởi đầu của luồng sự kiện ca sử
dụng, sau đó đi theo luồng từng bước và xác định xem đối tượng phân tích nào và các
tương tác của các thể hiện tác nhân nào là cần thiết để thực thi ca sử đụng đó. Trong một
vài trường hợp, có thể bổ sung các mô tả bằng văn bản cho các biểu đồ cộng tác, đặc biệt
nếu có nhiều biểu đồ thực thi cùng một ca sử dụng hoặc nếu các biểu đồ trình bày các
luồng phức tạp.
c. Nắm bắt các yêu cầu đặc biệt
Ta cần nắm bắt các yêu cầu phi chức năng cần cho việc thực thi một ca sử dụng
mà đã được xác định trong phân tích nhưng phải được xử lý trong thiết kế và thực thi.
1.3.3.3. Phân tích một lớp
Mục đích của việc phân tích một lớp là:
Xác định và duy trì các trách nhiệm của một lớp phân tích dựa trên vai trò của nó
trong các thực thi ca sử dụng.
Xác định và duy trì các thuộc tính và các mối quan hệ của lớp phân tích.
Nắm bắt các yêu cầu đặc biệt về việc thực thi của lớp phân tích.