Tài liệu tham khảo hỗ trợ môn học PHÂN TÍCH THIẾT KẾ HTTT VỚI UML

Tài liệu tham khảo hỗ trợ môn học

PHÂN TÍCH THIẾT KẾ HTTT VỚI UML
TS. Phan Đăng Cầu

Hà nội, 25/04/2006
(Tổng số trang cả bìa: 58)


MỤC LỤC
CHƯƠNG 1. MỞ ĐẦU...................................................................................4

1.1. MỘT VÀI KHÁI NIỆM CƠ BẢN........................................................4
1.2. CÔNG NGHỆ PHẦN MỀM NHÌN TỪ GÓC ĐỘ LỊCH SỬ....................6
1.3. MỤC ĐÍCH VÀ YÊU CẦU CỦA MÔN HỌC........................................8
CHƯƠNG 2. PHA XÁC ĐỊNH YÊU CẦU...........................................................9

2.1. NẮM BẮT YÊU CẦU.......................................................................9
2.2. PHÂN TÍCH YÊU CẦU...................................................................10
2.3. LÀM BẢN MẪU (PROTOTYPING)..................................................10
2.4. CÓ KHÁI NIỆM YÊU CẦU HƯỚNG ĐỐI TƯỢNG KHÔNG?.............11
2.5. TÓM TẲT CHƯƠNG.....................................................................11
2.6. PHA YÊU CẦU: TÌM HIỂU VẤN ĐỀ QUẢN LÝ SÁCH Ở THƯ VIỆN. . .11
CHƯƠNG 3. TỔNG QUAN VỀ UML VÀ PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG15

3.1. SỰ RA ĐỜI CỦA PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG...............15
3.2. TỔNG QUAN VỀ NGÔN NGỮ UML...............................................15
3.3. MÔ HÌNH USE-CASE....................................................................17
3.4. MÔ HÌNH LỚP.............................................................................28
3.5. BIỂU ĐỒ HOẠT ĐỘNG.................................................................35
3.6. BIỂU ĐỒ TRẠNG THÁI.................................................................39

3.7. BIỂU ĐỒ TUẦN TỰ......................................................................41
3.8. BIỂU ĐỒ CỘNG TÁC....................................................................45
3.9. SỬ DỤNG PHẦN MỀM RATIONAL ROSE.......................................47
3.10. SỬ DỤNG MỘT SỐ PHẦN MỀM KHÁC........................................49
CHƯƠNG 4. PHA PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG....................................50

4.1. PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG................................................50
4.2. PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG HỆ THỐNG QUẢN LÝ THƯ VIỆN
..........................................................................................................50
CHƯƠNG 5. PHA THIẾT KẾ HƯỚNG ĐỐI TƯỢNG.......................................59

5.1. THIẾT KẾ CƠ SỞ DỮ LIỆU...........................................................59
5.2. XÂY DỰNG BIỂU ĐỒ TƯƠNG TÁC CHO CÁC SCENARIO..............59
5.3. XÂY DỰNG BIỂU ĐỒ LỚP CHI TIẾT.............................................60
5.4. THIẾT KẾ GIAO DIỆN...................................................................61
5.5. THIẾT KẾ CHI TIẾT......................................................................62
5.6. VỀ VẤN ĐỀ CÀI ĐẶT OOD...........................................................62


MỘT SỐ THUẬT NGỮ VÀ CÁCH VIẾT TẮT....................................................63
TÀI LIỆU THAM KHẢO..................................................................................64
CÂU HỎI VÀ BÀI TẬP...................................................................................65


CHƯƠNG 1. MỞ ĐẦU
1.1. MỘT VÀI KHÁI NIỆM CƠ BẢN

Phần cứng (hardware) là các thiết bị cấu kiện mang tính vật lý có thể tiếp xúc bằng tay được
như máy in, ổ đĩa, máy quét, các mạch tích hợp (IC).
Phần mềm (software) hiểu theo nghĩa đơn giản nhất là các chương trình chứa các dòng lệnh

chỉ thị cho máy tính thực hiện một công việc nào đó. Tuy nhiên thường người ta hiểu phần
mềm là một tập hợp các chương trình và cả dữ liệu phục vụ cho một công việc được tin học
hóa nào đó. Ví dụ phần mềm quản lý các dịch vụ bay, phần mềm điều khiển lò phản ứng hạt
nhân, phần mềm điều khiển dịch vụ mobile phone...Đôi khi người ta gọi phần mềm là chương
trình, cho dù thực tế thì phần mềm gồm nhiều chương trình và dữ liệu. Ví dụ: chương trình
quản lý nhân sự, chương trình quản lý tín dụng...
Trong công nghệ phần mềm, người ta hiểu phần mềm không chỉ là các chương trình, dữ liệu,
mà còn gồm cả các tài liệu liên quan như các bản đặc tả, thiết kế, hướng dẫn sử dụng.
Chương trình (program): đôi khi người ta gọi phần mềm là chương trình. Hay chính xác hơn,
người ta thường gọi phần được cài đặt trên máy tính để chạy là chương trình. Với cách hiểu
như vậy thì phần mềm = chương trình + tài liệu. Tuy nhiên, trong thực tế có khi người ta đồng
nhất hai khái niệm này. Ví dụ người ta nói rằng "phần mềm được cài đặt trên máy tính khách
hàng".
Kỹ nghệ phần mềm (software engineering) là cách làm phần mềm tuân theo những nguyên tắc
tương tự như các nguyên tắc của kỹ nghệ truyền thống (ví dụ kỹ nghệ xây dựng cầu, kỹ nghệ
làm đường,...)
Do thói quen, trong nhiều tài liệu người ta dùng từ công nghệ phần mềm thay cho từ được
dịch đúng nghĩa hơn là kỹ nghệ phần mềm.
Vòng đời phần mềm (software life-cycle) là các giai đoạn mà một phần mềm phải trải qua, bắt
đầu từ khảo sát nhu cầu thực tế cho đến khi phần mềm thôi sử dụng.
Phát triển phần mềm (software developement): Trước những năm 1970, việc sản xuất một
phần mềm được coi là kết quả của hai giai đoạn nối tiếp nhau: phát triển và bảo trì. Phát triển
phần mềm là giai đoạn từ những khảo sát đầu tiên cho đến khi phần mềm được hoàn thành và
đưa vào sử dụng. Khoảng thời gian sau đó cho đến khi phần mềm thôi sử dụng được gọi là thời
gian bảo trì (software maintenance). Năm 1970 W.W. Royce lần đầu tiên đưa ra mô hình phát
triển phần mềm (software development model) trải qua nhiều giai đoạn được gọi là mô hình
thác đổ (Waterfall model). Trong mô hình này, quá trình tạo ra phần mềm ( a process for the
creation of software) được coi như một dòng chảy trải qua các pha yêu cầu, phân tích, thiết kế,
cài đặt, tích hợp và bảo trì.
Người phát triển (software developer) là tên gọi chung cho những người tham gia xây dựng

phần mềm.
Nhóm đảm bảo chất lượng phần mềm (software quality assurance group = SQA group) nhóm
chuyên kiểm tra chất lượng phần mềm, kiểm tra kết quả của từng giai đoạn xây dựng phần
mềm.
Quy trình làm phần mềm (software process) là cách thức làm ra phần mềm, bao gồm vòng
đời phần mềm, các công cụ và những người phát triển phần mềm.
Pha (phase) là một giai đoạn trong quá trình xây dựng phần mềm. Ví dụ pha xác định yêu cầu,
pha phân tích...


PTTK HTTT với UML - Chương 1. Mở đầu

Yêu cầu (requirements) là pha đầu tiên trong quá trình xây dựng phần mềm. Người phát triển
và khách hàng ngồi lại với nhau. Khách hàng nêu ra những yêu cầu mà phần mềm phải có.
Những người phát triển ghi chép lại. Nếu dịch theo tiếng Anh "requirements phase" là pha yêu
cầu. Tuy nhiên cách gọi quá đơn giản như thế này có thể hơi khó hiểu, do đó ta sẽ gọi là pha
xác định yêu cầu.
Đặc tả (specification) hoặc phân tích (analysis): Trên cơ sở những yêu cầu của khách hàng,
người phát triển mô tả lại chính xác hơn các yêu cầu mà phần mềm phải có. Cách mô tả này có
tính chuyên môn và đôi khi sử dụng các công cụ trợ giúp. Pha này trả lời câu hỏi "phần mềm
làm cái gì?" (what the product is to do?)
Phân tích hệ thống (system analysis) người ta thường gộp hai pha yêu cầu và phân tích thành
một pha và gọi là pha phân tích hệ thống.
Thiết kế (design) là pha tiếp theo pha đặc tả. Căn cứ vào tài liệu đặc tả, pha này mô tả cách
thức mà phần mềm thực hiện các công việc cụ thể. Pha này trả lời câu hỏi "phần mềm thực
hiện những cái đó như thế nào?" (how the product is to do it). “Cái đó” ở dây được hiểu là
những gì phần mềm cần làm được nêu trong pha đặc tả. Pha thiết kế thường có hai phần: thiết
kế kiến trúc (architecture design) và thiết kế chi tiết (detail design).
Cài đặt (implementation) hoặc mã hóa (coding) hay lập trình (programming): viết chương
trình bằng một ngôn ngữ cụ thể nào đó.

Tích hợp (integration) kết nối các phần chương trình đã viết thành một phần mềm thống nhất
và chạy thử, hiệu chỉnh cho đến khi chạy tốt.
Bảo trì (maintenance) hay đôi khi được gọi là hỗ trợ (trong tài liệu tiếng Việt): Những hiệu
chỉnh, sửa đổi trên phần mềm như sửa lỗi phát sinh, hiệu chỉnh phần mềm theo yêu cầu khách
hàng... kể từ khi phần mềm được đưa vào sử dụng.
Ngày nay để xây dựng một phần mềm người ta thường thực hiện các bước (các bước này theo
thuật ngữ tin học được gọi là các pha) sau đây:
Xác định yêu cầu, phân tích, thiết kế, cài đặt, tích hợp, bảo trì.
Trong nhiều tài liệu người ta gộp hai pha đầu tiên và đặt tên là "Phân tích hệ thống". Pha tích
hợp gồm hai công việc: ghép nối các phần chương trình (đã được viết và kiểm thử riêng biệt)
thành phần mềm đầy đủ, sau đó chạy thử và kiểm tra toàn bộ phần mềm. Cũng có lúc người ta
cho rằng việc tích hợp phải được tiến hành đồng thời với lập trình, do đó người ta tách công
việc kiểm thử từ pha tích hợp thành một pha riêng. Cũng có lúc người ta kết hợp hai pha cài
đặt và tích hợp thành pha "cài đặt và tích hợp".
Nếu tổ hợp các cách gọi khác nhau nói trên, có thể có nhiều cách mô tả các bước làm phần
mềm tuy khác nhau về hình thức nhưng thực chất là tương đương, ví dụ như:
Xác định yêu cầu, phân tích, thiết kế, cài đặt, kiểm thử, bảo trì.
Phân tích hệ thống, thiết kế, cài đặt, kiểm thử, bảo trì.
Xác định yêu cầu, phân tích, thiết kế, cài đặt và tích hợp, bảo trì.
Xác định yêu cầu, phân tích, thiết kế, cài đặt và kiểm thử, bảo trì.
...
Lưu ý rằng từ "phân tích" có thể thay bằng từ đồng nghĩa là "đặc tả"; từ "cài đặt" còn có các
cách gọi khác nhau là "thực hiện" hay "lập trình".
Trong tài liệu này chúng ta sẽ sử dụng cách gọi đầu tiên.
5


PTTK HTTT với UML - Chương 1. Mở đầu

1.2. CÔNG NGHỆ PHẦN MỀM NHÌN TỪ GÓC ĐỘ LỊCH SỬ

Máy tính điện tử đầu tiên cho mục đích thương mại là máy UNIVAC-1 được sản xuất năm
1951 ở Mỹ. Từ khoảng những năm 1955 thì bắt đầu có các phần mềm, tức là các chương trình
máy tính. Cho đến nay, nếu lấy phương pháp và mức độ phức tạp làm căn cứ, thì có thể chia
quá trình phát triển phần mềm thành 3 giai đoạn: 1955 - 1970, 1971 - 1985, 1986 đến nay. Tất
nhiên sự phân chia này chỉ là tương đối mà thôi. Đặc điểm của từng giai đoạn là:
- 1955 - 1970: Tính toán và quản lý rời rạc, quản lý nhỏ. Đặc tả những yêu cầu của khách
hàng lúc đó còn dùng ngôn ngữ tự nhiên thông thường. Ví dụ các câu kiểu như: tôi muốn
có tệp dữ liệu chứa những thông tin về bán sản phầm như số hóa đơn, người bán, mặt
hàng,...; dữ liệu sẽ được nhập từ bàn phím, có kiểm tra rồi mới đưa vào tệp. Hàng tháng tôi
muốn lấy thông tin về doanh thu, lãi, số hàng bán... Chương trình hồi đó chỉ gồm khoảng
trên dưới vài trăm dòng lệnh, do đó thừong chỉ do một người thực hiện. Thiết kế thời ấy
không được soạn thảo ra giấy mà chỉ hình thành trong tư duy của người lập trình. Người
lập trình vừa viết chương trình vừa suy nghĩ về cách tổ chức dữ liệu, cách sử dụng các thuật
toán sao cho chương trình chạy tốt, đáp ứng được yêu cầu của khách hàng. Phương pháp lập
trình được sử dụng thời đó là lập trình tuyến tính, tức là cách viết chương trình trong đó
phần lớn các lệnh được đặt theo trình tự thực hiện của chúng, nghĩa là lệnh cần thực hiện
trước sẽ được viết trước, lệnh thực hiện sau được viết sau.
- 1971 - 1985: Lúc này đã có nhu cầu xây dựng các phần mềm thời gian thực (ví dụ tính
toán trong lò phản ứng hạt nhân phải có ngay kết quả để điều khiển kịp thời); có nhu cầu
xây dựng các mạng cục bộ và kết nối các cơ sở dữ liệu. Phần mềm trong thời kỳ này đã
khá lớn, một người không thể hoàn thành trong thời gian ngắn được. Người ta nghĩ đến việc
phân chia phần mềm cho nhiều người làm rồi ghép nối lại thành phần mềm hoàn chỉnh. Để
làm được điều này người ta phải nghĩ cách diễn tả phần mềm một cách chính xác. Ngôn
ngữ tự nhiên thường chứa đựng những yếu tố nhập nhằng không thích hợp cho công việc
này, do đó người ta đã đưa ra các công cụ để đặc tả phần mềm, trong đó những công cụ có
tính trực quan, sử dụng các biểu đồ là được sử dụng nhiều nhất. Vì vấn đề lớn cần phải được
mô tả có cấu trúc cho dễ hiểu, do đó phương pháp phân tích có cấu trúc (structured
analysis) đã ra đời. Phương pháp cấu trúc được thực sự sử dụng từ sau năm 1975. Phương
pháp này tập trung vào việc mô tả các công việc cần thực hiện trong phần mềm và thông tin

chuyển giao giữa chúng. Thành phần cơ bản của phương pháp cấu trúc là biểu đồ luồng dữ
liệu (Data Flow Diagram - DFD). Thiết kế thời đó chú trọng tới cấu hình hệ thống
(system configuration). Vấn đề cấu trúc dữ liệu và giải thuật cũng được chú ý. Các
chương trình tiêu biểu thời đó có thể kể tới hệ điều hành DOS, UNIX...Lúc đó cũng đã có
những cơ sở dữ liệu có thể truy cập từ xa. Do nhu cầu thực tế, các ngôn ngữ lập trình ra đời
giai đoạn này đã có khả năng hỗ trợ phương pháp lập trình có cấu trúc, nghĩa là chương
trình được phân chia thành các chương trình con, mỗi chương trình con có tên và các
chức năng xử lý riêng, có thể giao tiếp với các chương trình con khác thông qua các đối số
và kiểu trả về (nếu có).
- Từ 1986 đến nay: Đây là thời kỳ của máy vi tính PC, thời nối mạng tầm rộng, mạng
toàn cầu Internet. Ngày nay có những hệ phần mềm cần hàng trăm người làm trong nhiều
năm như hệ phần mềm dùng cho chương trình không gian của Mỹ. Thậm chí có những hệ
cần đến hàng ngàn người trong nhiều nước làm trong nhiều năm như chương trình điều
khiển tổng đài điện thoại hiện được bán khắp nơi trên thế giới. Khác với các sản phẩm khác,
phần mềm không bao giờ giữ nguyên mà không ngừng được thay đổi. Ví dụ như chương
trình quản lý kết quả thi đại học chẳng hạn. Có thể mỗi năm lại có một chính sách khác và
phải sửa lại cho phù hợp. Chương trình quản lý nhân sự của một cơ quan, chương trình quản
lý du lịch, ... cũng vậy. Người ta nhận thấy rằng phương pháp cấu trúc chỉ thích hợp cho các
phần mềm dưới 5000 dòng lệnh. Đặc điểm của phương pháp cấu trúc là tách riêng dữ liệu
và các thao tác xử lý chúng; trong khi đó có thể thấy rằng các công việc trong thực tế đều
6


PTTK HTTT với UML - Chương 1. Mở đầu

do các đối tượng thực hiện, mà các đối tượng thì bao hàm trong chúng cả các thuộc tính và
hành vi. Ví dụ như công việc ở một cửa hàng chẳng hạn, nếu có một chút trừu tượng và
nhân cách hóa, thì có thể xem là sự phối hợp hoạt động của các đối tượng: khách hàng,
hàng, hóa đơn... Phương pháp diễn tả phần mềm theo cách nhìn nhận này được gọi là
phương pháp hướng đối tượng (Object-Oriented Method). Bản chất của phương pháp này

là mô tả phần mềm như một hoạt động được tạo nên bởi các đối tượng. Mặc dù hiện nay
phương pháp cấu trúc vẫn còn được sử dụng, nhưng phương pháp hướng đối tượng ngày
càng chiếm ưu thế và được sử dụng nhiều hơn. Phương pháp hướng đối tượng bao gồm:
phân tích, thiết kế và lập trình hướng đối tượng. Trong thiết kế người ta chú ý đến
môđun (module), đối tượng (object), giao thức (protocol) và giao diện (interface). Giao
thức hay giao diện nói về sự trao đổi giữa các đối tượng. Khi cài đặt trên máy tính người ta
thường dùng ngôn ngữ hướng đối tượng. Các công cụ CASE (Computer Aided Software
Engineering) cũng được sử dụng nhiều trong công việc làm phần mềm. Ngoài các phần mềm
được viết theo đặt hàng, người ta chú trọng đến các phần mềm đóng gói như: Netscape,
Internet Explorer, Word, Excel...
Người ta cho rằng việc xây dựng một phần mềm cũng cần tuân theo những nguyên tắc và kỹ
luật giống như khi xây dựng một chiếc cầu hay thực hiện những công việc kỹ nghệ khác. Nếu
một chiếc cầu bị lỗi khi xây dựng và do đó bị sập thì tác hại gây ra rất lớn. Một phần mềm quan
trọng như phần mềm điều khiển hệ thống tên lửa đạn đạo của một nước mà có lỗi, cho kết quả
tính toán sai thì hậu quả nó gây ra cũng thật là kinh khủng. Chính vì vậy một nhóm nghiên cứu
của NATO trong năm 1967 đã sử dụng thuật ngữ "Software engineering". Họ muốn rằng khi
xây dựng phần mềm thì các kỹ sư cũng cần áp dụng các nguyên tắc của kỹ nghệ truyền thống.
Tuy nhiên, có nhiều sự khác biệt giữa sản phẩm của kỹ nghệ truyền thống và công nghệ phần
mềm. Ví dụ như chiếc cầu và hệ điều hành chẳng hạn. Sự cố cầu sập rất ít khi xảy ra và nếu
xảy ra thì cách khắc phục thường là xây dựng lại. Còn hệ điều hành nếu có sự cố có khi chỉ cần
tắt máy khởi động lại là lại chạy tốt. Phần mềm có thể sửa lại, có khi là tới 50% để có thể chạy
trên máy tính có cấu hình khác hoặc thực hiện thêm các chức năng khác. Còn chiếc cầu muốn
sửa lại 50% thì rất khó, nhiều khi xây dựng mới còn dễ thực hiện hơn.
Mục tiêu của công nghệ phần mềm là sản xuất ra các phần mềm không có lỗi, được hoàn
thành đúng thời hạn với kinh phí cho phép và thỏa mãn yêu cầu khách hàng. Hơn nữa phần
mềm phải dễ sửa đổi khi người sử dụng cần.
Để đạt được điều này, các kỹ sư phần mềm phải được trang bị các kỹ năng về kỹ thuật cũng
như về quản lý. Các kỹ năng này không chỉ thể hiện khi viết chương trình, mà phải được áp
dụng trong các pha xây dựng phần mềm, bắt đầu từ khảo sát yêu cầu khách hàng cho đến giai
đoạn bảo trì. Có thể nêu một vài lý do khiến chúng ta phải nghiên cứu các cách thức xây dựng

phần mềm một cách có khoa học là:
• Ngày nay phần lớn phần mềm được xây dựng theo đơn đặt hàng. Như vậy cần có một
ngôn ngữ chung giữa người xây dựng phần mềm và khách hàng.
• Phần mềm thường không do một người mà gồm rất nhiều người xây dựng. Những người
cùng phát triển một phần mềm phải hiểu rõ công việc của mình và công việc chung, mối
liên hệ giữa công việc của từng cá nhân hoặc từng nhóm. Cần có một cách thức diễn đạt
các công việc làm phần mềm sao cho mỗi kỹ sư phần mềm đều có thể trao đổi dễ dàng
các ý tưởng và công việc của mình với các kỹ sư trong nhóm làm việc.
• Phần mềm cũng là một thứ hàng hóa như những thứ hàng hoá khác và do đó phải tuân
thủ nguyên tắc của kinh tế thị trường là sản phẩm phải độc lập với người sản xuất.
Nghĩa là sau khi mua hàng, người mua không bị lệ thuộc vào người bán. Muốn vậy thì
sản phẩm phần mềm ngoài chương trình chạy trên máy, cần có thêm các tài liệu sao cho
người khác có thể tìm hiểu và bảo trì được. Vậy thì cần một ngôn ngữ, một cách trình
bày chung cho các sản phẩm phần mềm.

