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

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ệcnà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 q

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ầnmề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ọchó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ạtnhâ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ươngtrì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ìnhquả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 đồngnhấ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áchhà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ầnmề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êucầ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ềmlà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ựchiệ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áchhà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 theothuậ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íchhợ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 tacho 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ôngviệ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ầnmề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ì.

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ìnhmá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ể chiaquá trình phát triển phần mềm thành 3 giai đoạn: 1955 - 1970, 1971 - 1985, 1986 đến nay Tấtnhiê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ặthà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ôimuố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ậttoá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ệntrướ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ệcphâ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ệcnà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 đờigiai đ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ươngtrì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

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 nayphươ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àycà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ếumộ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 quantrọ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ầnmề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ếuxả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ầntắ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ạytrê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ốnsử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ũngnhư 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 ápdụ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ựngphầ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ộtngô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ườicù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ốiliê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 đạtcá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àngcá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 chongườ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ìnhbày chung cho các sản phẩm phần mềm

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 raphầ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ềmthì 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 phacò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ầnmề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ầnmề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 địnhyê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 để

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 đề (conceptexploration) 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êucầ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ảnphẩ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êncủ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ủakhá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ầnmề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ựcthư 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ácthuậ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ểucá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âydự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ầntì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:

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ưachắ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êuthì 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 đưacho 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áccầ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áccô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ỹ Tuynhiê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ỏithí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ácthô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ôngviệ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àmviệ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ữngthô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ữngngườ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ìmkiế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ôitrườ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ànphí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ôngviệ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ăngthì 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 trongbả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ấtlượ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ếpcá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áchoặ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ạicá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ómchuyể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.

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ọngnhấ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ảnmẫ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êmbớ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áchhà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ườiphá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ầnlà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êngặ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ếubiể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 xemchứ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ảnmẫ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ứcnă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ậmchí 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áclớ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áphướ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ọ (determinetheir 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ọndù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

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 quamạ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ácbạ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ể ghihì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ànhviê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êntrong 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 ghilạ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ự tracứ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ệnmộ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ácnhau: 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 trongphiế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áchmượ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àocũ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 chomộ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ếumượ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:

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.

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ữ

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ượnsá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áytí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ênquan đế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 thaotá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ẳnghạ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 trongthẻ 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 đưasá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áytí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áchnhiệ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ânquyề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ôngthườ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ứcnă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ả)

- 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

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ứcnă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ềuchứ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ảntrị 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ìnhthườ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

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íchhướ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ủaRumbaugh Năm 1994 Rumbaugh gặp Booch tại Rational và hai ông đã cùng nhau phát triểncông cụ gọi là phương pháp luận thống nhất (unified methodology), tuy nhiên hai ông đã nhanhchó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ượngdù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ươngphá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ềmhướ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ànthế 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ềmtrong 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ườikhiế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

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ươngtá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 trongmộ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 Tuynhiê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ò quantrọ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 đồ case, biểu đồ lớp và biểu đồ tuần tự Các biểu đồ

use-case 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ó.

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ệmtrạ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ênthô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áiniệ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àymộ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ộttrạ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)

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

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 vaitrò 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ằngkhô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ôngtin

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ì

use-case 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:

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ómlạ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

Hình 3.1 Các use-case trong một hệ thống (con)

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?

Bán hàng

Bán hàng Xem bảng giá

Khác h hàng

Nhân viên bán hàng

Xem công văn Văn thư

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

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

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ốngthự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ụ:

Hình 3.3 Kết hợp generalization giữa các Actor 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ụ:

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

Văn thư hàng

Nhân viên cơ quan

Bán hàng

In hóa đơn

<<include

>>

Ngưới sử dụng

Nhập số liệu

Nhập từ bàn phím Nhập từ tệp

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

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:

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:

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ó

Bán hàng

Ký hợp đồng bảo hành

<<extend

