Child pages
  • «Specify» relationship
Skip to end of metadata
Go to start of metadata

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

2022-10-28 IISOMI Meeting Minutes

Regarding abstract/concrete of the extending class in the «Specify» relationship:
UML Modelling Guidelines only recommend to use abstract extending classes (whereas TAPI uses concrete extending classes); need to discuss this issue with TAPI.

2022-11-18 IISOMI Meeting Minutes

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 «Specify», redraw/clarify various figures as noted above (related to... not only root class)

2023-01-20 IISOMI Meeting notes

Question: Should the UML Modelling Guidelines allow concrete specification classes like TAPI is using it?

The mapping tool is already able to deal with both cases.

Agreement: Both alternatives (concrete and abstract augmenting classes) are allowed but the abstract augmenting class is recommended

2023-01-27 IISOMI Meeting notes

Email thread discussion.

The main issue is with the tooling not differentiating between abstract and concrete classes when creating the Augment statement in yang.

In the case of an abstract class: there should be no container added, for a concrete class the uses should be wrapped in a container.

See Slide 4 and Slide 6 of specify-augment.pptx (

Agreement: two new actions created, one for Bernd to create a small model with both examples and update the powerpoint with the expected results, and the second action is for Scott to run the tool and determine how to support the "abstract" case (which is currently not supported). 

  • No labels