Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different representation of relationships in the diagram, openapi schema, and plugin implementation #4

Open
Fak3 opened this issue Jan 13, 2020 · 0 comments

Comments

@Fak3
Copy link

Fak3 commented Jan 13, 2020

In the doc there is a uml diagram of how a relationship is linked with Entity:
Screenshot_20200113_235529
Which implies that Entity json object has a source json key with a value that contains a Relationship json object, which in turn has target json key with a value that contains only identifying property(ies) of a target Entity. For ex:

{
  "name": "TransportMovement",
  "source": [
    {
      "name": "usedTransportMeans",
      "description": "The means of transport used for this logistics transport movement.",
      "type": "references",
      "minCardinality": 0,
      "maxCardinality": 1,
      "target": {
        "name": "TransportMeans"
      }
    }
  ]
}

Diagram defines 3 possible values of type:
Screenshot_20200114_001622

The openapi schema referenced from the interchange spec is called JSON Schema (which it is not): https://edi3.org/specs/edi3-model-interchange/develop/#json-schema-1. This schema defines standalone Relationship object, not nested under Entity, in contrast to the uml schema given above.

The current model-interchange staruml plugin does something different:

  • nests Relationship under the Entity object which this relationship is sourced from, but call this attribute "Relationship"
  • uses composition/aggregation/associationClassLink/generalization/interfaceRealization/interface as Relationship type, instead of 3 possible types defined in diagram (screenshot above).
  • has both source and target json keys, instead of just target
  • does not have minCardinality/maxCardinality, but instead have cardinality under both source and target json sub-objects.
  • source and target json sub-objects also have property "type": "Entity" and "navigable": true

example:

    "LogisticsLocation": {
        "type": "Entity",
        "name": "LogisticsLocation",
        "isAbstract": false,
        "description": "A logistics related physical location or place.",
        "version": "",
        "status": "",
        "Required": [
            "Unlocode"
        ],
        "Property": [
             ...
        ],
        "Relationship": [
            {
                "name": "PostalTradeAddress",
                "description": "The postal trade address information for this logistics related location.",
                "type": "interface",
                "source": {
                    "name": "LogisticsLocation",
                    "type": "Entity",
                    "cardinality": "",
                    "navigable": true
                },
                "target": {
                    "name": "TradeAddress",
                    "type": "Entity",
                    "cardinality": "0..1",
                    "navigable": true
                }
            }
        ]
    }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant