Messages

46

General Board / Re: Executable States machine - files generation

« on: December 06, 2020, 08:15:08 pm »

Hi Yann,

I'm not 100% on this but I would say probably not.
While you can modify regular code generation templates, the ones for an executable state machine are not accessible for modification and there are no options that relate to the code structure.

/Uffe

47

Uml Process / Re: convert business use case & business actor

« on: December 06, 2020, 07:55:00 pm »

Hello,


It is not possible to make business use cases / actors appear like regular use cases / actors. These shapes are determined by standards: a business use case has that line across it and that's that.

If you have specific requirements in your organization, you can add your own stereotypes, diagram types, etc. Enforcing them is difficult, however: a knowledgeable user will always be able to create a default business use case.
This is because the UML languages are extensible, but not reducible: you can add your own symbols, but you can't remove the ones defined in the standard. And indeed, EA does not allow you to do that. You can hide them to a certain extent, but you can't eliminate them entirely.

In this type of situation, I usually recommend spending the effort on training the modellers rather than trying to make the tool do something it fundamentally can't do.

HTH,


/Uffe

48

Automation Interface, Add-Ins and Tools / Re: Partly hidden stereotyped connector with shapescript to change the color

« on: November 24, 2020, 07:50:12 pm »

Well, it seems the editor doesn't recognize whether the script is for an element or a connector.

It could be both. I've had stereotypes that extend both Class and Association; it makes writing the shape main a bit fiddly but EA copes.

Fair point. And the editor tooltip does tell you that DrawNativeShape() won't work for a connector script. But who has time to read those?

/U

49

Automation Interface, Add-Ins and Tools / Re: Partly hidden stereotyped connector with shapescript to change the color

« on: November 23, 2020, 08:00:20 pm »

Well, it seems the editor doesn't recognize whether the script is for an element or a connector. I'd call that poor design rather than a bug.

/U

50

Automation Interface, Add-Ins and Tools / Re: Partly hidden stereotyped connector with shapescript to change the color

« on: November 23, 2020, 07:19:41 pm »

Is DrawNativeShape() allowed with connectors? Try moveto(0,0); lineto(100,0); instead.

As per help it's explicitely not allowed.

Not quite. "This method is only enabled for element Shape Scripts; line Shape Scripts are not supported."

The editor allows you to call DrawNativeShape() in a connector script, and the auto-completion also includes it. So the claim that it isn't enabled is simply wrong.
It isn't supported in connector scripts, but the editor permits and in fact encourages you to use it anyway.

/U

51

Automation Interface, Add-Ins and Tools / Re: Alternate image on actors with Shapescript

« on: November 23, 2020, 07:13:31 pm »

Hi Guillaume,


Presumably the rectangle notation menu is enabled if that property is referenced in the script.
So try just putting the RectangleNotation check back, and try nesting it with the DisplayImage check (both ways).

I'm not aware of any way of adding your own menu items through shape scripts.
If you're getting two Use Rectangle Notation menu items under any circumstances, that's a bug.

HTH,


/Uffe

52

Automation Interface, Add-Ins and Tools / Re: Partly hidden stereotyped connector with shapescript to change the color

« on: November 23, 2020, 06:27:43 pm »

Is DrawNativeShape() allowed with connectors?

Yes, it is. But it doesn't do anything in a connector script.

/Uffe

53

General Board / Re: Ghost model author

« on: November 20, 2020, 09:16:05 pm »

Hello again,

@Uffe
 I have no idea how the name got into the repository of a brand new computer. I have opened models in which the ghost author is correctly present, but I don't see how that name could get into the EA registry entries. Hence my question to @Sparx.
The registry entry which was so keenly spotted by Q was just a plain text string, of the full name of the author as it appeared in the author drop-down.

I wonder if it's possible to set a 'default author' somewhere in EA, and only the repositories which contain that author happen to set that property? And once set, all new reps get it. No link to a windows account - brand new computer.

Well, even on a brand new Windows installation there is at least one account. Not a domain account, but a local one. (Actually there are about half a dozen accounts on a fresh install, but only one whose name is set during installation.)

In addition to the accounts, the Windows installation also keeps registration information under HKLM\Software\Microsoft\Windows NT\CurrentVersion, values RegisteredOwner and RegisteredOrganization. So if the default author is set by the installer, it could use these values, possibly as a fallback in some situation.

Are you using the Sparx installer, or is the installation repackaged locally? That's a big piece of the puzzle.

/U

54

General Board / Re: What options do I have for showing tabular information based on UML?

« on: November 20, 2020, 09:04:52 pm »

If the number and names of the columns are not constant you probably need to resort to some kind of scripting solution.
...
I believe you would need a "Document script" template. The code in your script then needs to return the raw RTF code for your table.

Not necessarily. If you can define the maximum number of columns, you can create a template for each number up to the max and then select the appropriate one in the script. With this approach there's no need for RTF injection, you can just use regular templates.
And you can usually define the maximum number of columns because ultimately they still need to fit on a page. It's never a thousand.

Often this is not worth the effort though.

Agreed. Sometimes, but not often.


/U

55

General Board / Re: How would you model a timeout condition in a statechart?

« on: November 20, 2020, 08:56:58 pm »

Hello,

From the preceding state, draw a transition to a Fork.
From the Fork, draw one transition to the next "normal" state with constraint type Signal and a guard "Signal received" or similar.
From the Fork, draw one transition to the "timed out" state with constraint type Time (specification value can be set to the wait time, eg "10s") and a guard "Timeout".

All paths from a Fork are followed in a non-specified order (could be sequential, could be parallel), so you need the guards to specify the condition that must be fulfilled for each transition to be followed. If (and only if) they are mutually exclusive, only one transition will be followed.

HTH,


/Uffe

56

General Board / Re: Linking from structures to type block diagrams

« on: November 20, 2020, 08:45:33 pm »

Hi Patrick,


Wow, DDS eh? That takes me back. Glad to see someone's using it.

Unfortunately, what you want doesn't really have any support in EA.

... linking an attribute of some structure with a well defined type to the corresponding block diagram of this type?

The problem is that EA is not aware of any one single diagram associated with any element. While you can locate the classifier element which is used as the attribute's type, EA doesn't have a concept of a particular diagram which defines that type.

So it's not something that exists in vanilla EA, but it is quite possible to achieve something like it.
Here's an outline of a solution:

• In the model, you need to add the type-definition diagram's GUID to a tagged value (call it "Definition diagram") in the type element (eg Header).
  You can do this manually every time, or you can create a stereotype which auto-creates the tagged value whenever an element of that stereotype is created. Either way, you must remember to set the value to the correct type-definition diagram's GUID once you have created that diagram.
• To enable the lookup, you need to construct an Add-In.
  This is because a diagram-context script can only distinguish elements and connectors, it doesn't recognize that an individual attribute is selected in the diagram. But an Add-In can recognize that fact.
  
  • In the Add-In you need to store the currently selected attribute by handling EA_OnContextItemChanged().
  • You also need a diagram-context menu item "Type definition diagram" or similar.
  • When the menu item is triggered, the Add-In retrieves the diagram GUID stored in the attribute type element's tagged value, retrieves the diagram's properties from the database with Repository.GetDiagramByGuid() and opens the diagram using Repository.OpenDiagram().
    You need to retrieve the properties because OpenDiagram() takes a long, not a GUID, but it's more robust to store GUIDs in situations like this.

As an alternative to creating a tagged value, you could conceivably use composite diagrams. Each element in EA can have one (1) composite diagram, and that diagram has some special handling associated with it so it's easy to retrieve from the API and so on. However, this assumes that no type-definition diagram defines more than one type, because two elements can't share the same composite diagram.
(Well, technically they can, but it's not intended use and it can have nasty side effects -- deleting an element also deletes its composite diagram, and if that diagram happens to be the composite diagram of another element then that other element loses its composite diagram. This is probably not what you want, so it's better to go with a tagged value even if you do have to copy-paste a lot of GUIDs.)

The Add-In could also include some support functions to reduce the amount of GUID copy-pasting, clear the tagged values targetting a certain diagram when that diagram is deleted (or indeed prevent the deletion of said diagram if it's the target of an element's tagged value), etc.

You could also just locate the type element, rather than the type-definition diagram, and then use EA's built-in "Find in Diagrams" function. This would obviate the need for tagged values storing the type-definition diagram GUIDs.
However, you'd still need the Add-In because the crux is once again that only an Add-In can be aware of what attribute the user has selected in a diagram. Also, if the element is present in more than one diagram, the user would be presented with a selection dialog and then need to select the correct one.
So that would be a simpler solution that does not introduce any tagged values (which need maintenance as the model changes over time), but at the cost of a less smooth user experience.

HTH,


/Uffe

PS Why yes, I am available to build this for you. Hit me up with a PM if you'd like a quote.

57

General Board / Re: Ghost model author

« on: November 20, 2020, 07:58:31 pm »

Hi Ian,


Out of curiosity, was this ghost user name taken from your system, or was it some kind of default name?
If the latter, what was it?

And if the former, was it an account name, or a full name, or some other Windows account property?


/Uffe

58

Bugs and Issues / Re: 15.1 Toolbox missing options for Sequence Diagram.

« on: November 19, 2020, 07:38:13 pm »

For some reason, there seems to be no properties dialog for the Sequence/Message connector. (Anymore?)
Instead, you have to look in the properties window.

/U

59

General Board / Re: What options do I have for showing tabular information based on UML?

« on: November 19, 2020, 07:36:59 pm »

Hello,


The problem with EA's document generation facilities wrt tables is that there is no dynamicity in the columns. It's easy to create a template with a table where the number of rows is determined during document generation, but the set of columns is fixed in each template.

But anything's possible. I have created column-dynamic tables in the past; it's not pretty but it can be done.

HTH,


/Uffe

60

Automation Interface, Add-Ins and Tools / Re: DocumentGenerator.DocumentElement: nDepth seems to do not work.

« on: November 19, 2020, 07:25:21 pm »

Hi,


The built-in template "Requirement Report - Details" isn't intened to be used this way. It's intended to be run on a package and produce a full document on its own. DocumentGenerator.DocumentElement() is intended to produce output for a single element into the DocumentGenerator's stream. I recommend you create your own template to output the details you want for an element and use that instead.

As a general rule, when using Repository.GetElementSet(..., 2) only select t_object.Object_ID because that's all EA uses -- the element details are retrieved separately behind the scenes. This makes no difference to small queries, but it will have an impact on large ones.

The manual states that DocumentGenerator.SetStyleSheetDocument() "can be called before NewDocument." Try that, I think it might be ignored otherwise. Again, mixing built-in templates with DocumentGenerator is off the beaten track and may well have surprising consequences.

HTH,


/Uffe