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 ... 76
Bugs and Issues / Behaviour of action pins
« on: March 22, 2018, 11:06:41 pm »
Hey all,

I'm bumping into some things I don't like with action pins. Am I the only one?

Let's say I create an activity with some parameters, and specify classes for their types.
Let's then say I create a call behavior action from the activity, with an action pin for each parameter.
Each pin thus created is correctly linked to the correct behavior (the activity) and parameter.

However, each pin is of "input" kind -- regardless of the corresponding parameter's direction.

Shouldn't the pin kind follow the parameter direction?

Furthermore, the pins do not have any types set.

Shouldn't they?

Finally, if an activity parameter's type (class) has tagged values, those tagged values are included in the parameter's extended tagged values.
A pin does not -- even after setting the type to match the corresponding parameter's, the pin has no extended tagged values.

Shouldn't tagged values be "extended-inherited" from types to pins, just as from types to parameters?

The first two I can script my way around if necessary. But there's magic behind the extended tagged values, so I'd need that to be fixed in the tool.

Or am I unreasonable -- or plain wrong -- in how I expect action pins to work?


Uml Process / Re: Action pins and instances of artifacts
« on: March 22, 2018, 08:19:25 pm »
It hasn't been fixed in 13.5.1352.



1) Create a package. The name of this package will be shown in the browser tab title when navigating the HTML.
There's no need to create a master document, just a regular package.

2) Create a documentation diagram and a model document. The name of this element is not used anywhere. "HTML Generator" is a good name.

3) Leave the model document's tagged values empty or default. They are not used for HTML generation.

4) Drag-and-drop each package you want to include onto the model document.
You can't drag root nodes onto the model document, but you can drag view-level packages from multiple root nodes.

5) If you wish, you can edit the names and top-down order of the resultant attributes.
The attribute names control what package names are displayed in the HTML tree view. The actual links to the packages will not be lost, and (in EA) you can right-click each attribute and find the package in project browser.

That's the setup.
To generate, select the model document and hit Shift-F8. In this dialog is where you select the style (= HTML template set).

You might be able to save a generation configuration (ie, the settings in the HTML generation dialog) as a resource document. I don't know, I haven't tried that for this type of setup.



General Board / Re: Problem with hyperlinks to EA models
« on: March 21, 2018, 10:45:12 pm »
That was it, yeah. I had the same basic solution: create a new URI scheme (I think I called mine eamodel), and implement a protocol handler which opens the specified EA resource.

Pretty straightforward piece of kit really. Had some limitations, of course, but basically did what you need.


Also, I make it a policy to rather use a supplier's bad terms than make up my own good ones -- at least that way, explaining them isn't my problem.  ::)
That's OK when there's only one supplier.  In my "day job" there are several in many instances and they all tend to disagree. So, my experience is that it is better to use the correct term - with, of course, supplying the mapping.
Absolutely. When maintaining the mapping is an option, that is the better way to go. I was speaking more specifically about this forum.
Contexts for, uh, hontexts, I guess.

Also, since I also have to create structured language and have now a reasonable idea of "how language needs to work" in order to communicate unambiguously, I get protective of terms.
That's OK. It just means you're an architect. A much maligned profession, without which nothing has a hope in hell of being delivered to spec or on time.

"Composite Structure Diagram" makes sense, "Composite Diagram" actually doesn't.  The former means a diagram that is the composite structure (of something), the latter means a diagram of composites?
Yeah... "Linked Diagram" would be better, but we won't see that change I fear.


General Board / Re: Problem with hyperlinks to EA models
« on: March 21, 2018, 08:20:00 pm »
Have a look at the Save as Shortcut command. That allows you to choose diagrams to open on launching the shortcut.
Ok, that works, but it's not ideal.
If you want true hyperlinks that point to specific diagrams in an EA project, which can be used from within another EA project or in a web page or wherever, that's not what EA's hyperlinks and shortcut files offer.

It can be implemented, however. I did this a few years back, but I never brought it to market. I dropped it after I saw there was an open source effort to achieve the same thing. Pretty sure that's been abandoned in turn now, though.


Bugs and Issues / Re: DB2 import: FK constraint connector target role
« on: March 21, 2018, 08:12:54 pm »
We've seen those problems and a few others.
I reported them as bugs back then, and we devised a workaround based upon parsing the DDL and adding/correcting the missing/wrong info.

Any response on those bug reports?
Are you in a position to check if they've been addressed in the 14 beta?

And have you got anything written down as to the symptoms, causes, effects and/or workarounds?
Specifically, did you see EA crashing at the end of every DB2 import like we do?
Not that I'm asking you to do my work for me or anything....  ;D

This functionality is part of the EA Database Transformer add-in and was specifically made for DB2.
The add-in is open source, so if some parts do not work exactly how you need then you can change the code yourself (or ask me to change it for you)

I'll keep that in my back pocket, although the primary option must be to get the functionality we've paid for out of the tool where it's supposed to have been implemented already.

The usage section on the page is a little scant -- am I correct in that the intended way of working is to
  • Import the schema into EA using EA's built-in functionality,
  • Export the DDL from the DBMS separately,
  • Use the Add-In to patch ("complete") the model with the contents of the exported DDL.



Bugs and Issues / DB2 import: FK constraint connector target role
« on: March 21, 2018, 03:02:41 am »
Hi all,

Using 13.5.1352 on Windows 7x64, importing from a z/OS DB2 12 database through IBM DB2 Connect.

After import, some but not all foreign key constraint connectors are out of whack. The Involved Columns list is empty (as is the Join on Constraint field), and the target role is set to some random string of garbage.

The same garbage string gets reused in several broken connectors, but from one import there may be more than one such garbage string.
The behaviour is not consistent; the garbage strings and which connectors get them vary from import to import (of the same database).

Has anyone else seen this? If so, what's going on?

I can go through and set the Join on Constraint property manually. The dropdown is properly populated.
But does anyone know if this indicates that something else is broken in the model?

Secondly, EA crashes after import. Far as I can tell, this is an unrelated error.
The crash occurs even if I tell EA not to import any constraints or foreign keys at all, and it occurs whether or not I tell it to draw diagrams.

The Windows log shows a fault somewhere in or near ntdll.dll.

Anyone else see this?



Right, with you.

While it is overwhelmingly likely that the term "composite diagram" indeed derives from "composite structure diagram", they're not the same thing in EA's terminology. "Composite structure diagram" is a diagram type, while a "composite diagram" is, shall we say, a diagram role -- it indicates a special relationship between an element and a diagram.

In MDG Technology design, you specify in an element stereotype definition whether creation of elements with that stereotype should also cause the creation of such special diagrams, and if so, what type of diagram should be created. These properties are called _makeComposite and _defaultDiagramType, respectively.

So the term "composite" is in there, and does not refer specifically to the "composite structure" diagram type. In addition, the GUI allows you to select any type of diagram as the "composite diagram" for an element. Even the default composite diagram type for an element type is not necessarily the composite structure diagram. Activities, for instance, get an activity diagram.

I agree that "attached", or better still "linked", diagram would be a better term for these, especially since as you point out a link is clearly what the icon indicates. So an element may have any number of "child" diagrams, and may have one "linked" diagram, which by default is a child diagram, but does not actually have to be(!).
Buuuut, since the term "composite" is used in MDG Technology definitions, it can't be changed.

Also, I make it a policy to rather use a supplier's bad terms than make up my own good ones -- at least that way, explaining them isn't my problem.  ::)


General Board / Re: Problem with hyperlinks to EA models
« on: March 20, 2018, 08:38:34 pm »
This makes no sense to me (and note the target model IS editable once it has been opened, irrespective of the fact that it was accessed via an "open" link), but what the heck, it works.
"Edit" actions (not type) are valid for "file" type links and not much else AFAIK.

EA first checks if the file extension is something it thinks it can make sense of, like .txt or .xml. If so, it opens the file in one of its internal editors.

If the extension is not recognized, I believe the two actions fall through to Windows. In Windows, you can register "open" and "edit" applications per file type. These two do not have to be the same. .xml files are often a good test case; right-click an .xml file in the Windows Explorer and try the Open and Edit menu items -- quite often they will lead to different applications being started (but of course this depends on your Windows configuration).

When EA installs, it registers itself as the "open" application for .eap files -- but not as the "edit" application. (You can verify this by right-clicking an .eap file in the Explorer; there will be an Open but no Edit menu item.)

So if you create a "file" hyperlink in EA and specify the "open" action for an .eap file, when you ask EA to follow the link it tells Windows to "open" the file, which causes another EA instance to be started.
If on the other hand you specify the "edit" action, when EA is asked to follow the link it tells Windows to "edit" the .eap file -- and Windows doesn't know how to do that, so nothing happens.

It would be reasonable to expect EA to say something in this case, such as "no 'edit' action is defined for this file extension". You should file a feature request, or possibly even a bug report.


Interesting proposal, Uffe.

However, notwithstanding EA's UI, the ONLY thing EA knows about the attached diagram is that it is attached to the Parent object.  We use that fact to hijack the linkage for our Neighborhood diagrams.  Consequently, how can you tell it's a composite structure diagram?  In my MDG, the usual markers may not apply...


PS: Our Neighborhood diagrams bump into the same problem.  But that's because we haven't written the code to place the parent object on the diagram.  Like Sparx bug fixes, it will come sometime before the end of the universe...   ;)

I'm not sure I quite understand the objection. Looking at a diagram in and of itself, you can't tell whether it is the composite diagram for an element. But you can tell whether an element has a composite diagram, and if so, which one it is. (NType=8, PDATA1=Diagram ID). This works even if someone has been evil and moved the diagram out of its parent element in the project browser (meaning the diagram's ParentID no longer contains the ID of the element for which it is the composite diagram).

So you can ascertain whether a diagram is a composite diagram, and if so, which element it is the composite diagram of. That's all you need.
Now it is possible to abuse EA and make one diagram be the composite diagram of two elements. But that's not a problem for this proposal: as long as you can establish that a diagram is a composite diagram, you can relax the parent-element-must-be-present restrictions for the structural elements of any of the elements for which the diagram is the composite diagram.
For the proposal to work, you only need to establish whether the diagram is the composite diagram of an element which has structural elements.

EA already does this kind of check when determining whether to draw the composite icon on an element, and it does it correctly even when abused as outlined.


Bugs and Issues / Re: Python reverse - empty result
« on: March 20, 2018, 03:23:04 am »
Are there classes in your code?

If you're writing classless Python I don't think you'll get anything out of an EA reverse-engineer.


General Board / Re: License Server questions
« on: March 20, 2018, 03:20:38 am »
Hello Marcel,

Geert is correct: from the technical perspective, there are no issues. (I am not a Sparx employee and will offer no advice on licensing terms and legal implications.)

Two Sparx license servers on the same network do not appear to communicate, so there's no check to prevent you from installing the same license in two keystores.
So for what you want to do, you can (again, from the technical perspective) install a license server on the third machine, install your licenses in that, and then remove them from the old keystore once you've configured all EA clients to use the new keystore and checked that they can acquire licenses.
To move to a different host, just repeat the same process.



General Board / Re: HTML report for several root nodes?
« on: March 20, 2018, 03:09:32 am »

This is one of the more bizarre limitations in EA.
The way around it is to create a master document for your HTML export. You can't drop root nodes as packages onto a model document, but you can drop view-level packages.

This of course means the root nodes are not included in the generated HTML, which means you lose one level in the model tree. But you can modify the names of the model document attributes without losing the links to the actual packages, which means you can impose a naming scheme like
root1 -- view1
root1 -- view2
root2 -- view1
root3 -- view1
root3 -- view2

It's not perfect, but at least you can include all the model content in one HTML generation, and see what root node each view-level package belongs to in the (flattened) result.



General Board / Re: Problem with hyperlinks to EA models
« on: March 20, 2018, 02:57:08 am »
Hi Colin,

Firstly, the link must be resolvable for every user. Don't use any kind of relative or drive-letter-based path; UNC is the only thing that works.
Secondly, the program resolving the link (EA in this case) must know what to do with .EAP files. Make sure they're properly registered to be opened with EA.
Thirdly, the user account running the program must have read access to the file. Check that.



Pages: [1] 2 3 ... 76