ỨNG DỤNG FRAMEWORK VÀ LẬP TRÌNH RÀNG

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Đỗ Huy Thịnh
ỨNG DỤNG FRAMEWORK VÀ LẬP TRÌNH RÀNG

BUỘC CHO BÀI TOÁN LẬP THỜI KHÓA BIỂU
KHÓA LUẬN TỐT NGHIỆP HỆ ĐẠI HỌC CHÍNH QUY
Ngành: Công nghệ thông tin
HÀ NỘI – 2006
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Đỗ Huy Thịnh
ỨNG DỤNG FRAMEWORK VÀ LẬP TRÌNH RÀNG

BUỘC CHO BÀI TOÁN LẬP THỜI KHÓA BIỂU
KHÓA LUẬN TỐT NGHIỆP HỆ ĐẠI HỌC CHÍNH QUY

Ngành: Công nghệ thông tin
Cán bộ hướng dẫn: PGS.Ts. Nguyễn Văn Vỵ
HÀ NỘI – 2006
LỜI CẢM ƠN
Lời đầu tiên em xin bày tỏ lòng biết ơn sâu sắc tới thầy giáo PGS.TS.Nguyễn
Văn Vỵ, thầy đã tận tình hướng dẫn giúp em hoàn thành khóa luận.
Em xin bày tỏ lòng biết ơn tới các thầy cô giáo trong khoa Công nghệ thông tin
- Trường Đại học Công nghệ - ĐHQGHN. Các thầy cô đã dạy bảo và luôn tạo điều
kiện tốt nhất cho chúng em học tập trong suốt quá trình học đại học đặc biệt là trong
thời gian làm khóa luận tốt nghiệp.
Tôi xin cảm ơn các bạn sinh viên lớp K47CA trường Đại học Công nghệ,
những người bạn luôn bên cạnh ủng hộ tôi trong suốt những năm học đại học.
Cuối cùng con xin gửi tới Bố Mẹ và gia đình tình thương yêu và lòng biết ơn.
Bố mẹ luôn là nguồn động viên và là chỗ dựa vững chắc cho con.
Hà Nội, ngày 20 tháng 5 năm 2006
Sinh viên
Đỗ Huy Thịnh
Đỗ Huy Thịnh Trang - ii -

TÓM TẮT NỘI DUNG
Bài toán sắp xếp thời khóa biểu từ lâu luôn thu hút được sự quan tâm của
nhiều nhà nghiên cứu và nhiều chuyên gia trong lĩnh vực liên quan. Sự nổi tiếng của
bài toán không chỉ ở độ phức tạp mà còn ở tính thực tiễn, khả năng áp dụng trong thực
tế.
Khóa luận tốt nghiệp “Ứng dụng framework và lập trình ràng buộc cho bài
toán lập thời khóa biểu” hướng tới xây dựng hệ thống nhằm giải quyết bài toán xếp
thời khóa biểu học kỳ vận dụng các công nghệ framework ( khung làm việc) và lập
trình ràng buộc đối tượng.
Khóa luận được tổ chức thành bốn phần với nội dung như sau:
♦ Chương I: Giới thiệu bài toán lập thời khóa biểu nói chung và bài toán
lập thời khóa biểu học kỳ mà khóa luận giải quyết.
♦ Chương II: Giới thiệu tổng quan và trình bày các thành phần của ngôn
ngữ ràng buộc đối tượng.
♦ Chương III: Giới thiệu tổng quan và cấu trúc khung làm việc thông qua
một số ví dụ.
♦ Chương IV: Phân tích, thiết kế và cài đặt hệ thống cho bài toán xếp thời
khóa biểu học kỳ.
Đỗ Huy Thịnh Trang - iii -

MỤC LỤC
LỜI CẢM ƠN ............................................................................................................... ii
TÓM TẮT NỘI DUNG ............................................................................................... iii
MỤC LỤC .................................................................................................................... iv
DANH MỤC BẢNG BIỂU ......................................................................................... vi
DANH MỤC HÌNH VẼ.............................................................................................. vii
MỞ ĐẦU.........................................................................................................................1
Chương 1. .......................................................................................................................2
Bài toán lập Thời khóa biểu .........................................................................................2
1.1. Giới thiệu chung bài toán lập thời khóa biểu .......................................................2
1.1.1. Bài toán xếp thời khóa biểu nhà trường ........................................................2
1.1.2. Phân loại bài toán xếp thời khóa biểu. ..........................................................2
1.1.3. Các đối tượng liên quan đến Thời khóa biểu ................................................3
1.2. Bài toán lập thời khóa biểu giải quyết trong khóa luận........................................4
1.2.1. Hoạt động nghiệp vụ .....................................................................................5
1.2.2. Bảng tổng hợp các chức năng của hệ thống “Lập thời khóa biểu học kỳ” ...6
1.2.3. Từ điển dữ liệu và mô hình lĩnh vực nghiệp vụ ............................................7
Chương 2. .......................................................................................................................9
Ngôn ngữ ràng buộc đối tượng.....................................................................................9
2.1. Giới thiệu chung ...............................................................................................9
2.2. Đặc điểm OCL....................................................................................................10
2.2.1. Cả truy vấn và ngôn ngữ ràng buộc.............................................................10
2.2.2. Ngôn ngữ dựa trên cơ sở toán học nhưng không có các ký hiệu toán học..10
2.2.3. Ngôn ngữ định nghĩa kiểu ...........................................................................11
2.2.4. Ngôn ngữ khai báo ......................................................................................11
2.3. Bài toán L&R .....................................................................................................11
2.4. Ngữ cảnh của các biểu thức OCL.......................................................................13
2.4.1. Mô hình kết hợp ..........................................................................................13
2.4.2. Các lớp và các kiểu khác .............................................................................15
2.4.3. Các thuộc tính và các đầu mút của liên kết .................................................16
2.4.4. Các phương thức..........................................................................................17
2.4.5. Các biểu thức trong các biểu đồ hành vi .....................................................18
2.4.6. Các ca sử dụng.............................................................................................18
2.4.7. Các ràng buộc và thừa kế ............................................................................18
2.5. Các thành phần OCL cơ bản...............................................................................20
2.5.1. Các biểu thức, kiểu và giá trị.......................................................................20
2.5.2. Các kiểu cơ sở và các toán tử ......................................................................21
2.5.3. Các quy tắc ưu tiên ......................................................................................24
2.5.4. Chú thích .....................................................................................................24
2.6. Các kiểu người dùng định nghĩa.........................................................................24
Đỗ Huy Thịnh Trang - iv -

2.6.1. Các thuộc tính và các phương thức .............................................................24
2.6.2. Các kết hợp và kết tập .................................................................................25
2.6.3. Các kiểu liệt kê ............................................................................................27
2.7. Kiểu tập hợp .......................................................................................................28
2.7.1. Các kiểu tập hợp ..........................................................................................28
2.7.2. Các phép toán trên các kiểu tập hợp............................................................30
2.7.3. Các phép toán lặp và duyệt..........................................................................34
2.8. Các cấu trúc nâng cao.........................................................................................35
2.8.1. Các cấu trúc cho các điều kiện sau..............................................................35
Chương 3. .....................................................................................................................37
Giới thiệu khung làm việc...........................................................................................37
3.1. Sự ra đời của khung làm việc .............................................................................37
3.1.1. Một số khái niệm hướng đối tượng .............................................................37
3.1.2. Sử dụng lại phần mềm .................................................................................39
3.2. Ví dụ khung làm việc .........................................................................................43
3.2.1. Khung làm việc cộng tác .............................................................................45
3.2.2. Làm mịn khung làm việc.............................................................................51
Chương 4. .....................................................................................................................56
Xây dựng hệ thống cho bài toán lập Thời khóa biểu ...............................................56
4.1. Mô hình ca sử dụng ............................................................................................56
4.1.1. Xác định tác nhân ........................................................................................56
4.1.2. Các ca sử dụng.............................................................................................56
4.2. Phân tích .............................................................................................................60
4.2.1. Phân tích kiến trúc .......................................................................................60
4.2.2. Phân tích ca sử dụng....................................................................................61
4.3. Thiết kế ...............................................................................................................69
4.3.1. Thiết kế lớp..................................................................................................69
4.3.2. Cấu trúc dữ liệu và thuật toán......................................................................73
4.4. Cài đặt.................................................................................................................77
4.4.1. Công cụ........................................................................................................77
4.4.2. Môi trường triển khai ..................................................................................77
4.4.3. Giao diện chính............................................................................................78
4.4.4. Kết quả.........................................................................................................86
KẾT LUẬN ..................................................................................................................89
TÀI LIỆU THAM KHẢO...........................................................................................90
Đỗ Huy Thịnh Trang - v -

DANH MỤC BẢNG BIỂU
Bảng 1. Tổng hợp các chức năng hệ thống "Lập thời khóa biểu học kỳ".......................6
Bảng 2. Từ điển dữ liệu ...................................................................................................7
Bảng 3. Các phép toán định nghĩa trên kiểu dữ liệu boolean........................................21
Bảng 4. Các toán tử chuẩn kiểu số nguyên và số thực ..................................................22
Bảng 5. Các toán tử kiểu dữ liệu xâu ký tự ...................................................................23
Bảng 6. Độ ưu tiên các toán tử ......................................................................................24
Bảng 7. Các phép toán trên kiểu tập hợp.......................................................................30
Bảng 8. Các phép toán biến đổi trên kiểu tập hợp.........................................................31
Bảng 9. Các phép toán duyệt định nghĩa trên kiểu tập hợp...........................................34
Bảng 10. Bảng luồng sự kiện ca sử dụng lập danh sách lớp học .................................57
Bảng 11. Bảng luồng sự kiện ca sử dụng lập danh sách môn học ...............................57
Bảng 12. Bảng luồng sự kiện ca sử dụng lập danh sách giáo viên giảng dạy..............58
Bảng 13. Bảng luồng sự kiện ca sử dụng xác định giáo viên dạy môn học cho lớp....59
Bảng 14. Bảng luồng sự kiện ca sử dụng lập danh sách ràng buộc .............................59
Bảng 15. Bảng luồng sự kiện ca sử dụng lập thời khóa biểu .......................................60
Bảng 16. Các thuộc tính lớp thiết kế Spciality..............................................................69
Bảng 17. Các thuộc tính lớp thiết kế Teacher ...............................................................69
Bảng 18. Các thuộc tính thêm lớp con Tie_Teacher .....................................................70
Bảng 19. Các thuộc tính lớp thiết kế Subject ................................................................70
Bảng 20. Các thuộc tính thêm lớp con Subject- Class ..................................................71
Bảng 21. Các thuộc tính lớp thiết kế Class ...................................................................71
Bảng 22. Thuộc tính thêm lớp con Tie_Class ...............................................................72
Bảng 23. Các thuộc tính lớp thiết kế Timeable .............................................................72
Bảng 24. Bảng chia môn học các ca học dựa trên số tiết học .......................................75
Bảng 25. Kết quả chương trình trên một số bộ dữ liệu .................................................87
Đỗ Huy Thịnh Trang - vi -

DANH MỤC HÌNH VẼ
Hình 1. Mô hình lĩnh vực nghiệp vụ bài toán xếp thời khóa biểu...................................8
Hình 2. Ví dụ mô hình UML không biểu diễn hết đặc tả...............................................9
Hình 3. Mô hình hệ thống chương trình Loyalty ..........................................................12
Hình 4. Định nghĩa ngữ cảnh trong mô hình UML.......................................................14
Hình 5. Cây thừa kế của ví dụ minh họa .......................................................................19
Hình 6. Ví dụ điều hướng trong kết hợp ( kết tập) ........................................................25
Hình 7. Ví dụ lớp kết hợp..............................................................................................26
Hình 8. Ví dụ kiểu liệt kê ..............................................................................................27
Hình 9. Ví dụ liên kết động và đa hình..........................................................................38
Hình 10. Sự khác nhau trong điều khiển giữa khung làm việc và thư viện lớp ............40
Hình 11. Ví dụ về áp dụng một mô hình khung làm việc .............................................44
Hình 12. Sự cộng tác giữa các đối tượng ......................................................................46
Hình 13. Khuôn mẫu cộng tác.......................................................................................48
Hình 14. Mô hình kiểu đích cho việc sử dụng sự quan sát ...........................................49
Hình 15. Ví dụ ứng dụng khung làm việc và sự thay thế..............................................49
Hình 16. Kết quả mở của ứng dụng khung làm việc.....................................................50
Hình 17. Khung làm việc cho việc thương mại: duy trì kho hàng ................................52
Hình 18. Sự cộng tác Trade Supply...............................................................................54
Hình 19. Làm tài liệu sự làm mịn khung làm việc ........................................................55
Hình 20. Mô hình ca sử dụng ........................................................................................56
Hình 21. Biểu đồ cộng tác ca sử dụng lập danh sách lớp học.......................................61
Hình 22. Biểu đồ cộng tác ca sử dụng lập danh sách môn học trong học kỳ................62
Hình 23. Biểu đồ cộng tác ca sử dụng lập Danh sách giáo viên trong học kỳ ..............63
Hình 24. Biểu đồ cộng tác ca sử dụng lập danh sách lớp- môn học .............................65
Hình 25. Biểu đồ cộng tác ca sử dụng lập danh sách lớp- môn- giáo viên ...................66
Hình 26. Biểu đồ cộng tác ca sử dụng lập danh sách các ràng buộc.............................67
Hình 27. Biểu đồ cộng tác ca sử dụng lập thời khóa biểu.............................................68
Hình 28. Biểu đồ lớp thiết kế ........................................................................................73
Hình 29. Ma trận đánh dấu trạng thái lớp .....................................................................75
Hình 30. Giao diện menu Sửa dữ liệu ...........................................................................78
Hình 31. Giao diện chỉnh sửa danh sách chuyên ngành................................................79
Hình 32. Giao diện chỉnh sửa danh sách lớp học ..........................................................79
Hình 33. Giao diện chỉnh sửa danh sách môn học. .......................................................80
Hình 34. Giao diện chỉnh sửa danh sách giáo viên .......................................................80
Hình 35. Giao diện menu Chọn dữ liệu.........................................................................81
Hình 36. Giao diện nhập học kỳ - năm học...................................................................81
Hình 37. Giao diện chọn lớp học cho học kỳ ................................................................82
Hình 38. Giao diện chọn môn học cho học kỳ ..............................................................82
Hình 39. Giao diện chọn giáo viên giảng dạy cho học kỳ.............................................83
Đỗ Huy Thịnh Trang - vii -

Hình 40. Giao diện menu Xếp TKB ...............................................................................83
Hình 41. Giao diện nhập ngày nghỉ lớp học..................................................................84
Hình 42. Giao diện nhập ngày nghỉ giáo viên...............................................................84
Hình 43. Giao diện thông báo xếp xong thời khóa biểu................................................85
Hình 44. Xác nhận hủy lập thời khóa biểu ....................................................................85
Hình 45. Giao diện menu Xem TKB ..............................................................................85
Hình 46. Giao diện xem thời khóa biểu theo lớp ..........................................................86
Hình 47. Giao diện xem thời lịch dạy giáo viên............................................................86
Hình 48. Ví dụ kết quả thời khóa biểu lớp ....................................................................87
Hình 49. Ví dụ kết quả lịch dạy giáo viên 1..................................................................88
Hình 50. Ví dụ kết quả lịch dạy giáo viên 2..................................................................88
Đỗ Huy Thịnh Trang - viii -

MỞ ĐẦU
Bài toán lập thời khóa biểu từ lâu luôn thu hút được sự quan tâm của nhiều tổ
chức giáo dục và các nhà nghiên cứu bởi tính ứng dụng cao và độ phức tạp. Các bài
toán lập thời khóa biểu rất phong phú và đa dạng bởi các ràng buộc và yêu cầu của
từng tổ chức. Bài toán đặc trưng bởi các ràng buộc và các ràng buộc có thể được thêm
vào với nhiều mức khác nhau. Rất nhiều chương trình đã được lập và đưa vào sử dụng.
Phần lớn các chương trình đó được phát triển dựa trên cơ sở một mô hình toán học
chặt chẽ và thuật toán xây dựng là dành riêng cho mô hình đó. Vì vậy khi áp dụng, nó
chỉ thích hợp với một phạm vi hẹp mà ở đó bài toán đặt ra đúng với mô hình đã xây
dựng. Ngay trong phạm vi đó, khi xuất hiện thêm một vài ràng buộc mới thì kết quả đã
không hiệu quả, thậm chí không cho lời giải.
Một vấn đề đặt ra là, cần phát triển một hệ thống thời khóa biểu có thể thích
nghi được với nhiều lớp bài toán lập thời khóa biểu khác nhau về ràng buộc với sự cải
biên sửa đổi không nhiều và tiến hành là dễ dàng nhanh chóng. Chỉ có một hệ thống
như vậy mới thực sự đáp ứng được yêu cầu thực tế cao và hiệu quả.
Khóa luận hướng đến giải quyết bài toán này dựa trên hai cơ sở sau:
♦ Tìm một thuật toán kiểu heuristic đủ đơn giản để giải bài toán. Do đó dễ cải
biên mỗi khi thêm ràng buộc.
♦ Sử dụng hai công nghệ tiên tiến là Framework và lập trình ràng buộc. Vì lớp bài
toán thời khóa biểu có phần lõi chung, nên Framework trợ giúp thiết kế xây
dựng ứng dụng cho lớp này dễ dàng thay đổi ràng buộc bổ sung. Còn lập trình
ràng buộc trợ giúp việc lâp trình có ràng buộc tiện lợi, nhanh chóng.
Đỗ Huy Thịnh Trang - 1 -

Chương 1. Bài toán lập Thời khóa biểu
Chương 1.
Bài toán lập Thời khóa biểu

1.1. Giới thiệu chung bài toán lập thời khóa biểu
1.1.1. Bài toán xếp thời khóa biểu nhà trường
Bài toán sắp xếp thời khóa biểu từ lâu luôn thu hút được sự quan tâm của nhiều
nhà nghiên cứu và nhiều chuyên gia trong lĩnh vực liên quan. Sự nổi tiếng của bài toán
không chỉ ở độ phức tạp mà còn ở tính thực tiễn, khả năng áp dụng trong thực tế. Bất
cứ một cơ sở đào tạo nào, thời khóa biểu học tập của học viên ( học sinh, sinh viên) và
giảng dạy của giáo viên giảng dạy luôn có vai trò quan trọng kết nối hầu như toàn bộ
các hoạt động.
Bài toán xếp thời khóa biểu là một trường hợp riêng của bài toán lập lịch trong
đó đưa ra một chuỗi các sự kiện (thông thường là các môn học, bài giảng, môn thi) và
bao gồm các giáo viên và học viên trong một khoảng thời gian định trước và thoả mãn
một tập hợp các ràng buộc của từng loại thời khoá biểu khác nhau. Các ràng buộc bao
gồm khả năng học tập của học viên và khả năng giảng dạy của giáo viên, số lượng và
sức chứa của phòng học, hạn định về thời gian và yêu cầu đáp ứng của các sự kiện.
1.1.2. Phân loại bài toán xếp thời khóa biểu.
a. Theo loại khuôn dạng thời gian Thời khóa biểu.

Phân loại theo mẫu biểu của thời khóa biểu được in ra. Trên thực tế có rất nhiều
loại thời khóa biểu khác nhau, rất đa dạng và tùy thuộc vào hoàn cảnh, điều kiện của
từng trường. Có thể liệt kê một số loại tiêu biểu:
♦ Thời khóa biểu TUẦN

Là mẫu dạng thời khóa biểu cho một tuần và được dùng làm chuẩn cho tất cả
các tuần của học kỳ ( năm học). Đa số các trường học của Việt Nam đều sử dụng
khuôn mẫu này.
♦ Thời khóa biểu HỌC KỲ

Là mẫu khuôn dạng thời khóa biểu được biểu diễn đến từng ngày trong suốt học
kỳ ( năm học).
♦ Thời khóa biểu 2 ( nhiều) TUẦN / HỌC KỲ

Là loại thời khóa biểu khuôn dạng tuần, tuy nhiên thời gian phân bố cho thời
khóa biểu được chia làm nhiều khoảng trong một học kỳ hay năm học. Với mô hình
này các môn học được sắp xêp không dàn đều trong một học kỳ mà thường co dãn
trong những khoảng thời gian nhỏ hơn.
♦ Thời khóa biểu THÁNG ( NĂM HỌC)

Là loại thời khóa biểu được thiết kế chi tiết từng tháng ( năm học).
b. Phân loại theo đơn vị xếp Thời khóa biểu

