Hi,
This apparently took off in quite a few directions. :)
Not sure how I am going to respond to this. Inline probably becomes a bit too messy at this point, so I try to make an "aggregated" followup. I hope that I will be able to respond to most of the comments made by Charles and Ernesto earlier in the thread (as well as on
Bug 492737).
First, I think that Charles is right. I definitively think that Ernesto's interpretation of the different categories went in a rather different direction than what I have envisioned them. As Charles say,
my presentation from MODPROD (which was authored ahead of the formulation of these 3 categories of modeling) summarizes pretty well the distinction between category 2 and category 3, i.e. the definition of "Blueprint models vs. Map models" on page 7 maps to the distinction with category 2, prescriptive, modeling respectively. category 3, descriptive, modeling.
One area that I need to clarify, is this about "freedom" when it comes to descriptive modeling. Ernesto talks about different modes in the tool and giving additional freedom when doing category 3, descriptive modeling. Sure, that is probably something that could be done, but that was definitively what I envision.
This thread started out where I tried to explain the use of UML-RT outside the context of its "sweet spot", which of course its category 2 modeling, prescriptive modeling, where the "model is the application", from which we generate all code. I tried to explain, based on 10+ years experience of using UML-RT in system modeling initiatives, that UML-RT also is useful in category 3, descriptive modeling.
But I do not see that we necessarily need to relax or give the user more freedom, just because we talk about category 3 modeling. If the user is not happy at all with being "constrained" by UML-RT in his descriptive modeling endevour, then the user should not be basing his modeling on UML-RT, but probably make his own DSML. If the user is still happy by being "constrained" by UML, then base the DSML on top of UML, i.e. the sweet spot for Papyrus. If the user is not happy being constrained by UML either, then go for some Ecore based DSML. If the user is not happy with the either, then go completely without models and describe your system in ordinary free text documents with free form figures (which is where most organizations starts when it comes to their category 3 "models").
I really do not see that we shall start reason too much about making different "modes" for Papyrus-RT to support category 3, descriptive modeling. That was really not my intention.
Sure there could of course always be certain details in the tooling where you would like to "loosen" things, and make it a bit more flexible. One such area is the support for multiple parameters, where we have a strong need for that from a system modeling, category 3 kind of modeling. But the legacy code-generator/run-time still had the constraint that it only could be single parameter protocol messages. But we could still use multiple parameters for the non-code-generating case, visualizing multiple parameters/arguments for messages in sequence diagrams.
Also to be clear this about transitioning between the different categories as Ernesto mentions, I really don't see that you ever transition from category 3, descriptive modeling, to any of the other categories, like category 2, prescriptive modeling. As indicated in the MODPROD presentation, then use of "Map models", is very often an "afterthought", raising the level of abstraction of some system already "existing" (or developed in parallell). The system can be developed using hand written code or/and more detailed implementation/design models of category2. But I really don't expect that your category 3 model will transition into anything else.
Yes, category 1 models naturally can transition into category 2 models, i.e. the classic analysis model elaborated into a design model, where the life cycle of the category 1 model makes it to costly to maintain so that you throw it away. We also have the case where category 2 models, once meant to be specifications (but maybe not necessarily as detailed to be useful for code-generation), transitions over to become category 3 models, which you go from updating "before" to updating them "after". This is also what I have explained in the MODPROD presentation, where organizations go from being "water fall" driven to work more agile using cross functional teams.
Regarding transformation between different categories of models and whether it is bi-directional or not, we are back to the MODPROD presentation. Its subtitle actually says it all: 'Transformation in the "wrong" direction'. Exactly as Ernesto comments, "I would've expected the other direction". That is actually the core point of my presentation: Normally everyone expects the transformation from a higher level abstraction model into the more refined one. That is what everyone expects. So I am not surprised by this statement. But the presentation is all bout doing in the other, "wrong", direction... :)
To reduce both complexity and cost, we have been using the "wrong" direction, i.e. going from the more refined model, utilizing abstraction patterns (which Bran has done some interesting work categorizing different abstraction patterns), to a higher level abstraction model. And to avoid complexity, especially when it comes to configuration management and base line handling, the direction is single direction. Pick one source of information and transform only in one direction.
I am not sure that I have made this more clear, or just added to the confusion. I feel that there are more things that I would have liked to comment on in the previous mails, but I feel I will just go on and on here... This is a huge area of discussion, and I see that depending on a person back-ground we reason rather differently.
Especially in these areas of "correct by construction" and how much the tooling should enforce this, vs. how much validations/constraints we shall vs. how to deal with "incomplete" models, which in my opinion is still models that the are to be considered compliant with the language specification (otherwise you have far too strict language specification that makes it impossible to even build a model). Anyway, this topic I see that Ernesto comes back to over and over again, especially in conjunction with that we still have not gotten all the tooling in place for Papyrus-RT (which should enforce a much higher degree of "correct by construction", e.g. related to Bugzilla Ernesto wrote about incorrect connectors where the tooling is not yet complete with respect to that). This I also feel seem to be area that needs further discussion, and probably also depends a lot based on how much experience one have had of the earlier generations of UML-RT based tools (ObjecTime, RoseRT, RSARTE) one has.
/Peter Cigéhn