1. Trang chủ
  2. » Luận Văn - Báo Cáo

Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP

121 512 7

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 121
Dung lượng 5,88 MB

Nội dung

Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP

Trang 1

Luận văn thạc sĩ - 1 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

MỤC LỤC

DANH MỤC CÁC TỪ TIẾNG ANH VÀ VIẾT TẮT 4

DANH MỤC CÁC BẢNG 4

DANH MỤC CÁC HÌNH, SƠ ĐỒ 6

MỞ ĐẦU 7

Mục tiêu, phạm vi của đề tài 7

CHƯƠNG I: HỆ THỐNG HOẠCH ĐỊNH NGUỒN LỰC DOANH NGHIỆP - ERP VÀ CÁC VẤN ĐỀ ĐẶT RA 10

I Khái niệm về ERP 10

II Hiện trạng ERP ở Việt Nam và những bất cập 12

III Lựa chọn phương pháp tiếp cận phát triển hệ thống ERP 13

1 Cách tiếp cận hướng chức năng 13

2 Cách tiếp cận hướng đối tượng 18

3 So sánh sự giống và khác nhau của hai cách tiếp cận trong quá trình phát triển phần mềm: 20

4 Ưu điểm chính của phương pháp hướng đối tượng 21

5 Lựa chọn phương pháp tiếp cận để phát triển Hệ thống thông tin quản trị nhân sự&Lương trong bài toán ERP 22

CHƯƠNG II: QUY TRÌNH PHÂN TÍCH, THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 23

I Xây dụng mô hình nghiệp vụ 23

1 Mở đầu 23

2 Tìm hiểu nắm vững nghiệp vụ 23

II Xác định yêu cầu 25

1 Mở đầu 25

2 Luồng công việc xác định yêu cầu 25

3 Tìm các tác nhân và các ca sử dụng 26

4 Thứ tự ưu tiên các ca sử dụng 28

5 Mô tả chi tiết một ca sử dụng 29

6 Tạo bản mẫu Giao diện người dùng 30

7 Cấu trúc mô hình ca sử dụng 31

III Phân tích 32

1 Mở đầu 32

2 Luồng công việc phân tích 33

3 Phân tích kiến trúc 33

4 Phân tích một ca sử dụng 36

Trang 2

Luận văn thạc sĩ - 2 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

5 Phân tích một lớp 39

6 Phân tích một gói 40

IV Thiết kế 41

1 Mở đầu 41

2 Luồng công việc thiết kế 42

3 Thiết kế kiến trúc 42

4 Thiết kế một ca sử dụng 46

5 Thiết kế một lớp 49

6 Thiết kế một hệ thống con 52

CHƯƠNG III: HỆ THỐNG QUẢN LÝ NHÂN SỰ - TIỀN LƯƠNG 54

I Chức năng nhiệm vụ 54

II Mô tả hoạt động nghiệp vụ quy trình quản lý nhân sự, tiền lương 55

1.Đặc tả yêu cầu 55

2.Quy trình quản lý nhân sự tiền lương 57

2.1 Biểu đồ hoạt động nghiệp vụ quản lý thông tin tuyển dụng nhân viên 57

2.2 Biểu đồ hoạt động nghiệp vụ quản lý Hợp đồng lao động 59

2.3 Biểu đồ hoạt động nghiệp vụ quản lý Quá trình công tác 62

2.4 Biểu đồ hoạt động nghiệp vụ quản lý quá trình khen thưởng, kỷ luật 63

2.5 Biểu đồ hoạt động nghiệp vụ quản lý Quá trình đào tạo 66

2.6 Biểu đồ hoạt động nghiệp vụ quản lý Lương 68

Tổng hợp các chức năng của quy trình quản lý Nhân sự - Tiền lương 69

III Phát triển mô hình ca sử dụng 71

1 Xác định tác nhân 71

2 Xác định ca sử dụng 71

3 Mô hình ca sử dụng mức gộp 73

3.1 Mô hình ca sử dụng mức gộp quản lý thông tin tuyển dụng nhân viên 73

3.2 Mô hình ca sử dụng mức gộp quản lý Hợp đồng lao dộng 74

3.3 Mô hình ca sử dụng mức gộp quản lý Khen thưởng – Kỷ luật 75

3.4 Mô hình ca sử dụng mức gộp quản lý Quá trình đào tạo 75

3.5 Mô hình ca sử dụng mức gộp quản lý Lương 76

IV Mô tả chi tiết các ca sử dụng điển hình 76

1.Ca sử dụng cập nhật danh mục công việc 76

2.Ca sử dụng cập nhật Hợp đồng lao động 79

2.1 Ca sử dụng thêm mới hợp đồng lao động 80

2.2 Ca sử dụng sửa thông tin hợp đồng lao động 81

2.3 Ca sử dụng xóa hợp đồng lao động 82

2.4 Ca sử dụng tìm kiếm hợp đồng lao động 82

Trang 3

Luận văn thạc sĩ - 3 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

V Phân tích hệ thống 83

1 Ca sử dụng cập nhật danh mục công việc 83

2 Ca sử dụng cập nhật Hợp đồng lao động 84

2.1 Mô hình khái niệm 84

2.2 Biểu đồ tuần tự 86

VI Biểu đồ lớp 87

1 Biểu đồ lớp quản lý thông tin Tuyển dụng nhân viên 87

2 Biểu đồ lớp quản lý Hợp đồng lao động 88

3 Biểu đồ lớp quản lý Quá trình công tác 89

4 Biểu đồ lớp quản lý Quá trình khen thưởng – kỷ luật 90

5 Biểu đồ lớp quản lý Quá trình đào tạo 91

6 Biểu đồ lớp quản lý Lương 92

VII Thiết kế bảng thực thể dữ liệu 93

VIII.Chương trình thử nghiệm 116

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 118

TÀI LIỆU THAM KHẢO 121

Trang 4

Luận văn thạc sĩ - 4 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

DANH MỤC CÁC TỪ TIẾNG ANH VÀ VIẾT TẮT

DANH MỤC CÁC BẢNG

Bảng 1: Đợt tuyển dụng - NS_UV_DotTuyendung 93

Bảng 2: Đề nghị tuyển dụng - NS_DeNghiTuyenDung 93

Bảng 3: Vị trí tuyển dụng - NS_Vitri 93

Bảng 4: Chi tiết đề nghị tuyển dụng - NS_DeNghiChiTiet 94

Bảng 5: Hội đồng tuyển dụng - NS_Hoidong 94

Bảng 6: Chi tiết hội đồng - NS_ChiTietHoidong 94

Bảng 7: Kết quả phỏng vấn - Kiểm tra - NS_KetQuaPhongVan 94

Bảng 8: Hồ sơ dự tuyển - NS_UV_Hosotuyendung 95

Bảng 9: Bằng cấp của ứng viên - NS_UV_BangCap 95

Bảng 10: Quá trình làm việc của ứng viên - NS_UV_QuaTrinhLamViec 96

Bảng 11: Quá trình học tập của ứng viên - NS_UV_QuaTrinhHocTap 96

Bảng 12: Danh mục công ty thành viên/Chi nhánh - NS_DM_CongTy 96

Bảng 13: Danh mục bộ phận - NS_DM_Bophan 98

Bảng 14: Danh mục Chức danh - NS_DM_Chucdanh 98

Bảng 15 : Danh mục Chức vụ - NS_DM_Chucvu 98

Bảng 16: Danh mục Bằng cấp - NS_DM_Bangcap 98

Bảng 17: Danh mục Loại hợp đồng - NS_DM_Hopdong 99

Bảng 18: Danh mục Lý do vắng mặt- NS_DM_LydoVang 99

Bảng 19: Danh mục Ca làm việc - NS_DM_Ca 99

Bảng 20: Danh mục Bộ phận - NS_DM_BoPhan 99

Bảng 21: Thông tin nhân viên - NS_Nhanvien 100

Bảng 22: Hợp đồng lao động/Thử việc - NS_HopdongLD 101

Bảng 23: Nhận xét thử việc - NS_NhanxetThuviec 101

Trang 5

Luận văn thạc sĩ - 5 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

Bảng 24: Tạm hoãn hợp đồng - NS_TamhoanHDLD 103

Bảng 25: Chấm dứt hợp đồng - NS_ChamdutHDLD 103

Bảng 26: Thông tin sức khỏe nhân viên - NS_SucKhoe 103

Bảng 27: Thông tin quan hệ nhân viên - NS_QuanHe 104

Bảng 28: Lý lịch làm việc nhân viên - NS_LylichLamviec 104

Bảng 29: Quá trình làm việc nhân viên - NS_QuatrinhLamviec 104

Bảng 30: Nghỉ phép năm nhân viên - NS_NghiphepNam 105

Bảng 31: Nghỉ phép nhân viên - NS_Nghiphep 105

Bảng 32: Bảo hiểm Y tế nhân viên - NS_BHYT 105

Bảng 33: Bảo hiểm xã hội nhân viên - NS_BHXH 106

Bảng 34: Xếp ca nhân viên - NS_XepCa 106

Bảng 35: Lương cơ bản - NS_LuongCoBan 106

Bảng 36: Bảng Hệ số lương - NS_BangHeSoLuong 107

Bảng 37: Bảng lương chi tiết - NS_BangLuongChitiet 107

Bảng 38: Bảng chấm công - NS_BangChamCong 108

Bảng 39: Tạm ứng - NS_TamUng 109

Bảng 40: Bảng mã chấm công - NS_MaChamcong 109

Bảng 41: Cách tính lương - NS_CachtinhLuong 109

Bảng 42: Bảng thuế thu nhập - NS_ThueThuNhap 111

Bảng 43: Ngày nghỉ - NS_NgayNghi 111

Bảng 44: Yêu cầu khen thưởng kỷ luật - NS_YeucauKTKL 111

Bảng 45: Loại khen thưởng kỷ luật - NS_LoaiKTKL 111

Bảng 46: Hội đồng khen thưởng kỷ luật - NS_HoidongKTKL 112

Bảng 47: Chi tiết hội đồng khen thưởng kỷ luật - NS_ChitietHoidongKTKL 112

Bảng 48: Kết luận khen thưởng kỷ luật - NS_KetluanKTKL 112

Bảng 49: Danh mục dự án - NS_DM_DuAn 112

Bảng 50: Thành viên dự án - NS_ThanhvienDuAn 113

Bảng 51: Danh mục công việc - NS_DM_Congviec 113

Bảng 52: Quá trình công tác - NS_QuatrinhCongtac 113

Bảng 53: Yêu cầu đào tạo - NS_YeucauDaotao 113

Bảng 54: Khóa học - NS_KhoaHoc 114

Bảng 55: Khóa học - NS_ChiTietKhoaHoc 114

Bảng 56: Phê duyệt khóa học - NS_PheDuyetKhoahoc 115

Bảng 57: Qua trình đào tạo - NS_QuatrinhDaotao 115

Trang 6

Luận văn thạc sĩ - 6 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

DANH MỤC CÁC HÌNH, SƠ ĐỒ

Hình 1: Biểu đồ hoạt động nghiệp vụ quản lý thông tin Tuyển dụng Nhân viên 57

Hình 2: Biểu đồ hoạt động nghiệp vụ quản lý Hợp đồng lao động 60

Hình 3: Biểu đồ hoạt động nghiệp vụ quản lý Quá trình công tác 62

Hình 4: Biểu đồ hoạt động nghiệp vụ quản lý Khen thưởng – Kỷ luật 63

Hình 5: Biểu đồ hoạt động nghiệp vụ quản lý Quá trình đào tạo 66

Hình 6: Biểu đồ hoạt động nghiệp vụ quản lý Lương 68

Hình 7: Mô hình ca sử dụng mức gộp quản lý Tuyển dụng nhân viên 73

Hình 8: Mô hình ca sử dụng mức gộp quản lý Hợp đồng lao động 74

Hình 9: Mô hình ca sử dụng mức gộp quản lý Khen thưởng – Kỷ luật 75

Hình 10: Mô hình ca sử dụng mức gộp quản lý Quá trình đào tạo 75

Hình 11: Mô hình ca sử dụng mức gộp quản lý Lương 76

Hình 12: Mô hình ca sử dụng mức gộp quản lý Công việc 77

Hình 13: Mô tả chi tiết ca sử dụng cập nhật Hợp đồng lao động 79

Hình 14: Sơ đồ liên kết ca sử dụng cập nhật danh mục Công việc 83

Hình 15: Biểu đồ tuần tự ca sử dụng cập nhật danh mục Công việc 83

Hình 16: Sơ đồ liên kết ca sử dụng cập nhật Hợp đồng lao động 85

Hình 17: Biểu đồ tuần tự ca sử dụng cập nhật Hợp đồng lao động 86

Hình 18: Biểu đồ lớp quản lý thông tin tuyển dụng nhân viên 87

Hình 19Biểu đồ lớp quản lý thông tin Hợp đồng lao động 88

Hình 20: Biểu đồ lớp quản lý Quá trình công tác 89

Hình 21: Biểu đồ lớp quản lý Quá trình khen thưởng – kỷ luật 90

Hình 22: Biểu đồ lớp quản lý Quá trình đào tạo 91

Hình 23: Biểu đồ lớp quản lý Lương 92

Trang 7

Luận văn thạc sĩ - 7 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

MỞ ĐẦU

Mục tiêu, phạm vi của đề tài

Đề tài nghiên cứu, phân tích và thiết kế Hệ thống thông tin quản lý Nhân sự & Lương trong Hệ thống hoạch định nguồn lực doanh nghiệp (Enterprise Resource Planning - ERP) làm cơ sở cho việc xây dựng sản phẩm phần mềm ERP phục vụ,

hỗ trợ và hiện đại hoá công tác quản lý các hoạt động của doanh nghiệp

ERP - Hoạch định nguồn lực doanh nghiệp (Enterprise resources Planning) là bộ giải pháp công nghệ thông tin có khả năng tích hợp toàn bộ ứng dụng quản lí sản xuất kinh doanh vào một hệ thống duy nhất, có thể tự động hoá các quy trình quản

lý, điều hành Mọi hoạt động của doanh nghiệp, từ quản trị nguồn nhân lực, quản lý dây chuyền sản xuất và cung ứng vật tư, quản lý tài chính nội bộ đến việc bán hàng, tiếp thị sản phẩm, trao đổi với các đối tác, với khách hàng đều được thực hiện trên một hệ thống duy nhất

Đặc trưng của phần mềm ERP là có cấu trúc phân hệ (module) Phần mềm có cấu trúc phân hệ là một tập hợp gồm nhiều phần riêng lẻ, mỗi phần có một chức năng riêng Từng phân hệ có thể hoạt động độc lâp nhưng do bản chất của hệ thống ERP, chúng kết nôi với nhau để tự động chia sẻ thông tin với các phân hệ khác nhau nhằm tạo nên một hệ thống mạnh hơn

Theo tài liệu chính thức của CIBRES, cơ quan tổ chức thi và cấp chứng chỉ CIERP (Certified Implementer of ERP – Chứng chỉ chuyên viên triển khai hệ thống ERP) thì một ERP tiêu chuẩn sẽ bao gồm các thành phần sau đây:

1 Kế toán tài chính

Sổ cái

Sổ phụ tiền mặt, sổ phụ ngân hàng Bán hàng và các khoản phải thu Mua hàng và các khoản phải trả

2 Nhân sự & Lương

3 Tài sản cố định

4 Hậu cần

Quản lý kho và tồn khoQuản lý giao nhận

Trang 8

Luận văn thạc sĩ - 8 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

Quản lý nhà cung cấp

5 Sản xuấtLập kế hoạch sản xuấtLập kế hoạch nguyên vật liệuLập kế hoạch phân phốiLập kế hoạch điều phối năng lựcCông thức sản phẩm

Quản lý luồng sản xuất Quản lý mã vạch

Quản lý lệnh sản xuất

6 Dự báo và lập kế hoạch

7 Công cụ lập báo cáoNhư vậy, ERP là một tổ hợp các thành phần dành cho các phòng ban chức năng trong một doanh nghiệp như kế toán, bán hàng, vật tư, sản xuất

Một hệ thống ERP cụ thể có thể gồm không đầy đủ các thành phần trên Nhưng, như đã nói, "tích hợp" mới là điều chính yếu nhất của ERP Tích hợp ở đây hiểu là mọi phân hệ trong ERP cuối cùng đều đưa dữ liệu về một CSDL chung và duy nhất, sau đó dữ liệu sẽ tự tìm đường đi để có mặt trong các bước xử lý tiếp theo ở những

bộ phận liên quan, cũng như trên các báo cáo tài chính và quản trị Nói một cách khác, không có dữ liệu nào cần phải nhập vào hai lần trong toàn bộ hệ thống này, là điều khó tránh khi doanh nghiệp sử dụng nhiều hệ thống chức năng riêng rẽ trước kia

ERP giúp doanh nghiệp đánh giá được dịch vụ hoặc vùng tập trung nhiều khách hàng, đánh giá dịch vụ khách hàng ưa thích sử dụng cũng như khách hàng tiềm năng Bên cạnh đó, ERP còn thể hiện nhiều lợi ích khác với tính năng tích hợp như: Phát triển khả năng mua bán và đặt hàng cũng như đăng kí dịch vụ trên mạng; điều phối toàn bộ giá cả cho các dự án; Theo dõi, quản lí và sử dụng các tài sản; Xác định quyền hạn và trách nhiệm của từng người tham gia hệ thống

Như đã giới thiệu ở trên, ERP là một hệ thống quản lý bao trùm lên mọi hoạt động của doanh nghiệp Trong phạm vi đề tài này em chỉ tiến hành nghiên cứu, phân tích

và thiết kế một phần trong bài toán ERP đó là: Xây dựng hệ thống thông tin Quản

lý Nhân sự & Tiền lương trong hệ thống ERP

Trang 9

Luận văn thạc sĩ - 9 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

Trang 10

Luận văn thạc sĩ - 10 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

CH

Ư ƠNG I :

HỆ THỐNG HOẠCH ĐỊNH NGUỒN LỰC DOANH NGHIỆP -

ERP VÀ CÁC VẤN ĐỀ ĐẶT RA

I Khái niệm về ERP.

Hệ thống hoạch định Nguồn lực Doanh nghiệp - Enterprise Resource Planning (ERP) là một thuật ngữ được dùng liên quan tới một loạt hoạt động của doanh nghiệp, do phần mềm máy tính hỗ trợ , giúp doanh nghiệp quản lý một cách hiệu quả các nguồn lực Đồng thời quản lý, theo dõi và đánh giá các hoạt động trong doanh nghiệp bao gồm: kế toán, phân tích tài chính, quản lý mua hàng, quản lý tồn kho, hoạch định và quản lý sản xuát, quản lý hậu cần, quản lý quan hệ với khách hàng, v.v Mục tiêu tổng quát của hệ thống này là đảm bảo các nguồn lực thích hợp của doanh nghiệp như nhân lực, vật tư, máy móc và tiền bạc có sẵn với số lượng đủ khi cần, bằng cách sử dụng các công cụ hoạch định và lên kế hoạch

Các nhà quản lý đã sớm nhận thấy máy tính không chỉ đơn thuần là một công cụ trợ giúp nâng cao năng suất mà đã trở thành công cụ chủ đạo giúp doanh nghiệp tạo sự chuyển biến triệt để trong cách làm việc, tiết kiệm chi phí, nâng cao chất lượng sản phẩm cũng như cải thiện đáng kể mối quan hệ với khách hàng

Từ những năm 60 đến nay, trên thế giới đã có nhiều hệ thống quản lý được áp dụng cho các doanh nghiệp:

MRP – Material Requirement Planning – Hoạch định nhu cầu nguyên liệu

MRPII – Manufacturing Resource Planning – Hoạch định nguồn lực sản xuất MES – Manufacturing Execution System – Hệ thống điều hành sản xuất

ERP – Enterprise Resource Planning – Hoạch định nguồn lực doanh nghiệp

ERM – Enterprise Resource Management – Quản trị nguồn lực doanh nghiệp CRM – Client Relationship Management – Quản trị quan hệ khách hàng

SCM – Supply Chain Management – Quản trị dây chuyền cung cấp

Trang 11

Luận văn thạc sĩ - 11 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

MRP và MRPII: Hệ thống MRP được phát triển từ giữa những năm 60, đến giữa những năm 70 thì chuyển qua hệ thống MRPII MRP chủ yếu đưa ra các tính toán

về nguyên vật liệu cần thiết để hoàn thành kế hoạch sản xuất, MRPII chú trọng vào khái niệm quản lý, bao gồm quản lý lao động và chi phí Thời kỳ này các hệ thống chạy trên các hệ thống máy lớn Mainframe và máy Mini

ERP: Đến những năm 90, cùng với sự phát triển của công nghệ phần cứng và mạng máy tính dựa trên cấu trúc Client – Server sử dụng máy chủ PC thay cho máy lớn trở thành phổ biến, các hệ thống MRP nhường chỗ cho hệ thống mới là ERP ERP không chỉ giới hạn trong quản lý sản xuất mà còn bao trùm lên toàn bộ các hoạt động chính của doanh nghiệp như: Kế toán, Quản trị nhân lực, Quản trị hậu cần, Quản trị hệ thống bán hàng

