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 ... 104
I've been doing some work automating some of the stuff I do with UML profiles and MDG's
Oh snap! You too? :)
The documentation does mention something that it is related to pre-version 7 technologies, so maybe this is some very old forgotten relic from ye olde days?
Pretty sure it is.
Anyways, I'm still looking for a way to import an MDG file into a model with a script. Anyone happen to know if that is possible (and if so, how)?

Well I haven't tried it, but an imported technology is placed in t_document with:
  • DocName = Technology ID
  • DocID = Don't know. A GUID which isn't in the technology .mts or .xml file.
  • ElementID = "TECHNOLOGY"
  • ElementType = "TECHNOLOGY"
  • DocType = "TECHNOLOGY"
... plus presumably the actual data in BinContent, but I haven't checked. All other columns show up as empty in EA's query results.

t_document is generally safe to insert into, isn't it? I mean, you don't have to perform any t_xref black magic right?

In which case a simple Repository.Execute() ought to do it.


General Board / Re: EA freezes when trying to open class properties
« on: May 28, 2020, 08:40:53 pm »
Hi Stefan,

I'm aware of one issue that sounds similar in 15.0.

If an element's name ends with a non-breaking space, EA can't render it in a diagram and will freeze when you try.

The freeze will occur if:
  • You create an element in a diagram and give it such a name;
  • You create an element in the browser with such a name, then add it to a diagram;
  • You open a diagram which contains an element with such a name.
    This can happen if a diagram contains a "normal" element, you edit the name in the browser, then open the diagram.
    Note that in the first two cases, the element is actually added to the diagram, so after you've restarted EA opening that diagram will cause it to freeze again.
Non-breaking spaces can sneak into element names if you copy text from other tools, especially web browsers. EA accepts them in element names (and shows them as regular whitespaces), but if they're at the end of the name, the diagram renderer hangs. (It's fine if they're in the start or middle of the name.)

I sent a bug report, but they wanted screenshots. Of whitespaces in dialog text fields and a hung EA. Go figure.



Bugs and Issues / Connector meanings in RTF templates
« on: May 28, 2020, 05:57:20 pm »

The no-longer-that-recent additions of the special metaclass attributes _MeaningForwards and _MeaningBackwards -- how do you get them into an RTF template?
I've looked through all the fields in the entire connector section subtree, but there's no Meaning, MeaningForwards or MeaningBackwards.
I'm on 15.0.


Hey all,

If you hit F1 in the script editor, EA opens the Script Editor manual page.

Wouldn't it be really useful if in the case that the cursor is on a token that exists in the EA API (eg EA.Element) it would instead open up the relevant API documentation page (in this case, the Element class page)?

I think it would.


Well, I haven't sent a bug report or anything. But since the dialog is a bit all over the place I guess the question is: how should it work?

Is it better to show something like what's in the diagram (type/status)?
Is it better to show the description (aka Note field)? Which is often empty?
If the dialog does get an overhaul, should it perhaps work in a different way?
Maybe a tree view or tree view table with the element at its root and then nodes for Attributes, Operations, Tests, etc?


Bugs and Issues / Multiple same-name tagged values in profile
« on: May 27, 2020, 05:21:46 pm »
Hi all,

One annoyance with EA's metamodelling facilities is that there is (or was, that's the question) no way to get multiple same-named tagged values to work properly.

There are a couple of different ways of specifying that a stereotype should auto-create certain tagged values. In an element of that stereotype, the tagged values associated with the stereotype are shown in their own tab in the element's property dialog. The tab is named after the profile in which the stereotype is defined.

The problem arises when I need to create multiple instances of the same tagged value in an element. The profile model doesn't care about multiplicity on tagged value attributes or connectors (except that a connector that points to another stereotype will result in either a RefGUID or a RefGUIDList tagged value depending on the connector end's multiplicity). I can make my tagged value type available for manual addition, but adding the tagged value manually means EA does not show it in the same tab in the element's property dialog.

The question is: with the recent changes to the metamodelling facilities, is there now a way to allow multiple same-named tagged values added manually to be displayed in the profile-named tab in the property dialog?



Hi all,

Just had a quick look through what the Link to Element Feature dialog actually displays. It doesn't make a lot of sense.

