fbpx
Wikipedia

Alloy (specification language)

In computer science and software engineering, Alloy is a declarative specification language for expressing complex structural constraints and behavior in a software system. Alloy provides a simple structural modeling tool based on first-order logic.[1] Alloy is targeted at the creation of micro-models that can then be automatically checked for correctness. Alloy specifications can be checked using the Alloy Analyzer.

Although Alloy is designed with automatic analysis in mind, Alloy differs from many specification languages designed for model-checking in that it permits the definition of infinite models. The Alloy Analyzer is designed to perform finite scope checks even on infinite models.

The Alloy language and analyzer are developed by a team led by Daniel Jackson at the Massachusetts Institute of Technology in the United States.

History and influences edit

The first version of the Alloy language appeared in 1997. It was a rather limited object modeling language. Succeeding iterations of the language "added quantifiers, higher arity relations, polymorphism, subtyping, and signatures".[2]

The mathematical underpinnings of the language were heavily influenced by the Z notation, and the syntax of Alloy owes more to languages such as Object Constraint Language.

The Alloy Analyzer edit

 
Alloy Analyzer.

The Alloy Analyzer was specifically developed to support so-called "lightweight formal methods". As such, it is intended to provide fully automated analysis, in contrast to the interactive theorem proving techniques commonly used with specification languages similar to Alloy. Development of the Analyzer was originally inspired by the automated analysis provided by model checkers. However, model-checking is ill-suited to the kind of models that are typically developed in Alloy, and as a result the core of the Analyzer was eventually implemented as a model-finder built atop a boolean SAT solver.[1]

Through version 3.0, the Alloy Analyzer incorporated an integral SAT-based model-finder based on an off-the-shelf SAT-solver. However, as of version 4.0 the Analyzer makes use of the Kodkod model-finder, for which the Analyzer acts as a front-end. Both model-finders essentially translate a model expressed in relational logic into a corresponding boolean logic formula, and then invoke an off-the-shelf SAT-solver on the boolean formula. In the event that the solver finds a solution, the result is translated back into a corresponding binding of constants to variables in the relational logic model.[3]

In order to ensure the model-finding problem is decidable, the Alloy Analyzer performs model-finding over restricted scopes consisting of a user-defined finite number of objects. This has the effect of limiting the generality of the results produced by the Analyzer. However, the designers of the Alloy Analyzer justify the decision to work within limited scopes through an appeal to the small scope hypothesis: that a high proportion of bugs can be found by testing a program for all test inputs within some small scope.[4]

Model structure edit

Alloy models are relational in nature, and are composed of several different kinds of statements:[1]

  • Signatures define the vocabulary of a model by creating new sets
sig Object{} defines a signature Object
sig List{ head : lone Node } defines a signature List that contains a field head of type Node and multiplicity lone - this establishes the existence of a relation between Lists and Nodes such that every List is associated with no more than one head Node
  • Facts are constraints that are assumed to always hold
  • Predicates are parameterized constraints, and can be used to represent operations
  • Functions are expressions that return results
  • Assertions are assumptions about the model

Because Alloy is a declarative language the meaning of a model is unaffected by the order of statements.

References edit

  1. ^ a b c Jackson, Daniel (2006). Software Abstractions: Logic, Language, and Analysis. MIT Press. ISBN 978-0-262-10114-1.
  2. ^ . Archived from the original on 7 June 2007. Retrieved 7 March 2013.
  3. ^ Torlak, E.; Dennis, G. (April 2008). (PDF). First ACM Alloy Workshop. Portland, Oregon. Archived from the original (PDF) on 22 June 2010. Retrieved 19 April 2009.
  4. ^ Andoni, Alexandr; Daniliuc, Dumitru; Khurshid, Sarfraz; Marinov, Darko (2002). "Evaluating the small scope hypothesis". CiteSeerX 10.1.1.8.7702.

External links edit

  • Alloy website
  • Alloy Github Repository
  • Guide to Alloy
  • at MIT

alloy, specification, language, computer, science, software, engineering, alloy, declarative, specification, language, expressing, complex, structural, constraints, behavior, software, system, alloy, provides, simple, structural, modeling, tool, based, first, . In computer science and software engineering Alloy is a declarative specification language for expressing complex structural constraints and behavior in a software system Alloy provides a simple structural modeling tool based on first order logic 1 Alloy is targeted at the creation of micro models that can then be automatically checked for correctness Alloy specifications can be checked using the Alloy Analyzer Although Alloy is designed with automatic analysis in mind Alloy differs from many specification languages designed for model checking in that it permits the definition of infinite models The Alloy Analyzer is designed to perform finite scope checks even on infinite models The Alloy language and analyzer are developed by a team led by Daniel Jackson at the Massachusetts Institute of Technology in the United States Contents 1 History and influences 2 The Alloy Analyzer 3 Model structure 4 References 5 External linksHistory and influences editThe first version of the Alloy language appeared in 1997 It was a rather limited object modeling language Succeeding iterations of the language added quantifiers higher arity relations polymorphism subtyping and signatures 2 The mathematical underpinnings of the language were heavily influenced by the Z notation and the syntax of Alloy owes more to languages such as Object Constraint Language The Alloy Analyzer edit nbsp Alloy Analyzer The Alloy Analyzer was specifically developed to support so called lightweight formal methods As such it is intended to provide fully automated analysis in contrast to the interactive theorem proving techniques commonly used with specification languages similar to Alloy Development of the Analyzer was originally inspired by the automated analysis provided by model checkers However model checking is ill suited to the kind of models that are typically developed in Alloy and as a result the core of the Analyzer was eventually implemented as a model finder built atop a boolean SAT solver 1 Through version 3 0 the Alloy Analyzer incorporated an integral SAT based model finder based on an off the shelf SAT solver However as of version 4 0 the Analyzer makes use of the Kodkod model finder for which the Analyzer acts as a front end Both model finders essentially translate a model expressed in relational logic into a corresponding boolean logic formula and then invoke an off the shelf SAT solver on the boolean formula In the event that the solver finds a solution the result is translated back into a corresponding binding of constants to variables in the relational logic model 3 In order to ensure the model finding problem is decidable the Alloy Analyzer performs model finding over restricted scopes consisting of a user defined finite number of objects This has the effect of limiting the generality of the results produced by the Analyzer However the designers of the Alloy Analyzer justify the decision to work within limited scopes through an appeal to the small scope hypothesis that a high proportion of bugs can be found by testing a program for all test inputs within some small scope 4 Model structure editAlloy models are relational in nature and are composed of several different kinds of statements 1 Signatures define the vocabulary of a model by creating new sets b sig b Object defines a signature Object b sig b List head b lone b Node defines a signature List that contains a field head of type Node and multiplicity lone this establishes the existence of a relation between Lists and Nodes such that every List is associated with no more than one head Node dd Facts are constraints that are assumed to always hold Predicates are parameterized constraints and can be used to represent operations Functions are expressions that return results Assertions are assumptions about the modelBecause Alloy is a declarative language the meaning of a model is unaffected by the order of statements References edit a b c Jackson Daniel 2006 Software Abstractions Logic Language and Analysis MIT Press ISBN 978 0 262 10114 1 Alloy FAQ Archived from the original on 7 June 2007 Retrieved 7 March 2013 Torlak E Dennis G April 2008 Kodkod for Alloy Users PDF First ACM Alloy Workshop Portland Oregon Archived from the original PDF on 22 June 2010 Retrieved 19 April 2009 Andoni Alexandr Daniliuc Dumitru Khurshid Sarfraz Marinov Darko 2002 Evaluating the small scope hypothesis CiteSeerX 10 1 1 8 7702 External links editAlloy website Alloy Github Repository Guide to Alloy Kodkod analysis engine website at MIT An Alloy Metamodel in Ecore Retrieved from https en wikipedia org w index php title Alloy specification language amp oldid 1166967065, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.