ESF Metamodel Profile conventions

Naming conventions

For differing profiles and models of the packages:

• NC1. All profiles and models are prefixed by 'ESF'.

• NC2. All packages are prefixed by 'S'.

For example, if you add a new profile (or subprofile), you must name this profile like "ESFNewProfile". But, if you add a new package to the profile, you must name it like "SNewPackage".

General naming convention for profiles, models and packages:

• NC3. Names for profile, models or packages are in plural. Except for some cases like ESFCore.

We are using concepts similar to UML and SysML. For example, in ESFArchitectureConcepts there is the concept of Block as well aw in SysML. But they have different meanings. The solution is adding a prefix:

• NC4. Prefix 'S' must be use for all ESF concepts (e.g., SBlock, SModel, etc.). 'S' corresponds to Safety and Security also.

But there are the prefixes which are preemptive on the previously convention:

• NC5. The nature prefix 'Abstract', 'I', etc. is preemptive on the 'S' prefix. We should have AbstractSElement for example.

In case of the properties which have the higher cardinality to 1:

• NC6. All properties with higher cardinality to 1 are suffixed by 'List'. For instance, SBlock has a property sPortsList whose cardinality is [0..*].

Development points

• Proposition P1. For shared safety object among package a solution might be to have Interfaces in both package, and Implementation only on one to simplify both coding and usability of the concept.

• Decision D1. Profile is linked to UML Element.

• Decision D2. Multi-heritage should be avoided, use of proxy and association is privileged (e.g., SFailureMode and SEvent).

• Question Q1. How to define the container for ESFObjects? A solution might be to add a tooling profile!

• Question Q2. Do we need a top NamedElement metaclass extension or a solution based on more low-level metaclass extensions?