MÔ HÌNH HÓA ĐỐI TƯỢNG– CLASS DIAGRAM ĐIỂM CAO

Kỹ Thuật - Công Nghệ - Khoa học xã hội - Quản trị kinh doanh Mô hình hóa đối tượngMô hình hóa đối tượng Nội dung trước
Mô hình hóa yêu cầu:  Lược đồ Use-case  Khái niệm Actor và Usecase  Ví dụ
Mô hình hóa các dòng dữ liệu của mỗi Use-case 4 – Mô hình hóa đối tượng– Class Diagram 2
Mô hình hóa các dòng dữ liệu của mỗi Use-case  Giới thiệu Mô hình DFD  Sử dụng mô hình DFD để mô hình hóa yêu cầu lưu trữ, tra cứu, tính toán, kết xuất Nội dung
Quản lý yêu cầu:  Giới thiệu  Chi tiết quản lý yêu cầu  Các kỹ năng 4 – Mô hình hóa đối tượng– Class Diagram 3  Các kỹ năng
Mô hình hoá đối tượng
Class Class Diagram Giới thiệu
Một trong những hoạt động đầu tiên
Mục tiêu: tìm cái cần xây dựng
Giao tiếp giữa người dùng và người phát triển, vì vậy  Không có ký hiệu phức tạp (ngoại trừ trong lĩnh vực chuyên môn)  Thường dùng ngôn ngữ tự nhiên  Hợp đồng 4 – Mô hình hóa đối tượng– Class Diagram  Hợp đồng
Các cách thức để xác định yêu cầu
Các cách thức để chuẩn hóa yêu cầu  Scenarios, Use Cases, Mockups Prototypes, Feature, Lists
Stakeholders  Những người quan tâm đến sản phẩm 4 Thế nào là quản trị yêu cầu
Là tiến trình tìm hiểu, sưu liệu và quản lý các yêu cầu.
Sử dụng những kỹ thuật mang tính hệ 4 – Mô hình hóa đối tượng– Class Diagram thống để đảm bảo yêu cầu:  Complete (đầy đủ)  Consistent (nhất quán)  Relevant (thích đáng) 5 Thế nào là quản trị yêu cầu
Diễn tả bằng văn xuôi,  Tìm hiểu cái người dùng muốn  Tổ chức thông tin này lại  Sưu liệu thông tin này 4 – Mô hình hóa đối tượng– Class Diagram  Sưu liệu thông tin này  Theo vết thay đổi thông tin này  Quản lý tất cả thay đổi  Đáp ứng nhu cầu người dùng cuối
Thiết lập quy trình và thực hiện theo nó 6 Thế nào là quản trị yêu cầu
Hầu hết các tổ chức phát triển phần mềm đều làm việc này theo những cách thức khác nhau.
Nhưng thường chúng không mang tính hình thức và mang tính không thống nhất từ dự án này qua dự án khác 4 – Mô hình hóa đối tượng– Class Diagram
CMM Level 1 vs. CMM Level 2 = Định nghĩa được tiến trình quản lý yêu câu 7 Thế nào là một yêu cầu
Là một khả năng của phần mềm được người dùng yêu cầu, để giải quyết một vấn đề nhằm đạt một mục tiêu nào đó 4 – Mô hình hóa đối tượng– Class Diagram
Thành công của dự án = thoả mãn các yêu cầu 8 Nguồn yêu cầu: Khách hàng
Phỏng vấn khách hàng  Người trả tiền cho chúng ta  Những stakeholders Người sử dụng Người quản lý
Vấn đề:  Khách hàng có thể không biết họ muốn gì 4 – Mô hình hóa đối tượng– Class Diagram  Khách hàng có thể không biết họ muốn gì Phần mềm là một khái niệm trừu tượng và phức tạp  KH có thể thay đổi ý kiến  KH không có khả năng diễn tả nhu cầu theo những thuật ngữ chuyên môn Giao tiếp giữa người chuyên làm p.mềm người bình thường
Các kỹ thuật  Giao diện Hệ thống đã tồn tại 9 Nguồn yêu cầu: thị trường
Đánh giá các sản phẩm cạnh tranh  Những gì trước đây đã thực hiện?  Nơi nào là nơi thích hợp cho chúng ta  Lưu ý vấn đề bản quyền, thương hiệu sáng chế Tự đánh giá khả năng của chúng ta 4 – Mô hình hóa đối tượng– Class Diagram
Tự đánh giá khả năng của chúng ta  Chúng ta có thể làm gì tốt hơn đối thủ cạnh tranh  Những kiến thức, kỹ năng, ý tưởng mà chúng ta có 10 Nguồn yêu cầu: thị trường
Khảo sát thị trường  Phỏng vấn khách hàng (cũ, tiềm năng, …)  Lưy ý tới những quảng cáo, tạo nhu cầu thị trường  Quan tâm tới xu hướng phát triển của thị trường 4 – Mô hình hóa đối tượng– Class Diagram  Quan tâm tới xu hướng phát triển của thị trường
Vấn đề  Người ta không biết người ta muốn gì?  Thị trường thay đổi rất nhanh  Bảo mật ý tường ??? 11 Nguồn các yêu cầu: các chuẩn
Các chuẩn và các hệ thống chuyển đổi  System standard, file formats, network protocols  Usability standards  Domain standards
Official standards  written by a standards body 4 – Mô hình hóa đối tượng– Class Diagram  written by a standards body ANSI ISO (e.g. Unicode) IEEE (e.g. Posix)
Industry standards  Java, Dot-Net  Wimp user interface  WAMP, LAMP 12 Các loại yêu cầu
Chức năng  Features  User interface  InputOutput
Phi chức năng 4 – Mô hình hóa đối tượng– Class Diagram
Phi chức năng  Hướng người dùng Performance, Precision, Reliability  Hướng người phát triển Maintainability, Reusability, Interoperability 13 Những vấn đề quản trị yêu cầu
Nhiều hệ thống thường  Chuyền giao trễ và vượt ngân sách cho phép  Không đáp ứng đầy đủ yêu cầu người dùng  Không hoạt động hiệu quả
Bước đầu tiên để giải quyết vấn đề 4 – Mô hình hóa đối tượng– Class Diagram
Bước đầu tiên để giải quyết vấn đề   xác định nguyên nhân cốt lõi
Ví dụ về những nguyên nhân cốt lõi  Thiếu dữ liệu người dùng  Yêu cầu đặc tả không đầy đủ  Yêu cầu và đặc tả thay đổi 14 Tăng chi phí do yêu cầu sai hoặc thiếu sót 0.1 0.5 1 Requirements Design Coding 4 – Mô hình hóa đối tượng– Class Diagram 2 5 20 15 Tỷ lệ chi phí để sửa chữa theo từng giai đoạn Unit testing Acceptance - testing Maintenance Thế nào là quản trị yêu cầu tốt
Ngăn:  Vượt chi phí và thời gian  Huỷ dự án
Một dự án thành công cần các yếu tố:  Sự quan tâm của người dùng 4 – Mô hình hóa đối tượng– Class Diagram  Sự quan tâm của người dùng  Hỗ trợ của người quản lý  Yêu cầu rõ ràng 16 Chất lượng của yêu cầu: tính ổn định
Ổn định  Không có mâu thuẫn  Chương trình sẽ không thể hoạt động nếu yêu cầ u mâu thuẫn
Khó đảm báo vì 4 – Mô hình hóa đối tượng– Class Diagram  Số lượng yêu cầu lớn  Mâu thuẫn tiềm ẩn
Bản chất VĐ: mâu thuẫn có thể dẫn đến mọi thứ …
Vấn đề  Khó giải thích mâu thuẫn cho khách hàng  Khách hàng muốn những thứ không thể 17 Chất lượng yêu cầu: có thể quản lý được
Tài nguyên phải có thể đáp ứng các yêu cầu  Có thể làm đúng thời gian  Với chi phí cho phép  Trong khả năng (kỹ năng) có thể?
Quản lý rủi ro  Xếp độ ưu tiên các yêu cầu 4 – Mô hình hóa đối tượng– Class Diagram  Xếp độ ưu tiên các yêu cầu  Phải có thay thế nếu cái chính không hoạt động  Mở ra những vấn đề không thể để nói đến những yêu cầ u có thể làm
Quản lý độ phức tạp  Đừng làm mọi thứ cùng một lúc  Qui trình lặp  Prototyping 18 Chất lượng yêu cầu: sự đặc tả
Càng chính xác và chi tiết càng tốt
Không tốt  “program shall be fast”  “it takes a number as input”
Tốt  “program shall give a response in less than 1s” 4 – Mô hình hóa đối tượng– Class Diagram  “program shall give a response in less than 1s”  “it takes a 16-bit signed integer as input”
Những định nghĩa  Luôn là những ý tưởng tốt  Vd: “by ''''Number'''', we always mean a 16-bit signed integer”
Qui tắc định nghĩa  Không định nghĩa xoay vòng (phụ thuộc) 19 Chất lượng yêu cầu không thiên về cài đặt
Thiên về cài đặt:  Đưa thông tin thiết kế  Đưa thông tin về mã nguồn
Sử dụng những thuật ngữ chuyên môn  Không dùng từ ngữ chuyên môn kỹ thuật  Bạn muốn tập trung vài CÁI GÌ 4 – Mô hình hóa đối tượng– Class Diagram  Bạn muốn tập trung vài CÁI GÌ  Bỏ LÀM THẾ NÀO lại phần sau
Ví dụ không tốt  “store the checked-out books in an array”  “calculate the square root with Newton''''s algorithm”
Ví dụ tốt  “the library knows which books are checked out”  “return the square root with 5-digit precision” 20 Đội ngũ phát triển phần mềm
Quản lý yêu cầu đụng đến từng cá nhân trong đội ngũ phát triển
Nếu nhóm xác định yêu cầu làm việc tốt 4 – Mô hình hóa đối tượng– Class Diagram  ảnh hưởng tốt đến kết quả của toàn nhóm phát triển dự án 21 Những kỹ năng xác định yêu cầu 6 kỹ năng cần thiết
Phân tích vấn đề
Hiểu nhu cầu người dùng 4 – Mô hình hóa đối tượng– Class Diagram
Định nghĩa được hệ thống
Quản lý được phạm vi
Tinh lọc được hệ thống
Xây dựng đúng hệ thống cần thiết 22 Kỹ năng làm việc Cũng cần phải có
Giao tiếp
Phân tích và suy nghĩ 4 – Mô hình hóa đối tượng– Class Diagram
Diễn giải
Lập báo cáo
Trình diễn 23 Chi phí cho việc xác định yêu cầu
Chi phí:  Chiếm từ 15 đến 30 kinh phí toàn dự án
Khi bỏ ra càng nhiều thời gian cho công đoạn xác định yêu cầu, chúng ta sẽ càng 4 – Mô hình hóa đối tượng– Class Diagram đoạn xác định yêu cầu, chúng ta sẽ càng tiết thời gian cho:  Thiết kế  Triển khai  Kiểm chứng 24 Qui trình lấy yêu cầu Requirememts eliciation Requirememts Analysis Negotiation Requirememts documentation Requirememts validation 4 – Mô hình hóa đối tượng– Class Diagram 25 Requirememts document System specification User needs domain information, existing system information, regulations, standards, etc. Agreed Requirements Phân tích kiến trúc trong ngữ cảnh 4 – Mô hình hóa đối tượng– Class Diagram 26 Tổng quan về phân tích 4 – Mô hình hóa đối tượng– Class Diagram 27 Mô hình “4+1 View” 4 – Mô hình hóa đối tượng– Class Diagram 28 UML trong mô hình 4+1 view
Use case View: đây là hướng nhìn chỉ ra khía cạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài. Use case Diagrams
Logical View: chỉ ra chức năng sẽ được thiết kế bên 4 – Mô hình hóa đối tượng– Class Diagram
Logical View: chỉ ra chức năng sẽ được thiết kế bên trong hệ thống như thế nào Class Diagrams Object Diagrams Package Diagrams Composite Structure Diagrams State Machine Diagrams 29 UML trong mô hình 4+1 view
Process View: chỉ ra sự tồn tại song song trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống. Sequence Diagrams Communication Diagrams Activity Diagrams 4 – Mô hình hóa đối tượng– Class Diagram Activity Diagrams Timing Diagrams Interaction Overview Diagrams 30
Implementation View Development View: chỉ ra khía cạnh tổ chức của các thành phần code. Component Diagrams
Deployment View Physical View: chỉ ra khía cạnh triển khai hệ thống vào các kiến trúc vật lý (các máy tính UML trong mô hình 4+1 view 4 – Mô hình hóa đối tượng– Class Diagram triển khai hệ thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm công tác). Deployment Diagrams 31 Class Diagram
Class Diagram là sơ đồ mô tả các lớp, các giao diện (interface) và các mối liên hệ giữa chúng, cho ta một khung nhìn tĩnh của các lớp trong mô hình. 4 – Mô hình hóa đối tượng– Class Diagram 32 Ví dụ 4 – Mô hình hóa đối tượng– Class Diagram 33 Object Class
Class (Lớp)  Là 1 nhóm Object chung thuộc tính và hành vi  Chung mối quan hệ và chung ngữ nghĩa  Là khuôn mẫu để tạo ra đối tượng
Object (Đối tượng): là thể hiện thực tế của 1 4 – Mô hình hóa đối tượng– Class Diagram
Object (Đối tượng): là thể hiện thực tế của 1 lớp Ví dụ: Lớp Sinh viên có thể tạo ra 2 đối tượ ng là sinh viên A và sinh viên B. 34 Analysis Class
Bước đầu cho một hệ thống có khả năng thực thi 4 – Mô hình hóa đối tượng– Class Diagram 35 Tìm các class 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 4 – Mô hình hóa đối tượng– Class Diagram 36 Các Stereotyle của lớp Trong biểu đồ lớp, stereotype là cơ chế để phân lớp. Có 3 loại lớp phân tích: 4 – Mô hình hóa đối tượng– Class Diagram 37 Boundary Class
Là lớp trung gian thể hiện sự tương tác giữa hệ thống và những gì bên ngoài hệ thống
Các lớp biên:  Lớp giao diện giữa người dùng và hệ thống  Lớp giữa hệ thống và các hệ thống bên ngoài 4 – Mô hình hóa đối tượng– Class Diagram 38  Lớp giữa hệ thống và các hệ thống bên ngoài Ví dụ giao dịch với “Hệ thống tài vụ”  Lớp giữa hệ thống và thiết bị ngoại vi Ví dụ “Thiết bị giải mã vạch”
Với mỗi cặp ActorUse-Case bao giờ c...