Sharing elements across version controlled package

[bcrier]

Hi everyone,

I ran into a roadblock while sharing elements across version controlled packages. Please help with solutions or suggestions if you can.  Thank you.  Here are the detaials.  Let's say I have following packages:

Package A  --> Version controlled and currently Checked In
    Diagram A
    Element A1
    Element A2
Package B  --> Version controlled and currently Checked Out
    Diagram B
    Element B1
    Element B2

So I am happily working on Diagram B and bring in the element A1 as a Simple Link share type.  Now I establish association between B1 and A1 (source to destination) and it works.  Then I establish association between A1 and B2 (source to destination) and it does not work.  Reason A1 is not checked out.

So it appears that for an association to orginate from an element that element has to be cheked out.

My plan was to to have a project where certain parts of the project are checked in and hence locked, but the elements from these packages can still be shared by a broader team in their individual models.  Now that whole idea seems to be at risk.

How can I accomplish this in EA?  Any help is appreciated.

Bobby

[Geert Bellekens]

Bobby,

If you think about it it makes sense.
If you lock packageA (or not have it checked out) that means that you don't want to allow any changes to this package (and its owned elements).
Adding a relation from A1 to B1 is similar to adding an attribute to A1, it changes A1. If you don't want to allow adding attributes to A1 then you should allow adding an association from A1 to B1.

Geert

PS. I think there is still something wrong with the "source/destination" paradigm used by EA. EA always considers the source of a relation to be the "owner". This paradigm does not follow the UML rules about relationship ownership. The ownership of a relation should be based on the navigability of the ends of that relation.
In most cases however the "source/destination" paradigm works well enough to be usable.

[Paolo F Cantoni]

[size=18]...[/size]
PS. I think there is still something wrong with the "source/destination" paradigm used by EA. EA always considers the source of a relation to be the "owner". This paradigm does not follow the UML rules about relationship ownership. The ownership of a relation should be based on the navigability of the ends of that relation.
In most cases however the "source/destination" paradigm works well enough to be usable.

I think (haven't checked recently) if you look closely Geert, the UML specification about the ownership being based on the relationship ends ONLY applies to the ends themselves.  The relationship is not actually owned by anything...  (in fact, it can even own the ends! (if not owned by the client or supplier - and , for n-ary relationships n>2 the ends MUST be owned by the relationship))

HTH,
Paolo

[Geert Bellekens]

Paolo,

You are absolutely right. I was a bit quick to use the term "ownership".
What I was really trying to say that there is an issue in EA when it comes to defining relations between a "writable" element and a "locked" element.
If A1 is locked, and B1 is writable, I can only create a relationship where B1 is the source and A1 is the target.
Once that relationship is there I can do anything I want with the navigability on both ends.
So I can make an association A1 --->B1 as long as B1 is the source, and A1 is de destination.
The relationship above is known to A1 and makes A1 dependent on B1. That is a problem, because A1 was supposed to be locked, and not changeable. In my book adding a dependency to A1 to another element is in fact changing A1.

Geert

[Dave.B]

...
In my book adding a dependency to A1 to another element is in fact changing A1.

Geert

I agree! I try to be careful about the direction that I make associations in so that a logical source->target relationship is established, even for classes within the same package. And as the majority of associations are uni-directional I have set the option "Links->Association default = source --> target", which also has the effect of reminding me of which is the target since the association now has an arrowhead pointing at it.

What really annoys me is that if I use the toolbox composite association (white or black diamond end) that it insists on placing the diamond at the target end and thus forcing me to draw it in the wrong direction from logical target to logical source! Generally (when class modelling), I try not to be too lazy and start off with a plain association made in the right direction and then set the end properties appropriately. But in SysML, the only way that EA will let you draw a part association (black diamond) in a BDD is with the tool box, as the quick connectors list doesn't have the plain old association listed in it.

Regards
Dave B.

[Geert Bellekens]

There is a way to reverse the direction in which aggregations are drawn in EA.
Look in the options somewhere.

Geert

[Dave.B]

I've tried that, and it doesn't help! If you set the "Links -> Draw Aggregations Reversed" option you can draw the aggregation from logical source to target and the diamond is placed seemingly at the source end, BUT when you look at the associations properties you'll find that EA has reversed the logical direction that the association was drawn in and placed the diamond at the target end of it!

So what looks like a promising tool option is in fact useless!

Regards
Dave B.

[Frank Horn]

You  can use an association and then get your diamond on the right end with the "Aggregation" combo on the "Source Role" tab of the "Association Properties" dialog.

[Dave.B]

You  can use an association and then get your diamond on the right end with the "Aggregation" combo on the "Source Role" tab of the "Association Properties" dialog.

But as I said a few posts ago that only works in a class diagram and not in a SysML block definition diagram.

But in SysML, the only way that EA will let you draw a part association (black diamond) in a BDD is with the tool box, as the quick connectors list doesn't have the plain old association listed in it.  

Still, it is solution when class modelling, i.e. don't use the tool box connectors!

Dave B.

[bcrier]

Excellent discussion, and I agree that in a way adding an association between A1 and B1 (A1 being the source) is changing A1.  Or at least, this is how EA interprets it.

On the other hand, is a relationship an attribute of an element, source or destination?  In my opinion, an element (i.e. an object or class or anything) is standalone even if it is dependent on another element.  Isn't that the foundation of all modern system architectures?

I confess that I am not an authority on UML, and I am just using plain logic for this interpretation.  Seems like EA has incorrectly tightly coupled the relationships to the source elements.

I guess, if checked in elements cannot be linked "from", using EA security would likely result in the same situation e.g. if a solutions architect does not have the permissions to modify the "Enterprise Package" then he/she will not be able to establish links from that package (as source).

Bobby

[Geert Bellekens]

Bobby,

Unfortunately EA handles the "security locking" in a different way then the "version control locking".
When an element is set to "read-only" by the security locking you can still add relations to this element, regardless of whether it is the source or target.

On the discussion about whether or not a relationship changes something to the element; in fact according to UML, when you add an assocation to a class, and this class knows this relation, that is equivalent to adding an attribute.
The memberends of an association map to ownedattribute of a class.
In case of a generalization, this generalization is owned by the "specific" subclass.
I think it is safe to say that adding a relation "known" to a class is in fact changing the class, just like adding an attribute would change the class.

Geert