Lecture03.pdf

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

Đỗ Ngọc GV: Phan ThịNhư KimLoan Loan

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

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

2

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

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

3

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ế

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

4

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

IBM _ Rational Unified Process

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

5

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

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. IBM _ Rational Unified Process • Xác định giao diện người dùng cho hệ thống. 3- Mô hình hoá yêu cầu

6

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

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

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

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

8

Khái niệm Actor Tác nhân BÊN NGOÀI hệ thống Có tương tác với hệ thống Con người

Tên Actor Phần mềm

Phần cứng 3- Mô hình hoá yêu cầu

Phần mềm khác 9

Actor Tác nhân là bất kỳ thứ gì tương tác với hệ thống, có sự trao đổi dữ liệu với hệ thống Không phải là một phần của hệ thống Tác nhân có thể là: Người dùng, Thiết bị phần cứng, Hệ thống phần mềm khác Tác nhân trao đổi thông tin với hệ thống: ▫Gửi thông tin tới hệ thống ▫Nhận thông tin từ hệ thống

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

10

Actor  Nhóm người sử dụng Tác nhân BÊN NGOÀI hệ thống Có tương tác với hệ thống Con người

Tên Actor Phần mềm

Phần cứng 3- Mô hình hoá yêu cầu

Phần mềm khác 11

Tổng quát hóa (giữa các actor)

Student

Full-time Student

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

Part-time Student

12

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

John có vai trò như Một sinh viên

Student John

John có vai trò như Một giảng viên Lecturer

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

13

Actors & System Boundary

System Boundary – Giới hạn của hệ thống 3- Mô hình hoá yêu cầu

14

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

STT

Yêu cầu

Nhóm người dùng

1

Tiếp nhận học sinh

Giáo vụ?

2

Lập danh sách lớp

Giáo vụ?

3

Tra cứu học sinh

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

4

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

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

5

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

Ban giám hiệu?

6

Thay đổi quy định

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

 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ế 3- Mô hình hoá yêu cầu

15

Actor  Phần cứng ngoại vi Tác nhân BÊN NGOÀI hệ thống Có tương tác với hệ thống Con người

Tên Actor Phần mềm

Phần cứng 3- Mô hình hoá yêu cầu

Phần mềm khác 16

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

Các thiết bị ngoại vi mà phần mềm cần tương tác

 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…

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

Có cần liệt kê tất cả thiết bị ngoại vi?

17

Actor  Phần mềm khác Tác nhân BÊN NGOÀI hệ thống Có tương tác với hệ thống Con người

Tên Actor Phần mềm

Phần cứng 3- Mô hình hoá yêu cầu

Phần mềm khác 18

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) …

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

19

Xác định Actor  Ai là người cung cấp hoặc lấy thông tin từ hệ thống ?  Ai sử dụng chức năng của hệ thống?  Ai sẽ duy trì, quản lý và giữ cho hệ thống làm việc?  Những phần mềm/hệ thống khác mà hệ thống cần tương tác?

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

20

Ví dụ Xác định actor trong các trường hợp sau: Hệ thống quản lý thư viện Hệ thống đăng ký môn học

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

21

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

Use-Case

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

22

Ví dụ Ví dụ cho một giao dịch rút tiền bên máy ATM, các hành động chính của khách hàng (tác nhân) có thể là :  Đưa thẻ vào máy ATM  Nhập PIN  Chọn loại giao dịch (rút tiền)  Nhập số tiền mặt muốn rút ra  Yêu cầu về loại tiền  Nhặt tiền ra từ máy  Rút thẻ và tờ in kết quả giao dịch Use case trong trường hợp này là gì?

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

23

Ví dụ Trong hệ thống ATM:  Khách hàng có thể dùng máy ATM để truy vấn thông tin tài khoản, gửi tiền, rút tiền.  Nhân viên vận hành sẽ cần khởi động hệ thống, đóng hệ thống. Hệ thống có những use case nào?

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

24

Sơ đồ Use-case

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

Khách hàng

Kiểm tra tài khoản

Rút tiền

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

25

Xác định Use-case Xem các yêu cầu chức năng để tìm ra các Use-case Với mỗi tác nhân, ta xác định:  Tác nhân cần những chức năng nào từ hệ thống?  Tác nhân đó có tạo ra hay thay đổi dữ liệu gì của hệ thống?  Tác nhân đó có phải thông báo gì cho hệ thống?  Tác nhân đó có cần thông tin thông báo gì từ hệ thống?

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

26

Quan hệ giữa các Use Case 

Có 3 loại:  Quan hệ sử dụng(<<use>> hay <>)  Quan hệ mở rộng(<<extend>>)  Quan hệ kế thừa(<>)

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

27

Quan hệ <>  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ệ <<use>> hay <> Biểu diễn:    

Rút tiền từ tài khoả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

<>

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

Kiểm tra chữ ký

<>

In kết quả 28

Quan hệ <<extend>>    

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  Với hình tam giác rỗng  Trỏ về phía UC gốc  Đi kèm stereotype <<extend>>

