Biểu đồ trình tự

mô tả sự trao đổi thông điệp giữa các đối tượng trình tự theo thời gian, thông điệp được gửi và nhận bởi các đối tượng đang hoạt động trong hệ thống. được thể hiện theo hai trục:

(i) Trục dọctrên xuống chỉ thời gian xảy ra các sự kiện, hay sự truyền thông điệp, được biểu diễn bằng các đường thẳng đứng đứt nét bắt đầu từ đỉnh đến đáy của biểu đồ.

(ii) Trục ngangtừ trái qua phải là dãy các đối tượng tham gia vào việc trao đổi các thông điệp với nhau theo chiều ngang, có thể có cả các tác nhân.

Đối tượng được biểu diễn bằng hình chữ nhật trong đó có tên đối tượng cụ thể và/hoặc tên lớp cùng được gạch dưới (hoặc tên lớp được gạch dưới biểu diễn cho một đối tượng bất kỳ của lớp đó).

được đọc từ trên xuống dưới, từ trái sang phải. Thứ tự các đối tượng trong biểu đồ phải được sắp xếp sao cho đơn giản nhất có thể để dễ quan sát. Thời gian thực hiện một thông điệp của một đối tượng, hay còn gọi là hoạt động của đối tượng được biểu diễn bằng hình chữ nhật hẹp dọc theo trục thẳng đứng của đối tượng đó.

Mỗi thông điệp đều có tên gọi thể hiện được ý nghĩa của thông tin cần gửi và các tham số về dữ liệu liên quan. Thông thường đó là các lời gọi hàm. Khi định nghĩa các lớp sau này thì mỗi thông điệp nhận được sẽ trở thành một phương thức. Một đối tượng có thể gửi thông điệp tới chính nó. Những thông điệp này gọi là phản thân, nó chỉ ra rằng đối tượng gọi chính các thao tác của mình để thực hiện.

Tác nhân ngoài kích hoạt các đối tượng trong biểu đồ trình tự hoạt động, nhưng nó không phải là phần tử của biểu đồ loại này.

Mặt khác, trong khi Notes được sử dụng để chú thích cho các đối tượng trong biểu đồ trình tự thì Scripts được sử dụng để chú thích cho các thông điệp. Chúng được đặt bên trái của một hoạt động của đối tượng , ngang với mức thông điệp cần chú thích. Scripts được sử dụng để mô tả các điều kiện logic hoặc điều kiện lặp, ví dụ lệnh IF hay WHILE, v.v. trong quá trình trao đổi thông điệp. Scripts không hỗ trợ để tạo ra mã chương trình, nhưng nó giúp cho người phát triển hệ thống biết được những điều kiện cần phải tuân theo.

Chúng ta xét tiếp ca sử dụng “Gọi điện thoại”, trong đó có hai tác nhân là Caller (người gọi) và Callee (người nghe) . Hệ thống nhận được các sự kiện vào được ký hiệu là các lời gọi hàm: liftReceiver() (nhấc tai nghe), dialsPhoneNumber() (quay số), answerPhone() (trả lời điện thoại) và hangUp() (đặt tai nghe xuống, nhấc tay lên). mô tả cho các hoạt động trên được xác định như sau:

Scripts trong biểu đồ trình tự

Các bước xây dựng biểu đồ trình tự

1. Xác định các tác nhân, các đối tượng tham gia vào ca sử dụng và vẽ chúng theo hàng ngang trên cùng theo đúng các ký hiệu,

2. Xác định những thông điệp (lời gọi hàm) mà tác nhân cần trao đổi với một đối tượng nào đó, hoặc giữa các đối tượng tương tác với nhau theo trình tự thời gian và vẽ lần lượt các hoạt động đó từ trên xuống theo thứ tự thực hiện trong thực tế. Cần xác định chính xác các loại thông điệp trao đổi giữa các đối tượng là đơn giản, đồng bộ hay dị bộ.

Chúng ta tiếp tục xây dựng một số biểu đồ trình tự mô tả các hành vi của hệ thống bán hàng HBH. Hành vi của hệ thống được thể hiện trong các biểu đồ trình tự thông qua sự tương tác của các đối tượng với nhau. Sự tương tác đó được thể hiện bằng các lời gọi hàm và sẽ được khai báo công khai (public) trong các lớp.

