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

Pages: 1 ... 12 13 [14] 15 16 ... 18
196
Bugs and Issues / Activity simulation: input and arguments
« on: February 22, 2012, 12:17:45 am »
Hi!


I'm fiddling about with some model simulation.

Invocation actions are executed correctly, ie they cause the defining activity (classifier) to be run through the simulation.

Is there a way to display the parameter values as set on the invocation action?
If not, is there another way to achieve the same sort of thing, possibly using different model elements?

Also, I am able to specify an input for the simulation, but that doesn't seem to do anything. Is the input used for anything and is there a way to display it during the simulation?

Cheers,


/Uffe

197
Bugs and Issues / Read-Only package: how?
« on: February 15, 2012, 12:07:07 am »
Hey all,

I was just flipping idly through the version history, and came across a reference to making packages read-only, introduced in 9.0 (909). Sounds great - except I can't seem to find how to set this property.

It's not in the package's general properties nor in the advanced properties, I don't see it in the Properties window nor is there a tagged value for it, and I can't find an option for it in any context menu.
Searching through the help file, weeeelll... that just gets you a lot of hits in the automation section.
So.

I know I'm being a complete dunce here, but please - how do I set a package read-only?

Cheers,


/Uffe

198
Bugs and Issues / Database engineering: Views
« on: February 04, 2012, 01:17:39 am »
Hi!

Investigating a potential issue (separate post), I am trying to create a simple database model with a view.

I create a table, then a view and a dependency from the view to the table.
The help file says that when I next open the view's properties, "The tables are now listed in the Dependencies field".

Uhm - no they're not.
What's wrong?

I'm using 9.0.905.

Cheers,


/Uffe

199
Bugs and Issues / Reverse-engineer DB2 Views
« on: February 04, 2012, 01:09:08 am »
Hi!

When reverse-engineering a db schema, do I get anything meaningful in terms of Views?
I am asking on behalf of a user who is attempting to reverse a DB2 schema. A <<view>> Class is created, but it seems to have no relationships nor a textual definition.
We're using 9.0.905.

Cheers,


/Uffe

200
Bugs and Issues / Requirement stability
« on: January 09, 2012, 08:06:23 pm »
Hi all,


Quick question: an internal requirement (ie one created in an element's Requirements tab) has a Stability. Requirement elements as created from the Common toolbox do not.

If I create an external requirement from an internal one, what happens to the Stability?

Cheers,


/Uffe

201
Bugs and Issues / Individual vs project settings
« on: January 05, 2012, 06:22:39 pm »
Hello chaps and chapettes,


Here's one that might have escaped your notice.
If you link connectors to attributes and then reroute them manually, adding some ctrl-Q corners, then change the sort order in the options, your diagram is completely screwed up.
It seems EA stores absolute positions for the corners, not their positions relative to the attributes they're connected to.

This wouldn't be much of a deal if it wasn't for the fact that in a team setting, each modeller can set their sort order individually. And yes, there are several workarounds, but this highlights a deeper issue with EA: some settings are per-user, some are project-wide, and some are per-user-and-project, and it is not entirely clear which are which.

I would like to see this more clearly indicated, somewhere in the help file if nothing else. I realize this is a long-term, bit-by-bit kind of a thing, but it would really help with larger-scale deployments where the project administrators might be new to EA themselves.

Comments?


/Uffe

202
Bugs and Issues / Ports, embedded elements and children
« on: January 03, 2012, 09:21:11 pm »
Hi all,


Let's say I create a Component with a Port which in turn provides an Interface.
I then create an instance of that Component. If I then select the Port in the instance and ask to create another provided Interface, EA says I can't "add embedded elements to locked or checked-in elements."

However, I can delete the inherited provided Interfaces.
I can also create a new Port, move the inherited provided Interfaces to it, then delete the original Port and add additional Interfaces to my new Port.

This behaviour is the same for a Generalization of the original Component.

So my question is: is this a bug? Why should I not be allowed to add Interfaces to an inherited Port when I can delete Interfaces from it?

Cheers,


/Uffe

203
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.


Thoughts?


/Uffe

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


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?

Cheers,


/Uffe

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


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.

Cheers,


/Uffe

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


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?

Cheers,


/Uffe

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

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?

Cheers,


/Uffe

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


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?


Cheers,


/Uffe

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


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.

Cheers,


/Uffe

210
Bugs and Issues / MDG Technology: Tagged Value Types not imported
« on: September 17, 2009, 05:14:15 pm »
Hi!


I've constructed a fairly large MDG Technology with a few dozen stereotypes, toolboxes, diagrams, code generation templates, and MDA transforms.
These all work when I import them (using Settings - MDG Technologies).

I have also defined a few Tagged Value Types, which are used in some of the stereotypes. These do not get imported with the MDG Technology.

I am definitely using the MDG Technology creation wizard correctly. I have checked and the type definitions are clearly present in the MDG XML file.
I have also verified that if I copy the definitions manually from the project where they're defined to the project where the MDG Technology is imported, the tags in the stereotypes which use them work instantly with no need for restart or refresh - so the definitions are syntactically correct (I use some Custom ones for things like six-digit strings etc).

Has anyone else observed this behaviour? Is there a simple fix?


Cheers,

/Uffe

Pages: 1 ... 12 13 [14] 15 16 ... 18