Khóa luận Kiểm chứng đặt tả UML cho tác tử phần mềm

h (a) biểu diễn các luồng được gửi đi song song (phép AND). Hình (b) bao gồm một hộp quyết định xác định xem luồng nào sẽ được gửi đi tiếp (phép OR). Hình (c) xác định trong một thời điểm chỉ có một luồng được phép gửi đi (phép XOR). 31 3.4.3.3 Mức 3 – biểu diễn xử lý bên trong Agent Tại mức thấp nhất, đặc tả về một giao thức. Agent yêu cầu giải thích rõ ràng những xử lý chi tiết bên trong agent để tiến hành giao thức. Các mô hình mức cao hơn (gọi là holon) bao gồm tập các agent ở mức thấp hơn. Các hành vi bên trong có thể được biểu diễn bằng việc sử dụng đệ quy các cách biểu diễn ở mức 2. Ví dụ: Hình 3.9: Các hành vi bên trong của agent Initiator (a) và Participant(b) 3.5 Java Agent DEvelopment Framework (JADE) 3.5.1 Khái niệm về JADE “JADE (Java Agent DEvelopment Framework) is a software Framework fully implemented in Java language. It simplifies the implementation of multi-agent systems through a middle-ware that complies with the FIPA specifications and through a set of graphical tools that supports the debugging and deployment phases” [3]. Ta có thể tóm tắt lại định nghĩ trên như sau: - JADE là phần mềm dạng middle-ware phục vụ cho việc phát triển hệ đa tác tử. Nó hỗ trợ việc xây dựng từng agent trong hệ đa agent. Cung cấp các dịch vụ cho từng hoạt động của agent, các công cụ phục vụ cho việc debug và agent xây dựng dựa trên chuẩn FIFA. - JADE là một hệ thống mã nguồn mở, được xây dựng trên ngôn ngữ Java. 32 3.5.2 Cấu trúc của JADE platform Platform JADE là môi trường hỗ trợ agent hoạt động, trao đổi thông tin. Platform JADE chứa nhiều container, các container có thể hoạt động độc lập trên các host khác nhau. Có hai loại container chính: - JADE main-container: Mỗi platform chỉ có một main-container. Container này được khở tạo và hủy cùng với platform. Nó chứa một số agent quan trọng của JADE platform như: o RMA (Remote Management Agent): Hoạt động như màn hình đi ều khiển, phục vụ việc quản lý platform. o DF (Directory Facilitator): Là một agent cung cấp dịch vụ trang vàng (yellow-page) trong platform.  Trang vàng (Yellow-page): Là một dịch vụ cung cấp chức năng quản lý việc giao tiếp giữa các agent, đối chiếu thông tin trao đổi. o AMS (Agent Management System): Là agent theo dõi quản lý sự truy cập và sử dụng agent platform. Cung cấp dịch vụ trang trắng (white- page).  Trang trắng (White-page) cung cấp chức năng quản lý việc đăng ký của agent, quản lý ID của các agent đã đăng ký và quản lý vòng đời của agent. - JADE agent-container: Chứa các agent của người sử dụng, nó có thể nằm trên các host khác nhau. Hình 3.10: Cấu trúc phân tán của JADE 33 3.5.3 Một số lớp quan trọng trong thư viện JADE - Gói jade.core: Cài đặt các thành phần cơ bản của hệ thống. Nó chứa lớp Agent, các agent được tạo ra bắt buộc phải kế thừa từ lớp này. Ngoài ra nó còn chứa gói jade.core.behavior: cung cấp các hàm cài đặt nhiệm vụ cho agent. o Lớp jade.core.Agent: cung cấp các phương thức đăng ký với platform, các phương thức xác định trạng thái của agent, quản lý trạng thái và các phương thức hoạt động của agent. Cách tạo agent: public class MyAgent extends Agent { // some attributes public void setup() { // registry with AMS.. // other activities addBehaviour(myBehaviour) } // other methods } o Gói jade.core.behavior: Chứa các lớp cho phép tạo ra các hoạt động của agent từ đơn giản đến phức tạp. Ta có thể tạo ra các hành động cho agent bằng việc kế thừa từ các lớp này. Cách tạo behavior: public class MyBehaviour extends Behaviour { // some attributes public MyBehaviour(Agent agent){super(agent)} public void action() { // agent action } // other methods } - Gói jade.lang.acl: cung cấp các phương thức xử lý giao tiếp giữa các agent theo chuẩn FIFA. - Gói jade.domain: mô tả các thực thể quản lý agent theo chuẩn FIFA. Nó cung cấp một số dịch vụ như: life-cycle, yellow-page, white-page. Ngoài ra còn một số gói khác như: jade.wrapper, jade.content, jade.tools… Hoạt động của một agent: 34 Hình 3.11: Hoạt động của agent 3.6 Kết luận Các kiến thức về UML, XML, XMI, AUML mà tôi trình bày trong chương này không phải quá mới mẻ và cũng không thật sự đầy đủ. Nhưng đó là những nền tảng kiến thức cơ bản tôi sử dụng trong khóa luận để xây dựng công cụ tự động sinh mô- đun aspect kiểm chứng. Để giải quyết bài toán “kiểm chứng đặc tả UML cho tác tử phần mềm”, tôi chia bài toán ra làm hai bước nhỏ: Bước thứ nhất là xây dựng FSM từ tài liệu XMI mô tả các biểu đồ UML. Bước thứ hai là xây dựng bộ sinh aspect tự động từ FSM. Hai bước này sẽ được trình bày cụ thể ở các chương sau. 35 Chương 4. Xây dựng máy trạng thái từ biểu đồ UML Trong chương 2 và 3 tôi đã trình bày các ki ến thức nền tảng cơ bản để xây dựng công cụ Protocol Verification Generator(PVG). Trong chương này, tôi sẽ trình bày bước thứ nhất trong phương pháp xây dựng công cụ tự động sinh mô-đun aspect, đó là phân tích tài liệu XMI được xuất ra từ một biểu đồ UML, từ đó xây dựng máy trạng thái. Như vậy, trong bước này ta có: - Input: Một tài liệu XMI mô tả biểu đồ trạng thái hoặc biểu đồ trình tự UML. - Output: Máy trạng thái nếu xây dựng được, nếu không sẽ báo lỗi. Để xây dựng được máy trạng thái, trước tiên tôi sẽ xây dựng các cấu trúc dữ liệu để đặc tả các thành phần của biểu đồ UML bằng các đối tượng trong Java, cấu trúc dữ liệu của máy trạng thái mà tôi sử dụng. Tiếp theo, tôi sẽ trình bày cách thức tạo ra máy trạng thái từ tài liệu XMI và các cấu trúc dữ liệu đã xây dựng trước đó. 4.1 Biểu đồ trạng thái 4.1.1 Quy tắc biểu diễn giao thức bằng biểu đồ trạng thái Ngoài cách vẽ biểu đồ trạng thái như trong UML đề cập, tôi xin đưa ra thêm một số quy tắc dùng biểu đồ trạng thái để biểu diễn giao thức. Công cụ PVG mà tôi xây dựng sẽ sử dụng các quy tắc này như là một chuẩn để nó có thể hiểu được giao thức mà người dùng đặc tả bằng UML. Nếu người dùng không tuân thủ các quy tắc này, chương trình sẽ không đưa ra được kết quả như ý. Một số quy tắc: - Trong một tài liệu UML, chỉ có một biểu đồ trạng thái thể hiện giao thức cần kiểm tra. - Biểu đồ trạng thái bắt buộc phải có trạng thái bắt đầu và trạng thái kết thúc. - Trạng thái bắt đẩu có tên bắt đầu bằng “Initial”, và chỉ có các cạnh đi ra chứ không có cạnh đi vào trạng thái này. - Trạng thái kết thúc có tên bắt đầu bằng “FinalState” và chỉ có cạnh đi vào, không có cạnh đi ra từ trạng thái này. 36 - Các trạng thái khác phải có ít nhất một cạnh đi vào và một cạnh đi ra. Tên của các trạng thái này không bắt đầu bằng “Initial” hoặc “FinalState”. - Các cạnh là chữ ký (signature) của các hàm, phương thức sẽ được gọi dùng để thay đổi trạng thái. Chữ ký này được định nghĩa gi ống như tên hàm trong mã nguồn của chương trình cần kiểm chứng, bao gồm cả kiểu giá trị trả về, tên hàm, danh sách các tham số truyền vào. Ví dụ: o Trong mã nguồn, ta gọi hàm init() không có tham số truyền vào, kiểu trả về là void thì tên của cạnh trong biểu đồ UML sẽ là: void init(). o Hàm int setAge(int age) được gọi trong mã nguồn thì tên của cạnh tương ứng sẽ là: int setAge(int age). Đối số age là không bỏ được. - Chú ý rằng tên của tham số truyền vào phải giống với tên biến đã khai báo trong mã nguồn của chương trình cần kiểm chứng. - Điều kiện tiên quyết (precondition) để hàm được gọi sẽ được mô tả trong “GuardCondition” của cạnh. Điều kiện này cũng phải giống với điều kiện trong mã nguồn của chương trình. Hoặc nó là đoạn code trả về giá trị boolean (ví dụ như một phương thức tĩnh (static) boolean isTrue()) Sau đây là ví dụ mô tả một cạnh trong biểu đồ trạng thái UML: - Đoạn mã trong chương trình: if(temp.isTrue()) { init(); ..... } - Ta sẽ mô tả cạnh của biểu đồ trạng thái UML như sau: Hình 4.1: UMLTransition o Tên của cạnh (Name): void init(). o Điều kiện tiên quyết (GủadCondition): temp.isTrue() 4.1.2 Xây dựng cấu trúc dữ liệu mô tả biểu đồ trạng thái UML Ta có thể thấy một biểu đồ trạng thái UML gồm hai thành phần chính: Các trạng thái (State) và các cạnh (Transition). Tôi sẽ xây dựng hai lớp để mô tả hai thành này phần của biểu đồ trạng thái UML. 37 4.1.2.1 Lớp State – mô tả các trạng thái (các đỉnh) Trong biểu đồ trạng thái UML, đỉnh được mô tả gồm có tên của đỉnh, các cạnh đi vào đỉnh và các cạnh đi ra từ đỉnh. Trạng thái bắt đầu chỉ có cạnh đi ra, không có cạnh đi vào. Trạng thái kết thúc, chỉ có các cạnh đi vào đỉnh, không có các cạnh đi ra từ đỉnh. Như vậy, để mô tả một trạng thái ít nhất ta cần mô tả ba dữ liệu: tên đỉnh, các cạnh đi vào và các cạnh đi ra. Để xét xem còn dữ liệu nào cần mô tả nữa không, ta xem cách tài liệu XMI mô tả một trạng thái của biểu đồ trạng thái UML (Phụ lục A). <UML:SimpleState xmi.id="UMLCompositeState.17" name="State1" visibility="public" isSpecification="false" container="UMLCompositeState.15" outgoing="UMLTransition.22" incoming="UMLTransition.21" 4.1.2.2 Lớp Transition – mô tả các cạnh của biểu đồ trạng thái UML /> Nhìn vào cách tài liệu XMI mô tả một trạng thái, ta thấy cần mô tả thêm một dữ liệu nữa về một trạng thái, đó là id của trạng thái (xmi.id). Tài liệu XMI dùng id của trạng thái để đại diện cho một trạng thái bất kỳ trong các liên kết của trạng thái đó với các thành phần khác của biểu dồ, vì vậy dữ liệu về id của trạng thái là rất quan trọng, không thể bỏ qua. Tóm lại, ta cần bốn dữ liệu để mô tả một trạng thái: id của trạng thái, tên trạng thái, các cạnh đi vào và các cạnh đi ra. Và lớp State mô tả trạng thái được xây dựng cơ bản như sau: public class State { private String xmiId; private String name; private String[] incoming; private String[] outgoing; // các phương thức khác. } Một cạnh được mô tả gồm có tên của cạnh và là một đường liên kết giữa hai đỉnh trong biểu đồ trạng thái UML, bắt đầu từ một đỉnh (trạng thái) của biểu đồ và kết thúc ở một đỉnh khác. Vì vậy, để mô tả một cạnh của biểu đồ, ta phải mô tả tên của cạnh, đỉnh bắt đầu của cạnh và đỉnh kết thúc của cạnh. Ngoài ra, tài liệu XMI dùng id để mô tả các thành phần của biểu đồ, như vậy đỉnh bắt đầu và đỉnh kết thúc của cạnh sẽ là id của đỉnh bắt đầu và kết thúc. Mặt khác ta cũng cần thêm id để mô tả id của cạnh. Như vậy, ta đã có 4 dữ liệu cần thiết phải mô tả một cạnh, đó là: id của cạnh, tên của cạnh, 38 id của đỉnh bắt đầu, id của đỉnh kết thúc. Ta xét xem XMI mô tả biểu cạnh của biểu đồ trạng thái như thế nào: <UML:Transition xmi.id="UMLTransition.11" name="void init()" visibility="public" isSpecification="false" stateMachine="UMLStateMachine.4" source="UMLPseudostate.6" target="UMLCompositeState.7"> <UML:BooleanExpression xmi.id="X.17" body="a >= b" - Id của cạnh: xmi.id /> Như vậy sau khi xét tài liệu XMI, ta thấy: Ngoài bốn dữ liệu cần thiết đã chỉ ra ở trên, tài liệu XMI còn mô tả điều kiện tiên quyết để phương thức được thực hiện trong phần tử là phần tử con của . Tóm lại, để mô tả một cạnh, ta cần năm dữ liệu sau: - Tên cạnh: name - Id của đỉnh mà từ đó cạnh đi ra: source - Id của đỉnh mà cạnh đi vào: target - Điều kiện tiên quyết: guard.expression. Lớp Transition được xây dựng như sau: public class Transition { private String xmiId; // ID của cạnh private String name; // Tên cạnh private String source; // ID của đỉnh mà cạnh đi ra private String target; // ID của đỉnh mà cạnh đi vào private String preCondition; // điều kiện để chuyển trạng thái ..... } 4.1.2.3 Mô tả biểu đồ trạng thái bằng các đối tượng trong Java Hai lớp State và Transition mô tả hai thành phần chính của biểu đồ trạng thái UML. Tuy nhiên, một biểu đồ trạng thái thường có nhiều State và nhiều Transition, vì vậy để tiện cho việc truy xuất dữ liệu về các thành phần này tôi xây dựng thêm hai lớp nữa mô tả danh sách các State (ListStates) và danh sách các Transition (ListTransitions) có trong biểu đồ trạng thái UML. Hai lớp này 39 có nhiệm vụ duyệt tài liệu XMI và lấy dữ liệu về các State, các Transition. Sơ đồ lớp mô tả các đối tượng được minh họa như hình vẽ dưới đây: Hình 4.2: Sơ đồ lớp biểu diễn biểu đồ trạng thái bằng các đối tượng trong Java Trong hai lớp ListStates và ListTransitions, tôi xây dựng thêm một số phương thức khác để lấy các thành phần dữ liệu của một State và Transition một cách dễ dàng như: lấy dữ liệu về một State khi biết id của State hay lấy dữ liệu về một Transition khi biết id của Transition đó. Cách xây dựng các hàm này hết sức đơn giản, khi ta đã có m ột danh sách các State và Transition, ta chỉ việc duyệt trong danh sách này, so sánh id của State hoặc Transition với tham số id truyền vào, nếu đúng thì ta xuất dữ liệu ra theo ý muốn. Như đã trình bày ở chương 3, tôi sử dụng thư viện XML DOM trong Java để đọc thông tin từ tài liệu XMI. Cấu trúc của tài liệu XMI này tôi chỉ rõ ở phụ lục A; Ở đây, tôi sẽ chỉ ra các node (thẻ XML) cần đọc để lấy dữ liệu. - Các trạng thái: o Trạng thái bắt đầu: : . o Trạng thái kết thúc: . o Trạng thái trung gian: . o Với mỗi trạng thái, các thuộc tính (attribute) cần đọc để lấy dữ liệu là:  xmi.id  name  incoming  outgoing 40  điều kiện sẽ được lấy thông qua thuộc tính body của phần tử con: . - Các cạnh (Transition) o Các node cần duyệt: . o Các thuộc tính cần đọc để lấy dữ liệu:  xmi.id  name  source  target Khi đã xác đ ịnh được các node, các thuộc tính cần đọc để lấy dữ liệu, công việc còn lại là đọc tài liệu XMI và tạo ra danh sách các trạng thái và danh sách các Transition là hết sức đơn giản như sau: - Khởi tạo ListState, ListTransition - Lấy danh sách các node (NodeList) của Transition và State. - Duyệt từng node trong NodeList - Tạo ra một Transition và một State mới, thêm vào danh sách. Sau bước này, ta sẽ có một danh sách mô tả các State và Transition có trong biểu đồ UML. Bước tiếp theo, tôi sẽ trình bày cách tạo ra FSM từ hai danh sách này. 4.1.3 Xây dựng FSM mô tả biểu đồ trạng thái UML Như ta đã bi ết, để chuyển từ trạng thái này, sang trạng thái kia thì cần có hàm chuyển trạng thái. Trong nghiên cứu của tôi, hàm chuyển trạng thái được mô tả trong các cạnh của biểu đồ trạng thái. Tập hợp các hàm chuyển trạng thái sẽ tạo thành giao thức mô tả hoạt động của đối tượng. FSM được xây dựng cần phải mô tả được giao thức này. Mặt khác, trong mã nguồn của chương trình, các tr ạng thái hầu như không có ý nghĩa, các đoạn mã chỉ mô tả các phương thức được thực hiện – chính là các cạnh của biểu đồ, và mục đích của việc kiểm chứng ở đây chính là kiểm tra xem các phương thức trong mã nguồn của chương trình có được gọi theo đúng giao thức đã được chỉ ra hay không. Để kiểm tra việc này, công cụ tự sinh aspect cần phải biết phương thức nào được gọi trước, phương thức nào được gọi sau từ đó sẽ kiểm tra được các vi phạm các giao thức ràng buộc đối tượng. FSM được xây dựng cần phải mô tả được điều này. Dựa vào bài báo [5] tôi xây dựng FSM gồm các thành phần dữ liệu sau: HashMap> fsm = null; HashSet entrySigs, exitSigs; 41 HashMap> stateMap = null; Trong đó: - entrySigs: Mô tả các cạnh đi ra từ trạng thái bắt đầu. - exitSigs: Mô tả các cạnh đi vào trạng thái kết thúc. - fsm: Là một HashMap, với key chính là một cạnh đi ra từ một trạng thái trung gian. Value chính là các cạnh đi vào trạng thái này. - stateMap: Biểu diễn các trạng thái và các cạnh đi vào trạng thái. Hashmap này sẽ được dùng để đánh số các trạng thái của biểu đồ. Thuật toán xây dựng FSM như sau: - Input: tài liệu XMI mô tả biểu đồ trạng thái UML - Output: FSM nếu xây dựng được, nếu không sẽ báo lỗi. - Các bước thực hiện: o Khởi tạo fsm, entrySigs, exitSigs, stateMap. o Đọc file XMI, lấy ListStates và ListTransitions. o Duyệt từng State trong ListStates  Tạo giá trị cho stateMap: • Nếu nó là trạng thái bắt đầu: thêm một phần tử mới với key là “START”, value = null. • Ngược lại thêm vào stateMap một phần tử với với key là tên trạng thái hiện tại, value là tên của các cạnh đi vào đỉnh.  Nếu nó là trạng thái bắt đầu, lấy tên + precondition cho vào entrySigs và cho vào fsm (biến fsm) với key là tên + precondition còn value là: “START”.  Nếu nó là trạng thái kết thúc, lấy tên + precondition cho vào exitSigs.  Nếu nó là trạng thái trung gian. • Lấy tên của tất cả các cạnh đi vào trạng thái cho vào cấu trúc dữ liệu dạng “Set” trong Java. • Duyệt từng cạnh đi ra từ trạng thái. Lấy tên + precondition. Thêm vào fsm key là tên + precondition của cạnh đi ra và value là “Set” chứa các cạnh đi vào ở trên. 42 4.2 Biểu đồ trình tự UML 4.2.1 Cách biểu diễn giao thức giữa nhiều đối tượng bằng biểu đồ trình tự UML Một biểu đồ trình tự bao gồm hai thành phần chính, đó là các đối tượng và các thông điệp trao đổi giữa các đối tượng. Các đối tượng ở đây, chính là tên của các lớp trong mã nguồn của chương trình. Các thông điệp trao đổi giữa các đối tượng chính là các phương thức của các lớp trong mã nguồn mà ta cần kiểm chứng. Khi mô tả giao thức giữa các lớp bằng biểu đồ trình tự UML, ta sẽ mô tả như sau: - Tên của lớp trong mã nguồn – cũng chính là tên của đối tượng (UMLObject) trong biểu đồ. Và đối với lớp, ta chỉ cần mô tả tên của lớp đó. - Các thông điệp trao đổi giữa các đối tượng được (UMLStimulus) mô tả đầy đủ các thành phần giống như mô tả phương thức của các lớp trong mã nguồn. Cũng gồm có tên phương thức, các tham số truyền vào, kiểu giá trị trả về và thông điệp là phương thức của lớp nào thì nó đư ợc bắt đầu đi ra từ lớp đó. o Tên phương thức mô tả thông qua thuộc tính name. o Các tham số truyền vào được mô tả thông qua thuộc tính Arguments. Các tham số truyền vào, được mô tả bao gồm cả kiểu dữ liệu và tên của tham số. Tên tham số giống như tên của tham số truyền vào trong lời gọi phương thức ở mã nguồn chính của chương trình. o Kiểu giá trị trả về được mô tả bằng thuộc tính Return. Cụ thể các thành phần này được mô tả chi tiết như hình dưới đây: 43 Hình 4.3: StarUML mô tả các thành phần trong biểu đồ trình tự Hoàn toàn tương tự cách xây dựng FSM từ biểu đồ trạng thái, FSM mô tả biểu đồ trình tự UML cũng được xây dựng hoàn toàn tương tự như vậy. Cũng gồm hai bước nhỏ: Thứ nhất là xây dựng cấu trúc dữ liệu mô tả các thành phần của biểu đồ, cách mô tả biểu đồ bằng các thành phần này. Thứ hai là xây dựng FSM từ các thành phần dữ liệu đã được cấu trúc hóa thành các đối tượng được định nghĩa ở bước thứ nhất. Biểu đồ trình tự UML gồm hai thành phần chính: Các đối tượng (Object) và các thông điệp trao đổi giữa các đối tượng (Stimulus). Tôi cũng xây dựng cấu trúc dữ liệu mô tả hai thành phần này như sau: 4.2.2 Xây dựng cấu trúc dữ liệu mô tả biểu đồ trình tự UML Phương pháp xây dựng cấu trúc dữ liệu mô tả biểu đồ trình tự UML hoàn toàn tương tự với cách xây dựng cấu trúc dữ liệu mô tả biểu đồ trạng thái mà tôi đã trình bày ở phần trước. Đầu tiên là tôi xem xét các thành phần chính của biểu đồ, ta sẽ mô tả dữ liệu gì thông qua các thành phần này. Tiếp theo là phân tích tài liệu XMI được xuất ra từ một biểu đồ trình tự UML, xem xét xem tài liệu XMI dùng các thẻ gì để mô tả các thành phần chính này, các thành phần dữ liệu trong thẻ (thuộc tính) gồm những gì. Cuối cùng, tôi sẽ lọc ra các dữ liệu cần thiết nhất và xây dựng các lớp Java để mô tả các thành phần chính của biểu đồ. Đây cũng chính là phương pháp phân tích tài li ệu XMI mà tôi sử dụng trong khóa luận. Áp dụng phương pháp phân tích tài liệu XMI ở trên, tôi xây dựng các lớp mô tả biểu đồ trình tự UML theo như biểu đồ lớp được mô tả trong hình vẽ dưới đây: 44 Hình 4.4: Sơ đồ lớp biểu diễn các thành phần của biểu đồ trình tự UML 4.2.2.1 Lớp ClassifierRole mô tả các đối tượng Mô tả các lớp trong biểu đồ trạng thái, ta chỉ mô tả tên của lớp, ngoài ra XMI mô tả thêm id của lớp, như vậy để mô tả một ClassifierRole, ta chỉ cần mô tả hai thành phần dữ liệu, đó là: id của lớp và tên của lớp: public class ClassifierRole { private String id; // ID cua lop private String name; // Ten lop } Tài liệu XMI, mô tả các lớp thông qua thành phần (thẻ) <UML: ClassifierRole>, trong đó: - xmi.id: Mô tả id của ClassifierRole. - name: Mô tả tên của ClassifierRole. Đây cũng chính là tên thẻ và tên các thuộc tính của thẻ khi ta duyệt tài liệu UML và lấy dữ liệu mô tả các ClassifierRole. 4.2.2.2 Lớp Message mô tả thông điệp trao đổi giữa các đối tượng Thông điệp – hay chính là tên của phương thức được gọi trong mã nguồn. Mà như ta đã biết, một phương thức được mô tả bởi các thành phần như: tên phương thức, các tham số truyền vào, kiểu giá trị trả về của phương thức và một thành phần quan trọng không kém là ta cần xác định xem phương thức đó thuộc lớp (class) nào. Nhưng khi phân tích tài liệu XMI ta thấy: Không giống như các thành phần khác của biểu đồ UML, các dữ liệu mô tả một thành phần đều là các thuộc tính của một loại thẻ nào đó. Ví dụ như thẻ mô tả các cạnh của biểu đồ trạng thái, thẻ <UML: 45 ClassifierRole> mô tả các đối tượng của biểu đồ trình tự. Dữ liệu mô tả về một thông điệp của biểu đồ trình tự UML được thể hiện qua hai loại thẻ khác nhau: - Thẻ chứa các dữ liệu mô tả tên phương thức, lớp chứa phương thức đó. - Thẻ mô tả các tham số, kiểu giá trị trả về của phương thức. Vì vậy, tôi xây dựng hai lớp độc lập nhau để lưu trữ những thành phần dữ liệu khác nhau của một thông điệp được mô tả trên hai loại thẻ XML khác nhau. Đó là lớp Message và lớp TaggedValue. Lớp Message mô tả hai dữ liệu về thông điệp được mô tả trong thẻ đó là tên phương thức và id của lớp chứa phương thức đó. Lớp TaggedValue đại diện cho thẻ mô tả về tên các tham số và kiểu giá trị trả về của phương thức: - Class Message: public class Message { private String id; //ID cua message private String name; // Ten cua message private String sender; // ID cua lop } - Class TaggedValue: public class TaggedValue { private String value; // gia tri cua TaggedValue private String ID; // ID cua Message } Một thông điệp sẽ là sự kết hợp của Message và TagedValue. Thông qua thuộc tính id của thông điệp. 4.2.2.3 Mô tả biểu đồ trình tự UML bằng các đối tượng trong Java Ta đã có ba lớp cơ bản: ClassifierRole, Message, TagedValue để mô tả hai thành phần quan trọng của biểu đồ trạng thái UML, đó là đối tượng và thông điệp trao đổi giữa các đối tượng. Trong một biểu đồ trình tự, không chỉ có một đối tượng hay một thông điệp, mà nó chứa mỗi chuỗi các đối tượng và các thông điệp trao đổi giữa các đối tượng, tạo nên giao thức trao đổi thông điệp giữa các đối tượng. Do đó, cũng giống như mô tả biểu đồ trình tự, để mô tả các thành phần có trong biểu đồ trình tự, tôi cũng dùng một danh sách các ClassifierRole để lưu trữ tất cả các đối tượng có trong biểu đồ. Danh sách các Message và danh sách các TagedValue để lưu trữ tất cả các thông điệp trao đổi giữa các đối tượng trong biểu đồ. Các lớp này được mô tả trong hình 4.3. 46 Ngoài ra tôi cũng xây dựng thêm các phương thức giúp truy xuất dữ liệu về từng thành phần trong danh sách các đối tượng trong lớp được dễ dàng hơn thông qua id của đối tượng đó. 4.2.3 Xây dựng FSM mô tả biểu đồ trình tự UML Giao thức được mô tả bằng biểu đồ trình tự là giao thức liên quan đến nhiều lớp đối tượng khác nhau, nhưng xét cho cùng, nó cũng g ần giống với giao thức trên một lớp đối tượng được mô tả bằng biểu đồ trạng thái. Nó cũng quy đ ịnh dãy các phương thức sẽ được gọi trong chương trình và l ập trình viên sẽ phải gọi các phương thức trong các lớp khác nhau đúng theo trình tự như vậy. Việc kiểm chứng, xét cho cùng cũng chính là để kiểm tra xem lập trình viên gọi các phương thức có đúng như giao thức đặc tả ban đầu không. Do đó, Máy trạng thái mô tả biểu đồ trình tự tôi xây dựng cũng tương tự với máy trạng thái mô tả biểu đồ trạng thái. Gồm ba thành phần dữ liệu: HashMap> fsm = null; HashSet entrySigs, exitSigs; - entrySigs: Mô tả phương thức bắt đầu của giao thức - exitSigs: Mô tả phương thức kết thúc giao thức - fsm: Là một HashMap, với key một phương thức bất kỳ khác phương thức mở đầu và phương thức kết thúc giao thức. Value chính là phương thức ngay trước nó trong giao thức. Một câu hỏi đặt ra là: Trong biểu đồ trình tự, các phương thức (thông điệp) được mô tả theo một dãy và đư ợc đánh số thứ tự tự động bắt đầu từ 1, như vậy thì cần ba thành phần dữ liệu để mô tả một dãy gọi phương thức như vậy có phải là thừa không? Tôi xin trả lời là không hề thừa chút nào. Vì trong khi kiểm chứng, theo như bài báo [5] đề cập, không phải trong chương trì nh, mỗi lớp đối tượng được đặc tả ở đây chỉ được khởi tạo và thực hiện một lần. Lập trình viên có thể thực hiện giao thức nhiều lần bằng cách khai báo các biến khác nhau của các lớ