1. Trang chủ
  2. » Cao đẳng - Đại học

ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA HỆ THỐNG TƯƠNG TRANH ĐẠI HỌC QUỐC GIA HÀ NỘI

53 1,7K 1
Tài liệu được quét OCR, nội dung có thể không chính xác

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

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

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 53
Dung lượng 8,3 MB

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

Nội dung

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

TRUONG 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

HA NOI - 2010

Trang 2

TRUONG 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

HÀ NỘI - 2010

Trang 3

LỜ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

Lê Hồng Phong

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

đúng theo thiết kế hay không.

Trang 5

MỤC LỤC

1.1 Nhu cau thu té va ly do thie hién dé tai occ cs ceseesscsesesesesssesesesees 1

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

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

3.3.1 Giao diện của cơng cụ LTSA cv S9 1 1S 11 nhu 23

SE VƠ 1v 6ï cuaưiađiiaiaiiiiitỐcdÝ 24 S69 .64o nh ố .d -sa 25

3.3.5 LTS ATiẠIS€T .G Q1 ng TH TK KT KkEEn 27 3.3.6 LTSA ATITTÍOT, G2 1 9v 399999191 99111 1 1191111 kh 28

Chương 4: Kiểm chứng cài đặt . - - c1 1E E3 1133 111 1 1kg 3l

vi

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

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

vii

Trang 7

Danh 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;0/).52591.0L(/)8.4,.,;-0 0, 20060) 011 13 Hinh 2.3.2.la: Bita toi CU triet Cid cee ccececsesssesesesesssveveevsvsvevevecsevevsvsvevscsenensvevevacneseves 13

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

viii

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

Hình 4.5e: Máy trạng thái REDEXIT trong thiết kế - - cnxsssevsvsrserererred 4]

Trang 9

Danh mục các bảng biêu

Bảng 4.3.2a Những toán tử tương đương giữa FSP và J4VA csc s3 32 Bảng 4.3.2b: Các thành phân cơ bản khi chuyển từ Java sang FSP e 32

Trang 11

Chươ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 soá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

Cách tiệp cận của khóa luận là:

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à

đúng với thiết kế không.

Trang 13

1.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 toá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?

Chương 5 khái quát những kết quả đạt được và hướng phát triển trong tương lai.

Trang 14

Chươ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

Thiêt kê có vai trò vô cùng quan trọng trong sản xuât phân mêm nói chung và phan mém tương tranh nói riêng Phần mềm được lập trình ra có đạt yêu cầu hay

Trang 15

khô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:

Trang 16

Maybay = (catcanh -> bay -> hacanh -> Maybay)

FSP có tính đệ quy nên ta có thể dễ dàng giải quyết bài toán trên Ta có mô hình

được phân tích từ mẫu FSP này:

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

action ffelx (x -> P) mô tả một tiến trình trong đó các hành động x hoạt động đúng theo mô tả của tiến trình P [1] Tiến trình P phải viết hoa chữ cái đầu, hành động x viêt

Trang 17

Trong đó: 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)

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à

hành động đó có rất nhiều giá trị Ta có thể gán nhãn cho các quy trình và hành động

đó và lập chỉ mục cho chúng Ví dụ FSP mô tả hành động vào, ra của 3 chiếc ô tô khi qua 3 công của một trạm soát vẻ:

Trang 18

Gate = (in[1] -> out[1] -> Gate

| in[2] -> out[2] -> 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:

Trong đó i:1 N có nghĩa i có giá trị lần lượt từ 1 đến N

Hành động được đảm bảo (Guarded Action): thường rất hữu dụng để định nghĩa các hành động cụ thể nhưng muốn xảy ra phải thỏa mãn một điều kiện nào đó

Ví dụ mô tả đám đông vào thang máy, thang máy cho phép chở 10 người, nếu số

Trang 19

ngườ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]:

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

thái bắt đầu của nó [1].

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 21

Sự 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ự.:

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 toán “bữa tối của triết gia” [1]:

11

Trang 22

PHIL = (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

12

Trang 23

phil.{ [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

13

Trang 24

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 toà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:

14

Trang 25

property 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

LTSA (Labelled Transition System Analiser) là một công cụ hỗ trợ kiếm chứng với đặc tả là LTS LTSA sử dụng để kiểm tra tính mong muốn và không mong muốn cho tất cả các trình tự có thể có của các sự kiện và hành động [1] LTSA được tải miễn phí từ trang web [4] chính thức của cuốn sách “Concurrency: State Models and Java Programs second edition [1]” Ta lay vi du LTSA phân tích một đặc tả LTS cho trạng thải vào, ra của một chiéc ô tô khi qua câu:

CAR = (enter -> exit -> CAR)

Trang 26

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

16

Ngày đăng: 07/07/2015, 12:15

HÌNH ẢNH LIÊN QUAN

Hình  2.2.1a:  Mô  hình  hóa  hành  trình  bay  của  máy  bay. - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.2.1a: Mô hình hóa hành trình bay của máy bay (Trang 16)
Hình  2.2.2b:  May  trang  thai  Gate - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.2.2b: May trang thai Gate (Trang 18)
Hình  2.3.1d[1]:  Su  tong  hop  tuan te  LOOP - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.3.1d[1]: Su tong hop tuan te LOOP (Trang 20)
Hình  2.3.1c  [1  :  Tiến  trình  tuân  tự  BOMP - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.3.1c [1 : Tiến trình tuân tự BOMP (Trang 20)
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ự.: - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh đưới cho một ví dụ về sự tổng hợp song song của tiến trình tuần tự.: (Trang 21)
Hình  2.3.1a:  Máy  trạng  thái  PHIN - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.3.1a: Máy trạng thái PHIN (Trang 22)
Hình  2.3.2.1a:  Bữa  tối  của  triết  gia[1] - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.3.2.1a: Bữa tối của triết gia[1] (Trang 23)
Hình  2.3.2.1b:  Deadlock[t] - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.3.2.1b: Deadlock[t] (Trang 24)
Hình  2.4a:  Mô  hình  hành  động  của  chiếc  ô  tô - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 2.4a: Mô hình hành động của chiếc ô tô (Trang 26)
Hình  3.1:  Mô  tả  các  ô  tô  đi  qua  một  chiếc  cầu  hẹp[1] - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 3.1: Mô tả các ô tô đi qua một chiếc cầu hẹp[1] (Trang 28)
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 - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
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 (Trang 35)
Hình  3.3.4:  Kết  quả  hiển  thị  khi  biên  dịch  đoạn  mã  LTS - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
nh 3.3.4: Kết quả hiển thị khi biên dịch đoạn mã LTS (Trang 36)
Bảng  4.3.2b:  Các  thành  phan  co  ban  khi  chuyến  từ  Java  sang  FSP: - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
ng 4.3.2b: Các thành phan co ban khi chuyến từ Java sang FSP: (Trang 42)
Bảng  4.3.2a  Những  toán  tử  tương  đương  giữa  FSP  và  Java - ĐẶC TẢ VẢ KIỂM CHỨNG THIẾT KẾ CỦA   HỆ THỐNG TƯƠNG TRANH   ĐẠI HỌC QUỐC GIA HÀ NỘI
ng 4.3.2a Những toán tử tương đương giữa FSP và Java (Trang 42)

TỪ KHÓA LIÊN QUAN

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

TÀI LIỆU LIÊN QUAN

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

w