| Re: [papyrus-rt-dev] Replication factors for capsule parts and ports |
Hi,So this case currently supported in legacy models is probably something we should try out in our import tests. I can make an evolved version of the PingPong model which defines the replication factor of ports and capsule parts using a constant. Then we can use that model as driver for this work. If this is something that shall be supported, I will update the Bugzillas to clarify that we probably also need a Browse... button next to the Replication field, in the corresponding way as in the legacy tooling, and clarifications how the replication field shall automatically be filled in with the qualified name of the selected constant.Any opinions about which version of the PingPoing model I shall evolve into using constants in this way?Regarding any of the other improvements, e.g. to also support the case where the constant is defined in an external headerfile, e.g. as #define (something that the legacy code-generator cannot support) but which has been raised as a needed feature, or the possibility to provide replication factors in target specific transformation configuration files is probably something that we should look into as well. But I guess we start-off with supporting what can be done in the legacy tooling and code-generator./Peter CigéhnOn 20 November 2015 at 18:18, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:Thanks Peter. I was aware of the plans to use "Replication", but I wasn't aware that legacy models could provide it as a string.Currently the code generator obtains the multiplicity from the port, part or any property via the org.eclipse.uml2.uml.Property.lowerBound and org.eclipse.uml2.uml.Property.upperBound and both return an int, so that limits the user by allowing only LiteralInteger and LiteralUnlimitedNatural.I do not know how the tooling populates the relevant features in the model.To support LiteralStrings, one possibility would be for us to get the ValueSpecification instead of the int (calling e.g. getUpperValue), and then either trying to resolve the symbol if the ValueSpecification is a LiteralString (which in the general case may not be possible), or (probably better) updating the intermediate meta-model to support such strings and adapting the part of the generator that emits type declarations accordingly. I think this is doable, so we could generate the corresponding array declarations with constants and then the user can create his own headers with constant definitions, or define them in any other way in which constants can be defined.If the tooling adds a browse button and lets you select any constant, I'll expect the constant to be a ValueSpecification, and we would deal with it accordingly.Would you mind opening a bugzilla with this issue, since the others are assigned to tooling?ThanksOn Fri, Nov 20, 2015 at 10:45 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:_______________________________________________Hi,When I made some comments on a Bugzilla related to how replicated capsule parts (and also ports) shall have "stacked" notation in the capsule structure diagram, seeI realized that I am not sure what is (or planned to be) supported in the code generator.As I have indicated in the two Bugzillas related to that we shall use the terminology "Replication factor" and "Replication" (instead of multiplicity)the replication shall be possible to specify both as a numeric value as well as a string.In legacy models you are allowed to specify the multiplicity in form of a string (specified with an OpaqueExpression, but I do know that it has been discussion about the use of OpaqueExpression and the import tool currently has the possibilty to make all OpaqueExpressions into LiteralStrings) where that string references, using the qualified name, of a constant defined somewhere in the model.In the legacy tooling there is even a "Browse..." button next to the multiplicity field (which as indicated above will be called replication in Papyrus-RT) where you can browse (or search) the model to locate the constant, and then the (text) field of multiplicity is automatically filled with the qualified name of the selected constant, i.e. an attribute owned by some class with a default value (and probably some settings that it is a constant).So my question is if any such pattern is supported by the code generator, and whether we shall add such a browse button to the tooling or not?Or if there are some other plans how to support replication factors based on some constant either in the model, or even possibly in external header files which potentially could be shared with other external code to ensure that certain constants in some global headerfile *both* controls replication factors inside the model, as well as in external code. Or the possibility that replication factors are specified in transformation configuration files, so that when you build for different targets you build with different replication factors in the model./Peter Cigéhn
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
--Ernesto PosseZeligsoft.com
_______________________________________________
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 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