CHAPTER 7: REQUIREMENTS MODELING: FLOW,

BEHAVIOR, PATTERNS, AND WEBAPPS

7.1 Chiến lược của 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
để phân tích được mô hình hóa, đượ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.

7.2 Mô hình hướng dòng chảy

7.2.1 Tạo mô hình dòng dữ liệu

Một vài hướng dẫn đơn giản có thể hỗ trợ vô cùng lớn trong quá trình tạo sơ đồ luồng dữ
liệu: (1) sơ đồ luồng dữ liệu mức 0 sẽ mô tả phần mềm / hệ thống như một bong bóng
đơn lẻ; (2) đầu vào và đầu ra chính cần được lưu ý cẩn thận; (3) sàng lọc nên bắt đầu
bằng cách cô lập các quy trình ứng cử viên, đối tượng dữ liệu và lưu trữ dữ liệu được
trình bày ở cấp độ tiếp theo; (4) tất cả các mũi tên và bong bóng phải được dán nhãn bằng
tên có ý nghĩa; (5) tính liên tục của luồng thông tin phải được duy trì từ cấp này sang cấp
khác và (6) một bong bóng tại một thời điểm nên được tinh chỉnh. Có một xu hướng tự
nhiên là quá phức tạp biểu đồ luồng dữ liệu. Điều này xảy ra khi bạn cố gắng hiển thị quá
nhiều chi tiết quá sớm hoặc thể hiện các khía cạnh thủ tục của phần mềm thay cho luồng
thông tin.

7.2.2 tạo mô hình dòng điều khiển

• Liệt kê tất cả các cảm biến được đọc bởi phần mềm.

• Liệt kê tất cả các điều kiện ngắt.

• Liệt kê tất cả các Switch, được vận hành bởi một nhà điều hành.

• Liệt kê tất cả các điều kiện dữ liệu.

• Nhắc lại phân tích danh từ / động từ đã được áp dụng cho tường thuật xử lý, xem lại tất
cả các mục kiểm soát của Cameron về các đầu vào / đầu ra của đặc tả điều khiển có thể.

• Mô tả hành vi của một hệ thống bằng cách xác định các trạng thái của nó, xác định cách
đạt được từng trạng thái và xác định các chuyển đổi giữa các trạng thái.

• Tập trung vào những thiếu sót có thể có một lỗi rất phổ biến trong việc chỉ định kiểm
soát.

7.2.3 các đặc tả điều khiển

Một đặc tả điều khiển (CSPEC) thể hiện hành vi của hệ thống (ở cấp độ mà nó đã được
tham chiếu) theo hai cách khác nhau. CSPEC chứa một sơ đồ trạng thái là một đặc tả tuần
tự của hành vi. Nó cũng có thể chứa một bảng kích hoạt chương trình, một đặc tả tổ hợp
của hành vi. CSPEC mô tả hành vi của hệ thống, nhưng nó không cung cấp thông tin nào
về hoạt động bên trong của các quy trình được kích hoạt do kết quả của hành vi này.

7.2.4 quy trình kỹ thuật

Đặc tả quy trình (PSPEC) được sử dụng để mô tả tất cả các quy trình mô hình dòng chảy
xuất hiện ở cấp độ tinh chỉnh cuối cùng. Nội dung của đặc tả quy trình có thể bao gồm
văn bản tường thuật, mô tả ngôn ngữ thiết kế chương trình (PDL) của thuật toán quy
trình, phương trình toán học, bảng hoặc sơ đồ hoạt động UML. Bằng cách cung cấp
PSPEC để đi kèm với mỗi bong bóng trong mô hình dòng chảy, bạn có thể tạo ra một mô
hình mini-spec trực tiếp làm nhiệm vụ hướng dẫn thiết kế thành phần phần mềm sẽ thực
hiện bong bóng.

7.3 tạo mô hình hành vi

7.3.1 xác định các sự kiện với trường hợp sử dụng

một sự kiện không phải là những thông tin đã được trao đổi, mà là thực tế là thông tin đã
được trao đổi.