Thập kỷ 90 là thời kỳ hoàng kim của ERP tất cả các công ty đa quốc gia và đại đa

số các công ty tại các nước phát triển đều đã triển khai ERP Đầu thế kỷ 21 thế giới bắt đầu nói nhiều đến bước phát triển tiếp theo của ERP là ERM cùng các hệ thống khác tận dụng tiến bộ của công nghệ Internet là CRM và SCM

ERM: ERM tuy gần với ERP về cách viết nhưng là khái niệm rộng hơn, nó không phải là một bước tiến hóa về chức năng hay kỹ thuật như MRP tiến hóa lên ERP, ERM thực chất là một bộ công cụ quản lý doanh nghiệp mà phần mềm chỉ là một

bộ phận Các công cụ khác có thể hoàn toàn mang tính quản lý như: Huấn luyện, Kỹ thuật quản trị dự án các yếu tố phi máy tính của ERM là điểm tiến hóa rất quan trọng, nhiều dự án ERP không thành công là do thiếu yếu tố này

CRM: Đặt trọng tâm vào khả năng giao tiếp với bên ngoài (Khách hàng, Nhà cung cấp ) của một hệ thống quản lý CRM quản lý từ phân tích thị trường, lập kế hoạch tiếp thị và bán hàng đến các hoạt động tiếp thị như chiến dịch tiếp thị trực tiếp qua Email, quản lý hoạt động chăm sóc khách hàng CRM còn phân tích nhiều chiều

về khách hàng để giúp doanh nghiệp định hướng các hoạt động phát triển sản phẩm

và bán hàng

SCM: Được định nghĩa là quá trình từ lập kế hoạch mua nguyên vật liệu, lựa chọn nhà cung cấp, đưa ra các quy trình theo đó nhà cung cấp sẽ phải tuân thủ trong việc cung cấp nguyên vật liệu cho doanh nghiệp, lập kế hoạch cho lượng hàng sản xuất,

Trang 12

Luận văn thạc sĩ - 12 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

quản lý quá trình giao hàng cho đến quản lý hàng trả lại và hỗ trợ khách hàng trong việc nhận hàng

Trong các hệ thống phần mềm quản lý nói trên, thì ERP là quan trọng nhất, đó là xương sống của mọi hệ thống quản lý trong các công ty lớn trên thế giới Tất cả các công ty đa quốc gia hiện nay sẽ ngừng hoạt động nếu hệ thống ERP của họ bị trục trặc vì bằng cách thủ công, công ty không thể kiểm soát được hàng trăm chi nhánh

và hàng triệu giao dịch diễn ra hàng ngày trên khắp thế giới Với các công ty vừa và nhỏ, ERP cũng là công cụ chính để họ tăng hiệu quả quản lý

II Hiện trạng ERP ở Việt Nam và những bất cập

ERP là sản phẩm của sự kết hợp giữa công nghệ thông tin cùng với bề dày kinh nghiệm quản lý trong đó cho phép nhà quản lý tối ưu hoá quy trình hoạt động theo

hệ thống quản trị tiêu chuẩn quốc tế Một hệ thống hoạt động mang tính mạng lưới,

do vậy yêu cầu người phát triển hệ thống phải có cái nhìn sâu rộng, tổng quát không những về CNTT mà còn phải có tầm nhìn chiến lược trong quản lý

Ở Việt Nam hiện còn tụt hậu khá xa trong tổ chức sản xuất, phân phối và triển khai ERP Số lượng các nhà sản xuất trong nước và nhập khẩu cũng đã đưa ra được sự lựa chọn nhất định cho nhiều đối tượng khách hàng Tuy nhiên, chưa hãng phần mềm ERP của Việt Nam nào xây dựng được một hệ thống ERP mạnh và chuyên nghiệp Các công ty lớn trong nước cũng mới chỉ bắt đầu bắt tay vào xây dựng sản phẩm Các hãng phần mềm của Việt Nam chủ yếu làm đại lý Hệ thống phân phối sản phẩm cho các hãng sản xuất ERP của nước ngoài, nên chỉ tác động được vào một khoảng hẹp các khách hàng có vốn đầu tư nước ngoài

Việc triển khai ERP cho các doanh nghiệp Việt Nam còn gặp rất nhiều khó khăn, hầu hết các doanh nghiệp đều chưa triển khai ERP với nhiều lý do chủ quan và khách quan sau:

+ Nhận thức: Các đối tượng triển khai ERP chủ yếu là các doanh nghiệp lớn, các doanh nghiệp Việt Nam chưa có thói quen chi trả một số tiền lớn để mua một hệ thống phần mềm quản lý các hoạt động của họ Phần lớn chỉ dừng lại ở mức triển khai một số phần mềm kế toán và một số phần mềm quản lý khác cho các bộ phận

Trang 13

Luận văn thạc sĩ - 13 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

trong công ty Tuy nhiên những phần mềm này hoạt động đơn lẻ không chia sẻthông tin với nhau

+ Quy trình quản lý: Để triển khai được hệ thống ERP đòi hỏi doanh nghiệp phải có các quy trình chặt chẽ, khoa học trong mọi hoạt động Muốn áp dụng được ERP trước hết phải chuẩn hóa quy trình nghiệp vụ, hiện nay hầu hết các doanh nghiệp Việt nam chưa có quy trình nghiệp vụ rõ ràng, cụ thể do đó không phải doanh nghiệp nào cũng dùng được ERP Những doanh nghiệp đã đạt chuẩn ISO về quy trình quản lý sẽ dễ dàng hơn khi triển khai ERP

+ Yêu cầu triển khai cao: ERP là một hệ thống phức tạp, do vậy khi triển khai phải đảm bảo các điều kiện cần thiết như cơ cấu nhân sự bao gồm cả phía triển khai và khách hàng, cán bộ tư vấn quản lý, tư vấn kỹ thuật, tư vấn hệ thống Công việc triển khai được chia làm nhiều giai đoạn: Phân tích và lập kế hoạch, thiết kế, chuyển đổi dữ liệu, chạy thử, chuyển giao

III Lựa chọn phương pháp tiếp cận phát triển hệ thống ERP

Có hai cách tiếp cận cơ bản để phát triển phần mềm:

Cách tiếp hướng chức năng và Cách tiếp cận hướng đối tượng.

1 Cách tiếp cận hướng chức năng

FoxPro hay Pascal từ trước đến nay đều được thực hiện theo cách tiếp cận hướng chức năng hay còn được gọi là cách tiếp cận hướng thủ tục Cách tiếp cận này có những đặc trưng sau:

Dựa vào chức năng, nhiệm vụ là chính Khi khảo sát, phân tích một hệ thống

chúng ta thường tập trung vào các nhiệm vụ mà nó cần thực hiện Chúng ta tập trung trước hết nghiên cứu các yêu cầu của bài toán để xác định các chức năng chính của hệ thống Do đó, hệ thống phần mềm được xem như là tập các chức năng,

Trang 14

Luận văn thạc sĩ - 14 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

hành tìm ra để làm việc, nó còn là ứng dụng thực tế của một khái niệm lý thuyết đầy hiệu lực

Theo cách tiếp cận này, việc phân rã chức năng và làm mịn dần được thực hiện theo cách từ trên xuống Khả năng của con người là có giới hạn khi khảo sát, nghiên cứu để hiểu và thực thi những gì mà hệ thống thực tế đòi hỏi Để thống trị (quản lý được) độ phức tạp của những vấn đề phức tạp trong thực tế

thường chúng ta phải sử dụng nguyên lý chia để trị, nghĩa là phân tách nhỏ các chức năng chính thành các chức năng đơn giản hơn theo cách từ trên xuống Quá trình

này được lặp lại cho đến khi thu được những đơn thể chức năng tương đối đơn giản, hiểu được và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp để liên kết chúng trong hệ thống Độ phức tạp liên kết các thành phần chức năng của hệ thống thường là tỉ lệ nghịch với độ phức tạp của các đơn thể Vì thế một vấn đề đặt ra là có cách nào để biết khi nào quá trình phân tách các đơn thể chức năng hay còn gọi là quá trình làm mịn dần này kết thúc Thông thường thì quá trình thực hiện phân rã các chức năng của hệ thống phụ thuộc nhiều vào độ phức hợp của bài toán ứng dụng và vào trình độ của những người tham gia phát triển phần mềm Một hệ thống được phân tích dựa trên các chức năng hoặc quá trình

sẽ được chia thành các hệ thống con và tạo ra cấu trúc phân cấp các chức năng

Ví dụ, hệ thống quản lý thư

viện có thể phân chia từ trên xuống như sau:

Hệ thống quản lý thư viện

Chúng ta có thể khẳng định là các chức năng của nhiều hệ thống thông tin quản lýđều có thể tổ chức thành sơ đồ chức năng theo cấu trúc phân cấp có thứ bậc

Các hoạt động trong quá trình phân tích HTTT được tiến hành theo một trình

tự khoa học, mang tính công nghệ cao Trước hết phải có kế hoạch phân tích tỷ

mỷ, chu đáo đễn từng khâu công việc Sau đó tiến hành từ bước phân tích chức năng của HTTT, phân tích dòng thông tin nghiệp vụ và sau đó tiến hành mô hình

Trang 15

Luận văn thạc sĩ - 15 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

hoá HTTT bằng các mô hình như sơ đồ luồng dữ liệu, các ma trận phân tích phạm

vi, cân đối chức năng và dữ liệu Cuối cùng là bản báo cáo chi tiết toàn bộ những kết quả của quá trình phân tích hệ thống Kết quả của giai đoạn phân tích sẽ là cơ

sở rất quan trọng để đưa ra quyết định có tiếp tục thiết kế hệ thống hay không Và nếu có thì tài liệu phân tích sẽ là nền tảng cơ bản để thiết kế hệ thống

Quá trình phân tích thiết kế sử dụng một nhóm các công cụ, kĩ thuật và mô hình để ghi nhận phân tích hệ thống hiện tại cũng như các yêu cầu mới của người sử dụng, đồng thời xác định khuôn dạng mới của hệ thống tương lai.Phân tích thiết kế hệ thống có cấu trúc có những quy tắc chung, chỉ ra những công

cụ sẽ được dùng ở từng giai đoạn của quá trình phát triển và quan hệ giữa chúng Mỗi quy tắc gồm một loạt các bước và giai đoạn, được hỗ trợ bởi các mẫu và các bảng kiểm tra, sẽ áp đặt cách tiếp cận chuẩn hoá cho tiến trình phát triển Giữa các bước có sự phụ thuộc lẫn nhau, sản phẩm của bước này là đầu vào của bước tiếp theo Điều này làm cho hệ thống đáng tin cậy hơn

