Testing versus instance generation

Slides:



Advertisements
Similar presentations
Semantics Static semantics Dynamic semantics attribute grammars
Advertisements

Annoucements  Next labs 9 and 10 are paired for everyone. So don’t miss the lab.  There is a review session for the quiz on Monday, November 4, at 8:00.
ISBN Chapter 3 Describing Syntax and Semantics.
Planning systems and its’ applications in software engineering Saša Tošić, M. Ivanović Risan, 2007.
Towards a Lightweight Model of BGP Safety Matvey Arye Princeton University Joint work with: Rob Harrison, Richard Wang, Jennifer Rexford (Princeton) Pamela.
Software Requirements
1 درس مهندسي نيازمندي استاد دكتر عبداله زاده دانشجو خيرالنسا مرچانت Meaning of Requirement.
Four Dark Corners of Requirements Engineering
1 Advanced Material The following slides contain advanced material and are optional.
Describing Syntax and Semantics
How do you find out... Think of the various ways that you find out about a new product. Finding out about new products...
What Exactly are the Techniques of Software Verification and Validation A Storehouse of Vast Knowledge on Software Testing.
Computer Science 340 Software Design & Testing Design By Contract.
A Z Approach in Validating ORA-SS Data Models Scott Uk-Jin Lee Jing Sun Gillian Dobbie Yuan Fang Li.
Proof Carrying Code Zhiwei Lin. Outline Proof-Carrying Code The Design and Implementation of a Certifying Compiler A Proof – Carrying Code Architecture.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Mobile Agent Security Presented By Sayuri Yonekawa October 17, 2000.
Author: Alex Groce, Daniel Kroening, and Flavio Lerda Computer Science Department, Carnegie Mellon University Pittsburgh, PA Source: R. Alur and.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
Concepts and Realization of a Diagram Editor Generator Based on Hypergraph Transformation Author: Mark Minas Presenter: Song Gu.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Lecture 15 Page 1 CS 236 Online Evaluating Running Systems Evaluating system security requires knowing what’s going on Many steps are necessary for a full.
Of 29 lecture 15: description logic - introduction.
What is a software? Computer Software, or just Software, is the collection of computer programs and related data that provide the instructions telling.
Introduction to Problem Solving Programming is a problem solving activity. When you write a program, you are actually writing an instruction for the computer.
Abstraction and Abstract Interpretation. Abstraction (a simplified view) Abstraction is an effective tool in verification Given a transition system, we.
Model Checking Early Requirements Specifications in Tropos Presented by Chin-Yi Tsai.
International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Model-based Systems Engineering (MBSE) Initiative Ontology Action Team INCOSE MBSE Workshop.
LB160 (Professional Communication Skills For Business Studies)
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVII. Verification and Validation.
WP4 Models and Contents Quality Assessment
A Review of Software Testing - P. David Coward
Using Human Errors to Inspect SRS
PREPARED BY G.VIJAYA KUMAR ASST.PROFESSOR
CS223: Software Engineering
Databases We are particularly interested in relational databases
LPV: a new technique, based on linear programming, to formally prove or disprove safety properties J-L Lambert, valiosys.
Karen Wickett School of Information University of Texas at Austin
ece 720 intelligent web: ontology and beyond
LAE Assessment My Course Was Selected For LAE Assessment Reporting.
Great Theoretical Ideas in Computer Science
Different Types of Testing
Chapter 8 – Software Testing
Constraints in Entity-Relationship Models
Automated Pattern Based Mobile Testing
Software Quality Engineering CS- 449
The Ontological Argument Ontological
Formulating a research question
Knowledge Representation
LEQ: How do I organize a response to a LEQ?
Counseling with Depth of Knowledge
Aspect Validation: Connecting Aspects and Formal Methods
Testing and Test-Driven Development CSC 4700 Software Engineering
Model the non-negative even integers
Each hotel guest has a set of keys and no two guests have the same key
Use Alloy to model and find a solution to the Farmer, Goat, Cabbage, and Wolf problem Roger L. Costello July 14, 2018.
Welcome to Corporate Training -1
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Software Verification, Validation, and Acceptance Testing
Depth and Complexity Icons
Institute of Computing Tech.
Validity and Reliability II: The Basics
State Machines 6-Apr-196-Apr-19.
Chen Li Information and Computer Science
Overview of Workflows: Why Use Them?
Introducing the Math Icons TK – 3rd
Evaluating Classifiers
Computer Science 340 Software Design & Testing
When, What, Why create system and software models
Presentation transcript:

Testing versus instance generation Roger L. Costello April 22, 2018

Traditional software development Create software. Create tests. Execute software on tests. Evaluate the test results. If any tests failed, then modify the software and goto step 1.

Alloy development Create model. Have the Alloy Analyzer generate instances. Examine the instances. Are the instances the kind of instances that I expect? If no, modify the model and goto step 2.

Testing vs instance generation You (a human) create the instance (test) and then see if it satisfies the constraints described by the software (i.e., you run the test on the software). With Alloy, the instances are automatically generated by the Alloy Analyzer (a machine) from the model. You examine the instances to see if it is the kind of instance you expect.

Testing vs instance generation (cont.) With traditional software development, tests represent what you meant for the software to say. By executing the tests on the software you see if the software means what you think it means. “This is what I meant to say, did I actually say that?” Alloy instances show you what you said in the model. You examine the instances and decide if that’s what you meant for the model to say. “This is what you said, is that what you meant to say?”

Peter Kriens says … The key reason to create instances of models is to show where you still misunderstand the problem. I’ve come to the conclusion that Alloy is more a specification tool than anything else. I heavily use it to understand a problem domain. The task of modeling something you don’t understand is the most valuable part of Alloy. I’ve probably got hundreds of unfinished models on my computer because once I understood the problem the need disappeared to model it …

Yes, you described in your own words the difference between validation (did i build the right thing) and verification (did i build it right). While "testing" as you named it, is used to verify that the software has been built correctly, Alloy can IMHO be used both for validation and verification, as explained in the following: Validation: Instance generation from an empty predicate gives you instances conforming to your specification allowing you to have a grasp on what you have specified. You can use the knowledge gained from reviewing those instances to validate your specification. Indeed, those instances will help you answer the question: Are the generated instances mirroring what I meant to specify? (did I build the right thing). Verification In Alloy, you can also verify that certain property are respected in your specification through the use of assertions. Checking assertions yields existing counter examples that, when existing, disprove the compliance of your specification to the violated assertion. If any, the counter-examples generated from checking assertion help you answer the question: Did I specify my model correctly w.r.t. my assertions? (did I build it right?). Loïc Gammaitoni