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 ... 551
General Board / Re: Advice on creating Arcimate reports from diagrams
« on: July 05, 2018, 08:47:33 pm »
Hi cTor,

Document generation in Enterprise Architect is not an easy task.
It is not uncommon to hire a consultant to set-up the templates for you.

I documented the way do document generation on my website:

Another alternative is to use EADocX, a commercial add-in for Enterprise Architect.


Never thought of doing that export yourself with an add-in? I did that for other reference data in the past.


Yes, I though of it many times, but I never found the time for it, and I figured this should be a standard feature of EA.
And I've never been sufficiently annoyed by it to get me to actually start writing an add-in and/or script for it.


I would like an option in the export reference data to select only certain scripts for export.
EA only has an option to export ALL the scripts (including a bunch of temp debug stuff that should never be exported anyway) and that is costing me a lot of time (and thus my customers a lot of money)

Each time I update a script in DEV that needs to be promoted to TEST/PROD
- Export all scripts
- Open the resulting xml file
- Copy paste the script parts I need to a new file (not forgetting the groups if not yet existing on the target model)
- Remove all scripts in the file with only those I copied

That could be so much easier if I could just select the scripts I want to export.

(bonus points if the export feature would automatically detect !INCLUDES and export those as well)


- import MDG
- export all scripts (backup)
- delete the model scripts
- link your template to the MDG script(s)
- re-import your model scripts
- regenerate MDG


Next to my code on Github I also wrote a few articles that might help you:

The thing is that "not too complicated" examples don't really exist in the wild.
Everything starts simple, but then you start refactoring out duplicate code, building a framework of reusable wrappers, and before you know it you have a codebase of 100.00 lines of sometimes quite complicated code  :-\


Could also be exactly what it says, an SQL syntax error.

In those cases you can usually find the exact query executed in %appdata%Sparx Systems\EA\DBError.txt

Make sure that your DDL is correct and working before trying to execute it through EA.


A) How can the code you mentioned work if you don't use double quotes around your SQL string?
B) Don't add tables, or change anything to the standard EA database schema. That is a notoriously bad idea and will come back to bite you later on.


I think the workaround before the fix was to:

- generate the MDG technology containing the script
- import this MDG technology into your development model (your model now has two version of the script, one from the MDG and one from the model)
- open the template fragment properties and select the MDG script instead of the model script
- remove the MDG from your development model (your fragment should now no longer work in your development model as it is linked to a script that no longer exists)
- generate the MDG containing both the script as the template fragment
- Test your MDG in a new model


PS. I personally haven't tested whether or not this issue has been solved in v13 or later.

As a result, you get an insidious bug in your code. It works fine until some other profile including a stereotype with that name loads before yours.

Please... Always fully qualify your stereotypes.
Phew. Even worse :-( How about EA insisting on a FQN when checking the parameters?

And breaking a bunch of existing working code?
I hope not.


General Board / Re: Composition in profiles packages
« on: June 30, 2018, 09:57:47 pm »
You should create your own composition stereotype, extending the metaclass Association.


General Board / Re: Classic menu bar / Standard Menu Bar
« on: June 29, 2018, 03:28:00 pm »

But honestly, yes. The ribbons are the worst of all.

I do not agree. I think the ribbons are an improvement of the classic menu structure, especially for new users.

Downside is of course that we "oldies" have to re-learn the location of all actions/buttons.

It is just too bad they couldn't get it right the first time and decided to mix everything up again between v13 and v14


While you are at it, you can maybe try to implement the same for other types of objects in the EA world, think connectors, attributes, operations,...


The relationships you see in the ArchiMate technology are (mostly) the ones that are defined in the metamodel diagrams in the specification. Using this method allows you to define both quicklinkers and model validation using exactly the same information.

So the Archimate MDG has been built using metamodel constraints, which drive the quicklinks ?
What about the 'model validation' mentioned above?  Is there a way I can validate a package for compliance to the MDG (ie Archimate) as opposed to base UML validation (using 'Validate Current Package')?

I started a post on this a few days ago if you'd rather use that to respond:

I think Simon is talking about the strict connector syntax option here.


General Board / Re: Classic menu bar / Standard Menu Bar
« on: June 28, 2018, 11:31:17 pm »
Please Please reconsider this change.
Pretty sure that won't ever happen.

But if you are re-learning EA anyway then you better go directly to v14 as they once again re-shuffled everything :-\


General Board / Re: Delete / Remove a List Override
« on: June 28, 2018, 09:13:08 pm »
In the latest version I've noticed an option to Remove unused lists under the button Manage.


PS. I don't think this info is stored in a structured way in the database, but rather somewhere in the style sheet used (RTF)

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