Problem Statement:
Different usage of the «Specify» relationship in TAPI: TAPI uses concrete extending classes which is not recommended in the Modelling Guidelines.
Document: Draft_TR-514_UML_Modeling_Guidelines_v1.3.04 - ib-00.docx
Italo's request
It was noted that the statement above indicates that the augmenting class must be abstract.
The tooling and the UML-YANG guidelines indicate that the augmenting class can be concrete.
TAPI uses concrete augmenting class.
Italo has a problem with this in the example below.
In the example above it is not clear how the specify relationship was formed.
In the above example, if TopologyContext was abstract the _topology attribute would appear in TapiContext in the instance.
The figure below is not correct as the augmenting class is concrete.
Two choices:
- mandate abstract class (implications on TAPI)
- allow (and explain) both concrete and abstract (depending upon the rules, this may still have implications for TAPI)
- Bernd Zeuner Regarding concrete v abstract augmenting class, provide figures to support further discussion and decision.
Also discussed:
Italo confirmed that this was now covered.
Bernd questioned whether this should be MainModel or MainModule.
Agreed that the use of model/module is just a a string and does not need to be translated by the tool.
The above diagram is not correct as it implies that the target must be a root element but it is not shown as such. As any class can be augmented the diagram should be generalized to show a partial string in the target such as /xxx/ etc.
- Bernd Zeuner On , redraw/clarify various figures as noted above (related to... not only root class)
Agreement: Both alternatives (concrete and abstract augmenting classes) are allowed but the abstract augmenting class is recommended
Overview
Content Tools
Activity