I recently did a video on this topic, but its importance needs a written version that can be scrolled through for better understanding.

Traders without a technical computer programming background could benefit from understanding how a trading simulation application is designed. The process of structuring the logic of a computer program is a skill that is transportable into almost every intellectual discipline I can think of.

Even simple decisions like planning a short vacation driving trip are suited to the conditional logic that computer programming so effectively teaches. It's for that reason that even though the topic of this post and the video is designing a computer program that simulates the staging out of transactions in a position in many different ways as a function of stop loss placement, both this post and the video are really meant to teach the critical components of the over all decision making process we all go through daily.

I understand that once the video frames whip by, it's very difficult to effectively process the material without the ability to scroll back a section or two to review the material. To help with some of that, I've included pictures of the hand written notes I used to do the video here in this post.

If you haven't watched that video yet, I'd suggest that if you enjoy video education that you watch this video now by clicking this link. It will take you to the bottom of this post where you can watch the video right on the page. When done, you can then just jump back up here to catch the rest of my written presentation.

Anyway, just a thought if you're interested in seeing the video.

Almost from the start I was writing simulation applications. First, against stock price movement, and then later against stock options, and then commodities.

From a personal standpoint, I don't like programming stock simulations simply because stock prices are moved too easily, and radically, when, for example, news comes out that the Treasurer absconded with $50 Million Dollars, and is living comfortably in Nicaragua.

I liked options at first because you were limited to your loss as to the price you paid for the Call or Put. Because I was trading options at the time, I began to program against the correlation of option strike as a function of time and stock price volatility.

At the time, the Black-Scholes option pricing model was used as the benchmark pricing for risk control. It's a very complex mathematical partial differential equation of raw form looking similar to the following:

Equation for the Black-Scholes Options Pricing Model

Through my programming, I discovered why the time decay differential of the option probably could not be overcome on a long term basis..

And, as I've mentioned in other posts, the creators of the Black-Scholes Model had most likely only derived it from Brownian Motion structure, and had not considered true market force risk. That was one of the major reasons the entire derivatives market imploded in 2008 creating the greatest economic collapse and recession since we've had post The Great Depression.

I found currencies in 2007, and began programming price action simulations somewhere in the 2008/2009 time frame. So, I haven't just stumbled out of the barn on this stuff. I've been at it for quite awhile.

Though all problems differ, the solution process of any problem is the same. It consists of basically just three steps:

Problem Solution Steps

• Specifically identify the problem to solve.
• Abstract out the keys issues of the problem, and solve each one of those.
• Correctly connect those solutions into a chronologically viable overall solution to the entire problem.

Sounds simple. And it really is. However, as to applying that process to computer applications, it's far more work than you might think.

Having said that, relax.... You don't need to know how to write code to solve price action issues. However, you should use a simple variation of the principles of conditional logic thought process as is used in programming.

Say you wanted to do an analysis of making a cup of coffee to determine the best combination of coffee grounds, water, and temperature.

So, what 'things' would you need to look at to solve this problem? Easy, right? Just: coffee grounds, water, and temperature.

Note here that the combination of different beans for the grounds, or how long you roast those grounds is immaterial to our problem. Our problem is to use some base type of coffee, and compare the amount of that coffee to the other problem components.

Look, just those 3 components as static elements create a permutation matrix of 15 different test cases. If you add different types of beans into things, not only are you complicating the problem, but you're not really simulating the issue you're trying to solve.

In software development terms, adding additional elements to solve creates what's called 'Scope Creep'. This simply means that the original problem that you had set out to solve has now grown beyond solving just that problem.

How do you resolve that? You resolve that by very clearly and specifically defining exactly what the problem is you are trying to solve. That very specific definition is what's referred to as the application's Problem Domain.

The issue which the simulation application that I'm writing tries to solve is how best to stage transactions out of a position as the stop loss point is varied. To state this clearly as my Problem Domain, I wrote the following down on a piece of paper before I wrote 1 line of code:

SOA Application Problem Domain

Find the best profit target stage out pattern as a function of stop loss placement.

*** SOA stands for: Stage Out Analysis, i.e. the name of the application itself.

Note that for purposes of this post, I'll just refer to these as 'components'. However, in object oriented software development they are actually referred to as 'Actors'. The term 'actor' represents a main element of the story, of which the Problem Domain is certainly a story.

Regardless of what you call them, the process of identifying components is similar to how I identified the coffee grounds, water, and temperature as the components of the coffee making simulation example. I did that by simply dissecting the Problem Domain to find those components.

Here's the list of major components for the SOA application which are either mentioned — or implied — in the SOA Application Problem Domain:

SOA Application Components

• Market Data
• Price
• Transaction
• Position
• Rules

The Market Data is where we get the information for building the Price candles/bars we'll apply Rules against to see if a stop or profit target hit will cause a change to closing either a Transaction, or if all Transactions are closed, then a closed Position.

Diagrammatically, this would be drawn up as follows:

SOA Application Components

You'll note that I've only listed 4 properties for the Transaction object, but indicated other properties that may be needed in a more complex application. Again, this is in keeping within the restrictions which the Problem Domain establishes over all aspects of application design. You only add in a component or a property to a component if it is essential to the solution of the Problem Domain.

Also note the arrows between Price and Market Data, and Position and Transaction. Those are referred to as application component association, which is the topic of the next section.

In this particular case, it infers that a Position object 'contains', or has object properties of Transactions.

The following diagram shows all of the associations in the SOA Application:

SOA Application Component Association

A Controller object has been added to the application. Every application has some sort of 'controller', or main program. A controller orchestrates all of the rest of the objects in the application to solve the Problem Domain.

Walking through the flow this diagram implies is a matter of following all of the interaction arrow reference. Note that the controller sits at the center of all of this activity.

The Controller first makes a 'getPrices()' call out to the Market Data object. This Market Data object could be a database, hard coded data within the program, or it could make some sort of web-services (over the internet) call to some other data source.

Once the controller has this data, it will create a series of Price objects each having properties of: enterDate, high, low, and close values.

It will then create a series of Transaction objects. In the case of my application needs, each Transaction will have an enterDate and entryPrice equal to similar values on the first Price object that was created. This is another associative link within the application.

However, this associative link is only known to the Controller as part of the general mechanics of building Prices and Transactions that will have parallel time frames and pricing. Because this is just generic 'plumbing' a programmer would have to do, it is not an actual part of the component association diagram.

After the Controller creates the Transaction objects, it then creates a Position object to put them into. And that just makes sense. While there can only be 1 transaction for each order a trader makes, a Position can consist of many Transactions.

Since the SOA application's Problem Domain is to study the results of staging out multiple Transactions, then a Position object is a mandatory component of the application as it represents the container for those Transactions.

And finally, the Controller creates the specific set of rules that will be applied against the Prices to determine whether a Transaction should be closed or not. Since there can be many rules, they are all programmed inside of the Rules object.

Once the Controller has created all of the application's necessary components, it passes them to the MarketBO (for Market Business Object) to do something with them.

The Market business object is another added component to the application. It is actually written in computer code as MarketBO to clearly identify its use in the application as an action object as opposed to a data, or information object. That just means that it 'does' something rather than just 'knowing' about something.

So, to summarize here:

SOA Application Component Association

The Controller builds a series of components that will be used in the application, and then passes them to the MarketBO. The MarketBO organizes these components to interact with each other such that the rules in the Rules object are correctly executed against the Prices.

Below the diagram is a chronological component interaction summary of the component association diagram.

This is needed to clearly identify the order in which application component creation must take place, and then what the Controller is supposed to do with all of those components

