Sparx Systems Forum

Enterprise Architect => Bugs and Issues => Topic started by: Uffe on April 01, 2020, 03:13:10 am

Title: Quick Linker and Activity diagrams
Post by: Uffe on April 01, 2020, 03:13:10 am
Hello,


Having done a bit of testing of the Quick Linker in 15.1.1527, which clearly I'm the first person to do, I've arrived at the following.

If you create a custom Activity diagram and reuse some of the contents of the vanilla toolbox, the non-stereotyped elements behave incorrectly.

Quick Linker definitions which have a stereotyped Action in the Source columns (A/B), the non-stereotyped element types in the Target columns (C/D) and a non-stereotyped ControlFlow in the New Link columns (H/I) do work.
This is true for ActivityFinal, Decision, ForkJoinH, ForkJoinV, Receive and Send.

Quick Linker definitions which have the non-stereotyped element types in the Source columns (A/B), a stereotyped Action in the Target columns (C/D) and a non-stereotyped ControlFlow in the New Link columns (H/I) don't work.
This is true for ActivityInitial, Decision, ForkJoinH, ForkJoinV, Receive and Send.

When the Quick Linker is used from one of the non-stereotyped elements to a stereotyped Action, in some cases the menu does contain a ControlFlow entry, but not the one specified in the Quick Link artifact (different New Link Caption).
This is true for ActivityInitial, Decision, ForkJoinH and ForkJoinV.

When the Quick Linker is used from one of the non-stereotyped elements to a stereotyped Action, in some cases the menu doesn't contain a ControlFlow entry
This is true for Receive and Send.

Having the Quick Linker definition in place appears to make EA create ControlFlows when instructed, and not Object Flows -- which it otherwise might, as discussed elsewhere.


/Uffe
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on April 01, 2020, 08:26:48 am
There are multiple problems with your definitions in a post 15.0 world. (When metamodel constraints were introduced)

First, quicklinker rules that specify exclusive to stereotype on a non-stereotyped element are discarded. This isn't related to metamodel constraints, it is just a fix because they break everything.

Second, I think that the quicklinker is won't see the rules from non stereotyped objects with non stereotyped connectors as adding anything to the base metamodel.

You are seeing the UML control flow rule to your stereotyped actions. Not sure why these aren't showing up from Receive/Send. Likely your situation didn't get the fix to treat them as actions.

I can't reproduce a Control Flow being created when an Object Flow was intended.
Title: Re: Quick Linker and Activity diagrams
Post by: Uffe on April 01, 2020, 10:24:13 pm
There are multiple problems with your definitions in a post 15.0 world. (When metamodel constraints were introduced)
There are no mentions of any breaking changes in either the version history, the Quick Linker manual pages, or the metamodel views manual pages for either 15.0 or 15.1.
There is no supporting documentation to show how to move from a quick linker definition to a set of metamodel constraints, and nowhere the slightest mention of any actual need to do so.

When I enquired about the quick linker issues I was having in 15.0, you told me to upgrade. Not a word about any "multiple problems with my definitions."
Now I've got 400 pissed-off users and an unknown number of broken models.

Quote
First, quicklinker rules that specify exclusive to stereotype on a non-stereotyped element are discarded. This isn't related to metamodel constraints, it is just a fix because they break everything.
This is news to me and to everyone else who reads the documentation.
But I've removed TRUE from the P columns of all lines which specify a non-stereotyped element type in the A/B columns. It still doesn't work.

Quote
Second, I think that the quicklinker is won't see the rules from non stereotyped objects with non stereotyped connectors as adding anything to the base metamodel.
Which is wrong.
When will that be fixed?

Quote
You are seeing the UML control flow rule to your stereotyped actions. Not sure why these aren't showing up from Receive/Send. Likely your situation didn't get the fix to treat them as actions.
What does that mean, my "situation"? What fix?

Quote
I can't reproduce a Control Flow being created when an Object Flow was intended.
It's the other way around. With strict syntax enabled, requests for Control Flows create Object Flows.


I've already asked IT to roll back the upgrade, citing the severe quality control issues at Sparx Systems. This also goes into the supplier due diligence database, btw.
But what is my path forward here?

Do I create stereotyped versions of Send and Receive?
Do I need to stereotype ActivityInitial, ActivityFinal, Decision, ForkJoinH and ForkJoinV as well?

