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 - Uffe

Pages: 1 ... 55 56 [57] 58 59 ... 72
Bugs and Issues / Re: Composite element/diagram weirdness
« on: January 03, 2012, 04:34:21 am »
Hmm, yes -- I can see where you're coming from. I'm still not convinced, though.

Consider the Make Composite function. This creates a diagram (unless the element already contains one), but does not provide the option of linking to an existing one.
This would imply that the intended semantics are closer to strict containment than a softer link.

In fact, AFAIK the many-elements-to-single-diagram behaviour only applies to Activities: switch off the Automatic SubActivities option, and EA creates Diagram Hyperlinks instead.
This would also seem to weaken the case for the current behaviour: why Activities, specifically? Especially considering that an InvocationAction which is an instance of a Composite Activity will, when double-clicked, open its classifier's diagram.

I wouldn't be kicking up a fuss except this has caused some consternation with my current client. I'm quite prepared to lump it (don't have to like it  ;D), but I wouldn't mind hearing from a Sparx rep on this issue.



Bugs and Issues / Composite element/diagram weirdness
« on: January 02, 2012, 08:50:51 pm »
Hi all,

I've got some issues with Composite elements and diagrams in EA. I would call this behaviour buggy, but I'd like to hear your thoughts.
My premise is that the Composite element/diagram relationship should be strictly one-to-one and that the diagram should always be contained in its parent element, but in certain circumstances EA violates both these principles.

Weirdness #1: EA allows you to move a Composite diagram out of its parent element.
When you do, the Composite relationship is retained, so that if you then double-click the element in a different diagram, you navigate to the composite diagram -- which is now located somewhere else.

Weirdness #2: multiple Composite elements can share the same diagram. Here's how:
1. Create an Activity diagram "Blarg". Put some simple stuff in it.
2. Create a second Activity diagram "Honk", preferably in a different package.
3. Into the "Honk" diagram, drag the "Blarg" diagram from the browser and select to create a Hyperlink.
4. EA creates a Composite Activity named "Blarg" whose composite diagram is the "Blarg" diagram.
5. Repeat 3 a few times. You now have several Composite Activities which share the same diagram (which is not actually contained in any of the Activities).

I would suggest the following behaviour instead.

#1: If you try to move a Composite diagram out of its parent element, EA either refuses while the element is marked as Composite (forcing you to un-Compositeify the element first), or automatically breaks the Composite relationship.

#2: In drop-diagram-on-diagram situations where EA would create a Composite element, extend the "Drop Diagram As" dialog to include both Hyperlink and Composite Element.
A Composite element should be created in the package where the dragged diagram ("Blarg" above) is located, not in the package where the dropped-onto ("Honk") diagram is located, and the diagram should be moved into the new element.
The Composite Element option should only be available if the diagram is not already a composite diagram.



Bugs and Issues / Re: MDG Tech: "Merge" pattern creates new element
« on: November 19, 2011, 02:12:45 am »
Hi again,

I also noticed the same behaviour for the "A" element when I specified them both as Merge only.



Bugs and Issues / Re: MDG Tech: "Merge" pattern creates new element
« on: November 18, 2011, 06:37:12 pm »
Element A is an Activity, with a stereotype from a profile ("P") in the same MDG Technology.

Element B is a Process, from the built-in Extended profile (a stereotyped Activity).

The connector is a Dependency, also with a stereotype from profile P.

Both of my stereotypes are common-or-garden ones with no tagged values, shape scripts or any custom attributes.



Bugs and Issues / MDG Tech: "Merge" pattern creates new element
« on: November 18, 2011, 03:12:38 am »

I'm building an MDG Technology where I want to include an extremely simple pattern: create one new element (A) and draw one connector from that new element to one existing element (B).
I've drawn my diagram and saved it as a pattern, specifying "Create" as the only option for element A, and "Merge" as the only option for element B.

When I load my MDG Technology and apply the pattern, element A is created, and the connector is created and hooked up to the existing element which I've selected in the browser. Fine.
But in addition, a new element named B is created.

Am I doing something wrong here? Does anyone recognize this behaviour?



Bugs and Issues / Re: Reference data export: matrix profiles
« on: November 11, 2011, 05:46:36 am »
Ah, I see. Well that's alright then.



Bugs and Issues / Reference data export: matrix profiles
« on: November 10, 2011, 10:43:10 pm »

I've got a couple of diagram matrix profiles defined in a project (visible in the Resources window), which I'd like to transfer to another one.
Problem is, when I try to export them (Project - Model Import/Export - Export Reference Data) I end up with an XML file which contains only the <RefData> tag - no actual contents.

Has anyone got any input?
I'm on 9.0.905 on XP SP3.



Bugs and Issues / Re: Strange lock behaviour
« on: October 28, 2011, 10:53:06 pm »
2-3) Locking is stored per element. The context menu just looks into the selected element to set the radio button to the opposite. So that seems logical.
Well, not quite. The context menu appears to be controlled not by the actual lock but by a client-internal cached lock state, which is not updated correctly when the same client manipulates the lock in a different way.

