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 ... 73
Uml Process / Re: [sysML1.4] How to type a connector with EA
« on: January 17, 2018, 12:03:24 am »
Look like regular ol' ports to me.

Not sure if they're available in the SysML diagram toolboxes, but you can add them as child elements on classes.


There is something called Scheduled Tasks in the cloud server. This appears to be exactly what's needed: a way to do EA things in a server context.

However, this is "currently" limited to updating a time series chart and has been since it was first introduced, so it's demo-level functionality. Maybe if enough users push for it, this could be extended to run an HTML report and other useful things (see more suggestions here).

Unfortunately, I think it's unlikely we'll see any movement on this. The scheduled tasks functionality seems destined to remain a (nother) demo hack that no one uses, and Sparx likely see this problem as a way to push users onto the $3000-$8000 per year cloud server. And that can't do server-side automation either -- it only gives you an HTML view, which is not the same as a generated HTML report.


General Board / Re: Hyperlink as an element in Project Browser
« on: January 11, 2018, 09:27:54 pm »
If you're prepared to spend a bit of time on it, what you can do is create an element stereotype which has a tagged value "URL", and a custom icon and shape script to make it look like a hyperlink in project browser and diagrams. Add to that an Add-In which ensures that the URL is set when the element is created, and that the URL is opened when the element is double-clicked.

This does what you want it to: create a proper element that shows up in the project browser and can be placed in any number of diagrams, and which behaves like a hyperlink.

It's a fair bit of work, so whether it's worth it in your case only you can decide. But it's doable.


General Board / Re: Running script from an specific Element
« on: January 11, 2018, 09:17:41 pm »
Hej Steen! :)

(Back on T guys. Boring, I know.)

I've answered this question a couple times before; here on this forum and here on Stack Overflow.

TL;DR: scripts can be stored in the project, in each user's installation (don't -- maintenance nightmare), or in MDG Technologies, which is the fancy name for EA's extension facility. For any type of non-hobbyist installation, this is the way to go.

When it comes to having scripts respond specifically to one type of element, yes, you can do that. Such scripts aren't stored in the element itself, but in special script groups called Diagram Scripts or Project Browser Scripts, depending on where you want to invoke them from. (What Nabil is talking about is an adaptation they've done locally, not part of EA's built-in functionality.) Scripts in these groups are automatically made available to users in the context menu (right-click -- Scripts).

The thing with these diagram / project browser scripts is that they cannot be distributed in an MDG Technology: they have to be stored in each project where they're needed. This is a known limitation.

However, a diagram/browser script can call a script that's located in an MDG Technology. So what I always do in these situations is write a very basic diagram/browser script which just checks what type of element (or connector) it's being invoked for, and then pass control to the "real" script which is in an MDG Technology. A typical use case for this setup is when doing generation of complex documents. (Geert prefers a different approach here, I know.)

In your case, what you want is a diagram script which calculates the tagged value based on the diagram it's invoked from and stores the result in the selected element. I'd put all the calculation stuff in an MDG Technology and have the diagram script just check the basics, like that the element is an artifact and that the diagram is the proper type. Of course, if you're just testing stuff you don't need to bother with an MDG Technology, but if you're working on something that needs to be maintainable and/or have some level of protection from accidental changes there's no other option.

But you also said "started when needed." If by this you mean "run manually when the user decides to", what I've outlined above works. If on the other hand you mean "run automatically when something happens" you need an Add-In, which is a piece of software you must write and distribute to all clients. An Add-In can react to events (like elements being created, deleted, or added to a diagram), which scripts can't.

If all of this is a little overwhelming, feel free to PM me. I'm an EA consultant located in Stockholm, and I have extensive experience of large-scale EA deployments.



General Board / Re: Compact Repository model
« on: January 11, 2018, 08:32:29 pm »
Hello Rupert,

As others have pointed out, there are some EA features which cause database bloat when used without due consideration for maintenance. To this I would like to add one which doesn't cause bloat but which can cause drastically reduced performance: model views.

A model view is like an alternative project browser which displays only a subset of what's in the project based on some query. It is possible to create auto-refreshing views and set them to refresh up to once a second, which (depending on the nature of the query) can cause the client to grind to a halt.

If you have a situation where some users experience a substantially slower client than others, this is worth a look. I've had to clobber these things in the past, from users who swear blind they haven't ever been into that menu (meaning they fiddled with it, forgot all about it, and are now too embarrassed to own up).



  • Open the scripting window. (Depends on the version you're using, in 11 it's in the Tools menu.
  • Top left icon, New Normal Group. Call it Tmp or whatever.
  • Second icon, New VBScript. Call it Fix Directions or something.
  • Cut & paste.
Code: [Select]
option explicit

Hit the fourth icon ( S ->) to run it.

That's it.

This is a quick and dirty hack. Do not use it in a production environment. Do not run it on blind faith. Do not pass Go. Do not inkassera kr 4000.


General Board / Re: Import .uml files from StarUML2?
« on: December 19, 2017, 11:32:44 pm »
Hi Marcus,

It's the old Diagram Interchange problem again. Basic XMI does not include a standardized format for diagrams, but it is extensible. Meaning that all tool vendors are free to add diagram data to their extended version of XMI, which their own tool can then read but no one else's can. In short, using plain XMI diagrams cannot be migrated between tools.

This shortcoming of XMI was addressed years ago in the supplemental Diagram Interchange standard, which EA supports. But that will only help you if StarUML does too.

Failing that, you're looking at a custom translation tool. I'm not aware of one, but perhaps someone else is.



Well no worries. The context for a script in EA includes a global variable Repository, so you can just create a script and call Repository.Execute() with a SQL statement and it'll do it. That method is undocumented, which is for a reason: it will bypass a lot of the stuff EA normally does to make sure the database stays consistent. In other words, it is quite possible to break a project beyond repair.

Note that while the snippet I posted should work (haven't tested it), it will change the direction of every single connector in the project. You did say "all". :) So either you'll have to narrow that statement down, or run the script in a temp project that only contains the stuff you want to modify.

I'm guessing that even in a temp project not all your connectors will be associations, so perhaps this would be more appropriate:
Code: [Select]
update t_connector set Direction = 'Unspecified' where Connector_Type = 'Association' and Direction = 'Bi-Directional'

Hej Anders,

If you know what you're doing you can always call the undocumented Repository.Execute() in a script, passing it something like
Code: [Select]
update t_connector set Direction = 'Unspecified' where Direction = 'Bi-Directional'

Bugs and Issues / Re: Compartments and instances
« on: December 15, 2017, 10:51:48 pm »
Hej Mats,

The only solution I can see is to create an Add-In and call that in your shape script.

The problem, as you've identified, is that the classifier and instances are different elements, and while there is a unique classifier for each instance, the reverse is not true. So a shape script can find the classifier of an element, but not its instanceS.

What would be useful to resolve this is to extend the custom compartment feature of the shape script, so that in addition to ChildElement and RelatedElement, you could add a sub-script for InstanceElement -- worth a feature request, I think.

But as it is, you can't retrieve the instances without going through an Add-In.


Suggestions and Requests / Watermarks. Discuss.
« on: December 12, 2017, 09:14:52 pm »
Hi all,

This is a discussion post regarding watermarks.

There are two instances of watermarks in EA: document and diagram watermarks. A document watermark consists of an image which can be specified in the document generation dialog and which is then superimposed on each page of the generated document, while a diagram watermark consists of a single line of text which is superimposed on copied, printed and generated diagrams. The text is repeated diagonally lower-left-to-upper-right with a fixed typeface, size and line separation.

I'm OK with how the document watermarks work, except they're not in the API. So I think there needs to be an addition to the DocumentGenerator() class which allows you to set an image file for the document watermark.

Diagram watermarks are a different story.

First off, there's a bug which causes the watermark to appear in front of the diagram label (eg "class My Class Diagram"). The watermark should be behind everything else, including frames and labels.

More importantly, however, these watermarks are specified per workspace. That is to say, they're stored in the user's registry and not in the project. Meaning a modeller puts the same watermarks on diagrams from every project they access, while at the same time two modellers can print the same diagram at the same time with different watermarks.

This doesn't make sense to me. It would be more natural for a watermark to be dependent on some aspect of the diagram or the model of which it is a part, not on the user account that's exporting the diagram.

I therefore propose that the diagram watermark functionality is reworked as follows:
  • Diagram watermarks to be stored in the project, not in the user's registry. (If necessary, split them into "user (or workspace) watermark" and "project watermark".)
  • [Project] watermark content to be selectable: either the diagram's version; or its parent element's Status, specified tagged value or other property common to all elements; or a fixed string; or an image file (like a document watermark).
  • Watermark layout to be selectable: typeface, size, direction and line separation.



Well the thing is I want to automate it so I can control which, if any, watermark gets put on a document without the user having to remember to a) select a watermark when appropriate, or b) deselect it when not (since EA remembers the selected watermark between generations).

I already have linked documents which I use in calls to DocumentGenerator.InsertLinkedDocument() in my document generation scripts to get headers and footers. My idea was to duplicate these and add "draft" watermarks to the duplicates, and then in the script to select one of them based on the status of the model for which the document is being generated.


Bugs and Issues / Re: Default tag values do not work properly
« on: December 12, 2017, 01:53:41 am »

Have you reported it?


Hi all,

I'd like to stamp "draft" (or whatever) watermarks on certain generated documents. RTF doesn't actually support those, but according to this MSDN article you can achieve the same effect using a \shp.

I tried creating a watermark in a Word document and saving that as RTF (which works, Word can render it correctly when reopening the file), then importing that into a linked document in EA (by creating the linked document, then in the RTF editor selecting File - Import), the idea being that I could use that document in a call to DocumentGenerator.InsertLinkedDocument() to get the watermark to show up on all pages.

The EA RTF editor did not display the watermark, but not to worry, the RTF specification says you're allowed to ignore content you can't handle, but if I export the document, the \shp is gone. I'm not sure the spec says you can do that, but anyway, that means this approach doesn't work.

But is there another way to create a watermark like this?

I can script it, sure. But I was looking for a way to have it incorporated into the template.


you cannot use WITH directly in EA because EA just ignores it for whatever reason.
In principle all but SELECT statements are ignored.

I may be wrong here -- I'm no DBA -- but I think that's because EA basically uses a lowest-common-denominator SQL dialect, and Access doesn't support 'with' clauses.

Either of those contentions may be wrong. :)


Pages: [1] 2 3 ... 73