Vận dụng công nghệ hướng đối tượng sử dụng mẫu thiết kế để phát triển ứng dụng Tổ chức và quản lý hoạt động giao công việc

Cơ sở khoa học và ý nghĩa thực tiễn của việc nghiên cứu và ứng dụng các mô hình sử dụng lại vào quá trình thiết kế phần mềm: Một trong những giải pháp để nâng cao năng suất của quá trìn

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC HÌNH VẼ VÀ ĐỒ THỊ 4

DANH MỤC CÁC BẢNG 7

MỞ ĐẦU 8

1 Cơ sở khoa học và thực tiễn của đề tài: 8

2 Mục tiêu và phạm vi nghiên cứu của luận văn 10

3 Nội dung nghiên cứu và thực hiện của luận văn 10

4 Tóm tắt cấu trúc của luận văn 10

CHƯƠNG 1 TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI 12

1.1 Giới thiệu chung 12

1.2 Tổng quan về các mẫu thiết kế (Design Pattern) 12

1.2.1 Mẫu thiết kế là gì ? 12

1.2.1.1 Các định nghĩa về mẫu thiết kế [4,9] 12

1.2.1.2 Các thành phần của mẫu thiết kế [8,9] 13

1.2.2 Danh mục các mẫu thiết kế và phân loại [9] 14

1.2.3 Sơ đồ mối quan hệ giữa các mẫu thiết kế [9] 15

1.3 Giới thiệu một số mẫu thiết kế điển hình về hành vi và trình diễn [8,9,10] 16

1.3.1 Mẫu Observer (mẫu quan sát) 16

1.3.2 Mẫu Command (mẫu thực hiện lệnh) 18

1.3.3 Mẫu State (mẫu trạng thái) 20

1.3.4 Mẫu Template Method (phương thức tiêu bản) 22

1.3.5 Mẫu Chain of Responsibility (chuỗi các trách nhiệm) 23

1.3.6 Mẫu Interpreter (mẫu phiên dịch) 25

1.3.7 Mẫu Interator (mẫu lặp) 26

1.3.8 Mẫu Mediator (mẫu trung gian) 27

1.3.9 Mẫu Memento (mẫu lưu giữ) 29

1.3.10 Mẫu Strategy (mẫu chiến lược) 31

1.3.11 Mẫu Visitor (mẫu kiểm tra) 32

CHƯƠNG 2 VẬN DỤNG MẪU THIẾT KẾ HÀNH VI TIẾN HÀNH PHÂN TÍCH THIẾT KẾ VÀ XÂY DỰNG HỆ THỐNG “TỔ CHỨC VÀ QUẢN LÝ HOẠT ĐỘNG GIAO CÔNG VIỆC” 36

2.1 Nắm bắt yêu cầu bài toán 36

2.1.1 Bài toán đặt ra 36

2.1.2 Phạm vi bài toán 36

2.1.3 Mô tả nghiệp vụ quản lý 37

2.1.3.1 Xác định các thông tin chung về quản lý công việc 37

2.1.3.2 Công tác quản lý hoạt động giao công việc 38

2.1.3.3 Sơ đồ tiến trình quản lý hoạt động giao công việc 39

2.1.3.4 Các yêu cầu xây dựng hệ thống quản lý hoạt động giao công việc 39 2.1.3.5 Các chức năng hệ thống 40

2.1.4 Từ điển dữ liệu và mô hình lĩnh vực nghiệp vụ 41

2.1.4.1 Các khái niệm dự tuyển cho nghiệp vụ quản lý giao việc 41

2.1.4.2 Mô hình lĩnh vực nghiệp vụ 41

2.2 Đặc tả hệ thống 42

2.2.1 Các tác nhân (Actor) trong hệ thống 42

2.2.2 Các ca sử dụng (Usecase) của hệ thống 44

2.2.2.1 Ca sử dụng Đăng nhập hệ thống 44

2.2.2.2 Ca sử dụng Tạo công việc mới 44

2.2.2.3 Ca sử dụng Sửa thông tin hồ sơ công việc 45

2.2.2.4 Ca sử dụng Xoá hồ sơ công việc 45

2.2.2.5 Ca sử dụng Phân giải quyết công việc 45

2.2.2.6 Ca sử dụng Chỉ đạo giải quyết công việc 46

2.2.2.7 Ca sử dụng sửa Chỉ đạo giải quyết công việc 46

2.2.2.8 Ca sử dụng Giải quyết công việc 46

2.2.2.9 Ca sử dụng Báo cáo thống kê 47

2.2.2.10 Ca sử dụng Xem và tra cứu công việc 47

2.2.2.11 Ca sử dụng Cập nhật danh mục từ điển 47

2.2.2.12 Ca sử dụng Cập nhật người dùng 48

2.2.2.13 Ca sử dụng Cập nhật nhóm quyền 48

2.2.2.14 Ca sử dụng Phân quyền truy nhập 48

2.2.3 Mô hình ca sử dụng tổng thể 49

2.2.3.1 Gói ca sử dụng Đăng nhập hệ thống 49

2.2.3.2 Gói ca sử dụng Quản lý giải quyết công việc 50

2.2.3.3 Gói ca sử dụng Quản trị tiện ích 51

2.2.3.4 Gói ca sử dụng Báo cáo thống kê 51

2.2.3.5 Gói ca sử dụng Quản trị phân quyền người dùng 51

2.2.4 Mô tả chi tiết các ca sử dụng 52

2.2.4.1 Gói ca sử dụng Đăng nhập hệ thống 52

2.2.4.2 Gói ca sử dụng Quản lý giải quyết công việc 53

2.2.4.3 Gói ca sử dụng Quản trị tiện ích 60

2.2.4.4 Gói ca sử dụng Báo cáo thống kê 63

2.2.4.5 Gói ca sử dụng Quản trị phân quyền người dùng 67

2.3 Phân tích hệ thống 69

2.3.1 Phân tích các ca sử dụng 69

2.3.1.1 Gói ca sử dụng Đăng nhập hệ thống 69

2.3.1.2 Gói ca sử dụng Quản lý giải quyết công việc 71

2.3.1.3 Gói ca sử dụng Quản trị tiện ích 79

2.3.1.4 Gói ca sử dụng Báo cáo thống kê 82

2.3.1.5 Gói ca sử dụng Quản trị phân quyền người dùng 86

2.3.2 Phân tích các lớp 89

2.3.2.1 Lớp biên 89

2.3.2.2 Lớp điều khiển 91

2.3.2.3 Lớp thực thể 94

2.4 Thiết kế hệ thống 96

2.4.1 Kiến trúc vật lý của ứng dụng 96

2.4.2 Xác định các gói thiết kế 96

2.4.3 Thiết kế cho từng ca sử dụng 97

2.4.3.1 Gói ca sử dụng Đăng nhập hệ thống 97

2.4.3.2 Gói ca sử dụng Quản lý giải quyết công việc 100

2.4.3.3 Gói ca sử dụng Quản trị tiện ích 114

2.4.3.4 Gói ca sử dụng phục vụ tra cứu, báo cáo, thống kê 116

2.4.3.5 Gói ca sử dụng Quản trị phân quyền người dùng 122

2.4.4 Thiết kế một số lớp 123

2.4.4.1 Lớp giao diện 123

2.4.4.2 Lớp điều khiển 125

2.4.4.3 Lớp thực thể 127

CHƯƠNG 3 CÀI ĐẶT VÀ TRIỂN KHAI HỆ THỐNG 135

3.1 Các yêu cầu cài đặt triển khai hệ thống 135

3.2 Giới thiệu chương trình 136

3.2.1 Các mục tiêu mà hệ thống đạt được 136

3.2.2 Cấu trúc chương trình 137

3.2.3 Các đối tượng sử dụng chương trình 137

3.2.4 Giao diện một số chức năng chính 137

3.3 Khả năng triển khai áp dụng 142

KẾT LUẬN 143

1 Các kết quả đạt được 143

2 Những vấn đề tồn tại và hướng mở rộng và phát triển 143

TÀI LIỆU THAM KHẢO 145

Tài liệu tiếng Việt 145

Tài liệu tiếng Anh 145

Các trang Web 146

Bộ công cụ 146

DANH MỤC CÁC HÌNH VẼ VÀ ĐỒ THỊ Hình 1.1: Sơ đồ mối quan hệ giữa các mẫu thiết kế 16

Hình 1.2: Cấu trúc mẫu Observer 17

Hình 1.3: Biểu đồ cộng tác của mẫu Observer 18

Hình 1.4: Cấu trúc mẫu Command 19

Hình 1.5: Biểu đồ cộng tác của mẫu Command 20

Hình 1.6: Cấu trúc mẫu State 21

Hình 1.7: Cấu trúc mẫu Template Method 22

Hình 1.8: Cấu trúc mẫu Chain of Responsibility 24

Hình 1.9: Cấu trúc mẫu Interpreter 25

Hình 1.10: Cấu trúc mẫu Interator 26

Hình 1.11: Cấu trúc mẫu Mediator 28

Hình 1.12: Cấu trúc mẫu Memento 30

Hình 1.13: Biểu đồ cộng tác của mẫu Memento 30

Hình 1.14: Cấu trúc mẫu Strategy 31

Hình 1.15: Cấu trúc mẫu Visitor 33

Hình 1.16: Biểu đồ cộng tác của mẫu Visitor 34

Hình 2.1 Mô hình phân cấp quản lý trong doanh nghiệp 37

Hình 2.2: Sơ đồ tiến trình quản lý hoạt động giao công việc 39

Hình 2.3: Mô hình khái niệm hệ thống tổ chức và quản lý giao công việc 42

Hình 2.4: Gói ca sử dụng Đăng nhập hệ thống 49

Hình 2.5: Gói ca sử dụng Quản lý giải quyết công việc 50

Hình 2.6: Gói ca sử dụng Quản trị tiện ích 51

Hình 2.7: Gói ca sử dụng Báo cáo thống kê 51

Hình 2.8: Gói ca sử dụng Quản trị phân quyền người dùng 52

Hình 2.9: Các lớp phân tích thực thi ca sử dụng Đăng nhập 70

Hình 2.10: Biểu đồ cộng tác ca sử dụng Đăng nhập 70

Hình 2.11: Các lớp phân tích thực thi ca sử dụng Đổi mật khẩu 71

Hình 2.12: Biểu đồ cộng tác ca sử dụng Đổi mật khẩu 71

Hình 2.13: Các lớp phân tích thực thi ca sử dụng Tạo công việc mới 72

Hình 2.14: Biểu đồ cộng tác ca sử dụng Tạo công việc mới 72

Hình 2.15: Các lớp phân tích thực thi ca sử dụng Sửa nội dung công việc 73

Hình 2.16: Biểu đồ cộng tác ca sử dụng Sửa nội dung công việc 73

Hình 2.17: Các lớp phân tích thực thi ca sử dụng Xoá công việc 74

Hình 2.18: Biểu đồ cộng tác ca sử dụng Xoá công việc 74

Hình 2.19: Các lớp phân tích thực thi ca sử dụng Phân công việc 75

Hình 2.20: Biểu đồ cộng tác ca sử dụng Phân công việc 76

Hình 2.21: Các lớp phân tích thực thi ca sử dụng Chỉ đạo giải quyết công việc 77

Hình 2.22: Biểu đồ cộng tác ca sử dụng Chỉ đạo giải quyết công việc 77

Hình 2.23: Các lớp phân tích thực thi ca sử dụng Giải quyết công việc 78

Hình 2.24: Biểu đồ cộng tác ca sử dụng Giải quyết công việc 79

Hình 2.25: Các lớp phân tích thực thi ca sử dụng Cập nhật Phòng ban 79

Hình 2.26: Biểu đồ cộng tác ca sử dụng Cập nhật Phòng ban 80

Hình 2.27: Các lớp phân tích thực thi ca sử dụng Cập nhật Nhân viên 80

Hình 2.28: Biểu đồ cộng tác ca sử dụng Cập nhật Nhân viên 81

Hình 2.29: Các lớp phân tích thực thi ca sử dụng Cập nhật Loại công việc 81

Hình 2.30: Biểu đồ cộng tác ca sử dụng Cập nhật Loại công việc 82

Hình 2.31: Các lớp phân tích thực thi ca sử dụng Tra cứu công việc 83

Hình 2.32: Biểu đồ cộng tác ca sử dụng Tra cứu công việc 83

Hình 2.33: Các lớp phân tích thực thi ca sử dụng Báo cáo công việc 84

Hình 2.34: Biểu đồ cộng tác ca sử dụng Báo cáo công việc 85

Hình 2.35: Các lớp phân tích thực thi ca sử dụng Vẽ biểu đồ Gantt 86

Hình 2.36: Biểu đồ cộng tác ca sử dụng Vẽ biểu đồ Gantt 86

Hình 2.37: Các lớp phân tích thực thi ca sử dụng Cập nhật nhóm quyền 87

Hình 2.38: Biểu đồ cộng tác ca sử dụng Cập nhật nhóm quyền 87

Hình 2.39: Các lớp phân tích thực thi ca sử dụng Phân quyền người dùng 88

Hình 2.40: Biểu đồ cộng tác ca sử dụng Phân quyền người dùng 89

Hình 2.41: Kiến trúc vật lý của ứng dụng 96

Hình 2.42: Biểu đồ lớp thiết kế thực thi ca sử dụng Đăng nhập 97

Hình 2.43: Biểu đồ cộng tác ca sử dụng Đăng nhập 98

Hình 2.44: Biểu đồ lớp thiết kế ca sử dụng Đăng nhập áp dụng mẫu Singleton 99

Hình 2.45: Biểu đồ lớp thiết kế thực thi ca sử dụng Đổi mật khẩu 100

Hình 2.46: Biểu đồ cộng tác ca sử dụng Đổi mật khẩu 100

Hình 2.47: Biểu đồ lớp thiết kế thực thi ca sử dụng Tạo công việc mới 101

Hình 2.48: Biểu đồ cộng tác ca sử dụng Tạo công việc mới 101

Hình 2.49 Biểu đồ lớp thiết kế thực thi ca sử dụng Tạo công việc mới áp dụng mẫu thiết kế Observer 103

Hình 2.50: Biểu đồ cộng tác ca sử dụng Tạo công việc mới áp dụng mẫu thiết kế Observer 104

Hình 2.51: Biểu đồ lớp thiết kế thực thi ca sử dụng Sửa nội dung công việc 105

Hình 2.52: Biểu đồ cộng tác ca sử dụng Sửa nội dung công việc 106

Hình 2.53: Biểu đồ lớp thiết kế thực thi ca sử dụng Xoá công việc 106

Hình 2.54: Biểu đồ cộng tác ca sử dụng Xoá công việc 107

Hình 2.55: Biểu đồ lớp thiết kế thực thi ca sử dụng Phân công việc 107

Hình 2.56: Biểu đồ cộng tác ca sử dụng Phân công việc 108

Hình 2.57 Biểu đồ lớp thiết kế thực thi ca sử dụng Phân công việc áp dụng mẫu thiết kế State 110

Hình 2.58: Biểu đồ cộng tác ca sử dụng Phân công việcáp dụng mẫu thiết kế State 111 Hình 2.59: Biểu đồ lớp thiết kế thực thi ca sử dụng Chỉ đạo công việc 112

Hình 2.60: Biểu đồ cộng tác ca sử dụng Chỉ đạo công việc 112

Hình 2.61: Biểu đồ lớp thiết kế thực thi ca sử dụng Giải quyết công việc 113

Hình 2.62: Biểu đồ cộng tác ca sử dụng Giải quyết công việc 114

Hình 2.63: Biểu đồ lớp thiết kế thực thi ca sử dụng Cập nhật Phòng ban 114

Hình 2.64: Biểu đồ cộng tác ca sử dụng Cập nhật Phòng ban 115

Hình 2.65: Biểu đồ lớp thiết kế thực thi ca sử dụng Cập nhật Nhân viên 115

Hình 2.66: Biểu đồ cộng tác ca sử dụng Cập nhật Nhân viên 116

Hình 2.67: Biểu đồ lớp thiết kế thực thi ca sử dụng Tra cứu công việc 116

Hình 2.68: Biểu đồ cộng tác ca sử dụng Tra cứu công việc 117

Hình 2.69: Biểu đồ lớp thiết kế thực thi ca sử dụng Báo cáo công việc 118

Hình 2.70: Biểu đồ cộng tác ca sử dụng Báo cáo công việc 118

Hình 2.71: Áp dụng mẫu thiết kế Composite vào lớp CongViecthực hiện tổng hợp, báo cáo, hiển thị thông tin trong ca sử dụng Báo cáo công việc 120

Hình 2.72: Biểu đồ cộng tác ca sử dụng Báo cáo công việc áp dụng mẫu thiết kế Composite vào lớp CongViec 120

Hình 2.73: Biểu đồ lớp thiết kế thực thi ca sử dụng Vẽ biểu đồ Gantt 121

Hình 2.74: Biểu đồ cộng tác ca sử dụng Vẽ biểu đồ Gantt 121

Hình 2.75: Biểu đồ lớp thiết kế thực thi ca sử dụng Cập nhật nhóm quyền 122

Hình 2.76: Biểu đồ cộng tác ca sử dụng Cập nhật nhóm quyền 122

Hình 2.77: Biểu đồ lớp thực thi ca sử dụng Phân quyền chức năng 123

Hình 2.78: Biểu đồ cộng tác ca sử dụng Phân quyền chức năng 123

DANH MỤC CÁC BẢNG Bảng 2.1: Các chức năng hệ thống 41

Bảng 2.2: Các khái niệm dự tuyển cho nghiệp vụ quản lý giao việc 41

Bảng 2.3: Mô tả các tác nhân trong hệ thống 44

MỞ ĐẦU

1 Cơ sở khoa học và thực tiễn của đề tài:

a Cơ sở khoa học và ý nghĩa thực tiễn của việc nghiên cứu và ứng dụng các mô hình sử dụng lại vào quá trình thiết kế phần mềm:

Một trong những giải pháp để nâng cao năng suất của quá trình phát triển phần mềm là xây dựng những giải pháp để có thể sử dụng lại trong các bước tiếp theo hoặc trong các dự án phần mềm khác Sự ra đời của những giải pháp hướng đối tượng mà chủ yếu là phân tích thiết kế và lập trình hượng đối tượng đã đem lại những bước tiến đáng kể Trong đó, thiết kế hướng đối tượng đóng vai trò định hướng và quyết định đến việc sử dụng lại những tài nguyên trong quá trình phát triển phần mềm

Thiết kế hướng đối tượng cho phép chúng ta theo dõi và quản lý được sự phụ thuộc giữa các mô đun trong kiến trúc của hệ thống Tuy nhiên, thiết kế một phần mềm hướng đối tượng đã khó, việc thiết kế phần mềm hướng đối tượng với các thành phần có thể sử dụng lại thậm chí còn khó hơn nhiều Trước tiên, cần phải tìm ra các đối tượng thật chính xác, thể hiện chúng dưới các lớp đối tượng với mức độ trừu tượng phù hợp Đồng thời, ta cũng cần chỉ ra được sơ đồ thừa kế, mối liên hệ và giao tiếp của những đối tượng này Những yêu cầu trên cần thiết kế để đáp ứng được yêu cầu của bài toán hiện tại song cũng cần có tính tổng quát và linh hoạt đủ để có thể giải quyết một phần hoặc toàn bộ các bài toán có thể gặp trong tương lai

