Behavioral modeling trong phân tích thiết kế hệ thống

Hai chương trước đã thảo luận về mô hình chức năng và mô hình cấu trúc. Hệ thống các nhà phân tích sử dụng các mô hình chức năng để mô tả quan điểm hành vi bên ngoài của một thông tin hệ thống, trong khi họ sử dụng các mô hình cấu trúc để mô tả chế độ xem tĩnh của một hệ thống thông tin.Trong chương này, chúng tôi thảo luận về cách các nhà phân tích sử dụng các mô hình hành vi để đại diện cho hành vi nội bộ tức là hoặc chế độ xem động của một hệ thống thông tin. Có hai loại mô hình hành vi. Đầu tiên, có những mô hình hành vi được sử dụng để đại diện cho các chi tiết cơ bản của quy trình kinh doanh được mô tả bằng mô hình use case. Trong UML, sơ đồ tương tác (trình tự và giao tiếp) được sử dụng cho loại mô hình hành vi. Thứ hai, có một mô hình hành vi được sử dụng để đại diện cho những thay đổi xảy ra trong dữ liệu cơ bản. UML sử dụng máy trạng thái hành vi cho việc này.

GIỚI THIỆU

Hai chương trước đã thảo luận về mô hình chức năng và mô hình cấu trúc Hệ thống các nhà phân tích sử dụng các mô hình chức năng để mô tả quan điểm hành

vi bên ngoài của một thông tin hệ thống, trong khi họ sử dụng các mô hình cấu trúc

để mô tả chế độ xem tĩnh của một hệ thống thông tin.Trong chương này, chúng tôi thảo luận về cách các nhà phân tích sử dụng các mô hình hành vi để đại diện cho hành vi nội bộ tức là hoặc chế độ xem động của một hệ thống thông tin

Có hai loại mô hình hành vi Đầu tiên, có những mô hình hành vi được sử dụng

để đại diện cho các chi tiết cơ bản của quy trình kinh doanh được mô tả bằng mô hình use case Trong UML, sơ đồ tương tác (trình tự và giao tiếp) được sử dụng cho loại mô hình hành vi Thứ hai, có một mô hình hành vi được sử dụng để đại diện cho những thay đổi xảy ra trong dữ liệu cơ bản UML sử dụng máy trạng thái hành vi cho việc này

Trong quá trình phân tích, các nhà phân tích sử dụng các mô hình hành vi để nắm bắt sự hiểu biết cơ bản về các khía cạnh năng động của quy trình kinh doanh

cơ bản Theo truyền thống, các mô hình hành vi đã được sử dụng chủ yếu trong quá trình thiết kế, nơi các nhà phân tích tinh chỉnh cázc mô hình hành vi để bao gồm các chi tiết thực hiện (xem Chương 8) Hiện tại, chúng tôi tập trung vào

những gì động quan điểm về hệ thống đang phát triển chứ không phải về khía cạnh năng động của hệ thống sẽ như thế nào được thực hiện

Trong chương này, chúng tôi tập trung vào việc tạo ra các mô hình hành vi của quy trình kinh doanh Sử dụng sơ đồ tương tác (sơ đồ trình tự và giao tiếp) và máy trạng thái hành vi, có thể cung cấp một cái nhìn đầy đủ về các khía cạnh động của

hệ thống thông tin kinh doanh đang phát triển Đầu tiên chúng tôi mô tả các mô hình hành vi và các thành phần Sau đó, chúng tôi mô tả từng sơ đồ, cách chúng

được tạo ra và cách chúng có liên quan đến các mô hình chức năng và cấu trúc được mô tả trong Chương 5 và 6.

CÁC MÔ HÌNH HÀNH VI (BEHAVIORAL MODELS)

Khi một nhà phân tích đang cố gắng hiểu miền ứng dụng cơ bản của một vấn

đề, người đó phải xem xét cả khía cạnh cấu trúc và hành vi của vấn đề không giống các cách tiếp cận khác để phát triển hệ thống thông tin, cách tiếp cận hướng đối tượng cố gắng xem miền ứng dụng cơ bản một cách tổng thể Bằng cách xem miền sự cố như một tập hợp các trường hợp sử dụng được hỗ trợ bởi một tập hợp các đối tượng cộng tác, phương pháp tiếp cận hướng đối tượng cho phép nhà phân tích giảm thiểu khoảng cách ngữ nghĩa giữa tập hợp các đối tượng trong thế giới thực và mô hình hướng đối tượng đang phát triển của miền vấn đề Tuy nhiên, như chúng tôi đã chỉ ra trong chương trước, thế giới thực có xu hướng lộn xộn, điều này làm cho việc mô hình hóa hoàn hảo miền ứng dụng thực tế là không thể trong phần mềm Điều này là bởi vì phần mềm phải gọn gàng và logic để hoạt động Một trong những mục đích chính của mô hình hành vi là chỉ ra cách thức các đối tượng trong miền có vấn đề sẽ làm việc cùng nhau để tạo thành sự cộng tác để

hỗ trợ từng các trường hợp sử dụng Trong khi các mô hình cấu trúc đại diện cho các đối tượng và các mối quan hệ giữa chúng, các mô hình hành vi mô tả quan điểm nội bộ của quy trình kinh doanh mà một trường hợp mô tả Quá trình có thể được hiển thị bằng sự tương tác diễn ra giữa các đối tượng cộng tác để hỗ trợ một use case thông qua việc sử dụng tương tác (trình tự và giao tiếp) sơ đồ Cũng có thểcho thấy hiệu quả mà tập hợp các trường hợp sử dụng tạo nên hệ thống có trên các đối tượng trong hệ thống thông qua việc sử dụng trạng thái hành vi máy móc

Tạo các mô hình hành vi là một quá trình lặp đi lặp lại không chỉ qua các chỉ số

mô hình hành vi vidual [ví dụ: sơ đồ tương tác (trình tự và giao tiếp) và máy trạng thái hành vi] mà còn trên chức năng (xem Chương 5) và cấu trúc mô hình (xem Chương 6) Khi các mô hình hành vi được tạo ra, không có gì lạ khi những thay đổi đối với mô hình chức năng và cấu trúc Trong ba phần tiếp theo, chúng tôi mô

tả sơ đồ tương tác và máy trạng thái hành vi và khi nào sử dụng chúng

INTERACTION DIAGRAMS:

Một trong những điểm khác biệt của sơ đồ lớp và sơ đồ tương tác ngoài sự khác biệt rõ ràng mà một mô tả cấu trúc và hành vi khác, thì sơ đồ lớp tập trung vào các lớp còn sơ đồ tương tác tập trung vào đối tượng

Objects, Operations, and Messages:

Một đối tượng là sự khởi tạo của một lớp, nghĩa là một người, địa điểm, sự kiệnthực tế hoặc về mà chúng ta muốn nắm bắt thông tin Ví dụ nếu chúng ta đặt một cuộc hẹn cho một phòng khám Các lớp bao gồm bệnh nhân, bác sĩ cuộc hẹn; còn bệnh nhân X chẳng hạn được coi là một đối tượng là một trường hợp của các lớp bệnh nhân

Mỗi đối tượng đều có thuộc tính của riêng nó, ví dụ bệnh nhân X có tên, ngày sinh, tuổi, nơi ở, số điện thoại và chúng cũng có hành Các vi sẽ được mô tả bằng hành động của nó Hành động chỉ là hành động của đổi tượng có thể thực hiện được Ví dụ, một đối tượng cuộc hẹn có thể lên lịch một cuộc hẹn mới, xóa một cuộc hẹn và xác định vị trí cuộc hẹn có sẵn tiếp theo Sau đó trong quá trình phát triển của hệ thống đang phát triển, các hành vi sẽ được thực hiện như các phương thức

Mỗi đối tượng cũng có thể gửi và nhận thông điệp Thông điệp là thông tin được gửi đến các đối tượng để yêu cầu một đối tượng thực hiện một trong các hành

vi của nó Về cơ bản thông điệp là một chức năng hoặc thủ tục tín hiệu từ đối tượng này sang đối tượng khác Ví dụ, nếu một bệnh nhân mới làm quen với văn phòng bác sĩ, hệ thống sẽ gửi một thông báo chèn vào ứng dụng Đối tượng bệnh nhân sẽ nhận được hướng dẫn (thông báo) và làm những gì nó cần làm để tiếp tục thêm bệnh nhân mới vào hệ thống (hành vi)

Sequence Diagrams:

Biểu đồ tuần tự là một trong hai loại biểu đồ tương tác Nó minh họa cho các đối tượng tham gia vào use case và các thông điệp giữa chúng trong một use case Biểu đồ trình tự là một mô hình động thể hiện trình tự rõ ràng thông báo được truyền giữa các đối tượng trong một tương tác xác định Bởi vì trình tự sơ đồ nhấn mạnh thứ tự dựa trên thời gian của hoạt động diễn ra giữa một nhóm của các đối tượng, chúng rất hữu ích để hiểu các thông số kỹ thuật thời gian thực và phức tạp của use case

Biểu đồ trình tự có thể là một biểu đồ trình tự chung hiển thị tất cả các tình huống có thể xảy ra cho một use case, nhưng thường thì mỗi nhà phân tích phát triển một tập hợp các sơ đồ trình tự phiên bản, mỗi trong số đó mô tả một kịch bản duy nhất trong use case Nếu bạn quan tâm tìm hiểu quy trình kiểm soát của một kịch bản theo thời gian, bạn nên sử dụng một sơ đồ tuần tự để mô tả thông tin này Các sơ đồ được sử dụng trong cả quá trình phân tích và thiết kế các giai đoạn Tuy nhiên, các sơ đồ thiết kế rất cụ thể để triển khai, thường bao gồm các đối tượng cơ

sở dữ liệu hoặc các thành phần giao diện người dùng cụ thể như các lớp

Elements of a Sequence Diagram:

Hình 7-1 cho thấy một biểu đồ trình tự mô tả các đối tượng và thông điệp cho trường hợp sử dụng đặt hẹn, mô tả quy trình mà bệnh nhân tạo một cuộc hẹn mới

hoặc hủy bỏ hoặc lên lịch lại cuộc hẹn cho hệ thống đặt hẹn tại phòng khám của bác sĩ Trong trường hợp cụ thể, quá trình đặt lịch hẹn được miêu tả

Các tác nhân và đối tượng tham gia vào trình tự được đặt trên đầu sơ đồ sử dụng các ký hiệu tác nhân từ biểu đồ use case và các ký hiệu đối tượng từ đối tượng sơ đồ (xem Hình 7-2) Lưu ý rằng các tác nhân và đối tượng trong Hình 7-1

là Bệnh nhân, Nhân viên lễ tân, Bệnh nhân, Thanh toán chưa thanh toán, Cuộc hẹn

và anAppt Họ không được đưa vào bất kỳ thứ tự cụ thể nào, mặc dù thật tốt khi tổ chức chúng theo một cách hợp lý nào đó, chẳng hạn như thứ tự mà chúng tham gia vào trình tự Đối với mỗi đối tượng, tên của lớp mà chúng là một cá thể được đặt sau tên của đối tượng (ví dụ: Bệnh nhân: Danh sách bệnh nhân có nghĩa là Bệnh nhân là một phiên bản của lớp Danh sách bệnh nhân có chứa cá nhân đối tượng bệnh nhân)

Một đường chấm chạy dọc bên dưới mỗi tác nhân và đối tượng để biểu thị huyết mạch của các tác nhân / đối tượng theo thời gian (xem Hình 7-1) Đôi khi

một vật tạo ra một vật tạm thời Trong trường hợp này, dấu X được đặt ở cuối đường huyết mạch tại điểm đối tượng bị hủy (không hiển thị) Ví dụ: hãy nghĩ về đối tượng giỏ hàng cho một web ứng dụng thương mại Giỏ hàng được sử dụng để tạm thời nắm bắt các mục hàng cho một đặt hàng, nhưng khi đơn hàng được xác nhận, giỏ hàng không còn cần thiết nữa Trong này trường hợp, dấu X sẽ được đặt tại điểm mà đối tượng giỏ hàng bị hủy Khi các đối tượng tiếp tục tồn tại trong hệ thống sau khi chúng được sử dụng trong sơ đồ tuần tự, sau đó đường huyết mạch tiếp tục đến cuối sơ đồ (đây là trường hợp của tất cả các đối tượng trong Hình 7-1).

Thuật ngữ và định nghĩa Biểu tượng

An actor:

• Là một người hoặc hệ thống thu

được lợi ích từ bên ngoài hệ

thống

• Tham gia vào một chuỗi bằng

cách gửi và / hoặc nhận thông

điệp

• Đặt trên đầu sơ đồ

• Được mô tả như một nhân vật

dính (mặc định) hoặc, nếu có sự

tham gia của một tác nhân không

phải con người, như một hình

chữ nhật có <<actor>> trong đó

(thay thế)

An object:

• Tham gia vào một chuỗi bằng

cách gửi và / hoặc nhận thông

điệp

• Được đặt trên đầu của sơ đồ

A lifeline:

• Biểu thị vòng đời của một đối

tượng trong một chuỗi

• Chứa dấu X tại điểm mà lớp

không còn tương tác

An execution occurrence:

• Là một hình chữ nhật dài hẹp

được đặt trên đỉnh một đường

huyết mạch

• Biểu thị khi một đối tượng đang

gửi hoặc nhận thông điệp

A message:

• Truyền thông tin từ đối tượng

này sang đối tượng khác

• Một thao tác lệnh được gắn nhãn

với thông điệp đang được gửi

với một mũi tên liền, trong khi

lệnh trả về được gắn nhãn được

hiển thị dưới dạng mũi tên đứt

A guard condition:

• Đại diện cho một bài kiểm tra

phải được thỏa mãn để gửi thông

điệp

For object destruction:

• Để hủy đối tượng

mô hình các use case, hai loại thông báo thường được sử dụng: lệnh hoạt động và lệnh trả về Thông điệp cuộc gọi hoạt động được truyền giữa các lớp được hiển thị bằng cách sử dụng các đường liền nét nối hai đối tượng bằng một mũi tên trên dòng hiển thị thông điệp được chuyển Giá trị đối số cho thông báo được đặt trong dấu ngoặc đơn bên cạnh tên của thư Thứ tự các thông điệp đi từ từ đầu đến cuối trang, vì vậy các thông báo nằm cao hơn trên sơ đồ thể hiện thông báo xuất hiện

sớm hơn trong chuỗi, so với các thông báo thấp hơn xảy ra sau Lệnh trả về được

mô tả như một đường đứt nét với một mũi tên ở cuối dòng mô tả hướng của sự trở lại Thông tin được trả về được sử dụng để gắn nhãn cho mũi tên Tuy nhiên, bởi vìviệc thêm các thông báo trả về có xu hướng làm lộn xộn sơ đồ, trừ khi các thông báo trả về thêm nhiều thông tin vào sơ đồ, chúng có thể được bỏ qua Ví dụ, trong Hình 7-1, không các thông điệp trả về được mô tả.4 Trong Hình 7-1,

‘LookUpPatology ()’ là một thông báo được gửi từ diễn viên Nhân viên tiếp tân đốitượng Bệnh nhân, là nơi chứa cho bệnh nhân hiện tại xác định xem tác nhân aP Hospital có phải là bệnh nhân hiện tại hay không

Đôi khi, một thông điệp chỉ được gửi nếu một điều kiện được đáp ứng Trong những trường hợp đó, điều kiện là được đặt giữa một tập hợp các dấu ngoặc vuông,[] {ví dụ: [aP Hospital Exists] LookupBills ()} Điều kiện được đặt trước tên thông điệp Tuy nhiên, khi sử dụng biểu đồ tuần tự để mô hình hóa một kịch bản cụ thể, các điều kiện thường không được hiển thị trên bất kỳ sơ đồ trình tự đơn lẻ nào Thay vào đó, các điều kiện chỉ được ngụ ý thông qua sự tồn tại của các sơ đồ trình

tự khác nhau Có những lúc một thông điệp được lặp lại Điều này được chỉ định bằng dấu hoa thị (*) ở phía trước của tên thư (ví dụ: * CD yêu cầu) Một đối tượng

có thể gửi một thông điệp cho chính nó Đây là được gọi là tự ủy quyền

Đôi khi, một đối tượng sẽ tạo ra một đối tượng khác Điều này được hiển thị bởi thông báo đang được gửi trực tiếp đến một đối tượng thay vì huyết mạch của nó Trong Hình 7-1, tác nhân aRecepologist tạo một đối tượng anAppt

Hình 7-3 mô tả hai ví dụ bổ sung về biểu đồ trình tự theo từng trường hợp cụ thể Cái đầu tiên liên quan đến use case Make Lunch đã được mô tả trong sơ đồ hoạt động được miêu tả trong Hình 5-4 Cái thứ hai liên quan đến trường hợp sử dụng Đặt hàng được liên kết với sơ đồ hoạt động trong Hình 5-3 Trong cả hai ví dụ, các

sơ đồ đơn giản đại diện cho một kịch bản duy nhất Lưu ý, trong sơ đồ trình tự Thực hiện Bữa trưa có một thông báo được gửi từ một tác nhân đến chính nó

