Community
Participate
Working Groups
Currently, profiles and stereotypes are necessarily serialized in the main *.uml file. Papyrus shall enable to manage profile/stereotype applications in separated, optional files. Users must be able to open the main *.uml model without loading the profile model(s).
*** Bug 438966 has been marked as a duplicate of this bug. ***
I have pushed a new branch with a prototype of profile application externalization for Papyrus: committers/cdamus/external_stereotypes This updates the three existing plug-ins in the sandbox/ExternalResourceStereotypeApplication directory in git and adds another. These four plug-ins add to Papyrus the ability to manage optionally loadable profile and stereotype applications as demonstrated in a brief (less than 11 minutes) YouTube video: http://youtu.be/vXX80WnNNuY This demonstrates several new UI components: - context-menu action on resources in the Project Explorer (or anywhere) to load a resource containing externalized profile (and stereotype) applications into the Papyrus editor currently open on the model to which it pertains, opening such editor first if necessary - context-menu actions in the Model Explorer, on a selected Package, to externalize (factor out into a separate resource) or internalize (reintegrate into the main UML resource) one or more profile applications of the package. Corresponding action buttons for selected profiles in the "Profiles" tab of the property sheet for packages - context-menu action in the Model Explorer, on a selected profile-application externalization model, to unload the profile and stereotype applications that it provides. This is the inverse operation to the first action, above The structure of the resource that stores externalized profile applications is like so: - a package serving as the root UML container for externalized profile applications - it has a special ProfileExternalization profile applied that provides an XML namespace to make these resources easily distinguishable from normal UML content - sub-packages that serve as proxies for packages in the user model. These contain the ProfileApplication elements that we want to load and interpret as being "applied to" the corresponding package in the user model - a contained Dependency relationship links the user-model package to this external package. The Dependency is stereotyped as <<applyProfiles>> (from the aforementioned ProfileExternalization profile). It has the user-model package as its client (leveraging the fact that in UML 2.5 the NamedElement::clientDependency property is derived and transient) and the external package as its supplier - as additional roots of the resource, all of the instances of stereotypes defined by the profile applications maintained in this resource A new IModel in the Papyrus ModelSet installs custom ProfileApplicationHelper and StereotypeApplicationHelper implementations on the model-set to help the UML API to find externalized profile and stereotype applications. ** NOTE ** that this requires the UML2 patch on bug 444588, which I hope to be able to process for Mars M3. The profile-application helper finds loaded externalized profile applications for a package by following any client dependencies of the package that are stereotyped as <<applyProfiles>> and picking up the ProfileApplications owned by the supplier packages. Inherited profile applications are not included, which is important (that is why the ProfileExternalization profile is applied to a container package). The stereotype-application helper ensures that stereotype applications are stored in the same resource as the profile-application that defines them, whether that be in the main UML content or in an external profile-application resource. Things to consider include: - the prototype loads profile-application resources explicitly via context-menu action in the Project Explorer only. It would be nice to make this more discoverable/friendly. For example, - prompt when opening a model to ask which profile applications to load, from a list? - context-menu action in the Model Explorer to load profile applications, again letting the user pick from a list? - in any case, need a decoration in the Model Explorer for packages that have unloaded profile applications available to load? - the Properties View UI for unapplying profiles needs to handle externalized profiles cleaning up the partner package in the profile-application resource) - do we need an action that combines the application and externalization of a profile in a single operation? - the prototype shows profile-application packages in the Model Explorer. This does have the advantage of allowing the user to, for example, add diagrams and comments and stuff to these packages, but I find it less than ideal. But where else can the unload action be presented? Not in the Profiles table in the package properties because any number of packages can have profile applications in the same resource and they are loaded/unloaded per resource - in the Luna release, diagrams automatically delete stereotype compartment shapes for stereotypes that are not available when rendering a diagram. This needs to be rethought for Mars because now we have use cases where stereotypes may intentionally be unavailable and we don't want to lose information about how they should be presented in the diagram whenever we do have them loaded Interactions that are as yet wholly untested: - required extensions. I don't anticipate a problem with these because explicit stereotype application objects are created for them and are collocated with the profile application, so we shouldn't run into cases where they are created by accident because the profile application is loaded but the stereotype applications are not - multiple applications of the same profile. This externalization mechanism makes it possible to apply the same profile any number of times to the same package (though at most once within the actual user model). The tool needs to ensure sensible behaviour when a user attempts to load an application of a profile for which some other application is already loaded - profile migration. I don't expect much difficulty here as the UML API involved delegates to helpers as required - stereotype repair. There is more custom code involved in this than in profile migration - controlled units. I don't expect any difficulty here as the location of externalized profile applications is based entirely on the URIs of UML resources, irrespective of any sub-unit or cross-reference dependencies between them - import/export. Other UML-based applications don't know about externalized profile applications, so we probably want some kind of export function that reintegrates selected profile applications on the fly
Commit d8d6c27047f86cb5031ccb95bb838c69995b6cbe adds to the branch a pair of user-friendly context menu actions in the Model Explorer. Now, on the root package (or any package), you can easily: * pick from any profile application resources that are not yet loaded, to load them. A dialog presents profile application resources pertaining to all of the controlled units currently loaded in the Model Explorer (for the model containing the selected package) * pick from any profile application resources that are loaded, to unload them A very brief video (less than three minutes) demonstrates: http://youtu.be/GNsPFr3gyyE
A further refinement of this prototype: commit 98c1f7d3b297a01f11560938d52cff5cd17a0840 on the branch adds a filter (enabled by default) that hides loaded profile application models from view in the Model Explorer. http://youtu.be/TUAnLrm5npM (less than two minutes)
(In reply to Christian W. Damus from comment #2) > I have pushed a new branch with a prototype of profile application > externalization for Papyrus: ...phew, what a long comment. :) My only comments at this point is separate profile apps as separate models in separate projects, and multiple profile apps (mutually exclusive) for the the same source model (already covered), and swift switching between them. Thank you. Great work. :)
A new update: commit 1fc1e8851c37adb9a36bf04474231662039117c8 on the branch implements support for storing profile applications in any UML resource anywhere in the workspace, even in different projects than the user model resources. See a demonstration (less than five minutes) here: http://youtu.be/O9ltnFb4t-E So, profile-application models are no longer component resources of the Papyrus model (composite resource thing). It's an independent UML model resource. To maintain the ease of use of the "Load Profile Applications..." context menu action in the Model Explorer that presents a dialog showing the resources containing profile applications applied to the model that are not yet loaded, a new index is employed that provides efficient access to the cross-references between profile-application resources and user-model resources. This index is built on startup of the workbench and maintained automatically as UML resources in the workspace change. For maximal efficiency, it only parses resources of profile-application-resource content type and only parses as much of each resource (via raw SAX API) as needed to find references to the user models that apply the profile applications.
Nice to see such fast progress. I just spoke with Toni yesterday and suggested him to bring up this about being able to store the externalized profile application in a separate project. When looking at the video it seem like the profile application model has an ordinary dependency, with the stereotype <<ApplyProfiles>>. May I suggest making that into an element import, or package import, instead to make it possible to open the profile application model (if you make it into a Papyrus model as you mention in the video) and then browse the source model within the context of the profile application model. I know another modeling tool that is doing it like that. Then you can choose to either browse the source model directly, and load the externalized profile application model as demonstrated in the videos. Or you can start by open the externalized profile application model and automatically open up, and start browsing the source model via the element (or package) import within the context of the profile application model. With a plain dependency, you don't have the in-place browsing of the related element.
Hi, Peter, Did you notice the direction of the dependency relationship? It's a dependency from the package in the user that model that wants to optionally apply a profile to the package in the profile-application model that owns the profile application. I think this expresses the semantics better than an element import in the other direction. An import of the user-model package just brings that package into the namespace of the profile-application model, which doesn't suggest any dependency of the user-model package on the profile application (a profile application is semantically still a fairly significant dependency of a package on a profile). Ideally, the ProfileApplication metaclass would decouple the applyingPackage property from the owner property. In UML 2.5, applyingPackage subsets owner. If applyingPackage could be set independently of the owner (as is the case with Dependency::client), then we would be able to store profile applications separately from their applying packages "natively" in UML. But, that kind of change needs to come from OMG into Eclipse UML2. In any case, it's up to the tool to decide how to present UML models for editing. Whether the structure is an ElementImport as you suggest or a Dependency as it is now, Papyrus can choose to load and present these models however is best for the editing experience. Under no circumstances should the semantics of the model be tailored for the convenience of the tooling :-) (It may be worth noting also that nothing prevents multiple user models from externalizing profile applications in the same profile-application model, by design. So, there's not really an unique user model to open for editing in that case.)
Commit c0573c33eab04c307bbead0a6ce016d1aa7503e9 on the branch ensures that when Papyrus opens a profile-application model in the Papyrus Editor, all of the models to which it applies profile applications are loaded. These are what are presented in the Model Explorer for editing (by default; the filter can be disabled as usual that hides loaded profile-application models). See a brief demonstration (two and a quarter minutes): http://youtu.be/PcsBt2fsn2A
Nice work Christian! The latest video shows exactly what I was after... :) My proposal about element/package import was just me trying to be pragmatic, proposing something that I thought would be the "cheapest" solution. If I do consider the semantics instead, I completely agree with you that a dependency is much better. I assumed it was better to propose something that I thought would work "out of the box", but considering how fast you made the real solution, I will never propose any pragmatic solutions in the future... :) (In reply to Christian W. Damus from comment #8) > Under no circumstances should > the semantics of the model be tailored for the convenience of the tooling > :-) Could not agree more! As comment to this I have always wondered why Import > Import Package From User Model in Papyrus *only* are able to create a package import. Considering the semantics between package import vs. element import, it often makes more sense to do element import (of a package) due to the difference in name space semantics. So I guess people create models with package imports due to "convience of the tooling", instead of creating models which semantically probably would make more sense with element import. Sorry for the off-topic comment, but I could not resist... :)
(In reply to comment #10) > Nice work Christian! The latest video shows exactly what I was after... :) Thanks for the feed-back. > My proposal about element/package import was just me trying to be pragmatic, > proposing something that I thought would be the "cheapest" solution. If I do > consider the semantics instead, I completely agree with you that a dependency is > much better. Glad to hear it! :-) > I assumed it was better to propose something that I thought would work "out of > the box", but considering how fast you made the real solution, I will never > propose any pragmatic solutions in the future... :) Don't say that! We're always open to suggestions. It's just that, as it happens, in this case my solution worked out of the box (well, almost ... it was a one-liner to make the user models show up in the Model Explorer on opening the editor on the profile-application model). > (In reply to Christian W. Damus from comment #8) > > Under no circumstances should > > the semantics of the model be tailored for the convenience of the tooling > > :-) > > Could not agree more! As comment to this I have always wondered why Import > > Import Package From User Model in Papyrus *only* are able to create a package > import. Considering the semantics between package import vs. element import, it > often makes more sense to do element import (of a package) due to the difference > in name space semantics. So I guess people create models with package imports > due to "convience of the tooling", instead of creating models which semantically > probably would make more sense with element import. Sorry for the off-topic > comment, but I could not resist... :) Actually, that's a good point. I would be inclined to suggest raising an enhancement request or bug report for that in bugzilla, except that there is actually a supported way to create the element import. It's just not as convenient: 1. Import the package using the "Load" action, not creating a PackageImport. 2. Drag and drop the importing package and the package loaded in step 1 together onto a class diagram. 3. Draw an ElementImport relationship between the two using the palette tool. So, three steps where there might have been one (and probably a fourth to delete the diagram content from steps 2 and 3 that you don't want). Maybe that is worth a bugzilla ... You could contribute a gerrit patch! :-)
Commit 0295802bd76a789529ed149f08bb66ebfbefeed7 on the branch adds a couple of UI affordances to help users to discover that there are externalized profile applications available for their models: - a label decorator (just a placeholder icon for now) for models that have available unloaded profile applications - a preference (enabled by default) to prompt to load available profile applications on opening a model, if it has unloaded profile applications available See a brief (three minutes) demonstration: http://youtu.be/eLdW9DiC4jg
Great work Christian! Just a question (maybe I missed it) on variants of profile applications, e.g. profile applications for the same stereotype but with different property values?
(In reply to Patrik Nandorf from comment #13) > Great work Christian! Thanks, Patrik! > Just a question (maybe I missed it) on variants of profile applications, > e.g. profile applications for the same stereotype but with different > property values? I didn't explicitly demonstrate it because there is some work that will be required to ensure sanity of the model, but currently this prototype fully supports multiple (externalized) applications of the same profile on the same package with different data in the stereotype applications. The tooling issue that needs to be addressed is ensuring that the user can only load one application of any given profile on a package at one time, because an element may only have at most one application of any stereotype. I'm thinking of adding information about the actual profiles applied to my index of profile applications in the workspace. Stay tuned ...
I have pushed a number of further changes to the branch, continuing the evolution of the profile application externalization capability. See a demonstration here: http://youtu.be/6o8Ei5doC-Y The most noteworthy improvements are: * the Externalize Profile Applications wizard now lets you set a name/identifier for the model that is created to store the profile application(s). This name is included in the workspace-wide index of profile application models so that it may be presented in various parts of the UI to identify the profile application model in a way that is meaningful to the user, including: * the Load/Unload Profile Applications dialogs show the model identifier (qualified by the resource path) instead of the file name * the labels of Packages in the Model Explorer are decorated with a list of the model identifiers from which externalized profile applications have been loaded) * the labels of applied Profiles in the Properties view for Packages are decorated with the model identifiers from which they were load (if they are externalized profile applications) The wizard lets profile applications be stored in an existing profile-application model. In that case, it shows the current name/identifier of that model and it is not editable. * sane handling of multiple applications of the same profile on the same package, to support alternative data-fills for the same stereotypes. Mostly this involves restricting user actions in the menus and wizards: * the system does not offer a profile-application model as available to load if it applies a profile to a package that "natively" has that profile applied (the profile application is owned by the applying package) * the Externalize Profile Applications wizard does not permit storing a profile application in an existing UML model that either: * is not a profile-application model (but just some ordinary user model), or * already has an application of that profile to the same package. Otherwise, this model could never be loaded because it would have a repeated profile application for that package * the Load Profile Applications action does not allow selection of multiple profile-application models that would apply the same profile to the same package * the Load Profile Applications action allows the loading of a profile-application model that has applies a profile already applied to the same package by another loaded profile-application model. In this case, it reports the conflict with the loaded profile-application model and requires the user to unload it one currently loaded. This implements a "switching" between applications of the same profile on a package So, in short, this update offers a simple way for users to keep track of and recognize the meaning of externalized profile applications and also to manage repeated (alternative) profile applications in a safe manner.
Hi Christian. Great improvements in short time. :) See emails for additional comments. Soon we need to test this on our test-case model. Perhaps we (you) can hack the test-case XML to "apply" the new stereotypes? When can I test this myself? Thanx again/Toni
(In reply to Christian W. Damus from comment #6) ... > This index is built on startup of the workbench and maintained > automatically as UML resources in the workspace change. Here is another use case: 1) Create a new workspace. 2) Import exported projects or projects from a Git repo. When does the index get populated?
(In reply to comment #16) > > Soon we need to test this on our test-case model. > Perhaps we (you) can hack the test-case XML to "apply" the new stereotypes? What test-case XML is that? > When can I test this myself? I want to look into creating a build job for my branch, today or tomorrow. Once that's in place, you would be able to update an installation from that build's output repository. (In reply to comment #17) > > Here is another use case: > > 1) Create a new workspace. > 2) Import exported projects or projects from a Git repo. > > When does the index get populated? The import creates a whole bunch of new files in the workspace, which the indexer detects and processes quietly in the background. It doesn't take long, but if the index isn't ready before it is needed, the code accessing it blocks until it's ready. That would show the usual "user operation is waiting on background jobs" dialog.
I have pushed new commits to the branch that * fix further diagram refresh issues. The PapyrusStereotypeListener didn't account for the fact that when a resource containing stereotype applications is loaded, those stereotype applications don't emit SET notifications for their base_Xyz reference but rather RESOLVE, when eventually their base_Xyz reference proxies are resolved * a bunch of refactoring of APIs and UI to use "Decorator Model" terminology instead of the very cumbersome "Profile Application Model" because that's what these models are: optional decorators on the user models * releng bits to integrate the new Decorator Models feature into the build
The first installable build of this feature is now available. Point your p2 at https://hudson.eclipse.org/papyrus/job/Papyrus-DecoratorModels/lastSuccessfulBuild/artifact/repository/ In order to run this you **must** add the following options to your eclipse.ini following the -vmargs line: -Dorg.eclipse.uml2.uml.util.UMLUtil$ProfileApplicationHelper.INSTANCE=org.eclipse.papyrus.uml.decoratormodel:org.eclipse.papyrus.uml.decoratormodel.helper.PapyrusProfileApplicationHelper -Dorg.eclipse.uml2.uml.util.UMLUtil$StereotypeApplicationHelper.INSTANCE=org.eclipse.papyrus.uml.decoratormodel:org.eclipse.papyrus.uml.decoratormodel.helper.PapyrusStereotypeApplicationHelper (each line beginning with -D must be a single contiguous line in eclipse.ini without spaces, regardless of how it appears to be wrapped in this bugzilla comment) These arguments are necessary to work around the fact that the UML API enhancements on which this feature depends are not yet available from the Eclipse UML2 project. Without them, Decorator Models will not work at all.
New changes pushed to the branch (and available in the next build) are demonstrated briefly, here: http://youtu.be/5VjkMfjwuuo (about two and a half minutes) This is a Properties View tab for packages that have decorator models that apply profiles to them, making it easier than ever to access those decorator models to load and unload them. All the same constraints apply as seen previously, vis-a-vis conflicts between multiple decorator models that apply the same profiles to the same packages and conflicts with profiles natively applied to a package.
Great usability improvements. :) Can the name of the properties tab be customized? ...perhaps profile sensitive?
(In reply to Christian W. Damus from comment #18) > (In reply to comment #16) > > > > Soon we need to test this on our test-case model. > > Perhaps we (you) can hack the test-case XML to "apply" the new stereotypes? > > What test-case XML is that? The obfuscated one I've used, but I think it's better to re-create the whole test case model in Papyrus by externalizing the profile application.
(In reply to comment #22) > Great usability improvements. :) > > Can the name of the properties tab be customized? The Papyrus XWT-based properties view framework has no support for dynamic tab labels, unless perhaps there's a way to plug in dynamically-generated (at run-time) customization models with computed tab labels. > ...perhaps profile sensitive? Which profile? There can be many different profiles applied to a package. My original idea had been just to add a dynamically available section to the existing Profiles tab, but then it wouldn't be apparent from a glance at the Properties view that a package has decorator models available or loaded, because the default active tab is UML, so the contents of the Profile tab would not be visible.
Commit db275c54e9db00660f4e7627001af3ff0c0addff adds a new Duplicate action in the Decorators tab of the property sheet for packages. This invokes a new wizard that makes it quick and easy to duplicate a decorator model, to start from an existing profile application and edit the stereotypes in an alternative decorator model. See a brief demonstration (seven minutes): http://youtu.be/hnKCUc1UsGQ
Commit dc44ce535bee901409bf02ae08e433ff3aa01724 on the branch updates the UI terminology from "Decorator Model" to simply "Profile Application", with some exceptions: * sometimes explanatory text references "profile application models" or "profile application resources" where necessary to disambuiguate the resource from the ProfileApplication elements that it stores * the property tab is renamed as "Applications" because otherwise the label would simply be too long
Commit 5b0ee2e adds support for "control mode" with externalized profile applications. When a package is controlled that either has or inherits (from ancestor packages) externalized profile applications, these profile applications are refactored to * update references to elements in the model (especially from stereotypes to their base elements!) according to the new controlled resource URI * add an externalized profile application for the package, itself, for every externalized profile that it had inherited from an ancestor package The logical inverse refactorings are performed for a resource that is uncontrolled: * update references to elements in the new model according to the elimination of the controlled resource * remove externalized profile applications for the package that are redundant with externalized profile applications inherited from an ancestor package (only where the same Ecore definition is applied, of course!) These refactorings are all implemented for both loaded and unloaded profile applications (the latter being found via the index, as usual). These refactorings fully support undo/redo. In the case that any currently unloaded profile applications need to be updated, the user is first alerted to the fact that the model will have to be saved to ensure that the cross-references from unloaded profile applications to elements in the model are consistent. This is necessary because the user might otherwise elect not to save the editor, but the unloaded profile applications are already changed on disk (we cannot load them into the editor to perform the refactoring because the user did not ask to load them and they may conflict with each other or with profile applications that are currently loaded). In the case that the only profile applications affected by the (un)control refactoring are already loaded, the editor does not have to be saved and the user is not prompted. The affected profile applications will either be saved when the editor is saved or nothing will be saved if the editor is eventually just closed. (note that the unloading of a profile application already requires the user to save the editor first if it that profile application has any unsaved changes) The core UML control participant is updated to ensure that it only copies profile applications, and only moves stereotype applications, into the new controlled resource when they were previously owned by some resource in the model (not by an externalized profile-application resource). JUnit regression tests will follow in another commit.
Commit fcf5f6141e21eb031c88f24a11a7690d839fc14e on the branch adds support for migration of profile applications when loading them, using the same dialog as appears when opening a model that has profile applications needing migration.
I pushed a large Gerrit patch set for review to integrate this feature into master for Mars M3: https://git.eclipse.org/r/35898 As yet, I have not tested (nor added support for) stereotype repair on externalized profile applications. All other major use cases, however, including profile migration (normal versioning workflow) and controlled resources are covered. Also, Help documentation is not yet included, but that can come closer to the M3 deadline without risk.
The Gerrit patch now includes support for stereotype repair when loading a profile application.
The Gerrit patch is merged to master for Mars M3. User documentation is added to the Using Profiles section of the help with commit 893264d2e7cc35baa6a87bc8a6e60494d9d8b9fe.
