1. Trang chủ
  2. » Luận Văn - Báo Cáo

Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0

61 848 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 61
Dung lượng 2,34 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Phương pháp phân tích đối tượng của biểu đồ tuần tự thành các khối đơn .... Chương này trình bày phương pháp bóc tách đối tượng của biểu đồ tuần tự thành các khối đơn, tiếp đó là phương

Trang 1

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN QUỐC NAM

PHƯƠNG PHÁP KIỂM CHỨNG TÍNH ĐÚNG ĐẮN CỦA CÁC BIỂU ĐỒ TUẦN TỰ UML 2.0

Ngành: Công nghệ thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã Số: 60 48 01 03

LUẬN VĂN THẠC SĨ Ngành: Công nghệ Thông tin

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS TRỊNH THANH BÌNH ĐỒNG HƯỚNG DẪN: TS PHẠM NGỌC HÙNG

Hà nội – 2015

Trang 2

MỤC LỤC

MỤC LỤC i

LỜI CẢM ƠN iii

LỜI CAM ĐOAN iv

DANH MỤC THUẬT NGỮ VIẾT TẮT v

DANH MỤC HÌNH VẼ vi

DANH MỤC BẢNG viii

Chương 1: Giới thiệu 1

Chương 2: Phương pháp phân tích biểu đồ tuần tự nhằm xây dựng các mô hình đặc tả 3

2.1 Biểu đồ tuần tự UML2.0 3

2.2 Phương pháp phân tích đối tượng của biểu đồ tuần tự thành các khối đơn 11

2.3 Phương pháp sinh ôtômat vào/ra từ các khối đơn của biểu đồ tuần tự 14

2.3.1 Trường hợp khối đơn không chứa phân đoạn nào 16

2.3.2 Trường hợp khối đơn chứa một phân đoạn Option 16

2.3.3 Trường hợp khối đơn chứa một phân đoạn Alternative 18

2.3.4 Trường hợp khối đơn chứa một phân đoạn Loop 19

2.3.5 Trường hợp khối đơn chứa một phân đoạn Break 21

2.3.6 Trường hợp khối đơn chứa một phân đoạn Parallel 22

2.3.7 Trường hợp khối đơn chứa một phân đoạn Strict 23

2.3.8 Trường hợp khối đơn chứa một phân đoạn Critical 24

2.3.9 Trường hợp khối đơn chứa một phân đoạn Consider 25

2.3.10 Trường hợp khối đơn chứa một phân đoạn Ignore 27

2.4 Phương pháp xây dựng ôtômat vào/ra cho đối tượng của biểu đồ tuần tự 28

Chương 3: Công cụ sinh ôtômat vào/ra từ biểu đồ tuần tự 32

Trang 3

3.1 Giới thiệu về công cụ 32

3.2 Thực nghiệm 36

3.2.1 Bài toán đặt chỗ 36

3.2.2 Bài toán máy thanh toán ở siêu thị 40

3.3 Đánh giá 46

Chương 4: Phương pháp kiểm chứng tính đúng đắn của biểu đồ tuần tự qua ôtômat vào/ra 47

4.1 Kiểm chứng tính đúng đắn của biểu đồ tuần tự qua ôtômat vào/ra 47

4.2 Áp dụng phương pháp kiểm chứng với trường hợp bài toán đặt chỗ 48

Chương 5: KẾT LUẬN 50

TÀI LIỆU THAM KHẢO 51

Trang 4

LỜI CẢM ƠN

Trước tiên tôi xin dành lời cảm ơn chân thành và sâu sắc đến hai thầy giáo, TS Trịnh Thanh Bình và TS Phạm Ngọc Hùng – những người đã hướng dẫn, khuyến khích, chỉ bảo và tạo cho tôi những điều kiện tốt nhất từ khi bắt đầu cho tới khi hoàn thành công việc của mình

Tôi xin dành lời cảm ơn chân thành tới các thầy cô giáo khoa Công nghệ thông tin, trường Đại học Công nghệ, ĐH QGHN đã tận tình đào tạo, cung cấp cho tôi những kiến thức vô cùng quý giá và đã tạo điều kiện tốt nhất cho tôi trong suốt quá trình học tập, nghiên cứu tại trường

Đồng thời tôi xin chân thành cảm ơn những người thân trong gia đình cùng toàn thể bạn bè đã luôn giúp đỡ, động viên tôi trong những lúc gặp phải khó khăn trong việc học tập và nghiên cứu chương trình thạc sĩ tại Đại học Công nghệ, ĐH QGHN

Trang 5

LỜI CAM ĐOAN

Tôi xin cam đoan rằng luận văn thạc sĩ công nghệ thông tin “Phương pháp kiểm

chứng tính đúng đắn của các biểu đồ tuần tự UML 2.0” là công trình nghiên cứu của

riêng tôi, không sao chép lại của người khác Trong toàn bộ nội dung của luận văn,

những điều đã được trình bày hoặc là của chính cá nhân tôi hoặc là được tổng hợp từ

nhiều nguồn tài liệu Tất cả các nguồn tài liệu tham khảo đều có xuất xứ rõ ràng và

hợp pháp

Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định

cho lời cam đoan này

Hà Nội, ngày … tháng … năm 2015

Trần Quốc Nam

Trang 6

DANH MỤC THUẬT NGỮ VIẾT TẮT

STT Từ viết tắt Từ đầy đủ Ý nghĩa

1 DFA Deterministic Finite Automata Ôtômat hữu hạn trạng thái

2 I/O Automata Input/Output Automata Ôtômat vào/ra

Trang 7

DANH MỤC HÌNH VẼ

Hình 2.1 Phân đoạn Loop 4

Hình 2.2 Phân đoạn Alt 4

Hình 2.3 Phân đoạn Par và ví dụ thứ tự thực hiện 5

Hình 2.4 Phân đoạn Opt 6

Hình 2.5 Phân đoạn Break 6

Hình 2.6 Phân đoạn Seq 7

Hình 2.7 Phân đoạn Strict 8

Hình 2.8 Phân đoạn Ignore 8

Hình 2.9 Phân đoạn Consider 9

Hình 2.10 Phân đoạn Critical 9

Hình 2.11 Phân đoạn Neg 10

Hình 2.12 Phân đoạn Assert 10

Hình 2.13 Khối đơn gồm một phân đoạn opt 11

Hình 2.14 Khối đơn không chứa phân đoạn và ôtômát cho đối tượng User 16

Hình 2.15 Khối đơn chỉ chứa một phân đoạn Option và ôtômat cho đối tượng User 17

Hình 2.16 Khối đơn chỉ chứa một phân đoạn Alternative và ôtômat cho đối tượng User 19

Hình 2.17 Khối đơn chỉ chứa một phân đoạn Loop và ôtômat cho đối tượng User 20

Hình 2.18 Khối đơn chỉ chứa một phân đoạn Break và ôtômat cho đối tượng User 22

Hình 2.19 Khối đơn chỉ chứa một phân đoạn Paraller và ôtômat cho đối tượng Admin 23

Hình 2.20 Khối đơn chỉ chứa một phân đoạn Strict và ôtômat cho đối tượng User 24 Hình 2.21 Khối đơn chỉ chứa một phân đoạn Critical và ôtômat cho đối tượng User 25

Trang 8

Hình 2.21 Khối đơn chỉ chứa một phân đoạn Consider và ôtômat cho đối tượng User

26

Hình 2.22 Khối đơn chỉ chứa một phân đoạn Ignore và ôtômat cho đối tượng User 28

Hình 4.1.1 Kiến trúc của công cụ 32

Hình 4.1.2 Biểu đồ lớp của công cụ 33

Hình 4.1.3 Khối Loop đơn giản 34

Hình 4.1.4 Đầu ra của công cụ với khối Loop đơn giản 35

Hình 4.2.1 Biểu đồ tuần tự xử lý đặt chỗ 36

Hình 4.2.2 Đầu ra mong muốn cho đối tượng Oder 38

Hình 4.2.3 Đầu ra mong muốn cho đối tượng Ticket 38

Hình 4.2.4 Đầu ra mong muốn cho đối tượng Account 39

Hình 4.2.5 Biểu đồ tuần tự máy thanh toán ở siêu thị 40

Hình 4.2.6 Đầu ra mong muốn cho đối tượng Customer 42

Hình 4.2.7 Đầu ra mong muốn cho đối tượng Cashier 43

Hình 4.2.8 Đầu ra mong muốn cho đối tượng Card Processor 44

Hình 4.2.9 Đầu ra mong muốn cho đối tượng Cash Register 44

Trang 9

DANH MỤC BẢNG

Bảng 5.1 Mô phỏng kiểm chứng thuộc tính P với bài toán đặt chỗ 49

Trang 10

Chương 1: Giới thiệu

Đảm bảo chất lượng là một vấn đề quan trọng và tiêu tốn chi phí cao trong quá trình phát triển phần mềm Tự động hóa quá trình đảm bảo chất lượng là tiêu chí hướng tới của các doanh nghiệp nhằm giảm đi chi phí phát triển ngay từ khâu thiết kế Ngoài ra, đối với những sản phẩm có yêu cầu chất lượng cao như hệ thống điều khiển máy bay, tàu ga, kỹ thuật quân sự, y tế v.v nhà đầu tư sẽ yêu cầu áp dụng các phương pháp hình thức nhằm đảm bảo tính đúng đắn của thiết kế trước khi triển khai Giải pháp phố biến nhất hiện nay để giải quyết vấn đề trên là áp dụng các phương pháp kiểm chứng mô hình để tự động hóa quá trình kiểm chứng tính đúng đắn của thiết kế [2], [6], [9] Để

áp dụng những phương pháp này, ta cần phải xây dựng các mô hình đặc tả chính xác hành vi của hệ thống cần kiểm chứng [4], [10], [11] Tuy nhiên, xây dựng mô hình cho các hệ thống phần mềm là một công việc khó khăn và tiềm ẩn nhiều lỗi Các nghiên cứu hiện tại hầu hết giả sử các mô hình này đã có và đúng đắn Trong thực tế, giả định này rất khó để hiện thực, nhất là từ phía các công ty phát triển phần mềm Hạn chế trên

là một trong những nguyên nhân chính dẫn đến các phương pháp này khó áp dụng trong thực tế

Để giải quyết vấn đề nêu trên, một trong những hướng tiếp cận là sử dụng đầu vào cho các phương pháp kiểm chứng từ biểu đồ thiết kế UML Việc đưa ra phương pháp

mô hình hóa biểu đồ UML, ở đây là biểu đồ tuần tự UML 2.0, giúp cho việc áp dụng các phương pháp kiểm chứng mô hình hoàn toàn có thể thực hiện được trong thực tế

Nghiên cứu hiện tại được đề cập trong [3] tập trung xây dựng một ôtômat cho cả biểu

đồ tuần tự Phương pháp này chỉ đảm bảo được các thuộc tính an toàn (safety properties) [7], kiểm tra các hành vi một cách tuần tự theo thời gian Cách tiếp cận này không thể hiện được tính hướng đối tượng vốn có biểu đồ tuần tự là sự tương tác giữa các đối tượng với nhau, gửi và nhận các loại thông điệp, các điểm xuất phát và điểm đến của chúng, đặc biệt đối với các hệ thống tương tranh Vì vậy một cách khác ta cần bóc tách xây dựng ôtômat thể hiện hành vi của từng đối tượng trong mối quan hệ với các đối tượng khác từ đó ta có hành vi của hệ thống

