Some thoughts on Arcadia/Capella terminology and "usage-based modeling"

[ms34449.yahoo.com_ol]

Hi,
let me please formulate some comments and proposals on the Capela/Arcadia concepts as presented in the webinars:
https://www.youtube.com/watch?v=74eKWrSs8hI
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.
https://www.youtube.com/watch?time_continue=2685&v=qFfj8 K3uj3Y
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”.
https://www.youtube.com/watch?v=I28EhAXe-i8&index=6& list=PLfrEYVpSGVLxEFRODSWUTP8N5i3NTG4o-
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
  br
  Marek

[SBonnet]

Hi,
Thank you for your comments. Do not forget the primary audience for Arcadia/Capella are not necessarily engineers with strong SW background. The type/instance/composition/aggregation/etc. discussions is something we have had many times over the last 10 years.
About your first comment: I would have no problem using “condition” instead of “situation”. We might consider a change of terminology when we integrate what is currently an add-on into the core of Capella. This is something we will discuss with users.
About the second comment. I agree on the fact that I used terminology shortcuts/simplifications and I probably lacked rigor. I disagree on the class vs instance being “essential”. Many systems engineers start modeling without even knowing what is a class. For what it’s worth, I have a SW background, I’ve done a lot of UML and OO. My years oat the contact of systems engineers made me revisit my fundamentals.
About the third comment: Among others, see the slides of Ed Seidewitz, co-lead of the team working on an response to the RFP.
https:// www.slideshare.net/seidewitz/sysml-v2-and-mbse-the-next-ten- years. In particular from slide 16.
In Capella, the type-instance topic has been partially addressed by the tool and the REC-RPL mechanisms. But we lack a proper underlying conceptual foundation. Because we have tried for several years, we know this foundation is not SysML v1. But we are hopeful we will be able to adopt the SysML v2 concepts for Structure if they match our needs.

[ms34449.yahoo.com_ol]

Hi,
ad 1st comment: appreciate!
ad 2nd comment: sure, I am aware of that. But: it is more than a matter of naming (even if not completely correct in other contexts, e.g. “class” could be replaced by much more familiar “type” etc.) - the fact that these concepts come from Computer Science does not make them less sound or useful. That was my only point of criticism: it is better to reuse the already established concepts and extend them only if unavoidable. This also helps to promote acceptance and wide adoption.
ad 3rd comment: will have a look into it and will get back to you.
br
Marek

[ms34449.yahoo.com_ol]

Hi again,
Ad “usage-based modeling”: First let me pls explain, that the possibilities and concepts of entity reuse are one of the fundamental questions in our project, as we want to use a combination of Capella and Enterprise Architect and, of course, have already identified some clear opportunities in our evolving architecture.
After studying
https://www.slideshare.net/seidewitz/sysml-v2-and-mbse-the-n ext-ten-years I must admit I still don´t get what exactly is meant by “usage”, what falls into the category of “usage” (the need to make SysML more “precise” is very understandable, but it contrasts this somehow vague term of “usage”). Different values of properties? No problem at all, this is one of the actual reasons we distinguish between instances (aka objects) and classes - different instances have different values of their (instance) attributes. Internal structure is the same for all instances of a type? Does not need to be if the classical subtyping and polymorpism concepts are used (LSP principle) - together with encapsulation they make it possible to use a different subtype (or variant if you will) of the same type without violating the external interface of the type. All in all, imho to provide crucial insight into this an exampel could help showing what would be a requirement/use case, that could not be solved with the known concepts I have mentioned.
br
Marek

[ms34449.yahoo.com_ol]

Finally, just for clarification, here is what I think is a correspondence betwen the dDifferent kinds of conformance between a RPL and its REC" and the known concepts:
“Blackbox: No modification is allowed on the Replica.”
-> cloning (deep copy) of objects (instances)
“Constrained Reuse: Internal elements can be added inside a RPL, but constraints and Interfaces (Function and Component Ports for example) defined in REC cannot be modified.”
-> some suggestions: inextensible inheritance, final inheritance, mutable cloning
“Inheritance: Any element can be added in the RPL, including new Interfaces.”
-> Yes, inheritance