Tuesday, August 09, 2005
Reconciliation
Some reconciliations need to be balanced.
For example, if comparing a trade order against several trade fills, then we have the situation where the total number of, say, bonds ordered should be the same as the number of trades filled. Since its an likely to be an accounting problem where the fills will have a different sign. That means the balance will be zero.
For example, if comparing a trade order against several trade fills, then we have the situation where the total number of, say, bonds ordered should be the same as the number of trades filled. Since its an likely to be an accounting problem where the fills will have a different sign. That means the balance will be zero.
Monday, August 08, 2005
Classes with FSM
Classes with finite state machines are an example which OO supports badly.
The test is to look at the object's identity. If you are copying identity from one class to another, then you have probably been caught.
Take a simple account class. You decide to split it into two classes, active account and dormant account. The bank account number is going to be common, and you want to prevent having two accounts, one active, one dormant with the same account number.
In reality, dormant or active is a state on the account.
Different classes were made because the data relevant to each class is different.
What is needed is an abstract base class, account, with two sub classes, dormant and active.
The test is to look at the object's identity. If you are copying identity from one class to another, then you have probably been caught.
Take a simple account class. You decide to split it into two classes, active account and dormant account. The bank account number is going to be common, and you want to prevent having two accounts, one active, one dormant with the same account number.
In reality, dormant or active is a state on the account.
Different classes were made because the data relevant to each class is different.
What is needed is an abstract base class, account, with two sub classes, dormant and active.
Development driving class heirarchies
Sometimes the development process drives the class heirarchy. Trade and order are a good example where there usually are two separate teams developing different subsystems or systems. The benefits of having a common class heirarchy are lost because they don't, can't or aren't allowed to work together.
Prototypes don't make good base classes
Take the example of trade and order. Both good prototypical examples like tree and fir are for trees. However both miss the base class.
ie. Look for base classes.
ie. Look for base classes.
Named Scenarios
Named scenarios are a good idea. You can then save a particular set of shifts or stress tests.
The tool should also be able to generate actual scenarios. For example, give it two dates, and that determines all the shifts. ie. The changes in the summer of 1998 would be a Russian crisis scenario.
The tool should also be able to generate actual scenarios. For example, give it two dates, and that determines all the shifts. ie. The changes in the summer of 1998 would be a Russian crisis scenario.
