let me please formulate some comments and proposals on the Capela/Arcadia concepts as presented in the webinars:
In addition to what Rafael Godzilla mentions in his comment, also the term “Situation” is arguable. A situation is extrinsic, it relates “to a position (location) or a set of circumstances”, i.e. to the context of the subject, to the environment it is in, rather than to the intrinsic state/mode etc. of the subject. A “system condition” could be a better name: the system is in a condition comprising a particular operational mode and a certain externally induced state.
At it says “to be able to distinguish different occurrences of each element and to be able to give them different properties or values”. Well, either it is not an “occurrence” of the same “element” or it cannot have “different properties” (just values). If an element has a different property than it is simply a different element, though it may be derived, mixed-in, aggregated in or in any otherrelation to the other element. The term “usage-based modelling” used in this presentation just obliterates and blurs the essential concepts of “class” vs. “instance”.
Could you pls direct me to the part of OMG RFP SysML v2, where the “usage-based modeling” has been adressed as requirement of SysML V2. Imho this concept is not in accordance of still in many apsects object oriented (OO) nature of SysML v2, especially the block-instance (specification) paradigm. It is not clear to me what is the actual concept behind it and why it is needed in the first place or what benefits should it provide. It is confusing to use the word property when actual a property value is meant, I guess. So, in OO, there is juste a class (block) and and "materialization"of that class, i.e. an object istance.
REC-RPL: If RPL is “usage” and “usage” can be both an instance (blackbox ?) and a class (inheritance, constrained reuse?) , throwing these semantically distinct relationships into one bag called REC-RPL is just obfuscating a clear distinction between is-a and has-a relationships and their respective variants, is-instance-of and is-allocated-in etc… These are well which are well-established terms. E.g. inheritance of interfaces only, inheritance of interfaces and functions (‘implementation’), various forms of constrained extensibility inheritance etc, composition. Another alternative is a prototype-based inheritance.
. Imho it would be much more clearer to use just these clearly defined and well-established concepts to meta-modelrelationships between:
- definitions (aka classes, aka blocks, aka types): is-a and has-a
- between definitions and instances (aka objects): instance-of
- between instances of different architectural lavels - Arcadia layers (e.g. logical-physical).: is-allocated-in