7


PTTK HTTT với UML - Chương 1. Mở đầu

1.3. MỤC ĐÍCH VÀ YÊU CẦU CỦA MÔN HỌC

Như trên đã nói tới, phân tích và thiết kế là hai giai đoạn quan trọng của quá trình tạo ra
phần mềm. Có hai phương pháp đang được sử dụng là cấu trúc và hướng đối tượng, trong đó
phương pháp hướng đối tượng ngày càng chiếm ưu thế hơn. Trong các giai đoạn làm phần mềm
thì chỉ có pha đầu tiên, pha xác định yêu cầu, là chủ yếu sử dụng ngôn ngữ tự nhiên; các pha
còn lại đều sử dụng một số công cụ chuyên dụng. UML là một công cụ được tạo ra với mục
đích sử dụng cho phân tích và thiết kế phần mềm theo phương pháp HĐT. UML là ngôn ngữ
nửa hình thức, có tính trực quan, tức là sử dụng các biểu tượng hình ảnh, dùng để mô tả phần
mềm. Mục đích của môn học này là sử dụng UML cho công việc phân tích và thiết kế phần

mềm hướng đối tượng. Vì phân tích chỉ có thể được thực hiện sau khi hoàn thành pha xác định
yêu cầu, do đó môn học bao hàm cả việc giới thiệu những công việc cần làm trong pha xác
định yêu cầu. Các yêu cầu của môn học này là:
• Sinh viên cần nắm được những công việc cần làm trong các pha: xác định yêu cầu,
phân tích và thiết kế phần mềm.
• Nắm được những quy tắc, các biểu tượng và các dạng biểu đồ cơ bản trong UML để
có thể phân tích và thiết kế một phần mềm HĐT.
• Áp dụng được những kiến thức đã học để thực hiện các pha xác định yêu cầu, phân
tích và thiết kế một vấn đề thực tế cần tin học hóa.
Ngoài ra chúng tôi cũng khuyến khích các bạn sinh viên nên cài đặt chương trình theo bản
phân tích thiết kế bằng một ngôn ngữ mà các bạn đã quen thuộc hoặc dễ học, ví dụ Microsoft
Access chẳng hạn, vì như vậy các bạn sẽ hiểu sâu hơn lý thuyết.

8


CHƯƠNG 2. PHA XÁC ĐỊNH YÊU CẦU
2.1. NẮM BẮT YÊU CẦU

Quá trình khám phá các yêu cầu của khách hàng được gọi là sự nắm bắt yêu cầu (requirements
capture), hoặc sự gợi mở yêu cầu (requirements elicitation) hay tìm hiểu vấn đề (concept
exploration). Sau khi các yêu cầu được xác định thì chúng được xem xét để hiệu chỉnh, lược
bỏ bớt hoặc mở rộng. Quá trình này được gọi là phân tích yêu cầu (requrements analysis). Pha
yêu cầu thường được bắt đầu bằng việc gặp gỡ trao đổi giữa một vài thành viên của nhóm yêu
cầu và một vài thành viên đại diện cho công ty khách hàng để cùng nhau xác định xem sản
phẩm phần mềm cần những gì. Cuộc trao đổi thường được thực hiện theo cách là thành viên
của nhóm yêu cầu đưa ra các câu hỏi có tính gợi mở về lĩnh vực mà phần mềm được sử dụng.
Các thành viên của công ty khách hàng hoặc trả lời các câu hỏi của nhóm yêu cầu, hoặc chủ
động nêu ra các vấn đề mà họ cần. Rõ ràng những thành viên tham gia khám phá yêu cầu của
khách hàng phải có hiểu viết về lĩnh vực mà phần mềm ứng dụng để có thể hiểu được những

điều khách hàng nói và có thể đưa ra các câu hỏi có ý nghĩa. Vì vậy việc nhiệm vụ đầu tiên của
nhóm yêu cầu chính là tìm hiểu và làm quen với lĩnh vực ứng dụng của phần mềm mà khách
hàng muốn có. Ví dụ nếu phần mềm là quản lý các chuyến bay của một hãng hàng không thì
lĩnh vực cần tìm hiểu là cách thức quản lý các chuyến bay của một hãng hàng không. Nếu phần
mềm là chương trình quản lý thư viện thì nhóm yêu cầu cần có hiểu biết nhất định về lĩnh vực
thư viện...Để sử dụng từ một cách chính xác, các thành viên nhóm yêu cầu cần tìm hiểu các
thuật ngữ. Ví dụ nếu họ đang chuẩn bị làm phần mềm trong lĩnh vực sinh học thì cần tìm hiểu
các thuật ngữ về sinh học. Một trong những phương pháp khắc phục vấn đề thuật ngữ là xây
dựng bộ từ vựng về lĩnh vực ứng dụng. Mỗi lần gặp một thuật ngữ mới thì nhóm yêu cầu cần
tìm hiểu để hiểu được một cách chính xác và đưa thuật ngữ này vào bộ từ vựng. Sau khi đã có
nhưng hiểu biết nhất định về lĩnh vực ứng dụng phần mềm, các thành viên bắt đầu khám phá,
tìm hiểu các yêu cầu khách hàng theo các cách thức sau:

2.1.1. Phỏng vấn khách hàng
Có hai kiểu phỏng vấn: có cấu trúc (structured) và không có cấu trúc (unstructured). Với kiểu
phỏng vấn cấu trúc thì các câu hỏi đóng (close-ended) và được chuẩn bị trước. Ví dụ như
"công ty sử dụng bao nhiêu nhân viên bán hàng", "lương trung bình của các nhân viên trong
công ty là bao nhiêu"... Trong cách phỏng vấn không có cấu trúc thì các câu hỏi có tính mở
(open-ended) được đưa ra. Ví dụ như "Hãy nêu ra một vài điểm yếu của phần mềm đang sử
dụng mà khách hàng có ý định thay thế". Tuy nhiên cũng không nên hỏi những câu quá chung
chung, khó trả lời như "Hãy nói cho tôi biết về sản phẩm hiện tại". Các câu hỏi mở nên đưa ra
sao cho có thể khích lệ người được phỏng vấn có thể cho câu trả lời trong một phạm vi rộng,
tuy nhiên cũng không nên rộng quá mà chỉ nằm trong phạm vi các thông tin cần nắm bắt.
Phỏng vấn có hiệu quả là công việc không dễ dàng. Điều kiện quan trọng đầu tiên là người
phỏng vấn cần am hiểu về lĩnh vực mà họ chuẩn bị phỏng vấn. Các câu hỏi đưa ra cũng phải
hợp lý để người được phỏng vấn có thể nói ra những thông tin có ích cần thiết một cách tự
nhiên, không bị gò ép hay e ngại gì. Đôi khi những câu hỏi quá thẳng thắn và trực tiếp chưa
chắc đã nhận được câu trả lời đúng. Ví dụ nếu hỏi rằng "lương anh chị rất thấp, nhưng chi tiêu
thì có vẻ rất nhiều. Anh chị hãy cho biết làm sao có được khoản tiền ngoài lương kia..." thì
thường là người được hỏi sẽ tìm cách né tránh câu trả lời thật.

Sau khi phỏng vấn xong thì người phỏng vấn cần viết báo cáo về kết quả phỏng vấn và nên đưa
cho người được phỏng vấn xem và góp ý kiến.

2.1.2. Kịch bản (scenario)
Kịch bản là một kỹ thuật được sử dụng để phân tích yêu cầu. Kịch bản là mô tả các thao tác
cần thực hiện trên phần mềm cần xây dựng để hoàn thành một công việc nào đó (trong các
công việc mà phần mềm cung cấp).


PTTK HTTT với UML - Chương 2. Pha xác định yêu cầu

2.1.3. Một vài kỹ thuật nắm bắt yêu cầu khác
Một kỹ thuật khác hay được sử dụng để nắm bắt các yêu cầu khách hàng là gửi các bảng câu
hỏi cho một số thành viên đại diện của công ty khách hàng. Bằng cách này có thể gửi cho hàng
trăm thành viên và có thể nhận được các câu trả lời dưới dạng viết và được suy nghĩ kỹ. Tuy
nhiên nếu từ bảng câu hỏi đã được trả lời, người phỏng vấn có thể đưa ra thêm các câu hỏi
thích hợp với người được phỏng vấn thì có thể nhận được các thông tin bổ ích. Đôi khi các
thông tin này có ích hơn nhiều so với trả lời viết đã có.
Một cách khác để tìm hiểu và nắm bắt yêu cầu khách hàng, đặc biệt trong môi trường kinh
doanh, là xem xét các biểu mẫu khác nhau mà các khách hàng sử dụng. Ví dụ việc xem xét các
biểu mẫu được in ra trong phòng in ấn có thể biết được các dạng báo cáo, cỡ giấy; tài liệu viết
về cách thức điều hành hoặc mô tả công việc là những công cụ rất hữu ích để giúp tìm ra công
việc gì đang được thực hiện và được thực hiện như thế nào ở công ty khách hàng.
Gần đây người ta thường áp dụng thêm một phương pháp nữa là quay băng video cảnh làm
việc ở công ty khách hàng (tất nhiên là được sự cho phép của công ty và của những người
được quay). Như vậy có thể biết được chính xác những gì đang xảy ra. Tuy nhiên cách này có
một nhược điểm là phải tốn khá nhiều thời gian để xem lại băng và phân tích để rút ra những
thông tin cần thiết. Một nhược điểm rất lớn khác của phương pháp này là phần lớn những
người được quay đề không thích mình xuất hiện trong máy quay và trở nên dè dặt khi hành
động.

Sau khi thu được các thông tin ban đầu về yêu cầu khách hàng thì bước tiếp theo là phân tích
các yêu cầu đó để rút ra những thông tin cơ bản nhất có thể giúp ích cho việc xây dựng phần
mềm.
2.2. PHÂN TÍCH YÊU CẦU

Tới thời điểm này, nhóm yêu cầu đã có được tập hợp khởi đầu của các yêu cầu khách hàng.
Các yêu cầu này được phân làm hai loại: chức năng (functional) và phi chức năng
(nonfunctional).
Yêu cầu chức năng thường gắn với chức năng tương ứng của phần mềm cần xây dựng và thể
hiện dưới dạng các mục chọn của thực đơn, ví dụ như: "Phần mềm cung cấp chức năng tìm
kiếm hàng hóa theo tên hàng và ngày bán". Đặc tả phi chức năng dùng để chỉ rõ tính chất nào
đó của phần mềm cần xây dựng, ví dụ tính tin cậy và bảo trì được; hoặc liên quan đến môi
trường mà phần mềm được sử dụng, ví dụ: tất cả các mã khách hàng được nhập trực tiếp từ bàn
phím và được lưu trong một tệp bảng dữ liệu". Tóm lại yêu cầu chức năng là nói đến một công
việc cụ thể, thường thể hiện bằng các mục chọn trong chương trình; còn yêu cầu phi chức năng
thì nói về các tính chất của phần mềm, các tính chất này không thể thể hiện được bằng một việc
cụ thể. Thí dụ từ câu "yêu cầu phần mềm phải có giao diện đẹp, thân thiện với người sử dụng"
ta không thể nói được cụ thể là phải làm gì.
Một điều rất quan trọng là phần mềm phải theo dõi được (traceable). Điều này có nghĩa là có
thể kiểm tra xem tất cả các yêu cầu đã được thể hiện trong bản đặc tả chưa; điểm nào trong
bản báo cáo yêu cầu tương ứng với điểm nào trong báo cáo đặc tả. Tương tự báo cáo thiết kế
hay chương trình cũng phải tương ứng với các tài liệu trước đó. Như vậy nhóm bảo đảm chất
lượng phần mềm có thể kiểm tra xem có phải tất cả các mục trong các yêu cầu khách hàng đã
được thực hiện chưa.
Tất cả các yêu cầu thu thập được ban đầu đề được đưa cho khách hàng xem xét. Họ sẽ sắp xếp
các mục yêu cầu theo thứ tự quan trọng, phát hiện và hiệu chỉnh những điều không chính xác
hoặc bỏ đi những mục không cần thiết...
Tiếp theo, nhóm yêu cầu sẽ thảo luận với những khách hàng đã được phỏng vấn và xem xét lại
các vấn đề một cách kỹ càng, xem có điều gì còn bị bỏ sót không. Và như chúng ta biết, kỹ
thuật phân tích yêu cầu hiệu quả và chính xác nhất là làm bản mẫu, vì vậy nếu có thể thì nhóm

