Ứ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)

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.

ĐẠ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 771Website: itf.ud.edu.vn, E-mail: cntt@edu.ud.vn

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

ĐÀ 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

MỞ ĐẦU 1

I Đặt vấn đề 1

II Mục đích và ý nghĩa 1

III Khái quát hệ thống 2

IV Phạm vi đề tài 3

V Nhiệm vụ thực hiện 3

VI Phương pháp triển khai 4

VII Công cụ và môi trường triển khai 4

VIII Dự kiến kết quả đạt được 4

IX Bố cục trình bày 4

CƠ SỞ LÝ THUYẾT 5

I Ngôn ngữ mô hình hóa UML 5

1 Sự ra đời UML 5

2 Quá trình phát triển của UML 5

3 Các thành phần của UML 5

a Hướng nhìn và sơ đồ 5

b Phần tử mô hình hóa 6

4 Hạn chế của UML 8

5 Sự phát triển và tính ổn định của UML 9

II Mẫu thiết kế DP 9

1 Lịch sử phát triển 9

2 Định nghĩa 9

3 Các yếu tố xác định một DP 9

4 Phân loại 10

5 Vận dụng 10

a) Mẫu Factory 10

b) Mẫu Singleton 10

c) Mẫu Strategy 11

III Mô hình ba lớp 11

1 Presentation Layer 12

2 Business Logic Layer 12

3 Data Access Layer 13

IV Vấn đề bảo mật trong ASP.Net 13

1 Các phương thức chứng thực 13

2 Các phương thức xác thực 14

ĐẶC TẢ CHỨC NĂNG HỆ THỐNG 16

I Quy định đánh mã số 16

1 Mã trường 16

2 Mã khoa, phòng ban 16

3 Mã ngành 16

4 Mã học phần 16

5 Mã lớp sinh hoạt 16

6 Mã lớp học phần 16

7 Mã sinh viên 16

II Chức năng các Actor tham gia vào hệ thống 17

1 Người dùng chung 17

2 Sinh viên 17

3 Giảng viên 17

4 Giáo vụ khoa 17

5 Cán bộ đào tạo 17

6 Quản trị hệ thống 18

III Xây dựng kịch cảnh cho các UseCase 18

1 NgườiDùngChung 18

a) Xem_Thông_Tin_Các_Phòng_Ban/Khoa 18

b) Xem_Thông_Tin_Cán_Bộ_Nhân_Viên 19

c) Xem_Thông_Báo_Tin_Tức 19

2 SinhViên 19

a) Đăng_Nhập 19

d) Xem_Thông_Tin_Cá_Nhân_Sinh_Viên 20

e) Đăng_Ký_Học_Phần 20

f) Hủy_Học_Phần_Đã_Chọn 21

g) Xem_Lịch_Thi 22

h) Xem_Thời_Khóa_Biểu 22

i) Xem_Danh_Sách_Các_Học_Phần_Có_Điểm_Thi_Trên_5 22

j) Xem_Hướng_Dẫn_Đăng_Ký_Học_Phần 23

k) Thay_Đổi_Password 23

l) Đăng_Xuất 24

3 GiảngViên 24

a) Đăng_Nhập 24

b) Xem_Thông_Tin_Cá_Nhân_Giảng_Viên 24

c) Xem_Danh_Sách_Sinh_Viên 25

d) Thay_Đổi_Password 25

e) Xem_Lịch_Dạy 26

f) Đăng_Xuất 26

4 GiáoVụKhoa 27

a) Đăng_Nhập 27

b) Xem_Báo_Cáo_Thống_Kê 27

c) Xem_Danh_Sách_Sinh_Viên 27

d) Thay_Đổi_Password 28

e) Đăng_Xuất 28

5 CánBộĐàoTạo 29

a) Đăng_Nhập 29

b) Quản_Lý_Tài_Khoản_Giảng_Viên 29

c) Quản_Lý_Tài_Khoản_Sinh_Viên 30

d) Quản_Lý_Lớp_Học 30

e) Quản_Lý_Phòng_Học 31

f) Quản_Lý_Học_Phần 31

g) Xem_Danh_Sách_Sinh_Viên 32

h) Xếp_Lịch_Thi 32

i) Giới_Hạn_Đăng_Ký 33

j) Tạo_Thời_Khóa_Biểu_Dự_Kiến 33

k) Xem_Xét_Tổ_Chức_Các_Lớp_Học_Phần_Đề_Nghị 34

l) Xem_Báo_Cáo_Thống_Kê 34

m) Quản_Lý_Chương_Trình_Đào_Tạo 35

n) Nhập_Và_Cập_Nhật_Điểm 35

o) Thay_Đổi_Password 35

p) Đăng_Xuất 36

6 QuảnTrịHệThống 36

a) Đăng_Nhập 36

b) Quản_Lý_Tài_Khoản_Cán_Bộ_Đào_Tạo 37

c) Quản_Lý_Tài_Khoản_Giáo_Vụ_Khoa 37

d) Cấu_Hình_Hệ_Thống&Duy_Trì_Hệ_Thống 38

e) Thay_Đổi_Password 38

f) Đăng_Xuất 39

IV Sơ đồ use-case 39

PHÂN TÍCH THIẾT KẾ HỆ THỐNG 45

I Mô hình hóa cấu trúc 45

1 Quá trình xây dựng các lớp ứng dụng 45

a Khởi tạo danh sách các lớp ứng viên 45

