Bài giảng phân tích và thiết kế hướng đối tượng mô hình hóa yêu cầu đỗ ngọc như loan

Các yêu cầu người dùng trong ngữ cảnh 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 n

Trang 1

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

Trang 2

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

Trang 3

 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

Trang 4

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ế

Trang 5

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

Trang 6

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

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

Trang 7

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

Trang 8

• 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

Trang 9

Khái niệm Actor

Trang 10

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

Trang 12

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

Student

Full-time Student

Part-time Student

Trang 13

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

Trang 14

Actors & System Boundary

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

Trang 15

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

6 Thay đổi quy định

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

Trang 17

• Đọ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…

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?

Trang 19

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)

 …

Trang 21

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

Trang 22

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

Trang 24

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?

Trang 25

Sơ đồ Use-case

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

Trang 26

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?

Trang 27

Quan hệ giữa các Use Case

Trang 28

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

Kiểm tra

<<include>>

Trang 29

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

Trang 30

Quan hệ <<generalise>

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

<<generalise>>

Trang 31

Ví dụ (ATM)

Trang 32

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

Trang 33

Ví dụ

Trang 34

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

Trang 35

Mô tả use-case

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

Trang 36

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ẻ

Trang 37

K

Rút tiền

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

Nhập password Đúng ?

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

K

Thay thế

Thay thế bình thường

Trang 38

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

case, dùng 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

Trang 39

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

Trang 40

Ví dụ

Hãy viết đặc tả cho use case “Xem kết

quả học tập” của sinh viên

Trang 41

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

Trang 42

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

Trang 43

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

Trang 44

Ví dụ

Trang 46

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

 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

Trang 47

 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

Trang 48

 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

Trang 49

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:

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

 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

Trang 50

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

Trang 51

 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

Tiêu đề	Mô Hình Hóa Yêu Cầu
Tác giả	Đỗ Ngọc
Người hướng dẫn	GV: Phan Thị Như Kim Loan
Trường học	Đại học
Thể loại	bài giảng

Định dạng
Số trang	70
Dung lượng	2,07 MB