Overall Diagram

The next diagram shows the main architecture of the application:

Source of groups

Data will be taken dynamically if possible. That means that groups will be populated with new stocks or futures automatically but sometimes this is not possible. For example, currently groups are declared at the application code level and then are persisted into the database.

With the introduction of different markets and different times each group will be linked to a market. Markets will be introduced by hand into the database as a requisite of the application. They will be updated by hand too. This forces us to introduce by hand too the links between groups and the markets. They will come as static data on the database.

SOLID

The application will be designed trying to follow the SOLID guidelines, specifically the single responsibility principle. As a result of applying this principle we use often the concept of a data source. A data source is a class that knows how to write / read objects from / to the database. It has to be designed to handle only one class (or very related classes as stocks and stockgroups).

Why to use the single responsibility principle? As a result of using it a design has a higher number of classes but each class has a single task. The code is much more encapsulated and maintainable and boundaries are much better detected.

Static data

Static data deployed by the application will be read with data sources. There will be no cache of this data and each time a Load is done a new object will be created even when representing the same entity. This way of working has been selected due to its simplicity and because looks like this is not going to have side-effects on the application. If side-effects are found a cache will be created and all static data will be read and created at the initialization of the application (we will face different problems with this approach as we can have several instances of the same stockgroup in memory representing different times.

Quotations Model

Quotation size is something to consider as they are the thing that will get the most space on the database and in memory. Initially we stored at the database the data when changed and we maintained the same structure in memory. Latter we found this approach has some problems:

  1. Having the data at irregular intervals makes harder to create indicators (as for example the moving average one) as they are designed to work with fixed time spans between values.
  2. Updating charts and engines when a value changes slows down the reaction of the engines as they only act on quotation changes. Even when quotations do not change their averages and other indicators should be changing with time.

Due to these issues the memory model will be changed while maintaining the database model. In memory we will have a fixed time representation and the transform will be done when Loading / Saving quotes. The interval selected will be approximately 1 second, as we cannot ensure this value due to the different network delays we need a way to introduce a quotation exactly each second:

It's very important that data taken in realtime and the same data loaded from the database generate the same memory data.

Code Metrics

Current code metrics as of 02/18/2013. We are near the 10.000 code lines (without plugins nor integration tests). Even when the code grow the maintainability index has improved due to the continuous code refactoring.

Previous code metrics as of 03/05/2012. We had about 4.000 code lines (without plugins)

Last edited Feb 18, 2013 at 8:58 AM by somos, version 14

Comments

No comments yet.