b Loại bỏ các lớp giả 47

c Đồng nhất các lớp ứng viên trùng lắp 48

d Xác định các danh từ, cụm danh từ có thể là thuộc tính 50

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 51 f Các lớp ứng viên sau quá trình xây dựng 53

2 Mô hình hóa các lớp ứng dụng 53

a Sơ đồ lớp của nhóm người dùng sinh viên 55

b Sơ đồ lớp của nhóm đối tượng giảng viên 58

c Sơ đồ lớp của nhóm đối tượng giáo vụ khoa 60

d Sơ đồ lớp của nhóm đối tượng cán bộ đào tạo 61

e Sơ đồ lớp của nhóm đối tượng quản trị hệ thống 65

II Mô hình hóa hành vi 66

III Xác định mối quan hệ giữa các lớp 70

IV Thiết kế hệ thống 72

1 Thiết kế lớp 72

2 Chuyển đổi đối tượng sang mô hình quan hệ 78

a Chuyển đổi lớp – bảng 78

b Chuyển đổi mối liên kết 78

3 Triển khai hệ thống OCRS 80

4 Giải thuật và độ phức tạp giải thuật 80

XÂY DỰNG VÀ TRIỂN KHAI HỆ THỐNG 83

I Trang chủ hệ thống OCRS 83

1 Hệ thống menu trái 83

2 Hệ thống menu trên 84

3 Khung đăng nhập 84

4 Đếm số người dùng đang truy cập 84

5 Đồng hồ và lịch 84

II Trang màn hình lựa chọn sinh viên 85

III Trang đăng ký học phần 86

IV Trang màn hình lựa chọn giảng viên 87

V Trang màn hình lựa chọn giáo vụ khoa 88

VI Trang màn hình lựa chọn cán bộ đào tạo 89

VII Trang màn hình lựa chọn quản trị hệ thống 91

KẾT LUẬN 92

I Kết quả đạt được 92

1 Về mặt lý thuyết 92

2 Về mặt thực tiễn 92

II Hướng phát triển của đề tài 93

DANH MỤC HÌNH ẢNH

Hình II.1: Các giai đoạn phát triển UML 5

Hình II.2: Phân loại các biểu đồ trong UML 2.0 6

Hình II.3: Sơ đồ cấu trúc mẫu Factory 10

Hình II.4: Sơ đồ cấu trúc mẫu Singleton 11

Hình II.5: Sơ đồ cấu trúc mẫu Strategy 11

Hình II.6: Mô hình ba lớp 12

Hình III.1: Sơ đồ khung cảnh của hệ thống OCRS 18

Hình III.2: Sơ đồ use-case tổng quát về hệ thống [Mức 1] 40

Hình III.3: Sơ đồ use-case của Actor sinh viên [Mức 2] 40

Hình III.4: Sơ đồ use-case của Actor giảng viên [Mức 2] 41

Hình III.5: Sơ đồ use-case của Actor giáo vụ khoa [Mức 2] 41

Hình III.6: Sơ đồ use-case của Actor cán bộ đào tạo [Mức 2] 42

Hình III.7: Sơ đồ use-case của Actor quản trị hệ thống [Mức 2] 43

Hình III.8: Sơ đồ use-case của chức năng đăng nhập vào hệ thống [Mức 3] 43

Hình III.9: Sơ đồ use-case của chức năng đăng xuất khỏi hệ thống [Mức 3] 44

Hình IV.1: Sơ đồ lớp tổng quan hệ thống OCRS 54

Hình IV.2: Sơ đồ lớp của actor SinhViên [Mức 1] 55

Hình IV.3: Sơ đồ lớp mịn dần chức năng HủyHọcPhầnĐãĐăngKý [Mức 2] 55

Hình IV.4: Sơ đồ lớp mịn dần chức năng ĐăngKýHọcPhần [Mức 2] 56

Hình IV.5: Sơ đồ lớp mịn dần chức năng ThayĐổiPassword [Mức 2] 56

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] 56

Hình IV.7: Sơ đồ chức năng XemLịchThi [Mức 2] 57

Hình IV.8: Sơ đồ chức năng XemThờiKhóaBiểu [Mức 2] 57

Hình IV.9: Sơ đồ chức năng XemThôngTinCáNhân [Mức 2] 57

Hình IV.10: Sơ đồ chức năng KiểmTraHọcPhầnĐăngKý [Mức 3] 58

Hình IV.11: Sơ đồ lớp của actor GiảngViên [Mức 1] 58

Hình IV.12: Sơ đồ chức năng XemLịchDạy [Mức 2] 59

Hình IV.13: Sơ đồ chức năng XemThôngTinCáNhân [Mức 2] 59

Hình IV.14: Sơ đồ chức năng XemDanhSáchSinhViên [Mức 2] 59

Hình IV.15: Sơ đồ chức năng ThayĐổiPassword [Mức 2] 59

Hình IV.16: Sơ đồ lớp của actor GiáoVụKhoa [Mức 1] 60

Hình IV.17: Sơ đồ chức năng XemDanhSáchSinhViên [Mức 2] 60

Hình IV.18: Sơ đồ chức năng ThayĐổiPassword [Mức 2] 60

Hình IV.19: Sơ đồ chức năng XemBáoCáoThốngKê [Mức 2] 61

Hình IV.20: Sơ đồ chức năng XemThôngTinCáNhân [Mức 2] 61