chuyển qua bước làm bản mẫu để đưa cho khách hàng xem xét một cách trực quan hơn.
2.3. LÀM BẢN MẪU (PROTOTYPING)

Bản mẫu được xem là kỹ thuật phân tích yêu cầu chính xác nhất.
10


PTTK HTTT với UML - Chương 2. Pha xác định yêu cầu

Bản mẫu là phần mềm được xây dựng nhanh chủ yếu để thể hiện các chức năng quan trọng
nhất của phần mềm cần xây dựng. Mục đích của bản mẫu là thể hiện các yêu cầu khách hàng,
do đó khi xây dựng người ta chú ý nhiều đến giao diện và các báo cáo in ra. Những vấn đề
quan trọng khác mà một phần mềm sản phẩm cần phải có như tính bảo mật, an toàn dữ liệu, tốc
độ tính toán, kiểm tra và khắc phục lỗi... đều chưa được chú ý khi làm bản mẫu; nghĩa là bản
mẫu chỉ là thể hiện bên ngoài của sản phẩm và bỏ qua những phần được che dấu. Bản mẫu
được cài đặt để khách hàng sử dụng thử. Qua việc thao tác trực tiếp với bản mẫu, họ sẽ thấy
được các chức năng của phần mềm đã thể hiện đúng các yêu cầu của họ chưa, cái gì cần thêm
bớt hay hiệu chỉnh bổ sung. Những người phát triển sẽ hiệu chỉnh bản mẫu cho đến khi khách
hàng vừa ý và cho rằng mọi yêu cầu của họ đã được bao hàm trong phần mềm (tất nhiên là về
hình thức). Bản mẫu sẽ được dùng làm cơ sở để biên soạn tài liệu đặc tả.
Như tên gọi của nó, bản mẫu nhanh (rapid prototype) được xây dựng với mục đích để người
phát triển và khách hàng thống nhất càng nhanh càng tốt những điều mà sản phẩm chính cần
làm. Như vậy có rất nhiều điều có thể bỏ qua khi làm bản mẫu. Bản mẫu có thể thường xuyên
gặp sự cố và phải khởi động lại; màn hình nhập dữ liệu có thể chưa đẹp; báo cáo in ra còn thiếu
biểu tượng công ty khách hàng,...
2.4. CÓ KHÁI NIỆM YÊU CẦU HƯỚNG ĐỐI TƯỢNG KHÔNG?

Mục đích của pha yêu cầu là xác định các nhu cầu thực của khách hàng, nghĩa là xác định xem
chức năng của hệ thống cần xây dựng là gì. Pha yêu cầu không đề cập đến việc hệ thống sẽ
được xây dựng như thế nào. Như vậy ở đây không nói đến phương pháp hướng đối tượng hay

phương pháp cổ điển, không có khái niệm "yêu cầu hướng đối tượng". Tài liệu sử dụng (user
manual) trong pha này chỉ nói đến việc người sử dụng cần thực hiện các bước thao tác như thế
nào khi chạy chương trình, chứ không nói đến việc phần mềm được xây dựng như thế nào. Như
vậy trong pha yêu cầu chỉ trả lời câu hỏi là "phần mềm làm gì" , còn cách thức mà phần mềm
được xây dựng thì chưa nói tới. Cho dù trong pha yêu cầu người phát triển phải xây dựng bản
mẫu thì mục đích của họ là bằng cách nào đó xây dựng nhanh bản mẫu thể hiện được các chức
năng mà khách hàng cần. Có thể họ sử dụng một ngôn ngữ cổ điển như C hay Lisp, hoặc thậm
chí ngôn ngữ hỗ trợ hướng đối tượng như C++, nhưng họ chưa quan tâm đến việc thiết kế các
lớp sao cho hợp lý, nghĩa là về thực chất không thể nói bản mẫu được viết theo phương pháp
hướng đối tượng hay không.
2.5. TÓM TẲT CHƯƠNG

Thực hiện pha yêu cầu như thế nào?
Nắm bắt yêu cầu (requirements elicitation):
- Phỏng vấn các thành viên của công ty khách hàng để xác định nhu cầu của họ (determine
their needs).
Phân tích yêu cầu (requirements analysis):
- Viết tài liệu ghi lại các yêu cầu sơ khởi của khách hàng (preliminary requirements).
- Tinh chế lại tài liệu yêu cầu khách hàng (refine the requirements document).
- Xây dựng bản mẫu thể hiện các chức năng cơ bản của phần mềm cần xây dựng.
- Hiệu chỉnh bản mẫu theo sự góp ý của các thành viên của công ty khách hàng được lựa chọn
dùng thử bản mẫu.
2.6. PHA YÊU CẦU: TÌM HIỂU VẤN ĐỀ QUẢN LÝ SÁCH Ở THƯ VIỆN

Mục tiêu của ta là xây dựng phần mềm hỗ trợ công tác quản lý sách ở thư viện. Tìm hiểu
một thư viện bất kỳ, ta có thể gặp hai tình huống:
1. Công tác quản lý sách hoàn toàn được thao tác bằng tay, chưa có chương trình máy tính hỗ
trợ.
2. Thư viện đã có chương trình, nhưng muốn thay thế bằng chương trình tốt hơn, ví dụ như
chương trình cũ chỉ được cài đặt trên một máy, bạn đọc chưa truy cập được từ xa. Và vì vậy

11


PTTK HTTT với UML - Chương 2. Pha xác định yêu cầu

chưa có phân quyền cho các mức truy cập khác nhau. Bạn đọc không thể truy cập thông qua
mạng internet... Chương trình mới cần có các tính năng này.
Phiên bản chương trình 1.0 sẽ được giả thiết là thư viện chưa có chương trình máy tính hỗ trợ
công tác quản lý sách. Chương trình này sẽ chứa những chức năng cơ bản nhất, chủ yếu để các
bạn làm quen với kiến thức đã học. Các bạn có thể phát triển các phiên bản nâng cao hơn.
2.6.1. Nắm bắt yêu cầu
Để nắm bắt được yêu cầu khách hàng, người ta sử dụng một số cách thức như sau: gặp gỡ trao
đổi với khách hàng, phỏng vấn họ, quan sát họ làm việc (nếu khách hàng cho phép có thể ghi
hình những thao tác phức tạp), xem các mẫu báo cáo, gửi các bảng câu hỏi cho một số thành
viên, ... tóm lại là mọi cách có thể. Để có thể nêu ra những câu hỏi hợp lý và hiểu được những
điều khách hàng nói, việc đầu tiên mà nhóm yêu cầu cần làm là tìm hiểu và làm quen với lĩnh
vực ứng dụng của phần mềm. Lưu ý rằng khi tìm hiểu các yêu cầu của khách hàng thì ta phải
có định hướng về phần mềm cần xây dựng.Vì mục tiêu của chúng ta là xây dựng phần mềm hỗ
trợ công việc quản lý sách, do đó ta chỉ tập trung tìm hiểu các vấn đề liên quan. Tuy nhiên
trong giai đoạn nắm bắt yêu cầu có thể ta chưa biết rõ thông tin nào là có ích, nên tạm thời ghi
lại những điều ghi nhận được.
a. Tìm hiểu nghiệp vụ ở thư viện
Chức năng của thư viện là lưu trữ sách và tài liệu và phục vụ bạn đọc. Bạn đọc có thể tự tra
cứu, tìm sách, sau đó thông qua thủ thư mượn sách để đọc tại chỗ hoặc mang về nhà. Vì số
lượng sách và tài liệu rất lớn, lượng bạn đọc cần phục vụ rất đông nên sách và tài liệu phải
được sắp xếp trong kho một cách hợp lý, quy trình mượn trả sách cũng phải được thực hiện
một cách khoa học. Khách hàng của thư viện chính là bạn đọc có thẻ. Những người chưa có thẻ
có thể xin giấy giới thiệu cơ quan đến thư viện xin làm thẻ và được cấp một phiếu đăng ký.
Sau khi điền thông tin cá nhân vào phiếu đúng như giấy giới thiệu cơ quan thì phiếu đăng ký
được thư viện xác nhận và lưu giữ. Độc giả được thư viện cấp một tấm thẻ gọi là thẻ thư viện.

Tùy vào chức danh hay học vị, thẻ có thể sử dụng để mượn sách đọc tại chỗ hoặc đem về nhà.
Thường thư viện có hai phòng: phòng đọc và phòng mượn. Có ba thủ thư làm ba việc khác
nhau: một người kiểm tra thẻ, người thứ hai tiếp nhận sách trả và đưa sách mượn cho độc giả,
người thứ ba lấy sách từ kho và đưa sách vào kho.
Để mượn sách, bạn đọc tìm sách trong các ngăn. Nếu tìm thấy thì ghi lại thông tin sách trong
phiếu mượn và đưa cho thủ thư. Thủ thư trước hết kiểm tra thẻ, nếu thấy hợp lệ thì sẽ căn cứ
vào phiếu mượn sẽ kiểm tra thông tin sách mượn của độc giả trong sổ mượn tương ứng (mỗi
độc giả đã từng mượn sách sẽ có một cuốn sổ được gọi là sổ mượn ghi lại các thông tin về sách
mượn của chính độc giả đó). Số sách mượn tối đa là hai cuốn. Như vậy nếu số sách đang mượn
là i thì i ≤ 2 và chỉ được mượn thêm 2-i cuốn.
Có hai kiểu mượn sách: sách mượn đọc tại chỗ và sách mượn đem về. Không phải bạn đọc nào
cũng có thể mượn sách đem về. Chỉ có những bạn đọc thỏa mãn một số điều kiện nào đó mới
được mượn sách đem về nhà.
Nếu trả sách, số ngày từ ngày mượn gần nhất đến ngày trả được tính. Giả sử số ngày là n. Nếu
n≤15 thì sách được trả bình thường. Nếu n>5 thì bạn đọc phả nộp phạt 1000đồng/cuốn cho
một ngày quá hạn. Như vậy số tiền phạt là (n-15)*1000.
Nếu là sách trả thì thủ thư xóa thông tin sách mượn trong sổ mượn. Nếu là sách mượn thì thủ
thư ghi thông tin sách mượn (mã sách, tên sách, ngày mượn) vào sổ mượn.
Một loại thông tin hết sức quan trọng và bổ ích là các báo biểu mà khách hàng sử dụng. Đây
sẽ là những căn cứ rất tốt để người phát triển hiểu được khách hàng cần gì. Ở các thư viện thì
các báo biểu này có thể là: phiếu đăng ký làm thẻ, thẻ thư viện, thẻ lưu thông tin sách, phiếu
mượn, phiếu trả. Trong số này thì thông tin trên thẻ và phiếu đăng ký làm thể giống nhau, nên
ta chỉ cần xem xét một trong hai. Vậy các biểu mẫu ở một thư viện có các loại như sau:
Phiếu đăng
ký
Số thẻ
Số CMT
Họ tên
Giới tính
Ngày sinh

Địa chỉ
Được mượn
về
Được
chấp

Sach
Mã sách
Tên sách
Tác giả
Nhà
xuất
bản
Phân loại
Số lượng
Nơi lưu trữ

Phiếu
mượn
Số thẻ
Mã thủ thư
Mã sách
Ngày mượn
Ngày trả
Trả rồi?
Ghi chú

Phiếu trả
Số thẻ
Mã thủ thư

Mã sách
Ngày mượn
Ngày trả
Trả rồi?
Ghi chú

Báo cáo
Báo cáo về sách
nhập kho trong
khoảng thời gian.
Báo cáo về
sách mượn về
trong khoảng
thời gian.

12


PTTK HTTT với UML - Chương 2. Pha xác định yêu cầu

Hình 2.1. Các biểu mẫu sử dụng để quản lý sách ở thư viện
b. Tìm hiểu yêu cầu khách hàng về phần mềm quản lý sách
Thư viện muốn rằng các thao tác trên đây được tin học hóa càng nhiều càng tốt. Trước mắt vì
thư viện chưa có phần mềm nào, nên họ muốn có phần mềm hỗ trợ cho công việc quản lý mượn
sách của bạn đọc. Phiên bản đầu tiên này chỉ cài đặt trên máy tính của thư viện. Cũng có thể
dữ liệu được lưu trữ ở máy chủ (server). Ở sảnh ngoài của phòng mượn có thể đặt một máy
tính client trên đó cài đặt chương trình và độc giả có thể tìm kiếm sách sau khi đã đăng nhập và
gõ đúng mật khẩu của mình. Ở máy tính này bạn đọc chỉ truy cập được ở mức chung nhất và
chỉ thực hiện được thao tác tìm kiếm sách và xem (chứ không sửa được) những thông tin liên
quan đến chính mình mà thôi. Chỉ có thủ thư mới được quyền truy cập nhiều chức năng hơn,

như kiểm tra và nhập thông tin về bạn đọc, thông tin mượn sách trả sách, nhập sách mới, thống
kê về số lượng sách...
2.6.2. Phân tích yêu cầu
Từ những thông tin nhận được trong phần nắm bắt yêu cầu ở trên, ta thấy rằng có những thao
tác trước mắt khó có thể tin học hóa. Ví dụ thao tác kiểm tra xem thẻ có hợp lệ không chẳng
hạn. Có rất nhiều nguyên nhân để nghi ngờ hoặc khẳng định thẻ không hợp lệ. Ví dụ ảnh trong
thẻ không giống người mang thẻ, thẻ đã hết hạn hay có dấu hiệu chữ ký giả...Hay thao tác đưa
sách vào kho chẳng hạn, cũng rất khó đưa vào chương trình. Làm sao có thể kiểm tra bằng máy
tính là sách đã được đưa vào kho và đặt đúng nơi quy định? Từ tập yêu cầu trên ta có thể đưa
ra những yêu cầu sau đây của phần mềm:
a. Yêu cầu chức năng
Đối tượng phục vụ của phần mềm là độc giả và thủ thư. Tuy nhiên việc cấp thẻ cho độc giả,
tương ứng với việc cho phép thêm độc giả mới phải do người có thẩm quyền cao hơn quyết
định. Đối với phần mềm thì người chịu trách nhiệm toàn bộ sự hoạt động của phần mềm là
người quản trị, mà ta thường gọi là người quản trị hệ thống. Người quản trị hệ thống thường là
người am hiểu tin học nhất trong cơ quan. Về mặt quyền hành thực tế thì có thể họ không có.
Như vậy thực ra họ thực hiện các thao tác trên phần mềm với sự ủy nhiệm của người có trách
nhiệm thực sự trong cơ quan. Vậy có ba nhóm người sử dụng phần mềm với ba mức phân
quyền từ thấp nhất đến cao nhất là: Bạn đọc, thủ thư và người quản trị. Theo cách thông
thường, đôi khi ta sẽ dùng từ “hệ thống” thay cho từ “phần mềm”. Phần mềm cần có các chức
năng sau:
Với bạn đọc:
- Đăng ký làm thẻ thư viện.
- Tìm kiếm sách (theo chủ đề, theo tên sách, theo tác giả).
- Mượn sách.
- Trả sách.
Với thủ thư:
- Cấp thẻ cho độc giả
- Cho độc giả mượn sách.
- Nhận sách trả từ bạn đọc.

- Nhập sách mới.
- Sửa/xóa thẻ.
- In báo cáo thống kê về sách (sách trong kho, sách muợn, số lượt sử dụng...)
b. Yêu cầu phi chức năng
13


PTTK HTTT với UML - Chương 2. Pha xác định yêu cầu

- Hệ thống hoạt động tin cậy, dữ liệu luôn được cất giữ an toàn.
- Hệ thống bảo đảm được tính bảo mật, người được phân quyền chỉ được sử dụng đúng chức
năng dành cho mình.
- Có giao diện thân thiện với người dùng.
- Chương trình chạy nhanh, đáp ứng kịp thời nhu cầu tìm kiếm của bạn đọc.
Với mục đích minh họa các kiến thức lý thuyết, trong phiên bản này chúng ta tạm bỏ qua nhiều
chức năng quan trọng khác của một phần mềm như phân quyền sử dụng (trong đó người quản
trị có quyền cao nhất, là người được lãnh đạo ủy quyền bảo đảm cho phần mềm hoạt động tốt
và nhập/in ấn các thông tin quan trọng), lưu trữ dữ liệu. Ta cũng bỏ qua nhiều chức năng bình
thường của một chương trình quản lý thư viện, ví dụ tạm thời ta không xét tới vấn đề sách quá
hạn. Mục yêu cầu phi chức năng trên đây chủ yếu được viết ra như một hình mẫu để các bạn
hiểu thế nào là yêu cầu phi chức năng mà thôi.

14


CHƯƠNG 3. TỔNG QUAN VỀ UML VÀ PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG
3.1. SỰ RA ĐỜI CỦA PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG

Phân tích hệ thống theo phương pháp hướng đối tượng (object-oriented analysis, OOA) là một
kỹ thuật đặc tả nửa hình thức. Hiện nay cũng có khá nhiều kỹ thuật phân tích hướng đối tượng,

nhưng về bản chất chúng tương đương nhau. Giống như các kỹ thuật nửa hình thức, phân tích
hướng đối tượng cũng dùng các biểu tượng đồ họa để biểu diễn các đối tượng và các quá trình
xử lý. OOA ra đời vào đầu những năm 90 của thế kỷ trước. Năm 1991, Rumbaugh (New york)
và các cộng sự đưa ra kỹ thuật mô hình hóa hướng đối tượng (object modeling technique,
OMT) được sử dụng cho phân tích và thiết kế hướng đối tượng. Năm 1994 Grady Booch
(Rational, California) cũng phát triển một kỹ thuật OOA mà về bản chất cũng tương tự như của
Rumbaugh. Năm 1994 Rumbaugh gặp Booch tại Rational và hai ông đã cùng nhau phát triển
công cụ gọi là phương pháp luận thống nhất (unified methodology), tuy nhiên hai ông đã nhanh
chóng nhận ra rằng thực chất không phải là phương pháp, mà đơn thuần chỉ là các biểu tượng
dùng để biểu diễn sản phẩm phần mềm hướng đối tượng (HĐT), và đã đổi tên công cụ thành
"ngôn ngữ mô hình hóa thống nhất" (unified modeling language, gọi tắt là UML). Năm 1995
Ivar Jacobson thuộc công ty Ericsson, Thụy điển, người tiên phong trong lĩnh vực công nghệ
phần mềm HĐT, đã gặp Rumbaugh và Booch tại Rational. Jacobson đã nghiên cứu phương
pháp HĐT từ năm 1967 và năm 1992 cho ra đời phương pháp mang tên "công nghệ phần mềm
hướng đối tượng" (object-oriented software engineering). Phiên bản 1.0 của ngôn ngữ UML đã
được xuất bản năm 1997, được coi là công trình chung của ba tác giả Rumbaugh, Jacobson và
Booch. UML hiện nay trở thành chuẩn quốc tế, và đang được hiệu chỉnh và phát triển dưới sự
giám sát của nhóm quản lý hướng đối tượng (Object Management Group), là hiệp hội các công
ty trên phạm vi toàn thế giới có hoạt động tích cực trong phương pháp HĐT.
Jacobson, Booch và Rumbaugh đã cùng nhau xây dựng công cụ được gọi là Rational Unified
Process là quy trình phát triển phần mềm thống nhất dựa trên UML đầu tiên. (Quy trình này
có tên là Rational, là nơi công cụ này ra đời). Một phương pháp quan trọng khác dựa vào UML
là Catalysis do D'Souza và Wills xây dựng năm 1999. UML được chấp nhận rộng rãi trên toàn
thế giới và có thể khẳng định gần như chắc chắn rằng, các phương pháp phát triển phần mềm
trong tương lai cũng sẽ lấy UML làm cơ sở.
Trong tài liệu này UML được dùng để biểu diễn cả phân tích và thiết kế HĐT.
Phân tích hướng đối tượng chính là cách nhìn nhận phần mềm được tạo thành bởi các đối
tượng có mối liên quan với nhau. Vì OOA hay OOD đều sử dụng UML làm công cụ diễn đạt,
do đó trước hết chúng ta sẽ tìm hiểu qua về ngôn ngữ này.
3.2. TỔNG QUAN VỀ NGÔN NGỮ UML

3.2.1. UML là gì?

UML là ngôn ngữ trực quan (tức là sử dụng các biểu tượng để mô tả các vấn đề và công việc)
được dùng trong pha phân tích và pha thiết kế trong quy trình xây dựng một phần mềm hướng
đối tượng. UML là một ngôn ngữ đặc tả nửa hình thức (semiformal specification language,
tuy nhiên cũng có tài liệu cho rằng UML là ngôn ngữ hình thức).
Giống như những ngôn ngữ khác (ngôn ngữ tự nhiên, ngôn ngữ lập trình, ngôn ngữ cho người
khiếm thính...), UML cũng có một tập các phần tử và tập các quy tắc để diễn đạt vấn đề. Tuy
nhiên UML không phải là ngôn ngữ lập trình, nghĩa là bạn không thể sử dụng nó để viết
chương trình. UML cũng không phải là một phương pháp, phương pháp luận hay quy trình
phát triển phần mềm.
Hầu hết các phần tử của UML là các biểu tượng đồ họa như đoạn thẳng, hình chữ nhật, hình
ôvan... Các phần tử này thường có nhãn để chỉ rõ tác dụng của nó. Có thể sử dụng UML để tạo
ra một mô hình có dạng chuẩn dữ liệu (giống như CORBA và XMI DTD). Tuy nhiên cách biễu
diễn bằng hình ảnh của UML vẫn được sử dụng nhiều hơn vì dễ hiểu hơn.


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

