Sparxian: "Everything possible"

[Paolo F Cantoni]

As you know, we users (rather endearingly) call the crew at Sparx "Sparxians".

However there is one side effect of this that is REALLY starting to impinge on our ability to effectively (and certainly efficiently) use EA.  That side effect is that they speak Sparxian and not Earthly languages such as English (as the rest of us do).

I was sorely tempted to write another "Dear Geoffrey" posting, but I thought I'd give the Sparxians the (initial) benefit of the doubt.

I'm now investigating MDA transforms.  As I've learnt over the years, before using something new (or even not used for a while) in EA I had best investigate how many bugs there are in the functionality I haven't used before.

So, I'm trying the Transform "out of the box"...

The description of the "Default" transform reads:

$COMMENT="  A default set of transformation templates has been created  "
$COMMENT="  that copies everything possible from the original model.    "
$COMMENT="  These templates are designed to make it easier to write a   "
$COMMENT="  basic transformation.  Any model information that           "
$COMMENT="  shouldn't be copied directly can be added to the            "
$COMMENT="  %TRANSFORM_CURRENT()% macros, with a corresponding new      "
$COMMENT="  assignment created to specify what should be created.       "

$COMMENT="  This template creates a package to contain all transformed  "
$COMMENT="  elements.                                                   "

(my emphasis).

What I'd like to do now is to issue a challenge to both the Sparxians and the user base to provide below a definition of what they (you) understand by the term everything possible.

Fellow user Oliver F. noted in: New bug: Phase field is ignored in transformations that everything possible did not (apparently) include the Phase field.

Anyway, please respond with what you think the phrase "everything possible" means in the context of a transformation (or even any other field of endeavour).

Once I see whether I'm off on another planet to the rest of the user base (I am far away, and separated, in Perth, Western Australia) - wrt the meaning of "everything possible".  I'll provide full details of the testing I've done.  (Notice I haven't implied that Sparx haven't done this testing.  That's because the definition of whether what I've found indicates a bug and lack of testing (or not) depends upon the interpretation of the phrase "everything possible".

Also, not being an expert, the "Transform out of the box" appears to be coded to do what I had interpreted the initial coment above to mean.  So, to be clear, I'm not complaining about the coding - just the outcomes (as did Oliver above).

TIA (for your feedback - wrt interpretation),
Paolo

[mrf]

Everything Possible = Everything supported by the transformation framework = http://www.sparxsystems.com/uml_tool_guide/mda_transformations/transformingobjects.html

PS: The issue with the Phase field not being available has been acknowledged and is in the process of being rectified.

[Paolo F Cantoni]

Everything Possible = Everything supported by the transformation framework = http://www.sparxsystems.com/uml_tool_guide/mda_transformations/transformingobjects.html
[size=18]...[/size]

Well then Michael,  I took an "out of the box" base model and used the "out of the box transform" and created a Class and transformed it...

Care to guess how many of the 20 odd objectProperties listed therein actually transformed and then if I changed them in the source were synchronized correctly?  The two numbers are different (for reasons that are beyond me).  Also would you care to guess how many objectProperties were corrupted during synchronization?

I AM assuming that you accept that the "out of the box transform" is coded to transform the set of objectProperties listed on the linked page.

Paolo

[Geert Bellekens]

Paolo,

Have you considered "rolling your own" MDA transforms i.s.o. trying to get the built-in MDA transforms to do something usefull?

I'm getting the impression that the first option is going to cost you less in the end  :-/

I have a feeling its going to be like the RFT report generator. It gets you pretty far pretty fast, but the last miles to your destination are going to cost you dearly. (if you're überhaubt even going to get there)

Geert

[Paolo F Cantoni]

Paolo,

Have you considered "rolling your own" MDA transforms i.s.o. trying to get the built-in MDA transforms to do something usefull?

Eventually, Geert, that's likely to be the case.  But there are two issues I'm trying to address here:

The first is that the MDA Transform doesn't seem to work at all (to any, what I would think, reasonable extent).  I mean, unlike the RTF Generator you mention, it REALLY isn't rocket science.

Secondly, some of our customers, especially new ones, don't want anything that isn't "mainstream" EA - and they generally view Add-ins as non-mainstream.  I think they'd view scripts as mainstream (hence my feature request for EXEC_SCRIPT)

I'm getting the impression that the first option is going to cost you less in the end  :-/

Probably  , but see above.  Besides, it shouldn't be the case.

I have a feeling its going to be like the RFT report generator. It gets you pretty far pretty fast, but the last miles to your destination are going to cost you dearly. (if you're überhaubt even going to get there)

Geert

At the present, the car stalled after leaving the kerb...

Assuming, of course, that the problem is NOT specific to my machine, but since I duplicated Oliver's experience, I suspect not.

Paolo

[Oliver F.]

PS: The issue with the Phase field not being available has been acknowledged and is in the process of being rectified.

Which I can acknowledge as Alan has sent me an appropriate statement.

Oliver

[Geert Bellekens]

Secondly, some of our customers, especially new ones, don't want anything that isn't "mainstream" EA - and they generally view Add-ins as non-mainstream.  I think they'd view scripts as mainstream (hence my feature request for EXEC_SCRIPT)

I've encountered that sentiment before too, and I think it is wrong from a customer point of view.

It's the same for custom document generators, custom model validation, and I'm pretty sure for custom MDA transforms.

If you want any of those things to work in your environment you are going to spend quite a lot of time writing EA specific templates, scripts etc... I doubt whether the effort to get a decent RTF document template is less then the effort to create a document generator from scratch.

The advantages of a custom tool is that (given that you design it in a proper way )

• It will work exactly as you want it, for 100%, not more or less OK
  
• The effort is not lost when you would decide to switch CASE tools.
• You do not increase the (already strong) vendor lock-in.

It just seems hard to explain that to people who have "maximum out of the box" as one of their principles  
They should realize that creating templates for document generation, or MDA transforms is no "more" out of the box then creating a whole custom tool.

Geert

[Paolo F Cantoni]

[size=18]...[/size]

I've encountered that sentiment before too, and I think it is wrong from a customer point of view.
[size=18]...[/size]
Geert

I agree, but it's hard to convince the customer.

It's easier to get them going with some "out of the box" stuff and once they're on board, move them onto the more "involved" mechanisms.

I've said elsewhere that I now view EA as an "engine" onto which you need to impose your particular modelling style - which is often particular to an organization.  We're working toward enabling that.

Paolo

[Geert Bellekens]

I agree, but it's hard to convince the customer.

Would it be easier if we had an (open source) modelling tooling framework that you can use to build your tools upon?

I've been thinking about something like that for a while, but I don't have the time (or money) to do something like that on my own.

The tools I'm writing today are all based on the same framework pattern, and they allow both variations in modelling method (style) as variations in the "engine" behind it.

I'm not sure if I could get the permission to open source my current (customer owned) work, but I could certainly replicate it.

Geert

[Paolo F Cantoni]

Yes, Geert,  I've been thinking along the same lines.

The problem that the open source framework addresses is that no customer wants to be "out there alone".

If we can show that they are just "jumping on the bandwagon", then it makes it a lot easier, I think.

Perhaps it might be better to start a new topic - either getting Sparx to move these last posts to it or just copying the content.  I think this idea is something most users might have an input on and deserves its own topic.

Paolo

[Geert Bellekens]

Paolo,

I've created a new topic

Geert

[Paolo F Cantoni]

Everything Possible = Everything supported by the transformation framework = http://www.sparxsystems.com/uml_tool_guide/mda_transformations/transformingobjects.html
[size=18]...[/size]

Well then Michael,  I took an "out of the box" base model and used the "out of the box transform" and created a Class and transformed it...

Care to guess how many of the 20 odd objectProperties listed therein actually transformed and then if I changed them in the source were synchronized correctly?  The two numbers are different (for reasons that are beyond me).  Also would you care to guess how many objectProperties were corrupted during synchronization?

I AM assuming that you accept that the "out of the box transform" is coded to transform the set of objectProperties listed on the linked page.

Paolo

Getting back to the original point of the topic, do I have to submit a formal bug report or will someone confirm or deny how many objectProperties get transformed?

Paolo

[Paolo F Cantoni]

[size=18]BUMP![/size]
Bug report submitted:
The out-of-the-box default transform does NOT (or incorrectly) transform(s) the following objectProperties:

Abstract
Alias
Arguments
Author
Complexity
Concurrency
Filename
Header
Import
IsActive
IsLeaf
IsRoot
IsSpecification
Keyword
Language
Multiplicity
Persistence
Phase
Scope
Status
Stereotype
Version
Visibility.

Some properties are not created correctly; others won't subsequently synchronize.  Scope, appears to be corrupted on subsequent synchronizations.It would be very useful if some kind soul could confirm my observations.

Paolo