Hình IV.21: Sơ đồ lớp của actor CánBộĐàoTạo [Mức 1] 61

Hình IV.22: Sơ đồ chức năng GiớiHạnĐăngKý [Mức 2] 62

Hình IV.23: Sơ đồ chức năng XemBáoCáoThốngKê [Mức 2] 62

Hình IV.24: Sơ đồ chức năng ThayĐổiPassword [Mức 2] 62

Hình IV.25: Sơ đồ chức năng TạoDữLiệu [Mức 2] 63

Hình IV.26: Sơ đồ chức năng Xóa/KhóaDữLiệu [Mức2] 63

Hình IV.27: Sơ đồ chức năng XemThôngTin [Mức 2] 64

Hình IV.28: Sơ đồ chức năng CậpNhậtThôngTin [Mức 2] 64

Hình IV.29: Sơ đồ chức năng CậpNhậtĐiểm [Mức 2] 65

Hình IV.30: Sơ đồ lớp của actor QuảnTrịHệThống [Mức 1] 65

Hình IV.31: Sơ đồ lớp chức năng ThayĐổiPassword [Mức 2] 66

Hình IV.32: Sơ đồ lớp chức năng XemThôngTinCáNhân [Mức 2] 66

Hình IV.33: Sơ đồ hoạt động của actor sinh viên 67

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 68

Hình IV.35: Sơ đồ trình tự đăng ký học phần của sinh viên 69

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ý 70

Hình IV.37: Sơ đồ lớp tổng quát hệ thống OCRS [Hướng nhìn Logic] 71

Hình IV.38: Các ký hiệu minh họa phạm vi truy cập 72

Hình IV.39: Mô hình ba lớp của nhóm người dùng sinh viên 73

Hình IV.40: Mô hình ba lớp của nhóm người dùng giảng viên 74

Hình IV.41: Mô hình ba lớp của nhóm người dùng giáo vụ khoa 75

Hình IV.42: Mô hình ba lớp của nhóm người dùng cán bộ đào tạo 76

Hình IV.43: Mô hình ba lớp của nhóm người dùng quản trị hệ thống 77

Hình IV.44: Lược đồ cơ sở dữ liệu quan hệ 79

Hình IV.45: Sơ đồ triển khai của hệ thống OCRS 80

Hình V.1: Trang chủ hệ thống OCRS 83

Hình V.2: Trang màn hình lựa chọn sinh viên 85

Hình V.3: Trang đăng ký học phần 86

Hình V.4: Trang màn hình lựa chọn giảng viên 87

Hình V.5: Trang màn hình lựa chọn giáo vụ khoa 88

Hình V.6: Trang màn hình lựa chọn cán bộ đào tạo 89

Hình V.7: Trang màn hình lựa chọn quản trị hệ thống 91

DANH MỤC BẢNG

Bảng II.1: Các phần tử mô hình trong UML 8

Bảng IV.1: Các danh từ đồng nhất 48

Bảng V.1: Hệ thống menu trái của trang chủ 84

Bảng V.2: Hệ thống menu trên của trang chủ 84

Bảng V.3: Hệ thống menu trái trang màn hình lựa chọn sinh viên 85

Bảng V.4: Hệ thống menu trái trang màn hình lựa chọn giảng viên 87

Bảng V.5: Hệ thống menu trái trang màn hình lựa chọn giáo vụ khoa 88

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 90

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 91

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ụ

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

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í

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

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

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

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ênmô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áctrườ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ànhviên của Đại học Đà Nẵng đã và đang triển khai để đưa vào thử nghiệm các hệ thống chophé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ũngnhư 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ữngvấ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 ramộ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 chosinh 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ọncá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ênchủ 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ĐTgiả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ầnthiế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ủasinh 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 đượctin 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à đangphát triển như vũ bão hiện nay

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

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êucầ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ểnkhai 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 đangthay đổ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áckhá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ựachọ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à sinhviê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ộcvà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ố sinhviê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ớphọ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ọcphầ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ờigian 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ủyhọ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ầnmớ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ầnTù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ặchai 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úchọ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í chomỗ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ạytrong 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

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ý 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 độngqua 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ượclạ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ọcphầ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ọcphầ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

 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ơ đồ trongmỗ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

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ươngtrì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à chophé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ảomật hiệu quả

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

PHẦN II

CƠ SỞ LÝ THUYẾT

I Ngôn ngữ mô hình hóa UML

1 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ìnhhó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 đốitượ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ầnphả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 typhầ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ápBooch 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ộtphương pháp hợp nhất, đánh dấu cho sự ra đời của ngôn ngữ UML

2 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ácchứ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

3 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ồmhướ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

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

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 hainhó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ảnUML 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ớingữ 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ácxem 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ơ đồ

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

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à đượcxem 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 UMLdiễ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ộtchuỗ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ộtgiá trị đến với một tác nhân cụ thể

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

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ácthuộ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ớilớ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…

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ểnthị giữa các lớp với nhau Nó còn dùng để biểuthị cho một tập các dữ liệu liên quan nào đó

Hoạt động: đặc trưng cho khả năng hoạt động

của một quá trình nào đó

tác nhân và một use-case, hoặc giữa các lớp

một phần tử trong một phương thức nào đó vớimột phần tử khác

các lớp thành phần khác, không bắt buộc phảiđầy đủ

thừa kế, tức một lớp có thể thừa kế từ một lớpkhác về cả thuộc tính và phương thức

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ộtgiao diện

19 Quan hệ cấu thành: biểu thị cho một lớp

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ếthoà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 ưumộ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ưngkhả 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ỏitrướ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

Cơ sở lý thuyết

5 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ởiOMG-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ểnphầ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áttriể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ổngquá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àythườ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 đặtphầ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ămPattern 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.

2 Đị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ộtngữ 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ầnmề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ạnphá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 choviệ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ụngnhằ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ụngcao Đ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 đốitượng

3 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ôngdụ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àochi 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à khinà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

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áclự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

 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ácmẫ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

5 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ố trongcá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ụngcá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 đốitượ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ậpcá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 chomỗ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 đượctạ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

Cơ sở lý thuyết

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ủamẫ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ọichươ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ẻ đốitượng được tạo ra

Hình II.4: Sơ đồ cấu trúc mẫu Singleton

Trong sơ đồ này, thành phần static dùng để định nghĩa một phương thức tĩnh để người sử

dụng truy xuất đến thể hiện duy nhất của nó, phương thức này sẽ tạo mới hay trả về mộtthực thể tương ứng tùy vào tình huống cụ thể tương ứng

Áp dụng: hệ thống OCRS là một ứng dụng Web, vì vậy số lượng người truy cập vào hệ

thống phải được truy xuất toàn cục

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

Hình II.5: Sơ đồ cấu trúc mẫu Strategy

Trong sơ đồ này, phần tử Strategy định nghĩa giao tiếp cho tất cả các lớp thể hiện giải thuật ConreteStrategy hiện thực interface 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ý, còn tại thời điểm run-time nó được cung cấp một đối tượnggiải thuật cụ thể thay thế cho đối tượng Strategy Có thể cung cấp con trỏ pointer chophép Strategy truy xuất dữ liệu của Context – chính bản thân của đối tượng Context

Áp dụng: được dùng để giải quyết việc lựa chọn các hình thức hiển thị khác nhau nhưng

giống về cấu trúc, của cùng một trang web

III Mô hình ba lớp

Trong phát triển ứng dụng, để dễ quản lý các thành phần của hệ thống, cũng như không bịảnh hưởng bởi các thay đổi, người ta hay nhóm các thành phần có cùng chức năng lại vớinhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnhhưởng lẫn nhau Ví dụ trong một công ty có nhiều phòng ban, mỗi phòng ban sẽ chịu tráchnhiệm về một công việc cụ thể, phòng này không được can thiệp vào công việc nội bộ củaphòng kia

Cơ sở lý thuyết

Trong phát triển phần mềm, người ta cũng áp dụng cách phân chia chức năng này Chúng

ta đã từng nghe nói đến thuật ngữ kiến trúc đa tầng/nhiều lớp, mỗi lớp sẽ thực hiện một chứcnăng nào đó, trong đó mô hình ba lớp là phổ biến nhất, bao gồm Presentation, Business Logic,

và Data Access Các lớp này sẽ giao tiếp với nhau thông qua các dịch vụ mà mỗi lớp cung cấp

để tạo nên ứng dụng, lớp này cũng không cần biết bên trong lớp kia làm gì mà chỉ cần biết lớpkia cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi

Hình II.6: Mô hình ba lớp

1 Presentation Layer

Lớp này làm nhiệm vụ giao tiếp với người dùng cuối để thu thập dữ liệu và hiển thị kếtquả/dữ liệu thông qua các thành phần trong giao diện người sử dụng Lớp này sẽ sử dụng cácdịch vụ do lớp Business Logic cung cấp Trong Net thì bạn có thể dùng Windows Forms,ASP.Net hay Mobile Forms để hiện thực lớp này

Trong lớp này có 2 thành phần chính là User Interface Components và User InterfaceProcess Components:

 UI Components: là những phần tử chịu trách nhiệm thu thập và hiển thị thông tin cho

người dùng cuối Trong ASP.Net thì những thành phần này có thể là các TextBox, cácButton, DataGrid v.v

 UI Process Components: là thành phần chịu trách nhiệm quản lý các qui trình chuyển

đổi giữa các UI Components Ví dụ chịu trách nhiệm quản lý các màn hình nhập dữliệu trong một loạt các thao tác định trước như các bước trong một Wizard v.v

2 Business Logic Layer

Lớp này thực hiện các nghiệp vụ chính của hệ thống, sử dụng các dịch vụ do lớp DataAccess cung cấp, và cung cấp các dịch vụ cho lớp Presentation Lớp này cũng có thể sử dụngcác dịch vụ của các nhà cung cấp thứ 3 (3rd parties) để thực hiện công việc của mình(ví dụnhư sử dụng dịch vụ của các cổng thanh toán trực tuyến như VeriSign, Paypal )

Trong lớp này có các thành phần chính là Business Components, Business Entities vàService Interface:

Cơ sở lý thuyết

 Service Interface: là giao diện lập trình mà lớp này cung cấp cho lớp Presentation sử

dụng Lớp Presentation chỉ cần biết các dịch vụ thông qua giao diện này mà không cầnphải quan tâm đến bên trong lớp này được hiện thực như thế nào

 Business Entities: là những thực thể mô tả những đối tượng thông tin mà hệ thống xử

lý Các business entities này cũng được dùng để trao đổi thông tin giữa lớpPresentation và lớp Data Access

 Business Components: là những thành phần chính thực hiện các dịch vụ mà Service

