BÀI 8 LÀM VIỆC VỚI CÁC STATE DIAGRAM
lượt xem 85
download
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...
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: BÀI 8 LÀM VIỆC VỚI CÁC STATE DIAGRAM
- 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 diagram. Các diagram chúng ta đã học trước dùng để mô hình hóa hành vi của một hệ thống hoặc ít nhất cũng là một nhóm các class, object hoặc use case. Trong khi đó, state diagram lại biểu diễn các trạng thái của một object thôi. Trang 1 – Bài 8
- Tập ký hiệu: Hình 8.1 cho thấy một hình chữ nhật tròn góc biểu diễn cho một trạng thái (state) cùng với mũi tên biểu diễn sự chuyển dịch (transition). Hình cũng cho thấy 2 loại vòng tròn khác nhau biểu diễn cho các điểm đầu và điểm cuối. Hình 8.1 Biểu tượng UML trong một state diagram. Các chi tiết trong biểu tượng trạng thái Hình 8.2: Có thể chia một biểu tượng trạng thái thành các phần để biểu diễn tên, biến trạng thái và các hoạt động Nếu như biểu tượng class được chia thành 3 phần là name, attribute và operation thì biểu tượng trạng thái cũng có thể được chia thành 3 phần. Phần trên là tên (name) trạng thái (buộc phải có dù có chia biểu tượng trạng thái hay không), phần giữa là các biến trạng thái (state variable) và phần cuối là các hoạt động (activity). Hình 8.3 Các trạng thái của 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ể chỉ ra một sự kiện dẫn đến sự chuyển dịch (trigger event) và hành động (action) làm thay đổi trạng thái. Đôi lúc, một event gây ra một transition mà không có một action kết hợp và đôi lúc một transition xuất hiện do một trạng thái kết thúc một hành động (không phải bởi một event). Loại transition này được gọi là chuyển dịch không kích (triggerless transition). Ví dụ về các chi tiết chuyển dịch trong GUI. Giả sử GUI có thể là một trong ba trạng thái: initializing, working, shutting down. Khi mở công tắc PC, quá trình khởi động diễn ra. Việc mở công tắc PC là “triggering event” khiến GUI chuyển dịch đến trạng thái “initializing” và quá trình khởi động trở thành một “action” diễn ra trong quá trình chuyển dịch. Việc chuyển dịch GUI đến trạng thái “working” là kết quả của các hành động trong trạng thái “initializing”. Khi ta chọn shut down PC, ta tạo ra một trigger event mà gây ra sự chuyển dịch GUI đến trạng thái “shutting down” và PC tắt. Hình 8.4 biểu diễn state diagram ghi nhận các trạng thái và chuyển dịch trên của GUI. Hình 8.4 Các trạng thái và chuyển dịch của một giao diện người dùng đồ họa (GUI) bao gồm sự kiện kích, hành động và chuyển dịch không kích Bổ sung chi tiết cho sự dịch chuyển trạng thái: các Guard Condition Quay trở lại ví dụ trên với GUI, nếu ta bỏ mặc computer (không gõ phím hoặc dùng mouse) trong một khoảng thời gian nhất định, hiện tượng screen saver sẽ xuất hiện. Một trạng thái mới - trạng thái “screensaving” – không có trong hình 8.4. Trang 3 – Bài 8
- Khoảng thời gian cho screen saver được đặc tả trong Windows Control Panel. Nó thường là 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 Việc người dùng nhập liệu sẽ kích sự chuyển dịch từ “Awaiting User Input” sang “Registering User Input”. Các hoạt động (activity) trong “Registering User Input” sẽ chuyển dịch GUI sang “Visualizing User Input”. Sau trạng thái thứ ba, GUI quay trở về “Awaiting User Input”. Hình 8.6 cho thấy cách biểu diễn các trạng thái con tuần tự trong trạng thái “working” của GUI. Trang 4 – Bài 8
- Hình 8.6 Các trạng thái con tuần tự GUI gồm trạng thái “screensaving” và một điều kiện bảo vệ Trạng thái con đồng thời Trong trạng thái “working”, GUI không phải chỉ chờ người dùng. Nó cũng theo dõi giờ hệ thống (system clock) và cập nhật hiển thị của một ứng dụng sau một khoảng thời gian nhất định. Ví dụ, một ứng dụng có đồng hồ hiển thị trên màn hình mà GUI cần cập nhật. Theo hình 8.7, các trạng thái “watch system clock” và “update display” tạo thành 1 chuỗi tuần tự và nó diễn ra cùng lúc với chuỗi tuần tự đã đề cập ở trên. Hai chuỗi tuần tự này là đồng thời nhau. Hình 8.7 Các trạng thái con đồng thời tiếp diễn cùng lúc. Nét đứt dùng để ngăn cách các trạng thái con đồng thời. Thuật ngữ: Trạng thái “working” là một trạng thái ghép (composite state). Một trạng thái 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 cũng có các thuộc tính. Do một signal cũng là một object nên nó cũng có thể tạo phân cấp thừa kế của các signal. Tầm quan trọng của state diagram UML state diagram cung cấp nhiều loại biểu tượng và chứa đựng nhiều ý tưởng nhằm mô hình hóa các thay đổi mà một object trải qua. Trong thực tế, state diagram rất cần thiết bởi nó giúp các phân tích viên, thiết kế viên và lập trình viên hiểu được hành vi của object trong một hệ thống. Một class diagram và object diagram tương ứng chỉ cho biết khía cạnh tĩnh của hệ thống. Chúng biểu diễn sự phân cấp, mối quan hệ của các object. Chúng không cho thấy các chi tiết động của các hành vi. 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. Với một bức tranh rõ ràng về hành vi của object, khả năng nhóm lập trình viên sẽ tạo ra một hệ thống thỏa mãn yêu cầu càng dễ trở thành hiện thực. Bức tranh tổng thể về state diagram Hình 8.9 Bức tranh tổng thể của UML giờ đây có thêm các thành phần hành vi, đó là state diagram. Trang 6 – Bài 8
- Tóm lược Các object trong một hệ thống thay đổi trạng thái của chúng nhằm đáp ứng lại các sự kiện cũng như thời gian. State diagram của UML ghi nhận các thay đổi trạng thái này. Một state diagram tập trung vào sự thay đổi trạng thái chỉ trong một object. Một hình chữ nhật tròn 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 1. Giả sử bạn đang thiết kế một lò nướng bánh (toaster). Hãy tạo một state diagram để theo dõi các trạng thái của bánh mì trong lò nướng, bao gồm triggering event, action và guard condition. 2. Mỗi khi một object gửi một signal, nó sẽ tạo một đối tượng signal và truyền nó. Trong windows, một số signal từ user đến GUI. Giả sử Signal là một class các signal ta gửi đến Windows. Hãy tạo một class diagram các signal có thể, trong đó biểu diễn tất cả mối quan hệ thừa kế. Trang 7 – Bài 8
CÓ THỂ BẠN MUỐN DOWNLOAD
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn