Phàn tích sự tương tác giữa các đối tượng

Một phần của tài liệu uml và ứng dụng để xây dựng mô hình cho hệ thống tín dụng (Trang 49)

2.3.1 Kịch bản

Như đã đề cập ở phần trên, các Use case ở mức cao chứa những mô tả một cách chung nhất trình tự của các sự kiện. Nó có thể có các ngoại lệ, các dòng xen kẽ xảy ra khi Use case đó được thực hiện. Một trình tự cụ thể của Use case được gọi là một kịch bản. Kịch bản là một ví dụ thực tế về việc sử dụng Use case, nó là một trong rất nhiều đường dẫn mà Use case đó cho phép. Kịch bản được dùng để thẩm định lại các yêu cầu của người sử dụng. Một Use case có thể có nhiều kịch bản nhưng mỗi kịch bản được tạo nên từ đúng một Use case, nó thuộc vào Use case đó

và giải thích một cách chi tiết hơn cho Use case đó. Khi một kịch bản được tạo ra mà ta thấy nó có nhiều điểm khác với ý tưởng của Use case đó thì nên tạo ra một Use case mới.

Việc phát triển các kịch bản có thê tuân theo các bước sau:

s Bắt đầu với một Use case và nhận dạng một điểm quyết định.

s Nhận dạng ai hay cái gì có liên quan đến.

s Làm các lựa chọn và cứ tiếp tục như vậv.

Ví dụ: Với Use case “Quản lý hồ sơ pháp lý cá thể” có thể có các kịch bản

s Việc nhập hồ sơ thành công

s Mã khách hàng mà cán bộ tín dụng nhập vào máy không tìm thấy trong CSDL

Một câu hỏi đặt ra là với một Use case thì bao nhiêu kịch bản là đủ? Ta cần tìm số lượng kịch bản nhỏ nhất nhưng phải bao phủ được Use case đó một cách thích đáng. Việc định nghĩa các kịch bán cho một Use case sẽ dừng lại khi ta thấy các dấu hiệu sau:

S Ta không thể nghĩ thêm được kịch bản nào nữa.

s Các kịch bản mới không cung cấp được điều gì mới mẻ giúp hiểu thêm về Use case đó.

■S Các kịch bản mới thuộc vào các Use case khác.

s Không đủ thống tin để tiếp tục. Khi ta không quyết định được là có nên

tiếp tục hay không, hay thấy khó khăn trong việc định nghĩa các kịch bản mới thì nên dừng việc định nghĩa lại và làm một số công việc khác như: định nghĩa biểu đồ trình tự, cặp nhật biểu đồ lớp. Thông thường những việc này sẽ cho thêm một số Ihông tin.

Kịch bản được mô tả bằng các biểu đồ tương tác. Các biểu đồ tương tác chứa đựng các thông tin chi tiết giống như mô tả trong luồng sự kiện của Use case. Nhưng khác với mô tả bằng văn bản trong Use case, trong các biểu đồ nàv thông tin được mô tả một cách trực quan bằng hình vẽ, vì thế nó rất dễ hiểu và dỗ nắm bất.

Các biểu đổ tương tác tập trung vào các đối tượng sẽ dược tạo ra để thực hiện các chức nàng chi ra trong Use case. Có hai loại biểu đồ tương tác đó là:

Biêu đồ trình tự (sequence diagram) và biểu đồ hợp tác (collaboration diagram).

2.3.2 Biểu đồ trình tự2.3.2.1 Định nghĩa 2.3.2.1 Định nghĩa

Biểu đổ trình tự chỉ ra sự tương tác giữa các đối tượng được sắp xếp theo trình tự thời gian. Nó mô tả cư xử của các đối tượng trong kịch bản, giúp ta hình dung được khía cạnh động của hệ Ihống. Đối với mỗi kịch bản cần tạo ra một biểu đổ trình tự đế mô tả cách mà các đối tượng hợp tác với nhau để thực hiện kịch bản đó.

2.3.2.2 M ó tả

Biểu đồ trình tự gồm một tập các đối tượng và các thông báo được gửi đi giữa chúng để thực hiện một kịch bản. Biểu đổ này nhấn mạnh vào trình tự thời gian giữa các thông báo. Biểu đồ này chỉ chứa các đối tượng mà không chứa các lớp. Các đối tương trong biểu đồ trình tự ánh xạ đến các lớp trong biểu đồ lớp, hoặc cũng có thể xuất phát từ một danh từ trong kịch bản. Một thông báo là một sự kích thích từ đối tượng này đến đối tượng khác để truyền thông tin hoặc yêu cầu đối tượng kia làm một việc gì đó.

