How to build the above model - alloy

I am a beginner in Alloy.
I'm trying to model a math problem.
I want to prove the theorem that the plane exists at least four lines, I use the below four axioms to prove the theorems.
axiom 1: There exists at least one line;
axiom 2: Every line contain
at least three points;
axioms3: Not all points lie on the same line;
axioms4: There is exactly one line through any two points.
Theorem : There exist at least four lines.
How to build the above model?

Here is a general approach to modeling such a problem in Alloy.
First identify the relevant concepts (e.g. Point,Line ...) and declare them as so called signatures.
Then declare in the body of those signatures so called fields defining relations between those concepts. (e.g. containment relation between a line and points).
Once such structure is defined you can express your axioms as invariants in so called facts.
To learn how to declare signatures, fields and facts, please have a look at the Alloy online tutorial: http://alloy.mit.edu/alloy/tutorials/online/

Related

What is a Unary association in UML

While I googled to understand the Unary associations, I got the following two explanations:
the first is:
A unary relationship is when both participants in the relationship are
the same entity. For Example: Subjects may be prerequisites for other
subjects, or one employee manages many Employees.
and the second is:
Class B knows about ClassA.
Class A does not know about ClassB.
Now lets look at the following example:
You can see the Person and Address relationship below. We call this
relationship as has-a relationship since person has a address. So
Person knows the address but address does not know anything about
person
Am I misunderstanding something?
Common language
The arity of an association is about how many classes are associated. This is an ambiguous concept since some understand different classes, whereas others understand instances.
When applied to unary, the first interpretation would mean reflexive association (or self-association, i.e. a class associated with iteself), whereas the second would mean a class associated with nothing (not very useful: any class could be associated with nothing else).
UML perspective
Fortunately, the UML specifications are much more precise than the common language:
An Association specifies a semantic relationship that can occur between typed instances. It has at least two memberEnds represented by Properties, each of which has the type of the end. More than one end of the Association may have the same type.
So in UML there is no "unary association". It's binary, ternary, or n-ary (terms used in the specs). There is no special term in UML for a binary association with the same class at both ends. But reflexive or self-association are terms which are more popular than unary.
E/R modeling
The term "unary" is popular in the context of entity-relationship modeling, to describe a relation in a relational database. Relations correspond more or less to an association in UML, and entities to classes, but there are some subtle semantic differences. E/R has its foundation in the set theory. And if a relation is between the same entities, it means in fact that only one set is involved. This is probably why unary is more popular in this context.
Merriam-webster defines Unary as
having, consisting of, or acting on a single element, item, or
component
So the first explanation is correct one since this type of association acts on a single class. The term Unary however is not used in UML and might be confusing.
UML uses the term binary to indicate that an association has two ends, and ternary or n-ary to indicate an association has multiple ends.
The Unary association you are talking about is actually a binary association to itself, also known as reflexive association.
Not to be confused with a Unidirectional association, which is an association that is only navigable (has an arrow) to one side.

What is the difference between st_isvalid and st_issimple?

In Postgis there are two very similar functions. One is st_isValid, the other one is st_isSimple. I'd like to understand the difference between both for Polygons. For the st_isValid we have:
Some of the rules of polygon validity feel obvious, and others feel arbitrary (and in fact, are arbitrary).
Polygon rings must close.
Rings that define holes should be inside rings that define exterior boundaries.
Rings may not self-intersect (they may neither touch nor cross one another).
Rings may not touch other rings, except at a point.
For the st_isSimple we've got:
Returns true if this Geometry has no anomalous geometric points, such as self intersection or self tangency. For more information on the OGC's definition of geometry simplicity and validity, refer to "Ensuring OpenGIS compliancy of geometries"
Does it mean that any valid polygon is automatically simple?
Both functions check for similar OGC definition compliancy of geometries, but are defined for different geometries (by dimension);
By OGC definition
a [Multi]LineString can (should) be simple
a [Multi]Polygon can (should) be valid
This implies that
a simple [Multi]LineString is always considered valid
a valid [Multi]Polygon is always considered simple (as in, it must have at least one simple closed LineString ring)
thus the answer is yes.
Strictly speaking, using the inherent checks of the OGC defined functionality on the 'wrong' geometry type is useless.
PostGIS, however, liberally extends the functionality of ST_IsValid to use the correct checks for all geometry types.

UML constraint across three associations?

