BÁO CÁO XÂY DỰNG MÔ HÌNH 3 LỚP HỆ THỐNG HỌC PHÍ potx

BÁO CÁO XÂY DỰNG MÔ HÌNH 3 LỚP HỆ THỐNG HỌC PHÍ I. Khái quát về mô hình 3 lớp H1. Mô hình Three tiers Mô hình kiến trúc ứng dụng 3 lớp là một khuôn khổ cơ bản cho việc xây dựng thiết kế một hệ thống quản lý ở mức logic. Việc phân đoạn ứng dụng ra thành các lớp giúp cho việc quản lý dể dàng, tăng tính độc lập, tính dùng lại, tính tương thích củng như giúp cho việc bảo trì hệ thống dể dàng hơn. II. Xây dựng hệ thống học phí theo mô hình 3 lớp 1. Tầng dử liệu – Mô hình DataBase cho hệ thống Hệ cơ sở dử liệu thiết kế theo mô hình User Case dựng sẳn, thông qua yêu cầu khách hàng khi phân tích yêu cầu hệ thống, ta xây dựng DataBase gồm có các bảng dử liệu, các hàm dựng sẳn, các View và các StoreProcedure và các biểu đồ 1.1 Mối quan hệ giửa sinh viên và các khóa học H2. Student Course Relationship  Mổi sinh viên có thông tin cá nhân, thông tin khóa học (học kỳ) và thông tin về thẻ ngân hàng  Mỗi khóa học sẻ chứa thông tin về số tín chỉ và chi tiết khóa học. Số tín chỉ nhận được thông qua thông tin đăng ký môn học của sinh viên tại phòng đào tạo 1.2 Mối quan hệ giửa sinh viên và các chính sách hổ trợ H3. Student Policy Relationship  Nắm thông tin về miển giảm học phí của sinh viên  Cho biết sinh viên được hưởng những hổ trợ nào về học phí, tỷ lệ là bao nhiêu  Thông tin này do phòng công tác chính trị cung cấp cho phòng kế hoạch tài chính 1.3 Mối quan hệ giửa sinh viên và các lần đóng học phí H4. Student Tuition Relationship  Cho biết thông tin về các lần đóng học phí của sinh viên. Bao gồm số tiền đóng, ngày đóng, phương thức đóng là trực tiếp hay qua giao dịch ngân hàng  Mỗi sinh viên có thể đóng học phí trong học kỳ đó nhiều lần 1.4 Các View và các hàm dựng sẳn Ngoài các bảng dử liệu, trong hệ cơ sở dử liệu còn chứa các hàm và các View phục vụ cho việc thống kê các thông tin quan trọng. Có thể dùng View để tổng hợp danh sách sinh viên nợ học phí, xem xét các lần giao dịch và thông tin khác. Vì View không biểu diển được dưới dạng biểu đồ nền báo cáo không nêu ra ở đây. 2. Tầng dịch vụ - Mô hình nghiệp vụ và các cấu trúc dử liệu Thông qua mô hình dử liệu đã thiết kế ở tầng dử liệu, ta xây dựng bên trên là các mô hình nghiệp vụ và các cấu trúc dử liệu. Tầng dịch vụ ta chia làm 3 module là DataAdapter cùng các mô hình nghiệp vụ và TableMapped 2.1 DataAdapter – Bộ kết nối giữa DBMS với các dịch vụ và ứng dụng DataAdapter là một hệ thống cho phép ứng dụng thao tác với dử liệu, bao gồm có truy xuất dử liệu, cập nhật dử liệu và phóng ra các lổi liên quan đến việc tương tác với hệ cơ sở dử liệu từ ứng dụng. H5. Data Adapter Operation DataAdapter chỉ hiện thực được bằng mã chương trình, sau đây là một đoạn code mẩu viết bằng ngôn ngử C# namespace DataAdapter { public class ConnectionManager { private ConnectionManager() { } public static void GetData(DataTable table,string commandText) { table.Rows.Clear(); using (SqlConnection con = new SqlConnection(ConnectionString)) { SqlDataAdapter da = new SqlDataAdapter(commandText, con); da.Fill(table); } } } H6. Một phương thức GetData trong DataAdapter Ngoài ra trong module này củng chứa hệ thống nghiệp vụ như: 1. Thực hiện thu tiền học phí trực tiếp: Khi sinh viên đóng tiền học phí trực tiếp tại phòng kế hoạch tài chính, hệ thống hiển thị thông tin vắn tắt của sinh viên, thông tin nợ học phí và các học kỳ tương ứng, cho phép nhận dử liệu đóng học phí mới của sinh viên… 2. Thống kê lượng tiền đã thu trong từng đợt: Sau một đợt nộp học phí, hệ thống tổng hợp thông tin đóng học phí trong đợt đóng đó, thống kê xem lượng tiền thu là bao nhiêu… 3. Giải quyết đơn xin nợ học phí: Một số trường hợp sinh viên muốn gia hạn đóng học phí, hệ thống hổ trợ bằng cách đánh dấu sinh viên đó được phép nợ và kéo dài hạn đóng học phí của sinh viên. 4. Thống kê số lượng sinh viên nộp và không nộp học phí: Thông qua dử liệu, hệ thống tổng hợp và đưa ra số liệu thống kê giúp hổ trợ cung cấp thông tin bổ sung cho mục đích khác. 5. Thông báo gửi danh sách sinh viên nợ học phí cho phòng đào tạo: Hệ thống tổng hợp các thông tin có được xuất ra nhiều dạng dử liệu như Excel hay Xml, đồng thời cho phép in ra các tài liệu chứa thông tin về sinh viên chưa hoàn thành nghĩa vụ học phí cho phòng đào tạo 2.2 TableMapped – Cấu trúc dử liệu và các ràng buộc DataAdapter là đối tượng duy nhất trong hệ thống giao tiếp giửa tầng ứng dụng và tầng Data. Nhưng thực tế lại không như vậy. Khi DataAdapter truy vấn dử liệu, kết quả trả về lại không trả trực tiếp cho tầng ứng dụng mà lại được xử lý bởi module TableMapped trước khi gửi lên tầng ứng dụng TableMapped chứa thông tin và cấu trúc dử liệu ở một mức nào đó gần giống với cấu trúc dử liệu trong DataBase. Nhưng ngoài ra, TableMapped còn đảm nhận nhiệm vụ là xây dựng một cấu trúc dử liệu để hiển thị trên phía client. Các Request luôn xuất phát từ tầng ứng dụng. Các Request bao gồm co truy vấn dử liệu và thay đổi dử liệu. Khi truy vấn dử liệu, tầng ứng dụng gửi Request xuống tầng dịch vụ, DataAdapter sẻ giao tiếp với DBMS và trả kết quả là dử liệu thô. Từ dử liệu thô đó, TableMapped sinh ra dử liệu với cấu trúc hiển thị phù hợp với Form hiển thị tại tầng ứng dụng. Khi thay đổi dử liệu, trước khi một mẩu tin được gửi đến DataAdapter, TableMapped nắm giử các ràng buộc dử liệu, kiểm tra một mẩu tin là hợp lệ, sau đó gửi mẩu tin cùng các tham số và hành động tương ứng đến cho DataAdapter để thực hiện thay đổi dử liệu tại DBMS. 3. Tầng ứng dụng – trình diển dử liệu phía client Tầng ứng dụng bao gồm tập hợp các giao diện để giao tiếp với người dùng. Tầng ứng dụng nhận các Request, chuyển Request đến tầng dịch vụ và nhận kết quả trả về từ tầng dịch vụ để thông báo củng như hiển thị kết quả cho người dùng biết. Giao diện được xây dựng bằng các Form, trên các Form có các control bao gồm control hiển thị, control nhập dữ liệu và control điều khiển. Với control hiển thị, Tầng ứng dụng nhận cấu trúc dử liệu từ TableMapped cùng các định dạng (như định dạng ngày, định dang tiền, định dạng số v.v ) để hiển thị dử liệu một cách trực quan và sinh động cho người sử dụng hiểu được. Control nhập liệu cho phép người dùng điền thông tin cần thiết, thay đổi thông tin sẵn có củng như phát hiện lỗi nhập liệu đã được qui định trong module TableMapped để phát ra thông báo với người dùng. Control điều khiển cho phép người dùng gửi một Request đến tầng dịch vụ như các nút nhấn. III. Thiết kế chi tiết use-case đóng học phí trực tiếp 1. Mô tả nghiệp vụ Use-case mô tả quá trình đóng học phí trực tiếp của sinh viên tại phòng kế hoạch tài chính. Khi sinh viên đến đóng học phí tại phòng kế hoạch tài chính, Nhân viên thu học phí sẻ nhập MSSV của sinh viên đóng học phí và “kiểm tra” thông tin nợ học phí của sinh viên. Phòng KHTC chỉ thu tiền của sinh viên còn nợ, và thu không vượt quá khoảng tiền sinh viên nợ trong học kỳ đó. Khoảng nợ bao gồm có khoảng nợ các học kỳ trước và nếu có của học kỳ đó. Khi xác định là sinh viên có nợ học phí, phòng KHTC sẻ thu số tiền tương ứng, thêm dử liệu thu, in phiếu thu gửi cho sinh viên và hoàn tất quá trình đóng học phí trực của một sinh viên. Quá trình thu trực tiếp không xảy ra thường xuyên mà tốt chức thành các đợt thu nhất định. Sinh viên theo dỏi thông báo và đóng học phí theo thông báo của phòng KHTC. 2. Yêu cầu dử liệu Với các thông tin phân tích như trên, ta cần có thông tin về đợt đóng học phí, thông tin ngắn gọn về sinh viên và thông tin về tình hình nợ củng như lịch sử đóng học phí trong các học kỳ nợ học phí của sinh viên. 3. Thiết kế tầng Database Bảng dử liệu Student, lưu thông tin cơ bản của sinh viên Bảng dử liệu StudentCourse lưu thông tin tín chỉ trong học kỳ Bảng dử liệu StuPolicy lưu thông tin miển giảm trong học kỳ Bảng dử liệu TuitionFees lưu thông tin chi tiết một lần đóng Xây dựng bảng RoundTuitionFees chứa thông tin các đợt thu học phí Xây dựng View_TuitionFees chứa thông tin tổ hợp giửa bảng TuitionFees, bảng Student và bảng StudentCourse H7. Thiết kế tầng Database Từ View_TuitionFee(Thông tin đóng HP) và RoundTuitionFees (đợt đóng HP), ta sẻ lấy được thông tin đóng học phí trong một đợt nhất định Từ StuPolicy, Student, StudentCours, ta tính được số tiền HP trong học kỳ đó mà SV phải đóng. Kết hợp với StudentCours và TuitionFees ta tính tổng được số tiền HP mà sinh viên đã đóng cho một học kỳ nhất định Từ số tiền cần đóng và số tiền đã đóng, ta tính được số tiền nợ của SV trong một học kỳ tương ứng. Hàm UpdateData chỉ cập nhật dử liệu duy nhất cho bảng TuitionFees. 4. Thiết kế tầng dịch vụ Với module TableMapped, ta xây dựng cấu trúc dử liệu hiển thị danh sách các lần đóng học phí trong một đợt đóng, cấu trúc dử liệu hiển thị danh sách học kỳ nợ và cấu Student StudentCours TuitionFees View_TuitionFee RoundTuitionFees StuPolicy Student StudentCours GetData CalculateTuitionFee StudentCours TuitionFees SumFees Calc & Get Debt TuitionFees UpdateData trúc dử liệu cho thông tin đợt đóng, thông tin ngắn gọn về sinh viên và các ràng buộc dử liệu tương ứng Với DataAdapter ta xây dựng hàm lấy dử liệu về các lần đóng học phí của sinh viên trong một đợt cụ thể, xây dựng hàm lấy dử liệu về tình trạng nợ học phí của sinh viên tương ứng với một học kỳ mà sinh viên học, xây dựng hàm lấy thông tin về đợt đóng, hàm lấy thông tin cơ bản của sinh viên và một hàm cập nhật dử liệu vào DataBase H8. Các quá trình xử lý ở tầng dịch vụ List_Tuition_Fee Get_List_TuitionFee DataBase List_Course_In_Debt Get_Course_In_Debt Round_Tuition_Info Student_Short_Info Get_Round Tution_Info Update_Data To_DB Get_Student Short_Info Evalue data input 5. Thiết kế tầng ứng dụng Xây dựng các form hiển thị, gồm module hiển thị chính và module để xem và bổ cập nhật thông tin đóng học phí của một sinh viên như sau H9. Giao diện chính của module đóng học phí trực tiếp Trên giao diện hiển thị cơ bản dánh sách thu học phí, được nhóm theo từng ngày: [...]... nợ học phí học kỳ nào, năm học nào, học phí là bao nhiêu, đã đóng bao nhiêu và còn nợ lại bao nhiêu Có 2 link là chi tiết và thanh toán, link chi tiết khi click vào sẻ hiển thị một form cho biết các lần thanh toán học phí trong học kỳ đó Khi click vào link thanh toán, bên tab “các lân đóng trong học kỳ” sẻ được thêm một mẩu tin, trong đó số tiền đóng là số tiền nợ, học kỳ đóng là học kỳ nợ, năm học. .. số tiền đóng, học kỳ đóng, năm học Khi load chương trình, form này chỉ hiển thị những mẩu tin có ngày đóng học phí nằm trong đợt thu mà thôi Khi nhân viên phòng công tác chính trị nhập MSSV vào ô và bấm kiểm tra, một form khác hiện lên: H12 Tình trạng nợ của một sinh viên Trên form thông báo tình trạng nợ học phí của sinh viên và các lần đóng khác trong học kỳ Trong tab tình trạng nợ học phí, cho biết...H10 Các mẩu tin được nhóm theo ngày Bên dưới có thông tin đợt thu, học kỳ, năm học và các control: H11 Thông tin đợt đóng học phí và các control Ô MSSV để nhập MSSV vào kiểm tra Nút tìm kiếm cho phép tìm kiếm thông tin đóng học phí của sinh viên khi cần truy xuất lại thông tin Nút in phiếu cho phép in phiếu đóng học phí, nút xóa cho phép xóa một mẩu tin, nút sửa cho phép hiệu chỉnh thông tin... lân đóng trong học kỳ” sẻ được thêm một mẩu tin, trong đó số tiền đóng là số tiền nợ, học kỳ đóng là học kỳ nợ, năm học là năm học mà sinh viên nợ học phí H 13 Lịch sử các lần đóng tương ứng với các học kỳ nợ Nút xóa để xóa mẩu tin trong gridview bên tab “Các lần đóng trong học kỳ” và nút lưu là lưu thông tin để thay đổi Nút in cho phép in các mẩu tin được chọn tren grid Nút đóng để đóng form Trên Form . BÁO CÁO XÂY DỰNG MÔ HÌNH 3 LỚP HỆ THỐNG HỌC PHÍ I. Khái quát về mô hình 3 lớp H1. Mô hình Three tiers Mô hình kiến trúc ứng dụng 3 lớp là một khuôn khổ cơ bản cho việc xây dựng. thống dể dàng hơn. II. Xây dựng hệ thống học phí theo mô hình 3 lớp 1. Tầng dử liệu – Mô hình DataBase cho hệ thống Hệ cơ sở dử liệu thiết kế theo mô hình User Case dựng sẳn, thông qua yêu. form thông báo tình trạng nợ học phí của sinh viên và các lần đóng khác trong học kỳ. Trong tab tình trạng nợ học phí, cho biết sinh viên nợ học phí học kỳ nào, năm học nào, học phí là bao