3.2.2. Một số khái niệm và thành phần cơ bản của UML
- Mô hình (Model) Theo từ điển tiếng Việt, từ mô hình có hai nghĩa: 1. là vật cùng hình dạng
nhưng làm thu nhỏ lại nhiều lần, dùng làm mô phỏng cấu tạo và hoạt động của một vật khác để
trưng bày và nghiên cứu (ví dụ: mô hình máy bay triển lãm mô hình nhà ở kiểu mới. 2. là hình
thức diễn đạt hết sức gọn theo một ngôn ngữ nào đó các đặc trưng chủ yếu của một đối tượng
để nghiên cứu đối tượng ấy. Mô hình hóa (modeling) là tạo ra mô hình để trên mô hình ấy
nghiên cứu một đối tượng nào đó.
Trong UML từ mô hình được hiểu theo nghĩa thứ hai, nhưng ngôn ngữ sử dụng là ngôn ngữ
trực quan. Tuy nhiên thường thì mô hình không chỉ một biểu diễn cụ thể, mà là tập hợp của một
số biểu diễn, ví dụ mô hình use-case có nghĩa là tập hợp các biểu đồ use-case, mô hình động là

tập hợp các biểu đồ biểu diễn sự thay đổi theo thời gian như biểu đồ trạng thái, biểu đồ tương
tác, biểu đồ hoạt động...
- Hướng nhìn (View): Hướng nhìn (có một số tài liệu gọi là khung nhìn, hay góc nhìn) là một
khái niệm trong UML, chứ không phải là một thành phần biểu diễn có thể nhìn thấy được như
use-case, biểu đồ, lớp... Trong đời thường, khi quan sát một vật thể phức tạp ta phải nhìn từ
nhiều hướng khác nhau. Khi biểu diễn các vật đó trên giấy cũng không thể chỉ biểu diễn trong
một bản vẽ duy nhất mà phải dùng nhiều bản vẽ, mỗi bản vẽ biểu diễn vật từ một hướng nhìn.
Với một phần mềm phức tạp cũng vậy, ta cũng phải quan sát từ những hướng khác nhau. Tuy
nhiên hướng ở đây không còn được hiểu theo nghĩa đen nữa, vì phần mềm không phải là một
vật có thể quan sát một cách rõ ràng như ngôi nhà, chiếc cầu... Hướng nhìn ở đây được hiểu là
các khía cạnh khác nhau cần mô tả, mô hình hoá và trừu tượng hoá của hệ thống. Mỗi hướng
nhìn gồm một số loại biểu đồ khác nhau.
Các hướng nhìn thường sử dụng là:
Use-case view (Hướng nhìn theo trường hợp sử dụng)
Mô tả các chức năng của hệ thống có ý nghĩa cho các tác nhân. Tác nhân ở đay có thể là người sử dụng
hoặc một hệ thống khác. Hướng nhìn use-case mang tính trung tâm, vì nó là cơ sở cho các hướng nhìn
khác.

Logical view (Hướng nhìn logic)
Ngược lại với hướng nhìn use-case, hướng nhìn logic nhìn vào bên trong hệ thống. Nó mô tả các cấu trúc
tĩnh (lớp, đối tượng, quan hệ), cũng như sự tương tác giữa các đối tượng.

Component view (Hướng nhìn theo thành phần)
Deployment view (Hướng nhìn triển khai)
Concurrency view (Hướng nhìn song song)
Trong các hướng nhìn trên đây thì hướng nhìn use-case và hướng nhìn logic đóng vai trò quan
trọng cốt yếu trong phân tích và thiết kế hướng đối tượng.
- Biểu đồ (Diagram): Mỗi biểu đồ là một loại hình vẽ mô tả phần mềm trong một khung nhìn.
Các dạng biểu đồ thường gặp (các biểu đồ hay sử dụng hơn được in đậm):
Use-case diagram (biểu đồ trường hợp sử dụng)

Class diagram (biểu đồ lớp)
Object diagram (biểu đồ đối tượng)
Activity diagram (biểu đồ hoạt động)
State diagram (biểu đồ trạng thái)
Sequence diagram (biểu đồ tuần tự)
Collaboration diagram (biểu đồ tương tác)
Component diagram (biểu đồ thành phần)
Deployment diagram (biểu đồ triển khai)
Concurrency diagram (biểu đồ song song)
Trong các biểu đồ trên thì các biểu đồ quan trọng nhất, đóng vai trò cốt yếu trong phân tích
thiết kế hướng đối tượng là biểu đồ use-case, biểu đồ lớp và biểu đồ tuần tự. Các biểu đồ usecase cho ta bức tranh toàn cảnh về những gì đang xảy ra trong hệ thống (hiện tại hoặc dự định
xây dựng), hay nói một cách khác thì mô hình này cung cấp một cách nhìn tổng thể về những
gì hệ thống sẽ làm và ai sẽ dùng nó.
16


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

Biểu đồ lớp (gồm các lớp cùng mối quan hệ giữa chúng) cho ta một cách nhìn tĩnh về cấu trúc
của các thành phần (lớp) tạo nên phần mềm. Như vậy biểu đồ này đã phần nào cho ta cách nhìn
vào "bên trong" của hệ thống.
Biểu đồ hoạt động mà một dạng đặc biệt của nó là biểu đồ trạng thái cho ta biết những hoạt
động hay trạng thái nào cần phải trải qua để đi từ một hoạt động hoặc trạng thái này đến hoạt
động hoặc trạng thái khác. Ba khái niệm quan trọng được sử dụng trong loại biểu đồ này là
hoạt động (activity), trạng thái (state) và chuyển tiếp (transition). Thực ra hai khái niệm trạng
thái và hoạt động gần như tương đương nhau. Theo một nghĩa nào đó thì có thể xem khái niệm
trạng thái là khái niệm rộng hơn, vì trạng thái cũng có thể thực hiện các hành động. Tuy nhiên
thông thường thì hoạt động phải thực hiện hành động, còn trạng thái ngầm chỉ việc chờ đợi. Ví
dụ máy điện thoại đang ở trạng thái gác máy hay máy bận. Ta cũng có thể nói máy điện thoại
đang ở trạng thái quay số (hoạt động) hay bị ngắt kết nối. Mặc dù rất khó phân biệt hai khái

niệm biểu đồ trạng thái và biểu đồ hoạt động, nhưng người ta vẫn xem xét hai loại biểu đồ này
một cách riêng biệt. Nếu như sự chú ý được tập trung vào các hoạt động thì ta gọi biểu đồ là
biểu đồ hoạt động. Khi đó biểu đồ có thể có các trạng thái nhưng trạng thái chỉ biểu diễn các
điểm chờ trước khi xảy ra hoạt động tiếp theo. Nếu sự chú ý là các trạng thái, thì biểu đồ có
thể chứa các hoạt động, nhưng chỉ nhằm mô tả hàng động xảy ra trước khi chuyển đến một
trạng thái mới.
Nếu như các "điểm dừng" giữa các chuyển tiếp trong biểu đồ hoạt động là hoạt động hoặc
trạng thái thì trong biểu đồ tương tác (interaction diagram) các "điểm dừng" lại là các đối
tượng hoặc tác nhân (tác nhân cũng là đối tượng). Biểu đồ này mô tả các tương tác theo thứ tự
thời gian giữa các đối tượng để thực hiện một công việc gì đó (thường là công việc gắn với
use-case). Có hai loại biểu đồ tương tác là tuần tự (sequence diagram) và cộng tác
(collaboration diagram). Cả hai loại biểu đồ đều chỉ ra trình tự thực hiện các hành động, nhưng
nếu thời gian được nhấn mạnh thì người ta sử dụng biểu đồ tuần tự, còn nếu hành động được
nhấn mạnh thì người ta dùng biểu đồ cộng tác.
- Phần tử mô hình (Model element): Mỗi khái niệm được sử dụng trong biểu đồ được gọi là
phần tử mô hình.
- Gói (package): UML được tổ chức thành các gói, mỗi gói chứa một số biểu đồ.
- Hệ thống con (sub-system): Hệ thống con biểu diễn các bộ phận của hệ thống vật lý, chúng
có thể được tổ chức trong các package.
- Khuôn mẫu (Stereotype): Được sử dụng để định nghĩa một loại phần tử mô hình mới dựa vào
một loại phần tử đã có.
- Đặc tả (Specification) Mô tả chi tiết một phần tử.
- Cơ chế chung (General Merchanism)
- Trang trí (Adornment)
- Ghi chú (Note)
- Giá trị đính kèm (Tagged value).
- Ràng buộc (Constraint)
- Các công cụ (Tools )
3.3. MÔ HÌNH USE-CASE

3.3.1. Biểu đồ use-case

Use-case như tên gọi của nó, là một trường hợp sử dụng của hệ thống, tức là một công việc mà
hệ thống sẽ thực hiện để đạt được kết quả có ý nghĩa đối với một tác nhân nào đó.
Use-case thường bao gồm một chuỗi hành động được mô tả thông qua scenario.
17


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

Tác nhân (actor) ở đây có thể là người hoặc hệ thống tương tác với use-case. Thường actor là
một người sử dụng hệ thống. Trong UML tác nhân thường là một lớp.
Một biểu đồ use-case (use-case diagram) được tạo ra từ các hình ô van (biểu diễn use-case) và
hình người (biểu diễn tác nhân sử dụng user-case). Tên của tác nhân (actor) được đặt phía dưới
hình người, tên của use-case được đặt bên trong hình ô van hoặc phía dưới. Chúng được liên
kết với nhau bằng các đoạn thẳng để chỉ rõ tác nhân nào sử dụng use-case nào. Đoạn thẳng này
có thể có mũi tên ở cuối (phía use-case) nếu ta muốn nhấn mạnh tác nhân tương ứng đóng vai
trò kích hoạt use-case (nếu có nhiều tác nhân liên hệ với use-case). Nhiều tác giả khuyên rằng
không nên dùng đoạn thẳng có mũi tên, vì đoạn thẳng loại này thường biểu diễn luồng thông
tin.
Các biểu đồ use-case (tập hợp các biểu đồ này sẽ được gọi là mô hình use-case) cung cấp một
bức tranh toàn cảnh về những gì đang xảy ra trong hệ thống (hiện tại hay dự định xây
dựng), cụ thể hơn, mô hình use-case trả lời cho câu hỏi: ai (hoặc hệ thống nào) sử dụng phần
mềm và sử dụng để làm gì. Các use-case được Jacobson đưa ra vào năm 1992, ban đầu được
được thực hiện trong công ty Ericsson, Thụy điển. Trong cách tiếp cận của Jacobson thì usecase là điểm bắt đầu trong quá trình xây dựng một hệ thống phần mềm mới. Trong thuật
ngữ UML thì gói use-case là một gói con (sub-package) của gói Behavioural Element (phần tử
hành vi). Nghĩa là nó được sử dụng để xác định hành vi của một thực thể. Use-case không xác
định chi tiết các hành vi được thực hiện như thế nào, chi tiết này sẽ được thảo luận trong các
mô hình khác của quy trình thiết kế hệ thống. Thông thường, cách thực hiện một use-case được
định nghĩa trong một hoặc nhiều mô hình cộng tác (collaboration diagram) nhằm biểu diễn sự

tương tác giữa các đối tượng cùng hoạt động.
Mục đích của biểu đồ use-case:
- Dùng để mô hình hóa các chuỗi hành động của hệ thống.
- Cung cấp một cách nhìn tổng thể về những gì mà hệ thống sẽ làm và ai sẽ dùng nó.
- Đưa ra cơ sở để xác định giao tiếp người-máy của hệ thống.
- Dùng để mô hình hóa các kịch bản (scenario) cho một trường hợp sử dụng.
- Để người dùng cuối có thể hiểu được và có thể giao tiếp với hệ thống ở mức tổng thể.
- Làm cơ sở cho việc phác thảo ra các đặc tả kiểm tra.
Ví dụ về use-case: Trong một hệ thống quản lý công văn của một cơ quan có thể có biểu đồ
use-case như sau:
Xem công
văn
Văn thư

Nếu các use-case là các thành phần của một hệ thống hoặc hệ thống con thì chúng được nhóm
lại trong một hình chữ nhật được đặt tên (chính là tên hệ thống).
Ví dụ: Hệ thống bán hàng
Bán hàng
Bán
hàng
Khác
h

Xem
bảng
giá

Nhân
viên
bán

thống
(con)
hàng

Hìnhhàng
3.1. Các use-case trong một hệ
Tìm Actor bằng cách trả lời câu hỏi:Actor nào thao tác với hệ thống và vai trò của actor đó là
gì?
Xác định Use-case bằng cách trả lời câu hỏi: Một Actor sẽ làm gì để thao tác với hệ thống?
18


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

19


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

Các kiểu kết hợp (association) và quan hệ (relationship) giữa các use-case:
Kết hợp generalization (tổng quát hóa):
+ Kết hợp generalization giữa các use-case. Kết hợp này được biểu diễn bằng một đoạn thẳng
có mũi tên hình tam giác đi từ một use-case đến use-case tổng quát hơn.

Ngưới sử
dụng

Nhập số
liệu

Nhập từ bàn
phím

Nhập từ tệp

Hình 3.2. Kết hợp generalization giữa các use-case
Hình 3.2. chỉ sự kết hợp tổng quát hoá giữa các use-case nhập số liệu với nhập từ bàn phím
và nhập từ tệp. Ở đây nhập số liệu là use-case tổng quát, còn các use-case còn lại là các
trường hợp riêng. Đôi khi một use-case tổng quát có thể không bao giờ tồn tại trong hệ thống
thực. Nó chỉ đóng vai trò chung cho các use-case cụ thể (như trường hợp trên đây). Trong
trường hợp này chúng ta gọi là abstract use-case. Tên của loại use-case này được in nghiêng.
Các use-case không phải là abstract thì được gọi là concret use-case hoặc real use-case.
+ Kết hợp generalization giữa các Actor. Kết hợp này được biểu diễn bằng một đoạn thẳng có
mũi tên hình tam giác đi từ một Actor đến Actor tổng quát hơn, ví dụ:

Nhân viên cơ
quan
Hình
3.3. Kết

Văn thư
hàng
generalization giữa
các Actor

hợp
Hình 3.3. có nghĩa là tác nhân văn thư là trường hợp riêng của tác nhân nhân viên. Điều này
phù hợp với thực tế: văn thư cũng là nhân viên cơ quan, nhưng nhân viên cơ quan có thể không
phải là văn thư. Vậy văn thư là trường hợp riêng của nhân viên.
Trong các ngôn ngữ lập trình hỗ trợ HĐT, generalization thường được cài đặt bằng kỹ thuật kế

thừa (inheritance).
Có 2 loại quan hệ giữa các use-case:
+ Quan hệ include (bao hàm) giữa các use-case. Quan hệ này được biểu diễn bằng mũi tên đứt
nét từ use-case bao hàm đến use-case con. Từ <<include>> được đặt cạnh đoạn thẳng này như
hình 3.4.
Ví dụ:
Bán
hàng
<>>
In hóa đơn

Hình 3.4. Quan hệ include giữa các use-case
Hình 3.4. có nghĩa là: thao tác Bán hàng bao gồm một số thao tác, trong đó có thao tác In hóa
đơn. Điều này có nghĩa là nếu Bán hàng thì phải In hóa đơn nhưng ngược lại thì chưa chắc.
+ Quan hệ extend (mở rộng) giữa các use-case. Quan hệ này cũng được biểu diễn bằng mũi tên
đứt nét từ use-case cần mở rộng đến use-case được mở rộng. Từ <<extend>> được đặt cạnh
20


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

đoạn thẳng này như hình 3.5.
Ví dụ:
Bán
hàng
<>>
Ký hợp
đồng bảo

hành

Hình 3.5. Quan hệ extend giữa các use-case
Hình 3.5. có nghĩa là use-case bán hàng được mở rộng sang use-case ký hợp đồng bảo hành.
Điều này có nghĩa là: trong điều kiện bình thường thì thao tác bán hàng không dẫn tới việc ký
hợp đồng bảo hành. Chỉ trong một số điều kiện nào đó thì mới có sự mở rộng, ví dụ như khi
bán các thiết bị tin học chẳng hạn. Vậy use-case mở rộng (ở hình 3.5 là "ký hợp đồng bảo
hành") có thể coi là một tình huống phát sinh từ use-case được mở rộng (ở trên là "bán hàng").
Tuy nhiên trong cách biểu diễn thì có phần ngược với cách suy nghĩ, cũng giống như
generalization, mũi tên đi từ cái phát sinh đến cái gốc. Để chỉ rõ điều kiện phát sinh, người ta
viết thêm điều kiện trong use-case gốc và gọi phần điều kiện này là các điểm mở rộng
(extension points). Ví dụ với use-case bán hàng có thể viết như sau:
Bán hàng
Các điểm mở
rộng:
Bán các thiết bị
tin học
<>>
Ký hợp
đồng bảo
hành

Hình 3.5b. Quan hệ extend giữa các use-case
Có thể so sánh sự khác biệt giữa generalization, extend và include thông qua hình sau đây:
Giao hàng

Bán hàng

Bán hàng

<>>
>>
Giao ở
cửa hàng

Mang
đến tận
nhà

In hóa đơn

Xuất
hàng

<>>
Nhập hàng
từ nhà
cung cấp

<>>
Hết hàng

<>>

Hình 3.6. So sánh giữa generalization, extend và include.

Ta có thể đọc như sau: Thao tác giao hàng được thực hiện bằng một trong hai cách: giao ở cửa
hàng hoặc mang đến tận nhà. Hai cách giao hàng này có thể có một thao tác chung là "đóng
gói hàng" nằm ở nút giao hàng. Như vậy trong kết hợp generalization thì các thao tác chung
nằm ở nút gốc (nếu có), còn các trường hợp riêng nằm ở các nút con. Thao tác bán hàng được
thực hiện bằng hai thao tác: In hóa đơn và xuất hàng. Thao tác bán hàng trong điều kiện bình
thường thì được thực hiện suôn sẻ. Tuy nhiên có một tình huống phát sinh làm cho thao tác
bán hàng không thực hiện được đó là tình hưống hết hàng. Tình huống hết hàng có thể phát
sinh tình huống nhập hàng từ nhà cung cấp. Vậy thao tác nhập hàng từ nhà cung cấp cũng có
21


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

thể coi là được phát sinh từ thao tác bán hàng.
Chú ý. Trong UML phiên bản 1.1, include và extend được gọi là uses và extends.
Ngoài ra các use-case liên quan đến nhau có thể được nhóm lại thành gói, ví dụ:
Bán hàng

Quản lý kho

Hình 3.7. Các gói chứa use-case

3.3.2. Mô hình use-case
Mô hình use-case là tập hợp các biểu đồ use-case. Biểu đồ use-case lại là tập hợp của một số
use-case cùng các kết hợp và các tác nhân sử dụng chúng. Trong UML, use-case được sử dụng
để nắm bắt các yêu cầu ở mức ngoài về chức năng sử dụng của hệ thống (to capture high
level user-functional requirements of the system). Nên lưu ý là use-case không nên sử dụng để
mô tả các yêu cầu phi chức năng hay "bên trong" các chức năng (tức là cách thực thi các chức
năng), vì use-case trước hết là kỹ thuật phi hình thức và không hoàn toàn chính xác. Tuy nhiên
use-case giúp chúng ta xác định cấu trúc và các yêu cầu chính của sản phẩm phần mềm.

Mô hình use-case đưa ra câu trả lời cho câu hỏi: hệ thống làm gì khi quan sát từ bên ngoài?
Use-case là một thành phần của dự toán và là thành phần nhỏ bé nhất của sản phẩm chuyển
giao. Nếu sản phẩm được tinh chỉnh theo nhiều bước và chuyển giao nhiều lần thì mỗi lần
chuyển giao lại có một mô hình use-case kèm theo. Các use-case không phải là mô hình phân
rã chức năng, cũng không phải nhằm nắm bắt tất cả các yêu cầu của hệ thống. Mô hình usecase chỉ là bước ban đầu. Để diễn tả sâu hơn cấu trúc và cách hoạt động của hệ thống, ta cần
đến các kỹ thuật mô hình hóa khác. Mô hình đối tượng (Object model) mô tả cấu trúc tĩnh của
hệ thống và quan hệ giữa các lớp. Mô hình động gồm các biểu đồ như biểu đồ tuần tự, biểu đồ
trạng thái, sẽ mô tả chi tiết cách ứng xử của hệ thống, nhằm trả lời cho câu hỏi: hệ thống thực
hiện các chức năng như thế nào. Mô hình quy trình công việc (business process model) sẽ cho
biết trình tự các công việc được thực hiện như thế nào, cả phần tin học hóa và phần thủ công.
Use-case không phải là kỹ thuật bắt buộc trong mô hình hóa hướng đối tượng. Và cũng
không có lý do cơ bản nào để ngăn cản việc ứng dụng nó như một công cụ ban đầu của
phương pháp phát triển có cấu trúc. Tuy nhiên chúng không được dùng trong phân tích có cấu
trúc vì những người sáng tạo ra chúng đang tập trung sự chú ý vào việc phát triển các phương
pháp hướng đối tượng.

3.3.3. Xây dựng mô hình use-case như thế nào?
Như đã nói đến trong phần trước, theo thuật ngữ của UML thì người hoặc hệ thống sử dụng
phần mềm mà ta đang xem xét được gọi là tác nhân của phần mềm đó, còn use-case như tên gọi
của nó, là một trường hợp sử dụng của phần mềm liên quan đến tác nhân nào đó.
Để xây dựng mô hình này, ta cần trả lời hai câu hỏi:
1) Ai (hoặc hệ thống nào) trực tiếp sử dụng phần mềm? Câu trả lời sẽ đưa ra danh sách các tác
nhân.
Từ danh sách các tác nhân đầu tiên ta chọn ra tác nhân quan trọng nhất, sau đó là tác nhân
quan trọng thứ nhì,... Với mỗi tác nhân ta nêu câu hỏi:
2) Tác nhân muốn làm gì với hệ thống (tức là phần mềm)? Câu trả lời sẽ là các use-case.
Ban đầu mỗi tác nhân cùng các use-case liên quan sẽ là một biểu đồ. Tuy nhiên sau đó ta cần
xem xét các use-case của các tác nhân khác nhau. Nếu ta thấy có nhiều điểm chung thì nên
dùng một use-case cho các tác nhân. Ví dụ use-case mượn sách của tác nhân bạn đọc cũng
tương tự như use-case cho mượn sách của thủ thư nên ta gộp hai use-case này thành một và gọi

22


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

là use-case mượn sách.
Nếu trình bày một cách có hệ thống thì để xác định một use-case đơn giản (a simple use-case
recipe) ta cần thực hiện 8 bước như sau:
Bước 1. Nhận diện xem ai sẽ là người trực tiếp sử dụng hệ thống, ví dụ người sẽ ngồi vào bàn
phím và gõ vào bàn phím để sử dụng chương trình. Họ là các tác nhân. Tác nhân có thể là
một hệ thống khác, để tìm tác nhân loại này ta nêu câu hỏi: hệ thống nào tương tác với hệ
thống này?
Bước 2. Hãy chọn một phần tử trong các tác nhân. Ví dụ đó là thư ký nhận đơn đặt hàng (sales
order clerk), mà ta sẽ gọi đơn giản là người bán hàng.
Bước 3. Hãy xác định xem tác nhân này muốn làm gì với hệ thống. Những việc tác nhân này
muốn thực hiện trên hệ thống sẽ trở thành các use-case.
Bước 4. Với mỗi use-case hãy xác định dòng công việc (course) thường xuyên nhất khi actor
sử dụng hệ thống (the most usual course when the actor is using the system).
Bước 5. Mô tả dòng công việc cơ sở này trong phần diễn tả use-case (the description for the
use-case).
Hãy mô tả theo cách "tác nhân làm cái gì đó, hệ thống sẽ làm cái gì đó...", tuy nhiên chỉ giữ
ở mức bên ngoài. Bạn hãy chỉ mô tả những điều hệ thống làm mà tác nhân nhận biết được và
ngược lại, những điều tác nhân làm mà hệ thống nhận biết được. Trước mắt chưa cần quan
tâm đến các quan hệ đặc biệt như <<extend>> hay <<include>>.
Diễn tả (description)
Người bán hàng nhập họ của khách hàng. Hệ thống
Nhập
hiện trên màn hình tất cả các khách hàng có cùng
đơn
họ. Người bán hàng chọn một người trong số này.