Phần lớn các kịch bản là do một Actor chính khởi xướng, một số kịch bản có thèm các Actor thứ yếu có liên quan. Do vậy, thông thường mỗi biểu đồ trình tự đều có ít nhất một Actor. Và thường có từ 4 đến 8 đối tượng trong một biểu đồ. Nếu có ít hơn 4 thì mức độ chi tiết là thấp và có thể không mô tả được điều gì mới mẻ. Còn nếu nhiểu hơn 8 đối tượng thì biểu đồ sẽ có qúa nhiều chi tiết và việc đọc nó sẽ trở nên khó khăn. Vậy thì mức độ chi tiết thế nào là vừa đủ? Các gợi ý sau sẽ giúp chúng ta trong việc quyết định mức độ chi tiết của biểu đồ trình tự. Nếu khống thể giải thích được cách mà các đối tượng thực hiện một phương thức nào đó hay vẫn mư hổ về các thực thê nghiệp vụ (business entity) thì nên tiếp tục chi tiết hoá biểu đồ trình tự. Còn nếu các đối tượng có thê thực hiện các phương thức một cách lô gic

hoặc không phát hiện thêm được trách nhiệm nào mới thì có nghĩa là mức độ chi tiết của bicu đồ là vừa đủ.

Dựa vào biểu đổ trình tự, khách hàng có thê kiểm tra xem các quy trình nghiệp vu của họ đã được mô tả đúng hay chưa? Còn ngưdi phát triển thì xem xét các đối tượng và các phương thức cần có đê thực hiện một kịch bản.

2.3.2.3 Kí hiệu

Trong biêu đồ này, đối tượng được biểu diễn thông qua một hộp đặt trên đình của lifeline (là đường đứt nét theo chiều dọc). Lifeline đại diện cho đời sống của đối tượng trong sự lương tác. Mỗi thông báo được thể hiện bằng một mũi tên giữa hai lifeline của 2 đối tượng. Mỗi thống báo được dán nhãn ở mức tối thiểu với tên thông báo. có thể đưa vào các tham số và một vài thông tin điều khiển. Một đối tuợng có thể gửi thông báo cho chính nó, khi đó thông báo này được gọi là self-delegation.

Jim : Customer 1 The ATM Jim's acc : Account inserts card request pin PIN entered u < verifies PIN OK account options ^ < options request cash < options . < cash debit account return OK Hình 2-5: Biểu đổ trình tự 2.3.3 Biêu đó hợp tác 2.3.3.1 Đ ịnh nghĩa

Biểu đồ hợp tác là một cách khác để thê hiện một kịch bản. Khác với biểu đồ trình tự tập trung thể hiện sự tương tác giữa các đối tượng theo trình tự thời gian, biểu đổ hợp tác tập trung thể hiện mối quan hệ giữa các đối tượng.

2 3 3 .2 M ỏ tả (adsbygoogle = window.adsbygoogle || []).push({});

Biểu đồ hợp tác cung cấp những thông tin giống như biểu đồ trình tự nhưng nhấn mạnh vào mối quan hệ giữa các đối tượng. Biểu đổ hợp tác cũng rất có ích khi ta muốn xem xét ảnh hưởng của sự Ihay đổi trên một đối tượng. Trcn biểu đồ hợp

tác ta có thể thấy được các đối tượng tương tác với nhau như thế nào và khi ta thay đổi một đối tượng , ta có thể thấy nhữniỉ đối tượng nào có thể bị ảnh hưởng.

2.3.3.3 Kí hiệu

Đối tượng được vẽ như lớp nhưng tên đối tượng được gạch chân, các liên kết là những đường thẳng, thông điệp là những mũi tên được gắn trên một liên kết, bao gổrn nhãn thông điệp, sô thứ tự.

Hình 2-6: Biểu đổ hợp tác

2.4 Thêm vào các thuộc tính và phương thức cho lớp 2.4.1 Thuộc tính

Là một tính chất được đặt tên của lớp, dùng để mô tả khoảng giá trị mà tính chất đó có thể nhận được. Một lóp có thể có nhiều thuộc tính hoặc không có thuộc tính nào. Các thuộc tính được định nghĩa bởi tên, kiểu và giá trị khởi đầu.

Tìm các thuộc tính: có rất nhiều nguồn để tìm các thuộc tính của một lớp. Để hắt đầu ta có thê xem xét tài liệu của Use case. Hãy nhìn vào các danh từ trong các sự kiện, một số trong đó sẽ là lớp hay đối tượng, một số sẽ là các actor và một số sẽ là các thuộc tính. Ví dụ như trong luồng sự kiện ta có mô tả sau: Thủ kho nhập vào tên mặt hàng, sô' lượng, giá bán ... Điều này cho ta biết, lớp “Hàng hoá” sẽ có các thuộc tính Ten mặt hàng, số lượng, giá c ả ...

Ngoài ra ta cũng có thể xem trong lài liệu đặc tả yêu cầu. Có thể có các yêu cầu chí rõ rằng những thông tin nào cần được thu thập và lưu trữ bởi hệ thống.

Nếu bạn đã định nghĩa cơ sở dữ liệu, mỗi trường trong các bảng sẽ có thể là một thuộc tính của một lớp. Thông thường có một ánh xạ một -m ộ t giữa bảng trong cơ sở dữ liệu và một lớp thực thể. Tuy nhiên khi xác định các thuộc tính, chúng ta cần phải chắc rằng mỗi thuộc tính có thể lần ngược lại về một yêu cầu. Điều này giúp chúng ta tránh được một sai lầm thường gặp là thiết kế nhiều thông tin mà không ai dùng. Mỗi một yêu cầu lại được lần ngược về luồng sự kiện của Use case. Nếu không làm được việc này ta không thể chác là thống tin đó người dùng có cần hay không.

Khi xây dựng các thuộc tính, cần phải chắc là chúng được gán cho các lớp thích hợp. Nếu một lớp có quá nhiều thuộc tính, lớp đó có thể cần tách thành các lớp khác nhỏ hơn. Đôi khi chúng ta xem xét một thông tin và cân nhắc liệu nó là một lớp hay chỉ là thuộc tính của một lớp khác? Ví dụ như một thuộc tính “Tên công ty”,

nó có phải là một thuộc tính của lớp Người hay nó là một lớp? Câu trả lời phụ thuộc

vào ứng dụng mà ta xây dựng. Nếu ta cần lưu trữ thông tin về công ty và có một số thao tác liên quan đến công ty thì nó có thể là một lớp. Nhưng nếu ta không cần biết thêm một thông tin cụ thể nào khác về công ty thì nó chỉ là một thuộc tính của lớp Người. Một điều nữa cần cân nhắc là thông tin đó có ứng xử nào không, nếu có thì có thể nó là một lớp, nếu không nó chỉ là một thuộc tính.

2.4.2 Phương thức

Là sự cài đặt của một dịch vụ mà lớp đó cung cấp. Một phương thức là một sự trừu tượng hóa của điều mà ta có thể làm với đối tượng của lớp đó.

Tìm các phương thức: Biểu đổ trình tự biểu đồ hợp tác ta giúp ta rất nhiều trong việc tìm ra phương thức cho các lớp.

Có bốn loại phương thức được xem xét, đó là:

Các phương thức thực hiện( Implementor Operations):

Các phương thức này thực hiện các chức năng của lớp. Chúng có thể tìm ra bằng cách xem xét các biểu đồ tương tác. Các biểu đồ tương tác tạp trung vào các

chức năng nghiệp vụ và mỏi thông điệp trên biểu đổ hâu như sẽ ánh xạ tới một phương thức thực hiện.

Các phương thức quản lý( Manager Operations):

Các phương thức này quản lý việc tạo và hủy đối tượng. Cấu tử( constructor) và Húy tử( destructor) thuộc vào loại này.

Các phương thức truy nhập( Access Operations):

Thuộc tính thông thường là riêng (private) hoặc được bảo vệ (protected). Tuy nhiên các lớp khác đôi khi muốn nhìn hoặc thay đổi các thuộc tính của một lớp. Điều này có the thực hiện thông qua các phương thức truy nhập. Cách tiếp cận này bảo đảm tính đóng kín của đối tượng, giữ cho các thuộc tính được bảo vệ an toàn trong lớp nhưng vẫn cung cấp những cách thức có kiểm soát để truy cập tới các thuộc tính của lớp.

Các thuộc tính giúp đỡ (Helper Operations):

Các phương thức này là các phương thức mà một lớp cẩn có để thực hiện các trách nhiệm của nó nhưng các lớp khác không cần biết đến. Chúng là các phương thức riêng hoặc được bảo vệ của lớp.

Cũng giống như loại phương thức thực hiện, các phương thức giúp đỡ cũng có thể thấy trên các biểu đồ tương tác. Thông thường chúng là các thông điệp phản hổi (tức là phát đi từ lớp và nơi nhận cũng chính là lớp đó).

2.5 Xác định ứng xử của đối tượng2.5.1 Biêu đồ trạng thái 2.5.1 Biêu đồ trạng thái

