lecture03

GV: Phan Thị Kim Loan

Mô hình hoá yêu cầu

3- Mô hình hoá yêu cầu

Nội dung trước

Hệ thống hướng chức năng vs. Hệ thống hướng đối

tượng

Các đặc điểm cơ bản của hệ thống hướng đối tượng

Giới thiệu UML – UML 2.0

Phân tích thiết kế hướng đối tượng với UML 2.0

2

3- Mô hình hoá yêu cầu 3

Nội dung

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


Mục tiêu

Tìm hiểu các khái niệm cơ bản về xác định yêu

cầu người dùng và tác dụng của chúng lên Phân

tích và Thiết kế

Tìm hiểu cách ghi nhận và diễn dịch các yêu cầu

của người dùng, là những thông tin được dùng

để bắt đầu việc phân tích và thiết kế

4


Các yêu cầu người dùng trong ngữ cảnh

5

IBM _ Rational Unified Process


Các yêu cầu người dùng trong ngữ cảnh

6

IBM _ Rational Unified Process

Mục đích của bước xác định yêu cầu người dùng là:

• Ði đến thỏa thuận với khách hàng về các chức năng của hệ thống (những gì

hệ thống phải thực hiện).

• Cho phép các nhà phát triển hệ thống (system developer) hiểu rõ hơn các

yêu cầu đối với hệ thống.

• Phân định các ranh giới của hệ thống.

• Cung cấp cơ sở để hoạch định nội dung kỹ thuật của các vòng lặp.

• Xác định giao diện người dùng cho hệ thống.


Các dạng thông về yêu cầu người dùng

Use case Model

Các Use Case

Use Case Report

Bảng chú giải

Các đặc tả bổ sung

7


Mở đầu

Đặt vấn đề:

Các mô tả về yêu cầu trong giai đoạn xác

định yêu cầu:

• Chỉ mô tả chủ yếu các thông tin liên quan đến việc

thực hiện các nghiệp vụ trong thế giới thực, chưa

thể hiện rõ nét việc thực hiện các nghiệp vụ trên

máy tính

• Mô tả thông quá các văn bản dễ gây ra nhầm lẫn

và không trực quan

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

8


Khái niệm Actor

9

Tên Actor

Tác nhân BÊN NGOÀI hệ thống

Có tương tác với hệ thống

Phần mềm

Con người

Phần cứng Phần mềm khác


Actor

An actor represents anything that interacts with

the system. An actor is EXTERNAL!

Actors are not part of the system, they represent

roles a user of the system can play.

An actor may actively interchange information with

the system.

An actor may be a passive recipient of information.

An actor can represent a human, a machine or

another system.

10


Actor Nhóm người sử dụng

11

Tên Actor



Phần mềm

Con người



Actor Generalization

12

Student

Full-time

Student

Part-time

Student


1 User có thể có nhiều vai trò (Role)

13

Student

Lecturer

John

John có vai trò như

Một sinh viên

John có vai trò như

Một giảng viên


Actors & System Boundary

14

System Boundary – Giới hạn của hệ thống


Ví dụ

STT Yêu cầu

1 Tiếp nhận học sinh

2 Lập danh sách lớp

3 Tra cứu học sinh

4 Nhận bảng điểm môn

5 Xem báo cáo tổng kết

6 Thay đổi quy định

15

Nhóm người dùng

Giáo vụ?

Giáo vụ?

Mọi người? Phụ huynh? Học sinh?

Giáo viên? Giáo vụ?

Ban giám hiệu?

Ban giám hiệu? Quản trị hệ thống?

Xét phần mềm Quản lý học sinh cấp III

Một nhóm người dùng = một Actor

Mỗi Nhóm người dùng (Actor) được quyền sử dụng một hay nhiều chức năng

trong hệ thống

Một chức năng có thể cho phép nhiều Nhóm người dùng sử dụng

Nhiều nhóm người dùng có cùng các quyền hạn giống nhau

Việc xác định Actor phụ thuộc ngữ cảnh và quy trình thực tế


Actor Phần cứng ngoại vi

16

Tên Actor



Phần mềm

Con người



Ví dụ

Ví dụ: Phần mềm quản lý Siêu thị:

• Đọc thông tin từ thiết bị đọc mã vạch

Phần mềm quản lý cửa tự động:

• Đọc thông tin từ camera

• Phát lệnh điều khiển mở cửa

Phần mềm quản lý ra vào các phòng trong công sở

• Đọc tín hiệu từ đầu đọc thẻ từ

• Phát lệnh điều khiển mở cửa

Phần mềm chống trộm

• Đọc tín hiệu từ camera, sensor

• Phát lệnh điều khiển ra loa, đèn, điện thoại…

17

Các thiết bị ngoại vi

mà phần mềm

cần tương tác

Có cần liệt kê

tất cả thiết bị ngoại vi?


Actor Phần mềm khác

18

Tên Actor



Phần mềm

Con người



Ví dụ

Kết xuất/nạp dữ liệu từ Excel

Kết xuất dữ liệu báo cáo ra phần mềm gửi email

(Microsoft Outlook, Outlook Express…)

Phần mềm trung gian kết nối để chuyển đổi email từ

dạng Web-based sang POP3 (ví dụ Yahoo!Pop)

…

19


Use-Case

Khái niệm Use-Case

Một Use-Case là một chuỗi các hành động mà hệ thống thực hiện mang lại một kết quả quan sát được đối với actor.

Có thể hiểu một Use-Case là một chức năng của hệ thống, mang một ý nghĩa nhất định đối với người dùng

20


Ví dụ

STT Yêu cầu

1 Tiếp nhận học sinh

2 Lập danh sách lớp

3 Tra cứu học sinh

4 Nhận bảng điểm môn

5 Xem báo cáo tổng kết


21

Xét phần mềm Quản lý học sinh cấp III

Có bao nhiêu Use-case trong Ví dụ này?

Bao gồm cả tính năng

Thêm mới, Xóa, và Sửa


Ví dụ

22

STT Yêu cầu

1 Sắp đặt mạch điện

2 Cung cấp nguồn điện

3 Thay đổi thông số

4 Lưu bài thí nghiệm

5 Lấy lại thí nghiệm


Phần mềm thí nghiệm mạch điện

Có bao nhiêu Use-case trong Ví dụ này?


Sơ đồ Use-case

23

Rút tiền

Khách hàng Kiểm tra tài khoản

Sự tương tác giữa Actor và Use-case

Chiều của mũi tên thể hiển vai trò chủ động trong sự tương tác


Tổng quát hóa giữa các Actor

24

Người sử dụng

Giáo viên Giáo vụ


Mô tả Use-case

1. Use-Case bắt đầu khi khách hàng đưa thẻ tín dụng vào. Hệ

thống đọc và thẩm tra thông tin của thẻ.

2. Hệ thông nhắc nhập số PIN. Hệ thống kiểm tra số PIN.

3. Hệ thống hỏi tác vụ nào khách hàng muốn thực hiện. Khách

hàng chọn “Rút tiền.”

4. Hệ thống hỏi số lượng. Khách hàng nhập số lượng.

5. Hệ thống yêu cầu nhập kiểu tài khoản. Khách hàng chọn

checking hoặc savings.

6. Hệ thống liên lạc với ATM network . . .

25


Mô tả use-case

basic flow (“Happy Path”)

Một số alternative flows

Các biến thể thường gặp (Regular variants)

Các trường hợp bất thường (Odd cases)

Exceptional flows xử lý các tình huống lỗi

26

“Happy Path”


Variations trong 1 use case

VD: Khách hàng có thể chọn các loại giao dịch ATM sau:

Rút tiền ra

Kiểm tra tiền trong tài khoản

Điểu kiện gây ra lỗi là những bước tiến hành bất bình thường trong 1

Use Case.

VD:

Mức tiền trong TK không đủ để tiến hành giao dịch

Password nhập không đúng

ATM bị nghẽn thẻ

27

3- Mô hình hoá yêu cầu 28

K

Rút tiền

K.H đưa thẻ vào ATM

Nhập password

Đúng ?

Chọn giao dịch

Đúng ?

Tiếp tục xử lý

Chọn




Điều kiện

gây lỗi

Điều kiện

gây lỗi

K

Thay thế

bình thường

Thay thế

bình thường

C

C

Vấn số dư

Vd

: C

ác t

iến

tìn

h t

ron

g h

ệ t

hố

ng

AT

M


Quan hệ giữa các Use Case

Có 3 loại:

Quan hệ sử dụng(<<uses>> hay <<includes>>)

Quan hệ mở rộng(<<extends>>)

Quan hệ kế thừa(<<generalization>>)

29


Quan hệ <<includes>>

Một nhóm các Use Case có chung 1 hành vi.

Tách hành vi đó thành 1 use case riêng (Included UC)

Use case tách riêng được các use case khác sử dụng

tạo nên quan hệ <<uses>> hay <<includes>>

Biểu diễn:

Đoạn thẳng nét đứt

Với hình tam giác rỗng

Trỏ về phía UC được sử dụng

Đi kèm stereotype

<<includes>>

30

Rút tiền từ tài khoản

Kiểm tra chữ ký In kết quả

<<includes>> <<includes>>


Quan hệ <<extends>>

31

Một UC cung cấp 1 phần các chức năng cần thiết cho 1 UC mới.

UC mới = UC cũ (Base Use Case) + thêm chức năng mới.

UC mới = UC mở rộng (Extended Use Case)

UC mở rông không nhất thiết phải dùng toàn bộ hành vi của

UC gốc

Biểu diễn:

Đoạn thẳng nét đứt


Trỏ về phía UC gốc

Đi kèm stereotype <<extend>>

QL loại hàng QL đơn vị

tính

<<extends>>

<<extends>>

QL thông tin hàng hóa


Quan hệ <<generalization>

32

Một số UC cùng xử lý các chức năng tương tự --> gom nhóm

Cung cấp giá trị gia tăng cho thiết kế

Biểu diễn:

Các đoạn thẳng liền


Trỏ về phía UC gốc

Đi kèm stereotype <<generalises>>

Make appointment

Make old appointment

Make new appointment

<<generalises>>


Sơ đồ luồng dữ liệu

Các ký hiệu

33

Tác nhân/thiết bị (Người sử dụng,

thiết bị phát sinh hay tiếp nhận dữ liệu)

Khối xử lý

Luồng dữ liệu (thông tin)

Bộ nhớ phụ (Hồ sơ, Sổ sách, tập tin, csdl…)


Các cấp sơ đồ

Các cấp sơ đồ

Cấp 0: Toàn bộ phần mềm là một khối xử lý

Cấp 1: Sơ đồ cấp 0 có thể phân rã thành nhiều sơ

đồ cấp 1, các sơ đồ cấp 1 này phải đảm bảo thể

hiện đầy đủ ý nghĩa sở đồ cấp 0 (tác nhân, thiết

bị, luồng dữ liệu, xử lý, bộ nhớ phụ)

Cấp 2: Mỗi sơ đồ cấp 1 lại có thể phân rã thành

nhiều sơ đồ cấp 2 tương tự như việc phân rã của

sơ đồ cấp 0

…

34


Ví dụ: sơ đồ cấp 0

35

Configuration Information

Configuration

Data

Configuration

Data


Ví dụ: sơ đồ cấp 1

36


Sơ đồ tổng quát

37

Người dùng

Thiết bị nhập Thiết bị xuất Xử lý …

D1 D2

D3 D4

D5

D6

Ý nghĩa từng dòng dữ liệu

D1:…………….

D2:…………….

D3:…………….

D4:…………….

D5:…………….

