gfse / sysml-specif-bridge Goto Github PK

wrt SysML to SpecIF transformation tables:

An EA-Element.Type 'Component' is a FMC:Actor, because it can be seen as an agent modifying states. Of course, a 'Component' may also internally contain states (= store information), but a piece of software or a mechanical part is best regarded an actor when seen from external (according to my experience or prior usage). A BoM is in my eyes more intuitively seen as a collection of actors than a collection of states.

Let's discuss.

In the class definitions the term "PC-UML_Multipilcity" is being used in several places. It seems there is a typo and it should be "PC-UML_Multiplicity".

I would like to add a SourceCode resource class to the base elements in SpecIF. In https://github.com/GfSE/SysML-SpecIF-Bridge/blob/master/classDefinitions/406_UML_ResourceClasses.specif you can find a proposal:
{
"id": "RC-UML_SourceCode",
"title": "UML:SourceCode",
"description": "Source code assigned to a model element (e.g. an activity or operation).",
"propertyClasses": [
"PC-Name",
"PC-UML_ImplementationLanguage",
"PC-Value"
],
"revision": "main/1",
"replaces": [],
"changedAt": "2019-03-24T12:00:00+02:00"
}
The ImplementationLanguage property holds avalue like Java, C, C#, OCL etc.
In the value-property the source Code (complete or part/snipped) is included.
I do not know if there is a still stndardized proposal existing.

To avoid defining a special statement for each connector type, I used in my prototype implementation the dcterms:type property and a very general Statement class (UML:Relationship).

You, @odungern have defined different types of statements to map SysML connectors in your SpecIF example (Small Vehicle).

How should we proceed in this case? Define a lot of special statement classes or use one and use a type property?

Last week we discussed if the statements SpecIF:preceds, SpecIF:triggers and SpecIF:signals can be combined to one statement. When combined there is no information lost, because the type of the connection is already given by the two resources that are connected together.
One idea was to replace all three statements with the statement SpecIF:signals. Other ideas could be SpecIF:continues, SpecIF:commences or SpecIF:activates. What do you think? Which statement fits best for the application?

In the FMC4SE systems engineering extension the communication channel (circle symbol) is replaced by "UML Ports". These ports are sub-elements of the component element. The advantage of that approach is, that you can seperate and reuse a component without loosing the interface information.

The figure above shows the principle.
Now it is possible to model a connection between two active components in 2 different ways:

1. A direct connector line from one port to the next port
2. A connection from the first port to an explicit modeled passive element and a second connection from the passive component to the target port:
   
   In the example above you can see an example of a direct connection (Electronic Document) and a passive element in between (Invoice Document).

How should we map this to SpecIF?

How should an object flow with no direction (---) or bi-directional (<->) represented in SpecIF?
For uni-directional (-->) it is clear for me: This is SpecIF:writes. But how represent the other two cases that can occur in models?

wrt SysML to SpecIF transformation tables:

I propose to map a EA-Element.Type 'Package' to a SpecIF resourceClass 'SpecIF:Collection'. This resourceClass is also used by a BPMN 'Group'.

(A SpecIF:Heading is used for headings in documents, in case there is no model element for a logic grouping).

Thanks @oalt for preparing the SysML to SpecIF transformation table !

May I suggest:

• to rename column 'SpecIF-Element' by 'SpecIF resourceClass'
• to add a column SpecIF:SubClass to specify the vocabulary term signifying the type of element.

For example a SysML start event would be assigned a resourceClass named FMC:Event and get a property named 'SpecIF:SubClass' with a value 'SpecIF:startEvent'. The values of 'SpecIF:SubClass' should be used by all modelling notations (SysML, BPMN and others) to allow model integration.

Currently the property set of the FMC resource elements is limited to three elements (https://github.com/GfSE/SpecIF/blob/master/classDefinitions/03_FMC%20Modeling/403_ResourceClasses.specif)

• "PC-Name"
• "PC-Text"
• "PC-Status"

To be able to map the UML data to the FMC base elements without using inheritance and new resource classes, the following properties are needed additionally:

1. Visibility Kind (public, protected, private etc.) - not yet a standard property in SpecIF
2. SpecIF:Stereotype
3. dcterms:type - Information of the original metatype (e.g. OMG:UML:2.5.1:Class) - not yet a standard property in SpecIF
4. rdf:value - property to save a value of different meaning, depending on the element type (Attribute Default value, a taggedValue value etc.) - not yet a standard property in SpecIF
5. SpecIF:Alias - an alias Name - not yet a standard property in SpecIF
6. SpecIF:SubClass - The sub-class of the element

I think with these few extensions, the most data of UML elements can be transformed to SpecIF-FMC. @odungern: What do you think?

If you agree, I can extend the class definitions for FMC modeling and the base-property definitions in the SpecIF repository.