Bài giảng Phân tích và thiết kế hệ thống - Chương 6: Domain Model - Lược đồ lớp và Đối tượng của hệ thống - Trần Thị Kim Chi

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCMKHOA CÔNG NGHỆ THÔNG TINDOMAIN MODELLƯỢC ĐỒ LỚP &ĐỐI TƯỢNG CỦA HỆ THỐNGChương VNỘI DUNGCác khái niệm về lược đồ lớpMô hình lớp miền (Domain Model)Nhận diện lớpNhận diện quan hệ Association, aggregation, generalizationXây dựng lược đồ lớp bằng cách hiện thực use caseThiết lập các packageTổng quan về phân tích Use CaseSupplementarySpecificationsGlossaryUse-CaseAnalysisProject Specific GuidelinesUse-Case RealizationAnalysis ModelUse-Case ModelAnalysis ClassesSoftware ArchitectureDocumentKhái niệm mô hình tĩnhMô hình đối tượng định nghĩa hệ thống theo khái niệm các thành phần tĩnh. Mô hình đối tượng miêu tả ứng xử mang tính cấu trúc và chức năng của các lớp.Tiếp cận xây dựng lược đồ lớp phân tíchHai tiếp cận chính để xây dựng lược đồ lớp:Domain Model: iterative ‘traditional’ approach:Xây dựng lược đồ lớp từ tri thức về miền ứng dụng Mô hình các khái niệm, sự vật quan trọng trong miền ứng dụng và quan hệ ràng buộc giữa chúngUse-case analysis: Use case driven approachIdentify boundary, control, entity classes needed for each use caseConsolidate into analysis model for application as a wholeDomain Model (Mô hình miền)Phân hoạch và mô tả các sự vật và các khái niệm quan trọng trong miền ứng dụng.Hoạt động phân tích hướng đối tượng cổ điển.Mô hình lớp phân tích độc lập với các use case cụ thểKhông biểu diễn các đối tượng phần mềm mà là tự điển trực quan về các khái niệm quan trọng của miền.UML Class Diagram7Là mô hình chính để phân tích yêu cầuCloseRegistrationForm+ open()+ close registration()Student+ get tuition()+ add schedule()+ get schedule()+ delete schedule()+ has pre-requisites()Schedule- semester+ commit()+ select alternate()+ remove offering()+ level()+ cancel()+ get cost()+ delete()+ submit()+ save()+ any conflicts?()+ create with offerings()+ update with new selections()Professor- name- employeeID : UniqueId- hireDate- status- discipline- maxLoad+ submitFinalGrade()+ acceptCourseOffering()+ setMaxLoad()+ takeSabbatical()+ teachClass()CloseRegistrationController+ is registration open?()+ close registration()Class Diagram UsageWhen modeling the static view of a system, class diagrams are typically used in one of three ways, to model:The vocabulary of a systemCollaborationsA logical database schemaRepresenting Classes and Objects in the UMLProfessor- name- employeeID : UniqueId- hireDate- status- discipline- maxLoad+ submitFinalGrade()+ acceptCourseOffering()+ setMaxLoad()+ takeSabbatical()+ teachClass()class nameattributesoperationsClassJ Clark : Professor : ProfessorNamed ObjectAnonymous ObjectObjectĐỐI TƯỢNG - OBJECTĐối tượng (Object):Mô hình đối tượng quan niệm thế giới bao gồm các đối tượng(object) sinh sống và tương tác với nhau.Đối tượng bao gồm:Dữ liệu: mang một giá trị nhất địnhTác vụ: thực hiện một công việc nào đóVD:ĐỐI TƯỢNG - OBJECTMargaret:date of birth: 1980/03/03position: TellerTransaction 487:amount: 200.00time: 2001/09/01 14:30Greg:date of birth: 1970/01/01address: 75 Object Dr.Mortgage Account 29865:balance: 198760.00opened: 2000/08/12property: 75 Object Dr.Instant Teller 876:location: Java Valley CafeSavings Account 12876:balance: 1976.32opened: 1997/03/03Jane:date of birth: 1955/02/02position: Manageraddress: 99 UML St.address: 150 C++ Rd.ĐỐI TƯỢNG - OBJECTDựa vào đặc tả của từng use case để tìm kiếm các đối tượngCác đối tượng thường xuất hiện trong các danh từ hay nhóm danh từMột số lưu ý:Đối tượng/lớp phải thật sự cần thiết cho sự hoạt động của hệ thốngĐối tượng/lớp tương ứng với bảng cơ sở dữ liệuĐối tượng/lớp tương ứng với actor.ĐỐI TƯỢNG - OBJECTPhân loại đối tượng/lớp:Đối tượng thực thể(entity): biểu diễn các thông tin cần thiết của hệ thống, có thể được lưu trong cơ sở dữ liệuĐối tượng biên (boundary): thực hiện chức năng giao tiếp với actorĐối tượng điều khiển (control): điều khiển các đối tượng khác.LỚP - CLASSLớp là sự mô tả những thuộc tính và những hành vi của một hay nhiều đối tượng trong hệ thống của bạn. Một đối tượng là một thể hiện của một lớp.Personnameageweight(Person)(Person)Joe Smithage=39weight=158Mary Wilsonage=27weight=121LỚP - CLASSDescribes a group of objects with common:Properties (attributes)Behavior (operations)RelationshipsSemanticsClass NameAttributesOperationsProfessornameProfessorId : UniqueIdcreate()save()delete()change()CẤU TRÚC LỚP - CLASSBiểu diễn lớp trong UML:Tên> Thuộc tínhTác vụStereotype cho lớp:>>>Đối tượng cũng được biểu diễn bằng các stereotype thông thường gồm 2 phần:Tên đối tượng + tên lớp (được gạch chân), giá trị các thuộc tính(trạng thái của đối tượng)VÍ DỤ LỚP - CLASSBiểu diễn lớp trong UML:Class nameData members(attributes)Instance methodsArgumentsReturn typesClass method (static)PHÂN LOẠI LỚPLớp biên (bourndary class)Lớp thực thể (entity class)Lớp điều khiển (control class)PHÂN LOẠI LỚPUse CasesAnalysisClassesSourceCodeExecDesignElementsUse-Case AnalysisPHÂN TÍCH LỚP – ANALYSIS CLASSTìm kiếm các lớp từ Use case behavior: toàn bộ hành vi của Use case phải được phân bổ về cho các analysis classLỚP GIAO DIỆN -BOUNDARY CLASSThực hiện chức năng giao tiếp với actorThường chứa các phần tử giao diện hoặc điều khiển giao diện người dùng( button, listbox, option group, menu)Khó nhận biết các thuộc tính và tác vụ trong mô hình phân tíchVí dụ: đối với hệ thống quản lý thư viện, các đối tượng biên như: TheMuonForm, BanDocForm, Form_DangNhapLỚP GIAO DIỆN -BOUNDARY CLASSLà lớp trung gian giữa giao diện và hệ thống bên ngoàiPhân loạiUser interface classesSystem interface classes Device interface classesTrong UML được gán stereotype là >Một boundary class cho 1 cặp actor/use caseLỚP GIAO DIỆN -BOUNDARY CLASSLưu trữ và quản trị các thông tin trong systemActor 1Actor 2>>>>>LỚP GIAO DIỆN -BOUNDARY CLASSExample: Finding Boundary ClassesLỚP GIAO DIỆN -BOUNDARY CLASSCác User Interface ClassTập trung vào những thông tin gì được thể hiện cho người dùngKhông tập trung vào các chi tiết UI Các System và Device Interface ClassTập trung vào những protocol nào phải định nghĩaKhông tập trung vào cách mà các protocol sẽ được cài đặtTập trung vào các nhiệm vụ, chứ không phải chi tiết!LỚP THỰC THỂ - ENTITY CLASSBiểu diễn cho các thực thể xuất hiện một cách tự nhiên trong hệ thốngThông tin về các đối tượng thực thể có thể phải được lưu trữ lâu dài (database,file)Trong UML được gán stereotype là >Dễ nhận diện các thuộc tính của chúngVí dụ: đối với hệ thống quản lý thư viện đã mô tả ở phần trước, nhận diện các đối tượng thực thể như:Sách, Bạn đọc, Thẻ mượn, Thủ thư.Là sự trừu tượng hóa chính của hệ thốngGlossaryBusiness-Domain ModelEnvironment independent.Analysis class stereotypeUse CaseArchitectural Analysis AbstractionsLỚP THỰC THỂ - ENTITY CLASSVai trò lớp thực thểStore and manage information in the system.Actor 1>>>>>Actor 2LỚP THỰC THỂ - ENTITY CLASSCách tìm lớp thực thểDựa vào các dòng sự kiện của use casePhương pháp lọc danh từGạch dưới các mệnh đề danh từLoại bỏ các danh từ dư thừaLoại bỏ các danh từ mơ hồLoại bỏ actor (ngoài phạm vi)Loại bỏ các kiến trúc cài đặtLoại bỏ thuộc tính Loại bỏ phương thức operationLỚP THỰC THỂ - ENTITY CLASSRegister for Courses (Create Schedule)StudentScheduleCourseOfferingLỚP THỰC THỂ - ENTITY CLASSRegister for Courses (Create Schedule)LỚP THỰC THỂ - ENTITY CLASSLỚP ĐIỀU KHIỂN – CONTROL CLASSCó nhiệm vụ điều khiển các lớp khác Trong UML, được gán stereotype là >Lớp biên thường có quan hệ liên kết hoặc phụ thuộc với các lớp khácDùng điều phối hành vi use caseUse case phức tạp sẽ yêu cầu nhiều hơn một lớp điều khiểnVAI TRÒ LỚP ĐIỀU KHIỂNCoordinate the use-case behavior.Actor 1>>>>>Actor 2ĐỐI TƯỢNG/LỚP ĐIỀU KHIỂNCách tìm lớp điều khiểnNguyên tắc chung: cần 1 lớp điều khiển cho mỗi use case. Khi tiêp tục phân tích, lớp điều khiển của use case phức có thể phát triển thành nhiều hơn 1 lớpExample: Summary: Analysis ClassesStudentCourse Catalog SystemRegister for CoursesUse-Case ModelDesign ModelRegisterForCoursesFormCourseCatalogSystemStudentScheduleCourseOfferingRegistrationControllerExample: Summary: Analysis ClassesPhân phối hành vi use case vào các lớpĐối với dòng sự kiện của mỗi use case: Xác định các lớp phân tíchPhân phối hành vi của use case vào các lớp phân tíchMô hình hóa sự tương tác của các lớp phân tích trong lược đồ tương tác (Interaction diagrams)Cách phân phối trách nhiệm cho các lớpVới lớp BoundaryCác hành vi liên quan đến giao tiếp với actorVới lớp EntityCác hành vi liên quan đến dữ liệuVới lớp ControlCác hành vi xác định use case hay một phần dòng sự kiện quan trọngCách phân phối trách nhiệm cho các lớpAi có dữ liệu cần cho việc thực hiện nhiệm vụ?Một class có dữ liệu, hãy để nhiệm vụ cùng với dữ liệuNhiều class có dữ liệu :Hãy để nhiệm vụ trong 1 class và thêm quan hệ với các class khác.Tạo một class mới, để nhiệm vụ trong class mới này, và thêm quan hệ với các class cũHãy để nhiệm vụ trong control class, và thêm quan hệ với các class cần để thực hiện nhiệm vụVí dụ lớp Example 1Ví dụ về các lớp trong doanh nghiệp và các hệ thống thông tin: Khách hàng Bản hợp đồng Hóa đơn Món nợ Tài sản Bản công bố giá cổ phiếu Ví dụ lớp Example 2Các lớp trong một hệ thống kỹ thuật thường bao gồm các đối tượng kỹ thuật, ví dụ như máy móc được sử dụng trong hệ thống: Sensor Màn hình I/O card Động cơ Nút bấm Lớp điều khiểnVí dụ lớp Example 3Các hệ thống phần mềm thường có các lớp đại diện cho các thực thể phần mềm trong một hệ điều hành: File Chương trình chạy được Trang thiết bị Icon Cửa sổ Thanh kéoTHUỘC TÍNH CỦA LỚPThuộc tính: mô tả cấu trúc của 1 lớp, là một vùng có thể chứa dữ liệu (đơn hoặc tổ hợp) của lớpDữ liệu mà thuộc tính thể hiện nằm trong một khoảng giá trị nào đó được xác định bởi kiểu dữ liệu.Thuộc tính có thể bị che dấu hoặc truy xuất được từ bên ngoài: public, protected, privateTHUỘC TÍNH CỦA LỚPBiểu diễn thuộc tínhChỉ ra tên, kiểu và giá trị mặc định nếu có attributeName : Type = Default Tuân theo quy ước đặt tên của ngôn ngữ cài đặt và của dự án. Kiểu (type) nên là kiểu dữ liệu cơ bản trong ngôn ngữ thực thi: integer, float, double, long, char, string, date, timeKiểu dữ liệu có sẵn, kiểu dữ liệu người dùng định nghĩa, hoặc lớp tự định nghĩa. UML cho phép định nghĩa tất cả kiểu dữ liệu trên.NHẬN DIỆN THUỘC TÍNHDựa vào đặc tả của từng use case, tìm kiếm các danh từ hoặc nhóm danh từ liên quan đến đối tượng đang xétTrả lời câu hỏi: những thành phần nào cấu thành đối tượng đang xét?Lưu ý: cùng một đối tượng trong các ngữ cảnh khác nhau chúng ta có thể tìm được các thuộc tính khác nhau.Nên xác định (không bắt buộc) trong mô hình phân tích:Kiểu của thuộc tính: một số kiểu cơ bảnBậc của thuộc tính: số ít hoặc số nhiềuVisibility của thuộc tính: mức độ cho phép truy xuất thuộc tính từ bên ngoàiTrường hợp thuộc tính được miêu tả thông qua quan hệ với các lớp khác: UML cho phép thể hiện bậc trên quan hệ (ví dụ: 1,0,*,2..9,0..n)MỨC ĐỘ TRUY XUẤT THUỘC TÍNHCó 3 mức độ truy xuất thuộc tính:Public (+): có thể truy xuất thuộc tính từ tất cả các vị trí khác nhauProtected (#): bản thân lớp đang xét Private(-) : chỉ có lớp đang xét có thể truy xuất Thông thưong nên đặt mức độ truy xuất thuộc tính là private hoặc protected(cho các lớp cơ sở), không nên là public. Thuộc tính nên được truy xuất thông qua tác vụ get,set.MỨC ĐỘ TRUY XUẤT THUỘC TÍNHCác thuộc tính tiêu biểu Các thuộc tính chung (+) và riêng (-)Các thuộc tính chung và riêng Các thuộc tính với gía trị mặc nhiên và thuộc tính phạm vi lớp Một thuộc tính với liệt kê gía trị (status) NHẬN DIỆN TÁC VỤ (OPERATION)Ứng xử chung chia sẻ cho tất cả các đối tượng của lớpDịch vụ mà các đối tượng có thể cung cấp cho đối tượng khácHành động mà một đối tượng có thể thực hiện:Đọc hay ghi các giá trị thuộc tínhThực hiện các tính toánGởi messages tới đối tượng khácTạo hoặc hủy các liên kết với đối tượng khácStudent+ get tuition()+ add schedule()+ get schedule()+ delete schedule()+ has prerequisites()NHẬN DIỆN TÁC VỤ (OPERATION)Tác vụ (operation) Là một dịch vụ có thể yêu cầu từ phía đối tượng để thực hiện hành viDấu hiệu nhận dạng của tác vụ (signature) xác định các thông số truyền cũng như kết quả trả về.Phương thức (method) là phần hiện thực của tác vụTác vụ có thể bị che dấu hoặc truy xuất từ bên ngoàiTác vụ có thể được override trong các lớp con thừa kếTrừu tượng(abstract): không có hiện thựcMột số ngôn ngữ lập trình cho phép định nghĩa: Tác vụ khởi tạo(constructor)Tác vụ hủy (destructor)NHẬN DIỆN TÁC VỤ (OPERATION)OperationscompartmentCác giá trị mặc nhiên của tham số Dựa vào đặc tả của từng use case, tìm kiếm các động từ hoặc nhóm động từ liên quan đến đối tượng đang xétChú ý xem đối tượng được tạo ra và hủy bỏ như thế nào? Trong thời gian đó nó gửi/nhận thông điệp ra sao?Các đối tượng biên có các tác vụ nhận lệnh từ actorXem xét mức độ truy xuất của các tác vụ tương tự như đối với các thuộc tính; các tác vụ thường có visibility là + hoặc #Một số tác vụ không xuất hiện một cách tự nhiên trong mô hình phân tích  mô hình thiết kế sẽ nghiên cứu trách nhiệm và hành vi của từng đối tượngNHẬN DIỆN TÁC VỤ (OPERATION)Khi thiết kế operation signatures phải bảo đảm hàm chứa:Các tham số truyền theo giá trị hay tham số?Các tham số có bị thay đổi bởi operation?Các tham số là optional?Các tham số có giá trị mặc định?Miền tham số hợp lệ?Càng ít tham số càng tốtTruyền các object thay vì “data bits”Những gì cần xem xét:Các thuật toán đặc biệtCác object và các operation khác cần sử dụngCách cài đặt và cách sử dụng các attribute và các tham sốCách cài đặt và sử dụng các mỗi quan hệThiết kế Operation SignaturesBÀI TẬPWhich of the following items do you think should be a class, and which should be an instance? For any item which should be an instance, name a suitable class for it.General Motors b) Automoible companyStudent d) Computer Science StudentMary Smith f) GameBoard Game h) ChessCar j) Mazda carThe game of chess between Tom and Jane which started at 2:30pm yesterdayThe car with serial number DL 2C 7151BÀI TẬPIdentify the attributes that might be present in the following classes. Try to be reasonably exhaustive.PassengerRoomPhone CallBÀI TẬPWhich of the following are variables, and which are objects?Jim Smith, a passenger on flight 101Jim Smith’s addressThe reference to the object representing Jim SmithQUAN HỆ - RELATIONSHIPQuan hệ giữa các lớp gồm có bốn loại: Association Aggregation Composition Generalization Dependency RealizationORORORLink - kết nối giữa các đối tượng57net1_05:CourseOfferingnet2_05:CourseOfferingdat_05:CourseOfferingNetwork Basic:CourseDatabase:CourseLà một thể hiện của một association giữa các lớp.Nếu 2 đối tượng có liên kết thì các lớp tương ứng của chúng sẽ có mối kết hợpKết nối nhằm tạo dễ dàng cho việc truyền messageMối liên hệ ngữ nghĩa giữa hai hay nhiều lớp chỉ ra sự liên kết giữa các thể hiện của chúng Mối quan hệ về mặt cấu trúc chỉ ra các đối tượng của lớp này có kết nối với các đối tượng của lớp khác. LIÊN HỆ (ASSOCIATION)LIÊN HỆ (ASSOCIATION)Countryname(Country)CanadaCitynamehas-capital(City)Ottawahas-capital(Country)France(City)Parishas-capital(Country)Austria(City)Viennahas-capitalClass diagramObject diagramMối liên hệ ngữ nghĩa giữa các thể hiện (instances) của các classLIÊN HỆ (ASSOCIATION)LIÊN HỆ (ASSOCIATION)PerformResponsibility LinkAssociationCommunication DiagramClass Diagram0..*0..*ClientSupplier:Client:SupplierClientSupplierPerformResponsibility()Relationship for every link!LIÊN HỆ (ASSOCIATION)Vai trò trong liên hệ: Các vai trò được nối với mỗi lớp bao chứa trong quan hệ. Vai trò của một lớp là chức năng mà nó đảm nhận nhìn từ góc nhìn của lớp kia. Tên vai trò được viết kèm với một mũi tên chỉ từ hướng lớp chủ nhân ra, thể hiện lớp này đóng vai trò như thế nào đối với lớp mà mũi tên chỉ đến. Vai trò trong liên hệ giữa Customer và Account LIÊN HỆ (ASSOCIATION)Vai trò trong liên hệ: “Nhân vật” mà một class”đóng vai trong associationLIÊN HỆ (ASSOCIATION)Multiplicity –Bản số trong liên hệ: Bản số quan hệ là số lượng thể hiện của một lớp liên quan tới MỘT thể hiện của lớp khác. Với mỗi liên kết, có hai bản số quan hệ cho hai đầu của liên kết. Định nghĩa có bao nhiêu đối tượng tham gia vào quan hệ1 – Mặc định0 .. 1 * – n .. m – Điều kiện n >Schedule>CourseOffering1-way navigation11>RegisterForCoursesForm>RegistrationControllerLIÊN HỆ (ASSOCIATION)Một sơ đồ lớp tiêu biểu LIÊN HỆ (ASSOCIATION)RegisterForCoursesForm>CourseOffering>Schedule>0..*primaryCourses0..4Student>0..*1RegistrationController>110..1currentSchedule0..1Aggregation là một dạng đặc biệt của association dùng để mô hình mối quan hệ whole-partLà mối quan hệ “Is a part-of”.Ký hiệu:Có 2 dạng:Chia sẻ: chia sẻ giữa các bao gộp khác nhauHoàn toàn (composite): sở hữu đầy đủQUAN HỆ BAO GỘP (Aggregation) Aggregation là một dạng đặc biệt của liên kết mô hình hóa mối quan hệ toàn thể-bộ phận (whole-part) giữa đối tượng toàn thể và các bộ phận của nó. Kết tập là mối quan hệ “là một phần” (“is a part-of”). Bản số quan hệ được biểu diễn giống như các liên kết khác QUAN HỆ BAO GỘP (Aggregation) QUAN HỆ BAO GỘP (Aggregation) QUAN HỆ BAO GỘP (Aggregation) Whole/aggregatepart0..40..2primaryCoursesalternateCourses0..*0..*0..*1>Student>Schedule>CourseOfferingQUAN HỆ BAO GỘP (Aggregation) Khi nghi ngờ, sử dụng associationNếu hai đối tượng đang bị ràng buộc chặt chẽ bởi một mối quan hệ toàn phầnThe relationship is an aggregation.Nếu hai đối tượng thường được coi là độc lập, mặc dù chúng thường được liên kếtThe relationship is an association.CarDoor0..2,41CarDoor0..2,41QUAN HỆ BAO GỘP (Aggregation) Bốn ngữ nghĩa có thể của AggregationSở hữu độc quyền (Exclusive Owns): Book has ChapterCó sự phụ thuộc tồn tại (không có chapter nếu không có book)Không chia sẻLà thuộc tính cố định (một chapter không thể chuyển sang book khác)Sở hữu (Owns): Car has TireKhông chia sẻKhông là thuộc tính cố định (có thể chuyển tire sang một car khác)Có (Has): Department has StudentKhông có sự phụ thuộc tồn tại, có thể chia sẻ.Thành viên (Member): Meeting has ChairpersonKhông có đặc trưng gì đặc biệt ngoại trừ là tư cách thành viênMột dạng của kết tập với quyền sở hữu mạnh và các vòng đời trùng khớp giữa hai lớp Whole sở hữu Part, tạo và hủy Part. Part bị bỏ đi khi Whole bị bỏ, Part không thể tồn tại nếu Whole không tồn tại. QUAN HỆ CẤU THÀNH(Composition) QUAN HỆ BAO GỘP (Aggregation) Aggregation cơ bản là bất kỳ quan hệ whole–partNgữ nghĩa có thể rất mơ hồTương ứng với ngữ nghĩa "Has" và "Member".Một đối tượng thành phần (part) có thể thuộc nhiều hơn một đối tượng bao gồm (whole) Composition là Aggregation mạnh hơnTại một thời điểm, mỗi đối tượng thành phần (part) chỉ có thể thuộc chỉ một đối tượng bao gồm (whole).Có sự phụ thuộc tồn tại từ "part" vào "whole"Khi đối tượng "whole" bị hủy thì các "part" cũng bị hủyTương ứngQUAN HỆ BAO GỘP (Aggregation) Quan hệ m*n có thể chấp nhậnQuan hệ m*n không được phépCác Student có thể trong nhiều CourseOffering.Nếu CourseOffering bị hủy, các Student không bị hủy!Nếu Book bị xóa, các chương (Chapter) trong Book cũng bị xóa!Aggregation – University and Chancellor Nếu không có trường Đại học (University), hiệu trưởng (Chancellor) không thể tồn tại. Nếu không có Chancellor, University vẫn có thể tồn tại Composition – University and Faculty University không thể tồn tại nếu không có các giảng viên (Faculty) và ngược lại (share time-life) Thời gian sống của University gắn chặt với thời gian sống của Faculty Nếu Faculties được giải phóng thì University không thể tồn tại và ngược lại Ví dụ – Aggregration vs. Composition Một class “được gắn” vào một associationChứa các thuộc tính của relationshipMột thể hiện / 1 linkAssociation ClassScheduleOfferingInfostatus// mark as selected()// mark as cancelled()// is selected?()>CourseOffering>Schedule>0..*0..4primaryCoursesalternateCourses0..*0..2PrimaryScheduleOfferingInfobgrade// is enrolled in?()// mark as enrolled in()// mark as committed()>Mối quan hệ giữa các lớp (r