Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] [PROVENANCE INTERNET] Feedbacks about architecture framework

Dear all,

I have the same issues as Camille regarding loading time and adding required resource. I suspect, resources are loaded multiple times, otherwise it would not take that long.

Compared to the neon version I like that error-prone IDs have now be replaced by "real" model references. But I still have quite a large list of shortcomings:

* Validation: the validation of an element-type file almost always reports no errors, even if there are for instance undefined references, duplicate IDs, etc.

* Better editors:

- References can be selected via a pull down menu. This doesn't scale. There is no filter to search for a given element (you can type blindly but you have to write the whole prefix, starting with Metamodel or Specialization Type ...). Thus, it would be good to see a filter line which allows to prefix with "*" and type the name of the element-type to find.

- No completion/browsing/validation, e.g.if we enter an advice class name or a stereotype name in a matcher-condition/application-advice. It's simply a string and up to the user to enter/check.

- As we don't see the full path of an element-type reference, we cannot distinguish between two elements having the same name. This is a minor issue, as you can avoid having identical names in most cases, but I once made the mistake to use the same name for the (non-child) DI element and the associated semantic element type.

* Redundancy:

- Icon paths within element type definitions are taken into account for the new-child menu, but they have do be redone in the Palette definition (and at other places)

- Duplication of matcher conditions and apply-stereotype advice. While I understand that these are two different things, you'll need both with identical data in most cases. A pragmatical solution would be have a boolean flag in the stereotype-matcher condition (defaulting to true) indicating "apply-during-create"

- Old problem of having separate element-type-DI definitions for child-node and top-node. It would be great, if it is possible to distinguish them only if needed, i.e. if they should actually be presented differently. Well, this is rather an inheritance from GMF instead of an issue in the architecture framework

* Runtime robustness:

A single bad element-type definition can break all diagrams and produce a runtime NPE. It's hard to find which element type definition caused the problem

* Generation from profile definition

An initial set of element types definitions can be generated from a profile. While this is very useful, a re-generation e.g. after a profile evolution would overwrite existing advice configurations. I.e. it would be grate to have an incremental generator that preserves these definitions.

Best regards


On 12/10/2017 13:43, TESSIER Patrick wrote:

Hi all committers and advanced users of papyrus,


For the oxygen version, the architecture framework has been developed and used.

I would like to know your feedbacks about this framework, to include , if needed,  improvements in the road map of photon.


You can write that it is nice, why, we appreciate this kind of remarks.

You can also write remarks about:

-        Needs improvements about developer points of view:

o   Configuration about .architecture

o   How to define something that you have difficulties to do.

o   Maybe problems of performance that you have detected.

-        Needs improvements about user points of view:

o   Menus

o   Some behaviors that you have not understand…

Responses need to be clearly and precise in order to be managed.


Patrick Tessier

_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top