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 ... 3 4 [5] 6 7 ... 85
61
Bugs and Issues / Re: HTML Report Not Working In Google Chrome
« on: April 26, 2018, 06:31:14 pm »
Hello,


If you're generating HTML it's probably because you want to make models available to people who don't use EA. This implies that you're in a reasonable-size organization.

If that is the case, it's worth considering setting up a web server to serve the EA-generated HTML. You probably already have a web server on your intranet, in which case you just need to add a publication area where you can write the generated HTML and the server can read it.

Not only will this obviate the need for people to circumvent a security feature of their web browser, it will also provide better performance: a web server is far more adept at dealing efficiently with HTML than a file server is. If you're generating large chunks of HTML, and if you're making them available on a WAN, this performance boost will be significant.


/Uffe

62
Bugs and Issues / Re: ActivityParameter _instanceType not honoured
« on: April 26, 2018, 06:14:54 pm »
Unless I'm mistaken, _instanceType is only used for stereotyped Classifiers when dropping from the project browser onto the diagram.

Well, you may be right but if so then that isn't documented anywhere. And while ActivityParameter is not in itself a classifier type it acts as one for ActionPins, so the expectation that an ActivityParameter _instanceType should apply when creating an ActionPin is a reasonable one.

Strangely, it seems _instanceType has been deprecated. Except, no, it hasn't.

Quote
On the other hand, the version 14 metaconstraints are more flexible and powerful.
http://www.sparxsystems.com/enterprise_architect_user_guide/14.0/modeling_tools/metamodelconstraints.html

I don't know how it's going to go for Activities with Parameters. But for classifiers containing ports it can create the appropriate stereotypes on the slots of an instance based on the classifier and slot rule types.

Well, considering that action pins are pretty poorly implemented in the first place, I'm not holding my breath. The more I tinker with these, the more it looks like they're in need of a serious overhaul.

/Uffe

63
Bugs and Issues / ActivityParameter _instanceType not honoured
« on: April 25, 2018, 07:12:11 pm »
Hi all,

If you create two stereotypes, one of ActivityParameter and one of ActionPin, and specify that the parameter stereotype should be instantiated to the pin stereotype using the _instanceType attribute in the ActivityParameter metaclass, that specification is not honoured when EA creates an action pin during instantiation of an activity with parameters.

AFAIK there is no other way to instantiate an activity parameter. You can't drag-and-drop one onto an empty diagram area, nor onto an action.

Reported.


/Uffe

64
Bugs and Issues / Language in activity parameters and action pins
« on: April 25, 2018, 06:58:30 pm »
Hi all,


When you create an activity parameter in a diagram, the parameter's Language property is set to the project's default regardless of the corresponding properties in the diagram and the activity.

If you create the parameter in the Structural Elements dialog, the behaviour is the same.

The behaviour is also the same for action pins in actions, both when created from the toolbox and in the Structural Elements dialog.

When an action pin is created as the result of instantiating an activity with paremeters, the pin is likewise given the project default Language.

When an activity parameter is created, its Language should be set to the same as its parent activity's.
When a pin is created manually, its Language should be set to the same as its parent action's.
When a pin is created as an instance of a parameter, its Language should be set to the same as the corresponding parameter's.

Reported.


/Uffe

65
General Board / Re: Aris vs EA for Process Modelling
« on: April 25, 2018, 06:11:29 pm »
... it felt like people arguing whether baseball bats or tennis rackets were the best tool... the answer of course depends on what game are we playing?

This is probably the best way of making this point that I have ever heard. I'm gonna steal it.

Quote
So I would focus efforts on getting maximum clarity on what your client wants to achieve and how they want to achieve it - then the tool choice should be straightforward.

Yeah... Good luck with that. ;)

/Uffe

66
General Board / Re: Show activity numbering in diagram?
« on: April 24, 2018, 11:23:57 pm »
Hello,

As Geert explains, numbering is tricky in activity diagrams.

If numbering of things is a key point you want to communicate, you might want to consider using a communication diagram in addition to your activity diagrams.


/Uffe

67
Bugs and Issues / Actions in toolboxes
« on: April 24, 2018, 09:05:52 pm »
Hi all,


If you specify a toolbox which includes the following attribute definition

Name: UML::CallBehaviorAction
Initial Value: CB Action

... the resulting toolbox creates CallBehaviorActions correctly, but the icon is incorrect. Instead of the standard action icon, the stereotype icon (from the Profile toolbox) is displayed.

If instead you define the toolbox attribute as

Name: UML::CallBehaviorAction(UML::Action)
Initial Value: CB Action

... the correct icon is displayed.


Also, while the user guide page on elements used in toolboxes omits CallOperationAction (but includes CallBehaviorAction), you can in fact specify a CallOperationAction in your toolbox, and it works as expected.

Both reported.


/Uffe

68
Well the each-element-no-more-than-once-in-each-diagram thing appears to be pretty fundamental in EA, and I don't think we're going to see that change anytime soon.

Virtualized connectors is a workaround that's been provided to get around this limitation for certain use cases. If you're not in one of those use cases, it won't work for you and you're relegated to EA's core functionality: when diagrams get unwieldy due to the once-per-diagram limitation, work with separate diagrams or instances of elements.

And as I always advise my clients, basing a method of working or a tool adaptation on something other than the core functionality of that tool is precarious at best. You're taking on risk that way, and reality has a tendency to bite.

/Uffe

69
In brief: no.

But you can usually achieve the desired result using instances or activity parameters.

/Uffe

70
Bugs and Issues / Re: Time-aware models: revert clone
« on: April 24, 2018, 04:46:36 pm »
Notwithstanding that the cloning mechanism is for our use (notionally), I could practice what I preach and open up a "crowd-sourced" requirements and use case thread - to help us specify what the mechanism should do and how it should behave.

I'm in!

/Uffe

71
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

72
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

73
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

74
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

75
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

Pages: 1 ... 3 4 [5] 6 7 ... 85