Bao Cao Tot Nghiep - Hoan Chinh

5/16/2018 Bao Cao Tot Nghiep - Hoan Chinh - slidepdf.com

http://slidepdf.com/reader/full/bao-cao-tot-nghiep-hoan-chinh 1/116

ĐẠI HỌC ĐÀ NẴNGTRƯỜNG ĐẠI HỌC BÁCH KHOA

KHOA CÔNG NGH THÔNG TINTel. (84-511) 736 949, Fax. (84-511) 842 771

Website: itf.ud.edu.vn, E-mail: [email protected]

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 ĐỨCNGUYỄN THỊ HÀ QUYÊN

LỚP : 02T1CBHD : ThS. GV. TRƯƠNG NGỌC CHÂU

ĐÀ NẴNG, 06/2007

mailto:itf.ud.edu.vn

mailto:itf.ud.edu.vn



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à kinhnghiệ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ộcbộ môn Công nghệ phần mềm, khoa Công nghệ thông tin, trường Đạihọc Bách khoa Đà Nẵng, người đã hướng dẫn, tạo điều kiện thuận lợivà 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ệpnà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ếnthứ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 đề ...........................................................................................................................1II. 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...............................................................................................................5I. Ngôn ngữ mô hình hóa UML ..............................................................................................5

i. Sự ra đời UML................................................................................................................5

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

iii. 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...................................................................................................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 ..............................................................................................................101. 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 haythự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 đốitượ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ạpsẽ 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 “duynhấ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...............................................................................................................18II. Chức năng các Actor tham gia vào hệ thống .................................................................19

1. Người dùng chung........................................................................................................19

ii. Sinh viên.......................................................................................................................19

iii. Giảng viên...................................................................................................................19

iv. Giáo vụ khoa...............................................................................................................19

v. Cán bộ đào tạo..............................................................................................................19

vi. Quản trị hệ thống.........................................................................................................20

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

1. NgườiDùngChung........................................................................................................20a)Xem_Thông_Tin_Các_Phòng_Ban/Khoa................................................................20

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

c)Xem_Thông_Báo_Tin_Tức......................................................................................21

ii. SinhViên.......................................................................................................................21

a)Đăng_Nhập...............................................................................................................21

d)Xem_Thông_Tin_Cá_Nhân_Sinh_Viên..................................................................22

e)Đăng_Ký_Học_Phần................................................................................................22

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

g)Xem_Lịch_Thi..........................................................................................................24

h)Xem_Thời_Khóa_Biểu.............................................................................................24

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

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

k)Thay_Đổi_Password.................................................................................................25

l)Đăng_Xuất.................................................................................................................26

iii. GiảngViên...................................................................................................................26

a)Đăng_Nhập...............................................................................................................26

b)Xem_Thông_Tin_Cá_Nhân_Giảng_Viên................................................................26c)Xem_Danh_Sách_Sinh_Viên...................................................................................27

d)Thay_Đổi_Password.................................................................................................27



e)Xem_Lịch_Dạy.........................................................................................................28

f)Đăng_Xuất.................................................................................................................28

iv. GiáoVụKhoa................................................................................................................28

a)Đăng_Nhập...............................................................................................................28

b)Xem_Báo_Cáo_Thống_Kê.......................................................................................29

c)Xem_Danh_Sách_Sinh_Viên...................................................................................29d)Thay_Đổi_Password.................................................................................................30

e)Đăng_Xuất................................................................................................................30

v. CánBộĐàoTạo..............................................................................................................31

a)Đăng_Nhập...............................................................................................................31

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

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

d)Quản_Lý_Lớp_Học..................................................................................................32

e)Quản_Lý_Phòng_Học...............................................................................................33

f)Quản_Lý_Học_Phần.................................................................................................33g)Xem_Danh_Sách_Sinh_Viên...................................................................................34

h)Xếp_Lịch_Thi...........................................................................................................34

i)Giới_Hạn_Đăng_Ký..................................................................................................35

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

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

l)Xem_Báo_Cáo_Thống_Kê.......................................................................................36

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

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

o)Thay_Đổi_Password.................................................................................................37 p)Đăng_Xuất................................................................................................................38

vi. QuảnTrịHệThống........................................................................................................38

a)Đăng_Nhập...............................................................................................................38

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

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

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

e)Thay_Đổi_Password.................................................................................................40

f)Đăng_Xuất.................................................................................................................41

IV. Sơ đồ use-case ...............................................................................................................41

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

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

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

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

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

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

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

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

ii. Mô hình hóa các lớp ứng dụng....................................................................................56



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

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 .......................................................................................................69III. Xác định mối quan hệ giữa các lớp ...............................................................................73

IV. Thiết kế hệ thống ...........................................................................................................75

1. Thiết kế lớp...................................................................................................................75

ii. Chuyển đổi đối tượng sang mô hình quan hệ..............................................................83

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

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

iii. Triển khai hệ thống OCRS.........................................................................................86

iv. Giải thuật và độ phức tạp giải thuật............................................................................86

XÂY DỰNG VÀ TRIỂN KHAI HỆ THỐNG.....................................................................89I. Trang chủ hệ thống OCRS ................................................................................................89

1. Hệ thống menu trái.......................................................................................................89

ii. Hệ thống menu trên......................................................................................................90

iii. Khung đăng nhập........................................................................................................90

iv. Đếm số người dùng đang truy cập..............................................................................90

v. Đồng hồ và lịch............................................................................................................90

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

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

IV. Trang màn hình lựa chọn giảng viên ............................................................................93V. Trang màn hình lựa chọn giáo vụ khoa ..........................................................................94

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

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

98

KẾT LUẬN..............................................................................................................................99

I. Kết quả đạt được ...............................................................................................................99

1. Về mặt lý thuyết...........................................................................................................99

ii. Về mặt thực tiễn...........................................................................................................99

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



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..................................................................7

...................................................................................................................................................11Hì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............................................................20

...................................................................................................................................................42

...................................................................................................................................................42

...................................................................................................................................................45

...................................................................................................................................................57

...................................................................................................................................................58

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

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

...................................................................................................................................................43

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

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

...................................................................................................................................................44

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

...................................................................................................................................................45

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

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

...................................................................................................................................................46

Hình III.9: Sơ đồ use-case của chức năng đăng xuất khỏi hệ thống [Mức 3].................46Hình IV.1: Sơ đồ lớp tổng quan hệ thống OCRS................................................................57

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

...................................................................................................................................................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

...................................................................................................................................................59

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

...................................................................................................................................................59

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

...................................................................................................................................................59Hì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



...................................................................................................................................................60

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

...................................................................................................................................................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

...................................................................................................................................................62Hì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]................................................62

...................................................................................................................................................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]................................................63...................................................................................................................................................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].................................................64

...................................................................................................................................................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]................................................65

...................................................................................................................................................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]..................................................66

...................................................................................................................................................67Hì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]...............................................67

...................................................................................................................................................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]............................................68

...................................................................................................................................................69Hì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

...................................................................................................................................................70

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

...................................................................................................................................................71

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............71

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

...................................................................................................................................................73Hình IV.36: Sơ đồ trình tự biểu diễn quá trình hủy các học phần đã đăng ký...............73

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

...................................................................................................................................................75

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

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

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

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

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

Hình IV.43: Mô hình ba lớp của nhóm người dùng quản trị hệ thống............................82Hình IV.44: Lược đồ cơ sở dữ liệu quan hệ........................................................................85

...................................................................................................................................................86

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

...................................................................................................................................................89

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

...................................................................................................................................................90

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

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

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

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

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

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



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.......................................................................................51

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

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

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

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

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........................97

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...................98



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ệpXDTLTĐ 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 sơ đồ hợp tác

Communication sơ đồ giao tiếp

State machine sơ đồ máy trạng tháiState 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àiComposite 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ạnPresentation 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ộihọ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à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 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ũ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 ra mộtdanh 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ênthô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ộplạ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 sinhviê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ảngdạ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ữasinh 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ầ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 được tinhọ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áttriển như vũ bão hiện nay.

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ụngthử 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 1



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 đăngký 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ể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áiniệ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ệ Webtiê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óaUML 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 Patterntrong 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ọnhọ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ềukiệ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ý, sinhviê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ỳ đó theokhung 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 trongcá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, sinhviê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ủachú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ượngsinh 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ờ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ầ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ầ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ặ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ú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óabiể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ạy tronghọc kỳ đó. Tuy nhiên hệ thống OCRS không quản lý những vấn đề này, chúng thuộc mộtmodule 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 đầuvào cho những module đó.




Mở đầu

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, tacó 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ữngvấ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ụngmô 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ấytừ 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ốngthự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áiquá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ơ đồ 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ớpvà 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ácdị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à cho phépnhữ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ếtquả đă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ả.

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




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ượnglầ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á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ộ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á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

iii. Các thành phần của UML

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


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ácngô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



PHẦN II

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.




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óiv.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ờikhắ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.xnhư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áytrạ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ể đượcgọi là sơ đồ tuần tự.

b. Phần tử mô hình hóaCá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 ComponentThà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ó.



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ànhphầ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áttương tác

Sơ đồ

trình tự

Sơ đồ

giao tiếp

Sơ đồ

thời khắc




2

Actor

Tác nhân: là một người hoặc một vật, hoặcmộ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 tincù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ểudiễn dưới dạng một hình chữ nhật như một lớpvà khuôn mẫu <<Actor>> cũng phải được xácđịnh cùng với lớp đó.

3Note

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 xemnhư là lời giải thích, nó có thể chứa bất kỳ loạithông tin nào, và sẽ không được UML diễngiải.

4

Use case

Use-case: biểu thị cho một chức năng nguyênvẹ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ạora 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ể.

5Package

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ácthà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ácthuộ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 đốitượ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ới lớp

8 Node Nút : đại diện cho các tài nguyên xử lý hệ thốngnhư 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 đốitượ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 độngvề 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 đó.






11 Trạng thái bắt đầu

12 Trạng thái kết thúc

13

A c tivi ty

Hoạt động : đặc trưng cho khả năng hoạt độngcủ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ộttá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ủamột phần tử trong một phương thức nào đó vớimột phần tử khác.

16 Quan hệ kết tập: cho biết một lớp bao gồm cáclớ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ăngthừ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.

18 Quan hệ nhận thức: biểu thị cho khả năngnhậ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 đượccấ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 UMLiv. 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ủamì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ẫncó 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 ưu mộtquá 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.





v. Sự phát triển và tính ổn định của UMLUML đượ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ể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ểnrấ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âydự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áttham 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ườngkhô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 Patternchuyê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ĩaDP 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ầ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ạn pháttriể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ệcxá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ụ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ụnggiú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 chitiế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.





Consequences: gọi là hệ quả, cho ta thấy việc áp dụng các Solution để giải quyết nhữngProblem có hiệu quả hay không. Nói cách khác, Consequences đặt ra cho ta các lựachọ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ạiErich 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áclớ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 đốitượ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ốiquan 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 đốitượ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á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.

v. Vận dụngTrong 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ácmẫ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ìnhkhở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 đượctạ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ượngConcreteCreator .

Á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ươngtá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áctrang 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ỗingườ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ạora. 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 đó đượctạ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ìnhgọ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.

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 đónggó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ảithuậ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ậtcho 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ượng giảithuật cụ thể thay thế cho đối tượng Strategy. Có thể cung cấp con trỏ pointer cho phépStrategy 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ưnggiố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ới nhauvà phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫnnhau. Ví dụ trong một công ty có nhiều phòng ban, mỗi phòng ban sẽ chịu trách nhiệ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ủa phòng kia.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ức nă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ớp kiacung 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ớp1. 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 chongười dùng cuối. Trong ASP.Net thì những thành phần này có thể là các TextBox, các

Button, 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ệutrong một loạt các thao tác định trước như các bước trong một Wizard v.v...

ii. Business Logic LayerLớ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 Data

Access 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:





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ần

phả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ớp Presentation

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ệpvụ, 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.

iii. Data Access LayerLớ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, Servive Agents:

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ụng thư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/R MappingFrameworks để 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ộtcá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ển v.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ều hết sứcquan 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 ứngdụ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ầngASP.Net. Nói như thế không có nghĩa là các chủ đề đó không quan trọng. Ngược lại, nếu khôngcấ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ựchiện để đảm bảo an toàn cho ứng dụng ASP.Net thông qua các công cụ .Net Framework cungcấ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 trungvào hai quá trình: chứng thực (authentication) và xác thực (authorization). Chúng ta sẽ quantâm tới ba phương thức chứng thực mà ASP.Net cung cấp: Windows, Form và Passport. Cònvớ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ụngdanh sách điều khiển truy cập ACL ( Access Control List ), ngoài ra còn có cơ chế xác thựcProgrammatic.

