Bài giảng kiến trúc phần mềm - Mô hình Use case

Tác nhân có thể được phân thành 02 loại: Tác nhân chính Primary actor là tác nhân sử dụng những chức năng căn bản của hệ thống các chức năng chính.. Use case: Use case trong ngôn ngữ U

Mô hình Use case

Khoa Công nghệ thông tin Trường Đại học Nguyễn Tất Thành

1

1 Giới thiệu

2 Sơ đồ Use case / Các phần tử trong sơ đồ use case

3 Xác định Actor

4 Xác định Use case

5 Lập sơ đồ Use case

6 Các mối quan hệ của Use case

7 Mô tả Use case và các dòng sự kiện

8 Kiểm tra và xác nhận sơ đồ Use case

Nội dung

2

hình Use

case

Sử dụng kiến thức

cơ sở ngành làm nền tảng cho kiến thức chuyên ngành

Sử dụng kiến thức

cơ sở ngành làm nền tảng cho kiến thức chuyên ngành

Vận dụng được kiến thức ngành trong việc phân tích thiết kế và đánh giá chất lượng phần mềm

Xây dựng chương trình phần mềm từ bảng thiết

kế và từ

mã nguồn

có sẵn

cứu tài liệu chuyên môn bằng tiếng Anh

Xây dựng

kế hoạch cho dự án

Có trách nhiệm trong công việc được giao

Mục tiêu bài học

Mô hình hoá là phương pháp làm việc khoa học, giúp hiểu rõ hơn về

1 Giới thiệu

Thông qua mô hình Use case, nhà phát triển nắm bắt được các vấn đề trong hệ thống và có giải pháp phù hợp

Mô hình Use case giúp chỉ ra được phương thức hoạt động của hệ thống tương lai theo hướng nhìn của người dùng

Mô hình Use case được mô tả trong ngôn ngữ UML qua sơ đồ Use case (Use case diagram) và tài liệu mô tả kèm theo

Mô hình Use case có thể có nhiều sơ đồ Use case

Câu hỏi: Ai quan tâm đến mô hình use case?

1 Giới thiệu

5

Những thành phần có trong một mô hình Use case là: Hệ thống, Use

case, Actor Hệ thống được mô tả qua các chức năng mà nó sẽ thực thi

2.1/ Hệ thống (system):

Là phạm vi của bài toán cần xem xét Lưu ý rằng một hệ thống không nhất thiết là một hệ thống thông tin/hệ thống phần mềm, nó có thể là một cái máy, hoặc tổ chức, doanh nghiệp,

Ví dụ: Máy ATM, Tổ chức bán vé qua trạm, bộ phận Checkin tại sân bay, được hiểu là các hệ thống

2 Sơ đồ Use case

6

đã học trong lập trình hướng đối tượng

Một Use case bao giờ cũng được kích hoạt bởi một tác nhân (gửi thông điệp đến Actor)

2 Sơ đồ Use case

7

Tác nhân có thể được phân thành 02 loại:

Tác nhân chính (Primary actor) là tác nhân sử dụng những chức năng căn bản của hệ thống (các chức năng chính) Ví dụ: trong một hệ thống bảo hiểm, một tác nhân căn bản là xử lý việc mua và quản lý các hợp đồng bảo hiểm

Tác nhân phụ (Secondary actor) là tác nhân sử dụng các chức năng phụ của hệ thống, Ví dụ như các chức năng bảo trì hệ thống, backup

dữ liệu

2 Sơ đồ Use case

8

2.3/ Use case:

Use case trong ngôn ngữ UML được định nghĩa là các hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được

Sự trừu tượng hóa chuỗi các hành động mà nó sinh ra các chức năng

Mô tả các chức năng người dùng có thể nhìn thấy được

Luôn được khởi động bởi tác nhân

Use case cho thấy tương tác giữa tác nhân và hệ thống

2 Sơ đồ Use case

9

Kỹ thuật cơ bản để xác định tác nhân là trả lời một số các câu hỏi sau:

Ai sẽ sử dụng những chức năng chính của hệ thống (tác nhân chính)?

Ai cần sự hỗ trợ của hệ thống để thực hiện những tác vụ hàng ngày của họ?

Ai cần bảo trì, quản trị và đảm bảo cho hệ thống hoạt động (tác nhân phụ)?

