REQUIREMENTS MODELING: SCENARIOS, INFORMATION, AND

ANALYSIS CLASSES
6.1 Phân tích yêu cầu
6.1.1 Mục tiêu và triết lý chung
Trong suốt mô hình yêu cầu, trọng tâm chính của bạn là cái gì, không phải như thế nào.
Tương tác người dùng nào xảy ra trong một trường hợp cụ thể, hệ thống thao tác với đối
tượng nào, hệ thống phải thực hiện chức năng gì, hệ thống thể hiện hành vi gì, giao diện
nào được xác định và áp dụng các ràng buộc nào?
Điều quan trọng cần lưu ý là tất cả các yếu tố của mô hình yêu cầu sẽ được trực tiếp theo
dõi đến các bộ phận của mô hình thiết kế. Một phân chia rõ ràng các nhiệm vụ phân tích
và thiết kế giữa hai hoạt động mô hình quan trọng là không phải lúc nào có thể. Một số
thiết kế luôn xảy ra như một phần của phân tích, và một số phân tích sẽ được tiến hành
trong quá trình thiết kế.
6.1.2 Quy tắc phân tích ngón tay cái
• Mô hình nên tập trung vào các yêu cầu có thể nhìn thấy trong các vấn đề hoặc tên miền
kinh doanh. Mức độ trừu tượng nên tương đối cao.
• Mỗi yếu tố của mô hình yêu cầu nên thêm vào một sự hiểu biết tổng thể yêu cầu phần
mềm và cung cấp cái nhìn sâu sắc về tên miền thông tin, chức năng, và hành vi của hệ
thống.
• Trì hoãn xem xét cơ sở hạ tầng và các mô hình phi chức năng khác cho đến khi thiết kế.
• Giảm thiểu các khớp nối trong toàn bộ hệ thống.
• Hãy chắc chắn rằng mô hình yêu cầu cung cấp giá trị cho tất cả các bên liên quan.
• Giữ mô hình đơn giản như nó có thể được.
6.1.3 Phân tích tên miền
Phân tích miền phần mềm là nhận dạng, phân tích và đặc tả các yêu cầu chung từ một
miền ứng dụng cụ thể, thường được sử dụng lại cho nhiều dự án trong miền ứng dụng đó.
. . . [Phân tích miền hướng đối tượng là] nhận dạng, phân tích và đặc tả các khả năng phổ
biến, có thể sử dụng lại trong một ứng dụng cụ thể.
6.1.4 Phương pháp mô hình hóa yêu cầu
Một quan điểm về mô hình hóa các yêu cầu, được gọi là phân tích có cấu trúc, xem xét
dữ liệu và các quy trình biến đổi dữ liệu thành các thực thể riêng biệt. Các đối tượng dữ
liệu được mô hình hóa theo cách xác định các thuộc tính và mối quan hệ của chúng. Các
quy trình thao tác với các đối tượng dữ liệu được mô hình hóa theo cách cho thấy cách
chúng biến đổi dữ liệu khi các đối tượng dữ liệu chảy qua hệ thống.
Cách tiếp cận thứ hai để mô hình hóa phân tích, được gọi là phân tích hướng đối tượng,
tập trung vào định nghĩa của các lớp và cách thức chúng hợp tác với nhau để thực hiện
các yêu cầu của khách hàng. UML và Quy trình hợp nhất chủ yếu hướng đối tượng.
6.2 mô hình dựa trên kịch bản
6.2.1 tạo một trường hợp sử dụng sơ bộ
Hai yêu cầu đầu tiên về nhiệm vụ kỹ thuật Khởi động và khơi gợi Giáo dục cung cấp cho
bạn thông tin mà bạn sẽ cần để bắt đầu viết các sơ đồ use case. Các yêu cầu thu thập các
cuộc họp, QFD và các cơ chế kỹ thuật yêu cầu khác được sử dụng để xác định các bên
liên quan, xác định phạm vi của vấn đề, xác định mục tiêu hoạt động tổng thể, thiết lập
các ưu tiên, phác thảo tất cả các yêu cầu chức năng đã biết và mô tả những điều (đối
tượng) sẽ bị thao túng bởi hệ thống.
6.2.2 Tinh chỉnh sơ bộ Use case
Một mô tả về các tương tác thay thế là điều cần thiết cho sự hiểu biết đầy đủ về chức
năng đang được mô tả bởi một trường hợp sử dụng. Do đó, mỗi bước trong kịch bản
chính được đánh giá bằng cách đặt các câu hỏi sau;
• Actor có thể thực hiện một số hành động khác tại thời điểm này?
• Có thể là Actor sẽ gặp một số điều kiện lỗi tại thời điểm này? Nếu vậy, nó có thể là gì?
• Có khả năng Actor sẽ gặp phải một số hành vi khác vào thời điểm này không? Nếu vậy,
nó có thể là gì?
6.2.3 Viết hình thức một Use Case
Mọi ký hiệu mô hình đều có những hạn chế và trường hợp sử dụng cũng không ngoại lệ.
Giống như bất kỳ hình thức mô tả bằng văn bản nào khác, trường hợp sử dụng chỉ tốt như
tác giả của nó. Nếu mô tả không rõ ràng, trường hợp sử dụng có thể gây hiểu nhầm hoặc
mơ hồ. Một ca sử dụng tập trung vào các yêu cầu chức năng và hành vi và thường không
phù hợp với các yêu cầu không chức năng. Đối với các tình huống trong đó mô hình yêu
cầu phải có chi tiết và độ chính xác đáng kể (ví dụ: các hệ thống quan trọng an toàn),
trường hợp sử dụng có thể không đủ.
6.3 mô hình UML bổ sung trường hợp sử dụng
6.3.1 Xây dựng sơ đồ Diagram
Sơ đồ hoạt động UML bổ sung cho trường hợp sử dụng bằng cách cung cấp biểu diễn đồ
họa của luồng tương tác trong một kịch bản cụ thể. Tương tự như sơ đồ, sơ đồ hoạt động
sử dụng các hình chữ nhật tròn để ngụ ý một chức năng hệ thống cụ thể, mũi tên để thể
hiện dòng chảy qua hệ thống, kim cương quyết định để mô tả quyết định phân nhánh
(mỗi mũi tên phát ra từ kim cương được dán nhãn) và các đường ngang chắc chắn để chỉ
ra các hoạt động song song đang xảy ra.
6.3.2 Swimlane Diagrams
Biểu đồ swimlane của UML là một biến thể hữu ích của biểu đồ hoạt động và cho phép
bạn đại diện cho dòng chảy của các hoạt động được mô tả bởi trường hợp sử dụng và
đồng thời chỉ ra diễn viên nào (nếu có nhiều diễn viên tham gia vào một trường hợp sử
dụng cụ) hoặc lớp phân tích (được thảo luận sau trong chương này) có trách Trách nhiệm
được thể hiện như là các phân đoạn Parallel chia sơ đồ theo chiều dọc, giống như làn
đường trong hồ bơi.
6,4 MÔ HÌNH HÓA DỮ LIỆU KHÁI NIỆM
6.4.1 Đối tượng dữ liệu
Một đối tượng dữ liệu là một đại diện của thông tin tổng hợp phải được hiểu bởi phần
mềm. Theo thông tin tổng hợp, tôi có nghĩa là một cái gì đó có một số thuộc tính hoặc
thuộc tính khác nhau. Do đó, chiều rộng (một giá trị) sẽ không phải là một đối tượng dữ
liệu hợp lệ, nhưng kích thước (kết hợp chiều cao, chiều rộng và chiều sâu) có thể được
định nghĩa là một đối tượng.
6.4.2 Thuộc tính dữ liệu
Các thuộc tính dữ liệu xác định các thuộc tính của một đối tượng dữ liệu và đảm nhận
một trong ba đặc điểm khác nhau.
6.4.3 Mối quan hệ
Cặp quan hệ đối tượng là nền tảng của mô hình dữ liệu. Các cặp này có thể được biểu
diễn bằng đồ họa bằng sơ đồ mối quan hệ thực thể (ERD).
6.5 LỰA CHỌN LỚP

Bài 6.5: Xử lý đơn hàng trên web: