1. Trang chủ
  2. » Công Nghệ Thông Tin

mô hình hóa yêu cầu biểu đồ usecase

17 560 1

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 17
Dung lượng 895,18 KB

Nội dung

Gv: Vũ Thị Dương Email: duongvt01@gmail.com KHOA CÔNG NGHỆ THÔNG TIN Trường Đại học công nghiệp Hà Nội PHÂN TÍCH THIẾT KẾ HƯỚNG ĐỐI TƯỢNG Mô hình hóa trường hợp sử dụng Bài 3 Phân

Trang 1

Gv: Vũ Thị Dương

Email: duongvt01@gmail.com

KHOA CÔNG NGHỆ THÔNG TIN

Trường Đại học công nghiệp Hà Nội

PHÂN TÍCH THIẾT KẾ

HƯỚNG ĐỐI TƯỢNG

Mô hình hóa

trường hợp sử dụng

Bài 3

Phân tích thiết kế hướng đối tượng Bài 2 - 3/53

Mục tiêu

 Sau khi học xong bài sinh viên nắm được

 Khái niệm ca sử dụng

 Khái niệm đối tác

 Các loại quan hệ trong biểu đồ ca sử dụng

 Vẽ được biểu đồ ca sử dụng

Trang 2

Phân tích thiết kế hướng đối tượng Bài 4 - 4/31

Giới thiệu mô hình hóa UC

 Trong pha thu thập yêu cầu và phân tích hệ thống thường phải xây

dựng các biểu đồ cho

 Mô hình nghiệp vụ

 Mô hình trường hợp sử dụng

 Mô hình giao diện người sử dụng

 Mô hình trường hợp sử dụng (Use case model) mô tả hệ thống được

sử dụng như thế nào

 Use case (UC) hệ thống và tác nhân hệ thống xác định phạm vi hệ thống

UC là những gì bên trong hệ thống

Actor là những gì bên ngoài hệ thống

 Biểu đồ UC mô tả tương tác giữa các UC và tác nhân để hình thành chức

năng hệ thống

Phân tích thiết kế hướng đối tượng Bài 4 - 5/31

Các khái niệm mô hình hóa UC

 Các khái niệm cơ bản

 Tác nhân (Actor)

 Trường hợp sử dụng (Use case-UC)

 Quan hệ (Relationship)

 Biểu đồ hoạt động (Activity Diagram)

 Biểu đồ trường hợp sử dụng (Use case Diagram)

Phân tích thiết kế hướng đối tượng Bài 4 - 6/31

Tác nhân

 Tác nhân (actor)?

 tác nhân (tác nhân ngoài) là một vai trò của một hay

(Mô tả ai, cái gì tương tác với hệ thống)

 Đối tác phải là người (vật thể) có trao đổi thông tin với

hệ thống hay hưởng lợi từ hệ thống và phải có sự tự

trị trong quyết định

 Bốn loại:

Đối tác chính: con người sử dụng trực tiếp chức năng

chính hệ thống (khách hàng, giáo viên)

Đối tác phụ: Những người làm công tác quản lý, bảo

dưỡng hệ thống

Thiết bị ngoài: Thiết bị được hệ thống điều khiển

Hệ thống khác: là các hệ thống không thuộc hệ thống

đang xây dựng nhưng có tương tác với nó

 Đặt tên: là danh từ hay cụm danh từ, theo vai

trò, không theo tên cụ thể vì nó là lớp

Customer

Trang 3

Phân tích thiết kế hướng đối tượng Bài 4 - 7/31

Tìm kiếm tác nhân như thế nào?

 Hãy trả lời các câu hỏi sau để tìm ra tác nhân hệ thống

 Ai sẽ sử dụng chức năng chính của hệ thống?

 Ai giúp hệ thống làm việc hàng ngày?

 Ai quản trị, bảo dưỡng để hệ thống làm việc liên tục?

 Hệ thống quản lý thiết bị phần cứng nào?

 Hệ thống đang xây dựng tương tác với hệ thống khác nào?

 Ai hay cái gì quan tâm đến kết quả hệ thống cho lại?

Thí dụ ứng dụng UML

 Một trường đại học thực hiện tin học hóa hệ thống đăng ký học và dạy học theo hệ thống tín

chỉ

 Hệ thống cho phép sinh viên có quyền lựa chọn môn học cho mỗi học kỳ

 Trước khi bước vào học kỳ mới, Giáo vụ gửi danh sách các môn học trong học kỳ và thời khóa

biểu dự kiến chocác thầy giáo Thầy giáo đăng ký các môn mà mình có thể giảng trong học kỳ

 Căn cứ vào ds thầy + môn ở trên và vào kế hoạch học tập chung của trường, cán bộ quản

sinh lập 1 danh sách các môn học có trong học kỳ kèm với các thông tin cần thiết như: thầy

giáo, số giờ, các môn phải học trước … để sinh viên có căn cứ để lựa chọn

 Tiếp đó mỗi sinh viên đăng ký các môn mà mình học rồi gửi cho phòng quản sinh Thông

thường mỗi sinh viên được chọn từ 6-8 môn/học kỳ và thực hiện đăng ký trong vòng 1 tuần

 Khi hết hạn đăng ký, cbqs dựa vào thông tin nhận được tổ chức các lớp giảng cho từng môn

 Mỗi lớp giảng không dưới 10 người và k quá 30 người Do điều kiện hạn chế này mà có thể

xảy ra trường hợp lớp giảng quá vắng không tổ chức được hoặc lớp giảng quá đông mà tổ

chức thêm 1 lớp nữa thì lại thiếu người Trong trường hợp đó hệ thống sẽ thông báo lại với

sinh viên để học đăng ký lại

 Khi đã hoàn tất việc xếp lớp phòng quản sinh thông báo cho từng thầy lịch day và cho sinh

viên lịch hoc của mình Mặt khác, ds các môn học cho các môn học cho từng sinh viên cũng

được gửi cho phòng tài vụ để tính học phí

 Nhà trường muốn xây dựng một hệ thống thông tin trên máy tính để trợ giúp quá trình đăng

ký nói trên Trong đó các thầy cô giáo có thể truy nhập trực tiếp để đăng ký môn dạy hay

xem danh sách sinh viên lớp mình dạy, còn sinh viên thì được dành một số ngày cho phép để

truy cập hệ thống để sửa (thêm hay bỏ) các môn học mà mình sẽ đăng ký

Phân tích thiết kế hướng đối tượng Bài 4 - 9/31

Ca sử dụng - Use case

 Use case là một biểu diễn của một tập hợp

các chuỗi hành động mà hệ thống thực

hiện nhằm cung cấp 1 kết quả cụ thể cho 1

đối tác

 Tập hợp các ca sử dụng là mô tả toàn bộ

hệ thống cần xây dựng

Một ca sử dụng tương ứng với 1 chức

năng của hệ thống dưới góc nhìn của

người sử dụng

Một ca sử dụng chỉ ra làm thế nào 1 mục tiêu cuả

người sử dụng được thỏa mãn bởi hệ thống

Purchase Ticket

Trang 4

Phân tích thiết kế hướng đối tượng Bài 4 - 10/31

Ca sử dụng

 Lưu ý:

 Ca sử dụng phải liên kết với một hay một số đối tác trong đó có 1

đối tác chính (Đối tác kích hoạt ca sử dụng một cách trực tiếp hay

gián tiếp)

 Một ca sử dụng phải dẫn tới 1 kết quả cụ thể- nghĩa là 1 kết quả

nhận biết được trọn vẹn va đo đếm được

 Cần phân biệt các mục tiêu của người sử dụng và các tương tác

của họ với hệ thống

Mục tiêu là cái mà người sử dụng mong đợi

Tương tác là kỹ thuật cho phép đáp ứng mục tiêu

 Ví dụ: Mục tiêu: có được một văn bản trình bày đẹp

Tương tác: Chọn định dạng trang, font, lề…

Phân tích thiết kế hướng đối tượng Bài 4 - 11/31

Ca sử dụng

 Ví dụ:1

 Giáo vụ cần phải thêm môn học, sửa môn học, loại bỏ môn học

Đó có là 3 ca sử dụng không?

Không, vì Quản lý môn học mới là khái niệm trọn vẹn, kích hoạt

bỏi cùng 1 đối tác (giáo vụ), đề cập tới cùng một thực thể trong hệ

thống là kế hoạch học tập để nhằm hoàn tất nó

 Ví dụ 2:

 Xây dựng hệ thống ATM cho phép rut tiền:

 Đưa thẻ vào

 Nhập mã pin – chọn số tiền rut- khẳng định số tiền rút-lấy tiền, lấy

thẻ- lấy biên lại rút

 Tìm các ca sử dụng?

Phân tích thiết kế hướng đối tượng Bài 4 - 12/31

Xây dựng UC để làm gì?

 Hình thành và mô tả yêu cầu chức năng hệ thống

 Là kết quả thỏa thuận giữa khách hàng và người phát triển hệ

thống phần mềm

 Cho phép mô tả rõ ràng và nhất quán cái hệ thống sẽ làm

 Mô hình có khả năng được sử dụng xuyên suốt quá trình phát triển

 Cung cấp cơ sở để kiểm tra, thử nghiệm hệ thống

 Cho khả năng dễ thay đổi hay mở rộng yêu cầu hệ thống

Phân tích

Thu thập,

lọc và đánh

giá UC

Thiết kế, cài đặt

Cài đặt UC

Kiểm tra

Kiểm tra xem UC thỏa mãn?

UC gắn các bước trong tiến

trình phát triển

UC và tiến trình phát triển

Trang 5

Phân tích thiết kế hướng đối tượng Bài 4 - 13/31

Xây dựng UC để làm gì?

 Ai quan tâm đến UC?

Người

sử dụng Phân tích viên

Thử nghiệm

Kiến trúc sư Lập trình viên

Use case

Diễn đạt Hiểu

Kiểm tra Thiết kế Cài đặt

Phân tích thiết kế hướng đối tượng Bài 4 - 14/31

Tìm kiếm UC như thế nào?

 Với mỗi tác nhân đã tìm ra, hãy trả lời các câu hỏi sau để tìm ra

các Use case hệ thống

 Tác nhân yêu cầu hệ thống thực hiện chức năng nào?

 Tác nhân cần đọc, tạo lập, bãi bỏ, lưu trữ, sửa đổi các thông tin nào

trong hệ thống?

 Tác nhân cần thông báo cho hệ thống sự kiện xảy ra trong nó?

 Hệ thống cần thông báo cái gì đó cho tác nhân?

 Hệ thống cần vào/ra nào? Vào/ra đi đến đâu hay từ đâu?

 Đặt tên UC hệ thống

 Động từ + cụm danh từ diễn tả ý nghĩa của UC

 Đặt theo khái niệm nghiệp vụ của tổ chức

 Không đặt tên sử dụng từ kỹ thuật, chuyên môn

 Nên sử dụng các động từ, cụm từ ngắn gọn

 Tùy theo tầm cỡ dự án mà mỗi hệ thống có từ 20-70 UC

Phân tích thiết kế hướng đối tượng Bài 4 - 15/31

Đã tìm đầy đủ UC cho hệ thống?

 Các câu hỏi sau giúp xác định đã tìm đầy đủ UC?

 Mỗi yêu cầu chức năng ở trong ít nhất một UC?

Nếu yêu cầu chức năng không ở trong UC nào thì nó sẽ không

được cài đặt sau này

 Đã khảo sát mọi tác nhân tương tác với hệ thống?

 Tác nhân cung cấp cho hệ thống thông tin nào?

 Tác nhân nhận thông tin nào từ hệ thống?

 Đã nhận biết mọi hệ thống bên ngoài tương tác với hệ

thống đang xây dựng?

 Thông tin nào hệ thống bên ngoài nhận và gửi cho hệ

thống đang xây dựng?

Trang 6

Phân tích thiết kế hướng đối tượng Bài 4 - 16/31

Luồng sự kiện trong UC

 Tài liệu luồng sự kiện (flow of events)- đặc tả UC- mô tả hành vi của

từng ca sử dụng

 Mô tả luồng logíc đi qua UC

 mô tả người sử dụng làm gì, hệ thống làm gì

 Trong một UC có nhiều luồng sự kiện: luồng chính, luồng phụ

 Mỗi luồng đó gọi là 1 kịch bản (scenario)

 Các loại kịch bản

 Kịch bản chính

 Kịch bản phụ

 Kịch bản ngoại lệ và sai hỏng

Kịch bản 3

UC

Kịch bản 1 Kịch bản 2

Phân tích thiết kế hướng đối tượng Bài 4 - 17/31

Làm tài liệu UC (đặc tả)

 Mô tả UC (chỉ nói rõ what, không how)

 Đặc tả chỉ rõ ca sử dụng trao đổi thông tin với các đối tác

nào, nó bắt đầu và kết thúc ra sao, nó có thể diễn ra theo

các kịch bản nào

Thông thường bao gồm các thông tin sau

Phân tích thiết kế hướng đối tượng Bài 4 - 18/31

Tài liệu đặc tả UC

 Mô tả tóm tắt (bắt buộc): tên, mục đích tóm lược, đối

tác, ngày lập, người lập, version

 Mô tả các kịch bản (bắt buộc):

 Tiền điều kiện (pre-condition):

Điều kiện cần thực hiện trước khi UC khởi động ;

Không phải UC nào cũng có tiền điều kiện

 Luồng sự kiện chính và luồng sự kiện rẽ nhánh

 Hậu điều kiện (post-condition)

 Các yêu cầu về giao diện: (tùy ý) : thêm các ràng buộc về giao

diện người máy

 Các ràng buộc phi chức năng (tùy ý): Tấn suất khối lượng, …

Trang 7

Phân tích thiết kế hướng đối tượng Bài 4 - 19/31

Tài liệu luồng sự kiện

 Tài liệu luồng sự kiện bao gồm

 Mô tả vắn tắt UC

 Tiền điều kiện (pre-condition)

 Luồng sự kiện chính và luồng sự kiện rẽ nhánh

chi tiết về UC được mô tả trong hai luồng sự kiện này

mô tả cái gì sẽ xảy ra để thực hiện chức năng của UC

Nội dung tài liệu

UC khởi động như thế nào?

Các đường đi xuyên qua các UC

Luồng chính thông qua UC

Luồng rẽ nhánh thông qua UC

Các luồng lỗi

UC kết thúc thế nào

 Hậu điều kiện (post-condition)

Là điều kiện được thực hiện ngay sau khi kết thúc UC

Phân tích thiết kế hướng đối tượng Bài 4 - 20/31

Thí dụ tài liệu luồng sự kiện

 Làm tài liệu các luồng sự kiện cho UC “Purchase Ticket”

 Mô tả tóm tắt:

về các chuyến bay và có thể đặt mua vé và kết thúc

 Mô tả các kịch

nhập thành công vào hệ thống

(còn nữa)

Phân tích thiết kế hướng đối tượng Bài 4 - 21/31

Thí dụ tài liệu luồng sự kiện

 Làm tài liệu các luồng sự kiện cho UC “Purchase Ticket”

 Các bước trong luồng sự kiện chính

1.UC bắt đầu khi customer chọn chức năng xem thông tin chuyến bay

2.Hệ thống hiển thị thành phố đến, đi và thời gian hạ cánh, cất cánh

3.User nhập nơi đến, đi, thời gian ngày tháng khởi hành và trở về

4.Hệ thống hiển thị danh sách chuyến bay và giá vé

A1 Không còn chuyến bay

5.User chọn chuyến bay để đặt trước

6.Hệ thống hiển thị các loại vé để user chọn

7.User chọn giá vé

A2 User chọn giá vé cho thành viên frequent-flyer

8.Hệ thống hiển thị giá vé sẽ bán cho khách hàng

9.User khẳng định giá vé

10 Hệ thống hiển thị loại thẻ tín dụng, số thẻ, thời gian hết hạn

11 User nhập loại thẻ tín dụng, số thẻ, thời gian hết hạn

12 Hệ thống trình mua bằng thẻ

(còn nữa)

Trang 8

Phân tích thiết kế hướng đối tượng Bài 4 - 22/31

Thí dụ tài liệu luồng sự kiện

A6 Không thấy tài khoản

A7 Không đủ tiền

E1 Không xâm nhập được hệ thống tín dụng

13.Hệ thống dành chỗ cho user

14.Hệ thống phát sinh và hiển thị mã xác thực cho user

15.User khẳng định đã nhận mã

16.Use case kết thúc

 Luồng phụ

A1 Không có chuyến bay

1 Hệ thống hiển thị thông điệp thông báo không có chuyến bay

2 User khẳng định thông điệp

3 Trở lại luồng chính Bước 2

A2 Vé dành cho thành viên frequent-flyer

1 Hệ thống hiển thị số hiệu frequent-flayer

2 User nhập số

3 Hệ thống khẳng định tính hợp lệ của số

A3 Số không hợp lệ

Phân tích thiết kế hướng đối tượng Bài 4 - 23/31

Thí dụ tài liệu luồng sự kiện

 Làm tài liệu các luồng sự kiện cho UC “Đăng ký môn học”

 Mô tả tóm tắt:

học kỳ nào đó

 Tóm lược: Sinh viên chọn một học kỳ rồi sau đó có thể thêm, bỏ,

xem in các môn học, chọn ngày học, chọn lớp và kết thúc

 Đối tác: sinh viên

 Mô tả các kịch

 Điều kiện đầu vào: Ca sử dụng được thực hiện khi sinh viên đăng

nhập thành công vào hệ thống và chỉ hoạt động được khi ca sử dụng

duy trì thông tin môn học đã được thực hiện

(còn nữa)

Phân tích thiết kế hướng đối tượng Bài 4 - 24/31

Thí dụ đặc tả ca sử dụng

 Ca sử dụng này bắt đầu khi sinh viên đăng nhập vào hệ thống ĐKMH

