The Project Tree

[sargasso]

Is there any documentation or help or otherwise around that explains the structure of the project browser tree?

To explain, what I'm looking for is something that details exactly what the parent/child positioning in the tree actually means within EA.

Obviously, I'm not talking about the package/element relationship or about element features (attributes, operations) but more about elements that are dragged to become children of other elements.

Now we are at ver 4.0 these positional issues seem to be a lot more important/relevant than before.  

Bruce

[thomaskilian]

Hi Bruce,
in what respect do you think that there has changed something? Still I see no difference to 3.6 - it's just the hierarchical position of an element that changes. Or did I miss something?

Cheers, Thomas

[klatchy]

Hi Thomas, Bruce

Is there any way that we can set the heirarchical position of the element using the Automation interface?

For example, I would like to add some elements to an exisiting element, but as child elements.

Currently I am using AddNew() on the parent element's Elements collection (heh.. that looks confusing). But after Update() and Refresh() the new children do not seem to be showing up in the project tree view at all.

I created some of my own elements in the actual EA application to experiment. I structured them hierarchically and noticed that child elements appear in both the package's Elements collection and in the Elements collection of their parent element. This has me confused, should I be adding the new child element to the parent element's Elements collection or the package's Elements collection

Any advice would be much appreciated!

Thanks,

Ian

I started a related thread at http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=Automation;action=display;num=1082417487

[sargasso]

Hi Bruce,
in what respect do you think that there has changed something? Still I see no difference to 3.6 - it's just the hierarchical position of an element that changes. Or did I miss something?

Cheers, Thomas

One immediate example - if you place an enumerator class as a child of a C# class, EA now generates the enumerator as an internal in the parent class source file automatically.  I didn't think this happened in 3.6? but I'm not complaining about it!

I am trying to compile a list of "things" the heirarchy does (amongst other 10^6 things Iam trying to do).  I was looking to see if anyone else has any information that could save me some time.

For example - what effect does placing a state machine model's diagram and elements under the involved class do? anything? nothing?  ....  :-/

Consider the class powersupply, it has two states ON and OFF - in the ON state the only sensible exposure is to method TurnOff, similarly for the OFF state the method is TurnOn. Very simple to model as a state machine.  Suppose we do it this way:
1. in our designclass model create class "powersupply"
2. set it as a composite element
3. doubleclick the element - this opens the child "Composite structure diagram".
4. ignore the diagram type
5. add the two states "On" and "Off"
6. add the methods "TurnOff" and "TurnOn" to the respective states as DoActions
7. add a state transition from On to Off and another from Off to On (since we are not allowed to have bi-directional state transitions   )  set the Trigger for both of these transitions to "ToggleSwitch"

Now we have a simple power supply with a switch that toggles it between the on and off states.
This shgould be easily implementable in C# using subclassing.  Now EA "used to" generate the subclasses for this example - but I'll be d....ed if I can get it to do it now?

Bruce

[sargasso]

... and here's another!


Create a classified object on a diagram.  Now create a "part" element and place it on the diagram.

In the tree we have a "sibling" relationship, not that that signifies anything.

Now drag the part over the whole and drop it there.

Look at the tree - the part is now a child of the whole!

Now try and move the part object in the diagram - it wont move outside the "bounding square" of the whole.

Now drag the part in the tree out of the child relationship and make it a sibling again.  You can now move the part freely in the diagram. So move it away from the parent.

Finally, on the tree, drag the part back to a child relationship of the whole.  Now try to move the part elemtn on the diagram - it snaps back inside the whole.

Bruce

[benc]

Hi Bruce,

Thanks for the feedback- see my responses below.

One immediate example - if you place an enumerator class as a child of a C# class, EA now generates the enumerator as an internal in the parent class source file automatically.  I didn't think this happened in 3.6? but I'm not complaining about it!

EA treats the enumerator class as a nested (inner) class for purposes of code engineering- similary other "child" class/interface elements, are generated as nested classes. In EA 3.6 inner classes were only generated from the nesting relationship (anchor notation).

The anchor notation may still be used in EA 4.0 to model/generate inner classes, but EA will now reverse engineer such classes as owned elements in the Project View, without the anchor notation. The help file needs updating to this effect.

This shgould be easily implementable in C# using subclassing.  Now EA "used to" generate the subclasses for this example - but I'll be d....ed if I can get it to do it now?

This was an unintended side effect when first we introduced the "Owned Element" approach for engineering nested classes. Basically, states and other nested types were generated as classes. I believe build 724 prevented this from occuring. When reverse engineering the code EA would import the nested types as classes, not states ... this would create some havoc in the model.

Regarding the part/whole diagram issue:

Finally, on the tree, drag the part back to a child relationship of the whole.  Now try to move the part elemtn on the diagram - it snaps back inside the whole.

This is a minor bug in the diagram update- the part should be replaced back inside the whole when dragged back to the whole from the tree. Thanks for alerting us to this. We will have this corrected ASAP.

Regards,
Ben