Author Topic: EA Element class .Elements  (Read 8435 times)

Hurra

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
    • Find me at LinkedIn!
EA Element class .Elements
« on: March 08, 2018, 02:00:57 am »
Hello!

I am building a rather complex document spanning down four levels and collecting various neighbouring elements.

I have run into a problem, which I first thought might be a bug, but probably is some error in the code.

I start the documentation with a diagram with elements. For each element I get child elements with the built in sections: package>element>child elements>, and then continue with a custom script.

Quote from: enterprise architect user guide: EA Element Class
Elements

Collection

Notes: Read only

Returns a collection of child elements (sub-elements) attached to this element as seen in the tree view.

Collection Class

I had no problem continuing the document documenting relevant neighbours and further child elements. However, we added a child diagram which caused problems and I don't understand why. According to the documentation elem.Elements should only collect child elements, not all childs like child diagrams.

The strange thing also is that some elements which have child diagrams have correct documentation, but one element with child diagram only generates correctly if the child diagram is removed.

Snippet of the code which cause error SOMETIMES when there is a child diagram:
Code: [Select]
element = Repository.GetElementByID( objectID );
childElems = element.Elements;
for ( i = 0; i < childElems.Count; i++ )
{
currentElement = childElems.GetAt( i );
relatedRoles = getNeighbour( currentElement.ElementID, "stereotype", "ArchiMate_BusinessRole" );
if ( relatedRoles.length == 0 )
{
...
}
...
}

I think the problem is that childElems sometimes include a child diagram. Is that even possible??

Any help where to start debugging is appreciated! Perhaps it is enough to add
Code: [Select]
if ( childElems.Count == 0 )
? But I doubt that is the problem since there are child elements..
always learning!

Hurra

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
    • Find me at LinkedIn!
Re: EA Element class .Elements
« Reply #1 on: March 08, 2018, 02:22:10 am »
childElems has length 6 although there are only 5 child elements, and 1 child diagram.
always learning!

Hurra

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
    • Find me at LinkedIn!
Re: EA Element class .Elements
« Reply #2 on: March 08, 2018, 02:30:12 am »
Code: [Select]
Script Trace - CWIX 2017 has 6 childs
Script Trace - Element: CIWX 2017 IPC, stereotyp: ArchiMate_BusinessCollaboration
Script Trace - Element: CWIX 2017 ESC, stereotyp: ArchiMate_BusinessCollaboration
Script Trace - Element: CWIX 2017 EXE, stereotyp: ArchiMate_BusinessCollaboration
Script Trace - Element: CWIX 2017 FCC, stereotyp: ArchiMate_BusinessCollaboration
Script Trace - Element: CWIX 2017 MPC, stereotyp: ArchiMate_BusinessCollaboration
Script Trace - Element: , stereotyp:

Where does the extra empty element(?) come from??

Notice that this is the only element with this problem. Other elements with child elements and diagrams documents fine.

When I change location of the diagram, i.e. no child diagrams, it runs fine. But other elements with child diagram runs fine as well...
« Last Edit: March 08, 2018, 02:36:37 am by RWHurra »
always learning!

Uffe

  • EA Practitioner
  • ***
  • Posts: 1859
  • Karma: +133/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Re: EA Element class .Elements
« Reply #3 on: March 08, 2018, 03:15:54 am »
Diagram objects, ie elements which appear only in diagrams and not the project browser, are represented as regular elements with a row in t_object. Could it be that you've got a Note or a Boundary or something in your child diagram?

I'm not sure whether diagram objects are in fact stored in Element.Elements for a diagram in Element.Diagrams -- it might be they're in Package.Elements for the nearest-up package. But it's worth a check.

Not sure what you've got in your trace there, but try printing the .Type and .Subtype.

HTH,


/Uffe
My theories are always correct, just apply them to the right reality.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: EA Element class .Elements
« Reply #4 on: March 08, 2018, 03:28:25 am »
No, in my experience .Elements only contains elements.
But that is easy to verify in the database.
Just list all t_object where parentID is equal to your parent element ID.

Most likely the 6th element is something like a note, diagram legend, hyperlink,... i.e. an element without a name. That would also explain why it goes away if you remove the diagram. Some elements (such as diagram legends) are seen as "owned by the diagram" and they will always move together with that diagram.

