Stock Analyst 2 Plugin Classes

The classes inside the Stock Analyst 2 project are mainly split between the system in charge of loading the plugins (under the Engines namespace) and the classes in charge of showing the result of the execution of a plugin (under the Visualization namespace)


  • PluginSystem: it is the glue that contains the elements that conform the whole plugin system. It creates its own objects (the db related objects are taken from the ApplicationInitializer) and makes them work together thru its method Initialize() which scans for all the available plugins, creates them and raise events for each one to allow the main window process to handle the event and create the UI elements that allow the end user to interact with the plugins.
  • PluginDetector: its main responsibility is to scan the execution folder for all the available classes implementing the plugin interface. To improve its performance there is a list with all the application assemblies so the detector can skip them. To know if an assembly has plugins it has to contain the attribute PluginContainer.
  • PluginActivator: its responsibility is to take a list of plugin types (the ones detected by the PluginDetector) and to instantiate them into the objects that will be used by the application. It will give them the objects that they need to work (like database clients, etc).
  • PluginLoader: its duty is to create the UI elements that will be needed by the UI from the data offered by the plugin (an icon and a entry string) and to raise an event requesting the attach of a plugin. This event will be rethrow by the PluginSystem and handled by the MainUi.


There are two namespaces, one for the classes dedicated to realtime plugin visualization (they're just a few) and the ones related with historical plugin visualization (they are more classes here because the code related with result information extraction and visualization).

Historical Plugins Visualization

This is the internal structure of the historical plugin viewer user controls. There is one user control for each task:

  • HistoricalPluginViewer: the historical plugin viewer is the whole UserControl that allows end users to interact with a plugin in historical mode. It shows everything, the Control Panel when a plugin has been selected and results when they are available too, using the Execution Summary, the Results Chart and the Operation Details. Internally is composed of the currently selected plugin ControlPanel and a ResultViewer to visualize the plugin execution results.
  • HistoricalPluginViewerVM: contains the objects required by the HistoricalPluginViewer. Mainly the current plugin and the results if available. The results are a fixed collection that is cleared and filled when new results are received through the plugin event ResultsAvailable.
  • ResultViewer: it's the user control in charge of showing to the user all the information available about the execution of the currently selected plugin. Again, it is mainly a composition of other sub-controls: a SummaryViewer, a ResultChartViewer, a DetailViewer and a CustomDataViewer.
  • ResultViewerVM: contains the data of the ResultViewer. It contains the viewmodels of the sub-controls of the view and a ExecutionStatisticsCalculator that performs the calculation of statistics over the received operations. The ResultViewer should be hidden and shown again when loading new data from a plugin to notify to the end user that the results are there, to do this the control is hidden when the results are cleared and shown again when there is new data. The control has no fading because the fade animation is done asynchronously and thus the fade out is done with the new data being loaded.
  • SummaryViewer: the summary viewer shows to the user the key points of the operations executed by the plugin. The data shown by the summary is:
    • Total Result: the final amount of money generated by the plugin including fees and everything.
    • Average Operation: the amount of money generated by each operation. This allows us to compare strategies with different execution times. The one with higher average will (probably) behave better over the time.
    • Max Amount Required: the maximum amount of money required during the execution of the plugin. Without this amount the strategy couldn't be executed. This value is used to calculate the profit.
    • Profit: the result versus the amount required. This is the one of the most important value of the strategy. 
    • Daily profit: this value, like the average operation, allows us to compare strategies using different time ranges. This can be the most important value of a strategy.
    • Best partial: this is the maximum amount of money gathered during the execution of the strategy.
    • Worst partial: this is the maximum amount of money lost during the execution of the strategy.
    • Best strike: this is the maximum amount of money that we could have win if we had executed the strategy between the range specified by the Date Range. This is the best possible result achievable by the plugin with the provided data.
    • Worst strike: this is the maximum amount of money that we could have lost if we had executed the strategy between the range specified by the Date Range. This is the worst possible result achievable by the plugin with the provided data.
    • Other fields that are selfexplanatory: all the fields have a tooltip explaining its function.
  • SummaryViewerVM: contains the data presented on the SummaryViewer and the tools to calculate it. The data represented is stored into an ExecutionStatistics object (is the viewer model) and it is filled by an instance of the ExecutionStatisticsCalculator object when results are received.
  • CustomDataViewer: it shows whatever usercontrols a plugin sends after its execution. The viewer simply shows them in a vertical list. 
  • CustomDataViewerVM: it simply contains the list of UserControls sent by the plugin to be shown.
  • ResultChart: shows a chart representing the accumulated result with a green line and the partial results with blue vertical bars.
  • ResultChartVM: transforms and stores the data coming from the model (the statistics calculated from the operations done by the plugin) in the way required by the view (DataSeries of DataPoints).
  • DetailViewer: presents a detail on the operations executed by the plugin in the form of a grid. The size of the columns is calculated on the Loaded event because having a * sized column does not allow other columns to change its size after creation (as the one with the * is taking all the available space). It currently has the following fields:
    • Operation Start: the start time of the operation. It can be a buy or a sell.
    • Operation End: the end time of the operation. It has to be the opposite operation of the operation start.
    • Buy price: the price at which the commodity was bought.
    • Sell price: the price at which the commodity was sell.
    • Volume: the amount of commodities bought and sold. Currently we only 
    • Fee:
    • WIP
  • DetailViewerVM: contains and manages the data shown by the DetailViewer. It's main duty is to transform operations into DetailViewerRowVM objects.
  • DetailViewerRowVM: it is just a container of the data show by each row of the grid.

Realtime Plugins Visualization

  • RealtimePluginViewer: WIP
  • RealtimePluginViewerVM


  • ExecutionStatistics: models all the information than can be inferred and extracted from the list of operations done by a plugin. 
  • ExecutionStatisticsCalculator: its responsibility is to extract the information from the list of operations done by a plugin in the form of a ExecutionStatistics object. To do a better usage of the MVVM paradigm an ExecutionStatisticsCalculator has always the same ExecutionStatistics object updated instead of creating new objects on each execution. The calculator has no public methods, it is automatically executed when new operations are received from the current plugin. If the list of operations has new operations means that a new set of operations has been loaded as the whole set of operations is loaded with a single AddRange. if the list is cleared then the results are cleared too.
  • PluginSystemVM: its responsibility is to contain the data used by the Views related with the plugins. Currently it is only used by the MainWindow. It is in charge of enabling or disabling the plugin sections based on the number of loaded plugins (if there are no plugins available then the plugins menus / toolbars are disabled).

Last edited Feb 18, 2013 at 9:54 AM by somos, version 7


No comments yet.