STRESS TESTING Stress testing measures the impact of an abnormal market move on a portfolio. Running abnormal scenarios allows us to quantify the move’s effects on a portfolio, and if these effects are unacceptable, the portfolio composition may need to be revised. Scenarios are often historical in nature. For example, what would have happened had this portfolio gone through the crash of 1987, or September 11? What would happen if all our correlations go to 1? If our firm is engaged in dynamic hedging or constant rebalancing of portfolios, what would happen if a major shock occurred overnight and market liquidity dries up? None of these scenarios is statistical in nature, but clearly there are nonzero probabilities associated with them that must be addressed. Now let’s incorporate UML design techniques and Monte Carlo simulation into a simple VaR calculator. STRUCTURAL DIAGRAMS Structural diagrams show the static architecture of a software project. Class Diagram A full class diagram displays an overview of an entire system including the constituent classes and the relationships between them. However, class diagrams are static and only show what relationships exist, but not when they happen. UML notation for a class is a rectangle with three parts, one each for the class name, the attributes, and the member methods or functions. An individual class is represented in Figure 20.5. Here Monte Carlo is the name of the class, and it represents the definition of a Monte Carlo simulation object. The 2 and þ signs define the private and public visibility of the attributes and methods. Although not shown, # would define protected visibility. MyMarket, CurrentPortfolio, dblIterations, and dblDaysAhead are all private attributes of the Monte Carlo class. The dblDaysA- head attribute, for example, will hold the time horizon of the Unified Modeling Language 353 Team-LRN simulation in terms of the number of days. DblIterations will hold the number of times the simulation will run. The member functions are listed in the bottom box and include the property gets and sets. The signatures of the respective methods are also shown outlining the input and output argument types. The New() method, of course, is the constructor, and StdNormRnd() is the function described in Chapter 5 that returns a standard normal deviate. In this case the properties are all WriteOnly, and so only sets are listed. In addition to the classes themselves, we can also represent in UML the class relationships. Relationships between classes are shown as connecting links and come in five varieties—dependen- cies, associations, composition, generalization, and aggregation. These links should also define the relationship’s multiplicity rules, which we will discuss shortly. When a class has as a member another class, we say that it depends on that class. This is then a dependency relationship and is drawn as a dotted line with an arrow pointing to the containing class. In the example shown in Figure 20.6, the Monte Carlo class depends on the Portfolio class and has a constraint that the F I G U R E 20.5 354 Object-Oriented Programming Team-LRN relationship not be empty. Of course, if there is no portfolio, there is no value at risk to calculate. A constraint, written in braces {}, requires that every implementation satisfy a condition. As you can see from Figure 20.6, as we begin to move outward and take a look at the bigger picture, we may start to abbreviate or even omit details at lower levels. An association is the most basic relationship and in UML is drawn as a line connecting the two classes. As Figure 20.7 shows, an association relationship exists between the Portfolio class and the Algorithms Package. If a class exists only as a member of another class, then the relationship is referred to as a composition within the containing class. A composition is drawn as a line with a solid diamond at the containing class end, as shown in Figure 20.8. In our trading system example, the OleDbConnection, OleDbDataAdapter, and DataSet F I G U R E 20.6 Unified Modeling Language 355 Team-LRN classes, collectively referred to as a Data Package, will exist only as members of the Market class. A generalization is equivalent to an inheritance relationship and is drawn as a line with a hollow arrow pointing to the base class, as you can see in Figure 20.9. Inheritance—or in UMI-speak, generalization—shows that Portfolio is a derived class of HashTable, and of course inherits all the attributes and methods of the parent. The Value property has also been added to the class Portfolio. An aggregation is a relationship in which several instances of a class belong to a Collection class. An aggregation is drawn as a line with a hollow diamond pointing to the collection. In Figure 20.10, an aggregation exists between Portfolio and Stock. The asterisk near the Stock class and the 1 near the Portfolio class represent the multiplicities. A single portfolio can have many stocks. Thus there is a one-to-many relationship between Portfolio F I G U R E 20.8 F I G U R E 20.7 356 Object-Oriented Programming Team-LRN and Stock. Since a Portfolio has Stocks as elements, the diamond is positioned near the Portfolio box. We could also add a StockOption to represent another type of element in a Portfolio. The multiplicity is the number of instances of a class that may be associated with a single instance of the class at the other end. The following table describes the most common multiplicities. Multiplicity Description 0 1 Zero or one instance 0 à or à Zero or more instances 1 One instance 1 à One or more instances The class diagram in Figure 20.11 models the entire Monte Carlo simulation application we will create later in the chapter. As you can see, the central class is the Monte Carlo class. F I G U R E 20.9 Unified Modeling Language 357 Team-LRN Object Diagram An object diagram is simply a snapshot of all the objects at any given time. Object diagrams show instances of classes, and objects come and go, sometimes rapidly. So object diagrams are useful for F I G U R E 20.10 358 Object-Oriented Programming Team-LRN explaining very small project pieces with highly complicated relationships, especially recursive ones. The object diagram in Figure 20.12 instantiates the class diagram, replacing it with a concrete example. Each rectangle in the object diagram corre- sponds to a single instance of a class. Instance names are underlined in UML diagrams. Class names are often omitted from object diagrams since the meanings are usually clear. Component Diagrams A component diagram describes the physical units of a software system and the dependencies between them. Software com- ponents, such as the executable files and library files, are often combined into a single system and as a result have relationships and dependencies between them. In UML, components are drawn as rectangular boxes, with two smaller rectangles sticking out the left side. Dependencies are F I G U R E 20.11 Unified Modeling Language 359 Team-LRN dashed lines with arrows pointing from the client component to the supplier component upon which it depends. The TraderAPI component contains an interface, shown in Figure 20.13 as a “lollipop.” The dependency relationship within this diagram indicates that the .exe file component refers to services offered by the TraderAPI component via its public interface. Deployment Diagram A deployment diagram illustrates the physical organization of hardware in a system. Each node on a deployment diagram represents a hardware unit, and communication relationships exist between nodes. Nodes are drawn as three-dimensional boxes and contain software components. Since the VaR model we have been following does not require any Internet or even LAN communication, we will show the hardware structure of an automated order routing system. The F I G U R E 20.12 360 Object-Oriented Programming Team-LRN deployment diagram shown in Figure 20.14 lays out the communication relationships between the hardware components involved in automated trade entry. BEHAVIOR DIAGRAMS A behavior diagram represents the different aspects of a system’s behavior. Use Case Diagram A use case diagram describes from an outside observer’s point of view what a system does, but not how it does it. A use case explains what happens when a hypothetical user or actor interacts with the system. An actor is someone or something that initiates an interaction with the system. Actually a use case is very much like a scenario or a simple case study where an actor interacts with a system and is provided services by it. The picture shown in Figure 20.15 is a simplified run VaR simulation use case. The actor is a financial engineer. The connection between actor and use case is a communication. Use case diagrams are helpful in determining system requirements. In fact, new use cases often bring to light new requirements as the system undergoes an evolutionary design cycle and changes are made. Further, their simple, graphical notation facilitates communication. A simple use case diagram can be expanded with additional features to display more information. The use case diagram in Figure 20.16 expands the original VaR simulation diagram with additio nal features for a simplified trading system. In this F I G U R E 20.13 Unified Modeling Language 361 Team-LRN expanded design, we could include the ability to place trades and populate a portfolio. Note again that the use case diagram does not represent any sequence; it simply shows the list of scenarios. A system boundary rectangle separates the system from the external actors—the financial engineer and the exchange. The <<uses>> relationship links use cases to additional ones, such as in the case Calculate Portfolio Value in Figure 20.16. Uses relationships like the one F I G U R E 20–14 362 Object-Oriented Programming Team-LRN [...]... engineering, 3– 7 Financial engineers, 4 – 5 Financial functions, 98– 99 Financial Information Exchange (FIX), 324, 325 Financial markets, evolution of, 3 Financial Markets Exchange (FMEX), 315 – 316 Financial Markets Markup Language (FMML), 303 – 320 Financial Products Markup Language (FpML), 324, 325 – 327 FinXML, 324 FIX (see Financial Information Exchange) FIX interface, 274 FIX Protocol, Ltd (FPL),... Extensible Financial Research Markup Language (XFRML), 324 Extensible Markup Language (XML), 272, 301 – 320 Extreme value estimators, 72 – 73 Team-LRN 387 Fair value, 58– 59 False condition, 96 “Fat tails”, 6 Fidelity, 327 Fields, 188 – 190 FillObj class, 283, 285 Finally block, 162 Finance.mdb database, 193 – 194 Financial abbreviations, 329 Financial engineering, 3– 7 Financial engineers, 4 – 5 Financial. .. R Nieto 2002 Visual Basic. NET: How to Program, 2d ed Prentice-Hall CHAPTER 16 Melamed, Leo 2002 “Derivatives Exchanges in a Changed World Order.” Handbook of World Stock, Derivative and Commodity Exchanges Mondo Visione Ltd CHAPTER 17 Black, Keith 2003 “Applications of Optimization in Financial Markets. ” A working paper Cernauskas, Debra 2003 “Maximum Likelihood Parameter Estimation for Financial Model... Flat-file structures, 187 Floor() function, 91 FMEX (see Financial Markets Exchange) FMML (see Financial Markets Markup Lanugage) For Each Next loop, 68 –69 Forecasting, 73– 77, 153 – 158 Foreign (forex), 329 Foreign keys, 191 Forex (foreign), 329 Format() function, 93 – 94 For Next loop, 68, 71 – 72, 135 FPL (see FIX Protocol, Ltd.) FpML (see Financial Products Markup Language) Friend keyword, 119... Microsoft Intermediate Language NQLX Nasdaq Liffe Markets NYSE New York Stock Exchange OOP Object-Oriented Programming RCW Run-time callable wrapper RDBMS Relational database management system RDM Relational database model SQL Structured Query Language STP Straight-through processing TT Trading Technologies, Inc UML Unified Modeling Language VBA Visual Basic for Applications VIX S&P 100 volatility index... October 23 “A Software Development Methodology for Financial Markets. ” Paper presented at the 11th International Conference on Software Quality, Pittsburgh, PA Kumiega, Andrew, and Benjamin Van Vliet 2003 “An Automated Trading System Development Methodology.” A working paper Rawlings, Bruce 2003 “In Sample versus Out of Sample Testing for Financial Markets. ” A working paper Royce, Winston W 1970, August... calculate value at risk using a Monte Carlo simulation Team-LRN This page intentionally left blank Team-LRN References CHAPTER 1 Bernstein, Peter 1992 Capital Ideas The Free Press Norman, David 2002 Professional Electronic Trading John Wiley & Sons (Asia) Pte Ltd Van Vliet, Benjamin, and Andrew Kumiega 2000, Winter “Obsolescence of the Naked Trader.” Journal of Global Financial Markets, pp 21 – 23 CHAPTER... diagrams in your own words 2 Explain the three methods described for calculating value at risk 3 How would you create an objects and program document using UML? 4 Describe each of the three categories of diagrams 5 What is a package? Team-LRN Unified Modeling Language 377 PROJECT 20.1 The beta of stock is the covariance of the stock with the market divided by the standard deviation of the market according... End Property Public ReadOnly Property Price() Get Return dblPrice End Get End Property Public ReadOnly Property Shares() Team-LRN Unified Modeling Language 371 F I G U R E 20.22 Get Return dblShares End Get End Property End Class We could calculate a stock’s beta using the historical price database, Finance.mdb, but for the sake of simplicity, we will leave this step out Step 4 Add a Portfolio class... Format(myPortfolio.Value, "###,###,###.00") txtVaR.Text = Format(myReturns, "###,###,###.00") End Sub Step 10 Run the program (see Figure 20.23) SUMMARY In this chapter we covered each of the 12 diagrams in UML, the Unified Modeling Language, and applied them to a Monte Carlo simulation for a portfolio of stocks The chapter example program was built from these diagrams According to the Kumiega–Van Vliet Trading System Development . Carlo class. The dblDaysA- head attribute, for example, will hold the time horizon of the Unified Modeling Language 353 Team-LRN simulation in terms of the number of days. DblIterations will hold the. picture, we may start to abbreviate or even omit details at lower levels. An association is the most basic relationship and in UML is drawn as a line connecting the two classes. As Figure 20.7 shows, an. trading system example, the OleDbConnection, OleDbDataAdapter, and DataSet F I G U R E 20.6 Unified Modeling Language 355 Team-LRN classes, collectively referred to as a Data Package, will exist only