Chương IV. Tổng quan về ngôn ngữ mô hình hóa thống nhất uml và phương pháp hướng đối tượng pot

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 diagr

Trang 1

CHƯƠNG IV – TỔNG QUAN VỀ NGÔN NGỮ MÔ HÌNH HÓA THỐNG NHẤT UML VÀ PHƯƠNG PHÁP HƯỚNG ĐỐI TƯỢNG.

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-orientedanalysis, 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 đốitượ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 đốitượ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ũngphá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ùngnhau phát triển công cụ gọi là phương pháp luận thống nhất (unifiedmethodology), tuy nhiên hai ông đã nhanh chóng nhận ra rằng thực chấtkhông phải là phương pháp, mà đơn thuần chỉ là các biểu tượng dùng để biểudiễ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, người tiên phong trong lĩnh vực côngnghệ 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ươngpháp mang tên "công nghệ phần mềm hướng đối tượng" (object-orientedsoftware engineering) Phiên bản 1.0 của ngôn ngữ UML đã được xuất bảnnă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ế, đang được hiệu chỉnh,phát triển dưới sự giám sát của nhóm quản lý hướng đối tượng (ObjectManagement 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ựatrê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 doD'Souza và Wills xây dựng năm 1999 UML được chấp nhận rộng rãi trêntoàn thế giới và có thể khẳng định gần như chắc chắn rằng, các phương phápphát triển phần mềm trong tương lai cũng sẽ lấy UML làm cơ sở

62

Trang 2

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ạothà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

2 Tổng quan về ngôn ngữ mô hình hoá thống nhất UML

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ônngữ đặ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ậpcác quy tắc để diễn đạt vấn đề Tuy nhiên UML không phải là ngôn ngữ lậptrình, nghĩa là bạn không thể sử dụng nó để viết chương trình UML cũngkhông phải là một phương pháp, phương pháp luận hay quy trình phát triểnphầ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ụngcủ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 ảnhcủa UML vẫn được sử dụng nhiều vì dễ hiểu hơn

2.2 Một số khái niệm và thành phần cơ bản của UML

2.2.1 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 để môphỏng cấu tạo và hoạt động của một vật khác với mục đích 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 đặctrư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ượngnào đó

Trang 3

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ộtbiể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

2.2.2 Hướng nhìn

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 quansá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ễncá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ớimộ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ácnhau 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ôinhà, 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 ởđây có thể là người sử dụng hoặc một hệ thống khác Hướng nhìn use-casemang 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ưtương tác động 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ìnlogic đóng vai trò quan trọng cốt yếu trong phân tích và thiết kế hướng đốitượng

64

Trang 4

2.2.3 Biểu đồ (Diagram)

Mỗi biểu đồ là một loại hình vẽ mô tả phần mềm trong mộtkhung 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ì hai loại biểu đồ quan trọng nhất là biểu đồ

use-case và biểu đồ lớp Các biểu đồ use-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óimộ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ó

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ậybiể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 tabiế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ệmquan trọng được sử dụng trong loại biểu đồ này là hoạt động (activity), trạngthá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ể xemkhá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ệncá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ạngthá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ạngthái quay số (hoạt động) hay bị ngắt kết nối Mặc dù rất khó phân biệt haikhái niệm biểu đồ trạng thái và biểu đồ hoạt động, nhưng người ta vẫn xemxét hai loại biểu đồ này một cách riêng biệt Nếu như sự chú ý được tập trungvào các hoạt động thì ta gọi biểu đồ là biểu đồ hoạt động Khi đó biểu đồ có

Trang 5

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 khixả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 khichuyể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à đốitượng) Biểu đồ này mô tả các tương tác theo thứ tự thời gian giữa các đốitượ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áchà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ộngtác

2.2.4 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

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

2.2.6 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

2.2.7 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ựavào một loại phần tử đã có

2.2.8 Đặc tả (Specification) Mô tả chi tiết một phần tử.

Đặc tả (Specification): mô tả chi tiết một phần tử

