Ứ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

Đỗ Huy Thịnh Trang - ii -

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

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

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

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

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

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

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

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.

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

4 Teacher-subject Giao viên – môn học Giáo viên dạy tương ứng với môn học

5 Curriculum Chương trình đào tạo(CTĐT)

6 Degree Hệ đào tạo Bao gồm hệ chính qui, tại chức, tập trung hay từ xa…

7 Semester Học kỳ

8 Timetable Thời khóa biểu Lịch học cho các lớp trong trường, khoa

9 SubjectClass Môn học – lớp Các môn học tương ứng với lớp

10 Training bureau staff

Nhân viên phòng Đào Tạo

Người phụ trách quản lí giảng dạy và học tập

11 Training bureau Phòng Đào Tạo Phụ trách các vấn đề về giảng dạy và học tập

12 Bureau of administration

Phòng hành chính tổng hợp

13 Department Bộ phận

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

15 Priority Ưu tiên, ràng buộc Yêu cầu đặt ra khi lập thời 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: context CustomerCard 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: context CustomerCard inv: self.owner.dateOfBirth.isBefore( Date::now ) context CustomerCard 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 tác)

X - X -



last() - X - X

prepend( đối tượng) - X - X

subOrderedSet( lower, upper) - X - -

subSequence( lower, upper) - - - X

symmetricDifference( 2 đối tượng cộng tác)

X - - -

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 thức)

trả lại tập các tập hợp 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.

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

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.

class Shape -move() //thi hành -draw() //ảo

class Circle -draw() //thi hành

class Square -draw() //thi hành



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,…).

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

Observation

Stock Meter

Subject [value/level]

Observer [view_value/reading]



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.

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.

value value_view

Cập nhật

Subject Observer

Các vai trò được nắm giữ bởi phần này của mỗi đối tượng

Phần này của đối tượng liên quan đến sự cộng tác và không được biết đến

Phần này của đối tượng liên quan đến sự cộng tác Subject-Observer

Biến nội tại liên quan đến cả hai phần

Phần còn lại của đối tượng



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.



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ả

<value> <value_view>

Register

subject observers

update

0,1 0..*

<Subject> <Observer>

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()]]

Mẫu thiết kế quan sá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ả.

Hình 14. Mô hình kiểu đích cho việc sử dụng sự quan sát

Hình 15. Ví dụ ứng dụng khung làm việc và sự thay thế

addCall (c : Call)

post calls = calls @ pre + c

getCall ( ) : Call

post result = calls @ pre->head

& calls = calls @ pre->tail

temperature : int other stuff about Thermometers

Thermometer

CallCallQueue calls

0..* {seq}

CallQueue

Call

Thermometer

reading

Observation

Subject [value\calls->size] Observer

[value_view\reading]

0..* calls



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.

addCall (c : Call)

post calls = calls @

pre + c

& [[observers.update (

)]]

getCall ( ) : Call

post result = calls @

pre->head

& calls = calls @ pre-

>tail

& [[observers.update (

)]]

CallQueue

reading other stuff about Thermometers

Thermometer

Call calls

0..* {seq}

subject observers

0,1 0..*

update

register

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 độ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).



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

depletion (p:Product)

stock( product): int lowLimit( product):int

<Trader>

<Distributor >

stock( product): int lowLimit( product):int

<Sản phẩmt> Ngày

<Order> Từ

đang nợ *

Các hoá đơn

Tới *

Cho *

0,1 Đã phân phối *

Yêu cầu cung cấp hàng cho kinh doanh

inv Trader:: ( p:Product:: stock (p) < lowLimit(p)orders[for=p] <> 0 )



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



Hình 18. Sự cộng tác Trade Supply

depletion (p:Product)

stock( product): int lowLimit( product): int

<Trader> <Distributor >

stock( product): int lowLimit( product): int

<Product> Date

<Order >

Tạo hóa đơn

Phân phối

Trả

Từ

Chưa trả

* Các hoá đơn

Tới *

Cung cấp hàng cho kinh doanh

Cho *

0,1 Đã phân phối

*

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) ]]

<depletion (p:Product)>



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 :

Hình 19. Làm tài liệu sự làm mịn khung làm việc

Yêu cầu cung cấp hàng cho

Cung cấp hàng cho kinh

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)]]

• depletion(p) post stock(p)

<lowLimit(p) => [[makeOrder(p)]]

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 học

2. Hiện form điều chỉnh danh sách lớp học Danh sách các lớp

3. Xác định các lớp học cho học kỳ

4. Thể hiện danh sách các 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


♦ Luồng sự kiện: Bảng 11. Bảng luồng sự kiện ca sử dụng lập danh sách môn 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

5. Chọn chức năng lập danh sách các môn học cho lớp

6. Hiện form điều chỉnh danh sách môn học cho từng lớp tương ứng

Danh sách môn học Danh sách lớp- học kỳ

7. Chọn lớp và chọn môn tương ứng

8. Hiện danh sách các môn học tương ứng với lớp đã chọn

Danh sách môn học - lớp

9. Chỉnh sửa danh sách

10. Chỉnh sửa danh và lưu lại




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


♦ Luồng sự kiện: 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

Hành động của tác nhân Phản ứng của hệ thống Dữ liệu liên quan 11. Chọn chức năng lập

danh sách giáo viên giảng dạy

12. Hiện form điều chỉnh danh sách giáo viên giảng dạy

13. Xác định các giáo viên giảng dạy cho học kỳ tiếp theo

14. Thể hiện danh sách các giáo viên giảng dạy đã được chọn, cập nhật danh sách vào cơ sở dữ 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)




♦ Luồng sự kiện: 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

Hành động của tác nhân Phản ứng của hệ thống Dữ liệu liên quan 15. Chọn chức năng

xác định giáo viên giảng dạy cho các môn học

16. Hiện form điều chỉnh giáo viên giảng dạy cho các môn học của từng lớp


17. Xác định giáo viên giảng dạy cho các môn học của từng lớp

18. Thể hiện danh sách các môn học và các giáo viên giảng dạy tương ứng của từng lớp, và cập nhật vào cơ sở dữ liệu

Danh sách giáo viên, 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.


♦ Luồng sự kiện: 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

Xem, cập nhật các ràng buộc Cập nhật thông tin và ghi nhận

Danh sách Ràng 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.


♦ Luồng sự kiện: Bảng 15. Bảng luồng sự kiện ca sử dụng lập thời khóa biểu


19. Chọn chức năng lập thời khóa biểu

20. Xử lí và hiện ra kết quả có được

Danh sách môn - lớp - Giáo viên, Danh sách ràng buộc, thời khóa biểu.

21. Chọn lớp học 22. Hiện thời khóa biểu của

lớp học Danh sách lớp - học kỳ, Thời khóa biểu.

23. Chọn giáo viên giảng dạy

24. Hiện thời khóa biểu của giáo viên giảng dạy

Danh sách Giáo viên, Thời khóa 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:

: NhanVienPDT : frmDS_Lop : LapDS_Lop-HocKy

: DS_Lop

: DS_Lop - HocKy

1: LenDS_Lop 2: LapDS

3: LayThongTin

4: TaoMoi

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 :

: NhanVienPDT : frmDS_MonHoc : LapDS_MonHoc

: DS_MonHoc

: DS_MonHoc - HocKy

1: LapDS_MonHoc 2: ThucHien3: LayThongTin

4: TaoMoi

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ỳ

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

: NhanVienPDT : frmDS_GiaoVien : LapDS_GiaoVien

: DS_GiaoVien

: DS_GiaoVien- HocKy

1: LapDS_GiangVien 2: ThucHien

3: LayThongTin

4: TaoMoi

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ỳ



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




: NhanVienPDT : frm_Lop-Mon : LapDS_Lop- Mon

: DS_Lop - HocKy

: DS_MonHoc - HocKy

: DS_Lop- MonHoc

1: XacDinhMon- Lop 2: ThucHien

3: LayThongTin

4: LayThongTin

5: TaoMoi

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.


: NhanVienPDT : frmDS_Lop-Mon-GV : LapDS_Lop-Mon-GV : DS_GiaoVien- HocKy

: DS_Lop- MonHoc

: DS_Lop- MonHoc- GiaoVien

1: LapDS_Lop-Mon-GV2: ThucHien

3: LayThongTin

4: LayThongTin

5: TaoMoi

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.


: NhanVienPDT : LapDS_RangBuoc

: DS_RangBuoc

: frmDS_RangBuoc

: RangBuoc1: LapDS_RangBuoc 2: ThucHien

3: TaoMoi

4: LayThongTin

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.


: NhanVienPDT : frmLapTKB : LapTKB

: DS_Lop- MonHoc- GiaoVien

: ThoiKhoaBieu

: DS_RangBuoc

1: LapTKB 2: ThucHien

3: TaoMoi

4: LayThongTin

5: LayThongTin

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)

♦ Các thuộc tính 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

♦ Các phương thức - 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)

♦ Các thuộc tính 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

♦ Các phương thứ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)

♦ Các thuộc tính 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 Subject-Class

Bằng số môn từng lớp học

Các môn học của lớp trong học kỳ.

♦ Các phương thức - 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)

♦ Các thuộc tính Bảng 23. Các thuộc tính lớp thiết kế Timeable


arr_Class Mảng kiểu Class

Bằng số lớp học trong học kỳ

Mảng các lớp học trong học kỳ

Term-Year String 9 Học kỳ- lớp học

♦ Các phương thứ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

Documents