ỨNG DỤNG UML DESIGN PATTERN XÂY DỰNG HỆ THỐNG ĐĂNG KÝ TÍN CHỈ TRỰC TUYẾN (ONLINE COURSE REGISTER SYSTEM)

ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA CÔNG NGHỆ THÔNG TIN
Tel. (84-511) 736 949, Fax. (84-511) 842 771
Website: itf.ud.edu.vn, E-mail:

LUẬN VĂN TỐT NGHIỆP KỸ SƯ
NGÀNH CÔNG NGHỆ THÔNG TIN
MÃ NGÀNH : 05115
ĐỀ TÀI :
ỨNG DỤNG UML & DESIGN PATTERN
XÂY DỰNG HỆ THỐNG ĐĂNG KÝ TÍN CHỈ TRỰC TUYẾN
(ONLINE COURSE REGISTER SYSTEM)
Mã số : 02T1-003
02T1-027
Ngày bảo vệ : 13/06/2007 – 15/06/2007
SINH VIÊN : LÊ HỮU ĐỨC
NGUYỄN THỊ HÀ QUYÊN
LỚP : 02T1
CBHD : ThS. GV. TRƯƠNG NGỌC CHÂU
ĐÀ NẴNG, 06/2007
LỜI CẢM ƠN
Lời đầu tiên chúng tôi xin bày tỏ lòng biết ơn sâu sắc đến tất cả
quý thầy cô, những người đã tận tụy dạy dỗ, truyền đạt kiến thức và
kinh nghiệm quý báu cho chúng tôi trong suốt năm năm học qua.
Chúng tôi xin chân thành cảm ơn ThS. Trương Ngọc Châu - thuộc
bộ môn Công nghệ phần mềm, khoa Công nghệ thông tin, trường Đại
học Bách khoa Đà Nẵng, người đã hướng dẫn, tạo điều kiện thuận lợi
và giúp đỡ chúng tôi trong suốt thời gian làm đề tài.
Và để có được kết quả như ngày hôm nay, chúng tôi rất biết ơn gia
đình đã động viên, khích lệ và tạo mọi điều kiện thuận lợi nhất trong

suốt quá trình học tập cũng như quá trình thực hiện đề tài tốt nghiệp
này.
Xin chân thành cám ơn các bạn trong khoa Công nghệ thông tin –
khóa 02, đặc biệt là các bạn lớp 02T1 đã ủng hộ, giúp đỡ, chia sẻ kiến
thức, kinh nghiệm và tài liệu có được cho nhóm chúng tôi trong quá
trình nghiên cứu và thực hiện đề tài.
Một lần nữa xin chân thành cám ơn!
LỜI CAM ĐOAN
Chúng tôi xin cam đoan :
1 Những nội dung trong luận văn này là do chúng tôi thực hiện dưới sự
hướng dẫn trực tiếp của thầy ThS. GV. Trương Ngọc Châu.
2 Mọi tham khảo dùng trong luận văn đều được trích dẫn rõ ràng tên
tác giả, tên công trình, thời gian, địa điểm công bố.
3 Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá,
chúng tôi xin chịu hoàn toàn trách nhiệm.
Sinh viên,
Lê Hữu Đức
Nguyễn Thị Hà Quyên
MỤC LỤC
ĐÀ NẴNG, 06/2007 1
MỞ ĐẦU 1
I. Đặt vấn đề 1
II. Mục đích và ý nghĩa 2
III. Khái quát hệ thống 3
IV. Phạm vi đề tài 4
V. Nhiệm vụ thực hiện 4
VI. Phương pháp triển khai 5
VII. Công cụ và môi trường triển khai 5
VIII. Dự kiến kết quả đạt được 5
IX. Bố cục trình bày 5

CƠ SỞ LÝ THUYẾT 6
I. Ngôn ngữ mô hình hóa UML 6
i. Sự ra đời UML 6
ii. Quá trình phát triển của UML 6
iii. Các thành phần của UML 6
a.Hướng nhìn và sơ đồ 6
b.Phần tử mô hình hóa 7
iv. Hạn chế của UML 9
v. Sự phát triển và tính ổn định của UML 10
II. Mẫu thiết kế DP 10
1. Lịch sử phát triển 10
ii. Định nghĩa 10
iii. Các yếu tố xác định một DP 10
iv. Phân loại 11
v. Vận dụng 11
a)Mẫu Factory: được gọi là mẫu phương thức chế xuất, nó định nghĩa một giao
diện “sinh” ra đối tượng và để cho lớp con kế thừa quyết định lớp nào sẽ được dùng để
“sinh” ra đối tượng hay các cá thể của một lớp. Phương thức chế xuất cho phép một
lớp chuyển quá trình khởi tạo đối tượng cho lớp con kế thừa hay lớp con kế thừa sẽ
quyết định sản phẩm được tạo ra 11
b)Mẫu Singleton: được gọi là mẫu đơn, đảm bảo một tầng chỉ có một đối tượng hay
thực thể duy nhất được tạo ra và đồng thời cung cấp một truy cập toàn cục đến đối
tượng được tạo ra. Chúng ta xét trường hợp có nhiều đối tượng có cùng chung một số
tính chất nào đó được tạo ra ứng với mỗi một yêu cầu từ các client, lúc này độ phức
tạp sẽ tăng lên và ứng dụng sẽ chiếm dụng nhiều vùng nhớ hơn. Mẫu Singleton là một
giải pháp đặc biệt của mẫu chế xuất, ở chỗ đối tượng sinh ra là điểm truy cập toàn cục
“duy nhất” đối với mọi chương trình gọi đến, hay nói một cách khác tất cả các client
gọi đến đều chia sẻ đối tượng được tạo ra 11
c)Mẫu Strategy: được gọi là mẫu chiến lược, xác định họ các thuật toán, 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 12
III. Mô hình ba lớp 12
1. Presentation Layer 13
ii. Business Logic Layer 13
iii. Data Access Layer 14
IV. Vấn đề bảo mật trong ASP.Net 14
1. Các phương thức chứng thực 14
ii. Các phương thức xác thực 15
ĐẶC TẢ CHỨC NĂNG HỆ THỐNG 17
I. Quy định đánh mã số 17
1. Mã trường 17
ii. Mã khoa, phòng ban 17
iii. Mã ngành 17
iv. Mã học phần 17
v. Mã lớp sinh hoạt 17
vi. Mã lớp học phần 17
vii. Mã sinh viên 17
II. Chức năng các Actor tham gia vào hệ thống 18
1. Người dùng chung 18
ii. Sinh viên 18
iii. Giảng viên 18
iv. Giáo vụ khoa 18
v. Cán bộ đào tạo 18
vi. Quản trị hệ thống 19
III. Xây dựng kịch cảnh cho các UseCase 19
1. NgườiDùngChung 19
a)Xem_Thông_Tin_Các_Phòng_Ban/Khoa 19
b)Xem_Thông_Tin_Cán_Bộ_Nhân_Viên 20
c)Xem_Thông_Báo_Tin_Tức 20
ii. SinhViên 20

