Book a Demo

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 ... 574
1
I downloaded the Lieber c4 model from Sparx website
I tried to change the appearance of some stereotypes changing the attribute cx, cy and bgcolor inside the XML file before loading into EA
Changed cx and cy are taken into account but the bgcolor change don't work
I weant only to change the default appearance when the stereotype is created living the user the option to modify
thanks for your answer.
Fausto
Ciao Fausto,
The usual reason for this behaviour is that the shapescript contains a statement overriding the "default" value shown in the XML file.
Remember the definition of "default" is:  "In the absence of a countervailing instruction, do this...".  Unfortunately, the shapescript - hidden in the base64 encoding - contains that "countervailing instruction".  It would appear the shapescript doesn't have an override for the cx and cy values.
HTH,
Paolo

2
General Board / Re: Can no longer post SQL Statements to this forum
« on: July 17, 2025, 08:11:41 pm »
Interesting, this is very specific and a very Sparxian solution was implemented. A simple select statement can be posted, please below.

Code: [Select]
SELECT * FROM t_object
But any statement starting with anything other than a SELECT statement cannot be posted.

SQL statements for most RDBMS do not have to start with a SELECT statement. A plea to Sparx Systems, please address that at least in the forum and, if possible, in the software.
(my emphasis)
Not necessarily, Modesto.  SQL injection is usually used to make some change to the database (i.e. delete it). SELECTS don't do that, so they are allowed.  It may be a more generic setting in the Cloudflare system.

My AU$0.05
Paolo

3
The dataverse is a semantic layer and I don’t think it can be reverse-engineered, which is what the database builder does.  Curiously, according to Microsoft, it can be explored/queried using SQL Server Management Studio.
(my emphasis)
It's the OLD you have  to use/buy OUR tools to do stuff...

Paolo

4
I found the issue. I had defined the toolbox item as
- ArchiMate_Realization(UML::Realization)
But in after looking in the MDG technology for ArchiMate 3, I found that the stereotype ArchiMate_Realization was actually an extension of UML Dependency, and not of UML Realization.
After changing my toolbox item definition to
- ArchiMate_Realization(UML::Dependency)
The problem was solved.

Geert
Yes, I've been caught by that kind of "discrepancy" before.  Can you see any rationale for this?  (not blaming Sparx, just observing anomaly in the standard)

Paolo

5

Hi Paolo,

Could you tell me please why VCEs are the correct way to manage multiple copies of elements on a diagram? How tells us that only an element can be represented only once on a diagram?

Issues are in fact: no possibility to resize, and not possibility to not use rectangle notation.

V.
Hi Viking,
I agree with your points about the issues regarding the VCEs. In essence, they aren't first-class diagram objects. I can't see why they couldn't have all the attributes of a standard diagram object and, indeed, have an entry t_diagramobject (with an indicator to say the item is a VCE)—which they don't at present.  In addition, their behaviour when arcs are suppressed must be the standard behaviour.

Now, to my reasons for believing VCEs are conceptually the correct way to achieve the ends of multiple instances of the SAME item on the diagram.

Firstly, we must agree that we deal with a diagram as a model view.  Consequently, only one instance of an object is in a given state in the model.  (See what I did?  I allowed multiple occurrences in different states - as with TAM ;) ).

Why do we put model items onto a diagram?  It is because they are related in some way.  The modelling technology that you use may not be able to express these relationships, but they exist nonetheless.  In addition, there are relationships that EA chooses NOT to express via t_connector entries but by other means.  In our technology, we surface all such relationships that we are interested in (including those implied by visual embedding).  Consequently, their relationships are notionally visible when we place items on a diagram.

If, for whatever reason, we wish to place more than one instance of the same item on a diagram, we are implicitly saying that (at least) one of those relationships) can be attached to the instance!
Similarly, that statement implicitly requires that the instance has access to all the item's inherent properties (but separate display properties if needed).

So far, so good.

The tricky part is deciding which relationships need to be assigned to the VCE and which to the original item, since there may be more than one. The current implementation only allows one, but conceptually, that may not be the case.  Still, the current implementation is good enough, mainly since we suppress relationships that don't have a diagram in most of our use cases.

To summarise, VCEs provide a conceptually valid vehicle for allowing multiple instances of the same item in the same state on a single diagram while preserving the integrity of the underlying model.  However, to resolve the outstanding issues, they need to be closer to first-class citizens of the diagram than they are at present.  Similarly, the diagram-specific connectors need to be enhanced to indicate which instance they will be connected to.  Lastly, both the vertices and arcs ned to be fully manageable from a rendering perspective to allow the modeller full expression.

Thoughts?
Paolo

6
General Board / Re: SQL Queries, Connectors, and 'Find in Diagram'
« on: May 21, 2025, 08:39:40 am »
I wouldn't get too excited just yet. AS CLASSTABLE was introduced a couple of years ago, and I haven't seen much change yet in the treatment of connectors.

I'll put the party balloons back in the bag...
Such a sad image :'(

In dutch we have a saying feels applicable: "Iemand blij maken met een dooie mus", which translates to "To make someone happy with a dead sparrow"

Geert
Who said the Dutch were blunt?    ;)
(I know Geert is Flemish)

Paolo

7
By now, I would have confirmed that the problem exists in v17.0 or v17.1.

Just a thought,
Paolo

(Experience has shown that to get any traction on a defect, it must be present in the latest version)

8
This request has been made already several times, e.g., https://sparxsystems.com/forums/smf/index.php/topic,26866.msg221902.html#msg221902. But I could not find an answer.

