a build a student record managing system

Question

A.  Build a student record managing system application by doing the following:

1.  Create a Student inheritance hierarchy. This should include the following requirements:

• Create the Student class. Student will be the super class and an abstract class. At least one method on Student will be abstract.
• Student class holds the attributes first name, last name, student ID, GPA, status (resident or nonresident), and mentor. All attributes will be inherited by the subclasses.
• Create appropriate overloaded constructors for the super class, Student.
• Student has an abstract method, calculateTuition(), which will be implemented in the subclasses Undergraduate, Graduate, and Part-time, making use of the polymorphism principle.
• Create the subclasses Undergraduate, Graduate, and Part-time, which inherit from the Student class. Each subclass will encapsulate a specialization of Student.
• Create an abstract method, update(). When this method is called, the database entry for the student is updated.
• Create an abstract method, add() method. When this method is called, the database entry for the student is created.
• Create an abstract method, delete(). When this method is called, the database entry for the student is deleted.
• Create an abstract method, query(). When this method is called, a query is made to the database to retrieve the information and is then printed to the screen.

2.  Create subclasses. This should include the following requirements:

• Create the subclass Undergraduate, which inherits from Student. Undergraduate has the additional attribute, "level" (freshman, sophomore, junior, senior).
• Create the subclass Graduate, which inherits from Student. Graduate has additional attributes, "thesisTitle", and "thesisAdvisor".
• Create the subclass Part-time, which inherits from Student. Part-time students are working adults. Part-time students have an attribute, "company", which is the name of their sponsoring employer.
• Incorporate the technique of information hiding by making appropriate attributes private and creating getters and setters to access and modify each private attribute.
• Create overloaded constructors for each Student type. The super class constructor should be used by each subclass's constructors to set those attributes found in the super class. Create enough constructors for each class to initialize the instance variables (attributes) of an object, either by initial values passed into the constructor or default values used if none is passed in. All values passed in should be verified for validity.

3.  Implement the following methods using polymorphism. This should include the following requirements:

• Implement calcuateTuition() method as follows:

»  Status of resident: undergraduate tuition = number of credit hours × 200

»  Status of nonresident: undergraduate tuition = number of credit hours × 400

»  Status of resident: undergraduate part time = number of credit hours × 250

»  Status of nonresident: undergraduate part time = number of credit hours × 450

»  Status of resident: graduate = number of credit hours × 300

»  Status of nonresident: graduate = number of credit hours × 350

• Student objects should know how to display the information. Override the toString() method on each subclass. Use inheritance to display attributes provided by super class by calling super.toString() method.

4.  Override the following methods.  This should include the following requirements:

• For each subclass, implement method query(). When this method is called, a query is made to the database to retrieve the information and then the information is printed to the screen. If appropriate, use toString() within the print() method.
• For each subclass, implement method update(). When this method is called, the database entry for the student is updated.
• For each subclass, implement method add() method. When this method is called, the database entry for the student is created.
• For each subclass, implement method delete(). When this method is called, the database entry for the student is deleted.

5.  Create an application that tests the following requirements:

• Application should allow the user to add, update, delete, and query any student type.

B.  Create UML Use Case Diagrams that could be inserted into a Software Requirement Specification (SRS) document that captures all functional requirements for this application. Use the task description in part A to elicit the requirements. You will only be required to document the functional requirements and provide Use Case diagrams. You do not have to complete a complete SRS document.

1.  Document the functional requirements with UML use case diagrams for each requirement. For each functional requirement provide the following:

• Requirement number and title
• Description of the functionality
• Input
• Results of processing or output
• Error handling or recovering requirements outlined
• UML use case diagrams (It is very important that your UML use case diagrams are complete and proper UML 2.0 Modeling notation is used.)

C.  Create UML Class and Sequence Diagrams that could be inserted into a Software Design Specification (SDS) document. (It is very important that your UML diagrams are complete and proper UML 2.0 Modeling notation is used. Your design must be an object-oriented design.) You will only be required to submit the class and sequence diagrams and not have to complete a SDS document.

1.  Your UML Diagrams should include the following:

a.  Comprehensive Class Diagrams: Show all classes and all relationships among all classes. These should include the following:

• Relationships: Your object oriented design will require you to diagram all class relationships using correct UML 2.0 Modeling notation which minimally includes:

»  Inheritance

»  Association Relationships

• Multiplicity: Note any multiplicity in the relationships (e.g., 1-1, 1-many, etc.) using correct UML 2.0 Modeling notation.
• Attributes: For each class, all attributes with types (e.g., int, double, etc.) and access control (e.g., private, public, protected) need to be noted using proper UML 2.0 Modeling notation.
• Methods: Methods with signatures and access control should be provided. All methods have to be indicated, including all constructors, setters, and getters.
• Abstract Classes and Interfaces: Any abstract classes and interfaces used in your design must be properly indicated using UML 2.0 Modeling notation.

b.  Sequence Diagrams: Model the object interactions required for each functional scenario. For each Use Case provided in the functional requirements section, at least one sequence diagram should be provided to model the interaction between the objects inside the application.

D.  Develop a test plan that includes test cases that test all functional requirements of the system.

1.  The test plan should include at least the following sections:

• Title Page
• Introduction: Brief description (suggested length of 1-2 paragraphs) of the application under test
• Overview of Testing Strategy: See part D1a.
• Resource Requirements: Discuss hardware and software required to complete the test plan.
• List of Features to Test: A simple table is sufficient. If features are numbered, the feature number can be used in your test cases.
• Acceptance Criteria: Identify the standards that must be met when considering if the application is ready for release. In your case, this means that the application should be ready to be submitted for grading.
• Test Cases: Should be submitted as an appendix to the test plan

a.  In the "Overview of Testing Strategy" section, compare white box testing, black box testing, unit testing, and integration testing and how they can be used to verify your application.

• Identify which testing strategy you will use.

2.  Execute the test plan, including running all test cases.

a.  Discuss the results of each test case in the "Test Cases" section.