Interface cung cấp, chịu trách nhiệm kiểm tra các ràng buộc logic, các qui tắc nghiệp

vụ, sử dụng các dịch vụ bên ngoài khác để thực hiện các yêu cầu của ứng dụng

3 Data Access Layer

Lớp này thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của ứng dụng.Thường lớp này sẽ sử dụng các dịch vụ của các hệ quản trị cơ sở dữ liệu như SQL Server,Oracle v.v để thực hiện nhiệm vụ của mình

Trong lớp này có các thành phần chính là Data Access Logic, Data Sources, ServiveAgents:

 Data Access Logic components:(DALC) là thành phần chính chịu trách nhiệm lưu trữ

vào và truy xuất dữ liệu từ các nguồn dữ liệu - Data Sources như RDMBS, XML, Filesystems v.v Trong Net, các DALC này thường được hiện thực bằng cách sử dụngthư viện ADO.Net để giao tiếp với các hệ cơ sở dữ liệu hoặc sử dụng các O/RMapping Frameworks để thực hiện việc ánh xạ các đối tượng trong bộ nhớ thành dữliệu lưu trữ trong cơ sở dữ liệu

 Service Agents: là những thành phần trợ giúp việc truy xuất các dịch vụ bên ngoài một

cách dễ dàng và đơn giản như truy xuất các dịch vụ nội tại

IV Vấn đề bảo mật trong ASP.Net

Sự quan trọng của bảo mật không lời nào nói hết Nếu không đầu tư thời gian cũng như tàinguyên thích đáng cho nhiệm vụ này có thể dẫn tới những kết quả không mong muốn như thấtthoát dữ liệu, sai hỏng trong thực thi ứng dụng hoặc ứng dụng bị chiếm quyền điều khiểnv.v… Vì vậy, quan tâm vấn đề bảo mật ngay từ khi bắt đầu xây dựng ứng dụng cũng là điềuhết sức quan trọng

Bảo mật vốn là chủ đề cực kỳ phức tạp và bảo mật trong ASP.Net cũng không phải ngoại

lệ Trong phần này, chúng tôi sẽ giới thiệu một số phương thức giúp đảm bảo an toàn cho cácứng dụng ASP.Net mà không bàn về bảo mật mạng, bảo mật máy chủ và bảo mật cơ sở hạtầng ASP.Net Nói như thế không có nghĩa là các chủ đề đó không quan trọng Ngược lại, nếukhông cấu hình hỗ trợ bảo mật phù hợp cho máy chủ và cơ sở hạ tầng mạng, những gì cốgắng thực hiện để đảm bảo an toàn cho ứng dụng ASP.Net thông qua các công cụ NetFramework cung cấp sẽ trở nên vô ích

Đảm bảo an toàn trong truy cập ứng dụng hay truy cập tài nguyên thuộc ứng dụng tập

trung vào hai quá trình: chứng thực (authentication) và xác thực (authorization) Chúng ta sẽ

quan tâm tới ba phương thức chứng thực mà ASP.Net cung cấp: Windows, Form và Passport.Còn với xác thực, chúng ta sẽ quan tâm chủ yếu với hai cơ chế: sử dụng đường dẫn URL và

sử dụng danh sách điều khiển truy cập ACL (Access Control List), ngoài ra còn có cơ chế xác

thực Programmatic

1 Các phương thức chứng thực

Chứng thực là quá trình nhận dạng người hay chương trình có yêu cầu Nó không gánquyền truy cập tài nguyên, là chức năng của cơ chế xác thực, mà chỉ kiểm tra định danh đãbiết để đưa ra quyết định xem liệu có chấp nhận yêu cầu này hay không Nói một cách đơngiản, chứng thực trả lời cho câu hỏi: “Bạn là ai?”

Cơ sở lý thuyết

Trong ứng dụng ASP cổ điển, có hai phương thức chứng thực chính: một là dựa trên IIS đểchứng thực người dùng theo tài khoản Windows, sau đó sử dụng các danh sách điều khiểntruy cập để hoàn tất quá trình chứng thực; hai là đưa ra kiểu chứng thực riêng, so sánh để

khớp với thông tin chứng thực người dùng lưu trữ trên máy chủ (có thể nằm trong Microsoft Active Directory) Mỗi phương thức đều có những điểm hạn chế riêng ASP.Net cung cấp ba

cơ chế chứng thực:

 Chứng thực Windows: cung cấp tính năng tương tự như chứng thực IIS trong ASP cổ

điển, tuy nhiên cũng có một số điểm khác nhau quan trọng Chứng thực Windows làmviệc cùng với chứng thực tích hợp sẵn trong IIS và dùng định danh do chứng thực IIScung cấp để thực hiện quá trình chứng thực

 Chứng thực Forms: chủ yếu được dùng cho cơ chế chứng thực riêng Chứng thực

Form hỗ trợ trang đăng nhập chung, cung cấp nhiều tuỳ chọn về lưu trữ thông tinchứng thực, từ cơ sở dữ liệu với định dạng XML, file cấu hình và một số phương thứctrợ giúp để quản lý các hoạt động chứng thực Cơ chế chứng thực này hầu hết đượcdùng cho các trường hợp liên quan đến Internet

 Chứng thực Passport: Chứng thực Passport cho phép một người dùng có một mật

