Nghiên cứu các mẫu thiết kế và ứng dụng để xây dựng hệ thống quản lý thông tin tổng thể cho doanh nghiệp

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

BẢNG CHỮ VIẾT TẮT 5

DANH MỤC CÁC HÌNH VẼ VÀ ðỒ THỊ 6

MỞ ðẦU 9

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

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

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

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

CHƯƠNG 1 13

TỔNG QUAN VỀ MÔ HÌNH SỬ DỤNG LẠI 13

1.1 Giới thiệu chung 13

1.2 Tổng quan về các mẫu thiết kế 13

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

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

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

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

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

1.3 Một số mẫu thiết kế ñiển hình trong các ứng dụng quản lý .17

1.3.1 Mẫu Quan sát 18

1.3.2 Mẫu Thực hiện lệnh 20

1.3.3 Mẫu Trạng thái 22

1.3.4 Mẫu Phương thức tiêu bản 23

1.3.5 Mẫu Chuỗi các trách nhiệm 24

1.3.6 Mẫu Chiến lược 26

1.3.7 Mẫu Kịch bản thao tác 28

1.3.8 Mẫu Mô hình lĩnh vực 29

1.3.9 Mẫu Cổng dữ liệu của bảng 31

1.3.10 Mẫu ðối tượng chuyển ñổi dữ liệu 33

TỔNG QUAN VỀ HỆ THỐNG HOẠCH ðỊNH NGUỒN LỰC DOANH NGHIỆP -

ERP 36

2.1 Lịch sử hình thành 36

2.2 ERM- Sự tích hợp ERP và Nghiệp vụ sản xuất kinh doanh 40

2.3 Lợi ích của danh nghiệp khi sử dụng ERP 43

2.3.1 Tiếp cận thông tin quản trị ñáng tin cậy 43

2.3.2 Công tác kế toán chính xác hơn 43

2.3.3 Cải tiến quản lý hàng tồn kho 43

2.3.4 Tăng hiệu quả sản xuất 43

2.3.5 Quản lý nhân sự hiệu quả hơn 44

2.3.6 Các qui trình kinh doanh ñược xác ñịnh rõ ràng hơn 44

CHƯƠNG 3 45

ỨNG DỤNG CÁC MẪU THIẾT KẾ ðỂ XÂY DỰNG CÁC PHÂN HỆ TRONG HỆ THỐNG QUẢN LÝ DOANH NGHIỆP 45

3.1 Phân hệ chính: Các lớp cơ sở, quản lý bảo mật, báo cáo .45

3.1.1 Bài toán ñặt ra 45

3.1.2 Phạm vi bài toán 46

3.1.3 Phân tích yêu cầu bài toán và xác ñịnh giải pháp 46

3.1.4 Thiết kế Phân hệ chính 47

3.1.4.1 Thiết kế các lớp xử lý, truy cập CSDL 48

3.1.4.2 Chức năng Quản lý bảo mật ứng dụng 53

3.1.4.3 Chức năng Quản lý cấu trúc các bảng dữ liệu 69

3.2 Phân hệ Quản lý mua bán vật tư – nguyên liệu 74

3.2.1 Bài toán ñặt ra 74

3.2.2 Phạm vi bài toán 75

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

3.2.3.1 Xác ñịnh các thông tin chung về quản lý mua bán vật tư, nguyên liệu 75

3.2.3.2 Công tác quản lý hoạt ñộng mua bán vật tư - nguyên liệu 78

3.2.3.3 Sơ ñồ tiến trình quản lý hoạt ñộng mua bán vật tư 79

3.2.3.4 Các yêu cầu của phân hệ quản lý mua bán vật tư-nguyên liệu80 3.2.3.5 Các chức năng của Phân hệ quản lý mua bán vật tư-nguyên liệu 80

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

3.2.4 ðặc tả hệ thống 83

3.2.4.1 Các tác nhân của hệ thống 83

3.2.4.2 Các ca sử dụng tiêu biểu của hệ thống 85

3.2.4.3 Mô hình ca sử dụng tổng thể 88

3.2.4.4 Mô tả chi tiết các ca sử dụng 89

3.2.5 Phân tích hệ thống 95

3.2.5.1 Phân tích các ca sử dụng 95

3.2.5.1 Phân tích các lớp 101

3.2.6 Thiết kế hệ thống 105

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

3.2.6.2 Xác ñịnh các gói thiết kế 106

3.2.6.3 Thiết kế cho từng ca sử dụng 106

CHƯƠNG 4 109

CÀI ðẶT VÀ TRIỂN KHAI HỆ THỐNG 109

4.1 Các yêu cầu cài ñặt triển khai hệ thống 109

4.2 Giới thiệu chương trình 110

4.2.1 Các mục tiêu mà hệ thống ñạt ñược 110

4.2.2 Cấu trúc chương trình 110

4.2.3 Các ñối tượng sử dụng chương trình 111

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

4.3 Khả năng triển khai áp dụng 114

KẾT LUẬN 115

1 Các kết quả ñạt ñược 115

TÀI LIỆU THAM KHẢO 117

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

Tài liệu tiếng Anh 117

Các trang Web 118

Bộ công cụ 118

Chữ viết tắt Tên ñầy ñủ

APICS American Production and Inventory Control Society BOM Bill of Materials

CSDL Cơ Sở Dữ Liệu

ERP Enterprise Resource Planning

ERM Enterprise Resource Management

GOF Gang Of Four

GUI Graphic User Interface

MRP Material Requirements Planning

MRP II Manufacturing Resource Planning

NCC Nhà cung cấp

SQL Strured-Query Languague

VT-NL Vật tư- Nguyên liệu

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

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

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

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

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

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

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

Hình 1.8.1: Cấu trúc mẫu Chain of Responsibility 25

Hình 1.8.2: Cấu trúc mẫu Chain of Responsibility 25

Hình 1.9: Cấu trúc mẫu Strategy 26

Hình 1.10: Cấu trúc mẫu Transaction Script 28

Hình 1.11: Cấu trúc mẫu Transaction Script kết hợp với mẫu Command 29

Hình 1.12: Cấu trúc mẫu Domain Model sử dụng mẫu Strategy 30

Hình 1.13: Cấu trúc mẫu Table Data Gateway 32

Hình 1.14: Cấu trúc mẫu Data Transfer Object 34

Hình 2.1 Lịch sử phát triển của ERP 37

Hình 2.2 ERM – Sự tích hợp ERP và nghiệp vụ 41

Hình 2.3 ðịnh nghĩa mô hình ERM .42

Hình 3.1 Kiến trúc hệ thống dựa trên mẫu MVC .47

Hình 3.2 Kiến trúc các lớp giao tiếp CSDL sử dụng mẫu thiết kế 48

Hình 3.3 Sử dụng Table Definition ñể giảm thiểu thay ñổi .50

Hình 3.4 Cấu trúc các phân lớp quản lý các gói của mỗi Phân hệ trong hệ thống 51

Hình 3.5 Lược ñồ lớp xử lý dữ liệu của ñối tượng Nhân viên .53

Hình 3.6 Quá trình ñăng nhập hệ thống .54

Hình 3.7 Mô hình tổng thể các ca sử dụng liên quan ñến bảo mật .54

Hình 3.8 Các lớp thực thi ca sử dụng ðăng nhập 59

Hình 3.9 Biểu ñồ cộng tác ca sử dụng ðăng nhập .60

Hình 3.10 Các lớp thực thi ca sử dụng ðổi mật khẩu .60

Hình 3.11 Biểu ñồ cộng tác ca sử dụng ðổi mật khẩu .61

Hình 3.12 Các lớp trong ca sử dụng Cập nhật nhóm quyền 61

Hình 3.13 Biểu ñồ cộng tác ca sử dụng Cập nhật nhóm quyền .62

Hình 3.14 Các lớp trong ca sử dụng Phân quyền .62

Hình 3.15 Biểu ñồ cộng tác ca sử dụng Phân quyền .63

Hình 3.16 Lớp thiết kế ca sử dụng ðăng nhập chưa áp dụng mẫu 65

Hình 3.17 Các lớp thiết kế trong ca sử dụng ðăng nhập áp dụng các mẫu thiết kế .66

Hình 3.18 Các lớp thiết kế ca sử dụng ðổi mật khẩu chưa áp dụng mẫu 67

Hình 3.19 Các lớp thiết kế trong ca sử dụng ðổi mật khẩu áp dụng các mẫu thiết kế 67

Hình 3.20 Kiến trúc các lớp bảo mật ứng dụng 68

Hình 3.21 Mô hình ca sử dụng phần Quản lý cấu trúc bảng .70

Hình 3.22 Các lớp của ca sử dụng Cập Nhật Nhóm Bảng 70

Hình 3.23 Biểu ñồ cộng tác ca sử dụng Cập Nhật Nhóm Bảng 71

Hình 3.24 Các lớp của ca sử dụng Cập Nhật Bảng 71

Hình 3.25 Biểu ñồ cộng tác ca sử dụng Cập Nhật Bảng 72

Hình 3.26 Các lớp thiết kế trong ca sử dụng Cập nhật nhóm bảng 72

Hình 3.27 Các lớp thiết kế trong ca sử dụng cập nhật nhóm bảng áp dụng mẫu 73

Hình 3.28 Các lớp thiết kế trong ca sử dụng Cập nhật bảng 73

Hình 3.29 Các lớp thiết kế trong ca sử dụng Cập nhật bảng áp dụng mẫu 73

Hình 3.30 Kiến trúc lớp của phần Quản lý cấu trúc bảng 74

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

Hình 3.32: Sơ ñồ tiến trình quản lý mua bán VT-NL 79

Hình 3.33: Mô hình khái niệm của chức năng Quản lý mua bán VT-NL 83

Hình 3.34: Mô hình ca sử dụng tổng thể của Phân hệ Quản lý mua bán VT-NL 88

Hình 3.35: Các lớp thực thi ca sử dụng Lập phiếu yêu cầu mua 95

Hình 3.36: Biểu ñồ cộng tác các lớp ca sử dụng Lập phiếu yêu cầu mua 96

Hình 3.37: Các lớp thực thi ca sử dụng Lập yêu cầu báo giá 96

Hình 3.38: Biểu ñồ cộng tác các lớp ca sử dụng Lập yêu cầu báo giá 97

Hình 3.39: Các lớp thực thi ca sử dụng Lập yêu cầu ñặt hàng 97

Hình 3.40: Biểu ñồ cộng tác các lớp ca sử dụng Lập yêu cầu ñặt hàng 98

Hình 3.41: Các lớp phân tích thực thi ca sử dụng Lập phiếu Nhận hàng 98

Hình 3.42: Biểu ñồ cộng tác các lớp ca sử dụng Lập phiếu nhận hàng 99

Hình 3.43: Các lớp phân tích thực thi ca sử dụng Lập phiếu yêu cầu thanh toán 100

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

Hình 3.46: Các lớp thiết kế ca sử dụng Lập yêu cầu mua hàng .106

Hình 3.47: Các lớp thiết kế ca sử dụng Lập yêu cầu mua hàng sử dụng mẫu .107

Hình 3.48: Các lớp thiết kế ca sử dụng Lập yêu cầu báo giá .107

Hình 3.49: Các lớp thiết kế ca sử dụng Lập yêu cầu báo giá .108

Hình 3.50: Lớp thiết kế yêu cầu mua hàng áp dụng mẫu State 108

Hình 4.1: Giao diện chính của chương trình .112

Hình 4.2: Giao diện quản lý thực ñơn .112

Hình 4.3: Giao diện quản lý Báo cáo .113

Hình 4.4: Giao diện quản lý Khách hàng .114

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

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

Hệ thống Quản lý tổng thể doanh nghiệp:

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 một cách tập trung ñể có thể tra cứu tìm kiếm dễ dàng và nhanh chóng mỗi khi có nhu cầu

Hiện nay hầu hết các doanh nghiệp ñã ứng dụng CNTT trong việc quản lý ñiều hành doanh nghiệp của mình Tuy nhiên, qua khảo sát thực tế cho thấy, hầu hết các hệ thống phần mềm của các doanh nghiệp ñang hoạt ñộng khá ñộc lập, hầu như không liên kết ñược với nhau hoặc nếu có thì liên kế với nhau một cách rất hạn chế Chính vì việc liên kết các hệ thống phần mềm khác nhau trong một doanh nghiệp thành một hệ thống tập trung, quản lý tổng thể và chia sẻ thông tin trong doanh nghiệp một cách ñồng nhất, trong suốt là một nhu cầu hết sức cấp thiết

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 “Nghiên cứu các mẫu thiết

kế và ứng dụng ñể xây dựng Hệ thống Quản lý thông tin tổng thể doanh nghiệp” Mục tiêu của bài toán “Xây dựng Hệ thống Quản lý thông tin tổng thể cho doanh nghiệp” là xây dựng một hệ thống quản lý thông tin bao gồm nhiều Phân hệ Mỗi một Phân hệ giải quyết ñược chọn vẹn một hay một số yêu cầu của bài toán nghiệp vụ-quản lý thông tin của doanh nghiệp

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ệ ứng dụng

chủ-khách (COM+) ñể cập nhật và xử lý thông tin ðồng thời hệ thống cũng ñược thiết

kế ñể có thể chạy ñược cả trên nền Web lẫn desktop application

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ệ NET của Microsoft ñể 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,

và một số mẫu tiêu biểu ứng dụng trong các hệ thống quản lý doanh nghiệp

– 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ế ñể phân tích, thiết kế hệ thống quản lý thông tin tổng thể cho các doanh nghiệp

– 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

– Nghiên cứu một số mẫu ñiển hình về hành vi và trình diễn cũng như các mẫu ñiển hình của các ứng dụng doanh nghiệp

– Tổng quan về hệ thống hoạch ñịnh nguồn lực doanh nghiệp ERP

– Vận dụng mẫu thiết kế cũng như lý thuyết về ERP ñể tiến hành phân tích và thiết kế Hệ thống quản lý thông tin tổng thể cho doanh nghiệp

– 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 hay ñược dùng trong các ứng dụng doanh nghiệp

CHƯƠNG 2: Tổng quan về Hệ thống Hoạch ñịnh nguồn lực doanh nghiệp ERP Chương này giới thiệu tổng quan về hệ thống ERP, lịch sử hình thành cũng như

xu hướng phát triển, tiến hóa của ERP Qua ñó ñưa ra ñược những khái niệm cũng như cái nhìn tổng thể về hệ thống quản lý thông tin tổng thể của doanh nghiệp, phục vụ cho việc phân tích, thiết kế hệ thống quản lý thông tin tổng thể ở chương 3

CHƯƠNG 3: Ứng dụng các mẫu thiết kế ñể xây dựng các Phân hệ của hệ thống Quản lý thông tin tổng thể doanh nghiệp

Chương này mô tả việc cận dụng các mẫu thiết kế ñể phân tích, thiết kế và xây dựng một số Phân hệ trong hệ thống Quản lý thông tin tổng thể cho doanh nghiệp CHƯƠNG 4: Cài ñặt

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

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 - GOF) ñã 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ế

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ế (Design Pattern) 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 [3]

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

Mẫu hành vi bao gồm các mẫu sau: Chain of Responsibility, Command, Interpreter,

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 Một số mẫu thiết kế ñiển hình trong các ứng dụng quản lý

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ế ñiển hình về hành vi và trình diễn hay ñược dùng trong các ứng dụng quản lý doanh nghiệp như là các mẫu thiết kế dành cho lý luận nghiệp vụ (domain logic) hoặc các mẫu về hành vi quan hệ của các ñối tượng hoặc cấu trúc quan hệ của

1.3.1 Mẫu Quan sát

1.3.1.1 Ý nghĩa

Mẫu quan sát (Observer) ñị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 Observer 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)

1.3.1.4 Biểu ñồ cộng tác