Do I replace Send / Receive with SendSignal / AcceptEvent Actions?
What will then work differently?
Do I need to stereotype them?

Do I replace the quick linker definition with metamodel constraints?
How do I then achieve the intended result of Control Flows between all activity diagram elements, with a custom New Link Caption?
How do I specify metamodel constraints between my stereotyped elements and the non-stereotyped built-in activity diagram elements, including the non-action Send and Receive?

Do I wait for a fix from Sparx?
When will that come?
If one does come, what else will break?


/Uffe
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on April 02, 2020, 09:37:24 am
I understand you're upset. Probably embarrassed that you requested this upgrade and now you're having different issues. I am doing my best to help you.

I said that issues that you raised were fixed in 15.1. I have no insight into any other modelling you do within your organization. I have no way to tell that you have a custom profile, let alone what impact anything will have on your profile.

There are no mentions of any breaking changes in either the version history, the Quick Linker manual pages, or the metamodel views manual pages for either 15.0 or 15.1.

Here's one line that does.
Quote
Quicklink flag 'Exclusive to stereotype' will now be ignored for unstereotyped elements

That's not the only one in that little part of the release notes though.

There is no supporting documentation to show how to move from a quick linker definition to a set of metamodel constraints, and nowhere the slightest mention of any actual need to do so.
I don't think there is any need to do so. Yes, you get some extra functionality. Some that's just different.

If you want a metamodel rule to include your stereotyped actions as suggestions:

When I enquired about the quick linker issues I was having in 15.0, you told me to upgrade. Not a word about any "multiple problems with my definitions."
Now I've got 400 pissed-off users and an unknown number of broken models.
As previously mentioned, I have no insight into your usage of profiles.

I only have one such user. Not sure why you would have broken models. Nothing you have described so far would be a broken model. Worst case is that users need to use the toolbox to create connectors.

Quote
First, quicklinker rules that specify exclusive to stereotype on a non-stereotyped element are discarded. This isn't related to metamodel constraints, it is just a fix because they break everything.
This is news to me and to everyone else who reads the documentation.
To me it's surprising that anyone would expect it to work. It's exclusive to what stereotype?

Quote
Second, I think that the quicklinker is won't see the rules from non stereotyped objects with non stereotyped connectors as adding anything to the base metamodel.
Which is wrong.
When will that be fixed?
I'm sorry. I don't know. The rule that is there has worked well for all the users that have upgraded before you, with all sorts of profiles and quicklinker definitions.

Quote
You are seeing the UML control flow rule to your stereotyped actions. Not sure why these aren't showing up from Receive/Send. Likely your situation didn't get the fix to treat them as actions.
What does that mean, my "situation"? What fix?
All I mean is that a fix was made to processing of metamodel constraints to treat Receive/Send as specialized actions. (Which they are in UML 2) I don't know why they don't behave like other elements in your profile.

It's the other way around. With strict syntax enabled, requests for Control Flows create Object Flows.
My apologies. Both connector types were working as expected for me.

Do I create stereotyped versions of Send and Receive?
Do I need to stereotype ActivityInitial, ActivityFinal, Decision, ForkJoinH and ForkJoinV as well?

Do I replace Send / Receive with SendSignal / AcceptEvent Actions?
What will then work differently?
Do I need to stereotype them?

Do I replace the quick linker definition with metamodel constraints?
How do I then achieve the intended result of Control Flows between all activity diagram elements, with a custom New Link Caption?
How do I specify metamodel constraints between my stereotyped elements and the non-stereotyped built-in activity diagram elements, including the non-action Send and Receive?

Do I wait for a fix from Sparx?
When will that come?
If one does come, what else will break?
I'm sorry. I don't have answers for you. There's too much I don't know about your profile, your goals, the type of models you are creating. Is there any chance you could send in an official support request including your technology? That would help us to help you.

From what I can tell you do have workarounds. The main issue I can see is that the quicklinker isn't providing the option of creating your stereotyped action. You could create your action first then connect it, or you could create an action and then stereotype it. That seems like less of an issue than EA preventing flows to events without disabling strict connector syntax. But it's entirely possible I'm missing something.
Title: Re: Quick Linker and Activity diagrams
Post by: Paolo F Cantoni on April 02, 2020, 10:51:04 am
As I did on another forum,  I'm loathed to get involved here (believe it to not  :) ). But I'll make some observations.

