TÌM HIỂU MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG QUẢN LÝ KÝ TÚC XÁ TRƯỜNG ĐẠI HỌC QUẢNG NAM - Full 10 điểm

TRƯỜNG ĐẠI HỌC QUẢNG NAM KHOA CÔNG NGHỆ THÔNG TIN ---------- KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC TÌM HIỂU MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM VÀ ỨNG DỤNG XÂY DỰNG HỆ THỐNG QUẢN LÝ KÝ TÚC XÁ TRƯỜNG ĐẠI HỌC QUẢNG NAM Sinh viên thực hiện: Bùi Lê Quốc Nam MSSV: 2112011015 CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN KHÓA 2012 – 2016 Giảng viên hướng dẫn: ThS. ĐỖ QUANG KHÔI Quảng Nam, tháng 04 năm 2016 LỜI CẢM ƠN Trước hết tôi xin gửi lời cảm ơn sâu sắc đến ThS. Đỗ Quang Khôi, người đã trực tiếp hướng dẫn, giúp đỡ, định hướng và đóng góp ý kiến cho tôi trong suốt thời gian làm bài để tôi có thể hoàn thành Khóa luận tốt nghiệp này. Tôi xin chân thành cảm ơn tất cả thầy, cô giáo trường Đại học Quảng Nam. Đặc biệt là các thầy, cô trong Khoa Công nghệ thông tin của trường đã tận tình dạy dỗ và truyền đạt kiến thức cho tôi trong suốt quá trình học tập và nghiên cứu tại trường, tạo điều kiện thuận lợi cho tôi trong thời gian cuối khóa để hoàn thành chương trình tốt nghiệp. Tôi cũng gởi lời cảm ơn đến Trung tâm học liệu và Công nghệ thông tin – Trường Đại học Quảng Nam đã tạo môi trường, điều kiện giúp đỡ cho tôi trong suốt quá trình thực tập tốt nghiệp và những kinh nghiệm trong thực tế. Đồng thời, tôi cũng gởi lời cảm ơn đến gia đình, bạn bè đã động viên, giúp đỡ tôi lúc khó khăn trong học tập và trong cuộc sống. -i- MỤC LỤC DANH MỤC TỪ VIẾT TẮT.............................................................................. iv DANH MỤC HÌNH VẼ ....................................................................................... v Phần 1. MỞ ĐẦU ................................................................................................. 1 1.1. Lý do chọn đề tài ..................................................................................... 1 1.2. Mục đích nghiên cứu ............................................................................... 2 1.3. Đối tượng và phạm vi nghiên cứu ........................................................... 2 1.4. Phương pháp nghiên cứu ......................................................................... 2 1.5. Lịch sử nghiên cứu .................................................................................. 2 1.6. Đóng góp của đề tài ................................................................................. 2 1.7. Cấu trúc của khóa luận ............................................................................ 3 Phần 2. NỘI DUNG NGHIÊN CỨU .................................................................. 4 Chương 1: TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM .......................... 4 1.1. Khái niệm kiến trúc phần mềm ................................................................ 4 1.1.1. Khái niệm .......................................................................................... 4 1.1.2. Lịch sử kiến trúc phần mềm .............................................................. 5 1.1.3. Tầm quan trọng của kiến trúc phần mềm ......................................... 6 1.2. Phân loại mô hình kiến trúc ..................................................................... 7 1.2.1. Mô hình đơn lập ................................................................................ 7 1.2.2. Mô hình phân tán .............................................................................. 7 1.2.2.1. Đặc điểm..................................................................................... 7 1.2.2.2. Đặc tính ...................................................................................... 8 1.2.2.3. Một số mô hình phân tán ............................................................ 8 1.3. Xử lý dữ liệu với ADO.NET ................................................................. 11 1.3.1. Tính năng của ADO.NET ................................................................ 11 1.3.2. Kiến trúc tổng quan của ADO.NET ................................................ 12 1.3.3. Tổng quan về các mô hình xử lý dữ liệu trong ADO.NET .............. 13 1.3.3.1. Mô hình kết nối ........................................................................ 13 1.3.3.2. Mô hình ngắt kết nối ................................................................ 14 1.3.4. Lựa chọn giữa mô hình Kết nối và mô hình Ngắt kết nối ............... 15 -ii- 1.4. Kết luận chương 1.................................................................................. 16 Chương 2: MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM .................... 17 2.1. Mô hình MVC........................................................................................ 17 2.1.1. Kiến trúc mô hình MVC .................................................................. 17 2.1.2. Đặc điểm mô hình MVC .................................................................. 17 2.1.3. Các thành phần của ASP.NET MVC............................................... 18 2.1.4. Lợi ích của mô hình MVC ............................................................... 19 2.2. Mô hình MVVM .................................................................................... 19 2.3. Mô hình đa tầng (n-Tier) ....................................................................... 20 2.3.1. Khái niệm ........................................................................................ 21 2.3.2. Các thành phần của mô hình 3 tầng ............................................... 21 2.3.3. Tính chất của 3-Tier........................................................................ 22 2.3.4. Ưu, nhược điểm của 3-tier .............................................................. 24 2.4. Mô hình 3-Layer .................................................................................... 24 2.4.1. Khái niệm ........................................................................................ 24 2.4.2. Các thành phần của 3-Layer........................................................... 25 2.4.3. Ưu điểm khi sử dụng mô hình 3-Layer ........................................... 27 2.5. So sánh các mô hình kiến trúc phần mềm ............................................. 28 2.5.1. So sánh mô hình 3-Tier và mô hình MVC ....................................... 28 2.5.2. So sánh 3-tier và 3-layer ................................................................. 29 2.6. Kết luận chương 2.................................................................................. 31 Chương 3: XÂY DỰNG HỆ THỐNG QUẢN LÝ KÝ TÚC XÁ TRƯỜNG ĐẠI HỌC QUẢNG NAM .............................................................................. 32 3.1. Khảo sát hệ thống .................................................................................. 32 3.1.1. Tổng quan về tổ chức ...................................................................... 32 3.1.1.1. Mô tả khái quát về tổ chức ....................................................... 32 3.1.1.2. Mục tiêu tổ chức ....................................................................... 33 3.1.1.3. Cơ cấu tổ chức .......................................................................... 33 3.1.2. Các quy trình hoạt động nghiệp vụ ................................................. 34 3.2. Phân tích và thiết kế hệ thống ................................................................ 41 3.2.1. Các yêu cầu của hệ thống mới ........................................................ 41 3.2.1.1. Mục tiêu của hệ thống .............................................................. 41 -iii- 3.2.1.2. Yêu cầu phi chức năng ............................................................. 41 3.2.1.3. Yêu cầu chức năng ................................................................... 41 3.2.2. Phân tích hệ thống .......................................................................... 42 3.2.2.1. Các tác nhân của hệ thống ........................................................ 42 3.2.2.2. Ca sử dụng của hệ thống .......................................................... 42 3.2.2.3. Biểu đồ ca sử dụng (Use Case) của hệ thống ........................... 43 3.2.2.4. Đặc tả ca sử dụng ..................................................................... 44 3.2.3. Mô hình cấu trúc của Hệ thống ...................................................... 50 3.2.3.1. Xác định các lớp thực thể ......................................................... 50 3.2.3.2. Xác định các lớp biên ............................................................... 51 3.2.3.3. Xác đinh các lớp điều khiển ..................................................... 53 3.2.4. Mô hình hành vi của Hệ thống ........................................................ 53 3.2.4.1. Mô hình tuần tự ........................................................................ 53 3.2.4.2. Biểu đồ hoạt động .................................................................... 58 3.2.5. Thiết kế ............................................................................................ 59 3.2.5.1. Cơ sở dữ liệu của hệ thống ....................................................... 59 3.2.5.2. Biều đồ định hướng giao diện người dùng ............................... 67 3.2.6. Cài đặt hệ thống .............................................................................. 69 3.3. Cài đặt kiến trúc chương trình theo mô hình 1- tier, 3 layer ................. 69 3.4. Một số giao diện chính của chương trình .............................................. 72 3.5. Kết luận chương 3.................................................................................. 74 Phần 3. KẾT LUẬN ........................................................................................... 75 Phần 4. TÀI LIỆU THAM KHẢO ................................................................... 76 -iv- DANH MỤC TỪ VIẾT TẮT Tên viết tắt Tên đầy đủ KTX Kí túc xá KTPM Kiến trúc phần mềm GUI Graphic User Interface BLL Business Logic Layer DAL Data Access Layer DTO Data Tranfer Object MVC Model-View-Controler MVVM Model-View-ViewModel TTHTSV Trung tâm hỗ trợ sinh viên UC Use case -v- DANH MỤC HÌNH VẼ Hình 1.1. Mô hình Client – Server ......................................................................... 8 Hình 1.2. Mô hình 3-Tier ....................................................................................... 9 Hình 1.3. Mô hình Peer-To-Peer với kiến trúc không tập trung .......................... 10 Hình 1.4. Mô hình Peer-To-Peer với kiến trúc bán tập trung .............................. 11 Hình 1.5. Kiến trúc tổng quan của ADO.NET ..................................................... 12 Hình 1.6. Mô hình kết nối .................................................................................... 13 Hình 1.7. Mô hình ngắt kết nối ............................................................................ 14 Hình 2.1. Mô hình MVC trong ASP.NET ........................................................... 17 Hình 2.2. Các thành phần của MVC .................................................................... 18 Hình 2.3. Các thành phần của mô hình MVVM .................................................. 19 Hình 2.4. Các tầng trong mô hình 3-tier và nhiệm vụ của nó .............................. 22 Hình 2.5. Mô hình 3-Tier giảm sự gắn kết giữa các thực thể .............................. 23 Hình 2.6. Mô hình 3-Tier giúp dễ dàng tái sử dụng phần mềm ........................... 23 Hình 2.7. Mô hình 3-Tier giúp dễ dàng chia sẻ trách nhiệm ............................... 23 Hình 2.8. Các thành phần của mô hình 3-Layer .................................................. 25 Hình 2.9. Quá trình xử lý của kiến trúc 3 tầng..................................................... 28 Hình 2.10. Quá trình xử lý của mô hình MVC .................................................... 29 Hình 2.11. Mô hình 3-Tier mang tính vật lý ........................................................ 30 Hình 2.12. Mô hình 3-Layer mang tính logic ...................................................... 30 Hình 3.1. Cơ cấu tổ chức của Trung tâm hỗ trợ sinh viên ................................... 32 Hình 3.3. Kiến trúc của chương trình demo theo mô hình 1-Tier, 3-Layer ......... 71 Hình 3.4. Giao diện Đăng nhập của chương trình ............................................... 72 Hình 3.5. Giao diện chính của chương trình ........................................................ 72 Hình 3.6. Cửa sổ nhập thông tin SV mới ............................................................. 73 Hình 3.7. Cửa sổ chuyển sinh viên qua phòng khác ............................................ 73 Hình 3.8. Cửa sổ tính phí điện nước từng phòng ................................................. 74 -1- Phần 1. MỞ ĐẦU 1.1. Lý do chọn đề tài Kiến trúc phần mềm là một chuyên ngành bắt đầu từ những năm 70 của thế kỷ trước. Với việc gia tăng độ phức tạp và áp lực về việc phát triển các hệ thống thời gian thực phức tạp, kiến trúc phần mềm (KTPM) nổi lên như là một kiến trúc cơ sở của việc phát triển phần mềm và công nghệ hệ thống chủ lực. Như bất kỳ lĩnh vực nghiên cứu nào khác, KTPM cũng có những thách thức ban đầu của nó. Một KTPM thể hiện các phương diện cấu trúc và hành vi của một hệ thống. Các nhà phát triển phần mềm rất coi trọng KTPM vì nó quyết định mối quan hệ giữa các thành phần trong phần mềm, phát triển module, tái sử dụng sau này. Ban đầu với những chương trình đơn giản, KTPM được thiết kế đơn giản với việc thiết kế thuật toán, cấu trúc dữ liệu... dần dần khi những phần mềm lớn ra đời, việc điều phối, quản lý con người, quản lý thành phần phần mềm, quản lý tiến trình phát triển dự án... đã hình thành những KTPM và những mẫu phần mềm. Trong phát triển ứng dụng hiện nay, để 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 nhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫn nhau. Điều này có nghĩa là ứng dụng được phát triển theo kiểu phân tán, các thành phần của hệ thống đảm nhận những vai trò, nhiệm vụ khác nhau. KTX của nhà trường hiện đang quản lý theo cách truyền thống. Việc đăng ký và quản lý thủ công gây nên nhiều khó khăn, tốn thời gian và gây lãng phí cả về công sức và tiền bạc. Chính vì những lí do trên nên tôi đã chọn đề tài “ Tìm hiểu một số mô hình kiến trúc phần mềm và ứng dụng xây dựng hệ thống Quản lý ký túc xá Trường Đại học Quảng Nam” làm Khóa luận tốt nghiệp. -2- 1.2. Mục đích nghiên cứu - Nắm vững những kiến thức cơ bản về KTPM, mô hình MVC và đặc biệt là kiến trúc 3 lớp. - Áp dụng kiến trúc 3 lớp vào việc Xây dựng hệ thống Quản lý ký túc xá trường Đại học Quảng Nam 1.3. Đối tượng và phạm vi nghiên cứu - Kiến thức cơ bản và kiến trúc phần mềm - Kiến thức về MVC và kiến trúc đa tầng. - Ứng dụng mô hình kiến trúc 1-tier, 3-layers vào xây dựng 1 hệ thống. 1.4. Phương pháp nghiên cứu - Nghiên cứu tài liệu, giáo trình, luận văn, bài báo, thông tin trên mạng. - Phân tích, tổng hợp tài liệu. - Thống kê, phân tích dữ liệu. 1.5. Lịch sử nghiên cứu Kiến trúc phần mềm đã được một số tác giả tìm hiểu và nghiên cứu trước đó. Phần lớn các tác giả đều cho thấy một cách tổng quan về nội dung lý thuyết của KTPM và kiến trúc 3 lớp đồng thời cũng xây dựng một hệ thống phù hợp với môi trường và bản thân tác giả. Với những ưu điểm của mình thì lập trình 3 lớp đã được sử dụng trong nhiều hệ thống lớn tuy nhiên nó còn khá mới mẻ đối với sinh viên trường Đại học Quảng Nam. 1.6. Đóng góp của đề tài Đề tài được nghiên cứu nhằm trình bày tổng quan về các KTPM. Trình bày những kiến thức cơ bản và tổng quan về KTPM và một số mô hình KTPM tiêu biểu nhất. Xây dựng chương trình ứng dụng trong việc quản lý kí túc xá trường Đại học Quảng Nam -3- 1.7. Cấu trúc của khóa luận Lời cảm ơn Mục lục Danh mục các ký hiệu, các chữ viết tắt Danh mục các bảng Danh mục các hình vẽ, đồ thị MỞ ĐẦU 1. Lý do chọn đề tài 2. Mục đích nghiên cứu 3. Đối tượng và phạm vi nghiên cứu 4. Phương pháp nghiên cứu 5. Lịch sử nghiên cứu 6. Đóng góp của đề tài NỘI DUNG Chương 1: Tổng quan về kiến trúc phần mề m Chương 2: Một số mô hình kiến trúc phần mề m Chương 3: Xây dựng hệ thống quản lý ký túc xá trường Đại họ c Quảng Nam KẾT LUẬN TÀI LIỆU THAM KHẢO PHỤ LỤC -4- Phần 2. NỘI DUNG NGHIÊN CỨU Chương 1: TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM 1.1. Khái niệm kiến trúc phần mềm 1.1.1. Khái niệm Nhiều nhà nghiên cứu đã giải thích về kiến trúc phần mềm, và họ có các quan điểm khác nhau về cách trình bày tốt nhất về kiến trúc của hệ thống phần mềm. Không có cách giải thích nào là sai; mỗi kiến trúc có giá trị riêng. Định nghĩa của Bass L, và cộng sự nắm giữ được điểm cốt yếu của cái mà kiến trúc phần mềm đòi hỏi: “Kiến trúc phần mềm của một chương trình hoặc hệ thố ng tính toán là cấu trúc hoặc các cấu trúc của hệ thống đó, gồm các thành phần củ a phần mềm, các thuộc tính có thể trông thấy được từ bên ngoài củ a các thành phần này, và các mối quan hệ giữa chúng” . Định nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô (coarse- grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the architecture). Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ phận kiến trúc cơ bản còn lại. Các chi tiết bên trong của sự thiết kế và cài đặt thành phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần mềm đặc biệt chỉ như một hộp đen. Hộp đen này có các thuộc tính nhất định mà nó biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung các đích nghiệp vụ hoặc công nghệ thông tin. Kiến trúc phần mềm xác định các khối kiến trúc cơ bản, với một mức độ chi tiết thích hợp. Nó cũng xác định và viết tư liệu việc các bộ phận cơ bản liên quan lẫn nhau như thế nào. Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây -5- dựng theo kiểu lặp lại, gia tăng, và độc lập. Các bộ phận riêng lẻ có các mối quan hệ hiện với nhau. Khi đan xen vào nhau, các bộ phận riêng lẻ đó tạo nên kiến trúc của hệ thống, tổ chức, hoặc ứng dụng. Ngoài ra, thuật ngữ “kiến trúc phần mềm” cũng đề cập đến các tài liệu kiến trúc phần mềm của một hệ thống, thuận tiện cho việc trao đổi thông tin giữa các thành viên trong một dự án. KTPM giúp việc quyết định ở mức cao trong thiết kế phần mềm dễ dàng hơn và cho phép tái sử dụng các thành phần và mẫu thiết kế của các dự án. Lĩnh vực khoa học máy tính trải qua sự kết hợp các vấn đề cùng với sự phức tạp của cấu trúc. Lúc đầu, sự phức tạp được giải quyết bởi người phát triển bằng cách lựa chọn các cấu trúc dữ liệu đúng đắn, phát triển các thuật toán và áp dụng các thuật toán để chia nhỏ các vấn đề. Khái niệm “Kiến trúc phần mềm” tập trung vào việc giảm tải các phức tạp bằng cách trừu tượng hóa vấn đề và phân chia rõ trách nhiệm công việc. Tuy vậy, đến ngày nay vẫn chưa có một khái niệm thật chính xác và rõ ràng cho thuật ngữ “Kiến trúc phần mềm”. Như vậy mặc dù khái niệm “Kiến trúc phần mềm” đã xuất hiện trong các giảng đường đại học và được đưa vào sử dụng trong ngành công nghệ phần mềm, nhưng việc nó vẫn chưa có các quy tắc, luật lệ chung và chưa rõ ràng nên thiết kế KTPM vẫn là một sự pha tạp giữa “khoa học” và “nghệ thuật”. Vẻ “nghệ thuật” của kiến trúc phần mềm được lý giải là do có sự xuất hiện của các yêu cầu phi chức năng của hệ thống mà phần mềm phải đáp ứng được các yêu cầu này, chẳng hạn như các yêu cầu về các thuộc tính chất lượng. Ngoài ra, phần mềm còn phải thỏa mãn các yêu cầu khác như: khả năng chịu lỗi, tính tương thích với các phiên bản cũ của các phần mềm khác (backward compatibility), khả năng mở rộng, tính tin cậy, khả năng bảo trì, tính hiện hữu, tính bảo mật, tính dễ dùng, và một số các yêu cầu khác nữa. 1.1.2. Lịch sử kiến trúc phần mềm Nguồn gốc của kiến trúc phần mềm như một ý tưởng được giới thiệu đầu tiên trong nghiên cứu của Edsger Dijkstra năm 1968 và David Parnas đầu những -6- năm 1970. Các nhà khoa học nhấn mạnh rằng cấu trúc của một hệ thống phần mềm rất quan trọng và đạt được cấu trúc đúng đắn là một yếu tố quyết định. Các nghiên cứu về lĩnh vực này ngày càng nhiều và trở nên phổ biến từ đầu những năm 1990 cùng với các nghiên cứu tập trung vào các mẫu thiết kế (pattern), ngôn ngữ đặc tả kiến trúc (Architecture Description Languages), tài liệu kiến trúc và các phương pháp chính thức. Các viện nghiên cứu đóng vai trò quan trọng trong nghiên cứu môn học KTPM. Mary Shaw và David Garlan của viện nghiên cứu Carnegie Mellon đã viết cuốn sách “Software Architecture: Perspectives on an Emerging Discipline” vào năm 1996, mang đến các khái niệm tiến bộ trong KTPM như thành phần, kết nối (connector), kiểu (style) và nhiều thứ nữa. Trường đại học tổng hợp California, viện nghiên cứu phần mềm Irvine cũng có nhiều nỗ lực trong nghiên cứu KTPM, chủ yếu hướng vào các kiểu kiến trúc, ngôn ngữ đặc tả kiến trúc và các kiến trúc động. Một trong những chuẩn đầu tiên trong KTPM là chuẩn ANSI/IEEE 1471-2000 được ISO chấp nhận như ISO/IEC DIS 25961. 1.1.3. Tầm quan trọng của kiến trúc phần mềm Có 3 lý do chính để giải thích tầm quan trọng của KTPM:  Hỗ trợ giao tiếp Hỗ trợ việc giao tiếp với các thành viên trong dự án. KTPM tái hiện một vẻ bề ngoài trừu tượng của hệ thống. Với sự trừu tượng hóa hệ thống với các khái niệm dễ hiểu, những thành viên trong dự án sẽ chỉ cần vận dụng các kiến thức cơ bản của mình về hệ thống trong việc tìm hiểu, dàn xếp, phối hợp làm việc, và bàn bạc trao đổi với nhau.  Giúp ra quyết định sớm hơn Việc ra quyết định được thực hiện sớm hơn. KTPM biểu thị các quyết định thiết kế dành cho hệ thống. Như vậy các đội tham gia phát triển, triển khai, kiểm thử và bảo trì phần mềm cũng như các nhóm người dùng và các cấp quản lý sẽ có cái nhìn tổng quan hơn cũng như sớm hơn về hệ thống ngay từ khi nó còn sơ khai. Mỗi đội đó sẽ có các đóng góp ý kiến của mình, các đề xuất cũng như các -7- phản bác của mình khi mọi chuyện chưa quá muộn. Nếu không có quyết định sớm, thì khi phần mềm đã được xây dựng hoàn chỉnh hoặc khá hoàn chỉnh mà đột ngột xuất hiện các yêu cầu thay đổi từ phía nhóm này hoặc nhóm khác, ngoài việc gây trì trệ cho tiến độ công việc mà còn có thể gây ra tâm lý căng thẳng, mâu thuẫn giữa các đội tham gia trong dự án.  Tính khả chuyển cho hệ thống KTPM không phụ thuộc vào một ngôn ngữ cụ thể nào cả mà chỉ tuân theo một số chuẩn của các ngôn ngữ đặc tả nó. Ngoài ra, KTPM khi được xây dựng cho một hệ thống, nó tạo thành một mô hình có sự gắn kết tương đối với hệ thống. KTPM còn chỉ ra cách thức mà phần mềm làm việc với hệ thống. Do vậy, khi ta muốn chuyển phần mềm sang làm việc ở các hệ thống khác có những điểm tương đồng nhất định với hệ thống cũ thì phần mềm này cũng sẽ có các thuộc tính chất lượng và các yêu cầu chức năng được đảm bảo là không quá khác so với khi tồn tại ở hệ thống cũ. 1.2. Phân loại mô hình kiến trúc 1.2.1. Mô hình đơn lập Là một thể thống nhất, không có sự phân nhóm và các thành phần trong mô hình đơn lập thì tự do tương tác.  Ưu điểm: + Dễ lập trình và triển khai. + Tốc độ xử lý cao.  Nhược điểm: + Khó bảo trì, nâng cấp. + Không chia sẻ dữ liệu. 1.2.2. Mô hình phân tán 1.2.2.1. Đặc điểm - Chia sẻ tài nguyên: chia sẻ tài nguyên phần cứng và phần mềm. - Tính mở: Cho phép sử dụng phần mềm và thiết bị của các nhà cung cấp khác nhau. -8- - Xử lý đồng thời: Nâng cao hiệu năng của hệ thống. - Tính mềm dẻo: Cho phép thêm mới tài nguyên một cách dễ dàng. - Khả năng chịu lỗi: Cho phép hệ thống tiếp tục vận hành khi lỗi phát sinh. 1.2.2.2. Đặc tính - Tính phức tạp: hệ thống phân tán phức tạp hơn hệ thống tập trung. - Tính an toàn: Dễ bị tấn công từ bên ngoài. - Tính quản lý được: Cần nhiều công sức hơn để quản lý hệ thống. - Không thể dự đoán trước: Khả năng đáp ứng không được dự đoán trước do phụ thuộc vào phương thức tổ chức hệ thống và khả năng chịu tải của hệ thống mạng. 1.2.2.3. Một số mô hình phân tán  Mô hình Client – Server: - Là mô hình tổ chức trong đó các dịch vụ được cung cấp bởi server (chương trình chủ) và client (chương trình khách) sử dụng các dịch vụ đó (máy tính trên đó cài đặt chương trình chủ gọi là máy chủ). - Client gửi yêu cầu (request) tới server, server tiếp nhận, xử lý vả trả về kết quả cho client. - Client biết server nhưng server không cần biết client. - Để client-server giao tiếp được với nhau cần tuân theo chuẩn, gọi là giao thức. - Một server có thể nối tới nhiều server khác để tăng hiệu quả xử lý. - Client và server là các tiến trình logic. Hình 1.1. Mô hình Client – Server -9-  Ưu điểm: + Dữ liệu chia sẻ và đồng bộ. + Hạn chế tương tác. + Dễ bảo trì, nâng cấp, cô lập lỗi.  Nhược điểm: + Chi phí triển khai. + Tốc độ xử lí.  Mô hình 3 – Tiers: Được phân thành 3 tầng: * Tầng giao diện (Presentation tier): Các thực thể phần mềm làm nhiệm vụ nhập liệu, trình bày, hiển thị, có thể bao gồm bước kiểm tra dữ liệu trước khi gọi Business Logic Tier và tương tác với người sử dụng. * Tầng xử lý (Business tier): Các thực thể phần mềm thực hiện các chức năng nghiệp vụ, chứa các xử lý chính và quản lý các transaction. * Tầng dữ liệu (Data tier): các thực thể phần mềm làm nhiệm vụ lưu trữ dữ liệu, tương tác với cơ sở dữ liệu (thêm, xóa, sửa, chọn). Hình 1.2. Mô hình 3-Tier -10-  Ưu điểm: + Tương tự mô hình Client–Server. + Xử lý chia sẻ và được chia nhỏ.  Khuyết điểm: + Tương tự mô hình Client-Server. Trong Chương 2 của Khóa luận sẽ trình bày cụ thể hơn về mô hình này.  Mô hình Peer - To - Peer (mô hình ngang hàng): - Là mô hình không tập trung, trong đó việc tính toán có thể được thực hiện ở bất cứ nút nào trên mạng. - Triển khai trên nhiều máy (node). - Các node tương tác được với nhau. - Mỗi node đóng vai trò Client – Server. - Chia sẻ dữ liệu và xử lý trên toàn bộ node. - Ngoài mô hình Peer-To-Peer có kiến trúc không tập trung truyền thống còn có mô hình kiến trúc bán tập trung. Hình 1.3. Mô hình Peer-To-Peer với kiến trúc không tập trung -11- Hình 1.4. Mô hình Peer-To-Peer với kiến trúc bán tập trung  Ưu điểm: + Không cần Server trung tâm. + Không gian lưu trữ và khả năng xử lý dàn trải + Dễ triển khai.  Nhược điểm: + Khó lập trình và quản lý dữ liệu. 1.3. Xử lý dữ liệu với ADO.NET Xử lý dữ liệu là nhiệm vụ phổ biến và quan trọng của nhiều chương trình ứng dụng. Dữ liệu được truy xuất, xử lý của một chương trình ứng dụng có thể là một tập tin văn bản, tập tin các bản ghi, hay là một nguồn dữ liệu từ CSDL nào đó. ADO.NET là một tập các lớp nằm trong bộ thư viện lớp cơ sở của .NET Framework, cho phép các ứng dụng windows (như C#, VB.NET) hay ứng dụng Web (như ASP.NET) thao tác dễ dàng với các nguồn dữ liệu. 1.3.1. Tính năng của ADO.NET * Hỗ trợ lập trình: Cung cấp các lớp thao tác với CSDL giúp lập trình viên lập trình nhanh hơn và giảm bớt lỗi. -12- Cung cấp các công cụ để thao tác với CSDL ngay trên phần Designer giúp lập trình viên tương tác với CSDL mà không cần hiểu sâu về CSDL. * Khả năng mở rộng: Sử dụng kiến trúc không kết nối chỉ kết nối với dữ liệu khi cần thiết nên giảm tải cho server CSDL -> Ứng dụng có thể đáp ứng nhiều người dùng hơn. * Khả năng tích hợp: ADO.NET có thể gửi dữ liệu cho bất cứ ứng dụng nào hỗ trợ XML. 1.3.2. Kiến trúc tổng quan của ADO.NET ADO.NET được chia ra làm hai phần chính rõ rệt, được thể hiện qua hình 1.5: Hình 1.5. Kiến trúc tổng quan của ADO.NET DataSet là thành phần chính cho đặc trưng kết nối không liên tục của kiến trúc ADO.NET. DataSet được thiết kế để có thể thích ứng với bất kỳ nguồn dữ liệu nào. DataSet chứa một hay nhiều đối tượng DataTable mà nó được tạo từ tập các dòng và cột dữ liệu, cùng với khoá chính, khóa ngoại, ràng buộc và các thông tin liên quan đến đối tượng DataTable này. Bản thân DataSet được dạng như một tập tin XML. Thành phần chính thứ hai của ADO.NET chính là NET Provider Data, nó chứa các đối tượng phục vụ cho việc thao tác trên cơ sở dữ liệu được hiệu quả và nhanh chóng, nó bao gồm một tập các đối tượng Connection, Command, -13- DataReader và DataAdapter. Đối tượng Connection cung cấp một kết nối đến cơ sở dữ liệu, Command cung cấp một thao tác đến cơ sở dữ liệu, DataReader cho phép chỉ đọc dữ liệu và DataAdapter là cầu nối trung gian giữa DataSet và nguồn dữ liệu. 1.3.3. Tổng quan về các mô hình xử lý dữ liệu trong ADO.NET 1.3.3.1. Mô hình kết nối Trong mô hình kết nối của ADO.NET, có một connection hoạt động được duy trì giữa đối tượng DataReader của ứng dụng và một data source (nguồn dữ liệu). Một dòng dữ liệu (datarow) được trả về từ data source mỗi khi phương thức Read của đối tượng DataReader được thực thi. Điểm quan trọng nhất của mô hình kết nối đó là dữ liệu được lấy từ tập dữ liệu (các record được trả về bởi một lệnh SQL nào đó) theo kiểu từng record một cho một lần đọc, chỉ đọc, và chỉ theo một hướng tiến… Hình dưới đây mô tả cách sử dụng DataReader trong chế dộ kết nối. Hình 1.6. Mô hình kết nối  Các bước điển hình để làm việc với đối tượng DataReader là như sau: 1. Tạo đối tượng Connection bằng cách truyền một chuỗi Connection string cho hàm khởi dựng của nó. 2. Khởi tạo một biến chuỗi và gán câu lệnh SQL dựa theo dữ liệu muốn nạp về. 3. Khởi tạo một đối tượng Command với nội dung câu lệnh SQL đã được xác định ở trên. -14- 4. Tạo đối tượng DataReader bằng cách thực thi phương thức Command.ExecuteReader. Đối tượng này sau đó sẽ được dùng để đọc kết quả của câu truy vấn mỗi dòng 1 lần. Một số đối tượng khi làm việc với mô hình kết nối như: lớp conection command, DataReader. 1.3.3.2. Mô hình ngắt kết nối Triết lý của mô hình ngắt kết nối đó là: Dữ liệu được nạp - sử dụng một lệnh SQL – từ nguồn dữ liệu bên ngoài vào bộ nhớ đệm tại máy client; tập kết quả được xử lý tại máy cục bộ, mọi cập nhật sau đó sẽ được truyền từ dữ liệu trong bộ nhớ ngược trở lại nguồn dữ liệu. Mô hình được gọi là “ngắt kết nối” bởi vì đối tượng kết nối chỉ được mở đủ lâu để đọc dữ liệu từ nguồn dữ liệu và tiến hành các thao tác cập nhật. Bằng cách đưa dữ liệu Connection, bộ nhớ, thời gian xử lý sẽ được giải phóng bớt. Tuy vậy, mô hình này cũng có nhược điểm về thời gian cần để nạp tập dữ liệu và bộ nhớ dùng để chứa dữ liệu tại máy client. Như hình dưới đây minh họa, các thành phần chính của mô hình ngắt kết nối đó là DataAdapter và DataSet. DataAdapter làm nhiệm vụ như là cầu nối giữa nguồn dữ liệu và DataSet, nạp dữ liệu vào các bảng của DataSet và đẩy các thay đổi ngược trở lại nguồn dữ liệu. Một DataSet đóng vai trò như là một cơ sở dữ liệu quan hệ nằm trong bộ nhớ, chứa một hay nhiều DataTable, giữa các DataTable này cũng có thể có các mối quan hệ với nhau như trong một cơ sở dữ liệu quan hệ thực. Một DataTable chứa các dòng và các cột dữ liệu thường được lấy từ cơ sở dữ liệu nguồn. Hình 1.7. Mô hình ngắt kết nối -15- Trong số các phương thức và thuộc tính của DataAdaper thì Fill() và Update() là hai phương thức quan trọng nhất. Fill() chuyển một query đến cơ sở dữ liệu và lưu tập kết quả trả về trong một DataTable nào đó; phương thức Update() thực hiện một thao tác thêm, xóa, cập nhật dựa trên những thay đổi của đối tượng DataSet. Các lệnh cập nhật thực sự được chứa trong các thuộc tính của DataAdapter. Đối tượng khi làm việc với mô hình ngắt kết nối: lớp DataSet. 1.3.4. Lựa chọn giữa mô hình Kết nối và mô hình Ngắt kết nối DataReader và DataSet đưa ra 2 cách tiếp cận khác nhau về xử lý dữ liệu. DataReader cho phép truy xuất kiểu forward-only, read-only. Bằng cách xử lý từng dòng một, cách tiếp cận này giúp tiết kiệm bộ nhớ. DataSet, ngược lại cho phép truy xuất theo kiểu read/write, nhưng lại yêu cầu phải có đủ bộ nhớ để quản lý bản sao dữ liệu nạp về data source. Như vậy, bạn có thể suy ra một số quy tắc chung: Nếu ứng dụng không cần tính năng cập nhật dữ liệu và hầu như chỉ hiển thị và chọn lọc dữ liệu, DataReader là lựa chọn thích hợp, nếu ứng dụng cần cập nhật dữ liệu, giải pháp được sử dụng DataSet nên được xem xét. Tất nhiên cũng có một số tình huống đi ngược lại với quy tắc chung nói trên. Chẳng hạn, nếu data source chứa một số lượng lớn các record, khi đó DataSet phải yêu cầu quá nhiều tài nguyên bộ nhớ, hoặc nếu dữ liệu chỉ yêu cầu một vài thao tác cập nhật, thì sự kết hợp giữa DataReader và Command để thực thi cập nhật sẽ có thể có ý nghĩa hơn. Tóm lại, một DataSet là một lựa chọn tốt khi:  Dữ liệu cần được serialize (tuần tự hóa) và/hoặc gửi đi bằng HTTP.  Các điều khiển read-only trên Form/WinForm được kết buộc (bind) với data source.  Một điều khiển WinForm như GridView hay DataView được kết buộc với một data source có khả năng cập nhật được.  Một ứng dụng Desktop cần thêm, xóa, sửa dòng dữ liệu. -16- Trong khi đó, DataReader là lựa chọn cho những trường hợp:  Cần quản lý một số lượng lớn các record, lớn đến mức mà bộ nhớ và thời gian để nạp dữ liệu cho DataSet là phi thực tế.  Dữ liệu là read-only và được kết buộc với một điều khiển loại danh sách (list control) của WinForm hoặc WebForm.  CSDL là không ổn định và thay đổi thường xuyên. 1.4. Kết luận chương 1 Chương 1 đã trình bày những kiến thức cơ bản và tổng quan nhất về KTPM cũng như việc xử lý dữ liệu với ADO.NET. Qua đó cũng cho thấy được việc xây dựng KTPM và xử lý dữ liệu là một vấn đề quan trọng trong quá trình xây dựng hệ thống phần mềm, đặc biệt là những phần mềm lớn. Trong KTPM có nhiều mô hình kiến trúc khác nhau, mỗi loại đều có những ưu và nhược điểm riêng của nó. Chương 2 sẽ giới thiệu một số mô hình kiến trúc phổ biến đang được sử dụng trong việc xây dựng các ứng dụng thông dụng hiện nay. -17- Chương 2: MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM 2.1. Mô hình MVC 2.1.1. Kiến trúc mô hình MVC Trong kiến trúc MVC, một đối tượng đồ họa người dùng (GUI Component) bao gồm 3 thành phần cơ bản: Model, View, và Controller. Model có trách nhiệm đối với toàn bộ dữ liệu cũng như trạng thái của đối tượng đồ họa. View chính là thể hiện trực quan của Model, hay nói cách khác chính là giao diện của đối tượng đồ họa. Và Controller điều khiển việc tương tác giữa đối tượng đồ họa với người sử dụng cũng như những đối tượng khác. Hình 2.1. Mô hình MVC trong ASP.NET 2.1.2. Đặc điểm mô hình MVC Lợi ích quan trọng nhất của mô hình MVC là nó giúp cho ứng dụng dễ bảo trì, module hóa các chức năng, và được xây dựng nhanh chóng. MVC tách các tác vụ của ứng dụng thành các phần riêng lẽ model, view, controller giúp cho việc xây dựng ứng dụng nhẹ nhàng hơn. Dễ dàng thêm các tính năng mới, và các tính năng cũ có thể dễ dàng thay đổi. MVC cho phép các nhà phát triển và các nhà thiết kế có thể làm việc đồng thời với nhau. MVC cho phép thay đổi trong 1 phần của ứng dụng mà không ảnh hưởng đến các phần khác. -18- 2.1.3. Các thành phần của ASP.NET MVC ASP.NET MVC cũng chia nhỏ một ứng dụng thành ba thành phần để cài đặt, mỗi thành phần đóng một vai trò khác nhau và ảnh hưởng lẫn nhau, đó là model, view, và controller. Hình 2.2. Các thành phần của MVC + Models: có nhiệm vụ lưu trữ thông tin, trạng thái của các đối tượng, thông thường nó là một lớp được ánh xạ từ một bảng trong CSDL. Ví dụ: Chúng ta có lớp Giáo trình được sử dụng để mô tả dữ liệu từ bảng Giáo trình trong SQL, bao gồm Mã giáo trình, Tên giáo trình... + Views: chịu trách nhiệm hiển thị các thông tin lên cho người dùng thông qua giao diện. Thông thường, các thông tin cần hiển thị được lấy từ thành phần Models. + Controllers: chịu trách nhiệm xử lý các tác động về mặt giao diện, các thao tác đối với models, và cuối cùng là chọn một view thích hợp để hiển thị ra màn hình. Trong kiến trúc MVC, View chỉ có tác dụng hiển thị giao diện mà thôi, còn điều khiển dòng nhập xuất của người dùng vẫn do Controllers đảm trách. -19- 2.1.4. Lợi ích của mô hình MVC  Có tính mở rộng do có thể thay thế từng thành phần 1 cách dễ dàng.  Không sử dụng Viewstate, điều này làm các nhà phát triển dễ dàng điều khiển ứng dụng của mình.  Hệ thống định tuyến mới mạnh mẽ.  Hỗ trợ tốt hơn cho test-driven development (TDD – mô hình phát triển kiểm thử) cài đặt các kiểm thử đơn vị (unit tests) tự động, xác định và kiểm tra lại các yêu cầu trước khi bắt tay vào viết code.  Hỗ trợ kết hợp rất tốt giữa người lập trình và người thiết kế giao diện.  Sử dụng các tính năng tốt nhất đã có của ASP.NET. 2.2. Mô hình MVVM Mô hình MVVM (Model - View - View Model) là một mô hình kiến trúc dùng trong công nghệ phần mềm được phát triển từ Microsoft và chủ yếu dựa trên mô hình MVC. Xuất phát từ như cầu thực tế, đó là sự thay đổi trong việc xử lý sự kiện và dữ liệu, giữa các tầng của ứng dụng với nhau, qua đó, hầu hết các công việc của tầng kết hợp với lớp presentation. Điều này làm nảy sinh ra nhu cầu phải có một mô hình phát triển ứng dụng mới phù hợp hơn. Và do đó, mô hình Model – View – ViewModel (MVVM) ra đời và ngày càng trở nên phổ biến hơn. Mô hình MVVM giúp phát triển ứng dụng linh hoạt bằng cách tách biệt ra 3 phần là Model, View và View Model như hình vẽ dưới đây: Hình 2.3. Các thành phần của mô hình MVVM -20- Trong đó:  View: tương tự như trong mô hình MVC, View là phần giao diện của ứng dụng để hiển thị dữ liệu và nhận tương tác của người dùng. Nó có nhiệm vụ hiển thị thông tin từ View Model, người dùng có thể tương tác với View để truyền mệnh lệnh xuống cho View Model và có thể được cập nhật thông tin khi trạng thái thông tin trong View Model thay đổi. Một điểm khác biệt so với các ứng dụng truyền thống là View trong mô hình này tích cực hơn. Nó có khả năng thực hiện các hành vi và phản hồi lại người dùng thông qua tính năng binding, command.  ViewModel: là phần xử lý logic, lấy dữ liệu từ cơ sở dữ liệu trong phần Model hiển thị lên View và cập nhập dữ liệu từ View xuống cơ sở dữ liệu trong Model, hoặc có thể chỉ xử lý nghiệp vụ thông thường mà không cần lấy dữ liệu dưới cơ sở dữ liệu. ViewModel có thể được xem là thành phần thay thế cho Controller trong mô hình MVC. Nó chứa các mã lệnh cần thiết để thực hiện data binding, command. Lưu ý rằng nó không phải là phần dữ liệu trong Model và cũng không phải là UI trong View, mà nó quản lý phần dữ liệu mà người dùng đang tương tác.  Model: là phần chứa dữ liệu của ứng dụng và nó được tách riêng với phần giao diện người dùng (UI). Cũng tương tự như trong mô hình MVC. Model là các đối tượng giúp truy xuất và thao tác trên dữ liệu thực sự. 2.3. Mô hình đa tầng (n-Tier) Trong kỹ thuật phần mềm, kiến trúc đa tầng (thường được gọi là kiến trúc n-tier) là một kiến trúc client-server trong đó trình bày, xử lý ứng dụng, và quản lý dữ liệu chức năng được tách biệt. Việc sử dụng rộng rãi nhất của kiến trúc đa tầng là kiến trúc 3 tầng (3-Tier). Kiến trúc n-tier ứng dụng cung cấp một mô hình mà các nhà phát triển có thể tạo ra các ứng dụng linh hoạt và sử dụng lại. Bằng cách tách một ứng dụng -21- thành các tầng, các nhà phát triển có được các tùy chọn để sửa đổi hoặc bổ sung thêm một tầng cụ thể, thay vì làm lại toàn bộ ứng dụng. 2.3.1. Khái niệm Mô hình 3 tầng (3–Tiers) là một kiến trúc kiểu Client – Server mà trong đó giao diện người dùng (UI-user interface), các quy tắc xử lý (BR-business rule hay BL-business logic), và việc lưu trữ dữ liệu được phát triển như những module độc lập, và hầu hết là được duy trì trên các nền tảng độc lập, và mô hình 3 tầng (3-tier) được coi là một KTPM và là một mẫu thiết kế. 2.3.2. Các thành phần của mô hình 3 tầng 3-Tiers có tính vật lý (physical): là mô hình client-server (mỗi tier có thể đặt chung 1 nơi hoặc nhiều nơi, kết nối với nhau qua Web services, WCF, Remoting…). Như vậy, ta có thể mô hình này phân tách ứng dụng ra làm 3 module riêng biệt. Kiến trúc 3-tier gồm 3 tầng chính:  Presentation Tier: bao gồm các thành phần xử lý giao diện Graphic User Interface (GUI). Được dùng để giao tiếp với người dùng, nhiệm vụ chính là hiển thị dữ liệu và nhận dữ liệu từ người dùng.  Business Logic Tier: gồm các thành phần Business Logic Layer (BLL), Data Access Layer (DAL) và Data Tranfer Object (DTO). Được dùng để cung cấp các chức năng của phần mềm.  Data Tier: Tầng giao tiếp với các hệ quản trị CSDL. -22- Hình 2.4. Các tầng trong mô hình 3-tier và nhiệm vụ của nó 2.3.3. Tính chất của 3-Tier - Giảm sự gắn kết giữa các thực thể phần mềm: xây dựng phần mềm theo mô hình 3-Tier làm giảm sự gắn kết giữa các thành phần trong hệ thống do mỗi tầng có trách nhiệm độc lập tương đối. -23- Hình 2.5. Mô hình 3-Tier giảm sự gắn kết giữa các thực thể - Tái sử dụng: chính vì giảm sự gắn kết giữa các tầng nên xây dựng phần mềm theo mô hình 3-Tier giúp cho việc bổ sung, chỉnh sửa, cập nhật hệ thống một cách dễ dàng, đơn giản hơn. Hình 2.6. Mô hình 3-Tier giúp dễ dàng tái sử dụng phần mềm - Chia sẻ trách nhiệm: vì mỗi tầng có thể đặt ở nhiều nơi khác nhau và vai trò của mỗi tầng là khác nhau và tương đối độc lập nên việc phát triển phần mềm theo mô hình này giúp chia sẻ trách nhiệm ở mỗi tầng cũng như trách nhiệm đối với đội ngũ phát triển hệ thống. Hình 2.7. Mô hình 3-Tier giúp dễ dàng chia sẻ trách nhiệm -24- 2.3.4. Ưu, nhược điểm của 3-tier 3-tier là một KTPM, có nghĩa là bạn có thể dùng nó để xây dựng nên bộ khung tổng thể của ứng dụng. Tuy nhiên bạn cần chú ý những ưu và nhược điểm sau đây để áp dụng nó một cách đúng đắn. * Ưu điểm: + Dễ dàng mở rộng, thay đổi quy mô hệ thống: Khi cần tải lớn, người quản trị có thể dễ dàng thêm các máy chủ vào nhóm, hoặc lấy bớt ra trong trường hợp ngược lại. * Nhược điểm: + Việc truyền dữ liệu giữa các tầng sẽ chậm hơn vì phải truyền giữa các tiến trình khác nhau (IPC), dữ liệu cần phải được đóng gói -> truyền đi -> mở gói trước khi có thể dùng được. + Việc phát triển ứng dụng phức tạp hơn. 2.4. Mô hình 3-Layer 2.4.1. Khái niệm 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 nhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫn nhau. Ví dụ trong một công ty có từng phòng ban, mỗi phòng ban sẽ chịu trách nhiệm một công việc cụ thể nào đó, phòng này không được can thiệp vào công việc nội bộ của phòng kia như Phòng tài chính thì chỉ phát lương, còn chuyện lấy tiền đâu phát cho các anh phòng Marketing thì các anh không cần biết. Trong phát triển phần mềm, người ta cũng áp dụng cách phân chia chức năng này, đó là mô hình 3-Layer (3 lớp), mỗi lớp sẽ thực hiện một chức năng nào đó. Không như mô hình 3-Tiers có tính vật lý, mô hình 3-Layers có tính logic (mỗi layer có 1 công việc) và là 1 thành phần của 3-Tiers. -25- 2.4.2. Các thành phần của 3-Layer Mô hình 3-Layer được cấu thành từ 3 Layer: Presentation Layer hay còn gọi là Graphic User Interface (GUI), Business Logic Layer (BLL) và Data Access Layer (DAL). Các lớp này sẽ giao tiếp với nhau thông qua các dịch vụ (services) 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 kia cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi. Mô hình 3 lớp mà Microsoft đề nghị dùng cho các hệ thống phát triển trên nền .NET như sau: Hình 2.8. Các thành phần của mô hình 3-Layer Trong đó:  GUI: Thành phần gia

NỘI DUNG NGHIÊN CỨU

1.1 Khái niệm kiến trúc phần mềm

Nhiều nhà nghiên cứu đã giải thích về kiến trúc phần mềm, và họ có các quan điểm khác nhau về cách trình bày tốt nhất về kiến trúc của hệ thống phần mềm Không có cách giải thích nào là sai; mỗi kiến trúc có giá trị riêng Định nghĩa của Bass L, và cộng sự nắm giữ được điểm cốt yếu của cái mà kiến trúc phần mềm đòi hỏi: “Kiến trúc phần mềm của một chương trình hoặc hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống đó, gồm các thành phần của phần mềm, các thuộc tính có thể trông thấy được từ bên ngoài của các thành phần này, và các mối quan hệ giữa chúng” Định nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô (coarse- grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the architecture) Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ phận kiến trúc cơ bản còn lại Các chi tiết bên trong của sự thiết kế và cài đặt thành phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần mềm đặc biệt chỉ như một hộp đen Hộp đen này có các thuộc tính nhất định mà nó biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung các đích nghiệp vụ hoặc công nghệ thông tin Kiến trúc phần mềm xác định các khối kiến trúc cơ bản, với một mức độ chi tiết thích hợp

Nó cũng xác định và viết tư liệu việc các bộ phận cơ bản liên quan lẫn nhau như thế nào

Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây

TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM

Khái niệm kiến trúc phần mềm

Nhiều nhà nghiên cứu đã giải thích về kiến trúc phần mềm, và họ có các quan điểm khác nhau về cách trình bày tốt nhất về kiến trúc của hệ thống phần mềm Không có cách giải thích nào là sai; mỗi kiến trúc có giá trị riêng Định nghĩa của Bass L, và cộng sự nắm giữ được điểm cốt yếu của cái mà kiến trúc phần mềm đòi hỏi: “Kiến trúc phần mềm của một chương trình hoặc hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống đó, gồm các thành phần của phần mềm, các thuộc tính có thể trông thấy được từ bên ngoài của các thành phần này, và các mối quan hệ giữa chúng” Định nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô (coarse- grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the architecture) Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ phận kiến trúc cơ bản còn lại Các chi tiết bên trong của sự thiết kế và cài đặt thành phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần mềm đặc biệt chỉ như một hộp đen Hộp đen này có các thuộc tính nhất định mà nó biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung các đích nghiệp vụ hoặc công nghệ thông tin Kiến trúc phần mềm xác định các khối kiến trúc cơ bản, với một mức độ chi tiết thích hợp

Nó cũng xác định và viết tư liệu việc các bộ phận cơ bản liên quan lẫn nhau như thế nào

Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây

-5- dựng theo kiểu lặp lại, gia tăng, và độc lập Các bộ phận riêng lẻ có các mối quan hệ hiện với nhau Khi đan xen vào nhau, các bộ phận riêng lẻ đó tạo nên kiến trúc của hệ thống, tổ chức, hoặc ứng dụng

Ngoài ra, thuật ngữ “kiến trúc phần mềm” cũng đề cập đến các tài liệu kiến trúc phần mềm của một hệ thống, thuận tiện cho việc trao đổi thông tin giữa các thành viên trong một dự án KTPM giúp việc quyết định ở mức cao trong thiết kế phần mềm dễ dàng hơn và cho phép tái sử dụng các thành phần và mẫu thiết kế của các dự án

Lĩnh vực khoa học máy tính trải qua sự kết hợp các vấn đề cùng với sự phức tạp của cấu trúc Lúc đầu, sự phức tạp được giải quyết bởi người phát triển bằng cách lựa chọn các cấu trúc dữ liệu đúng đắn, phát triển các thuật toán và áp dụng các thuật toán để chia nhỏ các vấn đề Khái niệm “Kiến trúc phần mềm” tập trung vào việc giảm tải các phức tạp bằng cách trừu tượng hóa vấn đề và phân chia rõ trách nhiệm công việc Tuy vậy, đến ngày nay vẫn chưa có một khái niệm thật chính xác và rõ ràng cho thuật ngữ “Kiến trúc phần mềm”

Như vậy mặc dù khái niệm “Kiến trúc phần mềm” đã xuất hiện trong các giảng đường đại học và được đưa vào sử dụng trong ngành công nghệ phần mềm, nhưng việc nó vẫn chưa có các quy tắc, luật lệ chung và chưa rõ ràng nên thiết kế KTPM vẫn là một sự pha tạp giữa “khoa học” và “nghệ thuật” Vẻ “nghệ thuật” của kiến trúc phần mềm được lý giải là do có sự xuất hiện của các yêu cầu phi chức năng của hệ thống mà phần mềm phải đáp ứng được các yêu cầu này, chẳng hạn như các yêu cầu về các thuộc tính chất lượng Ngoài ra, phần mềm còn phải thỏa mãn các yêu cầu khác như: khả năng chịu lỗi, tính tương thích với các phiên bản cũ của các phần mềm khác (backward compatibility), khả năng mở rộng, tính tin cậy, khả năng bảo trì, tính hiện hữu, tính bảo mật, tính dễ dùng, và một số các yêu cầu khác nữa

Nguồn gốc của kiến trúc phần mềm như một ý tưởng được giới thiệu đầu tiên trong nghiên cứu của Edsger Dijkstra năm 1968 và David Parnas đầu những

-6- năm 1970 Các nhà khoa học nhấn mạnh rằng cấu trúc của một hệ thống phần mềm rất quan trọng và đạt được cấu trúc đúng đắn là một yếu tố quyết định Các nghiên cứu về lĩnh vực này ngày càng nhiều và trở nên phổ biến từ đầu những năm 1990 cùng với các nghiên cứu tập trung vào các mẫu thiết kế (pattern), ngôn ngữ đặc tả kiến trúc (Architecture Description Languages), tài liệu kiến trúc và các phương pháp chính thức Các viện nghiên cứu đóng vai trò quan trọng trong nghiên cứu môn học KTPM Mary Shaw và David Garlan của viện nghiên cứu Carnegie Mellon đã viết cuốn sách “Software Architecture: Perspectives on an Emerging Discipline” vào năm 1996, mang đến các khái niệm tiến bộ trong KTPM như thành phần, kết nối (connector), kiểu (style) và nhiều thứ nữa Trường đại học tổng hợp California, viện nghiên cứu phần mềm Irvine cũng có nhiều nỗ lực trong nghiên cứu KTPM, chủ yếu hướng vào các kiểu kiến trúc, ngôn ngữ đặc tả kiến trúc và các kiến trúc động Một trong những chuẩn đầu tiên trong KTPM là chuẩn ANSI/IEEE 1471-2000 được ISO chấp nhận như ISO/IEC DIS 25961

1.1.3 T ầ m quan tr ọ ng c ủ a ki ế n trúc ph ầ n m ề m

Có 3 lý do chính để giải thích tầm quan trọng của KTPM:

Hỗ trợ việc giao tiếp với các thành viên trong dự án KTPM tái hiện một vẻ bề ngoài trừu tượng của hệ thống Với sự trừu tượng hóa hệ thống với các khái niệm dễ hiểu, những thành viên trong dự án sẽ chỉ cần vận dụng các kiến thức cơ bản của mình về hệ thống trong việc tìm hiểu, dàn xếp, phối hợp làm việc, và bàn bạc trao đổi với nhau

 Giúp ra quyết định sớm hơn

Việc ra quyết định được thực hiện sớm hơn KTPM biểu thị các quyết định thiết kế dành cho hệ thống Như vậy các đội tham gia phát triển, triển khai, kiểm thử và bảo trì phần mềm cũng như các nhóm người dùng và các cấp quản lý sẽ có cái nhìn tổng quan hơn cũng như sớm hơn về hệ thống ngay từ khi nó còn sơ khai Mỗi đội đó sẽ có các đóng góp ý kiến của mình, các đề xuất cũng như các

-7- phản bác của mình khi mọi chuyện chưa quá muộn Nếu không có quyết định sớm, thì khi phần mềm đã được xây dựng hoàn chỉnh hoặc khá hoàn chỉnh mà đột ngột xuất hiện các yêu cầu thay đổi từ phía nhóm này hoặc nhóm khác, ngoài việc gây trì trệ cho tiến độ công việc mà còn có thể gây ra tâm lý căng thẳng, mâu thuẫn giữa các đội tham gia trong dự án

 Tính khả chuyển cho hệ thống

KTPM không phụ thuộc vào một ngôn ngữ cụ thể nào cả mà chỉ tuân theo một số chuẩn của các ngôn ngữ đặc tả nó Ngoài ra, KTPM khi được xây dựng cho một hệ thống, nó tạo thành một mô hình có sự gắn kết tương đối với hệ thống KTPM còn chỉ ra cách thức mà phần mềm làm việc với hệ thống Do vậy, khi ta muốn chuyển phần mềm sang làm việc ở các hệ thống khác có những điểm tương đồng nhất định với hệ thống cũ thì phần mềm này cũng sẽ có các thuộc tính chất lượng và các yêu cầu chức năng được đảm bảo là không quá khác so với khi tồn tại ở hệ thống cũ.

Phân loại mô hình kiến trúc

Là một thể thống nhất, không có sự phân nhóm và các thành phần trong mô hình đơn lập thì tự do tương tác

+ Dễ lập trình và triển khai

+ Tốc độ xử lý cao

+ Khó bảo trì, nâng cấp

+ Không chia sẻ dữ liệu

- Chia sẻ tài nguyên: chia sẻ tài nguyên phần cứng và phần mềm

- Tính mở: Cho phép sử dụng phần mềm và thiết bị của các nhà cung cấp khác nhau

- Xử lý đồng thời: Nâng cao hiệu năng của hệ thống

- Tính mềm dẻo: Cho phép thêm mới tài nguyên một cách dễ dàng

- Khả năng chịu lỗi: Cho phép hệ thống tiếp tục vận hành khi lỗi phát sinh

- Tính phức tạp: hệ thống phân tán phức tạp hơn hệ thống tập trung

- Tính an toàn: Dễ bị tấn công từ bên ngoài

- Tính quản lý được: Cần nhiều công sức hơn để quản lý hệ thống

- Không thể dự đoán trước: Khả năng đáp ứng không được dự đoán trước do phụ thuộc vào phương thức tổ chức hệ thống và khả năng chịu tải của hệ thống mạng

1.2.2.3 Một số mô hình phân tán

- Là mô hình tổ chức trong đó các dịch vụ được cung cấp bởi server (chương trình chủ) và client (chương trình khách) sử dụng các dịch vụ đó (máy tính trên đó cài đặt chương trình chủ gọi là máy chủ)

- Client gửi yêu cầu (request) tới server, server tiếp nhận, xử lý vả trả về kết quả cho client

- Client biết server nhưng server không cần biết client

- Để client-server giao tiếp được với nhau cần tuân theo chuẩn, gọi là giao thức

- Một server có thể nối tới nhiều server khác để tăng hiệu quả xử lý

- Client và server là các tiến trình logic

Hình 1.1 Mô hình Client – Server

+ Dữ liệu chia sẻ và đồng bộ

+ Dễ bảo trì, nâng cấp, cô lập lỗi

 Mô hình 3 – Tiers: Được phân thành 3 tầng:

* T ầ ng giao di ệ n (Presentation tier): Các thực thể phần mềm làm nhiệm vụ nhập liệu, trình bày, hiển thị, có thể bao gồm bước kiểm tra dữ liệu trước khi gọi Business Logic Tier và tương tác với người sử dụng

* T ầ ng x ử lý (Business tier): Các thực thể phần mềm thực hiện các chức năng nghiệp vụ, chứa các xử lý chính và quản lý các transaction

* T ầ ng d ữ li ệ u (Data tier): các thực thể phần mềm làm nhiệm vụ lưu trữ dữ liệu, tương tác với cơ sở dữ liệu (thêm, xóa, sửa, chọn)

+ Tương tự mô hình Client–Server

+ Xử lý chia sẻ và được chia nhỏ

+ Tương tự mô hình Client-Server

Trong Chương 2 của Khóa luận sẽ trình bày cụ thể hơn về mô hình này

 Mô hình Peer - To - Peer (mô hình ngang hàng):

- Là mô hình không tập trung, trong đó việc tính toán có thể được thực hiện ở bất cứ nút nào trên mạng

- Triển khai trên nhiều máy (node)

- Các node tương tác được với nhau

- Mỗi node đóng vai trò Client – Server

- Chia sẻ dữ liệu và xử lý trên toàn bộ node

- Ngoài mô hình Peer-To-Peer có kiến trúc không tập trung truyền thống còn có mô hình kiến trúc bán tập trung

Hình 1.3 Mô hình Peer-To-Peer với kiến trúc không tập trung

Hình 1.4 Mô hình Peer-To-Peer với kiến trúc bán tập trung

+ Không cần Server trung tâm

+ Không gian lưu trữ và khả năng xử lý dàn trải

+ Khó lập trình và quản lý dữ liệu.

Xử lý dữ liệu với ADO.NET

Xử lý dữ liệu là nhiệm vụ phổ biến và quan trọng của nhiều chương trình ứng dụng Dữ liệu được truy xuất, xử lý của một chương trình ứng dụng có thể là một tập tin văn bản, tập tin các bản ghi, hay là một nguồn dữ liệu từ CSDL nào đó

ADO.NET là một tập các lớp nằm trong bộ thư viện lớp cơ sở của NET Framework, cho phép các ứng dụng windows (như C#, VB.NET) hay ứng dụng Web (như ASP.NET) thao tác dễ dàng với các nguồn dữ liệu

Cung cấp các lớp thao tác với CSDL giúp lập trình viên lập trình nhanh hơn và giảm bớt lỗi

Cung cấp các công cụ để thao tác với CSDL ngay trên phần Designer giúp lập trình viên tương tác với CSDL mà không cần hiểu sâu về CSDL

Sử dụng kiến trúc không kết nối chỉ kết nối với dữ liệu khi cần thiết nên giảm tải cho server CSDL -> Ứng dụng có thể đáp ứng nhiều người dùng hơn

ADO.NET có thể gửi dữ liệu cho bất cứ ứng dụng nào hỗ trợ XML

1.3.2 Ki ế n trúc t ổ ng quan c ủ a ADO.NET

ADO.NET được chia ra làm hai phần chính rõ rệt, được thể hiện qua hình 1.5:

Hình 1.5 Kiến trúc tổng quan của ADO.NET

DataSet là thành phần chính cho đặc trưng kết nối không liên tục của kiến trúc ADO.NET DataSet được thiết kế để có thể thích ứng với bất kỳ nguồn dữ liệu nào DataSet chứa một hay nhiều đối tượng DataTable mà nó được tạo từ tập các dòng và cột dữ liệu, cùng với khoá chính, khóa ngoại, ràng buộc và các thông tin liên quan đến đối tượng DataTable này Bản thân DataSet được dạng như một tập tin XML

Thành phần chính thứ hai của ADO.NET chính là NET Provider Data, nó chứa các đối tượng phục vụ cho việc thao tác trên cơ sở dữ liệu được hiệu quả và nhanh chóng, nó bao gồm một tập các đối tượng Connection, Command,

DataReader và DataAdapter Đối tượng Connection cung cấp một kết nối đến cơ sở dữ liệu, Command cung cấp một thao tác đến cơ sở dữ liệu, DataReader cho phép chỉ đọc dữ liệu và DataAdapter là cầu nối trung gian giữa DataSet và nguồn dữ liệu

1.3.3 T ổ ng quan v ề các mô hình x ử lý d ữ li ệ u trong ADO.NET

Trong mô hình kết nối của ADO.NET, có một connection hoạt động được duy trì giữa đối tượng DataReader của ứng dụng và một data source (nguồn dữ liệu) Một dòng dữ liệu (datarow) được trả về từ data source mỗi khi phương thức Read của đối tượng DataReader được thực thi Điểm quan trọng nhất của mô hình kết nối đó là dữ liệu được lấy từ tập dữ liệu (các record được trả về bởi một lệnh SQL nào đó) theo kiểu từng record một cho một lần đọc, chỉ đọc, và chỉ theo một hướng tiến…

Hình dưới đây mô tả cách sử dụng DataReader trong chế dộ kết nối

Hình 1.6 Mô hình kết nối

 Các bước điển hình để làm việc với đối tượng DataReader là như sau:

1 Tạo đối tượng Connection bằng cách truyền một chuỗi Connection string cho hàm khởi dựng của nó

2 Khởi tạo một biến chuỗi và gán câu lệnh SQL dựa theo dữ liệu muốn nạp về

3 Khởi tạo một đối tượng Command với nội dung câu lệnh SQL đã được xác định ở trên

4 Tạo đối tượng DataReader bằng cách thực thi phương thức Command.ExecuteReader Đối tượng này sau đó sẽ được dùng để đọc kết quả của câu truy vấn mỗi dòng 1 lần

Một số đối tượng khi làm việc với mô hình kết nối như: lớp conection command, DataReader

1.3.3.2 Mô hình ngắt kết nối

Triết lý của mô hình ngắt kết nối đó là: Dữ liệu được nạp - sử dụng một lệnh SQL – từ nguồn dữ liệu bên ngoài vào bộ nhớ đệm tại máy client; tập kết quả được xử lý tại máy cục bộ, mọi cập nhật sau đó sẽ được truyền từ dữ liệu trong bộ nhớ ngược trở lại nguồn dữ liệu

Mô hình được gọi là “ngắt kết nối” bởi vì đối tượng kết nối chỉ được mở đủ lâu để đọc dữ liệu từ nguồn dữ liệu và tiến hành các thao tác cập nhật Bằng cách đưa dữ liệu Connection, bộ nhớ, thời gian xử lý sẽ được giải phóng bớt Tuy vậy, mô hình này cũng có nhược điểm về thời gian cần để nạp tập dữ liệu và bộ nhớ dùng để chứa dữ liệu tại máy client

Như hình dưới đây minh họa, các thành phần chính của mô hình ngắt kết nối đó là DataAdapter và DataSet DataAdapter làm nhiệm vụ như là cầu nối giữa nguồn dữ liệu và DataSet, nạp dữ liệu vào các bảng của DataSet và đẩy các thay đổi ngược trở lại nguồn dữ liệu Một DataSet đóng vai trò như là một cơ sở dữ liệu quan hệ nằm trong bộ nhớ, chứa một hay nhiều DataTable, giữa các DataTable này cũng có thể có các mối quan hệ với nhau như trong một cơ sở dữ liệu quan hệ thực Một DataTable chứa các dòng và các cột dữ liệu thường được lấy từ cơ sở dữ liệu nguồn

Hình 1.7 Mô hình ngắt kết nối

Trong số các phương thức và thuộc tính của DataAdaper thì Fill() và Update() là hai phương thức quan trọng nhất Fill() chuyển một query đến cơ sở dữ liệu và lưu tập kết quả trả về trong một DataTable nào đó; phương thức Update() thực hiện một thao tác thêm, xóa, cập nhật dựa trên những thay đổi của đối tượng DataSet Các lệnh cập nhật thực sự được chứa trong các thuộc tính của DataAdapter Đối tượng khi làm việc với mô hình ngắt kết nối: lớp DataSet

1.3.4 L ự a ch ọ n gi ữ a mô hình K ế t n ố i và mô hình Ng ắ t k ế t n ố i

DataReader và DataSet đưa ra 2 cách tiếp cận khác nhau về xử lý dữ liệu DataReader cho phép truy xuất kiểu forward-only, read-only Bằng cách xử lý từng dòng một, cách tiếp cận này giúp tiết kiệm bộ nhớ DataSet, ngược lại cho phép truy xuất theo kiểu read/write, nhưng lại yêu cầu phải có đủ bộ nhớ để quản lý bản sao dữ liệu nạp về data source Như vậy, bạn có thể suy ra một số quy tắc chung: Nếu ứng dụng không cần tính năng cập nhật dữ liệu và hầu như chỉ hiển thị và chọn lọc dữ liệu, DataReader là lựa chọn thích hợp, nếu ứng dụng cần cập nhật dữ liệu, giải pháp được sử dụng DataSet nên được xem xét

Tất nhiên cũng có một số tình huống đi ngược lại với quy tắc chung nói trên Chẳng hạn, nếu data source chứa một số lượng lớn các record, khi đó DataSet phải yêu cầu quá nhiều tài nguyên bộ nhớ, hoặc nếu dữ liệu chỉ yêu cầu một vài thao tác cập nhật, thì sự kết hợp giữa DataReader và Command để thực thi cập nhật sẽ có thể có ý nghĩa hơn

Tóm l ạ i, m ộ t DataSet là m ộ t l ự a ch ọ n t ố t khi:

 Dữ liệu cần được serialize (tuần tự hóa) và/hoặc gửi đi bằng HTTP

 Các điều khiển read-only trên Form/WinForm được kết buộc (bind) với data source

 Một điều khiển WinForm như GridView hay DataView được kết buộc với một data source có khả năng cập nhật được

 Một ứng dụng Desktop cần thêm, xóa, sửa dòng dữ liệu

Trong khi đ ó, DataReader là l ự a ch ọ n cho nh ữ ng tr ườ ng h ợ p:

 Cần quản lý một số lượng lớn các record, lớn đến mức mà bộ nhớ và thời gian để nạp dữ liệu cho DataSet là phi thực tế

 Dữ liệu là read-only và được kết buộc với một điều khiển loại danh sách (list control) của WinForm hoặc WebForm

 CSDL là không ổn định và thay đổi thường xuyên.

Kết luận chương 1

Chương 1 đã trình bày những kiến thức cơ bản và tổng quan nhất về KTPM cũng như việc xử lý dữ liệu với ADO.NET Qua đó cũng cho thấy được việc xây dựng KTPM và xử lý dữ liệu là một vấn đề quan trọng trong quá trình xây dựng hệ thống phần mềm, đặc biệt là những phần mềm lớn

Trong KTPM có nhiều mô hình kiến trúc khác nhau, mỗi loại đều có những ưu và nhược điểm riêng của nó Chương 2 sẽ giới thiệu một số mô hình kiến trúc phổ biến đang được sử dụng trong việc xây dựng các ứng dụng thông dụng hiện nay

MỘT SỐ MÔ HÌNH KIẾN TRÚC PHẦN MỀM

Mô hình MVC

2.1.1 Ki ế n trúc mô hình MVC

Trong kiến trúc MVC, một đối tượng đồ họa người dùng (GUI Component) bao gồm 3 thành phần cơ bản: Model, View, và Controller Model có trách nhiệm đối với toàn bộ dữ liệu cũng như trạng thái của đối tượng đồ họa View chính là thể hiện trực quan của Model, hay nói cách khác chính là giao diện của đối tượng đồ họa Và Controller điều khiển việc tương tác giữa đối tượng đồ họa với người sử dụng cũng như những đối tượng khác

Hình 2.1 Mô hình MVC trong ASP.NET 2.1.2 Đặ c đ i ể m mô hình MVC

Lợi ích quan trọng nhất của mô hình MVC là nó giúp cho ứng dụng dễ bảo trì, module hóa các chức năng, và được xây dựng nhanh chóng MVC tách các tác vụ của ứng dụng thành các phần riêng lẽ model, view, controller giúp cho việc xây dựng ứng dụng nhẹ nhàng hơn Dễ dàng thêm các tính năng mới, và các tính năng cũ có thể dễ dàng thay đổi MVC cho phép các nhà phát triển và các nhà thiết kế có thể làm việc đồng thời với nhau MVC cho phép thay đổi trong 1 phần của ứng dụng mà không ảnh hưởng đến các phần khác

2.1.3 Các thành ph ầ n c ủ a ASP.NET MVC

ASP.NET MVC cũng chia nhỏ một ứng dụng thành ba thành phần để cài đặt, mỗi thành phần đóng một vai trò khác nhau và ảnh hưởng lẫn nhau, đó là model, view, và controller

Hình 2.2 Các thành phần của MVC

+ Models: có nhiệm vụ lưu trữ thông tin, trạng thái của các đối tượng, thông thường nó là một lớp được ánh xạ từ một bảng trong CSDL

Ví dụ: Chúng ta có lớp Giáo trình được sử dụng để mô tả dữ liệu từ bảng Giáo trình trong SQL, bao gồm Mã giáo trình, Tên giáo trình

+ Views: chịu trách nhiệm hiển thị các thông tin lên cho người dùng thông qua giao diện Thông thường, các thông tin cần hiển thị được lấy từ thành phần Models

+ Controllers: chịu trách nhiệm xử lý các tác động về mặt giao diện, các thao tác đối với models, và cuối cùng là chọn một view thích hợp để hiển thị ra màn hình Trong kiến trúc MVC, View chỉ có tác dụng hiển thị giao diện mà thôi, còn điều khiển dòng nhập xuất của người dùng vẫn do Controllers đảm trách

 Có tính mở rộng do có thể thay thế từng thành phần 1 cách dễ dàng

 Không sử dụng Viewstate, điều này làm các nhà phát triển dễ dàng điều khiển ứng dụng của mình

 Hệ thống định tuyến mới mạnh mẽ

 Hỗ trợ tốt hơn cho test-driven development (TDD – mô hình phát triển kiểm thử) cài đặt các kiểm thử đơn vị (unit tests) tự động, xác định và kiểm tra lại các yêu cầu trước khi bắt tay vào viết code

 Hỗ trợ kết hợp rất tốt giữa người lập trình và người thiết kế giao diện

 Sử dụng các tính năng tốt nhất đã có của ASP.NET.

Mô hình MVVM

Mô hình MVVM (Model - View - View Model) là một mô hình kiến trúc dùng trong công nghệ phần mềm được phát triển từ Microsoft và chủ yếu dựa trên mô hình MVC Xuất phát từ như cầu thực tế, đó là sự thay đổi trong việc xử lý sự kiện và dữ liệu, giữa các tầng của ứng dụng với nhau, qua đó, hầu hết các công việc của tầng kết hợp với lớp presentation Điều này làm nảy sinh ra nhu cầu phải có một mô hình phát triển ứng dụng mới phù hợp hơn Và do đó, mô hình Model – View – ViewModel (MVVM) ra đời và ngày càng trở nên phổ biến hơn

Mô hình MVVM giúp phát triển ứng dụng linh hoạt bằng cách tách biệt ra 3 phần là Model, View và View Model như hình vẽ dưới đây:

Hình 2.3 Các thành phần của mô hình MVVM

 View: tương tự như trong mô hình MVC, View là phần giao diện của ứng dụng để hiển thị dữ liệu và nhận tương tác của người dùng Nó có nhiệm vụ hiển thị thông tin từ View Model, người dùng có thể tương tác với View để truyền mệnh lệnh xuống cho View Model và có thể được cập nhật thông tin khi trạng thái thông tin trong View Model thay đổi Một điểm khác biệt so với các ứng dụng truyền thống là View trong mô hình này tích cực hơn Nó có khả năng thực hiện các hành vi và phản hồi lại người dùng thông qua tính năng binding, command

 ViewModel: là phần xử lý logic, lấy dữ liệu từ cơ sở dữ liệu trong phần

Model hiển thị lên View và cập nhập dữ liệu từ View xuống cơ sở dữ liệu trong Model, hoặc có thể chỉ xử lý nghiệp vụ thông thường mà không cần lấy dữ liệu dưới cơ sở dữ liệu ViewModel có thể được xem là thành phần thay thế cho Controller trong mô hình MVC Nó chứa các mã lệnh cần thiết để thực hiện data binding, command Lưu ý rằng nó không phải là phần dữ liệu trong Model và cũng không phải là UI trong View, mà nó quản lý phần dữ liệu mà người dùng đang tương tác

 Model: là phần chứa dữ liệu của ứng dụng và nó được tách riêng với phần giao diện người dùng (UI) Cũng tương tự như trong mô hình MVC Model là các đối tượng giúp truy xuất và thao tác trên dữ liệu thực sự.

Mô hình đa tầng (n-Tier)

Trong kỹ thuật phần mềm, kiến trúc đa tầng (thường được gọi là kiến trúc n-tier) là một kiến trúc client-server trong đó trình bày, xử lý ứng dụng, và quản lý dữ liệu chức năng được tách biệt Việc sử dụng rộng rãi nhất của kiến trúc đa tầng là kiến trúc 3 tầng (3-Tier)

Kiến trúc n-tier ứng dụng cung cấp một mô hình mà các nhà phát triển có thể tạo ra các ứng dụng linh hoạt và sử dụng lại Bằng cách tách một ứng dụng

-21- thành các tầng, các nhà phát triển có được các tùy chọn để sửa đổi hoặc bổ sung thêm một tầng cụ thể, thay vì làm lại toàn bộ ứng dụng

Mô hình 3 tầng (3–Tiers) là một kiến trúc kiểu Client – Server mà trong đó giao diện người dùng (UI-user interface), các quy tắc xử lý (BR-business rule hay BL-business logic), và việc lưu trữ dữ liệu được phát triển như những module độc lập, và hầu hết là được duy trì trên các nền tảng độc lập, và mô hình

3 tầng (3-tier) được coi là một KTPM và là một mẫu thiết kế

2.3.2 Các thành ph ầ n c ủ a mô hình 3 t ầ ng

3-Tiers có tính vật lý (physical): là mô hình client-server (mỗi tier có thể đặt chung 1 nơi hoặc nhiều nơi, kết nối với nhau qua Web services, WCF, Remoting…)

Như vậy, ta có thể mô hình này phân tách ứng dụng ra làm 3 module riêng biệt. Kiến trúc 3-tier gồm 3 tầng chính:

 Presentation Tier: bao gồm các thành phần xử lý giao diện Graphic User Interface (GUI) Được dùng để giao tiếp với người dùng, nhiệm vụ chính là hiển thị dữ liệu và nhận dữ liệu từ người dùng.

 Business Logic Tier: gồm các thành phần Business Logic Layer (BLL), Data Access Layer (DAL) và Data Tranfer Object (DTO) Được dùng để cung cấp các chức năng của phần mềm

 Data Tier: Tầng giao tiếp với các hệ quản trị CSDL

Hình 2.4 Các tầng trong mô hình 3-tier và nhiệm vụ của nó

- Giảm sự gắn kết giữa các thực thể phần mềm: xây dựng phần mềm theo mô hình 3-Tier làm giảm sự gắn kết giữa các thành phần trong hệ thống do mỗi tầng có trách nhiệm độc lập tương đối

Hình 2.5 Mô hình 3-Tier giảm sự gắn kết giữa các thực thể

- Tái sử dụng: chính vì giảm sự gắn kết giữa các tầng nên xây dựng phần mềm theo mô hình 3-Tier giúp cho việc bổ sung, chỉnh sửa, cập nhật hệ thống một cách dễ dàng, đơn giản hơn

Hình 2.6 Mô hình 3-Tier giúp dễ dàng tái sử dụng phần mềm

- Chia sẻ trách nhiệm: vì mỗi tầng có thể đặt ở nhiều nơi khác nhau và vai trò của mỗi tầng là khác nhau và tương đối độc lập nên việc phát triển phần mềm theo mô hình này giúp chia sẻ trách nhiệm ở mỗi tầng cũng như trách nhiệm đối với đội ngũ phát triển hệ thống

Hình 2.7 Mô hình 3-Tier giúp dễ dàng chia sẻ trách nhiệm

3-tier là một KTPM, có nghĩa là bạn có thể dùng nó để xây dựng nên bộ khung tổng thể của ứng dụng Tuy nhiên bạn cần chú ý những ưu và nhược điểm sau đây để áp dụng nó một cách đúng đắn

+ Dễ dàng mở rộng, thay đổi quy mô hệ thống: Khi cần tải lớn, người quản trị có thể dễ dàng thêm các máy chủ vào nhóm, hoặc lấy bớt ra trong trường hợp ngược lại

+ Việc truyền dữ liệu giữa các tầng sẽ chậm hơn vì phải truyền giữa các tiến trình khác nhau (IPC), dữ liệu cần phải được đóng gói -> truyền đi -> mở gói trước khi có thể dùng được

+ Việc phát triển ứng dụng phức tạp hơn.

Mô hình 3-Layer

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 nhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫn nhau Ví dụ trong một công ty có từng phòng ban, mỗi phòng ban sẽ chịu trách nhiệm một công việc cụ thể nào đó, phòng này không được can thiệp vào công việc nội bộ của phòng kia như Phòng tài chính thì chỉ phát lương, còn chuyện lấy tiền đâu phát cho các anh phòng Marketing thì các anh không cần biết Trong phát triển phần mềm, người ta cũng áp dụng cách phân chia chức năng này, đó là mô hình 3-Layer (3 lớp), mỗi lớp sẽ thực hiện một chức năng nào đó

Không như mô hình 3-Tiers có tính vật lý, mô hình 3-Layers có tính logic (mỗi layer có 1 công việc) và là 1 thành phần của 3-Tiers

Mô hình 3-Layer được cấu thành từ 3 Layer: Presentation Layer hay còn gọi là Graphic User Interface (GUI), Business Logic Layer (BLL) và Data Access Layer (DAL) Các lớp này sẽ giao tiếp với nhau thông qua các dịch vụ (services) 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 kia cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi

Mô hình 3 lớp mà Microsoft đề nghị dùng cho các hệ thống phát triển trên nền NET như sau:

Hình 2.8 Các thành phần của mô hình 3-Layer

 GUI: Thành phần giao diện, là các form của chương trình tương tác với người sử dụng

 BLL: Xử lý các nghiệp vụ của chương trình như tính toán, xử lý hợp lệ và toàn vẹn về mặt dữ liệu

 DAL: Tầng giao tiếp với các hệ quản trị CSDL

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ết quả/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ác dịch vụ do lớp Business Logic cung cấp Trong NET ta 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 (1) và User Interface Process Components (2)

 UI Components: là những phần tử chịu trách nhiệm thu thập và hiển thị thông tin cho người dùng cuối Trong ASP.NET thì những thành phần này có thể là các TextBox, các Button, DataGrid…

 UI Process Components: là thành phần chịu trách nhiệm quản lý các qui trình chuyển đổi giữa các UI Components Ví dụ chịu trách nhiệm quản lý các màn hình nhập dữ liệu trong một loạt các thao tác định trước như các bước trong một Wizard…

L ư u ý: lớp này không nên sử dụng trực tiếp các dịch vụ của lớp Data Access mà nên sử dụng thông qua các dịch vụ của lớp Business Logic vì khi sử dụng trực tiếp như vậy thì có thể bỏ qua các ràng buộc, các logic nghiệp vụ mà ứng dụng cần phải có b) Business Logic Layer (BLL)

Lớp này thực hiện các nghiệp vụ chính của hệ thống, sử dụng các dịch vụ do lớp 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ụng cá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

(4), Business Entities (8) và Service Interface (6)

 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

-27- 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 (constraints), các qui tắc nghiệp vụ (business rules), 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 c) Data Access Layer (DAL)