khẩu duy nhất trong khi có thể đăng nhập (địa chỉ e-mail được gắn với tài khoảnPassport của họ) vào nhiều ứng dụng hay website Điều này giúp đơn giản quá trìnhđăng nhập của người dùng và giảm bớt công việc quản trị khi bảo trì tài khoản ngườidùng Để sử dụng được chứng thực Passport trong ASP.Net chúng ta phải download

và cài đặt Passport SDK

Trong các phương thức chứng thực trên phương thức chứng thực Forms được đánh giá làphương thức hữu ích nhất trong ba phương thức ASP.Net cung cấp Nó cung cấp một cơ sở hạtầng rất linh hoạt cho các ngữ cảnh bảo mật tự người dùng định nghĩa Khi một ứng dụngđược cấu hình để dùng chứng thực Forms, các yêu cầu về tài nguyên được bảo vệ sẽ đượcchuyển tới một trang đăng nhập cụ thể

Cơ chế chứng thực ASP.Net thường được cấu hình ở mức máy, dùng file machine.confighoặc mức ứng dụng, dùng file web.config Chúng ta có thể cấu hình các thiết lập chứng thực

sử dụng phần tử <authentication> cùng với các thuộc tính và phần tử con của nó.

Các thiết lập chứng thực không được phép cấu hình bên dưới mức ứng dụng Tức là nếumuốn áp dụng quy chế chứng thực cho một thư mục con của một ứng dụng, chúng ta cần phảicấu hình nó như một ứng dụng trong IIS Các thiết lập xác thực không gặp phải hạn chế này

2 Các phương thức xác thực

Xác thực là quá trình xác định xem liệu người dùng đã được nhận dạng trong quá trình

chứng thực có được phép truy cập tài nguyên họ đang yêu cầu không hay phải thực hiện thêmhành động nào khác (ví dụ như update dữ liệu cho cơ sở dữ liệu rồi mới được truy cập) Quátrình chứng thực trả lời cho câu hỏi: “Bạn là ai?”, còn quá trình xác thực trả lời cho câu hỏi:

“Bạn có được phép làm điều đó hay không?”

Xác thực trong ASP.Net có ba hình thức: xác thực sử dụng Danh sách điều khiển truy cập,xác thực sử dụng đưòng dẫn URL và xác thực programmatic:

 Xác thực ACL: danh sách điều khiển truy cập được dùng trong Windows NT,

Windows 2000, Windows XP và Windows Sever 2003 để kiểm soát truy cập tàinguyên hệ thống như các tệp, thư mục trong hệ thống file NTFS Bạn có thể gán một

số tài nguyên nhất định vào ACL cho tài khoản người dùng hoặc một nhóm ngườidùng Windows để cho phép họ truy cập tài nguyên hoặc xác định kiểu truy cập (đọc,ghi, thay đổi…) được phép dùng Xác thực ACL chủ yếu được dùng với chứng thựcWindows trong ASP.Net IIS sử dụng nhận dạng người dùng đã qua chứng thực để

Cơ sở lý thuyết

thực hiện các kiểm tra ACL và cũng có thể đưa ra các yêu cầu về tài nguyên được bảo

vệ bởi ACL bằng cách dùng ngữ cảnh bảo mật của người dùng

 Xác thực URL: chế độ xác thực URL sử dụng các thẻ <allow> và <deny> của phần

tử cấu hình <authorization> (trong file machine.config hoặc web.config) để kiểm soát

truy cập file, thư mục bên trong ứng dụng Truy cập có thể được cho phép hoặc bị từchối dựa trên tên người dùng (username), vai trò (role) và phương thức HTTP dùng đểyêu cầu tài nguyên

 Xác thực Programmatic: chúng ta có thể thực hiện các kiểm tra programmatic tại thời

gian chạy bằng cách xác định xem liệu người dùng có được phép thực hiện một hànhđộng nào đó hay không Cách chủ yếu để thực hiện điều này là thông qua phương thứcIsInRole, được định nghĩa bởi giao diện Iprincipal và có thể truy cập từ thuộc tínhUser của lớp Page

Phần cấu hình các phương thức chứng thực và các cơ chế xác thực chúng tôi không trìnhbày tại đây, các bạn có thể tham khảo cách thức cấu hình tại các tài liệu tham khảo đã nêu ởcuối đồ án này

 Ý nghĩa: UDD là mã khoa quản lý học phần; MMM là số thứ tự học phần trong khoa;

Z là đặc thù học phần, trong đó 0 – học phần chung toàn trường, 1 – học phần chungtoàn hệ, kể cả Cao Đẳng và Trung Cấp, 2 – học phần chung cho một số ngành khácnhau và 3 – học phần chuyên ngành

5 Mã lớp sinh hoạt

 Ký hiệu:

 Ý nghĩa: UDD là mã khoa quản lý; NS là mã ngành; KK là mã khóa học, lấy hai chữ

số cuối của niên khóa bởi vì vòng đời phần mềm có thể vài chục năm; L là số thứ tựlớp trong một khoa của niên khóa đó, và bắt đầu từ 1 9; H là mã hình thức đào tạo,trong đó 1 – chính quy, 2 – vừa học vừa làm; C là mã cấp đào tạo, với 1 – Đại học, 2 –Cao Đẳng, 3 – Trung Cấp

sẽ rất khó cho quá trình xây dựng cũng như sử dụng hệ thống