EA has evolved to a great EAM-tool. When I am asked for the biggest disadvantage of EA I mention the missing ability to represent an element multiple time (“doublets”). This is key in Enterprise Architecture Management. Multiple Connector Ends is not an appropriate solution.
•   Will EA support doublets and if so, when?
•   If not, why not?
Hi Viking,
Can you explain why Virtual Connector Ends (VCEs)  aren't appropriate for your needs?  You may recall that I have many issues with VCE rendering, but I have also noted that I think, in principle, VCEs are, conceptually, the correct way to manage multiple copies of elements on a diagram.


Paolo

9
Hi Mitch,
in the DB, the Default value is the "Default" column.  Try #Default#".

HTH,
Paolo

10
Bugs and Issues / Re: Timeaware Modeling TMA - bug in version 17 ?
« on: March 20, 2025, 06:20:03 pm »
Thank you, Viking.
So the issue with V17 is that it is no longer possible to bring cloned elements into the same diagram as their clones using the "Insert Related Elements" option. Conceptually, I can see why that is not desirable. But Practically, I am not that sure. Ultimately, I would like to have a time-aware gap modelling diagram, something possibly very similar to what Paolo is referring to.

"Clone Element as New Version" does not create a trace relationship in version 17 (1). The consequence is also that "Insert Related Elements" cannot be used because the trace relationship is not there (2). So, (1) is the root cause.
So, is that by design or a regression bug in v17?  If the former, what is the rationale?  If the latter, when will it be fixed?

Paolo

11
Bugs and Issues / Re: Timeaware Modeling TMA - bug in version 17 ?
« on: March 19, 2025, 02:16:58 pm »
Hi,

As my other post for your post, EA now does not create a Trace connector between the TAM objects. At least, I am sure that this is not a bug.

For the TAM feature, I think this behaviour (we cannot add the TAM objects by the Insert Related Elements feature) is reasonable since the 'same' TAM objects in the different timeframes should not be in the same diagram.
(my emphasis)
Hi Takeshi-san,
We have the 'same' TAM objects on the same diagram all the time.  We have developed Transition diagrams to show how one item 'evolves' over time.  It also allows us to make sure that all the items involved in the transition are correctly accounted for.

Do you have some theoretical reason for the statement?
Just interested,
Paolo

12
I know its an old thread, but the following is relevant to something I am working on:

Query usys_system.Default_Diagram. It should contain the guid of your diagram

Which table is that? I can only find tables that begin with t_

I am looking for where the default diagram is set within the repository tables.

Phil
Hi Phil,
It's in t_xref, Name=DefaultDiagram, Type=element property
IIRC, there's also a linkage in PDATAn  (if you're thinking of manipulating things directly).


HTH,
Paolo

13
One thing I discovered is that the issue of element text not being printed appears to be connected to whether or not the diagram has been set to the diagram setting "Scale to 1 Page". If this is not set it appears to print okay. Weird right?
I think I've observed some issues with diagrams "Scale to 1 page", but I can't recall what they were (or, obviously, which diagrams were affected).  We print our diagrams so rarely now...

Paolo

14
General Board / Re: Linking Connectors to Diagrams
« on: January 15, 2025, 09:45:57 am »
Paulo,

Many thanks for your insights. Let me put your mind at rest - I am very clear on the difference between model and diagrams.  I didn't want to bore you all with the details but I am constructing a very detailed model with views surfaced in various diagrams (you do actually have to look at something eventually.

To assist those consuming the model, almost every element is a composite element linked to a diagram showing more implementation detail concerning that element.  Simple, easy, built into the tool.  What I would like to do is extend that to connectors, "composite connectors" if you will.  The reason for this is my model is organised into multiple layers of abstraction.  At the top, a simple connector showing an integration between two elements may, at a more detailed level, have a more complex structure.  I would like to link a diagram showing that view to the more abstract connector.  Simple problem looking for a solution.  Any thoughts?
Ahh, Hicholas,
now I can see what you are trying to achieve!  As Geert says, you want to create a composite diagram for a connector - to show how a single connector at one level is, in fact, multiple connectors at a lower level.
We have the same (and related issues).  We solved it by using the fact that EA now allows relationships between relationships.
We assert that a relationship can be derived from other relationships via a Derivation relationship.  We have various forms of derivation (by traversal, by union, by specialization etc.).  This will allow you to model the concepts you want.  By creating a diagram with the vertices involved in the derivations; the canonical and derived relationships, and derivation relationships, you effectively get the composite diagram for the high-level connector!  In your case, a simple composition relation between the high-level and lower-level relationships may "do the trick".

Does that help?
Paolo

15
General Board / Re: Linking Connectors to Diagrams
« on: January 14, 2025, 12:36:45 pm »
Does anyone know if I can link a connector (between two elements) to a diagram?  I have searched everywhere (well, many places ;D ) but can find no information.  Can it be done? If not, any alternative suggestions are welcome.
Hi Niocholas,
I don't understand what you are asking. Perhaps some structural input from me can help clarify your question.
Firstly, we are dealing with a model - the model is held within the database.  A diagram is simply a view into the model that shows whatever shapes and lines the modeller wishes.  The lines and shapes on a diagram should be selected to make whatever point (indeed a viewpoint) the modeller tries to make through the diagram.

Consequently, neither the shapes nor the lines belong to any specific diagram.  Indeed, the default mechanism is that when you add a new relationship between two shapes on one diagram, the relationship will also appear between the same two shapes on any other diagram in which the two shapes appear together.

Does that help?
Paolo

Pages: [1] 2 3 ... 574