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 - adepreter

Pages: [1] 2 3 ... 8
Hello Eve,

Thank you very much for your quick answer.
I tried to use Repository.LoadAddins (see code below) but that does not make the OnInitializeTechnologies to be called.

To summarize:
- If I just open the repository from the Windows UI, it calls OnInitializeTechnologies properly (it has being doing this for years).
- But when a batch program opens the repository then OnInitializeTechnologies is not called, even when Repository.LoadAddins() is called after opening the repository.

What would you suggest?


if (eaRepo.OpenFile(sFullPath))
    return true;

Dear Eve and Ian,

Indeed as indicated on this link provided by Eve, we can load an MDG from an AddIn, and that is what I am doing.

However, the problem is that the OnInitializeTechnologies is not loaded when EA is started in batch mode.

And that prevents us from generating HTML in batch mode, which is a feature I absolutely need (I might not be the only one).

So if the ImportTechnology was working instead, that would be a viable workaround. So the request from Ian should be considered I think.

As a conclusion the ability to load a custom MDG, including in batch mode, is critical.
We should be able to do this
- either OnInitializeTechnologies
- or using ImportTechnology

Any idea, Eve, when we can have a quick fix with one or the other options?


I need to generate HTML using an MDG loaded from my addin. And this needs to run in batch mode.
But OnInitializeTechnologies is not called when running in batch mode.
It works perfectly well when running in normal/user interface mode.

As a workaround I tried to start another instance and call RunHTMLReport() on that other instance (code below)
But RunHTMLReport() returns an error.

Did anybody encounter the same problem... and found a solution :-) ?

Thank you in advance


Process externalEaProcess = Process.Start(repositoryFileInfo.FullName)
object obj = Marshal.GetActiveObject("EA.App");
EA.App app = obj as EA.App;
Repository repo = app.Repository;

If you want to define it in the MDG, isn't simple to create a different diagram type and test the diagram type in the shape script?

Here is a resulting diagram in compact view mode (name of the diagram stereotype).

These diagrams are generated automatically following diagram templates that can also include auto legends.
- All the diagrams are complete
- Saving a lot of time and money
- All the diagrams have a consistent layout

   if (hasproperty("diagram.stereotype", "Compact View"))
   else if (hasproperty("diagram.stereotype", "Undecorated View"))

Dear Sparxters,
After changing diagram types using C# code equivalent to the VB Script below...

I noticed that when I make an EXISTING element composite, the default diagram type defined in the MDG is not applied.
It works only for new elements.

Any idea what is missing in the code below to apply the diagram type changes to existing elements?

option explicit
sub MigrateDiagramsStereotype (oldType, oldStereotype, newType, newStereotype)
   Dim sql

   Repository.EnsureOutputVisible "Script"
   Repository.ClearOutput "Script"

   ' SQL SERVER SYNTAX ONLY - Cannot be translated to Access as Cast expression does not work with Access
   sql = "update t_diagram " &_
        "set Diagram_Type = '" + newType + "'" &_
        ", StyleEx = cast(replace(cast(StyleEx as nvarchar(max)), 'MDGDgm=" + oldStereotype + "', 'MDGDgm=" + newStereotype + "') as ntext) " &_
        "where " &_
        "Diagram_Type = '" + oldType + "' AND " &_
        "StyleEx like '%MDGDgm=" + oldStereotype + "%'"
   Repository.Execute (sql)
end sub

sub main
      MigrateDiagramsStereotype "Logical",   "MyDiagramPage::MyDiagramStereoyype", "Logical", ""MyNewDiagramPage::MyNewDiagramStereoype"
end sub


Did this all start from adequate requirements? And from whom?

It seems (just a guess) to start from an assumption that it is a good idea to start mixing different languages that were not designed to work together, that have different semantics, different metamodels, different terminologies etc....

For people to effectively communicate and collaborate across several disciplines, they should better speak one language, and use one tool and one repository.
Teams can use one language that does everything they need or two that are exactly complementary if they need more.
Complementary OK. But there should not be any redundancy.

Also the term "metamodel view" sounds like a mix of concepts that does no make sense to me.
What my users need is the ability to create views based on a single language metamodel.
And to be able to create views, I, the framework author, need to be able to define Viewpoints, as defined e.g. in ISO 42010:
Hopefully, that is what diagram pages are about.

--- My users' requirements and my derived requirements ----

As a professional focusing on framework, language and tool authoring, these are some of the things my customers need.
Most things I could resolve myself. But there are areas where I would like to go further, and I can't due to EA limitations, as explained below.
And these limitations persist maybe because the EA development team seems to be focusing on requirements of obscure origin leading to these unusable language mixtures.

So here are mys users requirements and my derived framework author requirements:
- Modelling elements and connectors (MDG UML profile)
- Language Metamodel covering the entire language (as in Labnaf)
- Easy-to read yet formal language metamodel expressed using the end user modeling language itself (as in Labnaf)
- Pre-conditional (preventing from) and post-conditional model validation (validate after the fact) (as in Labnaf)
- Dynamic model validation based on the language metamodel that is expressed using the end user language (as in Labnaf)
- Quicklinks generated from the language metamodel (as in Labnaf)
- Viewpoints (MDG Diagram pages)
- Toolboxes (MDG Toolbox pages)
- Filters on the available items on the toolbox (------------ HOW?)
- Filters (that can be set on and off by the end user or he administrator) on the type of connectors an elements that can appear on a specific type of diagram (------------ HOW?)

- Ability to load/import and activate an MDG any time programmatically at runtime, when EA is already running (------------ HOW?)
- Ability to programmatically (re)load quick links in memory for an active MDG (------------ HOW?)
- And finally get rid of this EA bug that removes the "From"part of quick links for each diagram page that does not have the same name as the MDG

Hi Eve,
Thank you for your explanations.

Regarding requirements:
It must be simple.
My users want one single language that merges (not "integrates") standards.
It is one MDG created from scratch.
The quick links and the validation are generated from the metamodel expressed in the single language that everybody knows and shares.
I speak English French and Dutch but I am not trying to communicate using several languages in the same sentence :-)

Regarding the hierarchy of diagram types:
I must be simple.
I implemented the "several diagram types on several diagrams" approach as explained on this page from the Sparx doc.

However there is a bug in Sparx (see ref 19072645 where I also illustrate in a Word doc the structure of diagram types): When you create a diagram on a page that has a name that is different from the name of the MDG, then the "From" part of the quick links is lost.

Do you have any work around to suggest?

Thank you,

Thank you Eve,

Is it possible to create these views without constraints on the possible element connections?
Indeed I think the view is not the right place to express metamodel constraints, except in the case where your view represents code or configuration items.

For Strategy and Enterprise Architecture you need one single metamodel applied to one single language (not one metamodel per view).
In the toolbox you need to show the usual elements and connectors.
But one should not prevent users from adding, sometimes, some additonal elements and connectors that are not usual in that kind of view.

Also it is better to implement the language metamodel using the language itself.
So it can be used both for
- Metamodel documentation
- Dynamic model validation
For example this language metamodel is used both for dynamic model validation and documentation.

In a diagram profile, how can we group/categorize existing diagram types so that they appear in a tree browser a bit like in Archimate 3?

So that, with a perspective properly set, the Add Diagram window shows for example:

- Corporate Objectives
- Domain Goals
- ...
- Organization Landscape
- ...
- Application Landscape
- Application Interactions

Is there a way to automatically replace sql select content stored in list views and charts?

The traceability window is still ignoring MDG icons and this is confusing end users.

One generic way to solve it and to allow extensions at the same time is to provide an addin event that we can use to provide the icon that we need.
The icon could then also reflect the state of any element property or tagged value.

Thank you Paolo

Users are asking for a way to enter tagged values for a set of recurrent of a very long list of tagged values (longer than the window height).
As far as EA 14.1 is concerned, the specification manager is still very cumbersome for data entry.
It is also limited to the content of a package.

Pages: [1] 2 3 ... 8