Connecting Locked Elements - is there a away using v13?

[Paolo F Cantoni]

We have the repository set up so that we have different groups.  We have also separated the diagrams from the items.

One of the groups is Enterprise Architects - who can do stuff in the Enterprise branch (set up for Group: EAs), another group is the Solution Architects who work in the Projects branch (set up for Group: SAs)

We don't want SAs to change EA objects, but we are prepared to let them add/modify/delete relationships between them.  EA Stops you creating relationships between two locked objects (at least as of v13).  Is there a way to allow the relationships to be created?  Am I missing some arcane permission or is it just not allowed and I need to submit a feature request?

I don't want to get into the philosophical argument that "manipulating relationships is (effectively) modifying the element".  I'm after a practical solution to the problem.

TIA,
Paolo

[Boron]

We have some similar "problem" with our approach of designing/modelling the software in our company.
We additionally have our packages under version control that also prevents adding relationships in other diagrams.

Our solution:
We are not using the originals elements (e.g. classes) in diagrams outside the original package, but we are using instances or properties of the elements.
Thus the original elements remain unchanged but the instances are related somehow via any kind of thinkable relationships.

[PeterHeintz]

Hi Paolo,
I do not have an exact solution to you problem, but maybe I can point you to a direction which might help you.

About the philosophical argument, I mean if relationships are own entities, you do not change the items those refer to.
But if the relationship is owned by those items you change those owning item if you change the link. Then there is always the question who is the owner and when access rights come in place the users get lost.

Maybe the Asset Service can help, you but I cannot exactly explain why. I can just give you my observations.

I have a library intended to be used by many projects. This library I maintain in a separate repository to have it clean (no references to any usage).

This library I import in a concrete project via EA Asset feature. In the project I lock the asset package for any user. The project related stuff I put in other packages having user group locks.

When modeling in my project related packages I can link from my project related stuff to the read only assets in any direction (from my point of view essential when using assets).

But even more, I can create links between asset elements as well. What from my point of view changes the asset and should therefore not be there, but maybe it is the door to solve your problem (as long as the door is not closed by a bugfix).

When updating to a new asset version I do the following on the projects using the asset library:
1.   Backup all somehow (just if disaster happens)
2.   Baseline all project related stuff (excluding asset library).
3.   Import new assert library version
4.   Restore baseline

After step 3, some (but not all) project items to asset items relationships are lost (presumably those owned by the “read only” asset items because the new asset version do not have those anyway).
After step 4, those lost relationships are there again, because presumably the baseline knows those missed but “not owned” relationships as well.
Links created between assets are lost in any case (not a problem in my scenario).

Maybe if you handle your elements as assets and your diagrams as “project related” it might work for you. The question is how long?!?

[Geert Bellekens]

I wouldn't bother sending in a feature request to reverse what is essentially a bugfix (allowing the creation of links between locked elements is surely a bug).

I'm pretty sure they will not undo that fix (at least I wouldn't if I were in their shoes).

So I guess you'll either have to revise your security policy (which is flawed anyway, why would you want to allow people to create relations to things they are not allowed to change?) or you'll have to go through the backdoor and create a script/add-in that creates the requested relation directly in the database.

Geert

[PeterHeintz]

Hi Geert,
Yes, there are bugs in somehow, at least when you connect items in the asset library.
However a library is only useful if used. And using something in UML is e.g. using as classifier, as a part, as reference, as …. And most of that usage in UML you do by drawing some kind of line between elements.
On the other hand a library should not change by its usage (at least from my understanding).

For instance in my library I have some SysML blocks describing some ARM controllers.
In my project related model I have some PCB’s referring to the controller via part relation. By doing so, I use the ARM library item but I do not want to change it.

I think the problem is somehow that links are not entities of it’s own in EA somewhere.

However to allow to change a library for all library users makes the asset service useless.
In other words, yes I think there are some “bugs” in that area, but some can probably only be fixed before the connectional basis is changed.

[Graham_Moir]

So I guess you'll either have to revise your security policy (which is flawed anyway, why would you want to allow people to create relations to things they are not allowed to change?)

Actually I'm not sure it's flawed.  We have the situation where the Enterprise (Business) Architects have defined corporate "Capabilities" and "Functions" amongst other things.   We want the Solution Architects to link/create relationships to these elements/objects so that we can understand which projects, new solutions, existing systems etc. etc. relate to those top level entities.  But we definitely don't want anyone except the Enterprise Architects to change the definition of them. 

[Paolo F Cantoni]

So I guess you'll either have to revise your security policy (which is flawed anyway, why would you want to allow people to create relations to things they are not allowed to change?)

Actually, I'm not sure it's flawed.  We have the situation where the Enterprise (Business) Architects have defined corporate "Capabilities" and "Functions" amongst other things.   We want the Solution Architects to link/create relationships to these elements/objects so that we can understand which projects, new solutions, existing systems etc. etc. relate to those top level entities.  But we definitely don't want anyone except the Enterprise Architects to change the definition of them.

We had a discussion at our "Modelling Review Board" following the initial posting and discussion here.  We came to the conclusion that (although initially, I said I didn't want to get into the "changing the relationships of the item is modifying the item") there is NO getting away from the fact that modifying the relationships modifies the item.  So we decided to only allow the EAs to change enterprise level objects and the SAs etc. would have to ask an EA to do it.  The Board decided that it was a good opportunity to create discussion between the EAs and the other architects.

We'll see how it goes...

Paolo