Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Kristofer

Pages: [1] 2 3
Thanks for the options!

The Custom Compartment with RelatedElement is also interesting.

This is the situation:

We have information flow diagrams showing our applications. We have added tagged values for ID, alias, lifecycle, status and other things related to the application. Everyone needs to see the ID and alias so we know that we are all talking about the same application (different parts of the organisation seems to use different names). The other tags are mostly targeting the more advanced group and is not of interest to the "general public"; hence I would like to hide them in some diagrams. Using tags is also a convenient way to make things searchable (i.e. show me all applications that are under development).

Right now I am trying to find out the best way to do this. We can still change the way we work. Is custom compartments a better way?

I could use the diagram stereotype to show different tagged values. This shape script will go into a mdg profile later, so it may be better to use Type or MdgType.


We have an element type with several tagged values. Some of them are relevant to one group of people, and others are relevant to another group. Unfortunately we cannot select which tagged values should be visible in a certain diagram.

So to solve atleast some of the problem, I would like to create a shape script that always shows the tags that are relevant for all people, and if someone creating a diagram want to show all tagged values, that is up to them.

I thought that one option is to use "shape label" with SetOrigin = SW.

Code: [Select]
shape label {
   SetOrigin("SW", 5, 35);

This makes it possible to hide these tagged values if someone wants to show all tagged values (instead of having duplicate information). The problem is however that the default width of the label is too short so the user needs to immediately change the width. The maximum width of the label may also be too short, which makes the text wrap.

Is there another (better) way to do this?

The requirement is essentially:
  • Show the value of certain tagged values, somewhere inside the element, each on its own line.
  • Don't wrap the text
  • Preferable (but not a requirement), hide this if all tagged values are shown on the element

General Board / Re: Labels moving around by themself
« on: October 25, 2017, 09:27:49 pm »
I found the post in the forum, but I don't think they are related.

I have to keep an eye on the diagrams and see if I cant find any pattern that causes the change.

General Board / Labels moving around by themself
« on: October 24, 2017, 11:00:26 pm »
I have a very annoying problem when working with information flow diagrams; the connector labels are moving by themself!

When I create the diagram I position the connector labels (the one showing the conveyed information items and the stereotype label). Everything looks fine, I save, store as image, and close the diagram. At some other point I open the diagram again, and the labels are somewhere else, meaning I have to spend time positioning them again (and again the next time I open the diagram).

I have 30+ information flow diagrams, and when we add/remove a conveyed item, all diagrams showing this connector need to be re-published so they are consistent. This means...I have to open all diagrams and re-position the labels and save to image manually.

The labels also change size. If we have 10 conveyed items on a connector we cannot always have them all on one line, so we increase the height. When the diagrams is opened at a later point, the size of the label can be something else (but not all on one line).

This does not happen all the time when opening the diagram. Sometimes the labels stay where they should, and sometimes they move. I have not been able to find out the cause. "It just happens".

I emailed Sparx about this, but haven't got any answer so I wonder if someone else have experienced this and have a solution. This is very time consuming.

Using EA 13.0.1309.

General Board / Re: Diagram filter and missing tag
« on: August 24, 2017, 05:44:59 pm »
I did so!  :)

General Board / Diagram filter and missing tag
« on: August 23, 2017, 05:49:55 pm »

When you create a diagram filter, you can filter on a specific tag and its value. Is it possible to also filter on elements that are missing a certain tag?

For example:
I want in my diagram to show:
- All elements with the tag XYZ with a value of abc
- All elements missing the tag XYZ

So essentially, I want to show all elements in the diagram, except for those with a certain tag with a certain value.


I did not experience any big issues in EA 12.

I just discovered that you can "work-around" the bug(?) in EA 13 by first adjusting the connector the way you want it (while line style is custom), open its properties, change the line style to "Orthogonal - Rounded" and close the Properties dialog box. It will look strange in the diagram, but just save it anyway, close the diagram and open it again. It now looks "okay".

I hope they (re-)implement this feature. If all other connectors are rounded in the class diagram, people wonder if there is a special meaning why these connectors are not rounded.


In EA 12 you could have rounded corners for relationships to itself. You just changed the line style to "Orthogonal rounded". This does not seem to work in EA 13 and you are forced to use a "Custom line", which does not have rounded corners. Since all other connectors in our diagrams are rounded, it looks a bit odd.