Lớp này thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của ứng dụng Thường lớp này sẽ sử dụng các dịch vụ của các hệ quản trị cơ sở dữ liệu như SQL Server, Oracle, để 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 (7), Servive Agents (5)

 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, File systems… 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 Mapping Frameworks để thực hiện việc ánh xạ các đối tượng trong bộ nhớ thành dữ liệu lưu trữ trong CSDL

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

2.4.3 Ư u đ i ể m khi s ử d ụ ng mô hình 3-Layer

- Trước hết phải nói rằng việc tổ chức dự án Web dưới dạng mô hình 3 lớp sẽ giúp cho dự án có cấu trúc sáng sủa, rõ ràng, dễ dùng lại Từ đó việc phát triển và bảo trì hệ thống sẽ thuận lợi hơn Điều này giúp chúng ta tiết kiệm nhiều thời gian hơn khi mở rộng chương trình trong tương lai Khi dự án bất chợt thay đổi hệ quản trị cơ sở dữ liệu hoặc chuyển ứng dụng từ dạng webform sang dạng

-28- winform thì chúng ta chỉ tốn ít thời gian để thay đổi trên lớp DAL hoặc GUI mà thôi, giữ nguyên hai lớp còn lại mà không cần phải thay đổi toàn bộ dự án

- Một điều cũng vô cùng quan trọng đối với người lập trình viên đó là việc xử lý và bẫy các lỗi runtime Mô hình 3 lớp hỗ trợ cho người lập trình xác định loại lỗi xuất hiện tại lớp nào và dễ dàng đưa ra cách xử lý chúng ở từng lớp cụ thể