The computer analysis first required a Problem Domain. That enabled me to identify the main components, or 'objects' of the application. The next task was to determine how those components should be associated with each other so that I could then establish not only the order of component creation, but also how those components should come together to solve the Problem Domain.

The Problem Domain for the coffee example is to determine the best combination of coffee grounds, water, and temperature.

The components you need to solve this problem then become: coffee grounds, water, and temperature.

The association of those components is pretty easy: the temperature of the water increased, and is then passed through the coffee grounds.

Though you don't need a computer program to help you do any of that, hopefully you can see that the process used to build the program is the same process that could be applied to making coffee. In fact, if you had never made coffee in your life before, the instructions to do so would be exactly like this.

The point in understanding the computer programming analysis process is relevant to the solution of every problem, whereas just solving one problem may not really help you solve a totally different problem.

One of the very first components that I identified for the simulation was the Rules object. These rules will be run against each Price object (which represents a single candle or bar).

The rules will determine what to do if a stop is hit, as opposed to if a profit target is hit. By 'what to do' I mean:

Example Rules

• What conditions cause the rules to be run against the next Price?
• When does checking against the next Price end?
• If a stop is hit, should 1 or all Transactions be closed?
• If a profit target is hit, should 1 or all Transactions be closed?
• In closing a Transaction, what values should be used?
• If a profit target is hit, and only 1 transaction is closed, what is the rule for incrementing to the next profit target?
• If there are still open Transactions, and another Price is checked, how is the running stop adjusted?
• If a running stop is hit, should 1 or all Transactions be closed?
• What constitutes closing the Position?
• How many runs of the simulation should be done?
• How does the application collect the results of each simulation run?
• How are the final metrics of the results calculated?

I mentioned in the video when discussing the Rules object that all of the analysis, component identification, component association, etc. I can put together in a matter of a few hours. However, it might take literally weeks of work to build the Rules object. If you remember that part of the video, I think you'll better understand now why I said that....

SOA Application Rules Identification

After glancing through all of those questions that the Rules object needs to address, I hope you see that each of those questions goes to answering some point of the Problem Domain.

SOA Application Rules Come From Problem Domain

Those written questions can then be extrapolated into a conditional logic analysis document.

SOA Application Basic Simulation Conditional Logic Analysis

SOA Application Base Simulation Flow Chart

If you're not familiar with flow chart symbols: a round, elliptical shape generally represents a start or stop point, a rectangle represents some action to take, whereas a triangle represents a decision to be made.

Note in this diagram that the decision triangle 'Rule hit?' doesn't go into any detail as to what the rule is, but rather what generally to do when a rule is hit.

It basically acts in the simulation flow as a place holder where rule analysis takes place.

The decision triangle 'Rule hit?' just indicates that if no rule is 'hit' (whatever that might imply), go to the next price candle. However, if a price rule is hit (whatever that might imply) then 'Process Transaction' (whatever that might imply). Then, if everything is 'Ok?' (whatever that might imply) go to the next candle, else end the simulation.

This is the exact diagram I used to structure the basic component interaction and decision flow for the application I'm currently building.

I wrote all of the raw code to traverse that basic logic flow, i.e. with no real decisions being made. That initial code was written to confirm that the program flow as I identified it would be successful navigating through that decision matrix.

SOA Application Flow Chart

Though a little more involved than the basic flow chart, it's fairly simple to understand — and thus simple to write the application code in the Rules object to facilitate solution of the overall Problem Domain.

The goal of this post is not to teach computer programming. I hope you understand that, and further don't think you have to know any of this stuff to trade, or to create a trading plan.

The Point of the Whole Post....

All of this computer application analysis and design is a process, a process that can be taken and applied to the solution of any problem.

It represents a process of how to do your trading analysis — or planning your next vacation trip — rather than what to do.

If you skipped down here from the text to watch this before reading the post, you can click here to jump back up here to catch the rest of my written presentation.

Video: Developing A Computer FOREX Trading Simulation Model