Is this "by-design" in EA 13, or a bug?

Uml Process / Re: Realize information flow, how does it work?
« on: April 01, 2017, 01:25:57 am »
Thanks for the explanation!

That might give me some new insights, on monday.  :-)

Uml Process / Re: Realize information flow, how does it work?
« on: April 01, 2017, 12:31:06 am »
Hmm, perhaps I misunderstand ports, or did not use it properly.

When I used ports i thought of it as one port equals one interface. So if another application used several interfaces/ports on the same application, several connectors was created. Essentially, it resulted in that each diagram was focused only on one application, and the overall information flow (the flow of information items through systems for receiving, storing, maintaining and making data available to others) was lost. The diagrams became too cluttered that it was not readable anymore.

Do you have any example diagram?

Uml Process / Re: Realize information flow, how does it work?
« on: March 31, 2017, 11:09:35 pm »
Thanks for your answers!

Uffe, you are probably right, the problem arises when we need to show both the outside and inside at the same time.

Our situation is this; we have about 150 applications communicating with each other, and we need an overview of how these are connected and what information items are flowing (1). These applications may have one or many interfaces, and we also want to know "who" is using a particular interface in case it will be changed in the future (2). These two are the the main needs (at this moment).

In some cases, we cannot really agree on what an application/system/component is, hence in some situations we need to make a more detailed view (the inside) to be able to communicate with different groups of people. If you say "System A", it has different menings to different people.

We actually used ports in the information flow diagrams when we started, but realised after a while that it has a visual drawback.  If you have one application with 5 interfaces/ports, and you have another application using all 5 of these, you end up with 5 connectors, just between these two applications. Put in another few applications and you end up with a diagram with a lot of connectors.

So I am trying to find the best way to document (1) and (2), and still have it maintainable over time with as little risk as possible for it to become contradictory.

Uml Process / Re: Realize information flow, how does it work?
« on: March 31, 2017, 05:57:56 pm »

Of course this is possible, and I am starting to think that perhaps we need to do that. But if there is a "proper" way to do this, I would like to use that way, so we don't end up with unnecessary connectors that we cannot maintain over time. If people forgets to change/delete/add connectors in one diagram, what should we consider the truth? If the information flow diagram says there is an information flow between two applications, but the information flow is not realized, which diagram is showing the reality? Which diagram was forgotten when something was changed?

So I am essentially trying to, as long as possible, have "one source - one update", without duplicating things just because it is necessary to show it visually.

Uml Process / Re: Realize information flow, how does it work?
« on: March 31, 2017, 12:16:54 am »
Thanks, you are correct, it should go the other way!

Any ideas on the other questions?

Uml Process / Realize information flow, how does it work?
« on: March 30, 2017, 07:23:00 pm »

I am in the process of documentating our existing IT systems. I want to do this on two levels, a higher level with only the information flow, and then a little bit more detailed level on how two systems interact with each other (for example what other systems use a REST service provided by a system). The first image shows an example of the higher level (information flow diagram), and the second image shows an example of the lower level (component diagram).

The question is however how to best do this in EA, without messing up with unnecessary connectors all over the place.

Since a few questions araise, i am not sure if i do this correctly, so i would appreciate if someone could tell how to best accomplish what I have described above.

Questions (assuming i have created the information flow diagram):

I drag a dependency relationship from required interface Customer to provided interface GetCustomer. I select "Information Flows Realized" and get two options "Order, Customer" and "Order, Customer" (the two information flows already between the components). The information item here is obviously only Customer (Order is to another interface).

I can select one of the options in the list, and click on the ellipsis button to select Customer, but this changes the information flow connector to only convey Customer.

I can also click on the "Click to create new information flow" to add Customer, but the list will now have three items. This also actually adds two connectors between the interfaces, one dependency and one information flow connector.

What should I do? The benefit of selecting one of the options in the list is that the information flow connector will be "hidden" in that diagram (the two connectors lies on top of each other) and I don't have to manually hide it. But I also don't want to create one information flow connector for each information item.

The interface CreateOrder is a delegated interface provided by an internal component of "Some System", so the interface is attached to a Port. If I do the same procedure as in A above, the list will be empty. Does this mean that I have done something wrong in my modelling?

Or am I doing this completely wrong?

Pages: [1] 2 3