Quick Linker and Activity diagrams

[Uffe]

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

[Eve]

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.

[Uffe]

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.

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.

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?

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?

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

[Eve]

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.

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:

• Add the ControlFlow metaclass to your profile
• Create two metaconstraint connectors from it to your action stereotype(s)
• Set the umlRole properties to source and target
• When your profile is imported that will add your stereotype(s) to the valid types.

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.

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?

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.

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.

[Paolo F Cantoni]

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.

[Eve]

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.

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.

User-defined profiles are now prevented from using the reserved name 'UML'

Yes, at least one user had been doing this.

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.

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

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.

¹ Just to lighten the mood a little.

[Uffe]

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

[skiwi]

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.

[Eve]

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.

[Eve]

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

[Uffe]

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.

[KThiel]

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

[skiwi]

Please remember to report this officially as a bug report - see link at the bottom of this page

[Eve]

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.

[Uffe]

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:

• Element types: any combination of
  
  • unstereotyped ActivityInitial (source only)
  • unstereotyped ActivityFinal (target only)
  • unstereotyped Decision
  • unstereotyped ForkJoinH
  • unstereotyped ForkJoinV
  • unstereotyped non-action ("red") Send
  • unstereotyped non-action ("red") Receive
  • stereotyped Action with kind CallBehavior
  • stereotyped Action with no defined kind
• Diagram types:
  
  • built-in Activity diagram
  • customized Activity diagram
• Creation method:
  
  • toolbox connector icon
  • quicklinker
• Quicklinker definitions:
  
  • no custom definitions
  • metaconstraint custom definitions (ie not the deprecated spreadsheet-like RTF definitions)
• Filter to Toolbox:
  
  • enabled
  • disabled
• Strict Connector Syntax:
  
  • enabled
  • disabled

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.