D6:…………….

Thuật toán xử lý:

-Bước 1:………………

-Bước 2:………………

-Bước 3:………………

-………………………..

Dữ liệu

nhập

Dữ liệu

xuất

Dữ liệu

đọc

Dữ liệu

ghi


Sơ đồ tổng quát cho Yêu cầu lưu trữ

D1: Thông tin cần lưu trữ (dựa vào biểu mẫu liên

quan)

D5: Thông tin cần lưu trữ (chỉ có trong một số yêu

cầu đặc biệt)

D3:

Các danh mục để chọn lựa

Dữ liệu cần thiết cho việc kiểm tra tính hợp lệ

(dựa vào quy định)

D2:

Các danh mục để chọn lựa

Kết quả thành công/thất bại

D4: Dữ liệu được lưu trữ (dựa vào biểu mẫu).

Ghi chú: Thông thường

D4 = D1 (+ D5) (+ ID tự phát sinh)

D6: Dữ liệu kết xuất (chỉ có trong một số yêu cầu

đặc biệt)

38

Người dùng

Thiết bị nhập Thiết bị xuất Xử lý LT

D1 D2

D3 D4

D5

D6



Xử lý lưu trữ

Đọc D3 để lấy các tham số, quy

định và danh mục

Hiển thị D2 (các danh mục)

Nhận thông tin D1, D5 (nếu cần)

Kiểm tra các thông tin D1, D5 có

thỏa quy định liên quan hay không

(dựa vào D3 nếu cần thiết)

Nếu thỏa quy định, ghi D4, thông

báo kết quả D2 (nếu cần) và xuất

D6 (nếu cần thiết)

39

Người dùng


D1 D2

D3 D4

D5

D6



Ghi chú:

D1 không nhất thiết chứa toàn bộ thông tin trong biểu mẫu liên

quan

Tùy theo quy định có thể có hay không có D5

D4 hoặc D6 không nhất thiết phải trùng với D1 hoặc D5

D2 không nhất thiết phải trùng với D3

40

Người dùng


D1 D2

D3 D4

D5

D6


Sơ đồ tổng quát cho Yêu cầu tra cứu

D1: Thông tin về đối tượng muốn tìm kiếm (dựa vào biểu mẫu liên quan đến đối tượng cần tìm kiếm)

D5: Thông tin về đối tượng muốn tìm kiếm (chỉ có trong một số yêu cầu đặc biệt)

D3: Các danh mục để chọn lựa

Dữ liệu về đối tượng khi tìm thấy (dựa vào biểu mẫu liên quan đến đối tượng cần tìm kiếm)

D2: Các danh mục để chọn lựa

Dữ liệu về đối tượng khi tìm thấy (dựa vào biểu mẫu liên quan đến đối tượng cần tìm kiếm)

D6: Dữ liệu kết xuất (thông thường là cần thiết)

D4: Dữ liệu cần lưu trữ lại Thông thường không cần thiết

Cần thiết khi nào???

41

Người dùng

Thiết bị nhập Thiết bị xuất Xử lý TC

D1 D2

D3 D4

D5

D6



Xử lý tra cứu

Đọc để lấy các danh mục (D3)

Hiển thị D2 (các danh mục)

Nhận thông tin về tiêu chí tìm

kiếm D1, D5 (nếu cần)

Tìm kiếm theo các tiêu chí D1,

D5, nhận được danh sách các

đối tượng tìm được (D3)

Hiển thị thông tin kết quả (D2) và

kết xuất D6 (nếu cần)

42

Người dùng


D1 D2

D3 D4

D5

D6



Ghi chú:

Có rất nhiều mức độ khác nhau từ rất đơn giản đến rất phức tạp để xác định D1

D1 chức nhiều thông tin thì việc tìm kiếm sẽ dễ dàng cho người dùng và ngược lại sẽ khó khăn cho phần thiết kế và cài đặt chức năng này

