Java代写：CAB302 Electronic Asset Trading Platform

发表于   |   分类于

使用client-server模式，实现一个Electronic trading platform供买家和卖家交易，需要使用GUI, Sqlite等。

Electronic trading platform

Overview

The unnamed client corporation has contracted your team of developers to create a client-server system for electronic trading of virtual assets within their organisation. Included in this document are a description of the project from the corporation (Appendix A), as well as a collection of user stories from project stakeholders (Appendix B).

Your team’s task is to gather requirements from the project description and user stories. Your team must 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, along with a comprehensive unit testing suite. Finally, you will need to demonstrate this system to the client, showing how you have met their requirements. Due to the international nature of our client and the present situation with COVID-19, this demonstration will need to be recorded in the form of a video. The client also wants individual videos from members of your team, detailing their individual contributions.

These are not sequential steps, and it is expected you will revisit earlier steps as you develop the project and learn more about what you are creating.

In addition to your code and the reports described previously, the client also insists on having access to the full revision history of your project. This means that, from the start, your project’s working directory needs to be hosted in a Git repository and you need to be regularly creating commits with useful commit messages. This will also help your team to collaborate with each other. (Note that, if you have a copy of your repository hosted by a provider like GitHub or BitBucket, make sure that your project is private to ensure that your code is safe from other competing teams who might try to pass off your hard work as their own.)

The client will naturally want to be updated at various points during the project’s development and you will be required to submit videos for that purpose as well.

Project Stages

Requirements

For this part of the project you must create a requirements document, which simply consists of a list of the client’s requirements, for use when creating your detailed design. This may be a separate document or part of your main report (along with the detailed design.)

You will find the client’s requirements in Appendix A (Project description) and Appendix B (User stories) of this specification. If you require clarification as to the client’s requirements, send email to [email protected] - before you do so, however, check the “Responses to Client Inquiries” folder on Blackboard (under Assessment -> Major Project) to see if your question has already been answered.

We have no specific requirements for how this document needs to be formatted- simply that it contains a list of requirements and their priorities (e.g. must have, should have, nice to have) and that those requirements are sensibly grouped (e.g. by priority.) You can also include e.g. very basic user interface mockups if those help to describe the design for the project. The main thing is that this document needs to contain all the information needed by a project team to implement the project the client wants without needing to go back to the information in Appendices A and B. In other words, you need to synthesise all relevant facts contained within those appendices into your requirements document.

You can search the web for “product requirements document” to get ideas for possible structures for this document, but you are not required to follow any of them.

Expected length: 2-4 pages.

Detailed Design

Your team needs to create a detailed design document that takes the project requirements from your requirements document and describes, in detail, the components needed to create the software you have been tasked with developing.