>>

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ết hàng

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ụ:

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ứcnă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ênuse-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ểngiao 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

use-case 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ươngphá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ânquan 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ầnxem 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

Quản lý khoBán hàng

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 quantâm đến các quan hệ đặc biệt như <<extend>> hay <<include>>

Hình 3.17 Diễn tả dòng công việc cho mỗi use-case

Người

bán hàng

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

Diễn tả (description)

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 cả các khách hàng có cùng

họ Người bán hàng chọn một người trong số này

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.

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

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

Diễn tả

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

cả các khách hàng có cùng họ Người bán hàng chọn một người trong số này 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

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

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ả (description)

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 cả các khách hàng có cùng

họ Người bán hàng chọn một người trong số này

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.

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

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

Diễn tả

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

cả các khách hàng có cùng họ Người bán hàng chọn một người trong số này 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

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

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

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

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

<<extend

>>

Hiện thông tin chi tiết

về khách hàng

<<inclu de>>

<<inclu de>>

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 sinhuse-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ườnggặ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ệtgiữ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ácmặ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ốthơ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ảnnhấ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 đơngiả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ôngqua 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-casekhô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ấtnhiê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ậyngườ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ấttiệ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ôngthường (xem ví dụ trong mục 3.3.6 sau đây)

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

3.3.7 Xây dựng mô hình use-case cho bài toán điều khiển hoạt động thang máy Giả sử cần xây dựng phần mềm điều khiển n thang máy trong ngôi nhà có m tầng.

Các thang máy hoạt động theo cách thức như sau:

1 Mỗi thang máy có m nút bấm, mỗi nút tương ứng với một tầng Các nút được đánh sốbằng số tầng tương ứng Khi một nút được nhấn thì nó sẽ sáng lên và thang máy sẽ đượcchuyển đến tầng tương ứng Khi thang máy đến được tầng cần thiết thì thì đèn nút bấm

sẽ tắt Ví dụ khi nút số 5 được nhấn thì nó sáng lên, thang máy sẽ dịch chuyển đến tầng

số 5 và khi đến được tầng số 5 thì đèn ở nút số 5 cũng tắt

2 Mỗi tầng, trừ tầng đầu tiên và tầng trên cùng, đều có 2 nút bấm: một nút yêu cầu thangmáy đi lên (up-elevator) và nút còn lại yêu cầu thang máy đi xuống(down-elevator) Cácnút này sẽ bật sáng mỗi khi được nhấn

Bây giờ chúng ta sẽ xây dựng biểu đồ use-case cho vấn đề này theo các bước như gợi ý ở trên

Trước hết ta trả lời câu hỏi: ai trực tiếp sử dụng thang máy? Câu trả lời là: người muốn đi tới

các tầng bằng thang máy, mà ta gọi đơn giản là người sử dụng Tiếp theo là trả lời câu hỏi:

người sử dụng làm gì? Câu trả lời là "người sử dụng nhấn nút" Ta có biểu đồ đơn giản đầu

tiên như sau:

Hình 3.20 Biểu đồ use-case đầu tiên cho bài toán thang máy

Tuy nhiên ta thấy rằng thao tác nhấn nút chưa phải là thao tác có thể thực hiện vì có hai loại nút: nút thang máy và nút tầng Do đó ta dùng kết hợp generalization để tách use-case này

thành hai use-case như hình sau:

Hình 3.21 Biểu đồ use-case sau bước tinh chỉnh thứ hai

Tuy nhiên cũng là trả lời câu hỏi "người sử dụng làm gì?", ta cũng có thể trả lời là "người sửdụng nhấn nút thang máy hoặc nút tầng Và từ đây ta có biểu đồ use-case tương đương vớibiểu đồ trên nhưng hình thức biểu diễn có khác:

Hình 3.22 Use-case cho vấn đề thang máyMỗi use-case mô tả một chức năng của phần mềm cần xây dựng Nó cung cấp mô tả chung vềchức năng; còn các scenario lại là các thể hiện cụ thể của use-case, cũng giống như các đối

