Which elements are locked by Team for Capella?

Hello,

I found Team for Capella as a Capella Add-on to enable simultaneous editing of the same Capella model.
Could somebody do me a kindness and either explain to me what exactly is locked or give me a pointer to some kind of documentation?
The only resource I was able to find was a Demo on Youtube which only states that elements are locked.

I greatly appreciate your help!
With best regards,
A. Zwenger

Hi Adrian,

You will find more information on this page: https://www.obeosoft.com/en/team-for-capella
including at the bottom where it points to a dedicated webinar on the topic.

From there you can contact Obeo if you need more information.
All the best,
Stephane LACRAMPE
Obeo Canada

Hello Stephane,

I am grateful for your response!
I have checked the website and have seen the webinar. However, it is only shown what is locked in one diagram. I am asking myself which other elements in other diagrams are locked as well. Let’s say I am editing an element from the “customer operational Need analysis”. Are all representations and refinements of said element locked in all the following Arcadia steps as well? And what is considered as the elements “closest dependents”?
Thank you in advance! Best regards,
A. Zwenger

Hi Adrian,

So the general idea is that we are locking as few elements as possible while guarantying that there will never be a conflict between two users editing the model.
The rules are the following:

    1. If you have the lock on an element, this means that others cannot change its properties/attributes. For simple properties like name, others cannot change it while you have the lock. For properties that are lists (references…), this means that others cannot change the list (ie add/remove elements from the list) but they can still modify existing elements in this list.

For example, when a Function is locked, others cannot change its name, or add/remove Ports or add or remove sub-Functions. They may still modify the properties from its previously existing ports or sub-Functions though.

    1. So, when using Team for Capella, when you start to edit a simple property (name…), you will take the lock of the element.

For example: if you edit the name of a Function, you take the lock on this Function.

    1. Then, when you start to add or delete an element for the list, then it takes the lock on the container of this list.

For example, if you add a Port to a Function, or if you add a sub-Function to a Function, then the Function gets locked.

    1. A locked element is rendered as locked in all opened representations and in all views.

For example, if you have the lock on a Function, others will see it as locked in all opened diagrams/tables as well as in the Project Explorer tree view. That does not mean that the diagram itself is locked, only the Function is.

  1. For Diagrams: if you have an open diagram, and if you start modifying the graphical aspect of it, then you take the lock on this diagram. This means that others cannot change the graphical aspect of this diagram.

For example, if you refresh an open diagram, or re/arrange elements on this diagram, or resize a function in this diagram, then you take the lock on this diagram.

Another example: if you change the name of a Function in a diagram you have opened, then you take the lock on this diagram, because changing the name of a Function will change the graphical aspect of your diagram. If you change the summary property of a function, this won’t take the lock on the diagram. Going back to the Function name change: once you have the lock on a diagram, others may still open this diagram, they may still do changes on objects in this diagram but no changes that will change the graphical aspect of the diagram. For example, they won’t be able to rename other functions from this diagram because the diagram is locked. Nevertheless, they may still change the name of other functions that appears in this diagram from other diagrams or from the project explorer view for example.

  1. When a user edit a model element or a diagram, then locks are taken automatically according to the previous rules, and other users are automatically and instantly notified of these locks

  2. When a user saves its changes, locks are automatically released and other users are automatically and instantly notified of these lock release

Now, from there it is obvious that I have not described all the rules, and one can be imaginative (what about explicit locks, what about tables, what happens if a user leaves/is disconnected, etc…) and there are other functions related to locking/unlocking, but in the end the following principle is “we are locking as few elements as possible while guarantying that there will never be a conflict between two users editing the model” to ensure a smooth collaboration between users.

I hope this should be answering you questions.

Stephane Lacrampe
Obeo Canada

2 Likes

Hello Stephane,

Thank you so much! This has cleared a lot of confusion! Thank you.

However, It is still unclear to me what is locked in other Arcadia steps.
If I were to edit an Actor in the “customer operational need analysis” while somebody else is working on the “System/ Sw/hw Need analysis”, what would be locked there?
What the corresponding system entity be locked? Furthermore, would all corresponding representations of the actor be locked in all other steps too?

Thank you in advance. With best regards,
A. Zwenger

@aztuda my understanding is that the model elements are all independent at the different ARCADIA layers, that is, a change in a model element at Operational Analysis (OA) level will not lock the traced element down in the System Analysis (SA) of further below in the architecture.

When transitioned from one top-level to the next level-down, new model elements will be created and traced/referenced to the upper-elements, that makes a good use for traceability.
Hence, when you lock an operational entity at operational analysis will not affect the system actor at system level.

Any changes at OA may need then to be agreed and transitioned to the SA to be reflected at SA.

I hope that helps,
HĂ©lder Castro

1 Like

@aztuda
If a user takes the lock on an OA Actor, nothing will be locked in the SA level, not any semantic element nor any diagram, even if there is a traceability link with an SA Actor.

Now the other way round: if a user takes the lock on a SA Actor, nothing will be locked a the OA level. not any semantic element nor any diagram, even if there is a traceability link with an SA Actor.

I guess your question may be: but what happens in these cases with the traceability link between the 2 Actors? The traceability link between the OA and SA Actor is stored in the SA Actor. So when the SA Actor is locked, only the holder of the lock can change this link.
One consequence of this: let’s say a user SA takes a lock on an SA Actor. Let’s say another user wants to delete the OA Actor: he won’t be allowed to do it since the OA Actor deletion requires the deletion of the OA/SA Actor traceability link. Beyond this case of deletion that triggers a modification at the SA level (if a traceability link exists between the 2), the user working at the OA level is free to modify its OA Actor.

Now another topic, diagrams: generally speaking, taking a lock on an Actor does not trigger any lock on diagrams. A diagram is locked only when there is a modification on the model that triggers a change on an OPEN diagram. So for instance, if you have no diagram open, you go on the project explorer and change the name of an Actor, you will take the lock on the semantic model element corresponding to this Actor but no diagrams will get locked.

Please do not hesitate to contact us if you’re interested in acquiring some licenses.

I hope this helps.
Stephane Lacrampe
Obeo Canada

2 Likes

Thank you so much for clearing this up @HelderCastro and @StephaneLacrampe !
Best regards,
A. Zwenger

1 Like
Copyright © Eclipse Capella, the Eclipse Capella logo, Eclipse and the Eclipse logo are Trademarks of The Eclipse Foundation.