XÂY DỰNG HỆ THỐNG QUẢN LÝ, ĐIỀU HÀNH CÔNG VIỆC TRỰC TUYẾN E-OFFICE TẠI TRƯỜNG ĐẠI HỌC QUẢNG NAM - Full 10 điểm

TRƯỜNG ĐẠI HỌC QUẢNG NAM KHOA CÔNG NGHỆ THÔNG TIN -----  ----- KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC XÂY DỰNG HỆ THỐNG QUẢN LÝ CÔNG VĂN, ĐIỀU HÀNH CÔNG VIỆC TRỰC TUYẾN E-OFFICE TẠI TRƯỜNG ĐẠI HỌC QUẢNG NAM Sinh viên thực hiện PHẠM VĂN QUANG MSSV: 2112011022 CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN KHÓA: 2012 – 2016 Giảng viên hướng dẫn ThS ĐỖ QUANG KHÔI Qu ả ng Nam, tháng 4 n ă m 2016 - ii - LỜI CẢM ƠN Trước hết em xin gởi lời cảm ơn sâu sắc đến ThS Đỗ Quang Khôi, người đã trực tiếp hướng dẫn, giúp đỡ, định hướng và đóng góp ý kiến cho em trong suốt thời gian làm bài để em có thể hoàn thành bài Khóa luận tốt nghiệp này Em xin chân thành cảm ơn tất cả các thầy, cô giáo trường Đại Học Quảng Nam Đặc biệt là các thầy, cô trong Khoa Công nghệ thông tin của trường đã tận tình dạy dỗ và truyền đạt kiến thức cho em trong suốt quá trình học tập và nghiên cứu tại trường, tạo điều kiện thuận lợi cho em trong thời gian cuối khóa để hoàn thành chương trình tốt nghiệp Em cũng gởi lời cảm ơn đến Trung tâm học liệu và Công nghệ thông tin trường Đại Học Quảng Nam đã tạo điều kiện giúp đỡ cho em trong quá trình thực tập tốt nghiệp và những kinh nghiệm trong thực tế Đồng thời, em cũng gởi lời cảm ơn đến gia đình, bạn bè đã động viên, giúp đỡ em lúc khó khăn trong học tập và trong cuộc sống - iii - MỤC LỤC DANH MỤC BIỂU MẪU, HÌNH ẢNH vi DANH MỤC TỪ VIẾT TẮC viii I THÔNG TIN CHUNG ix II NỘI DUNG ĐỀ TÀI 1 PHẦN 1 MỞ ĐẦU 1 1 Lý do chọn đề tài 1 2 Mục đích nghiên cứu 1 3 Đối tượng và phạm vi nghiên cứu 1 4 Phương pháp nghiên cứu 2 5 Lịch sử nghiên cứu 2 6 Đóng góp của đề tài 2 7 Cấu trúc của khóa luận 2 PHẦN 2 NỘI DUNG NGHIÊN CỨU 4 Chương 1: GIỚI THIỆU VỀ UML VÀ CÁC CÔNG CỤ PHÁT TRIỂN HỆ THỐNG 4 1 1 Giới thiệu về UML 4 1 2 Một số biểu đồ trong UML và chức năng của nó 6 1 2 1 Bi ể u đồ ca s ử d ụ ng (Use Case Diagram) 6 1 2 2 Bi ể u đồ l ớ p (Class Diagram) 7 1 2 3 Bi ể u đồ ho ạ t độ ng (Activity Diagram) 8 1 2 4 Bi ể u đồ t ươ ng tác (Interaction Diagram) 8 1 2 5 Bi ể u đồ tr ạ ng thái (State Diagram) 10 1 2 6 Bi ể u đồ đố i t ượ ng (Object Diagram) 10 1 2 7 Bi ể u đồ gói (Package Diagram) 11 1 2 8 Bi ể u đồ thành ph ầ n (Component Diagram) 11 1 2 9 Bi ể u đồ tri ể n khai (Deployment Diagram) 12 1 3 Các hướng nhìn của UML 13 1 3 1 H ướ ng nhìn ng ườ i dùng (Use Case View) 14 1 3 2 H ướ ng nhìn Logic (Logical View) 15 1 3 3 H ướ ng nhìn thành ph ầ n (Component View) 15 1 3 4 H ướ ng nhìn song song (Concurrency View) 15 1 3 5 H ướ ng nhìn tri ể n khai (Deployment View) 16 1 4 Các công cụ hỗ trợ trong phân tích và thiết kế hệ thống với UML 16 1 5 Tổng kết chương 1 17 - iv - Chương 2: PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG QUẢN LÝ, ĐIỀU HÀNH CÔNG VIỆC TRỰC TUYẾN E-OFFICE 18 2 1 Khảo sát 18 2 1 1 Phát bi ể u bài toán 18 2 1 2 Kh ả o sát hi ệ n tr ạ ng th ự c t ế 18 2 1 3 Yêu c ầ u ch ứ c n ă ng c ủ a bài toán 21 2 1 4 Yêu c ầ u phi ch ứ c n ă ng c ủ a bài toán 22 2 2 Mô hình hóa yêu cầu hệ thống 23 2 2 1 Xác đị nh các tác nhân 23 2 2 2 Xác đị nh các Use Case 23 2 2 3 Bi ể u đồ ca s ử d ụ ng t ổ ng th ể c ủ a h ệ th ố ng 24 2 2 4 Đặ c t ả yêu c ầ u 25 2 3 Mô hình hóa cấu trúc hệ thống 31 2 3 1 Xác đị nh các l ớ p th ự c th ể 31 2 3 2 Xây d ự ng th ẻ CRC c ủ a các l ớ p th ự c th ể 34 2 3 3 Xác đị nh các l ớ p biên 42 2 3 4 Xác đị nh các l ớ p đ i ề u khi ể n 43 2 3 5 Bi ể u đồ l ớ p 44 2 4 Mô hình hóa hành vi của hệ thống 45 2 4 1 Bi ể u đồ tr ạ ng thái 45 2 4 2 Bi ể u đồ tu ầ n t ự 48 2 4 3 Bi ể u đồ ho ạ t độ ng 52 2 5 Thiết kế hệ thống 55 2 5 1 Thi ế t k ế chi ti ế t c ơ s ở d ữ li ệ u 55 2 5 2 Thi ế t k ế giao di ệ n 62 2 5 3 Thi ế t k ế ki ế n trúc v ậ t lý h ệ th ố ng 66 2 6 Kết luận chương 2 68 Chương 3: CHƯƠNG TRÌNH THỬ NGHIỆM 69 3 1 Cài đặt hệ thống 69 3 2 Các mô-đun chức năng của website 69 3 3 Một số giao diện chính của chương trình 70 3 3 1 Trang đă ng nh ậ p: 70 3 3 2 Trang làm vi ệ c c ủ a VT: 70 3 3 3 Trang làm vi ệ c c ủ a HT: 71 3 3 4 Trang phân công x ử lý công v ă n đế n 71 3 3 5 Trang phê duy ệ t công v ă n đ i 72 3 3 6 Trang làm vi ệ c c ủ a PHT: 73 3 3 7 Trang làm vi ệ c c ủ a LDP: 74 3 3 8 Trang làm vi ệ c c ủ a CB: 74 - v - 3 3 9 Trang báo cáo x ử lý công v ă n 75 3 4 Kết luận chương 3 75 PHẦN 3 KẾT LUẬN 76 1 Kết luận 76 2 Hướng phát triển 76 PHẦN 4 TÀI LIỆU THAM KHẢO 77 - vi - DANH MỤC BIỂU MẪU, HÌNH ẢNH Hình 1 1 - Biểu đồ use case của một công ty bảo hiểm 7 Hình 1 2 - Biểu đồ lớp cho một giao dịch Tài chính 7 Hình 1 3 - Một biểu đồ hoạt động in một văn bản 8 Hình 1 4 - Sơ đồ trình tự của Order 9 Hình 1 5 - Một sơ đồ giao tiếp cho một Order 9 Hình 1 6 - Một ví dụ về biểu đồ trạng thái 10 Hình 1 7 - Biểu đồ lớp và biểu đồ đối tượng thể hiện của lớp 11 Hình 1 8 - Một biểu đồ thành phần chỉ ra sự phụ thuộc giữa các thành phần mã 12 Hình 1 9 - Một biểu đồ triển khai chỉ ra kiến trúc vật lý của hệ thống 12 Hình 1 10 - Các View trong UML 13 Hình 2 1 - Cơ cấu tổ chức trường ĐHQN 19 Hình 2 2 – Biểu đồ UC tổng thể 24 Hình 2 3 - Biểu đồ lớp 44 Hình 2 4 – Biểu đồ trạng thái lớp chuyên viên 45 Hình 2 5 – Biểu đồ trạng thái lớp đơn vị 45 Hình 2 6 – Biểu đồ trạng thái lớp công văn đến 46 Hình 2 7 – Biểu đồ trạng thái lớp công văn đi 46 Hình 2 8 – Biểu đồ trạng thái tìm kiếm tra cứu 47 Hình 2 9 – Biểu đồ trạng thái thống kê 47 Hình 2 10 – Biểu đồ tuần tự đăng nhập 48 Hình 2 11 – Biểu đồ tuần tự thêm đơn vị 48 Hình 2 12 – Biểu đồ tuần tự xử lý công văn đến 49 Hình 2 13 – Biểu đồ tuần tự xử lý công văn đi 50 Hình 2 14 – Biểu đồ tuần tự Tìm kiếm tra cứu 51 Hình 2 15 – Biểu đồ tuần tự thống kê 51 Hình 2 16 – Biểu đồ hoạt động đơn vị 52 Hình 2 17 – Biểu đồ hoạt động xử lý công văn đến 53 Hình 2 18 – Biểu đồ hoạt động xử lý công văn đi 54 Hình 2 19 – Mô hình quan hệ 55 Hình 2 20 – Sơ đồ người máy văn thư 62 - vii - Hình 2 21 – Sơ đồ người máy hiệu trưởng 63 Hình 2 22 – Sơ đồ người máy phó hiệu trưởng 64 Hình 2 23 – Sơ đồ người máy lãnh đạo phòng 65 Hình 2 24 – Sơ đồ người máy chuyên viên 65 Hình 2 25 – Sơ đồ người máy tìm kiếm 66 Hình 2 26 – Biểu đồ thành phần 66 Hình 2 27 – Biểu đồ triển khai 67 - viii - DANH MỤC TỪ VIẾT TẮC Tên viết tắt Tên đầy đủ SysML Hệ thống mô hình hóa ngôn ngữ BPMN Ký hiệu mô hình hóa quá trình kinh doanh HTML Ngôn ngữ đánh dấu siêu văn bản HC-TH Hành chính tổng hợp DN Đăng nhập DK Đăng ký QMK Quê mật khẩu VT Văn thư HT Hiệu trưởng PHT Phó hiệu trưởng LDP Lãnh đạo phòng CB Cán bộ ND Người dùng I Interface C Controller TK Thống kê UC Use case UML Unified Modeling Language CSDL Cơ sở dữ liệu - ix - I THÔNG TIN CHUNG 1 Thông tin về sinh viên 1 1) Họ và tên: Phạm Văn Quang 1 2) Mã số SV: 2112011022 1 3) Ngành đào tạo: Công Nghệ Thông Tin 1 4) Khóa học: 2012 - 2016 1 5) Lớp học: Đại học Công nghệ thông tin K12 (DT12CTT01) 1 6) Địa chỉ liên lạc: Lớp Đại học Công nghệ thông tin K12 1 7) Số điện thoại: 0963248875 1 8) Email: vanquangpham94@gmail com 2 Đề tài 2 1) Tên đề tài: Xây dựng hệ thống quản lý, điều hành công việc trực tuyến e- Office tại Trường Đại Học Quảng Nam 3 Giảng viên hướng dẫn 3 1) Họ tên: Đỗ Quang Khôi 3 2) Chức vụ: Giám đốc Trung tâm Học liệu và Công nghệ thông tin 3 4) Học vị: Thạc sĩ 3 5) Nơi công tác: Trung tâm Học liệu và Công nghệ thông tin - Trường Đại học Quảng Nam 3 6) Số điện thoại: 0905571491 3 7) Email: doquangkhoi@qnamuni edu vn Dsad - 1 - II NỘI DUNG ĐỀ TÀI PHẦN 1 MỞ ĐẦU 1 Lý do chọn đề tài Ngày nay, công nghệ thông tin ngày càng phát triển và tỏ ra tầm quan trọng trong tất cả các lĩnh vực, có thể nói công nghệ thông tin đã trở thành thước đo để đánh giá sự phát triển của xã hội hiện đại - nơi mà con người đang dần thoát khỏi cách làm việc thủ công, thô sơ và dần tiến đến tin học hóa trong tất cả các lĩnh vực để công việc có hiệu quả hơn, tiết kiệm thời gian và nhân lực Trong bất kỳ lĩnh vực nào thì công tác quản lý luôn giữ một vai trò vô cùng quan trọng, trong đó có công tác quản lý văn bản Chính vì lẽ đó, ngay khi được học môn Phân tích, thiết kế hệ thống thông tin và Công nghệ phần mềm, nhận thức được vai trò quan trọng của việc tin học hóa trong công tác quản lý, chúng em thực hiện đề tài “Xây dựng hệ thống quản lý, điều hành công việc trực tuyến e-Office tại Trường Đại Học Quảng Nam” với hy vọng nếu đề tài thành công và có thể đưa vào ứng dụng sẽ có thể giúp cho công tác quản lý văn bản của các cơ quan, xí nghiệp đơn giản hơn, nhanh chóng hơn, hiệu quả hơn, thay thế cho cách quản lý truyền thống bằng hồ sơ, sổ sách Chính vì những lý do trên, em đã chọn đề tài “ Xây d ự ng h ệ th ố ng qu ả n lý công v ă n, đ i ề u hành công vi ệ c tr ự c tuy ế n e-Office t ạ i Tr ườ ng Đạ i H ọ c Qu ả ng Nam ” để làm luận văn tốt nghiệp 2 Mục đích nghiên cứu - Nắm vững những kiến thức cơ bản về phân tích và thiết kế hệ thống hướng đối tượng với UML, đặc biệt là một số kỹ thuật trong phân phân tích và các công cụ hỗ trợ - Áp dụng dụng phân tích thiết kế hệ thống để xây dựng và phát triển các phần mền hỗ trợ cho công việc trong cuộc sống 3 Đối tượng và phạm vi nghiên cứu - Các kỹ thuật phân tích và phát triển hệ thống theo hướng đối tượng với UML - Áp dụng xây dựng Website quản lý, điều hành công việc tại Trường Đại học Quảng Nam - 2 - 4 Phương pháp nghiên cứu - Tìm hiểu tài liệu, giáo trình, luận văn, bài báo, thông tin trên mạng, tìm hiểu thực tế - Phân tích, tổng hợp tài liệu - Thống kê, phân tích dữ liệu 5 Lịch sử nghiên cứu Với vấn đề về xây dựng hệ thống quản lý, điều hành công việc cũng đã được nhiều tác giả phân tích, nghiên cứu theo nhiều hướng khác nhau Phần lớn các tác giả đều cho thấy một cách tổng quan về quản lý công việc, đặc biệt là quản lý công văn đến, công văn đi Bên cạnh đó vẫn có một số vấn đề ít được đề cập là điều hành công việc trực tuyến Thay vì sự quản lý công văn cũng như công việc được làm thủ công và lưu trữ trên sổ sách và hồ sơ Thì vấn đề mất mát hay là có quá nhiều sổ sách cũng như hồ sơ lưu lại làm khó có thể kiểm soát, mất diện tích lưu trữ Công việc tìm kiếm gặp nhiều khó khăn v v v Vì thế việc xây dựng và thiết kế một hệ thống quản lý, điều hành công việc trực tuyến là rất cần thiết trong khi đó thì việc ứng dụng này ít được nghiên cứu Việc này sẽ giúp tin học hóa quy trình tạo độ chính xác cho đơn vị sử dụng 6 Đóng góp của đề tài Đề tài được nghiên cứu nhằm trình bày những kiến thức cơ bản và tổng quan về phân tích thiết kế hệ thống theo hướng đối tượng với UML, các kỹ thuật cơ bản trong phân tích thiết kế hệ thống theo hướng đối tượng Xây dựng Website quản lý, điều hành công việc tại Trường Đại học Quảng Nam với các chức năng cơ bản trong quản lý, điều hành công việc 7 Cấu trúc của khóa luận Lời cảm ơn Mục lục Danh mục các ký hiệu, các chữ viết tắt - 3 - Danh mục các hình vẽ, đồ thị MỞ ĐẦU 1 Lý do chọn đề tài 2 Mục đích nghiên cứu 3 Đối tượng và phạm vi nghiên cứu 4 Phương pháp nghiên cứu 5 Lịch sử nghiên cứu 6 Đóng góp của đề tài NỘI DUNG Ch ươ ng 1: Gi ớ i thi ệ u v ề UML và các công c ụ phát tri ể n h ệ th ố ng Ch ươ ng 2: Phân tích và thi ế t k ế h ệ th ố ng qu ả n lý, đ i ề u hành công vi ệ c tr ự c tuy ế n e-Office Ch ươ ng 3: Ch ươ ng trình th ử nghi ệ m KẾT LUẬN TÀI LIỆU THAM KHẢO PHỤ LỤC - 4 - PHẦN 2 NỘI DUNG NGHIÊN CỨU Chương 1: GIỚI THIỆU VỀ UML VÀ CÁC CÔNG CỤ PHÁT TRIỂN HỆ THỐNG 1 1 Giới thiệu về UML 1 1 1 L ị ch s ử ra đờ i c ủ a UML Trong bối cảnh trên, người ta nhận thấy cần thiết phải cung cấp một phương pháp tiệm cận được chuẩn hoá và thống nhất cho việc mô hình hoá hướng đối tượng Yêu cầu cụ thể là đưa ra một tập hợp chuẩn hoá các ký hiệu (Notation) và các biểu đồ (Diagram) để nắm bắt các quyết định về mặt thiết kế một cách rõ ràng, rành mạch Đã có ba công trình tiên phong nhắm tới mục tiêu đó, chúng được thực hiện dưới sự lãnh đạo của James Rumbaugh, Grady Booch và Ivar Jacobson Chính những cố gắng này dẫn đến kết quả là xây dựng được một Ngôn Ngữ Mô Hình Hoá Thống Nhất (Unifield Modeling Language – UML) UML là một ngôn ngữ mô hình hoá thống nhất có phần chính bao gồm những ký hiệu hình học, được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả các thiết kế của một hệ thống Nó là một ngôn ngữ để đặc tả, trực quan hoá, xây dựng và làm tư liệu cho nhiều khía cạnh khác nhau của một hệ thống có nồng độ phần mềm cao UML có thể được sử dụng làm công cụ giao tiếp giữa người dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm 1 1 2 UML-Ngôn ng ữ mô hình hóa th ố ng nh ấ t Ngôn ngữ mô hình hóa thống nhất (Unifield Modeling Language – UML) là một ngôn ngữ để biểu diễn mô hình theo hướng đối tượng được xây dựng bởi ba tác giả trên với chủ đích là: Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy - 5 - 1 1 3 Các giai đ o ạ n c ơ b ả n trong UML 1 1 3 1 Giai đ o ạ n nghiên c ứ u s ơ b ộ UML đưa ra khái niệm Use Case để nắm bắt các yêu cầu của khách hàng (người sử dụng) UML sử dụng biểu đồ Use case (Use Case Diagram) để nêu bật mối quan hệ cũng như sự giao tiếp với hệ thống Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía hệ thống (tức là Use case) Các tác nhân và các Use case được mô hình hóa cùng các mối quan hệ và được miêu tả trong biểu đồ Use case của UML Mỗi một Use case được mô tả trong tài liệu, và nó sẽ đặc tả các yêu cầu của khách hàng 1 1 3 2 Giai đ o ạ n phân tích Giai đoạn phân tích quan tâm đến quá trình trừu tượng hóa đầu tiên (các lớp và các đối tượng) cũng như cơ chế hiện hữu trong phạm vi vấn đề Sau khi nhà phân tích đã nhận biết được các lớp thành phần của mô hình cũng như mối quan hệ giữa chúng với nhau, các lớp cùng các mối quan hệ đó sẽ được miêu tả bằng công cụ biểu đồ lớp (class diagram) của UML Sự cộng tác giữa các lớp nhằm thực hiện các Use case cũng sẽ được miêu tả nhờ vào các mô hình động (dynamic models) của UML Trong giai đoạn phân tích, chỉ duy nhất các lớp có tồn tại trong phạm vi vấn đề (các khái niệm đời thực) là được mô hình hóa Các lớp kỹ thuật định nghĩa chi tiết cũng như giải pháp trong hệ thống phần mềm, ví dụ như các lớp cho giao diện người dùng, cho ngân hàng dữ liệu, cho sự giao tiếp, trùng hợp, v v , chưa phải là mối quan tâm của giai đoạn này 1 1 3 3 Giai đ o ạ n thi ế t k ế Trong giai đoạn này, kết quả của giai đoạn phân tích sẽ được mở rộng thành một giải pháp kỹ thuật Các lớp mới sẽ được bổ sung để tạo thành một hạ tầng cơ sở kỹ thuật Giao diện người dùng, các chức năng để lưu trữ các đối tượng trong ngân hàng dữ liệu, giao tiếp với các hệ thống khác, giao diện với các thiết bị ngoại vi và các máy móc khác trong hệ thống Các lớp thuộc phạm vi vấn đề có từ giai đoạn phân tích sẽ được "nhúng" vào hạ tầng cơ sở kỹ thuật này, tạo ra khả năng thay đổi trong cả hai phương diện: Phạm vi vấn đề và hạ tầng cơ sở Giai đoạn thiết kế sẽ đưa ra kết quả là bản đặc tả chi tiết cho giai đoạn xây dựng hệ thống - 6 - 1 1 3 4 Giai đ o ạ n xây d ự ng Trong giai đoạn xây dựng (giai đoạn lập trình), các lớp của giai đoạn thiết kế sẽ được biến thành những dòng code cụ thể trong một ngôn ngữ lập trình hướng đối tượng cụ thể (không nên dùng một ngôn ngữ lập trình hướng chức năng) Phụ thuộc vào khả năng của ngôn ngữ được sử dụng, đây có thể là một công việc khó khăn hay dễ dàng Khi tạo ra các mô hình phân tích và thiết kế trong UML, tốt nhất nên cố gắng né tránh việc ngay lập tức biến đổi các mô hình này thành các dòng code Trong những giai đoạn trước, mô hình được sử dụng để dễ hiểu, dễ giao tiếp và tạo nên cấu trúc của hệ thống Vì vậy, vội vàng đưa ra những kết luận về việc viết code có thể sẽ thành một trở ngại cho việc tạo ra các mô hình chính xác và đơn giản Giai đoạn xây dựng là một giai đoạn riêng biệt, nơi các mô hình được chuyển thành code 1 13 5 Th ử nghi ệ m Một hệ thống phần mềm thường được thử nghiệm qua nhiều giai đoạn và với nhiều nhóm thử nghiệm khác nhau Các nhóm sử dụng nhiều loại biểu đồ UML khác nhau làm nền tảng cho công việc của mình: Thử nghiệm đơn vị sử dụng biểu đồ lớp (class diagram) và đặc tả lớp, thử nghiệm tích hợp thường sử dụng biểu đồ thành phần (component diagram) và biểu đồ cộng tác (collaboration diagram), và giai đoạn thử nghiệm hệ thống sử dụng biểu đồ Use case (use case diagram) để đảm bảo hệ thống có phương thức hoạt động đúng như đã được định nghĩa từ ban đầu trong các biểu đồ này 1 2 Một số biểu đồ trong UML và chức năng của nó 1 2 1 Bi ể u đồ ca s ử d ụ ng (Use Case Diagram) Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại cảnh và mối liên kết của chúng đối với Use case mà hệ thống cung cấp Một Use case là một lời miêu tả của một chức năng mà hệ thống cung cấp Lời miêu tả Use case thường là một văn bản tài liệu, nhưng kèm theo đó cũng có thể là một biểu đồ hoạt động Các Use case được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các tác nhân (hành vi của hệ thống theo như sự mong đợi của người sử dụng), không miêu tả chức năng được cung cấp sẽ hoạt động nội bộ bên trong hệ thống ra sao Các Use case định nghĩa các yêu cầu về mặt chức năng đối với hệ thống - 7 - Hình 1 1 - Biểu đồ use case của một công ty bảo hiểm 1 2 2 Bi ể u đồ l ớ p (Class Diagram) Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống Các lớp là đại diện cho các “vật” được xử lý trong hệ thống Các lớp có thể quan hệ với nhau trong nhiều dạng: liên kết (associated - được nối kết với nhau), phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác), chuyên biệt hóa (specialized - một lớp này là một kết quả chuyên biệt hóa của lớp khác), hay đóng gói (packaged - hợp với nhau thành một đơn vị) Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên trong của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation) Biểu đồ được coi là biểu đồ tĩnh theo phương diện cấu trúc được miêu tả ở đây có hiệu lực tại bất kỳ thời điểm nào trong toàn bộ vòng đời hệ thống Một hệ thống thường sẽ có một loạt các biểu đồ lớp – chẳng phải bao giờ tất cả các biểu đồ lớp này cũng được nhập vào một biểu đồ lớp tổng thể duy nhất - và một lớp có thể tham gia vào nhiều biểu đồ lớp Hình 1 2 - Biểu đồ lớp cho một giao dịch Tài chính - 8 - 1 2 3 Bi ể u đồ ho ạ t độ ng (Activity Diagram) Một biểu đồ hoạt động chỉ ra một trình tự lần lượt của các hoạt động (activity) Biểu đồ hoạt động thường được sử dụng để miêu tả các hoạt động được thực hiện trong một thủ tục, mặc dù nó cũng có thể được sử dụng để miêu tả các dòng chảy hoạt động khác, ví dụ như trong một Use case hay trong một trình tự tương tác Biểu đồ hoạt động bao gồm các trạng thái hành động, chứa đặc tả của một hoạt động cần phải được thực hiện (một hành động - action) Một trạng thái hành động sẽ qua đi khi hành động được thực hiện xong (khác với biểu đồ trạng thái: một trạng thái chỉ chuyển sang trạng thái khác sau khi đã xảy ra một sự kiện rõ ràng !) Dòng điều khiển ở đây chạy giữa các trạng thái hành động liên kết với nhau Biểu đồ còn có thể chỉ ra các quyết định, các điều kiện, cũng như phần thực thi song song của các trạng thái hành động Biểu đồ ngoài ra còn có thể chứa các loại đặc tả cho các thông điệp được gửi đi hoặc được nhận về, trong tư cách là thành phần của hành động được thực hiện Hình 1 3 - M ộ t bi ể u đồ ho ạ t độ ng in m ộ t v ă n b ả n 1 2 4 Bi ể u đồ t ươ ng tác (Interaction Diagram) 1 2 4 1 Bi ể u đồ tu ầ n t ự Biểu đồ tuần tự (Sequence Diagram) là một trong hai biểu đồ tương tác chính, với chủ ý làm nổi bật trình tự theo thời gian của các thông điệp Nó trình bày một tập các đối tượng cùng với những thông điệp chuyển giao giữ chúng với nhau Các đối tượng ở đây thường là cá thể có tên hay khuyết danh của các lớp, song thế vào chỗ các đối tượng, cũng còn có thể là các đối tác, các hợp tác, các thành phần, các nút - 9 - Hình 1 4 - S ơ đồ trình t ự c ủ a Order 1 2 4 2 Bi ể u đồ giao ti ế p Biểu đồ giao tiếp(Communication Diagran) là một trong hai biểu đồ tương tác chính, với chủ ý làm nổi khung cảnh tổ chức của sự tương tác Nó trình bày một tập hợp các đối tượng, các kết nối giữa các đối tượng đó cùng với những thông điệp chuyển giao giữa chúng với nhau Các đối tượng nói đây thường là các cá thể có tên hay khuyết danh của các lớp, song thế vào chỗ các đối tượng, cũng còn có thể là các đối tác, các hợp tác, các thành phần, các nút Hình 1 5 - M ộ t s ơ đồ giao ti ế p c ủ a m ộ t Order - 10 - 1 2 5 Bi ể u đồ tr ạ ng thái (State Diagram) Một biểu đồ trạng thái thường là một sự bổ sung cho lời miêu tả một lớp Nó chỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng thái Một sự kiện có thể xảy ra khi một đối tượng tự gửi thông điệp đến cho nó, ví dụ như để thông báo rằng một khoảng thời gian được xác định đã qua đi, hay là một số điều kiện nào đó đã được thỏa mãn Một sự thay đổi trạng thái được gọi là một sự chuyển đổi trạng thái (State Transition) Một chuyển đổi trạng thái cũng có thể có một hành động liên quan, xác định điều gì phải được thực hiện khi sự chuyển đổi trạng thái này diễn ra Biểu đồ trạng thái không được vẽ cho tất cả các lớp, mà chỉ riêng cho những lớp có một số lượng các trạng thái được định nghĩa rõ ràng và hành vi của lớp bị ảnh hưởng và thay đổi qua các trạng thái khác nhau Biểu đồ trạng thái cũng có thể được vẽ cho hệ thống tổng thể Hình 1 6 - M ộ t ví d ụ v ề bi ể u đồ tr ạ ng thái 1 2 6 Bi ể u đồ đố i t ượ ng (Object Diagram) Biểu đồ đối tượng là một phiên bản của biểu đồ lớp và thường cũng sử dụng các ký hiệu như biểu đồ lớp Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp Biểu đồ đối tượng là một ví dụ của biểu đồ lớp, chỉ ra một bức tranh thực tế có thể xảy ra khi hệ thống thực thi, bức tranh mà hệ thống có thể có tại một thời điểm nào đó Biểu đồ đối tượng sử dụng chung các ký hiệu của biểu đồ lớp, chỉ trừ hai ngoại lệ, đối tượng được viết với tên được gạch dưới và tất cả các thực thể trong một mối quan hệ đều được chỉ ra Biểu đồ đối tượng không quan trọng bằng biểu đồ lớp, chúng có thể được sử dụng để ví dụ hóa một biểu đồ lớp phức tạp, chỉ ra với những thực thể cụ thể và những mối quan hệ như thế thì bức tranh toàn cảnh sẽ ra sao Một biểu đồ đối tượng thường thường - 11 - được sử dụng làm một thành phần của một biểu đồ cộng tác (collaboration), chỉ ra lối ứng xử động giữa một loạt các đối tượng Hình 1 7 - Bi ể u đồ l ớ p và bi ể u đồ đố i t ượ ng th ể hi ệ n c ủ a l ớ p 1 2 7 Bi ể u đồ gói (Package Diagram) - Cho thấy phần cứng của hệ thống và các phần mền trong các phần cứng và mối liên hệ giữa chúng - Deployment Diagram rất hữu ích khi giải pháp phần mềm được triển khai trên nhiều máy tính với nhau có cùng cấu hình duy nhất 1 2 8 Bi ể u đồ thành ph ầ n (Component Diagram) Một biểu đồ thành phần chỉ ra cấu trúc vật lý của các dòng lệnh (code) theo khái niệm thành phần code Một thành phần code có thể là một tập tin source code, một thành phần nhị phân (binary) hay một thành phần thực thi được (executable) Một thành phần chứa các thông tin về các lớp logic hoặc các lớp mà nó thi hành, như thế có nghĩa là nó tạo ra một ánh xạ từ hướng nhìn logic vào hướng nhìn thành phần Biểu đồ thành phần cũng chỉ ra những sự phụ thuộc giữa các thành phần với nhau, trợ giúp cho công việc phân tích hiệu ứng mà một thành phần được thay đổi sẽ gây ra đối với các thành phần khác Thành phần cũng có thể được miêu tả với bất kỳ loại giao diện nào mà chúng bộc lộ, ví dụ như giao diện OLE/COM và chúng có thể được nhóm góp lại với nhau thành từng gói (package) Biểu đồ thành phần được sử dụng trong công việc lập trình - 12 - Hình 1 8 - M ộ t bi ể u đồ thành ph ầ n ch ỉ ra s ự ph ụ thu ộ c gi ữ a các thành ph ầ n mã 1 2 9 Bi ể u đồ tri ể n khai (Deployment Diagram) Biểu đồ triển khai chỉ ra kiến trúc vật lý của phần cứng cũng như phần mềm trong hệ thống Bạn có thể chỉ ra từng máy tính cụ thể và từng trang thiết bị cụ thể (node) đi kèm sự nối kết giữa chúng với nhau, bạn cũng có thể chỉ ra loại của các mối nối kết đó Bên trong các nút mạng (node), các thành phần thực thi được cũng như các đối tượng sẽ được xác định vị trí để chỉ ra những phần mềm nào sẽ được thực thi tại những nút mạng nào Bạn cũng có thể chỉ ra sự phụ thuộc giữa các thành phần Hình 1 9 - M ộ t bi ể u đồ tri ể n khai ch ỉ ra ki ế n trúc v ậ t lý c ủ a h ệ th ố ng Biểu đồ triển khai chỉ ra hướng nhìn triển khai, miêu tả kiến trúc vật lý thật sự của hệ thống Đây là một hướng nhìn rất xa lối miêu tả duy chức năng của hướng nhìn Use - 13 - case Mặc dù vậy, trong một mô hình tốt, người ta có thể chỉ tất cả những con đường dẫn từ một nút mạng trong một kiến trúc vật lý cho tới những thành phần của nó, cho tới lớp mà nó thực thi, cho tới những tương tác mà các đối tượng của lớp này tham gia để rồi cuối cùng, tiến tới một Use Case Rất nhiều hướng nhìn khác nhau của hệ thống được sử dụng đồng thời để tạo ra một lời miêu tả thấu đáo đối với hệ thống trong sự tổng thể của nó 1 3 Các hướng nhìn của UML Mô hình hóa một hệ thống phức tạp là một việc làm khó khăn Lý tưởng nhất là toàn bộ hệ thống được miêu tả chỉ trong một bản vẽ, một bản vẽ định nghĩa một cách rõ ràng và mạch lạc toàn bộ hệ thống, một bản vẽ ngoài ra lại còn dễ giao tiếp và dễ hiểu Mặc dù vậy, thường thì đây là chuyện bất khả thi Một bản vẽ không thể nắm bắt tất cả các thông tin cần thiết để miêu tả một hệ thống Một hệ thống cần phải được miêu tả với một loạt các khía cạnh khác nhau: về mặt chức năng (cấu trúc tĩnh của nó cũng như các tương tác động), về mặt phi chức năng (yêu cầu về thời gian, về độ đáng tin cậy, về quá trình thực thi, v v và v v ) cũng như về khía cạnh tổ chức (tổ chức làm việc, ánh xạ nó vào các code module, ) Vì vậy một hệ thống thường được miêu tả trong một loạt các hướng nhìn khác nhau, mỗi hướng nhìn sẽ thể hiện một bức ảnh ánh xạ của toàn bộ hệ thống và chỉ ra một khía cạnh riêng của hệ thống Hình 1 10 - Các View trong UML Mỗi một hướng nhìn được miêu tả trong một loạt các biểu đồ, chứa đựng các thông tin nêu bật khía cạnh đặc biệt đó của hệ thống Trong thực tế khi phân tích và thiết kế rất dễ xảy ra sự trùng lặp thông tin, cho nên một biểu đồ trên thật tế có thể là thành phần của nhiều hướng nhìn khác nhau Khi nhìn hệ thống từ nhiều hướng nhìn khác nhau, tại một thời điểm có thể người ta chỉ tập trung vào một khía cạnh của hệ thống Một biểu đồ trong một hướng - 14 - nhìn cụ thể nào đó cần phải đủ độ đơn giản để tạo điều kiện giao tiếp dễ dàng, để dính liền với các biểu đồ khác cũng như các hướng nhìn khác, làm sao cho bức tranh toàn cảnh của hệ thống được miêu tả bằng sự kết hợp tất cả các thông tin từ tất cả các hướng nhìn Một biểu đồ chứa các kí hiệu hình học mô tả các phần tử mô hình của hệ thống UML có tất cả các hướng nhìn sau:  Hướng nhìn Use case (use case view): đây là hướng nhìn chỉ ra khía cạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài  Hướng nhìn logic (logical view): chỉ ra chức năng sẽ được thiết kế bên trong hệ thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như ứng xử động của hệ thống  Hướng nhìn thành phần (component view): chỉ ra khía cạnh tổ chức của các thành phần code  Hướng nhìn song song (concurrency view): chỉ ra sự tồn tại song song, trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống  Hướng nhìn triển khai (deployment view): chỉ ra khía cạnh triển khai hệ thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm công tác) 1 3 1 H ướ ng nhìn ng ườ i dùng (Use Case View) Hướng nhìn Use case miêu tả chức năng của hệ thống sẽ phải cung cấp do được tác nhân từ bên ngoài mong đợi Tác nhân là thực thể tương tác với hệ thống, đó có thể là một người sử dụng hoặc là một hệ thống khác Hướng nhìn Use case là hướng nhìn dành cho khách hàng, nhà thiết kế, nhà phát triển và người thử nghiệm, nó được miêu tả qua các biểu đồ Use case (use case diagram) và thỉnh thoảng cũng bao gồm cả các biểu đồ hoạt động (activity diagram) Cách sử dụng hệ thống nhìn chung sẽ được miêu tả qua một loạt các Use case trong hướng nhìn Use case, nơi mỗi một Use case là một lời miêu tả mang tính đặc thù cho một tính năng của hệ thống (có nghĩa là một chức năng được mong đợi) Hướng nhìn Use case mang tính trung tâm, bởi nó đặt ra nội dung thúc đẩy sự phát triển các hướng nhìn khác Mục tiêu chung của hệ thống là cung cấp các chức năng miêu tả trong hướng nhìn này – cùng với một vài các thuộc tính mang tính phi chức năng khác, - 15 - vì thế hướng nhìn này có ảnh hưởng đến tất cả các hướng nhìn khác Hướng nhìn này cũng được sử dụng để thẩm tra (verify) hệ thống qua việc thử nghiệm xem hướng nhìn Use case có đúng với mong đợi của khách hàng 1 3 2 H ướ ng nhìn Logic (Logical View) Hướng nhìn logic miêu tả phương thức mà các chức năng của hệ thống sẽ được cung cấp Chủ yếu nó được sử dụng cho các nhà thiết kế và nhà phát triển Ngược lại với hướng nhìn Use case, hướng nhìn logic nhìn vào phía bên trong của hệ thống Nó miêu tả kể cả cấu trúc tĩnh (lớp, đối tượng, và quan hệ) cũng như sự tương tác động sẽ xảy ra khi các đối tượng gửi thông điệp cho nhau để cung cấp chức năng đã định sẵn Hướng nhìn logic định nghĩa các thuộc tính như trường tồn (persistency) hoặc song song (concurrency), cũng như các giao diện cũng như cấu trúc nội tại của các lớp Cấu trúc tĩnh được miêu tả bằng các biểu đồ lớp (class diagram) và biểu đồ đối tượng (object diagram) Quá trình mô hình hóa động được miêu tả trong các biểu đồ trạng thái (state diagram), biểu đồ trình tự (sequence diagram), biểu đồ tương tác (collaboration diagram) và biểu đồ hoạt động (activity diagram) 1 3 3 H ướ ng nhìn thành ph ầ n (Component View) Là một lời miêu tả của việc thực thi các modul cũng như sự phụ thuộc giữa chúng với nhau Nó thường được sử dụng cho nhà phát triển và thường bao gồm nhiều biểu đồ thành phần Thành phần ở đây là các modul lệnh thuộc nhiều loại khác nhau, sẽ được chỉ ra trong biểu đồ cùng với cấu trúc cũng như sự phụ thuộc của chúng Các thông tin bổ sung về các thành phần, ví dụ như vị trí của tài nguyên (trách nhiệm đối với một thành phần), hoặc các thông tin quản trị khác, ví dụ như một bản báo cáo về tiến trình của công việc cũng có thể được bổ sung vào đây 1 3 4 H ướ ng nhìn song song (Concurrency View) Hướng nhìn song song nhắm tới sự chia hệ thống thành các qui trình (process) và các bộ xử lý (processor) Khía cạnh này, vốn là một thuộc tính phi chức năng của hệ thống, cho phép chúng ta sử dụng một cách hữu hiệu các nguồn tài nguyên, thực thi song song, cũng như xử lý các sự kiện không đồng bộ từ môi trường Bên cạnh việc chia hệ - 16 - thống thành các tiểu trình có thể được thực thi song song, hướng nhìn này cũng phải quan tâm đến vấn đề giao tiếp và đồng bộ hóa các tiểu trình đó Hướng nhìn song song giành cho nhà phát triển và người tích hợp hệ thống, nó bao gồm các biểu đồ động (trạng thái, trình tự, tương tác và hoạt động) cùng các biểu đồ thực thi (biểu đồ thành phần và biểu đồ triển khai) 1 3 5 H ướ ng nhìn tri ể n khai (Deployment View) Cuối cùng, hướng nhìn triển khai chỉ cho chúng ta sơ đồ triển khai về mặt vật lý của hệ thống, ví dụ như các máy tính cũng như các máy móc và sự liên kết giữa chúng với nhau Hướng nhìn triển khai giành cho các nhà phát triển, người tích hợp cũng như người thử nghiệm hệ thống và được thể hiện bằng các biểu đồ triển khai Hướng nhìn này cũng bao gồm sự ánh xạ các thành phần của hệ thống vào cấu trúc vật lý, ví dụ như chương trình nào hay đối tượng nào sẽ được thực thi trên máy tính nào 1 4 Các công cụ hỗ trợ trong phân tích và thiết kế hệ thống với UML Enterprise Architect là một môi trường giúp thiết kế và xây dựng phần mềm, mô hình hóa quy trình kinh doanh, phát triển hệ thống nhúng và thời gian thực Với khả năng tích hợp quản lý các yêu cầu, Enterprise Architect giúp người dùng có thể truy vết ở mức độ cao những mô hình đặc tả phân tích, thiết kế, thực thi, kiểm thử, bảo trì sử dụng UML, SysML, BPMN và các mô hình chuẩn khác Enterprise Architect là một công cụ thiết kế đồ họa đa người dùng hỗ trợ mạnh mẽ một nhóm phát triển và bảo trì hệ thống Enterprise Architect được đánh giá cao về: - Mô hình hóa toàn diện UML 2 1 - Tích hợp quản lý yêu cầu - Mở rộng hỗ trợ quản lý dự án, bao gồm những tài nguyên, kiểm thử - Hỗ trợ kiểm thử: kiểm thử trường hợp (test case), hỗ trợ Junit và Nunit - Tùy chọn tài liệu linh động: viết cáo báo định dạng HTML, RTF - Hỗ trợ kỹ thuật mã hóa bởi nhiều ngôn ngữ - 17 - - Được đánh giá cáo về tính khả dụng, tốc độ, sự ổn định và giá cả Từ những ưu điểm nổi bật trên, Enterprise Architect mang lại những lợi ích: - Mô hình hóa và quản lý những thông tin phức tạp - Mô hình, quản lý và truy vết các yêu cầu - Hợp nhất đội và chia sẻ tầm nhìn - Thiết kế xây dựng những hệ thống đa dạng sử dụng UML - Hiển thị, kiểm soát và hiểu được những phần mềm phức tạp - Sử dụng đầy đủ mô hình hóa chu trình vòng đời và quản lý dự án - Chia sẻ và sử dụng lại những thông tin giữa các công cụ khác nhau - Tạo những mô hình độc lập với môi trường nền tảng bằng kiến trúc mô hình hóa điều khiển 1 5 Tổng kết chương 1 Chương 1 đã giới thiệu về UML và các công cụ phát triển hệ thống với mục đích chính là dùng các biểu đồ hướng đối tượng để mô tả hệ thống Trên cơ sở ngôn ngữ UML, đề tài tập trung phân tích và thiết kế hệ thống Quản lý công văn và điều hành văn bản trực tuyến e-Office tại trường Đại Học Quảng Nam trong Chương 2 - 18 - Chương 2: PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG QUẢN LÝ, ĐIỀU HÀNH CÔNG VIỆC TRỰC TUYẾN E-OFFICE 2 1 Khảo sát 2 1 1 Phát bi ể u bài toán Quản lý công văn và điều hành công việc là một nhiệm vụ thiết yếu và cần thiết của bất kỳ tổ chức đơn vị nào Hiện tại việc quả lý công văn của Trường Đại Học Quảng Nam là do phòng Hành Chính-Tổng Hợp đảm nhiệm Quy trình quản lý và xử lý công văn của phòng Hành Chính-Tổng Hợp hiện nay còn quá thô sơ Lưu trữ và xử lý còn thủ công làm việc trê giấy Dễ xảy ra sai sót và nhầm lẫn 2 1 2 Kh ả o sát hi ệ n tr ạ ng th ự c t ế 2 1 2 1 Ch ứ c n ă ng, nhi ệ m v ụ c ủ a t ổ ch ứ c c ủ a phòng Hành Chính-T ổ ng H ợ p Chức năng chủ yếu là tham mưu cho Hiệu trưởng về công tác hành chính, tổng hợp, pháp chế và quản lý, vận hành hệ thống kỹ thuật CNTT tại khu B Trên cơ sở đó, tổ chức thực hiện các nhiệm vụ chủ yếu sau đây: 1 Xây dựng các chương trình và kế hoạch công tác của trường, tổ chức theo dõi và đôn đốc hoạt động của các đơn vị trong trường thực hiện chương trình, kế hoạch công tác lập các biểu và báo cáo thống kê theo yêu cầu của cấp trên và của trường, chịu trách nhiệm về pháp lý, thể thức trong công tác thông tin nội bộ và ra bên ngoài Thường xuyên rà soát, kiểm soát các văn bản do các đơn vị trong trường tham mưu, đảm bảo việc ban hành các văn bản đúng pháp luật trước khi trình Hiệu trưởng ký và đóng dấu Hàng năm xây dựng kế hoạch và tổ chức tuyên truyền các văn bản pháp luật theo quy định 2 Tổ chức soạn thảo các văn bản, quy định thuộc lĩnh vực được phân công phụ trách theo sự chỉ đạo của Hiệu trưởng Giúp Hiệu trưởng điều hành mối quan hệ, lề lối làm việc giữa các đơn vị trong toàn trường theo chức năng, nhiệm vụ đã quy định Chịu trách nhiệm sao, gửi các văn bản do lãnh đạo trường ký đến các cá nhân, đơn vị trong và ngoài trường đúng thời gian - 19 - 3 Xây dựng và đề xuất Hiệu trưởng ban hành quy định về quản lý công tác văn thư - lưu trữ của trường Trực tiếp quản lý công tác hành chính, văn thư - lưu trữ cấp trường, đóng dấu, quản lý con dấu trường và của trung tâm Ngoại ngữ - Tin học, quản lý chữ ký các cấp lãnh đạo của trường được Hiệu trưởng phân cấp ký, đóng dấu, mua, in ấn, quản lý, cấp phát phôi bằng, chứng chỉ, chứng nhận, cấp giấy công tác, giấy giới thiệu, nhận bưu phẩm, sao lục các văn bản của trường và cấp trên theo quy định Tiếp nhận, phân loại văn bản của các đơn vị trong và ngoài trường 2 1 2 2 C ơ c ấ u t ổ ch ứ c Hình 2 1 - C ơ c ấ u t ổ ch ứ c tr ườ ng Đ HQN - 20 - 2 1 2 3 Các quy trình ho ạ t độ ng  Quy trình gi ả i quy ế t công v ă n đế n: Tiếp nhận văn bản và phân loại văn bản (1) Vào sổ đóng dấu đến, ghi ngày đến và đăng ký văn bản (2) Trình Hiệu trưởng phê duyệt cho ý kiến chỉ đạo (3) Văn thư nhận lại văn bản từ Hiệu trưởng vào sổ theo dõi làm thủ tục luân chuyển đến các đơn vị (4) Gởi văn bản đến các đơn vị, cá nhân (5) Quản lý, lưu trữ văn bản (6) Di ễ n gi ả i quy trình: Bước 1: Văn thư chịu trách nhiệm tiếp nhận và phân loại văn bản Bước 2: Văn thư vào sổ đóng dấu đến, ghi ngày đến và đăng ký văn bản Bước 3: Văn thư trình Hiệu trưởng phê duyệt cho ý kiến chỉ đạo Bước 4: Văn thư nhận lại văn bản từ Hiệu trưởng vào sổ theo dõi làm thủ tục luân chuyển đến các đơn vị Bước 5: Văn thư chuyển văn bản tới các đơn vị, các nhân theo đúng phê duyệt của Hiệu trưởng Bước 6: Quản lý và lưu trữ văn bản theo quy định - 21 -  Quy trình gi ả i quy ế t công v ă n đ i: Đơn vị chức năng soạn thảo văn bản (1) Lãnh đạo đơn vị kiểm tra nội dung văn bản (2) Chuyên viên hoặc Văn thư đơn vị tập hợp văn bản gởi đến phòng HC-TH (3) Phòng HC- TH kiểm tra thể thức văn bản và pháp lý (4) Văn thư phòng HC-TH trình Hiệu trưởng ký phê duyệt (5) Văn thư phòng HC-TH nhận lại văn bản và xử lý văn bản (6) Quản lý, lưu trữ văn bản (7) Di ễ n gi ả i quy trình: Bước 1: Chuyên viên hoặc văn thư đơn vị được giao nhiệm vụ có trách nhiệm soạn thảo văn bản Bước 2: Lãnh đạo đơn vị kiểm tra, ký nháy và chịu trách nhiện nội dung văn bản (Lãnh đạo đơn vị ký nháy sau chữ cuối cùng(sau dâu / ) của nội dung văn bản) Bước 3: Chuyên viên hoặc văn thư đơn vị chuyển văn bản đến phòng HC-TH Bước 4: Lãnh đạo phòng HC-TH kiểm tra, ký nháy và chịu trách nhiệm về thể thức văn bản và pháp lý Bước 5: Văn thư phòng HC-TH trình Hiệu trưởng ký duyệt Bước 6: Văn thư phòng HC-TH nhận lại văn bản đã ký, đóng dấu, vào sổ theo dõi, và làm thủ tục gởi văn bản tới các đơn vị trong, ngoài trường Bước 7: Quản lý, lưu trữ văn bản theo quy định 2 1 3 Yêu c ầ u ch ứ c n ă ng c ủ a bài toán  Các ch ứ c n ă ng đă ng nh ậ p, đă ng ký: - Đăng nhập bằng tài khoản của mỗi người dùng đã được phân quyền - 22 - - Đăng ký tài khoản - Quên mật khẩu - Liên hệ người quản trị hệ thống khi cần giúp đỡ  Các ch ứ c n ă ng x ử lý công v ă n đế n: - Cập nhật công văn đến - Quản lý sổ công văn đến - Xử lý sau khi nhận công văn đến - Nhận báo cáo  Các ch ứ c n ă ng x ử lý công v ă n đ i: - Cập nhật công văn đi - Quản lý sổ công văn đi - Phát hành dự thảo công văn đi - Duyệt công văn đi - Phát hành công văn đi  Các ch ứ c n ă ng tìm ki ế m tra c ứ u: - Người dùng tìm kiếm tra cứu công văn theo quyền hạn của mình  Các ch ứ c n ă ng th ố ng k ế : - Văn thư trường là người trực tiếp thực hiện thống kê và in sổ công văn đến và đi để báo cáo cho Lãnh đạo 2 1 4 Yêu c ầ u phi ch ứ c n ă ng c ủ a bài toán - Giao diện hài hòa, thẫm mỹ, dễ thao tác, thực hiện - Phần mềm được sử dụng trên môi trường Web Nên tất cả các máy tính, laptop, ipad, smatphone… đều có thể truy cập được - Bảo mật: Mỗi người dùng trong hệ thống cần được cấp phép truy cập các chức năng và thông tin cần thiết liên quan đến nhiêm vụ và trách nhiệm của mình, đồng thời không được truy cập đến các chức năng nằm ngoài phạm vi trách nhiệm của mình Việc - 23 - phân quyền làm việc do quản trị hệ thống đảm nhận Vì đây là hệ thống của nhà trường nên việc bảo mật thông tin sẽ được bảo mật một cách tốt nhất - Đảm bảo toàn vẹn dữ liệu 2 2 Mô hình hóa yêu cầu hệ thống 2 2 1 Xác đị nh các tác nhân 1 Hiệu Trưởng 2 Phó Hiệu Trưởng 3 Văn Thư 4 Lãnh Đạo Phòng 5 Chuyên viên 2 2 2 Xác đị nh các Use Case (ca s ử d ụ ng)  Đăng nhập hệ thống: mô tả người dùng đăng nhập vào hệ thống bằng tài khoản đã được tạo trước đó hoặc có thể đăng ký để thực hiện các chức năng của hệ thống  Quản lý danh mục dữ liệu: mô tả việc văn thư khai báo, cập nhật các dữ liệu ban đầu cho hệ thống, như: Loại văn bản, chuyên viên, đon vị, đơn vị ngoài, các bộ ngoài…  Xử lý công văn đến: mô tả sau khi văn thư nhận được công văn đến và đưa lên hệ thống trình Hiệu Trưởng Hiệu Trưởng phân công xử lý hoặc chuyển phân công cho Hiệu Phó Nếu Hiệu Trưởng phân công thì Hiệu Phó thực hiện chức năng phân công xử lý Nếu đơn vị nào được nhận xử lý thì Lãnh Đạo đơn vị có trách nhiệm phân công xử lý cho các bộ trong phòng hoặc trực tiếp xử lý công văn và lập báo cáo lên cho cấp trên  Xử lý công văn đi: mô tả khi một đơn vị nào có nhu cầu phát hành một công văn đi Các bộ đơn vị phát hành dự thảo công văn đi và gởi cho Lãnh Đạo phòng Lãnh Đạo phòng xem xét, yêu cầu sửa hoặc gởi cho Văn Thư Văn Thư xem xét, yêu cầu sửa hoặc gởi cho Hiệu Trưởng Hiệu Trưởng xem xét, sửa, duyệt ban hành công văn hoặc phân công duyệt cho Hiệu Phó Sau khi quá trình này hoàn thành Văn Thư thực hiện việc ban hành công văn đi - 24 -  Tìm kiếm tra cứu công văn: mô tả người dùng có thể tìm kiếm tra cứu những công văn theo quyền hạn của mình  Thống kê: Văn thư trường thực hiện chức năng in sổ công văn để báo cáo 2 2 3 Bi ể u đồ ca s ử d ụ ng t ổ ng th ể c ủ a h ệ th ố ng uc uctongthe HieuTruong VanThu LanhDaoPhong CacBoPhong PhoHieuTruong Dang Nhap Xu Ly Cong Van Den Xu Ly Cong Van Di Tim Kiem Tra Cuu Thong Ke Kiem tra tai khoan Quan ly danh muc «include» Hình 2 2 – Bi ể u đồ UC t ổ ng th ể - 25 - 2 2 4 Đặ c t ả yêu c ầ u Tên Use-Case: Đăng nhập ID : 1 M ứ c độ quan tr ọ ng: Cao Tác nhân chính: Hiệu Trưởng, Phó Hiệu Trưởng, Văn thư, Lãnh đạo phòng, Chuyên viên phòng Ki ể u Use-Case : Chi tiết, cần thiết Nh ữ ng ng ườ i tham gia và quan tâm: Không có Mô t ả v ắ n t ắ t: Usecase này mô tả người dùng ( Hiệu Trưởng, Phó Hiệu Trưởng…) đă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): 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, đồng thời phân quyền tùy theo từng chuyên viên Các lu ồ ng s ự ki ệ n con: - Nếu người dùng quên mật khẩu thì có thể sử dụng chức năng quên mật khẩu - Người dùng có thể đăng ký tài khoản và cho người quản khi duyệt thì mới được sử dụng - Người dùng có thể liên hệ với quản trị Web site để được hỗ trợ 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 - 26 - Tên Use-Case: Quản lý Danh mục ID: 2 M ứ c độ quan tr ọ ng: Cao Tác nhân chính: Văn thư Ki ể u Use-Case: Chi tiết, cần thiết Nh ữ ng ng ườ i tham gia và quan tâm: Không có Mô t ả v ắ n t ắ t: Usecase này mô tả Văn thư thêm những thông tin ban đầu cho hệ thống Kh ở i s ự : Nhập những thông tin của các bản liên quan như đơn vị các bộ… Các m ố i quan h ệ : Kết hợp (Association): Không có Bao hàm (Include): Không có Mở rộng (Extend): Không có Khái quát hóa (Generalization): Không có Các lu ồ ng s ự ki ệ n thông th ườ ng: - Cập nhật thông tin bảng cán bộ - Cập nhật thông tin bảng đơn vị - Cập nhập thông tin bảng đơn vị ngoài Các lu ồ ng s ự ki ệ n con: Không có Các lu ồ ng s ự ki ệ n thay th ế /ngo ạ i l ệ : Không có - 27 - Tên Use-Case: Xử lý công văn đến ID: 3 M ứ c độ quan tr ọ ng: Cao Tác nhân chính: Hiệu Trưởng, Phó Hiệu Trưởng, Văn thư, Lãnh đạo phòng, Chuyên viên phòng Ki ể u Use-Case: Chi tiết, cần thiết Nh ữ ng ng ườ i tham gia và quan tâm: Không có Mô t ả v ắ n t ắ t: Usecase này mô tả quá trình xử lý một công văn đến Kh ở i s ự : Khi có một công văn đến Văn thư tiếp nhận, phân loại, và đưa công văn này lên hệ thống Các m ố i quan h ệ : Kết hợp (Association): Không có Bao hàm (Include): Không có Mở rộng (Extend): Không có Khái quát hóa (Generalization): Không có Các lu ồ ng s ự ki ệ n thông th ườ ng: - Sau khi Văn thư đưa công văn lên hệ thống - Hiệu Trưởng tiếp nhận công văn và xử lý - Nếu Hiệu Trưởng phân công phê duyệt cho Phó Hiệu Trưởng Phó Hiệu Trưởng sẽ phân công xử lý công văn Hoặc Hiệu Trưởng có thể trực tiếp phân công xử lý công văn - Lãnh đạo đơn vị tiếp nhận xử lý công văn đến có thể phân công xử lý công văn cho các bộ phòng hoặc trực tiếp xử lý công văn - Sau khi hoàn thành xử lý các bộ hoặc Lãnh đạo đơn vị báo cáo lại cho Hiệu Trưởng Các lu ồ ng s ự ki ệ n con: Tìm kiếm tra cứu công văn đến theo quyển đã được phân Các lu ồ ng s ự ki ệ n thay th ế /ngo ạ i l ệ : Nếu trong thời gian xử lý công văn, đơn vị hoặc chuyên viên không được để quá hạn xử lý mới báo cáo - 28 - Tên Use-Case: Xử lý công văn đi ID: 4 M ứ c độ quan tr ọ ng: Cao Tác nhân chính: Hiệu Trưởng, Phó Hiệu Trưởng, Văn thư, Lãnh đạo phòng, Chuyên viên phòng Ki ể u Use-Case: Chi tiết, cần thiết Nh ữ ng ng ườ i tham gia và quan tâm: Không có Mô t ả v ắ n t ắ t: Usecase này mô tả việc xử lý và phát hành công văn đi Kh ở i s ự : Các bộ phòng phát hành dự thảo công văn đi gởi cho Lãnh đạo phòng Các m ố i quan h ệ : Kết hợp (Association): Không có Bao hàm (Include): Không có Mở rộng (Extend): Không có Khái quát hóa (Generalization): Không có Các lu ồ ng s ự ki ệ n thông th ườ ng: - Sau khi các bộ phòng phát hành dự thảo công văn đi gởi cho Lãnh đạo phòng - Lãnh đạo phòng xem xét, yêu cầu sửa hoặc trình lên Văn thư - Văn thư xem xét, yêu cầu sửa hoặc trình lên Hiệu Trưởng - Hiệu Trưởng xem xét, yêu cầu sửa, phê duyệt hoặc chuyển phê duyệt ban hành công văn - Sau khi nhận được phê duyệt từ Lãnh Đạo Trường Văn thư lưu vào sổ công văn đi và ban hành công văn Các lu ồ ng s ự ki ệ n con: Không có Các lu ồ ng s ự ki ệ n thay th ế /ngo ạ i l ệ : Công văn có thể bị hủy trước khi ban hành - 29 - Tên Use-Case: Tìm kiếm tra cứu ID: 5 M ứ c độ quan tr ọ ng: Cao Tác nhân chính: Hiệu Trưởng, Phó Hiệu Trưởng, Văn thư, Lãnh đạo phòng, Chuyên viên phòng Ki ể u Use-Case: Chi tiết, cần thiết Nh ữ ng ng ườ i tham gia và quan tâm: Mô t ả v ắ n t ắ t: Usecase này mô tả tìm kiếm tra cứu công văn Kh ở i s ự : Tất cả người dùng đều có thể tìm kiếm tra cứu công văn theo quyền hạn của mình Các m ố i quan h ệ : Kết hợp (Association): Không có Bao hàm (Include): Không có Mở rộng (Extend): Không có Khái quát hóa (Generalization): Không có Các lu ồ ng s ự ki ệ n thông th ườ ng: - Sau khi đăng nhập vào hệ thống người dùng có thể tìm kiếm được thông tin các công văn theo quyền hạn của mình Các lu ồ ng s ự ki ệ n con: Không có Các lu ồ ng s ự ki ệ n thay th ế /ngo ạ i l ệ : Không có - 30 - Tên Use-Case: Thống kê ID: 6 M ứ c độ quan tr ọ ng: Cao Tác nhân chính: Văn thư trường Ki ể u Use-Case: Chi tiết, cần thiết Nh ữ ng ng ườ i tham gia và quan tâm: Không có Mô t ả v ắ n t ắ t: Usecase này mô tả việc thống kê công văn Kh ở i s ự : Thống kê – in sổ công văn đến và đi Các m ố i quan h ệ : Kết hợp (Association): Không có Bao hàm (Include): Không có Mở rộng (Extend): Không có Khái quát hóa (Generalization): Không có Các lu ồ ng s ự ki ệ n thông th ườ ng: - Sau khi đăng nhập vào hệ thống văn thư thực hiện chức năng in sổ công văn Các lu ồ ng s ự ki ệ n con: Không có Các lu ồ ng s ự ki ệ n thay th ế /ngo ạ i l ệ : Không có - 31 - 2 3 Mô hình hóa cấu trúc hệ thống 2 3 1 Xác đị nh các l ớ p th ự c th ể  Lớp Loại Văn Bản (LOAIVANBAN) gồm các thuộc tính sau: MaLoai: Mã loại TenLoai: Tên loại GhiChu: Ghi chú  Lớp Tình Trạng (TINHTRANG) gồm các thuộc tính sau: MaTT: Mã tình trạng TenTT: Tên tình trạng GhiChu: Ghi chú  Lớp Công Văn Đến (CONGVANDEN) gồm các thuộc tính sau: ID_CongVanDen: ID công văn đến SoVB: Số văn bản MaLoai: Loại văn bản SoKyHieu: Số ký hiệu MaDonViNgoai: Mã đơn vị ngoài NguoiKyVB: Người ký văn bản NgayThangVB: Ngày tháng văn bản MaCanBo: Mã cán bộ NgayDen: Ngày đến LinkNoiDung: Nội dung TrichYeu: Trích yếu nội dung SoTrang: Số trang SoBan: Số bản NgayTrinh: Ngày trình - 32 - NgayDuyet: Ngày duyệt Web: Web MaTT: Mã trạng thái GhiChu: Ghi chú  Lớp Công Văn Đi (CONGVANDI) gồm các thuộc tính sau: ID_CongVanDi: ID công văn đi SoVB: Sổ văn bản MaLoai: Loại văn bản SoKyHieu: Số ký hiệu MaDonViNgoai: Mã đơn vị ngoài NgayBanHanh: Ngày ban hành NgayThangVB: Ngày tháng văn bản LinkNoiDung: Nội dung TrichYeu: Trích yếu nội dung NguoiKy: Người ký SoTrang: Số trang SoBan: Số bản NgayTrinh: Ngày trình NgayDuyet: Ngày duyệt Web: Web MaTT: Mã trạng thái GhiChu: Ghi chú  Lớp Quyền Hạn (QUYENHAN) gồm các thuộc tính sau: MaQH: Mã quyền hạn TenQH: Tên quyền hạn - 33 - GhiChu: Ghi chú  Lớp Đơn Vị (DONVI) gồm các thuộc tính sau: MaDonVi: Mã đơn vị TenDonVi: Tên đơn vị GhiChu: Ghi chú  Lớp Chuyên viên (CANBO) gồm các thuộc tính sau: MaCanBo: Mã cán bộ TenCanBo: Tên cán bộ MaDonVi: Mã đơn vị Email: Email SDT: Số điện thoại MaQH: Mã quyền hạn TaiKhoan: Tài Khoản MatKhau: Mật Khẩu GhiChu: Ghi chú  Lớp Đơn Vị Ngoài (DONVINGOAI) gồm các thuộc tính sau: MaDonViNgoai: Mã đơn vị ngoài TenDonViNgoai: Tên đơn vị ngoài GhiChu: Ghi chú - 34 - 2 3 2 Xây d ự ng th ẻ CRC c ủ a các l ớ p th ự c th ể  Th ẻ CRC lo ạ i v ă n b ả n Front: Tên lớp: LOAIVANBAN ID: 1 Mô tả: Lưu giữ thông tin, phân loai công văn đến và công văn đi Các Ca sử dụng kết hợp: Xử lý công văn đến, xử lý công văn đi, tìm kiếm tra cứu Trách nhiệm Hiển thị thông tin từng loại công văn Cập nhật loại công văn mới Lưu loại công văn khi có công văn đến và công văn đi Lớp cộng tác CONGVANDEN, CONGVANDI Back: Thuộc tính: o MaLoai: Mã loại o TenLoai: Tên loại o GhiChu: Ghi chú Mối quan hệ: - Generalization: Không có - Aggregation: CONGVANDEN,CONGVANDI - Other associations: Không có - 35 -  Th ẻ CRC tình tr ạ ng Front: Tên lớp: TINHTRANG ID: 2 Mô tả: Lưu giữ các tình trạng xử lý của công văn Các Ca sử dụng kết hợp: Xử lý công văn đến, xử lý công văn đi, tìm kiếm tra cứu Trách nhiệm Hiển thị thông tin từng tình trạng của công văn Cập nhật tình trạng mới của công văn Lưu tình trạng công văn khi có công văn đến, công văn đi hoặc công văn đang xử lý Lớp cộng tác CONGVANDEN, CONGVANDI Back: Thuộc tính: o MaTT: Mã tình trạng o TenTT: Tên tình trạng o GhiChu: Ghi chú Mối quan hệ: - Generalization: - Aggregation: - Other associations: CONGVANDEN,CONGVANDI - 36 -  Th ẻ CRC quy ề n h ạ n Front: Tên lớp: QUYENHAN ID: 3 Mô tả: Lưu giữ các quyền hạn khác nhau trong hệ thống Các Ca sử dụng kết hợp: Tìm kiếm tra cứu Trách nhiệm Người sử dụng chỉ có thể thực hiện được chức năng khi được người quản trị phân quyền Tìm kiếm tra cứu công văn theo quyền hạn nhất định Lớp cộng tác CANBO Back: Thuộc tính: o MaQH: Mã quyền hạn o TenQH: Tên quyền hạn o GhiChu: Ghi chú Mối quan hệ: - Generalization: - Aggregation: CANBO - Other associations: - 37 -  Th ẻ CRC chuyên viên Front: Tên lớp: CANBO ID: 4 Mô tả: Lưu giữ thông tin của chuyên viên theo từng đơn vị Các Ca sử dụng kết hợp: Xử lý ông văn đ

XÂY DỰNG HỆ THỐNG QUẢN LÝ, ĐIỀU HÀNH CÔNG VIỆC TRỰC TUYẾN E-OFFICE TẠI TRƯỜNG ĐẠI HỌC QUẢNG NAM - Full 10 điểm

Thông tin tài liệu

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan