1 Introduction 1.1 The problem The University of Fribourg is fortunate to count among its student associations der Schweizer Universitäten the Börsenspiel (BSU). This association with non-profit founded in 1991 organizes every year a variety of stock market simulation games on the Internet, one for students of High Schools and Universities Swiss. This simulation allows students to learn about financial markets and to link the theory taught courses and practice. To organize such a simulation, it is a group of motivated students, who have knowledge and interest in both the field of management (especially in finance) than in IT. It is also necessary to have an efficient IT infrastructure that is understandable by computer scientists but also managers. It is sometimes difficult to organize and coordinate the work of people from different fields; lack of common language, communication is sometimes more inefficient. In general, student associations, very little time is devoted to the analysis process and the organization again, there is very little documentation of tasks and software.
1.2 Objectives To overcome this lack of organization, this work aims to analyze the features that are covered by the simulation software market of the association and suggest improvements. These improvements will be modeled and then implemented in a prototype. A project management approach based on Rational Unified Process (RUP) will be used for analysis, modeling and implementation. In a first phase, the various processes needed to manage the game will be modeled using "Use Cases" Unified Modeling Language (UML). This will allow us to have a global vision of all the functions to be done to manage the simulation using a common language with standard UML. In a second phase, analysis of the weaknesses of the process will help identify potential for improvement. Especially for this phase, the understanding of the business logic is essential. The logic includes the operation of various financial tools that can be traded in the simulations (stocks, options, bonds, currencies, ETFs, etc..) And the operation of the Exchange and certain concepts of finance. Great potential for improvement is, apparently, in the configuration of the simulation game. Indeed, often, managers have to deal with parts of the configuration of the game such as: responding to ads purchase, merger or any other stock market news, insert the names and currency values chosen for the game in the database, the value of a splitter action, observe the strategies of the players to make comments and constantly improve the game, go missing classes, etc.. These are tasks that, in the current state of the architecture of BSU, ask the person knowledge of finance and IT. It's the same for the configuration of the game that can be performed only by computer scientists or people with good computer skills: there would be a big efficiency gain if it could be done from one place of BSU architecture and by someone without extensive knowledge of the application. In a third phase, more detailed modeling of the Use Case "Configuration of the Game" will lead to a change in the current architecture to a solution of three-tier architecture and multi-thirds. In a fourth phase, the architecture of current BSU will face a description of the three-tier architecture ideal. This confrontation will come out the benefits of a well-defined three-tier architecture, including the largest: the separation of "business logic" of the "view". And an interface to administer the game, which will be easy to use for non-computer and only will be created. The last phase will consist of the choice of technologies (. Net, Ruby on Rails or other) to create this interface, the implementation of a prototype and testing. The four phases of RUP - Inception, Elaboration, Implementation, Transition - have been well covered and the process improvement project completed. 1.3 Implementation method What are the different financial tools and financial characteristics to consider in setting up a stock market game? It is essential to know the business logic of the financial stock market game in order to improve its configuration. For this first chapter will be dedicated to the financial aspects of the game This question will be answered by observing the game and literature. How do I make a change in the information system of a company? An IT project can be completed, if it does not follow a clear methodology. For this it is necessary to choose a methodology that has already proven itself. This question will be answered by the literature. What features are expected by the stakeholders to set up the game? It is essential to propose a solution that meets the needs of stakeholders, for that you need to consult them before. This question will be answered by the empire. Which architecture is most appropriate for BSU? (What change in terms of architecture is that) This issue will provide the backbone of the project and show the benefits of change of architecture. This question will be answered by the literature. What are the technology. NET, ASP.NET and ADO.NET? (Qelles. NET technologies should be used?) Before choosing a technology is definitely needed to know how it works, its advantages and disadvantages. This question will be answered by the literature. Will the new interface is beneficial to a better configuration of the game? It is not enough to predict the action, we must also act to at least see the consequences for this prototype interface will be implemented and tested. This question will be answered through programming and successive tests.
2 The business logic: a description of various tools and features to consider in setting up a stock market game Before dealing with the technical and implementation of an IT project, it is necessary to dwell on the business logic of it. In the case of the BSU, the stock knowledge of the principles underlying the simulation is of major importance. The administrators of the game should be familiar not only with business logic implemented by the BSU program, but also with the Swiss stock market reality. Indeed, for reasons of simplification, it differs in some points from that modeled in the application BSU. The result is that an administrator should be notified aware of these differences to properly configure the simulation. To this end, this second chapter presents a practical description of knowledge and scholarship required a direct confrontation with the implementation made by the BSU. It answers the question: what are the different financial tools and financial characteristics to consider in setting up a stock market game? 2.1 Simulation Portfolio Management (PMS) 2.1.1 Concepts of simulation The simulation organized by the BSU for students of Swiss universities called Portfolio Mangement Simulation (PMS). For eight weeks, players manage a wealth of CHF one million and may invest in financial instruments described in Section 2.3. Orders placed during the day are executed at the closing of the day. Participants have two portfolios: 1. a portfolio, said Classic, with a limitation of options to purchase 5% of the portfolio with the purchase. Two rankings are calculated on this one: • Performance: only returns obtained over the entire period of the game account • Risk Management: profitability and risk are taken into account using the Sharpe ratio (see Section 2.1.2). 2. a portfolio, said derivative, consisting only of Eurex options: one Derivative classification is calculated on this portfolio according to profitability [BSU 2008]. 2.1.2 Classification Measures Players To determine the rankings discussed in the previous section, it is necessary to have two different measures: one takes into account only the profitability, the other combining it with the risk. Simple returns The simple returns on assets are measured as follows:
or RFIN which is simple profitability over the period of play; Pfin Pdébut and prices are holding at the end respectively at the beginning of the period of play To calculate the performance rankings and derivatives, simple returns for each portfolio are calculated. The player with the highest profit wins. Sharpe ratio By its nature, the stock market simulation contains a bias against a real portfolio management: as the money is fictional, investors have less risk aversion. To correct this distortion, a measure of performance taking into account not only profitability but also the risk should be used. Several measures exist to account for risk in performance calculations. The Sharpe ratio, Treynor and Jensen alpha are classic examples. At the BSU, is based on the Sharpe ratio that the classification is made Risk Management. The Sharpe ratio is the measure most used by the investment fund industry in the United States. Ex-post definition is:
Where RPF is the profitability of the portfolio measured PF, Rf is the risk free interest rate, is σPF volatility of portfolio returns. SRPF indicates profitability received in excess of the risk-free rate, per unit of risk. The higher the ratio, the better the compensation for the risk taken by the investor, so the better its performance. Volatility is a measure of risk used here. Several limitations must be observed when using this ratio. First, the Sharpe ratio depends on the risk-free interest rate used. Several different classifications may well result, hence the importance of choosing the risk-free interest rate. Second, the Sharpe ratios of non-zero positive and are unusable. It is possible that the profitability of a portfolio is less than or equal to the risk-free rate. A ranking of portfolios by size of their Sharpe ratio would lead to an erroneous result [Steiner and Bruns 2002]. Calculation of the ranking at the BSU At the BSU, the risk-free interest rate used is the one month Libor rate. It is updated once at the beginning of each game The variance is, in turn, calculated by the program using the simple daily returns of the portfolios of the players. The use of simple returns to the classic formula of the variance result in systematic errors which are generally of lesser magnitude. In practice, this is done quite often for reasons of simplification. The use of instant returns would be many times more accurate to calculate the variance of returns [Isakov 2006]. Instant profitability profitability continuously made. It has the advantage of being additive and to calculate the variance due to non-geometric and arithmetic mean
2.2 Financial markets: Swiss Infrastructure and Exchange (SIX) Swiss Exchange and Eurex The organization of a stock market simulation depends largely on available financial data. Those used to come from the BSU Financial Quote Service (FQS). FQS is a service of SIX Swiss Exchange that allows you to receive financial data for securities listed on SIX Swiss Exchange, SWX Europe and Scoach Eurex, the data on stock indexes and currencies are also available [SWX 2008a]. BSU does not currently market data Scoach structured products, for that reason, this chapter will focus on SIX Swiss Exchange and Eurex. 2.2.1 SIX Swiss Exchange As of September 30, 2008, called the Swiss Stock Exchange SWX Swiss Exchange [Group 2008]. It is one of the first fully electronic exchanges in the world. Since 1996, the system takes care of sending the order to final settlement according to the latest techniques. The brokers will negotiate more at auction, but return their operations in computers installed in the banks. Electronic Exchange The electronic exchange provides significant advantages: 1. Liquidity is increased, that is, the probability for a seller to find a buyer is greater. 2. There is greater transparency: all courses paid for and traded are known, the market is well visible in its entirety. 3. With the streamlining of procedures, transaction costs are lower. 4. Trading is continuous on all securities in unlimited amounts throughout the opening day of the grant [Schneider 2008]. Trading on the SWX Swiss Exchange is centralized and organized according to the orders ("order-driven market"). This means that liquidity in this market is guaranteed by the individual orders and do not require market-making, in contrast to Eurex (see section 2.2.2) [SWX 2008b]. Figure 1 shows the electronic system of the Exchange SIX Swiss Exchange: • The trader is made available to all banks in Switzerland and abroad, practicing securities trading business and being accepted as participants associated with the SIX Swiss Exchange. With this technical infrastructure, agents can participate in exchange operations. • The Exchange sends the information to the trading system traders. He collects the orders and sales in a central order book and automatically matching according to very precise rules. • The Gateway is a portal or filter whose function is to ensure fair treatment of all members participating in the stock market and acts as a network security system between the traders and the System of the Exchange. • The Settlement Communication System (COMSEC) and Swiss Interbank Clearing (SIC) are responsible for the settlement (liquidation), respectively Clearing (clearing). Transactions are automatically transmitted from the Exchange System SECOM and SIC. • The Swiss Market Feed (SMF) records all data on the real-time market of securities traded on the SIX Swiss Exchange [Exfeed 2008]. It is a source of FQS.
Figure 1: System for Electronic Exchange SIX Swiss Exchange [Schneider 2008]
Organization of the SIX Swiss Exchange SIX Swiss Exchange is one of 100% of the division of trading in cash (Cash Market Division) of SIS Group (formerly, Swiss Financial Market Services AG) and offers three types of investment vehicles. They are traded, respectively: • the stock market: stocks, shares, participation certificates, bonus certificates (see Section 2.3.1); • the bond market (bonds): Bonds of Borrowing (straight bonds), variable rate bonds (floating rate bonds), Zero-coupon bonds (zerobonds), dual currency bonds, subordinated borrowings, convertible bonds (convertible bonds), loans to Loan Participation Notes option (see Section 2.3.2); • the market for Exchange Traded Funds (ETF) Exchange Traded Structured Funds (ETSF) and investment funds: investment funds and individual funds, ETFs, ETSFs and investment companies with variable capital (SICAV) (see Chapter 2.3 .3). Market shares of the SIX Swiss Exchange are treated all securities other than securities SMI / SLI. They are traded on SWX Europe is the award-Helvetian UK securities and ETFs leaders in Europe. SWX Europe is 100% owned by SWX Swiss Exchange.) Since 1 January 2007, all derivatives admitted to the SWX Swiss Exchange are traded on the trading platform of Scoach. This is the first European exchange for structured products, warrants and certificates are traded. Scoach was created by Deutsche Börse and SWX Swiss Exchange. One of the largest futures markets in the world, Eurex is owned by Swiss and German stock exchanges. Thus, SIX Swiss Exchange plays an important role in derivatives (see Section 2.2.2). The leading European indices such as Stoxx and Swiss Fund Data are also part of the group with SIX SWX Exfeed, which is the company responsible for market data on the SIX Swiss Exchange and SWX Europe [SWX 2008b]. The other group entities are SIX SIS AG, which is responsible for processing and filing of domestic and foreign securities [AG 2008] Finally, Telekurs is active in the fields of international financial information, transactions and card payment systems electronic payments [Telekurs 2008].
Figure 2: Organization of the SIX Swiss Exchange [SWX 2008b]
Order types There are several types of possible orders to the Exchange: normal order (normal order), with iceberg order (hidden size order), order acceptance (accept order), order fill-or-kill order, and if (conditional order) [Schneider 2008]. The types of orders to the BSU For now, participants in the simulation can only place orders normal so-called "best", that is to say that the orders are executed in any case, whatever the price. In the context of the BSU, orders and orders to normal condition (Stop Loss, One Stop Order and stop-limit) are interesting. In [Shehu 2008], the ability to add orders limited to the BSU game was analyzed, it is to date not yet implemented. Commissions and taxes of trading Stock exchange are the following costs: • Brokerage: commission that banks charge their customers as service provision for the execution of trading orders. Each bank sets its rates individually. [Zindel 2008] compares the brokerage fees applied in Switzerland in May 2008. It appears that there is great variation from one bank to another. • Federal Stamp (stamp duty): Tax paid if one of the contractors or intermediaries is a securities dealer. • Stock exchange tax SIX Swiss Exchange: Stock exchange tax paid by the bank on the SIX Swiss Exchange. Each product segment has its specific trading costs. Cost to the BSU At the BSU, for simplification, only brokerage fees are collected. Custody or administration fees, which are management fees charged by banks to hold the securities in deposit, are not considered either.
2.2.2 Eurex Eurex is one of the leading derivatives exchanges around the world. It is a corporation equally owned by Deutsche Börse AG and SIX Swiss Exchange. Its electronic trading system allows it to offer a wide range of international products at relatively advantageous. Figure 3 shows the increase in the number of contracts per segment for the year 1999 to 2007 at Eurex. The evolution of the exchange Eurex following the global market for derivatives traded on organized markets. Indeed, as documented in [Novello 2007] the market does not know the crisis and continues to grow since the beginning of the millennium.
Figure 3: Evolution of volumes by product segment (contracts in millions) [Eurex 2008]
Specificity of the derivatives market Compared to the SIX Swiss Exchange, Eurex has some specific characteristics of the nature of its futures. One of the biggest differences is Eurex is a market with a hybrid structure, also called "quote-and-order-driven market". This means that all investors can advertise the prices at which they are willing to buy and sell ("order") but in addition, special players in the market, called "market-makers" must make their offers ("quotes") for products for which they are responsible [Ranaldo 2007]. Orders and quotes are inserted throughout the trading day in the central order book, where the matching is performed [Eurex 2008]. The market-makers, often employees of international investment banks, are obliged, when they receive a request to submit a bid and sales. This application is called "Quote Request" and is, nowadays, in general, fully processed by computer: the trader enters the computer the settings and the system calculates the price. The existence of market-makers and provides liquidity to the market. Another big difference compared to Eurex from a spot market is the existence of the clearing (Clearing House). This assures the buyer that the contract will be accomplished. It manages all transactions, maintains the accounts and makes margin calls. They are a mechanism to ensure that the investor will not default if, for example, one option would be exercised by the buyer [Hull 2003]. The mechanism of the margin call works like this: if an investor has sold such options, the structure of the contract that cash flow will be zero or negative at the time of exercise. To guard against the future risk, the amount of collateral (margin) to be paid on a deposit account. After each market close, the positions of investors are valued ("marked to market") and the margin should be adjusted accordingly. If the investor bought an option, its cash flows will be zero or positive, it will not need to provide security [Eck, Langer and Riechert 2006]. The prices used to value positions of investors called the settlement price (daily settlment price). The daily settlment price is calculated each evening using the Eurex binomial model of Cox / Ross / Rubinstein option pricing for stock options and using the model of Black / Scholes 76 for index options [Eurex 2008]. Implications for BSU These characteristics are important to the Eurex simulation of BSU for several points. First, thanks to market-makers and the daily settlement price, it is possible to have a way (buying and selling) every day and an evaluation of each option market closes, even if n ' has not been traded during the day. This makes possible the negotiation of option in the simulation even when the contract was entered into the Eurex will and therefore no closing price will be available. The organizers of the BSU evaluate options, in this case, the price of the daily settlement price. Second, at present, it is possible to buy options in the Eurex simulation BSU. It is not necessary to take into account the margin call for the simulation.
The products traded on the Eurex Eurex offers a wide range of derivatives: interest rates, equities, equity indices, volatility indices, ETFs, funds, inflation and CO2. In addition, the product offering continues to grow. Of all the instruments, future and options are the most traded. The products traded on Eurex BSU For the simulation of BSU, only stock options and index futures are currently used. At Eurex share options are American style. Index options are usually European-style [Schneider 2008]. As to the BSU, the options can not be exercised, is not the type of difference (see Section 2.3.5).
Types of Orders At Eurex, there are several types of orders: market-order, with a limit order, stop and combination [Eurex 2008]. Types of orders to BSU At the BSU, only the order-order market exists, that is to say the order is executed in any case whatever the price. In [Shehu 2008], the ability to add orders limited to the BSU game was analyzed, it is to date not yet implemented.
Transaction costs to the Eurex Transaction costs include the costs of Eurex trading and clearing. They vary by product and product group. Fees charged by Eurex, the broker added those that can be very different from one another. Transaction costs to BSU At the BSU, for simplification, only brokerage fees are collected.
Other kinds of options traded in Switzerland Eurex options are not the only ones that can be negotiated in Switzerland. Indeed, there are two kinds: 1. Warrants: The warrants are traded on the stock exchange Scoach. Their main difference from the Eurex options is that they can be of purchased (position called "long") and not sold by investors. 2. Options over-the-counter (OTC) option or by mutual agreement: the contract is concluded off-exchange directly between buyer and seller. The advantage of such an option is that they can be tailored to customer needs. At BSU At the BSU, for now, only the Eurex options are used.
2.3 The financial tools 2.3.1 Actions Definition A share is a variable income, representing a fraction of the equity of a public company. The action gives the holder: • social rights: right to vote at the general assembly, right to consultation, right to elect and be elected in the election of an organ of society, right to challenge decisions of the meeting general right of control, • economic rights: the right to a portion of the profits, right to subscribe for new shares in a capital increase or entitled to a portion of the proceeds of liquidation in the event of liquidation [UBS 2008]. Value The value of a share can be estimated using the Gordon model. The latter is based on the updating of all future cash flows generated by the action: dividends and resale price [Brealey, Myers and Lehman 2003].
Equity trading on the BSU At the BSU, the following types of actions, traded on the SIX Swiss Exchange and SWX Europe, are used: • Bearer shares: the action is freely transferable; • shares: the shareholder must be registered in the register of shareholders; transmission is more restrictive; • participation certificates: This title can be issued in bearer form or in the name of the participant. It confers rights similar to those attached to ordinary shares; except that it incorporates only economic rights but not social rights. At the BSU, participants buy and sell shares at the closing of the title, plus brokerage fees. They receive gross dividends to the date of distribution of the latter. Contrary to reality, participants in the game does not have to pay the withholding tax on dividends.
2.3.2 Obligations Definition A bond is a fixed income. It is a loan and long-term negotiable securities issued by companies or bodies governed by public law [UBS 2008]. Value The value of a bond can be estimated by discounting all future cash flows generated by the duty: interest and final repayment [Brealey, Myers and Lehman 2003]. The value of a bond, also called dirty price, can be divided into: • During clean-coupon price or a percentage of nominal; • accrued interest, also expressed as a percentage of nominal.
The dirty price P is the price paid by the bond purchase. Fl is the accrued interest by multiplying the fraction of the Year by the amount of the coupon. The clean price C is the dirty price without accrued interest. So there is the relation. The course published by the SWX is a clean price. Bonds trading at BSU At the BSU, the following types of bonds traded on the SIX Swiss Exchange are used: • fixed-rate bond: the payment of interest is the nominal value multiplied by the interest rate; • zero coupon bond: no annual coupon, but it is trading well below their redemption value; • perpetuity: it has no repayment or amortization. BSU bonds are bought and sold in the clean price, unlike the stock market reality, accrued interest are not taken into account during transactions. Interest is calculated on the period, however, holding bonds and are added to the amount of interest deposit account. Thus, there is a bias in the game compared to the reality of the BSU players can buy more bonds in the game that he could do in the stock market with the same amount of money, the fact that he should not pay interest. It may well affect the interests of more titles and the value of its portfolio will be exposed to lower and higher bond prices. Contrary to reality, participants in the game does not have to pay the withholding tax on interest.
2.3.3 Exchange Traded Funds (ETF): Definition An exchange traded fund (ETF), also known as tracker is a fund that is traded on the stock market and reflects the evolution of the course and the performance of an underlying index. The latter can be based, among other things, on the market: stocks, bonds, commodities, real estate and money market. ETFs are experiencing a growing success since their introduction in 1993 because they offer significant advantages: • First, unlike traditional index funds, they are exchange traded. Market makers must ensure liquidity. • They have management costs generally lower than traditional investment funds, due, among other things, their replication purely mathematical index (passive management). • Publication of the indicative net asset value (iNAV for indicative net asset value) at all times by the exchange provides the investor the highest transparency. It is possible to know at all times the difference between the intrinsic value of the ETF and the price listed. It is possible that the price of the ETF rises gradually above its underlying index, while dividend payments of the securities comprising the index are made. This gap is decreasing as the ETF itself pays a dividend. The Manager of the ETF issues new shares and buys any investor wishing. This has the effect of increasing the collective wealth and the number of shares outstanding, in the event of an issue and in case of redemption, reduce the collective wealth and the number of shares outstanding. This opportunity to buy and sell shares on the primary market allows ETFs are traded on a course close to the secondary market iNAV [SWX 2008b]. Value The intrinsic value of an ETF is called iNAV [Novello 2007]. It is calculated by the SIX Swiss Exchange permanently by adding the price of the securities included in the background and dividing by the number of shares outstanding [SWX 2008b]. Figure 4 shows in blue the price of the ETF iShares DAX and his black iNAV. As it emerges, the ETFs are trading at a price close to the indicative net asset value. Only for a short time, there are differences of a few cents. The investor has to have security at any time, a fair price for an ETF [Eibl 2008]. Figure 4: Evolution of the ETF iShares DAX and its iNAV [DeutscheBörse 2008]
ETFs trading at BSU ETFs are not yet available in the game of the BSU. However, as their importance is growing, it would be to think about vigilantes. They do not require more specific implementation, they can be treated in the game such as stocks. Indeed, as the latter, they generally still have a course and a theoretical value, they pay dividends and purchase and sale result in brokerage commissions and trading. One of the only differences is that the fund management of the ETF takes, in addition, management fees that impact on the evolution of periodically over the fund.
2.3.4 Currency Definition A motto is a debt denominated in a foreign currency payable abroad. It may take the form of an ave or paper value [UBS 2008]. The big difference compared to other trading values used in the play of BSU is that currencies are not traded on an exchange but OTC: treat all partners directly. The major players in these exchanges are banks that form a network: the interbank market. The currency market, also known as Foreign Exchange (Forex) is a global market. He suffers no temporal restriction: you can trade currencies 24 hours over 24 hours. A trading day begins in Asia, Europe continues to finish in the United States. A big disadvantage of trading currencies is the limited choice of liquid currencies. The fact is, in fact, that few in comparison with, for example, actions in which there are hundreds. Transaction costs are relatively low, as a rule, only the spread (difference between bid and ask prices) is seen as indirect costs [Metz, 2007]. Value To assess the exchange of one currency, there are several models that focus on only a few influencing factors. The theory of purchasing power parity and interest parity are two examples known. There is another approach to fundamental analysis, which monitors all relevant economic data and to identify future influence on prices. Data on the political situation, economic situation, monetary policy, interest rates and speculation are used [Metz, 2007]. Forex trading at BSU At the BSU, the few most liquid currency market are used. As usual in practice for a single deposit, players receive no interest. Transaction costs are similar to other stocks traded on the BSU, which is relatively expensive in comparison with reality, where only the spread is taken. As currencies are traded continuously and CTA, the import of foreign exchange for the game is made for more or less regular hours and the same supplier.
2.3.5 Options Definition An option is a contract between the buyer of the option, called the owner and seller, called a party. It gives the holder the right to buy (call) or sell (put) to a predetermined date (maturity date) and a fixed price (exercise price) a certain quantity of goods or a number of shares (underlying asset) in return for immediate payment of a premium (option premium) to the signatory. One option is a derivative asset that is to say, it derives its value from the evolution of the underlying asset. In the graphs Figure 5 and Figure 6 are shown the pay-offs of the holders of a call, respectively, a put based on changes in the price of the underlying asset. The pay-off of the holder of a call becomes positive when the price of the underlying exceeds the option premium p paid plus the exercise price K paid. The loss of a long position (position holder) of a call is limited, while the gain is unlimited. The pay-off of the holder of a put is maximized when the price of the underlying asset is zero. The gain is thus equal to the exercise price less the premium received K p paid, it is limited, as the loss is at most equal to the amount of the premium p [Hull 2003]. Figure 5: Pay-off of the holder of a call [Wikipedia 2008]
Figure 6: Pay-off of the holder of a put [Wikipedia 2008]
Two types of option are: • American options: they may be exercised any time until maturity; • European options: they may be exercised only at the maturity date. Options contracts traded on Eurex are, they represent a number of different options depending on the option chosen. The course Eurex indicates the price of an option, we must multiply by the size of the contract to determine the transaction price [Brealey, Myers and Lehman 2003]. Value There are several kinds of models to evaluate options: analytical models (Black and Scholes model and its extension), numerical models (binomial, trinomial, Monte Carlo simulation, etc.). And models of analytical approximation. These models are used, among other things, to determine the price of compensation (see Section 2.2.2) [Brealey, Myers and Lehman 2003]. Trading in options to BSU At the BSU, two kinds of options are traded Eurex: • Stock options: the underlying action, • index options: the underlying is an index. The organization of a stock market simulation with options is more difficult than in cash only. Some simplifications must be implemented, the following are an example: • Contrary to the Eurex trading done, it is not possible in the game BSU to become a signatory of an option. A short position (position signatory) of an option is more risky than long positions: the maximum loss not just to the premium paid at the beginning of the contract (as a long position). The cash flows for a short position is always positive for sale (receipt of the premium) and may develop negative thereafter. Why margin calls (see Chapter 2.2.2) are made in practice. For the simulation, this means, among other things, that the value of the margin should be calculated every night and the positions of the players taking too much risk should be closed. • In the simulation, it is not possible to exercise options. The difference between American and European options becomes insignificant. It can be shown that in practice, in general, it is anyway not profitable to exercise an option before its maturity date. It is better to sell it and buy the stock separately, rather than exercising the option. • If an option is not negotiated for the day on the exchange Eurex, she has no last price (Last Price). To continue to use it in the simulation, it is necessary to use a different estimate of its value which is the settlement price (daily settlement price) (see Section 2.2.2). • The transaction options fell to a penny is suspended in the simulation. In reality, if they again became attractive, they will be bought at a higher price. Blocking options also offer the opportunity to protect the players, who want real influence over the options for cheap and win the simulation. Choosing options for the simulation with a longer maturity reduces the probability of having the options to one cent, as time is a component which positively influences the option price. Options with a maturity closest in time are, right time, more interesting to negotiate.
2.4 The stock market events can disrupt the game In the two months of simulation, it is possible that business activity creates adjustments in the game This chapter briefly describes the disruptive events and required actions by the directors BSU. 2.4.1 Split A split of a stock is the division of its nominal value. As this does not change the value of the company, it should not affect shareholder wealth. All things being equal, the share price should be divided by the number of new shares received (n) for an old (m) and the number of shares should be multiplied by this same factor, the wealth should be continued the same. For options, the contract specifications are changed to reflect the expected change in the share price. The exercise price must be multiplied by the factor m / n and the number of shares underlying an option contract must be multiplied by n / m. If the share price decline in the proportions expected, the total contract value is unchanged [Hull 2003]. Treatment of a split in the BSU In the game, simplifications have been introduced: • for the shares, their number remains unchanged, but the course is multiplied by n / m; • For options, the exercise price multiplied by m / n, the number of shares corresponding to a contract remains the same and the course is multiplied by n / m. 2.4.2 Merger and Acquisition In the strict sense, an acquisition means that a company called initiator, buys another company, called target. The latter thus ceases to exist and only the actions of the initiator still being negotiated. In a merger the two companies, more or less equal size, agree to continue their existence into a single entity. The shares of both companies are replaced by new joint. In practice, few mergers between companies of equal size. In general, the larger of the two companies bought the other, but for reasons of communication, it is quite common to talk of a merger, even though technically it is an acquisition. An offer directly to shareholders is a possibility to form of acquisition. To protect small shareholders, the law requires companies that want to take control to make an offer to all shareholders. At the exchange, two kinds of offers are commonly used: • Tender Offer (OPA): a cash amount offered in exchange for shares of the target company. • exchange offer (OPE): the offeror offers shares in exchange for shares. These offers may be hybrid, that is to say, consist of part cash and part in shares [Brealey, Myers and Lehman 2003]. Treatment of a merger with the BSU In the simulation, once a company is acquired or merges, actions and options are sold at the last force in effect. 2.4.3 Bankruptcy A bankruptcy is the forced sale of the total assets of a debtor on the register of trade following its inability to pay. The proceeds of the realization is then divided among creditors [UBS 2008]. When a company went bankrupt its shares have lost value. Treatment of bankruptcy at the BSU In the game, shares and call options of a company bankrupt are estimated at CHF 0 .- The options are sold puts strength.
3 The analysis of an information system An IT project can be completed, if it does not follow a clear methodology. This chapter provides an answer to the question: how to make a change in the information system of a company? To answer this question, a methodology that has proven will be presented: Rational Unified Process (RUP). Disciplines "Code requirements," "Analysis and Design", "Implementation" and "Test" are described here in order to be applied in the practical part, in Chapters 4, 5 6. Two techniques used in this process will help the development: modeling and prototyping. 3.1 Methodology Project Management: Rational Unified Process (RUP) 3.1.1 RUP: a methodology for project management Definition Rational Unified Process (RUP) is a methodology for managing projects. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its purpose is to ensure production of quality software that meet user needs and whose development respects the constraints of budget and time. RUP has been designed and documented using the UML (see Section 3.2.1) [Kruchten 2001]. History The first version of RUP, version 5.0, was created in 1998 by the company "Rational". The latter was founded by the same authors of the early versions of UML Booch, Rumbaugh and Jacobson. RUP is the result of a long process and based on best development practices. Its chief architect is Philippe Kruchten. In 2003, Rational was acquired by International Business Machines (IBM). The latest version (7.0) was released with the announcement of IBM Rational Method Composer (RMC) in November 2005 [Rajalekshmi 2008].
Rational Method Composer (RMC) RMC is a commercial product to create, configure, visualize and publish processes as Web pages. RUP is an integral part as a vast library reusable [IBM 2008a]. Figure 7 below shows a page from the published ORs with RMC. RUP is a process known as delivery of RMC. These processes are complete for a certain type of project they are a starting point to plan and rapidly initiate a project. The wider process of delivery is the Life Cycle Classic RUP, RUP is similar to version 6.0. For small projects, the life cycle for small project RUP is preferred. It does not prescribe or business modeling discipline, or discipline of deployment, some products were discontinued and a few other changes were made. The life cycle of business modeling and architecture modeling and service-oriented ORs are two other delivery process [Admiraal 2007a]. RMC also contains patterns of capabilities that are pieces of reusable processes addressing common problems. The Figure 10 and Figure 13 are examples of patterns of abilities. The Framework process RMC enables the expert to adapt RUP process to each project by making available an architecture and construction groups use [Rajalekshmi 2008].
Figure 7: A RUP page customizable by RMC [IBM 2008b]
Key principles for business-driven development RUP version 7.0 was a major update of its practices now call the Key Principles for Business-driven development. They are described briefly below: • Adapt the process: the size of the development process must be adapted to the needs of the project. For example, for a limited project, involving a local team and a known technology, the process should be made so simple. • Balancing the priorities of stakeholders: stakeholders would like to have an application that does exactly what they want to do while minimizing the cost of development and planning time, but these goals often conflict. It is therefore necessary to manage requirements effectively, understand and prioritize. • Collaborate across teams: this answers the questions: How to motivate his team to make it successful? How to work in a team software distributed or localized in one place? How to establish a collaboration between sales teams, IT and software development? • Demonstrate the value iteration: an incremental value can provide an early and continuous feedback information in order to be able to adjust plans, process key risks early in the life cycle, to consider and manage change. • Raise the level of abstraction: visual modeling using UML and the focus on architecture development team helping to raise the level of abstraction and prevents it goes directly to the code requirements. To reduce complexity, it is also important, among other things, to reuse existing solutions, using high level languages, frameworks and patterns of applications. • continued focus on quality: in RUP, the software developed at each iteration is tested in conjunction with its construction. This allows a noticeable improvement in the quality [IBM 2008b].
Unified Method Architecture (UMA) The meta-model which is based on RUP to describe its process is called: Unified Method Architecture (UMA). It can support multiple models of different life cycles: life cycle RUP iterative development, life cycles cascade, etc.. The UMA specification itself has been submitted to the Object Management Group (OMG) as proposed meta-process model of software engineering (Software Process Engineering Metamodel: SPEM 2.0) [IBM 2008b]. The main principle of UMA is a clear separation between content and method of its use in the temporal unfolding of a process. Content method described in detail the tasks to be performed (regardless of time dependencies) for a product and know-how to get there. The unfolding process gives the content of the method after a time and allow adaptation to very different types of projects. Figure 8 shows an overview of key concepts of the architecture UMA [Essigkrug 2007]. The following concepts are represented: • A product (formerly Artifact) answers the question: what is the result? • A task (formerly Activity): Describes how something should be done. • A role-sets the responsibility for certain tasks. • An activity (formerly detail the sequence of activity) is the component of a process as fundamental. • A pattern of capacity and delivery process: cf. above. • Advice: instructions are, for example, techniques and information to build a product or perform an activity [Krebs 2008 and Shuja, S. 5].
Figure 8: Overview of key concepts of the UMA architecture [IBM 2008b] Unlike the sequential methods, like the cascade model, RUP is a methodology based on an iterative and incremental [Corporation 1998]. Figure 9 shows the two dimensions underlying RUP: • The horizontal dimension: is the dynamic aspect, that is to say processes. A development cycle is divided into phases and iterations. • The vertical dimension: is the content of the method or discipline. These are the grouping as inclusive as possible of the contents and methods of gathering all the tasks that match a particular area [cf.Essigkrug 2007]. The colored surface represents the intensity with which each discipline shall be held within each phase. As [Brandon and Brothers 2006] notes, RUP, iterative in nature, has a lot of overlap in the application of methods of its contents, for example, application components are tested only at the end of construction, but steadily, from the creation phase.
Figure 9: Static and dynamic aspects of RUP [IBM 2008b] Reviews Despite the flexibility offered by RMC to configure RUP to their needs, many criticisms are heard. [Brandon and Brothers 2006], for example, RUP does not consider appropriate for all software development projects. Specifically, he finds that for large internal projects and risky when it is necessary to quickly deploy a portion of the proceeds, RUP can be satisfactory. Wolfgang Hesse also expressed his criticism in one of his most famous articles [Hesse 2003]. He blames the OR, among others, his approach too focused on too much like the phases to phases of cascade model. It can not arise, according to his analysis, a methodology focused on architecture, prides itself as the OR of being. In [Riaan, Stefan and Derrick 2007], RUP is still described as being very expensive to implement. Using RUP in this work In this master thesis, to satisfy the key principle of RUP "Adapting the process," a lighter version of the delivery process for small projects will serve as a guideline. To "raise the level of abstraction," UML modeling techniques and prototyping will be used. Disciplines and techniques used in this work are described in more detail in later chapters. 3.1.2 Code requirements The purpose of discipline requirements gathering is to describe what the system should do and allow developers and customers to agree on this description. To achieve this goal, the required functionality and constraints must be expressed, organized and documented the compromises and decisions must also be documented [Corporation 1998]. Gather user requirements is central to a project to develop software and should not be underestimated. For this reason, RUP is based on use cases as a thread throughout the development process (see 3.2.1). As the use cases are developed according to the needs of stakeholders, the system will thus most likely to match user expectations [Shuja and Krebs 2008]. Figure 10 shows the activity diagram of the discipline Code requirements. Each activity shown in this diagram is divided into tasks which themselves are composed of steps. RUP documents for each activity in each discipline what are its components, managers and the products used and products [IBM 2008b]. The bulk of the work in this discipline is the responsibility of the analyst system. Some important tasks are: • define a common vocabulary for end users and producers of the project, • Identify actors and use cases (see section 3.2.1), • develop a vision of what the system should do • determine the demands of stakeholders, • develop additional specifications, • prioritize the use cases, • structure the use case model, • a detailed use case. RUP offers several products that can be delivered by the Reports of discipline requirements. As part of this work, the product specification of software requirements (Software Requirements Specification) will be produced (see Section 3.2.1).
Figure 10: Pattern Collection capacity requirements [IBM 2008b] 3.1.3 Analysis and Design The purpose of this discipline is to show how the system will be implemented. It provides a bridge between user requirements and technical platform. After a user perspective, we pass by an architect who will view the result of the implementation of the software [Corporation 1998]. The design is done: • meet all user requirements, • have a robust architecture, • be environmentally suitable implementation [Shuja and Krebs 2008]. Figure 11 shows the sequence of activities of the Analysis and Design discipline. Tasks are made, including: • The architectural analysis (for discussion on the architecture cf. Chapter 5) • Designing a user interface, • Creation of a prototype user interface (see Section 3.2.2), • Design classes (see Section 3.2.1), • Design of the database, etc.. [IBM 2008b]. [Chris and Elizabeth 2002] describes how the user interface design is supported in the RUP. As part of this work, the following will be achieved: • A first prototype of the interface, created on paper (see Section 3.2.2), • an evolutionary prototype that will include coded during the usability testing (see chapter 3.1.4), • a design model (see Section 3.2.1). It is important here to emphasize the importance of working closely with users of the software, when creating the prototype of the user interface. This can help in the management of the usability of the system, the discovery of new requirements and detailed requirements definition [IBM 2008b].
Figure 11: Pattern Analysis and design capacity [IBM 2008b] 3.1.4 Implementation and test Implementation Implementing discipline is made up of the implementation of the components (or services) and successive integration in the system. The test developers, code reviews and bug fixes are also included [Essigkrug 2007]. Several roles are well engaged in this discipline: software architect, integrator, the implementer and the technical editor. Figure 12 shows the pattern of capacity for this discipline.
Figure 12: Pattern implementation capacity [Rajalekshmi 2008]
The different roles share the following tasks: • The software architect is responsible for the physical structure of software components and the way in which classes and packages are organized in the data system. • The implementer is responsible for the implementation of components, developer testing and implementation of these. A test developer is a test suite that validates the proper functioning of the component, it is composed mainly of unit tests (a test unit checks an object or multiple objects separately) [IBM 2008b]. The implementor must also test the behavior of the code at runtime. • The integrator plans and implements the integration of different components. • The technical editor is responsible for code review. Test Test discipline plays a key role in quality assurance, as it is controlled by the executable software meet the requirements [Essigkrug 2007]. The goals of testing are: • verify the interaction between objects, • check that the integration of all components of the software is well done, • ensure that all requirements have been implemented • identify and to ensure that the defects were corrected before deployment of the software [Corporation 1998]. RUP offers an iterative approach, which means that tests are carried out throughout the duration of the project. In this way, defects can be detected as early as possible, reducing the cost to repair [Shuja and Krebs 2008]. Figure 13 shows the pattern of capacity is proposed to perform the tests. ORs are several quality risks, including risks of functionality, usability, reliability, performance and support. For each of these areas, RUP offers different kinds of tests [IBM 2008b]. In this work, test developers in the form of unit tests will be performed. Usability testing will evaluate the usability of the GUI by representative users.
Figure 13: Test Pattern capacity [IBM 2008b] 3.2 Techniques: Unified Modeling Language (UML) and Prototyping 3.2.1 Unified Modeling Language (UML) UML: a modeling language Unified Modeling Language (UML) is a modeling language whose original purpose was to enable the computer to represent a software system and its intended use in the company. This should help increase the rigor and quality of the construction of applications they developed [Morley, and Hugues Leblanc 2006]. UML is a standard non-proprietary, defined by the OMG. Its origins lie in the mid 90s. The authors of the early versions of UML are the same as RUP or Booch, Rumbaugh, Jacobson. Since November 2007, the OMG UML 2.1.2 released version, and is now working on Version 2.2 [OMG 2008]. Is described by a UML meta-model, ie a model representing the elementary constituents of UML with their usage rules and syntax. This allows, among other things, to ensure consistency between different tools, methods and models using UML to facilitate the exchange between workshops [Morley, and Hugues Leblanc 2006]. It should not be confused with UML software development methodology. UML provides several types of diagrams for modeling different aspects of the development process, but it does not give instructions on the use of these models in the development process. This will be the task of a development methodology, such as, for example, RUP (see section 3.1.1) [IBM 2008b]. The UML use case The discipline of RUP requirements gathering advice for all projects, to create a UML use case [Admiraal 2007b]. The latter describes the information system from the perspective of users and allows for better integration of user requirements in the development process. It serves as a thread throughout the project and for this reason, RUP is said to be based on use cases [Corporation 1998]. A use case is a specific way to use a system. It answers the question: what the actor does he achieve by using the system [Admiraal 2007b]? A use case is a grouping of activities triggered by an external actor that produces an identifiable result: a feature of the system [Morley, and Hugues Leblanc 2006]. A UML use case includes the use cases and shows the links between them and the actors. Dependencies between different cases may also be represented. A textual description of the full model, the following may be included: the purpose of the event, players can trigger the event, the sequence of actions, business rules and reference materials used or produced during the activities of If [Morley, and Hugues Leblanc 2006]. Figure 14 shows a model can be an automaton of the University of Fribourg. With the latter, a student is able to load the card, control data and to change them. These three features, the actor "student" and the relationships that link them are illustrated in the diagram. In this work, several use case diagrams are created. They will be complemented by the product of ORs "Specifications extra" containing non-functional requirements and additional functional requirements. The use case diagrams and specifications together form the additional work product "Specifying software requirements," English "Software Requirements Specification." The latter describes all the requirements of the system or part of the system [Essigkrug 2007].
Figure 14: Example of a use case diagram Class diagrams Class diagrams are among the most commonly used diagrams in modeling object-oriented systems [Booch, Rumbaugh and Jacobson 2000]. They represent the static structure in terms of classes and relations between these classes [Muller 2000]. A class is an abstract description of a set of objects of the application domain. It is represented by rectangles compartmentalized: the first compartment is mandatory and contains the name of the class, the second and third are optional are respectively contain attributes and operations of the class [Muller 2000]. Relations between classes describe potential links from one object to another object. Thus, it is possible to have a class with other classes: • a dependent relationship: expresses a relation of use of one class by another. • a generalization relationship: is a relationship between a general element and an element derived from it, but more specific. The generalization applies when it is possible that the more specific element that is "a kind of" the more general element. a relationship of association expresses a structural relationship that specifies that objects of a class are connected to objects of another class [Booch, Rumbaugh and Jacobson 2000]. Figure 15 shows an example of class diagram. Classes "Fish" and "Bird" are both "kinds" of animals. For this reason they are connected to the class, called superclass, "Animal" by a generalization relationship. Thus, these two classes, called subclasses inherit the attributes and methods of the superclass, that is to say that the objects of the class "Bird" and Class "Fish" automatically inherit the attributes " speed "and" weight "and the method" eat ". Class diagrams are used to model the static design view of a system. They can be, among others, used to model the vocabulary of the system, model collaboration between scheduled classes or to schedule a diagram and model database [Booch, Rumbaugh and Jacobson 2000]. In this work, the class diagram will serve as a model design for programming [Admiraal 2007b].
Figure 15: Example of a class diagram 3.2.2 Prototyping Prototyping, such as technical development of computer applications, first appeared in the literature of software engineering in the 1980s, but has not enjoyed great importance in the texts of information systems into the year 1990. The development of web based technologies and the increased emphasis on rapid deployment systems have contributed to the increase in the use of prototyping in software development over the last decade [Zant 2005]. Prototyping can be defined as the process during which a preliminary business model for an application, called prototype is created [Budde and Züllighoven 1990]. The latter development assistance software at several levels, most often for: • develop and evaluate user requirements, specifications and product design; • demonstrate the feasibility, performance, system behavior, etc..; • identify and reduce the risk of poor development of the system; • better communication, especially between different groups; • answer questions about the properties of the system [Luqi and Steigerwald 1992]; • to plan product development; • better define the product and strategy [Arnowitz, Arent and Berger 2007]. As described in [Arnowitz, Arent and Berger 2007], the technique of prototyping can be introduced at any stage of software development, even at different stages of the process, for different purposes. This will allow, for example, to create a prototype in the analysis phase to better understand user needs, but also to make a prototype in the implementation phase to test the performance of parts of the system as an algorithm system or database, etc.. [Zant 2005]. To be effective, a prototype should be built and modified rapidly, accurately and without great expense. It should not be neither efficient, comprehensive, portable and robust and it does not use the same hardware, software or implementation language that the system to produce [Luqi and Steigerwald 1992]. [Wood and Kang 1992] presents an overview of technology and literature relating to the creation and use of prototypes in the field of software systems. It is clear from his analysis that, according to the author, classifications and terminology are used. [Wood and Kang 1992] proposes to classify the approaches to prototyping observed in a relatively general, based on several features clear and distinct, rather than ambiguous abstractions. In [Arnowitz, Arent and Berger 2007] Also, a general classification is used, it is based, among other things, the following characteristics: • the audience (the target audience of the prototype is it made the team of programmers, customers, etc..?) • rapid prototype development, • the phase of software development in which the prototype is used, • the life of the prototype, • the similarity of the prototype to finished product. According to [Wood and Kang 1992] Another useful classification is performed according to the function of the prototype. This will be a prototype: • Experimental (also called fast-concept, disposable or exploration) will not be used in the final product, or • scalable: it will be constantly improved to be finally delivered to the customer as a final product. The RUP (see section 3.1.1) follows this categorization by function and adds another depending on the subject of exploration of the prototype. Two types emerge: • the prototype of behavior: it explores the specific behavior of the system. • the prototype structure: it explores the architectural and technological issues [RUP 2008]. In [Arnowitz, Arent and Berger 2007], different methodologies and tools are described to perform an effective prototyping. It appears that the corner of the tablecloth, the Framework object-oriented through the video camera and the PowerPoint presentation, virtually any tool can be used effectively to create a prototype, the importance of being fit means to ends [Pomberger and Weinreich 1994]. In this master thesis, an experimental prototype on paper the GUI will be created at the beginning of the analysis phase and design (see Section 3.1.3). It will only be used internally as a basis for development and communication. An evolutionary prototype is then created using the Framework Visual Studio. The hearing of the second prototype will consist of end users.
Series 4 requirements of SI BSU As explained in Chapter 3.1.2, the purpose of discipline requirements gathering is to describe what the system should do and allow developers and customers to agree on this description. This chapter answers the question: what features are expected by stakeholders to set up the game? According to RUP, the answer will be given as use cases (cf.3.2.1), the activity diagram and textual description. 4.1 Analysis Preliminary To find the solution that will increase the more effective when configuring the game, interviews were conducted with administrators BSU. The complete process for current configuration of the game was done once sets to identify problems and potential for improvement. The wishes and comments of the directors were taken into account. From this preliminary stage of analysis emerged the following important points: • Instructions for configuring the game are currently on a sheet or incomplete file that we must search each time. • The procedure for setting the game is done directly in the database (see arch): no graphical interface is used. • The result is often desired that the functions of sorting and searching the database must be in query Structured Query Language (SQL). • The same information must be entered in several different tables: Ex: For PMS, the dates of the games must be returned once for the Classic and a portfolio for both derivatives portfolios, as they are the same. • The direct manipulation of the database can generate errors if all the constraints are not taken into account. Ex: trying to delete tables containing primary keys referenced by other fields in other tables. • The configuration steps are no longer for years because they are not necessarily mandatory, but recommended, Ex: adjustment of interest rates. • Administrators do not know what to match certain fields and often the same questions arise. • Lack of a computer program documentation for how the fields in the database are required. All these points contribute greatly to the increased time required for an administrator to configure the game to overcome these points, the prototype solution should in all cases: • Provide a friendly interface where the setup instructions and a description of the fields should appear. • Provide the functionality of sorting and searching. • Automate certain procedures: Ex: dump. • Provide a common entry to mask the information to be equal. • Provide comprehensive documentation of the prototype generated for it to be kept up to date in the future. 4.2 The Product: Software Requirements Specification (Software Requirements Specification) 4.2.1 Framework As seen in 3.2.1, the software requirements specification is a description of all requirements of the system or part of the system. This chapter will be based on the model of the system created in the BSU [Shehu 2008]. In the latter, four types of features have been identified and grouped in the form of use cases in four main packages: Admin, Computing, Registration and Negotiation. The configuration of the game is in the package is Admin and the Use Case 2 (UC2): Package Admin: 1. (UC1) Update the website (the Administrator) 2. (UC2) Set up the game (by the Administrator at the beginning of the simulation) 3. (UC3) Set up connection to the SWX 4. (UC26) Import courses SWX (the PLC)
Error! Reference source not found. shows the diagram of the model when using the Admin package with the use case "Putting the game in place."
Figure 16: Diagram "Admin" Admin package with the CPU "Putting the game in place" [Shehu 2008] The UC2 is our subject of analysis and will be described in more detail in 4.3.1. 4.2.2 Definitions, Acronyms and Abbreviations As discussed in Chapter 3.1.2, an important task of the code requirements is the definition of a common vocabulary for end users and producers of the project: • Director: a person authorized to administer the game • Calculation of the game: import closing price of PMS in the program and updating of portfolios of members. • Negotiation: placing a market order in the game PMS • Period - one business day of the grant during the game PMS. • System: website design created for configuration sets the BSU • Alternative gaming: Simulation organized by the BSU and being composed of sets (see game), The Ex PMS is a variant of game • Game: Constituent of a variation of different game play (Classic and Derivative) allow a different portfolio composition • Classic - the classic game, where you can trade stocks, bonds, options, currencies and funds. • Derivative - the game derivative, where only the options can be negotiated. • Sub-menu "Titles" are part of the sub-menus "Securities" menus "Actions", "Obligations", "Options", "Currency", "Fund" • Emptying Tables: Action by which the tables used for calculations are emptied and the periods used in other tables are reset • Menu "General" menu contains all the general configurations of a modified game • Game Menu: Menu "Classic" and "Derivative" corresponding to the game content in an alternative game • Player - anyone with an account in the database BSU. 4.3 Specification of use cases (Use-Case Specification) The use case UC2 is the subject of analysis in this present work, it requires a more detailed description. It will be made, first, in text form by following certain rules of structure to facilitate the expression, understanding and consistency. It will show the flow of events describing the interactions between actors and the system. This form of description use case specification is called use case in the OR. It provides examples and stencils for specifying use cases. Second, an activity diagram showing the description in the specification of the use case UC2 will be created. It will allow a macroscopic view and time of the modeled system. 4.3.1 Use Case UC2 Put the game in place Objective: This use case is used to configure the game early in the period of variant Thurs Actor: The Administrator Main timeline: Preconditions: - The Administrator has the right to access the system - The period variant game has not started - No sub-menus "Securities" has been configured using periods Actions: 1. The use case begins when the Administrator has successfully logged on the system. 2. A home page prompts the user to choose an alternative set of games 3. The Administrator chooses the alternative games 4. A start page for configuring the variant game gives a little explanation of the steps to do so. 5. The Administrator clicks the menu item "Empty Tables" 6. The page of "Empty Tables" is displayed with an explanation of the process 7. The administrator presses the button to empty the tables 8. The system asks for confirmation of the Administrator 9. The Administrator confirms its action 10. The system displays a message that he is to perform the action requested. Meanwhile, the empty tables (Bank BedingungManuell, Kurs, Member_Session, Mutation, Portfolio, Rangliste) and puts all the periods used in other tables (Allgemein, Titel, and BedingungManuell Bedingung) is null, or at the period early in the game when these actions are completed, it displays a message that the tables have been successfully flushed. 11. The Administrator clicks on the menu "periods" 12. The page "periods" is displayed with a little explanation 13. The Administrator clicks on the Stock Exchange for timing business. After consultation it is up to the system. 14. The Administrator selects the calendar system working day from the stock exchange and click the button to save the periods 15. The system deletes the old times and new backup periods selected by the Administrator. In doing so, he enters twice in the first period and called the first of two "Initializing." The last time entry is named "End". Fields and SpielBeginn Spielende Allgemein table are adjusted for selected dates. 16. The main scenario continues in the alternative scenarios 16.1., 16.2., 16.3., 16. 4. The order of execution of these scenarios is equal, but they must all be executed. 17. The Administrator logs off the system. 18. The use case ends here. Postconditions: - All menus a variant of the game have been configured.
The numbers of alternative scenarios correspond to a connection alternative: Ex 1.a. corresponds to activities instead of activities of the main timeline starting at 1. Alternative scenarios 1.a. Dump table when the game has already begun Preconditions: - The current date is in the range of periods returned to the table "periods" (The game has already begun) - The Administrator will still clear the tables Actions: 1. The use case begins when the Administrator has successfully logged on the system. 2. A home page prompts the user to choose an alternative set of games 3. The Administrator chooses the alternative games 4. A start page for configuring the variant game gives a little explanation of the steps to do so. 5. The Administrator clicks the menu item "Empty Tables" 6. The system displays a page saying that the emptying of the tables can not be done with a link to still be able to access 7. The Administrator clicks on the link to still access the dump table 8. The continued use to the main timeline for action 6. 16.1. Configuration menu "General" Preconditions: - The menu "Periods" has already been configured - The variant of play has not started Actions: 1. The Administrator clicks on the "General" menu to edit the general information of the game 2. The system displays the "General". 3. The Administrator clicks on the button to edit the entire table 3.4. The table in edit mode 4.5. The Administrator introduced the changes and weigh on the button to save the table. 5.6. The system saves the changes and puts the table in reading. 6.7. The continued use to the main timeline for action 16 Postcondition: The General menu has been configured
16.2. Configuring players Preconditions: - No precondition Actions: 1. The Administrator clicks on the menu "Players" 2. The system displays the "Players" 3. Conditions: The Administrator will only change one or more fields "inactive member", "Paid" or "Blocked" to one or more players - The Administrator clicks on the boxes for the fields to change - The system displays a cross and saves the changes directly 4. Conditions: The administrator wants to change information other than "inactive member", "Paid" or "Blocked" to one or more players - The Administrator presses the "Select" corresponding to the player - The system displays all the information for this player - The Administrator clicks on the button to edit the entire table - The table in edit mode - The Administrator introduced the changes and click the button to save the table. - The system records the changes and puts the table in reading 5. Conditions: The administrator wants to see information other than "inactive member", "Paid" or "Blocked" to one or more players - The Administrator presses the "Select" corresponding to the player - The system displays information about the player 6. The continued use to the main timeline for action 16. Postcondition: - Menu "Players" has been configured
16.3. Configuration menus or games Preconditions: - The period variant game has not started Actions: 1. The Administrator hangs over the game menu "Classic" 2. The system displays the game page 3. Condition: The Administrator wants to change as a limit in the portfolio - The Administrator weighs on the button to edit the line to change - The field "limit" is being selected in edit mode - The Administrator introduced the value and click the button to save - The line is recorded - The Administrator will repeat the point 3. for all the fields he wants to change. 4. Condition: There is a game "Derivative" The continued use in an action. this scenario with the menu "Derivative" 5. The continued use to the main timeline for action 16. Postcondition: - The game menus have been configured
16.4. Configuration sub-menu to "Titles" Precondition: - The tables have been emptied - The periods have been gathered Actions: 1. The Administrator clicks on a sub-menu to "Titles" 2. The system displays the page corresponding to the class of securities selected 3. Condition: The Administrator wants to delete a title - It weighs on the "Clear" button corresponding to the title to be erased - The system asks for confirmation - The Administrator confirms - The title is deleted 4. Condition: The Administrator wants to create a new title - The Administrator weighs on the button to create a new title - The system displays a form to create a new title - The Administrator completes the form and press the button to save - The system records the new title and the form disappears 5. Condition: The Administrator will find information on a title - The Administrator presses the button to select the title - A page with all the details of the title is displayed 6. Condition: The Administrator wants to change the information of a title - The Administrator supports the button to select the title - A page with all the details of the title is displayed - The Administrator enters the changes and click on the button to save - The system records the changes 7. The administrator repeats this scenario to an action. for each sub-menu to "Titles" and for each game 8. The continued use to the main timeline for action 16. Postcondition: - The sub-menus "Titles" were configured
* A. One or more fields are returned false Preconditions: - An incorrect value was returned in a field and the Administrator has pressed the button to save changes Actions: 1. The system displays an error 2. Administrator presses the 'Back' button of the browser 3. The page is redisplayed with unsaved changes 4. The Administrator corrects the fields and supports knew the button to save the changes. 5. The continued use to the main timeline where it left off Postcondition: - Fields were recorded
* B. The Administrator remains idle for too long on the page Precondition: - Inactivity of the Administrator is longer than the timeout of the server Actions: 1. The system displays the login page 2. The Administrator enters his login and password and press Connect 3. The system displays the home page 4. The use case continues where it left off or a few steps before Postcondition: - The Administrator is logged in again - The system will display the last active page (or grafted page ...)
* C. A title or a player looking for is not visible on the page Precondition: - A title or a player looking for is not visible on the page 1. Condition: The Administrator wants to search by keyword - The Administrator enters the keyword (name, surname or email for a player; German name, French name, ISIN or name of an import title) - The system searches and displays the corresponding results or a message that the search was unsuccessful. 2. Condition: The Administrator will find by sorting by column - The Administrator clicks on the name of the column after which he wants to sort the rows - The system redisplays the lines in ascending order of the selected column - Status: The Administrator will sort the rows in descending order: - The Administrator clicks on the column after which he wants to sort the rows - The system redisplays the lines in descending order of the selected column. - The use case may continue to Action 2 of this scenario or continue to Action 3. 3. Condition: The Administrator will look by choosing the page to display - The Administrator clicks on the menu swap - The corresponding page is displayed - The use case can go in 2 or 3 or 4 point. 4. The continued use to the main timeline where it left off Postcondition: The title or the player looking for was found or does not exist
* D. The Administrator wants information on a field Precondition: - The Administrator wants information on a field Actions: 1. The Administrator clicks on the icon of the field of information 2. The system displays information 3. The Administrator supports on the cross to close the message 4. The information message disappears
Activity diagram use case UC2 "Establishment of the game" Figure 16: Activity diagram of the UC2 "Establishment of the game" summarizes the sequence of activities to do during the set up of the game
Figure 16: Activity diagram of the UC2 "Establishment of the game"
5 Analysis and design of the IS BSU As explained in Chapter 3.1.3, the purpose of discipline "Analysis and Design" is to show how the system will be implemented. It provides a bridge between user requirements and technical platform. The next question will be answered in this chapter: What benefits can make an architecture in three stages (three-tier architecture) in the design of the site configuration? Design patterns (design patterns) and. NET technologies used to design such an application will be subject to this chapter. 5.1 Architecture of the current information system of the BSU 5.1.1 Overview This chapter is based on [Shehu 2008] and [Husemann 2007]. The system information (SI) current BSU is based on a set of servers connected to the network within the University of Fribourg. Figure 17: Architecture of the components of information system BSU [Husemann 2007] represents a simplified model of the IS. The following components are included: • The BSU website: It is available at URL: www.unifr.ch / bsu. It is the visible part for the players: the place where they can manage their portfolio. It consists of two parts: o the public part coded in HTML and JavaScript. o secure part of a dynamic, for members and coded in ASP.NET. The website is on an IIS web server located on a virtual server (VM). • PMS Administration (Access): This program is based on "MS Access 2003." It is used for configuration and calculation of the simulation. It is connected to the database is accessible by BSU and the PC called BSUPC04 or the physical server called BSUPC03. • The database BSU (PMS DB): It is based on MS SQL Server 2005 which is on the physical server BSUPC03. It contains information on all the games organized by the BSU. It is used by the program Access PMS, the BSU website, the import program of courses and the data warehouse. • The import program courses (SWX Quote Import): Java program that imports the actual course of the SIX Swiss Exchange and put them in the database BSU. It is connected to the system FQS in Chapter 2.2. • The data warehouse BSU (Datawarehouse PMS): It is based on the program Microstrategy. It is a tool for data analysis of stock market simulation (Online Analytical Processing, OLAP) that players can visit the website. Data is loaded from the database BSU by ETL (extracting, transforming, loading). The configuration of the data warehouse is from software "Microstrategy Desktop" (MSTR Desktop) installed on the server BSUPC03.
Figure 17: Architecture of the components of information system BSU [Husemann 2007] Currently, several projects are under way to improve the architecture of the BSU described above. The import program of courses and PMS Administration program (Access) make among other party.
5.1.2 Components used in the current configuration of the game As stated in Chapter 4.1, the configuration of the PMS is being done mostly on the way and erase their values directly from the database (DB PMS). The PMS Administration (Access) has, admittedly, some interfaces to manage certain aspects of the game, but only its management interface players can be used during the initial setup of the game 5.2 Design of the desired application 5.2.1 Layered Architecture Architecture As written in [Fowler and Rice 2003], the word architecture is a term that has often been described in the software industry, but whose definition is not consensus. Two are both right recurrent: • an architecture is the division of high-level of a system component parts, • the architectural decisions taken are difficult to change. This definition derives some subjectivity. Indeed, if part of the system is easier to change it was supposed to start, it may be that it is not of architectural decisions, but "simple" design decisions. Layering A technique that can reasonably be described as architectural called Layering. This is one of the most architectures used by software developers to divide a complicated system [Fowler and Rice 2003]. A layer (layer) is a coherent group of related features. In an architecture called "layered" strict layer n can only use the services of layer n-1. In practice, this restriction is sometimes lax [Bass, Clements and Kazman 2003]. Figure 18 shows the hierarchical organization of layers in the example of a security module.
Figure 18: A layered security architecture [Pfleeger 1998] The term "Layer" and "tier" The terms layer (layer) and floor (third) are often subject to confusion and are often used as synonyms. But there is a distinction between these two words: "tier" means a physical separation on different machines. While "layer" refers to a logical separation: it is not required to perform the different layers on different nodes. For example, on a machine with a local database, it is possible to run an application in three layers on a "tier". It is also possible to separate several physical components as shown in Figure 19: Two-thirds [Fowler and Rice 2003].
Figure 19: Two-thirds [Oldby and Dan 2006] The three main layers The difficult part of the layering is to know how many layers you must divide its application and what responsibilities they assign. In this present work, a classic three-layer architecture will be applied, in fact, the responsibilities within the site configuration can be logically separated into three layers: • A presentation layer (Presentation Layer) is responsible for the interaction between the user and the software. It should display the information and interpret commands from the user. • A business logic layer (also called business logic layer, or Domain BLL layer): It is responsible for the implementation of rules and business logic calculations. She runs the logic on the basis of data from users and DAL [Fowler and Rice 2003]. • A Data Access Layer (Data Access Layer, DAL): It handles the communication with other systems that perform tasks requested by the application. These can be databases, messaging systems, other applications, etc.. Figure 20 illustrates the organization of these three layers.
Figure 20: The three traditional layers [Mitchell 2006] 5.2.2 Model View Controller (MVC) Pattern Model View Controller (MVC) divides the user interface interaction into three distinct roles: • Model: represents the gateway to the business logic and is responsible for application functionality [Mortensen, McGovern and Liptaak 2003]. • View: it deals exclusively with the display of information to the user. • Controller: It is responsible for interpreting the requests of the user to manipulate the model and display the appropriate view in response [Fowler and Rice 2003]. Figure 21 shows the sequence of activities triggered when an event such as a page request is generated by a user: 1. The request is intercepted by the Controller. 2. The controller evaluates the event and asked the model to run the business logic required. 3. The model performs the actions requested and returns the results to the Controller. 4. The controller determines the view to be displayed. 5. The view is loaded. If it needs to display data from a data source, it can not receive them by the Model. It is impossible to perform actions (such as a call to a database) directly. 6. The view is displayed on the user interface [Mortensen, McGovern and Liptaak 2003].
Figure 21: Model View Controller pattern [Mortensen, McGovern and Liptaak 2003] 5.3 Advantages and disadvantages of a three-layer architecture In general A division into layers of an application can provide several important benefits: • Low interdependence (low coupling) between components of the system. The interdependence is characterized by the intensity with which the elements are connected to each other: if they know of the existence or if they use the services of other elements. Little interdependence reduces the impact of changes made to the system. A layer can be substituted by another as they offer the same services, the implementation is so high, the interface is paramount [Oldby and Dan 2006]. It is thus possible, for example, to have several different presentation layers (eg a command line interface and a web interface) using the same business logic layer [Fowler and Rice 2003]. • High cohesion (high cohesion) within each layer. Cohesion refers to the intensity with which an item is focused on its responsibilities. Thus, a layer with responsibilities closely related and not running many different tasks is called "high cohesion". This quality makes the system easier to understand, reuse, maintain, and, as a side effect, reduces the interdependence between different components [Oldby and Dan 2006]. Each layer can be considered as an additional level of abstraction and the system can be designed as a decomposition of a complex problem into a sequence of abstract steps [Pfleeger 1998]. There are also some negative points to mention: • The division of the system in different layers means more work for implementation at the beginning since many components must be created. The code may seem too complicated for less experienced programmers [Oldby and Dan 2006]. • A change in one layer can result in a cascade change in all other layers. A typical example is the addition of a new field in the database: if it is to be displayed in the presentation layer, the change will be in the data access layer, presentation layer and all layers between two [Fowler and Rice 2003]. • Additional layers can affect system performance. It is often very likely that the encapsulation of underlying functions in a single layer optimizes resulting ultimately in a performance gain [Fowler and Rice 2003]. For BSU Compared to current components used to set configuration (see 5.1.2), a big negative for the creation of a layered application is the complexity of the resulting architecture. Indeed, the great strength of the current configuration of the game is that the architecture is very simple (only a database!). The configuration of the game is now very clear (the administrator always knows what data is put into the database!). For less experienced developers that simplicity is a great advantage that should not be underestimated. Hence arises the importance of keeping the site design configuration architecture as simple as possible with known patterns. A three-layer architecture, with the use of the MVC pattern to structure the interaction with the user interface is a good solution. 5.4 Design of the desired application. NET As seen in Section 5.1, the architecture of the BSU is based almost entirely on Microsoft technologies. To keep the consistency and use the latest technologies, the site configuration will be based on the ASP.NET 3.5 Framework. This will enable us, among other things, to use LinQ (see 5.4.5) and the new AJAX controls (see 5.4.3). The language chosen is C # because it has the advantage of Java is very similar to teaching at the University of Fribourg, this will simplify site maintenance. In addition, currently, there are more professional developers that C # VB [Walther 2007], this fact is reflected, among other things, the number of online help and books published in C #. This chapter focuses on the early design with the overall system. NET technologies. Then the three layers are described in more detail. 5.4.1 Layered Architecture. NET The purpose of this chapter is to examine how to implement the architecture described in 5.2.1 with. NET technologies. Represents a crucial point in this context, access to data. Object Relational Mapping (ORM) Data access will be implemented using technologies Object Relational Mapping (ORM) Microsoft. ORM allows a program written in an object-oriented language to file objects in a relational database as if it was an object-oriented database. It is therefore no need to write SQL commands and programming is facilitated [Flasko 2008]. The commands to manipulate objects will be made in Language Integrated Query (LINQ). The latter is an extension of. NET languages (under the Framework 3.5) with data query capabilities. In Chapter 6 examples of LINQ query will be displayed. There, at the time of preparation of this work, two ORM technologies from Microsoft that could be used in the implementation of the DAL: • LinQ to SQL: Provides direct 1-1 mapping of a database to Microsoft SQL Server. NET classes and the creation of LINQ query with the resulting objects. LinQ to SQL was developed for a scenario of rapid design (RAD: Rapid Application Developer) with a database where the Microsoft SQL Server database has a great resemblance to the object model of the application [Flasko 2008 ]. • ADO.NET Entity Framework (LINQ to Entities): Allows a flexible mapping and the ability to have a large discrepancy between the data storage and the underlying object model of the application. It is therefore much more complex and flexible than LINQ to SQL and is a business scenario [Arefin 2008]. Unfortunately, the ADO.NET Entity Framework was still in beta at the beginning of this project. For this reason, the choice of ORM is restricted to LinQ to SQL. LinQ to SQL Using LINQ to SQL in the application development can significantly reduce programming time, certainly, but why the price is to disseminate the LINQ to SQL queries directly where the result is used. LINQ queries to SQL and must be made in the business layer and presentation layer. This creates a dispersion of data access in all the code and therefore runs counter to the model in three layers. To keep a pure three-layer architecture, it is necessary to create a data access layer separated. Only within the latter, it will be possible to do LINQ queries and list them. The DAL will return objects, not LINQ to SQL. And requests made to the database will not be launched from any part of the application [Marguerie, Eichert and WOOLEY 2008]. This strict separation into three layers means a lot of plumbing code and more. Nevertheless, it is necessary to achieve the benefits of good architecture discussed in 5.3. Use of data in the presentation layer To display data in the presentation layer, you can use with LINQ to SQL two different controls: • LinqDataSource: This new control allows you to use LINQ in an ASP.NET page to search and modify data. His great positive is that it greatly reduces the code to implement: for commands such as selecting, updating, inserting, deleting, sorting and paging are created dynamically by the control! However, its use implies a direct link to the presentation layer with the layer of data which is not a good design practice [Esposito, 2007]. • ObjectDataSource: Connects to the presentation layer components of the diaper business. Methods such as the selection, updating, inserting, deleting and sorting must be created manually unfortunately all [Corporation 2008]. Only the ObjectDataSource can be used in the present work because it is the only control to allow a clear separation into three layers. As emphasized in [Oldby and Dan 2006], the use of ASP.NET with Visual Studio encourages the presentation layer to connect directly with the data access layer! Overview The system was implemented by creating different projects in Visual Studio. Thus it would be possible to separate the three layers of three different machines (Three others). The programming will be against an interface and using the pattern that will promote the independence of the layers. FFigure 22: illustrates the various components of the system: • BSUConfiguration: is the presentation layer. It is implemented in an ASP.NET website. • BLL: is the business layer. It is implemented in a C # class library. • DAL: is the data access layer. It is implemented in a C # class library. • Entities: corresponds to the model objects that are handled in three layers. It is implemented in a C # class library created based on the model of the database through ORM technology LinQ to SQL (see Chapter 5.4.5). • CommonObjects: corresponds to the model objects that are handled in three layers. It is implemented in a C # class library. Objects are created in the DAL based on the file DAL.xml. • The file DAL.xml and the database: they provide the data necessary to create objects of classes contained in the packets and CommonObjects Entities.
Figure 22: The composition of the system in different packages 5.4.2 Model View Controller. NET ASP.NET does not implement the MVC pattern as seen in Chapter 5.2.2: the controller does not act on the application level, but at the level of individual pages. The URL does not match the Controller action, but to a page on disk [Corporation 2009]. The pattern implemented by an ASP.NET page called "Page Controller" [Fowler and Rice 2003]. An ASP.NET page is divided into two parts: the view that contains the various controls and a C # class that corresponds to the Controller. This contains functions for each action that the Controller may take when an event is generated and it is to process the page. These functions can be connected to the Model View and the resulting [Mortensen, McGovern and Liptaak 2003]. If a controller at the application level is necessary, it can be created using the HttpHandler, as it intercepts the request before the ASP.NET pages [Oldby and Dan 2006]. Microsoft has released a beta version of ASP.NET MVC framework. The latter implements the MVC pattern as seen in Chapter 5.2.2, it is unfortunately currently only available in beta [Corporation 2009]. 5.4.3 Presentation layer Next to the PMS, the BSU organizes several other simulations exchanges. In this context, it is desirable that the website can be scalable and allow the configuration also other variants of games. As shown in Figure 23: Prototype of paper the layout of the site, each simulation will therefore have its own tab. It will be dynamically generated on the basis of information on the simulations in the file DAL.xml. The menu also will adjust dynamically depending on whether the simulation has only one version or also a version Classic Derivative. Information common to both sets (Classic and Derivative) will be united under the same menu items: for example dates of play for the Classic and the derivative are the same, there are only a sub-menu "periods." It will be the same for the sub-menus: "Players," "General" and "Empty Tables." The layout will be done through the Master Pages. They allow to give a web site a unified look. The browser uses the Sitemap and the SiteMapPath control to display a "bread crumb". A bread crumb informs the user about its position in the site. Due to the dynamic creation of tabs and the menu navigation will be dynamically adjusted by the Controller. The login will be managed by the Login controls and LoginStatus. The security settings are configurable from the web.config file. Ajax UpdateProgress control will be used to indicate to the user that the system is currently executing the query requested. It will be very useful when the system will need considerable time to complete a task, such as when emptying the tables. As described in Chapter 3.2.2, the implementation of the user interface will be based on a paper prototype. The latter was created for the entire site with only a few illustrations have been added to this document. Figures 23 shows the general layout of the site with its menu and dynamically created tabs. Figure 24 shows the contents of the "General" menu. The latter is based on the description of the use case of Section 4.3 and represents the alternative scenario 16.1: Configuring the "General" menu. Figure 25 is also based on the description of Use Case 2 represents the alternative scenario and 16.4: Configuration sub-menu to "Titles".
Figure 23: Prototype of the paper overall layout of the site
Figure 24: Configuration menu "General".
Figure 25: Configuration sub-menu to "Titles" 5.4.4 Business Logic Layer The business layer provides the presentation layer functions that are not related to the display data, but their treatment. In the case of system configuration BSU, these functions include, among others, the logic of selection, update, insert and delete objects. The logic of comparison between different values will also be implemented in the business layer and will be re-used in the presentation layer to implement sorting. Using the ObjectDataSource, all these functions must be created manually, unfortunately, (see Section 5.1). 5.4.5 Data Access Layer The data required to create objects of classes contained in the packets and CommonObjects Entities are respectively: • file DAL.xml, • the database.
DAL.xml DAL.xml file (see Figure 26) contains data on: • different versions of games (Ex: PMS, Derivative, Speed) • sets contained in each of these variants of play (Classic and derivatives).
Figure 26: Part of the file contents DAL.xml
Based on these data, objects representing the variations of play and games can be created in the DAL and other layers used in the system. The file also contains DAL.xml for every game the name of the mapping to use to connect each set with its data in the database (cf.ci below). The database The database contains information on BSU all variations of play in a single database. The tables of the latter belong either to a specific game, or they are common to all variations of games. The name of the table belonging to a particular game begins with a prefix corresponding to the number of game: Example for variant PMS game, the game Classic is the number 2. All tables containing only information about the game 2 then begin with the prefix "_02_" _02_Periode, _02_Allgemein, etc.. (See 9.3). Information common to all variants of the game are contained in tables without prefix: Ex: Gruppe. Mapping database with objects is carried out through the intervention of the DataContext. It lies at the heart of LinQ to SQL. He is responsible for most of the work, including: a complete collection of objects from the database and manage the connection with it [Marguerie, Eichert and WOOLEY 2008]. When creating the DataContext, two elements are required: • The mapping file: it describes the correspondence between the tables in the database and the classes contained in the package Entities. There is a mapping file per game • The ConnectionString: it contains the information to access the database. As the logical structure of information about a game is the same for all games, the classes contained in the package Entities do not represent the entire database, but only the tables corresponding to a game and those common to all games (see . Figure 28: Diagram of entities). Following mapping file which is passed to the DataContext, the entities will be linked to tables in the database corresponding to the game: Ex: If the mapping file "mapping02.xml" is passed to the DataContext, the objects that the DataContext will handle will be created , modified and deleted tables with the prefix _02_ and communal tables. Information about the correspondence between the mapping files and games can be configured in the file DAL.xml. Indeed, the database contains no information about the relationship between the tables and various games (Ex: the tables are prefixed with 02 to play the Classic PMS). The site configuration file by DAL.xml can change the list of games configurable by the system without having to recompile the application. Without a configuration file as DAL.xml information about the correspondence between the games and tables should have been coded in raw code. This would have had highly inflexible. The file also contains the ConnectionString DAL.xml. Figure 27 illustrates the components involved in the creation of entities.
Figure 27: ORM The class diagram in Figure 28: Diagram shows the classes of entities created by mapping the database and are also called entities. As discussed in Chapter 5.4.1, LINQ to SQL does not offer great flexibility to design the classes from the model database. It is, among other things, not possible to join several tables in the database into a single entity. This implies that it is not possible to create a single entity of two tables "Option" and "OptionDetails" although logically they represent the same class. An association may nevertheless be established between them. The only implementation inheritance as LINQ to SQL mapping is reached when all the elements of the hierarchy are in a table. Luckily, this is exactly the case of the table "Titles". The latter contains a record of all asset classes. It is therefore possible to create a class hierarchy with the entity "Titel" as a superclass and entities "Aktie", "Duty", "Currency", "bottom" and "Option" as subclasses . Class "Aktie" is, in turn, implemented as an abstract class and has as subclasses of the classes "SMIAktie", "SPIAktie" and "AuslandsAktie."
Figure 28: Diagram of entities
6 Implementation and Testing This chapter embodies the design of the system made in paragraph 5 in a file folder structure and programming. The implementation of the application into three layers, so it is configured using DAL.xml represents a considerable additional programming from its two layers for non-configurable (see 5). Subchapter 6.1 illustrates this and shows the implementation of the overall system. A second sub-chapter will be devoted to testing. 6.1 Implementation of the prototype This chapter focuses on the implementation of the system and provides some more detailed examples of some interesting parts of the code. Figure 32 shows the five projects created in VS to implement the structure described in Chapter 5.4.1. This chapter consists of five sub-sections each containing one of these projects.
Figure 29: The five projects created in VS The site configuration to be used not only by the administrator in charge of the configuration of the game, the system will not take over the management of parallelism (concurrency). Not to exceed the scope of this project, other aspects were not taken into account. Error handling, among others, was kept at a basic level. For more details, see the chapter "Perspective: other possible improvements to the architecture BSU." 6.1.1 The "BSUConfiguration" General structure As explained in Chapter 5.4.1, the presentation layer is created by ASP.NET 3.5. Files and folders component of the project site are illustrated in Figure 33.
Figure 30: Folders and files that make up the project "BSUConfiguration" Rérérences The presentation layer has references only to the object model contained within the projects "Entities" and "CommonObjects" and on the layer "BLL". Layer "DAL" is, according to a three-layer architecture strict, not referenced by "BSUConfiguration" (see 5.4.1). App_Code The files located in the App_Code folder is compiled dynamically by the Framework. App_Code in this project contains a class of control to display a customized message before deleting an entry (the control standard does not require confirmation before erasing). Aspx pages As discussed in Chapter 5.4.2, the aspx pages are the view, while the C # classes with them ("code behind" or "file aspx.cs") are the Controllers. Each URL corresponds to an aspx page. The data from the database are displayed on the page using the controls: • GridView: display data from multiple objects, • DetailsView: display data from a single object. These two controls will provide the objects to display through the ObjectDataSource control described in section 5.4.1. The functions it calls are in the BLL. The GridView and DetailsView have all the bubbles of information describing the fields. These bubbles of information are implemented in JavaScript in the file BSU.Master. The GridViews can be sorted by clicking on the headers of the table. These sorts of functions are implemented in the control itself and the methods for selecting objects (BLL project). The GridViews also have a personal pager to navigate between its pages. The latter is implemented in the code behind. Figure 31 illustrates these components using the screenshot of the "Actions" menu. The latter is the use case description in Chapter 4.3 and the alternative scenario is 16.4: Configuration sub-menu to "Titles".
Figure 31: Screenshot of the 'Actions' menu As described in section 5.4.3, more advanced controls such as Calendar and Ajax UpdateProgress control have also been used, respectively, in the pages "periods" and "Dump the tables." These controls allow you to give a simple web page look more approaching a Desktop program. Figure 32 shows the screenshot of the menu "periods." It fits the description of the use case of Section 4.3 and represents the main timeline action11. The implementation of events allows the Controller to make the website more dynamic and to adapt the controls to less standard scenarios in this project, they were particularly in demand (see below). Master Page The layout was made possible thanks to Master Pages (see section 5.4.3): BSU.Master and SpielVariante.Master. BSU.Master is applied to all pages of the site and has a container site (PlaceHolder). PlaceHolder in this, there may be content directly to the page (as in the Default.aspx page) or the second Master Page: SpielVariante.Master. It contains the menu of each tab and a PlaceHolder for the content of the page. Figure 32 illustrates, as an example, the three parts contained in the page "Periode.aspx": The top red is the Master Page BSU.Master, the left in blue is SpielVariante.Master, the content of the page "Periode.aspx" is displayed in the lower right. BSU.Master contains the login control "LoginStatus", the JavaScript functions used in the site, text bubbles information, breadcrum and setting tabs. The latter two, like the menu SpielVariante.Master are dynamically adjusted in their respective Class C #. web.config The web.config file contains the configuration information from the website as XML. Security settings are also included. As described in Chapter 5.4.3, the login is managed by the Login controls and LoginStatus located respectively in the login.aspx page and the file BSU.Master. Web.sitemap As described in Chapter 5.4.3, the navigation uses the XML file Web.sitemap and the SiteMapPath control to display the bread crumb. Dynamic adjustment of the latter to the structure of the website is configurable by the Controller.
Figure 32: The composition of the page "Period" Some implementation details As the programming standard scenarios in ASP.NET is very easy to do as much when it comes out of the beaten track, things get complicated greatly. The following examples illustrate these facts. As in the previous chapter, the entities are the same for different sets of BSU, ie d.elles do not have information when the game which they belong. It is in the DAL that will be determined how the table database entities to be connected. The LAD holds its information from the BLL which in turn holds the presentation layer. It is, indeed, in that each operation (create, update, delete) will be made directly associated with a game or a variant of the game So when, for example, the selection of an action it will always be necessary to specify not only the ID of the action, but also with what game it is connected. The ObjectDataSource (see Section 5.4.1) requires knowledge of the methods for creating, updating and deletion of BLL in order to work. With its attribute "DataObjectTypeName," it may take as parameter objects directly. The problem is that when the ObjectDataSource is working with objects (which is still the sense of object-oriented programming (OO)), it is possible to take, of course, other parameters for the method of selection, but not the method of updating! This is impossible, even through the C # code! The only solution would not work with objects, which would require to pass each value of each object one by one and to forget all the beautiful concept of OO. In the code system, this amounts to saying that it is possible, for example, to request the update of a security with a specific ID, but it is not possible to say what game this As part! Microsoft has not provided for the update to go other parameters that the object to update, we had to find a trick to still transmit the identity of the game DAL partner. This was done by adding two variables in the BLL: • currentspiel: is the game • currentspielviante: is the game variant Figure 33 shows the code added to the BLL. It shows the two variables and "setter" respectively.
Figure 33: Variables and currentspielvariante spielvariante the BLL These variables are updated since the presentation layer before each update through the implementation of the event OnUpdating. It is raised just before each update. Figure 34 shows how the values are taken from the Controller to move to the BLL.
Figure 34: updating function triggered when the event OnUpdating All functions for inserting and updating "save" the BLL do, therefore, only the object to update a parameter and removes the information about the game from the variable currentspiel (see Figure 35) .
Figure 35: function "save" the BLL This procedure can, of course, to divert the problem of setting the update function, but the BLL is a static class, it restricts the use of the site by writing to one user. This restriction is, in the case of the BSU, no problem, as only an administrator of the game have the rights set configuration (see 6.1). Another problem occurred when programming for the insertion of new shares in the page "Aktie.aspx." Entity "Action" is an abstract type (see Section 5.4.5), it is possible as such to update, to delete it but it is not possible or to create an abstract type "Action", or to update the class of shares (eg: to change an action in a foreign action Switzerland). To create an action, it was necessary to attribute value as "DataObjectTypeName" ObjectDataSource to a type of concrete action (Ex: SMIAktie). This gives the impression that the ObjectDataSource will create a specific action such as SMI. Then, use the event "OnItemInserting", which is raised just before the action is inserted, to change the nature of the object to the type of action selected by the user. Figure 36 shows the implementation of the function of the event OnItemInserting.
Figure 36: The use of the event "OnItemInserting" Regarding the change of class action, LINQ does not allow to do so, it would have been possible to implement with a SQL command to the lowest level. This has not been considered necessary and it is therefore not possible for a user to change the category of an action once it has been created. The last delicate point in this report commented on the entities "Option" and "OpionDetails." As commented in Chapter 5.4.5, these two entities should form only if in LinQ to SQL allows. As things stand, the two are nevertheless linked by an association (see Figure 28: Diagram of entities). The ObjectDataSource Page "Option.aspx" has as unique attribute value "DataObjectTypeName" entity "Option", ie d. all the operations insert, update and delete as a parameter entity will "Option". Each of these operations, the function of the corresponding event will perform the same operations, from behind, also the entity "OptionDetails" option for a "full" (OptionDetails included) to be processed. The code for these functions are too large to be included in this report, it is in the functions "Inserting", "deleting" and "updating" the file Option.aspx.cs of Annex 9.4. 6.1.2 The "BLL" General structure As explained in Chapter 5.4.1, the layer of business logic was implemented as a C # library project. Files and folders make up this project are shown in Figure 37.
Figure 37: Folders and files that make up the project "BLL" Rérérences The BLL has references only to the object model contained within the projects "Entities" and "CommonObjects" and on the layer "DAL", according to a strict three-layer architecture (see 5.4.1). C # classes Two classes make up the project BLL: • BLLFacade.cs: contains all the business logic methods called by the presentation layer. The methods for updating, creation and deletion of entities are, among other party. It is implemented as a static class. • Comparison.cs: contains all the comparators required to implement the sorting in the presentation layer. As explained in Chapter 5.4.1, using the ObjectDataSource in our architecture forced the implementation of manual sorting. Some implementation details A peculiarity in the implementation of LAD is the existence of variables "currentSpiel" and "currentSpielVariante" discussed in 6.1.1.
6.1.3 The "LAD" General structure As explained in Chapter 5.4.1, the data access layer was implemented as a C # library project. Files and folders make up this project are shown in Figure 38.
Figure 38: Folders and files that make up the project "LAD" Rérérences The DAL has reference only to the object model contained within the projects "Entities" and "CommonObjects" according to a strict three-layer architecture (see 5.4.1). C # classes The DAL was implemented using, among others, the pattern "Facade". This design pattern allows you to hide a sub-system behind a single object. The latter has a single unified interface and is responsible for working with the components of the subsystem [Larman 2006]. DALFacade.cs file with its interface is subject IDALFacade.cs Facade and envelope and the subsystem consists of classes: • KategorienManager.cs: implements the subsystem responsible for functions relating to the entities "Kategorien" • PeriodenManager.cs: implements the subsystem responsible for functions relating to the entities "Period" • SpielerManager.cs: implements the subsystem responsible for functions relating to the entities "Spieler" • SpielManager.cs: implements the subsystem responsible for functions relating to the entities 'Spiel' • TitelManger.cs: implements the subsystem responsible for functions relating to the entities "Titel". Dal.xml The role of DAL.xml file and the operation of each component involved in the ORM process are explained in Chapter 5.4.5. The DALFacade reads the information about games from the file DAL.xml and for each game, it instantiates the entire list of Managers above. They are each connected to their DataContext, which provides them from the database, the entities of their respective game. The DALFacade also parse the file DAL.xml order to instantiate objects and BSUSpiel BSUSpielVariante classes contained in CommonObejcts (see section 6.1.5). Some implementation details The implementation of the DAL with LINQ to SQL illustrates how the latter is more appropriate for a development scenario RAD to create a three-layer architecture! The first obstacle lies in the updating of the entities in the database. In a first phase, the objects were created from the database and passed to the presentation layer as a list of objects. They have been detached from their DataContext (which they were not posted in a scenario RAD). The sample code in Figure 39 shows the function implemented in the DAL TitelManager to search all currencies. It recognizes the call to the DataContext to retrieve the table entities "Titel" and the LINQ query to retrieve only the securities of currencies. It is important to note that the query is executed inside the DAL and returns a list of objects according to the principle of a three-layer architecture.
Figure 39: the function implementation getAllDevisen () In a second step, an entity "Currency" has been changed in the presentation layer and the function of updating the DAL was called. During this call, the object was then detached from the DataContext. The problem is that LINQ to SQL will handle all the objects through the DataContext so that any changes made can be monitored and recorded later in the database [Strahl 2007]. Many different implementations of the function update were tested. The one that worked is illustrated in Figure 40. It implies that the entity to update or recreated from the database (and the entity shall be attached to the DataContext) and the values of the entity passed as parameter (which is detached from the DataContext) are updated one to one! This solution is clearly not optimal, it has nevertheless the advantage of some significant work! The last point documented in this report is the table of the database containing the periods of play (table 0x_Periode, "x" is the number of game). This is the only table whose IDs start at 0 and must be consecutive. When entries are deleted from the table, the database continues to increment the value of the following ID. LINQ to SQL does not allow you to reset the ID, it was necessary to use a lower-level function for SQL to guarantee that the ID can be reset. After each erase times, then reset the SQL ID to 0.
Figure 40: The implementation of the function update currency 6.1.4 The "Entities" General structure As explained in Chapter 5.4.1, the object model is used to pass information between layers. It is composed of projects "CommonObjects" and "Entities". Files and folders make up the project "Entities" are shown in Figure 41. The latter is implemented as a C # library project. Rérérences The object model does not refer to any other project. C # classes Entities_20081215.cs class contains the classes representing the information in the database. It was generated by the tool SqlMetal and LINQ to SQL designer. As a first step, the diagram entities (bsu_20081215.dbml file) was created from the database using SqlMetal. It was then modified in the designer to get the diagram entities in Figure 28. Based on the latter, created SqlMetal entities_20081215.cs class and mapping files (see Section 5.4.5).
Figure 41: Folders and files that make up the project "Entities" 6.1.5 The "CommonObjects" General structure The "CommonObjects" is part of the object model of the system. It is implemented as a C # library project. Files and folders make up this project are shown in Figure 41. Rérérences The object model does not refer to any other project. C # classes Classes are BsuSpielVariante BsuSpiel and games and game variants. DAL.xml of data are used to create their instances.
Figure 42: Folders and files that make up the project "CommonObjects"
6.2 Testing As discussed in Chapter 3.1, the RUP is based on use cases. The system tests are thus based on the description of the UC2 Set up the game, made in Chapter 4.3. Much of the tests were performed manually and implicitly throughout the project. To illustrate the approach, a test case for the main scenario of UC2 is described below. The results were compiled in the summary of test. 6.2.1 Introduction Tests inside the table are to be executed sequentially. The ID tests correspond to the numbers of the main timeline of the activities which they are attached. Only the tab for the PMS should be tested systematically. The tests are to achieve ave browsers FireFox version 3. and Explorer version 6. 6.2.2 Test Case Test ID Purpose Actions Expected Outcome (postings) 7 tables of the game will be emptied • In the "Empty Tables", click the "Empty Table" for both games contained in the variant of the game: • * The tables are empty • periods linked by foreign key in other tables ** are either null or the period with ID 0 • The message "the tables have been flushed with success" displayed The 14 periods are entered into the database • In the "Periods", select and deselect the days, weeks, months (from different months). • Click "save the dates" for both games contained in the variant of the game: • The new periods are periods in the table • They are displayed in the GridView to top • Fields and SpielBeginn Spielende Allgemein the table are updated • The DetailsView menu "General" shows the new fields beginning of the game and end game *: Empty tables are: Bank, BedingungManuell, Kurs, Member_Session, Mutation, Portfolio, Rangliste ** Periods used in the following tables: Allgemein, Titel, and Bedingung BedingungManuell
6.2.3 Summary of tests Tests with ID 7 and 14 have produced results in accordance with the test cases above. No errors were reported. In other tests done implicitly, it was observed that the display of JavaScript functions were not performed properly with Explorer. With FireFox, for against, no display problems were reported.
7 Summary and Conclusion Will the new interface is beneficial to a better configuration of the game? It is not enough to predict the action, we must also act to at least see the consequences for this prototype interface will be implemented and tested. This question will be answered through programming and successive tests. The transition of the new site configuration has already begun with the installation of software on the new server. The configuration of the next game could be done with the new program. Summary: Put the basic scientific questions: Conclusion: 1. My conclusions on developing characters: . NET Developer Standard is great for but there is sth others have! At first there was little blog. Net 3.5 layer archtecture now much There is no documentation of the program and the database to see which field matches what: bsp: the periods are the only field that start at 0. Important to know the business to know that if there are funds must also be taken dividend. Even to put the comment there are bugs! I had never done or LinQ or asp.net or a website alone. LinQ in 3 layers: as explained by MS says LinQ is for Rad and its new Framework for 3TIER. For the forced execution of the query with a ToList have to go for a record has the fields is difficult. LinQ to SQL is dead is better Entity Framework because it separates well between what is and LinqProvider ORMFramework! Difficulties because: BD is? Normal form: Relationship as said verwirrend Teuff between some fields of the bd. . LinQ is not suitable for the 3TIER, was lucky because in BD BSU has the only type of legacy that LINQ supports nämlich ... Despite that managed to make a site that automatically adjusts its just changing the conf file, when at the base site would just be for the PMS! It took a lot more programming in the code behind in order to programmatically add controls in the configuration file, but it has been worth it! ASP.net is very good! 2. My conclusions on Project Management with RUP. 3. My conclusions at all: This was because there was anspruchswoll finance, management proj, and programming the three have nothing to do but all connected by the fact that the BSU is to understand the 3. 4. SWOT analysis: As I did design science: S: easy to configure, faster W: more layers, making the architecture more complex for the new bsu (sth new to learn) O: Put the first step of a lifting of BSU T: that LinQ is no longer used, support for the Entity Framework will come in place, people do not update config site if they make changes to the game site become desu 7.1 Perspective: other possible improvements to the architecture BSU At this time, other parts of the arch BSU are again: the import and the basic program. To improve the site configuration, to 1. internationalization, 2. validators, 3. Concnurrency and handling errors 4. Do with EntityFramework 5. to the RBA (the conditions are included) 6. add a button to the options that are in the classic version are made in the derivative at the same time erase the old table. 7. Watch the compatibility of the Explorer with javascript
8 Bibliography Admiraal, H. (2007a) Difference between versions 6 and 7 ORs. Admiraal, H. (2007b) Pitfalls using UML in RUP. AG, S. S. (2008) SIX SIS AG. https://www.sec.sisclear.com/sec/cm/index.htm last accessed 24.09.08. Arefin, M. (2008) Difference between LINQ to SQL and the Entity Framework. http://dotnethitman.spaces.live.com/blog/cns!E149A8B1E1C25B14!195.entry last accessed 28/01/2009. Arnowitz, J., Arent, M. and Berger, N. (Hrsg.) (2007) Effective prototyping for software makers. The Morgan Kaufmann series in interactive technologies, Elsevier, Amsterdam. Bass, L., Clements, P. and Kazman, R. (Hrsg.) (2003) Software architecture in practice. SEI series in software engineering, Addison-Wesley, 2nd, etc. Boston. Booch, G., Rumbaugh, J. and Jacobson, I. (Hrsg.) (2000) The User's Guide: UML. Eyrolles, Paris. Brandon, D. Mr. and Brothers, C. (Hrsg.) (2006) Project management for modern information systems. IRM Press, Hershey. Brealey, R. A., Myers, S. C. and Lehman, PJ (Hrsg.) (2003) Principles of financial management. Pearson Education, 7th ed., Paris. BSU (2008) der Schweizer Universitäten Börsenspiel. www.unifr.ch / bsu last accessed 29.04.08. Budde, R. and Züllighoven, H. (1990) Prototyping revisited. Chris P. and Elizabeth K. (2002) In support of user interface design in the Rational Unified Process. IEEE Computer Society Press, p. 21-27. Corporation, M. (2008) LinqDataSource Web Server Control Overview. In MSDN Magazine. Corporation, M. (2009) ASP.NET MVC. http://www.asp.net/mvc/ last access 29.01.2009, Microsoft Corporation. Corporation, R. S. (1998) Best Practices for Software Development Teams. In Rational Software White Paper. DeutscheBörse (2008) iShares DAX (DE). http://www.boerse-frankfurt.de last accessed 02.10.08. Eck, C., Langer, M., & Riechert, M. (Hrsg.) (2006) Eurex Futures und Optionen. Finanzbuch Verlag. Eibl, H. (Hrsg.) (2008) ETFs Exchange Traded Funds. FinanzBuch Verlag, München. Esposito, D. (2007) LinqDataSource vs ObjectDataSource vs SqlDataSource. last access. Essigkrug, A. (2007) Rational Unified Process kompakt. Elsevier Spektrum Akad. Verl., 2. Aufl., Heidelberg Munich. Eurex (2008) Eurex. http://www.eurexchange.com/index.html last accessed 25.09.08. Exfeed, S. (2008) SIX Exfeed. http://www.exfeed.com/index.html last accessed 23.09.08. Flasko, E. (2008) Introducing LINQ to Relational Data. In MSDN Magazine, 01.2008. Fowler, M. and Rice, D. i. (Hrsg.) (2003) Patterns of Enterprise Application Architecture. The Addison Wesley Signature Series, Addison-Wesley, Boston etc.. Group, S. (2008) Medienmitteilung. http://www.six-group.com/media_releases/online/media_release_200809301104_de.pdf last accessed 30.09.08. Hesse, W. (2003) Dinosaur Meets Archaeopteryx? or: Is There An Alternative for Rational's Unified Process? In Software and Systems Modeling (SoSyM), Vol. 2 (4), p. 240-247. Hull, J. (Hrsg.) (2003) Options, futures & other derivatives. Prentice Hall finance series. Options / futures / derivatives, Prentice-Hall: Pearson Education International, 5th, Upper Saddle River, NJ. Husemann, S. (2007) Roadmap BSU. Fribourg. IBM (2008a) Rational Method Composer. http://www-01.ibm.com/software/awdtools/rmc/features/index.html?S_CMP=wspace last accessed 16.10.2008. IBM (2008b) Rational Unified Process. http://www-01.ibm.com/software/awdtools/rup/ last accessed 16.10.2008. Isakov, D. (2006) Evalution measures of performance. In Portfolio Management, University of Fribourg, Fribourg. Kruchten, P. (Hrsg.) (2001) The Rational Unified Process: an introduction. The Addison-Wesley object technology series, Addison-Wesley, 2nd, 5th print., Boston. Larman, C. (Hrsg.) (2006) Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. Prentice Hall PTR, 3rd, 7th printing, Upper Saddle River, NJ Luqi, L. and Steigerwald, R. (1992) Rapid prototyping software. In System Sciences, 1992. Proceedings of the Twenty-Fifth Hawaii International Conference on, Vol. ii, p. 470-479 vol.2. Marguerie, F., Eichert, S. and WOOLEY, J. (2008) LinQ in Action. Manning, Manning, Greenwich. Metz, D. (Hrsg.) (2007) Devisenhandel. FinanzBuch Verlag, München. Mitchell, S. (2006) Tutorial 2: Creating a Business Logic Layer. In MSDN Magazine, 06.2006. Morley, C., Hugues, J. and Leblanc, B. (Hrsg.) (2006) UML 2 for the analysis of an information system: the specifications of the client. InfoPro. Management Information Systems, Wiley, 3rd ed., Paris. Mortensen, K., McGovern, R. and Liptaak, C. (2003) ASP.NET and Struts: Web Application Architectures. In MSDN Magazine, 12.2003. Muller, P.-A. (Hrsg.) (2000) Modeling with UML. Eyrolles, 7th edition 2000, Paris. Novello, P. (Hrsg.) (2007) Stock: Investors' Guide. P. Novello, 3rd ed., Updated and enlarged., Geneva. Oldby, N. K. E. and Dan, M. B. (2006) Application of a layered architecture design in ASP.NET 2.0 - and a Comparison between J2EE and. NET-IT University of Copenhagen (ITU) Copenhagen. OMG (2008) Catalog of OMG Modeling and Metadata Specifications. Catalog of OMG Modeling and Metadata Specifications last access. Pfleeger, S. L. (Hrsg.) (1998) Software engineering: theory and practice. Prentice Hall, Upper Saddle River, N.J. Pomberger, G. and Weinreich, R. (1994) The Role of Prototyping in Software Development. In the Conference on Technology of Object-Oriented Languages and Systems (TOOLS Europe '94), Prentice Hall, Versailles, France. Rajalekshmi (2008) Rational Unified Process (RUP). http://perpetuastudents.wordpress.com/2008/01/21/rational-unified-process-rup/ last accessed 16.10.2008. Ranaldo, A. (2007) Introduction to market microstructure University of Zurich. Riaan, K., Stefan, G. and Derrick, G. K. (2007) Assessment of a framework to compare software development methodologies. In Proceedings of the 2007 Annual Research Conference of the South African institute of Computer Scientists and information technologists on IT research in developing countries, ACM, Port Elizabeth, South Africa. RUP (2008) Concept: Prototypes. last accessed 16.10.2008. Schneider, F. (2008) BankingToday.ch. Verlag SKV, Zürich. Shehu, E. (2008) Analysis of an information system and extend it with new features. Department of Computer Science University of Fribourg, Fribourg. Shuja, A. K. and Krebs, J. (2008) IBM Rational Unified Process Reference and Certification Guide: Solution Designer. IBM Press, Upper Saddle River, N.J. Steiner, M. and Bruns, C. (Hrsg.) (2002) Wertpapiermanagement: Professional Wertpapieranalyse und Portfoliostrukturierung. Handelsblatt Bücher, Schäffer-Poeschel, 8., Überarb. und erw. Aufl., Stuttgart. Strahl, R. (2007) Attaching and LINQ to SQL Entities. http://www.west-wind.com/WebLog/posts/134095.aspx last accessed 01/02/2009. SWX (2008a) Financial Quote Service. http://fqs.swx.com/ last accessed 23.09.08. SWX (2008b) SWX. http://www.swx.com/index.html last accessed 23.09.08. Telekurs (2008) Telekurs. http://www.telekurs.com/fr/tkhoch_home.htm last accessed 24.09.08. UBS (2008) Glossary. www.ubs.ch last accessed 24.09.08. Walther, S. (2007) ASP.NET 3.5 Unleashed. Sams, Chicago. Wikipedia (2008) Options. http://fr.wikipedia.org/wiki/Option last accessed 01.10.08. Wood, D. P. and Kang, K. C. (1992) A Classification and Bibliography of Software Prototyping. Zant, R. F. (2005) Hands-on prototyping in system analysis and design. In Information Systems, Vol. VI (1). Zindel, S. (2008) The costs of trade may vary up to a hundredfold. In Balance Sheet (No.250), 21.05.2008.
9 Appendix 9.1 Installation Guide: The application was programmed on Windows XP, using Visual Studio 2008 and SQL Server 2005 Standard Edition. It was installed on Windows Server 2003 with IIS 6.0 and SQL Server 2005 Standard Edition. 9.1.1 Pre conditions: On the server: • Microsoft. NET Framework 3.5 • Operating Systems: Windows Server 2003, Windows Server 2008, Windows Vista or Windows XP • Web server IIS (Internet Information Services) • SQL Server Database On the development machine: • Visual Studio 2008 or Visual Web Developer 2008 • Operating Systems: Windows Server 2003, Windows Server 2008, Windows Vista or Windows XP The following components are included in Visual Studio 2008 and Visual Web Developer 2008: • Microsoft. NET Framework 3.5, • a web server (ASP.NET Development Server), • a database SQL Server.
9.1.2 Configuring the website DAL.xml To function properly, the site needs to know where the XML file that contains the configuration DAL.xml games and connection information to the database. To do this, open the solution that is in DAL.sln \ Projects \ DAL. In the file DALFacade.cs specify the property value ServerPath, as shown in Figure 39. Figure 43: Attribute ServerPath file DALFacade.cs
Warning: This is the path where the file DAL.xml on the server after publication. Here, the records of web server on C: \ \ Inetpub \ \ wwwroot total path is C: \ \ Inetpub \ \ wwwroot \ \ BSUConfiguration \ \ bin \ \. Recompile the DAL by going to the menu: Build Build DAL. Figure 40 shows the message that should appear in the output window below:
Figure 44: Message displayed in Visual Studio after a compilation réuissie
Then open the solution in BLL.sln \ Projects \ BLL and rebuild it as: Build Build BLL. Close the two open projects.
Connecting to the database To configure the connection to the database DAL.xml open the file located in \ Projects \ DAL \ DAL tag and indicate in the Connection, the atribut url, cf. Figure 41.
Figure 45: Beacon to connect to the database file DAL.xml Here the database is located on the server-sr-SVW 960.unifr.ch, it is called test, using the id bsu and has the password bsu. Save your changes and close the file.
Configuration sets The site configuration can have multiple games BSU games and variations of play everything is customizable through DAL.xml file located under \ Projects \ DAL \ DAL. Just tell him what games (Spiel) correspond to which variant of the game (variant) and enter the name, id and mapping of the games and the name and id variations of play Figure 42 is an example configuration for RBA games and PMS. Figure 46: Configuration of games and variations of games in the file DAL.xml The numbers of ids and mappings of sets correspond to the numbers of tables in the database, for example: play 01 matches at the tables 01_Allgemein, 01_Allgemein_Text, etc.. This game is linked to tables with mapping01.xml. The mapping files are located under \ Projects \ DAL \ DAL. To add more, please read "How to add extra games? ". Authentication of administrators User authentication on the web page can be configured through the Web.config file located under \ Projects \ BSUConfiguration \ BSUConfiguration. In the following screenshot, the login configuration with password bsu can be used to access the site.
Figure 47: Managing Users in Web.config 9.1.3 Installation Open the web project located in BSUConfiguration.sln Projects \ BSUConfiguration with Visual Studio. From the menu, go to Build Publish BSUConfiguration. This window appears:
Figure 48: Window web publishing Click on the icon with the three points and create a new folder called BSUConfiguration to the location you prefer (in this case, it is created on the desktop). Set other options as shown in the screenshot. Click Publish. Go to the created folder and copy on the server in the folder of the web server. Here, the file is copied to C: \ Inetpub \ wwwroot \. Start the Internet Information Services (IIS) Manager under All Programs Administrative Tools Internet Information Services (IIS) Manager. Create a new Application Pool: Right-click on the Application Pools folder New Application Pool ... A window like the one in Figure 45 should appear:
Figure 49: Window for creating an Application Pool Rename the ID. Here it is appointed AppPool asp.net3.5. Click OK.
Figure 50: Configuration Tabs website BSUConfiguration He must then tell the website to use this Application Pool: Right click the folder Web Sites Properties BSUConfiguration. Home Directory tab in the Application pool box, select the application pool you just created. Click OK. Then tab to the Web Site Connection timeout to 10,000 seconds. Click OK. Home Directory tab, click Settings, Options tab, set the ASP script timeout to 3600. Click OK. On the ASP.NET tab, click Edit Configuration ... under the Application tab set the Request execution timeout to 10,000. Click OK. On the ASP.NET tab, the ASP.NET version must be 2.0 (2.0.50727). Click OK.
9.2 Advanced Configuration of the site: 9.2.1 Changing the information windows The windows are made information to provide the administrator with enough to configure the game and it is therefore necessary to keep them current. Figure 47 shows an example of window information:
Figure 51: Window of Information for ISIN To change the text displayed in the windows of information, open the file that is under BSUConfiguration.sln \ Projects \ BSUConfiguration. In the file BSU.Master.cs texts are displayed in the windows of information. They are arranged by section: for example, Kategorie, Titel, AktienDetails, etc.. and number of columns in the GridView or number of rows in the DetailsView, starting with 0. To find out which section is to change, go to the file aspx.cs corresponding to the web page to edit. Look for the first parameter to the function of the class BSU getHelpText. This is the name of section. Section names ending with the word "Detail" correspond to sections of the DetailsView, the other match of the GridView. Example: page http://www-bsu.unifr.ch:8080/Aktien.aspx?Id=2 it would be desirable to change the text displayed for the field in the GridView ISIN. Follow these steps: • Open the file that is in Akien.aspx.cs BSUConfiguration.sln. • Search function BSU.getHelpText. As shown in Figure 48 and Figure 49, two results coincide: Figure 52: Bsu.getHepText seeks the corresponding text in Section Titel
Figure 53: BSU.getHelpText seeks the corresponding text in Section AktienDetail Titel section corresponds to the GridView securities, while the DetailsView is qu'AktienDetail action. As we want to change the text displayed in the third column of the GridView page Aktien.aspx, it will change the text corresponding to the section Titel and id 2 located in the file BSU.Master.cs. In Figure 50, it will then replace the text "<h4> ValorenNr </ h4> International Securities Id" with the selected text.
Figure 54: Relevant information in the file BSU.Master.cs After modification, please recompile the project: Build Build BSUConfiguration and reinstall it: see 9.1.3 Installation. 9.2.2 How to add extra games? To add a new variant game site configuration, simply create a new mapping point to the new tables and adjust the file DAL.xml. To do this, go to the folder on the server BSUConfiguration \ bin and copy a mapping file that you rename "mapping ** '** corresponding to the number of the game and the number of tables. For example, for a new variant game called "Neues Spiel" and correspondent for the game Classic with 07 tables and game tables 08 Derivative, copy twice a mapping file and rename the "mapping07.xml" and " mapping08.xml ", see Figure 51.
Figure 55: copy of the mapping files Open each of these two files and replace all tags in the attribute table with the name corresponding to the tables of these new games. Figure 52: shows an example with the name that will become bsu_01_Allgemein bsu_07_Allgemein for mapping07.xml and bsu_08_Allgemein for mapping08.xml.
Figure 56: Beacon to adapt to the file and mapping07.xml mapping08.xml
Figure 57: Tag after the change to the file mapping07.xml Repeat the replacement of 01 by 07 (08) for all the tags tables, save changes and close the files. Open the file located in DAL.xml BSUConfiguration \ bin and add the line of code in Figure 54: New variant of game "Neues Spiel" <Spielvarianten> between the tags.
1.2 Objectives To overcome this lack of organization, this work aims to analyze the features that are covered by the simulation software market of the association and suggest improvements. These improvements will be modeled and then implemented in a prototype. A project management approach based on Rational Unified Process (RUP) will be used for analysis, modeling and implementation. In a first phase, the various processes needed to manage the game will be modeled using "Use Cases" Unified Modeling Language (UML). This will allow us to have a global vision of all the functions to be done to manage the simulation using a common language with standard UML. In a second phase, analysis of the weaknesses of the process will help identify potential for improvement. Especially for this phase, the understanding of the business logic is essential. The logic includes the operation of various financial tools that can be traded in the simulations (stocks, options, bonds, currencies, ETFs, etc..) And the operation of the Exchange and certain concepts of finance. Great potential for improvement is, apparently, in the configuration of the simulation game. Indeed, often, managers have to deal with parts of the configuration of the game such as: responding to ads purchase, merger or any other stock market news, insert the names and currency values chosen for the game in the database, the value of a splitter action, observe the strategies of the players to make comments and constantly improve the game, go missing classes, etc.. These are tasks that, in the current state of the architecture of BSU, ask the person knowledge of finance and IT. It's the same for the configuration of the game that can be performed only by computer scientists or people with good computer skills: there would be a big efficiency gain if it could be done from one place of BSU architecture and by someone without extensive knowledge of the application. In a third phase, more detailed modeling of the Use Case "Configuration of the Game" will lead to a change in the current architecture to a solution of three-tier architecture and multi-thirds. In a fourth phase, the architecture of current BSU will face a description of the three-tier architecture ideal. This confrontation will come out the benefits of a well-defined three-tier architecture, including the largest: the separation of "business logic" of the "view". And an interface to administer the game, which will be easy to use for non-computer and only will be created. The last phase will consist of the choice of technologies (. Net, Ruby on Rails or other) to create this interface, the implementation of a prototype and testing. The four phases of RUP - Inception, Elaboration, Implementation, Transition - have been well covered and the process improvement project completed. 1.3 Implementation method What are the different financial tools and financial characteristics to consider in setting up a stock market game? It is essential to know the business logic of the financial stock market game in order to improve its configuration. For this first chapter will be dedicated to the financial aspects of the game This question will be answered by observing the game and literature. How do I make a change in the information system of a company? An IT project can be completed, if it does not follow a clear methodology. For this it is necessary to choose a methodology that has already proven itself. This question will be answered by the literature. What features are expected by the stakeholders to set up the game? It is essential to propose a solution that meets the needs of stakeholders, for that you need to consult them before. This question will be answered by the empire. Which architecture is most appropriate for BSU? (What change in terms of architecture is that) This issue will provide the backbone of the project and show the benefits of change of architecture. This question will be answered by the literature. What are the technology. NET, ASP.NET and ADO.NET? (Qelles. NET technologies should be used?) Before choosing a technology is definitely needed to know how it works, its advantages and disadvantages. This question will be answered by the literature. Will the new interface is beneficial to a better configuration of the game? It is not enough to predict the action, we must also act to at least see the consequences for this prototype interface will be implemented and tested. This question will be answered through programming and successive tests.
2 The business logic: a description of various tools and features to consider in setting up a stock market game Before dealing with the technical and implementation of an IT project, it is necessary to dwell on the business logic of it. In the case of the BSU, the stock knowledge of the principles underlying the simulation is of major importance. The administrators of the game should be familiar not only with business logic implemented by the BSU program, but also with the Swiss stock market reality. Indeed, for reasons of simplification, it differs in some points from that modeled in the application BSU. The result is that an administrator should be notified aware of these differences to properly configure the simulation. To this end, this second chapter presents a practical description of knowledge and scholarship required a direct confrontation with the implementation made by the BSU. It answers the question: what are the different financial tools and financial characteristics to consider in setting up a stock market game? 2.1 Simulation Portfolio Management (PMS) 2.1.1 Concepts of simulation The simulation organized by the BSU for students of Swiss universities called Portfolio Mangement Simulation (PMS). For eight weeks, players manage a wealth of CHF one million and may invest in financial instruments described in Section 2.3. Orders placed during the day are executed at the closing of the day. Participants have two portfolios: 1. a portfolio, said Classic, with a limitation of options to purchase 5% of the portfolio with the purchase. Two rankings are calculated on this one: • Performance: only returns obtained over the entire period of the game account • Risk Management: profitability and risk are taken into account using the Sharpe ratio (see Section 2.1.2). 2. a portfolio, said derivative, consisting only of Eurex options: one Derivative classification is calculated on this portfolio according to profitability [BSU 2008]. 2.1.2 Classification Measures Players To determine the rankings discussed in the previous section, it is necessary to have two different measures: one takes into account only the profitability, the other combining it with the risk. Simple returns The simple returns on assets are measured as follows:
or RFIN which is simple profitability over the period of play; Pfin Pdébut and prices are holding at the end respectively at the beginning of the period of play To calculate the performance rankings and derivatives, simple returns for each portfolio are calculated. The player with the highest profit wins. Sharpe ratio By its nature, the stock market simulation contains a bias against a real portfolio management: as the money is fictional, investors have less risk aversion. To correct this distortion, a measure of performance taking into account not only profitability but also the risk should be used. Several measures exist to account for risk in performance calculations. The Sharpe ratio, Treynor and Jensen alpha are classic examples. At the BSU, is based on the Sharpe ratio that the classification is made Risk Management. The Sharpe ratio is the measure most used by the investment fund industry in the United States. Ex-post definition is:
Where RPF is the profitability of the portfolio measured PF, Rf is the risk free interest rate, is σPF volatility of portfolio returns. SRPF indicates profitability received in excess of the risk-free rate, per unit of risk. The higher the ratio, the better the compensation for the risk taken by the investor, so the better its performance. Volatility is a measure of risk used here. Several limitations must be observed when using this ratio. First, the Sharpe ratio depends on the risk-free interest rate used. Several different classifications may well result, hence the importance of choosing the risk-free interest rate. Second, the Sharpe ratios of non-zero positive and are unusable. It is possible that the profitability of a portfolio is less than or equal to the risk-free rate. A ranking of portfolios by size of their Sharpe ratio would lead to an erroneous result [Steiner and Bruns 2002]. Calculation of the ranking at the BSU At the BSU, the risk-free interest rate used is the one month Libor rate. It is updated once at the beginning of each game The variance is, in turn, calculated by the program using the simple daily returns of the portfolios of the players. The use of simple returns to the classic formula of the variance result in systematic errors which are generally of lesser magnitude. In practice, this is done quite often for reasons of simplification. The use of instant returns would be many times more accurate to calculate the variance of returns [Isakov 2006]. Instant profitability profitability continuously made. It has the advantage of being additive and to calculate the variance due to non-geometric and arithmetic mean
2.2 Financial markets: Swiss Infrastructure and Exchange (SIX) Swiss Exchange and Eurex The organization of a stock market simulation depends largely on available financial data. Those used to come from the BSU Financial Quote Service (FQS). FQS is a service of SIX Swiss Exchange that allows you to receive financial data for securities listed on SIX Swiss Exchange, SWX Europe and Scoach Eurex, the data on stock indexes and currencies are also available [SWX 2008a]. BSU does not currently market data Scoach structured products, for that reason, this chapter will focus on SIX Swiss Exchange and Eurex. 2.2.1 SIX Swiss Exchange As of September 30, 2008, called the Swiss Stock Exchange SWX Swiss Exchange [Group 2008]. It is one of the first fully electronic exchanges in the world. Since 1996, the system takes care of sending the order to final settlement according to the latest techniques. The brokers will negotiate more at auction, but return their operations in computers installed in the banks. Electronic Exchange The electronic exchange provides significant advantages: 1. Liquidity is increased, that is, the probability for a seller to find a buyer is greater. 2. There is greater transparency: all courses paid for and traded are known, the market is well visible in its entirety. 3. With the streamlining of procedures, transaction costs are lower. 4. Trading is continuous on all securities in unlimited amounts throughout the opening day of the grant [Schneider 2008]. Trading on the SWX Swiss Exchange is centralized and organized according to the orders ("order-driven market"). This means that liquidity in this market is guaranteed by the individual orders and do not require market-making, in contrast to Eurex (see section 2.2.2) [SWX 2008b]. Figure 1 shows the electronic system of the Exchange SIX Swiss Exchange: • The trader is made available to all banks in Switzerland and abroad, practicing securities trading business and being accepted as participants associated with the SIX Swiss Exchange. With this technical infrastructure, agents can participate in exchange operations. • The Exchange sends the information to the trading system traders. He collects the orders and sales in a central order book and automatically matching according to very precise rules. • The Gateway is a portal or filter whose function is to ensure fair treatment of all members participating in the stock market and acts as a network security system between the traders and the System of the Exchange. • The Settlement Communication System (COMSEC) and Swiss Interbank Clearing (SIC) are responsible for the settlement (liquidation), respectively Clearing (clearing). Transactions are automatically transmitted from the Exchange System SECOM and SIC. • The Swiss Market Feed (SMF) records all data on the real-time market of securities traded on the SIX Swiss Exchange [Exfeed 2008]. It is a source of FQS.
Figure 1: System for Electronic Exchange SIX Swiss Exchange [Schneider 2008]
Organization of the SIX Swiss Exchange SIX Swiss Exchange is one of 100% of the division of trading in cash (Cash Market Division) of SIS Group (formerly, Swiss Financial Market Services AG) and offers three types of investment vehicles. They are traded, respectively: • the stock market: stocks, shares, participation certificates, bonus certificates (see Section 2.3.1); • the bond market (bonds): Bonds of Borrowing (straight bonds), variable rate bonds (floating rate bonds), Zero-coupon bonds (zerobonds), dual currency bonds, subordinated borrowings, convertible bonds (convertible bonds), loans to Loan Participation Notes option (see Section 2.3.2); • the market for Exchange Traded Funds (ETF) Exchange Traded Structured Funds (ETSF) and investment funds: investment funds and individual funds, ETFs, ETSFs and investment companies with variable capital (SICAV) (see Chapter 2.3 .3). Market shares of the SIX Swiss Exchange are treated all securities other than securities SMI / SLI. They are traded on SWX Europe is the award-Helvetian UK securities and ETFs leaders in Europe. SWX Europe is 100% owned by SWX Swiss Exchange.) Since 1 January 2007, all derivatives admitted to the SWX Swiss Exchange are traded on the trading platform of Scoach. This is the first European exchange for structured products, warrants and certificates are traded. Scoach was created by Deutsche Börse and SWX Swiss Exchange. One of the largest futures markets in the world, Eurex is owned by Swiss and German stock exchanges. Thus, SIX Swiss Exchange plays an important role in derivatives (see Section 2.2.2). The leading European indices such as Stoxx and Swiss Fund Data are also part of the group with SIX SWX Exfeed, which is the company responsible for market data on the SIX Swiss Exchange and SWX Europe [SWX 2008b]. The other group entities are SIX SIS AG, which is responsible for processing and filing of domestic and foreign securities [AG 2008] Finally, Telekurs is active in the fields of international financial information, transactions and card payment systems electronic payments [Telekurs 2008].
Figure 2: Organization of the SIX Swiss Exchange [SWX 2008b]
Order types There are several types of possible orders to the Exchange: normal order (normal order), with iceberg order (hidden size order), order acceptance (accept order), order fill-or-kill order, and if (conditional order) [Schneider 2008]. The types of orders to the BSU For now, participants in the simulation can only place orders normal so-called "best", that is to say that the orders are executed in any case, whatever the price. In the context of the BSU, orders and orders to normal condition (Stop Loss, One Stop Order and stop-limit) are interesting. In [Shehu 2008], the ability to add orders limited to the BSU game was analyzed, it is to date not yet implemented. Commissions and taxes of trading Stock exchange are the following costs: • Brokerage: commission that banks charge their customers as service provision for the execution of trading orders. Each bank sets its rates individually. [Zindel 2008] compares the brokerage fees applied in Switzerland in May 2008. It appears that there is great variation from one bank to another. • Federal Stamp (stamp duty): Tax paid if one of the contractors or intermediaries is a securities dealer. • Stock exchange tax SIX Swiss Exchange: Stock exchange tax paid by the bank on the SIX Swiss Exchange. Each product segment has its specific trading costs. Cost to the BSU At the BSU, for simplification, only brokerage fees are collected. Custody or administration fees, which are management fees charged by banks to hold the securities in deposit, are not considered either.
2.2.2 Eurex Eurex is one of the leading derivatives exchanges around the world. It is a corporation equally owned by Deutsche Börse AG and SIX Swiss Exchange. Its electronic trading system allows it to offer a wide range of international products at relatively advantageous. Figure 3 shows the increase in the number of contracts per segment for the year 1999 to 2007 at Eurex. The evolution of the exchange Eurex following the global market for derivatives traded on organized markets. Indeed, as documented in [Novello 2007] the market does not know the crisis and continues to grow since the beginning of the millennium.
Figure 3: Evolution of volumes by product segment (contracts in millions) [Eurex 2008]
Specificity of the derivatives market Compared to the SIX Swiss Exchange, Eurex has some specific characteristics of the nature of its futures. One of the biggest differences is Eurex is a market with a hybrid structure, also called "quote-and-order-driven market". This means that all investors can advertise the prices at which they are willing to buy and sell ("order") but in addition, special players in the market, called "market-makers" must make their offers ("quotes") for products for which they are responsible [Ranaldo 2007]. Orders and quotes are inserted throughout the trading day in the central order book, where the matching is performed [Eurex 2008]. The market-makers, often employees of international investment banks, are obliged, when they receive a request to submit a bid and sales. This application is called "Quote Request" and is, nowadays, in general, fully processed by computer: the trader enters the computer the settings and the system calculates the price. The existence of market-makers and provides liquidity to the market. Another big difference compared to Eurex from a spot market is the existence of the clearing (Clearing House). This assures the buyer that the contract will be accomplished. It manages all transactions, maintains the accounts and makes margin calls. They are a mechanism to ensure that the investor will not default if, for example, one option would be exercised by the buyer [Hull 2003]. The mechanism of the margin call works like this: if an investor has sold such options, the structure of the contract that cash flow will be zero or negative at the time of exercise. To guard against the future risk, the amount of collateral (margin) to be paid on a deposit account. After each market close, the positions of investors are valued ("marked to market") and the margin should be adjusted accordingly. If the investor bought an option, its cash flows will be zero or positive, it will not need to provide security [Eck, Langer and Riechert 2006]. The prices used to value positions of investors called the settlement price (daily settlment price). The daily settlment price is calculated each evening using the Eurex binomial model of Cox / Ross / Rubinstein option pricing for stock options and using the model of Black / Scholes 76 for index options [Eurex 2008]. Implications for BSU These characteristics are important to the Eurex simulation of BSU for several points. First, thanks to market-makers and the daily settlement price, it is possible to have a way (buying and selling) every day and an evaluation of each option market closes, even if n ' has not been traded during the day. This makes possible the negotiation of option in the simulation even when the contract was entered into the Eurex will and therefore no closing price will be available. The organizers of the BSU evaluate options, in this case, the price of the daily settlement price. Second, at present, it is possible to buy options in the Eurex simulation BSU. It is not necessary to take into account the margin call for the simulation.
The products traded on the Eurex Eurex offers a wide range of derivatives: interest rates, equities, equity indices, volatility indices, ETFs, funds, inflation and CO2. In addition, the product offering continues to grow. Of all the instruments, future and options are the most traded. The products traded on Eurex BSU For the simulation of BSU, only stock options and index futures are currently used. At Eurex share options are American style. Index options are usually European-style [Schneider 2008]. As to the BSU, the options can not be exercised, is not the type of difference (see Section 2.3.5).
Types of Orders At Eurex, there are several types of orders: market-order, with a limit order, stop and combination [Eurex 2008]. Types of orders to BSU At the BSU, only the order-order market exists, that is to say the order is executed in any case whatever the price. In [Shehu 2008], the ability to add orders limited to the BSU game was analyzed, it is to date not yet implemented.
Transaction costs to the Eurex Transaction costs include the costs of Eurex trading and clearing. They vary by product and product group. Fees charged by Eurex, the broker added those that can be very different from one another. Transaction costs to BSU At the BSU, for simplification, only brokerage fees are collected.
Other kinds of options traded in Switzerland Eurex options are not the only ones that can be negotiated in Switzerland. Indeed, there are two kinds: 1. Warrants: The warrants are traded on the stock exchange Scoach. Their main difference from the Eurex options is that they can be of purchased (position called "long") and not sold by investors. 2. Options over-the-counter (OTC) option or by mutual agreement: the contract is concluded off-exchange directly between buyer and seller. The advantage of such an option is that they can be tailored to customer needs. At BSU At the BSU, for now, only the Eurex options are used.
2.3 The financial tools 2.3.1 Actions Definition A share is a variable income, representing a fraction of the equity of a public company. The action gives the holder: • social rights: right to vote at the general assembly, right to consultation, right to elect and be elected in the election of an organ of society, right to challenge decisions of the meeting general right of control, • economic rights: the right to a portion of the profits, right to subscribe for new shares in a capital increase or entitled to a portion of the proceeds of liquidation in the event of liquidation [UBS 2008]. Value The value of a share can be estimated using the Gordon model. The latter is based on the updating of all future cash flows generated by the action: dividends and resale price [Brealey, Myers and Lehman 2003].
Equity trading on the BSU At the BSU, the following types of actions, traded on the SIX Swiss Exchange and SWX Europe, are used: • Bearer shares: the action is freely transferable; • shares: the shareholder must be registered in the register of shareholders; transmission is more restrictive; • participation certificates: This title can be issued in bearer form or in the name of the participant. It confers rights similar to those attached to ordinary shares; except that it incorporates only economic rights but not social rights. At the BSU, participants buy and sell shares at the closing of the title, plus brokerage fees. They receive gross dividends to the date of distribution of the latter. Contrary to reality, participants in the game does not have to pay the withholding tax on dividends.
2.3.2 Obligations Definition A bond is a fixed income. It is a loan and long-term negotiable securities issued by companies or bodies governed by public law [UBS 2008]. Value The value of a bond can be estimated by discounting all future cash flows generated by the duty: interest and final repayment [Brealey, Myers and Lehman 2003]. The value of a bond, also called dirty price, can be divided into: • During clean-coupon price or a percentage of nominal; • accrued interest, also expressed as a percentage of nominal.
The dirty price P is the price paid by the bond purchase. Fl is the accrued interest by multiplying the fraction of the Year by the amount of the coupon. The clean price C is the dirty price without accrued interest. So there is the relation. The course published by the SWX is a clean price. Bonds trading at BSU At the BSU, the following types of bonds traded on the SIX Swiss Exchange are used: • fixed-rate bond: the payment of interest is the nominal value multiplied by the interest rate; • zero coupon bond: no annual coupon, but it is trading well below their redemption value; • perpetuity: it has no repayment or amortization. BSU bonds are bought and sold in the clean price, unlike the stock market reality, accrued interest are not taken into account during transactions. Interest is calculated on the period, however, holding bonds and are added to the amount of interest deposit account. Thus, there is a bias in the game compared to the reality of the BSU players can buy more bonds in the game that he could do in the stock market with the same amount of money, the fact that he should not pay interest. It may well affect the interests of more titles and the value of its portfolio will be exposed to lower and higher bond prices. Contrary to reality, participants in the game does not have to pay the withholding tax on interest.
2.3.3 Exchange Traded Funds (ETF): Definition An exchange traded fund (ETF), also known as tracker is a fund that is traded on the stock market and reflects the evolution of the course and the performance of an underlying index. The latter can be based, among other things, on the market: stocks, bonds, commodities, real estate and money market. ETFs are experiencing a growing success since their introduction in 1993 because they offer significant advantages: • First, unlike traditional index funds, they are exchange traded. Market makers must ensure liquidity. • They have management costs generally lower than traditional investment funds, due, among other things, their replication purely mathematical index (passive management). • Publication of the indicative net asset value (iNAV for indicative net asset value) at all times by the exchange provides the investor the highest transparency. It is possible to know at all times the difference between the intrinsic value of the ETF and the price listed. It is possible that the price of the ETF rises gradually above its underlying index, while dividend payments of the securities comprising the index are made. This gap is decreasing as the ETF itself pays a dividend. The Manager of the ETF issues new shares and buys any investor wishing. This has the effect of increasing the collective wealth and the number of shares outstanding, in the event of an issue and in case of redemption, reduce the collective wealth and the number of shares outstanding. This opportunity to buy and sell shares on the primary market allows ETFs are traded on a course close to the secondary market iNAV [SWX 2008b]. Value The intrinsic value of an ETF is called iNAV [Novello 2007]. It is calculated by the SIX Swiss Exchange permanently by adding the price of the securities included in the background and dividing by the number of shares outstanding [SWX 2008b]. Figure 4 shows in blue the price of the ETF iShares DAX and his black iNAV. As it emerges, the ETFs are trading at a price close to the indicative net asset value. Only for a short time, there are differences of a few cents. The investor has to have security at any time, a fair price for an ETF [Eibl 2008]. Figure 4: Evolution of the ETF iShares DAX and its iNAV [DeutscheBörse 2008]
ETFs trading at BSU ETFs are not yet available in the game of the BSU. However, as their importance is growing, it would be to think about vigilantes. They do not require more specific implementation, they can be treated in the game such as stocks. Indeed, as the latter, they generally still have a course and a theoretical value, they pay dividends and purchase and sale result in brokerage commissions and trading. One of the only differences is that the fund management of the ETF takes, in addition, management fees that impact on the evolution of periodically over the fund.
2.3.4 Currency Definition A motto is a debt denominated in a foreign currency payable abroad. It may take the form of an ave or paper value [UBS 2008]. The big difference compared to other trading values used in the play of BSU is that currencies are not traded on an exchange but OTC: treat all partners directly. The major players in these exchanges are banks that form a network: the interbank market. The currency market, also known as Foreign Exchange (Forex) is a global market. He suffers no temporal restriction: you can trade currencies 24 hours over 24 hours. A trading day begins in Asia, Europe continues to finish in the United States. A big disadvantage of trading currencies is the limited choice of liquid currencies. The fact is, in fact, that few in comparison with, for example, actions in which there are hundreds. Transaction costs are relatively low, as a rule, only the spread (difference between bid and ask prices) is seen as indirect costs [Metz, 2007]. Value To assess the exchange of one currency, there are several models that focus on only a few influencing factors. The theory of purchasing power parity and interest parity are two examples known. There is another approach to fundamental analysis, which monitors all relevant economic data and to identify future influence on prices. Data on the political situation, economic situation, monetary policy, interest rates and speculation are used [Metz, 2007]. Forex trading at BSU At the BSU, the few most liquid currency market are used. As usual in practice for a single deposit, players receive no interest. Transaction costs are similar to other stocks traded on the BSU, which is relatively expensive in comparison with reality, where only the spread is taken. As currencies are traded continuously and CTA, the import of foreign exchange for the game is made for more or less regular hours and the same supplier.
2.3.5 Options Definition An option is a contract between the buyer of the option, called the owner and seller, called a party. It gives the holder the right to buy (call) or sell (put) to a predetermined date (maturity date) and a fixed price (exercise price) a certain quantity of goods or a number of shares (underlying asset) in return for immediate payment of a premium (option premium) to the signatory. One option is a derivative asset that is to say, it derives its value from the evolution of the underlying asset. In the graphs Figure 5 and Figure 6 are shown the pay-offs of the holders of a call, respectively, a put based on changes in the price of the underlying asset. The pay-off of the holder of a call becomes positive when the price of the underlying exceeds the option premium p paid plus the exercise price K paid. The loss of a long position (position holder) of a call is limited, while the gain is unlimited. The pay-off of the holder of a put is maximized when the price of the underlying asset is zero. The gain is thus equal to the exercise price less the premium received K p paid, it is limited, as the loss is at most equal to the amount of the premium p [Hull 2003]. Figure 5: Pay-off of the holder of a call [Wikipedia 2008]
Figure 6: Pay-off of the holder of a put [Wikipedia 2008]
Two types of option are: • American options: they may be exercised any time until maturity; • European options: they may be exercised only at the maturity date. Options contracts traded on Eurex are, they represent a number of different options depending on the option chosen. The course Eurex indicates the price of an option, we must multiply by the size of the contract to determine the transaction price [Brealey, Myers and Lehman 2003]. Value There are several kinds of models to evaluate options: analytical models (Black and Scholes model and its extension), numerical models (binomial, trinomial, Monte Carlo simulation, etc.). And models of analytical approximation. These models are used, among other things, to determine the price of compensation (see Section 2.2.2) [Brealey, Myers and Lehman 2003]. Trading in options to BSU At the BSU, two kinds of options are traded Eurex: • Stock options: the underlying action, • index options: the underlying is an index. The organization of a stock market simulation with options is more difficult than in cash only. Some simplifications must be implemented, the following are an example: • Contrary to the Eurex trading done, it is not possible in the game BSU to become a signatory of an option. A short position (position signatory) of an option is more risky than long positions: the maximum loss not just to the premium paid at the beginning of the contract (as a long position). The cash flows for a short position is always positive for sale (receipt of the premium) and may develop negative thereafter. Why margin calls (see Chapter 2.2.2) are made in practice. For the simulation, this means, among other things, that the value of the margin should be calculated every night and the positions of the players taking too much risk should be closed. • In the simulation, it is not possible to exercise options. The difference between American and European options becomes insignificant. It can be shown that in practice, in general, it is anyway not profitable to exercise an option before its maturity date. It is better to sell it and buy the stock separately, rather than exercising the option. • If an option is not negotiated for the day on the exchange Eurex, she has no last price (Last Price). To continue to use it in the simulation, it is necessary to use a different estimate of its value which is the settlement price (daily settlement price) (see Section 2.2.2). • The transaction options fell to a penny is suspended in the simulation. In reality, if they again became attractive, they will be bought at a higher price. Blocking options also offer the opportunity to protect the players, who want real influence over the options for cheap and win the simulation. Choosing options for the simulation with a longer maturity reduces the probability of having the options to one cent, as time is a component which positively influences the option price. Options with a maturity closest in time are, right time, more interesting to negotiate.
2.4 The stock market events can disrupt the game In the two months of simulation, it is possible that business activity creates adjustments in the game This chapter briefly describes the disruptive events and required actions by the directors BSU. 2.4.1 Split A split of a stock is the division of its nominal value. As this does not change the value of the company, it should not affect shareholder wealth. All things being equal, the share price should be divided by the number of new shares received (n) for an old (m) and the number of shares should be multiplied by this same factor, the wealth should be continued the same. For options, the contract specifications are changed to reflect the expected change in the share price. The exercise price must be multiplied by the factor m / n and the number of shares underlying an option contract must be multiplied by n / m. If the share price decline in the proportions expected, the total contract value is unchanged [Hull 2003]. Treatment of a split in the BSU In the game, simplifications have been introduced: • for the shares, their number remains unchanged, but the course is multiplied by n / m; • For options, the exercise price multiplied by m / n, the number of shares corresponding to a contract remains the same and the course is multiplied by n / m. 2.4.2 Merger and Acquisition In the strict sense, an acquisition means that a company called initiator, buys another company, called target. The latter thus ceases to exist and only the actions of the initiator still being negotiated. In a merger the two companies, more or less equal size, agree to continue their existence into a single entity. The shares of both companies are replaced by new joint. In practice, few mergers between companies of equal size. In general, the larger of the two companies bought the other, but for reasons of communication, it is quite common to talk of a merger, even though technically it is an acquisition. An offer directly to shareholders is a possibility to form of acquisition. To protect small shareholders, the law requires companies that want to take control to make an offer to all shareholders. At the exchange, two kinds of offers are commonly used: • Tender Offer (OPA): a cash amount offered in exchange for shares of the target company. • exchange offer (OPE): the offeror offers shares in exchange for shares. These offers may be hybrid, that is to say, consist of part cash and part in shares [Brealey, Myers and Lehman 2003]. Treatment of a merger with the BSU In the simulation, once a company is acquired or merges, actions and options are sold at the last force in effect. 2.4.3 Bankruptcy A bankruptcy is the forced sale of the total assets of a debtor on the register of trade following its inability to pay. The proceeds of the realization is then divided among creditors [UBS 2008]. When a company went bankrupt its shares have lost value. Treatment of bankruptcy at the BSU In the game, shares and call options of a company bankrupt are estimated at CHF 0 .- The options are sold puts strength.
3 The analysis of an information system An IT project can be completed, if it does not follow a clear methodology. This chapter provides an answer to the question: how to make a change in the information system of a company? To answer this question, a methodology that has proven will be presented: Rational Unified Process (RUP). Disciplines "Code requirements," "Analysis and Design", "Implementation" and "Test" are described here in order to be applied in the practical part, in Chapters 4, 5 6. Two techniques used in this process will help the development: modeling and prototyping. 3.1 Methodology Project Management: Rational Unified Process (RUP) 3.1.1 RUP: a methodology for project management Definition Rational Unified Process (RUP) is a methodology for managing projects. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its purpose is to ensure production of quality software that meet user needs and whose development respects the constraints of budget and time. RUP has been designed and documented using the UML (see Section 3.2.1) [Kruchten 2001]. History The first version of RUP, version 5.0, was created in 1998 by the company "Rational". The latter was founded by the same authors of the early versions of UML Booch, Rumbaugh and Jacobson. RUP is the result of a long process and based on best development practices. Its chief architect is Philippe Kruchten. In 2003, Rational was acquired by International Business Machines (IBM). The latest version (7.0) was released with the announcement of IBM Rational Method Composer (RMC) in November 2005 [Rajalekshmi 2008].
Rational Method Composer (RMC) RMC is a commercial product to create, configure, visualize and publish processes as Web pages. RUP is an integral part as a vast library reusable [IBM 2008a]. Figure 7 below shows a page from the published ORs with RMC. RUP is a process known as delivery of RMC. These processes are complete for a certain type of project they are a starting point to plan and rapidly initiate a project. The wider process of delivery is the Life Cycle Classic RUP, RUP is similar to version 6.0. For small projects, the life cycle for small project RUP is preferred. It does not prescribe or business modeling discipline, or discipline of deployment, some products were discontinued and a few other changes were made. The life cycle of business modeling and architecture modeling and service-oriented ORs are two other delivery process [Admiraal 2007a]. RMC also contains patterns of capabilities that are pieces of reusable processes addressing common problems. The Figure 10 and Figure 13 are examples of patterns of abilities. The Framework process RMC enables the expert to adapt RUP process to each project by making available an architecture and construction groups use [Rajalekshmi 2008].
Figure 7: A RUP page customizable by RMC [IBM 2008b]
Key principles for business-driven development RUP version 7.0 was a major update of its practices now call the Key Principles for Business-driven development. They are described briefly below: • Adapt the process: the size of the development process must be adapted to the needs of the project. For example, for a limited project, involving a local team and a known technology, the process should be made so simple. • Balancing the priorities of stakeholders: stakeholders would like to have an application that does exactly what they want to do while minimizing the cost of development and planning time, but these goals often conflict. It is therefore necessary to manage requirements effectively, understand and prioritize. • Collaborate across teams: this answers the questions: How to motivate his team to make it successful? How to work in a team software distributed or localized in one place? How to establish a collaboration between sales teams, IT and software development? • Demonstrate the value iteration: an incremental value can provide an early and continuous feedback information in order to be able to adjust plans, process key risks early in the life cycle, to consider and manage change. • Raise the level of abstraction: visual modeling using UML and the focus on architecture development team helping to raise the level of abstraction and prevents it goes directly to the code requirements. To reduce complexity, it is also important, among other things, to reuse existing solutions, using high level languages, frameworks and patterns of applications. • continued focus on quality: in RUP, the software developed at each iteration is tested in conjunction with its construction. This allows a noticeable improvement in the quality [IBM 2008b].
Unified Method Architecture (UMA) The meta-model which is based on RUP to describe its process is called: Unified Method Architecture (UMA). It can support multiple models of different life cycles: life cycle RUP iterative development, life cycles cascade, etc.. The UMA specification itself has been submitted to the Object Management Group (OMG) as proposed meta-process model of software engineering (Software Process Engineering Metamodel: SPEM 2.0) [IBM 2008b]. The main principle of UMA is a clear separation between content and method of its use in the temporal unfolding of a process. Content method described in detail the tasks to be performed (regardless of time dependencies) for a product and know-how to get there. The unfolding process gives the content of the method after a time and allow adaptation to very different types of projects. Figure 8 shows an overview of key concepts of the architecture UMA [Essigkrug 2007]. The following concepts are represented: • A product (formerly Artifact) answers the question: what is the result? • A task (formerly Activity): Describes how something should be done. • A role-sets the responsibility for certain tasks. • An activity (formerly detail the sequence of activity) is the component of a process as fundamental. • A pattern of capacity and delivery process: cf. above. • Advice: instructions are, for example, techniques and information to build a product or perform an activity [Krebs 2008 and Shuja, S. 5].
Figure 8: Overview of key concepts of the UMA architecture [IBM 2008b] Unlike the sequential methods, like the cascade model, RUP is a methodology based on an iterative and incremental [Corporation 1998]. Figure 9 shows the two dimensions underlying RUP: • The horizontal dimension: is the dynamic aspect, that is to say processes. A development cycle is divided into phases and iterations. • The vertical dimension: is the content of the method or discipline. These are the grouping as inclusive as possible of the contents and methods of gathering all the tasks that match a particular area [cf.Essigkrug 2007]. The colored surface represents the intensity with which each discipline shall be held within each phase. As [Brandon and Brothers 2006] notes, RUP, iterative in nature, has a lot of overlap in the application of methods of its contents, for example, application components are tested only at the end of construction, but steadily, from the creation phase.
Figure 9: Static and dynamic aspects of RUP [IBM 2008b] Reviews Despite the flexibility offered by RMC to configure RUP to their needs, many criticisms are heard. [Brandon and Brothers 2006], for example, RUP does not consider appropriate for all software development projects. Specifically, he finds that for large internal projects and risky when it is necessary to quickly deploy a portion of the proceeds, RUP can be satisfactory. Wolfgang Hesse also expressed his criticism in one of his most famous articles [Hesse 2003]. He blames the OR, among others, his approach too focused on too much like the phases to phases of cascade model. It can not arise, according to his analysis, a methodology focused on architecture, prides itself as the OR of being. In [Riaan, Stefan and Derrick 2007], RUP is still described as being very expensive to implement. Using RUP in this work In this master thesis, to satisfy the key principle of RUP "Adapting the process," a lighter version of the delivery process for small projects will serve as a guideline. To "raise the level of abstraction," UML modeling techniques and prototyping will be used. Disciplines and techniques used in this work are described in more detail in later chapters. 3.1.2 Code requirements The purpose of discipline requirements gathering is to describe what the system should do and allow developers and customers to agree on this description. To achieve this goal, the required functionality and constraints must be expressed, organized and documented the compromises and decisions must also be documented [Corporation 1998]. Gather user requirements is central to a project to develop software and should not be underestimated. For this reason, RUP is based on use cases as a thread throughout the development process (see 3.2.1). As the use cases are developed according to the needs of stakeholders, the system will thus most likely to match user expectations [Shuja and Krebs 2008]. Figure 10 shows the activity diagram of the discipline Code requirements. Each activity shown in this diagram is divided into tasks which themselves are composed of steps. RUP documents for each activity in each discipline what are its components, managers and the products used and products [IBM 2008b]. The bulk of the work in this discipline is the responsibility of the analyst system. Some important tasks are: • define a common vocabulary for end users and producers of the project, • Identify actors and use cases (see section 3.2.1), • develop a vision of what the system should do • determine the demands of stakeholders, • develop additional specifications, • prioritize the use cases, • structure the use case model, • a detailed use case. RUP offers several products that can be delivered by the Reports of discipline requirements. As part of this work, the product specification of software requirements (Software Requirements Specification) will be produced (see Section 3.2.1).
Figure 10: Pattern Collection capacity requirements [IBM 2008b] 3.1.3 Analysis and Design The purpose of this discipline is to show how the system will be implemented. It provides a bridge between user requirements and technical platform. After a user perspective, we pass by an architect who will view the result of the implementation of the software [Corporation 1998]. The design is done: • meet all user requirements, • have a robust architecture, • be environmentally suitable implementation [Shuja and Krebs 2008]. Figure 11 shows the sequence of activities of the Analysis and Design discipline. Tasks are made, including: • The architectural analysis (for discussion on the architecture cf. Chapter 5) • Designing a user interface, • Creation of a prototype user interface (see Section 3.2.2), • Design classes (see Section 3.2.1), • Design of the database, etc.. [IBM 2008b]. [Chris and Elizabeth 2002] describes how the user interface design is supported in the RUP. As part of this work, the following will be achieved: • A first prototype of the interface, created on paper (see Section 3.2.2), • an evolutionary prototype that will include coded during the usability testing (see chapter 3.1.4), • a design model (see Section 3.2.1). It is important here to emphasize the importance of working closely with users of the software, when creating the prototype of the user interface. This can help in the management of the usability of the system, the discovery of new requirements and detailed requirements definition [IBM 2008b].
Figure 11: Pattern Analysis and design capacity [IBM 2008b] 3.1.4 Implementation and test Implementation Implementing discipline is made up of the implementation of the components (or services) and successive integration in the system. The test developers, code reviews and bug fixes are also included [Essigkrug 2007]. Several roles are well engaged in this discipline: software architect, integrator, the implementer and the technical editor. Figure 12 shows the pattern of capacity for this discipline.
Figure 12: Pattern implementation capacity [Rajalekshmi 2008]
The different roles share the following tasks: • The software architect is responsible for the physical structure of software components and the way in which classes and packages are organized in the data system. • The implementer is responsible for the implementation of components, developer testing and implementation of these. A test developer is a test suite that validates the proper functioning of the component, it is composed mainly of unit tests (a test unit checks an object or multiple objects separately) [IBM 2008b]. The implementor must also test the behavior of the code at runtime. • The integrator plans and implements the integration of different components. • The technical editor is responsible for code review. Test Test discipline plays a key role in quality assurance, as it is controlled by the executable software meet the requirements [Essigkrug 2007]. The goals of testing are: • verify the interaction between objects, • check that the integration of all components of the software is well done, • ensure that all requirements have been implemented • identify and to ensure that the defects were corrected before deployment of the software [Corporation 1998]. RUP offers an iterative approach, which means that tests are carried out throughout the duration of the project. In this way, defects can be detected as early as possible, reducing the cost to repair [Shuja and Krebs 2008]. Figure 13 shows the pattern of capacity is proposed to perform the tests. ORs are several quality risks, including risks of functionality, usability, reliability, performance and support. For each of these areas, RUP offers different kinds of tests [IBM 2008b]. In this work, test developers in the form of unit tests will be performed. Usability testing will evaluate the usability of the GUI by representative users.
Figure 13: Test Pattern capacity [IBM 2008b] 3.2 Techniques: Unified Modeling Language (UML) and Prototyping 3.2.1 Unified Modeling Language (UML) UML: a modeling language Unified Modeling Language (UML) is a modeling language whose original purpose was to enable the computer to represent a software system and its intended use in the company. This should help increase the rigor and quality of the construction of applications they developed [Morley, and Hugues Leblanc 2006]. UML is a standard non-proprietary, defined by the OMG. Its origins lie in the mid 90s. The authors of the early versions of UML are the same as RUP or Booch, Rumbaugh, Jacobson. Since November 2007, the OMG UML 2.1.2 released version, and is now working on Version 2.2 [OMG 2008]. Is described by a UML meta-model, ie a model representing the elementary constituents of UML with their usage rules and syntax. This allows, among other things, to ensure consistency between different tools, methods and models using UML to facilitate the exchange between workshops [Morley, and Hugues Leblanc 2006]. It should not be confused with UML software development methodology. UML provides several types of diagrams for modeling different aspects of the development process, but it does not give instructions on the use of these models in the development process. This will be the task of a development methodology, such as, for example, RUP (see section 3.1.1) [IBM 2008b]. The UML use case The discipline of RUP requirements gathering advice for all projects, to create a UML use case [Admiraal 2007b]. The latter describes the information system from the perspective of users and allows for better integration of user requirements in the development process. It serves as a thread throughout the project and for this reason, RUP is said to be based on use cases [Corporation 1998]. A use case is a specific way to use a system. It answers the question: what the actor does he achieve by using the system [Admiraal 2007b]? A use case is a grouping of activities triggered by an external actor that produces an identifiable result: a feature of the system [Morley, and Hugues Leblanc 2006]. A UML use case includes the use cases and shows the links between them and the actors. Dependencies between different cases may also be represented. A textual description of the full model, the following may be included: the purpose of the event, players can trigger the event, the sequence of actions, business rules and reference materials used or produced during the activities of If [Morley, and Hugues Leblanc 2006]. Figure 14 shows a model can be an automaton of the University of Fribourg. With the latter, a student is able to load the card, control data and to change them. These three features, the actor "student" and the relationships that link them are illustrated in the diagram. In this work, several use case diagrams are created. They will be complemented by the product of ORs "Specifications extra" containing non-functional requirements and additional functional requirements. The use case diagrams and specifications together form the additional work product "Specifying software requirements," English "Software Requirements Specification." The latter describes all the requirements of the system or part of the system [Essigkrug 2007].
Figure 14: Example of a use case diagram Class diagrams Class diagrams are among the most commonly used diagrams in modeling object-oriented systems [Booch, Rumbaugh and Jacobson 2000]. They represent the static structure in terms of classes and relations between these classes [Muller 2000]. A class is an abstract description of a set of objects of the application domain. It is represented by rectangles compartmentalized: the first compartment is mandatory and contains the name of the class, the second and third are optional are respectively contain attributes and operations of the class [Muller 2000]. Relations between classes describe potential links from one object to another object. Thus, it is possible to have a class with other classes: • a dependent relationship: expresses a relation of use of one class by another. • a generalization relationship: is a relationship between a general element and an element derived from it, but more specific. The generalization applies when it is possible that the more specific element that is "a kind of" the more general element. a relationship of association expresses a structural relationship that specifies that objects of a class are connected to objects of another class [Booch, Rumbaugh and Jacobson 2000]. Figure 15 shows an example of class diagram. Classes "Fish" and "Bird" are both "kinds" of animals. For this reason they are connected to the class, called superclass, "Animal" by a generalization relationship. Thus, these two classes, called subclasses inherit the attributes and methods of the superclass, that is to say that the objects of the class "Bird" and Class "Fish" automatically inherit the attributes " speed "and" weight "and the method" eat ". Class diagrams are used to model the static design view of a system. They can be, among others, used to model the vocabulary of the system, model collaboration between scheduled classes or to schedule a diagram and model database [Booch, Rumbaugh and Jacobson 2000]. In this work, the class diagram will serve as a model design for programming [Admiraal 2007b].
Figure 15: Example of a class diagram 3.2.2 Prototyping Prototyping, such as technical development of computer applications, first appeared in the literature of software engineering in the 1980s, but has not enjoyed great importance in the texts of information systems into the year 1990. The development of web based technologies and the increased emphasis on rapid deployment systems have contributed to the increase in the use of prototyping in software development over the last decade [Zant 2005]. Prototyping can be defined as the process during which a preliminary business model for an application, called prototype is created [Budde and Züllighoven 1990]. The latter development assistance software at several levels, most often for: • develop and evaluate user requirements, specifications and product design; • demonstrate the feasibility, performance, system behavior, etc..; • identify and reduce the risk of poor development of the system; • better communication, especially between different groups; • answer questions about the properties of the system [Luqi and Steigerwald 1992]; • to plan product development; • better define the product and strategy [Arnowitz, Arent and Berger 2007]. As described in [Arnowitz, Arent and Berger 2007], the technique of prototyping can be introduced at any stage of software development, even at different stages of the process, for different purposes. This will allow, for example, to create a prototype in the analysis phase to better understand user needs, but also to make a prototype in the implementation phase to test the performance of parts of the system as an algorithm system or database, etc.. [Zant 2005]. To be effective, a prototype should be built and modified rapidly, accurately and without great expense. It should not be neither efficient, comprehensive, portable and robust and it does not use the same hardware, software or implementation language that the system to produce [Luqi and Steigerwald 1992]. [Wood and Kang 1992] presents an overview of technology and literature relating to the creation and use of prototypes in the field of software systems. It is clear from his analysis that, according to the author, classifications and terminology are used. [Wood and Kang 1992] proposes to classify the approaches to prototyping observed in a relatively general, based on several features clear and distinct, rather than ambiguous abstractions. In [Arnowitz, Arent and Berger 2007] Also, a general classification is used, it is based, among other things, the following characteristics: • the audience (the target audience of the prototype is it made the team of programmers, customers, etc..?) • rapid prototype development, • the phase of software development in which the prototype is used, • the life of the prototype, • the similarity of the prototype to finished product. According to [Wood and Kang 1992] Another useful classification is performed according to the function of the prototype. This will be a prototype: • Experimental (also called fast-concept, disposable or exploration) will not be used in the final product, or • scalable: it will be constantly improved to be finally delivered to the customer as a final product. The RUP (see section 3.1.1) follows this categorization by function and adds another depending on the subject of exploration of the prototype. Two types emerge: • the prototype of behavior: it explores the specific behavior of the system. • the prototype structure: it explores the architectural and technological issues [RUP 2008]. In [Arnowitz, Arent and Berger 2007], different methodologies and tools are described to perform an effective prototyping. It appears that the corner of the tablecloth, the Framework object-oriented through the video camera and the PowerPoint presentation, virtually any tool can be used effectively to create a prototype, the importance of being fit means to ends [Pomberger and Weinreich 1994]. In this master thesis, an experimental prototype on paper the GUI will be created at the beginning of the analysis phase and design (see Section 3.1.3). It will only be used internally as a basis for development and communication. An evolutionary prototype is then created using the Framework Visual Studio. The hearing of the second prototype will consist of end users.
Series 4 requirements of SI BSU As explained in Chapter 3.1.2, the purpose of discipline requirements gathering is to describe what the system should do and allow developers and customers to agree on this description. This chapter answers the question: what features are expected by stakeholders to set up the game? According to RUP, the answer will be given as use cases (cf.3.2.1), the activity diagram and textual description. 4.1 Analysis Preliminary To find the solution that will increase the more effective when configuring the game, interviews were conducted with administrators BSU. The complete process for current configuration of the game was done once sets to identify problems and potential for improvement. The wishes and comments of the directors were taken into account. From this preliminary stage of analysis emerged the following important points: • Instructions for configuring the game are currently on a sheet or incomplete file that we must search each time. • The procedure for setting the game is done directly in the database (see arch): no graphical interface is used. • The result is often desired that the functions of sorting and searching the database must be in query Structured Query Language (SQL). • The same information must be entered in several different tables: Ex: For PMS, the dates of the games must be returned once for the Classic and a portfolio for both derivatives portfolios, as they are the same. • The direct manipulation of the database can generate errors if all the constraints are not taken into account. Ex: trying to delete tables containing primary keys referenced by other fields in other tables. • The configuration steps are no longer for years because they are not necessarily mandatory, but recommended, Ex: adjustment of interest rates. • Administrators do not know what to match certain fields and often the same questions arise. • Lack of a computer program documentation for how the fields in the database are required. All these points contribute greatly to the increased time required for an administrator to configure the game to overcome these points, the prototype solution should in all cases: • Provide a friendly interface where the setup instructions and a description of the fields should appear. • Provide the functionality of sorting and searching. • Automate certain procedures: Ex: dump. • Provide a common entry to mask the information to be equal. • Provide comprehensive documentation of the prototype generated for it to be kept up to date in the future. 4.2 The Product: Software Requirements Specification (Software Requirements Specification) 4.2.1 Framework As seen in 3.2.1, the software requirements specification is a description of all requirements of the system or part of the system. This chapter will be based on the model of the system created in the BSU [Shehu 2008]. In the latter, four types of features have been identified and grouped in the form of use cases in four main packages: Admin, Computing, Registration and Negotiation. The configuration of the game is in the package is Admin and the Use Case 2 (UC2): Package Admin: 1. (UC1) Update the website (the Administrator) 2. (UC2) Set up the game (by the Administrator at the beginning of the simulation) 3. (UC3) Set up connection to the SWX 4. (UC26) Import courses SWX (the PLC)
Error! Reference source not found. shows the diagram of the model when using the Admin package with the use case "Putting the game in place."
Figure 16: Diagram "Admin" Admin package with the CPU "Putting the game in place" [Shehu 2008] The UC2 is our subject of analysis and will be described in more detail in 4.3.1. 4.2.2 Definitions, Acronyms and Abbreviations As discussed in Chapter 3.1.2, an important task of the code requirements is the definition of a common vocabulary for end users and producers of the project: • Director: a person authorized to administer the game • Calculation of the game: import closing price of PMS in the program and updating of portfolios of members. • Negotiation: placing a market order in the game PMS • Period - one business day of the grant during the game PMS. • System: website design created for configuration sets the BSU • Alternative gaming: Simulation organized by the BSU and being composed of sets (see game), The Ex PMS is a variant of game • Game: Constituent of a variation of different game play (Classic and Derivative) allow a different portfolio composition • Classic - the classic game, where you can trade stocks, bonds, options, currencies and funds. • Derivative - the game derivative, where only the options can be negotiated. • Sub-menu "Titles" are part of the sub-menus "Securities" menus "Actions", "Obligations", "Options", "Currency", "Fund" • Emptying Tables: Action by which the tables used for calculations are emptied and the periods used in other tables are reset • Menu "General" menu contains all the general configurations of a modified game • Game Menu: Menu "Classic" and "Derivative" corresponding to the game content in an alternative game • Player - anyone with an account in the database BSU. 4.3 Specification of use cases (Use-Case Specification) The use case UC2 is the subject of analysis in this present work, it requires a more detailed description. It will be made, first, in text form by following certain rules of structure to facilitate the expression, understanding and consistency. It will show the flow of events describing the interactions between actors and the system. This form of description use case specification is called use case in the OR. It provides examples and stencils for specifying use cases. Second, an activity diagram showing the description in the specification of the use case UC2 will be created. It will allow a macroscopic view and time of the modeled system. 4.3.1 Use Case UC2 Put the game in place Objective: This use case is used to configure the game early in the period of variant Thurs Actor: The Administrator Main timeline: Preconditions: - The Administrator has the right to access the system - The period variant game has not started - No sub-menus "Securities" has been configured using periods Actions: 1. The use case begins when the Administrator has successfully logged on the system. 2. A home page prompts the user to choose an alternative set of games 3. The Administrator chooses the alternative games 4. A start page for configuring the variant game gives a little explanation of the steps to do so. 5. The Administrator clicks the menu item "Empty Tables" 6. The page of "Empty Tables" is displayed with an explanation of the process 7. The administrator presses the button to empty the tables 8. The system asks for confirmation of the Administrator 9. The Administrator confirms its action 10. The system displays a message that he is to perform the action requested. Meanwhile, the empty tables (Bank BedingungManuell, Kurs, Member_Session, Mutation, Portfolio, Rangliste) and puts all the periods used in other tables (Allgemein, Titel, and BedingungManuell Bedingung) is null, or at the period early in the game when these actions are completed, it displays a message that the tables have been successfully flushed. 11. The Administrator clicks on the menu "periods" 12. The page "periods" is displayed with a little explanation 13. The Administrator clicks on the Stock Exchange for timing business. After consultation it is up to the system. 14. The Administrator selects the calendar system working day from the stock exchange and click the button to save the periods 15. The system deletes the old times and new backup periods selected by the Administrator. In doing so, he enters twice in the first period and called the first of two "Initializing." The last time entry is named "End". Fields and SpielBeginn Spielende Allgemein table are adjusted for selected dates. 16. The main scenario continues in the alternative scenarios 16.1., 16.2., 16.3., 16. 4. The order of execution of these scenarios is equal, but they must all be executed. 17. The Administrator logs off the system. 18. The use case ends here. Postconditions: - All menus a variant of the game have been configured.
The numbers of alternative scenarios correspond to a connection alternative: Ex 1.a. corresponds to activities instead of activities of the main timeline starting at 1. Alternative scenarios 1.a. Dump table when the game has already begun Preconditions: - The current date is in the range of periods returned to the table "periods" (The game has already begun) - The Administrator will still clear the tables Actions: 1. The use case begins when the Administrator has successfully logged on the system. 2. A home page prompts the user to choose an alternative set of games 3. The Administrator chooses the alternative games 4. A start page for configuring the variant game gives a little explanation of the steps to do so. 5. The Administrator clicks the menu item "Empty Tables" 6. The system displays a page saying that the emptying of the tables can not be done with a link to still be able to access 7. The Administrator clicks on the link to still access the dump table 8. The continued use to the main timeline for action 6. 16.1. Configuration menu "General" Preconditions: - The menu "Periods" has already been configured - The variant of play has not started Actions: 1. The Administrator clicks on the "General" menu to edit the general information of the game 2. The system displays the "General". 3. The Administrator clicks on the button to edit the entire table 3.4. The table in edit mode 4.5. The Administrator introduced the changes and weigh on the button to save the table. 5.6. The system saves the changes and puts the table in reading. 6.7. The continued use to the main timeline for action 16 Postcondition: The General menu has been configured
16.2. Configuring players Preconditions: - No precondition Actions: 1. The Administrator clicks on the menu "Players" 2. The system displays the "Players" 3. Conditions: The Administrator will only change one or more fields "inactive member", "Paid" or "Blocked" to one or more players - The Administrator clicks on the boxes for the fields to change - The system displays a cross and saves the changes directly 4. Conditions: The administrator wants to change information other than "inactive member", "Paid" or "Blocked" to one or more players - The Administrator presses the "Select" corresponding to the player - The system displays all the information for this player - The Administrator clicks on the button to edit the entire table - The table in edit mode - The Administrator introduced the changes and click the button to save the table. - The system records the changes and puts the table in reading 5. Conditions: The administrator wants to see information other than "inactive member", "Paid" or "Blocked" to one or more players - The Administrator presses the "Select" corresponding to the player - The system displays information about the player 6. The continued use to the main timeline for action 16. Postcondition: - Menu "Players" has been configured
16.3. Configuration menus or games Preconditions: - The period variant game has not started Actions: 1. The Administrator hangs over the game menu "Classic" 2. The system displays the game page 3. Condition: The Administrator wants to change as a limit in the portfolio - The Administrator weighs on the button to edit the line to change - The field "limit" is being selected in edit mode - The Administrator introduced the value and click the button to save - The line is recorded - The Administrator will repeat the point 3. for all the fields he wants to change. 4. Condition: There is a game "Derivative" The continued use in an action. this scenario with the menu "Derivative" 5. The continued use to the main timeline for action 16. Postcondition: - The game menus have been configured
16.4. Configuration sub-menu to "Titles" Precondition: - The tables have been emptied - The periods have been gathered Actions: 1. The Administrator clicks on a sub-menu to "Titles" 2. The system displays the page corresponding to the class of securities selected 3. Condition: The Administrator wants to delete a title - It weighs on the "Clear" button corresponding to the title to be erased - The system asks for confirmation - The Administrator confirms - The title is deleted 4. Condition: The Administrator wants to create a new title - The Administrator weighs on the button to create a new title - The system displays a form to create a new title - The Administrator completes the form and press the button to save - The system records the new title and the form disappears 5. Condition: The Administrator will find information on a title - The Administrator presses the button to select the title - A page with all the details of the title is displayed 6. Condition: The Administrator wants to change the information of a title - The Administrator supports the button to select the title - A page with all the details of the title is displayed - The Administrator enters the changes and click on the button to save - The system records the changes 7. The administrator repeats this scenario to an action. for each sub-menu to "Titles" and for each game 8. The continued use to the main timeline for action 16. Postcondition: - The sub-menus "Titles" were configured
* A. One or more fields are returned false Preconditions: - An incorrect value was returned in a field and the Administrator has pressed the button to save changes Actions: 1. The system displays an error 2. Administrator presses the 'Back' button of the browser 3. The page is redisplayed with unsaved changes 4. The Administrator corrects the fields and supports knew the button to save the changes. 5. The continued use to the main timeline where it left off Postcondition: - Fields were recorded
* B. The Administrator remains idle for too long on the page Precondition: - Inactivity of the Administrator is longer than the timeout of the server Actions: 1. The system displays the login page 2. The Administrator enters his login and password and press Connect 3. The system displays the home page 4. The use case continues where it left off or a few steps before Postcondition: - The Administrator is logged in again - The system will display the last active page (or grafted page ...)
* C. A title or a player looking for is not visible on the page Precondition: - A title or a player looking for is not visible on the page 1. Condition: The Administrator wants to search by keyword - The Administrator enters the keyword (name, surname or email for a player; German name, French name, ISIN or name of an import title) - The system searches and displays the corresponding results or a message that the search was unsuccessful. 2. Condition: The Administrator will find by sorting by column - The Administrator clicks on the name of the column after which he wants to sort the rows - The system redisplays the lines in ascending order of the selected column - Status: The Administrator will sort the rows in descending order: - The Administrator clicks on the column after which he wants to sort the rows - The system redisplays the lines in descending order of the selected column. - The use case may continue to Action 2 of this scenario or continue to Action 3. 3. Condition: The Administrator will look by choosing the page to display - The Administrator clicks on the menu swap - The corresponding page is displayed - The use case can go in 2 or 3 or 4 point. 4. The continued use to the main timeline where it left off Postcondition: The title or the player looking for was found or does not exist
* D. The Administrator wants information on a field Precondition: - The Administrator wants information on a field Actions: 1. The Administrator clicks on the icon of the field of information 2. The system displays information 3. The Administrator supports on the cross to close the message 4. The information message disappears
Activity diagram use case UC2 "Establishment of the game" Figure 16: Activity diagram of the UC2 "Establishment of the game" summarizes the sequence of activities to do during the set up of the game
Figure 16: Activity diagram of the UC2 "Establishment of the game"
5 Analysis and design of the IS BSU As explained in Chapter 3.1.3, the purpose of discipline "Analysis and Design" is to show how the system will be implemented. It provides a bridge between user requirements and technical platform. The next question will be answered in this chapter: What benefits can make an architecture in three stages (three-tier architecture) in the design of the site configuration? Design patterns (design patterns) and. NET technologies used to design such an application will be subject to this chapter. 5.1 Architecture of the current information system of the BSU 5.1.1 Overview This chapter is based on [Shehu 2008] and [Husemann 2007]. The system information (SI) current BSU is based on a set of servers connected to the network within the University of Fribourg. Figure 17: Architecture of the components of information system BSU [Husemann 2007] represents a simplified model of the IS. The following components are included: • The BSU website: It is available at URL: www.unifr.ch / bsu. It is the visible part for the players: the place where they can manage their portfolio. It consists of two parts: o the public part coded in HTML and JavaScript. o secure part of a dynamic, for members and coded in ASP.NET. The website is on an IIS web server located on a virtual server (VM). • PMS Administration (Access): This program is based on "MS Access 2003." It is used for configuration and calculation of the simulation. It is connected to the database is accessible by BSU and the PC called BSUPC04 or the physical server called BSUPC03. • The database BSU (PMS DB): It is based on MS SQL Server 2005 which is on the physical server BSUPC03. It contains information on all the games organized by the BSU. It is used by the program Access PMS, the BSU website, the import program of courses and the data warehouse. • The import program courses (SWX Quote Import): Java program that imports the actual course of the SIX Swiss Exchange and put them in the database BSU. It is connected to the system FQS in Chapter 2.2. • The data warehouse BSU (Datawarehouse PMS): It is based on the program Microstrategy. It is a tool for data analysis of stock market simulation (Online Analytical Processing, OLAP) that players can visit the website. Data is loaded from the database BSU by ETL (extracting, transforming, loading). The configuration of the data warehouse is from software "Microstrategy Desktop" (MSTR Desktop) installed on the server BSUPC03.
Figure 17: Architecture of the components of information system BSU [Husemann 2007] Currently, several projects are under way to improve the architecture of the BSU described above. The import program of courses and PMS Administration program (Access) make among other party.
5.1.2 Components used in the current configuration of the game As stated in Chapter 4.1, the configuration of the PMS is being done mostly on the way and erase their values directly from the database (DB PMS). The PMS Administration (Access) has, admittedly, some interfaces to manage certain aspects of the game, but only its management interface players can be used during the initial setup of the game 5.2 Design of the desired application 5.2.1 Layered Architecture Architecture As written in [Fowler and Rice 2003], the word architecture is a term that has often been described in the software industry, but whose definition is not consensus. Two are both right recurrent: • an architecture is the division of high-level of a system component parts, • the architectural decisions taken are difficult to change. This definition derives some subjectivity. Indeed, if part of the system is easier to change it was supposed to start, it may be that it is not of architectural decisions, but "simple" design decisions. Layering A technique that can reasonably be described as architectural called Layering. This is one of the most architectures used by software developers to divide a complicated system [Fowler and Rice 2003]. A layer (layer) is a coherent group of related features. In an architecture called "layered" strict layer n can only use the services of layer n-1. In practice, this restriction is sometimes lax [Bass, Clements and Kazman 2003]. Figure 18 shows the hierarchical organization of layers in the example of a security module.
Figure 18: A layered security architecture [Pfleeger 1998] The term "Layer" and "tier" The terms layer (layer) and floor (third) are often subject to confusion and are often used as synonyms. But there is a distinction between these two words: "tier" means a physical separation on different machines. While "layer" refers to a logical separation: it is not required to perform the different layers on different nodes. For example, on a machine with a local database, it is possible to run an application in three layers on a "tier". It is also possible to separate several physical components as shown in Figure 19: Two-thirds [Fowler and Rice 2003].
Figure 19: Two-thirds [Oldby and Dan 2006] The three main layers The difficult part of the layering is to know how many layers you must divide its application and what responsibilities they assign. In this present work, a classic three-layer architecture will be applied, in fact, the responsibilities within the site configuration can be logically separated into three layers: • A presentation layer (Presentation Layer) is responsible for the interaction between the user and the software. It should display the information and interpret commands from the user. • A business logic layer (also called business logic layer, or Domain BLL layer): It is responsible for the implementation of rules and business logic calculations. She runs the logic on the basis of data from users and DAL [Fowler and Rice 2003]. • A Data Access Layer (Data Access Layer, DAL): It handles the communication with other systems that perform tasks requested by the application. These can be databases, messaging systems, other applications, etc.. Figure 20 illustrates the organization of these three layers.
Figure 20: The three traditional layers [Mitchell 2006] 5.2.2 Model View Controller (MVC) Pattern Model View Controller (MVC) divides the user interface interaction into three distinct roles: • Model: represents the gateway to the business logic and is responsible for application functionality [Mortensen, McGovern and Liptaak 2003]. • View: it deals exclusively with the display of information to the user. • Controller: It is responsible for interpreting the requests of the user to manipulate the model and display the appropriate view in response [Fowler and Rice 2003]. Figure 21 shows the sequence of activities triggered when an event such as a page request is generated by a user: 1. The request is intercepted by the Controller. 2. The controller evaluates the event and asked the model to run the business logic required. 3. The model performs the actions requested and returns the results to the Controller. 4. The controller determines the view to be displayed. 5. The view is loaded. If it needs to display data from a data source, it can not receive them by the Model. It is impossible to perform actions (such as a call to a database) directly. 6. The view is displayed on the user interface [Mortensen, McGovern and Liptaak 2003].
Figure 21: Model View Controller pattern [Mortensen, McGovern and Liptaak 2003] 5.3 Advantages and disadvantages of a three-layer architecture In general A division into layers of an application can provide several important benefits: • Low interdependence (low coupling) between components of the system. The interdependence is characterized by the intensity with which the elements are connected to each other: if they know of the existence or if they use the services of other elements. Little interdependence reduces the impact of changes made to the system. A layer can be substituted by another as they offer the same services, the implementation is so high, the interface is paramount [Oldby and Dan 2006]. It is thus possible, for example, to have several different presentation layers (eg a command line interface and a web interface) using the same business logic layer [Fowler and Rice 2003]. • High cohesion (high cohesion) within each layer. Cohesion refers to the intensity with which an item is focused on its responsibilities. Thus, a layer with responsibilities closely related and not running many different tasks is called "high cohesion". This quality makes the system easier to understand, reuse, maintain, and, as a side effect, reduces the interdependence between different components [Oldby and Dan 2006]. Each layer can be considered as an additional level of abstraction and the system can be designed as a decomposition of a complex problem into a sequence of abstract steps [Pfleeger 1998]. There are also some negative points to mention: • The division of the system in different layers means more work for implementation at the beginning since many components must be created. The code may seem too complicated for less experienced programmers [Oldby and Dan 2006]. • A change in one layer can result in a cascade change in all other layers. A typical example is the addition of a new field in the database: if it is to be displayed in the presentation layer, the change will be in the data access layer, presentation layer and all layers between two [Fowler and Rice 2003]. • Additional layers can affect system performance. It is often very likely that the encapsulation of underlying functions in a single layer optimizes resulting ultimately in a performance gain [Fowler and Rice 2003]. For BSU Compared to current components used to set configuration (see 5.1.2), a big negative for the creation of a layered application is the complexity of the resulting architecture. Indeed, the great strength of the current configuration of the game is that the architecture is very simple (only a database!). The configuration of the game is now very clear (the administrator always knows what data is put into the database!). For less experienced developers that simplicity is a great advantage that should not be underestimated. Hence arises the importance of keeping the site design configuration architecture as simple as possible with known patterns. A three-layer architecture, with the use of the MVC pattern to structure the interaction with the user interface is a good solution. 5.4 Design of the desired application. NET As seen in Section 5.1, the architecture of the BSU is based almost entirely on Microsoft technologies. To keep the consistency and use the latest technologies, the site configuration will be based on the ASP.NET 3.5 Framework. This will enable us, among other things, to use LinQ (see 5.4.5) and the new AJAX controls (see 5.4.3). The language chosen is C # because it has the advantage of Java is very similar to teaching at the University of Fribourg, this will simplify site maintenance. In addition, currently, there are more professional developers that C # VB [Walther 2007], this fact is reflected, among other things, the number of online help and books published in C #. This chapter focuses on the early design with the overall system. NET technologies. Then the three layers are described in more detail. 5.4.1 Layered Architecture. NET The purpose of this chapter is to examine how to implement the architecture described in 5.2.1 with. NET technologies. Represents a crucial point in this context, access to data. Object Relational Mapping (ORM) Data access will be implemented using technologies Object Relational Mapping (ORM) Microsoft. ORM allows a program written in an object-oriented language to file objects in a relational database as if it was an object-oriented database. It is therefore no need to write SQL commands and programming is facilitated [Flasko 2008]. The commands to manipulate objects will be made in Language Integrated Query (LINQ). The latter is an extension of. NET languages (under the Framework 3.5) with data query capabilities. In Chapter 6 examples of LINQ query will be displayed. There, at the time of preparation of this work, two ORM technologies from Microsoft that could be used in the implementation of the DAL: • LinQ to SQL: Provides direct 1-1 mapping of a database to Microsoft SQL Server. NET classes and the creation of LINQ query with the resulting objects. LinQ to SQL was developed for a scenario of rapid design (RAD: Rapid Application Developer) with a database where the Microsoft SQL Server database has a great resemblance to the object model of the application [Flasko 2008 ]. • ADO.NET Entity Framework (LINQ to Entities): Allows a flexible mapping and the ability to have a large discrepancy between the data storage and the underlying object model of the application. It is therefore much more complex and flexible than LINQ to SQL and is a business scenario [Arefin 2008]. Unfortunately, the ADO.NET Entity Framework was still in beta at the beginning of this project. For this reason, the choice of ORM is restricted to LinQ to SQL. LinQ to SQL Using LINQ to SQL in the application development can significantly reduce programming time, certainly, but why the price is to disseminate the LINQ to SQL queries directly where the result is used. LINQ queries to SQL and must be made in the business layer and presentation layer. This creates a dispersion of data access in all the code and therefore runs counter to the model in three layers. To keep a pure three-layer architecture, it is necessary to create a data access layer separated. Only within the latter, it will be possible to do LINQ queries and list them. The DAL will return objects, not LINQ to SQL. And requests made to the database will not be launched from any part of the application [Marguerie, Eichert and WOOLEY 2008]. This strict separation into three layers means a lot of plumbing code and more. Nevertheless, it is necessary to achieve the benefits of good architecture discussed in 5.3. Use of data in the presentation layer To display data in the presentation layer, you can use with LINQ to SQL two different controls: • LinqDataSource: This new control allows you to use LINQ in an ASP.NET page to search and modify data. His great positive is that it greatly reduces the code to implement: for commands such as selecting, updating, inserting, deleting, sorting and paging are created dynamically by the control! However, its use implies a direct link to the presentation layer with the layer of data which is not a good design practice [Esposito, 2007]. • ObjectDataSource: Connects to the presentation layer components of the diaper business. Methods such as the selection, updating, inserting, deleting and sorting must be created manually unfortunately all [Corporation 2008]. Only the ObjectDataSource can be used in the present work because it is the only control to allow a clear separation into three layers. As emphasized in [Oldby and Dan 2006], the use of ASP.NET with Visual Studio encourages the presentation layer to connect directly with the data access layer! Overview The system was implemented by creating different projects in Visual Studio. Thus it would be possible to separate the three layers of three different machines (Three others). The programming will be against an interface and using the pattern that will promote the independence of the layers. FFigure 22: illustrates the various components of the system: • BSUConfiguration: is the presentation layer. It is implemented in an ASP.NET website. • BLL: is the business layer. It is implemented in a C # class library. • DAL: is the data access layer. It is implemented in a C # class library. • Entities: corresponds to the model objects that are handled in three layers. It is implemented in a C # class library created based on the model of the database through ORM technology LinQ to SQL (see Chapter 5.4.5). • CommonObjects: corresponds to the model objects that are handled in three layers. It is implemented in a C # class library. Objects are created in the DAL based on the file DAL.xml. • The file DAL.xml and the database: they provide the data necessary to create objects of classes contained in the packets and CommonObjects Entities.
Figure 22: The composition of the system in different packages 5.4.2 Model View Controller. NET ASP.NET does not implement the MVC pattern as seen in Chapter 5.2.2: the controller does not act on the application level, but at the level of individual pages. The URL does not match the Controller action, but to a page on disk [Corporation 2009]. The pattern implemented by an ASP.NET page called "Page Controller" [Fowler and Rice 2003]. An ASP.NET page is divided into two parts: the view that contains the various controls and a C # class that corresponds to the Controller. This contains functions for each action that the Controller may take when an event is generated and it is to process the page. These functions can be connected to the Model View and the resulting [Mortensen, McGovern and Liptaak 2003]. If a controller at the application level is necessary, it can be created using the HttpHandler, as it intercepts the request before the ASP.NET pages [Oldby and Dan 2006]. Microsoft has released a beta version of ASP.NET MVC framework. The latter implements the MVC pattern as seen in Chapter 5.2.2, it is unfortunately currently only available in beta [Corporation 2009]. 5.4.3 Presentation layer Next to the PMS, the BSU organizes several other simulations exchanges. In this context, it is desirable that the website can be scalable and allow the configuration also other variants of games. As shown in Figure 23: Prototype of paper the layout of the site, each simulation will therefore have its own tab. It will be dynamically generated on the basis of information on the simulations in the file DAL.xml. The menu also will adjust dynamically depending on whether the simulation has only one version or also a version Classic Derivative. Information common to both sets (Classic and Derivative) will be united under the same menu items: for example dates of play for the Classic and the derivative are the same, there are only a sub-menu "periods." It will be the same for the sub-menus: "Players," "General" and "Empty Tables." The layout will be done through the Master Pages. They allow to give a web site a unified look. The browser uses the Sitemap and the SiteMapPath control to display a "bread crumb". A bread crumb informs the user about its position in the site. Due to the dynamic creation of tabs and the menu navigation will be dynamically adjusted by the Controller. The login will be managed by the Login controls and LoginStatus. The security settings are configurable from the web.config file. Ajax UpdateProgress control will be used to indicate to the user that the system is currently executing the query requested. It will be very useful when the system will need considerable time to complete a task, such as when emptying the tables. As described in Chapter 3.2.2, the implementation of the user interface will be based on a paper prototype. The latter was created for the entire site with only a few illustrations have been added to this document. Figures 23 shows the general layout of the site with its menu and dynamically created tabs. Figure 24 shows the contents of the "General" menu. The latter is based on the description of the use case of Section 4.3 and represents the alternative scenario 16.1: Configuring the "General" menu. Figure 25 is also based on the description of Use Case 2 represents the alternative scenario and 16.4: Configuration sub-menu to "Titles".
Figure 23: Prototype of the paper overall layout of the site
Figure 24: Configuration menu "General".
Figure 25: Configuration sub-menu to "Titles" 5.4.4 Business Logic Layer The business layer provides the presentation layer functions that are not related to the display data, but their treatment. In the case of system configuration BSU, these functions include, among others, the logic of selection, update, insert and delete objects. The logic of comparison between different values will also be implemented in the business layer and will be re-used in the presentation layer to implement sorting. Using the ObjectDataSource, all these functions must be created manually, unfortunately, (see Section 5.1). 5.4.5 Data Access Layer The data required to create objects of classes contained in the packets and CommonObjects Entities are respectively: • file DAL.xml, • the database.
DAL.xml DAL.xml file (see Figure 26) contains data on: • different versions of games (Ex: PMS, Derivative, Speed) • sets contained in each of these variants of play (Classic and derivatives).
Figure 26: Part of the file contents DAL.xml
Based on these data, objects representing the variations of play and games can be created in the DAL and other layers used in the system. The file also contains DAL.xml for every game the name of the mapping to use to connect each set with its data in the database (cf.ci below). The database The database contains information on BSU all variations of play in a single database. The tables of the latter belong either to a specific game, or they are common to all variations of games. The name of the table belonging to a particular game begins with a prefix corresponding to the number of game: Example for variant PMS game, the game Classic is the number 2. All tables containing only information about the game 2 then begin with the prefix "_02_" _02_Periode, _02_Allgemein, etc.. (See 9.3). Information common to all variants of the game are contained in tables without prefix: Ex: Gruppe. Mapping database with objects is carried out through the intervention of the DataContext. It lies at the heart of LinQ to SQL. He is responsible for most of the work, including: a complete collection of objects from the database and manage the connection with it [Marguerie, Eichert and WOOLEY 2008]. When creating the DataContext, two elements are required: • The mapping file: it describes the correspondence between the tables in the database and the classes contained in the package Entities. There is a mapping file per game • The ConnectionString: it contains the information to access the database. As the logical structure of information about a game is the same for all games, the classes contained in the package Entities do not represent the entire database, but only the tables corresponding to a game and those common to all games (see . Figure 28: Diagram of entities). Following mapping file which is passed to the DataContext, the entities will be linked to tables in the database corresponding to the game: Ex: If the mapping file "mapping02.xml" is passed to the DataContext, the objects that the DataContext will handle will be created , modified and deleted tables with the prefix _02_ and communal tables. Information about the correspondence between the mapping files and games can be configured in the file DAL.xml. Indeed, the database contains no information about the relationship between the tables and various games (Ex: the tables are prefixed with 02 to play the Classic PMS). The site configuration file by DAL.xml can change the list of games configurable by the system without having to recompile the application. Without a configuration file as DAL.xml information about the correspondence between the games and tables should have been coded in raw code. This would have had highly inflexible. The file also contains the ConnectionString DAL.xml. Figure 27 illustrates the components involved in the creation of entities.
Figure 27: ORM The class diagram in Figure 28: Diagram shows the classes of entities created by mapping the database and are also called entities. As discussed in Chapter 5.4.1, LINQ to SQL does not offer great flexibility to design the classes from the model database. It is, among other things, not possible to join several tables in the database into a single entity. This implies that it is not possible to create a single entity of two tables "Option" and "OptionDetails" although logically they represent the same class. An association may nevertheless be established between them. The only implementation inheritance as LINQ to SQL mapping is reached when all the elements of the hierarchy are in a table. Luckily, this is exactly the case of the table "Titles". The latter contains a record of all asset classes. It is therefore possible to create a class hierarchy with the entity "Titel" as a superclass and entities "Aktie", "Duty", "Currency", "bottom" and "Option" as subclasses . Class "Aktie" is, in turn, implemented as an abstract class and has as subclasses of the classes "SMIAktie", "SPIAktie" and "AuslandsAktie."
Figure 28: Diagram of entities
6 Implementation and Testing This chapter embodies the design of the system made in paragraph 5 in a file folder structure and programming. The implementation of the application into three layers, so it is configured using DAL.xml represents a considerable additional programming from its two layers for non-configurable (see 5). Subchapter 6.1 illustrates this and shows the implementation of the overall system. A second sub-chapter will be devoted to testing. 6.1 Implementation of the prototype This chapter focuses on the implementation of the system and provides some more detailed examples of some interesting parts of the code. Figure 32 shows the five projects created in VS to implement the structure described in Chapter 5.4.1. This chapter consists of five sub-sections each containing one of these projects.
Figure 29: The five projects created in VS The site configuration to be used not only by the administrator in charge of the configuration of the game, the system will not take over the management of parallelism (concurrency). Not to exceed the scope of this project, other aspects were not taken into account. Error handling, among others, was kept at a basic level. For more details, see the chapter "Perspective: other possible improvements to the architecture BSU." 6.1.1 The "BSUConfiguration" General structure As explained in Chapter 5.4.1, the presentation layer is created by ASP.NET 3.5. Files and folders component of the project site are illustrated in Figure 33.
Figure 30: Folders and files that make up the project "BSUConfiguration" Rérérences The presentation layer has references only to the object model contained within the projects "Entities" and "CommonObjects" and on the layer "BLL". Layer "DAL" is, according to a three-layer architecture strict, not referenced by "BSUConfiguration" (see 5.4.1). App_Code The files located in the App_Code folder is compiled dynamically by the Framework. App_Code in this project contains a class of control to display a customized message before deleting an entry (the control standard does not require confirmation before erasing). Aspx pages As discussed in Chapter 5.4.2, the aspx pages are the view, while the C # classes with them ("code behind" or "file aspx.cs") are the Controllers. Each URL corresponds to an aspx page. The data from the database are displayed on the page using the controls: • GridView: display data from multiple objects, • DetailsView: display data from a single object. These two controls will provide the objects to display through the ObjectDataSource control described in section 5.4.1. The functions it calls are in the BLL. The GridView and DetailsView have all the bubbles of information describing the fields. These bubbles of information are implemented in JavaScript in the file BSU.Master. The GridViews can be sorted by clicking on the headers of the table. These sorts of functions are implemented in the control itself and the methods for selecting objects (BLL project). The GridViews also have a personal pager to navigate between its pages. The latter is implemented in the code behind. Figure 31 illustrates these components using the screenshot of the "Actions" menu. The latter is the use case description in Chapter 4.3 and the alternative scenario is 16.4: Configuration sub-menu to "Titles".
Figure 31: Screenshot of the 'Actions' menu As described in section 5.4.3, more advanced controls such as Calendar and Ajax UpdateProgress control have also been used, respectively, in the pages "periods" and "Dump the tables." These controls allow you to give a simple web page look more approaching a Desktop program. Figure 32 shows the screenshot of the menu "periods." It fits the description of the use case of Section 4.3 and represents the main timeline action11. The implementation of events allows the Controller to make the website more dynamic and to adapt the controls to less standard scenarios in this project, they were particularly in demand (see below). Master Page The layout was made possible thanks to Master Pages (see section 5.4.3): BSU.Master and SpielVariante.Master. BSU.Master is applied to all pages of the site and has a container site (PlaceHolder). PlaceHolder in this, there may be content directly to the page (as in the Default.aspx page) or the second Master Page: SpielVariante.Master. It contains the menu of each tab and a PlaceHolder for the content of the page. Figure 32 illustrates, as an example, the three parts contained in the page "Periode.aspx": The top red is the Master Page BSU.Master, the left in blue is SpielVariante.Master, the content of the page "Periode.aspx" is displayed in the lower right. BSU.Master contains the login control "LoginStatus", the JavaScript functions used in the site, text bubbles information, breadcrum and setting tabs. The latter two, like the menu SpielVariante.Master are dynamically adjusted in their respective Class C #. web.config The web.config file contains the configuration information from the website as XML. Security settings are also included. As described in Chapter 5.4.3, the login is managed by the Login controls and LoginStatus located respectively in the login.aspx page and the file BSU.Master. Web.sitemap As described in Chapter 5.4.3, the navigation uses the XML file Web.sitemap and the SiteMapPath control to display the bread crumb. Dynamic adjustment of the latter to the structure of the website is configurable by the Controller.
Figure 32: The composition of the page "Period" Some implementation details As the programming standard scenarios in ASP.NET is very easy to do as much when it comes out of the beaten track, things get complicated greatly. The following examples illustrate these facts. As in the previous chapter, the entities are the same for different sets of BSU, ie d.elles do not have information when the game which they belong. It is in the DAL that will be determined how the table database entities to be connected. The LAD holds its information from the BLL which in turn holds the presentation layer. It is, indeed, in that each operation (create, update, delete) will be made directly associated with a game or a variant of the game So when, for example, the selection of an action it will always be necessary to specify not only the ID of the action, but also with what game it is connected. The ObjectDataSource (see Section 5.4.1) requires knowledge of the methods for creating, updating and deletion of BLL in order to work. With its attribute "DataObjectTypeName," it may take as parameter objects directly. The problem is that when the ObjectDataSource is working with objects (which is still the sense of object-oriented programming (OO)), it is possible to take, of course, other parameters for the method of selection, but not the method of updating! This is impossible, even through the C # code! The only solution would not work with objects, which would require to pass each value of each object one by one and to forget all the beautiful concept of OO. In the code system, this amounts to saying that it is possible, for example, to request the update of a security with a specific ID, but it is not possible to say what game this As part! Microsoft has not provided for the update to go other parameters that the object to update, we had to find a trick to still transmit the identity of the game DAL partner. This was done by adding two variables in the BLL: • currentspiel: is the game • currentspielviante: is the game variant Figure 33 shows the code added to the BLL. It shows the two variables and "setter" respectively.
Figure 33: Variables and currentspielvariante spielvariante the BLL These variables are updated since the presentation layer before each update through the implementation of the event OnUpdating. It is raised just before each update. Figure 34 shows how the values are taken from the Controller to move to the BLL.
Figure 34: updating function triggered when the event OnUpdating All functions for inserting and updating "save" the BLL do, therefore, only the object to update a parameter and removes the information about the game from the variable currentspiel (see Figure 35) .
Figure 35: function "save" the BLL This procedure can, of course, to divert the problem of setting the update function, but the BLL is a static class, it restricts the use of the site by writing to one user. This restriction is, in the case of the BSU, no problem, as only an administrator of the game have the rights set configuration (see 6.1). Another problem occurred when programming for the insertion of new shares in the page "Aktie.aspx." Entity "Action" is an abstract type (see Section 5.4.5), it is possible as such to update, to delete it but it is not possible or to create an abstract type "Action", or to update the class of shares (eg: to change an action in a foreign action Switzerland). To create an action, it was necessary to attribute value as "DataObjectTypeName" ObjectDataSource to a type of concrete action (Ex: SMIAktie). This gives the impression that the ObjectDataSource will create a specific action such as SMI. Then, use the event "OnItemInserting", which is raised just before the action is inserted, to change the nature of the object to the type of action selected by the user. Figure 36 shows the implementation of the function of the event OnItemInserting.
Figure 36: The use of the event "OnItemInserting" Regarding the change of class action, LINQ does not allow to do so, it would have been possible to implement with a SQL command to the lowest level. This has not been considered necessary and it is therefore not possible for a user to change the category of an action once it has been created. The last delicate point in this report commented on the entities "Option" and "OpionDetails." As commented in Chapter 5.4.5, these two entities should form only if in LinQ to SQL allows. As things stand, the two are nevertheless linked by an association (see Figure 28: Diagram of entities). The ObjectDataSource Page "Option.aspx" has as unique attribute value "DataObjectTypeName" entity "Option", ie d. all the operations insert, update and delete as a parameter entity will "Option". Each of these operations, the function of the corresponding event will perform the same operations, from behind, also the entity "OptionDetails" option for a "full" (OptionDetails included) to be processed. The code for these functions are too large to be included in this report, it is in the functions "Inserting", "deleting" and "updating" the file Option.aspx.cs of Annex 9.4. 6.1.2 The "BLL" General structure As explained in Chapter 5.4.1, the layer of business logic was implemented as a C # library project. Files and folders make up this project are shown in Figure 37.
Figure 37: Folders and files that make up the project "BLL" Rérérences The BLL has references only to the object model contained within the projects "Entities" and "CommonObjects" and on the layer "DAL", according to a strict three-layer architecture (see 5.4.1). C # classes Two classes make up the project BLL: • BLLFacade.cs: contains all the business logic methods called by the presentation layer. The methods for updating, creation and deletion of entities are, among other party. It is implemented as a static class. • Comparison.cs: contains all the comparators required to implement the sorting in the presentation layer. As explained in Chapter 5.4.1, using the ObjectDataSource in our architecture forced the implementation of manual sorting. Some implementation details A peculiarity in the implementation of LAD is the existence of variables "currentSpiel" and "currentSpielVariante" discussed in 6.1.1.
6.1.3 The "LAD" General structure As explained in Chapter 5.4.1, the data access layer was implemented as a C # library project. Files and folders make up this project are shown in Figure 38.
Figure 38: Folders and files that make up the project "LAD" Rérérences The DAL has reference only to the object model contained within the projects "Entities" and "CommonObjects" according to a strict three-layer architecture (see 5.4.1). C # classes The DAL was implemented using, among others, the pattern "Facade". This design pattern allows you to hide a sub-system behind a single object. The latter has a single unified interface and is responsible for working with the components of the subsystem [Larman 2006]. DALFacade.cs file with its interface is subject IDALFacade.cs Facade and envelope and the subsystem consists of classes: • KategorienManager.cs: implements the subsystem responsible for functions relating to the entities "Kategorien" • PeriodenManager.cs: implements the subsystem responsible for functions relating to the entities "Period" • SpielerManager.cs: implements the subsystem responsible for functions relating to the entities "Spieler" • SpielManager.cs: implements the subsystem responsible for functions relating to the entities 'Spiel' • TitelManger.cs: implements the subsystem responsible for functions relating to the entities "Titel". Dal.xml The role of DAL.xml file and the operation of each component involved in the ORM process are explained in Chapter 5.4.5. The DALFacade reads the information about games from the file DAL.xml and for each game, it instantiates the entire list of Managers above. They are each connected to their DataContext, which provides them from the database, the entities of their respective game. The DALFacade also parse the file DAL.xml order to instantiate objects and BSUSpiel BSUSpielVariante classes contained in CommonObejcts (see section 6.1.5). Some implementation details The implementation of the DAL with LINQ to SQL illustrates how the latter is more appropriate for a development scenario RAD to create a three-layer architecture! The first obstacle lies in the updating of the entities in the database. In a first phase, the objects were created from the database and passed to the presentation layer as a list of objects. They have been detached from their DataContext (which they were not posted in a scenario RAD). The sample code in Figure 39 shows the function implemented in the DAL TitelManager to search all currencies. It recognizes the call to the DataContext to retrieve the table entities "Titel" and the LINQ query to retrieve only the securities of currencies. It is important to note that the query is executed inside the DAL and returns a list of objects according to the principle of a three-layer architecture.
Figure 39: the function implementation getAllDevisen () In a second step, an entity "Currency" has been changed in the presentation layer and the function of updating the DAL was called. During this call, the object was then detached from the DataContext. The problem is that LINQ to SQL will handle all the objects through the DataContext so that any changes made can be monitored and recorded later in the database [Strahl 2007]. Many different implementations of the function update were tested. The one that worked is illustrated in Figure 40. It implies that the entity to update or recreated from the database (and the entity shall be attached to the DataContext) and the values of the entity passed as parameter (which is detached from the DataContext) are updated one to one! This solution is clearly not optimal, it has nevertheless the advantage of some significant work! The last point documented in this report is the table of the database containing the periods of play (table 0x_Periode, "x" is the number of game). This is the only table whose IDs start at 0 and must be consecutive. When entries are deleted from the table, the database continues to increment the value of the following ID. LINQ to SQL does not allow you to reset the ID, it was necessary to use a lower-level function for SQL to guarantee that the ID can be reset. After each erase times, then reset the SQL ID to 0.
Figure 40: The implementation of the function update currency 6.1.4 The "Entities" General structure As explained in Chapter 5.4.1, the object model is used to pass information between layers. It is composed of projects "CommonObjects" and "Entities". Files and folders make up the project "Entities" are shown in Figure 41. The latter is implemented as a C # library project. Rérérences The object model does not refer to any other project. C # classes Entities_20081215.cs class contains the classes representing the information in the database. It was generated by the tool SqlMetal and LINQ to SQL designer. As a first step, the diagram entities (bsu_20081215.dbml file) was created from the database using SqlMetal. It was then modified in the designer to get the diagram entities in Figure 28. Based on the latter, created SqlMetal entities_20081215.cs class and mapping files (see Section 5.4.5).
Figure 41: Folders and files that make up the project "Entities" 6.1.5 The "CommonObjects" General structure The "CommonObjects" is part of the object model of the system. It is implemented as a C # library project. Files and folders make up this project are shown in Figure 41. Rérérences The object model does not refer to any other project. C # classes Classes are BsuSpielVariante BsuSpiel and games and game variants. DAL.xml of data are used to create their instances.
Figure 42: Folders and files that make up the project "CommonObjects"
6.2 Testing As discussed in Chapter 3.1, the RUP is based on use cases. The system tests are thus based on the description of the UC2 Set up the game, made in Chapter 4.3. Much of the tests were performed manually and implicitly throughout the project. To illustrate the approach, a test case for the main scenario of UC2 is described below. The results were compiled in the summary of test. 6.2.1 Introduction Tests inside the table are to be executed sequentially. The ID tests correspond to the numbers of the main timeline of the activities which they are attached. Only the tab for the PMS should be tested systematically. The tests are to achieve ave browsers FireFox version 3. and Explorer version 6. 6.2.2 Test Case Test ID Purpose Actions Expected Outcome (postings) 7 tables of the game will be emptied • In the "Empty Tables", click the "Empty Table" for both games contained in the variant of the game: • * The tables are empty • periods linked by foreign key in other tables ** are either null or the period with ID 0 • The message "the tables have been flushed with success" displayed The 14 periods are entered into the database • In the "Periods", select and deselect the days, weeks, months (from different months). • Click "save the dates" for both games contained in the variant of the game: • The new periods are periods in the table • They are displayed in the GridView to top • Fields and SpielBeginn Spielende Allgemein the table are updated • The DetailsView menu "General" shows the new fields beginning of the game and end game *: Empty tables are: Bank, BedingungManuell, Kurs, Member_Session, Mutation, Portfolio, Rangliste ** Periods used in the following tables: Allgemein, Titel, and Bedingung BedingungManuell
6.2.3 Summary of tests Tests with ID 7 and 14 have produced results in accordance with the test cases above. No errors were reported. In other tests done implicitly, it was observed that the display of JavaScript functions were not performed properly with Explorer. With FireFox, for against, no display problems were reported.
7 Summary and Conclusion Will the new interface is beneficial to a better configuration of the game? It is not enough to predict the action, we must also act to at least see the consequences for this prototype interface will be implemented and tested. This question will be answered through programming and successive tests. The transition of the new site configuration has already begun with the installation of software on the new server. The configuration of the next game could be done with the new program. Summary: Put the basic scientific questions: Conclusion: 1. My conclusions on developing characters: . NET Developer Standard is great for but there is sth others have! At first there was little blog. Net 3.5 layer archtecture now much There is no documentation of the program and the database to see which field matches what: bsp: the periods are the only field that start at 0. Important to know the business to know that if there are funds must also be taken dividend. Even to put the comment there are bugs! I had never done or LinQ or asp.net or a website alone. LinQ in 3 layers: as explained by MS says LinQ is for Rad and its new Framework for 3TIER. For the forced execution of the query with a ToList have to go for a record has the fields is difficult. LinQ to SQL is dead is better Entity Framework because it separates well between what is and LinqProvider ORMFramework! Difficulties because: BD is? Normal form: Relationship as said verwirrend Teuff between some fields of the bd. . LinQ is not suitable for the 3TIER, was lucky because in BD BSU has the only type of legacy that LINQ supports nämlich ... Despite that managed to make a site that automatically adjusts its just changing the conf file, when at the base site would just be for the PMS! It took a lot more programming in the code behind in order to programmatically add controls in the configuration file, but it has been worth it! ASP.net is very good! 2. My conclusions on Project Management with RUP. 3. My conclusions at all: This was because there was anspruchswoll finance, management proj, and programming the three have nothing to do but all connected by the fact that the BSU is to understand the 3. 4. SWOT analysis: As I did design science: S: easy to configure, faster W: more layers, making the architecture more complex for the new bsu (sth new to learn) O: Put the first step of a lifting of BSU T: that LinQ is no longer used, support for the Entity Framework will come in place, people do not update config site if they make changes to the game site become desu 7.1 Perspective: other possible improvements to the architecture BSU At this time, other parts of the arch BSU are again: the import and the basic program. To improve the site configuration, to 1. internationalization, 2. validators, 3. Concnurrency and handling errors 4. Do with EntityFramework 5. to the RBA (the conditions are included) 6. add a button to the options that are in the classic version are made in the derivative at the same time erase the old table. 7. Watch the compatibility of the Explorer with javascript
8 Bibliography Admiraal, H. (2007a) Difference between versions 6 and 7 ORs. Admiraal, H. (2007b) Pitfalls using UML in RUP. AG, S. S. (2008) SIX SIS AG. https://www.sec.sisclear.com/sec/cm/index.htm last accessed 24.09.08. Arefin, M. (2008) Difference between LINQ to SQL and the Entity Framework. http://dotnethitman.spaces.live.com/blog/cns!E149A8B1E1C25B14!195.entry last accessed 28/01/2009. Arnowitz, J., Arent, M. and Berger, N. (Hrsg.) (2007) Effective prototyping for software makers. The Morgan Kaufmann series in interactive technologies, Elsevier, Amsterdam. Bass, L., Clements, P. and Kazman, R. (Hrsg.) (2003) Software architecture in practice. SEI series in software engineering, Addison-Wesley, 2nd, etc. Boston. Booch, G., Rumbaugh, J. and Jacobson, I. (Hrsg.) (2000) The User's Guide: UML. Eyrolles, Paris. Brandon, D. Mr. and Brothers, C. (Hrsg.) (2006) Project management for modern information systems. IRM Press, Hershey. Brealey, R. A., Myers, S. C. and Lehman, PJ (Hrsg.) (2003) Principles of financial management. Pearson Education, 7th ed., Paris. BSU (2008) der Schweizer Universitäten Börsenspiel. www.unifr.ch / bsu last accessed 29.04.08. Budde, R. and Züllighoven, H. (1990) Prototyping revisited. Chris P. and Elizabeth K. (2002) In support of user interface design in the Rational Unified Process. IEEE Computer Society Press, p. 21-27. Corporation, M. (2008) LinqDataSource Web Server Control Overview. In MSDN Magazine. Corporation, M. (2009) ASP.NET MVC. http://www.asp.net/mvc/ last access 29.01.2009, Microsoft Corporation. Corporation, R. S. (1998) Best Practices for Software Development Teams. In Rational Software White Paper. DeutscheBörse (2008) iShares DAX (DE). http://www.boerse-frankfurt.de last accessed 02.10.08. Eck, C., Langer, M., & Riechert, M. (Hrsg.) (2006) Eurex Futures und Optionen. Finanzbuch Verlag. Eibl, H. (Hrsg.) (2008) ETFs Exchange Traded Funds. FinanzBuch Verlag, München. Esposito, D. (2007) LinqDataSource vs ObjectDataSource vs SqlDataSource. last access. Essigkrug, A. (2007) Rational Unified Process kompakt. Elsevier Spektrum Akad. Verl., 2. Aufl., Heidelberg Munich. Eurex (2008) Eurex. http://www.eurexchange.com/index.html last accessed 25.09.08. Exfeed, S. (2008) SIX Exfeed. http://www.exfeed.com/index.html last accessed 23.09.08. Flasko, E. (2008) Introducing LINQ to Relational Data. In MSDN Magazine, 01.2008. Fowler, M. and Rice, D. i. (Hrsg.) (2003) Patterns of Enterprise Application Architecture. The Addison Wesley Signature Series, Addison-Wesley, Boston etc.. Group, S. (2008) Medienmitteilung. http://www.six-group.com/media_releases/online/media_release_200809301104_de.pdf last accessed 30.09.08. Hesse, W. (2003) Dinosaur Meets Archaeopteryx? or: Is There An Alternative for Rational's Unified Process? In Software and Systems Modeling (SoSyM), Vol. 2 (4), p. 240-247. Hull, J. (Hrsg.) (2003) Options, futures & other derivatives. Prentice Hall finance series. Options / futures / derivatives, Prentice-Hall: Pearson Education International, 5th, Upper Saddle River, NJ. Husemann, S. (2007) Roadmap BSU. Fribourg. IBM (2008a) Rational Method Composer. http://www-01.ibm.com/software/awdtools/rmc/features/index.html?S_CMP=wspace last accessed 16.10.2008. IBM (2008b) Rational Unified Process. http://www-01.ibm.com/software/awdtools/rup/ last accessed 16.10.2008. Isakov, D. (2006) Evalution measures of performance. In Portfolio Management, University of Fribourg, Fribourg. Kruchten, P. (Hrsg.) (2001) The Rational Unified Process: an introduction. The Addison-Wesley object technology series, Addison-Wesley, 2nd, 5th print., Boston. Larman, C. (Hrsg.) (2006) Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development. Prentice Hall PTR, 3rd, 7th printing, Upper Saddle River, NJ Luqi, L. and Steigerwald, R. (1992) Rapid prototyping software. In System Sciences, 1992. Proceedings of the Twenty-Fifth Hawaii International Conference on, Vol. ii, p. 470-479 vol.2. Marguerie, F., Eichert, S. and WOOLEY, J. (2008) LinQ in Action. Manning, Manning, Greenwich. Metz, D. (Hrsg.) (2007) Devisenhandel. FinanzBuch Verlag, München. Mitchell, S. (2006) Tutorial 2: Creating a Business Logic Layer. In MSDN Magazine, 06.2006. Morley, C., Hugues, J. and Leblanc, B. (Hrsg.) (2006) UML 2 for the analysis of an information system: the specifications of the client. InfoPro. Management Information Systems, Wiley, 3rd ed., Paris. Mortensen, K., McGovern, R. and Liptaak, C. (2003) ASP.NET and Struts: Web Application Architectures. In MSDN Magazine, 12.2003. Muller, P.-A. (Hrsg.) (2000) Modeling with UML. Eyrolles, 7th edition 2000, Paris. Novello, P. (Hrsg.) (2007) Stock: Investors' Guide. P. Novello, 3rd ed., Updated and enlarged., Geneva. Oldby, N. K. E. and Dan, M. B. (2006) Application of a layered architecture design in ASP.NET 2.0 - and a Comparison between J2EE and. NET-IT University of Copenhagen (ITU) Copenhagen. OMG (2008) Catalog of OMG Modeling and Metadata Specifications. Catalog of OMG Modeling and Metadata Specifications last access. Pfleeger, S. L. (Hrsg.) (1998) Software engineering: theory and practice. Prentice Hall, Upper Saddle River, N.J. Pomberger, G. and Weinreich, R. (1994) The Role of Prototyping in Software Development. In the Conference on Technology of Object-Oriented Languages and Systems (TOOLS Europe '94), Prentice Hall, Versailles, France. Rajalekshmi (2008) Rational Unified Process (RUP). http://perpetuastudents.wordpress.com/2008/01/21/rational-unified-process-rup/ last accessed 16.10.2008. Ranaldo, A. (2007) Introduction to market microstructure University of Zurich. Riaan, K., Stefan, G. and Derrick, G. K. (2007) Assessment of a framework to compare software development methodologies. In Proceedings of the 2007 Annual Research Conference of the South African institute of Computer Scientists and information technologists on IT research in developing countries, ACM, Port Elizabeth, South Africa. RUP (2008) Concept: Prototypes. last accessed 16.10.2008. Schneider, F. (2008) BankingToday.ch. Verlag SKV, Zürich. Shehu, E. (2008) Analysis of an information system and extend it with new features. Department of Computer Science University of Fribourg, Fribourg. Shuja, A. K. and Krebs, J. (2008) IBM Rational Unified Process Reference and Certification Guide: Solution Designer. IBM Press, Upper Saddle River, N.J. Steiner, M. and Bruns, C. (Hrsg.) (2002) Wertpapiermanagement: Professional Wertpapieranalyse und Portfoliostrukturierung. Handelsblatt Bücher, Schäffer-Poeschel, 8., Überarb. und erw. Aufl., Stuttgart. Strahl, R. (2007) Attaching and LINQ to SQL Entities. http://www.west-wind.com/WebLog/posts/134095.aspx last accessed 01/02/2009. SWX (2008a) Financial Quote Service. http://fqs.swx.com/ last accessed 23.09.08. SWX (2008b) SWX. http://www.swx.com/index.html last accessed 23.09.08. Telekurs (2008) Telekurs. http://www.telekurs.com/fr/tkhoch_home.htm last accessed 24.09.08. UBS (2008) Glossary. www.ubs.ch last accessed 24.09.08. Walther, S. (2007) ASP.NET 3.5 Unleashed. Sams, Chicago. Wikipedia (2008) Options. http://fr.wikipedia.org/wiki/Option last accessed 01.10.08. Wood, D. P. and Kang, K. C. (1992) A Classification and Bibliography of Software Prototyping. Zant, R. F. (2005) Hands-on prototyping in system analysis and design. In Information Systems, Vol. VI (1). Zindel, S. (2008) The costs of trade may vary up to a hundredfold. In Balance Sheet (No.250), 21.05.2008.
9 Appendix 9.1 Installation Guide: The application was programmed on Windows XP, using Visual Studio 2008 and SQL Server 2005 Standard Edition. It was installed on Windows Server 2003 with IIS 6.0 and SQL Server 2005 Standard Edition. 9.1.1 Pre conditions: On the server: • Microsoft. NET Framework 3.5 • Operating Systems: Windows Server 2003, Windows Server 2008, Windows Vista or Windows XP • Web server IIS (Internet Information Services) • SQL Server Database On the development machine: • Visual Studio 2008 or Visual Web Developer 2008 • Operating Systems: Windows Server 2003, Windows Server 2008, Windows Vista or Windows XP The following components are included in Visual Studio 2008 and Visual Web Developer 2008: • Microsoft. NET Framework 3.5, • a web server (ASP.NET Development Server), • a database SQL Server.
9.1.2 Configuring the website DAL.xml To function properly, the site needs to know where the XML file that contains the configuration DAL.xml games and connection information to the database. To do this, open the solution that is in DAL.sln \ Projects \ DAL. In the file DALFacade.cs specify the property value ServerPath, as shown in Figure 39. Figure 43: Attribute ServerPath file DALFacade.cs
Warning: This is the path where the file DAL.xml on the server after publication. Here, the records of web server on C: \ \ Inetpub \ \ wwwroot total path is C: \ \ Inetpub \ \ wwwroot \ \ BSUConfiguration \ \ bin \ \. Recompile the DAL by going to the menu: Build Build DAL. Figure 40 shows the message that should appear in the output window below:
Figure 44: Message displayed in Visual Studio after a compilation réuissie
Then open the solution in BLL.sln \ Projects \ BLL and rebuild it as: Build Build BLL. Close the two open projects.
Connecting to the database To configure the connection to the database DAL.xml open the file located in \ Projects \ DAL \ DAL tag and indicate in the Connection, the atribut url, cf. Figure 41.
Figure 45: Beacon to connect to the database file DAL.xml Here the database is located on the server-sr-SVW 960.unifr.ch, it is called test, using the id bsu and has the password bsu. Save your changes and close the file.
Configuration sets The site configuration can have multiple games BSU games and variations of play everything is customizable through DAL.xml file located under \ Projects \ DAL \ DAL. Just tell him what games (Spiel) correspond to which variant of the game (variant) and enter the name, id and mapping of the games and the name and id variations of play Figure 42 is an example configuration for RBA games and PMS. Figure 46: Configuration of games and variations of games in the file DAL.xml The numbers of ids and mappings of sets correspond to the numbers of tables in the database, for example: play 01 matches at the tables 01_Allgemein, 01_Allgemein_Text, etc.. This game is linked to tables with mapping01.xml. The mapping files are located under \ Projects \ DAL \ DAL. To add more, please read "How to add extra games? ". Authentication of administrators User authentication on the web page can be configured through the Web.config file located under \ Projects \ BSUConfiguration \ BSUConfiguration. In the following screenshot, the login configuration with password bsu can be used to access the site.
Figure 47: Managing Users in Web.config 9.1.3 Installation Open the web project located in BSUConfiguration.sln Projects \ BSUConfiguration with Visual Studio. From the menu, go to Build Publish BSUConfiguration. This window appears:
Figure 48: Window web publishing Click on the icon with the three points and create a new folder called BSUConfiguration to the location you prefer (in this case, it is created on the desktop). Set other options as shown in the screenshot. Click Publish. Go to the created folder and copy on the server in the folder of the web server. Here, the file is copied to C: \ Inetpub \ wwwroot \. Start the Internet Information Services (IIS) Manager under All Programs Administrative Tools Internet Information Services (IIS) Manager. Create a new Application Pool: Right-click on the Application Pools folder New Application Pool ... A window like the one in Figure 45 should appear:
Figure 49: Window for creating an Application Pool Rename the ID. Here it is appointed AppPool asp.net3.5. Click OK.
Figure 50: Configuration Tabs website BSUConfiguration He must then tell the website to use this Application Pool: Right click the folder Web Sites Properties BSUConfiguration. Home Directory tab in the Application pool box, select the application pool you just created. Click OK. Then tab to the Web Site Connection timeout to 10,000 seconds. Click OK. Home Directory tab, click Settings, Options tab, set the ASP script timeout to 3600. Click OK. On the ASP.NET tab, click Edit Configuration ... under the Application tab set the Request execution timeout to 10,000. Click OK. On the ASP.NET tab, the ASP.NET version must be 2.0 (2.0.50727). Click OK.
9.2 Advanced Configuration of the site: 9.2.1 Changing the information windows The windows are made information to provide the administrator with enough to configure the game and it is therefore necessary to keep them current. Figure 47 shows an example of window information:
Figure 51: Window of Information for ISIN To change the text displayed in the windows of information, open the file that is under BSUConfiguration.sln \ Projects \ BSUConfiguration. In the file BSU.Master.cs texts are displayed in the windows of information. They are arranged by section: for example, Kategorie, Titel, AktienDetails, etc.. and number of columns in the GridView or number of rows in the DetailsView, starting with 0. To find out which section is to change, go to the file aspx.cs corresponding to the web page to edit. Look for the first parameter to the function of the class BSU getHelpText. This is the name of section. Section names ending with the word "Detail" correspond to sections of the DetailsView, the other match of the GridView. Example: page http://www-bsu.unifr.ch:8080/Aktien.aspx?Id=2 it would be desirable to change the text displayed for the field in the GridView ISIN. Follow these steps: • Open the file that is in Akien.aspx.cs BSUConfiguration.sln. • Search function BSU.getHelpText. As shown in Figure 48 and Figure 49, two results coincide: Figure 52: Bsu.getHepText seeks the corresponding text in Section Titel
Figure 53: BSU.getHelpText seeks the corresponding text in Section AktienDetail Titel section corresponds to the GridView securities, while the DetailsView is qu'AktienDetail action. As we want to change the text displayed in the third column of the GridView page Aktien.aspx, it will change the text corresponding to the section Titel and id 2 located in the file BSU.Master.cs. In Figure 50, it will then replace the text "<h4> ValorenNr </ h4> International Securities Id" with the selected text.
Figure 54: Relevant information in the file BSU.Master.cs After modification, please recompile the project: Build Build BSUConfiguration and reinstall it: see 9.1.3 Installation. 9.2.2 How to add extra games? To add a new variant game site configuration, simply create a new mapping point to the new tables and adjust the file DAL.xml. To do this, go to the folder on the server BSUConfiguration \ bin and copy a mapping file that you rename "mapping ** '** corresponding to the number of the game and the number of tables. For example, for a new variant game called "Neues Spiel" and correspondent for the game Classic with 07 tables and game tables 08 Derivative, copy twice a mapping file and rename the "mapping07.xml" and " mapping08.xml ", see Figure 51.
Figure 55: copy of the mapping files Open each of these two files and replace all tags in the attribute table with the name corresponding to the tables of these new games. Figure 52: shows an example with the name that will become bsu_01_Allgemein bsu_07_Allgemein for mapping07.xml and bsu_08_Allgemein for mapping08.xml.
Figure 56: Beacon to adapt to the file and mapping07.xml mapping08.xml
Figure 57: Tag after the change to the file mapping07.xml Repeat the replacement of 01 by 07 (08) for all the tags tables, save changes and close the files. Open the file located in DAL.xml BSUConfiguration \ bin and add the line of code in Figure 54: New variant of game "Neues Spiel" <Spielvarianten> between the tags.
Aucun commentaire:
Enregistrer un commentaire