Giáo trình Phân tích và thiết kế hệ thống thông tin - Trình độ: Cao đẳng - Trường Cao đẳng nghề kỹ thuật công nghệ

Nội dung text: Giáo trình Phân tích và thiết kế hệ thống thông tin - Trình độ: Cao đẳng - Trường Cao đẳng nghề kỹ thuật công nghệ

1. BỘ LAO ĐỘNG - THƯƠNG BINH VÀ XÃ HỘI TRƯỜNG CAO ĐẲNG NGHỀ KỸ THUẬT CÔNG NGHỆ š› & š› GIÁO TRÌNH MÔN HỌC: PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG THÔNG TIN NGHỀ: LẬP TRÌNH VIÊN MÁY TÍNH TRÌNH ĐỘ: CAO ĐẲNG Ban hành kèm theo Quyết định số: 13A/QĐ-CĐNKTCN ngày 10 tháng 01 năm 2019 của Hiệu trưởng Trường Cao đẳng nghề Kỹ thuật Công nghệ Hà Nội, năm 2021 (Lưu hành nội bộ) 1
2. TUYÊN BỐ BẢN QUYỀN: Tài liệu này thuộc loại sách giáo trình nên các nguồn thông tin có thể được phép dùng nguyên bản hoặc trích dùng cho các mục đích về đào tạo và tham khảo. Mọi mục đích khác mang tính lệch lạc hoặc sử dụng với mục đích kinh doanh thiếu lành mạnh sẽ bị nghiêm cấm. MÃ TÀI LIỆU: MHLTV 19 2
3. LỜI GIỚI THIỆU Tổ chức xây dựng, quản lý vận hành hệ thống thông tin (HTTT) là một trong những ứng dụng quan trọng của ngành công nghệ thông tin (CNTT) và đến nay đã có nhiều HTTT được xây dựng và ứng dụng trong thực tiễn. Mặc dù hiện nay có khá nhiều ngôn ngữ lập trình và hệ quản trị cơ sở dữ liệu cũng như các phần mềm chuyên dụng áp dụng trong công tác quản lý, tuy nhiên đối với một hệ thống thông tin việc vận dụng ngay các phần mềm đó là một vấn đề gặp không ít khó khăn. Các hệ thống thông tin chưa đáp ứng được yêu cầu của các nhà quản lý có nhiều nguyên nhân song nguyên nhân quan trọng đó là các nhà xây dựng hệ thống thông tin không được trang bị kiến thức cơ bản về phân tích và thiết kế, thiếu kinh nghiệm tham gia vào quá trình phân tích thiết kế dẫn đến giai đoạn cài đặt phải thay đổi nhiều, gây ra sự lãng phí trong việc xây dựng khai thác, bảo trì và phát triển hệ thống. Phân tích thiết kế hệ thống thông tin là phương pháp luận để xây dựng và phát triển hệ thống thông tin bao gồm các lý thuyết, mô hình, phương pháp và các công cụ sử dụng trong quá trình phân tích và thiết kế hệ thống. Mặc dầu có rất nhiều cố gắng, nhưng không tránh khỏi những thiếu sót, nhóm tác giả rất mong nhận được sự đóng góp ý kiến của độc giả để giáo trình được hoàn thiện hơn. Xin chân thành cảm ơn! Hà Nội, ngày 23 tháng 04 năm 2021 Tham gia biên soạn 1. Chủ biên Trần Thị Vinh 2. Tập thể Giảng viên Khoa CNTT Mọi thông tin đóng góp chia sẻ xin gửi về hòm thư tranthivinhvnn@gmail.com, hoặc liên hệ số điện thoại 0978113529 3
4. MỤC LỤC LỜI GIỚI THIỆU 3 CHƯƠNG 1: HỆ THỐNG THÔNG TIN 8 1.1. Hệ thống thông tin 8 1.2. Các cách tiếp cận phân tích hệ thống thông tin 8 1.2.1.Phương pháp hướng cấu trúc 8 1.2.2. Phương pháp hướng đối tượng 9 1.3.Các khái niệm cơ bản về hướng đối tượng 10 1.3.1. Đối tượng và trừu tượng hóa 10 1.3.2. Lớp và thể hiện 12 1.3.3. Sự trao đổi và thông điệp 12 1.3.4. Sự phân cấp 12 1.3.5. Tính bao bọc 13 1.3.6. Tính đa hình 13 1.4. Chu trình phát triển phần mềm và tiến trình RUP 13 1.4.1. Chu trình phát triển phần mềm 13 1.4.2. Các giai đoạn của chu trình phát triển phần mềm 13 1.4.3. Tiến trình phát triển phần mềm RUP 14 1.5. Các bước phân tích thiết kế hướng đối tượng 15 2.1. Giới thiệu UML 17 2.1.1. Lịch sử về UML 17 2.1.2. UML – ngôn ngữ mô hình hóa hướng đối tượng 17 2.2 Các khái niệm cơ bản trong UML 17 2.3. Các biểu đồ UML 18 2.3.1. Biểu đồ Use case 18 2.3.2.Biểu đồ lớp 19 2.3.4.Biểu đồ đối tượng 23 2.3.5.Biểu đồ trạng thái 23 2.3.6.Biểu đồ trình tự 25 2.3.7.Biểu đồ cộng tác 26 2.3.8.Biểu đồ hoạt động 27 2.3.9.Biểu đồ thành phần 30 2.3.10.Biểu đồ triển khai 30 2.4. Giới thiệu công cụ Rational Rose 31 CHƯƠNG 3: PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG 33 3.1. Phân tích yêu cầu hệ thống 33 3.1.1. Yêu cầu là gì? 33 3.1.2. Xác định yêu cầu hệ thống 33 3.1.3. Phân loại yêu cầu 34 1.4. Mô hình hoá nghiệp vụ 34 3.2. Mô hình hóa Use case 38 3.2.1. Giới thiệu về use case 38 3.2.2. Sơ đồ use case 39 3.2.3. Xác định các biến thể của use case 39 4
5. 2.2.4. Thiết lập các mối quan hệ giữa các use case 39 3.2.5. Đặc tả actor và use case 39 3.3. Xây dựng đối tượng hệ thống 40 3.3.1. Các khái niệm cơ bản về sơ đồ lớp 40 3.3.2. Xác định lớp đối tượng 40 3.3.3. Mô hình hóa liên kết giữa các lớp 41 3.3.4. Xác định thuộc tính, method của các lớp 41 3.3.5. Xây dựng mô hình khái niệm 41 3.3.6. Xây dựng biểu đồ tương tác 42 3.3.7. Xây dựng biểu đồ trạng thái 42 3.3.8. Xây dựng biểu đồ hoạt động 42 CHƯƠNG 4: THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 46 4.1.Thiết kế các hệ thống con 46 4.1.1. Hệ thống con 46 4.1.2. Phân chia hệ thống thành các hệ thống con 46 4.1.3. Kiến trúc phân tầng 46 4.2. Thiết kế giao diện người dùng và thiết kế lớp 47 4.2.1. Thiết kế giao diện người dùng 47 4.2.2. Thiết kế lớp 48 4.3. Thiết kế việc lưu trữ các dữ liệu 50 4.4. Mô hình hóa cài đặt hệ thống 53 4.4.1. Giới thiệu 53 4.4.2. Xây dựng biểu đồ thành phần 53 4.4.3. Xây dựng biểu đồ triển khai 57 TÀI LIỆU THAM KHẢO 61 5
6. GIÁO TRÌNH MÔN HỌC Tên môn học: Phân tích và thiết kế hệ thống thông tin Mã môn học: MHLTV 19 Vị trí, tính chất, ý nghĩa và vai trò của môn học: - Vị trí: Môn học được bố trí sau khi sinh viên học xong các môn học chung và môn kiến thức kỹ thuật cơ sở, thuộc về khối kiến thức chuyên môn nghề và trước các môn học, mô đun đào tạo nghề chuyên sâu khác; - Tính chất: Là môn học chuyên ngành. - Ý nghĩa và vai trò của môn học: Đây là mô đun tự chọn trong chuyên môn nghề, cung cấp cho sinh viên các kỹ năng cơ bản nhất về phân tích và thiết kế hệ thống thông tin, xây dựng các hệ thống thông tin cơ bản để phục vụ trong thực tiễn. Mục tiêu của môn học: - Về kiến thức + Nhắc lại được các khái niệm: dữ liệu, thông tin, hệ thống, hệ thống thông tin. + Phân tích thiết kế hệ thống thông tin theo hướng đối tượng bằng UML và sử dụng thành thạo một công cụ làm tài liệu như Rational Rose; +Trình bày được những kiến thức cơ bản về phân tích và thiết kế hệ thống thông tin hướng đối tượng bằng UML(Unifield Modeling Language), có kỹ năng sử dụng công cụ Rational Rose cho việc phát triển các phần mềm hướng đối tượng - Về Kỹ năng + Áp dụng các phương pháp phân tích và thiết kế hệ thống thông tin vào việc xây dựng ứng dụng thực tế; + Xây dựng được một bản phân tích thiết kế hoàn chỉnh cho các hệ thống vừa và nhỏ - Về năng lực tự chủ và trách nhiệm + Bố trí làm việc khoa học đảm bảo an toàn cho người và phương tiện học tập. + Đảm bảo được tính chính xác trong sử dụng các kí pháp Nội dung của môn học: Thời gian Kiểm Số tra* Tên các bài trong mô đun Tổng Lý Thực TT (LT số thuyết hành hoặcT H) 1 Chương 1: Tổng quan 6 3 3 1.1.Hệ thống thông tin 0.5 1.2. Các cách tiếp cận phân tích hệ thống 0.5 thông tin 1.3. Các khái niệm cơ bản về hướng đối 0.5 tượng 1.4. Chu trình phát triển phần mềm 0.5 1 1.5. Các bước phân tích thiết kế hệ thống 1 2 2 Chương 2: UML và công cụ phát triển hệ 15 9 6 thống 2.1. Giới thiệu về UML (Unified Modeling 2 Language) 6
7. 2.2. Các khái niệm cơ bản trong UML 3 1 2.3. Các biểu đồ UML 3 3 2.4. Giới thiệu công cụ Rational Rose 1 2 3 Chương 3: Phân tích hướng đối tượng 18 6 12 3.1. Phân tích yêu cầu hệ thống 2 4 3.2. Mô hình hóa Use case 2 4 3.3.Xây dựng đối tượng hệ thống 2 4 4 Chương 4: Thiết kế hướng đối tượng 15 6 9 4.1. Thiết kế các hệ thống con 1 2 4.2. Thiết kế giao diện người dùng và thiết kế 2 3 lớp 4.3. Thiết kế việc lưu trữ các dữ liệu 2 2 4.4. Mô hình hóa cài đặt hệ thống 1 2 5 Kiểm tra 1 1 6 Thi hết môn 2 2 Cộng 60 27 30 3 * Ghi chú: Thời gian kiểm tra lý thuyết được tính vào giờ lý thuyết, kiểm tra thực hành được tính bằng giờ thực hành. 7
8. CHƯƠNG 1: HỆ THỐNG THÔNG TIN Mã chương: MHLTV 19.01 Giới thiệu: Chương này sẽ trình bày các khái niệm cơ bản về thông tin và hệ thống thông tin (HTTT). Tiếp sau các khái niệm khởi đầu, chương này trình bày các đặc trưng cơ bản của HTTT, khái niệm về hệ thống xử lý tác nghiệp, hệ thống thông tin quản lý và hệ hỗ trợ ra quyết định. Trình bày khái niệm về HTTT tổng thể trong tổ chức hoạt động và các phương pháp cơ bản xây dựng HTTT. Mục tiêu: -Hiểu được ý nghĩa, vai trò của thông tin trong thực tiễn; -Nhận thức cơ bản về hệ thống thông tin nhằm định hướng cho quá trình phân tích và thiết kế hệ thống thông tin; -Thực hiện các thao tác an toàn với máy tính. Nội dung: 1.1. Hệ thống thông tin Mục tiêu: - Làm cho sinh viên nhận biết được các yếu tố của một hệ thống: phần tử, mục đích, môi trường; - Nhận thức cơ bản về hệ thống thông tin, nhằm định hướng cho quá trình phân tích và thiết kế hệ thống thông tin; - Trình bày được các đặc trưng của HTTT; - Hiểu và trình bày được các HTTT được phân loại theo chức năng. Nêu ra được các giai đoạn phát triển hệ thống. Hệ thống: Là một tập hợp có tổ chức của nhiều phần tử thường xuyên tương tác với nhau, có những mối quan hệ ràng buộc lẫn nhau và cùng hoạt động chung cho một mục đích nào đó. Môi trường là phần nằm ngoài hệ thống đang xét và thực chất nó là một hệ thống nào đó có giao tiếp với hệ thống đang xét. Giữa hệ thống và môi trường là đường giới hạn xác định phạm vi của hệ thống. Môi trường Phần tử Hình 1.1 Mô hình tổng quát của một hệ thống Ví dụ: Hệ mặt trời, hệ thống triết học, hệ thống thủy lực, hệ thống pháp luật, hệ thống cơ khí v.v 1.2. Các cách tiếp cận phân tích hệ thống thông tin 1.2.1.Phương pháp hướng cấu trúc 8
9. Phương pháp phân tích và thiết kế hướng cấu trúc bao gồm các hoạt động : khảo sát, phân tích, thiết kế, xây dựng, kiểm thử và cài đặt, vận hành. Đặc trưng của phương pháp này là các hoạt động có thể thực hiện một cách song song. Mỗi hoạt động có thể cung cấp những sửa đổi phù hợp cho một hoặc nhiều hệ thống trước đó. Ba công cụ quan trọng để mô hình hóa hệ thống theo phương pháp phân tích và thiết kế hướng cấu trúc là : - Mô hình chức năng - Mô hình dữ liệu - Mô hình luồng dữ liệu Trong đó mỗi mô hình thể hiện một cách nhìn ở góc độ khác nhau vào hệ thống. Mô hình chức năng : Mô hình mô tả các chức năng chính của hệ thống thông tin, thông thường được biểu diễn bằng sơ đồ chức năng nghiệp vụ, thể hiện hệ thống từ khía cạnh chức năng, trả lời cho câu hỏi : Hệ thống thực hiện những công việc gì ? Mô hình được sử dụng cho mục đích này là sơ đồ phân rã chức năng BFD (Business Functional Diagram). Nội dung chính của BFD là sơ đồ phân cấp chức năng của hệ thống. Mô hình dữ liệu : Mô tả các dữ liệu chính sẽ có trong hệ thống và mối quan hệ ràng buộc giữa chúng, thông thường được mô tả bằng sơ đồ quan hệ thực thể, các bảng thuộc tính các ràng buộc dữ liệu v.v , thể hiện hệ thống từ khía cạnh dữ liệu hay trả lời cho câu hỏi : Hệ thống sử dụng dữ liệu gì để phục vụ cho hoạt động của mình ? Mô hình dữ liệu ERD (Entity Relationship Diagram) là một trong các công cụ phản ánh hệ thống từ một khía cạnh khác, bổ sung với BFD để tạo nên một tổ hợp trọn vẹn của quá trình phân tích. Mô hình luồng dữ liệu : Mô tả luồng dữ liệu trong hệ thống. Có thể biểu diễn bằng nhiều sơ đồ: sơ đồ ngữ cảnh, sơ đồ phân rã các xử lý, sơ đồ dòng dữ liệu mức đỉnh và sơ đồ dòng dữ liệu các mức dưới đỉnh. Một trong các mô hình kinh điển được sử dụng cho mục đích mô tả luồng dữ liệu là sơ đồ dòng dữ liệu DFD (Data Flow Dragram). DFD thể hiện một mô hình hệ thống với quan niệm bình đẳng cho cả dữ liệu và chức năng, là một trong những công cụ quan trọng nhất của phân tích hệ thống hướng cấu trúc. Sơ đồ chỉ cách thông tin chuyển vận từ chức năng này hoặc từ quá trình này sang chức năng hoặc quá trình khác. Một điều khá quan trọng là sơ đồ chỉ ra được những thông tin nào cần phải có trước khi thực hiện một chức năng hay một quá trình. 1.2.2. Phương pháp hướng đối tượng Trong những năm gần đây phương thức lập trình hướng đối tượng đã thống lĩnh thị trường lập trình phần mềm và UML cũng đã trở thành ngôn ngữ mô hình hóa phổ biến trong sản xuất phần mềm. Hầu hết các trường đại học, cao đẳng đã đưa hai môn này vào đào tạo chính khóa và cũng có không ít tài liệu viết về những vấn đề này. Tuy nhiên, nó vẫn còn rất khó hiểu và khó áp dụng với sinh viên, và những bạn trẻ đang làm về Công nghệ thông tin. Trong loạt bài này, chúng tôi sẽ cố gắng trình bày một cách đơn giản và dễ hiểu nhất các kiến thức về Phân tích và thiết kế hướng đối tượng và UML để giúp các bạn hiểu và áp dụng vào thực tế. Các bài viết sẽ hướng dẫn các bạn phân tích và thiết kế một ứng dụng cụ thể để từ đó tự rút ra bài học kinh nghiệm cho mình và tiếp tục nghiên cứu sâu hơn. 9
10. Bài đầu tiên sẽ bàn một cách cơ bản về Phân tích thiết kế hướng đối tượng và UML. Lưu ý: Để hiểu được loạt bài này bạn phải có kiến thức cơ bản về lập trình hướng đối tượng, vì chúng tôi sẽ không đi chi tiết vào các định nghĩa về lập trình hướng đối tượng. Khái niệm về Phân tích và thiết kế hướng đối tượng (Object Oriented Analysis and Design: OOAD) Trong kỹ nghệ phần mềm để sản xuất được một sản phẩm phần mềm người ta chia quá trình phát triển sản phẩm ra nhiều giai đoạn như thu thập và phân tích yêu cầu, phân tích và thiết kế hệ thống, phát triển (coding), kiểm thử, triển khai và bảo trì. Trong đó, giai đoạn phân tích, thiết kế bao giờ cũng là giai đoạn khó khăn và phức tạp nhất. Giai đoạn này giúp chúng ta hiểu rõ yêu cầu đặt ra, xác định giải pháp, mô tả chi tiết giải pháp. Nó trả lời 2 câu hỏi What (phần mềm này làm cái gì?) và How (làm nó như thế nào?). Để phân tích và thiết kế một phần mềm thì có nhiều cách làm, một trong những cách làm đó là xem hệ thống gồm những đối tượng sống trong đó và tương tác với nhau. Việc mô tả được tất cả các đối tượng và sự tương tác của chúng sẽ giúp chúng ta hiểu rõ hệ thống và cài đặt được nó. Phương thức này gọi là Phân tích thiết kế hướng đối tượng (OOAD) Khái niệm về UML (Unified Modeling Language) UML là ngôn ngữ mô hình hóa hợp nhất dùng để biểu diễn hệ thống. Nói một cách đơn giản là nó dùng để tạo ra các bản vẽ nhằm mô tả thiết kế hệ thống. Các bản vẽ này được sử dụng để các nhóm thiết kế trao đổi với nhau cũng như dùng để thi công hệ thống (phát triển), thuyết phục khách hàng, các nhà đầu tư v.v (Giống như trong xây dựng người ta dùng các bản vẽ thiết kế để hướng dẫn và kiểm soát thi công, bán hàng căn hộ v.v ) Tại sao lại là OOAD và UML? OOAD cần các bản vẽ để mô tả hệ thống được thiết kế, còn UML là ngôn ngữ mô tả các bản vẽ nên cần nội dung thể hiện. Do vậy, chúng ta phân tích và thiết kế theo hướng đối tượng và sử dụng UML để biểu diễn các thiết kế đó nên chúng thường đi đôi với nhau. OOAD sử dụng UML UML sử dụng để vẽ cho nhiều lĩnh vực khác nhau như phần mềm, cơ khí, xây dựng v trong phạm vi các bài viết này chúng ta chỉ nghiên cứu cách sử dụng UML cho phân tích và thiết kế hướng đối tượng trong ngành phần mềm. OOAD sử dụng UML bao gồm các thành phần sau: – View (góc nhìn) – Diagram (bản vẽ) – Notations (ký hiệu) – Mechanisms (qui tắc, cơ chế) Chúng ta sẽ tìm hiểu kỹ hơn các thành phần trên. View (góc nhìn) Mỗi góc nhìn như thầy bói xem voi, nó không thể hiện hết hệ thống nhưng thể hiện rõ hệ thống ở một khía cạnh. Chính vì thế trong xây dựng có bản vẽ kiến trúc (nhìn về mặt kiến trúc), bản vẽ kết cấu (nhìn về mặt kết cấu), bản vẽ thi công (nhìn về mặt thi công). Trong phần mềm cũng như vậy, OOAD sử dụng UML có các góc nhìn sau: 1.3.Các khái niệm cơ bản về hướng đối tượng 1.3.1. Đối tượng và trừu tượng hóa 10
11. Mô hình hóa hướng đối tượng (Object-Oriented Modeling – OOM): Phương pháp dùng để mô hình hóa các chương trình máy tính theo phương pháp hướng đối tượng (OO Programming – OOP). Phân tích thiết kế hướng đối tượng (OO analysis and design – OOAD): là một kỹ thuật phần mềm tiếp cần việc mô hình hóa các vấn đề thực tế thành các hệ thống phần mềm như các đối tượng tương tác lẫn nhau 11
12. 1.3.2. Lớp và thể hiện Lớp đối tượng (Class) là một khung chứa các cấu trúc và hành vi chung của một đối tượng. 1.3.3. Sự trao đổi và thông điệp Sự trừu tượng hóa (Abstraction) là việc xây dựng mô hình chỉ bao gồm các đặc điểm quan trọng, cần thiết và phân biệt với các đặc điểm của mô hình khác. Cũng có khái niệm nói về sự trừu tượng hóa là cách cơ chế biểu diễn thực tế phức tạp bằng mô hình đơn giản 1.3.4. Sự phân cấp Sự phân cấp (Hierachy) có thể coi như sắp xếp thứ tự hoặc phân hạng sự trừ tượng hóa của các đối tượng theo một cấu trúc cây. Trong đó: ▪ Phân cấp toàn thể - bộ phận ▪ 12
13. Phân cấp các đối tượng chứa nhau ▪ Phân cấp lớp ▪ Phân cấp sự kế thừa ▪ Phân cấp theo kiểu đối tượng 1.3.5. Tính bao bọc Tính đóng gói (Encapsulation) là quy tụ các tính chất (thuộc tính, hành vi) vào trong hộp đen của sự trừu tượng hóa – cho phép ẩn đi cài đặt ở phía sau các giao diện 1.3.6. Tính đa hình Đa hình (Polymorphos - Nhiều hình thái khác nhau) ▪ Mọi sự thực thi của giao diện phải bao gồm ít nhất một giao diện. Trong có có các thực thi có thể áp dụng cho nhiều hình thức giao diện 1.4. Chu trình phát triển phần mềm và tiến trình RUP 1.4.1. Chu trình phát triển phần mềm RUP – Rational Unified Process – Quy trình hợp nhất Quy trình nghiệp vụ cho kỹ thuật phần mềm hướng đối tượng, dùng mô tả một họ các tiến trình kỹ thuật phần mềm cùng chia sẻ cấu trúc và kiến trúc tiến trình chung. Có 4 pha (phases): • Khởi tạo • Chi tiết • Xây dựng • Chuyển giao 1.4.2. Các giai đoạn của chu trình phát triển phần mềm Quy trình phát triên c ủa một ph ần mềm có thể được chia thành các giai đoạn như sau: Nghiên cứu sơ bộ (Preliminary Investigation hay còn gọi là Feasibility Study) 13
14. Phân tích yêu cầu (Analysis) Thiết kế hệ thống (Design of the System) Xây dựng phần mềm (Software Construction) Thử nghi ệm hệ thống (System Testing) Thực hiện, triển khai (System Implementation) Bảo trì, nâng cấp (System Maintenance) 1.4.3. Tiến trình phát triển phần mềm RUP Tiến trình thống nhất (Rational Unified Process - RUP) 〈 Là Software Engineering process 〈 Là sản phẩm tiến trình (process product) do Rational Software phát triển và bảo trì RUP nâng cao team productivity 〈 Các hoạt động RUP tạo lập và quản lý models 〈 Là hướng dẫn cách sử dụng hiệu quả UML Các nguyên tắc cơ bản của RUP Lặp và tăng trưởng Dự án được cắt thành những vòng lặp hoặc giai đoạn ngắn. Cuối mỗi vòng lặp thì một phần thi hành được của hệ thống được sản sinh theo cách tăng trưởng (thêm vào) dần dần. 14
15. Tập trung vào kiến trúc Toàn bộ hệ thống phức tạp phải được chia thành từng phần (các modun) để có thể dễ dàng triển khai và bảo trì, tạo nên một kiến trúc. (Theo 5 góc nhìn) Dẫn dắt các ca sử dụng RUP nhấn mạnh sự đáp ứng nhu cầu người dùng, thể hiện bởi các ca sử dụng. Các ca sử dụng ảnh hưởng và dẫn đường cho mọi giai đoạn phát triển của hệ thống. Khống chế bởi các nguy cơ Các nguy cơ chính đối với dự án phải phát hiện sớm và loại bỏ càng sớm càng tốt. Yêu cầu này cũng là căn cứ để xác định thứ tự trước sau của các vòng lặp. Các pha và công đoạn của tiến trình RUP Có 4 pha Khởi đầu (inception) Cho một cái nhìn tổng quát về hệ thống sẽ xây dựng và về dự án sẽ triển khai. Phác thảo (elaboration) Bao gồm sự phân tích chi ti ết hơn về h ệ th ống, cả v ề chức năng lẫn cấu trúc tĩnh. Đồng thời một kiến trúc hệ thống cũng được đề xuất. Kiến trúc này có thể dựng thành nguyên mẫu, trên đó thể hiện nhiều ý đồ đối với hệ thống Xây dựng (construction) Tập trung vào việc thiết kế và thực thi hệ thống. Chuyển giao (transition) Nhằm chuyển hệ th ống đã xây dựng cho người dùng cuối Time 1.5. Các bước phân tích thiết kế hướng đối tượng Quá trình phân tích nhìn chung là hệ quả của việc trả lời câu hỏi "Hệ thống cần phải làm gì?". Những mục tiêu cụ thể của giai đoạn phân tích là: 15
16. 〈 Xác định hệ thống cần phải làm gì. 〈 Nghiên cứu thấu đáo tất cả các chức năng cần cung cấp và những yếu tố liên quan 〈 Xây dựng một mô hình nêu bật bản chất vấn đề từ một hướng nhìn có thực (trong đời sống thực). 〈 Trao định nghĩa vấn đề cho chuyên gia lĩnh vực để nhận sự đánh giá, góp ý. 〈 Kết quả của giai đoạn phân tích là bản Đặc tả yêu cầu (Requirements Specifications). Một số các công việc thường được thực hiện trong giai đoạn thiết kế: 〈 Nhận biết form nhập liệu tùy theo các thành phần dữ liệu cần nhập. 〈 Nhận biết reports và những output mà hệ thống mới phải sản sinh 〈 Thiết kế forms (vẽ trên giấy hay máy tính, sử dụng công cụ thiết kế) 〈 Nhận biết các thành phần dữ liệu và bảng để tạo database Ước tính các thủ tục giải thích quá trình xử lý từ input đến output. 16
17. CHƯƠNG 2: UML VÀ CÔNG CỤ PHÁT TRIỂN HỆ THỐNG Mã chương: MHLTV 19.02 Giới thiệu UML (Unified Modeling Language) là ngôn ngữ dành cho việc đặc tả, hình dung, xây dựng và làm tài liệu của các hệ thống phần mềm. UML tạo cơ hội để viết thiết kế hệ thống, bao gồm những khái niệm như tiến trình nghiệp vụ và các chức năng của hệ thống. Cụ thể, nó hữu dụng cho những ngôn ngữ khai báo, giản đồ cơ sở dữ liệu, thành phần phần mềm có khả năng tái sử dụng. UML được phát triển bởi Rational Rose và một số nhóm cộng tác, nó nhanh chóng trở thành một trong những ngôn ngữ chuẩn để xây dựng hệ thống phần mềm hướng đối tượng (Object-Oriented). Đây là ngôn ngữ kế vị xứng đáng cho những ngôn ngữ mô hình hoá như Booch, OOSE/Jacobson, OMT và một số các phương thức khác. Mục tiêu - Nêu được lịch sử phát triển của UML - Trình bày được khái niệm cơ bản trong UML, các biểu đồ UML - Vận dụng linh hoạt các biểu đồ UML xác định yêu cầu hệ thống trong thực tế. - Vận dụng thành thạo công cụ Ratinonal Rose. Nội dung 2.1. Giới thiệu UML Mô hình khái niệm – mô hình được tạo lên bởi các khái niệm và các quan hệ giữa chúng. Mô hình khái niệm là bước đầu tiền vẽ các biểu đồ UML. Nó giúp hiểu được các thực thể trong thế giới thực và chúng tương tác lẫn nhau như thế nào. Để UML mô tả thế giới thực, nó cần phải tạo ra mô hình khái niệm và sau đó xử lý dần dần từng bước. Mô hình khái niệm của UML có thể mô tả 3 khái niệm chính: Các khối xây dựng UML (UML Building Blocks) Luật liên kết các khối xây dựng UML Cơ chế chung của UML 2.1.1. Lịch sử về UML A picture is worth a thousand words” – UML. Mục đích chính là UML như là cơ chế mô hình hóa đơn giản để mô hình tất cả các hệ thống tiện ích của môi trường thực tế phức tạp hiện nay 2.1.2. UML – ngôn ngữ mô hình hóa hướng đối tượng UML – Ngôn ngữ chuẩn cho đặc tả, hình ảnh hóa, xây dựng, và mô tả tài liệu cho các tác nhân của hệ thống phần mềm. UML – được tạo bởi Nhóm Quản lý Đối tượng (Object Management Group – OMG), phiên bản UML 1.0 được đưa ra vào tháng 01/1997. OMG tiếp tục phát triển UML như một tiêu chuẩn công nghiệp phần mềm thực sự. 2.2 Các khái niệm cơ bản trong UML Đặc điểm UML: UML viết tắt của Unified Modeling Language UML khác với ngôn ngữ lập trình: C/C++, Java, PHP, Cobol, UML là ngôn ngữ hình ảnh sử dụng tạo ra các bản kế hoạch thiết kế. 17
18. UML có thể được mô tả như ngôn ngữ mô hình hóa hình ảnh đa năng để hình ảnh hóa, đặc tả, xây dựng và văn bản hóa hệ thống phần mềm Mặc dù UML chuyên dành cho thiết kế, mô hình hóa phần mềm, nhưng nó có thể dùng để mô hình hóa các hệ thống không phải phần mềm. Ví dụ: luồng nghiệp vụ cho một đơn vị sản xuất. 2.3. Các biểu đồ UML 2.3.1. Biểu đồ Use case Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại cảnh và mối liên kết của chúng đối với Use case mà hệ thống cung cấp. Một Use case là một lời miêu tả của một chức năng mà hệ thống cung cấp. Lời miêu tả Use case thường là một văn bản tài liệu, nhưng kèm theo đó cũng có thể là một biểu đồ hoạt động. Các Use case được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các tác nhân (hành vi của hệ thống theo như sự mong đợi của người sử dụng), không miêu tả chức năng được cung cấp sẽ hoạt động nội bộ bên trong hệ thống ra sao. Các Use case định nghĩa các yêu cầu về mặt chức năng đối với hệ thống. - Hệ thống: Với vai trò là thành phần của biểu đồ use case, hệ thống biểu diễn ranh giới giữa bên trong và bên ngoài của một chủ thể trong phần mềm chúng ta xây dựng.Một hệ thống ở trong biểu đồ use case không nhất thiết là một hệ phần mềm; nó có thể là một chiếc máy,hoặc là một hệ thống thực như một doanh nghiệp, một trường đại học, - Tác nhân(actor):là người dùng của hệ thống, một tác nhân có thể là một người dùng thực hoặc các hệ thống máy tính khác có vai trò nào đó trong hoạt động của hệ thống. Như vậy, tác nhân thực hiện các use case. Một tác nhân có thể thực hiện nhiều use case và ngược lại một use case cũng có thể được thực hiện bởi nhiều tác nhân Tác nhân được kí hiệu: hoặc 〈 Các use case: Đây là thành phần cơ bản của biểu đồ use case. Các use case được biểu diễn bởi các hình elip.Tên các use case thể hiện một chức năng xác định của hệ thống. Các Use case được kí hiệu bằng hình elips. 〈 Mối quan hệ giữa các use case: o Association: thường được dùng để mô tả mối quan hệ giữa Actor và Use Case và giữa các Use Case với nhau 18
19. Ví dụ quan hệ association: o Include: là quan hệ giữa các Use Case với nhau, nó mô tả việc một Use Case lớn được chia ra thành các Use Case nhỏ để dễ cài đặt (module hóa) hoặc thể hiện sự dùng lại. Ví dụ quan hệ include: o Extent: Extend dùng để mô tả quan hệ giữa 2 Use Case. Quan hệ Extend được sử dụng khi có một Use Case được tạo ra để bổ sung chức năng cho một Use Case có sẵn và được sử dụng trong một điều kiện nhất định nào đó. 2.3.2.Biểu đồ lớp Classes (Các lớp) Class là thành phần chính của bản vẽ Class Diagram. Class mô tả về một nhóm đối tượng có cùng tính chất, hành động trong hệ thống. Ví dụ mô tả về khách hàng chúng ta dùng lớp “Customer”. Class được mô tả gồm tên Class, thuộc tính và phương thức. Ký hiệu về Class Trong đó, – Class Name: là tên của lớp. – Attributes (thuộc tính): mô tả tính chất của các đối tượng. Ví dụ như khách hàng có Mã khách hàng, Tên khách hàng, Địa chỉ, Ngày sinh v.v 19
20. – Method (Phương thức): chỉ các hành động mà đối tượng này có thể thực hiện trong hệ thống. Nó thể hiện hành vi của các đối tượng do lớp này tạo ra. Ví dụ về một Class Một số loại Class đặc biệt như Abstract Class (lớp không tạo ra đối tượng), Interface (lớp khai báo mà không cài đặt) v.v chúng ta xem thêm các tài liệu về lập trình hướng đối tượng để hiểu rõ hơn các vấn đề này. Ý nghĩa Trong phương pháp hướng đối tượng, một nhóm đối tượng có chung một số thuộc tính và phương thức tạo thành một lớp. Mối tương tác giữa các đối tượng trong hệ thống sẽ được biểu diễn thông qua mối quan hệ giữa các lớp. Các lớp (bao gồm cả các thuộc tính và phương thức) cùng với các mối quan hệ sẽ tạo thành biểu đồ lớp (class diagram). Biểu đồ lớp là một biểu đồ dạng mô hình tĩnh nhằm mô tả hướng cách nhìn tĩnh về một hệ thống bằng các khái niệm lớp, các thuộc tính, phương thức của lớp và mối quan hệ giữa chúng với nhau. Tập ký hiệu UML cho biểu đồ lớp Trong phần này, chúng ta sẽ xem xét các vấn đề liên quan đến biểu diễn biểu đồ lớp trong UML. Đăng nhập Đăng ký Mua sách Kí hiệu lớp: trong UML, mỗi lớp được biểu diễn bởi hình chữ nhật gồm ba phần: tên lớp, các thuộc tính và các phương thức. Thuộc tính: các thuộc tính trong biểu đồ lớp được biểu diễn theo cấu trúc chung như sau: phạmvi tên: kiểu sốĐốitượng = mặcđịnh (Giá trịGiớihạn ) Trong đó: phạmvi cho biết phạm vi truy nhập của thuộc tính. Có bốn kiểu xác định phạm vi thuộc tính là: +: thuộc tính kiểu public #: thuộc tính kiểu protected -: thuộc tính kiểu private. ~: thuộc tính được phép truy nhập tới từ các lớp trong cùng package Các phạm vi của thuộc tính có thể được biểu diễn dưới dạng ký hiệu (+, #, -, ~) như trong UML hoặc biểu diễn dưới dạng các từ khoá (public, protected, private) như trong các ngôn ngữ lập trình. Tên: là xâu ký tự biểu diễn tên thuộc tính. kiểu: là kiểu dữ liệu của thuộc tính. 20
21. sốĐốitượng: chỉ ra số đối tượng khai báo cho thuộc tính ứng với một mặcđịnh: là giá trị khởi đầu mặc định (nếu có) của thuộc tính. GiátrịGiớihạn: là giới hạn các giá trị cho thuộc tính (thông tin này không bắt buộc). Ví dụ Một khai báo thuộc tính đầy đủ: purchaseDate:Date[1] =”01-01-2000” (Saturday) Phương thức (method): các phương thức trong UML được biểu diễn theo cấu trúc chung như sau: phạmvi tênPhương thức(danhSáchThamsố): kiểuTralại { kiểuPhươngthức} Trong đó: Phạmvi biểu diễn phạm vi cho phương thức. Giống như đối với thuộc tính, có bốn dạng kiểu xác định cơ bản cho phương thức là: +: phương thức kiểu public #: phương thức kiểu protected kiểuTrảlại: chỉ ra kiểu giá trị trả về của phương thức. danhSáchThamsố: biểu diễn danh sách các tham số trong khai báo của phương thức. Mỗi tham số được biểu diễn dưới dạng chung: tên tham số: kiểu giá trị = giá trị mặc định. kiểuPhươngthức: không bắt buộc, cho biết kiểu phương thức. Phương thức có thể có một trong các kiểu đặc biệt sau: abstract: phương thức kiểu trừu tượng query: phương thức kiểu truy vấn. Ví dụ một khai báo phương thức cho một lớp: generatePurchaseList(prodID:int): StringCác kiểu lớp trong UML UML định nghĩa ba kiểu lớp dựa trên vai trò của nó trong hệ thống bao gồm: - Lớp thực thể (entity class): là lớp đại diện cho các thực thể chứa thông tin về các đối tượng xác định nào đó. Ví dụ, lớp Khách hàng, Hóa đơn. - Lớp biên (boundary class): là lớp nằm ở ranh giới giữa hệ thống với môi trường bên ngoài nhằm thực hiện vai trò nhận yêu cầu trực tiếp từ các tác nhân và chuyển các yêu cầu đó cho các lớp bên trong hệ thống. - Lớp điều khiển (controller class): thực hiện các chức năng điều khiển hoạt động của hệ thống tương ứng với các chức năng cụ thể nào đó của một nhóm các lớp biên hoặc nhóm các lớp thực thể. stt Kiểu lớp Kí hiệu UML 1 Lớp thực thể 2 Lớp biên (lớp giao diện) 3 Lớp điều khiển Các quan hệ trong biểu đồ lớp thực thể Như đã trình bày trong Chương 1, giữa các lớp thực có thể có bốn dạng quan hệ cơ bản. 21
22. Phần tiếp theo sẽ trình bày chi tiết hơn cách biểu diễn quan hệ này trong UML: - Kế thừa (Inheritance): Kế thừa là mối quan hệ giữa một lớp có các đặc trưng mang tính khái quát cao hơn và một lớp có các tính chất đặc biệt hơn. Trong biểuđồ lớp, quan hệ kế thừa được biểu diễn bằng một mũi tên có tam giác rỗng gắn ở đầu. - Liên kết (Association): Một liên kết (association) là một sự kết nối giữa các lớp, cũng có nghĩa là sự kết nối giữa các đối tượng của các lớp này. Trong UML, quan hệ này nhằm mô tả mối liên quan về mặt ngữ nghĩa (semantic) giữa hai nhóm đối tượng được biểu diễn bởi các lớp tương ứng. Quan hệ liên kết được biểu diễn bởi đoạn thẳng hai chiều nối hai đối tượng và có thể kèm theo nghĩa của quan hệ tại hai đầu của đoạn thẳng. Ví dụ sau lớp khách hàng có quan hệ liên kết với lớp sản phẩm. Ngữ nghĩa của quan hệ này thể hiện ở chỗ: khách hàng mua sản phẩm, còn sản phẩm được bán cho khách hàng. Quan hệ kiểu hai chiều Quan hệ liên kết cũng có thể có dạng một chiều. Xem ví dụ Quan hệ một chiều - Hợp thành (Composition): Quan hệ hợp thành biểu diễn một quan hệ kiểu tổng thể bộ phận nhưng mạnh hơn quan hệ kết hợp. Lớp A có quan hệ hợp thành với lớp B nếu lớp A là một phần của lớp B và sự tồn tại của đối tượng lớp B điều khiển sự tồn tại của đối tượng lớp A. Quan hệ này được biểu diễn bởi một mũi tên gắn hình thoi đặc ở đầu Phần tử mô Ý nghĩa Cách biểu diễn Ký hiệu trong biểu đồ hình Lớp (class) Biểu diễn tên lớp, Một hình chữ nhật Tên lớp các thuộc tính và gồm 3 phần tách Các Thuộc tính phương thức của biệt. Các phương thức lớp đó. Quan hệ kế Lớp này thừa Mũi tên tam giác. thừa hưởng các thuộc tính - phương thức của lớp kia Quan hệ kiểu Biểu diễn quan hệ Một đường kẻ liền liên kết giữa hai lớp độc nét (có tên xác lập, có liên quan định) nối giữa hai đến nhau lớp 22
23. Quan hệ kết Biểu diễn quan hệ Đường kẻ liền nét hợp kiểu bộ phận – tổng có hình thoi ở đầu thể. Quan hệ hợp Biểu diễn quan hệ Đường kẻ liền nét thành kiểu bộ phận – tổng có hình thoi đặc ở thể mạnh. thoi đầu Bảng Tóm tắt các phần tử mô hình UML trong biểu đồ lớp Ví dụ: biểu diễn một phần của biểu đồ lớp trong Hệ thống quản lý thư viện trong đó các lớp Thủ như (người quản lý thư viên) và Bạn đọc kế thừa từ lớp tổng quát là lớp Người. Biểu đồ lớp 2.3.4.Biểu đồ đối tượng Biểu đồ giao tiếp là biểu đồ tương tác biểu diễn mối quan hệ giữa các đối tượng, giữa các đối tượng và tác nhân. Biểu đồ giao tiếp cũng có các thông điệp với nội dung tương tự như trong biểu đồ tuần tự. Tuy nhiên, các đối tượng được đặt một cách tự do trong không gian của biểu đồ và không có đường vòng đời cho các đối tượng; các thông điệp được đánh số thể hiện thứ tự thời gian. Tập ký hiệu UML cho biểu đồ giao tiếp Các thành phần cơ bản của một biểu đồ giao tiếp là: - Các đối tượng: được biểu diễn bởi các hình chữ nhật, bên trong là tên của đối tượng. Cách viết chung của đối tượng là: tên đối tượng: tên lớp. Trong biểu đồ giao tiếp, các đối tượng tham gia tương tác luôn xuất hiện tại một vị trí xác định. - Các liên kết: giữa hai đối tượng có tương tác sẽ có một liên kết nối 2 đối tượng đó. Liên kết này không có chiều. - Các thông điệp: được biểu diễn bằng các mũi tên hướng từ đối tượng gửi sang đối tượng nhận bên cạnh liên kết giữa 2 đối tượng đó. Trong biểu đồ giao tiếp, các thông điệp được đánh số theo thứ tự xuất hiện trong kịch bản mô tả ca sử dụng 2.3.5.Biểu đồ trạng thái Ý nghĩa 23
24. - Biểu đồ trạng thái được sử dụng để biểu diễn các trạng thái và sự chuyển tiếp giữa các trạng thái của các đối tượng trong một lớp xác định. Thông thường, mỗi lớp sẽ có một biểu đồ trạng thái (trừ lớp trừu tượng là lớp không có đối tượng) được biểu diễn dưới dạng máy trạng thái hữu hạn với các trạng thái và sự chuyển tiếp giữa các trạng thái đó. Tập ký hiệu UML cho biểu đồ trạng thái Các thành phần trong một biểu đồ trạng thái bao gồm: - Trạng thái (state): Bên trong các trạng thái có thể miêu tả các biến trạng thái hoặc các hành động (action) tương ứng với trạng thái đó. - Trạng thái con (substate): là một trạng thái chứa bên trong một trạng thái khác. Trạng thái có nhiều trạng thái con gọi là trạng thái tổ hợp. Ví dụ có trạng thái con thể hiện trong ví dụ sau Biểu đồ trạng thái là dạng biểu đồ mô tả các trạng thái có thể có và sự chuyển đổi giữa các trạng thái đó khi có các sự kiện tác động của một đối tượng. Đối với các đối tượng có nhiều trạng thái thì biểu đồ trạng thái là sự lựa chọn tốt nhất giúp chúng ta có thể hiểu rõ hơn về hệ thống. - Trạng thái khởi đầu (initial state): trạng thái đầu tiên khi kích hoạt đối tượng. - Trạng thái kết thúc (final state): kết thúc vòng đời đối tượng. - Các chuyển tiếp (transition): biểu diễn các chuyển đổi giữa các trạng thái. - Sự kiện (event): sự kiện tác động gây ra sự chuyển đổi trạng thái. Mỗi sự kiện được đi kèm với các điều kiện (guard) và các hành động (action). Trong một biểu đồ trạng thái của UML có thể có một số loại sự kiện sau đây: - Sự kiện gọi (call event): Yêu cầu thực hiện một hành động (một phương thức) - Sự kiện tín hiệu (signal event): Gửi thông điệp (chứa các giá trị thuộc tính tham số liên quan) giữa các trạng thái. - Sự kiện thời gian (time event): Biểu diễn quá trình chuyển tiếp theo thời gian, thường kèm theo từ mô tả thời gian cụ thể. Các thành phần của biểu đồ trạng thái 〈 Trạng thái bắt đầu: (Initial State) 〈 Trạng thái kết thúc: (Final State) 24
25. Trong biểu đồ, đường mũi tên chỉ ra sự biến đổi từ một trạng thái sang trạng thái khác. 〈 Sự kiện (Event) hoặc Chuyển đổi (Transition) 〈 Trạng thái đối tượng (State) 2.3.6.Biểu đồ trình tự Biểu đồ tuần tự là biểu đồ dùng để xác định các trình tự diễn ra sự kiện của một nhóm đối tượng nào đó. Nó miêu tả chi tiết các thông điệp được gửi và nhận giữa các đối tượng đồng thời cũng chú trọng đến việc trình tự về mặt thời gian gửi và nhận các thông điệp đó. Có hai loại biểu đồ tương tác: Biểu đồ tuần tự và biểu đồ cộng tác. Các biểu đồ tuần tự biểu diễn mối liên hệ giữa các đối tượng trong hệ thống và giữa các đối tượng với các tác nhân bên ngoài theo thời gian. Biểu đồ tuần tự nhấn mạnh thứ tự thực hiện của các tương tác. Tập ký hiệu UML cho biểu đồ tuần tự Các thành phần cơ bản của một biểu đồ tuần tự là: - Các đối tượng (object): được biểu diễn bởi các hình chữ nhật, bên trong là tên của đối tượng. Cách viết chung của đối tượng là: tên đối tượng: tên lớp. Nếu chỉ viết: tên lớp thì có nghĩa là bất cứ đối tượng nào của lớp tương ứng đó. Trong biểu đồ tuần tự, không phải tất cả các đối tượng đều cùng lúc xuất hiện trên một biểu đồ mà chúng chỉ xuất hiện (về mặt thời gian) khi thực sự tham gia vào tương tác. - Các thông điệp: được biểu diễn bằng các mũi tên hướng từ đối tượng gửi sang đối tượng nhận. Tên các thông điệp có thể biểu diễn dưới dạng phi hình thức (như các thông tin trong kịch bản) hoặc dưới dạng hình thức (với dạng giống như các phương thức). Rõ ràng rằng biểu diễn dưới dạng hình thức sẽ rất hữu ích cho việc xác định các phương thức cho lớp. Biểu đồ tuần tự cho phép có các thông điệp từ một đối tượng tới chính bản thân nó. - Trong biểu đồ tuần tự có thể có nhiều loại thông điệp khác nhau tuỳ theo mục đích sử dụng và tác động của thông điệp đến đối tượng. Các dạng thông điệp được tổng kết theo bảng dưới đây STT Loạimessage Mô tả Biểu diễn 1 Gọi (call) Mô tả một lời gọi từ đối tượng này đến đối tượng kia. 2 Trả về (return) Trả về giá trị ứng với lời gọi 3 Gửi (send) Gửi một tín hiệu tới một đối tượng 25
26. 4 Tạo (create) Tạo một đối tượng 5 Huỷ (destroy) - Đường vòng đời: là một đường kẻ nối dài phía dưới đối tượng, mô tả quá trình tồn tại của đối tượng trong quá trình tương tác của biểu đồ. - Chú thích: biểu đồ tuần tự cũng có thể có chú thích để người đọc dễ dàng hiểu được nội dung của biểu đồ đó. 2.3.7.Biểu đồ cộng tác Đưa ra tổ chức đối tượng mà ở đó phương thức gọi tuần tự với số thứ tự kèm theo. ▪ Các phương thức tương tự như sequence diagram. Khác là sequence diagram ko mô tả tổ chức đối tượng, còn collaboration diagram thì có Mô hình luồng điều khiển theo luồng thời gian Mô hình luồng điều khiển theo tổ chức cấu trúc Cho kỹ thuật chuyển và đảo nghịch 26
27. 2.3.8.Biểu đồ hoạt động Ý nghĩa Biểu đồ hoạt động biểu diễn các hoạt động và sự đồng bộ, chuyển tiếp các hoạt động của hệ thống trong một lớp hoặc kết hợp giữa các lớp với nhau trong một chức năng cụ thể. Biểu đồ hoạt động có thể được sử dụng cho nhiều mục đích khác nhau, ví dụ như: 〈 Để xác định các hành động phải thực hiện trong phạm vi một phương thức. 〈 Để xác định công việc cụ thể của một đối tượng. 〈 Để chỉ ra một nhóm hành động liên quan của các đối tượng được thực hiện như thế nào và chúng sẽ ảnh hưởng thế nào đến những đối tượng xung quanh. Tập ký hiệu UML Các phần tử mô hình UML cho biểu đồ hoạt động bao gồm: Hoạt động (Activity): là một quy trình được định nghĩa rõ ràng, có thể được thực hiện bởi một phương thức hoặc một nhóm đối tượng. Hoạt động được thể hiện bằng hình chữ nhật tròn cạnh. Thanh đồng bộ hóa (Synchronisation bar): cho phép ta mở ra hoặc là đóng lại các nhánh chạy song song trong tiến trình. Thanh đồng bộ hoá trong biểu đồ động Điều kiện (Guard Condition): các biểu thức logic có giá trị hoặc đúng hoặc sai. Điều kiện được thể hiện trong ngoặc vuông, ví dụ: [Customer existing]. Các luồng (swimlane): Mỗi biểu đồ hoạt động có thể biểu diễn sự phối hợp hoạt động trong nhiều lớp khác nhau. Khi đó mỗi lớp được phân tách bởi một luồng 27
28. (swimlane) riêng biệt và các luồng này được biểu diễn đơn giản là các ô khác nhau trong biểu đồ. Các ký hiệu UML cho biểu đồ hoạt động được tổng kết trong Bảng sau: Phần tử mô hình Ý nghĩa Ký hiệu trong biểu đồ Hoạt động Mô tả một hoạt động gồm tên hoạt động và đặc tả của nó Trạng thái khởi đầu Trạng thái kết thúc Thanh đồng bộ ngang Mô tả thanh đồng bộ nằm ngang Thanh đồng bộ hoá dọc Mô tả thanh đồng bộ theo chiều thẳng đứng Chuyển tiếp Quyết định Mô tả một lựa chọn điều kiện. Các luồng phân cách nhau bởi một phân tách các lớp đối tượng đường kẻ dọc từ trên khác xuống dưới biểu đồ nhau tồn tại trong biểu đồ hoạt động 28
29. Biểu đồ hoạt động là biểu đồ mô tả các bước thực hiện, các hành động, các nút quyết định và điều kiện rẽ nhánh để điều khiển luồng thực hiện của hệ thống. Đối với những luồng thực thi có nhiều tiến trình chạy song song thì biểu đồ hoạt động là sự lựa chọn tối ưu cho việc thể hiện. Biểu đồ hoạt động khá giống với biểu đồ trạng thái ở tập các kí hiệu nên rất dễ gây nhầm lẫn. Khi vẽ chúng ta cần phải xác định rõ điểm khác nhau giữa hai dạng biểu đồ này là biểu đồ hoạt động tập trung mô tả các hoạt động và kết qủa thu được từ việc thay đổi trạng thái của đối tượng còn biểu đồ trạng thái chỉ mô tả tập tất cả các trạng thái của một đối tượng và những sự kiện dẫn tới sự thay đổi qua lại giữa các trạng thái đó. Các thành phần của biểu đồ hoạt động 〈 Trạng thái khởi tạo hoặc điểm bắt đầu (Initial State or Start Point) 〈 Hoạt động hoặc trạng thái hoạt động (Activity or Action State) Hoạt động và sự chuyển đổi hoạt động được ký hiệu và cách sử dụng hoàn toàn giống như trạng thái trong biểu đồ trạng thái đã nêu ở trên. 〈 Nút quyết định và rẽ nhánh Nút rẽ nhánh trong biểu đồ hoạt động được kí hiệu bằng hình thoi màu trắng. 〈 Thanh tương tranh hay thanh đồng bộ Có thể có nhiều luồng hành động được bắt đầu thực hiện hay kết thúc đồng thời trong hệ thống. Thanh đồng bộ kết hợp: Thanh đồng bộ chia nhánh: 〈 Cạnh gián đoạn (Interrupting Edge) 29
30. 〈 Luồng hoạt động (Action Folow) 〈 Phân làn (Swimlanes) 2.3.9.Biểu đồ thành phần Ý nghĩa Biểu đồ thành phần được sử dụng để biểu diễn các thành phần phần mềm cấu thành nên hệ thống. Một hệ phần mềm có thể được xây dựng từ đầu bằng cách sử dụng mô hình lớp như đã trình bày trong các phần trước của tài liệu, hoặc cũng có thể được tạo nên từ các thành phần sẵn có. Mỗi thành phần có thể coi như một phần mềm nhỏ hơn, cung cấp một khối dạng hộp đen trong quá trình xây dựng phần mềm lớn. Nói cách khác, các thành phần là các gói được xây dựng cho quá trình triển khai hệ thống. Các thành phần có thể là các gói ở mức cao như JavaBean, các gói thư viện liên kết động dll, hoặc các phần mềm nhỏ được tạo ra từ các thành phần nhỏ hơn như các lớp và các thư viện chức năng. Tập ký hiệu UML Tập ký hiệu UML cho biểu đồ thành phần được tổng kết trong bảng sau: Phầnt ử mô hình Ýngh ĩa Ký hiệu trong biểu đồ Thành phần Mô tả một thành phần của biểu đồ, mỗi thành phần có thể chứa nhiều lớp hoặc nhiều chương trình con Giao tiếp Mô tả giao tiếp gắn với mỗi thành phần Mối quan hệ phụ Mối quan hệ giữa các thành thuộc giữa các phần thành phần 2.3.10.Biểu đồ triển khai Ý nghĩa Biểu đồ triển khai biểu diễn kiến trúc cài đặt và triển khai hệ thống dưới dạng các đỉnh và các mối quan hệ giữa các đỉnh đó. Thông thường, các đỉnh được kết nối với nhau thông qua các liên kết truyền thông như các giao thức kết nối mạng TCP/IP, IIOP Tập ký hiệu UML cho biểu đồ triển khai 30
31. Tập ký hiệu UML cho biểu đồ triển khai hệ thống được biểu diễn trong Bảng sau: Phần tử mô hình Ý nghĩa Ký hiệu trong biểu đồ ác nodes (hay các thiết ác nodes (hay các thiết bị) Biểu diễn các thành bị) Biểu diễn các thành phần không có bộ vi xử phần không có bộ vi xử lý trong biểu đồ triển lý trong biểu đồ triển khai hệ thốn khai hệ thốn Các bộ xử lý Biểu diễn các thành phần có bộ vi xử lý trong biểu đồ triển khai hệ thống Các liên kết truyền Nối các thành phần thông của biểu đồ triển khai hệ thống. Thường mô tả một giao thức truyền thông cụ thể 2.4. Giới thiệu công cụ Rational Rose Rational rose là phần mềm công cụ mạnh hỗ trợ phân tích, thiết kế hệ thống phần mềm theo đối tượng. Nó giúp ta mô hình hóa hệ thống trước khi viết mã chương trình. Rational rose hỗ trợ cho việc làm mô hình doanh nghiệp, giúp bạn hiểu được hệ thống của mô hình doanh nghiệp. Giúp chúng ta phân tích và làm cho chúng ta có thể thiết kees cho mô hình. Mô hình Rose là bức tranh của hệ thống từ những phối cảnh khác nhau nó bao gồm tất cả các mô hình UML, actors, use case, object, component và deployment nodes vv trong hệ thống. Nó mô tả chi tiết mà hệ thống bao gồm và nó sẽ làm việc như thế nào vì thế người lập trình có thể dùng mô hình như một bản thiết kế cho công việc xây dựng hệ thống. Ưu điểm: + Cung cấp nhiều tính năng + Mô hình hướng đối tượng + Cung cấ cho UML, COM, OMT, Booch ‘93 + Kiểm tra ngữ nghĩa + Hỗ trợ phát sinh mã cho một số ngôn ngữ Tồn tại: + Phải cân chỉnh nhiều cho mô hình được đẹp + Trong bản free không hỗ trợ phát sinh mã cho một số ngôn ngữ + Không lùi về những bước trước đã làm + Dung lượng khá nặng 31
32. Bài tập 1. Trình bày mục đích và mức độ hoàn thành mục đích chấp nhận được của hệ thống thông tin. Nêu mục đích của hệ thống thông tin đối với doanh nghiệp, cơ quan quản lý nhà nước và đối với tầm quốc gia. 2. Nêu các thành phần và các đặc trưng của hệ thống thông tin. 3. Nêu khái niệm về hoạt động tác nghiệp, quyết định có cấu trúc, nửa cấu trúc hoặc không có cấu trúc. Cho các ví dụ thực tế, liên hệ bản thân về hoạt động tác nghiệp, quyết định có cấu trúc, nửa cấu trúc hoặc không có cấu trúc. 4. Trình bày các loại hệ thống thông tin hệ thống thông tin theo chức năng. 5. Trình bày hệ thống thông tin tổng thể trong tổ chức hoạt động và các bước xây dựng hệ thống thông tin. 32
33. CHƯƠNG 3: PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG Mã chương : MHLTV 19.03 Giới thiệu Trong những năm gần đây phương thức lập trình hướng đối tượng đã thống lĩnh thị trường lập trình phần mềm và UML cũng đã trở thành ngôn ngữ mô hình hóa phổ biến trong sản xuất phần mềm. Hầu hết các trường đại học, cao đẳng đã đưa hai môn này vào đào tạo chính khóa và cũng có không ít tài liệu viết về những vấn đề này. Tuy nhiên, nó vẫn còn rất khó hiểu và khó áp dụng với người học và những bạn trẻ đang làm về Công nghệ thông tin. Trong bài này, chúng tôi sẽ cố gắng trình bày một cách đơn giản và dễ hiểu nhất các kiến thức về Phân tích và thiết kế hướng đối tượng và UML để giúp các bạn hiểu và áp dụng vào thực tế. Các bài viết sẽ hướng dẫn các bạn phân tích và thiết kế một ứng dụng cụ thể để từ đó tự rút ra bài học kinh nghiệm cho mình và tiếp tục nghiên cứu sâu hơn. Mục tiêu - Xác định được yêu cầu của hệ thống - Xây dựng được mô hình hóa nghiệp vụ - Xây dựng được biểu đồ tương tác biểu đồ trạng thái, biểu đồ hoạt động. Nội dung 3.1. Phân tích yêu cầu hệ thống 3.1.1. Yêu cầu là gì? Yêu cầu (requirement) đơn giản là những phát biểu về những gì mà hệ thống phải làm hay đặc trưng nào mà hệ thống phải có. Trong pha xác định yêu cầu, các yêu cầu được thể hiện theo quan điểm của người sử dụng nghiệp vụ và tập trung vào ”cái gì” mà hệ thống có thể thực hiện. Các yêu cầu này tập trung vào các nhu cầu của người sử dụng nghiệp vụ nên thường được gọi yêu cầu nghiệp vụ (business requirement) hay yêu cầu người sử dụng (user requirement) 3.1.2. Xác định yêu cầu hệ thống Đầu ra của pha xác định yêu cầu (requirement determination) thông thường là một báo cáo bằng văn bản cùng với một số biểu đồ trong UML để mô tả các yêu cầu chức năng và phi chức năng. Đây là công đoạn cần sự tham gia của cả chuyên gia phân tích trong nhóm phát triển và đại diện của tổ chức người sử dụng. Thực tế người sử dụng thường không biết chính xác những gì họ cần và do đó các nhà phân tích phải giúp họ khám phá ra những yêu cầu của họ. Ba kỹ thuật quen thuộc hỗ trợ cho các nhà phân tích thực hiện công việc này : Tự động hóa tiến trình nghiệp vụ (BPA: business process automation), cải tiến tiến trình nghiệp vụ (BPI: business process improvement) và kỹ nghệ lặp tiến trình nghiệp vụ (BPR: business process reengineering). Những kỹ thuật này là các công cụ mà các nhà phân tích có thể sử dụng khi họ cần hướng dẫn người sử dụng giải thích những gì họ muốn từ hệ thống. Nó có thể giúp cho những người sử dụng xem xét đánh giá tình trạng hiện thời của hệ thống và các tiến trình đang xảy ra, đồng thời xác định chính xác cái gì cần phải thay đổi và phát triển các khái niệm cho hệ thống mới định phát triển. Ba kỹ thuật này được xem là tương tự nhau nhưng có sự khác biệt nhau về mức độ thay đổi. BPA tạo ra lượng thay đổi nhỏ; BPI tạo ra lượng thay đổi trung bình và BPR tạo ra lượng thay đổi lớn ảnh hưởng nhiều đến tổ chức hệ thống. Mặc dù các kỹ thuật này có thể giúp người sử dụng có cái nhìn về hệ thống mới nhưng không đủ để có thể 33
34. trích được thông tin về yêu cầu nghiệp vụ chi tiết cần xây dựng hệ thống. Vì vậy, ngoài những kỹ thuật này, người ta còn có thể sử dụng nhiều kỹ thuật để thu thập yêu cầu như phỏng vấn, lập phiếu điều tra, quan sát, phân tích tài liệu Việc trình bày đầy đủ nội dung về thu thập yêu cầu và những kỹ thuật yêu cầu nằm ngoài phạm vi của giáo trình và bạn đọc cần quan tâm có thể tham khảo ([2] [6] [8]). Một khi đã thu thập được yêu cầu người sử dụng, người phát triển cần phải xem xét cách biểu diễn hay mô hình các yêu cầu này như thế nào. Như đã đề cập trong phần trước, thông thường có hai giai đoạn xác định yêu cầu: Xác định yêu cầu nghiệp vụ và xác định yêu cầu hệ thống. Khi đó, kết quả thực hiện của các giai đoạn này sẽ được gọi các mô hình nghiệp vụ và mô hình hệ thống 〈 Xác định và mô tả các tác nhân 〈 Xác định và mô tả các ca sử dụng 〈 Xây dựng kịch bản 〈 Xây dựng biểu đồ ca sử dụng 〈 Xếp ưu tiên các ca sử dụng 〈 Phác họa giao diện người dùng 3.1.3. Phân loại yêu cầu Các yêu cầu hệ thống thường được chia làm hai nhóm: yêu cầu chức năng và yêu cầu phi chức năng. Yêu cầu chức năng (functional requirement) liên quan trực tiếp đến tiến trình mà hệ thống cần phải xử lý hay thông tin mà hệ thống cần lưu trữ. Ví dụ, các chức năng mà hệ thống bán hàng cung cấp như tạo giỏ hàng, tạo đơn đặt hàng, tìm kiếm là các yêu cầu chức năng. Yêu cầu phi chức năng (nonfunctional requirement) liên quan đến các tính chất của hành vi mà hệ thống phải có như khả năng truy nhập hệ thống qua các trình duyệt Web khác nhau hay hỗ trợ việc sử dụng video để quảng cáo Yêu cầu phi chức năng chủ yếu được sử dụng trong pha thiết kế khi cần đưa ra quyết định về giao diện người dùng, các phần cứng và phần mềm cần hỗ trợ hay có liên quan, và kiến trúc vật lý cơ sở cho hệ thống. 1.4. Mô hình hoá nghiệp vụ Trong phần này, chúng ta sẽ xem xét cách xây dựng mô hình nghiệp vụ để làm tiền đề cho việc xây dựng mô hình chức năng của hệ thống sau này. Mô hình nghiệp vụ (business model) có thể đơn giản như là một biểu đồ lớp nhằm chỉ ra những quan hệ giữa các thực thể nghiệp vụ nên đôi khi còn được gọi là mô hình miền (domain model). Đối với các dự án nhỏ, mô hình miền có thể được xem là tạm đủ. Tuy nhiên, trong đa phần các dự án phần mềm, chúng ta phải xaay dựng toàn bộ mô hình nghiệp vụ để biểu diễn cách mà các nghiệp vụ được vận hành hay một phần nghiệp vụ có liên quan đến hệ thống dự định phát triển. Ca sử dụng không phải là cách duy nhất để mô hình hóa một nghiệp vụ. Nhưng đó là cách đơn giản hơn so với các cách mô hình phức tạp như mô hình hóa tiến trình nghiệp vụ (business process modeling) hay phân tích luồng công việc (workflow analysis). Mô hình hóa nghiệp vụ dựa vào ca sử dụng được xem là đơn giản vì nó không đòi hỏi một sự am hiểu chuyên sâu về công nghệ hay kỹ thuật nào, mà chỉ với sự hiểu biết thông thường và một chút logic là có thể hiểu được những gì nó thể hiện. Mô hình hóa nghiệp vụ với ca sử dụng bao gồm các bước sau đây: 1. Xác định và mô tả các tác nhân 2. Xây dựng bảng thuật ngữ 3. Xác định và mô tả các ca sử dụng 34
35. 4. Xây dựng chi tiết ca sử dụng 5. Xây dựng biểu đồ hoạt động (Tùy chọn) 6. Xây dựng biểu đồ giao tiếp (Tùy chọn) Cần nhấn mạnh ở đây rằng trong quá trình phát triển hệ phần mềm hướng đối tượng, chúng ta cần phải lặp đi lặp lại những bước này cho đến khi có được một bức tranh đầy đủ về hệ thống mà ta muốn xây dựng. Xác định và mô tả các tác nhân Việc đầu tiên ta cần phải làm là xác định các tác nhân nghiệp vụ. Một tác nhân (actor) là một người hay một đối tượng giữ vai trò nào đó trong nghiệp vụ như một bộ phận hay một hệ phần mềm riêng biệt. Việc xác định tác nhân giúp chúng ta xác định được cách mà nghiệp vụ được sử dụng, từ đó chỉ ra được các trường hợp sử dụng. Trong thực tế, một tác nhân có thể đóng các vai trò khác nhau trong những thời điểm khác nhau. Ví dụ, một nhân viên thư viện khi hết giờ làm việc có thể mượn sách về nhà đọc và khi đó anh ta trở thành bạn đọc; một nhân viên của Công ty cho thuê xe ôtô sẽ trở thành khách hàng khi hết giờ làm việc anh ta quyết định thuê một chiếc ô tô để đi nghỉ cuối tuần. Vì vậy trong giai đoạn này của quá trình phát triển, ta nên làm việc chính với các nhà đầu tư để tìm hiểu xem các hoạt động nghiệp vụ tương ứng với mỗi tác nhân và khi đó chúng ta sẽ xác định được các tác nhân một cách dễ dàng hơn. Chúng ta hãy xem cẩn thận hơn ví dụ về hệ quản lý đăng ký học tín chỉ sau đây: Ví dụ: Hệ thống quản lý đăng ký học theo tín chỉ ở trường Đại học có các phòng ban, cá nhân là những tác nhân liên quan sau đây: • Văn phòng khoa: xác định các ràng buộc được đăng ký các môn học, mời giảng viên cho các lớp tín chỉ. • Phòng đào tạo: tạo lớp tín chỉ, xây dựng kế hoạch lớp tín chỉ, điều kiện được tốt nghiệp các ngành học đối với sinh viên. • Sinh viên: xem các khóa học trong kỳ tới, đăng ký học, hủy đăng ký, xem lịch học, xem kết quả học tập các môn học. • Giảng viên: xem danh sách môn học, đăng ký giảng dạy, xem lịch giảng dạy • Phòng kế toán: dựa trên số tín chỉ sinh viên đăng ký để thu học phí. • Hệ thống lập lịch phòng học: sắp xếp lớp, phòng học, kíp theo sĩ số lớp tùy từng hệ, khoa, khóa học hay chuyên ngành. • Hệ thống quản lý sinh viên: phân lớp, quản lý mã sinh viên, hồ sơ học bạ sinh viên, danh sách sinh viên • Hệ thống quản lý kết quả học tập: cập nhật điểm thành phần, danh sách sinh viên không đủ điều kiện dự thi, cập nhật điểm thi, tổng hợp điểm, danh sách sinh viên nhận học bổng Xây dựng Bảng Thuật ngữ Nhiều nghiên cứu đã chỉ ra rằng việc tiến hành xây dựng Bảng thuật ngữ (Glossary) ngay khi khởi đầu dự án đóng vai trò quan trọng cho việc xác định chính xác các yêu cầu khách hàng. Từ Bảng thuật ngữ được cộng đồng hướng đối tượng ưa thích hơn từ điển dữ liệu (data dictionary) như được dùng trước đây. Mục đích của bảng thuật ngữ là nhằm làm sáng tỏ các thuật ngữ sử dụng cho một miền nào đó để mọi người hiểu được các sản phẩm trong quá trình phát triển phần mềm. Trong khi đó, từ điển dữ liệu ngụ ý rằng dữ liệu được mô hình hóa một cách độc lập và như vậy đã tách dữ liệu ra khỏi hoạt động liên quan. Điều mà những người theo quan điểm hướng đối tượng đã phải tìm cách để tránh tính cô lập này. Hơn nữa, bảng thuật ngữ cũng cho phép ta sắp 35
36. xếp thành các nhóm từ đồng nghĩa để có thể dùng bất kỳ từ nào trong nhóm mà không gây ra sự hiểu nhầm. Mỗi dòng trong Bảng thuật ngữ định nghĩa một thuật ngữ và nó có thể ngắn hoặc dài tùy theo các trường hợp. Tuy nhiên, việc mô tả tác nhân thường là có tính chất tổng quát bởi vì nó có thể được áp dụng trong nhiều ngữ cảnh. Do đó, ta có thể ghi lại các quan hệ của mỗi thuật ngữ trong quá trình phát triển như tác nhân nghiệp vụ, tác nhân hệ thống Sau đây là danh sách các mối quan hệ mà chúng ta có thể tham khảo trong quá trình xây dựng bảng thuật ngữ: - Tác nhân nghiệp vụ (business actor): tác nhân xuất hiện trong các yêu cầu nghiệp vụ. - Đối tượng nghiệp vụ (business object): đối tượng xuất hiện trong các yêu cầu nghiệp vụ. - Tác nhân hệ thống (syste actor): tác nhân xuất hiện trong các yêu cầu hệ thống. - Đối tượng hệ thống (system object): đối tượng xuất hiện (bên trong hệ thống) trong các yêu cầu hệ thống. - Đối tượng phân tích (analysis object): đối tượng xuất hiện trong mô hình phân tích. - Sản phẩn triển khai (deployment artifact): những sản phẩm được triển khai trong hệ thống, ví dụ một tệp tin. - Đối tượng thiết kế (design object): đối tượng xuất hiện trong mô hình thiết kế. - Đỉnh thiết kế (design node): một máy tính hoặc một tiến trình tạo thành kiến trúc hệ thống. - Cụm thiết kế (design layer): phân rã một hệ thống con theo chiều ngang. - Gói thiết kế (design package): một nhóm các lớp liên quan nhau về mặt logic, được dùng để tổ chức công việc phát triển hệ thống. Trong bảng liệt kê này, đối tượng được hiểu là một thực thể hoặc “dữ liệu và tiến trình đã được đóng gói” như cách hiểu thông thường trong cách tiếp cận hướng đối tượng. Mỗi loại đối tượng (nghiệp vụ, hệ thống, phân tích, thiết kế) là hơi khác nhau. Ví dụ, khi bạn đọc mượn một cuốn sách, công việc của thủ thư lúc này vừa liên quan đến đối tượng nghiệp vụ ở bên ngoài hệ thống là cuốn sách vật lý trên giá sách vừa liên quan đến đối tượng nằm trong chính hệ thống được khởi tạo từ lớp chúng ta cài đặt. Các thực thể trong Bảng thuật ngữ đều tuân theo quy định đặt tên lớp như lớp bạn đọc Bandoc, lớp sách Sach, nhân viên thư viện NhanvienThuvien, thủ kho Thukho, thủ thư Thuthu Rõ ràng khi chúng ta sử dụng cùng một quy định trong tất cả tài liệu của dự án, thì người đọc dễ dàng tham chiếu đến các định nghĩa trong bảng thuật ngữ hơn. Ví dụ: Một số thuật ngữ trong Hệ đăng ký học theo tín chỉ: STT Tiếng Anh Tiếng Việt Giải thích nội dung 1 Branches Ngành Một lĩnh vực đào tạo chia thành một số ngành. Ví dụ, công nghệ thông tin có ngành công nghệ phần mềm, hệ thống thông tin 2 Classes Lớp Là cách tổ chức một số sinh viên cùng ngành, cùng khóa để theo dõi, quản lý. 3 Credit Tín chỉ Được sử dụng để tính khối lượng học tập của SV. Một tín chỉ được quy định bằng 15 tiết học lý 4 Faculty Khoa Một bộ phân trong một trường đào tạo một hay một số ngành học nhất định 5 Majors Chuyên nghành Một ngành chia thành một số chuyên ngành 6 Marks Điểm Con số đánh giá két quả thực hiện việc học tập của sinh viên về một môn học nào đó 7 Prerequire subjects Môn học điều kiện Những yêu cầu cần có để có thể học được môn học nêu ra 36
37. 8 schoolYear Năm học Thường gồm 10 tháng, chia làm một số học kỳ 9 Semesters Học kỳ Một khỏang thời gian được quy định trong một năm học. Năm học có thể được chia thành hai hay ba học kỳ 10 Student Sinh viên Thí sinh trúng tuyển vào học trong trường đại học 11 Subjects Môn học Gồm các thông tin chi tiết về môn học như tên môn, số tín chỉ, chuyên nghành, môn điều kiện 12 Instructor Giảng viên Người trực tiếp giảng dạy các môn học 13 timeTables Thời khóa biểu Lịch học cho các lớp gồm môn học, giờ học, phòng học và giảng viên dạy môn tương ứng Xác định và mô tả các ca sử dụng nghiệp vụ Một khi đã xác định được các tác nhân, nhiệm vụ tiếp theo là xác định các ca sử dụng nghiệp vụ. Mỗi ca sử dụng là một phần nhỏ của nghiệp vụ. Tại thời điểm này, các ca sử dụng có thể liên quan đến giao tiếp hai chiều giữa các tác nhân, đặc biệt tác nhân con người. Sau này, ta sẽ thấy các ca sử dụng hệ thống sẽ có cấu trúc hơn vì giao tiếp lúc này thường là giữa tác nhân và hệ thống hay giữa các chức năng liên quan nhau bên trong hệ thống. Không có một quy tắc nào để chỉ ra cách chia nhỏ nghiệp vụ thành các ca sử dụng. Điều này phải dựa vào kinh nghiệm, tư duy logic và cảm nhận chung về nghiệp vụ. Những cuộc hội thảo, phỏng vấn với các nhà đầu tư, khách hàng hay người sử dụng sẽ hỗ trợ rất nhiều trong việc xác định các ca sử dụng. Hơn nữa, các tài liệu về đào tạo nhân viên hay người quản lý, các sổ tay hướng dẫn cho nhân viên như hướng dẫn giảng viên trong trường đại học, các quy định cùng nhiều tài liệu khác sẽ là các nguồn hỗ trợ quan trọng. Trong quá trình xác định các ca sử dụng, phải luôn luôn nằm lòng câu hỏi sau đây: “Các hành động chủ yếu làm cho nghiệp vụ đó hoạt động là gì?” Phải nhớ rằng, khi mô hình hóa nghiệp vụ, chúng ta không quan tâm tới cách mà hệ thống định phát triển có thể vận hành thế nào. Giai đoạn này chủ yếu tập trung mô tả cách mà nghiệp vụ hiện thời đang diễn ra thế nào. UML không quy định nội dung của các ca sử dụng nghiệp vụ hay cách đánh số thứ tự thế nào. Do đó, chúng ta có thể sử dụng ngôn ngữ tự nhiên để mô tả trình tự các bước hay ngôn ngữ có cấu trúc (ngôn ngữ tự nhiên với if then .else và cấu trúc lặp loop quen thuộc trong ngôn ngữ lập trình) hay bất cứ thứ gì có thể diễn đạt và dễ hiểu nhau. Tuy nhiên, ta nên viết theo trình tự các bước với ngôn ngữ tự nhiên để làm các ca sử dụng rõ ràng và độc lập với cài đặt. Việc sử dụng ngôn ngữ cấu trúc có nguy cơ làm cho khách hàng đầu tư dự án khó hiểu vì mô tả của chúng ta mang tính chất “chuyen môn” quá. Sau khi đã có danh sách đề xuất các ca sử dụng, chúng ta có thể liệt kê các bước có liên quan trong mỗi ca. Ví dụ: Danh sách một số ca sử dụng trong Hệ thống đăng ký học theo tín chỉ - Đăng ký khóa học: sinh viên đăng ký các khóa học trong kỳ tới với phòng đào tạo. - Hủy khóa học: sinh viên hủy khóa học đã đăng ký với phòng đào tạo. - Xem điểm: sinh viên xem điểm tổng kết các khóa học của mình. - Xem kết quả đăng ký học: sinh viên xem danh sách các khóa học đã đăng ký. - Xem chương trình học: sinh viên xem danh sách các môn học của từng khoa, chuyên ngành, hệ đào tạo - Đăng ký thi đi: sinh viên đăng ký các khóa học sẽ thi cuối kỳ. - Đăng ký thi lại: sinh viên đăng ký các khóa học sẽ thi lại. - Xem lịch thi cá nhân: sinh viên xem lịch thi các khóa học mình đã đăng ký thi. - Đăng ký giảng dạy: giảng viên đăng ký các môn học có thể đảm nhiệm trong kỳ tới. 37
38. - Hủy đăng ký giảng dạy: giảng viên hủy đăng ký các môn học có thể đảm nhiệm trong kỳ tới. - Xem lịch giảng dạy: giảng viên xem lịch giảng dạy của mình trong kỳ tới. Mô tả chi tiết ca sử dụng Tại thời điểm này, việc mô tả chi tiết ca sử dụng chỉ là bước đầu để hiểu được hoạt động nghiệp vụ hiện thời mà người sử dụng đang tiến hành. Chi tiết hóa ca sử dụng bằng kịch bản (scenario) sẽ được trình bày một cách đầy đủ hơn trong phần sau khi đề cập đến giai đoạn xác định yêu cầu hệ thống. Ví dụ: Ca sử dụng: Đăng ký khóa học Ca sử dụng: Đăng ký khóa học 1. Sinh viên (SV) truy cập vào website nhà trường để đăng ký học 2. Hệ thống yêu cầu SV đăng nhập trước khi đăng ký 3. Sinh viên đăng nhập hệ thống 4. Hệ thống kiểm tra các thông tin liên quan đến SV này. 4.1. Nếu đúng, SV đề nghị Danh sách các môn học muốn đăng ký. 4.1.1. Nếu các yêu cầu đối với các khóa học được thỏa mãn, SV được ghi danh vào các lớp học. 4.1.2. Nếu không, Hệ thống thông báo SV chưa đủ điều kiện học môn học. 4.2. Nếu sai, Hệ thống yêu cầu SV nhập lại tài khoản và mật khẩu truy cập. 3.2. Mô hình hóa Use case 3.2.1. Giới thiệu về use case Use Case Diagram: bản vẽ mô tả về ca sử dụng của hệ thống. Bản vẽ này sẽ giúp chúng ta biết được ai sử dụng hệ thống, hệ thống có những chức năng gì. Lập được bản vẽ này bạn sẽ hiểu được yêu cầu của hệ thống cần xây dựng. Class Diagram: bản vẽ này mô tả cấu trúc của hệ thống, tức hệ thống được cấu tạo từ những thành phần nào. Nó mô tả khía cạnh tĩnh của hệ thống. Object Diagram: Tương tự như Class Diagram nhưng nó mô tả đến đối tượng thay vì lớp (Class). Sequence Diagarm: là bản vẽ mô tả sự tương tác của các đối tượng trong hệ thống với nhau được mô tả tuần tự các bước tương tác theo thời gian. Collaboration Diagram: tương tự như sequence Diagram nhưng nhấn mạnh về sự tương tác thay vì tuần tự theo thời gian. State Diagram: bản vẽ mô tả sự thay đổi trạng thái của một đối tượng. Nó được dùng để theo dõi các đối tượng có trạng thái thay đổi nhiều trong hệ thống. Activity Diagram: bản vẽ mô tả các hoạt động của đối tượng, thường được sử dụng để hiểu về nghiệp vụ của hệ thống. Component Diagram: bản vẽ mô tả về việc bố trí các thành phần của hệ thống cũng như việc sử dụng các thành phần đó. Deployment Diagram: bản vẽ mô tả việc triển khai của hệ thống như việc kết nối, cài đặt, hiệu năng của hệ thống v.v Notations (các ký hiệu) Notations là các ký hiệu để vẽ, nó như từ vựng trong ngôn ngữ tự nhiên. Bạn phải biết từ vựng thì mới ghép thành câu, thành bài được. Chúng ta sẽ tìm hiểu kỹ các notations trong từng bản vẽ sau này. Dưới đây là vài ví dụ về notation. Mechanisms (Rules) Mechanisms là các qui tắc để lập nên bản vẽ, mỗi bản vẽ có qui tắc riêng và bạn phải nắm được để tạo nên các bản vẽ thiết kế đúng. Các qui tắc này chúng ta sẽ bàn kỹ trong các bài về các bản vẽ. 38
39. 3.2.2. Sơ đồ use case 3.2.3. Xác định các biến thể của use case Mô tả sự tương tác giữa các đối tượng thiết kế Đơn giản hoá biểu đồ tuần tự sử dụng hệ thống con Mô tả các hành vi liên quan dữ liệu bền vững Làm mịn sự mô tả luồng các sự kiện Thống nhất các lớp và các hệ thống con 2.2.4. Thiết lập các mối quan hệ giữa các use case 3.2.5. Đặc tả actor và use case Lớp phân tích Lớp thiết kế 39
40. Ánh xạ nhiều – nhiều 3.3. Xây dựng đối tượng hệ thống 3.3.1. Các khái niệm cơ bản về sơ đồ lớp Đối tượng: là cái gì đó tồn tại trong thế giới thực Lớp (Lớp đối tượng) Mô tả thuộc tính, hành vi, ngữ nghĩa của một nhóm đối tượng Lớp xác định thông tin nào được lưu trữ trong đối tượng và hành vi nào đối tượng có Ký pháp đồ họa của lớp trong biểu đồ 〈 Tên lớp (class name) 〈 Thuộc tính (Attribute) 〈 Thao tác (Operation) ü Private: ü Public: ü Protected: 3.3.2. Xác định lớp đối tượng Một số khuyến cáo về việc Tìm kiếm lớp Từ các danh từ trong: Văn bản mô tả bài toán; luồng sự kiện/Kịch bản • Danh từ => lớp?; Động từ => Phương thức? 40
41. • Chú ý rằng danh từ có thể là: tác nhân, lớp, thuộc tính và biểu thức không phải loại trên Từ biểu đồ tương tác • Những cái chung của đối tượng tạo thành lớp • VD: Biểu đồ thể hiện Khách hàng A và Khách hàng B rút tiền. Khách hàng A và B có chung một số thuộc tính (tên, địa chỉ, sđt, ) và một số phương thức => Có thể hình thành lớp cho Khách hàng A và Khách hàng B (Ví dụ: Khách Hàng) Từ các nơi khác • Các báo cáo tìm ra trong pha phân tích yêu cầu hình thành lớp giao diện • Các thiết bị phần cứng được biểu diễn bởi lớp khác nhau Cùng với chuyên gia lĩnh vực vấn đề trả lời các câu hỏi sau đây để tìm ra lớp ü Có thông tin nào cần lưu trữ hay phân tích? Nếu có, nó là lớp ü Có hệ thống ngoài không? Nếu có thì nó được xem như những lớp chứa trong hệ thống của ta hay hệ thống của ta tương tác với chúng ü Có mẫu, thư viện lớp, thành phần ? Nếu có, thông thường chúng chứa các ứng viên lớp ü Hệ thống cần quản lý các thiết bị ngoại vi nào? Mọi thiết bị kỹ thuật nối với hệ thống đều là ứng viên lớp. ü Tác nhân đóng vai trò tác nghiệp nào? Các nhiệm vụ này có thể là lớp; thí dụ người sử dụng, thao tác viên hệ thống, khách hàng 3.3.3. Mô hình hóa liên kết giữa các lớp 3.3.4. Xác định thuộc tính, method của các lớp Hành vi thường độc lập với bên ngoài (môi trường hệ thống) Hành vi xác định logic điều khiển và tổ chức các giao dịch trong ca sử dụng Hành vi ít bị thay đổi khi cấu trúc và hành vi bên trong lớp thực thể thay đổi. Hành vi sử dụng hay thiết lập nội dung của các lớp thực thể. Hành vi thường không là duy nhất, tùy theo từng tình huống, kịch bản ca sử dụng 3.3.5. Xây dựng mô hình khái niệm 41
42. Khi việc phân tích vẫn tiếp tục, một lớp điều khiển của một ca sử dụng phức tạp có thể được phát triển thành nhiều hơn một lớp 3.3.6. Xây dựng biểu đồ tương tác ϖ Ai là người có dữ liệu cần thiết để thực hiện các trách nhiệm (responsibility)? Nếu một lớp có dữ liệu, đặt trách nhiệm đi kèm với dữ liệu • Nếu nhiều lớp có dữ liệu Gán trách nhiệp với một lớp và thêm vào một quan hệ với lớp khác • Tạo một lớp mới, đặt trách nhiệm vào trong lớp mới, thêm vào các quan hệ với các lớp cần thiết để thực hiện trách nhiệm đó • Đặt trách nhiệm vào trong lớp điều khiển, và thêm vào các quan hệ với các lớp mà cần thiết để thực hiện trách nhiệm 3.3.7. Xây dựng biểu đồ trạng thái 3.3.8. Xây dựng biểu đồ hoạt động Biểu đồ hoạt động trong UML được sử dụng để chỉ ra sự phụ thuộc giữa các hoạt động khi chuyển từ điểm bắt đầu tới một điểm kế thúc của một tiến trình. Giống như biểu đồ 42
43. giao tiếp, các hành động trong biểu đồ hoạt động có thể không tương ứng với từng bước trong mô tả chi tiết của ca sử dụng. Trong thực tế phát triển phần mềm, biểu đồ hoạt động có thể được sử dụng cho nhiều mục đích khác nhau. Ví dụ, biểu đồ hoạt động có thể được sử dụng để xây dựng toàn bộ mô hình nghiệp vụ hoặc viết tài liệu cho một phương thức để thể hiện hành vi của một đối tượng phần mềm. Biểu đồ hoạt động là một đồ thị có hướng, trong đó các nút (đỉnh) là các hoạt động và các cung là các dịch chuyển: - Hoạt động (activity) là một công việc có thể được xử lý bằng tay như Điền mẫu, hoặc bằng máy như Hiển thị màn hình đăng nhập. Một hoạt động được biểu diễn trong biểu đồ bằng một hình chữ nhật tròn góc có mang tên của hoạt động - Chuyển dịch (Transition) là sự chuyển từ hoạt động này sang hoạt động khác được thể hiển bằng một mũi tên nối giữa hai hoạt động. - Nút khởi đầu (start) thể hiển điểm bắt đầu của hoạt động được ký hiệu bởi một hình tròn đặc. Nút kết thúc (end) thể hiển điểm kết thúc các hoạt động được ký hiệu hình tròn đặc có viền bao quanh. Tùy trường hợp có thể có một hoặc nhiều nút kết thúc - Các điều kiện chuyển dịch hoạt động (transition condition) được ký hiệu bởi một hình thoi để thực hiện sự rẽ nhánh các hoạt động. - Thanh đồng bộ hóa (synchronization bars) để mở hay đóng các nhánh thực hiện song song. 43
44. Ví dụ Biểu đồ hoạt động cho ca sử dụng Sinh viên đăng ký môn học 44
45. CÂU HỎI ÔN TẬP 1. Hãy làm rõ ý tưởng trong sơ đồ đặc tả các giai đoạn phân tích & thiết kế. 2. Nêu ý nghĩa, mục tiêu và các yêu cầu của từng công đoạn trong quá trình phát triển hệ thống thông tin. Anh/Chị có nhận xét gì về cấu trúc và trình tự của chu trình phát triển này ? 3. Tại sao trong mọi quá trình phát triển hệ thống thông tin, dù là theo chu trình sống nào, cũng đều phải bao gồm 2 giai đoạn trung tâm và phân biệt là phân tích & thiết kế ? 4. Nhiệm vụ của giai đoạn phân tích là phải trả lời những câu hỏi nào? 5. Nêu bản chất của 3 phương pháp cơ bản (mô hình/cách tiếp cận) để xây dựng hệ thống thông tin và so sánh lợi thế cũng như hạn chế giữa chúng. 6. Bàn về tính hiệu quả của một hệ thống thông tin. Nếu Anh/Chị được quyền quyết định dự trình phương án đưa hệ thống mới vào hoạt động, Anh/Chị chọn phương án nào trong những phương án đã nêu? tại sao? 45
46. CHƯƠNG 4: THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Mã chương: MHLVT 19.04 Giới thiệu Mục đích của phân tích là hình dung ra nghiệp vụ cần gì, trong khi mục đích của pha thiết kế là quyết định cách xây dựng hệ thống. Hay nói một cách khác, phân tích là nhằm trả lời câu hỏi “cái gì”, còn thiết kế là để trả lời câu hỏi “như thế nào”. Ho ạt động chính của pha thiết kế là tiến hóa tập biểu diễn phân tích thành tập biểu diễn thiết kế. Trong pha này, nhóm dự án xem xét cẩn thận hệ thống mới sẽ hoạt động và được tích hợp như thế nào trong môi trường và hệ thống hiện thời. Nhóm cần phải xem xét nhiều chiến lược thiết kế và quyết định chiến lược nào sẽ được sử dụng. Mục tiêu -Thiết kế được các hệ thống con - Thiết kế giao diện người dùng, thiết kế lớp, thiết kế việc lưu trữ dữ liệu. - Xây dựng được biểu đồ thành phần và biểu đồ triển khai. Nội dung 4.1.Thiết kế các hệ thống con 4.1.1. Hệ thống con ü Xây dựng biểu đồ lớp thiết kế ü Xây dựng biểu đồ tuần tự ü Xây dựng lược đồ cơ sở dữ liệu 4.1.2. Phân chia hệ thống thành các hệ thống con 4.1.3. Kiến trúc phân tầng Kiến trúc hai tầng (two tier architecture) là thế hệ kiến trúc tiếp theo được phổ biến vào những năm 1970. Ý tưởng của kiến trúc này là nhằm tăng cường khả năng xử lý trên mỗi máy khách để cho các máy tính trung tâm không phải thực hiện tất cả các tiến trình. Như vậy, chúng ta có thể thêm hay thay thế các máy khách rẻ hơn các máy tính trung tâm. Các máy khách thường là các máy tính mini hay các workstation, có thể truy nhập vào các máy tính midi hay các file server. Sự kết hợp giữa máy tính mini và máy tính midi được chỉ ra ở đây cũng tương tự như sự kết hợp giữa workstation và file server. Với kiến trúc hai tầng, chương trình và dữ liệu phải được chuyển từ máy tính trung tâm sang máy khách. Điều này đòi hỏi phải có sự kết nối nhanh giữa hai bên và điều này dẫn đến ý tưởng hiện đại về mạng. Mạng là một tập hợp bất kỳ các máy chủ (host) được kết nối với nhau bằng các đường giao tiếp tốc độ cao. Hoạt động của mô hình kiến trúc hai tầng Máy khách (Client) và máy chủ (Server) trao đổi thông tin với nhau dưới dạng các thông điệp (Message). Thông điệp gởi từ máy khách sang máy chủ gọi là các thông điệp yêu cầu (Request Message) mô tả công việc mà phần máy khách muốn máy chủ thực hiện. 46
47. Hình 5.2: Kiến trúc chương trình Client-Server Mỗi khi máy chủ nhận được một thông điệp yêu cầu, máy chủ sẽ phân tích yêu cầu, thực thi công việc theo yêu cầu và gởi kết quả về máy khách (nếu có) trong một thông điệp trả lời (Reply Message). Khi vận hành, một máy chủ sẽ phục vụ cho nhiều máy khách. Mỗi một ứng dụng trên mô hình máy khách - máy chủ (client-server) phải có một Giao thức (Protocol) riêng để trao đổi thông tin, phối hợp công việc giữa máy khách và máy chủ. Giao thức qui định một số vấn đề cơ bản sau: • Khuôn dạng loại thông điệp. • Số lượng và ý nghĩa của từng loại thông điệp. • Cách thức bắt tay, đồng bộ hóa tiến trình truyền nhận giữa máy chủ và máy khách Thông thường phần máy khách đảm nhận các chức năng về giao diện người dùng, như tạo các form nhập liệu, các thông báo, các biểu báo giao tiếp với người dùng; phần máy chủ này đảm nhận các chức năng về xử lý và lưu trữ dữ liệu. Mô hình tạo điều kiện dễ dàng cho việc bảo trì, chia sẻ, tổng hợp dữ liệu trong toàn bộ công ty hoặc tổ chức. Các chức năng về hoạt động nghiệp vụ có thể được cài đặt ở phần máy khách hoặc ở phần máy chủ và khi đó sẽ tạo ra hai loại kiến trúc máy khách-máy chủ là máy khách nặng (Fat Client) và máy khách nhẹ (Thin Client). 4.2. Thiết kế giao diện người dùng và thiết kế lớp 4.2.1. Thiết kế giao diện người dùng Các thành phần thiết kế giao diện người dùng Một số định nghĩa Kỹ thuật định hướng Theo cách những người sử dụng bảo hệ thống làm gì Kỹ thuật đầu vào Theo cách hệ thống nắm bắt được thông tin Kỹ thuật đầu ra Theo cách hệ thống cung cấp thông tin cho người dùng và các hệ thống khác Đồ hoạ giao diện người dùng (GUI) Sử dụng các đối tượng đồ hoạ (cửa sổ, biểu tượng, các nút, ) 〈 Kiểu phổ biến nhất của giao diện 〈 Thiết kế định hướng Một số nguyên lý cơ bản Áp dụng cho những người dùng Không hiểu thủ công Không được đào tạo Không có trợ giúp bên ngoài dễ dàng bằng tay Sự hướng dẫn sẽ là: Rõ ràng và dễ hiểu Đặt trong vị trí trực giác trên màn hình Biết trước người dùng sẽ làm gì Đơn giản hoá việc khôi phục từ lỗi Sử dụng thứ tự cú pháp phù hợp 4.1 5 Một số nguyên lý cơ bản (cont) Ngăn cản sai sót Giới hạn sự lựa chọn Người sử dụng có thể tạo ra lỗi hoặc thải hồi hoàn toàn hệ thống Không bao giờ hiển thị các lệnh mà không thể hiển thị (hoặc ẩn chúng đi) Nhận thực các hoạt động mà khó hoặc không thể xảy ra để khôi phục Một số nguyên lý cơ bản (cont) Đơn giản hoá việc khôi phục từ lỗi Người sử dụng có thể sẽ tạo ra sai sót Nếu có thể, có chức năng "undo" Thực hiện cuốn ngược Tự động cập nhật Sử dụng thứ tự cú pháp phù hợp Thông thường định rõ một hoạt động và một đối tượng Có thể sử dụng Action-Object, hoặc Object-Action Các cửa sổ sử dụng Object-Action (cut and paste) Bất cứ khi nào bạn chọn, nó cũng được sử dụng thuận lợi Các kiểu của điều khiển định hướng Các ngôn ngữ Ngôn ngữ lệnh Người dùng đưa vào các lệnh sử dụng ngôn ngữ đặc biệt DOS, UNIX, SQL, Khó để học, nhanh và dễ để sử dụng Ngôn ngữ tự nhiên Dễ để học Chậm và không chính xác 47
48. Các kiểu của điều khiển định hướng (cont) Menus Mục đích chung tại menu không sâu rộng Xem xét việc sử dụng “khoá nóng” Điểu khiển trực tiếp Sử dụng các biểu tượng để bắt đầu chương trình Sử dụng hình dạng và kích thước đối tượng Có thể không phải theo trực giác cho tất cả các lệnh Kiểu của menu Các kiểu menu Menu bar Dropdown menu Khi nào thì bạn Pop- up menu sử dụng kiểu Tab menu menu này? Toolbar Image map Thông điệp tiêu đề Phải rõ ràng, ngắn gọn và hoàn chỉnh Phải đúng đắn về mặt ngữ pháp và không ràng buộc từ ngữ chuyên môn và tóm tắt Tránh phủ định và hài hước Kiểu của các thông điệp Các kiểu thông điệp Khi nào thì bạn sử dụng kiểu thông Thông báo lỗi điệp này? Thông báo xác nhận Thông báo chấp nhận Thông báo chờ Thông báo trợ giúp Bài tập Giả sử rằng bạn đang thiết kế giao diện mới cho hệ thống dịch vụ tại trường bạn. Bạn sẽ kết hợp chặt chẽ các nguyên lý cơ bản của thiết kế đầu vào vào thiết kế giao diện của bạn như thế nào? 〈 Thiết kế đầu vào Các nguyên lý cơ bản Mục đích là đơn giản và dễ nắm bắt các thông tin đúng đắn cho hệ thống Phản ánh tự nhiên của đầu vào Tìm các cách đơn giản để tập trung chúng 4.1- 19Xử lý trực tuyến và khối Xử lý trực tuyến các bản ghi trực tiếp giao dịch trong CSDL thích hợp Xử lý theo khối tập trung các đầu vào trên một thời gian và đưa chúng vào hệ thống tại một thời điểm trong một đợt Xử lý khối làm đơn giản hoá các giao dịch dữ liệu và các quá trình khác, nhưng có nghĩa rằng việc kiểm kê và các báo cáo khác là không chính xác trong thời gian thực 4.2.2. Thiết kế lớp Khi chuyển từ pha phân tích sang pha thiết kế, một số lớp sẽ bị loại bỏ (ví dụ như những lớp điều khiển) và một số lớp khác sẽ được thêm vào (như các lớp để thực thi đa nhiệm). Người thiết kế sẽ tự quyết định thiết kế đối tượng nghiệp vụ, biên và và điều khiển sao cho có thể thành mã cài đặt được. Thật ra, điều này cũng tùy thuộc vào cách tiếp cận của mô hình tiến trình mà dự án sử dụng. Đối mỗi lớp thiết kế mà chúng ta đưa ra, chúng ta cần chọn tên và kiểu của các trường. Thông thường, các trường được dẫn xuất từ các thuộc tính và các liên kết được tìm thấy trong suốt quá trình phân tích. Cũng như các thuộc tính và liên kết, chúng ta cần xem xét tới quan hệ kế thừa. Quan hệ kế thừa không nhất thiết phải được ánh xạ thànhcái gì mới mà cần quyết định giữ hay không giữ chúng. Nó có thể có hay không có tính kế thừa trong hệ thống nhưng thường nó được đưa vào trong pha thiết kế hơn là phân tích. Ánh xạ các phương thức Khi chuyển đến giai đoạn thiết kế, chúng ta thường sử dụng các thuật ngữ phương thức (method) và thông điệp (message) trong lập trình hơn là thuật ngữ thao tác (operation) trong UML. Cho đến nay, phương thức được đưa ra chỉ đơn thuần như một cách ghi lại hiện thực hóa các ca sử dụng và có thể xem như là hiệu ứng phụ để kiểm định các lớp phân tích có hỗ trợ cài đặt hay không mà thôi. Các phương thức trong pha phân tích nên bỏ qua trong thiết kế. Như vậy, phương thức thiết kế đến từ đâu? Đối với đa số các đối tượng, không quan tâm đến cụm chứa nó, các thông điệp sẽ được thêm vào bởi một số lý do sau đây: 48
49. Để cho phép các đối tượng client đọc hoặc thay đổi các giá trị của các trường. Để cho phép đối tượng client truy nhập dữ liệu dẫn xuất. Ví dụ, như một thông điệp để đọc hóa đơn các mặt hàng đăng ký mua, chúng ta cũng muốn có thể đọc được tổng hóa đơn. Do kinh nghiệm hay trực giác nói rằng thông điệp thêm vào là có ích. Bởi vì khung hay mẫu mà chúng ta định sử dụng đòi hỏi phải có các thông điệp nào đó.Khi chúng ta thiết kế dịch vụ nghiệp vụ cho tầng giữa, chúng ta tìm ra những thông điệp cho các đối tượng dịch vụ. Khi chỉ ra được dịch vụ nghiệp vụ có thể được thỏa mãn bằng cách sử dụng các đối tượng nghiệp vụ, chúng ta có khả năng đối đầu với nhiều thông điệp hơn. Tóm lại, khi ánh xạ các lớp, các thuộc tính và các quan hệ trong pha phân tích sang pha thiết kế, các thông điệp sẽ bắt đầu xuất hiện từ mọi hướng Các kiểu biến Khi đưa vào một trường, chúng ta cần xem nó nên thuộc kiểu nào: kiểu cơ bản hay kiểu lớp. Thông thường, chúng ta hạn chế các kiểu sau đây: Kiểu cơ bản và kiểu lớp đơn giản mà chúng ta hy vọng tìm được trong mọi ngôn ngữ lập trình hướng đối tượng (ví dụ: int, float, boolean, String, List ). Những lớp mà chính chúng ta xây dựng. Phạm vi của các trường Đồng thời với tên và kiểu của trường, chúng ta phải khai báo phạm vi truy nhập của chúng. Phạm vi của chúng chỉ rõ các đoạn code nào cho phép đọc hay thay đổi giá trị. Có bốn cách truy nhập sau đây: Private (UML ký hiệu -): chỉ sử dụng trong phạm vi lớp định nghĩa. Package (UML ký hiệu ~): dùng trong phạm vi lớp định nghĩa và tất cả những lớp cùng gói. Protected (UML ký hiệu #): dùng trong phạm vi lớp định nghĩa, tất cả những lớp cùng gói và tất cả những lớp con của lớp định nghĩa (dù trong hay ngoài gói). Public (UML ký hiệu +): dùng bất cứ ở đâu. Thông thường, nếu ngôn ngữ cho phép, người phát triển sẽ tạo ra các trường private. Điều này ngoài lợi ích của việc đóng gói, nó sẽ làm cho compiler các cơ hội tối ưu hơn. Đôi khi người phát triển sẽ tạo ra trường protected để người phát triển những lớp con có nhiều cơ hội để sửa đổi các hành vi của lớp cha (mặc dù việc làm này làm tăng sự gắn bó giữa lớp cha và lớp con). Các trường với phạm vi package là không tốt vì chúng có thể được truy nhập bởi mẫu code trong gói mà không biết gì về đối tượng sở hữu nó. Đôi khi vì lý do thực tế như hiệu năng, người phát triển sẽ cho truy nhật kiểu package nhưng chỉ với ngôn ngữ lập trình nào có cách chỉ cho đọc giá trị (ví dụ, từ khóa final trong java). Phạm vi cũng có thể áp dụng với thông điệp. Khi đó, thông điệp có thể là: Public, nếu nó là phần của giao diện của package. Package, nếu nó là mã cài đặt được sử dụng bởi chính lớp đó và bởi lớp trong cùng package. Protected, nếu nó là mã cài đặt đuợc sử dụng bởi chính lớp đó, lớp con và các lớp trong cùng package. Private, nếu nó là mã cài đặt để sử dụng chỉ bởi lớp đó. Ngoại trừ Java, không phải ngôn ngữ nào cũng hổ trợ các kiểu truy nhập trên Các toán tử truy nhập Có hai toán tử truy nhập: get trả về giá trị của trường và set thiết lập giá trị mới của 49
50. trường. Các toán tử này làm dễ dàng cho việc bảo trì hơn và trình biên dịch dễ tối ưu hơn. Ánh xạ các lớp, thuộc tính và kiểu quan hệ hợp thành Trong UML, một số ký hiệu giống nhau được sử dụng cả cho biểu đồ lớp phân tích và biểu đồ lớp thiết kế. Khi ánh xạ sang biểu đồ lớp thiết kế, ba vấn đề chính các lớp phải được cài đặt, các kiểu thuộc tính, và cách ánh xạ hợp thành. Hình vẽ dưới đây chỉ ra biểu đồ lớp phân tích với quan hệ hợp thành được ánh xạ thành biểu đồ lớp thiết kế. Trong trường hợp này, quyết định phải đuợc tạo ra để giữ lại cả hai các lớp phân tích mà không hỗ trợ các lớp phụ thuộc (ngoài các lớp String). Các thuộc tính truy nhập trường vẫn để private là thích hợp. Trong pha phân tích, hợp thành là song hướng: bắt đầu từ một trong hai đối tượng, chúng ta có thể dễ dàng tìm thấy các đối tượng ở đầu kia. Tuy nhiên, khi chuyển sang thiết kế, chúng ta phải đối phó với một thực tế là các trường chỉ có thể hướng theo một chiều tại thời gian chạy. Nghĩa là, chúng ta có thể lấy trường từ một đối tượng sở hữu tới đối tượng ở đầu kia, nhưng không là ngược lại. Vì vậy, chúng ta cần quyết định xem chúng ta có muốn có một trường ở mỗi đầu của mối quan hệ hoặc chỉ ở một đầu và nếu vậy thì đầu nào. Chúng ta mong quan hệ hợp thành ban đầu là từ cái hợp thành đến cái được hợp thành. Điều này phản ánh một thực tế là cái được hợp thành là chủ sở hữu của mối quan hệ. Nó cũng phản ánh một thực tế là một hợp thành tương tự như một thuộc tính. Nghĩa là, đối tượng được hợp thành sử dụng dịch vụ của các thuộc tính hoặc các đối tượng hợp thành, nhưng không theo chiều ngược lại. Điều này cũng không tuyệt đối, nếu cảm thấy phù hợp với hệ th ống cụ th ể thì chúng ta có th ể đặt một trường bên trong đối tượng đuợc hợp hay bên trong cả được hợp và hợp thành. Sau khi đã quyết định hướng của hợpthành, chúng ta có thể thêm một đầu mũi tên cho biểu đồ lớp để chỉ ra cách hợp thành ánh xạ tới một trường. Trong thời gian chạy, các thông điệp chỉ có thể theo hướng mũi tên. Chúng ta có thể b ỏ h ợp thành phần và biểu diễn hoTen:HoTen bên trong SinhVien Ánh xạ quan hệ hợp thành 4.3. Thiết kế việc lưu trữ các dữ liệu Các hệ quản trị cơ sở dữ liệu Trong hơn bốn thập kỷ qua, nhiều Hệ quản trị cơ sở dữ liệu (DBMS: Database Management System) đã được phát triển như Hệ cơ sở dữ liệu quan hệ, Hệ cơ sở dữ liệu 50
51. hướng đối tượng Có một sự khác biệt giữa các ngôn ngữ lập trình mà chúng ta sử dụng để viết mã và cách chúng ta truy cập dữ liệu trong cơ sở dữ liệu. Do đó, chúng ta cần phải thực hiện một vài kiểu ánh xạ theo thời gian chạy giữa các hệ thống phần mềm và hệ cơ sở dữ liệu. Một số công cụ như EJB của J2EE sẽ tạo ra mã ánh xạ cho chúng ta. Tuy nhiên, nếu muốn sử dụng các công cụ như vậy, chúng ta vẫn cần phải hiểu rõ các nguyên lý cơ bản để sử dụng chúng hiệu quả. Cơ sở dữ liệu quan hệ thường được sử dụng để lưu trữ dữ liệu trong một hệ đa tầng trên Internet vì một số lý do sau đây: - Cơ sở dữ liệu quan hệ là quen thuộc nhất. Mặc dù có nhiều cơ sở dữ liệu hướng đối tượng, nhưng chúng chưa được sử dụng rộng rãi, đặc biệt trong các doanh nghiệp. - Tất cả cơ sở dữ liệu quan hệ đều dựa trên mô hình toán học nên chúng xem là thống nhất trong nhiều dạng của DBMS. - Tất cả cài đặt hệ cơ sở dữ liệu quan hệ trong thương mại đều hỗ trợ ngôn ngữ lai SQL (SQL: Structured Query Luange). - Ngôn ngữ lập trình Java cung cấp một thư viện Mô hình quan hệ Mô hình quan hệ là một mô hình toán học có độ tin cậy và dễ dàng tối ưu. Tuy nhiên, mô hình quan hệ không giống mô hình mạng và mô hình phân cấp, nó không có các liên kết vật lý. Tất cả dữ liệu được chứa trong các bảng, các cột. Dữ liệu trong hai bảng được quan hệ với nhau thông qua các cột thay cho liên kết vật lý. Mặc dù mô hình hướng đối tượng có thể ánh xạ dễ dàng thành mô hình quan hệ như sẽ khó để dự đoán ánh xạ nào là hiệu quả nhất cho hệ phần mềm của chúng ta. Do đó, cần phải thử nghiệm trên nhiều ánh xạ để tìm ánh xạ thích hợp nhất cho hệ của chúng ta. Trong phần này chúng ta xem xét một ánh xạ trực tiếp từ mô hình lớp thiết kế. Các ánh xạ này cũng đủ để nói rằng các kĩ thuật cơ bản liên quan đến sử dụng câu lệnh SQL để đọc dữ liệu từ CSDL thành đối tượng vào thời gian chạy và sau đó ghi dữ liệu mớivào CSDL. Mô hình quan hệ dựa trên các bảng dữ liệu chứa các dòng và các cột, mỗi cột chứa một kiểu riêng biệt. Chuẩn SQL định nghĩa một số kiểu mà ta có thể lựa chọn: - VARCHAR(X): một chuỗi mà có thế nhiều nhất là X kí tự - INTEGER: một kiểu số nguyên mà thường là 32 bit - DATE: kiểu ngày tháng trong lịch - TIMESTAMP: một sự kết hợp của ngày và thời gian trong ngày - BOOLEAN: true hay fals Khóa Một khóa là một giá trị hay bộ giá trị định danh duy nhất một dòng cho mỗi thực thể. Một số bảng chứa tập khóa tự nhiên, ví dụ Sinh viên có mã sinh viên; Một số bảng cần đưa ra khóa, ví dụ khách hàng cần có khóa để định danh người duy nhất mua số sản phẩm nào đó. Khóa có thể kết hợp nhiều giá trị. Ánh xạ mô hình đối tượng thành mô hình quan hệ Khi ánh xạ mô hình đối tượng thành Bảng, ta có thể bắt đầu hoặc với biểu đồ lớp phân tích hoặc biểu đồ lớp thiết kế. Biểu đồ lớp phân tích gần gũi với mô hình quan hệ hơn vì nó không chỉ ra hướng liên kết. Tuy nhiên, biểu đồ lớp thiết kế có kiểu gán cho các 51
52. trường nên tiện lợi khi thiết kế bảng. Để giải quyết vấn đề này, chúng ta sẽ sử dụng mô hình phân tích để thiết kế các bảng và lấy kiểu từ mô hình thiết kế. Ánh xạ các lớp thực thể Để ánh xạ một thực thể (đối tượng nghiệp vụ) từ mô hình hướng đối tượng thành lược đồ quan hệ, ta đưa ra bảng có cùng tên như lớp thực thể, trong đó mỗi dòng biểu diễn một đối tượng duy nhất của miền nghiệp vụ. Với trường đơn giản (kiểu cơ bản hay String), ta thêm một cột vào bảng với cùng tên như trường và kiểu dữ liệu thích hợp SQL. Các trường có kiểu đối tượng phải được xem xét theo cách khác mà ta sẽ trình bày trong mục tiếp theo. Để tiện cho lập trình hướng đối tượng, ta đưa ra một thuộc tính kiểu nguyên integer ID để làm khóa chính. Lợi ích của việc thêm ID là nó làm đơn giản việc code và làm cho việc đọc các đối tượng hoặc chuyển từ đối tượng này sang đối tượng khác dễ dàng và hiệu quả hơn. Ánh xạ các liên kết Như trình bày trong phần trước, khi ánh xạ từ mô hình lớp phân tích thành mô hình lớp thiết kế, ta phải chuyển liên kết hai chiều trong phân tích thành liên kết một chiều. Tuy nhiên, vì cơ sở dữ liệu quan hệ lưu trữ trực tiếp liên kết hai chiều nên chúng ta không gặp phải vấn đề như khi mô hình lớp thiết kế. Ví dụ, nếu lược đồ CSDL cho phép liên kết từ thực thể A đến thực thể B, thì DBMS và ngôn ngữ truy vấn sẽ cho phép ta liên kết từ B đến A. Do đó, lược đồ cơ sở dữ liệu của ta giống với mô hình lớp phân tích hơn là mô hình lớp thiết kế. Sau đây, chúng ta sẽ xem xét chi tiết cách ánh xạ các mô hình lớp thành các lược đồ cơ sở dữ liệu. Liên kết 1-1 Với liên kết 1 -1 chúng ta có thể thêm một khóa ngoại vào một trong các bảng thực thể. Một khóa ngoại là một thực thể trong một bảng tham chiếu đến khoá chính cuả một bảng khác. Nghĩa là, nó là một tham chiếu từ một dòng trong một bảng đến một dòng trong một bảng khác. Liên kết 1-n Với liên kết 1-n, chúng ta có thể thêm một khóa ngoại vào bảng “nhiều” như chỉ ra trong ví dụ dưới đây. Vì một Khoa có thể đảm nhiệm nhiều Môn học nên khóa KhoaID được thêm vào bảng Monhoc. Liên kết n-m Đối với quan hệ nhiều-nhiều, một khóa ngoại là chưa đủ để định danh nhiều thực thể ở mỗi đầu liên kết. Cách giải quyết là sử dụng một bảng kết nối (link table), trong đó mỗi dòng trong bảng liên kết biểu diễn một liên kết giữa một thực thể trong một bảng 52
53. và một thực thể trong bảng khác. Bảng liên kết có khoá chính là hợp của hai khoá ngoại ánh xạ đến đến bảng. Chúng ta có thể sử dụng bảng liên kết để lưu trữ quan hệ một - một, một -nhiều. Quan hệ n-m có thể xem là trường hợp đặc biệt của các lớp liên kết được trình bày tiếp theo sau 4.4. Mô hình hóa cài đặt hệ thống 4.4.1. Giới thiệu • Mô hình là một dạng trừu tượng hóa của một hệ thống thực. • Mô hình là một hình ảnh (một biểu diễn) của một hệ thống thực, được diễn tả: - Ở một mức độ trừu tượng hóa nào đó - Theo một quan điểm (hay một góc nhìn) nào đó - Bởi một hình thức diễn tả hiểu được (văn bản, phương trình, bảng, đồ thị, ) nào đó • Mô hình hóa là việc dùng mô hình để nhận thức và diễn tả một hệ thống • Quá trình phân tích và thiết kế hệ thống là quá trình mô hình hóa hệ thống đó Mục đích • Giúp hiểu và thực hiện được sự trừu tượng hóa, tổng quát hóa các khái niệm cơ sở nhằm giảm thiểu độ phức tạp của hệ thống • Giúp quan sát được hệ thống như nó vốn có và nó phải có • Giúp đặc tả được cấu trúc và hành vi của hệ thống • Giúp tạo khuôn mẫu và hướng dẫn cách xây dựng, thử nghiệm, mô phỏng, thực hiện, hoàn thiện theo mô hình • Là cơ sở để trao đổi Mô hình hóa hệ thống phần mềm • Mô hình hóa hướng chức năng (từ 1970, với Youndon, Constantine, DeMacro, ) lấy chức năng làm đơn vị phân rã hệ thống • Mô hình hóa hướng đối tượng (từ 1990, với Booch, Rumbaugh, Jacobson, Yourdon, ) lấy đối tượng làm đơn vị phân rã hệ thống. 4.4.2. Xây dựng biểu đồ thành phần Xây dựng biểu đồ giao tiếp (Communication diagram) Biểu đồ giao tiếp trong UML là một thể hiện chi tiết của một ca sử dụng bằng một loạt các tương tác theo thứ tự xảy ra giữa các tác nhân và hệ thống và các đối tượng bên trong hệ thống. Do không sử dụng quá nhiều chi tiết kỹ thuật trong giai đoạn đầu của quá trình phát triển, nên biểu đồ giao tiếp thường được sử dụng để mô hình hóa nghiệp vụ. Chuỗi các tương tác trong biểu đồ có thể không hoàn toàn tương ứng với chuỗi các bước trong mô tả chi tiết ca sử dụng. Mỗi tương tác sẽ biểu diễn một cách khái quát về một hoặc nhiều bước. Trong biểu đồ giao tiếp, thông điệp (message) truyền đi giữa các đối tượng được biểu diễn bằng một mũi tên nhỏ, vẽ dọc theo đường kết nối giữa hai đối tượng, với hàm ý rằng nhờ kết nối đó mà bên gửi biết bên nhận để có thể gửi thông điệp đi. Có thể cho rằng thứ tự của các tương tác nên tương ứng một cách chính xác với thứ tự các bước trong chi tiết ca sử dụng. Tuy nhiên, bởi ngôn ngữ tự nhiên không phải là một dãy tuần tự các bước. Do đó, nhiều khả năng mỗi thao tác sẽ mô tả tổng hợp của một hay nhiều bước. Mặc dù không chính xác như ca sử dụng, nhưng biểu đồ giao tiếp 53
54. vẫn là cần thiết bởi vì nó chi tiết hóa hơn các ca sử dụng. Hơn nữa, nó có thể giúp chúng ta có được một cái nhìn đầy đủ và rõ ràng hơn về hệ thống sau này ngay từ giai đoạn đầu phát triển. Vì sự tương tác được đưa ra trong giai đoạn này là không quá phức tạp, nên yêu cầu xây dựng mỗi biểu đồ giao tiếp cho mỗi ca sử dụng là hoàn toàn hợp lý. Để đơn giản, các tương tác trong biểu đồ giao tiếp mà chúng ta mô tả nên là đường đi chuẩn mực (normal path) xuyên suốt ca sử dụng. Sau này, khi đề cập đến ca sử dụng hệ thống, chúng ta có thể cần xác định thêm các đường đi khác thường hay ngoại lệ (normal path). Tuy nhiên, bây giờ chúng ta chỉ cần hiểu sự tồn tại của chúng tương ứng với mỗi ca sử dụng là được. Biểu đồ giao tiếp sinh viên đăng ký môn học Xây dựng biểu đồ hoạt động (Activity diagram) Biểu đồ hoạt động trong UML được sử dụng để chỉ ra sự phụ thuộc giữa các hoạt động khi chuyển từ điểm bắt đầu tới một điểm kế thúc của một tiến trình. Giống như biểu đồ giao tiếp, các hành động trong biểu đồ ho ạt động có thể không tương ứng với từng bước trong mô tả chi tiết của ca sử dụng. Trong thực tế phát triển phần mềm, biểu đồ hoạt động có thể được sử dụng cho nhiều mục đích khác nhau. Ví dụ, biểu đồ hoạt động có thể được sử dụng để xây dựng toàn bộ mô hình nghiệp vụ hoặc viết tài liệu cho một phương thức để thể hiện hành vi của một đối tượng phần mềm. Biểu đồ hoạt động là một đồ thị có hướng, trong đó các nút (đỉnh) là các hoạt động và các cung là các dịch chuyển: - Hoạt động (activity) là một công việc có thể được xử lý bằng tay như Điền mẫu, hoặc bằng máy như Hiển thị màn hình đăng nhập. Một hoạt động được biểu diễn trong biểu đồ bằng một hình chữ nhật tròn góc có mang tên của hoạt động - Chuyển dịch (Transition) là sự chuyển từ hoạt động này sang hoạt động khác được thể hiển bằng một mũi tên nối giữa hai hoạt động. - Nút khởi đầu (start) thể hiển điểm bắt đầu của hoạt động được ký hiệu bởi một hình tròn đặc. 54
55. Nút kết thúc (end) thể hiển điểm kết thúc các hoạt động được ký hiệu hình tròn đặc có viền bao quanh. Tùy trường hợp có thể có một hoặc nhiều nút kết thúc Các điều kiện chuyển dịch hoạt động (transition condition) được ký hiệu bởi một hình thoi để thực hiện sự rẽ nhánh các hoạt động. - Thanh đồng bộ hóa (synchronization bars) để mở hay đóng các nhánh thực hiện song song. XÁC ĐỊNH YÊU CẦU HỆ THỐNG Giai đoạn thứ hai của pha xác định yêu cầu là mô hình hóa yêu cầu hệ thống (system requirement modeling) mà chúng ta định phát triển để cải tiến nghiệp vụ hiện thời của khách hàng. Mô hình hóa yêu cầu hệ thống với ca sử dụng được thể hiện bằng mô hình ca sử dụng (use case model). Cách tiếp cận này đã trở thành quen thuộc trong phát triển phần mềm hướng đối tượng hiện nay và sẽ được sử dụng trong giáo trình này vì nó dễ xây dựng và dễ hiểu đối với mọi người. Mô hình ca sử dụng trong giai đoạn xác định yêu cầu hệ thống sẽ được chi tiết hóa hơn và có tính “kỹ thuật” hơn so với ca sử dụng trong giai đoạn xác định yêu cầu nghiệp vụ đã được trình bày trong mục trước. Xác định yêu cầu hệ thống bao gồm các bước sau đây: 1. Xác định và mô tả các tác nhân 2. Xác định và mô tả các ca sử dụng 3. Xây dựng biểu đồ ca sử dụng 4. Xây dựng kịch bản 5. Xếp ưu tiên các ca sử dụng 6. Phác họa giao diện người dùng Xác định và mô tả các tác nhân Trước hết điều ta cần làm là xác định và mô tả các tác nhân của hệ thống với sự giúp đỡ của khách hàng. Các tác nhân ở đây bao gồm con người hay các hệ thống bên ngoài có tương tác trực tiếp với hệ thống sẽ xây dựng chứ không bao gồm cả các tác nhân gián tiếp như trong giai đoạn xác định yêu cầu nghiệp vụ. Quan hệ giữa các tác nhân 55
56. Các tác nhân trong hệ thống thường có một mối quan hệ nào đó và việc phát hiện các quan hệ này sẽ giúp cung cấp cách nhìn tổng quát về hệ thống. Một tác nhân SA có thể là m ột đặc biệt hóa (specialized actor) của một tác nhân tổng quát khác GA (generalized actor). Khi đó, các tác nhân đặc biệt hóa sẽ kế thừa các hành vi từ các tác nhân tổng quát hóa. Điều này tạo thêm sức mạnh cho mô hình ca sử dụng sau này. Trong UML chúng ta cũng sử dụng ký hiệu tương tự như quan hệ kế thừa giữa các lớp. Hệ quản lý học theo tín chỉ có các nhân Sinh viên, Giảng viên và Nhân viên Phòng đào tạo. Ta có thể tiếp tục đặc biệt hóa Nhân viên Phòng đào tạo thành Nhân viên xếp lịch dạy, Nhân viên nhập điểm, Nhân viên theo dõi tình hình học tâp Hay có thể tổng quát hóa Sinh viên, Giảng viên, Nhân viên thành Thành viên (member). Điều này có thể xem là hơi phức tạp nhưng nó sẽ mang lại nhiều lợi ích hơn. Vì nó đảm bảo rằng bạn hiểu chính xác miền bài toán và khách hàng hy vọng sẽ có được một hệ th ống với những chức năng mà họ thực sự mong muốn. Ví dụ: Hệ thống đăng ký học theo tín chỉ bao gồm các tác nhân sau đây: - Nhân viên: cập nhật (môn học, thông tin về khoa, chuyên ngành, lớp học, điểm thi ), hủy (môn học, chuyên ngành, khoa ) - Sinh viên: xem lịch học, đăng ký học, hủy đăng ký Xác định và mô tả các ca sử dụng Một khi đã có được danh sách các tác nhân, với sự trợ giúp của các khách hàng ta sẽ tiếp tục xác định được sự tương ứng giữa các ca sử dụng với các tác nhân đó. Đồng thời khi đề xuất ca sử dụng, ta phải viết một mô tả ngắn gọn về các ca sử dụng đó. Ví dụ: Một số ca sử dụng của Hệ thống đăng ký học theo tín chỉ: U1 Đăng nhập: các tác nhân đăng nhập hệ thống. U2 Thoát: các tác nhân thoát khỏi hệ thống. U3 Đăng ký học: sinh viên đăng ký các môn học trong kỳ tới. U4 Xem lịch học: sinh viên xem lịch về các lớp học đã đăng ký U5 Xem lịch thi học kỳ: sinh viên xem lịch thi học kỳ các môn đã đăng ký U6 Xem điểm học tập: sinh viên xem kết quả học tập của mình. U7 In bảng điểm: sinh viên in bảng điểm các khóa học của mình. U8 Tìm kiếm thông tin: sinh viên tìm kiếm các môn học của từng khoa, chuyên ngành, hệ đào tạo U9 Xem lịch giảng dạy: giảng viên xem lịch giảng dạy của mình trong kỳ tới. U10 Đổi mật khẩu: người dùng thay đổi mật khẩu truy cập hệ thống. U11 Thay đổi thông tin cá nhân: người dùng thay đổi thông tin cá nhân sau khi đăng nhập hệ thống U12 Quản lý xếp lớp: nhân viên phòng đào tạo thực hiện chức năng phân chia và xếp lớp cho các môn học sinh viên đăng ký U13 Quản lý điểm sinh viên: nhân viên phòng đào tạo cập nhật kết quả điểm của sinh viên U14 Gửi thông báo: phòng đào tạo gửi các thông báo tới sinh viên. U15 Xem thông báo: giảng viên, sinh viên xem các thông báo của phòng đào tạo 56
57. 4.4.3. Xây dựng biểu đồ triển khai Giữa các ca sử dụng có ba kiểu quan hệ sau đây: đặc biệt hóa, bao hàm và mở rộng. Chúng cho phép nhóm các ca sử dụng có liên quan, phân rã các ca sử dụng, sử dụng lại hành vi và xác định hành vi không bắt buộc • Đặc biệt hóa (Specialize): giống như tác nhân, một ca sử dụng có thể kế thừa (inherit) từ một ca sử dụng khác. Để tránh những phức tạp liên quan đến việc định nghĩa lại các bước và thêm các bước phụ, ta có thể đặc biệt hóa các ca sử dụng trừu tượng (abstract use case). Ca sử dụng trừu tượng là ca sử dụng không có bước nào, nhiệm vụ của nó là nhóm một số ca sử dụng lại với nhau. Bao hàm (Include): một ca sử dụng UC1 có một số bước được cung cấp bởi một ca sử dụng khác UC2 thì ta nói UC1 bao hàm UC2. Khi đó, UC1 gọi là ca sử dụng nguồn và UC2 gọi là ca sử dụng đích. Quan hệ bao hàm được dùng để rút ra các bước chung cho một số ca sử dụng, hoặc để chia ca sử dụng lớn thành các ca sử dụng nhỏ hơn. • Mở rộng (Extend): một ca sử dụng UC1 thêm thông tin vào một ca sử dụng khác UC2 thì UC1 được gọi là mở rộng của UC2. Thông thường các thông tin đó xuất hiện ở cuối ca sử dụng nhưng chúng cũng có thể xảy ra ở đầu hoặc đôi khi là ở giữa. Có một sự khác biệt cơ bản giữa bao hàm và mở rộng. Với bao gồm, ca sử dụng nguồn sẽ không hoạt động nếu không có ca sử dụng đích, với mở rộng, ca sử dùng nguồn sẽ làm việc tốt kể cả không có ca sử dụng đích. Nói cách khác, ca sử dụng được bao gồm có sự tồn tại độc lập, còn ca sử dụng mở rộng chỉ tồn tại như là một mở rộng. Thực tế khó xác định chính xác quan hệ giữa các ca sử dụng trong lần đầu tiên qua mô hình yêu cầu hệ thống. Hơn nữa, việc xác định quan hệ này phụ thuộc vào chúng ta quyết định xem cái gì là thực sự cần thiết và khách hàng của chúng ta chấp nhận nó hay không. Trong cách tiếp cận hướng đối tượng, có nhiều cách phân tích ca sử dụng thành các mối quan hệ bao hàm, mở rộng hay kế thừa. • Đặc biệt hóa: Có thể nhận thấy trong biểu đồ ca sử dụng ví dụ Biểu đồ phân rã ca sử dụng Quản lý xếp lớp, ca sử dụng Quản lý xếp lớp được phân rã thành các ca sử dụng: 57
58. Quản lý Đăng ký học, Quản lý phân lớp, Lập lịch dạy trong biểu đồ ca sử dụng phân rã. Trong khi đó ca sử dụng Quản lý xếp lớp là ca sử dụng trừu tượng, nó có nhiệm vụ chính là nhóm các ca sử dụng Quản lý Đăng ký học, Quản lý phân lớp, Lập lịch thành một ca sử dụng trừu tượng trong biểu đồ ca sử dụng. Khi phân rã ca sử dụng, Quản lý xếp lớp được xem là đã được đặt biệt hóa. • Bao hàm: Ca sử dụng Xem danh sách đăng ký môn học, Chuyển lớp sinh viên trước khi thực hiện phải bao gồm thao tác tìm kiếm thông tin cần thiết. Do đó, các ca sử dụng này bao gồm > ca sử dụng Tìm kiếm thông tin. • Mở rộng: Các ca sử dụng Đăng ký môn học, Xem thời khóa biểu, Xem điểm học tập là mở rộng của ca sử dụng Đăng nhập. Người dùng sẽ không thể thực hiện các chức năng đó nếu ca sử dụng Đăng nhập chưa được thực hiện BÀI TẬP 1. Xây dựng biểu đồ lớp thiết kế từ biểu đồ lớp phân tích cho hệ quản lý học tín chỉ 2. Sử dụng các công nghệ có sẵn để thiết kế các giao diện của hệ quản lý học tín chỉ 3. Trình bày các bước thiết kế chi tiết cho Hệ quản lý thư viện 4. Trình bày các bước thiết kế chi tiết cho Hệ quản lý bán hàn Biểu đồ phân rã ca sử dụng Quản lý xếp lớp Tiền điều kiện (preconditions), Hậu điều kiện (postconditions) Khi xem xét sự kế thừa giữa các ca sử dụng, ta cũng phải quan tâm đến việc đặc biệt hóa có ảnh hưởng gì đến điều kiện trước và điều kiện sau không. Mặc dù các ca sử dụng chỉ kế thừa từ ca sử dụng trừu tượng nhưng chúng vẫn có điều kiện trước và điều kiện sau. Sau đây là một số quy tắc: 1.Khi một ca sử dụng cụ thể hóa một ca sử dụng khác, nó kế thừa các tiền điều kiện của ca sử dụng cha như là một điểm khởi đầu. Bất cứ tiền điều kiện nào của ca sử dung con phải làm yếu đi tiền điều kiện ca sử dụng cha, nghĩa là chúng được kết hợp với các điều kiện trước của ca sử dụng con bởi phép toán “hoặc”. 2.Với các hậu điều kiện, điểm khởi đầu của ca sử dụng con là hậu điều kiện của ca sử dụng cha. Các hậu điều kiện mà ca sử dụng con thêm vào phải làm mạnh ca sử dụng cha, nghĩa là nó sẽ kết hợp với hậu điều kiện của ca sử dụng cha bằng phép toán “và”. 58