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

Chia sẻ: Trịnh Thị Thoa | Ngày: | Loại File: DOC | Số trang:38

Thêm vào BST

Báo xấu

198
lượt xem 39
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Phân tích hệ thống theo phương pháp hướng đối tượng (objectoriented analysis, OOA) là một kỹ thuật đặc tả nửa hình thức. Hiện nay cũng có khá nhiều kỹ thuật phân tích hướng đối tượng, nhưng về bản chất chúng tương đương nhau. Giống như các kỹ thuật nửa hình thức, phân tích hướng đối tượng cũng dùng các biểu tượng đồ họa để biểu diễn các đối tượng và các quá trình xử lý.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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

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- oriented analysis, OOA) là một kỹ thuật đặc tả nửa hình thức. Hiện nay cũng có khá nhiều kỹ thuật phân tích hướng đối tượng, nhưng về bản chất chúng tương đương nhau. Giống như các kỹ thuật nửa hình thức, phân tích hướng đối tượng cũng dùng các biểu tượng đồ họa để biểu diễn các đối tượng và các quá trình xử lý. OOA ra đời vào đầu những năm 90 của thế kỷ trước. Năm 1991, Rumbaugh (New york) và các c ộng sự đưa ra kỹ thuật mô hình hóa hướng đối tượng (object modeling technique, OMT), được sử dụng cho phân tích và thiết kế hướng đối tượng. Năm 1994 Grady Booch (Rational, California) cũng phát triển một kỹ thuật OOA mà về bản chất cũng tương tự như của Rumbaugh. Năm 1994 Rumbaugh gặp Booch tại Rational và hai ông đã cùng nhau phát triển công cụ gọi là phương pháp luận thống nhất (unified methodology), tuy nhiên hai ông đã nhanh chóng nhận ra rằng thực chất không phải là phương pháp, mà đơn thuần chỉ là các biểu tượng dùng để biểu diễn sản phẩm phần mềm hướng đối tượng (HĐT), và đã đổi tên công cụ thành "ngôn ngữ mô hình hóa thống nhất" (unified modeling language, gọi tắt là UML). Năm 1995 Ivar Jacobson, người tiên phong trong lĩnh vực công nghệ phần mềm HĐT, đã gặp Rumbaugh và Booch tại Rational. Jacobson đã nghiên cứu phương pháp HĐT từ năm 1967 và năm 1992 cho ra đời phương pháp mang tên "công nghệ phần mềm hướng đối tượng" (object-oriented software engineering). Phiên bản 1.0 của ngôn ngữ UML đã được xuất bản năm 1997, được coi là công trình chung của ba tác giả Rumbaugh, Jacobson và Booch. UML hiện nay trở thành chuẩn quốc tế, đ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 (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 62
toàn thế giới và có thể khẳng định gần như chắc chắn rằng, các phương pháp phát triển phần mềm trong tương lai cũng sẽ lấy UML làm cơ sở. Trong tài liệu này UML được dùng để biểu diễn cả phân tích và thiết kế HĐT. Phân tích hướng đối tượng chính là cách nhìn nhận phần mềm được tạo thành bởi các đối tượng có mối liên quan với nhau. Vì OOA hay OOD đều sử dụng UML làm công cụ diễn đạt, do đó trước hết chúng ta sẽ tìm hiểu qua về ngôn ngữ này. 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ôn ngữ đặc tả nửa hình thức (semiformal specification language, tuy nhiên cũng có tài liệu cho rằng UML là ngôn ngữ hình thức). Giống như những ngôn ngữ khác (ngôn ngữ tự nhiên, ngôn ngữ lập trình, ngôn ngữ cho người khiếm thính...), UML cũng có một tập các phần tử và tập các quy tắc để diễn đạt vấn đề. Tuy nhiên UML không phải là ngôn ngữ lập trình, nghĩa là bạn không thể sử dụng nó để viết chương trình. UML cũng không phải là một phương pháp, phương pháp luận hay quy trình phát triển phần mềm. Hầu hết các phần tử của UML là các biểu tượng đồ họa như đoạn thẳng, hình chữ nhật, hình ôvan... Các phần tử này thường có nhãn để chỉ rõ tác dụng của nó. Có thể sử dụng UML để tạo ra một mô hình có dạng chuẩn dữ liệu (giống như CORBA và XMI DTD). Tuy nhiên cách bi ễu diễn bằng hình ảnh của UML vẫn được sử dụng nhiều 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 đặc trưng chủ yếu của một đối tượng để nghiên cứu đối tượng ấy. Mô hình 63
hóa (modeling) là tạo ra mô hình để trên mô hình ấy nghiên cứu một đối tượng nào đó. Trong UML từ mô hình được hiểu theo nghĩa thứ hai, nhưng ngôn ngữ sử dụng là ngôn ngữ trực quan. Tuy nhiên, thường thì mô hình không chỉ một biểu diễn cụ thể, mà là tập hợp của một số biểu diễn, ví dụ mô hình use-case có nghĩa là tập hợp các biểu đồ use-case, mô hình động là tập hợp các biểu đồ biểu diễn sự thay đổi theo thời gian như biểu đồ trạng thái, biểu đồ tương tác, biểu đồ hoạt động... 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 quan sát một vật thể phức tạp ta phải nhìn từ nhiều hướng khác nhau. Khi biểu diễn các vật đó trên giấy cũng không thể chỉ biểu diễn trong một bản vẽ duy nhất mà phải dùng nhiều bản vẽ, mỗi bản vẽ biểu diễn vật từ một hướng nhìn. Với một phần mềm phức tạp cũng vậy, ta cũng phải quan sát từ những hướng khác nhau. Tuy nhiên hướng ở đây không còn được hiểu theo nghĩa đen nữa, vì phần mềm không phải là một vật có thể quan sát một cách rõ ràng như ngôi nhà, chiếc cầu... Hướng nhìn ở đây được hiểu là các khía cạnh khác nhau cần mô tả, mô hình hoá và trừu tượng hoá của hệ thống. Mỗi hướng nhìn gồm một số loại biểu đồ khác nhau. Các hướng nhìn thường sử dụng là: Use-case view (Hướng nhìn theo trường hợp sử dụng). Mô tả các chức năng của hệ thống có ý nghĩa cho các tác nhân. Tác nhân ở đây 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ư 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ìn logic đóng vai trò quan trọng cốt yếu trong phân tích và thiết kế hướng đối tượng. 64
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ộ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ì 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-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ó. Biểu đồ lớp (gồm các lớp cùng mối quan hệ giữa chúng) cho ta một cách nhìn tĩnh về cấu trúc của các thành phần (lớp) tạo nên phần mềm. Như vậy biểu đồ này đã phần nào cho ta cách nhìn vào "bên trong" c ủa hệ thống. Biểu đồ hoạt động mà một dạng đặc biệt của nó là biểu đồ trạng thái cho ta biết những hoạt động hay trạng thái nào cần phải trải qua để đi từ một hoạt động hoặc trạng thái này đến hoạt động hoặc trạng thái khác. Ba khái niệm quan trọng được sử dụng trong loại biểu đồ này là hoạt động (activity), trạng thái (state) và chuyển tiếp (transition). Thực ra, hai khái niệm trạng thái và hoạt động gần như tương đương nhau. Theo một nghĩa nào đó thì có thể xem khái niệm trạng thái là khái niệm rộng hơn, vì trạng thái cũng có thể thực hiện các hành động. Tuy nhiên, thông thường thì hoạt động phải thực hiện hành động, còn trạng thái ngầm chỉ việc chờ đợi. Ví dụ máy điện thoại đang ở trạng thái gác máy hay máy bận. Ta cũng có thể 65
nói máy điện thoại đang ở trạng thái quay số (hoạt động) hay bị ngắt kết nối. Mặc dù rất khó phân biệt hai khái niệm biểu đồ trạng thái và biểu đồ hoạt động, nhưng người ta vẫn xem xét hai loại biểu đồ này một cách riêng biệt. Nếu như sự chú ý được tập trung vào các hoạt động thì ta gọi biểu đồ là biểu đồ hoạt động. Khi đó biểu đồ có thể có các trạng thái nhưng trạng thái chỉ biểu diễn các điểm chờ trước khi xảy ra hoạt động tiếp theo. Nếu sự chú ý là các trạng thái, thì biểu đồ có thể chứa các hoạt động, nhưng chỉ nhằm mô tả hàng động xảy ra trước khi chuyển đến một trạng thái mới. Nếu như các "điểm dừng" giữa các chuyển tiếp trong biểu đồ hoạt động là hoạt động hoặc trạng thái thì trong biểu đồ tương tác (interaction diagram) các "điểm dừng" lại là các đối tượng hoặc tác nhân (tác nhân cũng là đối tượng). Biểu đồ này mô tả các tương tác theo thứ tự thời gian giữa các đối tượng để thực hiện một công việc gì đó (thường là công việc gắn với use-case). Có hai loại biểu đồ tương tác là tuần tự (sequence diagram) và cộng tác (collaboration diagram). Cả hai loại biểu đồ đều chỉ ra trình tự thực hiện các hành động, nhưng nếu thời gian được nhấn mạnh thì người ta sử dụng biểu đồ tuần tự, còn nếu hành động được nhấn mạnh thì người ta dùng biểu đồ cộng tác. 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ựa và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ử. 66
Đặ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) 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). 2.2.13. Ràng buộc (Constraint) Ràng buộc (Constraint) 2.2.14. Các công cụ (Tools) Các công cụ (Tools ) 3. Mô hình use-case 3.1. Biểu đồ use-case Use-case nh ư tên gọi của nó, là một trường hợp sử dụng của hệ thống, nó mô tả một chuỗi hành động 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 đó. 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. Các biểu đồ use-case (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 cho ta câu trả lời cho câu 67
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: Xem công văn Văn thư Nếu các use-case là các thành ph ần của một hệ thống hoặc hệ thống con thì chúng được nhóm lại trong một hình chữ nhật được đặt tên (chính là tên hệ thống). Ví dụ: Hệ thống bán hàng Bán hàng Bán hàng 68 Xem bảng giá Khách Nhân viên hà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à 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? 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. Nhập số liệu Người sử dụng Nhập từ bàn phím Nhập từ tệp Hình 4.2. Kết hợp generalization giữa các use-case Hì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ới nhập từ bàn phím và nhập từ tệp. Ở đây nhập số liệu là use-case tổng quát, còn các use-case còn lại là các trường hợp riêng. Đôi khi một use-case tổng quát có thể không bao giờ tồn tại trong hệ thống thực. Nó chỉ đóng vai trò chung cho các use-case cụ thể (như trường hợp trên đây). Trong trường hợp này chúng ta gọi là abstract use-case. Tên của loại use-case này được in nghiêng. Các use-case không phải là abstract thì được gọi là concret use-case hoặc real use-case. + Kết hợp generalization giữa các Actor: kết hợp này được biểu diễn bằng một đoạn thẳng có mũi tên hình tam giác đi từ một Actor đến Actor tổng quát hơn, ví dụ: 69
Nhân viên cơ quan Văn thư Hình 4.3. Kết hợp generalization giữa các Actor Hì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â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ừ được đặt cạnh đoạn thẳng này như hình 7.4. Ví dụ: Bán hàng In hóa đơn Hình 4.4. Quan hệ include giữa các use-case Hình 4.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ừ được đặt cạnh đoạn thẳng này như hình 7.5. Ví dụ: Bán hàng Ký hợp đồng bảo hành 70
Hình 4.5. Quan hệ extend giữa các use-case Hì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ọc chẳ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án hàng"). Tuy nhiên, trong cách biểu diễn thì có phần ngược với cách suy nghĩ, cũng giống như generalization, mũi tên đi từ cái phát sinh đến cái gốc. Để chỉ rõ điều kiện phát sinh, người ta viết thêm điều kiện trong use-case gốc và gọi phần điều kiện này là các điểm mở rộng (extension points). Ví dụ với use-case bán hàng có thể viết như sau: Bán hàng Các điểm mở rộng: Bán các thiết bị tin học Ký hợp đồng bảo hành Hình 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: Giao hàng Bán hàng Bán hàng Giao ở cửa Mang đến In hóa đơn Xuất hàng Hết hàng Nhập hàng từ tận nhà hàng nhà cung cấp Hình 4.6. So sánh giữa generalization, extend và include. 71
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ó 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ụ: Quản lý kho Bán hàng Hình 4.7. Các gói chứa use-case 3.2. Mô hình use-case Mô hình use-case là t ập hợp các biểu đồ use-case. Biểu đồ use- case lại là tập hợp của một số use-case cùng các kết hợp và các tác nhân sử dụng chúng. Trong UML, use-case được sử dụng để nắm bắt các yêu cầu ở mức ngoài về chức năng sử dụng của hệ thống (to capture high level user- functional requirements of the system). Nên lưu ý là use-case không nên sử dụng để mô tả các yêu cầu phi chức năng hay "bên trong" các chức năng (tức là cách thực thi các chức năng), vì use-case trước hết là kỹ thuật phi hình thức và không hoàn toàn chính xác. Tuy nhiên use-case giúp chúng ta xác định cấu trúc và các yêu cầu chính của sản phẩm phần mềm. Mô hình use-case đưa ra câu trả lời cho câu hỏi: hệ thống làm gì khi quan sát từ bên ngoài? Use-case là một thành phần của dự toán và là thành phần nhỏ bé nhất của sản phẩm chuyển giao. Nếu sản phẩm được tinh chỉnh theo nhiều bước và chuyển giao nhiều lần thì mỗi lần chuyển giao 72
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ươ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ác nhân của phần mềm đó, còn use-case như tên gọi của nó, là một trường hợp sử dụng của phần mềm liên quan đến tác nhân nào đó. Để xây dựng mô hình này, ta cần trả lời hai câu hỏi: 1) Ai (hoặc hệ thống nào) trực tiếp sử dụng phần mềm? Câu trả lời sẽ đưa ra danh sách các tác nhân. Từ danh sách các tác nhân đầu tiên ta chọn ra tác nhân quan trọng nhất, sau đó là tác nhân quan trọng thứ nhì,... Với mỗi tác nhân ta nêu câu hỏi: 2) Tác nhân muốn làm gì với hệ thống (tức là phần mềm)? Câu trả lời sẽ là các use-case. Ban đầu mỗi tác nhân cùng các use-case liên quan sẽ là một biểu đồ. Tuy nhiên, sau đó ta cần xem xét các use-case của các tác nhân khác nhau. Nếu ta thấy có nhiều điểm chung thì nên dùng một use-case cho các tác nhân. Ví dụ, use-case mượn sách của tác nhân bạn đọc cũng tương tự như use-case cho mượn sách của thủ thư nên ta gộp hai use-case này thành một và gọi là use-case mượn sách. 73
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ác nhân có thể là một hệ thống khác, để tìm tác nhân loại này ta nêu câu hỏi: hệ thống nào tương tác với hệ thống này? Bước 2. Hãy chọn một phần tử trong các tác nhân. Ví dụ đó là thư ký nhận đơn đặt hàng (sales order clerk), mà ta sẽ gọi đơn giản là người bán hàng. Bước 3. Hãy xác định xem tác nhân này muốn làm gì với hệ thống. Những việc tác nhân này muốn thực hiện trên hệ thống sẽ trở thành các use-case. Bước 4. Với mỗi use-case hãy xác định dòng công việc (course) thường xuyên nhất khi actor sử dụng hệ thống (the most usual course when the actor is using the system). Bước 5. Mô tả dòng công việc cơ sở này trong phần diễn tả use-case (the description for the use-case). Hãy mô tả theo cách "tác nhân làm cái gì đó, hệ thống sẽ làm cái gì đó...", tuy nhiên chỉ giữ ở mức bên ngoài. Bạn hãy chỉ mô tả những điều hệ thống làm mà tác nhân nhận biết được và ngược lại, những điều tác nhân làm mà hệ thống nhận biết được. Trước mắt chưa cần quan tâm đến các quan hệ đặc biệt như hay . 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 Nhập 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 đơn đặt người trong số này. Các thông tin chi tiết về khách hàng này được hàng 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). 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 Kiểm tra tiền Người bán số này. Các thông tin chi tiết về khách hàng này nợ của khách hàng được hiện trên màn hình. Đồng thời, hệ thống hà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. 74
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. 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 Nhập 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 đơn đặt người trong số này. Các thông tin chi tiết về khách hàng này được hàng 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). 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 Kiểm tra tiền Người bán số này. Các thông tin chi tiết về khách hàng này nợ của khách hàng được hiện trên màn hình. Đồng thời, hệ thống hà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 Diễn tả không tìm thấy khách hàng 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 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. 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ề Nhập khách hàng. Với mỗi mặt hàng khách đơn đặt muốn đặt mua, người bán hàng nhập hàng một dòng. Khi tất cả các mặt hàng đã Hiện thông tin được nhập thì hệ thống xác nhận đơn chi tiết về đặt hàng (confirm). khách hàng Nhập lại vì Kiểm tra tiền không tìm thấy Người bán nợ của khách khách hàng hàng hàng Diễn tả Diễn tả Sử dụng use-case “Hiện thông tin...” để tìm và Sử dụng use-case “Hiện thông hiện ra thông tin chi tiết về khách hàng... Nếu tin...” để tìm và hiện ra thông hệ thống không tìm thấy khách hàng nào có họ 75 tin chi tiết về khách như vừa nhập thì báo lỗi và cho phép người sử hàng.Đồng thời, hệ thống dụng nhập lại họ khác và tiếp tục tìm kiếm hiện trên màn hình lịch trình trả nợ của khách hàng trong
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. Tuy nhiên một lỗi thường gặp là quá nhiều use-case được đưa vào mô hình. Vậy bước tiếp theo chúng ta xem xét vấn đề: cái gì không nên đưa vào mô hình use-case? 3.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, ta 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 muốn mô tả thông tin về mối quan hệ đặc biệt giữa các đối tượng, ví dụ một đơn đặt hàng có thể chứa một hoặc nhiều dòng thông tin về các mặt hàng, hay khách hàng ngoài họ ra còn có tên riêng, địa chỉ và các thông tin khác... thì tốt hơn nên dùng mô hình lớp. Hoặc nếu chúng ta muốn mô tả rằng danh 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ê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.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 76
chung và use-case mở rộng), và trường hợp đơn giản nhất là không chứa các quan hệ mở rộng hoặc sử dụng giữa các use-case. Xuất phát từ mô hình đơn giản ban đầu, ta 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 phải lưu ý rằng không thể mô hình hóa tất cả bằng mô hình use-case. Trong nhiều trường hợp, bên cạnh mô hình use-case đơn giản, nếu có thêm scenario hoặc một vài loại biểu đồ nữa thì mô hình sẽ dễ hiểu hơn, như ví dụ về phần mềm điều khiển hoạt động thang máy sau đây. 3.6. Mô tả use-case (use-case description) Rõ ràng t ừ biểu đồ use-case ta mới có ý niệm rất sơ lược về chức năng của mỗi use-case thông qua tên của nó. Vì vậy, đối với mỗi use- case người ta thêm phần mô tả bên dưới. Mô tả use-case khô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ệc trong 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ường chiếm phần nhiều hơn, làm cho hai cột không cân đối, do đó người ta thường trì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). 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ẽ đượ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 đượ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. 77
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 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á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: Nhấn nút hµng Người sử dụng 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ợp generalization để tách use-case này thành hai use-case như hình sau: Nhấn nút Người sử dụng Nhấn nút tầng Nhấn nút thang máy Hình 4.12. 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ới biểu đồ trên nhưng hình thức biểu diễn có khác: Thang máy Nhấn nút thang máy Nhấn nút ở mỗi tầng 78 Người sử dụng
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ó 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 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út trê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áy dừ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ều scenario. 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ơn cho 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. 79
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ờ. 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ếp theo: 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ế. 4. Mô hình lớp 4.1. Biểu đồ lớp 80
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 (Class diagrams describe the types of objects in the system and the various kinds of static relationships th at exist among them). Lớp là khái niệm nền tảng trong phân tích và thiết kế HĐT. Đây là khái niệm khó, các định nghĩa trong các tài liệu hiện có không hoàn toàn nhất quán và đôi khi không chặt chẽ. Ví dụ, rất nhiều tài liệu đưa ra định nghĩa: lớp là tập hợp các đối tượng có chung các thuộc tính và hành vi, ví dụ lớp khách hàng là tập hợp các khách hàng (của cửa hàng đang khảo sát). Nếu nói như vậy thì không thể nói rằng họ tên, giới tính,... là thuộc tính của lớp; vì đây là thuộc tính 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à: "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: 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ác khá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ông tin 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ác thuộ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 được xá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ường nó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: 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ột nhóm các dữ liệu, hàm có liên 81