Reference no: EM132738281

SOFT40051 Advanced Software Engineering - Nottingham Trent University

Aim

The aim of the Module's portfolio assignment is to demonstrate the knowledge gained during the module in understanding BOTH object-oriented analysis and design (OOAD), and object- oriented programming (OOP) using C++.

In this assignment task, you are required to produce a working program in C++, a design overview based on a reversed engineered class and sequence diagram, and a structured report describing the testing and evaluation of the program and its design. The System Specification for the C++ program is given below in Section B ‘C++ Assessment Scenario/Problem'. The Design Specification is given below in Section C ‘Design Specification'. The Report Specification is given below in Section D ‘Report Specification'. A short summary is given below.

B. C++ Assessment Scenario/Problem
Requirements Specification for a Simple Banking Transaction Data Structure and Management Tool
A system (to be developed as a program written in C++ and using the command line for output) is required that allows the user to create and edit a list containing a number of initially unordered Banking Transaction objects. The Banking Transaction objects represent various types of currency withdrawals by debit card, cashpoint machine, direct debit, and deposits by transfer, creditpoint machine and interest payment. The Banking Transaction objects will be entered by the user and stored in a linked list (consisting of a List class and a Link class, which must be adapted from those used in lecture 8 and lab 8, or lecture 11 and lab 11).

The Banking Transaction objects will have a Transaction base class that has the derived classes: Debit, Cashpoint, DirectDebit, Transfer, Creditpoint and Interest.

Transaction will be an abstract class and its subclasses will be concrete classes.

All Transaction derived classes will have a type, date, time and amount (in pounds and pence). In addition:

• Class Debit will have attributes to store the card number used, retailer name, retailer location, authorisation method (online, phone, mail order).
• Class Cashpoint will have attributes to store the location id of the cashpoint machine, and the card used.
• Class DirectDebit will have an attribute to store a reference.
• Class Transfer will have attributes to store the account number and bank sort code from where the transfer originated.
• Class Creditpoint will have an attribute to store the type of payment (cheque or cash).
• Class Interest will have an attribute to store the type of interest (daily, monthly or annual).

The user will be able to set the attributes of the Banking Transaction objects only when they are created and not after addition to the link list. The type of Banking Transaction should not need to be stored as a class attribute to record what the type of derived class is (e.g. typeid can be used to identify the type of derived class), but the program will need to be store the type in the file output.

The user interface will be a menu having the following options:

Q - Quit: The program should end without saving the Banking Transaction objects.
I - Insert an object: The user should be prompted to enter a Banking Transaction object type and its attributes, and place the Banking Transaction object at the top (start) of the linked list.
D - Delete an object: The Banking Transaction object at the top of the linked list is deleted. C - Contents of the list: Display a list of all the Banking Transaction objects, their type and their attributes.
U - Contents of the upper objects: Display a list of the first ten Banking Transaction objects, their type and their attributes.
S - Save to file: Ask the user for a filename and append (add to the end of the file) all the Banking Transaction objects, from the linked list, and their attributes in that file. The same text format should be used in this file as in the supplied test file TestData.txt (see below).
L - Load from file: Ask the user for a filename and load the Banking Transaction objects and their attributes from that file into the program's linked list. The Banking Transaction objects are added to those already in the program's linked list. The file saved in ‘S' should be able to be loaded in ‘L'.

N - Linear Search: Perform a linear search through the link list to find all Banking Transaction objects with a specified date (i.e. any time on that date) and display its attribute values. The linear search algorithm used should be from lecture 11 and lab 11.
T - Sort: Sort the Linked List so that the date attribute of each Banking Transaction object is decreasing (getting further back in time) from the top of the link list. The sort algorithm used should be from lecture 11 and lab 11.

After completion of each choice, other than Quit, the system waits for the user to press a key to return to the menu again.

Your report section ‘Evaluation of the program' (see below) should include an evaluation of the speed of the linear search and sort operations on the supplied data file ‘TestData.txt' for either: Stage 1 the linked list; or Stage 2 the linked list compared with the STL stack.

An interface will be required to perform the functionality above. Clarity of instructions to the user and simplicity should be considered in the interface design.

Additional Program Design Requirements Specification

1. There will be base class named Transaction and derived classes as specified above.
2. The program will use a class TransactionList that has a linked list as an attribute. The linked list should contain pointers to the base class Transaction objects but be able to store all types of Banking Transaction objects. Dynamic memory for the objects will be allocated/deallocated with C++ ‘new' and ‘delete'.
3. The linked list will have a List class and a Link class, which should be adapted from those used in lecture 8 and lab 8 or lecture 11 and lab 11.
4. The main function should have a minimal amount of code.
5. A file created by you containing at least one of each type of Banking Transaction objects should be submitted with the code (MyTest.txt). This file should be associated with your test plan and enable testing of all the user functions completed.
6. A file of 1000 transactions will be supplied with this specification (TestData.txt). This is to test the performance of the link list searches and sorting by recording the time taken for doing: a linear search on the original TestData.txt data; a sort on the original TestData.txt data.
7. Code given in the lectures should be used to perform the algorithms for linear search and sort, and the timer function.

Requirements Specification - Optional Task
Additional marks to improve your grade can be attained by incorporating a design pattern in your code for an extra optional task. After completing the requirements above, which uses a Link List data structure, you can optionally adapt your program to complete the following additional task.

The system will allow the user to choose between two data structures to store the Banking Transaction objects:

• a linked list (consisting of a List class and a Link class, which must be adapted from those used in lecture 8 and lab 8, or lecture 11 and lab 11).

Both are last-in, first-out (LIFO) list data structures. The aim of including two data structures is to compare the speed of running searches on each data structure.

The program should have the same functionality and requirements as for the Link List data structure. The program should allow the user to switch between the two data structures at run-time with minimal change of the code structure. To achieve this an Abstract Factory design pattern (see reference below) is required to be used in the code structure. The product will be the data structure. Functions using the data structure should be written to make use of the abstract factory and its abstract product.

C. Design Specification
Specification for the design of the Engine Inspection System
You are required to reverse engineer your final program code to produce a class diagram. The reverse engineering is to be performed using IBM Rational Software Architect. The class diagram will therefore show all of the classes used in your submitted program code. The classes will include the attributes, operations and associations.

Once the class diagram has been created using IBM Rational Software Architect, you are required to create one main sequence diagram for the use case: ‘I - Insert an object'. The sequence diagram is to be created by following the program code corresponding to the use case ‘I - Insert an object' from user choice to the addition of an object to the Link. Messages should correspond to each operation in the code and object lifelines for each class object used during the code.

D. Report Specification
The report about the testing and evaluation of your program and program design should start with a title, your student id, module name and id, and contain the following three sections:

Test Plan and Results
This section should contain: a series of tests and expected outcomes; the results of running these tests. The tests should relate to the list of function requirements in Section B.

Evaluation of the Program

This section, which should be no longer than one page, should state the strengths and weaknesses of your program and program design. This should include an evaluation of the test results. This should also include an evaluation of the speed of the linear search and sort operations on the supplied data file ‘TestData.txt' for either: Stage 1 the linked list; or Stage 2 the linked list compared with the STL stack.

Attachment:- Advanced Software Engineering.rar