Khóa luận Kiểm chứng cài đặt biểu đồ tương tác với UML 2.0

Mục lục

Chương 1. Mở đầu 1

1.1. Đặt vấn đề 1

1.2. Nội dung bài toán 2

1.3. Tổng quan phương pháp “kiểm chứng cài đặt biểu đồ tương tác với UML 2.0” 2

1.4 . Cấu trúc khóa luận 4

Chương 2. Annotaions , Aspects và UML 2.0 5

2.1. Annotations 5

2.1.1. Khái niệm annotaions 5

2.1.2. Ưu điểm của annotations 5

2.1.3. Cấu trúc annotaions 6

2.1.4. Target annotions 6

2.2. Aspect 7

2.2.1. Lập trình hướng khía cạnh AOP 7

2.2.2. AspectJ 9

2.3. UML 2.0 10

2.3.1. khai niệm về UML 10

2.3.2. Biểu đồ trình tự UML 11

2.4. Xây dựng máy trạng thái từ biểu đồ trình tự 16

2.4.1. Cấu trúc dữ liệu mô tả biểu đồ trình tự 16

2.4.2. Xây dựng máy trạng thái(FSM) 18

2.5. Tổng kết chương 19

Chương 3 . Xây dựng cộng cụ tự động sinh Aspect từ máy trạng thái 20

3.1. Biểu đồ trình tự và các đoạn gộp 20

3.2. Sinh Aspect từ biêu đồ trình tự 21

3.3. Kết luận 23

Chương 4. Thực nghiệm 24

4.1. Xây dựng công cụ 24

4.2. Kiểm chứng một số giao thức thực tế 27

4.2.1. Kiểm chứng biểu đồ truy cập thông tin cơ bản của một máy ATM 27

4.2.2. Kiểm chứng biểu đồ loop 32

4.2.3. Kiểm chứng biểu đồ tổng quát 36

4.3. Kết luận 44

Chương 5. Kết luận 45

Phụ lục 47

Phụ lục A : Tài liệu XMI mô tả biểu đồ trình tự 47

 

 

