BÀI GIẢNG PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

BÀI GIẢNG PHÂN TÍCH VÀ THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Tài liệu tham khảo [1] Dương Kiều Hoa, Tôn Thất Hồ An Giáo trình phân tích thiết kế hệ thống hướng đối tượng với UML Nhà xuất Thống kê, 2003 [2] Nguyễn Văn Ba Phát triển hệ thống hướng đối tượng với UML 2.0 C++ Nhà xuất Đại học quốc gia Hà Nội, 2005 CHƯƠNG TỔNG QUAN VỀ PHÂN TÍCH THIẾT KẾ HỆ THỐNG GIỚI THIỆU CHUNG 1.1 Định hướng cho phát triển hệ thống Phát triển hệ thống hiểu trình xây dựng hệ thống tin học, kề từ lúc có ý tưởng, đến khảo sát tìm hiểu nhu cầu, phân tích để sâu vào chi tiết, thiết kế làm cho thích ứng với điều kiện kỹ thuật sẵn có, cài đặt thực thi ngơn ngữ lập trình (NNLT) tảng kỹ thuật đó, cuối kiểm chứng chuyển giao Trong giảng này, tập trung vào giai đoạn: tìm hiểu nhu cầu, phân tích, thiết kế cài đặt ngơn ngữ lập trình C++ Để phát triển hệ thống có nhiều phương pháp, song chúng tập trung theo hướng chính: hướng chức hướng đối tượng Phương pháp hướng chức phát triển mạnh vào năm 70, 80 kỷ trước, lấy chức làm đơn vị phân rã tiến hành phân tích hệ thống Câu hỏi hệ thống thường đặt sớm cho người dùng người phát triển là: “Hệ thống phải làm gì?” Bởi nghiên cứu hệ thống dựa vào chức cách làm tự nhiên dễ hiểu Phương pháp hưóng chức dẫn đến việc cài đặt hệ thống NNLT theo thủ tục (Pascal, C, …) Các phương pháp hướng chức có nhược điểm lớn: hệ thống xây dựng theo cách thường khó sửa chữa nâng cấp Phương pháp hướng đối tượng đời vào đầu năm 90 khắc phục đáng kể nhược điểm Phương pháp lấy đối tượng làm đơn nguyên hệ thống Đối tượng kết hợp chức liệu – kết hợp có lý vò chức thao tác số liệu định ngược lại, liệu xử lý số chức Điều khơng hợp lý mà tự nhiên dễ hiểu: đối tượng tin học thường dùng để phản ánh hay mô đối tượng giới thực Phương pháp hướng đối tượng dẫn đến việc cài đặt hệ thống NNLT hướng đối tượng (C++, Java, …) 1.2 Tính trực quan Chúng ta thấy rằng: Một số tập hợp liệu phức tạp định trình bày đồ thị truyền tải đến người đọc nhiều thông tin so với liệu thô Với phần mềm vậy, ngành Công nghiệp phần mềm (CNPM) ngày phát triển, hệ thống trở nên phức tạp Khả nắm bắt kiểm sốt phức tạp kèm với khả trình bày hệ thống cách tồn diện - trình bày vượt ngồi giới hạn dịng lệnh thơ Sự thành công thị trường ngôn ngữ Visual Basic phần giao diện trực quan C++, Java cho thấy trình bày trực quan mang tính cốt yếu q trình phát triển hệ thống phức tạp 1.3 Mơ hình Trước đây, có thời gian dài, ngành CNPM phải nói tới "khủng hoảng phần mềm": Các tranh luận dựa thực tế nhiều đồ án phần mềm sản sinh hệ thống thoả mãn đòi hỏi nhu cầu khách hàng, mà vượt ngân sách thời hạn Các cơng nghệ lập trình hướng đối tượng, lập trình trực quan mơi trường phát triển tiên tiến có giúp nâng cao suất lao động, nhiều trường hợp, chúng hướng tới tầng thấp việc phát triển phần mềm: phần viết lệnh (coding) Một vấn đề ngành phát triển phần mềm thời có nhiều đồ án bắt tay vào lập trình sớm tập trung nhiều vào việc viết code Lý phần ban quản trị thiếu hiểu biết quy trình phát triển phần mềm họ nảy lo âu thấy đội quân lập trình họ khơng viết code Và thân lập trình viên cảm thấy an tâm họ ngồi viết code - vốn tác vụ mà họ quen thuộc! – xây dựng mơ hình trừu tượng cho hệ thống mà họ phải tạo nên Mơ hình dạng trừu tượng hố hệ thống thực Nói chi tiết mơ hình hình ảnh (một biểu diễn) hệ thống thực, diễn tả:   mức độ trừu tượng hố theo quan điểm (góc nhìn)  hình thức diễn tả hiểu (văn bản, đồ thị, mô hình, …) Việc dùng mơ hình để nhận thức, diễn tả hệ thống gọi mô hình hố Như q trình phân tích, thiết kế gọi q trình mơ hình hố hệ thống Mơ hình hố phương thức tư vấn đề cách sử dụng mô hình tổ chức xoay quanh khái niệm thực tế Mơ hình giúp chúng ta:   hiểu vấn đề rõ giao tiếp người có liên quan đến dự án (khách hàng, chuyên gia lĩnh vực thuộc đề án, người phân tích, thiết kế, lập trình viên) dễ dàng  hiểu đòi hỏi hệ thống tốt hơn, tạo thiết kế rõ ràng  xây dựng nên hệ thống dễ bảo trì  dễ kiểm định Từ mục đích trên, ta suy mơ hình tốt phải đạt yêu cầu sau:   dễ đọc, dễ hiểu, dễ trao đổi đầy đủ, chặt chẽ  dễ thực Mơ hình kết trừu tượng hóa nhằm miêu tả thành phần cốt yếu vấn đề hay cấu trúc phức tạp qua việc lọc bớt chi tiết không quan trọng làm cho vấn đề trở thành dễ hiểu Trừu tượng hóa lực người, cho phép giải vấn đề phức tạp Các kỹ sư, nghệ sĩ thợ thủ cơng xây dựng mơ hình từ hàng ngàn năm để thử nghiệm thiết kế trước thực Phát triển phần mềm không ngoại lệ Để xây dựng hệ thống phức tạp, nhà phát triển phải trừu tượng hóa theo nhiều hướng nhìn khác hệ thống, sử dụng ký hiệu xác để xây dựng mơ hình, kiểm tra xem mơ hình có thỏa mãn địi hỏi hệ thống, bổ sung thêm chi tiết để chuyển mơ hình thành thực Chúng ta xây dựng mơ hình cho hệ thống phức tạp hiểu thấu đáo hệ thống trạng thái toàn vẹn chúng Khả thấu hiểu nắm bắt tính phức tạp người có hạn Điều ta thấy rõ ví dụ ngành xây dựng Nếu bạn muốn tạo túp lều góc vườn, bạn bắt tay vào xây Nếu bạn xây ngơi nhà, có lẽ bạn cần tới vẽ, bạn muốn xây nhà chọc trời chắn bạn khơng thể khơng cần vẽ Thế giới phần mềm Chỉ tập trung vào dòng code hay chí phân tích Forms Visual Basic khơng thể cung cấp nhìn tồn cục việc phát triển đồ án Xây dựng mơ hình cho phép nhà thiết kế tập trung vào tranh toàn cảnh tương tác thành phần đồ án, tránh bị sa lầy vào chi tiết riêng biệt thành phần CHU TRÌNH PHÁT TRIỂN PHẦN MỀM 2.1 Sự phức tạp phát triển phần mềm Kinh nghiệm nhiều nhà thiết kế phát triển cho thấy phát triển phần mềm thường toán phức tạp Xin nêu số lý thường kể đến:   Những người phát triển phần mềm khó hiểu cho người dùng cần Yêu cầu người dùng thường thay đổi thời gian phát triển  Yêu cầu thường miêu tả văn bản, dài dịng, khó hiểu, nhiều mâu thuẫn  Đội quân phát triển phần mềm, vốn người "ngồi cuộc", khó nhận thức thấu đáo mối quan hệ tiềm ẩn phức tạp vấn đề nghiệp vụ cần thể xác ứng dụng lớn  Khả nắm bắt liệu phức tạp người (tại thời điểm) có hạn  Khó định lượng xác hiệu suất thành phẩm thỏa mãn xác mong chờ từ phía người dùng  Chọn lựa phần cứng phần mềm thích hợp cho giải pháp thách thức lớn người thiết kế (Designer) Phần mềm ngồi cần có khả thích ứng mở rộng Phần mềm thiết kế tốt phần mềm đứng vững trước biến đổi môi trường, dù từ phía cộng đồng người dùng hay từ phía cơng nghệ Ví dụ phần mềm phát triển cho ngân hàng cần có khả tái sử dụng cho ngân hàng khác với sửa đổi hồn tồn khơng cần sửa đổi Phần mềm thoả mãn yêu cầu coi phần mềm có khả thích ứng Một phần mềm có khả mở rộng phần mềm thiết kế cho dễ phát triển theo yêu cầu người dùng mà không cần sửa chữa nhiều Một số khiếm khuyết thường gặp phát triển phần mềm là:   Hiểu khơng người dùng cần Khơng thể thích ứng cho phù hợp với thay đổi yêu cầu hệ thống  Các Module khơng khớp với  Phần mềm khó bảo trì, nâng cấp, mở rộng  Phát trễ lỗ hổng dự án  Chất lượng phần mềm  Hiệu phần mềm thấp  Các thành viên nhóm khơng biết thay đổi gì, nào, đâu, phải thay đổi 2.2 Chu Trình Phát Triển Phần Mềm (Software Development Life Cycle) Vì phát triển phần mềm tốn khó, nên có lẽ trước hết ta cần điểm qua số công việc trình Thường người ta hay tập hợp chúng theo tiến trình thời gian cách tương đối, xoay quanh chu trình phần mềm, dẫn tới kết qủa khái niệm Chu Trình Phát Triển Phần Mềm (Software Development Life Cycle - SDLC) sau: Chu Trình Phát Triển Phần Mềm chuỗi hoạt động nhà phân tích (Analyst), nhà thiết kế (Designer), người phát triển (Developer) người dùng (User) để phát triển thực hệ thống thông tin   Nhà phân tích (Analyst): người nghiên cứu yêu cầu khách hàng/người dùng để định nghĩa phạm vi toán, nhận dạng nhu cầu tổ chức, xác định xem nhân lực, phương pháp cơng nghệ máy tính để cải thiện cách tốt cơng tác tổ chức Q trình phân tích phải trả lời câu hỏi: Làm gì? Nhà thiết kế (Designer): thiết kế hệ thống (chức năng, database, screens, forms, reports, …), định yêu cầu phần cứng phần mềm cho hệ thống cần phát triển Quá trình thiết kế để trả lời câu hỏi: Làm nào?  Chuyên gia lĩnh vực (Domain Experts): người hiểu thực chất vấn đề tất phức tạp hệ thống cần tin học hố Họ khơng thiết phải nhà lập trình, họ giúp nhà lập trình hiểu yêu cầu đặt hệ thống cần phát triển Quá trình phát triển phần mềm có nhiều thuận lợi đội ngũ làm phần mềm có trợ giúp họ  Lập trình viên (Programmer): người dựa phân tích thiết kế để viết chương trình (coding) cho hệ thống ngơn ngữ lập trình thống  Người dùng (User): đối tượng phục vụ hệ thống cần phát triển Để cho rõ hơn, xin lấy ví dụ vấn đề đơn giản sau: Người bình thường nhìn xe tơ thường có tranh từ bên ngồi sau: Hình 1.1: Nhìn vấn đề tơ người bình thường Chun gia lĩnh vực giúp nhà phân tích "trình bày lại" vấn đề sau: Hình 1.2: Nhìn vấn đề tơ chun gia phân tích Chính trợ giúp chun gia lĩnh vực đóng vai trị quan trọng nên giai đoạn đầu trình phát triển phần mềm, kết phân tích nên thể cho dễ hiểu chuyên gia lĩnh vực Đây môt nhiều lý khiến cho phương pháp hướng đối tượng nhiều người hưởng ứng 2.3 Các giai đoạn Chu Trình Phát Triển Phần Mềm Chu trình phần mềm thường chia thành giai đoạn sau:  Nghiên cứu sơ (Preliminary Investigation)  Phân tích yêu cầu (Analysis)  Thiết kế hệ thống (System Design)  Xây dựng phần mềm (Software Construction)  Thử nghiệm hệ thống (System Testing)  Thực hiện, triển khai (System Implementation)  Bảo trì, nâng cấp (System Maintenance) a) Nghiên cứu sơ bộ: Câu hỏi quan trọng phát triển hệ thống hồn tồn khơng phải câu hỏi mang tính phương pháp luận, mà câu hỏi kỹ thuật Nó câu hỏi dường đơn giản, thật đặc biệt khó trả lời: “Đây có hệ thống để thực khơng?” Đáng buồn câu hỏi thực tế thường đặt Mặc dù việc lầm lẫn phương pháp hay định sai lầm kỹ thuật dẫn tới thất bại, thường dự án cứu vãn có đầy đủ tài nguyên cố gắng quên nhân viên tài giỏi Nhưng chẳng điều cứu vãn cho hệ thống phần mềm hồn toàn chẳng cần tới cố gắng tự động hóa quy trình lầm lạc Trước bắt tay vào dự án, bạn phải có ý tưởng cho Ý tưởng song song với việc nắm bắt yêu cầu xuất giai đoạn khởi đầu Nó hồn tất phát biểu: "Hệ thống mà mong muốn làm việc sau " Trong suốt giai đoạn này, tạo nên tranh ý tưởng đó, nhiều giả thuyết công nhận hay loại bỏ Các hoạt động thời gian thường bao gồm thu thập ý tưởng, nhận biết rủi ro, nhận biết giao diện bên ngoài, nhận biết các chức mà hệ thống cần cung cấp, tạo vài nguyên mẫu dùng để “minh chứng khái niệm hệ thống” Ý tưởng đến từ nhiều nguồn khác nhau: khách hàng, chuyên gia lĩnh vực, nhà phát triển khác, chuyên gia kỹ nghệ, nghiên cứu tính khả thi việc xem xét hệ thống khác tồn Một khía cạnh cần nhắc tới code viết thời kỳ thường bị “bỏ đi”, chúng viết nhằm mục đích thẩm tra hay trợ giúp giả thuyết khác nhau, chưa phải thứ code viết theo kết phân tích thiết kế thấu đáo Trong giai đọan nghiên cứu sơ bộ, nhóm phát triển hệ thống cần xem xét yêu cầu người dùng, nguồn tài nguyên sử dụng, cơng nghệ cộng đồng người dùng ý tưởng họ hệ thống Một giai đoạn nghiên cứu sơ thích đáng lập nên tập hợp yêu cầu (dù mức độ khái quát cao) hệ thống khả thi mong muốn, kể phương diện kỹ thuật lẫn xã hội Một giai đoạn nghiên cứu sơ không thực thoả đáng dẫn tới hệ thống không mong muốn, đắt tiền, bất khả thi định nghĩa lầm lạc – hệ thống thừơng chẳng hoàn tất hay sử dụng Kết giai đoạn nghiên cứu sơ Báo Cáo Kết Quả Nghiên Cứu Tính Khả Thi Khi hệ thống tương lai chấp nhận dựa báo cáo lúc giai đoạn Phân tích bắt đầu b) Phân tích yêu cầu Sau xem xét tính khả thi hệ thống tạo lập tranh sơ dự án, bước sang giai đoạn thường coi quan trọng cơng việc lập trình: hiểu hệ thống cần xây dựng Người thực công việc nhà phân tích Q trình phân tích nhìn chung hệ việc trả lời câu hỏi "Hệ thống cần phải làm gì?" Q trình phân tích bao gồm việc nghiên cứu chi tiết hệ thống doanh nghiệp thời, tìm cho ngun lý hoạt động vị trí nâng cao, cải thiện Bên cạnh việc nghiên cứu xem xét chức mà hệ thống cần cung cấp mối quan hệ chúng, bên với phía ngồi hệ thống Trong tồn giai đoạn này, nhà phân tích người dùng cần cộng tác mật thiết với để xác định yêu cầu hệ thống, tức tính cần phải đưa vào hệ thống Những mục tiêu cụ thể giai đoạn phân tích là:   Xác định hệ thống cần phải làm Nghiên cứu thấu đáo tất chức cần cung cấp yếu tố liên quan  Xây dựng mô hình nêu bật chất vấn đề từ hướng nhìn có thực (trong đời sống thực)  Trao định nghĩa vấn đề cho chuyên gia lĩnh vực để nhận đánh giá, góp ý Kết giai đoạn phân tích Đặc Tả Yêu Cầu (Requirements Specifications) c) Thiết kế hệ thống Sau giai đoạn phân tích, yêu cầu cụ thể hệ thống xác định, giai đoạn thiết kế cho yêu cầu Công tác thiết kế xoay quanh câu hỏi chính: “Hệ thống làm cách để thỏa mãn yêu cầu nêu Đặc Tả Yêu Cầu? ” Một số công việc thường thực giai đoạn thiết kế:   Nhận biết form nhập liệu tùy theo thành phần liệu cần nhập Nhận biết reports output mà hệ thống phải sản sinh  Thiết kế forms (vẽ giấy hay máy tính, sử dụng công cụ thiết kế)  Nhận biết thành phần liệu bảng để tạo database  Ước tính thủ tục giải thích q trình xử lý từ input đến output Kết giai đoạn thiết kế Đặc Tả Thiết Kế (Design Specifications) Bản Đặc Tả Thiết Kế chuyển sang cho lập trình viên để thực giai đoạn xây dựng phần mềm d) Xây dựng phần mềm Đây giai đoạn viết lệnh (code) thực sự, tạo hệ thống Từng người viết code thực yêu cầu nhà thiết kế định sẵn Cũng người viết code chịu trách nhiệm viết tài liệu liên quan đến chương trình, giải thích thủ tục (procedure) mà tạo nên viết lý cho việc Để đảm bảo chương trình viết nên phải thoả mãn yêu cầu có ghi trước Đặc Tả Thiết Kế, người viết code đồng thời phải tiến hành thử nghiệm phần chương trình Phần thử nghiệm giai đoạn chia thành hai bước chính: Thử nghiệm đơn vị: Người viết code chạy thử phần chương trình với liệu giả (test/dummy data) Việc thực theo kế hoạch thử, người viết code soạn Mục đích giai đoạn thử xem chương trình có cho kết mong đợi Giai đoạn thử nghiệm đơn vị nhiều gọi "Thử hộp trắng" (White Box Testing) Thử nghiệm đơn vị độc lập: Công việc thành viên khác nhóm đảm trách Cần chọn người khơng có liên quan trực tiếp đến việc viết code đơn vị chương trình cần thử nghiệm để đảm bảo tính “độc lập” Cơng việc thử đợt thực dựa kế hoạch thử người viết code soạn nên e) Thử nghiệm hệ thống Sau thủ tục thử nghiệm riêng, cần phải thử nghiệm toàn hệ thống Mọi thủ tục tích hợp chạy thử, kiểm tra xem chi tiết ghi Đặc Tả Yêu Cầu mong chờ người dùng có thoả mãn Dữ liệu thử cần chọn lọc đặc biệt, kết cần phân tích để phát lệch lạc so với mong chờ f) Thực hiện, triển khai Trong giai đoạn này, hệ thống vừa phát triển triển khai cho phía người dùng Trước để người dùng thật bắt tay vào sử dụng hệ thống, nhóm nhà phát triển cần tạo file liệu cần thiết huấn luyện cho người dùng, để đảm bảo hệ thống sử dụng hữu hiệu g) Bảo trì, nâng cấp Tùy theo biến đổi môi trường sử dụng, hệ thống trở nên lỗi thời hay cần phải sửa đổi nâng cấp để sử dụng có hiệu Hoạt động bảo trì hệ thống khác biệt tùy theo mức độ sửa đổi nâng cấp cần thiết TIẾN TRÌNH RUP Tiến trình RUP (Rational Unified Process) tiến trình mơ hình hố với UML nhóm “ba người bạn” (Rumbaugh, Jacobsson Booch) đưa Đây quy trình phát triển phần mềm theo kinh nghiệm họ chuẩn, nhiên sử dụng rộng rãi 3.1 Các nguyên tắc RUP Tiến trình RUP tiến trình phát triển phần mềm dựa nguyên tắc lặp tăng trưởng, tập trung vào kiến trúc, dẫn dắt theo ca sử dụng khống chế nguy a) Lặp tăng trưởng Dự án cắt thành vòng lặp giai đoạn ngắn cho phép kiểm soát dễ dàng tiến triển dự án Cuối vịng lặp phần thi hành hệ thống sản sinh theo cách tăng trưởng (thêm vào dần dần) b) Tập trung vào kiến trúc Hệ thống phức tạp cần phân chia thành phần để dễ dàng triển khai, tạo nên kiến trúc Kiến trúc trình bày theo góc nhìn khác biểu đồ UML c) Dẫn dắt theo ca sử dụng RUP nhấn mạnh đáp ứng nhu cầu người sử dụng, thể ca sử dụng Do ca sử dụng ảnh hưởng dẫn đường cho giai đoạn phát triển hệ thống Nắm bắt nhu cầu để phát ca sử dụng Phân tích sâu vào ca sử dụng Thiết kế cài đặt để xây dựng hệ thống theo tưng ca sử dụng Kiểm định nghiệm thu hệ thống thực theo ca sử dụng Ca sử dụng để xác định vòng lặp tăng trưởng, để phân cơng cơng việc nhóm phát triển d) Khống chế nguy Các nguy dự án cần phát sớm phải loại bỏ sớm tốt Yêu cầu để xác định thứ tự trước sau vòng lặp 3.2 Các pha tiến trình RUP Tiến trình RUP tổ chức thành pha (phase) nối thời gian là: khởi đầu, triển khai, xây dựng chuyển giao a) Pha khởi đầu Pha khởi đầu (inception) nhằm cho nhìn tổng quát hệ thống cần xây dựng (chức năng, công nghệ, …) dự án triển khai (phạm vi, mục tiêu, tính khả thi, …), từ đưa kết luận có nên phát triển dự án khơng b) Pha triển khai Pha triển khai (elaboration) bao gồm phân tích chi tiết hệ thống, đồng thời kiến trúc hệ thống đề xuất Kiến trúc dựng thành nguyên mẫu (prototype), thử nghiệm nhiều ý đồ với hệ thống c) Pha xây dựng Pha xây dựng (construction) tập trung vào việc thiết kế thực thi (cài đặt) hệ thống Nếu pha triển khai cho kiến trúc hệ thống pha xây dựng kiến trúc 10 Khách hàng nhập số tiền cần rút ATM gửi số tiền cần rút đến cho tài khoản Đối tượng tài khoản trừ số tiền vào mức tiền tài khoản Tại thời điểm này, thấy có mũi tên quay trở lại vào đối tượng tài khoản Ý nghĩa đối tượng tài khoản xử lý yêu cầu nội đối tượng khơng gửi kiện Đối tượng tài khoản trả mức tiền tài khoản cho máy ATM Đối tượng ATM trả mức tiền tài khoản cho khách hàng dĩ nhiên, lượng tiền khách hàng yêu cầu rút Đối tượng tài khoản bắt đầu sinh đối tượng ATM cần tới để kiểm tra mã số đối tượng tài khoản tiếp tục sống giao dịch hoàn tất Sau đó, chết Bởi khách hàng muốn tiếp tục thực giao dịch khác nên đối tượng khách hàng đối tượng máy ATM tiếp tục tồn tại, điều qua việc đường đời đối tượng kéo vượt đường thẳng thể kiện cuối chuỗi tương tác Loại tương tác hữu dụng hệ thống có số lượng nhỏ đối tượng với số lượng lớn kiện xảy chúng Mặc dù vậy, số lượng đối tượng hệ thống tăng lên mơ hình khơng cịn thích hợp Để vẽ biểu đồ tuần tự, xác định đối tượng liên quan thể kiện xảy chúng Khi vẽ biểu đồ tuần tự, cần ý:    Sự kiện biểu diễn đường thẳng nằm ngang Đối tượng đường nằm dọc Thời gian thể đường thẳng nằm dọc biểu đồ Điều có nghĩa kiện cần phải thể theo thứ tự mà chúng xảy ra, vẽ từ xuống BIỂU ĐỒ CỘNG TÁC (COLLABORATION DIAGRAM) Một biểu đồ cộng tác miêu tả tương tác đối tượng giống biểu đồ tuần tự, tập trung trước hết vào kiện, tức tập trung chủ yếu vào tương tác đối tượng Trong biểu đồ cộng tác, đối tượng biểu diễn kí hiệu lớp Thứ tự biểu đồ cộng tác thể cách đánh số thông điệp Kỹ thuật đánh số coi có phần khó hiểu so với kỹ thuật mũi tên sử dụng biểu đồ Nhưng ưu điểm biểu đồ cộng tác chi tiết lệnh gọi hàm (thủ tục), yếu tố né tránh biểu đồ Biểu đồ sau ví dụ cho biểu đồ cộng tác, chuẩn bị cho cảnh kịch rút tiền mặt biểu đồ phần trước Hãy quan sát thứ tự số 98 biểu đồ Đầu tiên thủ tục WithdrawalReq() gọi từ lớp khách hàng Đó lệnh gọi số Bước hàm AskForPin(), số 1.1, gọi từ lớp ATM Thông điệp biểu đồ viết dạng pin:= AskForPin(), thể "giá trị trả về" hàm mã số mà lớp khách hàng cung cấp Hình cung bên lớp tài khoản biểu thị hàm ComputeNetBalance() gọi nội lớp tài khoản xử lý cục Thường thủ tục riêng (private) lớp Hình 6.5- Một biểu đồ cộng tác kích cảnh rút tiền máy ATM BIỂU ĐỒ TRẠNG THÁI (STATE DIAGRAM) Biểu đồ trạng thái nắm bắt vòng đời đối tượng, hệ thống (Subsystem) hệ thống Chúng cho ta biết trạng thái mà đối tượng có kiện (các thông điệp nhận được, khoảng thời gian qua đi, lỗi xảy ra, điều kiện thỏa mãn) ảnh hưởng đến trạng thái dọc theo tiến trình thời gian Biểu đồ trạng thái đính kèm với tất lớp có trạng thái nhận diện rõ ràng có lối ứng xử phức tạp Biểu đồ trạng thái xác định ứng xử miêu tả khác biệt phụ thuộc vào trạng thái, ngồi cịn miêu tả rõ kiện thay đổi trạng thái đối tượng lớp 7.1 Trạng thái biến đổi trạng thái (State transition) Tất đối tượng có trạng thái; trạng thái kết hoạt động trước đối tượng thực thường xác định qua giá trị thuộc tính nối kết đối tượng với đối tượng khác Một lớp có thuộc tính đặc biệt xác định trạng thái, trạng thái xác định qua giá trị thuộc tính “bình thường" đối tượng Ví dụ trạng thái đối tượng: 99 Hóa đơn (đối tượng) trả tiền (trạng thái) Chiếc xe ô tô (đối tượng) đứng yên (trạng thái) Động (đối tượng) chạy (trạng thái) Jen (đối tượng) đóng vai trò người bán hàng (trạng thái) Kate (đối tượng) lấy chồng (trạng thái) Một đối tượng thay đổi trạng thái có việc xảy ra, thứ gọi kiện; ví dụ có trả tiền cho hóa đơn, bật động xe ô tô lấy chồng lấy vợ Khía cạnh động có hai chiều khơng gian: tương tác biến đổi trạng thái nội Tương tác miêu tả lối ứng xử đối ngoại đối tượng đối tượng tương tác với đối tượng khác (qua việc gửi thông điệp, nối kết chấm dứt nối kết) Sự biến đổi trạng thái nội miêu tả đối tượng thay đổi trạng thái – ví dụ giá trị thuộc tính nội thay đổi Biểu đồ trạng thái sử dụng để miêu tả việc thân đối tượng phản ứng trước kiện chúng thay đổi trạng thái nội chúng nào, ví dụ, hóa đơn chuyển từ trạng thái chưa trả tiền sang trạng thái trả tiền có trả tiền cho Khi hóa đơn tạo ra, bước vào trạng thái chưa trả tiền 7.2 Biểu đồ trạng thái Biểu đồ trạng thái thể khía cạnh mà ta quan tâm tới xem xét trạng thái đối tượng:      Trạng thái ban đầu Một số trạng thái Một nhiều trạng thái kết thúc Sự biến đổi trạng thái Những kiện gây nên biến đổi từ trạng thái sang trạng thái khác Hình sau kí hiệu UML thể trạng thái bắt đầu trạng thái kết thúc, kiện trạng thái đối tượng Hình 6.6- Các ký hiệu thể bắt đầu, kết thúc, kiện trạng thái đối tượng 100 Hình 6.7- Biểu đồ trạng thái thực hố đơn Một trạng thái có ba thành phần, hình sau : Hình 6.8- Các ngăn Tên, Biến trạng thái hành động Phần thứ tên trạng thái, ví dụ chờ, trả tiền hay chuyển động Phần thứ hai (không bắt buộc) dành cho biến trạng thái Đây thuộc tính lớp thể qua biểu đồ trạng thái; nhiều biến tạm thời tỏ hữu dụng trạng thái, ví dụ loại biến đếm (counter) Phần thứ ba (không bắt buộc) phần dành cho hoạt động, nơi kiện hành động liệt kê Có ba loại kiện chuẩn hóa sử dụng cho phần hành động: entry (đi vào), exit (đi ra), (thực hiện) Loại kiện vào sử dụng để xác định hành động khởi nhập trạng thái, ví dụ gán giá trị cho thuộc tính gửi thơng điệp Sự kiện sử dụng để xác định hành động rời bỏ trạng thái Sự kiện thực sử dụng để xác định hành động cần phải thực trạng thái, ví dụ gửi thơng điệp, chờ, hay tính tốn Ba loại kiện chuẩn khơng thể sử dụng cho mục đích khác Một biến đổi trạng thái thường có kiện kèm với nó, khơng bắt buộc Nếu có kiện kèm, thay đổi trạng thái thực kiện xảy Một hành động loại thực trạng thái q trình tiếp diễn (ví dụ chờ, điều khiển thủ tục, ) phải thực đối tượng nguyên trạng thái Một hành động thực bị ngắt kiện từ ngồi, có nghĩa kiện kiện gây nên biến đổi trạng thái ngưng ngắt hành động thực mang tính nội tiếp diễn Trong trường hợp biến đổi trạng thái kiện kèm trạng thái thay đổi hành động nội trạng thái thực xong (hành động nội kiểu vào, ra, thực hay hành động người sử dụng định nghĩa) Theo đó, tất hành động thuộc trạng thái thực xong, thay đổi trạng thái tự động xảy mà khơng cần kiện từ ngồi 101 Hình 6.9- Biến đổi trạng thái khơng có kiện từ Sự thay đổi trạng thái xảy hoạt động trạng thái thực xong 7.3 Nhận biết trạng thái kiện Quá trình phát kiện trạng thái mặt chất bao gồm việc hỏi số câu hỏi thích hợp:           Một đối tượng có trạng thái nào?: Hãy liệt kê tất trạng thái mà đối tượng có vịng đời Những kiện xảy ra?: Bởi kiện gây việc thay đổi trạng thái nên nhận kiện bước quan trọng để nhận diện trạng thái Trạng thái gì?: Sau nhận diện kiện, xác định trạng thái kiện xảy trạng thái sau kiện xảy Có thủ tục thực thi?: Hãy để ý đến thủ tục ảnh hưởng đến trạng thái đối tượng Chuỗi tương tác đối tượng gì?: Tương tác đối tượng ảnh hưởng đến trạng thái đối tượng Qui định áp dụng cho phản ứng đối tượng với nhau?: Các qui định kiềm tỏa phản ứng kiện xác định rõ trạng thái Những kiện chuyển tải xảy ra?: Nhiều có số kiện thay đổi trạng thái khơng thể xảy Ví dụ bán ô tô bán Cái khiến cho đối tượng tạo ra?: Đối tượng tạo để trả lời cho kiện Ví dụ sinh viên ghi danh cho khóa học Cái khiến cho đối tượng bị hủy?: Đối tượng bị hủy chúng khơng cần tới Ví dụ sinh viên kết thúc khóa học Cái khiến cho đối tượng cần phải tái phân loại (reclassfied)?: Những loại kiện nhân viên tăng chức thành nhà quản trị khiến cho động tác tái phân loại nhân viên thực 7.4 Một số lời mách bảo cho việc tạo dựng biểu đồ trạng thái Một mơ hình tạo nên, nêu câu hỏi kiểm tra xem mơ hình có khả cung cấp tất câu trả lời Qui trình sau cần phải nhắc lại cho đối tượng 102 Chuyển biểu đồ thành biểu đồ trạng thái Hãy dõi theo chuỗi kiện miêu tả biểu đồ, chuỗi phải mang tính tiêu biểu cho tương tác hệ thống Hãy quan sát kiện ảnh hưởng đến đối tượng mà ta nghiên cứu Hãy xếp kiện thành đường dẫn, dán nhãn input (hoặc entry) output (exit) cho kiện Khoảng cách hai kiện trạng thái Nếu cảnh kịch nhắc nhắc lại nhiều lần (vô giới hạn), nối đường dẫn từ trạng thái cuối đến trạng thái Biểu đồ sau biểu đồ trạng thái lớp máy ATM, chiết suất từ biểu đồ biểu đồ cộng tác trình bày phần trước Hình 6.10- Chuyển biểu đồ sang biểu đồ trạng thái Nhận vịng lặp (loop) Một chuỗi kiện nhắc nhắc lại vô số lần gọi vịng lặp (loop) Hình 6.11- Biểu đồ lặp Chú ý: 103 Trong vòng lặp, chuỗi kiện nhắc nhắc lại cần phải đồng với Nếu có chuỗi kiện khác chuỗi khác trường hợp khơng có vịng lặp Lý tưởng trạng thái vịng lặp có kiện kết thúc Đây yếu tố quan trọng, khơng vịng lặp khơng kết thúc Bổ sung thêm điều kiện biên điều kiện đặc biệt Sau hoàn tất biểu đồ trạng thái cho đối tượng cần thiết hệ thống, đến lúc cần kiểm tra, đối chứng chúng với điều kiện biên điều kiện đặc biệt khác, điều kiện chưa quan tâm đủ độ thời gian tạo dựng biểu đồ trạng thái Điều kiện biên điều kiện thao tác giá trị, giá trị nằm bên ranh giới điều kiện để định trạng thái đối tượng, ví dụ quy định kỳ hạn tài khoản 30 ngày ngày thứ 31 tài khoản điều kiện biên Các điều kiện đặc biệt điều kiện ngoại lệ, ví dụ ngày thứ 30 tháng năm 2000 (nếu có điều kiện tồn đời thực) Trộn lẫn cảnh kịch khác vào biểu đồ trạng thái Một biểu đồ trạng thái cho đối tượng sẵn sàng, cần phải trộn chuỗi kiện có ảnh hưởng đến đối tượng vào biểu đồ trạng thái Điều có nghĩa cần phải quan sát hiệu ứng gián tiếp kiện khác đối tượng chủ đề biểu đồ trạng thái Đây việc quan trọng, đối tượng hệ thống tương tác với đối tượng khác có khả gây nên kiện cho đối tượng định trước, nên lối ứng xử cần phải thể biểu đồ trạng thái Điểm bắt đầu cho công việc là: Ấn định điểm bắt đầu chung cho tất chuỗi kiện bổ sung Xác định điểm nơi ứng xử bắt đầu khác biệt với ứng xử mơ hình hóa biểu đồ trạng thái Bổ sung thêm biến đổi từ trạng thái này, tư cách đường dẫn thay Cần để ý đến đường dẫn ngồi đồng thật có khác biệt tình định Hãy ý đến kiện xảy tình bất tiện Mỗi kiện khách hàng hay người sử dụng gây nên sa vào trạng thái kiện bất tiện Hệ thống không nắm quyền điều khiển người sử dụng người sử dụng định để làm nảy kiện thời điểm tiện lợi Ví dụ khách hàng định kết thúc trước kỳ hạn tài khoản đầu tư Một trường hợp khác cần phải xử lý kiện người sử dụng gây nên khơng thể xảy Có loạt lý (người sử dụng thiếu tập trung, buồn nản, lơ đãng ) khiến cho kiện loại không xảy Cả trường hợp phải xử lý thấu đáo Ví dụ khách hàng thất bại việc báo cho nhà băng biết mệnh lệnh kỳ 104 hạn tài khoản, séc viết lại khơng có khả giải tỏa mức tiền cần thiết Nhìn theo phương diện biểu đồ trạng thái thành phần mơ hình động, cần ý điểm sau: Biểu đồ trạng thái cần tạo dựng nên cho lớp đối tượng có ứng xử động quan trọng Hãy thẩm tra biểu đồ trạng thái theo khía cạnh tính quán kiện dùng chung tồn mơ hình động đắn Dùng trường hợp sử dụng để hỗ trợ cho trình tạo dựng biểu đồ trạng thái Khi định nghĩa trạng thái, để ý đến thuộc tính liên quan BIỂU ĐỒ HOẠT ĐỘNG (ACTIVITY DIAGRAM) Biểu đồ hoạt động nắm bắt hành động kết chúng Biểu đồ hoạt động tập trung vào công việc thực thực thi thủ tục (hàm), hoạt động lần thực thi trường hợp sử dụng đối tượng Biểu đồ hoạt động biến thể biểu đồ trạng thái có mục tiêu tương đối khác, nắm bắt hành động (công việc hoạt động phải thực hiện) kết chúng theo biến đổi trạng thái Các trạng thái biểu đồ hoạt động (được gọi trạng thái hành động) chuyển sang giai đoạn hành động trạng thái thực xong (mà không xác định kiện theo nội dung biểu đồ trạng thái) Một điểm phân biệt khác biểu đồ hoạt động biểu đồ trạng thái hành động định vị luồng (swimlane) Một luồng gom nhóm hoạt động, ý tới khái niệm người chịu trách nhiệm cho chúng chúng nằm đâu tổ chức Một biểu đồ hoạt động phương pháp bổ sung cho việc miêu tả tương tác, kèm với trách nhiệm thể rõ hành động xảy nào, chúng làm (thay đổi trạng thái đối tượng), chúng xảy (chuỗi hành động), chúng xảy đâu (luồng hành động) Biểu đồ hoạt động sử dụng cho nhiều mục đích khác nhau, ví dụ như: Để nắm bắt công việc (hành động) phải thực thi thủ tục thực Đây tác dụng thường gặp quan trọng biểu đồ hoạt động Để nắm bắt công việc nội đối tượng Để nhóm hành động liên quan thực thi sao, chúng ảnh hưởng đến đối tượng nằm xung quanh chúng Để trường hợp sử dụng thực thể hóa nào, theo khái niệm hành động biến đổi trạng thái đối tượng 105 Để doanh nghiệp hoạt động theo khái niệm công nhân (tác nhân), qui trình nghiệp vụ (workflow), tổ chức đối tượng (các khía cạnh vật lý tri thức sử dụng doanh nghiệp) Biểu đồ hoạt động coi loại Flow chart Điểm khác biệt Flow Chart bình thường áp dụng qui trình tuần tự, biểu đồ hoạt động xử lý các qui trình song song Hành động thay đổi trạng thái Một hành động thực để sản sinh kết Việc thực thi thủ tục miêu tả dạng tập hợp hành động liên quan, sau chúng chuyển thành dòng code thật Theo định nghĩa phần trước, biểu đồ hoạt động hành động mối quan hệ chúng có điểm bắt đầu điểm kết thúc Biểu đồ hoạt động sử dụng ký hiệu biểu đồ trạng thái bình thường Hình 6.12- Khi người gọi tác vụ PrintAllCustomer (trong lớp CustomerWindow), hành động khởi động hành động hộp thơng báo lên hình; hành động thứ hai tạo tập tin postscript; hành động thứ ba gởi file postscript đến máy in; hành động thứ tư xóa hộp thơng báo hình Các hành động chuyển tiếp tự động; chúng xảy hành động giai đoạn nguồn thực Các thay đổi bảo vệ điều kiện canh giữ (Guard-condition), điều kiện phải thỏa mãn thay đổi nổ Một ký hiệu hình thoi sử dụng để thể định Ký hiệu định có nhiều thay đổi vào nhiều thay đổi dán nhãn kèm điều kiện bảo vệ Bình thường ra, số thay đổi thỏa mãn (là đúng) Một thay đổi chia thành hai hay nhiều thay đổi khác dẫn đến hành động xảy song song Các hành động thực đồng thời, chúng thực Yếu tố quan trọng tất thay đổi đồng thời phải thực trước chúng thống lại với (nếu có) Một đường thẳng nằm ngang kẻ đậm (cịn gọi đồng hộ hóa – Synchronisation Bar) thay đổi chia thành nhiều nhánh khác chia sẻ thành hành động song song Cũng đường thẳng sử dụng để thống nhánh 106 Kí hiệu UML cho thành phần biểu đồ hoạt động: Hoạt động (Activity): qui trình định nghĩa rõ ràng, thực thi qua hàm nhóm đối tượng Hoạt động thể hình chữ nhật bo trịn cạnh Thanh đồng hóa (Synchronisation bar): chúng cho phép ta mở đóng lại nhánh chạy song song nội tiến trình Hình 6.13- Thanh đồng hóa Điều kiện canh giữ (Guard Condition): biểu thức logic có giá trị hoặc sai Điều kiện canh giữ thể ngoặc vng, ví dụ: [Customer existing] Điểm định (Decision Point): sử dụng để thay đổi khả thi Kí hiệu hình thoi Hình sau miêu tả đoạn biểu đồ hoạt động máy ATM Sau thẻ đưa vào máy, ta thấy có ba hoạt động song song: Xác nhận thẻ Xác nhận mã số PIN Xác nhận số tiền yêu cầu rút Chỉ sử dụng biểu đồ hoạt động, hoạt động song song miêu tả Mỗi hoạt động xác nhận thân trình riêng biệt 107 Hình 6.14- Biểu đồ hoạt động máy ATM VÒNG ĐỜI ĐỐI TƯỢNG (OBJECT LIFECYCLE) Vòng đời mà đối tượng qua phụ thuộc vào loại đối tượng Có hai loại vòng đời khác đối tượng: vòng đời sinh chết đi; vòng đời vòng lặp 9.1 Vòng đời sinh chết Trong vịng đời sinh chết đi: Sẽ có hay nhiều trạng thái nơi đối tượng bắt đầu tồn Những trạng thái gọi trạng thái tạo đối tượng Sẽ có hay nhiều trạng thái đóng tư cách điểm kết thúc cho vòng đời đối tượng Những trạng thái gọi trạng thái kết thúc Có hai loại trạng thái kết thúc Một dạng trạng thái kết thúc loại nơi đối tượng bị hủy không tiếp tục tồn Loại thứ hai dạng trạng thái kết thúc mà sau đối tượng lưu trữ lại chuyển sang trạng thái im lặng Đối tượng tiếp tục tồn không tiếp tục thể ứng xử động 108 Sau trạng thái khởi tạo trước trạng thái kết thúc, đối tượng qua nhiều trạng thái trung gian Tại thời điểm, đối tượng phải trạng thái thời Khơng có điểm sau trạng thái khởi tạo trước trạng thái kết thúc mà đối tượng lại khơng có trạng thái Ví dụ cho đối tượng có vịng đời sinh chết đi: khách hàng, tài khoản 9.2 Vòng đời lặp Khác với trường hợp sinh chết đi, vòng đời vòng lặp: Đối tượng coi ln ln tồn cịn mãi tiếp tục tồn Khơng có trạng thái khởi tạo khơng có trạng thái kết thúc Mặc dù thật đối tượng tạo thời điểm thật bị hủy diệt thời điểm đó, coi ln ln tồn có mặt Thường đối tượng tỏ có vòng đời vòng lặp tạo thời điểm cài đặt hệ thống chết hệ thống kết thúc Một đối tượng với vòng đời vịng lặp có nhiều trạng thái "ngủ yên" Đó trạng thái nơi đối tượng nằm chờ kiện xảy Bên cạnh đó, đối tượng luôn trạng thái thời Ví dụ cho đối tượng có vịng đời lặp lại: máy rút tiền tự động (ATM), nhân viên thu ngân 10 XEM XÉT LẠI MƠ HÌNH ĐỘNG 10.1 Thẩm vấn biểu đồ trạng thái Sau hoàn tất thành phần mơ hình động biểu đồ tuần tự, biểu đồ cộng tác, biểu đồ trạng thái biểu đồ hoạt động, nhóm phát triển phác thảo biểu đồ thành phần biểu đồ triển khai Biểu đồ triển khai coi biểu đồ cuối mơ hình động Tới thời điểm này, coi ta hồn tất phiên mơ hình động Phần quan trọng mơ hình biểu đồ trạng thái Hãy tìm câu trả lời cho loạt câu hỏi để xác định xem biểu đồ trạng thái đắn có mức độ chi tiết thích hợp hay chưa Cơng việc cần nhắm tới hai mục đích: Kiểm tra tính trọn vẹn mơ hình Đảm bảo điều kiện gây lỗi xử lý Trong giai đoạn này, có cảnh kịch (scenario) xuất gia nhập phạm vi quan sát chúng ta, trước có số trạng thái chưa xử lý Những tình 109 loại loại vấn đề giải quyết, song né tránh qua việc xác định thật đầy đủ kiện trạng thái 10.2 Phối hợp kiện Bước cuối vòng kiểm tra bổ sung nhằm đảm bảo tính đắn mơ hình động: Kiểm tra để đảm bảo thơng điệp có đối tượng gửi đối tượng nhận Trong số trường hợp, số liệu xác đối tượng nhận kiện khơng biết tới, phải đảm bảo biết lớp xử lý kiện Hãy nghiên cứu mơ hình theo khía cạnh trạng thái, tìm trạng thái khơng có trạng thái dẫn trước khơng có trạng thái Những trạng thái thái trạng thái khởi đầu trạng thái kết thúc Mặc dù vậy, trạng thái không thuộc hai loại trạng thái kia, triệu chứng cho thấy mơ hình cịn thiếu điều Nhìn chung, tất trạng thái thường có trạng thái dẫn trước trạng thái tiếp sau Hãy lần theo hịêu ứng kiện vào (entry) để đảm bảo chúng tương thích với trường hợp sử dụng nơi chúng xuất phát Để làm điều này, lần theo kiện từ đối tượng đến đối tượng khác, kiểm tra xem kiện có phù hợp với trường hợp sử dụng hay khơng Trong trường hợp có mâu thuẫn, sửa lại biểu đồ trạng thái trường hợp sử dụng để đảm bảo quán Kiểm tra lại lỗi đồng bộ, chúng kết kiện khơng chờ đợi 10.3 Bao sử dụng biểu đồ Không cần phải vẽ tất loại biểu đồ động cho tất loại hệ thống Mặc dù vậy, số trường hợp khác thiết phải cần đến số loại biểu đồ động định Sau vài lời mách bảo giúp giải thích vài điều cịn chưa thơng tỏ việc sử dụng loại biểu đồ động Biểu đồ biểu đồ cộng tác vẽ muốn xem xét ứng xử động nhiều đối tượng/lớp nội cảnh kịch trường hợp sử dụng Biểu đồ biểu đồ cộng tác hữu dụng việc cộng tác đối tượng, chúng lại không hữu dụng muốn miêu tả ứng xử xác đối tượng Biểu đồ trạng thái sử dụng để thể ứng xử xác đối tượng Biểu đồ hoạt động sử dụng để thể lối ứng xử xuyên suốt nhiều trường hợp sử dụng tiểu trình xảy song song lần thực thi 110 Biểu đồ thành phần biểu đồ triển khai sử dụng để mối quan hệ vật lý phần mềm thành phần phần cứng hệ thống 10.4 Lớp biểu đồ trạng thái Tất lớp thừa kế thuộc tính thủ tục lớp cha Vì vậy, lớp thừa kế mơ hình động lớp cha Ngồi biểu đồ trạng thái thừa kế, lớp có biểu đồ trạng thái riêng Biểu đồ trạng thái lớp cha mở rộng để bao chứa lối ứng xử chuyên biệt lớp Biểu đồ trạng thái lớp biểu đồ trạng thái lớp cha phải bảo trì riêng biệt độc lập Biểu đồ trạng thái lớp cần phải định nghĩa sử dụng thuộc tính lớp khơng phải thuộc tính lớp cha Mặt khác, có móc nối ngồi ý muốn lớp cha đến với lớp thơng qua thuộc tính mà chúng sử dụng chung, ví dụ nên xem xét biểu đồ trạng thái cho tài khoản có kỳ hạn theo phương diện thay đổi thuộc tính chúng, khơng phải thuộc tính lớp cha Ta phải để né tránh trường hợp trộn lẫn thuộc tính lớp lớp cha Việc tuân thủ quy tắc kể trình vẽ biểu đồ trạng thái cho lớp đảm bảo tính mơđun cho động tác mở rộng bạn 11 PHỐI HỢP MƠ HÌNH ĐỐI TƯỢNG VÀ MƠ HÌNH ĐỘNG Khi kết hợp mơ hình đối tượng mơ hình động, kiện mơ hình động cần phải tương thích với thủ tục mơ hình đối tượng Từ suy ra, thay đổi mặt trạng thái mơ hình động cần phải phù hợp với thủ tục đối tượng Hành động phụ thuộc vào trạng thái đối tượng vào kiện Mối quan hệ mơ hình đối tượng mơ hình động miêu tả sau: Mơ hình đối tượng cấu (framework) cho mơ hình động Mơ hình động xác định chuỗi thay đổi phép xảy đối tượng mơ hình đối tượng Mơ hình động bị hạn chế đối tượng có mặt mơ hình đối tượng cấu trúc chúng Không thể có mơ hình động cho đối tượng khơng tồn mơ hình đối tượng Có mối quan hệ 1-1 mơ hình đối tượng mơ hình động Mơ hình động mơ hình đối tượng cộng thêm với phần ứng xử "sống" 111 Mô hình đối tượng miêu tả khác biệt đối tượng khác biệt lớp Khi đối tượng ứng xử khác đối tượng khác đối tượng số có lớp riêng Mặc dù vậy, mơ hình động, khác biệt ứng xử động mô hình hóa thành trạng thái khác lớp 12 TĨM TẮT VỀ MƠ HÌNH ĐỘNG Tất hệ thống có cấu trúc tĩnh có ứng xử động Cấu trúc miêu tả qua phần tử mơ hình tĩnh, ví dụ lớp, quan hệ lớp, nút mạng thành phần Khái niệm ứng xử miêu tả phần tử mơ hình nội cấu trúc tương tác với dọc theo tiến trình thời gian Đó thường tương tác xác định trước mơ hình hóa Mơ hình hóa ứng xử động hệ thống gọi mơ hình động, UML hỗ trợ Có tất bốn loại biểu đồ khác nhau, loại với mục đích khác nhau: biểu đồ trạng thái , biểu đồ tuần tự, biểu đồ cộng tác biểu đồ hoạt động Biểu đồ trạng thái sử dụng để miêu tả lối ứng xử trạng thái nội lớp (nó sử dụng cho hệ thống cho toàn hệ thống) Nó tập trung vào khía cạnh đối tượng theo tiến trình thời gian thay đổi trạng thái chúng tùy theo kiện xảy ra, lối ứng xử hành động thực trạng thái, thay đổi trạng thái xảy Một kiện nổ điều kiện trở thành thỏa mãn, nhận tín hiệu lệnh gọi thủ tục, khoảng thời gian định trước qua Biểu đồ sử dụng để miêu tả nhóm đối tượng tương tác với cảnh kịch riêng biệt Nó tập trung vào chuỗi thông điệp, tức câu hỏi thông điệp gửi nhận nhóm đối tượng Biểu đồ có hai trục; trục dọc thời gian trục nằm ngang đối tượng tham gia cảnh kịch Khía cạnh quan trọng biểu đồ thời gian Biểu đồ cộng tác sử dụng để miêu tả đối tượng tương tác với khơng gian nhớ (space), có nghĩa bên cạnh tương tác động, cịn miêu tả rõ ràng đối tượng nối kết với Trong biểu đồ cộng tác khơng có trục cho thời gian; thay vào đó, thơng điệp đánh số để tạo chuỗi Biểu đồ hoạt động sử dụng để miêu tả việc xảy ra sao, công việc thực Biểu đồ hoạt động sử dụng cho thủ tục, lớp, trường hợp sử dụng, sử dụng để quy trình nghiệp vụ (workflow) 112