Thang máy

Nhấn nút thang máy Nhấn nút ở mỗi tầng Người

sử dụng

Ngưới sử dụng

Nhấn nút

Nhấn nút thang

Nhấn nút hàng

Ngưới sử dụng

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

tượng là các thể hiện của lớp vậy Scenario cho ta hiểu rõ hơn về use-case, vì nó chỉ rõ use-case

xử lý các tình huống như thế nào khi nhận được các chỉ thị từ các tác nhân Các use-case cho

ta bức tranh toàn cảnh về các tác động qua lại giữa các lớp của phần mềm với nhau và với những tác nhân sử dụng phần mềm Các scenario chính là tập hợp các tác động cụ thể giữa các đối tượng và những người sử dụng

Chỉ có các khả năng tương tác giữa người sử dụng và các lớp là người sử dụng bấm vào núttrên thang máy để thang máy chuyển động hoặc bấm vào nút ở tầng nhà để yêu cầu thang máydừng lại khi đi đến tầng đó Bằng việc phối hợp các thao tác này ta có thể đưa ra rất nhiềuscenario Sau đây là một scenario chuẩn và một scenario ngoại lệ (UML cung cấp hai loại biểu

đồ là tuần tự và tương tác để biểu diễn các scenario Tuy nhiên các biểu đồ này thích hợp hơncho giai đoạn thiết kế)

Scenario chuẩn (normal scenario):

1 Người sử dụng A đang ở tầng 3 và muốn lên tầng 7 Anh ta nhấn vào nút ↑ (up-elevator)

để gọi thang máy đến

2 Nút up-floor bật sáng

3 Thang máy đến tầng 3 và mang theo người sử dụng B B vào thang máy ở tầng 1 và đãnhấn nút bên trong thang máy để lên tầng 9

4 Nút ↑ tắt

5 Cửa thang máy mở ra

6 Bắt đầu thời gian chờ đợi (thang máy ở trạng thái đứng yên)

A bước vào thang máy

7 A nhấn vào nút số 7 trong thang máy

8 Nút số 7 trong thang máy sáng lên

9 Cửa thang máy đóng lại

10 Thang máy chuyển đến tầng 7

11 Nút số 7 trong thang máy tắt

12 Cửa thang máy mở ra (để A bước ra ngoài)

13 Bắt đầu thời gian chờ đợi

A bước ra khỏi thang máy

14 Cửa thang máy đóng lại sau một khoảng thời gian chờ

15 Thang máy tiếp tục chuyển động lên tầng 9 mang theo B

Sau đây là scenario ngoại lệ: A muốn xuống tầng 1 nhưng lại nhấn nhầm vào nút ↑,

Scenario ngoại lệ (an exception scenario):

1 Người sử dụng A đang ở tầng 3 và muốn xuống tầng 1 Anh ta nhấn nhầm vào nút ↑

2 Nút ↑ bật sáng

3 Thang máy đến tầng 3 và mang theo người sử dụng B B vào thang máy ở tầng 1 và đãnhấn nút bên trong thang máy để lên tầng 9

4 Nút ↑ tắt

5 Cửa thang máy mở ra

6 Bắt đầu thời gian chờ đợi

A bước vào thang máy

7 A nhấn vào nút số 1 trong thang máy

8 Nút số 1 trong thang máy sáng lên

9 Cửa thang máy đóng lại

10 Thang máy chuyển đến tầng 9

11 Nút số 9 trong thang máy tắt

12 Cửa thang máy mở ra (để B bước ra ngoài)

13 Bắt đầu thời gian chờ đợi

B bước ra khỏi thang máy

14 Cửa thang máy đóng lại sau một khoảng thời gian chờ

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

15 Thang máy chuyển động xuống tầng 1 mang theo A

