View source for Tech Meeting 2015 04 21@CEAList

== Present ==
* Yupanqui Munoz (CEA List)
* Matthieu Perin (CEA List)
* Jonathan Dumont (All4tec)

== Minutes ==
=== Work on the ESF Meta-model ===

Two major subsets : ''ArchitecturalConcepts'' (for link with the system engineer objects) & ''SafetyConcepts'' (that hold all the element types for the safety related actions : object containing data, analysis, ...).

==== General consideration ====
* Model organisation
 '''Decision D1''' Our model will address different view points and domains. It must be split in several and independent models. 
 For example, the ''Process'' and the ''ViewPoint'' models must be separated.

==== Analysis of ''ArchitecturalConcept'' ====
* Naming conventions
We are using concepts similar to UML and SysML. For example a ''Block'' in ESF and a ''Block'' of SysML. But they are different. Using a prefix might be a solution ? But users uses objects by their names so prefixing might be confusing...
 '''Decision D2''' Prefix "S" must be use for all ESF concepts (''SBlock'', ''SModel'', etc.). 'S' corresponds to Safety and Security also.

* Conception strategy
We are designing a model to represent an architecture. 
 '''Decision D3''' Our objective is to be as closed as possible to the standard UML/SysML concepts.

* Port direction
We need to have the direction of the ''SPort'' clearly defined. We must also manage the INOUT direction, as in SysML.

* Link between Connector & Port
Use one or two associations ? Do we need a constraint between the connector's ends ? Moreover, the ''SConnector'' needs to know it's ends, and it can be ''SPort'' or ''SPortRole'' instances, according to the context. A solution might be to add an abstract object ''SAbstractConnectableElement'' from which ''SPort'' and ''SPortRole'' inherit. 
 '''Decision D4''' Keep only one association of multiplicity '2..*', between ''SAbstractConnectableElement'' & ''SConnector'' in ''ArchitecturalConcepts''. 
 The multiplicity is chosen to be compliant with what can be done in UML.
 
 '''Decision D5''' ''SPort'' and ''SPortRole'' must inherit from ''SAbstractConnectableElement''.

* Connector role : assembly and delegation ?
A ''SConnector'' can link a ''SPort'' (port of a block) and a ''SPortRole'' (port of a part), or between two ''SPorts''. These connectors can be distinguished by a delegation or an assembly role. Must it be different concepts or not ? 
 '''Decision D6''' Keep only one ''SConnector'' concept, the delegation and assembly role will be managed by the standard UML property of ''Connector'' : 'kind'.

* PortRole concept
This concept corresponds to the port used by a connector in the context of a ''SPart''. But the problem of ''SPortRole'' is that it have to be hold by an UML element in the profile implementation... A solution might be to use ''Class"" everywhere, or ''Instance specification''. Another solution is to map it to a ''Property'', which can own other properties but only using association. It's not a real aggregation. Using classes everywhere can work, but we miss all the interests of using UML : The owned objects are not deleted with their parent, for example. 

 '''Decision D7''' ''SPortRole'' should be an owned Property of ''SBlock''.
 A constraint must be added to ensure that a ''SPortRole'' owner is the same owner that the ''SPort'' that it roles.
 
 '''Decision D8''' ''SPart'' should be an owned Property of ''SBlock''
 
 '''Decision D9''' ''SPort'' should be a owned Port of ''SBlock''
 
 '''Decision D10'''  All elements are linked to their relatives (for example ''SPort'' to ''SPortRole'), so tooling should take in account the propagation of an element deletion.
 Indeed, as the ''SPortRole'' is not owned by a ''SPort'', the deletion of the ''SPort'' won't automatically delete the corresponding ''SPortRole'' instances.

* TopBlock concept
A model can have several ''Blocks''. But amongst these ''Blocks'', only few of them are at the model top level.
 '''Decision D11''' ''topBlock'' should be a derivated boolean property of ''SBlock''. 
 Its value is true if the ''SBlock'' doesn't have any usage (''SPart'' with this ''SBlock'' as type).

 '''Decision D12''' It is not possible to link two top blocks ! To do this, use a parent top block to define their communication context.

==== Architectural Concepts metamodel (Meeting Result) ====
* Overview of all elements of the Architectural Concepts metamodel
[https://polarsys.org/wiki/images/d/d1/ArchitecturalConcepts_metamodel_Overview.png Full resolution] (987 × 689 pixels, file size: 30 KB, MIME type: image/png)
[[File:ArchitecturalConcepts_metamodel_Overview.png| 800x558px]]

* Relation between all elements of the Architectural Concepts metamodel
[https://polarsys.org/wiki/images/e/e4/ArchitecturalConcepts_metamodel.png Full resolution] (1,187 × 678 pixels, file size: 71 KB, MIME type: image/png)
[[File:ArchitecturalConcepts_metamodel.png| 800x457px]]