Hệ thống thông tin - Chương 2: Các khái niệm cơ bản trong hướng đối tượng

Nội dung text: Hệ thống thông tin - Chương 2: Các khái niệm cơ bản trong hướng đối tượng

1. TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP TP.HCM KHOA CÔNG NGHỆ THÔNG TIN Chương II Trần Thị Kim Chi 1
2. NỘI DUNG 2.1. Tổng quan về phân tích thiết kế hướng đối tượng OOAD (Object-Oriented Analysis and Design) 2.2. Các đặc trưng của phương pháp hướng đối tượng 2.3. Giới thiệu về hướng đối tượng: Object và class, các đặc trưng của class: kế thừa, đóng gói và đa hình 2.4. Unified Modeling Language (UML) 2.5. Tiến trình RUP Trần Thị Kim Chi 2
3. TỔNG QUAN VỀ OOAD • Mô hình hướng đối tượng giới thiệu một quan điểm lập trình và phân tích/thiết kế khác hẳn so với trường phái cổ điển (có cấu trúc) • Bắt đầu nhen nhóm vào những năm cuối 60s và đến đầu 90s trở nên rất phổ biến trong công nghiệp phần mềm • Những ngôn ngữ hướng đối tượng đầu tiên: Smalltalk, Eiffel. Sau đó xuất hiện thêm: Object Pascal, C++, Java • Hình thành các phương pháp phân tích/thiết kế hướng đối tượng. Trần Thị Kim Chi 3
4. TỔNG QUAN VỀ OOAD • Chiến lược phát triển phần mềm hướng đối tượng là quan sát thế giới thực như tập các đối tượng • Các tính chất của đối tuợng – Ðối tượng có thể là • thực thể nhìn thấy được trong thế giới thực (trong pha phân tích yêu cầu) • biểu diễn thực thể hệ thống (trong pha thiết kế) – Ðối tượng có trách nhiệm quản lý trạng thái của mình, cung cấp dịch vụ cho đối tượng khác khi có yêu cầu dữ liệu và hàm cùng gói trong đối tượng • Chức năng hệ thống: các dịch vụ được yêu cầu và cung cấp như thế nào giữa các đối tượng, không quan tâm đến thay đổi trạng thái bên trong đối tượng Trần Thị Kim Chi 4
5. TỔNG QUAN VỀ OOAD • Các đối tượng được phân thành class – Các đối tượng thuộc cùng lớp đều có đặc tính (thuộc tính và thao tác) chung • Hướng đối tượng tập trung vào cả thông tin và hành vi • Cho khả năng xây dựng hệ thống mềm dẻo, “co dãn” • Phương pháp này dựa trên các nguyên tắc sau – Tính đóng gói – Kế thừa – Ða hình Trần Thị Kim Chi 5
6. TỔNG QUAN VỀ OOAD • Class Model • Data-Oriented – static structure – what objects are in the system? – how are they related? • Action-Oriented • Dynamic Model – behavioral aspects – what events occur in the system – when do they occur and in • Both Data and Actions what order? • Functional Model – data transformations – “what” does the system do Trần Thị Kim Chi 6
7. TỔNG QUAN VỀ OOAD Static Diagrams Class Use-Case Diagrams Sequence Diagrams Object Diagrams Diagrams Communication Component Diagrams Models Diagrams Dynamic Diagrams State Machine Deployment Diagrams Diagrams Activity Diagrams Trần Thị Kim Chi 7
8. TỔNG QUAN VỀ OOAD Các bước phân tích và thiết kế theo hướng đối tượng • Các bước phân tích thiết kế hướng đối tượng dựa trên biểu đồ các ký hiệuUML (Unit Modeling Language). • Các giai đoạn phân tích thiết kế hướng đối tượng – Phân tích hướng đối tượng(Object Oriented Analysis - OOA) – Thiết kế hướng đối tượng(Object Oriented Design – OOD) – Lập trình hướng đối tượng (Object Oriented Programming - OOP) Trần Thị Kim Chi 8
9. PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG (OBJECT ORIENTED ANALYSIS – OOA) • Phát triển mô hình chính xác và súc tích của vấn đề • Ánh xạ các thực thể ở thế giới thực đối tượng trong thiết kế. • Chứa các thực thể trong một vấn đề có thực. • Giữ nguyên mẫu về cấu trúc, quan hệ cũng như hành vi của chúng. • Ví dụ: Cửa hàng bán xe hơi – Thực thể (đối tượng): ? – Tương tác và quan hệ giữa các thực thể: ? Trần Thị Kim Chi 9
10. PHÂN TÍCH HƯỚNG ĐỐI TƯỢNG (OBJECT ORIENTED ANALYSIS – OOA) Ví dụ: Cửa hàng bán xe hơi, giai đoạn OOA sẽ nhận biết được • Các thực thể: – Khách hàng – Người bán hàng – Phiếu đặt hàng – Phiếu (hoá đơn) thanh toán – Xe hơi • Tương tác và quan hệ giữa các thực thể trên là: – Người bán hàng giới thiệu xe cho khách hàng – Khách hàng chọn xe – Khách hàng viết phiếu đặt xe – Khách hàng trả tiền xe – Người bán hàng giao xe cho khách hàng Trần Thị Kim Chi 10
11. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG (OBJECT ORIENTED DESIGN – OOD) • Tạo thiết kế dựa trên kết quả của giai đoạn OOA, dựa trên các yêu cầu chức năng, phi chức năng – Yêu cầu chức năng? – Yêu cầu phi chức năng? • Định nghĩa các : – chức năng, thủ tục (operations), – thuộc tính (attributes) – mối quan hệ của một hay nhiều lớp (class) quyết định chúng cần phải được điều chỉnh sao cho phù hợp với môi trường phát triển • Đưa ra các biểu đồ: • Tĩnh: biểu thị các lớp và đối tượng • Động: biểu thị tương tác giữa các lớp và phương thức hoạt động chính xác của chúng. • Kết quả của giai đoạn thiết kế là bản thiết kế kiến trúc và thiết kế chi 11tiết. Trần Thị Kim Chi
12. LẬP TRÌNH HƯỚNG ĐỐI TƯỢNG (OBJECT ORIENTED PROGRAMMING - OOP) • Java • C++ • Smalltalk Trần Thị Kim Chi 12
13. CÁC ĐẶC TRƯNG CỦA HƯỚNG ĐỐI TƯỢNG Trần Thị Kim Chi 13
14. Lớp trừu tượng và lớp cụ thể (Abstract and Concrete Class) Abstraction: Giảm độ phức tạp bằng cách che giấu những chi tiết không liên quan. Trần Thị Kim Chi 14
15. Review: Encapsulation Illustrated – Kết hợp tiến trình và dữ liệu vào một thực thể thống nhất. Nhiều gói kết hợp thành một hệ thống con (subsystem). – Vấn đề cơ bản trong đóng gói (encapsulation) là giao diện thông báo của một đối tượng, phải đảm bảo các giao tiếp được thực hiện thông qua tập các hoạt động được xác định trước. – Dữ liệu bên trong đối tượng chỉ được truy cập bởi các hoạt động của đối tượng Trần Thị Kim Chi 15
16. Review: Encapsulation Illustrated • Giáo sư Clark có thể dạy 4 lớp trong Professor Clark học kỳ tiếp theo. Name: J Clark Employee ID: 567138 HireDate: 07/25/1991 Status: Tenured Discipline: Finance SetMaxLoad(4) MaxLoad: 4 TakeSabbatical() Trần Thị Kim Chi 16
17. MODULARITY – Chia một hệ thống phức tạp thành các module nhỏ hơn dễ quản lý hơn. Các module này có thể kết hợp để tạo thành hệ thống. – Nhằm mục đích hiểu rõ hơn một hệ thống phức tạp Trần Thị Kim Chi 17
18. MODULARITY • Tách hệ thống đăng ký khóa học (course Registration System) thành các module. Billing System Course Catalog System Course Registration System Student Management System Trần Thị Kim Chi 18
19. HIERARCHY • Phân cấp (Hierarchy) • Hệ thống phân cấp tổ chức theo cấu trúccây • Loại hệ thống phân cấp: • Aggregation hierarchy, • Class hierarchy, • Containment hierarchy, • Inheritance hierarchy, • Partition hierarchy, • Specialization hierarchy, • Type hierarchy Trần Thị Kim Chi 19
20. HIERARCHY Increasing Asset abstraction BankAccount Security RealEstate Decreasing Savings Checking Stock Bond abstraction Elements at the same level of the hierarchy should be at the same level of abstraction. Trần Thị Kim Chi 20
21. CÁC KHÁI NIỆM VỀ HƯỚNG ĐỐI TƯỢNG • Lớp và đối tượng, sự đóng bao • Thuộc tính, tác vụ, thông điệp • Bao gộp, thừa kế • Tính đa hình, tính vĩnh cửu Trần Thị Kim Chi 21
22. ĐỐI TƯỢNG (OBJECT) Đối tượng (Object): • Các đối tượng (Objects) là các thực thể trong thế giới thực như: con người, sự vật, sự kiện mà nó liên quan đến hệ thống đang phân tích. • Hệ thống hướng đối tượng mô tả các thực thể như các đối tượng. – Mỗi đối tượng có các thuộc tính mô tả thông tin của các đối tượng – Mỗi đối tượng cũng có các hành vi, xác định hoạt động của đối tượng.
23. ĐỐ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: Trần Thị Kim Chi 23
24. ĐỐI TƯỢNG (OBJECT) Đối tượng (Object): • VD: (Person) Person Joe Smith name age=39 age weight=158 weight (Person) Mary Wilson age=27 weight=121 Trần Thị Kim Chi 24
25. LỚP (CLASS) • Lớp là một nhóm các đối tượng có cùng thuộc tính, hành vivà các mối quan hệ. Đối tượng là một thể hiện của một lớp. • Một lớp xác định cácthuộc tính và hành vi của tất cả các đối tượng trong lớp đó. • Mỗi lớp có một tên riêngbiệt • Một lớp là sự trừu tượng của chính nó – Nhấn mạnh những đặc điểm liên quan – Che dấu những đặc điểm khác Class Attributes Operations ball radius, weight catch, throw football air pressure pass, kick, hand-off baseball liveness hit, pitch, tag Trần Thị Kim Chi 25
26. LỚP (CLASS) • Thuộc tính: 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 • Giá trị của tất cả các thuộc tính xác định trạng thái của đối tượng – VD: một đối tượng của Circle có (Radius, x, y) = (2, 1.8,6.4) • Thuộc tính có thể bị che dấu hoặc truy xuất được từ bên ngoài: public, protected, private Trần Thị Kim Chi 26
27. LỚP (CLASS) Professor - name - employeeID : UniqueID - hireDate - status - discipline - maxLoad + submitFinalGrade() + acceptCourseOffering() Professor J Clark + setMaxLoad() + takeSabbatical() + teachClass() Trần Thị Kim Chi 27
28. LỚP (CLASS) • Thuộc tính có2 loại tầm vực: – Tầm vực lớp: thuộc tính chung cho tất cả đối tượng của 1 lớp – Tầm vực đối tượng: thuộc tính của từng đối tượng (có thể mang giá trị khác nhau) • Bậc của thuộc tính chỉ ra số lượng dữ liệu mà bản thân thuộc tính có thể nắm giữ: 0 1, 1 *, 10 20. Trần Thị Kim Chi 28
29. LỚP (CLASS) • Tác vụ - hành vi (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) • Thông báo (Messages): thông tin gửi cho đối tượng kích hoạt phương thức. Một thôngTrầnbáo Thị làKim mộtChi hàm hoặc một thủ tục29gọi từ một đối tượng đến một đối tượng khác.
30. QUAN HỆ GIỮA LỚP VÀ ĐỐI TƯƠNG • Lớp là mô tả tĩnh của đối tượng, đối tượng là một thể hiện (INSTANCE) củalớp tại thời điểm thực thi Professor Torpie Professor Professor MeijerProfessor Allen Trần Thị Kim Chi 30
31. QUAN HỆ GIỮA CÁC LỚP (CLASS) Class Relationships:  Association OR  Aggregation OR  Composition OR  Generalization  Dependency  Realization Trần Thị Kim Chi 31
32. LỚP (CLASS) - Association and Links • Thuộc tính Navigability xác định hướng từ lớp liên kết đến lớp mục tiêu bằng cách sử dụng quan hệ kết hợp (association) • Ví dụ: kết hợp giữa Schedule và Course Offering là navigable theo cả 2 hướng • Schedule cần biết Course Offering được gán vào Schedule. • Ngược lại, Course Offering cần phải biết Schedules trong nó. RegistrationController Schedule CourseOffering
33. LỚP (CLASS) - Association and Links • Quan hệ ngữ nghĩa giữa 2 hay nhiều lớp xác định kết nối giữa các giữa các điển hìnhcủ a hai lớp đó. 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 Trần Thị Kim ChiVienna 33
34. Association • Xác định mối quan hệ giữa hai hoặc nhiều lớp trong hệ thống. Các loại kết hợp trong quan hệ Association – Directed Association: kết hợp có hướng, được biểu diễn bằng một nhãn và mũi tên chỉ hướng
35. Association – Reflexive Association: sự kết hợp giữa một class với chính nó. – Ví dụ: Một nhân viên quản lý tối đa 10 nhân viên
36. Association Multiplicity: Unspecified Số instances Exactly One của một 1 class có thể Zero or More 0 * kết hợp với một Zero or More * instance của lớp còn lại. One or More 1 * Zero or One (optional scalar role) 0 1 Specified Range 2 4 Multiple, Disjoint Ranges 2, 4 6 Trần Thị Kim Chi 36
37. Association Ví dụ
38. Association Ví dụ: • Một sinh viên có thể đăng ký ít nhất là một và nhiều nhất là 5 khóa học. • Một khóa học ít nhất là 10 và tối đa là 300 sinh viên
39. Aggregation • Aggregation: là một dạng đặc biệt của association nó thể hiện quan hệhas -a hoặcpart -whole, còn gọi làshare aggregation Trần Thị Kim Chi 39
40. Aggregation • Ví dụ: Course (khóa học) có nhiều student, nhưng student có thể tồn tại độc lập hoặc thuộc một course khác. Trần Thị Kim Chi 40
41. Composition • Quan hệ Composition là loạiAggregation chặt chẽ hơn, còn gọi làNon -share aggregation. Trần Thị Kim Chi 41
42. Composition • Ví dụ: – Apartment (căn hộ) được tạo thành từ nhiều Room (phòng), Room chỉ thuộc Apartment, Room không thể tồn tại độc lập. Trần Thị Kim Chi 42
43. LỚP (CLASS) – Association, Aggregation and Composition 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 Trần Thị Kim Chi 43
44. LỚP (CLASS) – Association, Aggregation and 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ặtvớ 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 Trần Thị Kim Chi 44
45. Quan hệ Tổng quát hóa (Generalization) • Mối quan hệ giữa các lớp mà trong đó một lớp có thể chia sẽ cấu trúc hoặc hành vi cho nhiều lớp khác. • Xác định một hệ thống phân cấp trừu tượng, trong đó một lớp con(subclass) kế thừa từ một hoặc nhiều lớp cha (superclasses) • Loại quan hệ kế thừa – Single inheritance: subclass kế thừ từ một superclass. – Multiple inheritance: subclass kế thừa từ một hoặc nhiều superclass. Trần Thị Kim Chi 45
46. Quan hệ Tổng quát hóa (Generalization) • Trong hệ thống phân cấp – Lớp có thể hiện (instances) gọi là concrete class. – Lớp không có thể hiện (instances) gọi là abstract classes. Trần Thị Kim Chi 46
47. Tổng quát hóa (Generalization) Sơ đồ 1: Lớp B dẫn xuất từl ớp A, lớp C dẫn xuất từl ớp B Trần Thị Kim Chi 47
48. Tổng quát hóa (Generalization) Trần Thị Kim Chi 48
49. Tổng quát hóa (Generalization) • Ví dụ đơn kế thừa:Một lớp kế thừa từ MỘT lớp khác Trần Thị Kim Chi 49
50. Tổng quát hóa (Generalization) • Ví dụ đa kế thừa:Một lớp có thể kế thừa từ nhiều lớp khác Trần Thị Kim Chi 50
51. 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 Trần Thị Kim Chi 51
52. Tổng quát hóa (Generalization) Advantages of Inheritance • Reusability – reuse public methods of base class • Extensibility – Extend the base class • Data hiding – base class keeps some data private derive class cannot change it • Rapid prototyping Trần Thị Kim Chi 52
53. Quan hệ Dependency • Một quan hệ giữa hai phần tử mô hình, trong đó, sự thay đổi của mô hình này sẽ gây ra sự thay đổi của mô hình kia Dependency relationship Class Client Supplier Dependency relationship Component Client Supplier Dependency relationship Package ClientPackage SupplierPackage Trần Thị Kim Chi 53
54. ĐA HÌNH (POLYMORPHISM)  Cùng một hành vi nhưng thể hiện khác nhau bởi những lớp đối tượng khác nhau. • Ví dụ đa hình (Polymorphism) Trần Thị Kim Chi 54
55. ĐA HÌNH (POLYMORPHISM) • Ví dụ thực thi đa hình (Polymorphism) Trần Thị Kim Chi 55
56. THÔNG ĐIỆP – Message • Thông điệp là một phép gọi tác vụ đến một đối tượng cụ thể. • Thông điệp gồm 3 phần: – Đối tượng đích – Dấu hiệu nhận dạng tác vụ muốn gọi – Danh sách thông số gọi Trần Thị Kim Chi 56
57. Class Modeling - An Example FastData Inc. wants a subsystem to process office supply orders via the Web. The user will supply via a form their name, password, account number, and a list of supplies along with an indication of the quantities desired. The subsystem will validate the input, enter the order into a database, and generate a receipt with the order number, expected ship date, and the total cost of the order. If the validation step fails, the subsystem will generate an error message describing the cause of the failure. Trần Thị Kim Chi 57
58. Class Modeling - Concise Problem Definition •Define the problem concisely – Use only a single sentence “FastData, Inc. employees may order office supplies via the Web and receive a receipt confirming the order” •This is the first step towards identifying the classes of the subsystem Trần Thị Kim Chi 58
59. Class Modeling - Informal Strategy •Identify the constraints governing the system – Use only a single paragraph “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.” •We now have more information to be used in identifying classes for the subsystem Trần Thị Kim Chi 59
60. Class Modeling - Formalize the Strategy • Identify the nouns of the description, which serve as the basis for identifying the subsystem’s classes. – Look for out-of-domain nouns (and throw them out!) – Look for abstract nouns (use these for attributes) – The remaining nouns are good candidates! “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.” Trần Thị Kim Chi 60
61. Nouns • 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. Trần Thị Kim Chi 61
62. Class Model employee order order DB name number password account total cost error message receipt item explanation order number name ship date quantity total cost price Trần Thị Kim Chi 62
63. Class Model, continued 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 Trần Thị Kim Chi 63
64. Class Modeling - Relationships 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 Trần Thị Kim Chi 64
65. Khái niệm lớp cấu trúc - Structured Class • Lớp cấu trúc chứa các thành phần (part) và vai trò (Role) mà nó tạo thành cấu trúc và thực hiện hành vi của nó. • Mô tả cấu trúc hiện thực bên trong lớp cấu trúc • Các thành phần chính nó cũng tạo thành các lớp cấu trúc. • Cho phép phân cấp cấu trúc dạng mô hình phân cấp • Kết nối (connector) được sử dụng để biểu diễn sự liên kết giữa các thành phần trong một ngữ cảnh cụ thể Trần Thị Kim Chi 65
66. Ký hiệu lớp cấu trúc • Thành phần(part) hoặc vai trò (role): được biểu diễn bằng biểu tượng của một lớp (hình chữ nhật)  Cú pháp: rolename : Typename [ multiplicity ] • Cả 3 thành phần có thể bỏ qua • Nếu multiplicity bỏ qua, mặc định là 1 • Tham chiếu đến đối tượng bên ngoài biểu diễn bằng hình chữ nhật nét đứt Trần Thị Kim Chi 66
67. Class Diagram versus Structure Diagram Class Diagram Structure Diagram Student Student 1 1 shared : Schedule [0 *] shared 0 * 0 * comp comp : Schedule [0 *] Schedule Schedule Trần Thị Kim Chi 67
68. Structure Diagram Ví dụ: Khi một hệ thống được phân rã, mỗi thành phần có thể trở thành một lớp cấu trúc chứa các thành phần của chính nó. Course Registration System : StudentManagementSystem : BillingSystem : CourseCatalogSystem
69. What Is an Interface? • Khai báo một tập thống nhất các tính năng và quy ước chung. • Interface là cốt lõi của khả năng “Plug and play” của một kiến trúc. • Interface hình thức hóa tính đa hình. Cho phép định nghĩa tính đa hình bằng cách khai báo, không liên quan đến hiện thực. Trần Thị Kim Chi 69
70. What Is an Interface? • Ví dụ: giao tiếp giữa providers and consumers, có các interface – Provided interface. – Required interface. Trần Thị Kim Chi 70
71. Example: A Provided Interface Elided/Iconic Manufacturer A Representation (“ball”) Manufacturer B Remote Sensor Manufacturer C Manufacturer A Canonical (Class/Stereotype) > RemoteSensor Representation Manufacturer B Manufacturer C Trần Thị Kim Chi 71
72. What Is an Interface? Example: A Required Interface Elided/Iconic Remote Control Representation Remote Sensor (“socket”) > Canonical Remote Control Remote Sensor (Class/Stereotype) Representation Trần Thị Kim Chi 72
73. What Is an Interface? Example: A Required Interface Elided/Iconic Remote Control Representation Remote Sensor (“socket”) > Canonical Remote Control Remote Sensor (Class/Stereotype) Representation Trần Thị Kim Chi 73
74. What is a Port? • Port là một cấu trúc đóng gói sự tương tác giữa nội dung của một lớp và môi trường của nó. – Hành vi của Port được xác định bởi giao diện cung cấp (provided) và yêu cầu (required) của nó. • Việc hiệu chỉnh cấu trúc bên trong không ảnh hưởng đến bên ngoài. • Một lớp có thể có nhiều port. – Một Port có một tập các giao diện Provided và Required Trần Thị Kim Chi 74
75. What is a Port? • A port is shown as a small square with the name placed nearby. portName • Ports may be public, protected or private Trần Thị Kim Chi 75
76. Port Types • Ports có thể có nhiều loại hiện thực khác nhau: – Service Port: chỉ sử dụng để hiện thực bên trong của lớp – Behavior Port: các yêu cầu trên Port được hiện thực trực tiếp bởi lớp – Relay Port: các yêu cầu trên Port được chuyển đến các bộ phận bên trong hiện thực. Trần Thị Kim Chi 76
77. Port Types Structured Class Name Behavior Port Service Port Relay Port partA partB Trần Thị Kim Chi 77
78. Sơ đồ mô tả - Diagram Depiction • Mỗi sơ đồ có một khung, một ngăn chứa tiêu đề và một vùng chứa nội dung. Trần Thị Kim Chi 78
79. Sơ đồ mô tả - Diagram Depiction • Khung chứa tên theo cú pháp: [ ] [ ] • có thể là: – Activity - activity diagram – Package - class diagram, package diagram – Communication - communication diagram – Component - component diagram – Class - composite structure diagram . deployment - deployment diagram . intover - interaction overview diagram . object - object diagram . state machine - state machine diagram . sd - sequence diagram . timing -timing diagram . use case - use case diagram Trần Thị Kim Chi 79
80. What Are Notes? • Chú thích được thêm vào sơ đồ, bao gồm – Thông tin trên sơ đồ – Bất kỳ phần tử UML nào There can be up to one MaintainScheduleForm MaintainScheduleForm per user session. Trần Thị Kim Chi 80
81. Questions • What are the four basic principles of object orientation? Provide a brief description of each. • What is an object and what is a class? What is the difference between the two? • What is a class relationship? Give some examples. • What is polymorphism? • What is an interface? Trần Thị Kim Chi 81
82. UNIFIED MODELING LANGUAGE (UML) • Là ngôn ngữ mô hình hóa (UML) dùng để xác định, xây dựng và lưu trữ lại kết quả (artifact) của quá trình phát triển hệ thống. • UML ra đời nhằm chấm dứt cuộc chiến các phương thức (“method wars”) trong cộng đồng OO. • “Three Amigos”: Ivar Jacobson, Grady Booch và Jim Rumbaugh đã hợp nhất các phương pháp OO và tạo ra ngôn ngữ mô hình hóa chuẩn UML Trần Thị Kim Chi 82
83. UNIFIED MODELING LANGUAGE (UML) Lịch sử phát triển của UML Trần Thị Kim Chi 83
84. UNIFIED MODELING LANGUAGE (UML) • UML (Unified Modeling Language): ngôn ngữ dùng để mô hình hóa quá trình phát triển hệ thống phần mềm hướng đối tượng. • Các biểu đồ trong UML được chia thành 2 nhóm: – Biểu đồ cấu trúc (Structure Diagrams): class, object, package, deployment, component, composite structure diagrams – Biểu đồ hành vi (Behavioral Diagrams): activity, sequence, communication, interaction, use case diagrams Trần Thị Kim Chi 84
85. UNIFIED MODELING LANGUAGE (UML) UML là ngôn ngữ dùng để Các hệ thống ứng dụng UML lập và cung cấp tài liệu. Tài liệu gồm có: • Hệthống thông tin (Information System) • Ghi chép về các yêu cầu của hệ thống • Hệ thống kỹ thuật (Technical System) • Kiến trúc của hệ thống • Hệ thống nhúng (Embeded • Thiết kế System) • Mã nguồn • Hệ thống phân bố • Kế hoạch dự án (Distributed System) • Tests • Hệ thống giao dịch • Các nguyên mẫu (Business System) • Phần mềm hệ thống Trần Thị Kim Chi(System SoftWare) 85
86. UNIFIED MODELING LANGUAGE (UML) UML defines 13 diagrams that describe 4+1 architectural views 4+1 architectural views model was proposed by Philippe Kruchten, IBM Trần Thị Kim Chi 86
87. UNIFIED MODELING LANGUAGE (UML) Class, interface, collaboration, Structural Things use case, components, nodes Behavior things Interaction, State machine -Class diagram -Object diagram Group things Package Structural Diagram -Component diagram -Deployment diagram Annotation things Note Things Diagram Relationship - Use case diagram Dependency, Aggregation, - Activity diagram Structural Relationship Behavioral Diagram Association, Generalization - Interaction diagram Communication, Includes, - State machine diagram Behavior Relationship Extends, Generalizes Trần Thị Kim Chi 87
88. UNIFIED MODELING LANGUAGE (UML) Trần Thị Kim Chi 88
89. UNIFIED MODELING LANGUAGE (UML) UML defines 13 diagrams that describe 4+1 architectural views 4+1 architectural views model was proposed by Philippe Kruchten, IBM Trần Thị Kim Chi 89
90. UNIFIED MODELING LANGUAGE (UML) Biểu đồ Use case Trần Thị Kim Chi 90
91. UNIFIED MODELING LANGUAGE (UML) Biểu đồ lớp (Class diagram) Trần Thị Kim Chi 91
92. UNIFIED MODELING LANGUAGE (UML) Biểu đồ đối tượng (Object diagram) Trần Thị Kim Chi 92
93. UNIFIED MODELING LANGUAGE (UML) Biểu đồ trạng thái (State diagram) Trần Thị Kim Chi 93
94. UNIFIED MODELING LANGUAGE (UML) Biểu đồ trình tự (Sequence diagram) Trần Thị Kim Chi 94
95. UNIFIED MODELING LANGUAGE (UML) Biểu đồ tương tác (Communication Diagram) Trần Thị Kim Chi 95
96. UNIFIED MODELING LANGUAGE (UML) Biểu đồ hoạt động (Activity Diagram) Trần Thị Kim Chi 96
97. UNIFIED MODELING LANGUAGE (UML) Biểu đồ thành phần (Component Diagram) Trần Thị Kim Chi 97
98. UNIFIED MODELING LANGUAGE (UML) Biểu đồ triển khai (Deployment Diagram) Trần Thị Kim Chi 98
99. RATIONAL UNIFIED PROCESS (RUP) IMPLEMENTS BEST PRACTICES Trần Thị Kim Chi 99
100. QUY TRÌNH RUP(Rational Unified Process)(1) • Do hãng Rational phát triển • Là quy trình phát triển hợp nhất gồm các pha (phase) và các giai đoạn công việc (workflow) mà đội thực hiện dự án cần tuân theo. • Quá trình thực hiện qua toàn bộ các pha được gọi là chu trình phát triển • Kết quả của quá trình phát triển các RUP được gọi là các Artifact, bao gồm các mô hình và các bộ tài liệu. • Mục tiêu của RUP là tạo ra sản phẩm phần mềm chất lượng cao nhất đáp ứng nhu cầu của người dùng. • Về mặt quản lý: RUP cung cấp một giải pháp để phân công công việc và nhiệm vụ trong hệ thống phát triển phần mềm. Trần Thị Kim Chi 100
101. QUY TRÌNH RUP(Rational Unified Process)(1) • Đặc điểm của tiến trình RUP – Là một tiến trình lặp đi lặp lại, phù hợp với những hệ thống có yêu cầu thay đổi. – Sử dụng mô hình UML – Phát triển theo kiến trúc trung tâm (architecture-centric) giảm thiểu làm lại, tăng khả năng tái sử dụng. – Nhấn mạnh việc xây dựng hệ thống dựa trên sự hiểu biết thấu đáo chức năng của hệ thống – RUP hỗ trợ kỹ thuật hướng đối tượng, RUP dựa trên khái niệm về đối tượng, lớp và mối quan hệ giữa chúng. – RUP luôn quan tâm đến hoạt động kiểm soát chất lượng và quản lý rủi ro Trần Thị Kim Chi 101
102. QUY TRÌNH RUP(Rational Unified Process)(1) • Các mô hình: - Mô hình nghiệp vụ - Mô hình tình huống sử dụng - Mô hình phân tích thiết kế - Mô hình triển khai - Mô hình thử nghiệm • Các tài liệu: - Bộ tài liệu về xác định yêu cầu hệ thống - Bộ tài liệu thiết kế - Bộ tài liệu lập trình - Bộ tài liệu triểnTrần khaiThị Kim Chi 102
103. QUY TRÌNH RUP(Rational Unified Process)(1) • Giai đoạn (Phases) là khoảng cách giữa 2 mốc quan trọng của tiến trình, mỗi giai đoạn phải xác định mục tiêu cần đáp ứng, sản phẩm hoàn thành, và các quyết định để chuyển sang giai đoạn tiếp theo. • RUP gồm 4 giai đoạn: – Inception, – Elaboration, – Construction, – Transition. Trần Thị Kim Chi 103
104. QUY TRÌNH RUP(Rational Unified Process)(1) Trần Thị Kim Chi 104
105. CÁC CÔNG VIỆC TRONG TIẾN TRÌNH RUP Trần Thị Kim Chi 105
106. CÁC GIAI ĐOẠN CÔNG VIỆC CỦA RUP(1) • Mô hình hóa nghiệp vụ (business modeling): mô tả cấu trúc và quy trình nghiệp vụ. • Xác định yêu cầu (requirement): mô tả nghiệp vụ bằng phương pháp “tình huống sử dụng” (use case base method) • Phân tích và thiết kế (analysis & design): mô tả kiến trúc hệ thống thông qua các sơ đồ phân tích thiết kế. • Lập trình: thực hiện các việc xây dựng chương trình bằng ngôn ngữ lập trình. Trần Thị Kim Chi 106
107. CÁC GIAI ĐOẠN CÔNG VIỆC CỦA RUP(1) • Thử nghiệm: mô tả các tình huống và kịch bản thử nghiệm, tiến hành thử nghiệm hệ thống phần mềm. • Triển khai: đưa hệ thống phần mềm vào sử dụng. • Quản trị cấu hình và quản trị thay đổi: kiểm soát các thay đổi và duy trì sự hợp nhất của các thành phần dự án. • Quản trị dự án: quản lý toàn bộ quá trình làm việc của dự án. • Môi trường: đảm bảo các hạ tầng cần thiết để có thể phát triển được hệ thống Trần Thị Kim Chi 107
108. CÁC PHA CỦA RUP(1) • Khởi động (Inception) – Tìm hiểu nghiệp vụ – Xác định phạm vi của dự án • .Cuối pha này: kiểm tra các mục tiêu của quá trình phát triển của dự án và quyết định có tiếp tục quá trình phát triển hay không • Phác thảo (Elaboration) – Phân tích nghiệp vụ – Xác định kiến trúc phù hợp – Xây dựng kế hoạch cho dự án – Giới hạn yếu tố rủi ro cao nhất • Cuối pha này cần kiểm tra các mục tiêu và phạm vi chi tiết của hệ thống, sự lựa chọn về kiến trúc và cách xử lý các rủi ro có thể đồng thời quyết định có tiếp tục chuyển sang pha xây dựng hay không Trần Thị Kim Chi 108
109. CÁC PHA CỦA RUP(1) • Xây dựng (Construction) • Phát triển sản phẩm đầy đủ chuyển giao tới người sử dụng. • Hoàn tất các yêu cầu còn thiếu,làm mịn thiết kế và hoàn thành việc lập trình ứng dụng. • Cuối pha: kiểm tra hệ thống sẵn sàng hoạt động chưa? – Chuyển giao (Deployment) • Triển khai hệ thống đến người dùng • Ghi nhận các vấn đề phát sinh(nếu có) và các hạn chế để hoàn thiện phiên bản cuối cùng. Trần Thị Kim Chi 109
110. CHU TRÌNH PHÁT TRIỂN • RUP trải qua 4 giai đoạn gọi là chu trình phát triển và kết quả là một sản phẩm phần mềm mới. • Khi sản phẩm đã tồn tại thì các phiên bản tiếp theo được phát triển bằng cách lặp đi lặp lại một chuỗi các 4 giai đoạn trên. Trần Thị Kim Chi 110
111. HỆ THỐNG PHẦN MỀM HỖ TRỢ CHO RUP • Rational Requisite Pro • Rational Rose • Rational XDE • Rational Clear Case Trần Thị Kim Chi 111
112. CÂU HỎI VÀ BÀI TẬP • Câu 1. Ba tác giả gia nhập công ty phần Mềm Rational để phát triển UML là ai? • Câu 2. Tổ chức nào hiện nay chịu tráchnhi ệm về chuẩn UML? • Câu 3. Lý do sử dụng UML? • Câu 4. Hướng nhìn là gì? UML bao gồm những hướng nhìn nào? • Câu 5. Liệt kê các biểu đồ của UML? • Câu 6. Phân biệt mô hình tĩnhv à mô hình động trong UML? Trần Thị Kim Chi 112
113. CÂU HỎI VÀ BÀI TẬP • Câu 1. Ba tác giả gia nhập công ty phần Mềm Rational để phát triển UML là ai? • Câu 2. Tổ chức nào hiện nay chịu tráchnhi ệm về chuẩn UML? • Câu 3. Lý do sử dụng UML? • Câu 4. Hướng nhìn là gì? UML bao gồm những hướng nhìn nào? • Câu 5. Liệt kê các biểu đồ của UML? • Câu 6. Phân biệt mô hình tĩnhv à mô hình động trong UML? Trần Thị Kim Chi 113
114. CÂU HỎI VÀ BÀI TẬP • What are the four basic principles of object orientation? Provide a brief description of each. • What is an object and what is a class? What is the difference between the two? • What is a class relationship? Give some examples. • What is polymorphism? • What is an interface? Trần Thị Kim Chi 114
115. 115 Trần Thị Kim Chi