Ngoài các scenario trên đây có thể đưa ra nhiều scenario nữa để giúp cho nhóm phát triển hiểu

rõ hơn cách hoạt động của hệ thống cần mô hình hóa Các thông tin này cần thiết cho bước tiếptheo: xây dựng các lớp và mô hình lớp Scenario sẽ còn được dùng trong bước thiết kế

của các phần tử thuộc tập hợp Định nghĩa UML về lớp theo nguyên văn tiếng Anh là: "class is

a description of a set of objects that share the same attributes, operations, methods, relationships, and semantics" Như vậy nếu chỉ lưu ý đến những từ quan trọng thì có thể đưa ra

định nghĩa lớp như sau:

Định nghĩa 1

Lớp là khái niệm được dùng để mô tả các đối tượng có cùng loại thuộc tính và hành vi

Như thế, phần lớn các tài liệu đã bỏ qua từ "mô tả", là một từ mà theo chúng tôi là rất quan

trọng Lớp không phải là tập hợp các đối tượng, mà là sự mô tả của nhóm các đối tượng có

chung một số đặc trưng nào đó mà thôi Như vậy lớp khách hàng không phải là tập hợp cáckhách hàng, mà là sự mô tả các khách hàng Như thế các đặc trưng chung của các đối tượng sẽđược mô tả trong lớp Lớp đóng vai trò như một cái khung hay như một tờ khai chưa có thôngtin cụ thể Ví dụ với các khách hàng của một cửa hàng nào đó thì người ta cần lưu lại cácthuộc tính như họ tên, giới tính, số điện thoại; và ta biết rằng những hành động họ thường làm

là tìm kiếm hàng, mua hàng Với một khách hàng cụ thể thì các thuộc tính và hành vi đượcxác định, và ta gọi khách hàng cụ thể là đối tượng thuộc lớp khách hàng Người ta cũng thườngnói đối tượng là thể hiện của lớp Như thế, theo chúng tôi có thể đưa ra định nghĩa rõ hơn vềlớp như sau:

Định nghĩa 2

Lớp là tập hợp các thuộc tính và phương thức có liên quan với nhau Lớp được đặt tên và

thường được dùng để mô tả các đối tượng có cùng loại thuộc tính và hành vi.

Định nghĩa này mở ra khả năng cho phép chúng ta xây dựng thêm các lớp mới trong phần mềm

để cho việc phân tích thiết kế được đơn giản hơn Các lớp mới này có thể chỉ đơn giản là mộtnhóm các dữ liệu và hàm có liên quan với nhau trong phần mềm và không nhất thiết phải cómột lớp các đối tượng tương ứng trong thực tế

Người ta cũng thường dùng cách nói trực quan: Các lớp là những phần tử hay các "vật" tạonên phần mềm

Trong biểu đồ UML lớp được biểu diễn bằng hình chữ nhật Tên lớp thường được viết đậm, các

từ được viết liền nhau nhưng chữ đầu từ được viết hoa, ví dụ BankAccount (không viết là Bank

Account) Thể hiện của lớp, tức là các đối tượng, được quy ước là viết có gạch chân, theo

mẫu: <tên đối tượng>:<tên lớp tương ứng> , :<tên lớp> hoặc <tên đối tượng> Ví dụaDoc:Document, :Document, aDoc

Biểu đồ lớp bao gồm các lớp cùng với các ký hiệu khác biểu diễn mối quan hệ giữa chúng

Biểu đồ lớp mô tả các kiểu đối tượng trong hệ thống và các mối quan hệ tĩnh giữa chúng (Classdiagrams describe the types of objects in the system and the various kinds of staticrelationships that exist among them)

Biểu đồ lớp cho ta biết những thành phần tạo nên phần mềm và mối liên quan giữa chúng Biểu

đồ này chỉ cho biết mối liên quan tĩnh giữa các thành phần Để thấy được mối tương quan động

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