Biểu đồ mô tả hoạt động của người bán hàng và hệ thống

Như trong các kịch bản đã phân tích ở trên, sau khi chọn đủ hàng, người mua sẽ đưa giỏ (hoặc xe) hàng đến quầy để trả tiền. Người bán hàng phải nhập vào các thông tin và số lượng của mỗi mặt hàng. Những thông tin về mặt thường được xác định thông qua mã sản phẩm upc (thuộc lớp UPC – Universal Product Code). Vậy đối tượng :NguoiBan phải gửi đến cho :HeThong (một hệ thống bán hàng) thông điệp enterItems()(upc, n), để nhập vào mã sản phẩm upc và n đơn vị hàng cần mua. Khi đã nhập xong tất cả các mặt hàng của khách muốn mua thì phải báo cho hệ thống biết là đã nhập xong bằng cách nhấn nút Kết thúc, nghĩa là gửi cho hệ thống thông điệp endSale(). Hệ thống sẽ thông báo cho khách mua hàng biết tổng số tiền phải trả. Nếu khách hàng trả bằng tiền mặt thì :NguoiBan gửi tiếp đến cho :HeThong thông điệp makePayment(soTien).

Các hoạt động trên được mô tả trong biểu đồ trình tự như hình 3.

mô tả sự tương tác giữa người bán và hệ thống

mô tả ca sử dụng “Thanh toán tiền mặt”

Khi đối tượng :HeThong nhận được yêu cầu thanh toán của khách hàng thông qua người bán, nghĩa là nó nhận được thông điệp makePayment(soTien)thì nó phải gửi cho một đối tượng mộtphiênbánhàng:PhienBanHang một yêu cầu tương tự. Đối tượng mộtphiên bán hànglại yêu cầu đối tượng tạo ra một đối tượng mộtlần thanhtoán:ThanhToan để thanh toán theo soTienmà khách đưa. Đối tượng mộtlần thanhtoángửi lại thông điệp balance()cho hệ thống :HeThongbiếtsốtiềndư(soTienkhách đưa trừ đi số tiền mua hàng) phải trả lại cho khách và để hiển thị (displayBalance()) lên màn hình, để người bán thông báo lại cho khách hàng khi khách trả tiền mặt. mô tả dãy các hành động trao đổi giữa các đối tượng nêu trên được thiết lập như sau:

mô tả ca sử dụng “Thanh toán (tiền mặt)”

mô tả ca sử dụng “ Thanh toán bằng thẻ tín dụng”

Khi thanh toán tiền hàng, khách hàng có thể trả bằng thẻ tín dụng. Thẻ tín dụng được xác định thông qua soHieuThe (số hiệu thẻ) và hanSD (hạn sử dụng). Điều đó được thể hiện bằng việc gửi một thông điệp makeCreditPayment(soHieuThe, hanSD) cho hệ thống. Thông thường hệ thống phải gửi một yêu cầu kiểm duyệt thẻ requestApproval(yeuCau)) tới bộ phận kiểm duyệt thẻ tín dụng là tác nhân ngoài của hệ thống. Hệ thống sẽ dựa vào kết quả trả lời của bộ phận kiểm duyệt để thanh toán với khách hàng bằng cách trừ đi số tiền mua hàng trong thẻ tín dụng nếu nó hợp pháp, nghĩa là thực hiện handleCreditReply() (xử lý thẻ đã kiểm duyệt), dựa vào kết quả của bộ phận kiểm duyệt. mô tả sự tương tác giữa người bán hàng, hệ thống và bộ phận kiểm duyệt thẻ KiemDuyet được thiết lập như sau:

mô tả sự trao đổi giữa người bán, hệ thống và bộ phận kiểm duyệt

Tương tự như trên, chúng ta có thể tạo ra những biểu đồ trình tự cho các ca sử dụng khác của hệ thống.

Ở bài trước chúng ta đã xây dựng các lớp và tập trung chủ yếu vào việc phát hiện các thuộc tính của chúng. Khi đã xây dựng được các biểu đồ trạng thái và biểu đồ trình tự thì chúng ta đã hiểu hơn về sự tương tác giữa các đối tượng trong hệ thống. Chúng ta có thể dần dần xác định được hành vi ứng xử của các đối tượng, nghĩa là xác định các hàm thành phần của các lớp.

Nghiên cứu các biểu đồ trình tự chúng ta nhận thấy:

Khi có một thông điệp mgs() gửi đến cho một đối tượng thì lớp của đối tượng đó phải có hàm thành phần là msg().

Dựa vào nguyên lý nêu trên và căn cứ vào các biểu đồ trình tự ở hình 5-5, 5-6, 5-7, lớp HeThong sẽ có những hàm thành phần như sau:

Các thao tác của hệ thống được ghi nhận vào lớp có tên là HeThong

Khi xây dựng thêm biểu đồ trình tự cho ca sử dụng “Thanh toán bằng séc” thì những hàm như: makeCheckPayment(), handleCheckReply(), v.v sẽ được bổ sung thêm vào lớp HBH.

1. Để đơn gian, trong giai đoạn này chúng ta có thể bỏ qua các đối số của các hàm thành phần của các lớp.

2. Các hàm thành phần cũng có phạm vi truy cập giống như các thuộc tính trong các lớp đối tượng. Do vậy, người thiết kế có thể khai báo chúng là công khai (public), được bảo vệ (protected), sở hữu riêng (private) hay mặc định như đã nêu ở phần định nghĩa các thuộc tính .Tương tự, chúng ta bổ sung các hàm thành phần vào các lớp khác còn lại của HBH.

Như đã thấy ở trên, biểu đồ trình tự mới chỉ cho chúng ta biết tên của những nhiệm vụ mà mỗi đối tượng cần phải thực hiện khi nhận được một thông điệp, nhưng chưa mô tả cách thực hiện những công việc đó như thế nào. Để hiểu rõ hơn về những hành vi của các đối tượng và để hỗ trợ cho thiết kế và cài đặt các lớp sau này, chúng ta cần xây dựng các hợp đồng (Contract) hay các đặc tả cho những hoạt động (thao tác, hàm) đã xác định được. Hợp đồng cho các hoạt động của hệ thống mô tả về sự thay đổi trạng thái mà khi bắt đầu thì phải thoả mãn tiền điều kiện (pre-conditions) và sau đó, khi kết thúc sẽ thoả mãn hậu điều kiện (post-conditions). Những hợp đồng này có thể lưu ở những tệp khác nhau và được gán vào biểu đồ tương ứng.

• Pre-conditions: là những điều kiện mà trạng thái của hệ thống được giả thiết là thoả mãn trước khi thực hiện một thao tác, một hàm.
• Post-conditions: là những điều kiện mà trạng thái của hệ thống phải thoả mãn sau khi thực hiện xong một thao tác, một hàm.

Một cách hình thức, hợp đồng cho hoạt động Op() có thể viết theo bộ ba của Hoare:

{Pre-conditions} Op() {Post-conditions}

Thể hiện rằng: nếu hoạt động Op() bắt đầu từ trạng thái thoả mãn Pre-conditions thì sau khi kết thúc thực hiện hệ thống sẽ ở trạng thái thoả mãn Post-conditions.

Pre-condition và Post-condition là những mệnh đề boolean (mệnh đề điều kiện logic).

Ngoài Pre-conditions và Post-coditions, chúng có thể bổ sung thêm mô tả tóm tắt về trách nhiệm, kiểu, lớp nào, tham chiếu tới những chức năng nào, chú thích, những ngoại lệ và kết quả, v.v. [17].

Chúng ta có thể xây dựng các hợp đồng cho các qui trình xử lý thông tin như sau:

1. Từ các biểu đồ trình tự, xác định các thao tác, hàm, hoạt động của các lớp trong hệ thống,

2. Với mỗi thao tác trên hãy xây dựng một hợp đồng,

3. Mô tả tóm tắt những trách nhiệm chính mà hệ thống phải thực hiện khi thực thi thao tác này.

4. Trong Post-condition phải nêu được các trạng thái của các đối tượng sau khi kết thúc thao tác.

5. Để mô tả Post-conditions, hãy căn cứ vào:

+ Việc tạo lập, huỷ bỏ các đối tượng

+ Những thay đổi của các thuộc tính

+ Thiết lập hay huỷ bỏ các mối liên kết giữa các đối tượng.

Đặc tả các thao tác (hàm thành phần) của lớp HBH. Sau đây chúng ta xét một số đặc tả các hàm theo các hợp đồng chính.

1. Hợp đồng để nhập các thông tin về các mặt hàng

Hợp đồng

Tên gọi:	enterItems()(upc: UPC, soLuong: Int)
Trách nhiệm:	Nhập lần lượt cácthôngtinvề những mặt hàng mà khách đã chọn mua và đưa chúng vào phiên bán hàng. Hiển thị các thông tin mô tả và giá bán của từng mặt hàng.
Kiểu lớp:	System (Hệ thống)
Tham chiếu tói:	R1.1, R1.3, R1.9 và ca sử dụng Bán hàng
Chú ý:	Sử dụng phương pháp truy nhập nhanh vào CSDL
Ngoại lệ:	Nếu upckhông hợp lệ thì thông báo lỗi
Kết quả( Output ):
Pre-conditions:	UPC được biết trước
Post-conditions:	+ Nếu mặt hàng nhập vào là đầu tiên thì phải tạo ra một đối tượng phienBanHangcủa lớp PhienBanHangvà kết hợp nó vào hệ thống HBH,+ Tạo ra một đối tượng dongBanHang của lớp dongBanHangcho mặt hàng vừa nhập vào và gán dongBanHang.soLuong=soHang(đối số của hàm),+ dongBanHangđược liên kết với MoTaMatHangdựa vào mã upc.

2. Hợp đồng về việc kết thúc nhập hàng

Hợp đồng

Tên gọi:	endSale()()
Trách nhiệm:	Ghi nhận những mặt hàng đã được nhập. Hiển thị tổng số tiền bán hàng.
Kiểu lớp:	System (Hệ thống)
Tham chiếu tóiư	R1.2, và ca sử dụng Bánhàng
Chú ý:
Ngoại lệ:	Nếu phiên bán hàng không thực hiện được thì có lỗi
Kết quả ( O utput ):
Pre-conditions:	UPC được biết trước
Post-conditions:	PhienBanHang.ketThucnhận giá trị true.

Lớp PhienBanHang từ hình 4-14 sẽ được bổ sung thêm thuộc tính ketThuc khi phân tích ca sử dụng “Thanh toán”. Thuộc tính này có kiểu logic và sẽ nhận giá trị true khi kết thúc việc nhập dữ liệu thành công và bắt đầu thực hiện thu tiền của khách hàng.

3. Hợp đồng thực hiện thu tiền mặt

Hợp đồng

Tên gọi:	makePayment(soTien: DVT), trong đó DVT là lớp các loại tiền
Trách nhiệm:	Ghi nhận các thông tin liên quan đến việc thanhtoán, tính số tiền dưcần trả lại cho khách.
Kiểu lớp:	System (Hệ thống)
Tham chiếu tới:	R2.1, và ca sử dụng Bánhàng
Chú ý:
Ngoại lệ :	Nếu phiên bán hàng không kết thúc thì có lỗiNếu soTien nhỏ hơn tongSoTien thì cũng có lỗi
Kết quả ( O utpu t ):
Pre-conditions:
Post-conditions:	+ Một đối tượng thanhToanđược tạo lập,+ số tiền dư là soTien-ThanhToan.tongSoTien+ thanhToanđược liên kết với phienBanHangđã được tạo lập ở hợp đồng 1. để thực hiện việc cập nhật những mặt hàng đã bán, tổng số tiền, v.v.

Tương tự, hãy xây dựng các hợp đồng cho những thao tác còn lại của các lớp.

Đối với những ca sử dụng có nhiều đối tượng tham gia thì biểu đồ trình tựlà khá phức tạp, do vậy nó không thích hợp. Muốn hiểu rõ hoạt động của các đối tượng thì tốt nhất là nên phân tách những ca sử dụng phức hợp thành các ca sử dụng tương đối đơn giản, dễ hiểu và mô tả được bằng biểu đồ trình tự một cách đơn giản hơn.