[CreateSandwich ()] Tùy thuộc vào mức độ phức tạp của kịch bản đang được mô hình hóa, thông báo cụ thể này có thể đã bị loại bỏ Chắc chắn, cả quá trình làm bữa trưa và đặt hàng có thể hơi phức tạp hơn một chút Tuy nhiên, theo quan điểm học tập, bạn nên bạn sẽ có thể thấy cách biểu đồ trình tự và các sơ đồ hoạt động liên quan đến nhau.

Building a Sequence Diagram

Trong phần này, chúng tôi mô tả quy trình sáu bước được sử dụng để tạo một sơ

đồ tuần tự (xem Hình 7-4) Bước đầu tiên của quy trình là xác định bối cảnh của

biểu đồ trình tự Bối cảnh của sơ đồ có thể là một hệ thống, một công dụng trường hợp hoặc một kịch bản của một use case Bối cảnh của sơ đồ được mô tả như một khung xung quanh sơ đồ (xem Hình 7-1, 7-2 và 7-3) Thông thường nhất, nó là mộtusecase kịch bản Hình 7-1 mô tả sơ đồ trình tự trường hợp cụ thể cho kịch bản từ trường hợp sử dụng Đặt hẹn được đưa ra trong Hình 5-5 để tạo cuộc hẹn cho một bệnh nhân hiện có Đối với từng tình huống có thể xảy ra cho use case Cuộc hẹn, một sơ đồ trình tự riêng cho từng trường hợp cụ thể sẽ được tạo Trên bề ngoài, đâydường như là rất nhiều công việc có thể dư thừa và vô ích

Figure 7-3

Tuy nhiên tại thời điểm này trong việc biểu diễn một hệ thống, chúng tôi vẫn đang cố gắng hiểu hoàn toàn vấn đề Do đó, quá trình này tạo ra các biểu đồ trình

tự cụ thể cho từng kịch bản thay vì tạo một sơ đồ trình tự chung chung cho toàn bộ trường hợp sử dụng sẽ cho phép các nhà phát triển hiểu đầy đủ hơn về vấn đề đang được giải quyết Hơn nữa, mỗi sơ đồ trình tự cụ thể cho từng trường hợp khá đơn giản để diễn giải, trong khi một sơ đồ trình tự chung có thể rất phức tạp Như vậy, thử nghiệm của một trường hợp sử dụng cụ thể được thực hiện theo cách dễ dàng hơn nhiều bằng cách xác thực và xác minh sự hoàn chỉnh của tập hợp các sơ đồ trình tự theo trường hợp cụ thể thay vì cố gắng làm việc thông qua một sơ đồ trình

tự chung phức tạp duy nhất

Bước thứ hai là xác định các đối tượng tham gia vào chuỗi là được mô hình hóa

— nghĩa là, các đối tượng tương tác với nhau trong tình huống use case Các đối tượng được xác định trong quá trình phát triển mô hình cấu trúc (xem Chương 6) Đây là các lớp mà các đối tượng của biểu đồ tuần tự cho kịch bản này sẽ là dựa trên Một cách tiếp cận rất hữu ích để xác định tất cả các tình huống liên quan đến việc sử dụng trường hợp là nhập vai các thẻ CRC (xem Chương 6) Điều này có thểgiúp bạn xác định thiếu các hoạt động cần thiết để hỗ trợ quá trình kinh doanh, mà use case là đại diện, một cách đầy đủ Ngoài ra, trong quá trình nhập vai, có khả năng là các lớp mới, và do đó các đối tượng mới, sẽ được khám phá Đừng lo lắng quá nhiều về việc xác định tất cả đồ vật một cách hoàn hảo; hãy nhớ rằng quá trình

mô hình hóa hành vi là lặp đi lặp lại Thông thường, sơ đồ trình tự được sửa đổi nhiều lần trong quá trình mô hình hóa hành vi

Bước thứ ba là thiết lập đường huyết mạch cho từng đối tượng Để làm điều này,

bạn cần vẽ một đường thẳng đứng dòng chấm bên dưới mỗi lớp để thể hiện sự tồn tại của lớp trong chuỗi được đặt bên dưới đối tượng tại điểm trên dây huyết mạch nơi đối tượng biến mất

Bước thứ tư là thêm các thông báo vào sơ đồ Điều này được thực hiện bằng cách