As Uffe said, about the "Exclusive to stereotype"; that, too, was "news to me".  How could that be?  It was CLEARLY specified in the Release Notes!

Well, firstly, in the main, they are Release Bullet Points, not release notes - in my opinion.  It would be MOST useful if some of the changes (and this particular one IS a BREAKING change) were explained more fully with the impact elaborated.
Secondly, in any arbitrary release, for me - and I suspect most users- the majority, sometimes the VAST majority of changes DON'T apply to me, so I tend to skim them.  I don't know the answer to this, other than the previous proposal.
Thirdly, the changes are often couched in cryptic prose (some might think, I couldn't possibly say [1], deliberately cryptic).  In any event, I often struggle to understand the import and impact of what has been written.
Fourthly, unlike qwerty, I have noticed that some bugs that I've reported have been fixed, but it wasn't apparent - that is I didn't catch any mention in the release "notes".

It seems to me that perhaps, more informative communication from Sparx would be useful.  One solution (and which would increase Forum participation by the user base) is to add a more detailed narrative of the changes in the Forum thread that announces the release.  We (as users) can then add posts asking for any clarification, referencing the detail.  The communication needs to be less cryptic.

That's my thoughts on the matter.

Paolo

[1]  Francis Urquhart has a lot to answer for.
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on April 02, 2020, 11:35:26 am
I don't expect anyone to read the full release notes. I know they aren't always clear, I would hope that someone who manages a custom technology and skims the release notes would see a category called 'User Profiles and Technologies' and think it warrants closer investigation. The one item that's relevant to this discussion isn't even close to the only 'breaking' change in that category.

Quote
Save Package as UML Profile will now only use explicit sizes instead of the first diagram size found
Will result in no sizes being exported when they were previously.

Quote
User-defined profiles are now prevented from using the reserved name 'UML'
Yes, at least one user had been doing this.

Quote
Shape scripts will now draw alternate images with using alpha channel
We have had users in the past complain about the introduction of alpha channels breaking their diagrams.

Quote
New shape script print subsitutions: #SS# and #ES# substitute the start or end stereotype character(s) as determined by the "Use extended << and >> characters" option
If anyone had those sequences being printed in a shape script the result will be different.

Including the exclusive to stereotype change, there are three bug fixes and two new features that either could be or known to be breaking change to someone. That's just one small section of the release notes for one build. My point is, there are a lot of potentially breaking (https://xkcd.com/1172/)1 changes all the time. You just don't expect them to impact many people.

Personally, I wouldn't have expected anyone to use exclusive to stereotype filter without a stereotype. But if I read the documentation for that column, the result should be that the rule would exclude itself.

Quote
Set to True to indicate that elements of type 'Source Element Type' with the stereotype 'Source Stereotype Filter' do not display the Quick Linker definitions of the equivalent unstereotyped element.
According to that, if the source stereotype filter is empty, no definitions relating to that unstereotyped element will be displayed. The change just makes such an entry not corrupt the entire quicklinker menu.

1 Just to lighten the mood a little.
Title: Re: Quick Linker and Activity diagrams
Post by: Uffe on April 02, 2020, 10:04:12 pm
The bit about non-stereotyped elements in the quick linker A/B columns was in 13.0. My point was that there was no mention of any aspect of the quick linker not working with the introduction of metamodel constraints, which was 15.0. You said my definitions wouldn't work in a post-15 world. But I think you're on the wrong track there anyway.

The catastrophic bug introduced in 15.1 -- where EA creates Object Flows when told to create Control Flows -- is not related to the old style quick linker definition. It persists after I've removed all quick linker definitions from my technologies.

It is also not related to the quick linker itself. It's the same with a Control Flow in a custom toolbox: it creates Object Flows.

I've got an attribute  UML::ControlFlow = Control Flow  in a toolbox page. In many situations, but not all, EA interprets that as an Object Flow.
If I use the toolbox to draw a connector between a non-stereotyped ActivityInitial and a non-stereotyped Send or Receive, EA pops a menu, which includes ControlFlow, and when I escape out of that menu, EA says the requested connection is not UML compliant.

So what you get in that custom diagram when you request a Control Flow is sometimes a Control Flow, sometimes an option to create a different connector including a Control Flow, sometimes an Object Flow which is visually indistinguishable but which all my scripts, searches and document templates aren't looking for, and sometimes an Object Flow with auto-created ActionPins.

That's what I mean by an unknown number of broken models.

I don't have a workaround.

I can redesign my profiles to use metamodel constraints instead of quick linker definitions, and no doubt have to work around any number of bugs and undocumented features in that area as well, but EA creating Object Flows when Control Flows are requested is not something I can work around in the profile.

It all seems to boil down to two bugs.

1) In a custom activity diagram, EA doesn't handle Control Flows correctly when either element is a Send or Receive.
2) In a custom activity diagram, EA interprets requests to create Control Flows as requests to create Object Flows.

1 has been around since at least 13.5, which is why my quick linker definitions didn't include any entries for Send and Receive. I only added those back after upgrading to 15.1.
2 is new in 15.1.

Just so you understand, we upgraded from 13.5 to 15.0 to 15.1. (And are now downgrading back to 15.0.)
Title: Re: Quick Linker and Activity diagrams
Post by: skiwi on April 03, 2020, 07:31:02 am
I don't expect anyone to read the full release notes.

I for one always read the full release notes.
I would expect that many 'administrators' of EA in organisations would go through them with a fine toothed comb looking for changes that may affect the organisation, and changes that may advantage the organisation.


I'm all for too much detail, rather than too little.
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on April 03, 2020, 08:46:04 am
If you haven't been using object flows in your modeling at all, here's a custom sql search that will return the start object of all object flows. You can use that to go to each diagram and work out what should be there.

Code: [Select]
SELECT
t_object.ea_guid AS CLASSGUID, t_object.Object_Type AS CLASSTYPE, t_object.Name AS Object, t_object.Object_Type AS [Type],t_object.Stereotype, t_object.Author, t_object.Scope, t_object.Status, t_object.Phase, t_object.CreatedDate, t_object.ModifiedDate

FROM
t_object, t_connector

WHERE
t_object.Object_ID = t_connector.Start_Object_ID and t_connector.Connector_Type='ObjectFlow'

I will come back to this to offer more assistance when I get the chance.
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on April 03, 2020, 01:36:48 pm
The catastrophic bug introduced in 15.1 -- where EA creates Object Flows when told to create Control Flows -- is not related to the old style quick linker definition. It persists after I've removed all quick linker definitions from my technologies.

It is also not related to the quick linker itself. It's the same with a Control Flow in a custom toolbox: it creates Object Flows.

I've got an attribute  UML::ControlFlow = Control Flow  in a toolbox page. In many situations, but not all, EA interprets that as an Object Flow.
If I use the toolbox to draw a connector between a non-stereotyped ActivityInitial and a non-stereotyped Send or Receive, EA pops a menu, which includes ControlFlow, and when I escape out of that menu, EA says the requested connection is not UML compliant.
I believe you. It's certainly a problem, and if I could reproduce it I would already be trying to get it fixed. I just haven't worked out what I'm missing yet. It's bothering me now...
Title: Re: Quick Linker and Activity diagrams
Post by: Uffe on April 03, 2020, 08:17:14 pm
Well, since we've now rolled back to 15.0 I can't help any more than I already have.
I will be keeping an eye on the release notes, but will advise the client that with no fix in sight 15.1 is a no-go.
Title: Re: Quick Linker and Activity diagrams
Post by: KThiel on April 17, 2020, 03:45:06 pm
In build 1528 I also have these problems when trying to create an activity diagram with a control flow.
I can't even reproduce the ModelWizard in SysML Perspective suggested Activity with Actions and Control Flows.

to reproduce the buggs here are steps to get to them:
1.1) let the model wizard build the "Activity with Actions and Control Flows" pattern.
1.2) try to create with the quicklinker a control flow from the "activity initial" to the "1.1a: 1.1 Activity" action.
1.3) you will get the pop-up with "The requested connection is not UML compliant".

2.1) let the model wizard build the "Activity with Actions and Control Flows" pattern.
2.2a) try to create a control flow with the quicklinker between one of the actions, it doesn't show the option control flow.

2.2b) When you select control flow in the tool box and then drag a line between the actions, it creates an object flow with actionpins.

Hope this will help to solve this. I also do a roll-back to 15.0, can't work with this version.

Kind regards,

KThiel
Title: Re: Quick Linker and Activity diagrams
Post by: skiwi on April 20, 2020, 08:23:04 am
Please remember to report this officially as a bug report - see link at the bottom of this page
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on April 20, 2020, 08:49:47 am
Yes, Call Behavior Actions appear to be the missing link I didn't find on my own. We do have a correction and I'll be pushing for one to be released soon.
Title: Re: Quick Linker and Activity diagrams
Post by: Uffe on April 20, 2020, 08:20:17 pm
This is excellent news.

Can you please confirm that after this fix, EA will no longer create Object Flows when commanded to create Control Flows in each of the following cases:
There's a neat 2048 cases there, all identified as suspect from my bughunt. Since I don't know exactly what the problem was or what the fix entails, I can't say for certain that it won't reappear. And as I'm sure you will appreciate, I can't very well tell the client (the 400-user client) that they need to spend the money to test all of these.
Well I could, but they'd laugh me out of the room.

I can't tell you the amount of goodwill both Sparx and I have lost with this client as a result of this debacle. The client is in no mood to spend any more money on this problem, and is increasingly of the opinion that EA as a whole just isn't worth it.

If I can't get a hard confirmation that we don't need to test this fix, my only remaining recommendation to the client is to stay on 15.0 while a different tool is sourced.
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on April 21, 2020, 08:57:50 am
We have been able to reproduce only one situation where an Object Flow was created instead of a Control Flow. Where either object was a Call Behavior Action with the behavior specified and strict connector syntax is enabled.

In addition, where the source was such a CallBehaviorAction the quicklinker didn't offer the option of Control Flow.

I can't give a "hard confirmation" anything else will be fixed because we haven't reproduced reproduced the error. No amount of tests will confirm we've fixed an issue we can't reproduce. Right now if a developer gave me such a promise I would probably very unprofessionally yell at them. If we can reproduce other situations where it could happen before release then I'll be able say if they will be fixed too.
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on May 21, 2020, 04:23:22 pm
My understanding is that the issue reported here is corrected in 15.2, including finding the situation where the "old" event elements created the wrong connectors.

https://www.sparxsystems.com/products/ea/15.2/index.html (https://www.sparxsystems.com/products/ea/15.2/index.html)
Title: Re: Quick Linker and Activity diagrams
Post by: Richard Freggi on May 22, 2020, 12:16:26 am
There are multiple problems with your definitions in a post 15.0 world. (When metamodel constraints were introduced)

First, quicklinker rules that specify exclusive to stereotype on a non-stereotyped element are discarded. This isn't related to metamodel constraints, it is just a fix because they break everything.

Second, I think that the quicklinker is won't see the rules from non stereotyped objects with non stereotyped connectors as adding anything to the base metamodel.

You are seeing the UML control flow rule to your stereotyped actions. Not sure why these aren't showing up from Receive/Send. Likely your situation didn't get the fix to treat them as actions.

I can't reproduce a Control Flow being created when an Object Flow was intended.

Hello Eve

can you expand on your statement on the "post-15 world" and share any links to documents as to how EA 15 is materially/practically different from 13?  Especially metamodel changes got my interest.

The reason is that I am evaluating upgrading to 15 from 1310, but of course having to spend 3 weeks looking for moved menus is a major drawback, and also the benefits of V15 compared to V13 are not enough for me (based on the announcement and release notes).  No sarcasm, I'm asking in all honesty because this is a topic I need to stay current on for my work, so thanks for any guidance!
Title: Re: Quick Linker and Activity diagrams
Post by: Eve on May 22, 2020, 10:58:57 am
In 13, your profiles had no control over what was a valid relationship. They would be validated with the base types of each end and the connector. (Or not at all depending on the user settings) All you could do was define the list of relationships that you wanted to show in the quicklinker.

Now, any profile can specify valid relationships between its stereotypes. Or even the relationships to base UML elements and other profiles.

Those valid relationships are used to build a quicklinker that shows a list of appropriate relationships. Where "appropriate" includes by default that anything new being created is expected to be on that diagram (as determined by the toolbox). This does cause some change in behavior even for old style quicklink definitions. Not everyone is a fan, but it also provides means for end users to define their own specialized diagram (view) types, that the original authors of a technology didn't have to know about.

It's even possible to add valid relationships to the UML behavior (a common use of this is to allow ControlFlow between Activities, which was never legal UML but EA allowed) or to prevent some (by using a restricted perspective)