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 - Paolo F Cantoni

Pages: [1] 2 3 ... 543
1
General Board / Re: Control flows and object flows
« on: May 09, 2022, 09:45:06 pm »
What selection criterium did you use? You'll have to make sure your object flows are included in your selection.
I have tried with Filter set to Connector - None, Connector - Type, or Connector - Stereotype, and Applies to set to ControlFlow or ObjectFlow depending on the type. The end result is always the same, no change.
Hey Modesto,
Are you able to get the Legends working with ANY connector?  I have a sneaking recollection that they don't actually work with connectors[1].  Perhaps others can correct me.  I just checked our common legends and NONE apply to connectors, only shapes.

HTH,
Paolo

[1] Perhaps, another case of connectors being second class citizens?
No, it works for connectors as well. (at least in v15.2.1559)
We use that to indicate the lifecycle on our architecture diagrams for both elements as connectors.

Geert
MyBad, then.  Sorry!

However, I would still suggest testing the legend on other connector types and on other machines.  One of our machines behaves anomalously and so we first confirm any anomalies we find on other machines before reporting a defect.


Paolo

Paolo

2
General Board / Re: Control flows and object flows
« on: May 09, 2022, 09:17:00 pm »
What selection criterium did you use? You'll have to make sure your object flows are included in your selection.
I have tried with Filter set to Connector - None, Connector - Type, or Connector - Stereotype, and Applies to set to ControlFlow or ObjectFlow depending on the type. The end result is always the same, no change.
Hey Modesto,
Are you able to get the Legends working with ANY connector?  I have a sneaking recollection that they don't actually work with connectors[1].  Perhaps others can correct me.  I just checked our common legends and NONE apply to connectors, only shapes.

HTH,
Paolo

[1] Perhaps, another case of connectors being second class citizens?

3
General Board / Re: ArchiMate instance of class
« on: May 09, 2022, 09:10:52 pm »
Hi Jim,
I would recommend re-reading (and attempting to absorb) my post #9. in the original thread, you referenced.  I believe it contains the solution to the problem. Note especially my final comment about standards...

We decided to create a modelling environment that works rather than one that adheres to standards that don't actually work.  However, it DOES require that you actually think about what you are trying to do rather than blindly follow "authority".  Yes, if you look at many of my posts, I DO hold contrarian views.

HTH,
Paolo

4
General Board / Re: Archimate instance of class
« on: May 09, 2022, 02:38:26 pm »
I don't think I've looked at it at all since that discussion.

From memory, ArchiMate is a bit weird. I believe it actually recommends modelling instances as a specialization of the type. So if you have an instance of 'Data Owner' that you want to model, you create a new Business Role with a specialization to Data Owner.
That's, effectively, how we went.  Our placeholder items are generalizations of specific items.  However, we have TWO kinds of specializations:  (the more common) inheritance (IS A TYPE OF) and restriction (IS WHERE). The specific items are restrictions on the placeholders.  You can consider the placeholders the equivalent of a query "A Data Owner is an X where".  If the specific item meets the query requirements, then it is a restriction on the placeholder.

Works REALLY well for us!

HTH,
Paolo

5
General Board / Re: Stereotype Properties _AttPri, _AttPro, etc
« on: May 08, 2022, 06:40:45 pm »
AH, its amazing what a good rant will do for you.
About 10 minutes after I finished the last post I realised what I had done wrong.
The _AttPkg, etc attributes are inverse from the others (i.e. 1 = hide).

All working nicely, now onto the next bugs :-)

Thanks guys :-)
Concistency, konsistency, consistensy! TMUffe - after Paolo
and...
Manage Complexity,
   .   .   Reduce Ambiguity,
   .   .   .   .   Eliminate Inconsistency!
TM


Paolo

6
General Board / Re: Stereotype Properties _AttPri, _AttPro, etc
« on: May 07, 2022, 09:52:46 am »
Hi Jays,
Is this the exported XML from the MDG generation or a handcrafted one?
If the latter, try generating from an MDG model to see what EA creates. What you've done looks OK, but occasionally, as we know, EA has surprises "up its sleeve".

Paolo

7
According to the documentation, setting it back to -1 should work: https://sparxsystems.com/enterprise_architect_user_guide/16.0/add-ins___scripting/diagramobjects.html

Quote
BackgroundColor

Long

Notes: The background color of the object on the diagram.

Set to -1 to re-set to the default color in the model.

So if that doesn't work it's officially a bug.

Geert
+1


Paolo

8
Bugs and Issues / Re: Automatically Added Relations in Diagrams
« on: May 03, 2022, 01:16:45 pm »
Thanks, Geert! To answer your question: We are currently in requirements capture. If relationships from other requirements diagrams appear here, it will disturb rather than help. Later in the requirements analysis, of course, all relationships must be taken into account, but in our current phase, we would like to freeze the diagram for the time being.

Regards,
Bernhard
Hi Bernhard,

Freezing diagrams can be tricky.  Sparx has created a "Freezing mechanism" but it is only for "visible connectors".  We found that for us, we needed to "freeze" more than just connectors.  However, the built-in functionality may be enough for your needs.

