I would suggest that the SignalGenerator class should live up to its name and do just that -- generate trading signals. It should not know anything about the trades or their types. Instead of the "push" model where SignalGenerator initiates something (as it is in your diagram), you could use a "pull" model where the class that acts as a trader interrogates SignalGenerator. Also, the PositionManager class that you diagrammed earlier is not shown in this sequence diagram above. Perhaps for a reason, but it's not obvious to me.
Yes, good point. Initially, that is what I had in mind for SignalGenerator - simply generating buy/sell signals where there was an abstract Signal class. You could then combine multiple SignalGenerators to come to a trading decision: if all the Signals are green - buy. This way you could reuse signal generators across strategies and swap in/out signal generation. At least, that was my pure OO way of thinking about it. I suppose I have been influenced by commercial software where this concept doesn't exist in quite the same way. There was one software I came across, it may have been Tradecisions, whereby you could combine multiple systems under one system in the same way I had envisaged treating Signals. However, when it came to actually coding some strategies, I found the Signal concept to be a bit OO too far. OK, so perhaps my SignalGenerator should be renamed to Trader. The function it performs remains the same though. It does essentially "pull" signal information for decision making from anywhere it deems fit. This could be from a traditional TA indicator whether using code native to the framework or using external code. Inside Trader e.g.: Code: onBar(Instrument i,Bar b) { if(myIndicatorValue IS some value) { buyMarket(...); } } There's no reason why that couldn't be replaced by a more OO Signal-based approach e.g. Code: onBar(Instrument i,Bar b) { if(mySignalGenerator.getSignal() == SignalType.BUY) { buyMarket(...); } } Perhaps this is what you meant by having the Trader interrogate the SignalGenerator. I think we're on the same page except for my naming choice. The PositionManager isn't involved in the sequence to execute a trade. It does however get involved when an execution report event is raised from the broker. The PositionManager listens for these execution reports and then opens/closes positions accordingly. It also notifies the strategy of various pertinent events e.g. onPositionOpened(). In order for the PositionManager to listen to the right execution reports it may need to be given a heads-up with a correlation id or even just the order ID when orders are being placed. Perhaps that is what you were expecting. Code: . . . //override base class to provide //our own code for this event handler.. onBar(...) { //decision making logic here... //we want go long... buyMarket(...); } . . . //override to provide our own code //for this event handler... onPositionOpened(...) { //A position was openend so //now we want to bracket it OCAGroup ocag = new OCAGroup(...); ocag.addOrder(new StopLoss...); ocag.addOrder(new ProfitTarget...); orderManager.submit(ocag); } . . . Thanks for the input. Hopefully some of these discussions will yield an idea or two that you can incorporate into JSystemTrader as the thread goes along.
Assuming I rename SignalGenerator to Trader. Does anyone else have thoughts on having separate SignalGenerator(s)? Hypothetically you could have 1 or more SignalGenerators per strategy. Then, in Trader you would look at a "SignalAggregator" which in turn looked at all of the SignalGenerators configured for the strategy. Using a configurable voting mechanism e.g. unaminous, majority,weighted etc. the SignalAggregator would come to a decision: BUY/SELL. Perhaps also a strength indicator related to the voting mechanism. Then in Trader: Code: onBar(...){ if(signalAggregator.getDecision() == SignalType.BUY) { buyMarket(...); } Is this OO too far? This would require the system developer to override not only the Trader class but implement 1 or more SignalGenerators for their strategy. Of course, using the SignalAggregator would be optional for strategies that don't work on a signal concept and all decision making logic could be coded inline inside of Trader. However, if used, it could be quite a powerful mechanism for testing by adding/removing confirmation signal generators etc. or adjusting the weightings or voting strategy. Has anyone seen/used this concept in other software?
I dont know if any trading softwares use the voting concept but I knwo that voting algorithm is a very basic approach in machine learning. In my implementation, I have two base classes Strategy and CompositeStrategy. The class CompositeStrategy contains a list of specific stratgies which are subclasses of Strategy, and has the methods to add/delete Strategy. For implementign a new voting or other kind of reasoning/deciding algorithms, I just need to subclass CompositeStrategy.
Interesting, using the composite design pattern is certainly a neat way to go about it. I could feasibly apply that here to have SignalGenerator and SignalGeneratorComposite. Presumably the actual order management occurs elsewhere?
I hope so, too. The JSystemTrader design is very similar to yours (although JSystemTrader is more narrow in scope), so we are pretty much on the same page. However, there may be some confusion because of the class naming, so it would be good to define each class responsibilities explicitly. It looks to me that your SignalGenerator is acting as a) a signal generator, b) a trading strategy, c) a trader, and d) a money manager. Given your apparent emphasis on pure OO design, it seems that SignalGenerator is too heavy with its responsibilities. From the name of the class, I initially thought that all it does is to generate trading signals, such as "buy" and "sell", based on some technical indicator. So, what I suggested in my previous post is that that functionality would fall quite naturally to that class scope, but anything beyond should be defined elsewhere. I am also a little confused by the PositionManager, because I originally thought that its function is, well, to manage positions. That is, I attributed the "money management" functionality to it. For example, suppose a buy signal is generated, and PositionManager calculates the risk/reward and decides to buy 1 contract. Later on, another "buy" signal is generated (perhaps from a different indicator), and PositionManager decided to add to an existing position. However, as you clarified, the PositionManager responsibilities are just to track the P&L. That's fine, too, but what class performs money management then? Now, what I think of a class named Trader is a class that doesn't know anything about indicators, signals, positions, and P&L. All it knows is how to place orders. It's dumb in its ignorance, so to speak, but that's precisely the intent. In your design, perhaps it's a function of OrderManager?
Code: public abstract class TradingSystem extends Indicator { //to generate signals Strategy strategy; //to execute/manage orders Broker broker; }
This class structure implies that TradingSystem is an Indicator, which it's obviously not. I'd say a more intuitive relationship is "TradingSystem has an Indicator", or even better, "TradingSystem uses an Indicator".
Well, this is the same idea that NeoTicker follows. Essentially, it treats TradingSystems as specialized Indicators. For example, Indicators are given one or more data series as input and spit out indicator values for each bar, for example, that comes in. Compound indicators spit out compound indicator values for each bar that comes in built from the output of other indicators and/or market data. Continuing the progression, Trading systems spit out an equity curve data series (by NeoTicker convention) based on each bar that comes in from other indicators or market data. Trading systems additionally also have order management functions. The concept of Trading system as a specialized Indicator was quite a neat way of implementing it I thought. After all, many people use indicator thresholds to trigger buy/sell actions. It's perhaps all just a matter of semantics as at the end of the day, all ATS software is essentially doing the same thing.
I should be more clear about how I define Indicator. I consider anything that exports data arrays as an indicator. An SMA is an indicator, it exports a data array of price average, a trading system is an indciator, it (at least) exports a signal array and an equity curve array. I don't like to have many abstraction layers in the level of framework (top level), instead I like to have many layers in the implementation level (lower level). I know this approach is not good for very comprehensive application. One advantage is that I can use the same gui (like the one for indicator) for many things, it is also good to end users, they dont' need to know many concepts. We really said the same thing in almost identical words. You see, you are totally right, all ATS software is doing the same thing with just little bit of different tweaks.