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



General Board / Re: Hide packages/folders from users (Sparx V14
« on: March 20, 2018, 02:45:51 am »
  • You need the latest version of SQL (i think from 2018 or latest Oracle
SQL Server 2016 and later support row-level security.


Hi all,

EA does not allow structural elements (ports, activity parameters, etc) to be placed in a diagram unless their parent element is in the diagram as well.
This makes sense in most situations, but when the diagram is the composite diagram for the parent element it does not.

I would like to propose, therefore, a relaxation of the parent element restriction to allow structural elements to be placed in a diagram without their parent element if the diagram is the composite diagram of the parent element.

A composite diagram typically depicts the inner structure of a parent element -- a structural breakdown in the case of classes and components, or a behavioral breakdown in the case of activities -- with the structural elements representing parts of that breakdown.
In these cases, the presence of the parent element in the diagram serves no semantic purpose: if the diagram's context is a breakdown of an element, that element is unnecessary. All it does is cause layout problems.
However, if you want to show the structural elements, you have to include the parent. There's no other way to get them in there.

So EA should allow structural elements to be placed freely within the composite diagram of their parent element.

If the user chooses to place the parent element in its own composite diagram, the old rules should apply and the layout of the structural elements should be locked to the parent element.

You can almost see what I'm after by creating a diagram filter which hides the parent element's type, and applying it in a composite diagram. This causes the structural elements to appear to be free-floating, although they are in fact still constrained by the hidden parent element.


Hi Eamonn,

If you're working in-project (as opposed to with a modelled profile), the Uml Types config dialog is in Configure -- Reference Data (on the right).
In there, you can set a shape script for a selected stereotype.

As to the script, you should probably do a decoration instead of adding the letter to the main script.
Code: (shape script) [Select]
shape main {
decoration LetterA {
    orientation = "NE";



Key points for us are:
  • Access rights for each project.

That right there is the clincher. The only way to achieve that is multiple repositories.

It is important to understand that EA's security model is just fluff. It does not actually provide any security.

Actual security is provided by the underlying database, and every user account that accesses an EA project needs read and write privileges in the database -- even accounts without the Update Diagrams and Update Elements permissions.

This means that any user account with access to the database can access all the data in it, both for reading and writing, using raw SQL.

So if you have information security requirements that say that people should only have access to certain EA projects, the only way is to place those projects in different repositories and assign access rights to the user accounts accordingly.
If on the other hand you're not concerned with information security between projects but just want to ensure that team A doesn't make changes to team B's models, you can achieve that with EA's "security". Even with that though, read access applies to the whole project: it's only writing that's restricted.

Until v14's row-level access has been confirmed as viable.  Then maybe you can "hide" those confidential portions of the repository using that.

It isn't, and you can't. The model introduced in v14 is strictly hierarchical, meaning you can't set one part of a project up to be visible to team A only, and another to team B only. If team A should not be able to read team B's area you can achieve that by giving team B higher privileges, but that means they will also be able to ream team A's area.

So that fell over right out of the gate, I'm sorry to say.


Hello Martin,

No that's not something you can do. Tags are statically linked to stereotypes, and stereotypes are themselves a pretty static property of an element: a stereotype describes the (extended) type of element, and is not something you flip back and forth.

However, you can create generalizations between stereotypes in your profile, which you can use to achieve something similar.

In your case, you could create one abstract stereotype DataObject with the metatype attribute, and two specializations SimpleDataObject and ComplexDataObject with the following tags.
    ObjectCode : SimpleObjectCode   {Variable, Array}
    DataType   : SimpleDataType     {...}
    ObjectCode : ComplexObjectCode  {Record}
    DataType   : ComplexDataType    {...}

This should meet the requirements in terms of structure and rules for tags. However, it still won't be dynamic. If you want the tags to change automatically when you change a stereotype, you have to write an Add-In.



Element also has another meaning in UML. Almost anything in UML is an Element (except for diagram, tagged values, and maybe a few other things), but they are not all stored in t_object.
In UML, yes. But EA is less an implementation of the UML metamodel and more of a UMLish tool.
So I prefer the more neutral Item as a term.

You're not wrong, but you do then introduce a new term into the conversation. If your audience is up to speed on UML and EA then well and good, but if they're struggling with the conceptual side of things it can confuse more than it helps.

I guess what I'm saying is "it depends." :)


I prefer diagram-only elements or non-browser elements.

Since object is in fact an element type, I always avoid using that word to describe anything else.
(Leaving aside the fact that elements are referred to as objects in the EA database schema -- t_object, t_objectproperties, .Object_ID, etc. Consistency!)


Hello, and welcome to the forum. Please note that we're all users here.

For general code samples, have a look at the Code Samples page.

The database is famously undocumented, but you can generate a model of it using EA itself.

I haven't tried doing what you're attempting, but I would assume it would involve a number of calls to Project.RunReport() (documentation here). How you'd go about finding "all defined documents" I couldn't say off-hand.

Finally, keep in mind that while you can interact with an EA project through the API, you cannot set your program up to run on a server. It has to run in an interactive session. There are many posts on this in this forum. (Use the search function in the forum menu, the search box in the upper right doesn't work).



Pages: [1] 2 3 ... 76