2.2.9 Cơ chế chung (General Merchanism)

Cơ chế chung (General Merchanism)

66

Trang 6

2.2.10 Trang trí (Adornment)

Trang trí (Adornment)

2.2.11 Ghi chú (Note)

Ghi chú (Note)

2.2.12 Giá trị đính kèm (Tagged value).

Giá trị đính kèm (Tagged value)

Tác nhân (actor) ở đây có thể là người hoặc hệ thống tương tác với case Thường actor là một người sử dụng hệ thống Trong UML, tác nhânthường là một lớp

use-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 nhaubằng các đoạn thẳng để chỉ rõ tác nhân nào sử dụng use-case nào

Các biểu đồ use-case (sẽ được gọi là mô hình use-case) cung cấp một bứctranh toàn cảnh về những gì đang xảy ra trong hệ thống (hiện tại hay dự địnhxây dựng), cụ thể hơn, mô hình use-case cho ta câu 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ểmbắt đầu trong quá trình xây dựng một hệ thống phần mềm mới Trong thuậtngữ UML thì gói use-case là một gói con (sub-package) của gói Behavioural

Trang 7

Element (phần tử hành vi) Nghĩa là nó được sử dụng để xác định hành vi củamột thực thể Use-case không xác định chi tiết các hành vi được thực hiệnnhư thế nào, chi tiết này sẽ được thảo luận trong các mô hình khác của quytrình thiết kế hệ thống Thông thường, cách thực hiện một use-case được địnhnghĩa trong một hoặc nhiều mô hình cộng tác (collaboration diagram) nhằmbiể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 conthì 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

Hình 4.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à vaitrò của actor đó là gì?

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

Trang 8

Xác định Use-case bằng cách trả lời câu hỏi: một Actor sẽ làm gì để thaotác với hệ thố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ễnbằng một đoạn thẳng có mũi tên hình tam giác đi từ một use-case đếnuse-case tổng quát hơn

Hình 4.2 Kết hợp generalization giữa các use-caseHình 4.2 chỉ sự kết hợp tổng quát hoá giữa các use-case nhập số liệu vớinhậ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ổngquá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ợpnày chúng ta gọi là abstract use-case Tên của loại use-case này được innghiêng Các use-case không phải là abstract thì được gọi là concret use-casehoặ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ằngmột đoạn thẳng có mũi tên hình tam giác đi từ một Actor đến Actor tổngquát hơn, ví dụ:

Hình 4.3 Kết hợp generalization giữa các ActorHình 4.3 có nghĩa: tác nhân văn thư là trường hợp riêng của tác nhânnhâ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ườnghợp riêng của nhân viên

Người sử dụng

Nhập số liệu

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

Văn thư Nhân viên cơ quan

Trang 9

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ểudiễ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 7.4

Ví dụ:

