Open joeseibel opened 7 years ago
I missed that portion of the committee meeting, but I like the idea of being able to run them from a launch configuration. It would open up many new capabilities like using them when launch groups and saving launch configurations to file.
What analyses do we have?
What kind of inputs do we have? -- Influences how we run the analysis
Package file (no dialog or other inputs) (NOT package object in the outline view)
Instance model file (no dialog or other inputs) (NOT system instance object in the outline view)
Any instance object (Converts to System Instance object)
Instance Model file or Any instance object (Converts to System Instance object) + workspace preferences
Any instance object (Converts to System Instance object) + Dialog box + workspace preferences
Instance model file or System instance object + Dialog box + workspace preferences
Instance model file or System instance object + Dialog box
Instance model file or System instance object
What kind of outputs do we have? -- Shouldn't affect how the analysis is run, but interesting to know
I don't think the built-in Eclipse launch configuration mechanism the appropriate because it is meant to actually execute an external program. It provides run
, debug
, and profile
modes. These don't make sense for us.
See https://www.vogella.com/tutorials/EclipseLauncherFramework/article.html
We probably want something similar, a mechanism that
But I think it's pushing the semantics to directly piggyback on the launch configuration extension point.
Question: What role should workspace preferences play in analysis configuration?
Fault tree generation, Flow latency analysis, and Functional hazard assessment make use of workspace preferences. Fault tree analysis even uses project-specific settings.
FHA uses the workspace preference as its only configuration. It is obtained by the command handler, and then used as an argument to the class that performs the FHA task.
Fault tree generation gets other settings from a dialog box (this is another problem discussed later). The generation process is not parameterized by the value workspace preference/project property. Instead the generation process is hardwired to repeatedly call FaultTreeModel.getPrecision()
.
Flow latency uses the workspace preferences to initialize the default values in its configuration dialog box only, and to determine if the dialog box is shown at all.
I would argue that the way workspace preferences/project properties are used in fault tree generation is horrible for a variety of reasons. But from the consideration of "rerunning an analysis", it does not provide for a consistent way to rerun the generation. Changing the preference value between runs would change the manner in which the fault tree is generated.
In FHA, the workspace preference could easily be replaced by a dialog box that is presented at the start of the analysis.
In flow latency, the preferences have the least impact. As mentioned above, they are used to set the defaults for the dialog box. This is definitely the model that should be emulated, if any.
In summary, I think the correct role for workspace preferences/project properties is for them to determine the default settings of any parameters to the analysis. Most likely these parameter would in general be configured using a standardized dialog or pane that is used by the analysis "service."
We should absolutely avoid doing what fault tree generation is doing.
Dialog boxes are used by
The dialog boxes are used to get additional parameters for the analysis. These can definitely replaced by some kind of standardized dialog/pane that can be be used remember the analysis settings.
One interesting thing is that fault tree generation requires the user to choose a "state name" as input, and these states are taken from the model. Being able to populate the dialog/pane using information from the model needs to be taken into account in any future mechanism. In this case the resulting input is a name as String
. It is possible the name won't exist anymore the next time the analysis is run. Rerunning the analysis based on the old settings would have to detect this case. Basically the analysis would have to either validate it's settings before starting or be able to tolerate bad settings, e.g., by terminating gracefully with a controlled failure.
Any analysis of a model is going to run over the instance model. But we do want to be able to run over declarative model components: the Find Unused Classifiers analysis runs over the declarative model. This doesn't analysis properties over a model, but rather deals with properties of the model "source code." There are no extant examples of similar analyses right now, but it is easy to imagine that there could be more in the future.
This issue probably has implications for #2384.
Went looking for how plugins are allowed to save state, because this information doesn't seem like it belongs in workspace preferences or project properties, which both seem to be based only on key–value pairs.
See: https://wiki.eclipse.org/FAQ_Where_do_plug-ins_store_their_state%3F
Plugins have a state location that is unique to a workspace into which they can store arbitrary files. This location is obtained by calling the method getStateLocation
on the Plugin
instance.
Point here is that we don't have to try to squeeze the analysis configurations into preferences or properties. We can create our own data file to save the information.
Having a way to rerun the analysis doesn't mean we cannot keep launching analyses the way we do now, e.g., via commands in the outline and navigator menus. It doesn't mean special dedicated dialogs always have to be used.
We need to have a standard way for the analysis to
Then we need ways to
Should an analysis be able to provide a "blank template" for an analysis run so that a analysis configuration can be created from scratch without running a prior analysis?
As an API detail, it may be worth exploring having the analysis be able to marshal/unmarshal or be able to pickle/unpickle its own settings. This implies the analysis would be responsible for building its own "Settings" pane as well. This avoids having to save the settings as yet another form of attribute–value pairs.
A–V pairs drive me nuts because they are hard to type check and they constrain what kind of inputs are available.
We need a way to identify analyses so that they can be found and executed.
Discussed this @lwrage and we want to keep this as simple as possible:
From an API and implementation point of view, we have the problem that currently there is no entity that represents an analysis. We have abstract classes that are used to implement AADL-aware commands, but they don't have to be analyses, and as a command typically hand off actual processing to other classes.
Here I think we need to introduce a Java interface for analysis. It needs to have a method that takes a configuration/picked state object and executes the analysis using it. Invoked this way
Actually, the instantiation and possible reinstantiation should not be handled by the new analysis instance, but by the components that manage the "last used analysis" menu.
The pickled state object needs to be able to provide a human-readable description of the contents so that the actual parameters of the analysis can be shown to the user. This might a string, or maybe a UI pane so that it can be displayed in a standard dialog.
When an analysis runs (no matter how it runs), it needs to report that it ran and provided a pickled configuration to some central bookkeeper.
Missed these analyses some how:
These just take an instance model as input and do not present a dialog box or have other configuration options.
How to make a dynamic menu (toolbar or otherwise) that would show the most recent list of recently executed analyses:
We want to make as few changes as possible to existing analysis implementations.
Step 1: Add a dynamic menu in a toolbar to the UI.
Advanced: analysis executor provides an image descriptor.
Going to start by "upgrading" the Flow Latency analysis because this analysis uses a dialog box to get inputs, and I know what it's supposed to do.
Now that I'm defining some interfaces for this, it makes more sense for the configuration state to be part of the "execution" object.
As always, I forgot about modes and SystemOperationMode
. Problem is there doesn't seem to be standard way of handling this for analyses in general. Currently every analysis does it's own thing, e.g.,
Bus Load Analysis always analyzes in every SOM
Flow Latency Analysis asks the user what to do, and can analyze in a single specific SOM, or in all of the them.
So for now, SOM needs to be part of the configuration state saved by the analysis.
Addendum: This is actually quite awful because the driver for looking at the different system operation modes is in the AbstractInstanceOrDeclarativeModelModifyHandler
class. I was hoping not to have to modify this class considering that I'm trying to get rid of it, but it cannot be helped.
The configuration of an analysis can include multiple instance models:
The model URIs are distinguished in the runner configuration because I want the command that invokes the runner to take care of reinstantiating the models before rerunning the command. So I need to expose a list of URIs, not just a single URI.
See also #2329 about SOM selection. This should be unified across all analyses.
SOMs definitely complicate this issue, as current behavior of analyses is all over the place. Need to "step back" and review the overall analysis situation.
Started internal wiki page to discuss this: https://wiki-int.sei.cmu.edu/confluence/display/AADL/OSATE+Analysis+Execution
There should be a way for OSATE to remember the last analysis which was run and which model it was run on so that a user need only to click a button to rerun the previously executed analysis.
One possible approach is to turn the analyses into run configurations instead of having them be actions or commands in the menu/toolbar.
This request came up during the AADL standards committee meeting.