Open Information Model & Tooling
Space shortcuts
Expand all   Collapse all
Child pages
  • Project proposal for UML-To-YANG
Skip to end of metadata
Go to start of metadata

The UML-To-YANG tool based on javascript is a critical software component and should be treated as a managed open-source project.

The idea could be to handle it similar to projects managed by Linux Foundation Network, such as OpenDaylight/yangtools or ONAP/CCSDK.

Scope

The scope converting UML to YANG migth be to restictive, maybe UML tooling which may include also other convertions from and to UML may get more attraction. However the core of such project should be XMI-to-YANG.

Project setup proposal

In order to have a continous development and maintenance of the UML-To-YANG tool it is nessesary to have commited development resources and a common project structure. 

  • Specification: UML Guidelines, UML-YANG-Guidelines
  • Developer guide/wiki: Confluence
  • Integrated development environment: eclipse (proposal)
  • Code review: gerrit  (with a clone to a public github)
  • Modul tests, regression tests: junit
  • Build process: Maven
  • Continuous integration: Jenkins
  • Continuous delivery: docker, kubernetes, web-services
  • Continuous Code Quality: sonar
  • User documentation: Read-the-docs
  • Logging: log4j
  • License: Apache 2.0

UML to YANG Mapping

  • Object Reference Mapping (All)
    • Generate reference grouping based on composition tree (composition association)
    • Use these Groupings for shared/none associations
    • use of xPath “current()” function
  • Mapping of Abstraction / <specify> relationship 
    • Elimination of the target attribute
    • Addition of multiplicity - accordingly enclose the "uses <grouping>" in Container or List
    • Dependency on the "Reference" grouping feature
    • Auto-generate the CRUD operations input/output parameters and equivalent actions
  • Use of “when” and “must” statements
    • Mapping of UML Constraints - to be used mainly in <augment>/<specify> and in conditional associations
  • Use of require instance statement and mandatory statement
  • Mapping of complex datatype
  • Mapping of Classes to Identities
  • No labels

2 Comments

  1. Martin Skorupski

    To my experience, there is a lot tool support (any programming language) to generate xml. It is much easier generating xml than directly yang. Therefore the xml representation of yang could be generated first, called yin. In a last step yin can be converted to yang and yang-tree using pyang.

  2. Martin Skorupski

    A potential starting point for implementation

    • Every statement in yang - container, list, leaf, uses, key, ... should be presented by its own class. 
    • All classes must implement the constructor, its individual logic and the toYin() method. → interface.
    • All yang statements, their containment and cardinality/multiplicity are described in RFC7950 Section 7 (https://tools.ietf.org/html/rfc7950#section-7).
      Section 13.1 lists all yang/yin statements.
    • The current software structure could be similar/reused: XmiParser → Processor → YinBuilder → valid Yin.