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.


Topics - Paolo F Cantoni

Pages: 1 ... 60 61 [62] 63 64 ... 80
916
Bugs and Issues / lineto behaves differently for main than endshapes
« on: August 29, 2008, 01:42:50 pm »
In the main shape the X value appears to be a percentage of the line, the Y value is some offset (but not to same scale - seems to be approximately 1/10th scale).

In the subshape, both x and y are absolute values.

shape main
{
    lineto(75,75);
}
shape target
{
    lineto(75,75);
}

Observe the inconsistent behaviour.

NOTE: this percentage stuff also seems to apply to shapes drawn in the main shape for the connector - try drawing some and see...

Paolo

917
Bugs and Issues / When is default NOT default?
« on: January 25, 2010, 07:15:48 pm »
I'm setting up an MDG technology for a client and we'd previously setup some stereotypes using the Settings|UML...|Stereotypes dialog.  We changed the Default Colours to our required values.

In the MDG Technology section of the Help file it says:
You can define the appearance of stereotyped elements and connectors as you create or edit the stereotypes, using the Override Appearance and Default Colors panels of the UML Types dialog. However, an easier way is to review your completed profile diagram and set the default appearance of the elements and connectors in place.
Now, I don't know about you, but, for me, the usual reading of the above bit of natural language is that the second use of the word default mirrors the first use.

Well, it turns out that isn't actually so...  When you follow the instructions, you do get the colours you set.  However, under the covers, EA does it by actually setting the colour values (in the same way as <Context Menu>|Appearance|Set Default [F4] in the element itself!  This means that if you change the rendering in the MDG, all existing elements retain their (now incorrect) rendering.  In our case, all the existing 600 elements which were previously correctly rendered by UML|Stereotypes, lost their rendering completely!

Before I send a (justifiably irritable) bug report (because I really need a fix for this).  Is there any way to create the same effect (specify the default colours once in the MDG technology - like the UML|Stereotypes dialog) so that all existing stereotyped elements get the appropriate rendering?

Thoughts?

Paolo

918
Bugs and Issues / Support for instances of relationships
« on: January 12, 2010, 04:19:40 pm »
[edit]Topic Subject changed to: Support for instances of relationships
(was: Link as Association Instance)
[/edit]
The UML 2.2 Superstructure (formal) Specification in discussing InstanceSpecification says (in part):

[size=14]7.3.22 InstanceSpecification (from Kernel)[/size]
An instance specification is a model element that represents an instance in a modeled system.
Description
An instance specification specifies existence of an entity in a modeled system and completely or partially describes the entity. The description may include:
• Classification of the entity by one or more classifiers of which the entity is an instance. If the only classifier specified is abstract, then the instance specification only partially describes the entity.
• The kind of instance, based on its classifier or classifiers. For example, an instance specification whose classifier is a class describes an object of that class, while an instance specification whose classifier is an association describes a link of that association.
Before I submit a Feature Request is there any way to do this in EA build 850?

What about the issue of instances of other types of relationships?

As we move more into Instance Models, EA's fragility in this area impacts us more.  I could create a new topic to discuss Instances, in general, and we could provide Sparx with our view points.  See also: Action as Activity instance? for an indication of some of the issues and some possible representations of instances.

TIA,
Paolo

919
Bugs and Issues / classifier.metatype = null in shapescript
« on: January 08, 2010, 06:25:13 pm »
In a shapescript, the list of properties includes:
  • classifier
  • classifier.alias
  • classifier.metatype
  • classifier.name
  • classifier.stereotype
Of these, classifier and classifier.name return the same value (so one is, presumably, redundant)

However of much more significance is that classifier.metatype returns nothing and, therefore, can't be used to test against.

Steps:
Create a ShapeScript consisting of printlns for the above properties

Observe classifier and classifier.name return the same value, and that classifier.metatype returns nothing.
Reported,
Paolo

920
Bugs and Issues / Sparxian: "Everything possible"
« on: December 18, 2009, 02:39:16 pm »
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:

Quote
$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


921
Bugs and Issues / Classifier selection not "real-time"
« on: December 22, 2009, 05:56:18 pm »
The Instance Classifier [Ctrl+L] selection browser doesn't use the current type of the element set.  If you change the type of an element (so that it should appear on the list) and then browse for it, it won't be found until the next time you reload the package.

Similarly, if you change it so that it shouldn't appear, it stays there (but, interestingly, with the new - invalid - icon) , until the package reload.  This makes it problematic for users.

The Search tab works correctly.


Steps:
Create an Artifact.

Observe it is not on the list of Classifiers.

Change to a Class

Observe it is STILL not on the list of Classifiers.

Reload package.

Observe it is NOW on the list of Classifiers.

Change back to Artifact and observe reverse behaviour.
Reported,
Paolo

922
Bugs and Issues / Browser and t_xref inconsistent after Transforms
« on: December 17, 2009, 01:08:32 am »
I've just spent 8 hours today tracking down what I consider a very serious bug in the MDA transformation process.  It's after 10pm so I'm going to bed to rest.  I'll document the details tomorrow.

If you try to apply the same transform from the same source package to multiple target packages, weird things happen.

Has any one else tried that before?  I suspect not - because of this bug - but I thought I'd ask just in case anyone got it to work.  (Can't see how, but you never know with EAUI).

Anyway, if you attempt to perform (what I consider a reasonable use case) you'll find that the transformation information in t_xref no longer matches what is going on in the browser.


Steps:
Create a simple transform.
Run it
Pick one of the transformed elements, drag it to another package (say not in the transform)
Rerun the transform
The "missing" item will not be created
Change the target package
Rerun the transform
Nothing is created in the new package.
Open t_xref, create a view joining Client and Supplier to t_object and Link to t_package - select only the transform entries - for the namespace of your transform. Observe that t_xref claims that the items should be in the second package, but they haven't moved in the browser!

See my tag line...

Now, I suspect some aspects of the bug are due to the underlying data model used for transformations, but the principal cause is just code that doesn't work...

Paolo

923
Bugs and Issues / Transform Selection TOO sticky
« on: December 17, 2009, 01:01:55 pm »
The Model Transformation [Ctrl+H] [Ctrl+Shift+H) dialog doesn't allow you to unmark a transform permanently.  If you unmark it for this run, it's back the next time you open the dialog.

However, if you change the transform templates, the check box is unmarked and the pointer to the desired target disappears!

What use case does this behaviour support?


Steps:
Select and mark  transform in Model Transform dialog.
Close dialog
Open dialog.
Observe transform is still marked.
Unmark transform.
Close dialog
Open dialog.
Observe transform is still (incorrectly) marked.


924
Bugs and Issues / Buttons on Transform Editor not indicative
« on: December 17, 2009, 07:19:31 pm »
The [Get Default Template] [Save] and [Delete] buttons on the Transform Editor are not indicative of their state so it can be confusing and may lead to accidental deletion of subsidiary macros.

Reported,
Paolo

925
Bugs and Issues / Too hard to delete Transform Templates
« on: December 17, 2009, 06:33:09 pm »
The creation of a Transformation or Code template shouldn't require the changing/saving of one of the subsidiary macro templates.  I may want a default template under another name.

Similarly the deletion of a template should NOT require the explicit deletion of every changed subsidiary macro.

When you're creating new transforms and testing changes, you often want to quickly create/delete temporary templates to allow you to "Compare and Contrast".

What Use Case does the current behaviour support?

Reported,
Paolo

926
Bugs and Issues / Need "Don't close" after Model Transform
« on: December 17, 2009, 12:48:52 pm »
The Model Transformation [Ctrl+H] [Ctrl+Shift+H) dialog needs a checkbox (similar to that for Windows File Download dialogs) to inhibit automatic closing of the dialog after the transformation completes.

If something goes wrong, we users need to see what EA thought it did.  Otherwise, if you're going to force a close, why not do it immediately and save writing stuff to the progress window - which we can't view (becuaseit's scrolling too fast and then disappears).


Steps:
Run Model Transformation
Be frustrated at inability to see what the transform is doing (at least for the last few objects)

Reported,
Paolo
PS: if this capability had been there, I would have "sussed out": Browser and t_xref inconsistent after Transforms hours earlier...

927
Bugs and Issues / Null is NOT False
« on: December 09, 2009, 12:27:21 pm »
When EA does a package import it replaces a false value in t_attribute.IsStatic with a NULL value.

NULL Is NOT the same as False!

Of ALL the Booleans in t_attribute, IsStatic is the only one that exhibits this behaviour.

This needs to be rectified immediately,  the semantics of the model are changed on import.

Indeed, you should check that ALL booleans ONLY emit 0 & 1.


Steps:
Take a repository,  ensure there are NO t_attribute rows with IsStatic = NULL.  Make sure there ARE t_attribute Rows with IsStatic = 0

Export then re-import.

Observe IsStatic now contains NULL values for the rows that were previously 0.

Reported,
Paolo

928
Bugs and Issues / Feature Linked Notes don't cascade
« on: December 09, 2009, 04:38:42 pm »
If you link a note to another note and use "Link this note to an Element Feature..." EA copies the current state of the Feature (such as, in this case, the Note Notes column) into the Notes column of the Linked Note.

If you change the origin note, the rendered note will change, but the column value does not.

If you then link a new note to the second (linked) note, you will get the (incorrect) value of the second note column.   The linkages won't cascade.

They should.  If there is an initial copy (which is a dubious concept for a linked note) then it's EA's responsibility to maintain that copy correctly.


Steps:
(see above)

Why do I need Notes linked to Notes?  Well it turns out that if you copy a diagram Note from one diagram to another, the internal texts is NOT maintained.  Since I want to have one place of definition of some information, I thought I'd use the Feature Linked Note to achieve (and it could be argued, the more correct mechanism) effectively the same outcome.  Didn't work - since if I update the origin (in this case diagram Notes) the linked note doesn't update.

Reported,
Paolo

929
Bugs and Issues / Boundary name affects Package Display
« on: December 09, 2009, 05:19:18 pm »
If you place a package on a diagram and display its contents, then place a boundary on the diagram with the same name as the package, the contents of the package will double up.  In fact, if you add another boundary to the diagram - again with the same name it will then triple up and so on...

Looks like a "count(*)" query bug to me...

Reported,
Paolo

930
Bugs and Issues / Base64 output is not stable
« on: December 09, 2009, 03:57:59 pm »
EA uses Base64 encoding in the XMI for (amongst other things) Model Documents. (dt:dt="bin.base64" - in the XML entry).

However, each time you do an export, even if there has been NO change to the entire repository, the encoding changes.

This makes it difficult to use file comparison products to ensure the consistency of output.

I see no reason (not being a Base64 expert) why they should be different.


Steps:
Export a package containing Model Documents.

Save export.

Reexport - changing nothing.

Compare the two outputs - the Base64 encoded data is different.

Can any Base64 experts explain if this phenomenon is inherent in Base64?

Reported,
Paolo

Pages: 1 ... 60 61 [62] 63 64 ... 80