6) You can rename the model root without any lock!
Also worth a bug report, I think, but I haven't sent one. I did send one off regarding my OP; I have a 100+ user deployment here, and locking simply has to work.

Bugs and Issues / Strange lock behaviour
« on: October 17, 2011, 11:03:05 pm »

I am in a DBMS repository, with the "Require Lock to Edit" policy.
I am observing the following locking anomalies in 9.0.905:

1) If I have a diagram open when locking / unlocking its parent package, the "Delete Connector" menu option in the connector context menu is wrong. It remains available when I lock the package, and remains unavailable when I unlock it.
   The latter is an inconvenience, but the former is potentially dangerous.

2) If I apply a lock on a diagram from within the diagram itself (not the project browser), I can then add new elements even though the parent package is not locked (ie, I cannot right-click the package and Add an element).
   If I do this, I can then not delete the element again (requires package lock).

3) The in-diagram Apply / Release User Lock menu options replace one another. They seem not to check the current lock status, but instead to remember which one of them was called last.
   In other words, you can lock the diagram using the in-diagram menu, then unlock it in the browser, and then unlock it again in the in-diagram menu.

These all seem like bugs to me, but I can find no specific reference to them in the version history. Can anyone say whether they have been adressed in 9.1, or reported to Sparx?



Bugs and Issues / Re: Lock indications not updated
« on: October 17, 2011, 10:34:43 pm »
Yes, it makes sense for it to work that way since EA has no server of its own and the actual lock itself (in t_seclocks) does not remember whether it was applied recursively. Thought I'd check though. Thanks to you both.


Bugs and Issues / Lock indications not updated
« on: October 17, 2011, 05:51:37 pm »

We're using EA 9.1 in a DBMS repository, with the "Require Lock to Edit" policy. We have observed the following behaviour:
1) User A locks package P, including child packages.
2) User A sees P and its child packages as locked (blue exclamation).
2) User B selects P in the browser, and expands it.
3) User B sees P as locked (red exclamation), but not its child packages.

The desired behaviour would of course be that user B sees all child packages as locked as well.
Has anyone else observed this, and/or has any input?



Bugs and Issues / Re: Hyperlinks in NOTES (856) not working?
« on: February 04, 2011, 08:04:27 pm »
OK, I just realized that maybe when you said Notes fields, you meant Notes fields - not Notes themselves.  :-[

I tested this in 8.0 (864), and here's the scoop.

You can create a hyperlink inside a Note field, as above.
The link is not displayed as a link in a diagram, nor is it clickable.
If you switch on formatted Notes for the Element, the link is displayed properly, but is not clickable.
If you create a separate Note and link it to the Element's Note, again, the link is displayed properly, but is not clickable.

In other words, it doesn't work in 864.

Sorry about my confusion there.



Bugs and Issues / Re: Hyperlinks in NOTES (856) not working?
« on: February 04, 2011, 07:58:13 pm »

I'm using 8.0 (864), and it works there.
First off, you need to select the text in the Note, then bring up the link dialog - if you try to add the link without having any text selected, you end up with nothing (like you describe). This is because the link itself is not displayed, it needs a text label - pretty much like HTML.

Here's what a note with a "Web Site" link looks like in XMI:
Code: [Select]
<packagedElement xmi:type="uml:Package" xmi:id="EAPK_768A8BCF_8565_45e8_8321_E16FD320A811" name="Link in Note" visibility="public">
    <ownedComment xmi:type="uml:Comment" xmi:id="EAID_AA4CC489_85C0_4ecb_A20B_D26E2F1723D5"
     body="Some text <a href="$inet://"><font color="#0000ff"><u>and a link</u></font></a>."/>

This is a note with the text "Some text and a link.", where the "and a link" part covers an http link to

Hope that helps.



Bugs and Issues / Size of Port in Component
« on: February 03, 2011, 02:49:57 am »

I'm working on a rather large and involved MDG Technology, and I'm bumping into a problem with Port sizes.

I create a Component (A) with a stereotype defined in one of my profiles, and then drop that Component onto a different Component (B), the resulting Port ends up huge - and I can't resize it.

I get the same result if I create the Port first and set its Property Type.

If I then change the Port's Property Type to a stereotype-less Component (C), the Port shrinks down to the regular size.

Anyone recognize this? Is there anything I can do to fix it?



Bugs and Issues / Connectors btw Component Instance Ports one-way
« on: November 24, 2010, 07:37:28 pm »

If you create two Components, each of which has a Port, and then create Instances of both Components (and display their Ports), you cannot draw a two-way Connector between the Ports: if you open the Connector Properties dialog, the Direction listbox is disabled.

This behaviour is consistent for all types of connector. If the connector Source or Target or both is a Port in an Instance, you cannot change the direction of the connector. I have also tested with Classes instead of Components; same result.
There is a workaround: draw the Connector between the two Instances, change its direction, and move the endpoints.

So my question is: is this a bug? I can't find support for this behaviour in the UML standard.



Pages: 1 ... 55 56 [57] 58 59 ... 72