The following model contains a "run" command that instructs the Alloy Analyzer to generate an instance of the relation to.address, where the relation is constrained to exactly one tuple.
sig Message {
to: Name
}
sig Name {
address: Address
}
sig Address {}
run {one to.address}
But I don't want to constrain the to.address relation. I would like to simply write this:
run {to.address}
Hey Alloy Analyzer, generate an instance of the relation to.address
Executing that run command results in this error message: {to.address} must be a formula.
Is there a way to instruct the Alloy Analyzer to generate an instance of the relation to.address without specifying a constraint on the relation? If not, why not?
I think you're misunderstanding what the visualizer does. Each execution of Alloy generates an instance that binds all relations. The body of the run command is a constraint that determines which instances are valid; it has no effect on which relations are displayed. To do what you want, you can write a constraint that names the relation (eg with an existential quantifier). Or if you want to see the value of a particular expression, you can just type it into the evaluator.
Related
In a model I am writing, I would like to say that a reading of a manuscript identifies a sequence of tokens in the manuscript and maps them to types; the mapping should be defined for all tokens in the manuscript and should identify exactly one type for each token. (Types and tokens here are as described by Peirce's type/token distinction.)
When I write
sig Document, Type, Token {}
sig Reading {
doc: Document,
tokens: seq Token,
mapping: elems[tokens] -> one Type
}
run {} for 3
an attempt to execute the run command produces the error message
The name "elems" cannot be found.
If I replace elems[tokens] with seq/Int.tokens (borrowing from the definition of elems in util/sequiv) or (simplifying) Int.tokens or univ.tokens, I get the results I expect.
If I replace elems[tokens] with ran[tokens] (and include open util/relation), I get a similar complaint about the name ran.
Using these names elsewhere in the model (not shown) does not elicit this error, so I infer that the problem is not that the functions in question are unknown but that function invocations are unwelcome in the right hand side of a field declaration.
The grammar says of the right-hand side of a field declaration only that it is an expression, and function invocations are allowed as expressions. So I suppose there is a constraint expressed elsewhere that explains why my initial formulation does not work. Can anyone tell me what it is?
I can make do with univ.tokens for now, but I would prefer the original formulation as easier for my expected readers to understand -- they can squint and think of it as a function call, whereas with dot join I need to pause to explain it to them, which distracts from the core task of the model. My thanks for any help.
I toyed a bit with the example and it seems your inference is correct. One can't reference a function in field declarations (even if the grammar states otherwise)
What you proposed (univ.tokens or Int.tokens) is for me the cleanest workaround.
What Peter proposed in his comment does indeed the trick, but redefining elems looks too fishy, especially since the elems function is already clearly defined for your readers. It could be a source of confusion.
Another idea if you really really insist on using elems[token] would be to define mapping as a relation from Token to Type and then to constrain the left-handside of the relation to consist only of those Token present in the sequence. Here would then be your model:
sig Document, Type, Token {}
sig Reading {
doc: Document,
tokens: seq Token,
mapping: Token -> one Type
}{
mapping.Type =elems[tokens]
}
run {} for 3
Does anyone happen to know if a program concept exits in a language that allows for the construction of interfaces that only specify the required data types needed to satisfy it's implementation?
In other words, the naming conventions of the object/class implementing it are irrelevant. Successful implementation is based on whether or not, the property types comprise to satisfy the interface's type definition requirements.
For example, suppose I had a program that created a bunch of type aliases. I'd like to potentially do this:
# Revenue of the transaction
type Revenue = Float
# Id of the Transaction
type TransactionId = String
interface Transaction {
Revenue
TransactionId
}
# This compiles...
type MyCustomTransaction implements Transaction {
saleAmount: Revenue
id: TransactionId
myCustomProperty: Boolean
}
What you are describing is a less useful version of protocols or abstract classes which define a required interface. By just defining the type and not requiring the name be defined the interface is useless.
Think about it like this. I tell you that some object complies with the Transaction interface. You only know that the object contains a property that is a Revenue and a TransactionId. However you do not know how to access them and what they mean. So can you even use the interface?
There is an idea similar to what you are saying like typed-tuples, which are groups of elements that are not necessarily named like (5,5,"Hello") which is of type (Int,Int,String). However since a tuple is ordered, knowing the type provides an "implicit" interface in that you know the amount and types of elements contained.
Here is some more reading on protocols and abstract classes if you are interested:
https://en.wikipedia.org/wiki/Abstract_type
https://en.wikipedia.org/wiki/Concept_(generic_programming)
https://en.wikipedia.org/wiki/Protocol_(object-oriented_programming)
The following signature describes the state of a photo-management application:
sig ApplicationState {
catalogs: set Catalog,
catalogState: catalogs -> one CatalogState
}
A signature, of course, creates a set. In this case, it creates a set of ApplicationStates:
ApplicationState0
ApplicationState1
...
catalogs is a field. It maps each ApplicationState to a set of Catalog values:
ApplicationState0, Catalog0
ApplicationState0, Catalog1
ApplicationState1, Catalog0
...
catalogState is also a field. It maps each ApplicationState to a relation. The relation is:
catalogs -> one CatalogState
That relation says: Map each value of catalogs to one CatalogState value. We already saw catalogs, which I'll repeat here:
ApplicationState0, Catalog0
ApplicationState0, Catalog1
ApplicationState1, Catalog0
...
So, the relation says to map each of those tuples to one CatalogState, like so:
ApplicationState0, Catalog0, CatalogState0
ApplicationState0, Catalog1, CatalogState0
ApplicationState1, Catalog0, CatalogState0
...
Okay, back to catalogState. Earlier we said that it maps each ApplicationState to a relation, and we just saw what that relation is. So, I believe that catalogState denotes a relation with arity=4, like so:
ApplicationState0, ApplicationState0, Catalog0, CatalogState0
ApplicationState0, ApplicationState0, Catalog1, CatalogState0
ApplicationState0, ApplicationState1, Catalog0, CatalogState0
...
But, when I run the Alloy Evaluator, it says that catalogState is a ternary relation. My takeaway from this example is:
Usually a field name denotes a relation.
A field name used in an arrow expression does not denote a relation. Rather, it denotes column 2 of the relation (the range of the relation).
Is that right? Where is this explained in the Software Abstractions book?
Section 4.2.2 of Sofware Abstractions (p. 97 in the second edition) begins
Relations are declared as fields of signatures.
That addresses at least part of your question, I think. (I think it may be helpful to work through the index entries for 'field' and relation and read every section they point to.)
You say
A field name used in an arrow expression does not denote a relation. Rather, it denotes column 2 of the relation (the range of the relation).
It may sound pedantic, but no: field names always denote relations. Within the context of a signature declaration however, they are implicitly prefixed with this., which removes the first column of the relation. In your declaration catalogState: catalogs -> one CatalogState, the reference to catalogs is indeed a reference to a binary relation over ApplicationState and Catalog. In this context, however, it's silently expanded to this.catalogs, which evaluates to a set of Catalog individuals. The keyword this is introduced in section 4.2.2 of Software Abstractions.
The cardinality constraints on declarations may also be a complicating factor in your example; I won't try to explain their effect here. I'll only say that when I have run into problems with cardinality constraints, I have often found that a very careful reading of the relevant parts of the language reference in Appendix B has generally sufficed to let me understand what was going on. (I admit that sometimes it has taken more than one reading.)
I have in front of me an Alloy model composed of different modules (files).
The main module (the one containing the command) does not contain any signature declaration, only a command and some facts.
This model enforces that only one instance can possibly be satisfiable but after analysis, several satisfiable instances are found.
I investigated the differences between the generated instances to discover that a Univ signature appeared magically (in addition to the built-in univ signature).
The difference between each instance generated come from the number of atoms belonging to that mysterious addition.
After adding a signature to the main module, the Univ signature disappeared.
It seems that the Alloy analyzer adds this signature by itself when no signature declarations are found in the module containing the command executed.
Is this behavior generally desired ? If so, why ?
The simplest way to reproduce this behavior is to have a module containing only: run {}
I believe that this particular case is a bug. The original motivation is that when you have no sigs defined (at all), and just want to check some property over the built-in relations (e.g., unit, iden, none), unless a sig exists, the analyzer won't be able to produce instances with more than 0 atoms. That's why the Univ sig is automatically generated in those cases. The current implementation fails to check if the imported modules define any sigs, so in those cases, as you already realized, you end up with the mysterious Univ sig. You also correctly pointed out that an easy workaround would be to add a dummy empty sig to the module where your command is defined, e.g.,
sig Dummy {}
fact { no Dummy }
You should also check the latest experimental version, because this bug may be fixed there (not sure though).
What is the difference between association and dependency? Can you give code examples?
What is the relationship between class A and B?
class A
{
B *b;
void f ()
{
b = new B ();
b->f();
delete b;
}
}
The short answer is: how any specific source language construct should be represented in UML is not strictly defined. This would be part of a standardized UML profile for the language in question, but these are sadly few and far between. Long answer follows.
In your example, I'm afraid I would have to say "neither", just to be difficult. A has a member variable of type B, so the relationship is actually an aggregation or a composition... Or a directed association. In UML, a directed association with a named target role is semantically equivalent to an attribute with the corresponding name.
As a rule of thumb, it's an aggregation if b gets initialized in A's constructor; it's a composition if it also gets destroyed in B's destructor (shared lifecycle). If neither applies, it's an attribute / directed association.
If b was not a member variable in A, and the local variable b was not operatoed on (no methods were called on it), then I would represent that as a dependency: A needs B, but it doesn't have an attribute of that type.
But f() actually calls a method defined in B. This to me makes the correct relationship a <<use>>, which is a more specialized form of dependency.
Finally, an (undirected) association is the weakest form of link between two classes, and for that very reason I tend not to use them when describing source constructs. When I do, I usually use them when there are no direct source code relationships, but the two classes are still somehow related. An example of this might be a situation where the two are responsible for different parts of the same larger algorithm, but a third class uses them both.
It may be useful to see this question I asked: does an association imply a dependency in UML
My understanding is:
Association
public class SchoolClass{
/** This field, of type Bar, represents an association, a conceptual link
* between SchoolClass and Student. (Yes, this should probably be
* a List<Student>, but the array notation is clearer for the explanation)
*/
private Student[] students;
}
Dependency
public class SchoolClass{
private Timetable classTimetable;
public void generateTimetable(){
/*
* Here, SchoolClass depends on TimetableGenerator to function,
* but this doesn't represent a conceptual relationship. It's more of
* a logical implementation detail.
*/
TimetableGenerator timetableGen = new TimetableGenerator();
/*
* Timetable, however, is an association, as it is a conceptual
* relationship that describes some aspect of the data that the
* class holds (Remember OOP101? Objects consist of data and operations
* upon that data, associations are UMLs way or representing that data)
*/
classTimetable = timetableGen.generateTimetable();
}
}
If you want to see the difference at the "code level", in an association between A and B, the implementation of A (or B or both depending on cardinalities, navigability,...) in an OO lang would include an attribute of type B.
Instead in a dependency, A would probably have a method where one of the parameters is of type B. So A and B are not linked but changing B would affect the dependant class A since maybe the way the A method manipulates the object B is no longer valid (e.g. B has changed the signature of a method and this induces a compile error in the class A)
Get it from Wiki: Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
So I think the case here is association, if B is a parameter variable or local variable of a method of the A, then they are dependency.
A dependency really is very loosely defined. So there would be no code representation.
Wiki: A dependency is a semantic relationship where a change to the influent or independent modeling element may affect the semantics of the dependent modeling element.[1]
From the OMG Spec: A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).