So sánh các mô hình kiến trúc phần mềm

2.5.1 So sánh mô hình 3-Tier và mô hình MVC

Trong 3-Tiers, quá trình đi theo chiều dọc, bắt đầu từ Presentation, sang

BL, rồi tới Data, và từ Data, chạy ngược lại BL rồi quay lại Presentation

Hình 2.9 Quá trình xử lý của kiến trúc 3 tầng

Còn trong MVC, dữ liệu được nhận bởi View, View sẽ chuyển cho Controller cập nhật vào Model rồi sau đó dữ liệu trong Model sẽ được đưa lại cho View mà không thông qua Controller, do vậy luồng xử lý này có hình tam giác

Hình 2.10 Quá trình xử lý của mô hình MVC 2.5.2 So sánh 3-tier và 3-layer

3-tiers có nghĩa là 3 tầng, 3-layer có nghĩa là 3 lớp Về mặt ý nghĩa tầng sẽ lớn hơn lớp, mỗi tầng sẽ có nhiều lớp

Không như 3-Tiers có tính vật lý, 3-Layers có tính logic (mỗi layer có 1 công việc) và là 1 thành phần của 3-Tiers

Tầng cho chúng ta thấy sự tách biệt vật lý với nhau, những tầng này có thể nằm cùng một nơi hay các nơi khác nhau, trên thực tế các ứng dụng lớn thì Database sẽ nằm ở một Server, các API hay Web Service nằm một Server khác và ứng dụng thì chạy ở Client

