mô hình hoá yêu cầu - nhuloan.weebly.com · nhiều nhóm người dùng có cùng các...
TRANSCRIPT
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
3- Mô hình hoá yêu cầu
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
3- Mô hình hoá yêu cầu
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.
3- Mô hình hoá yêu cầu
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
3- Mô hình hoá yêu cầu
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
3- Mô hình hoá yêu cầu
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
3- Mô hình hoá yêu cầu
Actor
Tác nhân là bất ky 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
10
3- Mô hình hoá yêu cầu
Actor Nhóm người sử dụng
11
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
3- Mô hình hoá yêu cầu
Tổng quát hóa (giữa các actor)
12
Student
Full-time
Student
Part-time
Student
3- Mô hình hoá yêu cầu
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
3- Mô hình hoá yêu cầu
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ế
3- Mô hình hoá yêu cầu
Actor Phần cứng ngoại vi
16
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
3- Mô hình hoá yêu cầu
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?
3- Mô hình hoá yêu cầu
Actor Phần mềm khác
18
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
3- Mô hình hoá yêu cầu
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
3- Mô hình hoá yêu cầu
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?
20
3- Mô hình hoá yêu cầu
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
21
3- Mô hình hoá yêu cầu
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
22
3- Mô hình hoá yêu cầu
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ì?
23
3- Mô hình hoá yêu cầu
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?
24
3- Mô hình hoá yêu cầu
Sơ đồ Use-case
25
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
3- Mô hình hoá yêu cầu
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?
26
3- Mô hình hoá yêu cầu
Quan hệ giữa các Use Case
Có 3 loại:
Quan hệ sử dụng(<<use>> hay <<include>>)
Quan hệ mở rộng(<<extend>>)
Quan hệ kế thừa(<<generalise>>)
27
3- Mô hình hoá yêu cầu
Quan hệ <<include>>
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 <<include>>
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
<<include>>
28
Rút tiền từ tài khoản
Kiểm tra chữ ký In kết quả
<<include>> <<include>>
3- Mô hình hoá yêu cầu
Quan hệ <<extend>>
29
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 loại hàng QL đơn vị
tính
<<extend>>
<<extend>>
QL thông tin hàng hóa
3- Mô hình hoá yêu cầu
Quan hệ <<generalise>
30
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 <<generalise>>
Make appointment
Make old appointment
Make new appointment
<<generalise>>
3- Mô hình hoá yêu cầu
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
32
3- Mô hình hoá yêu cầu
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 . . .
34
3- Mô hình hoá yêu cầu
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
35
“Happy Path”
3- Mô hình hoá yêu cầu
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ẻ
36
3- Mô hình hoá yêu cầu 37
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
Tiếp tục xử lý
Tiếp tục xử lý
Tiếp tục xử lý
Đ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
3- Mô hình hoá yêu cầu
Đặ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 use-case…)
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 (Pre-Conditions): 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.
38
3- Mô hình hoá yêu cầu
Đặ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ó
39
3- Mô hình hoá yêu cầu
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
41
3- Mô hình hoá yêu cầu
Sơ đồ luồng dữ liệu
Các ký hiệu
42
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
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
…
43
3- Mô hình hoá yêu cầu
Sơ đồ tổng quát
45
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
3- Mô hình hoá yêu cầu
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)
46
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý LT
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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
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)
47
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý LT
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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
48
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý LT
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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???
49
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý TC
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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)
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)
50
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý TC
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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
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)
51
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý TC
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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)
52
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý TT
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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
53
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý TT
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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ó
=> Khi nào cần D4?
Thông thường D2 và D6 bao gồm D3 và
D4
54
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý TT
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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)
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 (biểu mẫu liên
quan)
D6: Dữ liệu kết xuất (thường giống D2)
55
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý BB
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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
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
56
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý BB
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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)
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
57
Người dùng
Thiết bị nhập Thiết bị xuất Xử lý BB
D1 D2
D3 D4
D5
D6
3- Mô hình hoá yêu cầu
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
59
3- Mô hình hoá yêu cầu
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
60
3- Mô hình hoá yêu cầu
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
61
3- Mô hình hoá yêu cầu
Bảng chú giải
Từ điển thuật ngữ (Glossary)
2-BangChuGiai_V1_TenDeTai.doc
62
----------------------------------------------------------------------------------------------------------------------
Glossary
3- Mô hình hoá yêu cầu
Đặ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”
64
3- Mô hình hoá yêu cầu
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ế
4-DacTaBoSung_V1_TenDeTai.doc
65
----------------------------------------------------------------------------------------------------------------------
Supplementary
Specification
3- Mô hình hoá yêu cầu
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?
66
3- Mô hình hoá yêu cầu
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?
67
3- Mô hình hoá yêu cầu
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?
68
3- Mô hình hoá yêu cầu
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?
69