1. Các phương thức chứng thựcChứ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án quyề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 để đưara 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 đơn giản, chứngthực trả lời cho câu hỏi: “Bạn là ai?”.





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ển truycậ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ớithô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ựcForm hỗ trợ trang đăng nhập chung, cung cấp nhiều tuỳ chọn về lưu trữ thông tin chứngthự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ức trợ 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 được dùng chocá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ẩuduy nhất trong khi có thể đăng nhập (địa chỉ e-mail được gắn với tài khoản Passport củahọ) 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ủangười dùng và giảm bớt công việc quản trị khi bảo trì tài khoản người dùng. Để sử dụngđược chứng thực Passport trong ASP.Net chúng ta phải download và cài đặt PassportSDK.

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 đượccấ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ẽ được chuyể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.

ii. 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êm

hà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, Windows2000, Windows XP và Windows Sever 2003 để kiểm soát truy cập tài nguyên hệ thốngnhư 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ười dù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ực Windows trong ASP.Net.IIS sử dụng nhận dạng người dùng đã qua chứng thực để thực hiện các kiểm tra ACL và








PHẦN III

vii. Mã sinh viên

Ký hiệu:


U D D N S L K K H C S S



Đặ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 Đại HọcBá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ỗiActor có những yêu cầu và chức năng khác nhau.

1. Người dùng chunga) 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ệ.

ii. Sinh viêna) Đă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.

iii. Giảng viêna) Đă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.

iv. Giáo vụ khoaa) Đă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.

v. Cán bộ đào tạoa) Đă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ê.





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.

vi. Quản trị hệ thốnga) Đă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

1. NgườiDùngChunga) Xem_Thông_Tin_Các_Phòng_Ban/Khoa

Mục đích:

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

Hoạt động:

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ầuxem thôngtin chung

thời khóa biểu cá nhân

lịch thi cá nhân

SinhViên

GiảngViên

đăng kýmôn dạy lịch dạy

GiáoVụKhoa

xuất ra báo cáo

CánBộĐàoTạo

NgườiDùngChung

đăng kýhọc phần

hiển thịthông tin

thời khóa biểudự kiến

giới hạnđăng ký

thời khóa biểudự kiến

QuảnTrịHệThống

cấu hìnhhệ thống

duy trìhệ thống

xuất ra báo cáo




Thông tin ra:

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

Ngoại lệ:

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

Tên UseCase:

UseCase_Level1_TongQuat1.

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

Mục đích:

Xem thông tin của các cán bộ nhân viên trong trường.

Hoạt động:


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.

Ngoại lệ:


Tên UseCase:


c) Xem_Thông_Báo_Tin_Tức

Mục đích:

Xem các thông báo, tin tức của nhà trường, ví dụ như thông tin mở một nghànhmới,thông tin về hội thảo du học, hay thông tin về cuộc thi sáng tạo Robocon,…

Hoạt động:


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

Thông tin vào:


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.

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

Tên UseCase:


ii. SinhViêna) Đăng_Nhập

Mục đích:

Sinh viên đăng nhập vào hệ thống.

Hoạt động:

Nhập vào Username & Password.

Submit.





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!”).


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ệ.

Ngoại lệ:


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

Tên UseCase:

UseCase_Level2_SinhVien1.d) Xem_Thông_Tin_Cá_Nhân_Sinh_Viên

Mục đích:

Cho phép sinh viên xem thông tin cá nhân của chính mình, bao gồm những thôngtin về bản thân sinh viên như họ tên, ngày sinh, quê quán…

Hoạt động:

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

Thông tin vào:

Username.


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

Ngoại lệ:



Đăng_Nhập [UseCase_Level2_SinhVien1]

Tên UseCase:

UseCase_Level2_SinhVien2.

e) Đăng_Ký_Học_PhầnMục đích:

Sinh viên đăng ký học phần thông qua hệ thống Internet.

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, bao gồm các học phần để đăng ký trong học kỳ nàyvà 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ần bắ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:





Username.

Mã học kỳ.

Mã các lớp học phần đã chọn.

Mã các học phần đề nghị.


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ở dữliệu.

Đưa ra các lớp học phần mà sinh viên đã đăng ký.

Ngoại lệ:




Tên UseCase:


f) Hủy_Học_Phần_Đã_ChọnMục đích:

Cho phép sinh viên hủy chọn lớp học phần của học phần đã đăng ký để đăng kýlại, bằng cách hủy chọn và chọn lại một lớp học phần khác trong khoảng thời giancho phép.

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

Hủy chọn lớp học phần của học phần đã chọn.

Submit.Thông tin vào:

Username.

Mã học kỳ.

Mã các lớp học phần của các học phần đã hủy chọn.


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.








Tên UseCase:


g) Xem_Lịch_Thi

Mục đích:

Cho phép sinh viên xem lịch thi của các lớp học phần đã đăng ký học theo kỳ.

Hoạt động:

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

Thông tin vào:

Username.

Mã học kỳ.


Thông tin ra:

Lịch thi của sinh viên theo kỳ.Ngoại lệ:




Tên UseCase:


h) Xem_Thời_Khóa_Biểu

Mục đích:

Cho phép sinh viên xem thời khóa biểu theo kỳ.Hoạt động:

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

Thông tin vào:

Username.

Mã học kỳ.


Thông tin ra:

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




Tên UseCase:


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

Mục đích:

Cho phép sinh viên xem các học phần mình đã thi qua.

Hoạt động:Yêu cầu xem danh sách các học phần sinh viên đã thi qua.





Thông tin vào:

Username.


Thông tin ra:

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

Ngoại lệ:




Tên UseCase:


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

Mục đích:

Cho phép sinh viên biết được cách thức để thao tác trên hệ thống, đặc biệt là quytrình khi đăng ký học phần nhằm hạn chế ở mức thấp nhất những sai sót khôngđáng có cho sinh viên.

Hoạt động:

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

Thông tin vào:


Thông tin ra:

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




Tên UseCase:


k) Thay_Đổi_Password

Mục đích:

Cho phép thay đổi password hiện tại.

Hoạt động:Yêu cầu thay đổi password.

Thông tin vào:

Username.


Kiểm tra password hiện tại và so khớp password mới với password mới xác nhậ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:






Tên UseCase:


l) Đăng_Xuất

Mục đích:

Cho phép sinh viên đăng xuất khỏi hệ thống.

Hoạt động:

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

Thông tin vào:

Username.


Thông tin ra:

Trả về trang đăng nhập.

Ngoại lệ:



Tên UseCase:


iii. GiảngViêna) Đăng_Nhập

Mục đích:

Cho phép giảng viên đăng nhập vào hệ thống.

Hoạt động: Nhập vào Username & Password.

Submit.

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!” ).



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ợp lệ.


Ngoại lệ:



Tên UseCase:

UseCase_Level2_GiangVien1.

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

Mục đích:

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.


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…

Ngoại lệ:



Đăng_Nhập [UseCase_Level2_GiangVien1]

Tên UseCase:

UseCase_Level2_GiangVien2.c) Xem_Danh_Sách_Sinh_Viên

Mục đích:

Cho phép giảng viên xem danh sách các lớp học phần hay lớp sinh hoạt do mình phụ trách.

Hoạt động:

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.

Ngoại lệ:




Tên UseCase:

UseCase_Level2_GiangVien3.d) Thay_Đổi_Password

Mục đích:


Hoạt động:

Yêu cầu thay đổi password.

Thông tin vào:

Username.


Kiểm tra password hiện tại và so khớp password mới với password mới xác nhận.Thông tin ra:






Ngoại lệ:




Tên UseCase:


e) Xem_Lịch_Dạy

Mục đích:

Cho phép giảng viên xem lịch dạy của mình trong học kỳ nào đó.

Hoạt độ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.

Ngoại lệ:




Tên UseCase:

UseCase_Level2_GiangVien5.f) Đăng_Xuất

Mục đích:

Cho phép giảng viên đăng xuất khỏi hệ thống.

Hoạt động:


Thông tin vào:

Username.


Thông tin ra:Trả về trang đăng nhập.

Ngoại lệ:




Tên UseCase:


iv. GiáoVụKhoaa) Đăng_Nhập

Mục đích:





Cho phép giáo vụ khoa đăng nhập vào hệ thống.

Hoạt động:


Submit.

Thông tin vào:

Username (mã giáo vụ khoa theo các quy tắc đặt mã đã nêu).

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



Thông tin ra:

Trả về trang màn hình lựa chọn giáo vụ khoa nếu Username & Password hợp lệ.




Tên UseCase:

UseCase_Level2_GiaoVuKhoa1.

b) Xem_Báo_Cáo_Thống_Kê

Mục đích:

Cho phép giáo vụ khoa xem một số báo cáo thống kê, chẳng hạn như về tình hìnhhọc tập chung của sinh viên ở mỗi ngành mỗi khóa, danh sách sinh viên đăng kýchưa đủ số tín chỉ tối thiểu hoặc danh các sinh viên chưa đăng ký…

Hoạt động:

Yêu cầu xem các báo cáo về một vấn đề nào đó.

Submit.

Thông tin vào:

Username.

Loại báo cáo cần xem.


Thông tin ra:

Đưa ra báo cáo cần xem.Ngoại lệ:



Đăng_Nhập [UseCase_Level2_GiaoVuKhoa1]

Tên UseCase:


c) Xem_Danh_Sách_Sinh_Viên

Mục đích:

Cho phép giáo vụ khoa xem danh sách các sinh viên trong một lớp học phần hoặclớp sinh hoạt.

Hoạt động:





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

Thông tin vào:

Username.

Mã lớp học phần hoặc mã lớp sinh hoạt cần xem.


Thông tin ra:

Hiển thị danh sách các sinh viên ứng với mã lớp đã nhập.

Ngoại lệ:




Tên UseCase:


d) Thay_Đổi_PasswordMục đích:


Hoạt động:


Thông tin vào:

Username.



Thông tin ra:Thông báo thành công.

Ngoại lệ:




Tên UseCase:


e) Đăng_Xuất

Mục đích:Cho phép giáo vụ khoa đăng xuất khỏi hệ thống.

Hoạt động:


Thông tin vào:

Username.


Thông tin ra:









Tên UseCase:


v. CánBộĐàoTạoa) Đăng_Nhập

Mục đích:

Cho phép cán bộ đào tạo đăng nhập vào hệ thống.

Hoạt động:


Submit.

Thông tin vào:

Username (mã cán bộ đào tạo theo các quy tắc đặt mã đã nêu).

Password (mặc định “cbdtbkdn!”).Kiểm tra hợp lệ:


Thông tin ra:

Trả về trang màn hình lựa chọn cán bộ đào tạo nếu Username & Pasword hợp lệ.


Ngoại lệ:


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

UseCase_Level2_CanBoDaoTao1.

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

Mục đích:

Cho phép cán bộ đào tạo mới, chỉnh sửa, xóa – khóa tài khoản giảng viên và xemthông tin chi tiết của một giảng viên.

Hoạt động:

Yêu cầu quản lý tài khoản giảng viên.

Thông tin vào:Username.

Mã giảng viên, họ và tên, ngày tháng năm sinh, quê quán, địa chỉ tạm trú, giớitính, tình trạng gia đình, điện thoại liên lạc, email, số chứng minh nhân dân, ngàycấp chứng minh nhân dân, nơi cấp chứng minh nhân dân, thời gian công tác, dântộc, quốc tịch, khoa quản lý, học hàm học vị, chức vụ (có thể kiêm nhiệm đồngthời nhiều chức vụ), tôn giáo, ghi chú.


Kiểm tra định dạng các dữ liệu nhập vào.

Kiểm tra các thông tin vào bắt buộc (mã giảng viên, họ tên…)

Thông tin ra:

Cập nhật cơ sở dữ liệu giảng viên.





Ngoại lệ:



Đăng_Nhập [UseCase_Level2_CanBoDaoTao1]

Tên UseCase:


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

Mục đích:

Cho phép cán bộ đào tạo mới, chỉnh sửa, xóa – khóa tài khoản sinh viên và xemthông tin chi tiết của một sinh viên cụ thể.

Hoạt động:

Yêu cầu quản lý tài khoản sinh viên.

Thông tin vào:

Username.Mã sinh viên, họ và tên, ngày tháng năm sinh, quê quán, địa chỉ tạm trú, giới tính,tình trạng gia đình, điện thoại liên lạc, email, số chứng minh nhân dân, ngày cấpchứng minh nhân dân, nơi cấp chứng minh nhân dân, mức ưu tiên ( dùng trongviệc xét điều kiện học tiếp, hoặc thôi học của một sinh viên), dân tộc, quốc tịch,lớp sinh hoạt, tôn giáo, ghi chú.


Thông tin ra:

Tạo một tài khoản sinh viên trong cơ sở dữ liệu.

Đưa ra thông báo thành công.




Tên UseCase:


d) Quản_Lý_Lớp_Học

Mục đích:

Cho phép cán bộ đào tạo mới, chỉnh sửa thông tin, xóa - khóa một lớp học.

Hoạt động:Yêu cầu quản lý thông tin một lớp học.

Thông tin vào:

Username.

Nếu lớp sinh hoạt, thì cần nhập những thông tin về mã lớp sinh hoạt, tên lớp, giáoviên chủ nhiệm của lớp sinh hoạt đó, số lượng sinh viên trong lớp sinh hoạt,ngành đào tạo, cấp đào tạo, hình thức đào tạo và khóa học.

Nếu lớp học phần, thì cần nhập thông tin về mã lớp học phần, nhóm học phần,năm học, loại học kỳ, số lượng sinh viên, giáo viên phụ trách và khóa học.

Kiểm tra hợp lệ:Kiểm tra định dạng dữ liệu nhập vào.

Kiểm tra các thông tin vào bắt buộc (mã lớp sinh hoạt, mã lớp học phần, …)





Thông tin ra:

Cập nhật cơ sở dữ liệu lớp học phần, lớp sinh hoạt.

Ngoại lệ:




Tên UseCase:


e) Quản_Lý_Phòng_Học

Mục đích:

Cho phép cán bộ đào tạo tạo mới, chỉnh sửa, xóa một phòng học mới.

Hoạt động:

Yêu cầu quản lý phòng học.


Mã phòng học, khu, loại phòng học (phòng học dùng để học lý thuyết hay để thínghiệm, thực hành…), số sinh viên cho phép học tối đa, số sinh viên cho phép thitối đa, trạng thái phòng học, rảnh hay bận khi bước vào một học kỳ mới.


Kiểm tra định dạng dữ liệu nhập vào.

Kiểm tra các thông tin vào bắt buộc (mã phòng học…)

Thông tin ra:

Cập nhật cơ sở dữ liệu phòng học.Ngoại lệ:




Tên UseCase:


f) Quản_Lý_Học_Phần

Mục đích:

Cho phép cán bộ đào tạo tạo mới, chỉnh sửa thông tin, xóa học phần.Hoạt động:

Yêu cầu quản lý học phần.

Thông tin vào:

Username.

Mã học phần, tên học phần, tên viết tắt, số tín chỉ, tổng số tiết học, thuộc khoa,đặc thù học phần (với 0 là học phần chung cho toàn trường, 1 là học phần dùngcho cả hệ Cao Đẳng, Trung Cấp, 2 dùng cho một số ngành, và 3 dùng cho chuyênngành), loại học phần (thuộc loại học phần học lý thuyết hay thực hành, thínghiệm…), loại phòng (nếu là học phần lý thuyết thì cần loại phòng học lý thuyết,

còn nếu là thực hành thì cần loại phòng thực hành…), ghi chú.Kiểm tra hợp lệ:






Kiểm tra các thông tin vào bắt buộc (mã học phần).

Thông tin ra:

Cập nhật cơ sở dữ liệu học phần.

Ngoại lệ:




Tên UseCase:


g) Xem_Danh_Sách_Sinh_Viên

Mục đích:

Cho phép cán bộ đào tạo xem danh sách sinh viên trong một lớp học phần hoặclớp sinh hoạt.

Hoạt động:Yêu cầu xem danh sách các sinh viên.

Thông tin vào:

Username.

Mã lớp học phần hoặc mã lớp sinh hoạt cần xem.


Thông tin ra:

Hiển thị danh sách các sinh viên ứng với lớp học phần đã chọn.

Ngoại lệ:



Tên UseCase:


h) Xếp_Lịch_Thi

Mục đích:

Sắp xếp lịch thi cho các lớp học phần sau khi kết thúc khoảng thời gian đăng ký.

Hoạt động:

Yêu cầu xếp lịch thi cho các lớp học phần trong học kỳ, tuy nhiên công việc nàythuộc phân hệ khác, có thể là phân hệ xếp thời khóa biểu, và phân hệ đăng ký tínchỉ này chỉ đưa thông tin vào và lấy thông tin ra từ phân hệ đó mà thôi.

Thông tin vào:

Username.

Mã lớp học phần, phòng thi, ngày, thời gian bắt đầu, tổng thời gian(dữ liệu có thểđược giả lập để chạy chương trình vì chưa được kết nối với phân hệ sắp xếp lịchthi và thời khóa biểu).


Thông tin ra:

Lịch thi tương ứng của mỗi lớp học phần.

Ngoại lệ:








Tên UseCase:


i) Giới_Hạn_Đăng_Ký

Mục đích:

Cho phép cán bộ đào tạo đưa ra các khoảng thời gian cho phép đăng ký học phầncũng như khoảng thời gian cho phép chỉnh sửa các đăng ký.

Hoạt động:

Yêu cầu giới hạn đăng ký cho một học kỳ.

Thông tin vào:

Username.

Mã loại học kỳ, khoảng thời gian cho phép đăng ký, khoảng thời gian cho phépchỉnh sửa.


Thông tin ra:

Cập nhật cơ sở dữ liệu về thời hạn đăng ký học phần của sinh viên.

Ngoại lệ:




Tên UseCase:UseCase_Level2_CanBoDaoTao9.

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

Mục đích:

Cho phép cán bộ đào tạo tạo thời khóa biểu dự kiến với thông tin được lấy từ phân hệ thời khóa biểu.

Hoạt động:

Yêu cầu tạo thời khóa biểu dự kiến.

Thông tin vào:

Username.Các học phần cần mở lớp và số lượng sinh viên cho mỗi học phần, cùng cácthông tin cần thiết về số phòng còn trống,….


Thông tin ra:

Thời khóa biểu dự kiến cho các lớp học phần.

Cập nhật cơ sở dữ liệu về thời khóa biểu của các lớp học phần.

Ngoại lệ:


Các chức năng liên kết:Đăng_Nhập [UseCase_Level2_CanBoDaoTao1]

Tên UseCase:






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

Mục đích:

Cán bộ đào tạo dựa vào thông tin sinh viên submit lên để xem xét có mở thêmmột số lớp học phần theo đề nghị của sinh viên hay không.

Hoạt động:

Yêu cầu cần tổ chức các lớp học phần do sinh viên đề nghị.

Thông tin vào:

Username.

Các học phần cùng số lượng sinh viên đề nghị mở lớp học phần.

Số lượng phòng phù hợp cho loại học phần đó mà còn trống.


Thông tin ra:

Thời khóa biểu thêm cho các lớp học phần mới này.Cập nhật cơ sở dữ liệu tương ứng.

Ngoại lệ:




Tên UseCase:


l) Xem_Báo_Cáo_Thống_Kê

Mục đích:Cho phép cán bộ đào tạo xem báo cáo thống kê về việc đăng ký của sinh viên(danh sách sinh viên đăng ký chưa đạt số tín chỉ tối thiểu, danh sách sinh viênchưa đăng ký).

Hoạt động:

Yêu cầu xem báo cáo thống kê.

Thông tin vào:

Username.

Loại báo cáo cần xem.


Đưa ra báo cáo cần xem.

Ngoại lệ:




Tên UseCase:


m) Quản_Lý_Chương_Trình_Đào_TạoMục đích:





Cho phép cán bộ đào tạo tạo mới, chỉnh sửa, xóa chương trình đào tạo của cácngành trong trường.

Hoạt động:

Yêu cầu quản lý chương trình đào tạo một ngành.

Thông tin vào:

Username.

Mã ngành, mã học kỳ, mã học phần, nhóm tự chọn, khối kiến thức (chuyênngành, cơ sở ngành).



Kiểm tra các thông tin vào bắt buộc (mã ngành, mã học kỳ và mã học phần).

Thông tin ra:

Chương trình đào tạo của ngành.

Ngoại lệ:




Tên UseCase:


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

Mục đích:

Cho phép cán bộ đào tạo nhập, chỉnh sửa điểm cho từng sinh viên hoặc một lớphọc phần.

Hoạt động:

Yêu cầu nhập và cập nhật điểm.

Chọn một lớp học phần hoặc sinh viên muốn nhập hoặc cập nhật điểm.

Thông tin vào:

Mã lớp học phần hoặc mã sinh viên cần nhập và cập nhật điểm.


Thông tin ra:

Cập nhật điểm số của sinh viên trong cơ sở dữ liệu.




Tên UseCase:


o) Thay_Đổi_Password

Mục đích:


Hoạt động:Yêu cầu thay đổi password.

Thông tin vào:





Username.



Thông tin ra:


Ngoại lệ:




Tên UseCase:


p) Đăng_Xuất

Mục đích:

Cho phép cán bộ đào tạo đăng xuất khỏi hệ thống.Hoạt động:


Thông tin vào:


Thông tin ra:


Ngoại lệ:


Các chức năng liên kết:Đăng_Nhập [UseCase_Level2_CanBoDaoTao1]

Tên UseCase:


vi. QuảnTrịHệThốnga) Đăng_Nhập

Mục đích:

Quản trị hệ thống đăng nhập vào hệ thống.

Hoạt động:


Submit.

Thông tin vào:

Username (mã quản trị hệ thống theo các quy tắc đặt mã đã nêu).

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



Thông tin ra:

Trả về trang màn hình lựa chọn của quản trị hệ thống nếu Username & Paswordhợp lệ.






Ngoại lệ:



Tên UseCase:

UseCase_Level2_QuanTriHeThong1.

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

Mục đích:

Cho phép quản trị hệ thống tạo mới, chỉnh sửa thông tin, xóa – khóa tài khoản cán bộ đào tạo, và xem thông tin chi tiết của từng cán bộ đào tạo.

Hoạt động:

Yêu cầu quản lý cán bộ đào tạo.

Thông tin vào:

Username.

Mã cán bộ đào tạo, họ và tên, ngày tháng năm sinh, quê quán, địa chỉ tạm trú, giớitính, tình trạng gia đình, điện thoại liên lạc, email, số chứng minh nhân dân, ngàycấp chứng minh nhân dân, nơi cấp chứng minh nhân dân, thời gian công tác, dântộc, quốc tịch, khoa quản lý, học hàm học vị, chức vụ (có thể kiêm nhiệm đồngthời nhiều chức vụ), tôn giáo, ghi chú.



Kiểm tra các thông tin vào bắt buộc (mã cán bộ đào tạo,…).

Thông tin ra:

Cập nhật cơ sở dữ liệu cán bộ đào tạo.



Đăng_Nhập [UseCase_Level2_QuanTriHeThong1]

Tên UseCase:


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

Mục đích:

Cho phép quản trị hệ thống tạo mới, chỉnh sửa thông tin, xóa – khóa tài khoản

giáo vụ khoa và xem thông tin chi tiết của giáo vụ khoa.Hoạt động:

Yêu cầu quản lý giáo vụ khoa.

Thông tin vào:

Username.

Mã cán bộ đào tạo, họ và tên, ngày tháng năm sinh, quê quán, địa chỉ tạm trú, giớitính, tình trạng gia đình, điện thoại liên lạc, email, số chứng minh nhân dân, ngàycấp chứng minh nhân dân, nơi cấp chứng minh nhân dân, thời gian công tác, dântộc, quốc tịch, khoa quản lý, học hàm học vị, chức vụ (có thể kiêm nhiệm đồngthời nhiều chức vụ), tôn giáo, ghi chú.







Kiểm tra các thông tin vào bắt buộc (mã giáo vụ khoa,…).

Thông tin ra:

Cập nhật cơ sở dữ liệu giáo vụ khoa.

Ngoại lệ:




Tên UseCase:


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

Mục đích:

Cho phép quản trị hệ thống cấu hình để hệ thống hoạt động được và đảm bảo duytrì hệ thống hoạt động tốt nhất.

Hoạt động:Cấu hình và duy trì hệ thống.

Thông tin vào:

Các thông tin về hệ thống và thông tin liên quan cần thiết.


Thông tin ra:

Hệ thống hoạt động được và đúng dự định.

Ngoại lệ:


Các chức năng liên kết:Đăng_Nhập [UseCase_Level2_QuanTriHeThong1]

Tên UseCase:


e) Thay_Đổi_Password

Mục đích:


Hoạt động:





Thông tin ra:


Ngoại lệ:



Đăng_Nhập [UseCase_Level2_QuanTriHeThong1]Tên UseCase:






f) Đăng_Xuất

Mục đích:

Quản trị hệ thống đăng xuất khỏi hệ thống.

Hoạt động:


Thông tin vào:


Thông tin ra:


Ngoại lệ:




Tên UseCase:UseCase_Level2_QuanTriHeThong6.

IV. Sơ đồ use-case

UML có năm hướng nhìn đối với một hệ thống (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 bố trí), chúng hỗ trợ tương quan lẫnnhau. Tuy nhiên, hướng nhìn use-case đóng vai trò quan trọng đặc biệt đối với kiến trúc hệthống, nó ảnh hưởng xuyên suốt đối với bốn hướng nhìn còn lại và trong cả quá trình xây dựnghệ thống.

Với các Actor và các đặc tả về chức năng của mỗi người dùng đối với hệ thống trong phầntrên, chúng ta đã có cái nhìn tổng thể về hệ thống, nắm được những chức năng cơ bản và gầnnhư là đầy đủ của những người dùng này. Tuy nhiên, ở trên chúng ta chỉ thấy được chức năngriêng lẻ mà chưa thấy được mối quan hệ giữa chúng, một bước rất quan trọng giúp người đọcdễ dàng thân thiện và nắm bắt được hệ thống mà ta đang xây dựng. Vì vậy, chúng ta cần bổsung những mối quan hệ giữa các use-case này, và cách tốt và rõ ràng nhất là chúng ta sẽ sửdụng các sơ đồ use-case để trình bày mối quan hệ giữa các Actor với hệ thống cũng như giữacác use-case với nhau.

Nhóm người dùng chung có ba quyền khi tương tác với hệ thống, đó là những quyền cơ bảnmà bất cứ một người dùng nào muốn tìm hiểu về trường ĐHBK. Các nhóm người dùng sinhviên, giảng viên, giáo vụ khoa, cán bộ đào tạo và quản trị hệ thống cũng có ba quyền như trên,và ngoài ra họ sẽ có thêm những quyền riêng tùy thuộc vào chức năng của mỗi nhóm người

dùng như đã phân tích ở trên. Vì vậy, các nhóm người dùng này sẽ kế thừa từ nhóm người dùngchung hay quan hệ giữa nhóm người dùng chung với các nhóm người dùng còn lại là quan hệkhái quát hóa.





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

Đường mũi tên có một đầu hình tam giác rỗng biểu thị cho quan hệ khái quát hóa giữa cácActor, trong đó Actor khái quát ở gốc của đường mũi tên, còn Actor chuyên biệt ở phía đườngmũi tên. Vì vậy, ở sơ đồ trên, năm nhóm người dùng hợp thức không những kế thừa các hànhvi và thuộc tính của nhóm người dùng chung, các nhóm người dùng này còn có thể đè lấp, thayđổi một phần nào đó các hành vi kế thừa và có thể thêm hành vi mới.

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





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

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





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





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

Các hình trên được trình bày theo thứ tự nhằm mục đích chỉ rõ mức độ được phép thao tácvới hệ thống, hay còn gọi là quyền sử dụng hệ thống, tăng dần từ nhóm người dùng sinh viênvà cuối cùng là nhóm người dùng quản trị hệ thống.

Đặc biệt, để sử dụng được các chức năng khác, một điều cần thiết là người dùng phải đăngnhập thành công vào hệ thống,. Vì vậy, ở sơ đồ trên tất cả các use-case nối đến use-caseĐăng_Nhập bởi liên kết << permit>>, tức là cho phép thực hiện chức năng sau khi đăng nhập.Và khi thoát khỏi hệ thống, người dùng cần phải đăng xuất. Hai sơ đồ dưới đây sẽ làm rõ cácchức năng này, chức năng đăng nhập và đăng xuất.

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





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

Các nhóm người dùng được đặt tên bắt đầu bằng kí tự “ A”, viết tắt của từ Actor , nhằm làmrõ hơn mục đích và ý nghĩa của các tác nhân đối với hệ thống OCRS.

Ở mỗi sơ đồ, phần cuối cùng của tên sơ đồ có ghi rõ mức mịn dần của mỗi sơ đồ, trong đó[Mức 1] là mức khái quát nhất, và càng về sau, các sơ đồ càng làm rõ ràng hơn cho một chức

năng nào đó trong mức cao hơn.Trong các sơ đồ trên, liên kết <<include>> nhằm mục đích cho biết một chức năng muốnthực hiện tốt cần phải sử dụng thêm các chức năng khác làm cơ sở, trong đó chức năng cơ sở ở đầu mũi tên của đường mũi tên nét đứt. Còn liên kết <<permit>> được vẽ bằng đường mũi tênliền nét, nó cho biết để thực hiện được một chức năng nào đó thì cần phải thực hiện xong mộtchức năng trước đó, và chức năng ở gốc mũi tên là chức năng phải được thực hiện hoàn thành.




PHẦN IV

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

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

Ở phần trước, chúng ta đã mô tả hệ thống bằng các use-case, nhưng đó thực chất chỉ lànhững mô tả được nhìn từ phía người dùng. Một sự phân tích tiếp tục theo hướng chức năng sẽ

dẫn ta trở lại con đường của các phương pháp hướng chức năng kinh điển kéo theo nhữngnhược điểm của nó.

Vì vậy, sau bước đặc tả yêu cầu hệ thống bằng các use-case và các sơ đồ use-case, chúng tacần chuyển sang cách tiếp cận đối tượng.

1. Quá trình xây dựng các lớp ứng dụngTrước hết chúng ta cần xác định các lớp trong hệ thống, để rồi từ đó mô tả các mối quan hệ

giữa chúng thông qua các sơ đồ. Từ những khái niệm, thường là các vật thể hoặc sự kiện, đượcsử dụng trong lĩnh vực ứng dụng, ta sẽ đề xuất ra các đối tượng và lớp để miêu tả, mô phỏngchúng. Loại đối tượng này được gọi là các đối tượng thực thể hay đối tượng lĩnh vực. Đồngthời, từ những use-case, ta nghiên cứu về sự cần thiết phải hợp tác của những đối tượng nào đểthực hiện use-case này. Qua đó, ta có thể gặp lại các đối tượng thực thể ở trên, và như vậykhẳng định được vị thế của chúng trong hệ thống, đồng thời lại phát hiện thêm được các loạiđối tượng phù trợ.

Lưu ý rằng, để xác định được các đối tượng này, ta tuân thủ theo quy tắc sau:

Các danh từ sẽ là các đối tượng hay thuộc tính. Trong đó, các khái niệm có thể chuyểnthành các đối tượng có thể là các thực thể như vật chất, xe đạp, máy bay, cảm biếnv.v…; các vai trò như mẹ, giáo viên, cảnh sát, cán bộ v.v…; các sự kiện như hạ cánh,ngắt, đăng ký xe máy v.v…; các tương tác như cho vay, hội thảo v.v…; các tổ chức nhưcông ty, khoa, lớp v.v…

Các động từ có thể là các phương thức.

Từ các khái niệm nghiệp vụ được phát hiện, ta sẽ giữ nguyên tên các khái niệm như trongthực tế, và đặc biệt sẽ không dùng nhiều tên cho một khái niệm, dù rằng trong thực tế có thể lànhư vậy.

a. Khởi tạo danh sách các lớp ứng viênCác danh từ và cụm danh từ trong các mô tả use-case, cũng như trong quá trình phân tích

hiện trạng tại trường ĐHBK ĐN, từ những tài liệu viết hay từ các quá trình phỏng vấn một sốcán bộ ở phòng đào tạo, khoa v.v…

Kiến thức đại cương Khoa học xã hội

Khoa học nhân văn Khoa học tự nhiên

Kiến thức giáo dục chuyên nghiệp Kiến thức cơ sở Kiến thức chuyên ngành Học phần

Học phần bắt buộc Học phần tự chọn bắt buộc

Học phần tự chọn tự do Học phần học trước

Học phần tiên quyết Học phần song hành

Học phần tương đương Học phần thí nghiệm

Học phần lý thuyết Học phần thực hành

Đồ án môn học Thực tập nhận thức

Thực tập tốt nghiệp Khóa luận tốt nghiệp

Ngành Chuyên ngành Ngành chuyên môn Tên ngành học




PHẦN IV

Điểm Điểm học phần




Phân tích thiết kế hệ thống

Điểm trung bình chung học tập Kết quả học phần

Điểm trung bình chung tích lũy Học kỳ

Học kỳ chính Học kỳ phụ

Học kỳ III Học kỳ hè

Học kỳ ở trường khác Học kỳ tạm dừngHiệu trưởng Cán bộ phòng đào tạo

Trưởng khoa Giảng viên

Giảng viên phụ trách lớp học phần Giáo viên chủ nhiệm

Trưởng bộ môn Bộ môn phụ trách môn học

Sinh viên Sinh viên tại chức

Sinh viên dự thính Sinh viên chính quy

Văn phòng Khoa

Trường Nhà trường

Phòng học LớpLớp sinh hoạt Lớp học phần

Mã học phần Mã phòng học

Mã lớp học phần Mã lớp sinh hoạt

Mã ngành Mã khoá học

Mã sinh viên Mã giảng viên

Chương trình đào tạo Khối lượng công việc

Tín chỉ Tín chỉ học phí

Mức học phí Tổng số tín chỉ tích luỹ

Số tín chỉ học kỳ Chương trình đào tạoCấp đại học Khoá học

Khoá đào tạo Năm học

Bảng kế hoạch học tập Cố vấn học tập

Sĩ số Điều kiện ràng buộc

Đăng ký học phần Chữ ký

Thủ tục học phí Học phí

Tuần Số tiết

Tuần dự trữ Tuần kiểm tra

Tuần học Tuần thiTuần thực tập Tuần bảo vệ

Thời gian biểu Thời khoá biểu

Thời gian Thời khoá biểu chính

Danh sách học phần Thời khóa biểu dự kiến

Thông tin cá nhân Người dùng chung

Bản tin Thông báo

Tài khoản Lịch thi

Quản trị hệ thống Quy trình

Buổi học Danh sách Giảng Viên

Danh sách phòng học Danh sách sinh viên





Giáo vụ khoa Môn học đã đăng ký

Cấp học

b. Loại bỏ các lớp giảCác lớp giả là các lớp không có ý nghĩa trong lĩnh vực ứng dụng. Với các lớp giả này, dấu

hiệu của loại được thể hiện bằng cách gạch ngang mỗi danh từ hay cụm danh từ muốn loại bỏ.Kiến thức đại cương Khoa học xã hội


Kiến thức giáo dục chuyên nghiệp Kiến thức cơ sở

Kiến thức chuyên ngành Học phần





Học phần lý thuyết Học phần thực hànhĐồ án môn học Thực tập nhận thức

Thực tập tốt nghiệp Khoá luận tốt nghiệp

Ngành Chuyên ngành

Ngành chuyên môn Tên ngành học





Học kỳ III Học kỳ hèHọc kỳ ở trường khác Học kỳ tạm dừng

Hiệu trưởng Cán bộ phòng đào tạo






Văn phòng Khoa

Trường Nhà trườngPhòng học Lớp

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








Số tín chỉ học kỳ Văn thư





Cấp đại học Khoá học



Sĩ số sinh viên Điều kiện ràng buộc



Tuần Số tiết


Tuần học Tuần thi

Tuần thực tập Tuần bảo vệ




Thông tin cá nhân Người dùng chungBản tin Thông báo






Cấp học

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

Cần rà soát lại danh sách để tìm kiếm các danh từ, cụm danh từ trùng lắp về ý nghĩa mặc dùcách dùng từ có khác nhau. Chúng ta sẽ chọn lựa danh từ, cụm danh từ chứa đầy ngữ nghĩanhất và loại những danh từ, cụm danh từ khác.

STT Các lớp ứng viên trùng lắp Lớp ứng viên thay thế

1Trường

Nhà trườngTrường

2Khóa học

Khóa đào tạo

Khóa

3

Ngành

Ngành chuyên môn

Tên ngành học

Chuyên ngành

Ngành

4Giáo vụ khoa

Văn thưGiáo vụ khoa

5

Học kỳ phụ

Học kỳ IIIHọc kỳ hè Học kỳ hè

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


















Điểm Điểm học phầnĐiểm trung bình chung học tập Kết quả học phần




Học kỳ ở trường khác Học kỳ tạm dừng




Trưởng bộ môn Bộ môn phụ trách môn họcSinh viên Sinh viên tại chức


Văn phòng Khoa


Phòng học Lớp




Mã ngành Mã khoá họcMã sinh viên Mã giảng viên








Sĩ số sinh viên Điều kiện ràng buộcĐăng ký học phần Chữ ký






Tuần Số tiết












Danh sách phòng học Danh sách sinh viênGiáo vụ khoa Môn học đã đăng ký

Cấp học

d. Xác định các danh từ, cụm danh từ có thể là thuộc tínhCác danh từ, cụm danh từ có thể là thuộc tính khi chỉ được sử dụng như là giá trị, và không

có nhiều hơn một đặc trưng riêng, hoặc chỉ mô tả một đặc trưng của một đối tượng khác




Kiến thức chuyên ngành Học phầnHọc phần bắt buộc Học phần tự chọn bắt buộc








Ngành chuyên môn Tên ngành họcĐiểm Điểm học phần
















Văn phòng Khoa


Phòng học Lớp









Số tín chỉ học kỳ Văn thưCấp đại học Khoá học






Tuần Số tiết


Tuần học Tuần thiTuần thực tập Tuần bảo vệ








Buổi học Danh sách Giảng ViênDanh sách phòng học Danh sách sinh viên


Cấp học

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ốngMỗi lớp phải có mục tiêu khi thuộc hệ thống, mục tiêu này phải thật rõ ràng trong ngữ cảnh

mục tiêu chung của hệ thống. Nếu chúng ta không diễn đạt được mục tiêu của lớp trong hệthống thì loại ra khỏi danh sách. Hoặc các lớp mặc dù có tham gia vào hoạt động của hệ thống,tuy nhiên nó không thuộc phạm vi biểu diễn của hệ thống thì cũng bị loại ra.

Kiến thức đại cương Khoa học xã hộiKhoa học nhân văn Khoa học tự nhiên



















Học kỳ chính Học kỳ phụHọc kỳ III Học kỳ hè








Văn phòng KhoaTrường Nhà trường

Phòng học Lớp







Tín chỉ Tín chỉ học phíMức học phí Tổng số tín chỉ tích luỹ








Tuần Số tiếtTuần dự trữ Tuần kiểm tra

















Cấp học

f. Các lớp ứng viên sau quá trình xây dựngHọc phần Ngành

Học kỳ Cán bộ đào tạo

Giảng viên Sinh viên

Khoa Trường

Ngành Phòng học


Chương trình đào tạo Khóa học

Người dùng chung Giáo vụ khoa

Đăng ký học phần Kết quả học phầnBản tin Thông báo

Lịch thi Quản trị hệ thống

Cấp học

Phương pháp này là triệt để, khó bỏ sót khái niệm, song cũng không phải là luôn chính xácvì có nhiều khái niệm không là khái niệm nghề nghiệp và không phải lúc nào cũng dễ phân biệtgiữa đối tượng thuộc tính, tuy nhiên đây vẫn là phương pháp tối ưu ở bước tìm và phát hiện cácđối tượng để hình thành nên các lớp cho hệ thống.

Qua quá trình xây dựng các lớp trên, chúng ta đã có được những lớp ứng viên cho hệ thống,

tuy nhiên đây là một ứng dụng web, vì vậy trong khi thiết kế và xây dựng, sẽ phát sinh một vàilớp cần thiết, chẳng hạn như các web page hay là các form.

Các lớp ứng viên này sẽ xuyên suốt hệ thống, và cũng chính là những đối tượng mà chúng tasẽ quan tâm trong khi viết code và thiết kế cơ sở dữ liệu.

ii. Mô hình hóa các lớp ứng dụngSơ đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống. Các lớp có thể quan hệ với nhau

theo nhiều dạng thức như association, dependency, package hay chuyên biệt hóa bằnggeneralization. Sơ đồ được coi là sơ đồ tĩnh theo phương diện cấu trúc được miêu tả ở đây cóhiệu lực tại bất kỳ thời điểm nào trong toàn bộ vòng đời hệ thống.

Qua quá trình phân tích và loại bỏ các lớp ứng viên ở trên, chúng ta tiến hành xây dựng sơ

đồ lớp với mỗi lớp đại diện cho một trang hay một phần của trang trong ứng dụng, trong đó cáckhuôn mẫu <<client page>>, <<server page>>, <<form>> để phân biệt chức năng xử lý củamỗi loại đối tượng của ứng dụng web, và một số khuôn mẫu khác.





Khuôn mẫu <<client page>> được gán cho một lớp để nhấn mạnh đó là lớp đượctương tác bởi người dùng từ phía máy client khi có một yêu cầu nào đó.

Khuôn mẫu <<server page>> được gán cho một lớp để nhấn mạnh đó là lớp xử lý cácyêu cầu được phát từ client tại máy server, sau đó server trả kết quả về lại cho máyclient.

Khuôn mẫu <<form>> được gán cho một lớp để nhấn mạnh lớp đó như là một nhómcác đối tượng có nhiệm vụ nhập liệu.

Khuôn mẫu <<link>> được dùng cho một kết hợp để thể hiện mối liên kết giữa các lớpvới nhau, cụ thể nó thể hiện yêu cầu của người dùng từ trang chủ đến các trang liên kếtkhác.

Khuôn mẫu <<build>> được dùng cho một kết hợp cho biết quá trình đáp trả yêu cầucủa client, và kết quả này được hiển thị ở trang client.

Khuôn mẫu <<submit>> được dùng với một kết hợp cho biết thông tin từ form nhập sẽđược chuyển cho server xử lý.

Khuôn mẫu <<re-direct>> được dùng cho một kết hợp nối giữa trang server và trangclient với ý nghĩa kết quả trả về của trang server không là duy nhất.

Khuôn mẫu <<write>> được dung cho một kết hợp nối giữa một lớp và một interfacecho biết dữ liệu từ quá trình xử lý của server page sẽ được lưu vào cơ sở dữ liệu.

Trước tiên, để hiểu được cấu trúc các trang web khi thiết chương trình, bất kỳ một trang webnào cũng cần phải có một trang chủ để mà từ đó có thể đi đến các trang khác. Với hệ thốngOCRS này, chúng tôi phân các trang trước hết theo chức năng người dùng bằng cách click vàotab mang tên mỗi nhóm người dùng. Ngoài ra, còn phân trang theo chức năng hiển thị củatrang, như các trang để xem thông tin cán bộ nhân viên trong trường, hay trang xem thông tincác phòng ban, v.v…

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

Các sơ đồ lớp dưới sẽ tương ứng với các chức năng của từng nhóm người dùng như đã phântích trong sơ đồ use-case ở phần trước. Tuy nhiên, nếu chỉ dừng lại ở đó, chúng ta sẽ khó hìnhdung được cấu trúc các trang của ứng dụng web này cũng như cấu trúc thiết kế chương trình.Do đó, quá trình mịn dần các lớp theo chức năng là việc không thể thiếu và rất hữu ích trongtrường hợp này. Vì vậy, các sơ đồ được trình bày dưới đây nhằm mục đích trên với ý nghĩađược thể hiện qua tên của sơ đồ kề dưới mỗi hình.





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

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

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





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

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

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]





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

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

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

Với nhóm người dùng sinh viên, việc đăng ký học phần không giống với những chức năngkhác, nghĩa là để cho phép sinh viên có thể theo học một học phần tại một lớp học phần tươngứng cụ thể, hệ thống đòi hỏi sinh viên phải thỏa mãn một số yêu cầu cần thiết như điều kiệnhọc trước, điều kiện tiên quyết và điều kiện song hành của một học phần. Không những thế,nhằm tối ưu hóa khả năng tự động cho hệ thống, để quyết định cho phép sinh viên theo học mộtlớp học phần hay không, hệ thống cần phải kiểm tra số lượng sinh viên tối đa được phép theohọc một lớp học phần (thông tin này được ấn định bởi phòng đào tạo khi mở một lớp học phầndựa vào thông tin về khả năng chứa của từng phòng học cụ thể) theo quy tắc ai đăng ký trước

thì sẽ được ưu tiên trước. Ngoài ra, do quy định về tổng số tín chỉ tối đa, tối thiểu mà sinh viênđược phép học ở mỗi kỳ, hệ thống cũng cần phải kiểm tra vấn đề này. Vì vậy, việc mịn dầnchức năng kiểm tra việc đăng ký học phần cũng rất cần thiết.





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

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

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

Như đã nói trên, dưới đây sẽ trình bày các sơ đồ mịn dần của sơ đồ lớp này.





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


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

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





Giảng viên tương tác với hệ thống thông qua ba chức năng này, trong đó mỗi chức năng chỉmang tính truy xuất dữ liệu mà không được phép thao tác thay đổi dữ liệu, vì vậy ta sẽ không

phân rã nhỏ hơn nữa các chức năng đó của giảng viên.

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

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

Như đã nói trên, dưới đây sẽ trình bày các sơ đồ mịn dần của sơ đồ lớp này.

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






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


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

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





Trong sơ đồ trên, chúng em sử dụng khuôn mẫu hiển thị dưới dạng icon với hình vòng tròncó bánh răng quay biểu diễn trang server với ý nghĩa cán bộ đào tạo là đối tượng quản lý toàn

bộ quá trình đào tạo theo học chế tín chỉ và có khả năng thao tác chính với dữ liệu. Sau đây làcác sơ đồ mịn dần của sơ đồ lớp này.

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

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






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

Sơ đồ trên cho biết cán bộ đào tạo có quyền tạo mới các tài khoản sinh viên và giảng viên cảtrường cũng như tạo mới các tài khoản về phòng học, học phần, lớp học.

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





Sơ đồ trên cho biết cán bộ đào tạo có quyền khóa các tài khoản sinh viên và giảng viên cảtrường cũng như xóa các tài khoản về phòng học, học phần, lớp học.

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

Sơ đồ trên cho biết cán bộ đào tạo có quyền xem thông tin chi tiết của từng sinh viên vàgiảng viên trong trường cũng như xem thông tin cá nhân của chính cán bộ đào tạo và thông tinvề các tài khoản về phòng học, học phần, lớp học.

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





Sơ đồ trên cho biết cán bộ đào tạo có quyền chỉnh sửa thông tin các tài khoản sinh viên vàgiảng viên cả trường cũng như chỉnh sửa thông tin các tài khoản về phòng học, học phần, lớphọc.

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

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

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





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

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

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

Hành vi là cách hành động, ứng xử của một hệ thống. Mô hình hóa hành vi đối với hệ thốnglà sự diễn tả khía cạnh động của hệ thống, đối lập với mô hình hóa cấu trúc là sự diễn tả khíacạnh tĩnh của hệ thống.

Chúng ta đã biết, use-case được dùng để mô hình hóa các chức năng trong hệ thống và xácđịnh cách thức các tác nhân tương tác với hệ thống và mô hình hóa cấu trúc tĩnh của hệ thốngcho phép chúng ta thâm nhập vào bên trong hệ thống đồng thời chỉ ra các đối tượng, các lớptham gia vào các use-case đó. Tuy nhiên, nếu chỉ dừng lại ở đó chúng ta sẽ không thấy đượchoạt động của các lớp, mà cụ thể là của các đối tượng của lớp. Vì vậy, trong phần này chúng tacần mô hình hóa hệ thống ở mức tương tác thông qua các sơ đồ hoạt động và sơ đồ tuần tự.

Sơ đồ hoạt động trong mô hình đối tượng minh họa luồng công việc của một hiện thực hóa

use-case nghiệp vụ, nó cho biết việc sắp xếp các công việc theo một thứ tự nhằm đạt được cácmục tiêu của nghiệp vụ. Một hoạt động trong sơ đồ hoạt động có thể là một công việc thủ cônghoặc tự động hóa để hoàn thành một đơn vị công việc. So với sơ đồ tuần tự có cùng mục đíchthì sơ đồ hoạt động tập trung mô tả cách thức phân chia trách nhiệm thành các lớp, trong khiđó, sơ đồ tuần tự lại mô tả cách thức các đối tượng tương tác theo trình tự. Sơ đồ hoạt động tậptrung vào luồng công việc trong khi sơ đồ tuần tự tập trung vào việc xử lý các thực thể. Chúng

bổ sung cho nhau, và lý giải cho mục đích sử dụng hai loại sơ đồ này khi mô hình hóa hành vihệ thống.

Về mặt bản chất, sơ đồ cộng tác và sơ đồ tuần tự là như nhau, chúng chỉ khác nhau ở mụcđích truyền đạt thông điệp cần diễn tả cho người đọc, tức là sơ đồ trình tự mô tả rõ ràng trình tựcác sự kiện và nó được sử dụng thích hợp khi use-case phức tạp, còn sơ đồ cộng tác trình bàycác mối liên kết giao tiếp cùng những thông điệp giữa các đối tượng và nó giúp người đọc hiểuđược tất cả các tác động trên một đối tượng. Và người ta đã đưa ra một khuyến cáo rằng, khôngnên dùng cả hai sơ đồ này đồng thời để diễn tả cùng một tương tác.





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





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

Ở đây chúng em chỉ mô hình hóa hai quá trình, đó là quá trình đăng ký học phần của sinhviên và việc xem xét các học phần đề nghị từ kết quả đăng ký của sinh viên để tổ chức các lớphọc phần mới không thuộc kế hoạch giảng dạy dự kiến của nhà trường nói chung cũng như của

phòng đào tạo nói riêng, nhằm nhấn mạnh chức năng chính của chương trình ứng dụng này.Hơn nữa, đây là hai quá trình đòi hỏi độ phức tạp cao khi sinh viên muốn đăng ký học phần vàviệc tổ chức thêm các lớp học phần được bắt nguồn từ đâu, được tiến hành như thế nào cũng rấtquan trọng.





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





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ý

Như đã phân tích ở trên, không chỉ cho phép đăng ký học phần, hệ thống còn cho phép sinhviên có thể hủy những học phần đã đăng ký sau khi đã đăng ký học phần hoặc cũng có thể ngaytrong lần sinh viên đang đăng ký học phần. Xét về hoạt động, thì sinh viên chỉ cần hủy chọn lớphọc phần đã đăng ký, tuy nhiên quá trình này sẽ rõ ràng hơn rất nhiều khi được mô hình qua sơ đồ trình tự trên.

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

Trong môi trường hướng đối tượng, đối tượng đảm nhiệm vai trò chủ động trong một hệ

thống. Đối tượng không tồn tại một cách độc lập mà luôn tương tác với những đối tượng khác,sự tương tác này thể hiện thông qua mối kết hợp gồm cả những hoạt động và hành vi của đốitượng.

Từ tập các lớp ứng viên thu được sau quá trình xây dựng lớp cùng với quá trình phân tíchcác hành vi và sự tương tác giữa các đối tượng trong những phần trên, chúng ta đã xác đinhđược một số mối quan hệ giữa các lớp. Tuy nhiên các mối quan hệ này vẫn chưa tối ưu và rờirạc, vì vậy việc cần thiết xây dựng một sơ đồ lớp tổng quan với đầy đủ các quan hệ giữa nhữnglớp chính của ứng dụng là hết sức cần thiết.

Với ứng dụng OCRS các đối tượng người dùng giảng viên, giáo vụ khoa, cán bộ đào tạo vàquản trị hệ thống về bản chất đều là cán bộ công nhân viên của trường và đều có những thôngtin lưu trữ giống nhau, mỗi đối tượng chỉ khác nhau về mặt chức năng sử dụng. Đó là nguyênnhân để ta xây dựng một lớp khái quát đại diện cho các đối tượng đã nêu ở trên, mỗi đối tượngsẽ kế thừa những thuộc tính và phương thức chung từ lớp khái quát này. Dưới đây là sơ đồ lớptổng thể hệ thống OCRS.





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





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

1. Thiết kế lớpMục tiêu chính của giai đoạn phân tích là tập trung vào xác định những gì cần được thực

hiện. Các đối tượng được phát hiện trong giai đoạn phân tích sẽ làm cơ sở cho giai đoạn thiết

kế. Các thuộc tính, phương thức và mối liên kết của lớp được xác định trong giai đoạn phântích, và được bổ sung từ các mô hình biểu diễn tương tác giữa các đối tượng, phải được thiết kếcho việc cài đặt như là một thành phần được mô tả theo ngôn ngữ cài đặt.

Trong phần này, chúng ta tập trung chi tiết hóa hướng nhìn logic bằng cách xác định thêmcác lớp chi tiết ở cả tầng giao diện và tầng truy cập cơ sở dữ liệu để từ đó hình thành một sơ đồlớp hoàn chỉnh mô tả đầy đủ các đối tượng của ứng dụng chuẩn bị cho việc cài đặt.

Ngoài ra, dựa trên các kết quả này chúng ta phát triển thiết kế vật lý hệ thống bằng cách xâydựng thêm các hướng nhìn cài đặt và hướng nhìn triển khai nhằm chuyển giao kết quả thiết kếhệ thống gần với một ngôn ngữ và công cụ lập trình xác định cho giai đoạn lập trình để có thểcài đặt phù hợp với các thiết bị tài nguyên trong một môi trường hệ thống thực tế một cách hiệu

quả nhất.Hầu hết các hệ thống được phát triển có xu hướng xây dựng một kiến trúc hai tầng đó làgiao diện và dữ liệu. Trong kiến trúc hai tầng đó các màn hình giao diện người dùng liên kết đểtruy cập dữ liệu thông qua các đoạn chương trình được cài trực tiếp trên các đoạn giao diện. Vídụ: một chương trình viết trên nền Visual Basic có một form giao diện, một thủ tục xử lý sựkiện trong nút “Cập nhật” của form này có tên cmd_CapNhat_Click() có thể thực hiện luônviệc truy cập và cập nhật cơ sở dữ liệu trực tiếp, như vậy thủ tục này cài đặt luôn các ngữ nghĩavề tác nghiệp. Việc thiết kế theo mô hình này tạo ra một sự phụ thuộc rất lớn giữa giao diện vàcơ sở dữ liệu, do đó rất khó cải tiến bảo trì và khó sử dụng.

Một cách tiếp cận kiến trúc khác tốt hơn chính là tạo ra sự độc lập giữa giao diện và ngườisử dụng bằng cách cô lập các chức năng của lớp giao diện với các chức năng của lớp tácnghiệp, của lớp tác nghiệp với lớp truy cập cơ sở dữ liệu. Đó chính là cách tiếp cận ba lớp, từcách tiếp cận này cho phép chúng ta tạo ra được các đối tượng đại diện cho các đối tượng hữuhình trong thực tế nhưng hoàn toàn độc lập với cách thức mà các đối tượng này trình bày tớingười dùng cũng như cách mà dữ liệu của nó được lưu trữ trong cơ sở dữ liệu.

Một chương trình sẽ tạo ra một số dữ liệu trong quá trình thực thi. Mỗi dữ liệu sẽ có mộtthời gian sống khác nhau. Dữ liệu tạm thời (Transient Data) có thời gian sống phụ thuộc vàothời gian sống của tiến trình sử dụng nó và được giải phóng khi tiến trình như các biến trongmột quá trình thực thi thủ tục, kết quả tạm thời để đánh giá biểu thức, biến toàn cục và biến cấp

phát động. Dữ liệu liên tục ( Persistent Data) có thời gian tồn tại lâu hơn và độc lập với tiếntrình sử dụng nó, chúng được quản lý bởi hệ quản trị cơ sở dữ liệu hay hệ thống lưu trữ tập tin.

Đa số các lớp trong ứng dụng được chúng em thiết kế là lớp Persistent.Để phát huy hướng đối tượng ở mức cao nhất, người ta khuyến cáo tất cả các thuộc tính nên

được gán cho một phạm vi truy cập nội bộ dạng Protected nhằm đảm bảo tính bao bọc và có thểthừa kế nếu sau này cần phát triển thêm các lớp con. Các phương thức thì nên được truy cậptoàn cục như chính bản chất sử dụng phương thức, ngoại trừ một số phương thức chỉ được sửdụng trong nội bộ lớp đó hoặc lớp con kế thừa. Trong Rational Rose quy ước về các phạm vitruy cập như sau:





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









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





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





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





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





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





ii. Chuyển đổi đối tượng sang mô hình quan hệTrong cơ sở dữ liệu quan hệ, một lược đồ được hình thành bởi các bảng gồm các cột và

dòng. Trong mô hình hướng đối tượng, tương ứng tới một bảng là một lớp hoặc nhiều lớp. Cácthành phần tương ứng như sau:

Một cột ứng với một thuộc tính của lớp. Một dòng của bảng ứng với một đối tượng.

Một thủ tục lưu trữ nội, hay còn gọi là Store Procedure, có thể tương ứng với một phương thức.

Như vậy, việc chuyển đổi sơ đồ lớp sang lược đồ quan hệ gồm những công việc sau:

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

Chuyển đổi mối liên kết bao gồm liên kết kết hợp và liên kết kế thừa.

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

Trong đa số các trường hợp thì việc chuyển đổi này là một - một, một lớp sẽ chuyển thànhmột bảng cụ thể như sau:

Một lớp thành một bảng.

Một thuộc tính ( persistent ) thành một cột: chỉ có các thuộc tính có nhu cầu cần lưu trữvà được đòi hỏi bởi ứng dụng sẽ được chuyển thành cột của bảng.

Một đối tượng (thể hiện) thành một dòng.

b. Chuyển đổi mối liên kếtChuyển đổi liên kết kết hợp

Trường hợp 1: Trong chuyển đổi mối kết hợp một – một, chúng ta có thể lấy cột khóa

chính trong một bảng chuyển qua bảng khác làm khóa ngoại. Trường hợp 2: Trong chuyển đổi một kết hợp dạng một - nhiều, chúng ta lấy cột khóa

chính ứng với lớp phía một trong mối kết hợp đưa vào bảng ứng với lớp phía nhiều làmkhóa ngoại.

Trường hợp 3 : Trong chuyển đổi mối kết hợp nhiều – nhiều, chúng ta tạo ra một bảngcho mối kết hợp đó bằng cách lấy các khóa chính của các bảng đưa vào bảng mới nàynhư là khóa ngoại.

Chuyển đổi liên kết kế thừa

Trong lược đồ quan hệ không có khái niệm kế thừa mà chúng ta thường dùng liên kết khóachính – khóa ngoại để diễn đạt điều này. Ví dụ, ta có lớp CánBộ có các thuộc tính (canboid,

hoten, ngaysinh) và hai lớp GiảngViên có thuộc (canboid, thuockhoa), CánBộĐàoTạo có thuộctính (canboid) kế thừa từ lớp CánBộ, với kiểu liên kết này ta có thể chuyển đổi sau:

Trường hợp 1: Chỉ sử dụng một bảng lưu trữ tất cả các loại cán bộ. Do đó, các thuộctính của bảng được hình thành từ các thuộc tính của lớp CánBộ, GiảngViên,CánBộĐàoTạo. Ngoài ra chúng ta cũng đưa vào thêm một thuộc tính (loaicanbo) để

phân biệt cán bộ thuộc loại nào trong cơ sở dữ liệu.

Trường hợp 2: Sử dụng ba bảng tương ứng cho ba lớp. Tuy nhiên, nhằm mô tả sự kếthừa trong các bảng GiảngViên và CánBộĐàoTạo chúng ta thêm vào tất cả các thuộctính của bảng CánBộ cho mỗi bảng. Các thể hiện tương ứng của nhóm các đối tượnggiảng viên hay các cán bộ đào tạo sẽ được lưu trong bảng tương ứng.

Trường hợp 3: Chỉ dùng hai bảng GiảngViên và CánBộĐàoTạo. Tuy nhiên, tất cả cácthuộc tính của lớp CánBộ sẽ được đưa vào hai bảng này để thể hiện sự thừa kế. Nếumuốn truy xuất thông tin về lớp CánBộ, ta có thể tạo một bảng hợp của hai bảng.





Áp dụng những quy tắt chuyển đổi trên ta có lược đồ cơ sở dữ liệu quan hệ sau:





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





iii. Triển khai hệ thống OCRSHệ thống OCRS là một ứng dụng Web chạy trên môi trường Internet và đặc thù của hệ

thống này được thiết kế cho phép các đối tượng khác nhau có thể sử dụng các chức năng khácnhau với những cấp độ bảo mật khác nhau. Chính vì những lý do đó vấn đề bảo mật cho hệthống được nhóm phát triển rất quan tâm ngay trong giai đoạn phân tích và thiết kế kiến trúc hệthống.

Hiện nay, trong môi trường công nghệ thông tin của Việt Nam các ngôn ngữ lập trình Webđược sử dụng rất đa dạng như PHP, JSP, ASP,… các ngôn ngữ được nêu ở trên là những ngônngữ được sử dụng phổ biến nhất trong các ứng dụng Web hiện nay. Mỗi ngôn ngữ đều cónhững mặt mạnh và mặt yếu riêng, tuy nhiên chúng em quyết định chọn ngôn ngữ ASP.Net 2.0của Microsoft vì những tính năng linh hoạt trong việc xử lý dữ liệu thông qua mô hìnhADO.Net cũng như khả năng bảo mật cho ứng dụng khá cao dựa trên nền .Net Framework 2.0.Và sơ đồ sau sẽ minh họa cho điều này.