Hình 2.11 Mô hình 3-Tier mang tính vật lý

Khác với tầng, lớp không thể hiện rõ sự tách biệt về mặt vật lý chúng thường nằm chung một nơi nhưng ở các namspace khác nhau

Hình 2.12 Mô hình 3-Layer mang tính logic

Khi dùng từ layer, chúng ta nói tới việc phân chia ứng dụng thành cách thành phần một cách logic theo hướng chức năng hoặc theo vai trò, điều này giúp

-31- phần mềm của bạn có cấu trúc sáng sủa, dễ dùng lại, từ đó giúp việc phát triền và bảo trì dễ dàng hơn Các layer khác nhau khi được thực thi vẫn có thể nằm trong cùng một bộ nhớ của một process, và hiển nhiên việc giao tiếp giữa 2 layer có thể không phải là giao tiếp giữa 2 process, đồng nghĩa với việc chúng không liên quan tới mô hình client/server

Trái lại, tier liên quan đến cách phân chia một cách vật lý các thành phần trên các máy tính khác nhau Điều này làm nhiều người nhầm lẫn giữa layer và tier là chúng có cùng cách phân chia (presentation, business, data), tuy nhiên trên thực tế chúng khác nhau Vì cách phân chia trên nên 1 tier có thể chưa hơn nhiều