Một cách tiếp cận để giải quyết vấn đề trên được đề xuất trong [5] Ý tưởng chính của phương pháp này là xây dựng một ôtômat vào/ra (Input/Output Automata – I/O

Trang 11

Automata) [8] cho mỗi đối tượng của biểu đồ tuần tự Ôtômat vào/ra là sự mở rộng của ôtômat hữu hạn trạng thái (Deterministic Finite Automata - DFA) [1] Các trạng thái trong ôtômat vào/ra biễu diễn các ánh xạ từ hành vi tới các đối tượng trong biểu

đồ tuần tự Hàm chuyển trạng thái được biểu diễn bởi ánh xạ hai ngôi (điều kiện, hành vi) thể hiện sự tương tác giữa các đối tượng [5] Luận văn tập trung vào xây dựng thuật toán và công cụ hiện thực hóa việc xây dựng ôtômat vào/ra cho các đối tượng trong biểu đồ tuần tự Các mô hình ôtômat vào/ra này cùng với việc đưa vào các thuộc tính sẽ là đầu vào cho các công cụ kiểm chứng hỗ trợ ôtômat vào/ra nhằm kiểm chứng tính đúng đắn của thiết kế

Phần còn lại của luận văn được cấu trúc như sau Phương pháp sinh mô hình cho các đối tượng của biểu đồ tuần tự UML2.0 được giới thiệu trong chương 2 Chương này trình bày phương pháp bóc tách đối tượng của biểu đồ tuần tự thành các khối đơn, tiếp đó là phương pháp sinh ôtômat vào/ra từ các khối đơn của biểu đồ tuần tự và cuối cùng là phương pháp ghép nối các ôtômat vào/ra được sinh ra từ các khối đơn để được một ôtômat cho cả đối tượng Chương 3 giới thiệu về công cụ thực nghiệm và kết quả thực nghiệm của phương pháp sinh ôtômat vào/ra cho các đối tượng của biểu đồ tuần

tự được trình bày trong chương 2 Chương 4 nghiên cứu phương pháp để kiểm chứng tính đúng đắn của biểu đồ tuần tự thông qua việc kiểm tra tính đúng đắn của các ôtômat vào/ra được sinh ra từ các đối tượng cùng các thuộc tính yêu cầu Chương này nghiên cứu phương pháp mô phỏng sự tương tác giữa các ôtômat vào/ra từ các đối tượng, qua đó kiểm chứng tính đúng đắn của biểu đồ tuần tự đối với thuộc tính yêu cầu Kết luận và định hướng phát triển cho luận văn được trình bày trong chương 5

Trang 12

Chương 2: Phương pháp phân tích biểu đồ tuần tự nhằm xây dựng các mô hình đặc tả

Để áp dụng các phương pháp kiểm chứng tự động dựa trên mô hình, việc đầu tiên cần làm là xây dựng các mô hình đặc tả thiết kế của phần mềm, ở đây là biểu đồ tuần tự UML2.0 Đầu vào của bài toán là biểu đồ tuần tự UML2.0, ta cần xây dựng thuật toán để chuyển đổi các đối tượng của biểu đồ tuần tự thành các ôtômat vào/ra [8]

Ý tưởng để giải quyết vấn đề trên là bóc từng đối tượng của biểu đồ tuần tự thành một tập các khối đơn (biểu đồ tuần tự và khối đơn được đề cập ở mục 2.1) Sau đó, thuật toán chuyển đổi được xây dựng để chuyển từng khối đơn đó thành các ôtômat vào/ra Cuối cùng, luận văn xây dựng thuật toán để ghép nối các ôtômat có được thành một ôtômat tương ứng với đối tượng của biểu đồ tuần tự Chi tiết các thuật toán được

mô tả trong 3 mục từ 2.2 đến 2.4

2.1 Biểu đồ tuần tự UML2.0

Biểu đồ tuần tự (Sequence Diagram – SD) thể hiện tương tác giữa các thực thể của hệ thống theo thứ tự trình tự mà các tương tác này xảy ra SD nhấn mạnh sự tương tác giữa các đối tượng và chỉ ra sự tương tác là khía cạnh quan trọng nhất Biểu đồ tuần tự UML2.0 đưa vào sự kết hợp giữa các phân đoạn (combined fragment), cho phép thực hiện các tương tác phức tạp Thành phần chính của biểu đồ tuần tự gồm: Đối tượng, Thông điệp và Phân đoạn

Đối tượng được biểu diễn bằng hai phần: phần tiêu đề khai báo đối tượng và chu

kỳ sống, các đối tượng tương tác với nhau thông qua các thông điệp Thời gian các đối tượng tồn tại được biểu diễn bằng đường đứt nét, chu kỳ sống biểu diễn bằng đường nét đôi

Thông điệp được biểu diễn ở dạng đường mũi tên từ chu kỳ sống của đối tượng

gửi đến đối tượng nhận Các mũi tên này được sắp xếp theo trình tự thời gian từ trên xuống Có ba loại thông điệp: Thông điệp đồng bộ (nét liền), thông điệp phản hồi (nét đứt), thông điệp đệ quy (gọi tới chính đối tượng)

Trang 13

Phân đoạn dùng để biểu diễn các luồng điều khiển phức tạp Mỗi phân đoạn có

một từ khóa và có một hoặc nhiều đoạn con (gọi là các toán hạng tương tác – interaction operands) Tương ứng với cấu trúc điều khiển trong các ngôn ngữ lập trình như lặp, rẽ nhánh, song song chúng ta có 12 phân đoạn khác nhau với các nhãn tương

ứng loop, alt, par, v.v [12]

Phân đoạn lặp (Loop): chỉ ra rằng phân đoạn kết hợp biểu diễn một vòng lặp

Toán hạng lặp sẽ được lặp đi lặp lại một số lần Điều kiện có thể gồm một cận dưới (minint), một cận trên (maxint) và một biểu thức Boolean Sau minint lần lặp, biểu thức được kiểm tra, chừng nào biểu thức còn đúng và số lần lặp còn nhỏ hơn hoặc bằng maxint thì vòng lặp vẫn tiếp tục Hình 2.1 miêu tả phân đoạn loop sau khi lặp hết

