Child pages
  • Contributions

oimt2018.RJ.001.01_Draft-ONF-TR-xxx_v1.0-info_UML-OpenAPI-Mapping.docx

OS SDN Logo-01.jpg  

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

Disclaimer

CREATIVE COMMONS ATTRUBUTION 4.0 INTERNATIONAL PUBLIC LICENSE

By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, you are granted the Licensed Rights in consideration of your acceptance of these terms and conditions, and the Licensor grants Your such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. For full details, explanations, and examples of the use of this License, please visit:

http://creativecommons.org/licenses/by/4.0/legalcode

 

Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.

 

Open Networking Foundation

2275 E. Bayshore Road, Suite 103, Palo Alto, CA 94303

http://www.opennetworking.org

http://opensourcesdn.org

 


Content

1 Introduction ......................................................................................................................

2 References ........................................................................................................................

3 Abbreviations ...................................................................................................................

4 Overview ...........................................................................................................................

4.1 Documentation Overview ............................................................................................

4.2 JSON Schema and JSON data .......................................................................................

5 UML- OpenAPI Mapping Guidelines ..............................................................................

5.1 Mapping of Classes ......................................................................................................

5.2 Mapping of Attributes ..................................................................................................

5.3 Mapping of Data Types ................................................................................................

5.3.1 Generic Mapping of Complex Data Types ...........................................................

5.3.2 Mapping of Common Primitive Data Types .........................................................

5.3.3 Mapping of Enumeration Types ..........................................................................

5.4 Mapping of Relationships .............................................................................................

5.4.1 Mapping of Associations .....................................................................................

5.4.2 Mapping of Dependencies ...................................................................................

5.5 Mapping of Interfaces and Operations .........................................................................

5.6 Mapping of Operation Parameters ...............................................................................

5.7 Mapping of Notifications ..............................................................................................

5.8 Mapping of UML Packages ...........................................................................................

6 Tool – User Interactions ..................................................................................................

6.1 General items

6.2 Lifecycle State Treatment ............................................................................................

7 Contributors .....................................................................................................................


1          Introduction

This Technical Recommendation defines the guidelines for a mapping from a protocol-neutral UML information model to an OpenAPI (a.k.a Swagger API), which is a RESTful API with JSON data schema. The UML information model has to be defined based on the UML Modeling Guidelines defined in [1] . The OpenAPI is defined in [4] .

2          References

[1] ONF TR-514 “UML Modeling Guidelines 1.1” ( https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/UML_Modeling_Guidelines_Version_1-1.pdf )

[2] OpenModelProfile ( https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools/tree/OpenModelProfile )

[3] JSON Schema ( http://json-schema.org/ )

[4] The OpenAPI Specification ( https://github.com/OAI/OpenAPI-Specification )

3          Abbreviations

DS Data Schema

IM Information Model

JSON JavaScript Object Notation

NA Not Applicable

REST       Representational State Transfer

SMI Structure of Management Information

UML Unified Modeling Language

4          Overview

4.1      Documentation Overview

This document is part of a series of Technical Recommendations. The location of this document within the documentation architecture is shown in Figure 4 .1 below:

Figure 4 . 1 : ONF Specification Architecture

4.2      JSON Schema and JSON data

JSON Schema is a vocabulary that is used to annotate and validate JSON data documents. As stated in [3] , the advantages of JSON Schema include :

-             describes your existing data format

-             clear, human- and machine-readable documentation

-             complete structural validation, useful for automated testing and validating client-submitted data

On the other hand, JSON data or instance is the exact data exchanged over the API. Both JSON Schema and JSON data can be used for RESTful API specification.

In this document, UML-OpenAPI (RESTful API with JSON Schema) mapping guidelines will be specified.

5          UML- OpenAPI Mapping Guidelines

The UML- OpenAPI mapping rules are defined in table format and are structured based on the UML artifacts defined in [1] . For the JSON Schema Artifact in the table, <example text> means to replace the <example text> with “example text” in UML.

Example mappings are shown below the mapping tables.

Open issues are either marked in yellow and/or by comments.

5.1      Mapping of Classes

 

Table 5 . 1 : Class Mapping
(Mappings required by currently used UML artifacts)

Class “object” in "definitions" section

UML Artifact

JSON Schema Artifact

Comments

documentation “Applied comments”
(carried in XMI as “ownedComment”)

“description” substatement

Multiple “applied comments” defined in UML, need to be collapsed into a single “description” substatement.

Class Name

objec t name in "definitions" section:

“< Class Name>-c”

The “-c” suffix indicates that this object is a class in UML.

attribute s

Properties

See 5.2

object identifier

x-key / x-path

Note: Attributes used as object identifier are defined in UML by the attribute property “partOfObjectKey” >0 .

It is possible that the superclass or abstract class contains the key attribute for the instantiated subclass.

Generalization Class

Combining schemas from the generalized Class and the target Class together with “ allOf ” statement.

 

abstract

NA Not Applicable

 

isLeaf

NA

 

InterfaceModel_Profile:: objectCreationNotification
[YES/NO/NA]

object in "definitions" section

See 5.7 .
Goes beyond the simple “a notification has to be sent”; a tool can construct the signature of the notification by reading the created object.

InterfaceModel_Profile:: objectDeletionNotification
[YES/NO/NA]

object in "definitions" section

See 5.7 .
Goes beyond the simple “a notification has to be sent”; a tool can construct the signature of the notification by providing the object identifier of the deleted object (i.e., not necessary to provide the attributes of the deleted object).

InterfaceModel_Profile:: « RootElement»

NA

 

multiplicity >1 on association to the class

See 5.2 , the mapping of attributes with type = class

 

OpenModel_Profile:: « Reference»

NA

 

OpenModel_Profile:: « Example»

NA

 

OpenModel_Profile::lifecycleState

NA

 

Proxy Class ;
XOR ;

OpenModel_Profile:: « Choice»

NA

 

OpenModelClass::support

NA

 

OpenModelClass::condition

NA

 

Operation

See 5.5 , 5.6

 

Conditional Pac

NA

 

 

Table 5 . 2 : Class Mapping Example

        "TapiTopology -c ": {

            "description": "The ForwardingDomain (FD) object class models .. . ",

            "allOf": [

                {

                    "$ref": "#/definitions/GlobalClass"

                },

                {

                    "properties": {

                        "_linkRefList": {

                            "items": {

                                "type": "string",

                                "x-path": "/Tapi_Link/uuid"

                            },

                            "type": "array"

                        },

                        "layerProtocolName": {

                            "items": {

                                "type": "string"

                            },

                            "type": "array"

                        },

                        "_nodeRefList": {

                            "items": {

                                "type": "string",

                                "x-path": "/Tapi_Node/uuid"

                            },

                            "type": "array"

                        }

                     }    

  "required": [ "layerProtocolName" ]

                }

            ]

        }

 

5.2      Mapping of Attributes

 

Table 5 . 3 : Attribute Mapping
(Mappings required by currently used UML artifacts)

Attribute property (key-value pair):

Each key is the name of a property and each value is a JSON schema used to validate that property.

UML Artifact

JSON Schema Artifact

Comments

documentation “Applied comments”
(carried in XMI as “ownedComment”)

“description” substatement

Multiple “applied comments” defined in UML, need to be collapsed into a single “description” substatement.

Attribute name

Property name

 

Attribute type = Common Primitive Types

When Multiplicity 1:

"< attribute name>": {

"type": "<common primitive type>"

}

 

When Multiplicity >1:

"< attribute name>": {

"items": {

           "type": "<common primitive type>"

                 },

          "type": "array",

         }

Common PrimitiveType:

  1. string
  2. boolean
  3. integer

Attribute type =

Complex Data Type

When Multiplicity 1:

"< attribute name>": {

"$ref": "#/definitions/<attribute type>"

}

 

When Multiplicity >1:

"< attribute name>": {

"items": {

               "$ref": "#/definitions/<attribute type>"

                  },

                "type": "array",

                "x-key":"< attribute name>"

}

The < attribute name> for "x-key" should be a Common Primitive Type attribute with partOfObjectKey >0 within the Complex Data Type.

Attribute type = class

( Multiplicity 1)

When stereotype StrictComposite:
"< attribute name>": {

              "type": "string",

               "x-path": "/<attribute type>/< object identifier > "

}

 

When Aggregation=composite  and stereotype=StrictComposite:

"< attribute name>": {

                    "$ref": "#/definitions/<attribute type>"

}

Attributes used as object identifier are defined in UML by the attribute property “partOfObjectKey” >0 .

Attribute type = class

( Multiplicity >1)

When stereotype StrictComposite:

"< attribute name>": {

"items":{

"type": "string",

           "x-path": "/<attribute type>/< object identifier > "

                             },

                    "type": "array"

}

 

When Aggregation=composite  and stereotype=StrictComposite:

"< attribute name>": {

"items": {

             "$ref": "#/definitions/<attribute type>"

              },

              "type": "array",

              "x-key": "< attribute name>"

}

The < attribute name> for "x-key" should be a Common Primitive Type attribute with partOfObjectKey >0 within the class.

Multiplicity
(carried in XMI as
lowerValue and upperValue)

lowerValue =>   "minItems"

upperValue=>    "maxItems"

 

defaultValue

"default" : " < default Value> "

If a default value exists and it is the desired value, the parameter does not have to be explicitly configured by the user. When the value of “defaultValue” is “NA”, the tool ignores it and doesn’t print out “default” substatement.

isUnique

uniqueItems

Only apply to arrays. The value of this keyword MUST be a boolean.

If this keyword has boolean value false, the instance validates   successfully.  If it has boolean value true, the instance validates   successfully if all of its elements are unique.

If not present, this keyword may be considered present with boolean value false.

isOrdered

Not supported by OpenAPI

 

OpenModelAttribute::

valueRange

For integer and number typed attributes:
-- >  minimum, maximum,

exclusiveMinimum ,

exclusiveMaximum

When the value of “valueRange” is “null”, “NA”, “See data type”, the tool ignores it and doesn’t print out “range” substatement.

OpenModelAttribute::

partOfObjectKey >0

Array::“x-key” substatement

It is possible that the (abstract) superclass contains the key attribute for the instantiated subclass.

OpenModelAttribute ::

support=MANDATORY

Required Properties

 

OpenModelAttribute:: partOfObjectKey >0

NA

See the mapping of attributes with type= class and type= Complex Data Type

OpenModelAttribute::isInvariant

NA

 

OpenModelAttribute::unsigned

NA

 

OpenModelAttribute::counter

NA

 

InterfaceModelAttribute::unit

NA

 

InterfaceModelAttribute::writeAllowed

NA

 

InterfaceModelAttribute:: attributeValueChangeNotification

NA

 

InterfaceModel_Profile::bitLength

NA

 

InterfaceModel_Profile::encoding

NA

 

OpenModel_Profile:: « PassedByReference»

NA

 

OpenModel_Profile:: « Reference»

NA

 

OpenModel_Profile:: « Example»

NA

 

OpenModel_Profile::lifecycleState

NA

 

OpenModelAttribute::support

NA

 

OpenModelAttribute::condition

NA

 

 

Table 5 . 4 : Attribute Type Mapping Example

Attribute type = Common Primitive Types:

Cla ss1 ”: {
description ”: "This class models the..." ,
"properties": {
      “ class1Id ”: {"type": "string" } ,
      “ attribute1 ”: {"type": "string"} ,
      “ attribute2 : {

"items": {

                   "type": "integer"

"minimum": 0,

"maximum": 100,

                   },

                  "type": "array",

"minItems": 2,

"maxItems": 6

                }

attribute 3” : {
type ”: " boolean ",
"default" : true
}

attribute4 ”: {

"type": "string",

"enum": ["LITERAL_1","LITERAL_ 2 " ,

"LITERAL_ 3 "] ,

"default" : "LITERAL_ 2 "
}
     }

"required": [ class1Id ”, “ attribute1 ”, “ attribute 2”, “ attribute 3”, “ attribute 4” ]

}

Attribute type = Complex Data Type ( Multiplicity 1):

"routingConstraints": {

  "$ref": #/definitions/TapiRoutingConstraints-d"

   }

Attribute type = Complex Data Type ( Multiplicity >1):

  "explicitPath": {

      "items": {

           "$ref": "#/definitions/TapiPathElement-d"

            },

         "type": "array",

          "x-key": "_nodeEdgePointRef"

      }

Attribute type = class ( Multiplicity 1),

stereotype <StrictComposite >:

 

" _objectClass6 ": {

       "type": "string",

        "x-path": "/O bjectClass6-c / attribute 61"

}

 

Attribute type = class ( Multiplicity 1),

Aggregation=composite, stereotype=<StrictComposite >:

" _objectClass5 ": {

                    "$ref": "#/definitions/ ObjectClass5-c "

}

Attribute type = class ( Multiplicity >1)

stereotype <StrictComposite >:

" _objectClass6 ": {

"items":{

"type": "string",

"x-path": "/O bjectClass6-c / attribute 61"

             },

              "type": "array"

}

Attribute type = class ( Multiplicity >1),

Aggregation=composite, stereotype=<StrictComposite >:

"_objectClass5": {

      "items": {

       "$ref": #/definitions/ObjectClass5-c"

         },

      "type": "array",

      "x-key": " attribute 51"

}

 

5.3      Mapping of Data Types

Various kinds of data types are defined in UML:

  • Primitive Data Types (not further structured; e.g., Integer, String Boolean )
  • Complex Data Types (containing attributes; e.g., Host which combines ipAddress and domainName)
  • Enumerations

They are used as the type definition of attributes and parameters.

5.3.1 Generic Mapping of Complex Data Types

 

Table 5 . 5 : Complex Data Type Mapping

Complex Data Type “object” in "definitions" section

UML Artifact

JSON Schema Artifact

Comments

documentation “Applied comments”
(carried in XMI as “ownedComment”)

“description” substat ement

Multiple “applied comments” defined in UML, need to be collapsed into a single “description” substatement.

Complex Data Type Name

objec t name in "definitions" section:

“< Complex Data Type Name>-d”

The “-d” suffix indicates that this object is a Complex Data Type in UML.

attributes

Properties

See 5.2

XOR
OpenModel_Profile:: « Choice»

NA

 

OpenModel_Profile:: « Reference»

NA

 

OpenModel_Profile:: « Example»

NA

 

OpenModel_Profile::lifecycleState

NA

 

 

Table 5 . 6 : Complex Data Type Mapping Example

        "Capacity": {

            "description": "Information on capacity of a particular TopologicalEntity.",

            "properties": {

                "committedInformationRate": {

                    "type": "string"

                },

                "peakBurstSize": {

                    "type": "string"

                },

                "totalSize": {

                    "type": "string",

                    "description": "Total capacity of the TopologicalEntity in MB/s"

                },

                "committedBurstSize": {

                    "type": "string"

                },

                "packetBwProfileType": {

                    "type": "string"

                },

                "peakInformationRate": {

                    "type": "string"

                },

                "couplingFlag": {

                    "type": "boolean" ,

"default" : false

                },

                "colorAware": {

                    "type": "boolean"

"default" : false

                }

            }

"required": [ "totalSize" , "packetBwProfileType" , "committedInformationRate" ]

        },

 

5.3.2 Mapping of Common Primitive Data Types

A list of generic UML data types is defined in a “CommonDataTypes” Model Library. This library is imported to every UML model to make these data types available for the model designer.

Table 5 . 7 : Common Primitive Data Type Mapping

UML CommonDataTypes JSON Schema Types

UML Artifact

JSON Schema Artifact(type/format)

Comments

Boolean

boolean

 

String

string

The length of a string can be constrained using the minLength and maxLength keywords. For both keywords, the value must be a non-negative number.

«LENGTH_32_BIT» Integer

integer/int32

Signed 32 bits

«LENGTH_64_BIT» Integer

integer/int64

Signed 64 bits

Integer

«UNSIGNED, LENGTH_8_BIT» Integer

integer/int8

 

«UNSIGNED, LENGTH_16_BIT» Integer

integer/int16

 

«UNSIGNED, LENGTH_32_BIT» Integer

integer/int32

 

«UNSIGNED, LENGTH_64_BIT» Integer

integer/int64

 

«LENGTH_32_BIT» Real (float)

number/float

 

«LENGTH_64_BIT» Real (double)

number/double

 

DateTime

string/date-time

As defined by  date-time  - RFC3339

Uuid

Uuid

 

5.3.3 Mapping of Enumeration Types

 

Table 5 . 8 : Enumeration Type Mapping
(Mappings required by currently used UML artifacts)

Fixed Enumeration Type   “enum” statement

UML Artifact

JSON Schema Artifact

Comments

documentation “Applied comments”
(carried in XMI as “ownedComment”)

“description” substatement

Multiple “applied comments” defined in UML, need to be collapsed into a single “description” substatement.

literal name

enum value within enum array

The enum keyword is used to restrict a value to a fixed set of values. It must be an array with at least one element, where each element is unique.

Default type for enum value is string.

OpenModel_Profile:: « Reference»

NA

 

OpenModel_Profile:: « Example»

NA

 

OpenModel_Profile::lifecycleState

NA

 

 

5.4      Mapping of Relationships

5.4.1 Mapping of Associations

All associations (i.e., pointers, composition aggregations and shared aggregations) are per default passed by reference (i.e., contain only the reference (name, identifier, address) to the referred instance(s) when being transferred across the interface); except the «StrictComposite» and «ExtendedComposite» associations which are always passed by value (i.e., contain the complete information of the instance(s) when being transferred across the interface).

This lead to the following 3 kinds of association scenarios:

  1. Pointers, composition aggregations and shared aggregations which are passed by reference
  2. «StrictComposite» associations which are passed by value
  3. «ExtendedComposite» associations which can also be somehow treated as passed by value.

Please refer to Table 5 . 4   for the examples of associations mapping.

5.4.2 Mapping of Dependencies

Three different kinds of dependency scenarios need to be mapped:

  1. Dependency relationship annotated by the «NamedBy» stereotype
  2. Usage dependency relationship between an Interface and the object class the Interface is working on (along with the relationship name)
  3. Abstraction dependency relationship annotated by the «Specify» stereotype

 

The mapping rules for the first two kinds are for further study. For the third one, a new combined schema will be created by using “allOf” statement to combine the schemas from the specify Class and the entity Class together.

Table 5 . 9 : Dependency Mapping Examples

FFS

FFS

"entity_schema": {

       "allOf": [

        {

            "$ref": "#/definitions/entity"

         },

       {

"properties": {

         " example-attr-3": {

                "type": "integer"  },

         " example-attr-4": {

                "type": "boolean"  }

}

          ]

},

 

   "entity": {

        "properties": {

         " example-attr-1": {

                "type": "integer"  },

         " example-attr-2": {

                "type": "boolean"  }

}

}

 

5.5      Mapping of Interfaces and Operations

Table 5 . 10 : Interface and Operation Mapping

Interface and Operation Paths , Path Item and Operation Object

UML Artifact

JSON Schema Artifact

Comments

documentation “Applied comments”
(carried in XMI as “ownedComment”)

Operation summary

Multiple “applied comments” defined in UML, need to be collapsed into a single “ summary

Model name , Interface name

"description" and "title" field

 

Model name , Interface name, Operation name

"paths": {

"/operations/ <Model name>-<Interface name>:< Operation name> /

}

 

Operation name

Operation description

 

Operation name

Operation parameters description:

“< Operation name> body object”

 

input parameter

Operation parameters schema:{ "$ref": "#/definitions/ < Operation name> RPCInputSchema" }

 

Operation name

Operation parameters name

 

output parameter

Response 200 schema:{ "$ref": "#/definitions/ < Operation name> RPC Out putSchema" }

 

Operation name

Operation operationId

 

 

Table 5 . 11 : Interface/Operation Mapping Example

    "paths": {

        "/operations/TapiModule-Interfaces-Tapi_TopologyAPI : getTopologyDetails/":

{  "post": {

                "responses": {

                    "200": {

                        "description": "Successful operation",

                        "schema": {

                            "$ref": "#/definitions/GetTopologyDetailsRPCOutputSchema"

                        }

                    },

                    "400": {  "description": "Internal Error"    }

                },

                "description": "Create operation of resource: getTopologyDetails",

                "parameters": [

                    {  "required": true,

                        "description": "getTopologyDetailsbody object",

                        "schema": { "$ref": "#/definitions/GetTopologyDetailsRPCInputSchema"

                        },

                        "name": "getTopologyDetails",

                        "in": "body"

                    }

                ],

                "produces": [ "application/json" ],

                "summary": "Create getTopologyDetails by ID",

                "consumes": [ "application/json" ],

                "operationId": "createGetTopologyDetailsById"

            }

}

     "/operations/ TapiModule-Interfaces-Tapi_TopologyAPI : get Node Details/": { …}

        },

 

5.6      Mapping of Operation Parameters

 

Table 5 . 12 : Parameter Mapping

Operation Parameters “RPCInputSchema” or “RPC Out putSchema” properties

UML Artifact

JSON Schema Artifact

Comments

documentation “Applied comments”
(carried in XMI as “ownedComment”)

“description” substatement

Multiple “applied comments” defined in UML, need to be collapsed into a single “description” substatement.

direction

“RPCInputSchema” or “RPC Out putSchema”

 

Parameter

propert y

see 5.2 Mapping of Attributes

 

Table 5 . 13 : Interface/Operation/Parameter Mapping Example

C:\Users\t450\AppData\Local\Temp\WeChat Files\6E3D.tm.png

        "GetTopologyDetailsRPCInputSchema": {

            "properties": {

                "topologyId": {

                    "type": "string"

                },

                "layerProtocolName": {

                    "items": {

                        "type": "string"

                    },

                    "type": "array"

                },

                "topologyName": {

                    "type": "string"

                }

            }

        },

        "GetTopologyDetailsRPCOutputSchema": {

            "properties": {

                "topology": {

                    "$ref": "#/definitions/TapiTopology"

                }

            }

        },

 

5.7      Mapping of Notifications

Like the class mapping, the signals are mapped to “object” in OpenAPI’s "definitions" section.

Table 5 . 14 : Notification Mapping
(Mappings required by currently used UML artifacts)

Signal “object” in "definitions" section

UML Artifact

JSON Schema Artifact

Comments

documentation “Applied comments”
(carried in XMI as “ownedComment”)

“description” substatement

Multiple “applied comments” defined in UML, need to be collapsed into a single “description” substatement.

Signal Name

objec t name in "definitions" section:

“< Signal Name>-s”

The “-s” suffix indicates that this object is a Signal in UML.

attribute s

Properties

See 5.2

OpenModel_Profile:: « Reference»

NA

 

OpenModel_Profile:: « Example»

NA

 

OpenModel_Profile::lifecycleState

NA

 

OpenModelNotification::
triggerConditionList

NA

 

OpenModelNotification::support

NA

 

OpenModelNotification::condition

Proxy Class: See section 8.6 .

XOR: See section 8.3 .

NA

 

 

Table 5 . 15 : Notification Mapping Example

N otification A-s ”: {
    "properties": {
        attribute1 ”: {"type": "string"} ,

attribute 2 ”: {"type": "integer"} ,

  }

}

 

 

5.8      Mapping of UML Packages

The mapping tool shall generate a JSON Schema file per UML model.

According to the UML Modeling Guidelines [7] , each UML model is basically structured into the following packages:

Figure 5 . 1 : Pre-defined Packages in a UML Module

Table 5 . 16 : UML Packages Mapping Example

  "definitions": {  }

"paths": {  }

 

UML Package information (e.g. Model name, Interface name, Operation name , version , etc.) will be mapped to OpenAPI s Info Object . The generator shall generate the following information by using Info Object at the top of each JSON Schema file :

Table 5 . 16 : UML Package Information Mapping Example

UML Artifact

JSON Schema Artifact

JSON Schema Type

Description

Model name , Interface name, Operation name

title

string

Required. The title of the application , e.g. Model name+ Interface name + Operation name ”.

Model name , Interface name, Operation name

description

string

A short description of the application. GFM syntax can be used for rich text representation. E.g. Model name+ Interface name+ Operation name generated from UML by UML2OpenAPI tool ”.

Tbd

termsOfService

string

The Terms of Service for the API.

Tbd

contact

Contact Object

The contact information for the exposed API.

Tbd

license

License Object

The license information for the exposed API.

Tbd

version

string

Required Provides the version of the application API (not to be confused with the specification version).

 

For example :

title: Swagger Sample App

description: This is a sample server Petstore server.

termsOfService: http://swagger.io/terms/

contact:

  name: API Support

  url: http://www.swagger.io/support

  email: support@swagger.io

license:

  name: Apache 2.0

  url: http://www.apache.org/licenses/LICENSE-2.0.html

version: 1.0.1

 

6          Tool – User Interactions

Some features of the mapping tool need additional instructions from the user which are gathered by the tool in interactions with the user.

6.1      General items

The tool needs to ask the user for the following information:

  1. Add suffix “- c ” to the object classes : No|Yes (default: No).
  2. Add suffix “- d ” to the complex data types : No|Yes (default: No).

6.2      Lifecycle State Treatment

UML elements are annotated by at least one of the following lifecycle states:

  • «Deprecated»
  • «Experimental»
  • «Faulty»
  • «LikelyToChange»
  • «Mature»
  • «Obsolete»
  • «Preliminary».

The tool shall allow the user to select – based on the lifecycle states – which UML elements are mapped; default is Mature only.

 

7          Contributors

Ruiquan Jing ( E d itor, China Telecom)

Guoyong Zhao ( China Telecom)

Hing-Kam Lam (FiberHome)

Nigel Davis (Ciena)

Bernd Zeuner (Deutsche Telekom)

Chris Hartley (Cisco)

Italo Busi (Huawei)

Karthik Sethuraman (NEC)