7.3.2 Đại diện tình trạng

Trong bối cảnh mô hình hóa hành vi, phải xem xét hai đặc điểm khác nhau của các trạng
thái: (1) trạng thái của mỗi lớp khi hệ thống thực hiện chức năng của nó và (2) trạng thái
của hệ thống được quan sát từ bên ngoài khi hệ thống thực hiện chức năng của nó .

Sơ đồ trạng thái cho các lớp phân tích. Một thành phần của mô hình hành vi là sơ đồ
trạng thái UML đại diện cho các trạng thái hoạt động cho mỗi lớp và các sự kiện (kích
hoạt) gây ra thay đổi giữa các trạng thái hoạt động này.

Sơ đồ trình tự. Kiểu biểu diễn hành vi thứ hai, được gọi là sơ đồ trình tự trong UML,
cho biết cách các sự kiện gây ra sự chuyển đổi từ đối tượng sang đối tượng.

7.4 thực trạng cho mô hình yêu cầu

Các mẫu phần mềm là một cơ chế để nắm bắt khởi kiến nghiệp vụ theo cách cho phép áp
dụng lại khi gặp sự cố mới. Trong một số trường hợp, khởi kiến nghiệp vụ được áp dụng
cho một vấn đề mới trong cùng một miền ứng dụng. Trong các trường hợp khác, khởi
kiến nghiệp vụ được thu thập bởi một mẫu có thể được áp dụng bằng cách tương tự với
một khởi kiến ứng dụng hoàn toàn khác.

7.4.1 Khám phá các mẫu phân tích

Mô hình yêu cầu bao gồm rất nhiều yếu tố: dựa trên kịch bản (use case), hướng dữ liệu
(mô hình dữ liệu), dựa trên lớp, hướng dòng chảy và hành vi. Mỗi yếu tố này kiểm tra
vấn đề từ một góc độ khác nhau và mỗi yếu tố cung cấp cơ hội khám phá các mẫu có thể
xảy ra trên toàn miền ứng dụng hoặc tương tự trên các miền ứng dụng khác nhau.

7.4.2 Ví dụ về mẫu yêu cầu: truyền động-cảm biến

Một trong những yêu cầu của chức năng bảo mật SafeHome là khả năng cảm biến bảo
mật đơn. Các tiện ích mở rộng dựa trên Internet cho SafeHome sẽ yêu cầu khả năng kiểm
soát chuyển động (ví dụ: xoay, thu phóng) của camera an ninh trong khu dân cư. Hàm ý-
Phần mềm SafeHome phải quản lý các cảm biến khác nhau và các bộ truyền động khác
Konrad và Cheng đã đề xuất một mẫu yêu cầu có tên Actuator-Sensor cung cấp hướng
dẫn hữu ích để mô hình hóa yêu cầu này trong phần mềm SafeHome.

7.5 Mô hình hóa yêu cầu cho webapps

7.5.1 Phân tích bao nhiêu là đủ?

• Kích thước và độ phức tạp của gia tăng WebApp.

• Số lượng các bên liên quan.

• Kích thước của nhóm WebApp.

• Mức độ mà các thành viên của nhóm WebApp đã làm việc cùng nhau trước .

• Mức độ thành công của tổ chức Phụ thuộc trực tiếp vào sự thành công của WebApp.

7.5.2 đầu vào của mô hình hóa yêu cầu

các đầu vào cho mô hình yêu cầu sẽ là thông tin được thu thập trong hoạt động giao tiếp,
bất cứ thứ gì từ một email không chính thức đến một bản tóm tắt dự án chi tiết với các
kịch bản sử dụng toàn diện và thông số kỹ thuật của sản phẩm.

7.5.2 đầu ra của mô hình hóa yêu cầu

Bạn có thể phát triển từng mô hình này bằng cách sử dụng sơ đồ đại diện (thường được
gọi là ngôn ngữ trực tuyến) cho phép ý định và cấu trúc của nó được truyền đạt và đánh
giá dễ dàng giữa các thành viên của nhóm kỹ thuật Web và các bên liên quan khác. Do
đó, một danh sách các vấn đề chính (ví dụ: lỗi, thiếu sót, không nhất quán, đề xuất cải
tiến hoặc sửa đổi, các điểm cần làm rõ) được xác định và hành động.

