Việc chuyển đổi từ một phiên bản của UCMeta [10] sang biểu đồ máy trạng thái bao gồm 12 luật, đƣợc tóm tắt trong Bảng 3.6.
Các chỉ số ở dƣới của luật (Cột 1, Bảng 3.6) chỉ ra loại luật: "c" và "a" biểu thị tƣơng ứng luật composite và atomic; luật composite có thể bị tách, trong khi đó luật atomic thì không. Bộ luật biến đổi chỉ có duy nhất một luật dạng composite đó là luật 5, còn lại các luật đều thuộc dạng atomic. Trong đó luật 5 lại bao gồm cả hai loại luật composite và atomic.
28
Bảng 3.6: Tóm tắt các luật biến đổi
Luật Mô tả
1a Tạo một thể hiện của StateMachine cho mô hình ca sử dụng.
2a Tạo trạng thái khởi tạo (PseudostateKind = initial) cho máy trạng thái.
3a Tạo một thể hiện của State, đƣợc đặt tên là „start‟, đại diện cho trạng thái bắt đầu của máy trạng thái.
4a Tạo một thể hiện của Transition. Trình kích hoạt của nó đƣợc đặt tên là „construct‟. Quá trình chuyển đổi này kết nối trạng thái khởi tạo với trạng thái bắt đầu.
5c Gọi luật 5.1-5.4 để xử lý từng ca sử dụng của mô hình ca sử dụng.
5.1a Tạo một thể hiện của State cho mỗi tiền điều kiện của ca sử dụng,
miễn là trạng thái đó chƣa đƣợc tạo, điều này có thể thực hiện đƣợc vì hai ca sử dụng có thể có cùng một tiền điều kiện.
5.2a Tạo một thể hiện của State cho mỗi hậu điều kiện của luồng cơ bản
trong ca sử dụng, miễn là trạng thái đó chƣa đƣợc tạo.
5.3a Kết nối các State tƣơng ứng tiền điều kiện tới các State tƣơng ứng
hậu điều kiện của luồng cơ bản trong ca sử dụng với Transition có
trình kích hoạt là tên ca sử dụng. Xem Hình 3.2 để biết mã Kermeta tƣơng ứng.
5.4c Xử lý hậu điều kiện của luồng thay thế trong ca sử dụng.
5.4.1a Tạo một thể hiện của State cho mỗi hậu điều kiện trong mỗi luồng
thay thế.
5.4.2a Kết nối các State tƣơng ứng tiền điều kiện của luồng cơ bản tới các State tƣơng ứng hậu điều kiện của luồng thay thế với Transition có
trình kích hoạt là tên ca sử dụng. Xem Hình 3.3 để biết cách xác định các điều kiện đảm bảo.
6a Kết nối tiền điều kiện với hậu điều kiện thông qua Transition của ca sử dụng. Trình kích hoạt của nó bao gồm ca sử dụng. Tác dụng của nó bao gồm ca sử dụng và phần đảm bảo là sự kết hợp của tất cả các câu điều kiện trong các bƣớc trƣớc đó chứa mệnh đề INCLUDE USE CASE.
29
Luật 1 tạo UML StateMachine cho ca sử dụng UCMod, sau đó có thể đƣợc miêu tả nhƣ một biểu đồ máy trạng thái.
Luật 2-4 tạo ra trạng thái ban đầu (Pseudostate), trạng thái bắt đầu (State) và chuyển tiếp (Transition) từ trạng thái ban đầu sang trạng thái bắt đầu. Các lý do yêu cầu trạng thái bắt đầu là đối với một máy trạng thái, nó thƣờng đƣợc yêu cầu chuyển từ trạng thái bắt đầu sang nhiều trạng thái thông qua nhiều hơn một chuyển tiếp (Transition). Tuy nhiên, trạng thái ban đầu của UML có thể có nhiều nhất một chuyển tiếp từ nó.
Luật Composite 5 bao gồm các luật atomic 5.1-5.4 để xử lý từng ca sử dụng của UCMod.
Việc tạo máy trạng thái là duy nhất cho toàn bộ UCMod. Máy trạng thái đƣợc tạo là máy trạng thái cấp hệ thống, nơi lập mô hình các trạng thái của toàn bộ hệ thống và các lệnh cấp hệ thống dƣới dạng chuyển tiếp. Ngƣợc lại, trong các máy trạng thái cấp lớp, các trạng thái đƣợc mô hình hóa dựa trên các biến của lớp đó và các chuyển tiếp có các cách kích hoạt, ví dụ nhƣ lời gọi các sự kiện là dƣới dạng lời gọi phƣơng thức. Máy trạng thái cấp hệ thống ở mức trừu tƣợng cao hơn máy trạng thái cấp lớp và phù hợp hơn với kiểm thử cấp hệ thống. Để tự động tạo các máy trạng thái cấp hệ thống, sẽ sử dụng thông tin chủ yếu chứa trong tiền điều kiện (pre-condition) và hậu điều kiện (post-condition) của tất cả các ca sử dụng trong một UCMod để tạo trạng thái. Khởi tạo State cho mỗi câu của tiền điều kiện và hậu điều kiện, nhƣng đảm bảo rằng không có trạng thái trùng lặp nào đƣợc tạo ra. Vì tiền điều kiện của một ca sử dụng cho biết điều gì phải xảy ra trƣớc khi ca sử dụng có thể bắt đầu và hậu điều kiện của ca sử dụng chỉ ra những gì phải thỏa mãn sau khi ca sử dụng hoàn tất.
Luật 5.3 để tạo chuyển tiếp giữa các trạng thái bắt nguồn từ tiền điều kiện và các trạng thái bắt nguồn từ hậu điều kiện của luồng cơ bản (basic flow).
Hình 3.2 trình bày một đoạn trích mã của Kermeta [6] triển khai luật 5.3 để tạo một Transition (pre2post_transition: uml:: Transition).
Phần đầu tiên của đoạn trích cho thấy cách xác định điều kiện đảm bảo của một chuyển tiếp (S1). Nhƣ trong Hình 3.2, nếu các bƣớc của luồng cơ bản của một ca sử dụng chứa ConditionalSentences (step. asType (ConditionalSentence)
và/hoặc ConditionCheckSentences (step. isInstanceOf (ConditionCheckSentence)), sau đó điều kiện đảm bảo của quá trình chuyển tiếp đƣợc tạo ra phải là sự kết hợp các điều kiện của những câu này. Ví dụ, sự chuyển đổi từ trạng thái The system is in a conference call (tiền điều kiện của ca sử dụng
30
Disconnect, nhƣ trong Bảng 3.5) tới trạng thái The system is idle (hậu điều kiện sau của luồng cơ bản Disconnect) với kích hoạt (trigger) Disconnect và có hiệu lực The system disconnects Endpoint, có điều kiện đảm bảo: Endpoint to be disconnected is in the conference call. AND The conference call has only one Endpoint. Điều kiện đảm bảo là sự kết hợp của hai câu kiểm tra điều kiện (tức là, những câu VALIDATES THAT) của các bƣớc 2 và 5 của luồng cơ bản (Bảng 6).
Nhờ có RUCM và UCMeta, việc tạo ra các điều kiện đảm bảo chính xác trở nên khả thi và dễ dàng hơn. Điều này là do RUCM định nghĩa một tập hợp các từ khóa (ví dụ: VALIDATES THAT) and UCMeta cấu tạo chúng thành các Metaclass (ví dụ: ConditionCheckSentence). Sự chuyển tiếp từ UCMod đƣợc thể hiện bằng RUCM tới một UCMeta đƣợc tự động hóa và trình bày trong [10].
Hình 3.2: Đoạn trích mã Kermeta để triển khai luật 5.3.
Phần thứ hai của đoạn trích (S2) trong Hình 3.2 cho thấy điều kiện đảm bảo đƣợc khởi tạo nhƣ thế nào dƣới dạng một uml::Constraint.
31
Phần thứ ba của đoạn trích (S3) tạo ra kích hoạt của quá trình chuyển đổi. Tên của nó đƣợc gán làm tên của ca sử dụng, điều này là hợp lý vì ca sử dụng kích hoạt quá trình chuyển tiếp từ tiền điều kiện tới hậu điều kiện của luồng cơ bản.
Phần thứ tƣ của đoạn trích (S4) tạo ra kết quả mong muốn của quá trình chuyển tiếp. Kết quả mong muốn đƣợc xác định bởi bƣớc cuối cùng của luồng cơ bản. Có thể nói rằng các bƣớc trong luồng cơ bản (ngoại trừ các câu điều kiện) tất cả có thể đƣợc coi là kết quả mong muốn. Tuy nhiên, trong hầu hết các trƣờng hợp, bƣớc cuối cùng là đủ để chỉ ra kết quả của quá trình chuyển tiếp. Trong tƣơng lai, khi nhiều thực nghiệm hơn đƣợc thực hiện, quá trình chuyển đổi này dự kiến sẽ đƣợc tinh chỉnh.
Phần cuối cùng (S5) của đoạn trích gọi một thao tác (operation) để tạo ra chuyển tiếp.
Luật 5.4 xử lý các hậu điều kiện của mỗi luồng thay thế của ca sử dụng. Lƣu ý rằng RUCM thực thi từng luồng sự kiện (cả luồng cơ bản và các luồng thay thế) của một UCS chứa hậu điều kiện riêng của nó. Đặc điểm này của RUCM làm cho việc chuyển đổi (luật 5.4) một cách có hệ thống. Đối với trƣờng hợp mẫu ca sử dụng truyền thống mà không thực thi đặc tính RUCM này, các UCS đƣợc thể hiện với nó sẽ có một hậu điều kiện duy nhất cho mỗi ca sử dụng. Do đó không thể tránh khỏi hậu điều kiện sẽ kết hợp tất cả các điều kiện của luồng cơ bản và luồng thay thế, vì thế dẫn đến việc một trạng thái duy nhất tƣơng ứng với hậu điều kiện của ca sử dụng. Trạng thái nhƣ vậy là không chính xác vì nó bao gồm tất cả các trạng thái quan trọng mà hệ thống có thể chuyển đến trong khi thực hiện một ca sử dụng. Trong kiểm thử, ta mong muốn việc có các trạng thái riêng biệt và các chuyển tiếp riêng biệt với các điều kiện khác nhau để xử lý các luồng thay thế. Đây chính xác là những gì mà quá trình chuyển đổi đƣợc thực hiện với sự trợ giúp của RUCM. Lý do của tách bạch việc xử lý các hậu điều kiện của các luồng thay thế với các luật chuyển đổi của việc xử lý luồng cơ bản là các điều kiện đảm bảo đƣợc xử lý theo một cách khác.
Luật 5.4 tiếp tục gọi các luật 5.4.1 và 5.4.2 để lần lƣợt tạo trạng thái cho hậu điều kiện của mỗi luồng thay thế và kết nối các trạng thái này với các trạng thái đã đƣợc tạo ra tƣơng ứng với tiền điều kiện của luồng cơ bản qua chuyển tiếp. Đoạn trích về mã Kermeta của luật này đƣợc cung cấp trong Hình 2.9, đƣợc sử dụng chủ yếu để giải thích cách mà các điều kiện đảm bảo của quá trình chuyển tiếp đƣợc xác định. Có thể thấy từ code, điều kiện đảm bảo của quá trình chuyển
32
tiếp từ trạng thái đƣợc tạo cho tiền điều kiện của ca sử dụng và trạng thái đƣợc tạo cho hậu điều kiện của một luồng thay thế đƣợc xác định bằng cách phủ định câu điều kiện (có thể là ConditionalSentence hoặc ConditionCheckSentence) của luồng cơ bản mà từ đó các luồng thay thế tách ra (đƣợc chỉ ra bằng cách sử dụng từ khoá RFS trong UCS của use case) (Mục 3.3). Ví dụ, sự chuyển tiếp trạng thái
The system is in a conference call (đại diện cho tiền điều kiện của use case
Disconnect, nhƣ trong Bảng 6) tới chính nó (đại diện cho hậu điều kiện của luồng
Disconnect thay thế cụ thể đầu tiên) với kích hoạt Disconnect và có hệ quả The system sends a failure message to User, có điều kiện đảm bảo: NOT Endpoint to be disconnected is in the conference call.
Hình 3.3: Đoạn trích mã Kermeta để triển khai luật 5.4.2.
Luật 6 xử lý mối quan hệ bao gồm (include relationship) của UCMod. Đối với mỗi quan hệ bao gồm, quá trình chuyển đổi đƣợc tạo ra để liên kết tiền điều kiện của ca sử dụng bao gồm (including use case) với hậu điều kiện của nó, với kích hoạt đƣợc đặt tên là tên của ca sử dụng bao gồm, kết quả đƣợc đặt tên là tên của ca sử dụng đƣợc bao gồm và điều kiện đảm bảo là kết hợp tất cả các điều kiện của các câu điều kiện từ các bƣớc trƣớc bƣớc INCLUDE USE CASE. Nhƣ trong Hình 3.4, trƣờng hợp sử dụng ReturnVideo bao gồm ca sử dụng
ReadBarCode ở bƣớc 2 luồng cơ bản. Các chuyển tiếp đƣợc tạo để kết nối tiền điều kiện của ca sử dụng ReturnVideo tới hậu điều kiện của nó. Ví dụ, một quá trình chuyển tiếp đƣợc tạo ra để kết nối tiền điều kiện của ReturnVideo
(„Employee is authenticated’) với hậu điều kiện luồng cơ bản của nó (câu „A video copy has been returned.’ và câu „The video copy is available for rent.’), với kích hoạt „ReadBarCode’, hệ quả „ReturnVideo’.
Về việc mở rộng (Extend) mối quan hệ giữa các ca sử dụng, chúng tôi không cần các luật cụ thể để xử lý chúng. Nhƣ trong Hình 3.4, ca sử dụng
33
VideoOverdue mở rộng ca sử dụng ReturnVideo trong luồng thay thế 1, khi „The
system VALIDATES THAT the video copy is not overdue’ (Luồng cơ bản, bƣớc
5) là không đúng. Khi chúng ta tuân theo các luật 5.3 và 5.4.2, quá trình chuyển tiếp đƣợc tạo ra để kết nối tiền điều kiện của VideoOverdue và các hậu điều kiện của nó của cả luồng cơ bản và luồng thay thế. Lƣu ý rằng tiền điều kiện của
VideoOverdue là sự kết hợp tiền điều kiện của ReturnVideo và điều kiện đảo của luồng cơ bản, bƣớc 5. Do đó, không cần tạo chuyển đổi từ tiền điều kiện của
ReturnVideo sang hậu điều kiện của VideoOverdue và do đó chúng tôi không thấy cần phải có luật để xử lý việc Mở rộng các mối quan hệ.
Hình 3.4: Mối quan hệ Include và Extend giữa các ca sử dụng.
(1) ReturnVideo Description: Employee scans a video copy to clear the
video copy from a member‟s account.
Precondition: Employee is authenticated.
Basic flow step 2: INCLUDE USE CASE ReadBarCode
Basic flow step 5: The system VALIDATES THAT the video copy is not
overdue.
Basic flow postcondition: A video copy has been returned. The video copy is
available for rent.
Alternative flow 1 (RFS Basic flow 5): EXTENDED USE CASE
VideoOverdue
(2) VideoOverdue Description: Employee of the store handles an overdue
video copy. A fine for the delay in returning the video copy is computed, printed, and recorded.
Precondition: Employee is authenticated. The video copy returned by the
member is overdue.
Basic flow postcondition: The fine for the overdue video copy is computed.
The fine for the overdue video copy is printed. The fine for the overdue video copy is recorded.
34
(3) ReadBarCode Description: Employee scans a video copy using the bar
code reader. Precondition: There is a bar code on the video copy