Chúng ta có thể thấy rằng: Một số tập hợp dữ liệu phức tạp nhất định khi được trình bày bằng đồ thị sẽ truyền tải đến người đọc nhiều thông tin hơn so với các dữ liệu thô. Với phần mềm cũng vậy, khi ngành Công nghiệp của chúng ta ngày càng phát triển, các hệ thống sẽ trở nên phức tạp hơn. Khả năng nắm bắt và kiểm soát sự phức tạp đó của chúng ta đi kèm với khả năng trình bày hệ thống một cách toàn diện một sự trình bày vượt ra ngoài giới hạn của những dòng lệnh thô. Sự thành công trên thị trường của những ngôn ngữ như Visual Basic và phần giao diện trực quan của C++, Java đã cho thấy sự trình bày trực quan mang tính cốt yếu đối với quá trình phát triển các hệ thống phức tạp.
DẪn nhẬp: 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 ngày phát triển, hệ thống trở nên phức tạp Khả nắm bắt kiểm soát phức tạp kèm với khả trình bày hệ thống cách toàn diện - trình bày vượt 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 trình phát triển hệ thống phức tạp Mô hình trừu tượng: Trước đây, có thời gian dài, ngành công nghiệp phải nói tới "Cuộc 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 hóa trực quan: Mô hình hoá trực quan phương thức tư vấn đề sử dụng mô hình tổ chức xoay quanh khái niệm đời thực Mô hình giúp hiểu vấn đề, giao tiếp với người có liên quan đến dự án (khách hàng, chuyên gia lĩnh vực thuộc đề án, nhà phân tích, nhà thiết kế, …) Mô hình hữu dụng việc mô hình hoá doanh nghiệp, soạn thảo tài liệu, thiết kế chương trình ngân hàng liệu Mô hình giúp 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ì 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 1/163 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 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 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 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 chẳng cung cấp nhìn toà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 lớn 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 Một môi trường kinh doanh mang tính cạnh tranh gay gắt luôn thay đổi dẫn đến tính phức tạp ngày tăng cao, tính phức tạp đặt thách thức đặc trưng cho nhà phát triển hệ thống Mô hình giúp tổ chức, trình bày trực quan, thấu hiểu tạo nên hệ thống phức tạp Chúng giúp đáp ứng thách thức việc phát triển phần mềm, hôm ngày mai Mô tả chu trình phát triển phần mềm Mô tả chu trình phát triển phần mềm: Software Development – toán phức tạp: Kinh nghiệm nhiều nhà thiết kế phát triển cho thấy phát triển phần mềm 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 chí mâu thuẫn 2/163 - Đội quân phát triển phần mềm, vốn người "ngoài cuộc", khó nhận thức thấu đáo mối quan hệ tiềm ẩn phức tạp 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 Designer Phần mềm 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 nhà băng cần có khả tái sử dụng cho nhà băng khác với sửa đổi hoàn toà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 Chính vậy, số khiếm khuyết thường gặp phát triển phần mềm là: - Hiểu 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 thay đổi gì, nào, đâu, phải thay đổi Chu Trình Phát Triển Phần Mềm (Software Development Life Cycle): 3/163 Vì phát triển phần mềm toá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ững hoạt động thực nhiều giai đọan khác 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 Nhà thiết kế (Designer): thiết kế hệ thống theo hướng cấu trúc 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 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 hoá 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 sau: Vấn đề Nhìn vấn đề ô tô người bình thường 4/163 Chuyên gia lĩnh vực giúp nhà phân tích "trình bày lại" vấn đề sau: Nhìn vấn đề ô tô chuyên gia phân tích Chính trợ giúp chuyên 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 Các giai đoạn Chu Trình Phát Triển Phần Mềm: Chu trình phần mềm chia thành giai đoạn sau: - Nghiên cứu sơ (Preliminary Investigation hay gọi Feasibility Study) - Phân tích yêu cầu (Analysis) - Thiết kế hệ thống (Design of the System) - 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 hoàn toàn 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 chẳng đặt lại không trả lời Mặc dù việc lầm lẫn phương 5/163 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 hoà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ó hoà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 doanh nghiệp (cần dùng hệ thố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 Có thể thực thảo luận, nghiên cứu, xem xét khía cạnh thương mại, phân tích khả lời-lỗ, phân tích trường hợp sử dụng tạo nguyên mẫu để xây dựng nên khái niệm cho hệ thống đích với mục đích, quyền ưu tiên phạm vi Thường giai đoạn người ta tiến hành tạo phiên thô lịch trình kế hoạch sử dụng tài nguyên 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 6/163 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 Quá 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ì?" Quá 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 nguyên 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 hệ thống Trong toà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ế) 7/163 - 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 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ế Chi Tiết 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ế Chi Tiết, 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 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 8/163 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 Sơ đồ tổng quát giai đoạn Chu Trình Phát Triển Phần Mềm: Sơ đồ tổng quát giai đoạn Chu Trình Phát Triển Phần Mềm Phương pháp hướng chức phương pháp hướng đối tượng Phương pháp hướng chức phương pháp hướng đối tượng: Phương pháp hướng chức năng: 9/163 Đây lối tiếp cận truyền thống ngành Công nghệ phần mềm Theo lối tiếp cận này, quan tâm chủ yếu tới thông tin mà hệ thống giữ gìn Chúng ta hỏi người dùng xem họ cần thông tin nào, thiết kế ngân hàng liệu để chứa thông tin đó, cung cấp Forms để nhập thông tin in báo cáo để trình bày thông tin Nói cách khác, tập trung vào thông tin không để ý đến xảy với hệ thống cách hoạt động (ứng xử) hệ thống Đây lối tiệm cận xoay quanh liệu áp dụng để tạo nên hàng ngàn hệ thống suốt nhiều năm trời Lối tiếp cận xoay quanh liệu phương pháp tốt cho việc thiết kế ngân hàng liệu nắm bắt thông tin, áp dụng cho việc thiết kế ứng dụng lại khiến phát sinh nhiều khó khăn Một thách thức lớn yêu cầu hệ thống thường xuyên thay đổi Một hệ thống xoay quanh liệu dể dàng xử lý việc thay đổi ngân hàng liệu, lại khó thực thi thay đổi nguyên tắc nghiệp vụ hay cách hoạt động hệ thống Phương pháp hướng đối tượng phát triển để trả lời cho vấn đề Với lối tiếp cận hướng đối tượng, tập trung vào haimặt vấn đề : thông tin vàcách hoạt động Phương pháp hướng đối tượng: Hướng đối tượng thuật ngữ thông dụng thời ngành công nghiệp phần mềm Các công ty nhanh chóng tìm cách áp dụng tích hợp công nghệ vào ứng dụng họ Thật đa phần ứng dụng thời mang tính hướng đối tượng Nhưng hướng đối tượng có nghĩa gì? Lối tiếp cận hướng đối tượng lối tư vấn đề theo lối ánh xạ thành phần toán vào đối tượng đời thực Với lối tiếp cận này, chia ứng dụng thành thành phần nhỏ, gọi đối tượng, chúng tương đối độc lập với Sau ta xây dựng ứng dụng cách chắp đối tượng lại với Hãy nghĩ đến trò chơi xây lâu đài mẫu gỗ Bước tạo hay mua vài loại mẫu gỗ bản, từ tạo nên khối xây dựng Một có khối xây dựng đó, bạn chắp ráp chúng lại với để tạo lâu đài Tương tự xây dựng số đối tượng giới máy tính, bạn chắp chúng lại với để tạo ứng dụng Xin lấy ví dụ đơn giản: vấn đề rút tiền mặt nhà băng Các “mẫu gỗ“ thành phần ánh xạ đối tượng đời thực tài khoản, nhân viên, khách hàng, …Và ứng dụng sẽ nhận diện giải đáp xoay quanh đối tượng 10/163 - Độ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 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 138/163 Các ký hiệu UML thể bắt đầu, kết thúc, kiện trạng thái đối tượng Biểu đồ trạng thái thực hoá đơn Một trạng thái có ba thành phần, hình sau : 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đi 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 toán Ba loại kiện chuẩn 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 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ừ ngoà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ừ 139/163 Biến đổi trạng thái kiện từ Sự thay đổi trạng thái xảy hoạt động trạng thái thực xong 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 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 140/163 - 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 Một số lời mách bảo cho việc tạo dựng biểu đồ trạng thái - Chuyển biểu đồ thành biểu đồ trạng thái - Xác định vòng lặp (loop) - Bổ sung thêm điều kiện biên điều kiện đặc biệt - Trộn lẫn cảnh kịch khác vào 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 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 Chuyển biểu đồ sang biểu đồ trạng thái 141/163 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) Biểu đồ lặp Chú ý: 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 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, 142/163 đố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 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 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ỳ hạn tài khoản, séc viết lại 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 toà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 143/163 Biểu đồ hoạt động (Activity Diagram) 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 - Để 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 144/163 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 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 Kí hiệu UML cho thành phần biểu đồ hoạt động: 145/163 - 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 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 vuông, 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 146/163 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 Vòng đời sinh chết đi: 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 147/163 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 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 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 luôn tồn mãi tiếp tục tồn - Không có trạng thái khởi tạo 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 luôn 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 Xem xét lại mô hình động 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 hoà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: 148/163 - 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 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 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 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 trạng thái dẫn trướ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 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 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 chưa thông tỏ việc sử dụng loại biểu đồ động 149/163 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 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 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 Ngoà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 thuộc tính lớp cha Mặt khác, có móc nố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, 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 Phối hợp mô hình đối tượng mô hình động Phối hợp mô hình đối tượng 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 150/163 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" - 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 Tóm tắt 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, 151/163 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, miêu tả rõ ràng đối tượng nối kết với Trong biểu đồ cộng tá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) 152/163 ... UML phân tích thiết kế hệ thống UML phân tích thiết kế hệ thống: UML sử dụng nhiều giai đoạn, từ phát triển, thiết kế thực bảo trì Vì mục đích ngôn ngữ dùng biểu đồ hướng đối tượng để mô tả hệ. .. - 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. .. chứa thông tin đó, cung cấp Forms để nhập thông tin in báo cáo để trình bày thông tin Nói cách khác, tập trung vào thông tin không để ý đến xảy với hệ thống cách hoạt động (ứng xử) hệ thống Đây