Closed michellutz closed 5 years ago
Just a quick comment: The implementation model in UML does not have to be developed manually, it could also be derived in an automated way - this is basically what the ShapeChange Transformations (#22) do.
Good to hear this about ShapeChange. I still had the question open if the ShapeChange flattener produced a UML implementation model or an adapted (flattened) GML application schema. Of course it can also do the latter but I understand now that it also produces a UML. Perfect.
@PalmJanssen To be precise: ShapeChange internally uses a model specification that is based on a UML profile that covers all the information that we have seen and that supports the General Feature Model. When a model is transformed, the result is a new model in the same specification. Typically that derived model is processed to generate implementation artefacts, but you may also generate a EA file (target: UML model) or an XML file that can be used as input to ShapeChange later (target: Model export - faster and avoid the 32-bit limitation that comes with EA).
@cportele Still perfect :)
For the discussion, I would like to add this diagram (from the document mentioned in #28) that describes an approach, as also used by ShapeChange:
So it is overall seen a two-step approach:
I think that an intermediate UML model would be a ice way to document the simplification. If Shapechange can generate it, it is perfect !
[2017.2 meeting 2018-09-28] It was agreed that intermediate simplification steps at the UML model level should be included and might be useful to document the applied simplifications.
Simplification rules could be implemented purely in the UML-to-encoding rules, or alternatively, in a first step, an implementation model could be manually developed in UML, and the UML-to-encoding rules could then be applied to that implementation model.
The latter was already foreseen in the data specifications template (for the UML-to-GML mapping):