Được sự đồng ý của thầy Trần Nguyên Vinh cùng các thầy cô ở phòng Đào tạo & Công tácsinh viên sau khi chúng em trình bày rõ vấn đề này, mã lớp học phần bây giờ sẽ gồm 13 ký tự,thêm một ký tự biểu thị cho loại học kỳ nào trong năm (1 – Học kỳ 1; 2 – Học kỳ 2; 3 – Học

kỳ hè) và hai ký tự biểu thị cho niên khóa tổ chức lớp học phần đó, ví dụ 02 có nghĩa là niênkhóa 2002-2003

Đặc tả chức năng hệ thống

 Ý nghĩa: UDDNS là mã ngành của sinh viên; L là số thứ tự lớp; KK là khóa học; H là

mã hình thức đào tạo, trong đó 1 – chính quy, 2 – vừa học vừa làm; C là cấp đào tạo,với 1 – Đại học, 2 – Cao Đẳng, 3 – Trung Cấp; SS là số thứ tự sinh viên trong lớp

II Chức năng các Actor tham gia vào hệ thống

Qua quá trình tìm hiểu phân tích hệ thống quản lý đăng ký tín chỉ thực tế tại trường ĐạiHọc Bách Khoa Đà Nẵng, chúng em nhận thấy có tất cả sáu Actor có tác động đến hệ thống

và mỗi Actor có những yêu cầu và chức năng khác nhau

1 Người dùng chung

a) Người dùng chung

b) Xem các thông tin về các phòng ban, các khoa trong trường

c) Xem thông tin về các cán bộ nhân viên trong trường

d) Xem các thông báo, tin tức của các khoa, phòng ban cũng như của trường

e) Xem các thông tin liên quan, lỗi khi truy xuất hay các trang của các ngoại lệ

8 Sinh viên

a) Đăng nhập - Đăng xuất

b) Xem thông tin cá nhân của sinh viên

c) Đăng ký học phần, hủy học phần đã đăng ký

d) Xem lịch thi

e) Xem thời khóa biểu

f) Xem danh sách những học phần có điểm thi đạt trên 5

g) Xem hướng dẫn đăng ký học phần

h) Thay đổi Password

9 Giảng viên

a) Đăng nhập - Đăng xuất

b) Xem thông tin giảng viên

c) Xem danh sách sinh viên (Lớp giảng dạy & Lớp chủ nhiệm)

d) Xem lịch dạy

e) Thay đổi Password

10 Giáo vụ khoa

a) Đăng nhập - Đăng xuất

b) Xem các báo cáo thống kê

c) Xem danh sách sinh viên theo ngành (Lớp sinh hoạt & Lớp học phần)

d) Thay đổi Password

11 Cán bộ đào tạo

a) Đăng nhập - Đăng xuất

b) Quản lý các tài khoản giảng viên và sinh viên

c) Xem danh sách sinh viên toàn trường (Lớp sinh hoạt & Lớp học phần)

d) Tạo thời khóa biểu dự kiến, xếp lịch thi

e) Giới hạn khoảng thời gian đăng ký, giới hạn số tín chỉ Min/Max

f) Xem xét, tổ chức các lớp học phần do sinh viên đề nghị

g) Xem các báo cáo thống kê

Đặc tả chức năng hệ thống

h) Quản lý đào tạo tín chỉ, bao gồm chương trình đào tạo và học phần

i) Nhập và cập nhật điểm cho sinh viên

j) Xem thông tin cá nhân cán bộ đào tạo

k) Thay đổi Password

12 Quản trị hệ thống

a) Đăng nhập - Đăng xuất

b) Quản lý tài khoản giáo vụ khoa và cán bộ đào tạo

c) Cấu hình hệ thống, duy trì hệ thống

d) Xem thông tin cá nhân quản trị hệ thống

e) Thay đổi Password

Hình III.1: Sơ đồ khung cảnh của hệ thống OCRSIII Xây dựng kịch cảnh cho các UseCase

Thao tác với trình duyệt web

Yêu cầu xem các thông tin về phòng ban, khoa trong trường

Thông tin vào:

Kiểm tra hợp lệ:

:HỆ THỐNG ĐĂNG KÝ TÍN

CHỈOCRS

yê

u cầ

u xe

m th ôn

g tin ch un g

thời khóa biểu

cá nhân

lịch thi

cá nhân

Si n h V iê n

Gi ản g Vi ên

đ ă n g k ý m ô n d ạ y

l ị c h d ạ y

Giáo VụK hoa

x u ấ t r a b á o c á o

CánB ộĐào Tạo

NgườiDùn gChung

đ ă n g k ý h ọ c p h ầ n

h i ể n t h ị t h ô n g t i n

thời khóa biểu

dự kiến

gi

ới h ạ

n đ ă n

g k ý

thời khóa biểu

dự kiến

QuảnTrị HệThống

c ấ u h ì n h h ệ t h ố n g

d u y t r ì h ệ t h ố n g

x u ấ t r a b á o c á o

Đặc tả chức năng hệ thống

Thông tin ra:

Trả về trang thông tin các phòng ban

Thao tác với trình duyệt web

Yêu cầu xem các thông tin về cán bộ nhân viên trong trường

Thông tin vào:

Kiểm tra hợp lệ:

Thông tin ra:

Trả về trang thông tin về các cán bộ nhân viên trong trường

Thao tác với trình duyệt web

Yêu cầu xem các thông báo, tin tức của khoa, trường

Thông tin vào:

Kiểm tra hợp lệ:

Thông tin ra:

Trả về trang thông tin về các thông báo, tin tức của khoa, trường

