Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 40 trang
THÔNG TIN TÀI LIỆU
Cấu trúc
Binder1.pdf
Binder4.pdf
Binder3.pdf
Cover.pdf
D.pdf
i.pdf
ii.pdf
iii.pdf
iv.pdf
v.pdf
vi.pdf
1.pdf
2.pdf
3.pdf
4.pdf
5.pdf
6.pdf
7.pdf
8.pdf
9.pdf
10.pdf
11.pdf
12.pdf
13.pdf
14.pdf
15.pdf
16.pdf
17.pdf
18.pdf
19.pdf
20.pdf
21.pdf
22.pdf
23.pdf
24.pdf
25.pdf
26.pdf
27.pdf
28.pdf
29.pdf
30.pdf
31.pdf
32.pdf
33.pdf
34.pdf
35.pdf
36.pdf
37.pdf
38.pdf
39.pdf
40.pdf
41.pdf
42.pdf
43.pdf
44.pdf
45.pdf
46.pdf
47.pdf
48.pdf
49.pdf
50.pdf
51.pdf
52.pdf
53.pdf
54.pdf
55.pdf
56.pdf
57.pdf
58.pdf
59.pdf
60.pdf
61.pdf
62.pdf
63.pdf
64.pdf
65.pdf
66.pdf
67.pdf
68.pdf
69.pdf
70.pdf
71.pdf
72.pdf
73.pdf
74.pdf
75.pdf
76.pdf
77.pdf
78.pdf
79.pdf
80.pdf
81.pdf
82.pdf
83.pdf
84.pdf
85.pdf
86.pdf
87.pdf
88.pdf
89.pdf
90.pdf
91.pdf
92.pdf
93.pdf
94.pdf
95.pdf
96.pdf
97.pdf
98.pdf
99.pdf
101.pdf
102.pdf
103.pdf
104.pdf
105.pdf
106.pdf
107.pdf
108.pdf
109.pdf
110.pdf
111.pdf
112.pdf
113.pdf
114.pdf
115.pdf
116.pdf
117.pdf
118.pdf
119.pdf
120.pdf
121.pdf
122.pdf
123.pdf
124.pdf
125.pdf
126.pdf
127.pdf
128.pdf
129.pdf
130.pdf
131.pdf
132.pdf
133.pdf
134.pdf
135.pdf
136.pdf
137.pdf
138.pdf
139.pdf
140.pdf
141.pdf
142.pdf
143.pdf
144.pdf
145.pdf
146.pdf
147.pdf
148.pdf
149.pdf
150.pdf
151.pdf
152.pdf
153.pdf
154.pdf
155.pdf
156.pdf
157.pdf
158.pdf
159.pdf
160.pdf
161.pdf
162.pdf
163.pdf
164.pdf
165.pdf
166.pdf
167.pdf
168.pdf
169.pdf
170.pdf
171.pdf
172.pdf
173.pdf
174.pdf
175.pdf
176.pdf
177.pdf
178.pdf
179.pdf
180.pdf
181.pdf
182.pdf
183.pdf
184.pdf
185.pdf
186.pdf
187.pdf
188.pdf
189.pdf
190.pdf
191.pdf
192.pdf
193.pdf
194.pdf
195.pdf
196.pdf
197.pdf
198.pdf
199.pdf
200.pdf
201.pdf
202.pdf
203.pdf
204.pdf
205.pdf
206.pdf
207.pdf
208.pdf
209.pdf
210.pdf
211.pdf
212.pdf
213.pdf
214.pdf
215.pdf
216.pdf
217.pdf
218.pdf
219.pdf
220.pdf
221.pdf
222.pdf
223.pdf
224.pdf
225.pdf
226.pdf
227.pdf
228.pdf
229.pdf
230.pdf
231.pdf
232.pdf
233.pdf
234.pdf
235.pdf
236.pdf
237.pdf
238.pdf
239.pdf
240.pdf
241.pdf
242.pdf
243.pdf
244.pdf
245.pdf
246.pdf
247.pdf
248.pdf
249.pdf
250.pdf
251.pdf
252.pdf
253.pdf
254.pdf
255.pdf
256.pdf
257.pdf
258.pdf
259.pdf
260.pdf
261.pdf
262.pdf
263.pdf
264.pdf
265.pdf
266.pdf
267.pdf
268.pdf
269.pdf
270.pdf
271.pdf
272.pdf
273.pdf
274.pdf
275.pdf
276.pdf
277.pdf
278.pdf
279.pdf
280.pdf
281.pdf
282.pdf
283.pdf
284.pdf
285.pdf
286.pdf
287.pdf
288.pdf
289.pdf
290.pdf
291.pdf
292.pdf
293.pdf
294.pdf
295.pdf
296.pdf
297.pdf
298.pdf
299.pdf
300.pdf
301.pdf
302.pdf
303.pdf
304.pdf
305.pdf
306.pdf
307.pdf
308.pdf
309.pdf
310.pdf
311.pdf
312.pdf
313.pdf
314.pdf
315.pdf
316.pdf
317.pdf
318.pdf
319.pdf
320.pdf
321.pdf
322.pdf
323.pdf
324.pdf
325.pdf
326.pdf
327.pdf
328.pdf
329.pdf
330.pdf
331.pdf
332.pdf
333.pdf
334.pdf
335.pdf
336.pdf
337.pdf
338.pdf
339.pdf
340.pdf
341.pdf
342.pdf
343.pdf
344.pdf
345.pdf
346.pdf
347.pdf
348.pdf
349.pdf
350.pdf
351.pdf
352.pdf
353.pdf
354.pdf
355.pdf
356.pdf
357.pdf
358.pdf
359.pdf
360.pdf
361.pdf
362.pdf
363.pdf
364.pdf
365.pdf
366.pdf
367.pdf
368.pdf
369.pdf
370.pdf
371.pdf
372.pdf
373.pdf
374.pdf
375.pdf
376.pdf
377.pdf
378.pdf
379.pdf
380.pdf
381.pdf
382.pdf
383.pdf
384.pdf
385.pdf
386.pdf
387.pdf
388.pdf
389.pdf
390.pdf
391.pdf
392.pdf
important.pdf
Local Disk
articlopedia.gigcities.com
Nội dung
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 FinancialMarkets Exchange (FMEX), 315 – 316 FinancialMarkets 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 FinancialMarkets Exchange) FMML (see FinancialMarkets 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