Hi, team,
The modeled diagram assistants feature (
bug 451230) has been merged to master. This feature comprises three main parts:
- a framework for modeled diagram assistants
- end-user tooling for generating diagram assistants for UML Profiles
- diagram assistant models for the base UML diagrams
The framework includes a model (well, several models, actually) of Diagram Assistants that are loaded by a single provider extension to the GMF Modeling Assistant Service.
The tooling includes wizards for generation of Element Types Configuration models and assistant models for a UML Profile, as described in the Papyrus User Guide in the on-line help (see below). These have been used so far to generate models for SysML 1.4, so happily I haven’t been the only one testing them (thanks Patrick and Önder).
As the Use Case and Class diagrams have, so far, been ported to the new Element Types Configurations framework for modeled element types, these also now have diagram assistants based on those element types. I still need to do some trimming in the class diagram assistants (the pop-up bar has too many tools) and performance tuning in general. But I would ask developers as they port the remaining UML diagrams to the new element types framework to give some thought to the diagram assistants and to generate and fine-tune those models, too (see the updates to the developer wiki referenced below). I am, of course, always available to help in this effort.
Note in particular that the Xtend templates for diagram generation have been modified to accommodate the needs of the diagram assistants provider. The Use Case and Class diagrams are re-generated from these updated templates. My own preliminary trials with the Activity diagram have been successful, but in that diagram and probably others it is necessary to add the pop-up bar edit policy to various shape compartments in the GMFGen models. See the developer wiki for details about that (I made it as easy as I could with a new menu action). I haven’t yet ventured near the Sequence diagram ...
Hyperlinks
Up to and including the Luna release of Papyrus, the pop-up bar assistant has actually been manifest at least on top-level shapes to present hyperlinks and the green “plus” tool that creates new hyperlinks. This is all now subsumed in the new PapyrusPopupBarEditPolicy. The hyperlink tools are shown after any tools contributed by assistants models.
Tools for Papyrus Developers
The Papyrus Developer Tools plug-ins add some tools to help kick-start the integration of assistant models into the first-party diagrams provided by Papyrus:
- context menu actions on GMFGen models to generate
- element types models (contributed by Florian but modified to support assistants)
- assistant models based on the same element types that are generated by the other action
- context menu action on compartment elements in the GMFGen model to add the pop-up bar edit policy
- context menu action on *.elementtypesconfigurations models to generate assistants for the modeled element types (this one’s not really so useful)
Plug-in Details
A bunch of new plug-ins are added to the git repository and the build for this feature:
- {oep}.infra.filters: a model of filters used in the specification of diagram assistants, but which are sufficiently general that they could be used by other tooling models (palettes, new-child menu, whatever)
- {oep}.uml.filters: UML-specific filters, such as to match elements in the scope of a particular profile application
- {oep}.infra.gmfdiag.assistant: the assistant model and the GMF assistant service provider that injects modeled assistants into the diagrams at run-time
- {oep}.infra.gmfdiag.assistant.ui: menu actions for hot-deploying and undeploying assistant models in the running Papyrus workbench
- {oep}.uml.profile.elementtypesconfigurations.generator: an Xtend transformation that generates an Element Types Configurations model for a UML Profile specializing a selected base element types set (either the UML element types generally or diagram-specific element type specializations)
- {oep}.uml.profile.elementtypesconfigurations.generator.ui: the wizard that runs the element types generator transformation
- {oep}.uml.profile.assistants.generator: the Xtend transformation that generates assistants model, based on the element-types generator
- {oep}.uml.profile.assistants.generator.ui: the wizard that runs the assistants and element-types generator transformations
Additionally, the model generator wizards make use of the TableCombo widget provided by the Eclipse Nebula project. So, the build and the PDE Target as configured by the Oomph setup model now include the org.eclipse.nebula.widgets.tablecombo plug-in. It is packaged in the org.eclipse.papyrus.infra.widgets.feature feature, so any other Papyrus UI plug-in is free to use it.
Documentation
End-user documentation is included in the Papyrus User Guide in a new Diagram Assistants for UML Profiles topic under Using UML Profiles.
Developer documentation is provided in the form of source models in the relevant projects in the Git repository and a brief blurb in the
Papyrus diagram generation Wiki page discussing the generation of assistant models for unprofiled UML in a new diagram.
JUnit Test Framework
Development of this feature was done on a branch for which I wanted to run automated tests on Hudson. To that end, I refactored the Papyrus test suite framework to push the following types from the org.eclipse.papyrus.tests plug-in down into org.eclipse.papyrus.junit.framework:
- AllTestsRunner class that implements the suite-of-suites test suite
- ITestSuiteClass interface and its implementations that integrate the “AllTest” suites from plug-ins and fragments into the suite-of-suites
This refactoring allowed me to break out a sub-suite of all the tests pertinent to the Diagram Assistants feature into a unit that could be run by the Tycho build: the top-pom-tests.xml is now parameterized with the test suite plug-in and class to run, the defaults being org.eclipse.papyrus.tests and its AllTests, respectively.
My hope is that we will use this new structure to partition the monolithic AllTest suite into more maintainable sub-suites by component.
Thanks for your attention and, as always, let me know if you have comments or concerns.
Christian
