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...
Mơ hình hóa đối tượng Nội dung trước Mơ hình hóa u cầu: Lược đồ Use-case Khái niệm Actor Usecase Ví dụ Mơ hình hóa dịng liệu Use-case Giới thiệu Mơ hình DFD Sử dụng mơ hình DFD để mơ hình hóa u cầu lưu trữ, tra cứu, tính tốn, kết xuất – Mơ hình hóa đối tượng– Class Diagram 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ỹ Mơ hình hố đối tượng Class & Class Diagram – Mơ hình hóa đối tượng– Class Diagram Giới thiệu Một hoạt động Mục tiêu: tìm cần xây dựng Giao tiếp người dùng người phát triển, Khơng có ký hiệu phức tạp (ngoại trừ lĩnh vực chuyên môn) Thường dùng ngôn ngữ tự nhiên 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 – Mơ hình hóa đối tượng– Class Diagram Thế quản trị yêu cầu Là tiến trình tìm hiểu, sưu liệu quản lý yêu cầu Sử dụng kỹ thuật mang tính hệ thống để đảm bảo yêu cầu: Complete (đầy đủ) Consistent (nhất quán) Relevant (thích đáng) – Mơ hình hóa đối tượng– Class Diagram Thế quản trị yêu cầu Diễn tả văn xi, Tìm hiểu người dùng muốn Tổ chức thông tin lại Sưu liệu thông tin Theo vết thay đổi thông tin Quản lý tất thay đổi Đáp ứng nhu cầu người dùng cuối Thiết lập quy trình thực theo – Mơ hình hóa đối tượng– Class Diagram Thế quản trị yêu cầu Hầu hết tổ chức phát triển phần mềm làm việc theo cách thức khác Nhưng thường chúng khơng mang tính hình thức mang tính khơng thống từ dự án qua dự án khác CMM Level vs CMM Level = Định nghĩa tiến trình quản lý yêu câu – Mơ hình hóa đối tượng– Class Diagram Thế yêu cầu Là khả phần mềm người dùng yêu cầu, để giải vấn đề nhằm đạt mục tiêu Thành cơng dự án = thoả mãn u cầu – Mơ hình hóa đối tượng– Class Diagram Nguồn yêu cầu: Khách hàng Phỏng vấn khách hàng Người trả tiền cho Những stakeholders • Người sử dụng • Người quản lý Vấn đề: Khách hàng khơng biết họ muốn • Phần mềm khái niệm trừu tượng phức tạp KH thay đổi ý kiến KH khơng có khả diễn tả nhu cầu theo thuật ngữ chun mơn • Giao tiếp 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 – Mơ hình hóa đối tượng– Class Diagram Nguồn yêu cầu: thị trường Đánh giá sản phẩm cạnh tranh Những trước thực hiện? Nơi nơi thích hợp cho Lưu ý vấn đề quyền, thương hiệu sáng chế Tự đánh giá khả Chúng ta làm tốt đối thủ cạnh tranh Những kiến thức, kỹ năng, ý tưởng mà có – Mơ hình hóa đối tượng– Class Diagram 10