Nigel Davisdetermine what Jira form structure etc.ONF can create IISOMI. Provide example/detail etc. for discussion.
Nigel DavisProvide an overview of the DDD trial profile and show application to the core model.
Andrea MazziniBernd Zeuner Improve explanation of target sterotype string content formation in the UML Guidelines.
3
0 min
UML → YANG Mapping Tool funding
Martin
O-RAN cooperation
October 1: O-RAN policy has changed collaboration rules. (O-RAN Alliance is registered in Germany)
October 15:Martin Skorupskichecked with O-RAN the tooling funding status. There is hope, not dead, but not moving either.
Martin SkorupskiGet a written statement from O-RAN leadership on state of tooling funding's
November 19 discussion: Martin reported on the progress of requesting funding from O-RAN for UML-YANG tooling. The proposal will be up for voting in O-RAN.
Martin Skorupskihas informed that the proposal reached the next level and moved from O-RAN TSC to O-RAN Executive Committee (EC). Discussion in O-RAN EC will start.
4
0 min
Attribute referencing
Martin
Reference from an ObjectClass to a specific attribute(!) of another ObjectClass
we - the ONF OTCC 5G-xHaul group - have the "use case" to reference from an ObjectClass a specific attribute(!) of another ObjectClass, which is by itself a reference to the next ObjectClass.
Example:
[ClassAA] -> [ClassBB]
So in ClassAA there is an attribute of "classBB" with type ClassBB.
Now, we would like to configure in another ClassCC an attribute called "pointerToClassBBbyClassAA" - which points to the attribute ClassAA::classBB of type "ClassBB".
I'm looking into UML specifications and UML Modelling Guidelines.
Is my understanding correct that UML is not designed to reference a specific attribute but "only" ObjectClasses, DataTypes, ....?
If yes, (and I still hope the answer to question #1 is no :) ) - could/should the "Reference Stereotype" be used for such case.
an other option might by to add an association from ClassCC to ClassBB and constrain it with the values given in attribute ClassAA::classBB
Any suggestions how to handle the situation in Papyrus UML following IISOMI guidelines?
2022-02-04:
The discussion concluded that option 3 (i.e., add an association from ClassCC to ClassBB and constrain it with the values given in attribute ClassAA::_classBB) is the right way to do. See the below.
In particular, if I understand correctly, for the root element object class (i.e., red element), the format is actually not “[/<ModelName>:<ClassName>:<navigable association end role name>]” as indicated in the UML guidelines v1.3.03 but it is in the format of “[/<ModelName>:<ClassName>:<name of the RootElement stereotype>]”
Model Name or Prefix
2022-01-21:
Italo Busiindicates that theUML guidelineis not requiring the undescore in thenameof theRootElementstereotype, while the examples in theUML to YANG guidelineinclude the undescore (e.g. TAPI currently has "_context"). It is recommendable to clarify and align the guidelines.
In particular, for the root element object class (i.e.,red element), the format is actually not “[/<ModelName>:<ClassName>:<navigable association end role name>]” as indicated in the UML guidelines v1.3.03 but it is in the format of “[/<ModelName>:<ClassName>:<name of the RootElement stereotype>]”, e.g.
The referencing mechanism used in the target path identifies each element in the path by going one step up the path (hierarchy) to find the referencing attribute from the class that references the class to be identified. This works for all but the root entity (where there is clearly nothing one step up the path hierarchy). This is why an artificial role end was used reference the root entity.
This is conveyed in the <<RootElement>> stereotype as shown above. It is as if a class Context references the TapiContext via a composition with a navigable attribute _context. The class "Context" does not exist in the model. Both the class name "Context" and its reference are derived from the value of the name in the <<RootElement>> Stereotype (i.e., "_context") where the class name is an upper camel form of the string with the "_" removed.
The mechanism should be described more clearly in the modeling guidelines.
Andrea MazziniBernd Zeuner: To improve the explanation of target sterotype string content formation by
Remaining issue
Italo's second question "Should we use the module name (i.e., IetfPtp) or the module prefix (i.e., ptp) or either option?"
Only briefly discussed. No definitive conclusion yet.
It seems that in UML it should be the module name, and the mapping tool will then maps the module name to the module prefix.
2022-02-04:
Bernd shared his off-line email discussion with Andrea on how to improve the explanation in section 5.4.3/TR514.
In his off-line discussion, Bernd raised a question on second part (yellow highlighted)of the path.
No conclusion reached from the long discussion. Will continue the discusion in the next call.
On Italo's second question "Should we use the module name (i.e., IetfPtp) or the module prefix (i.e., ptp) or either option?"
Agree that in the UML model, the module name should be used because module prefix is a YANG term.
In order to be able to compose the target path of the two «Specify» relationships the class diagram below has been extended with the greyed out "non existing" object class and composition relationships.
Andrea Mazzini will draft rules for the UML Modelling Guidelines for creating the target paths; this is part of the existing action item "Improve explanation of target sterotype string content formation in the UML Guidelines". Discussion will continue in two weeks.
0 min
UML Modeling Guidelines
Italo
UML modeling guidelines
Convention for the name of the non-navigable member ends of an association
Have seen cases where these member ends do not have names, cases where they have LCC names and cases where they have names following the same convention as navigable attributes (_ + LCC)
Cardinality for conditionally mandatory associations: should it be 1 or 0..1?
2022-02-04: No discussion. Deferred to 2022-02-11
6
0 min
Papyrus Releases
Papyrus Releases
Consider a plan for convergence of ITU-T Q14/15, ONF Common IM and TAPI to 2020-06 (4.16) version
November 19 discussion: The TR-512 v1.5 Core model was developed using Eclipse 2019-09. It the model can migrate to 2020-06 seamlessly, Q14/15 might move G.7711 v4.0 (12/2021 consent) also to Eclipse 2020-06. To verify the seamless migration:
Nigel Davis Try to move TR-512 v1.5 core model to 2020-06 (4.16) Eclipse
Hing-Kam LamTry to move TR-512 v1.5 core model to 2020-06 (4.16) Eclipse
2021-12-03:
from Kam - diagrams from TR-512 v1.5 core model on 2020-06 (4.16) Eclipse looks fine
proposal for next week ITU-T: IISOMI moves to 2020-06, because gen-doc works find
TAPI will follow after some tests will be done by Andrea Mazzini
Nigel Davis Try to move TR-512 v1.5 core model to 2020-06 (4.16) Eclipse
2022-01-21:
Scott Mansfieldclarifies that the Gendoc application depends on Papyrus version, and not on Eclipse version.
Scott Mansfieldmodel2docshould dump every UML construct, to be checked.
2022-01-21:
Brief discussion on2020-06 (4.16) noting that Papyrus appeared to be OK (butNigel Davisnoted that in his environment Gendoc was still not working due to memory apparently).
Nigel Davisnoted that OIMT have agreed to develop the profile and apply to a part of the core as an example. This can be presented to IISOMI in February.
Nigel DavisProvide an overview of the DDD trial profile and show application to the core model.
