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.
You could also say it’s a prototype model.Good thought! Maybe a Metatype diagram, since that’s what’s going to be on it!
You are making prototypes of the concepts to illustrate their usage.
Geert
It wasn’t trouble, merely a gentle correction.I take a very rigorous approach to nomenclature. I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym. I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.I know, and was aware I could get in trouble by using a less rigorous approach to nomenclature. But I will blame the forum’s poor search engine for not allowing me to quickly find one of the posts where we discussed this in the past. Perfectly happy with “nesting” meaning physical nesting, and using “visual embedding” to describe the ability to move an item in or out of another item on a diagram. Having said this, Sparx EA doesn’t do “visual embedding” very gracefully at times.
I agree with your point about the searching capability. Why is searching SO hard (as a functionality)? It’s not just here that one can criticise the searching as being less than optimal. Anyway, another gentle correction (to myself, not the least), Nesting doesn’t actually apply to physical nesting; it applies to referential or access nesting - as I have indicated in the past, nesting defines the namespace of the meronym - in other words, you have to access the higher level items to get to the lower level item (x.y.z). The physical nesting in the browser is just a manifestation of that concept.Also, “nesting” is really a form (de-)composition, but AFIK, there is no relationship for it in any modelling language I am familiar with. Is this not the same as representing “car” as a group of interrelated elements - e.g., engine, wheels, chassis, body, and so on - or a one element with (physically) nested elements?Yes, you are correct, it is a form of composition, but from the point of view of accessing the item via its FQN. We use the Nestign Connector as described in the User Guide:
As Guillaume and I have shown, no redesign of the browser is required; all that is required is to redesign the concept in our brains. It is easy enough to implement.
2 - From a usability point of view, the package browser, which is essentially a physically nested structure (almost an extended folder structure), often makes collaborative work on a single repository difficult and leads to unwanted data duplication. The collaboration problem would be easier to solve if a view, a Sparx EA view, could be constructed showing how elements are/or could be visually embedded. If the browser could be hidden for certain users, this view could serve as the main entry point for work by some of the users we typically collaborate with. After all, some relationships are a natural visual embedding: specialisation, aggregation, and composition.Since we gave away the notion of the browser indicating any form of holonymy, we basically haven’t had that problem. Only items that require referential nesting are nested. All other items are in a "flat" structure (by type). The diagrams are in a separate branch of the repository and can be structured however you like. Consequently, we don't have as much of a problem as you do.
We can indeed use Guillaume’s solution. I think I used it once in the past.I take a very rigorous approach to nomenclature. I reserve the term “nesting” for physical nesting, in which the identity of an item depends on its holonym. I use the term “Visual Embedding” to describe the ability to move an item into or out of (just as important) another item on a diagram.The Standard says: (4.5.1 Grouping)As noted by Paolo, in a much more sophisticated language, the issue with the way this is implemented is that, from memory, it is not possible to draw aggregations and compositions between a grouping and the elements it groups.
“The grouping element is used to aggregate or compose an arbitrary group of concepts, which can
be elements and/or relationships of the same or of different types.”
This, of course, brings to the forefront the way the browser was designed and implemented —and one of Paolo’s favourite subjects: visual nesting vs. physical nesting (Paolo, sorry for paraphrasing).
The issue is that the browser enforces physical nesting, meaning an element can exist only in one package or as a composite of another element—i.e., it can have only 1 parent element (package or standard). This means, the same version of an element can only exist once in the browser. I suspect Sparx Systems sees implementing the ArchiMate grouping, which could be argued is a form of visual nesting (not physical nesting), as a complete redesign of both the browser and the underlying data model; something they may not want to undertake.Not quite; Grasshopper... The ArchiMate Grouping is a Holonym (either an aggregate or composite - as required), consequently, the convention of suppressing the holonymic relationships when visually embedding applies. That is, the impetus is reversed from what your statement implies.
I've recently become a user of Enterprise Architect again after several years away and this was the first pain point I ran into when trying to change the line style of my connectors.“Noice!”
I found a workaround for my (Data Model) case:
- Select all diagram elements (Ctrl + a)
- Open the "Relationships" window
- Multi-select the relationships/connectors that you want
- Right click - change line style
A key challenge in the Sparx Systems implementation of both the UML Package and the ArchiMate Grouping element is the conflation of an element’s type with its role as a container. This design choice, while pragmatic in some respects, restricts the ability to create relationships to or from the container itself and other “proper” elements, fundamentally complicating modelling efforts such as the one described by the OP.I basically agree with Modesto (surprise, surprise! ) with a few, hopefully minor, caveats (see below). We also used Guillaume’s solution to create our own Grouping Element (with a set of supporting scripts).
(my emphasis)I've had the same experience. It's a great timesaver if you know what the result should look like.This seems to be the problem with all AI tools: if you know what you are doing or what you are expecting, they can be a good productivity tool. If you don’t, they just generate rubbish.
If you have no clue, it might be very time-consuming to figure out where exactly it goes astray.
Geert
I downloaded the Lieber c4 model from Sparx websiteCiao Fausto,
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
Interesting, this is very specific and a very Sparxian solution was implemented. A simple select statement can be posted, please below.(my emphasis)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.
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)
I found the issue. I had defined the toolbox item asYes, 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)
- 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
Hi Viking,
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.
).Who said the Dutch were blunt?Such a sad imageI 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...
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
