Book a Demo

Author Topic: v15.2 – EXTRAORDINARY overhead to create Extended toolbox item from a Pattern  (Read 3673 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
In a separate thread v15.2 – Can we create an extended stereotype from Toolbox?, Sparxian Eve shows how to create an extended toolbox item (i.e. an item with more than one stereotype on creation) using the Sparx UML Pattern process.

It is quite cumbersome! First, you have to create a specific diagram with ONLY one item on it, set up as desired.  Then you have to export the diagram as a pattern (creating a specific XML file) and then include it specifically in the MDG creation script file.
Lastly, you have to create a toolbox entry that references the specific pattern.  You can then drag the item from the toolbox and voila, an item with multiple stereotypes on creation!

That may seem like quite some overhead, for something that could (potentially) be easily handled by adding a _StereotypeEx attribute to the stereotype definition.  But that's not the reason I capitalised the word EXTRAORDINARY.

On investigation, we discovered that to (effectively add some tens of characters to the stereotype definition in the output XML), a single item added a pattern specification of 56KB!!!  Now, we intend to have a number of these extended toolbox items, which implies between 50-60KB for each! 

We've put in a lot of effort to reduce our MDG size via effective use of the model-based generation process and the size (for an even bigger and much more sophisticated metamodel than initially sized) has reduced from some 14MB to a little over 3 MB!  But at "50-60KB a pop" it's not going to take long to have a humungous MDG file again!

Now that you're aware of the OVERHEAD, is there support for embedding the creation of extended toolbox items by a more efficient mechanism?  If so, I'll put in a feature request and maybe in a couple of decades, we might see something.

TIA,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
Yes, the pattern mechanism is designed for much more complicated use cases. The overhead you're seeing is effectively to support those cases.

The bulk of the size of a pattern is a preview image. If you're using UMLPatternSilent in the toolbox that can be removed with no loss of functionality. It's an extra step in the process, but if the end result is important to you... You could probably even use an XSLT to remove all of the information you don't want from the pattern.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Yes, the pattern mechanism is designed for much more complicated use cases. The overhead you're seeing is effectively to support those cases.

The bulk of the size of a pattern is a preview image. If you're using UMLPatternSilent in the toolbox that can be removed with no loss of functionality. It's an extra step in the process, but if the end result is important to you... You could probably even use an XSLT to remove all of the information you don't want from the pattern.
Agreed - about the more complicated use cases.  I think it would be good to have a checkbox on the Save functionality to indicate that the target of this pattern is a Toolbox item and for it to remove unnecessary output such as the preview image.

Thoughts?
My suspicion is that it would be easier (and, perhaps, more appropriate) to add something like a _StereotypeEx attribute to the stereotype generation process.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8110
  • Karma: +119/-20
    • View Profile
I'm sure a custom feature built-in to the tool to do exactly what you and only you are after and nothing else would make it easier for you.

The point in suggesting the pattern is offering a way to make it work with the features that already exist in the tool.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
I'm sure a custom feature built-in to the tool to do exactly what you and only you are after and nothing else would make it easier for you.

The point in suggesting the pattern is offering a way to make it work with the features that already exist in the tool.
Agreed that at the moment, I'm probably the only user, but with the new model-based MDG generation, and the usage we've made of it to create a very consistent modelling environment which we hope (when the defects are fixed) will provide a truly flexible and easy to maintain process, the use of multiple stereotypes to take advantage of EA's hardcoded (inflexible) mechanisms and yet incorporate (hopefully seamlessly) them within the flexible framework will become more widespread.  I'm prepared to be the "bleeding edge".  My (possibly vain) hope is that these features that I request will be seen as useful for more general use.

I've been fortunate in my professional life that some things that I have promoted have become mainstream - sometimes decades later!

In this case, the only reason I have to request this functionality is that EA has hardcoded stuff - itself a dubious design choice!

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!