Change management
1. Introduction
Change management is about adding extra information about users activities while modeling. They can be related to any aspect of the modeling session (current tasks, current teams, a more detail explanation etc…). Its integration in Team for Capella provides a way to:
-
Ease the way users fill them.
-
Structure and request them.
Those information are attached to a commit. They can be visualized in the Commit History View by selecting each commit. Be aware that some commits are made by modeler itself. They do not represent commits that users would have made. They are tagged with the property team-technical-commit : true.
2. Main documentation
The main documentation of the Commit History View is available in the corresponding section of the Sirius Collaborative Mode user documentation.
Note that some actions have been hidden in Team for Capella, such as Create Branch… and Checkout popup menus. You can enable the CDO Actions capability in the Preferences page to access them.
3. Filling up extra information
In Team For Capella, there are two ways to fill up the extra information attached to a commit.
-
Users can choose to enter it for each commit using the preference "Require description for commit actions". The process can be eased using "a Commit description provider".
-
Users can choose to automatically use the description computed by the framework using the preference "Automatically use the pre-filled description when none is provided". Then use the custom action "Save with Description" when they want to change or add more detail about the current activity.
The following sections explain the different facilities used to compute a commit description.
3.1. Using CDO History
This strategy uses the history of the Team for Capella Server to guess what information the user wants to enter. Before each commit, it will look for the last commit done by the current user (that is not a Technical commit). For example, let’s say the current user is user1 and the server has the following history:
Date | User | Description |
---|---|---|
31/08/2017 16:00 |
User1 |
Update Xmi Ids team-technical-commit : true |
31/08/2017 15:59 |
User2 |
Activity 2 Doing some work |
31/08/2017 16:58 |
User1 |
Activity 1 Doing some other work |
31/08/2017 16:57 |
User1 |
Activity 1 Doing some other work |
If user1 saves the model, the framework would compute the following commit description:
Activity 1 Doing some other work
If he has activated the preference "Require description for commit actions" a dialog will open suggesting this message.
If not activated and the preference "Automatically use the pre-filled description when none is provided" is activated, the commit will be made using this message as commit description.
To activate this strategy, go to the preference page: Sirius > Team collaboration. Select Pre-fill commit description and select CDO History. Be aware that this mode only works on an authenticated Team for Capella Server.
3.2. Using Mylyn
This strategy uses Mylyn tasks to compute a commit description. Using the template defined in "Preference > Mylyn > Team", it computes a commit description from an active and not completed task. This strategy is really handy when using "Automatically use the pre-filled description when none is provided" preference. Indeed, with this configuration, the user only has to activate or deactivate Mylyn tasks to have a clean history filled up with extra information.
To activate this strategy, go to the preference page: Sirius > Team collaboration. Select Pre-fill commit description and select Mylyn.
4. Export user activities
Once history filled up with meaningful information, the user might want to use it. To do so, he can export it to a model format using the "Export Metadata actions" from the Commit History view.
Another way to export metadata is by using the importer.
5. Use exported activities
Once the information has been exported to a file, a model editor can be used to browse the different activities that occurred on the server. Using the "text" tab, he has access to a textual representation of the current model. He can even request it using Aql requests (more documentation here). Here is a representation of the metamodel:
For example, he might want to request all users that have participated to a given activity. To do so, he could use the following AQL request:
aql:self.activities->select(a|a.description.contains('Activity 1'))->collect(a|a.userId)
Using a dedicated format in the commit description (defined here), the user can even creates its own custom properties. Each one of them will be transformed into ActivityProperty. It might be used to create more advanced Aql requests.
6. Comparing commits
When using a server configured with Audit mode, it is possible to compare commits between each other. To do so, the user should open the Commit History view. From there he can select one or two commits and use "Compare with each other" or "Compare with previous" menus. The comparison is done using Diff/Merge framework (see document here).
Limitation: The Commit History View allows merging consecutive commits with the same user and description in only one visible commit. The Diff/Merge actions are not enabled on this kind of commit. You have to deactivate first the "Merge Consecutive Commits" option to make those actions enabled.
In the picture above, the differences are stored under two roots each representing a resource.
-
Semantic resource (Test.capella): Under this root, all semantics differences are displayed.
-
Graphical resources (Test.aird): Under this root all graphical differences are displayed.
Be aware that at this time, the integration between Team for Capella and Diff/Merge do not offer merge functionalities.