7.5.4 Mô hình nội dung cho WebApp

Mô hình nội dung chứa các thành phần cấu trúc cung cấp một cái nhìn quan trọng về các
yêu cầu nội dung cho WebApp. Các thành phần cấu trúc này bao gồm các đối tượng nội
dung và tất cả các lớp phân tích Các thực thể hiển thị của người dùng được tạo hoặc thao
tác khi người dùng tương tác với WebApp.

7.5.5 Mô hình tương tác cho WebApp

Phần lớn các ứng dụng Web cho phép một cuộc trò chuyện trên mạng giữa một người
dùng cuối và chức năng, nội dung và hành vi của người dùng cuối. Cuộc hội thoại này có
thể được mô tả bằng mô hình tương tác có thể bao gồm một hoặc nhiều yếu tố sau: (1) sơ
đồ use case, (2) sơ đồ trình tự, (3) sơ đồ trạng thái hoặc (4) nguyên mẫu giao diện người
dùng.

7.5.6 Mô hình chức năng cho WebApp

Mô hình chức năng giải quyết hai yếu tố xử lý của WebApp, mỗi yếu tố đại diện cho một
mức độ trừu tượng hóa thủ tục khác nhau: (1) chức năng có thể quan sát được do người
dùng cung cấp cho người dùng cuối và (2) các hoạt động có trong các lớp phân tích thực
hiện các hành vi gắn liền với lớp học.

7.5.7 Mô hình cấu hình cho WebApps

đối với các WebApp phức tạp hơn, một loạt các phức tạp cấu hình (ví dụ: phân phối tải
giữa nhiều máy chủ, kiến trúc bộ đệm, cơ sở dữ liệu từ xa, nhiều máy chủ phục vụ các
đối tượng khác nhau trên cùng một trang Web) có thể có tác động đến phân tích và thiết
kế. Sơ đồ triển khai UML có thể được sử dụng trong các tình huống trong đó các kiến
trúc cấu hình phức tạp phải được xem xét.

Mô hình điều hướng xem xét cách mỗi danh mục người dùng sẽ điều hướng từ một yếu
tố WebApp (ví dụ: đối tượng nội dung) sang đối tượng khác. Các cơ chế điều hướng
được xác định là một phần của thiết kế. Ở giai đoạn này, bạn nên tập trung vào các yêu
cầu điều hướng tổng thể.

7.6 Tổng kết

 BÀI TẬP

7.9

Điện thoại di động hiện đại cần nhiều ứng dụng khác nhau như máy ảnh, bluetooth,
internet, radio, ... Một số mẫu yêu cầu cho điện thoại di động hiện đại như vậy là:

Máy quay phim

Mô hình này cho biết cách chỉ định các cảm biến và bộ truyền động trong điện thoại,
được sử dụng để thực hiện các chức năng thu gọn camera. Mô hình này sử dụng các cảm
biến cho các chức năng phóng to và thu nhỏ của máy ảnh. một cơ chế kéo được sử dụng
cho các cảm biến thụ động và cơ chế đẩy cho các cảm biến hoạt động.

Mô hình này có thể được sử dụng trong các thiết bị khác nhau cần kết nối với máy
ảnh.

Radio

Mô hình này cung cấp chức năng của một đài phát thanh di động. nó sử dụng một số
công nghệ cho phép các trạm giao tiếp trên diện rộng là các khu vực khác nhau.

Mô hình này có thể được sử dụng trong xe hơi để cung cấp cơ sở cho hệ thống radio

Mạng không dây

Mô hình này cung cấp cho điện thoại di động quyền truy cập vào internet mà không
cần bất kỳ modem hoặc dây nào.

Mô hình này cũng có thể được sử dụng trong máy tính xách tay, là thiết bị di động.
do tính di động của họ, truy cập internet không dây rất hữu ích cho máy tính xách tay.

7.10