| Some questions on Papyrus Software Designer [message #1816317] |
Sat, 26 October 2019 18:12  |
|
Today I took some time to evaluate the Papyrus Software Designer (Java),. An overall positve experience, but I got stuck with some issues.
1. for a read-only, private property of a class code got generated that allows to update that property. I expect an private final <type> <id>
Is there some way to achieve that?
2. Associations with visibility private result in code that presents them public.
Is there some way to make these private?
3. I would like to be able to specify an one-to-many association to be represented as a set rather than as an array.
Is there some way to achieve that?
4. Association classes seem to be ignored at all.
Is there some way to generate code reflecting association classes?
Best regards
Carsten
|
|
|
| Re: Some questions on Papyrus Software Designer [message #1816345 is a reply to message #1816317] |
Mon, 28 October 2019 08:06  |
|
Hi Carsten,
1. read-only attributes are currently not treated specifically. If you want a final qualifier, use the "Final" stereotype. It is arguable that "read-only" could be mapped to final, so this could be an enhancement
2. This is apparently a bug, please post a bugzilla report
3. This is recently supported via the stereotype "ListHint", but only for C++. See bug 546545 and the discussions in this thread . The stereotype is from the common code generation profile, the effort to support Java as well is low, but we haven't had the time to do it.
4. Association classes are not supported right now.
Best
Ansgar
|
|
|
|
| Re: Some questions on Papyrus Software Designer [message #1816350 is a reply to message #1816317] |
Mon, 28 October 2019 09:22 |
|
Many thanks to Yoann and Ansgar for the help.
A remark on association classes. An association class is either an additional information or a constraint.
In the first case I would expect to get an operation like
get<associatinId>Data() : <associationClass> []
on the association source lto get the additional information.
In the second case in my opinion the operation the be like
get<associatinId>Target(in <associationClass> constraint) : <AssociationTargetClass> []
on the association source to search all targets fulfilling the constraint.
Wether the association class is to be interpreted can be specified using stereotypes.
In both cases a set of classes is returned, because in the first case several associations between a given source and a given target may exist and in the second case several targets may fulfill the constraints.
The second case also has another difficulty. Given the example a person with a given login is operator for all sites of a company, but chief operator for two sites. Assuming that the role chief operator includes the role operator for the two sites only the association attributed with chief operator will exist. When requesting all sites the person has the operator role the to sites will not be selected, if referenceRole. equals(role) simply triggers on object equality. Given that a compare is sometimes required.
/Carsten
Edit: corrections & clarifications
[Updated on: Mon, 28 October 2019 10:39] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02111 seconds
Search
Help
Register
Login
Home