Kết luận chương 2

Trong chương này đã trình bày được những đặc điểm cơ bản của các mô hình KTPM phổ biến đang được sử dụng trong phát triển phần mềm thông dụng hiện nay Đồng thời từ đó cũng cho thấy được sự khác nhau giữa các mô hình MVC, mô hình 3-Tiers và 3-Layer

Chương trình demo của khóa luận sẽ được xây dựng dựa trên mô hình 3-Layer và được trình bày cụ thể trong Chương 3

XÂY DỰNG HỆ THỐNG QUẢN LÝ KÝ TÚC XÁ TRƯỜNG ĐẠI HỌC QUẢNG NAM

Khảo sát hệ thống

3.1.1.1 Mô tả khái quát về tổ chức

Trường Đại học Quảng Nam được thành lập dựa trên cơ sở nâng cấp từ Trường Cao đẳng Sư phạm Quảng Nam vào năm 2007, là trường đại học công lập duy nhất của tỉnh Quảng Nam Hiện tại có khoảng 6000 sinh viên hệ chính quy theo học tại trường Trong đú cú khoảng ắ sinh viờn khụng cú hộ khẩu tại

Tp Tam Kỳ, nơi nhà trường tọa lạc Điều đó cho thấy nhu cầu chỗ ở của sinh viên nhà trường là rất lớn

Kí túc xá trường Đại học Quảng Nam chia thành 5 khu, bao gồm:

Hình 3.1 Cơ cấu tổ chức của Trung tâm hỗ trợ sinh viên

Kí Túc Xá Trường ĐH Quảng Nam

+Tầng 1: NV quản lí và 1 số GV

+ Tầng 2,3,4: giành cho sv cử tuyển

+ Từ tầng 1 đến tầng 3: cho sv nữ

+ Tầng 4 giành cho sv nam

Khu này giành cho sv nữ

Khu này có phòng ở kiểu mẫu

Giành cho các du học sinh Lào, gồm

Quản lí và giải quyết các nhu cầu của sv ở trong KTX.

Bộ Phận QL Điện Nước

QL trang thiết bị của KTX và chi phí điện

Việc quản lý KTX nói chung hiện tại của nhà trường vẫn còn gặp nhiều khó khăn vì các công việc quản lý vẫn còn quản lý một cách thủ công, từ việc thông báo, đăng ký chỗ ở, đến việc quản lý hồ sơ sinh viên nội trú, thu chi tiền phòng, tiền điện nước,…vẫn còn quản lý trên sổ sách là chính yếu Đặc biệt là vào đầu mỗi năm học mới, số lượng sinh viên đăng ký vào ở KTX là rất đông, với cách quản lý thủ công như vậy thì việc xử lý các đơn đăng ký của sinh viên rất chậm, đôi khi tạo ra những áp lực trong công việc đối với cán bộ quản lý KTX Vì vậy, việc tin học hóa công tác quản lý KTX của nhà trường là hết sức cần thiết

- Nâng cao chất lượng, hiệu quả quản lý, hỗ trợ sinh viên nội trú của nhà trường

- Hiện đại hóa nội dung và quá trình quản lý, hỗ trợ sinh viên của nhà trường

Cơ cấu tổ chức của Trung tâm hỗ trợ sinh viên được thể hiện ở bảng dưới đây:

TT Họ và Tên Chức vụ Trình độ

1 Hồ Hữu Phước Q Giám đốc Thạc sĩ QLGD

Hải Phó Giám đốc Thạc sĩ

3 Nguyễn Danh Phương Nhân viên Cao đẳng

4 Nguyễn Thị Hiền Oanh CV

5 Lê Thanh Nguyệt Vũ Chuyên viên Trung cấp

6 Đoàn Thị Loan Nhân viên

7 Lê Chiến Thắng Chuyên viên Cử nhân

8 Lê Công Dũng Nhân viên bảo vệ

9 Nguyễn Thị Ngần Nhân viên phục vụ

3.1.2 Các quy trình ho ạ t độ ng nghi ệ p v ụ

Với chức năng, nhiệm vụ của mình, Trung tâm hỗ trợ sinh viên hiện có 23 quy trình hoạt động nghiệp vụ, trong đó có một số quy trình liên quan đến nghiệp vụ quản lý sinh viên nội trú theo danh mục sau:

B ả ng 1: Danh mục quy trình xử lý nghiệp vụ Quản lý khu nội trú

TT Mã quy trình Tên quy trình

1 QT/07/TTHTSV Quy trình đăng ký ở nội trú

2 QT/08/TTHTSV Quy trình tổ chức quản lý khu nội trú

3 QT/09/TTHTSV Quy trình kiểm tra thực hiện nội qui ký túc xá

4 QT/10/TTHTSV Quy trình xử lý sinh viên vi phạm khu nội trú

5 QT/13/TTHTSV Quy trình thực hiện chế độ miễn giảm tại ký túc xá

6 QT/06/TTHTSV Đăng ký tạm trú, tạm vắng

7 QT/17/TTHTSV Quy trình thu, thanh quyết toán phí điện nước kí túc xá

8 QT/21/TTHTSV Quản lý lưu HS-SV Lào

Trong đó, một số quy trình chủ yếu trong công tác quản lý sinh viên nội trú được chi tiết như sau:

B ả ng 2: Quy trình đăng ký ở nội trú (QT/07/TTHTSV)

Trách nhiệm Nội dung thực hiện Hồ sơ

Nhận hồ sơ đăng ký:

Cán bộ BQL KTX nhận đơn đăng ký vào ở khu nội trú (theo mẫu) của học sinh – sinh viên, kèm theo:

- Giấy báo nhập học (photo)

- Các loại giấy tờ khác như: Gia đình có công với cách mạng, con thương bệnh binh, gia đình liệt sỹ, diện dân tộc thiểu số, con mồ côi cả cha lẫn mẹ, nhiễm chất độc hóa học

Phiếu đơn xin ở nội trú

Trách nhiệm Nội dung thực hiện Hồ sơ

Thứ tự ưu tiên xem xét khi tiếp nhận HSSV vào ở nội trú trong trường hợp số người có nguyện vọng vào ở nội trú lớn hơn khả năng tiếp nhận của khu nội trú:

- Anh hùng lực lượng vũ trang, Anh hùng lao động

- Con thương binh và bệnh binh đã xếp hạng (xét theo thứ tự xếp hạng: 1/4, 2/4, 3/4, 4/4)

- HSSV có hộ khẩu thường trú trước khi nhập học ở các địa phương thuộc khu vực 1 (vùng cao, vùng sâu, miền núi, hải đảo…), khu vực 2

- Con mồ côi cả cha lẫn mẹ

- Người có hoàn cảnh khó khăn

- HSSV có nhiều thành tích đóng góp trong công tác tập thể…

- HSSV tham gia công tác lớp, Đoàn, Hội HS-SV Đội tự quản.v.v

Ký hợp đồng ở nội trú:

- Ký hợp đồng ở nội trú (theo mẫu) với sinh viên đăng ký

- Biên bản nhận phòng và bàn giao tài sản trong phòng ở

- Sinh viên phải nắm rõ quy định ở nội trú

- Biên lai thu tiền ở nội trú

Trách nhiệm Nội dung thực hiện Hồ sơ

Kiểm tra việc thực hiện các quy định ở nội trú:

- Theo dõi việc thực hiện nội quy và các quy định ở nội trú

- Theo dõi số lượng sinh viên vào ở và số sinh viên xin ra không ở nội trú trong từng tháng

- Xử lý các hành vi làm hư hỏng và mất mát tài sản khu nội trú

- Kiểm tra việc sử dụng điện, nước…

- Biên bản giao trả phòng ở và tài sản

- Hàng tuần có kế hoạch tổ chức lao động cho HSSV trong khu nội trú

- Thu tiền điện nước hàng tháng HSSV đã sử dụng

- Chấm điểm phòng ở kiểu mẫu trong khu nội trú

- Hàng tháng có kế hoạch họp phòng trưởng vào đầu tháng và thông qua đó giáo dục HSSV trong khu nội trú thực hiện nội quy phòng ở trong khu nội trú

- Sổ thu tiền điện nước

Trách nhiệm Nội dung thực hiện Hồ sơ

- Xếp điểm rèn luyện cho từng HSSV trong khu nội trú và chuyển về phòng CTSV

- Trước khi nhận bàn giao phòng từ HSSV phải kiểm tra CSVC, vệ sinh trong phòng ở

- Thực hiện theo quy định của thủ tục quy trình kiểm soát hồ sơ

Các hồ sơ nêu trên