Một kinh nghiệm thường được áp dụng trong quá trình thiết kế là không tìm cách giải quyết mọi vấn đề bằng những thành phần căn bản Thay vào đó, ta cần tìm cách áp dụng những mô hình đã thành công trong thực tế đối với một số bài toán tương tự đã từng gặp Một khi mô hình giải quyết đã đủ hoàn thiện, nó có thể được sử dụng lại nhiều lần trong những lớp bài toán với yêu cầu nhất định Khi đó, người thiết kế khi gặp một bài toàn nào đó, qua xem xét để xác định được lớp bài toán, họ có thể tìm ra được mô hình thiết kế phù hợp và áp dụng ngay những mô hình đó vào thiết kế của mình mà không cần phải xem xét lại từ đầu

Việc nghiên cứu và ứng dụng các mô hình sử dụng lại vào quá trình thiết kế phần mềm là một bước tiếp cận mới trong khâu phân tích và thiết kế phần mềm hướng đối tượng Việc áp dụng các mô hình sử dụng lại vào quá trình thiết kế làm giảm thiểu thời gian và chi phí để thiết kế phần mềm, nâng cao khả năng ứng dụng và mở rộng phát triển trong tương lai của phần mềm ứng dụng Thiết kế phần mềm là một trong những khâu quan trọng nhất của quy trình xây dựng phần mềm, giai đoạn này quyết định rất lớn đến sự thành công hay thất bại của phần mềm Các mô hình sử dụng lại đã được nghiên cứu và áp dụng thành công vào thực tế, dó đó việc áp dụng các mô hình sử

dụng lại vào quá trình thiết kế làm giảm thiểu tính rủi ro trong quá trình xây dựng phần mềm sau này

b Cơ sở khoa học và ý nghĩa thực tiễn của việc nghiên cứu, thiết kế và xây dựng úng dụng “Tổ chức và quản lý hoạt động giao công việc”:

Ngày nay, với sự phát triển nhanh chóng của khoa học kỹ thuật nói chung và công nghệ thông tin nói riêng đã mang lại nhiều thành tựu to lớn Những thành tựu của khoa học được áp dụng trong tất cả các hoạt động của con người và đã đem lại những thành công hết sức lớn lao Ở Việt Nam, hiê ̣n nay, các công ty, xí nghiệp và các doanh nghiệp vừa và nhỏ hầu hết đã trang bị cơ sở hạ tầng về máy tính và kế t nối mạng đã tạo cơ sở cho việc áp dụng những công nghệ mới của mạng máy tính và internet vào lĩnh vực tìm kiếm, tổ chức và xử lý thông tin phục vụ công tác điều hành và quản lý sản xuất Với cơ sở hạ tầng công nghệ thông tin ngày càng phát triển mở rộng, các tổ chức, doanh nghiệp ngày càng có nhu cầu tin học hoá mọi lĩnh vực công việc, sản xuất, quản lý,… và mong muốn mọi thông tin quản lý điều hành sản xuất đều được lưu trữ trên máy tính để có thể tra cứu tìm kiếm dễ dàng và nhanh chóng mỗi khi có nhu cầu

Hoạt động giao việc và điều hành xử lý việc thực hiện công việc là một hoạt động chủ đạo trong hầu hết các tổ chức, doanh nghiệp Tuy nhiên, qua khảo sát thực tế cho thấy, hiện nay việc tổ chức và quản lý hoạt động giao công việc trong các tổ chức,

xí nghiệp chủ yếu thực hiện trực tiếp bằng miệng và quản lý dựa trên trên giấy tờ Do

đó, để tổ chức và theo dõi điều hành một công việc thực hiện qua nhiều người, nhiều cấp, trên nhiều giai đoạn thời gian khác nhau gặp rất nhiều khó khăn Việc tin học hoá hoạt động này để có thể tổ chức xử lý, theo dõi hoạt động giao công việc trên hệ thống máy tính là nhu cầu cấp thiết

Việc ứng dụng công nghệ thông tin vào tổ chức, quản lý hoạt động giao công việc là một trong các biện pháp có ý nghĩa thiết thực trong việc áp dụng các thành tựu khoa học kỹ thuật vào công tác điều hành và quản lý sản xuất trong các doanh nghiệp

Từ nhu cầu thực tiễn xã hội và đặc biệt là của đơn vị đang công tác, cùng với cơ

sở khoa học của việc nghiên cứu ứng dụng các mô hình sử dụng lại vào quá trình phân

tích thiết kế phần mềm, luận văn đã chọn đề tài với tên gọi “Vận dụng công nghệ hướng đối tượng sử dụng mẫu thiết kế để phát triển ứng dụng „Tổ chức và quản lý hoạt động giao công việc‟”

Mục tiêu của bài toán “Xây dựng ứng dụng tổ chức và quản lý hoạt động giao công việc” là xây dựng một hệ thống thông tin tổ chức và quản lý các hoạt động giao

công việc đang thực hiện trong một tổ chức, doanh nghiệp phân theo các cấp quản lý theo từng đầu người cụ thể dựa trên mạng máy tính Hệ thống giúp các cấp lãnh đạo

nắm sát tình hình thực hiện công việc và đưa ra ý kiến chỉ đạo và hướng giải quyết đúng đắn, kịp thời nhằm nâng cao hiệu quả quản lý Hệ thống cung cấp các đầu mục tra cứu và tổng hợp các công việc đã và đang thực hiện trên mạng máy tính để làm các thống kê, báo cáo định kỳ theo yêu cầu

Hệ thống được xây dựng sử dụng các công nghệ kỹ thuật mới như: ứng dụng hướng tiếp cận áp dụng các mẫu thiết kế, sử dụng công cụ mô hình hoá UML để phân tích và thiết kế bài toán theo mô hình hướng đối tượng; ứng dụng công nghệ web để

câ ̣p nhâ ̣t và xử lý thông tin

Với hướng tiếp cận phân tích và thiết kế hệ thống áp dụng công nghệ hướng đối tượng sử dụng các mẫu thiết kế, và sử dụng công nghệ web để xây dựng và phát triển

hệ thống, cho phép hệ thống dễ bảo trì và phát triển mở rộng trong tương lai đáp ứng được các yêu cầu thay đổi và phát triển ngày càng cao của xã hội Hệ thống được xây dựng hoàn toàn khả thi khi được áp dụng vào các tổ chức và doanh nghiệp có kết nối mạng máy tính

2 Mục tiêu và phạm vi nghiên cứu của luận văn

– Nghiên cứu các mô hình sử dụng lại và nắm bắt được mục tiêu, ý nghĩa và cách thức, tình huống áp dụng các mô hình sử dụng lại vào giải quyết các vấn

đề cụ thể Qua đó, tổng hợp lại một số mẫu điển hình về hành vi và trình diễn – Nắm bắt được phương pháp phân tích thiết kế hướng đối tượng một hệ thống

Sử dụng phương pháp phân tích thiết kế hướng đối tượng, áp dụng các mẫu thiết kế về hành vi và trình diễn để phân tích, thiết kế một ứng dụng cụ thể trên máy tính

– Từ kết quả phân tích và thiết kế tiến hành xây dựng hệ thống dựa trên các công cụ và môi trường đã lựa chọn

– Thực hiện triển khai và áp dụng hệ thống tại một đơn vị

3 Nội dung nghiên cứu và thực hiện của luận văn

– Tổng quan về phát triển phần mềm và sử dụng lại

– Một số mẫu điển hình về hành vi và trình diễn

– Vận dụng mẫu thiết kế hành vi tiến hành phân tích và thiết kế ứng dụng ứng dụng “Tổ chức và quản lý hoạt động giao công việc”

– Xây dựng chương trình và tiến hành cài đặt thử nghiệm

4 Tóm tắt cấu trúc của luận văn

Luận văn bao gồm các phần sau:

MỞ ĐẦU: Giới thiệu lý do chọn đề tài luận văn, nhu cầu thực tiễn và khả năng ứng

dụng của luận văn

CHƯƠNG 1: Tổng quan về mô hình sử dụng lại

Chương này giới thiệu tổng quan về phần mềm sử dụng lại, giới thiệu tổng quan

về các mẫu thiết kế, giới thiệu chi tiết một số mẫu thiết kế điển hình về hành vi và trình diễn

CHƯƠNG 2: Vận dụng mẫu thiết kế hành vi tiến hành phân tích, thiết kế và xây dựng

hệ thống tổ chức và quản lý hoạt động giao công việc

Chương này chỉ ra các ca sử dụng, các tác nhân của hệ thống, các mô hình ca sử dụng, mô tả và làm mịn dần bằng việc mô tả, phân tích từng ca sử dụng Phần thiết kế chỉ ra mô hình thiết kế một số ca sử dụng cơ bản

CHƯƠNG 3: Cài đặt và triển khai hệ thống

Chương này nêu các yêu cầu và môi trường cài đặt, triển khai hệ thống Giới thiệu một số chức năng chính và đưa ra một số màn hình nhập liệu, báo cáo của chương trình Khả năng triển khai áp dụng chương trình trong thực tiễn

KẾT LUẬN: Phần này nêu kết quả đạt được của luận văn và đề xuất phương hướng

nâng cấp và mở rộng ứng dụng đề tài vào thực tiễn trong tương lai

CHƯƠNG 1 TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI

1.1 Giới thiệu chung

Thiết kế phần mềm là một công đoạn quan trọng trong quy trình xây dựng và phát triển phần mềm Cũng như việc thiết kế phần mềm truyền thống, việc thiết kế phần mềm hướng đối tượng cần phải đáp ứng được yêu cầu của bài toán, song cũng cần có tính tổng quát và linh hoạt đủ để có thể giải quyết một phần hoặc toàn bộ các bài toán có thể gặp trong tương lai

Trong quá trình xây dựng và phát triển phần mềm, các thay đổi do yêu cầu từ phía khách hàng, các điều kiện phát sinh hay việc thiết kế một cách cứng nhắc trong quá trình thiết kế thường làm cho hệ thống trở nên rối rắm, các mô đun càng ngày càng bị phụ thuộc vào nhau Sự phụ thuộc này làm cho phần mềm ngày càng trở nên phình to và khó bảo trì, thậm chí dẫn đến thất bại

