Bài giảng Thiết kế hệ thống thông tin - Chương V: Dinamic Model-Lược đồ lớp & đối tượng của hệ thống

Nội dung text: Bài giảng Thiết kế hệ thống thông tin - Chương V: Dinamic Model-Lược đồ lớp & đối tượng của hệ thống

1. TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM KHOA CÔNG NGHỆ THÔNG TIN Chương V
2. NỘI DUNG • Các khái niệm về lược đồ lớp • Mô hình lớp miền (Domain Model) – Nhận diện lớp – Nhận diện quan hệ Association, aggregation, generalization • Xây dựng lược đồ lớp bằng cách hiện thực use case • Thiết lập các package
3. Tổng quan về phân tích Use Case Project Specific Software Use-Case Realization Glossary Guidelines Architecture Document Use-Case Supplementary Analysis Specifications Analysis Model Use-Case Model Analysis Classes
4. Khái niệm mô hình tĩnh Mô 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.
5. Tiếp cận xây dựng lược đồ lớp phân tích Hai tiếp cận chính để xây dựng lược đồ lớp: 1. 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úng 2. Use-case analysis: Use case driven approach – Identify boundary, control, entity classes needed for each use case – Consolidate into analysis model for application as a whole
6. Domain 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.
7. UML Class Diagram • Là mô hình chính để phân tích yêu cầu CloseRegistrationForm Schedule CloseRegistrationController - semester + open() + is registration open?() + close registration() + commit() + close registration() + select alternate() + remove offering() + level() Professor + cancel() - name Student + get cost() - employeeID : UniqueId + delete() - hireDate + submit() - status + get tuition() + save() - discipline + add schedule() + any conflicts?() - maxLoad + get schedule() + create with offerings() + delete schedule() + update with new selections() + submitFinalGrade() + has pre-requisites() + acceptCourseOffering() + setMaxLoad() + takeSabbatical() + teachClass() 7
8. Class Diagram Usage • When modeling the static view of a system, class diagrams are typically used in one of three ways, to model: – The vocabulary of a system – Collaborations – A logical database schema
9. Representing Classes and Objects in the UML class Professor J Clark : - name Professor name - employeeID : UniqueId - hireDate attribute - status Named Object s - discipline - maxLoad + submitFinalGrade() : Professor operatio + acceptCourseOffering() ns + setMaxLoad() + takeSabbatical() Anonymous Object + teachClass() Class Object
10. ĐỐ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 định – Tác vụ: thực hiện một công việc nào đó • VD:
11. ĐỐI TƯỢNG - OBJECT Jane: date of birth: 1955/02/02 address: 99 UML St. position: Manager Savings Account 12876: Greg: balance: 1976.32 date of birth: 1970/01/01 opened: 1997/03/03 address: 75 Object Dr. Margaret: date of birth: 1980/03/03 Mortgage Account 29865: address: 150 C++ Rd. position: Teller balance: 198760.00 opened: 2000/08/12 property: 75 Object Dr. Transaction 487: amount: 200.00 time: 2001/09/01 14:30 Instant Teller 876: location: Java Valley Cafe
12. ĐỐI TƯỢNG - OBJECT • Dựa vào đặc tả của từng use case để tìm kiếm các đối tượng • Cá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.
13. ĐỐI TƯỢNG - OBJECT • Phâ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.
14. LỚP - CLASS • Lớ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. (Person) Person Joe Smith name age=39 age weight=158 weight (Person) Mary Wilson age=27 weight=121
15. LỚP - CLASS • Describes a group of objects with common: – Properties (attributes) – Behavior (operations) – Relationships – Semantics Class Name Professor name Attributes ProfessorId : UniqueId create() Operations save() delete() change()
16. CẤU TRÚC LỚP - CLASS • Biểu diễn lớp trong UML: Stereotype cho lớp: Tên > - > - > - > Thuộc tính • Đố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 Tác vụ gạch chân), giá trị các thuộc tính(trạng thái của đối tượng)
17. VÍ DỤ LỚP - CLASS • Biểu diễn lớp trong UML: name Class name -x: double Data members-y: double (attributes) -z: double -n: int Instance methods+name() +method1(:double):double +method2():bool +classMethod() Class method (static) Return types Arguments
18. PHÂN LOẠI LỚP • Lớp biên (bourndary class) • Lớp thực thể (entity class) • Lớp điều khiển (control class)
19. PHÂN LOẠI LỚP Use Cases Analysis Design Source Exec Classes Elements Code Use-Case Analysis
20. PHÂN TÍCH LỚP – ANALYSIS CLASS • Tì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 class
21. LỚP GIAO DIỆN -BOUNDARY CLASS • Thực hiện chức năng giao tiếp với actor • Thườ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ích • Ví dụ: đối với hệ thống quản lý thư viện, các đối tượng biên như: TheMuonForm, BanDocForm, Form_DangNhap
22. LỚP GIAO DIỆN -BOUNDARY CLASS • Là lớp trung gian giữa giao diện và hệ thống bên ngoài • Phân loại – User interface classes – System interface classes – Device interface classes • Trong UML được gán stereotype là > • Một boundary class cho 1 cặp actor/use case
23. LỚP GIAO DIỆN -BOUNDARY CLASS > > > Actor 1 Actor 2 > > Lưu trữ và quản trị các thông tin trong system
24. LỚP GIAO DIỆN -BOUNDARY CLASS • Example: Finding Boundary Classes
25. LỚP GIAO DIỆN -BOUNDARY CLASS Các User Interface Class • Tập trung vào những thông tin gì được thể hiện cho người dùng • Không tập trung vào các chi tiết UI Các System và Device Interface Class • Tập trung vào những protocol nào phải định nghĩa • Không tập trung vào cách mà các protocol sẽ được cài đặt Tập trung vào các nhiệm vụ, chứ không phải chi tiết!
26. LỚP THỰC THỂ - ENTITY CLASS • Biểu diễn cho các thực thể xuất hiện một cách tự nhiên trong hệ thống • Thô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úng • Ví 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ư.
27. LỚP THỰC THỂ - ENTITY CLASS • Là sự trừu tượng hóa chính của hệ thống Analysis class stereotype Business-Domain Use Case Model Architectural Analysis Abstractions Glossary Environment independent.
28. LỚP THỰC THỂ - ENTITY CLASS • Vai trò lớp thực thể > > > Actor 1 Actor 2 > > Store and manage information in the system.
29. LỚP THỰC THỂ - ENTITY CLASS Cách tìm lớp thực thể • Dựa vào các dòng sự kiện của use case • Phươ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ừa – Loạ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 đặt – Loại bỏ thuộc tính – Loại bỏ phương thức operation
30. LỚP THỰC THỂ - ENTITY CLASS • Register for Courses (Create Schedule) CourseOffering Schedule Student
31. LỚP THỰC THỂ - ENTITY CLASS Register for Courses (Create Schedule)
32. LỚP ĐIỀU KHIỂN – CONTROL CLASS • Có 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ác • Dùng điều phối hành vi use case • Use case phức tạp sẽ yêu cầu nhiều hơn một lớp điều khiển
33. VAI TRÒ LỚP ĐIỀU KHIỂN > > > Actor 1 Actor 2 > > Coordinate the use-case behavior.
34. ĐỐI TƯỢNG/LỚP ĐIỀU KHIỂN Cách tìm lớp điều khiển • Nguyê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ớp
35. Example: Summary: Analysis Classes Student Register for Courses Course Catalog System Use-Case Model Design Model RegisterForCoursesForm CourseCatalogSystem Student Schedule CourseOffering RegistrationController
36. Example: Summary: Analysis Classes
37. Phâ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ích • Phân phối hành vi của use case vào các lớp phân tích • Mô 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)
38. Cách phân phối trách nhiệm cho các lớp • Với lớp Boundary – Các hành vi liên quan đến giao tiếp với actor • Với lớp Entity – Các hành vi liên quan đến dữ liệu • Với lớp Control – Các hành vi xác định use case hay một phần dòng sự kiện quan trọng
39. Cách phân phối trách nhiệm cho các lớp • Ai 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ệu – Nhiề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ụ
40. Ví dụ lớp Example 1 • Ví 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
41. Ví dụ lớp Example 2 • Cá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ển
42. Ví dụ lớp Example 3 • Cá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éo
43. THUỘC TÍNH CỦA LỚP Thuộ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ớp Dữ 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, private
44. THUỘC TÍNH CỦA LỚP Biểu diễn thuộc tính • Chỉ 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, time • Kiể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.
45. NHẬN DIỆN THUỘC TÍNH • Dự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ét • Trả 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ản – Bậc của thuộc tính: số ít hoặc số nhiều – Visibility của thuộc tính: mức độ cho phép truy xuất thuộc tính từ bên ngoài • Trườ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)
46. MỨC ĐỘ TRUY XUẤT THUỘC TÍNH • Có 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 nhau – Protected (#): 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.
47. MỨC ĐỘ TRUY XUẤT THUỘC TÍNH Các thuộc tính Các thuộc tính Các thuộc tính tiêu biểu chung (+) và riêng (-) chung và riêng Các thuộc tính với gía trị mặc Một thuộc tính với liệt kê gía trị (status) nhiên và thuộc tính phạm vi lớp
48. 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ớp Dịch vụ mà các đối tượng có thể Student cung cấp cho đối tượng khác + get tuition() Hành động mà một đối tượng có thể + add schedule() thực hiện: + get schedule() + delete schedule() Đọc hay ghi các giá trị thuộc tính + has prerequisites() Thực hiện các tính toán Gởi messages tới đối tượng khác Tạo hoặc hủy các liên kết với đối tượng khác
49. 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 vi Dấ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ài Tá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ực Mộ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)
50. NHẬN DIỆN TÁC VỤ (OPERATION) Operations compartment Các giá trị mặc nhiên của tham số
51. NHẬN DIỆN TÁC VỤ (OPERATION) • 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ét • Chú ý 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ừ actor • Xem 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ượng
52. Thiết kế Operation Signatures • 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ốt • Truyền các object thay vì “data bits” • Những gì cần xem xét: – Các thuật toán đặc biệt – Các object và các operation khác cần sử dụng – Cá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ệ
53. BÀI TẬP • Which 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. a) General Motors b) Automoible company c) Student d) Computer Science Student e) Mary Smith f) Game g) Board Game h) Chess i) Car j) Mazda car k) The game of chess between Tom and Jane which started at 2:30pm yesterday l) The car with serial number DL 2C 7151
54. BÀI TẬP Identify the attributes that might be present in the following classes. Try to be reasonably exhaustive. a) Passenger b) Room c) Phone Call
55. BÀI TẬP Which of the following are variables, and which are objects? a) Jim Smith, a passenger on flight 101 b) Jim Smith’s address c) The reference to the object representing Jim Smith
56. QUAN HỆ - RELATIONSHIP Quan hệ giữa các lớp gồm có bốn loại: ❖ Association OR ❖ Aggregation OR ❖ Composition OR ❖ Generalization ❖ Dependency ❖ Realization
57. Link - kết nối giữa các đối tượng • Là 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ợp • Kết nối nhằm tạo dễ dàng cho việc truyền message net2_05:CourseOffering net1_05:CourseOffering Network Basic:Course dat_05:CourseOffering Database:Course 57
58. LIÊN HỆ (ASSOCIATION) • Mố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.
59. LIÊN HỆ (ASSOCIATION) Country has-capital City Class diagram name name (Country) has-capital (City) Canada Ottawa (Country) has-capital (City) Object diagram France Paris (Country) has-capital (City) Austria Vienna
60. LIÊN HỆ (ASSOCIATION) • Mối liên hệ ngữ nghĩa giữa các thể hiện (instances) của các class
61. LIÊN HỆ (ASSOCIATION) Communication Diagram PerformResponsibility :Client :Supplier Link Client Supplier Class Diagram Client 0 * 0 * Supplier PerformResponsibility() Association Relationship for every link!
62. 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
63. LIÊN HỆ (ASSOCIATION) Vai trò trong liên hệ: • “Nhân vật” mà một class”đóng vai trong association
64. LIÊ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 định – 0 1 – * – – n m – Điều kiện n < m Số lượng trong liên hệ giữa Customer và Account
65. LIÊN HỆ (ASSOCIATION) Unspecified Exactly One 1 Zero or More 0 * Zero or More * One or More 1 * Zero or One (optional scalar role) 0 1 Specified Range 2 4 Multiple, Disjoint Ranges 2, 4 6
66. LIÊN HỆ (ASSOCIATION)
67. LIÊN HỆ (ASSOCIATION) • Bi-directional: – both classes are aware of each other and their relationship • Liên hệ một chiều (Uni-Directional Association): – two classes are related, but only one class knows that the relationship exists Một chiều Class1 Class2
68. LIÊN HỆ (ASSOCIATION) > 1 1 > RegisterForCoursesForm RegistrationController 1-way navigation 0 * 0 4 > primaryCourses > Schedule 0 * 0 2 CourseOffering alternateCourses 2-way navigation
69. LIÊN HỆ (ASSOCIATION) Một sơ đồ lớp tiêu biểu
70. LIÊN HỆ (ASSOCIATION) > > RegisterForCoursesForm RegistrationController 1 1 0 1 currentSchedule 0 1 > > > primaryCourses Student Schedule CourseOffering 1 0 * 0 * 0 4
71. QUAN HỆ BAO GỘP (Aggregation) • Aggregation là một dạng đặc biệt của association dùng để mô hình mối quan hệ whole-part • Là 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 nhau – Hoàn toàn (composite): sở hữu đầy đủ
72. 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
73. QUAN HỆ BAO GỘP (Aggregation)
74. QUAN HỆ BAO GỘP (Aggregation) Whole/aggregate part > > 0 * 0 4 1 0 * Student Schedule primaryCourses > 0 * 0 2 CourseOffering alternateCourses
75. QUAN HỆ BAO GỘP (Aggregation) • Nế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. Car Door 1 0 2,4 • 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. Car Door 1 0 2,4 Khi nghi ngờ, sử dụng association
76. QUAN HỆ BAO GỘP (Aggregation) Bốn ngữ nghĩa có thể của Aggregation • Sở hữu độc quyền (Exclusive Owns): Book has Chapter – Có 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 Tire – Khô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 Student – Không có sự phụ thuộc tồn tại, có thể chia sẻ. • Thành viên (Member): Meeting has Chairperson – Không có đặc trưng gì đặc biệt ngoại trừ là tư cách thành viên
77. QUAN HỆ CẤU THÀNH(Composition) • Mộ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.
78. QUAN HỆ BAO GỘP (Aggregation) • Aggregation cơ bản là bất kỳ quan hệ whole–part – Ngữ 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ơn – Tạ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ủy – Tương ứng
79. QUAN HỆ BAO GỘP (Aggregation) Quan hệ m*n có thể chấp nhận Các Student có thể trong nhiều CourseOffering Student CourseOffering. 1 * 0 * Nếu CourseOffering bị hủy, các Student không bị hủy! Quan hệ m*n không được phép Nếu Book bị xóa, các Book Chapter chương (Chapter) trong 1 1 * Book cũng bị xóa!
80. Ví dụ – Aggregration vs. Composition 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
81. Association Class • Một class “được gắn” vào một association • Chứa các thuộc tính của relationship > • Một thể hiện / 1 link ScheduleOfferingInfo status // mark as selected() // mark as cancelled() // is selected?() alternateCourses 0 * 0 2 > > Schedule CourseOffering 0 * primaryCourses 0 4 > PrimaryScheduleOfferingInfob grade // is enrolled in?() // mark as enrolled in() // mark as committed()
82. Mối quan hệ giữa các lớp (relationship) • Liên kết (Association) Sử dụng (use-a) • Kết tập (Aggregation) Strong association has-a/is-a-part • Hợp thành (Composition) Strong aggregation Share life-time
83. Mối quan hệ giữa các lớp (relationship)
84. Mối quan hệ giữa các lớp (relationship)
85. TỔNG QUÁT HÓA (GENERALIZATION) • Mối quan hệ giữa các lớp Account trong đó một lớp chia sẻ cấu balance trúc và/hoặc hành vi với một Superclass name number hoặc nhiều lớp khác (parent) Withdraw() • Xác định sự phân cấp về mức CreateStatement() độ trừu tượng hóa trong đó lớp con kế thừa từ một hoặc Generalizatio nhiều lớp cha n Relationship – Đơn kế thừa (Single inheritance) Checking Savings – Đa kế thừa (Multiple Subclasses inheritance) Withdraw() GetInterest() Withdraw() • Là mối liên hệ “là một loại” (“is a kind of”) Subtype – Sub class
86. TỔNG QUÁT HÓA (GENERALIZATION) Stock Savings Checking Tổng quát hơn Bond RealEstate Asset BankAccount Security RealEstate Savings Checking Stock Bond Dặn lớp cô Hương đi thi giữa kỳ lúc 12 g30 cả lớp luôn
87. TỔNG QUÁT HÓA (GENERALIZATION) Asset Asset BankAccount Security RealEstate Savings Checking Stock Bond Chuyên biệt hơn
88. TỔNG QUÁT HÓA (GENERALIZATION) Part-timeStudent Full-timeStudent Không có sự name name address address tổng quát hóa studentID studentID numberCourses gradDate Student name Có sự tổng quát address hóa studentID FulltimeStudent ParttimeStudent gradDate maxNumCourses
89. TỔNG QUÁT HÓA (GENERALIZATION) • Mục đích – Xác định các khả năng dùng lại – Tinh chỉnh cây kế thừa để có thể dễ dàng cài đặt • Những gì cần xem xét: – So sánh Abstract classes (không có thể hiện) với concrete classes (bất kỳ thể hiện nào) – Bài toán đa kế thừa – So sánh Generalization và Aggregation – Tổng quát hóa để hỗ trợ tái sử dụng trong cài đặt – Tổng quát hóa để hỗ trợ đa xạ (polymorphism) – Tổng quát hóa để hỗ trợ đa hình (metamorphosis) – Mô phỏng tổng quát hóa Subtype – Sub class
90. TỔNG QUÁT HÓA (GENERALIZATION)
91. TỔNG QUÁT HÓA (GENERALIZATION)
92. Lớp trừu tượng và lớp cụ thể (Abstract and Concrete Class) Lớp trừu tượng không thể có đối tượng ▫ Chứa phương thức trừu tượng ▫ Chữ nghiêng • Lớp cụ thể có thể có đối tượng
93. Polymorphism là gì? Khả năng che giấu các thực thi khác nhau dưới một giao diện duy nhất.
94. Polymorphism là gì?
95. Quan hệ Dependency – Phụ thuộc • Là một sự liên quan ngữ nghĩa giữa hai phần tử mô hình, một mang tính độc lập và một mang tính phụ thuộc. Mọi sự thay đổi trong phần tử độc lập sẽ ảnh hưởng đến phần tử phụ thuộc. Phần tử mô hình ở đây có thể là một lớp, một gói (package), một trường hợp sử dụng, .v.v Client Supplier
96. Mối quan hệ giữa các lớp (relationship)
97. Mối quan hệ giữa các lớp (relationship)
98. Domain Modeling Phát hiện lớp miền
99. BIỂU ĐỒ LỚP • Biểu đồ lớp chỉ ra sự tồn tại của các lớp và mối quan hệ giữa chúng trong bản thiết kế logic của một hệ thống – Chỉ ra cấu trúc tĩnh của mô hình như lớp, cấu trúc bên trong của chúng và mối quan hệ với các lớp khác. – Chỉ ra tất cả hoặc một phần cấu trúc lớp của một hệ thống. – Không đưa ra các thông tin tạm thời. • Khung nhìn tĩnh của một hệ thống chủ yếu hỗ trợ các yêu cầu chức năng của hệ thống.
100. BIỂU ĐỒ LỚP
101. BIỂU ĐỒ LỚP
102. XÂY DỰNG BIỂU ĐỒ LỚP • Biểu diễn cấu trúc của một số lớp và quan hệ giữa chúng → Mô tả khía cạnh tĩnh của hệ thống. • Hệ thống phức tạp có nhiều lớp → cần xây dựng nhiều lược đồ lớp, mỗi lược đồ mô tả một phần của hệ thống • Lược đồ lớp được bổ sung và hoàn thiện trong mô hình thiết kế (thêm một số lớp, chi tiết thuộc tính tác vụ, làm rõ các quan hệ)
103. Phát hiện lớp miền (Key Abstraction) • Từ các danh từ trong phát biểu bài toán – Tài liệu yêu cầu phải đầy đủ và đúng. • Là một phát biểu có mục đích • Miêu tả cho một tập các đối tượng (nhiều hơn 1) – Không xét các lớp chỉ có một thể hiện (Singleton) • Sở hữu một tập các thuộc tính – Thuộc tính định danh: chỉ xem xét nếu có ý nghĩa thực tế. • Sở hữu một tập các phép toán – Phép toán có thể nhận diện sau
104. Kiểm tra tính hợp lý của các lớp ứng viên • Nó có nằm ngoài phạm vi của hệ thống không? • Nó có ám chỉ tới toàn bộ hệ thống không? • Nó có lập lại một lớp khác không? • Nó có quá mơ hồ không? • Nó có buộc quá chặt với inputs và outputs vật lý không? • Nó có là một thuộc tính hay không? • Nó có là một mối kết hợp hay không? Nếu câu trả lời là "Yes", – Mô hình lớp theo một cách khác hoặc loại bỏ lớp đó
105. Nhận diện quan hệ • Từ các động từ biểu diễn các quy định nghiệp vụ (business rules) trong phát biểu bài toán • Tránh các chu trình trong quan hệ – có thể có ý nghĩa giống nhau register 0 * 0 * CourseOffering Student Schedule primaryCourses 1 0 * 0 * 0 4
106. Ví dụ: Hệ thống đăng ký học phần Course CourseOffering - credits - number Professor preRequisites - name offer - startTime teach instructor - professorId - curriculum - endTime - name 0 n - description 1 0 n - days 0 n 0 1 - number /- numStudents 0 n 0 2 0 4 alternateCourses primaryCourses PrimaryScheduleOfferingInfob - grade 0 n 0 n Student - name has Schedule - address - semester - studentID 1 0 n
107. Bài tập Class Diagram “FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.”
108. Bài tập Class Diagram • Out-of-Domain • Good Candidates – Internal Web – employee • Abstract – item (was office supplies) – user name – receipt – user password – order – account number – order database – order number – error message – ship date • Notes – total cost We have decided not to worry – list of supplies about the Web in this design. – office supplies -> item Instead we focus on the inputs and outputs and defer the Web details until later.
109. Bài tập Class Diagram employee order order DB name number password account total cost error message receipt item explanation order number name ship date quantity total cost price
110. Bài tập Class Diagram Since both receipts and error messages will be generated as output it might make sense to have them as subclasses of a more general class. We do not know enough yet to assign it attributes however. response error message receipt explanation order number ship date total cost
111. Bài tập Class Diagram employee order order DB name number password account total cost 1+ error message receipt item explanation order number name ship date quantity total cost price
112. Bài tập Class Diagram • Draw a class diagram for an information modeling system for a university. – University has one or more Departments. – Department offers one or more Classes. – A particular class will be offered by only one department. – Department has instructors and instructors can work for one or more departments. – Student can enroll in up to 5 classes in a University. – Instructors can teach up to 3 classes. – The same class can be taught by different instructors. – Students can be enrolled in more than one university.
113. Bài tập Class Diagram – University has one or more Departments. University Department 1 has 1 * – Department offers one or more Classes. – A particular class will be offered by only one department. Department Class 1 offers 1 *
114. Bài tập Class Diagram – Department has Instructors and instructors can work for one or more departments. Instructor Department 1 * assigned to 1 * – Student can enroll in up to 5 Classes. Student Class * takes 0 5
115. Bài tập Class Diagram – Instructors can teach up to 3 classes. – The same class can be taught by different instructors. Instructor Class 1 * teaches 1 3
116. Bài tập Class Diagram – Students can be enrolled in more than one school. Student University * member 1 *
117. Bài tập Class Diagram has University Department 1 1 * 1 * 1 * 1 offers assignedTo member * 1 * 1 * attends teaches Student Class Instructor * 1 5 1 3 1 *
118. Bài tập Class Diagram Owner Vehicle + firstName : string + weight : int - myVehicles - myOwner + lastName : string + topSpeed : int 0 * 1 + phoneNumber : string + VIN : string + getOwner ( ) + contactOwner ( [in] message : string ) : bool + getName ( ) : string Car + modelType : string Motorcycle + maxPassengers : int - wheels Wheel + modelType : string + addRepairNote ( [in] note : string ) : bool 2 + maxMileage : int - wheels 4
119. Mô tả cơ chế phân tích • Tập hợp tất cả cơ chế phân tích trong danh sách • Ánh xạ lớp với các cơ chế phân tích • Xác định các tính chất của cơ chế phân tích
120. Ví dụ: Mô tả cơ chế phân tích
121. Ví dụ: Mô tả cơ chế phân tích Cơ chế Persistency đối với lớp Schedule class: • Granularity: 1 to 10 Kbytes per product • Volume: up to 2,000 schedules • Access frequency • Create: 500 per day • Read: 2,000 access per hour • Update: 1,000 per day • Delete: 50 per day • Other characteristics
122. Hợp nhất các lớp phân tích • Mỗi use case khi hiện thực hóa sẽ cho ra 1 lược đồ lớp khác nhau • Loại bỏ các lớp trùng lặp từ các lược đồ lớp khác nhau
123. Đánh giá kết quả Course RegisterFor RegisterFor Registration Catalog CoursesForm CoursesForm System Controller Registration Controller Student Register for Student Courses Course Offering Course Schedule Offering Course CloseRegistration Course Catalog Schedule Form Catalog System System Close CloseRegistration Registration Billing Controller System CloseRegistration Student Controller Billing CloseRegistration Course System Form Offering Schedule
124. Đánh giá kết quả
125. Câu hỏi • Các class có hợp lý không? • Tên của các class có phản ánh đúng vai trò của chúng? • Class có biểu diễn 1 single well-defined abstraction? • Tất cả các attribute và responsibility có gắn kết với nhau về mặt chức năng không? • Class có cung cấp các hành vi được y/c? • Tất cả các yêu cầu cụ thể đã được thể hiện trên class chưa?
126. Câu hỏi • Tất cả các luồng chính và luồng con đã được điều khiển chưa, bao gồm cả các trường hợp ngoài lệ? • Đã tìm thấy tất cả các đối tượng cần thiết? • Đã phân phối một cách rõ ràng tất cả các hành vi về các đối tượng chưa? • Các hành vi có được phân phối về đúng đối tượng không? • Các interaction diagrams nằm ở đâu, mối quan hê gwiax chúng có rõ ràng và phù hợp không?
127. Câu hỏi • Mục tiêu của Use-Case Analysis là gì? • Một analysis class là gì? Cho biết tên và mô tả về 3 analysis stereotype. • Use-case realization là gì? • Mô tả một vài hoạt động khảo sát when đặt các trách nhiệm cho các analysis class. • Bao nhiêu interaction diagram phải được xây dựng trong giai đoạn Use-Case Analysis?
128. Câu hỏi • Hãy cho biết các khái niệm sau: – Các Requirements artifact, đặc biệt là đặc tả bổ sung – Các cơ chế phân tích có thể – Các flow of events interaction diagram cho một use case cụ thể • Với mỗi use case hãy xác định các dữ kiện sau: – Các thuộc tính và các mối quan hệ của Analysis class – Các cơ chế phân tích Analysis class • Xây dựng các lược đồ sau: – VOPC class diagram, chứa các analysis class, stereotype của chúng, nhiệm vụ, các attribute, và relationship. – Ánh xạ Analysis class với các cơ chế phân tích
129. THIẾT LẬP CÁC PACKAGE • Package là một cơ chế để tổ chức các phần tử vào nhóm có quan hệ ngữ nghĩa với nhau • Package có thể import các phần tử từ một package khác • Có thể chỉ ra quan hệ giữa các package – Phụ thuộc – Tổng quát hóa • Mức độ truy xuất của package – Private: chỉ nó và các package import nó có thể truy xuất nội dung – Protected: giống như các private nhưng cho phép thêm các package dẫn xuất – Public: các package khác có thể truy xuất nội dung – Implementation: không cho phép import, có thể áp dụng các phẩn tử bên trong package
130. THIẾT LẬP CÁC PACKAGE
131. THIẾT LẬP CÁC PACKAGE
132. THIẾT LẬP CÁC PACKAGE
133. NHẬN DIỆN THÊM MỘT SỐ LỚP THIẾT KẾ • Một số lớp khác xuất hiện làm chức năng duyệt (iterate) một lớp khác hay thực hiện các tính toán phức tạp • Sử dụng trực tiếp các lớp do thư viện hay ngôn ngữ cung cấp, hoặc tạo ra lớp mới bằng cách thừa kế hay tích hợp lớp có sẵn, ví dụ: CArray • Bổ sung các lớp mới vào lược đồ lớp đồng thời cập nhật các mối quan hệ mới(bao gộp, phụ thuộc)
134. ĐẶC TẢ CHI TIẾT CÁC THUỘC TÍNH • Trong mô hình phân tích cần chỉ rõ kiểu (hoặc cấu trúc dữ liệu) và mức độ truy xuất các thuộc tính • Có thể chọn một lớp cung cấp bởi thư viện lập trình để cụ thể hóa kiểu hay cấu trúc dữ liệu → bổ sung lớp của thư viện và quan hệ bao gộp vào lược đồ lớp.
135. NHÂN DIỆN CHÍNH XÁC CÁC TÁC VỤ • Các lược đồ mô tả hành vi(cộng tác, tuần tự, trạng thái, hành động) giúp nhận diện chính xác các tác vụ của các lớp • Dựa vào thông điệp hay hành động để xác định signature của các tác vụ • VD:
136. HOÀN CHỈNH LƯỢC ĐỒ LỚP • Cập nhật các lớp mới, thuộc tính, tác vụ và mối quan hệ mới • UML định nghĩa quan hệ phụ thuộc (dependency) giữa 2 lớp hoặc package: thay đổi ở một lớp, package kéo theo thay đổi ở lớp kia • Ký hiệu: • Một số stereotype quy ước trước >, >, >, >, >, >, >
137. HOÀN CHỈNH LƯỢC ĐỒ LỚP • VD thêm lược đồ lớp cho hệ thống đăng ký môn học
138. HOÀN CHỈNH LƯỢC ĐỒ LỚP • VD thêm lược đồ lớp cho hệ thống đăng ký môn học
139. Review 1. Hỏi: Khi tạo dựng mô hình, cần sử dụng các khái niệm của chính phạm vi vấn đề để mô hình dễ hiểu và dễ giao tiếp. Đáp: Đúng 2. Hỏi: Các lớp chỉ thể hiện cấu trúc thông tin? Đáp: sai, các lớp không phải chỉ thể hiện cấu trúc thông tin mà còn mô tả cả hành vi. 3. Hỏi: Các khái niệm then chốt thường sẽ trở thành các lớp trong mô hình phân tích? Đáp: Đúng 4. Hỏi: Thường các danh từ trong các lời phát biểu bài toán sẽ là ứng cử viên để chuyển thành lớp và đối tượng? Đáp: Đúng 139