I have to use Alloy in a Requirements Analysis and Specification Document for a university project. I started with the easy stuff, only signatures and no facts. These are the signatures I use:
abstract sig Date{
year: one Int,
month: one Int,
day: one Int
}
abstract sig Time{
h: one Int,
m: one Int,
s: one Int
}
abstract sig Double{
leftPart: one Int,
rightPart: one Int
}
abstract sig Bool{
value: one String
}
sig DateBirth extends Date{}
sig DateRide extends Date{}
sig DateExpiry extends Date{}
abstract sig User {
email: one String,
name: one String,
surname: one String,
gender: one Bool,
address: one String,
password: one String,
dateOfBirth: one DateBirth,
IDRide: set Ride
}
sig TaxiDriver extends User{
taxiLicense: one String,
personalLicense: one String,
IBAN: one String,
positionInQueue: lone Int,
IDTaxi: set Taxi
}
sig Client extends User{
}
sig Zone {
numberOfZone: one Int,
vertexNorthWest: one Double,
vertexNorthEast: one Double,
vertexSouthWest: one Double,
vertexSouthEast: one Double,
currentQueue: set TaxiDriver
}
sig Taxi {
IDTaxi: one String,
plate: one String,
availablePlaces: one Int,
}
sig Ride {
IDRide: one String,
origin: one String,
destination: one String,
dateOfRide: one DateRide,
timeOfDeparture: one Time,
timeOfArrival: one Time,
price: one Double,
numberOfPeople: one Int,
accepted: one Bool,
userEmail: set User
}
sig Credit_Card {
number: Double,
owner: String,
expiryDate: DateExpiry,
ownerEmail: one Client
}
Then, I added the predicate "show" to veify whether the it is consistent or not:
pred Show{}
run Show for 10
After running "Execute" on Alloy Analyzer 4.2 this is the message I get:
Executing "Run Show for 10"
Solver=sat4j Bitwidth=4 MaxSeq=7 SkolemDepth=1 Symmetry=20
21067 vars. 3840 primary vars. 37164 clauses. 376ms.
Instance. found. Predicate is consistent. 375ms.
No problems, right? But then, when I click on "Show" there are no instances of the signature "User" (and its child signatures) shown on the display, while all the others are there. I tried to click on "Next" a gazillion times to try to see if maybe I could find a model in which they were shown, but there weren't any.
Any idea/suggestion? Thanks!
It's probably because of the use of String. As far as I know, String is a reserved word in Alloy, but it is not really implemented at this point. Try to remove the String fields or replace them with something else.
On a more general note, Alloy is not so much about modelling real data (ints, bools and strings), but more about modelling structure, i.e. relationships between entities. For the analysis of structure, you usually don't need concrete data types.
The purpose of building an Alloy model is to capture the essence of a design or system and explore subtle properties. You don't want to include all the details you'd find in a database schema. Your model has lots of implementation details too, such as the ids (which aren't needed since they're implicit in the object identities), and the use of strings instead of conceptual types -- destination, eg, should have a type such as "Location".
So I'd recommend that you start again, and think first about what kinds of questions you'd like this model to answer.
Thanks to everyone, removing strings solved the problem.
However, my "distorted" vision about Alloy's purpose was due to the fact that we were asked to use it but we weren't given a real explanation on how to use it, in most examples all details were written. I guess I'll have to try and study it a bit more!
Related
I have been doing an intense - yet basic apparently - study on structs in these last days and one of the things I cannot understand is why one would ever name parameters in an initializer differently from their original name.
I know that is possible, that it is allowed but, in practice, I have always seen shadowing instead.
For example:
struct Person {
var name: String
var age: Int
init(firstName: String, ancientness: Int) {
self.name = firstName
self.age = ancientness
}
}
Apart from the absurd fun one would have in inventing idiotic names, is there a truly practical reason why one would ever do such a thing?
Thank you
The short answer is no. The long answer is when creating a custom structure you don't even have to provide a custom initializer. The struct will provide it for you. Not related to your question but you should always declare your properties as constants. If you need a different value create a new structure with the values updated from the old instance. Just create a "plain" structure:
struct Person {
let name: String
let age: Int
}
This will provide a the default initializer with the following signature:
Person.init(name: String, age: Int)
If you were gonna provide yourself the same initializer for that structure it would be written as:
init(name: String, age: Int) {
self.name = name
self.age = age
}
the final thoughts
There is no reason to do such thing. You should keep your initializers names matching the name of the properties that they will be assigned to. The only "advantage" of choosing a different name is not having to explicitly call self inside the initializer.
In your example it would suffice
init(firstName: String, ancientness: Int) {
name = firstName
age = ancientness
}
but not on mine
init(name: String, age: Int) {
name = name // Cannot assign to value: 'name' is a 'let' constant
age = age // Cannot assign to value: 'name' is a 'let' constant
}
A Truly practical reason?
The only one I can see is dropping the self which can already be done 99% of the time already when coding in Swift. I actually like a lot to use the shadowing whenever it is possible in all of my answers. You can see it at this post Swift Array instance method drop(at: Int) where a local var indexshadowing the collection method index<T: Comparable>(_ T, offsetBy: T, limitedBy: T).
Or at this post Swift: second occurrence with indexOf a classic shadowing example
var startIndex = self.startIndex
Where you can refer to startIndex local method variable or the collection's instance property adding the self prefix self.startIndex.
I have a grammar that looks like
A:
...
B:
...
I want to be able to give each element of type B some serial ID. So every time that the grammar creates a B object, it gets a (unique) new ID as a field.
I tried to do something like:
B:
myID=Tracer.getID()
...
where:
class Tracer {
static int ID=0;
static int getID() { return ID++;}
But I can't call external java class from the grammar.
It would be better if it's solvable without touching the src-gen files.
Thanks.
Are you aware that in textual models, there is no such thing as object identity? I.e. you fundamentally can't say that any two objects in different ASTs are identical. You can only establish an interpretation of equivalence using diff algorithms.
That aside, if you only need a temporary identity, what about using Object.hashCode()?
I have a signature
sig Test {
a: Int,
b: Int,
c: Int
}
If I have two instances (atoms?) of this ( x,y:Test )
can I define a relation between these where only some parameters has changed without having to list all the other parameters as equal?
I want to avoid having to list all unchanged fields
as this can be error-prone assuming I have many fields.
Currently I am using x.(a+b+c) = y.(a+next[b]+c) but would like to use something like x = y ++ (b->next[y.b])
from what I understand about Alloy I think the answer is No: you cannot talk about all relations where some atom is involved in without explicitly naming these relations. But some experts may correct me if I'm wrong.
How to use String in Alloy?
What kind of function or operators for String are supported in Alloy?
I searched questions here and find String is a keyword in Alloy.
But I cannot find any reference about how to use String in Alloy.
Could you give one? If not, is possible to give a brief about String in Alloy?
You can actually use strings in Alloy, but only as literals to specify constant values (i.e., no string operations are supported, and Alloy does not implement a string solver). That said, the main use of strings is Alloy is to assign constant string literals to some fields for the sole purpose of making the generated instances more readable when visualized. Here is a simple example
sig Person {
name: String,
email: String
}
one sig P1 extends Person {} {
name = "Joe"
email = "joe#email.com"
}
run {
some p: Person | p.name != "Joe"
}
The Alloy 4 grammar allows signature declarations (and some other things) to carry a private keyword. It also allows Allow specifications to contain enumeration declarations of the form
enum nephews { hughie, louis, dewey }
enum ducks { donald, daisy, scrooge, nephews }
The language reference doesn't (as far as I can tell) describe the meaning of either the private keyword or the enum construct.
Is there documentation available? Or are they in the grammar as constructs that are reserved for future specification?
This is my unofficial understanding of those two keywords.
enum nephews { hughie, louis, dewey }
is semantically equivalent to
open util/ordering[nephews] as nephewsOrd
abstract sig nephews {}
one sig hughie extends nephews {}
one sig louis extends nephews {}
one sig dewey extends nephews {}
fact {
nephewsOrd/first = hughie
nephewsOrd/next = hughie -> louis + louis -> dewey
}
The private keyword means that if a sig has the private attribute, its label is private within the same module. The same applies for private fields and private functions.
In addition to the previous accepted answer, I'd like to add some useful insights coming from a one-week experience with Alloy on enums, in particular on the main differences with standard sig.
If you use abstract sig + extend, you'll come up with a model in which there are many sets corresponding to the same concept. Maybe an example could clarify it better.
Suppose somthing like
sig Car {
dameges: set Damage
}
You have the choice to use
abstract sig Damage {}
sig MajorDamage, MinorDamage extends Damage {}
vs
enum Damage {
MajorDamage, MinorDamage
}
In the first case we can come up wiht a model with different MinorDamage atoms (MinorDamage0, MinorDamage1, ...) associatet to Cars, while in the second case you always have only one MinorDamage to which different Cars can refer.
It could have some sense in this case to use an abstract sig + extend form (because you can decide to track different MinorDamage or MajorDamage elements).
On the other hand, if you want to have a currentState: set State, it could be better to use an
enum State {Damaged, Parked, Driven}
to map the concept, in order to have exactly three State to which each Car can refer to. In this way, in the Visualizer, you can decide to project your model on exactly one of the states and it will highlight all the Cars associated to this state. You can't do that with the abstract + extend construct, of course, because projecting over MajorDamage0 will highlight only the Car associated to that Damage and nothing else.
So, in conclusion, it really depends on what you have to do.
Also, keep in mind that if you have an enum composed by X elements and execute
run some_predicate for Y
where Y < X, Alloy produces no instance at all.
So, in our last example, we can't have a Y < 3.
As a last note, enums don't always appear in the Visualizer if you use the Magic Layout button, but as I said previously you can "project" your model over the enum and switch between the different elements of the enum.