giữa chúng ta còn cần tới các biểu đồ khác như biểu đồ hoạt động, biểu đồ trạng thái, biểu đồtương tác (tuần tự và cộng tác)

Các loại kết hợp giữa các lớp: aggregation, composition và generalization

Như vậy các kết hợp aggregation và composition đều là biểu diễn cấu trúc whole-part giữa hai

lớp Sự khác biệt là: part trong aggregation có thể tồn tại độc lập, còn trong composition thì part là thành phần cùng gắn kết với whole (coincident lifetime)

Ký hiệu generalization (tổng quát hóa hay kế thừa), ví dụ:

có nghĩa là thư ký là trường hợp riêng của nhân viên, hay nhân viên là tổng quát hóa của thư

ký Nếu nhân viên có thuộc tính gì thì thư ký cũng có các thuộc tính đó Tuy nhiên thư ký có

thể có các thuộc tính mà nhân viên không có

Dạng tối thiểu của biểu diễn lớp là một hình chữ nhật trong đó có tên lớp Ví dụ về biểu đồ lớp:

Hình 3.8 Các biểu đồ lớp

Giải thích các ký hiệu:

Lớp HangMua được dẫn xuất từ lớp Hang, hay lớp HangMua là lớp thừa kế của lớp Hang.

Quan hệ này là quan hệ tổng quát hóa (generalization) Ta cũng gọi lớp Hang là lớp cha, lớp HangMua là lớp con.

No (No là phần nợ, Co là phần có của tài khoản) là thành phần của TaiKhoan, tuy nhiên nó phụ thuộc vào TaiKhoan Nếu phía TaiKhoan bị xóa thì phía No cũng bị xoá theo (Co cũng vậy).

Quan hệ này là composition, có thể coi là trường hợp riêng của aggregation Khi biễu diễn lớp,

Hành

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

ngoài thành phần bắt buộc là tên lớp, còn có thể có các thuộc tính và các phương thức, ví dụ:

Hang

TenHangGiaHangNhap()Xem()

3.4.2 Xây dựng mô hình lớp (class modeling) như thế nào?

Mô hình lớp đóng vai trò trụ cột trong phân tích và thiết kế hướng đối tượng Thành phần của

mô hình lớp là các biểu đồ lớp, trong đó biểu diễn các lớp cùng các mối quan hệ giữa chúng.

Mô hình đối tượng chính là thể hiện của mô hình lớp, trong đó bao gồm các biểu đồ đối tượng

là thể hiện của các biểu đồ lớp Các biểu đồ lớp được phân làm hai loại Trong bước phân tích

được gọi là biểu đồ lớp khái niệm (conceptual class diagram).Trong bước này các lớp cùng

các thuộc tính sẽ được đưa ra và biểu diễn theo biểu đồ thực thể-quan hệ (entity-relationshipdiagram) Hiện tại chỉ xác định các thuộc tính của các lớp Các phương thức (các hàm thànhphần) của các lớp sẽ được đưa vào trong giai đoạn thiết kế (cũng có tài liệu cho rằng cần nêu

cả phương thức, nhưng chỉ cần theo ngôn ngữ của người sử dụng) Biểu đồ lớp trong giai đoạn

thiết kế được gọi là biểu đồ lớp thiết kế (design class diagram)

Một trong những phương pháp xác định các lớp là dẫn xuất chúng từ các use-case Điều này

có nghĩa là các nhà phát triển cần xem xét kỹ các kịch bản, cả trường hợp chuẩn và ngoại lệ, từ

đó rút ra những thành phần tham gia trong các use-case Ví dụ trong bài toán thang máy thì từ