QL thông tin hàng hóa

<<extend>> <<extend>>

QL loại hàng 3- Mô hình hoá yêu cầu

QL đơn vị tính 29

Quan hệ <  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  Với hình tam giác rỗng  Trỏ về phía UC gốc  Đi kèm stereotype <>

Make appointment

<>

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

Make new appointment 30

Ví dụ (ATM)

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

31

Ví dụ Hãy vẽ biều đồ use case cho hệ thống quản lý thư viện với các chức năng chính như sau:  Người đọc có thể tra cứu sách có trong thư viện và liên hệ thủ thư để mượn sách. Để mượn/trả sách cần có thẻ thư viện, nếu chưa có cần liên hệ thủ thư để đăng ký.  Thủ thư sẽ dùng hệ thống để xử lý việc mượn và trả sách. Trong trường hợp sách cần mượn đã hết, thủ thư cần mượn sách từ thư viện khác. Thủ thư sẽ từ chối cho mượn sách trong trường hợp người mượn còn sách chưa trả và đã quá hạn.  Thủ thư cũng có thể đặt mua thêm sách cho thư viện

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

32

Ví dụ

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

33

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 . . . 3- Mô hình hoá yêu cầu

34

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

“Happy Path”

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

35

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ẻ 3- Mô hình hoá yêu cầu

36

Vd: Các tiến tình trong hệ thống ATM

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

Đúng ?

K

Điều kiện gây lỗi

C

Tiếp tục xử lý

Nhập password K Đúng ? C

Điều kiện gây lỗi

Tiếp tục xử lý

Chọn giao dịch Thay thế bình thường

Chọn

Rút tiền

Vấn số dư Tiếp tục xử lý 3- Mô hình hoá yêu cầu

Thay thế bình thường Tiếp tục xử lý 37

Đặc tả Use case  Tên Use-case  Tóm tắt (Brief Description): Tóm tắt ngắn gọn về Use-case (ai sử dụng use-case, dùng use-case để thực hiện chức năng gì, ý nghĩa của usecase…)  Dòng sự kiện (Flow of Events) Dòng sự kiện chính (Basic Flow) Các dòng sự kiện khác (Alternative Flows)  Các yêu cầu đặc biệt (Special Requirements): Ghi nhận các yêu cầu đặc biệt khi thực hiện Use-case (nếu có)  Trạng thái hệ thống khi bắt đầu thực hiện Use-case (PreConditions): Mô tả rõ điều kiện trước khi bắt đầu thực hiện Use-case (ví dụ có đòi hỏi người sử dụng phải đăng nhập thành công trước đó hay không…)  Trạng thái hệ thống sau khi thực hiện Use-case (Post-Conditions): Mô tả rõ tình trạng hệ thống sau khi thực hiện Use-case (bao gồm cả trường hợp Use-case thực hiện thành công, hoặc thất bại).  Điểm mở rộng (Extension Points): Mô tả những tình huống xuất hiện các Use-case khác có quan hệ <<extend>> với Use-case đang xét. 3- Mô hình hoá yêu cầu

38

Đặc tả Use case Login  Brief Description Mô tả việc đăng nhập của người dùng vào hệ thống  Flow of Events

- Basic Flow Bắt đầu khi actor muốn vào sử dụng các chức năng của hệ thống 1. Hệ thống yêu cầu nhập username và password 2. Actor nhập username và password. 3. Hệ thống xác nhận thông tin đăng nhập để cho actor đăng nhập vào hệ thống.

- Alternative Flows

  



Nếu actor nhập sai username/ mật khẩu, xuất hiện thông báo lỗi. Actor có thể chọn bắt đầu lại Basic Flow (nhập thông tin lại từ đầu) hoặc không đăng nhập nữa. Special Requirements: Không có Pre-Conditions: Không có Post-Conditions Nếu Login thành công, actor được đăng nhập vào hệ thống. Nếu không thì vẫn giữ nguyên trạng thái. Extension Points: Không có

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

39

Ví dụ Hãy viết đặc tả cho use case “Xem kết quả học tập” của sinh viên.

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

40

Data Flow Diagram  DFD(Data flow diagram- sơ đồ luồng dữ liệu) là một trong những công cụ hữu hiệu của giai đoạn phân tích  Sử dụng DFD để biểu diễn một cách linh hoạt các thực thể ngoài, các chức năng, luồng dữ liệu và các kho dữ liệu

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

41

Sơ đồ luồng dữ liệu Các ký hiệu 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…)

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

42

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 … 3- Mô hình hoá yêu cầu

43

Ví dụ

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

44

Sơ đồ tổng quát Ý nghĩa từng dòng dữ liệu D1:……………. Dữ liệu D2:……………. xuất D3:……………. D4:……………. D5:……………. D6:…………….

Dữ liệu nhập Người dùng D1 Thiết bị nhập

D5

D2

Thiết bị xuất

Xử lý … D6

Dữ liệu đọc

