This is software supplied "as is" with no warranty or statement that it is "fit for purpose".
This repository contains Python scripts that can be used to transform an OpenAPI 3.0 Specification to an XMI file that can be imported into the Sparx EA tool. This XMI file can be imported as a UML class model.
This resulting model provides the following features:
- Name of the input file is used as the name for the model, with "OAS_" used as a prefix.
- Name of the input file is used as the name for the root class, with "EARootClass_" used as a prefix.
- Class name
- Class description
- Property name
- Property description
- Property data type (maps to "Type")
- Property example value (maps to "Initial Value")
- Property format (maps to "Alias")
- Object properties link to their corresponding classes, as a directed association.
- Array properties link to their corresponding classes, as a directed association with name array.
- oneOf relationships link between classes, as a directed association with name oneOf.
- anyOf relationships link between classes, as a directed association with name anyOf.
The scripts have been built solely based on the requirements of DCSA, and may not work for general OpenAPI Specification files. In particular, the scripts expect a fully self-enclosed description without references to other files.
The output is in the Sparx XMI 1.1 format. This format is based on the OMG XMI format (https://www.omg.org/spec/XMI/), although there are a large number of proprietary extensions in "tagged values". The scripts have been built by reverse engineering the output from Sparx models in order to gain understanding of these tagged values.
It is believed that the XMI 1.1 format is preferable to the XMI 2.x format because it is easier to work with updates to models.
Newly generated UUIDs are used to populate the model. Note that the option to "ignore UUID" can be used in SparxEA import in order to update a model.
There are two scripts.
convert_oas_to_xmi.py
This script takes the OAS input and converts it to a basic XMI format, without creating any relationships between classes. Information on relationships between classes is included in the type information. This may be appropriate for some approaches, and it divides the scripts up into two components for easier maintenance / development. This provides a useful waypoint where users could add additional processing as required.
The script takes two parameters:
convert_oas_to_xmi.py INPUT_FILENAME OUTPUT_FILENAME
add_dependencies_to_xmi.py
This script takes the output from convert_oas_to_xmi.py and adds relationships between the classes. This is based entirely on the information on attribute and class types that was generated by that script.
The script takes two parameters:
add_dependencies_to_xmi.py INPUT_FILENAME OUTPUT_FILENAME
Although it is common practice to combine the two scripts, in their current form they cannot be connected directly via a pipe.