Software Engineering Fundamentals
Internal Stock Trading System
Project Overview
You are required to analyse, design, implement and test an internal stock trading system for employees of a group of companies involved in manufacturing. In the initial stage you are required to develop a client server application (RMI or sockets) without web access; however as a software engineer you are required to design the systems allowing for extensibility, maintainability and reusability.
This project is a client server application and is therefore better suited to those who have already completed Further Programming or Network Programming.
All client queries must be directed to your product owner, your tutor in this project. You may also post general questions to the Canvas Discussion Board.
Requirements by Product Owner
I want a stock trading software for a group of companies where employees given bonus shares are allowed to trade their stocks. In the initial development phase the stock trading will run as a separate system (not linked to the employee benefit system).
The Stock Trading Server Functionality
The server should run continuously allowing new orders to be added and withdrawn until it is brought down at the end of the day. Only six stocks belonging to the group are currently traded (see below). The server must initially start with the following stock prices. The stock prices will vary as trades are completed. Server must reject buy/sell orders that are not within ± 5 cents of the last trade, or are less than 5 cents.
OSX (250)
Ria (340)
NIBC (290)
Vienta (170)
BHT (260)
Cones (470)
Separate queues must be created for items waiting to be sold or bought at different prices.
· Server must verify and only accept buy/sell orders which are within +/- 5 cents of the last trade, down to a minimum of 5 cents. If a buy/sell order is valid, a transaction ID (newly generated) must be assigned (of the form TR080428000001) and client must be notified.
· Newly ordered items can be traded immediately if there are offers from ready buyers or sellers in the queue with the required quantity of stock and within specified price. If only part of the offer can be traded now, an offer with the remaining quantity must be added to the buy/sell priority queue. For example, if for a new sell order of 5000 BHT shares at 250 cents, only 1000 shares can be traded at that price (or higher) now, the remaining quantity is 4000.
· Buy or sell orders queued at the same price, must be traded on a first come first served basis. However if the prices are not the same, the queues offering the highest possible price must be traded first when selling, and lowest possible price when buying.
· The maximum number of shares must be traded whenever an item is offered. Partial trades must be conducted if only partial match can be found for an offer. A trade affects both the client making a new offer and the clients with offers in the queue. All affected clients must be notified of the result of trade. Note a trade may cause offers waiting in the queue to be removed or the remaining quantity to be updated. Two different cases are given below, applicable when a new buy offer is made. (Similar cases apply for sell offers). It is assumed that offers for sell queues are arranged with higher priority for lower price as lower priced offers will be traded first with a potential buyer. Similarly, buy queues are arranged with higher priority for higher prices as higher priced offers will be traded first with a potential seller.
Example 1:
Assume only two offers are queuing to sell BHT shares, first one (from client A) for 1000 shares at 270 and the second (from client B) one for 1000 shares at 280. At this stage, if another client (client C) offers to buy 1500 BHT shares at 290, the offer at 270 (from client A) must be removed from the sell queue, and the quantity for the one queuing at 280 (from client B) must be reduced to 500 (resulting in two trades). Also, buyer (client C) gets a trade done with all 1500 shares he/she offered to buy. All three clients (A, B, and C) must be notified of the trade and their trade details must be saved.
Example 2:
Assume only three offers are queuing to sell BHT shares, first one (Client A)for 1000 shares at 270, second one (client B) for 1000 shares at 280, and third one (client C) for 1000 shares at 295. At this stage if a client (client D) offers to buy 2500 BHT shares at 290, the offers at 270 and 280 (client A and B) must be removed from the sell queue (resulting in two trades) but the offer queuing at 295 (client C) must be left intact as this price is higher than what the buyer is willing to pay. As the buyer (client D) gets only a partial trade done, with 2000 shares, an offer for the remaining quantity, 500 BHT shares at 290 must be placed in the buy queue. All three affected clients (A, B and
D) must be notified of the trade and their trade details must be saved.
Registration
Before clients are allowed to buy and sell shares, a registration process must be completed passing username and password.
Server must validate the following:
· Username must be unique.
· Username and password must have at least 8 characters.
If registration is successful, server must generate a unique account-ID and notify the client. All subsequent transactions including buying, selling withdrawing and viewing must pass valid username and password. Account-ID should be used for all orders and transactions (i.e. database records should be associated with account-IDs rather than usernames).
Viewing Stock Prices
I need a view option that allow clients to view the following using appropriate GUI
· Current Stock price (based on last trade)
· Current buy/sell orders queued by this customer
The second option must show stock code, remaining quantity, desired price and current price (last traded price).
Buy/Sell Options
You must provide options for placing buy and sell orders for any of the shares currently traded at specified price. The share price offered must be quoted in cents, in steps of 1 cent. Maximum number of shares purchased in one trade must be limited to 10,000. The server is required to validate the data sent. If the server detects any anomaly and throws an exception, it must be caught and displayed, otherwise the transaction ID generated and returned by the server must be displayed (which may be required for future transactions).
When an order is placed the client must be notified of the quantity bought/sold and the quantity being queued. If a queued item is bought/sold at a later time the server must notify all clients affected by the trade using callbacks. A good user interface must alert clients when a queued item is traded (using UI elements such as pop-up).
Withdraw Order
This option must allow clients to withdraw all remaining unsold stocks in any buy/sell orders made earlier, by quoting the transaction ID for the order.
PROJECT OPTION 7: Page 3 /3
Monitoring Unusual Patterns
System should send notification to management when unusual buy or sell activities are noted possibly indicating some insider trading. The system should allow unusual activities and thresholds to be defined dynamically through the interface.
Transaction History
Auditors and clients must be allowed query all transactions completed between specific dates by specific clients. The server must access the completed trades to access the required information.
Sever Shutdown
When the server is brought down all queued items must be discarded.
Persistence
All trades done must be persisted. The data may be stored as flat files, serialized files or in databases.
Bonus Mark: Chart Option for Premium Clients
This option offered only to premium clients must allow users to view the specified stock price movement in the last 30 minutes using appropriate graphs. These graphs must be dynamically updated. The stock price data stored must be restricted to last 30 minutes. You must also do the necessary scaling to fit the graph.
2.88
13:45
…
13:15
2.70
Design Documents
Detailed design documents are needed including class, use case, sequence, activity and state diagrams. In the initial stages the UML diagram in sketch mode should be shown to the product owner (tutor). Scenario modelling and storyboarding should also be shown to the product owner before detailed design and implementation commences.
Teamwork
Teamwork marks will be based on your group and individual contribution during the feedback sessions and your contribution to Trello. Your team contribution will be reflected based on how well your individual contribution through individual design diagrams (such as use case textual descriptions, sequence diagrams and JUnit test cases) are consistent with the overall design and implementation and testing goals. In the final face-to-face marking you will be required to fill a peer review form, which will help determine your group contribution. If your team is using Git your contribution also will be taken into account when determining your group marks.
Marking Criteria
1. Milestones 1 and 2 (10 marks)
A. Milestone 1 (5 marks) in Week 7
This first demo/presentation will award marks for both group and individual work. Each individual member is expected to undertake at least two major tasks or responsibilities. Some of these responsibilities can be shared. For example, in the chess-like game show all valid move destinations for a piece can be a user- story/responsibility that must be shared by the Piece and the Board classes. The subclasses of Piece such as Rook and Knight may know valid moves but only the Board class knows where the vacant and opponent squares are located. In such a situation, those members writing the Rook and Knight classes may override the method getAllValidMoves():Squares[], while the person developing the Board class may write a method to check which of these squares are free to move using IsValidDestination(square). These two methods from different classes may thus be combined to determine all valid destinations. Students can defer non-model (GUI) aspects until the core- logic is fully tested (by using a simple textual interface).
Activity
Marks
Group Part
Presenting the Initial Release Backlog (design documents: Class and Use Case diagrams) and demonstrating a partially completed product.
2 marks
(4 mins)
Individual Part
Individual member is expected to explain his or her role/obligation towards carrying out the main user-stories/responsibilities, and any challenges faced.
3 marks
(4 x 1.5 mins)
B. Milestone 2 (5 marks) in Week 12
The second demo/presentation will award marks for both group and individual work though more marks is awarded for group work.
Activity
Marks
Group Part
Presenting the Final Release Backlog and demonstrating the final product
2 marks
(3 mins)
Use a class diagram to present the overall design; use two sequence-
diagrams to present the core functionality. Explain the design rationale highlighting usability, maintainability, extensibility etc.
2 marks
(3 mins)
Individual Part
Individual members explaining their role/ contribution and any challenges
1 mark
(4 x 1 min)
( PROJECT OVERVIEW IV )
2. Face to Face Tutor Marking 1 & 2 (Total 25 marks)
Face to face marking is designed to give feedback and to award marks for following processes, using industry tools, flexible designs and the use of standard modelling notations.
A. Initial Face to Face Demo and Marking (Total 5 marks) in Week 9
Activity: Group Part
2 Marks
Model a positive and a negative scenario for 4 main use cases/user stories. You may use the storyboarding technique/screenshots to show the sequence of interactions (1 mark). Design classes/methods that can collaborate to carry out the 4 main user stories/use cases. Your initial class diagram should be extended to show more details of methods (1 mark).
2 marks
(6 mins)
Activity: Individual Part
3 Marks
Each team member has to write two positive and two negative JUnit test cases (exceptions must be thrown for negative ones) for a significant method in an important domain class they are assigned (2 marks).
Each individual student has to explain how these tests help implement the different scenarios identified in the group part. (1 mark)
3 marks
(2 mins each)
No submission required but students are expected to bring their documents (storyboarding, scenarios, class diagrams) and execute the test cases developed by each individual student.
B. Final Face to Face Marking (Total 20 marks) Submit in week 12 and Demoed in week 13
Group effort will be measured through overall class and use-case diagrams, which should explain the overall requirements and design decisions. Each individual member is expected to demonstrate their individual contribution by detailing their part of the use-case (a use case textual description) and class- diagrams and by coming up with two other UML diagrams (a sequence diagram and one of state/activity/object diagrams). Tutors will check your diagrams are aligned with your code and how group diagrams such as class and use case diagrams are aligned with individual diagrams (sequence and state). Include a table giving contribution of each member, allowing group mark to be adjusted.
Activity: Group Part
10 Marks
Overall Class Diagram (group)
The class diagram must show all the methods, attributes, associations and multiplicities. Name the associations wherever possible.
Up to 2 marks for valid class diagram that captures all the main classes, associations (with naming) with the correct multiplicities. Standard UML notation expected.
The remaining 1 mark is allocated for consistency with individual sequence diagrams (update the class diagram to reflect the final sequence diagrams).
3 marks
Overall Use Case Diagram (group)
Up to 2 marks for a valid Use Case diagram capturing all individual use cases. For the remaining 1 mark show all the relationships including extends/includes.
3 marks
Group Evaluation (max 1 page report) including:
Lessons learnt about project/process management (2 marks)
Strengths and weaknesses of your system in terms of reusability, extensibility, maintainability and usability (2 marks).
4 marks
Activity: Individual Part
Total 10 marks
Show detailed methods/attributes/associations relating to individual contribution in the class diagram
2 marks
Show detailed explanation relating to individual contribution in use case diagrams present one use case textual description for a significant use case.
2 marks
Sequence Diagram (individual)
2 marks
One of state/activity/object diagram
2 marks
Code explanation by individuals. The code must be refactored and reflect the design.
2 marks
Submission Details: 29th May 2020 4.30 pm (week 12). No late submission allowed.
Final Submission (Week 12):
All source code and diagrams must be bound together and be submitted as a zip file called FinalSubmission.zip through Canvas by Friday 11.59 Week 12 (29th May).
In additional all the design diagrams must be bound and submitted to the Sessional Staff office (14.09.13) by
4.30 pm on the last day of the semester (29th May).
Assignments: Summary, Rationale and Common Aspects
These assignments are designed to facilitate an agile or test driven approach for the first milestone, and a more rigorous design and implementation for the second milestone using UML notation and design/code refactoring. We have tried hard to come up with interesting and varied projects to match your interests and backgrounds. Your team should consider the strengths and interests of your members when selecting the project. You may also want to do some reading, testing and feasibility studies before finalizing your assignment selection in week 3. The first milestone is designed to enable students to develop some working- software or a prototype as soon as possible and get some feedback during the class presentation in week 7. The second milestone will focus more on the design aspects including extensibility and maintainability of the software. In addition face-to-face feedback will be given to each team in private in weeks 9 and 13.
Applied Sciences
Architecture and Design
Biology
Business & Finance
Chemistry
Computer Science
Geography
Geology
Education
Engineering
English
Environmental science
Spanish
Government
History
Human Resource Management
Information Systems
Law
Literature
Mathematics
Nursing
Physics
Political Science
Psychology
Reading
Science
Social Science
Liberty University
New Hampshire University
Strayer University
University Of Phoenix
Walden University
Home
Homework Answers
Blog
Archive
Tags
Reviews
Contact
twitterfacebook
Copyright © 2022 SweetStudy.com