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

ĐẠ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


i

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


ii

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


iii

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.


iv

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


v

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.

3

FG

Fragment

Phân đoạn

4

SD

Sequence Diagram

Biểu đồ tuần tự

5

OP

Interaction Operand

Toán hạng tương tác


vi

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


vii

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


viii

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


1

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


2
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.


3

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).


4
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.
loop(5, 10)
[size <0]

notify()

Hình 2.1. Phân đoạn Loop
alt
[balance >0]

accept()

[else]

reject()

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


5
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
1a: searchGoogle()
2: readResult()

1b: searchBing()
3: readResult()

1c: searchYahoo()
4: readResult()

Operand1

1a

2

1b

Operand2

3
1c

Operand3

Operand1

Operand2

Operand3

4

1a
1b

2
3
1c

4

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


6
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.
loop(10)
add()

break

[y>0]
save()

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


7
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_bing()

search_yahoo()

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.


8
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_bing()

search_yahoo()

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.


9
consider {add, remove}

add()

remove()

Hình 2.9. Phân đoạn Consider
sd CriticalRegion

:Emergency

:Operator

par

:Caller

:Callee

call(100)
call(100)

call(101)

call(101)

Critical

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


10
đ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).
ControlPanel

Microwaye

MicrowayGenerator

Door

Chef
Open
Insert Food
Close
Set time and Power
Start

Lock
neg

Open
loop Cooking

Rotate Platter

[1, time]

Generate

Finish

Unlock
Open
Remove Food

Hình 2.11. Phân đoạn Neg
consider{q ,v ,w}
1 : v()

assert
2 : q()

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


11
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>


12
-

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
5 :
Switch element
6 :
case Object:
7 :
create object
8 :
create singleFragment, push to singleFragmentStack
9 :
break
10:
case Fragment:
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

13
16:
break
17:
case Operand:
18:
create new operand and push to stack
19:
break
20:
case Event:
21:
create new event and add to eventList; belong to the Operand on the top of
stack if stack is not null
22:
break
23:
case Constraint:
24:
create new constraint and add to the fragment on the top of stack
25:
break
26:
end switch
27: else if meet close tag then
28:
if element is Operand then
29:

op = stack.pop()
30:
set op ∈ the Fragment on the top of stack
31:
insert op to operandList
32:
else if element is Fragment then
33:
fragment = stack.pop()
34:
add fragment to singleFragment on top of singleFragmentStack
35:
if singleFragmentStack has more than 1 item then
36:
singleFragment = singleFragmentStack.pop;
37:
add singleFragment to singleFragmentList
38:
end if
39:
else if element is Object then
40:
singleFragment = singleFragmentStack.pop;
41:
add singleFragment to singleFragmentList
42:
add singleFragmentList to object
43:
add object to sdObjectList
44:

end if
45: end if
46: end for

Thuật toán 2.1 mô tả quá trình phân tích tệp xmi đầu vào biểu diễn của biểu đồ
tuần tự thành các đối tượng bao gồm các khối đơn. Trước tiên, thuật toán khởi tạo các
đố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ó,


14
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
đó.

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ự
Vấn đề tiếp theo được xét đến là phương pháp sinh ôtômat vào/ra từ các khối đơn,
khối chỉ chứa nhiều nhất một phân đoạn của biểu đồ tuần tự [5]. Luận văn nghiên cứu
xây dựng thuật toán chuyển đổi sang ôtômat vào/ra từ các khối đơn chứa một trong
chín loại phân đoạn sau: Option, Alternative, Loop, Break, Parallel, Strict, Critical,
Consider, Ignore và trường hợp khối không chứa bất kì phân đoạn nào.


15
Đầ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 đó:
-

E là tập các sự kiện E = EI ∪ EO,

-

EI là tập các sự kiện nhận,

-

EO là tập các sự kiện gửi,

-

FG là tập các phân đoạn, trường hợp khối đơn, FG chứa nhiều nhất 1 phần tử,

-

OP là tập các Operand,

-

C là tập các điều kiện C = {c1, c2, c3.. ck},

-

num là danh sách các số thứ tự của event từ 0 đến n, và

-

frag là một hàm chuyển từ E đến F.
Đầu ra của thuật toán là một ôtômat vào/ra tương ứng được mô tả bằng một bộ

sáu O = (Q, ∑𝐼 , ∑𝑂 , 𝛿, q0, F), trong đó:
-

Q = {q0, q1, q2, .., qn} là tập các trạng thái,

-

∑𝐼 = {(c, e)| 𝑐 ∈ 𝐶, 𝑒 ∈ EI } là tập các kí tự vào,

-

∑𝑂 = {(c, e)| 𝑐 ∈ 𝐶, 𝑒 ∈ EO } là tập các kí tự ra,

-

δ = 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
∑𝐼 = {(c, e)| c ∈ C, e ∈ EI}

-

Tập các kí tự ra của ôtômat được xác định bởi công thức
∑𝑂 = {(c, e)| c ∈ C, e ∈ EO}

-

Tập các luật chuyển δ và tập các kí tự kết thúc F được xác định bởi 10 trường
hợp được mô tả từ mục 2.3.1 tới 2.3.10.


16

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
2: set j= i+1
𝒋
3: set δ𝒊 = <ej>
4: end for

Chi tiết của thuật toán 2.2 như sau. Tập các quy tắc chuyển trạng thái của ôtômat
vào/ra sẽ được sinh ra bằng cách thêm lần lượt với mỗi i từ 0 đến |E|-1 (dòng 1) các
𝒋

quy tắc chuyển trạng thái δ𝒊 = <ej> với j= i+1 (dòng 2, 3).
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