các scenario trên đây ta có thể rút ra các lớp ứng cử viên là: các nút thang máy, các nút ở mỗitầng, các thang máy, các cửa, và các dụng cụ đo thời gian (timers) Như chúng ta sẽ thấy, cáclớp ứng cử viên này khá gần với các lớp thực được đưa ra trong quá trình xây dựng mô hìnhlớp Tuy nhiên trong thực tế có rất nhiều scenario và do đó số lớp ứng cử viên có thể rất lớn.Đối với những người phát triển ít kinh nghiệm thì việc lựa chọn ra các lớp thích hợp nhất làđiều khá khó khăn Thường thì việc thêm một lớp dễ hơn là loại bỏ một lớp từ tập đã có

Một cách tiếp cận khác trong việc lựa chọn các lớp khá hiệu quả là sử dụng các thẻ CRC(class-responsibility-collaboration) Tuy nhiên đối với những kỹ sư phần mềm chưa quen lĩnh

vực này thì nên dùng kỹ thuật trích danh từ (noun extraction) sẽ được giới thiệu sau đây.

3.4.3 Kỹ thuật trích danh từ (noun extraction)

Kỹ thuật trích danh từ được thực hiện trong ba bước sau đây:

Bước 1 Phát biểu bài toán một cách gọn và cô đọng (concise problem definition) Mô tả

vấn đề càng ngắn càng tốt, và nên gói gọn trong một câu Ví dụ với bài toán thang máy có thể

mô tả như sau:

Các nút trong thang máy và trên mỗi tầng điều khiển hoạt động của n thang máy trong ngôi nhà có m tầng.

Bước 2 Diễn tả hoạt động của hệ thống (hay còn gọi là chiến lược phi hình thức, informal strategy) Mô tả hoạt động của hệ thống một cách ngắn gọn, tốt nhất là trong một đoạn văn

(paragraph) Đoạn này thường bao gồm phần phát biểu ngắn gọn bài toán rồi bổ sung thêm cácđiều kiện ràng buộc Ví dụ với vấn đề thang máy có thể diễn tả như sau:

Các nút trong thang máy và trên mỗi tầng điều khiển hoạt động của n thang máy trong ngôi nhà có m tầng Các nút bật sáng mỗi khi được nhấn để yêu cầu thang máy dừng lại ở một tầng nào đó Sự bật sáng kết thúc khi yêu cầu được thực hiện xong Khi không có yêu cầu thì thang máy dừng ở tầng và cửa của nó đóng.

Bước 3 Đánh dấu các danh từ Bây giờ ta đánh dấu các danh từ mô tả các vật tồn tại trong

thực tế

Các nút trong thang máy và trên mỗi tầng điều khiển hoạt động của n thang máy trong

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

ngôi nhà có m tầng Các nút bật sáng mỗi khi được nhấn để yêu cầu thang máy dừng lại ở

một tầng nào đó Sự bật sáng kết thúc khi yêu cầu được thực hiện xong Khi không có yêu cầu thì thang máy dừng ở tầng và cửa của nó đóng.

Như vậy có các danh từ nút, thang máy, tầng, ngôi nhà và cửa Tuy nhiên trong các danh từnày thì có một số nằm ngoài phạm vi quan tâm của bài toán, ví dụ: tầng, ngôi nhà, cửa Vậy chỉ

còn lại hai danh từ là thang máy và nút Vậy ta sẽ có hai lớp là thang máy và nút Theo cách

đặt tên do UML quy định thì tên lớp được viết hoa chữ đầu, không chứa dấu cách Tuy nhiênchúng ta sẽ thực hiện điều này khi đặt tên lớp trong lập trình, còn bây giờ ta sẽ viết bằng tiếng

Việt có dấu cho dễ hiểu Tuy nhiên trong thực tế thì nút được phân làm hai loại: nút thang

máy và nút tầng nhà Hai loại nút này tương ứng với các lớp con dẫn xuất từ lớp nút Vì