Hình IV.45: Sơ đồ triển khai của hệ thống OCRSiv. Giải thuật và độ phức tạp giải thuật

Như hiện tại trường ĐHBK đang áp dụng, nhà trường phát sổ tay sinh viên cho mỗi sinhviên vào đầu mỗi học kỳ, vẫn cho phép sinh viên chọn lớp học phần muốn đăng ký, nhưng trênhết vẫn là khuyến cáo sinh viên nên học theo đúng chương trình đào tạo cho mỗi ngành ở mỗihọc kỳ. Sau khi đăng ký, sinh viên phải nộp lại kết quả đăng ký của mình cho phòng đào tạo, vàcác cán bộ đào tạo phải kiểm tra thật chính xác trên cơ sở kết quả học tập của sinh viên từ khivô trường đến thời điểm xét, cũng như ba điều kiện của từng học phần, và nhiều những điềukiện khác.

Vì vậy, với những quy định của cơ chế đào tạo tín chỉ, một vấn đề vô cùng quan trọng vàcũng không kém phần khó khăn chính là việc quyết định cho phép một sinh viên được học mộthọc phần nào đó hay không tại thời điểm xét?

Để kiểm tra quy định về việc cho phép mỗi sinh viên ở mỗi học kỳ được phép học tối đa – tốii thiểu bao nhiêu tín chỉ tổng cộng, chúng ta chỉ cần dựa vào những học phần mà sinh viên đãđăng ký cho học kỳ đó và tính tổng số tín chỉ của chúng là xong. Còn để kiểm tra số lượng sinhviên tối đa theo quy định cho mỗi lớp học phần ta chỉ việc sử dụng các biến đếm với giá trịkhởi gán là 0 cho mỗi lớp học phần tương ứng, rồi tăng nó lên một đơn vị mỗi khi có thêm mộtsinh viên đăng ký vào lớp học phần đó, đồng thời so khớp với số lượng sinh viên tối đa đượcấn định ngay khi lớp học phần đó được mở, và kết quả là cho phép sinh viên theo học lớp học

phần đó nếu biến đếm tương ứng vẫn chưa lớn hơn số lượng sinh viên tối đa như quy định đó.

Tuy nhiên, để kiểm tra các điều kiện học trước, tiên quyết và song hành của mỗi học phần,chúng ta phải nắm được các danh sách A1, A2 cho biết tất cả những học phần mà một sinh viênđã học, những học phần nào sinh viên đã học và có điểm thi kết thúc học phần lớn hơn hoặc





bằng năm. Đồng thời chúng ta cũng phải nắm được lần lượt các danh sách A3, A4, A5 các học phần thỏa mãn điều kiện học trước, tiên quyết và song hành của học phần đó, để rồi từ đó tìmkiếm xem tất cả những học phần này có nằm trong tập các tập A1/A2 hay không? Điều đó chothấy đây là công việc khá khó khăn và phức tạp, vì vậy việc đưa ra giải thuật và đánh giá độ

phức tạp của giải thuật cũng rất quan trọng trong đồ án này.

Khi đã xây dựng được giải thuật và chương trình tương ứng, yêu cầu về tính đơn giản củagiải thuật là rất cần thiết, đặc biệt là với ứng dụng xây dựng hệ thống đăng ký tín chỉ, với mộtkhối lượng dữ liệu đưa vào khá lớn thì vấn đề thời gian phải được xem xét. Vì vậy, yêu cầu đặtra là tốc độ, hơn nữa khối lượng dữ liệu quá lớn mà dung lượng bộ nhớ lại có giới hạn nên cũngkhông thể bỏ qua yêu cầu về tiết kiệm bộ nhớ được.

Lưu ý rằng, tất cả các giải thuật dưới đây đều tính cho thời điểm xét và được thực hiện ngaytrong hệ quản trị cơ sở dữ liệu SQL trước khi trả dữ liệu về cho đối tượng gọi. Trước hết, ta xétgiải thuật kiểm tra điều kiện học trước của học phần X ứng với sinh viên S như sau:

1) Yêu cầu: kiểm tra xem một sinh viên S có được phép học học phần X hay không?

2) Phác thảo giải thuật:

• Lấy tập những học phần có Điều_Kiện_Học_Phần = “Học trước” ở bảng dữ liệuđiều kiện học phần trong cơ sở dữ liệu của học phần X, và đưa vào tập hợp T1.

• Duyệt từng phần tử ai của tập hợp T1 trên:

Lấy tập những học phần sinh viên S đã học, và đưa vào tập hợp T2.

Kiểm tra ai có thuộc T2 hay không nếu ai không thuộc T2 thì điều kiện họctrước không được đảm bảo và dừng việc kiểm tra lại, kết luận sinh viên S khôngđược học học phần X; còn nếu đã duyệt hết các phần tử của T1 mà vẫn không rơivào trường hợp trên thì cũng dừng việc kiểm tra và kết luận sinh viên S được

phép học học phần X.

3) Mô phỏng hàm kiểm tra bằng giả ngữ :

Function HỌC_TRƯỚC(Học_Phần X, Sinh_Viên S):Boolean;

Begin

T1,T2 : Set;

T1 := ∅, T2 := ∅;

T2 := select HọcPhần from BảngKếtQuảThi where HọcPhần=X & SinhViên=S;

T1 := select HọcPhần from BảngĐiềuKiệnHọcPhần where HọcPhần=X &Điều_Kiện_Học_Phần=“Học trước”;

Với mỗi học phần ai của T1 chưa được kiểm tra thì làm

nếu ai ∉ T2 thì

{Có một học phần sinh viên chưa hoàn thành trước đó}

HỌCTRƯỚC := false;

{Đảm bảo điều kiện học trước, và cho phép sinh viên S theo học}

HỌCTRƯỚC := true;

End

4) Đánh giá độ phức tạp: với những quy tắc xác định độ phức tạp, ta thấy trong đoạn lệnh giảngữ trên các phép gán có thời gian thực hiện là hằng số nên độ phức tạp thời gian là O(1).Tiếp đến là câu lệnh lặp bên trong có câu lệnh nếu…thì và phép gán nên có độ phức tạp bậcmột, và gọi là O(n). Tuy nhiên, trong trường hợp này, thời gian thực hiện không chỉ phụthuộc vào kích thước dữ liệu mà còn phụ thuộc vào cả tình trạng dữ liệu nữa. Vì vậy, ta cần





phải xét đến cả độ phức tạp thời gian trung bình. Có thể thấy, trong trường hợp thuận lợinhất, tức là ngay khi xét phần tử đầu tiên của tập T1 thì điều kiện kiểm tra được thỏa mãnvà khi đó Ttốt = O(1); ngược lại với trường hợp xấu nhất, tức là phải duyệt tất cả các phần tửcủa tập T1 thì khi đó Txấu = O(n). Vậy độ phức tạp thời gian của giải thuật trường hợp xấunhất vẫn là O(n).

Như đã phân tích, việc kiểm tra điều kiện tiên quyết, song hành cũng giống như điều kiệnhọc trước, chỉ khác ở chỗ với điều kiện tiên quyết thì tập T2 phải thỏa điều kiện điểm thi học phần không dưới năm và với điều kiện song hành thì lệnh điều kiện là xét ai∈ T2 thì dừng đồngthời kết luận cho phép sinh viên theo học học phần X này. Do đó, việc đánh giá độ phức tạpcũng hoàn toàn tương tự và cho kết quả cũng giống nhau.




PHẦN V

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

Dựa vào những kết quả đạt được trong quá trình phân tích thiết kế nêu trên, chúng tôiđã tiến hành xây dựng hệ thống đăng ký tín chỉ trực tuyến OCRS với các trang cơ bảncùng các chức năng ở mỗi trang, và minh họa qua các hình dưới đây.

I. Trang chủ hệ thống OCRS

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

1. Hệ thống menu trái

STT Thành phần menu trái Miêu tả chức năng

1 Quay về trang chủ.

2 Giới thiệu thông tin các khoa trong trường.

3 Cho phép người dùng xem album hình ảnh vềcác hoạt động của khoa, của trường.




Xây dựng và triển khai hệ thống

STT Thành phần menu trái Miêu tả chức năng

4 Tra cứu điểm các kỳ đã học, chức năng nàyđược kế thừa từ chức năng tra cứu điểm trênwebsite hiện tại của trường (áp dụng cho đào

tạo niên chế).5 Cho phép sinh viên download giáo trình, tài

liệu cần thiết cho quá trình học, chức năng nàyđược kế thừa từ chức năng xem giáo trình trênwebsite hiện tại của trường.

6 Xem các văn bản, thông báo của trường cũngnhư của từng khoa, chức năng này được kếthừa từ chức xem văn bản & thông báo trênwebsite hiện tại của trường.

7 Cung cấp thông tin, địa chỉ khi cần liên lạc với

trường.

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

ii. Hệ thống menu trên

STT Thành phần menu trên Miêu tả chức năng

1 Cho phép truy cập vào các chức năng của nhómngười dùng quản trị hệ thống.

2 Cho phép truy cập vào các chức năng của nhóm

người dùng cán bộ đào tạo.

3 Cho phép truy cập vào các chức năng của nhómngười dùng giáo vụ khoa.

4 Cho phép truy cập vào các chức năng của nhómngười dùng giảng viên.

5 Cho phép truy cập vào các chức năng của nhómngười dùng sinh viên.

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

iii. Khung đăng nhập Người dùng có thể đăng nhập vào hệ thống bằng cách nhập mã người dùng vào ô “Mã User”và mật khẩu vào ô “Password”, sau đó click nút lệnh “Đăng nhập” ở góc dưới khung đăngnhập. Nếu thông tin nhập vào hợp lệ thì hệ thống sẽ chuyển đến trang chủ của mỗi nhóm đốitượng người dùng, ngược lại sẽ xuất hiện thông báo lỗi.

Người dùng có thể lưu mật khẩu cho lần truy cập sau bằng cách check vào ô chọn “Nhớ mậtkhẩu”.

iv. Đếm số người dùng đang truy cậpPhần này cho biết hiện tại có bao nhiêu người đang truy cập vào hệ thống.

v. Đồng hồ và lịchThông tin này hiển thị ngày giờ hiện tại, cụ thể để xem ngày người dùng cần click vào nútlệnh “Calendar” nằm bên mé phải của đồng hồ.





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

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

Các thành phần “Trang chủ”, “Tra Cứu Điểm”, “Giáo Trình”, “Văn Bản & Thông Báo” củahệ thống menu trái trong hình trên có chức năng tương tự các thành phần trong hệ thống menutrái đã nêu ở phần “Trang chủ hệ thống OCRS” nên chúng tôi sẽ không nhắc lại.


1 Lịch thi: hiển thị lịch thi lớp học phần đã

đăng ký. Thời khóa biểu: hiển thị thời khóa biểu các

lớp học phần đã đăng ký.

Đăng ký học phần: cho phép sinh viên đăngký các học phần muốn học.

Các học phần đã hoàn thành.

Xem thông tin cá nhân.

Thay đổi password.

2 Hướng dẫn quy trình đăng ký học phần.

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





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

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

Trang đăng ký học phần có hệ thống menu trái chứa các học phần sinh viên có thể đăng kýtrong học kỳ đã chọn ở phần chú thích “1. Chọn học kỳ cần đăng ký”. Khi chọn một học phầntrong menu trái, danh sách các lớp học phần sẽ hiển thị ở phần chú thích “3. Danh sách các lớphọc phần của một học phần”. Việc đăng ký được thực hiện khi người dùng nhấn nút lệnh

“Đăng ký học phần”. Kết quả đăng ký sẽ hiển thị ở phần chú thích “4. Danh sách các lớp học phần đã đăng ký”, nếu muốn chỉnh sửa kết quả đã đăng ký người dùng có thể hủy các lớp học phần đã chọn thông qua nút lệnh “Xóa học phần đã chọn”. Người dùng cũng có thể đề nghị cáchọc phần cần học thông qua nút lệnh “Đề nghị học phần”.





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

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

Chức năng các thành phần “Trang chủ”, “Thư Viện Ảnh”, “Văn Bản & Thông Báo”, “LiênHệ” của hệ thống menu trái trong hình trên đã được chúng tôi trình trình bày trong mục “Trangchủ hệ thống OCRS” nên sẽ không được trình bày lại ở đây.