5 lần, nếu điều kiện size < 0 đúng thì dừng lặp, việc kiểm tra này còn thực hiện chừng nào số lần lặp còn <= 10

Hình 2.2 Phân đoạn Alt

Phân đoạn lựa chọn đầy đủ (Alternative): Phân đoạn alt được biểu diễn với

khung có tiêu đề “alt”, sử dụng để chỉ ra sự lựa chọn loại trừ lần nhau giữa hai hai nhiều chuỗi thông điệp Phân đoạn có thể cho hai hoặc nhiều điều kiện gắn liền với

Trang 14

toán hạng khác nhau cùng một lúc, nhưng chỉ có một toán hạng sẽ thực hiện tại thời gian chạy Minh họa của phân đoạn alt trong hình 2.2, nếu điều kiện balance > 0 thỏa mãn thì thông điệp accept() được gửi, ngược lại thì thông điệp reject() được gửi

par

1c: searchYahoo() 4: readResult()

1b: searchBing() 3: readResult()

2: readResult() 1a: searchGoogle()

Trang 15

Phân đoạn song song (Parallel): Phân đoạn par được biểu diễn với khung có tiêu

đề “par”, phân đoạn par chỉ ra rằng các toán hạng trong phân đoạn kết hợp có thể được thực thi song song với nhau Các sự kiện trong các toán hạng khác nhau có thể đan xen vào nhau theo bất cứ cách nào, miễn là thứ tự của các sự kiện trong mỗi toán hạng được bảo toàn Minh hoạ của phân đoạn par trong hình 2.3, thứ tự thực hiện việc gửi thông điệp searchGoogle() (1a) phải trước readResult() (2), searchBing() (1b) phải trước readResult() (3), searchYahoo() (1c) phải trước readResult() (4) còn thứ tự thực hiện giữa các toán hạng khác nhau có thể đan xen (1a – 1b – 2 hoặc 1b – 1a – 3)

opt

[No error]

post_coment()

Hình 2.4 Phân đoạn Opt

Phân đoạn lựa chọn không đầy đủ (Option): Phân đoạn opt chỉ ra rằng phân đoạn

kết hợp biểu diễn một sự lựa chọn hành vi Trong phân đoạn chỉ có một toán hạng, toán hạng này có thể được thực thi hoặc không được thực thi tùy vào điều kiện Toán

tử opt gần giống với toán tử alt, chỉ có điều trong opt chỉ có một toán hạng duy nhất Minh họa của phân đoạn opt trong hình 2.4 nếu điều kiện No error thỏa mãn thì thông điệp post_comment() được gửi đi

Trang 16

Phân đoạn ngắt (Break): Phân đoạn break chỉ ra rằng khi điều kiện của toán tử

tương tác break đúng thì toán hạng trong phân đoạn kết hợp break sẽ được thực thi thay cho phần còn lại của phân đoạn tương tác (Interaction Fragment) bao gói bên ngoài Phân đoạn break thường được dùng kết hợp với phân đoạn loop Minh họa của phân đoạn break trong hình 2.5 Vòng lặp loop gửi thông điệp add() 10 lần nếu gặp điều kiện y > 0 thỏa mãn sẽ gửi thông điệp save() và chấm dứt

Phân đoạn tuần tự yếu (Weak Sequencing): Phân đoạn Weak Sequencing chỉ ra

rằng phân đoạn kết hợp biểu diễn một trình tự yếu giữa các hành vi của các toán hạng Trình tự yếu được định nghĩa bởi tập các vết với các đặc tính như sau

seq

search_google()

search_yahoo() search_bing()

Hình 2.6 Phân đoạn Seq

- Thứ tự của các sự kiện (EventOccurences) trong mỗi một toán hạng được duy trì

- Các sự kiện trên các đối tượng khác nhau ở các toán hạng khác nhau có thể xảy

ra theo thứ tự bất kỳ

- Các sự kiện trên cùng đối tượng ở các toán hạng khác nhau được sắp thứ tự sao cho một sự kiện của toán hạng thứ nhất xảy ra trước sự kiện của toán hạng thứ hai

Hình 2.6 mô tả phân đoạn Seq tìm kiếm bằng Google song song với Bing và Yahoo, tuy nhiên phải tìm bằng Bing trước khi tìm bằng Yahoo

Phân đoạn tuần tự ngặt (Strict Sequencing): Phân đoạn Strict Sequencing chỉ ra

rằng phân đoạn kết hợp biểu diễn một trình tự ngặt giữa các hành vi của các toán hạng

Trang 17

Minh họa của phân đoạn strict trong hình 2.7 phải tìm kiếm bằng Google rồi tới Bing

và sau đó là Yahoo

strict

search_google()

search_yahoo() search_bing()

Hình 2.7 Phân đoạn Strict

ignore {get, set}

add()

remove()

Hình 2.8 Phân đoạn Ignore

Phân đoạn từ chối (Ignore): Phân đoạn Ignore chỉ ra rằng có một số kiểu thông

điệp không được hiển thị trong phân đoạn kết hợp này Các kiểu thông điệp này có thể

bị coi là vô nghĩa và bị mặc nhiên bỏ qua Minh họa của phân đoạn ignore trong hình 2.8 Thông điệp get và set sẽ không được hiển thị trong phân đoạn này

Phân đoạn lưu ý (Consider): Phân đoạn consider chỉ ra rằng những thông điệp

nên được lưu ý trong phân đoạn kết hợp này Điều này tương đương với việc định nghĩa mọi thông điệp khác là bị bỏ qua Minh họa của phân đoạn consider trong hình 2.9 Chỉ có thông điệp add và remove được xét tới trong phân đoạn, các thông điệp khác được định nghĩa sẽ bị bỏ qua

Trang 18

consider {add, remove}

call(101) call(101)

call(911)

call(911)

Hình 2.10 Phân đoạn Critical

Phân đoạn vùng then chốt (Critical Region): Phân đoạn Critical Region là phân