đặt
Các thông tin chi tiết về khách hàng này được hiện
hàng
ra trên màn hình.
Với mỗi mặt hàng khách muốn đặt mua, người bán
hàng nhập các thông tin chi tiết về mặt hàng trong
một dòng. Khi tất cả các mặt hàng đã được
nhập
Diễn
tả thì
hệ thống xác nhận đơn đạt hàng (confirm).Người bán hàng nhập họ của khách
hàng. Hệ thống hiện trên màn hình tất
Kiểm tra
cả các khách hàng có cùng họ. Người
Người
tiền nợ của
bán hàng chọn một người trong số này.
bán hàng
khách hàng
Các thông tin chi tiết về khách hàng này
được hiện ra trên màn hình.
Đồng thời, hệ thống hiện trên màn hình
lịch trình trả nợ của khách trong sáu
tháng
Hình 3.17. Diễn tả dòng công việc
cho gần
mỗi đây
use-case

23

PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

Bước 6. Nếu bạn cảm thấy vừa lòng với các dòng công việc cơ bản thì hãy xem xét đến các
khả năng khác và bổ sung các khả năng này.
Diễn tả (description)
Người bán hàng nhập họ của khách hàng. Hệ thống
Nhập
hiện trên màn hình tất cả các khách hàng có cùng
đơn
họ. Người bán hàng chọn một người trong số này.
đặt
Các thông tin chi tiết về khách hàng này được hiện
hàng
ra trên màn hình.
Với mỗi mặt hàng khách muốn đặt mua, người bán
hàng nhập các thông tin chi tiết về mặt hàng trong
một dòng. Khi tất cả các mặt hàng đã được
nhập
Diễn
tả thì
hệ thống xác nhận đơn đạt hàng (confirm).Người bán hàng nhập họ của khách
hàng. Hệ thống hiện trên màn hình tất
Kiểm tra
cả các khách hàng có cùng họ. Người
Người
tiền nợ của
bán hàng chọn một người trong số này.
bán hàng

khách hàng
Các thông tin chi tiết về khách hàng này
được hiện ra trên màn hình.
Đồng thời, hệ thống hiện trên màn hình
lịch <trình trả nợ của khách trong sáu
tháng gần
>> đây
Diễn tả
Nếu trong use-case "Kiểm tra tiền nợ
khách hàng" nếu hệ thống không tìm
thấy khách hàng nào có họ như vừa
nhập thì báo lỗi và cho phép người sử
dụng nhập lại họ khác và lại tiếp tục tìm
kiếm.

Nhập lại do
không tìm
thấy khách
hàng

Hình 3.18. Bổ sung thêm use-case ứng với khả năng khác
Bước 7. Đọc lại các diễn tả và đối chiếu so sánh. Nếu phát hiện thấy có phần chung thì nên
tách ra thành các use-case cho các dòng công việc chung.
Diễn tả
Sử dụng use-case "Hiên thông
tin..." để tìm và hiện ra thông
tin chi tiết về khách hàng.
Với mỗi mặt hàng khách muốn
đặt mua, người bán hàng nhập

các thông tin chi tiết về mặt
hàng trong một dòng. Khi tất cả
các mặt hàng đã được nhập thì
hệ thống xác nhận đơn đạt
hàng (confirm).

Nhập
đơn
đặt
hàng

<de>>
Hiện thông
tin chi tiết
về khách
hàng

<de>>
Người
bán hàng

Kiểm tra
tiền nợ của
khách hàng

Diễn tả
Sử dụng use-case "Hiện
thông tin..." để tìm và

hiện ra thông tin chi tiết
về khách hàng.
Đồng thời, hệ thống hiện
trên màn hình lịch trình
trả nợ của khách trong
sáu tháng gần đây

<>>
Nhập lại vì
không tìm
thấy khách
hàng

Diễn tả
Sử dụng use-case "Hiện thông tin..." để
tìm và hiện ra thông tin chi tiết về khách
hàng. Nếu hệ thống không tìm thấy
khách hàng nào có họ như vừa nhập thì
báo lỗi và cho phép người sử dụng nhập
lại họ khác và lại tiếp tục tìm kiếm.

24


PTTK HTTT với UML - Chương 3. Tổng quan về UML và phương pháp hướng đối tượng

Hình 3.19. Tách dòng công việc chung thành use-case dùng chung
(Ta thấy rằng use-case "Nhập lại vì không tìm thấy khách hàng" được mở rộng từ use-case
"Hiện thông tin chi tiết về khách hàng", có nghĩa là use-case " Hiện thông tin... " làm nảy sinh

use-case " Nhập lại vì không tìm thấy...").
Bước 8. Lặp lại các bước từ 2 đến 7 cho tất cả các tác nhân.
Trên đây là cách khởi đầu tốt cho quá trình mô hình hóa use-case. Tuy nhiên một lỗi thường
gặp là quá nhiều use-case được đưa vào mô hình. Vậy bước tiếp theo chúng ta xem xét vấn đề:
cái gì không nên đưa vào mô hình use-case?

3.3.4. Cái gì không nên đưa vào mô hình use-case?
Trong quá trình xây dựng mô hình use-case, có thể còn có một số thông tin cần thiết và chi tiết
mà bạn cần biểu diễn. Đừng vội đưa vào mô hình use-case. Tốt hơn là bạn nên sử dụng một kỹ
thuật mô hình hóa khác thích hợp hơn. Nếu bạn muốn mô tả thông tin về mối quan hệ đặc biệt
giữa các đối tượng, ví dụ một đơn đặt hàng có thể chứa một hoặc nhiều dòng thông tin về các
mặt hàng, hay khách hàng ngoài họ ra còn có tên riêng, địa chỉ và các thông tin khác... thì tốt
hơn là bạn nên dùng mô hình lớp. Hoặc nếu bạn muốn mô tả rằng danh sách khách hàng có thể
chọn từ hộp ListBox thì bạn nên dùng biểu đồ tuần tự hay một bản mẫu GUI hoặc cả hai...
Bạn cũng cần thận trong trong việc bổ sung thêm các use-case theo các quan hệ include và
extend để tránh tình trạng đi quá xa, làm cho mô hình trở nên quá phức tạp. Chỉ nên phát triển
ở mức vừa phải, trong phạm vi mục đích của mô hình use-case là: mô tả các chức năng sử
dụng của phần mềm ở mức cao, tức là mức bên ngoài, làm cơ sở cho việc ước lượng chi phí
và chuyển giao.

3.3.5. Cân chỉnh lại mô hình use-case
Sự cân chỉnh mô hình use-case chính là sự lựa chọn một mô hình phù hợp giữa trường hợp quá
phức tạp (vì chứa quá nhiều use-case dùng chung và use-case mở rộng) và trường hợp đơn giản
nhất là không chứa các quan hệ mở rộng hoặc sử dụng giữa các use-case. Xuất phát từ mô hình
đơn giản ban đầu, bạn bổ sung dần các use-case bằng cách trả lời câu hỏi: đưa thêm use-case
này vào thì có ích hơn cho mô hình không? Tuy nhiên bạn phải lưu ý rằng không thể mô hình
hóa tất cả bằng mô hình use-case. Trong nhiều trường hợp, bên cạnh mô hình use-case đơn
giản, nếu có thêm scenario hoặc một vài loại biểu đồ nữa thì mô hình sẽ dễ hiểu hơn, như ví dụ
về phần mềm điều khiển hoạt động thang máy sau đây.

3.3.6. Mô tả use-case (use-case description)
Rõ ràng từ biểu đồ use-case ta mới có ý niệm rất sơ lược về chức năng của mỗi use-case thông
qua tên của nó. Vì vậy đối với mỗi use-case người ta thêm phần mô tả bên dưới. Mô tả use-case
khôngcó bất kỳ quy tắc cú pháp nào cả, bạn có thể mô tả bằng bất kỳ dạng nào bạn thích. Tất
nhiên nếu bạn làm việc trong một công ty nào đó thì bạn phải tuân thủ những cách thức mà
công ty đó quy ước. Có hai cách thông dụng nhất được sử dụng để mô tả use-case là:
• Viết thành một đoạn văn (như trong các hình 3.15-3.17).
• Liệt kê thành hai cột, một cột là hoạt động của tác nhân, cột còn lại là đáp ứng của hệ
thống.
Có thể thấy rằng cách thứ hai giống như một vở kịch có hai vai: tác nhân và hệ thống, vì vậy
người ta gọi cách trình bày này là kịch bản (scenario). Vì cách trình bày theo cột có phần bất
tiện, vì sự đáp ứng của hệ thống thường chiếm phần nhiều hơn, làm cho hai cột không cân đối,
vì vậy người ta thường trình bày theo chiều dọc như khi người ta trình bày một vở kịch thông
thường (xem ví dụ trong mục 3.3.6 sau đây).

25