Bài giảng phân tích và thiết kế hướng đối tượng phân tích thiết kế hướng đối tượng đỗ ngọc như loan

Mô 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
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

4 – Mô hình hóa đối tượng– Class Diagram

2


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
Mô hình hoá đối tượng
Class & Class Diagram

4 – Mô hình hóa đối tượng– Class Diagram

3

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

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 – Mô hình hóa đối tượng– Class Diagram

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ệ
thống để đảm bảo yêu cầu:
Complete (đầy đủ)
Consistent (nhất quán)
Relevant (thích đáng)
4 – Mô hình hóa đối tượng– Class Diagram

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
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ó
4 – Mô hình hóa đối tượng– Class Diagram

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
CMM Level 1 vs. CMM Level 2
= Định nghĩa được tiến trình quản lý yêu câu

4 – Mô hình hóa đối tượng– Class Diagram

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 đó
Thành công của dự án = thoả mãn các
yêu cầu

4 – Mô hình hóa đối tượng– Class Diagram

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ì
• 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
4 – Mô hình hóa đối tượng– Class Diagram

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
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ó

4 – Mô hình hóa đối tượng– Class Diagram

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

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 ???

4 – Mô hình hóa đối tượng– Class Diagram

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
• ANSI
• ISO (e.g. Unicode)
• IEEE (e.g. Posix)
Industry standards
Java, Dot-Net
Wimp user interface
WAMP, LAMP
4 – Mô hình hóa đối tượng– Class Diagram

12


Các loại yêu cầu
Chức năng
Features
User interface
Input/Output

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

4 – Mô hình hóa đối tượng– Class Diagram

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 đề
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
4 – Mô hình hóa đối tượng– Class Diagram

14

Tăng chi phí do yêu cầu sai hoặc thiếu sót
0.1

Requirements

0.5

Design

1

Coding

2

Unit testing

5

Acceptance - testing

20

Maintenance

Tỷ lệ chi phí để sửa chữa theo từng giai đoạn
4 – Mô hình hóa đối tượng– Class Diagram

15

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
Hỗ trợ của người quản lý
Yêu cầu rõ ràng

4 – Mô hình hóa đối tượng– Class Diagram

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ì
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ể
4 – Mô hình hóa đối tượng– Class Diagram

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
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
4 – Mô hình hóa đối tượng– Class Diagram

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”
“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)
4 – Mô hình hóa đối tượng– Class Diagram

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Ì
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”
4 – Mô hình hóa đối tượng– Class Diagram

20