Eclipse UML Generators/Specification/UserInterface/ConsistencyImprovement

Evolution Specification: User interface consistency improvement

Current status is DRAFT

Preamble

This is a proposal to improve the user interface consistency.

Relevant tickets:

• Bug 449080 - User interface consistency improvement

Introduction

The goal of this ticket is to make the user interface coherent for all the possible generations:

• context menus;
• generation builders;
• properties pages.

Detailed Specification

Iteration 1

Generation processing

Java and RTSJ generation are launched on UML files and C generation is launched on UML Elements (classes, packages...).

Configuration

All generations, Java, RTSJ and C, can be specialized using some properties like the generation target folder, the file headers... Currently, RTSJ and C generation use UML model properties

and Java generation defines them in the launcher.

For consistency, all generation properties will be accessible from the UML model properties (like RTSJ and C) in a "UML Generators" container.

With this properties, there is only one configuration by generation types. For example, Java generation has only one configuration per UML file.

Also, for Java generation, there is no synchronization between configuration in properties and in Acceleo launcher. But, in conception, there will be the same code that display the configuration in properties and launcher.

Launching from UML model

Currently, Java is generated with an Acceleo launcher

and RTSJ is launched with context menus

All generations can be launched in the same context menu: a menu "UML Generators". Icons on menus will be added.

The generations use the configuration defined in properties pages (see Configuration part). The Java generation Acceleo launcher will not be removed. Both of the launcher and the menu can be used to generate Java.

Launching from UML elements

C generation is directly launched in the context menu. Like Java generation, the "UML Generators" menu is added for consistency.

Reversing processing

Configuration

Properties can be defined for C reverse, they are available from C project properties. Only an "UML Generators" container is added to the page. No other updates will be done.

Launching from applying a nature

There are two menu actions to add and remove the C2UML nature from C projects. They currently are in the context menu "Configure" witch is used to convert projects in a nature. However, these actions can launch the reverse so they will be moved in "UML Generators" menu, like the others actions.

Icons will be added for menus.

Iteration 2

Generation processing

(Enhancement of Iteration 1)

To be consistent, C generation should be launched from UML files too.

Configuration

This configuration is set on UML models.

The configuration (properties) of the C generation seems not to be used. So, the related properties page will be removed.

The use of "Uml" on the label of these pages is redundant (and already specified in the "UML Generators" category). So, the labels will be composed like that:

<target/source technology name>

i.e.

Java code

For Java generation, if we want to share, from a properties page, the same meta configuration (list of properties and user interface) in order to be really consistent and to make easy the maintenance, we have to be driven and constrained by the launch configuration system. So, from a technical point of view, we have to be synchronized with this system because a launch configuration can not exist (be persisted) alone. Consequently, a combo box should be available in the properties page to select an existing launch configuration applicable on the current UML model. If there is no launch configuration, this page will ask this system to initialize a new one. The page will store only the launch configuration ID into the properties of the UML model.

Launching from UML model

From the contextual menu, the Java generation will be launched using the stored launch configuration referenced from the properties of the selected UML model.

The use of "Uml" on the label of the commands, in the contextual menu, is redundant (and already specified in the "UML Generators" category). So, the labels will be composed like that:

<generation action> <target/source technology name>

i.e.

Generate Java code

Reversing processing

(Enhancement of Iteration 1)

Configuration

This configuration is set on Eclipse projects.

For now, just the C module uses a configuration at this level to define where data have to be reversed to, in a UML model (C reverser). But, it seems that these properties are also used by the C generator to generate code from a piece of model (looking for data in a UML Package identified as containing source artifacts).

Also, note that C generation and reversing share a same stateful behavior, in particular about the input/output model which may be different from the selected one (from a generation) if the shared preference store is not updated correctly... Maybe a re-architecture work would be required and really appreciated later (in an other scope) but, for now, we make with legacy.

Anyway, as this configuration is common to the C generation and reversing, the title of the properties page will be "C Generation and Reversing".

Launching from applying a nature

Today, this nature is mainly used to initialize a reverse or generation and to activate a builder which listens to the changes in the source code or model to automatically update the related artifact(s).

But the synchronization code to model was removed (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=441328), so we have only one direction synchronization. Besides, the objective is to be able to manually launch, on demand, a full reverse processing. Nevertheless, the current work flow is strongly driven by the life cycle of this nature and to try to make coexist these 2 ways may raise the risk to get some side effects (with the model and preference store management).

So, this constraint of adding/removing a nature will be removed from the scope and a menu will be available from the project to launch on demand a C code reversing. The command will execute the same process as the add of the nature but without applying a nature (and so, without listeners). We will still saving configuration in the preference store to be "integrated" with legacy (but it will probably require to be reviewed later).

Backward Compatibility and Migration Paths

Metamodel Changes

This evolution does not change any meta-models.

API Changes

This evolution does not change any API.

User Interface Changes

• Generation actions will be contained in a "UML Generators" menu;
• Java generation will be launched from context menus actions;
• Java generation properties will be accessible from UML model properties;
• Icons will be added in menu actions.

Documentation Changes

All the user manual should integrate the user interfaces updates.

Tests and Non-regression strategy

This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.

Implementation choices and tradeoffs

Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.