Using Visual Basic NET Databases to Create Pricing Trading R_9

Unified Modeling Language 353 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 thename 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 Team-LRN 354 Object-Oriented Programming F I G U R E 20.5 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 dependsonthat class. This is then a dependencyrelationship 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 Team-LRN Unified Modeling Language 355 F I G U R E 20.6 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 Team-LRN 356 Object-Oriented Programming F I G U R E 20.7 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 Team-LRN Unified Modeling Language 357 F I G U R E 20.9 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 theclass at theotherend.The following table describes the most common multiplicities. Multiplicity 0..1 0.. or 1 1.. Description Zero or one instance Zero or more instances One instance 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. Team-LRN ... - tailieumienphi.vn