đoạn kết hợp biểu diễn một vùng then chốt (critical region) Một vùng then chốt nghĩa

là các vết trong vùng này không thể bị đan xen bởi các sự kiện (EventOccurence) khác (trên các đối tượng bị phủ bởi vùng này) Minh họa của phân đoạn critical trong hình 2.10 Thông điệp gọi 911 từ khi Operator nhận được và chuyển tiếp tới Emergency là không thể bị đan xen

Phân đoạn phủ đinh (Negative): Phân đoạn Negative chỉ ra rằng phân đoạn kết

hợp biểu diễn các vết (traces) được định nghĩa là không hợp lệ Minh họa của phân

Trang 19

đoạn negative trong hình 2.11 Khi cửa (Door) đang khóa (Lock) thì thông điệp mở cửa (Open) sẽ không hợp lệ cho tới khi lò nấu xong (phân đoạn loop Cooking)

Chef

Open Insert Food

Close Set time and Power

Start

Lock Open

neg

loop Cooking

[1, time]

Rotate Platter Generate

Unlock Open

Hình 2.12 Phân đoạn Assert

Phân đoạn khẳng định (Assertion): Phân đoạn assert chỉ ra rằng phân đoạn kết

hợp biểu diễn các vết hợp lệ Toán tử assert thường được sử dụng cùng với ignore hoặc consider Minh họa của phân đoạn assert trong hình 2.12: Khối assert chỉ chấp

Trang 20

nhận thông điệp q là hợp lệ, do đó nếu thông điệp w xảy ra thay cho q thì w không hợp

lệ

Khối đơn (single fragment) là biểu đồ tuần tự hoặc một đoạn của biểu đồ tuần tự

chỉ chứa nhiều nhất một hoặc không chứa phân đoạn nào Các thông điệp trong khối đơn có thể thuộc một phân đoạn hoặc không Ví dụ về khối đơn được mô tả như trong hình 2.13, khối chỉ chứa một phân đoạn Opt bao thông điệp b, c; thông điệp a, d vẫn thuộc khối đơn nhưng không nằm trong phân đoạn

Hình 2.13 Khối đơn gồm một phân đoạn opt

2.2 Phương pháp phân tích đối tượng của biểu đồ tuần tự thành các khối đơn

Vấn đề đầu tiên được xét đến để giải quyết bài toán phương pháp bóc tách các đối tượng của biểu đồ tuần tự thành các khối đơn Các khối đơn được sinh ra sẽ là đầu vào cho việc chuyển đổi sang ôtômat vào/ra được trình bày ở mục 2.3 Phương pháp

đề xuất yêu cầu thiết kế được biểu diễn bởi biểu đồ tuần tự của các thành phần dưới dạng xmi Một công cụ đã được luận văn phát triển để phân tích xmi đầu vào và tách thành các khối đơn của biểu đồ tuần tự Cấu trúc xmi đầu vào của thuật toán được quy định như sau

- Cặp thẻ bao ngoài cùng là <Sequence> và </Sequence>

Trang 21

- Cặp thẻ bao tiếp theo là <Object></Object> bao gồm id, name và trường type =

“Object”

- Tiếp theo là Event hoặc Fragment

- Event: Gồm trường id, type=”event“, name=“tên_message” và eventType=

“send” hay “receive”

- Fragment: Gồm trường id, type = „combined frament‟, operator (operator có các giá trị là alt, loop, par, v.v.)

- Operand: Bắt buộc phải nằm trong Fragment và ngay sau khai báo thẻ fragment, bao gồm id, type=“operator” (nếu là phân đoạn Consider hoặc Ignore thì operand nằm ngay sau khai báo <constraint value=“ “/>)

- Constraint: Gồm trường value, trường này chứa tên các message cách nhau bởi dấu cách, ví dụ: <constraint value=“get set”/> Thẻ này đặt giữa 2 thẻ fragment

và operand, được dùng để khai báo các message bị loại bỏ trong fragment Ignore hoặc các message cần giữ lại trong fragment Consider

- Event nằm trong sequence hoặc trong operand, không nằm trực tiếp trong fragment

Thuật toán 2.1 Phân tích biểu đồ tuần tự thành các khối đơn

Đầu vào: Biểu đồ tuần tự biểu diễn dưới dạng tệp xmi

Đầu ra: Danh sách các đối tượng của biểu đồ tuần tự được biểu diễn dưới dạng danh sách

các khối đơn

1 : create stack, singleFragmentStack

2 : create array sdObjectList, operandList, eventList and singleFragmentList

3 : For all element in xmi file do

4 : If meet open tag then

11: if stack is not null then

12: create new event with fragment id and add to eventList; belong to the Operand on the top of stack if stack is not null

13: create new singleFragment and push to singleFragmentStack

14: endif

15: create new fragment with singleFragment on top of singleFragmentStack and push to stack

Trang 22

21: create new event and add to eventList; belong to the Operand on the top of

stack if stack is not null

27: else if meet close tag then

28: if element is Operand then

34: add fragment to singleFragment on top of singleFragmentStack

35: if singleFragmentStack has more than 1 item then

41: add singleFragment to singleFragmentList

42: add singleFragmentList to object

43: add object to sdObjectList

đối tượng stack, singleFragmentStack (dòng 1) và các danh sách sdObjectList,

operandList, eventList và singleFragmentList (dòng 2) Sau đó lần lượt đọc các element từ tệp xmi đầu vào Nếu gặp element là thẻ mở, thuật toán kiểm tra xem đó là

thẻ nào và tạo dữ liệu cho phù hợp Có 5 loại thẻ có thể gặp là Object (dòng 6),

Fragment (dòng 10), Operand (dòng 17), Event (dòng 20) và Constraint (dòng 23)

Ứng với thẻ Object, thuật toán tạo đối tượng singleFragment và đẩy vào

singleFragmentStack (dòng 8) đồng thời tạo đối tượng object (dòng 7) Nếu gặp thẻ