Phương pháp lập trình hướng đối tượng ra đời góp phần giúp cho việc thiết kế phần mềm trở nên dễ dàng và linh động hơn Thiết kế hướng đối tượng cho phép theo dõi và quản lý được sự phụ thuộc giữa các mô đun trong kiến trúc của hệ thống

Việc tìm cách áp dụng những mô hình đã thành công trong thực tế đối với một số bài toán tương tự đã từng gặp và áp dụng những mô hình đó vào thiết kế của mình mà không cần phải xem xét lại từ đầu, đảm bảo tiết kiệm chí phí, thời gian xây dựng và phát triển phần mềm, nâng cao độ tinh cậy và chất lượng phần mềm

Năm 1995, Erich Gamma, Richard Helm, Join Vlissides, và Ralph Johnson (Gang of Four) đã công bố cuốn sách của họ “Elements of reusable Object-Oriented

Software” đánh dấu sự ra đời của “mẫu thiết kế” Đây là một bước tiến vô cùng quan

trọng đối với việc thiết kế phần mềm hướng đối tượng

1.2 Tổng quan về các mẫu thiết kế (Design Pattern)

1.2.1 Mẫu thiết kế là gì ?

1.2.1.1 Các định nghĩa về mẫu thiết kế [4,9]

 Mẫu thiết kế là một cặp giải pháp/vấn đề được đặt tên có thể áp dụng trong những ngữ cảnh mới và những hướng dẫn để áp dụng nó trong những tình huống mới như thế nào [4]

 Mẫu thiết kế không đơn thuần là một bước nào đó trong các giai đoạn phát triển

phần mềm mà nó đóng vai trò là sáng kiến để giải quyết một bài toán thông dụng nào đó Các giai đoạn phần mềm vẫn hoàn chỉnh mà không có mẫu thiết

kế, nhưng sự góp mặt của mẫu thiết kế sẽ giúp cho việc xác định bài toán cần giải quyết nhanh gọn hơn, từ đó đưa ra cách giải quyết hợp lý [9]

 Mẫu thiết kế không chỉ được sử dụng để xác định bài toán và cách giải quyết mà còn được sử dụng nhằm cô lập các thay đổi trong mã nguồn, từ đó làm cho hệ thống có khả năng tái sử dụng cao do mẫu thiết kế tuân thủ rất nghiêm ngặt các nguyên lý thiết kế hướng đối tượng [9]

Việc xác định thế nào là một mẫu thiết kế phụ thuộc vào các nhìn nhận vấn đề của mỗi người Theo GOF, cách nhìn nhận phổ biến nhất về các mẫu thiết kế là coi chúng giống như các mô tả về các đối tượng phục vụ mục đích trao đổi thông tin trong quá trình thiết kế đã được hiệu chỉnh để giải quyết những yêu cầu thiết kế trong những trường hợp nhất định

1.2.1.2 Các thành phần của mẫu thiết kế [8,9]

Mỗi mẫu thiết kế trước tiên mô tả một bài toán mà ta gặp nhiều lần rồi mô tả những yếu tố căn bản nhất để giải quyết bài toán theo cách mà ta có thể áp dụng lại nhiều lần Dựa trên mô tả như trên về các mẫu thiết kế, ta thấy chúng bao gồm những thành phần cơ bản sau:

 Tên: Là tên gọi qua đó ta có thể mô tả bài toán cần giải quyết, giải pháp thực

hiện hay kết quả Việc đặt tên mẫu thiết kế cho phép mô tả các bài toán và giải pháp một cách ngắn gọn Tạo thành một ngôn ngữ trong cộng đồng những người thiết kế Ví dụ, khi nói đến mẫu thiết kế “Façade”, ta hình dung ngay đến mô hình thiết kế một đối tượng với vai trò giao dịch của một tập các thành phần nhỏ hơn

 Bài toán: Cho phép xác định trong trường hợp nào thì áp dụng mẫu thiết kế

thông qua mô tả bài toán và ngữ cảnh của bài toán đó

 Giải pháp giải quyết bài toán: Mô tả những thành phần tạo nên mẫu thiết kế

(các lớp, các đối tượng) cùng mối quan hệ, vai trò và cách thức phối hợp giữa chúng (cấu trúc, thừa kế) Giải pháp không đề cập đến cách thức thiết kế hay thực hiện cụ thể nào vì nó được áp dụng trong rất nhiều tình huống khác nhau Thay vào đó, giải pháp của mẫu thiết kế được mô tả với tính khái quát cao với cách thức tổ chức chung nhất của các thành phần trong việc giải quyết bài toán

Ví dụ như mẫu thiết kế được gọi như một thành ngữ (mẫu GRASP), mẫu thiết

kế có thể mô tả bằng lời hoặc mô hình thiết kế hay bằng mã nguồn

 Hệ quả: Là những gì thu nhận được cùng với những yếu tố cần cân nhắc khi áp

dụng mẫu thiết kế để giải quyết bài toán Hệ quả thường không được đề cập khi nói đến một mẫu thiết kế nhưng đây là yếu tố quyết định khi cần chọn lựa hoặc phân tích chi phí và lợi ích khi áp dụng các mẫu thiết kế

1.2.2 Danh mục các mẫu thiết kế và phân loại [9]

Erich Gamma và các đồng sự của ông đề xuất 23 mẫu thiết kế, và đã đưa ra hai tiêu chí để phân loại các mẫu thiết kế này Đó là phân loại theo mục đích sử dụng (purpose) và phạm vi áp dụng của mẫu (scope)

a Theo mục đích sử dụng: Các mẫu thiết kế được phân thành 3 nhóm: mẫu kiến tạo, mẫu cấu trúc, mẫu hành vi

 Mẫu kiến tạo (Creational Patterns): mẫu kiến tạo trừu tượng hoá quá trình khởi

tạo đối tượng Các mẫu này giúp hệ thống không phải phụ thuộc vào cách một đối tượng được tạo ra, xây dựng và thể hiện

Mẫu thiết kế kiến tạo bao gồm các mẫu sau: Abstract Factory, Builder, Factory Method, Prototype, Singleton

 Mẫu cấu trúc (Structural Patterns): mẫu thiết kế cấu trúc đề cập đến cách mà các

đối tượng và lớp đối tượng kết hợp để tạo nên một cấu trúc lớn hơn và hữu dụng hơn Việc thiết kế các lớp đối tượng là nhằm đáp ứng các ràng buộc cụ thể của

hệ thống Mẫu cấu trúc mô tả mối quan hệ giữa các lớp này và sắp xếp sao cho nếu có bất kì sự thay đổi nào với hệ thống đều không làm thay đổi những quan

hệ đó

Mẫu thiết kế cấu trúc bao gồm các mẫu sau: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

 Mẫu hành vi (Behavioral Patterns): mẫu hành vi mô tả sự tương tác giữa các đối

tượng và cách chúng phân phối, cộng tác, để giải quyết một hay một nhóm trách nhiệm nào đó

Mẫu hành vi bao gồm các mẫu sau: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

b Theo phạm vi sử dụng: các mẫu thiết kế được phân thành 2 nhóm:

Phạm vi được nói đến khi ta quyết định nên áp dụng mẫu thiết kế vào các lớp hay

các đối tượng

 Mẫu thiết kế áp dụng cho Lớp (Class): các mẫu này mô tả và giải quyết mối

quan hệ giữa các lớp đối tượng và lớp con của chúng Các mối quan hệ này được thiết lập qua cơ chế kế thừa và chỉ xảy ra ở thời điểm biên dịch chương trình

(compiler-time)

Các mẫu thuộc loại này bao gồm: Factory Method, Adapter (class), Interpreter, Template Method

 Mẫu thiết kế áp dụng cho Đối tượng (Object): các mẫu này mô tả và giải quyết

mối quan hệ giữa các đối tượng Các mối quan hệ này có thể thay đổi tại thời điểm chạy chương trình (run-time)

Các mẫu thuộc loại này bao gồm: Abstract Factory, Builder, Prototype, Singleton, Adapter (Object), Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor

1.2.3 Sơ đồ mối quan hệ giữa các mẫu thiết kế [9]

Hình 1.1: Sơ đồ mối quan hệ giữa các mẫu thiết kế

1.3 Giới thiệu một số mẫu thiết kế điển hình về hành vi và trình diễn

[8,9,10]

Với phạm vi thực hiện của luận văn, phần này chỉ tổng hợp và giới thiệu một số mẫu thiết kế về hành vi và trình diễn đƣợc ứng dụng nhiều trong phân tích và thiết kế phần mềm, từ đó làm cơ sở để thực hiện áp dụng vào phân tích và thiết kế hệ thống ở phần sau

1.3.1 Mẫu Observer (mẫu quan sát)

1.3.1.1 Ý nghĩa

Định nghĩa mối quan hệ phụ thuộc một - nhiều giữa các đối tƣợng sao cho khi một đối tƣợng thay đổi trạng thái thì tất cả các đối tƣợng liên quan cũng sẽ đƣợc thông báo và tự động cập nhật theo

Mẫu Observers mô tả cách thiết lập mối quan hệ này Có hai đối tƣợng then chốt trong mẫu này, đó là Subject và Observer Một đối tƣợng Subject có thể có một hoặc nhiều đối tƣợng Observer phụ thuộc vào nó Tất cả các đối tƣợng Observer sẽ đƣợc cảnh báo (notify) khi đối tƣợng Subject có sự thay đổi về trạng thái Khi đó, các đối tƣợng Observer sẽ lấy thông tin về trạng thái của đối tƣợng Subject để tự cập nhật lại trạng thái của chính nó

1.3.1.3 Cấu trúc mẫu Observer

Hình 1.2: Cấu trúc mẫu Observer

