›
›

Giáo trình Phân tích hệ thống hướng đối tượng - Phạm Thị Xuân Lộc

pdf 60 trang hapham 4200
Download
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Phân tích hệ thống hướng đối tượng - Phạm Thị Xuân Lộc", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pdfgiao_trinh_phan_tich_he_thong_huong_doi_tuong_pham_thi_xuan.pdf

Nội dung text: Giáo trình Phân tích hệ thống hướng đối tượng - Phạm Thị Xuân Lộc

  1. TRƯỜNG ĐẠI HỌC CẦN THƠ KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG Giáo trình PHÂN TÍCH HỆ THỐNG HƯỚNG ĐỐI TƯỢNG Biên soạn: Phạm Thị Xuân Lộc 2009
  2. THÔNG TIN VỀ TÁC GIẢ PHẠM VI VÀ ĐỐI TƯỢNG SỬ DỤNG CỦA GIÁO TRÌNH 1. THÔNG TIN VỀ TÁC GIẢ Họ và tên: Phạm Thị Xuân Lộc Sinh năm: 1961 Cơ quan công tác: Bộ môn: Hệ thống thông tin- Toán ứng dụng Khoa: Công nghệ thông tin- Truyền thông Trường: Đại học Cần thơ Địa chỉ Email để liên hệ: ptxloc@cit.ctu.edu.vn 2. PHẠM VI VÀ ĐỐI TƯỢNG SỬ DỤNG Giáo trình có thể dùng tham khảo cho những ngành nào: Tin học Có thể dùng cho các trường nào: các trường có đào tạo chuyên ngành Hệ thống thông tin. Các từ khóa (Đề nghị cung cấp 10 từ khóa để tra cứu): trường hợp sử dụng, lớp, đối tượng, thuộc tính, phương thức, liên kết, bản số, tương tác, sơ đồ tuần tự, thông báo, Yêu cầu kiến thức trước khi học môn này: Cơ sở dữ liệu, Lập trình hướng đối tượng Đã xuất bản in chưa, nếu có thì Nhà xuất bản nào: chưa
  3. PhânPhân ttííchch hhệệ ththốốngng hhưướớngng đđốốii ttưượợngng ••PhPhạạmm ThThịị XuânXuân LLộộcc
  4. Tài liệu tham khảo Stt Tựa Thông tin chi tiết 1UML 2 của Benoit Charoux, Aomar Osmani, Yann Thiery-Mieg, NXB Pearson Education France, 2005. 2 UML par la pratique- Etude của Pascal Roques, XB lần 2, NXB Eyrolles, 2001 de cas et exercices corrigés 3 UML pour l’analyse d’un của Chantal Morley, Jean Hugues, Bernard systeme d’information Leblanc, XB lần 2, NXB Dunod, 2002 4 Phân tích thiếtkế hướng đối của Đặng Văn Đức, NXB Giáo dục, 2002 tựơng bằng UML 5 Modélisation objet avec UML của Pierre-Alian Muller, Nathalie Gaertner, XB lần 2, NXB Eyrolles, 2004 6 Object-oriented analysis David William Brown, NXB John Wileys & Sons, 2002 7 Trang web củaOMG 8 Các trang web liên quan UML
  5. 9 The object-oriented development của Tom Rowlett, NXB Prentice Hall PTR, process 2001 10 A introducton to object-oriented của David Willia Brown, NXB John Wileys analysis- Objects in plain English & Sons, 2002 11 Objects¸ components and của Desmond Francis D’Souza, Alan frameworks with UML Cameron Wills, NXB Addison – Wesley, 1999 12 Software reuse- Domain analysis của Jag Sodhi, Prince Sodhi, NXB McGraw- and design process Hill, 1999 13 La démarche objet- Concepts et của Max Bouché, NXB Afnor, 1994 outils 14 Object models- strategies, patterns của Peter Coad, NXB Prentice-Hall, 1997 & applications 15 Modern system analysis & design của Jeffrey Hoffer, Joey F.George, Joseph S. Valacich, NXB Prentice-Hall, 2002
  6. Mụclục I. Giớithiệu II. Sơ đồ hoạtvụ III. Sơ đồ lớp IV. Sơ đồ tương tác
  7. I. Giớithiệu I.1 Phân tích hệ thống hướng đối tượng I.2 UML I.3 Các loạisơ đồ trong UML
  8. I.1 Phân tích hệ thống hướng đối tượng •Cáchtiếpcậnhướng đốitượng là tấtyếu, để phát triểncáchệ thống phầnmềm: –phứctạp, –theokịp đà phát triển không ngừng củacông nghệ và các nhu cầu ứng dụng trong thựctế.
  9. I.1 Phân tích hệ thống hướng đối tượng (2) • Tuy nhiên, lậptrìnhhướng đối tượng lạiíttrựcquan, íttự nhiên hơnlập trình theo chứcnăng. ⇒ Đòi hỏiphảimôhìnhhóahướng đốitượng trướcthậttốt.
  10. I.1 Phân tích hệ thống hướng đối tượng (3) ƒ Giúp hiểu tốt hơn thực tế và so sánh tốt hơn các giải pháp thiết kế trước khi lập trình. ƒ Dựa trên các ngôn ngữ mô hình hóa.
  11. I.2 UML • UML (Unified Modeling Language) là một ngôn ngữđểmô hình hóa với các ký hiệu sinh động, • Cho phép: – Đặctả – Xây dựng – Hiểnthị – Lậpsưuliệu các hệ thống thông tin sử dụng khái niệm đối tượng.
  12. I.2 UML (2) •Từ năm 1993, được hình thành từ sự hợp nhấtcácphương pháp: – Booch củaGrady Boochở Rational Software Corporation, – OMT (Object Modeling Technology) của James Rumbaugh, – OOSE (Object Oriented Software Engineering) của Ivar Jacobson.
  13. I.2 UML (3) •Khởi đầutừ tên Unified Method • Đổi tên thành UML từ 1996 • Đượcchuyển cho OMG (Object Management Group) từ 1997, với version 1.1 được phát hành như mộtchuẩn •Hiện đang ở version 2.0 với nhiềucảitiến về mô hình hóa hành xử, về liên quan giữa các mô hình về cấutrúcvàhànhxử.
  14. I.3. Các loạisơ đồ trong UML 2.0 Sơ đồ về cấutrúc Sơ đồ về hành xử Sơ đồ về tương tác
  15. Class diagram Object diagram Sơ đồ lớp Sơ đồ Structure diagrams đối tượng Composite Sơ đồ về Sơ đồ structure cấutrúc cấutrúcphức diagram Sơ đồ đóng gói Sơ đồ Sơ đồ Package diagram thành tố triển khai Component diagram Deployment diagram
  16. Use case diagram Sơ đồ hoạtvụ Sơ đồ State diagram trạng thái Activity diagram Sơ đồ Sơ đồ về hoạt động Hành xử Behavior diagrams
  17. Sequence diagram Communication Sơ đồ diagram tuầntự Sơ đồ truyền thông Sơ đồ tổng thể về tương tác Timing Interaction overview Sơ đồ diagram diagram thờigian Sơ đồ về tuơng tác Interaction diagrams
  18. Chương II: Sơ đồ hoạt vụ (use case diagram) Chương II: Sơ đồ hoạt vụ 1 II.1. MỤC ĐÍCH CỦA TRƯỜNG HỢP SỬ DỤNG: 2 II.2 ĐỊNH NGHĨA VÀ KÝ HIỆU: 2 II.2.1 Định nghĩa: 2 II.2.2 Ký hiệu: 2 II.3 MÔ TẢ SƠ ĐỒ HOẠT VỤ: 3 II.3.1 Các quan điểm mô tả sơ đồ hoạt vụ: 3 II.3.2 Quan hệ giữa các trường hợp sử dụng trong một sơ đồ hoạt vụ: 3 II.4 QUAN HỆ GIỮA CÁC TÁC NHÂN: 5 II.5 MỘT VÀI NGUYÊN TẮC MÔ TẢ SƠ ĐỒ HOẠT VỤ: 6 II.5.1 Xác định các tác nhân: 6 II.5.2 Gom lại các trường hợp sử dụng: 6 II.6 MÔ TẢ BẰNG VĂN BẢN CÁC TRƯỜNG HỢP SỬ DỤNG: 7 II.6.1 Đinh danh: 7 II.6.2 Chuỗi hành vi: 7 II.6.3 Các mục bổ sung tùy ý : 7 II.7 ĐÓNG GÓI CÁC TRƯỜNG HỢP SỬ DỤNG: 9 II.7.1 Ngữ cảnh: 9 II.7.2 Đinh nghĩa: 10
  19. II.1. MỤC ĐÍCH CỦA TRƯỜNG HỢP SỬ DỤNG: Trường hợp sử dụng là một kỹ thuật mô tả hệ thống dựa trên quan điểm người sử dụng. Mỗi trường hợp sử dụng là một cách thức riêng biệt để sử dụng hệ thống. Trường hợp sử dụng là một tập hợp bao gồm các thao tác được kích họat bởi một tác nhân bên ngoài và tạo ra một kết quả xác định được (identifiable), quan sát được (observable). Việc nhóm lại các thao tác này không tương ứng với các cấu trúc đã cài đặt sẵn hoặc để cài đặt trực tiếp, ngắn hạn trước mắt. Nó tương ứng sát hơn với một chuỗi thao tác như một logic cảm nhận được từ người sử dụng. II.2 ĐỊNH NGHĨA VÀ KÝ HIỆU: II.2.1 Định nghĩa: Các trường hợp sử dụng được gom lại trong các sơ đồ họat vụ, nhằm chỉ ra mối liên hệ giữa các trường hợp sử dụng và các tác nhân. Những sơ đồ này cũng cho phép biểu diễn sự phụ thuộc: - giữa các trường hợp sử dụng lẫn nhau - giữa các tác nhân lẫn nhau II.2.2 Ký hiệu: Ký hiệu Ý nghĩa (Nếu tác nhân là người) Tác nhân (Nếu tác nhân > không phải là người) Trường hợp sử dụng Hoặc Quan hệ giữa tác nhân và trường hợp sử dụng (tác nhân kích hoạt trường hợp sử dụng) Quan hệ giữa các trường hợp sử dụng Đường biên hệ thống (tùy ý)
  20. II.3 MÔ TẢ SƠ ĐỒ HOẠT VỤ: II.3.1 Các quan điểm mô tả sơ đồ hoạt vụ: Mỗi trường hợp sử dụng được mô tả bằng một định nghĩa tổng quát và bằng một kịch bản (script) với các định nghĩa được minh họa cụ thể. Một trường hợp sử dụng có thể có mặt trong nhiều sơ đồ hoạt vụ. Có 2 quan điểm biểu diễn mô tả sơ đồ họat vụ: a. Thực hiện một sơ đồ họat vụ cho một tác nhân b. Thực hiện một sơ đồ họat vụ cho nhiều tác nhân, trong đó có một tác nhân chính kích hoạt sơ đồ hoạt vụ và các tác nhân phụ có tham gia vào các trường hợp sử dụng trong sơ đồ hoạt vụ. II.3.2 Quan hệ giữa các trường hợp sử dụng trong một sơ đồ hoạt vụ: II.3.2.1 Quan hệ “bao hàm” (inclusion): Trường hợp sử dụng B được coi là “bao hàm” trường hợp sử dụng A nếu hành vi mô tả B bao hàm hành vi mô tả A. Ta nói B phụ thuôc vào A. Ký hiệu : bao hàm B A Hoặc includes B A
  21. Ví dụ : bao hàm Nhận thanh toán Tạo biên lai cho cước từ khách hàng khách hàng II.3.2.2 Quan hệ “mở rộng” (extension): Nếu hành vi của trường hợp sử dụng B có thể được mở rộng bởi hành vi của trường hợp sử dụng A, ta nói A mở rộng B. Một sự mở rộng thường phải chịu một điều kiện, điều kiện này được biểu diễn dưới dạng một ghi chú (note) . Phải cho biết chính xác ở điểm nào của trường hợp đang xét thì mở rộng nó. Ký hiệu : mở rộng A B Hoặc extends A B Ví dụ : mở rộng Thanh toán Nhận giấy cước báo cước II.3.2.3 Quan hệ “tổng quát hóa” (generalization): Một trường hợp sử dụng A là một sự tổng quát hóa trường hợp sử dụng B nếu B là một trường hợp đặc biệt của A. Mối quan hệ « tổng quát hóa sẽ được diễn dịch thành khái niệm « thừa kế» trong các ngôn ngữ hướng đối tượng. Ký hiệu : biểu diễn bằng mũi tên khối rỗng về trường hợp sử dụng tổng quát hơn.
  22. A B Ví dụ : Thanh toán Thanh toán bằng thẻ Thanh toán bằng tiền mặt II.4 QUAN HỆ GIỮA CÁC TÁC NHÂN: Mối quan hệ duy nhất có thể có giữa các tác nhân là sự tổng quát hóa. Một tác nhân A là một sự tổng quát hóa của B nếu A có thể được thay thế bởi B trong mọi trường hợp sử dụng (chiều ngược lại không đúng). Ký hiệu: A B Ví dụ : linh luong Nhan vien ky quyet dinh Lanh dao
  23. mua the nap tien cho the chon thuc an dong goi san chon thuc an tu ds chon thuc an > SV chon thuc an theo yeu cau > > chon trong luong yc chon gia yeu cau II.5 MỘT VÀI NGUYÊN TẮC MÔ TẢ SƠ ĐỒ HOẠT VỤ: II.5.1 Xác định các tác nhân: - Các tác nhân là những người sử dụng hệ thống. Không nên quên những người sử dụng có trách nhiệm khai thác và bảo trì HTTT. Không kể đến những kỹ sư phần mềm cài đặt và tham số hóa phần mềm trước khi sử dụng. - Ngoài ra, tác nhân có thể là : + Các thiết bị ngoại vi sử dụng bởi hệ thống (máy in, robot, ) + Các phần mềm đã sẵn sàng để được tích hợp vào hệ thống + Các hệ thống tin học nằm ngoài nhưng có tương tác với hệ thống đang xét Để dễ tìm các tác nhân, nên hình dung ra trước các biến của hệ thống. Tất cả những ai, những gì sử dụng HT và có tương tác với HT là một tác nhân. Một trường hợp sử dụng luôn có ít nhất: - 1 tác nhân chính kích hoạt trường hợp sử dụng bằng yêu cầu của mình và HT sẽ sinh ra một kết quả quan sát được cho tác nhân đó - và thường có các tác nhân phụ khác. II.5.2 Gom lại các trường hợp sử dụng: - Không có nguyên tắc duy nhất. - Cần đứng trên quan điểm người sử dụng và xác định: + tác nhân đó được HT phục vụ thế nào + trong trường hợp nào tác nhân đó sử dụng HT + chức năng nào của HT mà tác nhân đó truy cập đến - Cần tránh sự dư thừa, và cần có trừu tượng hóa hợp lý để giam bớt số trường hợp, ví dụ không nên cho 1 trường hợp sử dụng chỉ có 1 thao tác.
  24. II.6 MÔ TẢ BẰNG VĂN BẢN CÁC TRƯỜNG HỢP SỬ DỤNG: Gồm có 3 phần: định danh, mô tả chuỗi hành vi và các mục bổ sung tùy ý: II.6.1 Đinh danh: - tên - mục tiêu (tóm tắt) - các tác nhân (chính + phụ) - ngày tạo và ngày cập nhật mới nhất - người tạo - phiên bản (version) II.6.2 Chuỗi hành vi: - mô tả tổng quát chuỗi - điều kiện đầu (pre-cond) - chuỗi liên kết các thông báo (messages) - điều kiện cuối (post-cond) - xử lý các ngoại lệ II.6.3 Các mục bổ sung tùy ý : II.6.3.1 Ràng buộc phi chức năng : - tính tin cậy (confidentiality) - tính bảo mật (security) - tính sẵn sàng (disponiblity) - tính cạnh tranh (concurrence) - thời gian đáp ứng - II.6.3.2 Ràng buộc về giao diện người-máy : Màu sắc, vị trí các mục, theo qui định của ngành dọc (ngành tài chính, ngân hàng ) Ví dụ 1: use case « Đăng nhập”: Định danh: - Tên: Đăng nhập - Mục tiêu (tóm tắt): Use case này mô tả cách một người dùng đăng nhập vào Hệ thống đăng ký học phần. - Tác nhân chính: Sinh viên - Ngày tạo và ngày cập nhật mới nhất: 26/1/08 - Người tạo: Nhóm 10- HK 2 2007-2008 - Phiên bản (version): 3
  25. Chuỗi hành vi: - Mô tả tổng quát chuỗi: Use case này bắt đầu khi một actor muốn đăng nhập vào Hệ thống đăng ký học phần. - Điều kiện đầu (pre-cond) : không có. - Chuỗi liên kết các thông báo (messages) : 1. Hệ thống yêu cầu actor nhập tên và mật khẩu. 2. Actor nhập tên và mật khẩu. 3. Hệ thống kiểm chứng tên và mật khẩu được nhập và cho phép actor đăng nhập vào hệ thống. - Điều kiện cuối (post-cond) : Nếu use case thành công, actor lúc này đã đăng nhập vào hệ thống. Nếu không trạng thái hệ thống không thay đổi. - Xử lý ngoại lệ: Nếu actor nhập sai tên hoặc mật khẩu, hệ thống sẽ hiển thị một thông báo lỗi. Actor có thể chọn trở về đăng nhập lại hoặc hủy bỏ việc đăng nhập, lúc này use case kết thúc. Nếu actor nhập sai : + Username : sẽ hiển thị thông báo không tồn tại username. + Password : sẽ hiển thị thông báo yêu cầu nhập đúng mật khẩu. Ví dụ 2: use case « Quản lý số lượng hàng tồn kho 1 ngành hàng”: a. Định danh: - Tên: Quản lý số lượng hàng tồn kho 1 ngành hàng. - Mục tiêu (tóm tắt): Tránh thất thoát, giải phóng hàng tồn. - Các tác nhân (chính + phụ): Nhân viên quản lý kho (phụ), Nhân viên quản lý ngành hàng (chính). - Ngày tạo và ngày cập nhật mới nhất: 21/11/2008 - Người tạo: Nhóm 5: Hồ Bửu Thiện, Nguyễn Phương Bình, Trần Duy Phương, lớp Tin học Cần thơ 2004 - Phiên bản (version): 1.0 b. Chuỗi hành vi: - Mô tả tổng quát chuỗi: kiểm tra số lượng xuất hàng, nhập hàng. - Điều kiện đầu (pre-cond) : có bảng thống kê hàng tồn của định kỳ trước, phiếu nhập, phiếu xuất, danh sách hàng thất thoát do hư hao (tất cả lưu trên cơ sở dữ liệu), danh mục ngành hàng. - Chuỗi liên kết các thông báo (messages) : + Hệ thống hiển thị danh mục ngành hàng + Nhân viên quản lý kho chọn ngành hàng (mã) + Nhân viên quản lý kho ghi ngày, giờ kiểm tra hàng tồn theo định kỳ. + Nhân viên quản lý kho truy xuất mã ngành hàng, mặt hàng để kiểm tra theo từng mặt hàng.
  26. + Hệ thống (hoặc do phương thức của một lớp) tính số lượng tồn cuối cho từng mặt hàng từ bảng thống kê hàng tồn của định kỳ trước, phiếu nhập, phiếu xuất, danh sách hàng thất thoát do hư hao, và lưu kết quả bảng vào cơ sở dữ liệu. Công thức tinh: TỒN CUỐI=TỒN ĐẦU+ NHẬP - XUẤT + Nhân viên quản lý kho kiểm tra số lượng hiện tại trong kho. + Nhân viên quản lý kho đối chiếu số lượng hàng tồn trên thực tế và số liệu tồn cuối tính được. + Nhân viên quản lý kho nhập số lượng hàng tồn trên thực tế, số lượng chênh lệch, lưu vào CSDL và in ra. + Nhân viên quản lý kho in bảng thống kê số lượng hàng tồn theo định kỳ. - Điều kiện cuối (post-cond) : Lưu vào cơ sở dữ liệu và in ra: o bảng thống kê số lượng hàng tồn của từng mặt hàng, o bảng thống kê số lượng chênh lệch của từng mặt hàng - Xử lý các ngoại lệ : o Nếu có mặt hàng chưa có phiếu xuất: đổi công thức thành: TỒN CUỐI=TỒN ĐẦU+ NHẬP o Nếu có mặt hàng chưa được kiểm kê tồn: đổi công thức thành: TỒN CUỐI=NHẬP- XUẤT o Nếu có mặt hàng chưa có phiếu xuất và cũng chưa được kiểm kê tồn: đổi công thức thành: TỒN CUỐI=NHẬP o Nếu số lượng xuất lớn hơn số lượng nhập thì yêu cầu nhập lại. o Nếu số lượng âm thì yêu cầu nhập lại. c. Các mục bổ sung tùy ý : ƒ Ràng buộc phi chức năng(non-functional constraints) : - Tính tin cậy (confidentiality): chính xác theo phiếu nhập và phiếu xuất. - Tính bảo mật (security): Nhân viên quản lý kho, nhân viên quản lý ngành hàng, ban giám đốc. - Tính sẵn sàng (disponiblity): giờ đóng cửa siêu thị, hoặc khi có yêu cầu từ lãnh đạo. - Tính cạnh tranh (concurrence) : không cho phép nhiều người cùng kiểm tra 1 kho. - Thời gian đáp ứng (response time): o tính số lượng tồn cuối: <=1’ o tính số liệu chênh lệch: 6 giờ. II.7 ĐÓNG GÓI CÁC TRƯỜNG HỢP SỬ DỤNG: II.7.1 Ngữ cảnh: UML cho phép nhóm lại các trường hợp sử dụng trong một gói (paquet, packet, package). Có thể đóng gói trên một hoặc nhiều tiêu chí sau:
  27. - Tác nhân: Thủ kho, Kế toán, Thu ngân, - Lĩnh vực chức năng: Quản lý kho, Quản lý nhân sự, - Đối tượng cần quản lý (thường nhập chung với cách phân chia gói theo lĩnh vực chưc năng): Hàng, Nhân viên, Cửa hàng - Vị trí địa lý: Đồng bằng sông Cửu long, Nam Trung bộ, - Thời gian thực hiện: Thu mua, Nhập kho, Trưng bày, Bán hàng, Giao hàng, Bảo hành, - Quyền truy xuất: Chỉ đọc, Chỉ thêm, Một sơ đồ hoạt vụ có thể có chứa nhiều gói và một gói có thể được chứa trong gói khác. Ví dụ: A::B (gói A chứa gói B) A::B::C (gói A chứa gói B, gói B chứa class C) II.7.2 Đinh nghĩa: Một gói cho phép tổ chức các thành phần để mô hình hóa thành nhóm. Một gói có thể chứa các lớp, các trường hợp sử dụng, các giao diện QL KHàng bao hàm Hỗ trợ KH QL Kho bao hàm
  28. Chương III: Sơ đồ lớp Chương III: Sơ đồ lớp 1 III.1 MỤC ĐÍCH CỦA SƠ ĐỒ LỚP : 2 III.2 LỚP vÀ CÁC KHÁI NIỆM LIÊN QUAN: 2 III.2.1 Lớp: 2 III.2.2 Phương thức trừu tượng và lớp trừu tượng: 3 III.2.3 Sự bao gói (encapsulation) và mức độ hiển thị (visibility): 3 III.2.4 Thuộc tính (attribute): 4 III.2.5 Phương thức (method): 5 III.3 GIAO DIỆN (INTERFACE): 5 III.4 QUAN HỆ GIỮA CÁC LỚP: 5 III.4.1 Liên kết (association): 5 III.4.2 Tính bội (multiplicity) : 6 III.4.3 Liên kết có ràng buộc (association with constraint): 6 III.4.4 Lớp-liên kết (association class) : 6 III.4.5 Liên kết do suy diễn: 7 III.4.6 Liên kết có thẩm định (qualified association): 8 III.4.7 Liên kết nhiều chiều: 8 III.4.8 Quan hệ kết tập (aggregation relation) : 10 III.4.9 Quan hệ cấu thành (composition) : 11 III.4.10 Quan hệ phụ thuộc (dependancy): 11 III.4.11 Quan hệ thừa kế : 11 III.5 RÀNG BUỘC : 12 III.6 XÂY DỰNG MỘT SƠ ĐỒ LỚP : 12 III.6.1 Các quan điểm mô hình hóa : 12 III.6.2 Các bước xây dựng : 12 1
  29. III.1 MỤC ĐÍCH CỦA SƠ ĐỒ LỚP : - Được xem là mô hình quan trọng nhất trong phân tích hệ thống hướng đối tượng. - Dùng để mô tả cấu trúc bên trong, tĩnh của hệ thống. - Không dùng để chỉ ra cách thức làm thế nào sử dung các tác tử (operation). Trách nhiệm đó sẽ do sơ đồ tương tác. III.2 LỚP vÀ CÁC KHÁI NIỆM LIÊN QUAN: III.2.1 Lớp: Lớp là một sự mô tả một tập hợp các đối tượng có cùng các đặc tính : cùng một ngữ nghĩa, có chung các thuộc tính, các phương thức và các quan hệ. Một đối tượng là một thể hiện của lớp. Ký hiệu : Tên lớp Danh sách các thuộc tính Danh sách các phương thức - Tên lớp : phải có nghĩa và bắt đầu bằng chữ hoa. Nếu nó được đóng gói, cần đặc tả tất cả các gói chứa nó theo thứ tự từ lớn đến nhỏ và cách bởi 2 dấu hai chấm ( :: ). Ví dụ : java ::lang ::Object - Mỗi thuộc tính (attribute) được mô tả bằng tên và kiểu. Tên của thuộc tính phải duy nhất trong lớp. - Mỗi phương thức (method) được mô tả kiểu trả về, danh sách các đối số và kiểu tương ứng của mỗi đối số. Ví dụ : Sinh_viên họ: String tên: String ngày_sinh: Date phái: {‘M’, ‘F’} lớp: String đkýMôn(m: String); đkýNhóm(): Integer; 2
  30. III.2.2 Phương thức trừu tượng và lớp trừu tượng: Một phương thức được gọi là trừu tượng nếu người ta biết được phần mô tả đầu của nó (header / entête / signature ) nhưng không biết cách thức nó có thể được thực hiện như thế nào. Một lớp được gọi là trừu tượng nếu nó định nghĩa ít nhất một phương thức trừu tượng hoặc khi một lớp cha chứa một phương thức trừu tượng chưa được thực hiện. Ví dụ : PhươngTrình {abstract} x: Array; GiaiPT();{abstract} PhươngTrìnhBac2 PhươngTrìnhBacN {abstract} x: Array; x: Array; a, b, c: Real; n: Integer; a: Array; GiaiPT(); Tên của một lớp trừu tượng sẽ có thêm từ khóa « abstract » đặt giữa dấu móc {} như trong ví dụ. III.2.3 Sự bao gói (encapsulation) và mức độ hiển thị (visibility): Một lớp hoặc thành phần của lớp (chẳng hạn thuộc tính) có nhiều mức độ được nhìn thấy tùy theo ký tự đứng trước nếu có: - Có từ khóa public hoặc dấu + đứng trước : được nhìn thấy từ bên ngoài - Không có ký tự nào đứng trước : chỉ được nhìn thấy từ trong gói chứa lớp đang xét - Có từ khóa protected hoặc dấu # đứng trước : được nhìn thấy từ trong lớp đang xét hoặc các lớp con cháu của lớp đó - Có từ khóa private hoặc dấu - đứng trước : chỉ được nhìn thấy từ trong lớp đang xét. 3
  31. Gói1 Gói2 +Lớp1 +Lớp2 “import” +Lớp4 -a1 a2 +a3 #a4 +Lớp3 III.2.4 Thuộc tính (attribute): Các thuộc tính biểu diễn các dữ liệu được bao gói trong các đối tượng của lớp đang xét. Một thuộc tính có thể được khởi tạo lúc khai báo. Ngữ pháp đầy đủ của thuộc tính như sau: [/] : [‘[’ ] ’]’ [= ] trong dó: : dùng các từ khóa public, private, protected hoặc các dấu tương ứng : kiểu dữ liệu cơ sở hoặc tên lớp : các chỉ số tối thiểu và tối đa cho một mảng của kiểu vừa nói ở trên : phải có kiểu tương ứng với kiểu nói trên. III.2.4.1 Thuộc tính của lớp: Thông thường, một thuộc tính sẽ có các trị khác nhau ở các đối tượng khác nhau của lớp đó. Tuy nhiên, tồn tại những thuộc tính có trị duy nhất cho tất cả các đối tượng của lớp đó. Các đối tượng truy xuất được thuộc tính đó, nhưng không được sở hữu một bản sao của nó. Đó chính là thuộc tính tĩnh mà trong Java và C++ dùng từ khóa static đứng trước tên của nó. Trong UML, thuộc tính của lớp được gạch dưới. Ví dụ: giá trị PI=3.14 của lớp Math trong Java luôn không đổi đối với bất kỳ đối tượng nào của lớp Math. III.2.4.2 Thuộc tính do suy diễn (derived attribute): Thuộc tính do suy diễn là thuộc tính có được do sự suy diễn, tính toán từ các thuộc tính khác. Nó được sử dụng như một thuộc tính thực thụ, nhưng được tính toán qua một phương thức. Thuộc tính do suy diễn được đánh dấu bởi dấu “/’ (slash) đứng trước. Ví dụ: /tri_gia: integer; 4
  32. III.2.5 Phương thức (method): Hành vi của một đối tượng được mô hình hóa bằng một tập các phương thức. Người ta phân biệt đặc tả (specification, header) của phương thức với cài đặt (implementation) của nó. Tương ứng với mỗi đặc tả, có thể có nhiều cài đặt, nhưng với mỗi cài đặt chỉ tương ứng với một đặc tả duy nhất. Đặc tả còn được gọi là “operation”, còn cài đặt cụ thể được gọi là “method”. III.3 GIAO DIỆN (INTERFACE): Giao diện cũng giống như lớp, nhưng không có đặc tả cho một cấu trúc bên trong, cũng như các giải thuật thực hiện cho các phương thức. Giao diện có thể mô tả chính xác điều kiện và kết quả việc kích họat nó. Ngược với lớp, giao diện không có thể hiện. Để được sử dụng, nó thường phải được thực hiện bởi một lớp. Một giao diện có thể được chuyên biệt hóa hoặc tổng quát hóa bởi một giao diện khác. Cách biểu diễn giao diện và mối liên hệ với lớp: “interface” TenGiaoDien TenLop TenGiaoDien TenLop III.4 QUAN HỆ GIỮA CÁC LỚP: III.4.1 Liên kết (association): Một liên kết biểu diễn mối liên hệ ngữ nghĩa bền vững giữa 2 lớp. Ký hiệu: A B Các thành phần đầy đủ của một liên kết gồm có: bản số tên liên kết bản số vai trò vai trò Mũi tên để chỉ ý nghĩa chính xác của tên liên kết từ lớp bên trái sang lớp bên phải. “Vai trò” phía một lớp dùng để chỉ vai trò của lớp đó trong liên kết đối với lớp kia. Vai trò, mũi tên có thể được bỏ qua. 5
  33. Nếu muốn biểu diễn sự thông thương từ một lớp sang lớp khác bị cấm ta dùng dấu tréo ở phía lớp đó trên đường nối. Ví dụ: dạy 1 * 1 * GViên Môn * được định nghĩa bởi 3 * Hình đa giác Điểm Trong ví dụ này, sự thông thương chỉ có chiều duy nh#ấđtỉ ntừh lớp “Hình đa giác” sang lớp “Điểm”. III.4.2 Tính bội (multiplicity) : Ở 2 đầu mối liên kết, phải có chỉ số để biểu diễn tính bội của liên kết, chính xác hơn là bản số (cardinality) của mỗi lớp tham gia vào liên kết. Chú ý: bản số của một lớp ở đầu này của liên kết được ký hiệu ở lớp đầu kia của liên kết. Ví dụ: 1 1 4 Môn GViên Ngữ nghĩa: 1 môn được dạy bởi ít nhất 1 giáo viên và nhiều nhất 4 giáo viên, trong khi 1 giáo viên chỉ dạy 1 môn duy nhất. III.4.3 Liên kết có ràng buộc (association with constraint): Việc thêm vào ràng buộc cho một hoặc nhiều liên kết mang lại nhiều thông tin hơn vì nó cho phép mô tả chính xác hơn tầm ảnh hưởng và chiều của lien kết. Các ràng buộc dược đặt trong dấu móc “{}” và có thể biểu diên bằng bất kỳ ngôn ngữ nào. Tuy nhiên, ngôn ngữ OCL ( Object Constraint Language) được ưa chuộng hơn. Ví dụ: được định nghĩa bởi * 3 * Hình đa giác Điểm #đỉnh {ordered} III.4.4 Lớp-liên kết (association class) : Khi phân tích, ta thấy có những thuộc tính không thể đặt vào được trong lớp thuần túy nào, mà phụ thuộc đồng thời vào nhiều lớp nối nhau qua một liên kết. Vì trong phân tích hệ thống hướng đối tượng, chỉ có lớp mới có thể chứa được thuộc tính nên liên kết này trở thành một lớp, gọi là lớp-liên kết. Ví dụ: các lớp “Co_chuyen_mon”, “Co_ngoai_ngu” và “Xin_tuyen” trong sơ đồ sau: 6
  34. + Chuyen_mon + Ngoai_ngu - ma_CM - ten_CM - ma_NN - ten_NN 1 * co_CM 1 * co_NN + Nguoi xin viec 0 * + Co_chuyen_mon 0 * + stt - ho - trinh_do - ten - nam_sinh + Co_ngoai_ngu + xin_TD - trinh_do + hien_thi 1 + duoc_nhan - duoc_danh_gia duoc_nhan 1 xin_tuyen 0 1 + Xin_tuyen + Vi_tri - danh_gia + stt_VT 0 * - dien_giai III.4.5 Liên kết do suy diễn: Liên kết do suy diễn là liên kết được đặt điều kiện hoặc được suy diễn từ ít nhất một liên kết khác. Mặc dù nó tạo ra sự dư thừa, nhưng thực tế lại có ích nếu phải sử dụng nhiều liên kết mới có được kết quả như mong muốn. Ký hiệu: có dấu slash (“/”) trước tên liên kết. Ví dụ 1: liên kết “có thẻ” trong sơ đồ về thẻ ATM dưới đây (dấu “/” được thay bởi từ khóa “derived” do phần mềm không cho phép ) + Khach hang - ma KH - ho KH - ten KH - dia chi KH 1 > 1 co the 0 * + The ATM - ma the - ngay tao - so du co TK 0 * cua TK 0 * 1 + Tai khoan - so TK - ngay tao - so du Ví dụ 2: liên kết “mua” là liên kết suy diễn và cần thiết duy trì khi cần biết thường xuyên khách hàng mua hàng gì bằng mối liên kết trực tiếp thay vì phải qua 2 liên kết “mua món” và “gồm”. 7
  35. + Khach hang - ma_KH - hoten_KH 0 * mua 1 + Hang 1 * - ma_hg + ten_hg + dvt mua mon 1 0 * 1 * gom + Mon hang cu the + stt + don gia III.4.6 Liên kết có thẩm định (qualified association): Có đôi khi một lớp này có tác động đến lớp khác liên kết với nó, đòi hỏi liên kết phải có một sự thẩm định (qualification) để tránh mô hình hóa không chính xác. Sự thẩm định này biểu hiện bằng cách cho thêm: - một chỉ số vào liên kết - hoặc một lớp vào lớp ban đầu Ví dụ 1: một đối tựong của lớp Object được tham chiếu bởi một chỉ số duy nhất trong một đối tượng của lớp Vector. 1 * Vector Object 1 1 Vector indice: integer Object Ví dụ 2: Do ngân hàng có nhiều hoạt động khác không liên quan đến khách hàng trong ngữ cảnh đang xét, và ta muốn giới hạn mối quan hệ giữa khách hàng và ngân hàng chỉ là thông qua các tài khoản: ta thêm vào một lớp “Tài khỏan” trong lớp “Ngân hàng”: 0 2 * Ngân hàng #Tài khỏan Khách hàng III.4.7 Liên kết nhiều chiều: Trong UML, ít khi dùng liên kết nhiều chiều, mà thường giới hạn ở 2 chiều, đôi khi 3 chiều. Lý do là vì để xác định bản số của mỗi lớp khá khó khăn. Thường thì các liên kết nhiều chiều được chuyển sang dùng lớp-liên kết, hoặc nhiều liên kết 2 chiều. Ví dụ: Về thời khóa biểu dạy học, có nhiều cách mô hình hóa: Cách 1: Dùng liên kết nhiều chiều nối với tất cả các lớp liên quan: 8
  36. + Phong 0 * + Thoi gian + Mon 0 * 0 * day hoc 0 * 0 * + Lop + Giao vien Cách 2: Khuynh hướng hiện nay là phá liên kết nhiều chiều ra thành các liên kết ít chiều hơn. Trong ví dụ dưới đây, do có tồn tại phụ thuộc hàm: Phòng, Thời gian -> Môn, Giáo viên, Lớp Nên các liên kết 3 chiều thực sự có khóa chỉ gồm khóa của Phòng và khóa của Thời gian kết hợp lại: + Giao vien 0 * 0 * + Thoi gian 0 * + Phong day boi 0 * 0 * 0 * 0 * day mon day o 0 * 0 * + Mon + Lop Phòng Thời gian Môn Giáo viên Lớp Hoặc: 9
  37. Phòng Thời gian Môn Giáo viên Lớp Cách 3: Chuyển nút ở liên kết nhiều chiều thành lớp mới + Phong - ma phong - nha hoc + Thoi gian - ngay - gio bat dau 1 * - gio ket thuc + Lop - ma lop 0 * 1 - so nhom 1 - si so 0 * + Phien 1 - stt 1 1 * 1 + Mon - ma mon 1 * - ten mon + GV - so DVHT - ma GV - ho GV - ten GV Cách 4: Khi lớp, giáo viên và môn không quan trọng lớp trong ngữ cảnh đang xét thì chuyển chúng chúng từ lớp thành thuộc tính trong lớp liên kết: + Thoi gian + Phong - ngay - ma phong - gio bat dau 0 * 0 * - nha hoc - gio ket thuc + Phien - stt - ten mon - ho GV - ten GV - ma lop III.4.8 Quan hệ kết tập (aggregation relation) : Một kết tập là một trường hợp đặc biệt của liên kết không đối xứng biểu diễn một mối quan hệ « chứa đựng » về cấu trúc hoặc hành vi của một phần tử trong một tập hợp. Không như liên kết, quan hệ kết tập có tính truyền. 10
  38. Quan hệ kết tập cũng cho phép việc ủy thác về tác tử : một tác tử có thể được thực hiện trên một lớp kết tập, thực tế được thực hiện trên các lớp thành phần của nó. Chu kỳ sống của lớp kết tập là độc lập với các lớp thành phần của nó. Mặt khác, một thể hiện của lớp thành phần có thể xuất hiện trong nhiều thể hiện của lớp kết tập. Ký hiệu : có hình thoi rỗng trên liên kết về phía lớp biểu diễn tập hợp chứa đựng. 1 * * 1 * Thư viện Kho sách Kệ sách III.4.9 Quan hệ cấu thành (composition) : Quan hệ cấu thành còn được gọi là quan hệ kết tập phức hợp, là một quan hệ kết tập đặc biệt. Nó mô tả một sự chứa đựng về cấu trúc giữa các thể hiện. Lớp chứa sẽ chịu trách nhiệm tạo ra, sao chép và xóa các lớp thành phần của nó. Mặt khác, việc sao chép hoặc xóa đi lớp chứa sẽ kéo theo sao chép hoặc xóa các lớp thành phần của nó. Một thể hiện của lớp thành phần chỉ thuộc về duy nhất một thể hiện của lớp chứa nó. Ký hiệu: hình thoi đặc trên liên kết ở phía lớp chứa. Ví dụ: 1 Bàn Mặt bàn 0 1 3 4 0 1 Mặt kính phủ Chân bàn III.4.10 Quan hệ phụ thuộc (dependancy): Khái niệm tương tự như trong phân tích cổ điển. Ký hiệu : đường gạch đứt nét có mũi tên từ lớp chịu phụ thuộc. Ví dụ : + Chuyen bay + Hang HK cua III.4.11 Quan hệ thừa kế : Khái niệm tương tự như trong phân tích cổ điển, cũng có thừa kế đơn và thừa kế bội. Ký hiệu : đường gạch có mũi tên rỗng hướng về lớp cha. Ví dụ : 11
  39. + Nhan vien + NV hanh chinh + Giao vien + Mon hoc - nhiem vu 1 * 1 * day III.5 RÀNG BUỘC : Các ràng buộc có thể biểu diễn bằng ngôn ngữ tự nhiên, một ngôn ngữ lập trình, biểu thức toán học hoặc ngôn ngữ OCL đi kèm theo UML. Cụ thể có các dạng ràng buộc sau được biểu diễn bằng OCL: - Các qui tắc thừa kế: {complete}, {incomplete}, {overlaps}, {distinct} - Hạn chế tầm vực của một liên kết: {subset}, {xor} - Cách thức phát triển các đối tượng: {frozen}, {addOnly} - Tổ chức các đối tượng:{ordered}, {frozen}, III.6 XÂY DỰNG MỘT SƠ ĐỒ LỚP : III.6.1 Các quan điểm mô hình hóa : - Top-down : Phân giải dần từ tổng quát xuống chi tiết - Bottom-up : Sau khi có sơ đồ chi tiết ở tất cả các khóa cạnh, mới nhóm lại dần thành các phân hệ riêng, dựa trên mối tương quan chặt chẽ giữa các lớp. III.6.2 Các bước xây dựng : III.6.2.1 Tìm các lớp của lĩnh vực chức năng : - Tìm các đối tượng và lớp trong thế giới thực o Lớp trong thế giới thực o Lớp con trong thế giới thực - Chuyển đổi từ các đối tượng trong thế giới thực sang đối tượng dữ liệu o Lớp trong thế giới dữ liệu o Quản trị sự phức tạp o Ánh xạ cho các lớp - Chọn lựa giữa lớp và thuộc tính - Lớp dữ liệu bổ sung - Tìm các cấu trúc kết tập và lớp con III.6 2.2 Tìm các mối liên kết giữa các lớp : III.6.2.3 Tìm các thuộc tính của mỗi lớp : III.6.2.4 Tổ chức lại và đơn giản hóa sơ đồ : Bằng cách sử dụng sự tổng quát hóa. 12
  40. III.6.2.5 Thử các đường truy xuất đến các lớp : Ví dụ: Quản lý hàng tồn + NV + maNV Variable character(4) + Thu kho + ho NV Variable character(20) + ten NV Variable character(7) + dia chi Variable character(128) - nam sinh Integer(2) 1 1 + ngay bat dau Date(8) > giu 1 * + Kho + ma kho + ten kho + dia chi kho + so DT lap + ds hang chua () : Hang + ds hang cua phieu (AV) : Hang + Hang + ma hang 1 + ten hang + DS phieu nhap 1 * + DS so thu tu phieu lien quan ghi phieu 1 * 0 * 1 * 1 * + Phieu N_X + Ghi phieu + Ghi hoa don + so phieu + so luong + so luong + ngay lap + don gia ghi HD + don gia + loai phieu + ds hang 0 * cho 0 * + NV ke toan 1 * + Hoa don 0 * 1 + so hoa don tao boi + ngay lap hoa don - so seri + la HD ban + tri gia HD III.6 2.6 Tinh lọc hóa sơ đồ: Khi so khớp lại với người sử dụng, hoặc với sơ đồ hoạt vụ, ta có thể : - Bớt đi liên kết giữa các lớp, nếu đó là liên kết suy diễn, hoặc không tương ứng với nhu cầu trong thế giới thực, - Chuyển lớp sang thuộc tính nếu nó không đóng vai trò thực sự quan trọng trong thế giới thực, hoặc không cần có dạng bảng mã. v.v - Ngược lại, cũng có thể thêm liên kết. - Chuyển một thuộc tính sang thành một lớp, chẳng hạn khi muốn đưa vào bảng mã tương ứng để hỗ trợ nhập liệu, hạn chế dữ liệu sai. III.6.2.7 Thiết lập các phương thức cho mỗi lớp : Các phương thức sẽ được bổ sung đầy đủ và chính xác sau khi so khớp với các sơ đồ khác như sơ đồ họat vụ, sơ đồ tuần tự hoặc sơ đồ cộng tác, sơ đồ hoạt động Ngược lại, sơ đồ hoạt vụ cũng sẽ được bổ sung sau khi lập các phương thức. 13
  41. Phương thức được thiết lập có thể bao gồm các phương thức lớp hoặc không. Ví dụ : có sơ đồ lớp như dưới đây và ta muốn thêm phương thức cho lớp « Lớp » + Lop + Mon - ma lop - ma mon - ten lop 0 * 0 * - si so - co thuc hanh - ban + Hoc 0 * - so tiet hoc o 1 + Phong + Thiet bi 1 * 1 * - ma TB trang bi - ten TB - tri gia Có các loại phương thức sau (phương thức lớp được ký hiệu là « * »): a. Hiển thị đối tượng đang xét: Ví dụ : hienLop() ; b. Hiển thị tất cả các đối tượng của lớp đang xét (*): Ví dụ : hienDsLop() ; c. Hiển thị tất cả các đối tượng của lớp đang xét, có sắp theo nhóm (*): Ví dụ : hienDsLopTheoSiso(); hienDsLopTheoBan(); hienDsLopTheoMon() ; hienDsLopTheoThietbi() ; d. Tìm kiếm đối tượng tương ứng khóa đối tượng (hoặc OID) của chính lớp đang xét (*) : Ví dụ : dsLop (ma_lop : string) : Lop ; e. Tìm kiếm tất cả các đối tượng hoặc tất cả các khóa đối tượng (hoặc OID) của chính lớp đang xét (*) : o Không tham sô o Có tham số, dựa trên khóa của Class_1 : chỉ trả về tối đa 1 đối tượng o Có tham số, dựa trên các thuộc tính của Class_1 Lưu ý : Khi tham số tương ứng với khóa của lớp, kết quả trả về chỉ 1 đối tượng. Ngược lại, trả về một mảng nhiều đối tượng, hoặc mảng nhiều khóa đối tượng. 14
  42. Ví dụ : Ta có các phương thức sau : dsLop() : Lop[ ] ; dsLop (ma_lop : string) : Lop ; dsLop (b : char) : Lop ; // tìm theo ban A, B, C, dsLop(si_so : integer) : Lop[ ] ; dsLop(si_so_min, si_so_max : integer) : Lop[ ] ; dsMaLop() : string[ ] ; dsMaLop (b : char) : string; // tìm theo ban của lớp dsMaLop(si_so : integer) : string[ ] ; dsMaLop(si_so_min, si_so_max : integer) : string[ ] ; f. Tìm kiếm các đối tượng/ OID của ít nhất một lớp khác C có liên kết với đối tượng đang xét c1 của Class_1: - Khởi đầu từ tìm kiếm qua 1 liên kết : o Không tham số o Có tham số, dựa trên các thuộc tính của C o Có tham số, dựa trên các thuộc tính của lớp liên kết (nếu có) Lưu ý : Kết quả trở về của phương thức sẽ là mảng (array) hay chỉ là một đối tượng hoặc một dữ liệu có kiểu dữ liệu sơ cấp, tùy thuộc vào bản số của Class_1 tham gia vào liên kết. Ví dụ : dsMon() : Mon[] ; dsMon(co_TH : boolean) : Mon[] ; dsMon(so_tiet : integer) : Mon[] ; dsMon(so_tiet_min, so_tiet_max : integer) : Mon[] ; dsMon(co_TH : boolean, so_tiet : integer) : Mon[] ; dsMon(co_TH : boolean, so_tiet_min, so_tiet_max : integer) : Mon[] ; phong(): Phong; dsMaMon() : string[] ; dsMon(co_TH : boolean) : string[] ; dsMaMon(so_tiet : integer) : string[] ; dsMaMon(so_tiet_min, so_tiet_max : integer) : string[] ; dsMaMon(co_TH : boolean, so_tiet : integer) : string[] ; dsMaMon(co_TH : boolean, so_tiet_min, so_tiet_max : integer) : string[] ; maPhong(): string; - Sau đó, có thể mở rộng tìm kiếm các đối tượng có liên kết với đối tượng đang xét qua n>1 liên kết. Ví dụ : dsThietbi(): Thietbi[]; // danh sách thiết bị trong phòng của lớp học đang xét dsThietbi(tri_gia: longint): Thietbi[]; dsThietbi(tri_gia_min, tri_gia_max: longint): Thietbi[]; g. Thống kê dùng hàm kết tập: Dùng các hàm kết tập (sum, count, max, min, avg) để tính ra kết quả. 15
  43. - Chỉ tính trên đối tượng đang xét - Chỉ tính trên lớp đang xét (*) o Dựa trên các thuộc tính của lớp đang xét o Dựa vào các mối liên kết với các lớp khác - Tính trên lớp kết nối với lớp đang xét (*) - Cũng có dạng không/ có tham số như trên Ví dụ : tsLop() : integer ; // tổng số lớp tsLop (b : char) : integer ; // tìm theo một ban tsLop(si_so : integer) : integer ; tsLop(si_so_min, si_so_max : integer) : integer ; tsLop(mon: Mon) : integer ; tsLop(ma_mon: string) : integer ; tsLop(tb: Thietbi) : integer ; tsLop(ma_thietbi: string) : integer ; tsLop(p: Phong() : integer; tsLop(ma_phong: string) : integer ; tsMon() : integer ; tsMon(co_TH : boolean) : Mon[] ; tsMon(so_tiet : integer) : Mon[] ; tsMon(so_tiet_min, so_tiet_max : integer) : Mon[] ; tsMon(co_TH : boolean, so_tiet : integer) : Mon[] ; tsMon(co_TH : boolean, so_tiet_min, so_tiet_max : integer) : Mon[] ; tsThietbi(): integer ; // tổng số thiết bị có trong phòng học của lớp đang xét tsThietbi(tri_gia: longint): integer ; tsThietbi(tri_gia_min, tri_gia_max: longint): integer ; tbinhSiso(): integer; // trung bình sĩ số tính trên tất cả các lớp tbinhSiso(b: char): integer; // trung bình sí số tính trên tất cả các lớp của một ban tbinhSotietLop(): integer; //trung bình số tiết học tính trên tất cả các môn của lớp đang xét maxSotietLop(): integer; // //số tiết tối đa tính trên tất cả các môn của lớp đang xét minSotietLop(): integer; // //số tiết tối thiểu tính trên tất cả các môn của lớp đang xét tbinhSotiet(): integer; //trung bình số tiết học tính trên tất cả các môn của tất cả các lớp maxSotiet(): integer; // //số tiết tối đa tính trên tất cả các môn của tất cả các lớp minSotiet(): integer; // //số tiết tối thiểu tính trên tất cả các môn của tất cả các lớp h. Hiển thị kết quả thống kê dùng hàm kết tập trên nhóm (*): 16
  44. Dùng các hàm kết tập (sum, count, max, min, avg) để tính ra kết quả. - Chỉ tính trên lớp đang xét o Dựa trên các thuộc tính của lớp đang xét o Dựa vào các mối liên kết với các lớp khác - Tính trên lớp kết nối với lớp đang xét - Cũng có dạng không/ có tham số như trên Ví dụ : tsLopTheoSiso(); tsLopTheoBan(); tsLopTheoMon() ; tsLopTheoPhong() ; tsLopTheoThietbi() ; trbinhSisoLopTheoBan(); trbinhSisoLopTheoMon() ; trbinhSisoLopTheoThietbi() ; i. Tìm kiếm đối tượng có một thuộc tính lớp/ thuộc tính liên kết đạt trị min/ max: Ví dụ : lopDongNhat(): Lop []; // ds các lớp có sĩ số đạt max lopHocMonLauNhat(): Lop []; // ds các lớp có số tiết học một môn đạt max j. Tìm kiếm đối tượng có một kết quả hàm kết tập theo nhóm đạt trị min/ max: Ví dụ : lopNhieuMonNhat(): Lop[]; // ds các lớp học nhiều môn nhất lopNhieuMonThuchanhNhat(): Lop[]; // ds các lớp học nhiều môn thực hành nhất (co thuc hanh=true) lopNhieuMonLythuyetNhat(): Lop[]; // ds các lớp học nhiều môn thực hành nhất (co thuc hanh=false) lopNhieuMonNhat(so_tiet: integer): Lop[]; // ds các lớp học nhiều môn có số tiết bằng so_tiet nhất lopNhieuThietbi(): Lop[]; // ds các lớp học với nhiều thiết bị nhất III.6.2.8 Chuyển sơ đồ lớp từ mức quan niệm sang mức luận lý. Ví dụ : 17
  45. NV PK_NV THU_KHO MA_NV PK_THU_KHO HO_NV MA_NV TEN_NV HO_NV DC_NV TEN_NV NAM_SINH DC_NV NGAY_BD NAM_SINH NGAY_BD KHO PK_KHO MA_KHO HANG MA_NV PK_HANG TEN_KHO MA_HG DC_KHO TEN_HG SO_DT GHI_PHIEU PK_GHI_PHIEU MA_HG GHI_HOA_DON PHIEU_N_X SO_PH PK_GHI_HOA_DON SL MA_HG PK_PHIEU_N_X DG SO_HD SO_PH SL MA_KHO DG MA_NV NGAY LOAI_PH HOA_DON NV_KE_TOAN PK_HOA_DON PK_NV_KE_TOAN CHO SO_HD MA_NV PK_CHO MA_NV HO_NV SO_PH NGAY_LAP_HOA_DON TEN_NV SO_HD SO_SERI_HD DC_NV LA_HD_BAN NAM_SINH TRI_GIA_HD NGAY_BD III.6.2.9 Đóng gói : Như ở sơ đồ hoạt vụ. 18
  46. Chương IV: Sơ đồ tương tác (interaction diagram) Chương IV: Sơ đồ tương tác (interaction diagram) 1 IV.1 GIỚI THIỆU : 2 IV.2 LỢI ÍCH CỦA TƯƠNG TÁC (interaction): 2 IV.2.1 Định nghĩa: 2 IV.2.1.1 Tương tác (interaction): 2 IV.2.1.2 Sinh tuyến (đường đời: lifeline) 2 IV.2.1.3 Sơ đồ tương tác: 2 IV.2.2 Ký hiệu : 2 IV.2.2.1 Sơ đồ tương tác: 2 IV.2.2.2 Sinh tuyến: 3 IV.2.3 Ứng dụng của sơ đồ tương tác : 3 IV.3 THÔNG BÁO (message): 4 IV.3.1 Các dạng thông báo : 4 IV.3.2 Ký hiệu : 4 IV.3.2.1 Thông báo đồng bộ và thông báo không đồng bộ : 4 IV.3.2.2 Tạo và hủy đối tượng : 4 IV.3.3 Thông báo và sự kiện : 5 IV.3.4 Ngữ pháp của thông báo : 6 IV.3.4.1 Thông báo gửi : 6 IV.3.4.3 Thông báo trả lời: 6 IV.3.5 Ràng buộc trên các sinh tuyến: 6 IV.3.6 Các kiểu phân đoạn của tương tác: 7 IV.3.6.1 Rẽ nhánh : 7 IV.3.6.2 Vòng lặp : 8 IV.3.6.3 Xử lý song song: 9 IV.3.6.4 Các toán tử assert, ignore và consider : 9 IV.3.7 Phân rã một sinh tuyến: 9 1
  47. IV.1 GIỚI THIỆU : Sơ đồ hoạt vụ chỉ ra các tác nhân tương tác với các chức năng lớn của một hệ thống. Đó là một cách nhìn thiên về chức năng và từ bên ngoài hệ thống. Sơ đồ lớp mô tả nhân của hệ thống với các lớp và cách thức chúng kết hợp lại với nhau. Đó là một cách nhìn tĩnh và thiên về cấu trúc. Các sơ đồ tương tác, về phần mình, cho phép đặt cầu nối giữa hai cách tiếp cận trên. Chúng cho thấy làm thế nào các thể hiện ở trong lòng hệ thống có thể tương tác với nhau để thực hiện một chức năng nào đó. Các tương tác khá nhiều và rất đa dạng, cần có một ngôn ngữ phong phú để biểu diễn chúng. UML cung cấp nhiều sơ đồ cho mục đích này : sơ đồ tuần tự (sequence diagram), sơ đồ cộng tác (collaboration diagram, hoặc còn gọi là sơ đồ liên lạc, sơ đồ truyền thông- communication diagram), sơ đồ về thời gian (timing diagram). Các sơ đồ này mang lại phong cách động cho việc mô hình hóa hệ thống. IV.2 LỢI ÍCH CỦA TƯƠNG TÁC (interaction): IV.2.1 Định nghĩa: IV.2.1.1 Tương tác (interaction): Một tương tác định nghĩa hành vi của một hệ có cấu trúc (một hệ thống con, một trường hợp sử dụng, một lớp, một thành tố, ) bằng cách đặc biệt chú trọng đến việc trao đổi các thông tin giữa các thể hiện (instances) của nó. IV.2.1.2 Sinh tuyến (đường đời: lifeline) Một sinh tuyến biểu diễn một thành phần duy nhất (có thể tương ứng với một người ngoài thế giới thực, hoặc một đối tượng trong lớp dữ liệu) tham gia vào một tương tác. IV.2.1.3 Sơ đồ tương tác: Các sơ đồ tuần tự và sơ đồ liên lạc biểu diễn các tương tác giữa các sinh tuyến. Một sơ đồ tuần tự chỉ ra các tương tác dưới góc độ thời gian, đặc biệt là các chuỗi thông báo (messages) trao đổi nhau giữa các sinh tuyến, trong khi một sơ đồ liên lạc biểu diễn về mặt không gian của các sinh tuyến. Còn có dạng thứ ba của sơ đồ tương tác là sơ đồ thời gian nhằm mô hình hóa các hệ thống được khai thác dưới những điều kiện nghiêm ngặt về TG, chẳng hạn các hệ thống thời thực. Tuy nhiên, các sơ đồ tuần tự hoàn toàn có thể thực hiện chức năng này. IV.2.2 Ký hiệu : IV.2.2.1 Sơ đồ tương tác: Biểu diễn bằng một hình chữ nhật, góc trái có tên của sơ đồ, đứng sau từ khóa : - sd : nếu là sơ đồ tuần tự - com : nếu là sơ đồ liên lạc/ sơ đồ cộng tác Có thể có : - danh sách các sinh tuyến đứng tiếp theo với từ khóa lifelines và dấu hai chấm. - ràng buộc trên ít nhất một thuộc tính nào đó có dùng trong sơ đồ 2
  48. IV.2.2.2 Sinh tuyến: Một sinh tuyến được biểu diễn bằng một hình chữ nhật hoặc một hình người « treo » một đường thẳng dọc có chấm. Trong hình chữ nhật hoặc phía dưới hình người chứa một định danh có ngữ pháp như sau : [ [ ] ] : Ví dụ : sd Rút tiền lifelines :KH, :Máy rút tiền, : Ngân hàng + ma: String: readonly ‘0000’<=ma<=’9999’ : Máy rút tiền : Ngân hàng : KH đưathẻ HiệnNhậpmã NhậpMã (ma) Ktra (ma) NH_OK= Ktra (ma) IV.2.3 Ứng dụng của sơ đồ tương tác : Các sơ đồ tương tác được sử dụng trong suốt một dự án, từ khi thu thập các nhu cầu cho đến khi thiết kế. Chúng dùng để : - mô tả các trường hợp sử dụng - mô hình hóa việc sử dụng một lớp hoặc một phương thức của lớp - thêm vào khía cạnh động cho việc mô hình hóa một hệ thống. Sơ đồ lớp trước tiên mô hình hóa lĩnh vực nào mà hệ thống sẽ được sử dụng trong đó, và lĩnh vực này tương đối độc lập với các CT ứng dụng (application) sẽ đến kết hợp bám chặt trên đó. Việc cài đặt một sơ đồ lớp chỉ là một cơ sở để phát triển trình ứng dụng. Cái đặc trưng cho một trình ứng dụng, chính là cách thức nó sử dụng sơ đồ lớp ra sao, tức cách thức các thể hiện của lớp tương tác nhau để thực hiện các chức năng của trình ứng dụng đó. Không có khía cạnh động này, một hệ thống chỉ là thuần túy tĩnh và không mang lại chức năng gì. Ta không nên mô tả tất cả các tương tác chỉ trên một sơ đồ. Cần phải nhắm vào một hệ thống con và nghiên cứu cách thức các phần tử của nó tương tác nhau để mô tả một ứng xử (behavior) đặc thù của hệ thống. Sơ đồ tuần tự thường dùng để mô tả các tương tác trong một hệ thống con, một trường hợp sử dụng, một lớp, một thành tố, , tức trong một hệ có cấu trúc. Còn sơ đồ liên lạc dùng trong một ngữ cảnh đặc thù nào đó nhằm sử dụng một chức năng nào đó của hệ thống. 3
  49. Ở đây, ta chủ yếu nghiên cứu về sơ đồ tuần tự. IV.3 THÔNG BÁO (message): IV.3.1 Các dạng thông báo : Các thông tin chủ yếu chứa trong các sơ đồ tuần tự là các thông báo. Một thông báo định nghĩa một liên lạc giữa các sinh tuyến. Có nhiều dạng thông báo, trong đó phổ biến nhất là dạng: (1) : Gửi một tín hiệu. Thông báo khởi động một phản ứng nơi đối tượng nhận. một cách không đồng bộ và không cần đợi trả lời. (2) : Kích hoạt thực hiện một thao tác trong một phương thức. Đây là dạng thông báo được sử dụng nhiều nhất trong lập trình hướng đối tượng. Ví dụ : dt.pt(), trong đó dt là đối tượng nhận thông báo và pt là một phương thức của dt. Trong thực tế, đa số thông báo loại này là đồng bộ. Cũng có thể thực hiện thông báo dạng này một cách không đồng bộ qua các thread. (3) : Tạo hoặc hủy một thể hiện (đối tượng) IV.3.2 Ký hiệu : IV.3.2.1 Thông báo đồng bộ và thông báo không đồng bộ : Trong UML, (1) và (2) được biểu diễn như nhau, và hướng về đối tượng nhận. Tuy nhiên, UML phân biệt : - Thông báo đồng bộ (synchrone) : Ở cuối mũi tên, ở đối tượng nhận, có thể có trả lời phản hồi bằng mũi tên đứt đọan - Thông báo không đồng bộ (asynchrone) : Thông báo đồng bộ Thông báo không đồng (synchrone) bộ (asynchrone) Cách 1 Cách 2 IV.3.2.2 Tạo và hủy đối tượng : - Tạo đối tượng : đốitgMới: Lớp - Hủy đối tượng : 4
  50. IV.3.3 Thông báo và sự kiện : UML phân biệt việc gửi với nhận một thông báo, cũng như phân biệt việc bắt đầu với việc kết thúc thực hiện một phản ứng. Các sự kiện (event) được dùng để đánh dấu từng giai đoạn. Ví dụ : sd Rút tiền : Máy rút tiền KH sự kiện bắt sự đưathẻ đầu thực hiện kiện gửi sự kiện nhận sự kiện chấm dứt thực hiện Hoặc : sd Rút tiền : Máy rút tiền KH sự kiện bắt sự đưathẻ đầu thực hiện ki ện gửi sự kiện nhận Kiểm tra thẻ sự kiện chấm dứt thực hiện Dựa vào các sự kiện gửi và nhận, UML định nghĩa 3 kiểu thông báo : - Thông báo đầy đủ : các sự kiện gửi và nhận đều được biết - Thông báo bị lạc : sự kiện gửi có được biết, nhưng sự kiện nhận thì không. Ký hiệu : 5
  51. - Thông báo tìm được : ngược lại, sự kiện nhận có được biết, nhưng sự kiện gửi thì không. Ký hiệu : IV.3.4 Ngữ pháp của thông báo : IV.3.4.1 Thông báo gửi : Thông báo gửi có ngữ pháp dưới đây : [ ( ) ] Trong danh sách, các tham số cách nhau bởi dấu phẩy, và mỗi tham số có ngữ pháp như sau : [ ] ] với : là dấu ‘=’ nếu đó là tham số chỉ đọc, dấu ‘ :’ nếu đó là tham số có thể sửa được (đọc/ ghi) Ví dụ : nhậpMã(« 1234 ») nhậpMã(m) ghiNhận(maSV, maSach) sửaSolg(sl : 10) IV.3.4.3 Thông báo trả lời: Thông báo trả lời có ngữ pháp dưới đây : [ = ] [ : ] Ví dụ : sốlgTồn= ktraHgTồn(« A001 ») maOK=ktraMa(ma) :true IV.3.5 Ràng buộc trên các sinh tuyến: Các sinh tuyến của một tương tác có thể mang đủ loại ràng buộc. Ký hiệu: - Một ràng buộc được biểu diễn trên một sinh tuyến bằng một văn bản giữa dấu móc ({ }). - Một ràng buộc cũng có thể được chứa trong một ghi chú gắn với thể hiện của sự kiện liên quan. 6
  52. sd Rút tiền : Máy KH ycầu_rút (sotien) assert ktraTìền(sotien) { Máy.tiềnMặt>sotien } rút (sotien) (Phép assert khẳng định sự cần thiết của việc gửi thông báo tiếp theo. Như vậy, để rút được tiền ở một máy rút tiền, bắt buộc phải kiểm tra số tiền mặt hiện có trong máy ; sau khi kiểm tra, thuộc tính tiềnMặt của Máy phải lớn hơn sotien.) Ghi chú : Một ràng buộc được đánh giá khi khai thác tương tác. Nếu ràng buộc không được thỏa mãn, các thể hiện của sự kiện đi theo sau ràng buộc nay sẽ được xem là không hợp lệ, ngược lại với khi ràng buộc được thỏa mãn. Như vậy, một sơ đồ tương tác có thể mô tả các thông báo không hợp lệ, nghĩa là không bao giờ được gửi đi. IV.3.6 Các kiểu phân đoạn của tương tác: IV.3.6.1 Rẽ nhánh : Có 2 từ khóa là : - « alt » (alternative)và “else’: rẽ nhánh 1 nếu điều kiện đúng và rẽ nhánh 2 nếu ngược lại. - « opt » (optional) : thực hiện hành vi tiếp theo nếu điều kiện đúng. 7
  53. Ví dụ : (giả sử thuộc tính nn chỉ có 2 trị là « Anh » và « Việt ») sd Rút tiền : Máy chọnNgônNgữ KH nn alt [ nn=’Việt’ ] hiệnMànHìnhViệt() [else ] hiệnMànHìnhAnh() rút (sotien) IV.3.6.2 Vòng lặp : Sử dụng 2 từ khóa : - « loop » : có 3 trường hợp : o Loop : lặp mãi đến khi có lệnh « break » o Loop : còn lặp lại khi điều kiện còn thỏa o Loop [ , ] : thường có dạng loop [1, n], lặp lại các bước lặp theo chỉ số nhận trị từ đến . Lưu ý : các biến trong điều kiện và các chỉ số phải được gán trị trước khi đặc tả loop. - « break » : để thoát ra khỏi vòng lặp. sd Xem tài khoản tk[i]: TK KH NV NH n loop[1,n] trigia() tg=trigia() tg=trigia() 8
  54. IV.3.6.3 Xử lý song song: Dùng từ khóa « par » (parallel). IV.3.6.4 Các toán tử assert, ignore và consider : Toán tử assert có tác dụng và ngữ pháp như đã trình bày ở phần IV.3.5. Các phép ignore và consider cho phép tập trung chú ý để mô hình hóa một số thông báo có thể được gửi trong một tương tác. ignore định nghĩa các thông báo có thể bỏ qua, còn consider định nghĩa các thông báo cần phải chú ý đến. Ngữ pháp : Các toán tử assert, ignore và consider được đặt sau tên của sơ đồ tuần tự, với ngữ pháp như sau : ignore { danh sách thông báo} consider { danh sách thông báo} IV.3.7 Phân rã một sinh tuyến: Đôi khi, một tương tác quá phức tạp để có thể đưoc mô tả trong một sơ đồ thôi, nên ta có thể cắt một sinh tuyến ra trên nhiều sơ đồ. Một phần của sinh tuyến được phân rã ra sẽ được thay thế bằng một hình chữ nhật với từ khóa ref, và được trình bày ở sơ đồ khác. sd Rút tiền lifelines :KH, :Máy rút tiền, : Ngân hàng + ma: String: readonly ‘0000’<=ma<=’9999’ : Máy rút tiền : Ngân hàng : KH đưaThẻ ma ref ktraThẻ(ma) ref [ma ok] cấpTiền(ma) 9
  55. Chương V: Các giai đoạn phân tích thiết kế một HTTT Sơ đồ tổng quát của việc thiết lập một HTTT: Việc thiết lập một HTTT bao gồm các công đoạn sau: Phân tích Thiết kế Sử dụng Cài đặt 1. Phân tich: Phân tích hệ thống thông tin hiện hành và đề xuất HTTT tương lai. 2. Thiết kế: Thiết kế một hệ thống tin học thỏa mãn các yêu cầu đã được đặt ra ở công đoạn trước. 3. Cài đặt: Chuyển các phần tử đã được mô tả ở công đoạn 2 sang ngôn ngữ lập trình và hệ quan trị cơ sở dữ liệu cụ thể. 4. Sử dụng: HTTT mới được vận hành từ hệ thống tin học đã cài đặt.
  56. Cụ thể hơn, ta có hình vẽ sau: Lập kế Phân tích Thiết kế họach Sử dụng Cài đặt Triển khai Kiểm thử Ta có thể chia việc phân tích thiết kế thành 7 giai đoạn:
  57. 1. Xác định 2. Thu thập 3. Mô hình hóa lĩnh vực thông tin các luồng công cần thiết việc 4. Đánh giá hệ thống hiện tại 5. Tái cấu hình căn bản cho HTTT 6. Mô hình hóa 7. Biên soạn HTTT tương lai điều kiện sách
  58. Stt Tên Mục đích Phương tiện thực hiện Các mô hình Mức Sử dụng giai UML đoạn 1 Xác Tạo ranh giới - tiếp xúc với cấp lãnh đạo sơ đồ lớp quan niệm - gói định cho HTTT, - tác nhân lĩnh thu thập sơ bộ vực thông tin cho cần dự án thiết - tiếp xúc với người quản trị TT sơ đồ đối quan niệm - trình ứng dụng tượng 2 Thu - Hiểu được - qua các tác nhân đã đề cập trong sơ sơ đồ lớp - quan niệm chỉ dùng các tên thập các khía cạnh đồ lớp ở g/đ 1 lớp, liên kết và các thông khác nhau của - tất cả các thành viên trong HT thực thuộc tinh cần thiết tin HT hiện hành - mô hình tĩnh đã có trong hồ sơ phân trong lớp liên kết - Ghi nhận các tích của HT hiện hành khái niệm - tiếp xúc với người quản trị TT tổng thể về - các giao diện người- máy của HT hiện - luận lý thông tin trong hành lĩnh vực đã - các tài liệu chức năng được sử dụng xác định trong lĩnh vực đang xét - kỉểm tra lại mô hình vật lý suy từ mô hình tĩnh đã có, nhờ vào cấu trúc các tập tin hoặc cơ sở dữ liệu hiên đang được sử dụng 3 Mô - Hiểu các - Ghi nhận những cảm nhận của người - sơ đồ hoạt vụ - quan niệm
  59. hình chức năng sử dụng (qua từng tác nhân) - sơ đồ tuần tự - luận lý hóa hiện hành - Phỏng vấn họ qua các kiểu sự kiện các - Xác định rõ trong lĩnh vực luồng vai trò các tác công nhân khác việc nhau trong hệ thống - Xác định cách thữc các tác nhân phối hợp với nhau để đạt mục tiêu của lĩnh vực đang xét 4 Đánh Đánh giá việc giá hệ quản lý thông thống tin và sự vận hiện hành của các tại quá trình chức năng 5 Tái Sử dụng đánh cấu giá trên để đưa hình ra các nguyên căn tắc mới, khái bản niệm mới cho HTTT
  60. 6 Mô Mô hình hóa - sơ đồ lớp - luận lý hình các khía cạnh - sơ đồ hoạt vụ hóa khác nhau của - sơ đồ tuần tự HTTT HTTT tương tương lai, và phác lai thảo dần điều kiện sách 7 Biên Tạo sưu liệu soạn cho nhà đầu tư điều lẫn nhà thực kiện hiện sách Sự tương đương với cách phân loại khác: Stt Tên giai đoạn Cách phân loại khác 1 Xác định lĩnh vực cần thiết Lập sơ đồ chỉ đạo 2 Thu thập thông tin Thu thập và đặc tả yêu cầu 3 Mô hình hóa các luồng công việc 4 Đánh giá hệ thống hiện tại Nghiên cứu khả thi 5 Tái cấu hình căn bản cho HTTT ( + Thiết kế tổng thể) 6 Mô hình hóa HTTT tương lai Thiết kế chi tiết 7 Biên soạn điều kiện sách Lập sưu liệu