There's a dropdown labelled "Feature Type" which allows you to select one of Attribute, Operation, Change, Defect, Issue, Task or Test (also None).
Then there's a table labelled "Feature" with two columns headed Feature and Description. This table is auto-populated with the available features of the selected type, so you can select one of them for the connector to be linked to (after you OK out of the dialog).

The Feature column of the Feature table shows the names of the respective features, but the Description doesn't show their descriptions. Instead, here's what is shown for each feature category.
Attribute    Attribute type
Operation    Operation return type
Change       "Change"
Defect       "Defect"
Issue        "Issue"
Task         "Task"
Test         Test class (eg "Unit"), except for Inspection tests where the name of the test is shown in both columns.

Change, Defect, Issue and Task are all types of maintenance item. No explanation why the other two, Feature (yes, again) and Document, didn't make the cut but that aside, the column obviously shows this property.

So clearly the Description column actually contains a type. Either it should be labelled as such, or (more helpful) it should show the corresponding attribute/operation/test/maintenance item description. They all have them. Furthermore, in the case of the maintenance items what's shown is completely redundant since the type of maintenance item is shown in the Feature Type dropdown just above.

But wait! There's more!

If you compare what's shown in the feature selection dialog with how the corresponding data is presented in a diagram, it makes more sense. Or even less.

Attributes and operations are shown with their types (by default). Maintenance items and tests, however, are shown with their status (default New and Not Run, respectively). If the logic is to show in the selection dialog what you can see in the diagram, then it should be type for attributes and operations, and status for maintenance items and tests. In this case, the column header should then be updated when the Feature Type selection is changed (which updates the table content).

So. Either the Description column should show descriptions, or the column should be changed to show the type or status, as appropriate, and the header should update to reflect this.


Also, if you link a connector to a test or maintenance item A you can't then change the link to point to another test or maintenance item B, without first deleting A from the element. So in addition to not working very well, it's broken too.


Yes, the Link to Element Feature thing is a fringe function that isn't fully supported in things like document generation. So if generating documents is a prime concern, you do need to take that into account.

You will need to use template fragments to pull the data out, and the storage format isn't documented. Basically the connector holds references to the features it's connected to (1 or 2) in the StyleEx property / column, where the feature(s) are referenced using their GUIDs.

I'm sure the precise details are in some post somewhere. It's been discussed in this forum several times over the years.



The AddIns key only gets created by Add-In installers, not by the EA installer. If it's there, EA scans it during startup; if not it doesn't.
But that only tells EA there are Add-Ins to look for. You must also register the Add-In DLL correctly so EA can actually load it.


Hi Marcin,

You could import the DB schemas and add a bunch of connectors between the columns using Link to Element Feature.
I wouldn't trust a DB model modified in this way to generate the schema back out again, but you could use it to show the client or to generate documents.



General Board / Re: Practical way to do reviews
« on: May 26, 2020, 06:32:22 pm »
Hi Geert,

I don't have a good answer for you, but I'd like to hear myself talk for a while offer some suggestions.

My background is in defence contracting, which is a high-QA environment to the point where it's more important to get it right, and to prove that it's been done right, than to streamline the QA processes. So that's where I'm coming from.

It's good practice to separate syntax checking, which a machine can do, from content checking, which requires understanding. Reviewing should focus primarily (exclusively, really) on the latter. If you're working with documents, an author is expected to spell-check, format and structure their document correctly before sending it out for review; asking a team of subject matter experts to check a document for spelling errors is just a waste of skills, time and money.

So a model validator should be seen as a tool used by the modeller, not by the reviewer. Once the validator OK's a model, it can be sent out for review. Now in your case you're doing both the syntax checking and the content checking, but it's still a good idea to keep them separate in your mind.

When it comes to storing and sharing review remarks, a cardinal rule is that the CI (configuration item under review) must not be altered in any way by the review. This means that any way of working which involves creating elements in the reviewed model -- adding notes to CI diagrams, setting properties in CI elements, adding connectors to CI elements -- is out. The review suggests changes, but only the author makes changes. This might be less of an issue when there is only one reviewer, but as soon as there are more than one it becomes impossible to keep track of what each reviewer actually saw, if you allow the review process to make changes to the CI.

