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

Pages: 1 2 [3] 4 5 ... 85
Suggestions and Requests / Re: Support LDAP within WebEA
« on: June 11, 2018, 09:14:43 pm »
+ 1

LDAP integration is often a minimum requirement for any enterprise-wide tool deployment.


Hi all,

Here's a left-field one.

When working with multiple projects and moving models between them, being able to quickly compare two instances of the same model is useful.

One way of doing this is to start two EA instances, undock the same window in both of them, align the two windows pixel-perfect one on top of the other, and then alt-tab between them looking for anything that "blinks". This is an obvious approach when working with diagrams, but really it works equally well with any type of window (properties, project browser, element browser...).

This type of visual comparison would be simplified by the ability to transparentifize the windows. That's a word. You could then just undock one, make it transparent and move it on top of the other, still-docked window; or you could undock both, make them both transparent, line them up and anything that shows up faint will only be present in one window, ie a difference.


That's not really the question. The question is, shouldn't it be possible to specify MDG Technologies with greater accuracy, taking into account file location and/or version?

The fact that the file location doesn't apply to the "import" deployment option is beside the point. The "referenced file" deployment option is supported, and could be improved in the manner suggested.


Suggestions and Requests / Add location to Required MDG Technologies
« on: June 08, 2018, 09:45:31 pm »
Hi all,

The Required MDG Technologies feature is useful, but it requires that users have the same MDG Technology paths set up. This is no issue for built-in technologies, but for locally developed ones it can be.

Specifically, if I want to trial a newer version of an MDG Technology I deploy it to a different network share than the "release" one. I would like to be able to set up a project to use my "trial" version instead of the "release" one and simply point my trial team to that project, but I can't do that because the MDGRequire and MDGBlklist (in t_genopt) specify the technologies by ID, not by file name.

So if the location could be added, either by using the technology file's path or by adding a t_genopt option for the MDG search path, I could specify the technology and path in my trial project and everyone would have a smoother EA experience.

As an alternative, of course, if the "MDG Technologies" dialog, as well as the required/disabled technologies option, were made version-aware, that would be even better.

By that I mean that the respective dialogs should list every version of each MDG Technology they find and force the user to choose exactly one of each such group. The technologies would be identified by their IDs, and listed with their version IDs.

Yet another alternative would be to store the technology ID + version ID in t_genopt. That would be good enough, although of course it wouldn't resolve the case where two MDG Technology files have the same technology ID and version ID -- but really that's poor version control on the developer's part.


Hi all,

Pro Cloud Server 2.1 introduced a "Server Based Plugin Interface".
Is this available somehow, somewhere, to tool builders?

Or is it just a way for Sparx to deploy its own integration products?


Hello, and welcome to the forum.

Just a note: this is a user forum, not an official channel for communicating with Sparx support or sales. Sparx representatives are active here, but for a specific inquiry it might be better to contact Sparx by e-mail (addresses listed here).

Sparx Systems tend to be reticent about roadmaps and future functionality, but if you can't get a satisfactory answer out of them the tool is eminently extensible, and there are several EA consultants hanging around the forum. Some of us even have extensive experience in the defence industry.  ::)

The EA API is reasonably well documented, and it is backwards-compatible over time: features are added, but rarely or never removed.

There is no specific API for the import/export functions, so you can't create a plugin that adds a particular XMI format to the XMI import/export dialogs, but you can always write your own import/export functions. They can be integrated into the EA GUI, just not into the regular XMI functionality.



Bugs and Issues / Re: MDG Technologies overwrite local scripts
« on: May 31, 2018, 02:48:21 am »
Hi Benno,

Has anyone experienced this?

Not that precisely, and I haven't tried generating an MDG Technology in 14, but I can tell you that

  8. A group "testMDG" appears in the Scripting window. The group is empty (expected behavior: the group should contain the script "mytest")
is an incorrect assumption. Script groups in an MDG Technology project are flattened into a single group with the MDG Technology's name. This is why you can't include project browser or diagram scripts in an MDG Technology.

I think it's your importing of an MDG Technology into the project where you develop it that's tripping you (or EA) up. I always do my testing in a different project, separate from my MDG Technology development project.

If my MDG Technology will include scripts, I create a single group for them which I name after the MDG Technology's ID -- not its name. This is to deal with situations where you have to make references to the MDG Technology from within the development project, such as when specifying a script to be called from a "Script" document template fragment.



General Board / Re: Adding attributes to MDG stereotype element
« on: May 31, 2018, 02:27:40 am »
I should add that the Override Attribute Initializers function allows you to override the initial values of any attributes up the generalization hierarchy, regardless of whether they've already been overridden in any intermediate classes.

So if what you're after is specifying different values of the same-named attributes in different classes, generalization is definitely the way to go.

Of course, if you're looking to create different instances of the same class with different values in the same set of attributes, that's what objects and run states are for.


I don't see why they would really need two separate executables.

Well, there might be good reasons why they are. But if EA fails to obtain a license, it could easily offer to launch EA Lite instead, if it's there.

But this would really only address the situation where you start EA, find that there are no licenses available in the pool and you realize you just want to look at something so EA Lite will do -- while at the same time the models you want to look at are not published as HTML and there's no WebEA set up.

So useful, but probably not the most common of use cases.


General Board / Re: Adding attributes to MDG stereotype element
« on: May 30, 2018, 01:12:20 am »
Precisly, I get tagged values. Now if I want +50 class to also have the same 4 attributes (which values I'll change later), how can I speed up this process? Do I have to drag and drop manually the attributes onto each one of the +50 elements?

Yes, in terms of UML Profiles: you can't specify a set of attributes or operations to be created on all classes of a certain stereotype, only a set of tagged values.

The proper UML way to repeat attributes is to use generalization. You can tell EA to display the inherited attributes in the specialized class by right-clicking the class in a diagram and select Features & Properties -- Feature and Compartment Visibility.

The same submenu has the item Override Attribute Initializers, which you can use to set values for both local and inherited attributes. You can also (ab)use this to show certain inherited attributes selectively by giving them an initial value of a single white space.



General Board / Re: MDG on V12+++
« on: May 25, 2018, 06:42:50 pm »
PS. Why version 12 now ??? The current version is 14.

Weeeellll -- more like the current version is 13.5 and the upcoming one is 14.

Since the official release of 14 (build 1418) they've been rushing out bugfixes at the rate of one a week, so I'd let things quiet down a bit before I'd call it stable.


Why would you write a captions of the form:
    "From" colour is prettier than "To" colour

When you can use the caption:
    "Prettier than

Because I have users, quite a few of them, who understand the long form better.

I fully accept that lines need to be drawn and that's why we discuss suggestions before making actual feature requests, but the "nobody needs that" is boycowpoo. I could name people who do, but I won't because GDPR wooo wooooooooo.

Of course, the recently added _MeaningForwards and _MeaningBackwards connector metaclass attributes could be used to good effect as well.
They already are if you define validation rules and quicklinker menus using metamodel constraints

Looks interesting, but that's in 14 and I wasn't planning on approaching the site until the cleanup crews have gone and the sirens have faded into the distance.

That said, I can't see where in the user guide this functionality is described. There's no "Meaning" on the linked page (and read into that...), and the Special Attributes page just plays coy and breathes "and elsewhere" in a seductive whisper. That's not documentation, that's a teaser trailer.

Anyway, I take it that's a hard "no" on my suggestion.


Can you give examples of how the macros would be used?  Your QuickLinker line and the resultant text on the QuickLinker menu?

Sure. Given a profile with stereotypes <<colour>> (Class) and <<prtrthn>> (Association), a quick linker definition line might read
    Class,colour,Class,colour,,,,Association,prtrthn,to,#SRCNAME# is prettier than #TGTNAME#,,TRUE,,TRUE,TRUE,,0,,,,,0

Used in a model with two <<colour>> Classes 'Coelin Blue' and 'Asda Green', quicklinking a connector from the former to the latter would yield a menu item
    Coelin Blue is prettier than Asda Green

So it saves you having to write captions on the form
    "From" colour is prettier than "To" colour
... which don't exactly roll off the tongue.

What other objects might get placeholders (besides origin/destination element name)?

In terms of element properties, none that I can see, really. Any information relating to the source/target element types is dealt with by adding separate definition lines.
This facility would add the ability to present information from the individual elements between which the connector is being drawn, and I don't see that anything other than the name (and alias if preferred) would be of much use. Possibly version, status, stuff like that, but I don't have a specific use case for those.

Of course, the recently added _MeaningForwards and _MeaningBackwards connector metaclass attributes could be used to good effect as well. If those were defined as "is prettier than" and "is uglier than" in the example above, you could create macro:ed captions like
    Class,colour,Class,colour,,,,Association,prtrthn,to,#SRCNAME# #MEANINGFWD# #TGTNAME#,,TRUE,,TRUE,TRUE,,0,,,,,0
    Class,colour,Class,colour,,,,Association,prtrthn,from,#SRCNAME# #MEANINGBCK# #TGTNAME#,,TRUE,,TRUE,TRUE,,0,,,,,0

giving you a popup menu with two items
    Coelin Blue is prettier than Asda Green
    Coelin Blue is uglier than Asda Green

... resulting in the same <<prtrthn>> Association being drawn, but in different directions.


You're just showing the user the same information that they have already selected. How does this vary between the different options shown by the quicklinker? I can't see it being anything except noise for an end user.

Good point, providing that all users is one user, who is fully conversant in the UML metamodel and the quirks of EA, and that the profile is strictly defined in terms of said metamodel as well as fully documented, communicated to, and understood by that user. So for me, yes, it would just be added noise.

But for users who are not modellers by profession or by choice, this is a small but not insignificant productivity enhancer.


Hi Rich,

The language itself shouldn't really be an issue. The EA API doesn't utilize any modern language features, it's all very basic. You can write Add-Ins in C++ if you like.

I'm not sure which examples you're referring to, but if they're telling you to run regasm manually or set your project up to auto-register the DLL for COM interoperability and you don't know what this does, then the problem is in the deployment space, not the source space or build space.

Are you developing an Add-In solely for use on your development machine, or will it need to be distributed to others?

If the latter, my best advice is to bite the bullet and add an installer project to your solution. I use WiX, which is what Microsoft recommends, and it's pretty easy to set the installer project up to harvest the necessary information from your DLL during build. Meaning you can set it up once and then forget about it.

Even if you're just doing something for yourself which you will never ever want to move to another machine either now or at any time in the future I'd advise you to set it up properly. Might as well do it right.




Please start your own thread for your own issue instead of resurrecting a dead one.

Pages: 1 2 [3] 4 5 ... 85