Update bus load analysis internal model to use ecore

[AaronGreenhouse]

After discussion of general analysis implementation issues with @lwrage we decided that the internal models should be based on Ecore for uniformity with the rest of OSATE.

The model used by Bus Load analysis needs to be converted to Ecore.

[AaronGreenhouse]

See https://www.vogella.com/tutorials/EclipseEMF/article.html

[AaronGreenhouse]

Created a new model busload.ecore. This uses a new generic element that created in analysis.ecore. The analysis.ecore model will eventually be moved to a new project/plugin.

Need to create some infrastructure for traversing the EMF model. Trying to think about what Anna is going to need for the other Resource analyses and to figure out what is the generic way of doing things.

[AaronGreenhouse]

Some comments on this:

Mutability

When implementing the analysis model using plain-old Java classes (POJC) I am able to make fields final to better protect them from accidental changes if the class is misused. I'm a big fan of doing this (but I notice that most large APIs from major vendors don't seem to do this). Ecore models make all the attributes publicly settable, and there is no set-once option. This isn't a really big deal, but a downside in my mind.

Model Traversal

For some inexplicable reason, EMF does not provide any way to control the traversal of Ecore models. It does not have a proper visitor pattern. As far as I can tell you are expected to use EcoreUtil.getAllContents to get a TreeIterator and then repeated pass the model objects to a Switch instance. This is a bit clunky, but so be it. The bigger deal is that (1) although getAllContents does a preorder traversal, this is not documented as a requirement, and (2) there is no provision for a postorder traversal.

Busload analysis needs a post order traversal to compute the loads. So I need to make my own machinery to do this. This seems wasteful, but there is no way around it. To this end I have the AnalysisModelTraversal class that is intended to be generic and used by other analysis implementations.

A side-effect of the clunkiness of using a Switch instance instead of a proper visitor pattern, is that it is difficul to maintain state during a traversal. In particular, Busload analysis needs to maintain the current data overhead value and the current Result object during the traversal, and this is computed in a top-down (preorder) manner. In a simple recursive descent implementation of a traversal that would be available in a POJC implementation, this could be maintained by a parameter to the visitation method. But this is not possible when using a Switch class. So instead I have to have an initial preorder traversal of the model and store the overhead and Result values as attributes of the model elements themselves, so they can then be read from the model during the "real analyses" in a second bottom up pass.

This adds unnecessary clunkiness to the implementation, and I would argue unnecessary junk into the analysis model.

Switch return values

The Switch class uses caseXXX methods to handle each EClass declared in the EMF EPackage. If a method returns null (the default implementation of each method), then the case method for the superclass of the EClass is called, and so on. The catch here is that if you have a Switch representing an operation that doesn't have a return value, you should not paratemerize the Switch with a Void class. This class has no instances, and so null is the only legal return value that can be used with it. This would cause the superclass case methods to always be invoked, all the way up the hierarchy. Not good. To get around this, I have instead made the return type Boolean and I return the value Boolean.TRUE if the case is handled.

A cleaner approach, I supposed, would be to introduce a new enumeration:

enum SwitchVoid {
    VOID;
]

and return SwitchVoid.VOID when successfully handled, and null otherwise. This would avoid assigning unwanted semantics to Boolean values.

[AaronGreenhouse]

@lwrage Pointed out that the above comment sounds like I was against using EMF. I was just trying to document how it forces a different way of doing things. Of course, the advantage of using EMF, is it provides uniformity across the analyses and with the main AADL models.

I haven't tested the my EMF version of the bus load analysis yet. Should be able to do so shortly.

My main complaint against EMF is with the model traversal and Switch classes. I used them because this seems to be the way that they advocate that you do it. But, well, it has problems. The traversal I wrote in the non-EMF version isn't perfect either. It uses an explicit stack to manage the values that are "passed down" during the pre-order traversal. This is not ideal either. This comes from the fact that that approach is visitor-based, even though the objects themselves are controlling the traversal.

So after I finish testing the new EMF version, I am going to make a third version, that also uses EMF, but instead of using visitors or Switch classes, features a straightforward recursive traversal of the tree (with the operation defined as part of the model) that allows for parameters to be directly passed so we can exploit the method-call stack.

Then we will have 3 implementations of the same analysis and be able to make some informed decisions about how to proceed in general.

[AaronGreenhouse]

More notes:

• Forgot to make the references "containment".
• I had made BusloadElement an unrelated to class to AnalysisElement and then used multiple inheritance. The BusLoadModel was an AnalysisElement but not a BusloadElement. This caused problems with the implementation of the isLeaf() and getOrderedChildren() operations because then the implementations from AnalysisElement weren't inherited and I would have to re-implement the methods in each class, which was undesirable. So I had to make BusLoadElement a subclass of AnalysisElement, and BusLoadModel a subclass of BusLoadElement.

[AaronGreenhouse]

Had to fiddle with the order of the reference declarations in BusOrVirtualBus to make them consistent with the order expected by the results. (That is to keep things consistent with the original version of the analysis.). Wasn't sure how to control this in the graphical editor, so I had to edit the XML directly.

[AaronGreenhouse]

Reg tests now pass. I didn't any actual coding errors (that I have discovered yet). All the problems were from EMF meta modeling. :-(

[AaronGreenhouse]

Okay, so I have the first working version: Ecore/EMF using iteration and Switch classes. This is on branch 2555_bus_load_analysis_ECORE

[AaronGreenhouse]

Going to make 2 more versions:

1. An EMF version that does not use Switch, but instead has explicit recursive traversal methods.
2. An improved POJO version that has explicit recursive traversal methods.

[AaronGreenhouse]

Created branch 2555_bus_load_analysis_POJO_no_visitor for the second choice above.