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 - Geert Bellekens

Pages: 1 2 3 [4] 5 6 ... 540
General Board / Re: Importing glossary terms
« on: May 10, 2018, 02:42:26 am »
You can use my Excel Importer to import glossary tools.


General Board / Re: SQL query: how to use "like" in "where" clause?
« on: May 04, 2018, 08:45:29 pm »
In EA you can use #WC# which will be translated to the correct wildcard by EA (* for .eap(x) files, and % for anything else)


General Board / Re: Rule model toolbox
« on: May 04, 2018, 04:49:29 pm »
I think you need to upgrade to the Unified edition.



General Board / Re: MDG Profile derived from sysml in V14
« on: May 04, 2018, 04:03:24 pm »
Wow thats interesting,  I can see SysML 1.1 , 1.2, 1.3 and 1.5, just noticed 1.4 is missing, looks like we've to change to refer to either 1.3 or 1.5.

One of the Sparxians commented about this a while ago.
IIRC there were so little differences between 1.4 and 1.5 that they simply renamed it instead of having them as separate versions.
So version 1.4 is now version 1.5.

I'm not sure how or if you need to you upgrade from 1.4 to 1.5


The resulting tagged value will indeed contain the GUID of the package as value.

You can use Repository.GetpackageByGUID() to get the package object


Yes, a known issue.

There is actually a difference between the SQL server database format and the .eap database format.

I once reported it as a bug, but I got the "it's a feature, not a bug" response  :-\


To Geert's points, if I understand them correctly, they rely on multiple instances of the Repository.  I guess one of my (implicit assumptions) was that there was ONLY one repository.

As part of our possible future solution description, we have a "Transition diagram", where we place the model items (vertices and arcs) in the current state. We then add the future items and connect the current and future things with a "Transitions to" relationship.  With EA recent ability to allow relationships between relationships and relationships and items, we can specify what the transition will be to the requisite level of detail.  It's a really easy way to see if we've "considered everything".

Consequently, we need to maintain all versions in the one repository to allow us to map between them.


Using different repositories is more of a workaround then an actual requirement.
Having one repository where we could maintain all versions would be ideal.
But in that case the tool would have to support that in a transparant way.

For example, if I want to query all use cases I only want to see those of the branch I'm working on, not the ones from other branches (unless specifically instructed)
Or if I want to set the type of an attribute, I only want to be able to select classes from the same branch
Or... etc..

Seems like you should be able to set the context you are working in (MIGHT-BE alternative X) and the tool should then support this in such a way that you only work with elements that are in that branch.
I can imagine that would be a serious challenge to implement that properly in a single repository.


Using version control we can achieve some of these requirements already.
- Investigate a previous (AS-WAS) state (create a branch based on a certain date and restore that to (a copy of) the model)
- Create different alternative MIGHT-BE scenarios (again using different version control branches in different models)

The major difficulty is Merging

A very common scenario would be to have

- An AS-IS (and maybe partly TO-BE) model that is actively maintained. Let's call this the main trunk.
- Multiple branches for possible alternative MIGHT-BE models

Things that are currently very hard (practically impossible) to do:
- Update a MIGHT-BE branch to contain the latest changes in the main trunk (in order to not get too much behind in the branch)
- When a MIGHT-BE scenario has been chosen, merge it back into the main trunk. (or do the update above and call promote this branch to be the main trunk)

I think the LemonTree tool from LieberLieber addresses this problem (and that of three way merges), but I'm not sure if the overhead that comes with a tool like that is acceptable is most scenario's.
I can't imagine people wanting to spend days looking at thousands of differences having to decide to go left (trunk) or right (branch).

If this problem is to be solved there should be a very intelligent merge engine that somehow manages to keep the overhead (and thus the need for human decisions) to a minimum.

I'm not even sure if this is doable, even in theory.


General Board / Re: Excel Import
« on: May 03, 2018, 04:20:17 pm »
You can also generate a document using the document generation templates.

Or you can use a proper database to store your model and have your team members use EA to consult the model.
There is even a free Lite edition that gives read-only access to a model.


There is actually a (somewhat complicated) way to do that for attributes.
- Make sure the attribute is visible on a diagram
- select the attribute on the diagram
- click again on the attribute to make it editable
- click somewhere on the type part
- right click on the type part and select [Goto Definition...]

This might work for operations as well (I haven't tried)

Or you can do like me and use the EA Navigator ;)


Hi Rupert,

Not out of the box, but you can of course test the current user in your script yourself, and refuse to execute if she doesn't meet your requirements.


Bugs and Issues / Re: RefGUIDList tag: field too small
« on: April 27, 2018, 11:33:12 pm »
In those cases I usually try to work with RefGUID alone.
If needed I allow multiple tagged values with the same name (I know that is against the rules)
The main reason is that RefGUIDList tagged values are very awkward to maintain (selecting multiple values with Ctrl key?)


Hi D,

A model in Enterprise Architect is stored in a database, and that can be very useful sometimes. It means you can query it using plain old SQL.

In your case you could use something like

Code: [Select]
select o.ea_guid AS CLASSGUID, o.Object_Type AS CLASSTYPE, o.Name  as ObjectName
from t_object o
where o.Name in (

If you go to model search, go into edit mode and paste this sql code in the SQL Scratch Pad, you should see some results (if 'firstname' or 'secondName' actually exist in the model as elements.)


I don't think this is supported, but to be sure you better contact support.


Now got it, thank you.

However I'm wondering if there is an option to number the activities by their sequence in each diagram?
Right now the numbers appear in sequence of their creation or some other logic I can't follow   ???


Activity 1 -> Activity 2 -> Activity 3
is auto numbered as follows
0020 --> 0058 --> 0079    (while the identifiers in between appear in another diagram).

I don't think this is even theoretically possible.
What if you have
- Activity1 -> Activity2
- Activity1 -> Activity3
- Activity3 -> Activity4
- Activity4 -> Activity1

Which order would they need to be in?

If you mean order them by "location" on the diagram, then what happens if you have two diagrams where the elements appear in different places?

You can of course write your own script that applies the sequence you need.


Pages: 1 2 3 [4] 5 6 ... 540