Table-based Software Designs: Bounded Model Checking and Counterexample Tracking

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Table-based Software Designs: Bounded Model Checking and Counterexample Tracking"

Transcription

1 Table-based Software Designs: Bounded Model Checking and Counterexample Tracking Noriyuki Katahira 1, Weiqiang Kong 1, Wanpeng Qian 1, Masahiko Watanabe 2, Tetsuro Katayama 3, Akira Fukuda 4 1 Fukuoka Industry, Science & Technology Foundation, Japan, {katahira, kong, 2 CATS Co., Ltd., Japan, 3 Faculty of Engineering, University of Miyazaki, Japan, 4 Graduate School and Faculty of ISEE, Kyushu University, Japan, Abstract Model description languages used by most software model checkers are typically program-like languages such as the Promela language for the well-known model checker Spin. To promote practical use of model checking techniques in on-site software development, we realized, however, that graphicalized modeling languages (e.g., representatively, UML) are more easily acceptable compared to model-checker-specific program-like formal description languages. In this paper, we propose a model checking technique for software designs developed in a table-based description language State Transition Matrix (STM), which is commonly considered to be effective for embedded software development. In addition, we also describe our proposed approach for graphically tracking counterexamples (i.e., design errors w.r.t. specified properties) reported by model checking. Supporting both graphicalized model description and graphically counterexample tracking is believed by us to be important for enhancing usability of model checking techniques and tools for on-site software engineers. Keywords: State Transition Matrix, Bounded Model Checking, SMT Solving, Counterexample Tracking 1. Introduction State Transition Matrix (STM) is a table-based model description language. Although primarily used for software development, STM is capable to describe general automatonbased system behaviors, e.g., human s operation etc. As a basic rule, the horizontal axis of a STM table declares status that a system under consideration could be in, the vertical axis declares events that may be dispatched to the system, and a row-column intersection cell declares behaviors (actions and transition target status) of the system when a specified event is dispatched in a specified status. A whole system could be described by defining each of its sub-systems as a STM and the sub-system STMs execute in an interleaving manner and communicate through shared variables or asynchronous message passing. STM has been widely accepted and used in software industry, and thus been adopted as the model description language of some commercial model-based CASE tools such as ZIPC [1]. However, although its wide acceptance and usage, there is lack of formal verification supports for conducting rigorous analysis to improve reliability of STM designs, e.g., ZIPC provides facilities for syntactic check and test only. Therefore, we started to implement a model checking tool called Garakabu2, which could be used to formally analyze correctness of STM designs (typically consisting of multiple STMs) developed using ZIPC w.r.t. user-specified Linear Temporal Logic (LTL) properties [2]. There are quite a few model checking tools, e.g., Spin [3] and CBMC [4], available for both academic and practical industry usage. In this paper, we focus only on the latter usage, which is also the primary target of Garakabu2. We have observed through our investigation in Japanese software industry that formal verification (primarily model checking) techniques are mostly applied, so far, after the development of source codes. To employ Spin-like model checkers, engineers have to re-describe the (parts of the) system (which could be a design, source codes, or others) to be checked with a model-checker-specific description language, in the Spin case, Promela. This re-description process is error-prone and thus it is non-trivial to guarantee the consistency between the original system and the redescribed one. CBMC-like model checkers could be used directly to analyze correctness of source codes, in the CBMC case, ANSI C and C++ source codes. However, our argument is that quite a lot source code errors are due to design errors, and therefore, detecting errors in an early design phase of the software development process could greatly reduce development time and costs. Garakabu2 is built to detect software design errors. Designs developed using STM by engineers for on-site software development could be checked by Garakabu2 just as they are, and thus engineers do not need to learn a second model-checker specific description language for conducting model checking. Another feature of Garakabu2 is that the execution sequences of counterexamples (i.e., design errors) reported could be tracked graphically (in the form of table) in STMs in the ZIPC environment. Such visible execution is expected to be useful for engineers to easily understand the reasons for design errors. We believe that these two features

2 Fig. 1: A Simplified Money-Changer System (MCS) consisting of a CHANGER and a RETURNER. are effective to some extent for enhancing usability of model checking techniques and tools, and thus are helpful for promoting their practical use in on-site software development. The rest of the paper is organized as follows. Section 2 introduces the table-based language STM. Section 3 describes the key techniques for Bounded Model Checking [5] STM designs. Section 4 discusses in detail our attempts made in Garakabu2 for enhancing its usability. Section 5 mentions future work and concludes the paper. 2. State Transition Matrix (STM) We informally introduce the table-based language STM that uses shared-variable as the means of communication, whereas interested readers are referred to [6] for its formal definitions. A simplified Money-Changer System (MCS) shown in Figure 1 is used as our demonstration example. MCS consists of two components modeled as two STMs. (1) A device called CHANGER, which supplies smaller denominations when equivalent amount of money in a larger denomination is inserted. The small denominations are delivered to another device called RETURNER. (2) Device RE- TURNER receives small denominations from CHANGER and waits until they are taken. MCS is modeled in a greatly simplified means by abstracting away details irrelevant to the demonstration purpose. Additionally, we intendedly introduced design errors to the system for demonstration purpose as well, e.g., MCS s behaviors are unreasonably defined when there are not enough small denominations, which will be discussed in detail in Section 4. Taking STM CHANGER as an example. CHANGER could be in three status, i.e., IDLE, WAIT_REQUEST, and WAIT_MONEY_TAKEN with obvious meaning. Initially, all STMs are in their left-most status. Three events that are possibly dispatched to CHANGER include xchangeprepare, x10yenrequest, and taken. Events whose names are prefixed with x are called external events, and those without are called internal ones. An external event is dispatched by the environment where the system concerned resides in, and an internal event is dispatched by the execution of the system. External event xchangeprepare denotes initialization of CHANGER, external event x10yenrequest denotes a request to exchange a banknote of 10K denomination, and internal event taken denotes that banknotes of small denominations have been taken. An event-status intersection cell declares the system s behavior when the specified event is dispatched in the specified status. There are three kinds of cells in a STM: - Normal cell. A normal cell declares actions and transition target status of a STM. For example, the intersection cell xchangeprepare-idle declares that if event xchangeprepare is dispatched when CHANGER is in status IDLE, CHANGER s balance is increased by and after that it changes to status WAIT_REQUEST. A cell could be divided into sub-cells if conditions are defined to further restrict STM s behavior, as of the case x10kyenrequest-wait_request in which condition balance>=10000 is defined. - Ignore cell. An ignore cell is denoted by a / ina STM. Meaning of an ignore cell is that the dispatch of an event in a status is ignored and nothing changes. For example, the intersection cell x10kyenrequest- IDLE means intuitively that a request to exchange when CHANGER is IDLE will just be ignored. - Invalid cell. An invalid cell is denoted by a ina STM. Meaning of an invalid cell is that an event should never be dispatched in a specified status. For example, the intersection cell taken-wait_request means intuitively that the event small denominations have been taken should not be dispatched when CHANGER is waiting for a request. Regarding normal cells, instead of actions and transition target status, the name of another STM (named here as called STM) could be written in them to express that the concrete behaviors are as those defined in the called STM. STMs defined in this way is called hierarchical STMs. In this paper, we will not further discuss such kind of STMs although model checking them are supported by Garakabu2. 3. Bounded Model Checking (BMC) of STM designs with Garakabu2 The original model checking algorithms implemented in Garakabu2, as been described in [7], are explicit-based ones similar to those of SPIN. Basic idea of explicit-based algorithms is to exhaustively explore through explicit representation all reachable system states (starting from the initial one) [2]. However, concurrent software systems like STM designs generally contain tremendous number of possible interleavings of events and combinations of data values [8],

3 which usually blows up, if represented explicitly, the state space to be analyzed. Such a problem is commonly called the state-explosion problem. Satisfiability Modulo Theories (SMT) [9] based model checking techniques could attack this problem by symbolically representing and enumerating states. In this section, we describe the key techniques implemented recently in Garakabu2 for SMT-based Bounded Model Checking (BMC) of STM designs. We refer interested readers to [6] for a more formal (mathematical) description. 3.1 Encoding of STM Designs Generally speaking, SMT is a technique to determine assignments of all the variables of a given logical formula to make the formula true, or no such assignment exists. The variables can be of types (such as integer and real) that have associated theories (such as the theories of linear integer arithmetic and linear real arithmetic, respectively), in which fixed interpretations are also given to non-logical operation symbols and functions. Key idea of employing SMT techniques to conduct BMC of STM designs is to encode all execution sequences within a given bound (execution step) of a STM design, together with the negation of a LTL property to be checked, into a quantifier-free logical formula. Satisfiability of the formula is then determined by SMT solvers. If satisfied, a model of the formula (i.e., interpretation/assignments to all the state variables that make the formula true) is a witness of some bad behaviors (i.e., design errors) of the STM design that violate the LTL property. Since only bounded behaviors of the design are analyzed, this approach is primarily used for revealing design errors rather than proving their absence. Figure 2 shows the overall process of BMC of STM designs with Garakabu2. A STM design could be viewed as a transition system whose behaviors are captured by an initial system state and a set of transitions that changes system states. A system state (hereinafter called state for simplicity) is a set of (all) state variables (hereinafter called variables for simplicity) declared and used in the STM design. For the MCS shown in Figure 1, a state is composed of: {xchangeprepare : Bool, x10kyenrequest : Bool, taken : Bool, balance : Int, payment : Int, paid : Bool, xreceive : Bool, chgstatus : Int, retstatus : Int} where Bool or Int written after each variable denote the type of the variable. Note that variables chgstatus and retstatus are additional variables introduced by Garakabu2 for representing respectively the current active status of each STM, where initially both of them have the value 0. Initial values of other variables are defined in a separate file in ZIPC which are omitted in this paper. Encoding rule for the initial state is an and-conjunction of equations, each of which link a variable with its initial value. The initial state of MCS is encoded into the following formula, called initfl: Loop on Steps within Upper Bound Fig. 2: Bounded Model Checking Process of Garakabu2 xchangeprepare_0 = false x10kyenrequest_0 = false taken_0 = false balance_0 = 0 payment_0 = 0 paid_0 = false xreceive_0 = false chgstatus_0 = 0 retstatus_0 = 0 Note however that, each variable of a state is renamed by attaching to its name a suffixed index number. The reason behind is that a set of fresh/new variables is introduced for each execution step (including the step for initial state), and is used to uniquely characterize a state (or, symbolically, a set of states) when the system reaches that step. Encoding rule for each execution step within a given bound is an or-conjunction of transitions that might possibly be executed from a previous state. There are two kinds of transitions for a STM design, one corresponding to the execution of a normal cell and another corresponding to the dispatch of an external event. For the MCS shown in Figure 1, there are 7 normal (sub-)cells (named as c1 to c7) and 3 external events (named as e1 to e3). We show the encoded formula, called c1fl, for normal cell c1 xchangeprepare-idle in step 1 in the following, and the remaining cells could be encoded similarly.

4 xchangeprepare_0 = true chgstatus_0 = 0 balance_1 = balance_ chgstatus_1 = 1 xchangeprepare_1 = xchangeprepare_0 x10kyenrequest_1 = x10kyenrequest_0... retstatus_1 = retstatus_0 The two equations in the first line of c1fl characterize the execution condition, whereas equations in the remaining lines characterize the execution effects, of c1 in step 1. The condition restricts that in the previous state, i.e. the state whose variables are with index number 0, event xchangeprepare is dispatched and CHANGER is in status 0. The effects express that the values of balance and chgstatus are changed and all the other variables remain unchanged (where some equations for unchanged variables are omitted in c1fl). Next, we show the encoded formula, called e1fl, for the dispatch of external event e1 xchangeprepare in step 1 in the following, and the dispatch of the remaining external events could be encoded similarly. xchangeprepare_0 = false xchangeprepare_1 = true x10kyenrequest_1 = x10kyenrequest_0... retstatus_1 = retstatus_0 where the equation in the first line in e1fl characterizes the execution condition, and the equations in the remaining lines characterize the execution effects. Again we omitted some equations for those variables whose values are unchanged. The entire encoded formula for execution step 1, called step1fl, is written as: c1fl... c7fl e1fl... e3fl, which intuitively means that one of the normal cells or dispatch of an external event is possible to be executed in step 1 from the initial state. Formulas for other execution steps within the given bound, say k, could be encoded similarly, while note that in each step a fresh set of new variables are introduced and used. Consequentially, all the states of the execution steps within k is expressed by an andconjunction of the form initfl step1fl... stepkfl. The part of Loops on Steps within Upper Bound written in Figure 2 is processed following the way as we have just explained above. The encoding rules implemented in Garakabu2 for Linear Temporal Logical (LTL) properties are similar to the approach described in [10]. We have implemented efficient algorithms for generation of Negation Normal Form (NNF) for LTL formulas and their encoding, which will be reported in another opportunity. 3.2 BMC of STM Designs Based on the encoding approach introduced in the previous subsection, Garakabu2 encodes a STM design and negation of a user-specified LTL property into a logical formula. The formula is then input into a state-of-the-art SMT step 0 step 1 step 2 step 3 step 4 step 5 step 6 step 7 step 8 step 9 step 10 step 11 step 12 step 13 Initial state of MCS Event xchangeprepare is dispatched by the environment Cell (0,0) of CHANGER is executed Event x10kyenrequest is dispatched by the environment Lhs of Cell (1,1) of CHANGER is executed Cell (0,0) of RETURNER is executed Event xreceive is dispatched by the environment Lhs of Cell (1,1) of RETURNER is executed Cell (2,2) of CHANGER is executed Event x10kyenrequest is dispatched by the environment Rhs of Cell (1,1) of CHANGER is executed Cell (0,0) of RETURNER is executed Event xreceive is dispatched by the environment Rhs of Cell (1,1) of RETURNER is executed Fig. 3: Execution Sequence of the Counterexample w.r.t. an Invalid Cell solver CVC3 [11] that are incorporated in Garakabu2, to try to detect counterexamples (i.e., design errors) through determination of the formula s satisfiability. In this paper, we show an example LTL property that is used to check whether the invalid cell taken- WAIT_REQUEST of MCS is unreachable, i.e., whether the event taken is indeed not possible to be dispatched when CHANGER is in the status WAIT_REQUEST. The property is declared by using the LTL operator globally [2] denoted by the symbol [G] in Garakabu2 as follows: [G]( (taken = true chgstatus = 1)) which could be read intuitively as that the two equations could not hold at the same time for any executions of MCS. We input this LTL property and the STM design MCS developed using ZIPC into Garakabu2. Garakabu2 finds in 2.8 seconds a counterexample whose execution step is 13. Figure 3 shows execution sequence of the counterexample. We use event and status index numbers (listed in Figure 1) to pinpoint a cell, e.g., Cell (0,0) of CHANGER denotes the cell xchangeprepare-idel, and Lhs or Rhs denotes the concrete sub-cell of a specified cell. After observing the execution sequence in Figure 3, we could understand that the problem (error) occurs in the Cell (1, 1), which dispatches the event paid even if there is not enough balance. We therefore revised MCS by removing the second assignment of this cell and checked the LTL property again. This time no counterexample is found when the upper bound is set to 50. However, it is worth pointing out that abstracting the clear execution sequence in Figure 3 from the output (that represents a counterexample) of CVC3 is extremely cumbersome since SMT solvers including CVC3 just simply output a set of variable assignments that makes the input formula true. Due to this, understanding a counterexample becomes a tough task, especially for on-site software engineers.

5 Fig. 4: High-level Structure of Garakabu2 4. Attempts for Enhancing Usability Although formal verification techniques, especially model checking, have been broadly recognized to be effective for enhancing software reliability, they have not been adopted as a standard phase of the software development process, and the use of them in a practical setting is still rare. A significant barrier behind, as also often mentioned in the literature, is that formal verification techniques are hard to learn and apply since a sufficiently enough mathematical knowledge is required and necessary, which however, is difficult for onsite software engineers. In this paper, we focus only on model checking among other formal verification techniques. Based on our observation of Japanese software industry, the above mentioned barrier is further divided into two detailed (sub-)barriers, while one is related to the input and the other is related to the output of model checking tools. In the following, we discuss our attempts made in Garakabu2 for alleviating separately the two (sub-)barriers, which we hope to be helpful or in a direction that may be helpful for promoting practical use of model checking techniques for on-site software development. 4.1 Input Table-based STM Design Regarding input, to apply model checking techniques and tools to analyze a target design, software engineers have to firstly describe the (parts of the) design with a model description language that is specific to the model checker to be used 1. However, fully mastering a model description language is non-trivial, which consequentially makes it difficult to guarantee the consistency between the 1 Although model checkers such as CBMC are available that could be used directly to analyze software source code, we focus on model checking of software designs since we believe that quite a lot source code errors are due to design errors, as discussed in Section 1. original design and re-described one, i.e., whether the redescribed one has exactly the same semantics as the original one. To alleviate this barrier, Garakabu2 accepts as its input models the designs developed using STM for on-site software development, i.e., the STM designs could be model checked just as they are, and therefore there is no need for software engineers to learn a second model description language. In addition, we believe that the table-based feature of the STM language also makes itself easier to master compared to program-like model description languages usually used by most of state-of-the-art model checkers. Figure 4 shows a high-level component structure of Garakabu2. To conduct BMC with Garakabu2, software engineers are only responsible to develop a STM design (that is to be used for later software development), LTL properties to be checked against the design, and an upper bound number to which depth the design is to be checked. The difficult mathematical computation for BMC (the Control Component in Figure 4) like those described in Section 3 are hidden into Garakabu2. Note however that, we still provide Logging Component in Garakabu2, which registers the states and transitions information that are generated and used inside. These information could be examined by advanced users when necessary if a fully understanding on how Garakabu2 works for their problems. The output and display components are to be discussed in the next subsection. 4.2 Output Counterexample Tracking Regarding output, as been discussed in Section 3, abstracting a clear execution sequence from the output of SMT solvers that represents a counterexample is extremely cumbersome. Therefore, understanding a counterexample and consequentially why a design error occurs, also becomes a tough task for software engineers.

6 Fig. 5: Graphically Counterexample Tracking with Garakabu2 and ZIPC To alleviate this barrier, we implemented in Garakabu2 an output component that computes the execution sequences of counterexamples from CVC3 s results (sets of variable assignments), and a display component that displays graphically (in the form of table) the execution sequences in STM designs (tables) in the ZIPC environment. Figure 5 shows the process of graphically tracking the execution sequences of counterexamples, where the subprocess to the left shows the activities executed by Garakabu2 and the sub-process to the right shows the activities executed by ZIPC environment. When Garakabu2 discovered a counterexample through BMC, the execution sequence of the counterexample is computed and listed in Garakabu2 s output interface (as shown in the lower part of the subfigure in the top-left of Figure 5). Users of Garakabu2 could click each segment of the sequence (possibly from top to bottom), and such click-activities are converted into ZIPC recognizable commands and transferred to ZIPC. ZIPC then receives and parses these commands and highlight the corresponding event or cell of a STM by changing its color, indicating the event or cell executed in that clicked execution step (as shown in the sub-figure in the bottom-right of Figure5). In addition, all the variables defined and used by users in the STM design, together with their respective values in each execution step, are listed in Garakabu2 s output interface. Such a graphical tracking functionality is believed by us to be greatly helpful for users of Garakabu2 (software engineers) to understand the exact reasons of counterexamples. 5. Conclusions and Future Work In this paper, we have introduced the BMC techniques implemented in Garakabu2 for model checking of software designs developed using a table-based language STM. Additionally, our attempts for enhancing the usabilities of model checking techniques in general and Garakabu2 in particular have also been described. The effectiveness of formal verification techniques for enhancing software reliability has been recognized broadly and the importance of them has been recently stressed again in international standards such as IEC61508 [12] and ISO26262 [13]. We believe that visibility is a key issue for usability. Based on this view point, we expect that our work could be helpful to some extent for promoting the practical use of formal verification techniques in on-site software development and finally making it become a standard phase of software development process. There are still quite a lot to be done as future work. The precise meaning of LTL formulas is commonly known to be non-intuitive and can confound even the experts [3]. Therefore specifying properties to be checked with LTL can be hard for software engineers. We are currently developing in Garakabu2 a graphical editor that could help software engineers specify LTL properties with a set of predefined, often-

7 used, and domain-specific property patterns [14], and/or with a set of graphical notations for LTL operators [15]. In addition, to make it possible for BMC to find counterexamples of deep execution steps, i.e., expand the state space that could be checked, we are currently investigating approaches that could take advantages of recent advances of multi-core processors and large-scale computing clusters (including distributed data processing technique/framework Hadoop etc). Acknowledgment This research is conducted as a program for the Regional Innovation Cluster (Global Type, the 2nd Stage)" by Ministry of Education, Culture, Sports, Science and Technology (MEXT), Japan. We would like to thank all relevant organizations and people for their support. References [1] CATS Co., Ltd., Japan, ZIPC Version 9.2. URL: [2] E. M. Clarke, O. Grumberg, and D. A. Peled, Model Checking, MIT Press, [3] G. Holzmann, The SPIN Model Checker: Primer and Reference Manual, ISBN , Addison-Wesley, [4] E. Clarke, D. Kroening, and F. Lerda, A Tool for Checking ANSI-C Programs, In TACAS 2004, LNCS 2988, pp , Springer, [5] A. Biere, A. Cimatti, E.M. Clarke and Y. Zhu, Symbolic Model Checking without BDDs, In TACAS 1999, LNCS 1579, pp , Springer, [6] W. Kong, T. Shiraishi, N. Katahira, M. Watanabe, T. Katayama, A. Fukuda, An SMT-based Approach to Bounded Model Checking of Designs in State Transition Matrix, To appear in IEICE Transactions on Information and Systems, 94-D(5), [7] T. Shiraishi, W. Kong, Y. Mizushima, N. Katahira, M. Matsumoto, M. Watanabe, T. Katayama, A. Fukuda, Model Checking of Software Design in State Transition Matrix, In SERP 2010, pp , [8] J. Dubrovin. Checking bounded reachability in asynchronous systems by symbolic event tracing. Technical Report TKK-ICS-R14, Helsinki University of Technology, [9] C. Barrett, R. Sebastiani, S. Seshia, and C. Tinelli, Satisfiability Modulo Theories, In Book: Handbook of Satisfiability. Edited by A. Biere, M. Heule, H. Maaren, and T. Walsh, ISBN , IOS Press, [10] T. Latvala, A. Biere, K. Heljanko, and T. Junttila, Simple Bounded LTL Model Checking, In FMCAD 2004, LNCS 3312, pp , Springer, [11] C. Barrett and C. Tinelli, CVC3, In CAV 2007, LNCS 4590, pp , Springer, [12] Association, International Standard for Electrical, Electronic and Programmable Electronic Safety related Systems, URL: [13] IOS, Road vehicles Functional Safety (under development), URL: [14] M. Dwyer, G. Avrunin, J. Corbett, Patterns in Property Specifications for Finite-State Verification, In ICSE 1998, pp , ACM, [15] S. Koike, S. Yoshida, and H. Ohsaki, Diagrammatic Notation for LTL Model Checking, In FOSE 2007, pp , 2007.

Formal Verification by Model Checking

Formal Verification by Model Checking Formal Verification by Model Checking Natasha Sharygina Carnegie Mellon University Guest Lectures at the Analysis of Software Artifacts Class, Spring 2005 1 Outline Lecture 1: Overview of Model Checking

More information

Formal Specification and Verification

Formal Specification and Verification Formal Specification and Verification Stefan Ratschan Katedra číslicového návrhu Fakulta informačních technologíı České vysoké učení technické v Praze 2. 5. 2011 Stefan Ratschan (FIT ČVUT) PI-PSC 4 2.

More information

System modeling. Budapest University of Technology and Economics Department of Measurement and Information Systems

System modeling. Budapest University of Technology and Economics Department of Measurement and Information Systems System modeling Business process modeling how to do it right Partially based on Process Anti-Patterns: How to Avoid the Common Traps of Business Process Modeling, J Koehler, J Vanhatalo, IBM Zürich, 2007.

More information

http://aejm.ca Journal of Mathematics http://rema.ca Volume 1, Number 1, Summer 2006 pp. 69 86

http://aejm.ca Journal of Mathematics http://rema.ca Volume 1, Number 1, Summer 2006 pp. 69 86 Atlantic Electronic http://aejm.ca Journal of Mathematics http://rema.ca Volume 1, Number 1, Summer 2006 pp. 69 86 AUTOMATED RECOGNITION OF STUTTER INVARIANCE OF LTL FORMULAS Jeffrey Dallien 1 and Wendy

More information

Testing LTL Formula Translation into Büchi Automata

Testing LTL Formula Translation into Büchi Automata Testing LTL Formula Translation into Büchi Automata Heikki Tauriainen and Keijo Heljanko Helsinki University of Technology, Laboratory for Theoretical Computer Science, P. O. Box 5400, FIN-02015 HUT, Finland

More information

Using Patterns and Composite Propositions to Automate the Generation of Complex LTL

Using Patterns and Composite Propositions to Automate the Generation of Complex LTL University of Texas at El Paso DigitalCommons@UTEP Departmental Technical Reports (CS) Department of Computer Science 8-1-2007 Using Patterns and Composite Propositions to Automate the Generation of Complex

More information

Today s Agenda. Automata and Logic. Quiz 4 Temporal Logic. Introduction Buchi Automata Linear Time Logic Summary

Today s Agenda. Automata and Logic. Quiz 4 Temporal Logic. Introduction Buchi Automata Linear Time Logic Summary Today s Agenda Quiz 4 Temporal Logic Formal Methods in Software Engineering 1 Automata and Logic Introduction Buchi Automata Linear Time Logic Summary Formal Methods in Software Engineering 2 1 Buchi Automata

More information

The Model Checker SPIN

The Model Checker SPIN The Model Checker SPIN Author: Gerard J. Holzmann Presented By: Maulik Patel Outline Introduction Structure Foundation Algorithms Memory management Example/Demo SPIN-Introduction Introduction SPIN (Simple(

More information

A Logic Approach for LTL System Modification

A Logic Approach for LTL System Modification A Logic Approach for LTL System Modification Yulin Ding and Yan Zhang School of Computing & Information Technology University of Western Sydney Kingswood, N.S.W. 1797, Australia email: {yding,yan}@cit.uws.edu.au

More information

Model Checking: An Introduction

Model Checking: An Introduction Announcements Model Checking: An Introduction Meeting 2 Office hours M 1:30pm-2:30pm W 5:30pm-6:30pm (after class) and by appointment ECOT 621 Moodle problems? Fundamentals of Programming Languages CSCI

More information

Temporal Logics. Computation Tree Logic

Temporal Logics. Computation Tree Logic Temporal Logics CTL: definition, relationship between operators, adequate sets, specifying properties, safety/liveness/fairness Modeling: sequential, concurrent systems; maximum parallelism/interleaving

More information

Quick Start Guide. June 3, 2012

Quick Start Guide. June 3, 2012 The ERIGONE Model Checker Quick Start Guide Mordechai (Moti) Ben-Ari Department of Science Teaching Weizmann Institute of Science Rehovot 76100 Israel http://stwww.weizmann.ac.il/g-cs/benari/ June 3, 2012

More information

A Static Analyzer for Large Safety-Critical Software. Considered Programs and Semantics. Automatic Program Verification by Abstract Interpretation

A Static Analyzer for Large Safety-Critical Software. Considered Programs and Semantics. Automatic Program Verification by Abstract Interpretation PLDI 03 A Static Analyzer for Large Safety-Critical Software B. Blanchet, P. Cousot, R. Cousot, J. Feret L. Mauborgne, A. Miné, D. Monniaux,. Rival CNRS École normale supérieure École polytechnique Paris

More information

The ProB Animator and Model Checker for B

The ProB Animator and Model Checker for B The ProB Animator and Model Checker for B A Tool Description Michael Leuschel and Michael Butler Department of Electronics and Computer Science University of Southampton Highfield, Southampton, SO17 1BJ,

More information

Testing XPath Queries using Model Checking

Testing XPath Queries using Model Checking Testing XPath Queries using Model Checking Claudio de la Riva, Javier Tuya, José García-Fanjul Computer Science Department, University of Oviedo Phone +34 98 518 26 64, Fax +34 98 518 21 56 [claudio tuya

More information

Formal verification of contracts for synchronous software components using NuSMV

Formal verification of contracts for synchronous software components using NuSMV Formal verification of contracts for synchronous software components using NuSMV Tobias Polzer Lehrstuhl für Informatik 8 Bachelorarbeit 13.05.2014 1 / 19 Problem description and goals Problem description

More information

Context-Bounded Model Checking of LTL Properties for ANSI-C Software. Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole

Context-Bounded Model Checking of LTL Properties for ANSI-C Software. Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole Context-Bounded Model Checking of LTL Properties for ANSI-C Software Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole Model Checking C Model checking: normally applied to formal state transition

More information

Formal Verification Coverage: Computing the Coverage Gap between Temporal Specifications

Formal Verification Coverage: Computing the Coverage Gap between Temporal Specifications Formal Verification Coverage: Computing the Coverage Gap between Temporal Specifications Sayantan Das Prasenjit Basu Ansuman Banerjee Pallab Dasgupta P.P. Chakrabarti Department of Computer Science & Engineering

More information

Model Checking based Software Verification

Model Checking based Software Verification Model Checking based Software Verification 18.5-2006 Keijo Heljanko Keijo.Heljanko@tkk.fi Department of Computer Science and Engineering Helsinki University of Technology http://www.tcs.tkk.fi/~kepa/ 1/24

More information

Fundamentals of Software Engineering

Fundamentals of Software Engineering Fundamentals of Software Engineering Model Checking with Temporal Logic Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard Bubel, Reiner

More information

Bounded LTL Model Checking with Stable Models

Bounded LTL Model Checking with Stable Models Under consideration for publication in Theory and Practice of Logic Programming 1 Bounded LTL Model Checking with Stable Models KEIJO HELJANKO and ILKKA NIEMELÄ Helsinki University of Technology Department

More information

5 Program Correctness

5 Program Correctness 5 Program Correctness 5.1. Introduction For any application, the designer of a distributed system has the responsibility of certifying the correctness of the system, before users start using it. This guarantee

More information

logic language, static/dynamic models SAT solvers Verified Software Systems 1 How can we model check of a program or system?

logic language, static/dynamic models SAT solvers Verified Software Systems 1 How can we model check of a program or system? 5. LTL, CTL Last part: Alloy logic language, static/dynamic models SAT solvers Today: Temporal Logic (LTL, CTL) Verified Software Systems 1 Overview How can we model check of a program or system? Modeling

More information

Lecture 9 verifying temporal logic

Lecture 9 verifying temporal logic Basics of advanced software systems Lecture 9 verifying temporal logic formulae with SPIN 21/01/2013 1 Outline for today 1. Introduction: motivations for formal methods, use in industry 2. Developing models

More information

Tool Support for Model Checking of Web application designs *

Tool Support for Model Checking of Web application designs * Tool Support for Model Checking of Web application designs * Marco Brambilla 1, Jordi Cabot 2 and Nathalie Moreno 3 1 Dipartimento di Elettronica e Informazione, Politecnico di Milano Piazza L. Da Vinci,

More information

Model Checking of Software

Model Checking of Software Model Checking of Software Patrice Godefroid Bell Laboratories, Lucent Technologies SpecNCheck Page 1 August 2001 A Brief History of Model Checking Prehistory: transformational programs and theorem proving

More information

Development of dynamically evolving and self-adaptive software. 1. Background

Development of dynamically evolving and self-adaptive software. 1. Background Development of dynamically evolving and self-adaptive software 1. Background LASER 2013 Isola d Elba, September 2013 Carlo Ghezzi Politecnico di Milano Deep-SE Group @ DEIB 1 Requirements Functional requirements

More information

Building SMT-based Software Model Checkers: an Experience Report

Building SMT-based Software Model Checkers: an Experience Report Building SMT-based Software Model Checkers: an Experience Report Alessandro Armando Artificial Intelligence Laboratory (AI-Lab) Dipartimento di Informatica Sistemistica e Telematica (DIST) University of

More information

Static Program Transformations for Efficient Software Model Checking

Static Program Transformations for Efficient Software Model Checking Static Program Transformations for Efficient Software Model Checking Shobha Vasudevan Jacob Abraham The University of Texas at Austin Dependable Systems Large and complex systems Software faults are major

More information

The Course. http://www.cse.unsw.edu.au/~cs3153/

The Course. http://www.cse.unsw.edu.au/~cs3153/ The Course http://www.cse.unsw.edu.au/~cs3153/ Lecturers Dr Peter Höfner NICTA L5 building Prof Rob van Glabbeek NICTA L5 building Dr Ralf Huuck NICTA ATP building 2 Plan/Schedule (1) Where and When Tuesday,

More information

Architectural Design

Architectural Design Software Engineering Architectural Design 1 Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural

More information

On the Modeling and Verification of Security-Aware and Process-Aware Information Systems

On the Modeling and Verification of Security-Aware and Process-Aware Information Systems On the Modeling and Verification of Security-Aware and Process-Aware Information Systems 29 August 2011 What are workflows to us? Plans or schedules that map users or resources to tasks Such mappings may

More information

Stylianos Basagiannis

Stylianos Basagiannis Interlocking control by Distributed Signal Boxes Technical Report (TR) 4 Stylianos Basagiannis Supervisors: Dr Andrew Pombortsis, Dr Panagiotis Katsaros Aristotle University of Thessaloniki Department

More information

Model-Checking Verification for Reliable Web Service

Model-Checking Verification for Reliable Web Service Model-Checking Verification for Reliable Web Service Shin NAKAJIMA Hosei University and PRESTO, JST nkjm@i.hosei.ac.jp Abstract Model-checking is a promising technique for the verification and validation

More information

Coverability for Parallel Programs

Coverability for Parallel Programs 2015 http://excel.fit.vutbr.cz Coverability for Parallel Programs Lenka Turoňová* Abstract We improve existing method for the automatic verification of systems with parallel running processes. The technique

More information

Software Engineering using Formal Methods

Software Engineering using Formal Methods Software Engineering using Formal Methods Model Checking with Temporal Logic Wolfgang Ahrendt 24th September 2013 SEFM: Model Checking with Temporal Logic /GU 130924 1 / 33 Model Checking with Spin model

More information

Automated Route Planning for Milk-Run Transport Logistics with the NuSMV Model Checker

Automated Route Planning for Milk-Run Transport Logistics with the NuSMV Model Checker IEICE TRANS. INF. & SYST., VOL.E96 D, NO.12 DECEMBER 2013 2555 PAPER Special Section on Parallel and Distributed Computing and Networking Automated Route Planning for Milk-Run Transport Logistics with

More information

INF5140: Specification and Verification of Parallel Systems

INF5140: Specification and Verification of Parallel Systems INF5140: Specification and Verification of Parallel Systems Lecture 7 LTL into Automata and Introduction to Promela Gerardo Schneider Department of Informatics University of Oslo INF5140, Spring 2007 Gerardo

More information

An eclipse-based Feature Models toolchain

An eclipse-based Feature Models toolchain An eclipse-based Feature Models toolchain Luca Gherardi, Davide Brugali Dept. of Information Technology and Mathematics Methods, University of Bergamo luca.gherardi@unibg.it, brugali@unibg.it Abstract.

More information

Fundamentals of Software Engineering

Fundamentals of Software Engineering Fundamentals of Software Engineering Model Checking with Temporal Logic Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard Bubel, Reiner

More information

A Model Checking Example

A Model Checking Example DISTRIBUTION STATEMENT A Approved for Public Release. Distribution is unlimited. Ref: LM Aero PIRA AER200910006 A Model Checking Example Solving Sudoku Using Simulink Design Verifier A BSTRACT. This paper

More information

npsolver A SAT Based Solver for Optimization Problems

npsolver A SAT Based Solver for Optimization Problems npsolver A SAT Based Solver for Optimization Problems Norbert Manthey and Peter Steinke Knowledge Representation and Reasoning Group Technische Universität Dresden, 01062 Dresden, Germany peter@janeway.inf.tu-dresden.de

More information

From Workflow Design Patterns to Logical Specifications

From Workflow Design Patterns to Logical Specifications AUTOMATYKA/ AUTOMATICS 2013 Vol. 17 No. 1 http://dx.doi.org/10.7494/automat.2013.17.1.59 Rados³aw Klimek* From Workflow Design Patterns to Logical Specifications 1. Introduction Formal methods in software

More information

Toward Model-Based Verification of Adaptive Allocation Managers

Toward Model-Based Verification of Adaptive Allocation Managers Toward Model-Based Verification of Adaptive Allocation Managers William Leal, Frank Drews, Chang Liu, Lonnie Welch Ohio University { leal@cs.ohiou.edu, drews@ohiou.edu, changliu@cs.ohiou.edu, welch@ohio.edu

More information

Lecture 2: The Complexity of Some Problems

Lecture 2: The Complexity of Some Problems IAS/PCMI Summer Session 2000 Clay Mathematics Undergraduate Program Basic Course on Computational Complexity Lecture 2: The Complexity of Some Problems David Mix Barrington and Alexis Maciel July 18, 2000

More information

A Classification of Model Checking-Based Verification Approaches for Software Models

A Classification of Model Checking-Based Verification Approaches for Software Models Volt Second Workshop on Verification Of Model Transformations, 2013, A Classification of Model Checking-Based Verification Approaches for Software Models Sebastian Gabmeyer a Petra Brosch a Martina Seidl

More information

PRACTICE BOOK COMPUTER SCIENCE TEST. Graduate Record Examinations. This practice book contains. Become familiar with. Visit GRE Online at www.gre.

PRACTICE BOOK COMPUTER SCIENCE TEST. Graduate Record Examinations. This practice book contains. Become familiar with. Visit GRE Online at www.gre. This book is provided FREE with test registration by the Graduate Record Examinations Board. Graduate Record Examinations This practice book contains one actual full-length GRE Computer Science Test test-taking

More information

VHDL Test Bench Tutorial

VHDL Test Bench Tutorial University of Pennsylvania Department of Electrical and Systems Engineering ESE171 - Digital Design Laboratory VHDL Test Bench Tutorial Purpose The goal of this tutorial is to demonstrate how to automate

More information

SOFTWARE MODEL CHECKING FOR AVIONICS SYSTEMS

SOFTWARE MODEL CHECKING FOR AVIONICS SYSTEMS SOFTWARE MODEL CHECKING FOR AVIONICS SYSTEMS Darren Cofer, Michael Whalen, Steven Miller Rockwell Collins, Cedar Rapids, IA Abstract The adoption of model-based development tools is changing the cost-benefit

More information

New Constructive Approach to Covert Channel Modeling and Channel Capacity Estimation

New Constructive Approach to Covert Channel Modeling and Channel Capacity Estimation 498 New Constructive Approach to Covert Channel Modeling and Channel Capacity Estimation Zhenghong Wang and Ruby B. Lee Department of Electrical Engineering, Princeton University Princeton, NJ 08544, USA

More information

2 SYSTEM DESCRIPTION TECHNIQUES

2 SYSTEM DESCRIPTION TECHNIQUES 2 SYSTEM DESCRIPTION TECHNIQUES 2.1 INTRODUCTION Graphical representation of any process is always better and more meaningful than its representation in words. Moreover, it is very difficult to arrange

More information

Modeling Guidelines Manual

Modeling Guidelines Manual Modeling Guidelines Manual [Insert company name here] July 2014 Author: John Doe john.doe@johnydoe.com Page 1 of 22 Table of Contents 1. Introduction... 3 2. Business Process Management (BPM)... 4 2.1.

More information

VeriTech - A Framework for Translating among Model Description Notations

VeriTech - A Framework for Translating among Model Description Notations Software Tools for Technology Transfer manuscript No. (will be inserted by the editor) VeriTech - A Framework for Translating among Model Description Notations Orna Grumberg and Shmuel Katz Computer Science

More information

AUTOMATIC PROTOCOL CREATION FOR INFORMATION SECURITY SYSTEM

AUTOMATIC PROTOCOL CREATION FOR INFORMATION SECURITY SYSTEM AUTOMATIC PROTOCOL CREATION FOR INFORMATION SECURITY SYSTEM Mr. Arjun Kumar arjunsingh@abes.ac.in ABES Engineering College, Ghaziabad Master of Computer Application ABSTRACT Now a days, security is very

More information

Reading 7 : Program Correctness

Reading 7 : Program Correctness CS/Math 240: Introduction to Discrete Mathematics Fall 2015 Instructors: Beck Hasti, Gautam Prakriya Reading 7 : Program Correctness 7.1 Program Correctness Showing that a program is correct means that

More information

InvGen: An Efficient Invariant Generator

InvGen: An Efficient Invariant Generator InvGen: An Efficient Invariant Generator Ashutosh Gupta and Andrey Rybalchenko Max Planck Institute for Software Systems (MPI-SWS) Abstract. In this paper we present InvGen, an automatic linear arithmetic

More information

Lumousoft Visual Programming Language and its IDE

Lumousoft Visual Programming Language and its IDE Lumousoft Visual Programming Language and its IDE Xianliang Lu Lumousoft Inc. Waterloo Ontario Canada Abstract - This paper presents a new high-level graphical programming language and its IDE (Integration

More information

Access Control Based on Dynamic Monitoring for Detecting Software Malicious Behaviours

Access Control Based on Dynamic Monitoring for Detecting Software Malicious Behaviours Access Control Based on Dynamic Monitoring for Detecting Software Malicious Behaviours K. Adi, L. Sullivan & A. El Kabbal Computer Security Research Laboratory http://w3.uqo.ca/lrsi NCAC'05 1 Motivation

More information

DiPro - A Tool for Probabilistic Counterexample Generation

DiPro - A Tool for Probabilistic Counterexample Generation DiPro - A Tool for Probabilistic Counterexample Generation Husain Aljazzar, Florian Leitner-Fischer, Stefan Leue, and Dimitar Simeonov University of Konstanz, Germany Abstract. The computation of counterexamples

More information

Introducing Formal Methods. Software Engineering and Formal Methods

Introducing Formal Methods. Software Engineering and Formal Methods Introducing Formal Methods Formal Methods for Software Specification and Analysis: An Overview 1 Software Engineering and Formal Methods Every Software engineering methodology is based on a recommended

More information

Formal Verification Methods 3: Model Checking

Formal Verification Methods 3: Model Checking Formal Verification Methods 3: Model Checking John Harrison Intel Corporation Marktoberdorf 2003 Fri 1st August 2003 (11:25 12:10) This presentation was not given in Marktoberdorf since it mostly duplicates

More information

A Simple and Flexible Way of Computing Small Unsatisfiable Cores in SAT Modulo Theories

A Simple and Flexible Way of Computing Small Unsatisfiable Cores in SAT Modulo Theories A Simple and Flexible Way of Computing Small Unsatisfiable Cores in SAT Modulo Theories Alessandro Cimatti 1, Alberto Griggio 2, and Roberto Sebastiani 2 1 ITC-IRST, Povo, Trento, Italy. cimatti@itc.it

More information

Understanding Primary Children s Thinking and Misconceptions

Understanding Primary Children s Thinking and Misconceptions Presentation Title Understanding Primary Children s Thinking and Misconceptions in Decimal Numbers Format Paper Session [ 8.01 ] Sub-theme Assessment and Student Achievement Understanding Primary Children

More information

Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification

Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification Introduction Overview Motivating Examples Interleaving Model Semantics of Correctness Testing, Debugging, and Verification Advanced Topics in Software Engineering 1 Concurrent Programs Characterized by

More information

The Trip Scheduling Problem

The Trip Scheduling Problem The Trip Scheduling Problem Claudia Archetti Department of Quantitative Methods, University of Brescia Contrada Santa Chiara 50, 25122 Brescia, Italy Martin Savelsbergh School of Industrial and Systems

More information

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions Announcements SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 Send your group

More information

[Refer Slide Time: 05:10]

[Refer Slide Time: 05:10] Principles of Programming Languages Prof: S. Arun Kumar Department of Computer Science and Engineering Indian Institute of Technology Delhi Lecture no 7 Lecture Title: Syntactic Classes Welcome to lecture

More information

CPS122 Lecture: State and Activity Diagrams in UML

CPS122 Lecture: State and Activity Diagrams in UML CPS122 Lecture: State and Activity Diagrams in UML Objectives: last revised February 14, 2012 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Demonstration

More information

TEACHING MODEL CHECKING TO UNDERGRADUATES

TEACHING MODEL CHECKING TO UNDERGRADUATES STUDIA UNIV. BABEŞ BOLYAI, INFORMATICA, Volume LV, Number 3, 2010 TEACHING MODEL CHECKING TO UNDERGRADUATES A.VESCAN AND M. FRENŢIU Abstract. The way program verification is taught in our faculty is firstly

More information

Modeling Requirements for Quantitative Consistency Analysis and Automatic Test Case Generation

Modeling Requirements for Quantitative Consistency Analysis and Automatic Test Case Generation Modeling Requirements for Quantitative Consistency Analysis and Automatic Test Case Generation Tom Bienmüller, Tino Teige, Andreas Eggers, and Matthias Stasch BTC Embedded Systems AG, Gerhard-Stalling-Straße

More information

SOFTWARE DEVELOPMENT LANGUAGES AND ENVIRONMENTS

SOFTWARE DEVELOPMENT LANGUAGES AND ENVIRONMENTS HIGHER COMPUTING SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT LANGUAGES AND ENVIRONMENTS PROCEDURAL, DECLARATIVE AND EVENT-DRIVEN LANGUAGES 1. A program contains the following statement: is_a(rover,dog).

More information

PGR Computing Programming Skills

PGR Computing Programming Skills PGR Computing Programming Skills Dr. I. Hawke 2008 1 Introduction The purpose of computing is to do something faster, more efficiently and more reliably than you could as a human do it. One obvious point

More information

A Business Process Services Portal

A Business Process Services Portal A Business Process Services Portal IBM Research Report RZ 3782 Cédric Favre 1, Zohar Feldman 3, Beat Gfeller 1, Thomas Gschwind 1, Jana Koehler 1, Jochen M. Küster 1, Oleksandr Maistrenko 1, Alexandru

More information

An Approach to Model Checking Ada Programs

An Approach to Model Checking Ada Programs An Approach to Model Checking Ada Programs José Miguel Faria 1,2, João Martins 1, and Jorge Sousa Pinto 1 1 Departamento de Informática / CCTC, Universidade do Minho, Braga, Portugal 2 Critical Software,

More information

Validated Templates for Specification of Complex LTL Formulas

Validated Templates for Specification of Complex LTL Formulas Validated Templates for Specification of Complex LTL Formulas Salamah Salamah Department of Electrical, computer, Software, and Systems Engineering Embry Riddle Aeronautical University 600 S. Clyde Morris

More information

Model Checking LTL Properties over C Programs with Bounded Traces

Model Checking LTL Properties over C Programs with Bounded Traces Noname manuscript No. (will be inserted by the editor) Model Checking LTL Properties over C Programs with Bounded Traces Jeremy Morse 1, Lucas Cordeiro 2, Denis Nicole 1, Bernd Fischer 1,3 1 Electronics

More information

Developing Touchless Interfaces with GestIT

Developing Touchless Interfaces with GestIT Developing Touchless Interfaces with GestIT Lucio Davide Spano ISTI-CNR Via G. Moruzzi 1, 56127, Pisa, Italy lucio.davide.spano@isti.cnr.it Abstract. In this paper, we report on the development of touchless

More information

Exploring Patterns and Functions

Exploring Patterns and Functions Technology and other electronic media have become popular with students of all ages. Game programs, virtual-reality helmets, and online environments are just some of the electronic tools that fascinate

More information

Formal Verification In Industry (I)

Formal Verification In Industry (I) Formal Verification In Industry (I) 1 Formal Verification In Industry (I) John Harrison Intel Corporation Formal verification Importance of hardware verification Approaches to hardware verification Combinational

More information

12 Abstract Data Types

12 Abstract Data Types 12 Abstract Data Types 12.1 Source: Foundations of Computer Science Cengage Learning Objectives After studying this chapter, the student should be able to: Define the concept of an abstract data type (ADT).

More information

Representation of Data

Representation of Data Representation of Data In contrast with higher-level programming languages, C does not provide strong abstractions for representing data. Indeed, while languages like Racket has a rich notion of data type

More information

ML for the Working Programmer

ML for the Working Programmer ML for the Working Programmer 2nd edition Lawrence C. Paulson University of Cambridge CAMBRIDGE UNIVERSITY PRESS CONTENTS Preface to the Second Edition Preface xiii xv 1 Standard ML 1 Functional Programming

More information

More Abstract Information. More Concrete Information

More Abstract Information. More Concrete Information Abstract Interpretation Sorin Lerner June 4, 2001 1 Introduction The work surveyed in class so far was not concerned with proving correctness of dataflow analyses. We saw algorithms for computing properties

More information

Model Checking for Generation of Test Suites in Software Unit Testing

Model Checking for Generation of Test Suites in Software Unit Testing Model Checking for Generation of Test Suites in Software Unit Testing Vasilios Almaliotis Panagiotis Katsaros Konstantinos Mokos Department of Informatics Aristotle University of Thessaloniki 54124 Thessaloniki,

More information

7.7 Solving Rational Equations

7.7 Solving Rational Equations Section 7.7 Solving Rational Equations 7 7.7 Solving Rational Equations When simplifying comple fractions in the previous section, we saw that multiplying both numerator and denominator by the appropriate

More information

WEB SERVICE INTERACTIONS: ANALYSIS AND DESIGN

WEB SERVICE INTERACTIONS: ANALYSIS AND DESIGN WEB SERVICE INTERACTIONS: ANALYSIS AND DESIGN Jianwen Su Tevfik Bultan Department of Computer Science University of California at Santa Barbara Xiang Fu School of Computer& Information Sciences Georgia

More information

Attaining EDF Task Scheduling with O(1) Time Complexity

Attaining EDF Task Scheduling with O(1) Time Complexity Attaining EDF Task Scheduling with O(1) Time Complexity Verber Domen University of Maribor, Faculty of Electrical Engineering and Computer Sciences, Maribor, Slovenia (e-mail: domen.verber@uni-mb.si) Abstract:

More information

Pythagorean Theorem. Overview. Grade 8 Mathematics, Quarter 3, Unit 3.1. Number of instructional days: 15 (1 day = minutes) Essential questions

Pythagorean Theorem. Overview. Grade 8 Mathematics, Quarter 3, Unit 3.1. Number of instructional days: 15 (1 day = minutes) Essential questions Grade 8 Mathematics, Quarter 3, Unit 3.1 Pythagorean Theorem Overview Number of instructional days: 15 (1 day = 45 60 minutes) Content to be learned Prove the Pythagorean Theorem. Given three side lengths,

More information

Formal Verification of Software

Formal Verification of Software Formal Verification of Software Sabine Broda Department of Computer Science/FCUP 12 de Novembro de 2014 Sabine Broda (DCC-FCUP) Formal Verification of Software 12 de Novembro de 2014 1 / 26 Formal Verification

More information

Software Active Online Monitoring Under. Anticipatory Semantics

Software Active Online Monitoring Under. Anticipatory Semantics Software Active Online Monitoring Under Anticipatory Semantics Changzhi Zhao, Wei Dong, Ji Wang, Zhichang Qi National Laboratory for Parallel and Distributed Processing P.R.China 7/21/2009 Overview Software

More information

C++ Programming: From Problem Analysis to Program Design, Fifth Edition. Chapter 2: Basic Elements of C++

C++ Programming: From Problem Analysis to Program Design, Fifth Edition. Chapter 2: Basic Elements of C++ C++ Programming: From Problem Analysis to Program Design, Fifth Edition Chapter 2: Basic Elements of C++ Objectives In this chapter, you will: Become familiar with the basic components of a C++ program,

More information

Algorithms, Flowcharts & Program Design. ComPro

Algorithms, Flowcharts & Program Design. ComPro Algorithms, Flowcharts & Program Design ComPro Definition Algorithm: o sequence of steps to be performed in order to solve a problem by the computer. Flowchart: o graphical or symbolic representation of

More information

SCHOOL OF MATHEMATICS MATHEMATICS FOR PART I ENGINEERING. Self Study Course

SCHOOL OF MATHEMATICS MATHEMATICS FOR PART I ENGINEERING. Self Study Course SCHOOL OF MATHEMATICS MATHEMATICS FOR PART I ENGINEERING Self Study Course MODULE 17 MATRICES II Module Topics 1. Inverse of matrix using cofactors 2. Sets of linear equations 3. Solution of sets of linear

More information

Design by Contract beyond class modelling

Design by Contract beyond class modelling Design by Contract beyond class modelling Introduction Design by Contract (DbC) or Programming by Contract is an approach to designing software. It says that designers should define precise and verifiable

More information

Integer Operations. Overview. Grade 7 Mathematics, Quarter 1, Unit 1.1. Number of Instructional Days: 15 (1 day = 45 minutes) Essential Questions

Integer Operations. Overview. Grade 7 Mathematics, Quarter 1, Unit 1.1. Number of Instructional Days: 15 (1 day = 45 minutes) Essential Questions Grade 7 Mathematics, Quarter 1, Unit 1.1 Integer Operations Overview Number of Instructional Days: 15 (1 day = 45 minutes) Content to Be Learned Describe situations in which opposites combine to make zero.

More information

Controlflow-based Coverage Criteria

Controlflow-based Coverage Criteria Controlflow-based Coverage Criteria W. Eric Wong Department of Computer Science The University of Texas at Dallas ewong@utdallas.edu http://www.utdallas.edu/~ewong Dataflow-based Coverage Criteria ( 2012

More information

Context-Bounded Model Checking of LTL Properties for ANSI-C Software

Context-Bounded Model Checking of LTL Properties for ANSI-C Software Context-Bounded Model Checking of LTL Properties for ANSI-C Software Jeremy Morse 1, Lucas Cordeiro 2, Denis Nicole 1, Bernd Fischer 1 1 Electronics and Computer Science, University of Southampton, UK

More information

Software Modeling and Verification

Software Modeling and Verification Software Modeling and Verification Alessandro Aldini DiSBeF - Sezione STI University of Urbino Carlo Bo Italy 3-4 February 2015 Algorithmic verification Correctness problem Is the software/hardware system

More information

6 3 4 9 = 6 10 + 3 10 + 4 10 + 9 10

6 3 4 9 = 6 10 + 3 10 + 4 10 + 9 10 Lesson The Binary Number System. Why Binary? The number system that you are familiar with, that you use every day, is the decimal number system, also commonly referred to as the base- system. When you

More information

6.5. Log-linear Graphs. Introduction. Prerequisites. Learning Outcomes. Learning Style

6.5. Log-linear Graphs. Introduction. Prerequisites. Learning Outcomes. Learning Style Log-linear Graphs 6.5 Introduction In this block we employ our knowledge of logarithms to simplify plotting the relation between one variable and another. In particular we consider those situations in

More information