Đặc tả chức năng hệ thống

Thông tin vào:

Username (mã sinh viên theo các quy tắc đặt mã đã nêu)

Password (mặc định : “svbkdn!”)

Kiểm tra hợp lệ:

So khớp Username & Password trong cơ sở dữ liệu với thông tin Username &Password nhập vào

Thông tin ra:

Trả về trang màn hình lựa chọn của sinh viên nếu Username & Pasword hợp lệ.Trả về trang đăng nhập nếu Username & Password không hợp lệ

Yêu cầu xem các thông tin cá nhân sinh viên

Thông tin vào:

Username

Kiểm tra hợp lệ:

Thông tin ra:

Hiển thị trang thông tin cá nhân của sinh viên

Yêu cầu đăng ký học phần cho một học kỳ

Xem danh sách các học phần, bao gồm các học phần để đăng ký trong học kỳnày và học phần còn nợ, học phần chưa đăng ký của các học kỳ trước (học phầnbắt buộc, học phần tự chọn bắt buộc, học phần tự chọn tự do)

Đưa ra học phần đề nghị mà sinh viên muốn học trong học kỳ này

Chọn các lớp học phần tương ứng phù hợp của từng học phần

Submit

Thông tin vào:

Kiểm tra khoảng thời gian hợp lệ cho phép sinh viên đăng ký.

Kiểm tra học kỳ được phép đăng ký

Kiểm tra tính duy nhất của các lớp học phần & học phần đã đăng ký

Kiểm tra tính duy nhất của các học phần đề nghị

Kiểm tra số tín chỉ được phép đăng ký tối đa (mặc định là ba mươi tín chỉ).Kiểm tra số lượng sinh viên đăng ký tối đa của một lớp học phần

Kiểm tra điều kiện học trước, tiên quyết và song hành của một học phần

Thông tin ra:

Cập nhật các học phần cùng các lớp học phần sinh viên đã đăng ký trong cơ sở

Hoạt động:

Yêu cầu đăng ký học phần cho một học kỳ

Xem danh sách các học phần đã đăng ký

Khoảng thời gian cho phép đăng ký

Thông tin ra:

Cập nhật các lớp học phần sinh viên đã đăng ký trong cơ sở dữ liệu

Ngoại lệ:

Đưa ra trang ngoại lệ thay thế, trang giúp đỡ

Các chức năng liên kết:

Yêu cầu xem lịch thi của mỗi kỳ.

Thông tin vào:

Username

Mã học kỳ

Kiểm tra hợp lệ:

Thông tin ra:

Lịch thi của sinh viên theo kỳ

Yêu cầu xem thời khóa biểu

Thông tin vào:

Username

Mã học kỳ

Kiểm tra hợp lệ:

Thông tin ra:

Thời khóa biểu của học kỳ đã chọn

Đặc tả chức năng hệ thống

Thông tin vào:

Username

Kiểm tra hợp lệ:

Thông tin ra:

Danh sách các học phần theo yêu cầu

Hoạt động:

Yêu cầu xem hướng dẫn đăng ký học phần

Thông tin vào:

Kiểm tra hợp lệ:

Thông tin ra:

Hiển thị trang thông tin hướng dẫn sinh viên đăng ký học phần

Yêu cầu thay đổi password

Thông tin vào:

Username

Kiểm tra hợp lệ:

Kiểm tra password hiện tại và so khớp password mới với password mới xácnhận

Thông tin ra:

Thông báo thành công

Ngoại lệ:

Đưa ra trang ngoại lệ thay thế, trang giúp đỡ

Các chức năng liên kết:

Yêu cầu đăng xuất.

Thông tin vào:

Thông tin vào:

Username (mã giảng viên theo các quy tắc đặt mã đã nêu)

Password (mặc định “gvbkdn!” )

Kiểm tra hợp lệ:

So khớp Username & Password trong cơ sở dữ liệu với thông tin Username &Password nhập vào

Thông tin ra:

Trả về trang màn hình lựa chọn của giảng viên nếu Username & Pasword hợplệ

Trả về trang đăng nhập nếu Username & Password không hợp lệ

Đặc tả chức năng hệ thống

Cho phép giảng viên xem những thông tin cá nhân về bản thân

Hoạt động:

Yêu cầu xem các thông tin cá nhân giảng viên

Thông tin vào:

Username

Kiểm tra hợp lệ:

Thông tin ra:

Hiển thị trang thông tin cá nhân của giảng viên, bao gồm các thông tin về bảnthân và gia đình của giảng viên như họ tên, ngày tháng năm sinh…

Yêu cầu xem danh sách các sinh viên

Thông tin vào:

Username

Lớp học phần hoặc lớp sinh hoạt cần xem

Kiểm tra hợp lệ:

Thông tin ra:

Hiển thị danh sách các sinh viên trong lớp đã nhập

Yêu cầu thay đổi password

Thông tin vào:

Username

Kiểm tra hợp lệ:

Kiểm tra password hiện tại và so khớp password mới với password mới xácnhận

Đặc tả chức năng hệ thống

Thông tin ra:

Thông báo thành công

Yêu cầu xem lịch dạy của các lớp học phần theo kỳ

Thông tin vào:

Username

Mã học kỳ

Kiểm tra hợp lệ:

Thông tin ra:

Lịch dạy các lớp học phần của giảng viên

Yêu cầu đăng xuất

Thông tin vào: