COMET Data Model - STARIONGROUP/COMET-SDK-Community-Edition GitHub Wiki
Introduction
The CDP4-COMET Data Model is a UML model that contains the concepts and their relationships that are used to perform Concurrent Design. The CDP4-COMET Data Model is derived from ECSS-E-TM-10-25A-Annex-A. Due to the fact that the CDP4-COMET Data Model is a pure extension of ECSS-E-TM-10-25A-Annex-A the implementations of it are 100% interoperable with other ECSS-E-TM-10-25A-Annex-A implementations. The COMET-SDK, the CDP4-COMET Desktop Application and the CDP4-COMET Web Services are all implementations of the CDP4-COMET Data Model.
Containment
Containment, or composite aggregation, is an important aspect of the CDP4-COMET Data Model. All concrete classes, and most abstract classes, are accessible via the so-called containment hierarchy. This mechanism is supported in the COMET-SDK, but also provides the mechanism to access data via the REST API that is described in [Annex C]]. The [CDP4-COMET Data Model is partitioned along 2 containment hierarchies starting at SiteDirectory and EngineeringModel. Both the SiteDirectory class and the EngineeringModel class derive from the abstract super class TopContainer.
SiteDirectory: The Site-Directory is a singleton that represents an instance of one Concurrent Design repository, e.g. the CDP4-COMET Web Services. It contains all the information regarding the different Engineering Models, Reference Data and users that exist in that repository.
EngineeringModel: An Engineering Model represents a Concurrent Design activity or project that is performed on a Concurrent Design repository. It contains concepts to capture the problem specification, e.g. the requirements, and the solution, e.g. a parametric architecture.
The DTO and POCO classes expose methods to interact with this containment hierarchy or route. The route of an object starts at a TopContainer, either SiteDirectory or EngineeringModel, and follows the properties that express an aggregate composition relationship. An example:
An
Email Addressis contained by aPerson. APersonis in turn contained by theSiteDirectory. The route is expressed as follows:SiteDirectory\{iid}\person\{iid}\email\{iid}
Note that this route contains the {iid} symbol. This is the unique identifier of the object. Also not that only SiteDirectory is Capitalized, all the other parts of the route are in lower-case only.
ECSS-E-TM-10-25A-Annex-A Extensions
The following paragraphs provide a high-level overview of the concepts that are added to the CDP4-COMET Data Model as extensions of ECSS-E-TM-10-25A-Annex-A. These extensions are based on concepts used in the CDP3, the Starion Group Concurrent Design Platform that the CDP4-COMET is an evolution of. The CDP4-COMET extensions, both classes and extra properties on existing classes, have been modelled in the UML master model and have been decorated with a CDPVersion stereotype. Plain or vanilla ECSS-E-TM-10-25A-Annex-A has an implicit version of 1.0.0. The version scheme follows Semantic Versioning.
The following table specifies the released versions of ECSS-E-TM-10-25A-Annex-A and how these map to CDP4-COMET version numbers. The CDP4-COMET extensions will increase the MINOR and PATCH version numbers. The ECSS-E-TM-10-25A-Annex-A version updates will increase the MAJOR version
| ECSS-E-TM-10-25A-Annex-A | CDP4-COMET meta-model Version | Comment |
|---|---|---|
| 2.4.1 | 1.0.0 | plain ECSS-E-TM-10-25A-Annex-A |
| 2.4.1 | 1.1.0 | ECSS-E-TM-10-25A-Annex-A wtih CDP4-COMET exentensions |
| 2.4.1 | 1.2.0 | ECSS-E-TM-10-25A-Annex-A wtih CDP4-COMET exentensions |
Person and Domain-Of-Expertise permission handling
The CDP4-COMET Data Model contains a mechanism to express the authorization or Permissions a Person or model Participant has by means of the PersonRole and the ParticipantRole classes. In essence, a role can be defined which has read or read-write access to a data model type or ClassKind.
Example:If a Participant has read access to
ElementDefinitions, that Participant has read access to allElementDefinitions in an Engineering Model.
While this is suffucient for most use cases, sometimes it is not, and certains Persons or Domains of Expertise should be excluded from being able to read/write a specific instance. This is achieved by means of the following attributes on the Thing class.
- excludedDomain: A list of DomainOfExpertise that is not authorized to read or write the Thing. A DomainOfExpertise cannot be excluded from it's own DomainOfExpertise
- excludedPerson: A list of Person that is not authorized to read or write the Thing. A Person cannot be excluded from it's own Person.
Ad-Hoc reporting
description coming soon
Diagrams
description coming soon
Stakeholder Value Mapping
description coming soon