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 - Svend Erik Nygaard

Pages: [1] 2 3 ... 8
Just to make sure, that I haven't missed the feature:

Is it correct, that there is no method in the object model telling which elements (plural) have been selected in the search result?

This is great (and, of course, about time  :))
Did you notice - Now you can also have icons on your stereotypes (metatypes) that extends package.
Earlier such icons would only show up in the project browser for elements, not for packages.

I cannot find how to publish a package as a UML profile  in EA v. 14.1.1427
I have tried:
Select a UML profile package in project broser
Then I go to ribbon: Specialize / Publish
But only gives me an option of: Publish Diagram as UML Profile (not a package)
I tried it, of course – but it actually does only save the diagram as a profile

I also tried the command search and opened the Save UML Profile window – but same result

In EA 14.0.1423 it worked (although, as Geert Bellekens told me, I had to have a diagram open )

Has anyone of you succeeded in saving a package as UML profile in EA v. 14.1.1427?

General Board / How do I hide derived tagged values?
« on: September 19, 2018, 06:57:45 pm »
In the tagged values pane/window, the derived tagged values are shown below the other tagged values.
This causes confusion and irritates my users.
I haven't found a way to hide them from the pane/window.
Is it not possible to hide these derived tagged values from this pane/window?

Yes, that was what I was on my mind from the beginning of this. I don't think it will be changed.
But I also wanted to hear about any work-around or thoughts from Sparx about this for the future - before I made the discussion to use connector direction for reading direction (a decision which will introduce a conventions that brakes the UML semantics - but are feasible for us for the reasons mentioned in the initial post)

... So the spec is to be blamed, not EA.

However, the way it's implemented in EA (placing the name direction on the diagram link instead of on the connector) is strange and causes extra / tedious efforts in modeling - and makes it more error-prone
1) it opens up for setting different name directions on the same connector on different diagrams - which is meaningless and erroneous
2) ... and you have to set it anew each time you re-use the connector on other diagrams

Suggestions and Requests / name's direction on dgm-link vs on connector
« on: August 21, 2018, 09:44:19 pm »
First: This is not about the connector's direction, but about the connector name's direction.

I have noticed, that the name's direction is stored on the diagram link - not on the connector.

This causes the following mal-function in EA:
1) the same connector can have different name directions on different diagrams - very unfortunate
2) when creating the same connector on (another) diagram, the name direction is not transferred (this is more an inconveniency than a malfunction - but it also makes modeling more error-prone, because of point 1 above)

I think the UML spec does noes not address this issue very clearly or explicitly - but I think the name direction should be on the connector itself.

This malfunction will probably make us use the connector's direction for the reading direction instead of the name direction.
Yes, I know, unlike the name direction, the connector direction has a semantic on it (navigability) - but since we don't use our model for forward engineering / code implementation, we may make that decision - unless there are plans to change the above described behavior.

Are there any such plans to change this behavior of the name direction in EA?

How do I administer enabling/disabling (and setting active) MDG Technologies for all users?
EA comes with a large bundle of MDG Technologies. I want to centrally disable a lot of these and set one of them as the active one. (preferably not for a specific model but for all clients)

That was a great shot, Geert - right in the bull's-eye  :)

One of the MDGs coming with EA14 must have a "impl" stereotype.

Of course that leaves me with a consideration of making my automation routines more robust (more precise)

I do not see anywhere in the t_connector table that tells me the 'absolute'/complete name of the stereotype - I'll look into that after the weekend (maybe in t_xref). It would be nice, had it been stored in two separate columns with the stereotype column holding only the short incomplete name - and then let it be purely e rendering choice.  Now I have two different values in the same column (respectively for rows before and after EA14)

Tanks very much for your help again

In my MDG, I have a stereotype “impl” extending “Realization”.
Before EA14, it behaved just like all other stereotypes, setting a connector’s stereotype property to “impl”.
But after upgrading to EA14, it sets a connector’s stereotype to “CPH_MetaModel::impl” – which causes a multitude of problems in our automation routines.
It seems, all other stereotypes in my MDG do NOT have this problem.
Have any of you experienced the same issue?

Below, I have included the MDG XML for the impl plus a couple of other connector steretypes. As mentioned only the impl causes problems.

<Stereotype name="impl" metatype="impl" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
      <Apply type="Realisation">
         <Property name="direction" value="Source -&gt; Destination"/>
      <Tag name="Master" type="boolean" description="" unit="" values="true,false" default=""/>

<Stereotype name="at" metatype="at" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
      <Apply type="Dependency">
         <Property name="direction" value="Source -&gt; Destination"/>

<Stereotype name="reflect" metatype="reflect" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
      <Apply type="Generalization">
         <Property name="direction" value="Source -&gt; Destination"/>
         <Property name="isSubstitutable" value=""/>
         <Property name="_lineStyle" value="direct"/>

Thanks, for quick answer, Geert.

After upgrading to EA 14 (1422), I cannot save package as uml profile
In EA 13.5 this menu item was in the package's context menu. Now in EA 14 it is under the ribbon Specialize/publish - but here the menu item "Save package as uml profile" is gray out.
(of course, I have selected a uml profile package when trying)
What am I doing wrong?

Why is it so important that you have a stereotype on your diagrams?

  • Searching
  • Reporting
  • Applying logic/rules/quality checks
  • ...

I'm sorry I don't understand what you mean with "elements created from the MDG's diagram type"

Yeah, that was a bit of fast typing, sorry.

I mean:

I create a customized diagram type "CityMap" in my MDG.
Then, when the user creates a new CityMap diagram, I want EA to set the diagram's stereotype to "CityMap"
Is there any way, I can specify in my MDG, that the diagram should automatically be given the stereotype "CityMap" - for instance, can I, in my MDG, specify a default value for the Stereotype property?

Pages: [1] 2 3 ... 8