thang máy hoạt động theo các thông tin gửi từ các nút nên ta có biểu đồ lớp đầu tiên như sau:

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.23 Biểu đồ lớp đầu tiênTrong thực tế thì các nút không gửi thông tin trực tiếp đến các thang máy, mà gửi đến một bộđiều khiển thang máy Bộ này sẽ xử lý và quyết định thang máy nào sẽ đáp ứng yêu cầu Do đó

ta có sơ đồ lớp trong bước tinh chỉnh thứ hai như sau:

Hình 3.24 Biểu đồ lớp ở bước tinh chỉnh thứ haiBây giờ ta xem xét các thuộc tính có thể của mỗi lớp Dựa vào scenario ta có thể thấy rằng

thuộc tính có thể thấy ngay của lớp nút là chiếu sáng hay không, thuộc tính của thang máy là cửa thang máy mở hay đóng Các thuộc tính này chỉ nhận hai giá trị có hoặc không, vậy chúng

có kiểu logic, hay còn được gọi là kiểu boolean Các lớp khác hiện tại chưa thấy thuộc tính nàođược bộc lộ rõ ràng Ta có bảng sau đây, với tên lớp được đặt lại để sau này tiện cho việc lậptrình:

Trên đây chỉ là mô hình lớp trong vài bước đầu tiên Mô hình này sẽ còn được sửa đổi cho phùhợp trong các pha sau này Sự sửa đổi có thể thực hiện cho đến pha tích hợp

Ghi chú Trong thực tế, việc áp dụng kỹ thuật trích danh từ đôi khi không dễ dàng Bằng cách

này ta đưa ra được một danh sách các danh từ là ứng cử viên cho lớp, nhưng việc lọc ra các

Nút

Nút thang máy

Nút tầng

Thang máy

Trao đổi thông tin

với

2m-2 m

Trao đổi thông tin

với

1 1

Nút

Nút thang máy

Nút tầng

ĐK thang máy

Trao đổi thông tin

với

2m-2 m

Trao đổi thông tin

với

Thang máy

Điều khiển n 1

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

danh từ thực sự cần thiết thì lại là vấn đề khó Lấy ví dụ ta cần viết chương trình quản lý bán

hàng chẳng hạn Ta thấy ngay là có thể rút ra các danh từ cần xây dựng lớp là khách hàng, nhân viên bán hàng, hóa đơn Có thể có nhiều danh từ khác, nhưng có vẻ đây là ba danh từ

không thể loại bỏ Có lẽ vì thế trong hầu hết các chương trình mẫu về bán hàng đều có lớp

khách hàng Tuy nhiên nếu ở một siêu thị lớn, khách hàng rất nhiều và thường xuyên thay đổi

thì việc quản lý khách hàng trở nên không cần thiết Mặc dầu khi khách hàng mua hàng ta vẫncần lưu thông tin về họ như họ tên, địa chỉ, số điện thoại để khi có sự cố có thể liên hệ giảiquyết, nhưng rõ ràng thông tin về mỗi khách hàng chỉ có ý nghĩa khi gắn với hóa đơn Trong

trường hợp này ta chỉ nên xem thông tin về khách hàng là các thuộc tính của hóa đơn mà thôi.

Vấn đề sẽ khác đi ở một cơ sở bán buôn Rõ ràng ở đây người ta thuờng xuuyên liên hệ vớimỗi khách hàng Mỗi lần trả tiền có thể ta lại phải tính cả các hóa đơn còn nợ trước đây; hayvới khách hàng mua nhiều có thể giảm giá, khuyến mại (kể cả các lần mua trước) Rõ ràngtrong trường hợp này vai trò của khách hàng đã vượt ra ngoài hóa đơn cụ thể, và như vậy

không thể xem chỉ là thuộc tính của hóa đơn, mà nên xem là một lớp độc lập Căn cứ vào điều

này, chúng tôi phát triển kỹ thuật trích danh từ theo cách như sau:

• Bằng kỹ thuật trích danh từ, ta có được danh sách các danh từ là ứng cử viên tạo lớp, tagọi danh sách này là danh sách (1)