Có sự tách bạch giữa mô hình vật lý và mô hình lôgic Mô hình vật lý thường được dùng để khảo sát hệ thống hiện tại và thiết kế hệ thống mới Mô hình lôgic dùng cho việc phân tích các yêu cầu của hệ thống

Một điểm khá nổi bật là trong phương pháp phân tích có cấu trúc này đã ghi nhận vai trò của người sử dụng trong các giai đoạn phát triển hệ thống

Trong chu trình phát triển hệ thống, người sử dụng tham gia vào hầu hết các pha trong vòng đời của mình, trừ pha mã hoá

Các giai đoạn thực hiện gần nhau trong quá trình phân tích thiết kế có thể tiến hành gần như song song

Mỗi giai đoạn có thể cung cấp những sửa đổi phù hợp cho một hoặc nhiều giaiđoạn trước đó

Quá trình xây dựng một HTTT bao gồm nhiều giai đoạn, mỗi giai đoạn có một nhiệm vụ cụ thể, giai đoạn sau dựa trên thành quả của giai đoạn trước, giai đoạn trước tạo tiền đề cho giai đoạn sau Do vậy, để đảm bảo cho quá trình thiết kế hệ thống được hiệu quả thì người phải tuân theo nguyên tắc tuần tự, không được bỏ

Trang 16

Luận văn thạc sĩ - 16 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

qua bất cứ một giai đoạn nào Đồng thời sau mỗi một giai đoạn, trên cơ sở phân tích đánh giá bổ sung phương án được thiết kế, người ta có thể quay lại giai đoạn trước

đó để hoàn thiện thêm rồi mới chuyển sang thiết kế giai đoạn tiếp theo, theo cấu trúc chu trình (lặp) Đây là một phương pháp khoa học làm cho quá trình thiết kế hệ thống trở nên mềm dẻo, không cứng nhắc và mỗi giai đoạn đều được bổ sung hoànthiện thêm trong quy trình thiết kế

Các đơn thể chức năng trao đổi với nhau bằng cách truyền tham số hay sử

dụng dữ liệu chung Một hệ thống phần mềm bao giờ cũng phải được xem như là một thể thống nhất, do đó các đơn thể chức năng phải có quan hệ trao đổi thống tin,

dữ liệu với nhau Trong một chương trình gồm nhiều hàm (thực hiện nhiều chức

Trang 17

Luận văn thạc sĩ - 17 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

năng khác nhau) muốn trao đổi dữ liệu được với nhau thì nhất thiết phải sử dụng dữ liệu liệu chung hoặc liên kết với nhau bằng cách truyền tham biến Mỗi đơn thể chức năng không những chỉ thao tác, xử lý trên những biến dữ liệu cục bộ mà còn phải sử dụng các biến chung, thường đó là các biến toàn cục.

Chức năng 1 Chức năng 2

Dữ liệu riêng Dữ liệu riêng

Với việc sử dụng những biến toàn cục thì những bất lợi trong quá trình thiết kế và lập trình là khó tránh khỏi Đối với những dự án lớn, phức tạp có nhiều nhóm thamgia, mỗi nhóm chỉ đảm nhận một số chức năng nhất định và như thế khi một nhóm có yêu cầu thay đổi về dữ liệu chung đó thì sẽ kéo theo tất cả các nhóm khác

có liên quan cũng phải thay đổi theo Kết quả là khi có yêu cầu thay đổi của một đơn thể chức năng sẽ ảnh hưởng tới các chức năng khác và do đó sẽ ảnh hưởng tới hiệu xuất lao động của các nhóm cũng như của cả dự án Mặt khác, các chức năng của hệ thống có nhu cầu phải thay đổi là tất yếu và rất thường xuyên

Tính mở và thích nghi của hệ thống được xây dựng theo cách tiếp cận này là thấp

vì:

Hệ thống được xây dựng dựa vào chức năng là chính mà trong thực tế thì chức năng, nhiệm vụ của hệ thống lại hay thay đổi Để đảm bảo cho hệ thống thực hiện

được công việc theo yêu cầu, nhất là những yêu cầu về mặt chức năng đó lại bị thay

đổi là công việc phức tạp và rất tốn kém Ví dụ: giám đốc thư viện yêu cầu thay đổi

cách quản lý bạn đọc hoặc hơn nữa, yêu cầu bổ sung chức năng theo dõi những tài liệu mới mà bạn đọc thường xuyên yêu cầu để đặt mua, v.v Khi đó vấn đề duy trì

hệ thống phần mềm không phải là vấn đề dễ thực hiện Nhiều khi có những yêu cầu thay đổi cơ bản mà việc sửa đổi không hiệu quả và vì thế đòi hỏi phải thiết kế lại hệ thống thì hiệu quả hơn

Trang 18

Luận văn thạc sĩ - 18 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

Các bộ phận của hệ thống phải sử dụng biến toàn cục để trao đổi với nhau, do vậy khả năng thay đổi, mở rộng của chúng và của cả hệ thống là bị hạn chế Như trên đã phân tích, những thay đổi liên quan đến các dữ liệu chung sẽ ảnh hưởng tới các bộ phận liên quan Do đó, một thiết kế tốt phải rõ ràng, dễ hiểu và mọi sửa đổi chỉ có hiệu ứng cục bộ

Khả năng tái sử dụng bị hạn chế và không hỗ trợ cơ chế kế thừa Để có độ thích nghi cao thì mỗi thành phần phải là tự chứa Muốn là tự chứa hoàn toàn thì một thành phần không nên dùng các thành phần ngoại lai Tuy nhiên, điều này lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên là dùng lại được Vậy là cần có một sự cân bằng giữa tính ưu việt của sự dùng lại các thành phần (ở đây chủ yếu là các hàm) và sự mất mát tính thích ứng được của chúng Các thành của hệ thống phải có tính cố kết nhưng phải tương đối lỏng để dễ thích nghi Một trong cơ

chế chính hỗ trợ để dễ có được tính thích nghi là kế thừa thì cách tiếp cận hướng

chức năng lại không hỗ trợ Đó là cơ chế biểu diễn tính tương tự của các thực thể, đơn giản hoá định nghĩa những khái niệm tương tự từ những sự vật đã được định nghĩa trước trên cơ sở bổ sung hay thay đổi một số các đặc trưng hay tính chất của chúng Cơ chế này giúp chúng ta thực hiện được nguyên lý tổng quát hoá và chi tiết hoá các thành phần của hệ thống phần mềm

2 Cách tiếp cận hướng đối tượng

Để khắc phục được những vấn đề tồn tại nêu trên thì chúng ta cần phải nghiên cứu phương pháp, mô hình và công cụ mới, thích hợp cho việc phát triển phần mềm đáp ứng các yêu cầu của khách hàng Mô hình hướng đối tượng có thể giúp chúng ta vượt được khủng hoảng trong công nghệ phần mềm và hy vọng sẽ đưa ra được những sản phẩm phần mềm thương mại chất lượng cao: tin cậy, dễ mở rộng, dễ thích nghi, cường tráng và phù hợp với yêu cầu của khách hàng Cách tiếp cận hướng đối tượng có những đặc trưng sau

Đặt trọng tâm vào dữ liệu (thực thể) Khi khảo sát, phân tích một hệ thống chúng

ta không tập trung vào các nhiệm vụ như trước đây mà tìm hiểu xem nó gồm những

thực thể nào Thực thể hay còn gọi là đối tượng, là những gì như người, vật, sự kiện, v.v mà chúng ta đang quan tâm, hay cần phải xử lý Ví dụ, khi xây dựng “Hệ thống

Trang 19

Luận văn thạc sĩ - 19 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

quản lý thư viện” thì trước hết chúng ta tìm hiểu xem nó gồm những lớp đối tượng

hoặc những khái niệm nào

Xem hệ thống như là tập các thực thể, các đối tượng Để hiểu rõ về hệ thống,

chúng ta phân tách hệ thống thành các đơn thể đơn giản hơn Quá trình này được

lặp lại cho đến khi thu được những đơn thể tương đối đơn giản, dễ hiểu và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp khi liên kết chúng trong hệ

thống Xét “Hệ thống quản lý thư viện”, chúng ta có các lớp đối tượng sau:

Các lớp đối tượng trao đổi với nhau bằng các thông điệp Theo nghĩa thông thường thì lớp là nhóm một số người, vật có những đặc tính tương tự nhau hoặc có những hành vi ứng xử giống nhau Trong mô hình đối tượng, khái niệm lớp là cấu trúc mô tả hợp nhất các thuộc tính, hay dữ liệu thành phần thể hiện các đặc tính của mỗi đối tượng và các phương thức, hay hàm thành phần thao tác trên các dữ liệu riêng và là giao diện trao đổi với các đối tượng khác để xác định hành vi của chúng trong hệ thống Khi có yêu cầu dữ liệu để thực hiện một nhiệm vụ nào đó, một đối tượng sẽ gửi một thông điệp (gọi một phương thức) cho đối tượng khác Đối tượng nhận được thông điệp yêu cầu sẽ phải thực hiện một số công việc trên các dữ liệu

mà nó sẵn có hoặc lại tiếp tục yêu cầu những đối tượng khác hỗ trợ để có những thông tin trả lời cho đối tượng yêu cầu Với phương thức xử lý như thế thì một chương trình hướng đối tượng thực sự có thể không cần sử dụng biến toàn cục nữa.Tính mở và thích nghi của hệ thống cao hơn vì:

Hệ thống được xây dựng dựa vào các lớp đối tượng nên khi có yêu cầu thay đổi thì chỉ thay đổi những lớp đối tượng có liên quan hoặc bổ sung thêm một số lớp đối tượng mới (có thể kế thừa từ những lớp có trước) để thực thi những nhiệm vụ mới mà hệ thống cần thực hiện Ví dụ: Giám đốc thư viện yêu cầu bổ sung chức năng theo dõi những tài liệu mới mà bạn đọc thường

Trang 20

Luận văn thạc sĩ - 20 - Nguyễn Chí Thành

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên h tt :/ / w w lrc - tnu e d u.vn

xuyên yêu cầu để đặt mua, ta có thể bổ sung thêm lớp mới để theo dõi yêu cầu: lớp Yêu_Cầu

Trong các chương trình hướng đối tượng có thể không cần sử dụng biến toàn cục nên mọi sửa đổi, cập nhật trong mỗi thành phần chỉ có hiệu ứng cục

bộ.

Hỗ trợ sử dụng lại và cơ chế kế thừa Các lớp đối tượng được tổ chức theo

nguyên lý bao gói và che giấu thông tin, điều này làm tăng thêm hiệu quả của kế

thừa và độ tin cậy của hệ thống Các ngôn ngữ lập trình hướng đối tượng như: C++, Java, C#, Delphi, v.v đều hỗ trợ quan hệ kế thừa

3 So sánh sự giống và khác nhau của hai cách tiếp cận trong quá trình phát triển phần mềm:

Phát triển phần mềm hướng đối tượng Phát triển phần mềm có cấu trúc

Thiết kế

Lập trình hướng đối

Bước đệm

CSDL

CSDL quan hệ

Trang 21

4 Ưu điểm chính của phương pháp hướng đối tượng

Đối tượng là cơ sở để kết hợp các đơn thể có thể sử dụng lại thành hệthống lớn hơn, tạo ra những sản phẩm có chất lượng cao

Qui ước truyền thông điệp giữa các đối tượng đảm bảo cho việc mô tả các giao diện giữa các đối tượng thành phần bên trong hệ thống và những hệ thống bên ngoài trở nên dễ dàng hơn Điều đó giúp cho việc phân chia những

dự án lớn, phức tạp để phân tích, thiết kế theo cách chia nhỏ bài toán thành các lớp đối tượng hoàn toàn tương ứng với quan điểm hướng tới lời giải phù hợp với thế giới thực một các tự nhiên

Nguyên lý bao gói, che giấu thông tin hỗ trợ cho việc xây dựng những hệthống thông tin an toàn

Nguyên lý kế thừa dựa chính vào dữ liệu rất phù hợp với ngữ nghĩa của

mô hình trong cài đặt

Lập trình hướng đối tượng đặc biệt là kỹ thuật kế thừa cho phép dễ dàng xác định các đơn thể và sử dụng ngay khi chúng chưa thực hiện đầy đủ các chức năg (đơn thể mở) và sau đó mở rộng được mà không làm ảnh hưởng tới các đơn thể khác

Định hướng đối tượng cung cấp những công cụ, môi trường mới, hiệu quả

để phát triển phần mềm theo hướng công nghiệp và hỗ trợ để tận dụng được những khả năng kế thừa, sử dụng lại ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp, nhạy cảm như: hệ thống động, hệ thống thời gian thực, v,v

Xoá bỏ được hố ngăn cách giữa các pha phân tích, thiết kế và cài đặt trong quá trình xây dựng phần mềm

Trang 22

5 Lựa chọn phương pháp tiếp cận để phát triển Hệ thống thông tin quản trị nhân sự&Lương trong bài toán ERP.

Như đã trình bầy ở chương I, đặc trưng của ERP là có cấu trúc phân hệ (module)

Nó được cấu thành từ nhiều phần riêng lẻ, mỗi phần có một chức năng riêng và có thể hoạt động độc lập Nhưng tích hợp mới là đặc trưng nhất của ERP, tích hợp ở đây được hiểu là:

Tích hợp từ nhiều phân hệ (module)

Tích hợp nhiều chức năng

Tích hợp cho nhiều mô hình quản lý của doanh nghiệp

Khi triển khai, việc phải thay đổi lại cấu trúc, chức năng và các lựa chọn là không thể tránh khỏi để phù hợp với từng doanh nghiệp cụ thể Mặt khác khi xã hội ngày càng phát triển thì các quan hệ lao động, cách thức quản lý cũng phải thay đổi để phù hợp với yêu cầu, chính vì vậy những nhà phát triển ERP phải luôn luôn cải tiến sản phẩm của mình sao cho hài lòng khách hàng

Căn cứ vào các đặc điểm trên của ERP và các ưu điểm của phương pháp tiếp cận hướng đối tượng nên em chọn phương pháp này cho để thực hiện luận văn này

Trang 23

Ư ƠNG I I : QUY TRÌNH PHÂN TÍCH, THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

I Xây dụng mô hình nghiệp vụ

1 Mở đầu

Để nắm bắt được yêu cầu của một hệ thống tin học hóa, ta cần tìm hiểu hệ thống thực Công việc này được tiến hành bằng cách tìm hiểu hoạt động nghiệp vụ và xây dựng các mô hình miền và mô hình nghiệp vụ để nắm bắt toàn bộ các vấn đề thuần nghiệp vụ của hệ thống

mô hình nào cả

Xây dựng mô hình miền

Mục đich của mô hình hóa miền là để hiểu và mô tả các lớp quan trọng nhất bối cảnh của miền Ta có thể lập một từ điển giải thích để định nghĩa về các lớp miền

Từ điển thuật ngữ và mô hình miền giúp khách hàng và người phát triển chia sẻ những thuật ngữ khái niệm chung Đối với những miền nghiệp vụ rất nhỏ, không cần thiết phát triển một mô hình miền mà chỉ cần sử dụng từ điển thuật ngữ là đủ

Mô hình miền (domain model)

Mô hình miền mô tả các khái niệm quan trọng của hệ thống qua các đối tượng của miền nghiệp vụ và liên kết giữa chúng với nhau Các đối tượng miền là những vật hay khái niệm trong thực tế hoặc các sự kiện diễn ra trong môi trường mà hệ thống làm việc Có 3 dạng lớp đối tượng miền điển hình

Trang 24

Các đối tượng nghiệp vụ thể hiện những vật được quản lý trong hoạt động nghiệp vụ như: bản yêu cầu nhân sự, tài khoản, hợp đồng

Các đối tượng thế giới thực và các khái niệm mà một hệ thống cần theo dõi, ví dụ như giao dịch thanh toán, mua hàng, rút tiền…

Các sự kiện sẽ hoặc đã xuất hiện: Chấm công, phỏng vấn, ký hợp đồng lao động …

Mô hình miền có thể mô tả bằng nhiều biểu đồ lớp của UML

Xây dựng mô hình nghiệp vụ

Một mô hình nghiệp vụ được phát triển qua hai bước:

· Xây dựng một mô hình ca sử dụng nghiệp vụ bao gồm việc xác định các tác nhân nghiệp vụ mà các tác nhân sử dụng Mô hình cho phép người phát triển hiểu rõ hơn về giá trị mà nghiệp vụ đem lại cho tác nhân sử dụng nó

· Phát triển một mô hình đối tượng nghiệp vụ bao chứa những người tham gia nghiệp vụ, các thực thể nghiệp vụ và các đơn vị công việc cùng nhau thực hiện các ca sử dụng nghiệp vụ Các quy tác nghiệp vụ

và các điều chình khác trong nghiệp vụ được liên kết với các đối tượng khác

Mô hình nghiệp vụ (bussiness model)

Mô hình nghiệp vụ được thể hiện ra bằng một mô hình ca sử dụng nghiệp vụ Nó có thể bao gồm các chế tác(thành phần) sau:

· Đối tượng miền

· Đối tượng nghiệp vụ

· Người tham gia nghiệp vụ và các trách nhiệm, thao tác tương ứng

Mô hình ca sử dụng nghiệp vụ

Mô hình ca sử dụng nghiệp vụ mô tả các quá trình nghiệp vụ của một tổ chức dưới dạng các ca sử dụng nghiệp vụ và các tác nhân nghiệp vụ tương ứng Nó xem xét một hệ thống nghiệp vụ từ quan điểm người sử dụng và chỉ ra làm thế nào để hệ thống cung cấp một giá trị gia tăng cho tác nhân nghiệp vụ hệ thống đó Mô hình ca

sử dụng nghiệp vụ được miêu tả bằng sơ đồ ca sử dụng[3]

Trang 25

Mô hình miền là một trường hợp riêng của mô hình nghiệp vụ mà ở đó ta chỉ tập trung vào các vật – các lớp miền hoặc các thực thể nghiệp vụ mà người tham gia nghiệp vụ sẽ phải làm với chúng

2.2 Xác định các yêu cầu bổ sung

Các yêu cầu bổ sung là các yêu cầu phi chức năng mà không thể liên kết với các ca

sử dụng nghiệp vụ cụ thể nào Chúng có ảnh hưởng đến nhiều ca sử dụng hoặc chỉ đến một ca sử dụng nghiệp vụ nào đó Ví dụ như tính thể hiện, các giao diện, các yêu cầu thiết kế vật lý và kiến trúc, các rằng buộc về thiết kế và cài đặt

II Xác định yêu cầu

Mục tiêu của việc xác định yêu cầu la phát triển một mô hình ca sử dụng của hệ thống cần xây dựng bằng cách dùng các ca sử dụng Các ca sử dụng cung cấp một cách có hệ thống và trực quan để nắm bắt các yêu cầu có tính chức năng mà tập trung đặc biệt vào giá trị gia tăng đem lại cho mỗi cá nhân người dùng hoặc mỗi hệ thống bên ngoài tương tác với hệ thống

2 Luồng công việc xác định yêu cầu

Để mô tả các yêu cầu nghiệp vụ của hệ thống dưới góc độ phát triển phần mềm cần:

Tìm các tác nhân và các ca sử dụng: nhằm đưa ra một phiên bản đầu tiêncủa mô hình ca sử dụng

Xác định các ca sử dụng có ý nghĩa về mặt kiến trúc và sắp ưu tiên các ca

sử dụng sẽ được triển khai trong mỗi vòng lặp

Mô tả chi tiết mọi ca sử dụng đã được sắp thứ tự ưu tiên

Đưa ra các giao diện – người dùng thích hợp cho mỗi tác nhân tương tác trong các ca sử dụng

Tái cấu trúc mô hình ca sử dụng bằng cách xác định và đưa ra các tổng quát hóa của các ca sử dụng để làm sao cho chúng càng dễ hiểu càng tốt

Kết quả của luồng công việc này là một phiên bản đầu tiên của mô hình ca sử dụng, các ca sử dụng và các bản mẫu giao diện – người sử dụng đã được tổng hợp lại Các kết quả của các lần lặp tiếp theo sẽ gồm các phiên bản mới của các thành phần này

Trang 26

nhưng chúng sẽ được hoàn thiện, được cải tiến và làm mịn dần trong quá trình các bước lặp

3.1 Tìm các tác nhân

Có hai tiêu chuẩn để xác định các tác nhân:

· Phải có ít nhất một người dùng mà có thể thực hiện vai trò của tác nhân dự kiến

· Sự trùng lặp giữa các vai trò của những tác nhân khác nhau đóng vai trong mối quan hệ với hệ thống là tối thiểu nhất

Sau khi tìm được tác nhân cần:

Mô tả ngắn gọn các vai trò của mỗi tác nhân tương tác với hệ thống và mục tiêu sử dụng hệ thống Việc mô tả ngắn gọn mỗi tác nhân phải nêu bật được các yêu cầu và các trách nhiệm của tác nhân đó

Các tác nhân nhận được ở đây có thể dùng làm điểm xuất phát để tìm các ca sửdụng

Trang 27

Khi xác định các ca sử dụng, nên áp dụng hai tiêu chuẩn sau:

Kết quả có giá trị: Mỗi ca sử dụng được thực hiện thành công phải cung cấp một giá trị cho tác nhân để đạt được một mục tiêu nào đó khi tác nhân tương tác với hệ thống