There are also related issues to model evolution and diagram "snapshotting".

HTH,
Paolo

9
Confirm it's not been fixed. I'm surprised, to be honest as they've taken so long to release V16 I thought they would have fixed that. That bug will prevent my organisation from upgrading as we use an MDG to extend ArchiMate. What is interesting is that the extra label doesn't appear on all ArchiMate extended objects so it points to some inconsistent coding.
Very disappointed this hasn't been fixed.
(my emphasis)
You said it!  I thought I had given sufficient information for the problem to be tracked down and eliminated (unless, like the VCE problem, there's a fundamental design problem).

I would've thought getting inheritance correct in this area would be crucial for making EA more flexible AND CONSISTENT!

Paolo
Sparxians,
Is this recognised as a defect?  If so, will it be re3ctified?  It DOES seem to point to a serious problem in the background.


Paolo

10
Bugs and Issues / Re: EA v16: MDG Technology for MS Office is missing
« on: April 24, 2022, 10:07:03 am »
As per Sunshine's response.  If you install the 64-bit version, you'll find it doesn't follow the release notes about where to place the 64bit AddIn information.  If you add that info manually, it enables the Addin.

HTH,
Paolo
Well tried installing the 64-bit version this weekend however like potterm I can't see it in Sparx EA V16 64 bit, as doesn't seem to see it.
What do you mean by the above comment? Looked at release notes and am not sure what you mean by adding that info manually. what info and how?
Sporry folks, I wasn't explicit enough.  I installed the 32-bit version first and then the 64 -bit.  Thus there was a registered Addin in the 32-bit world (which I checked with 32-bit EA).  I then copied the 32-bit entries manually to the 64-bit Registry path and an Addin showed up in the 64-bit EA.  I didn't test it out.

HTH,
Paolo

11
Confirm it's not been fixed. I'm surprised, to be honest as they've taken so long to release V16 I thought they would have fixed that. That bug will prevent my organisation from upgrading as we use an MDG to extend ArchiMate. What is interesting is that the extra label doesn't appear on all ArchiMate extended objects so it points to some inconsistent coding.
Very disappointed this hasn't been fixed.
(my emphasis)
You said it!  I thought I had given sufficient information for the problem to be tracked down and eliminated (unless, like the VCE problem, there's a fundamental design problem).

I would've thought getting inheritance correct in this area would be crucial for making EA more flexible AND CONSISTENT!

Paolo

12
Bugs and Issues / Re: EA v16: MDG Technology for MS Office is missing
« on: April 23, 2022, 10:11:50 am »
Thought I saw two new Office MDG on the download page. One for 32bit and the other for 64bit.
As per Sunshine's response.  If you install the 64-bit version, you'll find it doesn't follow the release notes about where to place the 64bit AddIn information.  If you add that info manually, it enables the Addin.

HTH,
Paolo

13
General Board / Re: Scriptlets - Resources for EA 16
« on: April 23, 2022, 10:07:56 am »
Scriptlets look interesting. https://sparxsystems.in/scriptlets-in-enterprise-architect-16-a-step-beyond-static-view/

Have any users used them?  What are your thoughts on their utility?

Are they only available for JavaScript or can other scripting languages be used?

TIA,
Paolo

14
...Hopefully, Sparx put some priority on this as we can't release v16 for general use without it.
Ditto
Well, looks like the v16.0 official release (1604) hasn't fixed the problem. 

Sunshine are you also able to confirm the problem still exists?

Paolo

15
Virtual Connector Ends solves one problem. That showing all connectors to the exact same shape can end up complicating the diagram unnecessarily. Instead, the element is being represented by a second shape allows you to simplify one or more lines.

It's not a general attempt to represent an element multiple times. If you want to have an unconnected element shown on the diagram, drop a diagram containing that element and hide the frame.

Because they exist only to simplify the layout of the relationships, it doesn't make sense for them to ever be displayed without those relationships. So, any method that results in the shape being drawn without the line (or disconnected from the line) is the problem.
But as skiwi (and others including myself) have observed, the VCE shape can't be made to look like the original shape.  Notwithstanding the original intent, the outcome is that there are multiple copies of the same element on the diagram.  The consequences of that were not (apparently) thought out properly.  Given that it is currently possible by two separate methods to create an unattached duplicate shape, it is further proof that the design is inherently flawed.  I accept that others might say that Sparx can't write code that works, but in my view, this is a case of bad design.
Further, I'd submit that if you actually asked the users, they might agree that we would see not being able to create the unattached by one of the three common methods by which connectors can be suppressed as the bug.

As I've said many times, I'm using EA in spite of EA, NOT because of it!

A slightly different design and implementation could have solved not just these problems, but many others.  In the other thread, you mentioned Sparx considered creating additional diagram objects, suitably identified as VCEs, but it was rejected because of the problems it caused.  I still debate that, it seems such a straightforward thing to do  (and indeed, for my part, when I created my first VCE I went looking in t_diagramobjects looking for it).  Could it be that another flawed design makes such a straightforward solution impractical?

Paolo

Pages: [1] 2 3 ... 543