Ở cấu trúc trên, khi khởi tạo một đối tƣợng thuộc lớp ConcreteObserver thì sự khởi tạo này phải dựa trên đối tƣợng thuộc lớp ConcreteSubject để lấy thông tin trạng thái hiện tại của đối tƣợng Subject Đặc điểm của mẫu này là sự ánh xạ qua lại giữa đối tƣợng thuộc lớp Subject và các đối tƣợng thuộc lớp Observer Đối tƣợng ConcreteObserver sẽ giữ con trỏ của đối tƣợng ConcreteSubject Ngƣợc lại, lớp cha của lớp ConcreteSubject (lớp Subject) sẽ giữ một mảng các con trỏ đến lớp Observer (lớp cha của lớp ConcreteObserver)

Hình 1.3: Biểu đồ cộng tác của mẫu Observer

1.3.2 Mẫu Command (mẫu thực hiện lệnh)

1.3.2.1 Ý nghĩa

Mẫu này dùng để đóng gói các yêu cầu khác nhau thành từng đối tượng thực hiện lệnh riêng biệt, do đó cho phép tham số hoá các tác vụ từ client với đối tượng thực hiện lệnh khác nhau, đưa vào hàng đợi hoặc log file các yêu cầu, hỗ trợ việc phục hồi các tác vụ đã thực hiện

1.3.2.2 Mô tả

Mẫu này tạo ra các lớp lệnh Command giúp cho việc gọi thực hiện sau này được

dễ dàng Mỗi lớp Command được định nghĩa tương ứng với một hành động (action) của một đối tượng nhận (receiver) nào đó (còn gọi là một cặp action-receiver) Sau này, khi muốn thực hiện lệnh nào, ta chỉ cần gọi thực hiện tương ứng với Command tương ứng

1.3.2.3 Cấu trúc mẫu Command

Hình 1.4: Cấu trúc mẫu Command Các thành phần tham gia vào cấu trúc Command:

 Command: Định nghĩa giao tiếp cho việc xử lý một tác vụ

 ConcreteCommand: Định nghĩa kết nối giữa một đối tượng nhận và một

tác vụ thực hiện

 Client: Tạo một đối tượng ConcreteCommand và đặt các đối tượng nhận

cho nó

 Invoker: Duyệt các command để đưa ra các yêu cầu khi cần

 Receiver: nhận biết khi nào cần thực hiện tác vụ tương ứng với các yêu cầu

được gửi tới

1.3.2.4 Biểu đồ cộng tác của các đối tượng tham gia vào mẫu

Hình 1.5: Biểu đồ cộng tác của mẫu Command Client tạo các đối tượng ConcreteCommand và xác định các đối tượng nhận tương ứng Đối tượng Invoker lưu giữ các đối tượng ConcreteCommand để có thể duyệt và đưa ra các yêu cầu khi cần

1.3.2.5 Các tình huống áp dụng

Có thể ứng dụng mẫu Command để xây dựng một thực đơn bằng cách tạo một tập hợp các Command tương ứng với các yêu cầu thực hiện các mục chọn trên thực đơn, …

Sử dụng mẫu này, ta có thể xây dựng các chức năng Phục hồi (undo), Thực hiện lại (Redu),… bằng cách lưu lại các lệnh đã được thực hiện vào một danh sách (queue, history list, log,…) Sau đó, chỉ cần dựa theo danh sách này để Phục hồi hoặc Thực hiện lại lệnh tương ứng Để làm được điều này, trong lớp ConcreteCommand (kế thừa

từ lớp Command) phải xây dựng sẵn chức năng Phục hồi của chính nó Khi đó, một tập hợp các lệnh đã được thực hiện sẽ được Phục hồi bằng chức năng Thực hiện lại của từng lệnh (command) chứa trong nó

Mẫu này dùng để mô tả làm thế nào đối tượng có thể tự đưa ra các ứng xử khác

nhau tương ứng với mỗi trạng thái vào thời điểm chạy

Mẫu này đưa ra một lớp trừu tượng (Abstract) đại diện cho các trạng thái của đối

tượng trong ngữ cảnh hiện tại (Context), ở đây ta gọi là lớp State Lớp này cung cấp

giao diện chung cho tất cả các lớp đại diện các trạng thái khác nhau của ngữ cảnh

Context Các lớp con, kế thừa từ lớp State này (ConcreteStateA, ConcreteStateB, …),

sẽ cung cấp chi tiết các ứng xử tương ứng với trạng thái của nó Đối tượng State có thể

truy xuất đối tượng Context khi cần thiết để nắm giữ các yêu cầu của đối tượng

Context

Lớp Context sẽ giữ một biến đối tượng trạng thái (một lớp con của lớp State sẽ

lưu giữ trạng thái hiện hành) Lớp Context sẽ uỷ nhiệm tất cả các lời gọi trạng thái đến

cho biến đối tượng này

1.3.3.3 Cấu trúc mẫu State

Hình 1.6: Cấu trúc mẫu State Các thành phần tham gia vào cấu trúc State:

 Context: Chứa các yêu cầu, các phương thức từ phía Client Lưu giữ một

thể hiện (instance) của trạng thái hiện hành (thuộc lớp ConcreteState)

 State: Chứa các ứng xử có liên quan đến các trạng thái của đối tượng

Context

 ConcreteState: các lớp con cài đặt các ứng xử tương ứng với các trạng thái

của đối tượng Context trên

1.3.3.4 Các tình huống áp dụng

Ứng xử của một đối tượng phụ thuộc vào trạng thái của đối tượng đó, ứng xử của

nó có thể thay đổi vào thời điểm chạy và phụ thuộc vào trạng thái lúc đó

Sự điều khiển có thể quá lớn và các nhánh trong cùng một cấu trúc điều kiện

If-else phụ thuộc vào các trạng thái khác nhau của đối tượng Mẫu này sẽ tách mỗi

nhánh của cấu trúc điều kiện trên thành một lớp riêng biệt, do đó có thể xử lý các trạng

thái của đối tượng một cách độc lập, không phụ thuộc nhiều vào các đối tượng khác

1.3.4.2 Cấu trúc mẫu

Hình 1.7: Cấu trúc mẫu Template Method Các thành phần tham gia vào cấu trúc mẫu Template Method:

 Lớp AbstractClass là lớp trừu tượng định nghĩa khung của thuật toán trong

phương thức mẫu (Template Method)

 Lớp ConcreteClass cài đặt cách thực hiện các hành vi cụ thể

(PrimitiveOperation) Trong phương thức mẫu, các hành vi cụ thể sẽ được thực hiện theo một thứ tự nhất định Mỗi lớp con có một cách cài đặt cách thực hiện các hành vi cụ thể này khác nhau

1.3.4.3 Các tình huống áp dụng

Sử dụng mẫu Template Method khi cần định nghĩa thứ tự của một thuật toán và chuyển cho các lớp con thực thi những hành vi cụ thể của thuật toán Lớp cha sẽ cài đặt các hành vi chung, các lớp con sẽ kế thừa và sử dụng lại các phương thức này và

chỉ cần cài đặt lại các hành vi riêng của nó

1.3.4.4 Thuận lợi và hạn chế

Sử dụng mẫu này, các phương thức chung được cài đặt ở lớp cha, các lớp con chỉ cần kế thừa và sử dụng mà không cần cài đặt lại Điều này giúp tránh được sự trùng lắp mã chương trình

Mẫu này thường được sử dụng trong các lớp thư viện dùng để gọi các hàm hook Đây là những hàm có sẵn trong các thư viện cho phép người dùng kế thừa và cài đặt lại

1.3.5 Mẫu Chain of Responsibility (chuỗi các trách nhiệm)

1.3.5.1 Ý nghĩa

Mẫu này cho phép đối tượng gửi yêu cầu (Sender), có thể không cần biết đến đối tượng sẽ nhận yêu cầu đó (Receiver), bằng cách thêm vào các đối tượng một phương thức để có thể nắm giữ yêu cầu Các đối tượng sẽ được tổ chức thành một chuỗi mắt xích, yêu cầu được gửi sẽ được duyệt theo chuỗi mắt xích này cho đến khi có một đối tượng trong mắt xích nhận lấy yêu cầu của nó

1.3.5.2 Mô tả

Mẫu này tổ chức hệ thống các đối tượng thành một chuỗi mắt xích từ cụ thể đến tổng quát Mỗi đối tượng trong mắt xích này sẽ được cung cấp một phương thức để có thể nắm giữ và xử lý yêu cầu Yêu cầu sẽ được trượt qua chuỗi mắt xích này theo thứ

tự, từng đối tượng trong mắt xích sẽ được nhận yêu cầu Nếu đúng là yêu cầu dành cho

nó thì nó sẽ xử lý, nếu không yêu cầu sẽ tiếp tục gửi đi cho các mắt xích đằng sau nó

1.3.5.3 Cấu trúc mẫu

Có thể mô tả cấu trúc của mẫu theo cách sau:

Hình 1.8: Cấu trúc mẫu Chain of Responsibility Các thành phần tham gia vào cấu trúc mẫu Chain of Responsibility:

 Handler: Định nghĩa một giao tiếp chung cho việc nắm giữ yêu cầu Cài

đặt một con trỏ kết nối Successor tới các Handler khác

 ConcreteHandler: Nắm giữ yêu cầu mà nó chịu trách nhiệm Các

ConcreteHandler có thể truy xuất đối tượng được liên kết bởi con trỏ kết nối Successor của nó Nếu nó có thể nắm giữ yêu cầu được gửi đến, nó sẽ thực hiện Nếu không thì nó sẽ tiếp tục gửi yêu cầu cho Successor của nó để chuyên yêu cầu cho đối tượng kế tiếp

 Client: Kích hoạt yêu cầu cho một đối tượng ConcreteHandle trong chuỗi

mắt xích Khi Client kích hoạt một yêu cầu, yêu cầu này sẽ được gửi đi theo chuỗi mắt xích cho đến khi có một đối tượng ConcreteHandler nào đó nhận yêu cầu này để xử lý

1.3.5.4 Các tình huống áp dụng

Có nhiều hơn một đối tượng có thể nắm giữ yêu cầu

Khi muốn gửi một yêu cầu tới nhiều đối tượng khác nhau mà không cần phải xác định rõ ràng đó là đối tượng nào