Tác nhân cụ thể: Nhờ việc xác định các ca sử dụng mà chúng cung cấp giá trị cho tác nhân người dùng thực Các ca sử dụng không nên quá lớn

Ca sử dụng (use case)

Mỗi cách thức mà tác nhân sử dụng hệ thống được gọi là một ca sử dụng Có thể coi các ca sử dụng như là những “khúc” chức năng mà hệ thống cung cấp và đem lại một giá trị gia tăng cho tác nhân Nói một cách khác, mỗi ca sử dụng đặc tả một chuỗi các hành động(kể cả các chuỗi hành động thay thế) mà hệ thống có thể thực hiện khi tương tác với các tác nhân của nó Một thể hiện ca sử dụng là sự thực hiện(hoặc xử lý) của ca sử dụng đó

Từ điển giải thích(glossary)

Trang 28

Một từ điển giải thích thường được dùng để xác định các thuật ngữ quan trọng và thông dụng mà người phát triển sử dụng để mô tả hệ thống Một từ điển giải thích đem lại sự thống nhất trong việc định nghĩa các khái niệm và các cách diễn đạt giữa những người phát triển

Kết quả của bước này cũng là một mô tả tổng quan của mô hình ca sử dụng Nó mô

tả các tác nhân và các ca sử dụng tương tác với nhau như thế nào, và các ca sử dụng liên kết với nhau như thế nào

Sau đó cần thẩm định mô hình ca sử dụng theo các tiêu chí sau:

· Mọi yêu cầu cần thiết về mặt chức năng đã được nắm bắt thành các ca

4 Thứ tự ưu tiên các ca sử dụng

Mục đích hoạt động này là nhằm lập thứ tự ưu tiên các ca sử dụng để quyết định những ca sử dụng nào cần được triển khai ngay trong những lần lặp đầu và chúng đóng vai trò như kiến trúc của hệ thống

Mô tả kiến trúc

Mô tả kiến trúc la một cái nhìn về mặt kiến trúc của mô hình ca sử dụng Nó gồm những ca sử dụng mang ý nghĩa về mặt kiến trúc

Một mô tả kiến trúc của một mô hình ca sử dụng thường bao gồm các ca sử dụng

mô tả một vài chức năng cốt yếu và quan trọng hoặc liên quan đến một vài yêu cầu

Trang 29

quan trọng mà cần được phát triển Mô tả kiến trúc này thường được sử dụng như là đầu vào để phân loại các ca sử dụng cho việc phát triển trong một vài bước lặp đầu

5 Mô tả chi tiết một ca sử dụng

Mục đích chính ở đây là mô tả luồng các sự kiện của ca sử dụng một cách chi tiết khi khởi đông, tương tác với các tác nhân như thế nào đến kết thúc Để mô tả chi tiết ca sử dụng ta có thể mô tả bằng văn bản(hay bảng) và các biểu đồ ca sử dụng kèm theo

Luồng các sự kiện của một ca sử dụng

Là luồng các sự kiện đặc tả chuỗi công việc mà hệ thống làm khi một ca sử dụng cụ thể được thực hiện Luồng các sự kiện cũng đặc tả cách thức mà hệ thống tương tác với các tác nhân khi ca sử dụng được thực hiện Nó có thể được mô tả dưới dạng văn bản(hay bảng) chuỗi các hoạt động của một ca sử dụng

5.1 Cấu trúc của một Mô tả ca sử dụng

Cấu trúc của mô tả ca sử dụng thường được tổ chức sao cho cả người phát triển, khách hàng, và người dùng đều có thể hiểu được Mô tả ca sử dụng cần có cấu trúc như sau:

· Trạng thái xuất phát(tiền điều kiện)

· Làm thế nào và khi nào thì ca sử dụng khởi động( tức là hành động thứ nhất được thực hiện như thế nào)

· Các chuỗi hành động phải được thực hiện theo thứ tự Ở đây thứ tựđược xác định bởi chuỗi hành động đã đánh số

· Ca sử dụng kết thúc như thế nào và khi nào

· Trạng thái khi kết thúc(hậu điều kiện)

· Các con đường không được phép thực hiện

· Mô tả các con đường cơ bản(phương án) mà dãy hành động xảy ra

· Mô tả các phương án ngoại lệ

Có thể mô tả mỗi phương án thực hiện ca sử dụng bằng văn bản( hay một bảng với cột tác nhân và cột phản ứng của hệ thống)

Một nhiệm vụ quan trọng nữa là đặc tả là những yêu cầu phi chức năng Đa số các yêu cầu phi chức năng đều có liên quan tới một ca sử dụng cụ thể nào đó Chẳng hạn các yêu cầu về tốc độ thực hiện, tính khả dụng, độ chính xác, thời gian phúc

Trang 30

đáp, thời gian phục hồi Các yêu cầu như vậy được gọi là các yêu cầu đặc biệt của

ca sử dụng đang xét Ta có thể chuẩn bị chúng như một phần tài liệ của Mô tả ca sử dụng

5.2 Hình thức hóa các Mô tả ca sử dụng

Đối với các ca sử dụng phức tạp, có nhiều trạng thái và sự chuyển tiếp, các mô tả ca

sử dụng bằng văn bản thương không đảm bảo tính chất nhất quán và làm cho người phát triển khó hình dung Do vậy, có thể mô tả cấu trúc đó bằng cách sử dụng các biểu đồ có tính trực quan hơn

6 Tạo bản mẫu Giao diện người dùng

Bây giờ ta cần phác thảo các giao diện người dùng để giúp cho người thực hiện các

ca sử dụng một cách hiệu quả Với mỗi ca sử dụng, ta cố gắng để nhận biết xem cái

gì là cần đối với các giao diện người dùng để tạo ra khả năng cho mỗi tác nhân dùng các ca sử dụng Công việc này gọi là thiết kế giao diện người dùng logic Sau đó ta tạo thiết kế giao diện người dùng thực và phát triển các bản mẫu để minh họa cách thức mà các người dùng có thể dùng hệ thống để thực hiện các ca sử dụng

6.1 Tạo một thiết kế Giao diện người dùng Logic

Khi các tác nhân tương tác với hệ thống, tác nhân sẽ dùng và thao tác qua yếu tố giao diện người dùng thể hiện cho các thuộc tính của các ca sử dụng Ta sẽ xác định

và đặc tả các yếu tố này cho một tác nhân tại một thời điểm xác định bằng cách duyệt qua mọi ca sử dụng mà tác nhân có thể truy nhập và xác định các yếu tố giao diện người dùng tương ứng cho mỗi ca sử dụng

Để nhận được các yếu tố giao diện cho mỗi tác nhân cần xác định:

· Yếu tố nào của giao diện người dùng cần có để dùng được các ca sửdụng?

· Các yêu tố này sẽ quan hệ với nhau như thế nào?

· Chúng sẽ được sử dụng như thế nào trong các ca sử dụng khác nhau?

· Dáng dấp của chúng là ra sao?

· Chúng sẽ được điều khiển như thế nào?

Trang 31

Để xác định những yếu tố giao diện – người dùng nào là cần có trong mỗi ca sửdụng, chúng ta có thể trả lời các câu hỏi sau:

· Cái nào trong số các lớp lĩnh vực, các thực thể nghiệp vụ, hoặc các đơn vị công việc là thích hợp để làm các yếu tố giao diện – người dùng cho ca sử dụng này?

· Những yếu tố giao diện – người dùng nào mà tác nhân phải làm việc với chúng

· Những hành động nào mà tác nhân có thể gọi đến và những quyết định nào mà tác nhân có thể tạo ra?

· Hướng dẫn nào và thông tin nào mà tác nhân cần có trước khi gọi đến mỗi hành động trong ca sử dụng

· Thông tin gì mà tác nhân cần cung cấp cho hệ thống?

· Thông tin gì mà hệ thống cần cung cấp cho tác nhận?

· Các giá trị trung bình đối với mọi tham số đầu vào/ đầu ra là gì?

6.2 Tạo một thiết kế giao diện người dùng thực và làm bản mẫu

Trước tiên, ta chuẩn bị các phác thảo thô của chùm các yếu tố giao diện - người dùng hình thành các giao diện người dùng có ích cho các tác nhân Sau đó bổ sung các yếu tố cần thiết để tổ hợp hàng yếu tố của giao diện – người dùng thành các giao diện người dùng đầy đủ Các yếu tố bổ sung này có thể bao gồm các bộ chứa(container) các yếu tố giao diện – người dùng, các cửa sổ, các công cụ và các điều khiển

Ta chuẩn bị xây dựng các bản mẫu có khả năng thi hành các chùm các yếu tố giao diện – người dùng quan trọng nhất Các bản mẫu này có thể được xây dựng bằng một công cụ lập bản mẫu nhanh nào đó

Cuối cùng cần phải thẩm định giao diện người dùng thông qua các lần xét duyệt các bản mẫu, các phác thảo và thực hiện càng sớm càng tốt để có thể tránh được những sai sót

7 Cấu trúc mô hình ca sử dụng

Mục đích cấu trúc mô hình ca sử dụng là

Trang 32

Tìm ra các mô tả chức năng có đặc tính chung hay được chia sẻ trong nhiều ca sử dụng để tách ra mô tả riêng

Tìm ra các chức năng phụ hoặc tùy chọn để mở rộng mô tả chức năng thành các chức năng mới

7.1 Xác định các mô tả chức năng chung

Chúng ta cần tìm hành động hoặc các phần của các hành động mà là chung hoặc được chia sẻ cho nhiều ca sử dụng Phần chung này có thể được tách ra và được mô

tả trong một ca sử dụng riêng biệt Ca sử dụng này được thể hiện bằng một sự tổng quát hóa của các ca sử dụng đã có và là một ca sử dụng trừu tượng

Ca sử dụng “thực” là kết quả mà chúng ta nhận được sau khi áp dụng sự tổng hợp hai ca sử dụng: một cụ thể, một trừu tượng Ca sử dụng thực này trình bày hành vi của thể hiện ca sử dụng mà một tác nhân nhận thức được khi tương tác với hệ thống

7.2 Xác định các mô tả chức năng bổ sung và tùy chọn

Một mối quan hệ mở rộng các ca sử dụng là một thể hiện sự mở rộng thêm một chuỗi các hành động của một ca sử dụng Một mối quan hệ mở rộng như là một các được thêm vào trong mô tả của một ca sử dụng gốc Các ca sử dụng “thực” có được nhờ việc áp dụng các quan hệ tổng quát hóa và mở rộng đối với các ca sử dụng trong mô hình Các ca sử dụng thực mới đem lại giá trị cho người dùng

7.3 Xác định mối quan hệ khác giữa các ca sử dụng

Mối quan hệ bao gồm là mối quan hệ mở rộng đảo ngược, nó cung cấp các mở rộng tường minh và vô điều kiện cho một ca sử dụng Khi bao gồm một ca sử dụng, thì chuỗi hành vi và các thuộc tính của ca sử dụng bị bao gồm đều được đóng gói và không thể bị thay đổi hoặc truy nhập – chỉ có kết quả(hoặc chức năng) của ca sử dụng bị bao gồm là có thể khai thác được, điều này là một điểm khác so với việc dùng mối quan hệ tổng quát hóa

III Phân tích

Khi nắm bắt yêu cầu ta đã xác định các yêu cầu chức năng dưới dạng các ca sửdụng và các yêu cầu phi chức năng dưới dạng các tài liệu bổ sung cho các mô tả ca

Trang 33

sử dụng Tuy nhiên, hầu như vẫn còn các vấn đề tồn tại chưa được giải quyết về yêu cầu của hệ thống Để giải quyết các vấn đề tồn tại, ta cần phân tích các yêu cầu bằng cách sử dụng ngôn ngữ của nhà phát triển để mô tả các kết quả nhận được và ta sẽ nhận được một mô hình phân tích

Mô hình phân tích

Mô hình phân tích là một mô hình đối tượng khái niệm Nó xác định các yêu cầu và lập luận về cấu trúc nội tại của hệ thống Mô hình phân tích được thể hiện ở mức cao bằng một hệ thống các gói phân tích Trong mô hình phân tích, các ca sử dụng được thực thi bởi các lớp và các đối tượng phân tích

2 Luồng công việc phân tích

Để tạo ra mô hình phân tích cần tiến hành

3 Phân tích kiến trúc

Mục đích của phân tích kiến trúc là phác họa những nét lớn của mô hình phân tích thông qua việc xác định các gói phân tích, các lớp phân tích hiển nhiên, và các yêu cầu chuyên biệt chung

3.1 Xác định các gói phân tích

Việc xác định các gói phân tích có thể được tiến hành một cách tự nhiên dựa trên các yêu cầu chức năng và nghiệp vụ của bài toán được xet Một cách trực tiếp để xác định các gói phân tích là bố trí phần lớn các ca sử dụng vào một gói riêng rồi sau đó tiến hành thực thi chức năng tương ứng bên trong gói đó

Gom các ca sử dụng vào một gói riêng thích hợp có thể dựa trên các tiêu chí sau:

· Các ca sử dụng cần có để hỗ trợ một quá trình nghiệp vụ riêng

Trang 34

· Các ca sử dụng cần có để hỗ trợ một tác nhân riêng của hệ thống

· Các ca sử dụng có quan hệ với nhau thông qua các quan hệ tổng quát hóa và mở rộng

Gói phân tích

Các gói phân tích cung cấp một phương tiện để tổ chức các chế tác của mô hình phân tích thành các “cụm” nhỏ hơn và dễ quản lý Một gói phân tích có thể chứa đựng các lớp phân tích, các thực thi ca sử dụng và các gói phân tích khác

3.2 Xử lý phần chung của các gói phân tích

Trong nhiều trường hợp ta có thể tìm thấy các phần chung giữa các gói phân tích, chẳng hạn: một lớp phân tích Một cách thích hợp để xử lý vấn đề này là đặt phần chung đó vào trong gói riêng nằm ngoài các gói chứa nó, rồi sau đó để các gói khác

có liên quan phụ thuộc vào gói chứa lớp chung này

Những lớp được chia sẻ có các phần chung như vậy thường là các lớp thực thể Chúng có thể được lần vết tới các lớp thực thể miền hoặc nghiệp vụ Do vậy, ta nên nghiên cứu các lớp thực thể miền hoặc lớp thực thể nghiệp vụ để tìm ra phần chung

và tạo nên các gói phân tích tổng quát ngay từ đầu

3.3 Xác định các gói dịch vụ

Việc xác định các dịch vụ thích hợp thường được tiến hành sau khi các yêu cầu chức năng đã được hiểu rõ và đã xác định phần lớn các lớp phân tích Các lớp phân tích trong một gói dịch vụ cần đóng góp thực hiện cùng một dịch vụ

Để xác định các gói dịch vụ, ta có thể làm như sau

Xác định một gói dịch vụ cho mỗi dịch vụ được chọn

Xác định một gói dịch vụ cho mỗi dịch vụ mà có thể khiến dịch vụ đó trở thành lựa chọn Ta sẽ xác định một gói dịch vụ cho mỗi dịch vụ được cung cấp bởi các lớp liên quan về mặt chức năng

Gói dịch vụ

Mỗi hệ thống cung cấp một tập hợp các dịch vụ cho khách hàng Ta sử dụng khái niệm gói dịch vụ để mô tả các gói được sử dụng ở một mức thấp hơn trong sơ đồ

Trang 35

phân cấp phân tích để cấu trúc hệ thống các dịch vụ mà nó cung cấp Một gói dịch

vụ có thể có các tính chất sau:

· Một gói dịch vụ chưa một tập hợp các lớp có liên quan với nhau vềmặt chức năng

· Một gói dịch vụ là không thể chia nhỏ

· Một hoặc nhiều gói dịch vụ có thể tham gia vào một thực thi ca sửdụng và một gói dịch vụ có thể tham gia vào nhiều thực thi ca sử dụng

· Một gói dịch vụ phụ thuộc rất ít vào các gói dịch vụ khác

· Một gói dịch vụ thường liên quan đến chỉ một hoặc một vài tác nhân

· Các chức năng mà một gói dịch vụ cung cấp có thể được quản lý như một đơn vị riêng biệt

3.4 Xác định các mối quan hệ phụ thuộc giữa các gói phân tích

Mục tiêu ở đây là tìm ra các gói phân tích tương đối độc lập với các gói khác, tự chúng được ghép nối lỏng lẻo với nhau nhưng có kết quả kết dính cao bên trọng Với mục tiêu trên ta cố gắng giảm số lượng các mối quan hệ giữa các lớp thuộc tính các gói khác nhau Cách tốt nhất để thực hiện công việc này là tổ chức mô hình phân tích thành các tầng bằng cách ghép các gói ứng dụng cụ thể ở một tầng đỉnh và các gói tổng quát hơn ở một tầng thấp hơn

3.5 Xác định các lớp thực thể hiển nhiên

Ta có thể xác định các lớp thực thể quan trọng nhất dựa trên các lớp miền hoặc các thực thể nghiệp vụ đã được xác định trong quá trình nắm bắt các yêu cầu Ở bước này không nên xác định quá nhiều lớp và đi quá sâu vào chi tiết Một phác thảo ban đầu bao gồm các lớp có ý nghĩa về mặt kiến trúc là đủ

3.6 Xác định các yêu cầu đặc biệt chung

Một yêu cầu đặc biệt là một yêu cầu nảy sinh ra trong quá trình phân tích và việc nắm bắt nó là quan trọng Các yêu cầu kiểu này có thể là:

· Tính lâu bền

· Sự phân bố và tính tương tranh

· Các điểm đặc trưng về an toàn

· Dung sai về lỗi

Trang 36

Một thực thi ca sử dụng phân tích là một sự cộng tác trong mô hình phân tích mô tả làm thế nào một ca sử dụng cụ thể được thực hiện và thể hiện dưới dạng các lớp phân tích và các đối tượng phân tích tương tác với nhau

Để xác định các lớp phân tích, ta làm mịn ca sử dụng dựa trên luồng các sự kiện mô

tả bằng văn bản – mô tả phân tích của thực thi ca sử dụng

Ta có thể xác định các lớp phân tích theo cách sau:

· Xác định các thực thể bằng việc nghiên cứu mô tả ca sử dụng và bất

kỳ mô hình miền chi tiết nào đang có, sau đó xét xem thông tin nào cần được đưa vào và cần thao tác trong thực thi ca sử dụng

· Xác định một lớp biên trung tâm đối với mỗi tác nhân là người vàchọn lớp này làm cửa sổ co bản trong giao diện người sử dụng mà tác nhân tương tác với nó Nếu tác nhân đã tương tác với một lớp biên nào đó, thì có thể dùng lại lớp này

· Xác định một lớp biên nguyên thủy cho mỗi thực thể đã được tìm ra lúc trước Các lớp này đại diện cho các đối tượng logic tương tác với tác nhân trong giao diện người dùng trong suốt một ca sử dụng

Trang 37

· Xác định một lớp biên trung tâm cho mõi tác nhân hệ thống ngoài, và chọn nó làm đại diện cho giao diện truyền thông

· Xác định một lớp điều khiển chịu trách nhiệm quản lý việc điều khiển

và phối hợp thực thi ca sử dụng, sau đó làm mịnh lớp điều khiển này theo các yêu cầu của ca sử dụng

Tập hợp các lớp phân tích tham gia một thực thi ca sử dụng vào một biểu đồ lớp và

sử dụng biểu đồ lớp nàu để chỉ ra các mối quan hệ được dùng trong việc thực thi ca

sử dụng

Lớp phân tích

Một lớp phân tích thể hiện cho một sự trừu tượng của một hoặc nhiều lớp và/hoặc

hệ thống con trong thiết kế hệ thống Có ba kiểu lớp cơ bản sau: lớp biên, lớp điều khiển, và lớp thực thể

Lớp biên

Một lớp biên thường được sử dụng để mô hình hóa tương tác giữa hệ thống

và các tác nhân của nó Tương tác này bao gồm có việc nhận và hiển thị thông tin từ các yêu cầu của người dùng và của các hệ thống ngoài Mỗi lớp biên liên quan đến

ít nhất một tác nhân và ngược lại

Các lớp biên thường thể hiện như các trừu tượng hóa của các cửa sổ(window), các biểu mẫu(form), các bảng hiển thị(pane), các giao diện truyền thông(communication interface), giao diện máy in(printer interface), các bộ cảm biến(sensor), các đầu cuối(terminal)…, nhưng ở một mức độ tương đối cao và mang tính khái niệm chứ không đi quá sau vào chi tiết giao diện người dùng

Lớp thực thể

Một lớp thực thể được dùng để mô hình hóa các thông tin tồn tại lâu dài và

có thể được lưu trữ Các lớp thực thể thường thể hiện các cấu trúc dữ liệu logic và góp phần làm rõ về các thông tin nào mà hệ thống phải dựa vào

Lớp điều khiển

Các lớp điều khiển thể hiện sự phối hợp, sắp trình tự, các giao dịch, sự điều khiển của các đối tượng và thường được sử dụng để bao gói các điều khiển liên

Trang 38

quan đến một ca sử dụng cụ thể Các khía cạnh động của hệ thống được mô hình hóa qua các lớp điều khiển

4.2 Mô tả các tương tác giữa các đối tượng phân tích

