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

Full resolution (987 × 689 pixels, file size: 30 KB, MIME type: image/png)

• Relation between all elements of the Architectural Concepts metamodel

Full resolution (1,187 × 678 pixels, file size: 71 KB, MIME type: image/png)