Alloy: a Language and Tool for Exploring Software Designs
Total Page:16
File Type:pdf, Size:1020Kb
Alloy: a language and tool for exploring software designs The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Jackson, Daniel. “Alloy: a language and tool for exploring software designs.” Communications of the ACM, 62, 9 (September 2019): 66-76 © 2019 The Author As Published 10.1145/3338843 Publisher Association for Computing Machinery (ACM) Version Original manuscript Citable link https://hdl.handle.net/1721.1/129357 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike Detailed Terms http://creativecommons.org/licenses/by-nc-sa/4.0/ Alloy: A Language and Tool for Exploring Software Designs Daniel Jackson Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology Alloy is a language and a toolkit for ex- to be desired. It’s notoriously incomplete, cally support directly. Also, because they ploring the kinds of structures that arise and burdensome, since you need to write generate mathematical proofs, which can in many software designs. This brief arti- test cases explicitly. And it’s very hard to be checked by tools that are smaller and cle aims to give a flavor of Alloy in action, use code to articulate design without get- simpler than the tool that finds the proof, to summarize how Alloy has been used to ting mired in low level details (such as the you can be confident that the analysis is date, and thereby to give you a sense of choice of data representations). sound. how you might use it in your own soft- An alternative, which has been ex- On the other hand, the combination of ware design work. plored since the 1970s, is to use a design an expressive logic and sound proof has language built not on conventional ma- meant that finding proofs cannot gener- Formal Design Languages chine instructions but on logic. Partiality ally be automated. So theorem provers Software involves structures of many comes for free because, rather than listing usually require considerable effort and sorts: architectures, database schemas, each step of a computation, you write a expertise from the user, often orders of network topologies, ontologies, and so logical constraint saying what’s true after, magnitude greater than the effort of con- on. When you design a software system, and that constraint can say as little or as structing a formal design in the first place. you need to be able to express the struc- much as you please. To analyze such a Moreover, failure to find a proof does not tures that are essential to the design, and language, you use specialized algorithms mean that a proof does not exist, and the- to check that they have the properties you such as model checkers or satisfiability orem provers don’t provide counterexam- expect. solvers (more on these below). This usu- ples that explain concretely why a theo- You can express a structure by sketch- ally requires much less effort than test- rem is not valid. So theorem provers are ing it on a napkin. That’s a good start, but ing, since you only need to express the not so useful when the intended property it’s limited. Informal representations give property you want to check rather than a does not hold—which unfortunately is inconsistent interpretations, and they large collection of cases. And the analy- the common case in design work. can’t be analyzed mechanically. So people sis is much more complete than testing, Model checkers revolutionized design have turned to formal notations that de- because it effectively covers all (or almost analysis by providing exactly the fea- fine structure and behavior precisely and all) test cases that you could have written tures theorem provers lacked. They offer objectively, and that can exploit the pow- by hand. push-button automation, requiring the er of computation. user to give only the design and prop- What Came Before: Theorem Provers By using formality early in develop- erty to be checked. They allow dynam- and Model Checkers ment, you can minimize the costs of am- ic properties to be expressed (through biguity and get feedback on your work by To understand Alloy, it helps to know a temporal logics), and generate counter- running analyses. The most popular ap- bit about the context in which it was de- examples when properties do not hold. proach that advocates this is agile devel- veloped, and the tools that existed at the Model checkers work by exploring the opment, in which the formal representa- time. space of possible states of a system, and tion is code in a traditional programming Theorem provers are mechanical aids if that space is large, they may require language and the analysis is conventional for constructing mathematical proofs. considerable computational resources unit testing. To apply a theorem prover to a software (or may fail to terminate). The so-called As a language for exploring designs, design problem, you formulate some in- “state explosion” problem arises because however, code is imperfect. It’s verbose tended property of the design, and then model checkers are often used to analyze and often indirect, and it doesn’t allow attempt to prove the theorem that the designs involving components that run in partial descriptions in which some details property follows from the design. The- parallel, resulting in an overall state space are left to be resolved later. And testing, orem provers tend to provide very rich that grows exponentially with the number as a way to analyze designs, leaves much logics, so they can usually express any of components. property you might care about, at least Alloy was inspired by the successes and To appear, CACM about states and state transitions—more limitations of model checkers. For designs Draft of February 22, 2019 dynamic properties can require a tempo- involving parallelism and simple state ral logic that theorem provers don’t typi- (comprising boolean variables, bound- ed integers, enumerations and fixed-size Relational logic. Alloy uses the same implicit coercions or overloading to ac- arrays), model checkers were ideal. They logic for describing designs and proper- commodate variants that Alloy unifies.) could easily find subtle synchronization ties. This logic combines the for-all and Alloy was influenced also by modeling bugs that appeared only in rare scenari- exists-some quantifiers of first-order log- languages such as UML. Like the class os that involved long traces with multiple ic with the operators of set theory and re- diagrams of UML, Alloy makes it easy to context switches, and therefore eluded lational calculus. describe a universe of objects as a classi- testing. The idea of modeling software designs fication tree, with each relation defined For hardware designs, model checkers with sets and relations had been pio- over nodes in this tree. Alloy’s dot oper- were often a good match. But for software neered in the Z language [32]. Alloy in- ator was inspired in part by the naviga- designs they were less ideal. Although corporated much of the power of Z, while tional expressions of OCL (the Object some software design problems involve simplifying the logic to make it more Constraint Language [39] of UML), but this kind of synchronization, often the tractable. by defining the dot as relational join, Al- complexity arises from the structure First, Alloy allows only first-order struc- loy dramatically simplifies the semantics of the state itself. Early model checkers tures, ruling out sets of sets and relations of navigation. (such as SMV [9]) had limited expressive- over sets, for example. This changes how Small scope analysis. Even plain first-or- ness in this regard, and did not support designs are modeled, but not what can be der logic (without relational operators) is rich structures such as trees, lists, tables modeled; after all, relational databases not decidable. This means that no algo- and graphs. have flourished despite being first order. rithm can exist that could analyze a soft- Explicit state model checkers, such Second, taking advantage of this re- ware design written in a language like Al- as SPIN [14], and later Java Pathfinder striction, Alloy’s operators are defined in loy completely. So something has to give. [37], allowed designs with rich state to a very general way, so that most expres- You could make the language decidable, be modeled, but, despite providing sup- sions can be written with just a few oper- but that would cripple its expressive pow- port for temporal properties, gave little ators. The key operator is relational join, er and make it unable to express even the help for expressing structural ones. To which in conventional mathematics only most basic properties of structures (al- express reachability (for example that two applies to binary relations, but in Alloy though exciting progress has been made social media users are connected by some works on relations of any arity. By using recently in applying decidable fragments path of friend edges), you would typical- a dot to represent the join operator, Al- of first-order logic to certain problems ly need to code an explicit search, which loy lets you write dereferencing expres- [29]). You could give up on automation, would have to be executed at every point sions as you would in an object oriented and require help from the user, but this at which the property was needed. Also, programming language, but gives these eliminates most of the benefit of an analy- explicit state model checkers have limit- expressions a simple mathematical inter- sis tool; analysis is no longer a reward for ed support for partiality (since the model pretation. So, as in Java, given an employ- constructing a design model, but a major checker would have to conduct a costly ee e, a relation dept that maps employees extra investment beyond modeling.