Let's say I have class A with associations to classes X, Y, and Z, respectively. I need to indicate that only one of these associations may be instantiated for any given instance of class A (so, an xor constraint). I know how to do this if the constraint is just across two associations. Obviously I can just make three seperate xor constraints (X-Y, X-Z, Y-Z) but I'm wondering if there is a better/cleaner/proper way to do it?
edit: The multiplicity constraints on the respective associations are not the same. Using an abstract class or interface will not work. Furthermore, a note is insufficient. I need to use some sort of formalized structure, preferably something standardized (e.g. by OMG) to express this because I am programmatically processing the model elements (i.e. it isn't just a picture). I understand how the underlying model for UML provides for this facility. It also specifies (though slightly vaguely) how it should be notated. I guess my main issue is, in fact, with finding a tool that allows me to make that notation. I don't think MagicDraw does so. I should have stated these things earlier.
FWIW, I'm using MagicDraw. It would be a nice bonus if the I could do this in a way that MagicDraw actually understood. I can live with it if that isn't possible.
The xor constraint is just a stylized and rather under-specified constraint for the 2-way case.
You can define an explicit constraint (in Complete OCL) as:
context A
inv OnlyAorBorC: A->size() + B->Size() + C->size() <= 1
MagicDraw may allow you to specify a similar contextual Constraint on A.
If "X", "Y" and/or "Z" can be somehow generalized (I mean, if you not doing this puraly for a conditional flow control), you can make an interface (or and abstract class) "I" for example, and make "X", "Y" and "Z" implement this interface. Then, you put an association with multiplicity 1 between A and the interface I.
See the diagram below:
Edit: The example above doesn't work in the case of A having different cardinalities between X, Y and Z. For this case, the only way that I can see is use an UML Constraint to restrict those relationships. You can define a Constraint in UML putting some OCL expression between curly braces. E. g.
Here, account owner is either Person or Corporation and this {xor} is predefined UML constraint.
I'm not sure about the details of your cardinalities requirements but, a combination between this {xor} and the interface example that I gave might be enough. At least it gives you a little bit more of options, like:
If you need to know more about the UML constraints subject, I got this example from uml-diagrams.org: http://www.uml-diagrams.org/constraint.html

Association definition in UML specification

An association defines a semantic relationship between classifiers. The instances of an association are a set of tuples relating instances of the classifiers. Eachtuple value may appear at most once. The Association represents a set of connections among instances of the Classifiers. An instance of an Association is a Link, which is atuple of Instances drawn from the corresponding Classifiers
I wonder if there is someone helps me understand every word of the association definition especially the highlighted ones?because I read about it from different resources but all of them say the same words but I would like a more elaborated definition
semantic relationship
This means there's a structural relationship between the things being associated that arises from the problem space. For example: the association Person owns Dog. In a dog licensing application, this relationship is the central concept; the application exists to manage the links between people and dogs. It's a 'semantic' relationship because it has meaning which originates from the problem space.
set of tuples relating instances of the classifiers
A tuple is 'an ordered set of elements' (wikipedia). An example of the Dog-Ownership association could be ("Fido", "Fred") where "Fido" represents a Dog and "Fred" a Person. An association can be represented as a set of tuples in that there is one tuple for each combination of Dog & Person for which the relation holds; e.g.
[("Fido", "Fred"), ("Angel", "Chuck Norris"), ("Boatswain", "Lord Byron")]
Note there are no tuples for pairs where the relationship doesn't hold; e.g. ("Fido", "Lord Byron").
each tuple value may appear at most once
It's not possible for the set to contain duplicates as this would just be saying the same thing twice. So there's no point adding ("Fido", "Fred") again to the list above; we already know Fred owns Fido.
The Association represents a set of connections among instances of the Classifiers
This is just another way to think about the relationship. For each tuple in the set, you can think of a link - or connection - between the related objects.
An instance of an Association is a Link, which is a tuple of Instances
See above. Each tuple represents one linked pair of objects. Links are to Associations as Objects are to Classes. Classes have many objects; Associations have many Links.
Fundamentally associations exist to show where things are systematically linked to other things. Tuples and sets are a way to think about and/or represent those linked things. (In fact I'd quibble somewhat with the definition in your OP: the links in an association can be represented as as a set of tuples: but that's not what they are, it's how they're modelled. The same information could equally be modelled by a Graph, where each object was represented by a vertex (node) and each association an edge.
hth.
EDIT:
Responding to your questions. Looks like you understand it pretty well; some observations.
First, here's how I would model it:
Now to each of your points:
Name: is the name of Association relationship(optional,you can give it a name or not)
I prefer verb phrase based naming as it brings out the meaning of the relationship. My model can be read directly as:
Each Person owns many Dogs (where 'many' means 0 or more)
Each Dog is owned by exactly one Person
Doing so removes the need to name the association explicitly, although you can still do so if you want.
visibility(I am not care about it,at least for now, I didn't realize its importance until now).
I would agree. Personally, I never annotate models with visibility.
Name:(here is the name of MemberEnd ),so,I left its default name in the screenshot
See comment about association naming above. I prefer verb-based naming to role-based: 'owns' is much more explicit in describing the purpose of a relationship than naming the association end 'dog' or 'dogs'.
the owner of memberEnd [...]
Personally: I don't use this. There's a whole other discussion about this that tbh I don't believe has a material impact in most cases.
Navigable [...]
Again I don't use this personally. In reality navigability should be derived from the underlying behaviour. Does it require navigating one way/both? Then set navigability accordingly. However some people like to specify it explicitly, on basis it makes the implementation clearer (If only navigable one way it can be implemented with reference(s) in one class only; if bi-directional it needs references in both directions - with attendant logic to keep things consistent).
Multiplicity
I agree with your selection.
Hope that helps.

Using variables in UML multiplicities

I was running a tutorial today, and a we were designing a Class diagram to model a road system. One of the constraints of the system is that any one segment of road has a maximum capacity; once reached, no new vehicles can enter the segment.
When drawing the class diagram, can I use capacity as one of the multiplicities? This way, instead of having 0..* vehicles on a road segment, I can have 0..capacity vehicles.
I had a look at ISO 1905-1 for inspiration, and I thought that what I want is similar to what they've called a 'multiplicity element'. In the standard, it states:
If the Multiplicity is associated with an element whose notation is a text string (such as an attribute, etc.), the multiplicity string will be placed within square brackets ([]) as part of that text string. Figure 9.33 shows two multiplicity strings as part of attribute specifications within a class symbol. -- section 9.12
However, in the examples it gives, they don't seem to employ this feature in the way I expected - they annotate association links rather than replace the multiplicities.
I would rather get a definitive answer for the students in question, rather than make a guess based on the standard, so I ask here: has anyone else faced this issue? How did you overcome it?
According to the UML specification you can use a ValueSpecification for lower and upper bounds of a multiplicity element. And a ValueSpecification can be an expression. So in theory it must be possible although the correct expression will be more complex. Indeed it mixes design and instance level.
In such a case it is more usual to use a constraint like this:
UML multiplicity constraint http://app.genmymodel.com/engine/xaelis/roads.jpg

Resources