D3 thông thường là danh sách các đối tượng tìm thấy cùng với thông tin liên quan.

D3 cũng có rất nhiều mức độ khác nhau để xác định các thông tin của đối tượng tìm thấy

D2 và D6 thường trùng với D3 (nhưng không nhất thiết)

43

Người dùng


D1 D2

D3 D4

D5

D6


Sơ đồ tổng quát cho Yêu cầu tính toán

D1: Thông tin về đối tượng cần thực hiện việc

xử lý tính toán (dựa vào các biểu mẫu liên

quan)

D5: Thông tin về đối tượng cần thực hiện việc

xử lý tính toán (chỉ có trong một số yêu cầu

đặc biệt)

D3:

Dữ liệu cần thiết cho việc xử lý tính toán

(dựa vào biểu mẫu và quy định liên quan)

Các tham số tính toán

D4: Kết quả của xử lý tính toán

D2: Kết quả của xử lý tính toán (thường gồm

cả D3 và D4)

D6: Dữ liệu kết xuất (thường gồm cả D3 và

D4)

44

Người dùng

Thiết bị nhập Thiết bị xuất Xử lý TT

D1 D2

D3 D4

D5

D6



Xử lý tính toán


Đọc D3 để lấy các dữ liệu cần thiết cho việc tính toán (kể cả các

tham số)

Sử dụng D1, D3, D5 và quy định liên quan để tính kết quả D4

Ghi kết quả D4

Hiển thị thông tin kết quả D2 và kết xuất D6

45

Người dùng


D1 D2

D3 D4

D5

D6



Ghi chú:

D1 thường có chứa yếu tố thời gian thực

hiện xử lý tính toán

Có nhiều mức độ khác nhau xác định D1

trong xử lý tính toán (để tăng tính tiện

dụng)

D1 có thể rỗng (tính toán cho mọi đối

tượng trong tất cả cột mốc thời gian liên

quan)

D4 có thể có hay không có

=> Khi nào cần D4?

Thông thường D2 và D6 bao gồm D3 và

D4

46

Người dùng


D1 D2

D3 D4

D5

D6


Sơ đồ tổng quát cho Yêu cầu báo biểu

D1: Thông tin về báo biểu muốn thực hiện (dựa vào

biểu mẫu liên quan)

D5: Thông tin về báo biểu muốn thực hiện (chỉ có

trong một số yêu cầu đặc biệt)

D3: Dữ liệu cần thiết cho việc tưực hiện báo biểu

(dựa vào biểu mẫu và quy định liên quan)

D4: Thông tin có trong báo biểu liên quan (cần thiết

phải lưu lại) nhưng chưa được xử lý và ghi nhận lại

(yêu cầu xử lý tính toán)

D2: Thông tin về báo biểu được lập (bêểu mẫu liên

quan)

D6: Dữ liệu kết xuất (thường giống D2)

47

Người dùng

Thiết bị nhập Thiết bị xuất Xử lý BB

D1 D2

D3 D4

D5

D6



Xử lý báo biểu


Đọc D3 để lấy các dữ liệu cần thiết

cho việc lập báo biểu

Nếu có D4 thì tính toán theo quy

định và Ghi kết quả D4

Hiển thị thông tin báo biểu D2 và

kết xuất D6

48

Người dùng


D1 D2

D3 D4

D5

D6



Ghi chú:

D1 thường có chứa yếu tố thời gian của báo

biểu

Có nhiều mức độ khác nhau xác định D1

trong xử lý tính toán (để tăng tính tiện dụng)

D4 có thể có hay không có

=> Khi nào cần D4?

Thông thường D2 và D6 bao gồm D3 và D4

49

Người dùng


D1 D2

D3 D4

D5

D6

GV: Phan Thị Kim Loan

Thực hành

50


Tài liệu trong giai đoạn xác đinh yêu cầu

Phát biểu bài toán (Problem Statement)

Bảng chú giải

Use-Case Model


Checkpoints

51


Thực hành

