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 ... 74
Bugs and Issues / Re: User guide API documentation not navigable
« on: January 31, 2018, 10:52:43 pm »
ErrrmrGrrrd. So that's actually a menu. Well I never.  :-[

You repeatedly have to press the "Topics" button (called "dropdown" by Simon but doesn't look like a dropdown) to navigate deeper into the topics tree.
Yes, I came to the same conclusion a few weeks ago.  I keep a copy of the last .chm file around for look-ups on older topics, then once I've got the right page, I try to get to the latest version.

I DO miss a lot of the functionality of the old chm file


Yeah. For a while I actually compiled CHM files from the downloaded HTML myself, but in order for the resulting structure to be navigable I had to do a lot of manual fiddling and in the end, given the pace of releases, it's just not worth the effort.

Anyway, thanks guys. Learned something. :)


Bugs and Issues / User guide API documentation not navigable
« on: January 31, 2018, 03:17:17 am »
Hi all,

The API documentation in the user guide cannot be navigated to find what you need.

Starting from the first page, I can navigate to Automation, then to Object Model, then to Reference, which has links to pages for the different packages.
Then what? Well, let's see.

Repository Package => "Learn more" => Repository Class. Well, OK -- but what about all the other classes? Fail.
Element Package => Just a class diagram, no links. Fail.
Element Features Package => Just a class diagram, no links. Fail.
Connector Package => Just a class diagram, no links. Fail.
Diagram Package => Just a class diagram, no links. Fail.
Project Interface Package => Just a class diagram, no links. Fail.
Document Generator Interface Package => "Learn more" => DocumentGenerator Class. Alright. And look, there's the Project class!
Mail Interface Package => "Learn more" => MailInterface Class. OK.

And if I'm looking for the Simulation Package I'm poop out of luck, 'cos that's not even listed on the Reference page. Are there other packages missing? Who knows?

Prev/Next buttons, you say? These packages have got dozens of classes in them. Left-to-right navigation is -- no. Just no.

Look, I understand the desire to move from the installed help file to an on-line web format but you can't just take a tree-structured bunch of help pages, flatten them out and call it good. You've got to make sure the new structure can actually be navigated, and that means every class has to be linked from its parent package's page.

It's time to fix this.


General Board / Re: different sets of Default Types
« on: January 30, 2018, 10:27:42 pm »
Why are the default types used for parameters and returns in operations different from those used with action pins and object-nodes?
It looks like the action pin property dialog ignores the Language property, and do not populate the type dropdown with the set of types for the selected language, which the attribute and operation property dialogs do. The same appears to be true for activity parameters.

I agree that they should.

However, if you create the action as an instance of an activity, the pins' Argument properties are set correctly -- but the Type is unset. I haven't checked, but it's probably the same for other behaviors.


I'll check that event; It's wierd that it's under contextmenu.
It's not context menu -- it's context item.

The context item events tell you when the user has changed the selection in the GUI, double-clicked something or made changes to the currently selected thing (element, diagram, etc).

So they're GUI-related, but nothing to do with any menus.



You're looking for EA_OnNotifyContextItemModified. It's in with the other context item events.

Note, however, that semantically this approach will only ever give you a partial solution. It doesn't cover all cases where something is changed which affects en element (eg inherited attributes).


General Board / Visibility levels: users or groups
« on: January 29, 2018, 09:09:25 pm »

From the user guide: "In additional to their normal permissions, database users are granted access to one or more visibility levels."

In anything but tiny-scale deployments, database (and everything else) access is administered not by user, but by group. In terms of SQL Server, users are created based on group, rather than user, principals.

Will EA's visibility levels work correctly when applied to group-based database users?


Hi all,

Element constraints aren't listed on the shape script Display Element/Connector Properties help page.
Is there a way to access them? Like a call to HasProperty("#CONSTRAINT:xyz#"), something like that?


Automation Interface, Add-Ins and Tools / Re: Control EA via command line
« on: January 23, 2018, 09:42:53 pm »
is it possible to control enterpirse architect via command line and is there any documenation about this topic?
Yes and no, in that order. There's nothing in the official documentation, but with Peter's approach you can do everything the "Object Model" API allows.

What i want to do:
I use a diagram script to generate a rtf-Report. We want to automate this step and have it done by jenkins every night. I think it would work with EA-Automation (like an external c#-code) but it would be nice if it would work with the already existing scripts of EA.
You can't invoke scripts through the API so you'd essentially have to reimplement the document generation script in your PowerShell script. But that shouldn't be too hard, since the in-EA script is using that very same API in the first place (meaning it can't do anything your PowerShell script couldn't).

As far as running at night, however, you'll hit the snag every automator does: EA has to be run in a logged-in user session. This applies to the automation API as well: it's client-side only, there is no server-side automation.

So you can schedule your script to run whenever you want, but you need to leave a logged-in computer on overnight for it to work. Whether that's something you can get Jenkins to do I don't know.



Bugs and Issues / User security: AD groups
« on: January 23, 2018, 09:00:14 pm »

Looking at the post-12.1 user security, it seems that I can specify a permissions group and link it to an AD group, but I cannot specify that all users belonging to an AD group should have access to the project. Nor can I tell EA to import all users belonging to a specific AD group.

Am I right?


Suggestions and Requests / Re: local user favourites or preferences
« on: January 23, 2018, 08:32:47 pm »
Hello Saeed,

User security is definitely advisable in any situation where more than one person access the same EA project. To enable it, you must use a special key which is available from the "registered users" section of the Sparx web site.

After enabling security, you should also switch to "Require User Lock to Edit" mode. This means that before any changes can be made, the user must "lock" the package. While the package is locked, no one else can lock it but they can still see all contents. There are other modes of user security in EA, but for a beginner this is the one you want.

Note that locks must be released manually; they are not released automatically when closing the session. The project administrator can release other people's locks, but the GUI for that is pretty bad which makes it a needlessly complicated process.

When you enable security, you get one "admin" account with full privileges. You must then create or import accounts for other users. You can create them with local passwords, or import them from the Windows Active Directory.

Users belong to groups, which control the permissions available to them. These groups can also be synched to AD groups.

Note finally that the unit of access control in EA is the project. It is not possible to restrict access to certain packages: users' permissions apply to everything within a project.



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).



Pages: 1 [2] 3 4 ... 74