Khi tập các đối tượng giữ yêu cầu cần được xác định một cách linh động

1.3.5.5 Thuận lợi và hạn chế

Giúp giảm sự phụ thuộc giữa các đối tượng: mẫu này giải phóng một đối tượng khi biết đối tượng khác đang nắm giữ yêu cầu Cả đối tượng gửi và nhận đều không biết nhau và một đối tượng trong chuỗi mắt xích không cần phải biết cầu trúc của chuỗi mắt xích

Việc giao nhiệm vụ cho các đối tượng được thực hiện một cách linh hoạt Mẫu này cho phép phân phối công việc giữa các đối tượng một cách linh hoạt, có thể thêm hoặc thay đổi việc nắm giữ các yêu cầu bằng cách thêm hay làm thay đổi chuỗi mắt xích ở thời điểm chạy chương trình

Nhược điểm của mẫu này là việc xác nhận được yêu cầu này có được xử lý hay không, yêu cầu có thể đi đến cuối chuỗi mắt xích mà không được xử lý Một yêu cầu cũng có thể không được xử lý nếu chuỗi mắt xích không được cấu hình một cách phù

1.3.6.2 Cấu trúc mẫu

Hình 1.9: Cấu trúc mẫu Interpreter Các thành phần tham gia vào cấu trúc mẫu Interpreter:

 AbstractExpresion: lớp trừu tượng, khai báo các tác vụ có thể thực hiện

được trên tất cả các nút trong cây cú pháp

 TerminalExpression: Cài đặt tác vụ thông dịch cho những ký pháp nguyên

tố của ngôn ngữ đặc tả

 NonterminalExpression: Có thể chứa các TerminalExpression bên trong

và cũng có thể chứa một NonterminalExpression khác Nó đóng vai trò như

là ngữ pháp của ngôn ngữ đặc tả

 Context: Là đối tượng chứa thông tin để thực hiện thông dịch Đối tượng

này là toàn cục đối với toàn quá trình thông dịch

1.3.6.4 Các tình huống áp dụng

Sử dụng mẫu Interpreter khi gặp vấn đề cần giải quyết lặp lại tương đối nhiều và

ta có thể biểu diễn vấn đề bằng một ngôn ngữ đặc tả tương đối đơn giản (ngôn ngữ đặc

tả này do ta tự thiết kế và xây dựng hoặc là những quy tắc đã có sẵn)

1.3.6.5 Thuận lợi và hạn chế

Một số ứng dụng đặc thù sẽ trở nên đơn giản khi cài đặt nếu ta xây dựng một bộ

cấu trúc ngữ pháp để đặc tả các tác vụ mà nó sẽ thực hiện thành các lệnh Sau đó tạo các thành phần thông dịch để có thể phân tích và thực thi các lệnh này

Hạn chế của mẫu này là ngôn ngữ đặc tả được xây dựng đòi hỏi phải có cấu trúc ngữ pháp đơn giản

1.3.7 Mẫu Interator (mẫu lặp)

1.3.7.1 Ý nghĩa

Mẫu Iterator cung cấp mẫu thiết kế các đối tượng hỗ trợ duyệt cho một đối tượng đóng vai trò thùng chứa (danh sách, ngăn xếp, hàng đợi, …) Một đối tượng hỗ trợ duyệt (Iterator Object) là đối tượng cho phép tuần tự duyệt qua tất cả các phần tử, các thành phần được chứa trong một đối tượng khác, đặc biệt là những đối tượng đóng vai trò thùng chứa

Mục đích chính của đối tượng hỗ trợ duyệt là cho phép người dùng xử lý từng thành phần được chứa bên trong đối tượng thùng chứa nhưng che dấu hoàn toàn cấu trúc nội tại của đối tượng của thùng chứa

Thông qua mẫu Iterator, các hình thức duyệt, giao diện lập trình cung cấp cho lập trình viên để duyệt qua các đối tượng của thùng chứa là không đổi, dẫu cho đối tượng của thùng chứa có kiểu khác nhau

1.3.7.2 Cấu trúc mẫu

Hình 1.10: Cấu trúc mẫu Interator Các thành phần tham gia vào cấu trúc mẫu Iterator:

 Iterator: Lớp thuần ảo dùng định nghĩa một giao tiếp để truy xuất và duyệt qua các thành phần

 ConcreteIterator: Cài đặt một giao tiếp Iterator và lưu lại vị trí hiện tại của

Việc duyệt không chịu ảnh hưởng nếu có sự thay đổi cấu trúc dữ liệu thùng chứa,

do giao diện lập trình dùng để duyệt là cố định nên mã chương trình sẽ không bị ảnh hưởng

Iterator là mẫu rất thông dụng, hầu hết các thư viện thùng chứa đều cài đặt Khi xây dựng cấu trúc dữ liệu, ta thường gói thùng chứa làm dữ liệu nội tại và cung cấp các phương thức để tương tác Với mẫu Iterator, ta có thể xây dựng đối tượng duyệt với các luật phù hợp với bài toán đang giải quyết

Ta có thể tạo nhiều hơn một đối tượng duyệt Iterator cùng tương tác trên một Aggregate

1.3.8 Mẫu Mediator (mẫu trung gian)

1.3.8.1 Ý nghĩa

Mẫu Medicator được sử dụng để đơn giản hoá các tương tác, các giao tiếp giữa các đối tượng trong hệ thống Thay vì để các đối tượng tưong tác với nhau một cách tuỳ ý thì Medicator tạo ra một lớp đối tượng trung gian nhằm quản lý các tương tác này

1.3.8.2 Cấu trúc mẫu

Có thể mô tả cấu trúc mẫu một cách khác như sau:

Hình 1.11: Cấu trúc mẫu Mediator Các thành phần tham gia vào cấu trúc mẫu Medicator:

 Mediator: Định nghĩa các hàm mà Client có thể gọi

 ConcreteMediator: Thực thi các hàm định nghĩa trong Mediator Lớp

ConcreteMediator chứa danh sách các Client nếu có bất kỳ sự thay đổi hoặc

có một yêu cầu từ một Client nào đó đến các Client còn lại

 Colleague: Định nghĩa các hàm mà Mediator có thể gọi để thông báo cho

các đối tượng của Mediator mỗi khi có sự thay đổi

 ConcreteClient: Thực thi hoặc mở rộng các hàm định nghĩa trong Client

Do các Client liên hệ với nhau thông qua Mediator, nên các Client đều lưu giữ đối tượng Mediator để thông báo cho các client còn lại mỗi khi nó có sự thay đổi hay cần thực hiện một yêu cầu nào đó

1.3.8.3 Các tình huống áp dụng

Trong các mô hình nghiệp vụ nảy sinh các luật ràng buộc phức tạp kéo theo mối quan hệ và sự tương tác giữa các đối tượng trong hệ thống cũng phức tạp, ta dùng Mediator để kiểm soát những ràng buộc này

Ta sử dụng mẫu Mediator khi muốn hệ thống bao gồm các đối tượng đơn giản, tường minh và có thể kiểm soát

Sử dụng mẫu Mediator khi muốn thay đổi hành vi của hệ thống và bố trí lại các lớp đối tượng mà không cần phải thay đổi mô hình nghiệp vụ

1.3.8.4 Thuận lợi và hạn chế

Sử dụng mẫu Mediator làm cho từng thành phần riêng lẻ trong hệ thống sẽ trở nên đơn giản hơn do chúng không phải liên lạc trực tiếp với nhau Các thông tin cụ thể

và cách thức giao tiếp giữa các thành phần sẽ được xử lý trong Mediator

Cách thức giao tiếp giữa các thành phần hay nhóm các thành phần sẽ được quản

lý và bảo trì dễ dàng hơn vì nhiệm vụ đó đã được Mediator xử lý

Việc tập trung các hành vi của hệ thống trong Mediator làm cho hệ thống dễ bảo trì hơn Chúng ta có thể tái sử dụng lại tất cả các thành phần và lúc cần thay đổi thì chỉ cần viết lại lớp Mediator mà thôi

Việc tập trung quá nhiều tác vụ xử lý trong Mediator gây ra khó khăn khi ta kiểm tra hay dò lỗi chương trình Việc theo vết các lỗi trong Mediator đồng nghĩa với việc phải xem xét tất cả các thành phần có liên quan

Khi số lượng các thành phần tham gia vào Mediator gia tăng thì Mediator sẽ bị phình to và trở thành đối tượng có cấu trúc phức tạp nhất trong hệ thống Do đó việc bảo trì và quản lý Mediator phức tạp và khó khăn hơn

1.3.9 Mẫu Memento (mẫu lưu giữ)

1.3.9.1 Ý nghĩa

Mẫu này được sử dụng nhằm mục đích không làm phá vỡ tính bao gói (encapsulation) nhưng vẫn lưu giữ và thể hiện được trạng thái bên trong đối tượng để sau này đối tượng có thể phục hồi lại trạng thái trước đó

1.3.9.2 Mô tả

Khi ta cần lưu giữ trạng thái bên trong của một đối tượng, chúng ta phải lưu giữ trạng thái của đối tượng ở một nơi nào đó để sau này có thể phục hồi lại trạng thái trước đó của đối tượng Theo nguyên tắc lập trình hướng đối tượng, một đối tượng không bao giờ được phép cho các đối tượng khác truy xuất đến trạng thái bên trong của nó (thành phần private) Nếu cho phép truy xuất đến các trạng thái bên trong, nó sẽ phá vỡ tính bao gói của đối tượng, làm cho ứng dụng khó tin cậy và khó mở rộng sau này

Mẫu Momento được thiết kế để giải quyết vấn đề này Một Memento là một đối tượng được tạo ra để lưu giữ các thành phần Private của đối tượng khác (gọi là đối

tượng nguồn (Originator) của Memento) Thao tác Phục hồi (Undo) sẽ yêu cầu một đối tượng nguồn của Memento khi nó cần kiểm tra trạng thái của đối tượng Đối tượng nguồn Originator sẽ kích hoạt Memento với thông tin mô tả trạng thái hiện tại của nó Chỉ đối tượng nguồn Originator mới có thể lưu giữ và lấy thông tin từ Memento, còn các đối tượng khác không có quyền này

