Bài giảng Phân tích thiết kế hệ thống thông tin - Chương 5: Mô hình hóa chức năng sử dụng use case

1

2

Nội dung
PHÂN TÍCH THIẾT KẾ
HỆ THỐNG THƠNG TIN

1.

2.
3.

Chương 5. Mơ hình hóa chức năng
sử dụng use case

4.
5.

Mơ hình hóa chức năng
Biểu đồ use case
Đặc tả use case
Biểu đồ activity
Case study

3

Mô hình hóa chức năng

4

1.1. Bức tranh PTKTHT

• Bức tranh PTKTHTTT
• Mục đích
• Mơ hình hóa chức năng

1


5

Bức tranh PTKTHT (2)

6

1.2. Mục đích
• Thiết lập và duy trì sự thoả thuận giữa khách

hàng và người tham gia dự án về việc hệ thống
sẽ làm được những gì
• Khơng nói làm như thế nào để đạt được điều đó

• Giúp cho những người phát triển hệ thống một

sự hiểu biết rõ hơn về những yêu cầu của hệ
thống

• Đưa ra những giới hạn mà hệ thống sẽ thực hiện và

KHƠNG thực hiện

• Cung cấp các thơng tin cơ bản để lập kế hoạch phát

triển dự án

7

1.2. Mục đích (2)

8

1.2. Mục đích (3)

• Cung cấp những cơ sở để ước lượng giá thành và thời

gian để phát triển hệ thống
• Nắm bắt được những u cầu và mục đích của người sử
dụng

2


9

10

1.3. Mơ hình hóa u cầu (3)

1.3. Mơ hình hóa chức năng
• Mơ hình hóa các chức năng mà hệ thống sẽ thực thi

• Mơ hình bao gồm các chức năng định trước của hệ thống
• Sử dụng khái niệm Use Case

Các thành phần chính:

11

Nội dung
1.
2.
3.
4.
5.

12

Biểu đồ Use-Case

Mơ hình hóa yêu cầu
Biểu đồ use case
Đặc tả use case
Biểu đồ activity
Case study

3


13

2.1. Actor và use case

14

2.1.1. Tác nhân
Tác nhân biểu diễn các vai trị của
một người dùng trong hệ thống

• Tác nhân (actor) biểu diễn bất cứ

thứ gì tương tác với hệ thống.



Ví dụ như các thiết bị ngoại vi, thậm chí là
database

Actor
• Use case (Chức năng)
• Mơ tả chức năng mà hệ thống có
• Mục đích là để PHÂN TÍCH u cầu
nghiệp vụ của bài tốn chứ khơng
phải để THIẾT KẾ phần mềm

Có thể là người, máy móc hoặc hệ thống
khác mà chúng ta khơng phải xây dựng



Có thể chủ động trao đổi thơng tin với hệ
thống

Có thể là người đưa thơng tin vào hệ thống
Có thể là người nhận thông tin.

Use Case


Actor

Không phải là một phần của hệ thống
Actors are EXTERNAL.

15

Tìm kiếm tác nhân của hệ thống
• Đặt các câu hỏi sau để tìm ra tác nhân:
– Nhóm người nào yêu cầu hệ thống làm việc giúp họ?
– Nhóm người nào kích hoạt chức năng của hệ thống?
– Nhóm người nào sẽ duy trì và quản trị hệ thống hoạt
động?
– Hệ thống có tương tác với các thiết bị hay phần mềm
ngoại vi nào khác hay khơng?
• Thơng tin về tác nhân:
– Tên tác nhân phải mô tả vai trị của tác nhân đó một
cách rõ ràng
– Tên nên là danh từ
– Cần mô tả khái quát khả năng của tác nhân đó

16

Ví dụ về tác nhân

Tác nhân 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

4


17

Tìm use case của hệ thống

2.1.2. Use case
Mỗi Use-Case biểu diễn cho một chức năng của hệ
thống
Use-Case là một chuỗi bao gồm nhiều hành động
Mỗi Use-Case có thể mở rộng (extext) thành nhiều UseCase khác
Mỗi Use-Case có thể bao hàm (include) nhiều Use-Case
khác
Use-Case được đặt bên trong phạm vi hệ thống
Ký hiệu: hình elip + tên Use-Case (động từ)

Use Case

18

Mượn sách

19

Những điều nên tránh khi tạo UC

