Location Package generalization questionned [message #1498] |
Mon, 13 February 2017 15:56 |
Matthieu Perin
Messages: 10 Registered: February 2017 Location: Lille, France
|
Junior Member |
|
|
Hi,
First of all, please let me introduce myself.
I am Matthieu Perin, presently working at IFSTTAR , the French research institute devoted to Transportation, network and infrastructure research. I am actually working in Lille center as a non-tenure researcher on a project of point command using formal methods and logic controllers. I was previously working at CEA List on a team specialized on Safety, Security and Meta-modeling (using SysML) linked to formal languages.
I would point to you an "issue" about some generalizations & composite association used in the Location Package.
![https://framapic.org/zmHuwO0dowNJ/nMRmbBqKwgwF.jpg](https://framapic.org/zmHuwO0dowNJ/nMRmbBqKwgwF.jpg)
In the previous picture, Area and Linear Location and their generalizations are presented, along with their associated elements of Topological Package.
Now let's try to create a Linear Location:
- Create a Linear Location
- Create an OrderedAssociatedNetElement (Mandatory due to composite multiplicity)
- Create an AssociatedNetElement (Suggested by the generalization)
- Create an AreaLocation (Mandatory due to composite multiplicity)
So we will have a "free" AreaLocation created, but the problems come from the fact that This object is weakly linked to the LinearLocation created at first (only a common generalization ...no even mandatory realized by the same instance).
A solution might be to make the LinearLocation to be a specialization of a AreaLocation, and tu explain that the composition of LinearLocation is a redefinition of the one of AreaLocation.
--
Matthieu Perin
IFSTTAR
matthieuperin(at)ifsttarfr
|
|
|