1.3.9.3 Cấu trúc mẫu

Hình 1.12: Cấu trúc mẫu MementoCác thành phần tham gia vào cấu trúc mẫu Memento:

 Memento: Lưu giữ trạng thái riêng của đối tượng nguồn Originator, bảo vệ

chống truy xuất bởi các đối tượng khác ngoài đối tượng Originator của nó

 Originator: Tạo một Memento chứa đựng thông tin về trạng thái riêng hiện

tại của nó Sử dụng Memento để phục hồi lại trạng thái riêng của nó

 CareTaker: Phản hồi về sự giữ an toàn của Memento Đảm bảo việc không

bao giờ thao tác hay truy xuất đến nội dung của Memento

1.3.9.4 Biểu đồ cộng tác

Hình 1.13: Biểu đồ cộng tác của mẫu MementoĐối tượng CareTaker sẽ gọi một Memento của một Originator, giữ nó một thời gian sau đó trả nó lại cho Originator

1.3.9.5 Các tình huống áp dụng

Ta thường sử dụng mẫu Memento khi một thông tin của trạng thái đối tượng phải được lưu lại để nó có thể được phục hồi lại trạng thái đó sau này

Khi cần các giao tiếp trực tiếp với các trạng thái chi tiết bên trong của đối tượng

mà không phá phá vỡ tính bao gói của đối tượng

Việc sử dụng mẫu Memento có thể tạo ra sự hao tổn tài nguyên

Memento có thể bị quá tải nếu đối tượng nguồn Originator phải sao chép khối lượng lớn những thông tin lưu trữ hay nếu người dùng tạo và trả lại Memento cho Originator khi đối tượng này đã đầy

1.3.10 Mẫu Strategy (mẫu chiến lược)

1.3.10.1 Ý nghĩa

Một bài toán, chương trình có nhiều thuật toán khác nhau để giải quyết một vấn

đề nào đó Mẫu này cho phép thực hiện việc đóng gói đối với từng thuật toán trong họ,

và cho phép Client lựa chọn thuật toán cụ thể trong số đó khi sử dụng

1.3.10.2 Cấu trúc mẫu

Hình 1.14: Cấu trúc mẫu Strategy Các thành phần tham gia vào cấu trúc mẫu Strategy:

 Strategy: Định nghĩa giao diện cho tất cả các lớp thể hiện giải thuật Có thể

nhận con trỏ tham chiếu đến đối tượng ngữ cảnh Context trong quá trình khởi tạo đối tượng để có thể có thêm các dữ liệu chứa trong đối tượng ngữ

cảnh Context

 ConcreteStrategy: Triển khai giao diện Strategy để thể hiện một giải thuật

cụ thể

 Context: Tại thời điểm biên dịch, chỉ sử dụng đối tượng kiểu Strategy khi

xác định giải thuật cho vấn đề cần xử lý Tại thời điểm chạy chương trình,

nó cung cấp một đối tượng giải thuật cụ thể thay thế cho đối tượng Strategy

Có thể cung cấp con trỏ cho phép Strategy truy xuất dữ liệu của đối tượng Context

1.3.10.3 Các tình huống áp dụng

Mẫu Strategy thường được áp dụng trong trường hợp một lớp có nhiều hành vi loại trừ lẫn nhau và quá trình chuyển từ hành vi này sang hành vi khác cần được thực hiện dễ dàng Khi đó mỗi hành vi sẽ được thể hiện trong một lớp ConcreteStrategy

1.3.10.4 Thuận lợi và hạn chế

Kiến trúc phân cấp của những lớp Strategy định nghĩa một họ các thuật toán hoặc các hành vi đối với những ngữ cảnh thích hợp phục vụ cho việc tái sử dụng Việc thực hiện những chức năng chung của thuật toán được thực hiện thông qua kế thừa giao tiếp chung Strategy

Việc tách sự thực hiện các giải thuật khỏi lớp Context thành các Strategy, và sự

kế thừa từ các Strategy tạo nên sự đa dạng về thuật toán và hành vi Việc thực thi thuật toán và thực thi lớp Context được tách biệt, làm cho lớp Context dễ hiểu, dễ bảo trì và

sử dụng

Mẫu này cung cấp những cách thực thi khác nhau cho cùng một hành vi

Một sự hạn chế của mẫu này là người dùng phải biết về những Strategy khác nhau và phải hiểu bằng cách nào để phân biệt các Strategy trước khi chọn một Strategy chính xác để thực hiện

1.3.11 Mẫu Visitor (mẫu kiểm tra)

(Accept) nhận một đối tượng đóng vai trò “thuật toán” (lớp Visitor) làm tham số hàm Đối tượng “thuật toán” Visitor cài đặt những hàm xử lý, thuật toán… cho nhiều loại đối tượng “dữ liệu” Trong phương thức Accept của đối tượng “dữ liệu” ta phải gọi đúng hàm xử lý và thuật toán tương ứng cho nó

Kỹ thuật cài đặt này khắc phục được các hạn chế của kỹ thuật nạp chồng hàm (Function Overloading) và nó có một tên gọi khác là kỹ thuật double dispatch

Hình 1.15: Cấu trúc mẫu Visitor Các thành phần tham gia vào cấu trúc mẫu Visitor:

 Visitor: Khai báo một chức năng cho mỗi lớp của ConcreteElement trong

cấu trúc của đối tượng

 ConcreteVisitor: đặt chi tiết mỗi chức năng đã được Visitor khai báo ở

trên

 Element: Định nghĩa phương thức Accept lấy Visitor là tham số

 ConcreteElement: Cài đặt cụ thể phương thức Accept với Visitor là tham

số

 ObjectStructure: Là chương trình, nó có thể duyệt qua các thành phần

chính của nó và cung cấp các giao tiếp cấp cao cho phép các Visitor có thể duyệt các thành tố của chính nó

1.3.11.3 Biểu đồ cộng tác

Hình 1.16: Biểu đồ cộng tác của mẫu Visitor Một Client khi sử dụng mẫu Visitor phải tạo một đối tượng ConcreteVisitor và sau đó duyệt qua cấu trúc các đối tượng, xem xét các thành phần Element Với mỗi thành phần Element được duyệt, nó gọi các phương thức Visitor tương ứng với lớp của

nó

1.3.11.4 Các tình huống áp dụng

Ta thường sử dụng mẫu Visitor khi một cấu trúc đối tượng chứa nhiều lớp đối tượng với nhiều giao tiếp khác nhau và ta muốn thực hiện các chức năng trên các đối tượng mà phụ thuộc vào các lớp con (lớp Concrete) của chúng

Nhiều chức năng, thao tác cần được thực hiện trên những đối tượng trong một cấu trúc đối tượng và ta muốn tránh làm phức tạp các lớp của chúng vì những chức năng thêm vào này Visitor định nghĩa các chức năng, thao tác này riêng vào một lớp khác

Thông thường, lớp định nghĩa đối tượng cấu trúc hiếm khi bị thay đổi, nhưng ta thường muốn định nghĩa các chức năng, thao tác mới trên cấu trúc này Việc thay đổi cấu trúc đối tượng này đòi hỏi phải định nghĩa lại tất cả các visitor Do đó, nếu cấu trúc đối tượng thường xuyên thay đổi, ta nên định nghĩa các chức năng ngay trong các lớp đó

1.3.11.5 Thuận lợi và hạn chế

Kỹ thuật Double Dispatch kết hợp với tính đa hình (polymophism) được sử dụng

đã thay thế hoàn toàn mệnh đề “If” làm cho mã chương trình dễ dàng mở rộng, hạn chế sự lệ thuộc và thay đổi mã chương trình khi mở rộng

Tạo khả năng mềm dẻo trong việc thêm mới một hàm, thuật toán xử lý, trên các đối tượng dữ liệu Khi cần thêm hàm, thuật toán xử lý ta chỉ cần thêm vào lớp Visitor

và cài đặt lại lớp ConcreteVisitor

Mẫu này giúp ta tách các phương thức, hàm hay thay đổi (được cài trong

ConcreteVisitor) và những hành vi, phương thức, hàm không thay đổi (được cài trong đối tượng dữ liệu ConcreteElement)

Hạn chế của mẫu này là việc tạo thêm một đối tượng dữ liệu mới (ConcreteElement) sẽ rất khó khăn, bởi vì lúc đó sẽ làm thêm số phương thức ảo ở lớp Visitor và lúc đó các phương thức của lớp ConcreteVisitor cũng tăng lên Vì vậy, ta nên áp dụng mẫu này với những đối tượng dữ liệu không thay đổi, mở rộng và chỉ có các hành vi, thuật toán, phương thức tác động lên đối tượng dữ liệu là được cải tiến và thay đổi

CHƯƠNG 2 VẬN DỤNG MẪU THIẾT KẾ HÀNH VI TIẾN HÀNH PHÂN TÍCH

THIẾT KẾ VÀ XÂY DỰNG HỆ THỐNG

“TỔ CHỨC VÀ QUẢN LÝ HOẠT ĐỘNG GIAO CÔNG VIỆC”

Trong chương này, chúng ta phân tích các yêu cầu, nghiệp vụ bài toán, chỉ ra các

ca sử dụng, các tác nhân của hệ thống, các mô hình ca sử dụng, mô tả và làm mịn dần

bằng việc mô tả, phân tích từng ca sử dụng Phần thiết kế chỉ ra mô hình thiết kế một

số ca sử dụng cơ bản Dựa trên kết quả phân tích và thiết kế, tiến hành xây dựng các

module phần mềm trên máy tính

2.1 Nắm bắt yêu cầu bài toán

2.1.1 Bài toán đặt ra

Trong một Công ty, doanh nghiệp, vấn đề quản lý nhân viên thực hiện công

