Data Model

PHENOM can generate a number of different data model formats and documentation artifacts from the current project.

Filter

The first drop down in the page allows the user to filter the model and the Nav Tree to only what is relevant for generation.

• None: no filter is applied
• Services: only display the services in the Nav Tree and only services will be exported (along with any elements necessary to export a valid model)
• Views: only display the views in the Nav Tree and only views will be exported (along with any elements necessary to export a valid model)
• Tags: the tag filter currently applied in the Nav Tree will be applied to the model upon export (necessary elements to make the model valid will be exported as well)

Generate Models & Artifacts

The user can then choose the type of artifact to generate. Each type of artifacts has its own generation options.

FACE (.face)

export the data model in FACE XMI format

Diagrams (.zip)

exports all the user-created diagrams as PGN files in a ZIP archive

IDL (.idl)

export the data model in Interface Description Language (IDL) format

Skayl (.skayl)

export the data model in Skayl's Proprietary Format (similar to FACE XMI, but this preserves the non-standardized integration model content)

User Template

export the data model using user templates

Artifact Descriptions

.face v2.1 XMI This is the canonical form for all Future Airborne Capability Environment (FACETM) version 2.1 data models. This style of model uses projection paths to capture data model semantics. It is a .face file in a customized version of the XMI file format.

.face v3.0 XMI This is the canonical form for all Future Airborne Capability Environment (FACETM) version 3.0 data models. This style of model uses queries and templates to capture data model semantics. It is a .face file in a customized version of the XMI file format.

.face v2.1 XMI obfuscated This is the canonical form for all Future Airborne Capability Environment (FACETM) version 2.1 data models. This style of model creates ambiguity with data model semantics. It is a .face file in a customized version of the XMI file format.

.html This is a mini-website. Each element of the data model is provided as a simple HTML file that can be clicked around and navigated in a web browser.

.docx This is a Word Document form of the data model. It captures all of the data model contents in a printable form.

.xml UML XMI This is an XMI version 1.2 file as exported by Sparx Systems Enterprise Architect. While it is intended to be a portable, model interchange file, the portability is limited by the implementation of the XMI reader.

.cpp TSS API View Classes This option will generate all of the classes needed to connect all defined interfaced to a FACE v2.1 Transport Service Segment (TSS). These classes conform to and can be used with the TSS API.

.cpp User Template Generated Choose this option to select from the available user templates.

Using Templates

Project data can be used to fill a file with a custom format that fulfills a user's requirements. To do this, the user must select 'User Template' from the File Type menu and then choose a valid template for Phenom to use. Model generation via a user template can be combined with tag reporting to delineate which nodes in the project should be used for the code generation.

Information about creating and editing templates can be found here.

Enumeration behavior

Phenom manages the relationships between Platform Enumerations, their Platform Enumeration Literals, and the Labels traced through the Measurement realized by the Platform Enumeration. Using the PDM Type Editor, a user can manage these relationships in Phenom:

Platform Type/Enumeration editing

Depending on how Platform Enumerations are managed by the modeler, Phenom will shape the project content on FACE export to reflect the status of each Enumeration. There are 3 groups of behavior for model export:

Matching: The Enumeration has been configured such that all Platform Enumeration Literals have a realizes relationship to a Label of the same name, and there is a Literal for every traced Label. No changes will be made to the export.

Subset: The Enumeration has been configured similarly to the matching case, however instead the Platform Enumeration Literals subset the traced Labels. In this case, a separate Measurement/Measurement Axis/Value Type Unit and Constraint are added specifically for this Platform Enumeration. The constraint's allowedValue contains the GUIDs of the previous ValueType's constrained labels.

Missing-realize/Mismatched: The Enumeration either doesn't perfectly realize matching Literals→Labels, or has differences/duplicates in the naming used. In these cases, new LDM content is generated just like the Subset case; however, to preserve the context of the Platform Enumeration's Literals, a new ValueType is also generated, with Labels matching the names of the Platform Enumeration.

To manage Enumerations of the last group, please check the Health Report:

Health Check