I am a beginner in Alloy (The Modelling Language made by MIT). I am trying to model the leasing of a 2 bedroom apartment in Alloy. I am trying to add a fact such that the number of people in each leased apartment is not more than 4. However the instance generated on running, still shows only one 2 bedroom leased apartment having 10 occupants. What am I doing wrong? Also if possible could someone point to some good resources on learning Alloy apart from the tutorial on the MIT website? Thanks.
abstract sig apartment {}
sig twoLeased extends apartment {
occupants: some People
} { #occupants < 5 }
sig twoUnleased extends apartment {
}
sig People {}
run {} for 3 but 4 twoLeased, 10 People
By default the bit width used to represent integers is 4 so your instance contains integers ranging from -8 to 7. In an instance where the number of occupant is 10, an integer overflow thus occur (as 10>8), #occupants returning a negative number it is thus inferior to 5 hence satisfying your invariant.
To fix this issue, you can either forbid integer overflow in the Alloy Analyzer settings or increase the bit width used to represent integers (e.g. run {} for 6 Int).
Related
my code is this:
but when I execute this.it show me only one house and one mohre.
what should I do???
abstract one sig board{}
sig mohre {live:one state }
sig house extends board{ver:one Int,hor:one Int,mo: mohre }
enum state{alive,dead}
run{#house>10 and #mohre>8}
Your run does not specify a scope. The default scope is 3 atoms of each sig and 16 integers ([-8..7]).
The US of cardinality 10 is therefore out if scope. Basically those models are in lala land. If you lower the cardinality or increase the scope things should work.
run{#house>10 and #mohre>8} for 12 but 5 int
This command allows 12 atoms of all types and has 32 integers. Weirdly, the integers are specified by their bit width and 5 bits gives you 32 values.
Additionally, you put a constraint on the abstract sig one board. Remove the one since that prevents a solution with more than one house.
(a) If there are 6 authors, what's the minimum and the maximum number of books? What's the minimum and the maximum number of readers?
(b) If there are 6 readers, what's the minimum and the maximum number of books? What's the minimum and the maximum number of authors?
If you don't know the exact numbers, just create an instance diagram according to the class diagram. I'll show you the a) part of the questions. Minimum: You've got six authors, so draw six objects typed by an Author. Every author must have at least one book. So draw one object typed by a Book. Well, every book can have up to two authors. Well, draw two links between the book and two authors. You still have 4 authors without a book. Repeat the steps above. You will end up with 3 books and 6 links. As for the Readers: there is no need do have one connected with a book. So the minimum is zero. If you did it well you should have something like this:
The similar way you do with the maximum. You will ended up with this:
So now you are able to do the b) part of your question.
Page 137 of the book Software Abstractions has these remarkable statements:
Integers are actually not very useful. If you think you need them,
think again; there is often a more abstract description that matches
the properties better. Just because integers appear in the problem
domain does not mean that they should be modeled as such. To figure
out whether integers are necessary, ask yourself what properties are
actually relied upon. For example, a communication protocol that
numbers its messages may rely only on the numbers being distinct; or
it may rely on them increasing; or perhaps even being totally ordered.
In none of these cases should integers be used.
Wow!
This is important. I want to deeply understand this.
To help me understand, I created two versions of the communication protocol.
The first version uses the Int datatype:
sig Message {
number: Int
}
The second version does not:
sig Message {
number: Number
}
sig Number {}
Is the second version more abstract? How is it more abstract? Is it more abstract because Number is not tied to a datatype? The first version is less abstract because it specifies a datatype (Int)?
Are datatypes the enemy of abstraction?
No, the second is no better. Suppose your messages aren't totally ordered, but are just partially ordered. Then the point is that rather than assigning an index to each message, you'd do better to make explicit the partial ordering on messages:
sig Message {follows: set Message, ...}
The following model is ok, Alloy finds instances.
abstract sig A{}
sig B extends A{}
sig C extends A{}
run {} for 1 but exactly 1 B, exactly 1 C
That makes me understand that the scope is not limited by the top-level signature A, but by its extensions, B and C.
However, I have a large model (no sense posting it here) that can only be satisfied with the scope of 14. With a scope of 13 the analyzer finds no instances.
When I analyze the instance found, using the evaluator to request 'univ', I get a solution that has about 5 atoms of each signature. Only the top-level abstract signatures have 14 atoms.
Am I missing something about scope? Does it affect something else besides the signatures (such as predicates)? Does it behave differently than what I assumed with the toy example?
Why won't my model simulate with a scope of 5?
edit:
here is my model if anyone is interested in taking a look. It is the result of model transformation, that's why legibility is an issue http://pastebin.com/17Z00wV4
edit2:
the predicate below works. If I run the predicate for 5 but don't specify the other ranges explicitly, it doesn't find instances.
run story3 for 5 but exactly 4 World, exactly 4 kPerson,
exactly 0 kSoftwareTool, exactly 1 kSourceCode,
exactly 1 kDocument, exactly 1 kDiagram, exactly 3 kChange,
exactly 1 kProject, exactly 2 coBranch, exactly 1 coRepository,
exactly 3 modeConfiguration, exactly 2 modeAtomicVersion,
exactly 2 relatorChangeRequest, exactly 0 relatorVerification,
exactly 1 relatorCheckIn, exactly 1 relatorCheckOut,
exactly 2 relatorConfigurationSelection,
exactly 1 relatorModification,
exactly 0 relatorRequestEvaluation, exactly 2 relatorMarkup
this one does not (it's the same predicate, but without the "exactly" keywords
run story3 for 5 but exactly 4 World, 4 kPerson, 1 kSourceCode,
1 kDocument, 1 kDiagram, 3 kChange, 1 kProject, 2 coBranch,
1 coRepository, 3 modeConfiguration, 2 modeAtomicVersion,
2 relatorChangeRequest, 1 relatorCheckIn, 1 relatorCheckOut,
2 relatorConfigurationSelection, 1 relatorModification,
2 relatorMarkup
I was told Alloy would find any possible instances within the defined scope so
run story3 for 5
should work too!
If each of the signature extending another one have a well defined scope, (it is the case for the small exemple you gave, then the the analyzer is "smart enough" to understand that the scope of the top level signature is at least equal to the some of the scopes of the signatures partitionning it.
In the case now you do not give any scopes to specific signatures, I assume that the analyzer won't be able to process the scope of the top signature as detailed bellow, the top level signature hence will have as scope the global one you gave.
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? Unintended?) Is util/ordering intended to be applied only to top-level signatures?
Or is there something else going on that I am missing?
In the model from this this is abstracted, I'd really like to have a name like A for the union of B and C, and I'd really like C to be ordered, and I'd really like B to be unordered and non-empty. At the moment, I seem to able to achieve any two of those goals; is there a way to manage all three at the same time?
[Addendum: I notice that specifying run show for 3 but 3 B, 3 C does achieve my three goals. By contrast, run show for 2 but 3 B produces no instances at all. Perhaps I need to understand the semantics of scope specifications better.]
Short answer: the phenomena reported result from the rules for default and implicit scopes; those rules are discussed in section B.7.6 of the Language Reference.
Longer answer:
The eventual suspicion that I should look at the semantics of scope specifications more closely proved to be warranted. In the example shown here, the rules work out exactly as documented:
For run show for 7, signature A has a default scope of 7; so do B and C. The use of the util/ordering module forces the number of C atoms to 7; that also exhausts the quota for signature A, which leaves signature B with an implicit scope of 0.
For run show for 2 but 3 B, signature A has a default scope of 2, and B has an explicit scope of 3. This leaves signature C with an implicit signature of 2 minus 3, or negative 1. That appears to count as an inconsistency; scope bounds are expected to be natural numbers.
For run show for 2 but 3 B, 3 C, signature A gets an implicit bound of 6 (the sum of its subsignatures' bounds).
As a way of gaining a better understanding of the scope rules, it proved useful to this user to execute all of the following commands:
run show for 3
run show for 3 but 2 C
run show for 3 but 2 B
run show for 3 but 2 B, 2 C
run show for 3 but 2 A
run show for 3 but 2 A, 2 C
run show for 3 but 2 A, 2 B
run show for 3 but 2 A, 2 B, 2 C
I'll leave this question in place for other answers and in the hope that it may help some other users.
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.
The reason is that when forcing an ordered sig to contain as many atoms as the scope allows it is possible for the translator to generate an efficient symmetry breaking predicate, which, in most examples with ordered sigs, results in much better solving time. So it is simply a trade-off, and the design decision was to enforce this extra constraint in order to gain performance.