Làm việc với công cụ Rational Rose

Case Study – Quản lý đăng ký học phần

Bài thực hành 3

52


Phát biểu bài toán

Bài toán

Tên bài toán: Course Registration

1-PhatBieuBaiToan_V1_TenDeTai.doc

53


Bảng chú giải

Từ điển thuật ngữ (Glossary)

2-BangChuGiai_V1_TenDeTai.doc

54

----------------------------------------------------------------------------------------------------------------------

Glossary


Use-Case Model

Giới thiệu

Survey Description

Use-Case Packages

Use Cases

Actors

Relationships

Diagrams

Use-Case Vieww

3-MoHinhUseCase_V1_TenDeTai.doc

55


Use-Case Model

56


Use-Case Diagram

57


Use Case

Tên

Brief description

Các luồng sự kiện

Activity & State Diagram

Use-Case diagrams

Special requirements

Preconditions

Postconditions

Các diagram khác

58


Đặc tả use-case

Ðiểm lại đặc tả của một use-case hoàn

chỉnh được cung cấp trong tài liệu, mô tả

các yêu cầu của ứng dụng “Course

Registration”

59



Functionality

Tính khả dụng (Usabilitu)

Tính tin cậy (Reliability)

Tính hiệu năng (Perfromance)

Tính hỗ trợ (Supportability)

Các ràng buộc thiết kế

4-DacTaBoSung_V1_TenDeTai.doc

60

----------------------------------------------------------------------------------------------------------------------

Supplementary

Specification


Checkpoints: Requirement: Use-Case Model

Use-case model có dễ hiểu không?

Sau khi nghiên cứu use-case model, bạn có hình thành được một

ý tuởng ràng về các chức năng của hệ thống và cách thức mà

chúng liên hệ với nhau ?

Đã xác định hết tất cả các actor? Tất cả các yêu cầu chức năng

được thỏa hay chưa?

Use-case model có chứa các hành vi vô dụng nào không?

Việc chia model thành các use-case package có xác đáng?

61


Checkpoints: : Requirements: Actors

Ðã xác định hết tất cả các actor?

Mỗi actor có tham gia vào ít nhất một use case?

Mỗi actor thật sự có một vai trò (role)? Có cần ghép hoặc

tách các actor không?

Có tồn tại 2 actor dùng cùng một vai trò đối với 1 use case

không?

Tên của các actor có gợi nhớ không? Users và customers có

hiểu tên của chúng?

62


Checkpoints : Requirements: Use-Cases

Mỗi use case có ít nhất một actor tương tác?

Các use case có độc lập với nhau?

Tồn tại các use case có các luồng sự kiện và các hành vi

tương tự nhau không?

Liệu các use case có tên duy nhất, gợi nhớ, và dễ hiểu để

chúng không bị nhầm lẫm trong các giai đoạn sau?

Các khách hàng và người dùng có hiểu tên và mô tả của các

use case không?

63


Checkpoints: Đặc tả Use-Case

Use case có đủ rõ ràng đối với những người muốn hiên thực?

Mục đích của use-case có rõ ràng?

Mô tả sơ lược (Brief description) có cho ta hình ảnh trung thực của

use-case?

Có xác định rõ luồng sự kiện của use-case như thế nào và khi nào

bắt đầu và kết thúc?

Chuỗi các giao tiếp giữa actor và use-case có tiện nghi không (từ góc

nhìn của người dùng)?

Các tương tác và các thông tin trao đổi của actor có rõ ràng?

Có use-case nào quá phức tạp không?

Các luồng sự kiện (basic và alternative) được mô hình đúng đắn?

64


Checkpoints: Requirements: Glossary

Các thuật ngữ có định nghĩa rõ ràng và súc tích?

Mỗi thuật ngữ có dùng đâu đó trong các mô tả use-

case?

Các thuật ngữ có được sử dụng hợp lý trong các mô tả

ngắn về các actor và use case?

65

[email protected]

lecture03

Documents