Tech Meeting 2015 06 8@CEAList

Present

• Matthieu Perin (CEA List)
• Nataliya Yakymets(CEA List)
• Yupanqui Munoz (CEA List)
• Jonathan Dumont (All4tec)
• Anne-Catherine Vie (All4tec)

Minutes

Objectives

Finalize Concepts metamodel for safety, and propose a first Stereotype.
Review of the cleaned version of the metamodel.
PM: Advance on UML implementation of the metamodel for ESFCore & ESFARchitecureConcepts

Meeting

Decision D1 SBehavior should be like SProperty out of ESFSafetyConcept and be a more generic I/O package. (answer to Q1 in previous meeting).

Proposition P1 In SEnvironement, SMode is a first proposal and should be reviewed later.

Decision D2 SEnvironement is renamed as SDysfunctions 

Question 1 There is  some objects in package SDysnfunctions with multiples heritage (e.g. Failure from SEvent -> AbstractSElements & 
from AbstractSDysnfunctionObjects -> AbstractSElements). Issue with this in UML might be solved using redefined variables.
To investigate.

Decision D3 SHazards & SRisks have been added to SDynsfunctions Package.

Decision D4 SSeverity, SOccurency, SCosts & SDetectability  have been added to SProperty Package.

Decision D5 An AsbtractedSPorpertyObjects have been added in ESFPorperties

Proposition P2 SProbability have been moved from SProperty to SBehaviours.

Question Q2 In SBehaviours, should SProabbility inherit from AbstractBehaviourOjects or AbstractSElements ?

Decision D6 The Analysis (e.g. ESFFmea) are directly linked to elements of ESFCore.

Question D7 Why ESF and S prefix ? => all Models are ESF prefixed (e.g. Core, FMEA), packages & objects are S prefixed.

Question Q3 How to define the container for ESFObjects ? a solution might be to add a tooling profile !

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