CAB302编程写作、辅导Java语言编程

” CAB302编程写作、辅导Java语言编程CAB302 Major Project: Electronic Asset Trading PlatformMajor Project:Electronic Asset Trading PlatformCAB302 Semester 1, 2021Date due: 06/06/21 (Sunday, Week 13)Weighting: 60% (50% group, 10% individual)Specification version: 1.0OverviewThe unnamed client corporation has contracted your team of developers to create a client-serversystem for electronic trading of virtual assets within their organisation. Included in this documentare a description of the project from the Corporation (Appendix A), as well as a collection of userstories from project stakeholders (Appendix B).Your teams task is to gather requirements from the project description and user stories. Your teammust produce a detailed design of the system you intend to construct to meet these requirements.You must then create an implementation of the system in the Java programming language, alongwith a comprehensive unit testing suite. Finally, you will need to demonstrate this system to theclient, showing how you have met their requirements. Due to the international nature of our clientand the present situation with COVID-19, this demonstration will need to be recorded in the form ofa video. The client also wants individual videos from members of your team, detailing theirindividual contributions.These are not sequential steps, and it is expected you will revisit earlier steps as you develop theproject and learn more about what you are creating.In addition to your code and the reports described previously, the client also insists on having accessto the full revision history of your project. This means that, from the start, your projects workingdirectory needs to be hosted in a Git repository and you need to be regularly creating commits withuseful commit messages. This will also help your team to collaborate with each other. (Note that, ifyou have a copy of your repository hosted by a provider like GitHub or BitBucket, make sure thatyour project is private to ensure that your code is safe from other competing teams who might tryto pass off your hard work as their own.)The client will naturally want to be updated at various points during the projects development andyou will be required to submit videos for that purpose as well.CAB302 Major Project: Electronic Asset Trading Platform2Project StagesRequirements (5%)For this part of the project you must create a requirements document, which simply consists of a listof the clients requirements, for use when creating your detailed design. This may be a separatedocument or part of your main report (along with the detailed design.)You will find the clients requirements in Appendix A (Project description) and Appendix B (Userstories) of this specification. If you require clarification as to the clients requirements, send email tocab302@qut.edu.au before you do so, however, check the Responses to Client Inquiries folderon Blackboard (under Assessment – Major Project) to see if your question has already beenanswered.We have no specific requirements for how this document needs to be formatted- simply that itcontains a list of requirements and their priorities (e.g. must have, should have, nice to have) andthat those requirements are sensibly grouped (e.g. by priority.) You can also include e.g. very basicuser interface mockups if those help to describe the design for the project. The main thing is thatthis document needs to contain all the information needed by a project team to implement theproject the client wants without needing to go back to the information in Appendices A and B. Inother words, you need to synthesise all relevant facts contained within those appendices into yourrequirements document.You can search the web for product Requirements document to get ideas for possible structuresfor this document, but you are not required to follow any of them.Expected length: 2-4 pages.Detailed Design (10%)Your team needs to create a detailed design document that takes the project requirements fromyour requirements document and describes, in detail, the components needed to create thesoftware you have been tasked with developing.As with the requirements document, there is no specific format required. However, it is expectedthat your document will contain at least the following: Designs of the (public) Java classes that will comprise your programs:o Descriptions of all public methods and fields.o Descriptions of the arguments each method takes and what the method returns.o Any assumptions (preconditions and postconditions).o Any checked exceptions that may be thrown by the method, and the circumstancesunder which the exceptions will be thrown.You may find it useful to use the JavaDoc tool to generate these descriptions from /**-style comments in your source code. This will make it easier to keep the designdocument up to date with the source code. You are permitted to submit your JavaDocseparately and to reference it from your detailed design document.It may be a good idea at this stage to create your project in your Java IDE and startcreating these classes and methods. Do not create the actual implementations yet (justmake all the methods return e.g. 0 or null), but just creating the classes and methodsCAB302 Major Project: Electronic Asset Trading Platform3will allow you to start creating JavaDoc-style /** comments, which you can use as partof your design process. How these classes interact with each other (e.g. which classes call which other classes, whichclasses are passed as arguments to the method calls of other classes.)o You may find it useful to create a class diagram to document this, but this is notrequired. Search for UML class diagram to see popular examples of this.Note that not every public Java class needs to be documented here- just the onesthat are responsible for the internal work that needs to be carried out, andtherefore the classes that would be tested via unit tests. Examples of classes thatyou do not need to include here are: Test classes Exceptions GUI forms Designs of the forms that make up the clients graphical user interface, and how these formsare interconnected.o These can be e.g., scanned/photographed sketches, but I would suggest usingdrawing tools to create respectable looking user interface mockups.o If you created the server as a GUI program, you should also include designs for theservers GUI forms. The design of the database schemao Tables and table columns (column names and data types)o How those tables are connected (primary keys and foreign keys)You may find it useful to use Object-Role Modelling to present this information, butit is not necessary. The design of the network protocol used by the client and server to exchange information.o A description of the data that is sent from client to server or from server to client,and how that data should be interpreted.o Basically, this part should contain All the information required to create a compatibleserver or client that could be used to replace the server or client that your teamcreates.Like every other step, it is not expected that you will create this in one go. You will end up refiningthis document over the course of the project as things change and you learn more about thesoftware you are creating. Make sure it is kept up to date.You can search the web for software design document to see examples of detailed designdocuments for software projects, but once again, you are not required to follow any particularstructure for this document.The principal litmus test by which you should judge this document is if a skilled team would be ableto take it and produce the software (by creating the classes described within the design anddeveloping their implementations) without needing to go back to the requirements document.Expected length: 6-12 pages, or longer if your detailed class description is included in the pagecount.CAB302 Major Project: Electronic Asset Trading Platform4Unit Testing (10%)For this part of the project, your team will need to take your detailed design document and use theinformation inside it to prepare JUnit 5 unit tests for each of the classes described within.Initially this will be black box unit tests, created before your team has developed theimplementations for these classes. These unit tests should check that the classes follow theirspecifications as described in the detailed design document.Remember to create unit tests for: Normal cases Boundary cases (for each equivalence class) Exceptional casesAs a general rule, every behaviour described in the specification for that class should be tested for.After implementation, your team must then come back to this section and create glass box unittests. This time the goal is to complement your black box tests with tests that attempt to achieve fullcode coverage. (You can use IntelliJ IDEA to evaluate code coverage of your unit tests using Runwith Coverage.) You want to create tests that are deliberately designed to cover as much code aspossible.As with the other stages, your unit tests are not expected to remain static. Changes to requirementsand design will result in you needing to modify your unit tests or create new ones.Some classes, particularly those that deal with external resources (database, network) may need tobe mocked for them to be tested. Creating mock classes is part of your unit testing stage, and thesedo not need to be documented in your detailed design.Remember the mantra of Test-Driven development: red, green, refactor!Implementation (10%)In this stage your team needs to actually Create the software requested by the client. Ideally yourdevelopment should be agile, and you should reach this stage early on, getting something very basicworking from the beginning. It is not necessary or desirable to develop the entire project at once.Get something very simple working, then expand on it. Implement classes that you have unit tests for. Follow the Test-Driven Developmentapproach and write very basic implementations designed to pass the unit tests, thenrefactor them to remove duplication and improve the quality of the code. Implement classes that you dont have unit tests for. These include the non-mock versions ofthe mock classes you created during the unit testing stage (classes designed to interfacewith a database or network connection), exception classes, GUI forms and so forth.Remember that you are creating two applications (a client program and a server program.) Wesuggest creating just one project (remember that each class can have its own main() method), butdividing your code up into multiple packages to reflect the application that uses each. For example,you might have a client package, a server package, as well, as a common package containingclasses that are used by both.Your team must make use of Java and the JDK (any version, but we will test with 15), which has allthe functionality you need for completing this project. Use of external Java frameworks (e.g. theCAB302 Major Project: Electronic Asset Trading Platform5Spring framework, JavaFX etc.) is permitted, but you must make sure you cite these and providedetailed instructions in your project for getting these working so that we can build your software.Integration (5%)Your team should only really consider this part if you are feeling confident and have already madegood progress in the other stages, but part of delivering a software project as a professionalsoftware team is delivering an established build pipeline: Build scripts (in Ant, Maven or Gradle) to automate building and running unit tests. A continuous integration pipeline (in Jenkins or GitHub Actions) to build and test yoursoftware automatically when commits are made to the project repository.Make sure you demonstrate your build script(s) and continuous integration pipeline in your finalsubmission video!DeliverablesAs described in the overview, the client wants you to provide video demonstrations of the indevelopmentproject, final software etc. No marks are given for the quality of your presentation orfancy video editing work it is simply important that the videos demonstrate everything that youhave been asked to do for this project. Note that these videos will be used primarily to mark yourassignment that is, if you do not demonstrate some particular feature or aspect of your work, youwill not get any marks for it. This applies to the documents you need to submit, your code, yoursoftware while it is running etc.We suggest you read the CRA (available on Blackboard under Assessment – Major Project) andconsider demonstrating each item in the same order they appear in the CRA, to ensure the markerdoes not miss anything.You can record these videos however you wish a simple recording of the screen with voiceover issufficient, for example.Zoom can be used for this (just click to start a new meeting, share your screen, start recording andgo). OBS Studio is another popular choice but requires more setup work. Use of a mobile phonecamera pointed at the screen is discouraged. Editing and artistic license is not marked; however, wedo need to be able to see what is going on in your video.(If you do not have a dedicated microphone but do have a mobile phone that supports Zoom, youcan use this as a workaround for getting your voice into the video. Create a Zoom meeting from yourcomputer, join the meeting on your phone, then screen-share from your computer. You can thentalk using the phone while recording video using your computer.)Note that everyone in your team will eventually need to submit a video, so make sure that everyonegets some experience with the process.Milestone #1 (Week 8) (5%)The client is keen to see your progress on the requirements and detailed design documents by theend of Week 8 (April 30) to check that you are on track. These are not expected to cover everythingby this point, but just to represent a good start. If you have some early prototype work on the actualsoftware, this would also be a good time to demonstrate this to the client. You should submit thefollowing:CAB302 Major Project: Electronic Asset Trading Platform6 Your requirements document as it currently stands. Your detailed design document as it currently stands. Your current plan for the next 2 weeks (sprint planning). Keep this realistic and achievable;and describe what each team Member will be doing in that time. A video showing your progress (including showing the documents and your plan for the next2 weeks.) Maximum length: 4 minutes.The client may not have time to read the documents, so make sure everything is covered in thevideo. You can then use this submission to get some useful feedback on how you are going, to checkthat you are on the right track etc.The maximum length for this video is 4 minutes. If you submit a longer video, we will watch the first4 minutes of it and give you marks based on that. You may want to rehearse what you are going tosay and present in the video to keep within this time limit.Note that if you do not submit this milestone by Week 8, you can still submit it later (by the final duedate of June 6) and get the marks (5%). However, you will not be able to get feedback in time for itto be useful. Submit by the end of Week 8 if you want feedback.Milestone #2 (Week 10) (5%)The client is keen to see your progress after the previous two weeks; and would like to see how yourrequirements/detailed design documents have evolved in this time (if they have), and in general,how the software is coming along. By the end of Week 10 (May 16) submit the following: Your requirements document as it currently stands. Your detailed design document as it currently stands. Your current plan for rest of the project duration. A video showing your progress since the Week 8 milestone (including showing thedocuments and your plan for the rest of the project.) Maximum length: 4 minutes.Once again, the client may not have time to read the documents, so make sure everything iscovered in the video. Use the video to specifically focus on things that have changed since the Week8 milestone (i.e. its not important to cover things you covered in the previous video.)The maximum length for this video is 4 minutes. If you submit a longer video, we will watch the first4 minutes of it.Again, if you do not submit this milestone by Week 10, you can still submit it later (by the final duedate of June 6) and get the marks (5%), but this will come at the cost of timely feedback.Group submission (Week 13)At long last, the project deadline has been reached. The client is keen to see your results. If theproject has reached its completion and does everything the client asked for, congratulations! If not,the client still wants to see what you managed to achieve in the time.By the end of Week 13 (11:59 PM Sunday, June 6) your team must submit the following: Your final requirements document. Your final detailed design document. Instructions on how to deploy your software (including how the database needs to be setup, any external Java frameworks that you have used etc.).CAB302 Major Project: Electronic Asset Trading Platform7 Your project directory, including full source code, unit tests, .git directory and so on. Submitthis as a .zip file. A video demonstrating every Aspect of the project. Maximum length: 10 minutes.Again, everything needs to be covered by the video. The video should be sufficient to mark yourentire assignment, so make sure you cover everything you wish to receive marks for. We stillrequire you to submit everything else (so that we can check it if we feel it is necessary) but you willnot get any marks for anything that is not covered in the video.The maximum length for this video is 10 minutes. It may be difficult to cover everything in that time.We recommend: Rehearsing what you are going to cover in the video. Ensuring that the software you are going to demonstrate (your client and server programs)are already open and running before you start so you do not need to wait for them to loadup. Consider using some simple video editing software (e.g. OpenShot) to cut down on pauses,make jumping between documents faster etc. after you have finished the initial recording.Note that the .git directory is hidden by default. You may need to configure your environment toshow hidden files/directories before you zip your project directory, in order to ensure that this isincluded.Individual submission (Week 13) (10%)In addition to what your group has managed to put together, the client also wants to know what youcan do individually, and has asked each member of your group to submit videos. These videos have amaximum length of 3 minutes each and should contain the following: The parts of the project you worked on by yourself, the parts that you worked on withothers etc. A quick scroll through the Git history of your project (e.g. on GitHub/BitBucket, or throughthe git log command from inside Git Bash, or through Show Git Log in IntelliJ IDEA),focusing on your individual commits.Note that it is not necessary for your group to collaborate on producing these the marks awardedfor the things demonstrated in these individual videos are awarded individually.CAB302 Major Project: Electronic Asset Trading Platform8Additional InformationVideo formats and sizesMake sure you submit your video files in a format that we can use. Generally speaking, if VLC canopen your video, you should be good. The videos created by Zoom and OBS Studio should not haveany problems, but if you use some other unusual software there may be an issue.Your video files should also not be too large. Zoom tends to create nice small video files, while OBSStudio (on default settings) creates pretty large ones. If you are using OBS Studio, it might bedesirable to re-encode your videos with a tool like Handbrake (experiment with the quality settings.)Try to aim for 50mb or less.Another approach you can take is to upload your video to a video sharing site like YouTube (preferunlisted to public when uploading your video), or a reliable file-sharing service like DropBox orGoogle Drive, and then submit the link.Group vs Individual marksThe standard mark breakdown for this assignment is 50% group marks, 10% individual marks. Groupmarks are awarded to the entire group (everyone will receive the same mark) while individual marksare awarded individually. The group marks come from the Milestone #1, Milestone #2 and GroupSubmission items above (worth 5%, 5% and 40% respectively), while the individual marks come fromyour individual submission video (worth 10%.) This is how the assignments will normally be assignedmarks.However, under certain circumstances, different members of the group may receive a differentgroup mark to each other. The main reason this might happen is if certain members of the group didnot contribute to certain stages of the project (e.g. did not contribute to the detailed design, did notwrite unit tests, did not write code.) In that case those group members will receive a group mark of 0for those sections (we cannot give you marks for things you did not do.)Now, we understand that occasionally group dynamics can turn ugly and things can happen, such asone group member taking over control of a certain part of the project and not allowing others tocontribute. We hope this does not happen to your group, but in those circumstances, the solution isto do work on these sections (reports, unit tests, implementation code etc.) and then submit yourwork separately along with your individual contribution video and an explanation of why you aredoing so, just to show that you are capable of doing the work and therefore are entitled to receivethe groups mark.CAB302 Major Project: Electronic Asset Trading Platform9Academic integrityThe process we will be using to ensure the integrity of this assignment is a simple one. At the end ofthe semester, with everything submitted, we will take everything that has been submitted (all yourdocuments, source code etc.) and throw it into various tools for detecting duplicates, just asStanford MOSS. If we find teams have submitted substantially duplicate work (either to anotherteam or to material found online) they will be automatically referred to the Faculty AcademicMisconduct Committee.Here are some tips on how to protect yourself: If you find some nice code online that does what you want (and there are no legal problemsassociated with you using it), e.g. on StackOverflow, feel free to copy and paste that intoyour project. But make sure you put in a comment above the code saying where you got itfrom. If the code is from StackOverflow, link the StackOverflow post. Cite everything you usefrom somewhere else. If you want to work with people who are not in your team, that is okay! You can discussideas, discuss requirements, talk about different ways of doing things. However, yourdocuments, source code, software etc. must be kept within your team and you must notsubmit work that was not created outside your team. In addition, do not record yourdemonstration videos using another groups software. If you have your code in an online repository provider like GitHub or BitBucket (this is highlyrecommended), make sure that you have it set to private so that others outside your teamcannot see it. Otherwise, unscrupulous individuals can submit your code and you may bepenalised by the Misconduct Committee even if you can prove it was your code originally. Dont make your repository public immediately after the due date. Last year I had a situationwhere one student made his repository public after the due date and another student, whowas given an extension, downloaded it and submitted it themselves. Wait a few monthsfirst. If an employer wants to see your work, you can just give them access to it individually. Do not upload your assignment or the assignment specification to any public external sites,including but not limited to StackOverflow, Chegg, social media etc.CAB302 Major Project: Electronic Asset Trading Platform10Appendix A: Client Project DescriptionTo Whom It May Concern,RE: Electronic Asset Trading PlatformWe have a great many different types of resources that need to be efficiently distributed and sharedacross the organisation (computational resources, hardware resources, software licenses etc.). Aftertrying a few approaches that we have determined are not satisfactory, we have settled on thefollowing approach, and we want your team to build us a software platform to help us implement it:We require your team to implement a virtual trading platform for these resources. The idea is thatorganisational units will be given a budget of a certain number of electronic credits. They can thenuse those credits to buy access to resources from other organisational units. So, for example, ourcompute cluster division might sell individual CPU hours for credits, and then take the credits theyget and use that to buy other things they need. We do not know, in advance, exactly what assets willbe traded on this platform you should create a flexible enough system that we can add new assettypes to.We require the software platform to facilitate trades via a marketplace model. Instead of having twoorganisational units agree to trade synchronously, organisational units who want to buy somethingwill put in a BUY order, for a certain quantity of a particular commodity at a particular price (e.g. BUY100 CPU hours at 10 credits each). Organisational units wishing to sell something will put in a SELLorder, again, for a certain quantity at a certain price (e.g. SELL 500 CPU hours at 10 credits each.)Your software will periodically check and reconcile all outstanding trades. In this particular example,100 CPU hours will be sold to the first organisational unit for 10 credits each. This will eliminate thefirst organisational units BUY order entirely, while the second organisational units SELL order willbe reduced to SELL 400 CPU hours at 10 credits each. Trades will not happen if the terms areunacceptable to either party (e.g. more expensive than the buyer is willing to pay, or less expensivethan the seller is willing to accept.) If there is some slack in two compatible trades (e.g. BUY 10widgets for 20 credits and SELL 10 widgets for 15 credits) the transaction should be carried outusing the lower price (which will always be the selling price.)We require this to be implemented with a client-server model, where we run 1 server (which keepstrack of every organisational units assets, credit balance and all trades.) and clients connect to thisserver to list trades. There should be no (artificial) limit to the number of commodities in thedatabase, no limit to the number of trades that can be listed and no limit to the number of usersusing the system. We need everyone to have their own usernames and passwords which the userwill enter into the client when logging in, to ensure only authorised users from each organisationalunit are able to trade.We have included some user stories from people in the organisation who will be using this software,so you can get a feel for what we want to see. Best of luck!Regards,The ManagerCAB302 Major Project: Electronic Asset Trading Platform11Appendix B: User StoriesAs a user, I think its important to have a nice, friendly GUI interface, not a dusty old commandline interface.As a user, when I am thinking about listing a buy or sell offer for an asset, I want to be able to seewhat current BUY and SELL offers are currently listed, so that I do not greatly overbid/underbid.As the leader of an organisational unit, I need all of the members of my team to have access tothis system, through their own individual usernames and passwords. I need them all to be tradingusing the credit balance and assets of the organisational unit they are part of.As a user, sometimes after adding an offer I might decide that I want to remove that offer,perhaps to relist it again at a different price. I should be able to see all the currently standingoffers from my organisational unit in the database and be able to selectively remove them.As the leader of an organisational unit, I do not want to accidentally put in a BUY offer for morecredits than my organisational unit has, or a SELL offer for more of a particular asset than myorganisational unit has. We do not want our organisational units to risk going into debt. Thesystem should check for this and stop us from listing more than we have. For example, if I have 50widgets and I have a SELL offer for 30 of the”