uml/ocl access to parent class name - uml

I try to write ocl to add constraint to child (animal), but the constraint must user parent class name (mamifere). I think the first version doesn't work, and I think there is a nicer solution that the second example. Help me please ?
image for example animal:

That looks strange. Your first constraint tells (provided it's linked to animal) that the type of aninmal must be mamifere, but mamifere inherits from animal. That does not make sense.
The second variant does not make sense either. Provided the constraint applies to anything on the diagram, each instance must be named mamifere2. So you can have only instances with name == mamifere2. Especially strange with a vivipare2 instance.
I don't see where you model any child relation at all. So I'm just guessing you mean this:
A child has two parents (well, for humans there now can be more). And there can be * children which must have the same type as the parents (so you can't model mules or the like).

Related

Type hint an instance of a metaclass

I have a function which takes a class and returns an instance of that class. I'm trying to figure out how to typehint that, with a twist. Typically I would use the typing module and do something like
T = TypeVar("T", bound="BaseClass")
def foo(specific_type: Type[T]) -> T:
...
However, in my case I don't exactly want to take a class inheriting from a specific base class. What I really want to do is take a class with a specific metaclass and return an instance of that class, but I can't figure out a way to typehint that without adding some sort of dummy BaseClass. Ideally I would want the inverse of Type, something like:
M = TypeVar("M", bound="MyMetaclass")
def foo(specific_type: M) -> Instance[M]: # <-- Instance generic is made up
...
This lets me specify that foo should take an instance of MyMetaclass (which a class with metaclass=MyMetaclass is) and return an instance of that instance (an object whose class has metaclass=MyMetclass).
Is there anything in Python that lets me type hint something similar to the above?
To be clear, there is actually a base class with metaclass=MyMetaclass which I expect specific_type should probably always inherit from. However, I cannot import it into the current context without creating circular dependencies; MyMetaclass is already imported into the current context. I can work around this (I'm not asking how to organize my project), but I specifically want to know if I can type hint an instance of a class with a known metaclass like this.

If instances are really just pointers to objects in Python, what happens when I change the value of a data attribute in a particular instance?

Suppose I define "Class original:" and create a class attribute "one = 4." Then I create an instance of the class "First = original()." My understanding is that First now contains a pointer to original and "First.one" will return "4." However, suppose I create "Second = original()" and then set "Second.one = 5." What exactly happens in memory? Does a new copy of Class original get created with a class attribute of 5?
I've created a Class original with class attribute one. I then created two instances of this class (First and Second) and verified that id(First.one) and id(Second.one) are pointing to the same place. They both return the same address. However, when I created Third=original() and set Third.one = 5 and then check id(Thrid.one) it appears to be pointing somewhere else. Where is it pointing and what happened? When I check original.one it still returns "4" so obviously the original object is not being modified. Thanks.
It appears you are asking about a piece of code similar to this:
class Original:
def __init__(self, n):
self.one = n
first = Original(4)
second = Original(4)
third = Original(5)
print(id(first.one))
# 140570468047360
print(id(second.one))
# 140570468047360
print(id(third.one))
# 140570468047336
Suppose I define "Class original:" and create a class attribute "one = 4." Then I create an instance of the class "First = original()." My understanding is that First now contains a pointer to original
No. The variable references the instance you created, not the class. If it referenced the class, there would be no way for you to get at the instance you just created.
The instance will, somewhere in its object header, of course contain a pointer to its class. Without that pointer, method lookup wouldn't be possible, since you wouldn't be able to find the class from the instance.
and "First.one" will return "4."
Yes. The attribute one of first contains a pointer to the object 4 (which is an instance of the class int).
[Note that technically, some Python implementations will perform an optimization and actually store the object 4 directly in the attribute instead of a pointer to the object. But that is an internal implementation detail.]
However, suppose I create "Second = original()" and then set "Second.one = 5." What exactly happens in memory? Does a new copy of Class original get created with a class attribute of 5?
No. Why would you need a separate copy of the class? The methods are still the same for both instances. In fact, that is precisely the reason why methods in Python take the instance as their first argument! That way, there need only be one method. (This is actually the same in every OO language, except that in most other languages, this argument is "invisible" and only accessible using a special keyword like self in Ruby, Smalltalk, Self, and Newspeak or this in Java, C#, and Scala.)
I've created a Class original with class attribute one. I then created two instances of this class (First and Second) and verified that id(First.one) and id(Second.one) are pointing to the same place. They both return the same address. However, when I created Third=original() and set Third.one = 5 and then check id(Thrid.one) it appears to be pointing somewhere else.
It is not quite clear to me what your question is here. first.one and second.one both point to 4, so they both point to the same ID since they both point to the same object. third.one points to 5, which is obviously a different object from 4, so naturally, it has a different ID.
It is, in fact, one of the requirement of IDs that different objects that exist at the same time must have different IDs.
Where is it pointing and what happened?
Again, it is not quite clear what you are asking.
It is pointing at 5, and nothing happened.
When I check original.one it still returns "4" so obviously the original object is not being modified.
Indeed, it isn't. Why would it be?

Aida tutorial is unclear

I am working on the Aida tutorial:
http://www.aidaweb.si/tutorial
but I got stuck on the end of the second section:
In a workplace make an instance of ADemoAddressBook and fill it with
a few example ADemoAddresses:
Should I add an Instance variable?
I don't understand what to do in that if someone can be more clear and explain it to me? I will really appreciate it.
No, you don't have to create Instance variable (or better object), because this class probably doesn't exist.
By Wikipedia instance OF the class (not instance class) is:
a specific realization of any object. Formally, "instance" is
synonymous with "object" as they are each a particular value
(realization), and these may be called an instance object;
To make that more clear, please take a look on this picture:
"Car" is class and "polo", "mini" and "beetle" are car-type objects = so they are instances of class "car".
Coming back to SmallTalk: How to create instance of one of the classes? That is simple.
You just need to use new or basicNew operator. More you can read there:
https://code.google.com/p/seaside/wiki/ObjectInitialization
http://esug.org/data/Articles/Columns/EwingPapers/class_initialize.pdf

OCL constraint to force strings not to be empty

I have a class diagram with numerous classes, some of them containing attributes of type string. I want all my strings to be of length at least 1.
The easy (yet ugly) solution is as follows:
context Class1
inv: self.attributeOfTypeString.size > 0
context Class2
inv: self.attributeOfTypeString.size > 0
...
Do you know a way to define an OCL constraints for all attributes matching a template? Something like:
global.select(attr | attr.TYPE = string) -> forall (str : string | str.size > 0)
Finally got an answer from somewhere else. I share it in case someone needs it someday.
There are three possible ways to solve the problem.
1°) The first one is to remember that multiple inheritance is allowed in UML. Therefore, we can make all classes with a string attribute inherit from a WithString class, and set the OCL constraint on this parent class. However this makes the diagrams kinda unreadable.
2°) Another possibility is to create a class String and to store an instance of this class instead of all string attributes. The problem with this encapsulation solution is the performance (use of a getter for all strings).
3°) Finally, the cleanest solution to my opinion is the following: we can declare the OCL constraint at the meta level. In the class diagram describing class diagrams, we can just state that all strings are non-empty.

Referencing an instance of a given class in sequence diagrams

I have to model a system where an object of the class Person will invoke the static method getBook(...) : Book on the class Book which will return an instance of a particular book.
How do you reference the book instance obtained by the operation?
As of now, I can think of two approaches, neither of which I have ever seen/used, which is why I am looking for the correct approach.
The first approach is to invoke methods directly on the book instance obtained, e.g. if the reference returned by getBook(...) : Book is named matchingBook, I would use matchingBook.doSomething(...), much like having a local variable.
The second way, which I find more in the line of sequence diagrams is to let the book instance returned by the operation appear with its own lifeline, e.g. next to the Book class, and referencing it with an arrow labeled doSomething(...).
However, with the second approach, it is not that obvious that this object is in fact the one returned by the operation.
The second approach is the correct. To show that you are pointing to the returned object (matchingBook), you can add the variable name to the title of the lifeline, like this:
The second approach is the correct one. Anytime you call operations on an object returned by a first operation, you can't do better than a name match between the result of the first call and the lifeline.
Anyway I don't really understand what you expect of the first way: where would you put matchingBook.doSomething(...)? on a arrow pointing which lifeline?

Resources