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

đặc tả và kiểm chứng các phần mềm tương tranh

53 723 2
Tài liệu đã được kiểm tra trùng lặp

Đ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 1,27 MB

Nội dung

Tài liệu tham khảo công nghệ thông tin đặc tả và kiểm chứng các phần mềm tương tranh

Trang 1

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Lê Hồng Phong

ĐẶC TẢ VÀ KIỂM CHỨNG CÁC PHẦN MỀMTƯƠNG TRANH

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

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

HÀ NỘI - 2010

Trang 2

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

Lê Hồng Phong

ĐẶC TẢ VÀ KIỂM CHỨNG CÁC PHẦN MỀM TƯƠNG TRANH

KHÓA LUẬN TỐT NGHIỆP HỆ ĐẠI HỌC CHÍNH QUY Ngành: công nghệ phần

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Lê Hồng Phong

ĐẶC TẢ VÀ KIỂM CHỨNG CÁC PHẦN MỀMTƯƠNG TRANH

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY Ngành: Công nghệ thông tin

Cán bộ hướng dẫn: Ts Phạm Ngọc Hùng

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àthầy Đặng Việt Dũng đã tận tình hướng dẫn, chỉ bảo 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 trongsuố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épnhư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 trongviệ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ậuquả 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 ảnhhưở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 đượckiể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 “Đặctả 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 lý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ạntrạng thái để đặc tả thiết kế và mã nguồn của phần mềm tương tranh Từ đó sử dụngcô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ồncủ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ệnkiể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ẵnbằ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

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

1.1 Nhu cầu thực tế và lý do thực hiện đề tài 1

1.2 Mục tiêu của đề tài 2

1.3 Nội dung của khóa luận 3

Chương 2: Các khái niệm cơ bản 4

2.1 Phương pháp mô hình hóa 4

3.3 Kiểm chứng thiết kế bằng LTSA 23

3.3.1 Giao diện của công cụ LTSA 23

Trang 6

4.1 Phương pháp để kiểm chứng cài đặt 30

4.2 Cách chuyển từ mã nguồn Java sang FSP 30

4.3 Ứng dụng để chuyển mã nguồn bài toán “SingleLandBridge” 33

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 ô tô 4

Hình 2.2.1a: Mô hình hóa hành trình bay của máy bay 6

Hình 2.2.2a: Máy trạng thái DRINKS 7

Hình 2.2.2b: Máy trạng thái Gate 8

Hình 2.3.1c: Tiến trình tuần tự BOMP 10

Hình 2.3.1d: Sự tổng hợp tuần tự LOOP 10

Hình 2.3.1e : Sự tổng hợp song song hai tiến trình tuần tự 11

Hình 2.3.1a: Máy trạng thái PHIN 12

Hình 2.3.1b: Máy trạng thái FORK 13

Hình 2.3.2.1a: Bữa tối của triết gia 13

Hình 2.3.2.1b: Deadlock 14

Hình 2.4a: Mô hình hành động của chiếc ô tô 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 ô tô đi qua một chiếc cầu hẹp 18

Hình 3.3.1: Giao diện công cụ LTSA 23

Hình 3.3.2: Kết quả hiển thị sau khi check safety 24

Hình 3.3.3: Kết quả hiển thị khi check progress 25

Hình 3.3.4: Kết quả hiển thị khi biên dịch đoạn mã LTS 26

Hình 3.3.5: LTS Analiser SingleLaneBridge 27

Hình 3.3.6: Animator SingleLandBridge 28

Hình 4.5a: Mở tệp SafeBridge bằng công cụ LTSA 36

Trang 8

Hình 4.5c: Check prgress phương thức redExit 38Hình 4.5d: Máy trạng thái REDEXIT 39Hình 4.5e: Máy trạng thái REDEXIT trong thiết kế 40

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

Trang 9

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

Trang 10

BẢNG KÝ TỰ VIẾT TẮT

FSP (Finite State Process) Máy hữu hạn trạng thái

LTS (Labelled Transition System) Máy dịch chuyển trạng thái có gán nhãnLTSA (LTS Analyzer) Công cụ hỗ trợ kiểm chứng với đặc tả là

LTS

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 conngườ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ể baogồ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ềmtương tranh chính là linh hồn của hệ thống, giúp chúng hoạt động chính xác theonhững gì mà con người yêu cầu Hiện nay, phần mềm tương tranh được ứng dụng rấtnhiề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, ti vi, đến những hệ thống điều khiển phức tạpnhư 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ềukhiển.

Những vật dụng, hệ thống điều khiển này gắn bó chặt chẽ với chúng ta, chỉ cầnmộ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àntoà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ươngpháp kiểm thử hiện tại chỉ là kiểm tra dữ liệu đầu ra của phần mềm rồi so sánh với dữ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 chi tiết hoạt động của chương trình và không kiểm soát được những lỗitiề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ẫncò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ảmuy 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ụngphươ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àncao, 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ếtkế bằng FSP[1] và sử dụng công cụ LTSA[1][4] để kiểm chứng thiết kế đó Sau khithiết kế đã được kiểm tra và thẩm định tính đúng đắn, chúng ta tiến hành cài đặtchươ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ếtkế 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ínhmô 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áttriể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ềukhiể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ó vaitrò 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ôngcó 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ôngcầ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áicủ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áydị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 SystemAnalyzer).

 Sử dụng công cụ hỗ trợ kiểm chứng LTSA để kiểm chứng thiết kế củamộ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ụngcô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 1 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áyhữ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íchLTSA 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ộtchươ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ụngrộng rã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ênmô 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.1: 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ốngvớ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àphần 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ọnphươ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ả chi tiết được cáchoạt động của phần mềm Thiết kế càng chi tiết thì phần mềm hoạt động càng chínhxá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ápthiế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ảiquyế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 chi 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 đúngtheo 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ìnhthức.

2.2 FSP (Finite State Process)

2.2.1 Khái 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 FSPcó thể mô tả được những hành động, trạng thái của tiến trình Ta lấy một ví dụ đơngiả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êntụ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ênsẽ không thể nào đầy đủ được Tuy nhiên ta hoàn toàn có thể giải quyết vấn đề đó nếumô tả các hành động đó bằng FSP:

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

Trang 16

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:

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ảyra 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 chi tiết một phần mềm tươngtranh với đặc tả là FSP.

2.2.2 Các thành phần 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 frefix (x -> P) mô tả một tiến trình trong đó các hành động x hoạt động đúngtheo 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êtbằng chữ cái thường.

Ta lấy lại ví dụ trên phần 2.2.1 :

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

Trong đó: Maybay là một tiến trình

Trang 17

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ếptheo 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 độngtiế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:

Hình 2.2.2a: Máy trạng thái 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ô khiqua 3 cổng của một trạm soát vé:

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

Trang 18

| in[3] -> out[3] -> Gate).

Trong đó [1], [2], [3] là chỉ mục của các hành động in và out.Kết quả khi phân tích bằng công cụ LTSA:

Hình 2.2.2b: Máy trạng thái 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ằngFSP đượ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

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ố ngườiquá 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],

Trang 19

Count[i:1 N] = (when(i<N) enter -> Count[i+1] | when(i>N) out -> Count[i-1]).

Hành động được đảm bảo bởi “when” đảm bảo cho thang máy hoạt động đúngcông suất Khi số người quá quy định thì phải ra ngoài bớt, khi số người trong thangchư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ĩaWRITE sử dụng write[1] và write[3]:

WRITER = (write[1]->write[3]->WRITER)

+{write[0 3]}.

Trong ví dụ này thì Alphabet của WRITE là 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 trongmộ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ìnhcụ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ềnhành động (Action prefix) 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ộttiế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ạngthái bắt đầu của nó [1].

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ảyra sau END Về mặt ngữ nghĩa nó tương tự như STOP Tuy nhiên, STOP là một trạngthái mà tiến trình tạm ngưng quá sớm, thường là do deadlock STOP được sử dụng khi

Trang 20

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:

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 trình 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ó dạng: SP1;SP2;….;SPn;LP [1]Nơi SP1;…;SPn là sự tổng hợp tuần tự và LP là tiến trình cục bộ Một sự tổnghợp 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].

Ví dụ tiến trình P123 và LOOP:

Hình 2.3.1d[1]: Sự tổng hợp tuần tự LOOP

Sự tổng hợp song song các tiến trình tuần tự: Sự tổng hợp song song SP1 ||

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

Trang 21

Hình dưới cho một ví dụ về sự tổng hợp song song của tiến trình tuần tự.:

Hình 2.3.1e[1] : Sự tổng hợp song song hai tiến trình tuần tự.

2.3 LTS (Labelled Transition System)

2.3.1 LTS

Khái niệm: Về cơ bản LTS[1][2] (Lebelled Transition System) giống FSP, mỗi

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ộtquá 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]:

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

Trang 22

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:

Hình 2.3.1a: Máy trạng thái PHIN

Hình 2.3.1b: Máy trạng thái FORK

Trang 23

2.3.2 Deadlock2.3.2.1 Khái 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áighế, 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ữamỗ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ếungườ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ộtchiế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 24