a)Đăng_Nhập 20
d)Xem_Thông_Tin_Cá_Nhân_Sinh_Viên 21
e)Đăng_Ký_Học_Phần 21
f)Hủy_Học_Phần_Đã_Chọn 22
g)Xem_Lịch_Thi 23
h)Xem_Thời_Khóa_Biểu 23
i)Xem_Danh_Sách_Các_Học_Phần_Có_Điểm_Thi_Trên_5 23
j)Xem_Hướng_Dẫn_Đăng_Ký_Học_Phần 24
k)Thay_Đổi_Password 24
l)Đăng_Xuất 25
iii. GiảngViên 25
a)Đăng_Nhập 25
b)Xem_Thông_Tin_Cá_Nhân_Giảng_Viên 25
c)Xem_Danh_Sách_Sinh_Viên 26
d)Thay_Đổi_Password 26
e)Xem_Lịch_Dạy 27
f)Đăng_Xuất 27
iv. GiáoVụKhoa 28
a)Đăng_Nhập 28
b)Xem_Báo_Cáo_Thống_Kê 28
c)Xem_Danh_Sách_Sinh_Viên 28
d)Thay_Đổi_Password 29
e)Đăng_Xuất 29
v. CánBộĐàoTạo 30
a)Đăng_Nhập 30
b)Quản_Lý_Tài_Khoản_Giảng_Viên 30
c)Quản_Lý_Tài_Khoản_Sinh_Viên 31
d)Quản_Lý_Lớp_Học 31
e)Quản_Lý_Phòng_Học 32
f)Quản_Lý_Học_Phần 32

g)Xem_Danh_Sách_Sinh_Viên 33
h)Xếp_Lịch_Thi 33
i)Giới_Hạn_Đăng_Ký 34
j)Tạo_Thời_Khóa_Biểu_Dự_Kiến 34
k)Xem_Xét_Tổ_Chức_Các_Lớp_Học_Phần_Đề_Nghị 35
l)Xem_Báo_Cáo_Thống_Kê 35
m)Quản_Lý_Chương_Trình_Đào_Tạo 36
n)Nhập_Và_Cập_Nhật_Điểm 36
o)Thay_Đổi_Password 36
p)Đăng_Xuất 37
vi. QuảnTrịHệThống 37
a)Đăng_Nhập 37
b)Quản_Lý_Tài_Khoản_Cán_Bộ_Đào_Tạo 38
c)Quản_Lý_Tài_Khoản_Giáo_Vụ_Khoa 38
d)Cấu_Hình_Hệ_Thống&Duy_Trì_Hệ_Thống 39
e)Thay_Đổi_Password 39
f)Đăng_Xuất 40
IV. Sơ đồ use-case 40
PHÂN TÍCH THIẾT KẾ HỆ THỐNG 46
I. Mô hình hóa cấu trúc 46
1. Quá trình xây dựng các lớp ứng dụng 46
a.Khởi tạo danh sách các lớp ứng viên 46
b.Loại bỏ các lớp giả 49
c.Đồng nhất các lớp ứng viên trùng lắp 50
d.Xác định các danh từ, cụm danh từ có thể là thuộc tính 52
e.Loại bỏ lớp ứng viên không có mục tiêu hoặc không thuộc phạm vi hệ thống 53
f. Các lớp ứng viên sau quá trình xây dựng 55
ii. Mô hình hóa các lớp ứng dụng 55
a.Sơ đồ lớp của nhóm người dùng sinh viên 57
b.Sơ đồ lớp của nhóm đối tượng giảng viên 61

c.Sơ đồ lớp của nhóm đối tượng giáo vụ khoa 63
d.Sơ đồ lớp của nhóm đối tượng cán bộ đào tạo 64
e.Sơ đồ lớp của nhóm đối tượng quản trị hệ thống 68
II. Mô hình hóa hành vi 69
III. Xác định mối quan hệ giữa các lớp 75
IV. Thiết kế hệ thống 78
1. Thiết kế lớp 78
ii. Chuyển đổi đối tượng sang mô hình quan hệ 86
a.Chuyển đổi lớp – bảng 86
b.Chuyển đổi mối liên kết 86
iii. Triển khai hệ thống OCRS 89
iv. Giải thuật và độ phức tạp giải thuật 89
XÂY DỰNG VÀ TRIỂN KHAI HỆ THỐNG 92
I. Trang chủ hệ thống OCRS 92
1. Hệ thống menu trái 92
ii. Hệ thống menu trên 93
iii. Khung đăng nhập 93
iv. Đếm số người dùng đang truy cập 93
v. Đồng hồ và lịch 93
II. Trang màn hình lựa chọn sinh viên 94
III. Trang đăng ký học phần 95
IV. Trang màn hình lựa chọn giảng viên 96
V. Trang màn hình lựa chọn giáo vụ khoa 97
VI. Trang màn hình lựa chọn cán bộ đào tạo 98
VII. Trang màn hình lựa chọn quản trị hệ thống 101
101
KẾT LUẬN 102
I. Kết quả đạt được 102
1. Về mặt lý thuyết 102
ii. Về mặt thực tiễn 102

II. Hướng phát triển của đề tài 103
DANH MỤC HÌNH ẢNH
Hình II.1: Các giai đoạn phát triển UML 6
Hình II.2: Phân loại các biểu đồ trong UML 2.0 7
11
Hình II.3: Sơ đồ cấu trúc mẫu Factory 11
12
Hình II.4: Sơ đồ cấu trúc mẫu Singleton 12
12
Hình II.5: Sơ đồ cấu trúc mẫu Strategy 12
13
Hình II.6: Mô hình ba lớp 13
Hình III.1: Sơ đồ khung cảnh của hệ thống OCRS 19
41
41
44
56
57
Hình III.2: Sơ đồ use-case tổng quát về hệ thống [Mức 1] 41
Hình III.3: Sơ đồ use-case của Actor sinh viên [Mức 2] 41
42
Hình III.4: Sơ đồ use-case của Actor giảng viên [Mức 2] 42
42
Hình III.5: Sơ đồ use-case của Actor giáo vụ khoa [Mức 2] 42
43
Hình III.6: Sơ đồ use-case của Actor cán bộ đào tạo [Mức 2] 43
44
Hình III.7: Sơ đồ use-case của Actor quản trị hệ thống [Mức 2] 44
Hình III.8: Sơ đồ use-case của chức năng đăng nhập vào hệ thống [Mức 3] 44
45