• Xem các yêu cầu chức năng để tìm ra các UC
• Đối với mỗi tác nhân tìm được, đặt các câu hỏi:
– Các tác nhân yêu cầu những gì từ hệ thống
– Các cơng việc chính mà tác nhân đó muốn HT thực thi?
– Tác nhân đó có tạo ra hay thay đổi dữ liệu gì của HT?
– Tác nhân đó có phải thơng báo gì cho HT?
– Tác nhân đó có cần thơng tin thơng báo gì từ HT?

• Thơng tin về use case:
– Tên của UC nên chỉ rõ kết quả của quá trình tương tác với
tác nhân
– Tên nên là động từ
– Mơ tả ngắn gọn về mục đích của UC

Nguyễn Thị Thu Trang, SE-FIT-HUT

20

Ví dụ: Xác định tác nhân và Use Case

• Tạo ra các UC quá nhỏ
• Hành động quá đơn giản mà chỉ cần mô tả bởi vài dịng

• Tạo ra q nhiều Use case (hàng chục)
• Nhóm các Use case liên quan thành một Use case tổng qt (mức
1)
• Mơ tả các Use Case tổng qt ở một sơ đồ khác (mức 2)
• Ví dụ: “Quản lý sách” bao gồm “Nhập sách”, “Xuất sách”, “…”

• Sử dụng các Use-case quá cụ thể, hoặc làm việc với dữ

liệu q cụ thể. Ví dụ:
• “Tìm sách theo tên” (nên là “Tìm sách”)
• “Nhập Pin vào máy ATM” (nên là “Nhập PIN”)
• “Thêm sách” (nên là “Quản lý sách” bao gồm “Thêm sách”)

5


21

Ví dụ: Xác định tác nhân và Use Case

23

Xác định Use Case

22

Phân loại tác nhân

Xác định Use Case

24

6


25

2.2. Mối liên hệ (relationship)

26

2.2.1. Mối liên hệ giữa các actor với nhau
• Khái qt hóa (Generalization)

• Mối liên hệ giữa các actor với nhau

• Tác nhân con kế thừa tính chất và

hành vi của tác nhân cha

• Khái qt hóa (Generalization)

• Mối liên hệ giữa actor và use case
• Giao tiếp
• Mối liên hệ giữa các use case với nhau
• Generalization: Khái qt hóa
• Include: Bao hàm
• Extend: Mở rộng

27

2.2.2. Mối liên hệ giữa actor với use case
• Thiết lập quan hệ giữa Tác nhân và Use Case
• Chúng tương tác bằng cách gửi các tín hiệu cho nhau
• Một use case mơ hình hóa một hội thoại giữa các tác

nhân và hệ thống
• Một use case được bắt đầu bởi một tác nhân để gọi một
chức năng nào đó trong hệ thống.

Association

Use Case

28

2.2.2. Mối liên hệ giữa actor với use case (2)
Chiều của quan hệ chính là chiều của tín hiệu gửi đi
• Từ tác nhân tới Use Case
• Kích hoạt Use case
• Hỏi thơng tin nào đó trong hệ thống
• Thay đổi thơng tin nào đó trong hệ thống
• Thơng báo cho UC về một sự kiện đặt biệt nào đó xảy ra với hệ thống
• Từ Use Case tới tác nhân:
• Nếu như có một điều gì đó xảy ra với HT và tác nhân đó cần được biết
sự kiện đó
• UC đơi khi cần hỏi thơng tin nào đó từ một tác nhân trước khi UC đó
đưa ra một quyết định

Actor

7


29

2.2.3. Mối liên hệ giữa các use case với
nhau

30

Quan hệ generalization

• Generalization

• Được sử dụng để chỉ ra một vài

• <<include>>
• always use

tính chất chung của một nhóm
tác nhân hoặc UC
• Sử dụng khái niệm kế thừa

• <<extend>>
• sometime use

• Mơ tả hành vi chung (chia sẻ) trong

UC cha

• Mơ tả hành vi riêng trong (các) UC

con

32

<<include>>
• Cho phép một UC sử dụng chức năng của UC khác
• Chức năng của UC Inclusion sẽ bắt buộc được gọi

trong UC Base
• Sử dụng stereotype là <<include>>

34

<<extend>>
• Cho phép mở rộng chức năng của một UC
• Chèn hành vi của UC Extension vào UC Base
• Chỉ chèn khi điều kiện extend đúng (mở rộng, phát sinh)

(Khi thực hiện thực hiện UC Base thì thực hiện UC
extension ở một số tình huống nào đó, chứ khơng bắt
buộc)
• Chèn vào lớp cơ sở tại điểm phát sinh (extension point)
• Sử dụng stereotype là <<extend>>

8


35

37

Nội dung

Biểu đồ Use Case
• Biểu

đồ use case
(use case diagram)

1.

• Là tập hợp các actor

2.

và các use case lại; bổ
sung các mối liên
quan
(association)
giữa chúng và lập
thành biểu đồ use
case

3.
4.
5.

Mơ hình hóa yêu cầu

Biểu đồ use case
Đặc tả use case
Biểu đồ activity
Case study

38

Đặc tả use case
• Đặc tả use case là gì?
• Mẫu đặc tả use case
• Ví dụ minh họa từ các case study

39

Đặc tả Use Case
• Kết thúc quá trình mơ hình hóa u cầu phải đặc tả lại tất

cả Use-case của hệ thống

• Mỗi Use-Case cần những thơng tin
• Tên
• Tên của Use case

• Mơ tả ngắn gọn:
• Mơ tả về vai trị và mục đích của use case, tránh kiểu diễn xi tên Use Case

• Ràng buộc (điều kiện)
• Tiền điều kiện
• Hậu điều kiện

• Luồng sự kiện (kịch bản):
• Mơ tả bằng lời những gì mà hệ thống sẽ làm thể hiện trên use-case, luồng sự

kiện chính, luồng sự kiện con, luồng sự kiện ngoại lệ.

• Biểu đồ hoạt động
• Minh họa luồng sự kiện bằng mơ hình

• Các u cầu đặc biệt…

9


40

41

Luồng sự kiện của use-case

Luồng sự kiện của use-case (2)

• Trả lời được quá trình từ khi bắt đầu đến khi kết thúc của

• Luồng chính (Basic flow)
• Luồng lý tưởng mà Use case thường hoạt động

một use-case

• Chỉ mơ tả chi tiết các sự kiện thuộc use-case đó
• Nếu có sự liên hệ với Use Case khác, nên có sự phân tích và tham

khảo ngắn gọn

• Mơ tả dữ liệu được trao đổi giữa tác nhân và use-case đó
• Cấu trúc: Ai làm gì, khi nào, với dữ liệu gì, [vì mục đích gì]
• Cần phân tích rõ hệ thống cần phải làm gì để đáp ứng được yêu
cầu của tác nhân đó. Khơng được mặc định cho rằng hệ thống tự
biết làm điều đó
• Tránh mơ tả chức năng hoặc GUI (Graphic User Interface)
• Tránh mơ tả chung chung, hoặc lúc nào cũng đúng

• Luồng phát sinh (Alternative flow)
• Sử dụng nhiều lần trong luồng chính
• Các trường hợp đặc biệt (vd nhấn mạnh một tính năng của HT)
• Gây ra lỗi, cách xử lý lỗi trong tình huống đó
• Chú ý
• Chỉ cần luồng chính là có thể hiểu được tác vụ chính mà Use Case
đó sẽ thực thi
• Phải có lời gọi luồng phát sinh từ luồng chính
• Tránh viết luồng phát sinh dài hơn luồng chính
• Tránh viết luồng phát sinh q dài
• Tránh tách quá nhiều luồng phát sinh

42

Luồng sự kiện của use-case (3)

43

Ví dụ

• Kịch bản là một thể hiện của UC đó
• Một Use Case có nhiều kịch bản tùy thuộc vào ngữ

cảnh cụ thể mà nó phát sinh

UC Rút tiền
1. Gọi UC “Xác thực KH”
2. Hiển thị menu.
3. KH chọn chức năng “Rút tiền”
4. ...

UC Xác thực KH
1. Đưa thẻ vào máy
2. Kiểm tra thẻ
3. KH nhập PIN
4. Hệ thống kiểm tra PIN
E1: Thẻ sai
E2: Sai PIN
E3: ...

10


44

Ràng buộc:

Luồng phát sinh “Rút tiền xu”
phát sinh tại bước 6 trong luồng

chính
• (Có thể có luồng phát sinh khác
như Hết tiền…)
• Luồng phát sinh Rút tiền xu:
(Phần này có thể viết chung với UC
Rút tiền, hoặc có thể viết riêng như
một UC nếu nó tương đối phức tạp)
1. Nếu KH chọn thể loại tiền xu
2. KH nhập số lượng xu
3. Hệ thống tính ra tổng số tiền
cần rút
4. KH chấp nhận
5. Khay tiền xu mở để xuất tiền
6. UC Rút tiền tiếp tục thực hiện
•

ID: 1

Tác nhân chính: người dùng

Loại Use-case: chi tiết cần thiết

Mức quan trọng: cao

Mức quan trọng:

Các
1.
2.
3.

4.

45

Loại:

mối quan hệ:
Kết hợp
Bao hàm
Mở rộng
Tổng qt hóa

Các dịng sự kiện tổng qt chính: /*mơ tả các dịng sự kiện chính*/
1. Hoạt động 1:
2. Hoạt động 2: /*hoạt động cho nhiều trường hợp xử lý*/
nếu <điều kiện> đúng thì thực hiện S-1: thực hiện công việc <A> /*TH1*/
nếu <điều kiện> đúng thì thực hiện S-2: thực hiện cơng việc <B> /*TH2*/
3. Hoạt động 3:
….
n. Hoạt động n:
Các dòng sự kiện chi tiết chính: /*mơ tả các hoạt động chi tiết cho các trường hợp trên*/
S-1: Thực hiện công việc A /*mô tả cho trường hợp 1 TH1*/
1. Hoạt động 1
2……
3. Hoạt động n
S-2: Thực hiện công việc B /*mô tả cho trường hợp 2 TH2*/
1. Hoạt động 1
2……
3. Hoạt động n
Các dịng sự kiện ngoại lệ: /*mơ tả các dịng sự kiện xử lý ngoại lệ cho các dòng sự kiện chính hoặc các dịng

sự kiện con*/
1.a. Hoạt động ngoại lệ cho hoạt động 1
3.a. Hoạt động ngoại lệ cho hoạt động 3
S-1 2.a. Hoạt động ngoại lệ cho hoạt động 2 trong S-1

46

Người liên quan và công việc quan tâm: người dùng muốn đăng nhập vào ht để thực hiện một thao tác trên
HT
Mơ tả tóm tắt: Use-Case này mô tả xử lý đăng nhập vào HT của một người dùng
Ràng buộc: Người dùng chọn chức năng đăng nhập từ trang chủ của HT
Loại: Bên ngồi
Các
1.
2.
3.
4.

Loại Use-case:

Mơ tả tóm tắt:

• Luồng phát sinh:

Tên Use-case: Đặng nhập

ID:

Tác nhân chính:

Người liên quan và cơng việc quan tâm:

Ví dụ đặc tả UC Rút tiền mặt
• Luồng chính:
1.Gọi UC “Xác thực KH” để
ktra KH
2.Hiển thị menu
3.KH chọn chức năng “Rút
tiền”
4.Nhập số tiền cần rút
5.HT gửi giao dịch tới ngân
hàng chờ chấp thuận
6.Máy ATM xuất tiền (tiền
giấy)
7.Trả lại thẻ
8.In biên lai

Tên Use-case:

mối quan hệ:
Kết hợp: Người dùng
Bao hàm: khơng có
Mở rộng: khơng có
Tổng qt hóa: khơng có

Các dịng sự kiện chính: /*mơ tả các dịng sự kiện chính*/
1. Hệ thống hiển thị trên màn hình đăng nhập
2. Người dùng chọn chức năng: /*hoạt động cho nhiều trường hợp xử lý*/
nếu người dùng nhập thông tin đăng nhập thực hiện S-1: xử lý đăng nhập
nếu người dùng chọn quên mật khẩu thực hiện S-2: xử lý quên mật khẩu

3. hệ thống hiển thị màn hình thông báo kết quả cho giao tác liên quan đến người dùng
Các dịng sự kiện con: /*mơ tả các hoạt động chi tiết cho các trường hợp trên*/
S-1: Xử lý đăng nhập
1. kiểm tra thông tin tài khoản
2. Hiển thị màn hình thơng báo đăng nhập thành cơng
S-2: Xử lý quên mật khẩu:
1. HT hiển thị màn hình để người dùng nhập Email
2. Người dùng nhập email và chọn nút chức năng lấy lại mật khẩu
3. HT kiểm tra email hợp lệ
4. Gởi liên kết để tạo lại mật khẩu mới
5. Gởi email thông báo đã tạo mới mật khẩu