Khi đã có một phác thảo về các lớp phân tích cần thiết để thực thi các ca sử dụng chúng ta cần phải mô tả cách thức mà các đối tượng phân tích tương tác với nhau như thế nào Việc này được tiến hành bằng cách sử dụng các biểu đồ cộng tác, chúng chứa các thể hiện của tác nhân tham gia, các đối tượng phân tích, và các mối liên kết giữa chúng Nếu ca sử dụng có các luồng hoặc luồng con khác nhau và tách biệt thì nên tạo một biểu đồ cộng tác riêng cho mỗi luồng

Một biểu đồ cộng tác xuất phát từ một điểm khởi đầu của luồng sự kiện ca sử dụng sau đó di theo luồng từng bước và xác định xem đối tượng phân tích nào và các tương tác của các thể hiện tác nhân nào là cần thiết để thực thi ca sử dụng đó Trong một biểu đồ cộng tác có các lưu ý sau:

· Một ca sử dụng được gọi bằng một thông báo từ một tác nhân chuyểntới một đối tượng biên

· Mỗi lớp phân tích được xác định trong bước trước phải có ít nhất một đối tượng phân tích tham gia trong một biểu đồ cộng tác

· Các thông báo không được phép gán cho các tác vụ vì chúng ta khôngđặc tả các tác vụ cho các lớp phân tích Các kết nối trong biểu đồ là các thể hiện của các liên kết giữa các lớp phân tích

· Không tập trung chính vào sự tuần tự trong biểu đồ mà nên tập trung vào các quan hệ(liên kết) giữa các đối tượng và các yêu cầu(như nắm bắt trên các thông báo) về các đối tượng cụ thể

· Biểu đồ cộng tác phải quản lý được mọi mối quan hệ của ca sử dụng được thực thi

Trong một số trường hợp, có thể bổ sung các mô tả bằng văn bản cho các biểu đồ cộng tác, đặc biệt nếu có nhiều biểu đồ thực thi cùng một ca sử dụng hoặc nếu có các biểu đồ trình bày các luồng phức tạp

4.3 Nắm bắt các yêu cầu đặc biệt

Trang 39

Ta cần nắm bắt các yêu cầu(phi chức năng) cần cho việc thực thi một ca sử dụng mà đã được xác định trong phân tích nhưng phải được xử lý trong thiết kế và thực thi

5 Phân tích một lớp

Mục đích của việc phân tích một lớp là:

Xác định và duy trì các trách nhiệm của một lớp phân tích dựa trên vai trò của nó trong các thực thi ca sử dụng

Xác định và duy trì các thuộc tính và các mối quan hệ của lớp phân tíchNắm bắt các yêu cầu đặc biệt về việc thực thi của lớp phân tích

5.1 Xác định các trách nhiệm

Các trách nhiệm của một lớp có thể được xác định bằng cách tổ hợp mọi vai trò mà lớp đó đảm nhận trong các thực thi ca sử dụng khác nhau Ta có thể tìm thấy mọi thực thi ca sử dụng mà lớp đó có tham gia, rút ra các trách nhiệm từ một vai trò mỗi lần nó đóng, thêm các trách nhiệm bổ sung hoặc thay đổi các trách nhiệm đang

có dựa trên mỗi lần thực thi một ca sử dụng

5.2 Xác định các thuộc tính

Một thuộc tính đặc tả một tính chất của một lớp phân tích và nó thường được gợi ý và đòi hỏi bởi các trách nhiệm của lớp của nó Các hướng dẫn khi xác định các thuộc tính

· Tên của thuộc tính phải là một danh từ

· Các kiểu của thuộc tính chỉ mang tính khai niệm trong phân tích, chúng không bị hạn chế bởi môi trường thực thi Khi chọn một kiểu thuộc tính, nên dùng một kiểu đã có sẵn

· Nếu một thể hiện thuộc tính đơn độc không thể chia sẻ cho nhiều đối tượng phân tích thì bắt buộc xác định thuộc tính đó là một lớp riêng

· Nếu một lớp phân tích trở nên quá phức tạp vì các thuộc tính của nó thì có thể tách ra thành các lớp riêng

· Các thuộc tính của các lớp thực thể thường là tương đối rõ ràng

· Các thuộc tính của các lớp biên tương tác với các tác nhân bên ngoài đại diện các hạng mục thông tin mà các tác nhân thao tác

Trang 40

· Các thuộc tính của các lớp biên tương tác với các tác nhân hệ thống ngoài của hệ thống thường đại diện các tính chất của một giao diện truyền thông

· Các lớp điều khiển có ít thuộc tính vì tuổi thọ của chúng ngắn Tuy nhiên, các lớp điều khiển có thể có các thuộc tính đại diện các giá trị được tích lũy hoặc được dẫn xuất trong quá trình thực thi một ca sử dụng

5.3 Xác định các liên kết và các kết hợp

Số lượng các mối quan hệ giữa các lớp phải được tối thiểu hóa Trước hết chúng không phải là các mối quan hệ ở thế giới thực mà là các mối quan hệ cần phải tồn tại để đáp ứng lại các đòi hỏi từ các thực thi ca sử dụng khác nhau

Các kết hợp phải được dùng khi các đối tượng đại diện cho:

· Các khái niệm mà về mặt vật lý là chứa đựng lẫn nhau, chẳng hạn oto chưa người lái và khách hàng trong đó

· Các khái niệm được tổng hợp từ nhau, chẳng hạn một ô tô gồm có động cơ và các bánh xe

· Các khái niệm mà chúng hình thành sau một sưu tập có tính khái niệm

về các đối tượng, như nhân sự bao gồm giám đốc, các trưởng bộ phận, nhân viên …

5.4 Xác định các tổng quát hóa

Các tổng quát hóa được dùng trong quá trình phân tích để biểu diễn hành vi chia sẻ và hành vi chung của các lớp phân tích khác nhau Các tổng quát hóa phải được giữ ở một mức cao và có tính khái niệm, chúng làm cho mô hình phân tích dễ hiểu hơn

5.5 Nắm bắt các yêu cầu đặc biệt

Khi nắm bắt các yêu cầu này, hãy tham khảo bất kỳ các yêu cầu đặc biệt chung nào đã được nhà kiến trúc xác định, nếu có thể

6 Phân tích một gói

Mục đích của việc phân tích một gói nhằm:

Ngày đăng: 25/04/2014, 21:48

HÌNH ẢNH LIÊN QUAN

Hình 1: Biểu đồ hoạt động nghiệp vụ quản lý thông tin Tuyển dụng Nhân viên - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 1 Biểu đồ hoạt động nghiệp vụ quản lý thông tin Tuyển dụng Nhân viên (Trang 57)
Bảng      hệ - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
ng hệ (Trang 62)
Bảng  hệ  số - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
ng hệ số (Trang 63)
Hình 7: Mô hình ca sử dụng mức gộp quản lý Tuyển dụng nhân viên - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 7 Mô hình ca sử dụng mức gộp quản lý Tuyển dụng nhân viên (Trang 73)
Hình 8: Mô hình ca sử dụng mức gộp quản lý Hợp đồng lao động - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 8 Mô hình ca sử dụng mức gộp quản lý Hợp đồng lao động (Trang 74)
Hình 10: Mô hình ca sử dụng mức gộp quản lý Quá trình đào tạo - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 10 Mô hình ca sử dụng mức gộp quản lý Quá trình đào tạo (Trang 75)
Hình 11: Mô hình ca sử dụng mức gộp quản lý Lương - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 11 Mô hình ca sử dụng mức gộp quản lý Lương (Trang 76)
Hình 12: Mô hình ca sử dụng mức gộp quản lý Công việc - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 12 Mô hình ca sử dụng mức gộp quản lý Công việc (Trang 77)
Bảng công việc - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng c ông việc (Trang 77)
Bảng công việc - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng c ông việc (Trang 78)
Bảng công việc - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng c ông việc (Trang 78)
Bảng công việc - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng c ông việc (Trang 79)
Hình 13: Mô tả chi tiết ca sử dụng cập nhật Hợp đồng lao động - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 13 Mô tả chi tiết ca sử dụng cập nhật Hợp đồng lao động (Trang 79)
Bảng hợp đồng lao động - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng h ợp đồng lao động (Trang 81)
Bảng  hợp  đồng  lao  động - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
ng hợp đồng lao động (Trang 82)
Bảng  hợp  đồng  lao  động - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
ng hợp đồng lao động (Trang 82)
Sơ đồ liên kết: - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Sơ đồ li ên kết: (Trang 83)
Sơ đồ liên kết: - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Sơ đồ li ên kết: (Trang 85)
Hình 17: Biểu đồ tuần tự ca sử dụng cập nhật Hợp đồng lao động - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 17 Biểu đồ tuần tự ca sử dụng cập nhật Hợp đồng lao động (Trang 86)
Hình 18: Biểu đồ lớp quản lý thông tin tuyển dụng nhân viên - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 18 Biểu đồ lớp quản lý thông tin tuyển dụng nhân viên (Trang 87)
Hình 19Biểu đồ lớp quản lý thông tin Hợp đồng lao động - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 19 Biểu đồ lớp quản lý thông tin Hợp đồng lao động (Trang 88)
Hình 20: Biểu đồ lớp quản lý Quá trình công tác - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 20 Biểu đồ lớp quản lý Quá trình công tác (Trang 89)
Hình 21: Biểu đồ lớp quản lý Quá trình khen thưởng – kỷ luật - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 21 Biểu đồ lớp quản lý Quá trình khen thưởng – kỷ luật (Trang 90)
Hình 22: Biểu đồ lớp quản lý Quá trình đào tạo - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 22 Biểu đồ lớp quản lý Quá trình đào tạo (Trang 91)
Hình 23: Biểu đồ lớp quản lý Lương - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Hình 23 Biểu đồ lớp quản lý Lương (Trang 92)
Bảng 21: Thông  tin nhân  viên - NS_Nhanvien - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng 21 Thông tin nhân viên - NS_Nhanvien (Trang 100)
Bảng 26: Thông  tin sức khỏe nhân  viên - NS_SucKhoe - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng 26 Thông tin sức khỏe nhân viên - NS_SucKhoe (Trang 103)
Bảng 33: Bảo hiểm xã hội nhân  viên - NS_BHXH - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng 33 Bảo hiểm xã hội nhân viên - NS_BHXH (Trang 106)
Bảng 39: Tạm  ứng  - NS_TamUng - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
Bảng 39 Tạm ứng - NS_TamUng (Trang 109)
Bảng  54: Khóa  học - NS_KhoaHoc - Xây dựng hệ thống thông tin Quản lý Nhân sự và Tiền lương trong hệ thống ERP
ng 54: Khóa học - NS_KhoaHoc (Trang 114)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w