Hình III.9: Sơ đồ use-case của chức năng đăng xuất khỏi hệ thống [Mức 3] 45
Hình IV.1: Sơ đồ lớp tổng quan hệ thống OCRS 56
Hình IV.2: Sơ đồ lớp của actor SinhViên [Mức 1] 57
58
Hình IV.3: Sơ đồ lớp mịn dần chức năng HủyHọcPhầnĐãĐăngKý [Mức 2] 58
58
Hình IV.4: Sơ đồ lớp mịn dần chức năng ĐăngKýHọcPhần [Mức 2] 58
59
Hình IV.5: Sơ đồ lớp mịn dần chức năng ThayĐổiPassword [Mức 2] 59
59
Hình IV.6: Sơ đồ lớp mịn dần chức năng HướngDẫnĐăngKýHọcPhần [Mức 2] 59
59
Hình IV.7: Sơ đồ chức năng XemLịchThi [Mức 2] 59
60
Hình IV.8: Sơ đồ chức năng XemThờiKhóaBiểu [Mức 2] 60
60
Hình IV.9: Sơ đồ chức năng XemThôngTinCáNhân [Mức 2] 60
61
Hình IV.10: Sơ đồ chức năng KiểmTraHọcPhầnĐăngKý [Mức 3] 61
61
Hình IV.11: Sơ đồ lớp của actor GiảngViên [Mức 1] 61
62
Hình IV.12: Sơ đồ chức năng XemLịchDạy [Mức 2] 62
62
Hình IV.13: Sơ đồ chức năng XemThôngTinCáNhân [Mức 2] 62
62
Hình IV.14: Sơ đồ chức năng XemDanhSáchSinhViên [Mức 2] 62
62
Hình IV.15: Sơ đồ chức năng ThayĐổiPassword [Mức 2] 63
63

Hình IV.16: Sơ đồ lớp của actor GiáoVụKhoa [Mức 1] 63
63
Hình IV.17: Sơ đồ chức năng XemDanhSáchSinhViên [Mức 2] 63
63
Hình IV.18: Sơ đồ chức năng ThayĐổiPassword [Mức 2] 64
64
Hình IV.19: Sơ đồ chức năng XemBáoCáoThốngKê [Mức 2] 64
64
Hình IV.20: Sơ đồ chức năng XemThôngTinCáNhân [Mức 2] 64
64
Hình IV.21: Sơ đồ lớp của actor CánBộĐàoTạo [Mức 1] 65
65
Hình IV.22: Sơ đồ chức năng GiớiHạnĐăngKý [Mức 2] 65
65
Hình IV.23: Sơ đồ chức năng XemBáoCáoThốngKê [Mức 2] 65
65
Hình IV.24: Sơ đồ chức năng ThayĐổiPassword [Mức 2] 66
66
Hình IV.25: Sơ đồ chức năng TạoDữLiệu [Mức 2] 66
66
Hình IV.26: Sơ đồ chức năng Xóa/KhóaDữLiệu [Mức2] 67
67
Hình IV.27: Sơ đồ chức năng XemThôngTin [Mức 2] 67
67
Hình IV.28: Sơ đồ chức năng CậpNhậtThôngTin [Mức 2] 68
68
Hình IV.29: Sơ đồ chức năng CậpNhậtĐiểm [Mức 2] 68
68
Hình IV.30: Sơ đồ lớp của actor QuảnTrịHệThống [Mức 1] 69
69

Hình IV.31: Sơ đồ lớp chức năng ThayĐổiPassword [Mức 2] 69
69
Hình IV.32: Sơ đồ lớp chức năng XemThôngTinCáNhân [Mức 2] 69
71
Hình IV.33: Sơ đồ hoạt động của actor sinh viên 71
72
Hình IV.34: Sơ đồ hoạt động tổ chức lớp học phần đề nghị của cán bộ đào tạo 72
Hình IV.35: Sơ đồ trình tự đăng ký học phần của sinh viên 74
75
Hình IV.36: Sơ đồ trình tự biểu diễn quá trình hủy các học phần đã đăng ký 75
Hình IV.37: Sơ đồ lớp tổng quát hệ thống OCRS [Hướng nhìn Logic] 77
78
Hình IV.38: Các ký hiệu minh họa phạm vi truy cập 79
Hình IV.39: Mô hình ba lớp của nhóm người dùng sinh viên 81
Hình IV.40: Mô hình ba lớp của nhóm người dùng giảng viên 82
Hình IV.41: Mô hình ba lớp của nhóm người dùng giáo vụ khoa 83
Hình IV.42: Mô hình ba lớp của nhóm người dùng cán bộ đào tạo 84
Hình IV.43: Mô hình ba lớp của nhóm người dùng quản trị hệ thống 85
Hình IV.44: Lược đồ cơ sở dữ liệu quan hệ 88
89
Hình IV.45: Sơ đồ triển khai của hệ thống OCRS 89
92
Hình V.1: Trang chủ hệ thống OCRS 92
93
Hình V.2: Trang màn hình lựa chọn sinh viên 94
Hình V.3: Trang đăng ký học phần 95
Hình V.4: Trang màn hình lựa chọn giảng viên 96
Hình V.5: Trang màn hình lựa chọn giáo vụ khoa 97
Hình V.6: Trang màn hình lựa chọn cán bộ đào tạo 98
Hình V.7: Trang màn hình lựa chọn quản trị hệ thống 101

DANH MỤC BẢNG
Bảng II.1: Các phần tử mô hình trong UML 9
Bảng IV.1: Các danh từ đồng nhất 50
Bảng V.1: Hệ thống menu trái của trang chủ 93
Bảng V.2: Hệ thống menu trên của trang chủ 93
Bảng V.3: Hệ thống menu trái trang màn hình lựa chọn sinh viên 94
Bảng V.4: Hệ thống menu trái trang màn hình lựa chọn giảng viên 96
Bảng V.5: Hệ thống menu trái trang màn hình lựa chọn giáo vụ khoa 98
Bảng V.6: Hệ thống menu trái trang màn hình lựa chọn cán bộ đào tạo 100
Bảng V.7: Hệ thống menu trái trang màn hình lựa chọn quản trị hệ thống 101
DANH MỤC CÁC TỪ VIẾT TẮT
UML Unified Modeling Language
DP Design Pattern
RUP Rational Unified Process
OMG Object Manager Group
OMA Object Management Architecture
RTF Revision Task Force
OMT Object Modeling Technique
OOA Object Oriented Analysis
OOD Object Oriented Design
OCRS Online Course Register System
ĐHBK ĐN Đại học Bách khoa Đà Nẵng
ĐHĐN Đại học Đà Nẵng
PĐT&CTSV Phòng Đào tạo & Công tác sinh viên
NCKH Nghiên cứu khoa học
KĐCLGDĐH Kiểm định chất lượng giáo dục Đại học
XDDD&CN Xây dựng Dân dụng & Công nghiệp
XDTLTĐ Xây dựng Thủy lợi Thủy điện
TTĐTKSCLC Trung tâm đào tạo kỹ sư chất lượng cao
CNNĐL Công nghệ Nhiệt Điện lạnh