STT Thành phần menu trên Miêu tả chức năng1 Lịch dạy: cho phép giảng viên xem ngày

giờ và địa điểm các lớp học phần mình dạy.

Xem danh sách sinh viên lớp sinh hoạt:danh sách các lớp sinh hoạt trong trường.

Xem danh sách sinh viên lớp học phần:danh sách sinh viên các lớp học phần.



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





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

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

Chức năng các thành phần “Trang chủ”, “Thư Viện Ảnh”, “Văn Bản & Thông Báo”, “LiênHệ” của hệ thống menu trái trong hình trên đã được chúng tôi trình bày trong mục “Trang chủhệ thống OCRS” nên sẽ không được trình bày lại.


1

Xem danh sách sinh viên lớp sinh hoạt:danh sách các lớp sinh hoạt trong trường.

Xem danh sách sinh viên lớp học phần:danh sách sinh viên các lớp học phần.

Danh sách sinh viên không đăng ký.

Danh sách sinh viên đăng ký chưa đạt số tínchỉ tối thiểu.







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

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

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

Chức năng thành phần “Trang chủ” trong hệ thống menu trái của trang màn hình lựa chọncán bộ đào tạo đã được chúng tôi đề cập trong mục “Trang chủ hệ thống OCRS” nên sẽ khôngđược nhắc lại ở đây.


1 Xem thông tin cá nhân. Thay đổi password





2 Tài khoản sinh viên: cho phép quản lý tàikhoản sinh viên, cụ thể tạo mới, xóa/khóa,chỉnh sửa, xem thông tin chi tiết sinh viên.

Tài khoản giảng viên: cho phép quản lý tàikhoản giảng viên, cụ thể tạo mới, xóa/khóa,chỉnh sửa, xem thông tin chi tiết giảng viên.


3 Lịch thi: quản lý lịch thi.

Thời khóa biểu: quản lý thời khóa biểu.

Chương trình đào tạo: quản lý chương trìnhđào tạo của cả trường.

Kết quả đăng ký của sinh viên: quản lý kết

quả đăng ký của sinh viên. Danh sách lớp học phần: quản lý lớp học

phần.

Danh sách lớp sinh hoạt: quản lý lớp sinhhoạt.

Danh sách học phần: quản lý học phần.

Điều kiện học phần: quản lý điều kiện học phần.

4 Nhập mới, chỉnh sửa điểm cho một lớp học

phần.

5 Danh sách sinh viên chưa đăng ký.

Danh sách sinh viên đăng ký chưa đạt.

Danh sách sinh viên lớp sinh hoạt.

Danh sách sinh viên lớp học phần.

6 Thời gian đăng ký: giới hạn khoảng thời

gian đăng ký học phần của sinh viên. Số tín chỉ Min/Max: giới hạn số tín chỉ tối

thiểu, tối đa sinh viên có thể đăng ký.





7 Trường: dữ liệu về các trường.

Danh sách các khoa.

Khu: danh sách các khu trong trường.

Phòng học: danh sách các phòng học.

Chức vụ: thông tin chức vụ. Học vị: danh sách các học vị.

Quốc tịch: thông tin quốc tịch.

Dân tộc: thông tin các dân tộc.

Tôn giáo: thông tin các tôn giáo.

Cấp đào tạo.

Khóa học: dữ liệu các khóa học.

Học kỳ: dữ liệu học kỳ.

Loại học kỳ. Đặc thù học phần.

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





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

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

Chức năng các thành phần “Trang chủ”, “Văn Bản & Thông Báo” của hệ thống menu tráitrong trang màn hình lựa chọn quản trị hệ thống đã được chúng tôi trình bày ở mục “Trang chủhệ thống OCRS” nên sẽ không được trình bày lại ở đây.


1 Quản lý tài khoản User: quản lý tài khoảnquản trị hệ thống, cán bộ đào tạo, giáo vụkhoa.



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




PHẦN VI

KẾT LUẬN

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

1. Về mặt lý thuyếtLàm thế nào để ứng dụng hoạt động nhanh, dễ nâng cấp, dễ bảo trì và có tính tái sử dụng

cao? Một ứng dụng chỉ đáp ứng được những yêu cầu trong hiện tại mà không có khả năng đápứng những yêu cầu mở rộng về sau thì không thể xem là một ứng dụng tốt. Thực tế tại nước tahiện nay, có rất nhiều phần mềm sản xuất trong nước ít có khả năng tái sử dụng và việc nângcấp sửa chữa cũng rất khó khăn, hãy tưởng tượng xem chuyện gì sẽ xảy ra với những phầnmềm dạng này khi người dùng yêu cầu thêm những chức năng mới hoặc yêu cầu quản lý củakhách hàng với hệ thống thay đổi? Chỉnh sửa mã nguồn chương trình là điều tất yếu, thậm chícó thể viết mới lại từ đầu. Giải quyết được những khó khăn nêu trên thực sự là một bài toán khócho tất cả các nhà phát triển phần mềm.

Luận văn này nêu ra một hướng giải quyết hiện nay đang được nhiều nhà phát triển phầnmềm lựa chọn, đó là sự kết hợp của quá trình phân tích ứng dụng dựa trên ngôn ngữ mô hình

hợp nhất UML và quá trình xây dựng ứng dụng theo mô hình ba tầng. Sự kết hợp trên đảm bảocho ứng dụng có khả năng nâng cấp, bảo trì dễ dàng, giảm khả năng phải sửa lại mã nguồnchương trình.

Có thể khẳng định rằng hệ thống quản lý đào tạo theo học chế tín chỉ là một hệ thống cực kỳ phức tạp. Nó bao gồm rất nhiều hệ thống con nằm bên trong như sắp xếp thời khóa biểu chosinh viên, quản lý quá trình đăng ký của sinh viên, quản lý điểm, quản lý hồ sơ sinh viên, quảnlý tài vụ v.v...

Có rất nhiều vấn đề cần nghiên cứu để xây dựng một ứng dụng quản lý tín chỉ hoàn chỉnh.Tuy nhiên trong đồ án tốt nghiệp này chúng em chỉ đặt ra một số yêu cầu để giải quyết, cụ thểchúng em chỉ giải quyết bài toán quản lý đăng ký tín chỉ. Với yêu cầu đặt ra như vậy chúng em

đã áp dụng giải pháp trên cho quá trình phân tích thiết kế hệ thống của mình. Chi tiết về nhữnglý thuyết nghiên cứu được chúng em đã trình bày khá rõ ràng trong các phần trước của luậnvăn. Đó chính là kết quả đạt được về mặt lý thuyết của đồ án.

ii. Về mặt thực tiễnDựa vào yêu cầu đặt ra ban đầu của đồ án, chúng em đã xây dựng thử nghiệm được hệ thống

đăng ký tín chỉ trực tuyến OCRS và đã đạt được một số kết quả sau:

Ứng dụng có giao diện thân thiện, hệ thống menu trợ giúp rõ ràng cộng với các bộ lọcvà tìm kiếm dữ liệu thông minh giúp người dùng thao tác thuận tiện và dễ dàng hơn.

Là một hệ thống có nhiều nhóm người dùng. Ứng dụng có khả năng quản lý tài khoảnngười dùng phân theo từng nhóm đối tượng. Với chức năng của mỗi nhóm đối tượng đã

được nêu rõ trong phần đặc tả ứng dụng. Với yêu cầu đặt ra của đồ án, ứng dụng quản lý đăng ký tín chỉ trực tuyến OCRS cho

phép sinh viên đăng ký các học phần với những ràng buộc về điều kiện học trước, songhành, tiên quyết, được kiểm tra một cách chính xác giúp sinh viên và cán bộ đào tạogiảm bớt thời gian và công sức rà soát lại các học phần đã đăng ký. Từ những kết quảđã đăng ký hệ thống sẽ thông báo cho sinh viên một thời khóa biểu cùng với lịch thi củacác học phần đã đăng ký, đồng thời sinh viên cũng biết được các học phần mình đãhoàn thành, các học phần còn nợ trong các kỳ trước để có kế hoạch học tập thích hợp.

Ngoài ra, hệ thống OCRS còn cho phép sinh viên tự đề nghị các học phần cần học đểcán bộ đào tạo xem xét việc mở lớp thông qua chức năng đề nghị học phần của sinh

viên. Chức năng này cho phép sinh viên có thể chủ động học những học phần mìnhmuốn học.




PHẦN VI

Ứng dụng cung cấp những chức năng linh động cho việc quản lý đăng ký tín chỉ. Giúpngười quản lý dễ dàng điều hành quá trình đăng ký của sinh viên với những số liệu




Kết luận

thống kê chính xác. Bên cạnh đó hệ thống OCRS cho phép người quản lý thiết lập lạicác thông số về khoảng thời gian đăng ký học phần, khoảng thời gian chỉnh sửa, số tínchỉ có thể đăng ký tối đa/tối thiểu. Điều đó làm cho hệ thống trở nên linh động hơn.

Hệ thống được thiết kế với khả năng kết hợp với các hệ thống quản lý khác trong hệthống quản lý đào tạo theo học chế tín chỉ.

Hệ thống OCRS được xây dựng trên tiêu chí bảo mật để giảm rủi ro sai lệch và mất mátdữ liệu có thể xảy ra, cụ thể chúng em đã cấu hình ứng dụng với những chức năng bảomật nhất định, password của tất cả nhóm người dùng bắt buộc phải có một ký tự đặc

biệt điều này giúp mật khẩu của mỗi tài khoản an toàn hơn, đồng thời hệ thống OCRScó khả năng chống lại các nguy cơ bảo mật phổ biến hiện nay như hiển thị các lỗi lậptrình hệ thống, Cross-site scripting, SQL-injection.

Với những kết quả đạt được ở trên, ứng dụng quản lý đăng ký tín chỉ trực tuyến có thểgóp phần giảm nhẹ chi phí cũng như đơn giản hóa công tác quản lý đăng ký tín chỉ củatrường.

Bên cạnh những kết quả khả quan, chương trình cũng có một số điểm cần lưu ý:

Cần cải thiện và cấu hình các tính năng bảo mật thêm nữa để đảm bảo hệ thống vậnhành một cách an toàn.

Tốc độ của chương trình cũng cần được cải tiến hơn.

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

Với việc thiết kế “mở”, trong tương lai hệ thống OCRS có khả năng kết hợp với các hệthống quản lý khác trong trường tạo thành một hệ thống quản lý đào tạo theo học chế tín chỉhoàn chỉnh.

Hệ thống OCRS làm cơ sở để hợp nhất cơ sở dữ liệu của tất cả các khoa trong trường cũng

như các trường thành viên của ĐHĐN, từ đó mở rộng và phát huy tối đa những ưu điểmcủa cơ chế đào tạo tín chỉ.




PHỤ LỤC

Tài liệu tham khảo:

[1] Joseph Schmuller ,“Sams Teach Yourself UML in 24 Hours, Third Edition”.

[2] TS.Dương Kiều Hoa – Tôn Thất Hòa, “Phân tích và thiết kế HTTT theo UML”.[3] Martin Fowler , “UML Distilled: A Brief Guide to the Standard Object Modeling

Language, Third Edition”.

[4] ThS.Phạm Nguyễn Cương và TS.Hồ Tường Vinh - Đại Học Khoa Học Tự Nhiên HCM,“Giáo trình phân tích và thiết kế hương đối tượng bằng ngôn ngữ UML”.

[5] Nguyễn Văn Ba, “Phát triển hệ thống hướng đối tượng với UML 2.0 và C++”.

[6] Nguyễn Quý Minh – Tăng Nguyễn Trung Hiếu – Phạm Anh Vũ – Lê Hải Dương,“Design Pattern”.

[7] Martin Fowler, “Patterns of Enterprise Application Architecture”.

[8] “Chương trình đào tạo, khóa 2006-2011, trường Đại học Bách khoa Đà Nẵng”.

[9] Phạm Hữu Khang – Hoàng Đức Hải, “Lập trình ứng dụng chuyên nghiệp SQL Server 2000”.

[10] Doug Lowe, “ASP.NET 2.0 Everyday Apps For Dummies”.

[11] Damon Armstrong, “Pro ASP.NET 2.0 Website Programming”.

[12] Mike Pastore and Emmett Dulaney, “Security+ Study Guide Second Edition”.

[13] Các tài liệu khác khai thác từ nguồn Internet.

http://www.informit.com/safari/author_bio.asp@ISBN=0321193687

http://www.informit.com/safari/author_bio.asp@ISBN=0321193687

Documents

Bao Cao Tot Nghiep - Hoan Chinh