vẽ các mũi tên đại diện cho các thông điệp được chuyển từ đối tượng này sang đối tượng khác, với mũi tên chỉ vào hướng truyền của thông điệp Các mũi tên phải được đặt theo thứ tự từ mũi tên đầu tiên thông báo (ở trên cùng) đến cuối cùng (ở dưới cùng) để hiển thị trình tự thời gian Mọi thông số được chuyển cùng với các thông báo phải được đặt trong dấu ngoặc đơn bên cạnh thông báo Tên Nếu một thông điệp được mong đợi được trả lại dưới dạng phản hồi cho một thông điệp, thì việc trả về thông báo không được hiển thị rõ ràng trên sơ đồ

Bước thứ năm là đặt sự xuất hiện thực thi trên huyết mạch của mỗi đối tượng

bằng cách vẽ một hộp hình chữ nhật hẹp trên đầu các đường huyết mạch để biểu thị khi các lớp đang gửi và nhận tin nhắn

Bước thứ sáu và cuối cùng là xác nhận sơ đồ trình tự Mục đích của bước này là

để đảm bảo rằng biểu đồ trình tự hoàn toàn đại diện cho quá trình cơ bản Điều nàyđược thực hiện bằng cách đảm bảo rằng sơ đồ mô tả tất cả các bước trong quy trình

SƠ ĐỒ GIAO TIẾP

Sơ đồ giao tiếp, giống như sơ đồ tuần tự, về cơ bản cung cấp một cái nhìn về các khía cạnh động của một hệ thống hướng đối tượng Như vậy, chúng có thể chỉ

ra cách các thành viên của một tập hợp các đối tượng cộng tác để thực hiện một use case sử dụng hoặc một kịch bản use case Hơn nữa, chúng có thể được sử dụng

để mô hình hóa tất cả các tương tác giữa một tập hợp các đối tượng cộng tác, tức làmột sự cộng tác (xem các thẻ CRC trong Chương 6) Trong trường hợp này, một sơ

đồ giao tiếp có thể mô tả mức độ phụ thuộc của các đối tượng khác nhau vào nhau

Sơ đồ truyền thông về cơ bản là một sơ đồ đối tượng cho thấy các mối quan hệ truyền thông điệp thay vì các liên kết tổng hợp hoặc tổng quát hóa Biểu đồ giao tiếp rất hữu ích để hiển thị các mẫu quy trình (tức là các mẫu hoạt động xảy ra trên một tập hợp các lớp đánh giá cộng tác)

Sơ đồ giao tiếp tương đương với sơ đồ tuần tự, nhưng chúng nhấn mạnh luồng thông điệp thông qua một tập hợp các đối tượng, trong khi sơ đồ tuần tự tập trung vào thứ tự thời gian của thông điệp được truyền đi Do đó, để hiểu luồng kiểm soát đối với một tập hợp các đối tượng cộng tác hoặc để hiểu các đối tượng nào cộng tác để hỗ trợ các quy trình nghiệp vụ, có thể sử dụng một sơ đồ giao tiếp Để sắp xếp thời gian các thông điệp, nên sử dụng một sơ đồ trình tự Trong một số trường hợp, cả hai đều có thể được sử dụng để thể hiện đầy đủ hơn hoạt động năng động của hệ thống

Elements of a Communication Diagram

Hình 7-5 cho thấy một sơ đồ giao tiếp cho trường hợp sử dụng Đặt hẹn Giống nhưbiểu đồ trình tự trong Hình 7-1, quy trình Tạo Cuộc hẹn được mô tả

Các tác nhân và đối tượng cộng tác để thực thi use case được đặt trên sơ đồ giaotiếp theo cách để nhấn mạnh thông điệp diễn ra giữa chúng Lưu ý rằng các tác nhân và đối tượng trong Hình 7-5 giống với các đối tượng trong Hình 7-1: a Bệnh nhân, Nhân viên tiếp tân, Bệnh nhân, Tiền thanh toán chưa được trả, Cuộc hẹn Một lần nữa, như với biểu đồ trình tự, đối với mỗi đối tượng, tên của lớp mà chúng

là một thể hiện được đặt sau tên của đối tượng (ví dụ: Bệnh nhân: Danh sách bệnh nhân) (Cú pháp của sơ đồ giao tiếp được cho trong Hình 7-6.) Không giống như

sơ đồ tuần tự, sơ đồ truyền thông không có phương tiện để hiển thị rõ ràng một đối tượng đang bị xóa hoặc được tạo Giả định rằng khi một thông báo xóa, hủy hoặc

xóa được gửi đến một đối tượng, nó sẽ không tồn tại và một thông báo tạo hoặc mới sẽ khiến một đối tượng mới tồn tại.

Một sự khác biệt khác giữa hai sơ đồ tương tác là đường truyền thông tin khôngbao giờ hiển thị trả về từ các lần gửi tin nhắn, trong khi biểu đồ trình tự có thể tùy chọn hiển thị chúng

Sự liên kết được hiển thị giữa các tác nhân và đối tượng bằng một đường vô hướng Ví dụ: có một mối liên quan được hiển thị giữa các tác nhân aP Hospital và aRecephers Thông báo được hiển thị dưới dạng nhãn trên các liên kết Đi kèm với nhãn là các dòng có mũi tên hiển thị hướng của tin nhắn được gửi đi Ví dụ, trong Hình 7-5, tác nhân aP Hospital gửi thông điệp RequestAppt () đến tác nhân

aRecephers và tác nhân aRecephers gửi thông báo NewCancelChangeAppt? () Và ApptTimes? () Tới tác nhân aP Hospital Trình tự của tin nhắn gửi được chỉ định bằng một số thứ tự Trong Hình 7-5, thông báo RequestAppt () là thông báo đầu tiên được gửi, trong khi thông báo NewCancelChangeAppt? () Và ApptTimes? () Lần lượt là thông báo thứ tư và thứ năm được gửi đi

Giống như sơ đồ tuần tự, sơ đồ giao tiếp có thể biểu diễn các thông điệp có điềukiện Ví dụ, trong Hình 7-5, thông báo LookupBills () chỉ được gửi nếu điều kiện [aP Hospital tồn tại] được đáp ứng Nếu một tin nhắn được gửi nhiều lần, một dấu

hoa thị sẽ được đặt sau số thứ tự Cuối cùng, một liên kết lặp lại trên một đối tượngcho thấy sự tự ủy quyền Thông báo được hiển thị dưới dạng nhãn của liên kết.

Khi một sơ đồ truyền thông có đầy đủ các đối tượng, nó có thể trở nên rất phức tạp và khó hiểu Khi điều này xảy ra, cần phải đơn giản hóa sơ đồ Một cách tiếp cận để đơn giản hóa một sơ đồ giao tiếp, như sơ đồ use case (xem Chương 5) và biểu đồ lớp (xem Chương 6), là thông qua việc sử dụng các gói (tức là các nhóm lớp log-ical) Trong trường hợp sơ đồ truyền thông, các đối tượng của nó được nhóm lại với nhau dựa trên các thông điệp được gửi đến và nhận từ các đối tượng khác

Hình 7-7 cung cấp thêm hai ví dụ về sơ đồ giao tiếp Các đường kính này tươngđương với biểu đồ trình tự trong Hình 7-3 Tuy nhiên, khi so sánh sơ đồ truyền thông với sơ đồ tuần tự trong các hình này, bạn thấy rằng có khá nhiều thông tin bị mất Ví dụ, thông báo CreateSandwich () không được tìm thấy Tuy nhiên, mục đích chính của sơ đồ giao tiếp là cho thấy các tác nhân và lớp khác nhau tương tác như thế nào và đây chính xác là thông tin được đưa vào

5 Xác thực sơ đồ giao tiếp

Building a Communication Diagram

Hãy nhớ rằng sơ đồ giao tiếp về cơ bản là một sơ đồ đối tượng thể hiện các mối quan hệ truyền thông điệp thay vì các liên kết tổng hợp hoặc tổng quát Trong phầnnày, chúng tôi mô tả một quy trình năm bước được sử dụng để xây dựng một sơ đồ

giao tiếp (xem Hình 7-8) Bước đầu tiên của quy trình là xác định bối cảnh của sơ

đồ giao tiếp Giống như hệ thống, một use case hoặc một kịch bản của một use

case Bối cảnh của sơ đồ được mô tả như một khung có nhãn xung quanh sơ đồ (xem Hình 7-5,: Biểu đồ trình tự ea, bối cảnh của sơ đồ có thể là 7-6 và 7-7).

Bước thứ hai là xác định các đối tượng (tác nhân) và các liên kết liên kết các đối

tượng (tác nhân) tham gia phối hợp với nhau Hãy nhớ rằng, các đối tượng kết hợp trong sự hợp tác là các thể hiện của các lớp được xác định trong quá trình phát triển mô hình cấu trúc (xem Chương 6) Giống như quá trình lập sơ đồ trình tự, có khả năng các đối tượng bị ràng buộc và do đó các lớp sẽ được phát hiện Một lần nữa, điều này là bình thường bởi vì quá trình phát triển cơ bản bổ sung là lặp đi lặplại và tăng dần Do đó, ngoài việc sửa đổi sơ đồ thông tin liên lạc, các sơ đồ trình

tự và mô hình cấu trúc cũng sẽ phải được sửa đổi Hơn nữa, các yêu cầu chức năng

bổ sung cũng có thể được phát hiện, do đó đòi hỏi các mô hình chức năng cũng phải được sửa đổi (xem Chương 5)

Bước thứ ba là bố trí các đối tượng (tác nhân) và các liên kết của chúng trên sơ đồ

giao tiếp kết hợp với các đối tượng khác trong sự cộng tác Bằng cách tập trung vào các mối liên kết giữa các đối tượng (các tác nhân) và giảm thiểu số lượng các mối liên kết đan chéo nhau, chúng ta có thể tăng tính dễ hiểu của sơ đồ

Bước thứ tư là thêm thông báo đến các liên kết giữa các đối tượng Chúng tôi thực

hiện bằng cách thêm tên của (các) thông báo vào liên kết liên kết giữa các đối tượng và một mũi tên hiển thị hướng của thông báo được gửi đi Hơn nữa, mỗi tin nhắn có số được kết hợp với nó để mô tả thứ tự theo thời gian

Bước thứ năm và cuối cùng là xác thực sơ đồ giao tiếp Mục đích của bước này là

đảm bảo rằng sơ đồ truyền thông mô tả trung thực (các) quy trình cơ bản Điều nàyđược thực hiện bằng cách đảm bảo rằng tất cả các bước trong quy trình được mô tảtrên sơ đồ

BEHAVIORAL STATE MACHINES

Một số lớp trong biểu đồ lớp đại diện cho một tập hợp các đối tượng khá năng động trong đó chúng chuyển qua nhiều trạng thái khác nhau trong suốt quá trình tồn tại của chúng Ví dụ: một bệnh nhân có thể thay đổi theo thời gian từ ‘mới’ thành ‘hiện tại’ thành ‘cũ’, v.v., dựa trên tình trạng của họ với bác sĩ của bác sĩ Máy trạng thái hành vi là một mô hình động cho thấy các trạng thái khác nhau mà một đối tượng đi qua trong vòng đời của nó để phản ứng với các sự kiện, cùng với các phản ứng và hành động của nó Thông thường, các máy trạng thái hành vi không được sử dụng cho tất cả các đối tượng, mà chỉ sử dụng cho các đối tượng phức tạp hơn nữa để giúp đơn giản hóa việc thiết kế các thuật toán cho các phương pháp của chúng Máy trạng thái hành vi hiển thị các trạng thái khác nhau của đối tượng và những sự kiện nào khiến đối tượng thay đổi từ trạng thái này sang trạng thái khác So với sơ đồ tương tác, máy trạng thái hành vi nên được sử dụng để giúphiểu các khía cạnh động của một lớp và cách các thể hiện của nó phát triển theo thời gian chứ không phải để xem cách một use case cụ thể hoặc kịch bản use case được thực thi trên một tập hợp các lớp học

Trong phần này, chúng tôi mô tả trạng thái, sự kiện, chuyển tiếp, hành động và hoạt động và việc sử dụng máy trạng thái hành vi để mô hình hóa các thay đổi trạng thái mà các đối tượng phức tạp đi qua Giống như khi tạo các sơ đồ tương tác, khi chúng tôi tạo một máy trạng thái hành vi cho một đối tượng, có thể chúng tôi sẽ phát hiện ra các sự kiện bổ sung cần được đưa vào mô hình chức năng của bạn (xem Chương 5), các hoạt động bổ sung cần được bao gồm trong mô hình cấu trúc (xem Chương 6), vì vậy có thể các sơ đồ tương tác của chúng ta có thể phải được chỉnh sửa lại Một lần nữa, bởi vì sự phát triển hướng đối tượng là lặp đi lặp lại và tăng dần, mô hình liên tục này của các mô hình đang phát triển (chức năng, cấu trúc và hành vi) của hệ thống được mong đợi