ĐTBCHT Điểm trung bình chung học tập
ĐTBCTL Điểm trung bình chung tích lũy
CTĐT Chương trình đào tạo
TTV Tổ tài vụ
GoF Gang of Four
HCTH Hành chính tổng hợp
GD&ĐT Giáo dục và đào tạo
KH-SĐH-HTQT Khoa học-Sau đại học-Hợp tác quốc tế
PĐT Phòng Đào tạo
DANH MỤC CÁC THUẬT NGỮ
Actor tác nhân
Use-Case chức năng hệ thống
View hướng nhìn
Use-case view hướng nhìn chức năng
Logic view hướng nhìn thiết kế
Process view hướng nhìn xử lý
Component view hướng nhìn thành phần
Deployment view hướng nhìn bố trí
Notation ký pháp
Process tiến trình
CASE công cụ hỗ trợ
Semantic ngữ nghĩa
Diagram sơ đồ
` Collaboration
diagram
sơ đồ hợp tác
Communication
diagram
sơ đồ giao tiếp
State machine

diagram
sơ đồ máy trạng thái
State diagram sơ đồ trạng thái
Sequence diagram sơ đồ trình tự
Class diagram sơ đồ lớp
Object diagram sơ đồ đối tượng
Activity diagram sơ đồ hoạt động
Component diagram
sơ đồ thành phần
Deployment diagram
sơ đồ bố trí
Package diagram sơ đồ gói
Use-case diagram sơ đồ use-case
Association liên kết
Dependency phụ thuộc
Generalization khái quát hóa
Aggregation kết tập
Classifier Loài
Composite cấu thành
Realization nhận thức
Start state trạng thái bắt đầu
End state trạng thái kết thúc
Design Pattern mẫu thiết kế
Consequences hệ quả
Scenario kịch cảnh
Activity hoạt động
Collaboration cộng tác
Communication giao tiếp
Deployment triển khai
Adornment trang trí

Specification đặc tả
Stereotype khuôn mẫu
Navigation định hướng
Reserve engineer tái tạo mô hình
Responsibility trách nhiệm
Elaboration triển khai
Workflow công đoạn
Presentation hiển thị, trình diễn
Business logic tác nghiệp
Data access truy cập dữ liệu
PHẦN I
MỞ ĐẦU
I. Đặt vấn đề
Hiện nay, học chế tín chỉ là hình thức đào tạo được xem là tiên tiến trên thế giới vì mục
đích đào tạo của nó là hướng vào sinh viên, coi người học là trung tâm trong quá trình dạy và
học. Với hình thức này, người học chủ động hơn trong việc tiếp thu kiến thức và sử dụng thời
gian, như chủ động lựa chọn môn học, giáo viên, giờ học v v…, đồng thời nâng cao khả năng
tự học, tự nghiên cứu và hạn chế được tình trạng dạy và học theo lối kinh viện.
Với xu thế phát triển của ngành giáo dục nước ta hiện nay, đào tạo theo học chế tín chỉ là
một trong bảy bước đi quan trọng trong lộ trình đổi mới giáo dục bậc đại học giai đoạn 2006 –
2020. Nét đặc trưng của hệ thống tín chỉ với chương trình đào tạo được cấu trúc thành các
học phần nhằm tăng khả năng linh động trong hệ thống đào tạo, đồng thời giúp sinh viên có
cơ hội học tập phù hợp với năng lực, hoàn cảnh và quy định chung của từng ngành chuyên
môn.
Cùng với chiến lược xây dựng và phát triển thành phố Đà Nẵng thời kỳ công nghiệp hóa,
hiện đại hóa, song song với quá trình hội nhập thế giới và khả năng tương thông giữa các
trường đại học trong cả nước, trường Đại học Bách khoa Đà Nẵng cũng như các trường thành
viên của Đại học Đà Nẵng đã và đang triển khai để đưa vào thử nghiệm các hệ thống cho
phép áp dụng và quản lý tốt nhất mọi vấn đề của cơ chế đào tạo tín chỉ.
Thực tế cho thấy, cơ chế đào tạo tín chỉ ở các trường đại học trên cả nước nói chung cũng

như trường ĐHBKĐN nói riêng, vẫn chưa được tin học hóa một cách triệt để và bộc lộ những
vấn đề sau:
 Quy trình thực hiện khá rắc rối, cụ thể: vào đầu mỗi học kỳ, phòng Đào tạo sẽ in ra
một danh sách các lớp học phần dự kiến dạy trong kỳ cùng thời khóa biểu của nó và
gọi là “Sổ tay sinh viên”; PĐT phát sổ tay sinh viên và phiếu đăng ký học phần cho
sinh viên thông qua lớp trưởng hoặc giáo viên chủ nhiệm; sinh viên quyết định chọn
các học phần cùng lớp học phần tương ứng và nộp lại cho lớp trưởng hay giáo viên
chủ nhiệm để nộp lại cho PĐT; PĐT phải kiểm tra và xem xét một cách chính xác để
cho phép một sinh viên có được theo học một ở một lớp học phần nào đó hay không?;
PĐT trả kết quả về lại cho mỗi sinh viên. Nếu có bất kỳ một thay đổi nào từ phía PĐT
về kế hoạch giảng dạy, quy trình này lại phải lặp lại, hoặc nếu có bất kỳ một sự không
đồng bộ nào giữa sinh viên và PĐT thì buộc sinh viên phải có đề nghị để được PĐT
giải quyết.
 Cần rất nhiều nhân lực cho quá trình kiểm tra cũng như xử lý các kết quả đăng ký, đề
nghị của sinh viên.
 Chi phí đào tạo cao hơn so với hình thức đào tạo trước đây, gồm cả chi phí để in ấn sổ
tay sinh viên và phiếu đăng ký học phần, chi phí cho nguồn nhân lực mới v.v…
Chính vì những lý do trên, việc tin học hóa hệ thống quản lý đào tạo tín chỉ là hết sức cần
thiết và cấp bách. Làm thế nào để giảm nhẹ công tác quản lý, quy trình đăng ký học phần của
sinh viên và đem lại hiêu quả giáo dục cao là những mong muốn không chỉ của nhà trường
mà còn của cả sinh viên chúng tôi nữa, đó chính là lý do chúng tôi quyết định chọn đề tài này.
Hệ thống đào tạo theo học chế tín chỉ là một hệ thống rất phức tạp liên quan tới nhiều vấn
đề khác như việc đăng ký học phần của sinh viên, sắp xếp thời khóa biểu, quản lý điểm, quản
lý nhân sự, quản lý hồ sơ sinh viên v.v Mỗi vấn đề như vậy là một bài toán thực tế cần được
tin học hóa để đơn giản quá trình quản lý trong thời đại mà công nghệ thông tin đã và đang
phát triển như vũ bão hiện nay.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 1
PHẦN I
II. Mục đích và ý nghĩa
Mục đích của đồ án tốt nghiệp này là tìm hiểu, xây dựng, hoàn thiện và đưa vào sử

dụng thử nghiệm “Hệ Thống Đăng Ký Tín Chỉ Trực Tuyến OCRS” cho trường Đại học Bách
khoa Đà Nẵng thông qua môi trường Internet.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 2
Mở đầu
OCRS là từ viết tắt của Online Course Register System, là hệ thống cho phép sinh viên
đăng ký tín chỉ trực tuyến, đồng thời đơn giản hóa và tối ưu công tác quản lý đăng ký tín chỉ
của PĐT.
Trong những năm gần đây, các hệ thống phần mềm ngày càng trở nên phức tạp cả về yêu
cầu cũng như kiến trúc. Vấn đề mà các nhà tin học hiện nay quan tâm là làm thế nào để triển
khai các dự án tin học một cách logic, khoa học, rõ ràng, có khả năng mở rộng cũng như tái
sử dụng. Các phương pháp luận, kỹ thuật và công cụ phát triển các hệ thống phần mềm đang
thay đổi một cách nhanh chóng. Một điều hiển nhiên rằng, phát triển hướng đối tượng với các
khái niệm cơ bản của nó và việc áp dụng các mẫu thiết kế cũng như ứng dụng các công nghệ
Web tiên tiến ngày càng được sử dụng rộng rãi. Vì vậy, chúng tôi đã sử dụng ngôn ngữ mô
hình hóa UML trong quá trình phân tích thiết kế hệ thống, và vận dụng các mẫu thiết kế
Design Pattern trong quá trình xây dựng triển khai hệ thống.
III.Khái quát hệ thống
Trường ĐHBK ĐN áp dụng chế độ học theo tín chỉ và cho phép sinh viên có quyền lựa
chọn học phần cho mỗi học kỳ. Để đăng ký học phần được, điều kiện quan trọng nhất là sinh
viên phải có tài khoản riêng của mình do PĐT quản lý bao gồm Username & Password, và
các điều kiện khác theo quy định của trường.
Khi đăng ký học phần, sinh viên phải đăng nhập vào hệ thống OCRS, rồi chọn vào mục
“Đăng ký học phần”, đồng thời phải xác định rõ là đăng ký cho học kỳ nào theo chương trình
đào tạo của mình. Chú ý rằng, mỗi học kỳ sinh viên chỉ có thể đăng ký một số lượng học phần
đảm bảo số tín chỉ min và số tín chỉ max cùng những điều kiện của mỗi học phần đó.
Sau khi sinh viên đã submit các thông tin đầy đủ theo yêu cầu của hệ thống để đăng ký,
sinh viên sẽ xem được thông tin về những học phần bắt buộc, học phần tự chọn trong học kỳ
đó theo khung chương trình đào tạo, cùng những học phần còn nợ và học phần chưa đăng ký
học trong các học kỳ trước của chính mình. Ngoài ra, sinh viên còn có thể đề nghị học một
học phần mới không thuộc thời khóa biểu dự kiến trong phần “Đề nghị của sinh viên”. Ở mỗi

học phần, sinh viên sẽ được xem tất cả các lớp học phần của học phần đó cùng thời khóa biểu
cụ thể của chúng, và sinh viên sẽ phải chọn một trong số những lớp học phần này, phụ thuộc
vào số lượng sinh viên tối đa của mỗi lớp học phần đó. Nếu một lớp học phần đã đủ số sinh
viên quy định, thì sinh viên sẽ không được học ở lớp học phần đó và phải đăng ký học ở lớp
học phần khác.
Đối với những học phần do sinh viên đề nghị, PĐT phải lấy các thông tin cần thiết về học
phần đó và mở các lớp học phần tương ứng để sinh viên có thể đăng ký tiếp trong khoảng thời
gian cho phép.
Sau khi đăng ký, nếu được phép, tức thời hạn đăng ký còn cho phép, sinh viên có thể hủy
học phần đã đăng ký và đăng ký lại học phần khác, bằng cách hủy chọn và chọn lại học phần
mới hoặc cũng có thể hủy học phần đã đăng ngay trong khi đang thực hiện đăng ký học phần
Tùy mỗi học kỳ, PĐT sẽ quy định khoảng thời gian đăng ký học phần, có thể là một hoặc
hai tuần, và khoảng thời gian chỉnh sửa các thông tin đã đăng ký cũng được quy định. Nếu đã
hết thời hạn quy định, sinh viên sẽ bị khóa không được đăng ký trong học kỳ đó.
Sau khi đã hoàn thành việc đăng ký, các thông tin về thời khóa biểu học và lịch thi kết thúc
học phần cho mỗi sinh viên, cũng như lịch dạy cho mỗi giảng viên sẽ được lưu trữ trong hệ
thống. Sinh viên và giảng viên có thể xem các thông tin này khi chọn vào mục “Thời khóa
biểu”, “Lịch thi” hay “Lịch dạy” tùy theo quyền của mỗi người dùng.
Thông tin về số học phần mà sinh viên đã đăng ký được gởi cho TTV để tính học phí cho
mỗi sinh viên. Lưu ý rằng để có được kế hoạch dạy học cũng như thời khóa biểu dự kiến,
trước khi bước vào một học kỳ mới, giảng viên sẽ đăng ký các học phần mà mình có thể dạy
trong học kỳ đó. Tuy nhiên hệ thống OCRS không quản lý những vấn đề này, chúng thuộc
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 3
Mở đầu
một module khác, hệ thống chỉ lấy thông tin từ những module này hay xuất thông tin ra để
làm đầu vào cho những module đó.
IV. Phạm vi đề tài
Bất kỳ một trường học nào ở bậc đại học, cho dù là đào tạo theo một mô hình nào đi nữa,
thì cũng cần phải tổ chức và quản lý tốt tất cả các vấn đề về tuyển sinh, trang thiết bị, sinh
viên, điểm thi của sinh viên v v…

Tuy nhiên, một thực tế rõ ràng rằng, không thể cùng một lúc và trên cùng một hệ thống, ta
có thể quản lý tất cả những vấn đề nói trên theo như mong muốn được, và việc chia nhỏ
những vấn đề nói trên thành những module riêng biệt trong quản lý là một điều tất yếu.
Qua thực tế và những kinh nghiệm thu thập được, việc quản lý của nhà trường khi áp dụng
mô hình đào tạo theo học chế tín chỉ có thể được chia thành mười hai phân hệ như sau:
 Quản lý chương trình đào tạo
 Quản lý đăng ký học phần
 Quản lý học bổng, miễn giảm học phí
 Quản lý điểm
 Quản lý khối lượng giảng dạy
 Quản lý nhân sự
 Quản lý phòng học
 Quản lý sinh viên
 Quản lý tài vụ
 Quản lý tuyển sinh
 Quản lý thời khóa biểu
 Quản lý thông tin phục vụ lãnh đạo
Mặc dù được chia thành các phân hệ như trên, nhưng giữa chúng vẫn có những tác động
qua lại, kết quả của phân hệ này có thể là thông tin đầu vào cho một phân hệ khác và ngược
lại. Chẳng hạn như, phân hệ “Quản lý tài vụ” cần phải lấy thông tin từ phân hệ “Đăng ký học
phần” về số lượng học phần sinh viên đăng ký ở mỗi học kỳ, hay phân hệ “Đăng ký học
phần” lại cần những thông tin từ phân hệ “Quản lý điểm” và ngược lại v v…Vì vậy, khi xây
dựng phân hệ “Đăng ký học phần” chúng ta cần phải sử dụng thông tin, có thể là giả lập,
được lấy từ những phân hệ khác.
V. Nhiệm vụ thực hiện
Để hoàn thành đồ án này, từ lúc bắt đầu đi tìm hiểu cho đến khi hình thành nên một hệ
thống thực tế hoàn chỉnh, cần thực hiện một số những nhiệm vụ sau:
 Tìm hiểu thực tế về công tác đào tạo ở trường từ các thầy cô giáo, từ những cán bộ ở
phòng đào tạo, từ sinh viên, từ những tài liệu liên quan v.v…, để có được cái nhìn khái
quát về hệ thống.

 Thu thập và hiệu chỉnh dữ liệu từ PĐT cho phù hợp với hệ thống.
 Đặc tả chức năng hệ thống OCRS dưới dạng văn bản.
 Tìm hiểu về ngôn ngữ UML để nắm được các khái niệm cơ bản và những sơ đồ trong
mỗi hướng nhìn đối với một hệ thống.
 Kết thúc quá trình phân tích thiết kế bằng các sơ đồ UML về hệ thống OCRS, như sơ
đồ use-case, sơ đồ lớp, sơ đồ triển khai.
 Tìm hiểu và ứng dụng các mẫu thiết kế DP để xây dựng hệ thống.
 Xây dựng hệ thống OCRS từ kết quả của quá trình phân tích thiết kế bằng công cụ
ASP.Net.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 4
Mở đầu
 Thử nghiệm hệ thống thông qua những use-case, thử nghiệm đơn vị thông qua sơ đồ
lớp và thử nghiệm tích hợp thông qua sơ đồ bố trí, sơ đồ cộng tác.
VI. Phương pháp triển khai
Trong đồ án này, chúng tôi đã sử dụng các phương pháp sau:
 Chia để trị: cụ thể là chia nhóm đối tượng người dùng, chia ứng dụng thành những thư
mục riêng để dễ quản lý.
 Áp dụng mô hình ba lớp trong xây dựng hệ thống: bao gồm Presentation Layer,
Businesss Logic Layer và Data Access Layer; chúng sẽ giao tiếp với nhau thông qua
các dịch vụ mà mỗi lớp cung cấp, lớp này không cần biết bên trong lớp kia làm gì mà
chỉ cần biết lớp kia cung cấp dịch vụ gì cho nó và sử dụng nó mà thôi.
 Ứng dụng DP trong quá trình xây dựng hệ thống, cụ thể là trong khi cài đặt chương
trình.
 Phát triển hệ thống theo tiến trình RUP.
VII. Công cụ và môi trường triển khai
 Hệ quản trị cơ sở dữ liệu SQL Server, phiên bản SQL 2000.
 Công cụ mô hình hóa Rational, phiên bản Enterprise 2003.
 Ngôn ngữ lập trình C# trên nền .Net Framwork 2.0 thuộc bộ Visual Studio 2005.
 Công cụ hỗ trợ lập trình Iron Speed Designer, phiên bản 4.2.0.
VIII. Dự kiến kết quả đạt được

Hệ thống OCRS sẽ cho phép người dùng đăng ký học phần thông qua Internet, và cho
phép những người dùng hợp pháp có quyền xem những thông tin cần thiết, kể cả thao tác với
hệ thống nếu người dùng đó được phép theo đúng quy trình và cơ chế đào tạo tín chỉ, và sẽ
cho kết quả đăng ký đúng như thực tế.
Hệ thống OCRS sẽ được bảo mật ở mức tối đa trên môi trường web bởi các chiến lược bảo
mật hiệu quả.
IX. Bố cục trình bày
Báo cáo gồm những phần trình bày sau:
• PHẦN I: Mở đầu
• PHẦN II: Cơ sở lý thuyết
• PHẦN III: Đặc tả chức năng hệ thống
• PHẦN IV: Phân tích thiết kế hệ thống
• PHẦN V: Xây dựng và triển khai chương trình
• PHẦN VI: Kết luận
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 5
PHẦN II
CƠ SỞ LÝ THUYẾT
I. Ngôn ngữ mô hình hóa UML
i. Sự ra đời UML
Ý tưởng về đối tượng bắt nguồn từ ngôn ngữ lập trình Simula, nhưng nó chỉ trụ vững được
kể từ cuối những năm 80, với sự ra đời của ngôn ngữ lập trình SmallTalk và C++.
Khi lập trình đối tượng đã thành đạt, ngay lập tức có nhu cầu về các phương pháp mô hình
hóa hướng đối tượng. Từ đầu những năm 90, nhiều phương pháp mô hình hóa hướng đối
tượng lần lượt ra đời bao gồm:
 OOAD của Grady Booch.
 OMT của Jim Rumbaugh và cộng sự.
 OOSE/Objectory của Ivar Jacobson và cộng sự.
 Fusion của Derek Coleman và cộng sự.
 OOA/OOD của Peter Coad và Edward Yourdon v.v…
Các phương pháp này đã sử dụng các ký pháp khác nhau, các bước đi khác nhau, do đó cần

phải tập hợp, quy tụ lại tạo thành một phương pháp thống nhất.
Tháng 1/1994, Grady Booch và Jim Bumbaugh bắt đầu hợp tác trong khuôn khổ công ty
phần mềm Rational, nhằm xây dựng một “phương pháp hợp nhất” trên cơ sở hai phương pháp
Booch 93 và OMT-2.
Năm 1995, Ivar Jacobson đã gia nhập hợp tác tạo thành một nhóm “ba người bạn”, họ
quyết định thu hẹp mục tiêu, nhằm thành lập một ngôn ngữ mô hình hóa hợp nhất hơn là một
phương pháp hợp nhất, đánh dấu cho sự ra đời của ngôn ngữ UML.
ii. Quá trình phát triển của UML
Từ khi ra đời cho đến nay, UML đã phát triển qua các giai đoạn, và sau mỗi giai đoạn các
chức năng, thành phần cũng như mục đích của nó ngày càng được củng cố và hoàn thiện hơn.
Các phiên bản cụ thể của UML được thể hiện dưới đây.
Hình II.1: Các giai đoạn phát triển UML
iii. Các thành phần của UML
a. Hướng nhìn và sơ đồ
Hướng nhìn chỉ ra những khía cạnh khác của hệ thống cần được mô hình hóa, bao gồm
hướng nhìn chức năng, hướng nhìn thiết kế, hướng nhìn xử lý, hướng nhìn thành phần và
hướng nhìn song song, trong đó mỗi hướng nhìn miêu tả một khía cạnh riêng biệt.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 6
UML
phiên bản 0
10/1995
UML
0.9
6/1996
UML
1.1
1/1997
IBM & Softeam & UML
đưa ra phiên bản 1.1
UML

1.1
14/11/1997
OMG công nhận chuẩn cho các
ngôn ngữ mô hình hóa và trao
đặc quyền xét lại cho UML
UML
1.2
6/1998
UML
1.3
10/1998
UML
1.4
5/2001
UML
2.0
2003
Cơ sở lý thuyết
Hướng nhìn không phải là một bản vẽ, nó là một sự trừu tượng hóa bao gồm một loạt các
sơ đồ khác nhau.
Các hướng nhìn được thể hiện bởi một hoặc một số các sơ đồ, mỗi sơ đồ gồm hai thành
phần: các nút là các phần tử của mô hình có dạng đồ họa hai chiều như lớp, trạng thái, gói
v.v…; các mối quan hệ là các phần tử mô hình có dạng đồ họa tuyến tính như liên kết, khái
quát hóa, phụ thuộc v.v…
UML 1.x có chín loại sơ đồ. UML 2.0 mở rộng thành mười ba loại, và được chia thành hai
nhóm gồm các sơ đồ về cấu trúc và các sơ đồ về hành vi như dưới đây.
Hình II.2: Phân loại các biểu đồ trong UML 2.0
Như vậy, so với UML 1.x, các sơ đồ cấu trúc đa hợp, sơ đồ bao quát tương tác và sơ đồ
thời khắc là hoàn toàn mới. Còn sơ đồ gói thì trước đây vẫn sử dụng trong các phiên bản
UML 1.x nhưng chưa được đặt tên chính thức. Ngoài ra, sơ đồ trạng thái được đổi tên thành

sơ đồ máy trạng thái và sơ đồ cộng tác được đổi thành sơ đồ giao tiếp, và sơ đồ trình tự còn có
thể được gọi là sơ đồ tuần tự.
b. Phần tử mô hình hóa
Các khái niệm được sử dụng trong các sơ đồ được gọi là các phần tử mô hình, ví dụ như
lớp, đối tượng, thông điệp, liên kết, phụ thuộc,…Mỗi phần tử mô hình được định nghĩa với
ngữ nghĩa, đó là một định nghĩa về bản chất phần tử, hay là một xác định ý nghĩa chính xác
xem nó sẽ thể hiện điều gì trong những lời khẳng định rõ ràng. Mỗi một phần tử mô hình còn
có một sự miêu tả trực quan, một kí hiệu hình học được sử dụng để miêu tả phần tử này trong
sơ đồ.
Mỗi phần tử mô hình được sử dụng trong nhiều sơ đồ khác nhau, nhưng nó luôn chỉ có một
ý nghĩa và một kí hiệu.
STT Phần tử mô hình Mô tả
1
Component
Thành phần: có thể là một thành phần chứa
đựng bằng cách đặt các thành phần khác vào
trong nó.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 7
Sơ đồ
Sơ đồ
cấu trúc
Sơ đồ
lớp
Sơ đồ
bố trí
Sơ đồ
cấu trúc
đa hợp
Sơ đồ
gói

Sơ đồ
thành
phần
Sơ đồ
đối
tượng
Sơ đồ
use-case
Sơ đồ
tương tác
Sơ đồ
hành vi
Sơ đồ
máy
trạng thái
Sơ đồ
hoạt
động
Sơ đồ
bao quát
tương tác
Sơ đồ
trình tự
Sơ đồ
giao tiếp
Sơ đồ
thời khắc
Cơ sở lý thuyết
STT Phần tử mô hình Mô tả
2

Actor
Tác nhân: là một người hoặc một vật, hoặc
một hệ thống khác, tương tác với hệ thống, sử
dụng hệ thống, bằng cách, tác nhân gởi thông
điệp đến hệ thống, hoặc nhận thông điệp xuất
phát từ hệ thống, hoặc thay đổi các thông tin
cùng với hệ thống. Ngoài cách biểu diễn này,
phần tử mô hình tác nhân còn có thể được biểu
diễn dưới dạng một hình chữ nhật như một lớp
và khuôn mẫu <<Actor>> cũng phải được xác
định cùng với lớp đó.
3
Note
Ghi chú: được sử dụng khi một phần của sơ
đồ không thể hiện hết ý đồ của nó, và được
xem như là lời giải thích, nó có thể chứa bất kỳ
loại thông tin nào, và sẽ không được UML
diễn giải.
4
Use case
Use-case: biểu thị cho một chức năng nguyên
vẹn mà một tác nhân nhận được, nó là một
chuỗi hành động mà hệ thống thực hiện để tạo
ra một kết quả có thể quan sát được, tức là một
giá trị đến với một tác nhân cụ thể.
5
Package
Gói: dùng để chứa đựng và tổ chức các phần
tử của sơ đồ. Chẳng hạn như tập các lớp hay
các thành phần tạo thành một hệ thống con thì

nên đưa vào trong một gói.
6
Class
Attributes
Operation()
Lớp: mang ý nghĩa của hướng đối tượng, các
thuộc tính và phương thức cũng được thể hiện
ở đây.
7
Object
Attributes
Operation()
Đối tượng: chỉ cái cụ thể của một lớp các đối
tượng. Tuy nhiên, nó phải phân biệt với các
thuộc tính cũng như các phương thức đều cụ
thể, và có đường gạch dưới để phân biệt với
lớp
8
Node
Nút: đại diện cho các tài nguyên xử lý hệ
thống như các máy tính có bộ xử lý và bộ nhớ,
v.v…
9
State
Trạng thái: biểu thị một trạng thái của một đối
tượng nào đó tại một thời điểm nào đó.
10
Interface
Giao diên: biểu thị cho một tập các hoạt động
về cách hành xử của các lớp và mức độ hiển

thị giữa các lớp với nhau. Nó còn dùng để biểu
thị cho một tập các dữ liệu liên quan nào đó.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 8
Cơ sở lý thuyết
STT Phần tử mô hình Mô tả
11
Trạng thái bắt đầu
12
Trạng thái kết thúc
13
Activity
Hoạt động: đặc trưng cho khả năng hoạt động
của một quá trình nào đó.
14
Quan hệ liên kết: biểu diễn liên hệ giữa một
tác nhân và một use-case, hoặc giữa các lớp.
15
Quan hệ phụ thuộc: cho biết sự phụ thuộc của
một phần tử trong một phương thức nào đó với
một phần tử khác.
16
Quan hệ kết tập: cho biết một lớp bao gồm
các lớp thành phần khác, không bắt buộc phải
đầy đủ.
17
Quan hệ khái quát hóa: biểu thị cho khả năng
thừa kế, tức một lớp có thể thừa kế từ một lớp
khác về cả thuộc tính và phương thức.
18
Quan hệ nhận thức: biểu thị cho khả năng

nhận biết qua một sự kiện hay thông điệp nào
đó. Nó biểu thị liên hệ giữa một lớp và một
giao diện.
19
Quan hệ cấu thành: biểu thị cho một lớp
được cấu thành từ các lớp thành phần khác
Bảng II.1: Các phần tử mô hình trong UML
iv. Hạn chế của UML
Từ khi ra đời và phát triển đến nay, UML đã thể hiện được rất nhiều những ưu điểm của
mình trong quá trình phân tích, thiết kế đi đến xây dựng hệ thống hoàn chỉnh. Tuy nhiên, vẫn
có một số những điểm hạn chế sau của UML:
 Để sử dụng được UML đòi hỏi phải trải qua một khóa đào tạo.
 Để triển khai một dự án tin học, cần phải có các quá trình mà UML chưa giải quyết
hoàn toàn. Việc đưa UML vào trong một quá trình là điều cần thiết nhưng để tối ưu
một quá trình đòi hỏi nhiều công sức và thời gian.
 Các tác giả của UML đã nhận thức được vai trò quan trọng của các quá trình, nhưng
khả năng chấp nhận của các ứng dụng công nghiệp về mô hình hóa đối tượng đòi hỏi
trước hết là sự sẵn sàng của một ngôn ngữ phân tích đối tượng đủ mạnh và chuẩn.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 9
Cơ sở lý thuyết
v. Sự phát triển và tính ổn định của UML
UML được phát triển trong ngữ cảnh quốc tế, các phiên bản thường xuyên được đổi mới,
được trao đổi kinh nghiệm. Các siêu mô hình UML được mô tả theo cách tiêu chuẩn hóa bởi
OMG-MOF.
UML có khả năng diễn đạt phong phú, bao trùm hết mọi giai đoạn của vòng đời phát triển
phần mềm.
UML thể hiện tính mở ở chỗ độc lập với lĩnh vực ứng dụng và ngôn ngữ cài đặt.
II. Mẫu thiết kế DP
Về mặt phương pháp luận, các phương pháp phân tích thiết kế hướng đối tượng đã phát
triển rất mạnh mẽ và góp phần đáng kể vào việc cải tiến chất lượng phần mềm nhờ vào khả

năng xây dựng các lớp đối tượng có tính tái sử dụng cao, dễ bảo trì và mở rộng.
Tuy nhiên, các phương pháp hướng đối tượng tập trung chủ yếu vào các hoạt động tổng
quát tham gia vào tiến trình phát triển phần mềm hướng đối tượng. Những phương pháp này
thường không đi vào giải quyết các vấn đề chi tiết nảy sinh trong quá trình thiết kế và cài đặt
phần mềm.
1. Lịch sử phát triển
Thuật ngữ Pattern xuất phát từ ngành kiến trúc với ý nghĩa như sau:
 Pattern: hay còn gọi là Theme, là cách giải quyết vấn đề, bài toán trong một ngữ cảnh,
hoàn cảnh cụ thể.
 Pattern Language: là một tập các Pattern để giải quyết chuỗi các vấn đề liên quan.
Năm 1987, Ward Cunningham và Kent Beck sử dụng ý tưởng trên để xây dựng năm
Pattern chuyên áp dụng cho thiết kế giao diện người dùng.
Năm 1995, Erich Gamma, Richard Helm, John Vlisides, và Ralph Johnson đã công bố
cuốn sách của họ “Elements of reusable Object-Oriented Software” đánh dấu sự ra đời của
Design Pattern.
ii. Định nghĩa
DP là vấn đề, bài toán thông dụng cần giải quyết và cách giải quyết bài toán đó trong một
ngữ cảnh cụ thể. DP không đơn thuần là một bước nào đó trong các giai đoạn phát triển phần
mềm mà nó đóng vai trò là sáng kiến để giải quyết một bài toán thông dụng. Các giai đoạn
phát triển phần mềm vẫn hoàn chỉnh mà không có DP nhưng sự góp mặt của DP 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ý.
Không chỉ được sử dụng để xác định bài toán và cách giải quyết, mà DP 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. Điều này là tất yếu vì DP tuân thủ rất nghiêm ngặt các nguyên lý thiết kế hướng đối
tượng.
iii. Các yếu tố xác định một DP
 Design Pattern Name: gọi là tên mẫu thiết kế, không đơn thuần chỉ là một từ ngữ
chuyên môn, tên mẫu giúp ta có thể hình dung một cách nhanh chóng và hiệu quả về
mẫu, mà không cần phải xem lại cấu trúc mẫu. Nắm được các Pattern name thông
dụng giúp ta nhìn được các bản thiết kế ở mức trừu tượng hơn, thay vì phải đi sâu vào

chi tiết.
 Problem: gọi là bài toán cần giải quyết, mô tả tình huống áp dụng DP. Ngoài ra,
Problem cũng giúp ta nhìn nhận vấn đề một cách thận trọng, biết khi nào nên và khi
nào không nên áp dụng DP.
 Solution: gọi là cách giải quyết bài toán, mô tả các nhân tố tham gia giải quyết bài
toán và mối quan hệ giữa chúng.
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 10
Cơ sở lý thuyết
 Consequences: gọi là hệ quả, cho ta thấy việc áp dụng các Solution để giải quyết
những Problem có hiệu quả hay không. Nói cách khác, Consequences đặt ra cho ta các
lựa chọn, từ đó có thể xem xét lựa chọn nào là phù hợp nhất, tốt nhất.
iv. Phân loại
Erich Gamma và các đồng sự đã đưa ra hai mươi ba mẫu thiết kế, được phân thành ba loại
theo hai tiêu chí sau:
 Phạm vi áp dụng của mẫu: được sử dụng khi ta cần quyết định nên áp dụng DP vào
các lớp hay vào các đối tượng. Áp dụng vào lớp nhằm mô tả và giải quyết mối quan
hệ, được thiết lập qua cơ chế kế thừa và chỉ xảy ra ở thời điểm biên dịch, giữa các lớp
đối tượng và lớp con của chúng. Áp dụng vào các đối tượng nhằm mô tả và giải quyết
mối quan hệ, cái mà có thể thay đổi tại thời điểm chạy chương trình – run time, giữa
các đối tượng.
 Mục đích sử dụng: với tiêu chí này, các mẫu thiết kế được chia thành ba loại gồm các
mẫu dùng để kiến tạo đối tượng, các mẫu tương tác và các mẫu cấu trúc.
v. Vận dụng
Trong số hai mươi ba mẫu thiết kế này, thông thường chúng ta chỉ sử dụng một số trong
các mẫu thiết kế đó, cụ thể đối với quá trình xây dựng hệ thống OCRS, chúng tôi đã áp dụng
các mẫu thiết kế sau:
a) Mẫu Factory: được gọi là mẫu phương thức chế xuất, nó định nghĩa một giao diện “sinh”
ra đối tượng và để cho lớp con kế thừa quyết định lớp nào sẽ được dùng để “sinh” ra đối
tượng hay các cá thể của một lớp. Phương thức chế xuất cho phép một lớp chuyển quá
trình khởi tạo đối tượng cho lớp con kế thừa hay lớp con kế thừa sẽ quyết định sản phẩm

được tạo ra.
Hình II.3: Sơ đồ cấu trúc mẫu Factory
Trong sơ đồ này, thành phần Product định nghĩa giao diện cho các đối tượng sản phẩm;
ConcreteProduct cài đặt giao diện cho Product; Creator khai báo phương thức sản xuất
FactoryMethod(), phương thức này trả về một đối tượng sản phẩm; ConcreteCreator()
thừa kế tầng Creator, cài đặt phương thức FactoryMethod() để trả về đối tượng
ConcreteCreator.
Áp dụng: hệ thống OCRS cho phép người dùng hợp thức đăng nhập vào hệ thống và
tương tác với hệ thống. Dựa vào Username&Password được nhập từ người dùng, xác lập
các trang tương ứng cho mỗi người dùng và hiển thị trang màn hình lựa chọn riêng cho
mỗi người dùng.
b) Mẫu Singleton: được gọi là mẫu đơn, đảm bảo một tầng chỉ có một đối tượng hay thực
thể duy nhất được tạo ra và đồng thời cung cấp một truy cập toàn cục đến đối tượng được
tạo ra. Chúng ta xét trường hợp có nhiều đối tượng có cùng chung một số tính chất nào đó
được tạo ra ứng với mỗi một yêu cầu từ các client, lúc này độ phức tạp sẽ tăng lên và ứng
Lê Hữu Đức – Nguyễn Thị Hà Quyên, Lớp 02T1 11