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 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ở. 62 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 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 đó. 63 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ể 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ó 65 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ử. Đặ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 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 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 67 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ó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) 68 Xem công văn Văn thư Bán hàng Bán hàng Xem bảng giá Khách hàng Nhân viên bán hàng 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. 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ụ: Hình 4.3. Kết hợp generalization giữa các Actor 69 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 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ừ <<include>> được đặt cạnh đoạn thẳng này như hình 7.4. Ví dụ: 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ừ <<extend>> được đặt cạnh đoạn thẳng này như hình 7.5. Ví dụ: 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ì 70 Bán hàng In hóa đơn <<include>> Bán hàng Ký hợp đồng bảo hành <<extend>> 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: 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 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 71 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 <<extend>> Giao hàng Giao ở cửa hàng Mang đến tận nhà Bán hàng In hóa đơn Xuất hàng <<include>> <<include>> Bán hàng <<extend>> <<extend>> <<extend>> Nhập hàng từ nhà cung cấp Hết hàng [...]... 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 72 thực... 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,... 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... 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 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... 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... đí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 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ệ... 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ả... tính: "Nếu là đối tượng, thì đối tượng đó phải có những thông tin gì?" • Gán các thuộc tính tới lớp tương ứng: "Thuộc tính này thuộc lớp nào" 4.5.2 Xác định các phương thức • Kiểm tra các động từ trong kịch bản, use-case để xác định phương thức • Tìm phương thức: "Nếu là đối tượng, thì đối tượng đó phải làm gì ?" • Gán các phương thức tới lớp tương ứng: "Phương thức này thuộc lớp nào ?" • Các phương thức... được tìm từ bên ngoài đối tượng 4.5.3 Xác định các quan hệ giữa các lớp đối tượng (Relationships) Kiểm tra các động từ và liên hệ với thực tế Ví dụ, trong thư viện thì một bạn đọc tại một thời điểm chỉ được mượn tối đa 2 quyển sách Vậy ta có quan hệ: Bạn đọc 1 0 2 88 Sách mượn bay 4.6 Cài đặt lớp trong một số ngôn ngữ lập trình Nếu bạn đã từng học ngôn ngữ lập trình hỗ trợ hướng đối tượng như C++ hay Java,... lớp trong phân tích thiết kế và lớp trong ngôn ngữ lập trình không? Các nhà sáng tạo các ngôn ngữ lập trình HĐT có ý đồ sử dụng khái niệm lớp trong ngôn ngữ lập trình để cài đặt các lớp trong phân tích thiết kế Ngôn ngữ Java chẳng hạn, hỗ trợ rất mạnh cho việc cài đặt các lớp Tuy nhiên, có nhiều ngôn ngữ lập trình rất mạnh nhưng lại không hỗ trợ đầy đủ khả năng hướng đối tượng, ví dụ Visual Basic, Visual . 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. 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. 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