1. Project Overview Our PROG 24178 project is a group project in which either two students or three students collaborate

[answerhappygod]

1 Project Overview Our Prog 24178 Project Is A Group Project In Which Either Two Students Or Three Students Collaborate 1 (86.4 KiB) Viewed 47 times

1. Project Overview Our PROG 24178 project is a group project in which either two students or three students collaborate equally to create an object-oriented program of medium complexity. It should be a GUI program that uses principles, best practices and technologies learned in the course. Certain elements are a required part of your project, for example it must implement a GUI of reasonable complexity, use a dynamic data structure like ArrayList, and use file input and/or output (further details below in "General Requirements"). The rest is up to you. Each student group will choose their own idea for their application and submit a project proposal outlining their idea. For the GUI portion of the project, you will use the JavaFX platform. You can desig your GUI graphically with Scene Builder or implement it dynamically in code. This choice, along with other detailed plans, must be clearly stated in the project proposal. Above all your project should be interesting and fun, so try to choose an idea you find interesting or potentially useful. Don't make your project too big or ambitious, remember it should take about as much time as two or three assignments. If you feel your project may be too big then you could simplify certain portions or leave parts for future implementation. For example, a GUI button could display a message "Not yet implemented". After you are done, you may want to add your project to your SLATE ePortfolio (Sheridan co-curricular record) to show off to others.
2. General Requirements 1. GUI Portion: The project will consist of at least 2 GUI windows or dialogs (minimum one per team member). In JavaFX this means at least 2 stages, where each stage has its own separate FXML file and controller class. Error messages or simple confirmation dialogs don't count. 2. Non-GUI Portion: Minimum one class per team member - so minimum two back-end (data management) classes, not counting GUI classes or controller classes. 3. File I/O: Either file input, output, or both. For example, a program that manages information about customers of a business could store the customer information in a file and then re-load the file next time your run the program. 1 4. Data structures: ArrayList (dynamic array) For example a multi-player game could use an ArrayList of Player objects to store information about all the players. Often (but not always) you may use a dynamic data structure like ArrayList to store information you read from a file. Don't use regular Java arrays. 5. Exception Handling: For full marks your proiect should contain enough
5. Exception Handling: For full marks your project should contain enough exception handling and error recovery so that bad user input (or bad input files etc.) don't crash the program. You should display a user-friendly error message instead. 6. Commenting: The code shall be commented as follows. a. Each Java class shall have a header comment which lists the principal author(s) of the code and briefly describes what the code in the file is for b. Each method and field shall be commented. For methods include the purpose of method and a brief description of each parameter. For fields give the purpose of the field and units if applicable (e.g. length in meters, price in dollars). c. Code inside methods shall be commented as needed (e.g. tricky steps) using non-Javadoc style comments. d. FXML files do not need to be commented. 7. Coding standards and quality: All code shall follow our coding standards. Variable names should be descriptive. Classes should be well designed and well structured, with use of object-oriented techniques such as encapsulation, inheritance, abstract classes, and interfaces where appropriate. Programs should not use repetitive code and should use field 2
variables only where necessary. Programs should not define variables or methods that are never used; logic should be written concisely and not cluttered with unnecessary code. 3. Project Deliverables 3.1 Project Proposal Prepare and submit a proposal document for the project with the following structure. The document should be created using Microsoft Word (hand in one .docx file using SLATE, no additional files), or on paper A cover page with the project title and all group member names. 1. Project Overview. A few paragraphs describing the purpose of the application, the development environment (Visual studio code, JDK17, etc.) and the technologies used (JavaFX, SceneBuilder, file I/O, collections, graphics etc.) Your description must make clear how you will be incorporating the required elements: a) File I/O - What information will you save to files on disk, and/or what information will you load from files? Detailed file format information is not required. 3 b) Dynamic array - What information will be stored in a dynamic data structure? How will it be managed? 2. User Interface. Provide one drawing for every window (stage/activity/dialog) you envision to be part of your project. You can draw it on paper, draw using Visio, or you can design it in Scene Builder and provide a screenshot. Proiect Class Structure Use UML class diagram/s) to present the rough class
3. Project Class Structure. Use UML class diagram(s) to present the rough class design you envision for the application. You should include all significant classes and their relationships (arrows). Fields and methods are not required to be listed. Diagrams can be done on paper, or with a UML drawing tool like StarUML or Visio (UML Model Diagram template). It must be clear which classes are GUI classes and which classes are non-GUI (data management) classes. For JavaFX all controller classes should have names ending with "Controller". Although each project will be unique, all JavaFX projects will have - FXML files for the GUI layout (one file per window) - Controller classes for the GUI event handlers (one per window) - Data management classes (typically two or more) When designing a larger application like your course project avoid putting data management code in the controller (GUI) classes. 3 4. Division of responsibilities. To the extent possible, list the planned division of responsibilities, e.g. who will work on which classes, who will design/implement the GUI, etc. Work should be divided between group members as evenly as possible one group member should not do most of the work! The proposal is not final. If it needs to be modified to be accepted, I will let you
The proposal is not final. If it needs to be modified to be accepted, I will let you know. During development certain functionality may be changed, modified, added or removed. Your original design may change - this is a part of a normal development process. The proposal must be updated and resubmitted if there are any major changes. The professionalism of your submission, and clarity of written communication is important. If your proposal is incomplete or missing any major element by the project due date you will receive the penalty. 3.2 Project Report The project report structure and format is similar to the proposal. It should include: 1. A cover page with the project title and group member names 2. Final project overview and description, including a description of how dynamic arrays and file I/O were used 3. Actual GUI screen snapshots for every window (stage/activity/dialog) 4. Final UML class diagram(s) including all classes you implemented and their relationships (fields and methods are not required to be listed) 5. A separate conclusion section for each group member describing important lessons you learned, difficulties you encountered, things you would do differently in the future etc. The project report sections should be written by the same group member who did the work described. The professionalism of your submission, and clarity of written communication is extremely important.