ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ ===========oOo========== HOÀNG PHƢƠNG THỨC ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA HỆ THỐNG TƯƠNG TRANH LUẬN VĂN THẠC SĨ Hà nội 2011 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ ===========oOo========== HOÀNG PHƢƠNG THỨC ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA HỆ THỐNG TƢƠNG TRANH Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 604810 LUẬN VĂN THẠC SĨ NGƢỜI HƢỚNG DẪN KHOA HỌC: TS. Phạm Ngọc Hùng Hà nội 2011 LỜI CẢM ƠN Trước tiên tôi xin bày tỏ lòng biết ơn sâu sắc tới TS. Phạm Ngọc Hùng, giảng viên Bộ môn Công nghệ phần mềm Khoa Công nghệ thông tin Trường Đại học Công nghệ ĐHQGHN. Trong thời gian học và làm luận văn tốt nghiệp, thầy đã dành nhiều thời gian quý báu và tận tình chỉ bảo, hướng dẫn tôi trong việc nghiên cứu, thực hiện luận văn. Tôi xin được cảm ơn các GS, TS đã giảng dạy tôi trong quá trình học tập và làm luận văn. Các thầy cô đã giúp tôi hiểu thấu đáo hơn lĩnh vực mà mình nghiên cứu để có thể vận dụng những kiến thức đó vào trong công tác của mình. Trân trọng cảm ơn đề tài mã số CN.10.03 đã trợ giúp tôi trong quá trình thực hiện luận văn này. Xin cảm ơn bạn bè, đồng nghiệp và nhất là các thành viên trong gia đình đã tạo mọi điều kiện tốt nhất, động viên, cổ vũ tôi trong suốt quá trình học tập và nghiên cứu để hoàn thành tốt bản luận văn tốt nghiệp này. Hà nội, tháng 6 năm 2011 Học viên thực hiện Hoàng Phƣơng Thức
Trang 1TRUONG DAI HOC CONG NGHE
Lê Hồng Phong
DAC TA VA KIEM CHUNG CAC PHAN MEM TUONG TRANH
KHOA LUAN TOT NGHIEP DAI HOC HE CHINH QUY
Nganh: Cong nghé thong tin
Trang 2TRUONG DAI HOC CONG NGHE
Lé Hong Phong
DAC TA VA KIEM CHUNG CAC PHAN MEM TUONG TRANH
KHOA LUAN TOT NGHIEP DAI HOC HE CHINH QUY
Nganh: Cong nghé thong tin
Cán bộ hướng dan: Ts Pham Ngoc Hing Cán bộ đồng hướng dẫn: Ths Đặng Việt Dũng
Trang 3LỜI CẢM ƠN
Lời đầu tiên em xin bày tỏ lòng biết ơn sâu sắc đến thầy Phạm Ngọc Hùng và thay Đặng Việt Dũng đã tận tình hướng dan, chi bao em trong quá trình thực hiện đề tài
Em xin chân thành cảm ơn các thầy cô giáo trong Khoa Công nghệ Thông tin, trường Đại học Công Nghệ, Đại học Quốc Gia Hà Nội đã tận tình giảng dạy, trang bị cho em những kiến thức quý báu trong suốt thời gian qua
Con xin chân thành cảm ơn ông bà, cha mẹ đã luôn động viên, ủng hộ con trong suốt thời gian học tập và thực hiện khóa luận tốt nghiệp
Tôi xin cảm ơn sự quan tâm, giúp đỡ và ủng hộ của anh chị em, bạn bè trong quá trình thực hiện khóa luận
Mặc dù đã cố gắng hoàn thành khóa luận trong phạm vi và khả năng cho phép nhưng chắc chắn sẽ không tránh khỏi những thiếu sót Em rất mong nhận được sự
thông cảm, góp ý và tận tình chỉ bảo của quý thầy cô và các bạn
Hà Nội, ngày 15 tháng 5 năm 2010 Sinh viên thực hiện
Trang 4
TÓM TẮT
Phần mềm tương tranh, một phần mềm được ứng dụng rộng rãi trong các hệ thống nhúng và các hệ thống điều khiển Chúng có vai trò vô cùng quan trọng trong việc điều khiến các hệ thống đó Chỉ cần một lỗi nhỏ của phần mềm có thê gây ra hậu quả vô cùng nghiêm trọng vì những hệ thống này có thê trực tiếp và gián tiếp ảnh hưởng đến cuộc sống của con người Chính vì vậy phần mềm tương tranh phải được
kiểm chứng để giảm thiểu tối đa lỗi của chương trình Vì những lý do đó, đề tài “Đặc
tá và kiêm chứng các phần mềm tương tranh” đề cập tới phương pháp hình thức, các ly thuyết về máy hữu hạn trạng thái (Finite State Process, FSP) và sử dụng máy hữu hạn
trạng thái để đặc tả thiết kế và mã nguồn của phần mềm tương tranh Từ đó sử dụng
công cụ phân tích máy hữu hạn trạng thái để kiểm chứng xem thiết kế và mã nguồn của phân mêm có lỗi và chạy đúng theo yêu câu không
Do thời gian có hạn nên phần thực nghiệm trong khóa luận này em chỉ thực hiện kiêm chứng một applet được viết băng Java Thiết kế của bài toàn đã được đặc tả sẵn bằng FSP Nhiệm vụ của em là kiếm chứng xem thiết kế đó có lỗi xác hay không và chuyên mã nguồn Java của applet thành FSP để kiểm chứng xem mã nguồn có chạy
Trang 5MỤC LỤC
Chương ]: Giới thiỆU c1 10 ng ng 1
1.1 Nhu cau thu té va ly do thie hién dé tai occ cs ceseesscsesesesesssesesesees 1
1.2 Mục tiêu của để tài 2c 2 tt 2
1.3 (000i vì /.84(0 80) i00 rrcđiiẢ ố 3 Chương 2: Các khái niệm cơ bản c ng ng ng ng ng hen 4 2.1 Phương pháp mô hình hóa - S1 1111110111310 1 803 1 vn khen 4
s„Ÿ⁄» á .ố.ố “3 5
2.2.1 Khái niệm ESP LH HH ng ng ng nh 5
2.2.2 Các thành phần cơ bản trong ESP ¿cv St tEvEErkrkrrrrrrxrrrerree 6
2.2.3 Quy trình tuần tựy 1k t TT TS 1115111111111 T11 rkrkrkrkeo 9 ZZ LTS + Lẻ ¬ ẮằẮH(.(:((:(::ƠƠ1OOỌỌ 11 “508 11 2.3.2 DeadlOCĂK - cv 9n ngọn ng nh 13 2.3.2.1 Khái nIỆm - - c0 nọ nh và 13 2.3.2.2 Phân tích Deadlock cv ng ng vàn 14 2.3.3 Thuộc tính An tồđ -.- - so c n3 ng vn ch nh key 14 2.3.4 Thuộc tính LLIV€R€SS + ng nh ve 15 2.4 CONG vu 0006/00 h6 15 2.5 KẾt luận tt tt tr 1111111111111 16 Chương 3: Kiém chirng thiét k6 oo ccecccssesscseseecscescscssssescsesvsssssscsessessssevevsessssnscsvens 17 3.1 Đặc tả thiết kế bằng FSP LH TT ST TT TT TT nàn Họ 17 3.3 Kiểm chứng thiết kế bằng L/TSA + - E1 S*StSESEEEEEExEx SE vevrrrkra 23
Trang 6
4.1 Phương pháp để kiểm chứng cài đặt - c5 n2 St SxteErkrrrerrrrrrrrre 3]
4.2 Cách chuyên từ mã nguồn Java sang ESP - s1 xEErrrkrkei 3l 4.3 Ứng dụng để chuyển mã nguồn bài toán “SingleLandBridge” -. - 34
4.5 Kiểm chứng cài đặt - - + cà ST TvE 111111 71111111111 1111111111 ke 36
4.6 Kết luận + ch nành HH 41
Chương 5: Kết luận ¿k6 3S E13 3E E313 E113 E31 TT nếu 42 Tài liệu tham khảo - + + c1 SE 9 ng ng Ki B288 43
Trang 7Danh mục các hình vẽ
Hình 2.1: Nghiên cứu khí động học trên mô hình ơ ẦƠ cv vvvevee 4 Hình 2.2.l1a: Mô hình hóa hành trình bay của máy ĐđV ccc ccc ssssxsvsvevrs 6 Hinh 2.2.2a: May trang thai DRINKS ccccccccceeecseeeececenseseeseseeseeseceesecessesseseeseesseeanags 7 Hình 2.2.2b: Máy trạng thái TQf€ on 133191990101 v kg v ng vn ng vyy ổ
Hình 2.3.1c: Tiến trình tuân tự BOMP + 5c ctsrerrrtrrerrrrrerrrrrrrrrrrrrrre 10
Hình 2.3 lả: Sự tổng hợp tuân tự LOOP 5 5 tt SE grưyi 10
Hình 2.3 le : Sự tổng hợp song song hai tiễn trình tuân fự sec cecsrcseerei 1]
I;01/).525WI.0/L()8.4.,J-0 0,00: nh 12
I;0/).52591.0L(/)8.4,.,;-0 0, 20060) 011 13 Hinh 2.3.2.la: Bita toi CU triet Cid cee ccececsesssesesesesssveveevsvsvevevecsevevsvsvevscsenensvevevacneseves 13
/;0 85255927/209 , 100nnẺn8n8 8e 14
Hình 2.4a: Mô hình hành động của chiếc ơ tƠ 5c SeStSEEEEEEEEEEEEEErrrrrsrrerrred 16 Hình 2.4b: LTSA animator điều khiển các hành động trong mô hình 2.4a 16 Hình 3.1: Mô tả các ô t6 di qua mOt chiéc COU NED voecececcccevecsssvsssvsvetsvsvsvsvevevsvsveneees 18 Hình 3.3.1]: Giao điện công Cụ L TY cọ ng TH TH ng ng ng ng vn v.v trà 23 Hình 3.3.2: Kết quả hiển thị sau khi check sqƒEfV St EcEeEerererrrrsrrerrred 24 Hình 3.3.3: Kết quả hiển thị khi check progress ccccccccccessevssesvsvsvsvsvevecsevevsvsvevscnseeves 25 Hình 3.3.4: Kết quả hiển thị khi biên dịch đoạn mã LT1S - 2S s cv S2 sec: 26 Hình 3.3.5: LTS Analiser SingleLaH©BYi(O€ - c cung ng ng ng ng vn v.v trà 27 Hình 3.3.6: Anừnator SingleLandlBTidÌ© TT TH tk vn ven 29 Hình 4.5a: Mở tệp SafeBridge bằng công cụ LT/SA ác sEerererrrersrerrred 37
Trang 8
Hình 4.5b: Check saƒfety phương thức F€@lFZXỈÍ Gv v.v ven 38 Hình 4.5c: Check prgress phương thức F€d[FXỈf Gv ng v.v rà 39 Hinh 4.5d: May trang thai RÑEDDEXÏ T Q0 vn HH 1n TH tk nh ren 40
Trang 9Danh mục các bảng biêu
Trang 11Chương 1: Giới thiệu
1.1 Nhu câu thực tế và lý do thực hiện đề tài
Ngày nay, cùng với sự phát triển mạnh mẽ của máy móc phục vụ đời sống con
người là sự phát triển âm thầm của các hệ thống tương tranh Chúng được tạo ra để điều khiển hoạt động của những máy móc đó Một hệ thống tương tranh có thể bao
gồm cả phần mềm và phần cứng nhưng cũng có thể chỉ có phần mềm Phần mềm tương tranh chính là linh hồn của hệ thống, giúp chúng hoạt động chính xác theo những gì mà con người yêu cầu Hiện nay, phần mềm tương tranh được ứng dụng tất nhiều trong các hệ thống nhúng và điều khiển Từ những vật dụng rất đơn giản trong
đời sống hàng ngày như nổi cơm điện, tỉ vi, đến những hệ thống điều khiển phức tạp
như hệ thống điều khiển tên lửa đều có một hoặc nhiều phần mềm tương tranh điều
khiển
Những vật dụng, hệ thống điều khiển này gan bo chat ché voi chung ta, chi can một lỗi nhỏ của phần mềm tương tranh cũng có thể gây ra hậu quả nghiêm trọng Đã
có những con tàu vũ trụ vừa mới rời khỏi mặt đất thì đã rơi, tiêu tốn hàng tỷ đô la để
nghiên cứu, chế tạo nó Nguyên nhân gây ra tai nạn đó chính là do lỗi của hệ thống điêu khiên con tàu
Chính vì vậy, yêu cầu kiểm chứng an toàn cho các hệ thống tương tranh là hoàn toàn tất yếu Hiện nay, song song với quá trình sản xuất phần mềm luôn có một quá
trình kiểm thử (testing) phần mềm Tuy nhiên, kiểm thử là chưa đủ vì các phương pháp kiểm thử hiện tại chỉ là kiểm tra dữ liệu đầu ra của phần mềm tôi so sánh với đữ
liệu đầu vào để kiểm tra xem chương trình chạy có lỗi hay không Chúng không hề kiêm tra được chỉ tiết hoạt động của chương trình và khơng kiểm sốt được những lỗi tiềm ân ngay cả khi chương trình vẫn chạy đúng Nếu phần mềm phát hành ra mà vẫn còn chứa lỗi thì nhà sản xuất phải thu hồi sản phẩm để sửa chữa Điều này làm giảm uy tín và tiêu tôn nhiêu tiên của nhà sản xuât
Chúng ta hoàn toàn có thể khắc phục được những vấn đề trên bằng cách sử dụng
phương pháp hình thức để đặc tá và kiếm chứng những phần mềm đòi hỏi tính an toàn cao, nhất là các phần mêm tương tranh
Trang 12
Trước hết, phải đảm bảo có một thiết kế đúng, chính xác bằng cách đặc tả thiết
kế bằng FSP[1] và sử dụng công cụ LTSA[1][4] để kiếm chứng thiết kế đó Sau khi
thiết kế đã được kiểm tra và thâm định tính đúng đắn, chúng ta tiến hành cài đặt
chương trình
Sau khi đã xây dựng xong phần mềm, có một câu hỏi đặt ra là liệu cài đặt có đúng với thiết kế không? Chúng ta đã có công cụ để kiểm tra tính đúng đắn của thiết kế vì vậy giải pháp cho bài toán này chính là chuyển mã nguồn của cài đặt thành chính mô hình được đặc tả bằng FSP và sử dụng công cụ LTSA để kiểm chứng
Với cách tiếp cận này, ta có được một quy trình kiểm chứng đầy đủ hai chiều, có
tính hệ thông từ pha kiểm thử đến pha cài đặt
1.2 Mục tiêu của đề tài
Phương pháp hình thức là các kỹ thuật toán học được sử dụng để đặc tả, phát triển và kiểm chứng các hệ thống phần mềm và phần cứng Phương pháp tiếp cận này đặc biệt quan trọng đối với các hệ thống cần có tính toàn vẹn cao như hệ thống điều khiển lò phản ứng hạt nhân, điều khiển tên lửa, khi vẫn để an toàn hay an ninh có vai trò quan trọng, để góp phần đảm bảo rằng quá trình phát triển của hệ thống sẽ không
có lỗi Khi kiêm chứng bằng phương pháp hình thức, điều đặc biệt là chúng ta không
cần dữ liệu đầu vào mà chỉ cần kiểm tra các mô hình mô tả các hành động, trạng thái của hệ thống khi hoạt động
Như vậy, đề tài cần giải quyết các công việc chính sau:
“ Tìm hiểu về phương pháp mô hình hóa, máy hữu hạn trạng thái, máy dịch chuyển trạng thái có gán nhãn (Labelled Transition System, LTS) và công cụ hỗ trợ kiểm chứng LTSA (Labelled Transition System Analyzer)
= Str dung cong cụ hỗ trợ kiém chimg LTSA dé kiém chimg thiết kế của một hệ thống điều khiển được đặc tả bằng FSP
“_ Đặc tả mã nguồn Java của hệ thống điều khiển trên bằng FSP, sử dụng công cụ hỗ trợ kiêm chứng LTSA để kiểm tra xem chương trình có lỗi và
Trang 131.3 Nội dung của khóa luận
Nội dung của khóa luận gồm 5 chương:
Chương l trình bày nhu cầu thực tế, lý do thực hiện đề tài và mục tiêu cần đạt
được
Chương 2 giới thiệu những lý thuyết cơ bản về phương pháp mô hình hóa, máy
hữu hạn trạng thái, máy dịch chuyển trạng thái có gán nhãn và công cụ phân tích LTSA của nó để ứng dụng trong kiểm chứng
Chương 3 trình bày ứng dụng FSP và LTSA để kiêm chứng một thiết kế xem có
chính xác với yêu cầu bài tốn đặt ra khơng?
Chương 4 trình bày cách chuyển từ Java sang FSP để ứng dụng kiểm chứng một chương trình có thỏa mãn thiết kế hay không?
Trang 14Chương 2: Các khái niệm cơ bản
Trong chương này chúng ta sẽ tìm hiểu một số khái niệm về phương pháp mô hình hóa, máy hữu hạn trạng thái, máy dịch chuyên trạng thái có gán nhãn và công cụ
hỗ trợ kiểm chứng LTSA
2.1 Phương pháp mô hình hóa
Mô hình là một đại diện đơn giản hóa của thế giới thực Mô hình được sử dụng rộng tãi trong kỹ thuật, để tập trung vào một khía cạnh cụ thể của một hệ thống thế giới thực [1]
Ví dụ, các nhà khoa học muốn nghiên cứu tính động học của một chiếc ô tô Thay vì sử dụng một chiếc ô tô thật, nhà khoa học chỉ cần sử dụng mô hình của chiếc ô
tô đó với điều kiện mô hình phải có hình dáng bên ngoài giống hệt chiếc ô tô thật Khí
động học của ô tô chỉ bị ảnh hưởng do hình dáng bên ngoài của nó nên nghiên cứu trên mô hình hoàn toàn cho kết quả chính xác giống như nghiên cứu trên chiếc ô tô thật
Hình 2.I: Nghiên cứu khí động học trên mô hình ô tô
Như vậy phương pháp mô hình hóa có ưu điểm là tạo được môi trường gần giống
với thực tế từ đó cho kết quả kiểm tra tương đối chính xác
Trang 15không là phụ thuộc vào thiết kế có chính xác hay không? Chính vì vậy, lựa chọn phương pháp thiết kế phù hợp với đặc tính của phần mềm là hết sức quan trọng
Khi thiết kế một phần mềm tương tranh, chúng ta phải mô tả chỉ tiết được các hoạt động của phần mềm Thiết kế càng chỉ tiết thì phần mềm hoạt động càng chính xác Tuy nhiên, để có được một thiết kế chính xác như vậy rất khó Các phương pháp thiết kế hiện tại chỉ đáp ứng được yêu cầu tạo ra thiết kế theo yêu cầu của sản phẩm
Tuy nhiên chúng lại không giải quyết được vấn đề kiểm chứng các thiết kế đó Như
vậy, chúng ta sẽ không thể tìm ra những hạn chế của thiết kế Bài toán đó sẽ được giải
quyết băng việc khai thác ưu điểm nỗi bật của phương pháp mô hình hóa:
- Phương pháp mô hình hóa có thể tạo ra một thiết kế mô tả được chỉ tiết hoạt
động của hệ thống Ở đây chúng ta sẽ sử dụng mẫu FSP để đặc tả thiết kế đó
- Phân tích mẫu thiết kế thông qua việc sử dụng công cụ LTSA, chúng ta có thể kiểm tra được mẫu thiết kế được đặc tả bằng FSP có chạy đúng, chính xác hay không
Khi phần mềm đã được viết xong, với phương pháp hình thức, chúng ta có thể
mô hình hóa mã nguồn của phần mềm để kiểm chứng xem phần mềm có chạy đúng
theo thiết kế hay không Đây chính là ứng dụng ngược rất hay của phương pháp hình
thức
2.2 FSP (Finite State Process)
2.2.1 Khai niém FSP
Máy hữu hạn trạng thái (FSP) được tạo ra để mô tả các mô hình tiến trình FSP có thể mô tả được những hành động, trạng thái của tiến trình Ta lay mot vi du don giản mô tả các hành động cât cánh, bay, hạ cảnh của một chiếc máy bay:
cât cánh -> bay -> hạ cánh -> cât cánh -> bay -> hạ cánh ->
Ta có thê thấy nếu máy bay còn hoạt động được thì các hành động này sẽ liên tục xảy ra đến khi nào mà máy bay không được sử dụng nữa Chính vì vậy mô tả trên sẽ không thê nào đầy đủ được Tuy nhiên ta hoàn toàn có thể giải quyết vẫn đề đó nếu
Trang 16Maybay = (catcanh -> bay -> hacanh -> Maybay)
FSP có tính đệ quy nên ta có thể dễ dàng giải quyết bài tốn trên Ta có mơ hình
được phân tích từ mẫu FSP này:
catcanh bay
Maybay
hacanh
Hình 2.2.1a: Mô hình hóa hành trình bay của máy bay
Một phần mềm tương tranh bao gồm rất nhiều tiến trình, mỗi tiến trình là sự thực thi của một tiến trình tuần tự Một tiến trình được chia làm một hoặc nhiều hành động nguyên tử ( hành động nguyên tử không thể chia được thành các hành động nhỏ hơn), các hành động này được thực thi một cách tuần tự Mỗi hành động gây ra một sự chuyên tiếp từ trạng thái hiện tại sang trạng thái tiếp theo Trình tự các hành động xảy ra có thê được xác định bằng một đồ thị chuyển tiếp Nói cách khác, chúng ta có thê mô hình hóa các tiến trình thành các máy hữu hạn trạng thái [1]
Như vậy, chúng ta hoàn toàn có thể mô hình hóa chỉ tiết một phần mềm tương tranh với đặc tả là FSP
2.2.2 Các thành phan cơ bản trong FSP
Action prefix ((x -> P)): Nếu x là một hành động và P là một tiến trình thì một
Trang 17Trong đó: Maybay là một tiến trình
catcanh, bay, hacanh là các hành động
Lựa chọn (| Choice): Nếu x, y là các hành động thì (x -> Q | y -> P) mô tả một
tiến trình trong đó các hành động đầu tiên tham gia là x hoặc y Các hành động tiếp theo hoạt động theo mô tả của Q nếu hành động đầu tiên xảy ra là x, các hành động tiếp theo hoạt động theo mô tả của P nếu hành động đầu tiên xảy ra là y
Ví dụ mô tả việc lây nước uông ở máy đun nước [1 |, nêu ân nút đỏ thì được cà phê, nêu ân nút xanh thì được trà:
DRINKS = (red -> coffee -> DRINKS | blue -> tea -> DRINKS) Khi phân tích mẫu FSP trên ta đuợc mô hình: red blue DRINKS tea cottee
Hinh 2.2.2a: May trang thai DRINKS
Lập chỉ mục cho các quy trình và hành động (indexed process and actions)
Khi mô hình các tiến trình và hành động có có những trường hợp những tiến trình và
Trang 18
Gate = (in[1] -> out[1] -> Gate | in[2] -> out[2] -> Gate
| in[3] -> out[3] -> Gate)
Trong do [1], [2], [3] la chi muc cua cac hanh d6ng in va out Kết quả khi phân tích bằng công cu LTSA:
mị1]
Gate
nu†[I]
Hình 2.2.2b: May trang thai Gate
Tham số tiến trình (Process parameters): khi tiến trình và hành động có nhiều giá trị thì thay vì đánh chỉ mục thì chúng ta có thể tạo tham số để mô tả tiến trình bằng FSP được gọn hơn Ta lẫy ví dụ Gate ở trên: const N =3 Gate = ( in[i:1 N] -> out[i] -> Gate)
Trong đó i:1 N có nghĩa i có giá trị lần lượt từ 1 đến N
Trang 19người quá quy định thì phải ra bớt, ngược lại có thể thêm người vào vì còn nhiều
người đang chờ được vào:
Count(N=10) = Count[1 ],
Count[i:1 N] = (when(<N) enter -> Count[i+1] | when(>N) out -> Count[i-1])
Hành động duoc dam bao boi “when” dam bao cho thang máy hoạt động đúng công suất Khi số người quá quy định thì phải ra ngoài bớt, khi số người trong thang
chưa tới giới hạn thì có thê tiếp tục vào
Alphabet của tiến trình (Process Alphabet): Alphabet của một tiến trình là một tập hợp tất cá cách hành động mà nó có thể tham gia Ta lấy một ví dụ định nghĩa WRITE st dung write[1] va write[3]: WRITER = (write[1 ]->write[3 ]->WRITER) + {write[0 3]} Trong ví du nay thi Alphabet cua WRITE 1a write[0 3] 2.2.3 Quy trình tuần tự
Các tiễn trình trong FSP được chia làm 3 loại:
- Các tiến trình cục bộ (local process) được định nghĩa là một trạng thái trong
một tiến trình cơ bản [1]
- Tiến trình cơ bản (primitive process) được xác định bởi tập hợp các tiến trình cục bộ Một tiến trình cục bộ được xác định bằng cách sử dụng STOP, ERROR, tiền
hành động (Action preñx) và lựa chọn (|, choice) [1]
- Tiến trình tuần tự ( sequential process) là một tiến trình có thể kết thúc Một
tiến trình có thể kết thúc nếu một tiến trình cục bộ END có thể được với tới từ trạng
Trang 20
Tiến trình cục bộ END: Tiến trình cục bộ END biểu thị trạng thái mà tiến trình kết thúc thành công Một tiến trình đúng đắn khi không có hành động nào tiếp theo xảy ra sau END Về mặt ngữ nghĩa nó tương tự như STOP Tuy nhiên, STOP là một trạng
thái mà tiến trình tạm ngưng quá sớm, thường là do deadlock STOP được sử dụng khi
ta muốn kết thúc một tiến trình [1] Ví dụ sau mô tả tiến trình hẹn giờ một quá bom nô trong đó trạng thái E là trạng thái kết thúc:
BOMB tick tick bang
@ ˆ@)"@ `
BOMB = (tick -> tick -> bang -> END)
Hình 2.3.1c [1 : Tiến trình tuân tự BOMP
Sự tổng hợp các tiến trình tuần tự: Nếu Q là một tiến trình tuần tự, P là một
tiến trình cục bộ, sau đó P;Q biểu diễn cho sự tổng hợp tuần tự như vậy khi P kết thúc, P;Q sẽ trở thành tiến trình Q [1]
Nếu chúng ta định nghĩa tién trinh SKIP = END then P; SKIP = P and SKIP; P = P Một sự tông hợp tuần tự trong FSP luôn luôn có dang: SP1;SP2; ;SPn;LP [1]
Noi SP1; ;SPn la su tong hop tuần tự và LP là tiến trình cục bộ Một sự tong hop tuần tự có thể xuất hiện ở bất cứ chỗ nào trong định nghĩa của một tiến trình cơ bản mà một tiến trình cục bộ tham chiếu đến có thể xuất hiện [1]
Vi dy tién trinh P123 va LOOP:
Trang 21Sự tổng hợp song song các tiến trình tuần tự: Sự tổng hợp song song SP! || SP2 của hai tiến trình tuần tự SP1 và SP2 kết thúc khi cả hai tiến trình cùng kết thúc
Nếu kết thúc có thê tới được trong SP1 || SP2 thì nó là tiến trình tuần tự [1]
Hình đưới cho một ví dụ về sự tổng hợp song song của tiến trình tuần tự.: a.X Y Œ) & b.x P = (x -> END) ||S = (a:P || b:P)
Hinh 2.3.1le[1] : Su tong hop song song hai tién trinh tuan ty
2.3 LTS (Labelled Transition System)
2.3.1 LTS
Khái niệm: Về co ban LTS[1][2] (Lebelled Transition System) giéng FSP, mdi
mô tả FSP có một mô tả máy trạng thái (LTS) tương ứng Mỗi LTS tương ứng với một quá trình FSP là một đồ thị Ta lẫy ví dụ LTS mơ tả bài tốn “bữa tối của triết gia” [1]:
Trang 22PHIL = (sitdown->right.get->left get ->eat->left.put->right.put ->arise->PHIL)
FORK = (get -> put -> FORK)
|| DINERS(N=5)= forall [i:0 N-1] (phil[i]: PHIL
|| (phil[i] left phil[((i-1) +N) %N].right}:: FORK)
menu RUN = {phil[0 4] {sitdown, eat}}
Phân tích mẫu LTS này ta được 2 mô hình tương ứng:
phil.0:PHIL phillH] stdnwm phí[Ù| nghỉ get phúủ[Ẳ|laftget phí[f|saát = plul[0) left-put plul[0] nght-put
plul[U] anse
Hình 2.3.1a: Máy trạng thái PHIN
Trang 23phil.{ [D].left.get, [4] right zet} -FORK
pluol.{ (0) left.put, [4] nght put} Hinh 2.3.16: May trang thai FORK 2.3.2 Deadlock
2.3.2.1 Khai niém
Deadlock xảy ra trong hệ thống khi tất cả các tiễn trình của hệ thống đều bị
chặn hoặc không đủ điều kiện để tiễn trình đó hoạt động
Một ví dụ vê deadlock điện hình là: “bữa tôi của triết gia” Một bàn ăn có 5 cái
ghê, 5 vị triệt gia cùng ngôi vào chiệc bàn Khi bày đũa, người phục vụ chỉ đê vào giữa
mỗi người 1 chiếc đũa Như vậy 2 bên mỗi vị triết gia đều có 2 chiếc đũa nhưng nêu
người này câm đũa thì người kia sẽ không có:
Hình 2.3.2.1a: Bữa tối của triết gia[1]
Nếu số đũa được chia đều ra cho năm người, như vậy mỗi người sẽ có một chiêc đũa Cả năm người sẽ không thê thực hiện bữa ăn của mình với một chiêc đũa được, khi đó deadlock xảy ra
Trang 24Hình 2.3.2.1b: Deadlock[t] 2.3.2.2 Phân tích Deadlock
Trong mô hình trạng thái hữu hạn FSP của một tiến trình, một trạng thái
đeadlock là một trạng thái không có sự chuyển tiếp đi Một tiến trình ở trạng thái như
vậy có thể không tham gia vào các hành động tiếp theo Trong ESP trạng thái deadlock
này được biểu diễn bằng một biến cục bộ STOP[1]
Nhìn chung, hệ thống tương tranh với rất nhiều tiến trình xảy ra rất có thÊ sẽ
xảy ra bế tắc Việc kiểm tra, phân tích deadlock trong đồ thị LTS là hết sức quan
trọng Nó đảm bảo cho việc thiết kế chương trình phần mềm đúng đắn và chính xác Công cụ LTSA có sẵn chức nằng phân tích deadlock, chúng ta sẽ nghiên cứu ở phần
sau
2.3.3 Thuéc tinh An toan (safety property)
Khái niệm safety: Thuộc tính an tồn đám bảo khơng có lỗi xảy ra trong quá trình thực hiện các tiến trình của một hệ thống tương tranh
Safety property: Về mặt cú pháp, những tiến trình FSP được thêm vào trước từ
khóa property dé khang định nó là một thuộc tính an toàn Một thuộc tính an toàn khăng định tất cả các hành động trong Alphabet của nó đều được nó chấp nhận Điều này đảm báo cho hệ thống hoạt động đồng bộ bởi tiến trình an toàn này
Ví dụ mô tả trạng thái đèn xanh, đỏ của đèn giao thông:
Trang 25property TRAFICLIGHT = (red -> enter
[blue -> exit)
2.3.4 Thudc tinh Liveness (Liveness property)
Khái niệm: Thuộc tính Liveness là thuộc tính quan trọng nhất trong chương hệ thống tương tranh, nó khăng định khi chương trình kết thúc có đạt trạng thái tốt hay không [1]
Thuộc tính tiến trình (progress): Một đặc tính progress khẳng định tại bất kỳ trạng thái nào của một trong các hoạt động của một thực thi phải xảy ra Tức là các
hoạt động thành công và phải được kết thúc
Phân tích tiến trình: phân tích tiến trình để tìm ra tập kết thúc của các trạng
thái Tập kết thúc của trạng thái là một tập hợp trong đó một trạng thái có thể truy cập
từ mọi trạng thái khác trong tập hợp thông qua một hoặc nhiều chuyển tiếp và không có chuyển tiếp nào từ bên trong tập hợp ra trạng thái bên ngoài tập hợp
2.4 Cong cu LTSA
Trang 26Hình 2.4a: Mô hình hành động của chiếc ô tô |4| Animator | | =1 li enter *! Run Step | exit — enter | enter exit 7) exit enter exit enter
Hình 2.4b: LTSA animator điều khiển các hành động trong mô hình 2.4a
Mỗi hành động được chọn trong Animator sẽ điều khiển các hoạt động tương ứng trong mô hình
2.5 Kết luận
Trong chương này, chúng ta đã tìm hiểu một số khái niệm phần mềm tương tranh, phương pháp mô hình hóa, máy hữu hạn trạng thái FSP và công cụ hỗ trợ kiểm chứng LTSA Đây là những khái niệm cơ bản mà chúng ta sẽ phải trang bị để có thể
thực hiện đặc tá và kiểm chứng thiết kế, cài đặt một phần mềm tương tranh mà chúng
ta sẽ tìm hiểu ở hai chương sau
Trang 27Chương 3: Kiểm chứng thiết kế
Một bản thiết kế, dù cân thận và chỉ tiết đến đâu cũng có thế tồn tại thiếu sót, chính vì vậy mô hình hóa thiết kế là một cách để kiểm chứng hiệu quả nhất Phương
pháp mô hình hóa được sử dụng rất rộng rãi trong kỹ thuật, ở một phương diện nào đó, mô hình có thé đại diện cho vật chất, mang day đủ các tính chất của vật chất Khi chúng ta kiểm tra trên mô hình sẽ cho kết quả tương đương với ở ngoài thực tế Trong thiết kế cũng vậy, mô hình hóa thiết kế sẽ cho chúng ta kiếm tra thiết kế một cách toàn
diện, xem nó có đúng với yêu câu bài toán đặt ra không?
3.1 Đặc tả thiết kế bằng FSP
Như chúng ta đã biết ở trên, FSP rất phù hợp cho việc thiết kế một phan mềm tương tranh, tuy nhiên, chúng ta vẫn cần kiểm chứng xem thiết kế liệu có đúng như yêu cầu của bài tốn khơng? LTS Analiser ( LTSA) dùng để phân tích FSP thành các
mô hình, thuận tiện cho việc kiểm tra thiết kế Để thuận tiện cho việc hình dung, chúng
ta cùng xem một ví dụ đặc tả thiết kế bằng FSP
Bài toán “SingleLandBridge” được phát biểu như sau: Trên một con đường có
một chiếc cầu hẹp, chiếc cầu chỉ đủ cho một làn xe chạy Yêu cầu đặt ra là tạo ra một
chương trình điều khiến sự ra, vào của ô tô ở hai đầu cầu Chương trình sẽ cho các ô tô
đi tới cầu được qua cầu nếu trên cầu chỉ có ô tô đi cùng chiều hoặc không có ô tô chạy theo hướng ngược lại Nếu trên cầu có xe đang qua cầu theo hương ngược lại hoặc có ô tô đã chờ ở đầu câu bên kia trước thì ô tô này phải cho cho chiéc xe đó qua trước
Chúng ta hãy cùng nghiên cứu yêu cầu thiết kế cho bài toán Thiết kế phải thực
hiện được nhiệm vụ chỉ cho phép ô tô đó được qua cầu nếu trên cầu có ô tô đi cùng hướng hoặc hướng ngược lại không có ô tô
Thiết kế của bài toán này đã được đặc tả bằng FSP trong các ví dụ có sẵn của
công cụ LTSA Ví dụ này mang tên “SingleLandBridge” Tuy nhiên, chúng ta sẽ tìm hiểu chỉ tiết cách đặc tả thiết kế bằng các máy trạng thái FSP Ta quy định ô tô qua
chiếc cầu sẽ phân thành hai loại là ô tô đó (red) đi từ phía tây sang và ô tô xanh (blue)
đi từ phía đông sang
Trang 28
Cy ws
TT #%
Hình 3.1: Mô tả các ô tô đi qua một chiếc cầu hẹp[1]
Trước khi đặc tả hai yêu cầu của thiết kế, chúng ta hãy định nghĩa hai tiến trình
ô tô và cầu trước:
Tiến trình ô tô (CAR) có hai hành động là đi vào (enter) và đi ra (exit) khi qua câu: CAR = (enter -> exit -> CAR)
Tuy nhiên nêu ơ tơ đi theo đồn thì mỗi lần chiếc ô tô dẫn đầu được qua câu thì
cả đoàn của chiệc 6 tô đó đêu được qua Ta có thêm một định nghĩa những chiệc ô tô nữa: CARS = (red:CONVOY || blue:CONVOY)
Trong đó red, blue là những chiếc xe đỏ hoặc xanh, CONVOY là tiến trình mô tả tính chất theo đoàn của những chiếc ô tô CONVOY được định nghĩa như sau: CONVOY = [ID]:CAR
ID là sô ô tô có trong đoàn ô tô
Nêu một chiếc ô tô đỏ lên cầu, đông nghĩa với việc trên câu đó không có chiêc ô tô xanh nào Nêu trên câu đã có ô tô đỏ rỗi nhưng do các ô tô đỏ di cùng chiêu nên chiêc ô tô đó vân được lên câu, khi đó sô ô tô đỏ trên câu sẽ tăng thêm một Ngược lại, khi ô tô đỏ đó rời câu, sô ô tô đỏ sẽ giảm đi một Nêu trên câu chỉ có một chiêc ô tô do,
Trang 29khi chiếc ô tô đó rời cầu thì trên cầu sẽ không còn chiếc ô tô nào, ta gọi đó là thuộc
tính ONEWAY Khi xáy ra ONEWAY, hai đầu cầu bên nào có ô tô tới trước sẽ được
qua trước Ta có định nghĩa tiến trình RED và thuộc tính ONEWAY:
RED[i:ID] = (red[ID].enter -> RED[i+1] |when(i==1 )red[ID].exit -> ONEWAY |when( i>1)red[ID].exit -> RED[i-1]
)
Thuộc tính an toàn ONEWAY khang định chiếc cầu an toàn và cho phép ô tô
qua câu khi trên câu chỉ có một chiếc ô tô và chiệc ô tô đó đã thốt ra ngồi chiệc câu: property ONEWAY = (red[ID].enter -> RED[1] |blue[ID].enter -> BLUE[1] ) Tương tự như vậy ta cũng có tiên trình BLUE: BLUE[i:ID] = (blue[ID].enter -> BLUE[i+1] |whenG==1)blue[ID].exit -> ONEWAY |when( 1>1)blue[ID].exit -> BLUE[i-1] )
Trên chiếc cầu bao giờ cũng chỉ có một loại ô tô, hoặc là ô tô đỏ, hoặc là ô tô
xanh Nếu có cả ô tô đỏ và ô tô xanh thì chắc chắn sẽ xảy ra tai nạn Khi trên cầu
Trang 30
BRIDGE[nr:T][nb:T]= /⁄mr, nb là sô ô tô đỏ, sô ô tô xanh có trên câu
(when (nb==0) //T là số loại ô tô có trên cầu red[ID].enter -> BRIDGE[nr+1 ][nb] Ired[ID].exit -> BRIDGE[nr-1][nb] |when (nr==0) blue[ID].enter -> BRIDGE[nr][nb+1 ] [blue[ID].exit -> BRIDGE[nr][nb-1] )
Bây giờ chúng ra sẽ đặc tả bằng FSP các yêu cầu mà thiết kế phải giải quyết
- Ó tô được lên câu khi trên câu không có ô tô đi ngược chiêu hoặc có ô tô đi cùng chiêu: NOPASSI =C[1], C[i:ID] = ([i].enter -> C[i%N+1)])
- Sau khi tât cả những chiệc xe di cùng chiêu rời câu, xe ở một trong hai đầu câu sẽ được phép qua câu:
NOPASS2 =C[]],
C[i:ID] = ([i]-exit > C[i%N+1))
|CONVOY = ([ID]:CAR || NOPASSI || NOPASS2)
IICARS = (red:CONVOY || blue:CONVOY)
Trang 31
||SingleLaneBridge = (CARS || BRIDGE || ONEWAY )
Tổng hợp tất cả các máy hữu hạn trạng thái FSP ta được một máy dịch chuyển
trạng thái có gán nhãn LTS hoàn chỉnh để đặc tả thiết kế bài toán:
/** Concurrency: State Models and Java Programs
* Jeff Magee and Jeff Kramer
*/
/* Single Lane bridge
Red cars go from west to east Blue cars go from east to west
*/
const N = 3 // number of each type of car range T = 0 N // type of car count
range ID= 1 N // car identities
BRIDGE = BRIDGE[0][0], /Anitially empty
Trang 32blue[ID].enter -> BRIDGE[nr][nb+1 ] [blue[ID].exit -> BRIDGE[nr][nb-1] ) CAR = (enter->exit->CAR) /* cars may not overtake each other */ NOPASS1 =C[1], C[i:ID] = ({i].enter -> C[i%N+1)]) NOPASS2 =C[1],
C[i:ID] = ({i].exit -> C[i%N+1])
||CONVOY = ({ID]:CAR || NOPASS1 || NOPASS2) ||CARS = (red: CONVOY || blue: CONVOY)
||SingleLaneBridge = (CARS || BRIDGE || ONEWAY )
Trang 333.3 Kiém chứng thiết kê bang LTSA
Sau khi đã đặc tả xong thiết kế của bài toán bằng FSP chúng ta tiến hành kiểm
chứng thiết kế đó bằng cách sử dụng công cụ hỗ trợ kiểm chứng LTSA để phân tích mẫu LTS vừa được tạo ra
3.3.1 Giao diện của công cụ LTSA
LTSA có giao diện trực quan rất dễ sử dụng như ảnh bên dưới: fr 5 || LTSA - SingleLaneBridge.lts | |) [rm File Edit Check Build Window Help Options Da | tS Bo - | 6 || My cars -ierG @| 4 4
Edit | Output, | Draw
cE Concurrency: tate Models and Java Programs E
# deff Magee and Jeff£ Kramer
~
+ Single Lane bridge
d cars go from west to east
Red
|} Blue care go from east to west ˆ
1
}const N = 3 // number of each type of car | ranqe T = O0 N // type of car count | range ID= 1 N // car identities
| BRIDGE = BRIDGE[O][O), //initially empty
| BRIDGE[nr:T][nb:T] = //ne ig the red count, nb the blue count {when (nb==0) red[TD].enter -> BRIDGE[nr+l1][nb] |red[ID] exit -> BRIDGE[nr-1][nb] lwhen (nr==0) blue[ID].enter -> BRIDGE[nr][nbt+l] |blue[ID] exit -> BRIDBE[nr ][nh-1 ] hes |CaR = fenter-yexit->CAR) ‘* cars may not overtake each other */ |NOPASS1 = C[1], LPs Th et PD ne =P 5% 1 14
Hình 3.3.1: Giao diện cong cu LTSA
Trong cửa sỐ giao diện của chương trình có 3 khung nhìn:
- Edit: để soạn thảo mã cho chương trình hoặc hiển thị đoạn mã đã có sẵn - Qufput: nơi trả về kết quả khi kiểm tra độ an toàn hoặc khi biên dịch đoạn mã
- Draw: Hién thi két qua là các mô hình khi biên dịch đoạn mã LTS
Trang 34
Chỉ tiết về 3 khung nhìn này chúng ta sẽ tìm hiểu ở các phần tương ứng tiếp theo
Nếu muốn viết một đoạn mã mới, chúng ta chỉ cần nhẫn vào biểu tượng New File hoặc vào thực đơn Eile chọn New Khi muốn lưu đoạn mã lại ta nhắn vào biểu tượng Save File hoặc tại hộp chọn File chọn Save, đặt tên cho đoạn mã và chọn OK Kiểu file mặc định là lts
Nêu muôn mở một đoạn mã có săn, nhân và biêu tượng Open file hoặc tại thực don File chon Open
Khi công việc chuẩn bị mã đã xong, ta tiến hành kiểm tra đoạn mã:
3.3.2 Check safety
Check safety sé kiém tra xem chương trình của bạn đã được thiết kế có an tồn hay khơng? Chương trình sẽ phân tích những tiến trình có trong thiết kế của bạn và
phân tích xem trong quá trình các tiến trình đó hoạt động có xảy ra deadlock hay không? Tại thực đơn Check chọn Safety r | | 5) LSA - SingleLaneBridge.lts Se File Edit Check Build Window Help Options / 8 m HỊ š R8 5 cx|mm GE Il Bicars ria Gg @\44| Edit) Output | Draw| Compiled: CAR ˆ Compiled: NOPASS1 Compiled: NOPAS5S2 Composition:
CARS = red: CONVOY.1:CAR || red: CONVOY.2:CAR || red:CONVOY.3:CAR || red:CONVOY.NOPASS1 ||
red: CONVOY.NOPASS2 || blue:CONVOY.1:CAR || blue:CONVOY.2:CAR || blue:CONVOY.3:CAR | |
Trang 35Trên hình vẽ, công cụ LTSA đã phân tích tất cả các máy trạng thái được tạo ra để kiêm tra xem thiết kế có an tồn khơng? Cụ thể trong bài toán này chúng ta có kết quả kiểm tra là “ No đeadlock/errors” tức là thiết kế không có lỗi và không có
deadlock
3.3.3 Check Progress
Check progess có tác dụng tìm ra những hành động có vi phạm hay không, điển
hình là hành động đó không có trạng thái kết thúc và không thê thực hiện được
Tại thực đơn Check chọn Progress
fF LTSA - SingleLaneBridge.lts oy) =) le
File Edit Check Build Window Help Options Bì ø W|% Mo «| £ l| MM cars ria G Oe 4l 4 | Ed#| Output | Drave| Compiled: CAR + Compiled: NOPASS1 Compiled: NOPASS2 Composition:
CARS = red:CONVOY.1:CAR || red: CONVOY.2:CAR || red:CONVOY.3:CAR || red:CONVOY.NOFASS1 ||
red: CONVOY.NOPASS2 || blue:CONVOY.1:CAR || blue:CONVOY.2:CAR || blue:CONVOY.3:CAR ||
blue:CONVOY.NOPASS1 || blue:CONVOY.NOPASS2 State Space:
HD 27a co ằẶRh 5S R.ố.ố ố8 -5
Progress Check
States: 144 Transitions: 432 Memory used: 6435K
No progress violations detected
Progress Check in: 0ms
1"
Hình 3.3.3: Kết quả hiển thị khi check progress
Trong cửa số output, tất cả các máy trạng thái được phân tích để tìm các vi phạm có thể có Cụ thể trong thiết kế này kết quả kiểm tra là “ No progress violations detected” nghĩa là không có progress nào v1 phạm
3.3.4 Compile
Chức năng Compile dùng để biên dịch đoạn mã LTS thành các máy trạng thái
tương ứng, tại đó, ta có thể kiểm tra xem thiết kế có chính xác thieo yêu cầu không?
Trang 36
Muôn biên dịch đoạn mã tại cửa sô của chương trình nhân biên tượng chữ C (Compile) hoặc tai thyc don Build chon Compile
r | ¬h
5) LTSA - SingleLaneBridge.its | | les
File Edit Check Build Window Help Options
Bel|+ ®@o ~|@ & l| MW[cans -|EtG @| 41 4/
Edit) Output | Draw Compiled: CAR ree Compiled: NOPASS1 Compiled: NOPASS2 1 "—————————————— ————
Hình 3.3.4: Kết quả hiển thị khi biên dịch đoạn mã LTS
Sau khi chọn Compile khung nhìn Output sẽ hiện ra thông báo kết quả biện dịch, nếu đoạn mã không có lỗi, chương trình sẽ thông báo biên dịch thành công Nếu đoạn mã có lỗi, cửa sô sé thông báo có lỗi ở dòng bao nhiêu đê sửa
Trên màn hình hiến thị có 3 dòng chữ bắt đầu bằng “Conpiled” điều đó có nghĩa có 3 máy trạng thái được biên dịch và không có lỗi về cú pháp Ba máy trạng
được tạo ra thành công là CAR, NOPASS, và NOPASS2 Nếu cõ lỗi về cú pháp,
chương trình sẽ không biên dịch được và sẽ báo lỗi đó là lỗi ở dòng bao nhiêu để ta có
thể biết và sửa
Các mô hình được tạo ra sẽ được hiển thị ở khung nhìn Draw mà được mô tả
trong phân 3.3.5
Trang 373.3.5 LTS Analiser
Kết quả phân tích ví dụ trên bằng LTSA:
r || LTSA - SingleLaneBridge.lts - | | =a 2= `
File Edit Check Build Window Help Options
Bel) } ®@o o| @ || 4M cans x.IP!' @ 4i 4:
Edit] Output] Draw | red: CONVOY 1:CAR red'°ONVOY.NOPASS1 red[1] enter red[2] enter red: CONVOY.2:CAR €> red: CONVOY.3:CAR | redCOhlVOY.NOPASS1 red:'CONVOY.NOPASS2 | red[2].ehter blua:CORlVOY 1:CaàR blue:CORhlVOY 2:CAR blue: CONVOY.2:CAR blue: CONVOY.NOPASS1 blue: CONVOY NOPASS2 Pe <0 *
Hinh 3.3.5: LTS Analiser SingleLaneBridge
Mỗi mô ta FSP được mô tả bằng một mô hình tương ứng trong LTSA Phần bên
trái là danh sách các mô hình, phần bên phải hiển thị mô hình tương ứng được chọn ở
danh sách bên trái
Trên hình ta thấy một máy trạng thái với tên trạng thái ban đầu là
Trang 38
NOPASS2 =C[]],
C[:IDI = ([i].exit > C[i~N+1))
||CONVOY = ([ID]:CAR || NOPASS! || NOPASS2) |ICARS = (red: CONVOY || blue: CONVOY)
3.3.6 LTSA Animator
LTSA Animator là chức năng để điều khiển cách hành động có thể xảy ra theo như thiết kế Để sử dụng chức năng này ta vào thực đơn Check chọn Run và chọn DEFAULT Cửa số Animator sé hién ra:
Trang 39
[6| LT5A - SingleLaneBridge.ts ¡am %
| File Edit Check Build Window Help Options _ —
Del)’ ®@ -~| 6 l| Mỹ cans x/B! G6 @ 414
Ea] Output| Draw | c
red: CONVOY.1:CAR ; blue[l]lenter blne[Z].enter
tedCONVOY 2:CAR <> blue:CONVOY .NOPASS1 red: CONVOY.3:CAR red:CONVOY.NOPASS1 >< red: CONVOY NOPASS2 a w blue[3] enter il vw ^ blue.'CONVOYNOPASS1 ic ; | mm X
blue: CONVOY.NOPASS2 | aes (S| © leet)
red.1.enter ˆ Run Step blue.1.enter — |_| red.1.enter |v) red.1.exit [¥) red.2.enter || red.2.exit |) red.3.enter || red.3.exit )- — = =5 Na an h Ee —' ` L_ ¡ blue.1.enter ——ˆ [⁄: blue.1.exit |¥| blue.2.enter [| blue.2.exit || blue.3.enter ~| [| blue.3.exit x
Hinh 3.3.6: Animator SingleLandBridge
Các hành động trong Animator sẽ tương ứng với các hành động trong mô hình Hành động được chọn trong Animator sẽ điều khiến hoạt động của mô hình trong LTSA Khi một hành động được thực thi, mỗi mô hình có hành động được thự hiện sẽ chuyên thành màu đỏ ở phần bên trái của cửa số LTSA Hành động được thực thi cũng được thê hiện bằng màu đỏ trong mô hình ở phần bên phải của cửa số LTSA
Toàn bộ các hành động trong thiết kế sẽ được Animator ghi lại, nhờ đó LTSA
có thê kiểm tra được toàn bộ các hành động có thé xảy ra trong thiết kế Với cách kiểm
tra bằng mô hình như vậy, chúng ta có thê dễ dàng kiểm tra xem thiết kế có đúng với
yêu cầu bài toán đặt ra không?
Bằng việc lựa chọn tất cả các hành động có thê xảy ra trong animator chúng ta đã kiểm tra được toàn bộ hoạt động của hệ thống tương tranh trong thiết kế Qua đó chúng ta kết luận được thiết kế có hoạt động chính xác hay không Cụ thê trong thiết
Trang 40
kế đang được kiểm chứng này, em đã kiểm tra các hoạt động xảy ra trong thiết kế và
thấy thiết kế hoạt động đúng theo yêu cầu
3.4 Kết luận
Trong chương này, chúng ta đã tìm hiểu được cách đặc tả một thiết kế bằng FSP và dùng công cụ LTSA để kiêm chứng thiết kế đó Đối với ví dụ cụ thể mà chúng ta sử dụng để kiểm chứng, thiết kế đã đáp ứng được yêu cầu đặt ra