doc56 trang | Chia sẻ: netpro | Lượt xem: 2257 | Lượt tải: 1download
Bạn đang xem trước 20 trang tài liệu Khóa luận Kiểm chứng cài đặt biểu đồ tương tác với UML 2.0, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
g thức. Ví dụ : @Test_Target(“test”) Public void test(){ // do something } Đối với annotations dạng này, nếu nó được định nghĩa dùng cho loại đối tượng nào thì nó chỉ có thể ghi chú cho loại đối tượng đó. Như annotaions ở ví dụ trên, nó chỉ có thể ghi chú cho đối tượng là một phương thức. Nếu sử dụng nó ghi chú cho một class hoặc một biến thì sẽ nhận được lỗi. 2.2. Aspect 2.2.1. Lập trình hướng khía cạnh AOP Vấn đề cốt lõi của AOP là cho phép chúng ta thực hiện các vấn đề riêng biệt một cách linh hoạt và kết hợp chúng lại để tạo nên hệ thống sau cùng. AOP bổ sung cho kỹ thuật lập trình hướng đối tượng bằng việc hỗ trợ một dạng mô-đun khác, cho phép kéo thể hiện chung của vấn đề đan nhau vào một khối. Khối này được gọi là ‘Aspect’ (tạm dịch là ‘lát’ – hàm ý lát cắt đi qua nhiều lớp đối tượng), từ chữ ‘Aspect’ này chúng ta có tên của phương pháp phát triển phần mềm mới: Aspect-oriented programming. Nhờ mã được tách riêng, vấn đề đan nhau trở nên dễ kiểm soát hơn. Các Aspect của hệ thống có thể thay đổi, thêm hoặc xóa lúc biên dịch và có thể tái sử dụng. Một dạng biên dịch đặc biệt có tên là Aspect Weaver thực hiện kết hợp các thành phần riêng lẻ lại thành hệ thống hợp nhất. AOP gồm 3 bước phái triển : Phân tích các yêu cầu để xác định vấn đề chung và vấn đề đan nhau. Xây dựng thể hiện từng vấn đề riêng biệt. Tổng hợp các thể hiện. Trình biên dịch AOP thực hiện theo hai bước : Kết hợp các hành vi riêng lẻ. Chuyển đổi thông tin kết quả sang dạng mã thực thi. Các ưu điểm của AOP[4]: Mô đun hoá những vấn đề đan nhau: AOP xác định các vấn đề một cách tách biệt hạn chế tối thiểu việc nhập nhằng mã, cho phép mô đun hoá cả vấn đề liên quan đến nhiều lớp đối tượng. Dễ dàng phát triển hệ thống: Việc thêm chức năng mới có thể thực hiện dễ dàng bằng cách tạo Aspect mới mà không cần quan tâm đến vấn đề đan nhau. Khi thêm các mô đun mới vào hệ thống, các Aspect hiện có sẽ đan kết với chúng và tạo nên sự phát triển chặt chẽ. Cho phép để lại quyết định thiết kế tương lai: Một thiết kế tốt phải tính đến cả yêu cầu hiện tại và tương lai, việc xác định yêu cầu tương lai là một công việc khó khăn. Nếu bỏ sót những yêu cầu tương lai có thể bạn sẽ phải thay đổi hay thực hiện lại nhiều phần hệ thống. Với AOP, người thiết kế hệ thống có thể để lại các quyết định thiết kế cho những yêu cầu tương lai nhờ thực hiện theo Tái sử dụng mã tốt hơn: Các Aspect là những mô đun riêng biệt, được kết hợp linh động – đây chính là yếu tố quan trọng để tái sử dụng mã. AOP cho phép tái sử dụng mã tốt hơn OOP. 2.2.2. AspectJ AspectJ là một mở rộng của lập trình hướng khía cạnh AOP để giúp cho việc học và phát triển ứng dụng Java dựa trên AOP dễ dàng nhanh chóng. AspectJ giúp cho việc mô-đun hóa các vấn đề quan tâm trong việc phát triển ứng dụng dễ dàng hơn như là: kiểm tra và xử lý lỗi, đồng bộ hóa, tối ưu hóa hiệu quả, theo dõi, tìm lỗi. AspectJ được cấu thành từ join-point, pointcut, advice[7]. Jointpoints là điểm định nghĩa trong chương trình, jointpoint có thể là một lời gọi hàm, khởi tạo một lớp, khởi tạo một đối tượng. Nhờ join-points mà ta có thể xác định các điểm mà chức năng cắt ngang hệ thống thêm vào. Join-point có các loại chính sau : Join-point tại các hàm khởi tạo. Join-point tại các điểm truy cập thuộc tính. Join-point tại các điểm truy cập ngoại lệ Pointcut là tập hợp các joinpont mà bạn sử dụng định nghĩa để thực thi advice. Pointcut sẽ chọn một jointpoint nào đó và ngữ cảnh tại join-point đó. Cú pháp của pointcut như sau : [acess specifier] pointcut pointcut-name([args]) : pointcut-definition; Ví dụ : public pointcut test() : call(String Start()) || call(boolean end()); Mã được thực thi ở từng join-point được gọi advice. Có nhiều loại advice: before - thực thi trước join-point, after - thực thi sau nó.Như vây, Advice là mã sẽ được thực hiện tại một joint-point mà được chọn bởi một pointcut. Advice được chia làm các loại sau : Before : Được thực hiện trước join-point Around: Được thực hiện sau join-point Affter : Được thực hiện sau joint-point AspectJ 5 có nhiều điểm mở rộng hơn so với các AspectJ trước đó, một điểm nỏi bật là nó có thể sử dụng annotations trong Java 5 như một join-point. Thông thường annotations trong trường hợp này được định nghĩa như một target annotations. Target annotaions này có thể được định nghĩa cho lớp, phương thức hoặc một thành phần nào khác. Trong khóa luận của tôi, tôi sử dụng annotaions định nghĩa cho phương thức. Với một annotations được định nghĩa cho phương thức. Nó sẽ được ghi chú trước một phương thức nào đó. Khi đó Aspect sẽ định nghĩa phương thức đó dưới dạng như sau : @Tên_annotations Tên_phương_thức(danh sách đối số). Ví dụ: pointcut test() : call(@Implement * m()); Ví dụ trên, pointcut được kích hoạt khi một phướng thức m() được ghi chú bởi annotations @Implement được gọi. 2.3. UML 2.0 2.3.1. khái niệm về UML UML (Unified Modeling Language) là một ngôn ngữ chuẩn cho việc cụ thể hóa, trực quan hóa, xây dựng và tạo tài liệu cho một hệ thống phần mềm, cũng như cho mô hình doanh nghiệp và những hệ thống khác. UML miêu tả một loạt các kỹ thuật công nghệ tốt nhất đã được kiểm chứng và thành công trong nhiều hệ thống lớn và phức tạp. UML là một phần quan trọng trong việc phát triển các phần mềm hướng đối tượng và trong quy trình phát triển phần mềm. UML sử dụng hầu hết các ký hiệu đồ họa để mô tả bản thiết kế của các dự án phần mềm. Sử dụng UML sẽ giúp cho các nhóm dự án có thể dễ dàng giao tiếp, khai thác những tiềm năng thiết kế, và phê chuẩn thiết kế kiến trúc của phần mềm. Những mục đích chính trong việc thiết kế của UML là: Cung cấp cho người dùng với một tài liệu đọc để sử dụng, có ý nghĩa như một ngôn ngữ mô hình trực quan, vì vậy họ có thể phát triển và trao đổi các mô hình có ý nghĩa. Cung cấp cơ chế đặc tả và khả năng mở rộng để mở rộng các khái niệm cốt lõi. Không phụ thuộc vào ngôn ngữ lập trình cụ thể và các quy trình phát triển Cung cấp một cơ sở chính thức cho việc hiểu những ngôn ngữ mô hình hóa. Gia tăng sự phát triển của thị trường các công cụ hướng đối tượng Hỗ trợ sự phát triển ở mức cao hơn các khái niệm như collaborations, frameworks, patterns and components. Tích hợp trong thực tế tốt nhất. UML 2.0 với nhiều thay đổi trong việc mô tả các thành phần trong biểu đồ. Với sự mở rộng trong mô tả các thành phần như đoạn gộp alt,opt, loop … mang lại nhiều tiện lợi cho người sử dụng. Dưới đây, tôi sẽ mô tả về một số thành phần trong biểu đồ trình tự UML 2.0. 2.3.2. Biểu đồ trình tự UML Một biểu đồ trình tự chỉ ra một cộng tác động giữa một loạt các đối tượng . Khía cạnh quan trọng của biểu đồ này là chỉ ra trình tự các thông điệp (message) được gửi giữa các đối tượng. Nó cũng chỉ ra trình tự tương tác giữa các đối tượng, điều sẽ xảy ra tại một thời điểm cụ thể nào đó trong trình tự thực thi của hệ thống. Các biểu đồ trình tự chứa một loạt các đối tượng được biểu diễn bằng các đường thẳng đứng. Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua. Các thông điệp được biểu diễn bằng các đường gạch ngang gắn liền với mũi tên (biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng. Trục thời gian cùng những lời nhận xét khác thường sẽ được đưa vào phần lề của biểu đồ. Dưới đây là một ví dụ về biểu đồ tuần tự. Hình 2.3.2a: Quá trình đăng nhập ATM Tiếp theo đây, tôi sẽ giới thiệu về các dạng của biểu đồ tuần tự trong UML 2.0. Uml 2.0 đã có sự thay đổi đáng kể vể cách thức biểu diễn biểu đồ tuần tự. Đầu tiên là chú thích trong biểu đồ, đặt tên thành thành phần chú thích trong một khung, thành phần khung được sử dụng như một nền tảng cho UML 2.0[1]. Một thành phần khung cung cấp một ranh giới cho biểu đồ, xác định vị trí và mối quan hệ của các thành phần trong biểu đồ. Dưới đây, là mô tả cho khung. Hình 2.3.2b mô tả một khung cơ bản Với biểu đồ tuần tự, có tất cả 12 loại đoạn gộp được định nghĩa:alt, opt, break, par, seq, strict, neg, critical, ignore, consider, assert, loop . Nhưng trên thực tế chỉ có 4 dạng là được sử dụng chủ yếu đó là : alt,opt, loop và break. Sau đây tôi sẽ trình bày về 4 loại này. 2.3.2.1. Alt Mục đích là tìm kiếm sự lựa chọn tổng thể có thể thay thế lẫn nhau giữa hai hoặc nhiều trình tự thông điệp. Các sự thay thế cho phép sự mô hình hóa cổ điển (if else)“nếu thì” (ví dụ : nếu tôi mua ba thứ thì tôi được giảm giá 15 % ; hoặc tôi được giảm giá 10%). Hình 2.3.2.1 biểu đồ trình tự sử dụng alt 2.3.2.2. Opt Mảng kết hợp opt(sự tùy chọn) được sử dụng để mô hình một trình tự sẽ xảy ra, giả sử trong điều kiện nhất định; nếu không trình tự sẽ không xảy ra. Sự tùy chọn được sử dụng để mô tả một mệnh để đơn giản “if then” (nếu thì) (ví dụ: nếu có ít hơn 5 cái bánh trên bàn thì thêm 2 cái bánh nữa) . Chú thích của mảng kết hợp tùy chọn tương tự đối với mảng kết hợp thay thế, ngoại trừ nó chỉ có một toán hạng và không bao giò có trạng thái “else”. Hình 2.3.2.2 biểu đồ dùng opt 2.3.2.3. Loop Đôi khi bạn sẽ cần một trình tự lặp đi lặp lại. Trong UML 2.0 mô hình hóa một biểu đồ lặp đi lặp lại đã được cải tiến cùng với điều kiện của mảng kết hợp vòng lặp. Hình 2.3.2.3 biểu đồ sử dụng loop 2.3.2.4 . Break Các khung break được dùng thông dụng để mô hình hóa ngoại trừ sự kiểm soát. Hình 2.3.2.4 Biểu đồ sử dụng break Với ví dụ trên, khi kiểm tra điều kiện balance < amount là sai thì thực hiện phần phía sau của đoạn gộp break. Ngược lại, nếu điều kiện là đúng thì đoạn gộp break được thực hiện. khi các thông điệp trong đoạn gộp break được thực hiện hết thì các thông điệp khác bên ngoài không được thực hiện nữa. 2.4. Xây dựng máy trạng thái từ biểu đồ trình tự 2.4.1. Cấu trúc dữ liệu mô tả biểu đồ trình tự Một biểu đồ trình tự gồm nhiều thành phần, trong đó có các thành phần quan trọng như đường sống, các thông điệp được trao đổi giữa các đường sống, các đoạn gộp,… khi miêu tả biểu đồ trình tự ta mô tả như sau: Tên lớp trong mã nguồn chương trình tương ứng với tên một đường sống. Các thông điệp trao đổi giữa các đường sống mô tả đầy đủ các thành phần như một phương thức trong lớp tương ứng ở mã nguồn chương trình. Một phương thức co các thành phần như tên, giá trị trả về, danh sách tham số. Hình 3.1.1 : Altova Umodel mô tả thành phần trong biểu đồ trình tự. Để xậy dựng được máy trạng thái(FSM) đầu tiên cần phải có cấu truc dữ liệu mô tả biểu đồ trình tự. Hai thành phần quan trọng cần xây dựng là đường sống và thông điệp được trao đổi giữa các đường sống. Bằng việc phân tích tài liệu XMI , các lớp mô tả thành phần đường sống và thông điệp giữa các đường sống được cài đặt. Lớp LifeLine mô tả một đường sống. class Lifeline { private String id, className, name; private boolean isMultiObject; String objectName; ///// } Trong tài liệu XMI, một đường sống được định nghĩa trong thẻ lifeline và nó có các thành phần quan trọng như: xmi.id cho biết id của đường sống. name mô tả tên của đường sống. Đối với phương thức trao đổi giữa hai đường sống được cài đặt thông qua lớp Message. Lớp này được cài đặt như sau : public class Message implements Comparable{ private String id, name; private String sendEventId, receiveEventId; String className; Lifeline from, to; String sourceState, targetState; ////////// } Trong tài liệu XMI, môt thông điệp được đặc tả trong thẻ message, với một thông điệp có các thành phần chính như sau : xmi.id mô tả id của thông điệp. name mô tả tên của thông điệp. sendEventId mô tả thành phần nguồn, nơi bắt đầu thông điệp. receiveEventId mô tả nơi đến của thông điệp. from thông điệp được bắt nguồn từ đường sống nào. To thông điệp kết thúc ở đường sống nào. sourceState cho biết trạng thái bắt đầu của thông điệp. targetState cho biết trạng thái kết thúc của thông điệp. 2.4.2. Xây dựng máy trạng thái(FSM) Trong biểu đồ trình tự, các thông điệp được để kế nhau, chúng mô tả thứ tự được gọi của các thông điệp. Việc mô tả các thành phần của máy trạng thái phải mô tả được điều này. Trong máy trạng thái, các tác nhân gây chuyển trạng thái chính là các thông điệp. Do đó, máy trạng thái được sinh ra phải mô tả được thứ tự trước sau của các thông điệp. Do đó, máy trạng thái được sinh ra gồm các thành phần dữ liệu sau : states danh sách các trạng thái của máy trạng thái. events danh sách các thông điệp. firstState trạng thái đầu tiên của máy trạng thái. lastStates tập các trạng thái cuối của máy trạng thái. Thuật toán xây dựng máy trạng thái : Bảng 2.4.2: Thuật toán xây dựng máy trạng thái[2] Stt tên Mô tả 1 input Tài liệu XMI 2 output Máy trangjt hái được sinh ra nếu không thông báo lỗi 3 Các bước thực hiện Khởi tạo fsm, states, events, firstState, lastState. Đọc file XMI, lấy các thành phần cần thiết: thông điệp, trạng thái,… Duyệt từng thông điệp, đưa vào events. Nếu là thông điệp cuối thì thêm trạng thái kết thúc vào lastStates. Nếu là thông điệp bắt đầu , thêm trạng thái nguồn vào firstState. Nếu là thông điệp trung gian, lưu các dữ liệu vào máy trạng thái 2.5. Tổng kết chương Trong chương này, tôi đã trình bày một số khái niệm cơ bản về annotations, AspectJ, annotaions trong AspectJ, UML, biểu đồ trình tự UML 2. Đây là các nền tảng trong khóa luận của tôi. Để xây dụng công cụ sinh Aspect tự động. Đồng thời tôi cũng trình bày thuật toán xây dựng máy trạng thái cơ bản. Chương 3 . Xây dựng cộng cụ tự động sinh Aspect từ máy trạng thái 3.1. Biểu đồ trình tự và các đoạn gộp Trong một biểu đồ trình tự UML2.0, các đoạn gộp là một trong các thành phần quan trọng. Để xây dựng được máy trạng thái thì cần mô tả được đầy đủa các yếu tố này. Có 4 loại đoạn gộp hay được sử dụng là alt, opt, loop, break. Do đó, cần xây dựng cấu trúc dữ liệu để lưu trữ chúng. Áp dụng phương pháp phân tích tài liệu XMI, các lớp mô tả khối gộp như sau. Hình 4.1 Sơ đồ biểu diễn các thành phần khối gộp Lớp CombinedFragment chịu trách nhiệm mô tả một đoạn gộp trong biểu đồ trình tự. Là một trong những thành phần quan trọng trong biểu đồ trình tự của UML2. Trong XMI một đoạn gộp được mô tả trong thành phần fragment với xmi:type="uml:CombinedFragment". Trong thành phần này, một đoạn gộp được mô tả bởi các thành phần như sau : Xmi.Id : cho biết id của đoạn gộp. Name : cho biết tên của đoạn gộp. interactionOperator : cho biết dạng của fragment là alt, loop,break hay opt … Ngoài ra các thành phần xmi.id và xmi.uuid có thể giúp chúng ta tình các message thuộc vào đoạn gộp bằng cách so sánh các id của đoạn gộp với các senEvent của message.Dưới đây là mô tả về lớp CombinedFragment. public class CombinedFragment { String id; Vector message; public Message firstMessageAfterFragment; ////// } Lớp Loop,opt,break các một lớp con của lớp CombinedFragment về cơ bản lớp này kế thừa các thành phần của lớp CombinedFragment. Chúng không có thêm thành phần nào. Để xác định chúng, trong quá trình phần tichs tài liệu XMI chúng ta so sánh thành phần interactionOperator để xác định. Lớp Alt là một lớp con của lớp CombinedFragment, khác với 3 lớp con trên, đôi với alse chúng ta cần quan tâm đến các thành phấn khác của nó. Alt là một mô tả điểu kiện chọn có trên hai điều kiện, chúng ta phải mô tả được điều này.Vì lý do đó, ngoài các thành phần như lớp cha lớp Alt còn có các thành phần Dưới đây là mô tả về lớp Alt. public class Alt extends CombinedFragment{ Vector ifMessage; Vector elseMessage; //} Sau đó, máy trạng thái sẽ được sinh ra như phân tích ở chương 2. 3.2. Sinh Aspect từ biểu đồ trình tự Việc kiểm chứng giao thức trên nhiều lớp đối tượng trong biểu đồ trình tự có thể coi như việc gọi tuần tự các phương thức. Giao thức được mô tả dưới dạng một FSM. Do đó, hành vi chuyển trạng thái là đúng khi: Trạng thái trước đó có gọi hàm chuyển trạng thái không. Điểu kiện chuyển trạng thái có thỏa mãn không. Khi thỏa mãn các điều kiện trên, thì sự chuyển trạng thái được thực hiện đúng và sẽ chuyển qua trạng thái mới. Như vậy, các join-point được xác định các điểm chuyển trạng thái; before advice sẽ chứa các hành vi kiểm tra sự chuyển trạng thái này là đúng hay sai. Sau đó, mã trạng thái được thay đổi; after advice chứa các hành vi kiểm tra điều kiện loop,alt, break, opt và kiểm tra điều kiện dừng. Để tiện cho việc kiểm tra, Trạng thái ban đầu của máy trạng thái ta đặt là “0”, dùng một biến Id để xác định tên các trạng thái hiện tại(ArrayList Id). Tại before, kiểm tra xem phương thức gây biến đổi trạng thái có phải bắt đầu từ một trạng thái có thể hiện tại hay không? Nếu vi phạm thì thông báo lỗi. Sau đó cập nhật lại trạng thái hiện tại. Trạng thái hiện tại được đặt mặc định ban đầu là “0”. Tại after advice. Khi này trạng thái hiện tại đã là trạng thái mới. Khi đó ta kiểm tra xem trạng thái này có thuộc alt, loop, opt hay break không, để đưa ra các hướng giải quyết tương ứng. Nếu nó là một trong các trạng thái kết thúc thì đưa ra thông báo tổng quát về qua trình thực hiện. Thuật toán sinh mã Aspect như sau : Bảng 3.2: Thuật toán sinh mã Aspect Bước Nội dung 1 Duyệt danh sách các trạng thái FSM, lấy các trạng thái rồi lấy tập các thông điệp gây ra biến đổi trạng thái. Dùng các hàm để xử lý các thông điệp này và đưa nó về dạng @Implement * ten_ham(). Sau đó đưa chúng vào pointcut. Việc này giúp chúng ta chỉ cần một pointcut. 2 Duyệt danh sách các trạng thái trong FSM lấy các trạng thái nguồn và các trạng thái đích tương ứng để tạo ra các điều kiện kiểm tra. 3 Tạo các pointcut, advice bằng cách thay thế các xâu tương ứng vừa được tạo ra ở trên vào vị trí cần thiết. 4 Kết hợp pointcut advice thành Aspect cần thiết Việc kiểm chứng cho từng thành phần đoạn gộp của biểu đồ trình tự lại có điểm khác nhau. Đối với break, opt khi trạng thại của chúng được kích hoạt thì ta đưa ra thông báo. Trạng thái kích hoạt một đoạn gộp break hoặc opt là trạng thái đầu tiên cuả nó. Do đó, khi một phương thức nào đó, kích hoạt sự chuyển trạng thái đến trạng thái này thì ta thông báo sự chuyển trạng thái đó. Đối với loop, nó cũng có trạng thái kích hoạt như trên. Nhưng với loop ta cần đếm số lần xuất hiện của nó. Do đó, ta dùng biến có tên dạng loop+ để đếm số lấn. Tại before, khi một trạng thái loop được kích hoạt thì ta tăng số lần đếm nó lên.Ví dụ: ta có một trạng thái kích hoạt loop là “2”. Ta đặt tên cho biến đếm lad loop2 và khởi tạo nó ban đầu là 0. Đối với alt, Tương tự nó có các trạng thái kích hoạt, nhưng khác với loop, break, opt. Với alt có nhiều trạng thái kích hoạt, do đó ta cần chỉ ra nó kích hoạt theo hướng nào. 3.3. Kết luận Trong chương này, tôi đã trình bày về cách xây dựng cấu trúc dữ liệu để mô tả các đoạn gộp. Từ đó, đưa các thông tin về các đoạn gộp vào máy trạng thái. Tại chương này, tôi đã trình bày về phương pháp sinh Aspect từ máy trạng thái để kiểm tra giao thức sinh ra từ biểu đồ tuần tự. Nội dung chính của phương pháp là duyệt qua các trạng thái của FSM, tìm các thành phần tương ứng và đưa vào Aspect dưới dạng các pointcut và các advice. Aspect được đưa ra kiểm chứng được hầu hết các giao thức mô tả bằng biều đồ trình tự UML như vòng lặp loop, lựa chọn một thành phần(opt), lựa chọn nhiều thành phần(đoạn gộp alt) và đoạn gộp break. Đây là mở rộng của UML 2. Aspect được sinh ra sẽ đan vào chương trình nguồn giúp cho việc kiểm chứng cho chương trình Java được thiết kế theo đặc tả của biểu đồ trình tự tương ứng. Chương 4. Thực nghiệm Để minh hoạ cho phương pháp xây dựng công cụ sinh Aspect được giới thiệu trong chương trước, chương này sẽ mô tả chi tiết các bước cài đặt mà tôi đã thực hiện và kết quả kiểm chứng trên một số giao thức thực tế. 4.1. Xây dựng công cụ Sau khi đặc tả giao thức kiểm chứng bằng UML, công cụ altova Umodel hỗ trợ xuất biểu đồ ra dạng XMI và đây chính là đầu vào cho công cụ của tôi. Áp dụng phương pháp đã giới thiệu ở các chương trước, tôi đã cái đặt thành công công cụ tự động sinh Aspect từ tài liệu XMI. Trong phương pháp này tối sử dụng công cụ eclipse và framework JDK để cài đặt công cụ. Giao diện làm việc của eclipse được minh họa như sau : Hình 5.1a : Cài đặt bằng công cụ eclipse Thuật toán cơ bản của phương pháp là việc phân tích tài liệu XMI, xây dựng cấu trúc mô tả các thành phần của biểu đồ trình tự UML. Từ đó, xây dựng máy trạng thái mô tả biểu đồ. Qua việc duyệt danh sách các trạng thái, phân tích tìm vị trí thích hợp của sinh ra xâu chứa nội dung Aspect, xâu Aspect chứa các nội dung tuân theo cấu trúc của Aspect. Về thực chất quá trình này thông qua các thông điệp để xác định nguồn và đích tương ứng mới phương thức được gọi, để sinh ra Aspect. Cài đặt công cụ thông qua các bước : Bước 1 : Tạo ra cấu trúc dữ liệu lưu các thông tin về biểu đồ trình tự. Bước 2 : Cài đặt thuật toán sinh ra máy trạng thái (FSM). Bước 3 : Cài đặt thuật toán sinh tự động Aspect. Hoàn tất quá trình cài đặt trên, tôi thu được công cụ tự động sinh mã kiểm chứng. Về công cụ của tôi, sau khi cài đặt như trên, tôi cài đặt dưới dạng một plugin dành cho eclipse. Với tên “org.eclipse.adj.creattoxmi”, để hoạt động được công cụ, đầu tiên phải copy file “org.eclipse.adj.creattoxmi.jar” vào thư mục “plugins” của eclipse. Khi đó, công cụ của tôi sẽ là một plugin dành cho eclipse, dưới đây là hình mô tả hoạt động của công cụ. Hình 5.1b : mô tả hoạt động của công cụ. Để hoạt động công của của tôi cài đặt, có một số yêu cầu như sau : Thứ nhất : copy file org.eclipse.adj.creattoxmi.jar vào thư mục plugins của eclipse. Thứ hai : import file Implement-Java.jar vào thư viện của project. Các file xmi được để trong một package của project.Mặc định, Aspect được sinh ra sẽ nằm trong package này. Hoạt động: Chọn file xmi cần chuyển qua Aspect. Nhấn ctrl + N Chọn Create Aspect from Xmi Hình 5.1.c : Lựa chọn chức năng Đặt lại tên và địa điểm để aspect nếu cần. Nếu không Aspect được sinh ra có tên trùng với tên của file XMI được chọn và ở trong package chứa file XMI đó. Hình 5.1d: Giao diện đặt tên cho aspect sinh ra Nếu không có file XMI nào được chọn hoặc Aspect không sinh ra được thì sẽ tạo ra một Aspect mặc định không có nội dung bên trong. 4.2. Kiểm chứng một số giao thức thực tế 4.2.1. Kiểm chứng biểu đồ truy cập thông tin cơ bản của một máy ATM 4.2.1.1. Đặc tả giao thức Hình 4.2.1.1. Giao thức truy cập thông tin cơ bản ATM Giao thức mô tả mối quan hệ giữa các lớp User, ATM, Consortium và Branch. Khi một đối tượng User gọi một phương thức getCashOnHand() một dãy các hàm được gọi phải tuân theo giao thức để hoàn thành quá trình. Quá trình được mô tả qua các thứ tự các hàm được gọi như sau : getCashOnHand() -> validateAccoutinfo() -> verifyCardWithBank(int stringCardStrinp) -> getConnected(). 4.2.1.2. Kiểm chứng Sử dụng công cụ altova Umodel tôi vẽ lại giao thức trên. Sau đó, xuất ra dưới dạng tài liệu XMI làm đầu vào cho công cụ. File XMI sinh ra được để trong fackage xmi của project. Khi chạy chương trình mã Aspect được sinh ra như sau : public Aspect ATM{ private boolean isError = false ; // xac dinh tính dung sai cua trang thai private int numError = 0; // xác địn số lỗi hiện tại private ArrayList Id = new ArrayList();//trạng thái hiện tại ArrayList listEnd = new ArrayList();// các trạng thái kết thúc //////////// Pointcut ATMChecked():call(@Implement * getConnected(char)) || call(@Implement * verifyCardWithBank(int)) || call(@Implement * validateAccoutinfo())|| call(@Implement * getCashOnhand()); before() : ATMChecked(){ String nameThisAspect = this.getClass().toString(); nameThisAspect = nameThisAspect.substring( nameThisAspect.lastIndexOf(".") + 1, nameThisAspect.length()); String CallMethod = getNameMethod( thisJoin-pointStaticPart); String AnnotationOfMethod = getAnnotationOfMethod(thisJoin-pointStaticPart); // kiem tra xem phuong thuc duoc goi co duoc dinh nghia de su dung aspect nay //khong if(isPart(nameThisAspect,AnnotationOfMethod) == false) return; if(Id.isEmpty()) Id.add("0"); // khoi tao trang thai ban dau // Dua cac trang thai ket thuc vao danh sach listEnd if(listEnd.isEmpty()){ listEnd.add("4"); } isError = true; // mac dinh la goi thu tu phuong thuc sai ArrayList l = new ArrayList(); ArrayList target = new ArrayList(); // dua cac trang thai co the la trang thai nguon khi goi phuong thuc vao l // dua cac trang thai co the la trang thai ket thuc vao danh sach target if( CallMethod.equals("* getConnected(char)")){ l.add("3"); target.add("4"); } else if( CallMethod.equals("* voidverifyCardWithBank(int)")){ l.add("2"); target.add("3"); } else if( CallMethod.equals("* validateAccoutinfo()")){ l.add("1"); target.add("2"); } else if( CallMethod.equals("* getCashOnhand()")){ l.add("0"); target.add("1"); } setIdIfTrue(l,target); /* kiem tra tinh dung

Các file đính kèm theo tài liệu này:

  • docKiểm chứng cài đặt biểu đồ tương tác với uml 20.doc