As with the requirements document, there is no specific format required. However, it is expected that your document will contain at least the following:

  • Designs of the (public) Java classes that will comprise your programs:
    • Descriptions of all public methods and fields.
    • Descriptions of the arguments each method takes and what the method returns.
    • Any assumptions (preconditions and postconditions).
    • Any checked exceptions that may be thrown by the method, and the circumstances under 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 design document up to date with the source code. You are permitted to submit your JavaDoc separately 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 start creating these classes and methods. Do not create the actual implementations yet (just make all the methods return e.g. 0 or ‘null’), but just creating the classes and methods will allow you to start creating JavaDoc-style /** comments, which you can use as part of your design process.
  • How these classes interact with each other (e.g. which classes call which other classes, which classes are passed as arguments to the method calls of other classes.)
    • You may find it useful to create a class diagram to document this, but this is not required. 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 ones that are responsible for the internal work that needs to be carried out, and therefore the classes that would be tested via unit tests. Examples of classes that you do not need to include here are:
      • Test classes
      • Exceptions
      • GUI forms
  • Designs of the forms that make up the client’s graphical user interface, and how these forms are interconnected.
    • These can be e.g., scanned/photographed sketches, but I would suggest using drawing tools to create respectable looking user interface mockups.
    • If you created the server as a GUI program, you should also include designs for the server’s GUI forms.
  • The design of the database schema
    • Tables and table columns (column names and data types)
    • How those tables are connected (primary keys and foreign keys) You may find it useful to use Object-Role Modelling to present this information, but it is not necessary.
  • The design of the network protocol used by the client and server to exchange information.
    • A description of the data that is sent from client to server or from server to client, and how that data should be interpreted.
    • Basically, this part should contain all the information required to create a compatible server or client that could be used to replace the server or client that your team creates.
      Like every other step, it is not expected that you will create this in one go. You will end up refining this document over the course of the project as things change and you learn more about the software 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 design documents for software projects, but once again, you are not required to follow any particular structure for this document.

The principal litmus test by which you should judge this document is if a skilled team would be able to take it and produce the software (by creating the classes described within the design and developing 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 page count.

Unit Testing

For this part of the project, your team will need to take your detailed design document and use the information 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 the implementations for these classes. These unit tests should check that the classes follow their specifications as described in the detailed design document.

Remember to create unit tests for:

  • Normal cases
  • Boundary cases (for each equivalence class)
  • Exceptional cases

As 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 unit tests. This time the goal is to complement your black box tests with tests that attempt to achieve full code coverage. (You can use IntelliJ IDEA to evaluate code coverage of your unit tests using ‘Run with Coverage.’) You want to create tests that are deliberately designed to cover as much code as possible.

As with the other stages, your unit tests are not expected to remain static. Changes to requirements and 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 to be mocked for them to be tested. Creating mock classes is part of your unit testing stage, and these do not need to be documented in your detailed design.

Remember the mantra of Test-Driven development: red, green, refactor!

Implementation

In this stage your team needs to actually create the software requested by the client. Ideally your development should be agile, and you should reach this stage early on, getting something very basic working 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 Development approach and write very basic implementations designed to pass the unit tests, then refactor them to remove duplication and improve the quality of the code.
  • Implement classes that you don’t have unit tests for. These include the non-mock versions of the mock classes you created during the unit testing stage (classes designed to interface with 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.) We suggest creating just one project (remember that each class can have its own main() method), but dividing 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 containing classes 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 all the functionality you need for completing this project. Use of external Java frameworks (e.g. the Spring framework, JavaFX etc.) is permitted, but you must make sure you cite these and provide detailed instructions in your project for getting these working so that we can build your software.

Integration

Your team should only really consider this part if you are feeling confident and have already made good progress in the other stages, but part of delivering a software project as a professional software 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 your software automatically when commits are made to the project repository.

Make sure you demonstrate your build script(s) and continuous integration pipeline in your final submission video!

Deliverables

As described in the overview, the client wants you to provide video demonstrations of the indevelopment project, final software etc. No marks are given for the quality of your presentation or fancy video editing work - it is simply important that the videos demonstrate everything that you have been asked to do for this project. Note that these videos will be used primarily to mark your assignment - that is, if you do not demonstrate some particular feature or aspect of your work, you will not get any marks for it. This applies to the documents you need to submit, your code, your software while it is running etc.

We suggest you read the CRA (available on Blackboard under Assessment -] Major Project) and consider demonstrating each item in the same order they appear in the CRA, to ensure the marker does not miss anything.

You can record these videos however you wish - a simple recording of the screen with voiceover is sufficient, for example.

Zoom can be used for this (just click to start a new meeting, share your screen, start recording and go). OBS Studio is another popular choice but requires more setup work. Use of a mobile phone camera pointed at the screen is discouraged. Editing and artistic license is not marked; however, we do 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, you can use this as a workaround for getting your voice into the video. Create a Zoom meeting from your computer, join the meeting on your phone, then screen-share from your computer. You can then talk 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 everyone gets some experience with the process.

Milestone #1 (Week 8)

The client is keen to see your progress on the requirements and detailed design documents by the end of Week 8 (April 30) to check that you are on track. These are not expected to cover everything by this point, but just to represent a good start. If you have some early prototype work on the actual software, this would also be a good time to demonstrate this to the client. You should submit the following:

  • 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 next 2 weeks.) Maximum length: 4 minutes.

The client may not have time to read the documents, so make sure everything is covered in the video. You can then use this submission to get some useful feedback on how you are going, to check that 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 first 4 minutes of it and give you marks based on that. You may want to rehearse what you are going to say 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 due date of June 6) and get the marks (5%). However, you will not be able to get feedback in time for it to be useful. Submit by the end of Week 8 if you want feedback.

Milestone #2 (Week 10)

The client is keen to see your progress after the previous two weeks; and would like to see how your requirements/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 the documents 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 is covered in the video. Use the video to specifically focus on things that have changed since the Week 8 milestone (i.e. it’s 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 first 4 minutes of it.

Again, if you do not submit this milestone by Week 10, you can still submit it later (by the final due date of June 6) and get the marks (5%), but this will come at the cost of timely feedback.

Group submission

At long last, the project deadline has been reached. The client is keen to see your results. If the project 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 set up, any external Java frameworks that you have used etc.).
  • Your project directory, including full source code, unit tests, .git directory and so on. Submit this 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 your entire assignment, so make sure you cover everything you wish to receive marks for. We still require you to submit everything else (so that we can check it if we feel it is necessary) but you will not 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 load up.
  • 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 to show hidden files/directories before you zip your project directory, in order to ensure that this is included.

Individual submission (Week 13)

In addition to what your group has managed to put together, the client also wants to know what you can do individually, and has asked each member of your group to submit videos. These videos have a maximum 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 with others etc.
  • A quick scroll through the Git history of your project (e.g. on GitHub/BitBucket, or through the ‘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 awarded for the things demonstrated in these individual videos are awarded individually.

Additional Information

Video formats and sizes

Make sure you submit your video files in a format that we can use. Generally speaking, if VLC can open your video, you should be good. The videos created by Zoom and OBS Studio should not have any 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 OBS Studio (on default settings) creates pretty large ones. If you are using OBS Studio, it might be desirable 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 (prefer ‘unlisted’ to ‘public’ when uploading your video), or a reliable file-sharing service like DropBox or Google Drive, and then submit the link.

Group vs Individual marks

The standard mark breakdown for this assignment is 50% group marks, 10% individual marks. Group marks are awarded to the entire group (everyone will receive the same mark) while individual marks are awarded individually. The group marks come from the Milestone #1, Milestone #2 and Group Submission items above (worth 5%, 5% and 40% respectively), while the individual marks come from your individual submission video (worth 10%.) This is how the assignments will normally be assigned marks.

However, under certain circumstances, different members of the group may receive a different group mark to each other. The main reason this might happen is if certain members of the group did not contribute to certain stages of the project (e.g. did not contribute to the detailed design, did not write unit tests, did not write code.) In that case those group members will receive a group mark of 0 for 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 as one group member taking over control of a certain part of the project and not allowing others to contribute. We hope this does not happen to your group, but in those circumstances, the solution is to do work on these sections (reports, unit tests, implementation code etc.) and then submit your work separately along with your individual contribution video and an explanation of why you are doing so, just to show that you are capable of doing the work and therefore are entitled to receive the group’s mark.