việc, lên các kế hoạch và theo dõi, giám sát nhân viên thực hiện công việc là một vấn

đề rất được quan tâm bởi các nhà quản lý doanh nghiệp Việc lên kế hoạch thực hiện

công việc, phân công nhân lực thực hiện cũng như theo dõi, giám sát về khối lượng,

chất lượng, tiến độ thực hiện công việc một cách khoa học, chặt chẽ là một trong

những yêu tố quan trọng được đặt lên hàng đầu trong các doanh nghiệp sản xuất

Ngoài việc quản lý thực hiện sản xuất, kinh doanh, các nhà quản lý doanh nghiệp cũng

có các chế độ khen thưởng dưới nhiều hình thức tới các nhân viên của mình một cách

kịp thời nhằm khuyến khích, động viên đội ngũ nhân viên của mình nhiệt tình phấn

đấu nâng cao năng suất và chất lượng thực hiện công việc

Để đạt được mục tiêu đó, các nhà quản lý phải lưu thông tin các hoạt động liên

quan đến quản lý, phân công xử lý công việc cũng như nhân lực và kế hoạch thực hiện

các công việc đó

Với các doanh nghiệp lớn, số lượng nhân viên nhiều và khối lượng công việc

xử lý hằng ngày cũng tương đối lớn, việc quản lý, theo dõi việc thực hiện công việc,

phân công giải quyết công việc, đòi hỏi nhiều công sức và thời gian Do đó, để thuận

lợi cho công tác quản lý cần có hệ thống thông tin dựa trên máy tính

Do số lượng các công việc rất lớn, vì vậy yêu cầu hệ thống phải đơn giản để có

thể thao tác nhanh chóng và chính xác

2.1.2 Phạm vi bài toán

Bài toán “tổ chức và quản lý hoạt động giao công việc” là bài toán phổ biến ở tất cả các công ty, cơ quan, doanh nghiệp Mục đích quản lý của các Cơ quan, Doanh nghiệp là nhƣ nhau, nhƣng do cách quản lý khác nhau nên luận văn không đi sâu vào các hoạt động của một Doanh nghiệp cụ thể Ở đây chỉ tập trung vào những chức năng chính tiêu biểu cho nhiều Cơ quan, Doanh nghiệp:

1 Quản lý đầu mục công việc

2 Quản lý giao công việc

3 Quản lý luồng thông tin chỉ đạo giải quyết công việc

4 Quản lý phân quyền duyệt, xem, xử lý công việc

5 Thống kê, báo cáo và tìm kiếm

2.1.3 Mô tả nghiệp vụ quản lý

2.1.3.1 Xác định các thông tin chung về quản lý công việc

Trong các Cơ quan, doanh nghiệp, cơ cấu tổ chức quản lý-điều hành điển hình đƣợc phân theo cấp quản lý từ cao xuống thấp nhƣ sau:

1 Ban Giám đốc (Giám đốc, các phó giám đốc, trợ lý, thƣ ký giám đốc)

Tổ m

Hình 2.1 Mô hình phân cấp quản lý trong doanh nghiệp Các công việc đƣợc xuất phát, tạo ra từ cấp Lãnh đạo phòng/tổ trở lên với nguồn

là: các chỉ đạo trong các cuộc họp, các công văn và các chỉ đạo đến từ cấp trên, công việc riêng của phòng Các công việc được tổ chức theo mô hình cây phân cấp, một công việc lớn được phân thành nhiều công việc nhỏ, mỗi công việc nhỏ nhất được giao cho một chuyên viên giải quyết

Thông tin cơ bản của mỗi công việc bao gồm: Tên công việc, Ngày giao, Người giao, Ngày yêu cầu kết thúc, Độ khẩn, Nội dung công việc, Nội dung giải quyết, Người (nhóm người giải quyết), ngày hoàn thành công việc, Khối lượng hoàn thành, Trạng thái giải quyết, Thời gian tiếp nhận công việc, Trạng thái (đọc, chưa đọc), Nội dung chỉ đạo,

Mỗi công việc được quản lý phân cấp theo chủ đề công việc Khi có công việc phân xuống Phòng/ban (các công việc lớn được chia cho nhiều phòng ban, chuyên viên cùng giải quyết), lãnh đạo Phòng phân về các Tổ, các lãnh đạo Tổ lại chia nhỏ công việc để phân cho từng chuyên viên giải quyết (công việc nhỏ nhất)

Mỗi công việc có các trạng thái giải quyết sau:

 Chưa phân giải quyết: công việc mới tạo ra chưa phân giải quyết

 Đang giải quyết: công việc đã được phân cho phòng ban (hay chuyên viên)

giải quyết nhưng chưa giải quyết xong

 Đã giải quyết xong: Tất cả các công việc đã phân cho phòng ban (hay

chuyên viên) giải quyết, và các công việc này đã được giải quyết xong

 Quá hạn giải quyết: tất cả các công việc đang giải quyết mà có ngày kết

thúc nhỏ hơn ngày hiện tại

Lãnh đạo dựa vào trạng thái giải quyết và mức độ hoàn thành công việc để theo dõi và cập nhật nội dung chỉ đạo thực hiện công việc Lãnh đạo có thể tổng hợp số lượng công việc theo trạng thái giải quyết và xem tiến độ giải quyết công việc của một chuyên viên, tổ, phòng hay toàn công ty

2.1.3.2 Công tác quản lý hoạt động giao công việc

Cấp trên (Lãnh đạo phòng/tổ trở lên) tạo các công việc và phân cho các cấp quản

lý dưới giải quyết (Giám đốc phân cho phòng, Lãnh đạo phòng phân cho Lãnh đạo tổ, Lãnh đạo tổ phân cho các Chuyên viên phối hợp giải quyết, )

Chỉ có người tạo ra công việc mới có quyền sửa, xoá nội dung công việc Người tạo ra công việc và Người chủ trì giải quyết công việc có quyền thay đổi các thông tin

về tiến độ hoàn thành và nội dung giải quyết công việc Người dùng ở cấp quản lý nào chỉ xem và chỉ đạo, giải quyết được các công việc tương ứng với cấp của mình

Công việc được Lãnh đạo phân công cho cấp dưới giải quyết có kèm theo độ

khẩn, giới hạn giải quyết và nội dung giải quyết cụng việc Một cụng việc cú thể được phõn cho một hoặc nhiều người giải quyết Mỗi cụng việc cú một người được giao trỏch nhiệm chớnh (người chủ trỡ cụng việc) Người chủ trỡ cụng việc cú quyền xem và chỉ đạo, phối hợp với cỏc người khỏc trong nhúm để giải quyết cụng việc Cỏc người thuộc nhúm tiếp nhận cụng việc, giải quyết phần việc của mỡnh và cập nhật nội dung giải quyết cụng việc Người chủ trỡ xem xột nội dung giải quyết cụng việc của cỏc thành viờn trong nhúm và cho cỏc chỉ đạo giải quyết, cập nhật thụng tin mức độ hoàn thành cụng việc, thụng tin đề xuất kiến nghị với cấp trờn

2.1.3.3 Sơ đồ tiến trỡnh quản lý hoạt động giao cụng việc

Ban Giá m Đ ốc, Th- ký Giá m đốc Ban Lã nh đạ o phòng, Chð trì công việc Nhân viê n

Tạ o đầu múc c ông việc t- ơng ứng

Nhập c hỉ đạ o và p hân

giả i q uyết

Nhập c hỉ đạ o và p hân giả i

q uyết Tạ o đầu múc công việc

Gải quyết

Nhập chỉ đạ o thực hiện

Bá o cá o Ch- a hoàn thành

Chỉ đạ o Hoàn thành

Kết thủc

Hỡnh 2.2: Sơ đồ tiến trỡnh quản lý hoạt động giao cụng việc

2.1.3.4 Cỏc yờu cầu xõy dựng hệ thống quản lý hoạt động giao cụng việc

Hệ thống quản lý hoạt động giao cụng việc được xõy dựng phải đỏp ứng được cỏc yờu cầu sau:

 Nội dung thông tin về công việc, luồng thông tin giải quyết công việc được lưu trên máy tính

 Hệ thống có thể hiển thị cây phân cấp giải quyết công việc theo từng chủ đề công việc, người dùng/nhóm người dùng/phòng ban Các công việc được hiển thị với màu sắc khác nhau tương ứng với trạng thái công việc đang/chưa/quá hạn giải quyết, điều này giúp Lãnh đạo biết được công việc đang ứ đọng và tắc lại ở bộ phận/phòng ban nào để kịp thời đôn đốc, chỉ đạo giải quyết

 Hệ thống đưa ra được ứng với mỗi công việc có bao nhiêu phòng/ban, chuyên viên tham gia vào công việc đó, tổng thời gian giải quyết công việc, thời gian chậm tiến độ

 Hệ thống đưa ra được ứng với mỗi người dùng/phòng ban có bao nhiêu công việc đã/đang/chưa giải quyết

 Vẽ biểu đồ Grantt hiển thị kế hoạch thực hiện cho từng chủ đề công việc: căn cứ vào ngày giải quyết và thời gian giải quyết có thể vẽ biểu đồ phân lịch giải quyết công việc, tuần tự các công việc được thực hiện

 Có thể tra cứu, báo cáo thống kê tình hình thực hiện, khối lượng thực hiện công việc dễ dàng, nhanh chóng trên máy tính

2.1.3.5 Các chức năng hệ thống

R.1 Cập nhật đầu mục công việc

R.1.1 Tạo đầu mục công việc mới R.1.2 Sửa đầu mục công việc R.1.3 Xoá đầu mục công việc

R.2 Phân giải quyết công việc R.3 Chỉ đạo giải quyết công việc

R.3.1 Thêm chỉ đạo mới R.3.2 Cập nhật chỉ đạo

R.4 Giải quyết công việc R.5 Cập nhật từ điển R.6 Vẽ biểu đồ Grantt

R.6.1 Vẽ biểu đồ công việc theo người giải quyết