(There is an alternative way of working with reviews which involves making changes in a local copy of the CI, and submitting diffs as a result of the review. Possibly something like this could be achieved in EA using baselines and a multi-project setup, but unless each CI model is completely self-contained it gets pretty complicated pretty quickly.)

The doctrine of no CI change means EA's maintenance items are out. They're not much use anyway, it's far too hard to navigate them in anything but a single-package-single-diagram-two-element scenario, aka the real world.

In general, I feel EA's functionality in this area (indeed, the whole collaboration area) is a bunch of half-baked ideas, nothing coherent that can actually be used. I haven't dived deep into the team library, but I note that the manual says it "can be used to conduct model reviews from any number of perspectives, including walk-throughs, formal model reviews, or ad-hoc reviews" -- but there's no laid-down process for how to do any of those things. Not even an outline. So it comes across as sales-pitch, demo-level stuff.

So it's roll your own, but I think there's a pretty handy way to do it: in-model RTF documents with hyperlinks.

Set up a package structure for reviews, in a separate root node. The substructure obviously depends on how the rest of your project is set up, but at the lowest level you'll want one package for each review of a particular CI. So the package at this level would be called something like "Review of model 'bla bla bla', 2020-05-26".

In this package, each reviewer gets one RTF document (document artifact). You can create a template for these; it's basically just a simple table.

The reviewer adds their remarks to their document, adding hyperlinks to diagrams/elements where appropriate. (If you want you could modify your validator to direct its output to such a document too, of course.) Hyperlinks are light and one-way, so the CI model is not changed by the review. Importantly, the hyperlinks are only there to ease navigation. The actual remark is expressed in free text.

In addition to allowing the reviewer to write free text, they can work on their remarks in the context of their review, not in the context of the CI model, and not tied to some half-baked "discussion" structure. This is important.

Then on top of this there is the question of what to do with the remarks once the review is completed. Some remarks should be implemented, others could be rejected. You could add a column for that to the review template, or you could collate all reviewers' remarks into a separate document where the author (or whoever makes the decisions) can record their decisions.

I really think document artifacts with hyperlinks are the best way to do reviews in EA. None of the built-in functions are going to work without a lot of customization, and while the artifact way will require some customization as well it's very simple to set up, to understand and to work in. The reviewer works from the project browser, but at the same time with a review focus and without making changes to the CI.



Hi Miguel,

Tricky. I don't think there's a way to do exactly what you want.

Background tiles (Preferences -- Diagrams -- Gradients and Background) are not included when you copy-paste into a different tool, but they are included when you generate documents. And anyway it's only one fixed image and I'm not sure if EA will accept one with a transparent colour.

Diagram watermarks (Preferences -- Diagram -- Appearance) are text-only and repeated over the entire page. I wrote a suggestion about those a few years ago but it never went anywhere.

Document watermarks (document generation dialog -- Generate) can be used to add a static watermark... to generated documents only.

So no, I'm pretty sure the answer is no.

You could achieve a limited version of this function with an Add-In which automatically adds *and moves* a header and/or footer every time a diagram is opened. It's the moving that's the tricky part: EA doesn't have a concept of a floating label which is always at the top or bottom of a diagram, everything in the diagram is located at an absolute coordinate. But since these auto-added images would be regular diagram objects they would also be included in generated documents.


Automation Interface, Add-Ins and Tools / Re: Stopping a script
« on: May 20, 2020, 08:41:21 pm »
Hi Pete,

You can stop the script by highlighting it in the Scripting window (or opening it in the editor) and hitting the Stop button.
It's not just for debug runs, but it's disabled if the script isn't running.

You can sometimes end up with scripts running that can't be stopped -- EA's job control isn't really up to scratch -- but scripts located in your project or the installation should usually be stoppable.


I tried adding parameters from the corresponding EA Command hyperlink to CustomCommand(). No good.

Probably not doing it right, but then again, it's undocumented so what's right? Anyway, I only spent five minutes on it. Could still be a way.

Welp, not in 1512 on SQL Server. It was definitely that, removing the offending character resolved the issue.


Pages: [1] 2 3 ... 104