Projects and Models Management

Projects & Models 101

A project in PHENOM is composed of one or more models which are loaded together into a workspace. A model is a collection of nodes. A node can be an entity, an association, an observable, a view… One objective of a project is to be:

• Independent
• Complete: reflect the reality to the best of its ability
• Compliant
• Valid (or at least "validatable ")

A model in and of itself might not constitute a complete, compliant, or even valid project as it might depend on entities inside other models, making it impossible to load independently. However, by combining several models in a project, they can form a complete, compliant, and valid model.

The following diagram depicts how a model can be part of multiple projects.

Once a project is loaded into PHENOM, the node contents of its constituent models can be added to as well as edited. If a user has multiple projects, he needs to decide which project he loads into his workspace to be able to view and edit it. He can easily switch between projects in the Projects Management page.

Project and Model management

When in PHENOM > Manage Models > Projects, the user can see the projects and models that he has access to.

To create a project, the user can click on the + button in the Projects list and then select existing models, import new FACE models, or add new blank models.

There are three ways a user can have access to a project or a model:

• He creates it
• He uploads it
• Another user gives him permission to it

The user will see, for each model, its inheritors and versions.

Model versions

In PHENOM, models maintain the content as well as the record of changes made to that content. By default, each model has a "live" version. This is the version of the model which, when loaded in a project workspace can be edited and amended. When the user is satisfied with the current state of a model, he can publish it, thus creating a “static” version of that model. A published version of a model is a snapshot of its content at one point in time. It cannot be added to or edited but can still be included in a model workspace, referenced by and depended upon by the contents of a different sub-model. In the example below, the sub-model version SDM_V-1 is a "published" version of the SDM sub-model. While it can be shared with other users, included in model workspaces, and referred to and depended upon by other sub-models, it can never be edited.

Sub-Model Inheritance & Content Merging

The same sub-model can be added to and loaded as a part of several different models workspaces. However, the users of those model workspaces will not be able to edit the content of the sub-model simultaneously. When a user chooses to include in a model a sub-model which is already a part of a different model, a "child" sub-model will be created. This inheriting or "child" sub-model is not a different version of a sub-model, but rather its own sub-model which inherits some portion of its content. At first, the inheriting and the parent sub-models are identical but as their respective user make changes, they grow apart. Therefore, it’s possible for this "child" sub-model to merge its changes to and from the parent sub-model. A user can see the relationships between sub-models in PHENOM > Manage > Branch > Sub-Model Manager. In this example, the sub-model DSDM is the parent of the sub-model DSDM_IN_RIELY_S_INTFC_DOC. This results from the DSDM_LIVE version of the DSDM sub model being loaded into a new model workspace. When edits are made in either the parent or child sub-model, the changes can be merged between them.

Sample Workflow

This section goes over a sample workflow which employs the PHENOM model structure concepts described in the sections above. In the scenario laid out below, a group of users, Chris, Dave, Nick, and Riley are working on different parts of completing a data model and documenting a set of interfaces against it. Each of them plays a slightly different role in the process, and they will use some of PHENOM's Model management features to keep their work organized. Pt. 1 - Chris Chris is working on updating the Shared Data Model (SDM) the group is using to conform to the latest changes released in an accepted standard. He loads an SDM content file to create a sub-model.

He loads the sub-model into an SDM_Editor model workspace and begins to make the changes.

Once he has made the changes necessary to match a decided-upon standard, he publishes a version v1 of his SDM sub-model.

Chris is going to make further changes in the SDM_Editor model, but that will be for the next standard update. In the meantime, he wants to make the static version of the SDM he just published available to the rest of his team, so he gives them permissions to it. However, making further changes to the SDM is his job and he wants to stay in control of the process, so he does not give any of his colleagues permissions to either the live version of the SDM sub-model or the SDM_Editor model workspace.

Pt. 2 - Dave Dave is working on creating a Domain Specific Data Model (DSDM) for the team to use - he will be referencing the SDM Chris released in his efforts. He creates a new model workspace into which he adds the SDM version he has access to and a blank sub-model which will contain the DSDM content he creates.

After he has added some content to his DSDM sub-model which references nodes in the SDM, he will see that his DSDM sub-model is now listed as dependent on the SDM sub-model he has been using – which means, it can no longer be loaded without it.

NOTE THAT THE SUBMODEL SECTION AT THE TOP RIGHT OF THE PAGE LISTS DSDM_LIVE AS THE HOME OF THE ENGINE ENTITY. Nick and Riley will be documenting some interfaces against the domain model that Dave is working on. However, Dave does not want them to have to wait for him to have finished with all of his work before they can start. Also, as they work on their interface documentation, they may come up with good changes to the DSDM and suggest that they be included in Dave's work. So, Dave decided to share his model workspace with Nick and Riley, which automatically gives them permissions to the active DSDM sub-model version he's working on.

Pt. 3 – Nick & Riley Nick and Riley will be documenting interfaces using the DSDM that was shared with them, but they will be working with different sets of interfaces, each in his own model workspace. If they try to create a new model workspace with just the DSDM, they will be rejected because they must also load in the SDM that was used to create it and on which it depends.

Once they have the appropriate permissions to all of the content, they can create their individual models with the sub-models to house their documentation work separate from the contents of both the SDM and the DSDM. In the example below, Riley creates a RILEY_s_INTFC_DOC model including the DSDM_live sub-model and a new blank sub-model for his changes. By doing so, a new sub-model, DSDM_IN_RILEY_S_INTFC_DOC, was created, inheriting from Dave’s DSDM_live.

Dave and Riley will now be able to independently edit DSDM content and merge changes between their two sub-models as they see appropriate. Whenever Dave makes new updates to the DSDM, Nick and Riley have the opportunity to pull in those changes into their copies of the sub-model. When either one of them makes a change to the DSDM portion of his model that he thinks should be included in the official version, they can make a push request to Dave's model that he can then either approve or ignore.