Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 67 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
67
Dung lượng
1,82 MB
Nội dung
MINISTRY OF EDUCATION AND TRAINING HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY - VU MINH PHONG Vu Minh Phong INFORMATION TECHNOLOGY STUDYING AND APPLYING BIP COMPONENT-FRAMEWORK IN SOFTWARE CONSTRUCTION AND VERIFICATION MASTER THESIS OF SCIENCE … INFORMATION TECHNOLOGY 2013B Hanoi – 2015 MINISTRY OF EDUCATION AND TRAINING HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY - Vu Minh Phong STUDYING AND APPLYING BIP COMPONENT-FRAMEWORK IN SOFTWARE CONSTRUCTION AND VERIFICATION Major : INFORMATION TECHNOLOGY MASTER THESIS OF SCIENCE … INFORMATION TECHNOLOGY ADVISOR : Assoc.Prof.Dr.Huynh Quyet Thang Hanoi – 2015 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI - Vũ Minh Phong NGHIÊNCỨUVÀỨNGDỤNGCÔNGCỤBIPTRONGPHÁTTRIỂNVÀKIỂMCHỨNGPHẦNMỀM Chuyên ngành : CÔNG NGHỆ THÔNG TIN LUẬN VĂN THẠC SĨ KHOA HỌC … CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC : PGS.TS Huỳnh Quyết Thắng Hà nội – 2015 Studying and applying BIP Component-Framework in Software Construction and Verification COMMITMENT I commit myself to be the person who was responsible for conducting this study All reference figures were extracted with clear derivation The presented results are truthful and have not published in any other person’s work VU MINH PHONG PhongVu_15BCNTT.KH Page Studying and applying BIP Component-Framework in Software Construction and Verification Menu COMMITMENT Abbreviations ACKNOWLEDGEMENT ABSTRACT CONTEXT ORGANIZATION OF THE THESIS 10 CHAPTER – BIP MODELING FRAMEWORK 11 1.1 Component-based Design 11 1.2 BIP Modeling Framework 12 1.2.1 Atomic Components 13 1.2.2 Interactions 15 1.2.3 Priorities 17 1.2.4 Composite components 17 1.3 Properties of BIP Components 18 1.3.1 Invariant 18 1.3.2 Local Deadlock-freedom 19 1.3.3 Global Deadlocks 20 1.4 BIP Tool-Chain 21 1.5 Summary 22 CHAPTER – VERIFICATION METHOD, INCREMENTAL CONSTRUCTION AND D-FINDER 24 2.1 Compositional Verification Method 25 2.1.1 Compositional Verification Rule 25 2.1.2 Component Invariants 27 2.1.3 Interaction Invariants 29 2.2 Abstraction 35 2.3 Checking Safety Properties 39 2.4 Application for Checking Deadlock-Freedom 40 2.5 Incremental Construction and Verification 40 PhongVu_15BCNTT.KH Page Studying and applying BIP Component-Framework in Software Construction and Verification 2.6 The D-Finder tool 42 2.7 Summary 43 CHAPTER – PROPOSED TECHNIQUE FOR DEADLOCK AVOIDANCE 46 3.1 Motivation 46 3.1.1 Limitation of checking safety properties 46 3.1.2 Possibly reachable states 47 3.2 Deadlock-avoidance 47 3.2.1 Idea 47 3.2.2 Technique 49 3.2.3 Example 51 3.2.3.1 Dinning Philosopher 51 3.2.3.2 Gas station 53 3.2.3.3 ATM 55 3.3 Implementation and experimental results 56 3.3.1 Implementation 56 3.3.2 Experiments 59 CONCLUSION AND PERSPECTIVE 61 REFERENCES 63 PhongVu_15BCNTT.KH Page Studying and applying BIP Component-Framework in Software Construction and Verification Abbreviations BIP Behavior-Interaction-Priority ATM Automated Teller Machine HUST PhongVu_15BCNTT.KH Hanoi University of Science and Technology Page Studying and applying BIP Component-Framework in Software Construction and Verification ACKNOWLEDGEMENT This thesis could not be done without special help and supports from Dr Hung Thanh Nguyen and Dr Thang Quyet Huynh I am honor and grateful for being their student for all the time I was in Hanoi University of Science and Technology (HUST) and I will forever be I also want to give special thanks to all of my teachers at HUST who had taught me the way of science and given me a significant boost for my future career in academia Your knowledge that was transferred to me will be put into good use and will honor the university we all loved Lastly, to my family, my friends who stood by me and cheered with me when I needed, I thank you very much It has been an honor to be born, be raised, and befriended by you PhongVu_15BCNTT.KH Page Studying and applying BIP Component-Framework in Software Construction and Verification ABSTRACT Model Checking in Formal verification for software system has long been a notorious research topic among computer science society The problems introduced in this research field include but not limited to: scalability, effectiveness, incrementality, compositionality There are many prior works [8][9] tried to solve these problems, and the current state of the art is BIP modeling framework (Behavior, Interaction, Priority) from Verimag [10] BIP is a component-based framework for modeling heterogeneous systems It allows software developers to deal with the complexity of systems and considers the correctness-by-construction for several important properties such as deadlock-freedom or invariants Hung et al proposed an extension [1]-[7] of BIP framework that verify safetyness properties of a component-based software system using a compositional verification approach It efficently computes the over-approximation of the reachable states of the system using component invariant and interation invariant One application for this approach is deadlock-freedom checking by computing the intersection between defined deadlock conditions and the over-approximation state set However, one weakness of this approach is that, it cannot tell if there are actual deadlock states in the real system or they are just on the over-approximation set and can never be reached in real-life situations Software developers, however, need at least a way to handle the deadlocks if they are about to happen when the systems are executed To address this need, we propose a novel technique to ultilize the over-approximation approach by labeling and avoiding deadlock states in run-time With this technique, not only deadlock states will be identified in run-time but the software system will also be able to avoid the deadlocks and continue on a safe execution path PhongVu_15BCNTT.KH Page Studying and applying BIP Component-Framework in Software Construction and Verification CONTEXT Software development is an important task in almost every industries we know of today However, this overly complicated process has led to many severe problems, resulted in losses of human lives and negative impacts on the economy The Therac25 medical radiation therapy device was involved in several cases where massive overdoses of radiation were administered to patients in 1985-87, a side effect of the buggy software powering the device A number of patients received up to 100 times the intended dose, and at least three of them died as a direct result of the radiation overdose Another radiation dosage error happened in Panama City in 2000, where therapy planning software from US company Multidata delivered different doses depending on the order in which data was entered This resulted in massive overdoses for some patients, and at least five died The number of deaths could potentially be much higher, but it is difficult to know how many of the 21 who died in the following years did so as a result of their cancer or ill effects from the radiation treatment In 1996, a European Ariane rocket was set to deliver a payload of satellites into Earth orbit, but problems with the software caused the launch rocket to veer off its path a mere 37 seconds after launch As it started disintegrating, it self-destructed (a security measure) The problem was the result of code reuse from the launch system’s predecessor, Ariane 4, which had very different flight conditions from Ariane More than $370 million were lost due to this error Safety-critical systems such as nuclear reactor managerment softwares or plane control systems can cause unimaginable castatrophic events if they are unstable or not work as expected Therefore, the construction of correct software systems is an essential requirement nowadays However, constructing such systems are becoming much more complicated because of the constantly growing demand of complexity and scalability Human inspection and review became an obsolate and inefficent method for detecting potential violation of desired properties of software system, thus the demand for automated software verification/testing tool is increasing These are also the two main PhongVu_15BCNTT.KH Page Studying and applying BIP Component-Framework in Software Construction and Verification state is deadlock/pre-deadlock, algorithm 3.2 continue traveling backward If the current state is a dangerous state, it will lower the priority for transition l l’ In the end, our result will be similar to that of figure Figure Assigning priority to avoid deadlock on dangerous states Figure further illustrates our point, that is transition T5 has higher priority than T6, T1 < T2, T7 < T8 and T3 < T4 They are in the invariant ф, and may never be reachable in real system S However, in any case that they are reachable in S, this technique will prevent the system to go into deadlock states, thus ultimately avoid deadlock PhongVu_15BCNTT.KH Page 50 Studying and applying BIP Component-Framework in Software Construction and Verification 3.2.3 Example 3.2.3.1 Dinning Philosopher Figure Dinning philosophers problem The Dining Philosophers problem, can be shortly presented as a number of philosophers sitting at a table doing one of two things: eating or thinking While they are thinking, they are not eating and while they are eating, they are not thinking They sit at a round table and each philosopher has a spaghetti disk in front of him Between two any next philosophers, there is a fork A philosopher can eat if he has both forks from the left and from the right And a philosopher can put two forks back to the table only if he has finished eating Here there is a deadlock situation if they all have the same order of taking forks and every philosopher has taken one fork, so everyone can not eat because each has only one fork However, if a Philosophers changes the order of taking forks, for example, he takes the right one before the left one while the others take the left one before the right one, then there is no deadlock We have considered both cases in the experimentation PhongVu_15BCNTT.KH Page 51 Studying and applying BIP Component-Framework in Software Construction and Verification We have modeled the philosopher and the fork in BIP Figure represents the behavior of a philosopher: initially in state lth, he can think by think transition or prepare for eating by first taking the left fork and moves to 01 location where he has one fork on the left hand, then taking the right fork and moves to E1 location where he has two forks on both hands At E2 he can eat by taking eat transition and moves to T1 location where he has finished eating, hence he can put two forks by put transition and returns to lt location The think and the eat transitions are internal, they can be executed without synchronizing with other components and hence their ports are complete, represented by triangles in the figure The other ports (left1, left2, done1) are incomplete (represented by circles) and their transitions need to synchronize with other components to be executed The model of a fork is quite simple It has two locations A and B Initially in the location A , a fork can be taken by use transition and goes to B location From B, a fork is released if the free transition is executed and the fork returns to A location Both ports use and free are incomplete D-finder detected a deadlock if all forks are occupied, i.e all philosophers are at state O, shown in figure Using algorithm assignPriority and goBackward algorithms as explained in 2.2, we found that states (O1 B1 T2 A2), (O2 B2 T1 A1) are Dangerous states, and transitions left2, left1 need to have lower priority than transition right1, righ2, respectively PhongVu_15BCNTT.KH Page 52 Studying and applying BIP Component-Framework in Software Construction and Verification Figure Philosophers Problem with deadlock state and deadock avoidance by prioritizing 3.2.3.2 Gas station Figure 10 Gas station problem Gas Station consists of an Operator with a computer, a set of pumps, and a set of customers Each pump can be used by a fixed number of customers The set of the atomic components involved in a system with n pumps and m customers for each pump is denoted by B[n, m] = {Operator, {pumpi}1≤i≤n, {customerij}1≤i≤n, 1≤j≤m } PhongVu_15BCNTT.KH Page 53 Studying and applying BIP Component-Framework in Software Construction and Verification Before using a pump, each customer has to prepay for the transaction Then the customer uses the pump, collects his change and goes to a state from which he may start a new transaction Before being used by a customer, the pumps have to be activated by the Operator When a pump is shut off, it can be re-activated for the next operation Figure gives the model for Gas Station system for one pump and two customers The Operator has two control locations and three ports.The transition labeled with prepay accepts a customer’s prepay and activates the pump for the customer When a customer is served, the transition labeled with finish will synchronize the pump and the customer A pump has three control locations and three ports Besides the synchronization between the Operator and customer through activate and finish ports, a pump and a customer are synchronized through start ports Figure 11 Gas Station with deadlock and Deadlock avoidance using Prioritizing Using our technique, we found several dangerous states, and prioritized start1 over prepay2 for instance PhongVu_15BCNTT.KH Page 54 Studying and applying BIP Component-Framework in Software Construction and Verification 3.2.3.3 ATM Figure 12 ATM model Automatic Teller Machine (ATM) is a computerized telecommunication device that provides services to access to financial transactions in a public space without the need for a cashier, human clerk or bank teller The structural model of the ATM system [CEFH01] is presented in Figure 6.10 The system is composed of the following components: User, ATM (modeling a cash dispenser) and Bank (modeling some aspects of bank operation) User and Bank interact only with ATM, but not with each other Figure 12 presents the modeling of ATM in BIP: – Initially at location l0, user can insert the card by insert transition and enter the confidential code (enter transition) Then there are two cases: if the code is invalid, user gets back the card by eject transition and returns to the initial state l0; otherwise, user continues by entering the amount of cash he/she wants to withdraw If the amount is not accepted, the transaction is canceled (cancel transition); else there are two cases: transition fails (fail transition) or is ready (success transition) for user to withdraw the money Finally user gets back their card – Initially at location l0, ATM is waiting for user to insert the card (insert transition) and then to enter the confidential code (enter transition) The time-out for entering the code is time units then it validates the entered code If it receives nonauthorized for the code by non_authorized transition, invalid transition takes place PhongVu_15BCNTT.KH Page 55 Studying and applying BIP Component-Framework in Software Construction and Verification and then it ejects the card If it receives authorized signal by authorized transition, the transition validated takes place and it moves to a location where user can enter the amount of cash The timeout for entering the amount is time units If the user cancels the transaction or the amount is not allowed, it returns to l6 to eject the card; else it accepts the amount and starts the transaction If the transaction is forbidden (veto transition), it will announce to user by fail transition; else it will wait for user to withdraw the cash (withdraw transaction) and eject the card to finish the transaction – For Bank, there are two components: BankValidation component checks the validity of PIN code and BankTransaction component checks whether the transaction is forbidden (veto) or allowed (fiat) The use of these parallel components allows supporting multi Users and multi ATMs With several modifications, two customer using the same account could end up in deadlock in fiat and veto part Normally, most database can handle this problem with their mechanism of transaction, but for testing purpose of our technique, we assume that they can not 3.3 Implementation and experimental results We implemented our technique in Java, along with D-finder for better intergration 3.3.1 Implementation We create several BIP examples using the Dinning Philosophers problem and ATM, Gas Station models The following is the BIP implementation of Dinning Philosophers for philosophers: model DiningPhilosopher atomic type Philosopher export port Port think export port Port eat export port Port pick_l export port Port pick_r PhongVu_15BCNTT.KH Page 56 Studying and applying BIP Component-Framework in Software Construction and Verification export port Port put place THINKING, HAS_ONE_FORK, HAS_TWO_FORK, FINISH 10 initial to THINKING on think 11 12 from THINKING to THINKING on pick_l 13 14 from THINKING to HAS_ONE_FORK on pick_r 15 16 from HAS_ONE_FORK to HAS_TWO_FORK on eat 17 18 from HAS_TWO_FORK to FINISH on put 19 from FINISH to THINKING 20 end 21 atomic type Fork 22 export port Port pick 23 export port Port put 24 place FREE, USED 25 initial to FREE 26 on pick 27 28 from FREE to USED on put 29 from USED to FREE 30 end 31 connector type rendezvous2(Port p1, Port p2) 32 define [ p1 p2 ] 33 end 34 connector type rendezvous3(Port p1, Port p2, Port p3) 35 define [ p1 p2 p3 ] 36 end PhongVu_15BCNTT.KH Page 57 Studying and applying BIP Component-Framework in Software Construction and Verification 37 connector type single(Port p1) 38 define [ p1 ] 39 end 40 compound type Philos 41 component Philosopher P1 42 component Fork F1 43 component Philosopher P2 44 component Fork F2 45 component Philosopher P3 46 component Fork F3 47 component Philosopher P4 48 component Fork F4 49 //connector single P1_think(P1.think) 50 connector single P1_eat(P1.eat) 51 connector rendezvous2 P1_pick_l(P1.pick_l, F1.pick) 52 connector rendezvous2 P1_pick_r(P1.pick_r, F4.pick) 53 connector rendezvous3 P1_put(P1.put, F1.put, F4.put) 54 //connector single P2_think(P2.think) 55 connector single P2_eat(P2.eat) 56 connector rendezvous2 P2_pick_l(P2.pick_l, F2.pick) 57 connector rendezvous2 P2_pick_r(P2.pick_r, F1.pick) 58 connector rendezvous3 P2_put(P2.put, F2.put, F1.put) 59 //connector single P3_think(P3.think) 60 connector single P3_eat(P3.eat) 61 connector rendezvous2 P3_pick_l(P3.pick_l, F3.pick) 62 connector rendezvous2 P3_pick_r(P3.pick_r, F2.pick) 63 connector rendezvous3 P3_put(P3.put, F3.put, F2.put) 64 //connector single P4_think(P4.think) 65 connector single P4_eat(P4.eat) 66 connector rendezvous2 P4_pick_l(P4.pick_l, F4.pick) PhongVu_15BCNTT.KH Page 58 Studying and applying BIP Component-Framework in Software Construction and Verification 67 connector rendezvous2 P4_pick_r(P4.pick_r, F3.pick) 68 connector rendezvous3 P4_put(P4.put, F4.put, F3.put) 69 end 70 component Philos diningPhi 71 end 3.3.2 Experiments Our technique can absolutely avoid deadlock for realsystem, but the main concern is its ability to find dangerous states and change priorities given a complex system It potentially has weakness of state space explosion of model checking because of the required job to traverse backward from all deadlock states to their ancestors However, we expect that this will not pose a significant problem given the number of deadlock states and their dangerous states is much smaller than the total number of states itself To test this, we designed an experiment on known problems of Dinning Philosophers, Gas station, ATM but at a larger number of components, then measure the time a laptop can execute it For the Dinning Philosopher problem, we setup a system with 20 philosopher and another system with 100 philosophers For the Gas station problem, we setup a system with customers x pumpers and another system with customers and pumpers, for these numbers are closer to real life situation For the ATM problem, since it is a very complicated system compare to Gas station and Dinning Philosopers, we only setup a system of ATMs The test has shown that this system alone has 423 priorities to alter After properly setting up the experiment, we ran it and the results are as below: Example Size #Priority Time Dinning Philo 20 philos 40 1s Dinning Philo 100 philos 200 5s PhongVu_15BCNTT.KH Page 59 Studying and applying BIP Component-Framework in Software Construction and Verification Gas Station 4C x 2P 24 3s Gas Station 6C x 3P 57 220s ATM ATMs 423 250s By far, the explosion of space for complicated examples such as ATM increase the number of Priorities quite fast, thus increasing the time in total However, the number of priorities does not always reflect the time it takes to complete the experiment We observed that Gas station with only 57 priorities takes much more time (220s) than Dinning Philoshopers wih 200 priorities (5s) This is because of the complexity of Gas station example compare to Dinning philosopher, as shown in previous sections This imposes a weakeness of this approach, which is the time it takes to fully discover dangerous states of a complex system However, given enough time and resource, it still can finish the job and thus, still is a viable method to discover and avoid deadlocks We plan to add more experiments in the future to test our technique PhongVu_15BCNTT.KH Page 60 Studying and applying BIP Component-Framework in Software Construction and Verification CONCLUSION AND PERSPECTIVE Constructing correct systems is always an essential requirement for engineers However with the growing demand of the complexity and of the size of systems, it becomes more and more difficult to build correctly a system with respect to its specification The violation of some property in systems, especially in critical systems, might cost expensively Therefore the check of correctness is essential to guarantee the correct behavior of the system In this thesis, we describe and introduce BIP modeling language for componentbased system verification BIP provides a useful modeling perspective of the system with several properties that developers can exploit and improve their systems in designing phase Along with BIP, we also introduced D-Finder, a tool to check Deadlock freedom of systems written in BIP D-Finder uses a compositional verification method IT is based on the the use of two kinds of invariants: component invariants which approximate reachable states of atomic components and interaction invariants which characterize global constraints induced by strong synchronizations between atomic components We later proposed a new technique ultilizing the result of checking safety properties of component-based systems described in the BIP language There is one key issues in the application of the compositional verification method for checking safety properties Real life systems might be overly complex and just checking their safety properties using invariant might not be very useful Developers are likely to encounter system bugs in their design, thus they need a fail-safe technique to avoid the bug, such as deadlock, in execution time To demonstrate our technique, we illustrated several non-trivial examples with deadlock states and Dangerous states Those examples prove that our technique can successfully prevent the deadlock execution path and avoid it for the whole system We then fully implemented our technique and test it on our extended examples to PhongVu_15BCNTT.KH Page 61 Studying and applying BIP Component-Framework in Software Construction and Verification test it scalability Although it needs further improvement in Dangerous-states discovering time, the results are promising PhongVu_15BCNTT.KH Page 62 Studying and applying BIP Component-Framework in Software Construction and Verification REFERENCES Joseph Sifakis, Marius Bozga, Saddek Bensalem, Thanh-Hung Nguyen (2010), Compositional Verification for Component-based Systems and Application IET Software Journal, Special Issue on Automated Compositional Verification, Volume 4, Issue 3, Pages 181-193 Félix Ingrand, Imen Kahloul, Matthieu Gallien, Saddek Bensalem, Thanh-Hung Nguyen (2009), Designing autonomous robots, Special Issue on Software Engineering for Robotics of the IEEE Robotics and Automation Magazine, Volume 16, Issue 1, Pages 67-77 Axel Legay, Joseph Sifakis, Marius Bozga, Rongjie Yan, Saddek Bensalem, Thanh-Hung Nguyen (2010), Incremental Component-based Construction and Verification using Invariants In FMCAD’10, 10th International Conference on Formal Methods in Computer Aided Design Axel Legay, Joseph Sifakis, Rongjie Yan, Saddek Bensalem, Thanh-Hung Nguyen (2010), Incremental Invariant Generation for Compositional Design In TASE’10, 4th IEEE International Symposium on Theoretical Aspects of Software Engineering, Pages 157-167 Joseph Sifakis, Marius Bozga, Saddek Bensalem, Thanh-Hung Nguyen (2009), D-Finder: A Tool for Compositional Deadlock Detection and Verification In CAV’09 21st International Conference on Computer Aided Verification, Pages 614619 Joseph Sifakis, Marius Bozga, Saddek Bensalem, Thanh-Hung Nguyen (2008): Compositional Verification for Component-based Systems and Application In ATVA’08, 6th International Symposium on Automated Technology for Verification and Analysis, Pages 64-79 Ananda Basu, Charles Lesire, Félix Ingrand, Joseph Sifakis, Matthieu Gallien, Saddek Bensalem, Thanh-Hung Nguyen (2008), Incremental Component-based PhongVu_15BCNTT.KH Page 63 Studying and applying BIP Component-Framework in Software Construction and Verification Construction and Verification of a Robotic System In ECAI’08, 18th European Conference on Artificial Intelligence, Pages 631-635 D.E Long, E.M Clarke, O Grumberg (1994), Model checking and abstraction, ACM Transactions on Programming Languages and Systems 16, no 5, 1512 – 1542 Edmund M Clarke, Doron A Peled, Orna Grumberg (1999), Model checking, The MIT Press 10 A Basu, J Sifakis, M Bozga (2006), Modeling heterogeneous real-time components in BIP, International Conference on Software Engineering and Formal Methods (SEFM) 11 Nguyen, T H (2010) Constructive verification for component-based systems (Doctoral dissertation, Institut National Polytechnique de Grenoble-INPG) PhongVu_15BCNTT.KH Page 64 ... BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI - Vũ Minh Phong NGHIÊN CỨU VÀ ỨNG DỤNG CÔNG CỤ BIP TRONG PHÁT TRIỂN VÀ KIỂM CHỨNG PHẦN MỀM Chuyên ngành : CÔNG NGHỆ THÔNG... of the system 1.4 BIP Tool-Chain The BIP tool-chain provides a set of tools for the modeling, the execution, the verification and the static transformation of BIP models Figure BIP Tool-Chain The... textually a system in BIP language – A compiler, for generating a BIP model from BIP description source – A code generator, for generating, from a model, C++ code executable on the BIP engine The code-generator