Please include an interface class or abstract class, an inheritance relationship, and one composition relationship. Please draw a UML diagram based on the following prompt. Utilize MVC and State Pattern. Have added information on that below. I have attached a picture of how the UML diagram should look like.
The scenario The Department of Computer Science would like to create a mechanism to keep track of positions and applicants for hourly positions. To help with understanding the positions and applications for a hiring system, the department has provided the requirements for an internal position management system. You and your co-workers have been requested to each propose a design for the static layout of the system by identifying the objects, their state and behavior, and the relationships between the objects in the system. Your design must include a State Pattern that models the finite-state machine of an application's state. Your manager will then choose a design that best describes the requirements for implementation. What you must do: Design Rationale and UML diagram You must design an application that satisfies the requirements of the WolfHire application. You will create a design proposal that shows the objects, their states and behaviors, and the relationships among the objects needed to implement the requirements. Your design must be described in a document containing a design rationale and a UML class diagram. Your design should: utilize the Model-View-Controller (MVC) design pattern (see the note about MVC, below), > utilize the State Pattern (see the note about State Pattern, below), > contain at least one interface or abstract class, > contain at least one inheritance relationship (which could include implementing an interface), and > contain at least one composition relationship. To heip your manager evaluate your design, you should answer the following technical questions in your design document as part of the rationale: 1. What objects are important to the system's implementation and how do you know they are important? 2. What data are required to implement the system and how do you know these data are needed? 3. Are the responsibilities assigned to an object appropriate for that object's abstraction and why? 4. What are the relationships between objects (such as inheritance and composition) and why are these relationships important? 5. Have you identified any design patterns appropriate for implementing the system (i.e., the State Pattern)? What are they and why are they appropriate? 6. What are the limitations of your design? What are the constraints of your system? MVC Note Java Swing, the user interface (UI) libraries for Java, does not follow the strictly traditional definition of MVC. Instead, Java Swing utilizes what might be called a separable model architecture. This means that the model is separate and distinct from the view/controller classes that make up the UI. Your design must focus on the model. In your UML class diagram, you should represent the UI as a class with minimal state and behavior. The only state for the UI you would need to show in the class diagram would be through association connectors with one or more model classes. The only behavior you might have in your UI class would be a main method should you choose to do that for your design. The relationship between your model and the UI must be justified in your design rationale. When thinking about the relationships between your UI and the model, consider the following questions: 1. What are the data and behaviors of your model that will be shown through the UI? 2. How does your UI get those data to display? What methods of the model must be called? State Pattern The State Pattern is an object-oriented solution to a state-based application. The finite-state machine that models the state of an application should be modeled using the State Pattern. This means the bubbles, which represent states, become classes. The transitions become the behavior(s) of the classes. A context class encapsulates the state pattern for each application and delegates the transitions to the current state for the given application. For more information on the State Pattern, see the lecture notes (Lecture Notes, Wikipedia article and the example Horner's Rule State Pattern implementation). The classes that make up the state pattern must be justified in your design rationale. Problem Overview The Department of Computer Science hires students to work as graders and research assistants, among other positions. Managing the applications and hiring process can be a challenge. We're going to create a tool, WolfHire, to help with managing the process of hiring hourly student workers for the Department of Computer Science. Faculty and staff can create positions. One such position would be a CSC 216 Peer Teaching Fellow (PTF). Students can then apply for the position. Faculty and staff can then process the applications through the Application FSM (details below). To simplify this proof-of-concept implementation, we won't require authentication or creation of user roles. You may assume that the correct person would interact with the application at any stage of the process. This process of managing applications for a position can be modeled as a finite-state machine (FSM). The FSM is illustrated in Figure 1. (The transitions are too detailed to fully label in the diagram. Instead each transition is given a name corresponding to the state where it starts. Descriptions of the transitions follow below.) Pigure: WoltHire Application rifite State Machine Applications are rejected with four possible reasons: > Qualifications: the applicant doesn't have sufficient qualifications for the position > Incomplete: the application is incomplete > Positions: the applicant is qualified, but there are insufficient positions to hire them > Duplicate: the application is a duplicate of another application Applications that reach the Hired state are eventually terminated and transition to the Inactive state. An application may be terminated with three possible reasons: > Completed: the job the applicant was hired for is completed (e.g., a grader position is only for a semester) > Resigned: an applicant may choose to resign their position > Fired: an applicant may be fired for underperformance The finite state machine for the applications for a position in the WolfHire system is described below. The transitions are labeled with the state they are coming from and match the arrows in the FSM diagram. > Submitted. A user will create a new application, which starts in the Submitted state. The application is either assigned to a faculty or staff member for review or is rejected. > SubmittedA. The application is assigned to a reviewer and moves to the Reviewing state. > SubmittedB. The application is Rejected due to one of the rejection reasons. > Rejected. An application in the Rejected state is marked as lacking qualifications, incomplete, due to insufficient positions, or duplicate. If something changes about an application or the position, it can be reconsidered. > RejectedA. Something has changed about the application moving it back to the Submitted state. > Reviewing. An application in the Reviewing state is under review by a faculty/staff member. The reviewer can move the application forward for interviewing, send it back to submitted if they are unable to review, or reject the application. > ReviewingA. The applicant is contacted for an interview (outside of WolfHire) and the application moves to the Interviewing state. > ReviewingB. The reviewer cannot review the application and moves it back to the Submitted state to be assigned to another reviewer. > Reviewing . The application is Rejected due to one of the rejection reasons. > Interviewing. An application in the Interviewing state represents the interview phase of a hiring process. The faculty/staff member can decide to hire the applicant and move them forward for Processing paperwork, reassign the application to another reviewer, reschedule the interview, or reject the application after the interview. > InterviewingA. The faculty/staff wants to hire the applicant and move the application on for Processing paperwork. > InterviewingB. The application is assigned to a new reviewer and is moved to Reviewing. > Interviewing . The interview is rescheduled. > InterviewingD. The application is Rejected due to one of the rejection reasons. > Processing. An application in the Processing state represents the completion of hiring paperwork. If an applicant is hired, they move to the Hired state. If the paperwork is incomplete or invalid, they may move to the Rejected state. > ProcessingA. The paperwork is completed and the applicant is Hired. > ProcessingB. The application is Rejected due to one of the rejection reasons. > Hired. An application in the Hired state represents a current employee for the position. > HiredA. The applicant is terminated for one of the termination reasons. > Inactive. An application is Inactive if the applicant is no longer working in the position. They could submit a new application to a position. UML Class Diagram Major classes from the requirements are included in the diagram. Fields appropriate for the hierarchy are in each class. \begin{tabular}{|c|} \hline \( \begin{array}{c}\text { CourseRecordio } \\ \text { edu ncsu.csc216.wolf_schedulerio }\end{array} \) \\ \hline \hline +readCourseRecords(file Name Strina): ArtravList
