Tablebased Software Designs: Bounded Model Checking and Counterexample Tracking


 Spencer Hensley
 2 years ago
 Views:
Transcription
1 Tablebased 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 programlike languages such as the Promela language for the wellknown model checker Spin. To promote practical use of model checking techniques in onsite software development, we realized, however, that graphicalized modeling languages (e.g., representatively, UML) are more easily acceptable compared to modelcheckerspecific programlike formal description languages. In this paper, we propose a model checking technique for software designs developed in a tablebased 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 onsite software engineers. Keywords: State Transition Matrix, Bounded Model Checking, SMT Solving, Counterexample Tracking 1. Introduction State Transition Matrix (STM) is a tablebased 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 rowcolumn 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 subsystems as a STM and the subsystem 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 modelbased 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. userspecified 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 Spinlike model checkers, engineers have to redescribe the (parts of the) system (which could be a design, source codes, or others) to be checked with a modelcheckerspecific description language, in the Spin case, Promela. This redescription process is errorprone and thus it is nontrivial to guarantee the consistency between the original system and the redescribed one. CBMClike 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 onsite software development could be checked by Garakabu2 just as they are, and thus engineers do not need to learn a second modelchecker 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 MoneyChanger 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 onsite software development. The rest of the paper is organized as follows. Section 2 introduces the tablebased 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 tablebased language STM that uses sharedvariable as the means of communication, whereas interested readers are referred to [6] for its formal definitions. A simplified MoneyChanger 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 leftmost 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 eventstatus 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 xchangeprepareidle 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 subcells if conditions are defined to further restrict STM s behavior, as of the case x10kyenrequestwait_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 takenwait_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 explicitbased ones similar to those of SPIN. Basic idea of explicitbased 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 stateexplosion 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 SMTbased 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 nonlogical 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 quantifierfree 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 andconjunction 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 orconjunction 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 xchangeprepareidle 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 userspecified LTL property into a logical formula. The formula is then input into a stateoftheart 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 xchangeprepareidel, and Lhs or Rhs denotes the concrete subcell 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 onsite software engineers.
5 Fig. 4: Highlevel 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 onsite software development. 4.1 Input Tablebased 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 nontrivial, 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 redescribed 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 onsite 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 tablebased feature of the STM language also makes itself easier to master compared to programlike model description languages usually used by most of stateoftheart model checkers. Figure 4 shows a highlevel 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 subprocess 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 topleft of Figure 5). Users of Garakabu2 could click each segment of the sequence (possibly from top to bottom), and such clickactivities 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 subfigure in the bottomright 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 tablebased 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 onsite 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 nonintuitive 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 domainspecific 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 multicore processors and largescale 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 , AddisonWesley, [4] E. Clarke, D. Kroening, and F. Lerda, A Tool for Checking ANSIC 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 SMTbased Approach to Bounded Model Checking of Designs in State Transition Matrix, To appear in IEICE Transactions on Information and Systems, 94D(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 TKKICSR14, 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 FiniteState 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 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 informationFormal 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) PIPSC 4 2.
More informationSystem 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 AntiPatterns: How to Avoid the Common Traps of Business Process Modeling, J Koehler, J Vanhatalo, IBM Zürich, 2007.
More informationhttp://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 informationTesting 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, FIN02015 HUT, Finland
More informationUsing 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 812007 Using Patterns and Composite Propositions to Automate the Generation of Complex
More informationToday 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 informationThe Model Checker SPIN
The Model Checker SPIN Author: Gerard J. Holzmann Presented By: Maulik Patel Outline Introduction Structure Foundation Algorithms Memory management Example/Demo SPINIntroduction Introduction SPIN (Simple(
More informationA 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 informationModel Checking: An Introduction
Announcements Model Checking: An Introduction Meeting 2 Office hours M 1:30pm2:30pm W 5:30pm6:30pm (after class) and by appointment ECOT 621 Moodle problems? Fundamentals of Programming Languages CSCI
More informationTemporal 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 informationQuick Start Guide. June 3, 2012
The ERIGONE Model Checker Quick Start Guide Mordechai (Moti) BenAri Department of Science Teaching Weizmann Institute of Science Rehovot 76100 Israel http://stwww.weizmann.ac.il/gcs/benari/ June 3, 2012
More informationA Static Analyzer for Large SafetyCritical Software. Considered Programs and Semantics. Automatic Program Verification by Abstract Interpretation
PLDI 03 A Static Analyzer for Large SafetyCritical 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 informationThe 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 informationTesting XPath Queries using Model Checking
Testing XPath Queries using Model Checking Claudio de la Riva, Javier Tuya, José GarcíaFanjul Computer Science Department, University of Oviedo Phone +34 98 518 26 64, Fax +34 98 518 21 56 [claudio tuya
More informationFormal 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 informationContextBounded Model Checking of LTL Properties for ANSIC Software. Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole
ContextBounded Model Checking of LTL Properties for ANSIC Software Jeremy Morse, Lucas Cordeiro, Bernd Fischer, Denis Nicole Model Checking C Model checking: normally applied to formal state transition
More informationFormal 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 informationModel Checking based Software Verification
Model Checking based Software Verification 18.52006 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 informationFundamentals 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 informationBounded 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 information5 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 informationlogic 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 informationLecture 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 informationTool 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 informationModel 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 informationDevelopment of dynamically evolving and selfadaptive software. 1. Background
Development of dynamically evolving and selfadaptive software 1. Background LASER 2013 Isola d Elba, September 2013 Carlo Ghezzi Politecnico di Milano DeepSE Group @ DEIB 1 Requirements Functional requirements
More informationBuilding SMTbased Software Model Checkers: an Experience Report
Building SMTbased Software Model Checkers: an Experience Report Alessandro Armando Artificial Intelligence Laboratory (AILab) Dipartimento di Informatica Sistemistica e Telematica (DIST) University of
More informationStatic 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 informationThe 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 informationArchitectural Design
Software Engineering Architectural Design 1 Software architecture The design process for identifying the subsystems making up a system and the framework for subsystem control and communication is architectural
More informationOn the Modeling and Verification of SecurityAware and ProcessAware Information Systems
On the Modeling and Verification of SecurityAware and ProcessAware Information Systems 29 August 2011 What are workflows to us? Plans or schedules that map users or resources to tasks Such mappings may
More informationStylianos 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 informationModelChecking Verification for Reliable Web Service
ModelChecking Verification for Reliable Web Service Shin NAKAJIMA Hosei University and PRESTO, JST nkjm@i.hosei.ac.jp Abstract Modelchecking is a promising technique for the verification and validation
More informationCoverability 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 informationSoftware 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 informationAutomated Route Planning for MilkRun 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 MilkRun Transport Logistics with
More informationINF5140: 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 informationAn eclipsebased Feature Models toolchain
An eclipsebased 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 informationFundamentals 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 informationA 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 informationnpsolver 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.tudresden.de
More informationFrom 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 informationToward ModelBased Verification of Adaptive Allocation Managers
Toward ModelBased 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 informationLecture 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 informationA Classification of Model CheckingBased Verification Approaches for Software Models
Volt Second Workshop on Verification Of Model Transformations, 2013, A Classification of Model CheckingBased Verification Approaches for Software Models Sebastian Gabmeyer a Petra Brosch a Martina Seidl
More informationPRACTICE 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 fulllength GRE Computer Science Test testtaking
More informationVHDL 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 informationSOFTWARE 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 modelbased development tools is changing the costbenefit
More informationNew 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 information2 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 informationModeling 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 informationVeriTech  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 informationAUTOMATIC 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 informationReading 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 informationInvGen: An Efficient Invariant Generator
InvGen: An Efficient Invariant Generator Ashutosh Gupta and Andrey Rybalchenko Max Planck Institute for Software Systems (MPISWS) Abstract. In this paper we present InvGen, an automatic linear arithmetic
More informationLumousoft 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 highlevel graphical programming language and its IDE (Integration
More informationAccess 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 informationDiPro  A Tool for Probabilistic Counterexample Generation
DiPro  A Tool for Probabilistic Counterexample Generation Husain Aljazzar, Florian LeitnerFischer, Stefan Leue, and Dimitar Simeonov University of Konstanz, Germany Abstract. The computation of counterexamples
More informationIntroducing 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 informationFormal 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 informationA 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 ITCIRST, Povo, Trento, Italy. cimatti@itc.it
More informationUnderstanding Primary Children s Thinking and Misconceptions
Presentation Title Understanding Primary Children s Thinking and Misconceptions in Decimal Numbers Format Paper Session [ 8.01 ] Subtheme Assessment and Student Achievement Understanding Primary Children
More informationOverview 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 informationThe 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 informationAnnouncements. 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]
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 informationCPS122 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 informationTEACHING 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 informationModeling 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, GerhardStallingStraße
More informationSOFTWARE DEVELOPMENT LANGUAGES AND ENVIRONMENTS
HIGHER COMPUTING SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT LANGUAGES AND ENVIRONMENTS PROCEDURAL, DECLARATIVE AND EVENTDRIVEN LANGUAGES 1. A program contains the following statement: is_a(rover,dog).
More informationPGR 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 informationA 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 informationAn 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 informationValidated 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 informationModel 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 informationDeveloping Touchless Interfaces with GestIT
Developing Touchless Interfaces with GestIT Lucio Davide Spano ISTICNR 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 informationExploring Patterns and Functions
Technology and other electronic media have become popular with students of all ages. Game programs, virtualreality helmets, and online environments are just some of the electronic tools that fascinate
More informationFormal 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 information12 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 informationRepresentation of Data
Representation of Data In contrast with higherlevel programming languages, C does not provide strong abstractions for representing data. Indeed, while languages like Racket has a rich notion of data type
More informationML 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 informationMore 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 informationModel 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 information7.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 informationWEB 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 informationAttaining 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 (email: domen.verber@unimb.si) Abstract:
More informationPythagorean 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 informationFormal Verification of Software
Formal Verification of Software Sabine Broda Department of Computer Science/FCUP 12 de Novembro de 2014 Sabine Broda (DCCFCUP) Formal Verification of Software 12 de Novembro de 2014 1 / 26 Formal Verification
More informationSoftware 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 informationC++ 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 informationAlgorithms, 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 informationSCHOOL 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 informationDesign 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 informationInteger 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 informationControlflowbased Coverage Criteria
Controlflowbased Coverage Criteria W. Eric Wong Department of Computer Science The University of Texas at Dallas ewong@utdallas.edu http://www.utdallas.edu/~ewong Dataflowbased Coverage Criteria ( 2012
More informationContextBounded Model Checking of LTL Properties for ANSIC Software
ContextBounded Model Checking of LTL Properties for ANSIC Software Jeremy Morse 1, Lucas Cordeiro 2, Denis Nicole 1, Bernd Fischer 1 1 Electronics and Computer Science, University of Southampton, UK
More informationSoftware Modeling and Verification
Software Modeling and Verification Alessandro Aldini DiSBeF  Sezione STI University of Urbino Carlo Bo Italy 34 February 2015 Algorithmic verification Correctness problem Is the software/hardware system
More information6 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 information6.5. Loglinear Graphs. Introduction. Prerequisites. Learning Outcomes. Learning Style
Loglinear 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