Hi,
I was checking the containers in the current Famix and I have found several strange attributes: 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. Cheers, -- Pavel _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
On Fri, Jul 28, 2017 at 3:14 PM, Pavel Krivanek
<[hidden email]> wrote: > Hi, > > I was checking the containers in the current Famix and I have found several > strange attributes: > > 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. > > Cheers, > -- Pavel > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev > Hi Pavel! 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 contains entities) - <technicalContainer> : for container that are only technical (source anchors) - <container> : the current on that would be both (95% of the current containement relations) 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… :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Free forum by Nabble | Edit this page |