Phân loại theo các đối tượng trực tiếp liên quan đến dữ liệu thời khóa biểu. Các
đối tượng chính của Thời khóa biểu bao gồm:
♦ Giáo viên giảng dạy: người trực tiếp giảng dạy theo các học phần môn học
được quy định chặt chẽ về thời lượng kiến thức và hình thức học.
♦ Phòng học: địa điểm học các môn và bài giảng do giáo viên đảm nhận.
♦ Học sinh: đối tượng học tập trực tiếp của giáo viên giảng dạy. Học sinh được
phân công vào các lớp học. Do có hai kiểu lớp học khác nhau tạo nên sự khác
biệt của mô hình Thời khóa biểu:
♦ Mô hình lớp học niên chế: học sinh nhập học và phân cố định vào lớp
theo năm học. Mô hình lớp này đơn giản về mặt tổ chức, quản lý nhưng
lại phức tạp trong việc xếp Thời khóa biểu.
♦ Mô hình lớp học tín chỉ: học sinh tự do đăng ký vào các bài giảng đã
chuẩn bị trước của thời khóa biểu. Các lớp học thực chất là các bài giảng
được thiết kế thời khóa biểu giảng dạy chi tiết. Thường thì sau khi thời
khóa biểu các lớp được lên kế hoạch thì học sinh mới căn cứ vào thời
khóa biểu cụ thể để đăng ký lớp học. Việc tổ chức Thời khóa biểu theo
lớp tín chỉ sẽ đơn giản hơn cho việc xếp Thời khóa biểu nhưng lại phức
tạp cho công việc quản lý chuyên môn đào tạo nhà trường.
1.1.3. Các đối tượng liên quan đến Thời khóa biểu
Các đối tượng liên quan trực tiếp đến Thời khóa biểu bao gồm: Giáo viên giảng
dạy, Phòng học và Môn học ( học phần giảng dạy):

♦ Giáo viên: trong mô hình bài toán xếp Thời khóa biểu vai trò các giáo viên là
ngang nhau. Mỗi giáo viên về nguyên tắc thuộc một Khoa hay Bộ môn và sẽ có
một Thời khóa biểu lịch giảng dạy riêng của mình trong học kỳ hay năm học
hiện thời.
♦ Môn học: môn học hay học phần là một đơn vị quản lý chính của chương trình
đào tạo và là đối tượng chính của cả hai mô hình lớp niên chế và tín chỉ. Chính
vì vậy môn học có vai trò quan trọng trong mô hình bài toán xếp Thời khóa
biểu. Mỗi môn học thuộc khoa hay bộ môn trực tiếp phụ trách và đặc trưng bởi
số đơn vị học trình ( thời lượng học).
♦ Phòng học: phòng học cũng đóng vai trò quan trọng trong bài toán xếp thời
khóa biểu. Phòng học đặc trưng bởi loại hình thức học ( lý thuyết, thực hành)
hay sức chứa và căn cứ vào đó phân công cho các lớp.
1.2. Bài toán lập thời khóa biểu giải quyết trong khóa luận
Trong khóa luận này chỉ xét bài toán lập thời khoá biểu cho trường đại học ở
Việt Nam mà cụ thể là trường Đại học Công Nghệ - Đại học Quốc Gia Hà Nội ( có thể
tổng quát cho các trường vẫn giảng dạy theo hệ lớp- môn- giáo viên giảng dạy).
Bài toán được phát biểu như sau:
Có một danh sách các lớp học học trong học kỳ, danh sách các môn học tương
ứng cho từng lớp học và danh sách giảng viên tương ứng với mỗi môn cho từng lớp.
Giảng đường cho mỗi lớp đã được xếp trước.
Một lời giải hay một thời khoá biểu chấp nhận được là tất cả các môn học được
chia vào các tiết học trong một tuần thoả mãn các điều kiện ngặt sau:
♦ Các lớp học không có tiết trống ở giữa.
♦ Giảng viên không dạy hai lớp khác nhau ở cùng một thời điểm.
♦ Tại một thời điểm mỗi lớp học chỉ học một môn.
Thêm vào đó, một thời khoá biểu chấp nhận được sẽ được đánh giá bằng số vi
phạm các ràng buộc mềm được cho như sau:
♦ Số buổi lên lớp của giáo viên giảng dạy là ít nhất.
♦ Giáo viên giảng dạy có không quá một tiết trống ở giữa các ca dạy trong ngày.

♦ Giáo viên giảng dạy có thể không dạy vào buổi nào đó.
♦ Lớp học có một ngày nghỉ ( ngoài chủ nhật) trong tuần.
1.2.1. Hoạt động nghiệp vụ
1.2.1.1. Lên danh sách các lớp sẽ được học trong học kỳ
Vào đầu năm học, nhân viên phòng Đào Tạo phụ trách phần quản lí giảng dạy
và học tập phải ra kế hoạch lập thời khóa biểu. Trước tiên nhân viên phòng Đào Tạo sẽ
lập danh sách các lớp sẽ học trong học kỳ đó. Đồng thời gửi số lớp học về phòng Hành
Chính Tổng Hợp đề nghị chuẩn bị lớp. Phòng Hành Chính Tổng Hợp gửi lại danh
sách và qui mô phòng học cho phòng Đào Tạo.
1.2.1.2. Xác định môn học cho mỗi lớp ( lớp- môn)
Với mỗi lớp học trong danh sách ở trên, nhân viên phòng Đào Tạo đối chiếu
với chương trình đào tạo đã được áp dụng để đưa ra danh sách môn học của từng lớp.
Từ danh sách các môn học, nhân viên phòng Đào Tạo trích ra các môn học cho mỗi bộ
môn và số trình phải dạy và gửi về các bộ môn để bộ môn đăng kí hay phân công giáo
viên giảng dạy. Đồng thời gửi danh sách này cho lãnh đạo khoa để lấy ý kiến đánh giá
giúp cho việc chỉnh sửa bổ sung chương trình đào tạo được khoa học hơn.
1.2.1.3. Phân công giảng dạy ( lớp- môn- giáo viên)

Sau khi nhận danh sách các giáo viên đăng kí giảng dạy từ các bộ môn, phòng
Đào Tạo tiến hành lập danh sách giáo viên giảng dạy tương ứng với mỗi môn học của
lớp.
1.2.1.4. Lên danh sách các phòng học

Dựa vào danh sách các phòng học và qui mô của từng lớp do phòng Hành
Chính Tổng Hợp gửi lại, nhân viên phòng Đào Tạo lên danh sách các giảng đường có
thể đưa vào sử dụng.
1.2.1.5. Lập thời khóa biểu

Từ danh sách các lớp và các môn học tương ứng, danh sách các giáo viên giảng
dạy đăng kí dạy và ý kiến của lãnh đạo khoa về chương trình đào tạo đưa ra, nhân viên
phòng Đào Tạo lập ra thời khóa biểu dự kiến và gửi đi các đơn vị liên quan lấy ý kiến
phản hồi. Căn cứ vào ý kiến phản hồi, nhân viên phòng đào tạo xếp thời khóa biểu
chính thức và gửi cho các đơn vị, bộ môn và các lớp.

1.2.2. Bảng tổng hợp các chức năng của hệ thống “Lập thời khóa biểu
học kỳ”
Bảng 1. Tổng hợp các chức năng hệ thống "Lập thời khóa biểu học kỳ"
Số chức năng Chức năng

R1 Lập danh sách các lớp học sẽ học trong học kỳ
R2 Lập danh sách các môn học cho các lớp
R3 Lập danh sách các giáo viên giảng dạy
R4 Xác định giáo viên giảng dạy cho các môn học của các lớp
R5 Xác định các ràng buộc, ưu tiên
R6 Lập thời khóa biểu dự kiến, chính thức

1.2.3. Từ điển dữ liệu và mô hình lĩnh vực nghiệp vụ
1.2.3.1. Từ điển dữ liệu
Bảng 2. Từ điển dữ liệu
STT Thuật ngữ Giải thích
English Tiếng Việt
1 Class Lớp
2 Teacher Giáo viên
3 Subject Môn học

Giáo viên dạy tương ứng với
4 Teacher-subject Giao viên – môn học môn học
Chương trình đào
5 Curriculum tạo(CTĐT)
Bao gồm hệ chính qui, tại
6 Degree Hệ đào tạo chức, tập trung hay từ xa…
7 Semester Học kỳ
Lịch học cho các lớp trong
8 Timetable Thời khóa biểu trường, khoa
Các môn học tương ứng với
9 SubjectClass Môn học – lớp lớp
Training Nhân viên phòng Người phụ trách quản lí
10 bureau staff Đào Tạo giảng dạy và học tập
Phụ trách các vấn đề về
11 Training bureau Phòng Đào Tạo giảng dạy và học tập
Bureau of Phòng hành chính
12 administration tổng hợp
13 Department Bộ phận
14 Classroom Giảng đường Địa điểm học tập

Yêu cầu đặt ra khi lập thời
15 Priority Ưu tiên, ràng buộc khóa biểu

1.2.3.2. Mô hình lĩnh vực nghiệp vụ
Hình 1. Mô hình lĩnh vực nghiệp vụ bài toán xếp thời khóa biểu

Chương 2. Ngôn ngữ ràng buộc đối tượng
Chương 2.
Ngôn ngữ ràng buộc đối tượng

2.1. Giới thiệu chung
OCL ( Object Contraint Language) là ngôn ngữ xây dựng mô hình phần mềm,
được định nghĩa như một chuẩn thêm vào UML cho phân tích và thiết kế hướng đối
tượng. Các biểu thức viết trong OCL phụ thuộc vào các kiểu ( lớp, giao diện,…) được
định nghĩa trong các biểu đồ UML.
Các biểu thức viết trong OCL thêm các thông tin quan trọng cho các mô hình
hướng đối tượng. Các thông tin này thường không thể biểu diễn trong biểu đồ. Trong
UML phiên bản 1.1 các thông tin này được giới hạn bởi các ràng buộc, mỗi ràng buộc
được định nghĩa như một hạn chế về giá trị nhận được ( một hay nhiều) của một hệ
thống hay mô hình hướng đối tượng. Trong UML phiên bản 2, một mô hình có thể
chứa nhiều thông tin thêm hơn là chỉ có ràng buộc. Tất cả các công việc như: định
nghĩa truy vấn, các giá trị tham chiếu, các quy tắc nghiệp vụ hay các điều kiện trạng
thái được viết bằng các biểu thức trong một mô hình. OCL là ngôn ngữ chuẩn trong đó
các biểu thức được viết một cách rõ ràng và dễ hiểu.
Một mô hình thường có những thiếu sót do những hạn chế của các biểu đồ. Một
biểu đồ đơn giản không thể biểu diễn các phát biểu đặc tả. Ví dụ trong mô hình UML
sau:
Hình 2. Ví dụ mô hình UML không biểu diễn hết đặc tả
Trong mô hình, quan hệ giữa lớp Flight ( chuyến bay) và lớp Person ( khách
hàng), phía lớp Person có bản số là 0…* tức là số khách hàng là không giới hạn.
Trong thực tế số khách hàng bị giới hạn bởi số ghế mà máy bay có, và giới hạn này

không thể biểu diễn trong biểu đồ. Trong ví dụ này có một cách chỉ định ràng buộc về
bản số thể hiện là thêm vào biểu đồ ràng buộc OCL sau:
context Flight
inv: passengers-> size () <= plane.numberOfSeats
2.2. Đặc điểm OCL

OCL thêm các thông tin làm mô hình nhất quán, hoàn thiện và rõ ràng. Nếu chỉ
có biểu đồ trong mô hình UML, hệ thống sẽ không đảm bảo tính chính xác, đúng đắn.
OCL là ngôn ngữ quan trọng giúp xây dựng mô hình tốt hơn.
2.2.1. Cả truy vấn và ngôn ngữ ràng buộc

Trong UML phiên bản 1.1 OCL là ngôn ngữ biểu diễn các ràng buộc trên các
thành phần trong các biểu đồ của mô hình. Một ràng buộc là một hạn chế trên một hay
nhiều giá trị của một phần hay cả hệ thống mô hình hướng đối tượng. Dù các biểu đồ
trong mô hình biểu diễn các đối tượng hay các giá trị dữ liệu nhưng những giá trị đó
chỉ hợp lệ nếu điều kiện xác định bởi ràng buộc thỏa mãn.
Đến UML phiên bản 2, OCL viết không chỉ ràng buộc, mà bất kỳ biểu thức nào
trên các thành phần của biểu đồ. Mọi biểu thức OCL biểu thị một giá trị hay một đối
tượng bên trong hệ thống.
Các biểu thức OCL được dùng ở bất kỳ nơi nào trong mô hình để biểu thị một
giá trị. Một giá trị có thể là một giá trị kiểu cơ sở ( số nguyên,…) hay một tham chiếu
tới một đối tượng, một tập các giá trị, hay tập các tham chiếu tới các đối tượng. Một
biểu thức OCL có thể biểu diễn , ví dụ một giá trị logic được dùng như điều kiện trong
biểu đồ trạng thái, hay một thông điệp (message) trong biểu đồ tương tác. Một biểu
thức OCL cũng có thể dùng để chỉ một đối tượng cụ thể trong biểu đồ đối tượng hay
biểu đồ tương tác.
2.2.2. Ngôn ngữ dựa trên cơ sở toán học nhưng không có các ký hiệu
toán học
Đặc điểm nổi bật của OCL là xây dựng dựa trên cơ sở toán học. Nó dựa trên lý
thuyết tập hợp và logic vị từ. Tuy nhiên OCL lại không dùng các ký hiệu toán học.
Một ngôn ngữ mô hình cần sự chặt chẽ và chính xác của toán học nhưng lại đòi hỏi
đặc điểm dễ hiểu của ngôn ngữ tự nhiên. OCL dùng các khái niệm toán học nhưng bỏ
qua các ký hiệu khó hiểu của toán học. Thay vì dùng ký hiệu toán học để biểu diễn
cùng một khái niệm, OCL dùng các từ khóa dễ hiểu.

2.2.3. Ngôn ngữ định nghĩa kiểu

Đặc trưng quan trọng của OCL là một ngôn ngữ định nghĩa kiểu. Các biểu thức
OCL được dùng cho các mục đích mô hình hóa và đặc tả. Do hầu hết các mô hình
không được thực thi trực tiếp, các biểu thức OCL được viết trên những phiên bản
không thực thi được của hệ thống. Tuy nhiên có thể kiểm tra một biểu thức OCL mà
không cần đưa ra phiên bản thực thi được của mô hình. Như một ngôn ngữ định nghĩa
kiểu, các biểu thức OCL có thể được kiểm tra trong mô hình trước khi thực thi. Nhờ
đó mà lỗi của mô hình có thể sớm được loại bỏ.
2.2.4. Ngôn ngữ khai báo

Một đặc tính dễ phân biệt khác của OCL là ngôn ngữ khai báo. Trong các ngôn
ngữ thủ tục giống như các ngôn ngữ lập trình, các biểu thức là các mô tả về các hành
động phải thực hiện. Trong một ngôn ngữ khai báo, một biểu thức phát biểu đơn giản
điều được thực hiện nhưng không chỉ ra cách làm như thế nào. Để đảm bảo điều này,
các biểu thức OCL không có ảnh hưởng tới hệ thống, có nghĩa là việc đánh giá một
biểu thức OCL không thay đổi trạng thái của hệ thống.
2.3. Bài toán L&R

Để tiện minh họa khi giới thiệu OCL xét một ví dụ mô hình một hệ thống của
một công ty Royal & Loyal ( R& L). R & L nghiên cứu về các chương trình cho các
công ty khuyến khích khách hàng thường xuyên bằng nhiều khoản tiền thưởng ( gọi là
chương trình Loyalty).

Hình 3. Mô hình hệ thống chương trình Loyalty
Lớp trung tâm của mô hình là LoyaltyProgram. Một hệ thống mà quản lý chỉ
một chương trình Loyalty đơn chứa chỉ một thể hiện của lớp này. Trong trường hợp
R& L, nhiều thể hiện của lớp này được biểu diễn trong hệ thống. Một công ty tham dự
chương trình mà cấp cho khách hàng thẻ thành viên trong chương trình Loyalty được
gọi là ProgramPartner. Có thể có nhiều công ty đăng ký cùng chương trình. Trong

trường hợp đó các khách hàng đăng ký chương trình Loyalty có thể thu lợi từ các dịch
vụ đưa ra do bất kỳ công ty tham dự nào.
Mọi khách hàng thành viên của chương trình có thể đăng ký chương trình
Loyalty bằng cách điền vào một form và nhận được một thẻ hội viên. Các đối tượng
của lớp Customer biểu diễn cho những người đã đăng ký chương trình. Thẻ thành
viên, biểu diễn bởi lớp CustomerCard, thuộc về một người. Một thẻ có thể dùng cho
cả gia đình hay cửa hàng. Hầu hết các chương trình Loyalty cho phép các khách hàng
tích lũy điểm thưởng. Mỗi công ty tham dự chương trình quyết định khi nào và bao
nhiều điểm thưởng sẽ chuyển khi khách hàng trả giá. Những điểm thưởng tích lũy
được có thể dùng để mua các dịch vụ cụ thể từ một trong các công ty tham gia chương
trình.
Để ghi lại điểm thưởng một khách hàng có được, mọi khách hàng thành viên
được kết hợp với một tài khoản LoyaltyAccount. Có 2 loại giao dịch đối với tài khoản
này. Thứ nhất là các giao dịch trong đó khách hàng nhận được điểm thưởng. Trong mô
hình các giao dịch này được biểu diễn bằng một lớp con Earning của lớp Transaction.
Thứ hai là các giao dịch trong đó khách hàng tiêu tốn điểm thưởng. Trong mô hình các
giao dịch loại này được biểu diễn bằng lớp con Burning.
Ngoài ra, căn cứ vào các dịch vụ đã sử dụng và lượng tiền chi trả mà khách
hàng có thể được xét lên khách hàng “vàng”. Khi đó khách hàng sẽ được sử dụng ưu
đãi các dịch vụ mức độ cao hơn. Để quản lý các cấp độ dịch vụ khác nhau dùng lớp
ServiceLevel. Một ServiceLevel được chương trình Loyalty định nghĩa và mỗi khách
hàng thành viên dùng.
Mỗi khi khách hàng thành viên được tăng bậc thẻ, R& L gửi tới khách hàng thẻ
mới cùng các thông tin về dịch vụ ưu đãi đi kèm, đồng thời làm mất hiệu lực thẻ cũ.
Khách hàng có thể rút khỏi chương trình. Khi đó thẻ của khách hàng đó sẽ mất
hiệu lực, số điểm thưởng còn lại bị xóa. R& L sẽ xóa quyền thành viên nếu khách hàng
không dùng thẻ trong một thời gian nhất định.
2.4. Ngữ cảnh của các biểu thức OCL

2.4.1. Mô hình kết hợp
OCL dựa trên các kiểu ( lớp, loại dữ liệu,…) được định nghĩa trong một mô
hình UML. Do đó sử dụng OCL bao gồm việc sử dụng một số thành phần của UML.
Các biểu thức OCL có thể bao gồm một số biểu đồ UML, thông thường chỉ biểu đồ
lớp được dùng.
Một mô hình phải là một thực thể nhất quán. Trong một mô hình, quan hệ giữa
các thực thể trong hai biểu đồ phải dễ hiểu. Tương tự với quan hệ giữa các biểu thức (

trong OCL) mà không gắn với các biểu đồ hay các thực thể trong biểu đồ. Có thể biểu
diễn quan hệ này bằng hai cách. Một là các biểu thức gắn với các thực thể cụ thể chỉ
có các hàm cụ thể. Ví dụ: một biểu thức định nghĩa một thuộc tính mới gắn với một
lớp, giao diện hay kiểu dữ liệu. Hai là thực thể mô hình UML mà có một biểu thức
được gắn vào xác định rõ các thực thể khác và có thể được tham chiếu. Ví dụ: một
biểu thức gắn với một lớp, tất cả các thuộc tính, kết hợp và phép toán truy vấn của lớp
đó được dùng.
Liên kết giữa một thực thể trong mô hình UML và một biểu thức OCL được gọi
là định nghĩa ngữ cảnh của biểu thức OCL đó.
2.4.1.1. Ngữ cảnh của một biểu thức OCL

Ngữ cảnh một biểu thức OCL chỉ ra thực thể trong đó biểu thức OCL được định
nghĩa. Thông thường ngữ cảnh là một lớp, giao diện, kiểu dữ liệu hay thành phần của
biểu đồ. Hoặc đôi khi có thể là một thao tác và hiếm khi là một thể hiện. Ngữ cảnh
luôn là một thành phần cụ thể được định nghĩa trong biểu đồ UML.
Các biểu thức OCL có thể đi kèm trong trong các biểu đồ trong mô hình, cũng
có thể được viết trong các file text riêng.
Trong mô hình định nghĩa ngữ cảnh được chỉ ra bởi một đường nhiều dấu chấm
liên kết thành phần mô hình và biểu thức OCL :
Hình 4. Định nghĩa ngữ cảnh trong mô hình UML

Khi biểu thức OCL được viết trong một file text riêng, định nghĩa ngữ cảnh
được viết theo khuôn dạng: từ khóa context theo sau là tên của kiểu. VD:
context Customer
inv: name = 'Edward'
2.4.1.2. Từ khóa self

Từ khóa self được dùng trong trường hợp cần thiết để chỉ ra một cách rõ ràng
ngữ cảnh. Ví dụ :
context Customer
inv: self.name = 'Edward'
context Membership
inv: participants.cards.Membership.includes( self )
Có thể có hơn một biểu thức với mỗi ngữ cảnh và tùy theo ngữ cảnh mà biểu
thức OCL có các chức năng khác nhau.
2.4.2. Các lớp và các kiểu khác

Khi ngữ cảnh là một kiểu, ví dụ một lớp, giao diện, kiểu dữ liệu hay thành phần
( thuộc tính, thao tác truy vấn, trạng thái, kết hợp) các biểu thức thuộc một trong các
dạng:
2.4.2.1. Các bất biến

Bất biến là một ràng buộc luôn đúng cho một đối tượng trong toàn bộ thời gian
tồn tại của đối tượng đó. Các bất biến thường biểu diễn các quy tắc gán cho các đối
tượng thực sau khi các đối tượng phần mềm được mô hình hóa. Một bất biến được gắn
với một mô hình có nghĩa là khi bất biến bị phá vỡ thì mô hình sẽ lỗi.
Để chỉ một biểu thức là một bất biến, sau khai báo ngữ cảnh là từ khóa inv, tên
tùy chọn, dấu : và biểu thức. Ví dụ :
context Customer
inv myInvariant23: self.name = 'Edward'
Trong ví dụ trên bất biến được đặt tên là myInvariant23, chỉ ra ràng buộc tất cả
thể hiện của lớp Customer có tên là Edward.
2.4.2.2. Định nghĩa các thuộc tính hay phương thức

Các thuộc tính hay phương thức có thể được định nghĩa bằng một biểu thức
OCL. Định nghĩa một thuộc tính hay phương thức có nghĩa là mọi thể hiện của ngữ
cảnh nhận thuộc tính hay phương thức được định nghĩa.

Để chỉ ra biểu thức là định nghĩa, sau khai báo ngữ cảnh là từ khóa def , dấu hai
chấm: và biểu thức. Ví dụ :
context Customer
def: initial : String = name.substring(1,1)
context CustomerCard
def: getTotalPoints( d: Date ) : Integer =
transactions->select( date.isAfter(d) ).points->sum()
Trong trường hợp định nghĩa thuộc tính, tên và loại của thuộc tính phải được
chỉ ra, theo sau là dấu = và giá trị gán cho thuộc tính.
Tất cả các phương thức định nghĩa trong OCL là các thao tác truy vấn. Tên, các
tham số ( gồm cả kiểu dữ liệu) và giá trị trả lại phải được đưa ra.
2.4.3. Các thuộc tính và các đầu mút của liên kết
2.4.3.1. Các quy tắc dẫn xuất

Một biểu thức có ngữ cảnh là một thuộc tính hay một quy tắc kết hợp có thể
được dùng như một quy tắc dẫn xuất. Một quy tắc dẫn xuất chỉ ra giá trị của một thành
phần của ngữ cảnh phải luôn bằng một giá trị được đưa ra bởi quy tắc.
Để chỉ ra biểu thức là một quy tắc dẫn xuất, khai báo ngữ cảnh bao gồm tên của
thuộc tính hay đầu kết hợp, từ khóa derive, dấu hai chấm : như ví dụ sau. Mức dịch vụ
trên thẻ của khách hàng luôn bằng cấp độ hiện tại của khách hàng đó :
context CustomerCard::myLevel : ServiceLevel
derive: Membership.currentLevel
2.4.3.2. Giá trị khởi tạo

Giá trị khởi tạo của một thuộc tính hay quy tắc kết hợp có thể đưa ra bởi một
biểu thức OCL. Một giá trị khởi tạo là giá trị mà thuộc tính hay quy tắc kết hợp nhận
được ngay khi thể hiện của ngữ cảnh được tạo ra. Sau khai báo ngữ cảnh dùng từ khóa
init, tên thuộc tính và biểu thức đưa ra giá trị khởi tạo. Ví dụ:
context CustomerCard::transactions : Set( Transaction )
init: Set{}
context CustomerCard::valid : Boolean

init: true
Chú ý rằng, có sự khác nhau giữa quy tắc dẫn xuất và giá trị khởi tạo. Quy tắc
dẫn xuất phát biểu một bất biến: thành phần dẫn xuất luôn nhận giá trị mà quy tắc đưa

ra. Một giá trị khởi tạo chỉ nhận ngay tại thời điểm tạo thể hiện ngữ cảnh. Sau đó,
thuộc tính có thể nhận giá trị khác tại các thời điểm khác.
2.4.4. Các phương thức
2.4.4.1. Các điều kiện trước và điều kiện sau

Có hai cách trong đó các biểu thức được dùng cho các phương thức là các điều
kiện trước và sau ( 2 dạng của các ràng buộc). Một điều kiện trước là một biểu thức
logic phải đúng tại thời điểm khi phương thức bắt đầu thực thi. Một điều kiện sau là
một biểu thức logic phải đúng tại thời điểm phương thức kết thúc thực thi. Một điều
kiện trước chỉ rõ biểu thức phải nhận đúng, nếu không thao tác sẽ không được thực
hiện. Ý nghĩa của điều kiện sau là chỉ biểu thức phải đúng, nếu không thao tác đã thực
hiện không chính xác.
Ngữ cảnh được định nghĩa bởi từ khóa context, tiếp đến là tên của kiểu chứa
thao tác, dấu hai chấm :, toàn bộ phép toán ( gồm tên, tất cả tham số và kiểu tham số,
giá trị trả về). Thường thì toàn bộ phép toán được định nghĩa trong biểu đồ lớp UML.
Tiếp sau định nghĩa ngữ cảnh là các dòng- gán nhãn với từ khóa pre và post-
bao gồm các điều kiện trước và sau. Cú pháp chung:
context Type1::operation(arg : Type2) : ReturnType
pre :
………
post:
………
Chú ý rằng, đối lập với các bất biến luôn đúng thì các điều kiện trước và sau chỉ
cần đúng tại thời điểm nhất định, lần lượt là trước và sau khi thực hiện các phương
thức.
2.4.4.2. Phần thân của các phép toán truy vấn

Các phép toán truy vấn có thể được định nghĩa đầy đủ bằng cách chỉ ra kết quả
của phép toán trong một biểu thức đơn. Sau khi định nghĩa các phép toán truy vấn
chưa có hiệu lực cho đến khi các phép toán được thực hiện.
Ngữ cảnh khai báo tương tự đối với trường hợp điều kiện trước và sau. Thay vì
dùng từ khóa pre hay post, từ khóa body được dùng, tiếp là đến biểu thức. Ví dụ :
context CustomerCard::getTransactions(from : Date, until: Date )
: Set(Transaction)
body: transactions->select( date.isAfter( from ) and
date.isBefore( until ) )

2.4.5. Các biểu thức trong các biểu đồ hành vi
2.4.5.1. Các thể hiện

Một biểu đồ tương tác chỉ ra chu kỳ sống của các thể hiện. Trong một biểu đồ
hoạt động, số các hoạt động có thể được thực hiện bởi một thể hiện cụ thể. Các biểu
thức OCL có thể được dùng để mô tả các thể hiện và quan hệ của chúng. Ngữ cảnh của
các biểu thức đó chính là biểu đồ thực hiện các biểu thức.
2.4.5.2. Các điều kiện

Một thông điệp trong một biểu đồ tuần tự hay cộng tác có thể có một điều kiện
đính kèm để quyết định việc thông điệp được gửi đi. Điều kiện này có thể viết như một
biểu thức OCL. Trong trường hợp này, biểu thức OCL được gắn với một thể hiện,
không gắn với một kiểu.
Các điều kiện cũng có thể là một phần của các biểu đồ hoạt động. Khi đó ngữ
cảnh là các điểm quyết định.
2.4.5.3. Các giá trị tham số thực

Các thông điệp trong các biểu đồ cộng tác và tuần tự có thể có các tham số. Do
một thông điệp mô tả một phương thức có các tham số là các giá trị thực. Có thể chỉ ra
giá trị thực của tham số bằng một biểu thức OCL. Ngữ cảnh của biểu thức khi đó là
thông điệp. Một thông điệp tới một đối tượng trong một biểu đồ tương tác tương ứng
với một phương thức trong kiểu của đối tượng đích.
Các hành động trong biểu đồ trạng thái và biểu đồ hoạt động cũng có thể có các
tham số giá trị thực.
2.4.6. Các ca sử dụng

Trong các ca sử dụng UML, các điều kiện trước và sau có thể được dùng, được
viết bằng OCL. Do các ca sử dụng là một cách không hình thức phát biểu các yêu cầu
và OCL là ngôn ngữ hình thức nên cần một số điều chỉnh khi các điều kiện trước và
sau của ca sử dụng được định nghĩa bằng các biểu thức OCL.
2.4.7. Các ràng buộc và thừa kế

Trong UML chuẩn không có quy tắc nào thực sự minh họa một biểu thức của
một lớp cha được thừa kế bởi các lớp con của nó. Để dùng các biểu thức thể hiện được
vai trò của thừa kế cần đưa ra các ngữ nghĩa thích hợp cho chúng. Các ngữ nghĩa được
chấp nhận một cách rộng rãi nhất của thừa kế để đảm bảo bất kỳ thể hiện nào của một
lớp con phải ứng xử giống như bất kỳ thể hiện nào của lớp cha của nó. Nguyên tắc này

(có tên gọi Liskov's Substitution) được phát biểu: bất cứ một thể hiện của một lớp được
tạo ra, nó luôn có thể thay thế một thể hiện của bất kỳ lớp con của nó. Các biểu thức
OCL tuân theo nguyên tắc này.
2.4.7.1. Hệ quả cho các bất biến

Các bất biến trong các lớp cha phải luôn áp dụng cho các lớp con. Các lớp con
có thể làm chặt bất biến hơn. Quy tắc tổng quát cho các bất biến được phát biểu: Một
bất biến cho một lớp cha được bởi các lớp con của nó thừa kế. Một lớp con có thể làm
chặt bất biến hơn nhưng không được làm bất biến yếu đi.
Hình 5. Cây thừa kế của ví dụ minh họa
Trong mô hình trên có thể định nghĩa lớp cha Stove một bất biến : nhiệt độ của
nó không được lớn hơn 200 độ C
context Stove
inv: temperature <= 200
Sẽ rất nguy hiểm nếu một lớp con ElectricStove có thể vượt giới hạn nhiệt độ
đó. Ví dụ , giả sử ElectricStove có thể có nhiệt độ không vượt quá 300 độ C:
context ElectricStove
inv: temperature <= 300
Khi đó việc dùng ElectricStove sẽ không đảm bảo an toàn ở nơi nào mà Stove
được dùng. Nếu tại một nơi mà nhiệt độ an toàn báo động hoản hoạn là 250 độ C, có
thể đặt một Stove ở đó. Nhưng nếu đặt một Stove tại đó và Stove trở thành
ElectricStove, nơi đó có thể bị đặt báo động có hỏa hoạn.
Trong một số trường hợp, nguyên tắc Liskov’s Substitution cũng có những hạn
chế. Các lớp con có thể thay đối các phương thức lớp cha và thêm vào các phương
thức hay thuộc tính, khi đó các bất biến của lớp cha có thể được thay đổi để phù hợp

với sự biến đổi đó. Việc một bất biến trên một lớp cha có cần phải thay đối hay không
khi một lớp con được thêm vào phụ thuộc vào nội dung của bất biến.
2.4.7.2. Các hệ quả cho các điều kiện trước và sau

Khi một phương thức được định nghĩa lại trong một lớp con, một điều kiện
trước có thể bị làm yếu đi nhưng không được làm chặt hơn. Ngược lại, một điều kiện
sau có thể chặt hơn, không được yếu đi. Ví dụ: định nghĩa phương thức open() cho lớp
Stove:
context Stove::open()
pre : status = StoveState::off
post: status = StoveState::off and isOpen
Biểu thức trên có nghĩa là có thể mở một Stove khi trạng thái của nó là off. Sau
khi đã mở, trạng thái mong muốn là off và biến isOpen có giá trị true. Giả sử lớp con
ElectricStove định nghĩa lại phương thức open() với các điều kiện trước và sau khác:
context ElectricStove::open()
pre : status = StoveState::off and temperature <= 100
post: isOpen
Điều kiện trước của phương thức open() định nghĩa lại có một điều kiện mở
rộng ( temperature<= 100). Khi đó ElectricStove sẽ không thể mở dưới các điều kiện
mà Stove có thể mở. Để đảm bảo một ElectricStove có thể thay thế một Stove tiền điều
kiện khi định nghĩa lại open() không được chặt hơn.
Điều kiện sau của open() khi định nghĩa lại bị yếu đi vì điều kiện status=
StoveState::off bị loại bỏ. Kết quả là ElectricStove không thực hiện như một Stove (
sau khi mở Stove ở trạng thái off).
2.5. Các thành phần OCL cơ bản

Các thành phần cơ bản được dùng để viết các ràng buộc và không tham chiếu
tới các thành phần trong mô hình UML.
2.5.1. Các biểu thức, kiểu và giá trị

Trong OCL, mỗi giá trị, là một đối tượng, một thể hiện thành phần hay một giá
trị dữ liệu có một kiểu nhất định, định nghĩa các phương thức có thể áp dụng cho đối
tượng. Các kiểu trong OCL được chia làm các nhóm:
2.5.1.1. Các kiểu định nghĩa trước

Được định nghĩa trong thư viện chuẩn bao gồm :

♦ Các kiểu cơ bản: gồm các kiểu dữ liệu số nguyên, số thực, xâu ký tự và logic (
tương tự các ngôn ngữ lập trình.)
♦ Các kiểu tập hợp.
2.5.1.2. Các kiểu do người dùng định nghĩa

OCL phân biệt giữa kiểu đối tượng và kiểu giá trị. Kiểu giá trị định nghĩa các
thể hiện không bao giờ thay đổi. VD số nguyên 1 có giá trị không đổi. Ngược lại kiểu
đối tượng định nghĩa các thể hiện có thể thay đối giá trị. VD một thể hiện của lớp
Person có thể thay đổi giá trị thuộc tính name. Kiểu định nghĩa trước là kiểu giá trị còn
kiểu người dùng định nghĩa là kiểu đối tượng. Các kiểu dữ liệu của UML, gồm các
kiểu liệt kế cũng là kiểu giá trị. Các giao diện, thành phần, lớp của UML là kiểu đối
tượng.
2.5.2. Các kiểu cơ sở và các toán tử
2.5.2.1. Kiểu boolean

Biến kiểu logic nhận một trong hai giá trị: true hay false. Các phép toán định
nghĩa trên kiểu dữ liệu:
Bảng 3. Các phép toán định nghĩa trên kiểu dữ liệu boolean
Toán tử Ký hiệu Kết quả trả về
hoặc a or b boolean
và a and b boolean
loại trừ a xor b boolean
phủ định not a boolean
bằng a=b boolean
khác a <> b boolean
bao hàm a implies b boolean
Các toán tử trong OCL đều phổ biến trong các ngôn ngữ lập trình trừ toán tử
implies. Phép toán này trả lại kết quả true nếu toán hạng thứ nhất có giá trị true và
toán hạng thứ hai cũng có giá trị true hoặc toán hạng thứ nhất có giá trị false.

Xét một VD của lớp Service từ ví dụ R & L ở trên. Kết quả của biểu thức sau có
giá trị true nếu một dịch vụ cung cấp điểm thưởng thì khách hàng không thể dùng
điểm thưởng để trả cho dịch vụ đó:
context Service
inv: self.pointsEarned > 0 implies not (self.pointsBurned = 0)
Một toán tử khác của kiểu boolean là if-then-else, có dạng:
if < biểu thức logic OCL>

then < biểu thức OCL>
else < biểu thức OCL>
endif
2.5.2.2. Kiểu số nguyên và số thực

Kiểu số nguyên và số thực trong OCL cũng giống như trong các ngôn ngữ lập
trình. Các toán tử chuẩn :
Bảng 4. Các toán tử chuẩn kiểu số nguyên và số thực

Toán tử Ký hiệu Kiểu kết quả
bằng a=b Boolean
khác a <> b Boolean
nhỏ hơn a<b boolean
lớn hơn a>b boolean
nhỏ hơn hoặc bằng a <= b boolean
lớn hơn hoặc bằng a >= b Boolean
cộng a+b số nguyên hay số thực
trừ a–b số nguyên hay số thực
nhân a*b số nguyên hay số thực
chia a/b số nguyên hay số thực
chia lấy dư a.mod(b) số nguyên
chia lấy phần nguyên a.div(b) số nguyên
trị tuyệt đối a.abs() số nguyên hay số thực

giá trị lớn nhất a và b a.max(b) số nguyên hay số thực

giá trị nhỏ nhất a và b a.min(b) số nguyên hay số thực
làm tròn a.round() số nguyên
lấy phần nguyên a.floor() số nguyên
VD :
2654 * 4.3 + 101 = 11513.2
(3.2).floor() / 3 = 1
1.175 * (-8.9).abs() - 10 = 0.4575
12 > 22.7 = false
12.max(33) = 33
33.max(12) = 33
13.mod(2) = 1
13.div(2) = 6
33.7.min(12) = 12.0
-24.abs() = 24
(-2.4).floor() = -3
2.5.2.3. Kiểu dữ liệu xâu ký tự

Cũng giống như các ngôn ngữ lập trình, kiểu dữ liệu xâu ký tự được viết trong
cặp dấu nháy ‘’. Các toán tử gồm có: toUpper, toLower, size, substring, concat:
Bảng 5. Các toán tử kiểu dữ liệu xâu ký tự
Toán tử Biểu thức Kiểu kết quả

nối xấu string.concat(string) xâu
lấy độ dài string.size() số nguyên
Chuyển về chữ thường string.toLower() xâu
Chuyển lên chữ hoa string.toUpper() xâu
lấy xâu con string.substring(int,int) xâu
bằng string1 = string2 boolean
Khác string1 <> string2 boolean
VD:
'Anneke'.size() = 6
('Anneke' = 'Jos') = false
'Anneke '.concat('and Jos') = 'Anneke and Jos'
'Anneke'.toUpper() = 'ANNEKE'
'Anneke'.toLower() = 'anneke'
'Anneke and Jos'.substring(12, 14) = 'Jos'

2.5.3. Các quy tắc ưu tiên

Trong trường hợp nhiều toán tử đi với nhau cần có quy tắc qui định độ ưu tiên
của các toán tử. Bảng các toán tử sau từ trên xuống dưới sắp theo thứ tự giảm dần độ
ưu tiên toán tử. Để an toàn, có thể dùng cặp dấu ngoặc () để chỉ định độ ưu tiên một
cách rõ ràng:
Bảng 6. Độ ưu tiên các toán tử

::
@pre
., ->, ^
-, not
*, /
<, >, <=, >=,
<>, =
and, or, xor
implies
2.5.4. Chú thích

Các biểu thức OCL có thể chứa chú thích. Một dòng chú thích OCL bắt đầu với
hai dấu nối --. Chú thích dài hơn một dòng có thể viết trong cặp /* và */. Ví dụ:
-- biểu thức 20 * 5 + 4 được tính ở đây
20 * 5 + 4 – đây là một chú thích
/* this is a very long comment that does not enlighten the reader
one bit about what the expression is really about */
2.6. Các kiểu người dùng định nghĩa

2.6.1. Các thuộc tính và các phương thức
Các biểu thức OCL có thể chứa các thuộc tính và phương thức của lớp. Cú pháp
tham chiếu đến một phương thức hay thuộc tính của một lớp là tên lớp, dấu :: và tên
thuộc tính hay phương thức ( có thể có tham số đi kèm). Ví dụ, trong ví dụ R & L trên
thuộc tính nowOfDate là một thuộc tính của lớp:
inv: goodThru.isAfter( Date::now )

Trường hợp các phương thức hay thuộc tính không thuộc lớp trong biểu thức
OCL trước tên phương thức hay thuộc tính là dấu chấm ( .). Tuy nhiên có một hạn chế
trong OCL: các phương thức có thể trả lại giá trị nhưng không được thay đổi trạng thái
của bất kỳ đối tượng nào ( hay còn gọi là phương thức truy vấn). Theo các đặc tả
UML, mỗi phép toán có nhãn logic isQuery. Nếu nhãn có giá trị true, phép toán không
có tác dụng thay đổi đối tượng và có thể dùng trong các biểu thức OCL.
2.6.2. Các kết hợp và kết tập

Một đặc điểm khác của kiểu người dùng định nghĩa là có thể dùng bên trong
OCL dẫn xuất từ các kết hợp ( hoặc kết tập) trong mô hình lớp. Các kết hợp có một số
đầu mút, mỗi đầu có một bản số, có thể có tên ( tên vai trò) gắn với lớp tham gia kết
hợp ( kết tập).
Các đầu mút kết hợp ( kết tập) có thể được dùng để điều hướng từ một đối
tượng trong hệ thống đến một đối tượng khác. Nếu tên của đầu kết hợp ( kết tập) thiếu,
có thể dùng tên của kiểu kết nối thay thế. Nếu dùng tên kiểu mà nhập nhằng thì bắt
buộc phải có mô tả của tên vai trò.
Xét trong ví dụ R & L:
Hình 6. Ví dụ điều hướng trong kết hợp ( kết tập)
Lớp Customer có hai điều hướng programs và cards. Lớp CustomerCard có

một điều hướng tên owner, lớp LoyaltyProgram có một điều hướng tên customer.
Các điều hướng trong OCL được coi như các thuộc tính. Dấu chấm (.) dùng để
tham chiếu tới các thuộc tính cũng được dùng để tham chiếu tới các điều hướng. Trong
một kiểu, tất cả tên ( của thuộc tính hay điều hướng) đều phải duy nhất, tránh sự nhập
nhằng giữa tên các thuộc tính và điều hướng.
Kiểu của một điều hướng có thể là kiểu người dùng định nghĩa hoặc là một tập
các kiểu người dùng định nghĩa. Nếu bản số ở đầu kết hợp là 1, kiểu kết quả là kiểu
người dùng định nghĩa nối với đầu kết hợp. Nếu bản số lớn hơn 1, kết quả có kiểu là
một tập hợp. Các thành phần trong tập hợp phải tuân theo kiểu người dùng định nghĩa

nối với đầu kết hợp. Trong ví dụ trên kiểu kết quả của điều hướng owner từ
CustomerCard là một kiểu người dùng định nghĩa Customer. Kiểu kết quả của cả
programs và cards từ Customer là các tập hợp.
Trong ví dụ hình trên có thể định nghĩa một bất biến dùng điều hướng owner từ
ngữ cảnh CustomerCard. Vì biểu thức OCL này cho kết quả một giá trị của kiểu
Customer, tất cả các thuộc tính và phương thức trong Customer có thể xuất hiện trong
biểu thức:
inv: self.owner.dateOfBirth.isBefore( Date::now )
inv: self.owner.programs->size() > 0
2.6.2.1. Các lớp kết hợp

Một biểu đồ lớp UML cho phép định nghĩa các lớp kết hợp- các lớp gắn với
một kết hợp. Từ một lớp kết hợp, luôn có thể điều hướng các thể hiện của các lớp tại
các đầu mút của kết hợp, dùng các quy tắc giống như đặt tên cho các điều hướng thông
thường. Chú ý rằng do bản chất của một lớp kết hợp, một điều hướng khi đó luôn cho
kết quả một giá trị đơn, không khi nào là một tập hợp của bất kỳ kiểu nào.
Hình 7. Ví dụ lớp kết hợp
Trong hình MemberShip là một lớp kết hợp. Lớp này có ba điều hướng:
programs của kiểu LoyaltyProgram, participants của kiểu Customer, và currentLevel
của kiểu ServiceLevel. Bất biến sau phát biểu một mức dịch vụ thực sự của một thành
viên phải luôn là một mức dịch vụ của chương trình Loyalty chứa thành viên đó:

context Membership
inv: programs.levels->includes( currentLevel )
Cũng có thể điều hướng từ lớp kết hợp Customer và LoyaltyProgram tới
Membership. Do lớp kết hợp không có tên vai trò, tên của điều hướng là tên của lớp
kết hợp.
Bản số tại các đầu mút kết hợp sẽ quyết định kiểu của biểu thức. Nếu một ngữ
cảnh nào đó bản số lớn hơn 1, điều hướng tới lớp kết hợp sẽ cho kết quả một tập hợp
các thể hiện lớp kết hợp. Ngược lại, điều hướng sẽ cho kết quả một thể hiện lớp kết
hợp. Ví dụ, điều hướng từ Customer tới MemberShip sẽ cho kết quả là giá trị kiểu tập
hợp Set(LoyaltyProgram).
Bất biến sau cũng phát biểu tương tự bất biến ở trên, nhưng là từ ngữ cảnh của
LoyaltyProgram: tập các mức dịch vụ phải chứa tất cả các mức của tất cả các thành
viên. Chú ý rằng từ ngữ cảnh LoyaltyProgram, Membership.currentLevel là một kiểu
Bag(ServiceLevel). Do đó dùng phép toán includesAll thay cho includes:
context LoyaltyProgram
inv: levels->includesAll( Membership.currentLevel )
2.6.3. Các kiểu liệt kê

Một kiểu liệt kê là một kiểu người dùng định nghĩa đặc biệt thường được dùng
như một kiểu cho các thuộc tính. Nó được định nghĩa bên trong biểu đồ lớp UML,
dùng kiểu nguyên mẫu liệt kê, như trong hình sau:
Hình 8. Ví dụ kiểu liệt kê
Các giá trị được định nghĩa trong <<enumeration>> có thể được dùng như các
giá trị trong một biểu thức OCL.
Ở VD trên lớp Customer thuộc tính isMale được thay đối thành gender. Bất
biến sau phát biểu các khách hàng nam tên phải bắt đầu bằng ‘Mr.’ :
context Customer
inv: gender = Gender::male implies title = 'Mr.'
Chỉ có hai toán tử dùng cho các giá trị liệt kê là toán tử = và <>.

2.7. Kiểu tập hợp

2.7.1. Các kiểu tập hợp
Các hệ thống hướng đối tượng thường thao tác trên các tập đối tượng. Vì bản số
các kết hợp hiếm khi là 1-1, hầu hết các kết hợp định nghĩa một quan hệ giữa một đối
tượng và một tập các đối tượng khác. Để thao tác với các tập đó, OCL định nghĩa
trước một số các kiểu tương ứng với các tập hợp.
Trong OCL, có 5 kiểu tập hợp. Có 4 kiểu cụ thể: Set, OrderedSet, Bag,
Sequence Kiểu còn lại là kiểu trìu tượng- Collection, là kiểu cha của bốn kiểu kia dùng
để định nghĩa các toán tử phổ biến cho tất cả các kiểu tập hợp.
♦ Set: một tập các thể hiện của một kiểu của OCL. Các phần tử trong Set không
có sự lặp lại và không có tính thứ tự.
♦ OrderedSet: một tập các phần tử có tính thứ tự.
♦ Bag: tập các phần tử không có thứ tự và cho phép lặp lại.
♦ Sequence: tập các phần tử có thứ tự và cho phép lặp lại.
Chú ý rằng thứ tự ở đây là thứ tự mà các phần tử được lưu chứ không phải thứ
tự về giá trị.
Các tập hợp được ghi trong cặp dấu ngoặc móc () hay ngoặc nhọn {} với tên
kiểu đứng trước. Trong mô hình R & L các điều hướng trong ngữ cảnh
LoyaltyProgram cho kết quả một tập hợp:
self.participants -- Set(Customer)
self.levels -- OrderedSet(ServiceLevel)
2.7.1.1. Các hằng tập hợp

Các phần tử của tập hợp được liệt kê cách nhau bởi dấu phẩy trong cặp dấu
ngoặc nhọn {}:
Set { 1 , 2 , 5 , 88 }
Set { 'apple' , 'orange', 'strawberry' }
OrderedSet { 'apple' , 'orange', 'strawberry', 'pear' }
Sequence { 1, 3, 45, 2, 3 }
Sequence { 'ape', 'nut' }
Bag {1 , 3 , 4, 3, 5 }
Nếu có dãy số nguyên liên tiếp nhau, có thể biểu diễn theo dạng miền con
m…n. Ví dụ dãy [2…6] tương đương với {2, 3, 4, 5, 6}

2.7.1.2. Các biểu thức kiểu tập hợp

Khi một kiểu của một phần tử là một tập hợp, biểu diễn bằng cách dùng các từ
Set, OrderedSet, Bag, Sequence và kiểu của các phần tử của tập hợp giữa cặp dấu
ngoặc (). Ví dụ:
Set(Customer)
Sequence(Set(ProgramPartners))
OrderedSet(ServiceLevel)
Bag(Burning)
2.7.1.3. Các toán tử tập hợp

Tất cả các toán tử trên các tập hợp biểu diễn trong các biểu thức OCL dùng mũi
tên, phép toán sau mũi tên được áp dụng cho tập hợp trước mũi tên. Cách biểu diễn
này cho phép người dùng định nghĩa các phép toán trong mô hình có cùng tên như các
phép toán chuẩn. Phép toán người dùng định nghĩa được viết sau dấu chấm (.),còn
phép toán chuẩn viết sau mũi tên ->.
Tất cả các kiểu tập hợp được định nghĩa là các kiểu giá trị, do đó giá trị của một
thể hiện không thể thay đổi. Các phép toán tập hợp không thay đổi một tập hợp, nhưng
có thể cho kết quả là một tập hợp mới.
Bất biến sau từ mô hình R & L, dùng phép toán chuẩn size(), phát biểu rằng số
người tham dự vào chương trình Loyalty phải nhỏ hơn hoặc bằng 10.000:
context LoyaltyProgram
inv: self.participants->size() < 10000
2.7.1.4. Các thể hiện được đối xử như là các tập hợp
Do cú pháp của các phép toán tập hợp khác với các phép toán kiểu người dùng
định nghĩa nên có thể dùng một thể hiện đơn như một tập hợp. Tập hợp này được xem
như một tập thể hiện chỉ có một phần tử. Ví dụ , trong mô hình R & L, các ràng buộc
sau cho kết quả là giá trị của phép toán người dùng định nghĩa isEmpty() và một thể
hiện của LoyaltyAccount:
context Membership
inv: account.isEmpty()
Ngược lại, ràng buộc sau cho kết quả giá trị của phép toán isEmpty của tập Set,
trong đó account được dùng như một tập hợp:
context Membership
inv: account->isEmpty()

Biểu thức có giá trị true nếu liên kết từ thể hiện của MemberShip tới một thể
hiện của LoyaltyAccount rỗng, có nghĩa là MemberShip không gắn với
LoyaltyAccount.
2.7.1.5. Tập hợp các tập hợp

Các tập hợp trong OCL là phẳng, nghĩa là nếu đặt một tập hợp vào bên trong
một tập hợp khác, các phần tử sẽ được đưa ra ngoài để thành một tập hợp kết quả. Ví
dụ, {set{1,2}, set{3,4}} trở thành set{1,2,3,4}.
2.7.2. Các phép toán trên các kiểu tập hợp

Các phép toán thường gặp trên các kiểu tập hợp được liệt kê trong bảng sau.
Các phép toán đó được định nghĩa bởi kiểu cha trìu tượng Collection:
Bảng 7. Các phép toán trên kiểu tập hợp
Phép toán Mô tả
count( đối tượng ) Trả lại số các sự kiện của đối tượng trong tập hợp
excludes( đối tượng) Có giá trị true nếu đối tượng không là một phần tử của
tập hợp
excludesAll( tập hợp) Có giá trị true nếu tất cả phần tử của tập hợp ( tham
số) không ở trong tập hợp hiện tại
includes( đối tượng ) Có giá trị true nếu đối tượng là một phần từ của tập
hợp
includeAll( tập hợp ) Có giá trị true nếu tất cả các phần tử của tập hợp (
tham số) có trong tập hợp hiện tại
isEmpty() Có giá trị true nếu tập hợp không chứa phần tử nào
notEmpty() Có giá trị true nếu tập hợp chứa ít nhất một phần tử
size() Trả lại số các phần tử trong tập hợp
sum() Cộng tổng tất cả các phần tử trong tập hợp. Các thành
phần phải là một kiểu hỗ trợ phép cộng ( như số nguyên
hay số thực)
Các ví dụ sau dùng các phép toán includes và includesAll. Bất biến phát biểu
mức dịch vụ của mỗi thành viên phải là một trong các mức của chương trình mà thành
viên đó tham dự:

context Membership
inv: programs.levels ->includes(currentLevel)
Bất biến sau ràng buộc các dịch vụ có sẵn cho một mức dịch vụ được cung cấp
bởi một đối tác của chương trình Loyalty:
context ServiceLevel
inv: program.partners
->includesAll(self.availableServices.partner)
2.7.2.1. Các phép toán biến đổi

Một số phép toán định nghĩa trên tất cả các kiểu tập hợp nhưng có một số chỉ áp
dụng cho một hay một số kiểu. Bảng sau chỉ ra khái quát về các phép toán biến đổi
trên bốn kiểu tập hợp. Dấu X có nghĩa là phép toán đó được định nghĩa cho kiểu tương
ứng, dấu nối – chỉ ra phép toán không được định nghĩa cho kiểu đó:
Bảng 8. Các phép toán biến đổi trên kiểu tập hợp
Phép toán Set OrderedSet Bag Sequence

= X X X X
<> X X X X
- X X - -
append( đối tượng ) - X - X
asBag() X X X X
asOrderedSet() X X X X
asSequence() X X X X
asSet() X X X X
at( chỉ số) - X - X
excluding( đối tượng ) X X X X
first() - X - X
flatten() X X X X
including( đối tượng) X X X X
indexOf( đối tượng ) - X - X
insertAt( chỉ số, đối tượng ) - X - X
intersection ( 2 đối tượng cộng X - X -
tác)

last() - X - X
prepend( đối tượng) - X - X
subOrderedSet( lower, upper) - X - -
subSequence( lower, upper) - - - X
symmetricDifference( 2 đối X - - -
tượng cộng tác)
unicon( 2 đối tượng cộng tác) X X X X
♦ Toán tử = và toán tử <>
Toán tử = trả lại giá trị true nếu tất cả các phần tử ở hai tập hợp giống nhau.
Đối với tập có thứ tự đòi hỏi cả thứ tự xuất hiện các phần tử phải như nhau. Đối
với tập có lặp lại phần tử thì số lần lặp lại của các phần tử cũng phải như nhau.
Ngược lại, toán tử <> trả lại true nếu tất cả các phần tử ở hai tập hợp không
giống nhau.
♦ Phép toán including và excluding
a-> including( b): cho một tập mới gồm tất cả các phần tử của a thêm vào các
phần tử trong b mà không có trong a.
a->excluding( b): cho một tập mới gồm tất các các phần tử của a trừ ra các
phần tử cũng có trong b.
♦ Phép toán flatten
Phép toán flatten biến đổi một tập hợp các tập hợp thành một tập hợp của các
đối tượng đơn.
♦ Phép toán asSet, asSequence, asBag, asOrderedSet
Các thể hiện của một trong bốn kiểu tập hợp Set, Sequence, Bag, OrderedSet có
thể được chuyển sang thể hiện của các kiểu kia, thực hiện tương ứng bởi các
phép toán asSet, asSequence, asBag, asOrderedSet.
♦ Phép toán union

Phép toán union nối hai tập hợp thành một tập hợp mới. Một set nối với một set
cho một set. Một set nối với một bag cho một bag. Một sequence hay
orderedSet không thể nối với một set hay một bag, chỉ nối được với một tập
hợp có thứ tự khác.
♦ Phép toán intersection
Phép toán intersection cho kết quả là một tập hợp mới gồm các phần tử trong cả
hai tập hợp. Phép toán áp dụng được đối với hai set, một set và một bag, hay hai
bag, nhưng không áp dụng cho sequence và orderedSet.
♦ Phép toán -
a- b: cho tập mới gồm các phần tử thuộc tập a nhưng không thuộc tập b.
♦ Phép toán symmetricDifference
a.symmetricDifference(b): cho tập mới gồm các phần tử thuộc tập a nhưng
không thuộc tập b hoặc thuộc tập b nhưng không thuộc tập a.
2.7.2.2. Các phép toán chỉ cho các tập hợp kiểu OrderedSet và Sequence
♦ Các phép toán first và last cho kết quả tương ứng là phần tử đầu và cuối của tập
hợp.
♦ Phép toán at cho kết quả là phần tử tại vị trí là tham số đưa ra.
♦ Phép toán indexOf cho kết quả là một số nguyên chỉ ra vị trí của phần tử trong
tập hợp. Nếu trong tập hợp phần tử xuất hiện nhiều lần thì kết quả là vị trí xuất
hiện đầu tiên của phần tử. Chỉ số của vị trí bắt đầu tính từ 1.
♦ Phép toán insertAt cho kết quả là một tập mới chèn thêm phần tử vào vị trí đưa
ra trong tham số.
♦ Phép toán subSequence (subOrderedSet): chỉ áp dụng cho các sequence

(subOrderedSet), cho kết quả là một sequence (subOrderedSet) mới chứa các
phần tử từ các vị trí có số thứ tự trong khoảng được đưa ra trong tham số.

♦ Phép toán append và prepend tương ứng thêm một phần tử vào một sequence ở
cuối và đầu tập hợp.
Một số VD:
equence{'a','b','c','c','d','e'}->first() = 'a'
OrderedSet{'a','b','c','d'}->last() = 'd'
Sequence{'a','b','c','c','d','e'}->at( 3 ) = 'c'
Sequence{'a','b','c','c','d','e'}->indexOf( 'c' ) = 3
OrderedSet{'a','b','c','d'}->insertAt( 3, 'X' ) =
OrderedSet{'a','b','X','c','d'}
Sequence{'a','b','c','c','d','e'}->subSequence( 3, 5 ) =
Sequence{'c','c','d'}
OrderedSet{'a','b','c','d'}->subOrderedSet( 2, 3 ) =
OrderedSet{'b','c'}
Sequence{'a','b','c','c','d','e'}->append( 'X' ) =
Sequence{'a','b','c','c','d','e','X'}
Sequence{'a','b','c','c','d','e'}->prepend( 'X' ) =
Sequence{'X','a','b','c','c','d','e'}
2.7.3. Các phép toán lặp và duyệt.

Các phép toán chuẩn OCL cho phép duyệt toàn bộ các phần tử trong một tập
hợp. Các phép toán đó xét từng phần tử trong tập hợp và xét giá trị của biểu thức
tương ứng với phần tử đó. Mọi phép toán duyệt đều có một biểu thức OCL như là
tham số, gọi là body hay body parameter. Bảng các phép toán duyệt định nghĩa trên
bốn kiểu tập hợp:
Bảng 9. Các phép toán duyệt định nghĩa trên kiểu tập hợp
Phép toán Mô tả
any ( biểu thức) trả lại một phần tử ngẫu nhiên trong tập hợp nguồn mà
biểu thức tham số có giá trị đúng.
collect ( biểu thức) trả lại tập các đối tượng là kết quả của biểu thức tham
số áp dụng trên mỗi phần tử của tập hợp nguồn.
collectNested( biểu trả lại tập các tập hợp là kết quả của biểu thức tham số
thức) áp dụng trên mỗi phần tử của tập hợp nguồn.
exitst( biểu thức) trả lại true nếu có ít nhất một phần tử trong tập hợp
nguồn thỏa mãn biểu thức.
forAll( biểu thức) trả lại true nếu biểu thức đúng đối với tất cả các phần
tử của tập hợp nguồn.
isUnique( biểu thức) trả lại true nếu biểu thức có một giá trị duy nhất đối
với tất cả các phần tử của tập hợp nguồn.

iterate( … ) duyệt tất cả các phần tử của tập hợp nguồn.

one ( biểu thức) trả lại true nếu có đúng một phần tử tập hợp nguồn
thỏa mãn biểu thức.
reject( biểu thức) trả lại một tập con của tập hợp nguồn chứa các phần tử
không thỏa mãn biểu thức.
select( biểu thức) trả lại một tập con của tập hợp nguồn chứa các phần tử
thỏa mãn biểu thức.
sortedBy( biểu thức) trả lại một tập hợp gồm các phần tử của tập hợp nguồn
được sắp xếp bởi biểu thức.
2.8. Các cấu trúc nâng cao

2.8.1. Các cấu trúc cho các điều kiện sau
Có hai cách viết ràng buộc cho các phép toán: điều kiện trước và các điều kiện
sau. Trong các điều kiện sau, có thể dùng một số cấu trúc đặc biệt. 2 từ khóa result và
@pre mở rộng khi làm việc với thời gian.
2.8.1.1. Từ khóa @pre

Từ khóa @pre chỉ ra giá trị của một thuộc tính hay một kết hợp tại thời điểm
bắt đầu thực hiện phép toán. Từ khóa là hậu tố của mục liên quan. Ví dụ :
context LoyaltyProgram::enroll(c : Customer)
pre : not (participants->includes(c))
post: participants = participants@pre->including(c)
2.8.1.2. Từ khóa result

Từ khóa result chỉ ra giá trị trả lại từ một phép toán. Kiểu của kết quả định
nghĩa trong kiểu trả về của phép toán. Trong ví dụ sau, kiểu của kết quả là
LoyaltyProgram. Chú ý rằng một điều hướng từ một lớp kết hợp, trong trường hợp
này- MemberShip luôn cho kết quả là một đối tượng đơn:
context Transaction::getProgram() : LoyaltyProgram
post: result = self.card.Membership.programs
2.8.1.3. Toán tử ocllsNew

Để quyết định một đối tượng có được tạo ra trong quá trình thực hiện một phép
toán hay không, toán tử ocllsNew được dùng. Nó trả lại true nếu đối tượng gọi nó
không tồn tại trong điều kiện trước nhưng tồn tại trong điều kiện sau. Trong ví dụ sau,

điều kiện sau phát biểu rằng giữa khoảng điều kiện trước và điều kiện sau, ít nhất một
khách hàng được thêm vào tập những người tham gia. Đối tượng khách hàng này được
tạo ra trong khoảng điều kiện trước và sau, có tên bằng tham số n, ngày sinh bằng
tham số d:
context LoyaltyProgram::enrollAndCreateCustomer( n : String,
d: Date ) : Customer
pre : -- none
post: result.oclIsNew() and
result.name = n and
result.dateOfBirth = d and
participants->includes( result )
Chú ý rằng một điều kiện sau không chỉ ra các câu lệnh trong phần thân của
phép toán.
2.8.1.4. Toán tử isSent

Toán tử isSent ( ký hiệu ^) biểu diễn một lời gọi có thể dùng trong điều kiện
sau. Toán tử này gọi một đối tượng đích và một thông điệp như là các toán hạng. Nó
trả về giá trị boolean. Ví dụ sau trên mẫu observer chuẩn phát biểu thông điệp
update(12,14) được gửi tới đối tượng đích observer trong khoảng giữa thời điểm điều
kiện trước và sau của phương thức hasChanged:
context Subject::hasChanged()
post: observer^update(12, 14)

Chương 3. Giới thiệu khung làm việc
Chương 3.
Giới thiệu khung làm việc

3.1. Sự ra đời của khung làm việc
Trong suốt 10 năm qua, sự cần thiết của sử dụng lại phần mềm trở nên rõ ràng.
Hướng đối tượng làm tăng khả năng sử dụng mã bằng cách cung cấp thừa kế và các
giao diện chuẩn. Các thư viện lớp cung cấp các thành phần xây dựng sẵn có thể dùng
lại được, nhưng việc sử dụng các thư viện lớp chủ yếu dẫn đến dùng lại mã nguồn và
chỉ một ít là dùng lại phân tích thiết kế. Để tăng khả năng sử dụng lại của phân tích
thiết kế, các khung làm việc hướng đối tượng ra đời.
3.1.1. Một số khái niệm hướng đối tượng
3.1.1.1. Thừa kế
Khi một lớp thừa kế từ một lớp khác, lớp thừa kế được gọi là một lớp con và
lớp được thừa kế được gọi là một lớp cha. Lớp con thừa kế từ lớp cha các phương thức
và các cấu trúc bên trong. Trong một lớp con, các phương thức mới có thể được thêm
vào và các phương thức thừa kế có thể được định nghĩa lại.
Thừa kế có một vài ưu điểm. Mã nguồn được sử dụng lại, do thừa kế cho phép
các lớp chia sẽ mã nguồn chung. Thừa kế cũng thích hợp trong giai đoạn bảo trì vì nó
có thể định nghĩa mã nguồn gốc trong lớp cha và thi hành trong một lớp con. Thừa kế
là một cách tốt để xây dựng mã nguồn và thiết kế. Theo lý thuyết, một thiết kế tốt là
thiết kế mà một lớp con là một trường hợp đặc biệt ( specialization- chuyên môn hóa)
lớp cha của nó.
Tuy có nhiều điểm mạnh nhưng thừa kế cũng có một số nhược điểm. Ví dụ,
thừa kế phá vỡ che dấu thông tin của các đối tượng- các lớp con phụ thuộc vào các lớp
cha của chúng và mã được phân bố trên toàn hệ thống. Điều này làm tăng khó khăn
khi tìm hiểu các hệ thống lớn các lớp theo cấp bậc.

3.1.1.2. Liên kết động và đa hình
class Shape
-move()
//thi hành
-draw()
//ảo
class Circle class Square
-draw() -draw()
//thi hành //thi hành
Shape S;
S = new Circle(); liên kết động
Đa hình S.draw();
// gọi draw() trong lớp Circle
S = new Square();
S.draw();
// gọi draw() trong lớp Square
Hình 9. Ví dụ liên kết động và đa hình
Liên kết động là quy trình liên két một lời gọi hàm với một định nghĩa hàm tại
thời gian chạy. Với liên kết động, quyết định chạy định nghĩa hàm nào đó được đưa ra
tại thời điểm chạy chứ không phải trong quá trình biên dịch, khi ta biết chắc đối tượng
thuộc lớp nào. Trong ví dụ trên, kiểm tra trên các đối tượng:
if ( S là đối tượng kiểu Circle) { drawCircle();}

elseif ( S là đối tượng kiểu Square) { drawSquare();}
và thay thế bởi một lời gọi hàm chung chung S.draw()
Trong một lời gọi tại thời điểm chạy, hệ thống quyết định thực thi hàm draw()
của lớp Circle hay của lớp Square.
Kết quả của liên kết động tạo ra đa hình. Đa hình dẫn đến các biến và tham số
có thể nhận giá trị của các kiểu khác nhau.

3.1.2. Sử dụng lại phần mềm

Sự mất cân đối giữa nhu cầu và năng suất phần mềm vẫn gia tăng. Sử dụng lại
là một cách để tăng năng suất phần mềm. Mục đích của việc sử dụng lại là không phát
triển thêm mà dùng lại những gì đã có. Điều này dẫn tới rút ngắn thời gian phát triển.
Thiết kế phần mềm cho mục đích sử dụng lại để cung cấp những thành phần
phần mềm chung có thể mở rộng được. Các thiết kế truyền thống cung cấp các thư
viện thủ tục cụ thể theo miền hay thư viện các lớp có thể dùng lại được. Khó khăn của
phương pháp này là các kiểu ứng xử trong một thư viện là mặc định. Một thư viện
thành phần chứa các thành phần khá nhỏ để xây dựng ứng dụng mong muốn, và khi
xây dựng một ứng dụng với các thành phần nhỏ thì sự liên lạc giữa các thành phần
khác nhau phải được định nghĩa.
Những ràng buộc đó được giải quyết bằng cách dùng một khung làm việc. Nhà
thiết kế ứng dụng không phải biết cách và thời điểm gọi các hàm, khung làm việc sẽ
chịu trách nhiệm về việc đó. Liên lạc giữa các thành phần bên trong một khung làm
việc được định nghĩa trước và người sử dụng lại không cần quan tâm đến điều đó.
3.1.2.1. Các thư viện lớp

Một thư viện lớp là một tập các lớp quan hệ với nhau được thiết kế để cung cấp
khả năng sử dụng lại. Một ví dụ của một thư viện lớp là tập các lớp kiểu tập hợp cho
các danh sách và ngăn xếp. Các thư viện lớp không áp đặt một thiết kế chi tiết trên một
ứng dụng, chúng chỉ trợ giúp ứng dụng làm việc. Các thư viện lớp cung cấp sự trợ
giúp tại mức thấp và người phát triển phải cung cấp các quan hệ giữa các thư viện.
Do một khung làm việc bao gồm tập các lớp nên có thể xem như một thư viện
lớp. Điều này không hoàn toàn đúng do trong một thư viện lớp mọi lớp đều độc lập
còn trong khung làm việc các lớp hầu như phụ thuộc lẫn nhau và không thể dùng ngoài
khung làm việc.
Khó khăn lớn với các thư viện lớp là chúng phải chứa các thành phần và cấu
trúc cụ thể theo miền đủ lớn để có thể sử dụng lại. Các đối tượng hiếm khi tự có các
hành vi có ích mà chỉ có được khi kết hợp ( tương tác) với các đối tượng khác.
Các khung làm việc cung cấp khả năng sử dụng lại tại một mức cao hơn. Kỹ
thuật sử dụng lại các khung làm việc dẫn đến dùng lại phân tích và thiết kế nhưng cho
phép sử dụng lại mã ở một mức cao hơn các bộ công cụ. Khi đó các ứng dụng có thể
được phát triển bằng cách dùng các khung làm việc như một điểm khởi đầu và viết
lượng mã ít hơn để thay đối hay mở rộng hành vi của khung làm việc.

3.1.2.2. Các khung làm việc

Một khung làm việc hướng đối tượng là một tập các lớp cộng tác, cả trìu tượng
và cụ thể tạo thành một thiết kế có thể dùng lại được cho một lớp cụ thể phần mềm.
Khung làm việc quyết định kiến trúc của các ứng dụng dùng nó bằng cách chia thiết kế
thành các lớp trìu tượng và định nghĩa các trách nhiệm, cộng tác và luồng điều khiển
giữa các lớp. Phát triển khung làm việc nhấn mạnh tới dùng lại thiết kế hơn là dùng lại
mã.
Các khung làm việc cũng dùng lại sự cài đặt nhưng không quan trọng như dùng
lại các giao diện bên trong của một hệ thống và sự phân chia các chức năng vào các
thành phần của hệ thống.
Liên kết động cho phép khung làm việc đối xử với một đối tượng mà không
quan tâm đến việc thực thi. Một nhà phát triển ứng dụng tạo ra một lớp mới từ các
khuôn mẫu ( template) được cung cấp bởi các lớp cha trìu tượng. Khung làm việc sẽ
gọi các phương thức và do sự thay đổi trong điều khiển này, các khung làm việc đôi
khi được xem như các thư viện không được sắp xếp.
Hình 10. Sự khác nhau trong điều khiển giữa khung làm việc và thư viện lớp
Khung làm việc cung cấp một kiến trúc dựa trên điều khiển với một tầng điều
khiển dữ liệu. Các nhà phát triển dùng tiện ích xây dựng trong khung làm việc bằng
cách tạo thể hiện các lớp và gọi các hàm thành viên ( điều khiển dữ liệu) của chúng,
mở rộng và thay đổi tiện ích bằng cách tạo ra các lớp dẫn xuất mới và chồng đè các
hàm thành viên ( điều khiển kiến trúc)
Khi một số ứng dụng được phát triển dùng khung làm việc, các thư viện của các
lớp con được chọn ra và sự tùy biến tăng lên bởi việc lựa chọn kết hợp các thành phần.
Khi đó sẽ tiết kiệm được thời gian tối thiểu vì không cần cài đặt và thử nghiệm.
Theo lĩnh vực ứng dụng khung làm việc chia ra thành các loại:

♦ Khung làm việc hỗ trợ: cung cấp các dịch vụ mức hệ thống, như truy nhập file,
hỗ trợ tính toán phân tán hay các điều khiển thiết bị. Các nhà phát triển ứng
dụng thường dùng trực tiếp các khung làm việc hỗ trợ. Các khung làm việc hỗ
trợ vẫn có thể được tùy biến, ví dụ khi phát triển một hệ thống file hay một điều
khiển thiết bị mới.
♦ Khung làm việc ứng dụng: đóng gói thành các chương trình ứng dụng theo chức
năng. Ví dụ, các khung làm việc ứng dụng giao diện đồ họa người dùng (GUI)
thương mại hiện nay cung cấp các tính năng chuẩn yêu cầu bởi tất cả các ứng
dụng GUI.
♦ Khung làm việc miền: đóng gói trong một miền vấn đề cụ thể. Vd, khung làm
việc hệ thống điều khiển cho phát triển các ứng dụng điều khiển quá trình sản
xuất, khung làm việc đa phương tiện, khung làm việc truy nhập dữ liệu…
3.1.2.3. Tại sao dùng khung làm việc

Khi dùng một thiết kế, khung làm việc tốt cả phân tích, thiết kế và mã được
dùng lại. Một khung làm việc cho phép dùng lại phân tích bằng việc miêu tả các đối
tượng quan trọng, các quan hệ giữa các đối tượng và cách các vấn đề lớn được chia
nhỏ ra thành các vấn đề con. Thiết kế được dùng lại trong thiết kế khung làm việc
chứa các thuật toán trìu tượng và định nghĩa các giao diện, cũng như các ràng buộc
một sự thực thi phải thỏa mãn. Mã được dùng lại từ một lớp cụ thể, thực thi bởi người
dùng có thể thừa kế hầu hết cài đặt từ lớp cha.
a. Ưu điểm
♦ Giảm thời gian hoàn thành: khi viết các ứng dụng xây dựng trên một khung làm
việc làm cơ sở, chỉ cần viết phần mã khác với các ứng dụng đã được viết trước
đó. Khối lượng mã phải viết sẽ ít hơn, có nghĩa là thu ngắn thời gian phát triển
và dó đó giảm thời gian hoàn thành.
♦ Chi phí bảo trì: các hệ thống bảo bảo trì chi phí thường rất cao. Một hệ thống
lớn thường bỏ ra 60-85% tổng chi phí cho bảo trì. Do đó giảm chi phí trong
khâu bảo trì có ý nghĩa rất lớn. Khi bảo trì các ứng dụng của một khung làm
việc, chỉ khung làm việc và mã là khác so với các ứng dụng đã được bảo trì
trước đó. Điều này có nghĩa những thay đổi chỉ thực hiện ở một nơi. So với bảo

trì các hệ thống khác, khi dùng các thiết kế khung làm việc tiết kiệm được chi
phí một cách đáng kể.
♦ Kiểm thử: khi dùng lại một khung làm việc, các kiểm thử cũng được dùng lại.
Các kiểm thử cần tạo mới là các kiểm thử của các module mới và tương tác
giữa các module mới và khung làm việc ( các kiểm thử hệ thống). Do đó, giảm
thời gian kiểm thử và soát lỗi. ( Với giả thiết các kiểm thử hệ thống kiểm tra
khung làm việc được dùng một cách đúng đắn).
♦ Tính tin cậy: một khung làm việc cũng như tất cả các phần mềm khác, chứa các
lỗi và hỏng hóc, nhưng khi khung làm việc được dùng lại nó có xu hướng trở
nên ổn định hơn và các lỗi hỏng hóc mới ngày càng giảm. Dùng lại một khung
làm việc ổn định sẽ tăng tính tin cậy so với việc viết mã mới hoàn toàn.
♦ Tuân theo các chuẩn: một khung làm việc được thiết kế tốt tuân theo các chuẩn.
Khi phát triển các ứng dụng từ khung làm việc, khung làm việc thiết lập các
ràng buộc trên các mã ứng dụng được viết. Điều này dẫn đến ứng dụng tuân
theo các chuẩn.
♦ Các khung làm việc bao gồm các kỹ thuật: thiết kế phần mềm tốt trong một lĩnh
vực cụ thể đòi hỏi kiến thức thu được từ kinh nghiệm. Do các khung làm việc
bao gồm các kỹ thuật, các vấn đề được giải quyết một lần, các quy tắc nghiệp
vụ và thiết kế không thay đổi khi dùng lại. Điều này cho phép một tổ chức xây
dựng trên nền tảng đã làm trong thời gian trước. Các khung làm việc cũng cho
phép các nhà phát triển phần mềm tập trung vào giải quyết ứng dụng và dựa
trên khung làm việc cung cấp các dịch vụ thích hợp. Nó giúp các nhà phát triển
không phải là các chuyên gia trong một lĩnh vực nhất định tránh được sự phức
tạp của các chi tiết cơ bản. Điều này có được là do khung làm việc ở trong tầm
kiểm soát. Khung làm việc cung cấp luồng điều khiển, trong khi phần mã của
lập trình viên ứng dụng chờ khung làm việc gọi. Có nghĩa là các nhà phát triển
không phải quan tâm tới các chi tiết và họ có thể tập trung giải quyết miền vấn
đề.
♦ Cải thiện độ ổn định và khả năng tương thích.
b. Khó khăn

Việc thiết kế các thành phần và kiến trúc cho sử dụng lại đòi hỏi nhiều thời gian
hơn so với thiết kế bình thường. Thiết kế một khung làm việc khó khăn hơn thiết kế
một thư viện thành phần, nhưng lợi ích tiềm năng của việc dùng lại một khung làm
việc lớn hơn nhiều so với dùng lại một thành phần từ thư viện. Một khung làm việc
gặp khó khăn hơn trong việc thiết kế vì kiến trúc của khung làm việc phải được thiết
kế bao gồm cả giao tiếp giữa các thành phần bên trong của khung làm việc. Khi thiết
kế một thành phần cho một thư viện thì không phải làm điều này.
3.2. Ví dụ khung làm việc

Đề tìm hiểu rõ hơn về khung làm việc xét ví dụ bài toán có mô hình nghiệp vụ:
có một kiểu Kho hàng ( Stock) với một thuộc tính mức ( Level), chọn một gói của các
thành phần giao diện người sử dụng, chúng ta tìm thấy kiểu công cụ đo ( Meter) dùng
cho việc hiển thị số để đọc ( reading ), phục vụ cho việc đánh giá tình trạng tồn kho.
Bây giờ chúng ta muốn xác định là Meter có thể được sử dụng để hiển thị mức
độ của Stock , bằng cách sử dụng mẫu thiết kế quan sát ( Observer). Thông thường
chúng ta chỉ chú ý đến các khía cạnh khác nhau của một mô hình trong các biểu đồ
khác nhau, chính vì vậy chúng ta không nói lại tất cả các thứ đã nói về hai đối tượng
đã được nói ở trên mà chúng ta chỉ cần định nghĩa các thuộc tính và các phương thức
phụ thêm cần thiết để có thể liên kết được chúng.
Vấn đề đặt ra cần xác định Meter có thể được dùng để hiển thị Level của Stock.
Sau đây chúng ta sẽ sử dụng mẫu thiết kế quan sát ( Observer) làm minh hoạ, nó là
một trong số các mẫu thiết kế được dùng phổ biến nhất.
Phương tiện thể hiện cho khung làm việc chính là khuôn mẫu ( template), nó là
một dạng của gói. Trong khuôn mẫu, một số kiểu và một số đặc điểm có thể được định
nghĩa trước bằng các tên đã được đặt chỗ trước ( placeholder name), tức một số kiểu
hay đặc tính đó đã được đặt tên và được định nghĩa một cách hình thức trong khuôn
mẫu đó. Khi khuôn mẫu được áp dụng thì ta chỉ cần thay thế các chỗ đã được định
nghĩa bằng các tên cụ thể của đối tượng được thay thế. Nhìn vào định nghĩa của nó
trong thư viện, chúng ta tìm thấy trong khuôn mẫu mẫu quan sát có hai kiểu được đặt
chỗ trước là Subject và Observer. Thay thế các tên này trong gói bởi Stock và Meter,
các định nghĩa thay thế trở thành một phần của mô hình. Nói một cách khác, bất cứ
thuộc tính và phương thức nào được định nghĩa cho Subject của khuôn mẫu thì bây giờ
cũng được định nghĩa trong Stock. Các tên khác được thay thế cũng tương tự như vậy.
Khuôn mẫu sử dụng một thuộc tính được gọi là giá trị ( value) cho Subject, giá trị mà
ta muốn quan sát; chính vì vậy chúng ta thay thế nó cho Level của Stock.
Khung làm việc là một gói khuôn mẫu, các phần tử có thể được thay thế. Nó
mở ra một phiên bản nội dung của khung làm việc dựa trên sự thay thế được tiến hành,

nói cách khác khi khung làm việc được triển khai, thì trong đó sẽ có sự thay thế. Sau
khi thay thế ta sẽ được một phiên bản khung làm việc mới có nội dung cụ thể nhưng
lại dựa trên nội dung của khung làm việc ban đầu.
Khung làm việc có thể là sự trừu tượng hóa bản đặc tả của một kiểu thông
thường, một họ các kiểu phụ thuộc lẫn nhau, một sự cộng tác, một khuôn mẫu làm
mịn, mô hình tạo nên chính chúng, thậm chí là một nhóm các thuộc tính cơ bản thông
thường (kết hợp, giao hoán,…).
Observation
Observer
Subject [view_value/reading]
[value/level]
Meter
Stock
Hình 11. Ví dụ về áp dụng một mô hình khung làm việc
Khung làm việc quan sát thể hiện một loạt các quyết định thiết kế về cách thức
mà hai kiểu đối tượng sẽ cộng tác với nhau như thế nào để đạt được kết quả mong
muốn mà không quan tâm đến bất kỳ một vai trò hay cộng tác cụ thể giữa các đối
tượng này. Sự khái quát này phân rã công việc thiết kế cho bất kỳ một miền xác định
nào. Đó chính là một trong rất nhiều những hiệu quả của việc sử dụng mô hình khung
làm việc.
Một mẫu thiết kế là một tập các ý tưởng có thể được áp dụng cho nhiều tình
huống trong phát triển phần mềm. Một khung làm việc là “trái tim” của các mẫu thiết
kế. Khi lưu khung làm việc trong thư viện, ta nên đóng gói nó cùng với các tài liệu.
Một khái niệm liên quan nữa, đó là các khuôn mẫu lớp được sử dụng trong một số
ngôn ngữ lập trình. Một khuôn mẫu lớp cũng là một khung mô hình nhưng nó chỉ chứa
một lớp duy nhất.
Sự đa dạng của các kỹ thuật hướng đối tượng cho phép ta xây dựng các khung
làm việc có thể thực thi được, bằng cách chia nhỏ nó thành các lớp, cắm thêm các
thành phần mới, và bằng cách thể hiện các lớp qua các ngôn ngữ được xây dựng để
phục vụ cho các mục đích này.
Các công cụ hỗ trợ cho các khung làm việc và các khuôn mẫu cho phép mở mỗi
ứng dụng của mô hình khung làm việc để có thể nhìn thấy mô hình kết quả với đầy đủ
thực thi được với tất cả những thành phần thay thế đã được tạo ra, tức là tất cả các
thành phần đã thay thế vào các điểm đặt chỗ trước của khung làm việc nguyên thủy
ban đầu. Về mặt ý tưởng, các khung làm việc sẽ lưu các định nghĩa của khung làm

việc, các định nghĩa ban đầu của các kiểu áp dụng, các biểu đồ trong khung làm việc
được sử dụng. Nếu như người dùng thay đổi bất cứ thành phần nào trong số chúng thì
mô hình kết quả đã mở ra và được thay đổi từng bước.
3.2.1. Khung làm việc cộng tác

Một sự cộng tác mô tả tương tác giữa các đối tượng được thiết kế để làm việc
với nhau. Mỗi đối tượng được thiết kế để nhằm một mục đích nhất định và tất cả các
hoạt động của nó đều nhằm vào hoàn thành mục đích đó. Hầu hết các kỹ năng thiết kế
hướng đối tượng là thiết kế sự cộng tác. Kỹ thuật CRC (classes: các lớp,
responsibilities: các trách nhiệm, collaborations: các cộng tác) là kỹ thuật cơ bản của
việc thiết kế hướng đối tượng và là sự phân chia các trách nhiệm giữa các đối tượng
cộng tác với nhau để làm một công việc nào đó. Chính việc phân tích này phân biệt
việc lập trình hướng đối tượng và thiết kế hướng cấu trúc, ở đó tất cả các công việc
được gộp vào một chương trình. Nếu ta làm công việc thiết kế tốt, ta sẽ có được một
thiết kế phân rã có tính linh hoạt và mở rộng được.
Khi hoàn thành tốt một thiết kế về sự cộng tác, nó sẽ có tác dụng ghi lại các ý
tưởng của người thiết kế và sử dụng lại được các ý tưởng đó. Đây chính là động lực
trong việc sử dụng các mẫu thiết kế. Một vài công cụ có khả năng hỗ trợ cách thức
định nghĩa các cộng tác này và kết nối chúng lại với nhau tạo thành các thiết kế lớn
hơn.
Các khung làm việc chính là các thành phần có khả năng sử dụng lại của thiết
kế. Chúng ta sẽ sử dụng các khung làm việc này vào các thành phần có khả năng sử
dụng lại của sự cộng tác.
Trong thực tế, các đối tượng tham gia vào nhiều sự cộng tác lẫn nhau, và trong
mỗi cộng tác đó, nó đều có một vai trò nhất định. Ví dụ, khi miêu tả về sự cộng tác
giữa đối tượng nhân viên, nó miêu tả sự tác động lẫn nhau giữa các nhân viên trong
công việc. Tuy nhiên, một nhân viên vừa có thể đóng vai trò là người quản lý, vừa
đóng vai trò là nhân viên. Tức là khi tham dự vào nhiều sự cộng tác thì trong mỗi sự
cộng tác, một đối tượng có thể đóng vai trò khác nhau.
Tuy nhiên trong những sự cộng tác như vậy, có thể có các sự cộng tác riêng rẽ
ảnh hưởng đến cùng một thuộc tính của một đối tượng. Ví dụ, giá trị tài khoản ngân
hàng (thuộc tính) của một người có thể được tăng lên nhờ vào việc gửi thêm tiền vào
tài khoản (sự cộng tác giữa khách hàng và ngân hàng). Mặt khác giá trị tài khoản đó
cũng có thể được tăng nhờ vào việc các nhân viên ngân hàng cộng gộp tiền lãi của tài
khoản vào trong tài khoản gốc (sự cộng tác của nhân viên ngân hàng và ngân hàng)
của người đó.

Để minh họa, ta xem xét sự cộng tác Subject-Observer. Trong hình 12 chúng ta
chỉ ra các giao diện bên ngoài của mỗi đối tượng chia được thành các vai trò trong các
sự cộng tác khác nhau cho dù các thuộc tính bên trong có thể được chia sẻ. Sự cộng
tác này “quản lý” hai vai trò: Subject và Observer. Subject có thuộc tính value và
Observer có thuộc tính khác được gọi là value_view. Một hành động update (cập nhật)
được khởi tạo bởi Subject và làm cho Observer cập nhật theo.
Các vai trò được nắm giữ bởi phần này của
mỗi đối tượng
Subject Observer
value value_view
Cập nhật
Phần này của đối tượng Phần còn lại

liên quan đến sự cộng Phần này của đối tượng của đối tượng
tác và không được biết liên quan đến sự cộng Biến nội tại liên quan
đến tác Subject-Observer đến cả hai phần
Hình 12. Sự cộng tác giữa các đối tượng
Tất nhiên một cặp các lớp bất kỳ có mối quan hệ như vậy trong một chuỗi các
mã chương trình có thể không được gọi là Subject và Observer. Chúng có vai trò lớn
và đáng quan tâm hơn trong chương trình của chúng, có lẽ giống như các thành phần
của GUI hay các ủy nhiệm trong các hệ thống phân tán. Nhưng cái đó mới nói lên
chính xác khung làm việc là gì: Chúng ta có thể chỉ định nghĩa các khía cạnh về một
cái gì đó mà ta muốn nói và sau đó cho phép người dùng sử dụng các tên khác và mở
rộng các định nghĩa khi họ áp dụng khung làm việc của ta.
Chính vì thế, đúng như chúng ta chỉ ra trong hình 12, chúng ta thực sự chỉ biết
một phần của đối tượng mà chúng ta đang miêu tả: phần còn lại phụ thuộc vào bất cứ
ai sử dụng khung làm việc. Trong ví dụ này, chúng ta không biết cách thức và tại sao
value của Subject thay đổi. Chúng ta chỉ biết rằng nó có thể thay đổi và khi nó thay đổi
Observer phải được cập nhật.

3.2.1.1. Các hành động trong khung làm việc cộng tác
Sự khác nhau lớn nhất giữa khung làm việc này và các khung làm việc khác là
khung làm việc này có các hành động. Thực tế, khung làm việc này có các hành động
sau:
♦ Hành động cập nhật giữa Subject và Observer.
♦ Tất cả các hành động khác mà ta không biết về chúng, các hành động đó thay
đổi giá trị của Subject.
Việc xác định hành động đầu tiên là khá dễ dàng:
action Observer :: update ()
post value_view = subject.value
- - phản ánh một cách chính xác giá trị value của Subject
Hành động update chỉ là một trong rất nhiều hành động có thể làm thay đổi giá
trị value của Subject. Nói một cách hình thức, ta sử dụng một kết quả bất biến, tức là ta
không quan tâm đến các hành động xảy ra đối với hệ thống như thế nào, khi nào và
như thế nào. Ta chỉ cần biết rằng, khi có một hành động xảy ra thì ta thu được một kết
quả bất biến. Ở đây cũng vây, ta không quan tâm xem hành động nào xảy ra, xảy ra
khi nào và xảy ra như thế nào đối với giá trị của Subject, nhưng ta chỉ biết một kết quả
bất biến là khi giá trị bị thay đổi thì hành động update luôn xảy ra: nó là một điều kiện
sau :
inv effect Subject ::
post value@pre <> value _ [[ observers.update() ]]
---Bất cứ hành động nào thay đổi giá trị value cũng đảm bảo
Observer phản ánh chính xác giá trị mới.
Điều kiện sau không chỉ áp dụng cho khung làm việc, mà nó còn phải được
thực hiện một cách chính xác trong các chương trình cụ thể là trong các lớp của
Subject và Observer. Không những thế các đặc tả (làm tài liệu) của nó cũng phải miêu
tả chính xác về các điều kiện sau này.
Hình sau đây chỉ ra khung làm việc cộng tác như chúng ta đã miêu tả nó trong
phần trước. Sự kết hợp Subject-Observer liên kết các thể hiện cụ thể của hai kiểu này
và hành động update chỉ áp dụng cho các Observer có một Subject hiện tại. Hành động
register liên kết một Subject cụ thể tới một Observer cụ thể. Nó là một hành động kết
nối mà chúng ta không xác định cách thức nó xảy ra, thậm chí ai là người gửi thông
điệp làm cho nó xảy ra, chúng ta chỉ xác định được là sẽ có một hành động như thế,
với trách nhiệm thực thi nó được phân bố giữa Subject và Observer.

Mẫu thiết kế quan sát
Register
<Subject> <Observer>
subject observers
<value> <value_view>
0,1 0..*
update
Observer ::
action update ( )
pre subject <> null
post value_view = subject.value
(s: Subject, o: Observer) ::

action register ( )
pre o.subject = null
post o.subject = s
Subject ::
inv effect
post value @ pre <> value ® [[observers.update()]]
Hình 13. Khuôn mẫu cộng tác
3.2.1.2. Áp dụng khung làm việc cộng tác

Bây giờ chúng ta sẽ xem xét một áp dụng cho khung làm việc cộng tác đã nói ở
phần trên cho hệ thống quản lý cuộc gọi. Một trong số các kiểu của mô hình được gọi
là CallQueue: một danh sách các cuộc gọi. Giả sử chúng ta đã có kiểu đó trong một
gói nào đó. Trong gói khác ta có một tập trang bị các giao diện người sử dụng đồ họa
(GUI), mà một trong số đó là Thermometer—dùng cho việc hiển thị giá trị các số.
Bây giờ chúng ta thiết kế một cầu nối giữa lôgic nghiệp vụ và giao diện người
sử dụng đồ họa (GUI), và chúng ta tạo ra một gói mà trong đó chúng ta thay thế
Thermometer và CallQueue. Ta muốn Thernmometer được sử dụng để chỉ ra số cuộc
gọi ( Calls) trong một danh sách hàng đợi cuộc gọi ( CallQueue). Chính vì vậy chúng
ta áp dụng khung làm việc quan sát như hình 14. Tại đây chúng ta thêm vào các đặc tả

cần thiết. Hình 13 hiển thị mô hình được mở: kết quả của việc áp dụng khung làm việc
và đưa ra đặc tả.
calls Call
CallQueue
0..*
{seq}
addCall (c : Call) Thermometer
post calls = calls @ pre + c
getCall ( ) : Call temperature : int
post result = calls @ pre->head other stuff
& calls = calls @ pre->tail about
Thermometers
Hình 14. Mô hình kiểu đích cho việc sử dụng sự quan sát
Observation
Subject
Observer
[value\calls->size]
[value_view\reading]
CallQueue
Thermometer
reading
0..* calls
Call
Hình 15. Ví dụ ứng dụng khung làm việc và sự thay thế

calls
CallQueue Call
0..*
{seq}
addCall (c : Call)
post calls = calls @ register Thermometer
pre + c
& [[observers.update ( reading
)]] subject observers other stuff
getCall ( ) : Call about
post result = calls @ 0,1 0..* Thermometers
pre->head
& calls = calls @ pre-
>tail update
& [[observers.update (
)]]
Thermometer ::
action update ( )
pre subject <> null
post reading = subject.calls->size
(s: CallQueue, o: Thermometer) ::

action register ( )
pre o.subject = null
post o.subject = s
Hình 16. Kết quả mở của ứng dụng khung làm việc
Khi nhìn vào ứng dụng khung làm việc, ta thấy tên Subject và Observer đã được
thay thế và các phương thức addCall và getCall cũng đã được đưa vào, chúng luôn
luôn thay đổi độ lớn các cuộc gọi vào mọi lúc, chính vì vậy cần loại bỏ
value<>value@pre từ các hậu điều kiện của chúng. Tại đây, hành động update có thể
được nhận diện như thông điệp notify (newvalue) hay theo kiểu MVC (Model, View,
Control) thì có thể bao gồm thông điệp update() tới Thermometer, và sau đó, nó phải
quay ngược trở lại CallQueue để yêu cầu chi tiết về sự thay đổi đã xảy ra.

Hành động register có thể được khởi tạo bằng một đối tượng giám sát để chỉ ra
một Thermometer cụ thể quan sát một CallQueue cụ thể. Tiếp đó, Thermometer phải
chỉ ra chính bản thân nó cho CallQueue biết, có như vậy thì chúng mới biết về nhau.
3.2.2. Làm mịn khung làm việc

Khung làm việc là một công cụ diễn tả sự trừu tượng và được sử dụng trong các
định nghĩa mô hình cơ bản. Chúng chỉ được sử dụng khi vấn đề cần giải quyết phải có
các tham số phù hợp với nó hoặc mức độ to lớn của vấn đề phải tương ứng với nó.
Một vấn đề đặt ra là, làm sao có thể áp dụng khung làm việc để giải quyết các
vấn đề cụ thể, quy mô nhỏ, và đôi khi các tham số của bài toán không tương ứng với
khung làm việc. Một giải pháp được đưa ra đó chính là sự làm mịn. Không có một quy
tắc nào trong việc định nghĩa khung làm việc tại một mức chi tiết cố định nào, bản
thân các khung làm việc phụ thuộc vào sự làm mịn, sự trừu tượng và sự hợp thành, tức
là khung làm việc được xây dựng có mức độ chi tiết, hay mức độ trừu tượng phụ thuộc
vào từng bài toán, từng cách xây dựng, quan điểm của người xây dựng, mục đích của
khung làm việc…, và cuối cùng là các thành phần hợp thành nên chính khung làm việc
đó. Hơn thế nữa, một vài sự làm mịn này cũng được định nghĩa như là các khung làm
việc.
3.2.2.1. Một ví dụ về làm mịn

Khung làm việc trong hình 17 sau minh họa mối quan hệ giữa một nhà kinh
doanh (Trader), tạo ra các hóa đơn ( Order) gửi các nhà phân phối ( Distributor).

Yêu cầu cung cấp hàng cho kinh doanh
<Trader>
stock( product): int <Distributor >

lowLimit( product):int
depletion (p:Product) <Order> Từ
stock( product): int

Tới
* lowLimit( product):int *
Các hoá đang nợ
đơn
* *
Cho
0,1 Đã phân phối
<Sản phẩmt> Ngày
inv Trader:: ( p:Product::

stock (p) < lowLimit(p)orders[for=p] <> 0 )
Hình 17. Khung làm việc cho việc thương mại: duy trì kho hàng
Khung làm việc cũng chỉ ra rằng nhà kinh doanh luôn có một hoá đơn khi kho
hàng ở mức thấp hơn mức quy định. Chính vì vậy mà kho hàng có thể luôn luôn tránh
được việc thiếu hàng. Đây chính là một khung làm việc mức cao, nói lên nhiệm vụ
tổng thể của hệ thống mà không đi vào các chi tiết quá cụ thể như cách thức các hóa
đơn tạo ra như thế nào- đó chính là các công việc mà các nhà thiết kế phải làm. Để làm
điều này, có thể định nghĩa những chi tiết trong chính mô hình đó hoặc xây dựng một
khung làm việc khác chứa các thông tin này.
Chúng ta hãy xem xét khung làm việc trong hình 18, một khung làm việc làm
mịn của khung làm việc trong hình 17, khi sản phẩm của bất kỳ kho hàng nào ở mức
thấp, nhà kinh doanh tạo ra một đơn hàng gửi người phân phối bằng cách sử dụng
hành động make_order. Khi Order được tạo ra, người phân phối có thể giao hàng và
người kinh doanh có thể trả tiền. Trong ví dụ trước (hình 17), chúng ta chỉ sử dụng
“kết quả”, tức là chỉ biết kết quả của hành động mà không nói đến nguyên nhân của
các hành động đó, thì ở đây ta chia ra nguyên nhân và kết quả. Đầu tiên ta tạo ra kết

quả có tên depletion(p) (sự làm rỗng: ở đây có nghĩa là làm giảm sản phẩm p trong
kho hàng) là một tên đặt sẵn trong khung làm việc cho bất cứ hành động nào là nguyên
nhân cho việc làm giảm p. Thứ hai, chúng ta tạo ra một điều kiện sau cho depletion;
đó chính là yêu cầu thực hiện hành động make_order. Việc phân chia nguyên nhân kết
quả như vậy rất có ích khi chúng ta có các mối quan hệ nhiều nhiều và ta muốn làm rõ
các nguyên nhân dẫn đến mỗi kết quả.

Cung cấp hàng cho kinh doanh
Tạo hóa đơn

<Trader>
<depletion <Distributor >
(p:Product)>
stock( product): int Phân phối
lowLimit( product): int
Trả
depletion (p:Product)
Từ
<Order >
Tới
* stock( product): int *
Các hoá đơn lowLimit( product): Chưa trả
int
* *
Cho
0,1 Đã phân phối
<Product> Date
action dist:Distributor –> trd:Trader :: deliver(o:Order)

-- Khi một nhà cung cấp gửi hàng tới nhà kinh doanh
pre o.to = trd & o.from = dist
post o.delivered <> null
& (trd.stock(o.for) += o.quantity)
action rtlr:Trader –> dist:Distributor :: make_order
(prod:Product, q:int)
-- Khi một nhà kinh doanh gửi thanh toán tới nhà cung cấp
post
let n:Order.new [quantity=q, to=rtlr, from=dist,
for=prod,paid = 0,
delivered=null, cost=dist.price(prod, q, rtlr)],
rtlr.orders += n & dist.outstanding += n
inv effect
post t:Trader, p:Product::
t.stock(p) < t.stock@pre(p) ==> t.depletion (p))
effect Trader:: depletion (p:Product)
post stock(p) < lowLimit(p) ==>
exists dist:Distributor, n: integer, n> 0 &
[[ this –> d.make_order (p, n) ]]
Hình 18. Sự cộng tác Trade Supply

2.2.2.2. Làm tài liệu sự làm mịn

Khi chúng ta muốn thông báo cho người sử dụng khung làm việc Cung cấp
hàng cho kinh doanh biết rằng việc sử dụng cùng các điểm đặt chỗ trước để thay thế
trong cả hai khung làm việc điều đạt được tập các mục đích được đặt ra trong khung
yêu cầu cung cấp hàng cho kinh doanh. Tức là nếu hai khung làm việc được kết hợp
lại với nhau, việc làm tài liệu sẽ không bị trùng lặp, ta không phải nói tất cả các thứ có
trong Cung cấp hàng cho kinh doanh mà nó đã được ngầm định trong yêu cầu cung
cấp hàng cho kinh doanh. Như vậy khi làm mịn khung làm việc thì các những yếu tố
cơ bản của khung làm việc sẽ không phải làm lại mà nó được ngầm định sử dụng lại.
Chúng ta có thể viết điều này như trong hình 19 :
Yêu cầu cung cấp hàng cho Bất kỳ hành động nào đều phải gọi
make_order nếu kho hàng của thương
nhân bị thiếu hàng. Đối số liên quan:
• Trader :: stock(p) < stock@

pre(p) => [[depletion(p)]]
Cung cấp hàng cho kinh • depletion(p) post stock(p)

<lowLimit(p) => [[makeOrder(p)]]
Hình 19. Làm tài liệu sự làm mịn khung làm việc

Chương 4. Xây dựng hệ thống cho bài toán Lập thời khóa biểu
Chương 4.
Xây dựng hệ thống cho bài toán lập Thời khóa biểu
4.1. Mô hình ca sử dụng
4.1.1. Xác định tác nhân
♦ Nhân viên phòng đào tạo ( người lập thời khóa biểu)
♦ Giáo viên và học viên ( những người xem thời khóa biểu)
4.1.2. Các ca sử dụng
Hình 20. Mô hình ca sử dụng
4.1.2.1. Ca sử dụng lập danh sách các lớp học
♦ Tác nhân: nhân viên phòng Đào Tạo

♦ Mục đích: đưa ra danh sách các lớp học sẽ học trong học kỳ
♦ Mô tả: Lần lượt thêm các lớp sẽ học trong kỳ học tiếp theo vào danh sách, hoặc
xóa bỏ một lớp ra khỏi danh sách các lớp sẽ học.
♦ Chức năng tham chiếu: R1
♦ Luồng sự kiện:
Bảng 10. Bảng luồng sự kiện ca sử dụng lập danh sách lớp học
Hành động của tác nhân Phản ứng của hệ thống Dữ liệu liên quan
1. Chọn chức năng lập
danh sách các lớp 2. Hiện form điều chỉnh
học danh sách lớp học Danh sách các lớp
3. Xác định các lớp 4. Thể hiện danh sách các

học cho học kỳ lớp đã được chọn Bảng tblClass
4.1.2.2. Ca sử dụng lập danh sách các môn học cho mỗi lớp
♦ Mục đích: Đưa ra danh sách các môn học tương ứng với từng lớp(ClassSubject)
♦ Mô tả: trên cơ sở chương trình đào tạo đã được lãnh đạo khoa xem xét và phê
duyệt, cán bộ phòng Đào Tạo lên danh sách các môn học sẽ học trong học kỳ
cho mỗi lớp
Bảng 11. Bảng luồng sự kiện ca sử dụng lập danh sách môn học
5. Chọn chức năng lập 6. Hiện form điều chỉnh Danh sách môn học
danh sách các môn danh sách môn học cho Danh sách lớp- học
học cho lớp từng lớp tương ứng kỳ
8. Hiện danh sách các môn
7. Chọn lớp và chọn học tương ứng với lớp Danh sách môn học
môn tương ứng đã chọn - lớp
9. Chỉnh sửa danh 10. Chỉnh sửa danh và lưu Danh sách môn học
sách lại - lớp

4.1.2.3. Ca sử dụng lập danh sách các giáo viên giảng dạy trong học kỳ
♦ Mục đích: Đưa ra danh sách tất cả các giáo viên giảng dạy sẽ tham gia giảng
dạy cho các lớp
♦ Mô tả: Lần lượt bổ xung vào danh sách giáo viên giảng dạy những giáo viên
giảng dạy thiếu và loại bỏ ra khỏi danh sách những giáo viên giảng dạy sẽ
không giảng dạy trong kỳ tiếp theo
Bảng 12. Bảng luồng sự kiện ca sử dụng lập danh sách giáo viên giảng dạy
11. Chọn chức năng lập 12. Hiện form điều chỉnh
danh sách giáo viên danh sách giáo viên
giảng dạy giảng dạy
14. Thể hiện danh sách các
giáo viên giảng dạy đã
13. Xác định các giáo được chọn, cập nhật
viên giảng dạy cho danh sách vào cơ sở dữ
học kỳ tiếp theo liệu Bảng tblTeacher
4.1.2.4. Ca sử dụng xác định giáo viên giảng dạy các môn học của các lớp
♦ Mục đích: đưa ra được danh sách các giáo viên giảng dạy đảm nhận việc giảng
dạy các môn học của mỗi lớp
♦ Mô tả: trước tiên phòng Đào Tạo gửi danh sách các môn học phân theo bộ môn
gửi đến bộ môn và giáo viên, từ đó bộ môn sẽ tiến hành phân công, đăng kí
giảng dạy và lập ra danh sách giáo viên giảng dạy gửi cho phòng Đào Tạo. Từ
danh sách này phòng Đào Tạo sẽ đưa ra được danh sách các giáo viên giảng dạy
dạy mỗi môn của các lớp(lớp – môn – giáo viên giảng dạy)

Bảng 13. Bảng luồng sự kiện ca sử dụng xác định giáo viên dạy môn học cho lớp
15. Chọn chức năng 16. Hiện form điều chỉnh
xác định giáo viên giáo viên giảng dạy cho
giảng dạy cho các các môn học của từng Danh sách môn học
môn học lớp - lớp
18. Thể hiện danh sách các
17. Xác định giáo viên môn học và các giáo
giảng dạy cho các viên giảng dạy tương
môn học của từng ứng của từng lớp, và cập Danh sách giáo viên,
lớp nhật vào cơ sở dữ liệu tblLink
4.1.2.5. Ca sử dụng xác định các ràng buộc
♦ Mục đích: liệt kê các ràng buộc của thời khóa biểu
♦ Mô tả: Căn cứ vào quy định của bộ Giáo dục, các quy chế giảng dạy,… đưa ra
danh sách các ràng buộc để áp dụng cho việc lập thời khoá biểu.
Bảng 14. Bảng luồng sự kiện ca sử dụng lập danh sách ràng buộc
Chọn chức năng lập danh
sách các ràng buộc Hiện form nhập liệu Danh sách ràng buộc
Cập nhật thông tin và ghi Danh sách Ràng
Xem, cập nhật các ràng buộc nhận buộc
4.1.2.6. Ca sử dụng lập thời khóa biểu
♦ Mục đích: Đưa ra được thời khóa biểu dự kiến và gửi cho các đơn vị liên quan
để lấy ý kiến, hoàn thiện thành thời khóa biểu chính thức.

♦ Mô tả: Từ danh sách lớp, danh sách các môn học của từng lớp, danh sách các
giáo viên giảng dạy, phòng học, và các ràng buộc… cán bộ phòng Đào Tạo tiến
hành chạy chương trình ( có thể kết hợp gắp thả) để có được thời khóa biểu dự
kiến, sau đó gửi cho các đơn vị để lấy ý kiến phản hồi, hoàn thiện thành thời
khóa biểu chính thức.
Bảng 15. Bảng luồng sự kiện ca sử dụng lập thời khóa biểu
Danh sách môn -
lớp - Giáo viên,
Danh sách ràng
19. Chọn chức năng lập 20. Xử lí và hiện ra kết quả buộc, thời khóa
thời khóa biểu có được biểu.
22. Hiện thời khóa biểu của Danh sách lớp - học
21. Chọn lớp học lớp học kỳ, Thời khóa biểu.
Danh sách Giáo
23. Chọn giáo viên 24. Hiện thời khóa biểu của viên, Thời khóa
giảng dạy giáo viên giảng dạy biểu.
4.2. Phân tích

4.2.1. Phân tích kiến trúc
4.2.1.1. Xác định gói phân tích

– Gói phân tích lập thời khóa biểu học kỳ.
4.2.1.2. Xác định các lớp thực thể hiển nhiên

– Lớp thực thể lớp ( Class).
– Lớp thực thể môn học ( Subject).
– Lớp thực thể giáo viên ( Teacher).

4.2.2. Phân tích ca sử dụng
4.2.2.1. Ca sử dụng lập danh sách các lớp học

– Tác nhân: nhân viên phòng Đào Tạo
– Các lớp phân tích:
♦ Lớp thực thể:
♦ Lớp thực thể DS_Lop chứa danh sách các lớp.
♦ Lớp thực thể DS_Lop-HocKy chứa danh sách các lớp học trong học kỳ.
♦ Lớp giao diện: Lớp giao diện frmDS_Lop cho phép tác nhân tạo danh sách các
lớp sẽ học trong học kỳ, cũng như xem hay sửa đổi danh sách hiện thời.
♦ Lớp điều khiển: Lớp điều khiển LapDS_Lop-HocKy có chức năng điều khiển
việc truy xuất và cập nhật danh sách các lớp học sẽ được học trong học kỳ.
– Biểu đồ cộng tác thực thi ca sử dụng:
3: LayThongTin
1: LenDS_Lop 2: LapDS
: DS_Lop
4: TaoMoi
: frmDS_Lop : LapDS_Lop-HocKy
: NhanVienPDT
: DS_Lop - HocKy
Hình 21. Biểu đồ cộng tác ca sử dụng lập danh sách lớp học
♦ Mô tả luồng các sự kiện phân tích diễn giải biểu đồ cộng tác: Nhân viên phòng
Đào Tạo chọn vào danh sách các lớp sẽ học trong học kỳ tiếp theo thông qua
các điều kiện (chương trình đào tạo, hệ đào tạo…), thông qua giao diện người
dùng (frmDS_Lop). Giao diện cung cấp cho người dùng danh sách các lớp học

đã được chọn, và thông tin về các lớp học. Người dùng qua đó thể thể sửa đổi
danh sách các lớp học bằng cách thêm, hoặc xóa một lớp học.
4.2.2.2. Ca sử dụng lập danh sách các môn học trong học kỳ
♦ Lớp thực thể DS_MonHoc chứa danh sách các môn học trong khung
chương trình.
♦ Lớp thực thể DS_MonHoc-HocKy chứa danh sách các môn học trong học
kỳ.
♦ Lớp giao diện: Lớp giao diện frmDS_MonHoc cho phép tác nhân xây dựng
danh sách các môn sẽ được giảng dạy trong học kỳ
♦ Lớp điều khiển: Lớp điều khiển LapDS_MonHoc có chức năng điều khiển việc
truy suất và cập nhật danh sách các lớp học sẽ được học trong học kỳ
– Biểu đồ cộng tác thực thi ca sử dụng :
3: LayThongTin
1: LapDS_MonHoc 2: ThucHien
: DS_MonHoc
4: TaoMoi
: frmDS_MonHoc : LapDS_MonHoc
: NhanVienPDT
: DS_MonHoc - HocKy
Hình 22. Biểu đồ cộng tác ca sử dụng lập danh sách môn học trong học kỳ
Đào Tạo dựa vào chương trình đào tạo của học kỳ để lên danh sách các môn
học sẽ được đưa vào giảng dạy trong học kỳ. Thông qua giao diện

frmDS_MonHoc để có thể biết thêm thông tin thông tin về một môn học và
chỉnh sửa danh sách các môn học
4.2.2.3. Ca sử dụng lập danh sách các giáo viên giảng dạy trong học kỳ
♦ Lớp thực thể frmDS_GiaoVien chứa thông tin về các giáo viên giảng dạy.
♦ Lớp thực thể DS_GiaoVien-HocKy chứa danh sách các giáo viên giảng
dạy giảng dạy trong học kỳ.
♦ Lớp thực thể giao diện: lớp giao diện frmDS_GiaoVien cho phép tác nhân xác
định, xây dựng và chỉnh sửa danh sách giáo viên giảng dạy cũng như các thông
tin về các giáo viên giảng dạy
♦ Lớp điều khiển: lớp điều khiển LapDS_GiaoVien có chức năng điều khiển việc
truy suất và cập nhật danh sách giáo viên giảng dạy cũng như thông tin về các
giáo viên giảng dạy của kỳ học
– Biểu đồ lớp cộng tác thực thi ca sử dụng :
3: LayThongTin
1: LapDS_GiangVien 2: ThucHien : DS_GiaoVien
4: TaoMoi
: frmDS_GiaoVien : LapDS_GiaoVien
: NhanVienPDT
: DS_GiaoVien- HocKy
Hình 23. Biểu đồ cộng tác ca sử dụng lập Danh sách giáo viên trong học kỳ

Đào Tạo dựa vào danh sách các giáo viên giảng dạy đăng kí giảng dạy ở các bộ
môn, thông qua giao diện frmDS_GiaoVien để chỉnh sửa
4.2.2.4. Ca sử dụng xác định môn học cho mỗi lớp

♦ Lớp thực thể DS_Lop-HocKy chứa danh sách các lớp học trong học kỳ.
♦ Lớp thực thể DS_Lop-MonHoc chứa danh sách các môn học mà lớp đó
sẽ được học trong một học kỳ
♦ Lớp thực thể DS_MonHoc-HocKy chứa danh sách các môn học trong học
kỳ của tất cả các lớp.
♦ Lớp giao diện: lớp giao diện frm_Lop-Mon cho phép người dùng chọn lớp học
cần lập danh sách và đồng thời cho phép chọn các môn học cho lớp học đó.
♦ Lớp điều khiển: lớp điều khiển LapDS_Lop-Mon có chức năng sửa đổi danh
sách môn học cho một lớp.

3: LayThongTin
: DS_Lop - HocKy
1: XacDinhMon- Lop 2: ThucHien

4: LayThongTin
5: TaoMoi
: frm_Lop-Mon : LapDS_Lop- Mon : DS_MonHoc - HocKy
: NhanVienPDT
: DS_Lop- MonHoc
Hình 24. Biểu đồ cộng tác ca sử dụng lập danh sách lớp- môn học
♦ Mô tả luồng các sự kiện phân tích diễn giải biểu đồ cộng tác: trước tiên, nhân
viên phòng Đào Tạo chọn ra một lớp cần thao tác trong danh sách các lớp học.
Rồi sau đó thông qua giao diện người dùng, thêm các môn học trong danh sách
các môn học vào lớp đó hoặc xóa các môn học trong danh sách môn lớp ra khỏi
danh sách các môn học của lớp đó.
4.2.2.5. Ca sử dụng xác định giáo viên giảng dạy mỗi môn cho từng lớp
– Tác nhân: nhân phòng Đào Tạo viên.
♦ Lớp DS_Lop-Mon-GV lưu thông tin về các môn học mà lớp đó sẽ học
trong học kỳ và giáo viên giảng dạy tương ứng sẽ dạy môn đó.
♦ Lớp DS_Lop-MonHoc lưu danh sách các môn học cùng với lớp học trong
học kỳ.
♦ Lớp DS_GiaoVien-Hocky lưu danh sách các giáo viên dạy trong học kỳ.

♦ Lớp giao diện: lớp giao diện frmDS_Lop-Mon-GV cho phép hiển thị danh sách
các lớp sẽ học trong học kỳ, cho phép người dùng chọn lớp cần thao tác trong
danh sách các lớp và hiển thị danh sách các môn học tương ứng của lớp đó. Cho
phép người dùng xác định giáo viên giảng dạy (trong danh sách các giáo viên
giảng dạy) tương ứng sẽ dạy một môn học cho lớp đó.
♦ Lớp điều khiển: lớp điều khiển LapDS_Lop-Mon_GV thực hiện việc tạo và
chỉnh sửa liên kết các giáo viên giảng dạy với từng môn học của một lớp.
3: LayThongTin
: DS_Lop- MonHoc
1: LapDS_Lop-Mon-GV
2: ThucHien
4: LayThongTin
5: TaoMoi
: frmDS_Lop-Mon-GV : LapDS_Lop-Mon-GV : DS_GiaoVien- HocKy
: NhanVienPDT
: DS_Lop- MonHoc- GiaoVien
Hình 25. Biểu đồ cộng tác ca sử dụng lập danh sách lớp- môn- giáo viên
♦ Mô tả luồng các sự kiện phân tích diễn giải biểu đồ cộng tác: trước tiên nhân
viên phòng Đào Tạo duyệt danh sách các lớp học trong học kỳ, sau đó chọn một
lớp cần lên danh sách giáo viên giảng dạy thông qua giao diện frmDS_Lop-
Mon-GV. Giao diện frmDS_Lop-Mon-GV sẽ hiện danh sách các môn học mà
lớp đó sẽ học trong học kỳ. Từ danh sách các giáo viên giảng dạy tương ứng với
mỗi môn học, người dùng sẽ chọn ra các giáo viên giảng dạy sẽ dạy cho các
môn học của lớp đó.
4.2.2.6. Ca sử dụng lập danh sách các ràng buộc

– Tác nhân: nhân viên phòng Đào Tạo.

♦ Lớp thực thể RangBuoc chứa thông tin về các qui tắc nghiệp vụ cần phải
tuân theo trong việc lập thời khóa biểu.
♦ Lớp thực thể DS_RangBuoc chứa thông tin về danh sách các ràng buộc
mà nhân viên phòng Đào Tạo đã thiết lập.
♦ Lớp giao diện: lớp giao diện frmDS_RangBuoc cho phép cho phép người dùng
lựa chọn và hiển thị danh sách các ràng buộc đã thiết lập.
♦ Lớp điều khiển: lớp điều khiển LapDS_RangBuoc làm nhiệm vụ liên kết các lớp
ràng buộc và danh sách các ràng buộc và tạo ra thực thể danh sách các ràng
buộc chứa danh sách các ràng buộc phải tuân theo và lưu vào cơ sở dữ liệu.
4: LayThongTin
1: LapDS_RangBuoc 2: ThucHien
: RangBuoc
3: TaoMoi
: frmDS_RangBuoc : LapDS_RangBuoc
: NhanVienPDT
: DS_RangBuoc
Hình 26. Biểu đồ cộng tác ca sử dụng lập danh sách các ràng buộc
♦ Mô tả luồng các sự kiện phân tích diễn giải biểu đồ cộng tác: nhân viên phòng
Đào Tạo duyệt danh sách các ràng buộc thông qua giao diện frmDS_RangBuoc.
Đánh dấu các ràng buộc sẽ được áp dụng và điều chỉnh nội dung của ràng
buộc(nếu có thể).
4.2.2.7. Ca sử dụng lập thời khóa biểu


♦ Lớp thực thể DS_RangBuoc lưu thông tin về danh sách các ràng buộc
phải thỏa mãn.
♦ Lớp thực thể DS_Lop-MonHoc-GiaoVien lưu thông tin về danh sách các
giáo viên giảng dạy dạy các môn của mỗi lớp.
♦ Lớp thực thể ThoiKhoaBieu lưu thông tin về thời gian biểu mới được
thiết lập
♦ Lớp giao diện: lớp giao diện frmLapTKB cho phép lựa chọn, hiển thị là thực
hiện thao tác gắp thả.
♦ Lớp điều khiển: lớp điều khiển LapTKB biểu thực hiện việc liên kết các lớp
thực thể để tạo ra thực thể ThoiKhoaBieu và hiện thị ra lớp giao diện
frmLapTKB.
3: TaoMoi
2: ThucHien : ThoiKhoaBieu
1: LapTKB
5: LayThongTin
: frmLapTKB : LapTKB
: NhanVienPDT : DS_RangBuoc
4: LayThongTin
: DS_Lop- MonHoc- GiaoVien
Hình 27. Biểu đồ cộng tác ca sử dụng lập thời khóa biểu
♦ Mô tả luồng các sự kiện phân tích diễn giải biểu đồ cộng tác: nhân viên phòng
Đào Tạo chọn các lớp (học sáng hay chiều…) để lập thời khóa biểu. Sau khi

truy suất cơ sở dữ liệu để lấy thông tin về các lớp, các môn học của các lớp, các
giáo viên giảng dạy sẽ dạy các môn học và danh sách các ràng buộc phải tuân
theo, chương trình sẽ tự động sinh ra một thời khóa biểu.
4.3. Thiết kế
4.3.1. Thiết kế lớp
4.3.1.1. Lớp thiết kế Speciality ( Chuyên ngành)
♦ Các thuộc tính

Bảng 16. Các thuộc tính lớp thiết kế Spciality
Tên thuộc tính Kiểu dữ liệu Kích cỡ Giải thích
SpeID String 5 (Spe..) Mã chuyên ngành
Name String 255 Tên chuyên ngành
♦ Các phương thức

- add(Name: String): thêm mới một chuyên ngành.
- edit(Name: String): sửa thông tin chuyên ngành.
- del(): xóa chuyên ngành.
4.3.1.2. Lớp thiết kế Teacher ( Giáo viên giảng dạy)

Bảng 17. Các thuộc tính lớp thiết kế Teacher
TeacherID String 4 (T…) Mã giáo viên
Name String 50 Tên giáo viên
Spe String 5 (Spe..) Mã chuyên ngành giáo viên

- add(Name:String, Spe:String): thêm mới giáo viên.
- edit(Name:String, Spe:String): sửa thông tin giáo viên.
- del(): xóa giáo viên.
- getInfo(): lấy thông tin giáo viên.

4.3.1.3. Lớp thiết kế Tie_Teacher ( Giáo viên có ràng buộc)

Là lớp con thừa kế từ lớp cha Teacher có thêm thuộc tính và phương thức:
♦ Thuộc tính
Bảng 18. Các thuộc tính thêm lớp con Tie_Teacher
OffDays String 9 (2,3,…) Xâu chứa các ngày giáo viên yêu
cầu được nghỉ.
♦ Phương thức
- getOffDays(): lấy các ngày nghỉ của giáo viên.
- setOffDays(): gán các ngày nghỉ cho giáo viên.
4.3.1.4. Lớp thiết kế Subject ( Môn học)

Bảng 19. Các thuộc tính lớp thiết kế Subject
SubjectID String 4 (S…) Mã môn học
Name String 255 Tên môn học
Spe String 5 (Spe..) Mã chuyên ngành môn học
ClassNumber Number Integer Số đơn vị học trình môn học

- add(Name:String, Spe:String, ClassNumber:Integer): thêm mới môn
học.
- edit(Name:String, Spe:String, ClassNumber:Integer): sửa thông tin
môn học.
- del(): xóa môn học.
- getInfo(): lấy thông tin môn học.
4.3.1.5. Lớp thiết kế Subject – Class ( Môn học cho lớp)

Là lớp con thừa kế từ lớp cha Subject với mục đích gán cho lớp, có thêm các
thuộc tính và phương thức:

♦ Thuộc tính
Bảng 20. Các thuộc tính thêm lớp con Subject- Class
Teacher Teacher Giáo viên dạy môn học cho một
lớp cụ thể.
Term – Year String 12 Học kỳ và năm học cần lập thời
khóa biểu
♦ Phương thức
- getTeacher(): lấy thông tin giáo viên dạy.
- setTeacher(Teacher:Teacher): gán giáo viên dạy cho môn học.
- setTerm-Year(Term-Year:String): gán học kỳ năm học cho môn học.
4.3.1.6. Lớp thiết kế Class ( Lớp học)

Bảng 21. Các thuộc tính lớp thiết kế Class
ClassID String 4 (C…) Mã lớp
Name String 255 Tên lớp
Time Char [S/C] Buổi học ( sáng hoặc chiều)
arr_Subject Mảng kiểu Bằng số môn Các môn học của lớp trong
Subject-Class từng lớp học học kỳ.

- add(Name:String, Time:String): thêm lớp mới.
- edit(Name:String, Time:String): sửa thông tin lớp.
- del(): xóa lớp học.
- setSubjects(arr_Subject:Subject-Class[]): gán các môn học cho lớp.
- getInfo(): lấy thông tin lớp học
4.3.1.7. Lớp thiết kế Tie_Class ( Lớp có ràng buộc)

Là lớp con thừa kế từ lớp cha Class với mục đích đưa thêm ràng buộc ngày nghỉ
trong tuần vào, có thêm thuộc tính và phương thức:

♦ Thuộc tính
Bảng 22. Thuộc tính thêm lớp con Tie_Class
OffDay Number Integer Ngày nghỉ trong tuần của lớp
♦ Phương thức
- getOffDay(): lấy ngày nghỉ của lớp.
- setOffDay(OffDay:Integer): gán ngày nghỉ cho lớp.
4.3.1.8. Lớp thiết kế Timeable ( Thời khóa biểu)

Bảng 23. Các thuộc tính lớp thiết kế Timeable
arr_Class Mảng kiểu Bằng số lớp học Mảng các lớp học trong
Class trong học kỳ học kỳ
Term-Year String 9 Học kỳ- lớp học

- setTerm-Year(Term-Year:String): gán học kỳ năm học cho thời khóa
biểu.
- setClasses(arr_Class:Class[]): gán các lớp cho thời khóa biểu.
- init(): khởi tạo dữ liệu
- schedule(): hàm chính lập thời khóa biểu.
- checkSatisfy(): phục vụ cho xếp ca học ( xét xem có xếp được hay không).
- cancel(): hủy bỏ việc xếp thời khóa biểu.

Hình 28. Biểu đồ lớp thiết kế
4.3.2. Cấu trúc dữ liệu và thuật toán

Bài toán xếp thời khoá biểu nói riêng và các bài toán tối ưu tổ hợp nói chung là
rất khó giải. Sự khó khăn của chúng được thể hiện ở độ phức tạp tính toán, thời gian
giải thường tăng theo hàm mũ của kích thước bài toán.
Như chúng ta đã biết, trong thuật toán “vét cạn” (tìm kiếm theo bề rộng hoặc
theo độ sâu), về mặt nguyên tắc các phương pháp tìm được nghiệm của bài toán nếu
bài toán có nghiệm, song trên thực tế, những bài toán NP-khó không thể áp dụng được
phương pháp này, vì ta phải phát triển một không gian trạng thái rất lớn, trước khi đi
tới trạng thái đích, mà do những hạn chế về thời gian tính toán và dung lượng bộ nhớ,
không cho phép chúng ta làm được điều đó.
Bài toán xếp thời khóa biểu có thể quy về bài toán giải quyết các ràng buộc chặt
ban đầu và một số ràng buộc mở rộng được thêm vào sau. Với mục đích xây dựng
framework cho bài toán thời khóa biểu yêu cầu thuật toán phải đơn giản, dễ sửa đổi và

mở rộng mỗi khi thêm một ràng buộc mới. Do đó trong khóa luận này chọn phương
pháp heuristic xây dựng thuật toán dựa trên các cảm nhận trực giác và kinh nghiệm khi
xếp thời khóa biểu để giải quyết các ràng buộc.
4.3.2.1. Các ràng buộc của bài toán
♦ Các ràng buộc cơ bản

– Tại một thời điểm, một lớp học chỉ học một môn và một giáo viên chỉ có thể
dạy một lớp.
– Trong một tuần, một môn học chỉ được học một lần, không được phép lặp lại.
Một môn học có thể chia ra thành các ca học nhiều buổi trong tuần nhưng
không nên quá 2 ca và 2 ca cùng môn không được xếp cùng một ngày.
– Các môn học phải được xếp đầy đủ trong tuần.
– Không có tiết trống giữa 2 môn học trong một ngày.
♦ Các ràng buộc mở rộng

– Giáo viên được xếp sao cho số ngày tới trường là ít nhất.
– Lớp học nghỉ vào ngày nào đó trong tuần.
– Hai ca của cùng một môn không học 2 ngày liền nhau trong tuần.
– Số tiết trống giữa các ca dạy trong một ngày của giáo viên không quá 1.
– Giáo viên xin nghỉ vào ngày nào đó trong tuần.
4.3.2.2. Giải quyết các ràng buộc
♦ Tại một thời điểm, một lớp chỉ có thể học một môn học và một giáo viên chỉ
có thể dạy một lớp: để tránh xung đột về thời gian học các môn học của một
lớp, ta sử dụng một ma trận để lưu trữ trạng thái về thời gian. Ma trận cho biết
tại một thời điểm (một tiết trong một ngày trong tuần) một lớp đã xếp lịch hay
chưa, nếu xếp rồi thì đó là môn nào.

Thứ 2 Thứ 3 Thứ 4 Thứ 5 Thứ 6 Thứ 7

Tiết 1
Tiết 2
Tiết 3
Tiết 4
Tiết 5
Tiết 6
Hình 29. Ma trận đánh dấu trạng thái lớp
Mỗi phần tử của ma trận có hai trạng thái: rỗng ( chưa xếp môn học cho lớp)
hay là tên môn học đã xếp. Như vậy có thể dùng một mảng 3 chiều
arr_Trạng_thái_lớp[Số_lớp][6][6] kiểu String để lưu trạng thái của lớp.
Tương tự có thể dùng mảng 3 chiều arr_Trạng_thái_GV[Số_GV][6][12] kiểu
String để lưu trạng thái của giáo viên ( cỡ chiều thứ 3 của mảng bằng 12 là do
đối với giáo viên một ngày có thể đến trường cả 2 buổi sáng chiều).
♦ Một môn học không học quá 2 buổi trong tuần: chia môn học ra thành các ca
học. Một môn học có thể có 1 hay 2 ca trong tuần. Các ca học của các môn khác
nhau sẽ được xếp liền nhau trong ngày.
Bảng 24. Bảng chia môn học các ca học dựa trên số tiết học
Tổng số tiết của môn Số ca Ca 1- Ca 2
1 1 1-0
2 1 2-0
3 1 3-0
4 1 4-0
4 2 2-2
5 2 3-2
6 2 3-3
7 2 4-3
8 2 4-4
♦ Một môn học chỉ học một lần trong tuần: để giải quyết ràng buộc này mỗi
lớp dùng mảng arr_Trạng_thái_ca[Số_ca] kiểu boolean đánh dấu ca học đó đã

được xếp hay chưa. Không xếp những ca đã được đánh dấu và khi xếp xong
một ca chuyển phần tử đánh dấu tương ứng sang trạng thái đã xếp.
♦ Các môn học phải đảm bảo là xếp đủ: sử dụng mảng đánh dấu trạng thái đã
xếp/chưa xếp cho các ca học đối với mỗi lớp có thể biết được môn nào chưa
được xếp. Trường hợp không xếp được đầy đủ các ca học, phải thực hiện thêm
điều chỉnh bằng tay- gắp thả ( trường hợp này rất ít, thử nghiệm chưa dùng tới).
♦ Không có tiết trống giữa các ca học của một lớp trong một ngày: xếp các ca
học liền nhau dựa trên mảng lưu trạng thái lớp.
♦ Giáo viên được xếp sao cho có số ngày đến trường là ít nhất có thể: giải
quyết ràng buộc bằng cách ưu tiên xếp trước cho giáo viên có số ca giảng dạy
trong tuần lớn hơn. Việc ưu tiên này làm cho giáo viên dạy nhiều trong tuần có
lịch tối ưu hơn.
♦ Các ca học cùng một môn ở mỗi lớp không học hai ngày liên tiếp: dựa vào
mảng trạng thái lớp kiểm tra ca định xếp có thỏa mãn không.
♦ Số tiết trống giữa các ca dạy trong một ngày của giáo viên không quá 1:
dựa vào mảng trạng thái giáo viên kiểm tra ca định xếp có thỏa mãn không.
♦ Lớp nghỉ một ngày nào đó trong tuần: khi xếp ca học phải bỏ ngày nghỉ của
lớp.
♦ Giáo viên xin nghỉ dạy vào ngày nào đó trong tuần: khi xếp ca học vào ngày
đó không chọn ca học do giáo viên đó dạy.
4.3.2.3. Thuật toán

– Xếp thời khóa biểu cho từng lớp một và theo trình tự thời gian học trong tuần (
xếp từng ngày trong tuần, từng tiết trong ngày).
♦ Tại một thời điểm duyệt mảng các ca học của lớp đó( đã sắp theo độ ưu tiên là
tổng số tiết mà giáo viên dạy môn đó phải dạy trong tuần), xét một ca học có
thể xếp được hay không ( có thỏa mãn các ràng buộc hay không):

♦ Nếu xếp được ( thỏa mãn): đánh dấu trạng thái lớp, trạng thái giáo viên
đối với khoảng thời gian có ca học vừa xếp rồi tiếp tục tăng chiều thời
gian của thời khóa biểu lớp đó lên xếp tiếp.
♦ Nếu không xếp được ( không thỏa mãn): xét đến ca tiếp theo đến khi tìm
được ca thỏa mãn thì xếp
– Nếu khi xét xong một lớp mà vẫn còn có ca chưa xếp tiến hành xếp lại lớp đó với
một số điều chỉnh :
♦ Mức 1 : xét lại các ca học mà chưa được xếp bỏ bớt các ràng buộc mở rộng .
♦ Mức 2 : xếp lại tất cả các ca học của lớp đó bỏ bớt các ràng buộc mở rộng.
♦ Mức 3: xếp lại sau khi đổi chỗ môn chưa xếp được ( có độ ưu tiên thấp) cho
môn có độ ưu tiên cao ngay trên cho đến khi xếp được.
♦ Số lần xếp lại là giới hạn do có trường hợp không thể xếp được môn học, không
quá số ca học của lớp đó.
4.4. Cài đặt
4.4.1. Công cụ
Các công cụ được sử dụng trong quá trình xây dựng hệ thống:
♦ Công cụ hỗ trợ thiết kế: Rational Rose 2002.
♦ Công cụ lập trình: Visual Studio .Net 2003, ngôn ngữ lập trình VB.Net.
♦ Hệ quản trị cơ sở dữ liệu: Access 2003.
4.4.2. Môi trường triển khai
4.4.2.1. Yêu cầu về phần cứng
♦ CPU Pentium 1,4GHz ; 256MB RAM

4.4.2.2. Yêu cầu về phần mềm
♦ Chương trình chạy trên nền .Net Framework 1.1 và hệ điều hành Windows XP
Pro.
4.4.3. Giao diện chính

Theo trình tự lập thời khóa biểu chương trình gồm các menu: Sửa dữ liệu, Chọn dữ
liệu, Xếp TKB, Xem TKB.
4.4.3.1. Menu Sửa dữ liệu
Hình 30. Giao diện menu Sửa dữ liệu
♦ Gồm các chức năng con chỉnh sửa danh sách chuyên ngành, lớp học, môn học,
giáo viên vào đầu mỗi kỳ hay năm học.

Hình 31. Giao diện chỉnh sửa danh sách chuyên ngành
Trên form có các nút Thêm, Sửa, Xóa chức năng tương ứng với tên nút.
Tương tự cho các giao diện chỉnh sửa danh sách lớp học, môn học, giáo viên.
Hình 32. Giao diện chỉnh sửa danh sách lớp học
Trên form, bên trái là danh sách các lớp học, di chuyển các hàng trên danh sách
thông tin thời gian học sẽ hiện ra tương ứng với lớp vừa chọn ở bên phải. Trên thanh
phía dưới danh sách lớp là các nút để di chuyển tới các lớp trong danh sách: nút << di
chuyển tới lớp đầu tiên trong danh sách, nút < di chuyển tới lớp liền trước lớp đang

chọn, nút > di chuyển tới lớp liền sau lớp đang chọn, nút >> di chuyển tới lớp ở cuối
danh sách.
Tương tự cho các giao diện chỉnh sửa danh sách môn học và giáo viên.
Hình 33. Giao diện chỉnh sửa danh sách môn học.
Hình 34. Giao diện chỉnh sửa danh sách giáo viên

4.4.3.2. Menu Chọn dữ liệu
Hình 35. Giao diện menu Chọn dữ liệu
Theo trình tự thao tác, đầu tiên nhập tên học kỳ và năm học lập thời khóa biểu
từ chức năng con Nhập học kỳ - năm học. Sau đó chọn lớp học, môn học và giáo viên
được phân công cho học kỳ từ các danh sách lớp học, môn học, giáo viên. Cuối cùng
là gán các môn học và giáo viên dạy cho mỗi lớp.
♦ Nhập học kỳ - năm học
Hình 36. Giao diện nhập học kỳ - năm học
♦ Chọn lớp học, môn học, giáo viên

Hình 37. Giao diện chọn lớp học cho học kỳ

Bên trái form là danh sách các lớp. Chọn một hay nhiều lớp từ danh sách này
rồi nhấn vào nút thêm, các lớp được chọn sẽ chuyển sang danh sách lớp đã chọn ở bên
phải form. Muốn loại bỏ một lớp đã chọn, chọn lớp đó từ danh sách lớp đã chọn và
nhấn nút xóa.
Tương tự cho các giao diện chọn môn học và giáo viên
Hình 38. Giao diện chọn môn học cho học kỳ

Hình 39. Giao diện chọn giáo viên giảng dạy cho học kỳ
4.4.3.3. Menu Xếp TKB
Hình 40. Giao diện menu Xếp TKB

Trước khi xếp thời khóa biểu tùy chọn các ràng buộc ngày nghỉ cho lớp và giáo
viên. Nếu các ô Ràng buộc lớp và Ràng buộc GVGD được đánh dấu, các chức năng
nhập ngày nghỉ tương ứng cho lớp và giáo viên giảng dạy sẽ hiện ra cho phép thêm
sửa xóa ngày nghỉ cho lớp và giáo viên.

Hình 41. Giao diện nhập ngày nghỉ lớp học

Trên form, bên trái là danh sách các lớp, chọn lớp và chỉnh sửa ngày nghỉ cho
lớp bằng cách chọn ngày nghỉ trong ô Ngày nghỉ ở bên phải, mỗi lớp chỉ nghỉ tối đa
một ngày trong tuần ( trừ chủ nhật). Các nút Thêm, Sửa, Xóa tương ứng với các chức
năng thêm, sửa, xóa ngày nghỉ của lớp.
Tương tự cho giao diện chỉnh sửa yêu cầu về ngày nghỉ của giáo viên. Khác với
ngày nghỉ của lớp, giáo viên có thể yêu cầu nghỉ nhiều hơn một ngày.
Hình 42. Giao diện nhập ngày nghỉ giáo viên
♦ Xếp thời khóa biểu

Chọn chức năng Xếp TKB, sau đó chờ đến khi hiện ra thông báo Xếp xong
TKB thì việc xếp thời khóa biểu được hoàn thành.
Hình 43. Giao diện thông báo xếp xong thời khóa biểu
♦ Hủy xếp thời khóa biểu

Khi chức năng này được chọn sẽ hiện ra thông báo xác nhận việc hủy bỏ xếp
thời khóa biểu. Nhấn vào No thoát khỏi chức năng, nhấn vào Yes toàn bộ dữ liệu đã
chọn và nhập để lập thời khóa biểu sẽ bị xóa, hủy bỏ việc lập thời khóa biểu.
Hình 44. Xác nhận hủy lập thời khóa biểu
4.4.3.4. Menu Xem TKB
Hình 45. Giao diện menu Xem TKB

Các chức năng con của menu Xem TKB chỉ hiện ra khi việc xếp thời khóa biểu
đã được hoàn thành. Nhấn vào Thời khóa biểu lớp và Thời khóa biểu GVGD để xem
thời khóa biểu cho lớp và cho giáo viên giảng dạy.
Hình 46. Giao diện xem thời khóa biểu theo lớp
Hình 47. Giao diện xem thời lịch dạy giáo viên
4.4.4. Kết quả

Chương trình sau khi được cài đặt và chạy thử nghiệp trên một số bộ dữ liệu
của trường Đại Học Công Nghệ cho kết quả:

4.4.4.1. Về thời gian
Bảng 25. Kết quả chương trình trên một số bộ dữ liệu

Bộ dữ liệu Thời gian chạy
Học kỳ I năm học 2005-2006 (20 lớp) <= 1s
Học kỳ II năm học 2005-2006 (20 lớp) <= 1s
Kết quả về mặt thời gian chạy là khá tốt so với các chương trình sử dụng các
thuật toán vét cạn hay mô phỏng tự nhiên.
4.4.4.2. Về kết quả
♦ Thời khóa biểu lớp: chương trình cho kết quả thời khóa biểu lớp các ca xếp liền
nhau, không có tiết trống ở giữa. Các giờ trống thường là ở cuối buổi học. Ví dụ
thời khóa biểu lớp K49ĐA có số ca học nhiều nhất trong tuần:
Hình 48. Ví dụ kết quả thời khóa biểu lớp
♦ Thời khóa biểu giáo viên: chương trình cho kết quả đối với các giáo viên có số
ca dạy lớn số buổi phải đến trường là khá tốt. Ví dụ lịch dạy của giáo viên dạy
số ca nhiều nhất của môn Giáo dục học đại cương và Logic học đại cương:

Hình 49. Ví dụ kết quả lịch dạy giáo viên 1
Hình 50. Ví dụ kết quả lịch dạy giáo viên 2

KẾT LUẬN
Trong khóa luận này đã vận dụng các công nghệ:
♦ Phân tích thiết kế hướng đối tượng
♦ Lập trình có ràng buộc

để phát triển một hệ thống xếp thời khóa biểu và thử nghiệm với việc thay đổi ràng
buộc rất khả quan. Tốc độ giải nhanh, việc đưa ràng buộc vào đơn giản.
Tuy nhiên do thời gian ngắn, việc thử nghiệm trên các ví dụ thực chưa nhiều.
Việc thay đổi các ràng buộc chưa đủ mức khác biệt, và số lượng ràng buộc thay đổi
còn hạn chế. Thêm nữa, mặc dù thiết kế hệ thống đủ tốt, nhưng chưa đạt đến một
framework như mong muốn.
Hướng nghiên cứu tiếp tục:
♦ Cần thử nghiệm trên nhiều ví dụ khác để hoàn thiện hệ thống và đưa vào
ứng dụng thực tế.
♦ Tiếp tục nghiên cứu, nâng cấp chương trình thành một framework hoàn
thiện để mở rộng phạm vi ứng dụng và tăng tính tiện dụng của chương
trình.

TÀI LIỆU THAM KHẢO
Tài liệu tham khảo tiếng Việt
[1] Nguyễn Việt Hùng, Nguyễn Văn Tuân - Xây dựng thời khóa biểu bằng cách kết
hợp phương pháp Heuristics và tương tác người máy - Khóa luận tốt nghiệp đại học
2005, Đại học Công nghệ - ĐHQGHN.
[2] Vũ Văn Thạch - Ứng dụng khung làm việc cho bài toán lập lịch - Khóa luận tốt
nghiệp đại học 2005, Đại học Công nghệ - ĐHQGHN
[3] PGS.TS. Nguyễn Văn Vỵ - Bài giảng Phân tích thiết kế hệ thống phần mềm theo
hướng đối tượng - Bộ môn Công nghệ phần mềm, Đại học Công nghệ - ĐHQGHN, Hà
Nội, 2004. 109 tr.
Tài liệu tham khảo tiếng Anh
[4] Michael Boggs, Wendy Boggs - Mastering UML With Rational Rose 2002 - Sybex.
[5] Desmond Francis D’Souza, Alan Cameron Wills - Objects, Components, and
Frameworks with UML - Addison Wesley, 1999.
[6] Anneke Kleppe, Jos Warmer - Object Constraint Languate, The: Getting Your
Models Ready for MDA, Second Edition - Addision Wesley, 2003.
[7] Niklas Landin, Axel Niklasson- Development of Object- Oriented Frameworks -
Department Of Communicaiton Systems Lund Institute of Technology, Lund
University Lund, Sweden.
[8] J.Riel - Object- Oriented Design Heuristics - Addision Wesley, 1996.
[9] Alan Wills - Frameworks and component-based development-
http://www.trireme.com

ỨNG DỤNG FRAMEWORK VÀ LẬP TRÌNH RÀNG

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ỨNG DỤNG FRAMEWORK VÀ LẬP TRÌNH RÀNG

Uploaded by

Copyright:

Available Formats

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ỨNG DỤNG FRAMEWORK VÀ LẬP TRÌNH RÀNG

KHÓA LUẬN TỐT NGHIỆP HỆ ĐẠI HỌC CHÍNH QUY

Ngành: Công nghệ thông tin

ỨNG DỤNG FRAMEWORK VÀ LẬP TRÌNH RÀNG

KHÓA LUẬN TỐT NGHIỆP HỆ ĐẠI HỌC CHÍNH QUY

Cán bộ hướng dẫn: PGS.Ts. Nguyễn Văn Vỵ

Đỗ Huy Thịnh Trang - ii -

Đỗ Huy Thịnh Trang - iii -

Đỗ Huy Thịnh Trang - iv -

Đỗ Huy Thịnh Trang - v -

Đỗ Huy Thịnh Trang - vi -

Đỗ Huy Thịnh Trang - vii -

Đỗ Huy Thịnh Trang - viii -

Đỗ Huy Thịnh Trang - 1 -

Bài toán lập Thời khóa biểu

1.1.2. Phân loại bài toán xếp thời khóa biểu.

a. Theo loại khuôn dạng thời gian Thời khóa biểu.

♦ Thời khóa biểu TUẦN

♦ Thời khóa biểu HỌC KỲ

♦ Thời khóa biểu 2 ( nhiều) TUẦN / HỌC KỲ

Đỗ Huy Thịnh Trang - 2 -

♦ Thời khóa biểu THÁNG ( NĂM HỌC)

b. Phân loại theo đơn vị xếp Thời khóa biểu

Đỗ Huy Thịnh Trang - 3 -

♦ Các lớp học không có tiết trống ở giữa.

♦ Số buổi lên lớp của giáo viên giảng dạy là ít nhất.

Đỗ Huy Thịnh Trang - 4 -

1.2.1. Hoạt động nghiệp vụ

1.2.1.3. Phân công giảng dạy ( lớp- môn- giáo viên)

1.2.1.4. Lên danh sách các phòng học

1.2.1.5. Lập thời khóa biểu

Đỗ Huy Thịnh Trang - 5 -

Số chức năng Chức năng

Đỗ Huy Thịnh Trang - 6 -

1.2.3. Từ điển dữ liệu và mô hình lĩnh vực nghiệp vụ

1.2.3.1. Từ điển dữ liệu

Bảng 2. Từ điển dữ liệu

STT Thuật ngữ Giải thích

English Tiếng Việt

2 Teacher Giáo viên

3 Subject Môn học

14 Classroom Giảng đường Địa điểm học tập

Đỗ Huy Thịnh Trang - 7 -

1.2.3.2. Mô hình lĩnh vực nghiệp vụ

Đỗ Huy Thịnh Trang - 8 -

Ngôn ngữ ràng buộc đối tượng

Hình 2. Ví dụ mô hình UML không biểu diễn hết đặc tả

Đỗ Huy Thịnh Trang - 9 -

2.2. Đặc điểm OCL

2.2.1. Cả truy vấn và ngôn ngữ ràng buộc

Đỗ Huy Thịnh Trang - 10 -

2.2.3. Ngôn ngữ định nghĩa kiểu

2.2.4. Ngôn ngữ khai báo

2.3. Bài toán L&R

Đỗ Huy Thịnh Trang - 11 -

Hình 3. Mô hình hệ thống chương trình Loyalty

Đỗ Huy Thịnh Trang - 12 -

2.4. Ngữ cảnh của các biểu thức OCL

Đỗ Huy Thịnh Trang - 13 -

2.4.1.1. Ngữ cảnh của một biểu thức OCL

Hình 4. Định nghĩa ngữ cảnh trong mô hình UML

Đỗ Huy Thịnh Trang - 14 -