Also possible is that you have a integrity issue. Try running the project integrity check and see if that solves something.

Geert

Hurra

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
    • Find me at LinkedIn!
Re: EA Element class .Elements
« Reply #5 on: March 08, 2018, 07:16:53 pm »
Thank you Geert and Uffe!

The problem was that we had a <Diagram Notes> in the diagram. I removed it and ticked "Show Diagram Details" instead, works like a charm again!

I guess there is no built-in solution to only get "real" elements. I have to to a for loop to check type/sub-type?
always learning!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: EA Element class .Elements
« Reply #6 on: March 08, 2018, 07:30:21 pm »
I guess there is no built-in solution to only get "real" elements. I have to to a for loop to check type/sub-type?

No, mainly because there's no generally agreed on definition of "real" I guess.

Geert

Hurra

  • EA User
  • **
  • Posts: 183
  • Karma: +0/-0
    • View Profile
    • Find me at LinkedIn!
Re: EA Element class .Elements
« Reply #7 on: March 08, 2018, 10:46:53 pm »
No, mainly because there's no generally agreed on definition of "real" I guess.

Geert

There is no spoon.
always learning!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8607
  • Karma: +257/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: EA Element class .Elements
« Reply #8 on: March 09, 2018, 10:35:20 am »
I guess there is no built-in solution to only get "real" elements. I have to to a for loop to check type/sub-type?

No, mainly because there's no generally agreed on definition of "real" I guess.

Geert
We define some types of objects (such as Diagram Notes, Hyperlinks, etc.) as support objects.  Avoids the problem of real objects.

We denote them in special reference tables and use that in our background processing queries.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Uffe

  • EA Practitioner
  • ***
  • Posts: 1859
  • Karma: +133/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Re: EA Element class .Elements
« Reply #9 on: March 09, 2018, 09:22:44 pm »
I prefer diagram-only elements or non-browser elements.

Since object is in fact an element type, I always avoid using that word to describe anything else.
(Leaving aside the fact that elements are referred to as objects in the EA database schema -- t_object, t_objectproperties, .Object_ID, etc. Consistency!)

/Uffe
My theories are always correct, just apply them to the right reality.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13404
  • Karma: +567/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: EA Element class .Elements
« Reply #10 on: March 09, 2018, 09:40:47 pm »
I prefer diagram-only elements or non-browser elements.

Since object is in fact an element type, I always avoid using that word to describe anything else.

Element also has another meaning in UML. Almost anything in UML is an Element (except for diagram, tagged values, and maybe a few other things), but they are not all stored in t_object.

So I prefer the more neutral Item as a term.

Geert

Uffe

  • EA Practitioner
  • ***
  • Posts: 1859
  • Karma: +133/-14
  • Flutes: 1; Clarinets: 1; Saxes: 5 and counting
    • View Profile
Re: EA Element class .Elements
« Reply #11 on: March 09, 2018, 11:17:23 pm »
Element also has another meaning in UML. Almost anything in UML is an Element (except for diagram, tagged values, and maybe a few other things), but they are not all stored in t_object.
In UML, yes. But EA is less an implementation of the UML metamodel and more of a UMLish tool.
Quote
So I prefer the more neutral Item as a term.

You're not wrong, but you do then introduce a new term into the conversation. If your audience is up to speed on UML and EA then well and good, but if they're struggling with the conceptual side of things it can confuse more than it helps.

I guess what I'm saying is "it depends." :)

/U
My theories are always correct, just apply them to the right reality.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8607
  • Karma: +257/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: EA Element class .Elements
« Reply #12 on: March 12, 2018, 10:39:23 am »
I prefer diagram-only elements or non-browser elements.

Since object is, in fact, an element type, I always avoid using that word to describe anything else.

Element also has another meaning in UML. Almost anything in UML is an Element (except for diagram, tagged values, and maybe a few other things), but they are not all stored in t_object.

So I prefer the more neutral Item as a term.

Geert
You may have noticed (apart from my deviation previously) that I've started using item also.  Item defines an identifiable member of a set; which describes the situation exactly.  It is a natural language definition, irrespective of any modelling language.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!