B ả ng 3: Quy trình tổ chức quản lý khu nội trú (QT/08/TTHTSV)

Trách nhiệm Nội dung thực hiện Hồ sơ

- Có bảng hiệu tên theo thứ tự từng khu: C1, C2, C3, C4, C5

- Mỗi khu có một bảng nội qui KTX, một bảng thông báo Có hệ thống loa phát thanh

- Có số phòng ở mỗi khu, có số giường ở mỗi phòng

- Lập hồ sơ sinh viên ở theo phòng và khu nội trú

- Lập sổ HSSV nội trú danh sách và có ảnh từng khu

- Mỗi phòng bầu một phòng trưởng có biên bản

- Có lịch phân công trực vệ sinh phòng hằng ngày ở mỗi phòng

- Có bảng nội qui phòng ở

- Mỗi sinh viên có một thẻ sinh viên nội trú

- Sổ có ảnh sinh viên

2 CBBQLNT - Thành lập 1 đội tự quản HSSV - Quyết

Trách nhiệm Nội dung thực hiện Hồ sơ

- Qui định chức năng nhiệm vụ đội tự quản

- Có lịch phân công trực đội tự quản

- Cán bộ quản lý khu nội trú chia lịch trực 24/24h định thành lập đội tự quản

- Kế hoạch HSSV các phòng làm vệ sinh khu nội trú mỗi tuần 1 lần

- Xây dựng kế hoạch họp phòng trưởng mỗi tháng 1 lần

- Kế hoạch kiểm tra việc thực hiện nội qui KTX định kỳ, đột xuất

- Xử lý HSSV vi phạm nội qui khu nội trú

- Khen thưởng những HSSV có thành tích trong các phong trào hoạt động nội trú

- Biên bản, bảng kiểm điểm, sổ khen thưởng kỷ luật.

B ả ng 4: Quy trình thu, thanh quyết toán phí điện nước (QT/17/TTHTSV)

TT Trách nhiệm Mô tả cách thức thực hiện

Sau khi Tổng hợp xong bảng điện nước vào đầu tháng

Ký bảng thu điện nước sau khi chuyên viên trình

Ký bảng nộp tiền điện cho P KH-TC

2 CB QL - Ghi chữ điện nước vào ngày cuối tháng

TT Trách nhiệm Mô tả cách thức thực hiện

- Gửi giấy báo đến các phòng sau khi CV làm xong giấy báo

- Lập bảng tỉnh điện nước sau khi CB QL ghi chữ số điện nước vào ngày cuối tháng

- Xuất giấy báo điện nước

- Nộp tiền điện cho nhà trường sau khi thu tiền xong

- Nộp tiền nước cho nhà máy nước sau khi thu tiền xong

Phiếu điện nước Bảng tính điện nước

- Ghi chữ số điện tổng KTX vào ngày cuối tháng

- Lập bảng thu tiền điện hàng tháng

- Thu tiền điện theo bảng thu tiền điện của phòng Quản trị

B ả ng 5: Quy trình quản lý sinh viên Lào (QT/21/TTHTSV)

TT Trách nhiệm Nội dung thực hiện Hồ sơ

Nhận hồ sơ đăng ký:

Có Quyết định tiếp nhận của BGH đối với Lưu HS-SV

Cán bộ BQL KTX nhận đơn đăng ký vào ở khu nội trú (theo mẫu) của học sinh - sinh viên, kèm theo:

Phiếu đơn xin ở nội trú

Ký hợp đồng ở nội trú:

- Ký hợp đồng ở nội trú (theo mẫu) với sinh viên đăng ký

- Biên bản nhận phòng và bàn giao tài sản trong

TT Trách nhiệm Nội dung thực hiện Hồ sơ phòng ở

- Sinh viên phải nắm rõ quy định ở nội trú

Kiểm tra việc thực hiện các quy định ở nội trú:

- Theo dõi việc thực hiện nội quy và các quy định ở nội trú

- Theo dõi số lượng sinh viên vào ở và số sinh viên xin ra không ở nội trú trong từng tháng

- Xử lý các hành vi làm hư hỏng và mất mát tài sản khu nội trú

- Kiểm tra việc sử dụng điện, nước…

- Thanh lý hợp đồng hết học kỳ, hết năm học

- Biên bản giao trả phòng ở và tài sản

- Hàng tuần có kế hoạch tổ chức lao động cho HSSV trong khu nội trú

- Thu tiền điện nước hàng tháng HSSV đã sử dụng

- Chấm điểm phòng ở kiểu mẫu trong khu nội trú

- Hàng tháng có kế hoạch họp phòng trưởng vào đầu tháng và thông qua đó giáo dục cho Lưu HSSV trong khu nội trú thực hiện nội quy phòng ở trong khu nội trú

- Xếp điểm rèn luyện cho từng HSSV trong khu nội trú và chuyển về phòng CTSV, các khoa

- Trước khi nhận bàn giao phòng từ HSSV phải

TT Trách nhiệm Nội dung thực hiện Hồ sơ kiểm tra CSVC, vệ sinh trong phòng ở

- Thực hiện theo quy định của thủ tục quy trình kiểm soát hồ sơ

Các hồ sơ nêu trên

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

3.2.1.1 Mục tiêu của hệ thống

- Nâng cao hiệu quả, giải quyết bớt áp lực cho Cán bộ quản lý trong việc quản lý sinh viên nội trú

- Tối đa công tác tin học hóa việc quản lý ký túc xá, nâng cao sự tin học hóa nhà trường

- Đáp ứng yêu cầu cần thiết quản lý sinh viên nội trú theo yêu cầu của Trung tâm hỗ trợ sinh viên nói riêng và của nhà trường nói chung

3.2.1.2 Yêu cầu phi chức năng

 Giao diện hài hòa, thẫm mỹ, dễ thao tác, thực hiện

 Khi sinh viên thực hiện đăng ký vào ở KTX đảm bảo họ phải đọc kỹ nội quy của KTX

 Giải quyết được những vấn đề còn tồn tại của hệ thống cũ

 Xây dựng phần mềm trong nguồn kinh phí cho phép

 Quản lý thông tin hồ sơ đăng ký ở KTX

 Sắp xếp phòng cho sinh viên

 Quản lý sinh viên ở KTX

 Quản lý phòng, tài sản trong KTX

 Cho phép tìm kiếm thông tin của một sinh viên, một hồ sơ đăng ký, phòng còn trống, sinh viên chưa đóng lệ phí,…

 Quản lý các khoản thu: tiền phòng, tiền điện, tiền nước và các khoản thu khác

 Tìm kiếm, in danh sách sinh viên theo yêu cầu

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

3.2.2.2 Ca sử dụng của hệ thống

 Đăng nhập hệ thống: mô tả người dùng (Ban Quản lý KTX) đăng nhập vào hệ thống bằng tài khoản đã được tạo trước đó để thực hiện các chức năng đã được phân quyền của hệ thống

 Đăng ký sử dụng: mô tả việc Ban quản lý đăng ký tài khoản để đăng nhập hệ thống

 Quản lý thông tin sinh viên: mô tả việc Ban Quản lý cập nhật thông tin của sinh viên

 Quản lý phòng: mô tả việc Ban Quản lý cập nhật các thông tin về phòng ở, tài sản có trong phòng ở và chuyển phòng ở cho Sinh viên

 Quản lý khoản thu: mô tả việc Ban Quản lý cập nhật phí nội trú của sinh viên và phí điện nước của phòng ở

 Tìm kiếm: mô tả việc Ban Quản lý tìm kiếm các thông tin về sinh viên, hồ sơ đăng ký và phòng ở

 Thống kê báo cáo: mô tả việc Ban Quản lý thống kê về sinh viên, phòng ở, hồ sơ đăng ký; báo cáo các khoản thu

3.2.2.3 Biểu đồ ca sử dụng (Use Case) của hệ thống uc uc QLKTX

Tìm Kiếm Thống kê, báo cáo Đăng ký sử dụng

Kiểm tra tài khoản ôextendằ ôincludeằ

3.2.2.4 Đặc tả ca sử dụng

Tên Use-Case: Đăng nhập ID: 1 Mức độ quan trọng: Cao

Kiểu Use-Case: Chi tiết, cần thiết

Ca sử dụng mô tả người dùng (Ban Quản lý KTX) đăng nhập vào hệ thống bằng tài khoản đã được tạo trước đó để thực hiện các chức năng đã được phân quyền của hệ thống

- Ban quản lý: đăng nhập vào hệ thống và thực hiện quản lý đăng ký ở KTX, quản lý thông tin sinh viên, quản lý phòng, quản lý khoản thu, tìm kiếm thông tin, thống kê báo cáo

Kết hợp (Association): Ban quản lý

Bao hàm (Include): Kiểm tra tài khoản

Các luồng sự kiện thông thường:

1 Ban quản lý đăng nhập vào hệ thống

2 Hệ thống kiểm tra tính hợp lệ của tài khoản (tên, mật mã và phân quyền)

3 Ban quản lý thoát khỏi hệ thống

Các luồng sự kiện con:

Các luồng sự kiện thay thế/ngoại lệ:

3a Nếu tài khoản không hợp lệ thì hệ thống thông báo yêu cầu người dùng đăng nhập lại vào hệ thống hoặc tạo một mật khẩu mới (nếu quên mật khẩu) 3b Nếu là người dùng mới thì Ban quản lý có thể tạo một tài khoản truy cập mới

Tên Use-Case: Đăng ký sử dụng ID: 2 Mức độ quan trọng: Bình thường Tác nhân chính:

Kiểu Use-Case: Chi tiết, cần thiết

Ca sử dụng mô tả người dùng tạo một tài khoản sử dụng để đăng nhập vào hệ thống

Ban quản lý đăng ký tài khoản mới khi đăng nhập lần đầu tiên

Kết hợp (Association): Ban quản lý

Mở rộng (Extend): Kiểm tra tài khoản

Các luồng sự kiện thông thường:

1 Ban quản lý đăng ký mới tài khoản

2 Hệ thống kiểm tra tính hợp lệ về thông tin đăng ký của người dùng

3 Ban quản lý thoát khỏi hệ thống

Các luồng sự kiện con:

2a Nếu thông tin đăng ký người dùng nhập vào hợp lệ thì hệ thống sẽ thông báo thành công cho người dùng

Các luồng sự kiện thay thế/ngoại lệ:

2a-1 Nếu thông tin tài khoản đăng ký không hợp lệ thì hệ thống thông báo yêu cầu người dùng đăng ký lại

2b Hủy đăng ký sử dụng

Tên Use-Case: Quản lý thông tin sinh viên

ID: 3 Mức độ quan trọng: Bình thường

Kiểu Use-Case: Chi tiết

Ca sử dụng mô tả việc Ban Quản lý cập nhật thông tin của sinh viên

- Ban quản lý đăng nhập vào hệ thống và cập nhật thông tin về một sinh viên

Kết hợp (Association): Ban quản lý

Các luồng sự kiện thông thường:

1 Ban quản lý chọn hiển thị thông tin sinh viên

2 Ban quản lý chọn cập nhật thông tin

3 Hệ thống kiểm tra tính hợp lệ của thông tin

4 Ban quản lý viên chấp nhận cập nhật

5 Hệ thống thực hiện cập nhật và gởi thông báo kết quả

6 Ban quản lý thoát khỏi hệ thống

Các luồng sự kiện con:

Các luồng sự kiện thay thế/ngoại lệ:

3a Nếu thông tin không hợp lệ thì hệ thống thông báo yêu cầu người dùng cập nhật lại

Tên Use-Case: Quản lý Phòng ID: 4 Mức độ quan trọng: Cao

Kiểu Use-Case: Tổng quát, cần thiết

Ca sử dụng mô tả việc Ban Quản lý cập nhật các thông tin về phòng ở, tài sản có trong phòng ở và chuyển phòng ở cho Sinh viên

BQL đăng nhập vào hệ thống và cập nhật thông tin về phòng ở trong KTX

Kết hợp (Association): Ban quản lý

Các luồng sự kiện thông thường:

1 Ban quản lý chọn hiển thị thông tin phòng ở

2 Ban quản lý chọn cập nhật thông tin phòng ở

3 Hệ thống kiểm tra tính hợp lệ của thông tin

4 Ban quản lý chấp nhận cập nhật

5 Hệ thống thực hiện cập nhật và gởi thông báo kết quả

6 Ban quản lý thoát khỏi hệ thống

Các luồng sự kiện con:

2a Ban quản lý cập nhật thông tin riêng của phòng ở

2b Ban quản lý cập nhật tài sản của phòng ở

2c-1 Ban quản lý xem DS sinh viên của phòng ở

2c-2 Ban quản lý chuyển SV đến phòng ở mới còn trống

Các luồng sự kiện thay thế/ngoại lệ:

3a Nếu thông tin không hợp lệ thì hệ thống thông báo yêu cầu người dùng cập nhật lại

Tên Use-Case: Quản lý Khoản thu ID: 5 Mức độ quan trọng: Cao

Kiểu Use-Case: Tổng quát, cần thiết

Ca sử dụng mô tả việc Ban Quản lý cập nhật phí nội trú của sinh viên và phí điện nước của phòng ở

Ban quản lý đăng nhập vào hệ thống và cập nhật khoản thu

Kết hợp (Association): Ban quản lý

Các luồng sự kiện thông thường:

1 Ban quản lý chọn hiển thị các khoản thu theo phòng

2 Ban quản lý chọn cập nhật các khoản thu

3 Ban quản lý chấp nhận cập nhật

4 Hệ thống thực hiện cập nhật và gởi thông báo kết quả

5 Ban quản lý thoát khỏi hệ thống

Các luồng sự kiện con:

2a Ban quản lý cập nhật khoản thu phí nội trú theo sinh viên

2b Ban quản lý cập nhật khoản thu phí điện nước theo phòng

Các luồng sự kiện thay thế/ngoại lệ:

Tên Use-Case: Thống kê báo cáo ID: 6 Mức độ quan trọng: Cao

Tác nhân chính: Ban quản lý Kiểu Use-Case: Tổng quát, cần thiết

Ca sử dụng mô tả việc Ban Quản lý thống kê về sinh viên, phòng ở, hồ sơ đăng ký; báo cáo các khoản thu

Ban quản lý đăng nhập vào hệ thống và thống kê báo cáo theo yêu cầu

Kết hợp (Association): Ban quản lý

Các luồng sự kiện thông thường:

1 Ban quản lý chọn yêu cầu thống kê báo cáo

2 Hệ thống thực hiện thống kê và gởi kết quả

3 Ban quản lý thoát khỏi hệ thống

Các luồng sự kiện con:

1a Ban quản lý chọn yêu cầu thống kê theo sinh viên

1b Ban quản lý chọn yêu cầu thống kê theo phòng

1c Ban quản lý chọn yêu cầu thống kê theo hồ sơ đăng ký

1d Ban quản lý chọn yêu cầu báo cáo các khoản thu

1d-1 Báo cáo phí nội trú theo yêu cầu

1d-2 Báo cáo phí điện nước theo yêu cầu

Các luồng sự kiện thay thế/ngoại lệ:

3.2.3 Mô hình c ấ u trúc c ủ a H ệ th ố ng

3.2.3.1 Xác định các lớp thực thể

Dựa vào các quy tắc phân tích văn bản cũng như những yêu cầu của hệ thống, hệ thống bao gồm các lớp thực thể sau:

- Lớp Tài khoản (TaiKhoan) gồm các thuộc tính:

- Lớp Sinh viên (SinhVien) gồm các thuộc tính:

 maSV: Mã sinh viên do nhà trường quy định

 tenSV: Họ tên sinh viên

 CMND: Chứng minh nhân dân của sinh viên

 khoa: Khoa sinh viên đang học

 lop: Lớp sinh viên đang học

 ngayVao: Ngày được chấp nhận vào ở KTX

- Lớp Phòng (Phong) gồm các thuộc tính:

 soGiuong: Số giường có thể dùng trong 1 phòng

 soGiuongTrong: Số giường còn trống

 GioiTinh: Phòng này dành cho Nam hay Nữ

- Lớp Tài sản (TaiSan) gồm có các thông tin sau:

- Lớp Khoa (Khoa) gồm các thông tin sau:

- Lớp Phí điện nước (PhiDienNuoc) gồm có các thông tin sau:

 chiSoDienDau: Chỉ số điện đầu tháng

 chiSoDienCuoi: Chỉ số điện cuối tháng

 chiSoNuocDau: Chỉ số nước đầu tháng

 chiSoNuocCuoi: Chỉ số nước cuối tháng

 nguoiNopPhi: Người phí điện nước

3.2.3.2 Xác định các lớp biên

Lớp biên là các lớp nhằm chuyển đổi thông tin giao tiếp giữa các tác nhân và hệ thống Đó chính là các giao diện để tác nhân giao tiếp với hệ thống, cho phép thu thập thông tin hay xuất các kết quả Mỗi cặp tác nhân-ca sử dụng có ít nhất 01 lớp biên

Dựa vào các ca sử dụng đã được xây dựng ở trên, hệ thống có các lớp biên như sau:

 Đố i v ớ i các s ử d ụ ng Đă ng nh ậ p:

- I_NSD_DN: giao diện cho phép người dùng nhập vào các thông tin đăng nhập hệ thống

 Đố i v ớ i ca s ử d ụ ng Đă ng ký s ử d ụ ng:

- Lớp I_NSD_DKTK: giao diện cho việc đăng ký một tài khoản mới

-52- của tác nhân Ban Quản lý KTX…

 Đố i v ớ i ca s ử d ụ ng Qu ả n lý thông tin sinh viên:

- Lớp I_NSD_TTSV: giao diện chính giao tiếp giữa tác nhân Ban Quản lý KTX và hệ thống

 Đố i v ớ i ca s ử d ụ ng Qu ả n lý phòng:

- Lớp I_QL_QLPhong: giao diện chính giao tiếp giữa tác nhân Ban Quản lý KTX và hệ thống

- Lớp I_QL_Them_SuaPhong: giao diện cho phép cho phép tác nhân Ban quản lý KTX thêm/sửa một phòng

- Lớp I_QL_Them_SuaTS: giao diện cho phép cho phép tác nhân Ban quản lý KTX thêm/sửa tài sản cho một phòng

- Lớp I_QL_ChuyenSV: giao diện cho phép cho phép tác nhân Ban quản lý KTX xếp phòng, chuyển phòng cho sinh viên

 Đố i v ớ i ca s ử d ụ ng Qu ả n lý kho ả n thu:

- Lớp I_QL_QLKT: giao diện chính giao tiếp giữa tác nhân Ban Quản lý KTX và hệ thống

- Lớp I_QL_PhiNT: giao diê ̣n cho phép tác nhân Ban quản lý KTX cập nhật lệ phí nội trú của sinh viên

- Lớp I_QL_PhiDN: giao diê ̣n cho phép tác nhân Ban quản lý KTX cập nhật lệ phí điện nước của sinh viên theo từng phòng

 Đố i v ớ i ca s ử d ụ ng Th ố ng kê báo cáo:

- Lớp I_QL_TKBC: giao diện chính giao tiếp giữa tác nhân Sinh viên, Ban Quản lý KTX và hệ thống

- Lớp I_QL_TKSV: giao diện cho phép tác nhân Ban quản lý KTX thống kê sinh viên trong ký túc

- Lớp I_QL_BCPDN: giao diện cho phép tác nhân Ban quản lý KTX báo cáo phí Điện nước của phòng

- Lớp I_QL_BCPNT: giao diện cho phép tác nhân Ban quản lý KTX báo cáo phí Lưu trú của sinh viên

- Lớp I_QL_TKPhong: giao diện cho phép tác nhân Ban quản lý KTX

-53- thống kê tình trạng phòng trong KTX

3.2.3.3 Xác đinh các lớp điều khiển

Lớp điều khiển là các lớp điều hành sự diễn biến trong một ca sử dụng Các lớp điều khiển chứa các quy tắc nghiệp vụ và đứng trung gian giữa lớp biên và lớp thực thể, cho phép từ màn hình có thể truy xuất được các thông tin chứa trong các lớp thực thể Mỗi ca sử dụng có ít nhất một lớp điều khiển Các lớp điều khiển chính của hệ thống:

- Lớp C_NSD_DK: lớp điều khiển cho ca sử dụng Đăng ký tài khoản

- Lớp C_NSD_DN: lớp điều khiển cho ca sử dụng Đăng nhập hệ thống

- Lớp C_QL_TTSV: lớp điều khiển cho ca sử dụng Quản lý thông tin sinh viên

- Lớp C_QL_QLPhong: lớp điều khiển cho ca sử dụng Quản lý phòng

- Lớp C_QL_QLKT: lớp điều khiển cho ca sử dụng Quản lý khoản thu

- Lớp C_QL_TKBC: lớp điều khiển cho ca sử dụng Thống kê báo cáo

3.2.4 Mô hình hành vi c ủ a H ệ th ố ng

Một số biểu đồ tuần tự cho các ca sử dụng chính:

* Bi ể u đồ tu ầ n t ự cho ca s ử d ụ ng Đă ng nh ậ p

:I_NSD_DN :C_NSD_DN :TaiKhoan

:NSD ycDangNhap() hienThiDangNhap() chonDangNhap(tenDN, matKhau) ycKiemTra(tenDN, matKhau) kiemTraTK(String, String) ketQua() ketQua() hienThiThongBao()

* Bi ể u đồ tu ầ n t ự cho Ca s ử d ụ ng Qu ả n lý sinh viên sd QL thong tin SV

:I_NSD_TTSV :I_NSD_SuaTT :C_NSD_TTSV :SinhVien

:DSSV chonHienThiTTSV() ycHienThiTTSV() layDSSV() ketQua() ketQua() hienThiKQ() chonThem/SuaTTSV() hienThiThemSua() nhapTT() ycThem/SuaTTSV() capNhatSV(maSV) ketQua() ketQua() hienThiTB()

* Bi ể u đồ tu ầ n t ự cho Ca s ử d ụ ng Qu ả n lý phòng sd QL Phong

:I_QL_Them_SuaPhong :C_QL_QLPhong :Phong

:DSPhong chonHienThiDSPhong() ycHienThiDSPhong() layDSPhong() ketQua() ketQua() hienThiDSPhong() chonThemSua() hienThiThemSua() nhapTT() ycThemSua() capNhatPhong() ketQua() ketQua() hienThiTB()

* Bi ể u đồ tu ầ n t ự cho Ca s ử d ụ ng Qu ả n lý kho ả n thu

+ Đối với ca sử dụng Thu phí nội trú: sd Thu phi Noi tru

:I_QL_QLKT :I_QL_QLNT :C_QL_QLKT chonCapnhatKT() htCapNhatKT() nhapTTCapNhat() ycCapNhat() capNhatPNT(maSV) ketQua() ketQua() hienThiTB()

+ Đối với ca sử dụng Thu phí điện nước: sd Thu phi Dien nuoc

:I_QL_QLKT :I_QL_QLDN :C_QL_QLKT :PhiDienNuoc chonCapNhatDN() htCapNhat() chapNhan() ycCapNhat() capNhatPDN(maPhong) ketQua() ketQua() hienThiTB()

Các biểu đồ hoạt động cho các phương thức chính của các lớp chính: a) Ph ươ ng th ứ c kiemTraTK(tenDN, matKhau) c ủ a l ớ p TaiKhoan: act KiemTraTK

Nhap thong tin tai khoan ôdatastoreằ

Dung Sai b) Ph ươ ng th ứ c themSV (thêm SV vào KTX) c ủ a l ớ p SinhVien sd act ThemSV

Thông báo kết quả ôdatastoreằ

Obj ect1 ki ểm tra thông ti n

-59- c) Ph ươ ng th ứ c chuyenSV (chuy ể n phòng ở cho Sinh viên) c ủ a l ớ p SinhVien sd act ChuyenPhong

Chuyển phòng Chọn SV muốn chuyển

Cập nhật thông tin Cập nhật phòng

Thông báo kết quả ôdatastoreằ

3.2.5.1 Cơ sở dữ liệu của hệ thống

* Lớp thực thể: class Class Mo

+ SuaDoiTuongUT() : void + ThemDoiTuongUT() : void + XoaDoiTuongUT() : void

+ SuaSV() : void + ThemVS() : void + XoaSV() : void

+ SuaLop() : void + ThemLop() : void + XoaLop() : void

+ SuaTonGiao() : void + ThemTonGiao() : void + XoaTonGiao() : void

+ SuaDanToc() : void + ThemDanToc() : void + XoaDanToc() : void

+ SuaKhoaHoc() : void + ThemKhoaHoc() : void + XoaKhoaHoc() : void

DOITUONG madoituong tendoituong mucuutien ghichu

PHIDIENNUOC sobienlaidiennuoc chisodiendau chisodiencuoi chisonuocdau chisonuoccuoi ngaydau ngaycuoi sotiendien sotiennuoc ngaythu maphong nguoinopphi Q

PHONG maphong tenphong sogiuong sogiuongtrong gioitinh

SINHVIEN masv tensv CMND gioitinh madantoc madoituong sodienthoai diachi makhoahoc ngayvao matongiao maphong makhoa malop

TAISAN mataisan maphong tentaisan soluong

LOP malop tenlop makhoa ghichu

PhiNoiTru sobienlaiphinoitru hocky namhoc sotien ngaythu

ID_LichSu masv tensv tenlop tenkhoa ngayra tendantoc tentongiao

BANQUANLY maBQL hoten ngaysinh gioitinh tendangnhap matkhau

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc

PK MaSV Text 10 Mã của sinh viên

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc

TenSV Text 50 Họ tên sinh viên

NgaySinh Date/Time Ngày sinh

CMND Text 10 Chứng minh nhân dân

FK MaDanToc Text 10 Dân tộc

FK MaDoiTuong Text 5 Đối tượng được hưởng chế độ ưu tiên

SoDT Text 15 Số điện thoại

KhoaHoc Text 2 Khóa học của sinh viên NgayVao Date/Time Ngày vào ở KTX

FK MaPhong Text 5 Mã phòng SV ở

FK MaKhoa Text 2 Mã khoa

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc (nếu có)

PK MaPhong Text 5 Mã phòng ở

2 ký tự đầu: tên khu; 3 ký tự sau số phòng

GioiTinh Text Phòng dành cho

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc (nếu có)

SoGiuong Byte Số giường trong phòng SoGiuongTrong Byte Số giường trống

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc (nếu có)

PK MaTaiSan Text 10 Mã tài sản

FK MaPhong Text 5 Mã phòng

TenTaiSan Text 30 Tên tài sản

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc

PK SoBienLaiDN Text Số biên lai thu phí điện nước ChiSoDienDau Integer Chỉ số điện đầu

ChiSoDienCuoi Integer Chỉ số điện cuối

ChiSoNuocDau Integer Chỉ số nước đầu

ChiSoNuocCuoi Integer Chỉ số nước cuối

NgayDau Date/Time Ngày đầu

NgayCuoi Date/Time Ngày cuối

SoTienDien Text 7 Số tiền điện

SoTienNuoc Text 7 Số tiền nước

NgayThu Date/Time Ngày thu

FK MaPhong Text 5 Mã phòng nộp phí

NguoiNopPhi Text 10 Người nộp phí

FK MaBQL Text Mã BQL thu phí

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc

PK SoBienLaiNT Text 10 Số biên lai thu phí nội trú NgayThu Date/Time Ngày thu phí

SoTien Text 7 Số tiền nộp

FK MaBQL Text 10 Mã CB Ban QL thu phí

Kiểu dữ liệu Độ rộng Mô tả Ràng buộc

PK MaKhoa Text 10 Mã khoa

TenKhoa Text 15 Tên khoa của SV

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả Ràng buộc

PK MaDoiTuong Text 10 Mã ngành đối tượng ưu tiên TenDoiTuong Text 30 Tên đối tượng ưu tiên

MucUuTien Text 50 Mức ưu tiên

Kiểu dữ liệu Độ rộng Mô tả Ràng buộc

PK MaLop Text 10 Mã lớp sinh viên học

TenLop Text 30 Tên lớp sinh viên học

FK MaKhoa Text 10 Mã khoa (có lớp SV học)

Khóa Tên trường Kiểu dữ liệu Độ rộng Mô tả

PK MaBQL Text 10 Mã người quản lý

HoTen Text Họ tên người quản lý

NgaySinh date Ngày sinh người quản lý

GioiTinh Text Giới tính người quản lý

TenDangNhap Text 30 Tên đăng nhập vào hệ thống MatKhau Text 30 Mật khẩu đăng nhập vào hệ thống

3.2.5.2 Biều đồ định hướng giao diện người dùng a) Bi ể u đồ đị nh h ướ ng giao di ệ n ng ườ i dùng cho ca s ử d ụ ng C ậ p nh ậ t sinh viên custom User Interface Mo Đăng nhập

Số điện thoại Địa chỉ

Thêm/Sửa Xóa Đăng nhập thành công

Chọn danh mục SV - Chọn cập nhật SV

Chọn Thêm/Sửa Chọn xóa

-68- b) Bi ể u đồ đị nh h ướ ng giao di ệ n ng ườ i dùng cho ca s ử d ụ ng Chuy ể n phòng SV custom User Interface Mo Đăng nhập

Số điện thoại Địa chỉ Dân tộc

Ngày vào Phòng chuyển đến

Thông báo Đăng nhập thành công

Chọn danh mục SV - Chọn chuyển phòng SV

Chọn SV và nhấn chuyển phòng

 Ngôn ngữ cài đặt: ngôn ngữ lập trình C#

 Kiến trúc mô hình của chương trình: mô hình 3-Layer

 Cơ sở dữ liệu: MS SQL Server 2008

 Môi trường hệ thống: môi trường NET Framework 4.0

Cài đặt kiến trúc chương trình theo mô hình 1- tier, 3 layer

+ “LopGiaoDien”: Tại lớp này chứa các Form giao diện để người dùng trực tiếp thực hiện các thao tác với hệ thống, với một số Form chính như sau: frmMainForm, frmThemSinhVien, frmTinhPhiDienNuoc, frmTinhPhiNoiTru…

+ “LopDuLieu”: Lớp này chứa các class riêng nhằm phục vụ cho đối tượng riêng và thực hiện việc truy cập đến CSDL SQL

Một số lớp tiêu biểu:

* D_SinhVien (Dữ liệu sinh viên)

+ “LopXuLy”: Lớp này chứa các class nhằm thực hiện việc truy cập đến

Một số lớp tiêu biểu:

Ngoài ra, còn có “LopThuThe” là lớp để ánh xạ các bảng trong CSDL quan hệ

Bước 2: Tạo tham chiếu giữa các lớp

+ “LopGiaoDien”: Tham chiếu đến “LopXuLy” và “LopThucThe”

+ “LopXuLy”: Tham chiếu đến “LopDuLieu” và “LopThucThe”

+ “LopDuLieu”: Tham chiếu đến “LopThucThe”

Thực hiện viết mã lệnh cho chương trình theo cấu trúc đã tạo ở trên

-71- Hình 3.3 sau đây thể hiện kiến trúc chương trình như đã trình bày:

Hình 3.3 Kiến trúc của chương trình demo theo mô hình 1-Tier, 3-Layer

Một số giao diện chính của chương trình

Hình 3.4 Giao diện Đăng nhập của chương trình

Hình 3.5 Giao diện chính của chương trình

Hình 3.6 Cửa sổ nhập thông tin SV mới

Hình 3.7 Cửa sổ chuyển sinh viên qua phòng khác

Hình 3.8 Cửa sổ tính phí điện nước từng phòng

Kết luận chương 3

Chương 3 đã phân tích và thiết kế hệ thống Quản lý Ký túc xá trường Đại học Quảng Nam, đồng thời cũng cài đặt thử nghiệm chương trình theo mô hình 1-tier, 3-layer chạy trên môi trường NET Framework 4.0 và ngôn ngữ lập trình C#, CSDL được quản lý và lưu trữ trên SQL Server 2008

Qua đó cũng cho thấy được ứng dụng của các mô hình kiến trúc phần mềm trong thực tế đã mang lại những thuận lợi cho việc phát triển phần mềm