D3

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

D4

Dữ liệu ghi

Thuật toán xử lý: -Bước 1:……………… -Bước 2:……………… -Bước 3:……………… -……………………….. 45

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: Người dùng  Các danh mục để chọn lựa D1 D2  Dữ liệu cần thiết cho việc kiểm tra tính hợp lệ (dựa vào quy định) D5 Thiết bị nhập Xử lý LT  D2: D6  Các danh mục để chọn lựa  Kết quả thành công/thất bại D3 D4  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) 3- Mô hình hoá yêu cầu

Thiết bị xuất

46

Sơ đồ tổng quát cho Yêu cầu lưu trữ  Xử lý lưu trữ  Đọc D3 để lấy các tham số, quy định và danh mục

Người dùng

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

 Nhận thông tin D1, D5 (nếu cần)  Kiểm tra các thông tin D1, D5 có

Thiết bị nhập

D5

Xử lý LT

Thiết bị xuất

D6

thỏa quy định liên quan hay không (dựa vào D3 nếu cần thiết)

D2

D3

D4

 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) 3- Mô hình hoá yêu cầu

47

Sơ đồ tổng quát cho Yêu cầu lưu trữ  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 Người dùng

D1 Thiết bị nhập

D5

D2

Xử lý LT

Thiết bị xuất

D6 D3

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

D4

48

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??? 3- Mô hình hoá yêu cầu

Người dùng

D1 Thiết bị nhập

D5

D2

Xử lý TC

Thiết bị xuất

D6 D3

D4

49

Sơ đồ tổng quát cho Yêu cầu tra cứu  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)

Người dùng

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

D5, nhận được danh sách các đối tượng tìm được (D3)

Thiết bị nhập

D5

D2

Xử lý TC

Thiết bị xuất

D6

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

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

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

D3

D4

50

Sơ đồ tổng quát cho Yêu cầu tra cứu  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ứa 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 Người dùng  D3 thông thường là danh sách các đối tượng tìm thấy cùng với thông D1 D2 tin liên quan.  D3 cũng có rất nhiều mức độ khác Thiết bị nhập D5 Xử lý TC nhau để xác định các thông tin của D6 đối tượng tìm thấy  D2 và D6 thường trùng với D3 D3 D4 (nhưng không nhất thiết)

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

Thiết bị xuất

51

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) Người dùng  D3:  Dữ liệu cần thiết cho việc xử lý tính toán D1 D2 (dựa vào biểu mẫu và quy định liên quan) D5  Các tham số tính toán Thiết bị nhập Xử lý TT D6  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 D3 cả D3 và D4) D4  D6: Dữ liệu kết xuất (thường gồm cả D3 và D4)

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

Thiết bị xuất

52

Sơ đồ tổng quát cho Yêu cầu tính toán  Xử lý tính toán  Nhận thông tin D1, D5 (nếu cầ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 Người dùng D1 Thiết bị nhập

D5

D2

Xử lý TT

Thiết bị xuất

D6 D3

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

D4

53

Sơ đồ tổng quát cho Yêu cầu tính toán  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ó

Thiết bị nhập

Người dùng

D1 D5

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

Xử lý TT

Thiết bị xuất

D6

=> Khi nào cần D4?

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

D2

D3

D4

54

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 thực hiện báo biểu

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

Người dùng

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

D1

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)

Thiết bị nhập

D5

D2

Xử lý BB

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

Thiết bị xuất

D6

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

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

D3

D4

55

Sơ đồ tổng quát cho Yêu cầu báo biểu  Xử lý báo biểu  Nhận thông tin D1, D5 (nếu cần)  Đọc D3 để lấy các dữ liệu cần thiết cho việc lập báo biểu Người dùng

 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à

D1 Thiết bị nhập

D5

Xử lý BB

Thiết bị xuất

D6

kết xuất D6 D3

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

D2

D4

56

Sơ đồ tổng quát cho Yêu cầu báo biểu  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)

Người dùng

D1

D2

 D4 có thể có hay không có => Khi nào cần D4?

Thiết bị nhập

D5

Xử lý BB

Thiết bị xuất

D6

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

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

D4

57

Thực hành

Đỗ Ngọc GV: Phan ThịNhư KimLoan Loan 58

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

Phát biểu bài toán (Problem Statement) Bảng chú giải Use-Case Model Các đặc tả bổ sung Checkpoints

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

59

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

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

60

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

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

61

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

62

Glossary ----------------------------------------------------------------------------------------------------------------

 Từ điển thuật ngữ (Glossary)  2-BangChuGiai_V1_TenDeTai.doc

Bảng chú giải

Use-Case Diagram

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

63

Đặ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”

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

64

Các đặc tả bổ sung Functionality Tính khả dụng (Usability) 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ế

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

     

Supplementary Specification

4-DacTaBoSung_V1_TenDeTai.doc 3- Mô hình hoá yêu cầu

65

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?

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

66

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?

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

67

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?

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

68

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?

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

69

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

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

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

70