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.

16. Change Management cdoactioncapability

3. Filling up extra information

In Team For Capella, there are two ways to fill up the extra information attached to a commit.

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:

16. Activitymetadata class diagram

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)
16. Aql request example

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.

16. Compare with diff merge

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.