alloy

I have the following Alloy module and run command: sig A { x : set A } run {all a: A| #a.x<3 and #a.x>1} for exactly 2 A, 2 int With "Forbid Overflow: No" the Alloy Analyzer 4.2 (Build date: 2012-09-25) does not find an instance. I believe the reason is that due to the overflow of the constant 3 the run predicate reads {all a: A| #a.x<-1 and #a.x>1} . With "Forbid Overflow: Yes" the Alloy Analyzer finds an instance. ---INSTANCE--- integers={-2, -1, 0, 1} univ={-1, -2, 0, 1, A$0, A$1} Int={-1, -2, 0, 1} seq/Int={0} String={} none={} this/A={A$0, A$1} this/A<:x={A$0->A$0, A$0->A$1, A$1->A$0, A$1

I have been interested in formal methods for some time. I have used formal methods to reason about some very specific sub-areas of a few projects I have been working on. I was never able to convince other team members to try the same let alone specify an entire domain with a formal method. One method I have found particularly interesting is Alloy . I think that it may "scale" better as foundation for an entire project because it is conceptually and notationally very close to actual programming languages. Furthermore, the tools are quite solid so that the benefits of model verification are

When debugging a perplexing problem in Alloy, I've used the evaluator to do 3 > 10 and get the result true . Am I missing something?! C. M. Sperberg-McQueen Alloy integers are typically very narrow by normal standards, and they normally have a sort of 'wraparound' semantics. In the default scope, in Alloy 4.2 Int ranges from -8 to 7, and literal 8, 9, 10 are indistinguishable from literal -8, -7, -6. (The use of out-of-range values like literal 10 cannot be detected statically, because in principle Alloy models can be infinite; the size of Int is not known statically. It is known dynamically,

Consider the following Alloy model: open util/ordering[C] abstract sig A {} sig B extends A {} sig C extends A {} pred show {} run show for 7 I understand why, when I run show for 7 , all the instances of this model have 7 atoms of signature C. (Well, that's not quite true. I understand that the ordered signature will always have as many atoms as the scope allows, because util/ordering tells me so. But that's not quite the same as why .) But why do no instances of this model have any atoms of signature B? Is this a side-effect of the special handling performed for util/ordering? (Intended?

I'm currently using the Alloy Analyzer API to build a program, and getting some peculiar behavior. Specifically, if I open a file and parse it (using CompUtil.parseEverything), then make a new Command and call TranslateAlloyToKodkod.execute_command on the parsed file and newly created command using MiniSat with UNSAT core, it runs fine. However, later in execution, my program parses a second input file (also using CompUtil.parseEverything), gets another world, makes a new command, and then I try to call TranslateAlloyToKodkod.execute_command again, it throws the following error: ERROR: class