mở Fragment, stack sẽ được kiểm tra xem có phần tử hay không (dòng 11) Nếu có,

Trang 23

thuật toán tạo một event giả với id giống như của fragment, thuộc operand ở đỉnh stack

và đưa vào eventList (dòng 12), đồng thời tạo đối tượng singleFragment và đẩy vào

singleFragmentStack (dòng 13) Sau đó, thuật toán khởi tạo một fragment thuộc singleFragment ở đỉnh singleFragmentStack và đưa vào stack (dòng 15) Nếu gặp thẻ

mở Operand, thuật toán khởi tạo đối tượng operand và đưa vào stack (dòng 18) Nếu gặp thẻ mở Event, thuật toán tạo đối tượng event và đưa vào eventList, event này sẽ thuộc operand trên đỉnh stack nếu stack không rỗng, hoặc không thuộc operand nào nếu ngược lại (dòng 21) Nếu gặp thẻ mở Constraint, thuật toán tạo constraint cho

fragment đầu tiên trên đỉnh stack (dòng 23) Trong trường hợp gặp thẻ đóng, thuật

toán sẽ kiểm tra thẻ đóng đó là gì để xử lý Có 3 trường hợp thẻ đóng có thể gặp là

Operand, Fragment và Object Trường hợp gặp thẻ đóng Operand, opeand được đưa

khỏi đỉnh stack, đánh dấu thuộc fragment ở trên đỉnh stack lúc này và đưa vào

opeandList (dòng 29, 30, 31) Trường hợp gặp thẻ đóng Fragment, fragment được lấy

ra khỏi đỉnh stack và được đưa vào singleFragment ở đỉnh singleFragmentStack (dòng 33, 34) Sau đó, singleFragmentStack được kiểm tra xem có nhiều hơn 1 phần

tử hay không (dòng 35) Nếu đúng, singleFragment được lấy ra khỏi

singleFragmentStack và đưa vào singleFragmentList (dòng 36, 37) Trường hợp gặp

thẻ đóng Object, singleFragment được lấy ra khỏi singleFragmentStack và đưa vào

singleFragmentList (dòng 40, 41), sau đó singleFragmentList được đưa vào object và object được đưa vào objectList (dòng 42, 43) Sau khi kết thúc đọc tệp xmi, ta được objectList tương ứng với các đối tượng của Biểu đồ tuần tự ban đầu Mỗi phần tử trong objectList là một danh sách các singleFragment tương ứng được bóc tách từ đối tượng

Trang 24

Đầu vào của thuật toán là các khối đơn của biểu đồ tuần tự được mô tả bằng một

bộ sáu SD = (E, FG, OP, C, num, frag), trong đó:

- δ = Q x (C x E) → Q là tập các luật chuyển δ(qi, < c,e >) = qj,

- q0 là trạng thái khởi đầu, và

- F = {f1, f2, , fm} là tập các trạng thái kết thúc

Ôtômat vào/ra đầu ra được xây dựng bởi các quy tắc như sau[5]

- Số lượng các trạng thái trong ôtômat chính bằng số lượng sự kiện trong SD

|Q| = |E| và Q = {q0, q1, …, qn}

- Tập các điều kiện của ôtômat tương ứng là tập điều kiện của SD: C = {c| c ∈ C}

- Tập các sự kiện của ôtômat tương ứng là tập sự kiện của SD: E = {e| e ∈ E}

- Tập các kí tự vào của ôtômat được xác định bởi công thức

Trang 25

2.3.1 Trường hợp khối đơn không chứa phân đoạn nào

Trường hợp đầu tiên được xét đến là khối đơn của biểu đồ tuần tự không chứa một phân đoạn nào [5] Sau khi có E = {e| e ∈ E} và C = {c| c ∈ C}, tập các trạng thái kết thúc F được xác định F = {qn} Tập các luật chuyển δ được xác định bởi thuật toán 2.2

Thuật toán 2.2: Thuật toán xác định tập các luật chuyển 𝛿 cho ôtômat vào/ra từ khối đơn

không chứa phân đoạn

1: For i from 0 to |E|-1 do

Hình 2.14 đưa ra ví dụ cho khối đơn không chứa phân đoạn nào và ôtômat được chuyển đổi cho đối tượng User

Hình 2.14 Khối đơn không chứa phân đoạn và ôtômát cho đối tượng User

2.3.2 Trường hợp khối đơn chứa một phân đoạn Option

Trường hợp thứ hai là khối đơn của biểu đồ tuần tự chứa duy nhất một phân đoạn Option [5] Sau khi có E = {e| e ∈ E} và C = {c| c ∈ C}, tập các trạng thái kết thúc F

Trang 26

được xác định bởi quy tắc F = {qn} ∪ {qi | ei ∉ FG and ei+1 ∈ FG and en ∈ FG} Tập các luật chuyển δ được xác định bởi thuật toán 2.3

Thuật toán 2.3: Thuật toán xác định tập các luật chuyển 𝛿 cho ôtômat vào/ra từ khối đơn chỉ

chứa phân đoạn Option

1 : For i from 0 to |E|-1 do

event đầu tiên của phân đoạn, cụ thể j = i+1 và event ej thuộc FG đồng thời event ej-1 không thuộc FG (dòng 7) ta có δ𝒊𝒋 = <c,e j > Trường hợp 3, nếu điều kiện của FG

không thỏa mãn dẫn tới FG không được thực thi hay j = i+|FG|+1 và event ej không

thuộc FG đồng thời event ej-1 thuộc FG (dòng 10) ta có δ𝒊𝒋 = <e j > Sau vòng lặp với i,

ta được δ là biểu diễn của tập các quy tắc chuyển trạng thái trong ôtômat vào/ra

Hình 2.15 Khối đơn chỉ chứa một phân đoạn Option và ôtômat cho đối tượng User

Trang 27

Hình 2.15 đưa ra ví dụ cho khối đơn chỉ chứa một phân đoạn Option và ôtômat được chuyển đổi của đối tượng User

