| 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.
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
|
|
|
|
Members
Search
Help
Login
Home