và nhập mật khẩu của mình

 Hệ thống kiểm tra thấy mật khẩu là đúng đắn (R1) và nhắc sinh viên chọn năm

học, học kỳ này hay sau (R2)

 Sinh viên chọn học kỳ, năm học

 hệ thống nhắn sinh viên chọn việc trong Thêm, Bỏ, Xem, In, Ra

 Nếu thêm được chọn thì kịch bản con: C1- Thêm một mộn học được

thực hiện

 Nếu Bỏ được chọn thì kịch bản con: C2- Bỏ một mộn học được thực

hiện

 Nếu Xem được chọn thì kịch bản con: C3- xem một lịch biểu được

thực hiện

 Nếu in được chọn thì kịch bản con: C4- In một lịch biểu được thực

hiện

 Nếu Ra được chọn thì ca sử dụng kết thúc

Trang 9

Thí dụ đặc tả ca sử dụng

 Các kịch bản con

 C1: Thêm một môn học

 Hệ thống hiển thị danh sách các môn học có thể được chọn

 Sinh viên chọn môn (R3)

 Hệ thống hiển thị các lớp và tên thầy giáo dạy + thời gian

 Sinh viên chọn lớp

 Hệ thống gán lớp học + môn cho sinh viên

Phân tích thiết kế hướng đối tượng Bài 4 - 25/31

 Các kịch bản khả dĩ khác

 R1: Mật khẩu đưa vào là không hợp lệ, người dùng có thể nhập lại

hoặc kết thúc ca sử dụng

 R2: Học kỳ đưa vào là không đúng đắng Người dùng có thể nhập

lại học kỳ hặc kết thúc ca sử dụng

 R3: Các lớp giảng không hiển thị được: Thông báo cho người dùng

là chọn lựa đó chưa sẵn sàng ở thời điểm hiện tại, Ca sử dụng bắt

đầu lại

 R4: Kết nối không được thiết lập: Thông tin được sao lưu và hệ

thống sẽ kết nối sau

vtduong2010 Phân tích thiết kế hướng đối tượng 26/62

Đặc tả ca sử dụng

 Các cách mô tả khác

 Mô bả gồm 2 sự kiện chính và các sự kiện ngoại lệ Các sự kiện chi

làm 2 luồng, luồng tương tứng với tác nhân và luồng tương ứng

với hệ thống

Phân tích thiết kế hướng đối tượng Bài 4 - 27/31

Hành động của tác nhân Hành động của hệ thống

Sinh viên: Đưa vào mật

khẩu và tên đăng nhập

2 Hệ thống xác nhận mật khẩu và tên đăng nhập 3.Sinh viên chọn học kỳ và

năm học

4.Hệ thống hiển thị các môn học có thể có trong học kỳ 5.Sinh viên chọn môn học 6 Hệ thống ghi nhận việc

chọn môn học 7.Sinh viên kết thúc việc

chọn môn

Trang 10

Đặc tả ca sử dụng

 Tóm lại

Xác định các ca sử dụng nhiều có thể

Không đi vào quá chi tiết nhằm giảm độ phức tập

Mô tả ngắn gọn về mỗi ca sử dụng là đủ

Đảm bảo rằng các ca sử dụng bao gồm hết các yêu cầu của hệ

thống

Phân tích thiết kế hướng đối tượng Bài 4 - 28/31

Phân tích thiết kế hướng đối tượng Bài 4 - 29/31

Các quan hệ

 Quan hệ kết hợp (Association)

 Là loại quan hệ giữa tác nhân và UC

 Mũi tên cho biết ai là người khởi xưởng giao tiếp

Customer Purchase Ticket

Customer Purchase Ticket Credit System

Quan hệ gộp giữa 2 Use-case

 Dùng để liên kết 2 Use-case: có stereotype là <<include>>

 Trong Use-case nguồn có điểm mở rộng mà tại đó bắt

buộc phải chèn Use-case đích vào

 Tại điểm mở rộng, diễn tiến của use-case nguồn tạm thời ngừng

lại để chuyển sang diễn tiến của use-case đích

 Khi kết thúc use-case đích, diễn tiến của use-case nguồn lại tiếp

tục

 Quan hệ ký hiệu là mũi tên đứt nét, đầu mũi tên huướng về UC

đích kèm theo khuôn dập <<include>>

Đăng nhập (UC đích)

<<include>>

Tìm kiếm (UC nguồn)

Ngày đăng: 20/03/2015, 10:02

TỪ KHÓA LIÊN QUAN

w