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] 2 3 ... 81
1
Bugs and Issues / CallOperation actions, action pins and exceptions
« on: April 23, 2018, 09:34:26 pm »
Hi all,


If I create a CallOperation, regardless of whether I've assigned an operation to it, I can't create my own action pins for it. That's OK, the intent is that CallOperation actions should be linked to operations, and the "Synchronize with Parameters" function in the properties dialog (in the Call tab) allows me to create pins for the operation's parameters.

But what if I want to create a pin for an exception?

An operation's parameters cannot be exceptions. There's no exception property to select. What you can do is add "raised exceptions" to the operation in the properties dialog, Redefines tab.

An action pin, on the other hand, can be an exception. There's an "Exception" property on a pin, and selecting it causes the pin to be displayed differently in diagrams (with an added triangle).

See where I'm going?

I can't manually add pins to a CallOperation action.
The CallOperation action's "Synchronize with Parameters" only creates action pins for the operation's parameters, not for its raised exceptions.
Pins can be exceptions, but operation parameters can't.

So.

How do I represent visually the call to an operation which throws exceptions?


/Uffe

2
Hi all,

The default display of a CallOperation action looks a bit like this:
              ActionName
    InterfaceName::OperationName


Or, if the action's name is the same as the operation's (which it is by default):
        ActionAndOperationName
           InterfaceName::


I've been testing a bunch of parameters in a custom shape script, but I can't seem to get at the interface name: neither the classifier.* nor the  propertytype.* properties give me what I need. (Classifier shows the operation name, but only until I close the diagram; when I reopen it, it's blank.)

Is there a hidden property that contains the "classifier" operation's parent element?


/Uffe

3
Bugs and Issues / Re: Time-aware models: revert clone
« on: April 23, 2018, 07:23:08 pm »
This is indeed a serious and very useful discussion. 

My conclusion - steer clear of time aware modelling for the foreseeable future.
Well I think Paolo hit the nail on the head further up: what exactly is a clone supposed to be?

What is "cloning" supposed to mean for a package structure, a diagram, an element? Or even an element feature or tagged value, although I for one would happily accept the element as the smallest cloneable entity.

It seems like the only considered use case has a package with no child packages, and a bunch of elements which each occur in exactly one diagram. If that is the case, then that's a good start and extending the solution to take more complex use cases into account should be doable.

But as it is, TAM is not yet ready for prime time.


/Uffe

4
Bugs and Issues / Re: Time-aware models: revert clone
« on: April 23, 2018, 06:45:02 pm »
I wasn't clear enough.  My point applies to BOTH sequential and parallel streams.  Each clone knows the predecessor clone, but NOT which version it was cloned from!

Say I have versions 1 to 5 in the model and the diagram I am using to clone has #2.  When I say clone to a new version it will place #5 on the diagram.

Now it doesn't know it came from #2 - so it can't revert to #2.  I'm not sure that reverting to #4 is what you're after.

I'm still not in complete agreement, but I think I see the problem here.

When you clone an element in a diagram, EA only replaces the predecessor with the clone in that diagram. I was unaware of this. This means that in a derived version of a model, you can have some diagrams with the clone and some with the predecessor (or not even "the" but "a" predecessor, chaining all the way back to the original).

This is insane.

If when cloning, the predecessor were replaced in all diagrams in the version of the model where the cloning takes place, and new relationships were created accordingly, the situation where both a clone and a predecessor are shown within the same model version could not arise. (At least, not without deliberately breaking the model.) And thus, reverting becomes possible.

Serious discussion! but just wondering how about a baseline of the source and the target packages before cloning, and use that to revert back? ideally automated, but in absence of which can it be a manual effort?

Only if the baseline functionality becomes time-aware.

At present, even with the best possible setup for baselines and TAM to coexist (a package which holds the baselines and only contains the original model package and its TAM clones, with no TAM clones existing outside that package), you can't use the baseline comparison function to see that one element is a clone of another. You only see a new element (the clone), with a new connector to a changed element (the predecessor).

The restore from baseline function would probably also need to understand what a TAM-clone is, and there would certainly need to be a specific "revert" or "un-clone" menu item.

Again, my basic point is that TAM is not integrated with other EA functions, and it shows.


Y'know, the more I look at this the more this whole thing looks like a concept demo that was deemed good enough for a trade show which somehow got shipped with no consideration for the fact that EA elements exist independently of diagrams -- one of EA's core features.


/Uffe

5
Bugs and Issues / CallOperationActions in project browser
« on: April 20, 2018, 10:04:54 pm »
Hi all,


A CallBehaviourAction is displayed with its classifier in the project browser on the form action_name : classifier_name.
A CallOperationAction, on the other hand, doesn't display its operation.

Shouldn't it?

Something like action_name : element_name::operation_name, where element is the interface, class, component or whatever that holds the operation?


/Uffe

6
If you create a stereotype for Action and assign it a shape script which prints the Classifier or Classifier.Name property, the expected behaviour for a CallOperationAction is that the name of the operation (when set) is printed. It is not.

When you set the action's operation, the name of that operation is printed -- but only until the diagram is closed. When next it is opened, nothing is printed although you can still Find the operation from the action.

It appears that classifiers defined by the GUID string and not the integer ID aren't handled correctly by the shape script engine.

/Uffe

7
If you create a stereotype for CallOperationAction on the fly, then assign it a shape script in Configure -- UML Types, and then create a CallOperationAction in an activity diagram and give it that stereotype, the shape script is not executed.

If you modify the stereotype to apply to Action, it is executed correctly on the same CallOperationAction.


/Uffe

8
Oh, and I found that if you've got the situation I had above, then select the non-cloned package in the cloned diagram and hit Clone Element as New Version, the old package is replaced by the new one in the diagram, and subsequently, the Clone Element menu item is greyed out.
As per my previous comments in the other TAM posts, I suspect it's working correctly.  Since the requirement for the initial clone of the diagram is to NOT clone any vertex, it is incumbent upon the user to determine which vertices to clone (including folders).
I'm not convinced. The way it works, the package has been cloned, but the original is shown in the cloned diagram.
Why would you want that?

Only reason I can see is that the cloned package doesn't contain any elements so you need the original in order to show package contents. But that only makes sense in the first generation anyway, so this is still more bug than feature in my book.

Still, if you're aware of it you can fix it immediately after parthenogenesis.1

/U


1 That's "creating a clone", children.

9
Bugs and Issues / Re: Time-aware MDG Technology models
« on: April 20, 2018, 06:49:05 pm »
Yes, and I agree with you, but there was also something that specifically didn't work when you exported from the diagram. Wish I could remember what.

OTOH, if you want to reuse a toolbox page between toolbox profiles you've got to export from the diagram. Unless they've done something with that in recent versions?

/Uffe

10
Bugs and Issues / Re: Time-aware models: revert clone
« on: April 20, 2018, 06:43:41 pm »
As far as I'm aware there's not.  I can also tell you why (I think).  In my topic on TAM where I discuss sequential versus parallel cloning; when you clone an early version which has subsequent versions, you get the latest version ONLY.  The cloned element has NO memory of where it was cloned from and so you can't revert.  It doesn't know which version to revert to.

Ah, but it does -- I'm reverting to the previous version. I'm not talking about parallel branches here, just a basic "undo check-out" if you will, of a single element.

The element I'm reverting has the special-dodgy-kludgy trace connector to its predecessor. Which diagrams that predecessor is in is easily checked, so restoring those occurrences to the cloned diagrams (where the predecessor has been replaced by the clone) should be no harder when reverting than when cloning the diagram in the first place.

I'm fully prepared to accept that you can't revert an element which has already been cloned in turn (ie has an inbound special-dodgy-kludgy trace relationship), but you should be able to back up from the head.

Amirite?


/Uffe

11
Bugs and Issues / Re: Time-aware MDG Technology models
« on: April 20, 2018, 04:52:26 pm »
Hi Paolo, and thanks for taking the time. I was hoping you would. :)

