Công Nghệ Thông Tin, it, phầm mềm, website, web, mobile app, trí tuệ nhân tạo, blockchain, AI, machine learning - Công Nghệ Thông Tin, it, phầm mềm, website, web, mobile app, trí tuệ nhân tạo, blockchain, AI, machine learning - Công nghệ thông tin UBND TỈNH QUẢNG NAM TRƯỜNG ĐẠI HỌC QUẢNG NAM KHOA CÔNG NGHỆ THÔNG TIN ---------- KHÓA LUẬN TỐT NGHIỆP XÂY DỰNG PHẦN MỀM QUẢN LÝ ĐOÀN VIÊN TRƯỜNG ĐẠI HỌC QUẢNG NAM THEO PHƯƠNG PHÁP PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG VỚI UML. Sinh viên thực hiện PHẠM THỊ KIM YẾN MSSV: 2112011039 CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN KHÓA: 2012 – 2016 Cán bộ hướng dẫn ThS. TRẦN THỊ DIỆU HIỀN Quảng Nam, tháng 04 năm 2015 MỤC LỤC Phần 1. MỞ ĐẦU ............................................................................................................................ 1 1.1. Lý do chọn đề tài .................................................................................................................. 1 1.2. Mục tiêu của đề tài................................................................................................................ 1 1.3. Đối tượng và phạm vi nghiên cứu ........................................................................................ 1 1.4. Phương pháp nghiên cứu ...................................................................................................... 2 1.5. Lịch sử nghiên cứu ............................................................................................................... 2 1.6 Đóng góp của đề tài ............................................................................................................... 2 1.7 Cấu trúc đề tài ........................................................................................................................ 2 Phần 2. NỘI DUNG NGHIÊN CỨU .............................................................................................. 3 CHƯƠNG 1: TỔNG QUAN VỀ PHÂN TÍCH THIẾT KẾHƯỚNG ĐỐI TƯỢNG...................... 3 1.1. Cơ bản về phân tích, thiết kế hướng đối tượng. ................................................................... 3 1.1.1. Khái niệm về Phân tích và thiết kế hướng đối tượng (Object Oriented Analysis and Design: OOAD) ....................................................................................................................... 3 1.1.2. Giới thiệuvề UML (Unified Modeling Language) ........................................................ 3 1.1.3. Tại sao phải sử dụng OOAD và UML? ........................................................................ 3 1.1.4. OOAD sử dụng UML .................................................................................................... 3 1.2. Mục đích của mô hình hướng đối tượng .............................................................................. 4 1.3. Sử dụng UML để phát triển phần mềm thống nhất .............................................................. 4 1.4. Các biểu đồ (Diagram): ........................................................................................................ 6 CHƯƠNG 2: CÁC MÔ HÌNH TRONG PHÂN TÍCH THIẾT KẾHƯỚNG ĐỐI TƯỢNG .......... 9 2.1. Use case (Ca sử dụng: UC)................................................................................................... 9 2.2. Đặc tả use case.................................................................................................................... 14 2.3. Biểu đồ UC ......................................................................................................................... 16 2.4. Mô hình hóa Use Case. ....................................................................................................... 19 2.5. Mô hình đối tượng và tương tác đối tượng ......................................................................... 22 2.5.1. Mô hình đối tượng ....................................................................................................... 22 2.5.2. Biểu đồ tương tác đối tượng ........................................................................................ 22 2.6. Biểu đồ lớp ......................................................................................................................... 25 2.6.1. Cách tìm lớp. ............................................................................................................... 25 2.6.2. Các kiểu lớp ................................................................................................................. 26 2.7. Mô hình biểu đồ trạng thái và biểu đồ hoạt động ............................................................... 28 2.7.1. Mô hình biểu đồ trạng thái .......................................................................................... 28 2.7.2.Mô hình biểu đồ hoạt động ........................................................................................... 29 2.8. Mô hình biểu đồ kiến trúc vật lý và phát sinh mã trình ...................................................... 30 2.8.1. Mô hình biểu đồ thành phần ........................................................................................ 30 2.8.2. Mô hình biểu đồ triển khai .......................................................................................... 30 CHƯƠNG 3: BÀI TOÁN ỨNG DỤNG: QUẢN LÝ ĐOÀN VIÊN TRƯỜNG ĐẠI HỌC QUẢNG NAM .............................................................................................................................. 33 3.1. Phân tích và xây dựng bài toán ........................................................................................... 33 3.1.1. Định nghĩa bài toán ..................................................................................................... 33 3.1.2. Yêu cầu phi chức năng của bài toán ............................................................................ 33 3.1.3. Yêu cầu chức năng của hệ thống. ................................................................................ 35 3.2. Phân tích hệ thống .............................................................................................................. 36 3.2.1. Biểu đồ ca sử dụng ...................................................................................................... 36 3.2.2. Biểu đồ cộng tác .......................................................................................................... 46 3.2.3. Biểu đồ lớp. ................................................................................................................. 54 3.2.4. Biểu đồ trạng thái ........................................................................................................ 59 3.2.5. Biểu đồ thành phần và biểu đồ triển khai. ................................................................... 62 3.3. Chương trình demo ............................................................................................................. 64 3.3.1. Form: Đăng nhập ......................................................................................................... 64 3.3.2. Form: Main .................................................................................................................. 64 3.3.3. From: Đoàn viên .......................................................................................................... 65 3.3.4. In danh sách đoàn viên theo chi đoàn. ......................................................................... 65 3.3.5. Form: Thu đoàn phí ..................................................................................................... 66 3.3.6. Form: Hoạt động.......................................................................................................... 67 3.3.7. Form: Danh sách đoàn viên tham gia hoạt động ......................................................... 67 3.3.8. Form: Ngân hàng máu sống ........................................................................................ 68 3.3.9. Form: Hiển thị thông tin của đoàn viên hiến máu ....................................................... 68 3.3.10. Form: đổi mật khẩu ................................................................................................... 69 3.3.11. Form thống kê đoàn phí ............................................................................................. 69 3.4. Kiểm tra thử hoạt động của hệ thống đối chiếu với sơ đồ UC ........................................... 70 Phần 3. KẾT LUẬN VÀ KIẾN NGHỊ .......................................................................................... 71 1. Kết luận ................................................................................................................................. 71 2. Kiến nghị ............................................................................................................................... 71 Phần 4. Tài liệu tham khảo ............................................................................................................ 72 GIẢNG VIÊN HƯỚNG DẪN ...................................................................................................... 73 DANH MỤC BIỂU MẪU,HÌNH ẢNH Hình 1.1: Các bản vẽ trong OOAD sử dụng UML .......................................................................... 6 Hình 1.2: Các View trong OOAD sử dụng UML............................................................................ 8 Hình 2.1: Ký hiệu của ca sử dụng ................................................................................................... 9 Hình 2.2: Biểu tượng tác nhân trong UML ................................................................................... 14 Hình 2.3: Sơ đồ cộng tác cập nhập đoàn viên ............................................................................... 24 Hình 2.4: Biểu đồ trạng thái lớp đoàn viên ................................................................................... 29 Hình 3.1: Sơ đồ Use Case tổng quát cho quản lý đoàn viên ......................................................... 45 Hình 3.2: Biểu đồ tuần tự cho sa sử dụng đăng nhập .................................................................... 50 Hình 3.3. Biểu đồ tuần tự cho ca sử dụng Cập nhập đoàn viên .................................................... 50 Hình 3.4. Biểu đồ tuần tự cho ca sử dụng Cập nhập đoàn phí ...................................................... 51 Hình 3.5. Biểu đồ tuần tự cho ca sử dụng Cập nhập chi đoàn ...................................................... 51 Hình 3.6. Biểu đồ tuần tự cho ca sử dụng Ngân hàng máu sống .................................................. 52 Hình 3.7. Biểu đồ tuần tự cho ca sử dụng Cập nhập hoạt động đoàn ........................................... 52 Hình 3.8. Biểu đồ tuần tự cho ca sử dụng Tìm kiếm ..................................................................... 53 Hình 3.9. Biểu đồ tuần tự cho ca sử dụng Thống kê ..................................................................... 53 Hình 3.10. Biểu đồ lớp .................................................................................................................. 55 Hình 3.11. Biểu đồ trạng thái cho lớp đăng nhập .......................................................................... 59 Hình 3.12. Biểu đồ trạng thái cho lớp chi đoàn ............................................................................. 60 Hình 3.13. Biểu đồ trạng thái cho lớp đoàn viên ........................................................................... 60 Hình 3.14. Biểu đồ trạng thái cho lớp thu đoàn phí ...................................................................... 61 Hình 3.15. Biểu đồ trạng thái cho lớp ngân hàng máu sống ......................................................... 61 Hình 3.16. Biểu đồ thành phần ...................................................................................................... 62 Hình 3.17. Biểu đồ triển khai ........................................................................................................ 63 Hình 3.18. From đăng nhập .......................................................................................................... 64 Hình 3.19. Form Main ................................................................................................................... 64 Hình 3.20. Form đoàn viên ............................................................................................................ 65 Hình 3.21. Form in đoàn viên theo chi đoàn ................................................................................. 65 Hình 3.22. Form hóa đơn thu tiền đoàn phí................................................................................... 66 Hình 3.23. Form hoạt động đoàn ................................................................................................... 67 Hình 3.24. Form đoàn viên tham gia tình nguyện ......................................................................... 67 Hình 3.25. Form hiến máu ............................................................................................................. 68 Hình 3.26. Form in danh sách đoàn viên hiến máu ....................................................................... 68 Hình 3.27. Form đổi mật khẩu....................................................................................................... 69 Hình 3.28. Form thống kê đoàn phí ............................................................................................... 69 DANH MỤC TỪ VIẾT TẮC C: controler DN: Đăng nhập DP: Đoàn phí OOAD: Object Oriented Analysis and Design HM: Hiến máu HDD: Hoạt động đoàn HSCD: Hồ sơ chi đoàn HSDV: Hồ sơ đoàn viên I: Interface NQL: Người quản lý QL: Quản lý QLCD: Quản lý chi đoàn QLDV: Quản lý đoàn viên QLHDD: Quản lý hoạt động đoàn TK: Thống kê TKCD: Tìm kiếm chi đoàn TKDV: Tìm kiếm đoàn viên UC: use case UML: Unified Modeling Language UP: quá trình hợp nhất USPD: quá trình phát triển phần mềm hợp nhất LỜI CẢM ƠN Lời đầu tiên em xin chân thành cảm ơn sự hướng dẫn và giúp đỡ tận tình của cô Trần Thị Diệu Hiền, giảng viên khoa Công nghệ thông tin trường đại học Quảng Nam . Trong suốt thời gian thực hiện khóa luận tốt nghiệp, mặc dù rất bận rộn trong công việc nhưng cô vẫn dành rất nhiều thời gian và tâm huyết trong việc hướng dẫn em. Cô đã cung cấp cho em rất nhiều hiểu biết về lĩnh vực mới khi em mới bắt đầu bước vào thực hiện khóa luận. Trong quá trình thực hiện khóa luận này, cô luôn định hướng, góp ý và sửa chữa những chỗ sai giúp em không bị lạc lối trong biển kiến thức rộng lớn. Cho đến hôm nay, khóa luận tốt nghiệp của em đã được hoàn thành, cũng nhờ sự nhắc nhở, đôn đốc, sự giúp đỡ nhiệt tình của cô. Em xin chân thành cảm ơn các thầy cô và bạn bè trong khoa Công nghệ thông tin đã giúp đỡ để bài khóa luận của em được hoàn chỉnh hơn. Tuy nhiên, do thời gian có hạn cũng như kiến thức còn non yếu, đề tài khóa luận cũng không tránh khỏi những thiếu sót nhất định. Mong nhận được sự đóng góp của quý thầy cô và bạn đọc để khóa luận được hoàn thiện hơn. Em xin chân thành cảm ơn Sinh viên thực hiện Phạm Thị Kim Yến Trang 1 Phần 1. MỞ ĐẦU 1.1. Lý do chọn đề tài - Phân tích thiết kế hệ thống hướng đối tượng là môn học được đào tạo ở hầu hết các trường đạihọc cho sinh viên theo học các chuyên ngành công nghệ thông tin, đặc biệt là đối với chuyên ngành hệ thống thông tin và công nghệ phần mềm. Môn học trang bị cho sinh viên những kiến thức nền tảng về các giai đoạn phân tích thiết kế trong một dự án công nghệ phần mềm cũng như là cách thức thực hiện và triển khai một dự án cụ thể như thế nào,… Từ đó giúp sinh viên có cách nhìn rộng mở hơn về vai trò cực kì quan trọng của việc phân tích thiết kế khi phát triển phần mềm. Bên cạnh đó, để tìm hiểu và viết được một phần mềm thì trước tiên ta phải hiểu về các mô hình trong phân tích thiết kế hướng đối tượng. - Hiện nay việc sử dụng tin học phục vụ trong nhà trường đã được áp dụng rất nhiều. Hầu hết tất cả các trường đại học đều sử dụng tin học trong các công tác quản lý. Công tác quản lý trong môi trường giáo dục bao gồm rất nhiều mặt như quản lý:hồ sơ sinh viên, điểm, học phí, hồ sơ đoàn viên, ... - Đối với trường đại học Quảng Nam khi số lượng đoàn viên của đoàn trường ngày càng tăng cao, lượng thông tin lưu trữ sẽ rất lớn, khó khăn trong việc tra cứu thông tin là tất yếu và thông tin không được chính xác là một điều khó tránh khỏi. Vì thế em chọn đề tài “ Xây dựng phần mềm quản lý đoàn viên trường đại học Quảng Nam theo phương pháp phân tích thiết kế hướng đối tượng với UML” làm đề tài của mình, với mong muốn giúp cho hoạt động quản lý đoàn viên của cán bộ đoàn trường một cách có hiệu quả và chính xác hơn trong công tác quản lí đoàn sinh viên trường đại Quảng Nam. 1.2. Mục tiêu của đề tài - Ôn lại kiến thức đã học các môn : C, Sql server, cơ sở dữ liệu, cấu trúc dữ liệu và giải thuật, ... - Tìm kiếm tư liệu thực tế xây dựng phần mềm. - Nghiên cứu sâu, trải nghiệm thực tế để xây dựng chương trình. 1.3. Đối tượng và phạm vi nghiên cứu - Nghiên cứu lý thuyết về phân tích thiết kế hướng đối tượng. - Nghiên cứu cách vẽ các biểu đồ trong phần mềm Rational Rose. Trang 2 - Nghiên cứu ngôn ngữ lập trình C, SQL 2008. - Xây dựng phần mềm quản lý đoàn viên của trường đại học Quảng Nam. 1.4. Phương pháp nghiên cứu - Tìm kiếm tài liệu liên quan đến phân tích thiết kế hướng đối tượng ở trường, thư viện, Internet, … - Đọc tài liệu, chọn những công cụ cần thiết cho việc xây dựng phần mềm - Phương pháp nghiên cứu lí thuyết. - Sử dụng phương pháp thu thập thông tin và tổng hợp, phân tích dựa trên lí thuyết use case. 1.5. Lịch sử nghiên cứu - Nội dung đã được đề cập ở môn học và được nhiều tác giả nghiên cứu, tuy nhiên để nâng cao kiến thức của bản thân tôiđi vào tìm hiểu các mô hình của phân tích thiết kế hướng đối tượng. 1.6 Đóng góp của đề tài - Hệ thống lại các kiến thức đã học về phân tích thiết kế hướng đối tượng, cơ sở dữ liệu sql, C, ... - Xây dựng được phần mềm quản lý đoàn viên cho trường đại học Quảng Nam. 1.7 Cấu trúc đề tài Với đề tài này, tôi dự định sẽ chia làm 3 chương: Chương 1: Tổng quan về phân tích thiết kế. Chương 2: Các mô hình trong phân tích thiết kế hướng đối tượng Chương 3: Bài toán ứng dụng: Quản lý đoàn viên trường đại học Quảng Nam Trang 3 Phần 2. NỘI DUNG NGHIÊN CỨU CHƯƠNG 1: TỔNG QUAN VỀ PHÂN TÍCH THIẾT KẾHƯỚNG ĐỐI TƯỢNG 1.1. Cơ bản về phân tích, thiết kế hướng đối tượng. 1.1.1. 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, 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) 1.1.2. Giới thiệuvề 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..) 1.1.3. Tại sao phải sử dụng 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,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. 1.1.4. OOAD sử dụng UML Trang 4 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.v.... Phân tích thiết kế hướng đối tượng 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ế) 1.2. Mục đích của mô hình hướng đối tượng Mô hình được các hệ thống (không chỉ hệ thống phần mềm) và sử dụng được tất cả các khái niệm hướng đối tượng một cách thống nhất. Cho phép đặc tả, hỗ trợ để đặc tả tường minh (trực quan) mối quan hệ giữa các khái niệm cơ bản trong hệ thống, đồng thời mô tả được mọi trạng thái hoạt động của hệ thống đối tượng. Nghĩa là cho phép mô tả được cả mô hình tĩnh lẫn mô hình động một cách đầy đủ và trực quan. Tận dụng được những khả năng sử dụng lại và kế thừa ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp và nhạy cảm như: các hệ thống động, hệ thống thời gian thực, hệ thống nhúng thời gian thực, v.v. Tóm lại,UMLsử dụng vẽ các biểu đồ trên là ngôn ngữ mô hình hoá, ngôn ngữ đặc tả và ngôn ngữ xây dựng mô hình trong quá trình phát triển phần mềm, đặc biệt là trong phân tích và thiết kế hệ thống hướng đối tượng. UML là ngôn ngữ hình thức, thống nhất và chuẩn hoá mô hìnhhệ thống một cách trực quan. Nghĩa là các thành phần trong mô hình được thể hiện bởicác ký hiệu đồ hoạ, biểu đồ và thể hiện đầy đủ mối quan hệ giữa chúng một cách thống nhất và có logic chặt chẽ. 1.3. Sử dụng UML để phát triển phần mềm thống nhất UML được phát triển để đặc tả quá trình phát triển phần mềm, nhằm mô hình hoá hệ thống. Quá trình phát triển phần mềm này gọi là quá trình phát triển phần mềm hợp nhất (USPD) hay quá trình hợp nhất Rational, gọi tắt là quá trình hợp nhất (UP). RUP là tập các qui tắc hướng dẫn về phương diện kỹ thuật và tổ chức để phát triển phần mềm, nhấn mạnh chủ yếu vào các bước phân tích và thiết kế. RUP được cấu trúc theo hai chiều: Trang 5 1. Chiều thời gian: chia quá trình thành các pha thực hiện và các bước lặp. 2. Chiều thành phần: các sản phẩm cùng với các hoạt động được xác định đầy đủ. 1. Cấu trúc dự án theo chiều thời gian bao gồm các pha thực hiện: (i)Khởi động (Inception): xác định dự án tổng thể (ii) Soạn thảo dự án tỉ mỉ (Elaboration): + Lập kế hoặch cho những hoạt động cần thiết + Xác định những tài nguyên cần để thực hiện dự án + Xác định các tính chất, đặc trưng của dự án + Xây dựng kiến trúc cho hệ thống. (iii) Xác định những sản phẩm ở mỗi pha thực hiện. (iv) Chuyển giao: cung cấp sản phẩm cho cộng đồng người sử dụng. 2. Cấu trúc dự án theo chiều thành phần bao gồm các hoạt động: Mô hình hoá nghiệp vụ: thiết lập các khả năng của hệ thống cần xây dựng và nhu cầu của người sử dụng. Phân tích các yêu cầu: chi tiết các yêu cầu chức năng và phi chức năng của hệ thống. Phân tích thiết kế hệ thống: mô tả hệ thống thực hiện các yêu cầu và hỗ trợ cài đặt. Cài đặt chương trình: lập trình những kết quả thiết kế nêu trên để hệ thống hoạt động đúng theo yêu cầu. Kiểm thử, kiểm chứng các thành phần và toàn bộ hệ thống. Triển khai hệ thống: khai thác hệ thống và huấn luyện người sử dụng. UP bao gồm con người, dự án, sản phẩm, qui trình và công cụ. Con người là những người tham gia dự án để tạo ra sản phẩm phần mềm theo một quá trình với sự hỗ trợ của công cụ được cung cấp. UP là quá trình phát triển phần mềm được hướng dẫn bởi các ca sử dụng. Nghĩa là các yêu cầu của người sử dụng được mô tả trong các ca sử dụng, là chuỗi các hành động được thực hiện bởi hệ thống nhằm cung cấp các dịch vụ, các thông tin cho khách hàng. Các ca sử dụng bao gồm chuỗi các công việc được xem là nền tảng để tạo ra mô hình thiết kế và cài đặt hệ thống. UP cũng là qui trình tập trung vào kiến trúc, được lặp và phát triển tăng trưởng liên tục. Kiến trúc của hệ thống phải được thiết kế nhằm đáp ứng các yêu cầu của cácca sử Trang 6 dụng chính, trong giới hạn của chuẩn phần cứng mà hệ thống sẽ chạy và của cấu trúc cả hệ thống lẫn các hệ thống con. Tính lặp của quá trình phát triển phần mềm được thể hiện ở chỗ là một dự án được chia thành các dự án nhỏ và được thực hiện lặplại trong từng bước thực hiện. Mỗi dự án nhỏ đều thực hiện phân tích, thiết kế, cài đặtvà kiểm thử, v.v... Mỗi phần việc đó được phát triển tăng trưởng và cả dự án cũng được thực hiện theo sự tăng trưởng này. UP không chỉ tạo ra một hệ thống phần mềm hoàn chỉnh mà còn tạo ra một số sản phẩm trung gian như các mô hình. Các mô hình chính trong UP là mô hình nghiệp vụ (ca sử dụng), mô hình khái niệm, mô hình thiết kế, mô hình triển khai và mô hình trắc nghiệm. Các mô hình này có sự phụ thuộc theo vết phát triển, nghĩa là có thể lần theo từng mô hình để đến được mô hình trước. 1.4. Các biểu đồ (Diagram): Diagram các bạn có thể dịch là sơ đồ. Tuy nhiên ở đây chúng ta sử dụng từ bản vẽ cho dễ hình dung. Các bản vẽ được dùng để thể hiện các góc nhìn của hệ thống. Hình 1.1: Các bản vẽ trong OOAD sử dụng UML Trong đó, – Biểu đồ ca sử dụng ( 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. Trang 7 – Biểu đồ lớp (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. – Biểu đồ đối tượng(Object Diagram): Tương tự như Class Diagram nhưng nó mô tả đến đối tượng thay vì lớp (Class). – Biểu đồ trình tự (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. – Biểu đồ cộng tác (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. – Biểu đồ trạng thái (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. – Biểu đồ hoạt độ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. – Biểu đồ thành phần (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 đó. – Biểu đồ triển khai (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… Các quan sát ( Các kiểu xem) Khi xem xét một hệ thống, chúng ta cần xây dựng mô hình từ những hướng nhìn (View- khía cạnh) khác nhau, xuất phát từ thực tế là những người làm việc với hệ thống, với các vai trò khác nhau sẽ nhìn hệ thống từ những khía cạnh khác nhau. UML xét hệ thống trên 5 khía cạnh: Trang 8 Hình 1.2: Các View trong OOAD sử dụng UML Trong đó, – Use Case View : cung cấp góc nhìn về các ca sử dụng giúp chúng ta hiểu hệ thống có gì? ai dùng và dùng nó như thế nào. – Logical View : cung cấp góc nhìn về cấu trúc hệ thống, xem nó được tổ chức như thế nào. Bên trong nó có gì. – Process View: cung cấp góc nhìn động về hệ thống, xem các thành phần trong hệ thống tương tác với nhau như thế nào. – Component View: Cũng là một góc nhìn về cấu trúc giúp chúng ta hiểu cách phân bổ và sử dụng lại các thành phần trong hệ thống ra sao. – Deployment View : cung cấp góc nhìn về triển khai hệ thống, nó cũng ảnh hưởng lớn đến kiến trúc hệ thống. Tập hợp các góc nhìn này sẽ giúp chúng ta hiểu rõ hệ thống cần phân tích, thiết kế. Trong hình 1.2 chúng ta thấy góc nhìn Use Case View nằm ở giữa và chi phối tất cả các góc nhìn còn lại. Chính vì thế chúng ta thường thấy các tài liệu nói về 4 view + 1 chứ không phải 5 view nhằm nhấn mạnh vai trò của Use Case View. Trang 9 CHƯƠNG 2: CÁC MÔ HÌNH TRONG PHÂN TÍCH THIẾT KẾHƯỚNG ĐỐI TƯỢNG 2.1. Use case (Ca sử dụng: UC) Ca sử dụng Khái niệm ca sử dụng hay trường hợp sử dụng (Use-case) được Ivan Jacobson đề xuất năm 1994 nhằm mô tả các dịch vụ của hệ thống cho khách hàng và xác định mối quan hệ tương tác giữa hệ thống phần mềm với người sử dụng trong nghiệp vụ. Một cách hệ thống hơn, ca sử dụng mô tả tập các hoạt động của hệ thống theo quan điểm của các tác nhân (Actor). Nó mô tả các yêu cầu của hệ thống và trả lời cho câu hỏi: Hệ thống phải làm cái gì? (What?) Ca sử dụng mô tả một quá trình bắt đầu cho đến khi kết thúc, gồm dãy các thao tác, các giao dịch cần thiết để sản sinh ra cái gì đó (giá trị, thông tin) theo yêu cầu của một tổ chức, của tác nhân,... Ca sử dụng được kí hiệu là: Hoạt động Hoạt động Trong đó “Hoạt động” là các chức năng, nhiệm vụ hay gọi chung là dịch vụ của hệ thống và nó thường được mô tả bằng các động từ hay mệnh đề động từ đơn. Ví dụ: đăng nhập, cập nhập, thanh toán, ... Những ca sử dụng phức tạp sẽ được mô tả chi tiết thông qua các kịch bản. Mục tiêu của ca sử dụng Mục tiêu của ca sử dụng trong cả quá trình phát triển phần mềm: Mô tả các yêu cầu chức năng của hệ thống, là kết quả của quá trình khảo sát, nghiên cứu các yêu cầu của bài toán và những thỏa thuận giữa khách hàng, người sử dụng hệ thống với người phát triển phần mềm. Làm cơ sở để người phân tích viên hiểu, người thiết kế xây dựng các kiến trúc, người lập trình cài đặt các chức năng của hệ thống. Hình 2.1: Ký hiệu của ca sử dụng Trang 10 Sự cần thiết phải có UC Use Case là một công cụ để khuyến khích những người dùng tiềm năng nói về hệ thống từ hướng nhìn của họ. Đối với người dùng, chẳng phải bao giờ việc thể hiện và mô tả những ý định trong việc sử dụng hệ thống cũng là chuyện dễ dàng. Một hiện thực có thật là người sử dụng thường biết nhiều hơn những gì mà họ có thể diễn tả ra: Công cụ Use Case sẽ giúp cho nhóm phát triển phần mềm hiểu rõ hơn, ngoài ra một sự trình bày trực quan cũng cho phép bạn kết hợp các biểu đồ Use Case với các loại biểu đồ khác. Sáng kiến chủ đạo là lôi cuốn được người dùng tham gia vào những giai đoạn đầu tiên của quá trình phân tích và thiết kế hệ thống. Việc này sẽ nâng cao xác suất cho việc hệ thống chung cuộc trở thành một công cụ quen thuộc đối với các người dùng mà nó dự định sẽ trợ giúp – thay vì là một tập hợp khó hiểu và rối rắm của các khái niệm máy tínhmà người dùng trong giới doanh thương có cảm giác không bao giờ hiểu được và không thể làm việc cùng. Công tác lôi kéo người sử dụng tham gia tích cực vào quá trình phân tích là nền tảng quan trọng cho việc tạo dựng một mô hình "thành công", một mô hình dễ được người sử dụng hiểu và chấp nhận sau khi đã thẩm xác các nhiệm vụ căn bản. Ngoài ra, Use Case còn giúp nhóm phát triển quyết định các lớp mà hệ thống phải triển khai. Ca sử dụng là gì? Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận được. Một Use Case trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể. Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống. Các tính chất tiêu biểu của một Use Case là: - Một Use Case bao giờ cũng được gây ra bởi một tác nhân, được thực hiện nhân danh một tác nhân nào đó. Tác nhân phải ra lệnh cho hệ thống để thực hiện Use Case đó, dù là trực tiếp hay gián tiếp. Hiếm khi có tác nhân không liên quan đến việc gây ra một Use Case nào đó. Trang 11 - Một Use Case phải cung cấp một giá trị cho một tác nhân. Giá trị đó không phải bao giờ cũng cần thiết phải nổi trội ra ngoài, nhưng luôn phải được thấy rõ. - Một Use Case là phải hoàn tất. Một trong những lỗi thường gặp là sẻ chia một Use Case thành các Use Case nhỏ hơn, và các Use Case này thực thi lẫn nhau giống như việc gọi hàm cho một ngôn ngữ lập trình. Một Use Case sẽ không được coi là hoàn tất chừng nào mà giá trị cuối cùng của nó chưa được sản sinh ra, thậm chí ngay cả khi đã xảy ra nhiều động tác giao tiếp (ví dụ như đối thoại với người sử dụng). Use Case được nối với tác nhân qua liên kết (association). Đường liên kết chỉ ra những tác nhân nào giao tiếp với Use Case nào. Mối liên kết bình thường ra là một mối quan hệ 1-1 và không có hướng. Điều đó muốn nói lên rằng một thực thể của lớp tác nhân sẽ giao tiếp với một thực thể của một Use Case và cả hai có thể giao tiếp với nhau trong cả hai chiều. Một Use Case sẽ được đặt tên theo một thực thể mà Use Case sẽ thực hiện, ví dụ như tìm kiếm, hóa đơn, cập nhật danh sách, v.v…, và thường là một cụm từ hơn là chỉ một từ riêng lẻ. Cách tìm ca sử dụng Quá trình tìm các Use Case bắt đầu với các tác nhân đã được xác định ở phần trước. Đối với mỗi tác nhân, hãy hỏi các câu hỏi sau: a . Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính của tác nhân là gì ?. Ví dụ: Đăng nhập vào hệ thống phần mềm quản lí đoàn viên, các hành động chính của người quản lý (tác nhân) có thể là : - Khởi động hệ thống. - Nhập tên, pass word. - Nếu đúng thì cho phép sử dụng phần mềm. - Nếu sai, thì yêu cầu người quản lý nhập lại tên hoặc pass word. b . Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa chữa, hay là lưu trữ một loại thông tin nào đó trong hệ thống? Ví dụ : - Người quản lý có thể thay đổi pass word . - Người quản lý có thể đăng kí thêm người dùng mới. Trang 12 c . Tác nhân có cần phải báo cho hệ thống biết về những sự kiện nào đó? Những sự kiện như thế sẽ đại diện cho những chức năng nào? d . Hệ thống có cần phải thông báo cho Actor về những thay đổi bất ngờ trong nội bộ hệ thống? e . Công việc hàng ngày của tác nhân có thể được đơn giản hóa hoặc hữu hiệu hóa qua các chức năng mới trong hệ thống (thường đây là những chức năng tiêu biểu chưa được tự động hóa trong hệ thống)? Một Use Case bao giờ cũng phải được liên kết với ít nhất một tác nhân. Use Case là một công cụ trợ giúp cho công việc của nhà phân tích cùng người sử dụng quyết định tính năng của hệ thống. Tác nhân là gì? Tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống.Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn nói rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các thông tin cùng với hệ thống. Nói một cách ngắn gọn, tác nhân thực hiện các Use Case. Một tác nhân là một dạng thực thể (một lớp), chứ không phải một thực thể. Một tác nhân giao tiếp với hệ thống bằng cách gửi hoặc là nhận thông điệp, giống như khái niệm chúng ta đã quen biết trong lập trình hướng đối tượng. Một Use Case bao giờ cũng được kích hoạt bởi một tác nhân gửi thông điệp đến cho nó. Khi một Use Case được thực hiện, Use Case có thể gửi thông điệp đến một hay là nhiều tác nhân. Những thông điệp này cũng có thể đến với các tác nhân khác, bên cạnh chính tác nhân đã kích hoạt và gây ra Use Case. Cách tìm tác nhân Khi nhận diện tác nhân, có nghĩa là chúng ta lọc ra các thực thể đáng quan tâm theo khía cạnh sử dụng và tương tác với hệ thống. Sau đó chúng ta có thể thử đặt mình vào vị trí của tác nhân để cố gắng nhận ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác định tác nhân cần những Use Case nào. Có thể nhận diện ra các tác nhân qua việc trả lời một số các câu hỏi như sau: - Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)? Trang 13 - Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ? - Ai sẽ cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động (tác nhân phụ)? - Hệ thống sẽ phải xử lý và làm việc với những trang thiết bị phần cứng nào? - Hệ thống cần phải tương tác với các hệ thống khác nào? Nhóm các hệ thống này được chia ra làm hai nhóm, nhóm kích hoạt cho mối quan hệ với hệ thống, và nhóm mà hệ thống cần phải xây dựng của chúng ta sẽ thiết lập quan hệ. Khái niệm hệ thống bao gồm cả các hệ thống máy tính khác cũng như các ứng dụng khác trong chính chiếc máy tính mà hệ thống này sẽ hoạt động. - Ai hay cái gì quan tâm đến kết quả (giá trị) mà hệ thống sẽ sản sinh ra? Khi đi tìm những người sử dụng hệ thống, đừng quan sát những người đang ngồi ở trước màn hình máy tính. Người sử dụng có thể là bất kỳ người nào hay bất kỳ vật nào tương tác hoặc trực tiếp hoặc gián tiếp với hệ thống và sử dụng các dịch vụ của hệ thống này để đạt đến một kết quả nào đó. Để có thể nhận dạng được tốt nhiều tác nhân khác nhau, hãy tiến hành nghiên cứu những người sử dụng của hệ thống hiện thời (một hệ thống thủ công hoặc một hệ thống đang tồn tại), hỏi xem họ đóng những vai trò nào khi thực thi công việc hàng ngày của họ với hệ thống. Cũng người sử dụng đó có thể thực thi nhiều vai trò khác nhau tại nhiều thời điểm khác nhau, tùy thuộc vào việc chức năng nào trong hệ thống đang được sử dụng. Một tác nhân là một vai trò (một lớp), chứ không phải một thực thể riêng lẻ. Mặc dù vậy, khi cung cấp ví dụ là một vài các thực thể của một tác nhân, chúng ta có thể đảm bảo rằng tác nhân đó thật sự tồn tại. Một tác nhân phải có một sự liên kết (Association) nào đó với một hoặc là nhiều Use Case. Mặc dù có những tác nhân có thể không kích hoạt nên một Use Case nào, nhưng tác nhân đó sẽ giao tiếp ít nhất với một Use Case tại một thời điểm nào đó. Cần phải đặt tên cho tác nhân làm sao để tên phản ánh đúng vai trò của tác nhân đó trong hệ thống. Biểu diễn tác nhân trong ngôn ngữ UML Tác nhân trong UML là một lớp với biệt ngữ "Actor" (Tác nhân) và tên của lớp này là tên của tác nhân (phản ánh vai trò của tác nhân). Một lớp tác nhân có thể vừa có thuộc tính (attribute) lẫn hành vi (method) cũng như một thuộc tính tài liệu (document) mô tả tác nhân đó. Một lớp tác nhân có một biểu tượng chuẩn hóa, biểu tượng "hình nhân": Trang 14 Hình 2.2: Biểu tượng tác nhân trong UML 2.2. Đặc tả use case Để hiểu rõ hơn về tiến trình xử lý các yêu cầu của hệ thống ta nên xây dựng các đặc tả cho các các ca sử dụng. Mẫu (Format) đặc tả cho ca sử dụng có dạng: Tên Use-Case: Tên ca sử dụng bắt đầu bằng động từ. ID: Số thứ tự của các ca sử dụng. Mức độ quang trọng: Ca sử dụng này có mức độ quan trọng như thế nào đối với hệ thống: cao, thấp, trung bình, .... Tác nhân chính: Tác nhân chính tham gia vào hệ thống. Kiểu Use-Case: Kiểu Use-Case đối với hệ thống ra làm sao: quan trọng, chi tiết, cần thiết, ... Những người tham gia và quan tâm: Ai sử dụng đối với hệ thống. Mô tả vắn tắt: Mô tả tóm tắt tiến trình xử lý công việc cần thự hiện. Khởi sự: Người trực tiếp sử dụng hệ thống thực hiện các công việc có liên quan. Tham chiếu: Các chức năng, ca sử dụng và những hệ thống liên quan. Các mối quan hệ: Ca sử dụng, Actor có mối quan hệ như thế. Các luồng sự kiện thông thường: Tiến trình thực hiện công việc. Các luồng sự kiện con: Các luồng sự kiện thay thếngoại lệ: Trang 15 Ví dụ: Đặc tả cho UC Đăng nhập quản lý đoàn viên Tên Use-Case:Đăng nhập ID: 1 Mức độ quan trọng: Cao Tác nhân chính: Nhân viên, Người quản lý Kiểu Use-Case: Chi tiết, cần thiết Những người tham gia và quan tâm: Người quản lý, Nhân viên - muốn đăng nhập vào hệ thống. Mô tả vắn tắt : Usecase này mô tả người dùng ( người quản lí, nhân viên) đăng nhập vào hệ thống bằng tài khoản đã được tạo trước đó để thực hiện các chức năng của hệ thống. Khởi sự: Nhân viên sau khi đăng nhập tài khoản và muốn sử dụng phần mềm. Các mối quan hệ: Kết hợp (Association): Người quản lý Bao hàm (Include): Mở rộng (Extend): Khái quát hóa (Generalization): Các luồng sự kiện thông thường: - Hệ thống yêu cầu actor nhập tên đăng nhập, mật khẩu. - Actor nhập tên đăng nhập, mật khẩu của mình và nhấn nút đăng nhập. - Hệ thống kiểm tra thông tin đăng nhập. - Hệ thống thông báo thành công và cho actor đăng nhập vào hệ thống. Các luồng sự kiệ n con: Các luồng sự kiện thay thếngoại lệ: Nếu thông tin đăng nhập không hợp lệ thì hệ thống thông báo yêu cầu người dùng đăng nhập lại. Trang 16 2.3. Biểu đồ UC Use-case như tên gọi của nó, là một trường hợp sử dụng của hệ thống, tức là một công việc mà hệ thống sẽ thực hiện để đạt được kết quả có ý nghĩa đối với mộttác nhân nào đó. Tác nhân (actor) ở đây có thể là người hoặc hệ thống tương tác với use-case. Thường actor là một người sử dụng hệ thống. Trong UML tác nhân thường là một lớp. Một biểu đồ use-case(use-case diagram) được tạo ra từ các hình ô van (biểu diễn use-case) và hình người (biểu diễn tác nhân sử dụng user-case). Tên của tác nhân (actor) được đặt phía dưới hình người, tên của use-case được đặt bên trong hình ô van hoặc phía dưới. Chúng được liên kết với nhau bằng các đoạn thẳng để chỉ rõ tác nhân nào sử dụng use-case nào. Đoạn thẳng này có thể có mũi tên ở cuối (phía use-case) nếu ta muốn nhấn mạnh tác nhân tương ứng đóng vai trò kích hoạt use-case (nếu có nhiều tác nhân liên hệ với use-case). Các biểu đồ use-case (tập hợp các biểu đồ này sẽ được gọi là mô hình use-case) cung cấp một bức tranh toàn cảnh về những gì đang xảy ra trong hệ thống (hiện tại hay dự định xây dựng), cụ thể hơn, mô hình use-case trả lời cho câu hỏi: ai (hoặc hệ thố ng nào) sử dụng phần mềm và sử dụng để làm gì . Mục đích của biểu đồ use-case: - Dùng để mô hình hóa các chuỗi hành động của hệ thống. - Cung cấp một cách nhìn tổng thể về những gì mà hệ thống sẽ làm và ai sẽ dùng nó. - Đưa ra cơ sở để xác định giao tiếp người-máy của hệ thống. - Dùng để mô hình hóa các kịch bản (scenario) cho một trường hợp sử dụng. - Để người dùng cuối có thể hiểu được và có thể giao tiếp với hệ thống ở mức tổng thể. - Làm cơ sở cho việc phát thảo ra các đặc tả kiểm tra. Ví dụ về use-case: Trong một hệ thống quản lý đoàn viên của một trường đại học có biểu đồ use-case như sau: Trang 17 Nếu các use-case là các thành phần của một hệ thống hoặc hệ thống con thì chúng được nhóm lại trong một hình chữ nhật được đặt tên (chính là tên hệ thống). Ví dụ: Hệ thống bán hàng Mối quan hệ giữa các ca sử dụng Có ba loại quan hệ Use Case: Quan hệ mở rộng, quan hệ sử dụng và quan hệ tạo nhóm. Quan hệ mở rộng và quan hệ sử dụng là hai dạng khác nhau của tính thừa kế. Quan hệ tạo nhóm là một phương cách để đặt nhiều Use Case chung với nhau vào trong một gói. Quan hệ mở rộng Nhiều khi trong quá trình phát triển Use Case, người ta thấy một số Use Case đã tồn tại cung cấp một phần những chức năng cần thiết cho một Use Case mới. Trong một trường hợp như vậy, có thể định nghĩa một Use Case mới là Use Case cũ cộng thêm một phần mới. Một Use Case như vậy được gọi là một Use Case mở rộng (Extended Use Case). Trong quan hệ mở rộng, Use Case gốc (Base Use Case ) được dùng để mở rộng phải là một Use Case hoàn thiện. Use Case mở rộng không nhất thiết phải sử dụng toàn bộ hành vi của Use Case gốc. Quan hệ mở rộng giữa các Use Case được biểu thị bằng đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case được dùng để mở rộng, đi kèm với stereotype . Bán hàng Bán hàng Xem bả ng giá Khách hàng Nhân viên bán hàng Cập nhập đoàn viên Người Quản Lý Trang 18 Quan hệ sử dụng Khi một nhóm các Use Case cùng chung một hành vi nào đó thì hành vi này có thể được tách riêng ra thành một Use Case riêng biệt và nó có thể được sử dụng bởi các Use Case kia, một mối quan hệ như vậy được gọi là quan hệ sử dụng. Trong quan hệ sử dụng, phải sử dụng toàn bộ Use Case khái quát hóa, nói một cách khác, ta có một Use Case này sử dụng toàn bộ một Use Case khác. Các hành động trong Use Case khái quát hóa không cần phải được sử dụng trong cùng một tiến trình. Chúng có thể được trộn lẫn với các hành động xảy ra trong Use Case chuyên biệt hóa. Quan hệ sử dụng giữa các Use Case được biểu thị bằng đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case được sử dụng, đi kèm với stereotype hoặc . Quan hệ chung nhóm Khi một số các Use Case cùng xử lý các chức năng tương tự hoặc có thể liên quan đến nhau theo một phương thức nào đó, người ta thường nhóm chúng lại với nhau. Nhóm các Use Case được thực hiện bằng khái niệm "Gói" (Package) của UML. Gói không cung cấp giá trị gia tăng cho thiết kế. Generalization: UC này được kế thừa các chức năng của UC kia. Trang 19 Các phần tử mô hình UC cùng với ý nghĩa và cách biểu diễn của nó được tổng kết trong bảng dưới đây: Phần tử mô hình Ý nghĩa Cách biểu diễn Ký hiệu trong biểu đồ Use case Biểu diễn một chức năng xác định của hệ thống Hình eclip chứa tên của use case Tác nhân Là một đối tượng bên ngoài hệ thống tương tác trực tiếp với các UC Biểu diễn bởi một kiểu actor (hình người tượng trưng) Mối quan hệ giữa các UC Tùy từng dạng quan hệ Extend và include có dạng mũi tên nét đứt. Generalization có dạng mũi tên tam giác. Biên của hệ thống Tách biệt phần bên trong và bên ngoài hệ thống. Được biểu diễn bởi một hình chữ nhật rỗng 2.4. Mô hình hóa Use Case. Những thành phần quan trọng nhất của một mô hình Use Case là Use Case, tác nhân và hệ thống. Ranh giới của hệ thống được định nghĩa qua chức năng tổng thể mà hệ thống sẽ thực thi. Chức năng tổng thể được thể hiện qua một loạt các Use Case và mỗi một Use Case đặc tả một chức năng trọn vẹn, có nghĩa là Use Case phải thực thi toàn bộ chức năng đó, từ sự kiện được kích hoạt đầu tiên bởi một tác nhân ngoại cảnh cho tới khi chức năng đòi hỏi được thực hiện hoàn tất. Một Use Case luôn luôn phải cung cấp một giá trị nào đó cho một tác nhân, giá trị này là những gì mà tác nhân mong muốn từ phía hệ thống. Tác nhân là bất kỳ một thực thể ngoại cảnh nào mong muốn tương tác với hệ thống. Thường Trang 20 thì, đó là một người sử dụng của hệ thống, nhưng nhiều khi cũng có thể là một hệ thống khác hoặc là một dạng máy móc thiết bị phần cứng nào đó cần tương tác với hệ thống. Mục tiêu chính yếu đối với các Use Case là: - Để quyết định và mô tả các yêu cầu về mặt chức năng của hệ thống, đây là kết quả rút ra từ sự thỏa thuận giữa khách hàng (vàhoặc người sử dụng cuối) và nhóm phát triển phần mềm. - Để tạo nên một lời mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì, làm sao để mô hình có thể được sử dụng nhất quán suốt toàn bộ quá trình phát triển, được sử dụng làm công cụ giao tiếp cho tất cả những người phát triển nên các yêu cầu này, và để tạo nên một nền tảng cho việc tạo nên các mô hình thiết kế cung cấp các chức năng được yêu cầu. - Để tạo nên một nền tảng cho các bước thử nghiệm hệ thống, đảm bảo hệ thống thỏa mãn đúng những yêu cầu do người sử dụng đưa ra. Trong thực tế thường là để trả lời câu hỏi: Liệu hệ thống cuối cùng có thực hiện những chức năng mà khởi đầu khách hàng đã đề nghị? - Để cung cấp khả năng theo dõi các yêu cầu về mặt chức năng được chuyển thành các lớp cụ thể cũng như các thủ tục cụ thể trong hệ thống. - Để đơn giản hóa việc thay đổi và mở rộng hệ thống qua việc thay đổi và mở rộng mô hình Use Case, sau đó chỉ theo dõi riêng những Use Case đã bị thay đổi cùng những hiệu ứng của chúng trong thiết kế hệ thống và xây dựng hệ thống. Những công việc cụ thể cần thiết để tạo nên một mô hình Use Case bao gồm: 1. Định nghĩa hệ thống (xác định phạm vi hệ thống) 2. Tìm ra các tác nhân cũng như các Use Case 3. Mô tả Use Case 4. Định nghĩa mối quan hệ giữa các Use Case 5. Kiểm tra và phê chuẩn mô hình. Đây là một công việc mang tính tương tác rất cao, bao gồm những cuộc thảo luận với khách hàng và những người đại diện cho các loại tác nhân. Mô hình Use Case bao gồm các biểu đồ Use Case chỉ ra các tác nhân, Use Case và mối quan hệ của chúng với nhau. Các biểu đồ này cho ta một cái nhìn tổng thể về mô hình, nhưng những lời mô tả Trang 21 thực sự của từng Use Case thường lại là văn bản. Vì các mô hình trực quan không thể cung cấp tất cả các thông tin cần thiết, nên cần thiết phải dùng cả hai kỹ thuật trình bày đó. Có rất nhiều người quan tâm đến việc sử dụng các mô hình Use Case. Khách hàng (vàhoặc người sử dụng cuối) quan tâm đến chúng vì mô hình Use Case đặc tả chức năng của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng ra sao. Các Use Case vì vậy phải được mô tả trong những thuật ngữ và ngôn ngữ của khách hàngngười sử dụng. Nhà phát triển cần đến các mô hình Use Case để hiểu hệ thống cần phải làm gì, và qua đó có được một nền tảng cho những công việc tương lai (các mô hình khác, các cấu trúc thiết kế và việc thực thi xây dựng hệ thống bằng code). Các nhóm chuyên gia thử nghiệm tích hợp và thử nghiệm hệ thống cần đến Use Case để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức năng đã được đặc tả trong giai đoạn đầu. Và cuối cùng, bất kỳ người nào liên quan đến những hoạt động liên kết đến chức năng của hệ thống đều có thể quan tâm đến các mô hình Use Case; ví dụ như các nhóm tiếp thị, bán hàng, hỗ trợ khách hàng và các nhóm soạn thảo tài liệu. Mô hình Use Case mô tả hướng nhìn Use Case của hệ thống. Hướng nhìn này là rất quan trọng, bởi nó ảnh hưởng đến tất cả các hướng nhìn khác của hệ thống. Cả cấu trúc logic lẫn cấu trúc physic đều chịu ảnh hưởng từ các Use Case, bởi chức năng được đặc tả trong mô hình này chính là những chức năng được thực thi trong các cấu trúc kia. Mục đích cuối cùng là thiết kế ra một giải pháp thỏa mãn các yêu cầu đó. Mô hình hóa các Use Case chẳng phải chỉ được dùng để nắm bắt các yêu cầu của hệ thống mới, nó cũng còn được sử dụng để hỗ trợ cho việc phát triển một phiên bản mới của hệ thống. Khi phát triển một phiên bản mới của hệ thống đang tồn tại, người ta sẽ bổ sung thêm các chức năng mới vào mô hình Use Case đã có bằng cách thêm vào các tác nhân mới cũng như các Use Case mới, hoặc là thay đổi đặc tả của các Use Case đã có. Khi bổ sung thêm vào mô hình Use Case đang tồn tại, hãy chú ý để không bỏ ra bất kỳ một chức năng nào vẫn còn được cần tới. Trang 22 2.5. Mô hình đối tượng và tương tác đối tượng 2.5.1. Mô hình đối tượng Một đối tượng là một cái ...
NỘI DUNG NGHIÊN CỨU
1.1 Cơ bản về phân tích, thiết kế hướng đối tượng
1.1.1 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, 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)
1.1.2.Giới thiệuvề 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 )
1.1.3 Tại sao phải sử dụng 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,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 1.1.4 OOAD sử dụng UML
TỔNG QUAN VỀ PHÂN TÍCH THIẾT KẾHƯỚNG ĐỐI TƯỢNG
Cơ bản về phân tích, thiết kế hướng đối tượng
1.1.1 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, 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)
1.1.2.Giới thiệuvề 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 )
1.1.3 Tại sao phải sử dụng 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,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 1.1.4 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.v
Phân tích thiết kế hướng đối tượng sử dụng UML bao gồm các thành phần sau: – View (góc nhìn)
– Mechanisms (qui tắc, cơ chế)
Mục đích của mô hình hướng đối tượng
Mô hình được các hệ thống (không chỉ hệ thống phần mềm) và sử dụng được tất cả các khái niệm hướng đối tượng một cách thống nhất
Cho phép đặc tả, hỗ trợ để đặc tả tường minh (trực quan) mối quan hệ giữa các khái niệm cơ bản trong hệ thống, đồng thời mô tả được mọi trạng thái hoạt động của hệ thống đối tượng Nghĩa là cho phép mô tả được cả mô hình tĩnh lẫn mô hình động một cách đầy đủ và trực quan
Tận dụng được những khả năng sử dụng lại và kế thừa ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp và nhạy cảm như: các hệ thống động, hệ thống thời gian thực, hệ thống nhúng thời gian thực, v.v
Tóm lại,UMLsử dụng vẽ các biểu đồ trên là ngôn ngữ mô hình hoá, ngôn ngữ đặc tả và ngôn ngữ xây dựng mô hình trong quá trình phát triển phần mềm, đặc biệt là trong phân tích và thiết kế hệ thống hướng đối tượng UML là ngôn ngữ hình thức, thống nhất và chuẩn hoá mô hìnhhệ thống một cách trực quan Nghĩa là các thành phần trong mô hình được thể hiện bởicác ký hiệu đồ hoạ, biểu đồ và thể hiện đầy đủ mối quan hệ giữa chúng một cách thống nhất và có logic chặt chẽ.
Sử dụng UML để phát triển phần mềm thống nhất
UML được phát triển để đặc tả quá trình phát triển phần mềm, nhằm mô hình hoá hệ thống Quá trình phát triển phần mềm này gọi là quá trình phát triển phần mềm hợp nhất (USPD) hay quá trình hợp nhất Rational, gọi tắt là quá trình hợp nhất (UP)
RUP là tập các qui tắc hướng dẫn về phương diện kỹ thuật và tổ chức để phát triển phần mềm, nhấn mạnh chủ yếu vào các bước phân tích và thiết kế
RUP được cấu trúc theo hai chiều:
1 Chiều thời gian: chia quá trình thành các pha thực hiện và các bước lặp
2 Chiều thành phần: các sản phẩm cùng với các hoạt động được xác định đầy đủ
1 C ấ u trúc d ự án theo chi ề u th ờ i gian bao gồm các pha thực hiện:
(i)Khởi động (Inception): xác định dự án tổng thể
(ii) Soạn thảo dự án tỉ mỉ (Elaboration):
+ Lập kế hoặch cho những hoạt động cần thiết
+ Xác định những tài nguyên cần để thực hiện dự án
+ Xác định các tính chất, đặc trưng của dự án
+ Xây dựng kiến trúc cho hệ thống
(iii) Xác định những sản phẩm ở mỗi pha thực hiện
(iv) Chuyển giao: cung cấp sản phẩm cho cộng đồng người sử dụng
2 C ấ u trúc d ự án theo chi ề u thành ph ầ n bao gồm các hoạt động:
Mô hình hoá nghiệp vụ: thiết lập các khả năng của hệ thống cần xây dựng và nhu cầu của người sử dụng
Phân tích các yêu cầu: chi tiết các yêu cầu chức năng và phi chức năng của hệ thống Phân tích thiết kế hệ thống: mô tả hệ thống thực hiện các yêu cầu và hỗ trợ cài đặt Cài đặt chương trình: lập trình những kết quả thiết kế nêu trên để hệ thống hoạt động đúng theo yêu cầu
Kiểm thử, kiểm chứng các thành phần và toàn bộ hệ thống
Triển khai hệ thống: khai thác hệ thống và huấn luyện người sử dụng
UP bao gồm con người, dự án, sản phẩm, qui trình và công cụ Con người là những người tham gia dự án để tạo ra sản phẩm phần mềm theo một quá trình với sự hỗ trợ của công cụ được cung cấp
UP là quá trình phát triển phần mềm được hướng dẫn bởi các ca sử dụng Nghĩa là các yêu cầu của người sử dụng được mô tả trong các ca sử dụng, là chuỗi các hành động được thực hiện bởi hệ thống nhằm cung cấp các dịch vụ, các thông tin cho khách hàng Các ca sử dụng bao gồm chuỗi các công việc được xem là nền tảng để tạo ra mô hình thiết kế và cài đặt hệ thống
UP cũng là qui trình tập trung vào kiến trúc, được lặp và phát triển tăng trưởng liên tục Kiến trúc của hệ thống phải được thiết kế nhằm đáp ứng các yêu cầu của cácca sử
Trang 6 dụng chính, trong giới hạn của chuẩn phần cứng mà hệ thống sẽ chạy và của cấu trúc cả hệ thống lẫn các hệ thống con Tính lặp của quá trình phát triển phần mềm được thể hiện ở chỗ là một dự án được chia thành các dự án nhỏ và được thực hiện lặplại trong từng bước thực hiện Mỗi dự án nhỏ đều thực hiện phân tích, thiết kế, cài đặtvà kiểm thử, v.v Mỗi phần việc đó được phát triển tăng trưởng và cả dự án cũng được thực hiện theo sự tăng trưởng này
UP không chỉ tạo ra một hệ thống phần mềm hoàn chỉnh mà còn tạo ra một số sản phẩm trung gian như các mô hình Các mô hình chính trong UP là mô hình nghiệp vụ (ca sử dụng), mô hình khái niệm, mô hình thiết kế, mô hình triển khai và mô hình trắc nghiệm Các mô hình này có sự phụ thuộc theo vết phát triển, nghĩa là có thể lần theo từng mô hình để đến được mô hình trước.
Các biểu đồ (Diagram)
Diagram các bạn có thể dịch là sơ đồ Tuy nhiên ở đây chúng ta sử dụng từ bản vẽ cho dễ hình dung Các bản vẽ được dùng để thể hiện các góc nhìn của hệ thống
Hình 1.1: Các bản vẽ trong OOAD sử dụng UML Trong đó,
– Biểu đồ ca sử dụng ( 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
– Biểu đồ lớp (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 – Biểu đồ đối tượng(Object Diagram): Tương tự như Class Diagram nhưng nó mô tả đến đối tượng thay vì lớp (Class)
– Biểu đồ trình tự (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 – Biểu đồ cộng tác (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
– Biểu đồ trạng thái (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
– Biểu đồ hoạt độ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
– Biểu đồ thành phần (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 đó
– Biểu đồ triển khai (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…
Các quan sát ( Các kiểu xem)
Khi xem xét một hệ thống, chúng ta cần xây dựng mô hình từ những hướng nhìn (View- khía cạnh) khác nhau, xuất phát từ thực tế là những người làm việc với hệ thống, với các vai trò khác nhau sẽ nhìn hệ thống từ những khía cạnh khác nhau
UML xét hệ thống trên 5 khía cạnh:
Hình 1.2: Các View trong OOAD sử dụng UML Trong đó,
– Use Case View: cung cấp góc nhìn về các ca sử dụng giúp chúng ta hiểu hệ thống có gì? ai dùng và dùng nó như thế nào
– Logical View: cung cấp góc nhìn về cấu trúc hệ thống, xem nó được tổ chức như thế nào Bên trong nó có gì
– Process View: cung cấp góc nhìn động về hệ thống, xem các thành phần trong hệ thống tương tác với nhau như thế nào
– Component View: Cũng là một góc nhìn về cấu trúc giúp chúng ta hiểu cách phân bổ và sử dụng lại các thành phần trong hệ thống ra sao
– Deployment View: cung cấp góc nhìn về triển khai hệ thống, nó cũng ảnh hưởng lớn đến kiến trúc hệ thống
Tập hợp các góc nhìn này sẽ giúp chúng ta hiểu rõ hệ thống cần phân tích, thiết kế Trong hình 1.2 chúng ta thấy góc nhìn Use Case View nằm ở giữa và chi phối tất cả các góc nhìn còn lại Chính vì thế chúng ta thường thấy các tài liệu nói về 4 view + 1 chứ không phải 5 view nhằm nhấn mạnh vai trò của Use Case View
CÁC MÔ HÌNH TRONG PHÂN TÍCH THIẾT KẾHƯỚNG ĐỐI TƯỢNG
Use case (Ca sử dụng: UC)
Khái niệm ca sử dụng hay trường hợp sử dụng (Use-case) được Ivan Jacobson đề xuất năm 1994 nhằm mô tả các dịch vụ của hệ thống cho khách hàng và xác định mối quan hệ tương tác giữa hệ thống phần mềm với người sử dụng trong nghiệp vụ
Một cách hệ thống hơn, ca sử dụng mô tả tập các hoạt động của hệ thống theo quan điểm của các tác nhân (Actor) Nó mô tả các yêu cầu của hệ thống và trả lời cho câu hỏi:
Hệ thống phải làm cái gì? (What?)
Ca sử dụng mô tả một quá trình bắt đầu cho đến khi kết thúc, gồm dãy các thao tác, các giao dịch cần thiết để sản sinh ra cái gì đó (giá trị, thông tin) theo yêu cầu của một tổ chức, của tác nhân,
Ca sử dụng được kí hiệu là: Hoạt động
Hoạt động Trong đó “Hoạt động” là các chức năng, nhiệm vụ hay gọi chung là dịch vụ của hệ thống và nó thường được mô tả bằng các động từ hay mệnh đề động từ đơn Ví dụ: đăng nhập, cập nhập, thanh toán,
Những ca sử dụng phức tạp sẽ được mô tả chi tiết thông qua các kịch bản
Mục tiêu của ca sử dụng
Mục tiêu của ca sử dụng trong cả quá trình phát triển phần mềm:
Mô tả các yêu cầu chức năng của hệ thống, là kết quả của quá trình khảo sát, nghiên cứu các yêu cầu của bài toán và những thỏa thuận giữa khách hàng, người sử dụng hệ thống với người phát triển phần mềm
Làm cơ sở để người phân tích viên hiểu, người thiết kế xây dựng các kiến trúc, người lập trình cài đặt các chức năng của hệ thống
Hình 2.1: Ký hiệu của ca sử dụng
Sự cần thiết phải có UC
Use Case là một công cụ để khuyến khích những người dùng tiềm năng nói về hệ thống từ hướng nhìn của họ Đối với người dùng, chẳng phải bao giờ việc thể hiện và mô tả những ý định trong việc sử dụng hệ thống cũng là chuyện dễ dàng Một hiện thực có thật là người sử dụng thường biết nhiều hơn những gì mà họ có thể diễn tả ra: Công cụ Use Case sẽ giúp cho nhóm phát triển phần mềm hiểu rõ hơn, ngoài ra một sự trình bày trực quan cũng cho phép bạn kết hợp các biểu đồ Use Case với các loại biểu đồ khác Sáng kiến chủ đạo là lôi cuốn được người dùng tham gia vào những giai đoạn đầu tiên của quá trình phân tích và thiết kế hệ thống Việc này sẽ nâng cao xác suất cho việc hệ thống chung cuộc trở thành một công cụ quen thuộc đối với các người dùng mà nó dự định sẽ trợ giúp – thay vì là một tập hợp khó hiểu và rối rắm của các khái niệm máy tínhmà người dùng trong giới doanh thương có cảm giác không bao giờ hiểu được và không thể làm việc cùng
Công tác lôi kéo người sử dụng tham gia tích cực vào quá trình phân tích là nền tảng quan trọng cho việc tạo dựng một mô hình "thành công", một mô hình dễ được người sử dụng hiểu và chấp nhận sau khi đã thẩm xác các nhiệm vụ căn bản Ngoài ra, Use Case còn giúp nhóm phát triển quyết định các lớp mà hệ thống phải triển khai
Ca sử dụng là gì?
Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận được Một Use Case trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống
Các tính chất tiêu biểu của một Use Case là:
- Một Use Case bao giờ cũng được gây ra bởi một tác nhân, được thực hiện nhân danh một tác nhân nào đó Tác nhân phải ra lệnh cho hệ thống để thực hiện Use Case đó, dù là trực tiếp hay gián tiếp Hiếm khi có tác nhân không liên quan đến việc gây ra một Use Case nào đó
- Một Use Case phải cung cấp một giá trị cho một tác nhân Giá trị đó không phải bao giờ cũng cần thiết phải nổi trội ra ngoài, nhưng luôn phải được thấy rõ
- Một Use Case là phải hoàn tất Một trong những lỗi thường gặp là sẻ chia một Use Case thành các Use Case nhỏ hơn, và các Use Case này thực thi lẫn nhau giống như việc gọi hàm cho một ngôn ngữ lập trình Một Use Case sẽ không được coi là hoàn tất chừng nào mà giá trị cuối cùng của nó chưa được sản sinh ra, thậm chí ngay cả khi đã xảy ra nhiều động tác giao tiếp (ví dụ như đối thoại với người sử dụng)
Use Case được nối với tác nhân qua liên kết (association) Đường liên kết chỉ ra những tác nhân nào giao tiếp với Use Case nào Mối liên kết bình thường ra là một mối quan hệ 1-1 và không có hướng Điều đó muốn nói lên rằng một thực thể của lớp tác nhân sẽ giao tiếp với một thực thể của một Use Case và cả hai có thể giao tiếp với nhau trong cả hai chiều Một Use Case sẽ được đặt tên theo một thực thể mà Use Case sẽ thực hiện, ví dụ như tìm kiếm, hóa đơn, cập nhật danh sách, v.v…, và thường là một cụm từ hơn là chỉ một từ riêng lẻ
Cách tìm ca sử dụng
Quá trình tìm các Use Case bắt đầu với các tác nhân đã được xác định ở phần trước Đối với mỗi tác nhân, hãy hỏi các câu hỏi sau: a Tác nhân này cần những chức năng nào từ hệ thống? Hành động chính của tác nhân là gì ?
Ví dụ: Đăng nhập vào hệ thống phần mềm quản lí đoàn viên, các hành động chính của người quản lý (tác nhân) có thể là :
- Nếu đúng thì cho phép sử dụng phần mềm
- Nếu sai, thì yêu cầu người quản lý nhập lại tên hoặc pass word b Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa chữa, hay là lưu trữ một loại thông tin nào đó trong hệ thống?
- Người quản lý có thể thay đổi pass word
- Người quản lý có thể đăng kí thêm người dùng mới
Trang 12 c Tác nhân có cần phải báo cho hệ thống biết về những sự kiện nào đó? Những sự kiện như thế sẽ đại diện cho những chức năng nào? d Hệ thống có cần phải thông báo cho Actor về những thay đổi bất ngờ trong nội bộ hệ thống? e Công việc hàng ngày của tác nhân có thể được đơn giản hóa hoặc hữu hiệu hóa qua các chức năng mới trong hệ thống (thường đây là những chức năng tiêu biểu chưa được tự động hóa trong hệ thống)?
Một Use Case bao giờ cũng phải được liên kết với ít nhất một tác nhân
Use Case là một công cụ trợ giúp cho công việc của nhà phân tích cùng người sử dụng quyết định tính năng của hệ thống
Đặc tả use case
Để hiểu rõ hơn về tiến trình xử lý các yêu cầu của hệ thống ta nên xây dựng các đặc tả cho các các ca sử dụng
Mẫu (Format) đặc tả cho ca sử dụng có dạng:
Tên Use-Case: Tên ca sử dụng bắt đầu bằng động từ
ID: Số thứ tự của các ca sử dụng
Mức độ quang trọng: Ca sử dụng này có mức độ quan trọng như thế nào đối với hệ thống: cao, thấp, trung bình,
Tác nhân chính: Tác nhân chính tham gia vào hệ thống
Kiểu Use-Case: Kiểu Use-Case đối với hệ thống ra làm sao: quan trọng, chi tiết, cần thiết,
Những người tham gia và quan tâm: Ai sử dụng đối với hệ thống
Mô tả vắn tắt: Mô tả tóm tắt tiến trình xử lý công việc cần thự hiện
Khởi sự: Người trực tiếp sử dụng hệ thống thực hiện các công việc có liên quan Tham chiếu: Các chức năng, ca sử dụng và những hệ thống liên quan
Các mối quan hệ: Ca sử dụng, Actor có mối quan hệ như thế
Các luồng sự kiện thông thường: Tiến trình thực hiện công việc
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Ví dụ: Đặc tả cho UC Đăng nhập quản lý đoàn viên
Tên Use-Case: Đăng nhập ID: 1 Mức độ quan trọng: Cao
Nhân viên, Người quản lý
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý, Nhân viên - muốn đăng nhập vào hệ thống
Mô tả vắn tắt: Usecase này mô tả người dùng ( người quản lí, nhân viên) đăng nhập vào hệ thống bằng tài khoản đã được tạo trước đó để thực hiện các chức năng của hệ thống
Nhân viên sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Hệ thống yêu cầu actor nhập tên đăng nhập, mật khẩu
- Actor nhập tên đăng nhập, mật khẩu của mình và nhấn nút đăng nhập
- Hệ thống kiểm tra thông tin đăng nhập
- Hệ thống thông báo thành công và cho actor đăng nhập vào hệ thống
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Nếu thông tin đăng nhập không hợp lệ thì hệ thống thông báo yêu cầu người dùng đăng nhập lại
Biểu đồ UC
Use-case như tên gọi của nó, là một trường hợp sử dụng của hệ thống, tức là một công việc mà hệ thống sẽ thực hiện để đạt được kết quả có ý nghĩa đối với mộttác nhân nào đó
Tác nhân (actor) ở đây có thể là người hoặc hệ thống tương tác với use-case
Thường actor là một người sử dụng hệ thống Trong UML tác nhân thường là một lớp Một biểu đồ use-case(use-case diagram) được tạo ra từ các hình ô van (biểu diễn use-case) và hình người (biểu diễn tác nhân sử dụng user-case) Tên của tác nhân (actor) được đặt phía dưới hình người, tên của use-case được đặt bên trong hình ô van hoặc phía dưới Chúng được liên kết với nhau bằng các đoạn thẳng để chỉ rõ tác nhân nào sử dụng use-case nào Đoạn thẳng này có thể có mũi tên ở cuối (phía use-case) nếu ta muốn nhấn mạnh tác nhân tương ứng đóng vai trò kích hoạt use-case (nếu có nhiều tác nhân liên hệ với use-case)
Các biểu đồ use-case (tập hợp các biểu đồ này sẽ được gọi là mô hình use-case) cung cấp một bức tranh toàn cảnh về những gì đang xảy ra trong hệ thống (hiện tại hay dự định xây dựng), cụ thể hơn, mô hình use-case trả lời cho câu hỏi: ai (hoặc hệ thống nào) sử dụng phần mềm và sử dụng để làm gì
Mục đích của biểu đồ use-case:
- Dùng để mô hình hóa các chuỗi hành động của hệ thống
- Cung cấp một cách nhìn tổng thể về những gì mà hệ thống sẽ làm và ai sẽ dùng nó
- Đưa ra cơ sở để xác định giao tiếp người-máy của hệ thống
- Dùng để mô hình hóa các kịch bản (scenario) cho một trường hợp sử dụng
- Để người dùng cuối có thể hiểu được và có thể giao tiếp với hệ thống ở mức tổng thể
- Làm cơ sở cho việc phát thảo ra các đặc tả kiểm tra
Ví dụ về use-case: Trong một hệ thống quản lý đoàn viên của một trường đại học có biểu đồ use-case như sau:
Nếu các use-case là các thành phần của một hệ thống hoặc hệ thống con thì chúng được nhóm lại trong một hình chữ nhật được đặt tên (chính là tên hệ thống)
Ví dụ: Hệ thống bán hàng
Mối quan hệ giữa các ca sử dụng
Có ba loại quan hệ Use Case: Quan hệ mở rộng, quan hệ sử dụng và quan hệ tạo nhóm Quan hệ mở rộng và quan hệ sử dụng là hai dạng khác nhau của tính thừa kế Quan hệ tạo nhóm là một phương cách để đặt nhiều Use Case chung với nhau vào trong một gói
Nhiều khi trong quá trình phát triển Use Case, người ta thấy một số Use Case đã tồn tại cung cấp một phần những chức năng cần thiết cho một Use Case mới Trong một trường hợp như vậy, có thể định nghĩa một Use Case mới là Use Case cũ cộng thêm một phần mới Một Use Case như vậy được gọi là một Use Case mở rộng (Extended Use Case) Trong quan hệ mở rộng, Use Case gốc (Base Use Case ) được dùng để mở rộng phải là một Use Case hoàn thiện Use Case mở rộng không nhất thiết phải sử dụng toàn bộ hành vi của Use Case gốc
Quan hệ mở rộng giữa các Use Case được biểu thị bằng đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case được dùng để mở rộng, đi kèm với stereotype
Xem bảng Khách giá hàng Nhân viên bán hàng
Cập nhập đoàn viên Người Quản Lý
Khi một nhóm các Use Case cùng chung một hành vi nào đó thì hành vi này có thể được tách riêng ra thành một Use Case riêng biệt và nó có thể được sử dụng bởi các Use Case kia, một mối quan hệ như vậy được gọi là quan hệ sử dụng
Trong quan hệ sử dụng, phải sử dụng toàn bộ Use Case khái quát hóa, nói một cách khác, ta có một Use Case này sử dụng toàn bộ một Use Case khác Các hành động trong Use Case khái quát hóa không cần phải được sử dụng trong cùng một tiến trình Chúng có thể được trộn lẫn với các hành động xảy ra trong Use Case chuyên biệt hóa
Quan hệ sử dụng giữa các Use Case được biểu thị bằng đoạn thẳng với hình tam giác rỗng trỏ về phía Use Case được sử dụng, đi kèm với stereotype hoặc
Khi một số các Use Case cùng xử lý các chức năng tương tự hoặc có thể liên quan đến nhau theo một phương thức nào đó, người ta thường nhóm chúng lại với nhau
Nhóm các Use Case được thực hiện bằng khái niệm "Gói" (Package) của UML Gói không cung cấp giá trị gia tăng cho thiết kế
Generalization: UC này được kế thừa các chức năng của UC kia
Các phần tử mô hình UC cùng với ý nghĩa và cách biểu diễn của nó được tổng kết trong bảng dưới đây:
Phần tử mô hình Ý nghĩa Cách biểu diễn Ký hiệu trong biểu đồ Use case Biểu diễn một chức năng xác định của hệ thống
Hình eclip chứa tên của use case
Tác nhân Là một đối tượng bên ngoài hệ thống tương tác trực tiếp với các UC
Biểu diễn bởi một kiểu actor (hình người tượng trưng)
Mối quan hệ giữa các UC
Tùy từng dạng quan hệ
Extend và include có dạng mũi tên nét đứt
Generalization có dạng mũi tên tam giác
Biên của hệ thống Tách biệt phần bên trong và bên ngoài hệ thống Được biểu diễn bởi một hình chữ nhật rỗng
Mô hình hóa Use Case
Những thành phần quan trọng nhất của một mô hình Use Case là Use Case, tác nhân và hệ thống Ranh giới của hệ thống được định nghĩa qua chức năng tổng thể mà hệ thống sẽ thực thi Chức năng tổng thể được thể hiện qua một loạt các Use Case và mỗi một Use Case đặc tả một chức năng trọn vẹn, có nghĩa là Use Case phải thực thi toàn bộ chức năng đó, từ sự kiện được kích hoạt đầu tiên bởi một tác nhân ngoại cảnh cho tới khi chức năng đòi hỏi được thực hiện hoàn tất Một Use Case luôn luôn phải cung cấp một giá trị nào đó cho một tác nhân, giá trị này là những gì mà tác nhân mong muốn từ phía hệ thống Tác nhân là bất kỳ một thực thể ngoại cảnh nào mong muốn tương tác với hệ thống Thường
Trang 20 thì, đó là một người sử dụng của hệ thống, nhưng nhiều khi cũng có thể là một hệ thống khác hoặc là một dạng máy móc thiết bị phần cứng nào đó cần tương tác với hệ thống Mục tiêu chính yếu đối với các Use Case là:
- Để quyết định và mô tả các yêu cầu về mặt chức năng của hệ thống, đây là kết quả rút ra từ sự thỏa thuận giữa khách hàng (và/hoặc người sử dụng cuối) và nhóm phát triển phần mềm
- Để tạo nên một lời mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì, làm sao để mô hình có thể được sử dụng nhất quán suốt toàn bộ quá trình phát triển, được sử dụng làm công cụ giao tiếp cho tất cả những người phát triển nên các yêu cầu này, và để tạo nên một nền tảng cho việc tạo nên các mô hình thiết kế cung cấp các chức năng được yêu cầu
- Để tạo nên một nền tảng cho các bước thử nghiệm hệ thống, đảm bảo hệ thống thỏa mãn đúng những yêu cầu do người sử dụng đưa ra Trong thực tế thường là để trả lời câu hỏi: Liệu hệ thống cuối cùng có thực hiện những chức năng mà khởi đầu khách hàng đã đề nghị?
- Để cung cấp khả năng theo dõi các yêu cầu về mặt chức năng được chuyển thành các lớp cụ thể cũng như các thủ tục cụ thể trong hệ thống
- Để đơn giản hóa việc thay đổi và mở rộng hệ thống qua việc thay đổi và mở rộng mô hình Use Case, sau đó chỉ theo dõi riêng những Use Case đã bị thay đổi cùng những hiệu ứng của chúng trong thiết kế hệ thống và xây dựng hệ thống
Những công việc cụ thể cần thiết để tạo nên một mô hình Use Case bao gồm:
1 Định nghĩa hệ thống (xác định phạm vi hệ thống)
2 Tìm ra các tác nhân cũng như các Use Case
4 Định nghĩa mối quan hệ giữa các Use Case
5 Kiểm tra và phê chuẩn mô hình Đây là một công việc mang tính tương tác rất cao, bao gồm những cuộc thảo luận với khách hàng và những người đại diện cho các loại tác nhân Mô hình Use Case bao gồm các biểu đồ Use Case chỉ ra các tác nhân, Use Case và mối quan hệ của chúng với nhau Các biểu đồ này cho ta một cái nhìn tổng thể về mô hình, nhưng những lời mô tả
Trang 21 thực sự của từng Use Case thường lại là văn bản Vì các mô hình trực quan không thể cung cấp tất cả các thông tin cần thiết, nên cần thiết phải dùng cả hai kỹ thuật trình bày đó
Có rất nhiều người quan tâm đến việc sử dụng các mô hình Use Case Khách hàng (và/hoặc người sử dụng cuối) quan tâm đến chúng vì mô hình Use Case đặc tả chức năng của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng ra sao Các Use Case vì vậy phải được mô tả trong những thuật ngữ và ngôn ngữ của khách hàng/người sử dụng Nhà phát triển cần đến các mô hình Use Case để hiểu hệ thống cần phải làm gì, và qua đó có được một nền tảng cho những công việc tương lai (các mô hình khác, các cấu trúc thiết kế và việc thực thi xây dựng hệ thống bằng code)
Các nhóm chuyên gia thử nghiệm tích hợp và thử nghiệm hệ thống cần đến Use Case để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức năng đã được đặc tả trong giai đoạn đầu
Và cuối cùng, bất kỳ người nào liên quan đến những hoạt động liên kết đến chức năng của hệ thống đều có thể quan tâm đến các mô hình Use Case; ví dụ như các nhóm tiếp thị, bán hàng, hỗ trợ khách hàng và các nhóm soạn thảo tài liệu
Mô hình Use Case mô tả hướng nhìn Use Case của hệ thống Hướng nhìn này là rất quan trọng, bởi nó ảnh hưởng đến tất cả các hướng nhìn khác của hệ thống Cả cấu trúc logic lẫn cấu trúc physic đều chịu ảnh hưởng từ các Use Case, bởi chức năng được đặc tả trong mô hình này chính là những chức năng được thực thi trong các cấu trúc kia Mục đích cuối cùng là thiết kế ra một giải pháp thỏa mãn các yêu cầu đó
Mô hình hóa các Use Case chẳng phải chỉ được dùng để nắm bắt các yêu cầu của hệ thống mới, nó cũng còn được sử dụng để hỗ trợ cho việc phát triển một phiên bản mới của hệ thống Khi phát triển một phiên bản mới của hệ thống đang tồn tại, người ta sẽ bổ sung thêm các chức năng mới vào mô hình Use Case đã có bằng cách thêm vào các tác nhân mới cũng như các Use Case mới, hoặc là thay đổi đặc tả của các Use Case đã có Khi bổ sung thêm vào mô hình Use Case đang tồn tại, hãy chú ý để không bỏ ra bất kỳ một chức năng nào vẫn còn được cần tới
Mô hình đối tượng và tương tác đối tượng
Một đối tượng là một cái gì đó gói riêng thông tin và cách ứng xử Nó là thuật ngữ biểu thị một thứ cụ thể trong thế giới thực nào đó Các mẫu thông tin mà đối tượng lưu giữ được gọi là các thuộc tính (attributes), các cách ứng xử của một đối tượng được gọi là các tác vụ (operations)
2.5.2 Biểu đồ tương tác đối tượng
Trong UML có 2 loại biểu đồ được xếp vào loại biểu đồ tương tác là biểu đồ tuần tự và biểu đồ cộng tác Biểu đồ tương tác dùng để mô hình các khía cạnh động của hệ thống Biểu đồ tương tác biểu diễn cách tương tác giữa các đối tượng để thực hiện một số chức năng ở mức cao mà đối tượng độc lập không thể thực hiện được Biểu đồ cộng tác biểu diễn sự tương tác trong ngữ cảnh của các vai trò lớp tham gia vào tương tác và biểu diễn mối quan hệ cấu trúc giữa các lớp bằng cách dùng các vai trò kết hợp Biểu đồ tuần tự được dùng để biểu diễn sự tương tác giống như biểu đồ cộng tác, nhưng nhấn mạnh tính thứ tự của thông điệp theo thời gian
Các thành phần của biểu đồ tương tác:
Đối tượng: biểu đồ tương tác sử dụng tên đối tượng, tên lớp hoặc cả hai
Liên kết: là hiện thực của kết hợp
Thông điệp: thông qua thông điệp, lớp hay đối tượng có thể yêu cầu lớp hay đối tượng khác thực hiện chức năng cụ thể
Biểu đồ tuần tự: Ý nghĩa: biểu diễn mối quan hệ giữa các đối tượng và tác nhân theo thứ tự 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
Các tập kí hiệu UML cho biểu đồ tuần tự:
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 các đối tượng đều xuất hiện ở trên cùng của 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 message: đượ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 message có thể biểu diễn dưới dạng phi hình thức (như các thông điệp theo 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) Biểu đồ tuần tự cho phép có các message từ đối tượng với chính bản thân nó
Các thành phần của biểu đồ tuần tự
Biểu đồ tuần tự mô tả sự trao đổi thông điệp giữa các đối tượng trình tự theo thời gian, thông điệp được gửi và nhận bởi các đối tượng đang hoạt động trong hệ thống Biểu đồ tuần tự được thực hiện theo 2 bước:
Trục dọc trên xuống chỉ thời gian xảy ra các sự kiện, hay sự truyền thông điệp, được biểu diễn bằng các đường gạch- gạch thẳng đứng bắt đầu từ đỉnh đến đáy của biểu đồ,đó là sự tồn tại của đối tượng trong chuỗi tương tác Trong khoảng thời gian này, đối tượng được thực thể hóa, sẵn sàng để gửi và nhận thông điệp
Trục ngang từ trái qua phải là dãy các đối tượng tham gia vào việc trao đổi các thông điệp với nhau theo chiều ngang, có thể có các tác nhân
Biểu đồ tuần tự được đọc từ trên xuống dưới, từ trái sang phải Thứ tự các đối tượng trong biểu đồ phải được sắp xếp sao cho đơn giản nhất có thể để dễ quan sát Thời gian thực hiện một thông điệp của một đối tượng được biểu diễn bằng hình chữ nhật hẹp dọc theo trục thẳng đứng của đối tượng đó
Ví dụ: Biểu đồ tuần tự cập nhập đoàn viên trong hệ thống quản lý đoàn viên:
:I_NQL_QLDV :C_NQL_QLDV :C_NQL_QLDV DoanVien DoanVien yeu cau tao moi ho so tao ho so tao ho so cap nhap ( sua, xoa) kiem tra luu ho so vao co so du lieu
Biểu đồ cộng tác Ý nghĩa: 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 nhấn mạnh đến vai trò của các đối tượng và tương tác
Biểu đồ cộng tác cũng có các message 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 life line cho mỗi đối tượng Các message có đánh số thể hiện thứ tự thời gian
Tập kí hiệu UML cho biểu đồ cộng tác:
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 đồ cộng tác, 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 kiên kết: giữa 2 đố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 message: đượ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 đồ cộng tác, các message được đánh số thứ tự theo thứ tự xuất hiện trong kịch bản mô tả use case tương ứng
Ví dụ:Biểu đồ cộng tác cập nhập đoàn viên trong hệ thống quản lý đoàn viên:
Hình 2.3: Sơ đồ cộng tác cập nhập đoàn viên
1: yeu cau tao moi ho so
2: tao ho so 3: tao ho so
4: cap nhap ( sua, xoa) 5: kiem tra
6: luu ho so vao co so du lieu
Biểu đồ lớp
Biểu đồ lớp là một loại mô hình tĩnh, để mô tả các view tĩnh của một hệ thống theo thuật ngữ lớp và quan hệ giữa các lớp Biểu đồ lớp tương tự như mô hình dữ liệu nhưng còn mô tả cả các hành vi trên các dữ liệu đó Mục đích của biểu đồ lớp là dùng để định nghĩa nền tảng cho các biểu đồ khác như: biểu đồ trạng thái, biểu đồ tuần tự, và phản ánh các mặt khác nhau của hệ thống Biểu đồ lớp giúp người phát triển phần mềm quan sát và lập kế hoạch cấu trúc hệ thống trước khi lập trình Nó đảm bảo rằng hệ thống được thiết kế tốt ngay từ đầu
Lớp được vẽ bởi một hình chữ nhật, chia thành 3 phần: tên lớp( Name), thuộc tính (attribute) và hành vi ( operation) của lớp
Lớp được tìm từ phạm vi bài toán cần được giải quyết, nên tên của lớp cũng nên đặt theo tên các đối tượng thực mà chúng biểu diễn Để tìm ra lớp cho bài toán, chúng ta cần trả lời các câu hỏi sau đây:
Có thông tin nào cần được lưu trữ hay phân tích hay không? Nếu có bất kỳ thông tin nào cần phải lưu trữ, biến đổi, phân tích, hay xử lý thì đó chính là một lớp dự định Các thông tin có thể là những khái niệm luôn phải được ghi nhận trong hệ thống hoặc là một sự kiện hay các giao dịch xảy ra tại một thời điểm xác định
Có hệ thống bên ngoài hay không? Hệ thống ngoài có thể được xem như các lớp mà hệ thống của chúng ta chứa hoặc tương tác với nó
Có các mẫu thiết kế, thư viện lớp, thành phần, không? Các thành phần này đã được xây dựng từ những dự án trước, từ các động sự hay các nhà sản xuất?
Có thiết bị nào mà hệ thống phải đáp ứng? Bất cứ thiết bị nào được nối với hệ thống đều có thể chuyển thành lớp dự tuyển
Có các thành phần có tổ chức không? Nên biểu diễn các thành phần này thành lớp, đặc biệt là trong mô hình kinh doanh
Tác nhân đóng vai trò như thế nào trong hệ thống? Các vai trò biểu diễn này nên được xem là lớp, chẳng hạn như người sử dụng, khách hàng, người điều khiển hệ thống,
UML được định nghĩa một số kiểu lớp đặc biệt dựa trên vai trò của nó trong biểu đồ lớp Uml có một số kiểu lớp:
Lớp thực thể: 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 đó
Lớp biên (lớp giao diện): là lớp nằm ở ranh giới giữa hệ thống với môi trường bên ngoài, 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: thực hiện các chức điều khiển hoạt động của hệ thống ứng với các chứa năng cụ thể nào đó với một nhóm các lớp biên hoặc lớp thực thể xác định
Các kiểu quan hệ trong lớp
Biểu đồ lớp bao gồm các lớp và quan giữa các lớp Quan hệ được sử dụng gồm kết hợp, tổng quát hóa (hay kế thừa), phụ thuộc và tinh chế
Kết hợp (association) là kết nối giữa các lớp cũng như giữa các đối tượng Sự kết hợp được định nghĩa là một quan hệ gồm một tập các mối liên kết, mỗi liên kết là một liên kết ngữ nghĩa giữa 2 đối tượng
Tổng quát hóa (generalization) là một quan hệ giữa một thành phần tổng quát hơn và một thành phần đặc tả hơn Thành phần đặc tả hơn chứa các thông tin thêm và có thể được dùng ở bất cứ nơi nào mà thành phần tổng quát hơn được phép dùng
Sự phụ thuộc (dependency) là quan hệ giữa một phần tử độc lập và một phần tử khác phụ thuộc vào nó Những thay đổi trong thành phần độc lập sẽ ảnh hưởng đến thành phần phụ thuộc
Sự tinh chế (refinement) là quan hệ giữa 2 lớp mô tả khác nhau của cùng một phần tử nhưng ở 2 cấp trừu tượng khác nhau
Bảng tổng kết phần tử mô hình UML được sử dụng trong mô hình lớp, ý nghĩa và ký hiệu tương ứng trong các biểu đồ
Phần tử mô hình Ý nghĩa Cách biểu diễn Kí hiệu trong biểu đồ
Biểu diễn tên lớp, các thuộc tính và phương thức của lớp đó
Một hình chữ nhật gồm 3 phần tách biệt
Quan hệ kiểu kết hợp
Biểu diễn quan hệ giữa 2 lớp độc lập, có liên quan đến nhau
Một đường kẻ liền nét (có tên xác định) nối giữa 2 lớp
Biểu diễn quan hệ kiểu bộ phận- tổng thể Đường kẻ liền nét có hình thoi ở đầu
Quan hệ khái quát hóa (kế thừa)
Lớp này thừa hưởng các thuộc tính- phương thức của lớp kia
Các lớp phụ thuộc lẫn nhau trong hoạt động của hệ thống
Mô hình biểu đồ trạng thái và biểu đồ hoạt động
2.7.1 Mô hình biểu đồ trạng thái
Biểu đồ trạng thái biểu diễn vòng đời của các đối tượng, của hệ thống con và cả hệ thống Qua đó cho biết các trạng thái mà một đối tượng có thể có và cách các sự kiện (thông điệp được nhận, thời gian trôi qua, lỗi, điều kiện trở nên đúng, ) tác động đến trạng thái đó theo thời gian Biểu đồ trạng thái nên gắn vào các lớp có trạng thái định danh rõ ràng và hành vi phức tạp Biểu đồ trạng thái xác định các hành vi và sự khác biệt đối với trạng thái hiện hành Biểu đồ còn minh họa các sự kiện nào sẽ làm thay đổi trạng thái các đối tượng của lớp
Biểu đồ trạng thái có thể có một điểm bắt đầu và nhiều điểm kết thúc Trạng thái bắt đầu được vẽ là một hình tròn đặc, còn trạng thái kết thúc được biểu diễn là một hình tròn bao quanh một hình tròn đặc nhỏ Trạng thái được vẽ là hình chữ nhật có góc tròn Giữa các trạng thái là sự chuyển trạng thái, được vẽ như một đường thẳng có mũi tên đi từ đối tượng này đến đối tượng kia Để xác định được các trạng thái và các sự kiện, chúng ta cần trả lời cho các câu hỏi sau:
Một đối tượng có thể ở những trạng thái nào? Liệt kê tất cả các trạng thái có thể có trong hệ thống của mỗi đối tượng
Những sự kiện nào có thể xuất hiện? Bởi vì sự kiện có thể làm biến đổi trạng thái, do vậy từ các sự kiện có thể xác định được các trạng thái của các đối tượng
Những trạng thái mới nào sẽ xuất hiện? Từ một trạng thái, đối tượng có thể chuyển sang trạng thái mới khi một số sự kiện xác định xuất hiện
Ở mỗi trạng thái, hoạt động của đối tượng là gì?
Sự tương tác giữa các đối tượng là gì? Sự tương tác giữa các đối tượng thường gắn chặt với các trạng thái của đối tượng
Những sự kiện, hay chuyển đổi trạng thái nào là không thể xảy ra? Một số sự kiện, hay trạng thái không thể chuyển sang trạng thái khác được?
Cái gì làm cho đối tượng được tạo ra? Đối tượng được tạo ra bởi một hay một số sự kiện
Cái gì làm cho đối tượng được hủy bỏ? Đối tượng thường được loại bỏ khi không còn cần thiết nó nữa
Biểu đồ trạng thái là cần thiết vì nó giúp người phân tích, thiết kế và người lập trình hiểu, nắm bắt được các hành vi ứng xử của các đối tượng tham gia vào các ca sử dụng
Họ không chỉ cài đặt đối tượng mà còn cần phải làm cho chúng thực hiện những công việc mà hệ thống yêu cầu Tuy nhiên, biểu đồ trạng thái không được sử dụng để sinh mã tự động trong khâu lập trình sau này
Ví dụ:Biểu đồ trạng thái của lớpđoàn viên
Hình 2.4: Biểu đồ trạng thái lớp đoàn viên 2.7.2.Mô hình biểu đồ hoạt động
Biểu đồ hoạt động trong UML chỉ ra 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 Biểu đồ hành động mô tả các hành động, các kết quả của những hành động đó và:
Nhấn mạnh hơn về công việc thực hiện khi cài đặt một thao tác của từng đối tượng
Tương tự như biểu đồ trạng thái, nhưng khác chủ yếu ở chỗ nó tập trung mô tả về các hoạt động (công việc và những thao tác cần thực thi) cùng những kết quả thu được từ việc thay đổi trạng thái của các đối tượng
Tao ho so Nhap thong tin ho so co doan vien moi nhap thong tin kiem tra thong tin ho so kiem tra luu thong tin vao co so du lieu Xem ho so chon ho so neu nghi hoc chon delete
Xoa co so du lieu kiem tra, dung luu vao co so du lieu
Trạng thái trong biểu đồ hành động là các trạng thái hoạt động, nó sẽ được chuyển sang trạng thái sau, nếu hành động ở trạng thái khác được hoàn thành.
Mô hình biểu đồ kiến trúc vật lý và phát sinh mã trình
2.8.1 Mô hình biểu đồ thành phần
Biểu đồ thành phần mô tả thành phần phần mềm cũng như sự phụ thuộc lẫn nhau giữa chúng, đồng thời biểu diễn cấu trúc của mã chương trình Các thành phần của hệ thống có thể là:
Thành phần nguồn: thành phần nguồn có ý nghĩa vào lúc dịch Thông thường là một tập tin mã nguồn cài đặt một hay nhiều lớp
Thành phần nhị phân: thành phần nhị phân thường là mã đối tượng được sinh ra sau khi dịch thành phần nguồn Có thể là một tập tin mã đối tượng, tập tin thư viện tĩnh hay tập tin thư viện động Thành phần nhị phân có ý nghĩa vào lúc liên kết hoặc lúc chạy nếu là tập tin thư viện động
Thành phần thực thi: là một tập tin chương trình thực thi, được sinh ra sau khi liên kết tất cả các thành phần nhị phân Một thành phần thực thi được biểu diễn đơn vị thực thi chạy trên bởi một bộ xử lý cụ thể (máy tính)
Với biểu đồ thành phần, người phát triển hệ thống thực hiện dịch, triển khai hệ thống sẽ biết thư viện mã trình nào tồn tại và những tệp có thể thực thi khi dịch và liên kết thành công
Quan hệ phụ thuộc giữa các thành phần được biểu diễn bằng một đường mũi tên đứt nét Kết nối phụ thuộc cho biết thành phần phụ thuộc phải dịch sau thành phần kia Lưu ý, nên tránh phụ thuộc vòng trong biểu đồ thành phần
Biểu đồ thành phần được xem như là tập các biểu tượng thành phần biểu diễn cho các thành phần vật lý trong một hệ thống Ý tưởng cơ bản của biểu đồ thành phần là tạo ra cho những người thiết kế và phát triển hệ thống một bức tranh chung về các thành phần của hệ thống
2.8.2 Mô hình biểu đồ triển khai
Biểu đồ triển khai chỉ ra cấu hình các phần tử xử lý lúc chương trình chạy, các nút trên mạng và các tiến trình phần mềm thực hiện trên những phần tử đó Nó chỉ ra mối
Trang 31 quan hệ giữa các phần cứng và phần mềm của hệ thống Biểu đồ triển khai chỉ ra toàn bộ các nút trên mạng, kết nối giữa chúng và các tiến trình chạy trên chúng
Các phần tử (nút) của biểu đồ triển khai:
Bộ xử lý: bộ xử lý của máy tính, máy chủ, trạm làm việc, các bộ xử lý được đặc tả chi tiết bằng cách bổ sung thêm các thông tin: o Stereotype: để phân nhóm các bộ xử lý o Đặc tính: mô tả các tính chất vật lý của mỗi bộ xử lý như: tốc độ tính toán, dung lượng bộ nhớ, o Lịch biểu (shelduling): mô tả loại lịch biểu thời gian xử lý, bao gồm:
- Preemptive cho phép những tiến trình có mức ưu tiên cao hơn có thể chiếm quyền xử lý đối với những tiến trình có mức ưu tiên thấp hơn
- Non preemptive không có ưu tiên, một tiến trình chỉ dùng khi nó tự kết thúc
- Cyclic chỉ ra chu kì điều khiển giữa các tiến trình
- Executive các lịch biểu được điều khiển bằng thuật toán, bằng chương trình
- Manual tiến trình được điều khiển bằng người sử dụng
Thiết bị: là máy móc hay bộ phận phần cứng nhưng không phải là bộ xử lý trung tâm như: màn hình, máy in, máy vẽ, thiết bị cũng có thể đặc tả một số thông tin chi tiết như: Stereotype và một số tính chất vật lý
Tiến trình là luồng thực hiện của một chương trình trong một bộ xử lý Một chương trình thực thi được xem như là một tiến trình Các tiến trình thường được gán các mức ưu tiên và bộ xử lý sẽ thực hiện những tiến trình có mức ưu tiên cao hơn
Mối liên hệ giữa các nút trong biểu đồ triển khai được biểu diễn thông qua các liên kết truyền thông và được đánh số theo thứ tự thời gian tương tự như trong biểu đồ cộng tác Chú ý rằng các message truyền thông truyền đi giữa các nút có thể là các luồng thông tin xác định hoặc cũng có thể là các đối tượng rời rạc, ví dụ như các file, các thông tin yêu cầu,
Các dạng liên kết truyền thông có thể có trong biểu đồ triển khai là:
TCP/IP: sử dụng bộ giao thức TCP/IP để liên kết Thông thường đây là các ứng dụng dựa trên Web
SNA: cũng là ứng dụng dựa trên Web nhưng sử dụng bộ giao thức SNA
Microwave: sử dụng liên kết bằng sóng vô tuyến tần số cao
Hồng ngoại: sử dụng liên kết hồng ngoại
Giao thức không dây: liên kết sử dụng giao thức không dây khác
Ngoài các liên kết truyền thông thông thường, giữa các node còn có thể có mối quan hệ dạng phụ thuộc Mối quan hệ phụ thuộc sẽ được biểu diến bởi các mũi tên đứt nét với kiểu chính là dạng phụ thuộc giữa hai node Kết quả của biểu đồ triển khai kết hợp với biểu đồ thành phần là một mô hình triển khai hệ thống đầy đủ với các node, liên kết giữa các node và các thành phần bên trong các node đó Mô hình này được gọi chung là một mô hình vật lý của hệ thống và sẽ là cơ sở để cài đặt, tích hợp hệ thống cũng như triển khai hệ thống tới người sử dụng
BÀI TOÁN ỨNG DỤNG: QUẢN LÝ ĐOÀN VIÊN TRƯỜNG ĐẠI HỌC QUẢNG NAM
Phân tích và xây dựng bài toán
- Một trường đại học có số lượng đoàn viên tăng lên hàng năm, như vậy muốn quản lý tốt đoàn viên của trường thì cần phảicó sự hỗ trợ phần mềm quản lý đoàn viên Phần mềm này giúp cho người quản lý theo dõi, nắm bắt được thông tin của từng đoàn viên cũng như hoạt động đoàn của nhà trường
- Mỗi năm sẽ có một số lượng lớn đoàn viên mới nhập học, vì vậy người quản lý phải nhập tất cả các thông tin của đoàn viên để dễ dàng quản lý
- Khi đến đợt hiến máu hay tình nguyện, chỉ cần đoàn viên đó cung cấp mã đoàn viên cho người quản lý, thì người quản lý dễ dàng truy xuất dữ liệu đã được lưu trữ khi cần
- Mỗi năm chi đoàn phải nộp đoàn phí, người quản lý cần nhập tất cả các thông tin liên quan đến đoàn phí của chi đoàn đó vào cơ sở dữ liệu để dễ dàng thống kê khi cần 3.1.2 Yêu cầu phi chức năng của bài toán
Yêu cầu chức năng của bài toán:
- Người sử dụng: Giao diện rõ ràng, thân thiện, dễ sử dụng, đầy đủ các chức năng cho hệ thống để dễ quản lý
+ Cập nhập đầy đủ, chính xác các dữ liệu có trên hệ thống
+ Thống kê đầy đủ các yêu cầu từ người sử dụng
Yêu cầu phi chức năng của bài toán
Dùng máy tính cài win 7 trở lên, visual 2008 trở lên và sql 2008
Các công cụ, kỹ thuật sử dụng
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 chúng ta mô hình hóa hệ thống trước khi viết mã 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 hệ thống và làm cho chúng ta
Trang 34 có thể thiết kế được 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 cases, objects, component và deployment nodes, 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
- Enterprise_Architect: là một môi trường giúp thiết kế và xây dựng phần mềm, mô hình hóa quy trình kinh doanh, phát triển hệ thống nhúng và thời gian thực Với khả năng tích hợp quản lý các yêu cầu, Enterprise Architect giúp người dùng có thể truy vết ở mức độ cao những mô hình đặc tả phân tích, thiết kế, thực thi, kiểm thử, bảo trì sử dụng UML, SysML, BPMN và các mô hình chuẩn khác Enterprise architect là một công cụ thiết kế đồ họa đa người dùng hỗ trợ mạnh mẽ một nhóm phát triển và bảo trì hệ thống Enterprise Architect là một công cụ mạnh giúp phát triển nhiều hệ thống khác nhau, tuy nhiên, trong khuôn khổ tài liệu, sẽ chỉ đề cập tới những hỗ trợ trong việc phát triển phần mềm
Là một công cụ quản lý dữ liệu được sử dụng phổ biến ở nhiều lĩnh vực Nếu bạn không có nhiều thời gian để nghiên cứu sâu về tin học mà lại có nhiều dữ liệu cần phải được phân tích, xử lý, thì hãy dùng SQL vì SQL đơn giản nhưng rất hiệu quả Hầu hết tất cả các ngôn ngữ lập trình cấp cao đều có hỗ trợ SQL
Microsoft Visual Studio là một môi trường phát triển tích hợp (IDE) từ Microsoft
Nó được sử dụng để phát triển chương trình máy tính cho Microsoft Windows, cũng như các trang web, các ứng dụng web và các dịch vụ web Visual Studio sử dụng nền tảng phát triển phần mềm của Microsoft như Windows API, Windows Forms, Windows Presentation Foundation, Windows Store và Microsoft Silverlight Nó có thể sản xuất cả hai ngôn ngữ máy và mã số quản lý
3.1.3 Yêu cầu chức năng của hệ thống
R1.1 Cập nhập tên đăng nhập của người quản lí Hiện
R1.2 Cập nhập mật khẩu của người quản lí Hiện
R1.3 Cung cấp cơ chế lưu trữ nhất quán giúp người quản lí lưu trữ thông tin tài khoản vào cơ sở dữ liệu Ẩn
R2.1 Cập nhập thông tin hồ sơ đoàn viên: thêm, sửa, xóa, lưu Hiện
R2.2 Cung cấp cơ chế lưu trữ nhất quán giúp người quản lí lưu trữ thông tin đoàn viên vào cơ sở dữ liệu Ẩn
R3.1 Cập nhập thông tin số phiếu của đoàn phí: thêm, sửa, xóa, lưu Hiện
R3.2 Tính tiền đoàn phí theo từng lớp, in hóa đơn thu tiền đoàn Hiện
R3.3 Cung cấp cơ chế lưu trữ nhất quán giúp người quản lí lưu trữ thông tin đoàn phí vào cơ sở dữ liệu Ẩn
R4.1 Tìm kiếm thông tin đoàn viên theo tên, theo mã hoặc theo chi đoàn
R5.1 Thống kê số lượng đoàn viên, đoàn phí, hiến máu Hiện
R6.1 Cập nhập thông chi đoàn: thêm, sửa, xóa, lưu Hiện
R6.2 Cung cấp cơ chế lưu trữ nhất quán giúp người quản lí lưu trữ thông tin chi đoàn vào cơ sở dữ liệu Ẩn
R7.1 Cập nhập thông tin hoạt động đoàn: thêm, sửa, xóa, lưu Hiện
R7.2 Cung cấp cơ chế lưu trữ nhất quán giúp người quản lí lưu trữ thông tin hoạt động của đoàn viên vào cơ sở dữ liệu Ẩn
R8.1 Cập nhập thông tin đoàn viên hiến máu: thêm, sửa, xóa, lưu Hiện
R8.2 Cung cấp cơ chế lưu trữ nhất quán giúp người quản lí lưu trữ thông tin đoàn viên hiến máu vào cơ sở dữ liệu Ẩn
Phân tích hệ thống
3.2.1 Biểu đồ ca sử dụng
- Cập nhập thông tin đoàn viên
- Cập nhập thông tin đoàn phí
- Thống kê đoàn viên, đoàn phí
- Cập nhập hoạt động đoàn
Tên Use-Case: Đăng nhập ID: 1 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý muốn đăng nhập vào hệ thống
Mô tả vắn tắt: Usecase này mô tả người quản lý đăng nhập vào hệ thống bằng tài khoản đã được tạo trước đó để thực hiện các chức năng của hệ thống
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Hệ thống yêu cầu actor nhập tên đăng nhập, mật khẩu
- Actor nhập tên đăng nhập, mật khẩu của mình và nhấn nút đăng nhập
- Hệ thống kiểm tra thông tin đăng nhập
- Hệ thống thông báo thành công và cho actor đăng nhập vào hệ thống
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Nếu thông tin đăng nhập không hợp lệ thì hệ thống thông báo yêu cầu người dùng đăng nhập lại
Tên Use-Case: Cập nhập đoàn viên ID: 2 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý muốn xem thông tin của đoàn viên
Mô tả vắn tắt: Usecase này mô tả người quản lý đăng nhập vào hệ thống và xem thông tin của đoàn viên, có thể cập nhập mới hoặc điều chỉnh thông tin khi có sự thay đổi, xóa bỏ đoàn viên nếu đoàn viên đó nghĩ học
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Quản lý thông tin các đoàn viên tại trường
- Nếu có đoàn viên mới thì tiến hành cập nhập hồ sơ
- Chỉnh sửa thông tin của đoàn viên khi sai sót và xóa đoàn viên nếu nghĩ học, sau đó lưu vào cơ sở dữ liệu
- Tìm kiếm thông tin khi có yêu cầu
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Nếu thông tin đoàn viên sai thì điều chỉnh
Tên Use-Case: Cập nhập đoàn phí ID: 3 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý xem thông tin của từng hóa đơn
Mô tả vắn tắt: Người quản lý đăng nhập vào hệ thống và xem thông tin của hóa đơn, có thể cập nhập mới hoặc điều chỉnh thông tin khi có sự thay đổi
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Cập nhập số phiếu (hóa đơn) từng chi đoàn, rồi tính tiền của chi đoàn theo năm học
- Chỉnh sửa thông tin hóa đơn khi sai sót, xóa thông tin của những hóa đơn dư thừa sau đó lưu vào cơ sở dữ liệu
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Nếu thông tin hóa đơn sai thì điều chỉnh lại
Tên Use-Case: Cập nhập hoạt động đoàn
ID: 4 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý xem thông tin của hoạt động
Mô tả vắn tắt: Người quản lý đăng nhập vào hệ thống và xem thông tin của hoạt động, có thể cập nhập mới hoặc điều chỉnh thông tin khi có sự thay đổi
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Quản lý thông tin các hoạt động tại trường
- Nếu có hoạt động mới thì tiến hành cập nhập thông tin
- Chỉnh sửa thông tin của hoạt động khi sai và xóa thông tin dư thừa sau đó lưu vào cơ sở dữ liệu
- Tìm kiếm thông tin khi có yêu cầu
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Tên Use-Case: Cập nhập chi đoàn ID: 5 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý muốn thống kê khi có yêu cầu
Mô tả vắn tắt: Người quản lý đăng nhập vào hệ thống và xem thông tin của chi đoàn, có thể cập nhập mới hoặc điều chỉnh thông tin khi có sự thay đổi
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Quản lý thông tin các chi đoàn tại trường
- Nếu có chi đoàn mới thì tiến hành thêm hồ sơ
- Chỉnh sửa thông tin của chi đoàn khi sai
- Tìm kiếm thông tin khi có yêu cầu
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Tên Use-Case: Thống kê ID: 6 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý muốn thống kê khi có yêu cầu
Mô tả vắn tắt: Usecase này mô tả người quản lý yêu cầu thống kê đoàn viên, tiền đoàn phí và hệ thống sẽ gửi lại kết quả thống kê
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Người quản lý yêu cầu thống kê đoàn viên, tiền đoàn phí, đoàn viên tham gia hiến máu
- Sau đó hệ thống thống kê và phản hồi lại cho người quản lý
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Tên Use-Case: Tìm kiếm ID: 7 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý muốn tìm kiếm khi có yêu cầu
Mô tả vắn tắt: Usecase này mô tả người quản lý yêu cầu tìm kiếm đoàn viên theo tên, theo mã hoặc theo chi đoàn, tìm kiếm thông tin của những đoàn viên hiến máu, tham gia các hoạt động tình nguyện
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Người quản lý yêu cầu hệ thống tìm kiếm theo yêu cầu
- Khi có kết quả thì hệ thống sẽ phản hồi lại cho người quản lý
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Tên Use-Case: Ngân hàng máu sống ID:8 Mức độ quan trọng: Cao
Kiểu Use-Case: Chi tiết, cần thiết
Những người tham gia và quan tâm:
Người quản lý muốn xem thông tin của đoàn viên tham gia hiến máu
Mô tả vắn tắt: Usecase này mô tả người quản lý sau khi đăng nhập vào hệ thống có thể xem thông tin của đoàn viên hến máu, sửa thông tin khi sai sót và xóa những thông tin dư thừa trong cơ sở dữ liệu
Người quản lý sau khi đăng nhập tài khoản và muốn sử dụng phần mềm
Kết hợp (Association): Người quản lý
Các luồng sự kiện thông thường:
- Cho phép xem thông tin của đoàn viên hiến máu
- Nếu có đoàn viên mới hiến máu thì tiến hành lập hồ sơ
- Khi thông tin của đoàn viên có sai sót thì yêu cầu sửa, xóa thông tin dư thừa sau đó lưu tất cả vào cơ sở dữ liệu
Các luồng sự kiện con:
Các luồng sự kiện thay thế/ngoại lệ:
Hình3.1: Sơ đồ Use Case tổng quát cho quản lý đoàn viên
Xác định các lớp biên
Lớp biên là các lớp nhằm chuyển đổi thông tin giao tiếp giữa các tác nhân và hệ thống Đó chính là các giao diện để tác nhân giao tiếp với hệ thống, cho phép thu thập thông tin hay xuất các kết quả Mỗi cặp tác nhân-ca sử dụng có ít nhất 01 lớp biên
Dựa vào các ca sử dụng đã được xây dựng ở trên, hệ thống có các lớp biên như sau:
Đố i v ớ i ca s ử d ụ ng Đă ng nh ậ p:
- Lớp I_NQL_DN: Giao diện cho phép người quản lý nhập các thông tin đăng nhập vào hệ thống
Đố i v ớ i ca s ử d ụ ng qu ả n lý đ oàn viên
- Lớp I_NQL_QLDV: Giao diện chính giao tiếp giữa tác nhân người quản lý với hệ thống
- Lớp I_NQL_CapnhatHSDV: Giao diện cho phép người quản lý thêm, sửa, xóa thông tin hồ sơ của đoàn viên
- Lớp I_NQL_TKDV: Giao diện cho phép người quản lý tìm kiếm đoàn viên theo mã, theo tên, chi đoàn,
Đố i v ớ i ca s ử d ụ ng qu ả n lý chi đ oàn
- Lớp I_NQL_QLCD: Giao diện chính giao tiếp giữa tác nhân người quản lý và hệ thống
- Lớp I_NQL_CapnhatHSCD: Giao diện cho phép người quản lý thêm, sửa, xóa thông tin chi đoàn trong hồ sơ
- Lớp I_NQL_TKCD: Giao diện cho người quản lý tìm kiếm chi đoàn theo khoa
Đố i v ớ i ca s ử d ụ ng th ố ng kê
- Lớp I_NQL_TK: Giao diện chính giao tiếp giữa tác nhân người quản lý với hệ thống
- Lớp I_NQL_TKDV: Giao diện cho phép người quản lý thống kê đoàn viên theo chi đoàn
Đố i v ớ i ca s ử d ụ ng qu ả n lý ho ạ t độ ng đ oàn
- Lớp I_NQL_HDD: Giao diện chính giao tiếp giữa tác nhân người quản lý và hệ thống
- Lớp I_NV_QLHDD: Giao diện cho phép người quản lý thêm, sửa, xóa thông tin các hoạt động đoàn trong hồ sơ
Đố i v ớ i ca s ử d ụ ng qu ả n lý đ oàn phí
- Lớp I_NQL_DP: Giao diện chính giao tiếp giữa tác nhân người quản lý và hệ thống
- Lớp I_NQL_CapNhapDP: Giao diện cho phép người quản lý tạo hóa đơn mới, cập nhập, thêm, sửa, xóa thông tin hóa đơn lưu trong hồ sơ
Đố i v ớ i ca s ử d ụ ng qu ả n lý ngân hàng máu s ố ng
- Lớp I_NQL_HM: Giao diện chính giao tiếp giữa tác nhân người quản lý và hệ thống
- Lớp I_NV_CapNhapHM: Giao diện cho phép người quản lý thêm, sửa, xóa thông tin các đoàn viên hiến máu trong hồ sơ
Xác định các lớp điều khiển
Lớp điều khiển là các lớp điều hành sự diễn biến trong một ca sử dụng Các lớp điều khiển chứa các quy tắc nghiệp vụ và đứng trung gian giữa lớp biên và lớp thực thể, cho phép từ màn hình có thể truy xuất được các thông tin chứa trong các lớp thực thể Mỗi ca sử dụng có ít nhất một lớp điều khiển
Các lớp điều khiển chính của hệ thống:
- Lớp C_NQL_DN: Lớp điều khiển cho ca sử dụng đăng nhập hệ thống
- Lớp C_NQL_QLHSDV: Lớp điều khiển cho ca sử dụng quản lí hồ sơ đoàn viên
- Lớp C_NQL_QLHSCD: Lớp điều khiển cho quản lý hồ sơ chi đoàn
- Lớp C_NQL_QLDP: Lớp điều khiển cho ca sử dụng quản lý hồ sơ đoàn phí
- Lớp C_NQL_QLHDD: Lớp điều khiển cho ca sử dụng quản lý hoạt động đoàn
- Lớp C_NQL_QLHM: Lớp điều khiển cho ca sử dụng quản lý ngân hàng máu sống
Xác định các lớp thực thể
Lớp: Đoàn viên (DoanVien1) gồm các thuộc tính sau: o MaDV: Mã đoàn viên do trường qui định o HoTen: Họ tên đoàn viên o NgaySinh: Ngày sinh của đoàn viên o MaCD: Mã chi đoàn do trường qui định o NgayVaoDoan: Ngày vào đoàn o KhoaHoc: Khóa học của đoàn viên o BiThuLCD: Bí thư liên chi đoàn o PhoBiThuLCD: Phó bí thư liên chi đoàn o UyVienLCD: Ủy viên liên chi đoàn o BiThuCD: Bí thư chi đoàn o PhoBiThuCD: Phó bí thư chi đoàn o UyVienCD: Ủy viên chi đoàn o GhiChu: Ghi chú o GioiTinh: Giới tính của đoàn viên
Lớp: Chi Đoàn (ChiDoan) gồm các thuộc tính sau: o MaCD: Mã chi đoàn do trường qui định o TenCD: Tên chi đoàn do trường qui định o MaLCD: Mã liên chi đoàn o TenLCD: Tên liên chi đoàn
Lớp: Đoàn Viên Hoạt Động (DoanVienHoatDong) gồm các thuộc tính sau: o MaDV: Mã đoàn viên do trường qui định o MaHoatDong: Mã hoạt động o GhiChu: Ghi chú
Lớp: Hiến Máu (HienMau) gồm các thuộc tính sau: o MaHienMau: Mã hiến máu o MaDV: Mã đoàn viên do trường qui định o NhomMau: Nhóm máu của đoàn viên o HienMauOTruong: Hiến máu ở trường
Trang 49 o HienMauCapCuu: Hiến máu cấp cứu o TongLan: Tổng lần hiến máu o SDT: Số điện thoại của đoàn viên hiên máu o GhiChu: Ghi chú
Lớp: Hoạt Động (HoatDong) gồm các thuộc tính sau: o MaHoatDong: Mã hoạt động o TenHD: Tên hoạt động khi tham gia o DiaDiem: Địa điểm hoạt động o ThoiGianBatDau: Thời gian bắt đầu hoạt động o ThoiGianKetThuc: Thời gian kết thúc hoạt động
Lớp: Thu Đoàn Phí (ThuDoanPhi) gồm các thuộc tính sau: o SoPhieu: Số phiếu do chi đoàn nộp tiền o MaDV: Mã đoàn viên do trường qui định o MaCD: Mã chi đoàn do trường qui định o LyDoNop: Lý do nộp tiền o NgayNop: Ngày nộp tiền của chi đoàn o SoLuong: Số lượng đoàn viên nộp tiền o Tien: Tiền mỗi người nộp là bao nhiêu o TongTien: Tổng tiền của chi đoàn nộp
Biểu đồ tuần tự cho ca sử dụng Đăng nhập:
Hình 3.2: Biểu đồ tuần tự cho sa sử dụng đăng nhập
Biểu đồ tuần tự cho ca sử dụng Cập nhập đoàn viên:
Hình 3.3 Biểu đồ tuần tự cho ca sử dụng Cập nhập đoàn viên
Chương trình demo
Khi người quản lý đăng nhập đúng tên và mật khẩu thì cho phép sử dụng phần mềm Nếu đăng nhập sai thì yêu cầu nhập lại.
Hình 3.18 From đăng nhập 3.3.2 Form: Main
Form giao diện của hệ thống phần mềm
Cho phép người quản lý xem thông tin của tất cả đoàn viên Nếu có đoàn viên mới thì người quản lý thêm vào, nếu thông tin đoàn viên sai thì chỉnh sửa và xóa nếu đoàn viên nghĩ học Sau đó lưu vào cơ sở dữ liệu
Hình 3.20 Form đoàn viên 3.3.4 In danh sách đoàn viên theo chi đoàn
Hình 3.21 Form in đoàn viên theo chi đoàn
Cho phép người quản lý xem tất cả các thông tin của chi đoàn nộp tiền đoàn phí Nếu có chi đoàn nộp tiền thì người quản lý nhập tất cả các thông tin vào hóa đơn, rồi tính tiền và lưu vào cơ sở dữ liệu Sau đó in hóa đơn cho chi đoàn đã nộp tiền Nếu hóa đơn nào sai sót thì sửa lại, còn hóa đơn dư thừa thì người quản lý xóa khỏi cơ sở dữ liệu
Hình 3.22 Form hóa đơn thu tiền đoàn phí
Cho phép người quản lý nhập tất cả các thông tin của các lần hoạt động tình nguyện Nếu thông tin sai sót thì sửa và xóa thông tin dư thừa
Hình 3.23 Form hoạt động đoàn 3.3.7 Form: Danh sách đoàn viên tham gia hoạt động
Hình 3.24 Form đoàn viên tham gia tình nguyện
3.3.8 Form: Ngân hàng máu sống
Cho phép người quản lý thêm mới đoàn viên hiến máu, nếu thông tin sai sót thì yêu cầu sửa, và xóa những thông tin dư thừa Sau đó lưu vào cơ sở dữ liệu
Hình 3.25 Form hiến máu 3.3.9 Form: Hiển thị thông tin của đoàn viên hiến máu
Cho phép người quản lý tìm kiếm đoàn viên hiến máu theo số lần, sau đó in ra dữ liệu khi cần để khen thưởng
Hình 3.26 Form in danh sách đoàn viên hiến máu
Cho phép người quản lý đổi lại mật khẩu
Hình 3.27 Form đổi mật khẩu
3.3.11 Form thống kê đoàn phí
Cho phép người quản lý thống kê tiền đoàn phí
Hình 3.28 Form thống kê đoàn phí
Kiểm tra thử hoạt động của hệ thống đối chiếu với sơ đồ UC
Khi người quản lý muốn sử dụng phần mềm thì phải đăng nhập vào hệ thống, nếu đăng nhập đúng thì cho phép sử dụng phần mềm Nếu sai, yêu cầu nhập lại tên hoặc pass word
UC Cập nhập thông tin đoàn viên
Người quản lý sử dụng phần mềm có thể xem tất các các thông tin của đoàn viên, và mỗi năm có một lượng đoàn viên mới vào trường nên người quản lý thêm thông tin đoàn viên đó vào hồ sơ Nếu có sai sót thì chỉnh sửa hoặc xóa đoàn viên đó (nếu nghĩ học hoặc chuyển trường)
UC Cập nhập thông tin đoàn phí
Người quản lý thêm hóa đơn thu tiền đoàn khi có chi đoàn nộp qua các năm, có thể chỉnh sửa hoặc xóa khi có sai sót, sau đó in hóa đơn cho chi đoàn
UC Thống kê đoàn viên, đoàn phí
Người quản lý có thể thống kê số lượng đoàn viên của từng chi đoàn, thống kê tiền đoàn phí nộp được qua các năm học
UC Cập nhập hiến máu
Khi có đợt hiến máu, người quản lý có thể thêm đoàn viên mới hiến máu, chỉnh sửa số lần hiến máu của đoàn có trước đó, hoặc xóa những đoàn viên hiến máu đã ra trường Sau đó lưu vào cơ sở dữ liệu
UC Cập nhập hoạt động đoàn
Mỗi năm trường có một số hoạt động tình nguyện, người quản lý sẽ nhập tên tất cả các hoạt động vào hệ thống phần mềm Và nhập thông tin những đoàn viên tham gia các hoạt động tình nguyện để truy xuất dữ liệu khi cần
Kết luận: Sơ đồ UC có liên quan chặt chẽ với tất cả các hoạt động của hệ thống