Hình 4.5 Quan hệ extend giữa các use-caseHình 4.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ọcchẳng hạn Vậy use-case mở rộng (ở Hình 4.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ánhà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ỉ

70

Bán hàng

In hóa đơn

<<include>>

Bán hàng

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

<<extend>>

Trang 10

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ọiphầ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 4.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 4.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 tronghai 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ựchiệ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ềukiện bình thường thì được thực hiện suôn sẻ Tuy nhiên, có một tình huốngphát sinh làm cho thao tác bán hàng không thực hiện được đó là tình hưốnghế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ó thể coi là đượcphá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

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

Trang 11

Ngoài ra các use-case liên quan đến nhau có thể được nhóm lại thành gói,

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ìnhthứ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 quansá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ầnnhỏ bé nhất của sản phẩm chuyển giao Nếu sản phẩm được tinh chỉnh theonhiề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ứcnă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 đốitượng (Object model) mô tả cấu trúc tĩnh của hệ thống và quan hệ giữa cáclớ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ốngthực hiện các chức năng như thế nào Mô hình quy trình công việc (businessprocess 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 đốitượ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

72

Quản lý khoBán hàng

Trang 12

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 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ácnhâ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 đồ Tuynhiê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 tathấ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 chomượn sách của thủ thư nên ta gộp hai use-case này thành một và gọi 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ẽ gõ vào bàn phím để sử dụng chương trình Họ là các tác nhân Tácnhâ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

Trang 13

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ốnglà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>>.

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

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

74

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

Người bán

hàng

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 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à tiếp tục tìm kiếm

<<extend>>

Trang 14

Hình 4.9 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

Hình 4.10 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 Tuynhiên một lỗi thường gặp là quá nhiều use-case được đưa vào mô hình Vậybước tiếp theo chúng ta xem xét vấn đề: cái gì không nên đưa vào mô hìnhuse-case?

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ìnhuse-case Tốt hơn, ta nên sử dụng một kỹ thuật mô hình hóa khác thích hợphơn Nếu 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ặthà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

Người bán

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 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.Đồng

thời, hệ thống hiện trên màn

hình lịch trình trả nợ của khách

hàng 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à tiếp tục tìm kiếm

<<extend>>

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

<<include

>>

<<include

>>

Trang 15

khác thì tốt hơn nên dùng mô hình lớp Hoặc nếu chúng ta muốn mô tả rằngdanh sách khách hàng có thể chọn từ hộp ListBox thì nên dùng biểu đồ tuần

tự hay một bản mẫu GUI hoặc cả hai

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ênquá 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.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ìnhphù hợp giữa trường hợp quá phức tạp (vì chứa quá nhiều use-case dùngchung và use-case mở rộng), và trường hợp đơn giản nhất là không chứa cácquan hệ mở rộng hoặc sử dụng giữa các use-case Xuất phát từ mô hình đơngiản ban đầu, ta bổ sung dần các use-case bằng cách trả lời câu hỏi: đưa thêmuse-case này vào thì có ích hơn cho mô hình không? Tuy nhiê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ườnghợp, bên cạnh mô hình use-case đơn giản, nếu có thêm scenario hoặc một vàiloại biểu đồ nữa thì mô hình sẽ dễ hiểu hơn, như ví dụ về phần mềm điềukhiển hoạt động thang máy sau đây

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ứcnăng của mỗi use-case thông qua tên của nó Vì vậy, đối với mỗi use-casengười ta thêm phần mô tả bên dưới Mô tả use-case không có bất kỳ quy tắc

cú pháp nào cả, có thể mô tả bằng bất kỳ dạng nào Tất nhiên nếu ta làm việctrong một công ty nào đó thì 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

• 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, sự đáp ứng của hệ thống thườngchiếm phần nhiều hơn, làm cho hai cột không cân đối, do đó người ta thườngtrình bày theo chiều dọc như khi trình bày một vở kịch thông thường (xem ví

dụ trong mục 3.7 sau đây)

76

Trang 16

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ácnú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ẽ được chuyể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 đượcnhấn thì nó sáng lên, thang máy sẽ dịch chuyển đến tầng số 5 và khi đến đượctầ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ộtnút yêu cầu thang má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ác nú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ácbướ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 thangmá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ênnhư sau:

Hình 4.11 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ợpgeneralization để tách use-case này thành hai use-case như hình sau:

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

Nhấn nút hµng Người sử dụng

Người sử dụng

Nhấn nút

Nhấn nút thang máy Nhấn nút tầng

Trang 17

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ới biểu đồ trên nhưng hình thức biểu diễn cókhác:

Hình 4.13 Use-case cho vấn đề thang máy

Mỗi use-case mô tả một chức năng của phần mềm cần xây dựng Nó cungcấ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ủause-case, cũng giống như các đối tượng là các thể hiện của lớp vậy Scenariocho 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ứctranh 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áctá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út trên thang máy để thang máy chuyển động hoặc bấm vàonút ở tầng nhà để yêu cầu thang máy dừng lại khi đi đến tầng đó Bằng việcphối hợp các thao tác này ta có thể đưa ra rất nhiều scenario Sau đây là mộtscenario 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àythích hợp hơn cho giai đoạn thiết kế)