MDG Technology development is my use case for time-aware exports. Rather than using the diagram's context menu item to generate a profile (which isn't an XMI export, but still an export of sorts) I've always used the project browser's.1

Being able to maintain TAM-style version-controlled MDG Technology models would be useful, but it would require that profile generation from cloned models included the non-cloned elements.

I should mention here that I haven't tested generating a profile from a TAM-cloned diagram, which might well work. My overall point is that the TAM functionality should be better integrated, and the generate-profile-from-browser function is an example of how it isn't.2


/Uffe


1There was something that didn't use to work when you used the diagram's menu. I can't remember what now and I don't know if it's ever been resolved but the two menu items did not yield the same result (!) (!!) (!!!!) (why isn't there an emoji with its hair on end?) so I went with the one that worked for me.

2Also I'm pretty much making this up as I go.

12
Bugs and Issues / Re: Custom Script fragments not working in 13.5.1352
« on: April 20, 2018, 04:08:23 pm »
Aww.... Killjoy.  :'(

13
General Board / Re: Where are user passwords stored?
« on: April 20, 2018, 12:46:49 am »
Ha!

I was gonna say, as a joke, "it's probably in t_xref." :)

/Uffe

14
Oh, and I found that if you've got the situation I had above, then select the non-cloned package in the cloned diagram and hit Clone Element as New Version, the old package is replaced by the new one in the diagram, and subsequently the Clone Element menu item is greyed out.

FWIW.

/Uffe

15
Yeah, it's looking that way from my perspective too. Kind of a cool demo feature, but it doesn't seem to have been integrated in any meaningful way, it doesn't support multiple branches and it doesn't seem to be possible to revert changes.

I'm trying to imagine what use case it's been designed for, but I'm coming up empty. It looks like something put together by someone who's never actually worked with version control or configuration management.

/Uffe

Pages: [1] 2 3 ... 81