Biểu đồ trình tự UML tập trung vào tƣơng tác giữa các đối tƣợng khác nhau trong một UC (trong nghiên cứu của chúng ta, chúng ta đề cập một UC nhƣ một thành phần) trong biểu đồ cộng tác thông tin đƣợc miêu tả tƣơng tác có thứ tự trong thứ tự tuần tự thông điệp.
Tài khoản
Thẻ ATM
Giao dịch ATM <<Nghiệp vụ>>
Quản lý giao dịch rút tiền
Client component * * * * * * * * * * * * W3 W1 W8 W4A.1 W5A.2 W5B.2 W8 W4 W5 W5A W5B W2 W6 W7 W4A W5A1 W5B1 ATM server component
Hình 2.3. Biểu đồ cộng tác của thành phần máy chủ ATM
W1: Yêu cầu rút tiền (chi tiết giao dịch) W5A.1: Ghi giao dịch kiểm tra tài khoản W2: Kiểm tra giới hạn thẻ (mã thẻ, số tiền) W5A2: Trả lời khách ( sai tài khoản) W3: Trả lời về giới hạn thẻ W5B: Quỹ thiếu
W4: Trừ tiền giao dịch (tài khoản, số tiền) W5B.1: Ghi giao dịch quỹ
W4A: Ghi giao dịch kiểm tra thẻ W5B.2: Trả lời khách (quỹ thiếu) W4A1: Trả lời khách (vƣợt quá giới hạn rút) W6: Cập nhật giới hạn thẻ (card id, số tiền)
W5: Dữ liệu tài khoản W7: Ghi giao dịch.
W5A: Sai tài khoản W8: Trả lời khách
Hình 2.3 miêu tả một phần biểu đồ trình tự của thành phần máy chủ ATM. Biểu đồ cộng kết hợp tất cả các kịch bản theo thứ tự. Hình 2.3, W5, W5A, và W5B chứng minh ba lựa chọn thay thế có thể xuất hiện sau thông điệp W4 bởi đối tƣợng quản lý giao dịch rút cho đối tƣợng tài khoản ATM.
Với biểu đồ cộng tác, chúng ta có thể lựa chọn mối quan hệ phụ thuộc ngữ cảnh chúng ta với trình tự có thể, nhƣ Hình 2.3 trong biểu đồ cộng tác có thể gọi đến mô hình chính xác làm thế nào giao diện và sự kiện tƣơng tác với nhau.
42
2.4.2 Sử dụng mô hình
2.6[Xác thực]: Xác thực PIN 2.6A [Hủy hiệu lực]: PIN không có hiệu lực 2.6B: Hủy tính hiệu lực thứ 3 của PIN
<<Thiết bị đọc I/O>>: Đầu đọc thẻ
<<Giao diện thiết bị I/O>>: Giao diện đọc thẻ
<<Thực thể>> Thẻ ATM
<<Giao diện người dùng>> Thẻ ATM
<<Thực thể>> Giao dịch ATM <<Điều khiển trạng thái>>
Bộ điều khiển ATM Ngân hàng phục vụ
* *
1. Thẻ đưa vào đầu đọc
1.1A Không nhận diện được thẻ: Từ chối
* *
1.1 Dữ liệu thẻ: Dữ liệu đọc
* * 1.2 Thẻ được đưa vào
*
*
1.3: Tiếp nhận PIN 2,6A.1: Thông báo số Pin sai 2.7: Hiển thị menu 2A.2a: Từ chối hiển thị
Khách hàng ATM
* *
1.4: Yêu cầu Pin 2.6A.2: Thông báo số Pin sai 2.8: Menu lựa chọn 2A.2a.1: Thông báo từ chối
2; 2.6A.3: Nhập số Pin 2A: Từ chối nhập * * 2.1; 2.6A.4: Yêu cầu đọc thẻ 2,2; 2.6A5: Dữ liệu thẻ * * 2,3; 2.6A6: Thông tin khách hàng 2A.1: Từ chối 2.4; 2.6A7: Dữ liệu thẻ, PIN 2.5; 2.6A8: Xác thực tính hợp lệ PIN * * * *
2.6A.1a; 2.6.1a; 2.7a: Cập nhật trạng thái 2A.2: Hủy
2.6B.1: sung công 2A.2: Hủy
2.6B.1: sung công
Hình 2.4. Biểu đồ cộng tác cho PIN hợp lệ
Nhƣ ta thấy, tuần tự “ 2A - 2A.1 - 2A.2, 2A.2a - 2A.3, 2A.2a.1( 2A.2 và 2A.2a là 2 thông điệp tồn tại cùng lúc) chỉ chuỗi cho phép ngƣời dùng hủy. Tuy thế, chuỗi này có thể xảy ra trong hoàn cảnh khác, nhƣ khi ngƣời dùng hủy giao dịch hiện tại sau khi đã nhập số PIN, hoặc ngƣời dùng hủy giao dịch hiện thời sau khi nhập sai số PIN. Với việc sử dụng biểu đồ cộng tác, ta có thể thấy rõ chuỗi các chuỗi thực hiện nhƣ sau:
Bằng cách sử dụng biểu đồ cộng tác, các giao tiếp giữa giao diện với các sự kiện có thể đƣợc làm rõ hơn.
Các mối quan hệ phụ thuộc về nội dung, mối quan hệ phụ thuộc ngữ cảnh phản ánh các chuỗi điều khiển của đối tƣợng trong một cấu phần với các tƣơng tác giữa actors và cấu phần đó. Tuy nhiên, các mối quan hệ phụ thuộc nội dung khác với các tƣơng tác là nó không thể chứa thông tin luồng điều khiển.Ví dụ, xem hình mô phỏng giao dịch phục vụ của máy ATM. Cấu phần
gồm 2 giao diện - rút tiền và gửi tiền. Các quan hệ phụ thuộc ngữ cảnh có thể mô tả tƣơng tác giữa các giao diện, nhƣng các quan hệ phụ thuộc nội dung giữa các giao diện không thể hiện đƣợc. Theo đó, giao diện rút tiền phụ thuộc giao diện gửi tiền bởi vì giao dịch gửi tiền sẽ cập nhật vào đối tƣợng tài khoản, trong khi giao dịch rút tiền sẽ sử dụng nó để kiểm tra xem còn đủ tiền trong tài khoản không. Nhƣng mặt khác, các quan hệ phụ thuộc nội dung không đƣợc đặc tả một cách trực tiếp trong chƣơng trình cũng nhƣ trong bất cứ lƣợc đồ nào. Để đặc tả các quan hệ phụ thuộc nội dung, thêm nữa là việc xử lý của các lƣợc đồ UML là cần thiết. Rất nhiều các tiếp cận có thể bỏ qua.
Để mô hình hóa các mối quan hệ phụ thuộc về nội dung, chúng ta loại ra các quan hệ phụ thuộc không có hiệu lực:
Nếu I2 vẫn còn lại trong trạng thái ban đầu, S1m sau lời gọi I1, mối quan hệ phụ thuộc không ảnh hƣởng đến hoạt động cuả phần mềm; mối quan hệ phụ thuộc đó là không hiệu quả.
Từ một trạng thái S, nếu lời gọi của I2 cho trạng thái S2, sẽ không ảnh hƣởng gì đến việc giao diện I1 có đƣợc gọi hay không. Trạng thái chuyển đổi chính là yếu tố xác định các quan hệ phụ thuộc. Ƣu điểm của các cách tiếp cận trên cơ sở UML có thể thấy đƣợc qua: (i) Các lƣợc đồ UML thƣờng đƣợc sử dụng đến trong pha phân tích và chịu sự tích hợp với cấu phần cung ứng. Hơn nữa, ngƣời dùng cấu phàn có thể nhận đƣợc các mẩu thông tin thông qua các lƣợc đồ thể hiện. Điều này thể hiện tính mềm dẻo, khả năng mở rộng và tính hiệu quả trên sự phát triển phần mềm cấu phần; (ii) Các mối quan hệ phụ thuộc ngữ cảnh và phụ thuộc về nội dung, điều kiện kiểm thử cung cấp trong mô hình của chúng ta sẽ đƣợc cập nhật theo:
Mỗi bƣớc chuyển tiếp trong lƣợc đồ cộng tác phải đƣợc kiểm thử ít nhất một lần.
44
Mỗi luồng đúng trong lƣợc đồ cộng tác phải đƣợc kiểm thử ít nhất một lần.
Mỗi quan hệ phụ thuộc về nội dung nhận đƣợc từ lƣợc đồ cộng tác phải đƣợc kiểm thử ít nhất một lần.
Mỗi quan hệ phụ thuộc nội dung một cách hiệu quả nhận đƣợc từ lƣợc đồ cộng tác phải kiểm thử ít nhất 1lần.
Chương 3
XÂY DỰNG ỨNG DỤNG THỬ NGHIỆM