BÀI 8
LÀM VIỆC VỚI CÁC STATE DIAGRAM

Chúng ta đã tìm hiểu về các thành phần cấu trúc quan trọng của UML. Trong bài này, chúng
ta tìm hiểu về một thành phần giúp biểu diễn những thay đổi trạng thái của object diễn ra
theo thời gian. Nội dung chính của bài:
 State diagram là gì?
 Các sự kiện, hành động và các điều kiện che/ chắn (guard condition)
 Các trạng thái con (substate): tuần tự và đồng thời
 Các trạng thái quá khứ
 Tầm quan trọng của state diagram
 Cách thức bổ sung state diagram vào mô hình UML

Thuật ngữ: Yếu tố hành vi (behavioral element), biểu diễn cách thức mà các thành phần
của một mô hình UML thay đổi theo thời gian.

State diagram là gì?
Một cách để mô tả sự thay đổi trong một hệ thống là nói rằng các đối tượng của hệ thống
thay đổi trạng thái (state) của chúng nhằm đáp ứng các sự kiện (event) và thời gian (time).
Một vài ví dụ:
Khi ta nhấn công tắc, đèn thay đổi trạng thái của nó từ “off” sang “on” hoặc ngược lại.
Khi ta bấm vào một điều khiển từ xa, một tivi thay đổi từ kênh này sang kênh khác.
Sau một khoảng thời gian thích hợp, máy giặt sẽ chuyển từ trạng thái giặt (wash) sang
giũ (rinse)

Thuật ngữ: Sơ đồ trạng thái (state diagram) ghi nhận các loại thay đổi như trên. Nó biểu
diễn các trạng thái mà một object có thể có cùng với sự chuyển dịch giữa các trạng thái,
đồng thời cho thấy điểm đầu (starting point) và điểm cuối (endpoint) của một chuỗi thay
đổi. State diagram còn có tên khác là state machine

Chú ý rằng một state diagram khác rất nhiều so với một class diagram hoặc một use case

máy fax có các biến
trạng thái và các
hoạt động. Trang 2 – Bài 8
Các biến trạng thái đóng vai trò giống bộ đo thời gian (timer) hoặc bộ đếm (counter). Các
hoạt động bao gồm sự kiện (event) và hành động (action). 3 loại hoạt động thường dùng là
entry (việc diễn ra khi hệ thống vào trạng thái), exit (việc diễn ra khi hệ thống rời trạng thái)
và do (việc diễn ra khi hệ thống trong trạng thái).
Trong ví dụ máy fax ở trên, khi nó đang gửi 1 fax, tức đang trong trạng thái “faxing” thì
máy fax cho thấy ngày, giờ nó bắt đầu gửi fax (các giá trị của biến “date” và “time”) và
cũng cho thấy số điện thoại của nó cũng như tên người gửi (các giá trị biến “phone number”
và “owner”). Trong khi ở trạng thái này, máy fax thực hiện những việc như thêm ngày giờ
gửi, số điện thoại, tên người gửi (datestamp, timestamp, phone number, owner) vào nội
dung fax, và một số hoạt động khác. Khi nó ở trạng thái nghỉ (idle), máy fax hiển thị trên
màn hình ngày giờ hiện hành.

Bổ sung chi tiết cho sự dịch chuyển trạng thái: các Event và các Action

Thuật ngữ: Ta có thể thêm một số cho tiết đến các dòng chuyển dịch (transition). Ta có thể

15 phút. Bất cứ việc gõ phím hay di chuyển mouse nào cũng chuyển dịch màn hình từ trạng
thái “screensaving” trở lại trạng thái “working”.

Thuật ngữ: khoảng thời gian 15 phút đó được gọi là một điều kiện bảo vệ (guard
condition), mà khi nó thỏa thì sự chuyển dịch sẽ xảy ra. Hình 8.5 biểu diễn state diagram
cho GUI có bổ sung trạng thái “screensaving” và guard condition. Chú ý rằng “guard
condition” được viết như là một biểu thức Boolean.

Hình 8.5
State diagram cho
GUI gồm trạng thái
“screensaving” và
một điều kiện bảo vệ Các trạng thái con (substate):

Thuật ngữ: Khi GUI đang ở trạng thái “working”, nó vẫn thay đổi tạo nên nhiều trạng thái
khác. Các trạng thái cư trú bên trong một trạng thái một trạng thái khác được gọi là trạng
thái con (substate). Substate chia làm 2 loại: tuần tự (sequential) và đồng thời (concurrent).

Trạng thái con tuần tự
Các trạng thái con tuần tự xuất hiện nối tiếp nhau. Trở lại các substate như đã đề cập ở trên
trong trạng thái “working” của GUI, ta có tuần tự sau:
Awaiting User Input
Registering User Input
Visualizing User Input

bao gồm các trạng thái con tuần tự cũng là một trạng thái ghép.

Các trạng thái quá khứ
Khi chế độ screen saver đang khởi động và ta di chuyển mouse để GUI trở lại trạng trái
“working”, điều gì sẽ xảy ra? Màn hình trở về trạng thái như lúc ngay sau khi GUI được
khởi động hay như lúc trước khi screen saver đến?
Hình 8.8
Trạng thái quá khứ,
ký hiệu bởi chữ H
trong vòng tròn nhỏ,
cho biết rằng một
trạng thái ghép ghi
nhớ trạng thái con
tích cực của nó khi
một đối tượng chuyển
dịch ra khỏi trạng
thái ghép. Trang 5 – Bài 8
Thông điệp (message) và báo hiệu (signal):
Trong ví dụ, trigger event gây ra sự chuyển dịch từ “screesaving” đến “working” là một gõ
phím (keystroke) hoặc một dịch chuyển mouse hoặc một kích mouse. Bất cứ sự kiện nào ở
trên cũng là một thông điệp từ người dùng (user) đến GUI. Đây là một khái niệm quan trọng
bởi các object liên lạc bằng cách gửi message cho nhau. Trong trường hợp này, trigger event
là một thông điệp từ một object (user) đến object khác (GUI).

Thuật ngữ: Một thông điệp kích một sự chuyển dịch trong state diagram của object nhận
được gọi là báo hiệu (signal). Trong thế giới hướng đối tượng, việc gửi một signal chính là
việc tạo một đối tượng báo hiệu (signal object) và truyền nó đến object nhận. Signal object

góc biểu diễn một trạng thái và một mũi tên biểu diễn sự chuyển dịch từ trạng thái này sang
trạng thái khác.
Biểu tượng trạng thái có tên trạng thái và có thể nắm giữ các biến trạng thái cũng như các
hoạt động trong trạng thái. Một sự chuyển dịch (transition)nhằm phản ứng lại một trigger
event và có thể đưa đến một hành động. Một transition cũng có thể xuất hiện do một hoạt
động trong một trạng thái. Một transition xuất hiện kiểu đó được gọi là một triggerless
transition. Cuối cùng, một transition có thể xuất hiện do một điều kiện cụ thể xảy ra, gọi là
guard condition.
Đôi khi, một trạng thái gồm các trạng thái con. Các trạng thái con có thể tuần tự (sequential)
hoặc đồng thời (concurent). Một trạng thái chứa các trạng thái con được gọi là trạng thái
ghép (composite state). Một trạng thái quá khứ (history state) cho biết một trạng thái ghép
ghi nhớ trạng thái con của nó khi object chuyển dịch ra khỏi trạng thái ghép.
Khi một object gửi một message kích một sự chuyển dịch trong state diagram của object
khác (receiving object) thì message đó là một signal. Một signal tự thân nó là một object và
ta có thể xây dựng một cây phân cấp thừa kế của các signal.
Cần có các state diagram vì chúng giúp các phân tích viên, thiết kế viên và lập trình viên
hiểu hành vi của các object trong một hệ thống. Những lập trình viên cần phải biết cách thức
object hoạt động bởi họ phải hiện thực những hành vi này trong phần mềm. State diagram
đảm bảo rằng lập trình viên không phải “đoán mò” object sẽ hoạt động như thế nào.

Câu hỏi
1. Cách tốt nhất để khởi đầu một state diagram là gì?
2. Mọi state diagram đều phải có trạng thái kết thúc phải không?
3. Các gợi ý khi trình bày một state diagram?
4. Một state diagram khác một class diagram, object diagram hoặc use case diagram ở
những điểm quan trọng nào?
5. Định nghĩa các thuật ngữ: transition, event, action
6. Thế nào là một triggerless transition?
7. Sự khác nhau giữa sequential substate và concurrent substate?
Bài tập