On Fri, Jul 28, 2017 at 3:14 PM, Pavel Krivanek
I was checking the containers in the current Famix and I have found several
FAMIXSourceAnchor>>#element is container but the relationship to
FAMIXSourcedEntity has one to one cardinality. It is the only case like this
and it is probably wrong.
Does it have any reason or is it an error?
Then the relation between FAMIXSourcedEntity>>#containerFiles and
FAMIXFile>>#entities it the only one with cardinality many to many where a
container is specified but Vincent already told me that this is an error.
Moose-dev mailing list
You raise something that is very interesting. We are talking about it
with Anne, Vincent and Nicolas.
I will expose the fact and a solution I wanted to propose at ESUG.
Currently in FAME, the container pragma is used to define the
technical containement. It is in UML the little black diamond. So it
can only be for relation of one-to-one or one-to-many. It cannot be
many-to-many. The FAMIXFile/FAMIXSourcedEntity relation can be
many-to-many because of languages where an entity is in multiple files
(C, C++, Ada…)
This is used for example on Orion to destoy contained entities when we
delete an entity.
The problem is that it is a technical containment. Using Moose we need
to use logical containement. In a logical way, a source anchor is not
contained in a sourced entity and also an file contains entity. This
is not technicaly true, but it is logicaly true.
Thus I would like to introduce new pragma and get those three:
- <logicalContainer> : for container that are only logical (files
- <technicalContainer> : for container that are only technical (source anchors)
- <container> : the current on that would be both (95% of the current
With this we could have #childrenEntities that would return the
logical children and #technicalChildrenEntities that would return the
technical ones for Orion.
I was going to present this idea to ESUG but since you raise the subject… :)
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France