Tài liệu 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à và