2.3.3 Trường hợp khối đơn chứa một phân đoạn Alternative

Trường hợp thứ ba là khối đơn của biểu đồ tuần tự chứa duy nhất một phân đoạn Alternative [5] Sau khi có E = {e| e ∈ E} và C = {c| c ∈ C}, tập các trạng thái kết thúc

F được xác định bởi công thức F = {qn} ∪ {qi | ei ∈ opk-1 and ei+1 ∈ opk and en ∈ FG} Tập các luật chuyển 𝛿 được xác định bởi thuật toán 2.4

Thuật toán 2.4: Thuật toán xác định tập các luật chuyển 𝛿 cho ôtômat vào/ra từ khối đơn chỉ

chứa phân đoạn Alternative

1 : For i from 0 to |E|-1 do

FG (dòng 3) thì ta có quy tắc chuyển trạng thái giữa qi và qj hay δ𝒊𝒋 =<e j > (dòng 4)

Trường hợp 2, nếu event ei thuộc Operand opk-1 và event ei+1 thuộc Operand opk (dòng

6), ta gán t = i+|op k |+…+|op m |+1 thì quy tắc chuyển trạng thái giữa qi và qt là δ𝒊𝒕=

Trang 28

<e t > (dòng 8) Trường hợp 3 nếu event ei không thuộc FG và event ei+1 thuộc FG (dòng 10) Thuật toán xét với mọi k từ 1,tới m, với mỗi trường hợp của k sẽ tồn tại quy tắc chuyển trạng thái δ𝒊𝒕= <c k , e t > (dòng 12, 16) với t = i+|op 1 |+…+|op k-1 |+1 (dòng

15) Sau vòng lặp với i, ta được δ là biểu diễn của tập các quy tắc chuyển trạng thái trong ôtômat vào/ra

Hình 2.16 Khối đơn chỉ chứa một phân đoạn Alternative và ôtômat cho đối tượng

User Hình 2.16 đưa ra ví dụ cho khối đơn chỉ chứa một phân đoạn Alternative và ôtômat được chuyển đổi của đối tượng User

2.3.4 Trường hợp khối đơn chứa một phân đoạn Loop

Trường hợp thứ tư là khối đơn của biểu đồ tuần tự chứa duy nhất một phân đoạn

Loop [5] Sau khi có E = {e| e ∈ E} và C = {c| c ∈ C}, tập các trạng thái kết thúc F

được xác định bởi công thức F = {qn} ∪ {qi | ei ∉ FG and ei+1 ∈ FG and en ∈ FG} Tập các luật chuyển 𝛿 được xác định bởi thuật toán 2.5

Thuật toán 2.5: Thuật toán xác định tập các luật chuyển 𝛿 cho ôtômat vào/ra từ khối đơn chỉ

chứa phân đoạn Loop

1 : For i from 0 to |E|-1 do

2 : set j=i+1

3 : If ej ∉ FG or ej-1 ∈ FG do

4 : set δ𝒊𝒋 =<e j >

5 : end if

Trang 29

(dòng 6) ta có quy tắc chuyển δ𝒊𝒋 = <c , e j > Trường hợp 3, vòng loop được thỏa mãn

điều kiện lặp sau ít nhất 1 lần chạy hay j = i-|FG|+1và event ej thuộc FG đồng thời

event ej-1 không thuộc FG (dòng 10) ta có quy tắc chuyển δ𝒊𝒋= <c , e j > Trường hợp 4,

vòng lặp không được chạy hay j= i+|FG|+1 và event ej không thuộc FG đồng thời

event ej-1 thuộc FG (dòng 14) ta có quy tắc chuyển δ𝒊𝒋 = <e j > Sau vòng lặp với i, ta

được δ là biểu diễn của tập các quy tắc chuyển trạng thái trong ôtômat vào/ra của khối đơn chỉ chứa một phân đoạn Loop

Hình 2.17 Khối đơn chỉ chứa một phân đoạn Loop và ôtômat cho đối tượng User

Trang 30

Hình 2.17 đưa ra ví dụ cho khối đơn chỉ chứa một phân đoạn Loop và ôtômat được chuyển đổi của đối tượng User

2.3.5 Trường hợp khối đơn chứa một phân đoạn Break

Trường hợp thứ năm là khối đơn của biểu đồ tuần tự chứa duy nhất một phân đoạn Break [5] Sau khi có E = {e| e ∈ E} và C = {c| c ∈ C}, tập các trạng thái kết thúc

F được xác định bởi công thức

F = {qn} ∪ {qi | (ei ∉ FG and ei+1 ∈ FG and en ∈ FG) or (ei ∈ FG and ei+1 ∉ FG)} Tập các luật chuyển δ được xác định bởi thuật toán 2.6

Thuật toán 2.6: Thuật toán xác định tập các luật chuyển 𝛿 cho ôtômat vào/ra từ khối đơn chỉ

chứa phân đoạn Break

1 : For i from 0 to |E|-1 do

FG hay j = i+1 và event ej thuộc FG đồng thời event ej-1 không thuộc FG (dòng 6) ta

có quy tắc chuyển δ𝒊𝒋=<c , e j > (dòng 7) Trường hợp 3, phân đoạn Break không được

chạy hay j s= i+|FG|+1; j ≤ n và event ej không thuộc FG đồng thời event ej-1 thuộc

FG (dòng 10) ta có quy tắc chuyển δ𝒊𝒋= <e j > (dòng 11) Sau vòng lặp với i, ta được δ

Ngày đăng: 06/04/2016, 16:44

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[1] Đỗ Đức Giáo (2011), Toán rời rạc ứng dụng trong tin học, Nhà xuất bản giáo dục Việt Nam.Tiếng Anh Sách, tạp chí
Tiêu đề: Toán rời rạc ứng dụng trong tin học
Tác giả: Đỗ Đức Giáo
Nhà XB: Nhà xuất bản giáo dục Việt Nam. Tiếng Anh
Năm: 2011
[2] Clarke, E. M.; Grumberg, O. &amp; Peled, D. A. (2000), Model checking, MIT, Cambridge, Mass Sách, tạp chí
Tiêu đề: Model checking
Tác giả: Clarke, E. M.; Grumberg, O. &amp; Peled, D. A
Năm: 2000
[3] H. M. Duong, L. K. Trinh, and P. N. Hung (2013), “An Assume-Guarantee Model Checker for Component-Based Systems”, The 10 th IEEE-RIVF International Conference on Computing and Communication Technologies Sách, tạp chí
Tiêu đề: An Assume-Guarantee Model Checker for Component-Based Systems”, "The 10"th
Tác giả: H. M. Duong, L. K. Trinh, and P. N. Hung
Năm: 2013
[4] L. B. Cuong and P. N. Hung (2012), “A Method for Generating Models of Black- box Components”, 4 th International Conference on Knowledge and Systems Engineering (KSE 2012), IEEE Computer Society Press, pp. 177-222 Sách, tạp chí
Tiêu đề: A Method for Generating Models of Black-box Components”, "4"th" International Conference on Knowledge and Systems Engineering (KSE 2012)
Tác giả: L. B. Cuong and P. N. Hung
Năm: 2012
[5] Zhang, C. &amp; Duan, Z. (2011), Specification and Verification of UML2.0 Sequence Diagrams Using Event Deterministic Finite Automata., in 'SSIRI (Companion)', IEEE Computer Society, , pp. 41-46 Sách, tạp chí
Tiêu đề: in 'SSIRI (Companion)', IEEE Computer Society
Tác giả: Zhang, C. &amp; Duan, Z
Năm: 2011
[6] J. Magee and J. Kramer ( 1990 ), „Concurrency: State Models and Java Programs‟, John Wiley and Sons Sách, tạp chí
Tiêu đề: Concurrency: State Models and Java Programs
[7] P. N. Hung, N. V. Ha, T. Aoki and T. Katayama (2012), “On Optimization of Minimized Assumption Generation Method for Component-based Software Verification”, IEICE Trans. on Fundamentals, Special Issue on Software Reliability Engineering, Vol. E95-A, No.9, pp. 1451-1460 Sách, tạp chí
Tiêu đề: On Optimization of Minimized Assumption Generation Method for Component-based Software Verification”, "IEICE Trans. on Fundamentals, Special Issue on Software Reliability Engineering
Tác giả: P. N. Hung, N. V. Ha, T. Aoki and T. Katayama
Năm: 2012
[8] Lynch, N. A. &amp; Tuttle, M. R. (1989), 'An introduction to input/output automata', CWI Quarterly 2, 219--246 Sách, tạp chí
Tiêu đề: CWI Quarterly
Tác giả: Lynch, N. A. &amp; Tuttle, M. R
Năm: 1989
[9] D. Lorenzoli, L. Mariani and M. Pezz` e (2008), “Automatic generation of software behavioral models”, ACM, Proceedings of the 30th international conference on Software engineering, pp. 501-510 Sách, tạp chí
Tiêu đề: Automatic generation of software behavioral models”, "ACM
Tác giả: D. Lorenzoli, L. Mariani and M. Pezz` e
Năm: 2008
[10] J.C. Corbett, M.B. Dwyer, J. Hatcliff, S. Laubach, C.S. Pasareanu, Robby and Hongjun Zheng (2000), ”Bandera: extracting finite-state models from Java Khác

HÌNH ẢNH LIÊN QUAN

Hình 2.3. Phân đoạn Par và ví dụ thứ tự thực hiện - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.3. Phân đoạn Par và ví dụ thứ tự thực hiện (Trang 14)
Hình 2.5. Phân đoạn Break - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.5. Phân đoạn Break (Trang 15)
Hình 2.6. Phân đoạn Seq - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.6. Phân đoạn Seq (Trang 16)
Hình 2.10. Phân đoạn Critical - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.10. Phân đoạn Critical (Trang 18)
Hình 2.11. Phân đoạn Neg - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.11. Phân đoạn Neg (Trang 19)
Hình 2.13. Khối đơn gồm một phân đoạn opt - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.13. Khối đơn gồm một phân đoạn opt (Trang 20)
Hình 2.16. Khối đơn chỉ chứa một phân đoạn Alternative và ôtômat cho đối tượng - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.16. Khối đơn chỉ chứa một phân đoạn Alternative và ôtômat cho đối tượng (Trang 28)
Hình 2.19. Khối đơn chỉ chứa một phân đoạn Paraller và ôtômat cho đối tượng Admin - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.19. Khối đơn chỉ chứa một phân đoạn Paraller và ôtômat cho đối tượng Admin (Trang 32)
Hình 2.22. Khối đơn chỉ chứa một phân đoạn Ignore và ôtômat cho đối tượng User - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 2.22. Khối đơn chỉ chứa một phân đoạn Ignore và ôtômat cho đối tượng User (Trang 37)
Hình 4.1.2. Biểu đồ lớp của công cụ - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 4.1.2. Biểu đồ lớp của công cụ (Trang 42)
Hình 4.2.1. Biểu đồ tuần tự xử lý đặt chỗ - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 4.2.1. Biểu đồ tuần tự xử lý đặt chỗ (Trang 45)
Hình 4.2.2. Đầu ra mong muốn cho đối tượng Oder - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 4.2.2. Đầu ra mong muốn cho đối tượng Oder (Trang 47)
Hình 4.2.5. Biểu đồ tuần tự máy thanh toán ở siêu thị - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 4.2.5. Biểu đồ tuần tự máy thanh toán ở siêu thị (Trang 49)
Hình 4.2.7. Đầu ra mong muốn cho đối tượng Cashier - Phương pháp kiểm chứng tính đúng đắn của các biểu đồ tuần tự UML 2 0
Hình 4.2.7. Đầu ra mong muốn cho đối tượng Cashier (Trang 52)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm