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

Pages: [1] 2 3 ... 8
1
Quote
Quote from: wikitect on August 29, 2023, 04:31:02 pm

    I've not yet tried IBD, Parametric, Package or Sequence.

Then why are you telling me my statement is incorrect?

I can only base my statement on what I've verified by evidence i.e. the non-apperanace of customised BDDs under the SysML1.5 heading. I've since confirmed the same with the IBD.

You said

Quote
Quote

    It was/is still possible to create the view specifications. They appear under the diagram type in the SysML category and you can select the view from the properties for the diagram.

i.e. ingoring the problem identified - custom BDDs not appearing under the SysML1.5 heading. They don't as I stated in my original post hence if you then state that they do - this is the incorrect statement. Quoting my statement that I'd not yet tested other types of SysML diagram has no bearing on the one type (BDD) for which the point was made. Quoting that doesn't support any argument is odd.

Clearly it isn't working - it shows under the technology heading - so the profile is correct.

It doesn't, however, show under the older SysML.15 heading - same profile extending the same SysML stereotype which - when visible and used creates a SysML BDD.

And similarly with the IBD...

2
I'd much rather not be. The trouble is in building profiles semi-regularly I'm spending a lot of time in the fringes of stuff that most EA users hardly encounter. Perhaps I ought to be given a discount as I won't feel so inclined to spend when on a pension soon...

3
And support have confirmed that a customised UML Class diagram created using a View Specification also doesn't show in the New Diagram dialog.

SysML BDD, SysML IBD and UML Class diagram affected. How did this get through testing?

4
Just tried an experiment wrt the other SysML diagram types.

As there's nothing listing the SysML Diagram names to use for extension I normally create a vanilla one and look at the properties to figure out the name.

  • SysML Package - 'SysML1.4::Package'
  • SysML Parametric - 'SysML1.4::Parametric
  • SysML Sequence - 'SysML1.4::Sequence'

all appear correctly in both the technology and SysML1.5 headings.

But - SysML Internal Block Diagram - 'SysML1.4::Internal Block' only appears under the technology heading. It too, like the BDD, does not appear under the SysML1.5 heading.

Anyone therefore on v15 is unable to see / select / produce a customised SysML BDD and a SysML IBD.

On v16 the additional technology heading does list everything so there is a workaround. The bug is still present however.



5
Oh - and for good measure the Extension connector shows nothing in the Traceability pane when either of the pair of elements selected that are connected using this connector. As a result I always have to use an additional Dependency between  View Specification and SysML stereotype.

6
Support ignored the bug identified.

Quote
It was/is still possible to create the view specifications. They appear under the diagram type in the SysML category and you can select the view from the properties for the diagram.

Not true. This is true for Requirement, Activity, UseCase and StateMachine - not Block Definition. I've not yet tried IBD, Parametric, Package or Sequence.

As I said

Quote
The SysML 1.5 heading doesn’t, however, list the custom technology SysML BDDs under the SysML1.5 > ‘BlockDefinition’ subheading - only Sparx’s own offerings (other SysML customisation such as Requirement Diagram, Activity Diagram do appear).

There is a bug. Selecting the SysML 1.5 heading only lists: the basic SysML technology and the UAF. It does not list any of the 21 custom BDDs I've defined using View Specifications - not something I'd miss. Luckily in v16 there is the additional technology heading where all of the SysML diagrams are listed. Not so for the SysML 1.5.

7
This is a gotcha.

You can only produce custom SysML diagrams using view specifications.

On v 15 however there is only the SysML 1.5 heading in the new diagram dialog from which to create SysML diagrams. The SysML 1.5 heading doesn’t, however, list the custom technology SysML BDDs under the SysML1.5 > ‘BlockDefinition’ subheading - only Sparx’s own offerings (other SysML customisation such as Requirement Diagram, Activity Diagram do appear).

The net result is that it is impossible in v15 to produce a customised SysML BDD from a technology.

In v16 it is possible because there are additional technology headings and the BlockDefinition subheading does list the customised BDDs.

This bug has clearly been around for some time.

8
When a diagram is deleted, any Diagram Hyperlinks (created when dragging a diagram onto the open diagram) that previously linked to the deleted diagram are not themselves deleted even though they no longer serve any purpose.

This results in an accumulation of non-functional (dead) hyperink elements if you don't spot the fact - and there's nothing provided to expose this litter.

The rationale provided is that a user might want to restore a diagram via an XMI import which seems to be a much lower level frequency use case than deleting a diagram that is the target of diagram hyperlinks.

As this is deliberate policy tools ought to be provided e.g. a search to reveal these so that the user can find and delete them.

9
Eve it's not a conspiracy but it is reliably and repeatedly ignoring the qualifying namespace of the stereotype - but only where the (unqualified) stereotype name already exists within a default set.

That's the problem. It is not reliable or repeatable on my end. The only time I succeeded to reproduce your behavior was when the rule generated on the profile generated a reference to a stereotype that didn't exist.

Every single stereotyped relationship is fully qualified. The same stereotypes used and referenced in the quicklink are used in view specifications and dragging from the resulting toolbox creates elements with the correct fully-qualified stereotype i.e. it's not stereotypes being unable to be found.

In terms of the lookup (which is a default behaviour and because it is systematic wrt lookup there are default defacto values even if they aren't defined as such ) a) why does it ignore whether a technology is enabled or not; which leads to b) is it only possible to mitigate by finding and temporarily moving them to another folder so they cannot be used as a source? Or do I guarantee what I want by renaming the technology so it appears at one end of the list and therefore the first to be looked within...?

10
Eve it's not a conspiracy but it is reliably and repeatedly ignoring the qualifying namespace of the stereotype - but only where the (unqualified) stereotype name already exists within a default set.

There is something special about the stereotypes because as I understand it EA will no longer accept an unqualified stereotype name and therefore it will add the (missing) profile name using a known profile that contains the stereotype name. EA therefore has some definition of a default profile which it can apply to ensure that stereotypes are fully-qualified. For whatever reason it's incorrectly applying it during creation using Quicklink.

I am not using nor have enabled any of the profiles which I've seen applied by EA on quicklink stereotype creation. They do not exist in any of the profiles I create. The profile name is very definitely not missing.





11
It's a possible mitigation but the faulty mechanism is still present - at best it will (possibly) prevent it from being executed. I say 'possibly' because I don't have any technology other than the basic set enabled and it's not clear that EA is even looking at local technologies rather than assigning a default based on a simple internal look-up. We just don't know.

I've also not checked to see whether it occurs using the older CSV-based method of defining Quicklink but I can't remember seeing elements with unexpected appearances be created (which is the immediate indicator that the stereotype is incorrect).

In some cases it is impossible to manually correct the stereotype once created - the only option is to manually create by dragging off the toolbox (which correctly implements the same fully-qualified stereotype).

This problem with ignoring/transmuting the fully-qualified name also manifests in part of the CSV import.

12
More default (Borg) stereotypes incorrectly applied to fully-qualified stereotypes using quicklink:-

  • Module - transmuted into FML::Module
  • Feature - transmuted into TOGAF::Feature
  • Product - transmuted into BIZBOK UML Profile::Product

13
Yes. The Quicklinker definition is fully qualified but Sparx EA ignores this for these stereotype names in preference to its internal Borg technologies.

There is a similar problem on importing from CSV under certain circumstances.

14
So far the troublesome stereotype names used by the internal Borg Collective discovered using Quicklink definitions to create TRAK:: stereotypes:-

  • Concern (transmuted into UAFP::Concern)
  • Event (transmuted into TOGAF::Event)
  • Project (transmuted into UAFP::Project)
  • Standard (transmuted into TOGAF::Standard)
  • Vulnerability (transmuted into RiskTaxonomy::Vuln)

15
Don’t worry on that score. Two submitted wrt this particular behaviour.

Just curious about what other stereotype names might suffer similar problems.

Pages: [1] 2 3 ... 8