Use case và kịch bản cung cấp cách thức để chỉ ra ứng xử của hệ thống, có nghĩa là sự tương tác giữa các đối tượng. Đôi khi ta cần xem xét tới ứng xử bên trong một đối tượng. Biểu đồ trạng thái dựa Irên các biểu đồ của Harel và thêm vào một số thay đổi. Một biểu đồ trạng thái (state) sẽ chỉ ra các trạng thái có thể có của một đối tượng trong chu kì sống của nó và các hành động đáp ứng của nó khi có một sự kiện xảy ra làm thay đổi trạng thái của nó. Một đối tượng sẽ được xem xét như một thực thể riêng rẽ, bất kì ảnh hường nào từ bên ngoài tới đối tượng sẽ được coi như những sự kiện. Khi một đối tượng phát hiện một sự kiện, nó phản ứng lại tùy

thuộc vào trạng thái của nó. Với các trạng thái khác nhau, đối tượng có thể có những phán ứng khác nhau với cùng một sự kiện. (adsbygoogle = window.adsbygoogle || []).push({});

Biểu đồ trạng thái (state diagram) không cần tạo cho tất cả các lớp (đối tượng) trong hệ thống. Nó chỉ tạo cho các lớp mà các trạng thái của nó là rõ ràng. Nếu đối tượng có thể có các phàn ứng khác nhau với cùng một sự kiện thì nghĩa là đối tượng đó có trạng thái. Các biểu đồ trình tự rất hữu ích cho việc xem xét ứng xử của một dối tượng.

Chú ý: Mỗi biểu đổ trình tự chi xây dựng cho một lớp.

2.5.1.1 Trạng thái

Định nghĩa: là một sự thav đổi các giá trị thuộc tính hoặc các mối quan hệ của đối tượng.

Mó tả: Trạng thái của đối tượng thể hiện bàng giá trị của các thuộc tính và các liên kết của đối tượng.

s Mô hình đối tượng mô tả các thuộc tính và các mối quan hệ có thể tồn tại của đối tượng khi thực hiện mô hình. Các giá trị thuộc tính và các mối quan hệ của đối tượng khi đó được gọi là trạng thái của đối tượng.

s Khi sự cư xử của đối tuợng dược gọi, nó có thể làm thay đổi các giá trị thuộc tính hoặc các quan hệ. Khi sự thay đổi này xảy ra, ta nói trạng thái của đối tượng đã thay đổi.

2.5.1.2 Trạng thái và sự kiện

s Một sự kiện xảy ra tại một thời điểm.

s Trạng thái là khoảng thời gian lúc dối tượng chờ sự kiện đó xảy ra.

s Một sự kiện có thể khiến đối tượng chuyển từ trạng thái này sang trạng thái khác.

s Một điều kiện bảo vệ là một biểu thức có giá trị Boolean được sử dụng để xác định xem trạng thái nào sẽ được thực hiện khi có các sự kiện trùng tên.

2.5.1.3 Sự chuyển trạng thái

The hiện việc chuyên lừ trạng thái này sang irạng thái khác. Khi chuyển trạng thái một đối tượng có thể thực hiện một số hành động. Có hai trạng thái đặc biệt đó là trạng thái bắt đầu và trạng thái kết thúc. Một biếu đổ chuvển trạng có một và chí mội trạng thái bắt đầu nhưng có thể có nhiều trạng thái kết thúc.

Một sự chuyển trạng có thê kèm theo các hành động hoặc điều kiện bảo vệ (guard condition). Một hành động là ứng xử diễn ra khi sự chuyển trạng thực hiện. Một điểu kiện bảo vệ là một biểu thức có giá trị đúng/sai cho phép sự chuyển trạng thực hiện chỉ khi nó mang giá trị đúng. Thông thường các hành động sẽ trở thành các operation của lớp và nó mang tính riêng (chí thực hiện bởi đối tượng)

2.5.1.4 Xây dựng biểu đồ chuyển trạng từ biểu đổ trình tự

Ta có thế dễ dàng xây dựng biểu đồ chuyển trạng từ biểu đồ trình tự dựa trên các nhận xét sau:

s Các mũi tên hướng vào các lớp trong biểu đồ trình tự là các sự kiện Irong biểu đổ chuyển trạng.

s Khoảng trống giữa hai mũi tên cùng hướng trong biểu đồ trình tự là trạng thái của đối tượng irong biểu đồ chuyển trạng.

Dựa vào hai nhận xét trên, ta xây dựng được biểu đồ chuyển trạng cơ bản, sau đó thêm vào các dòng xen kẽ từ các biểu đồ trình tự khác ta sẽ được biểu đồ chuyển trạng hoàn chỉnh.

Ví dụ: Từ biểu đồ trình tự xâv dựng trong phần ví dụ của biểu đổ trình tự, ta sẽ xây dựng được biểu đồ chuyển trạng như sau:

Một phần của tài liệu uml và ứng dụng để xây dựng mô hình cho hệ thống tín dụng (Trang 49)