Bài giảng Phân tích và thiết kế hệ thống thông tin: Phần 3 - Nguyễn Anh Hào

Phân tích & thiết kế H.T.T.T
Phần 3: Phân tích hệ thống
Nguyễn Anh Hào
Khoa CNTT2 – HV CNBCVT Cơ sở Tp.HCM
0913609730 –


Nội dung bài giảng

2

1. Hành động phân tích hệ thống
2. Yêu cầu đ/v hệ thống từ môi trường
3. Đặc tả hệ thống
•
•
•

Coi hệ thống là một đối tượng lớn: ranh giới của nó
tách hệ thống thành 2 phần: bên trong và bên ngoài
Nhìn từ ngoài: đặc tả những gì hệ thống sẽ làm cho
môi trường (usecase)
Nhìn vào bên trong: đặc tả kết cấu các thành phần
(đối tượng) cần thiết của hệ thống (classes) và các
quan hệ giữa các đối tượng này.


SE: phân tích hệ thống

3

• Trong SE, phân tích hệ thống:
– Là quá trình chuyễn đổi yêu cầu đ/v hệ thống thành đặc tả
về hệ thống. Các đặc tả này sẽ phải hiện thực trong hệ
thống sau khi nó được “cải tạo”.
– Đặc tả hệ thống = cấu trúc logic của hệ thống, nhìn từ phía
người phát triễn hệ thống, trong đó:
• Có các thành phần hợp thành hệ thống (các đối tượng)
• Có các quan hệ nội tại giữa các thành phần, mà người phát
triễn phải tìm ra và sử dụng chúng.

• Yêu cầu đối với hệ thống:
– Từ đâu ra ? Có phải là từ người sử dụng ? … Tất cả các câu
hỏi này phải được giải đáp từ cách lý giải về sự tồn tại của
hệ thống bằng lý thuyết hệ thống


Sự tương tác của hệ thống
Đề thực hiện được vai trò, hệ thống phải có các tương tác với môi
trường để tạo ra / lấy những thứ cần thiết cho / từ môi trường. Sự tương
tác này hình thành các yêu cầu chức năng của hệ thống.

Hệ thống là cổ
máy biến inputs
thành outputs
cho môi trường

4


Quan hệ giữa hệ thống - môi trường

5

• Hệ thống lớn (môi trường) phải giải quyết nhiều vấn đề
để giúp nó tồn tại, được gọi là miền vấn đề (problem
domain).
– Vd: Công ty phải làm gì để tồn tại được ?...

• Miền vấn đề chứa các vấn đề có tính quy luật (khách
quan, và kết dính với nhau theo cách nào đó)
– Vd: chuổi nghiệp vụ của tổ chức được xem là “bất biến”
(khách quan) vì người ta có lý do để làm như vậy.
– Domain Model: mô hình cho miền vấn đề

• Hệ thống đang xem xét là một bộ phận của hệ thống
lớn, do đó nó có vai trò hổ trợ giải quyết tốt các vấn đề
của hệ thống lớn, thông qua các tương tác của nó.


Yêu cầu từ môi trường

6

• Sự tương tác giữa hệ thống với môi trường bên ngoài
hình thành yêu cầu đối với hệ thống (cái gì nó phải
làm ra, và phải chuyễn giao như thế nào,…)
• Yêu cầu (từ tương tác) được xác định đúng (giải quyết
đúng bản chất của vấn đề trong miền vấn đề) thì hệ
thống sẽ hoạt động ổn định (ít bị thay đổi).
• Như vậy, khía cạnh đầu tiên của việc phân tích yêu

cầu là hiểu đúng bản chất của các tương tác trong môi
trường mà hệ thống sẽ vận hành.
– Phân tích các quan hệ cộng tác với nhau ở bên ngoài
(trong hệ thống lớn hơn) và có liên quan đến hệ thống.


Cách đặc tả hệ thống (1)

7

A. Nhìn hệ thống từ bên ngoài (outside view – ‘what’):
1. Xác định phạm vi trách nhiệm (vai trò) của hệ thống.
2. Mô hình hóa các quy luật cộng tác trong môi trường
có hệ thống tham gia.
–
–

Tìm ra các quy luật cộng tác mang tính bản chất
Vẽ Workflow,Dataflow,Collaboration,Activity, …

3. Xác định các tương tác cơ bản nhất, quyết định vai
trò của hệ thống trong môi trường (Usecases)
4. Đặc tả ứng xử của hệ thống đ/v từng usecase
–

“Phương thức” của hệ thống, scenario


Vai trò của use-case
Nhìn từ bên ngoài: Hệ thống sẽ làm được gì cho

hệ thống lớn hơn (qua sự cộng tác với các actors)
Use case
Nhìn vào bên
trong: Những đối
tượng trong hệ
thống hợp tác thực
hiện use-case như
thế nào ?
Ranh giới của phần mềm

8


Lược đồ use case: nhìn từ ngoài

9

1. Với các đối tượng có trong hệ thống lớn (môi trường):

–

Đối tượng nào cần hệ thống phần mềm này, hoặc
phần mềm này cần đối tượng nào ?

2. Định nghĩa use-case

–

Sự hợp tác trên có ý nghĩa gì đối với hệ thống lớn ?

3. Định nghĩa actor

–

Vai trò của các đối tượng trong hệ thống lớn (hoặc đối
với usecase) là gì ?

4. Vẽ lược đồ use case – nhìn từ bên ngoài cho hệ thống phần
mềm


ví dụ 1: coffee drink
Người ta cần gì ở tách cà phê ?

10


Coffee cup: interfaces

11


Coffee cup: use cases - external

Filling

Drinking

Pouring
Holding

Sitting

Holding

12


Ví dụ 2: Quản lý kho trong nhà hàng13
Tiền trả
Nhà cung câp
(cung ứng)
Chính phủ
(ra luật)
Đối thủ
(cạnh tranh)
Khách hàng
(tiêu thụ)

Nguyên liệu

Quy định

Kho
(lưu trữ)
Nguyên liệu
Nhà bếp
(chế biến)

Hàng hóa,

Dịch vụ
Tiền trả

Văn phòng
(điều khiển)

Thông tin,
mệnh lệnh

Thức ăn
Quầy phục vụ
(bán)

Tiền thu


Các tương tác liên quan đến kho
“Trả tiền mua ….”
Nhà cung câp
(cung ứng)

Kho
(lưu trữ)

“Tôi đặt mua …”
Người bán

“Tôi giao …”

Văn phòng

(điều khiển)
“Đề nghị trả tiền …”

Thủ kho

“Tôi cần …”

Giám đốc

“Xuất … cho …”

UML dùng thông điệp
để diễn tả cho tương tác

Nhà bếp
(chế biến)
Đầu bếp

14


Thông điệp (message)

15

• Thông điệp là một thông báo mang yêu cầu hoặc phản hồi, gửi
từ một đối tượng đến một đối tượng.
• Trong UML, thông điệp được diễn tả là:
[điều kiện] <tên loại thông điệp> (thông sô)
– [điều kiện]: điều kiện để thông điệp xuất hiện (biểu thức logic)

– <tên loại thông điệp>: tên của thông điệp
– (thông số): các thuộc tính của nhóm thông điệp

• Ví dụ, sau khi login, khách có thể đặt hàng trên website:
[acc=valid] Đặt hàng (mã kh,mã hàng,số lượng, ngày)


Kho của nhà hàng: Lược đồ cộng tác16
Trả tiền (tiền, hđ#)
Đặt mua(hàng,slg)

Người bán

y/c trả tiền (tiền, hđ#)

Thủ kho

Giám đốc

Giao(hàng,slg,hđ#)
y/c xuất(hàng,slg, pyc#)

Xuất (hàng,slg, pyc#)

Đầu bếp

Trong UML v2: lược đồ này gọi là communication diagram


Quản lý kho: use-cases (a)

PM quản lý kho
Đặt
hàng
Người bán
Nhập
kho
Giám đốc

Đầu bếp

Thủ kho

y/c trả
tiền
Xuất
kho

Phạm vi sử dụng của phần mềm (a): chỉ giới
hạn ở các tương tác với thủ kho

17


Quản lý kho:use-cases (b)
PM quản lý kho
Đặt
hàng
Nhập
kho

Thủ kho

y/c trả
tiền

Người bán

Giám đốc

Xuất
kho
Đầu bếp

Phạm vi sử dụng của phần mềm (b): có các tương
tác với thủ kho, người bán, giám đốc, và đầu bếp

18


Ví dụ 3: hệ thống khóa cửa

19

• Hệ thống khóa cửa yêu cầu chìa khóa là số pin để mở
cửa. Có 2 tình huống: số pin đúng và số pin sai
Book_SE_2012.pdf Page 82


Lược đồ tuần tự: chìa khóa đúng

20


Lược đồ tuần tự: chìa khóa sai

21


Lược đồ usecase: hệ thống khóa cửa22

Book_SE_2012.pdf Page 92


Usecase - Glossary
– glossary: là chuỗi quá trình tương tác giữa hệ thống
phần mềm với actor
USECASE: <Tên>

Actors

Actor’s goal

<tên actor>

<mục đích của actor>

Tình huống tương tác trên usecase
1. Actor <name> : <Hành động của actor trên usecase>
2. SYSTEM: <Đáp ứng của hệ thống theo sự kiện trước>
3…

23


Test usecase

24

• Để biết xem usecase có ích như thế nào ?
• BOSS TEST:
– “What have you been doing all day?”
– “Log in !” is a very, very bad answer (no value)

• The Elementary Business Process (EBP) test
– Một công việc sẽ phải góp phần tạo ra giá trị cho tổ
chức (xử lý các sự kiện / tình huống / vấn đề cho tổ
chức)
– Good: Nhận đơn đặt hàng, xác nhận đơn hàng
– Bad: xem, xóa, sửa,in,… đơn đặt hàng (là các tác vụ ở
mức chức năng)


Test Use-case example
Is this a useful use case diagram for ATM ?

NO ! A use case should satisfy a goal for the actor.

25