Hình 2.3.2.1b: Deadlock[1]

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áideadlock 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 FSP trạng thái deadlocknà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 tính An toàn (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 để khẳng định nó là một thuộc tính an toàn Một thuộc tính an toànkhẳng định tất cả các hành động trong Alphabet của nó đều được nó chấp nhận Điềunà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:

property TRAFICLIGHT = (red -> enter |blue -> exit).

2.3.4 Thuộc tính 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 haykhô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áchoạt động thành công và phải được kết thúc

Trang 25

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 Công cụ LTSA

LTSA (Labelled Transition System Analiser) là một công cụ hỗ trợ kiểm chứngvới đặc tả là LTS LTSA sử dụng để kiểm tra tính mong muốn và không mong muốncho 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ễnphí từ trang web [4] chính thức của cuốn sách “Concurrency: State Models and JavaPrograms second edition [1]” Ta lấy ví dụ LTSA phân tích một đặc tả LTS cho trạngthái vào, ra của một chiếc ô tô khi qua cầu:

CAR = (enter -> exit -> CAR).

Hình 2.4a: Mô hình hành động của chiếc ô tô

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ươngtranh, 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ểmchứ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úngta sẽ tìm hiểu ở hai chương sau.

Ngày đăng: 23/11/2012, 15:03

HÌNH ẢNH LIÊN QUAN

BẢNG KÝ TỰ VIẾT TẮT - đặc tả và kiểm chứng các phần mềm tương tranh
BẢNG KÝ TỰ VIẾT TẮT (Trang 17)
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. - đặc tả và kiểm chứng các phần mềm tương tranh
rong 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 (Trang 22)
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: - đặc tả và kiểm chứng các phần mềm tương tranh
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: (Trang 24)
Khi phân tích mẫu FSP trên ta đuợc mô hình: - đặc tả và kiểm chứng các phần mềm tương tranh
hi phân tích mẫu FSP trên ta đuợc mô hình: (Trang 25)
Hình 2.2.2b: Máy trạng thái Gate - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 2.2.2b Máy trạng thái Gate (Trang 26)
Hình 2.3.1d[1]: Sự tổng hợp tuần tự LOOP - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 2.3.1d [1]: Sự tổng hợp tuần tự LOOP (Trang 28)
Hình 2.3.1e[1 ]: Sự tổng hợp song song hai tiến trình tuần tự. 2.3 LTS (Labelled Transition System) - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 2.3.1e [1 ]: Sự tổng hợp song song hai tiến trình tuần tự. 2.3 LTS (Labelled Transition System) (Trang 29)
Hình 2.3.1a: Máy trạng thái PHIN - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 2.3.1a Máy trạng thái PHIN (Trang 30)
Phân tích mẫu LTS này ta được 2 mô hình tương ứng: - đặc tả và kiểm chứng các phần mềm tương tranh
h ân tích mẫu LTS này ta được 2 mô hình tương ứng: (Trang 30)
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 - đặc tả và kiểm chứng các phần mềm tương tranh
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 (Trang 31)
Hình 2.3.2.1a: Bữa tối của triết gia[1] - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 2.3.2.1a Bữa tối của triết gia[1] (Trang 31)
Hình 2.4b: LTSA animator điều khiển các hành động trong mô hình 2.4a - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 2.4b LTSA animator điều khiển các hành động trong mô hình 2.4a (Trang 33)
Hình 2.4a: Mô hình hành động của chiế cô tô - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 2.4a Mô hình hành động của chiế cô tô (Trang 33)
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 các phần mềm tương tranh
Hình 3.1 Mô tả cá cô tô đi qua một chiếc cầu hẹp[1] (Trang 36)
Hình 3.3.1: Giao diện công cụ LTSA - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 3.3.1 Giao diện công cụ LTSA (Trang 41)
Hình 3.3.2: Kết quả hiển thị sau khi check safety - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 3.3.2 Kết quả hiển thị sau khi check safety (Trang 42)
Hình 3.3.3: Kết quả hiển thị khi check progress - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 3.3.3 Kết quả hiển thị khi check progress (Trang 43)
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 các phần mềm tương tranh
Hình 3.3.4 Kết quả hiển thị khi biên dịch đoạn mã LTS (Trang 44)
Hình 3.3.5: LTS Analiser SingleLaneBridge - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 3.3.5 LTS Analiser SingleLaneBridge (Trang 45)
Hình 3.3.6: Animator SingleLandBridge - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 3.3.6 Animator SingleLandBridge (Trang 47)
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 các phần mềm tương tranh
Bảng 4.3.2a Những toán tử tương đương giữa FSP và Java (Trang 50)
Bảng 4.3.2b: Các thành phần cơ bản khi chuyển từ Java sang FSP: - đặc tả và kiểm chứng các phần mềm tương tranh
Bảng 4.3.2b Các thành phần cơ bản khi chuyển từ Java sang FSP: (Trang 50)
Hình 4.5a: Mở tệp SafeBridge bằng công cụ LTSA - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 4.5a Mở tệp SafeBridge bằng công cụ LTSA (Trang 54)
Hình 4.5b: Check safety phương thức redExit - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 4.5b Check safety phương thức redExit (Trang 55)
Hình 4.5c: Check prgress phương thức redExit - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 4.5c Check prgress phương thức redExit (Trang 56)
Hình 4.5d: Máy trạng thái REDEXIT - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 4.5d Máy trạng thái REDEXIT (Trang 57)
Hình 4.5e: Máy trạng thái REDEXIT trong thiết kế. - đặc tả và kiểm chứng các phần mềm tương tranh
Hình 4.5e Máy trạng thái REDEXIT trong thiết kế (Trang 58)

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

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

TÀI LIỆU LIÊN QUAN

w