Hệ thống cần phải tương tác với các hệ thống khác nào?

Ai hay đối tượng nào sử dụng kết quả mà hệ thống sẽ sản sinh ra?

3 Xác định Actor

Một kỹ thuật khác: Mô tả bài toán bằng đoạn văn bản (mô tả tóm tắt),

gạch dưới các đại từ/chủ từ, nó sẽ là các tác nhân dự tuyển của Use case diagram

Khi nhận diện tác nhân dự tuyển, chúng ta sẽ lọc ra các thực thể nào đáng quan tâm theo khía cạnh sử dụng và tương tác với hệ thống Sau

đó chúng ta có thể thử đặt mình vào vị trí của tác nhân để cố gắng nhận

ra các yêu cầu và đòi hỏi của tác nhân đối với hệ thống và xác định tác nhân cần những Use Case nào

3 Xác định Actor

11

Biểu diễn Actor

3 Xác định Actor

Hình 1: Ký hiệu biểu diễn Actor

Ví dụ: Xác định các tác nhân trong các hệ thống sau:

Đăng ký môn học tại trường Đại học NTT

Mua vé vào cửa Thảo cầm viên

Chứng nhận hồ sơ tại phường

Việc tìm các Use case bắt đầu với các tác nhân đã được xác định ở phần trước Đối với mỗi tác nhân, hãy trả lời các câu hỏi sau:

 Những chức năng nào mà hệ thống thực hiện?

 Những chức năng nào mà các Actor yêu cầu?

 Đầu vào / đầu ra của hệ thống đi và đến đâu?

 Gạch dưới các động từ/cụm động từ được dùng mô tả hệ thống

Những gì xác định được chọn lọc để trở thành Use case

4 Xác định Use case

Lưu ý khi xác định Use case:

• Use case là chức năng trọn vẹn

• Không xác định các Use case quá nhỏ (chia nhỏ chức năng)

• Có quá nhiều Use case

Đối với hệ thống lớn, Use case diagram được chia thành các gói

(package) gồm có: 1 Use case diagram tổng quát + nhiều Use case

diagram chi tiết theo các chức năng nhỏ hơn (nhiều gói)

4 Xác định Use case

15

Ví dụ: Xác định các Use case trong các hệ thống sau:

• Đăng ký môn học tại trường Đại học NTT

• Mua vé vào cửa Thảo cầm viên

• Chứng nhận hồ sơ tại phường

4 Xác định Use case

Biểu diễn Use case

4 Xác định Use case

Hình 2: Ký hiệu biểu diễn Use case

17

Gồm các bước sau:

 Xác định hệ thống, phạm vi của hệ thống và viết mô tả bài toán

 Xác định các Actor

 Xác định các Use case

 Phân tích mô hình Use case theo bài toán chia nhỏ: 1 sơ đồ Use case

tổng quát + nhiều sơ đồ Use case chi tiết (phân rã mô hình Use case)

 Lập sơ đồ Use case bằng phần mềm (Star UML, Microsoft Visio,…)

 Thiết lập mối quan hệ trong sơ đồ Use case

5 Lập sơ đồ Use case

18

5 Lập sơ đồ Use case

Hình 3 _ Sơ đồ Use case

Giữa các Use case có thể có mối quan hệ tương tác xảy ra, có các loại mối quan hệ sau:

6.1/ Quan hệ <<include>> giữa các use case:

Là quan hệ của 1 Use case có bao hàm Use case khác Quan hệ

<<include>> là ‘bắt buộc’ và được biểu diễn bằng mũi tên đứt nét từ Use

case bao hàm đến Use case included và đi kèm với stereotype <<include>> đặt cạnh đoạn thẳng này như hình

Ví dụ: quan hệ <<include>> giữa các Use case (Sv thảo luận và giải thích ý nghĩa)

6 Các mối quan hệ của Use case

22

Chúng ta thấy Use Case “Verify

Password” có thể gộp chung vào

Use Case Login nhưng ở đây chúng

ta tách ra để cho các Use Case khác

sử dụng hoặc để module hóa cho dễ

hiểu, dễ cài đặt

6.2/ Quan hệ <<extend>> giữa các use case:

Là quan hệ của 1 Use case có thể mở rộng hành vi từ 1 Use case khác

Quan hệ này là ‘tùy chọn’ và được biểu diễn bằng mũi tên đứt nét từ

Use case mở rộng (extending) đến Use case gốc (base) và đi kèm với stereotype <<extend>> đặt cạnh đoạn thẳng này như hình

6 Các mối quan hệ của Use case

23

Quan hệ Extend được sử dụng khi có một Use Case được tạo ra để bổ sung chức năng cho một Use Case có sẵn và được sử dụng trong một điều kiện nhất định nào đó

6.2/ Quan hệ <<extend>> giữa các use case:

6 Các mối quan hệ của Use case

Trong ví dụ trên “Open Account” là Use Case cơ sở để cho khách hàng

mở tài khoản Tuy nhiên, có thêm một điều kiện là nếu khách hàng là công ty thì có thể thêm người sở hữu lên tài khoản này Add Account Holder là chức năng mở rộng của Use Case “Open Account” cho trường hợp cụ thể nếu Actor là Công ty nên quan hệ của nó là quan

hệ Extend

Ví dụ: quan hệ <<extend>> giữa các Use case (Sv thảo luận và giải thích ý nghĩa)

6 Các mối quan hệ của Use case

25

6.3/ Quan hệ kế thừa giữa các use case:

Quan hệ thừa kế giữa Use case A và Use case B nói lên rằng Use case

B kế thừa những đặc điểm của Use case A ngoài ra nó cũng có thể có thêm những đặc trưng riêng của nó

Quan hệ này được biểu diễn bằng mũi tên từ Use case kế thừa (con) đến Use case cho kế thừa (cha)

6 Các mối quan hệ của Use case

Ví dụ: quan hệ kế thừa giữa các Use case (Sv thảo luận và giải thích ý nghĩa)

6 Các mối quan hệ của Use case

27

7.1/ Mô tả Use case:

Mô tả một Use case thường được thực hiện bằng văn bản Đây là

lời đặc tả về việc các tác nhân và các Use case trong hệ thống tương tác với nhau ra sao

Ngôn ngữ và các thuật ngữ được sử dụng trong lời mô tả chính là ngôn ngữ giao tiếp và các thuật ngữ được sử dụng sao cho khách hàng/người dùng có thể hiểu được Mô tả cho từng Use case theo mẫu sau: xem tai đây

7 Mô tả Use case và các dòng sự kiện

Số hiệu _ Tên Use case Requirements Mô tả yêu cầu chức năng mà Use case phải cung cấp đến người

dùng cuối Chúng tương ứng với các đặc tả chức năng tìm thấy sau khi phân tích hệ thống

Actors Chỉ ra các tác nhân nào làm việc với Use case này

Pre-conditions Điều kiện gì xảy ra trước khi Use case thực hiện

Post-conditions Điều kiện gì xảy ra sau khi Use case thực hiện

Constraints Constraint là một phát biểu về điều kiện ràng buộc hoặc giới

hạn mà Use case hoạt động dưới nó

Điều kiện ràng buộc phải là đúng (True) trong lúc thực thi Use case

Include Use case có / không là <<include>> cho Use case nào?

Extend Use case có / không là <<extend>> cho Use case nào?

Extension Points Điểm mở rộng khi Use case thực hiện vai trò extend

Mẫu mô tả Use case 1

29

Mẫu mô tả Use case 2

Số hiệu _ Tên Use case Requirements Mô tả yêu cầu chức năng mà Use case phải cung cấp đến người dùng

cuối Chúng tương ứng với các đặc tả chức năng tìm thấy sau khi phân tích hệ thống

Actors Chỉ ra các tác nhân nào làm việc với Use case này

Pre-conditions Điều kiện gì xảy ra trước khi Use case thực hiện

Post-conditions Điều kiện gì xảy ra sau khi Use case thực hiện

Triggers Phát biểu về điều kiện ràng buộc hoặc giới hạn mà Use case hoạt động

dưới nó

Điều kiện ràng buộc phải là đúng (True) trong lúc thực thi Use case

Normal Flow Dòng hành động chính

Alternative Flow Dòng hành động thay thế

Exception Flow Dòng hành động lỗi

7.2/ Các dòng sự kiện:

Mỗi sơ đồ Use case sẽ có một dòng hành động chính (Primary flow / Normal flow), đó là tiến trình bình thường hay tiến trình mong đợi đối với Use case này

Ngoài ra, có thể còn có một hay nhiều dòng hành động thay thế (Alternative flow) khác Chúng có thể được chia làm hai nhóm chính:

• Thay thế bình thường (Normal Alternative)

• Điều kiện gây lỗi (Error Conditions / Exception flow ) hay còn gọi

là dòng hành động lỗi

7 Mô tả Use case và các dòng sự kiện

31

Ví dụ: một khách hàng có thể chọn các loại giao dịch sau của ATM:

• Gửi tiền vào

• Rút tiền ra

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

Các hành động trên là dòng hành động chính

 Nếu kiểm tra mức tiền trong tài khoản có nhiều hơn 02 triệu thì rút ra 02

triệu, còn ít hơn 02 triệu thì không rút đó là dòng hành động thay thế

 Điều kiện gây lỗi là 3 lần nhập sai mật khẩu là đại diện cho những tiến trình bất bình thường của một Use case Cần phải tính trước đến những điều kiện gây lỗi đó

7 Mô tả Use case và các dòng sự kiện

Giai đoạn cuối cùng của mô hình Use case là kiểm tra và xác nhận Use case

8.1/ Kiểm tra (Verification) là đảm bảo hệ thống đã được phát triển đúng đắn và phù hợp với các đặc tả đã được tạo ra

Áp dụng Kỹ thuật đi dọc theo Use case (Walkthrough): là một trong

những kỹ thuật hữu dụng được dùng trong cả giai đoạn định nghĩa lẫn thử nghiệm Use case gọi là "Đi bộ dọc Use case”

Kỹ thuật này sẽ xác định còn Use case nào thiếu sót hay không?, nếu thiếu phải bổ sung vào Use case

8 Kiểm tra và xác nhận sơ đồ Use case

33

Theo kỹ thuật này, nhiều người khác nhau trong nhóm sẽ đóng vai hệ thống, vai tác nhân Người đảm nhận vai tác nhân sẽ bắt đầu bằng yêu cầu tác nhân làm gì với hệ thống Kết quả của công việc này là hệ thống sẽ khởi động một Use case cụ thể Người đóng vai hệ thống sẽ nói cần làm gì khi Use case được thực hiện Nhà phát triển đứng bên ngoài trò diễn kịch để ghi chép và tìm cách phát hiện ra các điểm thiếu sót trong mô hình

8 Kiểm tra và xác nhận sơ đồ Use case

Các "diễn viên" càng hiểu thấu đáo hệ thống bao nhiêu thì công việc thử Use case sẽ càng hiệu quả bấy nhiêu Việc thay đổi các diễn viên

để đóng những vai trò khác nhau sẽ dẫn tới những thay đổi trong mô

tả và hướng nhìn, cung cấp dữ liệu đầu vào cho mô hình để mô tả Use case rõ ràng hơn, minh bạch hơn, và chỉ ra những điểm còn thiếu

8 Kiểm tra và xác nhận sơ đồ Use case

35

8.2/ Phê duyệt (Validation) là sự xác nhận đảm bảo rằng hệ thống sẽ

được phát triển đúng là những gì mà khách hàng hoặc người sử dụng cuối thật sự cần đến

8 Kiểm tra và xác nhận sơ đồ Use case

Công việc phê duyệt xác nhận được thực hiện trước giai đoạn phát

triển hệ thống Khi một mô hình Use case được hoàn thành, nó phải được trình bày và thảo luận với khách hàng / người sử dụng Họ cần phải xác nhận rằng mô hình này là đúng đắn, hoàn tất và thỏa mãn sự mong đợi của họ đối với hệ thống; đặc biệt là phương cách mà hệ thống cung cấp chức năng cho họ Nếu hệ thống không thỏa mãn những yêu cầu cụ thể của người sử dụng thì toàn bộ dự án rất có thể sẽ phải làm lại từ đầu

8 Kiểm tra và xác nhận sơ đồ Use case

37

Sinh viên chuẩn bị trước các bài tập Giảng viên đã cho, thực hiện phân tích, tạo sơ đồ Use case (có mô tả Use case):

• Mỗi buổi thực hành nộp 03 bài

• Không sao chép bài của nhau

Tổng kết bài

Thảo luận các bài tập và Q/A

39