Plugins will be user created content using C# and WPF in the form of assemblies. These plugins will be loaded by Stock Analyst 2 on application start-up if they are stored on the main folder of the application and they will be available to be configured and executed by the end user.

A plugin can have up to two different roles, the historical role will execute the plugin over historical data and generate a report and it's always available. A real-time role will execute directly over the market data and generate real operations. It's up to the developer to create the real-time role. Normally a plugin will be created just with the historical role and if it's profitable then the real-time role will be added.

This is how plugins will be designed from a high level perspective. Both roles must share the same decision engine to have a tested system before going to the real market. 

A typical plugin will offer to the end user some parameters to tweak and a button to execute the strategy. The output of a historical plugin will be a list of operations executed by the plugin's engine. The output of a real-time plugin will be a notification each time that there is something to inform (start & stop of the engine and operation executed). The historical plugins will have also a way to return a list of UIElements that will be shown by the application, this way custom information could be returned by the plugin. The application will take the list of operations and custom information and present them to the end user extracting all the possible information. The real-time plugins will limit the information they offer to the end-user to the one related with its execution (to allow the bigger number of plugins possible on screen at the same time).

These are the areas of the screen when executing historical plugins:

And this is how the application looks with realtime plugins (just showing one):

The code to implement this feature is splited in three projects:

  1. StockAnalyst2: all the code used to load the plugins into the main ui, show the UI and manage the user interaction with the plugins (except the control panel) will be stored into this assembly (plugin's host).
  2. Plugins: all the shared code used by the plugins like the interface definition and common APIs will be stored in this assembly. This will be the main assembly referenced by the plugins (together with Stock Model and Utils).
  3. UserCreatedPlugin: will contain the strategy dependent code, the implementation of the required interfaces, etc.

This is how the plugin engine system fits with the current design of the application:

No plugin must try to access the database on creation because doing this would generate errors when the application is not configured avoiding the user to go to the options dialog.

Basic Structure

Each plugin contains the following structure:

  • Plugin class: there will be a class implementing the IStrategyPlugin.
  • Control panel: there will be a user control containinig all the needed elements to configure and execute the plugin. There will be one to be used in real-time and another one in historical mode.
  • Strategy control: normally the control panels are always the same between plugins, the only thing that changes from plugin to pluing is the strategy control. It's a user control containing the parameters that configure how the decision engine of the plugin will work.
  • Decision engine: is the class that will evaluate the different stock quotations and will generate the buy and sell signals in response.

Class Documentation

  1. Stock Analyst 2 Classes
  2. Plugin Classes

Last edited Feb 18, 2013 at 12:06 PM by somos, version 36


No comments yet.