Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: LeeD on December 19, 2013, 07:19:12 am
-
Hi
Is there a way in ea 10 to default new connectors to not show in other diagrams? I know I can right click on them/visibility/hide connector in other diagrams but when you're making a lot it's a pain.
Cheers
Lee
-
No, there is not.
-
Consider this a feature request then :-)
-
I fully support this feature request!
-
I must admit to being puzzled by this request...
If an association is not appropriate on all diagrams, maybe that is a case where you have two classes which appear to be the same thing...
...but are actually separate things.
In the past, stray associations on diagrams has demonstrated flawed thinking on my part.
Andy
-
I agree with Andy.
If you really need this feature you are doing it wrong 8-)
If a relation between two elements shouldn't be shown anywhere but in one location then the relation probably shouldn't exist in the first place.
Remember, EA is not Visio. It' a modelling tool, to build models that can be graphically represented. Not a tool to make pretty pictures.
Geert
-
Hi,
in principle I agree with Andy and Geert.
There are diagrams like context diagrams which represent special views where only particular relationships are viewed. They are valuable because they show a useful view for a particular question.
I don't know the silver bullet but I'm also annoyed by unwanted relationships.
My idea is: In a digram you can control if a new relationships is automatically added or not.
In my opinion: A diagram is a view to the model. Therefore there is no need to visualize all relationships. The author of the diagram has to say what the meaning of the diagram is (the story of the diagram, or what I want to tell you).
Helmut
-
I'm with AndyJ and Geert. Honestly I was about to write the same but did not for not being too grumpy with Christmas so near.
q.
-
I agree with what Helmut writes. To say it in other words: there is a difference between a model (containing concepts) and the representation of the model (references to concepts). A diagram is a representation.
For example I have three concepts: role A, role B and role C (guess you use ArchiMate). All those three roles have relations with each other (let's say flows).
Now I create a diagram in which I want to focus on role A. So I have roles A, B and C, and only the relations in which A is a party.
And now the awkward thing occurs: whenever I add a relation between B and C, it's added to my diagram that has A as focus.
Grrrrrr.....
A modelling tool should offer good support to this. (Visio is not a modelling tool, but a drawing tool.)
-
I like Helmuts suggestion too.
I'm not against hiding relations on some diagrams. I'm against hiding relations on all diagrams (but one).
Geert
PS. Now I'm going back to my cave before the whole christmassy thing starts :P
-
I am frankly amazed at the trend I am seeing here.
I am also retreating to my cave to avoid Christmas!
Yours in Grinchliness...
Andy
-
This is probably not so much a cut and dry topic. But, the overarching issue here is that many people use these tools in different ways. What one person may think is poor modeling using one paradigm, it could be considered good practice in another. The way for a tool like this to support many users is to provide the ability to configure the different default characteristics per type, stereotype, diagram, etc. If there were settings allowing you to override the default relationships that show up on a given type of diagram, this would meet the need I believe.
As for this being a modeling issue. I find that sometimes people operate too much at a "global" level. So, they define flows (dependencies) between classes/blocks instead of between properties/parts. If you want to say data flows between System1 and System2, that relationship would show up in all cases. What if you want to assert that in a certain situation, data does not flow, or a different type of data flows?
This is why I think modeling a Domain or other context element, then associating (composition/reference) the Classes/Systems provides some containment for your modeling into a specific context. I could have a System of Systems domain block, that has a composition relationship to System1 and System2. System1 and System2 are given a role.
Then, you could allocate behavior to sys1:System1 or sys2:System2, or define Flows between them, and then these relationships would not show up when you place System1 or System2 into a different diagram. Of course there will be cases where this doesn't make sense, but this is how I typically handle it.
-
In my opinion: A diagram is a view to the model. Therefore there is no need to visualize all relationships. The author of the diagram has to say what the meaning of the diagram is (the story of the diagram, or what I want to tell you).
I concur with this, for example in some high level or conceptual diagrams I show connections between major components that don't belong in detailed diagrams.
Simon
PS did I mention that an EA release concentrating solely (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1307921175/2#2) on diagram (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1277094607/0#0) enhancements (http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1313372981/1#1) would be a good thing?!
-
I know this is an old topic but Sparx Support referred me to this within the last 24 hours, so ...
ArchiMate might be a bit different than other modeling languages. If I have three elements A, B and C and relations from A to B and from B to C it might be relevant to show this on one diagram and then - on another diagram - only show A and C with a *derived* relation. The language has specific rules as to which relations can be derived from which. Therefore it IS highly relevant to be able to add relations without showing them in all previous diagrams.
To me the solution might be simple: If I lock the first diagram I thereby say that I don't want anybody to change anything. Sparx might then add the derived connection to the diagram but automatically turn the visibility off. If the diagram is not locked, Sparx can act as usual and make the new connection visible.
Feature request?
-
Yes. But probably one that ends up on (or under) a pile of other requests. Probably the fastest is to run a script on a regular basis which is altering the views in a way you want it. Later you could think of using an add-in to support that behavior on the fly.
q.
-
I know this is an old topic but Sparx Support referred me to this within the last 24 hours, so ...
ArchiMate might be a bit different than other modeling languages. If I have three elements A, B and C and relations from A to B and from B to C it might be relevant to show this on one diagram and then - on another diagram - only show A and C with a *derived* relation. The language has specific rules as to which relations can be derived from which. Therefore it IS highly relevant to be able to add relations without showing them in all previous diagrams.
To me the solution might be simple: If I lock the first diagram I thereby say that I don't want anybody to change anything. Sparx might then add the derived connection to the diagram but automatically turn the visibility off. If the diagram is not locked, Sparx can act as usual and make the new connection visible.
Feature request?
This is an important modelling topic. The ability to "zoom" in and out and show a model in more or less detail is very useful indeed. This can obviously be done manually, by explicitly hiding and showing connectors in diagrams (which indeed are Views). It would be nice if a tool understood the modelling language to such a degree that is could help with this. I think that certain Archimate-specific tools can indeed do this. But this is not easy and very much modelling-language dependent. For example... When A and E are connected via B, C and D with various intermediate elements and connectors.... What then is the relationship to be shown between A and E? I don't think the Archimate semantics will always be unambiguous in such cases. So I can understand that Sparx is not (yet) supporting this :-) although there are certainly simple cases where tool support would not be very complex.
-
In ArchiMate the different types of relations have different strength. The derived relation between A and E is the weakest of the relations in between. But you only add the derived relations if you need them in a view. You might also specify a "proper" relation between A and E, eg. an "association" which is always allowed.
I guess you cannot automate the decision on which relations to show in which diagrams, neither by scripts nor by an AddIn.
But it would indeed be a great help if a locked diagram was ... locked(!). And it should be a very minor and simple change in Sparx.
-
And it should be a very minor and simple change in Sparx.
Like me you don't know EA's architecture. Though, I probably can guess it. And it's definitely not that simple.
q.
-
But it would indeed be a great help if a locked diagram was ... locked(!). And it should be a very minor and simple change in Sparx.
That's a diagram centric view not a model centric view. A diagram is a representation of a number of elements in the model. Elements that can belong to anyone, not just the creator of the diagram.
-
But it would indeed be a great help if a locked diagram was ... locked(!). And it should be a very minor and simple change in Sparx.
That's a diagram centric view, not a model-centric view. A diagram is a representation of a number of elements in the model. Elements that can belong to anyone, not just the creator of the diagram.
As Glassboy says, the diagram is merely a specific view into the underlying model. The question of derived relationships is also more complex than ArchiMate proposes. And regardless of EA's internal architecture, as qwerty says "definitely not that simple"
In our methodology, we distinguish between at least 4 types of derived (from canonical) relationships:
By Traversal - the "classic" ArchiMate mechanism: grandparent_of(x) => parent_of(parent_of(x))
By Union - the aggregation of a number of separate semantics between the same two classifiers: knows(x) => parent_of(x) | child_of(x) | works_with(x) | is_friends_with(x) | (etc.)
By Projection - a binary relationship that is a "projection" of an n-ary relationship (usually an Association).
By Generalization - where the derived relationship is the Generalization of the relevant canonical relationships (whether by reverse inheritance or reverse restriction). Typically, this is because one of the relationship ends of the derived relationship is a Generalization of the appropriate ends of the canonical relationship.
Any given derived relationship can be a combination of the above if more than one traversal is involved.
In addition, there is the problem of explicit versus implicit "Association".
Explicit Association is where we REALLY mean the classical Associative Relationship - an n-ary (typically binary) relationship with defined multiplicity at the destination AssociationEnd. This specifies the number of instances of the destination classifier (under that AssociationEnd) for each instance of the origin classifier under the semantics (via name) of the Association.
Implicit association (on the other hand) is like the "association" (note the small "a"), that Lise Gerd Pedersen mentioned. What we in Oz would call the "Clayton's association" (aka "the association you have when you don't have an Association"). These types of "associations" are not explicit (as above). Instead, they represent an unspecified relationship between the two classifiers, but since ArchiMate doesn't have the «Unspecified» relationship, they fell back on "association". However, since you can't specify the explicit semantics of the relationship (and therefore you can't name it); by the Bjelke-Petersen "Duck Test" - it's not a duck ("Association").
Our shapescripts handle derivation in a consistent way, indicating the types of derivation and providing consistent rendering (so that it's clear on the diagram that the relationship is derived). In addition, with the recent ability to have relationships between relationships, we can explicitly model which relationships are involved in any specific derivation.
So, the decision of whether or not to render the derived relationship is highly dependent upon the viewpoint and the specific view of the diagram. I don't think it can be automated.
Paolo
-
But it would indeed be a great help if a locked diagram was ... locked(!). And it should be a very minor and simple change in Sparx.
That's a diagram centric view not a model centric view. A diagram is a representation of a number of elements in the model. Elements that can belong to anyone, not just the creator of the diagram.
And it is MUCH easier to hide a connector that you can see than show a connector that you can't see. If you open a diagram and see that a new connector has suddenly appeared, that means that there is new information in the model that the person who created the diagram wasn't aware of. If it belongs in the diagram, great; if it doesn't, hide it. Better that than opening a diagram and not knowing if there is new information that may need to be shown.
-
And it is MUCH easier to hide a connector that you can see than show a connector that you can't see. If you open a diagram and see that a new connector has suddenly appeared, that means that there is new information in the model that the person who created the diagram wasn't aware of. If it belongs in the diagram, great; if it doesn't, hide it. Better that than opening a diagram and not knowing if there is new information that may need to be shown.
That's certainly pragmatic. The ArchiMate shapescript is probably the second or third worst in the base product, but the most worked on by your more knowledgeable customer base. It would equally be as pragmatic to ask for their improvements and fold them into the product.
-
And it is MUCH easier to hide a connector that you can see than show a connector that you can't see. If you open a diagram and see that a new connector has suddenly appeared, that means that there is new information in the model that the person who created the diagram wasn't aware of. If it belongs in the diagram, great; if it doesn't, hide it. Better that than opening a diagram and not knowing if there is new information that may need to be shown.
That's certainly pragmatic. The ArchiMate shapescript is probably the second or third worst in the base product, but the most worked on by your more knowledgeable customer base. It would equally be as pragmatic to ask for their improvements and fold them into the product.
One thing we've toyed with is a "widget" to indicate that there are hidden relationships on the diagram. It's easy enough to run a query (behind the scenes ) to determine if there are hidden relationships on a diagram and add/remove the widget as appropriate. Obviously, it would be better if it was automagical.
"Information: This diagram has hidden relationships. You may be missing some information. To see which relationships are hidden, use the "Set Visible Relationships" dialog [Ctrl+Shift+I]"
Paolo
-
But it would indeed be a great help if a locked diagram was ... locked(!). And it should be a very minor and simple change in Sparx.
That's a diagram centric view not a model centric view. A diagram is a representation of a number of elements in the model. Elements that can belong to anyone, not just the creator of the diagram.
And it is MUCH easier to hide a connector that you can see than show a connector that you can't see. If you open a diagram and see that a new connector has suddenly appeared, that means that there is new information in the model that the person who created the diagram wasn't aware of. If it belongs in the diagram, great; if it doesn't, hide it. Better that than opening a diagram and not knowing if there is new information that may need to be shown.
You have right- user (like I) see what is "new" but:
- if someone delete relation from Repository, or change it betwen object - you can't see it. Someone, who want delete object or relation- can do it, even diagram are "Lock". When Object have "Lock" - yuo can still delete conect betwen him and other
- Sometimes We ( I & my group) doing diagrams with the same objects (difrent scope). On each of them we leave only few most important relation. But when I add new relation on second diagram I must still choose "Visiblity"->"Hide connector on other diagrams"- relation by relation... Or back on first diagram & hide all unnecessary.
In EA 14 We finally can Hiding many selected relations in one "Click" (Personally, I think that this is the biggest argument for switching to this version. Finally I can editing many relations in this same time)- But in old version user must do it connect by connect
-
I agree with what Helmut writes. To say it in other words: there is a difference between a model (containing concepts) and the representation of the model (references to concepts). A diagram is a representation.
For example I have three concepts: role A, role B and role C (guess you use ArchiMate). All those three roles have relations with each other (let's say flows).
Now I create a diagram in which I want to focus on role A. So I have roles A, B and C, and only the relations in which A is a party.
And now the awkward thing occurs: whenever I add a relation between B and C, it's added to my diagram that has A as focus.
Grrrrrr.....
A modelling tool should offer good support to this. (Visio is not a modelling tool, but a drawing tool.)
The tool offers support for this, via automation. We use scripts to 'tidy-up' context diagrams, so they show only the associations of the system of focus. I admit, it's something you have to build yourself but it is possible and not difficult!
-
The tool offers support for this, via automation. We use scripts to 'tidy-up' context diagrams, so they show only the associations of the system of focus. I admit, it's something you have to build yourself but it is possible and not difficult!
Maybe a decade ago, I suggested that when a relationship is added, EA could pop up a dialog (similar to set visible relations) that determined which diagrams the new relationship might appear on, and you could deselect those that you didn't want it on.
It might be time to resurrect this concept.
Paolo
-
Two ideas for improving the issues raised in this thread:
- There are design tools where connectors are "first class citizens" and have more or less the same status as elements like components and interfaces. I suppose this requires a completely different architecture of the tool but it may resolve some of the issues raised here. It would e.g. make it possible to create views that contain a filter on connectors.
- And while EA does have the concept of Diagram Filters, such filters are NOT part of a View but instead work globally over all views! Very regrettable I think. Why not make diagram filters part of a view/diagram?