Comments inline below.
/Charles
I also like the classification of kinds of modelling. I have made some relevant comments related to this in Bug 492737. I do have a couple more comments inline below.
<cr> Are you sure that is the right bug number (“Illegal connector between external port and port in a part”)?
</cr> Hi,
Some more answers/comments inline.
/Peter Cigéhn
I would imagine that if we are to support these categories, much more than setups would be needed. Each of these entails certain requirements on tooling, codegen and runtime.
Yes, I expect that it would. I wonder how much the viewpoint capability would help in this case (I need to read up on that as some point). But then, each category has their own, slightly different users, so they could be variants - unless Peter sees an interoperation need other than through model exchanges or transformations.
For example, as I suggested in Bug 492737, an approach to modelling based on "correct by construction" might run contrary to descriptive (category 3) modelling, where you want more of a free-hand. So if these categories are to be supported, then the tool should be aware of which mode is being used, and impose or lift restrictions accordingly. Similarly for code generation. Should codegen be supported in category 3, for example generating code "skeletons”?
<cr> You should read the presentation that Peter included. It will explain better the relationships between the three categories of models. Category 3 is not for generating, it is for exploring. It is a “map” of the system. It is a higher level view of a category 2 model. That model should be generated from the category 2 model.
</cr>
When you talk about synchronization between these categories, do you envision the possibility of moving back and forth between them? That may be much more complicated than supporting only one direction (category 3 to category 2).
<cr>I believe the generation/synchronization would be one way, from the category 2 model to the category 3 model.
</cr>
Thanks. I'll take a look.
I suppose that if you start with only one trace you capture only one very specific scenario. But you could infer sequence diagrams from sets of traces, rather than individual traces. It turns out this problem has been studied and there are some relevant publications out there, e.g. http://www.ligum.umontreal.ca/Grati-2010-ESDETIV/Grati-2010-ESDETIV.pdf/ I think it is very interesting, although the general automatic approach from traces to sequence diagrams could be seen as a machine learning approach, since you are trying to generalize from specific cases. Perhaps a mixed approach could be useful, where you start with a set of traces, automatically infer sequence diagrams and then manually adapt the diagrams to be more general or better capture the scenarios of interest.
Right. It was not exactly a misconception, but rather an incomplete description from my part. I understand that UML-RT "constrains" while providing new concepts, in the same way that any programming language's syntax and type system (if it has one) simultaneously constrains the set of legal programs and introduces new concepts. So my point there was that if we are going to enable category 3 modelling, then some of those syntactic restrictions need to be lifted by the tool, while still supporting language-specific concepts.
The issue then becomes a bit a matter of degree. Going back to the analogy to programming languages, one could think that a plain text editor is all you need to support "category 3 programming". But then, you can write anything in the text editor. To truly support some form of "descriptive" programming, the editor should still be language aware, but giving the user enough free hand and flexibility. Being language aware implicitly entails some restrictions. The restrictions that you put determine what other tools can do with the artifact. For example, a program may not be fully compliant with its language specification, but it may be partly compliant enabling certain kinds of processing, analysis and even code generation. The same would be true for a modelling language like UML-RT. If we are to support category 3 modelling, it should be decided where does the line lie. Or perhaps there isn't a dividing line, but a gradation from full-free form to fully compliant.
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________papyrus-rt-dev mailing listpapyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|