3.6.1. Áp dụng mẫu Bridge thiết kế lớp Sinhviên
1. ý nghĩa
Chúng ta đã biết trong thiết kế hướng đối tượng, một thành phần thường tồn tại hai phần: thành phần ảo (abstraction) - định nghĩa trước các chức năng và phần
thực thi (implementation) - thực thi các chức năng được định nghĩa trong phần ảo. Hai phần này liên quan với nhau thông qua quan hệ kế thừa. Những thay đổi tại abstraction thường dẫn đến những thay đổi tại implementation . Mẫu Bridge được sử dụng để tách thành phần ảo và phần thực thi riêng biệt. Nhờ đó các phần này có thể thay đổi, chỉnh sửa một cách độc lập và linh động. Thay vì liên hệ với nhau bằng quan hệ kế thừa, hai phần này sẽ liên hệ với nhau thông qua quan hệ chứa
trong “aggregation”
2. Bài toán thực tế
Trong hệ thống cơ sở dữ liệu cũ của trường đang sử dụng một lớp các đối tượng SINHVIEN (SV) để lưu toàn bộ các thông tin vê sinh viên được quản lý trong trường. Do số lượng sinh viên ngày càng nhiều và các thông tin quản lý trên mỗi sinh viên cũng phải tăng thêm do đó lớp đối tượng SINHVIEN cần phải được thay
đổi thành (PIMSV- personal info manager) sao cho việc quản lý ngày càng thuận tiện. Để thực hiện được mục đích này phương án đầu tiên là nhóm các đối tượng được thừa kế từ SV, mỗi đối tượng này sẽ thực hiện chức năng liệt kê khác nhau:
Hình 3.32. Sơ đồ thiết kế lớp sinh viên ban đầu
Tuy nhiên, giải pháp này không thực tế vì có rất nhiều cách kết hợp với nhau để tạo thành một kiểu SV mới. Như sơ đồ trên mặc dù cùng hiển thị một loại thông tin là nhiệm vụ (TaskSV), nhưng có hai cách hiển thị khác nhau là unorderSV và
prioritizedtaskSV. Mỗi lần tạo ra một kiểu mới như vậy, chúng ta phải tạo thêm một kiểu mới kế thừa rất mất thời gian và thiết kế rối rắm, trùng lặp nhiều.
Với một thiết kế tốt chỉ cần dùng lớp NameSV, TaskSV, unorderSV, PrioritizedSV, sau đó chúng ta kết hợp với nhau. Như vậy không chỉ đỡ tốn thờI
gian và chi phí, mà các yêu cầu, các chức năng vẫn được thực hiện đúng đắn và đầy đủ. Một giải pháp được đề ra là mỗi lớp đối tượng SV được tách thành hai
phần:
+ Svimterface (abstraction): Định nghĩa các chức năng hiển thị cơ bản như hiển thị theo tên, theo chức danh, theo nhiệm vụ...
+ Svimplementation (implementation): Thực thi các cách hiển thị theo thứ tự, độ ưu tiên...
Hình 3.33. Sơ đồ thiết kế lớp sinh viên sau khi biến đổi
Các chức năng bên SVInterface sẽ không làm gì hết mà uỷ quyền thực hiện việc hiển thị cho SVimplementer
Client SVInterface SVimplementer
NameSV
3. Cấu trúc mẫu
+ Biểu đồ lớp chưa áp dụng mẫu
Hình 3.34 Sơ đồ thiết kế lớp sinh viên
Hình 3.35. Sơ đồ thiết kế lớp sinh viên áp d ụng mẫu Bridge
4. Thuận lợi và hạn chế
Thuận lợi
Mẫu Bridge làm cho hệ thống trở lên linh động hơn nhờ việc tách biệt thành phần trình diễn (abstraction) và thành phần thực thi (implemetation). Nhờ đó có thể thêm các tính năng và chấp nhận được các thay đổi, mà không gây ảnh hưởng
lớn đến các thành phần khác.
Hạn chế
Mẫu Bridge là sự kết hợp giữa các thành phần Abstraction và Implemetation độc lập với nhau. Một trong những vấn đề thường gặp khi sử dụng Bridge đó là trong
quá trình thiết kế chúng ta không phân biệt rõ ràng trách nhiệm nào thuộc về Abstration và trách nhiệm nào thuộc về Implementation. Trong tương lai khi
chúng ta mở rộng hệ thống, các trách nhiệm này thay vì được đặt ở phần Abstraction ta lại thiết kế nó ở phần Implementation, dẫn tới việc không thực hiện
đúng ngữ nghĩa như ta mong đợi. Và cách cuối cùng là phải tái tổ chức lại hệ thống. Đây là công việc không dễ dàng chút nào, nó không chỉ tốn thời gian, phát
sinh chi phí mà có nguy cơ dẫn đến thay đổi dây chuyền tại những thành phần khác nữa.
3.6.2. Áp dụng mẫu Bridge thiết kế sơ đồ lớp cho ca sử dụng “Quản lý học phí”
+ Biểu đồ lớp trước khi áp dụng mẫu
Hình 3.36 Biểu đồ lớp “ Quản lý học phí”
Hình 3.37 Biểu đồ lớp có áp dụng mẫu “ Quản lý học phí”
3.6.3. Áp dụng Singleton thiết kế chức năng “Tìm kiếm sinh viên”
1. Ý nghĩa
Mẫu Singleton được thiết kế để đảm bảo một lớp chỉ có thể tạo một thể hiện duy nhất.
2. Bài toán thực tế
Trong khi triển khai chương trình chức năng “tìm kiếm sinh viên” được sử dụng rất nhiều lần và ở nhiều ca sử dụng khác nhau nhưng trong suốt quá trình thực thi
chương trình luôn phải đảm bảo chỉ có tối đa một hộp thoại tìm kiếm hiện hữu trên màn hình.
3. Giải pháp
Thiết kế cho lớp đó có thể tự kiểm soát thể hiện của nó. Cụ thể là lớp đó sẽ luôn bảo đảm không có thể hiện khác có thể được tạo từ nó. Thông thường, mọi đối tượng khi muốn được tạo mới từ class phải thông qua hàm dựng(construtor) của class đó. Vì vậy để ngăn không cho hàm dựng có thể được gọi. Sau đó sẽ cung cấp
một phương thức tĩnh để tạo mới đối tượng . Với giải pháp này, lớp sẽ đảm bảo luôn chỉ có một thể hiện duy nhất. Client truy xuất instance của lớp thông qua hàm
khởi tạo trên .
4 Biểu đồ lớp
Hình 3.38. Biểu đồ lớp “ Tìm kiếm” Các thành phần tham gia
– Định nghĩa một phương thức tĩnh để User truy xuất đến thể hiện duy
nhất của nó.
– Phương thức này tuỳ từng trường hợp mà tạo mới hay trả về Instance
tương ứng.
3.7. Mô tả chi tiết các lớp đối tƣợng
3.7.1. Sinh viên
Stt Tên trường Tiêu đề Kiểu Miền
giá trị Ràng buộc
2 Ten Tên sinh viên text <=8
3 Hodem Họ đệm text <=20
4 Quequan Quê quán text <=50
5 Ngaysinh Ngày sinh date 8
6 Noithuongtru Nơi thường trú text <=50
7 Dienchinhsach Diệnchính sách text <=50
8 SoCMT Sốchứng minh thư text 10
9 Gioitinh Giới tính Yes/no
10 Quoctich Quốc tịch text <=50
11 Tenlop Tên lớp text <=15
12 Tennganh Tên ngành text <=30
13 Tenkhoa Tên khoa text <=30
- Các thao tác
Tạo() : Tạo sinh viên mới
Sua() : Sửa thông tin sinh viên đã có trong cơ sở dữ liệu
Xem() : Xem sinh viên
laymasinhvien() : Thực hiện việc lấy mã sinh viên để phục vụ việc tìm
kiếm và tham chiếu đến các lớp khác
Laydssv(tenlop)
Timkiemsv(msv)
3.7.2. Lớp
Stt Tên trường Tiêu đề Kiểu Miền giá
trị
Ràng buộc
1 Malop Mã lớp text <=10 Khoá chính
2 Tenlop Tên lớp text <=20
3 GiaovienCN Giáoviên
chủ nhiệm
4 Si so Sĩ số number 3
5 Makhoa Mã khoa text <=10
6 Manganh Mã ngành text <=50
- Các thao tác
Tạo() : Tạo lớp mới
Sua() : Sửa thông tin lớp đã có trong cơ sở dữ liệu
Xem(): Xem sinh viên
laymalop() : Thực hiện việc lấy mã lớp giúp cho việc xếp lớp của sinh
viên và tính học phí.
3.7.3. Môn học
Stt Tên trường Tiêu đề Kiểu Miền giá trị Ràng buộc
1 Mamon Mã môn text <=10 Khoá chính
2 Tenmon Tên môn text <=20
3 DVHT số đơn vị học trình number
- Các thao tác
Tạo() : Tạo môn học mới
Sua() : Sửa thông môn học đã có trong cơ sở dữ liệu
Laymon() : Lấy tên môn
Xem() : Xem nội dung môn
3.7.4. Chuyên ngành
Stt Tên trường Tiêu đề Kiểu Miền giá trị Ràng buộc
1 Macn Mãchuyên ngành text <=10 Khoá chính
2 Tencn Tênchuyên ngành text <=20
- Các thao tác
Sua() : Sửa chuyên ngành đã có trong cơ sở dữ liệu
Laychuyennganh() : Lấy tên chuyên ngành
Xem() : Xem chuyên ngành
3.7.5. Đối tượng
Stt Tên trường Tiêu đề Kiểu Miền giá trị Ràng buộc
1 Madt Mã đối tượng text <=10 Khoá chính
2 Têndt Tên đối tượng text <=20
3 Chedomg Chế độ miễn giảm number 1
- Các thao tác
Tạo() : Tạo đối tượng mới
Sua() : Sửa đối tượng đã có trong cơ sở dữ liệu
Laydoituong() : Lấy đối tượng phục vụ cho việc tính chế độ miễn giảm học phí cho sinh viên
Xem() : Xem đối tượng
3.7.6. Học phí
Stt Tên trường Tiêu đề Kiểu Miền giá trị Ràng buộc
1 Malop Mã lớp text <=10 Khoá ngoại
2 Mahk Mã học kỳ text <=10 Khoá ngoại
3 Hphi Học phí number 9
- Các thao tác
Tạo() : Tạo đối tượng mới
Sua() : Sửa đối tượng đã có trong cơ sở dữ liệu
3.8. Thiết kế giao diện
3.8.1. Giao diện ” Cập nhật sinh viên”
GiaoG
Hình 3.39 Giao diện cập nhật sinh viên
Giao diện này cho phép cán bộ phòng đào tạo cập nhật danh sách của các sinh viên khi vào trường. Cán bộ phòng đào tạo cập nhật bằng cách nhập đầy đủ các thông tin vào các ô trống ở trên. Sau khi cán bộ phòng đào tạo nhập xong các thông tin muốn lưu vào cơ sở dữ liệu thì chọn nút “Đồng ý” còn không muốn lưu
3.8.1. Giao diện ” Cập nhật học phí”
Hình 3.40. Giao diện cập nhật học phí
Giao diện này cho phép nhân viên phòng kế toán nhập danh sách và số tiền các sinh viên đóng học phí theo kỳ. Sau khi nhân viên phòng kế toán nhập đầy đủ các
thông tin của sinh viên nộp học phì muốn lưu thông tin đó vào cơ sở dữ liệu thì chọn nút ” Đồng ý”, lúc này hệ thống kiểm tra các thông tin nhập vào nếu các
thông tin đúng thì chấp nhận lưu vào cơ sở dưc liệu, nếu không thì thông báo những dữ liệu chưa hợp lệ. Nếu nhân viên phòng kế toán ấn nút ”Thoát” thì thoát
KẾT LUẬN
Luận văn nghiên cứu về vấn đề ” Mẫu thiết kế và phân tích hướng mẫu”. Đây là một vấn đề còn rất mới mẻ, tuy nhiên trong luận văn đã trình bày chi tiết khái niệm mẫu, đồng thời giới được một số mẫu cơ bản trong 23 mẫu của nhóm tác giả Erich Gamma, Richard Helm, Ralph Johnson, Johnson Vilissides. Do thời gian có
hạn, vì vậy một số mẫu chưa được trình bày trong luận văn này. Phần ứng dụng của luận văn là tiến hành phân tích thiết kế hệ thống “ Quản lý sinh viên trường Đại Học Quản Trị Kinh Doanh Hà Nội” có áp dụng một số mẫu trong phân tích để
cài đặt. Đây là một hệ thống tương đối phức tạp vì các thông tin trong hệ thống thường xuyên biến động, đòi hỏi hệ thống cần phải xử lý. Số lượng thông tin cần
quản lý là tương đối lớn. Các phép xử lý trong hệ thống chủ yếu là theo lô, tiến hành đồng thời nhiều thao tác, mặt khác do tính chất nghiệp vụ đòi hỏi hệ thống cần phải có độ tin cậy cao, tính bảo mật tốt trong khi đó lại đảm bảo cho nhiều đối tượng khác nhau có thể truy nhập được các thông tin hệ thống. Quá trình xây dựng hệ thống “ Quản lý sinh viên trường Đại Học Quản Trị Kinh Doanh Hà Nội” phần nào đã nắm bắt được cách tiếp cận với bài toán quản lý, phương pháp phân tích, thiết kế, xây dựng bài toán dựa trên phương pháp lập trình hướng đối tượng, thông
qua đó áp dụng được các kiến thức đã được trang bị trong nhà trường vào thực tế. Đồng thời cũng nắm được các sử dụng các công cụ trợ giúp cho quá trình phân tích thiết kế xây dựng bài toán của lập trình hướng đối tượng là UML và sử dụng
một số mẫu trong phân tích.
Đề tài “Mẫu thiết kế và phân tích hướng mẫu” đã đạt được một số kết quả nhất định tuy nhiên đề tài cũng cần phát triển tiếp theo các hướng sau:
Tiếp tục nghiên cứu sâu hơn các mẫu để có khả năng vận dụng nhiều mẫu
trong hoạt động thiết kế.
Tiếp tục triển khai bài tiếp bài toán quản lý và hoàn thiện các chức năng đã