›
›

Giáo trình Phân tích thiết kế hệ thống hướng đối tượng bằng UML (Phần 1)

pdf 87 trang phuongnguyen 11012
Download
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Phân tích thiết kế hệ thống hướng đối tượng bằng UML (Phần 1)", để 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_thiet_ke_he_thong_huong_doi_tuong_bang.pdf

Nội dung text: Giáo trình Phân tích thiết kế hệ thống hướng đối tượng bằng UML (Phần 1)

  1. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Giáo trình PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG HƯỚNG ĐỐI TƯỢNG SỬ DỤNG UML Biên soạn ThS. Phạm Nguyễn Cương TS. Hồ Tường Vinh @ Đại Học KHTN-TP HCM ; ASIA-ITC 1
  2. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Giới thiệu Hệ thống phần mềm càng ngày càng trở nên phức tạp. Các ứng dụng hôm nay có những yêu cầu và kiến trúc đòi hỏi phức tạp hơn rất nhiều so với quá khứ. Các kỹ thuật, công cụ, và phương pháp luận phát triển hệ thống phần mềm đang thay đổi một cách nhanh chóng. Các phương pháp phát triển phần mềm chúng ta sẽ sử dụng trong tương lai có lẽ sẽ khác so với các phương pháp hiện hành đang sử dụng. Tuy nhiên, một điều hiển nhiên là phát triển hướng đối tượng và các khái niệm cơ bản của nó đang được sử dụng rộng rãi. Nhiều trường học đã nhận ra được điều này và đã tạo ra những khoá học phát triển hệ thống hướng đối tượng như một phần chính yếu của hệ thống thông tin tin học hoá và các chương trình khoa học máy tính. Giáo trình này dự kiến sẽ cung cấp một kiến thức nền tảng về phát triển các hệ thống hướng đối tượng cho các đối tượng sinh viên những năm cuối. Mục tiêu của giáo trình là cung cấp một mô tả rõ ràng về các khái niệm nền tảng phát triển hệ thống hướng đối tượng. Trong đó, nhấn mạnh đến tính đơn giản của tiếp cận giúp sinh viên có kiến thức về UML có thể dể dàng nắm bắt để phát triển một hệ thống hướng đối tượng. Mục tiêu Sau khi học xong môn học này sinh viên có thể: - Hiểu các nguyên lý nền tảng của kỹ thuật hướng đối tượng và các khái niệm về sự trừu tượng, tính bao bọc, tính thừa kế, và tính đa hình. - Hiểu về một số quy trình phát triển hệ thống, nội dung các giai đoạn cơ bản của một qui trình phát triển, và một số phương pháp phân tích thiết kế hướng đối tượng. - Tiếp cận toàn bộ qui trình phát triển hệ thống sử dụng các kỹ thuật hướng đối tượng - Sử dụng UML như là một công cụ mô hình hoá trong quá trình phát triển hệ thống - Phát triển hệ thống từ các mô hình use case được xem như là một mô hình phân tích nhằm biểu diễn đầy đủ yêu cầu hệ thống. - Áp dụng một qui trình lặp, tập trung vào kiến trúc để phát triển một mô hình thiết kế đủ chi tiết, đủ mạnh đáp ứng với các nhu cầu: o Phù hợp với các yêu cầu hệ thống đã được thống nhất qua mô hình use case trong giai đoạn phân tích. o Tái sử dụng. o Dễ dàng để cài đặt hệ thống trong một ngôn ngữ và môi trường cụ thể. @ Đại Học KHTN-TP HCM ; ASIA-ITC 2
  3. Phân tích thiết kế hệ thống hướng đối tượng bằng UML PHẦN 1: TỔNG QUAN Chương 1 GIỚI THIÊU VỀ PHƯƠNG PHÁP VÀ PHƯƠNG PHÁP LUẬN PHÁT TRIỂN HỆ THỐNG HƯỚNG ĐỐI TƯỢNG Giới thiệu về phương pháp phát triển hướng chức năng Đây là phương pháp cận truyền thống của ngành công nghiệp phần mềm trong đó quan điểm về phần mềm như là một tập hợp các chương trình (hoặc chức năng) và dữ liệu giả lập. Vậy chương trình là gì? Theo Niklaus Wirth, người tạo ra ngôn ngữ lập trình Pascal thì: “Chương trình = thuật giải + cấu trúc dữ liệu”. Điều này có nghĩa rằng có hai khía cạnh khác nhau của hệ thống được tiếp cận, hoặc tập trung vào các chức năng của hệ thống hoặc tập trung vào dữ liệu. Chúng ta chia hướng tiếp cận này thành hai thời kỳ: thời kỳ vào những năm thập niên 70, tiếp cận phân tích và thiết kế hệ thống theo phương pháp gọi là Descartes. Ý tưởng chính trong cách tiếp cận này là một quá trình lặp phân rã hệ thống thành các chức năng và ứng dụng phương pháp lập trình cấu trúc đơn thể chương trình, việc phân rã kết thúc khi một chức năng được phân rã có thể lập trình được. Trong thời kỳ này, người ta chưa quan tâm đến các thành phần không được tin học hoá mà chỉ xoay quanh đến các vấn đề trong hệ thống để lập trình, tập trung vào chức năng và ít tập trung vào dữ liệu (vì thời kỳ nay đang chuẩn hoá và phát triển về cơ sở dữ liệu, hệ quản trị cơ sở dữ liệu) Thời kỳ vào những thập niên 80, tiếp cận phân tích thiết kế theo phương pháp gọi là hệ thống. Quan điểm chính của phương pháp này là tiếp cận hệ thống theo 2 thành phần, thành phần xử lý (thành phần động) và thành phần dữ liệu (thành phần tĩnh) của hệ thống. Cách tiếp cận của các phương pháp trong giai đoạn này tuân theo hai tính chất : tính toàn thể : tiếp cận hệ thống qua việc mô tả các hệ thống con và sự tương tác giữa chúng ; tính đúng đắn : tìm kiếm sự phân rã, kết hợp các hệ thống con sao cho hành vi của nó tiêu biểu nhất của hệ thống trong môi trường tác động lên hệ thống con đó. Cách tiếp cận hệ thống theo hai thành phần chính là tiền đề cho cách tiếp cận hướng đối tượng trong các giai đoạn sau. Tuy nhiên, việc tiếp cận chủ yếu là hướng xoay quanh dữ liệu để thu thập và tổ chức dữ liệu nhằm khai thác mặt đáp ứng nhu cầu thông tin. Hướng tiếp cận gây khó khăn trong những hệ thống lớn và thường xuyên thay đổi cũng như là trong việc thiết kế nhằm tái sử dụng một thành phần đã có. Giới thiệu về phương pháp phát triển hướng đối tượng Vào thập niên 90, phương pháp tiếp cận phân tích thiết kế đối tượng là sự tổng hợp của phương pháp Descartes và phương pháp hệ thống. Trong khi các mô hình được đưa ra trong những thập niên trước thường đưa ra dữ liệu và xứ lý theo hai hướng độc lập nhau. Khái niệm đối tượng là sự tổng hợp giữa khái niệm xử lý và khái niệm dữ liệu chung trong một cách tiếp cận, và một hệ thống là một tập hợp các đối tượng liên kết nội. Có nghĩa rằng việc xây dựng hệ thống chính là việc xác định các đối tượng đó bằng cách cố gắng ánh xạ các đối tượng của thế giới thực thành đối tượng hệ thống, thiết kế và xây dựng nó, và hệ thống hình thành chính là qua sự kết hợp của các đối tượng này. Phương pháp hướng đối tượng được xem là phương pháp phân tích thiết kế thế hệ thứ ba, các phương pháp tiêu biểu là OOD, HOOD, BON, OSA, và sau này là OOSA, OOA, OMT, CRC, OOM, OOAD, OOSE, RUP/UML Đặc trưng cơ bản - Tính bao bọc (encapsulation): quan niệm mối quan hệ giữa đối tượng nhận và đối tượng cung cấp thông qua khái niệm hộp đen. Nghĩa là đối tượng nhận chỉ truy xuất đối tượng cung cấp qua giao diện được định nghĩa bởi đối tượng cung cấp, đối tượng nhận không được truy cập đến các đặc trưng được xem là “nội bộ” của đối tượng cung cấp. @ Đại Học KHTN-TP HCM ; ASIA-ITC 3
  4. Phân tích thiết kế hệ thống hướng đối tượng bằng UML - Tính phân loại (classification): gom nhóm các đối tượng có cùng cấu trúc và hành vi vào một lớp (class). - Tính kết hợp (aggregation): kết hợp các đối tượng và các đối tượng cấu thành nó để mô tả cấu trúc cục bộ của đối tượng (ví dụ: toà nhà phòng, xe sườn xe, bánh xe, ) , hoặc sự liên kết phụ thuộc lẫn nhau giữa các đối tượng. - Tính thừa kế (heritage): phân loại tổng quát hoá và chuyên biệt hoá các đối tượng, và cho phép chia sẽ các đặc trưng của một đối tượng. Phân loại Phương pháp lập trình hướng đối tượng được chia thành 2 hướng như sau: - Hướng lập trình: từ lập trình đơn thể chuyển sang lập trình hướng đối tượng với lý thuyết cơ bản dựa trên việc trừu tượng hóa kiểu dữ liệu. - Hướng hệ quản trị CSDL: phát triển thành CSDL hướng đối tượng Có 2 cách tiếp cận riêng biệt: - Phương pháp kỹ thuật: hướng công nghệ phần mềm như OOD, HOOD, BON, BOOCH, MECANO, OODA, - Phương pháp toàn cục: hướng về HTTT như OOA, OOSA, OOAD, OMT, OOM, Ưu điểm - Cấu trúc hoá được các cấu trúc phức tạp và sử dụng được cấu trúc đệ qui: các phương pháp đối tượng đều sử dụng các mô hình bao gồm nhiều khái niệm để biểu diễn nhiều ngữ nghĩa khác nhau của hệ thống. Ví dụ: trong mô hình lớp của OMT có khái niệm mối kết hợp thành phần cho phép mô tả một đối tượng là một thành phần của đối tượng khác, trong khi nếu dùng mô hình ER truyền thống không có khái niệm này do đó không thể biểu diễn được quan hệ thành phần. - Xác định được đối tượng của hệ thống qua định danh đối tượng1 - Tính thừa kế được đưa ra tạo tiền đề cho việc tái sử dụng Mô hình Mô hình (model) là một dạng thức trừu tượng về một hệ thống, được hình thành để hiểu hệ thống trước khi xây dựng hoặc thay đổi hệ thống đó. Theo Efraim Turban, mô hình là một dạng trình bày đơn giản hoá của thế giới thực. Bởi vì, hệ thống thực tế thì rất phức tạp và rộng lớn và khi tiếp cận hệ thống, có những chi tiết những mức độ phức tạp không cần thiết phải được mô tả và giải quyết. Mô hình cung cấp một phương tiện (các khái niệm) để quan niệm hoá vấn đề và giúp chúng ta có thể trao đổi các ý tưởng trong một hình thức cụ thể trực quan, không mơ hồ. Các đặc điểm của một mô hình: - Diễn đạt một mức độ trừu tượng hóa (ví dụ: mức quan niệm, mức tổ chức, mức vật lý, ) - Tuân theo một quan điểm (quan điểm của người mô hình hoá) - Có một hình thức biểu diễn (văn bản, đồ họa: sơ đồ, biểu đồ, đồ thị, ) Hầu hết các kỹ thuật mô hình hóa sử dụng trong phân tích thiết kế là các ngôn ngữ đồ họa (đa số là sơ đồ - diagram), các ngôn ngữ này bao gồm một tập hợp các ký hiệu. Các ký hiệu này 1 OID: Object Iden tifier @ Đại Học KHTN-TP HCM ; ASIA-ITC 4
  5. Phân tích thiết kế hệ thống hướng đối tượng bằng UML được dùng đi kèm theo các qui tắc của phương pháp luận giúp cho việc trao đổi các quan hệ thông tin phức tạp được rõ ràng hơn việc mô tả bằng văn bản. Ví dụ : Mô hình Cl a ss_ 3 Class_1 Class_5 Case_1 0 * Actor_1 0 1 Actor_2 Class_2 Cl a ss_4 0 1 Case_2 0 * Sơ đồ Đồ thị Văn bản Biểu đồ Mô hình tĩnh và mô hình động Mô hình tĩnh (static model): được xem như là hình ảnh về thông số hệ thống tại một thời điểm xác định. Các mô hình tĩnh được dùng để trình bày cấu trúc hoặc những khía cạnh tĩnh của hệ thống. Mô hình động (dynamic model): được xem như là một tập hợp các hành vi, thủ tục kết hợp với nhau để mô tả hành vi của hệ thống. Các mô hình động được dùng để biểu diễn sự tương tác của các đối tượng để thực hiện công việc hệ thống. Mục đích của mô hình hoá Đứng trước sự gia tăng mức độ phức tạp của một hệ thống, việc trực quan hoá và mô hình hóa ngày càng trở nên chính yếu trong cách tiếp cận về một hệ thống, đặc biệt là cách tiếp cận hướng đối tượng. Việc sử dụng các ký hiệu để trình bày hoặc mô hình hóa bài toán có các mục đích sau: - Làm sáng tỏ vấn đề: chúng ta có thể đưa ra được các lỗi hoặc các thiếu xót của hệ thống từ việc tiếp cận trực quan đồ họa hơn là các dạng trình bày khác như văn bản, đoạn mã, Hơn nữa, việc mô hình hoá giúp chúng ta dễ dàng hiểu được hệ thống. - Mô phỏng được hình ảnh tương tự của hệ thống: hình thức trình bày của mô hình có thể đưa ra được một hình ảnh giả lập như hoạt động thực sự của hệ thống thực tế, điều này giúp cho người tiếp cận cảm thấy thuận tiện khi làm việc với mô hình (là hình ảnh thu nhỏ của hệ thống thực tế) - Gia tăng khả năng duy trì hệ thống: các ký hiệu trực quan có thể cải tiến khả năng duy trì hệ thống. Thay đổi các vị trí được xác định trực quan và việc xác nhận trực quan trên mô hình các thay đổi đó sẽ giảm đi các lỗi. Do đó, chúng ta có thể tạo ra các thay đổi nhanh hơn và các lỗi được kiểm soát hoặc xảy ra ít hơn. - Làm đơn giản hóa vấn đề: mô hình hoá có thể biểu diễn hệ thống ở nhiều mức, từ mức tổng quát đến mức chi tiết, mức càng tổng quát thì ký hiệu sử dụng càng ít (do đó càng đơn giản hoá việc hiểu) và hệ thống được biểu diễn càng tổng quát. @ Đại Học KHTN-TP HCM ; ASIA-ITC 5
  6. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Phương pháp luận phát triển hệ thống Phương pháp luận phát triển hệ thống bao gồm hai thành phần : - Qui trình (process) : bao gồm các giai đoạn (phase) và tiến trình trong đó định nghĩa thứ tự các giai đoạn và các luật hình thành nên một quá trình phát triển hệ thống từ các công việc khởi tạo đến các công việc kết thúc của một dự án hệ thống. - Các khái niệm (notation), phương pháp : các mô hình (bao gồm các phương pháp mô hình hoá của mô hình) cho phép mô hình hoá các kết quả của quá trình phát triển hệ thống. Các giai đoạn cơ bản trong một qui trình : Để tự động hóa hoạt động xử lý, hệ thống phải trải qua một quá trình gồm nhiều bước được gọi là quá trình phát triển hệ thống. Cũng giống như nhiều tiến trình khác, phát triển hệ thống tự động cũng theo chu trình được gọi là vòng đời (Life cycle). Khái niệm vòng đời là một khái niệm rộng nó bắt đầu từ sự khởi đầu xây dựng cho đến kết thúc việc khai thác hệ thống. Nếu chúng ta chỉ chú trọng đến giai đoạn xây dựng và triển khai thì gọi là phát triển hệ thống. Vòng đời phát triển hệ thống - SDLC (Systems Development Life Cycle) là một phương pháp luận chung để phát triển nhiều loại hình hệ thống khác nhau. Tuy nhiên, các giai đoạn trong quá trình này cũng thay đổi khác nhau khoảng từ 3 cho đến 20 tùy theo qui mô và loại hình hệ thống chúng ta đang tiếp cận. Phần sau đây sẽ giới thiệu các giai đoạn cơ bản làm nền tảng chung cho hầu hết quá trình phát triển hệ thống: Giai đoạn khởi tạo Hoạt động chính của giai đoạn này là khảo sát tổng quan hệ thống, vạch ra các vấn đề tồn tại trong hệ thống và các cơ hội của hệ thống, cũng như trình bày lý do tại sao hệ thống nên hoặc không nên được đầu tư phát triển tự động hóa. Một công việc quan trọng tại thời điểm này là xác định phạm vi của hệ thống đề xuất, trưởng dự án và nhóm phân tích viên ban đầu cũng lập một kế hoạch các hoạt động của nhóm trong các giai đoạn tiếp theo của dự án phát triển hệ thống. Kế hoạch này xác định thời gian và nguồn lực cần thiết. Đánh giá khả thi của dự án và nhất là phải xác định được chi phí cần phải đầu tư và lợi ít mang lại từ hệ thống. Kết quả của giai đoạn này là xác định được dự án hoặc được chấp nhận để phát triển, hoặc bị từ chối, hoặc phải định hướng lại. Giai đoạn phân tích Giai đoạn phân tích bao gồm các bước sau: - Thu thập yêu cầu hệ thống: các phân tích viên làm việc với người sử dụng đề xác định tất cả những gì mà người dùng mong muốn từ hệ thống đề xuất. - Nguyên cứu các yêu cầu và cấu trúc hoá (mô hình hoá) để dễ dàng nhận biết và loại bỏ những yếu tố dư thừa. - Phát sinh các phương án thiết kế chọn lựa phù hợp với yêu cầu và so sánh các phương án này để xác định giải pháp nào là đáp ứng tốt nhất các yêu cầu trong một mức độ cho phép về chi phí, nhân lực, và kỹ thuật của tổ chức. Kết quả của giai đoạn này là bản mô tả về phương án được chọn. Trong phân tích hướng đối tượng giai đoạn này quan tâm đến mức độ trừu tượng hoá đầu tiên bằng cách xác định các lớp và các đối tượng đóng vai trò quan trọng nhằm diễn đạt các yêu cầu cũng như mục tiêu hệ thống. Để hiểu rõ các yêu cầu hệ thống chúng ta cần xác định ai là người dùng và là tác nhân hệ thống. Trong phương pháp phát triển hướng đối tượng cũng như phương pháp truyền thống, các mô tả kịch bản hoạt động được sử dụng để trợ giúp các phân tích viên hiểu được yêu cầu. Tuy nhiên, các kích bản này có thể được mô tả không đầy đủ hoặc không theo một hình thức. Do đó, khái niệm use case được dùng trong giai đoạn này @ Đại Học KHTN-TP HCM ; ASIA-ITC 6
  7. Phân tích thiết kế hệ thống hướng đối tượng bằng UML nhằm biểu diễn chức năng hệ thống và sự tương tác người dùng hệ thống. Các kích bản hoạt động lúc này sử dụng các mô hình động (dynamic diagram) nhằm mô tả nội dung của use case để làm rõ sự tương tác giữa các đối tượng, vai trò cũng như sự cộng tác của các đối tượng trong hoạt động của use case hệ thống. Trong giai đoạn phân tích, chỉ có các lớp tồn tại trong phạm vi hệ thống (ở thế giới thực) mới được mô hình hoá và như vậy thì kết quả mô hình hoá trong giai đoạn này sẽ phản ánh phạm vi của hệ thống. Các lớp về kỹ thuật, giao diện định nghĩa phần mềm cũng không quan tâm ở giai đoạn này. Giai đoạn thiết kế Trong giai đoạn này kết quả của giai đoạn phân tích sẽ được chi tiết hoá để trở thành một giải pháp kỹ thuật để thực hiện. Các đối tượng và các lớp mới được xác định để bổ sung vào việc cài đặt yêu cầu và tạo ra một hạ tầng cơ sở kỹ thuật về kiến trúc. Ví dụ: các lớp mới này có thể là lớp giao diện (màn hình nhập liệu, màn hình hỏi đáp, màn hình duyệt, ). Các lớp thuộc phạm vi vấn đề có từ giai đoạn phân tích sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra khả năng thay đổi trong cả hai phương diện: Phạm vi vấn đề và hạ tầng cơ sở. Giai đoạn thiết kế sẽ đưa ra kết quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống. Về mức độ thiết kế thì có thể chia kết quả của giai đoạn này thành hai mức: Thiết kế luận lý Đặc tả hệ thống ở mức độ trừu tượng hóa dựa trên kết quả của giải pháp được chọn lựa từ giai đoạn phân tích. Các khái niệm và mô hình được dùng trong giai đoạn này độc lập với phần cứng, phần mềm sẽ sử dụng và sự chọn lựa cài đặt. Theo quan điểm lý thuyết, ở bước này hệ thống có thể cài đặt trên bất kỳ trên nền tảng phần cứng và hệ điều hành nào, điều này cho thấy giai đoạn này chỉ tập trung để biểu diễn khía cạnh hành vi và tính năng của đối tượng hệ thống. Thiết kế vật lý Chuyển đổi kết quả thiết kế luận lý sang các đặc tả trên phần cứng, phần mềm và kỹ thuật đã chọn để cài đặt hệ thống. Cụ thể là đặc tả trên hệ máy tính , hệ quản trị cơ sở dữ liệu, ngôn ngữ lập trình đã chọn, . Kết quả của bước này là các đặc tả hệ thống vật lý sẳn sàng chuyển cho các lập trình viên hoặc những người xây dựng hệ thống khác để lập trình xây dựng hệ thống. Giai đoạn xây dựng Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của giai đoạn thiết kế sẽ được biến thành những dòng mã lệnh (code) cụ thể trong một ngôn ngữ lập trình hướng đối tượng (không nên dùng một ngôn ngữ lập trình hướng chức năng!). Phụ thuộc vào khả năng của ngôn ngữ được sử dụng, đây có thể là một công việc khó khăn hoặc dễ dàng. Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhất nên cố gắng né tránh việc ngay lập tức biến đổi các mô hình này thành các dòng mã lệnh. Trong những giai đoạn trước, mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo nên cấu trúc của hệ thống; vì vậy, vội vàng đưa ra những kết luận về việc viết mã lệnh có thể sẽ thành một trở ngại cho việc tạo ra các mô hình chính xác và đơn giản. Giai đoạn xây dựng là một giai đoạn riêng biệt, nơi các mô hình được chuyển thành các mã lệnh. Giai đoạn thử nghiệm Một hệ thống phần mềm thường được thử nghiệm qua nhiều giai đoạn và với nhiều nhóm thử nghiệm khác nhau. Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau làm nền tảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp (class diagram) và đặc tả lớp, thử nghiệm tích hợp thường sử dụng biểu đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram), và giai đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case @ Đại Học KHTN-TP HCM ; ASIA-ITC 7
  8. Phân tích thiết kế hệ thống hướng đối tượng bằng UML (use case diagram) để đảm bảo hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong các biểu đồ này. Giai đoạn cài đặt và bảo trì Điều chỉnh hệ thống phù hợp với nhu cầu sử dụng, các thay đổi phát sinh bao gồm: - Chức năng sử dụng chưa phù hợp tốt nhất với người sử dụng hoặc khó sử dụng - Các điều kiện và yêu cầu của người dùng hệ thống thay đổi, đòi hỏi phải chỉnh sửa sao cho hệ thống vẫn hữu dụng - Các lỗi hệ thống phát sinh do quá trình kiểm tra còn xót lại - Nâng cấp phiên bản mới của hệ thống Bảo trì hệ thống không nên xem như là một giai đoạn tách rời mà nên xem như là một sự lặp lại chu trình của những giai đoạn trước đòi hỏi phải được nghiên cứu đánh giá và cài đặt. Tuy nhiên, nếu một hệ thống không còn hoạt động như mong muốn do có sự thay đổi quá lớn về hoạt động, hoặc nhu cầu mới đặt ra vượt quá sự giải quyết của hệ thống hiện tại, hoặc chi phí để bảo trì là quá lớn. Lúc này yêu cầu về hệ thống mới được xác lập để thay thế hệ thống hiện tại và một qui trình lại bắt đầu. Ví dụ về qui trình phát triển Chúng ta có thể hình dung rằng chúng ta muốn xây dựng một căn nhà. Công việc đầu tiên là chúng ta chắc chắn là chúng ta dự tính xem chúng ta sẽ bỏ số tiền bao nhiêu để xây dựng căn nhà này, dựa trên số tiến này chúng ta tìm kiếm và phác hoạ (có thể chỉ trong ý tưởng) căn nhà này phải như thế nào? Loại căn nhà theo kiểu gì, có mấy phòng, chiều rộng và chiều dài bao nhiêu, rồi nào đến nền nhà, màu sắc, tiện nghi ?, Rồi sau đó, chúng ta sẽ chọn một đơn vị xây dựng (trong số nhiều đơn vị mà thoả yêu cầu nhất). Tất cả các yêu trên sẽ phải trao đổi với đơn vị xây dựng này nhằm thống nhất về giá cả cũng như các điều khoản về yêu cầu xây dựng. Giai đoạn này được xem như là giai đoạn phân tích. Tiếp đó, đơn vị xây dựng sẽ thực hiện công việc thiết kế chi tiết của căn nhà, và từng đơn vị trong căn nhà (phòng, tường, trần, mái, phòng khách, phòng ăn, phòng ngủ, ). Giai đoạn này được xem là giai đoạn thiết kế. Sau đó các bản thiết kế chi tiết của căn nhà sẽ được bộ phận thi công dựa vào đó để tiến hành việc xây dựng. Giai đoạn này được xem là giai đoạn xây dựng. Căn nhà sau khi hoàn tất sẽ được chuyển giao để sử dụng, tất nhiên trong quá trình sử dụng nếu có các hư hỏng thì đơn vị xây dựng sẽ phải tiến hành bảo trì và sửa chữa. Yêu cầu về căn nhà Ý tưởng về căn nhà Căn nhà xây xong Chuyển giao sử Phân tích & thiết kế Xây dựng dụng và bảo trì @ Đại Học KHTN-TP HCM ; ASIA-ITC 8
  9. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Mộ số qui trình phát triển Qui trình thác nước (waterfall – Boehm 1970) Phân tích yêu cầu Thiết kế quan niệm Thiết kế chi tiết Lập trình Thử nghiệm đơn vị Thử nghiệm tích hợp Thử nghiệm hệ thống Phân tích Thiết kế Cài đặt Thử nghiệm Đây là một qui trình đầu tiên được đế xuất và đã đưa ra được các giai đoạn căn bản nhất và đây đủ cho một quá trình phát triển hệ thống, các giai đoạn bao gồm : phân tích, thiết kế, cài đặt và thử nghiệm hệ thống. Từ khi được đề xuất qui trình này nhanh chóng được phổ cập sử dụng rộng rãi trong giới công nghiệp và cho đến bây giờ đã có nhiều cải tiến hoàn thiện. Nhược điểm : - Qui trình là các giai đoạn tuần tự nối tiếp nhau, có nghĩa là giai đoạn phân tích phải được hoàn thành rồi đến giai đoạn thiết kế, không cho phép sự quay lui và do đó, khi áp dụng qui trình này sẽ khó khăn khi ở giai đoạn trước có sự thay đổi (do sai xót, do nhu cầu người dùng thay đổi hoặc do có sự tiến hoá hệ thống, ). Qui trình tăng trưởng (D.R. Graham 1988) Tăng trưởng 1 Phân tích Thiết kế Lập trình Thử nghiệm Chuyển giao phần 1 Tăng trưởng 2 Phân tích Thiết kế Lập trình Thử nghiệm Chuyển giao phần 2 Tăng trưởng 3 Phân tích Thiết kế Lập trình Thử nghiệm Chuyển giao phần 3 - Quan điểm chính của qui trình này là phát triển từng phần (phân hệ con) của hệ thống dùng qui trình thác nước. - Lặp : phân chia hệ thống thành những phần có thể phát triển một cách độc lập. Mỗi thành phần trong quá trình phát triển sẽ được áp dụng qui trình thác và được xem như một tăng trưởng của hệ thống. Khi thành phần cuối cùng hoàn tất thì quá trình phát triển toàn bộ hệ thống kết thúc. Nhược điểm : qui trình này không thể áp dụng cho những hệ thống có sự phân chia không rõ ràng hoặc không thể phân chia thành những thành phần tác biệt. Qui trình xoắn ốc (Boehm 88) @ Đại Học KHTN-TP HCM ; ASIA-ITC 9
  10. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Xác định mục tiêu, Đánh giá các các phương án, các phương án ràng buộc Chu trình 3 Chu trình 2 Chu trình 1 Lập kế hoạch cho Phát triển và chi trình kế tiếp kiểm tra Là một quá trình gồm nhiều vòng lặp dựa trên bốn giai đoạn : - Giai đoạn 1 : o Đối với vòng lặp đầu tiên : phân tích yêu cầu o Từ vòng lặp thứ hai trở đi : thiết lập mục tiêu cho vòng lặp, xác định các phương án để đạt mục tiêu đó ; các ràng buộc xuất phát từ các kết quả của các vòng lặp trước. - Giai đoạn 2 : o Đánh giá các phương án dựa trên các sản phẩm đạt được và tiến trình thực thi phương án. o Xác định và giải quyết các rũi ro. - Giai đoạn 3 : o Phát triển và kiểm tra sản phẩm. - Giai đoạn 4 : o Lập kế hoạch cho vòng lặp tiếp theo. Qui trình xoắn ốc cũng có thể áp dụng qui trình khác, ví dụ giai đoạn 3 có thể được thực hiện áp dụng qui trình thác nước. Qui trình Booch (1996) Macro-process Quan niệm Phân tích Thiết kế Cài đặt ; tiến hoá Bảo trì Micro-process Gồm hai tiến trình : - Macro process : đóng vai trò như là bộ khung của micro process và bao phủ toàn bộ phạm vi dự án. Công việc chính của macro process là liên quan đến quản lý kỹ thuật của hệ thống trong việc chú trọng đến yêu cầu của người dùng và thời gian hoàn thành sản phẩm mà ít quan tâm đến chi tiết thiết kế hệ thống. Macro porcess gồm : @ Đại Học KHTN-TP HCM ; ASIA-ITC 10
  11. Phân tích thiết kế hệ thống hướng đối tượng bằng UML o Quan niệm hoá (conceptualization) : xác định yêu cầu căn bản, mục tiêu của hệ thống o Phân tích và phát triển mô hình : sử dụng sơ đồ để mô hình hoá đối tượng hệ thống ; xác định vai trò và trách nhiệm của các đối tượng ; mô hình hoá hành vi của hệ thống thông qua các kịch bản mô tả hành vi. o Thiết kế : thiết kế kiến trúc của hệ thống, các mối quan hệ giữa các lớp, các lớp sẽ được cài đặt, các vị trí định vị xử lý. o Cài đặt, tiến hoá : tinh chế hệ thống thông qua nhiều vòng lặp. Lập trình cài đặt phần mềm. o Bảo trì : điều chỉnh lỗi phát sinh, cập nhật các yêu cầu mới - Micro process : mô tả các hoạt động chi tiết của mỗi giai đoạn thông qua việc phân chia thành các hoạt động chi tiết theo từng nhóm phát triển hoặc theo từng đơn vị thời gian (giờ, ngày, tuần, ). RUP/UML (Rational Unified Process) Qui trình bao gồm bốn giai đoạn chính và đan xen nhiều dòng hoạt động (activity flow) như là : mô hình hoá nghiệp vụ, phân tích yêu cầu, phân tích và thiết kế, cài đặt, thử nghiệm triển khai, Mỗi giai đoạn được hình thành từ những bước lặp (iteration). - Khởi tạo (inception) : o Thiết lập phạm vi dự án, các điều kiện ràng buộc phạm vi, các kiến trúc đế xuất của hệ thống, o Xác định chi phí và thời gian của dự án, o Xác định độ rũi ro và môi trường hệ thống, o Xác định các thay đổi bổ sung, các tác động của các thay đổi này, các rũi ro nếu có, - Tinh chế (elaboration) : o Tinh chế kiến trúc hệ thống, yêu cầu hệ thống và đảm bảo kế hoạch sự ổn định của kế hoạch, o Đánh giá độ rũi ro, các thành phần sử dụng, o Xây dựng nền kiến trúc nền tảng hệ thống, - Xây dựng (construction) : o Quản lý tài nguyên, kiểm soát và thực hiện tối ưu hoá, o Hoàn thành việc phát triển các thành phần của sản phẩm, thử nghiệm sản phẩm, o Đánh giá sản phẩm cài đặt từ các tiêu chuẩn đã được thoả thuận, - Chuyển giao (transition) : o Thực hiện cài đặt hệ thống, o Thử nghiệm sản phẩm đã triển khai, o Thu thập các phản hồi từ phía người dùng, o Bảo trì hệ thống @ Đại Học KHTN-TP HCM ; ASIA-ITC 11
  12. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Phương pháp (method) - Phương pháp là một quá trình tập trung vào một hoặc một vài giai đoạn của toàn bộ qui trình phát triển. Ví dụ : o Phương pháp phân tích yêu cầu : mô tả cách thức và qui trình nhằm thu thập các yêu cầu của hệ thống, o Phương pháp phân tích thiết kế : tập trung vào giai đoạn phân tích và thiết kế o Phương pháp thử nghiệm : qui trình và cách thức cũng như các hoạt động thử nghiệm hệ thống o - Một phương pháp bao gồm một tập các ký hiệu đồ hoạ và văn bản, các luật sử dụng để mô tả các yếu tố hệ thống - Một phương pháp thường được áp dụng trong một qui trình của phương pháp luận nhằm hướng dẫn cách thức thực hiện chi tiết của giai đoạn trong qui trình phát triển. Một số phương pháp Phần sau đây sẽ tổng kết nội dung của một số phương pháp phát triển hệ thống hướng đối tượng: OOD (Object Oriented Design - G.Booch 1991) - Không đưa vào giai đoạn phân tích trong các phiên bản đầu tiên. Các bước phân tích hệ thống chuẩn bị cho giai đoạn thiết kế gồm : o Xác định vấn đề thế giới thực o Phát triển một chiến lược không hình thức hiện thức hoá từng phần đối với các vấn đề đã xác định o Hình thức hoá chiến lược này - Việc hình thức hoá chiến lược bao gồm một thứ tự các công việc sau : o Xác định lớp và đối tượng ở mức trừu tượng hoá o Xác định ngữ nghĩa cho các lớp và đối tượng o Xác định mối quan hệ giữa các lớp và các đối tượng o Cài đặt các lớp và đối tượng - Đưa vào khái niệm gói (package) và dùng như một thành phần tổ chức của mô hình. - Cài đặt các lớp và đối tượng thông qua việc đào sâu các chi tiết của lớp và đối tượng và cách thức cài đặt chúng trong một ngôn ngữ lập trình; cách thức tái sử dụng các thành phần và xây dựng các mô đun từ các lớp và đối tượng. - Trong giai đoạn thiết kế, phương pháp này nhánh mạnh sự phân biệt giữa tầng luận lý (trong thuật ngữ lớp và đối tượng) và tầng vật lý (trong thuật ngữ môđun và xử lý) và phân chia mô hình thành các mô hình động và mô hình tĩnh. o Sơ đồ lớp (mô hình tĩnh) @ Đại Học KHTN-TP HCM ; ASIA-ITC 12
  13. Phân tích thiết kế hệ thống hướng đối tượng bằng UML o Sơ đồ đối tượng(mô hình tĩnh) o Sơ đồ trạng thái (mô hình động) o Sơ đồ thời gian (mô hình động) o Sơ đồ mô- đun o Sơ đồ xử lý HOOD (Hierarchical Object Oriented Design) - Khía cạnh tĩnh được biểu diễn qua sơ đồ đối tượng; văn bản hình thức cho phép hoàn thiện sơ đồ này thông qua việc chỉ dẫn các ràng buộc đồng bộ. - Cấu trúc phân cấp được mô tả thông qua cấu trúc phân rã đối tượng - Các giai đoạn cơ bản của giai đoạn thiết kế như sau : o Xác định vấn đề : xác định ngữ cảnh của đối tượng với mục đích tổ chức và cấu trúc hoá dữ liệu từ các yêu cầu của giai đoạn phân tích. ƒ Diễn đạt vấn đề ƒ Phân tích và cấu trúc hoá dữ liệu yêu cầu : thu thập và phân tích tất cả thông tin liên quan đến vấn đề, bao gồm môi trường mà hệ thống được thiết kế. o Phát triển chiến lược giải pháp: phác hoạ giải pháp vấn đề thông qua việc xác định các đối tượng ở mức trừu tượng hoá cao. o Hình thức hoá và mô hình hoá chiến lược : xác định các đối tượng và các toán tử. Phát sinh một giải pháp thiết kế dùng sơ đồ cho phép trực quan hoá các khái niệm, bao gồm năm bước : ƒ Xác định đối tượng ƒ Xác định các toán tử ƒ Nhóm các đối tượng và các toán tử ƒ Mô tả đồ hoạ ƒ Điều chỉnh các quyết định thiết kế o Hình thức hoá giải pháp : giải pháp được hình thức hoá thông qua ƒ Mô tả hình thức giao diện đối tượng ƒ Mô tả hình thức đối tượng và các cấu trúc điều khiển toán tử OMT (Object modeling Technique) Cung cấp ba tập khái niệm diễn đạt ba cách nhìn về hệ thống. Sử dụng một phương pháp để dẫn dắt tới ba mô hình tương ứng với ba cách nhìn hệ thống. Các mô hình đó là : - Mô hình đối tượng mô tả cấu trúc tĩnh của các đối tượng bên trong hệ thống và các quan hệ của chúng. Các khái niệm chính là : o Lớp o Thuộc tính o Toán tử o Thừa kế o Mối kết hợp (association) o Mối kết hợp thành phần (aggregation) - Mô hình động hệ thống mô tả các khía cạnh của hệ thống có thể thay đổi theo thời gian. Mô hình này được sử dụng để xác định và cài đặt các khía cạnh điều khiển của một hệ thống. Các khái niệm đó là : @ Đại Học KHTN-TP HCM ; ASIA-ITC 13
  14. Phân tích thiết kế hệ thống hướng đối tượng bằng UML o Trạng thái o Trạng thái con/ cha o Sự kiện o Hành động o Hoạt động - Mô hình chức năng mô tả việc chuyển đổi giá trị dữ liệu bên trong hệ thống. Các khái niệm đó là : o Xử lý o Kho dữ liệu o Dòng dữ liệu o Dòng điều khiển o Tác nhân (nguồn, đích) - Phương pháp được phân chia thành bốn giai đoạn : o Phân tích : xây dựng một mô hình thế giới thực dựa vào việc mô tả vấn đề và yêu cầu hệ thống. Kết quả của giai đoạn này là : ƒ Bản mô tả vấn đề ƒ Mô hình đối tượng = sơ đồ lớp đối tượng + tự điển dữ liệu ƒ Mô hình động = sơ đồ trạng thái + sơ đồ dòng sự kiện toàn cục ƒ Mô hình chức năng = Sơ đồ dòng dữ liệu + các ràng buộc o Thiết kế hệ thống : phân chia hệ thống thành các hệ thống con dựa trên việc kết hợp kiến thức về lãnh vực vấn đề và kiến trúc đề xuất cho hệ thống. Kết quả của giai đoạn thiết kế là : ƒ Sưu liệu thiết kế hệ thống : kiến trúc hệ thống cơ sở và các quyết định chiến lược ở mức cao. o Thiết kế đối tượng : xây dựng một mô hình thiết kế dựa trên mô hình phân tích được làm giàu với các chi tiết cài đặt, bao gồm các lớp nền tảng các đối tượng cài đặt máy tính. Kết quả của giai đoạn này : ƒ Mô hình đối tượng chi tiết ƒ Mô hình động chi tiết ƒ Mô hình chức năng chi tiết o Cài đặt : chuyển đổi các kết quả thiết kế vào một ngôn ngữ và phần cứng cụ thể. Đặc biệt nhấn mạnh trên các đặc điểm có thể truy vết, khả năng uyển chuyển và dễ mở rộng. OOA (Object Oriented Analysis– Coad 90, 91) OOA sử dụng các nguyên lý cấu trúc hoá và kết hợp chúng với quan điểm hướng đối tượng tập trung vào giai đoạn phân tích. Phương pháp bao gồm năm bước : - Tìm lớp và đối tượng : xác định cách thức tìm lớp và đối tượng. Tiếp cận đầu tiên bắt đầu với lãnh vực ứng dụng và xác định các lớp, các đối tượng hình thành nền tảng cho ứng dụng. - Xác định cấu trúc : được thực hiện qua hai cách : o Xác định cấu trúc tổng quát hoá – chuyên biệt hoá và xác định sự phân cấp giữa các lớp đã tìm được @ Đại Học KHTN-TP HCM ; ASIA-ITC 14
  15. Phân tích thiết kế hệ thống hướng đối tượng bằng UML o Cấu trúc tổng thể - thành phần (whole – part) được dùng để mô hình hoá cách thức một đối tượng là một phần của đối tượng khác, và cách thức các đối tượng kết hợp thành các loại lớn hơn. - Xác định các chủ đề : phân chia các mô hình lớp, đối tượng thành các đơn vị lớn hơn gọi là chủ đề. - Xác định thuộc tính : xác định các thông tin và các mối liên kết cho mỗi thể hiện. Điều này bao gồm luôn việc xác định các thuộc tính cần thiết để đặc trưng hoá mỗi đối tượng. Các thuộc tính được tìm thấy sẽ được đưa vào đúng mức trong cấu trúc phân cấp. - Xác định các dịch vụ : định nghĩa các toán tử cho lớp bằng cách xác định các trạng thái và các dịch vụ nhằm truy cập và thay đổi trạng thái đó. Kết quả của giai đoạn phân tích là một mô hình gồm năm lớp: - Lớp chủ đề - Lớp các lớp và đối tượng - Lớp cấu trúc (sự thừa kế, mối quan hệ, ) - Lớp thuộc tính - Lớp dịch vụ Một mô hình thiết kế hướng đối tượng bao gồm các thành phần sau: - Thành phần lãnh vực vấn đề (Problem Domain Component) : kết quả của phân tích hướng đối tượng đưa trực tiếp vào thành phần này. - Thành phần tương tác (Humain Interaction Component) : bao gồm các hoạt động như là : phân loại người dùng, mô tả kích bản nhiệm vụ, thiết kế cấu trúc lệnh, thiết kế tương tác chi tiết, lập bản mẫu giao diện tương tác người – máy, định nghĩa các lớp của thành phần tương tác. - Thành phần quản lý nhiệm vụ (Task Management Component) : bao gồm việc xác định các nhiệm vụ (xử lý), các dịch vụ được cung cấp, mức độ ưu tiên, các sự kiện kích hoạt, và cách thức các xử lý trao đổi (với các xử lý khác và với bên ngoài hệ thống). - Thành phần quản lý dữ liệu (Data Management Component) : phụ thuộc rất nhiều vào công nghệ lưu trữ sẵn có và dữ liệu yêu cầu. @ Đại Học KHTN-TP HCM ; ASIA-ITC 15
  16. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Chương 2 CÁC KHÁI NIỆM CƠ BẢN VỀ HƯỚNG ĐỐI TƯỢNG Đối tượng (object) Đối tượng là thành phần trọng tâm của cách tiếp cận hướng đối tượng. Một đối tượng là một đại diện của bất kỳ sự vật nào cần được mô hình trong hệ thống và đóng một vai trò xác định trong lãnh vực ứng dụng. - Là một biểu diễn từ thế giới thực sang thể hiện của tin học (ví dụ : một chiếc xe ô tô trong thế giới thực được biểu diễn trong tin học dùng một khái niệm đối tượng xe ô tô). - Là một sự trừu tượng hoá, một khái niệm có ý nghĩa trong lãnh vực ứng dụng. - Diễn đạt một thực thể vật lý, hoặc một thực thể quan niệm, hoặc một thực thể phần mềm. - Đối tượng có thể là một thực thể hữu hình trực quan (ví dụ : một con người, một vị trí, một sự vật, ) hoặc một khái niệm, một sự kiện (ví dụ : phòng ban, bộ phận, kết hôn, đăng ký, ). Một thực thể phải thoả ba nguyên lý : - Phân biệt (distinction): đơn vị duy nhất (định danh) - Thường xuyên (permanence) : quá trình sống (trạng thái) - Hoạt động (activity) : vai trò, hành vi Đối tượng = định danh + trạng thái + hành vi Ví dụ : một đối tượng xe mô tô Trạng thái: 100cc 38.000 KM Trạng thái 90KM/H Môtô No 53N-7213 Đỏ Hành vi: Chạy() Định danh Đềmáy() Dừng() Hành vi Tắtmáy() Liên kết giữa các đối tượng - Mối kết hợp (association) – liên kết ngữ nghĩa : Giáo viên A Lớp học X giảng dạy Tài xế B Xe tải Y lái @ Đại Học KHTN-TP HCM ; ASIA-ITC 16
  17. Phân tích thiết kế hệ thống hướng đối tượng bằng UML - Phân cấp (hierarchy) – liên kết cấu trúc : Một xe mô tô Bánh xe 1 Bánh xe 2 Động cơ Đối tượng persistent/ transient - Đối tượng transient : là đối tượng có quá trình sống tối đa tương ứng với quá trình chạy ứng dụng (đối tượng không được lưu trữ trạng thái ) - Đối tượng persistent : đối tượng có trạng thái được lưu trữ trong máy tính và có thể được thực thi bởi một ứng dụng khác ứng dụng tạo ra nó (quá trình sống của nó kéo dài và có thể từ ứng dụng này qua ứng dụng khác do trạng thái của nó được lưu trữ trong máy tính). Thông thường, trạng thái của đối tượng này sẽ được lưu trữ vào cơ sở dữ liệu trong quá trình sử dụng, và việc lưu trữ này sẽ duy trì được tình trạng của đối tượng và cung cấp tình trạng này cho những lần thực thi khác của ứng dụng hoặc cung cấp trạng thái của đối tượng cho những ứng dụng khác. Lớp (class) - Một lớp là một mô tả của một tập hợp/ một loại các dối tượng có : o Cùng cấu trúc (định danh, đặc trưng) o Cùng hành vi (trạng thái, vai trò) - Trình bày của lớp : là một hình chữ nhật bao gồm ba phần (không bắt buộc) Xe Tên lớp loại người_sở_hữu số_đăng_ký Thuộc tính (mô tả trạng thái) màu_xe Thay_đổi_tài_xế() Toán tử (mô tả các hành vi) - Trong giai đoạn cài đặt, định danh của lớp được cài đặt từ một khoá. Khoá này cho phép phân biệt rõ các đối tượng của lợp một cách duy nhất. Khái niệm khoá có thể cho phép truy cập bởi người dùng một cách tường minh hoặc ngầm định. Một khoá tường minh có thể được khai báo chung với trạng thái của lớp trong khi đó khái niệm định danh là một khái niệm độc lập. và có các ý nghĩa sau : o Xác định tính duy nhất của đối tượng o Có ý nghĩa sử dụng đối với người dùng Ví dụ : trong lớp Xe có thể khai báo số_đăng_ký là một khoá. Thể hiện của lớp (instance) Thể hiện của lớp là một đối tượng cụ thể được tạo ra trên mô hình lớp : - Các toán tử của lớp mô tả các hành vi chung của các thể hiện - Tất cả các thể hiện của một lớp có chung các thuộc tính @ Đại Học KHTN-TP HCM ; ASIA-ITC 17
  18. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Phân cấp (hierarchy) Là cơ chế hỗ trợ việc tổng quát hoá theo cách thức sau : - Tổng quát hoá các đặc tính chung (định nghĩa các supper-class) - Định nghĩa các đặc tính chuyên biệt nhất của các trường hợp cụ thể (định nghĩa các sub-class) Super-class Sub-class Sub-class - Tổng quát hoá (generalisation) : xây dựng một lớp tổng quát từ các lớp khác cụ thể để đạt được một mức độ trừu tượng hoá có thể. - Chuyên biệt hoá (specialisation) : o Sự phân cấp của các lớp có phép mô tả các lớp chuyên biệt có thể từ các lớp trừu tượng o Sự chuyên biệt hoá cũng có thể được tạo ra để : ƒ Làm giàu thông tin : thêm mới thuộc tính hoặc toán tử vào lớp chuyên biệt so với các lớp trừu tượng ƒ Có thể thay thế hoặc định nghĩa lại các thuộc tính, toán tử trong các lớp chuyên biệt từ thuộc tính, toán tử của các lớp trừu tượng Trong quá trình phân tích hoặc thiết kế hệ thống hướng đối tượng, việc chuyên biệt hoá và tổng quát hoá cho phép định nghĩa các mối quan hệ tập con và làm sáng tỏ tính thừa kế. (Jacobson 1992). Nếu một lớp B thừa kế từ một lớp A, thì có nghĩa rằng tất cả các toán tử và các thuộc tính của lớp A trở thành toán tử và thuộc tính của lớp B. - Quan hệ kế thừa là quan hệ: o Có tính bắc cầu Class A {Nếu lớp B là một chuyên biệt hoá của lớp A và lớp C là một Class B chuyên biệt hoá của lớp B thì lớp C cũng là một chuyên biệt hoá của lớp A} Class C o Có thể đa kế thừa @ Đại Học KHTN-TP HCM ; ASIA-ITC 18
  19. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Giáo viên Nhà nghiên cứu {Lớp Gviên-Nhà NC đa kế thừa tất cả thuộc tính của lớp GViên – Nhà NC Giáo viên và lớp Nhà nghiên cứu} o Và được cài đặt với mục tiêu tái sử dụng - Khái niệm lớp trừu tượng (abstract) – lớp cụ thể (concrete) : Khi xây dựng một cấu trúc lớp phân cấp, chúng đã hình thành các lớp tổng quát và được gọi là lớp trừu tượng. Trong đó, tất cả các thể hiện đối tượng của một lớp trừu tượng đều xuất phát từ một trong những lớp cụ thể của nó. Một lớp trừu tượng không chứa đựng trực tiếp các đối tượng, các thể hiện của nó chỉ là sự xác định trừu tượng hơn của các thể hiện đối tượng trong các lớp cụ thể. Ngược lại, một lớp cụ thể thực sự chứa đựng các đối tượng và thể hiện. Trong ví dụ dưới đây, các lớp Xe tải và Xe ô tô là các lớp cụ thể bởi vì nó sẽ có các thể hiện xe ô tô và xe tải. Xe {Xe là một lớp trừu tượng, nó không có thể Số_xe hiện tồn tại trong thực Tài_xế tế} Loại_xe Số_lượng_sản_xuất Thay_đổi_tài_xế() Số_lượng_sản_xuất() Xe ô tô Xe tải Slượng_khách Tải_trọng_lớn_nhất Thay_đổi_sl_khách() Thay_đổi_tải_trọng_lớn_nhất() {Lớp cụ thể, các thể hiện của nó phản ánh các đối tượng tồn tại thực tế} Tính bao bọc(encapsulation) Che dấu thông tin là nguyên lý để che dấu những dữ liệu và thủ tục bên trong của một đối tượng và cung cấp một giao diện tới mỗi đối tượng như là một cách để tiết lộ ít nhất có thể được về nội dung bên trong của đối tượng. Các cơ thể bao bọc đối tượng tổng quan bao gồm : public, private, và protected @ Đại Học KHTN-TP HCM ; ASIA-ITC 19
  20. Phân tích thiết kế hệ thống hướng đối tượng bằng UML - public : thuộc tính và hành vi của đối tượng có thể được truy cập từ mọi nơi - private : thuộc tính và hành vi của đối tượng chỉ được bên trong lớp - protected : thuộc tính và hành vi của đối tượng chỉ được truy cập từ các lớp con Tính bao bọc là một mục tiêu trong thiết kế hướng đối tượng. Thay vì cho phép một đối tượng truy cập trực tiếp đến dữ liệu của một đối tượng khác, thì đối tượng này sẽ yêu cầu dữ liệu đó thông qua việc gọi thi hành một hành vi đã được thiết kế cho việc cung cấp dữ liệu và một thông điệp sẽ được gởi tới đối tượng đích thông tin được yêu cầu. Điều này không chỉ đảm bảo rằng các lệnh đang hoạt động trong dữ liệu đúng mà còn không cho phép các đối tượng có thể thao tác trực tiếp lên dữ liệu của đối tượng khác. Hoá đơn Hàng hoá Số_hđ mã hàng Ngày_lập tên hàng Số_lượng đơn vị tính Trị_giá đơn giá Trị_giá_hđ() Đơn_giá() Đổi_đơn_giá(đgiá_mới) {thuộc tính đơn giá trong lớp Hàng hoá là private, do đó, tất cả truy cập về đơn giá từ bên ngoài phải thông qua Đơn_giá(), hoặc các thay đổi về đơn giá phải thông qua Đổi_đơn_giá(đgiá_mới)} Một yếu tố quan trọng của tính bao bọc là việc thiết kế khác nhau của các đối tượng có thể sử dụng một phương thức (protocol) chung hoặc giao diện chung cho người dùng đối tượng. Điều này lý giải rằng nhiều đối tượng sẽ trả lời tới cùng thông điệp nhưng mỗi đối tượng sẽ thi hành thông điệp sử dụng các toán tử đã được biến đổi thích ứng tới lớp của nó. Bằng cách này, một chương trình có thể gởi một thông điệp tổng quát và để lại việc cài đặt cho đối tượng nhận. Điều này làm giảm sự phụ thuộc lẫn nhau và gia tăng số lượng trao đổi và tái sử dụng của đối tượng. Ví dụ : các động cơ xe ô tô có thể khác nhau về cách cài đặt và vận hành cụ thể, giao diện giữa tài xế và xe ô tô là thông qua một phương thức chung : ví dụ, đạp cần gas để tăng lực và nhã cần gas để giảm lực của xe. Tất cả tài xế đều biết phương thức này và tất cả tài xế đều sử dụng phương thức này trong tất cả xe ô tô mà không qua tâm đến động cơ của xe ô tô được thực hiện như thế nào (tất nhiên, các động cơ khác nhau thì có cách vận hành khác nhau). Tính đa hình (polymorphism) Trong hệ thống hứơng đối tượng, thuật ngữ đa hình dùng để mô tả các đối tượng có nhiều dạng thức. Đa hình có nghĩa rằng cùng một toán tử có thể xử lý một cách khác nhau trong các lớp khác nhau có chung một (vài) lớp cha (superclass). - Cùng toán tử có thể thi hành khác nhau trong các lớp khác nhau. - Các phương thức khác nhau cùng cài đặt cho toán tử này trong các lớp khác nhau phải có cùng ký hiệu (tên, tham số và giá trị trả về) - Cài đặt của toán tử được xác định bởi lớp đối tượng mà được sử dụng trực tiếp @ Đại Học KHTN-TP HCM ; ASIA-ITC 20
  21. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Hình vẽ() Chữ nhật Tam giác Tròn vẽ() vẽ() vẽ() {Vẽ hình chữ nhật} {Vẽ hình tam giác} {Vẽ hình tròn} Cấu trúc phân cấp trên cho thấy, lớp Hình là lớp tổng quát chung cho các lớp : Chữ nhật, Tam giác, Tròn. Vì cả ba lớp này đều có thể vẽ, do đó, có thể xác định một phương thức vẽ() chung trong lớp Hình. Tuy nhiên, các đối tượng trong các lớp chuyên biệt có thể được thực hiện trong một cách thức có thể khác so với phương thức vẽ() chung. Do đó, mỗi lớp chuyên biệt có thể cài đặt lại phượng thức vẽ() chồng lên phương thức vẽ() của lớp tổng quát. Nếu hệ thống xử lý một danh sách các đối tượng của lớp Hình, thì hệ thống sẽ dò tìm và thực hiện phương thức vẽ() phù hợp cho mỗi đối tượng. Nếu đối tượng đó là của lớp con Chữ nhật thì nội dung cài đặt của phương thức vẽ() trong lớp Chữ nhật sẽ được thực thi. Tương tự cho đối tượng của lớp con Tam giác và Tròn. Đa hình ở đây là cho phép có nhiều hình thức cài đặt của cùng một hành vi (phương thức). Hệ thống sẽ tự động thực hiện phương thức thích hợp cho mỗi đối tượng. Câu hỏi và bài tập @ Đại Học KHTN-TP HCM ; ASIA-ITC 21
  22. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Chương 3 UML (UNIFIED MODELING LANGUAGE) Lịch sử của UML - Số lượng các phương pháp luận hướng đối tượng gia tăng từ dưới 10 đến 50 trong khoảng những năm 1989 đến 1994, và do đó nảy sinh vấn đề là làm cho người phát triển khó tìm thấy một phương pháp luận duy nhất thoả mãn đầy đủ nhu cầu của họ. - Vào tháng mười năm 1994, Rumbaugh đã liên kết với công ty Booch (Rational Sofware Corporation) để kết hợp phương pháp Booch và phương pháp OMT. Và cho ra một bản phác thảo về phương pháp có tên là Unified Process vào tháng mười năm 1995. - Cũng trong năm 1995, Jacobson đã nỗ lực tích hợp phương pháp này với OOSE. Và những tài liệu đầu tiên về UML đã được trình làng vào trong năm 1996. - Phiên bản 1.0 của UML đã được công bố vào tháng giêng 1997, bao gồm các công việc của các thành viên của UML consortium : DEC MCI Systemhouse HP Microsoft i-Logix Oracle Intellicorp Rational Software IBM TI ICON Computing Unisys - Bản thảo về UML phiên bản 1.5 đã được tạo vào tháng ba năm 2003. - Phiên bản UML 2.0 sẽ được tạo vào 2004. UML 2.0 (2004) UML 1.5 (2003) UML 1.3 (99) UML 1.2 (98) Chuẩn hoá bởi OMG UML 1.1 (11- 97) UML 1.0 (1- 97) UML 0.9 (96) UML 0.8 (95) Các thành viên công nghiệp OOSE (HP, IBM,Oracle, Microsoft, Rational, ) Booch OMT Các phương pháp khác @ Đại Học KHTN-TP HCM ; ASIA-ITC 22
  23. Phân tích thiết kế hệ thống hướng đối tượng bằng UML 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 Rational UML OMG consortium U U U U U U U U U M M M M M M M M M L L L L L L L L L 0.8 0.9 1.0 1.1 1.2 1.3 1.4 1.5 2.0 ?? UML ? - UML được tạo ra nhằm chuẩn hoá ngôn ngữ mô hình hoá, UML không phải là một chuẩn về tiến trình và do đó, UML phải được sử dụng kết hợp với một tiến trình phương pháp luận. - UML là một ngôn ngữ dùng để đặc tả, trực quan hoá, và tư liệu hoá phần mềm hướng đối tượng. Nó không mô tả một tiến trình hay một phương pháp mà trong đó chúng ta dùng nó để mô hình hoá. Ví dụ : Công ty Rational Software đề xuất một quy trình RUP (Rational Unified Process) được xem như là một phương pháp luận phát triển hệ thống và có ngôn ngữ mô hình hoá là UML. - UML phủ tất cả các mức mô hình hoá khác nhau trong qui trình phát triển bao gồm chín loại sơ đồ, trong đó, năm sơ đồ dùng biểu diễn khía cạnh tĩnh và bốn sơ đồ biểu diễn khía cạnh động của hệ thống. Các đặc trưng của một tiến trình sử dụng UML Thuở ban đầu, qui trình tuần tự được xem là phương pháp hợp lý nhất để phát triển hệ thống. Tuy nhiên, trải qua vài thập niên, đã cho thấy các dự án sử dụng qui trình tuần tự thường ít thành công, bởi những nguyên do sau đây: - Sự giả định ban đầu có sai sót - Thất bại trong việc kết hợp các nhân tố con người - Các hệ thống ngày càng lớn và thường hay thay đổi - Chúng ta vẫn còn đang trong giai đoạn thăm dò của công nghệ phần mềm, và không có nhiều kinh nghiệm. Đây là lý do chính. Một phương pháp luận sử dụng UML phải kết hợp với một qui trình lặp và điều này sẽ làm giảm đi các hạn chế của qui trình tuần tự. Tính chất lặp gồm các đặc trưng cơ bản sau : - Tính lặp (iterative) o Thay vì nỗ lực xác định tất cả các chi tiết của mô hình trong một thời điểm, chúng ta chỉ xác định các chi tiết đã « đáp ứng » cho thời điểm đó để thực hiện, và o Lặp lại một (hoặc nhiều) vòng lặp khác bổ sung thêm các chi tiết - Gia tăng (incremental) @ Đại Học KHTN-TP HCM ; ASIA-ITC 23
  24. Phân tích thiết kế hệ thống hướng đối tượng bằng UML o Hệ thống tiến hoá thông qua một tập các sự gia tăng o Mỗi sự gia tăng sẽ bù đắp thêm vào hệ thống các tính năng khác - Tập trung vào người dùng (user – concentrated) o Phân tích viên xác định các tính năng của hệ thống thông qua các use case o Người dùng xác nhận các use case này o Thiết kế viên và người phát triển hiện thực hoá các use case o Người thử nghiệm kiểm tra hệ thống về việc thoả mãn các use case được đặt ra. Mô hình Use case Được xác định bởi Mô hình Hiện hực hoá phân tích bởi Phân bố bởi Mô hình thiết kế Cài đặt bởi Mô hình triển khai Kiểm tra bởi Mô hình cài đặt Mô hình thử nghiệm - Hướng kiến trúc (well-defined structure) o Hệ thống được phân chia thành các hệ thống con o Mức luận lý và vật lý phải được xác lập một cách tách biệt trong hệ thống - Các khung nhìn về hệ thống : o Khung nhìn luận lý (logical view): mô tả các yêu cầu chức năng của hệ thống, tức những gì hệ thống nên làm cho người dùng cuối. Đó là sự trừu tượng của mô hình thiết kế và xác định các gói thiết kế chính, các subsystem và lớp chính. Trong UML khung nhìn này có thể được trình bày dùng sơ đồ lớp, sơ đồ đối tượng, sơ đồ mô tả các gói, hệ thống con. o Khung nhìn thực hiện (implementation view): mô tả tổ chức của các đơn thể (module) phần mềm tĩnh (như mã nguồn, tập tin dữ liệu, thành phần, tập tin thực thi, và các thành phần kèm theo khác) trong môi trường phát triển. Trong UML khung nhìn này có thể dùng sơ đồ thành phần để trình bày. o Khung nhìn xử lý (process view): mô tả các khía cạnh xảy ra đồng thời của hệ thống thời gian thực (run-time) (tasks, threads, processes cũng như sự tương tác giữa chúng). Khung nhìn này tập trung vào sự đồng hành, song song, khởi động và đóng hệ thống, khả năng chịu đựng hư hỏng, và sự phân tán các đối tượng. @ Đại Học KHTN-TP HCM ; ASIA-ITC 24
  25. Phân tích thiết kế hệ thống hướng đối tượng bằng UML o Khung nhìn triển khai (deployment): cho thấy các tập tin thực thi và các thành phần khác nhau được triển khai trên các hệ thống như thế nào. Nó giải quyết các vấn đề như triển khai, cài đặt, và tốc độ. Trong UML, khung nhìn này có thể sử dụng sơ đồ triển khai để mô tả. o Khung nhìn use-case: đóng một vai trò đặc biệt đối với kiến trúc. Nó chứa một vài kịch bản hay use case chủ yếu. Ban đầu, chúng được dùng để khám phá và thiết kế kiến trúc trong các giai đoạn bắt đầu và giai đoạn đặc tả, nhưng sau đó chúng sẽ được dùng để xác nhận các khung nhìn khác nhau. Trong UML, khung nhìn này có thể sử dụng sơ đồ use case để minh hoạ. Người dùng Lập trình viên Chức năng Quản trị phần mềm Khung nhìn luận lý Khung nhìn thực hiện (logical view) (implementation view) Khung nhìn use case (Use case view) Khung nhìn xử lý Khung nhìn triển khai (proces view) (deployment view) Quản trị viên tích hợp hệ thống Thiết kế viên hệ thống Hiệu năng Hình thái hệ thống Tính co giản Chuyển giao, cài đặt Thông lượng Truyền thông Cần phân biệt khung nhìn kiến trúc với mô hình: mô hình là sự trình bày hoàn chỉnh về hệ thống, trong khi khung nhìn kiến trúc chỉ tập trung vào những gì có ý nghĩa về mặt kiến trúc, tức là những gì có tác động rộng lớn đến cấu trúc của hệ thống và lên tốc độ, sự hoàn thiện, tính tiến hóa của nó. Các sơ đồ trong UML - Các sơ đồ mô tả khía cạnh tĩnh o Sơ đồ đối tượng (object diagram) o Sơ đồ lớp (class diagram) o Sơ đồ use case (use case diagram) o Sơ đồ thành phần (component diagram) o Sơ đồ triển khai (deployment diragram) - Các sơ đồ mô tả khía cạnh động o Các sơ đồ tương tác (interaction diagram) ƒ Sơ đồ tuần tự (sequence diagram) ƒ Sơ đồ hợp tác (collaboration diagram) o Sơ đồ hoạt động (activity diagram) o Sơ đồ chuyển dịch trạng thái (state transition diagram) @ Đại Học KHTN-TP HCM ; ASIA-ITC 25
  26. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Sơ đồ lớp và đối tượng: được sử dụng để mô hình hoá cấu trúc tĩnh của hệ thống trong quá trình phát triển. Mỗi sơ đồ chứa đựng các lớp và các mối quan hệ giữa chúng (quan hệ kế thừa (heritage), quan hệ kết hợp (association), quan hệ tập hợp (aggregation), quan hệ thành phần (composition)). Chúng ta cũng có thể mô tả các hoạt động của lớp (operation). Sơ đồ đối tượng là một thể hiện của sơ đồ lớp. Nó mô tả trạng thái chi tiết của hệ thống tại một thời điểm cụ thể và là bức tranh của hệ thống tại một thời điểm, do đó, biểu đồ đối tượng dược dùng để minh hoạ một trường hợp thực tế của sơ đồ lớp. Sơ đồ đối tượng có cùng ký hiệu với biểu đồ lớp. Sơ đồ đối tượng được dùng để minh hoạ một trường hợp phức tạp của bức tranh thực tế về hệ thống trong các thể hiện cụ thể. Ví dụ : Sơ đồ lớp Tài xế Sở hữu Xe 0 1 1 * 1 Của * Bằng lái xe Xe tải Xe ô tô Xe mô tô Tác giả Sách 1 1 * tênTácGiả: string tựaSách: string địaChỉ: string nămXuấtBản: integer Sơ đồ đối tượng UML:Sách tựaSách =’UML’ nămXuấtBản=1998 Hoàng:Tác giả tênTácGiả =’Nguyễn Văn Hoàng’ địaChỉ=’123-Nguyễn Văn Cừ - Q5’ Cơ sở dữ liệu:Sách tựaSách =’UML’ nămXuấtBản=1997 Sơ đồ use case : xuất phát từ các mô hình use case của phương pháp OOSE (Jacobson). Nó mô tả giao diện với một hệ thống từ quan điểm và cách nhìn của người sử dụng. Một sơ đồ use case mô tả các tình huống tiêu biểu của việc sử dụng một hệ thống. Nó biểu thị các trường hợp sử dụng (trong việc mô hình hoá các tính năng hệ thống) và các tác nhân (trong việc mô hình hoá các vai trò tham gia bởi các cá nhân tương tác với hệ thống), và mối quan hệ giữa các use case và các tác nhân. Ví dụ : sơ đồ use case một hệ thống quản lý một thư viện @ Đại Học KHTN-TP HCM ; ASIA-ITC 26
  27. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Mượn sách Trả sách Thủ thư Mượn tại chổ Đọc giả Đọc sách, báo Mua sách Nhà cung cấp Sơ đồ thành phần : được sử dụng để biểu thị các nhìn tĩnh trong việc cài đặt một hệ thống. Mỗi sơ đồ bao gồm các thành phần (component) và các mối quan hệ phụ thuộc giữa chúng trong môi trường cài đặt. Một thành phần đại diện cho một yếu tố cài đặt vật lý của môi trường (mã nguồn, mã thực thi, tập tin, cơ sở dữ liệu, một thư viện hàm, ). Ví dụ : sơ đồ thành phần của một hệ thống phần mềm quản lý thư viện Tiện ích Cơ sở dữ liệu Giao diện Xử lý Sơ đồ triển khai : mô tả cách bố trí vật lý các thiết bị và sự phấn phối các thành phần trú ngụ tại các thiết bị này. Một sơ đồ triển khai bao gồm các nút (node) đại diện cho các tài nguyên thiết bị và các thành phần được cài đặt trong thiết bị, các liên kết trong sơ đồ dùng để mô tả sự trao đổi giữa các nút. Sơ đồ triển khai biểu thị một sự tương ứng giữa cấu trúc phần mềm của một hệ thống và kiến trúc về bố trí thiết bị của nó. Ví dụ : sơ đồ triển khai của hệ thống quản lý thư viện @ Đại Học KHTN-TP HCM ; ASIA-ITC 27
  28. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Node 1 (phòng quản trị):Server CSDL Node 3 (đọc giả):APP Giao diện Node 2 (phòng quản trị):APP Server Node 4 (thủ thư):APP Tiện ích Cơ sở dữ liệu Giao diện Xử lý Sơ đồ tuần tự và sơ đồ hợp tác : trình bày các cách nhìn động về tương tác giữa các đối tượng của hệ thống trong quá trình phát triển. Sơ đồ hợp tác mô tả sự hợp tác giữa một nhóm các đối tượng trong hoạt động để đạt một mục tiêu cụ thể. Sơ đồ tuần tự thêm vào chiều thời gian nhằm thể hiện trực quan thứ tự trao đổi của các thông điệp (message). Ví dụ : sơ đồ tuần tự mô tả hoạt động của xử lý cuộc gọi của máy điện thoại :Người gọi :Máy gọi Tổng đài :Máy nhận :Người nhận Nhấc máy Tín hiệu Quay số Kết nối Tín hiệu Đổ chuông Nhấc máy Tín hiệu Gác máy Tín hiệu gác máy Tín hiệu gác máy Tin hiệu gác máy @ Đại Học KHTN-TP HCM ; ASIA-ITC 28
  29. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Sơ đồ chuyển đổi trạng thái : hình thành từ phương pháp OMT và Booch. Mỗi sơ đồ được dùng có liên quan đến một lớp để biểu thị các trạng thái khác nhau của đối tượng của lớp và các biến cố kích hoạt sự chuyển dịch giữa các trạng thái. Ví dụ : sơ đồ trạng thái của sách trong thư viện Muợn Sẵn sàng cho mượn Trả Đang mượn Nhập kho lưu trữ Chấm dứt lưu hành Đánh mất Đánh mất Đánh mất Lưu trữ Hết lưu hành Mất Nhập kho Đánh mất Thanh lý Sơ đồ hoạt động : dùng để mô hình hoá các dòng hoạt động liên kết tới các lớp như là trong trường hợp của một nhóm các lớp hợp tác cùng thực hiện trong một loại tiến trình. Mỗi lớp sẽ đảm nhiệm các hoạt động và các chuyển dịch như được mô tả trong sơ đồ chuyển dịch trạng thái. Tuy nhiên, một sơ đồ hoạt động có thể liên quan đến nhiều lớp hơn là một lớp. Mặt khác nó mô tả tiến trình tuần tự các hoạt động, sự đồng bộ hoá các dòng điều khiển song song, các điều kiện và quyết định, điểm bắt đầu và điểm kết thúc tiến trình. Ví dụ : sơ đồ hoạt động đơn giản của hoạt động mượn sách thư viện Kiểm tra các sách đã mượn [Độc giả đến mượn sách] [Sách đã mượn 3] Cập nhật thông tin muợn Các hệ thống sử dụng UML trong việc mô hình hoá Việc sử dụng UML trong quá trình mô hình hoá có thể áp dụng trong các loại hệ thống sau : Hệ thống nghiệp vụ (business system) : mô tả tài nguyên (nhân lực, tài lực, tài sản, ), mục tiêu, luồng công việc, các qui tắc, ràng buộc trong hoạt động sản xuất kinh doanh của doanh nghiệp. Ví dụ : các công ty sản xuất, cửa hàng kinh doanh, y tế, giáo dục, Hệ thống thông tin (informaton system) : thu thập và lưu trữ, biến đổi dữ liệu nhằm cung cấp thông tin đáp ứng nhu cầu người nhận trong các tổ chức hoạt động nghiệp vụ. Hệ thống thông tin cũng được chia thành nhiều loại tuỳ thuộc vào quy mô và độ phức tạp : hệ thống thông tin tác nghiệp : là hệ thống chuyên xử lý việc thu thập và truy tìm thông tin trong môi hoạt động nghiệp vụ. Hệ thống thông tin quản lý : xử lý tổng hợp dữ liệu thông qua các thống kê báo cáo nhằm đáp ứng thông tin cho các nhà quản lý theo dõi tình hình hoạt động. Hệ thống thông tin chuyên gia, hệ hổ trợ ra quyết định : xử lý và tri thức hoá các dữ liệu hiện @ Đại Học KHTN-TP HCM ; ASIA-ITC 29
  30. Phân tích thiết kế hệ thống hướng đối tượng bằng UML tại nhằm đáp ứng các nhu cầu nâng cao về mặt thông tin như là hỗ trợ giải đáp tự động, hỗ trợ ra quyết định, dự báo tình hình tương lai, Phần mềm hệ thống (System software) : xây dựng các công cụ phần mềm cơ sở cho các phần mềm khác sử dụng như là hệ điều hành, hệ quản trị cơ sở dữ liệu, công cụ phát triển, . Hệ thống nhúng (embeded system) : là một loại hệ thống phần mềm được xây dựng gắn trên một loại thiết bị như : điện thoại di động, thiết bị điều khiển, Các hệ thống nhúng này thường được lập trình dùng ngôn ngữ cấp thấp hoặc chuyên dụng và có bộ nhớ lưu trữ cũng như màn hình. Hệ thống kỹ thuật (Technical system) : xử lý và điều khiển các thiết bị kỹ thuật như hệ thống viễn thông, hệ thống quân sự, hay các quá trình xử lý kỹ thuật công nghiệp (dây chuyền sản xuất, vận hành máy móc, ). Đây là loại thiết bị phải xử lý các giao tiếp đặc biệt , không có phần mềm chuẩn và thường là các hệ thống thời gian thực (real time). @ Đại Học KHTN-TP HCM ; ASIA-ITC 30
  31. Phân tích thiết kế hệ thống hướng đối tượng bằng UML PHẦN 2 PHÂN TÍCH HỆ THỐNG Mục tiêu Giúp cho người học nắm vững các nội dung về: - Tiến trình phân tích hướng đối tượng - Tiến trình, nội dung và các phương pháp khảo sát yêu cầu - Phân tích chức năng hệ thống bằng mô hình hoá use case - Hiểu về hệ thống nghiệp vụ và mô hình hoá hệ thống nghiệp vụ - Phân loại và xác định đối tượng hệ thống bằng việc xây dựng sơ đồ lớp Giới thiệu Bước đầu tiên để tìm ra một giải pháp thích hợp cho vấn đề hệ thống là hiểu vấn đề và lãnh vực của hệ thống đó. Mục tiêu chính của phân tích là nắm bắt một hình ảnh đầy đủ, không mơ hồ, và nhất quán về yêu cầu hệ thống và những gì hệ thống sẽ phải làm để đáp ứng đòi hỏi và nhu cầu người dùng. Điều này được thực hiện bằng cách xây dựng các mô hình của hệ thống với mục tiêu tập trung vào khía cạnh biểu diễn hệ thống về mặt nội dung (nghĩa là các mô hình tập trung vào làm rõ hệ thống có những gì) hơn là cách thức mà hệ thống thực hiện nội dung đó. Do đó, kết quả của giai đoạn phân tích là làm rõ các yếu tố hệ thống từ quan điểm và cách nhìn của người sử dụng mà không quan tâm đến cách thức chi tiết mà máy tính thực hiện nội dung đó. Phân tích là một tiến trình chuyển đổi một định nghĩa vấn đề từ một tập mờ các sự kiện, các dự kiến mang tính tưởng tượng thành một diễn đạt chặt chẽ các yêu cầu hệ thống. Thực sự, phân tích là một hoạt động mang tính sáng tạo bao gồm việc hiểu vấn đề, các ràng buộc liên quan đến vấn đề đó và các phương pháp để khống chế hoặc giải quyết những ràng buộc. Đây là một tiến trình lặp cho đến khi các vấn đề phải được rõ ràng. Phần này gồm ba chương bao gồm: xác định yêu cầu hệ thống; mô hình hoá use case; mô hình hoá nghiệp vụ; và xây dựng sơ đồ lớp. @ Đại Học KHTN-TP HCM ; ASIA-ITC 31
  32. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Chương 4 XÁC ĐỊNH YÊU CẦU HỆ THỐNG Mục tiêu Qua chương này, chúng ta có thể hiểu: - Mục tiêu của việc khảo sát hệ thống - Nội dung của việc khảo sát và các đối tượng để tiếp cận khảo sát - Môt số phương pháp khảo sát: phỏng vấn, bảng câu hỏi, phỏng vấn nhóm, phân tích tài liệu, thiết kế kết hợp người dùng, bản mẫu (prototype) - Yêu cầu và việc phân loại các yêu cầu hệ thống Mục đích khảo sát yêu cầu Khảo sát hệ thống là nhằm thu thập tốt nhất thông tin phản ánh về hệ thống hiện tại, để từ đó làm cơ sở cho việc phân tích và xây dựng hệ thống mới giải quyết tồn tại bất cập của hệ thống. Vậy khảo sát yêu cầu bao gồm những mục tiêu sau: - Tiếp cận với nghiệp vụ chuyên môn, môi trường của hệ thống - Tìm hiểu vai trò, chức năng, nhiệm vụ và cách thức hoạt động của hệ thống - Nêu ra được các điểm hạn chế, bất cập của hệ thống cần phải thay đổi - Đưa ra được những vấn đề của hệ thống cần phải được nghiên cứu thay đổi. Nội dung khảo sát Nội dung khảo sát phải tìm hiểu được các nội dung của hệ thống như sau: - Các mục tiêu hoạt động của đơn vị, các công việc và cách thức hoạt động để đạt những mục tiêu đó. - Những thông tin cần để thực hiện công việc từng loại công việc - Các nguồn dữ liệu (định nghĩa, cấu trúc, dung lượng, kích thước, ) bên trong và bên ngoài đơn vị. Có thể bao gồm: o Các hồ sơ, sổ sách, tập tin o Biểu mẫu, báo cáo, qui tắc, quy định, công thức. o Các qui tắc, qui định ràng buộc lên dữ liệu o Các sự kiện tác động lên dữ liệu - Tìm hiểu khi nào, như thế nào, và bởi ai các dữ liệu đó được tạo ra, di chuyển, biến đổi và được lưu trữ. Ứng với mỗi xử lý thực hiện tìm hiểu: o Phương pháp: cách thức thực hiện o Tần suất: số lần thực hiện trong một đơn vị thời gian o Khối lượng: độ lớn thông tin thực hiện o Độ phức tạp: xử lý là một là một quá trình phức tạp liên quan đến nhiều loại dữ liệu hay chỉ là một tính toán đơn giản với một vài loại dữ liệu. o Độ chính xác: độ chính xác của kết quả thực hiện - Thứ tự và các phụ thuộc khác giữa các hoạt động truy xuất dữ liệu khác nhau @ Đại Học KHTN-TP HCM ; ASIA-ITC 32
  33. Phân tích thiết kế hệ thống hướng đối tượng bằng UML - Các chính sách, hướng dẫn mô tả hoạt động quản lý, thị trường và môi trường hệ thống - Các phương tiện, tài nguyên có thể sử dụng - Trình độ chuyên môn sử dụng vi tính của các đối tượng xử lý thông tin hệ thống - Môi trường hệ thống (kinh tế, xã hội, cơ quan chủ quản) - Các đánh giá, phàn nàn về hệ thống hiện tại; các đề xuất giải quyết. Đối tượng khảo sát Có nhiều nguồn có thể cung cấp thông tin để đáp ứng nội dung khảo sát yêu cầu. Mỗi nguồn có một hình thức khác nhau do đó phải có một cách tiếp cận khảo sát khác nhau. Các đối tượng khảo sát đó là: Người dùng - Các cán bộ lãnh đạo, cán bộ quản lý: các đối tượng này sẽ giúp cho phân tích viên nắm bắt được tổng quan cấu trúc hệ thống, mục tiêu chung mà hệ thống mới mong muốn mang lại. Các thông tin mà đối tượng này mang lại thường là chiều rộng, mang tính tổng thể, chiến lược không mô tả chi tiết cách thức phải thực hiện. - Người sử dụng, nhân viên nghiệp vụ: các đối tượng này sẽ cung cấp thông tin chi tiết cách thức mà họ đang thực hiện công việc gồm các bước cụ thể, các giấy tờ biểu mẫu liên quan. Các thông tin mà đối tượng mang lại thường là chiều sâu, chi tiết, cục bộ bỏ qua ý tưởng chiến lược mang tính tổng thể. - Nhân viên kỹ thuật: các đối tượng này sẽ cung cấp thông tin về tình trạng công nghệ, trang thiết bị, phần mềm hiện hành đang sử dụng và khả năng, trình độ về kỹ thuật của họ. Các đối tượng này thường trợ giúp rất lớn trong việc huấn luyện, triển khai và bảo trì hệ thống mới. Tài liệu - Tài liệu về sổ sách, biễu mẫu, tập tin: nguồn cung cấp các thông tin về dữ liệu, luồng dữ liệu, giao dịch và xử lý giao dịch. Đặc biệt là các biểu mẫu đây chính là kết quả đầu ra của hệ thống. - Tài liệu về qui trình, thủ tục: nguồn cung cấp thông tin về qui trình xử lý, vai trò xử lý của các nhân viên, chi tiết mô tả công việc của nhân viên, các qui định thủ tục. - Các thông báo: các mẫu thông báo của hệ thống đối với môi trường ngoài, giữa các bộ phận trong hệ thống (ví dụ: thông báo họp mặt khách hàng, thông bao mời thầu, thông báo từ chối đơn hàng, hoặc các thông báo nội bộ như là thông báo bổ nhiệm, thông báo nâng lương, ) Chương trình máy tính - Các chương trình phần mềm hệ thống đang sử dụng, các chương trình này giúp xác định được cấu trúc dữ liệu hệ thống, thói quen của người sử dụng, chức năng mà hệ thống mới chưa đáp ứng được, số liệu thử nghiệm hệ thống. Phương pháp xác định yêu cầu Các phương pháp truyền thống xác định yêu cầu Phỏng vấn Phỏng vấn là một hình thức khảo sát thu thập thông tin trực tiếp từ các đối tượng sẽ sử dụng hệ thống. Vì mỗi người dùng sẽ có những hiểu biết nhất định về một phần công việc của mình trong hệ thống hiện tại và mong muốn hệ thống mới về những gì sẽ phục vụ và trợ giúp @ Đại Học KHTN-TP HCM ; ASIA-ITC 33
  34. Phân tích thiết kế hệ thống hướng đối tượng bằng UML cho công việc của họ. Ví dụ: một kế toán viên chi tiết thì biết được chi tiết các loại chứng từ, cách sắp xếp và xử lý chứng từ, còn kế toán viên tổng hợp thì chỉ quan tâm đến những số liệu nào và cách thức để tổng hợp số liệu đó để tạo ra các báo cáo thống kê, tổng hợp, Do đó, việc phỏng vấn phải được thực hiện trên nhiều người dùng khác nhau (ba loại người dùng) nhằm thu thập nhiều nhất yêu cầu hệ thống. Phỏng vấn là một cách thức đối thoại trực tiếp trong đó, phân tích viên sẽ ra câu hỏi và đối tượng phỏng vấn sẽ trả lời câu hỏi. Qui trình các bước thực hiện như sau: Phân tích viên Đơn vị Lên kế hoạch phỏng vấn Xác nhận kế hoạch phỏng vấn Chuẩn bị chủ đề, câu hỏi Xắp xếp nhân sự phỏng vấn tham gia phỏng vấn Gởi chủ đề phỏng vấn Đặt câu hỏi Trả lời Ghi nhận Kiểm tra và đánh giá kết Bổ sung hoặc xác nhận quả kết quả Tìm kiếm các quan điểm khác Hình 1. Sơ đồ mô phỏng quá trình phỏng vấn Đầu tiên phân tích viên chuẩn bị một kế hoạch phỏng vấn tổng quát, kế hoạch này sẽ liệt kê tất cả các lãnh vực của hệ thống cần khảo sát và thời gian dự kiến cho từng lãnh vực. Mẫu kế hoạch như sau: Kế hoạch phỏng vấn tổng quan Hệ thống: . Người lập: Ngày lập: / / . STT Chủ đề Yêu cầu Ngày bắt đầu Ngày kết thúc @ Đại Học KHTN-TP HCM ; ASIA-ITC 34
  35. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Kế hoạch phỏng vấn này sẽ được gởi đến đơn vị để được xác nhận về thời gian và bố trí nhân viên nào sẽ tham gia trả lời phỏng vấn. Một cuộc phỏng vấn sẽ hiệu quả hơn khi người phỏng vấn chuẩn bị các câu hỏi và thiết lập cho mình một hướng dẫn phỏng vấn và đối tượng trả lời biết trước được các câu hỏi để chuẩn bị thì chắc chắn thông tin trả lời sẽ xác định hơn và thời gian phỏng vấn sẽ được rút ngắn. Sau khi kết thúc phỏng vấn, phân tích viên phải dành thời gian để tổng hợp lại các kết qủa ghi nhận được, loại bỏ các thông tin trùng lắp, tìm ra vấn đề nào vẫn chưa rõ ràng cần phải hỏi lại, nếu cần thiết gởi bản kết quả phỏng vấn đến người được phỏng vấn nhờ xác nhận lại. Sau đó, phân tích viên nên tham khảo thêm các quan điểm khác về vấn đề đã phỏng vấn để có một quan điểm tổng quan hơn trong việc đánh giá kết quả ghi nhận được. Bảng kế hoạch hướng dẫn buổi phỏng vấn Hệ thống: Người phỏng vấn: . Phân tích viên: Vị trí/ phương tiện Văn phòng, phòng họp, điện thoại, Mục tiêu: Dữ liệu gì? Lãnh vực nào? Chi tiết buổi phỏng vấn Thời gian ước lượng (phút) Giới thiệu Tổng quan của hệ thống Chủ đề 1 Các câu hỏi Chủ đề 2 Các câu hỏi Tóm tắt các điểm chính Câu hỏi của người trả lời phỏng vấn Kết thúc Tổng: Quan sát tổng quan Phát sinh ngoài dự kiến Bảng câu hỏi mẫu dành cho phân tích viên để chuẩn bị câu hỏi và ghi nhận kết quả phỏng vấn (kết quả trả lời và kết quả quan sát về thái độ cử chỉ biểu hiện bên ngoài) Người được phỏng vấn: Ngày: / / . Câu hỏi Ghi nhận Câu hỏi 1: Trả lời: @ Đại Học KHTN-TP HCM ; ASIA-ITC 35
  36. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Kết quả quan sát: Ví dụ: Người được phỏng vấn: Trần Thị X Ngày: 05/08/2003 Câu hỏi Ghi nhận Câu hỏi 1: Trả lời: Tất cả đơn hàng của khách hàng phải Phải thanh toán trước hoặc ngay khi giao. được thanh toán trước rồi mới giao hàng? Kết quả quan sát: Thái độ không chắc chắn Câu hỏi 2: Trả lời Anh Chị muốn hệ thống mới sẽ giúp cho Dữ liệu chỉ nhập một lần và các báo cáo Anh Chị điều gì? tự động tính toán Kết quả quan sát Không tin tưởng lắm, hình như đã triễn khai thất bại một lần Loại câu hỏi phỏng vấn: Câu hỏi mở: là câu hỏi giúp cho việc trả lời được tự do trong phạm vi hệ thống. Kết quả trả lời không tuân theo một vài tình huống cố định. Mục đích của câu hỏi mở là khuyến khích người trả lời đưa ra được tất cả ý kiến có thể trong khuôn khổ câu hỏi. Do đó, câu hỏi mở dùng để thăm dò, gợi mở vấn đề và người trả lời phải có một kiến thức tương đối. Ví dụ: “Anh (Chị) đang xử lý thông tin gì?” hoặc “Anh (Chị) có khó khăn gì khi quản lý dữ liệu của mình?” Câu hỏi đóng: là câu hỏi mà sự trả lời là việc chọn lựa một hoặc nhiều trong những tình huống xác định trước. Do đó, câu hỏi đóng được dùng xác định một tình huống cụ thể. Ví dụ: “Điều nào dưới đây là tốt nhất đối với HTTT Anh (Chị) đang sử dụng?” □ Dễ dàng truy cập đến tất cả dữ liệu cần □ Thời gian trả lời tốt nhất của hệ thống □ Khả năng chạy đồng thời với các ứng dụng khác Câu hỏi đóng thường được thiết kế theo một trong những dạng sau: - Đúng – sai - Nhiều chọn lựa (có thể một trả lời hoặc trả lời tất cả chọn lựa) - Tỉ lệ trả lời: từ xấu đến tốt, từ rất đồng ý đến hoàn toàn không đồng ý. Mỗi điểm trên tỉ lệ nên có một nghĩa rõ ràng và nhất quán và thường có một điểm trung lập ở giữa - Xếp hạng các chọn lựa theo thứ tự mức độ quan trọng Xắp xếp câu hỏi: thứ tự câu hỏi phải hợp lý, phù hợp với mục tiêu khảo sát và khả năng của người trả lời. Các thứ tự có thể là: - Thu hẹp dần: ban đầu là những câu hỏi rộng, khái quát và càng về sau thì thu hẹp đến một mục tiêu. - Mở rộng dần: ban đầu đề cập đến một điểm nào đó rồi mở rộng dần phạm vi đề cập @ Đại Học KHTN-TP HCM ; ASIA-ITC 36
  37. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Câu hỏi mở Câu hỏi đóng Ưu điểm - Không ràng buộc kết quả - Thời gian trả lời ngắn trả lời - Nội dung trả lời tập trung, - Có thể phát sinh ý tưởng chi tiết mới Khuyết điểm - Thời gian dễ kéo dài - Mất nhiều thời gian chuẩn - Nội dung trả lời có thể bị câu hỏi vượt phạm vi câu hỏi - Không mở rộng được kết quả trả lời Khảo sát dùng bảng câu hỏi (questionaire) Phỏng vấn là một phương pháp hiệu quả để trao đổi và thu thập được những thông tin quan trọng từ phía người dùng. Tuy nhiên, thực hiện phỏng vấn cũng rất tốn kém về thời gian và nguồn lực. Phương phướng khảo sát dùng bảng câu hỏi ít tốn kém hơn, thời gian trả lời lại nhanh hơn, kết quả xác định hơn và thu thập được thông tin từ nhiều đối tượng hơn trong cùng một thời gian ngắn. Tuy nhiên, phương pháp này lại thụ động và ít mang lại chiều sâu hơn phương pháp phỏng vấn. Để thực hiện, các công việc phân tích viên cần phải làm rõ: - Tập hợp câu hỏi thành từng nhóm - Phân loại các đối tượng sử dụng thành nhóm và gởi nhóm câu hỏi nào đến nhóm người nào. Tổng quát , việc góm nhóm sẽ được thực hiện bởi một hoặc sự kết hợp của bốn phương pháp sau: o Đối tượng tích cực: đối tượng có vị trí thuận lợi, sẵn lòng để được khảo sát, hoặc những đối tượng có nhiều động lực trả lời nhất. o Nhóm ngẫu nhiên: chọn ngẫu nhiên một nhóm người dùng trong danh sách để gởi câu hỏi. o Theo chủ định: chọn những người thoả các tiêu chuẩn xác định nào đó. Ví dụ: những người đã làm việc với hệ thống 2 năm trở lên, những người thường xuyên sử dụng hệ thống, o Chọn theo loại: người dùng, quản lý, Thông thường, người ta kết hợp các phương pháp lại. Trong bất kỳ trường hợp nào khi nhận được trả lời chúng ta nên kiểm tra lại các trường hợp không trả lời để tìm ra nguyên nhân và xem xét các kết quả trả lời là hợp lệ và đủ để được chấp nhận không. So sánh giữa phỏng vấn và bảng câu hỏi được liệt kê dưới đây Đặc điểm Phỏng vấn Bảng câu hỏi Sự phong phú thông Cao (qua nhiều kênh: trả lời, Trung bình tới thấp (chỉ trả tin cử chỉ, ) lời) Thời gian Có thể kéo dài Thấp, vừa phải Chi phí Có thể cao Vừa phải Cơ hội nắm bắt và Tốt: việc phát hiện và chọn lọc Hạn chế: sau khi thu thập phát hiện các câu hỏi có thể được đặt ra dữ liệu cơ sở bởi hoặc người phỏng vấn @ Đại Học KHTN-TP HCM ; ASIA-ITC 37
  38. Phân tích thiết kế hệ thống hướng đối tượng bằng UML hoặc người được phỏng vấn Tính bảo mật Mọi người biết lẫn nhau Không biết người trả lời Vai trò tham gia Người được phỏng vấn đóng Trả lời thụ động, không một vai trò quan trọng và có chắc chắn quyết định kết thể quyết định kết quả quả Phỏng vấn nhóm Các yêu cầu được thu thập có thể sử dụng phương pháp phỏng vấn hoặc điều tra dùng bảng câu hỏi. Tuy nhiên, các kết quả phỏng vấn các đối tượng khác nhau có thể dẫn đến sự không nhất quán thông tin về hệ thống hiện hành và yêu cầu về hệ thống mới. Do đó, chúng ta lại phải thực hiện việc kiểm tra, chọn lọc và quyết định chính xác đâu là thông tin đúng và được chấp nhận cuối cùng. Thông thường chúng ta tiếp tục thực hiện các trao đổi và gặp gở các nhân vật quan trọng có thể quyết định định và giới hạn được kết quả thông tin. Các cuộc phỏng vấn mới này thường tốn thời gian và có khi lại trả lời lại các câu hỏi mà chúng ta đã được trả lời trước đó bởi những người khác. Do đó, phương pháp phỏng vấn từng cá nhân riêng lẽ vẫn còn những hạn chế nhất định. Phân tích viên Người phỏng vấn Câu hỏi về nghiệp vụ Trả lời về kỹ thuật Phỏng vấn Câu hỏi về kỹ thuật nhóm Trả lời về nghiệp vụ Trả lời về kỹ thuật Câu hỏi tổng quan, Phỏng vấn nhóm là một phương pháp tốt có thể giúp giải quyết được những yêu cầu trái ngược nhau. Các đặc điểm của phỏng vấn nhóm bao gồm: - Nhiều phân tích viên phụ trách nhiều lãnh vực khác nhau - Nhiều đối tượng phỏng vấn khác nhau mỗi đối tượng phụ trách một lãnh vực, có thể phân cấp từ quản lý đến nhân viên trực tiếp liên quan. - Tổ chức một buổi phỏng vấn chung gồm các phân tích viên và các đối tượng phỏng vấn. - Mỗi phân tích viên có thể đặt câu hỏi và các đối tượng đều có thể trả lời. Phân tích viên có thể ghi nhận lại chỉ những ý kiến liên quan đến lãnh vực của mình. Lợi điểm: - Giảm thiểu thời gian phỏng vấn: tất cả các yêu cầu sẽ được thông suốt tại một thời điểm thay vì phải phỏng vấn từng đối một tại những thời điểm khác nhau và thời gian sẽ kéo dài ra @ Đại Học KHTN-TP HCM ; ASIA-ITC 38
  39. Phân tích thiết kế hệ thống hướng đối tượng bằng UML - Cho phép các đối tượng phỏng vấn nghe được ý kiến chủ đạo của lãnh đạo trên những ý kiến bất đồng liên quan đến một vấn đề đặt ra. Đây là cơ hội làm cho các đối tượng thông suốt được ý kiến chủ đạo liên quan đến hệ thống mới. Nhược điểm: Nhược điểm chính là rất khó để tổ chức một buổi phỏng vấn nhóm vì khó để tìm được một thời gian và vị trí thích hợp cho tất cả mọi người. Ngày nay với công nghệ truyền thông phát triển cho phép tổ chức một buổi họp với các thành viên ở khoảng cách xa nhau (ví dụ: dùng Video conference). Quan sát trực tiếp Quan sát trực tiếp tại nơi làm việc, hiện trường nhằm thu thập chính xác cách thức và qui trình làm việc thực tế của hệ thống. Ưu điểm: - Đảm bảo tính trung thực của thông tin. Bởi vì các phương pháp phỏng vấn bị phụ thuộc vào cách thức mà người dùng trả lời, kiến thức và chủ quan của họ, - Thu thập tốt về thông tin mô tả tổng quan về hệ thống. Hạn chế - Thời gian có thể kéo dài. - Làm cho người dùng khó chịu khi thực hiện công việc, vì có cảm giác như bị theo dõi. Do đó, họ thường thay đổi cách thức làm việc không đúng với hiện trạng. Thông thường, người ta kết hợp các phương pháp phỏng vấn với phương pháp quan sát để tiến hành khảo sát. Phân tích tài liệu và thủ tục Phương pháp quan sát hệ thống hoạt động là phương pháp trực tiếp thì phương pháp nghiên cứu tài liệu và tủ tục là phương pháp quan sát gián tiếp, bởi vì nó không nghiên cứu trực tiếp ở hiện trường hệ thống mà thông qua các văn bản, giấy tờ, tài liệu, tập tin máy tính, mô tả hệ thống. Phương pháp này giúp xác định chi tiết về hệ thống hiện hành. Có rất nhiều tài liệu liên mô tả hoạt động hệ thống, các yêu cầu của hệ thống trong tương lai: tài liệu mô tả nhiệm vụ, các kế hoạch kinh doanh, cấu trúc tổ chức, các tra cứu về chính sách, bản mô tả công việc, các thư tín bên trong và bên ngoài, các báo cáo nghiên cứu, Chúng ta có thể thu thập được nhiều loại thông tin từ các hoạt động chung của đơn vị đến các dữ liệu cơ bản, dữ liệu cấu trúc. Thông thường phương pháp này kết hợp với phương pháp phỏng vấn ở mức thấp. @ Đại Học KHTN-TP HCM ; ASIA-ITC 39
  40. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Tài liệu giao dịch: chứng từ, thư từ, thông báo, Tài liệu Tài liệu lưu: sổ sách, tập tin, báo cáo, hoàn chỉnh Tài liệu tổng hợp: báo cáo, thống kê, kế hoạch Tài liệu tổ chức, chính sách: cấu trúc tổ chức, mô tả công việc, qui trình, thủ tục, Tài liệu Tài liệu bổ sung: bảng hỏi, phiếu thu thập, Tài liệu Tài liệu nghiên cứu: báo cáo nghiên làm tiếp cứu, Tài liệu chuẩn bị: cuộc họp, máy tính, Phân tích tài liệu sẽ mang lại các thông tin sau: - Các vấn đề tồn tại trong hệ thống (thiếu thông tin, các bước xử lý dư thừa) - Các cơ hội để hệ thống đáp ứng nhu cầu mới (ví dụ: việc phân tích tài liệu cho thấy từ dữ liệu lưu trữ mà lâu nay không để ý có thể phân tích thông tin từng loại khách hàng , điều này tạo một cơ hội cho bộ phận bán hàng là có thể đánh giá và phân tích hoạt động bán hàng) - Phương hướng tổ chức có thể tác động đến các yêu cầu của HTTT (ví dụ: một phương hướng mới của đơn vị là liên kết khách hàng và nhà cung cấp gần gũi hơn nữa với đơn vị mà trước đây chưa tính đến hoặc chưa thực hiện. Phương hướng này làm nảy sinh các nhu cầu mới về HTTT cần có để đáp ứng như là: hệ thống mới cần mở ra các kênh liên lạc thông tin cho khách hàng, xử lý các đánh giá dịch vụ khách hàng, ) - Lý do tồn tại của hệ thống hiện hành, những chi tiết không được quản lý bởi hệ thống hiện hành và bây giờ thì cần thiết và khả thi trong hệ thống mới. - Tìm ra tên và vị trí của những cá nhân có liên quan đến hệ thống. Giúp cho việc giao tiếp liên lạc đúng mục tiêu hơn. - Giá trị của đơn vị, cá nhân có thể trợ giúp để xác định các ưu tiên đối với những khả năng khác nhau đến từ nhiều người dùng khác nhau. - Các trường hợp xử lý thông tin đặc biệt không thường xuyên không thể được xác định bởi những phương pháp khác. - Dữ liệu cấu trúc, qui tắc xử lý dữ liệu, các nguyên lý hoạt động được thực hiện bởi HTTT. Một loại tài liệu hữu dụng khác là các thủ tục mô tả công việc của từng cá nhân hoặc nhóm. Các thủ tục này mô tả cách thức một công việc hoạt động, gồm dữ liệu và thông tin được sử dụng và được tạo ra trong quá trình thực hiện công việc. Tuy nhiên, việc phân tích tài liệu thủ tục cũng có một số nhược điểm sau: - Các thủ tục cũng là nguồn thông tin không đúng, trùng lắp - Thiếu tài liệu - Tài liệu hết hạn: dẫn đến việc phân tích tài liệu cho một kết quả không đúng với kết quả khi phỏng vấn. @ Đại Học KHTN-TP HCM ; ASIA-ITC 40
  41. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Các phương pháp mới xác định yêu cầu Thiết kế kết hợp người dùng (JAD - Join Application Design) Mục tiêu của JAD là một tiến trình xác định yêu cầu trong đó người dùng, nhà quản lý và các nhà phân tích làm việc với nhau trong một vài ngày diễn ra trong các buổi họp tập trung (trong một phòng) để xác định hoặc kiểm tra lại các yêu cầu hệ thống và các thiết kế chi tiết. Do đó, JAD có hình thức như là phương pháp phỏng vấn nhóm. Tuy nhiên, JAD đi theo một cấu trúc vai trò và chương trình đặc biệt hoàn toàn khác với phương pháp phỏng vấn nhóm đó là phân tích viên điều khiển thứ tự câu hỏi được trả lời bởi người dùng. Mục đích chính của JAD trong giai đoạn phân tích là thu thập yêu cầu hệ thống một cách đồng thời từ nhiều đối tượng khác nhau, kết quả là một tiến trình tập trung, có cấu trúc nhưng có hiệu quả cao. Điểm giống nhau với phỏng vấn nhóm là JAD cũng cho phép các phân tích viên quan sát vá xác định được ở đâu đồng ý và ở đâu có bất đồng trong các người dùng. Các cuộc gặp gỡ diễn ra trong vòng nhiều ngày tạo ra cơ hội để giải quyết bất đồng hoặc ít nhất cũng hiểu được tại sao có bất đồng. Thành phần của JAD bao gồm: - Một địa điểm: một địa điểm (phòng họp) có đầy đủ các trang thiết bị hỗ trợ cho cuộc họp, mục đích là làm cho mọi người có tập trung cao trong việc phân tích hệ thống. - Người tham dự bao gồm: o Người chủ trì: điều hành cuộc họp, thiết lập chương trình, giữ thái độ trung lập, tập trung vào việc hướng cuộc họp vào đúng chương trình, giải quyết bất đồng. o Người dùng: đại diện người sử dụng hệ thống o Phân tích viên hệ thống: các phân tích viên đặt câu hỏi về hệ thống o Người ghi chép: ghi chép tất cả các tông tin quá trình diễn ra JAD o Nhân viên HTTT: ngoài các phân tích viên, bao gồm thêm các lập trình viên, phân tích viên CSDL. - Chương trình: chương trình thể hiện nội dung của JAD bao gồm các bước và cuộc họp phải diễn ra đúng chương trình này - Công cụ: các công cụ trợ giúp phân tích thiết kế (thiết kế bản mẫu, vẽ sơ đồ, ), đánh giá và trợ giúp cho các phân tích để nâng cao hiệu quả và giảm thiểu thời gian của JAD. Sử dụng bản mẫu (prototype) xác định yêu cầu Sử dụng bản mẫu như một kỹ thuật xác định yêu cầu, phân tích viên làm việc với người dùng để xác định các yêu cầu cơ bản và ban đầu của hệ thống. Sau đó, phân tích viên dựa trên yêu cầu này để xây dựng một bản mẫu ban đầu. Bản mẫu khi hoàn thành sẽ gởi đến người dùng để người dùng sử dụng thử và kiểm tra. Đặc biệt, việc trực quan hóa các mô tả yêu cầu bằng lời được chuyển đổi thành hệ thống vật lý sẽ nhắc nhở người dùng thay đổi những yêu cầu tồn tại không phù hợp và phát sinh những yêu cầu mới (ví dụ: trong buổi phỏng vấn ban đầu, người dùng muốn xây dựng một form nhập hóa đơn với tất cả thông tin về khách hàng, hoá đơn, dịch vụ, hàng hoá, quá trình thanh toán, theo cách nghĩ của người dùng là tiện lợi. Tuy nhiên sau khi sử dụng bản mẫu, người dùng sẽ cảm thấy phức tạp, lẫn lộn và sẽ thay đổi yêu cầu với nhiều form khác nhau và sự di chuyển hợp lý giữa các form). Kết quả thử nghiệm của người dùng sẽ phản hồi tới phân tích viên và phân tích viên sẽ dùng thông tin phản hồi này để cải tiến bản mẫu rồi tiếp tục gởi đến người dùng và vòng lặp này cứ tiếp tục như vậy cho đến khi bản mẫu thoả mãn người dùng. @ Đại Học KHTN-TP HCM ; ASIA-ITC 41
  42. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Khi sử dụng phương pháp này, phân tích viên cũng phải sử dụng các phương pháp truyền thống để thu thập thông tin ban đầu. Các yêu cầu ban đầu Xác định bài toán Xây dựng bản mẫu Bản mẫu Chuyển đổi tới hệ thống vật lý Các yêu cầu mới Nếu bản mẫu không đủ Vấn đề phát sinh Cài đặt và sử dụng Đánh giá và nâng bảnmẫu cấpbảnmẫu Phiên bản kế tiếp Hình 2. Sơ đồ xác định yêu cầu dùng phương pháp bản mẫu (The New paradigm for Systems Development – J.D. Naumann & A.M. Jenkins ) Phương pháp bản mẫu sẽ rất hữu dụng để xác định yêu cầu trong các trường hợp sau: - Yêu cầu chưa rõ ràng và thông suốt, thường là các trường hợp về hệ thống mới hoặc là các trường hợp về hệ hỗ trợ ra quyết định. - Người dùng và các thành viên khác tham gia vào việc phát triển hệ thống. - Việc thiết kế phức tạp và đòi hỏi phải có một hình thức cụ thể để đánh giá. - Có những vấn đề giao tiếp đã tồn tại giữa phân tích viên và người dùng và tất cả đều mong muốn làm sáng tỏ. - Công cụ (đặc biệt là công cụ phát sinh form và report) và dữ liệu sẵn sàng để xây dựng hệ thống. Phương pháp này cũng có một số hạn chế: - Tạo ra một xu hướng làm việc không theo chuẩn tài liệu hình thức về yêu cầu hệ thống, và điều này làm khó khăn hơn để phát triển một hệ thống đầy đủ cần phải có một chuẩn mực tuân theo. - Các bản mẫu có thể trở thành rất đặc thù phong cách của người dùng ban đầu và khó để thích ứng với những người dùng tiềm năng khác. - Các bản mẫu thường được xây dựng trên các hệ thống đơn. Do đó, nó bỏ qua các phát sinh về tương tác và chia sẻ dữ liệu với những hệ thống khác. Ví dụ: mô tả khảo sát hoạt động của hệ thống máy ATM ngân hàng ABC ATM là một loại máy rút tiền tự động, máy được các ngân hàng lắp đặt để hỗ trợ cho khách hàng có thể rút tiền ở các vị trí thuận tiện mà không phải đến ngân hàng. Hoạt động của máy được mô tả như sau: Hệ thống được thiết kế để điều khiển một máy giao dịch tự động (ATM – Automated Teller @ Đại Học KHTN-TP HCM ; ASIA-ITC 42
  43. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Machine) có một đầu đọc từ để đọc thẻ ATM, một màn hình giao tiếp (hiển thị và bàn phím), một khe nhỏ để chuyển tiền, một khay đựng tiền, một máy in để in hoá đơn và một công tắc cho phép nhân viên vận hành bật và tắt máy. Máy ATM sẽ giao tiếp với hệ thống ngân hàng thông qua một phương thức thích hợp. Máy ATM sẽ phục vụ cho một khách hàng tại một thời điểm. Khách hàng của ngân hàng sẽ được lưu trữ thông tin về tên, số thẻ và PIN code (gồm 4 ký số) dùng để nhận dạng khách hàng, khách hàng có thể gởi và rút tiền từ tài khoản của mình tại máy ATM. Một khách hàng phải có một tài khoản tại ngân hàng. Với tài khoản này, khách hàng có thể thực hiện các giao dịch được cung cấp bởi máy ATM của ngân hàng. Khi khách hàng đến máy ATM để sử dụng, khách hàng sẽ được yêu cầu đưa thẻ vào máy, hoặc nhập vào số thẻ và mã PIN kiểm tra. Sau khi kiểm tra thành công, khách hàng có thể thực hiện một số giao dịch trên máy như sau: - Rút tiền: khách hàng nhập vào số tiền cần rút. Nếu số tiền dư trong tài khoản tiền gởi nhỏ hơn số tiền rút, hệ thống tự động tạo thêm một giao dịch rút tiền từ tài khoản tiết kiệm. Nếu số dư trong tài khoản vẫn không đủ hệ thống sẽ thông báo cho khách hàng và kết thúc giao dịch. - Gửi tiền: khách hàng có thể thực hiện việc gởi tiền vào tài khoản tiền gởi hoặc tiết kiệm. - Xem thông tin tài khoản: khách hàng có thể chọn xem thông tin về tài khoản của mình sau khi đăng nhập vào hệ thống. Khách hàng cũng có thể huỷ bỏ thực hiện một dịch vụ bằng việc chọn “huỷ bỏ” hoặc “đóng” từ giao diện máy. Yêu cầu Yêu cầu là: “một điều kiện, hoặc khả năng mà hệ thống phải đáp ứng”. Yêu cầu có thể phân thành hai loại lớn là yêu cầu chức năng (functional requirement) và yêu cầu phi chức năng (nonfunctional requirement): Yêu cầu chức năng Khi mô tả về một hệ thống, chúng ta nghĩ ngay đến hệ thống sẽ có những gì để thực hiện trên quan diểm người sử dụng. Những việc thực hiện này được xem như là các hành động mà hệ thống phải thi hành và được mô tả như là chức năng, hành vi, và yêu cầu. Yêu cầu chức năng được dùng để diễn đạt hành vi của một hệ thống bằng việc xác định tất cả điều kiện đầu vào và đầu ra để đạt được một kết quả mong muốn. Việc biểu diễn yêu cầu chức năng thường thông qua các sơ đồ. Trong UML chúng ta có thể dùng sơ đồ use case, sơ đồ hoạt động, sơ đồ tương tác. Ví dụ, trong một sơ đồ use case. Mỗi use case dùng để biểu diễn một chức năng của hệ thống cần có để cung cấp tới một đối tượng tác nhân. Use case 1 Mỗi use case mô tả một chức năng mà hệ thống cần có để đáp ứng yêu cầu Use case 2 @ Đại Học KHTN-TP HCM ; ASIA-ITC 43
  44. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Yêu cầu phi chức năng Là các đặc điểm chất lượng của chức năng mà hệ thống cần đáp ứng nhằm thoả mãn nhu cầu người sử dụng. Các đặc điểm chất lượng này được gọi là các yêu cầu phi chức năng. Chúng ta phân loại yêu cầu phi chức năng như sau: - Sự tiện lợi (usability): là các yêu cầu về yêu tố thẩm mỹ con người, tính dễ học, dễ sử dụng và sự nhất quán của giao diện, tài liệu sử dụng và các tài nguyên huấn luyện. - Sự tin cậy (realibility): là các yêu cầu về tần suất và giới hạn về hỏng hóc, khả năng phục hồi, khả năng dự đoán và độ chính xác. - Hiệu năng (performance): là các điều kiện áp đặt lên các yêu cầu chức năng. Ví dụ: tỉ lệ giao tác thực hiện, tốc độ thực hiện, tính sẵn sàng, độ chính xác, thời gian đáp ứng, thời gian phục hồi, dung lượng bộ nhớ sử dụng cho một hoạt động thi hành bởi hệ thống. - Khả năng chịu đựng (supportability): là các yêu cầu về độ bền, khá năng duy trì, và các yêu cầu khác về chất lượng đòi hỏi hệ thống phải được cập nhật sau thời điểm triển khai. Phân loại yêu cầu Với cách tiếp cận truyền thống, các yêu cầu được xem như là các đặc tả văn bản tương ứng với một trong hai loại trên, được diễn đạt qua hình thức:” Hệ thống sẽ ”. Tuy nhiên, để quản lý đầy đủ yêu cầu một cách có hiệu quả, các yêu cầu phải được mô tả dựa trên sự hiểu biết của người dùng và các đối tượng có liên quan. Sự hiểu biết này cung cấp cho nhóm phát triển lý do “tại sao?” cũng như “cái gì?” của hệ thống sẽ được phát triển. Vì hệ thống sẽ liên quan đến nhiều loại đối tượng khác nhau do đó, yêu cầu của hệ thống cũng có thể được phân loại theo nhiều cấp khác nhau: Nhu cầu (need): Mô tả các yêu cầu ở mức cao thường là các đối tượng có liên quan đến dự án như là: người đầu tư, người hưởng lợi từ dự án, người dùng cuối, cũng như người mua, người thầu, người phát triển, người quản lý, hoặc những đối tượng khác mà nhu cầu của họ hệ thống phải đáp ứng. Thu thập các nhu cầu này chúng ta phải khảo sát thông qua các phương pháp khảo sát như đã đề cập bên trên. Các nhu cầu được thu thập thông thường mô tả ớ mức cao, không rõ ràng, nhọc nhằn và thường bắt đầu như là một “nhu cầu” hoặc “mong muốn”. Ví dụ các nhu cầu có thể là: “Tôi cần gia tăng khả năng sản xuất”, “Tôi có nhu cầu mở rộng khả năng đáp ứng đơn hàng”, “Tôi có nhu cầu cải tiến hiệu năng hoạt động của hệ thống” “Tối muốn mở rộng việc khai thác số liệu của khách hàng” Các nhu cầu này được xem như là một tập hợp rất quan trọng giúp chúng ta hiểu về các mong muốn thực sự của các đối tượng liên quan ở mức cao và nó sẽ cung cấp các đầu vào then chốt tới các yêu cầu chi tiết của hệ thống giúp chúng ta xác định các lý do và nội dung hành vi hệ thống. Đặc điểm hệ thống (feature) Trong quá trình khảo sát hệ thống, nhu cầu và yêu cầu thường đi đôi với nhau. Trong khi nhu cầu là những cái mong muốn mang lại từ hệ thống trên quan điểm còn không rõ ràng thì yêu cầu ngược lại được mô tả mang tính giải pháp cho những nhu cầu đó. @ Đại Học KHTN-TP HCM ; ASIA-ITC 44
  45. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Ví dụ: một nhu cầu “Tôi muốn thông báo đến nhà cung cấp nhanh hơn” thì một yêu cầu là “hệ thống sẽ phát sinh thông báo tự động qua email đến nhà cung cấp” Các yêu cầu này chính là các biểu thức ở mức cao về hành vi hệ thống – gọi là đặc điểm (feature). Xét về khía cạnh kỹ thuật, đặc điểm được xem như là “một dịch vụ được cung cấp bởi hệ thống để đáp ứng nhu cầu”. Như vậy, đặc điểm của hệ thống chính là sự chuyển đổi quan điểm về cái gì (“thông báo nhanh hơn”) thành như thế nào (“email tự động”). Để xác định một đặc điểm chúng ta có thể thêm vào một số thuộc tính khác như là: rũi ro, độ ưu tiên, độ nỗ lực Yêu cầu phần mềm Để thích hợp hơn trong quá trình trao đổi với người phát triển về chính xác những gì mà hệ thống sẽ làm. Chúng ta cần một đưa vào thêm một mức đặc tả để chuyển dịch những nhu cầu và đặc điểm thành một đặc tả mà chúng ta có thể thiết kế, cài đặt, thử nghiệm. Các đặc tả này gọi là yêu cầu phần mềm và có thể tiếp cận theo hai loại: yêu cầu chức năng và yêu cầu phi chức năng. Nhu cầu Đặc điểm Yêu cầu phần mềm Yêu cầu về thiết kế/ thử nghiệm/ tài liệu Câu hỏi và bài tập Câu hỏi 1. Mục đích của khảo sát yêu cầu là gì? 2. Cần tiếp cận những đối tượng nào trong quá trình khảo sát? 3. Cần tu thập các nội dung gì trong quá trình khảo sát? 4. Các phương pháp khảo sát yêu cầu? 5. Ưu và khuyết điểm của phương pháp phỏng vấn? 6. Ưu và khuyết điểm của phượng pháp dùng bảng câu hỏi? 7. Yêu cầu là gì? Như thế nào là yêu cầu chức năng, phi chức năng? 8. Yêu cầu được phân thành bao nhiêu loại? Ý nghĩa của từng loại? @ Đại Học KHTN-TP HCM ; ASIA-ITC 45
  46. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Chương 5 MÔ HÌNH HOÁ USE CASE Mục tiêu Nội dung của chương này cung cấp cho sinh viên: - Hiểu ý nghĩa của việc sử dụng sơ đồ use case trong biểu diễn yêu cầu hệ thống - Xác định được các tác nhân và mối quan hệ giữa các tác nhân của một hệ thống phần mềm - Xác định được các use case biểu diễn chức năng phần mềm hệ thống và mối quan hệ giữa tác nhân cà use case nhằm xây dựng sơ đồ use case mô tả yêu cầu phần mềm hệ thống - Tinh chế sơ đồ use case nhằm làm gia tăng tính diễn đạt, tính tái sử dụng qua việc sử dụng các liên kết >, > Giới thiệu Trong giai đoạn phân tích, kết quả của quá trình khảo sát yêu cầu phản ánh quá trình làm việc của người phát triển với người sử dụng. Các kết quả này phải nhắm đến yếu tố của người dùng. Có nghĩa là người phát triển trước tiên phải diễn đạt bức tranh của hệ thống tương lai theo cách nhìn của người sử dụng. Điều này sẽ giúp cho người dùng có thể thấy được hệ thống sẽ làm thoã mãn các yêu cầu như thế nào và đó chính là chìa khoá đầu vào cho việc phát triển hệ thống trong các giai đoạn về sau. Một công cụ giúp diễn đạt điều này chính là mô hình use case. Jacobson và cộng sự của ông (1992) là những người tiên phong trong việc sử dụng mô hình use case để phân tích yêu cầu hệ thống. Bởi vì mô hình use case đặt trọng tâm để biểu diễn hệ thống hiện tại làm gì, hệ thống mới sẽ làm gì và môi trường của nó. Nó giúp cho người phát triển có thể hiểu rõ về yêu cầu chức năng hệ thống mà không quan tâm đến chức năng này được cài đặt như thế nào. Để hiểu yêu cầu của hệ thống, chúng ta phải tìm ra người dùng sẽ sử dụng hệ thống như thế nào. Do đó, từ quan điểm một người dùng, chúng ta phát hiện các tình huống sử dụng khác nhau của người dùng, các tình huống này được thiết lập bởi các use case. Tổng hợp các use case và tác nhân cùng với quan hệ giữa chúng sẽ cho ta một mô hình use case mô tả yêu cầu của hệ thống. Trong chương 6, quá trình mô hình hoá nghiệp vụ được áp dụng đối với các hệ thống nghiệp vụ và kết quả của nó sẽ cung cấp sơ đồ use case từ việc thống nhất các yêu cầu hệ thống phần mềm để tự động hoá hoạt động của hệ thống nghiệp vụ đó. Tuy nhiên, trong những hệ thống mà không có hoạt động nghiệp vụ (ví dụ: hệ thống nhúng), hoặc các nghiệp vụ của hệ thống không quá phức tạp hoặc không quan tâm để mô hình hoá nghiệp vụ thì việc xây dựng mô hình use case phần mềm sẽ là bước tiếp cận mô hình hoá đầu tiên về hệ thống. Một tiến trình xây dựng sơ đồ use case bao gồm các bước sau: - Xác định tác nhân hệ thống o Ai đang sử dụng hệ thống? o Hoặc trong trường hợp phát triển mới thì ai sẽ sử dụng hệ thống? - Phát triển use case o Người dùng (tác nhân) đang làm gì với hệ thống? o Hoặc trong trường hợp hệ thống mới thì người dùng sẽ làm gì với hệ thống? - Xây dựng sơ đồ use case @ Đại Học KHTN-TP HCM ; ASIA-ITC 46
  47. Phân tích thiết kế hệ thống hướng đối tượng bằng UML o Xác định mối quan hệ giữa tác nhân – use case o Xác định mối quan hệ giữa các use case - Phân chia sơ đồ use case thành các gói (package) Xác định tác nhân Tác nhân (actor) Ý nghĩa: một tác nhân là một đối tượng bên ngoài hệ thống giao tiếp với hệ thống theo một trong những hình thức sau: - Tương tác, trao đổi thông tin với hệ thống hoặc sử dụng chức năng hệ thống - Cung cấp đầu vào hoặc nhận các đầu ra từ hệ thống - Không điều khiển hoạt động của hệ thống Ký hiệu > Tên tác nhân Tên tác nhân: tên tác nhân là một danh từ Quan hệ giữa các tác nhân: Là quan hệ tổng quát hóa và chuyên biết hoá Ví dụ: Khách hàng Nhân viên Khách quen Nhân viên bán hàng Thủ kho Xác định tác nhân Xác định tác nhân cũng được xem có tầm quan trọng như xác định class, use case, liên kết, . Khi xác định người sử dụng phần mềm hệ thống, chúng ta đừng quan trọng vấn đề quan sát người nào đang sử dụng hệ thống mà chúng ta nên xác định xem vai trò chịu trách nhiệm trong việc sử dụng hệ thống. Nghĩa là tác động lên hệ thống theo nghĩa cung cấp thông tin cho hệ thống hoặc nhận kết quả xử lý từ hệ thống. Tác nhân được hiểu là một vai trò tham gia vào hệ thống không giống như một con người cụ thể hoặc một công việc. Một đối tượng có thể tham gia vào một hoặc nhiều vai trò @ Đại Học KHTN-TP HCM ; ASIA-ITC 47
  48. Phân tích thiết kế hệ thống hướng đối tượng bằng UML Người dùng Tác nhân Use case Nguyễn Văn A Khách hàng Bán hàng Nguyễn Thị B NV bán hàng Trần Văn C Thủ kho Đặt mua NGK Qua quá trình khảo sát và phân tích tài liệu hệ thống, chúng ta có thể nhận ra các tác nhân thông qua các câu hỏi sau: - Ai đang sử dụng hệ thống? Hoặc ai được tác động bởi hệ thống? Hoặc nhóm đối tượng nào cần hệ thống trợ giúp để làm công việc? (tác nhân chính) - Ai tác động tới hệ thống? Những nhóm đối tượng nào hệ thống cần để thực hiện hoạt động của nó (hoạt động gồm chức năng chính và chức năng phụ, như là chức năng quản trị)? - Những phần cứng hoặc hệ thống bên ngoài nào sử dụng hệ thống? Ví dụ: trong hoạt động của máy ATM của một ngân hàng, các tác nhân được xác định là: Khách hàng Nhân viên ngân Nhân viên vận hành hàng Trong đó, các tác nhân Khách hàng, Nhân viên ngân hàng là các tác nhân chính (primary actor) của hệ thống ATM. Bởi vì khách hàng là mục tiêu mà hệ thống tượng tác; Nhân viên ngân hàng sử dụng hệ thống để trợ giúp công việc. Trong khi đó, Nhân viên vận hành là tác nhân phụ (secondary actor) bởi vì tác nhân này đảm nhận những chức năng phụ mà hệ thống cần có để thực hiện hoạt động của nó. Hoặc trong một thư viện của trường đại học, các tác nhân của hệ thống phần mềm quản lý thư viên gồm: Độc giả Thủ thư Nhà cung cấp Xác định use case Use case Một Use case được xem như một chức năng hệ thống từ quan điểm người dùng, như vậy tập hợp tất cả use case biểu diễn bộ mặt của hệ thống bao gồm các chức năng cần có để cung cấp cho các đối tượng tương tác làm việc với hệ thống. Như vậy, use case dùng để mô tả yêu cầu @ Đại Học KHTN-TP HCM ; ASIA-ITC 48
  49. Phân tích thiết kế hệ thống hướng đối tượng bằng UML của hệ thống mới về mặt chức năng, mỗi chức năng sẽ được biểu diễn như một hoặc nhiều use case. Ví dụ: hệ thống cửa hàng NGK ta có một vài use case Bán hàng, quản trị tồn kho, Ký hiệu Tên use Bán hàng Quản trị case kho Xác định use case Chúng ta bắt đầu từ tập các tác nhân đã xác định trong bước đầu tiên. Ứng với mỗi tác nhân: - Tìm các nhiệm vụ và chức năng mà tác nhân sẽ thi hành hoặc hệ thống cần tác nhân để thi hành và mô hình hoá nó như là use case. Use case sẽ đại diện một dòng sự kiện dẫn tới một mục tiêu rõ ràng (hoặc trong một vài trường hợp, dẫn tới một vài mục tiêu riêng biệt có thể là các phương án thay thế cho tác nhân hoặc cho hệ thống so với dòng sự kiện chính) - Đặt tên cho use case: tên use case nên đặt nhằm phản ánh một mô tả tổng quan về chức năng của use case. Tên nên dễn đạt những gì xảy ra khi một thể hiện của use case được thi hành. Một hình thức đặt tên use case phổ biến là : động từ (do) + danh từ (what). - Mô tả use case một cách ngắn gọn bằng việc áp dụng các thuật ngữ gần gũi với người sử dụng. Điều này sẽ làm cho mô tả use case ít mơ hồ. Ví dụ: trong hệ thống ATM Tác nhân Khách hàng sẽ sử dụng hệ thống qua các chức năng: - Gửi tiền - Rút tiền - Truy vấn thông tin về tài khoản Tác nhân Nhân viên vận hành sẽ sử dụng các chức năng - Khởi động hệ thống - Đóng hệ thống Gửi tiền Rút tiền Truy vấn thông tin tài khoản Khởi động hệ Đóng hệ thống thống Gửi tiền: khách hàng đăng nhập vào hệ thống và yêu cầu gửi tiền vào tài khoản. Khách hàng sẽ xác định tài khoản và số tiền gửi, hệ thống sẽ tạo một giao tác gửi tiền và lưu vào hệ thống. Các bước như sau: - Yêu cầu xác định tài khoản - Hệ thống hỏi số tiền gửi @ Đại Học KHTN-TP HCM ; ASIA-ITC 49