• Tiếp theo ta tìm hiểu nghiệp vụ liên quan đến phần mềm, mà cách tốt nhất là tìm hiểu

các biểu mẫu về lĩnh vực ứng dụng của phần mềm Mỗi biểu mẫu sẽ là các lớp đầu tiên

được chọn Sau đó ta xác định xem danh từ nào trong danh sách (1) xuất hiện trong

biểu mẫu và với vai trò gì Nếu vai trò của danh từ chỉ gắn với biểu mẫu thì ta chỉ để

danh từ đó như là thuộc tính của lớp biểu mẫu tương ứng; còn nếu vai trò của nó vượt ra bên ngoài biểu mẫu thì nên để là lớp.

Lưu ý là danh từ có thể xuất hiện trong biểu mẫu dưới dạng ẩn Ví dụ biểu mẫu "Phiếu đăng

ký làm thẻ thư viện" có dạng như ở hình bên

Ta thấy rằng không có danh từ "Bạn đọc", nhưng

thực ra danh từ này xuất hiện rất nhiều:

Số thẻ bạn đọc, Họ tên bạn đọc,

Và ở thư viện thì thông tin về bạn đọc rất cần quản

lý nên ta tạo lớp BanDoc tương ứng

3.4.4 Kỹ thuật thẻ CRC

Trong nhiều năm, các thẻ CRC (class-responsibility-collaboration card) đã được sử dụng trongpha phân tích hướng đối tượng Đối với mỗi lớp, nhóm phát triển điền vào các thông tin như:tên lớp, các chức năng của lớp (responsibility) và danh sách các lớp gọi đến các chức năng củalớp này (collaboration) Cách tiếp cận này về sau đã được mở rộng Trước hết thẻ CRC baohàm một cách tường minh các thuộct tính và các phương thức của lớp, chứ không chỉ là cácchức năng được mô tả bằng ngôn ngữ tự nhiên Công nghệ cũng thay đổi Thay vì sử dụng cácthẻ, một số công ty phần mềm ghi tên các lớp trên các mẫu giấy ghi chú (Post-it note) rồi dịchchuyển vòng quanh trên bảng trắng; các đoạn thẳng được vẽ trên bảng nối các mẫu giấy đểbiểu thị sự tương tác Ngày nay toàn bộ cách làm này đã được tự động hóa: các công cụ CASEnhư System Architect có chứa các module có thể tạo ra và cập nhật các thẻ CRC trên màn hình.Điểm mạnh của thẻ CRC là, khi làm việc theo nhóm thì nhờ sự trao đổi giữa các thành viên cóthể phát hiện ra những điều còn thiếu hay không chính xác trong các lớp Mối quan hệ giữa cáclớp cũng được làm rõ Điểm mạnh nhất của kỹ thuật này là có thể phân phát các thẻ cho cácthành viên, mỗi thành viên sẽ xem xét kỹ hơn các lớp mà họ chịu trách nhiệm, đồng thời có thểxem xét và có ý kiến đóng góp cho các lớp khác Nhờ sự làm việc trong sự trao đổi hợp tác nhưvậy, biểu đồ lớp sẽ được đầy đủ và chính xác hơn

Điểm yếu của kỹ thuật CRC là không có phương pháp tốt để nhận diện các lớp, nếu các thànhviên không am hiểu nhiều về lĩnh vực ứng dụng tương ứng Tuy nhiên, nếu bằng cách nào đócác nhà phát triển đã xác định được khá nhiều lớp thì thông qua sự cộng tác, trao đổi thẻ CRC

là công cụ tuyệt vời để bảo đảm rằng mô hình lớp đưa ra là đầy đủ và chính xác

Phiếu đăng ký

Số thẻ

Số CMT

Họ tên Giới tính Ngày sinh Địa chỉ Được mượn về

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