- 作业标题：Project 1, Part 2: Product Backlog
- 课程名称：NCSU CSC216 Software Development Fundamentals
- 完成周期：2天
Project 1, Part 2: Product Backlog
Part 1 of this assignment laid out the requirements for the Product Backlog application that you must create. Part 2 details the design that you must implement and test. For this part, you must create a complete Java program consisting at multiple source code files and JUnit test cases. You must electronically submit your files to NCSU GitHub by the due date.
Set Up Your Work Environment
Before you think about any code, prepare your work environment to be compatible with the teaching staff grading criteria. The teaching staff relies on NCSU GitHub and Jenkins for grading your work. Follow these steps:
Create an Eclipse project named Project1: Right click in the package explorer, select New > Java Project. Name the project Project1. (The project naming is case sensitive. Be sure that the project name begins with a capital P and ends with a 1. There are no spaces in the project name.)
If you have not already done so, clone your remote NCSU GitHub repository corresponding to this project. Note that each major project will have its own repository.
Note
You are expected to complete the project individually. All work must be strictly your own.
Requirements
The requirements for this project are described in Project 1 Part 1 in eight different use cases. The Problem Overview describes the Task FSM for tasks. The system is further described in 18 use cases and associated product data format.
Startup
Use Case 0: Start ProductBacklog
Managing State
Use Case 1: Load System State
Use Case 2: Save System State
Use Case 3: Clear System State
Products
Use Case 4: Add Product
Use Case 5: Edit Product
Use Case 6: Remove Product
Use Case 7: Select Active Product
Tasks
Use Case 8: List Tasks
Use Case 9: Add a Task
Use Case 10: Delete a Task
Use Case 11: Edit a Task
Use Case 12: Edit Task in Backlog State
Use Case 13: Edit Task in Owned State
Use Case 14: Edit Task in Processing State
Use Case 15: Edit Task in Verifying State
Use Case 16: Edit Task in Done State
Use Case 17: Edit Task in Rejected State
Shutdown
Use Case 18: Quit ProductBacklog
Data Format
Valid Records
Invalid Records
Design
Your program must implement the teaching staff design, which is described below. The design consists of 13 different classes (6 as inner classes), 2 enumerations, and 1 interface. We are providing the interface (TaskState - which should be an inner interface of the Task class) and the graphical user interface front-end (ProductBacklogGUI).
Important
The project you push to NCSU GitHub must contain unmodified versions of the files that we provide for you unless stated otherwise by the instructor.
edu.ncsu.csc216.product_backlog.model.*
edu.ncsu.csc216.product_backlog.model.command. Sub-package of edu.ncsu.csc216.product_backlog.model containing the object representation of a command that a user would make in the Product Backlog system that might initiate a state change. This is an example of the Command Pattern.
Command. Encapsulates the information about a user command that would lead to a transition. Contains one inner enumeration, which is provided for you in the Implementation section, below.
CommandValue. An enumeration contained in the Command class. Represents one of the six possible commands that a user can make for the Task FSM.
edu.ncsu.csc216.product_backlog.model.task. Sub-package of edu.ncsu.csc216.product_backlog.model containing the State Pattern implementation of the task FSM.
Task. Concrete class that represents a task tracked in the Product Backlog system. A Task keeps track of all task information including the current state. Task is the Context class of the State Design pattern. The state is updated when a Command encapsulating an input from the user given to the Task leading to a transition. Task encapsulates the the TaskState interface, six concrete *State classes and one enumeration:
TaskState interface. Interface that describes behavior of concrete TaskState classes for the task FSM. You cannot change this code in any way. You MUST copy this interface code into the Task class as an inner interface. All concrete *State classes must implement TaskState:
BacklogState: Concrete class that represents the backlog state of the Task FSM.
OwnedState: Concrete class that represents the owned state of the Task FSM.
ProcessingState: Concrete class that represents the processing state of the Task FSM.
VerifyingState: Concrete class that represents the verifying state of the Task FSM.
DoneState: Concrete class that represents the done state of the Task FSM.
RejectedState: Concrete class that represents the canceled state of the Task FSM.
Type: An enumeration contained in the Task class. Represents the four possible categories of tasks.
edu.ncsu.csc216.product_backlog.model.product. Sub-package of edu.ncsu.csc216.product_backlog.model containing the Product class.
Product. Concrete class that maintains a its name and a list of associated Tasks.
edu.ncsu.csc216.product_backlog.model.io. Sub-package of edu.ncsu.csc216.product_backlog.model containing file processing classes.
ProductsReaders. Processes a file containing product and task information and creates a List of Products and their associated Tasks.
ProductsWriter. Writes the given list of Products to the file name provided.
edu.ncsu.csc216.product_backlog.model.backlog. Sub-package of edu.ncsu.csc216.product_backlog.model containing
BacklogManager. Concrete class that maintains a list of Products, the active or current Product, and handles events from the GUI. BacklogManager implements the Singleton Design Pattern.
edu.ncsu.csc216.product_backlog.view.*
edu.ncsu.csc216.product_backlog.view.ui. Sub-package of edu.ncsu.csc216.product_backlog.view containing the view-controller elements of the Product Backlog Model-View-Controller pattern.
ProductBacklogGUI class. The graphical user interface for the project. This is the class that starts execution of the program. You cannot change this code in any way. The ProductBacklogGUI interacts with the rest of the system through the BacklogManager singleton.
UML Diagrams
The UML class diagram for the design is shown in the figure below. The fields and methods represented by green circles (public) or yellow diamonds (protected) represent the minimum set of visible state and behavior required to implement the project. Fields that are private represent the state of the classes and should be used in almost all cases. Methods that are private were helpful in the teaching staff solution and are provided as a suggestion; you do not have to have the private methods in your solution. Note that parameter names are fully listed in the Implementation section.
…omit…