ðối tượng ConcreteSubject sẽ gửi thông báo tới các ñối tượng Observer của nó bất

cứ khi nào có sự thay ñổi trạng thái của các ñối tượng Observer

Sau khi xác nhận sự thay ñổi trong ñối tượng ConcreteSubject, ñối tượng ConcreteObserver có thể truy vấn thông tin của các ñối tượng Observer ðối tượng ConcreteObserver sử dụng thông tin này ñể ñồng bộ trạng thái của nó với các ñối tượng Observer ñó

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

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

Mẫu Observer thường ñược áp dụng khi: Ứng dụng có mối quan hệ phụ thuộc, ñối tượng này phụ thuộc vào ñối tượng kia Hoặc khi một sự thay ñổi ở ñối tượng này dẫn ñến sự thay ñổi ở ñối tượng khác và chúng ta không biết chính xác có bao nhiêu ñối tượng phải thay ñổi theo

Chúng ta có thể thêm vào một hoặc nhiều ñối tượng phụ thuộc trạng thái (Observer) mà không phải sửa ñổi lại ñối tượng chủ thể Subject hoặc các ñối tượng Observer phụ thuộc trạng thái khác

1.3.2 Mẫu Thực hiện lệnh

1.3.2.1 Ý nghĩa

Mẫu Thực hiện lệnh (Command) 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 tệp tin sổ ghi (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.3 Mẫu Trạng thái

1.3.3.2 Ý nghĩa

Mẫu Trạng thái (State) cho phép ñối tượng có thể tự ñiều chỉnh hành vi khi trạng

thái của nó thay ñổi (hành vi của ñối tượng phụ thuộc vào trạng thái của nó)

1.3.3.2 Mô tả

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 Chuỗi các trách nhiệm

1.3.5.1 Ý nghĩa

Mẫu Chuỗi các trách nhiệm 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

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

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

Hình 1.8.2: 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

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ù hợp

1.3.6 Mẫu Chiến lược

1.3.6.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 Chiến lược (Strategy) 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.6.2 Cấu trúc mẫu

Hình 1.9: 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.6.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.6.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.7 Mẫu Kịch bản thao tác

1.3.7.1 Ý nghĩa

Mẫu Kịch bản thao tác (Transaction Script) nhóm toàn bộ các logic nghiệp vụ chính lại thành các thủ tục (procedure), các thủ tục này sẽ kiểm soát một yêu cầu riêng

từ phía client hay từ các lớp trên tầng trình diễn

Hình 1.10: Cấu trúc mẫu Transaction Script Phần lớn các ứng dụng nghiệp vụ có thể ñược hiểu là một chuỗi các thao tác Một thao tác có thể là việc tổ chức thông tin theo một cách thức nào ñó trong khi các thao tác khác thì thay ñổi thông tin ñó Mỗi tương tác giữa một hệ thống khách (client) và

hệ thống chủ (server) hàm chứa một số logic nào ñó Trong một số trường hợp, có thể

ñó là hiển thị thông tin từ CSDL, trong các trường hợp khác có thể là các bước tính toán hoặc thẩm ñịnh số liệu

Một Transaction Script tổ chức toàn bộ các logic này thành một thủ tục ñơn lẻ, thực hiện lời gọi trực tiếp ñến CSDL hoặc thông qua một wrapper của CSDL Mỗi thao tác ñều có Transaction Script của nó, mặc dù các tác vụ nhỏ chung cũng có thể ñược chia ra thành các thủ tục con

1.3.7.1 Mô tả

Trong một Transaction Script, logic nghiệp vụ chủ yếu ñược tổ chức theo các thao tác mà ta có thể thực hiện ñược với hệ thống Giả sử yêu cầu của chúng ta là ñặt phòng khách sạn, khi ñó các nghiệp cụ như kiểm tra phòng trống, tính giá và cập nhật vào CSDL sẽ ñược thấy trong thủ tục là ‘ðặt Phòng Khách Sạn’

Không cần phải giải thích quá nhiều ñối với các trường hợp ñơn giản Tất nhiên chúng ta sẽ phải tổ chức mã lệnh vào các phân hệ sao cho có ý nghĩa Một trong những lợi ích của cách tiếp cận này là chúng ta không phải bận tâm nhiều ñến các thao tác khác ñang thực hiện ra sao Công việc của chúng ta là thông tin ñầu vào, truy suất CSDL, xử lý rồi lưu kết quả vào CSDL

Cách chung nhất ñể tổ chức các Transaction Script là ta sẽ gộp một vài Transaction Script vào một lớp ñơn, mỗi lớp sẽ ñịnh nghĩa một vùng chủ ñề của Transaction Script

liên quan ðây là là cách trực tiếp là là phù hợp nhất ñối với phần lớn các trường hợp Một cách nữa là các Transaction Script nằm trong chính lớp của nó bằng cách sử dụng mẫu Command (như hình 1.11) Trong trường hợp này ta ñịnh nghĩ một siêu kiểu (supertype) cho các lệnh ñể xác ñịnh một vài phương thức thực thi thuận với Transaction Script

cá thể có ích, nó có thể lớn như là một doanh nghiệp hoặc có thể nhỏ như một danh mục trên mẫu ñơn ñặt hàng

1.3.8.3 Mô tả

Khi ñưa mẫu Domain Model vào một ứng dụng dẫn ñến việc phải ñưa cả một lớp các ñối tượng vào ñể mô hình hóa nghiệp vụ mà chúng ta ñang làm Chúng ta sẽ phải tìm ra các ñối tượng mà chúng bắt chước dữ liệu nghiệp vụ và các ñối tượng mô tả các quy tắc nghiệp vụ ñược sử dụng Phần lớn các dữ liệu và quy trình ñược kết hợp lại trong một cluster mà quy trình liên quan mật thiết với dữ liệu mà chúng cần ñể làm việc Domain Model trộn dữ liệu với quy trình, có nhiều các thuộc tính ña trị và một mạng phức tạp các liên kết và sử dụng tính kế thừa

Hình 1.12: Cấu trúc mẫu Domain Model sử dụng mẫu Strategy

Vì các hành vi của nghiệp vụ là thay ñổi thường xuyên, vì vậy việc yếu tố quan trọng là làm sao ñể các ñối tượng trong tầng nghiệp vụ này có khả năng chỉnh sửa, tạo lập và kiểm thử một các dễ dàng Thông thường ta sẽ hay làm là giảm ñến mức tối ña

sự phụ thuộc của Domain Model vào các tầng khác của ứng dụng hay ñể các mẫu phân tầng khác có ít sự phụ thuộc nhất có thể giữa Domain Model và các phần khác của hệ thống

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

Với một Domain Model, có khá nhiều phạm vi khác nhau mà ta có thể sử dụng Tình huống ñơn giản nhất là ứng dụng ñơn người dùng trong ñó ñồ thị của ñối tượng ñược ñọc vào từ file và ñưa lên bộ nhớ Các ứng dụng cho desktop có thể làm theo cách như thế này Tuy nhiên ñây không phải là trường hợp phổ biến cho các ứng dụng

quản lý thơng tin đa tầng bởi vì nĩ cĩ quá nhiều đối tượng, việc đưa tất cả các đối tượng vào bộ nhớ sẽ tiêu tốn quá nhiều bộ nhớ và mất nhiều thời gian

Một điều cần quan tâm đối với Domain Model là sự phình lên của các đối tượng

Ví dụ khi ta xây dựng một màn hình để xử lý các đơn hàng (Order), chúng ta phải chú

ý rằng một số hành vi đặt hàng chỉ cần cho chính nĩ Nếu ta đưa tất cả các phương thức này vào lớp Order thì khi đĩ lớp Order sẽ trở lên quá lớn bởi vì nĩ chứa nhiều các phương thức mà chúng chỉ được dùng trong một vài tình huống riêng lẻ ðiều này làm chúng ta phải cần xem các phương thức nào là chung, khi đĩ ra sẽ đưa vào lớp Order, hoặc nếu nĩ là chuyên biệt thì ta sẽ tạo ra các lớp để sử dụng với mục đích chuyên biệt

đĩ, khi đĩ ta cĩ thể dùng mẫu Transaction Script

Tuy nhiên việc tách biệt các hành vi cho các mục đích chuyên biệt cĩ thể đưa đến việc trùng lặp các lớp Việc tìm ra các hành vi được tách ra từ lớp Order là khá khĩ khăn, vì thế chúng ta cố gắng để khơng nhìn thấy nĩ thay vì đĩ là trùng lặp nĩ Việc trùng lặp nhanh chĩng dẫn đến việc hệ thống sẽ phức tạp hơn và khơng tồn vẹn Tuy nhiên, ta thấy rằng việc các đối tượng phình lên khơng thường gặp nhiều như dự đốn, nếu gặp thì nĩ thường dễ nhìn thấy và khơng khĩ để chỉnh lại Lời khuyên là: khơng nên tách biệt các hành vi với mục đích sử dụng chuyên biệt, hãy đưa tất cả các hành vi của đối tượng vào trong các lớp một cách tự nhiên để tránh việc phình lên của đối tượng

Nếu ta cĩ một hệ thống mà ở đĩ các quy tắc nghiệp vụ là phức tạp và luơn thay đổi, liên quan nhiều đến các phép tính xác nhận tính hợp lệ, đến tính tốn, đạo hàm, khả năng… thì sẽ cần đến một mơ hình đối tượng để quản lý chúng (tức là dùng đến Domain Model) Ngược lại nếu chỉ cĩ các ứng dụng liên quan đến các phép phép tính đơn giản như kiểm tra giá trị NULL, tính tốn tổng, … thì Transaction Script là một sự lựa chọn tốt hơn

1.3.9 Mẫu Cổng dữ liệu của bảng

1.3.9.1 Ý nghĩa

Mẫu Cổng dữ liệu của bảng (Table Data Gateway) mơ tả một đối tượng hoạt động như một ‘Cổng’ vào một bảng trong CSDL Một thể hiện của nĩ quản lý tất cả các dịng trong bảng

Hình 1.13: Cấu trúc mẫu Table Data Gateway

Việc ñưa lẫn các câu lệnh SQL vào trong logic của ứng dụng có thể gây ra nhiều vấn ñề Rất nhiều nhà phát triển không rành về SQL và rất nhiều người viết ra các câu lệnh SQL không ñược tốt lắm Người quản trị CSDL có thể tìm ra các câu SQL một cách dễ dàng, vì vậy họ có thể chỉ ra làm thế nào ñể ñiều chỉnh và lấy ra dữ liệu từ CSDL

Một Table Data Gateway giữ tất cả các câu SQL dùng ñể truy cập vào một bảng hoặc một view như: truy vấn (SELECT), thêm mới (INSERT), cập nhật (UPDATE) và xóa (DELETE) Các thành phần khác trong hệ thống sẽ gọi ñến các phương thức của lớp này ñể thực hiện toàn bộ các thao tác với CSDL

1.3.9.2 Mô tả

Một Table Data Gateway có một giao diện ñơn giản, thường bao gồm một vài phương thức ñể tìm kiếm dữ liệu cùng với các phương thức ñể thêm/ xửa/ xóa dữ liệu Mỗi phương thức này ánh xạ các tham số truyền vào trong một lời gọi SQL và thực thi câu SQL ñó cùng với kết nối ñến CSDL Table Data Gateway thường không có trạng thái (stateless), vai trò của nó là ñẩy dữ liệu lên và lấy dữ liệu về

ðiều tinh tế nhất về Table Data Gateway là làm thể nào ñến trả về thông tin từ một câu truy vấn Thậm chí một câu truy vấn ñơn giản nhất như là tìm kiếm theo ñịnh danh

có có thể trả về nhiều dòng dữ liệu Trong môi trường lập trình mà ở ñó nó trả về nhiều dòng thì ta có thể áp dụng cho trường hợp trả về một dòng Tuy nhiên thì nhiều ngôn ngữ chỉ trả về cho ta một giá trị ñơn lẻ, nhiều câu truy vấn mới trả về nhiều dòng Một vấn ñề tương tự nữa là trả về một vài cấu trúc dữ liệu ñơn giản, ví dụ như là một ánh xạ Một ánh xạ hoạt ñộng nhưng nó bắt buộc dữ liệu phải ñược sao chép ra khỏi bản ghi lấy từ CSDL vào trong ánh xạ ñó Việc sử dụng ánh xạ ñể chuyển dữ liệu cho các ñối tượng khác là một cách thức không phù hợp vì nó ảnh hướng ñến việc kiểm tra thời gian dịch, và nó cũng không phải là một giao diện rõ ràng, ñiều này sẽ gây ra lỗi như là người dùng sẽ không hiểu những thứ ở trong ánh xạ ñó Một cách

tương tự tốt hơn ñó là dùng Data Transfer Object (hay là Value Object) ðây là ñối tượng dùng ñể tạo và ñược dùng ở những phần khác của ứng dụng

Nếu ta ñang sử dụng một Domain Model thì ta có thể dùng Table Data Gateway ñể trả về các ñối tượng miền tương ứng Có một vấn ñề về cách tiếp cận này thì chúng ta cần phải có các ràng buộc hai chiều giữa các ñối tượng miền và Gateway

ða phần khi sử dụng Table Data Gateway ta sẽ cần mỗi Gateway cho mỗi bảng trong CSDL, tuy nhiên trong các trường hợp ñơn giản ta có thể có một Table Data Gateway riêng lẻ ñể quản lý toàn bộ các phương thức cho tất cả các bảng Cũng có thể cần một Gateway cho nhiều các View hoặc thậm chí nhiều câu truy vấn mà ta không lưu thành các View trong CSDL ðương nhiên các Table Data Gateway dựa trên các View sẽ thường không phải cập nhật dữ liệu và vì thế mà nó sẽ không cần các phương thức cập nhật Tuy nhiên, ta có thể thực hiện việc cập nhật cho các bảng ở trong View sau ñó bao gói việc cập nhật này dưới dạng các phương thức cập nhật trong các Table Data Gateway

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

Table Data Gateway là một mẫu giao diện CSDL ñơn giản nhất hay ñược dùng, nó ánh xạ một cách chuẩn xác vào các bảng trong CSDL hoặc dữ liệu kiểu bản ghi Nó bao gói các logic truy cập ñến nguồn dữ liệu Table Data Gateway ít khi ñược sử dụng với Domain Model bởi vì Data Mapper ñưa ra một sự cách ly tốt hơn giữa Domain Modell

và CSDL

Table Data Gateway rất phù hợp với mẫu Transaction Script Nhiều người thường thích dùng Data Transfer Object, nhưng ñiều ñó tỏ ra không hiệu quả lắm trừ phi ta dùng Data Transfer Object ñó cho nhiều mục ñích khác

Một trong những lợi ích của việc sử dụng Table Data Gateway là bao gói việc truy cập dữ liệu và trong cùng một giao diện mà ở ñó ta có thể sử dụng các câu truy vấn SQL ñể thao tác với CSDL và cả các thủ tục lưu trữ (Stored Procedures), hơn nữa các thủ tục lưu trữ thường ñược tổ chức như là các Table Data Gateway

1.3.10 Mẫu ðối tượng chuyển ñổi dữ liệu

1.3.10.1 Ý nghĩa

ðối tượng chuyển ñổi dữ liệu (Data Transfer Object) là một mẫu dùng ñể chứa dữ liệu giữa các tiến trình nhằm làm giảm số lần gọi các thông ñiệp

Hình 1.14: Cấu trúc mẫu Data Transfer Object Khi ta làm việc với một giao diện từ xa như Remote Façade, mỗi lời gọi như vậy thường tốn nhiều chi phí Do vậy ta sẽ cần phải giảm số lần gọi, hay nói cách khác là chúng ta cần truyền nhiều dữ liệu hơn trong mỗi lần gọi Có một cách ñể làm ñược ñiều ñó là sử dụng nhiều tham số Tuy nhiên ñiều này gây khó khăn cho việc lập trình, hơn nữa việc này là không thể ñối với các ngôn ngữ như là Java khi mà giá trị nó trả

về chỉ là ñơn giá

Giải pháp là tạo ra một Data Transfer Object ñể chứa tất cả dữ liệu cho lần gọi Nó cần ñược chuỗi hóa ñể truyền qua ñược các kết nối Thông thường một bộ thông dịch ñược sử dụng ở phía máy chủ ñể truyền dữ liệu giữa Data Transfer Object và các ñối tượng miền bất kỳ

1.3.10.2 Mô tả

Data Transfer Object thường bao gồm một loạt các trường, cùng với các trình xuất/gán (getter/setter) của chúng Nó cho phép chúng ta chuyển nhiều phần thông tin thông qua mạng bằng chỉ một lời gọi ñơn lẻ, ñây là một thủ thuật cơ bản của các hệ thống phân tán

Khi nào một ñối tượng từ xa cần ñến dữ liệu, nó sẽ gọi ñến một ñối tượng Data Transfer Object thích hợp Data Transfer Object thường sẽ mang nhiều dữ liệu hơn những

gì mà ñối tượng từ xa yêu cầu, toàn bộ các dự liệu này ñược mang vì sẽ có khi ñối tượng từ xa cần dùng ñến nó Vì chi phí cho ñộ trễ của các lời gọi từ xa nên tốt hơn là

có những lỗi ở nơi gửi hơn là phải thực hiện nhiều lời gọi

Một Data Transfer Object thường chứa nhiều hơn thay vì chỉ một ñối tượng riêng

lẻ trên máy chủ Nó cộng gộp dữ liệu từ tất cả các ñối tượng trên máy chủ mà ñối tượng từ xa muốn lấy Ví dự nếu ñối tượng từ xa yêu cầu dữ liệu về ñối tượng ðơn hàng, ñối tượng Data Transfer Object ñược trả về sẽ chứa dữ liệu ñơn hàng, khách hàng, các mục trên ñơn hàng, sản phẩm trên ñơn hàng, thông tin giao hàng, …

1.3.10.3 Chuỗi hóa Data Transfer Object

Các trường dữ liệu trên Data Transfer Object thường rất ñơn giản, ñó có thể là các kiểu nguyên thủy, là các lớp ñơn giản như String, Date hoặc có thể là các ñối lớp Data Transfer Object khác ðể chuyển ñổi ñược các ñối tượng trong Data Transfer Object thông qua mạng, ta cần có các phương pháp ñể chuỗi hóa nó

Không chỉ có các getter, setter, Data Transfer Object còn phải có trách nhiệm rời rạc hóa chính bản thân nó ñể thành các ñịnh dạng có thể truyền ñược qua mạng Chuyển qua ñịnh dạng nào là phụ thuộc vào kết nối và ñộ khó của việc chuỗi hóa Một loại các nền (platform) cung cấp sẵn việc chuỗi hóa cho một số ñối tượng ñơn giản, ví

dụ Java có sẵn chuỗi hóa ở dạng nhị phân, NET có sẵn chuỗi hóa ở dạng nhị phân và XML

Thông thường, nếu Data Transfer Object là ñơn giản thì ta sẽ sử dụng ñược các cơ chế chuỗi hóa có sẵn Trong trường hợp ngược lại, nếu ta không dùng ñược cơ chế chuỗi hóa tự ñộng thì ta sẽ phải tự tạo cơ chế chuỗi hóa cho riêng mình

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

Data Transfer Object ñược sử dụng khi ta cần truyền nhiều ñối tượng giữa hai tiến trình trong một lời gọi hàng riêng lẻ Có một số trường hợp tương tự hay dùng Data Transfer Object, ñó là việc dùng ñể ñơn giản hóa các phương thức Setting có nhiều tham

số hoặc các phương thức Getting chứa các tham số dưới dạng tham biến

TỔNG QUAN VỀ HỆ THỐNG HOẠCH đỊNH NGUỒN LỰC

DOANH NGHIỆP - ERP

2.1 Lịch sử hình thành

ERP là chữ viết tắt của cụm từ Enterprise Resource Planning đó là một hệ thống phần mềm trợ giúp cho các hoạt ựộng sản xuất kinh doanh hoạt ựộng một cách hiệu quả và toàn diện Hầu hết các công ty ựa quốc gia trên thế giới ựều ựã dùng hệ thống ERP đa số các công ty này ựều chưa thể ựạt ựược lợi ắch tối ựa và toàn diện từ hệ thống ERP là do tắnh phức tạp và do chưa có sự hiểu cơ bản về hệ thống ERP Muốn

hệ thống ERP phát huy hết lợi ắch thì hệ thống phải vận hành một cách hài hoà với những hoạt ựộng sản xuất kinh doanh diễn ra hàng ngày

Hệ thống ERP thật sự là một hệ thống mang tắnh cách mạng cao Những người tiên phong trong lĩnh vực này ựã ựặt tên cho hệ thống ERP hiện ựại ngày nay bằng cách ghép các chữ cái ựầu tiên lại với nhau Vài từ viết tắt ựã gây ra sự nhầm lẫn trong nhiều năm qua như MRP, MRP II, ERP,và gần ựây là ERM

Bốn từ viết tắt ựược dùng liên quan ựến hệ thống ERP bao gồm :

- MRP: Material Requirements Planning - Hoạch ựịnh nhu cầu nguyên vật liệu

- MRP II: Manufacturing Resource Planning - Hoạch ựịnh nguồn lực 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

Hình 2.1 Lịch sử phát triển của ERP Vào thập niên 1950, bắt ñầu xuất hiện các khái niệm tập trung vào bốn chức năng căn bản của quá trình quản lý sản xuất bao gồm:

- Số lượng ñặt hàng kinh tế (EOQ)

- Lượng tồn kho an toàn (Safety Stock)

- Quản lý lệnh sản xuất (Work Orders)

Vào giữa thập niên 1960, các chức năng trên ñã cấu thành hệ thống MRP Dựa trên sự tích hợp các chức năng cơ bản của quá trình quản lý sản xuất

Vào những năm 1975, hệ MRP ñã ñược ñịnh nghĩa và hiểu biết một cách ñầy ñủ

và chính xác hơn Cũng kể từ ñó bắt ñầu hình thành hệ thống MRP II Sự lẫn lộn giữa MRP II và MRP ñã bắt ñầu ngay sau khi giới thiệu MRP II Việc dễ nhầm lẫn các thuật ngữ bắt ñầu trong ñào tạo và ñịnh nghĩa chung chung về MRP và MRP II Khi những chuyên gia tư vấn và các nhà hoạch ñịnh sử dụng thuật ngữ MRP thì họ cảm thấy không rõ ràng khi thảo luận về MRP hay MRP II

Tổ chức APICS, là một tổ chức có rất nhiều kinh nghiệm về hệ thống MRP, ñã ñịnh nghĩa MRP thống nhất trong cuốn từ ñiển biên soạn lần thứ chín của họ như sau:

“MRP là một tập hợp công nghệ sử dụng dữ liệu về BOM, thông tin kho và lịch sản xuất ñể tính toán ra nhu cầu nguyên vật liệu

MRP ñưa ra yêu cầu huỷ bỏ những ñơn ñặt hàng không cần thiết

MRP ñưa ra các ñề xuất ñể tối ưu hoá việc mua hàng bằng cách tính toán lại thời ñiểm có thể nhận nguyên vật liệu (từ nhà cung cấp) và thời ñiểm thật sự cần số hàng ñó cho sản xuất

MRP dựa trên số lượng hàng cần sản xuất trong một giai ñoạn và:

- Thứ nhất là: xác ñịnh số lượng và tất cả các nguyên vật liệu thành phần

ñể sản xuất một loại hàng ñó

- Thứ hai là: xác ñịnh các yếu tố về thời gian Thời ñiểm cần các nguyên

liệu và thành phần trong các công ñoạn của quá trình sản xuất

MRP dựa trên cấu trúc BOM, xem xét số lượng nguyên liệu tồn kho (thực tế, số lượng ñang trên ñường về) và xác ñịnh số lượng thật sự cần mua thêm trong thời gian giao hàng (mà nhà cung cấp hứa hẹn) nhằm ñáp ứng một cách tối ưu cho sản xuất.” Còn MRP II ñược ñịnh nghĩa là:

“Một phương pháp hoạch ñịnh hiệu quả các nguồn tài nguyên của doanh nghiệp

Nó nhắm ñến việc hoạch ñịnh hoạt ñộng cho từng ñơn vị bộ phận, hoạch ñịnh tài chính và có khả năng dự trù cho các tình huống xảy ra trong quá trình sản xuất

Nó ñược tạo thành từ nhiều chức năng riêng biệt, liên kết lại với nhau:

- Hoạch ñịnh kinh doanh

- Hoạch ñịnh bán hàng và giao dịch

- Hoạch ựịnh sản xuất

- Hoạch ựịnh yêu cầu nguyên vật liệu

- đầu ra của hệ thống ựược tắch hợp với những báo cáo tài chắnh như là:

- Kế hoạch kinh doanh

- Báo cáo các ựơn ựặt hàng

đến những thập niên 1975, sự xuất hiện của Công nghệ thông tin ựã góp phần xây dựng khái niệm ERP dựa trên hệ thống MRP II Ban ựầu có vài ựịnh nghĩa hệ thống ERP như sau:

ỘERP là một hệ thống thông tin hướng kế toán sử dụng kỹ thuật mới như giao diện người dùng, cơ sở dữ liệu quan hệ, ngôn ngữ máy tắnh thế hệ thứ tư, phần mềm

hỗ trợ máy tắnh, kiến trúc client/serverỢ

Tuy nhiên, các chuyên gia cho rằng một ựịnh nghĩa về ERP nên gồm những nghiệp vụ cần thiết cho hoạt ựộng sản xuất kinh doanh bao gồm: kế toán, sản xuất, phân phối, giao dịch, bán hàng, vật tư, chất lượngẦChắnh vì thế, hệ thống ERP ựược ựịnh nghĩa lại chắnh xác hơn như sau:

ỘERP là chữ viết tắt của Enterprise Resource Planning đó là một hệ thống phần mềm giúp cho các hoạt ựộng sản xuất kinh doanh hoạt ựộng một cách hiệu quả và toàn diện

Hệ thống ERP (dành cho doanh nghiệp sản xuất) bao gồm những phân hệ :

Ờ Quản lý các hoạt ựộng tiếp thị và bán hàng

Ờ Thiết kế và phát triển sản phẩm

Ờ Quản lý vật tư và thành phẩm

Quản lý mua hàng