Hi,
Gut feeling is that we first should focus on getting some redefinition/override/injection mechanism in place during build time. This is then highly related to any support similar to the transformation configuration files in the legacy tooling, which then would be used to control such redefinition/override/injection mechanism during the build/code-generation. This is actually work that is currently ongoing in the legacy code-generator, and does not actually exist yet, even though the need/requirements for it has been expressed. So the exact mechanism to be used in the legacy tooling is still up for decision. What we have discussed so far is to either use the ordinary UML/UML-RT redefinition mechanisms (which as we know is partly limited by what is being redefinable, a limit which we already have hit in UML-RT, e.g. when it comes to redefining triggers where a "workaround" is being used). The other solution has been to use "marking models", i.e. profile and stereotype applications persisted in separate resources. Then during build you simply apple the resource with the relevant profile application/stereotypes for that specific target. Then you can let this profile control what needs to be "redefined"/"overridden", i.e. this profile is then an additional dimension compared to the RtCppProperties profile for controlling the code-generator. Since none of this has been used in practice I cannot say which of these two alternatives is the best. Personally I think that the first approach with using the ordinary redefinition mechanism feels best. If there are limitations, then it can simply be combined with the "marking model" and some additional profile that can control additional redefinition scenarios in the code-generator, if needed.
As I said, these kinds of mechanism would be useful for both the unit testing case, where you e.g. want to inject mocking versions of a capsule onto a specific capsule part. But it is also useful in the Software Product Line scenario where you from the same "base model" want to build towards different target configurations e.g. to achieve scaling by redefining/overriding replication factors of capsule parts/ports.
But in all these cases the "base model" is always "complete" in some sense, e.g. by the use of base-classes which are "empty" or provide some core behavior/structure, which then should be able to be redefined/overridden during build-time.
Regarding my usage of "model weaving" I realize that I managed to get you into a completely different track, which was not my intention at all. Sorry for using a terminology which caused this confusion. I was using the "model weaving" term in a more generic term, meaning that you weave the "base model" together with a specific "redefinition model" (of which you have one per target that you intend to build for), during build time when building for that specific target. I did *not* mean that in anything in relation to aspect-oriented programming (AOP). So that was a side-track that I did expect to popup here also. I did not realize that the concept of "model weaving" was so strongly tied to the concept of aspects and AOP.
But since we are talking about aspects and AOP, I can mention that we actually have seen the need for aspects in the contexts of sequence diagrams in our system modeling initiatives, where we wanted to extend existing sequence diagrams at some defined "join points", to ensure that system engineers could extend existing sequence diagrams without touching them. But that area is probably something completely different, and let's not go there now! :)
/Peter Cigéhn