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

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 ...

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

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.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

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

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

- 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

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

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

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

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 gianbao 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ử

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

– 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

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

 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

- 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ẻ

- 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

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

- 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":

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ệ:

 Ví dụ: Đặc tả cho UC Đăng nhập quản lý đoàn viên

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 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

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:

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 <<extends>>

Bán hàng

Xem bảng giá Khách

Cập nhập đoàn viên Người Quản Lý

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 <<uses>> hoặc <<Include>>

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:

đồ

năng xác định của hệ thống

Hình eclip chứa tên của use case

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

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

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

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 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

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:

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:

: NguoiQuanLy

1: yeu cau tao moi ho so

2: tao ho so3: tao ho so

4: cap nhap ( sua, xoa)5: kiem tra

6: luu ho so vao co so du lieu

2.6 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

2.6.1 Cách tìm 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,

Name Attributes operations  Các ngăn của lớp - Ngăn chứa tên - Ngăn thuộc tính - Ngăn hành vi 2.6.2 Các kiểu lớp

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 đồ

mô hình

Lớp (class)

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

Quan hệ gộ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ệ

Mũi tên tam giác

Quan hệ phụ thuộc

Các lớp phụ thuộc lẫn nhau trong hoạt động của hệ thống

Mũi tên nét đứt

2.7 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ố

 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 soNhap thong tin ho soco doan vien moi nhap thong tin

kiem tra thong tin ho so

Xoa co so du lieukiem 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

2.8 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

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

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

3.1 Phân tích và xây dựng bài toán

3.1.1 Định nghĩa 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ý

- Người 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, Enterprise_Architect

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