47

Biểu đồ hoạt động
• Biểu đồ hoạt động trong mơ hình use case được sử dụng

để lưu lại các hoạt động và các hành động được thực
hiện trong một use case  Minh họa luồng sự kiện
• Biểu đồ luồng (flow chart): Chỉ ra luồng điều khiển từ hoạt động

hoặc hành động này đến hoạt động/hành động khác.
Flow of Events
This use case starts when the Registrar requests that the
system close registration.
1. The system checks to see if registration is in progress. If
it is, then a message is displayed to the Registrar and the
use case terminates. The Close Registration processing
cannot be performed if registration is in progress.

Activity 2

Activity 1

Activity 3

2. For each course offering, the system checks if a professor
has signed up to teach the course offering and at least three
students have registered. If so, the system commits the
course offering for each schedule that contains it.

Các dịng sự kiện ngoại lệ: /*mơ tả các dòng sự kiện xử lý ngoại lệ cho các dịng sự kiện chính hoặc các dịng
sự kiện con*/
S-1 2a. Xử lý nhập mật khẩu sai
1.
Hệ thống hiển thị lại màn hình đăng nhập để khách hàng nhập thơng tin.
2.
Quy lại bước 1 trong luồng sự kiện S-1
S-2.3a. Xử lý nhập email không hợp lệ
1. Hiển thị thông báo lỗi và yêu cầu nhập lại email
2. Quay lại bước 3 trong S-2

11


49

Biểu đồ hoạt động (2)

Biểu đồ hoạt động

• Hoạt động
• Đặc tả cho hành vi được diễn tả như một luồng thực thi

thông qua sự sắp xếp thứ tự của các đơn vị nhỏ hơn.
• Các đơn vị nhỏ hơn bao gồm các hoạt động lồng nhau và

các hành động riêng lẻ cơ bản
• Có thể chứa các ràng buộc biểu thức logic khi hoạt động

được gọi hoặc kết thúc

48

50

Biểu đồ hoạt động

51

Biểu đồ hoạt động

12


53

54

55

56

Biểu đồ hoạt động
• Được sử dụng để minh hoạ luồng sự kiện

13


60

Case study – Course Registration

61

Mơ hình hóa nghiệp vụ
• Xác định được phạm vi, hệ thống,

trực quan hóa hệ thống phức tạp

• Actor?

• Nắm bắt các yêu cầu nghiệp vụ, biểu

• Use case?
• Relationship?

Hệ thống

diễn các quy trình nghiệp vụ

• Biểu diễn sự thay đổi, cải tiến quy
trình đã tồn tại, hoặc xây dựng quy
trình mới, hoặc nâng cấp mơi
trường,…

Mơ hình hóa

62

63

Các bước mơ hình hóa nghiệp vụ

Các bước mơ hình hóa nghiệp vụ

• Đánh giá hiện trạng tổ chức
• Mục đích:

• Đánh giá hiện trạng tổ chức

• Đánh giá và nắm bắt thơng tin về tổ chức.
• Xác định các đối tượng liên quan (stakerholder) và khách hàng của hệ

thống.
• Định nghĩa phạm vị của việc mơ hình hóa nghiệp vụ.

• Nắm bắt thơng tin về tổ chức:
• Cơ cấu tổ chức, phân cấp và các vai trò trong hệ thống.
• Mơ tả ngắn gọn các thành phần và mối quan hệ này thơng qua
sơ đồ tổ chức

• Xác định những tiềm năng cải tiến và các mục tiêu mới của tổ chức.
• Mơ tả những mục tiêu chính của tổ chức.

Tổ văn phòng

Tổ bảo vệ

Tổ thu
ngân

Tổ mặt
hàng

Tổ tin học

Sơ đồ tổ chức của siêu thị

14


64

Các bước mơ hình hóa nghiệp vụ
• Đánh giá hiện trạng tổ chức
Mơ tả
Tổ văn
phịng

Gồm 1 Giám Đốc và 2 phó Giám Đốc có nhiệm vụ điều phối tồn

bộ hoạt động của siêu thị. Tổ phải nắm được tình hình mua bán,
doanh thu của siêu thị để báo cáo lại cho ban GĐ. Việc báo cáo
thực hiện hàng tháng, hàng quý hoặc cũng có khi báo cáo đột
xuất theo yêu cầu

Tổ bảo vệ

Kiểm tra và bảo vệ an ninh của siêu thị, ghi nhận hàng hóa đổi
lại của khách hàng

Tổ thu ngân

Thực hiện việc bán hàng và lập hóa đơn cho khách hàng, đồng
thời ghi nhận lại số hàng hóa bán được của mỗi loại để báo cáo
cho tổ quản lý sau mỗi ca làm việc

Tổ mặt hàng

Kiểm tra chất lượng hàng hóa và nắm tình trạng hàng hóa của
siêu thị, đảm bảo hàng hóa ln ở trong tình trạng tốt nhất khi
đến tay khách hàng. Khi phát hiện hàng hư hỏng phải kịp thời
báo cáo cho tổ văn phòng để có biện pháp giải quyết và điều
phối hàng

Tổ tin học

Thực hiện việc thu thập, kết xuất các báo cáo cần thiết phục vụ
cho tổ văn phịng

65

Các bước mơ hình hóa nghiệp vụ
• Đánh giá hiện trạng tổ chức
• Nắm bắt và phân tích các u tố sau:
• Hỗ trợ ra quyết định
• Ưu thế cạnh tranh
• Hồn vốn đầu tư, chỉ ra lợi kinh tế rõ ràng
• Giảm chi phí
• Hỗ trợ cho việc quản lý nghiệp vụ.
• Khả năng thực hiện công việc phải nhanh hơn và tốt hơn.

66

67

Các bước mơ hình hóa nghiệp vụ

Các bước mơ hình hóa nghiệp vụ

• Đánh giá hiện trạng tổ chức
• Xác định các đối tượng liên quan và khách hàng

• Đánh giá hiện trạng tổ chức
• Ví dụ: xác định các đối tượng liên quan và khách hàng trong hệ
thống siêu thị

• Đối tượng liên quanL là những người chịu ảnh hưởng trực tiếp từ các

tác động của hệ thống.
• Khách hàng: người dùng hệ thống, có thể những người liên quan

• Mơ tả nhu cầu của đối tượng liên quan

Tên

Đại diện

Vai trò

Người quản
lý

Giám đốc, người quản lý
siêu thị

Theo dõi tiến trình phát triển của dự án
và theo dõi tình hình hoạt động của siêu
thị

Nhân viên
bán hàng
Tên

Người nhập thông tin trong Chịu trách nhiệm trong khâu bán hàng
hệ thống
ở siêu thị, duy trì hoạt động của siêu thị
Mơ tả
Đối tượng liên quan

Người quản
lý

Đáp ứng các nhu cầu quản lý siêu thị
như hàng hóa, khách hàng, doanh số.

Người quản lý

Nhân viên
bán hàng

Đảm bảo rằng hệ thống sẽ đáp ứng các
nhu cầu của công việc bán hàng

Nhân viên bán hàng

Khách hàng

Đáp ứng nhu cầu tra cứu thơng tin về
hàng hóa có trong siêu thị

15


68

69

Các bước mơ hình hóa nghiệp vụ

Các bước mơ hình hóa nghiệp vụ

• Đánh giá hiện trạng tổ chức
• Giới hạn hệ thống phát triển

• Đánh giá hiện trạng tổ chức
• Giới hạn hệ thống phát triển

• Xác định ranh giới phát triển hệ thống bằng cách
• Chỉ ra những thực thể nằm ngồi hệ thống
• Chỉ ra những thực thể bên trong tổ chức như nằm ngoài hệ thống

70

Các bước mơ hình hóa nghiệp vụ
• Đánh giá hiện trạng tổ chức
• Ví dụ: xác định và trình bày các vấn đề của hệ thống

71

Các bước mơ hình hóa nghiệp vụ
• Xác định thuật ngữ nghiệp vụ

16


72

Mơ hình hóa nghiệp vụ với mơ hình Use case

73

Mơ hình hóa nghiệp vụ với mơ hình Use case
• Cách thực hiện
• Xác định ranh giới của nghiệp vụ
• Xác định tác nhân (Actor)
• Xác định nghiệp vụ/chức năng (Use-case)
• Xác định mối quan hệ giữa Actor với Actor, giữa Actor với Usecase, giữa Use-case với Use-case
• Mơ hình hóa nghiệp vụ với mơ hình Use-case

74

Mơ hình hóa nghiệp vụ với mơ hình Use case

17