Reference no: EM132391874
Relationship to Module Learning Outcomes
1. Perform a methodical analysis and design of a block-structured, engineering programming problem consistent with the conventions of the UML.
This assignment exercises methodical analysis and design using UML activity diagrams applied to an electrical engineering problem. Students may also employ pseudo-code.
2. Identify objects and classes and their relationships in simple object-oriented engineering problems and represent them using the conventions of the UML.
This assignment requires the use of classes and objects in the C++ code. It also requires the use of the UML class diagram.
3. Use an integrated development environment to create, compile, build and execute programs.
This assignment employs the Visual Studio IDE to create, compile, build and execute the specified program.
4. Implement a console application in a block structured compatible programming language.
This assignment requires a console application to be written using C++; a language which supports block structured programming. The assignment also introduces arrays and exercises further object- oriented concepts.
Individual Assignment Task - Financial Charting Program
A C++ console program is required to chart and analyse the historical price data for a financial market. After analysing the market price data and calculating the output, the program should plot the corresponding candlestick chart first, with a volume bar-chart underneath and a financial indicator of your choice underneath that (e.g. Simple Moving Average (SMA), Weighted or Exponential Moving Average (EMA), Moving Average Convergence/Divergence (MACD), Relative Strength Index (RSI), Mayer Multiple - Price divided by Moving Average, other well-known financial indicator, etc.).
The program should read in the historical input data from a Comma Separated Value (.csv) plain text file. The input file will usually contain 3 months' worth of data points (about 90 days), but ideally your program will be able to cope with varying amounts of input data or invalid file formats.
Finally, the program should give the user the option of outputting the financial plots to a separate plain text file (.txt) and an option to re-run the program with a new input filename,
Figure 1 (attached) shows the exact format the input file data will be in. Be very careful to note where the commas appear to separate the columns. Note that with the first column for 'Date' a comma appears in the middle of the data itself and this should be part of the read data - not a new column.
You can find an example input file download along with this coursework task sheet on Moodle. Each student should work individually on this coursework. In support of this, each student should solve the problem for a different financial indicator of choice or with significant changes to the calculation, output and implementation. Any cases of collusion, as in similar source code submissions, will be forwarded to Academic Conduct in the normal process.
Figure 2 (attached) shows an example of a fully-featured browser-based charting system. We will not be building something this complex, but hopefully it helps to illustrate our programming task.
The first chart is called a candlestick chart, which shows the daily price action.
The second chart shows the volume of orders completed on that day as a bargraph.
The third chart shows two simple moving averages calculated from the price data, one MA is over a 9-day period and the other MA is over an 18-day period.
Finally, the fourth chart shows the Relative Strength Index (RSI) calculated from the price data.
Figure 3 illustrates how candlesticks are drawn according to market price data over a specific timeframe (e.g. daily). There are 4 parts to a candlestick: Open, High, Low and Close price. When the Close price is greater-than Open price then this is referred to as a Bullish candlestick. When the Close price is less-than the Open price then this is referred to as a Bearish candlestick. ASCII art should be used to draw the candlestick chart for the console program. There is some flexibility in how to do this, but Figure 4 is given as an example of what your console program might look like when running.
The ASCII art candlestick chart could be plotted in a in a vertical instead of horizontal manner if you choose to.
The solid body of the candlesticks can be represented using the extended ASCII characters, e.g. char(176), char(177), char(178), char(219) to represent the green and red bodies of bullish and bearish candles. The axis can be drawn also using the extended ASCII characters, e.g. char(192), char(194) and char(196).
After plotting to the console, your program should prompt the user if they want to save the plot to a text file of their choice.
Finally, your program should have a re-run option at the end to allow the user to repeat the whole program and select another input file as required. Figure 4 is given as a starting point in your analysis of the problem and shows an example of what your program should look like when running.
Before writing the program, a methodical analysis and design must be completed including:
1. UML activity diagram at high-level to show an overview of the interaction between the user and the program (use swimlanes to show the user and system interaction).
2. UML activity diagram at low-level to show the details of how to "calculate the axis values for the candlestick chart".
3. UML activity diagram at low-level to show the details of how to "plot a row of the candlestick chart to the console".
4. UML class diagram to show the class design, attributes, methods, and any class relationships.
After writing your program you must create a screencast video clip, max. 3 minutes in length, where you demonstrate your program running and briefly go through and explain which features you have implemented successfully. You do not need to explain your source code in the screencast.
For a pass your UML, program and video should meet and demonstrate the following requirements to a suitable standard:
1. All UML diagrams are completed.
2. The program builds and runs without errors.
3. The basic program functionality is achieved using at least a single object of a single user defined class (e.g. Candlestick).
4. The program output is a close match to the console diagram and displays your name and SID clearly at the top.
5. A plain text CSV filename can be entered by the user at runtime and the data inside the file can be read and analysed successfully.
6. The output answer is calculated correctly for any given input CSV text file (in the correct format) and the corresponding plot is accurate.
7. A plain text filename can be entered by the user at runtime and the output charts can be saved in the plain text file.
8. The program can be re-run multiple times without errors.
9. Neatly written program code with consideration to the use of tabbing, suitable naming conventions, structured appropriately, use of private attributes and public methods.
For a first your UML, program and video demonstration should additionally meet the following requirements to a high standard:
1. Output from the program is fully formatted and correct; making use of the <iomanip>.
2. Fully implements all the features, correct calculations for axis increments, handles differing input data, implements some of the more advanced financial charts e.g. RSI or MACD etc.
3. Good use of arrays or library data structures (e.g. std::vector) for storing the data before calculating and plotting. May use a vector of objects.
4. Use of multiple user defined classes or types. Data is passed between objects as appropriateand the class diagram displays the correct relationships.
5. Efficient code design, code reuse being used instead of repeating code.
6. Good use of C++ standard libraries e.g. cmath, fstream, string, stringstream, vector, limits, algorithm, etc.
7. More thorough use of error checking on input from keyboard and from input files, e.g. incorrectly formatted inputs, etc.
8. Appropriate use of references and/or pointers such as 'passing by reference'.
9. Passing objects between functions/methods.
10. An attempt at proper code documentation, no linting errors under static code analysis, and good practices being used e.g. private attributes, meaningful identifiers, verb or verb phrases for functions and methods, nouns for class names and variable identifiers.
Attachment:- Assignment File.rar